managing projects - esi e-training - login: main

Managing Projects

© Copyright ESI InternationalNovember 2011All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, inany form or by any means, electronic, mechanical, photocopying, recording, or otherwise,without the prior written permission of ESI International.

ESI grants federal government users "Restricted Rights" (as the term is defined in FAR52.227-14 and DFARS 252.227-7013). Use, reproduction, or disclosure of these materials issubject to the restrictions set forth in the MOBIS, FSS, or contract under which the materialswere provided.

All material from A Guide to the Project Management Body of Knowledge (PMBOK® Guide)is reprinted with permission of the Project Management Institute, Four Campus Boulevard,Newtown Square, Pennsylvania 19073-3299, USA, a worldwide organization of advancingthe state-of-the-art in project management. Phone: (610)356-4600, Fax: (610)356-4647.

PMI® did not participate in the development of this publication and has not reviewed thecontent for accuracy. PMI® does not endorse or otherwise sponsor this publication andmakes no warranty, guarantee, or representation, expressed or implied, as to its accuracy orcontent. PMI® does not have any financial interest in this publication and has not contributedany financial resources.

The names of all companies and characters used in these materials are purely fictional. Anyresemblance to any existing or no longer existing company or living or dead person is notintended, and is purely coincidental.

PMI, PMBOK, and PMP are registered marks of the Project Management Institute, Inc.

State Council of Higher Education for Virginia (SCHEV) has certified this institution tooperate in Virginia.

ESI InternationalArlington, VA USA

Contents

Page

Module 1: Introduction to Project Management....................................... 1Introduction to Project Management ....................................................... 1

Introduction.......................................................................................... 1Module Overview................................................................................. 1Project Management Overview............................................................ 1

The Project............................................................................................... 2The Project Overview........................................................................... 2Project Management............................................................................ 3What Is a Program?............................................................................. 3The Project Constraints....................................................................... 4PMBOK® Guide Nine Knowledge Areas.............................................. 6The Project Life Cycle.......................................................................... 6Project Management Process Groups................................................. 7

The Project Manager Role....................................................................... 8Roles and Responsibilities of the Project Manager............................. 8Skills of the Project Manager............................................................... 9Professional Responsibilities of the Project Manager.......................... 9

Module Summary..................................................................................... 10Module Summary ................................................................................ 10

Module 2: Project Initiation ....................................................................... 11Introduction............................................................................................... 11

Module Overview................................................................................. 11Project Initiation ....................................................................................... 11

Project Initiation Overview................................................................... 11Project Influences .................................................................................... 12

Influences on a Project........................................................................ 12Project Stakeholders............................................................................ 13Project Personnel................................................................................. 14Understanding the Roles of Senior Management................................ 14Identify and Assess Business Needs and Opportunities..................... 15

Project Selection...................................................................................... 15Project Selection Overview.................................................................. 15Selection Tools.................................................................................... 16Qualitative Factors............................................................................... 16Benefit-to-Cost Ratio (BCR)................................................................. 17Present Value (PV).............................................................................. 18Net Present Value (NPV)..................................................................... 18Payback Period.................................................................................... 20

vii

Project Charter ........................................................................................ 21Project Charter..................................................................................... 21

The Right Start......................................................................................... 22The Right Start Overview..................................................................... 22Needs Assessment.............................................................................. 23Formulating Good Objectives.............................................................. 24Requirements and Specifications........................................................ 24Prototyping and Progressive Elaboration............................................ 25

Requirements Document.......................................................................... 26Requirements Document..................................................................... 26Project Requirements Document (PRD).............................................. 26

Module Summary..................................................................................... 27Module Summary................................................................................. 27

Module 3: Project Planning ....................................................................... 29Introduction............................................................................................... 29

Module Overview................................................................................. 29Project Planning....................................................................................... 29

Project Planning Overview................................................................... 29Core Project Team................................................................................... 30

Core Project Team Overview............................................................... 30Scope Planning........................................................................................ 31

Scope Planning Overview.................................................................... 31Work Breakdown Structure (WBS)........................................................... 32

WBS Structure..................................................................................... 32Key WBS Terms.................................................................................. 32WBS Models........................................................................................ 33Benefits and Uses of a WBS................................................................ 35How to Build a WBS............................................................................. 36WBS Dictionary.................................................................................... 36Where does the WBS Originate?......................................................... 37Translating the WBS into the Schedule............................................... 38

Estimating................................................................................................. 38Estimating Overview............................................................................ 38Good Estimating Practices................................................................... 39Estimating Techniques......................................................................... 39

Schedule Planning................................................................................... 41Schedule Planning Overview............................................................... 41Considerations for Estimating Activity Duration................................... 41Network Diagramming......................................................................... 42Transforming a WBS into a Network Diagram..................................... 43Forward Pass....................................................................................... 44Backward Pass.................................................................................... 46Network Analysis................................................................................. 48Displaying Schedule Data.................................................................... 49Gantt Charts......................................................................................... 49Project Calendars................................................................................ 49

viii

Milestone Charts.................................................................................. 50Estimating Cost and Determining the Budget.......................................... 50

Estimating Cost and Determining the Budget Overview...................... 50Estimating Cost Inputs......................................................................... 50Types of Cost Estimates...................................................................... 51Cost Components................................................................................ 52Cumulative Cost Curve........................................................................ 52

Resource Planning................................................................................... 54Resource Planning Overview............................................................... 54Resource Planning Tools and Techniques ......................................... 54Roles and Responsibilities Matrix........................................................ 55Resource Gantt Chart.......................................................................... 55Resource Loading Table...................................................................... 56Resource Loading Histogram.............................................................. 56Resource Leveling............................................................................... 56

Risk Planning........................................................................................... 57Risk Planning Overview....................................................................... 57Risk Identification................................................................................. 57Risk Probability and Impact................................................................. 58Risk Management Planning................................................................. 58ESI’s Risk Management Model............................................................ 59Risk Response Strategies.................................................................... 60

Procurement Planning.............................................................................. 61Procurement Planning Overview......................................................... 61Make-or-Buy Decision.......................................................................... 61Contract Type Selection....................................................................... 62Preparing Procurement Documents..................................................... 63Statement of Work............................................................................... 63Selecting the Contractor...................................................................... 64

Communication Planning......................................................................... 65Communication Planning..................................................................... 65

Quality Planning....................................................................................... 65Quality Planning................................................................................... 65

The Project Management Plan................................................................. 66From Planning to Implementation: The Project Management Plan..... 66Project Management Planning Software............................................. 66

Project Baselines...................................................................................... 67Project Baselines Overview................................................................. 67Who Needs Baselines?........................................................................ 67


Module 4: Project Implementation............................................................. 69Introduction............................................................................................... 69

Module Overview................................................................................. 69Project Implementation............................................................................. 69

Executing and Monitoring and Controlling........................................... 69

ix

Assessing Project Performance............................................................... 70Assessing Project Performance Overview........................................... 70Monitoring Project Performance.......................................................... 70Earned Value Management (EVM)...................................................... 70Variances............................................................................................. 72Assessing Project Status..................................................................... 74Corrective Action.................................................................................. 75Ways to Speed Up Schedules............................................................. 75Performance Reporting........................................................................ 76Project Evaluation................................................................................ 77

Managing Change.................................................................................... 78Changes............................................................................................... 78Change Control Board......................................................................... 79Configuration Management (CM)......................................................... 79

Managing Risk.......................................................................................... 80Managing Risk Overview..................................................................... 80

Quality...................................................................................................... 80Quality Overview.................................................................................. 80

Developing the Project Team................................................................... 82Developing the Project Team............................................................... 82Characteristics of Effective Teams...................................................... 82Acquiring Project Team Members........................................................ 83Project Team Structures...................................................................... 84Organizational Structures.................................................................... 85How to Form a Successful Team......................................................... 85Rewarding Project Team Members..................................................... 86Team Conflicts..................................................................................... 87Managing the Team............................................................................. 87

Managing Stakeholder Expectations........................................................ 88Managing Stakeholder Expectations Overview................................... 88

Scope Verification and Customer Acceptance......................................... 88Scope Verification and Customer Acceptance Overview.................... 88


Module 5: Project Closeout........................................................................ 91Introduction............................................................................................... 91

Module Overview................................................................................. 91Project Closeout....................................................................................... 91

Project Closeout Overview................................................................... 91Closeout Guidelines and Issues............................................................... 92

Guidelines for Project Closeout........................................................... 92Closeout Issues................................................................................... 93

Procurement and Project or Phase Closeout........................................... 94Procurement and Project or Phase Closeout Overview...................... 94Lessons Learned................................................................................. 94

x

People-Oriented Closeout Activities.................................................... 95Module Summary..................................................................................... 95

Module Summary................................................................................. 95 ...................... 145

xi

Module 1Introduction to Project Management

Introduction to Project Management

IntroductionThis text is intended to provide you with a quick reference guide to the fundamentals andconcepts of managing projects. It addresses the roles and responsibilities of the projectmanager across the project life cycle. It defines and develops the foundations of a projectmanagement plan, including the project requirements document (PRD), work breakdownstructure (WBS), costs, schedule, and other resources. It explains the basics of managing andcontrolling a project as actually performed against the project baseline and concludes with anexplanation of how to close out a project effectively.

Module OverviewThis module introduces the fundamentals of project management: the basic terms and conceptsthat underlie all the more detailed methods applied and activities that project managers andproject team members undertake.

Project Management OverviewAny study of project management should begin with the basic terms and concepts that provide afoundation for the detailed methods and activities that project managers and project teammembers perform throughout the life cycle of a project. Some of these terms and concepts arerelated to the project itself, such as the actual idea of a project, as well as the concept of theproject life cycle. Others relate to the discipline of project management: the project constraints(scope, cost, time, risk, quality, and resources) that silently govern every project; the keyprocesses that occur in every project; and the roles, responsibilities, and key competencies ofthe project manager.

Even though you may be encountering these terms and concepts for the first time, you probablyhave been involved in projects previously to some degree or another. If so, then you most likelywill find that you have already experienced the realities that they describe.

Module 1: Introduction to Project Management

© ESI International PMC:CPM:EN:000 ver. 1.0 1

The Project

The Project OverviewThe most fundamental concept in the field of project management is the idea of the projectitself. What is a project? What is not a project?

The Project Management Institute, Inc., known as PMI® is a professional organization dedicatedto advancing the understanding and use of project management principles. It is a leadingorganization in the field, and it publishes A Guide to the Project Management Body ofKnowledge, or PMBOK® Guide, which is widely accepted. In the PMBOK® Guide, p. 442, aproject is defined as “a temporary endeavor undertaken to create a unique product, service, orresult.”

Because the PMBOK® Guide’s approach constitutes a widely accepted means of breakingdown project management concepts and terms, its definition of the term “project” is a goodplace to start. A close look at the definition shows that projects have two key characteristics thatdistinguish them from other endeavors:

Projects are temporary.

Projects have unique product or services.

What does it mean to say that a project is temporary? It means that a project has a definitebeginning and end, but it doesn’t necessarily mean it is short in duration. This is true in both theplanned and actual sense, which distinguishes a project from other endeavors. For example,running a business or even a process within a business will have a definite beginning, butgenerally the hope is that it will never end, or that it will at least continue to operate successfullyfor as long as possible. It is therefore not a project. However, the endeavor of getting a newbusiness or new business process up and running is a project because it has not only a startpoint, but is also concluded when the new business or process has been launched and isunderway.

What is the significance of a unique end result? The key point is that projects are not the sameas processes designed to produce the same result over and over again. If a company decidesto build a microchip production plant for several hundred million dollars, then that’s aconstruction project. The characteristics of the facility and the site combine to make the plantone of a kind. After the microchips start rolling off the assembly line, you have mass productionof chips that do not differ from one to another. Similarly, if a business undertakes a processimprovement initiative for a customer service process, the development and implementation ofthe new or improved process constitutes a project, whereas subsequent, repeated performanceof the process does not.


2 PMC:CPM:EN:000 ver. 1.0 © ESI International

Project Management

According to the PMBOK® Guide, p. 443, project management is “the application of knowledge,skills, tools, and techniques to project activities to meet the project requirements.” This isaccomplished through the application and integration of the project management process ofinitiating, planning, executing, monitoring and controlling, and closing.

Now that you know what a project is, should you just let a project run its course on its own? Ofcourse not! If you let it run on its own or with minimum management, a project may or may notwork.

Instead of taking that risk, you should employ the techniques and concepts of projectmanagement. Project management helps ensure that time and resources are used mosteffectively to meet the project requirements or scope. Indeed, project management is a process,which is strongly emphasized in the PMBOK® Guide. As you’ll see in more detail later, there arebasically two roads to project management success: good planning or blind luck. It’s yourchoice.

What Is a Program?

There can be numerous projects in the ongoing operation of the business. Projects that aresimilar in nature or related in some other respect can be managed in a coordinated way toobtain benefits not available from managing them individually. When they are managed in sucha coordinated way, they constitute a program (PMBOK® Guide, p. 442).

For example, the Department of Transportation may have a highway improvement program thatcombines all new highway construction projects. One of the projects may be a complicatedexpansion of a major highway interchange. That project may be divided into several subprojects(smaller projects) requiring the building of new ramps and the removal of old ones, which mustproceed in sequential phases in order to maintain traffic flow and safety.

Take, for example, a company that decides to launch a broad-based,e-business initiative. Suppose that various individual projects are pursued, including thedevelopment and implementation of electronic business-to-business capabilities, onlinecustomer sales and service, and Web-based marketing and promotional techniques. Eachdevelopment effort will be a project in itself, but because they are closely related, it would belogical to manage them all together as an e-business development program.

Although program management and project management obviously affect each other, programmanagement requires different techniques because it addresses issues at a higher level andrequires a greater focus on the ongoing use and management of limited resources acrossmultiple endeavors. Programs mistakenly identified as projects may fail because programs can’tbe managed like projects. They usually do not have a defined beginning and end like projectsdo. They also lack the degree of specificity and clarity in their objectives that projects musthave. Unlike projects, programs cannot rely exclusively on borrowed resources. Instead, theymust rely on ongoing, long-term management and teaming structures, whereas projects areconstructed with an end in mind. A system or ongoing operation merely supports the projectsand programs within an organization. It is an ongoing or repetitive way of doing something. As



the organization evolves over time, so will the supporting operations. Consider, for example, thepayroll system in a typical organization. For years, paychecks were taken to the bank every payperiod to be cashed. With the push to go “paper free,” many organizations transitioned toelectronic pay stubs and automatic deposits.

Because individual projects within a program are related in some way, a change in one projectmay affect another project in the program. The program manager is responsible for monitoringimpacts of this nature.

Other important relationships include portfolio and portfolio management, as well as the role ofthe Project Management Office, as referenced in the PMBOK® Guide.

The Project Constraints

The project constraints, which represent the scope, cost, time, risk, quality, and resources on aproject, are key aspects of project management and are depicted as an interrelated graphicbecause each facet is critical and related to the others. In fact, changing one almost inevitablychanges the others.

What is meant by each facet or factor of the project constraints?

Scope: As defined in the PMBOK® Guide, p. 448, scope is “the sum of the products, services,and results to be provided as a project.” More specifically, project scope is “the work that mustbe performed to deliver a product, service, or result with the specified features and functions”(PMBOK® Guide, p. 444). In other words, project scope is all of the work that must becompleted for the project.

Budget/cost: “The approved estimate for the project to any work breakdown structure



component or any schedule activity” (PMBOK® Guide, p. 428)

Schedule/time: “The planned dates for performing schedule activities and the planned dates formeeting schedule milestones” (PMBOK® Guide, p. 444)

Risk: “An uncertain event or condition that, if it occurs, has a positive or negative effect on theproject’s objectives” (PMBOK® Guide, p. 446)

Quality: “The degree to which a set of inherent characteristics fulfills requirements” (PMBOK®

Guide, p. 445)

Resources: “Skilled human resources, equipment, services, supplies, commodities materials,budgets, or funds” (PMBOK® Guide, p. 446)

What then are the “constraints”? The constraints are how each factor affects the others. Forexample, if a decision is made to speed up the schedule and complete a project earlier thanoriginally planned, this will have repercussions. It may require the assignment of moreresources or a reduction in the scope of the project, thus lessening the quality. If projectmanagers can make their managers and clients understand the project constraints, they willavert or solve many potential problems!

The classic example of having to compromise to keep the project constraints balanced ariseswhen the project schedule must be accelerated. If a project manager develops a reasonableschedule to complete a project within two months but is required to finish in half the time, one ofthree things will have to happen: The project will either cost more because it will require addedor more costly resources to complete on time; the end product’s scope or quality will suffer; riskincreases regardless, or some combination of these consequences will occur.

The concept of the “constraints” can be used early in the planning stages to understand theneed to consider each factor and how it relates to the particular project. It can also be usedduring the course of the project to deal with changes, contingencies, and other unforeseeableissues that may arise.

The important thing to remember—whether you are thinking about processes, phases, orsomething else related to project management—is that they all take place against the backdropof the project constraints.

From the first day of the project, the factors that make up the project constraints are competingwith each other. As the PMBOK® Guide, p. 443, states, good project management is “theapplication of knowledge . . . to meet project requirements.” As the project manager, you mustunderstand the limitations that the project constraints impose and then work to find the balance.

There are no magic formulas here, just hard work, common sense, and persistence to find theartful way to accomplish what you need to. This is a constantly changing balance. Early in theproject, extra emphasis may need to be placed on scope matters. Later, cost trade-offs may benecessary to finish key portions of project scope by a particular date, such as a stockholders’meeting or the key season for a cyclical business.



PMBOK® Guide Nine Knowledge Areas

The purpose of the PMBOK® Guide is to identify that subset of the Project Management Body ofKnowledge that is generally recognized as good practice. The PMBOK® Guide, p.43, presentsthe discipline of project management in a matrix format based on nine “knowledge areas”.

The nine project management knowledge areas are—

Integration Management

Scope Management

Time Management

Cost Management

Quality Management

Human Resources Management

Communications Management

Risk Management

Procurement Management

For example, all nine project management knowledge areas involve planning processes tosome extent, but integration and communication management are the only knowledge areainvolved with initiating a process.

The Project Life Cycle

Although industries define the phases of a project differently, all the definitions boil down to thesame thing: a beginning, middle, and end that together constitute the project life cycle. ThePMBOK® Guide, p. 20, notes that each phase is a natural point to reassess the project todetermine if it continues or terminates and is usually marked by the completion of one or moredeliverables—that is, a tangible, verifiable work product.

Based on your own experience, chances are you will be familiar with differently named ororganized phases within a project life cycle. Many industries, government agencies, andbusiness enterprises have their own terminologies for explaining the project life cycle. Forexample, in the construction industry, developers may refer to feasibility, planning and design,construction, and turnover and start-up. Defense acquisition projects will go through the steps ofdetermination of mission need, concept exploration and definition, demonstration and validation,engineering and manufacturing development, and production and deployment. Drugmanufacturers will follow a cycle defined by discovery and screening, preclinical development,registration workup, and postsubmission activity. Software development firms will go through thesteps of feasibility, requirements, product design, detailed design, coding, integration, andimplementation.

In this text, we use a very generic, four-phase life cycle.



Initiation Planning Implementation Closeout

Initiation: This phase involves defining the business needs and client needs; formallyauthorizing the project to proceed; and identifying and developing the functional andtechnical requirements that lay the foundation for the project.Planning: This phase involves producing the project plan, which consists of the workbreakdown structure (WBS), schedule, budget, staff requirements, risk plan, communicationplan, quality plan, and procurement planImplementation: This phase involves executing the development of the solution whilemonitoring the performance and controlling the changes to align with stakeholderexpectations.Closeout: This phase involves reassigning all resources back to the organization; holdingpostproject reviews with the client; managing contracts, and documenting lessons learned.

Although different industries and organizations may label their project management phases bydifferent names because of the wide use of the PMBOK® Guide, this reference material will usethis generic life cycle in explaining project management.

Project Management Process Groups

The PMBOK® Guide recognizes an important aspect of the various processes involved inproject management. They often interact in complex ways and are not completed in a consistentor simple step-by-step fashion. Within each process and between processes, interactions andmuch iteration take place.

According to the PMBOK® Guide, p. 39, the five types of processes that occur in a project are—

Initiating Process: Defining and authorizing the project or phase. Even though projectmanagers are rarely involved in this process, they need to know what has happened andwhat they have inherited.Planning Process: Defining the project scope, refining objectives, and selecting the best ofthe alternative courses of action. This is the heart of the project manager’s job and it coversa lot of territory.Executing Process: Coordinating the people and other resources to carry out the plan. You,as the project manager, are not doing the work (except, maybe, on very small teams), butyou are working to allow others to implement or execute it.Monitoring and Controlling Process: Ensuring that project objectives are met by monitoringand measuring progress to identify variances from the plan so that corrective action can betaken. Do things always follow the plan? Of course not. Executing and Monitoring andControlling together make up implementation of the project after planning.Closing Process: Formalizing acceptance of the project (product, service, or result) or phaseand bringing it to an orderly end. Everyone is usually in such a hurry at the end of the projectto move on, but as we’ll see in Project Closeout, proper closeout is critical for real projectsuccess.

