Managing Projects

Managing Projects
PMC:CPM:EN:000 ver. 2.0
© Copyright ESI International
April 2013
All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in

any 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 FAR
52.227-14 and DFARS 252.227-7013). Use, reproduction, or disclosure of these materials is
subject to the restrictions set forth in the MOBIS, FSS, or contract under which the materials
were 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 advancing
the 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 the
content for accuracy. PMI® does not endorse or otherwise sponsor this publication and
makes no warranty, guarantee, or representation, expressed or implied, as to its accuracy or
content. PMI® does not have any financial interest in this publication and has not contributed
any financial resources.

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

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

ESI International
Arlington, VA USA
 Module 1: Introduction to Project Management

Module 1
Introduction to Project Management

Introduction to Project Management

Introduction
This text is intended to provide you with a quick reference guide to the fundamentals and
concepts of managing projects. It addresses the roles and responsibilities of the project
manager across the project life cycle. It defines and develops the foundations of a project
management plan, including the project requirements document (PRD), work breakdown
structure (WBS), costs, schedule, and other resources. It explains the basics of managing and
controlling a project as actually performed against the project baseline and concludes with an
explanation of how to close out a project effectively.

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

Project Management Overview

Any study of project management should begin with the basic terms and concepts that provide a
foundation for the detailed methods and activities that project managers and project team
members perform throughout the life cycle of a project. Some of these terms and concepts are
related to the project itself, such as the actual idea of a project, as well as the concept of the
project life cycle. Others relate to the discipline of project management: the project constraints
(scope, cost, time, risk, quality, strategy, and resources) that silently govern every project; the
key processes that occur in every project; and the roles, responsibilities, and key competencies
of the project manager.

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

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

Module 1: Introduction to Project Management

The Project

The Project Overview

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

First, let us consider whose definition are we looking to for clarity.

There are many organizations out there that provide their own definitions in the field of project
management. Probably the most widely known organization for the advancement of project
management is the Project Management Institute (PMI®1). Other project management
organizations include the Association for Project Management (APM), which is a strong member
of the International Project Management Association (IPMA).

PMI® is a U.S.-based, global professional organization dedicated to advancing the

understanding and use of project management principles and practices. It is a leading
organization in the field and provides credentialing in the discipline of project management.
Their methodology and compendium of project management know-how is published in A Guide
to the Project Management Body of Knowledge, or (PMBOK® Guide2), which is now in its 5th
edition.

IPMA is setup a bit differently than PMI. IPMA is based in Switzerland and is made up of
subsidiary associations for each of the member countries. IPMA is also one the other major
project management credentialing bodies. It leaves the the methodology and bodies of
knowledge to each subsidiary organization.

APM is the United Kingdom's IPMA organization and, just like PMI, is dedicated to advancing
the project management profession. The APM has its own style of credentialing based on the
IPMA credential. The APM also publishes the APM Body of Knowledge (APMBoK).

Each of the organizations mentioned above have their own flavor of the definition of what is and
a what is not a project. In short, it can be stated that a project is "a temporary undertaking to
create a project or service."3 If you are pursuing a credentia, you must know the specific
vocabulary for that exam and credential.

Because the PMBOK® Guide’s approach constitutes a widely accepted means of breaking
down project management concepts and terms, its definition of the term “project” is a good

1 PMI is a registered mark of the Project Management Institute, Inc.

2 PMBOK is a registered mark of the Project Management Institute, Inc.
3 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 342.

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

 Module 1: Introduction to Project Management

place to start. A close look at the definition shows that projects have two key characteristics that
distinguish 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 definite
beginning and end, but it doesn’t necessarily mean it is short in duration. This is true in both the
planned 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, but,
generally, the hope is that it will never end, or that it will at least continue to operate successfully
for as long as possible. It is, therefore, not a project. However, the endeavor of getting a new
business or new business process up and running is a project because it has not only a start
point, but is also concluded when the new business or process has been launched and is
underway.

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

Project Management
Project management is “the application of knowledge, skills, tools, and techniques to project
activities to meet or exceed stakeholders and expectations from a project."4 This is
accomplished through the application and integration of the project management process of
initiating, 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? Of
course not! If you let it run on its own or with minimum management, a project may or may not
work.

Instead of taking that risk, you should employ the techniques and concepts of project
management. Project management helps ensure that time and resources are used most
effectively to meet the project requirements or scope. Indeed, project management is an
iterative process. As you’ll see in more detail later, there are basically two roads to project
management success: good planning or blind luck. It’s your choice.

4 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 348.

© ESI International PMC:CPM:EN:000 ver. 2.0 3

Module 1: Introduction to Project Management

What Is a Program?
There can be numerous projects in the ongoing operation of the business. Projects that are
similar in nature or related in some other respect can be managed in a coordinated way to
obtain benefits not available from managing them individually. When they are managed in such
a coordinated way, they constitute a program.

For example, the Department of Transportation may have a highway improvement program that
combines all new highway construction projects. One of the projects may be a complicated
expansion 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 must
proceed 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 the development and
implementation of electronic business-to-business capabilities, online customer sales and
service, and Web-based marketing and promotional techniques. Each development effort will be
a project in itself, but because they are closely related, it would be logical to manage them all
together as an e-business development program.

Although program management and project management obviously affect each other, program
management requires different techniques because it addresses issues at a higher level and
requires a greater focus on the ongoing use and management of limited resources across
multiple endeavors. Programs mistakenly identified as projects may fail because programs can’t
be managed like projects. They usually do not have a defined beginning and end like projects
do. They also lack the degree of specificity and clarity in their objectives that projects must
have. Unlike projects, programs cannot rely exclusively on borrowed resources. Instead, they
must rely on ongoing, long-term management and teaming structures, whereas projects are
constructed with an end in mind. A system or ongoing operation merely supports the projects
and 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, the
payroll system in a typical organization. For years, paychecks were taken to the bank every pay
period to be cashed. With the push to go “paper free,” many organizations transitioned to
electronic pay stubs and automatic deposits.

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

Other important relationships include portfolio and portfolio management as well as the role of
the Project Management Office (PMO).

The Project Constraints

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

4 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 1: Introduction to Project Management

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

Scope: This refers to the total of all of the work required to deliver the product or service, and
only the work necessary to get the project done.

Budget/cost: This refers to the total funds needed to obtain project approval, which includes
labor, material, equipment, and other direct and indirect costs to complete the project.

Schedule/time: This refers to the planned dates for performing the work and other activities,
including milestones along the way.

Risk: This is a collection of possible events that might occur along the way. They may impact
the project either in a positive or negative manner.

Quality: This is the degree to which the product or service must meet to be considered
acceptable and read to use.

Resources: These allow the work to be done, from skilled people/human resources, equipment,
supplies, materials, and even the funds necessary.

Strategy: This is the guiding framework in which the project exists, either from the organization,
the local or regional government, the methodology used, or a combination of many other
factors.
What then are the “constraints”? The constraints are how each factor affects the others. For
example, if a decision is made to speed up the schedule and complete a project earlier than
originally planned, this will have repercussions. It may require the assignment of more
resources or a reduction in the scope of the project, thus lessening the quality. If project

© ESI International PMC:CPM:EN:000 ver. 2.0 5

Module 1: Introduction to Project Management

managers can make their managers and clients understand the project constraints, they will
avert or solve many potential problems!

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

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

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

From the first day of the project, the factors that make up the project constraints are competing
with each other. Good project management is “the application of knowledge." As the project
manager, you must understand 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 the
artful way to accomplish what you need to. This is a constantly changing balance. Early in the
project, extra emphasis may need to be placed on scope matters. Later, cost trade-offs may be
necessary to finish key portions of project scope by a particular date, such as a stockholders’
meeting or the key season for a cyclical business.

Project Management Knowledge and Focus Areas

The purpose of the PMBOK® Guide is to identify the subset of the Project Management Body of
Knowledge that is generally recognized as good practice. The PMBOK® Guide presents the
discipline of project management in a matrix format based on ten “knowledge areas.” As a
project manager trying to balance the constraints, there are many pieces of information to help
you.

The most common project management knowledge and focus areas are—
Integration
Scope
Time
Cost
Quality
Human Resources

6 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 1: Introduction to Project Management

Communications
Risk
Procurement
Value
Benefits
Health Safety and Environment
Stakeholder
Governance
Competency

The Project Life Cycle

Although industries define the phases of a project differently, all the definitions boil down to the
same thing: a beginning, middle, and end that together constitute the project life cycle. The
beginning and end of each phase is a natural point to reassess the project to determine if it
continues or terminates and is usually marked by the completion of one or more deliverables—
that is, a tangible, verifiable work product.

Based on your own experience, chances are you will be familiar with differently named or
organized phases within a project life cycle. Many industries, government agencies, and
business enterprises have their own terminologies for explaining the project life cycle. For
example, 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 of
determination of mission need, concept exploration and definition, demonstration and validation,
engineering and manufacturing development, and production and deployment. Drug
manufacturers will follow a cycle defined by discovery and screening, preclinical development,
registration workup, and postsubmission activity. Software development firms will go through the
steps of feasibility, requirements, product design, detailed design, coding, integration, and
implementation.

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, formally
authorizing the project to proceed, and identifying and developing the functional and
technical requirements that lay the foundation for the project.
Planning: This phase involves producing the project plan, which consists of the WBS,
schedule, budget, staff requirements, risk plan, communication plan, quality plan, and
procurement plan
Implementation: This phase involves executing the development of the solution while
monitoring the performance and controlling the changes to align with stakeholder
expectations.

© ESI International PMC:CPM:EN:000 ver. 2.0 7

Module 1: Introduction to Project Management

Closeout: This phase involves reassigning all resources back to the organization, holding
postproject reviews with the client, managing contracts, and documenting lessons learned.
Although different industries and organizations may label their project management phases by
different names because of the wide use of the PMBOK® Guide, this reference material will use
this generic life cycle in explaining project management.

Project Management Process Groups

Project management is iterative by nature, an important aspect of the various processes
involved in project management. These processes often interact in complex ways and are not
completed in a consistent or simple step-by-step fashion. Within each process and between
processes, interactions and much iteration take place.

The five typical groupings of processes that occur in a project (defined by their typical function)
are—
Initiating process: Defining and authorizing the project or phase. Even though project
managers are rarely involved in this process, they need to know what has happened and
what they have inherited.
Planning process: Defining the project scope, refining objectives, and selecting the best of
the alternative courses of action. This is the heart of the project manager’s job and it covers
a 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), but
you are working to allow others to implement or execute it.
Monitoring and controlling process: Ensuring that project objectives are met by monitoring
and measuring progress to identify variances from the plan so that corrective action can be
taken. Do things always follow the plan? Of course not. Executing and monitoring and
controlling together make up implementation of the project after planning.
Closing process: Formalizing acceptance of the project (product, service, or result) or phase
and bringing it to an orderly end. Everyone is usually in such a hurry at the end of the
project to move on, but as we’ll see in project closeout, proper closeout is critical for real
project success.
Besides the interactions among processes (such as between project control and execution), a
project 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 phase
having its own initiation, planning, execution, control, and closeout.

The need for these processes depends on the nature of the project. For example, you may
identify 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 being
performed with internal resources, engaging in risk analysis may not be worth the time and
effort, 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 project
life cycle, not all process types are involved with all knowledge areas.

8 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 1: Introduction to Project Management

The Project Manager Role

Roles and Responsibilities of the Project Manager

All project managers must assume certain roles and responsibilities to provide good project
management. The minimum basic responsibilities required of project managers include the
following:
Define the 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, the
project team, and the client. In dealing with the organization, the project manager must provide
information 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 project
team, the project manager must supervise them, lead them, provide them with resources, and
protect them from detrimental outside influences so they can get the project done. In working for
the client or customer, the project manager must communicate project status, manage
expectations, and otherwise make sure that the client remains satisfied.

Skills of the Project Manager

In the expanded role associated with the new project management paradigm, project managers
need a broad set of skills to be effective. It is still true that traditional project management skills
in scheduling, budgeting, and allocating human and material resources are necessary. These
are the primary tools of project managers, who are considered to be only implementers—the
tools 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 the
needs and wants of the people they deal with, including customers, peers, staff, and their own
managers. The primary role of the project manager is to make things happen. It takes both hard
skills and soft skills to be successful in today’s complex business environment.

© ESI International PMC:CPM:EN:000 ver. 2.0 9

Module 1: Introduction to Project Management

Professional Responsibilities of the Project Manager

In addition to general management responsibilities, the project manager also has other
professional 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. The
position of project manager is currently considered to be a professional position, not just a title.
During the past 15 years, organizations like ESI, PMI®, IPMA, APM, and others have worked
hard to raise the standards of project management.

Module Summary

Module Summary
A project is “a temporary undertaking to create a unique product or service.” 1
Project management is “the application of knowledge, skills, tools, and techniques to project
activities to meet or exceed stakeholder needs and expectations from a project.” 2
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 vary by type of project) make up the project’s life cycle.
An example of a four-phase project life cycle is Initiation, Planning, Implementation, and
Closeout.
Five interacting processes groups work together to make up a project: initiation, planning,
executing, monitoring and controlling, and closing.
Activities and processes within the five process groups are categorized within the ten
knowledge areas.
To be effective, project managers need to have “hard” skills, such as planning and
budgeting, as well as “soft” skills like communicating and conflict resolution.

1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 342.
2 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 348.

10 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 1: Introduction to Project Management