Besides the interactions among processes (such as between project control and execution), aproject may go through this series of processes more than once. For example, a large building



project may first go through design and then construction, with each major construction phasehaving its own initiation, planning, execution, control, and closeout.

The need for these processes depends on the nature of the project. For example, you mayidentify and analyze risk at different points in project planning or you may not analyze risk at all,based on the size, cost, and complexity of the project. In the case of a simple project beingperformed with internal resources, engaging in risk analysis may not be worth the time andeffort, and you also may have no procurement processes to consider.

Although these types of processes are active in each task, each phase, and the entire projectlife cycle, not all process types are involved with all knowledge areas.

The Project Manager Role

Roles and Responsibilities of the Project ManagerAll project managers must assume certain roles and responsibilities to provide good projectmanagement. The minimum basic responsibilities required of project managers include thefollowing:

Define project scope and clarify requirements

Select, build, and lead the project team

Identify and assess stakeholders

Develop the project plan including the WBS, budget, and schedule

Manage and control project risks

Manage project changes

Keep the project on schedule and within budget

Monitor and report project progress and status

Manage expectations and watch for and react to future trends

In fulfilling these responsibilities, the project manager must relate to the parent organization, theproject team, and the client. In dealing with the organization, the project manager must provideinformation to supervisors and other interested persons, obtain resources from other divisions,and coordinate with other project teams doing work for the same client. In managing the projectteam, the project manager must supervise them, lead them, provide them with resources, andprotect them from detrimental outside influences so they can get the project done. In working forthe client or customer, the project manager must communicate project status, manageexpectations, and otherwise make sure that the client remains satisfied.



Skills of the Project ManagerIn the expanded role associated with the new project management paradigm, project managersneed a broad set of skills to be effective. It is still true that traditional project management skillsin scheduling, budgeting, and allocating human and material resources are necessary. Theseare the primary tools of project managers, who are considered to be only implementers—thetools of technicians. Project managers should still be proficient in these so-called “hard skills,”as well as others such as contracting, financing, measuring performance, monitoring quality,and managing risk.

However, project managers also need to be adept at “soft skills” such as communicating;negotiating; problem solving; having political and cultural awareness; and understanding theneeds and wants of the people they deal with, including customers, peers, staff, and their ownmanagers. The primary role of the project manager is to make things happen. It takes both hardskills and soft skills to be successful in today’s complex business environment.

Professional Responsibilities of the Project ManagerIn addition to general management responsibilities, the project manager also has otherprofessional responsibilities of an ethical nature. These include the following:

Professional conduct

Integrity

Responsibility for actions of the team and the organization

Self-improvement

Fairness

Honesty

Communication

In brief, the project manager is expected to be a professional and to act accordingly. Theposition of project manager is currently considered to be a professional position, not just a title.During the past 15 years, organizations like PMI® and ESI International have worked hard toraise the standards of project management. Today, PMI® includes professional and socialresponsibility as a part of the PMP® certification examination.



Module Summary

Module SummaryA project is “a temporary endeavor undertaken to create a unique product, service, or result”(PMBOK® Guide, p. 442).Project management is “the application of knowledge, skills, tools, and techniques to projectactivities to meet the project requirements” (PMBOK® Guide, p. 443).The project manager must balance the project constraints of scope, cost, time, risk, quality,and resources over the life of the project.The phases of a project (which often vary by type of project) make up the project’s life cycle.An example of a project life cycle is Initiation, Planning, Implementation, and Closeout.Five interacting processes groups work together to make up a project: initiation, planning,execution, control, and closeout.Activities and processes within the five process groups are categorized within the nineknowledge areas.To be effective, project managers need to have “hard” skills, such as planning andbudgeting, as well as “soft” skills like communicating and conflict resolution.The project manager’s primary role is to manage the project, but also important are therelated roles of planning, leading, communicating, negotiating, and problem solving.



Module 2Project Initiation

Introduction

Module OverviewThis module focuses on project initiation. Even though the initiation of the project is often aunique process in that the project manager may have little or no input, it is important that theproject manager understand the process.

Project Initiation

Project Initiation OverviewFrom the project manager’s viewpoint, the initiation of the project is often a unique process inthat the project manager may have little or no input. Project initiation is often something thatsenior management has done before the project manager has been assigned. Nevertheless, theproject manager should understand the organizational influences on a project, the externalinfluences, and the role of stakeholders and senior management in the process of projectinitiation and in the success of the project, as well as the quantitative and qualitative methodsthat senior management may use to select projects.

In order to participate in the Initiating process effectively to the maximum extent possible whengiven the opportunity, the project manager should also have command of certain skills, such asthe ability to—

Develop good project objectives based on assessing needs

Distinguish between functional and technical requirements and to understand the role ofbothDevelop a project charter and a project requirements document

Analyze stakeholders and assess their power and influence

Module 2: Project Initiation


Project Influences

Influences on a Project

Various influences have a bearing on the performance and outcome of most projects. Theseinfluences may be internal in the form of the organization’s systems, structures, and culture. Aproject sponsor, which the PMBOK® Guide, p. 449, defines as “the person or group thatprovides the financial resources, in cash or in kind, for the project” is a key influence. In addition,enterprise environmental factors and organization process assets play a significant role in thelife of the project. There also may be external social, environmental, and economic factors. Inany event, a project never takes place in a vacuum. The more savvy you are about analyzingand proactively dealing with the influences on your projects, the more successful your projectswill be.

Because projects are carried out within larger organizations (whether for profit, nonprofit,personal, or government), characteristics of the organization influence the project. Being awareof these characteristics is essential. The systems of an organization will determine how thingshistorically have been done. How has research been carried out, for example, and how havecosts been tracked and allocated?

Organizational structure is a key internal influence:

Is the organization set up by function (engineering, marketing, and so on), by project teams,or by some other method?How does your project fit within the existing structure?

Where does the power and control of funding primarily rest, with functional managers orproject managers?Where does the control of human resources rest? With the project manager or the functionalmanager?

The answers to such questions can have a dramatic effect on how a project is accomplished.

The culture and style of an organization will affect its projects. Is the organization hierarchical?For example, must project managers go through functional managers to request assistancefrom another department? Or is it a more laid-back culture in which you can stroll down the hallor send off an e-mail to anyone at any level? The fact that something has “always has beendone this way” shouldn’t dictate the future, but the wise project manager will be mindful ofprevailing practices.

External factors of a social, economic, or environmental nature are almost always outside thecontrol of the project manager and the project team, yet they can make or break a project.Building a factory in another country will require adjustment to social customs and practices andthe local legal system. Completing a complex software development project where developersare in high demand and short supply will have a significant effect on project costs. Constructing



a nuclear power plant in the United States will be subject to environmental concerns. A goodproject manager must always be able to adjust project planning and execution to account forexternal factors such as these.

Project Stakeholders

What is meant by the term “stakeholders”? According to the PMBOK® Guide, p. 450,stakeholders are “persons and organizations such as customers, sponsors, performingorganization and the public, that are actively involved in the project, or whose interests may bepositively or negatively affected by execution or completion of the project.”

The PMBOK® Guide definition goes on to add, “They may also exert influence over the projectand its deliverables.” Some common examples of stakeholders include—

The organization’s leadership (for example, the head of a department that is expected tobenefit from an internal project)The client (for example, the bank that has hired a software development firm to design andbuild an online banking system)Customers/users (for example, the individual holders who will use that online bankingsystem after it is built)Partners in accomplishing the project (for example, vendors and subcontractors who areworking for a prime contractor on any kind of project)Special interest groups (for example, environmentalists with concerns about how a newbuilding may affect land use, or minorities interested in allocation of contracts)Government regulators (for example, the Food and Drug Administration in relation to apharmaceutical project, or a state transportation department in relation to a highway project)

As the list above suggests, stakeholders include some fairly obvious categories, as well asmany other people within and outside the organization that perform on the project. The projectmanager should cast a large and broad net to consider a project’s stakeholders and theirinterests because it is better to “over identify” stakeholders than to leave some out. ThePMBOK® Guide, p. 23-27, suggests at least the following:

Influencers

Project management team

Project management office

Sponsor

User

Performing organization

Several criteria can be used to determine who the project stakeholders are. Consider thefollowing:



Who gets the output from the project?

Who provides the input to the project team?

Who has the oversight responsibility?

Who has other related responsibilities?

Who reaps the rewards?

Who suffers the penalties?

After you identify who the stakeholders are, ask the “What’s in it for me?” (WIIFM?) question ontheir behalf. Then figure out the answer and share it with them because, to get people’s buy-in,you need to show them how they will benefit from helping you. If you fail to take thisfundamental step, you risk subjecting your project to a “unit veto.” In other words, anystakeholder—no matter how powerful or seemingly insignificant—may be able to veto yourproject, some completely and some only temporarily.

For example, a functional manager can most likely get your project cancelled if you do not havehis or her buy-in, whereas a procurement clerk can delay your project for a week or so by notordering what you need in a timely manner.

Project Personnel

PMI® recognizes three types of project personnel: the project manager, the project managementteam, and the project team. The PMBOK® Guide, p. 444, defines the project manager as “theperson assigned by the performing organization to achieve the project objectives” and theproject team as the group that is performing the work of the project, but may not be involved inthe management of the project.

In addition, most project managers will need to designate a project management team (alsoknown as core project team) that will comprise the key players in the project and will participateheavily in planning and managing the work. On small projects, however, this may be all of theproject’s team members. The point is that the larger the project, the more likely its staffarrangements will take on a hierarchical management structure and include members who donot participate in planning and managing the endeavor.

Understanding the Roles of Senior Management

“Senior management” normally initiates projects. Every organization has different ways ofdetermining who constitutes “senior management” and what authority and power they have.Basically, they are your bosses, whether they are called program/portfolio managers, divisionheads, vice presidents, managing partners, or sponsors. Since senior managers are keystakeholders in any project, it is important to remember that the structure and culture of theorganization affect the project manager’s relations with senior management. Relations may bevery formal and hierarchical, very informal, or somewhere in between. A key relationship for theproject manager is that with the project sponsor, who provides financial resources, in cash or inkind, for the project.



However your organization may define and label senior management, you need to understandand use that information to your advantage. As a project manager, ask yourself two questions:

1. What do they need from me?2. What do I need from them?

After the project has been decided upon and you have been named the project manager,“senior management” is usually your boss or your boss’s boss, and will play a role throughoutthe life of the project. They may need to approve the project plan, go to other divisions to helpyou obtain resources, and so on. They need to be kept abreast of project status and know theycan trust you to get the job done. As many a boss has said, “I don’t like surprises.”

Identify and Assess Business Needs and Opportunities

The initiation of a project typically stems from either a business need or a business opportunity.Senior management decides to take on these projects for many reasons. Some of the generalfactors that give rise to a new project include—

Obsolescence (We have software that needs updating.)

Competitive forces (Our competitors are building a new superstore and we need to keep upwith them.)Client requirements (We bid on an RFP and won.)

Employee suggestions (An employee has an idea to produce better widgets.)

Other sources (The company owner has a vision of a robot that can scramble eggs.)

Although the project manager is not usually involved in many of these matters, understandingwhy the project has been initiated is critical to ensuring the project meets the needs it isintended to satisfy. To reach the goal, you should know where the goal originated. The mostimportant thing to keep in mind is that projects are conceived and initiated for several reasons;but ultimately, they must support explicit business objectives.

Project Selection

Project Selection Overview

Before launching any project, the initiators must decide whether the project should beundertaken. This often means choosing among more than one potential project, given thescarcity of resources that most organizations face. You will discover that project selectionpractices are unique to each organization. This is another good reason why project managersshould know their own organizational culture and that of their clients. That way, if you are giventhe opportunity to participate in project selection, you can provide valuable input to the seniormanagement decision makers.



Best practices in project selection encourage objectivity, but selection is rarely purelyquantitative. Being fair to all potential projects is critical, but some things are just not quantitativeby their nature and need to be more loosely identified. Although bias will never be eliminated,the more project managers recognize and try to minimize it through factual analysis, the betterthe selections of their organizations will be. If you are assigned to a project after the projectselection process has been completed, find out how objective the decisions were and how thatwill influence your own decisions during the project.

Regardless of how it is accomplished, project selection should align with an organization’sstrategic intent and be a part of an organization’s balanced portfolio. If a steel manufacturerneeds to diversify to survive, choosing to make minor modifications to its old processes is likelynot a good project selection decision. It would be better to spend the effort on developing a newline of business.

Selection Tools

Selection factors may be either quantitative or qualitative. Qualitative factors include thefollowing:

Stakeholder bias

Organizational fit

Risk analysis

Scoring models

Quantitative factors tend to focus on cost and include the following:

Benefit-cost ratio (BCR)

Present value (PV)

Net present value (NPV)

Payback period

These methods are used to select projects by senior management; they are used by the projectmanager when planning the project and selecting vendors and contractors during theprocurement process. There are many more selection methods, but they are beyond the scopeof this introduction to project management.

Qualitative Factors

Consciously or unconsciously, senior management is likely to consider the biases, preferences,or aversions of key stakeholders such as customers, shareholders, employees, and themanagers themselves. This is difficult to avoid, so it must be recognized.

Organizational fit addresses whether the project fits with what the organization wants toaccomplish, what the organization is able to undertake, and whether the project will further theorganization’s strategic mission. One example would be a nonprofit organization that rejects



large donations if they are earmarked for projects that are inconsistent with its core mission.Another would be a computer company, which provides database support to a local hospital,declining a request to manage a network upgrade project for the facility because the companyonly delivers software services. This is not to say that any variation from business as usualshould be avoided, but rather that senior management has (or should have) consideredorganizational fit in its decision making. Many an organization has gone out of business bydiversifying too far beyond its core.

Risk is another important concept in project selection. At this point, suffice it to say that theorganization should do a preliminary identification and analysis of risks to decide whether theproject is worth undertaking despite its associated risks and include the high-level risks to thebusiness if the project is NOT done.

The scoring model evaluates various elements on several criteria by the portfolio/teammanager or other senior management. There are many varieties from weighted scoring models(each criteria having a particular weight over other criteria) to prioritization matrixes.

Benefit-to-Cost Ratio (BCR)The benefit-to-cost ratio (BCR) compares benefits to costs by dividing the former by the latterand determining the ratio:

BCR = Benefit / Cost

The higher the ratio, the better the deal is. For example, suppose you have two alternative waysto perform a particular group of work packages worth $200,000 in progress payments from theclient. Using your own company’s staff will cost $50,000, but a subcontractor is willing to do thesame work for $40,000. In the first case, the BCR is 4:1. The second case is the better dealbecause its BCR is 5:1.

Like any mathematical formula, BCR has its limitations. It is important to remember that likeprofit margin, BCR only focuses on a ratio and not on the volume of work involved. It, therefore,tells you nothing about the value of the output. A large discount retail chain may have a muchlower profit margin (or BCR) than an exclusive boutique, but makes much more money becauseof its business volume. Like most formulas, BCR also ignores considerations that are moredifficult to quantify in cost terms. What is the monetary value of spending a little extra time toensure that a customer is happy with your product? BCR is even limited in the quantitativesense in that it usually is not calculated in a way that takes into account the time value ofmoney. Present value and net present value calculations must be used to accomplish that.



Present Value (PV)

Given the choice between receiving $1,000 now and $1,000 a year from now, everyone wouldsee that it would be preferable to receive $1,000 now, assuming there are no tax complications.That is because you could invest the $1,000 for a year and receive the benefit of havingwhatever you purchased with it: a year of fun if you bought a mountain bike, interest if youbought a bond, dividends if you bought stock, or profits if you used it in your own business. Byusing such a simple example, this “time value of money” is easy to understand, but people oftenlose sight of it or have trouble figuring it out in more complex situations.

The formula for present value makes this a simple process and tells you the value today offuture cash flows. It is stated as PV = FV / (1 + i)n where—

PV = present value

FV = future value

i = interest rate or internal discount rate per the time measure being used (such as annualinterest rate for money received in a certain number of years or monthly interest rate formoney received in a certain number of months)n = number of time periods from today (based on the same time measure used indetermining i)

This formula may look complicated, but it is a calculation that project managers actually use allthe time. It merely quantifies what you know intuitively. The earlier you bring money into yourorganization, the more it is worth to you. The later you can spend it, the less it costs you.

Suppose you have a client who wants to repay your invoice of $1,000 by waiting two years andpaying you a $250 late fee for a total of $1,250. Is this a good deal? The answer depends onyour organization’s cost of capital. An organization’s cost of capital is calculated andpromulgated internally by the CFO. Let’s assume your organization’s cost of capital is 15percent. The relevant calculation would be as follows with i equal to 15 percent per year (.15)and n equal to two years.

PV = FV / (1 + i)n

PV = $1,250 / (1 + .15)2

PV = 1,250 / (1.15)2 = 1,250 / 1.3225PV = $945

Although you get an extra $250 later, you lose $55 in present value under the proposed deal.Thus, it’s not worth waiting given your current rate of return.

Net Present Value (NPV)

The real value of cash flow in a project is dependent on the currency amounts and the timing ofthe transfers for both revenue and cost. Net present value logic looks at both the inflow andoutflow of money over time.

The basic formula is: NPV = PV benefits – PV investments (both over the flow of time)



It is used to compare revenues to costs in arriving at the value of a project or project component(as indicated by the subscripts), but it can also be used to compare the present value of any twocash flow projections. For example, in the project selection process, senior management maycompare the value of two different projects, and in the procurement process, the projectmanager may compare the costs of two different vendors.

Consider a case where you are comparing two software sources for a six-month. IT project Off-the-Shelf, Inc., is offering an already-developed product for $11,000 with all but a small portionof cutover support cost being charged up front. Coders, Ltd., is proposing development of aprogram from scratch for $12,000, but is willing to accept equal payments over the life of theproject. Your firm’s cost of capital is 1.5 percent per month. The payment schedules aresummarized in the following table, and the question is whether the opportunity to defer paymentby using Coders, Ltd., adequately offsets that supplier’s higher price.

Month Off-the-Shelf, Inc., paymentschedule

Coders, Ltd., paymentschedule

0 $8,000 $2,000

1 $2,000 $2,000

2 $2,000

3 $2,000

4 $2,000

5 $1,000 $2,000

Total price $11,000 $12,000

To answer the question, you need to determine the present value of each vendor’s proposedcash flow and net them by calculating the difference between the two. The present values ofeach vendor’s payment schedule are calculated in the following table, based on the 1.5 percentper month interest rate, using the formula PV = FV / (1.015)n to find the present value of each ofthe future payments.



Month Off-the-Shelf, Inc., paymentschedule

Coders, Ltd., paymentschedule

0 $8,000 $2,000

1 $1,970 $1,970

2 $1,941

3 $1,913

4 $1,884

5 $928 $1,857

Total price $10,898 $11,565

The calculation shows that spreading out payments does not adequately offset the higher priceof Coders, Ltd., and that selecting Off-the-Shelf, Inc., offers a net present value of $11,565 –$10,898 = $667. The point to remember is that when you factor money into making decisions,you need to account fairly for the time value of the money. Net present value allows you to dothis.

Payback PeriodPerhaps the simplest method of making decisions about the value of cash outlays isdetermining what the payback period is. This approach is nothing more than calculating howlong it will take to earn or save as much as you have invested. For example, if you invest $5,000in new equipment and expect to receive no benefit for one year and save $1,000 per yearthereafter, the payback will occur after six years. Obviously, the quicker the payback, the betterit is. To get the most valid results from this approach, especially when long periods of time andlarge sums of money are involved, the numbers used in determining the payback period may becorrected to reflect their present values.



Project Charter

Project Charter

According to the PMBOK® Guide, p. 442, the project charter is “a document issued by theproject initiator or sponsor that formally authorizes the existence of the project, and provides theproject manager with the authority to apply organizational resources to project activities.” Inaddition to having documentation of what a project is to accomplish, the project manager shouldhave documentation of the authority to accomplish it. This is the purpose of the project charter.An output of project Initiation, the project charter is a written agreement among seniormanagement, the project manager, and the functional managers. It is essentially an internal“contract” that gives the project manager the authority for the job that he or she is being askedto do.

The purpose of this document is to give the project manager and project team the support theyneed to perform effectively. Inclusion of the functional managers as signatories to the chartercan be crucial because they often provide the resources you need (people, equipment, supplies,places, and so on). The charter puts senior management on the line by assigning them the taskof supporting you. Depending on the corporate climate, this may be essential to success. Don’tleave them out of the process on this one!

To formally authorize the project, some description of what the project is must be documented.This high-level summary, sometimes referred to as an executive summary includes—

Project sponsor

Measurable objective for the project

High-level requirements (usually business requirements at this point in time, but will includeany requirements that are known)Project description

Summary (high level) of budget and milestone schedule

Project approval requirements (signatory authority for approving project deliverables, and soon)

The project charter also identifies and assigns the project manager. It also should include—

The project manager’s name