The project manager’s primary role is to manage the project, but also important are the
related roles of planning, leading, communicating, negotiating, and problem solving.

© ESI International PMC:CPM:EN:000 ver. 2.0 11

 Module 2: Project Initiation

Module 2
Project Initiation

Introduction

Module Overview
This module focuses on project initiation. Even though the initiation of the project is often a
unique process in that the project manager may have little or no input, it is important that the
project manager understands the process.

Project Initiation

Project Initiation Overview

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

In order to participate in the initiating process effectively to the maximum extent possible when
given the opportunity, the project manager should also have command of certain skills, such as
the ability to—
Develop good project objectives based on assessing needs
Distinguish between functional and technical requirements and to understand the role of
both
Develop a project charter and a project requirements document (PRD)
Analyze stakeholders, assess their power and influence, and manage their expectations

© ESI International PMC:CPM:EN:000 ver. 2.0 13

Module 2: Project Initiation

Project Influences

Influences on a Project
Various influences have a bearing on the performance and outcome of most projects. These
influences may be internal in the form of the organization’s systems, structures, and culture. A
project sponsor is "the individual or group in the performing organization providing the financial
resources in cash or in kind for the project."1 In addition, enterprise environmental factors and
organization process assets play a significant role in the life of the project. There also may be
external social, environmental, and economic factors. In any event, a project never takes place
in a vacuum. The more savvy you are about analyzing and proactively dealing with the
influences on your projects, the more successful your projects will be.

Because projects are carried out within larger organizations (whether for profit, nonprofit,
personal, or government), characteristics of the organization influence the project. Being aware
of these characteristics is essential. The systems of an organization will determine how things
historically have been done. How has research been carried out, for example, and how have
costs 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 or
project managers?
Where does the control of human resources rest? With the project manager or the
functional manager?
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 assistance
from another department? Or is it a more laid-back culture in which you can stroll down the hall
or send off an e-mail to anyone at any level? The fact that something “always has been done
this way” shouldn’t dictate the future, but the wise project manager will be mindful of prevailing
practices.

External factors of a social, economic, or environmental nature are almost always outside the
control of the project manager and the project team, yet they can make or break a project.
Building a factory in another country will require an adjustment to social customs and practices
and the local legal system. Completing a complex software development project where
1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 414.

14 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 2: Project Initiation

developers are 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 good project manager must always be able to adjust project planning and execution
to account for external factors such as these.

Project Stakeholders
What is meant by the term “stakeholders”? "Stakeholders are individuals and/or organizations
actively involved in the project or whose interest maybe affected either positively or negatively
as a result of project execution or successful project completion."2

Stakeholders may also exert significant influence over the project and its deliverables. Some
common examples of stakeholders include—
The organization’s leadership (for example, the head of a department that is expected to
benefit from an internal project)
The client (for example, the bank that has hired a software development firm to design and
build an online banking system)
Customers/users (for example, the individual holders who will use that online banking
system after it is built)
Partners in accomplishing the project (for example, vendors and subcontractors who are
working for a prime contractor on any kind of project)
Special interest groups (for example, environmentalists with concerns about how a new
building may affect land use, or minorities interested in allocation of contracts)
Government regulators (for example, the U.S. Food and Drug Administration in relation to a
pharmaceutical 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 as many
other people within and outside the organization that perform on the project. The project
manager should cast a large and broad net to consider a project’s stakeholders and their
interests because it is better to “over identify” stakeholders than to leave some out. Best
practice suggests at least the following:
Influencers
Project management team
Project management office
Sponsor
User
Performing organization
Regulatory bodies
Several criteria can be used to determine who the project stakeholders are.
Consider the following:
Who gets the output from the project?
2 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 415.

© ESI International PMC:CPM:EN:000 ver. 2.0 15

Module 2: Project Initiation

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 on
their 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 this
fundamental step, you risk subjecting your project to a “unit veto.” In other words, any
stakeholder—no matter how powerful or seemingly insignificant—may be able to veto your
project, some completely and some only temporarily.

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

Project Personnel
There is a hierarchy in projects. The project manager, the project management team, and the
project team. The project manager is "the individual responsible for managing the overall project
and its deliverables."3 The project team is the group that is performing the work of the project
but may not be involved in the management of the project.

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

Understanding the Roles of Senior Management

“Senior management” normally initiates projects. Every organization has different ways of
determining who constitutes “senior management” and what authority and power they have.
Basically, they are your bosses, whether they are called program/portfolio managers, division
heads, vice presidents, managing partners, or sponsors. Since senior managers are key
stakeholders in any project, it is important to remember that the structure and culture of the
organization affect the project manager’s relations with senior management. Relations may be
very formal and hierarchical, very informal, or somewhere in between. A key relationship for the
project manager is that with the project sponsor, who provides financial resources—in cash or in
kind—for the project.
However your organization may define and label senior management, you need to understand
and use that information to your advantage. As a project manager, ask yourself two questions:
3 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 349.

16 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 2: Project Initiation

1. What do they need from me?

2. What do I need from them?
3. How do they want my project governed?
4. How do I escalate and resolve issues?
5. How does my project align with and support my organization's strategy?
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 throughout
the life of the project. They may need to approve the project plan, go to other divisions to help
you obtain resources, and so on. They need to be kept abreast of project status and know they
can trust you to get the job done. As many a boss has said, “I don’t like surprises.”

Senior management uses a philosophy to govern the projects that fall under their responsibility.
Governance is the rules, framework, and guidelines by which all projects in that organization
would be measured. Governance guidelines will be helpful to you in determining the
expectations of this group of senior managers. You should be familiar with your organizations
project governance guidelines. If your organization does not have them, do not worry, just work
with the project sponsor to help answer the questions.

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 general
factors 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 up
with them.)
Client requirements (We bid on a request for proposal [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, understanding
why the project has been initiated is critical to ensuring the project meets the needs it is
intended to satisfy. To reach the goal, you should know where the goal originated. The most
important thing to keep in mind is that projects are conceived and initiated for several reasons,
but, ultimately, they must support explicit business objectives.

© ESI International PMC:CPM:EN:000 ver. 2.0 17

Module 2: Project Initiation

Project Selection

Project Selection Overview

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

Best practices in project selection encourage objectivity, but selection is rarely purely
quantitative. Being fair to all potential projects is critical, but some things are just not quantitative
by 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 better
the selections of their organizations will be. If you are assigned to a project after the project
selection process has been completed, find out how objective the decisions were and how that
will influence your own decisions during the project.

Regardless of how it is accomplished, project selection should align with an organization’s

strategic intent and be a part of an organization’s balanced portfolio. If a steel manufacturer
needs to diversify to survive, choosing to make minor modifications to its old processes is likely
not a good project selection decision. It would be better to spend the effort on developing a new
line of business.

Selection Tools
Selection factors may be either quantitative or qualitative. Quantitative factors include the
following:
Benefit-cost ratio (BCR)
Present value (PV)
Net present value (NPV)
Payback period
Qualitative factors tend to focus on cost and include the following:
Stakeholder bias
Organizational fit
Risk analysis
Scoring models

18 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 2: Project Initiation

These methods are used to select projects by senior management; they are used by the project
manager when planning the project and selecting vendors and contractors during the
procurement process. There are many more selection methods, but they are beyond the scope
of 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 the
managers themselves. This is difficult to avoid, so it must be recognized.

Organizational fit addresses whether the project fits with what the organization wants to
accomplish, what the organization is able to undertake, and whether the project will further the
organization’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 company
only delivers software services. This is not to say that any variation from business as usual
should be avoided, but rather that senior management has (or should have) considered
organizational fit in its decision making. Many an organization has gone out of business by
diversifying too far beyond its core.

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

The scoring model evaluates various elements on several criteria by the portfolio/team
manager 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 latter
and determining the ratio:

BCR = Benefit / Cost

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

Like any mathematical formula, BCR has its limitations. It is important to remember that like
profit 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 much
lower profit margin (or BCR) than an exclusive boutique but makes much more money because

© ESI International PMC:CPM:EN:000 ver. 2.0 19

Module 2: Project Initiation

of its business volume. Like most formulas, BCR also ignores considerations that are more
difficult to quantify in cost terms. What is the monetary value of spending a little extra time to
ensure that a customer is happy with your product? BCR is even limited in the quantitative
sense in that it usually is not calculated in a way that takes into account the time value of
money. Present value (PV) and net present value (NPV) 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 would
see 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 having
whatever you purchased with it: a year of fun if you bought a mountain bike, interest if you
bought a bond, dividends if you bought stock, or profits if you used it in your own business. By
using such a simple example, this “time value of money” is easy to understand, but people often
lose sight of it or have trouble figuring it out in more complex situations.

The formula for PV makes this a simple process and tells you the value today of future 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 annual
interest rate for money received in a certain number of years or monthly interest rate for
money received in a certain number of months)
n = number of time periods from today (based on the same time measure used in
determining i)
This formula may look complicated, but it is a calculation that project managers actually use all
the time. It merely quantifies what you know intuitively. The earlier you bring money into your
organization, 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 and
paying you a $250 late fee for a total of $1,250. Is this a good deal? The answer depends on
your organization’s cost of capital. An organization’s cost of capital is calculated and
promulgated internally by the chief financial officer (CFO). Let’s assume your organization’s cost
of capital is 15 percent. 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.3225
PV = $945

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

20 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 2: Project Initiation

Net Present Value (NPV)

The real value of cash flow in a project is dependent on the currency amounts and the timing of
the transfers for both revenue and cost. NPV logic looks at both the inflow and outflow 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 PV of any two cash flow
projections. For example, in the project selection process, senior management may compare
the value of two different projects, and in the procurement process, the project manager 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 portion
of cutover support cost being charged up front. Coders, Ltd., is proposing development of a
program from scratch for $12,000 but is willing to accept equal payments over the life of the
project. Your firm’s cost of capital is 1.5 percent per month. The payment schedules are
summarized in the following table, and the question is whether the opportunity to defer payment
by using Coders, Ltd., adequately offsets that supplier’s higher price.

Off-the-Shelf, Inc., payment Coders, Ltd., payment

Month
schedule schedule

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 PV of each vendor’s proposed cash flow
and net them by calculating the difference between the two. The PVs of each vendor’s payment
schedule are calculated in the following table, based on the 1.5 percent per month interest rate,
using the formula PV = FV / (1.015)n to find the PV of each of the future payments.

© ESI International PMC:CPM:EN:000 ver. 2.0 21

Module 2: Project Initiation

Off-the-Shelf, Inc., payment Coders, Ltd., payment

Month
schedule schedule

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 price
of Coders, Ltd., and that selecting Off-the-Shelf, Inc., offers an NPV 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. NPV allows you to do this.

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

22 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 2: Project Initiation

Project Charter

Project Charter
The project charter is "a document issued and signed by senior management (in other words,
sponsor) that gives the project manager authority to apply organizational resources to project
activities and formally recognize the existence of a project." 1 In addition to having
documentation of what a project is to accomplish, the project manager should have
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 senior
management, 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 asked
to do.

The purpose of this document is to give the project manager and project team the support they
need to perform effectively. Inclusion of the functional managers as signatories to the charter
can 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 task
of supporting you. Depending on the corporate climate, this may be essential to success. Don’t
leave 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 include
any requirements that are known)
Project description
Summary (high level) of the preliminary budget and milestone schedule
Project approval requirements (signatory authority for approving project deliverables, and so
on)
Summarizes and clarifies, as a minimum, the preliminary boundaries of a project
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 manage
organizational resources

1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 343.

© ESI International PMC:CPM:EN:000 ver. 2.0 23

Module 2: Project Initiation

The 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 to
take 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 even
from project to project within an organization. In some situations, the project charter may be as
informal as an e-mail from the boss saying it is okay to proceed. In others, the project may have
to be reviewed and approved by the customer, and written authorization to proceed may have to
be 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 the
project.

The Right Start

The Right Start Overview

After a project has been selected to pursue, project initiation should start with a solid needs
assessment and then expand on it through the development of objectives, functional
requirements, and technical requirements.