A description of the project manager’s responsibility

Details of the authority level the project manager has in regards to this project to manageorganizational resourcesThe names (and signatures) of the person(s) authorizing the project and project charter



What happens when your senior managers have not written a project charter and do not want totake the time? Then you might need to do it for them, making sure, of course, to get their sign-off. Without their sign-off, you do not have documented, express authority to act.

The formality of project charters may vary widely from organization to organization and evenfrom project to project within an organization. In some situations, the project charter may be asinformal as an e-mail from the boss saying it is okay to proceed. In others, the project may haveto be reviewed and approved by the customer, and written authorization to proceed may have tobe obtained. In this case, the concept includes the business case, and it serves as the charter.The point here is that different organizations may use different documents to authorize theproject.

The Right Start

The Right Start OverviewAfter a project has been selected to pursue, project Initiation should start with a solid needsassessment and then expand on it through the development of objectives, functionalrequirements, and technical requirements.

Although different organizations will define these terms differently, for the purposes of thiscourse, they mean the following:

Needs/Goals: something required or wanted; a requisite; often somewhat vague

Objectives: something worked or strived for; (whichshould be worked out between whoever has the needs and whoever will fulfill them)



Requirements: refinements of the objectives; in general terms, what the customer needs toaccomplish; the objectives should be expressed in functional terms or desired capability andexplain what the project result will do

– Business requirements: These quantify the need of the business.– Quality requirements: These provide the acceptable level of quality.– Functional requirements: Relate directly to business and user functionality such as

business rules, reporting, and so on.– Nonfunctional requirements: Relate to the characteristics of the solution such as

availability, security, documentations, and so on.Here is an example for a very simple project:

Wants/needs: We want/need to print PowerPoint® slides quicker because it takes too long toget ready for our presentations.Objectives: Reduce slide copy packet preparation time to less than four hours.

Requirements: We need a packet for the client that includes bound, clear color copies ofpresentation slides prepared within four hours after the presentation is finalized.

– Quality requirements: The PowerPoint® slides must include graphics and images ofphoto quality.

As each of these concepts is examined in more detail, it is important to remember that theproject manager must resist letting any stakeholders push too quickly for their preferredtechnical requirements. Before technical specifications are addressed, there must be a clear,mutual understanding of the real objectives and requirements. Otherwise, better solutions thanthe one ultimately chosen may be overlooked. In the example above, many people wouldimmediately jump at buying a high-priced, fast printer when a low-cost contract with a copy shopmay be more cost-effective or reliable.

Needs Assessment

Effective needs assessment requires a recognition that needs exist on a variety of levels amongthe various project stakeholders. In fact, projects often arise out of conflicting needs. This issimply because everyone has different needs. For example, suppose a contractor has beenawarded a contract to build a new bridge. The customer, nearby homeowners, commuters,environmentalists, local politicians, and others all have needs associated with this project. In thiscase, as often happens, needs often conflict and the project cannot meet everyone’s needs.Commuters prefer a multispan bridge to reduce commuting; environmentalists prefer topreserve the nearby marsh, and so on.

In situations like this, senior management must understand and then balance or prioritize theconflicting needs, often working with customers to help them sort out what they really need(versus what might be “nice to have”). According to the PMBOK® Guide, p. 429, collectrequirements “is the process of defining and documenting stakeholders needs to meet theproject objectives.” The project manager should help in the process whenever he or she isassigned early enough to do so. The better the conflicts are addressed up front, the easiermanagement of the project will be.



Needs also should be separated from wants. In the same example, the contracting agencyneeds a bridge to move 3,000 cars across the river each weekday. It would also like to have anadditional lane for a possible monorail system. Is this a need or a want? The agency mustdecide.

Customers often do not actually know or understand their needs. It is frequently appropriate toexpand the customer’s view of its needs by pointing out opportunities that can be built into agiven project; these may be options of which the customer is not aware but very glad toexercise.

Needs are actually assessed through document review, interviews, surveys, and audits. Theseare done both internally and with the customer. It is unwise to just take a list of wishes and goforward! Sort out—and help the customer sort out—what is needed versus wanted, as well asthe priority or hierarchy of needs. Superficial work here will haunt you for the rest of the projectand beyond.

Formulating Good Objectives

Objectives should be developed as an outgrowth of carefully considered needs. They shouldrepresent an understanding between those who need something and those who can provide it.Objectives exist at all levels: corporate, department, program, project, work team, and specifictask. Your company and client need clear objectives for the overall work; your boss and youneed clear objectives for the project; and you and your workers need clear objectives for thetask. Without this understanding, the likelihood of successful work is low, whereas the likelihoodof rework, frustration, and arguments is high.

Well-developed objectives are characterized by the five elements of the SMART model:

S = Specific

M = Measurable

A = Agreed-upon

R = Realistic

T = Time-bound

If you don’t know the objective, or it is not well-defined, you cannot do your job well.

An “objective” used in this sense is a concept or a descriptive goal, not a document.

Requirements and Specifications

Requirements are the next link in the chain that began with needs, which were then linked toobjectives. It should therefore be expressed in functional or business terms or in terms of adesired capacity. Functional requirements—what the customer needs to have happen—arederived from the objectives. Technical specifications are how the project team develops to meetthe functional requirements.



Customers have certain functions they need fulfilled, which, of course, are based on the needsalready assessed and the objectives that they have already agreed upon. The clearer and morespecific the objectives are, the less work needs to be done on functional requirements. Excellentobjectives serve as good functional requirements; weak ones need a lot of work.

The development of technical specifications can go astray in two ways:

1. The project team should not just be rewording the functional requirements into techno-speak. Instead, the team members should be thinking about the technical solution for thecustomer’s requirements.

2. The customers should not be coming up with the technical solution. That is one of the mainreasons they hired the project team!

Part of the project manager’s role is to get people to do their part of the job. You need to keepcustomers focused on capability and experts and technicians focused on specifics. Too often,both seem to want to wander into the other’s domain.

At the end of the process, you should check back and answer the question of whether thetechnical specifications map back to the objectives. If they do not, either the requirements or theobjectives need to be reworked.

Prototyping and Progressive ElaborationPrototyping is an approach in which the project team works with the customer to define therequirements, although they are still vague. When the first prototype is created, the customerand project team review, refine, and change it. They continue building on the prototype untilneeds are suitably defined.

Prototyping encourages change. It works well in fluid, highly conceptual efforts, and it promptsthe organization and the customer to examine and review a set of iterations. Progressiveelaboration, like prototyping, requires collaboration between the customer, project manager, andproject team. Progressive elaboration—commonly used in software development—involves theincremental development of requirements. Requirements are identified early in the project andrefined as the project progresses. While the scope of the project does not change, thecharacteristics of the project (and requirements) are progressively elaborated.

The objective is a happy customer; you can use the prototyping concept or progressiveelaboration to help customers understand what they want and will be happy with. Prototypingand progressive elaboration should not be allowed to occur haphazardly. There must be acommon understanding of what the prototyping will entail and how progressive elaboration willbe conducted. Prototyping and progressive elaboration can include a variety of tools to achievegood requirements:

Rough sketches

Scale models

Depictions (blueprints)



With each approach, the amount of time and the resources that should be expended on eachiteration should be determined. In addition, the approach needs to be a defined process andneeds to have written changes processed at each iteration that can be reviewed and decidedupon.

Requirements Document

Requirements Document

Requirements documents represent key milestones in the elicitation, analysis, documentation,and validation of requirements.

The business requirements document is created by the business analyst (BA) and handed offfollowing a formal review and approval by the project sponsor. This document provides insightsinto the current (AS-IS) and future (TO-BE) states of the solution.

The requirements work plan, created by the BA, defines the work to be accomplished duringrequirements elicitation, analysis, documentation, and validation. It must be completed andapproved before any requirements analysis work begins and it may become a component of theoverall project management plan.

Project Requirements Document (PRD)

The traceability matrix is used to show how requirements are mapped to both business needsand the resulting deliverables. All requirements must be linked from the lowest level (resultingdeliverable) up to the top level (business need) to ensure a strong business case.

The PRD is the official, formal document that describes the identified project requirements indetail for the project stakeholders. This document also is referred to by other names anddepending on the organization, it may be called the requirements specification, requirementsdocument, or the functional specification.

Whatever it is called, the PRD is used to develop the design and technical specifications for aproduct, system, or program. It provides definitive linkage to Initiation and Planning. It is awritten record of what has already been discussed and decided upon, and serves as the roadmap to direct the project team. Preparing a PRD also reduces the amount of rework on theproject.

The PRD is drafted by the project team and delivered to senior management and keystakeholders for approval at the conclusion of the Initiation phase. This document shouldinclude an overview of the product or system and the business needs that it addresses. Theoverview also should include a glossary defining business and technical terms discussed in thepaper. This is especially important to ensure a common understanding of significant termsamong project stakeholders.



Other sections typically included in the requirements specification are the following:

Project objectives

Scope statement or statement of work (SOW)

Product description

User characteristics

Assumptions

Constraints

Interrelated projects

Specific functional and technical requirements (these should document external interfaces,functionality, performance requirements, logical database requirements, design constraints,system attributes, and quality characteristics)

In order to ensure traceability, the PRD should be developed pursuant to policies andprocedures that control the links between requirements and project objectives. You should beable to trace a requirement from a source in the project—for example, an end user—throughoutthe life cycle to a test at the end of the project.

Module Summary

Module SummaryInternal and external factors influence every project.Senior management usually selects and initiates a project.Quantitative methods and qualitative considerations enter into project selectionProjects originate for many reasons, from product obsolescence to client requirements toindividual innovation.Needs must be assessed, objectives set, and requirements defined so that specificationscan be set.Customers define functional requirements.The project team develops the technical requirements.A project charter spells out the roles and responsibilities of the project manager and keymembers of the project team, as well as input from other organizational agencies.The project requirements document (PRD) is the official document that describes theidentified project requirements.The requirements traceability matrix maps the evolution of the requirements from thebeginning to the end of the project.



Module 3Project Planning

Introduction

Module OverviewThis module is the heart of this course, just as project planning is the heart of projectmanagement. This module focuses on the crucial time at the beginning of a typical project,when important planning functions occur.

Project Planning

Project Planning OverviewIn a project’s life cycle, planning is most important and extensive planning phase performedbefore Implementation.

The processes that a project manager must master include planning the project scope throughthe use of a work breakdown structure (WBS), scheduling the project, planning project costs,and planning for the use of project resources. The project manager also should plan for risk,procurement planning, communications planning, and quality planning. The key output of allthese planning processes is the overall project management plan.

Module 3: Project Planning


Core Project Team

Core Project Team OverviewOne of the first steps the project manager should take to optimize the effectiveness of projectplanning is selecting a core group of key people, referred to as the project management team inthe PMBOK® Guide, each of whom offers an expertise or specialty crucial to the project. Forexample, in the case of an IT project, the core team may consist of the project manager, asoftware engineer, a hardware engineer, and a finances expert. The number of people andspecialties will vary with the project.

You should note, however, who should not be a part of this core team. It should not includeeveryone on the project (unless, of course, it is a tiny project) since you want the core projectteam to be a small, highly interactive, flexible group with the expertise needed to manage theproject. Preferably, its members will be self-starters and the group as a whole will becomfortable with self-direction. This is not the place for senior management. Rather, this teamreflects the project, not your stakeholders. Core project team members are involved people whowill actively plan and aid in the implementation of the project.

Sometimes you can identify and recruit whom you want; sometimes you are “stuck” withassigned team members. Obviously, it is to your advantage to have desirable team members inmind and to get them assigned to your project. For example, if you realize that your project willinvolve a lot of testing, ensure that you have a person on the core project team with thatexpertise. Often, senior management needs to weigh in on your behalf to obtain suchresources, particularly when you are going outside of your division to recruit team members.

Although you are looking for specialists, you must be able to take a broader view. No matterhow talented they may be, you don’t want people who can only focus on their discipline. You dowant people who think “we’re all in this together.” If they are dispersed geographically, youshould try to assemble them at least once (hopefully, early for the planning work) for face-to-face contact, which makes subsequent e-mails and phone calls run more smoothly.

Why address this team now? The core project team must be involved in the project planningthat is about to be discussed. They are your planning helpers.



Scope Planning

Scope Planning OverviewThe following are key terms related to planning the scope of a project:

Scope: “The sum of the products, services, and results to be provided as a project”(PMBOK® Guide, p. 448)Scope statement: A detailed description of the project’s deliverables and the work necessaryto complete the deliverables. It can be a documented basis for making future projectdecisions and for confirming or developing a common understanding of project scopeamong the stakeholders. As the project progresses, the scope statement may need to berevised or refined to reflect approved changes to the scope of the project.Define scope: “The process of developing a detailed description of the project and theproduct” (PMBOK® Guide, p. 432); the process of progressively elaborating the work of theproject, which involves developing a written scope statement that includes the projectjustification, the major deliverables, and the project objectives. Scope planning is the mostimportant type of planning because planning for everything else, including costs, resources,risks, and so on, depends on it. It drives the other planning processes and thus the projectitself, so it is not just a paper exercise. If you haven’t planned well for the scope (recognizingthat there will be changes along the way), how can you accurately plan the time and costsinvolved? How can you manage customer expectations? How can you monitor and controlexecution of the plan? How do you know what you should and shouldn’t do to complete theproject?

Having outlined project scope in the project charter and having documented it in the PRD, thePlanning phase is the time to focus on project details. Has the scope, which was provided ingeneral terms from in the project charter, been well-defined? Does it make sense? If not, theproject manager must get clarification and understand how it was developed. The scopestatement that results from the define scope process will be one of the basis elements forthe WBS.



Work Breakdown Structure (WBS)

WBS Structure

According to the PMBOK® Guide, pp. 116 and 452, the WBS—

Is the process of subdividing project deliverables and project work into smaller, moremanageable components…with each descending level of the WBS representing anincreasingly detailed definition of the project work

Is a deliverable-oriented hierarchical decomposition of the work to be executed by theproject management team to accomplish the project objectives and create the requireddeliverables

Organizes and defines the total scope of the project

You should not conclude from this definition that the WBS is defined only to the deliverablelevel. Neither resources or budget, nor schedule can be estimated with any accuracy unless theWBS is taken to the task or work package level, wherever that level of detail may be. In manycases, the project cannot be managed with a WBS that addresses only the deliverable level. Inother words, a WBS is essentially the scope statement reduced to individual pieces of work.

Almost everyone involved in project management will have developed a WBS or heard of theconcept, although it may be called by a variety of names in different organizations. The WBSproceeds from the most general or “highest” level (for example, “build a plane”) throughintermediate levels to the most specifically detailed or “lowest” level. Each progressively lowerlevel will further break down the work described in the level above into pieces of work thatconstitute the whole (such as, from “build the wings” to “rivet aluminum to frame” and “polishassembled wing”). The hierarchical organization of the WBS, in which larger elements arebroken down into smaller ones, is the key to understanding it. The WBS is not just a scatteredto-do list.

A well-defined WBS is crucial for project planning and control. It can protect the project managerfrom the “gold-plating” that can occur as a project moves along and can thereby prevent theproject team from expending time and resources on work that should not be done.

Key WBS TermsTwo key levels of the WBS are the work package and the control account (previously called acost account). The work package is the lowest level of the WBS. It is the level where workpackages are assigned and monitored and is the primary level for addressing schedules,costing, and resource requirements. Through work packages, the project manager can assignresources and track progress without getting bogged down in too much detail.

An undefined work package is called a planning package. In the PMBOK® Guide, p. 441, aplanning package is defined as a “WBS component below the control account with known work



content but without detailed schedule activities.” This also can be considered a placeholder forwork packages when using a rolling wave style of planning.

So, how detailed do you make the WBS? Or in other words, how big or how small should a workpackage be? The question of level of detail is a nagging one that will never go away.

There is no hard-and-fast answer, but here are some good guidelines:

Make sure that a work package is small enough to assign to an individual or small team.

Consider the “80-hour rule,” which states that no work package should exceed 80 hours ofwork (about two weeks).Keep the goal in mind. If a work package looks like it will require you to micro-manage, it istoo small. If it looks like it will make meaningful monitoring of work progress difficult or overlygeneral, it is too large.Realize that if you need to consider part of the work package here and part there (as you docosting, scheduling, and resource allocation), it is probably more than one work package.

Every activity that the PRD requires must be covered in a work package. If it is not in a workpackage, it will not be accomplished. Obviously, however, there will always be individualactivities that contribute to completing work packages, but these do not belong in the WBS.Much of this detailed information does go into the WBS dictionary (which will be discussedshortly).

Control accounts constitute a level of the WBS that is used for management reporting. Theseterms are not used in an accounting sense but as a project management term: They are thelevel at which costs can be tracked in a meaningful way for senior management and for moregeneral monitoring without too much detail. They are typically found at a level above the workpackage, but this can vary. Because different sections of a WBS will have different levels, andsome sections will be followed more carefully by program managers than others, the projectmanager will have to determine wisely what level to use to control and report the project ratherthan to follow some specific numeric rule.

WBS ModelsThe WBS can take on multiple forms and each format has its own advantages. The two mostcommon forms for a WBS are indented and graphic. The same information can be displayed indifferent formats, as the following examples show.

Outline/Indented Format

1.0 Management Information Software System

1.1 Assess needs

1.1.1 Measure state of current system

1.1.1.1 Identify components of current system1.1.1.2 Analyze components of current system



1.1.2 Determine future capability requirements

1.1.2.1 Perform gap assessment1.1.2.2 Identify required changes

1.1.3 Develop alternative approaches

1.1.3.1 Identify alternative approaches1.1.3.1 Analyze alternative approaches

1.1.4 Develop system requirements1.2 Develop specification

1.2.1 Develop preliminary software specifications1.2.2 Develop detailed software specifications1.2.3 Develop preliminary hardware specifications

Graphic Format

The indented format offers several advantages: It is easy to include project details; it edits andloads into major software tools such as Microsoft® Project. It lends itself to printed reports andcomputerized monitoring, is logical to follow, and allows one to easily see the grouping of tasks.In addition, it facilitates tracing low-level issues by work package number back to broader levelsand their responsible managers, and it supports easy reference to specific work items.

Effective use of this numbering system requires that you follow certain rules. Because apublished WBS is distributed widely, there is no telling who might have it and reference to it.Therefore, a WBS number should never be changed, deleted, or reused, and you should always



add a new number for new work.

The graphic format is good for showing the relative levels of the work and how smallercomponents of the project roll up into larger ones. For presentation purposes, this format alsofacilitates adjusting the depth of detail that is appropriate for various audiences.

Some people interpret information easier when they view it graphically; others prefer lists. Itdepends on the project team and the customer’s needs. You may find that it is best to createboth: perhaps an indented format for your team so you can guide them in greater detail and agraphic diagram to use for briefing senior management or the client.

There is also more than one way to handle wording in the WBS: Some people prefer subjectentries that identify the work output (for example, a construction project would have entries forroof, windows, and so on). This deliverable-oriented approach can work for projects with mostlyclear, discrete outputs.

Others prefer brief verb-object entries that specify the tasks being performed (for example, layroof, install windows, and so on). In service-oriented cases, task-oriented wording betterdescribes the work. For example, a wedding reception project may have entries for coordinatingthe catering, setting up a receiving line, arranging the punch serving, and so forth.

Either style is acceptable. You should select the one that fits your project. The real key tosuccess is not the format chosen but the inclusion of all the work in the WBS, regardless of howit may be described and depicted.

Benefits and Uses of a WBS

One of the primary reasons for project failure is the lack of understanding of the projectrequirements. The WBS is the primary means for ensuring that the customer’s needs are metand that only the work that the scope defines is considered in the project effort. Its benefits canbe summarized as follows:

Identifies all the work necessary to accomplish the objectives and refines the objectives

Identifies only the work necessary

Identifies specific work packages for estimating and assigning work

Provides a structure for measuring success

Clarifies responsibilities

Forces detailed planning and documentation

The WBS is the most important project management tool because it completely identifies all thework that the project scope describes and provides the basis for detailed planning,implementation, and control of the project. Its resulting uses can be summarized as follows:

Planning

Budgeting



Funding

Estimating

Scheduling

Performance measurement

Configuration management

Integrated logistic support

Test and performance evaluation

With a very well-defined WBS, the project manager can develop every other tool that isnecessary to plan, implement, and control the project. For example, although the WBS itself isnot a schedule or a network, it is a necessary first step and primary source of information for thedevelopment of these tools.

How to Build a WBS

The top-down approach is the most effective approach to developing the WBS. This approachbreaks the whole project into progressively smaller pieces. This process begins with anunderstanding of the purpose of your project. Based on that understanding, you break theproject down into its major segments of work. Then you break down the major segments intotheir component parts and each component into its subcomponents. You continue this processuntil you reach a level of detail that is sufficient for assigning and monitoring project work.

A WBS can also be built from the bottom-up. This is a less common approach and typicallyreserved for projects where team members are extremely familiar with the work entailed for theproject. In this approach, team members brainstorm and identify as many activities as possible.Then the activities are organized into their logical task groups. Task groups are then organizedinto phases or major components. After organizing this preliminary WBS, the project managershould question the team about how to perform the project better. For example, what testingactivities can be developed and how can defects be identified and corrected? The projectmanager should make sure such questions are answered before the WBS is finalized.

For example, consider building a WBS for the development of a Web site from the bottom up.The first step would be to ask team members to list detailed tasks they think would need to beperformed to create a Web site. After listing the tasks, the team members would then group thetasks into categories. For example, a business analyst on the team might know how to defineuser requirements for the Web site. A systems analyst might know the hardware and softwarerequirements. The team would then group these varied requirements into one broader categorycalled “Identify requirements.” The same approach would be followed until all the work packagelevel components have been identified and incorporated into groupings of major work segments.

WBS Dictionary

The WBS dictionary is not a book of terms and definitions, but a convenient way to captureessential information about certain work package without cluttering up the WBS. It is used to



document critical, detailed background information for each work package such as assumptions,specific activities below the WBS level, assigned resources, preceding activities, andsucceeding activities. Its contents will vary depending on the information needs of the particularproject.

A WBS dictionary entry is not required for every WBS element—only for those that requireclarification. A rule of thumb is if the team members, key stakeholders, and you know what theWBS item means exactly, then the element doesn’t need one. But, if it requires an explanation(that is, edit report), then it is recommended using one (that is, prepare for production). Projectmanagement is all about a common vocabulary for managing projects.

As an example, for a work package called “feed the dog” with a duration of 20 minutes,dictionary data might include the following:

Resources: A dog bowl, dog food, the dog, my son who will feed the dog

Deliverables: A full dog bowl, a tidy kitchen

Predecessors: Put the cat in the basement.

Successors: Let the dog out in the backyard.

Description: My son gets the sack of dog food out of the cabinet and dumps some in the dogbowl. He returns the sack to the cabinet and calls the dog.Reminder: Let the cat out of the basement after completion.

Where does the WBS Originate?

The WBS dictionary is valuable in several respects. It—

Ensures that all critical information about an activity is captured and is clear to each teammemberEliminates doubts about roles and responsibilities associated with the activity, what input isrequired, and what needs to happen before and afterwardsIs an outstanding document to use in bringing new people into the effort because it clearlystates what is expected in a particular piece of workCan be helpful in tracking lessons learned and planning future projects

You don’t have to start every WBS from scratch, but you shouldn’t just take an existing one andplug in new information. Off-the-shelf software provides templates with which you can start;professional organizations are a great source for those within their specialties. Companies oftenhave their own templates and past projects provide a good guide—obviously, those that aresimilar will be most applicable.

But, you cannot just rely on what already exists. Your creative energy, along with that of theproject team, will be needed to develop a WBS, especially when you are dealing with first-timeprojects or projects done in a completely new environment. Starting points such as templatesare great, but the core project management team will have to modify, expand, and adjust fromwhatever starting point they use to successfully address their project. You should never expect



to pull a WBS off the shelf and use it without making modifications. Remember, one of the keytraits of projects is their uniqueness. No two projects are ever exactly alike.

Translating the WBS into the Schedule

The primary purpose of the WBS is to identify all the work within the project scope, but in orderto plan how the project will be executed, the identified work also must be quantified.

Integrating those work packages requires information about the work packages beyond thedefinition of the work itself. You need to break down the work packages into activities. It is theseactivities that you will use to determine how long each package will take to perform, how much itwill cost, the resources it will require, and so on. This is the role of estimating. You cannot domore planning without these estimates.

The more you treat estimating as a deliberate process and not just guessing, the more likely youwill succeed. Three of PMI®’s 20 core planning processes are specifically named “estimate”(estimate activity durations, estimate activity resources, and estimate cost), and several othershave major estimating activities in them. The basic concepts of estimating apply to all aspects ofestimating. In other words, gathering data to estimate time follows the same basic process asgathering data to estimate cost.

Estimating

Estimating Overview

Estimating is another key step in project planning and a natural next step after development ofthe WBS. According to the Dictionary of Project Management Terms, p.151, estimating is“forecasting the cost, schedule, and resource requirements needed to produce a specificdeliverable.”

Estimates are the bridge from the WBS to planning schedules, costs, and resources:

Time estimates for scheduling

Cost estimates for budgeting

Personnel time estimates for staffing

Equipment estimates for resource allocation

Estimating is sometimes as much art as science, and it is an essential element to good projectplanning. The validity of the estimates heavily influences the smoothness of the project and thelikelihood of being on target or suffering overruns. Project managers must not succumb to thetemptation to belittle estimating on the grounds that everything will change or turn out differentlyanyway. In the first place, that’s not always the case. Carefully developed estimates help keepprojects on track by providing performance measures and permit more logical incorporation ofchanges into the plan. In addition, a well-prepared baseline estimate makes changing more



precise and easy, and provides a way to compare and determine whether the ongoing changesmake sense and are working.

Good Estimating PracticesThere are many levels of estimating precision; estimates range from ballpark to highly detailedfigures. The project manager should be clear about what kind of estimate can be made basedon the time and resources available and the precision of the scope information provided. Basedon that, the project manager must clearly communicate what kind of estimate is being providedto those who ask for it.

High accuracy is not always possible or desired. For instance, if a new client is beginningdiscussions and asks general questions to see whether the expected cost is in keeping with itsplans, a general ballpark estimate is in order. This can be calculated simply by comparison topast projects of a similar nature combined with appropriate adjustments for differences, such ascost escalation.

To develop a detailed project budget, you need more accuracy and a correspondingly detailedscope of work broken down into a WBS. That which the WBS has identified must now bequantified before you can continue planning. In the WBS, you broke down the project into smallassignable units called work packages. Each work package is a discrete piece of the projectthat must be accomplished. These units must now be planned specifically and integratedtogether into the project plan to create a detailed estimate “from the bottom up.”

To accomplish that integration, some information needs to be known about each work packagebeyond the definition of the work itself. You need to estimate how long it will take, how much itwill cost, and what resources it will require. You cannot do more planning without theseestimates.

The quality of your estimating will directly influence the quality of the project. When you areestimating work or effort, you are laying the groundwork for the remaining key elements ofplanning, such as scheduling, budgeting, and resource utilization. Bad estimates will undermineall those aspects of planning.

There are many good sources of information for estimates, including past experience that maybe gleaned from the files of previous projects, employees with different expertise, supervisors,consultants, and others.

Another great way of obtaining estimating information is searching the databases ofprofessional organizations. They retain valuable, historical data for their industries or areas ofinterest. With Internet access, this type of data has become much more widely available. It isalso a good idea not to rely on any one source, but rather to gather information from as many aspossible.

Estimating TechniquesThere are many methods, tools, and techniques available to assist with the development ofestimates, including three-point estimates and PERT. However, it is important to recognize that



bottom-up estimating based on the WBS will provide the most detailed and reliable results.

Examples of cost estimating techniques include the following:

Wideband Delphi: an idea-gathering technique that uses subject-matter experts to estimatethe project individually. The individual estimates are averaged, discussion incurs, and thesubject-matter experts will come up with a consensus on the estimate.Parametric: uses cost estimating relationships to express a mathematical relationshipbetween an items costs and some underlying physical, operational, or technicalcharacteristic.

– COCOMO 81 is based on the waterfall, top-down methodology. It relates level of effort inperson-months to project size in thousands of delivered source instructions. It has threelevels: basic, intermediate, and detailed. The basic level is often used to obtain a roughorder-of-magnitude estimate.

– COCOMO II is based on object-oriented methodologies and is computerized. It hasthree stages: application composition, early design, and post architecture. COCOMO IIrequires estimates of code size (lines of code, function points) and applies factors suchas application complexity, familiarity of organization and programmers with thetechnology and application, and level of expertise of programmers to produce an effortestimate.

PERT (Program Evaluation and Review Technique): an early diagramming methoddeveloped to mitigate risk in estimating schedules. Basically, PERT can be used to create a“weighted” average. Weighted averages tend to account slightly more for risk anduncertainty. One of the defining traits of PERT is that it is designed to provide four estimatesfor each activity for cost, time or resources: pessimistic (P), optimistic (O), most likely (ML),and expected (E). The expected time is derived through a simplified standard deviationcalculation based on the other three estimates.

Expected = (P + (4 x ML) + O)/6

You generate three estimates, usually from the lead person or team members doing a task.Suppose they think optimistically the task can be done in 10 weeks and, at the outside, in 18weeks. However, the most likely time will be 16 weeks. (Keep in mind that instead ofduration, these can be estimates of costs as well.) What is a reasonable duration forplanning? Using the formula, you get—

Expected = (10 weeks + (4 x 16 weeks) + 18 weeks)/6Expected = 15.3 weeks



Three-point estimate: a simple average of the optimistic (O), pessimistic (P), and most likely(ML), scenarios. It does not lend greater weight or credence to the most likely scenario,insteadit allows each of the possibilities equal influence, and thuspushes most analysis to later and later estimates. As such, this approach is limited to asingle, calculated value for duration rather than confidence levels as afforded by PERT. Theformula for the three-point schedule estimate is the following:

Expected = O+ML+P/3Historical: information on previous projects to develop estimates for a new project.

Schedule Planning

Schedule Planning Overview

Creating the schedule determines the time duration required to complete the project. It clarifiesthe relationships that exist among the various work packages and it helps project managers tomanage the time side of the triple constraint. In an actual project, the order of planningschedules, costs, and resources may vary depending on the nature and constraints of theproject. To some degree, these three types of planning are always done in concert with eachother because they are interdependent.

Four of the most commonly used scheduling tools and techniques available to project managersinclude, network diagrams, Gantt charts, project calendars, and milestone charts. Each of themcan be used for planning purposes, as well as to manage the execution of the work during thelife of a project.

Considerations for Estimating Activity Duration

Regardless of the scheduling technique being used, the durations of activities in the schedulemust be estimated. This is best done from the bottom up, especially for network schedules,which are defined by the activities, their logical dependencies, and their durations.

When estimating durations, it is important to understand precisely the type of durations beingdiscussed. Normally, estimates are converted from hours to days. For example, suppose adevelopment activity is estimated to take 48 hours. The time for the scheduled activity will be sixworkdays if an eight-hour workday is being used. If a Monday through Friday workweek is beingused, that workweek can be built into the schedule, and the total calendar days elapsed will beeight days.

Returning to the 48 hours of work time and the eight-hour workday, consideration should alwaysbe given to the resources assigned. For example, could two people perform the activity togetherin 24 hours and reduce its duration to three workdays? This sort of effect is much less likely inthe IT industry than it is in fields such as construction, where additional manpower or equipmentcan often speed performance.



Productivity and availability are other important resource concerns. If the developer assigned tothe activity is only allowed to work on the project half the time, it will take twice as long tocomplete the activity. Conversely, if one developer is twice as efficient as another, the activity’sduration must be estimated accordingly.

Network DiagrammingNetwork diagramming is a group of scheduling techniques that have several names and variousformats. However, the crucial trait they all share is that they expressly show the logicalrelationship between work packages or activities. Each technique does this by using somecombination of nodes (which may be circles, boxes, or other shapes) connected by arrows thatindicate the order of performance that activities must follow.

The first network scheduling method to be developed was PERT, which was created in the late1950s for the Navy’s Polaris ballistic missile program. In PERT, nodes are used to designate thestart and finish of activities, for instance, “Start testing guidance system” and “Finish testingguidance system.” This makes PERT an “event-oriented” system. The event nodes areconnected by arrows, which are by implication the activities being performed. PERT, therefore,predicts several possible durations for each activity and for the project as a whole. PERT wasintentionally designed this way to make it suitable for research and development projects wherethe time required to complete any particular work package is difficult to predict.

The critical path method (CPM) was also developed during the late 1950s for DuPont tomanage the construction of manufacturing facilities. Like PERT, CPM uses nodes to designatethe start and finish of activities and connects the nodes with arrows that represent the activitiesbeing performed. However, instead of naming the start and finish events, CPM names theactivities, such as “test guidance system.” CPM is, therefore, an “activity-on-arrow” system thatis “activity-oriented.” Unlike PERT, it was designed to use one estimate of each activity’sduration because construction activities can be (and typically must be) estimated with areasonable degree of accuracy. Because all network scheduling methods can be used toidentify the critical path in the schedule, this form of diagramming has over the years come to bereferred to as the “arrow diagramming method,” whereas CPM is often used to refer to networkdiagramming in general.

The most popular network diagram technique is the precedence diagramming method (PDM),which was developed during the 1960s. In PDM, activities are identified in boxes, andconnecting arrows represent the logical relationships between them. PDM is, therefore, an“activity-on-node” system that is “activity-oriented.” Like CPM, it assigns specific durations toeach activity. Because PDM has become, by far, the most popular network diagrammingtechnique, it will be the technique used in the remainder of this text.

Regardless of the specific technique, network diagramming is primarily a project managementtool to be used in managing the performance and sequencing of the work contained in the WBSwork packages. The activities of the work packages are used in the network schedule for theproject. The network schedule integrates this information by showing how relationships betweenactivities affect their sequencing and determine specific activity performance dates for the



project. These schedules are not typically shown to upper management and rarely to customersbecause they are better suited for use as working tools than as briefing aids.

Transforming a WBS into a Network DiagramTo create a network diagram for a project, you start with the work package level of the WBS.The work packages are broken down to their specific activities to use for the network diagram.These activities will become the network activities. The higher levels of the WBS are notscheduled because they comprise the work packages, and the work packages were determinedto be the WBS level at which work could be assigned and monitored most effectively.

Two characteristics must be identified for each network activity: the duration of the activity andthe activity’s logical relationship to other activities in the schedule.

The duration of an activity, which is determined through the estimating process, depends onfactors such as the nature of the activity and the resources available.

Determining logical relationships means identifying predecessor activities (that is, activities thatmust be performed before the activity in question) and successor activities (or those activitiesthat must be performed after the activity in question). Obviously, determining predecessors willdetermine successors and vice versa because stating that activity A is a predecessor to activityB is the same as saying activity B is a successor to activity A.

Two points should be noted about determining logical relationships. When predecessors areidentified for each activity, they should only be immediate predecessors. In other words, whenyou have a schedule sequence of activity A, which is followed by activity B, which is followed byactivity C, which is followed by activity D, you should identify activity D’s predecessor as activityC, not as activities A, B, and C. That would only create two unnecessary and redundant logicalrelationships.

Nevertheless, it is also important to understand that multiple predecessors or successors for agiven activity are possible and often exist. An example of that would be where activities A, B,and C all can be performed concurrently; the three activities have no logical relation to eachother; and all three must be performed before activity D. In that case, activity D would havethree predecessors, activities A, B, and C.

In certain situations, there are two special types of logical relationships that may be used: lagrelationships and lead relationships, or lag times and lead times. A lag is a forced amount oftime that serves a purpose but does not consume resources. For example, if you let a turkeycool before carving and serving it, you have set up a lag time. Resources are not beingconsumed, but time is passing. Lead time, the opposite of lag, is used when you need toaccelerate a logical relationship. For example, you need to wait for the turkey to cool, but in themeantime, you can get the salads on the table.

After building the network diagram a couple of questions come to mind:



How long will the project take?

How much could certain tasks slip?

What is the series of tasks (path) that determines the length of the project?

Forward PassUsing the critical path method, you can analyze the network diagram using three techniques:

Step Action Result

Forward Pass By path, start at the beginning, add alldurations together

Duration of project

Backward Pass By path, start at the end, subtract alldurations

Float

Path Analysis By path, review each path for least amountof float

Critical path

After you have listed all your project activities and determined their durations and logicalrelationships, you are ready to calculate the planned start and finish dates for the individualactivities (work packages) and for the project as a whole. This calculation is a process thatrequires two steps, known as the forward pass and the backward pass, respectively.

Consider the following simple set of activities:

Activity Predecessors Duration in workdays

A None (project start) 5

B A 15

C A 5

D A 10

E C and D 15

F B and E 5

G F 5



The following network diagram represents this set of activities in graphic format:

Calculating the forward pass on a network diagram will tell you the earliest time each activitycan start and finish and the overall duration of the project. It is the process of adding activitydurations from the first activity to the last.

For example, if we start with day 0 and label all times as the start of the workday, activity A willstart on day 0 and finish on day 5. Activities B, C, and D will each start on day 5, but addingtheir different durations to the five days used for activity A will result in different finish times foreach of them.

Activity B will finish on day 20 (5 + 15).

Activity C will finish on day 10 (5 + 5).

Activity D will finish on day 15 (5 + 10).

Activity E poses a different problem. Is its start time based on the finish of activity C or activityD? Keep in mind that one purpose of the forward pass is to determine the earliest time eachactivity can start and finish. Since both activity C and activity D must finish before activity E canstart, activity E’s earliest start time must be based on the predecessor activity that finishes later.Therefore, it is 15, based on the sum of the durations of activities A and D. This exampleillustrates the general rule for performing the forward pass through activities with multiplepredecessors. In such cases, you always add the activity’s duration to the finish of thepredecessor with the latest finish date.

Completing the forward pass for the complete set of activities leads to the results in thefollowing table. Note that the start time for activity F is based on the finish of activity E becauseit is later than the finish of activity B.



Activity Predecessors Duration inWorkdays

Start Finish

A None (projectstart)

5 0 5

B A 15 5 20

C A 5 5 10

D A 10 5 15

E C and D 15 15 30

F B and E 5 30 35

G F 5 35 40

Backward Pass

The next step in calculating a project schedule is to perform the backward pass. But why is anyfurther calculation necessary if the forward pass tells us when to start and finish each activity?Remember that the forward pass will tell you the earliest time each activity can start and finishand the overall duration of the project. As that statement implies, there are other times thatactivities can start and finish without affecting the overall project duration.

Using the current example, because activity F cannot start before day 30, activity B need not beperformed from day 5 through day 20. Its 15 days of work could be performed as late as day 15through day 30 without delaying the project. That type of flexibility in the project schedule is“float time” (sometimes called “slack time”) and it can be a valuable tool for the project manager.

Determining the available float time is one of the purposes of performing the backward pass.This can be done because the backward pass calculates the latest time that each activity canstart and finish without delaying the completion of the overall project. Dates generated byperforming the backward pass are therefore called “late start” and “late finish” dates.Conversely, dates generated by performing the forward pass are called “early start” and “earlyfinish” dates.

Mathematically speaking, float time can be defined as the difference between an activity’s earlyand late start dates or the difference between its early and late finish dates. Conceptuallyspeaking, it is the amount of time that an activity or chain of activities can be delayed withoutdelaying the project finish date.

Not surprisingly, the backward pass is a calculation that is the conceptual reverse of the forwardpass. The forward pass adds activity durations from the start of the first activity to the finish ofthe last, successor activity by successor activity. The backward pass depends on the forwardpass to determine the last activity’s finish time and then subtracts activity durations from thefinish of the last activity to the start of the first, predecessor activity by predecessor activity. Forexample, activity G will have a late finish of day 40 and a late start of day 35 (40 – 5). Activity Fwill have a late finish of day 35 and a late start of day 30 (35 – 5); and so on until you arrive at



activity A. At that point, you must subtract activity A’s 5-day duration from the late start date ofone of three different activities. Activities B, C, and D have different late start dates of 15, 10,and 5, respectively.

For this choice, remember that the backward pass determines the latest time each activity canstart and finish without delaying the project. Since activity A must finish before the late start dateof each of the three activities B, C, and D in order not to delay the project, activity A’s late startand finish times must be based on the successor activity that must start the earliest. Activity Amust therefore finish no later than day 5, based on the late start date of activity D, which wasdetermined using the durations of activities D through G. This example illustrates the generalrule for performing the backward pass through activities with multiple successors. In suchcases, you always subtract the activity’s duration from the late start of the successor with theearliest late start date.

Completing the backward pass for the entire network of activities leads to the results in thefollowing table where ES, EF, LS, and LF are used as abbreviations for early start, early finish,late start, and late finish, respectively.

Activity Predecessors Duration inWorkdays

ES EF LS LF Float Time

A None (project start) 5 0 5 0 5 0

B A 15 5 20 15 30 10

C A 5 5 10 10 15 5

D A 10 5 15 5 15 0

E C and D 15 15 30 15 30 0

F B and E 5 30 35 30 35 0

G F 5 35 40 35 40 0

In the example above, two activities have float time: Activity B has 10 days and activity C has 5days. Such float is not planned into projects, it is determined from the network diagram usingthe forward pass and backward pass. In the case of certain activities, however, there is no floattime. This leads to the next important concept in project scheduling using network diagrams: thecritical path.



Network Analysis

Analysis of a network reveals the duration of the project, the float, and the critical path. In anyschedule, activities must follow certain logical sequences. These sequences are defined by thedependencies in the schedule (for example, activity A must be completed before activity B canbegin). Because of the various dependencies, many paths or chains of activities can be tracedthrough the project schedule. The critical path is the longest chain of activities and, therefore,determines the minimum duration of the project. Activities on the critical path must happen ontime, or the project will likely be delayed (unless the time is recovered by performing successorcritical activities faster than planned or out of sequence).