Although different organizations will define these terms differently, for the purposes of this
course, they mean the following:
Needs/goals: Something required or wanted; a requisite; often somewhat vague
Objectives: Something worked or strived for; (which
should 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 to
accomplish; the objectives should be expressed in functional terms or desired capability and
explain what the project result will do

24 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 2: Project Initiation

Business requirements: These quantify the need of the business.

Quality requirements: These provide the acceptable level of quality.
Functional requirements: These relate directly to business and user functionality such
as business rules, reporting, and so on.
Nonfunctional requirements: These relate to the characteristics of the solution such as
availability, security, documentations, and so on.
Here is an example for a very simple project:
Needs/goals: We want/need to print PowerPoint® slides quicker because it takes too long to
get ready for our presentations.
Objectives: Reduce slide copy packet preparation time to less than 4 hours.
Requirements: We need a packet for the client that includes bound, clear-color copies of
presentation slides prepared within 4 hours after the presentation is finalized.
Quality requirements: The PowerPoint® slides must include graphics and images of
photo quality.
As each of these concepts is examined in more detail, it is important to remember that the
project manager must resist letting any stakeholders push too quickly for their preferred
technical requirements. Before technical specifications are addressed, there must be a clear,
mutual understanding of the real objectives and requirements. Otherwise, better solutions than
the one ultimately chosen may be overlooked. In the example above, many people would
immediately jump at buying a high-priced, fast printer when a low-cost contract with a copy shop
may be more cost-effective or reliable.

Needs Assessment
Effective needs assessment requires a recognition that needs exist on a variety of levels among
the various project stakeholders. In fact, projects often arise out of conflicting needs. This is
simply because everyone has different needs. For example, suppose a contractor has been
awarded 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 this
case, as often happens, needs often conflict, and the project cannot meet everyone’s needs.
Commuters prefer a multispan bridge to reduce commuting environmentalists prefer to preserve
the nearby marsh, for example.

In situations like this, senior management must understand and then balance or prioritize the
conflicting needs, often working with customers to help them sort out what they really need
(versus what might be “nice to have”). Collecting and documenting requirements is the process
of eliciting and documenting stakeholders wants and needs to meet the project objectives and
goals.” The project manager should help in the process whenever he or she is assigned early
enough to do so. The better the conflicts are addressed up front, the easier management of the
project will be.

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

© ESI International PMC:CPM:EN:000 ver. 2.0 25

Module 2: Project Initiation

decide.

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

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

Formulating Good Objectives

Objectives should be developed as an outgrowth of carefully considered needs. They should
represent 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 specific
task. Your company and client need clear objectives for the overall work; your boss and you
need clear objectives for the project; and you and your workers need clear objectives for the
task. Without this understanding, the likelihood of successful work is low, whereas the likelihood
of 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-constrained
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 to
objectives. It should, therefore, be expressed in functional or business terms or in terms of a
desired capacity. Functional requirements—what the customer needs to have happen—are
derived from the objectives. Technical specifications are how the project team develops to meet
the functional requirements.

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

26 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 2: Project Initiation

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 the
customer’s requirements.
2. The customers should not be coming up with the technical solution. That is one of the main
reasons 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 keep
customers 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 the
technical specifications map back to the objectives. If they do not, either the requirements or the
objectives need to be reworked.

Prototyping and Progressive Elaboration

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

Prototyping encourages change. It works well in fluid, highly conceptual efforts, and it prompts
the organization and the customer to examine and review a set of iterations. Progressive
elaboration, like prototyping, requires collaboration between the customer, project manager, and
project team. Progressive elaboration—commonly used in software development—involves the
incremental development of requirements. Requirements are identified early in the project and
refined as the project progresses. While the scope of the project does not change, the
characteristics of the project (and requirements) are progressively elaborated. Progressive
elaboration is very similar to rolling wave planning.

The objective is a happy customer; you can use the prototyping concept or progressive
elaboration to help customers understand what they want and will be happy with. Prototyping
and progressive elaboration should not be allowed to occur haphazardly. There must be a
common understanding of what the prototyping will entail and how progressive elaboration will
be conducted. Prototyping and progressive elaboration can include a variety of tools to achieve
good requirements:
Rough sketches
Scale models
Depictions (blueprints)
With each approach, the amount of time and the resources that should be expended on each
iteration should be determined. In addition, the approach needs to be a defined process and
needs to have written changes processed at each iteration that can be reviewed and decided
upon.

© ESI International PMC:CPM:EN:000 ver. 2.0 27

Module 2: Project Initiation

Requirements Document

Requirements Document
The requirements document represents key milestones in the elicitation, analysis,
documentation, and validation of requirements.

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

The requirements work plan, created by the business analyst, defines the work to be
accomplished during requirements elicitation, analysis, documentation, and validation. It must
be completed and approved before any requirements analysis work begins and it may become
a component of the overall project management plan.

Project Requirements Document (PRD)

The traceability matrix is used to show how requirements are mapped to both business needs
and the resulting deliverables. All requirements must be linked from the lowest level (resulting
deliverable) 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 in
detail for the project stakeholders. This document also is referred to by other names and,
depending on the organization, it may be called the requirements specification, requirements
document, or the functional specification.
Whatever it is called, the PRD is used to develop the design and technical specifications for a
product, system, or program. It provides definitive linkage to initiation and planning. It is a
written record of what has already been discussed and decided upon and serves as the road
map to direct the project team. Preparing a PRD also reduces the amount of rework on the
project.
The PRD is drafted by the project team and delivered to senior management and key
stakeholders for approval at the conclusion of the Initiation phase. This document should
include an overview of the product or system and the business needs that it addresses. The
overview also should include a glossary defining business and technical terms discussed in the
paper. This is especially important to ensure a common understanding of significant terms
among project stakeholders.
Other sections typically included in the requirements specification are the following:
Project objectives
Scope statement or statement of work (SOW)

28 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 2: Project Initiation

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 and
procedures that control the links between requirements and project objectives. You should be
able to trace a requirement from a source in the project—for example, an end user—throughout
the life cycle to a test at the end of the project.

Module Summary

Module Summary
Internal and external factors influence every project.
Senior management usually selects and initiates a project.
Quantitative methods and qualitative considerations enter into project selection.
Projects originate for many reasons, from product obsolescence to client requirements to
individual innovation.
Needs must be assessed, objectives set, and requirements defined so that specifications
can be set.
Customers define the requirements.
The project team develops the technical specifications.
A project charter spells out the roles and responsibilities of the project manager and key
members of the project team as well as input from other organizational agencies.
The PRD is the official document that describes the identified project requirements.
The requirements traceability maps the evolution of the requirements from the beginning to
the end of the project.

© ESI International PMC:CPM:EN:000 ver. 2.0 29

 Module 3: Project Planning

Module 3
Project Planning

Introduction

Module Overview
This module is the heart of this course, just as project planning is the heart of project
management. This module focuses on the crucial time at the beginning of a typical project,
when important planning functions occur. As the adage says "an ounce of prevention is worth a
pound of cure." So goes the planning of a project; you try to avoid problems in the first place,
rather than try to fix them once they arise.

Project Planning

Project Planning Overview

In a project’s life cycle, planning is most important and extensive planning phase performed
before implementation.

The processes that a project manager must master include planning the project scope through
the 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 all
these planning processes is the overall project management plan.

© ESI International PMC:CPM:EN:000 ver. 2.0 31

Module 3: Project Planning

Core Project Team

Core Project Team Overview

One of the first steps the project manager should take to optimize the effectiveness of project
planning is selecting a core group of key people, sometimes referred to as the project
management team, each of whom offers an expertise or specialty crucial to the project. For
example, in the case of an IT project, the core team may consist of the project manager, a
software engineer, a hardware engineer, and a finances expert. The number of people and
specialties will vary with the project.

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

Sometimes, you can identify and recruit whom you want; sometimes, you are “stuck” with
assigned team members. Obviously, it is to your advantage to have desirable team members in
mind and to get them assigned to your project. For example, if you realize that your project will
involve a lot of testing, ensure that you have a person on the core project team with that
expertise. Often, senior management needs to weigh in on your behalf to obtain such
resources, 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 matter
how talented they may be, you don’t want people who can only focus on their discipline. You do
want people who think “we’re all in this together.” If they are dispersed geographically, you

32 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

should 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 planning
that is about to be discussed. They are your planning helpers.

Scope Planning

Scope Planning Overview

The following are key terms related to planning the scope of a project:
Scope: "The sum of the products and services to be provided by the project." 1
Scope statement: A detailed description of the project’s deliverables and the work
necessary to complete the deliverables. It can be a documented basis for making future
project decisions and for confirming or developing a common understanding of project
scope among the stakeholders. As the project progresses, the scope statement may need
to be revised or refined to reflect approved changes to the scope of the project.
Define scope: Scope planning includes the process of progressively elaborating the work of
the project, which involves developing a written scope statement that includes the project
justification, the major deliverables, and the project objectives.

Scope planning is the most important 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 project itself, so it is not just a paper exercise. If you haven’t
planned well for the scope (recognizing that there will be changes along the way), how can
you accurately plan the time and costs involved? How can you manage customer
expectations? How can you monitor and control the execution of the plan? How do you
know what you should and should not do to complete the project?
Having outlined project scope in the project charter and having documented it in the project
requirements document (PRD), the Planning phase is the time to focus on project details. Has
the scope, which was provided in general terms from in the project charter, been well-defined?
Does it make sense? If not, the project manager must get clarification and understand how it
was developed. The scope statement that results from the define scope process will be one of
the basic elements for
the WBS.

1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 397.

© ESI International PMC:CPM:EN:000 ver. 2.0 33

Module 3: Project Planning

Work Breakdown Structure (WBS)

WBS Structure
The WBS is—
"A hierarchical structured grouping of project elements that organizes and defines the total
scope of the project" 1
"An increasingly detailed definition of a project component for each descending level of the
WBS"2
You should not conclude from this definition that the WBS is defined only to the deliverable
level. Neither resources or budget, nor schedule can be estimated with any accuracy unless the
WBS is taken to the task or work package level, wherever that level of detail may be. In many
cases, the project cannot be managed with a WBS that addresses only the deliverable level. In
other 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 the
concept, although it may be called by a variety of names in different organizations. The WBS
proceeds from the most general or “highest” level (for example, “build a plane”) through
intermediate levels to the most specifically detailed or “lowest” level. Each progressively lower
level will further break down the work described in the level above into pieces of work that
constitute the whole (such as from “build the wings” to “rivet aluminum to frame” and “polish
assembled wing”). The hierarchical organization of the WBS, in which larger elements are
broken down into smaller ones, is the key to understanding it. The WBS is not just a scattered
to-do list.

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

Key WBS Terms

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

An undefined work package is called a planning package. "A planning package is defined as
1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 470.
2 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 470.

34 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

logical aggregation of work within a control account that can be identified and budgeted in early
planning but is not yet defined into work packages.”3 This also can be considered a placeholder
for work 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 work
package 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 of
work (about two weeks).
Keep the goal in mind. If a work package looks like it will require you to micromanage, it is
too small. If it looks like it will make meaningful monitoring of work progress difficult or overly
general, it is too large.
Realize that if you need to consider part of the work package here and part there (as you do
costing, 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 work
package, it will not be accomplished. Obviously, however, there will always be individual
activities 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 discussed
shortly).

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

WBS Models
The WBS can take on multiple forms, and each format has its own advantages. The two most
common forms for a WBS are indented and graphic. The same information can be displayed in
different 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 system

3 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 313.

© ESI International PMC:CPM:EN:000 ver. 2.0 35

Module 3: Project Planning

1.1.1.2 Analyze components of current system

1.1.2 Determine future capability requirements
1.1.2.1 Perform gap assessment
1.1.2.2 Identify required changes
1.1.3 Develop alternative approaches
1.1.3.1 Identify alternative approaches
1.1.3.1 Analyze alternative approaches
1.1.4 Develop system requirements
1.2 Develop specification
1.2.1 Develop preliminary software specifications
1.2.2 Develop detailed software specifications
1.2.3 Develop preliminary hardware specifications

Graphic Format

The indented format offers several advantages: It is easy to include project details—it edits and
loads into major software tools such as Microsoft® Project. It lends itself to printed reports and
computerized 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 levels
and their responsible managers, and it supports the easy reference to specific work items.

Effective use of this numbering system requires that you follow certain rules. Because a
published WBS is distributed widely, there is no telling who might have it and reference to it.

36 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

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 smaller
components of the project roll up into larger ones. For presentation purposes, this format also
facilitates adjusting the depth of detail that is appropriate for various audiences.

Some people interpret information easier when they view it graphically; others prefer lists. It
depends on the project team and the customer’s needs. You may find that it is best to create
both: perhaps an indented format for your team so you can guide them in greater detail and a
graphic 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 subject
entries that identify the work output (for example, a construction project would have entries for
roof, windows, and so on). This deliverable-oriented approach can work for projects with mostly
clear, discrete outputs.

Others prefer brief verb-object entries that specify the tasks being performed (for example, lay
roof, install windows, and so on). In service-oriented cases, task-oriented wording better
describes the work. For example, a wedding reception project may have entries for coordinating
the 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 to
success is not the format chosen but the inclusion of all the work in the WBS, regardless of how
it 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 project
requirements. The WBS is the primary means for ensuring that the customer’s needs are met
and that only the work that the scope defines is considered in the project effort. Its benefits can
be 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 the
work 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

© ESI International PMC:CPM:EN:000 ver. 2.0 37

Module 3: Project Planning

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 is
necessary to plan, implement, and control the project. For example, although the WBS itself is
not a schedule or a network, it is a necessary first step and primary source of information for the
development of these tools.

How to Build a WBS

The top-down approach is the most effective approach to developing the WBS. This approach
breaks the whole project into progressively smaller pieces. This process begins with an
understanding of the purpose of your project. Based on that understanding, you break the
project down into its major segments of work. Then you break down the major segments into
their component parts and each component into its subcomponents. You continue this process
until 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 typically
reserved for projects where team members are extremely familiar with the work entailed for the
project. 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 organized
into phases or major components. After organizing this preliminary WBS, the project manager
should question the team about how to perform the project better. For example, what testing
activities can be developed and how can defects be identified and corrected? The project
manager 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 be
performed to create a Web site. After listing the tasks, the team members would then group the
tasks into categories. For example, a business analyst on the team might know how to define
user requirements for the Web site. A systems analyst might know the hardware and software
requirements. The team would then group these varied requirements into one broader category
called “Identify requirements.” The same approach would be followed until all the work package
level 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 capture
essential information about certain work packages without cluttering up the WBS. It is used to
document critical, detailed background information for specific work packages such as
assumptions, specific activities below the WBS level, assigned resources, preceding activities,
and succeeding activities. Its contents will vary depending on the information needs of the

38 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

particular project.

A WBS dictionary entry is not required for every WBS element—only for those that require
clarification. A rule of thumb is if you, the team members, and key stakeholders know what the
WBS item means exactly, then the element doesn’t need one. But, if it requires an explanation
(that is, edit report), then it is recommended that one is used (that is, prepare for production).
Project management 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
dog bowl. 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 team
member
Eliminates doubts about roles and responsibilities associated with the activity, what input is
required, and what needs to happen before and afterward
Is an outstanding document to use in bringing new people into the effort because it clearly
states what is expected in a particular piece of work
Can 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 and
plug 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 often
have their own templates, and past projects provide a good guide—obviously, those that are
similar will be most applicable.

But, you cannot just rely on what already exists. Your creative energy, along with that of the
project team, will be needed to develop a WBS, especially when you are dealing with first-time
projects or projects done in a completely new environment. Starting points such as templates
are great, but the core project management team will have to modify, expand, and adjust from
whatever 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 key
traits of projects is their uniqueness. No two projects are ever exactly alike.

© ESI International PMC:CPM:EN:000 ver. 2.0 39

Module 3: Project Planning

Translating the WBS into the Schedule

The primary purpose of the WBS is to identify all the work within the project scope, but in order
to 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 the
definition of the work itself. You need to break down the work packages into activities. It is these
activities that you will use to determine how long each package will take to perform, how much it
will cost, the resources it will require, and so on. This is the role of estimating. You cannot do
more planning without these estimates.

Estimating

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

The more you treat estimating as a deliberate process and not just guessing, the more likely you
will succeed. The basic concepts of estimating apply to all aspects of estimating. In other words,
gathering data to estimate time follows the same basic process as gathering data to estimate
cost.

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 project
planning. The validity of the estimates heavily influences the smoothness of the project and the
likelihood of being on target or suffering overruns. Project managers must not succumb to the
temptation to belittle estimating on the grounds that everything will change or turn out differently
anyway. In the first place, that’s not always the case. Carefully developed estimates help keep
projects on track by providing performance measures and permit more logical incorporation of
changes 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 changes
make sense and are working.

1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 151.

40 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

Good Estimating Practices

There are many levels of estimating precision; estimates range from ballpark to highly detailed
figures. The project manager should be clear about what kind of estimate can be made based
on the time and resources available and the precision of the scope information provided. Based
on that, the project manager must clearly communicate what kind of estimate is being provided
to those who ask for it.

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

To develop a detailed project budget, you need more accuracy and a correspondingly detailed
scope of work broken down into a WBS. That which the WBS has identified must now be
quantified before you can continue planning. In the WBS, you broke down the project into small,
assignable units called work packages. Each work package is a discrete piece of the project
that must be accomplished. These units must now be planned specifically and integrated
together 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 package
beyond the definition of the work itself. You need to estimate how long it will take, how much it
will cost, and what resources it will require. You cannot do more planning without these
estimates.

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

There are many good sources of information for estimates, including past experience that may
be 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 of

professional organizations. They retain valuable, historical data for their industries or areas of
interest. With Internet access, this type of data has become much more widely available. It is
also a good idea not to rely on any one source but rather to gather information from as many as
possible.

Estimating Techniques
There are many methods, tools, and techniques available to assist with the development of
estimates, including three-point estimates and Program Evaluation and Review Technique
(PERT). However, it is important to recognize that bottom-up estimating based on the WBS will
provide the most detailed and reliable results.

© ESI International PMC:CPM:EN:000 ver. 2.0 41

Module 3: Project Planning

Examples of cost estimating techniques include the following:

Wideband Delphi: This idea-gathering technique uses subject matter experts (SMEs) to
estimate the project individually. The individual estimates are averaged, discussion incurs,
and the SMEs will come up with a consensus on the estimate.
Parametric: This technique uses cost estimating relationships to express a mathematical
relationship between an item's costs and some underlying physical, operational, or technical
characteristic.
COCOMO 81 is based on the waterfall, top-down methodology. It relates level of effort
in person-months to project size in thousands of delivered source instructions. It has
three levels: basic, intermediate, and detailed. The basic level is often used to obtain a
rough order-of-magnitude estimate.
COCOMO II is based on object-oriented methodologies and is computerized. It has
three stages: application composition, early design, and post architecture. COCOMO II
requires estimates of code size (lines of code, function points) and applies factors such
as application complexity, familiarity of organization and programmers with the
technology and application, and level of expertise of programmers to produce an effort
estimate.
PERT: This early diagramming method was developed to mitigate risk in estimating
schedules. Basically, PERT can be used to create a “weighted” average. PMI® 2 refers to
PERT as a "beta distribution." Weighted averages tend to account slightly more for risk and
uncertainty. One of the defining traits of PERT is that it is designed to provide four estimates
for 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 deviation
calculation 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
18 weeks. However, the most likely time will be 16 weeks. (Keep in mind that instead of
duration, these can be estimates of costs as well.) What is a reasonable duration for
planning? Using the formula, you get—

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

Expected = 15.3 weeks
Three-point estimate: This estimate is a simple average of the optimistic (O), pessimistic
(P), and most likely (ML) scenarios. PMI® refers to this estimating formula as "triangular
distribution." It does not lend greater weight or credence to the most likely scenario; instead,
it allows each of the possibilities equal influence and, thus, pushes most analysis to later
and later estimates. As such, this approach is limited to a single, calculated value for
duration rather than confidence levels as afforded by PERT. The formula for the three-point
schedule estimate is the following:
Expected = O+ML+P/3

2 PMI is a registered mark of the Project Management Institute, Inc.

42 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

Historical lessons learned: Database information on previous projects is used 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 clarifies
the relationships that exist among the various work packages and it helps project managers to
manage the time side of the triple constraint. In an actual project, the order of planning
schedules, costs, and resources may vary depending on the nature and constraints of the
project. To some degree, these three types of planning are always done in concert with each
other because they are interdependent.

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

Considerations for Estimating Activity Duration

Regardless of the scheduling technique being used, the durations of activities in the schedule
must 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 being
discussed. Normally, estimates are converted from hours to days. For example, suppose a
development activity is estimated to take 48 hours. The time for the scheduled activity will be six
workdays if an eight-hour workday is being used. If a Monday through Friday workweek is being
used, that workweek can be built into the schedule, and the total calendar days elapsed will be
eight days.

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

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

© ESI International PMC:CPM:EN:000 ver. 2.0 43

Module 3: Project Planning

Network Diagramming
Network diagramming is a group of scheduling techniques that have several names and various
formats. However, the crucial trait they all share is that they expressly show the logical
relationship between work packages or activities. Each technique does this by using some
combination of nodes (which may be circles, boxes, or other shapes) connected by arrows that
indicate the order of performance that activities must follow.

The first network scheduling method to be developed was PERT, which was created in the late
1950s for the Navy’s Polaris ballistic missile program. In PERT, nodes are used to designate the
start and finish of activities, for instance, “Start testing guidance system” and “Finish testing
guidance system.” This makes PERT an “event-oriented” system. The event nodes are
connected 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 was
intentionally designed this way to make it suitable for research and development projects where
the 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 to
manage the construction of manufacturing facilities. Like PERT, CPM uses nodes to designate
the start and finish of activities and connects the nodes with arrows that represent the activities
being performed. However, instead of naming the start and finish events, CPM names the
activities, such as “test guidance system.” CPM is, therefore, an “activity-on-arrow” system that
is “activity oriented.” Unlike PERT, it was designed to use one estimate of each activity’s
duration because construction activities can be (and typically must be) estimated with a
reasonable degree of accuracy. Because all network scheduling methods can be used to
identify the critical path in the schedule, this form of diagramming has over the years come to be
referred to as the “arrow diagramming method,” whereas CPM is often used to refer to network
diagramming 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, and
connecting 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 to
each activity. Because PDM has become, by far, the most popular network diagramming
technique, it will be the technique used in the remainder of this text.

Regardless of the specific technique, network diagramming is primarily a project management

tool to be used in managing the performance and sequencing of the work contained in the WBS
work packages. The activities of the work packages are used in the network schedule for the
project. The network schedule integrates this information by showing how relationships between
activities affect their sequencing and determine specific activity performance dates for the
project. These schedules are not typically shown to upper management and rarely to customers
because they are better suited for use as working tools than as briefing aids.

Transforming a WBS into a Network Diagram

To 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.

44 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

These activities will become the network activities. The higher levels of the WBS are not
scheduled because they comprise the work packages, and the work packages were determined
to 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 and
the activity’s logical relationship to other activities in the schedule.

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

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

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

Nevertheless, it is also important to understand that multiple predecessors or successors for a

given 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 each
other; and all three must be performed before activity D. In that case, activity D would have
three predecessors, activities A, B, and C.

In certain situations, there are two special types of logical relationships that may be used: lag
relationships and lead relationships, or lag times and lead times. A lag is a forced amount of
time that serves a purpose but does not consume resources. For example, if you let a turkey
cool before carving and serving it, you have set up a lag time. Resources are not being
consumed, but time is passing. Lead time, the opposite of lag, is used when you need to
accelerate a logical relationship. For example, you need to wait for the turkey to cool, but in the
meantime, 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 Pass
Using the critical path method, you can analyze the network diagram using three techniques:

© ESI International PMC:CPM:EN:000 ver. 2.0 45

Module 3: Project Planning

Step Action Result

By path, start at the beginning, add all Duration of the

Forward Pass
durations together project

By path, start at the end, subtract all Float

Backward Pass
durations

By path, review each path for the least Critical path

Path Analysis
amount of float

After you have listed all your project activities and determined their durations and logical
relationships, you are ready to calculate the planned start and finish dates for the individual
activities (work packages) and for the project as a whole. This calculation is a process that
requires 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:

46 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

Calculating the forward pass on a network diagram will tell you the earliest time each activity
can start and finish, and the overall duration of the project. It is the process of adding activity
durations 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 will
start on day 0 and finish on day 5. Activities B, C, and D will each start on day 5, but adding
their different durations to the five days used for activity A will result in different finish times for
each 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 activity
D? Keep in mind that one purpose of the forward pass is to determine the earliest time each
activity can start and finish. Since both activity C and activity D must finish before activity E can
start, 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 example
illustrates the general rule for performing the forward pass through activities with multiple
predecessors. In such cases, you always add the activity’s duration to the finish of the
predecessor with the latest finish date.

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

Duration in
Activity Predecessors Start Finish
Workdays

None (project 5 0 5
A
start)

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 any
further 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 finish,

© ESI International PMC:CPM:EN:000 ver. 2.0 47

Module 3: Project Planning

and the overall duration of the project. As that statement implies, there are other times that
activities 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 be
performed from day 5 through day 20. Its 15 days of work could be performed as late as day 15
through 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 can
start and finish without delaying the completion of the overall project. Dates generated by
performing 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 “early
finish” dates.

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

Not surprisingly, the backward pass is a calculation that is the conceptual reverse of the forward
pass. The forward pass adds activity durations from the start of the first activity to the finish of
the last, successor activity by successor activity. The backward pass depends on the forward
pass to determine the last activity’s finish time and then subtracts activity durations from the
finish of the last activity to the start of the first, predecessor activity by predecessor activity. For
example, activity G will have a late finish of day 40 and a late start of day 35 (40 – 5). Activity F
will 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 of
one 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 can
start and finish without delaying the project. Since activity A must finish before the late start date
of each of the three activities B, C, and D in order not to delay the project, activity A’s late start
and finish times must be based on the successor activity that must start the earliest. Activity A
must, therefore, finish no later than day 5, based on the late start date of activity D, which was
determined using the durations of activities D through G. This example illustrates the general
rule for performing the backward pass through activities with multiple successors. In such
cases, you always subtract the activity’s duration from the late start of the successor with the
earliest late start date.

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

48 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

Duration in
Activity Predecessors ES EF LS LF Float Time
Workdays

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

A 15 5 20 15 3 10
B
0

A 5 5 10 10 1 5
C
5

A 10 5 15 5 1 0
D
5

C and D 15 15 30 15 3 0
E
0

B and E 5 30 35 30 3 0
F
5

F 5 35 40 35 4 0
G
0

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

Network Analysis
Analysis of a network reveals the duration of the project, the float, and the critical path. In any
schedule, activities must follow certain logical sequences. These sequences are defined by the
dependencies in the schedule (for example, activity A must be completed before activity B can
begin). Because of the various dependencies, many paths or chains of activities can be traced
through 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 on
time, or the project will likely be delayed (unless the time is recovered by performing successor
critical activities faster than planned or out of sequence).

Mathematically speaking, it can be called the chain of activities with the least float time (not
necessarily 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 dates
rather than on the latest early finish date. This is usually because of contract provisions and can
result in the calculation of negative float times when the project is behind schedule or smallest
float times, which are still greater than zero when the project is ahead of schedule. In such
cases, the critical path is more correctly referred to as the chain of activities with the least
amount of float time rather than the chain with zero float time.

© ESI International PMC:CPM:EN:000 ver. 2.0 49

Module 3: Project Planning

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

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

Another key reason for the project manager to understand the project’s critical path is to
improve decisions about resource allocations. Knowing where to put your most dependable
people may go a long way toward overcoming the potential delays to project completion that are
most 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 will
gradually be used up and they will become critical. Obviously, the more chains of critical and
near-critical activities there are, the more likely it is that the project will not finish on time. In
addition, the critical path only addresses the issue of work packages critical to finishing the
project 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 on
time. The project manager must not think that only critical path packages are critical to the
project outcome or that all noncritical path work packages are not.

Displaying Schedule Data

There are many ways to display information from project schedules. The graphic and tabular
displays used in applying the various network diagramming techniques provide several
approaches. In addition, there are several methods that are easier to understand, especially for
those 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 logical
relationships and other information characteristic of network diagrams, each of these simpler
displays can be generated from an underlying network analysis.

Gantt Charts
Gantt 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, and
progress on the project. They were first created by Henry L. Gantt in 1917 and are often
referred to as “bar charts” based on their format. With a network, you can determine float and
critical path. On a Gantt chart, you merely display when you want to do the various activities.

50 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

The dependencies between activities are not effectively illustrated and can be hard to verify as
well as the ability to show two sets of dates or even resource assignments. Even with some
weaknesses, the Gantt chart is one of the most familiar charts to many managers, and it is the
most understandable for people lacking formal management training, thus useful for high-level
reporting and decisions.

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

Project Calendars
Project calendars are another technique to use for depicting the schedule. This way of viewing
the schedule is intended to focus on daily activity. Thus, it allows one to see the specifics of a
particular 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 the
narrowest view of the schedule. To the contrary, calendar views often identify who is to do the
work.

Milestone Charts
Milestones are significant events in the completion of the project. They may be associated with
the completion of major activities, such as topping out the structure of a high-rise building or
completion of prototype reviews for the development of a software application. They may be
related to other matters such as funding points or contractually imposed progress dates. In any
event, 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 the overall project status at key points.

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

To effectively use milestones to check on your project’s status during the Planning phase, you
need 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?

© ESI International PMC:CPM:EN:000 ver. 2.0 51

Module 3: Project Planning

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 planning
process 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 should
eventually address cost issues at the work package level. This means planning all costs
associated 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? At a minimum, the following
inputs to cost estimating should be considered:
Culture, market condition, and software tools
Guidelines, processes, and procedures
Scope baseline
WBS
WBS dictionary
Project schedule
Roles and responsibilities matrices
Risk register
Direct and indirect cost components
Who can the project manager consult with in an effort to obtain cost information? There are a
variety of sources. They include outside estimators, those who perform the work, those with
experience working on similar projects, those who know the risks of the project in question, and
those who are responsible for the work.

Types of Cost Estimates

The 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 the
concept 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 or
75 percent above the estimate. Ideally, this sort of estimate is not developed until after

52 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

requirements have been identified; however, in reality it is often developed before then, which
can be dangerous and explains why estimates can grow dramatically from the first estimate to
the second.

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

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

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 is
between 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, such
as office electricity and heating.
Direct project costs typically include the cost of labor, materials, and equipment that are used in
completing the project. Labor includes both the cost of the organization’s own employees and
the 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 a
particular project is undertaken or not. Nevertheless, these costs must be allocated among all of
an 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 headquarters
expenses, fringe benefits, and depreciation. Marketing, sales, and research and development
are other common indirect expenses.

The project manager must always ensure that appropriate costs from all categories are included
in cost planning. Indirect costs are often misestimated or overlooked completely, but they are
real and must be accounted for.

Cumulative Cost Curve

Cumulative cost curves like the one below can be used to graphically depict the total planned
project expenditures (the budget) over time, based on the schedule and cost planning that has
been accomplished using the WBS. Time periods are measured along the X-axis and
cumulative costs expended at any particular time are measured along the Y-axis. A line graph is
plotted by connecting the cumulative cost points of the project during each time period over the
entire duration of the project. Since plotting project costs by time period in a noncumulative
fashion usually produces a bell curve with higher expenditures during the middle of the project

© ESI International PMC:CPM:EN:000 ver. 2.0 53

Module 3: Project Planning

and lower expenditures at the beginning and end, the cumulative cost curve usually takes the
shape of a somewhat flattened “S.”

During project execution, these graphs can be used in conjunction with earned value (EV)
analysis (which will be addressed in the next module) and can, thereby, show the project
manager how much 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 actual
cost curves can be tracked on the same graph for comparison purposes. However, the project
manager must be careful to ensure that people do not misinterpret the cumulative curve due to
lack of understanding of the underlying details. For example, when actual costs are plotted
against planned costs, they may see variances between the two curves and yet not understand
the actual events that underlie them. For example, if an unexpected opportunity arises to make
a major purchase ahead of schedule in order to get a significant discount, it will look like an
overspend, when in actuality, the project is saving money.

In addition, although they are cost curves, they cannot be understood as a way to evaluate
costs in isolation from the other two factors of the triple constraint, the project status in relation
to scope and schedule. If more money has been spent than budgeted, but the project is further

54 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

along, then that can be a good thing! On the other hand, you might have spent less than you
planned 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 resources
that will be required to complete the project. The resources required for any project include
personnel, equipment, and facilities. You can plan for the office space, sufficient people, and the
most up-to-date technology, or you can get stuck with what is offered you. Which would you
prefer?

Senior management and your core project team play a particularly significant role in resource
planning. In many organizations, senior management must go to other divisions of the company
on your behalf to help you enlist resources. If you need to use an outside contractor to perform
part of the project, your organization’s contracting officer will play an important role in your
project. Moreover, the core project team, through its own contacts and experience, is often your
best 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 around
your organization (for example, the software development manager for programmers, the office
administrator for clerical help, the facilities manager for office space, and so on). Regardless of
whether you work with them directly or with the help of senior management, it is ultimately
through them that you obtain the resources you need to get the job done. A good relationship
with functional managers can make project management life much easier.

Although all resources are important, in the final analysis, the people who work on the project
usually will make it succeed or fail. As a project manager, you need to get the best people you
can and plan how to use them most effectively. To do this, resource planning should identify the
skills needed for the project and when they are needed. For example, in many cases a project
won’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 resource
planning issues. Examples of these tools and techniques include—
Roles and responsibilities
Resource Gantt chart
Resource loading table
Resource loading histogram
Resource leveling

© ESI International PMC:CPM:EN:000 ver. 2.0 55

Module 3: Project Planning

Roles and Responsibilities

A resource/responsibility , also referred to as a roles and responsibilities , is an uncomplicated
way of showing which “resource” (person) is responsible for each task or group of tasks. It is
simply a grid with people identified along one axis and tasks along the other. Each person’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.

Roles and Responsibilities

Donna Duane Gina Jane Jerome Mark Pat Paul

Tasks
(role) (role) (role) (role) (role) (role) (role) (role)

Project R I C A
management

Requirements A C R I

Software A C
development

Mainframe I A R
consulting

Client/server A R
development

Infrastructure R C A

R= Responsible
A = Accountable/Approve
C = Consulted
I = Informed

A good serves several purposes. It aids your thought process in viewing what resources and
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 duties with the
new people because it depicts the duties left open by the departed individual. What it does 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 required
to perform them. Normally, the Gantt chart is a cascade of activities in chronological order by
start date. In this case, the activities are first grouped by their assigned resources, then by
chronological 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 of
their employees and to determine staffing possibilities for upcoming projects.

56 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

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 requirements
during each time period (usually weeks) and for the entire project. Once the resource loading
table 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 by
time period. Time periods are measured along the X-axis, and quantities of resources are
measured along the Y-axis. The amount of resources to be used according to the project
schedule during any given time period is depicted by a vertical bar, and the taller the bar, the
greater the amount of resources. Normally, the resources assigned are personnel, but this tool
can also be used for planning equipment used on an appropriate project, such as a highway
project requiring many pieces of heavy construction equipment. The end result is a vertical bar
chart that shows resource allocation over the life of the project.

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

Resource Leveling
Resource leveling is the technique that addresses the kinds of scheduling and resource
adjustments just mentioned. Resource leveling is defined broadly as any form of network
analysis in which scheduling decisions (start and finish dates) are driven by resource
management issues, such as limited resource availability.

With limited resource availability, the problem is that you simply do not have enough bodies to
do all the activities on their scheduled performance dates. With difficult-to-manage changes in
resource levels, you are trying to avoid the inefficiencies and resulting cost increases associated
with 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 that
applies 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 their
performance, the overall completion date need not be delayed because of scarce resources.

© ESI International PMC:CPM:EN:000 ver. 2.0 57

Module 3: Project Planning

Risk Planning

Risk Planning Overview

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

Risk Identification
A risk event is “discrete occurrence that may affect a project positively or negatively.”1
Identifying and analyzing risks takes place throughout the life of the project: They are factors in
project selection, as discussed previously; they become part of project planning and are
ongoing parts in project execution and control.

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

As you plan, you are not necessarily planning for the very worst-possible scenario, but you don’t
want to ignore some of the bad things that might happen (such as delayed permits, procurement
delays, 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 or
condition. Events such as a quicker-than-usual permitting process or the sudden availability of
your company’s best engineering whiz can boost your project performance if you are prepared
to take advantage of them. If you plan for some good risks, you will look good when you
capitalize on them. However, unlike the bad risks, the good ones tend to go away quickly if they
are not seized or acted upon.

1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 386.

58 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

Risk Probability and Impact

There 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 team
should prioritize the risks. Prioritization is an essential step because you are not likely to have
the resources to prepare for everything and because some potential events are too low in
priority to be worth planning for.

Risk probability may be quantified mathematically by determining that there is a certain percent
likelihood of a particular event occurring. Or, if there is no rational basis for percentage
estimates, 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, a
specific 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 it
should be the product of probability and effect estimates. If you have been able to quantify the
probabilities and effects of risks in percentage and cost terms, then you should be more
interested in a $50,000 risk with a 50 percent probability than you would be in a $100,000 risk
with 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 give
top priority to high-probability risks with high-potential effects. You should give less priority to
risks with a combination of high and low probability and effect. Therefore, you should not waste
your 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 of
identifying, quantifying, responding to, and controlling the risks inherent in a project. In other
words, 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 enabler
to that process. Risk management considers issues that could possibly affect that process as it
unfolds; project management looks at the process itself. Risk management looks at how we can
avoid 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 our
objective.

ESI’s Risk Management Model

Both PMI® and ESI International have developed risk management models. ESI’s eight-step
model is based on practical experience and best practices.

© ESI International PMC:CPM:EN:000 ver. 2.0 59

Module 3: Project Planning

ESI's Risk Management Model consists of the following eight steps:

Plan for risks that may impact the project.
Identify risk events and sources.
Analyze the impact and probability of each identified risk.
Prioritize risk to identify those that have the greatest impact on the project.
Plan the risk response for each prioritized risk.
Execute the risk response when the risk occurs.
Evaluate the corrective actions taken as a result of executing a risk response plan.
Document the risks that have occurred, the response taken, and effectiveness of the
response for future reference.

60 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

Risk Response Strategies

After you have identified the risks that are worth planning for, you have to decide what you are
going to do about each of them. Both threats and opportunities require response strategies. The
following applies to negative risks or threats:
Accept—After thorough analysis of the other ways to respond to a risk, you may reach the
conclusion that not changing the project plan is the most sensible approach of all because
any other response has costs that exceed its benefits or because the risk is an unavoidable
cost of doing business. Acceptance of a risk should include consideration of a backup plan
or contingency plan, including the use of a management reserve in either the budget and/or
the schedule to accommodate the risk event if it actually occurs.
Mitigate—Risk mitigation means reducing the probability or consequences of a threat to an
acceptable 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 or
build 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 examples
of this sort of approach being applied through contract provisions with third parties that are
involved in projects. Insurance coverage requirements, or “hold harmless” clauses, shift
threats of physical or personal harm. Clauses prohibiting or liquidating damages for delayed
completion transfer threats of project delays. Even compensation terms involve the transfer
of threats because a fixed-price contract makes the contractor suffer the consequences of
cost 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 condition
or to protect the project objectives. This may entail eliminating nonessential aspects of the
project scope that put the entire project in jeopardy. For example, if several vendors offer a
key project component and the preferred vendor is financially unsound, you may choose to
use a less attractive product from a more reliable source to avoid the threat of vendor
bankruptcy and nonperformance.

Like negative risks or threats, positive risks or opportunities must be planned for. The following
are the responses to opportunities:
Accept—Is the same as for threat. Acceptance of an opportunity should include the use of a
management reserve in either the budget and/or the schedule to seize the opportunity if it
occurs.
Enhance—Like mitigate on the previous page, enhancing modifies the size of the
opportunity. That is, you can increase the probability and/or the impact by identifying and
maximizing the key drivers. For example, to enhance the opportunity of producing a
superior product, 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 is
realized by attempting to eliminate the uncertainty associated with that opportunity. For
example, if several vendors offer a key project component and the preferred vendor is one
you would like to establish a sound relationship with or create business with, you may
choose to use that product. This would help to ensure future business.

© ESI International PMC:CPM:EN:000 ver. 2.0 61

Module 3: Project Planning

Share—Like transfer on the previous page, sharing allocates some or part of the ownership
to a third party who is most capable of capturing the opportunity. Sharing of the ownership
of intellectual property between the expert organization and your organization may help to
capture 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 your
project planning. Keep reviewing your risks, their priorities, and your response strategies during
the course of the project because they can change over time.

Procurement Planning

Procurement Planning Overview

Project managers are called on much more often to procure goods, services, and labor for their
projects from outside vendors and contractors. Because procurement and its legal ramifications
can be complex, it is best to work with professionals within your organizations to be sure that it
is performed properly. However, knowing the fundamentals of procurement will help you make
good procurement decisions that can be implemented correctly with the assistance of your
organization’s procurement professionals.

Make-or-Buy Decision
Before the project manager undertakes procurement related to any project component, a
fundamental question must be answered. The question is whether to use an outside vendor or
contractor to perform the work or provide the materials or equipment instead of accomplishing
the 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 using
chemists and lab technicians who are employees. Another would be studying and modifying
existing business processes using a team of employees without incorporating any new
technology or equipment. However, the larger and more complex a project is, the less likely it is
that 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 a
discrete, short-term effort?

62 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

Contract Type Selection

If the decision is to buy the solution from outside the organization, an appropriate type of
contract pricing should be used. There are three broad categories of contracts from which to
choose. 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 a
fixed total price for a well-defined product. For example, a school may award a fixed-price
contract to a company for the purchase of 200 desktop computers with specific operating
systems, processors, and amounts of memory, all to be delivered by a certain date. This type of
contract puts the risk of efficient and proper performance on the seller. To the extent that the
product is not well-defined, both the buyer and seller are at risk when using a fixed-price
contract. 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 the
buyer to ensure such costs are covered.

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

Time-and-materials (T&M) contracts are hybrid contractual arrangements that contain aspects
of both cost-reimbursable and fixed-price agreements. They resemble cost-reimbursable
agreements because they are open-ended and the full value of the arrangement is not defined
at 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 is
unlikely to miscalculate this component of the unit price for labor, T&M contracts typically place
performance 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. This
would only be the case when the buyer chooses the seller through some sort of a negotiated
procurement, such as a request for proposal, not when the buyer solicits offers for competitive
bids with the promise of award to the responsible and responsive bidder offering the lowest
fixed price.

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

© ESI International PMC:CPM:EN:000 ver. 2.0 63

Module 3: Project Planning

Preparing Procurement Documents

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

The terms "bid" and "quotation" are generally used when the source selection decision will be
based on price (as when buying commercial or standard items), while the term "proposal" is
generally used when other considerations, such as technical skills, technical services, and
technical approach are paramount. Common names for different types of procurement
documents 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®1”)
or subjective (for example, “The proposed project manager must have documented, previous
experience with similar projects”). Evaluation criteria are often included as part of the
procurement documents so that the sellers will understand how the contract award will be
determined.

Statement of Work
Contracts typically include a statement of work (SOW). The SOW is essentially the contractual
version 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—specific, measurable, agreed-upon, realistic, time-constrained)
requirements for the SOW is a must. It is the project manager and core team’s responsibility to
provide a clear description of requirements and measures of success in the SOW.

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

Selecting the Contractor

When you do decide to hire a vendor or contractor, you have numerous issues to address. One
of the first is the source selection process. You must determine the evaluation criteria that you
will use to select the vendor or contractor. Some general considerations include cost, reliability,
1 PMP is a registered mark of the Project Management Institute, Inc.

64 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

and timeliness. If you are procuring materials, you will be interested in factors such as
appropriate 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 expertise
and experience for the job as well as an excellent reputation.

Another aspect of source selection that you must address is what procurement documents will
be used. Will you be creating them from scratch, or will standardized procurement documents
be used, and if so, what are they and where do you get them? Will you be publishing an
advertisement for lump-sum bids in industry publications, or will you be sending a request for
technical and price proposals to a short list of prequalified contractors? What type of contract
will 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 selection
process. For example, what responsibilities does the project manager have in procurement and
solicitation? How will multiple contractors be managed? Will there be one prime contractor who
manages many subcontractors, or will there be many prime contractors that the sponsoring
organization’s project manager manages directly? And, how will procurement be coordinated
with the rest of the project?

Finally, different organizations have different approaches to dealing with procurement, from a
very formal and centralized process in which a contracting office plays a key role to one in which
the project manager has complete discretion. Make sure you understand how your organization
handles 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 the
project. The issue in communication planning is how information will flow during the project. The
more visible the project is, the larger the communication task will be, but every project has
various target audiences.

The first question should be who receives what types of information, or who needs to know
what. For example, detailed information like the WBS, project schedule, and cost plan broken
down to the work package level may be provided to all project team members for the entire
project scope or for those portions of the work in which each member is involved. Senior
management 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. Will
you 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 the

© ESI International PMC:CPM:EN:000 ver. 2.0 65

Module 3: Project Planning

project record and how will you store it? Will you keep hard copies of paper in file cabinets or
maintain an electronic archive? And finally, how will people be able to access the information
after 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 project
constraints. If you try to produce something in less time with fewer resources than would be
called for by a reasonable baseline plan, the scope of the project will be reduced either in terms
of the quantity or quality of the project deliverables.

You can best avoid this result by emphasizing quality during project planning and building
quality control and quality assurance processes into the project's costs and schedule from the
beginning. 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 them
promptly 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 of
your 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. The
project plan provides the road map for the Implementation phase of the project. In essence, it
summarizes all the planning you have already done:

66 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

Now, it is a question of putting them all together and making sure everything is coordinated. You
should 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 human
resource planning calls for personnel who make $30 per hour. Without a well-coordinated
project 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. The
important thing to remember is that they do not take the place of using your head and your
talents!

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

The second class of software is a newer family of programs specifically designed to help with
managing 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-consuming
tasks, 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 and
calculations will be made, but they will not do anyone any good. In short, these tools can be
very helpful, but you must know how to use them and know how to interpret their output.

© ESI International PMC:CPM:EN:000 ver. 2.0 67

Module 3: Project Planning

Project Baselines

Project Baselines Overview

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

Organizations have different ways of requiring baselines to be captured and presented. This is
not a major issue though, because most of the work of setting up the baselines has already
been done in project planning. Some of the typical baselines include the following planning
outputs:
Scope: scope statement, WBS
Cost: cumulative cost curve, project budget
Schedule: network diagram, Gantt chart
During the Implementation phase, the project manager uses the baseline information already
generated to measure and control the performance of the project team. In doing so, it is
important not to give one baseline undue precedence over the others. For example, too much
emphasis on time may drive up costs, whereas too much emphasis on cost control may
lengthen the schedule. The project manager can make smart decisions based on the complexity
of the project only when the compound effect on the multiple baseline references is considered.

Who Uses Baselines?

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

Management’s role is normally to review progress against baseline requirements and, if

necessary, 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 the
accounting 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 a
workable set of baselines and seeing that they are carried out. The project team’s role is also to
perform, and like the project manager, team members must be concerned with all baselines.

68 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 3: Project Planning

The project manager must communicate to the team and other stakeholders that the project
performance is judged against the baselines. Project performance does not change the
baselines; rather, the baselines help project managers to understand the variations so they can
make necessary project changes.

Module Summary

Module Summary
The core project team is involved in project planning.
Understanding the scope is key to project planning.
A WBS is a hierarchical approach to breaking down the scope of a project to facilitate
planning for its completion.
Although a WBS may have different formats, levels of detail, and ways of being created, the
work package is always the bottommost level.
Work packages break down into activities. It is these activities that are used to build the
network 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 component
work packages, including critical path and float times, and it may be presented in many
formats.
Cost planning determines the direct costs that the work packages require as well as the
indirect 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 planned
for through the appropriate response strategy.
Procurement planning involves deciding whether to procure outside services and how to
choose 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 other
baselines.

© ESI International PMC:CPM:EN:000 ver. 2.0 69

 Module 4: Project Implementation

Module 4
Project Implementation

Introduction

Module Overview
Two processes, executing and monitoring and controlling, are used predominately during the
Implementation phase 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 the
resources, issues, and the project so that the team can and will do the actual work in a
successful manner.

Project Implementation

"Executing" and "Monitoring and Controlling"

Project implementation is the third phase of our generic project life cycle. This is where the bulk
of the work for the project takes place. During implementation, the project team develops the
solution while the project manager coordinates team members, forecasts future trends, looks for
potential risk, and monitors and measures team and project performance. The project manager
is also responsible for managing stakeholder expectations and dealing with changes and risk
events.

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

As a project manager, during the Implementation phase you will find you will use predominantly
executing and monitoring and controlling of the process groups.

To perform these functions properly, you will need to be able to use a variety of project
management skills. They will include interpreting project baselines, aligning project team
performance with stakeholder expectations, responding to requested changes and risks as they
occur, assessing project performance, applying earned value management (EVM) to determine
project performance and future trends in performance, and completing and presenting
performance reports.

© ESI International PMC:CPM:EN:000 ver. 2.0 71

Module 4: Project Implementation

Assessing Project Performance

Assessing Project Performance Overview

Assessing performance is critical to project success and should be performed throughout the
Implementation phase in two general ways. First, the project team should continuously monitor
actual performance by comparing it to scope, time, and cost baselines developed during the
Planning phase and should adjust the project plans throughout performance, as necessary, to
cope with actual results that vary from the plan. Second, senior management and customers
should periodically evaluate planned versus actual project status and require the team to make
adjustments, when necessary, to assure satisfactory results. A key tool for assessing
performance is the concept of EVM.

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 EVM analysis. Numbers will never tell you
everything, but earned value (EV) provides you with an objective, mathematical approach to
viewing just a few numbers that correlate a variety of project baselines. EVM is not the only
monitoring tool; there are many others, but they generally focus on single aspects of the project.
EVM is the only tool that 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 work done—to assess how the project is performing.

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 50
percent complete today has a PV 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.

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 EV of $300 (.60 x $500).

72 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 4: Project Implementation

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

All three of these quantities are depicted on the following chart. Notice that the PV curve is
actually a cumulative cost curve, which was one of the outputs of the cost planning process
discussed in Module 3.

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

Comparing the three curves will tell you whether you are facing good or bad news. In the
example 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 to
completing the first step in the performance monitoring process—comparing actual results
against baselines. Now you need to determine the variances between the two.

Variances are simply the differences between what you have accomplished and what you had

© ESI International PMC:CPM:EN:000 ver. 2.0 73

Module 4: Project Implementation

planned to accomplish. When you know the three basic EV elements, it is easy to determine
cost variance (CV) and schedule variance (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 of
schedule), and negative values indicate poor performance (a cost overrun or being behind
schedule). A variance of zero means you are right on the schedule or cost baseline. Don’t
expect that to happen very often!

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

SPI = EV / PV

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

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

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

BAC: What is the total approved budget for all activities (including any overhead allocations) in a
project?

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 to
monitor performance, nor should it be. It just happens to be a powerful tool for packing a lot of
information into easily understood numbers.

For example, notice that the SV uses monetary measures to evaluate scheduled progress. This
can lead to misleading, if not downright bizarre, results. Consider a project with some
procurement activities that are major cost components but have months of float time. If you take
advantage of an unexpected discount and purchase these components well ahead of schedule
while less costly critical activities are falling behind, your SV may show you are “ahead of

74 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 4: Project Implementation

schedule,” although your network diagram forecasts significantly late project completion unless
corrective measures are taken.

Second, you must not forget the final step in performance monitoring—reacting to what you
have learned—regardless of how you determine variances from your baselines. You may need
to 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. In
addition, you may need to run interference with customers and stakeholders if you encounter
indications of scope creep.

Let’s take for example, an application development project that is expected to cost $40,000 and
take five months to perform. To keep it simple, assume that the costs will be expended at the
rate 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 is
50 percent complete. Using that example, the following measures of project CV and SV can be
calculated:
CV:
CV = EV – AC
CV = (50% x $40,000) – $18,000
CV = $20,000 – $18,000
CV = $2,000
SV:
SV = EV – PV
SV = (50% x $40,000) – $15,000
SV = $20,000 – $15,000
SV = $5,000
CPI:
CPI = EV/AC
CPI = (50% x $40,000)/$18,000
CPI = $20,000/$18,000
CPI = 1.11
SPI:
SPI = EV/PV
SPI = (50% x $40,000)/$15,000
SPI = $20,000/$15,000
SPI = 1.33

© ESI International PMC:CPM:EN:000 ver. 2.0 75

Module 4: Project Implementation

Assessing Project Status

It is easy to focus on the more cut-and-dried issues related to time and money when assessing
project status. From the formulas described in preceding sections, it is clear that a key aspect of
assessing project status is the evaluation of the worth of the work completed to date, or its EV.
Done correctly, this will be accomplished by a review of the status of work accomplished on
each of the work packages in the work breakdown structure (WBS).

This review is almost always done based on a percentage of completion so that the percentage
complete can be multiplied by the total value of the work package to determine its individual EV.
How to judge percentage complete for partially completed activities is always problematic
because it can be subjective. Using one of the following fixed formulas can help remove 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 is
completed, it is reported as 100 percent complete.
20/80 rule: This is a more conservative approach that reports 20 percent for the start of a
task.
0/100 rule: This is the most conservative approach. It assumes that a task does not earn
any 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 are
other 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 and
agreed upon with the client. Are you meeting the WBS? This review especially gets important as
changes occur and the WBS is changed.

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

One simple evaluation tool is a resource leveling chart that compares actual resources used
with what was planned. This is done by starting with a resource histogram developed during the
resource 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 project
performance.

Corrective Action
There are many clues that corrective project action is in order, starting with significant SVs and
CVs. Others include long delays in resolving problems, excessive project personnel turnover,
persistent quality control problems, and large numbers of changes or poor change control.

Corrective actions may take a variety of forms as well. You may be able to change task
relationships and perform critical path activities in parallel if you can accept increased risks. You
may be able to add more resources to critical path activities, but this usually decreases
efficiency and increases costs. It may be possible to move resources around and assign more

76 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 4: Project Implementation

experienced personnel to critical activities. You may decide to try a more efficient method, or a
better technology, but watch for time lost on the learning curve! Bringing in outside resources
may be useful if the quality or quantity of resources needed is not available within the
performing organization.

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

The important thing to remember when contemplating corrective action is the triple constraint
and the effect of each solution you consider. Implementing corrective strategies essentially
results in replanning the project. The project plan, including the WBS, the schedule, and the
cost estimate must all be revised as the project manager performs a balancing act in an effort to
bring 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 is
asked to perform faster than would normally be expected from the start. How can a project
manager accelerate a schedule in order to deal with such situations? Can the duration of a
project ever be shortened?

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

Crashing is defined as “taking action to decrease the total project duration by adding resources
(human and material) without altering the sequence of activities. The objective of crashing is to
obtain the maximum schedule compression with the least cost." 1

Crashing is typically done by adding resources to the project. The resources must be paid for
and often become less efficient when working under accelerated schedule requirements, thus
increasing the cost that the definition says to minimize.

Based on the project constraints, you know that crashing is not always possible and that it is
sometimes possible only with added resources. For example, it can take one person three days
to paint a house, but the same task can take two people two days. Besides incurring an
additional day’s wages, you will need more paintbrushes, more drop cloths, and maybe a
second ladder. But, there’s a limit to time savings, even when you continue to incur the costs
associated with additional resources. If you assign 50 people to paint, they’ll run into each other
instead of finishing quicker. The law of diminishing returns is alive and well.
1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 108.

© ESI International PMC:CPM:EN:000 ver. 2.0 77

Module 4: Project Implementation

Fast-tracking is defined as “compressing the project schedule by overlapping activities normally

performed in sequence, such as design and construction.” 2

The primary drawback to fast-tracking is the increased risk incurred through overlapping. The
potential for errors and rework increases and may have an adverse effect on both scope (in
terms of quality) and resource costs. Using the example in the definition, you may encounter a
fundamental design problem after some degree of construction has been completed, and
expensive 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 almost
always a time crunch in the real world of projects, but sometimes, the critical path tells you from
the start that you have to make some adjustments. For example, you know up front that a
dormitory must be ready in early August, or a store must open in time for the holiday shopping
season. As a project manager, you often may have to speed up your projects. The important
point is to examine the various options for accelerating the work and consider the ramifications
of cost and risk.

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

Besides standard content and timing, it is wise to use a standard format for performance
reporting. Doing so promotes clarity of communication and facilitates the tracking of progress
and issues from one report to the next. A good, standard approach for almost any subject
matter is to cover the following:
Current status (that is, progress since the last report, significant problems encountered, and
action taken or planned)
Forecast progress (or what you expect in the near future, anticipated problems, and
possible recommendations 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, and
conference calls, can all be used to tell stakeholders what they need to know, but do not go
overboard.

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

2 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 162.

78 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 4: Project Implementation

Project Evaluation
Project evaluation is a periodic process that may be done every month, quarter, or whenever it
is most appropriate. For example, there is a form of evaluation conducted after a project is
closed called a project audit. It gives you a chance to step back and figure out how your project
is performing. Beginning from the start of the project, you need to do it on a regular basis
because it is much easier to modify what you are doing with six months left in the project than it
is 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. In
evaluating the project, you should focus on the big-picture issues and trends. You should not
invest 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 not
nearly as important as knowing the overall budget trend and what it predicts for the final project
outcome. For example: Instead of worrying about being $2,000 over budget on a $50,000
project, 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 stick
to 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 of
action.

In performing any project evaluation that reaches the question of whether the project or any part
of it should be terminated, you must understand the concept of sunk costs. Sunk costs are what
you have already spent and cannot get back. When a task or project is costing more than
expected, people commonly decide to abandon it because they don’t want to continue to “throw
good 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 up
on sunk costs. Because you do not have the ability to reuse already expended funds, they
should not affect future decisions. If you end the endeavor, that money is spent. If you continue
the endeavor, it is spent. Either way, the spent money is sunk into the project and cannot be
changed.

What does matter is the money you can still control. If the project has spent $100,000 and
needs $10,000 to finish, you need to ask what the payback will be for spending that $10,000 on
the 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 the
smarter effort. Either way, the $100,000 is gone and cannot be recovered.

© ESI International PMC:CPM:EN:000 ver. 2.0 79

Module 4: Project Implementation

Managing Change

Changes
Changes in the project plan don’t come just from the customer. They can come from just about
anywhere: from the customer, the team, the project manager, senior management, or outside
regulatory stakeholders. Regardless of their sources, project managers need to be prepared for
changes because many are unavoidable and many are valid and in everyone’s interest to
pursue. 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 the
project plan. A configuration management plan should be included in the project plan, especially
on technical projects. Specific formats should be established that call for a review of the effect a
change may have on cost and time as well as scope and quality. Do not let comments in casual
conversations 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 has
authority to direct changes and to what extent.

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

As project manager, you must remember that changes may occur to any aspect of the triple
constraint and that changes in one aspect may have effects on another. The customer may
want to increase or decrease the scope of the project. Normally, that will have a corresponding
effect 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 by
causing additional expenses, such as overtime work. The point is, when you see a change
coming, evaluate what it does to all aspects of the triple constraint.

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

Change Control Board (CCB)

The project plan should provide for a CCB to review and approve or reject proposed changes on
a project. The CCB is “a formally constituted group of stakeholders responsible for approving or

80 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 4: Project Implementation

rejecting changes to the project baselines."1 Of course, all decisions and recommendations
should be recorded and become part of the historical record of the project.
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 as
similar 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 additional
requests, update the traceability documentation, and route the information appropriately. If
the change is significant, it may need to go through configuration management.

Configuration Management (CM)

A Configuration Management (CM) system is "a process used to apply technical and
administrative direction to document the functional and physical characteristics of an item or
system, control any changes to the characteristics, record and report the changes and their
implementation status, and audit the system to verify conformance to the requirements."2
It includes the documentation, tracking systems, and defined approval level necessary for
authorizing and controlling changes. In most application areas, the configuration management
system includes the change control system.

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

CM is intended to improve project team productivity and capacity. CM is a formal discipline to

provide methods and tools to identify the system developed, establish baselines, control
changes to these baselines, record and track status, and audit the product. It helps ensure that
the integrity and continuity of the system are recorded, communicated, and controlled. CM is
normally 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 controlling changes to
project baselines (scope, cost, schedule, and so on).

1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 62.
2 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 80

© ESI International PMC:CPM:EN:000 ver. 2.0 81

Module 4: Project Implementation

Managing Risk

Managing Risk Overview

As part of the control process, the project manager must constantly be on the lookout for risks
that become realities. Otherwise, the project manager will not be ready to react promptly and
effectively, and that is when the most trouble can occur. The assumptions that went into risk
planning must be monitored to see if they are still true. A risk that was considered acceptable
because of low probability and low effect may have become more likely and more serious during
the course of project implementation because of unforeseen external events. The project
manager should also watch for new dangers that may arise. You may be dealing with a whole
different set 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 news
that might have an adverse effect on the project.

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

Quality

Quality Overview
Quality assurance (QA) consists of all the planned and systematic activities implemented within
the quality system to provide confidence that the project will satisfy the relevant quality
standards. Quality control (QC) looks at the activities used to measure performance and
highlight potential changes to the processes. QA and QC should be performed throughout the
project. 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 QA activities that are
measurable, relevant, integrate, and assignable.

82 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 4: Project Implementation

Tools that can be used for QA include the following:

A cost-benefit analysis is a process of estimating tangible and intangible costs (outlays) and
benefits (returns) of various project alternatives, and using financial measures, such as
return on investments and payback period, to evaluate the relative desirability of the
alternative.
Benchmarking can be used to compare the characteristics of the project’s product with the
characteristics of similar products either inside or outside of the performing organization.
Design of experiments holds one variable constant in order to observe changes in other
variables.
Cost of quality deals with bottom-line quality cost. Conformance proactively addresses
quality, and nonconformance addresses quality reactively.
Flowcharting is a diagram consisting of symbols depicting a physical process, a thought
process, or an algorithm. It shows how the various elements of a system or process relate
and which can be used for continuous process improvements.
Quality audits are structured reviews of specific quality management activities. They identify
lessons learned that can improve project performance.
Various software development life cycles and methodologies are used, such as the
Software Quality Function Deployment (SQFD) Model, which yields a set of measurable
technical product specifications and their priorities. Another example is the Capability
Maturity Model® (CMM®), which is a five-level model developed by the Software
Engineering Institute at Carnegie Mellon University. It describes a generic path to process
improvement for software development in organizations. Level 1 is initial, indicating ad hoc
software development processes. Level 2 is repeatable, indicating the basic project
management processes are in place. Level 3 is defined, meaning that the organization uses
a standardized software process. Level 4 is managed, meaning that the organization
collects detailed measures of the software process and product quality. Level 5 is
optimizing, which is the highest maturity level, meaning that the organization enables
continuous process improvement 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 subcauses
create a specific effect.” 1
A flowchart is a “diagram consisting of symbols depicting a physical process, a thought
process, or an algorithm. It shows how the various elements of a system or process relate
and which can be used for continuous process improvement.” 2
A Pareto diagram, “ordered by frequency of occurrence, shows the number of results that
were generated by each identified cause.” 3
An inspection is an “examination or measurement of work to verify whether an item or
activity conforms to a specific requirement.”4
1 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 226.
2 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 175.
3 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 302.

© ESI International PMC:CPM:EN:000 ver. 2.0 83

Module 4: Project Implementation

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 to
remember 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. It
does not mean that the person who is the project manager can never perform any of the project
work. For example, on a small project, one person may be the project manager and the primary
software programmer. The point is that the person in that position is holding two roles and must
not confuse them.

The project manager must get the right members on the team and support them as they do the
work. Just as you seek the best and most suitable members for the core project team during the
requirements phase, you want the best for the larger project team as well. To the extent
possible 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 the
course of the project in order to keep it productive and let it reach its potential. Understanding
members’ motivations helps do that. There are many theories about what motivates different
people, and the project manager should be familiar with some of their underlying concepts and
be able to apply them to the project team.

Regardless of the theory being applied, the conclusion is the same: Different factors motivate
different people. As the project manager, you can’t meet every team member’s every need, but
you should understand what motivates them individually and apply that understanding to
promote the team’s effectiveness. On a large project, your subleaders should be aware of the
motivations 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 group
of individuals or a high-performing group of interdependent members committed to
accomplishing a goal together.

To form a high-performing group, the project manager needs to balance staff development with
getting the job done. For example, you may not assign one of the most important tasks to a
novice, but you would certainly want to carve out positions of responsibility for younger or less-
4 Ward, J. LeRoy. Dictionary of Project Management Terms. 3rd ed. Arlington, Va.: ESI International,
2008, p. 215.

84 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 4: Project Implementation

experienced people so they can learn. Conversely, if you have SMEs, you can give them the
leeway to use their expertise.

So, what elements are you looking for when creating a team? The optimum team size is
between six and eight with a maximum of 12 members. The team identity needs to extend
beyond the sum of the individual providing a common purpose. Providing a common approach
will enable the team to determine who does what job, what skills are required, what skills are
needed, and so on. Don’t forget to look for diverse perspectives, technical skills, and
interpersonal skills within your team. Encourage clearly defined, mutually agreed-upon
expectations. Finally, look for team members that engage and are responsible with a sense of
mutual accountability.

Acquiring Project Team Members

Based on the nature of the project, the performing organization and its resources, you probably
can determine whom you want on the project team, but how do you get them? Even the best
plan 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 be
tested by having to manage a team assembled by management’s design. Although you will
have referent authority, you may get a team that you find difficult to work with. From the
organization’s view, this can be a poor approach because it creates a temptation for the
project manager to blame someone else for project failure.
You can negotiate. This will require discussions with other project managers and functional
organizations to get team members assigned. It involves give and take, provides an
opportunity 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 have
purse-string authority, and you will know whom you’re getting. However, the team may have
mercenary tendencies and lack loyalty.
If you do not consider all the various parameters associated with project teams, you will not
know how well the staff will function, so having a well-functioning group will be purely a matter of
luck. There are several factors that the project manager should consider in selecting team
members, including the following:
Experience. It seems obvious that you would want the most experienced team member you
can get, but this is not always the case. You may want less-experienced people for a variety
of reasons. The project may call for a fresh perspective. The organization may need to
develop new talent. Too many team members with too much experience may conflict with
each 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 than
those who do not.
Personality traits. The project manager needs to determine whether the team members can
work together. Will the personalities mesh?
Availability. A technical expert with required skills for the project is needed but is unavailable
due to the demands for that expertise.

© ESI International PMC:CPM:EN:000 ver. 2.0 85

Module 4: Project Implementation

Productivity. Having the MS Project® expert on the team is not productive if you are not
using his or her MS Project® expertise to track your project but rather a spreadsheet or a
database.
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 do
not. Some may prefer to be closely managed, and if they are on the team, somebody else
must be willing to manage them.
Working with others. The ability to work with others in a team environment is critical for
project success. Someone who is not a team player is not suitable for a project environment
where success is measured by the collective accomplishments of everyone working
together.
Even if the project manager has no opportunity to influence which people are assigned to the
project team, these sorts of considerations are still vital because the project manager needs to
have 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 the
project, 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 the
project. It takes on a functional look with team members assigned to specific areas and not
working much together. (For example, the project could be preparing a training manual with
separate sections assigned to separate members.) Here, the project manager primarily serves
as 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 image
approach. When the specialty team structure is used, the team is organized to take advantage
of 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. This
works when you have only a few people who really know what is needed and others to do the
work. 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 has
the advantage of a very experienced project manager. Here, the project manager primarily
serves 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 their
expertise, and others support them. When appropriate, leadership will move from one project
team 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 your
project. The fact that your organization always uses a particular structure does not necessarily

86 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 4: Project Implementation

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

Any project team structure can easily be incorporated into a virtual team, which is noncolocated
and often does not meet face to face. Indeed, the global project environment has led more and
more 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 has
become an essential tool to manage the virtual team. The project manager should be aware of
different 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 located
with the rest of the team. Virtual teams require a bit more energy, but can work well. Set aside
time to establish clear expectations, protocols for resolving conflict, decision-making
procedures, and clear communication links and channels.

Organizational Structures
Different organizations naturally have different organizational structures. In setting up the project
team’s structure, the project manager must first consider the organization’s nature. In some
organizations, functional managers are very powerful and thus control much of what happens in
projects. In other situations, the nature of the work is such that it should be done mostly in quite
autonomous 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
the power and fully controls the project, and the functional managers serve as providers of
resources.

In other situations (very common with projects these days), the value of varied disciplines
working 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 the
work, but functional managers still have much control over what resources they allow the project
manager to use. The matrixed structure will vary in how it operates depending on the balance of
power between the project managers and the functional managers. PMI®1 uses the terms
“strong” and “weak” to indicate this range of relationships, with the strength of the matrix
indicating the relative power held by the project manager.

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

How to Form a Successful Team

Selecting and acquiring project personnel are only the first steps in transforming several
individuals into a successful team. A variety of techniques can be employed to do this:

1 PMI is a registered mark of the Project Management Institute, Inc.

© ESI International PMC:CPM:EN:000 ver. 2.0 87

Module 4: Project Implementation

Ensure that the project manager and team members agree to their commitments and
understand their roles and responsibilities. Use a roles and responsibility matrix.
Delegate responsibilities to those who can best handle them. Make empowerment an
operating feature of the team. Recognize the importance of delegation, given the numerous
responsibilities on the project.
Recognize that conflict is inevitable on projects. It cannot and should not be avoided. It can
actually 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 is
aligned with the organization’s strategic goals.
Diversity is a fact of life on projects, especially in the multicultural environment. It should be
encouraged and promoted.
For the project to be a success, each task must be completed. Each phase should be
closed out before the next phase begins. A formal project closeout plan should be prepared
and a closeout review conducted. Closure also helps team members achieve greater
satisfaction with project work.
Motivate the team and support team identity. Team identity provides a sense of greater
commitment to the project. It helps the project team members feel closer to each other and
increases their willingness to support each other in an effort to complete the project
successfully.

Rewarding Project Team Members

People need to be rewarded regularly for demonstrating desired performance. Yet, project
managers often do not have all the reward options available to them that functional managers
do 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 ensure
continued 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.
Hand out personalized certificates for outstanding performance.
Financial rewards. Bonuses, pay increases, or even a gift certificate or dinner for two on the
company can be given to top performers.
Responsibility. An effective team member can be assigned to a team leader position for the
project 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 the
functional manager, but a project manager who has supervised that person can provide
favorable 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 in
many forms, and whenever possible, recognize group contributions. Whether the reward is
expressed privately or publicly, stated on paper, made with money, or shown through some

88 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 4: Project Implementation

other means, providing feedback to individuals and to the team is important. The project
manager must 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 organization
and develop a suitable structure for your project team, conflict within a team or between the
team and other stakeholders during the implementation phase is usually inevitable. Human
nature being what it is, many everyday occurrences on a project team can lead to conflict. To
name just 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 and
dissension that diverts too much energy for the real tasks. According to traditional management
theory, conflict is bad and should be avoided. More contemporary theories suggest that some
conflict is good if it is managed to the mutual benefit of all concerned. For example, if people
question what is happening and are given the opportunity to share proposals for alternative
solutions, they can become more vested in the success of the project, and their ideas may well
improve the end result. This most often requires addressing conflicts head on in order to resolve
them. Although smoothing over conflicts or trying to solve them through compromise may work
at times, there also may be attempts to take the easy way out, which only create an atmosphere
of mistrust and dissension and divert too much energy from the real tasks. Under either
philosophy, 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 the
team to monitor its progress in developing the product or system. Even though the project
manager is not directly involved in development tasks, it is critical that he or she monitor their
progress. If necessary, the project manager should provide the team with supplemental
resources to keep the project on track.

It is also crucial that the project manager communicate frequently with the team members. This
is necessary to maintain awareness of any problems developers are facing, to keep the
development schedule and delivery dates on track, and to ensure that the product or system
being developed meets the approved design specifications and client business requirements.
Communications can be undertaken by holding regular meetings with the team to identify and
resolve 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 the

© ESI International PMC:CPM:EN:000 ver. 2.0 89

Module 4: Project Implementation

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

Managing Stakeholder Expectations

Managing Stakeholder Expectations Overview

At some point in the implementation phase of a project, the project manager will probably have
to manage stakeholder expectations and changes to the project baseline. This is often difficult
to do 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 goes
on. The scope might call for a landscaping plan with six new trees, but wouldn’t a fishpond look
nice right here, too? The project manager must first understand the revised expectation and
then either translate it into a change request or diplomatically help the customer understand the
“wandering nature” of the expectation and, thus, go back to the original scope.

This phenomenon is commonly referred to as “scope creep.” Managing scope creep is a

constant struggle because you are dealing with the triple constraint as well as with the intangible
but crucial factor of customer satisfaction. During the Planning phase, it is addressed by clearly
defining project requirements during the scope planning process. During the implementation
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’t want them
so involved in day-to-day activities that you fail to protect the team so it can do the work.

Validating Scope

Validating Scope Overview

Validating the scope of a project and customer acceptance are two more instances where the
WBS proves its value. Basically, these two efforts are intended to determine whether you did
what you planned to do.

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

90 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 4: Project Implementation

It is important to point out that scope validation and quality control are uniquely different in that
the former is primarily concerned with the acceptance of deliverables, while the latter is focused
on meeting the quality requirements specified for the deliverables. An easy way to see this is to
answer the questions, “Is it done?” (validate scope) and “Is it done right?” (perform quality
control).

Module Summary

Module Summary
Monitoring and controlling is ongoing and used by the team; evaluating is periodic and used
by senior management.
Change can be managed with a well-designed change management system.
EV shows the project manager the difference between what was planned and what 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 once they occur.
The project manager must develop, structure, and support the project team for it to perform
well.
Conflict is inevitable and must be managed.
Scope should be verified against the agreed-upon requirements.
Customer acceptance involves both technical acceptance and sign-off.
The probability of project success increases when actively managing stakeholders
engagements.
Open lines of communication and good interpersonal skills are beneficial in managing
stakeholders' expectations.

© ESI International PMC:CPM:EN:000 ver. 2.0 91

 Module 5: Project Closeout

Module 5
Project Closeout

Introduction

Module Overview
This text deals with the often-overlooked project closeout and the various types of activities
involved in the Closeout phase.

Project Closeout

Project Closeout Overview

Many project managers think the project ends as soon as the product or service is delivered to
the 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 activities
across all 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 of
contract compliance to sharing wisdom and experience for future projects. The project manager
needs to ensure that tasks required for proper scope verification and customer closure have
been accomplished. Contract and administrative closure also are essential to proper project
closeout. Finally, the project manager should complete an analysis of lessons learned and
project successes, and communicate them to the appropriate project stakeholders.

With pressures to reassign team members, move on to new activities, and so on, the only
practical way to accomplish closeout is to include it in the plan. The project plan specifically
should identify the various closeout tasks, allocate costs to them, schedule them, and assign
them resources. Include closeout work in the work breakdown structure (WBS) to be sure that
you adequately allocate the time, money, and resources to do it.

© ESI International PMC:CPM:EN:000 ver. 2.0 93

Module 5: Project Closeout

Closeout Guidelines and Issues

Guidelines for Project Closeout

Closeout does not just apply to completed—and hopefully highly successful—projects. Even
those that do not end as planned must be closed out properly. Also note that some closeout
activities are more important in prematurely closed projects than fully completed projects. For
example, the project manager must either schedule unstated work to ensure the work is
completed 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, team
members will recognize the importance of this phase and that the project is not complete until
this phase has been concluded. In addition, allow time to prepare a detailed closeout plan and
include this in the WBS for the project.

Develop and use a project closeout checklist so that you don’t overlook critical steps and
processes to be followed. There are countless details that need to be addressed, and you want
to ensure everything is closed out properly. Some items on the checklist (such as waiting for
final 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 review
shortly after the product or service has been delivered. The closeout review allows the project
team and the sponsor to discuss the final outcome and the lessons learned. Have someone
other than you (such as another project manager or someone from the corporate quality
assurance or audit group) perform a final review of the project results. Issues to be reviewed
should 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 the project's return on investment (ROI) obtained—or will it be in the future?
Collect all documentation pertaining to the technical solution developed and prepare closeout
documentation, including lessons learned, the final project report, and a procurement audit. Be
sure these lessons and project documents are archived in a location where they may be easily

94 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 5: Project Closeout

accessed as a record for the project and as a reference for future projects. Prepare a final
project report and communicate it to stakeholders. Your final report should include a summary
of the project results, a high-level executive summary with any appropriate graphs, and a
detailed section for those who are interested in the specifics. Focus on what business needs
have been met, the “big wins” for the organization, and the triple constraint (that is, planned
versus actual time, cost, and scope).

As project manager, you should continue to preserve the team identity and keep spirits high
among team members. You can do this through status meetings, performance feedback, award
recognition, 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 progress
on milestones completed, and reflect on how great a job the team did! Talk about the benefits
the business is experiencing due to the implementation of the project. You can even make these
meetings fun by recognizing star performers with awards.

Communication during closeout is as important as it is during other phases. Part of

communication involves providing performance feedback to team members and their functional
managers. Whenever possible, provide performance feedback in writing to address the skills
and qualities that make each person an outstanding team member and the areas of weakness
where they can improve. Be specific and honest. Describe opportunities or jobs that would allow
a 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, you
should make an effort to visit remote sites if the project team is physically dispersed. Making site
visits enables all team members to obtain closure on the project. It also offers people working at
remote sites a chance to give you face-to-face project feedback and provide you with an
opportunity 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 team
and individual team members’ accomplishments. Let everyone know the business benefits
realized from this great project!

Finally, review and document lessons learned from the experience to help improve performance
on future projects. Share what you learned—including what worked and what didn’t work—with
others so everyone can benefit! In addition, document what (in hindsight) you would have done
differently to really benefit future projects. Be sure the recorded lessons you and your team
collected 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 and
procedural 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 members
may not feel the same intensity to move ahead on tasks as they did during the “livelier” phases
of the project. In addition, some team members may already be working on new projects that

© ESI International PMC:CPM:EN:000 ver. 2.0 95

Module 5: Project Closeout

are taking up most or all of their time. As stated in the guideline for project closeout, the project
manager really needs to step in and encourage team members to stay focused until the
Closeout phase is complete. As the project manager, keep the team focused and maintain a
consistent and positive attitude. As soon as you begin to change your behavior, your team will
start to do the same.

Like the project team, the customer may experience a loss of interest in the project. Resistance
to change, change in attitude, and unavailability of key personnel make it difficult to complete
the last few tasks and tie up loose ends, especially when customer input is needed. The
customer will now own and manage the product or system. So, it is essential that that transfer of
knowledge and up-to-date documentation is completed and in place for the customer to be
effective 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 to
take over.

Procurement and Project or Phase Closeout

Procurement/Contract and Project/Phase Closeout Overview

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

There are several key components of a project or phase closeout:

Obtain final customer acceptance.
Provide the customer with relevant project information.
Recognize, reward, and reassign the project team members.
Terminate outstanding purchase orders from the subcontractors.
Prepare the final payment.
Dispose the materials and supplies.
Prepare the final cost and schedule reports.
Document the lessons learned.
Celebrate the project's successes.
You may also have to deal with returning borrowed equipment, moving out of temporary office
space, and accomplishing other tasks. Organized archives are essential as people move on to
new assignments. What would happen if the project were audited two years from now?

96 PMC:CPM:EN:000 ver. 2.0 © ESI International

 Module 5: Project Closeout

Lessons Learned
Lessons learned are the organization’s memory bank. Ideally, you will track lessons learned as
they occur, or at least at major evaluation points or milestones throughout the project, and not
wait 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, disseminated,
and preserved. Make sure a future project manager can learn from the good and bad content
many years after the project closes. Is there a process that your organization uses to do this? If
not, then you may want to work to create one for the long term. In the meantime, you should
distribute your lessons learned to those who can benefit from them. If you do not do this, your
organization will go back to square one every time it decides to pursue a similar project and
waste 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 care
of individual or personal issues, team issues, and public relations.

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

You may also want to distribute some letters of appreciation on your own on a formal or informal
basis for members of the project team, inasmuch as you should also be looking to the next
assignment. And, since you may be working with many of the same people in the future, a little
recognition 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 they
are to you. You may want to extend this to stakeholders outside the project team as a means of
promoting good feelings about the project outcome. In some cases, your organization may
require you to prepare performance reports. You may also be able to facilitate the team
members’ next assignments.

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

Module Summary

Module Summary
Plan for closeout in the WBS and the schedule.

© ESI International PMC:CPM:EN:000 ver. 2.0 97

Module 5: Project Closeout

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 the appropriate
recognition and celebration of your efforts.

98 PMC:CPM:EN:000 ver. 2.0 © ESI International