Mathematically speaking, it can be called the chain of activities with the least float time (notnecessarily zero float). In this example, it flows through activities A, D, E, F, and G.

In some projects, backward passes are calculated based on fixed project completion datesrather than on the latest early finish date. This is usually because of contract provisions and canresult in the calculation of negative float times when the project is behind schedule or smallestfloat times, which are still greater than zero when the project is ahead of schedule. In suchcases, the critical path is more correctly referred to as the chain of activities with the leastamount of float time rather than the chain with zero float time.

It is possible for a project to have multiple critical paths. However, it is much more likely to haveone or more float paths that are nearly as long as the critical path. This type of path is called anear-critical path. When a near-critical path is very close to the critical path (that is, has minimalfloat time), it must also be managed very closely so that it does not become the critical path andinadvertently cause the project to be late.

The most important reason for identifying the project’s critical path through the use of networkdiagramming is to allow the project manager to manage by exception. By identifying those workpackages that must finish on time for the project to finish on time, the critical path also identifiesthe packages that deserve special attention from the project manager to ensure that they arekept on schedule. It also identifies work packages with very little float. This is just as importantbecause with very little slippage, they can also become critical.

Another key reason for the project manager to understand the project’s critical path is toimprove decisions about resource allocations. Knowing where to put your most dependablepeople may go a long way toward overcoming the potential delays to project completion that aremost likely to occur.

However, overemphasis on the critical path can be as much a mistake as ignoring it altogether.If the work that has float is ignored for too long, the float in those chains of activities willgradually be used up and they will become critical. Obviously, the more chains of critical andnear-critical activities there are, the more likely it is that the project will not finish on time. Inaddition, the critical path only addresses the issue of work packages critical to finishing theproject on time. Many packages not on the critical path are critical in terms of budget issues,customer satisfaction issues, scope management, and so on. Project managers must always



remember that the critical path includes only those activities critical to finishing the project ontime. The project manager must not think that only critical path packages are critical to theproject outcome or that all noncritical path work packages are not.

Displaying Schedule DataThere are many ways to display information from project schedules. The graphic and tabulardisplays used in applying the various network diagramming techniques provide severalapproaches. In addition, there are several methods that are easier to understand, especially forthose who are not experts in network diagramming methods. These include Gantt charts,project calendars, and project milestone listings. Although they won’t show all the logicalrelationships and other information characteristic of network diagrams, each of these simplerdisplays can be generated from an underlying network analysis.

Gantt ChartsGantt charts plot project activities or groups of activities as horizontal bars across a timescale.They show activity start dates (the left end of each bar), finish dates (the right end of each bar),and durations. This one chart shows the optimal plan, resources constrained schedule, andprogress on the project. They were first created by Henry L. Gantt in 1917 and are oftenreferred to as “bar charts” based on their format. With a network, you can determine float andcritical path. On a Gantt chart, you merely display when you want to do the various activities.The dependencies between activities are not effectively illustrated and can be hard to verify aswell as the ability to show two sets of dates or even resource assignments. Even with someweaknesses, the Gantt chart is one of the most familiar charts to many managers, and it is themost understandable for people lacking formal management training, thus useful for high-levelreporting and decisions.

There are some common conventions in the use of Gantt charts. Clear or open bars mayrepresent planned work, whereas closed or shaded bars represent completed work. A verticalline may be used to show the update date for displayed data. Activities reflecting progress to theleft of the line would be behind schedule. Activities reflecting progress to the right of the linewould be ahead of schedule.

Project CalendarsProject calendars are another technique to use for depicting the schedule. This way of viewingthe schedule is intended to focus on daily activity. Thus, it allows one to see the specifics of aparticular day’s work. Although they can show you what needs to happen on a certain day,project calendars don’t furnish you with the overview that a Gantt chart does. They provide thenarrowest view of the schedule. To the contrary, calendar views often identify who is to do thework.



Milestone Charts

Milestones are significant events in the completion of the project. They may be associated withthe completion of major activities, such as topping out the structure of a high-rise building orcompletion of prototype reviews for the development of a software application. They may berelated to other matters such as funding points or contractually imposed progress dates. In anyevent, they are not scheduled activities in the usual sense because they—

Have no duration

Consume no resources

Basically, they serve as reminders to check on overall project status at key points.

Project managers, of course, want to see that a milestone is accomplished, but milestonesserve a greater purpose as a way to check the overall status of the project. For example, youmay have met Milestone #2, but if you are already supposed to be halfway to Milestone #3 andyou’re nowhere close, the overall schedule may be of concern. And by the way, how is yourbudget?

To effectively use milestones to check on your project’s status during the Planning phase, youneed to put the milestones into your WBS dictionary with specific expectations at those points.For example, Milestone: completion of component X. Check—

Is it done by the planned July 5 date? Did you spend the planned $50K?

Is the parallel work on component Y on track?

Is the installation team ready to begin putting X into the system as planned?

Estimating Cost and Determining the Budget

Estimating Cost and Determining the Budget Overview

Having planned the schedule, the project manager must turn to a second major planningprocess and deal with project cost; such as estimating cost and determining the budget.Although it may initially be approached from a very high-level view, good cost planning shouldeventually address cost issues at the work package level. This means planning all costsassociated with completing the individual work packages, as well as costs for overhead,contingency reserves, and other indirect expenditure.

Estimating Cost Inputs

What sort of information should you consider in estimating costs? The PMBOK® Guide, pp.167–174, lists the following inputs to cost estimating:



Enterprise environmental factors (culture, market condition, software tools)

Organizational process assets (guidelines, processes, procedures)

Scope baseline

– WBS– WBS dictionary

Project schedule

Resource plan

Risk register

Who can the project manager consult with in an effort to obtain cost information? There are avariety of sources. They include outside estimators, those who perform the work, those withexperience working on similar projects, those who know the risks of the project in question, andthose who are responsible for the work.

Types of Cost EstimatesThe major types of cost estimates vary depending on when they are done, why they are done,and how accurate they are. They include order-of-magnitude estimates, budgetary estimates,and definitive estimates.

The rough order-of-magnitude estimate is developed very early in the project, usually in theconcept stage. It is often done to help make project selection decisions. Its accuracy is typically+75 percent to -25 percent, meaning that the project’s actual costs could be 25 percent below or75 percent above the estimate. Ideally, this sort of estimate is not developed until afterrequirements have been identified; however, in reality it is often developed before then, whichcan be dangerous and explains why estimates can grow dramatically from the first estimate tothe second.

Budgetary estimating is usually done when the high-level design is completed, which is still fairlyearly in the project life cycle. The accuracy of the estimate is between +25 percent and -10percent.

A definitive estimate is usually developed after the detailed design has been completed. Itshould provide the most accurate estimate of project costs (within a range of +10 percent and -5percent).



Cost Components

Good cost planning requires a basic understanding of how organizations account for cost,including how they categorize various cost components. The most fundamental distinction isbetween direct and indirect costs.

Direct costs are costs directly attributed to the project.

Indirect costs are costs for organizational support not directly attributed to the project, suchas office electricity and heating.

Direct project costs typically include the cost of labor, materials, and equipment that are used incompleting the project. Labor includes both the cost of the organization’s own employees andthe cost of contract labor. Other direct costs include expenses for items such as fees, travel,and incidentals.

Indirect costs are also referred to as overhead. They will be incurred regardless of whether aparticular project is undertaken or not. Nevertheless, these costs must be allocated among all ofan organization’s initiatives (including the projects it undertakes) using some rational formula,and they must be offset by sufficient revenue if the organization is to remain solvent. Typically,they include general and administrative (G&A) expenses such as home office headquartersexpenses, fringe benefits, and depreciation. Marketing, sales, and research and developmentare other common indirect expenses.

The project manager must always ensure that appropriate costs from all categories are includedin cost planning. Indirect costs are often miss-estimated or overlooked completely, but they arereal, and they must be accounted for.

Cumulative Cost Curve

Cumulative cost curves like the one below can be used to graphically depict the total plannedproject expenditures (the budget) over time, based on the schedule and cost planning that hasbeen accomplished using the WBS. Time periods are measured along the X-axis andcumulative costs expended at any particular time are measured along the Y-axis. A line graph isplotted by connecting the cumulative cost points of the project during each time period over theentire duration of the project. Since plotting project costs by time period in a noncumulativefashion usually produces a bell curve with higher expenditures during the middle of the projectand lower expenditures at the beginning and end, the cumulative cost curve usually takes theshape of a somewhat flattened “S.”

During project execution, these graphs can be used in conjunction with earned-value analysis(which will be addressed in the next module) and can thereby show the project manager howmuch money has been spent at a certain point in time compared to what was budgeted.



Cumulative Cost Curve and Precedence Diagram

Cumulative cost curves are useful briefing tools because most people can easily read the graph.It can also serve as an excellent way of summarizing progress, since both planned and actualcost curves can be tracked on the same graph for comparison purposes. However, the projectmanager must be careful to ensure that people do not misinterpret the cumulative curve due tolack of understanding of the underlying details. For example, when actual costs are plottedagainst planned costs, they may see variances between the two curves and yet not understandthe actual events that underlie them. For example, if an unexpected opportunity arises to makea major purchase ahead of schedule in order to get a significant discount, it will look like anoverspend, when in actuality the project is saving money.

In addition, although they are cost curves, they cannot be understood as a way to evaluatecosts in isolation from the other two factors of the triple constraint, the project status in relationto scope and schedule. If more money has been spent than budgeted, but the project is furtheralong, then that can be a good thing! On the other hand, you might have spent less than youplanned by a certain point in time but still be woefully behind in your deliverables.



Resource Planning

Resource Planning Overview

In conjunction with planning the time and costs, the project manager must plan the resourcesthat will be required to complete the project. The resources required for any project includepersonnel, equipment, and facilities. You can plan for the office space, sufficient people, and themost up-to-date technology; or you can get stuck with what is offered you. Which would youprefer?

Senior management and your core project team play a particularly significant role in resourceplanning. In many organizations, senior management must go to other divisions of the companyon your behalf to help you enlist resources. If you need to use an outside contractor to performpart of the project, your organization’s contracting officer will play an important role in yourproject. Moreover, the core project team, through its own contacts and experience, is often yourbest route to the optimum resources.

One key group of individuals that you will need to get to know well is the functional managers(resource managers). These are the people who head the various groups of resources aroundyour organization (for example, the software development manager for programmers, the officeadministrator for clerical help, the facilities manager for office space, and so on). Regardless ofwhether you work with them directly or with the help of senior management, it is ultimatelythrough them that you obtain the resources you need to get the job done. A good relationshipwith functional managers can make project management life much easier.

Although all resources are important, in the final analysis, the people who work on the projectusually will make it succeed or fail. As a project manager, you need to get the best people youcan and plan how to use them most effectively. To do this, resource planning should identify theskills needed for the project and when they are needed. For example, in many cases a projectwon’t need a testing expert throughout the life of the project but only at certain times.

Resource Planning Tools and Techniques

There are tools and techniques that are specifically designed to help you address resourceplanning issues. Examples of these tools and techniques include—

Roles and responsibilities matrix

Resource Gantt chart

Resource loading table

Resource loading histogram

Resource leveling



Roles and Responsibilities Matrix

A resource/responsibility matrix, also referred to as a roles and responsibilities matrix, is anuncomplicated way of showing which “resource” (person) is responsible for each task or groupof tasks. It is simply a grid with people identified along one axis and tasks along the other. Eachperson’s role in relation to a particular task may then be highlighted as in the following example.Assigning levels of responsibilities for each type of task, as opposed to just checking them off,also can be helpful in planning and managing your resource requirements. For example, thePMBOK® Guide, p. 221, commonly uses the RACI matrix (R = Responsible, A = Accountable, C= Consult, and I = Inform). You can use any coding that works best for you and yourorganization.

Roles and Responsibilities

Tasks Donna(role)

Duane(role)

Gina(role)

Jane(role)

Jerome(role)

Mark(role)

Pat(role)

Paul(role)

Projectmanagement

R I C A

Requirements A C R I

Softwaredevelopment

A C

Mainframeconsulting

I A R

Client/serverdevelopment

A R

Infrastructure R C A

R= ResponsibleA = Accountable/ApproveC = ConsultedI = Informed

A good matrix serves several purposes. It aids your thought process in viewing what resourcesand what level of expertise are needed for the project. It shows you where critical holes exist.When staffing changes during the project, it becomes the starting point for reassigning dutieswith the new people because it depicts the duties left open by the departed individual. What itdoes not show, of course, is the interaction of resources with cost and schedule.

Resource Gantt Chart

A resource Gantt chart is a bar chart that groups activities according to the resources requiredto perform them. Normally, the Gantt chart is a cascade of activities in chronological order bystart date. In this case, the activities are first grouped by their assigned resources, then bychronological order within these groupings. While project managers use Gantt charts to allocate



resources on a specific project, functional managers use Gantt charts to track the availability oftheir employees and to determine staffing possibilities for upcoming projects.

Resource Loading Table

A resource loading table illustrates how many resources are needed and when they are needed.The project manager uses a resource loading table to calculate the total resource requirementsduring each time period (usually weeks) and for the entire project. Once the resource loadingtable is finalized, it can be used to create the resource loading histogram.

Resource Loading Histogram

A resource loading histogram is a vertical bar chart showing the planned allocation of people bytime period. Time periods are measured along the X-axis and quantities of resources aremeasured along the Y-axis. The amount of resources to be used according to the projectschedule during any given time period is depicted by a vertical bar, and the taller the bar, thegreater the amount of resources. Normally, the resources assigned are personnel, but this toolcan also be used for planning equipment used on an appropriate project, such as a highwayproject requiring many pieces of heavy construction equipment. The end result is a vertical barchart that shows resource allocation over the life of the project.

Each vertical bar represents the quantity of resources required for each time period based onsome standard unit (for instance, each work day). The quantities are calculated based on theresource requirements, together with start and finish dates that have been developed for eachwork package. This tool clearly shows when your schedule demands high levels of resourcesand when the numbers drop off. For the same reason, the tool can give you a sense of whenyou may be managing the most and giving the project your closest attention. It can also alertyou to potential problems. For example, what if you only have 13 people available to you butneed 25 people on some days? In that case, you either need to get more resources or adjustthe schedule!

Resource Leveling

Resource leveling is the technique that addresses the kinds of scheduling and resourceadjustments just mentioned. The PMBOK® Guide, p. 446, defines resource leveling broadly as“any form of schedule network analysis in which scheduling decisions (start and finish dates)are driven by resource constraints (for example, limited resource availability or difficult-to-manage changes in resource availability levels).”

With limited resource availability, the problem is that you simply do not have enough bodies todo all the activities on their scheduled performance dates. With difficult-to-manage changes inresource levels, you are trying to avoid the inefficiencies and resulting cost increases associatedwith wide, day-to-day swings in the number of resources involved in the work.

Resource leveling may be accomplished without extending the project schedule in some cases.Taking advantage of float time can do this. Limited resources may be scheduled in a way thatapplies them to the activities with the least float first. As long as critical activities are not affected



and the float remaining in the other activities is not entirely used up by delaying theirperformance, the overall completion date need not be delayed because of scarce resources.

Risk Planning

Risk Planning Overview

“Plan risk management” is the process of deciding how to approach and plan the riskmanagement activities for a project. Planning for risk is an integral part of planning on projects.

Risk Identification

A risk, according to the PMBOK® Guide, p. 446, is “An uncertain event or condition that, if itoccurs, has a positive or negative effect on a project’s objectives.” Identifying and analyzingrisks takes place throughout the life of the project: They are factors in project selection, asdiscussed previously; they become part of project planning, and they are ongoing parts inproject execution and control.

Risk is a definable event that can be assessed in terms of probability and impact. It may be athreat (negative event) or an opportunity (positive event). Both the timing and frequency of riskshould be considered.

As you plan, you are not necessarily planning for the very worst possible scenario, but you don’twant to ignore some of the bad things that might happen (such as delayed permits, procurementdelays, bad weather, loss of key team members, equipment failure, and so on).

Threat Opportunity

And don’t forget good risks! You want to be in a position to capitalize on a good event orcondition. Events such as a quicker-than-usual permitting process or the sudden availability ofyour company’s best engineering whiz can boost your project performance if you are preparedto take advantage of them. If you plan for some good risks, you will look good when youcapitalize on them. However, unlike the bad risks, the good ones tend to go away quickly if theyare not seized or acted upon. The PMBOK® Guide, pp. 303–305, elaborates on ways tominimize bad risks (threats) and minimize good risks (opportunity).



Risk Probability and ImpactThere are two key questions to analyze for each risk you identify:

1. What is the probability of the risk actually happening?2. What would be the impact of the risk on the project if it did happen?

Based on an assessment of the probability and effect of each identified risk, the project teamshould prioritize the risks. Prioritization is an essential step because you are not likely to havethe resources to prepare for everything and because some potential events are too low inpriority to be worth planning for.

Risk probability may be quantified mathematically by determining that there is a certain percentlikelihood of a particular event occurring. Or, if there is no rational basis for percentageestimates, you can take a broader conceptual approach and label risks as having high, medium,or low degrees of probability.

The same range of approaches may be used in determining risk effect. Where possible, aspecific cost estimate should be assigned to each risk. When that approach is not possible,risks may be labeled as having a high, medium, or low degree of effect.

Prioritization of risks will determine which ones are worth planning for and which are not, and itshould be the product of probability and effect estimates. If you have been able to quantify theprobabilities and effects of risks in percentage and cost terms, then you should be moreinterested in a $50,000 risk with a 50 percent probability than you would be in a $100,000 riskwith a 10 percent probability because the former is worth $25,000 and the latter is worth$10,000. If you cannot quantify probabilities and effects in mathematical terms, you should givetop priority to high-probability risks with high-potential effects. You should give less priority torisks with a combination of high and low probability and effect. Therefore, you should not wasteyour time planning for risks that have a low probability and low effect.

Risk Management Planning“Plan risk management” is that part of project management that deals with the processes ofidentifying, quantifying, responding to, and controlling the risks inherent in a project. In otherwords, there is a fundamental difference between risk management and project management.Project management is the process that gets us to an objective; risk management is an enablerto that process. Risk management considers issues that could possibly affect that process as itunfolds; project management looks at the process itself. Risk management looks at how we canavoid problems; project management looks at how we get beyond problems. It is a very simple,fundamental difference. When it comes to risk management, we are looking at the reality of day-to-day life and how we can have an impact on those things that might stop us from getting to ourobjective.



ESI’s Risk Management Model

Both PMI® and ESI International have developed risk management models. ESI’s eight-stepmodel is based on practical experience and best practices that go beyond the information in thePMBOK® Guide. The eight steps are listed in order below with the corresponding processesfrom the PMBOK® Guide.

The PMBOK® Guide model defines the following six processes:

Plan risk management – “The process of defining how to conduct risk management activitiesfor a project” (PMBOK® Guide, p. 440)Identify risk – “The process of determining which risks might affect the project anddocumenting their characteristics” (PMBOK® Guide, p. 436)Perform qualitative risk analysis – “The process of prioritizing risks for further analysis oraction by assessing and combining their probability of occurrence and impact” (PMBOK®

Guide, p. 440)Perform quantitative risk analysis – “The process of numerically analyzing the effect ofidentified risks on overall project objectives” (PMBOK® Guide, p. 440)



Plan risk response – “The process of developing options and actions to enhanceopportunities and to reduce threats to project objectives” (PMBOK® Guide, p. 440)Monitor and control risks – “The process of implementing risk response plans, trackingidentified risks, monitoring residual risks, identifying new risks, and evaluating the riskprocess throughout the project” (PMBOK® Guide, p. 438)

Risk Response StrategiesAfter you have identified the risks that are worth planning for, you have to decide what you aregoing to do about each of them. Both threats and opportunities require response strategies. Thefollowing applies to negative risks or threats (PMBOK® Guide, pp. 303–304):

Accept—After thorough analysis of the other ways to respond to a risk, you may reach theconclusion that not changing the project plan is the most sensible approach of all becauseany other response has costs that exceed its benefits or because the risk is an unavoidablecost of doing business. Acceptance of a risk should include consideration of a back-up planor contingency plan, including the use of a management reserve in either the budget and/orthe schedule to accommodate the risk event if it actually occurs.Mitigate—Risk mitigation means reducing the probability or consequences of a threat to anacceptable threshold. For example, to avoid the risk of producing an unacceptable product,you might decide to build in more testing of a new piece of software before you release it orbuild in four safety latches instead of three on a secure container. Basically, it is the belt-and-suspenders approach.Transfer—Transference means shifting the threat to a third party. There are many examplesof this sort of approach being applied through contract provisions with third parties that areinvolved in projects. Insurance coverage requirements or “hold harmless” clauses shiftthreats of physical or personal harm. Clauses prohibiting or liquidating damages for delayedcompletion transfer threats of project delays. Even compensation terms involve the transferof threats because a fixed-price contract makes the contractor suffer the consequences ofcost overruns and lets the contractor accrue the benefits of cost savings, whereas a cost-plus-percent-fee contract allocates those potential threats and rewards to the purchaser.Avoid—This strategy requires changing the project plan to eliminate the threat or conditionor to protect the project objectives. This may entail eliminating nonessential aspects of theproject scope that put the entire project in jeopardy. For example, if several vendors offer akey project component and the preferred vendor is financially unsound, you may choose touse a less attractive product from a more reliable source to avoid the threat of vendorbankruptcy and nonperformance.



Like negative risks or threats, positive risks or opportunities must be planned for. The followingare the responses to opportunities (PMBOK® Guide, pp. 304–305):

Accept—Is the same as for threat. Acceptance of an opportunity should include the use of amanagement reserve in either the budget and/or the schedule to seize the opportunity if itoccurs.Enhance—Like mitigate on the previous page, enhancing modifies the size of theopportunity. That is, you can increase the probability and/or the impact by identifying andmaximizing the key drivers. For example, to enhance the opportunity of producing a superiorproduct, you might decide to build in more testing of a new piece of software. In this way,you increase the probability of increasing business and reducing reworks.Exploit—Like avoid on the previous page, exploiting helps to ensure that an opportunity isrealized by attempting to eliminate the uncertainty associated with that opportunity. Forexample, if several vendors offer a key project component and the preferred vendor is oneyou would like to establish a sound relationship with or create business with, you maychoose to use that product. This would help to ensure future business.Share—Like transfer on the previous page, sharing allocates some or part of the ownershipto a third party who is most capable of capturing the opportunity. Sharing of the ownership ofintellectual property between the expert organization and your organization may help tocapture a business opportunity and establish an ongoing relationship.

To sum up, identify and analyze risks and put together a risk management plan as part of yourproject planning. Keep reviewing your risks, their priorities, and your response strategies duringthe course of the project because they can change over time.

Procurement Planning

Procurement Planning OverviewProject managers are called on much more often to procure goods, services, and labor for theirprojects from outside vendors and contractors. Because procurement and its legal ramificationscan be complex, it is best to work with professionals within your organizations to be sure that itis performed properly. However, knowing the fundamentals of procurement will help you makegood procurement decisions that can be implemented correctly with the assistance of yourorganization’s procurement professionals.

Make-or-Buy DecisionBefore the project manager undertakes procurement related to any project component, afundamental question must be answered. The question is whether to use an outside vendor orcontractor to perform the work or provide the materials or equipment instead of accomplishingthe same thing entirely with internal resources. This is the so-called “make-or-buy” decision.

Sometimes entire projects can be done without any significant outside help. One example would



be developing a new chemical compound in a laboratory that the organization owns usingchemists and lab technicians who are employees. Another would be studying and modifyingexisting business processes using a team of employees without incorporating any newtechnology or equipment. However, the larger and more complex a project is, the less likely it isthat no procurement will be involved.

Several factors can be considered in making the make-or-buy decision:

Does your organization have the capability or expertise necessary for a successful result?

Does your organization want to share the risk with another organization?

Who can do it faster, cheaper, or better—your employees or a contractor?

Does your organization want to undertake the ongoing expense of hiring full-time staff for adiscrete, short-term effort?

Contract Type Selection

If the decision is to buy the solution from outside the organization, an appropriate type ofcontract pricing should be used. There are three broad categories of contracts from which tochoose. They include fixed-price or lump-sum contracts, cost-reimbursable contracts, and time-and-materials contracts.

Fixed-price contracts are also known as lump-sum contracts. They require the buyer to pay afixed total price for a well-defined product. For example, a school may award a fixed-pricecontract to a company for the purchase of 200 desktop computers with specific operatingsystems, processors, and amounts of memory, all to be delivered by a certain date. This type ofcontract puts the risk of efficient and proper performance on the seller. To the extent that theproduct is not well-defined, both the buyer and seller are at risk when using a fixed-pricecontract. On the one hand, the buyer may not receive the desired product. On the other hand,the seller may incur additional costs to provide it, inflate the estimate, or file a claim against thebuyer to ensure such costs are covered.

Cost-reimbursable contracts require the buyer to reimburse the seller’s actual costs plus a feerepresenting the seller’s profit or overhead and profit. Costs are usually classified as direct costsor indirect costs. Direct costs are costs incurred for the exclusive benefit of the project (forexample, materials or salaries of full-time project staff). Indirect costs, also called overheadcosts, are costs allocated to the project by the performing organization as a cost of doingbusiness (for example, salaries of corporate executives). Indirect costs are usually calculated asa percentage of direct costs. The risk of inefficient performance and cost overruns falls on thebuyer with cost-reimbursable contracts. The risks are particularly high for the buyer if the fee isdefined as a percentage of cost without any maximum total payment since the more inefficientthe seller, the more the buyer will pay.

Time-and-materials (T&M) contracts are hybrid contractual arrangements that contain aspectsof both cost-reimbursable and fixed-price agreements. They resemble cost-reimbursableagreements because they are open-ended and the full value of the arrangement is not definedat the time of the award. Thus, T&M contracts can grow in contract value as if they were cost-reimbursable contracts. Conversely, T&M agreements also resemble fixed-price agreements in



terms of the hourly rates that the parties agree to for the seller’s personnel. Since the seller isunlikely to miscalculate this component of the unit price for labor, T&M contracts typically placeperformance risks on the buyer as a practical matter just as cost-reimbursable contracts do.

In some cases, the contract type may be decided after the vendor has been selected. Thiswould only be the case when the buyer chooses the seller through some sort of a negotiatedprocurement such as a request for proposal, not when the buyer solicits offers for competitivebids with the promise of award to the responsible and responsive bidder offering the lowestfixed price.

For example, an organization may have worked with a particular vendor on previous occasionsand based on the prior relationship, may decide to use a certain type of contract after decidingto use that vendor.

Preparing Procurement Documents

When the project team decides to purchase the product or system solution, solicitation planningactivities are performed under the oversight of the project manager to support the solicitation ofbids and proposals from prospective sellers on how best to provide the solution. Duringsolicitation planning, procurement documents are prepared and seller evaluation criteria aredetermined. Together they are used for the solicitation and selection of bids and proposals fromprospective sellers (contractors).

The terms bid and quotation are generally used when the source selection decision will bebased on price (as when buying commercial or standard items), while the term proposal isgenerally used when other considerations, such as technical skills, technical services, andtechnical approach are paramount. Common names for different types of procurementdocuments include Invitation for Bid (IFB), Request for Proposal (RFP), Request for Quotation(RFQ), Request for Information (RFI), Invitation for Negotiation, and Contractor Initial Response.

Evaluation criteria are used to rate or score proposals. They may be objective (for example,“The proposed project manager must be a certified Project Management Professional, PMP®”)or subjective (for example, “The proposed project manager must have documented, previousexperience with similar projects”). Evaluation criteria are often included as part of theprocurement documents so that the sellers will understand how the contract award will bedetermined.

Statement of Work

Contracts typically include a statement of work (SOW). The SOW is essentially the contractualversion of the project requirements and it typically covers the following subjects:

The work to be performed, including the hardware and software to be used

The location of where the work will be performed

The schedule

Specific deliverables and their descriptions and due dates



Standards with which must be complied

Acceptance criteria

Developing good (SMART) requirements for the SOW is a must. It is the project manager andcore team’s responsibility to provide a clear description of requirements and measures ofsuccess in the SOW.

Failure to do so can lead to a failed project, contract disputes, and even litigation.

Selecting the ContractorWhen you do decide to hire a vendor or contractor, you have numerous issues to address. Oneof the first is the source selection process. You must determine the evaluation criteria that youwill use to select the vendor or contractor. Some general considerations include cost, reliability,and timeliness. If you are procuring materials, you will be interested in factors such asappropriate quality and certain availability when you need them. If you are procuring services,you will want a contractor who will staff the project with people who have the proper expertiseand experience for the job, as well as an excellent reputation.

Another aspect of source selection that you must address is what procurement documents willbe used. Will you be creating them from scratch, or will standardized procurement documentsbe used, and if so, what are they and where do you get them? Will you be publishing anadvertisement for lump sum bids in industry publications, or will you be sending a request fortechnical and price proposals to a short list of prequalified contractors? What type of contractwill be used? Will it be fixed price, cost reimbursement, or some hybrid of those two formats?Will it contain incentives, and if so, how should they be structured?

There are other considerations related to procurement that go beyond the source selectionprocess. For example, what responsibilities does the project manager have in procurement andsolicitation? How will multiple contractors be managed? Will there be one prime contractor whomanages many subcontractors, or will there be many prime contractors that the sponsoringorganization’s project manager manages directly? And how will procurement be coordinatedwith the rest of the project?

Finally, different organizations have different approaches to dealing with procurement, from avery formal and centralized process in which a contracting office plays a key role to one in whichthe project manager has complete discretion. Make sure you understand how your organizationhandles procurement before you make commitments that you cannot meet.



Communication Planning

Communication Planning

Many stakeholders, including the project team, will need different kinds of information about theproject. The issue in communication planning is how information will flow during the project. Themore visible the project is, the larger the communication task will be, but every project hasvarious target audiences.

The first question should be who receives what types of information, or who needs to knowwhat. For example, detailed information like the WBS, project schedule, and cost plan brokendown to the work package level may be provided to all project team members for the entireproject scope or for those portions of the work in which each member is involved. Seniormanagement may only want high-level cost reporting with milestone schedule updates.

The questions to address next are how you will share the information, when, and how often. Willyou have group meetings? If so, will they be daily, weekly, or biweekly? Will you create group e-mail addresses, a project Web site, or a section on your company’s intranet?

Finally, for purposes of tracking actual events and lessons learned, what will become of theproject record and how will you store it? Will you keep hard copies of paper in file cabinets ormaintain an electronic archive? And finally, how will people be able to access the informationafter the project has been completed?

Quality Planning

Quality Planning

Quality often gets lost in the push of deadlines and budget cuts. This is a function of the projectconstraints. If you try to produce something in less time with fewer resources than would becalled for by a reasonable baseline plan, the scope of the project will be reduced either in termsof the quantity or quality of the project deliverables.

You can best avoid this result by emphasizing quality during project planning and buildingquality control and quality assurance processes into the project costs and schedule from thebeginning. In other words, quality should be planned into a project, not inspected into it.Catching and correcting defects long after they occur is much more costly than fixing thempromptly or avoiding them altogether. This is true for any kind of project.

When all is said and done, only the customer can really evaluate the quality of your project



result. The customer will do that whether you like it or not, and that will be a key barometer ofyour project’s success. As a project manager, you must accept this and plan for it.

The Project Management Plan

From Planning to Implementation: The Project Management Plan

The culmination of all this planning and the various component plans is the project plan. Theproject plan provides the road map for the Implementation phase of the project. In essence, itsummarizes all the planning you have already done:

Now it is a question of putting them all together and making sure everything is coordinated. Youshould not have a schedule that requires more personnel or equipment than you have available.You should not have a cost plan that assumes a labor rate of $20 per hour when your humanresource planning calls for personnel who make $30 per hour. Without a well-coordinatedproject plan, your project probably will fail; with it, you will have a reasonable chance of success.

Project Management Planning Software

Nowadays, there are many software tools that can help you perform as a project manager. Theimportant thing to remember is that they do not take the place of using your head and yourtalents!

The first class of software is the most widely used and is often not thought of as projectmanagement software. It is office management software, which includes database,spreadsheet, and word processing applications. All of these can be used to great advantage inmanaging projects.

The second class of software is a newer family of programs specifically designed to help withmanaging projects. They are designed with scheduling, risk, quality, decision support, or any



other aspect of project management in mind. Although they speed up many time-consumingtasks, you should not rely on them without understanding the concepts that underlie them.Otherwise, you will be like an infant playing with a calculator. Numbers will be keyed in andcalculations will be made, but they will not do anyone any good. In short, these tools can bevery helpful, but you must know how to use them and know how to interpret their output.

Project Baselines

Project Baselines Overview

The project baseline is the original project plan, adjusted for approved changes. The overallproject plan actually consists of three baselines that reflect the three aspects of the tripleconstraint. There are cost performance , schedule, and scope baselines, and the performanceof both the project manager and the project itself will be judged against all three. A baselineshould be detailed enough to serve as a measuring device that will answer the question, “Is theproject where it needs to be?”

Organizations have different ways of requiring baselines to be captured and presented. This isnot a major issue, though, because most of the work of setting up the baselines has alreadybeen done in project planning. Some of the typical baselines include the following planningoutputs:

Scope: scope statement, WBS

Cost performance: cumulative cost curve, project budget

Schedule: network diagram, Gantt chart

During the Execution phase, the project manager uses the baseline information alreadygenerated to measure and control the performance of the project team. In doing so, it isimportant not to give one baseline undue precedence over the others. For example, too muchemphasis on time may drive up costs, whereas too much emphasis on cost control maylengthen the schedule. The project manager can make smart decisions based on the complexityof the project only when the compound effect on the multiple baseline references is considered.

Who Needs Baselines?

Project baselines are useful to many different people in many different ways, which reflect theirvarious concerns and functions. The customer’s primary role is to approve the overall limits ofscope, time, and cost requirements. The customer’s involvement in scope requirements mayvary from a fairly general participation in the development of a functional requirement to closerparticipation in the development of a detailed set of plans and specifications. Quality will be amajor customer concern in almost every case.

Management’s role is normally to review progress against baseline requirements and, ifnecessary, to resolve conflicts and issues between the project manager and the customer. Cost



and schedule will be key concerns for senior management. They will be assisted by theaccounting department in this function, particularly in regard to monitoring project costs.

The role of the project manager is always to perform by integrating the customer’s wishes into aworkable set of baselines and seeing that they are carried out. The project team’s role is also toperform, and like the project manager, team members must be concerned with all baselines.The project manager must communicate to the team and other stakeholders that the projectperformance is judged against the baselines. Project performance does not change thebaselines; rather, the baselines help project managers to understand the variations so they canmake necessary project changes.

Module Summary

Module SummaryThe core project team is involved in project planning.Understanding the scope is key to project planning.A work breakdown structure (WBS) is a deliverable-oriented method of breaking down thescope of a project to facilitate planning for its completion.Although a WBS may have different formats, levels of detail, and ways of being created, thework package is always the bottommost level.Work packages break down into activities. It is these activities that are used to build thenetwork diagram that leads to the project schedule.A WBS dictionary provides important working-level information about certain work package.Schedule planning determines the timing of performance of the project and its componentwork packages, including critical path and float times, and it may be presented in manyformats.Cost planning determines the direct costs that the work packages require, as well as theindirect costs (overhead) allocated to the project.Resource planning covers people, materials, facilities, and other resources.Risks (both opportunities and threats) must be identified, analyzed, prioritized, and plannedfor through the appropriate response strategy.Procurement planning involves deciding whether to procure outside services and how tochoose which outside entity to use.Communication and quality round out the project manager’s planning processes.All these processes come together in the project management plan.Stakeholders measure how the project is doing against scope, time, cost, and otherbaselines.



Module 4Project Implementation

Introduction

Module OverviewTwo processes, executing and monitoring and controlling, together make up the Implementationphase of the project life cycle. To put it simply, this is the “doing” part of the project. However,the project manager’s major role is not doing the project; it is managing projects so that theteam can and will do the actual work in a successful manner.

Project Implementation

Executing and Monitoring and ControllingProject Implementation is the third phase of the generic project life cycle. This is where the bulkof the work for the project takes place. During Implementation, the project team develops thesolution while the project manager coordinates team members, forecasts future trends, looks forpotential risk, and monitors and measures team and project performance. The project manageris also responsible for managing stakeholder expectations and dealing with changes and riskevents.

Major deliverables that result from the Implementation phase typically include the product orservice but may also include project and team performance appraisals, status reports, andchange management forms.

As a project manager, during the Implementation phase you will find you will use predominantlyexecuting and monitoring and controlling, two of the five PMBOK® Guide process groups, at thesame time.

To perform these functions properly, you will need to be able to use a variety of projectmanagement skills. They will include interpreting project baselines, aligning project teamperformance with stakeholder expectations, responding to requested changes and risks as theyoccur, assessing project performance, applying earned value management to determine projectperformance and future trends in performance, and completing and presenting performancereports.

Module 4: Project Implementation


Assessing Project Performance

Assessing Project Performance Overview

Assessing performance is critical to project success and should be performed throughout theConstruction phase in two general ways. First, the project team should continuously monitoractual performance by comparing it to scope, time, and cost baselines developed during thePlanning phase, and should adjust the project plans throughout performance as necessary tocope with actual results that vary from the plan. Second, senior management and customersshould periodically evaluate planned versus actual project status and require the team to makeadjustments when necessary to assure satisfactory results. A key tool for assessingperformance is the concept of earned value management.

Monitoring Project Performance

Monitoring project performance is a three-step process:

1. Compare actual results against baselines for cost, time, and scope.2. Identify any variance between the three.3. React as necessary. If there is no significant variance, your reaction will be to continue

pursuing the project plan.

Earned Value Management (EVM)

A key tool for monitoring project performance is earned value management (EVM) analysis.Numbers will never tell you everything, but earned value provides you with an objective,mathematical approach to viewing just a few numbers that correlate a variety of projectbaselines. Earned value management is not the only monitoring tool; there are many others, butthey generally focus on single aspects of the project. Earned value management is the only toolthat effectively pulls all three main sides of the triple constraint into a single monitoring formula.It does this by correlating three pieces of data—planned work, actual cost, and value of the workdone—to assess how the project is performing.

The following definitions and abbreviations are further explained in the PMBOK® Guide, p. 182

Planned value (PV): What is the budgeted cost of the work scheduled (or planned) as of today?See the Gantt chart and budget for this. A $500 work package that was scheduled to be 50percent complete today has a planned value of $250 (.50 x $500).

Actual cost (AC): What is the actual amount spent as of today? Think bills rather than payments;once the money is committed it is spent.



Earned value (EV): What is the completed work worth or what has your effort earned as of now?It is measured in terms of the budgeted cost of the work packages accomplished to date. A$500 work package that is actually 60 percent complete as of today has an earned value of$300 (.60 x $500).

Note: The old acronyms are still turning up in organizations, textbooks, and databases. Plannedvalue (PV) was known as BCWS (budgeted cost of work scheduled), actual cost (AC) wasknown as ACWP (actual cost of work performed), and earned value (EV) was known as BCWP(budgeted cost of work performed).

All three of these quantities are depicted on the following chart (PMBOK® Guide, p. 183). Noticethat the PV curve is actually a cumulative cost curve, which was one of the outputs of the costplanning process discussed in Module 3.

Notice also that this EVM chart provides more information than a cumulative cost curve. EVMshows the value of the work done and the cost of that work.

As a project manager, you must know where all this information comes from. The PV is createdthe same way the cumulative cost curve was created. It is simply the budgeted cost of the workplanned (scheduled) to be done to date. The AC will derive from whatever accountingmechanisms are used to capture costs expended. They may include time sheets, payrollrecords, purchase orders, and so on. The EV is simply the budgeted cost of the work packagesthat have been completed to date. For example, the EV of an activity with a total PV of $10,000that is 30 percent complete would be $3,000.

Comparing the three curves will tell you whether you are facing good or bad news. In theexample above, the news is all bad:

The project is over budget and behind schedule.

Actual costs are more than the value of the work done.

You have accomplished less than you planned to at this point in the project.



Variances

By calculating the three basic components of EVM, you have used a common approach tocompleting the first step in the performance monitoring process—comparing actual resultsagainst baselines. Now you need to determine the variances between the two. The methodsdiscussed in this section are described in the PMBOK® Guide, p. 182

Variances are simply the differences between what you have accomplished and what you hadplanned to accomplish. When you know the three basic EV elements, it is easy to determinevariances in cost (CV) and schedule (SV). The formulas for calculating these two figures are—

CV = EV – AC

SV = EV – PV

In both formulas, positive values indicate good performance (a cost savings or being ahead ofschedule), and negative values indicate poor performance (a cost overrun or being behindschedule). A variance of zero means you are right on the schedule or cost baseline. Don’texpect that to happen very often!

Variances can also be determined by using index calculations, which provide a percentageperspective. The two indexes that can be calculated using EV data are the cost performanceindex (CPI) and the schedule performance index (SPI). The formulas for calculating these twoindexes are—

CPI = EV / AC

SPI = EV / PV

In both cases, an index greater than 1.0 indicates good performance (a cost savings or beingahead of schedule) and an index less than 1.0 indicates poor performance (a cost overrun orbeing behind schedule).

The same three starting points (PV, AC, and EV) are used for calculating variances andperformance indexes.

Don’t forget two additional formulas used to calculate variances. They are budget at completion(BAC) and estimate at completion (EAC):

Budget at completion (BAC): What is the total approved budget for all activities (including anyoverhead allocations) in a project?

Estimate at completion (EAC): What will this cost me?

BAC = Sum of all PVs

EAC = BAC/CPI



Some caveats regarding EV and related analyses are in order. First, EV is not the only way tomonitor performance, nor should it be. It just happens to be a powerful tool for packing a lot ofinformation into easily understood numbers.

For example, notice that the SV uses monetary measures to evaluate scheduled progress. Thiscan lead to misleading, if not downright bizarre, results. Consider a project with someprocurement activities that are major cost components but have months of float time. If you takeadvantage of an unexpected discount and purchase these components well ahead of schedulewhile less costly critical activities are falling behind, your SV may show you are “ahead ofschedule,” although your network diagram forecasts significantly late project completion unlesscorrective measures are taken.

Second, you must not forget the final step in performance monitoring—reacting to what youhave learned—regardless of how you determine variances from your baselines. You may needto resequence work, add resources, or pay for overtime in order to correct schedule variances.You may need to manage more closely those activities that are incurring cost overruns. Inaddition, you may need to run interference with customers and stakeholders if you encounterindications of scope creep.

Let’s take for example, an application development project that is expected to cost $40,000 andtake five months to perform. To keep it simple, assume that the costs will be expended at therate of $5,000 during the first and last months and $10,000 during the second, third and fourth.Further assume that by the end of the second month, $18,000 has been spent and the project is50 percent complete. Using that example, the following measures of project cost and schedulevariance can be calculated:

Cost variance (CV):

– CV = EV – AC– CV = (50% x $40,000) – $18,000– CV = $20,000 – $18,000– CV = $2,000

Schedule variance (SV)

– SV = EV – PV– SV = (50% x $40,000) – $15,000– SV = $20,000 – $15,000– SV = $5,000

Cost performance index (CPI)

– CPI = EV/AC– CPI = (50% x $40,000)/$18,000– CPI = $20,000/$18,000– CPI = 1.11



Schedule performance index (SPI)

– SPI = EV/PV– SPI = (50% x $40,000)/$15,000– SPI = $20,000/$15,000– SPI = 1.33

Assessing Project StatusIt is easy to focus on the more cut-and-dried issues related to time and money when assessingproject status. From the formulas described in preceding sections, it is clear that a key aspect ofassessing project status is the evaluation of the worth of the work completed to date, or itsearned value. Done correctly, this will be accomplished by a review of the status of workaccomplished on each of the work packages in the WBS.

This review is almost always done based on a percentage of completion so that the percentagecomplete can be multiplied by the total value of the work package to determine its individualearned value. How to judge percentage complete for partially completed activities is alwaysproblematic because it can be subjective. Using one of the following fixed formulas can helpremove some of the subjective aspects of this process:

50/50 rule: When a task is begun, it is reported as 50 percent complete. When it iscompleted, it is reported as 100 percent complete.20/80 rule: This is a more conservative approach that reports 20 percent for the start of atask.0/100 rule: This is the most conservative approach. It assumes that a task does not earnany value until it is totally completed and is commonly used in contracting situations.

Yet, the project schedule and cost do not tell the whole story of project performance; there areother issues critical to success. Review all the work done in project planning for help.

To assess scope status, go back to the WBS. Monitor the scope baselines that you set andagreed upon with the client. Are you meeting the WBS? This review especially gets important aschanges occur and the WBS is changed.

To assess quality, you can look at your quality planning, and perhaps, most importantly, checkon whether the customer is happy with how things are proceeding.

One simple evaluation tool is a resource leveling chart that compares actual resources usedwith what was planned. This is done by starting with a resource histogram developed during theresource planning process and plotting a line graph of actual resources used on top of it.Variances between the planned and actual use of resources will be obvious.

The key point is that you need to see the complete picture whenever you are assessing projectperformance.



Corrective Action

There are many clues that corrective project action is in order, starting with significant scheduleand cost variances. Others include long delays in resolving problems, excessive projectpersonnel turnover, persistent quality control problems, and large numbers of changes or poorchange control.

Corrective actions may take a variety of forms as well. You may be able to change taskrelationships and perform critical path activities in parallel if you can accept increased risks. Youmay be able to add more resources to critical path activities, but this usually decreasesefficiency and increases costs. It may be possible to move resources around and assign moreexperienced personnel to critical activities. You may decide to try a more efficient method, or abetter technology, but watch for time lost on the learning curve! Bringing in outside resourcesmay be useful if the quality or quantity of resources needed is not available within theperforming organization.

If outsourcing is involved, there are several options for addressing serious performanceproblems. As the buyer, you may want to look for another supplier who can provide what isneeded in a timelier manner. As the supplier, you may want to try to renegotiate the terms of thecontract to buy more time. Together, the buyer and seller may agree to change the scope of thecontract and provide a lower quantity or quality of deliverables for less money.

The important thing to remember when contemplating corrective action is the triple constraintand the effect of each solution you consider. Implementing corrective strategies essentiallyresults in replanning the project. The project plan, including the WBS, the schedule, and thecost estimate must all be revised as the project manager performs a balancing act in an effort tobring the project back on track, adhere to the schedule, and keep costs under control.

Ways to Speed Up Schedules

Projects may fall behind schedule for many reasons. In addition, sometimes the project team isasked to perform faster than would normally be expected from the start. How can a projectmanager accelerate a schedule in order to deal with such situations? Can the duration of aproject ever be shortened?

Yes, it can, but only if one or more of the tasks on the critical path can be accomplished in lesstime than scheduled. That brings us to speeding up the schedule. Basically, there are twooptions, crashing and fast-tracking, but neither should be taken lightly! Because of the tripleconstraint, you might speed up the schedule, but do so in a way that the effects on the project’sscope and quality or its costs and resource requirements of the completed project may not beworth the time saved.

Crashing is defined in the PMBOK® Guide, p. 431, as “taking action to decrease the total projectschedule duration after analyzing a number of alternatives to determine how to get themaximum duration compression for the least additional cost.”

Crashing is typically done by adding resources to the project. The resources must be paid forand often become less efficient when working under accelerated schedule requirements, thus



increasing the cost that the PMBOK® Guide definition says to minimize.

Based on the project constraints, you know that crashing is not always possible and that it issometimes possible only with added resources. For example, it can take one person three daysto paint a house, but the same task can take two people two days. Besides incurring anadditional day’s wages, you will need more paintbrushes, more drop cloths, and maybe asecond ladder. But there’s a limit to time savings, even when you continue to incur the costsassociated with additional resources. If you assign 50 people to paint, they’ll run into each otherinstead of finishing quicker. The law of diminishing returns is alive and well.

Fast-tracking as defined in the PMBOK® Guide, p. 435, is “a schedule compression techniquethat changes network logic to overlap phases that would normally be done in sequence, or toperform schedule activities in parallel.”

The primary drawback to fast-tracking is the increased risk incurred through overlapping. Thepotential for errors and rework increases and may have an adverse effect on both scope (interms of quality) and resource costs. Using the example in the definition, you may encounter afundamental design problem after some degree of construction has been completed, andexpensive demolition and rework may be the end result instead of saved time and costs.

What role do schedule acceleration methods have in schedule planning? There is almostalways a time crunch in the real world of projects, but sometimes the critical path tells you fromthe start that you have to make some adjustments. For example, you know up front that adormitory must be ready in early August, or a store must open in time for the holiday shoppingseason. As a project manager, you often may have to speed up your projects. The importantpoint is to examine the various options for accelerating the work and consider the ramificationsof cost and risk.

Performance ReportingIn addition to assessing your project, you must tell stakeholders what they need to know aboutthe project without burdening them with too fine a degree of detail or too much information. Thetiming and level of detail involved in performance reporting will depend on the audience. If youprovide too much information or detail, you may confuse them and waste valuable time thatcould be better spent on many other things.

Besides standard content and timing, it is wise to use a standard format for performancereporting. Doing so promotes clarity of communication and facilitates tracking of progress andissues from one report to the next. A good, standard approach for almost any subject matter isto cover the following:

Current status (that is, progress since the last report, significant problems encountered, andaction taken or planned)Forecast progress (or what you expect in the near future, anticipated problems, and possiblerecommendations for dealing with the problems)Other important and relevant information ( upcoming milestones, slipped milestones,milestones that have been met)



Common tools and techniques, such as summary reports, e-mails, charts, presentations, andconference calls can all be used to tell stakeholders what they need to know, but don’t gooverboard.

Communication and quality are tied into performance reporting. In essence, you areimplementing your communication and quality plans by giving people appropriate status andheads-up information.

Project Evaluation

Project evaluation is a periodic process that may be done every month, quarter, or whenever itis most appropriate. For example, there is a form of evaluation conducted after a project isclosed called a project audit. It gives you a chance to step back and figure out how your projectis performing. Beginning from the start of the project, you need to do it on a regular basisbecause it is much easier to modify what you are doing with six months left in the project than itis with six days left to go. Periodic evaluations can also help with stakeholder communications.

This is not the detailed daily monitoring that the project team performs for its own purposes. Inevaluating the project, you should focus on the big-picture issues and trends. You should notinvest an enormous amount of time in analyzing minor issues that have a potential limited effect.Being slightly over budget on one work package because of a minor amount of rework is notnearly as important as knowing the overall budget trend and what it predicts for the final projectoutcome. For example: Instead of worrying about being $2,000 over budget on a $50,000project, analyze the budget trend to determine possible projected expenditures at completion.

You may choose among various courses of action as the result of an evaluation.

If things are going well and no new risks are on the horizon, you will probably want to stickto your project plan.If they are not, you may need to make minor or major adjustments.

If you have a failed project, you may decide that early termination is the most sensible course ofaction.

In performing any project evaluation that reaches the question of whether the project or any partof it should be terminated, you must understand the concept of sunk costs. Sunk costs are whatyou have already spent and cannot get back. When a task or project is costing more thanexpected, people commonly decide to abandon it because they don’t want to continue to “throwgood money after bad,” but this can be a serious mistake.

It is easy to make errors of judgment in assessing project performance if you get overly hung upon sunk costs. Because you do not have the ability to reuse already expended funds, theyshould not affect future decisions. If you end the endeavor, that money is spent. If you continuethe endeavor, it is spent. Either way, the spent money is sunk into the project and cannot bechanged.

What does matter is the money you can still control. If the project has spent $100,000 andneeds $10,000 to finish, you need to ask what the payback will be for spending that $10,000 onthe project. Then ask what else could you do with the $10,000 and what would be the payback



from that effort. Financially speaking, whichever has the better payback for the $10,000 is thesmarter effort. Either way, the $100,000 is gone and cannot be recovered.

Managing Change

ChangesChanges in the project plan don’t come just from the customer. They can come from just aboutanywhere: from the customer, the team, the project manager, senior management, or outsideregulatory stakeholders. Regardless of their sources, project managers need to be prepared forchanges because many are unavoidable and many are valid and in everyone’s interest topursue. The key from a project control perspective is to manage them.

Because changes will happen, you must be ready for them with a process that is written into theproject plan. A configuration management plan should be included in the project plan, especiallyon technical projects. Specific formats should be established that call for a review of the effect achange may have on cost and time as well as scope and quality. Do not let comments in casualconversations be considered change requests. All change requests, no matter what the source,should be submitted in a standard written format. The process should clearly specify who hasauthority to direct changes and to what extent.

The change management plan should identify who is empowered to make decisions aboutchanges and whether there are any cost restrictions on such authority. It should include a clearprocess for dealing with changes expeditiously. This process should ensure that a completeanalysis is done to determine whether or not to accept the change and that the results of theanalysis are communicated to those who need to know them.

As project manager, you must remember that changes may occur to any aspect of the tripleconstraint and that changes in one aspect may have effects on another. The customer maywant to increase or decrease the scope of the project. Normally, that will have a correspondingeffect on cost. If critical activities are affected, it may also affect the overall project schedule.You may be asked to deliver the same scope at an earlier date. This may affect costs bycausing additional expenses, such as overtime work. The point is, when you see a changecoming, evaluate what it does to all aspects of the triple constraint.

You should follow a previously determined process when dealing with changes for severalreasons. One is to make sure you deal with the change expeditiously by taking the correctsteps. Having a process does not mean that it must be overly cumbersome. Another reason isthat a well-designed process will ensure that you perform a complete analysis before a finaldetermination is made on whether or not to make the change. And of course, a sensible processwill ensure that the results of the analysis are communicated to those who need to know them.



Change Control Board

The project plan should provide for a Change Control Board (CCB) to review and approve orreject proposed changes on a project. The CCB, according to the PMBOK® Guide, p. 428, is “aformally constituted group of stakeholders responsible for reviewing, evaluating, approving,delaying, or rejecting changes to the project, with all decisions and recommendations beingrecorded.”

When presented with a proposed change, the CCB has various options:

Reject the change. If it does, it should provide the reasons for the rejection, inasmuch assimilar changes may be requested later.Accept the change with revisions. The CCB should also provide the reasons for this action,update the traceability documentation, and route the information appropriately.Accept the change proposal as presented. In this case, the CCB should make no additionalrequests, update the traceability documentation, and route the information appropriately. Ifthe change is significant, it may need to go through configuration management.

Configuration Management (CM)

Configuration management (CM) is a deliverables-oriented, highly structured approach tomanaging change. According to the PMBOK® Guide, p. 429, a configuration managementsystem “is a collection of formal, documented procedures used to apply technical andadministrative directions and surveillance to—

Identify and document functional and physical characteristics of a product, result, service, orcomponentControl any changes to such characteristics

Record and report each change and its implementation status

Support the audit of the product, results or components to verify conformance torequirements

It includes the documentation, tracking systems, and defined approval level necessary forauthorizing and controlling changes. In most application areas, the configuration managementsystem includes the change control system.”

The advantage of configuration management, especially in large projects, is that it tracks thecountless, often small changes that can occur almost weekly, if not daily. However, in somecases, it could lead to too much paperwork.

CM is intended to improve project team productivity and capacity. CM is a formal discipline toprovide methods and tools to identify the system developed, establish baselines, controlchanges to these baselines, record and track status, and audit the product. It helps ensure thatthe integrity and continuity of the system are recorded, communicated, and controlled. CM isnormally handled as part of change management.

Another way to look at it is that CM is a method to control, document, and communicate



changes to the deliverable and process while change control focuses on “identifying,documenting, approving, or rejecting, and controlling changes to project baselines” (scope, cost,schedule, and so on). (PMBOK® Guide, p. 428)

Managing Risk

Managing Risk Overview

As part of the control process, the project manager must constantly be on the lookout for risksthat become realities. Otherwise, the project manager will not be ready to react promptly andeffectively, and that is when the most trouble can occur. The assumptions that went into riskplanning must be monitored to see if they are still true. A risk that was considered acceptablebecause of low probability and low effect may have become more likely and more serious duringthe course of project execution because of unforeseen external events. The project managershould also watch for new dangers that may arise. You may be dealing with a whole differentset of risks than seemed possible just a few weeks or months ago.

As a project manager, you should be alert for several red flags:

A large number of change requests

Serious cost overruns

Schedule delays

Not surprisingly, these are internal project signals that correspond to the project constraints.However, warnings of trouble may also come from external sources, such as events in the newsthat might have an adverse effect on the project.

Responses to risks that occur should follow the risk response plan in the risk management planwhenever appropriate. When unforeseen or discounted risks come to pass during the Executionphase of the project, you cannot rely on a predesigned plan, but using project reserves isanother option.

Quality

Quality Overview

Quality assurance (QA) consists of all the planned and systematic activities implemented withinthe quality system to provide confidence that the project will satisfy the relevant qualitystandards. Quality Control (QC) looks at the activities used to measure performance andhighlight potential changes to the processes. QA and QC should be performed throughout theproject. It is often performed by a QA department, but it does not have to be. Project managers



can greatly affect the quality of their projects by performing good quality assurance activitiesthat are measurable, relevant, integrate, and assignable.

Tools that can be used for quality assurance include the following:

A cost-benefit analysis is a process of estimating tangible and intangible costs (outlays) andbenefits (returns) of various project alternatives and using financial measures, such asreturn on investments and payback period, to evaluate the relative desirability of thealternative.Benchmarking can be used to compare the characteristics of the project’s product with thecharacteristics of similar products either inside or outside of the performing organization.Design of experiments holds one variable constant in order to observe changes in othervariables.Cost of quality deals with bottom line quality cost. Conformance proactively addressesquality and nonconformance addresses quality reactively.Flowcharting is a diagram consisting of symbols depicting a physical process, a thoughtprocess, or an algorithm. It shows how the various elements of a system or process relateand which can be used for continuous process improvements.Quality audits are structured reviews of specific quality management activities. They identifylessons learned that can improve project performance.Various software development life cycles and methodologies are used, such as the SoftwareQuality Function Deployment (SQFD) Model, which yields a set of measurable technicalproduct specifications and their priorities. Another example is the Capability Maturity Model(CMM), which is a five-level model developed by the Software Engineering Institute atCarnegie Mellon University. It describes a generic path to process improvement for softwaredevelopment in organizations. Level 1 is initial, indicating ad hoc software developmentprocesses. Level 2 is repeatable, indicating the basic project management processes are inplace. Level 3 is defined, meaning that the organization uses a standardizedsoftware process. Level 4 is managed, meaning that the organization collects detailedmeasures of the software process and product quality. Level 5 is optimizing, which is thehighest maturity level, meaning that the organization enables continuous processimprovement and innovation of ideas and technologies.

Tools that can be used for quality control include the following:

An Ishikawa diagram (cause and effect) “illustrates how various causes and subcausescreate a specific effect.” (Ward, p. 226)A flowchart is a “diagram consisting of symbols depicting a physical process, a thoughtprocess, or an algorithm. It shows how the various elements of a system or process relateand which can be used for continuous process improvement.” (Ward, p. 175)A Pareto diagram, “ordered by frequency of occurrence, shows the number of results thatwere generated by each identified cause.” (Ward, p. 302)An inspection is an “examination or measurement of work to verify whether an item oractivity conforms to a specific requirement.” (Ward, p. 215)



Developing the Project Team

Developing the Project Team

Unless a project is relatively small, the project manager’s role is not to do the project work.Because project managers tend to be “can-do” types, it is often a challenge for them toremember that their job is to manage the project, not to do it.

His or her role is to organize and supervise the project team so that team members can do it.New project managers, in particular, may have a difficult time understanding this principle. Itdoes not mean that the person who is the project manager can never perform any of the projectwork. For example, on a small project, one person may be the project manager and the primarysoftware programmer. The point is that the person in that position is holding two roles and mustnot confuse them.

The project manager must get the right members on the team and support them as they do thework. Just as you seek the best and most suitable members for the core project team during therequirements phase, you want the best for the larger project team as well. To the extentpossible within the organization, be proactive in identifying and recruiting the people you want.Enlist senior management and the leadership team to help, as appropriate.

In addition to assembling the team, the project manager needs to develop it throughout thecourse of the project in order to keep it productive and let it reach its potential. Understandingmembers’ motivations helps do that. There are many theories about what motivates differentpeople, and the project manager should be familiar with some of their underlying concepts andbe able to apply them to the project team.

Regardless of the theory being applied, the conclusion is the same: Different factors motivatedifferent people. As the project manager, you can’t meet every team member’s every need, butyou should understand what motivates them individually and apply that understanding topromote the team’s effectiveness. On a large project, your subleaders should be aware of themotivations of their members for the same reasons.

Characteristics of Effective Teams

Everyone knows from sports that a team can be a loosely assembled, poorly performing groupof individuals or a high-performing group of interdependent members committed toaccomplishing a goal together.

To form a high-performing group, the project manager needs to balance staff development withgetting the job done. For example, you may not assign one of the most important tasks to anovice, but you would certainly want to carve out positions of responsibility for younger or less-experienced people so they can learn. Conversely, if you have subject matter experts, you cangive them the leeway to use their expertise.



So, what elements are you looking for when creating a team? The optimum team size isbetween six and eight with a maximum of 12 members. The team identity needs to extendbeyond the sum of the individual providing a common purpose. Providing a common approachwill enable the team to determine who does what job, what skills are required, what skills areneeded, and so on. Don’t forget to look for diverse perspectives, technical skills andinterpersonal skills within your team. Encourage clearly defined, mutually agreed-uponexpectations. Finally, look for team members that engage and are responsible with a sense ofmutual accountability.

Acquiring Project Team MembersBased on the nature of the project, the performing organization and its resources, you probablycan determine whom you want on the project team, but how do you get them? Even the bestplan will fail if you can’t win the resources. Here are a few approaches you can try:

Your team may be preassigned. This will not require any action on your part, but you will betested by having to manage a team assembled by management’s design. Although you willhave referent authority, you may get a team that you find difficult to work with. From theorganization’s view, this can be a poor approach because it creates a temptation for theproject manager to blame someone else for project failure.You can negotiate. This will require discussion with other project managers and functionalorganizations to get team members assigned. It involves give and take, provides anopportunity to present perspectives, and offers chances for collaborative win-win solutions.But if you are a poor negotiator, you are not likely to get the people you want.Your team may be assembled through the procurement process. In this case, you will havepurse-string authority, and you will know whom you’re getting. However, the team may havemercenary tendencies and lack loyalty.

If you do not consider all the various parameters associated with project teams, you will notknow how well the staff will function, so having a well-functioning group will be purely a matter ofluck. There are several factors that the project manager should consider in selecting teammembers, including the following:

Experience. It seems obvious that you would want the most experienced team member youcan get, but this is not always the case. You may want less experienced people for a varietyof reasons. The project may call for a fresh perspective. The organization may need todevelop new talent. Too many team members with too much experience may conflict witheach other because each wants to have his or her way.Interest. It is always better to have team members who want to work on the project thanthose who do not.Personality traits. The project manager needs to determine whether the team members canwork together. Will the personalities mesh?Availability. A technical expert with required skills for the project is needed, but isunavailable due to the demands for that expertise.



Productivity. Having the MS Project® expert on the team isn’t productive if you are not usinghis or her MS Project® expertise to track your project, but rather a spreadsheet or adatabase.Work style. Team members need similar or complementary styles. Some want supervision;others want to be left alone. Some want interaction and extensive communication; others donot. Some may prefer to be closely managed, and if they are on the team, somebody elsemust be willing to manage them.Working with others. The ability to work with others in a team environment is critical forproject success. Someone who is not a team player is not suitable for a project environmentwhere success is measured by the collective accomplishments of everyone workingtogether.

Even if the project manager has no opportunity to influence which people are assigned to theproject team, these sorts of considerations are still vital because the project manager needs tohave a sense of the team’s shortcomings in advance.

Project Team Structures

In setting up the project team structure, the project manager should consider the nature of theproject, the organization, and the people involved and then establish a suitable team structure.There are many examples of team structures, but some of the more common ones include:mirror image, specialty, directive, and self-managed.

Mirror Image: The project manager can establish a team structure that largely mirrors theproject. It takes on a functional look with team members assigned to specific areas and notworking much together. (For example, the project could be preparing a training manual withseparate sections assigned to separate members.) Here, the project manager primarily servesas an “integrator.”

Specialty: When team members possess skills that can be used on multiple parts of the project,it is often a waste to assign them to only one aspect of the project by using the mirror imageapproach. When the specialty team structure is used, the team is organized to take advantageof the skills it has available. Here, the project manager primarily serves as a “coordinator.”

Directive: There is one clear boss who directs the activities of the other team members. Thisworks when you have only a few people who really know what is needed and others to do thework. This structure is of fairly limited use, but it can be an excellent system in certain situations,for example, when a very inexperienced team has to meet a very challenging deadline and hasthe advantage of a very experienced project manager. Here, the project manager primarilyserves as an “administrator.”

Self-managed: Teams are also called “self-directed” or “egoless” teams. On these teams,certain team members take on leadership of particular aspects of the project based on theirexpertise, and others support them. When appropriate, leadership will move from one projectteam member to another. Here, the project manager primarily serves as a “facilitator.”

Team structure is important. Don’t overlook consideration of which structure is best for yourproject. The fact that your organization always uses a particular structure does not necessarily



mean that structure will always work best. There is no single right team structure; theappropriateness of particular structures will vary from project to project and even from time totime between different parts of the same project.

Any project team structure can easily be incorporated into a virtual team, which is noncolocatedand often does not meet face-to- face. Indeed, the global project environment has led more andmore to the use of virtual teams. In addition, employees are working more and more from home,working more “flexible” hours, or have mobility challenges. Thus, the communication plan hasbecome an essential tool to manage the virtual team. The project manager should be aware ofdifferent structures as part of his or her “arsenal” of strategies.

Regardless of the team structure, one or more of the members may be “virtual” or not locatedwith the rest of the team. Virtual teams require a bit more energy, but can work well. Set asidetime to establish clear expectations, protocols for resolving conflict, decision-makingprocedures, and clear communication links and channels.

Organizational StructuresDifferent organizations naturally have different organizational structures. In setting up the projectteam’s structure, the project manager must first consider the organization’s nature. In someorganizations, functional managers are very powerful and thus control much of what happens inprojects. In other situations, the nature of the work is such that it should be done mostly in quiteautonomous functional areas. In these cases, the organization exhibits a “functional” structure.

When projects are considered to be critical to the organization or time or money is very limited,the organization is more likely to use a “projectized” structure. Here the project manager has thepower and fully controls the project, and the functional managers serve as providers ofresources.

In other situations (very common with projects these days), the value of varied disciplinesworking together makes more sense and leads to cross-functional orientation of the “matrixed”structure. The power here is more shared. The project manager will have responsibility for thework, but functional managers still have much control over what resources they allow the projectmanager to use. The matrixed structure will vary in how it operates depending on the balance ofpower between the project managers and the functional managers. PMI® uses the terms“strong” and “weak” to indicate this range of relationships, with the strength of the matrixindicating the relative power held by the project manager.

The project manager should be aware of these different structures as part of his or herorganization and know how to work within them successfully.

How to Form a Successful TeamSelecting and acquiring project personnel are only the first steps in transforming severalindividuals into a successful team. A variety of techniques can be employed to do this:



Ensure that the project manager and team members agree to their commitments andunderstand their roles and responsibilities. Use a roles and responsibility matrix.Delegate responsibilities to those who can best handle them. Make empowerment anoperating feature of the team. Recognize the importance of delegation, given the numerousresponsibilities on the project.Recognize that conflict is inevitable on projects. It cannot and should not be avoided. It canactually be beneficial and constructive to the overall project if well managed.Use the project charter to communicate the scope of the project and to ensure that it isaligned with the organization’s strategic goals.Diversity is a fact of life on projects, especially in the multicultural environment. It should beencouraged and promoted.For the project to be a success, each task must be completed. Each phase should be closedout before the next phase begins. A formal project closeout plan should be prepared and acloseout review conducted. Closure also helps team members achieve greater satisfactionwith project work.Motivate the team and support team identity. Team identity provides a sense of greatercommitment to the project. It helps the project team members feel closer to each other andincreases their willingness to support each other in an effort to complete the projectsuccessfully.

Rewarding Project Team MembersPeople need to be rewarded regularly for demonstrating desired performance. Yet, projectmanagers often do not have all the reward options available to them that functional managersdo because the team members usually do not report directly to the project manager. However,there are still ways that the project manager can and should show appreciation to ensurecontinued good performance either individually or for the whole team. Here are some options:

Public recognition. Say thank you in a project status meeting or departmental meeting. Handout personalized certificates for outstanding performance.Financial rewards. Bonuses, pay increases, or even a gift certificate or dinner for two on thecompany can be given to top performers.Responsibility. An effective team member can be assigned to a team leader position for theproject or simply asked to sit in for the project manager.Assignments. Good performers can be given their choice of the next project they work on,such as one involving a new technology that will allow them to increase their skills.Promotions. Promoting a team member to a higher rank usually has to be done by thefunctional manager, but a project manager who has supervised that person can providefavorable input and a recommendation.Team events. Take the team to lunch, dinner, or a team outing.

In short, reward those who meet or beat their commitments. Remember that rewards come inmany forms, and whenever possible, recognize group contributions. Whether the reward isexpressed privately or publicly, stated on paper, made with money, or through some other



means, providing feedback to individuals and to the team is important. The project managermust let people know when their behavior contributes to the project’s goals.

Team Conflicts

Despite your best efforts as a project manager to understand the nature of your organizationand develop a suitable structure for your project team, conflict within a team or between theteam and other stakeholders during the Execution phase is usually inevitable. Human naturebeing what it is, many everyday occurrences on a project team can lead to conflict. To namejust a few, consider the conflicts that can arise out of—

Schedules

Priorities

Personalities

Administrative procedures

Technical recommendations

Look for conflict and be ready to manage it.

There is no question that conflict can be mismanaged and create an atmosphere of mistrust anddissension that diverts too much energy for the real tasks. According to traditional managementtheory, conflict is bad and should be avoided. More contemporary theories suggest that someconflict is good if it is managed to the mutual benefit of all concerned. For example, if peoplequestion what is happening and are given the opportunity to share proposals for alternativesolutions, they can become more vested in the success of the project, and their ideas may wellimprove the end result. This most often requires addressing conflicts head on in order to resolvethem. Although smoothing over conflicts or trying to solve them through compromise may workat times, there also may be attempts to take the easy way out, which only create an atmosphereof mistrust and dissension and divert too much energy from the real tasks. Under eitherphilosophy, the project manager should be on the lookout for conflict and be ready to manage it.

Managing the Team

When the Implementation phase is under way, the project manager must stay involved with theteam to monitor its progress in developing the product or system. Even though the projectmanager is not directly involved in development tasks, it is critical that he or she monitor theirprogress. If necessary, the project manager should provide the team with supplementalresources to keep the project on track.

It is also crucial that the project manager communicate frequently with the team members. Thisis necessary to maintain awareness of any problems developers are facing, to keep thedevelopment schedule and delivery dates on track, and to ensure that the product or systembeing developed meets the approved design specifications and client business requirements.Communications can be undertaken by holding regular meetings with the team to identify andresolve any development problems and by less formal day-to-day contacts.



The project manager needs to “protect” the team from the outside so they can perform theproject as the baselines indicate. As a simple example, consider an open office. If you are theproject manager, where should your office be, way in the back? No, it should be in the front soyou can see what is going on and serve as a “gatekeeper” who filters interference from theoutside.

Managing Stakeholder Expectations

Managing Stakeholder Expectations Overview

At some point in the Execution phase of a project, the project manager will probably have tomanage stakeholder expectations and changes to the project baseline. This is often difficult todo without falling into the trap of being technically correct but practically wrong; in other words,having a customer that is not happy with what the project team is doing.

Stakeholder expectations, particularly those of the customer, tend to wander as the project goeson. The scope might call for a landscaping plan with six new trees, but wouldn’t a fishpond looknice right here, too? The project manager must first understand the revised expectation andthen either translate it into a change request or diplomatically help the customer understand the“wandering nature” of the expectation and, thus, go back to original scope.

This phenomenon is commonly referred to as “scope creep.” Managing scope creep is aconstant struggle because you are dealing with the triple constraint, as well as with theintangible but crucial factor of customer satisfaction. During the Planning phase, it is addressedby clearly defining project requirements during the scope planning process. During theExecution phase, you need to maintain dialogue and communications with the customer,providing updates on progress through formal and informal means. At the same time, you don’twant them so involved in day-to-day activities that you fail to protect the team so it can do thework.

Scope Verification and Customer Acceptance

Scope Verification and Customer Acceptance Overview

Scope verification and customer acceptance are two more instances where the WBS proves itsvalue. Basically, these two efforts are intended to determine whether you did what you plannedto do.



Scope verification is the core project team’s thorough internal check of the WBS to confirm thateverything was done. It is conceivable to have work packages that were not on the critical pathdelayed early in the project and never performed later, and the team needs to verify theabsence of such oversights. The team’s findings will be used to seek customer acceptance andto perform the administrative and other aspects prior to the close of the project or phase.

When you go to the customer, you have a few things to accomplish:

Cross-check what was actually accomplished against the requirements, making sure thatthe scope has been completed. Be sure to get acceptance documented by having thecustomer sign off on a checklist or some other form of acceptance.More importantly, do not just get the customer’s technical approval. Make sure that thecustomer is satisfied. Are there any hesitations or concerns? Remember that expectationsmay have outgrown scope. Even though you technically fulfilled the scope, the customermay be wishing for something extra that ranges from the impossible (another wing on thebuilding) to the negligible (a copy of the progress photographs). These sorts of last-minuteissues should be explored and satisfied as appropriate.Put on your marketing hat and ask, “What else can we do for you?” It might lead to a newproject. And don’t forget that you can properly accomplish the whole project, but in a hurry toget things wrapped up, you can do one thing that aggravates the customer. Which will beremembered, all the good things you did or that last impression, conveyed in haste?

It is important to point out that scope verification and quality control are uniquely different in thatthe former is primarily concerned with acceptance of deliverables, while the latter is focused onmeeting the quality requirements specified for the deliverables. An easy way to see this is toanswer the questions, “Is it done?” (Verify scope) and “Is it done right?” (Perform qualitycontrol).

Module Summary

Module Summary

Monitoring and controlling is ongoing and used by the team; evaluating is periodic and usedby senior management.Change can be managed with a well-designed change management system.Earned value shows the project manager the difference between what was planned andwhat has occurred at a certain point in time.Performance reports should be prepared differently for different audiences.Risk response plans can be used to manage risks.The project manager must develop, structure, and support the project team for it to performwell.Conflict is inevitable and must be managed.



Verify scope against agreed-upon requirements.Closing out with the customer involves both technical acceptance and sign-off.



Module 5Project Closeout

Introduction

Module OverviewThis text deals with the often-overlooked project closeout and the various types of activitiesinvolved in the Closeout phase.

Project Closeout

Project Closeout OverviewMany project managers think the project ends as soon as the product or service is delivered tothe client. Project closeout is a process that often is shortchanged, but it is, nevertheless,essential to complete project success. Project closeout is the process of finalizing all activitiesacross all of the project process groups to formally close the project.

There are various types of closeout activities, from making sure the “Ts are crossed” in terms ofcontract compliance to sharing wisdom and experience for future projects. The project managerneeds to ensure that tasks required for proper scope verification and customer closure havebeen accomplished. Contract and administrative closure also are essential to proper projectcloseout. Finally, the project manager should complete an analysis of lessons learned andproject successes, and communicate them to appropriate project stakeholders.

With pressures to reassign team members, move on to new activities, and so on, the onlypractical way to accomplish closeout is to include it in the plan. The project plan specificallyshould identify the various closeout tasks, allocate costs to them, schedule them, and assignthem resources. Include closeout work in the WBS to be sure that you adequately allocate thetime, money, and resources to do it.

Module 5: Project Closeout


Closeout Guidelines and Issues

Guidelines for Project CloseoutCloseout does not just apply to completed—and hopefully highly successful—projects. Eventhose that do not end as planned must be closed out properly. Also note that some closeoutactivities are MORE important in prematurely closed projects than fully completed projects. Forexample, the project manager must either schedule unstated work to ensure the work iscompleted on time or stakeholders must formally agree that such work may be accepted "as is”or at some other level of competition.

When planning the project schedule, always allow time for project closeout. As a result, teammembers will recognize the importance of this phase and that the project is not complete untilthis phase has been concluded. In addition, allow time to prepare a detailed closeout plan andinclude this in the work breakdown structure for the project.

Develop and use a project closeout checklist so that you don’t overlook critical steps andprocesses to be followed. There are countless details that need to be addressed, and you wantto ensure everything is closed out properly. Some items on the checklist (such as waiting forfinal invoices to be paid and checks to be cleared) can take months to officially close out.

Review prior projects to ensure you understand all the activities needed to close out a project,including—

Contract closeout

Transition to the customer

Transition to the technical maintenance teams

To communicate the official end of the project, begin by scheduling a formal closeout reviewshortly after the product or service has been delivered. The closeout review allows the projectteam and the sponsor to discuss the final outcome and the lessons learned. Have someoneother than you (such as another project manager or someone from the corporate qualityassurance or audit group) perform a final review of the project results. Issues to be reviewedshould include—

What was the overall level of customer satisfaction?

Was communication effective?

Did the project meet the business objectives?

Were project management processes streamlined and effective?

Was project return on investment (ROI) obtained—or will it be in the future?



Collect all documentation pertaining to the technical solution developed and prepare closeoutdocumentation, including lessons learned, the final project report, and a procurement audit. Besure these lessons and project documents are archived in a location where they may be easilyaccessed as a record for the project and as a reference for future projects. Prepare a finalproject report and communicate it to stakeholders. Your final report should include a summaryof the project results, a high-level executive summary with any appropriate graphs, and adetailed section for those who are interested in the specifics. Focus on what business needshave been met, the “big wins” for the organization, and the triple constraint (that is, plannedversus actual time, cost, and scope).

As project manager, you should continue to preserve the team identity and keep spirits highamong team members. You can do this through status meetings, performance feedback, awardrecognition, and a celebration. Just as you did throughout the earlier phases of the project,continue to conduct periodic status meetings until all tasks for the project have been completed.Status meetings can be brief and to the point. Stress the importance of the effort, show progresson milestones completed, and reflect on how great a job the team did! Talk about the benefitsthe business is experiencing due to the implementation of the project. You can even make thesemeetings fun by recognizing star performers with awards.

Communication during closeout is as important as it is during other phases. Part ofcommunication involves providing performance feedback to team members and their functionalmanagers. Whenever possible, provide performance feedback in writing to address the skillsand qualities that make each person an outstanding team member and the areas of weaknesswhere they can improve. Be specific and honest. Describe opportunities or jobs that would allowa person to enhance and improve his or her skills. Most people like to be challenged!

Not every project team has the luxury of working in the same location. Whenever possible, youshould make an effort to visit remote sites if the project team is physically dispersed. Making sitevisits enables all team members to obtain closure on the project. It also offers people working atremote sites a chance to give you face-to-face project feedback and provide you with anopportunity to thank them in person for their contribution to the success of the project.

Regardless of whether your project team is a virtual team or located in the same office,celebrate success! Publicly acknowledge those who have truly made the project successful.Have a party, meet after work for a get-together, or simply send an e-mail recognizing the teamand individual team members’ accomplishments. Let everyone know the business benefitsrealized from this great project!

Finally, review and document lessons learned from the experience to help improve performanceon future projects. Share what you learned—including what worked and what didn’t work—withothers so everyone can benefit! In addition, document what (in hindsight) you would have donedifferently to really benefit future projects. Be sure the recorded lessons you and your teamcollected are easily accessible to other teams that may participate in similar projects.

Closeout Issues

Both the project team members and the customer are likely to be affected by motivational andprocedural factors during this phase. Now that the fun part of the project is over, project team



members frequently lose interest. Because schedule pressure has subsided, team membersmay not feel the same intensity to move ahead on tasks as they did during the “livelier” phasesof the project. In addition, some team members may already be working on new projects thatare taking up most or all of their time. As stated in the guideline for project closeout, the projectmanager really needs to step in and encourage team members to stay focused until theCloseout phase is complete. As the project manager, keep the team focused and maintain aconsistent and positive attitude. As soon as you begin to change your behavior, your team willstart to do the same.

Like the project team, the customer may experience a loss of interest in the project. Resistanceto change, change in attitude, and unavailability of key personnel make it difficult to completethe last few tasks and tie up loose ends, especially when customer input is needed. Thecustomer will now own and manage the product or system. So, it is essential that that transfer ofknowledge and up-to-date documentation is completed and in place for the customer to beeffective when going forward even if there is a resistance by the customer to own the solution.Remember, as you transition off of the project, you want to ensure that the customer is ready totake over.

Procurement and Project or Phase Closeout

Procurement and Project or Phase Closeout Overview

Closing out a project takes more than closing the project books, and if you do not handle closingproperly, it will come back to haunt you. Almost every organization and contract has its owntechnical requirements for closing out a project. As project manager, you must be sure youunderstand what is required.

The PMBOK® Guide, p. 100, identifies several key components of a project or phase closeout:

Documenting project results to formalize acceptance of the product or service by the client

Collecting project records and ensuring they reflect final specifications

Analyzing project success and effectiveness through lessons learned and procurementauditsArchiving information for future use

You may also have to deal with returning borrowed equipment, moving out of temporary officespace, and accomplishing other tasks. Organized archives are essential as people move on tonew assignments. What would happen if the project were audited two years from now?

Lessons Learned

Lessons learned are the organization’s memory bank. Ideally, you will track lessons learned asthey occur, or at least at major evaluation points or milestones throughout the project, and notwait until during the final week of the project to capture them.



Documenting lessons learned is a waste of time if the information is not relevant, disseminatedand preserved. Make sure a future project manager can learn from the good and bad contentmany years after the project closes. Is there a process that your organization uses to do this? Ifnot, then you may want to work to create one for the long term. In the meantime, you shoulddistribute your lessons learned to those who can benefit from them. If you do not do this, yourorganization will go back to square one every time it decides to pursue a similar project andwaste a lot of time and effort in doing so.

People-Oriented Closeout Activities

Last but not least, do not overlook people-oriented closeout processes. This means taking careof individual or personal issues, team issues, and public relations.

Your personal closeout starts with documenting success, both for the project’s benefit and yourown. For example, you want to keep letters of appreciation from the client and other awards orforms of recognition. Communicate to senior management the success of the project and yourcontribution to it.

You may also want to distribute some letters of appreciation on your own on a formal or informalbasis for members of the project team, inasmuch as you should also be looking to the nextassignment. And since you may be working with many of the same people in the future, a littlerecognition will go a long way toward making them want to come back and work with you.

Celebration and recognition of efforts as a team are just as important to team members as theyare to you. You may want to extend this to stakeholders outside the project team as a means ofpromoting good feelings about the project outcome. In some cases, your organization mayrequire you to prepare performance reports. You may also be able to facilitate the teammembers’ next assignments.

Finally, don’t forget public relations. This means “talking up” your project within yourorganization and, as appropriate, in the outside world. It never hurts to create goodwill andopportunities for future business.

Module Summary

Module Summary

Plan for closeout in the WBS and the schedule.Procurement and project or phase closeout ensure that all project requirements are met.Lessons learned impart valuable knowledge to your organization for use in future work.Closing out the project with the team, stakeholders, and yourself includes appropriaterecognition and celebration of your efforts.

