(BusinessPro Collection) Dobson, Michael Singer - Successful Project Management - How To Complete Projects On Time, On Budget, and On Target-Ama Self-Study - American Management Association (2015)

Successful Project Management
Fourth Edition
How to Complete Projects on Time,

on Budget, and on Target
This page intentionally left blank
Fourth Edition
How to Complete Projects on Time,

on Budget, and on Target
Michael S. Dobson
Successful Project Management, Fourth Edition
How to Complete Projects on Time, on Budget, and on Target
© 2015 American Management Association. All rights reserved. This material may not be reproduced, stored in a retrieval system,
or transmitted in whole or in part, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise,
without the prior written permission of the publisher.
ISBN 13: 978-0-7612-1567-7
ISBN 10: 0-7612-1567-0
AMACOM Self-Study Program
http://www.amaselfstudy.org
AMERICAN MANAGEMENT ASSOCIATION
http://www.amanet.org
Contents
About This Course xiii
How to Take This Course xv
Pre-Test xvii
1 Understanding Project Management 1

Origins of Modern Project Management
Projects and Project Management
Projects and the Organization
Programs and Portfolios
Project Management Office (PMO)
Organizational Structure and Project Management
The Process of Project Management
Project Initiation
Project Planning
Project Execution
Project Monitoring and Control
Project Closing
The Many Hats of a Project Manager
Project Time Management
Project Scope Management
Project Cost Management
Project Communications Management
Project Stakeholder Management
Project Human Resources Management
Project Quality Management
Project Procurement Management
Project Risk Management
Project Integration Management
Recap
Review Questions
2 Defining the Project 21

From Problem to Project
Project Initiation
Project or Phase
Stakeholders
© American Management Association. All rights reserved.
http://www.amanet.org/ v
vi SUCCESSFUL PROJECT MANAGEMENT
Common Stakeholders
Other Stakeholders
Issues in Stakeholder Management
Constraints
Hierarchy of Constraints
Ranking Constraints
Assumptions
Project Charter
Obtaining Approval and Buy-In
Progressive Elaboration and the Project Objective
Recap
Review Questions
3 Planning the Activities 41

Iterative Planning
Statement of Work
Requirements Document
Work Breakdown Structure
Creating a Work Breakdown Structure
Phases, Deliverables, or Departments?
The One Hundred Percent Rule
Project Management Work in the WBS
Network Diagramming
Constructing an Activity List
Laying Out the Project
Determining the Critical Path
Additional Scheduling Relationships
Forward and Backward Pass
Gantt Chart
Recap
Review Questions
4 Estimating the Activities 65

Uncertainty in Project Planning
Estimating Methodologies
Standard Estimating Techniques
Analogous Estimating
Expert Judgment and Delphi Estimating
Parametric Estimating
Bottom-Up Estimating
Three-Point Estimating
Program Evaluation and Review Technique (PERT)
Monte Carlo Simulation
Issues in Estimating
Overoptimism
Parkinson’s Law
Rolling Wave Estimating

http://www.amanet.org/
CONTENTS vii
Recap
Review Questions
5 Preparing a Project Plan 79

Progressive Elaboration and the Project Plan
Staffing and Resource Requirements
Building the Project Team
Responsibility Assignment Matrix (RAM)
Loading and Leveling the Schedule
Outsourcing
Procurement Planning
Critical Path Method (CPM) Analysis
The Northridge Overpass Disaster
Implications for Project Planning
Critical Path Method
Crashing a Project
Communications and Stakeholder Management Plan
Recap
Review Questions
6 Managing Risk and Quality 95

The Project Universe
Risk
Threats and Opportunities
Pricing Risk
Uncertainty About Uncertainty
Risk Tolerance
Risk Management Process
Planning Risk Management
Identifying Risks
Performing Qualitative Risk Analysis
Performing Quantitative Risk Analysis
Planning Risk Responses
Residual and Secondary Risk
Implementing Risk Responses
Quality
Is Quality Scope?
Process Quality and Product Quality
Process Quality
Product Quality
Quality Tools and Processes
Recap
Review Questions

viii SUCCESSFUL PROJECT MANAGEMENT
7 Transition to Execution 123

From Plan to Work
Plan Approval
Performance Measurement Baseline
Schedule
Scope Verification
Cost Baseline
Teams and Other Resources
Acquiring the Team
Team Development
Kickoff Meeting
Work Management
Change Management
Fundamentals of Change Management
Change Control Boards and Configuration Management
Solving Problems
Contingency Plans
Corrective Actions and Workarounds
Recap
Review Questions
8 Controlling Time, Cost, and Scope 139

Planning Monitoring and Control
Monitoring Project Status
Status Reports
Status Meetings
Inspections and Reviews
Frequency of Reviews
Reporting Project Status
Risk Monitoring and Control
New Risk Cycle
Risk Reassessment
Risk Audits
Managing Reserves
Monitoring and Controlling Quality
Quality Assurance
Quality Control
Earned Value Management
Planned Value, Earned Value, and Actual Cost
Cost Variance and Schedule Variance
Cost and Schedule Performance Indices
Applying Earned Value
Advanced EVM
Updating the Project Plan and Baseline
Recap
Review Questions

CONTENTS ix
9 Evaluating and Reporting on 157

Project Performance
Project Closeout
Closeout Checklist
Transfer
Contract and Procurement Closure
Administrative Closure
Celebration and Reward
Lessons Learned
On to the Next Project!
Recap
Review Questions
Appendix A: Answers to Exercises and Case Studies 169
Exercise 1–1. Getting Started
Exercise 1–2. Knowledge Areas
Exercise 2–1. Stakeholder Register
Exercise 2–2. Hierarchy of Constraints
Exercise 2–3. PMO Project Constraints and Assumptions
Exercise 2–4. PMO Project Charter Outline
Exercise 3–1. Research and the SOW
Exercise 3–2. Different WBS Approaches
Exercise 3–3. Build a Work Breakdown Structure
Exercise 3–4. Activity List
Exercise 3–5. Network Diagram
Exercise 3–6. Forward and Backward Pass
Exercise 3–7. Create a Gantt Chart
Exercise 4–1. Types of Estimates
Exercise 4–2. Calculating PERT Estimates
Exercise 4–3. Estimating Review
Exercise 5–1. Skill Requirements
Exercise 5–2. Skill List
Exercise 5–3. Responsibility Assignment Matrix
Exercise 5–4. CPM Analysis
Exercise 5–5. Communications and Stakeholder Management Plan
Exercise 6–1. Risk Tolerance
Exercise 6–2. Risk Identification
Exercise 6–3. Qualitative Risk Analysis
Exercise 6–4. Sensitivity Analysis
Exercise 6–5. Risk Response Planning
Exercise 6–6. Functional and Nonfunctional Requirements
Exercise 7–1. Analyzing a Tracking Gantt Chart
Exercise 7–2. Problem Solving
Exercise 8–1. Earned Value Metrics
Exercise 8–2. Cost and Schedule Variance
Exercise 8–3. Performance Indices
Exercise 9–1. Closeout Checklist
Exercise 9–2. Implementing the PMO
Exercise 9–3. Lessons Learned Questions

x SUCCESSFUL PROJECT MANAGEMENT
Appendix B: Glossary 195

Appendix C: Bibliography and Recommended Reading 209
Appendix D: Additional Resources 213
Post-Test 217
Index 223
List of Exercises
Exercise 1–1 Getting Started
Think About It…Organization
Think About It…New Projects
Think About It…Closing Out
Exercise 1–2 Knowledge Areas
Think About It…Problem Definition
Think About It…Project or Phase
Exercise 2–1 Stakeholder Register
Exercise 2–2 Hierarchy of Constraints
Exercise 2–3 PMO Project Constraints and Assumptions
Exercise 2–4 PMO Project Charter Outline
Exercise 3–1 Research and the SOW
Think About It…Top Down or Bottom Up
Exercise 3–2 Different WBS Approaches
Exercise 3–3 Build a Work Breakdown Structure
Exercise 3–4 Activity List
Exercise 3–5 Network Diagram
Think About It…Will You Make the Deadline?
Exercise 3–6 Identify Critical Path and Float
Exercise 3–7 Draw a Gantt Chart
Think About It…Uncertainties on Your Project
Exercise 4–1 Types of Estimates
Exercise 4–2 Calculating PERT Estimates
Think About It…Managing Uncertainty
Exercise 4–3 Estimating Review
Exercise 5–1 Skill Requirements
Exercise 5–2 Skill List
Exercise 5–3 Responsibility Assignment Matrix
Think About It…Loading and Leveling
Think About It…Make or Buy
Exercise 5–4 CPM Analysis
Exercise 5–5 Communications and Stakeholder Management Plan
Exercise 6–1 Risk Tolerance
Think About It…Risk Management Policy
Exercise 6–2 Risk Identification
Exercise 6–3 Qualitative Risk Analysis
Exercise 6–4 EMV Calculations and Sensitivity Analysis
Exercise 6–5 Risk Response Planning
Think About It…Process Quality
Exercise 6–6 Functional and Nonfunctional Requirements
Exercise 7–1 Analyzing a Tracking Gantt Chart
Think About It…Teams
Think About It…Change Management
Exercise 7–2 Problem Solving

CONTENTS xi
Think About It…Monitoring and Control

Think About It…Meeting Culture
Exercise 8–1 Earned Value Metrics
Exercise 8–2 Cost and Schedule Variance
Exercise 8–3 Performance Indices
Think About It…Earned Value
Think About It…Project Closeout
Exercise 9–1 Closeout Checklist
Exercise 9–2 Implementing the PMO
Think About It…Celebration
Exercise 9–3 Lessons Learned Questions
Think About It…Next Steps
List of Exhibits
Exhibit 1–1 Case Study: Establishing a Project Management Office (PMO)
Exhibit 1–2 The Five Project Management Process Groups
Exhibit 1–3 The Ten Project Management Knowledge Areas
Exhibit 2–1 Phases
Exhibit 2–2 Analyzing Stakeholders
Exhibit 2–3 The Triple Constraint
Exhibit 2–4 Hierarchy of Constraints
Exhibit 3–1 Statement of Work
Exhibit 3–2 Guidelines for Writing Requirements
Exhibit 3–3 Work Breakdown Structure in “Org Chart” and Outline Format
Exhibit 3–4 Department Based vs. Phase Based WBS
Exhibit 3–5 Network Diagram
Exhibit 3–6 Critical Path
Exhibit 3–7 Forward Pass
Exhibit 3–8 Forward Pass Summary
Exhibit 3–9 Backward Pass
Exhibit 3–10 Backward Pass Summary
Exhibit 3–11 Critical Path and Float
Exhibit 3–12 Critical Path and Float Summary
Exhibit 3–13 Gantt Chart
Exhibit 3–14 Gantt Chart Data
Exhibit 3–15 Completed Gantt Chart
Exhibit 4–1 PERT Formulas
Exhibit 4–2 Standard Deviation Diagram
Exhibit 4–3 Z Table
Exhibit 5–1 Skill Requirements
Exhibit 5–2 Team Skills
Exhibit 5–3 Responsibility Assignment Matrix
Exhibit 5–4 Crashing a Project Using CPM
Exhibit 5–5 Summary of Crashing Activities
Exhibit 5–6 Communications and Stakeholder Management Plan Template
Exhibit 6–1 The Project Environment
Exhibit 6–2 Risk Identification
Exhibit 6–3 Sample Risk Register
Exhibit 6–4 Risk Triage Flowchart
Exhibit 6–5 Probability and Impact Matrix
Exhibit 6–6 Expected Monetary Value

xii SUCCESSFUL PROJECT MANAGEMENT
Exhibit 6–7 Decision Tree

Exhibit 6–8 Risk Response Strategies
Exhibit 7–1 Tracking Gantt Chart
Exhibit 7–2 Cost Baseline
Exhibit 7–3 Work Management Form
Exhibit 7–4 Problem Solving Strategy
Exhibit 8–1 Team Member Status Report Form
Exhibit 8–2 Project Status Report
Exhibit 8–3 Earned Value
Exhibit 9–1 Closeout Checklist
Exhibit 9–2 Lessons Learned/Project Salvage
FOR QUESTIONS AND COMMENTS:

Please contact Self Study at 1-800-225-3215 or email
AMASelfStudy@amanet.org for information about
Self Study courses. And visit our website at www.amaselfstudy.org

About This Course
“Project management is one of those applications that everyone

knows someone else should be using.”
–Michael J. Miller, InfoWorld, 1988
The management of projects is often vital to the success and growth of organ-
izations. Unlike ongoing operations, projects are both temporary and unique.
Because they are temporary, they often do not have the benefit of fully devel-
oped, mature, and permanent organizations devoted to their success. Because
they are at least in some respects unique, they each involve special problems,
issues, and considerations.
Project management, in a nutshell, is the art, craft, and science of manag-
ing projects. It is a wide-ranging and complex discipline that incorporates and
uses elements from many different disciplines. Although project management
was once considered just an aspect of such fields as architecture or engineering,
today project management is considered to be a discipline in its own right.
In a fast-moving and fast-changing world, project management skills are
often a vital element in your career growth and ultimate success. Even when
managing projects is only an element of your overall job, success in managing
projects often has a disproportionate impact on your career.
Successful Project Management, Fourth Edition, is an introductory course in
project management. In this course, you will learn the fundamental concepts,
strategies, techniques, and approaches of modern project management. The
course is designed for active project managers, technical team members who
need to understand the overall project approach in order to perform their roles
effectively, and senior managers and executives who must hire, supervise, and
evaluate project managers in their employ.
We will follow the basic project management approach as laid out in A
Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th Edition,
popularly known as the PMBOK® Guide, along with other sources listed in
the Bibliography and Recommended Reading section at the end of the course.
We strongly encourage you to read and study widely.

http://www.amanet.org/ xiii
xiv SUCCESSFUL PROJECT MANAGEMENT
Michael S. Dobson, PMP, is an internationally known authority on proj-

ect management and author of 62 books, including twelve on the topic of proj-
ect management. He has written eight books published by AMACOM.
As principal of Dobson Solutions (www.dobsonsolutions.com) and the
Sidewise Institute (www.sidewiseinsights.com), Michael consults, speaks, and
trains on project management topics throughout the world. His clients range
from the US Navy’s nuclear propulsion program to Calvin Klein Cosmetics.
As an operating executive and project manager, Michael has held the pos-
tions of Vice President, Discovery Software International; Vice President, Games
Workshop; and Director of Marketing and Games Development, TSR, Inc. He
was part of the team that built the Smithsonian Institution’s National Air and
Space Museum in the 1970s. He holds a bachelor’s degree from the University
of North Carolina at Charlotte.

How to Take This Course
This course consists of text material for you to read and three types of activ-
ities (the Pre- and Post-Test, in-text exercises, and end-of-chapter Review
Questions) for you to complete. These activities are designed to reinforce the
concepts brought out in the text portion of the course and to enable you to
evaluate your progress.
Pre- and Post-Tests

Both a pre-test and a post-test are included in this course. Take the pre-test
before you study any of the course material to determine your existing knowl-
edge of the subject matter. To get instructions on taking the test and having
it graded, please email AMASelfStudy@amanet.org, and you will receive an
email back with details on taking your test and getting your grade. This email
will also include instructions on taking your post-test, which you should do
upon completion of the course material.
Certificate
Once you have taken your post-test, you will receive an email with your grade
and a certificate if you have passed the course successfully (70% or higher).
All tests are reviewed thoroughly by our instructors, and your grade and a
certificate will be returned to you promptly.
The Text
The most important component of this course is the text, for it is here that
the concepts and methods are first presented. Reading each chapter twice will
increase the likelihood of your understanding the text fully.
We recommend that you work on this course in a systematic way. Only
by reading the text and working through the exercises at a regular and steady
pace will you get the most out of this course and retain what you have learned.
In your first reading, concentrate on getting an overview of the chapter’s con-
tents. Read the learning objectives at the beginning of each chapter first. They
serve as guidelines to the major topics of the chapter and enumerate the skills

http://www.amanet.org/ xv
xvi SUCCESSFUL PROJECT MANAGEMENT
you should master as you study the text. As you read the chapter, pay attention
to the heading and subheadings. Find the general theme of the section and
see how that theme relates to others. Don’t let yourself get bogged down with
details during the first reading; simply concentrate on remembering and un-
derstanding the major themes.
In your second reading, look for the details that underlie the themes.
Read the entire chapter carefully and methodically, underlining key points,
working out the details of the examples, and making marginal notations as
you go. Complete the exercises.
Exercises and Activities

Interspersed with the text in each chapter you will find exercises that take a
variety of forms. In some cases, no specific or formal answers are provided.
Where appropriate, suggested responses or commentary follow the exercises.
The Review Questions

After reading a chapter and before going on to the next, work through the re-
view questions. By answering the questions and comparing your own answers
to the answers provided, you will find it easier to grasp the major ideas of that
chapter. If you perform these self-check exercises conscientiously, you will
develop a framework in which to place material presented in later chapters.
Questions About Grading/Retaking the Test

If you have questions regarding the tests, the grading, or the courses itself,
please email Self Study at AMASelfStudy@amanet.org .
If you fail the Post-Test, you have one year to retake the test for one year
after the course’s purchase date.

Pre-Test

Fourth Edition
Course Code 98004

INSTRUCTIONS: To take this test and have it graded, please email AMASelfStudy
@amanet.org. You will receive an email back with details on taking your test and get-
ting your grade.
FOR QUESTIONS AND COMMENTS: You can also contact Self Study at 1-800-225-3215
or visit the website at www.amaselfstudy.org.
1. In a PERT analysis, what is the probability that an activity will be

completed no later than the PERT estimate?
(a) 50.00%
(b) 84.13%
(c) 15.87%
(d) 61.79%
2. The triple constraints include:

(a) risk, quality, and procurement.
(b) time, risk, and quality.
(c) time, cost, and quality.
(d) time, cost, and performance.

www.amanet.org xvii
xviii SUCCESSFUL PROJECT MANAGEMENT
3. A critical path activity can be compressed from eight weeks to four

weeks at a cost of $1,000 per week. The available float on the parallel
path is two weeks. There is a $1,200 bonus for each week early. How
would you crash this project?
(a) Crash four weeks from the critical path activity.
(b) Do not crash; it’s not financially appropriate.
(c) Crash two weeks from the critical path activity.
(d) Crash both critical and noncritical paths two weeks.
4. Which of the following is a step in project closeout?
(a) Charter
(b) Quality assurance
(c) Transfer
(d) Baseline
5. Which project management process includes activities needed to
define a new phase of an existing project?
(a) Progressive elaboration
(b) Project planning
(c) Project transfer
(d) Project initiation
6. What project management tool links resources to activities?
(a) WBS
(b) RAM
(c) PERT
(d) EVM
7. A particular business opportunity requires an investment of $150,000,
and has a 70% chance of success. If it succeeds, you will earn $275,000,
but if the investment fails, you will lose your entire investment. What is
the expected monetary value?
(a) $275,000
(b) -$150,000
(c) $125,000
(d) $147,500
8. What is a characteristic of a well-written requirement?
(a) Condition → Consequence
(b) Described in the project charter
(c) Unambiguous and verifiable
(d) Exists as a work package in the project’s WBS
9. The technique of adjusting your estimates as the project moves forward to
take advantage of improved knowledge and understanding is known as:
(a) the Monte Carlo simulation.
(b) the earned value method.
(c) rolling wave estimating.
(d) the program evaluation and review technique.

PRE-TEST xix
10. Look at the WBS that follows this question. How is it organized?
(a) By department or work group
(b) By phase
(c) By cost account
(d) By difficulty or risk
Develop a Course
Instructional Systems
Production Operations Marketing
Design
Research Topic Design Graphics Assign Presenter Determine Topic
Arrange Beta Test Develop Promotional

Write Workbook Produce Materials
Site Materials
Ship Materials to
Develop Exercises Conduct Beta Test Approve New Course
Seminar Location
Incorporate Beta Test Train Additional

Market Course
Feedback Speakers
Finalize Course
11. For a particular activity, we determine that optimistically it will take 6

weeks, pessimistically it will take 30 weeks, but it will most likely take
12 weeks. What is the PERT estimated time and the standard
deviation?
(a) E = 12, 𝛔 = 6
(b) E = 14, 𝛔 = 4
(c) E = 8, 𝛔 = 4
(d) E = 30, 𝛔 = 12
12. An analogous estimate is considered accurate if the final project cost is

within the range:
(a) -25%, +100%.
(b) -10%, +25%.
(c) -5%, +10%.
(d) -5%, +0%.
13. The extent to which the project’s product, service, and result satisfy the
needs for which it was undertaken is known as:
(a) quality.
(b) scope.
(c) risk.
(d) WBS.

xx SUCCESSFUL PROJECT MANAGEMENT
14. Look at the following network diagram. What is the critical path?
(a) A→B→D→H
(b) A→E→C→D→H
(c) A→E→F→G→H
(d) A→C→H
Activity B Activity D
4 days 3 days
Activity A Activity C Activity H

6 days 9 days 4 days
Activity E Activity F Activity G

2 days 3 days 1 day
15. Today, we were supposed to have completed four activities that were
planned to cost $2,500 each. We have actually accomplished only three
of those activities and we have spent $7,000 to date. In earned value
method terms, what is our cost performance index, rounded to the
nearest whole percent?
(a) 93%
(b) 107%
(c) 75%
(d) 133%
16. What document formally authorizes the existence of a project and

gives the project manager working authority to proceed?
(a) Project scope statement
(b) Project authorization document
(c) Project plan
(d) Project charter
17. What is “the application of knowledge, skills, tools, and techniques to

project activities to meet the project requirements”?
(b) Program evaluation and review technique
(c) Project management
(d) Iterative planning
18. What performance measurement baseline can serve as a metric for all
three triple constraints?
(a) Cost baseline
(b) Responsibility assignment matrix
(c) Tracking Gantt chart
(d) Weekly status reports

PRE-TEST xxi
19. The fundamental formula for risk is:

(a) P x I
(b) (O + 4M + P) / 6
(c) EV – AC
(d) BAC / CPI
20. How frequently should you hold status meetings or require status
reports?
(a) Preferably weekly, but no less often than monthly
(b) Whenever a problem or issue arises
(c) When the project sponsor or customer need an update
(d) Varies based on the speed of change within the project
21. What is defined as a “hierarchical decomposition of the total scope of

work to be carried out by the project team to accomplish the project
objectives and create the required deliverables”?
(a) Responsibility assignment matrix
(b) Work breakdown structure
(c) Critical path
(d) Project charter
22. What is one piece of information that should be included in a

communications and stakeholder management plan?
(a) To whom stakeholders report
(b) Ways to get around difficult stakeholders
(c) Stakeholder leadership roles in the project
(d) What we need/want from the stakeholder
23. The process of prioritizing risks for further analysis or action by

assessing and combining their probability of occurrence and impact is
known as:
(a) quantitative risk analysis.
(b) risk response planning.
(c) decision tree analysis.
(d) qualitative risk analysis.
24. What is a constraint?

(a) Something that limits your choices
(b) Something considered true for planning purposes
(c) Just the three elements of time, cost, and performance
(d) One of the nine knowledge areas of project management

xxii SUCCESSFUL PROJECT MANAGEMENT
25. You have identified a risk that the price of raw materials you need for
the project could potentially double in price by the time you would
normally purchase them. You decide you will buy the materials far in
advance of need to lock in the price. What risk response strategy have
you used?
(a) Avoid
(b) Mitigate
(c) Transfer
(d) Contingency plan

Understanding Project
1
Management
Learning Objectives
By the end of this chapter, you should be able
to:
• Describe the origins and growth of project
management as a discipline.
• Define projects and project management and
explain the concepts of progressive elabora-
tion and iterative activity as they apply to proj-
ect management.
• Describe the relationship between projects
and the organization, including the roles of
programs and portfolios, the function of a
Project Management Office (PMO), and the
characteristics of functional, projectized, and
matrix organizations.
• Identify and describe the five fundamental
processes of project management.
• List and define the ten knowledge areas of
project management.
Estimated timing for this chapter:

Reading 1 hour 20 minutes
Exercises 1 hour 30 minutes
Review Questions 10 minutes
Total Time 3 hours

http://www.amanet.org/ 1
2 SUCCESSFUL PROJECT MANAGEMENT
ORIGINS OF MODERN PROJECT

MANAGEMENT
Though projects have been managed since the beginning of civilization, project
management as a discipline is of more recent vintage. Imhotep, builder of the
first pyramid, was an architect, a physician, and possibly most importantly the
equivalent of prime minister, able to command all the resources necessary to
manage the project.
Military leaders were often project managers as well, and not merely on
the battlefield. At the Battle of Alesia (52 BCE), Gaius Julius Caesar built 24
miles of fortifications with a fortlet every 80 feet to defend his small force
against the massive Gallic army of Vercingetorix.
As mechanical and civil engineering emerged as formal disciplines in the
late 18th and early 19th centuries, engineers often served as project managers.
Gustave Eiffel did not merely design the tower that bears his name, but over-
saw its construction as well. This allowed him to identify and respond to some
of the technical challenges, such as building elevators that ran on slanted
tracks—something that had never been done before.
The new concepts of engineering led to the consideration of manage-
ment as a scientific discipline. Mechanical engineer Frederick W. Taylor began
studying ways to improve industrial efficiency and became one of the first
management consultants. He became known as the “father of scientific man-
agement” for his empirical studies, and many of his concepts, ideas, and ap-
proaches remain in use to this day. Although general management and project
management each have their unique qualities, the systematic study of general
management had a great influence on the way projects were managed.
Taylor’s college roommate, Henry Gantt, continued to work with him
for 30 years. Gantt developed the concept of incentive pay, linking the bonus
paid to managers to how well they trained their employees. He is, however,
best remembered in the discipline of project management for his development
of a bar chart that shows project progress. Though the chart is today known
as the Gantt chart, much of its modern format was actually developed by Pol-
ish engineer Karol Adamiecki.
What is often thought of as modern project management is even more re-
cent, dating back to the late 1950s. The Program Evaluation and Review Tech-
nique (PERT), a creation of the US Navy and Booz Allen Hamilton, allows
schedule analysis when details and durations of individual activities are un-
certain. At roughly the same time, DuPont Corporation and Remington Rand
developed the Critical Path Method (CPM), based on earlier scheduling tech-
niques that had played a role in the management of the Manhattan Project.
As projects have expanded in size and complexity, so has project manage-
ment grown as a discipline and career field distinct from engineering, archi-
tecture, and the military. The International Project Management Association
(IPMA), established in 1965, is a federation of more than 50 national and in-
ternational project management associations, and offers the IPMA Compe-
tence Baseline (ICB®) certification. The United Kingdom’s Association for
Project Management (APM) offers a Registered Project Professional (RPP)
designation.

UNDERSTANDING PROJECT MANAGEMENT 3
In the United States, the largest and best-known project management or-
ganization is the Project Management Institute (PMI), established in 1984. Its
standard terminology and guidelines for project management are contained
in A Guide to the Project Management Body of Knowledge (PMBOK® Guide), currently
in its fifth edition. The PMBOK® Guide is used by both the American National
Standards Institute (ANSI) and the Institute of Electrical and Electronics En-
gineers (IEEE) as its official standard. The PMI offers a range of credentials
for project managers, most famously the Project Management Professional
(PMP®) designation. This course is designed to be compatible with the fifth
edition of the PMBOK® Guide.
PROJECTS AND PROJECT MANAGEMENT

The general concept of work can be subdivided into ongoing work efforts, also
known as operations, and projects. A project, according to the PMBOK® Guide, is
“a temporary endeavor undertaken to create a unique product, service, or re-
sult.”
Unlike ongoing work efforts, projects always and necessarily end. Ideally,
the project ends when the “unique product, service, or result” has been deliv-
ered successfully. Projects also end when the attempt to do so has failed, or
when the customer no longer wants (or can pay for) it. Projects can also evolve
and change as they move forward, based on a better understanding of the ob-
jectives, the need to address problems or challenges as they arise, or changes
in the environment or circumstances surrounding the project.
Project management is defined as “the application of knowledge, skills, tools,
and techniques to project activities to meet the project requirements.” Al-
though this definition is a bit self-referential, it does provide a sense of the
scope and breadth of the discipline. It’s extremely difficult to define the bor-
ders of project management, as project managers must often apply general
management knowledge, technical knowledge, organizational understanding,
and much more in order to accomplish the job. There’s no safe area in which
you can say, “This isn’t part of what a project manager needs to know.”
The concept of progressive elaboration lies at the heart of many project man-
agement concepts, tools, and techniques. When you are first given a project,
it may seem utterly impossible, and that’s not uncommon. But remember the
old joke: How do you eat an elephant? One bite at a time. In project manage-
ment, progressive elaboration means that you take the big, unwieldy project,
and you break it into smaller pieces that you can get your arms around. Each
piece can be defined, and you can plan the steps necessary to accomplish it.
Often, people begin projects without a full understanding of the issues,
problems, and challenges involved. That leads to the other core concept at
the heart of project management: it is an iterative activity. You gain increasing
understanding and insight into the project, allowing you to expand on the de-
tails and confront the problems, risks, and challenges more effectively.
Exhibit 1–1 defines a sample project that we will use as a case study
throughout this course. In Exercise 1–1, you will take the first step toward
managing the project.

xhibit 1–1
Case Study: Establishing a Project Management Office (PMO)
You’ve learned that many organizations establish a Project Management Office (PMO) to provide
guidance, leadership, resources, and technical support to individual projects throughout the organ-
ization, and your CEO has expressed a desire to establish a PMO function in your own organization.
Because you are studying project management, you’ve been asked to lead this project.
In your initial discussions, you discover that the organization has relatively little understanding
of what a PMO is or what it does, and that some managers are skeptical of it. There is a concern
that managers may lose power and authority to the new PMO. On the other hand, several recent
projects have ended up failing, and there is a fear that your competitors, many of whom already
have PMOs, may pull ahead in the marketplace.
You have been directed to establish a PMO in time for the annual stockholders’ meeting, which
will take place in nine months.
Exercise 1–1
Getting Started
Instructions: We will use the Exhibit 1–1 case study, “Establishing a PMO,” throughout this book to
practice the skills we are learning.
When you are first given a project, it’s often the case that the project is not fully fleshed out,
and that’s okay. You normally must go through a process of gaining additional understanding and
insight about the project before you can manage it effectively. Read the following series of ques-
tions. Some of the answers are contained in the case study description, but not all of them. Answer
the questions to the best of your ability. Don’t worry if you can’t answer every question fully—that’s
quite normal at the beginning of a project.
When you have finished, turn to Appendix A: Answers to Exercises and Case Studies at the end
of this course to compare your responses with ours.
1. What is the project that must be accomplished?
2. Why are we doing this project? How will the project benefit us if it is successful?
Exercise 1-1 continues on next page.

Exercise 1–1 continued from previous page.

3. When must the project be accomplished?
4. What people, resources, and budget are available to us?
5. What authority and power do we have to accomplish the work?
6. Who are the stakeholders—the people who will be affected by our project?
7. Does our project face opposition? What is the nature of that opposition? Why are some people
opposed? Can their issues be addressed?
8. Are there any major known risks that we can see at the beginning of the project?
9. How will we measure our success?

PROJECTS AND THE ORGANIZATION

Projects normally take place inside a larger organizational environment, and
no matter how important your project may be, it’s never the only game in town.
Here are some organizational issues that may affect your projects.
Programs and Portfolios

Projects are often grouped into programs and portfolios. A program is simply
a group of projects that are managed together. This is usually because their
subject matter is similar. The IT department normally manages most IT pro-
jects, because it has the expertise and technical capability to do so.
A portfolio, on the other hand, organizes projects in terms of their organi-
zational perspective. Individual IT projects support many different parts of
the organization. If we are developing a new product, it might include project
components in IT, engineering, marketing, warehousing and distribution, in-
dustrial design, and many other areas. The portfolio cuts across organizational
boundaries and ties these very different projects together to achieve an overall
strategic objective.
Your project may be part of both a program and a portfolio, giving you
two sets of stakeholders to manage. You must understand the needs and goals
of both in order to manage your project effectively.
Project Management Office (PMO)

Our case study project involves establishing a Project Management Office
(PMO), but exactly what that is can vary by organization.
PMOs consolidate various project-related functions into a central office.
Depending on the organization, the PMO may establish policies, allocate re-
sources, provide technical support to individual project managers and teams,
consolidate status reporting, improve project management skills through train-
ing and coaching, and provide centralized information to senior management.
PMOs come in various flavors: supportive, controlling, and directive. A
supportive PMO primarily provides technical support to projects: templates,
best practices, training, coaching, and lessons learned. Controlling PMOs set
and enforce policy. Directive PMOs control and manage the projects them-
selves, centralizing control. There may not always be a clear dividing line among
these functions, so your mileage may vary.
Organizational Structure and Project Management

Most organizations traditionally operate as functional organizations, in which
the individual departments have particular technical functions: IT, marketing,
HR, engineering, sales, etc. This is excellent for ongoing operational work,
but less effective for projects, because projects frequently cut across organi-
zational boundaries.
Projectized organizations are completely organized around projects, with
a small central core providing overall leadership. A movie studio is a good ex-
ample. Each individual movie is its own project, a business unit in itself. It
contains all the different departments: set builders, electricians, costumers,

special effects, transportation, and craft services. This gives maximum control
to the project manager (director or producer) at the expense of significant du-
plication of effort.
Matrix organizations seek to have the best of both worlds (and occasion-
ally end up with the worst of both worlds) by combining elements of func-
tional and projectized based on the needs of the individual organization. In
weak matrix organizations, project managers have limited cross-departmental
authority and primarily coordinate and persuade. Strong matrix organizations
give project managers substantial authority to direct and control resources
even though they live in functional departments, and balanced matrix organ-
izations operate somewhere in between.
No organizational structure is right for all situations; each contains both
advantages and disadvantages. As a project manager, you need to understand
your own organizational environment (which may include unofficial as well
as official characteristics) in order to operate effectively. It’s never the case
that every decision and element will be optimized for your specific project
needs (nor should it be), so you will always need to adapt your project to its
environment.
Think About It . . . Organization
Is your organization primarily functional, projectized, or matrix? Do you have a PMO, and if so,
what type is it? What do you see as the advantages and disadvantages as far as your projects are
concerned?
THE PROCESS OF PROJECT MANAGEMENT

Because projects are temporary, with clear beginnings and ends, they follow
a natural process, often described in terms of the five component process groups
shown in Exhibit 1–2. Although these process groups are designed to take you
from the beginning of a project to its end, they also involve a fair amount of
iteration, especially as project monitoring and control identifies issues that
require adjustment as you move forward in the project.
Project Initiation
Before there is a project, there is some sort of need—a gap between where
we are and where we want to be. There may be more than one way to bridge

xhibit 1–2
The Five Project Management Process Groups
Project Project Project Project

Initiation Planning Execution Closeout
that gap, but eventually someone in authority (customer, project sponsor, ex-
ecutive) decides on the basic direction, and that leads to a project.
A project is not only temporary and unique, but also purposeful. Even if
the project is accomplished on time, on budget, and meets requirements, it’s
hard to call it successful if it doesn’t achieve its goal.
The process of project initiation involves defining this potential project,
determining how much it is likely to cost and how long it is likely to take, and
deciding who will lead the project and who will staff it. Though it’s ideal if
you’re involved in that process if you will eventually be the project manager,
it’s quite common for most of these major decisions to be made by other peo-
ple before you receive the project assignment.
Whether or not you were part of the process of defining the project, when
you get the assignment it’s a good idea to perform your own due diligence be-
fore committing yourself to the work. In particular, it’s desirable to take a good
hard look at assumptions and constraints.
Assumptions are things we believe to be true though we don’t actually have
any proof. It’s often necessary to make assumptions. In a research project, you
must assume that an answer actually exists—even though you may discover
later that it doesn’t, or that it isn’t at all what you expected or wanted. Often,
such factors as the budget and deadline rest on the assumption that there won’t
be any other important projects or emergencies that will interrupt you. Some
assumptions are more realistic or likely than others, but all assumptions need
to be out in the open where people can examine them properly.
Constraints are things that limit your choices. A deadline is a constraint;
so is a budget. Rules, laws, and policies are constraints. The particular skill
sets and talents available to you for the project are constraints. Sometimes
constraints are negotiable; other times they are not. The nature and extent of
constraints has a major effect on your ability to accomplish the project. Un-
derstanding them from the beginning is a crucial element in your eventual
success.

The project initiation phase ends with a project charter. That’s the formal,
written document that authorizes the project. The project charter takes many
different forms in different organizations, and often isn’t called by that name.
Still, it’s vital to have a clear, bright line that separates just talking about a
project from a formal directive to get started on it.
Think About It . . . New Projects
How is a new project established in your organization? Is there a formal project charter? Is there
another document that accomplishes the same thing? What works well or needs improvement in
how you start a project?
Project Planning
Project planning includes all the tools and processes necessary to define, or-
ganize, and develop the course of action that will accomplish the project goals.
It includes plans to manage schedule, cost, scope, risk, procurement, quality,
human resources, and stakeholders.
It is often said that failing to plan is planning to fail. Most of the tools
and techniques generally thought of as “project management” are actually
tools for planning: the work breakdown structure, Gantt charts, network dia-
grams, and the like. If project management is an “iterative process of progres-
sive elaboration,” as we’ve said, then project planning is the methodology to
accomplish this.
Many people confuse a project schedule with a project plan. Although
clearly a schedule is part of a plan, so is the budget, the communications strat-
egy, the risk management approach, and many other elements. Because proj-
ects differ, individual project plans may emphasize one of these elements more
than another.
Unless the project is fairly simple, planning doesn’t end just because
you’ve started work. Often, important parts of the project remain obscure until
some preliminary activities are complete. If you’re going to test a prototype
of whatever you’re building, the outcome of the test will reveal what corrective
actions are necessary. Until the test is performed, you don’t know what those
actions might be, and therefore you can’t do a whole lot of detailed planning
until you reach that point. Often, you begin with a plan that is detailed in its
opening phases but becomes increasingly sketchy as it extends into the future,
and you fill in the details (iterate and progressively elaborate) as you gain new
information.

Project Execution
The project plan describes what you are supposed to do, and project execution
is the process of actually doing it. In project execution, you assign project ac-
tivities to people, allocate resources (including, but not limited to, money),
and work with customers and other stakeholders. Although project execution
usually takes the majority of the total project schedule, budget, and other re-
sources, it doesn’t involve many specific “project management” techniques
and thus tends to get relatively little space in a book/course such as this.

During the execution of the project, the project manager must monitor how
things are going. Is the project on schedule and on budget? Does the work
being done meet the requirements, and is it of sufficient quality? Have cus-
tomer needs and requirements changed? Have we experienced unforeseen
problems or issues?
Project monitoring is the process of obtaining information to measure the
project performance against the baseline, and can involve status meetings, re-
ports, and direct measurements of the work. Project monitoring includes
watching for areas that may grow into problems or challenges so that you can
take early action. It also involves preparing necessary reports and briefings
for customers, project sponsors, and other stakeholders.
Project control is the process of adjusting the project based on this infor-
mation. If the schedule, budget, or other elements of the project should devi-
ate from the plan, the project manager must determine necessary corrective
or preventive action. If customers or other stakeholders want changes made
to the project, project control includes the change management process.
Project Closing
Because projects end, they need to be closed. Project closing is the process of
ensuring that the project deliverables have been accomplished and are satis-
factory in the eyes of the customer, that they have been transferred to their
appropriate destinations or new owners, that any contracts or procurement
actions have been completed, that project team members and other resources
are released to do other work, and that the necessary paperwork is done and
archived. The closing process also includes the process of lessons learned.
What if a project is cancelled before it is completed? Sometimes projects
fail, customer needs change, or other demands require the resources allocated
to your project. No matter why the project ends, there’s still paperwork, doc-
umentation, releasing resources, and preparing lessons learned. Therefore,
you must conduct project closeout for every project, regardless of the circum-
stances of its end.
Strangely, many project plans—even those done by highly experienced
project managers—often neglect the closeout process and allocate no time or
resources to its performance. This is an embarrassing mistake, but one that is
easily corrected. The project deadline and the actual end of the project aren’t nec-
essarily the same thing. The deadline usually refers to the point in time at which

you complete the actual work of the project; many closeout activities, such as
lessons learned and archiving, must necessarily happen after the deadline.
Think About It . . . Closing Out
Do you have a formal closing out process for projects? Does it include “lessons learned”? What
works well or needs improvement when it comes to completing projects in your organization?
THE MANY HATS OF A PROJECT MANAGER

One of the most interesting, rewarding, and challenging aspects of being a
project manager is the breadth of skills and activities required. In some ways,
a project manager is like a CEO for the project, responsible for the full range
of management disciplines. The PMBOK® Guide describes this concept with
what it terms knowledge areas.
Up until the fifth edition of the PMBOK® Guide, there were officially only
nine knowledge areas; the fifth edition added a tenth. Depending on the nature
and context of your project, you may not give equal focus to each knowledge
area, but you normally need at least a basic understanding of all of them in
order to be an effective project manager.
For the purpose of clarity, these ten knowledge areas have been grouped
as shown in Exhibit 1–3. Although project integration management comes at
the top, we’ll discuss that one last, because it brings together all the other is-
sues.
Project Time Management

The process of developing and managing the project schedule is known as
project time management. The project manager needs to have a clear understand-
ing of the timeframe of the project, such as the presence of any interim or
final deadlines. Time management involves determining the activities neces-
sary to accomplish the scope, the sequence in which they will be performed,
the determination of what resources will be given to each activity, estimating
how long each activity will take (this is often influenced by the resources you
assign to it, giving you some flexibility), and putting everything together into
a comprehensive project schedule.
Formal projects often use scheduling tools such as the Gantt chart or net-
work diagram to organize and present a schedule. In simpler, smaller, and less
formal projects, sometimes a simple calendar is sufficient. Either way, project

xhibit 1–3
The Ten Project Management Knowledge Areas
Core Constraints
Project
Project Time Project Cost
Scope
Management Management
Management
People
Project Project
Project
Communi- Human
Stakeholder
cations Resources
Management
Issues
Project Project
Project Risk
Quality Procurement
Management
time management also includes the process of monitoring and controlling the
schedule to ensure the project stays on track.
Project Scope Management

Project scope consists of all the work necessary to complete the project, and no
more. Scope management includes developing the detailed project require-
ments, writing a scope statement that summarizes the work to be done, devel-
oping the work breakdown structure (WBS), obtaining agreement from key
stakeholders on the scope, and monitoring and controlling the performance
of project scope during the life of the project. If changes are made to project
scope, project scope management includes the steps necessary to integrate
those changes into the overall scope management plan.

Project Cost Management

Project resources usually cost money, but not always. If you have particularly
scarce resources that have to be allocated carefully, or (worse) shared with
other projects, or if tools and materiel are in short supply, those can also count
as project costs. Generally, however, project cost management involves everything
to do with the project budget.
Sometimes, a project begins with a fixed amount of money, and your job
is to figure out how to accomplish the work within that cost constraint. Other
times, you are charged with analyzing the project to determine its likely cost,
and offer a budget recommendation for your management and customers to
consider. Some costs are estimates: you don’t know exactly what they will turn
out to be, but you may be able to establish a probable range. Other costs are
fixed: you know in advance how much they will cost with a pretty high degree
of certainty. And still other costs are variables: you may know how much per
hour a resource costs, but the total cost of that resource will vary based on
how many hours of work turn out to be needed.
Because of uncertainty, cost management often involves determining an
appropriate contingency allowance or contingency reserve (these terms mean slightly
different things, as we’ll learn later), and allocating contingency money in re-
sponse to problems that crop up.
Project Communications Management

It’s been estimated that project managers can spend as much as ninety percent
of their time communicating: staff meetings, briefings, work assignments,
problem-solving, telephone calls, e-mails, and more. Sometimes, you might
feel that you come to work for eight hours a day merely to handle meetings
and e-mails, and then need to come in early or stay late to do the actual work.
Given the extent and importance of project communication, it’s unsur-
prising that this vital area is considered a knowledge area all by itself. Project
communications management includes the preparation and dissemination of proj-
ect information to stakeholders: progress reports, issues, and other matters.
Different stakeholders have different needs, objectives, and interests, and
therefore need different types of information organized in different ways.
Project team members need information about the jobs they are supposed
to do, any circumstances that may affect their ability to do so, and in return
need channels to report risks, problems, and other issues that need to be ad-
dressed. Project customers need overall status information, including interim
reports on quality and performance, as well as early warning of any potential
issues that might jeopardize accomplishing the project on time and on budget.
Project sponsors and internal managers need to monitor resource consump-
tion, and in return must make decisions and choices that affect the project.
The act of calling communications management a knowledge area tells
you, the project manager, that it is important that you don’t leave communi-
cation to chance or handle it in an ad hoc manner. Planning communication
makes it easier to organize and disseminate information, identify key issues,
and keep track of who has been informed of what.

Project Stakeholder Management

In the fifth edition of the PMBOK® Guide, a new knowledge area was identified
and added for the first time: project stakeholder management. Though there is
overlap between this knowledge area and communications management,
stakeholder management is a much larger and more complex discipline. In
some ways, it’s the polite way to discuss the political dynamics and issues that
can surround a project and dramatically complicate the life of the project
manager and team.
Even if politics is a minor consideration, stakeholder management is still
important and requires planning and effort. Stakeholders consist of all the in-
dividuals and groups with a “stake” in the project. Some stakeholders are rel-
atively obvious: the customer, the sponsor, the project manager, and the team.
But the universe of stakeholders may also include vendors, the general public,
regulatory agencies, interest groups, and even the competition.
Stakeholders can be roughly sorted into positive stakeholders, whose in-
terests and goals align with your project; negative stakeholders, whose interests
are harmed or compromised by your project’s process or results; and tangential
stakeholders, who have an interest in some specific element of your project
but are not affected by the project as a whole. Some stakeholders have sub-
stantial power and authority over your projects, and others less. Your project
may have a minor effect on certain stakeholders and a major effect on others.
In project stakeholder management, you must identify stakeholders, de-
velop management strategies for dealing with them, engage stakeholders in
the project as appropriate, and ensure that stakeholders have appropriate in-
formation and support.
Project Human Resources Management

Project managers are a little bit like Blanche Dubois in A Streetcar Named Desire;
they “rely on the kindness of strangers.” Unlike conventional supervisors, proj-
ect managers often lead temporary teams because projects must end. If your
department does the same kind of project over and over again, you may have
project team members who are also your employees, but that’s less common.
More often, the project team is put together for the specific project, and in-
dividual team members typically have permanent organizational homes and
regular supervisors. This can create extra challenges for the project manager.
Project human resources management is everything involve organizing,
recruiting, managing, developing, and leading the people who must actually
perform the project work, whether they report to you in a conventional sense
or not. Sometimes, you’re assigned a project team at the beginning, and you
must accomplish the work using those resources. Other times, you develop a
project plan to determine what resources you really need, including consid-
eration of skill sets, experience level, and availability, then go about recruiting
the people you need.
There’s often a dimension of team building that’s part of a project effort.
Getting people to work effectively together isn’t automatic or guaranteed.
Team members may not be co-located, but rather scattered among different
offices and departments—sometimes, in different states or countries. Team

members may be assigned full-time to your project for its duration, but may
also be available to you only on a part-time basis.
Developing a project plan involves assigning the appropriate people to
accomplish activities, making sure people aren’t inadvertently double-booked
on multiple assignments, overseeing and managing their work, and handling
the associated documentation, such as time reporting.
Project Quality Management

The scope of the project, as we’ve learned, is the work that goes into accom-
plishing its goals. Just because the work is done, however, doesn’t automatically
mean that it’s good enough to accomplish its purpose.
There’s an overall discipline of quality management that’s practiced in many
organizations. It comes in many flavors: Six Sigma, TQM, Kaizen, and others.
While there are important differences among these, there are also some key
similarities. First, you have to measure it to manage it, so all quality disciplines
begin by defining quality in practical, measurable terms. From a project man-
agement perspective, the definition of quality is incorporated into the project’s
requirements. A requirement is a condition or capability that must be present
in the outcome of the project. Requirements should be written clearly, unam-
biguously, and measurably in order to be managed.
Quality assurance is the process of ensuring that the quality objectives of
the projects are being met. Quality control is the inspection and documentation
that goes along with it. If your organization practices a particular quality dis-
cipline, it most likely involves elements of continuous improvement. Part of the
goal of project lessons learned is to support the idea of continuous improve-
ment: making future projects better. However, there’s a limit to the idea of
continuous improvement within an individual project, because sooner or later
the project has to end.
Project Procurement Management

Unless the project is relatively small, it’s likely that you’ll acquire at least some
of the resources, products, or services from outside your organization. Project
procurement management involves all the activities in purchasing or acquiring
outside products or services for your project. Sometimes you’re the buyer, and
sometimes you’re the seller. Either way, contract management can be a major
part of your responsibilities as project manager.
Project procurement management includes making “make or buy” decisions,
identifying potential vendors or buyers, preparing proposals and soliciting
bids, selecting and awarding contracts, and managing the procurement rela-
tionship. Within a large contract, you may use all the other knowledge areas:
scheduling, budgeting, scope and quality management, communications, and
risk. A large and complex procurement can be a project in its own right, or a
“project within a project.”

Project Risk Management

Things happen. No matter how well you plan and organize your project, you
cannot eliminate risk as a potential project concern. Project risk management in-
volves establishing risk management policies and systems, identifying risks,
analyzing and prioritizing those risks, developing responses and strategies to
deal with them, and monitoring and controlling the risk environment through-
out the project.
A risk is an uncertain event or condition that, if it occurs, affects one or
more project objectives, or has an external impact of concern to the organi-
zation, the customer, or the project team. Risks themselves are subdivided into
threats, or risks with negative impact, and opportunities, or risks with positive
impact.
Some risks consist only of threats. These are known as pure risks or insur-
able risks, and in general, if you can deal with them at an appropriate cost,
you’re better off. Other risks combine opportunity and threat into the same
choice. New technology might hold the promise of improved performance
(opportunity) along with the potential of lower reliability (threat). Balancing
threat and opportunity is known as business risk, and avoiding that kind of risk
isn’t always in your best interest. In fact, some projects are themselves business
risks: we take on a challenging project when we are not certain of success
based on the potential benefit.

The tenth and final knowledge area is known as project integration management,
and it describes the project manager’s responsibility to bring all the disparate
elements of the project together and manage the project toward its goal. The
project processes and project knowledge areas frequently interact, and some-
times even blend together.
Project managers have to negotiate the project goal, and often take a lead
role in preparing the project charter. They bring together the entire project
plan, manage project work, oversee change control, and manage closeout.
They are the lead point of contact with major stakeholders and the customer,
and are the central agent in the identification and resolution of projects.
Not only does project integration management involve bringing project
elements together to achieve the goal, but it also involves ensuring that the
project goal actually meets the customer need that led to the project in the
first place! There are all too many cases in which the project was (more or
less) completed, but turned out to be useless in practice—the project man-
agement version of “the operation was a success but the patient died.”
In Exercise 1–2, we will apply the ten knowledge areas to our case study
project.

Exercise 1–2
Knowledge Areas
Instructions: In this exercise, we build on the case study first defined in Exhibit 1–1 and Exercise
1–1, fleshing out what we currently know about each of the ten knowledge areas as they apply to
this project. For each knowledge area, record all available information you have learned to this
point.
As before, you normally (both in the exercise and in real life) have limited information and will
not be able to answer questions fully at this stage. We will continue the process of progressive
elaboration in an iterative process as the project moves forward.
1. Project Integration Management. What we know about our role as project manager in bringing
this project together and leading it to a successful conclusion.
2. Project Time Management. What we know about the schedule and any time constraints.
3. Project Scope Management. What we know about the work that must be done, and the work
that is not included in this project.
4. Project Cost Management. What we know about the budget, resource availability, and anything
else we might spend to accomplish the project.
5. Project Communications Management. What we know about the need to report and com-
municate with others during the project.

Exercise 1-2 continued from previous page.
6. Project Stakeholder Management. What we know about people affected by the project, their
interests, and their issues.
7. Project Human Resources Management. What we know about the people and skills we need
to accomplish the work.
8. Project Quality Management. What we know about factors that determine whether this project
will meet the needs for which it was established.
9. Project Procurement Management. What we know about any products or services to be ac-
quired outside the organization.
10. Project Risk Management. What we know about project threats and opportunities.

While projects have existed for the duration of civilization,

project management as a formal discipline began in the early
years of the 20th century, but did not hit its stride until the late
1950s. Project management has grown from a secondary skill
to a primary discipline, and is considered essential in many
organizations.
A project is “a temporary endeavor undertaken to create
a unique product, service, or result,” and project management
is defined as “the application of knowledge, skills, tools, and
techniques to project activities to meet the project requirements.” Project
management usually involves the progressive elaboration of the project into
smaller, more manageable components. This is done in an iterative fashion,
with each iteration providing additional detail and understanding.
Projects take place inside organizations, and are often grouped into pro-
grams (projects managed together) and portfolios (projects organized around
strategic objectives). In many organizations, a Project Management Office
(PMO) provides support and direction to individual projects. Organizations
themselves can be functional, projectized, or matrix, each with advantages and
disadvantages.
A project typically follows a life cycle described in terms of five process
groups: project initiation, project planning, project execution, and project
closeout, with project monitoring and control providing feedback and over-
sight to keep the process on track.
Project managers wear many different hats. The ten knowledge areas of
project management show the breadth of knowledge, skills, and insights re-
quired of the project manager. Within the overall umbrella of project integra-
tion management, project managers work with the core constraints of time,
cost, and scope; the people issues of communications, stakeholder manage-
ment, and human resources; and related issues of quality, procurement, and
risk. These knowledge areas normally show up throughout the project life
cycle, although they may have greater or lesser impact on a given project.

Review Questions
INSTRUCTIONS: Here is the first set of review questions in this course. Answering the questions fol-
lowing each chapter will give you a chance to check your comprehension of the concepts as they are presented
and will reinforce your understanding of them.
As you can see below, the answer to each numbered question is printed to the side of the question.
Before beginning, you should conceal the answers in some way, either by folding the page vertically or by
placing a sheet of paper over the answers. Then read and answer each question. Compare your answers
with those given. For any questions you answer incorrectly, make an effort to understand why the answer
given is the correct one. You may find it helpful to turn back to the appropriate section of the chapter and
review the material of which you are unsure. At any rate, be sure you understand all the review questions
before going on to the next chapter.
1. Two fundamental characteristics of a project are: 1. (c)

(a) programs and portfolios.
(b) process groups and knowledge areas.
(c) temporary and unique.
(d) PERT and CPM.
2. In project management, an assumption is: 2. (c)

(a) something to be avoided at all costs.
(b) something that limits your choices and options.
(c) something treated as true in the absence of certain knowledge.
(d) something that only affects the project on which you are working.
3. One tool used in project scope management is: 3. (b)

(a) the Gantt chart.
(b) the work breakdown structure (WBS).
(c) the project communications plan.
(d) the organization’s Six Sigma policy.
4. In a portfolio, projects are grouped: 4. (d)

(a) by functional area.
(b) to enable the PMO to control them effectively.
(c) by size and organizational impact.
(d) based on organizational strategic objectives.
5. The project process that links to all other project processes is known as: 5. (d)
(a) project planning.
(b) project intiation.
(c) project management office.
(d) project monitoring and control.

Defining the Project
2
Learning Objectives
By the end of this chapter, you should be able to:
• Explain the importance of problem definition
in project initiation.
• Describe the process of project initiation.
• Describe the differences and similarities be-
tween projects and phases.
• Identify the characteristics of the three types
of stakeholders; identify at least five stake-
holders and determine their characteristics;
prepare a stakeholder register.
• Define constraints and provide examples; de-
scribe the triple constraints and the hierarchy
of constraints.
• Define assumptions.
• Describe the benefits of a project charter and
list elements that it should contain.
• List the key issues in obtaining approval and
buy-in.
• Explain why an initial project objective is not
necessarily the final one.

Reading 1 hour 25 minutes
Exercises 2 hours
Total Time 3 hours 35 minutes

FROM PROBLEM TO PROJECT

A project is a means to an end, not an end in itself. That important detail can
become obscured in the process of turning a problem (or opportunity) into a
project. “We want a new trade show display” sounds like a project, but there’s
not nearly enough information or context to allow you to get started.
Why do you want a new trade show display? Do you have one already?
What’s wrong with the current one? What is the trade show display supposed
to accomplish for you, and how much is that worth? What features or benefits
of the existing trade show booth are still desirable? How long do you expect
a trade show booth to last?
Notice that there can be a wide range of possible answers. Here are a few.
1. Our current trade show display is old and showing a lot of wear and tear.
2. We used to get 20 linear feet of space and our business has expanded so
much we now need 40 feet.
3. Our competition has upgraded their trade show display and our current
one pales by comparison.
4. We have important new product lines that aren’t represented in the current display.
Each answer leads to a different project. If the only problem is that our
existing display is showing its age, we will proceed differently than if we need
to double its size. If we’re adding new products to the existing line, we use dif-
ferent measurements than if we are trying to keep up with the competition.
When you are selected as the project manager, that raises an immediate
concern: many important decisions and choices about your project may have
already been made by the time you get your assignment. The rationale behind
those decisions and choices won’t always be explained to you, especially if you
don’t ask. This isn’t necessarily a conspiracy of silence (although hidden agen-
das have been known to derail projects), but rather an assumption that you al-
ready understand them or that it isn’t necessary for you to understand them.
Although you don’t always need to know everything about how your project
came to be, it’s a good idea to begin by finding out as much as you can about the
decisions that have been made before your selection. The most important ques-
tion in project management—and in practice the most overlooked—is “Why?”
The process of turning a general statement into an actual project is
known as project initiation.
Think About It . . . Problem Definition
Take a real-life project you’re involved in and define the problem, opportunity, or issue it is intended
to address. Do you think the project as defined will properly address the issue?

DEFINING THE PROJECT 23
PROJECT INITIATION
The PMBOK Guide® defines project initiation as “the processes performed to
define a new project or a new phase of an existing project.” These include
defining initial scope, budget, and time parameters, although they may evolve
significantly in the planning process. The major stakeholders are defined and
their interests and goals are identified. And somewhere in that process the
project manager is selected.
We normally think of a project as something with a defined beginning
and an end. From a technical perspective, that’s correct. We’ve just seen, how-
ever, that there’s a discussion process that precedes the project. Because a proj-
ect is a means to an end, there’s also an aftermath of a project, in which the
product, service, or result provides the benefit for which we did it in the first
place. Whereas project management as a discipline focuses on the project it-
self, a wider management perspective includes awareness of what comes be-
fore and after.
Some of the specific elements in project initiation include:
• Definition of the initial scope of work
• Preparation of the business case for the project
• Consideration of alternatives
• Consultation with stakeholders
• Preparation of the project charter
• Approval of the project
PROJECT OR PHASE
Notice that the PMBOK® Guide definition mentions both a new project and a
“new phase of an existing project.” Let’s imagine that our reason for upgrading
the trade show exhibit is based on a competitive analysis study. Of course, a
trade show exhibit isn’t a means to an end either. If we’re launching a major
new product line, the new trade show exhibit is part of the marketing push.
And let’s not forget the development of the new product line, which might
include engineering, industrial design, manufacturing, market testing, and
many other activities.
Each of these can be thought of as a separate, independent project, or as
a phase of an overall project, “bringing a new product to market.” Developing
a new pharmaceutical drug normally involves pure research, in which many
different compounds are studied, followed by initial testing, followed by fur-
ther testing, followed by the FDA approval process, followed by marketing.
Large and complex projects frequently take a phased approach. At the end
of each phase, there’s an opportunity to decide whether the project should con-
tinue, or whether it should be modified in light of what has been learned pre-
viously. Sometimes, the lead role on the project moves from one department or
team to another: the chemists working on a new drug turn it over to testers who
hand it to the people who manage the approval process, who turn it over to the
marketing team. There may be an executive overseeing the entire process, but
different individual project managers are responsible for specific phases.

If your project actually is a phase in some other, larger project, you need
to have at least a general understanding of the overall flow and how your par-
ticular section fits in. Whether or not your project is also a phase, it’s still a proj-
ect: a temporary and unique activity with a defined beginning and an end.
Exhibit 2–1 shows how a phased approach to a large project works for new prod-
uct development, a new shopping center, and a new IT system. Notice that each
phase contains the basic processes of a project, first shown in Exhibit 1–1.
Think About It . . . Project or Phase
Is your project complete in itself, or is it a phase in some larger project? Describe the larger project
and identify the phases that precede and follow yours.
STAKEHOLDERS
Stakeholders, as you’ll remember, are people or groups who are affected by
the project or who have an effect on the project. It can be the outcome of the
project, a particular task or activity of the project, the resources used by the
project, or decisions related to the project.
Stakeholders can be aligned with your project (positive stakeholders), be
opposed to your project (negative stakeholders), or have an unrelated second-
ary interest in your project (tangential stakeholders). Stakeholders can also
be mixed: positively aligned in some areas and opposed in others.
Stakeholders can have varying levels of impact on your project, and your
project can have varying levels of impact on stakeholders. Stakeholders can have
a stake in the entire life cycle of the project, or only in part of it. Some stake-
holders are hugely important in the project, and deserve a great deal of your
time, effort, and attention. Others are relatively minor, and require much less.
During project initiation, you should identify as many stakeholders as you
can, and determine their characteristics with respect to your project. However,
the stakeholder environment can change. You should keep a continuing eye on
your stakeholders and adjust your plan and approach as necessary.
Common Stakeholders
Some stakeholders commonly exist on almost every project. These include:
• Project sponsor: The manager or executive, usually internal, with over-
sight responsibility for the project. The project sponsor is usually the one
who makes major policy decisions.

• Customer: The person or group that has requested or purchased the prod-
uct, service, or result. Customers may be external to the organization or
internal. If internal, they may overlap with the project sponsor.
• Project manager: The person directly charged with managing and leading
the project. Though this is most often you, in a phased project, there may
be other project managers working before, after, or in parallel on elements
of the same overall project.
• Project team members: Project team members are those people responsi-
ble for performing specific project activities. Team members can work full
time on your project throughout the length of the project, but can also work
part-time or only on specific activities. They may or may not (more often
not) report to you in a formal supervisory relationship. Although they are
usually part of your organization, they may also be consultants or tempo-
rary hires. Team members may support several projects simultaneously,
and may also have regular, permanent jobs.
• Your own supervisor or manager: Though your supervisor or manager
may also be the project sponsor, this is not always the case. You may have a
permanent organizational home and job responsibilities, and you may need
xhibit 2–1
Phases
Each phase is a project in its own right, using the process approach shown in Exhibit 1–1.
New Product Introduction

Project Project Project Project Project Project Project Project Project Project Project Project Project Project Project Project
Initiation Planning Execution Closeout Initiation Planning Execution Closeout Initiation Planning Execution Closeout Initiation Planning Execution Closeout
Project Monitoring and Control Project Monitoring and Control Project Monitoring and Control Project Monitoring and Control
Design Phase Development Phase Manufacturing Phase Marketing Phase
New Shopping Center
Architecture Approvals Construction Recruiting Tenants
Project Project Project Project Project Project Project Project

Initiation Planning Execution Closeout Initiation Planning Execution Closeout
Project Monitoring and Control Project Monitoring and Control
Build-Out Grand Opening
New IT System
Need and Systems Analysis Programming Testing Training and Implementation

to spend some of your time and effort on permanent job responsibilities

even though you are serving as a project manager. Your own supervisor or
manager may be supportive of your project management role, or may be
resentful and unhappy that your time and energy is otherwise occupied.
• End user(s): End users are the people who will use the product, service, or
result that the project is creating. They may not be the actual customers,
and they may or may not be within your organization. You may not always
know who the end users are, or be able to reach them directly.
There may be some overlap among these roles. The customer may also
be the project sponsor, who may or may not also be in your management chain.
Other Stakeholders
You shouldn’t confine your search for stakeholders to these common cate-
gories. Some projects have great public visibility and may engender contro-
versy. If your project uses outside vendors, they too are stakeholders. While
on one hand, vendors are positive stakeholders with a strong interest in the
success of your project, they also have a potential conflict of interest: their
business ends with your project.
Earlier, we mentioned a pharmaceutical project, which requires regula-
tory approval. The regulators are project stakeholders as well. People man-
aging other projects in your organization are stakeholders in your project if
you all draw your resources from the same pool: more for you can mean less
for them. If assigning credit for success or blame for failure can be given to
different people or groups, they become stakeholders as well. Your competi-
tors are stakeholders in your project, because your success or failure has a di-
rect impact on them.
In one sense, there’s an almost unlimited universe of potential stakehold-
ers, but fortunately they aren’t all equally important. Some stakeholders re-
quire significant attention, but you may be able to ignore others with little or
no consequences.
Issues in Stakeholder Management

Identifying stakeholders is the first step. Analyzing and prioritizing stakehold-
ers is the second step. In the project initiation phase, you don’t necessarily go
all the way through the process of planning stakeholder management, but cer-
tain stakeholder issues will take center stage from the very beginning of the
project.
There are, as we’ve seen, many different considerations when thinking
about stakeholders. Exhibit 2–2 provides a list of questions to organize your
thoughts about the different stakeholders, illustrated using the trade show ex-
hibit project we defined at the beginning of this chapter.
Exercise 2–1 will then take you through the process of identifying and
analyzing stakeholders for the PMO project we began in the previous chapter.
In practice, preparing a stakeholder register like the one shown in this exercise
is an effective way to organize and track stakeholder information.

Exercise 2–1
Stakeholder Register
Instructions: Complete the stakeholder register for any stakeholders you can identify for the PMO
project we began in Chapter 1. The first stakeholder, the CEO, has been completed as an example.
Stake- Project Areas of Your Impact Their Impact Timing Management

holder Role Concern on Them on You Strategy
CEO Originator (1) Improve Potentially CEO controls Initial project Actively involve
of the project major effect timing, definition, CEO in
project performance/ on the CEO’s budget, and approval of requirements
lower failure reputation ultimate final results; process,
rate, (2) and job approval less involved provide updates
Show security in day-to-day throughout the
stockholders project, escalate
progress in any major
this area issues, support
public rollout at
stockholder
meeting,
keep happy.

xhibit 2–2
Analyzing Stakeholders
1. Define the stakeholder. Name and title if an individual; or the group if collective. Beware of
groups that may not all think the same way: the “general public” may contain both supporters
and opponents of your project. What is the major interest of each stakeholder?
Possible choices:
• Top management/CEO: Overall look and feel
• Marketing and sales executive and team: How well it works for their needs
• Exhibit vendors: Their capabilities, time constraints, and resources
• The trade show organization: Rules and standards for exhibits
• Trade show attendees: Does the exhibit attract them?
2. Impact of your project on the stakeholder. Impact can include both the work of the project
(consumption of resources, taking people away from other work, cost) and the outcome of the
project (what it does or doesn’t do, how well it works).
For the marketing and sales team, potential impact issues may include:
• Does the cost of the new exhibit come out of their budget?
• Will they have to supply team members to work on the project, taking them away from other
work?
• Will the final exhibit be easy to work in? Comfortable? Attractive?
• Will it attract the right customers?
• Will it look at least as good if not better than the competition?
• How much work will it be to set it up and take it down?
• Is is complicated to operate or prone to break down (fancy electronics, displays, computers)?
3. Impact of the stakeholder on you. What power does the stakeholder have over your project?
Is their cooperation and support necessary to your success? Must you do what they say? Do
they control access to resources, staff, and money?
For the marketing and sales team, potential issues may include:
• Are they driving the project or is it coming from the CEO/executive team?
• Do they really want a new exhibit?
• Do they decide how much money and which resources you get?
• What authority do they have to set requirements for the project?
• If they ask for something you believe is not feasible within the time and cost constraints, must
you accommodate them, or do you have the authority to refuse?
• If they are not pleased with the final result, even though you have met the requirements, what
will the consequences be for you?
4. Timing. Will this stakeholder be a stakeholder for the entire project, for specific phases of the
project, or for a single aspect of the project?
For the marketing and sales team, potential issues may include:
• Are they part of the decision whether to do the new exhibit?
• Do they get to approve the design?
• Will they be involved in vendor selection?
• Will they be involved in the actual work of the project?
• Will they approve the final result?

CONSTRAINTS
A project constraint limits your choices. If you have a budget of $50,000, you
aren’t supposed to spend $60,000. If you need to get the project done in time
for the stockholders’ meeting, there’s a consequence if you get it done three
weeks after the meeting. If your product must conform to a regulatory stan-
dard, it’s not successful if it fails to do so.
Every project has constraints. Depending on the constraints, the identical
project can be very easy or operationally impossible—or anything in between.
At the beginning of the project, it’s vital to get a handle on the constraints.
Some constraints may be negotiable, and others are fixed in stone.
Everyone’s heard the classic management joke: “Did you want it good,
fast, or cheap? Pick two.” This reveals one of the key concepts in project man-
agement: the triple constraint. Although projects can have many constraints, al-
most every project has the same three at the core, as shown in Exhibit 2–3.
xhibit 2–3
The Triple Constraint
It’s usually not a problem to be ahead of schedule, under budget, and exceeding performance.
Therefore, the triple constraints represent the least you can do and still call yourself successful.
• How long do we have? (Time constraint)

• How much can we spend? (Cost constraint)
• What must we accomplish? (Performance or scope)

All three constraints are not necessarily defined at the outset. When John
F. Kennedy said, “I believe that this nation should commit itself to achieving
the goal, before this decade is out, of landing a man on the moon and returning
him safely to the Earth,” he defined the time constraint (“before this decade
is out”) and the performance goal (“landing a man on the moon and returning
him safely to Earth”), but the cost constraint is nowhere to be found. That, of
course, doesn’t mean there wasn’t going to be a cost constraint, but merely
that it was still in the process of being analyzed and negotiated.
The “pick two” joke also reminds us that constraints are not always cre-
ated equal. Is it more important to bring the astronauts back alive or to stay
within the budget? What about “before the decade is out”?
Each project has its own priority. Sometimes the deadline is literal. Across it,
the project fails. If you lose, being on time and on budget may be scant com-
fort. Cost issues rule when the money or other resources just don’t exist, or
aren’t available to you. If you don’t have it, you can’t spend it and you can’t
use it. Finally, there are times when “good enough” isn’t. Achieving less than
the performance standard is failure. Sometimes saying “partial success” is like
saying “a little bit pregnant.”
There are a lot of different ways of looking at a project, and the triple
constraint approach is only one of those ways. Its special value comes when
you recognize that the triple constraints have a priority. In order, they are
driver, middle constraint, and weak constraint.
In a war, you can’t very well go back to your boss and say, “I lost, but in
my defense, I’m ahead of schedule and under budget.” Performance is the
driver. In some wars, there’s a pressure to get it done, which would make time
the middle constraint and cost the weak one. The best project management
approach is to use money and resources and overpower the enemy. Cost can
be the middle constraint, too.
If you’re a poor and small country, you simply might not be able to raise
a strong enough force no matter what you do. In that case, the best project
management approach is to play the long game, try to wear down the more
powerful adversary in hopes they will eventually get tired and go home.
In a rescue, time is usually the driver. The earlier someone can be recov-
ered, the greater the chance he or she will survive, and the clock is ticking for
some victims more rapidly than others. Performance is most often the middle
constraint. Although clearly it’s not a success if the victim doesn’t make it,
time pressure may justify taking a few extra risks when seconds are precious.
Cost is the weak constraint, because you can fund improved emergency re-
sponse if you’re willing to pay for it.
But sometimes cost can be the driver. The first rescue truck arrives on
the scene and what it carries is all you have to work with. Are there five pa-
tients and only three rescuers? Well, until another truck gets here, three res-
cuers are all you have. It doesn’t matter if there are ten more back at the
station, at least not until they can make it to the scene.

By the way, although the hierarchy of constraints usually stays the same
throughout the project, any major changes that impact your project may also
reorient your driver. Stay alert. Exhibit 2–4 shows the relationship between
the triple constraints and the hierarchy of constraints.
Ranking Constraints
How do you determine driver, middle, and weak constraints? Asking the proj-
ect sponsor or customer may or may not work. Often, the answer they care
about is, “All three.” But you can also frame it from the point of view of suc-
cess. “If I could finish early, and meet the cost and time constraints, or I could
finish on time and be under budget, or I could finish on time and on budget
but exceed the performance goals, which would you prefer?” Be careful,
though: what is true in one direction (success) isn’t automatically true in the
other (failure).
It may help to think of the hierarchy of constraints not as something that’s
chosen, but as something that flows naturally from the conception of the proj-
ect. It’s the reason for the project that establishes the hierarchy of constraints
for the project.
By the way, remember that although the hierarchy of constraints usually
stays the same throughout the project, any major changes that impact your
project may also reorient your driver. This is an important skill to master. In
Exercise 2–2, you’ll take a project and figure out its hierarchy of constraints.
xhibit 2–4
In a project, the triple constraints typically array themselves in a hierarchy, based not on how im-
portant they are, but how flexible they are: how much they can be stretched before we’re forced to
declare failure. The driver is least flexible. Failing the driver means failing the project. The middle
and weak constraints follow. You can use the extra flexibility (especially in the weak constraint).

Exercise 2–2
Instructions: Based on the following excerpt from JFK’s speech to Congress on going to the moon,
identify the triple constraints and rank them in the order of driver, middle, and weak constraint.
Finally, if we are to win the battle that is now going on around the world between free-
dom and tyranny, the dramatic achievements in space which occurred in recent weeks
should have made clear to us all, as did the Sputnik in 1957, the impact of this adven-
ture on the minds of men everywhere, who are attempting to make a determination of
which road they should take . . . . Now it is time to take longer strides—time for a great
new American enterprise—time for this nation to take a clearly leading role in space
achievement, which in many ways may hold the key to our future on earth.
I believe we possess all the resources and talents necessary. . . [but]. . . have never
specified long-range goals on an urgent time schedule, or managed our resources
and our time so as to insure their fulfillment.
Recognizing the head start obtained by the Soviets with their large rocket engines,
which gives them many months of lead-time, and recognizing the likelihood that they
will exploit this lead for some time to come in still more impressive successes, we nev-
ertheless are required to make new efforts on our own. For while we cannot guarantee
that we shall one day be first, we can guarantee that any failure to make this effort will
make us last . . . .
I therefore ask the Congress, above and beyond the increases I have earlier re-
quested for space activities, to provide the funds which are needed to meet the fol-
lowing national goals:
First, I believe that this nation should commit itself to achieving the goal, before this
decade is out, of landing a man on the moon and returning him safely to the Earth . . . .
Let it be clear—and this is a judgment which the Members of the Congress must fi-
nally make—let it be clear that I am asking the Congress and the country to accept a
firm commitment to a new course of action, a course which will last for many years and
carry very heavy costs: 531 million dollars in fiscal ‘62—an estimated 7 to 9 billion dollars
additional over the next five years . . . .
It is a most important decision that we make as a nation . . .
Triple Constraints
Time: ____________________________________________________________________
Cost:_____________________________________________________________________
Performance: ______________________________________________________________
Driver: ___________________________________________________________________
Middle: ___________________________________________________________________
Weak:____________________________________________________________________

ASSUMPTIONS
You may have heard the warning about assumptions: “assume” makes an “ass”
out of “u” and “me.” But that’s not always the best way to look at it. Some as-
sumptions are very useful. For example, you should assume that any weapon
you see is loaded—even if you’re pretty sure it isn’t. Treating a empty firearm
with care does no harm; treating a loaded firearm as empty can kill someone.
It’s not always necessary—or possible—to turn every assumption into a
fact or a falsehood. However, it is necessary to recognize assumptions for what
they are, and not confuse them with reality. You can make assumptions, the
project sponsor and customer make assumptions, and your team makes as-
sumptions. All of them need to be brought into the open. That’s not always
easy. We don’t always recognize the assumptions we are making. Try some of
the following techniques:
1. Document review. Go through any memos, directives, or requirements
and check each statement listed as fact. Do you know that it is true, or
could it be an assumption?
2. Brainstorm. Brainstorm everything you think you know about the project,
then look at each listed item to see if it’s really a fact or actually an as-
sumption.
3. Think about common assumptions. “If this project is successful, the prob-
lem or issue that led to it will be resolved.” “Everybody is in basic agree-
ment with this course of action.” “No major problems or surprises will
occur that will force us to modify resources or priorities.” All of these state-
ments might be true, but it’s probably wise to verify.
Some assumptions can be turned into either facts or falsehoods by a little

bit of research, and then they are no longer assumptions. Some assumptions
we make for the sake of safety (e.g., the gun that may or may not be loaded
gets treated as if it’s loaded). Other assumptions will remain uncertain until
the project reaches a certain point. Treat these assumptions as risks.
Exercise 2–3
PMO Project Constraints and Assumptions
In this exercise, we return to the PMO project first discussed in Exhibit 1–1. You have already com-
pleted two previous exercises (Exercises 1–1 and 1–2) that built on the initial project description.
Instructions: Use the material you wrote for the two previous exercises along with the following ad-
ditional guidance to develop a list of constraints and assumptions for the project. Then rank the
constraints using the triple constraints paradigm.
After your first meeting with the CEO, you go away and do some studying about PMOs, and talk
to several managers whose opinions and candor you value. You have further discussions with the
CEO as well, and now you have additional information.
• The CEO wants to cap the cost of the project at $50,000, and the cost of running the PMO at less
than $200,000 per year. However, the detailed scope of the project has not yet been established.
Exercise 2–3 continues on next page.


• Although there are some managers who dislike the PMO concept because they feel it will intrude
on their authority and the regular work of their departments, the primary source of skepticism is
whether the PMO will work as advertised and deliver the promised benefits.
• Your three largest competitors all have a PMO, but you have little access to information on how
those PMOs are set up and how well they work.
• The outside pressure to develop a PMO is coming from a stock analyst who studies your company,
and the lack of a PMO could affect the analyst’s rating and the stock price of your company.
• Your initial study of the PMO concept shows clearly that it has made a strong and positive differ-
ence in many organizations who have implemented it. However, some organizations have dis-
banded their PMOs because they did not work as advertised.
• Only a handful of people in your organization have formal project management training and only
two have their PMP® certification. Your most skilled project managers are in high demand for run-
ning actual projects.
Triple Constraints
Time: ____________________________________________________________________
Cost:_____________________________________________________________________
Performance: ______________________________________________________________
Driver: ___________________________________________________________________
Middle: ___________________________________________________________________
Weak:____________________________________________________________________
Assumptions
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
PROJECT CHARTER
In our summary of the project management knowledge areas and processes,
we described the project charter : the document that formally authorizes the ex-
istence of a project and gives the project manager working authority to pro-
ceed. Although a project charter may not actually be called “project charter,”
it’s vitally important that you get a written agreement that describes what you
have to do, when you have to do it, and how much you can spend in the
process.

The charter can be written as a memorandum or it may be structured as a

legal contract. Everything you need may be contained in a single document, or
you may find different elements in different places. One size does not fit all. A
project charter, by whatever name, is successful if it provides the project manager
with clear guidance and authority to accomplish the work, and is not successful
if the project manager is still flying blind and unsure of his or her authority.
While a project charter is always signed and approved at a level higher
than that of the project manager, it’s not uncommon for the project manager
to prepare a draft of the charter for the appropriate managers.
If something is left out of the project charter, it’s not necessarily fatal—
as long as the missing information shows up in another part of the process.
Here is a list of some of the things a project charter might include:
• Business need or purpose of the project
• Description of the product, service, or result that the project is supposed
to deliver, preferably expressed as measurable objectives
• High-level requirements of the project, along with boundaries—what the
project isn’t expected to accomplish
• List of constraints that apply to the project
• Major stakeholders and their individual needs and goals
• High-level risks and major milestones
• Assignment of a project manager, a statement of the project manager’s au-
thority and responsibility, and a list of people who must approve elements
of the project or its final outcome
• Other organizations that must support the project and what they are ex-
pected to provide
In some organizations, the project charter includes the actual project

plan, but we recommend that the planning process follow the issuance of the
charter.
In Exercise 2–4, you will list all the information that might go into the
project charter for your PMO.
Exercise 2–4
PMO Project Charter Outline
Instructions: In this exercise, you will describe what you know about each of the project charter el-
ements discussed previously. Note that some of them (the list of constraints and assumptions; the
list of stakeholders) were already done in previous exercises, and there’s no need to repeat the in-
formation here.
Business need or purpose of the project.
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

Description of the product, service, or result that the project is supposed to deliver, prefer-
ably expressed as measurable objectives.
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
High-level requirements of the project, along with boundaries—what the project isn’t ex-
pected to accomplish.
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
List of constraints that apply to the project.

Already done
Major stakeholders and their individual needs and goals.

Already done
High-level risks and major milestones.
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Assignment of a project manager, a statement of the project manager’s authority and respon-
sibility, and a list of people who must approve elements of the project or its final outcome.
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Other organizations that must support the project and what they are expected to provide.
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________

OBTAINING APPROVAL AND BUY-IN

Getting a project charter issued implies that the appropriate people have ap-
proved the project and have bought in to its methodology and goals. But that
isn’t something that happens automatically. When Watergate figure G. Gor-
don Liddy was asked to build a clandestine operation to support Richard
Nixon’s 1972 presidential campaign, he developed and presented a wide-rang-
ing plan with a budget of $1 million, and was told in no uncertain terms that
his proposal was excessive.
Even though he was developing a plan at their request, that didn’t mean his
management was obligated to approve it. Instead, they sent him back with in-
structions to revise the plan downward. Liddy did so, and developed a plan that
could be accomplished for no more than $500,000. That plan, too, was rejected
as excessive, and Liddy was forced to rescope the project once again, this time
within a $250,000 budget, and won management approval. He actually received
$83,000 in cash, and was told the other funds would be made available as needed.
Because the people involved wanted no direct connection to Liddy’s proj-
ect, there was no formal project charter authorizing the work. Instead, it pro-
ceeded on an informal basis. This resulted in scope creep: the addition of work
to the basic project without adjusting either the time or cost constraints. The
actual Watergate burglary was not in the original plan, but was added. By that
time, cost pressures had hampered the project so much that Liddy ended up
using a staff member from the Nixon campaign, a decision that triggered the
entire Watergate scandal. (Dobson 2013, 32–38)
A project charter helps protect the project manager against scope creep,
and helps protect the organization against a project manager making vital de-
cisions without oversight.
PROGRESSIVE ELABORATION AND THE

PROJECT OBJECTIVE
Just because the project charter is complete and has been approved, it’s not
wise to assume that you’ve got a stable project objective that will not change
going forward. In the case of our PMO project, we have a fairly good idea
what it’s supposed to accomplish, but we don’t have a lot of detail on how it
will be structured, set up, and operate.
In Chapter 1, we defined projects and project management, and in that
section described progressive elaboration as an element that lies at the heart of
many project management concepts, tools, and techniques. In progressive
elaboration, you break a large project into smaller pieces until you are able
to put together a meaningful plan.
Progressive elaboration applies to the project objective just as much as it
does to elements of the plan. As you move forward in the planning process,
you will frequently discover important questions and issues that are best ad-
dressed in the project objective. In other words, if you feel that your initiating
process is “two steps forward, one step back,” that’s not necessarily a sign of
problems, but rather a sign that you’re doing it right.

A project is a means to an end, rather than an end in itself. Un-

less you understand the underlying problem or issue, it’s hard
to establish the right objective or direction for the project.
The process of establishing a new project is called project
initiation. Some large projects are organized into phases, and
each project phase should be initiated as if it were a stand-
alone project.
In project initiation, you should identify and classify the most important
stakeholders, who are the people with some interest in, and potentially with
power over, some aspect of the project or the project’s output. Record this in-
formation in a stakeholder register. Some stakeholder categories exist on almost
every project, whereas others are less common or more specialized.
Constraints limit your choices, and every project has them. Though dif-
ferent people count constraints in different ways, the triple constraints of time,
cost, and performance are universal. Depending on the structure and purpose
of the project, these constraints normally sort into a hierarchy of driver, middle,
and weak constraint, depending not on their relative importance but on their
flexibility. Projects may have many other constraints. Some constraints are
flexible or negotiable, whereas others are fixed.
Assumptions are concepts treated as true without proof. Not all assump-
tions are bad; some assumptions promote safety and lower risk. Some assump-
tions can be turned into facts or falsehoods by examining them; only time will
reveal if other assumptions were true or false. Assumptions that cannot be re-
solved should be treated as risks.
A project charter is a written document that formally establishes the proj-
ect, assigns the project manager and provides authority, and contains enough
information to allow the project to proceed. It is unwise to begin a project
without getting an approved charter. The process of getting a project charter
approved also helps obtain the necessary management buy-in to the project.
The project charter may not be the final word on the project and its di-
rection. The concepts of progressive elaboration and iteration may cause you
to revisit the charter and potentially modify it in light of new information.

Review Questions
1. Which of these sets describes the hierarchy of constraints? 1. (c)

(a) Time constraint, cost constraint, performance criteria
(b) Constraints, assumptions, and stakeholders
(c) Driver, middle constraint, weak constraint
(d) Project charter, stakeholder register, requirements document
2. A project constraint: 2. (b)

(a) is something treated as true in the absence of proof.
(b) limits your choices.
(c) is something you should always try to get around.
(d) tells you the priority of your project.
3. A tangential stakeholder is someone who: 3. (b)

(a) does not think your project is important or worth doing.
(b) has an unrelated secondary interest in your project.
(c) personally benefits from your project.
(d) has a combination of positive and negative issues on your project.
4. What is a purpose of a project charter? 4. (c)

(a) It organizes the final project plan.
(b) It establishes project management policy for the organization.
(c) It formally authorizes the project.
(d) It serves as a contract with outside vendors supporting the
project work.
5. What is included in the process of project initiation? 5. (b)

(a) Developing a timeline of project activities
(b) Identifying constraints and assumptions
(c) Managing stakeholder opinions to reduce controversy and resistance
(d) Developing a risk response plan

Planning the Activities
3
Learning Objectives
• Explain the importance of progressive elab-
oration in the planning process.
• Create a project statement of work (SOW).
• Prepare a requirements document and ex-
plain when it is needed.
• Create and interpret a work breakdown
structure (WBS) in both org chart and outline
format.
• Develop an activity list and network diagram;
define the critical path, slack, and float; and
perform a forward and backward pass.
• Explain the role of the Gantt chart, and de-
scribe the process for turning a network dia-
gram into a Gantt chart.

Reading 1 hour
Exercises 3 hours 20 minutes

ITERATIVE PLANNING
There’s a bit of a chicken-and-egg problem in project planning: you can’t, for
example, make a good project plan without knowing the risks, and in order to
find all the risks, you need a good project plan. You need the plan to guide
your estimating, and you need your estimates to have a plan.
Here’s where progressive elaboration and the iterative nature of projects
comes back into play. Remember, progressive elaboration means that you
break the large project into smaller pieces, define each piece fully, and use
that expanded, more detailed information to support your planning and proj-
ect execution. The practical strategy for project planning requires you to make
a tentative initial version, use that version to spur your thinking and analysis
of these other issues, and then incorporate what you’ve learned into the plan.
For the time being, we’ll forget deadlines and budget. You need to know
whether you have a problem and how severe it is before you start figuring out
how to solve it.
In this chapter, we’ll create a project statement of work (SOW), a requirements
document, a work breakdown structure (WBS), and a network diagram. Though all
three of these items will almost certainly be modified, we still need to have
some general overview of the project to get started.
STATEMENT OF WORK
The project statement of work (SOW) is a narrative description of the
project. Usually fairly short (a couple of pages), it describes the output of the
project (a product, a service, or some other type of result) and what business
need it is expected to accomplish. It describes the project scope in terms of
its high-level characteristics or requirements. Exhibit 3–1 illustrates an SOW
for our case study PMO project.
Exercise 3–1
Research and the SOW
Instructions: You’ve been asked to set up your company’s PMO, and at least some of those who
take this course may not have any experience with PMOs. In the real world, that’s not necessarily
unusual. You are expected to learn on the job.
In this exercise, you are going to do some Internet research about PMOs to gain familiarity.
Then decide what changes (if any) you would make to the SOW in Exhibit 3–1.

PLANNING THE ACTIVITIES 43
xhibit 3–1
Statement of Work
Project Management Office

The goal of this project is to establish a functioning Project Management Office (PMO) for XYZ
Company. It should accomplish two objectives: first, to enhance our effectiveness in managing other
projects, and second, to reassure stockholders and stock analysts that we are adopting industry
best practices in project management. For that reason, the deadline for this project is the annual
stockholders’ meeting, scheduled to be held on [DATE], approximately nine months from now.
Because a PMO is an evolving structure, the endpoint of this project is to create a PMO capable
of growth and increasing maturity. A beginning PMO normally focuses on project manager training,
coaching, and mentoring. As it evolves, it may become involved in overall project governance and
provide direction for projects and programs. At the highest level, the PMO is the organization that
matches projects to strategic objectives, defines portfolio scope, and oversees investments in spe-
cific projects and programs.
Within the nine-month project timeframe, it is only possible to establish an initial PMO. Its growth
and maturity may result in future projects (or a continuous improvement process), but are not part
of the current project scope.
Measurable objectives for this project include:
• Research and write a PMO policy and departmental approach, and obtain necessary approvals.
• Determine what positions are required by the PMO, and recruit appropriate candidates, internal
or external, to fill the positions.
• Establish a training program in the fundamentals of project management, to be administered by
the PMO, and train all managers and staff with direct involvement in projects.
• Conduct presentations and briefings for all appropriate managers and staff on the role, functions,
and benefits of the PMO, and detail the services it offers.
• Get the PMO involved in one or more current projects to learn how it works and make any required
adjustments in methodology and approach.
• Prepare a presentation that the CEO or other appropriate executive can deliver at the stockhold-
ers’ meeting, and a report that can be sent to stock analysts and others.
• Conduct an “after action review” following the stockholders’ meeting and prepare a report and
presentation to recommend future actions.
Our preliminary budget estimate is $50,000 for direct project expenses and $200,000 per year
in staff costs for the new PMO.
REQUIREMENTS DOCUMENT
Not every project needs a formal requirements document; in many cases the
high-level requirements contained in the SOW are sufficient to allow the proj-
ect to move forward. Technology and construction projects, however, often
need a lot more detail in requirements, and if that is your situation, you should
consider preparing a separate requirements document. These documents can
be quite lengthy and detailed. In extreme cases, the work involved in devel-
oping requirements can be classified as a project in its own right.
A well-written requirement accurately describes an element of function-
ality or quality, and is both unambiguous and verifiable (you can tell if it has

been done or not). A requirement must be feasible and necessary. Require-

ments should be prioritized, so if there are contradictions, or if time and cost
considerations force project compromises, requirements of lesser importance
can be eliminated or postponed.
You must often cast a wide net to find all the project requirements. Dif-
ferent stakeholders want different things. Sometimes these requirements are
compatible and achievable, but sometimes you will find contradictions that
must be resolved before the project begins.
Different requirements will be addressed in different parts of the project.
A requirements traceability matrix links requirements to deliverables and activi-
ties to ensure that those requirements have been met. This is an important
tool in project monitoring and control.
Exhibit 3–2 provides guidelines on developing a requirements document.
Appendix D: Additional Resources contains links to some requirements tem-
plates; a quick Internet search will reveal many more.
WORK BREAKDOWN STRUCTURE

The work breakdown structure (WBS, sometimes pronounced “wubbus”) is
at the core of effective project management. It’s like the foundation of a house:
you don’t see much of it after the house is finished, but the quality of the
house is no better than the quality of the foundation on which it is built.
As the name implies, a work breakdown structure breaks the work of the
project into more manageable components, and structures them in a way that
supports the organization and approach used by the project. In PMBOK® Guide
language, it’s “a hierarchical decomposition of the total scope of work to be
carried out by the project team to accomplish the project objectives and create
the required deliverables.”
xhibit 3–2
Guidelines for Writing Requirements
1. Number each requirement to allow cross-referencing.

2. Write each requirement so it specifies what is required without limiting how it should be fulfilled.
3. Break large requirements into more detailed levels until they are unambiguous, measurable,
and clear.
4. Separate “functional requirements,” which define functions of a system or product, from “non-
functional requirements,” which are the qualities of a system such as security, usability, main-
tainability, and other “-ilities.”
5. Consider adding “nonrequirements” to make clear what characteristics are not included in the
project.

How many levels of decomposition should your WBS contain? Two or

three levels are most common, but there is no hard and fast rule. The goal is
that the lowest layer of your decomposition should consist of packages that
can be assigned to a single individual or a small team and can be completed
in a reasonable amount of time, typically between eight and 80 hours of effort.
That’s a guideline, not a rule—your mileage may vary. Your own decisions
may be affected by the difficulty or complexity of different project elements,
the work maturity and experience of those whom you assign to manage those
elements, and many other factors. You may find that you want to decompose
some project elements more than others: there’s no requirement that each part
of the project be decomposed to the same number of levels.
It’s almost always the case that more than one approach to a project is le-
gitimate: if you give the same project to two different trained project managers,
you’ll probably get two very different WBSs. Which one’s right? The one that
best reflects how you actually plan to organize and manage your project.
Too often, people rush through the WBS process so they can get on with
scheduling and other parts of planning, but that’s a mistake. If you have an
outstanding, complete, and comprehensive WBS, you’ll find not only that the
final project plan is better, but also easier to put together.
The WBS can be organized either in an “org chart” format or as an out-
line. We recommend that you build a WBS using the org chart approach, on
the grounds that it’s easier. If you enter your WBS into Microsoft Project® or
similar project management software, it will normally be displayed in outline
format. Exhibit 3–3 shows a sample WBS in both formats.
Creating a Work Breakdown Structure

To build an initial WBS for your project, you don’t need fancy software or
other tools. All you need is a big stack of sticky notes. Take one note, write
the name of the project on it, and stick it to the top of a whiteboard or piece
of flip chart paper. That’s Project Level 0, as shown in Exhibit 3–3.
The next step depends on your project circumstances. There are two basic
ways to break down the project: top down, and bottom up. In some cases, the
overall structure of your project is clear or predetermined. If, for example, your
project is the type of project you do all the time, you probably have an existing
organizational structure designed to handle it. You’re best off beginning with
that structure and breaking the project down in accordance with that structure.
For example, the course you’re reading right now is the output of a pro-
ject. Although this project is temporary (there’s a deadline) and unique (this
is the only self-paced course for introductory project management), the gen-
eral category (create a self-paced course) is the type of project the publisher
does all the time. They have editors, designers, and all the other necessary
functions, all organized for this purpose. Each work package or deliverable in
the WBS for this course project fits into an existing organizational structure.
The “top down” approach will work best.
Other times, the project is outside your normal work process, and you
don’t have a system in place to handle it. You must not only break down the
project, but also set up the organizational structure to handle it. Unless you
work for an event planning company, setting up the annual employee picnic is

xhibit 3–3
Work Breakdown Structure in Org Chart and Outline Formats
This exhibit shows the same project, “Pharmaceutical Project,” in both the org chart WBS format and
the outline WBS format. Notice that the first level of the WBS is “Level 0,” not “Level 1.” Also notice the
format of WBS numbers in the outline version. These numbers are automatically created if you enter a
WBS into Microsoft Project®.
Pharmaceutical Level 0 (Project)
Project
Level 1 (Phase,
Research Testing Approval Release Functional Area, Majo
Deliverable)
Identification of Likely Computer Models and

FDA Application Marketing Plan
Drugs Cellular Testing
Level 2 (Work
Packages)
Responses and
Initial Research Animal Testing Manufacturing
Presentations
Identification of Outreach to Medical

Clinical Trials Final Approval
Candidate Drugs Community
Phase 1 Trials
Level 3
(Components)
Phase 2 Trials
Phase 3 Trials
Outline Version
1.0 Pharmaceutical Project
1.1 Research
1.1.1 Identification of Likely Drugs
1.1.2 Initial Research
1.1.3 Identification of Candidate Drugs
1.2 Testing
1.2.1 Computer Models and Cellular Testing
1.2.2 Animal Testing
1.2.3 Clinical Trials
1.2.3.1 Phase 1 Trials
1.3 Approval
1.3.1 FDA Application
1.3.2 Responses and Presentations
1.3.3 Final Approval
1.4 Release
1.4.1 Marketing Plan
1.4.2 Manufacturing
1.4.3 Outreach to Medical Community

xhibit 3–4
Department-Based vs. Phase-Based WBS
The two WBSs shown here reflect two different ways to organize the same project. In the first, the
work packages are grouped by the department responsible for them. In the second, the work pack-
ages are grouped by phase.
Develop a Course
Design

Site Materials
Ship Materials to
Seminar Location

Market Course
Feedback Speakers
Finalize Course
Develop a Course
Development Testing Finalizing Rollout
Incorporate Beta Test

Determine Topic Assign Presenter Approve New Course
Feedback
Arrange Beta Test Train Additional Develop Promotional

Research Topic
Site Speakers Materials
Ship Materials to
Write Workbook Finalize Course Market Course
Seminar Location
Design Graphics Conduct Beta Test
Produce Materials

outside the normal work of the company. There isn’t a “Picnic Department”
designed to handle it. Instead, you will typically set up a team of people who
have regular jobs that don’t involve picnics, organize them into committees
(food, games, site, etc.), and assign each committee appropriate activities. Before
you can set up the committees, however, it’s a good idea to figure out what ac-
tually must be done. In this case, you’re better off with a “bottom up” approach.
In the “top down” approach, WBS Level 1 already exists. Make sticky
notes for each participating department or work group, and stick them to the
whiteboard or flip chart underneath the name of the project. Then look at
each department or group to figure out what they are supposed to do. Make
a separate sticky note for each thing that group is supposed to do, and add
those to the chart underneath the department name.
In the “bottom up” approach, start by identifying all the work packages
that have to be done. Write each work package on a separate sticky note, and
when you’ve got enough notes done, figure out the most appropriate way to
group them so that they can be managed and executed effectively.
Think About It . . . Top Down or Bottom Up
Think about a project you’ve been involved with. Would you have used a top down or a bottom up
approach in developing the WBS for that project? Why?
Phases, Deliverables, or Departments?

Compare the two work breakdown structures in Exhibit 3–4.
Exercise 3–2
Different WBS Approaches
Of the two approaches to the same project shown in Exhibit 3–4, what do you see as the advan-
tages and disadvantages of each?

The One Hundred Percent Rule

To be effective, a work breakdown structure must include 100% of the scope
of the project. If something isn’t in the WBS, it won’t end up in the final pro-
ject. That’s good if it wasn’t supposed to be in the project in the first place,
but it can be catastrophic if in fact it should have been included.
With that in mind, you should apply the One Hundred Percent Rule to
determine whether your WBS is complete and correct. This rule states that
the total of the work at the lowest levels should roll up to the higher levels so
that nothing is left out and no extra work is included. In project management
speak, the lowest level of a WBS is known as a work package (no further break-
down), and all higher levels are known as control accounts.
Project Management Work in the WBS

Often, you’ll see a heading in the WBS for “Project Management.” Project
management takes up time and consumes resources, so it’s very much part of
the work of a project. However, many project management activities aren’t
“work packages,” but rather ongoing activities. “Staff meetings,” “reports,” and
“oversight” don’t have a clearly defined beginning, end, or measurable output.
In addition, some work performed by the project manager may be better
placed in another category. In Exhibit 3–4, the activity “Approve New Course”
is listed under Marketing in the first version and under Rollout in the second
version. Either way, the project manager is either the person who approves
the course or the person who obtains approval from higher levels of the or-
ganization. The PMBOK® Guide does recommend adding a “Project Manage-
ment” category to your WBS. If you choose not to do so, be careful to account
for these project management functions elsewhere in your project plan.
Exercise 3–3
Build a Work Breakdown Structure
Instructions: In this exercise, you will prepare a work breakdown structure covering at least Levels
0–2 for our PMO case study project. You will need sticky notes and an appropriate surface (white-
board, flip chart) for this exercise. Use the information previously presented in Exhibits 1–1 and 3–
1, and Exercises 1–1, 1–2, 2–1, 2–3, and 2–4.
NETWORK DIAGRAMMING
The most common type of schedule in project management is the Gantt chart,
which is essentially a bar chart of activities on a calendar grid. Gantt charts
are easy to read and understand, but they aren’t actually the easiest type of
schedule to build. We recommend that you prepare a network diagram as the
first step in scheduling the process. A network diagram is essentially a flow-
chart of the project activities. Later in this chapter, we’ll show you how to con-
vert a network diagram into a Gantt chart.

A network diagram used to be called a PERT chart, showing its origin in

the PERT and CPM methodologies we discussed in Chapter 1, but today’s
network diagram is independent of both PERT and CPM. It even looks dif-
ferent. PERT and CPM diagrams originally used a technique called “activity
on arrow,” which was much more confusing to beginning project managers
but had the advantage of taking up less computer memory. Today, we most
commonly use the precedence diagramming method (PDM), also known as “ac-
tivity on node.” There is no reason for a modern project manager to ever use
“activity on arrow,” but you may find references to it in some project man-
agement texts. Should you need to know more about it, check Wikipedia
under “Arrow Diagramming Method.”
To create a network diagram, you begin with the work packages from
your WBS and create an activity list for each.
Constructing an Activity List

In a WBS, the work packages refer to the things you have to get done, and the
activities are the things you have to do. Let’s refer back to our pharmaceutical
project in Exhibit 3–3. Under the control account “Approval,” there’s a work
package named “FDA Application.” That’s something you have to get done—
it’s a project deliverable.
According to the FDA, a new drug application summary ordinarily runs
between 50 and 200 pages in length. It’s supposed to be prepared to the same
standard and level of detail as an article intended for publication in a scientific
and medical journal. It includes sections on:
• Proposed labeling text
• Pharmacologic class, scientific rationale, intended use, and potential clinical
benefits
• Foreign marketing history
• Chemistry, manufacturing, and controls
• Nonclinical pharmacology and toxicology summary
• Human pharmakinetic and bioavailability summary
• Microbiology summary
• Clinical data summary and results of statistical analysis
• Discussion of benefit/risk relationship and proposed postmarketing studies
And that’s just the summary. When you add all the supporting documen-
tation, clinical test reports, and other raw data, an application can be 100,000
pages long!
Clearly, preparing the FDA application can easily be considered a project
in its own right, as well as a phase inside the overall new drug approval process.
Though making it a work package in terms of the overall project makes sense,
it needs further levels of decomposition before you reach the point where it’s
manageable.
Much of the supporting documentation will have been created during
the research and clinical trials phases, so it mostly needs to be organized and
compiled so that reviewers can easily locate the relevant sections. As far as
the summary itself goes, it’s likely going to go through multiple drafts and

iterations, and may require numerous signoffs. It may also require multiple
authors who have specific subject-matter expertise, with an overall editor
whose job it is to manage the whole process. It may take months to prepare.
With that in mind, let’s look at some of the activities required to accom-
plish this work.
1. Assign editorial team
2. Obtain raw data from clinical trials and pharmacological studies
3. Organize data into categories
4. Prepare an index and table of contents for raw data
5. Develop summary sections for each category of data
6. Get summary sections reviewed for completeness and technical accuracy
7. Draft overall summary
8. Get reviews and input on summary draft
9. Rewrite summary to incorporate all comments
10. Conduct a secondary review
11. Write final summary version
12. Obtain final signoff
13. Print required number of copies of entire submission both for FDA and
for in-house files
14. Submit FDA application
Although the work package “FDA Application” in our WBS defines the
final deliverable, when it comes to scheduling the project, we are more inter-
ested in the list of activities. The amount of time each activity will take relates
to how long the overall project will take, and the cost of performing each ac-
tivity (person-hours, money) will determine the required budget to accom-
plish the work.
To calculate the total budget, figure out how much each activity will cost,
and add the numbers together. But when you try to calculate the total time
required, you run into a new complexity: parallel activities. Whereas some ac-
tivities can’t be started until one or more earlier activities are complete (you
can’t write the final summary version until you receive the comments on the
previous draft), others can take place in the same time period (print copies of
the raw research data while waiting for comments).
Exercise 3–4
Activity List
Instructions: Take your WBS from Exercise 3–3 and create an activity list for the project. To keep
the exercise manageable, try to limit the number of activities to between ten and fifteen.
1.
2.
3.


4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Laying Out the Project

To figure out how much time the project will take, we have to lay out the ac-
tivities in the order we expect to complete them. To do this, write each activity
on a separate sticky note. Create a sticky note labeled “Start” and one named
“Finish.” Stick the “Start” note on your whiteboard or flip chart, and begin
adding the activities until you reach “Finish.” Draw connecting lines to show
the dependency relationships among the activities. Exhibit 3–5 shows a completed
network diagram for the work package “FDA Application.”
xhibit 3–5
Network Diagram
1. 5. Write 6. Review
Assign Summary Summary
Team Sections Sections
7. Draft 8. 9. 10.
11. Write 12. Final
Start Overall Review Rewrite Review
Final Signoff
Summary 1st Draft Summary 2nd Draft
14.
FInish
Submit
2. Obtain 3. 4.
Raw Organize Prepare
Data Data Index 13. Print
Data

Exercise 3–5
Network Diagram
Instructions: Take the items from the activity list you prepared in Exercise 3–4. Write the activities
on sticky notes, with one activity per note. Add two additional notes for “Start” and “Finish.” Use
these notes to prepare a network diagram for the PMO project.
Determining the Critical Path

When two or more activities take place during the same time period (parallel
activities), only the longest path of activities (known as the critical path) deter-
mines how long the project will take.
In Exhibit 3–6, we’ve assigned time estimates to each activity. Notice that
the path Start2347 takes 0 + 4 + 12 + 3 + 2, or 21, weeks. The par-
allel path Start1567 takes 0 + 1 + 4 + 8 + 2, or 15, weeks. We say
that Start2347 is part of the critical path, which means we expect that
part of the project to take 21 weeks to accomplish. If any of those critical path
activities run longer than expected, the whole project will take longer to ac-
complish.
What if Activities 1, 5, or 6 take longer than expected? As long as their
combined lateness doesn’t exceed six weeks, our project is still on schedule!
We say that the path segment 156 has six weeks of slack or float. (“Slack”
and “float” are synonyms. One term comes from CPM and the other from
PERT, but they both describe the same thing.)
Knowing the critical path tells you two things: first, how long the project
is expected to take, and second, which activities have to stay on schedule in
order to achieve that time estimate. Because you have extra time to complete
activities with slack or float, you can worry less about them. In some cases,
xhibit 3–6
Critical Path
Critical activities are shown in solid black; noncritical activities (those with slack or float) are shown
in gray.
Slack/Float = 6 weeks
1 weeks 4 weeks 8 weeks 7. Draft 8. 9. 10.

11. Write 12. Final
Final Signoff
14.
2 weeks 6 weeks 2 weeks 6 weeks 2 weeks 6 weeks FInish
Submit
0 weeks 2. Obtain 3. 4.
13. Print 1 weeks
Data Data Index 0 weeks
Data
4 weeks 12 weeks 3 weeks Total Time = 60 weeks
3 weeks
Critical Path = 44 weeks

you can even move resources from an activity with lots of slack to an activity
on the critical path as a way to make sure you stay on schedule.
Remember that cost isn’t affected by the critical path. If you spend extra
money on a noncritical activity, it has the same effect as if you spend extra
money on a critical one.
Think About It . . . Will You Make the Deadline?
Although we haven’t yet estimated the duration of the various activities on the PMO project, what
is your current feeling about the time constraint based on your current network diagram? Is it com-
fortable, tight, or impossible? What makes you think so?
Additional Scheduling Relationships

All the relationships in our existing network diagram are of the type known
as “finish to start” (FS), which means that the successor activity can’t start
until the predecessor activity is finished. That’s by far the most common type
of relationship, but it isn’t the only one.
Finish to finish (FF) relationships describe situations in which one activity
can’t finish until its predecessor activity has finished. In cooking Thanksgiving
dinner, you don’t want to start the potatoes as soon as you put the turkey in
the oven, but rather time the potatoes so that they finish at the same time.
Start to start relationships (SS) say that an activity can’t start until its pred-
ecessor has started. Let’s say you want to make a hundred widgets and put
them in boxes. You don’t have to have all the widgets done before you put the
first one in a box, but you do need some of them.
Lag is additional time added to a relationship. In our widget example, you
could start boxing the widgets two days after you start making them. That’s a
start-to-start relationship with a two-day lag.
Lead is when you overlap two activities. You could start making the pota-
toes an hour before you finish cooking the turkey. Instead of a finish-to-finish
relationship, this is now a finish-to-start relationship with a one-hour lead.
Imposed dates are conditions when an outside date overrules a relationship.
If you’re putting a swimming pool in the back yard and order a truckload of
concrete, it doesn’t matter if you finish digging the hole early—the truck won’t
come until it’s scheduled. If you finish the hole a day late, the consequences
are much greater than a single day; you have to wait until the truck can come
back and you may have to pay for the unused concrete.

Forward and Backward Pass

For a lot of projects, it’s easy enough to find the critical path with a little in-
spection. In Exhibit 3–6, there are only two short segments where there are
multiple paths, and all you have to do is to compare the length of the top and
bottom segments.
For large projects, you’ll most likely use scheduling software, such as Mi-
crosoft Project®. It will automatically determine the critical path once you’ve
entered the duration and predecessor(s) of each activity. However, sometimes
you’ll have a project that falls somewhere in between, so it’s useful to know how
to calculate the critical path by hand. For that, you need to know how to perform
a forward and backward pass. Exhibit 3–7 shows a sample project without any task
names so you can just watch the numbers and learn how this process works.
Forward Pass
If an activity has slack or float, there is flexibility in the start and finish dates.
The early start is the earliest the activity can start considering its predecessors,
and the early finish is simply the early start plus the duration. The late finish is
the latest date an activity can finish without affecting the critical path, and
the late start is the late finish minus the duration.
The forward pass calculates early start and early finish; the backward pass
calculates late start and late finish. An activity is critical if the early/late start
and early/late finish are the same. If there’s a difference, the amount of the
difference is how much slack or float exists for that activity.
Exhibit 3–7 shows a forward pass calculation. The top center number in
each box is the duration. The top left number is the early start; the top right
number is the early finish.
xhibit 3–7
Forward Pass
Source: Adapted from Managing Multiple Projects by Dobson and Dobson ©2011. Used by permission of the publisher, AMACOM Books, a division of
American Management Association, New York, New York. All rights reserved. www.amacombooks.org

Start with the first activity, “Activity A,” which always has an early start
of zero. Its duration is zero; it finishes at zero. (An activity with a duration of
zero is called a milestone.) Activities B and C are both dependent on A; they
can’t start until A is finished. Because A is a milestone, B and C both start at
zero as well. Because B has a duration of 15 days, its early finish is 15; C’s
early finish is 11.
Activity D is dependent on both B and C. Its early start is the latest of the
early finishes of its predecessors. It therefore starts at 15, and 15 + 21 = 36, its
early finish. E, on the other hand, only requires that C be finished, so its early
start is 11, add 9, and its early finish is 20.
Activity F only needs D. It starts at 36, adds 8, and ends at 44. G needs
both D and E, so it begins at 36 (the later of the two predecessors) and ends
at 48 (36 + 12). The last activity, H, needs both F and G. It takes the G finish
of 48, adds 2, and now we know the duration of the project: 50 days. Exhibit
3–8 summarizes all these numbers.
Backward Pass
For the backward pass, we start with the end of the project and work backward
to the start, figuring out the late finish and late start of each activity. Exhibit
3–9 shows how it works. The numbers are summarized in Exhibit 3–10.
xhibit 3–8
Forward Pass Summary
Takes Early Start

Activity Early Start (plus) Duration = Early Finish
from Early Finish of:
A N/A 0 0 0
B A 0 15 15
C A 0 11 11
D Larger of C or D 15 21 36
E C 11 9 20
F D 36 8 44
G Larger of D or E 36 12 48
H Larger of F or G 48 2 50

xhibit 3–9
Backward Pass
xhibit 3–10
Backward Pass Summary
Takes Late Finish

Activity Late Finish (minus) Duration Late Start
from Late Start of
H Early Finish of H 50 2 48
G H 48 12 36
F H 48 8 40
E G 36 9 27
D Lesser of F or G 36 21 15
C Lesser of D or E 15 11 4
B D 15 15 0
A Lesser of B or C 0 0 0

For Activity H, the late finish is 50 days, and so the late start is 50 – 2, or
48. That number becomes the late finish for both F and G. For F, take the late
finish of 48, subtract 8, and the late start is 40. For G, 48 – 12 = 36.
Going backward, you pretend as if the arrows are reversed. If you have
more than one activity feeding a predecessor, this time you pass the lowest
number. Activity D’s late finish is governed by G’s 36, rather than F’s 40, and
36 – 21 = 15. E only cares about G, so its late finish is 36 and its early finish
is 27. However, it’s the late start of D that matters to both B and C. Both ac-
tivities have a late finish of 15; B’s late start is zero and C’s late start is 4. The
milestone, Activity A, ends up with a late finish and a late start of zero.
Critical Path and Float

Exhibit 3–11 puts all the numbers in their proper places. Now, we’ll determine
the critical path and float. To start, let’s compare the late and early figures for
each activity. The difference is zero for Activities A, B, D, G, and H. Those
activities make up the critical path.
Activities C, E, and F have float. For C, it’s four days (4 – 0 = 4). For E,
27 – 11 = 16 days of float. F has four days of float (40 – 36) as well. The num-
bers are summarized in Exhibit 3–12.
By the way, there’s a difference between total float, which is what we’ve
just calculated, and free float. Let’s imagine that Activity C uses its float, and
ends on day 15. Activity D, on the critical path, is unaffected. Activity E, with
16 days of float available, is also in good shape, but notice that because C is
late, E has lost four of those 16 days even before it starts. C’s float is not free
float, because it eats up some of E’s float. Activity F, on the other hand, has four
xhibit 3–11
Critical Path and Float

xhibit 3–12
Critical Path and Float Summary
Note that you will get the same answers if you use “Late Finish” and “Early Finish” instead.
(minus)
Activity Late Start Float Critical?
Early Start
A 0 0 0 Critical
B 0 0 0 Critical
C 4 0 4 Noncritical
D 15 15 0 Critical
E 27 11 16 Noncritical
F 40 36 4 Noncritical
G 36 36 0 Critical
H 48 48 0 Critical
days of float, but if it uses all four days, Activity H still starts when scheduled.
Because none of Activity F’s float comes from H, it is considered free float.
Notice that in the case of Activity C, it can start as early as day 0 but can
start as late as day 4. It has four days of total float; extra time before lateness
jeopardizes the project deadline. However, if Activity C uses any of its float, the
float available for Activity E is reduced because E will no longer start on Day
11. The float is shared, not free. The float in E and F, however, is free float, be-
cause no other activity is affected if those activities use their available float. Ex-
ercise 3–6 gives you an opportunity to practice the forward and backward pass.
Exercise 3–6
Identify Critical Path and Float
Instructions: Perform a forward and backward pass on the following figure. Determine the critical
path and identify available float.

GANTT CHART
A Gantt chart is a timeline of project activities drawn as a bar chart over a
calendar grid. Exhibit 3–13 shows a simple Gantt chart.
As we mentioned earlier, a Gantt chart is very easy to produce if you
have already done a network diagram. Create a table with a list of the activi-
ties, the duration of each, and the predecessor or predecessors of each. Exhibit
3–14 shows you such a table, as developed from the network diagram in Ex-
hibit 3–11.
To build a Gantt chart using project management software, you simply
enter this information in the appropriate columns and you’re done. To build
a Gantt chart by hand, create a calendar grid and draw each activity as a
straight line or bar from its start (determined by its predecessors) to its end
(determined by its duration). If the duration of an activity is zero, it’s a mile-
stone. The traditional symbol for a milestone in project management is a di-
amond ().
The sample Gantt chart in Exhibit 3–13 shows arrows connecting the
end of each line to the activity that’s dependent on it. This is optional. Exhibit
3–15 shows a Gantt chart built from the table in Exhibit 3–14.

xhibit 3–13
Gantt Chart
Credit: Gantt chart created using MindView Business Edition, authored by V. Heilman in 2011. Used under the Creative Commons Attribution-Share Alike
3.0 Unported license. Retrieved from http://commons.wikimedia.org/wiki/File:Gantt_chart_example.png, 5 August 2013.
xhibit 3–14 Activity Duration Predecessor(s)

Gantt Chart Data A 0 N/A
B 15d A
C 11d A
D 21d B, C
E 9d C
F 8d D
G 12d E, G
H 2d F, G
xhibit 3–15
Completed Gantt Chart
GANTT CHART
Task Dur. Pred. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Task A 0d —
Task B 15d A
Task C 11d A
Task D 21d B,C
Task E 9d C
Task F 8d D
Task G 12d D,E
Task H 2d F,G

Exercise 3–7
Draw a Gantt Chart
Instructions: Take the network diagram from Exercise 3–6 and turn it into a Gantt chart.
Activity Duration Predecessor(s)
Task 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Project planning is an iterative process. You need an initial

draft of a project plan in order to develop a final one. The
process begins by developing a project statement of work
(SOW), a narrative description of the project. In technology
and construction projects, you often need to prepare a re-
quirements document and requirements traceability matrix,
but this is not required in all cases.
The work breakdown structure (WBS) is at the core of effective project
management. Whether done in an org chart or outline format, it decomposes
the project into manageable components and organizes the work of the project
to make it easier to manage. Both top-down and bottom-up approaches are
used in developing a project WBS. The WBS can be organized by department
or skill area, phase, or many other ways; there is seldom only one right WBS
for a given project. Follow the 100% rule and make sure that each level of de-
composition includes 100% of the scope needed for each higher level. If
something isn’t in the WBS, it won’t be in the project.
Although Gantt charts are more frequently used for project scheduling,
a network diagram is easier to create and can be turned into a Gantt chart
when finalized. To build a network diagram, you must create an activity list
from your WBS, then arrange the activities in the order you plan to perform
them.
Activities can be dependent on other activities or parallel to them, de-
pending on the nature of the work and your choices. Most activity relation-
ships are “finish to start” (the successor activity can’t start until the predecessor
activity is finished), but “start to start” and “finish to finish” relationships are
also possible. Relationships can be adjusted by adding lag time or subtracting
lead time. Some project activities have “imposed dates” that override normal
activity relationships.
The critical path is the longest path from the project start to the project
finish. If any activity on the critical path is delayed, the deadline is jeopardized.
Other parallel activities may have slack or float, or extra time to complete
them before they, too, become critical.
In simple projects, it’s usually easy to spot the critical path. In very com-
plex projects, use project management software to find the critical path and
identify slack or float. You can determine the critical path, slack, and float
manually by using the forward and backward pass technique.

Review Questions
1. To prepare a WBS, you should: 1. (d)

(a) use a top-down approach.
(b) make sure each category has the same number of levels.
(c) organize the project scope into an outline structure.
(d) decompose the total project scope into a hierarchy.
2. An example of a nonfunctional requirement is: 2. (b)

(a) the type of material to be used.
(b) ease of use of the final product.
(c) a maintenance manual for the product.
(d) mean time between failures.
3. What is a parallel activity? 3. (a)

(a) An activity performed at the same time as another activity
(b) An activity that is necessary but outside the scope of the project
(c) An activity that must directly follow another activity
(d) An activity that contains slack or float
4. The project statement of work (SOW) is: 4. (b)

(a) the hierarchical decomposition of the project work.
(b) a narrative description of the project scope.
(c) an activity list of the work that must be completed.
(d) the requirements traceability matrix for the project.
5. What is the late finish of an activity? 5. (a)

(a) The latest an activity can finish without delaying a critical
path activity
(b) An activity that has missed its deadline
(c) The latest an activity can start based on its relationship
to predecessor activities
(d) The date a parallel activity can begin

Estimating the Activities
4
Learning Objectives
• Describe the process of progressively elabo-
rating the initial project plan.
• Define the difference between rough order of
magnitude, preliminary, and definitive esti-
mates and give circumstances in which each
is appropriate.
• Explain standard estimating techniques of
analogous estimating, expert judgment esti-
mating, Delphi method estimating, paramet-
ric estimating, and bottom-up estimating.
• Define three-point estimating and the two
methods that use it; perform PERT calcula-
tions using three-point estimates.
• List common issues in estimating, including
overoptimism, the role of contingency al-
lowances, and the use of rolling wave esti-
mates.

Reading 45 minutes

UNCERTAINTY IN PROJECT PLANNING

Our first version of a network diagram is an important milestone in develop-
ing a comprehensive and workable project management approach, but it’s
hardly the end of the process. How long will these activities take? How much
will they cost?
Sometimes we know exactly how long an activity will take and exactly
what it will cost. If you sign up to take a three-day seminar, it will take three
days—not two, and not four. If the seminar has a firm, fixed price of $1,250,
then it will cost $1,250.
Of course, there may be secondary considerations. If you have to travel
to another city and rent a car and a hotel room, you’ll incur those costs, and
they may vary depending on when and where you go, or how far in advance
you book. And if you’re traveling, you’ll probably need to leave at least a day
earlier, and may need to stay over an extra day, depending on flights.
With a little research, you can probably firm up those extra costs and
travel times, but in other cases you may be looking at a great deal more un-
certainty. At the beginning of this chapter, there’s a time estimate for how long
we expect it will take you to complete it. The reading time is based on the
word count and the average reading speed, which is 200 words per minute.
“Average,” of course, recognizes that some people read faster and others
slower. If you’re already familiar with project management, you may need less
time to absorb the concepts than if they are entirely new to you.
If you are supposed to gather user needs for a new IT system, the actual
time will be affected by how many users you survey, how willing they are to
provide you with information, how much information you ask for, and many
other variables. So how long will it take?
In this case, you have a choice. You could establish a quality goal—how
much information, how many users, what level of depth—and the time to ac-
complish it may vary. On the other hand, you could establish a time constraint,
say, two weeks, and do as much as you can within that two-week period. That
way you can guarantee you’ll make the deadline, but there’s a potential impact
on quality. You might use the hierarchy of constraints to help you choose the
best (or least worst) option, but the uncertainty remains. It’s simply shifted
position.
Think About It . . . Uncertainties on Your Project
What are some elements of projects in your organization that have uncertain durations and costs?
To what extent can you predict or control that uncertainty?

ESTIMATING THE ACTIVITIES 67
ESTIMATING METHODOLOGIES
The basic estimating methodology is known as a WAG, or Wildly Aimed
Guess. (It’s also defined in a less family-friendly way.) That’s distinct from a
SWAG, or Scientific Wildly Aimed Guess, which is delivered with a calm and
confident air, as if you know what you’re talking about.
Sometimes, guesses are the best we can do, and as long as we label them
for what they are, they can have some value in the planning process. Estimates,
unlike guesses, have history: they are based on some real data and use some real
methodology. That doesn’t always make them superior to guesses; some people’s
WAGs are better than other people’s detailed and documented estimates.
Different estimates are used for different purposes, and are based on dif-
ferent levels of understanding about a project.
A rough order of magnitude (ROM) estimate is used by decision-makers to
decide if a project will be undertaken at all. The estimator starts with very
little knowledge about the project. “How much would a new office building
cost?” Obviously, that will vary by how large the building is, whether it has
any special characteristics, where it will be built, and many other factors. But
if none of that has been decided yet, you can only come up with a very general
number. ROM estimates are considered accurate if the project comes in within
-25% to +100% of the number provided.
A preliminary estimate is based on a written statement of work (SOW), so
you have more information to work with, but a detailed plan has not yet been
created. Preliminary estimates are often used as the basis of a budget request
or a proposal bid, and are considered accurate within a range of -10% to +25%.
A definitive estimate requires a complete plan, so it’s used as the project
baseline. Because reality never quite lines up with the plan, a definitive estimate
still has some variance. It’s considered accurate in the range of -5% to +10%.
If you’re asked to provide an estimate, you should always specify the type
of estimate you’re providing, and offer the estimate as a range, rather than as
a single number.
STANDARD ESTIMATING TECHNIQUES

Depending on the detail available and the accuracy required, several common
estimating techniques are widely used: analogous estimating, expert judgment
or Delphi estimating, parametric estimating, and bottom-up estimating.
Analogous Estimating
An analogous estimate uses the real numbers from another similar project, and
adjusts them based on any known difference. How much does a new office
building cost? Well, that new five-story building over on Main Street was built
two years ago and cost $15 million. It holds 200 people. If you know you’re
going to need space for 500 people, you could multiply $15 million by 150%,
and offer an analogous estimate of $22.5 million. Notice that this type of es-
timate is a ROM, which suggests a range between $16.875 million (25% less)
and $45 million (100% more).

Expert Judgment and Delphi Estimating

If you want a good estimate, you could ask an expert. Experts bring extensive
experience and deep understanding to the table, and their numbers are often
quite accurate. There are several potential concerns, however.
First, is the expert actually an expert in the particular type of project or
activity? Some experts hate to disappoint the questioner, and will offer an “ex-
pert” opinion for which they are no more qualified than the average person.
Second, does the expert have a bias? If the expert has an economic inter-
est in the project, the estimate may be less reliable, regardless of the actual
knowledge of the expert. This isn’t always lying on the expert’s part: some-
times people tend to be optimistic when they are part of the project.
Third, is there a potential for “groupthink”? If you gather together a
group of experts and ask each in turn for an estimate, people who are asked
later tend to avoid violating the group consensus, and skew their answer to-
ward the others given.
The solution for groupthink is known as the Delphi method. In Delphi,
you give each expert an estimating worksheet with information and questions,
and have each complete it simultaneously. This keeps one person’s opinion
from being influenced by another. The average of the expert judgments is
often far more accurate than any individual’s estimate.
Depending on the questions asked and the information provided, expert
judgment estimates can fall into ROM, preliminary, or even definitive levels
of accuracy.
Parametric Estimating
A parametric estimate is one that uses a statistical model. If you ask a commercial
real estate person how much office space in your area costs, you’ll normally
get a cost-per-square-foot number. If office space goes for $35 a square foot,
and you need 1,200 square feet, the estimated annual rent is $42,000, or about
$3,500/month. Of course, the price of office space varies, but if a particular
landlord quotes a figure much higher or much lower than $3,500/month, it
should raise questions. Perhaps the difference is completely appropriate, but
you want to understand why.
That’s a simple parametric. A more complex parametric is one you’ve
encountered if you’ve purchased life insurance. An agent interviews you: your
age, your health history, whether you smoke, and many other factors. The
model queries a large statistical database and calculates what your premium
should be.
Depending on the sophistication of the model and the data available,
parametric estimates can be produced in all three categories of accuracy.
Bottom-Up Estimating
To prepare a bottom-up estimate, you need a comprehensive and complete proj-
ect plan, along with all the necessary supporting data. In a bottom-up estimate,
you begin by estimating each activity separately, rolling them up into WBS
work packages, then to control accounts, until you get to the final figure. Be-

cause a bottom-up estimate is based on the most detailed planning informa-

tion available, it constitutes a definitive estimate, which usually becomes the
baseline used to monitor project progress.
The potential danger with a bottom-up estimate is the tendency to pad
the numbers for safety. There’s nothing wrong with adjusting estimates based
on risk—we’ll learn how to do that in the next chapter—but padding is usually
just adding a WAG to the base number. Sometimes, the higher levels of the
WBS will add their own padding, and pretty soon your bottom-up estimate
is of no value. Although it’s not uncommon for project managers to pad esti-
mates, we strongly discourage the practice. Adjusting for risk is based on
analysis, not WAGs, and accomplishes the legitimate goal of ensuring you
have a reasonably good estimate without making up numbers.
Exercise 4–1
Types of Estimates
Instructions: For the following estimates, list the estimating methodology (WAG, analogous, expert,
Delphi, parametric, bottom-up) used and classify the expected accuracy (ROM, preliminary, budg-
etary, variable) of the number.
Estimate Basis Type Accuracy

1. The president says we’ll go to the moon in 10 years. ____________ ____________
2. We surveyed ten people and used the average. ____________ ____________
3. Joe has done this kind of thing a lot. ____________ ____________
4. We did something like this a few years back. ____________ ____________
5. When we added it all together, it came to $1 million. ____________ ____________
6. We ran the specs through our job cost program. ____________ ____________
7. Six weeks sounds reasonable. ____________ ____________
8. Research says 10–15K lines of code per year is average. ____________ ____________
9. Six months sounds about right. ____________ ____________
THREE-POINT ESTIMATING
In addition to these common estimating techniques, project management has
two unique estimating methodologies: PERT and Monte Carlo simulation.
Both are built on what are known as three-point estimates. This estimating tech-
nique is useful on projects that have a high degree of inherent uncertainty
and a need for accurate predictions.
Because it’s a fair amount of work, you should evaluate whether these
techniques are appropriate for your project. Even if you don’t need the infor-
mation right now, you may in the future. And if you plan to take the PMP® ex-
amination, you’ll need to have a grasp of the basic concepts of these methods.

Program Evaluation and Review Technique (PERT)

In our brief discussion of the history and evolution of project management in
Chapter 1, we mentioned the Program Evaluation and Review Technique
(PERT), which grew out of the Polaris submarine project in the 1950s. Polaris
was at the time the most complex engineering project ever undertaken, and
much of what the engineers and designers had to do had never been done be-
fore. This, of course, makes meaningful estimating problematic, and the proj-
ect planners had to invent a new approach to keep the project on track in spite
of the inherent uncertainty in the work.
The PERT method was based on the concept of three-point estimating. If
someone asks you for an estimate of how long something will take or how
much it will cost, and there’s a range, most people will provide their most likely
estimate. That seems reasonable enough, but in practice when you use most
likely estimates for individual activities, you’ll almost always end up late and
over budget.
To understand why this is, let’s look at two other potential estimates. The
optimistic estimate is the best-case scenario. It assumes that everything goes per-
fectly. The pessimistic estimate assumes the opposite: bad things will happen.
(Both of these estimates cover possibilities with a minimum of a 1% proba-
bility.) Notice that the difference between most likely and optimistic is usually
less than the difference between most likely and pessimistic. There’s only so
good it can get, but bad covers a much wider range. That makes a “most likely”
schedule extremely unlikely to meet its goals.
Because computing power in the 1950s was extremely limited, the PERT
planners were forced to come up with “quick and dirty” techniques to inte-
grate the three estimates into something that could be used in practice. Exhibit
4–1 shows the basic PERT formulas.
The PERT estimate, as you can see, is a weighted average of all three es-
timates, with “most likely” counting for more than either extreme. The Greek
letter 𝞼 (sigma) represents the standard deviation.
xhibit 4–1
PERT Formulas
𝐸 = 𝑂 + (4∗𝑀) + 𝑃 6
𝞼 = 𝑃 − 𝑂/6
Where:
E = PERT Estimate
O = Optimistic Estimate
M = Most Likely Estimate
P = Pessimistic Estimate
𝞼 = Standard Deviation

xhibit 4–2
Standard Deviation Diagram
Credit: Standard deviation diagram, based on an original graph by Jeremy Kemp, 2005. Licensed under the Creative Commons Attribution 2.5 Generic
license; downloaded from Wikimedia Commons on 1 August 2013.
The standard deviation helps you determine the probability of your actual
result meeting a given target. Exhibit 4–2 shows how the standard deviation
relates to the PERT estimate. Exhibit 4–3 provides a helpful “Z table” showing
your probability of meeting a given deadline or budget when expressed in stan-
dard deviations from the PERT estimate.
PERT calculations can be made for both time and cost. If the optimistic
estimate for an activity is $500, the most likely $750, and the pessimistic
$1,500, the PERT estimate will be ($500 + (4 * $750) + $1,500)/6, or $833.33,
and the standard deviation will be ($1,500 – $500)/6, or $166.67.
With time, there’s one additional fact you should know. If you want to know
the standard deviation for a series of activities, you have to square each of the
standard deviations, add them together, and take the square root of the sum.
Example: Take the path sequence A→B→C. A has a standard deviation
of 2 days, B has a standard deviation of 3 days, and C has a standard deviation
of 1 day. 22 + 32 + 12 = 4 + 9 + 1 = 14. The standard deviation of A→B→C is
the square root of 14, or about 3.74, which we’ll round to 4.
Exercise 4–2
Calculating PERT Estimates
Instructions: Use the PERT formulas and Z table to answer the following questions. Round all num-
bers to the nearest integer.
1. For Activity A, the optimistic estimate is 10 days, the most likely estimate is 12 days, and the
pessimistic estimate is 25 days. What is the PERT estimate and standard deviation?
2. For Activity A, the optimistic cost estimate is $5,000, the most likely estimate is $15,000, and
the pessimistic estimate is $21,000. What is the PERT estimate and standard deviation?
3. You are given a deadline of 15 days and a budget of $13,000 for Activity A. What is the proba-
bility that you will achieve the time and cost objectives?
4. For the path A→B→C, if the standard deviations are A = 4, B = 5, and C = 7, what is the stan-
dard deviation of the path?

xhibit 4–3
Z Table
This table, called a “Z table” in statistics, gives you the statistical probability of achieving a given
cost or time goal expressed in terms of the PERT estimate and the standard deviation.
Example 1: Your PERT estimate for a given activity is 10 days, and the standard deviation is 3
days. Your probability of meeting the goal in 10 days (E + 0𝞼) is 50%. Meeting the goal in 13 days
(E + 1𝞼) is 84.13%. Your probability of meeting the goal in 7 days (E – 1𝞼), however, is only 15.87%.
Example 2: Your PERT estimate for the activity is $15,000, and the standard deviation is $3,000.
If you are given a $16,000 budget, that’s $1,000 more than E, which is a third (0.3) of the standard
deviation. E + 0.3𝞼 is 61.79%. If you are given $14,000, the chance is now E – 0.3𝞼, or 38.21%.
𝞼 Probability 𝞼 Probability
-3 0.13% 0 50.00%
-2.9 0.19% 0.1 53.98%
-2.8 0.26% 0.2 57.93%
-2.7 0.35% 0.3 61.79%
-2.6 0.47% 0.4 65.54%
-2.5 0.62% 0.5 69.15%
-2.4 0.82% 0.6 72.57%
-2.3 1.07% 0.7 75.80%
-2.2 1.39% 0.8 78.81%
-2.1 1.79% 0.9 81.59%
-2 2.28% 1 84.13%
-1.9 2.87% 1.1 86.43%
-1.8 3.59% 1.2 88.49%
-1.7 4.46% 1.3 90.32%
-1.6 5.48% 1.4 91.92%
-1.5 6.68% 1.5 93.32%
-1.4 8.08% 1.6 94.52%
-1.3 9.68% 1.7 95.54%
-1.2 11.51% 1.8 96.41%
-1.1 13.57% 1.9 97.13%
-1 15.87% 2 97.72%
-0.9 18.41% 2.1 98.21%
-0.8 21.19% 2.2 98.61%
-0.7 24.20% 2.3 98.93%
-0.6 27.43% 2.4 99.18%
-0.5 30.85% 2.5 99.38%
-0.4 34.46% 2.6 99.53%
-0.3 38.21% 2.7 99.65%
-0.2 42.07% 2.8 99.74%
-0.1 46.02% 2.9 99.81%
0 50.00% 3 99.87%

Monte Carlo Simulation

If you’ve studied statistics, you will have noticed that our formulas for the standard
deviation are not what you learned. The reason is the limits to computers at the
time PERT was invented. PERT works well enough, but today’s project managers
have access to far more computing resources than the Polaris planners.
The Monte Carlo simulation technique uses the same three-point esti-
mates as PERT, but instead of applying the PERT formula, those numbers
get entered into a Monte Carlo program. There are many different Monte
Carlo simulators for project management on the market, and they usually
come in the form of a plug-in to various commercial software packages. There
are several Monte Carlo simulators for Microsoft Project®, and versions for
all the popular software packages.
When you install your Monte Carlo simulator and open your project man-
agement software, you’ll have the opportunity to enter the three-point estimates
for each activity. Some versions allow you to adjust the numbers and distribution
patterns. Once you’ve entered the data, simply run the program. Go get a cup
of coffee; this might take a while depending on the size of the project.
Starting with the first activity, the Monte Carlo simulator generates a
random number based on the three estimates and their weighting, and uses
that as the duration of the activity. If it’s earlier or later than scheduled, other
activities are moved forward or backward in the schedule based on their de-
pendencies. The program now goes to the next activity, repeats the process,
and so on until it reaches the end of the project. It stores how long it took to
complete the project (and how much was spent, if you’ve set it up that way),
then goes back to the first activity and does it again. And again, and again,
until it’s simulated the project several thousand times and generated a range
of finish dates and final costs. You can read the output to figure out the prob-
ability of meeting any particular deadline or budget.
The Monte Carlo method is both easier and more accurate than PERT,
but requires you to use a project management software program and a com-
patible Monte Carlo program. More and more, project managers are aban-
doning the traditional PERT method for the new technology.
Think About It . . . Managing Uncertainty
Not every project or every organization will receive enough benefit from PERT or Monte Carlo to
justify the time and effort involved, but in some cases it’s extremely valuable. Do these techniques
have a place in your organization’s projects? Under what circumstances would you want to use
these tools?

ISSUES IN ESTIMATING
Pretty much by definition, estimates aren’t the same thing as reality: your
mileage may vary. A healthy dose of skepticism about estimates is recom-
mended.
Overoptimism
Although some projects do come in ahead of their estimates, by far the more
common outcome is that projects tend to be late and over budget. There’s a
general bias toward optimism in the estimating process. People tend to over-
estimate how productive they are likely to be, underestimate the number of
interruptions and distractions, and fail to account for emergencies. According
to the annual Standish Group CHAOS Report on large corporate IT projects,
only 32% of projects actually meet their goals of time, cost, and performance
(Gruebl and Welch, 13).
Parkinson’s Law
Some project management authorities recommend adding a contingency al-
lowance to the time and cost estimates to account for poor estimating. Though
this has some virtues, it runs afoul of a well-known management principle
called Parkinson’s Law: work expands so as to fill the time available for its
completion (Parkinson, 1958).
If you have a comfortable amount of time in which to accomplish an ac-
tivity, there’s not a lot of urgency to get started, and there are almost always
various other issues that are calling for your attention. Adding contingency
to activities may in fact make them take longer, and the project will still be
late and over budget.
A project management technique known as critical chain project management
(CCPM) suggests that you should take the contingency allowance away from
individual activities and add them to the network diagram in the form of buffers
(Goldratt, 1997). This reduces the incentive for procrastination.
Rolling Wave Estimating

Another problem related to estimating is the extent to which knowledge and
understanding evolves in the course of a long project. If you’re looking at a
four or five year time horizon, your estimates of activity duration toward the
end of the project are highly speculative—little better than WAGs. As the
project moves forward, the experience and information you get will allow you
to improve and tighten estimates. Your initial plan might only be able to pro-
vide ROM-level estimates, but as time goes forward they can become prelim-
inary and eventually definitive. This process is known as rolling wave estimating,
an estimate iterated during the project life cycle as more information becomes
available.

Exercise 4–3
Estimating Review
Instructions: For your PMO project, you will need to make some estimates. For each estimate re-
quired, explain what technique or methodology you would use from the ones described in this
chapter, and where you might get any information necessary to develop those estimates. These
questions assume you’re using the network diagram from the Answer Key for Exercise 3–5.
1. How would you estimate the time required for Activity 1 (“Research”)?
2. How would you estimate the time required for Activity 3 (“Obtain Feedback”)?
3. How would you estimate the likely price of Activity 8 (“Obtain Outside Trainer”)?
4. How would you estimate the time required for Activity 6 (“Recruit PMO Head”)?
5. How would you estimate how much it will cost for Activity 11 (“Prepare Stockholder Presentation”)?

The first iteration of a project plan is an important milestone,

but not the end of the process. Normally, you should expect
to develop a lot of additional information and detail to flesh
out the plan and address issues.
Because there is often a great deal of uncertainty in a
project, we must normally develop estimates of time, cost, and
resources. Estimates come in varying degrees of accuracy,
ranging from rough order of magnitude (ROM) to progres-
sively more accurate preliminary and definitive estimates. Be-
sides the traditional Wildly Aimed Guess (WAG) method, other estimating
methodologies include analogous estimating, expert judgment and Delphi es-
timating, parametric estimating, and bottom-up estimating.
In project management, three-point estimates (optimistic, most likely,
and pessimistic estimates) are the basis of the Program Evaluation and Review
Technique (PERT) and the Monte Carlo simulation. The PERT method uses
statistical calculations to establish estimates and the range of likely outcomes.
Although it’s important for project managers to understand the PERT ap-
proach, the Monte Carlo method, which uses a software package to simulate
the project repeatedly, is more accurate and easier.
It’s much more common for projects to exceed their estimates rather than
meet them. Overoptimism and the failure to account for interruptions and
emergencies are common reasons. Some project management authorities rec-
ommend adding a contingency allowance, but that may trigger Parkinson’s
Law: the tendency of work to expand to fill the time available. The discipline
of critical chain project management suggests using buffers to hold contin-
gency rather than allocate it to individual activities or work packages.
In long projects, the availability of information increases over time, so
initial estimates are generally less meaningful than estimates prepared closer
to the start of the activity. Rolling wave estimating evolves the quality of the
estimate over the life cycle of the project as new and better information be-
comes available.

Review Questions
1. A preliminary estimate has an expected accuracy of: 1. (d)

(a) -25%, +100%.
(b) -25%, +75%.
(c) -5%, +10%.
(d) -10%, +25%.
2. One reason why projects are more frequently late and over budget 2. (a)
than early and under budget is:
(a) overoptimism in the estimating process.
(b) changes in scope requested by customers.
(c) using rough order of magnitude rather than preliminary estimates.
(d) incorrect calculations of the critical path.
3. Which of these is a potential danger in developing a bottom-up estimate? 3. (d)

(a) Flaws in the parametric model that is used
(b) Failure to use the Delphi method
(c) Relationship of the analogous project to the one being estimated
(d) Some team members may pad their estimates
4. If you decide the quickest an activity can be completed is six weeks, 4. (c)
the worst case is 24 weeks, and the most likely time is 12 weeks, what
is the PERT estimate and the standard deviation?
(a) E = 7, 𝞼 = 3
(b) E = 13, 𝞼 = 18
(c) E = 13, 𝞼 = 3
(d) E = 12, 𝞼 = 2
CALCULATION: The formula for the PERT estimate is (O + 4M + P)/6, or (6 + (4 * 12) +
24)/6 = 13. The formula for the standard deviation (𝞼) is (P – O)/6, or (24 – 6)/6 = 3.
5. In a PERT analysis, what is the probability that an activity will be 5. (c)

completed no later than one standard deviation from the estimate?
(a) 68.2%
(b) 50.00%
(c) 84.13%
(d) 15.87%

Preparing a Project Plan
5
Learning Objectives
• Describe the process of progressively elabo-
rating the initial project plan.
• Identify staffing and resource requirements
for a project.
• Describe how to build the project team and
prepare a responsibility assignment matrix
(RAM).
• Explain the concepts of loading and leveling
a project schedule.
• Describe the roles of outsourcing and pro-
curement planning.
• Perform critical path method (CPM) calcu-
lations and explain the circumstances in
which they are appropriate.
• Develop a communications and stakeholder
management plan.

Reading 55 minutes
Exercises 2 hours

PROGRESSIVE ELABORATION AND THE

PROJECT PLAN
A project plan consists of far more than simply a schedule. You need a budget,
a staffing plan, a procurement plan for any outsourcing or purchasing, a com-
munications plan to manage stakeholders, and plans for ensuring quality and
managing risk.
In our planning process so far, we began with a statement of work (SOW),
which we developed into a work breakdown structure (WBS). From the WBS,
we developed an activity list and prepared a network diagram and Gantt chart.
That constitutes a preliminary project plan.
In Chapter 4, we developed the plan by creating estimates for activities and
using those estimates, developed confidence measures using PERT and Monte
Carlo to see whether we would be able to meet the time and cost constraints.
In this chapter, we’ll continue to flesh out the components of the project
plan, including human resources, procurement, and communications plan-
ning. On the way, we’ll look at using the critical path method (CPM) as a tool
to balance scope and schedule. In the next chapter, we’ll address managing
quality and risk.
It’s important to note here that as you move forward in the planning
process, you normally learn information that will change some of your earlier
ideas. The SOW, WBS, network diagram, and estimates can and should
evolve—it’s the iterative nature of project planning in action. If you find that
your real-world planning process sometimes feels like “two steps forward, one
step back,” that’s probably a sign that you’re doing it right.
STAFFING AND RESOURCE REQUIREMENTS

In estimating, we figure out how long a project will take and how much it will
cost, but these are not the only considerations. How about people? How many
do we need, when do we need them, and what skills do they need to have?
Will our project require access to specialized tools and equipment?
In the real world, we’re often told how many people we get, and frequently
told who they are, even before we begin the planning process. Even so, we still
need to allocate people to different activities and make sure all the work is cov-
ered. If we have missing skills or too few (or too many) people, we may need
to go back to our project sponsor and see if we can modify the situation.
BUILDING THE PROJECT TEAM

In planning, the first step is to compare the team you have with the team you
need. There are three characteristics about your team you need to assess: the
number, the work maturity, and the skill set.
Number. Consider both the raw number of people available to your proj-
ect and the percentage time commitment of each. Two people available
only half the time counts the same as one full-time person. Some people
will be committed to your project from beginning to end, and others may

PREPARING A PROJECT PLAN 81
be available only for particular phases. That may be completely sensible,

as projects often have different work requirements at different times.
Work maturity. Work maturity encompasses level of experience, attitude
toward the organization and the project, ability to work independently
or with little direction, and other considerations. A person of low work
maturity isn’t necessarily a bad performer, but may simply be a relatively
fresh hire. Some people with lots of experience but bad attitudes might
be considered as having even lower work maturity.
Skill set. With some activities, it doesn’t matter which team member you
assign because they all possess the necessary skills. In other cases, you
may be very limited in who you can assign to a particular activity.
To find out whether your team is sufficient for your project, you must
assign team members to work packages or activities to see if there are any
problems. In addition to making sure that each activity is covered, you also
need to check that you haven’t inadvertently double-booked people on par-
allel activities. For the first, you’ll begin with a responsibility assignment ma-
trix (RAM), and for the second, we’ll look at resource loading and leveling.
Responsibility Assignment Matrix (RAM)

A responsibility assignment matrix, or RAM, is a tool that links resources to
activities. (You may also see this referred to as a RACI matrix.) To build a
RAM, you must first look at your project to see what skills are required to ac-
complish the work. Exhibit 5–1 takes the network diagram from the pharma-
ceutical project we developed in Exhibit 3–6 and lists the skills we need to
perform this project. Exercise 5–1 allows you to apply this tool to the PMO
case study project.
Exercise 5–1
Skill Requirements
Instructions: For the PMO case study project, analyze the network diagram you developed in Ex-
ercise 3–5 and list the skills your team needs to accomplish the work.
Exhibit 5–1 shows that we need one or more writers, at least one editor,
and one or more people in data management. Although project management
is involved throughout the project, the project manager has primary respon-
sibilities in such activities as assigning the team and in overseeing the review
process and completion of the final package.
Notice that we’ve listed “technical and management reviewing” as a skill
required to accomplish this project, but it’s pretty clear that those technical
and management reviewers aren’t part of our project team in any normal
sense. But they are part of the team in the sense that we can’t get the project
done without their input. The project manager doesn’t only have to manage

xhibit 5–1
Skill Requirements
1 weeks 4 weeks 8 weeks 7. Draft 8. 9. 10.

11. Write 12. Final
Final Signoff
14.
2 weeks 6 weeks 2 weeks 6 weeks 2 weeks 6 weeks FInish
Submit
0 weeks 2. Obtain 3. 4.
13. Print 1 weeks
Data Data Index 0 weeks
Data
4 weeks 12 weeks 3 weeks Total Time = 60 weeks
3 weeks
Critical Path = 44 weeks
Skills required:
Writing (Activities 5, 7, 9, 11)
Editing (Activities 5, 7, 9, 11)
Data Management (Activities 2, 3, 4, 13)
Project Management (Activities 1, 6, 8, 10, 12, 13)
Technical and Management Reviewing (Activities 6, 8, 10, 12)
the official team, but also has to “manage up” (Dobson and Dobson, 2000). In
this case, the project manager needs to identify the reviewers, make sure they
schedule the necessary time, make sure they get the information they need,
and follow up to make sure it all gets done.
The next step is to link those required skills to the skills possessed by
your team, which we’ve done in Exhibit 5–2. (We don’t need to assess the re-
viewers, so they don’t go on this list.) In Exercise 5–2, you will prepare your
own team skill assessment.
Exercise 5–2
Skill List
Instructions: As project manager, we assume that you have project management skills. You may
choose three of the following five candidates to complete your team.
Nguyen: Five years’ experience with the company in staff-level roles, BS degree in
Information Management. Skilled with PowerPoint.
Susan: Human resources generalist with four years’ experience.
Gemma: Three years with the company in management, MBA.

Jurgen: Three years in shareholder relations and two years in corporate

communications, MBA.
Sean: Edits company newsletter while serving as human resources manager for one
of the divisions, BA, four years’ experience.
Team Policy Project Org.

Research Writing Procurement HR Presentation
Member Development Management Devel.
Nguyen
Susan
Gemma
Jurgen
Sean
Now, we need to put this together into the final RAM table, shown in
Exhibit 5–3. For simplicity, we’ll add two reviewers: Yuri, the project sponsor,
and Maria, the technical reviewer. The project manager is Aliverdi. Exercise
5–3 gives you the opportunity to develop your own RAM.
xhibit 5–2
Team Skills
Team Data Project

Writing Editing
Member Management Management
Harry A N A N
Sally E E A N
François E A A A
Mariko A N E A
Aliverdi A A N E
Work maturity/skill level codes: N (Novice), A (Average), E (Expert)

xhibit 5–3
Responsibility Assignment Matrix
Activity Responsible Consulted Informed Approval

Assign Team Aliverdi Team Yuri
Obtain Raw Data Mariko Harry
Organize Raw Data Mariko Harry Maria
Harry,
Prepare Index Sally Mariko Aliverdi
François
Write Summary Sections François Sally Sally
Review Summary Sections Aliverdi Sally Yuri Maria
Draft Overall Summary François Sally
Review 1st Draft Maria Aliverdi Yuri Maria
Rewrite Summary François Sally
Review 2nd Draft Maria Aliverdi Yuri Maria
Write Final François Sally Yuri, Maria Aliverdi
Final Signoff Maria, Yuri Aliverdi Yuri
Print Aliverdi Mariko, Sally Yuri
Submittal Aliverdi Mariko, Sally Maria Yuri
Exercise 5–3
Responsibility Assignment Matrix
Instructions: Prepare a RAM for the PMO case study project based on your network diagram and
the information you developed in Exercises 5–1 and 5–2.

LOADING AND LEVELING THE SCHEDULE

When we map our assignments to the network diagram (known as loading the
schedule), we notice that Sally is responsible for preparing the index (4) and
for overseeing/editing the writing of the summary sections (5). Because these
tasks are on parallel paths, there’s a possibility that Sally may end up being
booked for two jobs simultaneously. We need to look closely at the schedule
to see if there’s a problem, and solve it if necessary.
Because Organize Data (3) takes 12 weeks, it looks like François and Sally
will be done long before the index must be prepared, so we don’t have a prob-
lem. But what if we did? In that case, we would have to level the schedule, or bal-
ance the workload and the resources available to do it. There are several ways.
The first way is to delay one of the double-booked activities. If Sally has not
finished editing François’s first draft when she’s supposed to start indexing,
you could delay the start of the indexing task until she’s available. This may
push out the schedule.
Another way to solve the problem is to reassign one of Sally’s jobs, either
by finding another editor for the writing job, or by finding another indexer
for the indexing job. Both of these run the risk of simply transferring the over-
load to another team member.
Third, rather than reassigning one of Sally’s jobs to another team member,
we could ask for another person to join our team. We could look for another
skilled writer/editor, or for another indexer. Notice we might not require that
new position for the life of the project.

Think About It . . . Loading and Leveling
Have you encountered situations in which a staff member was “double booked” for project activi-
ties? At what point did you realize it? Could you have found the problem earlier, and if so, what
might you have done differently?
OUTSOURCING
We also don’t necessarily have to confine ourselves to resources on hand.
Maybe we don’t have people with all the necessary skills, or perhaps we have
so much going on that everybody’s fully booked with other work. In that case,
we could consider outsourcing.
Almost any aspect of a project can, at least in theory, be handed off to some-
one else. If you have to make widgets, you can hire a manufacturer to make
them for you, or an engineering firm to design them. If you need writers, editors,
or indexers, you can hire them as consultants. If you’ve got to organize 100,000
pages of raw data, there are consulting firms that specialize in just that service.
Make or buy decisions are a powerful tool in the project manager’s arsenal.
Depending on your organizational circumstances, sometimes doing it yourself
is the best option, and sometimes it’s better to hire it out. Such factors as qual-
ity, speed, relative experience or capabilities, and what else internal resources
could do instead of that work can influence the decision. The best time for
make or buy decisions is early in the planning process, because they will have
a significant effect on the final project plan.
Procurement Planning
As you decide what you will be procuring as part of managing your project, you
need to start a procurement process. You need to define what you want to buy,
and identify one or more vendors who can supply your need. You will have to
get bids or proposals, evaluate them, choose your supplier, and negotiate nec-
essary contracts. Throughout the procurement process, you will need to make
sure that the vendor is performing on schedule and meeting requirements. You
will need to receive, inspect, and approve what you bought, and you will need
to pay invoices. All of these are activities that belong in your project plan.
The procurement process can turn into a major part of a project man-
ager’s responsibilities. A comprehensive study of procurement is, however, a
bit beyond the scope of this course. Many resources are available on this topic,
both in print and online.

Think About It . . . Make or Buy
How do you make “make or buy” decisions on your projects?
CRITICAL PATH METHOD (CPM)

ANALYSIS
Resources and time are often linked. More people and equipment can, in
many cases, accomplish activities in less time, but at the cost of more dollars.
Critical path method (CPM) analysis provides a methodology for balancing
time, cost, and resources for optimal project results.
The Northridge Overpass Disaster

In Los Angeles’s 1994 Northridge earthquake, an overpass collapse closed In-
terstate 10, a critically important transportation link. This was hugely destruc-
tive to the area, with a community impact estimated at about $1 million per
day. The California Department of Transportation and the Federal Highway
Management Administration expedited contracts and offered a $200,000 per
day completion bonus for the reconstruction. It only took 74 days for the con-
tractor to finish the job—winning a $14.8 million bonus in the process
(USDOT, 1994).
By the standards of large highway interchange construction, this is re-
markably fast, but a $200,000/day bonus is quite an incentive. From the city
of Los Angeles’s point of view, though, it wasn’t excessively generous. If the
city is losing $1 million per day, every day the project finishes ahead of sched-
ule is a net $800,000 benefit—$59.2 million in total. That puts the $14.8 mil-
lion bonus in perspective.
Implications for Project Planning

The general project management lesson to take from the Northridge case is
the observation that in many cases, there is a financial benefit to finishing
early (and a corresponding cost of being late). At the very minimum, finishing
early cuts the overhead cost of running the project.
The second lesson is that there is often a tradeoff between what you
spend to accomplish a work package and how long it takes. If you want to
build a brick wall of a certain dimension, you can calculate how long it would
take a single bricklayer. If you added a bricklayer, you’d cut the time in half,

but you’d be paying two people. Add more people, and you’ll continue to re-
duce the total time, up until some point of diminishing returns, where another
body doesn’t save you very much (or worse, the bricklayers start tripping over
one another).
It should be noted that extra resources don’t always produce a time ben-
efit. The classic project management example is that it take one woman nine
months to have a baby, but it doesn’t follow that nine women could get the
job done in one. In addition, there are some tasks that are highly uncertain,
and you cannot predict the value of adding people. If you want to develop a
new concept design, two people might get the job done faster than one, but
they could get mired in an argument and actually take longer.
Critical Path Method

Insights like these led to the development of the critical path method (CPM),
a scheduling technique with a number of similarities to PERT. It was devel-
oped by DuPont and Remington Rand in the 1950s. We take the idea of the
critical path from CPM, as well as the term “slack.” (“Float” came from PERT,
but the two words refer to the same basic concept.)
Where the systems differ is the particular problem they address. PERT
is a planning tool designed for projects with a high degree of uncertainty.
CPM focuses on the kind of project where extra resources have a reliable,
measurable effect on scheduling.
Let’s go back to Interstate 10. In this project, we’ve been offered an in-
centive of $200,000 a day. In order to speed up the project, we will have to
add resources, so our costs will go up. If our target is, say, to keep $50,000 of
that bonus as profit, that gives us $150,000 per day to spend on additional re-
sources. But we can’t just throw that money around; we have to target it. CPM
analysis shows us how to target the money.
Crashing a Project
Under normal conditions, we’d spend a certain amount of money to get a job
done is a normal amount of time. If we crash the project, we add resources.
The crash duration, in CPM, is the shortest possible time in which an activity
can be completed, and the crash cost is how much you have to spend to achieve
it. The value of early completion is how much it’s worth to get it done early.
Since the goal of spending this extra money is to speed up project com-
pletion, it only makes sense to crash activities on the critical path. Crashing
noncritical activities just creates more slack. Using the network diagram in
Exhibit 5–4, we’ll demonstrate a step-by-step crashing of a project. In Exercise
5–4, you’ll do your own.
Let’s assume that the value of early completion is $250,000 per week.
Clearly, it makes sense to crash Activity A ($200,000 per week), but not Ac-
tivity H ($260,000 per week, more than the value of early completion). We
spend an extra $1 million, but get $1.25 million in early completion value, for
a net savings of $250,000.
Crashing any of the noncritical activities doesn’t give us any benefit. On
the critical path, we start with the cheapest crash (Activity F, save 1 week and

xhibit 5–4
Crashing a Project Using CPM
Activity B Activity D Activity F
11, 8 15, 8 6, 5
$150 $165 $100

Activity A Activity H
10, 5 5, 3
$200 Activity C Activity E Activity G $260
9, 6 11, 9 8, 5
$100 $50 $80
Key:
“11, 8” = Normal time, Crash time (in weeks)
$150 = Cost per week of crashing (in thousands)
Critical path activities in black; noncritical activities in gray
Value of early completion = $250,000 per week
$150,000). Next, we crash Activity B, saving 3 weeks and $300,000. (Our proj-
ect expenditure, however, increased by $550,000.)
Before we start on Activity D, let’s go back and look at the critical path
again. In the original project, BDF = 32 weeks, and CEG = 28 weeks.
(We only count normal time for the initial calculation.) We’ve now crashed
BDF by a total of four weeks, meaning that both paths are now 28 weeks,
and critical! Even though there’s still the opportunity to crash Activity D,
doing so won’t speed up our completion any more.
But we’re not done yet. We can continue crashing, but now we have to
crash both paths at the same time to get any more schedule benefit. The only
crashable activity on the top route is Activity D, with a crash cost per week of
$165,000. Of the three noncritical activities, the cheapest to crash is Activity
E, at $50,000. There are two days in Activity E, so we only crash Activity D
by the same two days. It costs us $165,000 + $50,000 per week, or $215,000,
and we pick up another two days and save an additional $70,000.
Are we done yet? The next cheapest pair is Activity D (which is now 13,
8) and Activity G. The combined crash cost of these activities is $245,000.
This is very close to our limit. Depending on how confident we are of our
numbers, we might or might not take this. If we do, we can take another three
days out of Activity D and three out of Activity G for a net savings of $10,000.
Activity D still has two days of potential crash left, and Activity C has
three. But the cost of crashing both has now reached $265,000, above our

$250,000 value. Therefore, we won’t crash those last two activities. Exhibit
5–5 summarizes what we did.
If this sounds a little too good to be true, notice we spent an additional
$2,715,000 to achieve a time savings of 14 weeks. The gross benefit of being
14 weeks early is $3,500,000. Subtract those extra costs to get a net benefit of
$785,000.
Exercise 5–4
CPM Analysis
Instructions: Perform a CPM analysis of the following project. Critical path activities are shown in
black and noncritical activities are shown in gray. The value of early completion is $250 per day.
Critical Path = 0 + 15 + 21 + 8 + 2 = 46
15, 10 21, 18 8, 1
$100 $125 $200
Activity A
Activity H
0, 0
2, 1
$0
$50
Activity C Activity E Activity G
11, 9 9, 7 12, 5
$150 $175 $100
Slack = 46 - (0 + 11 + 9 + 12 + 2) = 46 - 34 = 12
COMMUNICATIONS AND STAKEHOLDER

MANAGEMENT PLAN
We’ve already emphasized the importance of stakeholder management and
communication in project management. In the planning stage, you should
think about exactly what you need to do to achieve your goals in these areas.
Do you need to have regular meetings with stakeholders? Do you need
to give them reports or briefings? Do they need to be in the loop in specific
decisions or on specific issues? Are they entitled to certain project informa-
tion? Is there information that should not be provided to them?
It’s important to get this down in writing in some organized form. With
numerous stakeholders and different information requirements, it’s all too
easy to forget who is supposed to know what, when, and how often.

xhibit 5–5
Summary of Crashing Activities
Cumulative Cumulative
Crash Activities Time Saved Money Saved
Time Saved Money Saved
1 A 5 weeks $250,000 5 weeks $250,000
2 F 1 week $150,000 6 weeks $400,000
3 B 3 weeks $300,000 9 weeks $700,000
4 D, E 2 weeks $70,000 11 weeks $770,000
5 D, G 3 weeks $15,000 14 weeks $785,000
One way to prepare a communications and stakeholder plan is to organize

it in a chart form, such as the one in Exhibit 5–6. In Exercise 5–5, you’ll de-
velop one for the PMO case study project.
Exercise 5–5
Communications and Stakeholder Management Plan
Instructions: Complete the communications and stakeholder management plan for four stakehold-
ers of your choice.
Stakeholder What the stakeholder What we need/want Communications Responsible

needs/wants from us from the stakeholder Strategy Person

xhibit 5–6
Communications and Stakeholder Management Plan Template
Stakeholder What the stakeholder What we need/want Communications Responsible

needs/wants from us from the stakeholder Strategy Person
Customer Successful outcome, Continued support, Weekly status Project

updates on progress, satisfied with outcome, summary, monthly manager
major issues feels informed meeting, inform about
major issues
Project Successful outcome, Approvals, support, Weekly status report Project

sponsor detailed progress resources, money, and meeting, escalate manager
information, major understanding issues as needed, give
issues and decisions early warning of
potential issues
Project team Successful outcome, Hard work, results, Daily check-in, weekly Project
members knowing overall status, early warning of status meeting, regular manager
having clear direction issues, creative praise for achievements
and support problem-solving,
teamwork
Project Successful outcome, Leadership, problem- Daily check-in and Team,

manager detailed knowledge of solving, running weekly status meeting Sponsor,
what’s going on, active interference, providing with team, weekly Customer
support from other support meeting with sponsor,
stakeholders, clear monthly meeting with
goals customer

The first iteration of a project plan is an important milestone,

but not the end of the process. Normally, you should expect
to develop a lot of additional information and detail to flesh
out the plan and address issues.
Staffing and developing the project team must involve
determining the skills your project requires and the skills that
team members bring to the table. You may need to negotiate
(or renegotiate) team size based on this analysis. A responsibility assignment
matrix (RAM) is often used for this purpose. When you assign team members
to activities in your network diagram (known as loading the schedule), you
may discover that you have booked the same team member on simultaneous
activities. To resolve the problem, you must level the schedule, either by mov-
ing the start date of tasks to allow the same person to complete both, or by
obtaining additional resources to cover the overlap. In addition to in-house
resources, outsourcing may be an option.
Make or buy decisions are used to determine whether it is best to do par-
ticular project activities in-house or procure them elsewhere. Such decisions
should be made as early in the project planning process as feasible. Procure-
ment requires active management and will likely alter your list of activities,
network diagram, and other project planning documents.
The critical path method (CPM) takes advantage of the fact that there is
often a financial benefit to finish a project early, and that additional resources
can speed up many activities. As long as you spend less in additional resources
than the time savings is worth, you end up with a project that is both faster
and cheaper. In crashing a project, you focus on critical path activities, because
shortening them will shorten project duration, whereas shortening noncritical
activities only increases the amount of slack.
A communications and stakeholder management plan allows you to de-
fine the specific communications strategies and activities you will follow, so
that you can add them to the work of the project.

Review Questions
1. Why should you prepare a communications and stakeholder 1. (d)

management plan?
(a) To keep the CEO and top executives up to date on project progress
(b) To ensure that project team members know the activities for which
they are responsible
(c) To keep stock analysts informed of major projects
(d) To avoid forgetting who is supposed to know what, when, and how often
2. The value of critical path analysis is: 2. (a)
(a) to determine when spending additional resources to speed up an
activity is profitable.
(b) to manage the effects of uncertainty in a project plan.
(c) to determine the total duration of a project with parallel activities.
(d) to manage loading and leveling of the schedule.
3. If John is assigned to two parallel activities with schedule dates that 3. (d)
overlap, one solution is to:
(a) tell John to do the activities and not be late, or there will be
consequences.
(b) stop the project because it cannot be accomplished.
(c) document the problem in your regular progress report.
(d) find another person to do one of the activities.
4. What is the difference between PERT and CPM? 4. (c)
(a) CPM is designed to help plan projects with high uncertainty;
PERT is designed to determine when extra resources will
profitably speed the schedule.
(b) PERT is designed to help plan projects with complex technical
activities; CPM is designed to plan projects with large numbers of
team members.
(c) PERT is designed to help plan projects with high uncertainty;
CPM is designed to determine when extra resources will
profitably speed the schedule.
(d) PERT is designed to plan projects using a lot of contracting and
outsourcing; CPM is designed to plan projects when in-house
resources will be used.
5. What is a responsibility assignment matrix? 5. (c)
(a) A list of skills required to complete project activities
(b) A tool to ensure that all communications and stakeholder management
activities have owners
(c) A tool that links resources to activities
(d) A list of skills possessed by your team members

Managing Risk and Quality
6
Learning Objectives
• Describe how risk and quality relate to other
project constraints.
• Define the concept of risk in project manage-
ment.
• List the steps in the risk management process,
including:
• Define risk, risk management threat, op-
portunity, business risk, pure risk, risk tol-
erance, risk thresholds, residual risk, and
secondary risk as they relate to project
planning.
• Describe the fundamental formula of risk
and its role in calculating expected mon-
etary value and preparing decision trees.
• Develop a risk management policy based
on templates.
• List at least ten sources of information
that support risk identification.
• Construct and fill out a risk register.
• Develop a probability and impact matrix.
Reading 1 hour 50 minutes • Describe eight types of risk responses for
both threats and opportunities.
Exercises 2 hours 25 minutes
• Explain the difference between product and
Review Questions 10 minutes process quality and between functional and
nonfunctional requirements, and list at least
four quality management tools.

THE PROJECT UNIVERSE

In Chapter 2, we discussed the importance of the triple constraints. Under-
standing the interplay of the constraints is crucial, but there’s more to the pic-
ture. The triple constraints are the outer boundaries of success: the most we
can spend, the longest we can take, and the least we can do, but we might want
to do better. That’s quality.
We don’t control everything about our project, and there are many things
we just don’t know and won’t know until much later. Some of this will affect
our project. That’s risk.
Exhibit 6–1 gives an expanded picture of our project universe. Quality
is the drive to improve in all three constraints: to do more and better, do it for
less, and do it more quickly. That’s why it’s a triangle inside the triple con-
straints, putting pressure on all three. Surrounding our project is the world of
risk, the things that might happen to the project. Risks can be threats, or they
can be opportunities. In this chapter, we’ll examine how quality management
and risk management enter into the project planning process.
RISK
The PMBOK® Guide defines risk as “an uncertain event or condition that, if it
occurs, has a positive or negative effect on one or more project objectives such
as scope, schedule, cost, and quality.” This should be interpreted in a broad
sense. Some risks have no immediate project impact, but can cause widespread
and long-term collateral damage outside the envelope of the project. Although
xhibit 6–1
The Project Environment
Quality
Risk

MANAGING RISK AND QUALITY 97
these may not always be project risks per se, they very definitely fall within the
project manager’s area of concern.
The term risk always describes the future, which is uncertain by defini-
tion. A risk may or may not actually happen. If it does happen, it’s no longer
a risk: it’s a problem. When we manage risk on a project, we are managing
some events that wouldn’t have happened anyway. The problem is that we
don’t always know which events those are.
The philosophy of risk management can be summarized in the Godzilla
Principle (Dobson, 1996). In the archetypical Japanese monster movie, the
monster often starts as a little baby, and as a result is ignored until massive ra-
diation exposure turns it into a rampaging giant with the desire to destroy
downtown Tokyo. All the people who ignored the baby monster are now out
in the streets, crying, “What are we going to do?” Unfortunately, most of the
good and easy options now lie in the past. Though not every baby monster
will grow into Godzilla, baby monsters in general are much easier to kill. In
other words, the opportunities to resolve an issue tend to decrease over time.
Though risk management is proactive and problem solving reactive, that
doesn’t mean problem solving isn’t important. No matter how well you plan,
sometimes Godzilla sneaks into Tokyo on the back roads.
Threats and Opportunities

In normal conversation, the word “risk” usually refers to negative conse-
quences, but as you see, the PMBOK® definition expands the idea of risk to
include potentially positive consequences as well. We subdivide risk into the
categories of threat (negative risk) and opportunity (positive risk).
Risks that only have potentially negative consequences are sometimes
called pure risk or insurable risk, implying one of the strategies often used to deal
with it. If a pure risk doesn’t happen, it’s a non-event. If you don’t get into a
car accident today, you aren’t better off; you failed to become worse off. In gen-
eral, if you can get rid of a pure risk at an appropriate cost, it’s a good idea.
Risks that combine threat and opportunity are known as business risks. In-
vestments, whether in the stock market or in new production capacity, have
some chance of success and some chance of failure. Unlike pure risk, it isn’t
always a good idea to avoid business risk. Sometimes, it’s appropriate to add
additional business risk to your project in hopes of realizing the opportunity.
Pricing Risk
Because risks, by definition, may or may not happen, the question arises: how
much should we be willing to spend in order to manage a particular risk? To
determine this, we have to figure out how likely it is that the risk will occur,
and how serious the impact of the risk will be if it occurs. That leads us to the
fundamental formula of risk:
R=P×I
In this formula, “P” stands for probability, “I” stands for impact, and “R”
is the risk score, or value of the risk itself. If there’s a 25% chance that a risk
could cost your project $10,000, the risk score is $2,500. If you can deal with

the risk effectively for less than $2,500, you’ve got a pretty strong business
case justification for action. However, the reverse isn’t automatically true.
When you buy car insurance, what you have to pay consists of the value of
the risk (how much the insurer expects to pay out for claims), plus the insurance
company’s cost of doing business and the profit the company hopes to make.
(Compensating for that somewhat is the income the insurance company makes
from investing the pool of money it takes in.) The bottom line is that you end
up paying more than the underlying value of the risk. This extra money is
known as a risk premium (which is why your bill says “premium” on it).
Is this a good idea? Well, for most of us, having to shell out several hun-
dred thousand dollars if we’re in a major accident is likely to be financially
devastating. Paying a premium to protect ourselves against a potentially cat-
astrophic risk is sensible. Because we’re paying more than the underlying
value of the risk, we do have to make a business case for why spending the
additional money is a good idea.
What about business risk? The P x I formula still applies, but we have to
consider both sides. Let’s say that we’re considering an investment in new
technology. There’s a 50-50 chance we’ll succeed. If we succeed, we expect
to make $100,000. If we fail, we’ll lose our investment of $50,000. The value
of the risk is (50% x +$100,000) + (50% x -$50,000), which works out to
+$25,000. In other words, this particular business investment has a positive
net risk score.
Should we make the investment? Not so fast. We should consider what
the impact on the company will be if we lose $50,000. For a mid-size or large
company, that’s unlikely to be fatal. If we’re financing a start-up with a second
mortgage on our house, the loss of $50,000 could be very serious indeed. We
should also consider what else we could do with that $50,000. If we are com-
paring two investments, one with a positive risk score of +$25,000 and the
other with a positive risk score of +$50,000, we will probably pass on the first
opportunity to take the one with a higher potential payoff.
Uncertainty About Uncertainty

An automobile insurer has thousands and thousands of customers, and there
are extensive data on automobile accidents going back years. Statistical analy-
sis can calculate probability and impact with a great deal of confidence. Proj-
ects, however, are temporary and unique. Often, there isn’t enough experience
for us to calculate the probability of an event happening with any meaningful
degree of accuracy. We’re more likely to know the potential impact, but even
that can be shrouded in mystery.
In project risk management, we must manage our risks without the com-
fort of strong statistical support. Projects are temporary and unique, so we
don’t have the “law of large numbers” working on our behalf.
Even in the absence of solid numbers, the P x I formula still helps us get
at least some idea of the value of a risk. If the probability of an event is low
and the impact is moderate, the risk value is moderately low. While translating
this into an actual money figure is a bit of a judgment call, we at least have
some parameters with which we can work.

Risk Tolerance
For most of us, a $300,000 car accident would be financially devastating, and
paying a premium for insurance is a very good idea. (In many places, it’s also
the law.) For Bill Gates or Warren Buffett, however, $300,000 is a minor ex-
penditure. There’s no value in paying a premium for a risk you can afford. For
those of us of more modest means, we normally have a deductible on our in-
surance policy, which represents an amount of money we can afford to pay
should we have an accident.
We’ve talked about risk in financial terms, because that’s the easiest to
measure. However, risks can fall into many different categories: safety and
health, reputation, legal or regulatory, or our personal career. You may have
a different attitude about risks in one category than in another. Some people
are reluctant to invest in the stock market but skydive on the weekend.
We use the term risk tolerance to describe the amount of threat risk we are
willing to accept in a specific category. Our personal risk tolerance may not
be the same as the risk tolerance of our company or our customer, and we
must often accept their risk tolerances as a constraint on our project. The term
risk appetite describes our willingness to accept opportunity or business risk.
In each category of risk, we (and our organization and our customers)
have a risk threshold. Some risks are simply too expensive and we are unwilling
to accept them; risks below the threshold are ones we are willing to consider.
In an organization, you as the project manager may be able to address risks
below the threshold on your own initiative, but risks above the threshold re-
quire review and approval by senior managers.
It’s often the case that neither we nor our organization have fully thought
through our risk tolerance, appetite, or thresholds. You may need to do some
inquiry to pin down these elements to determine your appropriate actions.
Exercise 6–1
Risk Tolerance
Instructions: Compare your tolerance for risk to that of your employer or organization. How much
risk would you take if the net benefit were positive? If you can quantify the risk threshold, do so; if
not, describe the tolerance as “high,” “medium,” or “low.”
Organizational Risk
Risk Category Personal Risk Tolerance
Tolerance
Financial Risk
Legal/Regulatory Risk
Risk of Being Sued

Physical Safety Risk to

Self or Others
Risk of Harm to the
Environment
Risk to Reputation
Risks to Product Quality
Publicity Risks
RISK MANAGEMENT PROCESS

Risk management primarily takes place in the planning and monitoring/con-
trol processes of our project, although an initial risk assessment should gen-
erally be part of deciding whether to go forward with a project in the initiation
phase. Notice that a project risk environment normally evolves during the
project, adding new risks. You will need to continually iterate the risk planning
steps throughout the project life cycle.
The PMBOK® Guide lists the following processes in project risk management:
• Plan risk management
• Identify risks
• Perform qualitative risk analysis
• Perform quantitative risk analysis
• Plan risk responses
• Control risks
Although performing risk lessons learned isn’t specifically listed as a

process, evaluating the risk management effectiveness should be a significant
part of overall lessons learned reviews.
In this chapter, we address all the steps except for “Control risks,” which
we will talk about in Chapter 8, “Controlling Time, Cost, and Scope.”
Planning Risk Management

Different projects and different organizations take different approaches to risk
management. If you’re building a nuclear reactor, you want a process that’s a
lot more robust than if you’re installing AV in the conference room. Risk man-
agement for services is not the same as risk management for products.
In deciding on how robust or detailed a risk management approach needs
to be, consider such factors as size of the project, potential impact of project
failure, complexity, and the extent to which the project takes you into unfa-
miliar territory.

Some organizations put a monetary threshold for formal risk manage-

ment plans, say $1 million. Others focus on any project with certain categories
of risk. Sometimes, a particular part of a project needs more in-depth risk
planning than another, say, if you are configuring a new assembly line and
need to make sure you’re OSHA compliant.
There are two potential approaches to risk management planning. The
first is to establish a policy at a high organizational level and make sure all
projects operate within that policy. If you don’t have such a policy, then you
get to develop your own internal risk management process, and if necessary,
get appropriate stakeholder approvals. A number of risk management plan
templates are available on the Web. Several risk management resources, in-
cluding templates, can be found in Appendix D: Additional Resources.
Think About It . . . Risk Management Policy
Does your organization or department have a formal risk management policy? If so, what types of
projects or situations are covered? How does the system you use work in practice? If not, how are
risks managed today? What works and what doesn’t work?
Identifying Risks
Once you’ve decided on your overall approach, the next step is to identify the
risks themselves. This can be as simple as having a meeting to brainstorm pos-
sible risks, or depending on what’s at stake, can be an intensive process that
potentially yields hundreds of risks worthy of further study. Exhibit 6–2 pro-
vides a number of ways to find risks on your project. Select those that seem
most appropriate.
A risk should be written in the format “Condition Consequence.” The
statement “We might be late” isn’t a risk because there are thousands of po-
tential reasons why that might happen, each of which may require a different
answer. The statement “The report may contain errors” is not a risk because
we don’t know the effect those errors might have on project objectives. The
statement “If there are errors in the report that require revision, then the ac-
tivity will take two days longer than planned” is a risk, because we know know
both the cause and the effect that concerns us. The easy way to write risks in
the proper format is to write them as “if…then” statements. The “if ” is the
condition or cause, and the “then” is the effect or consequence. (“Because…
then” works, too.)
Risks can be positive or have mixed potential outcomes. Don’t overlook
opportunities or business risks in risk identification.

xhibit 6–2
Risk Identification
Source of Risk Description and Method
Document Analysis Review all the paperwork associated with the project looking
for risks. There’s a potential risk lurking in every declarative
statement. “We will deliver on July 1” carries the implicit risk
that we may not meet that delivery date.
Assumption Analysis Assumptions are unavoidable, especially in early stages of
the project. Not all assumptions are bad; some promote
safety, such as the assumption that an unknown gun is
loaded. The dangerous assumptions are the ones you don’t
notice. Develop a list of assumptions in the initiating phase
and continue to add to it through the life of the project. Turn
assumptions into facts or falsehoods when possible;
assumptions that can’t be validated are risks.
Work Breakdown Some risks can happen at any time, such as losing a
Structure member of your team to other work. Other risks are confined
to specific work packages. If you’re planning to test your new
widget design, there’s a risk the widget may fail. The widget
can’t fail the test until you begin testing, and after the test is
over, there’s no longer any risk: it passed or it failed. The first
is a non-event; the second is now a problem. Look at each
work package for the risks associated with it.
Network Diagram In addition to studying the WBS, review the network
diagram. If there’s a chance an activity might be two days
late, it’s more meaningful if it’s on the critical path. If it’s not
critical, and there are five days of slack, a two-day delay may
be irrelevant.
Stakeholder Stakeholders are not infrequently sources of project risk. If
Management Plan you have a stakeholder known for changing his or her mind,
and or one who tends to micromanage project details, or one
Communications who needs daily reassurance, those risks will affect the
Management Plan management of your project.
Estimates Estimates, like risks, are future tense. When you’re done,
you can figure out the actual cost and time. Until that point,
there is uncertainty. How reliable is a given estimate? What
is the range of potential variance? Are there root causes or
triggers that would invalidate certain estimates?
Exhibit 6–2 continues on next page.

Exhibit 6–2 continued from previous page.
Procurement Outsourcing can be a highly valuable tool, but it’s not without
Documents risk. Review bids and proposals, check the history of the
company you’re working with, call references if appropriate,
and make sure you understand the contract, especially if it
was prepared by someone else.
Lessons Learned If your organization has done similar projects, review the
lessons learned from those projects. What risks were feared,
which occurred, and how well were they handled?
Checklists Airplane pilots review a checklist before taking off. Checklists
focus on areas where it’s easy to make a mistake or overlook
something and where the consequences of doing so can be
serious. Checklists are enormously valuable, but don’t ever
let a checklist replace the entire risk management process.
Experts In the same way experts are helpful in estimating, they often
have good insights on the risks you may face. You may also
use the Delphi technique if you are surveying multiple
experts and need to avoid groupthink.
Analysis Tools Several commonly used management tools can be helpful in
risk management. A SWOT analysis involves brainstorming
Strengths, Weaknesses, Opportunities, and Threats for a
well-rounded picture of the project. Quality tools such as the
Ishikawa (fishbone) diagram help break down problems into
components, allowing deeper insight into risks.
Organize your risks into a risk register. Add additional information about
each risk as you develop it. Exhibit 6–3 provides a sample format for a risk
register. Use the risk register to organize information about each risk, and to
track risks as the project moves forward. Some risks require far more infor-
mation than the space provided; you can develop those risks in separate doc-
uments, but keep a note on the risk register referencing where the appropriate
information can be found.
You may categorize risks to help in organizing and acting on them. You can
categorize risks according to risk tolerance (financial, legal, political, safety, rep-
utation), impact on objectives (time, cost, scope, quality), or however it makes
most sense to you. Your risk management plan will often define categories you
should use. “Where Found” on the risk register links the risk to some other proj-
ect document, such as WBS, network diagram, requirements lists, etc.
Exercise 6–2 is an opportunity for you to practice risk identification on
our PMO case study project; you will develop further information about each
risk as we move forward.

xhibit 6–3
Sample Risk Register
A risk register is most often organized as a spreadsheet.
Descriptio Category Where Risk

ID Probability Impact Disposition Comments
n of Risk of Risk Found? Rating
Exercise 6–2
Risk Identification
Instructions: For our PMO case study, identify five risks based on the work you’ve done so far, and
write each one in the “condition consequence” format. Try to find at least one opportunity risk or
business risk among them.
1. _________________________________________________________________________
2. _________________________________________________________________________
3. _________________________________________________________________________
4. _________________________________________________________________________
5. _________________________________________________________________________
Performing Qualitative Risk Analysis

Risk identification is only concerned with finding risks, so you should prefer
quantity to quality in that part of the process. However, not all risks are
equally serious, and many risks require deeper understanding in order to
come up with a meaningful response or solution.
Risk analysis is the process of studying our identified risks to understand
their characteristics and classify them appropriately. There are two types of
risk analysis: qualitative risk analysis, which is defined by the PMBOK® Guide as
“the process of prioritizing risks for further analysis or action by assessing and
combining their probability of occurrence and impact.” Quantitative risk analy-

sis is “the process of numerically analyzing the effect of identified risks on

overall project objectives.”
Risk Triage
As a preliminary step before the “assessing and combining their probability
of occurrence and impact,” we must first sort our identified risks into some
action categories. For many—perhaps even most—risks, we will classify them
as minor risks, where no further action is warranted, at least initially. For other
risks, we may find that we are not the proper people to address them, and we
must make sure those risks are reassigned to the appropriate people. A few
risks may require top management attention, and may even call into question
whether the project should continue to move forward. Follow the flowchart
in Exhibit 6–4 to sort risks for qualitative risk analysis.
Probability and Impact Matrix

Notice that impact and probability appear prominently on the triage flowchart
in Exhibit 6–4. Earlier, we mentioned the risk formula P x I. It’s easy to cal-
culate P x I if you have actual data on probability and impact, but as we also
discussed, it’s more frequently the case that you have very little hard data on
which to base a number.
That’s not necessarily a huge problem. You may not need to know that
there is a 74.2% chance of a $123,489.41 impact in order to decide on a proper
course of action. Knowing there is a high probability of a serious impact (or
a minor impact, depending on the size of the project) may be all the informa-
tion you really need to justify your response.
Project managers usually prepare a probability and impact matrix to clas-
sify risks. This matrix should be developed as part of your overall risk man-
agement plan. Exhibit 6–5 provides a sample. In our example, we are using
only three categories for probability and impact. Depending on how much
you know and how much detail you feel you need, you may use more.
Exercise 6–3
Qualitative Risk Analysis
Instructions: For each risk you identified in Exercise 6–2, determine its probability and impact using
the scale provided in Exhibit 6–5, and determine its category on the risk triage flowchart shown in
Exhibit 6–4.
1. _________________________________________________________________________
2. _________________________________________________________________________
3. _________________________________________________________________________
4. _________________________________________________________________________
5. _________________________________________________________________________

xhibit 6–4
Risk Triage Flowchart
Source: Adapted from Project Risk and Cost Analysis by Dobson and Dobson ©2012. Used by permission of the publisher, AMACOM Books, a division
of American Management Association, New York, New York. All rights reserved. www.amacombooks.org

xhibit 6–5
Probability and Impact Matrix
Probability
Impact 1 2 3
1 LOW
2 MEDIUM
3 HIGH
Expanding the Risk Register

Add the risk scores to the risk register. That information, combined with the
risk triage flowchart, helps you sort the risks into categories to handle them
appropriately. Some risks need active planning and management, but you sel-
dom have all the resources you need to tackle them all. These actionable risks
need to be prioritized, or at a minimum sorted into “high, medium, and low.”
The process of qualitative risk analysis means that you have to research
or at least think about risks in detail, and that yields important information.
Study the characteristics of the risk, don’t just sort and score it. What makes
it more or less likely? What circumstances would trigger it? Would it give off
a warning sign before happening?
Understanding each risk will help you select appropriate and cost-effec-
tive risk responses, and give you important insights in how to manage it. That
information, too, needs to be captured in the risk register. Don’t feel confined
by the tiny “comments” space on the spreadsheet: Add your notes, number
them, and put a cross reference in the space.
Overall Project Risk

In addition to scoring individual risks, it’s also useful to create an overall risk
score or assessment for the entire project. That helps customers, sponsors, or
stakeholders make better decisions. Project risk scoring has elements of both
art and science. A project risk score is meaningful only in context: how this
project compares to other projects.
One way to create a project risk score is simply to add up the scores of
the individual risks. If the sum of your risks comes to, say, 465, how does that
compare to other projects? If most projects have cumulative scores of 2,500
to 3,000, we might think of this as a fairly low risk project. If average scores
are 250 to 300, this project is comparatively high risk. Consider the amount
at stake as well. An inexpensive project with a score of 3,000 may still be lower

risk than a costly project with a score of 500, if considered from a larger or-
ganizational perspective.
Low risk projects don’t need tremendously robust risk management plans.
In a high risk situation, however, planning is essential. The “raw” risk score can
often be lowered substantially, which is the ultimate goal of our risk management
process.
Performing Quantitative Risk Analysis

Quantitative risk analysis, as we learned earlier, is “the process of numerically
analyzing the effect of identified risks on overall project objectives.” Quanti-
tative risk analysis uses statistical techniques to understand risks better. As
with qualitative risk analysis, you can measure individual risks and the risk of
the project as a whole.
For many risks, you don’t have enough numerical data, but you may be
surprised. Look at each risk, from high to low, to see whether you can develop
meaningful numbers about probability and impact. (You can also create useful
numbers. If you do the same thing on numerous projects, record what happens
and build your own statistics. Future projects will benefit.)
We’ve already worked with one of the most important project manage-
ment quantitative risk systems: PERT and its successor, the Monte Carlo sim-
ulation. Both approaches are based on risk: will your outcome be closer to
optimistic, pessimistic, or most likely values, and how confident are you of
your answer? Both approaches measure total project risk.
In addition to these two, there are some quantitative risk management
tools commonly used in project management: the calculation of expected mon-
etary value (EMV) and its offspring, the decision tree.
Add quantitative risk results to the risk register.
Expected Monetary Value

Earlier, we discussed business risk, in which both gains and losses are possible.
You’re asked to invest $50,000. Based on past performance of similar invest-
ments, you decide there’s a 30% chance that the investment will pay $1 million
and a 70% chance you’ll lose your entire investment. Should you take the offer?
This problem has both qualitative and quantitative issues. The raw num-
bers ($50,000; $1 million) don’t tell you the whole story. What would losing
$50,000 mean to you? If you’re a wealthy and experienced investor, it might
not be a big deal. If you would have to borrow the money from the local loan
shark, the cost of failure might be $50,000 and some broken legs. What would
a million dollars mean to you? For many, it would be life transforming. For
Bill Gates, it may not be worth the trouble to fill out the paperwork.
On the quantitative side, we can calculate an expected monetary value, or
EMV: What’s the investment worth in net dollars?
To calculate this, you first need to notice that the probabilities (30% and
70%) add up to 100%. That’s not coincidence. The sum of the probabilities
of all potential outcomes always equals 100%. If you roll a six-sided die, the
probability you’ll roll either a one, two, three, four, five, or six is 100%. (Yes,
the die can roll off the table, but then you have to roll it over again.) Armed
with this fact, we can add P x I into the process, as shown in Exhibit 6–6.

xhibit 6–6
Expected Monetary Value
EMV = P1I1 + P2I2 + … + PkIk

Where:
EMV = Expected monetary value
Px = Probability of a given event
Ix = Impact of a given event
Example: The expected monetary investment in which you stand a 30% chance of making $1 mil-
lion and a 70% chance of losing $50,000 = (0.3 x $1,000,000) + (0.7 x -$50,000) = $300,000 +
(-$35,000) = $265,000.
The investment in Exhibit 6–6 has an expected monetary value of

$265,000, but you aren’t going to get $265,000. You’ll get either $1 million or
lose $50,000. The EMV is how much you’d end up with on average if you
made this same investment over and over again, winning and losing according
to the probabilities.
Let’s say you’re asked to invest $200,000. Now, the EMV shrinks to
$156,000 ($300,000 – $140,000). At $500,000, it’s negative ($300,000 – $350,000
= -$50,000), and you definitely want to pass on this investment if you’re not
looking for tax writeoffs.
The EMV is useful in calculating a reasonable contingency allowance for a
project. The contingency allowance pays for small risks that aren’t worth man-
aging and for things you didn’t anticipate. Some areas have a standard con-
tingency allowance: real estate projects often use 10%.
Sensitivity Analysis
How accurate are those estimates of probability and impact? Is the success-
failure ratio really 30-70? How do we know? What about that $1 million pay-
day? It may be certain we lose our investment if it fails, but are we really
certain the payoff will be exactly $1 million?
When people see numbers, they’re often inclined to take them more se-
riously than they deserve. When you’re measuring risk, challenge your as-
sumptions. Sensitivity analysis is the study of how the variation (uncertainty)
in the output of a mathematical model can be apportioned, qualitatively or
quantitatively, to different sources of variation. It involves varying your as-
sumptions and redoing the EMV calculation, as practiced in Exercise 6–4.
Exercise 6–4
EMV Calculations and Sensitivity Analysis
Instructions: In this exercise, we will perform EMV calculations and a sensitivity analysis. The first
line describes the case we’ve been discussing in the text. Each subsequent line involves a different
set of assumptions. Perform an EMV calculation for each case. Notice that cases 5 and 6 involve
an additional case.

Case Pwinning Iwinning Plosing Ilosing Calculation
(0.3 x $1,000,000) +
1 30% $1 million 70% -$50,000
(0.7 x -$50,000) = $265,000
2 10% $1 million 90% -$50,000
3 30% $500,000 70% -$50,000
4 10% $500,000 90% -$50,000
5% $1,000,000
5 70% -$50,000
25% $250,000
5% $500,000
6 85% -$50,000
10% $250,000
How safe is this investment? Why do you think so?
Many times, when you’re asked to provide numbers, those numbers con-
tain assumptions. What will be the interest rate in four years? How much will
the price of raw materials fluctuate in the next three months? Consider con-
ducting a sensitivity analysis on your assumed numbers. If you’re wrong, what
would the consequences be?
Decision Trees
A decision tree compares EMVs side to side, usually graphically. Exhibit 6–7
provides an example.
In this example, the first block on the left is called a decision node : Which
investment? Investment A costs $8,000, and Investment B costs $12,000. Each
investment has three potential outcomes.
• For Investment A, there’s a 25% chance of earning $5,000, a 25% chance
of earning $10,000, and a 50% chance of earning $20,000.
• For Investment B, there’s a 60% chance of getting nothing, a 30% chance
of $20,000, and a 10% chance of $100,000.
Which investment has the better EMV? For Investment A, the first box
shows it costs $8,000, leaving you down $8,000. If we only get $5,000 in re-

xhibit 6–7
Decision Tree
Source: Adapted from Project Risk and Cost Analysis by Dobson and Dobson ©2012. Used by permission of the publisher, AMACOM Books, a division
of American Management Association, New York, New York. All rights reserved. www.amacombooks.org
turns, we’re at -$3,000. Multiply -$3,000 by 25% and you end up with -$750.
Work the next two branches the same way, then add up the answers: -$750 +
$500 + 6,000 = $5,750. That’s the EMV for Investment A, and you write it
just above the decision node.
Now calculate the outcomes for Investment B. Even though there’s a
chance of earning $100,000, the EMV totals only $2,800. Write that below In-
vestment A’s EMV, then label them. The better value, Investment A, is “true,”
and the other path is “false.”
You don’t have to turn your EMV comparisons into a graphic unless
there’s a specific requirement for it. You can simply provide the EMVs side
by side and prepare your recommendation.
Planning Risk Responses

Now that we’ve sorted, analyzed, and prioritized our risks, we need to decide
what to do about them. Exhibit 6–8 summarizes the strategies for responding
to risks, whether they are threats or opportunities. Notice that the responses
for threats and opportunity are paired. Avoiding a negative risk lines up with
exploiting a positive one. Mitigation reduces threats, whereas enhancing in-
creases opportunities. Transferring costs parallels sharing opportunities.

xhibit 6–8
Risk Response Strategies
Threat Opportunity Both
Avoid Exploit Contingent Response
Mitigate Enhance Acceptance
Transfer Share
Avoid
When you avoid a risk, you change the project or the environment so that the
risk can no longer happen, or if it does happen, the project is completely pro-
tected from its effects. If a particular investment could lose a lot of money, we
might decide not to invest. We no longer have that risk of losing money. (We
might, however, be passing up the possibility of gain.) If we’re worried about
hurricanes, we could move away from coastal areas. The hurricanes will still
happen, but we won’t be subject to their effects.
Mitigate
You might not be able to avoid a risk altogether, but you might be able to mit-
igate it. When you mitigate a risk, you make it smaller, lowering probability or
impact. If you drive safely, your risk of being in an accident is lower. The risk
is mitigated, but it’s not avoided. Driving safely lowers the probability, but the
potential impact is unchanged. Modern cars are often designed around “crash
cages” that give greater protection to driver and passenger in case of an acci-
dent. These safety features lower the impact of an accident, but its chance of
happening remains unchanged.
There’s no reason you can’t drive a safe car and drive safely at the same
time, and reduce the probability as well as the impact of an accident. Don’t
feel limited to one solution to a problem. Sometimes a number of small steps
can reduce the risk to acceptable levels.
Transfer
Another response to the potential of an accident is insurance, or paying a com-
pany a premium so they’ll pay in case you get in an accident. This is an ex-
ample of transfer. Transfer doesn’t necessarily change the risk itself, but merely
shifts ownership. My probability of being in an accident isn’t affected by
whether I have insurance. The financial impact is also the same; the only dif-
ference is whose signature is on the check.
In procurement, some contracts are fixed price and others are cost plus.
In a fixed price contract, the seller agrees to accept a price for goods and serv-
ices. The risks belong to the seller. In cost plus, the buyer agrees to cover the
costs of the vendor plus some additional money for profit. The risks now be-
long to the buyer.

There’s more to the story, of course. Fixed price contracts might exclude
certain risks. If a flight is cancelled for mechanical reasons, the airline owes
stranded passengers a hotel room as part of the fixed price of the ticket. If the
reason for cancellation is weather, passengers are on their own. Many terms
and conditions in a contract are about the transfer of particular risks between
buyer and seller.
Harry Truman famously had a sign on his White House desk reading,
“The buck stops here.” “Passing the buck” is another way to transfer risks. Some
decisions rightfully belong to people higher up the food chain, or in different
parts of the organization. Some belong to the customer, and some belong to
regulators or outside parties. Though passing the buck can be a way to shirk
responsibility, some bucks need to be passed so they end up in the proper hands.
Exploit
When you encounter an opportunity, you can exploit it and capture its value. If
your stock goes up in value, you can sell it and pocket the profit (less taxes, of
course). If it turns out you can buy an off-the-shelf product instead of building
it from scratch, you can save the money and time it would have taken to build
it from scratch. If the price of aluminum drops, you can buy extra to cover up-
coming projects.
You can plan for exploitation. If there’s a chance of finding an off-the-
shelf replacement for an expensive and time-consuming development process,
you definitely want to have someone looking to see if it exists.
If you’re going to cash in at some point, decide when that might be.
Should you sell if your stock reaches $40? What price for aluminum would
make bulk purchases worthwhile?
Enhance
If our stock has gone up $5, should we sell? If we think we’re close to the top of
the market, it’s probably a good idea to exploit the gain. If we think the stock
will keep going up another $20, we might want to hold onto it longer. That de-
cision contains risk, of course. What if our estimate of the stock’s target is wrong?
If you look for a new job, you probably want to polish your résumé or
get in touch with your contact list. That improves the probability of getting
that new job. If that updated résumé gets you a better job at a higher salary,
you’ve enhanced the impact.
Share
We don’t have to hog all the benefit of opportunities; we can share them with
others. We learned in kindergarten that sharing is nice. In the world of work,
sharing can also be practical, and we often underestimate its benefits to our-
selves as well as others.
If we’re looking for a job, we might come across an opportunity that’s
completely wrong for us, but might be just the thing for a friend or colleague.
Sharing the information takes little effort, and you’ll usually earn some good-
will in the process. The other person may or may not come across the job of
your dreams in return, but the more people you help, the greater the chances.

As project managers, we have to balance our commitment to the specific

project with a larger organizational perspective. We may discover a new
process that doesn’t benefit our immediate project but pays off somewhere
else. The special glue on Post-it® notes was an accidental byproduct of a failed
project, yet it resulted in 3M’s largest selling product line.
Sharing benefits with customers can win long-term business. When a
consumer products company lowers its costs, it might pass some of the savings
to the customer in the form of lower prices. That expands market share.
Contingent Response
A contingent response is something you’re only going to do if the risk actually
happens (or gives a warning sign that it’s about to). The particular response
can fit into any of the other risk categories: avoid, mitigate, transfer, etc. The
difference is the timing.
In case of a hurricane, we might need to evacuate the coastal areas, but
that disrupts the lives of many people and costs a lot of money. We don’t want
to order an evacuation unless it’s necessary. However, we develop evacuation
plans and procedures to be ready. These are contingency plans, because
they’re only going to go into effect if we actually need them. We don’t want
to wait until the hurricane actually strikes to begin the evacuation, so we have
to develop a trigger, a description of the circumstances that tells us to put those
contingency plans into effect.
How would you determine the trigger? In this case, there are two pieces
of information. The first is how long that evacuation would take. If it would
take two days, then the trigger has to be a minimum of two days before the
arrival of a hurricane. The second piece of information is weather reports.
Where is the hurricane? How fast is it moving? Triggers also carry risks. What
if the hurricane suddenly veers off and we evacuated for nothing? What if it
picks up speed and hits us much sooner than expected?
We often use contingency plans when the cost and difficulty of a risk response
is high. If we have a $2 million risk on our project that would take $1 million to
stop, we’d hate to spend the million if we don’t have to. We also use contingency
plans when the characteristics of a particular risk won’t be apparent until later.
Even though firefighters have a lot of training, they still have to wait until they
get on scene before figuring out exactly how to approach a particular blaze.
Sometimes a contingency plan is used as a backup. We may have miti-
gated a risk by lowering the probability it might happen, but that doesn’t mean
it won’t still happen. If the risk breaks through our first line of defense, we
may want to have a contingency response in hand.
Acceptance
The default strategy for every risk is acceptance: do nothing unless the risk hap-
pens, then deal with it as best we can. If the impact of a risk is very low, it’s often
sensible to accept it. It’s not worth the trouble to mitigate. If a particular risk on
our $2 million project would cost us $50, we shouldn’t care too much about it.
We are forced to accept some risks because there is nothing much we can
do about them. An airplane could crash into our house, but short of an anti-
aircraft gun in the back yard, there isn’t much we could do about it—and the
local zoning board would probably object to the artillery.

Accepting risks doesn’t have to be absolute. One role of a contingency

allowance is to have a pot of money (or extra time in the schedule) to pay for
some of those minor risks we’re accepting.
Residual and Secondary Risk

Another category of risks we may accept is residual risk. Residual risk is what’s
left over after we’ve implemented our risk response. If we drive safely and
carry insurance, we’ve mitigated our risk of accident, but we haven’t elimi-
nated it altogether. What still remains is residual risk.
The goal is to get residual risk down to the level where what’s left can be
safely accepted, although you might not be able to get all the way there. If
residual risk is too high, you can modify your prospective solution or come
up with a different one. As noted earlier, you can add additional risk responses
rather than stop with one.
Secondary risk is new risk created by your proposed solution to the original
risk. Investors sometimes structure complex derivatives as insurance against
risk, but those derivative strategies carry risks of their own. If you start job
hunting, you now have the new risk that your boss might find out. If we evac-
uate the coastal areas, people could be hurt during the move.
You should always examine any proposed risk response for secondary
risk. Sometimes, a risk response can make the situation much worse. If your
response has unacceptable secondary risk, you can modify your prospective
solution, come up with a different one, or add additional risk responses to ad-
dress the secondary risks.
Exercise 6–5
Risk Response Planning
Instructions: For each risk you analyzed in Exercise 6–3, develop a risk response. Explain which
category the risk response falls into as part of your answer. Is there significant residual or second-
ary risk after your proposed response?
1. _________________________________________________________________________
2. _________________________________________________________________________
3. _________________________________________________________________________
4. _________________________________________________________________________
5. _________________________________________________________________________
Implementing Risk Responses

Unless you’re accepting a risk or developing a contingency plan, most risk re-
sponses require some action on your part. That means the best place to im-
plement your risk responses is in the project plan itself. Some activities in

your schedule only exist because of risk. If you plan to test your product, it’s
because there’s a risk it might not meet all its objectives. If there’s no doubt
whatsoever about the outcome, the test is redundant. Prototypes, inspections,
and reviews also address risk. If you have to buy new equipment, you need a
purchasing activity in your schedule to make sure it’s done.
You should still complete the appropriate block in the risk register, even
if all you do is indicate where in the plan you put the risk response. You want
to have a record that the response was acted on, and when you conduct lessons
learned, you’ll want a consolidated risk list to review how effective your over-
all risk process has been, and how it can be strengthened in the future.
QUALITY
The PMBOK® Guide defines quality as “the extent to which the project’s pro-
duct, service, and result satisfies the needs for which it was undertaken.”
Quality, from a management perspective, isn’t an abstract concept of
“goodness,” but something measurable and concrete: the degree to which it
satisfies the needs of the customer and other stakeholders. (Although cus-
tomers are generally the most important stakeholders, they usually aren’t the
only ones who matter.)
Your stakeholders define what quality is, and ultimately judge the extent
to which you have achieved it. Stakeholders don’t always start with a full un-
derstanding of their own wants and needs, and sometimes what they ask you
to do won’t achieve their goals. It’s your responsibility to understand what
they want and need, and to translate those desires and needs into specific ac-
tions and decisions. Sometimes, it’s your responsibility to push back.
Is Quality Scope?
We tend to associate quality with scope, but that’s not always the case. Legitimate
stakeholder needs often include time and cost, not just scope or performance.
A lot of project managers resist the idea that they have to make it “cheap,”
which sounds like the antithesis of quality. But it isn’t. Customers have lots of
needs and wants, but limited amounts of money. If they spend more money
on your project, they have to spend less on something else that they might
need more. And they don’t always find value in extra bells and whistles.
In addition, sometimes when you get to “good enough,” there isn’t much
extra value in “better.” A world-class surgeon can’t really put on a bandage
any better than an EMT. Better to save the world-class surgeon’s time for
more challenging assignments.
Value can change over time. In the Apollo 13 rescue, NASA engineers
had to figure out a way to make a CO2 exchanger out of loose material on the
spacecraft, while the clock was ticking. Solving the problem too late would
have been the same thing as not solving it at all. That’s why quality is usually
portrayed at the center of the triple constraints. It affects all three.

Process Quality and Product Quality

In project management, there are two basic types of quality: process quality, or
how well we do things, and product quality, or the extent to which the project out-
put meets the customer’s wants or needs. Improving process quality mostly comes
from project lessons learned. That’s the part of a project in which we extract its
residual value (lessons, ideas, templates, risk information) so we can put it to use
in other projects or operations. Notice it benefits future projects, seldom our own.
Managing process quality during the project is part of project leadership.
Product quality is the extent to which our project’s “product, process, or
result” (we’ll just say product) meets the needs of our stakeholders (we’ll just
call them customers). Planning product quality in your project mostly comes
through setting requirements. Managing product quality during the project is
done through the processes of quality assurance and quality control.
Process Quality
On May 16, 1924, Bell Telephone Head of Inspection Engineering Dr. Walter
A. Shewhart presented a page-long memorandum to his supervisor that is
considered the beginning of process quality control. Most of our modern quality
management initiatives, from TQM to Six Sigma, can trace their origins back
to that memorandum.
Process quality control, as the name suggests, is about improving the way
in which you do things. In the world of operations and ongoing work, there’s
always room for improvement. That’s called continuous process improvement. In
project management, continuous improvement is about improving the way in
which we do projects. It can’t be about the project itself, which has to end.
Think About It . . . Process Quality
Does your organization use a formal quality management process, such as Six Sigma or TQM?
Have you been trained in it? How effective do you think it is? What aspects of it are applicable to
the project management experience?
Product Quality
Quality gurus universally tell you that you must “design quality in,” rather
than “inspect it in.” Inspection doesn’t add quality; it catches defects before
they get to the customer.
How do you design quality into a project? First, understand what the cus-
tomer wants and needs. Second, prioritize those wants and needs so you can
make the fewest and least harmful tradeoffs. Third, write down the needs in

the most measurable, concrete way you can, prioritize those wants and needs,
and spell them out in a way that lets team members get them done. When
you’ve done all that, you’ve designed quality into the project. In other words,
you “design quality in” through setting requirements: the concrete expectations
of the customers, users, or other key stakeholders.
By the way, quality is not the same thing as grade. Grade describes tech-
nical characteristics such as materials used, number and type of features, or
fitness for particular uses. In our EMT versus world-class surgeon example
above, we would classify the medical skills of the EMT as being of lower grade
than those of the surgeon. The quality of each is a separate consideration: how
well does each person meet the needs of the particular patient? In that sense,
an extremely skilled and conscientious EMT can provide services of much
higher quality than a careless or incompetent surgeon.
Functional and Nonfunctional Requirements

Requirements can be subdivided into two general categories: functional and
nonfunctional.
Functional requirements define some concrete element of the product: how
big it is, how fast it runs, how much it can hold. Good functional requirements
add quality by making sure the product meets the need. Bad functional require-
ments degrade quality. If we do something the customer hates but do it ahead
of schedule and under budget, it’s hard to call that a successful project outcome.
Nonfunctional requirements describe the result. They are often called “-ilities,”
because many of them (though not all) end in “-ility”: for example, usability,
manufacturability, and durability. Let’s take “usability.” Does it need to be “easy
to use?” How easy is “easy?” “Easy” for experts isn’t necessarily easy for novices.
Who are the users? Can we measure “easy?” Could it be “too easy?”
Exercise 6–6
Functional and Nonfunctional Requirements
Instructions: For each requirement, determine if it is functional or nonfunctional in nature.
Risk Type (F or N)
The product will function at an operating temperature of 150° Celsius.
The product will have an elegant user interface.
The product will be safe for unskilled users.
The product will fit inside a 20” x 40” x 60” box.
The product will use only ANSI standard materials.
The product will pass UL inspection.
The product will be lightweight and portable.

Quality Tools and Processes

Many quality tools and processes have been developed for ongoing opera-
tional work but also have applications in project management. Some common
techniques that may be relevant to your project include:
• Cost-Benefit Analysis. Given our earlier observation that cost can be a
factor in the customer’s needs and wants, considering the tradeoffs between
costs and benefits can increase quality. Offering product characteristics that
don’t add value to the customer adds cost but arguably lowers quality.
• Benchmarking. Earlier, we asked, How easy is “easy”? as an example of
defining nonfunctional requirements. One way to answer the question is
benchmarking: comparing our actual or planned projects to some equiva-
lent. If our competitor makes a similar product or offers a similar service,
how easy is ours to use or operate compared to our competitor? If you want
to be the best, all you need to do is to beat the second-best.
• Experiments. What combination of characteristics offers the best net
value? In car design, consumers like a low profile but lots of headroom.
Maximizing one customer’s desire in this case would mean minimizing an-
other. Design of experiments (DOE) is a statistical process that allows you
to alter several variables simultaneously in order to find the optimum bal-
ance.
• Cost of Quality (COQ). One famous book on quality was titled Quality Is
Free (Crosby, 1980). Author Philip Crosby pointed out that although it often
costs money to improve quality, there’s a cost associated with poor quality
as well: inspection, rework, and customer dissatisfaction. In that sense,
spending the cost of poor quality on improving quality is essentially free.
Quality is the drive to improve in all three of the triple con-

straints, and risk is the uncertainty that surrounds our project
environment.
Risk is defined as “an uncertain event or condition that,
if it occurs, has a positive or negative effect on one or more
project objectives such as scope, schedule, cost, and quality.”
Positive risks are known as opportunities, and negative risks are
called threats, or sometimes simply risks. Pure risk is all threat,
whereas business risk combines threat and opportunity in a single choice. All
risks are evaluated using the formula R = P x I, or probability times impact. If
you can pay less than the value of the risk to eliminate the threat (or capture
the opportunity), it’s usually worthwhile, but the opposite is not necessarily
true. Sometimes it is advisable to pay a risk premium, especially when risk tol-
erance in a particular area is low, or to rethink a project if its dangers exceed
the risk threshold.
The steps in risk management are: plan risk management, identify risks, per-
form qualitative risk analysis, perform quantitative risk analysis, plan risk responses,
and control risks. All but the last are part of project planning. There are many
sources to help you identify risks, from documents to assumptions to experi-

ence from previous projects. In risk identification, err on the side of inclusion.
Write risks in the form “condition consequence,” group them by categories
if appropriate, and put them on a risk register.
In qualitative risk analysis, you should perform a risk triage to sort risks
by the type of action required, and use a probability and impact matrix to rank
actionable risks against each other. Consider the overall project risk as an ad-
ditional factor. In quantitative risk analysis, apply statistical tools to important
risks and to the project as a whole to gain a deeper understanding. Quantitative
risk tools include PERT and Monte Carlo simulations, expected monetary value
(EMV), and decision trees. When numbers are uncertain, sensitivity analysis can
help tell how useful those numbers are.
Beginning with your highest priority risks, develop appropriate risk re-
sponses. For threats, you can consider avoidance, mitigation, and transfer. For op-
portunities, you can consider exploitation, enhancement, or sharing. The strategies
of contingent response and acceptance work for both threats and opportunities.
Consider residual risk and secondary risk in evaluating your responses. Imple-
ment risk responses (except for contingent) in your overall project manage-
ment plan.
Quality is “the extent to which the project’s product, service, and result
satisfies the needs for which it was undertaken.” To manage quality, you must
first establish concrete measurements based on the needs and wishes of cus-
tomers and other stakeholders. Quality isn’t limited to scope; in some cases
time and cost are major quality factors.
There are two basic types of quality: process quality, or how well we do
things, and product quality, or the extent to which the project output meets the
customer’s wants or needs. Improving process quality mostly comes from project
lessons learned. Managing process quality during the project is part of project
leadership.
Planning product quality in your project mostly comes through setting re-
quirements, both functional and nonfunctional. Managing product quality during
the project is done through the processes of quality assurance and quality control.
Numerous tools exist to help manage project quality, including cost-benefit
analysis, benchmarking, experiments, and the consideration of cost of quality.

Review Questions
1. Which of the following is a correctly written risk? 1. (c)

(a) There is a 75% chance that we will be late.
(b) Our mainframe is old and unreliable.
(c) If the widget fails to pass the test, our schedule will be set
back by one month.
(d) We have been told by the CEO that all projects must come
in under budget.
2. If a particular risk has a 25% chance of costing $20,000 and a 75% 2. (a)
chance of earning $10,000, what is the value of that risk?
(a) $2,500
(b) $12,500
(c) -$2,500
(d) -$5,000
SOLUTION: R = (0.25 * -$20,000) + (0.75 * $10,000) = (-$5,000 + $7,500) = $2,500
3. The extent to which the project’s product, service, and result satisfies 3. (c)
the needs for which it was undertaken is known as:
(a) process quality.
(b) cost of quality.
(c) product quality.
(d) the “-ilities.”
4. What is a business risk? 4. (a)

(a) A risk combining threat and opportunity
(b) Something that could go wrong and affect our overall business
(c) Another term for “pure risk”
(d) Leftover risk after our solution has been applied
5. There is a risk that our vendor will be late, and we are responding 5. (c)
to that risk by adding a penalty clause to the contract with the vendor.
What risk response strategy are we using?
(a) Avoid
(b) Mitigate
(c) Transfer
(d) Accept

Transition to Execution
7
Learning Objectives
• List the activities that occur in the transition
from project planning to project execution.
• Give at least three reasons why getting stake-
holder plan approval is important.
• Establish a performance measurement base-
line (PMB) for a project.
• Describe the process of acquiring, develop-
ing, launching, and managing a project team.
• Design a change management system for
your project.
• Explain the eight steps of an effective problem-
solving process.

Reading 45 minutes

FROM PLAN TO WORK

Project management books and programs focus primarily on planning, and
give short shrift to execution. There are good reasons for this. An IT project,
a construction project, or a project to write a new policy document have some
things in common. They all have a beginning and an end, specific deliverables
and work packages that must be accomplished, resources to expend, and stake-
holders to please. The basic elements of planning apply to all of them. When
it comes to execution, however, these projects diverge, and there’s less to say
from an overall project management perspective.
In this chapter, we’ll talk about the transition from planning to execution.
We must get approval for the plan, establish a performance measurement baseline
(PMB), acquire any resources we need that we don’t already have, build our
team, and lead that team to perform the work.
Projects change as they move forward. Sometimes the change is driven
from within the project: we discovered our planned approach didn’t work and
must now try a different avenue, or we uncovered a surprise that affects how
we move forward. Other times, change comes from stakeholders, either be-
cause their needs have changed or because they’ve simply changed their
minds. To make sure those changes are handled properly, requires a change
management system.
Although much of risk monitoring and control properly belongs in chap-
ter 8 next chapter, along with other monitoring and control responsibilities,
project execution includes deciding when and how to execute contingency plans,
corrective actions, and workarounds.
PLAN APPROVAL
Get your plan approved by key stakeholders to avoid potential miscommuni-
cation about objectives and deliverables, help stakeholders understand the
costs and risks associated with the project, and ensure that you and your stake-
holders are in alignment.
The two methods of getting plan approval are to provide a written plan
and to conduct a briefing or presentation—or both. Make sure you commu-
nicate the plan in ways your audience can understand. Not all stakeholders
are necessarily familiar with project management, and a bewildering array of
network diagrams and PERT calculations can confuse rather than illuminate.
Depending on the urgency and complexity of the project, give stakehold-
ers some time to review plans in as much depth as they choose. Don’t be sur-
prised if you have to go back and redraft sections of the plan as a result of
feedback. The more sensitive and expensive the project, the more challenges
you should expect to get. If your plan and approach is challenged or ques-
tioned, keep an open mind. It’s cheaper and easier to resolve issues in planning
than to find out after the fact that what you did (brilliantly, on time, and under
budget) turns out not to be what they really wanted. Always confirm plan ap-
proval in writing.

TRANSITION TO EXECUTION 125
Plan approval can be revoked or modified, whether based on issues within

the project or from outside. If a project should be cancelled for any reason,
you still need to do a project closeout, covered in Chapter 9.
PERFORMANCE MEASUREMENT BASELINE

The performance measurement baseline (PMB) is the summation of the plan. It’s
the metric that will show project status and reveal any discrepancies. The PMB
must cover all the triple constraints: are we on schedule, are we on budget, and
are we getting the work done? Although it’s technically not part of the plan, it
should be presented along with the plan and approved by stakeholders.
The PMB only changes in extraordinary circumstances. You must re-
baseline the project if major change orders dramatically affect time, cost, or
scope. You may also rebaseline if problems on your project force you to de-
velop a new direction to achieve your goals. In both cases, the purpose of re-
baselining isn’t to hide the original plan (sometimes it still remains on the
chart) but to make new performance data meaningful.
Schedule
A tracking Gantt chart can serve as a schedule baseline. In Microsoft Project®,
there’s a function to “Set Schedule,” after which the tracking Gantt option
appears. (Similar options are available in all but the most basic project man-
agement software.) If you can read an ordinary Gantt chart, a tracking Gantt
is easy. Instead of one bar representing an activity, you now have two. The
first bar represents the schedule. Underneath it, a second bar represents the
actual start, finish, and duration of completed activities. For activities not yet
started, the tracking Gantt shows when they will start and finish based on
what’s happened to early activities.
Exhibit 7–1 takes the Gantt chart from Exhibit 3–13 and turns it into a
tracking Gantt. The gray bars represent the original schedule, the black bars
represent actual performance, and the striped bars are a forecast based on re-
sults to date. The dotted line represents where we are in the project: the end
of Week 24.
You’ll notice that Task B finished two weeks ahead of schedule, and Task
C finished one week behind schedule. Task D, which was dependent on both,
still started two weeks early because only Task B was critical. Task E, depend-
ent on Task C, started and finished a week late.
Notice that Task D is in progress as of Week 24. We know when it started,
but we can only forecast when it will finish. That’s why the bar changes from
solid black to striped. Assuming Task D takes as much time as scheduled, it
will finish two weeks early. It’s on the critical path, which means all remaining
tasks are expected to start early, and we forecast that the project will end two
weeks ahead of schedule. But that’s not the final word. If we encounter prob-
lems in the second half of Task D or in subsequent tasks, we could consume
those two weeks and more. Still, it’s good news that as of right now we are
ahead of schedule.

Exercise 7–1
Analyzing a Tracking Gantt Chart
Instructions: You have just completed the seventh week of a twelve-week project. Complete the
tracking Gantt chart assuming that remaining tasks will take the planned amount of time. Do you
forecast that the project will end up on schedule, ahead of schedule, or behind schedule? By how
much?
TRACKING GANTT CHART

Now
Task Dur. Pred. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Task A 0d —
Task B 15d A
Task C 11d A
Task D 21d B,C
Task E 9d C
Task F 8d D
Task G 12d D,E
Task H 2d F,G
KEY
Schedule
Actual
Forecast
Scope Verification
The tracking Gantt chart tells us about the schedule, but it doesn’t indicate
what has been done. The process of scope verification involves whatever steps
are necessary to ensure that the work is done and done in line with require-
ments. Each work package creates some sort of deliverable, whether it’s a final
deliverable to be handed to the customer, or an interim deliverable that will
support another activity or work package within the project.
You can use the WBS as a tool to manage scope verification. Depending
on the level of work maturity and the difficulty or sensitivity of the work, you
must decide how carefully you need to check that the work is being done. For
some work packages, the word of the person you assign may be fully satisfac-
tory. In other cases, you may need to perform in-depth analysis and inspection.
If the output requires full-blown testing, it’s usually smarter to make the test
a separate activity or work package.
Cost Baseline
Different projects and organizations require different ways of tracking project
costs. You may need to review reports from the financial office to classify all
project expenses against specific accounting categories, or prepare detailed

xhibit 7–1
Tracking Gantt Chart
TRACKING GANTT CHART

Now
Task Dur. Pred. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
Task A 0d —
Task B 15d A
Task C 11d A
Task D 21d B,C
Task E 9d C
Task F 8d D
Task G 12d D,E
Task H 2d F,G
KEY
Schedule
Actual
Forecast
budget vs. actual spreadsheets. However, the best way to track a cost baseline
is with an “s-curve” chart showing cumulative sunk costs to date, as shown in
Exhibit 7–2.
This baseline describes a project that has a budgeted cost of $25,000 and
will take place over twelve weeks. As with the tracking Gantt chart, you can
add a second line representing the actual money expended to date as the fig-
ures come in.
As we’ll learn in the discussion of the earned value method in Chapter 8,
you can use the cost baseline as a PMB for all three constraints. We spend the
money in the plan to accomplish specific elements of work, so the money
spent to date parallels the work accomplished to date. We spend the money
over time, so the money spent to date also tracks whether we’re accomplishing
the work according to the schedule.
The cost baseline can’t distinguish between critical and noncritical ac-
tivities, and it can’t indicate how well the work was completed, but it’s a good
proxy for showing overall performance.
TEAMS AND OTHER RESOURCES

Who will be on the project team? What do you have to do to get hold of the
money? How will you acquire any necessary equipment, tools, or other re-
sources? As part of the transition from planning to execution, you must acquire
any people or resources you don’t already have. Normally, the authority to
do so should be spelled out either in the project charter or as part of obtaining

xhibit 7–2
Cost Baseline
$30.000
$25,000
$20.000
$15,000
$10,000
$5,000
$0
1 2 3 4 5 6 7 8 9 10 11 12
plan approval. In some cases, you may need to negotiate with stakeholders or
resource owners to acquire what you need.
Acquiring the Team

You may have been assigned a project team at the outset, but negotiation may
be possible. Your responsibility assignment matrix (RAM) will reveal any gaps
in skill or knowledge that may exist, and when your schedule is loaded, it will
reveal cases in which the work you need to do exceeds the resources available
with which to do it.
Depending on the gaps, you may need additional full-time people for
the duration of the project, full-time people for phases or elements of the
project, or part-time people. In addition to existing staff, you can consider
hiring permanently (if you’ll have a long-term need for the skill), arranging
training or coaching to expand the skills of existing staff), hiring consultants
or part-timers (especially for cases in which you need highly specialized skills
for short durations), or requiring overtime.
If specific team members have a difficult time working together, you may
be able to swap them for more congenial and cooperative replacements. If

your team has people in high demand, don’t be surprised if other projects or
operations take them away. That’s a common risk, and should be addressed in
your risk management plan.
Team Development
Project managers often aren’t the permanent supervisors of their team mem-
bers. Many team members have regular positions and official supervisors. As
a result, you don’t have the same type and level of power. That’s not neces-
sarily harmful. One of the simplest and best definitions of a leader is “someone
who gets followed.” We follow people for all sorts of reasons, ranging from at-
titude to skill to persuasiveness to rewards. The importance of official super-
visory status may be less than you think.
The subject of team building has filled hundreds of books, and a full dis-
cussion is far beyond the scope of this volume. The AMACOM Self-Study
program includes a course called Making Teams Work, along with numerous
other courses in leadership and supervision, and there are hundreds of courses
and workshops in team building offered around the world. Your success as a
project manager usually rests on the backs of your team members, so develop-
ing a high performance team is a core project management need. That doesn’t
merely help you succeed on today’s project, but builds a reputation that will
help you manage larger and more important projects in the future.
Think About It . . . Teams
How have you learned about teamwork? Have you had formal training or only experience—positive
or negative? Are there resources available to you in your position that would improve teamwork
on your projects? What will you do to advance your knowledge and skill?
Kickoff Meeting
Many project management authorities recommend a kickoff meeting as a way
to get a project started. The kickoff meeting should include team members,
project sponsors, customers, and other important stakeholders. Review the
plan, identify and share the roles that each participant will review, and start
the project with a burst of high energy.
Work Management
Because team members on a project must perform certain activities in a cer-
tain sequence, on more complex projects it becomes all too easy to overlook

work or forget important details. Always keep some sort of record of who has
been assigned to what activity as a fundamental part of keeping track of proj-
ect progress.
If the project is particularly large or complicated, details are critical, and
you have a large team, consider using a work management form, often called a WBS
Dictionary. An example of this kind of form is shown in Exhibit 7–3, but feel free
to modify it to suit your situation. Complete this form (or have the appropriate
team member complete it) and make two copies: one for the team member and
one for you to serve as an overall control log. Keep status information on your
copy of the form. When the activity is complete, the team member signs and
dates the form and gives it to you as a record of work complete.
CHANGE MANAGEMENT
Change is the only certainty on projects. The needs may change. People may
change. Technology may change. What we discover as we do the project may
surprise us.
Change by itself is normal and natural, and must be accommodated in
your project. However, when change is not managed effectively, the result is
scope creep, which we defined earlier as unplanned and unmanaged change.
This can kill a project—an old joke describes a project disaster as the moment
in which the speed of change starts to exceed the speed of progress.
The alternative to scope creep is to establish and maintain an effective
change management system.
Fundamentals of Change Management

The purpose of a change management system is to ensure that changes are
documented, analyzed for impact on the project, approved (or disapproved)
by the appropriate person(s), and implemented into the project plan.
Establish a clear change management policy in writing and make sure all
stakeholders know about the process. It shouldn’t be your goal to make
changes difficult, but it is important that a process be followed. The person
wanting the change should submit a change request in writing. The change re-
quest explains the change, may provide a rationale for the change, and gives
any supporting information. The project manager enters every change request
into a change log.
Every change needs to be analyzed, and that’s usually the job of the proj-
ect manager, who’s often in the best position to do so. What new activities will
need to be performed? Which planned activities will need to be changed or
dropped? Will other work on the project be affected? What will the change
cost? Will it take additional time?
A change management policy needs to specify who approves changes. It
could be you as project manager, the project sponsor, or the customer. Some-
times, the level of approval depends on the impact of the change: if it’s minor,
the project manager may simply approve it, but if it’s going to have a big im-
pact on the rest of the project, higher levels of the organization may want to
have a say.

xhibit 7–3
Work Management Form
The completed version of this form is based on the “Prepare Index” activity from the FDA project
shown in Exhibit 3–5. A blank copy is provided for your use.
Exhibit 7–3 continues on next page.

Exhibit 7–3 continued from previous page.

A change can be approved, rejected, conditionally approved, or deferred.

If a change is approved, note it in the change log, notify the requester, and
update the project plan. If a change is rejected, note it in the change log and
notify the requester.
A change can be conditionally approved. For example, you might make
the change if the requester will pay for it. A change can also be deferred, es-
pecially if you need additional information or more analysis is required. Keep
the requester informed and keep the change log updated.
Change Control Boards and Configuration Management

In large engineering and IT projects, it’s often the case that a seemingly harm-
less change can have catastrophic ripple effects elsewhere in the project. If
you want to change a component on an airplane, for example, there are several
layers of FAA approval that you need before you can go ahead.
Configuration management is an advanced type of change management used
in this kind of project. Configuration changes, no matter who requests them,
go through intensive review before they can be approved. Along with config-
uration management, such systems often establish a change control board to issue
final approval. The project manager may chair the change control board, or
serve as its secretary.
Think About It . . . Change Management
Does your organization, work group, or current project have a formal change management plan?
If so, is it proportionate and effective? Do people follow the process?
SOLVING PROBLEMS
As we discussed in Chapter 6, risks are future tense, but problems are in the
present. No matter how well you plan, sometimes threats turn into problems.
Three types of problem solving activities belong in project execution: imple-
menting contingency plans, corrective actions, and workarounds.

Contingency Plans
For many of our risks, we modified the project plan to include our risk re-
sponse. For some risks, we chose to develop contingency plans: things we will
do if and only if the issue actually occurs or sends a warning signal that it is
about to occur. Some contingency plans exist because we’re really hoping to
avoid a large expenditure to address a rare event—but if that event happens,
we’re stuck with the bill.
Every contingency plan must have a trigger, which is an event that tells
us that we should put that plan into operation. As part of project execution,
you need to watch for those triggers, and when appropriate, launch contin-
gency plans.
By their nature, contingency plans are effectively project changes. They
consume resources and time, and may alter scope. Though you don’t neces-
sarily have to enter these into the change log, you may need to rebaseline
parts of the project once the emergency has passed.
Evaluate the performance of the contingency plan. Is it solving the issue
appropriately? Now that you see it in the real world, could it be improved?
Could we have addressed the underlying risk more effectively?
Corrective Actions and Workarounds

Risk management is proactive: we plan and act in advance of the actual need.
We implement preventive actions. Problem solving is reactive: we deal with
the problem at hand with the tools we have available. We develop and imple-
ment corrective actions and workarounds. There are many strategies for effective
problem solving. Depending on the subject matter of your project, the type
of problem, and its importance, consider the steps presented in Exhibit 7– 4.
xhibit 7–4
Problem Solving Strategy
1. Define the problem.

2. Identify the underlying cause or issue.
3. Brainstorm multiple solutions.
4. Decide on the best solution.
5. Plan how the solution will be implemented.
6. Verify that the solution has been effective, or repeat if not.
7. Document the issue and response for lessons learned review.
8. Recognize contributors to solving the problem.

Exercise 7–2
Problem Solving
Instructions: You experience the following problems on the PMO project. For each:
• Identify at least two different potential solutions for each problem.

• Should these potential problems have been on your risk list? What could you have done differ-
ently?
• Can you fix this problem or only mitigate it? If you can only mitigate it, what parts of the problem
would remain?
1. The consultant you were planning to hire has problems and cannot do the job. You hired the
consultant five weeks before the engagement was due to begin, and two weeks later the con-
sultant had a medical problem and can no longer keep the engagement. It will take five more
weeks under normal conditions to get someone new, affecting all activities that use the con-
sultant.
2. A story appeared in the Wall Street Journal criticizing cost overruns and delays in one of your
larger projects. You are still a month away from being able to launch the PMO.
3. Your project sponsor is the deputy to the Chief Information Officer, a responsibility delegated
by the CEO. Your sponsor has been particularly supportive in dealing with skeptical managers,
keeping a lot of pressure off your project. Two months into the project, the deputy suddenly re-
signs to take a better job elsewhere.
The transition from planning to project execution is an im-

portant step in every project. Stakeholder approval avoids po-
tential miscommunication about objectives and deliverables,
helps stakeholders understand the costs and risks associated
with the project, and ensures that you and your stakeholders
are in alignment.
A performance measurement baseline (PMB) summa-
rizes the plan and provides a framework for showing any discrepancies be-
tween planned and actual performance. A PMB may include a tracking Gantt
chart, a scope verification process, and a cost baseline. Of the three, the cost
baseline is particularly important, because it can serve as a proxy for baselines
in all three triple constraint categories. A baseline should not be modified un-
less circumstances (major changes or other issues) render the original baseline
meaningless.
Acquiring, building, motivating, and leading the project team is the major
role of the project manager in executing the project. Good project managers
continually build their skills in this crucial area. Review the responsibility as-
signment matrix to make sure you have the necessary skills on your team and
recruit as necessary, either full or part time. Organize a kickoff meeting for
the project and implement a work management and control system if you
have to oversee a large number of people and activities.

Change is an inevitable part of projects. A formal change management

process helps avoid “scope creep.” The purpose of a change management sys-
tem is to ensure that changes are documented, analyzed for impact on the
project, approved (or disapproved) by the appropriate person(s), and imple-
mented into the project plan. For certain highly complex projects, you might
want to implement a change control board or configuration management.
Risk management is designed to identify and resolve certain issues long
before they happen, but problems inevitably arise. Develop problem-solving
skills in yourself and others. Monitor your project environment for early issue
detection and to make sure that any contingency plan triggers are seen on a
timely basis.

Review Questions
1. Which baseline can serve as a PMB for the entire project? 1. (c)
(a) Tracking Gantt chart
(b) Scope verification system
(c) Cost baseline
(d) Responsibility assignment matrix (RAM)
2. What is the alternative to scope creep on projects? 2. (a)

(a) Change management system
(b) Scope verification system
(c) Performance measurement baseline (PMB)
(d) Tracking Gantt chart
3. Which of these is a reason to seek stakeholder plan approval? 3. (a)

(a) To avoid potential miscommunications about objectives and
deliverables
(b) To make sure stakeholders accept full responsibility if things go wrong
(c) To gain preliminary information about stakeholder needs and issues
(d) To establish the performance measurement baseline (PMB)
4. To ensure that you keep track of who has been assigned to what 4. (a)
work activity, you may use a:
(a) work management form.
(b) tracking Gantt chart.
(c) configuration management system.
(d) performance measurement baseline.
5. What is a corrective action? 5. (d)

(a) A response incorporated into your risk management plan
(b) The situation that tells you to implement a contingency plan
(c) A reserve of time or money to address surprises
(d) A response to a problem that occurs on your project

Controlling Time, Cost,
8
and Scope
Learning Objectives
• Identify the six questions to ask when plan-
ning for project monitoring and control.
• Explain three different methods for obtaining
project status information.
• Describe the options for reporting project
status.
• Establish a risk monitoring and control sys-
tem and explain when to update and modify
your risk management plan.
• Define quality assurance and quality control
and list ways to implement these on your
projects.
• Define earned value management (EVM) and
explain how to determine BAC, PV, AC, EV,
SV, CV, SPI, CPI, and EAC.
• Explain the importance of managing the
project plan and baseline.

Reading 1 hour

PLANNING MONITORING AND CONTROL

Monitoring and controlling your project, like most other aspects of project
management, requires planning. Consider the following questions:
• How will you collect data about actual project status?
• What tools will you use to analyze those data?
• What format will you use to prepare project reports and updates? How will
you present that information?
• What is the threshold for problems that require you to inform project spon-
sors and customers?
• How will you manage and allocate any contingency allowance of time or
money?
• If your risk plan includes contingent responses, how will you know when
they should be implemented?
As with most project decisions, you don’t want to make this kind of choice
on the fly. In this chapter, you’ll learn a number of tools and techniques for
project monitoring and control so that you can make effective choices when
planning your next project.
You may find some choices have been made for you. Your organization
may have standard forms or report formats. There may be predetermined
thresholds for reporting project issues. In many cases, however, these decisions
will be yours as project manager.
Because monitoring and control is so important, you should be prepared
to allocate resources—including a substantial amount of your own time—to
this work. Because resources are usually in short supply, you don’t want to
overdo it. Be careful to select techniques and tools that add value and improve
your ability to manage the project.
Think About It . . . Monitoring and Control
What are some ways you currently monitor and control work on your projects? Do those methods
work well for you? How could they be improved?
MONITORING PROJECT STATUS

The three basic ways to gather information on project status are meetings, re-
ports, and inspections. You usually use all three techniques.

CONTROLLING TIME, COST, AND SCOPE 141
Status Reports
Members of your project team prepare status reports on their activities, and
you provide status reports on the overall project to appropriate stakeholders.
Which stakeholders and what information is decided when you prepare your
stakeholder management and communications management plans.
When the team is small and the project is not terribly complicated, it
may not be the best use of time to prepare a status report, but as team size
and complexity grows, it becomes harder for the project manager to keep all
the information in his or her mind.
Exhibit 8–1 shows a sample status report template for team members to
report status to you. “Stoplight Status” is green if everything is on track, yellow
if there is a minor variance, and red if there is a serious problem.
Status Meetings
There are several schools of thought on how to run a good status meeting.
One approach is to keep it to an absolute minimum: have each team member
xhibit 8–1
Team Member Status Report Form
Project Name Date Stoplight Status

Status Report
Activity Name/WBS Code
Planned Start Actual Start Planned Finish Actual Finish Variance
Planned Total Cost Expenditures to Date Estimate to Complete Current Variance Total Variance
Work Done in Last Reporting Period/Milestones Accomplished
Issues and Resolution
Risks and Anticipated Issues in Next Reporting Period
Name Date Submitted

summarize his or her own status, and then adjourn. (Some people even rec-
ommend that you should not allow chairs as a way to keep the meeting short.)
Of course, often issues crop up in status meetings that require fuller attention,
but not everybody needs to be part of every discussion. Set separate meetings
following the status meeting involving just the people who need to be there,
and let everybody else get back to work.
Another approach takes into account that the team status meeting may
be the only structured opportunity to bring everyone into the same room. Use
the meeting not merely to get updated status info (a form may accomplish
just as much) but as an opportunity to build trust, air issues, and recognize
achievements. Such team meetings can build morale.
Many project teams today are not co-located: team members may be in
different states, time zones, or countries. The travel costs to bring everybody
together are so high that it’s not feasible to have regular all-hands get-togethers.
If possible, do bring everyone together for the kickoff meeting and for the les-
sons learned workshop, but that’s usually enough. Status meetings can be done
through teleconference or videoconference. That limits the role of team build-
ing, but you still have the opportunity to acknowledge and praise good work.
No matter which approach is right for you, always practice good meeting
rules: distribute an agenda, make sure that you and team members are pre-
pared with the right information, control interruptions and sidebars, and be
mindful that if a meeting runs too long (over 40 minutes or so), people start
to lose focus and effectiveness drops. If you need more total meeting time to
get through all the issues, consider having more frequent, shorter, and more
focused meetings instead of a single marathon session.
Think About It . . . Meeting Culture
What grade (A, B, C, D, F) would you give to your organization’s meeting culture? What works and
what doesn’t? How could you improve the effectiveness of meetings on your project?
Inspections and Reviews

Status reports normally focus on schedule, budget, and deliverables. Status
meetings tend to focus on issues and problems. Neither approach gets into
the details of the work itself. For that, you need to inspect and review the
work product, whether it’s work in progress or work completed.
You can personally inspect the work, or you can establish a peer review
system in which people review each other’s work. In some cases, you may
want to bring in outside specialists to conduct a technical review.

When you perform inspections and reviews, it’s important not to let it
become an inquisition. When people think the goal is to find an opportunity
to criticize, they become risk averse and may go so far as to hide bad news.
Establish clear criteria up front through the requirements process so that team
members can measure their own progress and be in control of results. Avoid
surprise inspections. When deficiencies are found, focus on ways to help the
team member make necessary corrections rather than spend excessive time
figuring out what went wrong.
If the final product must undergo testing, it’s important to test compo-
nents at earlier stages of the project. If each component is right, it’s less likely
the final product will fail, and it’s easier to pinpoint problems if they should
be found in the testing process. Document all test and inspection results as
part of the overall project record.
Frequency of Reviews
It doesn’t make sense to have a status meeting or require a status report if
nothing much has happened since the last one. The frequency of reports has
to be based on the speed of change within the project. If you measure activity
duration in weeks, have a weekly meeting. If you measure it in months, have
a monthly meeting. If you measure it in hours, you may need to meet daily.
The tempo of a project often accelerates as it moves through the project
life cycle. In preliminary stages, activities could last a month or more, espe-
cially if the project involves a long lead time. As the project picks up speed,
you may start to measure activities in weeks. When you reach crunch time,
you might measure in days. In a rocket launch, the last project activities are
measured in seconds: 10-9-8-7-6-5-4-3-2-1. For each of those final ten sec-
onds, there are specific defined activities taking place, and should those ac-
tivities not produce green lights on the board, the launch will be stopped.
The information needs of stakeholders often influence the status update
timetable. If the customer and project sponsor want a monthly report, you
might schedule brief updates weekly and have an all-hands staff meeting once
a month, a few days before the report is due.
Decide on your review cycle as part of planning, and make sure your
team members know what is expected of them in the process.
Don’t be constrained by a regular meeting schedule. If nothing much is
happening in a particular week, you might choose to skip the status meeting.
If, on the other hand, you’re dealing with major issues or changes, you may
want to put additional emergency meetings on the schedule.
REPORTING PROJECT STATUS

The basic way to report project status to stakeholders is through an overall
project status report. Exhibit 8–2 shows a project status report template that
you can use to send information to key stakeholders.
For major project milestones on large projects, you might need to prepare
a briefing, complete with PowerPoint slides and handouts. You may even need
a “dog and pony show,” in which you bring key stakeholders to the project site

xhibit 8–2
Project Status Report
Project Name
Prepared By: Date: Reporting Period:

[mm/dd/yy] to [mm/dd/yy]
Project Overall Status:
Project Summary:
Work Performed During Last Period

Work Packages/
Deliverables Due Date % Completed Schedule Status
•
Work Scheduled for Next Period

Work Packages/
Deliverables Due Date % Completed Deliverable Status
•
Project Risk Management Status

Risk Risk Risk
Risk and Description Chance Impact Priority Change from Last Review
•
Project Issue Management Status

Project Target Issue
Issue and Description Impact Due Date Status Issue Resolution
•
Change Orders
Change Requests Requester Disposition Impact Summary
•
Project Issue Management Status

Project Target Issue
Issue and Description Impact Due Date Status Issue Resolution
•
Additional Information

to provide demonstrations, briefings, a Q&A opportunity—and refreshments.

Finding out stakeholder needs and expectations is part of your stake-
holder and communications management plan. As with internal status report-
ing, make sure team members know what to expect, when to expect it, and
what they are required to contribute to the process.
No matter what sort of schedule you set forth, you may need additional
special meetings if major project issues arise.
RISK MONITORING AND CONTROL

As we discussed, most risk responses should be made part of the overall project
plan. Contingent responses, by their very nature, must be kept separate.
However, just because you came up with a risk response doesn’t mean it
will necessarily work as advertised, and just because you performed an in-
depth review of potential risks doesn’t mean you caught them all, or that new
surprises can’t crop up at any time.
That’s why you need to track identified risks through the project and
measure how well your intended solution is working. Just because a risk hasn’t
happened doesn’t mean your solution has necessarily worked; some risk events
don’t happen completely on their own. The level of residual risk that you
identified may turn out to be higher or lower than you expected, and second-
ary risks may be more serious and far reaching than you originally imagined.
On top of that, the project environment doesn’t stay still. Change orders
normally bring with them new risks. Other organizational developments,
events in the real world, and unexpected side effects of project activities can
also be a source of new risk.
Make sure that risk is a discussion item at every status meeting and a cat-
egory on every status report. Depending on the level and nature of risks faced
by your project, you may want to have specific risk management meetings at
different stages of the project life cycle.
New Risk Cycle

Even though the previous risk steps (identification, analysis, and response) are
considered part of the planning process, you normally need to perform the entire
process again as the risk environment changes. Add new risks to the risk register,
perform qualitative and quantitative risk analysis as appropriate, develop appro-
priate risk responses, and integrate those responses into the project plan.
Risk Reassessment
In our risk triage process, we put aside a number of risks because their impact
or probability was too low, or the solution disproportionately expensive. For
risks we did address, we developed risk responses and contingency plans.
Characteristics of these risks may change during the project. Depending on
the overall level of risk, the amount at stake, and the changes you’ve experi-
enced, you may find it desirable to hold one or more special risk meetings in
which the entire risk register is reassessed based on the current situation.

Risk Audits
Both during the project and in lessons learned, evaluate the effectiveness of
your risk responses. If a risk was identified in a specific activity, the status re-
port should list whether the risk event occurred and how well the solution
worked.
Managing Reserves
One response to risks that we addressed earlier is to have a contingency re-
serve, which can consist of extra resources (financial and otherwise), extra
time (a schedule with a planned finish date in advance of the actual deadline),
or optional scope (desirable but nonmandatory project elements). During the
project, you’ll normally need to draw down some part of that reserve to ad-
dress those events.
MONITORING AND CONTROLLING

QUALITY
In Chapter 6, we learned that there are two basic types of quality: process qual-
ity, or how well things are done, and product quality, or the extent to which the
project output meets the customer’s wants or needs. We improve process qual-
ity through project lessons learned, and we manage it in the way we lead and
manage the project. We improve product quality by setting the right require-
ments and managing it by making sure those requirements are met.
Quality Assurance
Quality assurance is the name given to the activities involving the management
of process quality. In technical quality management, we often use the tools of
statistical process control (SPC) to track quality data and monitor variances
in our processes. Common quality assurance tools include:
• Process maps. A process map is a flowchart of the way in which we go about
certain work. A process map can help identify whether a process is need-
lessly complicated, or if the same work is handed back and forth multiple
times.
• Checksheets. Checksheets are forms for collecting data in an organized fash-
ion. For example, if we examine a product for defects, we can tally the cat-
egory of each defect in order to detect any patterns or common issues.
• Pareto diagrams. Pareto diagrams organize data in a vertical bar chart to make
it easy to distinguish the “vital few” sources that produce most threats or
opportunities.
• Control charts. Control charts keep track of whether a process is stable or
shows great variation.
These tools are common in such quality systems as total quality man-
agement (TQM) and Six Sigma. Appendix D: Additional Resources lists some
sources for additional information on quality management.

Quality Control
Quality control describes the various ways to ensure product quality. Tradition-
ally, quality control primarily meant inspection and testing, but the definition
has widened over time.
Simply saying that you plan to inspect or test a particular product isn’t
very helpful. Part of planning involves determining how you will inspect and
test. What are the most important requirements, or the requirements most vul-
nerable to error? Will testing be destructive (the test product is torn apart and
destroyed in the process) or nondestructive? In destructive testing, you can verify
every aspect of a product, but you can’t send it to the customer. That’s fine if
you’re making a thousand widgets, but less fine if you’re making one very ex-
pensive custom item. Nondestructive testing may not be able to look at the
product in the same depth, but it may still give you enough information.
Sometimes failure is inevitable. Mean time between failures (MTBF)
measures the average time a product can run until it breaks, and serves as a
measure of overall reliability and durability. MTBF helps determine proper
maintenance, repair, and upgrade cycles. If your project output is not a phys-
ical item, you might use checklists, user focus groups, or outside evaluations
to measure quality and compliance.
Establish your quality control methods and targets in the planning
process and implement them during project monitoring and control. During
lessons learned, review how effective and efficient your quality management
has been, and how you might improve it next time.
EARNED VALUE MANAGEMENT

Earned value management (EVM) is used to monitor and control large projects
in such fields as construction, engineering, and information technology. You
normally encounter EVM only in large organizations, and even then only on
the largest projects.
In particular, you will likely run into EVM if you work for the US govern-
ment either directly or as a contractor. The US Department of Defense (DoD)
introduced the predecessor to EVM, known as PERT/COST, in the 1960s. It
evolved into the Cost/Schedule Control Systems Criteria (C/SCSC) over the
next decade, and by the 1980s it evolved again into the modern EVM. In the
process, the system has become easier to use and demonstrably more effective.
Today, EVM is one of the major tools used in acquisition reform, and its
effectiveness has been demonstrated by the early cancellation of several major
defense programs before they went out of control. As a result, the US Office
of Management and Budget (OMB), which sets general policies and proce-
dures for government agencies, mandated its use government-wide in a doc-
ument known as OMB Circular A-11. As EVM’s track record has grown, its
use has been spreading into private industry outside the defense sector.
Planned Value, Earned Value, and Actual Cost

In our discussion of the cost baseline shown in Exhibit 7–2, we pointed out
that the cost baseline could be used as a stand-in for scope and schedule as

well. That’s the first key idea in how EVM works. Exhibit 8–3 takes that cost
baseline diagram and adds additional information.
Exhibit 8–3 shows that we have completed Week 8 of our 12-week proj-
ect. The original cost baseline from Exhibit 7–2 is shown as the planned value
(PV). As of the end of Week 8, the PV, or what we should have spent in order
to accomplish the work we were supposed to do is $16,250. (In older versions
of EVM, the term budgeted cost of work scheduled, or BCWS, is used instead
of PV.) Because it’s the plan, the PV goes all the way to the final planned proj-
ect cost of $25,000, which is known as the budget at completion (BAC).
The actual cost (AC), previously known as the actual cost of work per-
formed (ACWP) is how much money we’ve actually spent to date, regardless
of whether we’ve done more or less work than planned. At Week 8, the AC
stands at $20,000, meaning we’ve spent $3,750 more than planned.
Is that a problem? If that extra money is because we’re way ahead of
schedule and we’re doing stuff we wouldn’t otherwise have gotten done until
Week 9 or 10, that could arguably be good news. That’s why we have to com-
pare the AC to the value of the work we actually got done. The earned value
(EV), which used to be the budgeted cost of work performed (BCWP) is the
planned cost for the actual work—a hybrid measurement.
xhibit 8–3
Earned Value
$30,000
Now
BAC
$25,000
$20,000
EV
$15,000
AC
PV
$10,000
$5,000
$0
1 2 3 4 5 6 7 8 9 10 11 12
BAC = Budget at Completion

EV = Earned Value
AC = Actual Cost
PV = Planned Value

Confusing? Imagine that the plan says we should have done three activ-
ities by today, and each activity had a budget of $2,000. That means the PV is
$6,000. Unfortunately, we only got two activities done, so our EV is only
$4,000. We’re behind schedule by $2,000 worth of work.
Let’s imagine that we spent $5,000 on that work. The PV is still $6,000,
and the AC is $5,000. At first glance it looks like we’re under budget, but we
still have to do that third activity. Instead, we should compare the AC of $5,000
to the EV of $4,000. We got $4,000 worth of work accomplished, but we spent
$5,000 to get it done. That means we’re really $1,000 over budget from the
perspective of the overall project.
What if instead, we got four activities done instead of the three that were
scheduled? Our PV is still $6,000, because it only measures what’s in the
schedule. Our EV, however, is now $8,000! That means we’re ahead of sched-
ule by $2,000 worth of work.
Now let’s imagine that we spent $7,000 to get the work done. At first
glance, we appear to be over budget, with our AC of $7,000 comparing to the
PV of $6,000. But when we look at the EV of $8,000, it’s clear that we’re really
$1,000 under budget compared to the project as a whole.
Exercise 8–1
Earned Value Metrics
Instructions: For each problem, define the PV, AC, and EV. These questions use our network dia-
gram for the PMO project from the Answer Key to Exercise 3–5.
1. Today, the plan said that we should have accomplished Activity 1 “Research,” Activity 2 “Write
Policy,” Activity 3 “Obtain Feedback,” Activity 4 “Finalize Policy,” and Activity 5 “Org Chart and
Position Descriptions.” Each of these activities has a planned (budgeted) cost of $2,000. We
have accomplished all except Activity 5 and we have spent $9,500.
EV = _________
PV = _________
AC = _________
2. The financial report we just got tells us that we have spent $22,000 to date, and the schedule
says we should have just finished Activity 6 “Recruiting.” Since the last reporting period, we
have accomplished three tasks that were planned to cost $8,000, $4,000, and $9,000 each,
but have only completed half of Activity 6, which was supposed to cost $5,000.
EV = _________
PV = _________
AC = _________
3. The plan tells us that we were supposed to get $10,000 work of work done, but we actually got
$15,000 worth of work done as of the end of Activity 9 “Conduct Training.” So far, we have spent
$12,500.
EV = _________
PV = _________
AC = _________

Cost Variance and Schedule Variance

Now let’s go back to the illustration in Exhibit 8–3. As of Week 8, our numbers
stand like this:
PV = $16,250
AC = $20,000
EV = $18,500
We planned to accomplish $16,250 worth of work (PV); we spent $20,000

to do it (AC); and we got $18,500 worth of work done (EV). The cost variance
(CV) is the earned value (EV) minus the actual cost (AC), or:
CV = EV – AC = $18,500 – $20,000 = -$1,500
Negative numbers are bad news and positive ones are good news. We are
over budget by $1,500.
The schedule variance (SV) is the earned value (EV) minus the planned
value (PV), or:
SV = EV – PV = $18,500 – $16,250 = $2,250
We are ahead of schedule by $2,250!
We’re over budget but ahead of schedule. Is that a good thing or a bad
thing? Let’s say the deadline is very important and budget is more flexible. In
that case, going a bit over budget in order to speed up the project could be
the right thing to do. If the schedule is more flexible than the cost, we may be
more concerned with the extra $1,500 we spent than with the extra work we
got done in this timeframe.
Although CV is pretty straightforward, SV has a few odd things about it.
First, “$2,250 ahead of schedule” doesn’t actually tell us whether we’ll make
the deadline, because SV doesn’t distinguish between activities on the critical
path and noncritical activities with plenty of slack. It only measures the cash
value of work packages.
SV also goes away at the end of the project, because once the work is
done, it’s done. When the project is complete, whether you were early or late,
all the activities are now done, meaning that EV is now equal to PV, no matter
how far apart they got earlier.
Exercise 8–2
Cost and Schedule Variance
Instructions: For the three situations described in Exercise 8–1, calculate CV and SV for each.
1. _________________________________________________________________________
2. _________________________________________________________________________
3. _________________________________________________________________________

Cost and Schedule Performance Indices

You may be wondering at this point what all the fuss is about. Once we’ve got
our basic EVM numbers calculated, we can use them to gain powerful insights
about the real status of our projects. To do that, we’ll need two additional
measurements.
The cost performance index (CPI) is the ratio of the earned value (EV) to
the actual cost (AC), or CPI = EV / AC. If we’re exactly on budget and sched-
ule, the CPI is 100%. If we’re under budget, the CPI will be over 100%, and
if we’re over budget, it will be less than 100%. Generally, if the numbers are
within ±5%, that’s considered normal variance. In our example, the cost per-
formance index is:
CPI = EV / AC = $18,500 / $20,000 = 92.5%
The schedule performance index (SPI) is the ratio of the earned value (EV)
to the planned value (PV), or:
SPI = EV / PV = $18,500 / $16,250 = 114%
Exercise 8–3
Performance Indices
Instructions: For the three situations described in Exercise 8–1, calculate the CPI and SPI for each.
Round your answers to the nearest whole percentage point.
1. _________________________________________________________________________
2. _________________________________________________________________________
3. _________________________________________________________________________
Applying Earned Value

Here’s why this matters. Let’s take a particular defense industry contract, in
which DoD awarded a $2 billion contract to build a new weapons system. At
approximately 3% of total dollars spent (around $6 million), the government
contracting officer sees some terrible numbers: CPI = 70% and SPI = 55%.
Given that this contract is in its very early stages, how worried should we be?
The first thing we have to do is figure out what’s going on. There are
three possible reasons for these terrible numbers.
First, imagine that most of the activities have been pretty much on sched-
ule and on budget, but one activity experienced a major problem. That’s not
necessarily a big concern. It’s not as if anybody expects to get through a $2
billion project without a few unpleasant surprises. The cost variance is a little
less than $2 million, and when the project is complete, $2 million is about
1/10 of one percent—a trivial amount in a project this large.

Second, EVM has a problem with work in progress. Whenever we decide

to calculate EV and AC, it’s usually the case that we’re in the middle of some
activities, and it’s not always easy to measure exactly how far along we are.
We use approximations, such as the 50-50 method, in which we count an ac-
tivity 50% complete for EVM purposes as soon as it starts, and only credit
the other 50% when it’s over. That’s generally good enough, but what if a
whole lot of tasks are in progress but due tomorrow? Right now, we only credit
them as 50% complete, even though they’re really almost done. That can drive
down the CPI and SPI, but if we check again in a few days, the numbers will
look very different.
But what if those CPI and SPI numbers apply to pretty much all the ac-
tivities? That’s a trend, and it suggests a huge problem in the estimating for
the original project. If this trend continues, what will happen to the project?
We already learned about the budget at completion (BAC), which is the
total planned cost. Now we want to compare that to the estimate at completion
(EAC), which is how much we think it’s actually going to cost to finish the
project. There are several different formulas to calculate EAC. The simplest
is to divide the BAC by the CPI.
EAC = BAC / CPI = $2 billion / 70% = $2.85 billion
Right now, we’re only $2 million (0.1%) over budget, but if the trend
continues, we’ll be $850 million over when the project ends! And that’s not
even taking into account the SPI, which suggests we’re taking twice as long
to do the work. That means the personnel and other variable costs are likely
to double, although fixed costs won’t be affected. Depending on the ratio of
variable costs to fixed costs, this could add at least another $500 million to the
cost overrun.
In this particular case, the contracting officer told the contractor to come
up with a plan to meet the original deadline and budget. The contractor
couldn’t do it, and after some back and forth, the government cancelled the
project when only 5% of the dollars had been spent, avoiding a potential bil-
lion dollar disaster.
The use of EVM on large projects lets senior officials recognize problems
at very early stages, where they can either be fixed or the project can be mod-
ified or terminated.
Advanced EVM
If you end up in a position requiring EVM, you will want to study it in more
depth. There are many more EVM calculations and formulas than we have
shown here, and the exact application of EVM varies based on the kind of
project. On smaller projects, the cost of setting up and reporting EVM meas-
urements is often excessive, although Microsoft Project® and other scheduling
software provides some EVM features, such as automatic calculation of PV,
EV, and AC values if all the necessary information has been entered into the
software.

Think About It . . . Earned Value
Are earned value techniques used in your organization or on projects you’re involved with? Would
they be useful and appropriate tools in your project environment? What potential benefits would
you get if you used EVM information?
UPDATING THE PROJECT PLAN AND BASELINE

Whether you will use EVM or not, one important lesson from the previous
example is that you should pay attention not only to problems, but also to
trends. A small initial variance can grow into a serious problem, and it’s usually
better to act early when you see a trend in the wrong direction.
In Chapter 7, we talked about problem solving strategies and ways to
modify the plan based on change orders, risk contingency strategies, and other
factors. The monitoring and control processes supply you with the informa-
tion you need and the early warning signs to tell you when it’s time to act.
The final monitoring and control step is the management of the project
plan and baseline. Minor variations from the baseline, or specific changes that
have limited effect, don’t usually warrant doing all the work to rebaseline the
project. Major changes, whether voluntary or in response to problems, may
render the current baseline useless as a monitoring tool. In that case, rebaselin-
ing is mandatory.
In monitoring and controlling your project, you must answer a

number of questions:
• How will you collect data about actual project status?
• What tools will you use to analyze those data?
• What format will you use to prepare project reports and up-
dates? How will you present that information?
• What is the threshold for problems that require you to inform
project sponsors and customers?
• How will you manage and allocate any contingency allowance of time or
money?
• If your risk plan includes contingent responses, how will you know when
they should be implemented?

The three basic ways to gather information on project status are meetings,
reports, and inspections. You usually use all three techniques. If you do not
already have standard forms for status reporting, develop them. If the mem-
bers of your team are not co-located (are geographically dispersed), you need
to develop tools to allow them to communicate effectively in spite of distance
barriers. Establish frequency of reporting based on the tempo of the project,
but feel free to modify the reporting schedule based on issues that may arise.
Risk monitoring and control involves tracking identified risks, monitoring
the effectiveness of risk responses, adding new risks and modifying existing
risks, and monitoring residual and secondary risk. Make risks a discussion
item at every status meeting and a category on every status report. Carefully
monitor the use of any contingency allowance or reserve.
The process of quality assurance and quality control are how we manage
process and product quality during the execution phase of the project. Quality
assurance and control use such tools as statistical process control (SPC),
process mapping, and other standard quality tools. Establish your quality con-
trol methods and targets in the planning process and implement them during
project monitoring and control. During lessons learned, review how effective
and efficient your quality management has been, and how you might improve
it next time.
Earned value management (EVM) is an advanced method used to mon-
itor and control large projects in such fields as construction, engineering, and
information technology. It is in widespread use in the US federal government,
where it has successfully identified troubled projects at early stages of their
life cycle. The three key metrics used in EVM are the planned value (PV),
the actual cost (AC), and the earned value (EV). Combined, they allow you
to measure cost and schedule variance in terms of the value of work. The per-
formance indices of CPI and SPI are particularly valuable in identifying issues
early.
One EVM lesson applicable to all projects is the importance of watching
for trends. A seemingly small variance can sometimes indicate a growing prob-
lem. Do not rebaseline the project for minor issues, but remember that major
changes, whether voluntary or in response to problems, may render the cur-
rent baseline useless as a monitoring tool, making rebaselining mandatory.

Review Questions
1. What are the three basic ways to gather information on project status? 1. (d)
(a) SV, CV, and CPI
(b) Stakeholder management plan, communications management
plan, and responsibility assignment matrix
(c) Test results, customer feedback, and sponsor reaction
(d) Meetings, reports, and inspections
2. Which of the following is a tool associated with quality control? 2. (b)

(a) Process map
(b) Mean time between failure (MBTF)
(c) Checksheet
(d) Pareto diagram
3. We were supposed to complete $10,000 worth of work today, but we 3. (c)

have only completed $8,000 and we have spent $9,000. What is the
schedule variance and cost variance?
(a) SV = $2,000; CV = -$1,000
(b) SV = -$1,000; CV = -$2,000
(c) SV = -$2,000; CV = -$1,000
(d) SV = -$2,000; CV = $1,000
CALCULATION: PV = $10,000; EV = $8,000; AC = $9,000.
SV = $8,000 – $10,000 = -$2,000. CV = $8,000 – $9,000 = -$1,000.
4. The total project is planned to cost $100,000. The project currently 4. (b)
has a CPI of 85% and an SPI of 90%. What is the EVM forecast of
the likely total cost of the project, rounded to the nearest dollar?
(a) $111,111
(b) $117,647
(c) $85,000
(d) $90,000
CALCULATION: EAC (Estimate at Completion) = BAC (Budget at Completion) /
CPI (Cost Performance Index) = $100,000 / 0.85 = $117,647.06 = $117,647.
5. How frequently should you gather status information on your project? 5. (a)
(a) Based on the speed of change within the project
(b) At least weekly
(c) Whenever the customer or project sponsor wants an update
(d) No less often than monthly

Evaluating and Reporting on
9
Project Performance
Learning Objectives
• List the five elements of project closeout and
define each one.
• Prepare a closeout checklist from a template.
• Plan transfer of a project’s output to its final
destination.
• Plan and execute contract and procurement
closure.
• Plan and execute administrative closure.
• Celebrate project success and recognize pro-
ject performance.
• Establish a comprehensive lessons learned/
project salvage process.

Reading 45 minutes

PROJECT CLOSEOUT
The official PMBOK® definition of project closeout is “the process of finalizing
activities across all of the Project Management Process Groups to formally
complete the project or phase.” Let’s start with the last word: you’re not merely
supposed to close out a project, but also a phase, which we discussed in Chapter
2. You also need to close out a project (or phase) if it is cancelled or ended
short of completion, even though in one sense you haven’t “finalized activi-
ties…to formally complete the project.”
As we said earlier, no matter why the project ends, there’s still paperwork,
documentation, releasing resources, and preparing lessons learned. Therefore,
you must conduct project closeout for every project, regardless of the circum-
stances of its end.
When we talk about a project’s deadline, we normally mean the point at
which the the project’s “product, service, or result” has been completed and
transferred to the customer or other end user. Pretty much by definition, pro-
ject closeout happens after that. In spite of that, the vast majority of project
plans, including those developed by experienced project management pro-
fessionals, fail to include “Closeout” in their WBS list of work packages. That’s
a mistake. Closeout takes time and resources, and the failure to close a project
properly can have significant consequences.
Project closeout involves several steps:
1. Transfer. The product, service, or result has to be transferred to its ultimate
owner, whether it’s the customer or a group of end users. That may be as
simple as sticking a shipping label on it and calling for pickup, or it may
require a complex process of integration and training.
2. Contract closure. If your project requires procurement or contracting, all
contracts must be resolved, the contracts must be closed, and vendors must
be paid.
3. Administrative closure. You must notify stakeholders that the project is com-
plete and gain any necessary approvals. You must prepare and file any pa-
perwork your organization requires. You need to release team members
and other resources so they can be assigned to new work.
4. Celebration and reward. You owe your success in part to the people who
worked on your project. Acknowledging and rewarding performance is the
right thing to do, but it’s also the smart thing to do.
5. Lessons learned. No matter the outcome, every project has elements that are
useful in the future. In addition to analyzing performance and finding op-
portunities for improvement, don’t forget to salvage all the parts of the
project you might be able to reuse.
Depending on the complexity and size of the project, you may want to
create more WBS elements than simply “Closeout.” For example, the process
of turning the deliverables over to their final owners might require a WBS
package all its own.

EVALUATING AND REPORTING ON PROJECT PERFORMANCE 159
Think About It . . . Project Closeout
Do you have a formal closeout process for your projects? What works and does not work about
your current closeout activities, whether formal or nonexistent? What areas seem ripe for improve-
ment?
CLOSEOUT CHECKLIST
For many project managers, closeout is the least fun part of the project. By
project’s end, you’re usually ready to move on to something new, and nobody
likes being stuck with administrivia. By organizing your closeout strategy in
advance, you can reduce the amount of pain and boredom commonly associ-
ated with the process.
The first tip for running a smooth closeout is to close as you go. Create
both a physical folder (or inbox tray) and a folder on your computer labeled
“Closeout,” and whenever you come across documents, emails, or other ma-
terial you’ll need at the project’s end, add it to the folders.
Second, create a closeout checklist. Exhibit 9–1 provides a closeout checklist
template you can modify to fit your needs. A general checklist will serve most
projects; you usually only need to tweak a line item or two. A good closeout
checklist organizes the material and makes sure you don’t forget any steps.
Some items can be checked off long before the actual project ends, making
the final steps easier.
Exercise 9–1
Closeout Checklist
Instructions: How would you customize the closeout checklist for the PMO project?

xhibit 9–1
Closeout Checklist
PROJECT CLOSEOUT CHECKLIST

Date Comments
Project Completion
1 All activities completed
2 All deliverables completed
3 All WBS packages completed
4 All change orders completed
5 All outstanding issues resolved
6 External certifications and authorizations signed
7 All deliverables transferred to end user/customer
All “as builts” and supporting documentation transferred
8
to customer
9 Customer acceptance of all deliverables complete
Reporting
10 Interim and final reports to stakeholders complete
11 Budget and accounting reports complete
“Lessons learned” documentation complete and
12
submitted
13 Internal approval and acceptance complete
Resources
14 Team members released for other work
15 All project costs charged and any excess funds returned
16 Excess materiel disposed or transferred
17 Capital equipment and durables released
18 Rented or leased equipment and durables returned
19 Project plans archived
Contracts
19 All contract documentation complete
20 Vendor payments authorized
21 Contract and vendor evaluations complete
22 Rental or leasing agreements terminated
Customer and Team Satisfaction
23 Customer satisfaction evaluation performed
24 Customer satisfaction issues resolved
25 Team success celebrated
26 Individual performance evaluated and recognized
Closeout Name/Signature Date
complete

TRANSFER
The end of the project is usually determined at the beginning. Visualize exactly
how you will take the product’s output and deliver it to its intended customer.
What steps are necessary? Is there supporting documentation? Training? Ship-
ping? Packaging? As-builts? A period of transitional support? Will there be in-
stallation required? Will your product or service need to integrate with other
systems? How much time will all this take? How much will it cost? What re-
sources are required?
These are vital questions, and if they aren’t asked early and integrated
into the project plan, you may find yourself in trouble. An example: When
Chrysler designed the PT Cruiser, they neglected to consider how it would
be assembled. It wasn’t until the assembly line started up that they discovered
that car’s narrow hood was so constrained that there was only 0.6” of clearance
to fit the engine inside. Instead of being able to roll a new car off the assembly
line every two minutes, it took workers a day to fit each engine into each car.
Although ingenious workers found a workaround, eventually producing a car
every eighty seconds, this is an example of the kind of problem that occurs
when project managers think their work is done when the product is delivered
to the next stage of the process.
Exercise 9–2
Implementing the PMO
Instructions: How will your PMO be transferred from project status to full operation? Give specifics.
CONTRACT AND PROCUREMENT CLOSURE

Procurements start and finish at different times through the project life cycle,
so close out each procurement when it is done. Keep a log of procurements
and contracts so you can check them off on a continuing basis. During formal
closeout, close the remaining contracts and verify there are no outstanding
procurements.
If there are open claims involving a vendor, that doesn’t necessarily pre-
vent you from finalizing closeout. As long as the issues have been documented
and transferred to the right person in your purchasing department, you can
mark the procurement “done” from a project perspective. You may, of course,
be called upon to provide additional information if necessary.
Sometimes, procurements are closed early because of problems. A par-
ticular vendor may not deliver the right quality at the right time, forcing you

to use a backup. Those contracts have to be closed as well, and any related fi-
nancial issues resolved. As long as those actions are in the proper hands (your
purchasing or legal staff), you can also mark them “closed.”
When you are buying large, complex items or services, or ones with a par-
ticularly long lead time, you may need to conduct procurement audits or in-
spections. As part of closeout, you may have to engage in negotiations with
vendors to resolve issues sufficiently to allow you to mark those contracts closed.
Keep a procurement file with all contract and purchasing materials. It
should be archived along with other elements of administrative closure.
ADMINISTRATIVE CLOSURE
Most organizations have policies on document retention. You are normally
responsible for ensuring that a complete project file with all documentation
is archived in your records management system, in case of future claims or
problems that might arise. This file is separate from any “lessons learned,” al-
though your lessons learned report may be one of the items in your adminis-
trative closure file.
Different projects produce different amounts of information, and in some
cases administrative closure can take significant effort. If you think that might
be the case, that’s another reason why it’s so important to close as you go and
keep files up to date.
Administrative closure normally includes the release and return of assets.
Team members may return to their regular jobs or be transferred to a new
project team. If you’ve used consultants or outside resources, you’ll release
them to seek other work and handle the related contract issue as part of con-
tract closeout.
The accounting and finance departments will need final budget infor-
mation, and if you haven’t used all the allocated funds, you will need to turn
those over as well. If you use capital or durable assets, ranging from working
space to heavy machinery or anything else that isn’t used up in the perform-
ance of the project, those must also be relinquished or returned. Unused con-
sumables also need proper disposition.
CELEBRATION AND REWARD

It’s a good feeling to finish a project. Those feelings can build morale and im-
prove performance long term. Always celebrate project success, even if it’s
just going out to lunch with the team.
Though you normally aren’t paying project team member salaries out of
your own pocket, you can still reward performance. Writing letters for their
regular supervisor or for the personnel file can help advance people’s careers.
If you can give team members the opportunity to expand their skills and ex-
perience, that’s a reward not only for them but for the organization. As your
project winds down, keep an eye out for opportunities that might benefit
members of your team, and recommend them for new assignments.

Although performance evaluation is sometimes seen as more of a pun-

ishment than a reward, effective evaluation can be highly beneficial for pro-
fessional and personal growth. Even if you aren’t the official supervisor, you
can still give constructive and useful feedback.
Don’t limit rewards and celebration to full-time employees. Consultants,
part-timers, and vendors also have a stake in the project, and it normally takes
little effort to include them. Letters to their bosses, recommendations, and
evaluations are as valuable to them as to regular employees.
When you have a reputation for recognizing good performance and help-
ing people grow, you’ll find that more people want to work on your projects
and will work harder and better. Motivation isn’t a one-time thing, and you
may find that your efforts today pay dividends in years to come.
Think About It . . . Celebration
What ways have the ending of your projects been recognized and celebrated? Are there any par-
ticular things that have worked well or poorly? How important is it to you that your work on projects
and the ends of projects be recognized and celebrated?
LESSONS LEARNED
Project management authorities are unanimous in recognizing the importance
of conducting project “lessons learned” reviews, and we agree. However, in the
real world, lessons learned are frequently skipped, people often resist the
process, and the lessons themselves are seldom integrated into other projects.
Establishing a useful and effective “lessons learned” process isn’t easy or auto-
matic. As with other elements of closeout, it’s essential to plan before you act.
What are some reasons people dislike “lessons learned”? First, the process
too often turns into blamestorming, in which figuring out who messed up seems
to be more important than figuring out how to do it better next time. The idea
of “lessons” makes the process seem designed to focus on criticisms. People
aren’t sure what they’re supposed to be looking for. There is no clear mechanism
for making the information and results available to other project leaders. The
lessons learned report itself talks about the old project and doesn’t emphasize
transferrable lessons. The lessons themselves can appear to be patronizing. And,
of course, there’s the famous “Not Invented Here” (NIH) syndrome that makes
people resist knowledge from outside. “Our project is different,” they say.

Although we do endorse the practice of lessons learned, perhaps the

name itself is part of the problem. As we have suggested, many of the raw
planning documents (WBS, schedule, risk register) are inherently useful to
similar projects. Tools and processes invented to deal with an immediate issue
may have wider applicability.
Even failed projects provide surprising value. As we mentioned earlier,
Post-it® notes (or at least the special glue) were a byproduct of a failed pro-
ject—and they became 3M’s biggest seller. Vulcanized rubber, penicillin, x-rays,
and many other important developments came about as happy accidents.
With that in mind, consider calling the effort project salvage rather than
“lessons learned.” The goal is not merely to criticize and improve performance,
but to go through the project and recover everything in it that might be useful
to future project teams. If something unexpected went wrong, it may have been
such a surprise that there’s no basis to criticize anybody. However, now that it’s
happened once, perhaps future projects need to take that into account.
In the Tylenol® murders case of 1982, someone (still not caught) slipped
cyanide into bottles of Extra-Strength Tylenol® and killed seven people. Until
that point, there had never been a deliberate attempt to poison a commercial
product. Because it had never happened, nobody had thought to design products
to resist such an attack. It would be wrong to condemn Tylenol® manufacturer
McNeil for failing to anticipate the attack, but today, just about everything you
might consume comes in tamper-evident packaging.
As with all effective meetings, you need an agenda and process to make
lessons learned/project salvage work. Exhibit 9–2 lists some things worth con-
sidering.
Exercise 9–3
Lessons Learned Questions
Instructions: What elements in the PMO project can be salvaged to add future value? List at least five.
1. _________________________________________________________________________
2. _________________________________________________________________________
3. _________________________________________________________________________
4. _________________________________________________________________________
5. _________________________________________________________________________
6. _________________________________________________________________________
7. _________________________________________________________________________
8. _________________________________________________________________________
9. _________________________________________________________________________
10. _________________________________________________________________________

xhibit 9–2
Lessons Learned/Project Salvage
1. What planning materials did we create that might have value for future projects?
1.1 Work Breakdown Structure
1.2 Project Schedule
1.3 Cost Breakdown
1.4 Responsibility Assignment Matrix
1.5 Communications and Stakeholder Management Plans
1.6 Risk Register
1.7 Others?
2. What did we learn about how long it takes and how much it costs to complete
certain activities?
2.1 Raw information to improve future estimates
2.2 Possible causes of variance between estimates and actuals
2.3 Ideas for shortening time, lowering costs, and improving performance
3. Which risks from our risk register occurred? What unforeseen issues occurred?
3.1 Should we alter estimates of probability based on this experience?
3.2 Were our risk responses effective?
3.3 Did we have to implement contingency plans?
3.4 Did the contingency plans work as expected?
3.5 What workarounds or corrective actions did we need to take? Should we alter our
planned risk responses on future projects based on this information?
3.6 If we had unforeseen issues, are they likely to recur? If so, how would we address
them in future risk plans?
3.7 Based on experience, would we want to adjust our planned risk responses to be
more effective?
3.8 Was our contingency allowance appropriately sized? Do we need more or less in the
future?
4. What change requests did we receive and what actions did we take?
4.1 If we had surveyed stakeholder needs better, could we have changed our initial
project to integrate these issues, or did the change result from factors that could not
have been known in the planning phase?
5. Did our project team have all the necessary skills and work maturity to accomplish what
needed to be done?
5.1 Do we need to provide training and coaching opportunities to develop skills we are
likely to need on future projects?
5.2 Are there any overall performance issues we need to address?
6. How did vendors perform?
6.1 Should we use particular vendors again, or should we seek alternatives in the future?
6.2 If we used outside consultants or other resources, are there any people we might use
again—or people we shouldn’t use again?
7. Were stakeholders happy with the process and the outcome? Why or why not? How could
we improve in the future?
8. Did our project create any products, processes, or other results that might have more
general use in our organization?

ON TO THE NEXT PROJECT!

You’ve now completed a Self-Study course in the fundamentals of successful
project management, and seen how many of the concepts, tools, and tech-
niques work in practice. Based on your immediate project needs, you may find
some of these concepts more immediately useful than others. There’s a lot of
work in performing formal project management, and you’ll be more successful
if you start slowly and build up.
As you build a collection of previous project plans, you’ll find it easier to
go into greater depth. There’s a learning curve in project management, as in
most fields, so your first attempts will generally take more effort. Later, as you
gain familiarity, you’ll not only pick up speed, but also improve quality.
Every project ends, but a project manager’s career moves forward. By ap-
plying the tools and building from your experience, you’ll find yourself
steadily able to take on greater challenges with confidence and success.
Think About It . . . Next Steps
What are the most important ideas you will take away from this course? How will you implement
them in your future projects?
The official PMBOK® definition of project closeout is “the

process of finalizing activities across all of the Project Man-
agement Process Groups to formally complete the project or
phase.” Steps in project closeout are: transfer, contract closure,
administrative closure, celebration and reward, and lessons
learned. Because of the number of activities involved, put a
“closeout” work package in your WBS and ensure that your
schedule provides the time and resources necessary to accomplish it.
Develop a closeout checklist to have a smooth closeout. Set up a file to
collect information you will need in closeout, and close aspects of the project
as they are finished rather than waiting until the end to close everything. En-
sure all contracts and procurement actions are resolved. In administrative
closeout, organize and archive project materials, and release staff and other
resources.

Celebrate a project’s success and make sure you take personal action to
recognize and reward performance. That’s not only the right thing to do, but
also the practical thing to do: you’ll end up with a more motivated team in fu-
ture projects.
Although project management authorities are unanimous in recommend-
ing “lessons learned,” in practice it’s not so easy. Lessons learned can devolve
into criticism, and all too often the lessons are archived and never seen again.
Consider reframing it as “project salvage,” with a goal of taking everything
reusable from the project, from WBS to risk plans to research data. Even failed
projects can produce things of surprising value.
Even if no one else uses lessons learned, you can. Project management
can be difficult and time consuming. When you build future projects on the
foundation of previous ones, you save time and increase quality. Every disci-
pline has a learning curve. Though it may be tough today, it can get easier to-
morrow.

Review Questions
1. What is a positive reason to conduct project “lessons learned”? 1. (d)

(a) To find and discipline unsatisfactory workers
(b) To show other project managers what they’re doing wrong
(c) To make sure everything is put in the right file folder
(d) To make future projects better and easier
2. What is a reason for keeping a log of all procurement and contracts? 2. (c)
(a) Lessons learned
(b) Administrative closure
(c) Contract closure
(d) OMB Circular A-11
3. Who is responsible for ensuring that team performance is celebrated 3. (d)

and recognized?
(a) The human resources department
(b) The permanent supervisors of individual team members
(c) The project sponsor
(d) The project manager
4. What is a good first step to put lessons from this course to use? 4. (c)
(a) Put in a comprehensive project management system first thing
tomorrow
(b) Use every concept described in this book
(c) Perform earned value management on your next project
(d) Start slowly and build up
5. Which closeout process involves analyzing performance, finding 5. (d)

opportunities for improvement, and salvaging parts of the project
that might be useful in the future?
(a) Transfer
(b) Customer satisfaction review
(c) Administrative closure
(d) Lessons learned

Appendix A
Answers to Exercises and Case Studies
EXERCISE 1–1 GETTING STARTED

1. What is the project that must be accomplished?
Establish a Project Management Office (PMO) in our organization.
2. Why are we doing this project? How will the project benefit us if it is suc-
cessful?
Several recent projects have failed. The CEO believes that a PMO may
improve our project performance. In addition, many of our competitors
already have PMOs, and there is a fear that this will allow them to pull
ahead in the marketplace. Because the deadline of the project is the annual
stockholders’ meeting, this implies that there is a concern that stockholders
may have a negative opinion of our management if we do not establish a
PMO capability.
3. When must the project be accomplished?
The official deadline of the project is the annual stockholders’ meeting,
which will take place in nine months.
One important question that we will need to answer is how good or how
developed this PMO must be. Our new PMO won’t have a lot of time to
build a track record by the time of the stockholders’ meeting, so we may
need to consider that there is both a short-term goal (reassure stockhold-
ers) and a long-term goal (improve project performance). Does the stock-
holders’ meeting represent the official end of the project, or is it merely
the end of the initial phase?
4. What people, resources, and budget are available to us?
No information is provided in the initial case study to answer this question,
and that’s not unusual at this preliminary stage. Often, the project manager
will need to develop a plan and determine the resource requirements, and
then present it to the appropriate managers or customers. However, orga-
nizational issues and constraints may put limits on your options, and you
will need to assess those in the process of developing the budget.

5. What authority and power do we have to accomplish the work?

Because this project has been assigned to you by the CEO, this implies that
you will have valuable executive backing to support your role as project
manager. However, this isn’t a guarantee, and you should also be concerned
about the potential resistance from managers who are skeptical about a
PMO. It’s vital to distinguish between your official power and your practical
power—and it’s the practical power that enables you to get the work done.
6. Who are the stakeholders—the people who will be affected by our project?
What are their interests and concerns?
The CEO is a stakeholder, as are the various managers who will be affected
by the PMO. Some of those stakeholders are skeptical and potentially neg-
ative about the project; others may be supportive or neutral. Because the
deadline is tied to the stockholders’ meeting, this implies that the stock-
holders (along with the stock analysts) are also stakeholders in the project.
It is possible that one or more large or institutional stockholders are major
forces driving this project, and you will want to discover if this is true, and
if so, what their concerns may be.
This is unlikely to be a complete list of stakeholders. As you move
forward in the project, you will frequently discover many more individuals
and groups who will be affected.
7. Are there any major known risks that we can see at the beginning of the
project?
The biggest known risk is the potential for internal opposition on the part
of skeptical managers. It also hasn’t yet been determined if nine months is
a reasonable timeframe for accomplishing the work. An additional major
risk is that the resources and budget available to you are unknowns.
Again, this is only a preliminary list. You may discover many more
risks as you proceed with the planning process.
8. How will we measure our success?
Aside from the goal of having a functional PMO operational in time for
the stockholders’ meeting, other measurements are currently unclear. The
CEO will obviously play a role in defining success criteria, but the con-
cerns of the managers will also play a part.
EXERCISE 1–2 KNOWLEDGE AREAS

1. Project Integration Management. What we know about our role as proj-
ect manager in bringing this project together and leading it to a successful
conclusion.
This project involves work that is new to the organization and that may
be politically sensitive. The authority of the project manager is rooted in
the fact that it is the CEO who wants it accomplished, and may be sup-
ported by outside pressure from stockholders. No specific department or
work group inside our organization has all the necessary skills, so the proj-
ect will almost certainly cut across organizational boundaries.

APPENDIX A: ANSWERS TO EXERCISES AND CASE STUDIES 171
2. Project Time Management. What we know about the schedule and any
time constraints.
We know that the project must be complete in time for the stockholders’
meeting, nine months from now. We do not yet know how challenging this
schedule will be, or how much the schedule can be improved through extra
people or money.
3. Project Scope Management. What we know about the work that must be
done, and the work that is not included in this project.
Our current description of scope is rather limited: a “functioning PMO.”
Exactly what this looks like has to be fleshed out fairly quickly. There may
be long-term issues that are not part of this project, even though they will
have to be addressed eventually.
4. Project Cost Management. What we know about the budget, resource
availability, and anything else we might spend to accomplish the project.
We have received no guidance on budget or resources. This suggests that
our priority is more likely going to be time, and that we may have flexibil-
ity in the resources we request to accomplish the work.
5. Project Communications Management. What we know about the need
to report and communicate with others during the project.
The CEO’s personal interest means that the CEO will probably want to
keep track of progress, and in particular know about any issues that would
jeopardize the deadline. We will have standard project communications
issues, such as the need for status meetings and reports. Individual project
managers will be impacted by the new PMO and will also need to be con-
sulted about their issues, needs, and concerns, and about any changes they
will have to make to their own activities based on this new PMO struc-
ture.
6. Project Stakeholder Management. What we know about people affected
by the project, their interests, and their issues.
We are already aware that some managers have concerns about this new
PMO, and we need to discover exactly what those issues are and how we
can address them. We also need to understand the issues that make our
stockholders interested in the PMO so that our project scope addresses
the reasons they want a PMO in the first place.
7. Project Human Resources Management. What we know about the peo-
ple and skills we need to accomplish the work.
Aside from the assignment of a project manager, we have not yet received
any guidance on the team we will have to do the work. Given that the proj-
ect is to develop a new department, we will need to do the necessary
staffing, whether that involves transferring or reassigning existing employ-
ees or hiring new ones.
8. Project Quality Management. What we know about factors that deter-
mine whether this project will meet the needs for which it was established.

We seem to have two initial quality objectives: solve the problems that have
led to recent project failures, and show the stockholders that we are adopt-
ing industry best practices. Although these objectives are compatible, they
are not identical. It’s not enough to solve the problem; we must also demon-
strate the solution. And it’s equally not enough to show off a PMO; the
PMO actually has to work.
9. Project Procurement Management. What we know about any products
or services to be acquired outside the organization.
Any number of outside resources are available to us. We can hire project
management consultants with experience in setting up PMOs. We can hire
trainers to develop project management skills among our staff. If we must
recruit new employees to staff the PMO, we can hire outside recruiters.
This suggests that we will need to consider a variety of “make or buy”
choices, which will be affected by both the budget and the schedule.
10. Project Risk Management. What we know about project threats and op-
portunities.
We already know about potential internal resistance on the part of some
managers, and we do not yet know whether the time constraint is realistic.
Because we do not yet have much information on cost and resources, we
are uncertain what risks may exist in those areas. There are also substantial
opportunities available to us, not the least is that we are building a PMO
using project management, which means we will be building resources we
can take immediate advantage of.
EXERCISE 2–1 STAKEHOLDER REGISTER

Stakeholder Project Role Area of Concern Your Impact on Their Impact on Timing Management
Them You Strategy
Skeptical May be asked Will this project Positive: May May have political Interested in the In initial phases,
managers to furnish take away their improve project influence that can initial planning and identify concerns
resources or power, authority, or performance and be used for or strategy, which and potential
information in resources? Will it deliver better against you; may may or may not issues; address
support of the actually work, or results for their provide support or reassure them them as much as
project. merely add an departments or hindrance in the about some of their possible in hopes
additional layer of programs. process; may need concerns. Work of of reducing some
bureaucracy? What Negative:May take to provide the project may of the opposition.
powers will the new away some of their resources. impact their Show them
department have? power and resources. Output potential benefits of
authority; may take of the project may the project’s
away resources. affect their success. Escalate
May not work as authority and role. any major
advertised. problems to the
CEO.

Consultants Consulting and Depending on the Their particular Can fill in any Consultants will only Consider these
training extent and areas of expertise knowledge or skill be involved after the issues in “make or
services availability of and the functions gaps and decision is made to buy” decisions on
internal resources, we decide to supplement internal recruit and hire whether and where
and the overall acquire from resources. Will them. Will be to use outside
budget and timing, outside. Money consume project involved with services. Negotiate
we may want to they make from budget. May be operational decisions contracts carefully.
use outside providing the tempted to oversell and work in their Establish incentives
consultants and service. services and push area of expertise. to ensure their
trainers with Opportunity for for long-term May or may not have services are in line
experience in follow-up work. contracts. a long-term role in with your long-
setting up PMOs. the operation of the term goals.
PMO.
Project What the PMO We may survey The product, not While the needs, Project managers Survey project
managers can do for project managers the project, will be interests, and ideas will provide input, managers and
them to get their ideas the major impact of the project but not direction, to evaluate what is
about what the on them. Until the managers are the initial project working and not
PMO should do PMO is up and important and definition, and will working about the
and how it will running, project should be be the major end present system.
work. May use managers will considered, they are users of the PMO Develop an
some PMs as part continue to operate not the decision- once established. implementation
of the project team. as they have makers. Potential strategy to handle
previously. Some career opportunity the transition from
project managers for project current methods to
may be recruited to managers who want the new PMO.
work in the PMO. to be in the PMO.
Training and skill
building opportunity
for PMs.
Customers The quality of None Reducing project Some customers They may want to We may want to
projects failure rates will may be consulted know about the provide press
benefit customers. during the project, efforts we are releases or other
but in general, they undertaking to information to
will only deal with improve projects, customers
the result. but don’t care advertising our new
about the PMO as capabilities as part
such. of obtaining new
business, but this
work will probably
be handled by our
marketing and
sales team
separately from the
PMO project itself.
Stockholders None Our project results; Project success will Little or none They care about Communication
concerns about grow the company, during the project results, not about with stockholders
company which in turn will itself. the project or the will probably be
performance and increase stock PMO itself. kept with the CEO
stock price. price. and stockholder
relations people,
not with the project
team.

EXERCISE 2–2 HIERARCHY OF CONSTRAINTS

Triple Constraints
Here are the key phrases from JFK’s speech on each element, followed by
an interpretation of each:
Time: These are the references to time in the speech: “…before this
decade is out,” “have never specified long-range goals on an urgent time
schedule, or managed our resources and our time so as to insure their ful-
fillment,” “Recognizing the head start obtained by the Soviets with their
large rocket engines, which gives them many months of lead-time,” “…
we cannot guarantee that we shall one day be first, we can guarantee that
any failure to make this effort will make us last.”
The official time constraint is “before the decade is out,” but the pre-
ferred time constraint is “before the Soviet Union gets there.” Not every
constraint gets spelled out.
Cost: “531 million dollars in fiscal ‘62—an estimated 7 to 9 billion dollars
additional over the next five years,” “…above and beyond the increases I
have earlier requested for space activities.”
The official budget of the project is between $7 and $9 billion. That’s
a budgetary range of more than 20 percent. That suggests that these num-
bers are mostly estimates.
Performance: “…landing a man on the moon and returning him safely to
the Earth,” “…win the battle that is now going on around the world be-
tween freedom and tyranny.”
The technical performance objective is to get astronauts to the moon
and back. The wider context of the project is the competition with the So-
viet Union, the Space Race, and that people will measure success or failure
not so much by the trip, but by whether we win the race.
Driver: Time. If we don’t win the race, we won’t be declared the victor.
Middle: Performance. We are focused narrowly on “to the moon and back.”
Wider considerations of space exploration and colonization aren’t in the
project.
Weak: Cost. Because US national prestige is on the table, spending extra
money to pull ahead in the race will probably be received favorably.
EXERCISE 2–3 PMO PROJECT CONSTRAINTS AND

ASSUMPTIONS
Triple Constraints
Time: The deadline of the project is the stockholders’ meeting that will
take place in approximately nine months. This date is significant because
one of the reasons of this project is to reassure stockholders and stock an-
alysts that your company is moving forward.

Cost: There are two separate cost considerations. First is the project
budget itself. You have been asked to cap it at $50,000. This would include
any costs for outside consultants, software, training, etc. The value of em-
ployee time will not be charged to the budget. The second consideration
is the cost of running the PMO itself: no more than $200,000 per year.
While this is not technically a “project cost,” but rather an operational cost,
it still serves as a constraint on the PMO that you develop.
Performance: We have not been told the details of how this PMO should
work, but we have been told what its goals are. The first goal is to reassure
the stock analysts and stockholders that yes, we have a PMO. The second
goal, based on the management skepticism, is that the PMO needs to im-
prove the management of projects without adding excessive bureaucracy
or threatening the authority of line managers.
Driver: The need to have something to show the stock analysts and stock-
holders is dominant, so we conclude that time is the driver. After all, we
can continue to upgrade the new PMO after the meeting is over.
Middle Constraint: While the exact shape and structure of the PMO has
been left to us, the goals of (a) happy stock analysts and (b) greater project
management effectiveness are the reason for undertaking the project in
the first place. If the PMO doesn’t deliver the promised benefits, it hardly
matters whether we meet the budget or not: the money will have been
wasted. We conclude that performance is the middle constraint.
Assumptions
• The proposed budget of $50,000 and operating budget of $200,000 per
year will turn out to be reasonable once we develop the project scope.
• Only a few managers are worried about their authority being chal-
lenged; the managers who talked only about the PMO’s effectiveness do
not have a hidden agenda.
• Our competitions’ PMOs are benefitting their projects.
• The stock analysts’ concern about our company will go away if we
demonstrate that we have a functioning PMO.
• We will not be able to use in-house people to staff the PMO because
those who would be qualified cannot be spared from their current jobs.
• Nine months is a reasonable timeframe to accomplish this work.
• Even though you, the project manager, have no experience in setting up
a PMO, it is well within your ability to do so.
• Of all the ways we could improve project performance in our organiza-
tion, the PMO is the best strategy right now.

EXERCISE 2– 4 PMO PROJECT CHARTER OUTLINE

Business need or purpose of the project.
We need to improve the quality of our project management and show the
stock analysts that we are making progress.
Description of the product, service, or result that the project is
supposed to deliver, preferably expressed as measurable objectives.
A Project Management Office that is staffed, operational, and already in-
volved in supporting one or more projects.
High-level requirements of the project, along with boundaries—
what the project isn’t expected to accomplish.
We can’t reasonably be expected to have the PMO complete several proj-
ects within the nine month timeframe, so it’s enough to show that it’s be-
ginning to work. We also aren’t directly addressing project problems
themselves, but rather setting up a structure to help them.
List of constraints that apply to the project.
Already done.
Major stakeholders and their individual needs and goals.
Already done.
High-level risks and major milestones.
In addition to the possibility that some of our assumptions prove false, we
see significant risk in the budget and time constraint. That risk will not go
away until we have developed an overall project plan that we can meas-
ure.
Assignment of a project manager, a statement of the project
manager’s authority and responsibility, and a list of people who must
approve elements of the project or its final outcome.
You’re the project manager. The CEO, as the person assigning the project,
is also the person with final approval. However, the CEO may choose to
delegate some of that responsibility elsewhere. Even though the approval
of skeptical managers may not be required officially, it may be a good idea
to get their input and feedback.
Other organizations that must support the project and what they are
expected to provide.
Internal organizations and work groups are expected to support this effort,
regardless of skepticism. We may use outside consultants and trainer(s) to
provide specific project elements.

EXERCISE 3–1 RESEARCH AND THE SOW

There are many online resources you might look at. The first page of
Google® results (accessed 2 August 2013), offers links to a Wikipedia page,
a number of images including process and organizational charts, an article
on “Why You Need a Project Management Office” from CIO.com, a PMI®
website page offering downloadable papers (if you’re a member), a free
white paper from Planview, and a lot more.
There are any number of potential changes you might consider to the
SOW. First, you might decide that its role should focus on, say, IT, if that’s
the major source of projects. You might add information about staffing or
organizational structure. You might decide that the SOW should focus
more on hiring outside consultants, or the reverse.
EXERCISE 3–2 DIFFERENT WBS APPROACHES

In the first diagram, each department has its own expertise and functions.
By organizing the work accordingly, it’s clear what responsibilities each
department has. The advantage of putting the WBS together this way is
that there’s clarity about each functional role. The disadvantage is that it’s
difficult for a single person to exercise management control over all the
departments.
In the second diagram, we’ve assembled a cross-functional team con-
sisting of representatives from each of the functional groups, and intend
for them to work together throughout the project. The entire group works
on the first phase, then on the second, and so forth until the course is fin-
ished. While it’s natural that different groups will lead different phases,
this approach allows easier project control. The disadvantage is that that a
smaller work group doesn’t have easy access to the full resources of each
department, and individuals on your team may be assigned part-time to
multiple projects simultaneously.
There is, of course, no single right answer that fits every situation. As
we noted earlier, it’s normal to find more than one WBS approach for the
same project, and the right WBS for you is the one that reflects how you
plan to manage the project.

EXERCISE 3–3 BUILD A WORK BREAKDOWN STRUCTURE

Establish a PMO
Development Staffing Training
Org Chart and

Policy Statement Training Program
Position Descriptions
Internal Briefings Recruiting Conduct Training
Stockholder
Project Management
Presentation
Evaluation of Results
EXERCISE 3– 4 ACTIVITY LIST

1. Research PMO best practices
2. Write policy statement
3. Get comments and feedback on policy statement
4. Finalize policy statement
5. Set up org chart and write position descriptions for PMO
6. Conduct internal briefings and presentations on the PMO
7. Recruit candidates
8. Hire staff for the PMO
9. Hire consultant to conduct initial project management training
10. Conduct training classes
11. Arrange for the PMO to support one or more projects
12. Prepare a presentation for the stockholders’ meeting on the new PMO
13. Evaluate results and recommend next steps
EXERCISE 3–5 NETWORK DIAGRAM

8. 9.
Outside Conduct
trainer training
4.
1. 2. Write 3. 10. PMO Stockholder 12.
Start Finalize FInish
Research policy Feedback project Meeting Evaluate
policy
5. Org 11.
chart and 6. Recruit 7. Hire Stock-
PDs holder

Notes: Notice that we begin looking for an outside trainer and start setting
up the new PMO after we’ve received feedback but before the policy doc-
ument is finalized. This allows us some extra time for adjustment. The final
policy only needs to be in place when we hire.
To develop the stockholder presentation, we need to have the depart-
ment set up and running, with work being done to support one or more
projects. The stockholders’ meeting, like “Start” and “Finish,” is a project
milestone. Although in one sense the stockholders’ meeting is the deadline,
the evaluation and fine-tuning of the new PMO can and should take place
afterward—not all project work necessarily needs to be done before the
deadline to consider it a success. The project isn’t finished until final rec-
ommendations have been made.
EXERCISE 3–6 FORWARD AND BACKWARD PASS
EXERCISE 3–7 CREATE A GANTT CHART

A 0 N/A
B 5 A
C 7 A
D 9 A
E 3 B, C
F 6 C
G 3 D


H 6 E
I 8 F, G
J 0 H, I
This version shows the connecting lines, although they are optional, especially
in hand-drawn Gantt charts.
Task 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
EXERCISE 4–1 TYPES OF ESTIMATES

For the following estimates, list the estimating methodology used (WAG,
analogous, expert, Delphi, parametric, bottom-up), and classify the ex-
pected accuracy (ROM, preliminary, budgetary, variable) of the number.
Estimate Basis Type Accuracy
1. The president says we’ll go to the moon in WAG ROM
10 years.
2. We surveyed ten people and used the average. Delphi Prelimimary
3. Joe has done this kind of thing a lot. Expert Preliminary
4. We did something like this a few years back. Analogous ROM
5. When we added it all together, it came to Bottom-up Definitive
$1 million.
6. We ran the specs through our job cost program. Parametric Definitive
7. Six weeks sounds reasonable. WAG Variable
8. Research says 10–15K lines of code per year Parametric Preliminary
is average.
10. Six months sounds about right. WAG ROM

EXERCISE 4–2 CALCULATING PERT ESTIMATES

1. For Activity A, the optimistic estimate is 10 days, the most likely esti-
mate is 12 days, and the pessimistic estimate is 25 days. What is the
PERT estimate and standard deviation?
E = (10 + (4 * 12) + 25) / 6 = 14
𝞂 = (25 – 10) / 6 = 3
2. For Activity A, the optimistic cost estimate is $5,000, the most likely es-
timate is $15,000, and the pessimistic estimate is $21,000. What is the
PERT estimate and standard deviation?
E = ($5,000 + (4 * $15,000) + $21,000) / 6 = $14,333
𝞂 = (25 – 10) / 6 = $2,667
3. You are given a deadline of 15 days and a budget of $13,000 for Activity
A. What is the probability that you will achieve the time and cost ob-
jectives?
15 days is 1 day more than E. Divide 1 by 𝞼 (3), and get 0.3. 15 days is
equal to E + 0.3𝞼. According to the Z table, 0.3𝞼 = 61.79%.
$13,000 is $1,333 less than E. Divide $1,333 by 𝞼 ($2,667), and get
0.5. A budget of $13,000 is equal to E – .05𝞂, which equates to a 30.85%
chance of success.
4. For the path A B C, if the standard deviations are A = 4, B = 5,
and C = 7, what is the standard deviation of the path?
𝛔 = 42 + 52 + 72 = 16 + 25 + 49 = 90. The standard deviation of A B
C is the square root of 90, or 9.48, which we’ll round to 10.
EXERCISE 4–3 ESTIMATING REVIEW

1. How would you estimate the time required for Activity 1 (“Research”)?
Expert judgment. Find people who have conducted similar types of re-
search projects and develop an estimate based on their experience. You
might also use analogous estimating if you have done this kind of work
in the past.
2. How would you estimate the time required for Activity 3 (“Obtain Feed-
back”)?
Potential methods include analogous estimating (how long has it taken
in the past), or a variation on expert judgment (ask the people who will
provide feedback how long they think they’ll need).
3. How would you estimate the likely price of Activity 8 (“Obtain Outside
Trainer”)?
You could use analogous estimating if your organization has hired con-
sultants before, or expert judgment. Because prices may vary, you could
get preliminary estimates from three or more candidates and perform a
PERT calculation with the data.

4. How would you estimate the time required for Activity 6 (“Recruit
PMO Head”)?
Expert judgment from the HR department is the most obvious way.
Given that the time to hire is going to be a critical issue in making the
deadline, you might use the opportunity to negotiate with HR to see
how quickly they can do it. You probably would not want to use analo-
gous estimating, because that would use normal times, not expedited
processes.
5. How would you estimate how much it will cost for Activity 11 (“Prepare
Stockholder Presentation”)?
Analogous estimating or expert judgment would both work.
EXERCISE 5–1 SKILL REQUIREMENTS

The following skill list is based on our version of the PMO case study net-
work diagram from the answer to Exercise 3–5.
Internet research skills (Activity 1)
Policy development skills (Activities 2, 4)
Writing skills (Activities 2, 4, 11)
Project management skills (Activities 3, 10, 11)
Procurement skills (Activity 8)
Organizational development skills (Activity 5)
Human resources management skills (Activities 6, 7)
Presentation development skills (Activity 11)
EXERCISE 5–2 SKILL LIST

Comparing the skills and experience of the five candidates to the list we
developed in Exercise 4–3, we find:
Nguyen: Internet research (IT), presentations (PowerPoint)
Susan: Organizational development, human resources management
(both as HR generalist)
Gemma: Research (MBA), policy development (MBA, management
roles)
Jurgen: Policy development (shareholder relations), writing and
presentations (corporate communications)
Sean: Writing and presentations (newsletter), organizational
development, and human resources (HR)
We would probably ask for Gemma, Jurgen, and Sean. Notice the absence
of procurement skills among the candidates. This means we will probably
need help in that area, although Gemma is likely to have some experience
from her management roles.
Here’s a completed skills grid. Notice that some of the skill levels are
assumptions, so it’s okay if your answers do not completely agree.

Policy Project
Team Procure Org. Present
Research Develop Writing Manage HR
Member -ment Devel. -ation
-ment -ment
Nguyen E A A N N N N E
Susan A E A N A E E A
Gemma E E A A A E A A
Jurgen A E E N A N N E
Sean A E E N A E E E
Work maturity/skill levels codes: N (Novice), A (Average), E (Expert)
EXERCISE 5–3 RESPONSIBILITY ASSIGNMENT MATRIX
Research Jurgen Gemma Project Manager Project Manager
Write policy Sean Jurgen Project Manager Project Sponsor
Obtain feedback Project Manager Project Team Project Sponsor CEO

Project Manager,
Finalize policy Jurgen Gemma CEO
Sponsor
Develop org Project Manager,
Sean Jurgen, Gemma CEO
chart/PDs Project Sponsor
Recruit staff Sean HR Department Project Manager Project Manager
HR Department,
Hire staff Project Manager Project Sponsor CEO
Sean
Hire outside Gemma, Jurgen,
Project Manager Project Sponsor CEO
trainer Sean
Conduct training Consultant Project Team Project Sponsor CEO
Assign PMO to Project Sponsor, Jurgen, Sean,

Project Manager CEO
support project CEO Gemma
Stockholders’
Project Manager,
meeting Jurgen Sean CEO
Project Sponsor
presentation
Evaluation Project Manager Project Team Project Sponsor CEO

EXERCISE 5–4 CPM ANALYSIS

Total Total
Days Extra
Crash Activity Savings Time Cost
Saved Cost
Saved Saved
1 H 1 $50 $200 1 $200
2 B 5 $500 $750 6 $950
3 D 3 $375 $375 9 $1,325
41 F 4 $800 $200 13 $1,525
52 F, C 2 $400 $100 15 $1,625
Note 1. After the fourth crash, all activities are critical. Any further crashes
must be taken equally from both paths.
Note 2. After the fifth crash, there is still one available day to crash in Ac-
tivity F. However, the next cheapest combination (Activity F + Activity
G) will cost $275, which is more than our $250 value of early completion.
Total savings through CPM analysis: 15 weeks, $1,625.
The following is the final version of the network diagram.
Critical Path = 0 + 10 + 18 + 2 + 1 = 31
10, 10 18, 18 2, 1
$100 $125 $150
Activity A
Activity H
0, 0
1, 1
$0
$50
Activity C Activity E Activity G
9, 9 9, 7 12, 5
$50 $175 $125
Critical Path = 0 + 9 + 9 + 12 + 1 = 31

EXERCISE 5–5 COMMUNICATIONS AND STAKEHOLDER

MANAGEMENT PLAN
Stakeholder What the What we Communications Responsible
stakeholder need/want from Strategy Person
needs/wants the stakeholder
from us
CEO Keep stockholders Continued support, Weekly status Project manager
and stock analysts happy with summary, monthly
happy, demonstrate outcome, praise meeting, inform
improvement in and rewards for about major issues.
project project manager
management. and team.
Stockholders Reassurance that Improvement in High-quality Project manager,

and stock company is moving stock price, presentation at corporate
analysts forward in improved favorable analyst stockholders’ communications
project management reports, good meeting, reports and shareholder
and is responsive to mentions in the and other data to relations
stockholder needs. business press. analysts, evidence
of progress.
Project that Support and help Active embracing Choose project Project manager,
PMO is without feeling of the new work early, involve project CEO
assigned overburdened with group, help in manager in PMO
administrivia. making it planning
successful, good discussions, offer
project outcome. rewards for
cooperation and
performance.
Other managers A project outcome Lack of active Survey managers to Project manager
(especially the that doesn’t cause resistance, positive discover their main
skeptical ones) them to lose support, concerns, address
authority and power cooperation in concerns in plan,
and that improves implementing the brief managers
their success. new system. monthly.
EXERCISE 6–1 RISK TOLERANCE

Your answers to this exercise will vary, of course. In this example, we are de-
scribing each risk as a threshold rather than as “low,” “medium,” and “high”
to provide guidance in defining risk thresholds.

Risk Category Personal Risk Tolerance Organizational Risk Tolerance
Financial Risk I would invest up to $10,000 in The company would invest up to $1

high risk/high reward million in high risk/high reward
opportunities. opportunities.
Legal/Regulatory I am willing to drive up to 10 We will accept the risk of technical
Risk mph over the speed limit if I regulatory violations as long as the
am in a hurry.* potential consequences are less than
$50,000.
Risk of Being Sued I am not willing to risk being We accept the risk of lawsuits as a cost
sued. of doing business, and decide whether
to fight or settle depending on business
considerations.
Physical Safety Risk I am willing to play sports and We insist on compliance with all safety
to Self or Others engage in other outdoor programs and policies.
activities with a chance of
physical harm as long as I’m
having a good time.
Risk of Harm to the I don’t recycle.* We will comply with regulations
Environment regarding the environment.
Risk to Reputation My reputation is very Corporate reputation is an important

important to me and I do not business asset, but some risk is
want to risk damaging it. unavoidable if we are to be a forward-
looking organization.
Risks to Product Unless there’s a high payoff, Product quality is a characteristic we
Quality most things are okay if they’re can advertise, but we cannot afford to
“good enough.” make unprofitable products.
Publicity Risks I don’t want to be in the Controversy can increase company
limelight. visibility. As long as we’re on the right
side of the issues, we’re willing to take
the risk.
*These answers are common, but we don’t recommend them. It is important, however,
that you be honest with yourself on the risks you do and do not choose to accept.
EXERCISE 6–2 RISK IDENTIFICATION

1. Because we have no in-house experience in Project Management Of-
fices, the PMO we create may have deficiencies in its operation.
2. If the managers who have expressed some skepticism do not have their
issues addressed properly, they may actively oppose or put roadblocks
in the way of establishing our PMO.
3. If we cannot quickly find qualified people to staff our PMO, we may
not be able to make the stockholders’ meeting deadline.
4. If the PMO does not adequately address the issues and concerns of the
stock analysts, it will not cause our stock to rise.

5. If we don’t have a current project ready for PMO involvement, we will

not be able to demonstrate its performance in time for the stockholders’
meeting.
6. If the proposed PMO policy statement requires substantial revision,
there will be a significant delay on the critical path.
7. If we find high-quality templates or organizational material on building
PMOs that are applicable to our organization, we may be able to speed
the process significantly. (Opportunity risk)
8. Depending on the range of experience of the trainer/consultant we hire,
we may get the benefit of important insights that will add quality, or we
may receive inappropriate or incorrect advice that will lower quality.
(Business risk)
EXERCISE 6–3 QUALITATIVE RISK ANALYSIS

Risk from
Previous Probability Impact Risk Level Risk Triage Assignment
Exercise
Acceptance
1 – No
3 2 6 (high) (we don’t have it)/Act on the
experience
risk (get outside expertise)
Act on the risk
2 – Skeptical (listen to and address their
1 3 3 (medium)
managers concerns)/Transfer the risk
(get CEO involved)
Act on the risk (get it done
3 – Staffing
3 2 6 (high) early)/Transfer the risk
speed
(involve HR)
Transfer the risk
4 – Stock
1 3 3 (medium) (we aren’t in charge of
analysts
shareholder relations)
5 – No current Act on the risk

1 3 3 (medium)
project (locate a project early)
Act on the risk
6 – Needs (get early feedback)/Transfer
2 3 6 (high)
revision the risk (point out effect of
delay to reviewers)
Act on the risk
7 – Templates 2 3 6 (high)
(look for those templates)
Act on the risk
8 – Consultant 2 2 4 (medium) (research potential
consultants in depth)

EXERCISE 6–4 SENSITIVITY ANALYSIS
Case Pwinning Iwinning Plosing Ilosing Calculation
(0.3 x $1,000,000) + (0.7 x -$50,000) =

1 30% $1 million 70% -$50,000
$265,000
(0.1 x $1,000,000) + (0.9 x -$50,000) =

2 10% $1 million 90% -$50,000
$100,000 – $45,000 = $55,000
(0.3 x $500,000) + (0.7 x -$50,000) =

3 30% $500,000 70% -$50,000
$105,000
(0.1 x $500,000) + (0.9 x $50,000) =

4 10% $500,000 90% -$50,000
$50,000 – $45,000 = $5,000
5% $1,000,000 (0.05 x $1,000,000) + (0.25 x $250,000)

5 70% -$50,000 + (0.7 x -$50,000) = $50,000 + $62,500
25% $250,000 – $35,000 = $77,500
5%- $500,000 (0.05 x $500,000) + (0.1 x $250,000) +

6 85% -$50,000 (0.85 x -$50,000) = $25,000 + $25,000
10% $250,000 – $42,500 = $7,500
This investment appears very safe. Very large fluctuations in payoffs and prob-
ability still lead to an EMV that is positive. You might make only a little bit
of money, but it seems highly unlikely you will lose. Whether or not you make
the investment may rest on what options you have for your money.
EXERCISE 6–5 RISK RESPONSE PLANNING
Risk Category Strategy Residual/Secondary Risk
1 – No Mitigate We will hire a training A significant amount of residual

experience consultant who can also risk remains; the secondary risks
advise us, and we will do are that consultants cost money
research on PMOs. and we might not get great advice.
2– Mitigate/ We will mitigate the risks by Residual risk is fairly low, but the
Skeptical Transfer interviewing these managers secondary risk is that the CEO will
managers and attempting to address not think well of us if we must
their concerns. We will transfer invoke that help.
the remaining risk to the CEO
in case we encounter strong
resistance.

Risk Category Strategy Residual/Secondary Risk
3– Mitigate/ We will get position Hiring takes time, so residual risk is

Staffing Transfer descriptions ready early to significant. There is little secondary
speed give maximum time for risk.
staffing, and work with HR to
expedite the process.
4– Transfer We aren’t supposed to work The residual and secondary risks

Stock with stock analysts directly; we are mostly transferred along with
analysts have a director of shareholder the response.
relations.
5 – No Mitigate We will try to locate a suitable The residual risk is that the project
current project early. we select may not benefit
project immediately and measurably from
the PMO; the secondary risk is that
they (and other projects) may
resent outside interference.
6– Mitigate/ We will prepare the draft early Residual risk is low; secondary risk
Needs Transfer and only after consulting with is that we could create resentment.
Revision stakeholders about their
needs. If people are slow in
responding, we will ask the
CEO to make it a priority.
7– Exploit We will immediately search for Residual risk is low; secondary risk
Templates templates we might be able to is that we may pick a template that
use. isn’t suitable for our needs.
8– Mitigate/ We will research and interview The residual risk is that we could
Consultant Enhance consultants and check still get it wrong; the secondary risk
references carefully before is that these steps take extra time.
making a selection.
EXERCISE 6–6 FUNCTIONAL AND NONFUNCTIONAL

REQUIREMENTS
Risk Type (F or N)
The product will function at an operating temperature of 150° Celsius. Functional
The product will have an elegant user interface. Nonfunctional
The product will be safe for unskilled users. Nonfunctional
The product will fit inside a 20” x 40” x 60” box. Functional

Risk Type (F or N)
The product will use only ANSI standard materials. Functional
The product will pass UL inspection. Nonfunctional
The product will be lightweight and portable. Nonfunctional
EXERCISE 7–1 ANALYZING A TRACKING GANTT CHART

NOW
Planned Actual
Activity Predecessor Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10 Week 11 Week 12 Week 13 Week 14 Week 15 Week 16
Duration Duration
Activity A 0w 0w —
Activity B 2w 3w A
Activity C 2w 2w B
Activity D 1w 2w B
Activity E 2w 2w D
Activity F 2w 3w B
Activity G 3w 2w E
Activity H 3w F, G
Activity J 3w H
Activity K 2w E, G
Activity L 2w K
Activity M 0w J, L
Scheduled Milestone As of today, Activity F has taken two weeks. We estimate there is still one week of effort needed to finish.
Actual Forecast
Milestone
Forecast
The schedule forecast says the project will be completed one week behind
schedule.
EXERCISE 7–2 PROBLEM SOLVING

1. Consultant withdraws. (1) Solution 1: You should have had more than one
candidate under consideration for the job, so you shouldn’t have do to
the entire five-week process over again. Since you hired the consultant
five weeks in advance and the consultant pulled out two weeks later, if
you can get the replacement in three weeks, no problem. Solution 2: Al-
though the consultant needs to have a certain number of people trained
in time for the PMO launch, it’s not necessarily the case that everyone
needs to be trained that early. Some training could be safely moved until
after the stockholders’ meeting. (2) The idea that people can withdraw
from your project is a fairly common risk; it should have been consid-
ered. By ensuring that you have back-up people on your list, you can
reduce the replacement time. (3) This is a solvable problem; it should
not hamper finishing the project.

2. Major project in trouble. (1) Solution 1: This situation is a crisis for the
company, and they’re very lucky that your PMO project is already in
progress. Because of this major outside issue, you should talk to the
sponsor or CEO about whether a new approach that spends more money
is justified. Your initial budget was built on the assumption that the crisis
wasn’t immediate. It may now be desirable to increase the budget sub-
stantially and bring in more outside resources to assign to the project
emergency as well as to build the most effective PMO. Solution 2: You
could work with the corporate communications office to provide press
releases on the PMO work in progress as a counter to the press story
and continue the project as is. (2) If this wasn’t on your risk list, that’s
okay. It’s way outside the project scope. The exception would be if you
already knew that a troubled project was one of the motivators for the
PMO. In that case, escalating trouble on that project would be a high
risk. (3) This could be an opportunity as well as a threat—whether you
can fix all the problems with the troubled project or not, it’s a way of
getting the strongest possible support to make your PMO outstanding.
3. Project sponsor leaves. (1) Solution 1: Depending on the level of opposition
from skeptical managers, you might want to set up a meeting with the
CEO to arrange a new sponsor with appropriate power and influence.
Solution 2: You could ask the CEO to take direct action to support your
project over the objections of those skeptical managers. (2) Though the
departure of the sponsor might not be a risk you could have anticipated,
you already knew the risk from skeptical managers was high. Therefore,
you shouldn’t have been counting on the project sponsor to solve 100%
of the problem for you. Other steps in your risk plan, including outreach
to those managers and trying to address their concerns, should have re-
duced the problem. If their opposition is strong and ongoing, you would
have developed evidence to help persuade the CEO to take a stronger
personal stand. (3) This problem can be mitigated, but the skeptical
manager issue won’t go away and the transition of responsibility will
give you some problems no matter what.
EXERCISE 8–1 EARNED VALUE METRICS

1. EV = $8,000 (4 activities, $2,000 each)
PV = $10,000 (5 activities, $2,000 each)
AC = $9,500
2. EV = $23,500 ($8,000 + $4,000 + $9,000 + 50% of $5,000)
PV = $26,000 ($8,000 + $4,000 + $9,000 + $5,000)
AC = $22,000
3. EV = $15,000
PV = $10,000
AC = $12,500

EXERCISE 8–2 COST AND SCHEDULE VARIANCE

Problem 1
CV = EV – AC = $8,000 – $9,500 = -$1,500
SV = EV – PV = $8,000 – $10,000 = -$2,000
Problem 2
CV = EV – AC = $23,500 – $22,000 = $1,500
SV = EV – PV = $23,500 – $26,000 = -$2,500
Problem 3
CV = EV – AC = $15,000 – $12,500 = $2,500
SV = EV – PV = $15,000 – $10,000 = $5,000
EXERCISE 8–3 PERFORMANCE INDICES

Problem 1
CV = EV / AC = $8,000 / $9,500 = 0.84 = 84%
SV = EV / PV = $8,000 / $10,000 = 0.8 = 80%
Problem 2
CV = EV / AC = $23,500 / $22,000 = 107%
SV = EV / PV = $23,500 / $26,000 = 90%
Problem 3
CV = EV / AC = $15,000 / $12,500 = 120%
SV = EV / PV = $15,000 / $10,000 = 150%
EXERCISE 9–1 CLOSEOUT CHECKLIST

Certain closeout checklist items aren’t relevant to the PMO project, in-
cluding Items 6 and 8, probably Items 17 and 18, and Item 22. Because this
project has particular milestones (stockholder presentation, PMO starts
working on a real project), you could add a section labeled “Milestones”
and put some specifics there.
EXERCISE 9–2 IMPLEMENTING THE PMO

Although the project officially ends with standing up the new PMO and
preparing the stockholder presentation, the transition of the PMO to full
operational status could in some ways be considered a separate project, or
at least a separate phase—and it might be a good idea to treat it that way.
A PMO will necessarily go through a few bumps and alterations as it gains
maturity, so how will you ensure it gets the leadership direction it needs?
In our earlier discussion of the PMO, we thought that it might be a
good strategy to have the initial PMO focus primarily on project technical
support, growing into a greater leadership role as it develops. That’s an

example of how we think about implementation even at early stages of

project initiation and planning.
What other considerations matter? We know that one of our project
strategic weaknesses has been the lack of in-house PMO experience. That
suggests the importance of working on the job description of the manager
and hiring someone with significant PMO experience, but that won’t ad-
dress the internal “skeptical manager” issues. To address those, you might
think of proposing a “PMO Leadership Committee” that would involve the
participation of affected managers and project heads to provide this direc-
tion. You might propose a consultant-driven outside review of the PMO
after, say, six months or a year, to develop recommendations for change.
The specific suggestions are less important than the realization that
the job isn’t over just because the project is complete. It won’t really benefit
your organization to stand up a PMO that turns out to be ineffective. Re-
member that the very best time to work on implementation and transfer
is in early stages of scope definition and planning, when we have the great-
est potential opportunity to influence the outcome.
EXERCISE 9–3 LESSONS LEARNED QUESTIONS

What are some things we can salvage from the PMO project?
1. The research on how PMOs operate will be beneficial to the PMO staff.
2. The stockholder presentation, with slight modifications, can be used to
brief employees and managers on the new organization and its purpose.
3. The consultants we hire will gain some knowledge and understanding
of our organization, and can benefit us in the future.
4. The communications and stakeholder management plans give us a better
understanding of some of the organization’s important players and their
issues, and can be of benefit in the future.
5. In our risk management plan, the risks involving the quality and oper-
ation of the PMO will be useful to the PMO itself.
6. Comparing planned to actual estimates will improve the quality of future
estimates of similar work packages. Even though we won’t do this particular
project again, a number of the activities can show up in similar projects.
7. Risks and problems won’t merely affect the project, but also the ongoing
PMO. What have we learned that will be helpful to new PMO manage-
ment to help navigate the process of becoming fully operational?
8. Most change orders, we expect, will affect the PMO design and operation,
and those change orders will help the new PMO leadership understand
some of the organizational dynamics and issues they’ll need to deal with.
9. During the process of the project, the team will learn a lot about PMOs:
what works, what doesn’t, and what issues are common. This knowledge
will be useful in the PMO operation.
10. The overall historical files generated by the project will help PMO lead-
ership understand the origins of the new group so they can make better
decisions.

Appendix B: Glossary
Acceptance. A risk management strategy involving no action whatsoever

unless the risk actually occurs.
Activity. Something that must be completed in order to achieve your

project goals.
Actual cost (AC). In earned value management (EVM), how much we spent
for the work we have accomplished at this moment in the project.
Analogous estimate. An estimate based on the actual cost of a similar

project.
Assumptions. For planning purposes, assumptions are things we consider

to be true, real, or certain, without actual proof or demonstration. We might
assume that organizational priorities will not shift in the next six months, or
that the work is technically feasible even though it has not been done before.
Assumptions are often necessary, but carry risk.
Authority. The right to make decisions, spend funds, allocate resources,

or approve choices. Your authority can be defined in three categories: things
you can do without seeking permission, things you can do with permission,
and things that must be done by someone else.
Avoidance. A risk management strategy involving changing the project

so the risk event cannot occur or the project is protected from its conse-
quences.
Baseline. The approved project plan, plus or minus approved changes.

Use the baseline to compare actual to planned results so you can determine
if the project is on track. See performance management baseline (PMB).

Blamestorming. The process of figuring out who messed up rather than

how to fix the problem or keep it from recurring.
Bottom-up estimate. A detailed estimate based on rolling up estimates

for each individual project activity.
Budget at completion (BAC). In earned value management (EVM), the total

budget for the project.
Business risk. A risk situation that combines the possibility of positive

and negative outcomes for the same decision or event.
Change control board (CCB). A formal board that reviews and approves
technical changes to a project. See configuration management.
Change management. Identifying, documenting, approving (rejecting),

and controlling changes to the baseline. If change is not managed and con-
trolled, the result is scope creep.
Closeout. The formal process of bringing a project to an end.
Closeout checklist. A template to keep track of closeout activities and

requirements.
Co-location. The degree to which the members of your project team are
physically close to one another. Compare to virtual team.
Condition ➝ Consequence. A format for writing risk statements.
Configuration management. An advanced form of change management

for projects with extreme complexity and the potential for catastrophic ripple
effects. See change control board (CCB).
Constraint. A restriction, limitation, or barrier that limits your choices

and actions. The cost constraint (how much can I spend?), the time constraint
(how long do I have?), and the performance criteria (how good is “good
enough”?) form the triple constraints.
Contingency allowance. Extra time or money to compensate for known

risks.
Contingency plan. A risk management strategy involving a plan to be

triggered if the risk occurs or appears likely. Also called contingent response.
Contingency reserve. Money or time set aside for unknown risks.
Continuous improvement. The ongoing effort to improve the way in

which we perform work activities.

APPENDIX B: GLOSSARY 197
Corrective action. A reactive response to a problem or issue. See workaround.
Cost baseline. An “s-curve” chart showing cumulative project costs over

time.
Cost estimating. A process for determining the likely or potential cost

associated with a project or work package.
Cost of quality (COQ). The cost of improving quality compared to the

cost associated with poor quality.
Cost performance index (CPI). In earned value management (EVM), the

earned value (EV) divided by the actual cost (AC).
Cost variance (CV). In earned value management (EVM), the earned value
(EV) minus actual cost (AC).
Crash. The process of speeding up an activity by adding resources to it.

See critical path method (CPM).
Critical chain project management. An alternative to conventional proj-

ect management thinking with particular application to multiple project man-
agement. The critical chain method considers resource dependencies along
with precedence dependencies. The critical chain, therefore, unlike the crit-
ical path, can cut across project lines. Critical chain project management uses
buffers to control inherent project uncertainty.
Critical path. The sequence of project activities that determines the du-
ration of the project; the longest path through a project network diagram.
Critical path method (CPM). A method developed in the 1950s by

DuPont and Remington Rand to allow balancing of time, cost, and resources
for optimal project results.
Deadline. The date on which the project’s product, service, or result must
be completed. It is not necessarily the date of the last activity in a project.
Decision tree. A graphic display comparing one or more expected monetary

value (EMV) calculations.
Definitive estimate. An estimate based on a complete project plan.
Deliverable. A product, service, or result that must be produced to com-

plete a process, phase, or project. An external deliverable is normally provided
to a customer; internal deliverables are necessary for later steps in the same
project to occur.

Delphi technique. A technique of surveying different experts so that

their opinions do not affect one another.
Dependency relationship. A relationship among activities in a schedule

that determines when particular activities can start or finish.
Distribution. The range of possible outcomes and the number of times

each outcome has or is expected to occur.
Driver. The element of the triple constraint that is essential to success and
has the least flexibility
Duration. The amount of time an activity or project takes, measured in

work periods (not counting weekends, holidays, or other nonworking time).
Compare to effort.
Early finish. The early start plus the duration of an activity.
Early start. The earliest the activity can start considering its predeces-
sors.
Earned value (EV). In earned value management (EVM), how much we have
actually accomplished and how much we should have spent for that work at
a given point in the project.
Earned value management (EVM). An advanced tool for comparing

schedule and cost performance to plan. Considered an exceptionally valuable
tool for identifying troubled projects early.
Effort. The number of person-hours devoted to a specific task or work

package. Compare to duration.
Enhancement. A risk management strategy involving improving an op-

portunity’s probability or impact.
Estimate. A determination of the expected cost of the project based on

available information and history. See also WAG/SWAG.
Estimate at completion (EAC). In earned value management (EVM), how

much we estimate the complete project will end up costing based on perform-
ance to date.
Expected monetary value (EMV). A weighted total combining the dif-

ferent potential outcomes of a risk event.
Exploitation. A risk management strategy involving using an opportu-

nity to improve the project’s timeliness, cost, or quality.

Filtering. A process for analyzing risks.
Finish to finish (FF). A situation in which one activity can’t finish until
its predecessor has finished.
Finish to start (FS). A situation in which one activity can’t start until its
predecessor has finished.
Firefighting. A reactive form of multiple project management in which

projects start as the result of emergencies or system/product failures.
Float. Extra time to accomplish certain tasks before the accumulated

lateness threatens the expected project completion date. Synonym of slack.
See free float.
Forward and backward pass. A technique for calculating the critical path.
Free float. Extra time before the next task begins, whether the subsequent
task is on the critical path or not. See float.
Functional organization. Structuring the organization so that people are

grouped by areas of specialization.
Functional requirements. Statements that define some concrete element

of the product: how big it is, how fast it runs, how much it can hold. See re-
quirements and nonfunctional requirements.
Gantt chart. A bar graph drawn over a calendar grid, showing when spe-
cific tasks will be accomplished in the schedule.
Godzilla principle. The earlier you catch a risk, the greater the options
available to deal with it.
Grade. Technical characteristics such as materials used, number and type

of features, or fitness for particular uses.
Hierarchy of constraints. The order of driver, middle constraint, and weak

constraint that represents the priorities for achieving the triple constraints on
your project.
-ilities. See nonfunctional requirements.
Insurable risk. See pure risk.
Iterative activity. The process of developing the project and product

through a series of repeated cycles.
Kickoff meeting. The initial meeting that begins the actual project work.

Knowledge areas. In the PMBOK® Guide, knowledge areas are the iden-
tified areas of project management and the processes needed to perform them.
There are ten knowledge areas.
Lag. Additional time added to a dependency relationship.
Late finish. The latest the activity can finish without affecting the critical
path.
Late start. The late finish minus the duration of an activity.
Lead. Time subtracted from a dependency relationship.
Lessons learned. The process of evaluating a project’s performance for

future improvement.
Leveling. The process of balancing the workload and the resources avail-
able to do it.
Loading. The process of mapping work assignments to the network dia-

gram.
Matrix organization. A method of combining elements of functional and

projectized organizations to balance projects versus ongoing work efforts.
Milestone. A significant event in a project life cycle.
Mitigation. A risk management strategy involving lowering a combina-

tion of the risk’s likelihood or impact.
Monte Carlo simulation. A statistical technique of estimating durations

by simulating the project thousands of times using three-point estimates.
Network diagram. A flow chart picture of the work of the project that
shows interdependencies and connections.
Nonfunctional requirements. Statements that define some characteristic

of the product, service or result, often called “-ilities.”
Ongoing work effort. See operations.
Operations. Ongoing work efforts without a planned or intended ending.

Operations work is generally repetitive, following an organization’s existing
procedures.
Opportunity. A risk with a potential positive impact.

Parallel activity. An activity taking place at the same time as another ac-
tivity.
Parametric estimate. An estimate created using a statistical model.
Parkinson’s law. “Work expands so as to fill the time available for its com-
pletion.”
Performance management baseline (PMB). An integrated baseline of

cost, scope, and schedule used to track actual performance against the plan.
See baseline.
Phase. A portion of a project that achieves the completion of one or more

deliverables.
Planned value (PV). In earned value management (EVM), how much we

should have accomplished and how much we should have spent at a given
point in the project.
Portfolio. A collection of projects or programs and other work that are

grouped together to facilitate effective management of that work to meet
strategic business objectives. The projects and programs in a portfolio are not
necessarily independent or directly related.
Portfolio management. The centralized management of one or more

portfolios, including identifying, prioritizing, authorizing, managing, and con-
trolling projects, programs, and other related work to achieve specific strategic
business objectives. It focuses on ensuring that projects and programs are re-
viewed to prioritize resource allocation, and that the management of the port-
folio is consistent with and aligned to organizational strategies.
Preliminary estimate. An estimate based on a written statement of work

(SOW) but not a complete project plan.
Probability. The number of desired outcomes divided by the number of

possible outcomes.
Probability and impact matrix. A tool used in qualitative risk analysis to

classify and rank risks.
Process group. One of the stages in the project life cycle. The process
groups are project initiation, project planning, project execution, project man-
agement and control, and project closeout.
Process quality. Analyzing and improving the methods by which we do

project work.

Product quality. The extent to which our project’s “product, process, or

result meets the needs of our stakeholders.
Program. A group of related projects managed in a coordinated way to

obtain benefits and control not available from managing them individually.
Projects within a program are usually related by a common outcome or col-
lective capability.
Program evaluation and review technique (PERT). Invented by the US

Navy and Booz Allen Hamilton to manage the Polaris nuclear submarine
project in the late 1950s, the PERT method is considered one of the major
breakthroughs in project management practice. In the area of risk manage-
ment, PERT pioneered the use of the three-point estimating technique.
Program management. The centralized coordinated management of a

program to achieve its strategic objectives and benefits. Program management
focuses on project interdependencies to determine the optimal approach for
managing them.
Progressive elaboration. Iteratively increasing the level of detail in a

project management plan as more information becomes available.
Project. A temporary endeavor undertaken to create a unique product,

service, or result. Projects have a definite beginning and end.
Project charter. The document that that formally authorizes the exis-
tence of a project and gives the project manager working authority to proceed,
whether it’s a memo, an email, or a contract. It doesn’t matter if the project
charter is labeled “project charter” or not.
Project closeout. The process of ensuring that the project deliverables

have been satisfactorily accomplished and transferred to their new owners,
that project team members and other resources are released to do other work,
and that the necessary paperwork is done and archived.
Project communications management. The process of planning and ex-

ecuting the preparation and dissemination of project information to stake-
holders.
Project cost management. The process of determining how costs will be

planned, structured, and controlled, and the management of cost and budget
issues through the project life cycle.
Project execution. The process of performing and completing the re-

quired project work.

Project human resources management. The process of determining and

managing the roles, responsibilities, and reporting relationships of the people
on a project.
Project initiation. The process of defining a potential project, determin-

ing how much it is likely to cost and how long it is likely to take, and deciding
who will lead the project and who will staff it.
Project integration management. The processes and activities to iden-

tify, define, combine, unify, and coordinate the various project management
activities.
Project life cycle. The stages of a given project. May be general or spe-
cific to the needs of the project.
Project management. The application of knowledge, skills, tools, and

techniques to project activities to meet the project requirements.
Project management office (PMO). An internal group that standardizes

project management processes and facilitates the sharing of resources,
methodologies, tools, and techniques.
Project monitoring and control. The processes of tracking, reviewing,

and regulating project performance.
Project planning. The tools and processes necessary to define, organize,

and develop the course of action that will accomplish the project goals.
Project procurement management. The processes of making “make or

buy” decisions, identifying potential vendors or buyers, preparing proposals
and soliciting bids, selecting and awarding contracts, and managing the pro-
curement relationship.
Project quality management. The processes of determining and man-

aging the quality efforts on a project.
Project risk management. The processes of establishing risk manage-

ment policies and systems, identifying risks, analyzing and prioritizing those
risks, developing responses and strategies to deal with them, and monitoring
and controlling the risk environment throughout the project.
Project scope. All the work necessary to complete the project, and no
more.
Project sponsor. The manager or executive, usually internal, with over-

sight responsibility for the project.

Project stakeholder management. The process of identifying people or

groups that could impact or be impacted by the project and develop appro-
priate management strategies for them.
Pure risk. A risk situation that only has a negative outcome (also known
as insurable risk).
Qualitative risk analysis. The process of ranking risks according to prob-

ability and impact.
Quality. The extent to which the project’s product, service, and result
satisfies the needs for which it was undertaken.
Quality assurance/quality control (QA/QC). The processes of manag-

ing project and product quality.
Quantitative risk analysis. The process of using measurable and objec-

tive data to value risks.
Requirement. A condition or capability that must be in the final product,

service, or result.
Requirements traceability matrix. A grid linking requirements to their

appropriate deliverables.
Reserve. See contingency reserve.
Residual risk. Risk left over after you have taken action on the primary
risk.
Resource leveling. Adjusting schedule and resources to ensure project

work can be accomplished.
Resource loading. Determining resources required to accomplish project

work in a given time period.
Resource scheduling. Assigning specific resources to specific work pack-

ages.
Responsibility assignment matrix (RAM). A tool to ensure all project

roles are identified and assigned.
Risk. An uncertain event or condition that if it occurs will have a signif-

icant impact, whether negative (threat) or positive (opportunity). The funda-
mental formula of risk is R = P x I (probability times impact).

Risk analysis. The process of studying the risks of a particular project,

operation, or organization in order to define their probability, impact, and
other characteristics. The results of risk analysis help us decide which risks
should be addressed, which risks should be accepted, and which strategies are
likely to be most cost-effective in managing them.
Risk appetite. Willingness to accept opportunity or business risk.
Risk identification. The process of identifying and describing the risks

associated with the project.
Risk management. The process of identifying, analyzing, responding to,

and managing threats and opportunities.
Risk management plan. A document that is part of the project plan and
that identifies and describes the risks, rates their relative seriousness by con-
sidering their probability and impact, lists any planned responses or actions
intended to reduce downside risks or improve upside risks, and explains how
the project team will monitor risks and responses for effectiveness.
Risk management policy. A document that applies to an entire organi-

zation or category of projects. It describes how the organization wants risk
management to be performed, which projects and activities are covered by
the policy, the definitions and steps involved in the process, the types of re-
ports and documents that need to be prepared and disseminated, who must
be consulted or who must approve risk responses, and similar matters.
Risk mitigation cost. What you would need to spend to reduce the risk to an
acceptable level.
Risk monitoring and control. Activities involved in executing the risk

management plan and making adjustments based on actual experience.
Risk premium. The difference between the cost of responding to a risk

and the underlying value of the risk itself.
Risk reassessment. The process of reviewing risks from the project plan
in light of actual project information.
Risk register. A document that consolidates all project risk information.
Risk response planning. The process of deciding what action (if any) to
take in response to a specific risk or category of risk.
Risk threshold. The level above which we are not willing to accept risk
in a particular category.

Risk tolerance. The amount of risk we are willing to accept in a partic-

ular category.
Risk triage. A process of sorting risks by the nature of response.
Rolling wave estimate. An estimate iterated during the project life cycle
as more information becomes available.
Rough order of magnitude (ROM). An estimate used by decision-makers

to decide if a project will be undertaken at all.
Schedule compression. Techniques to reduce total project time.
Schedule performance index (SPI). In earned value management (EVM),

the earned value (EV) divided by the planned value (PV).
Schedule variance (SV). In earned value management (EVM), the earned

value (EV) minus planned value (PV).
Scope creep. Uncontrolled and unmanaged growth of project scope over

time. Something to be avoided.
Scope management. The knowledge area involving the processes of de-

veloping and managing the project scope.
Scope statement. A document in narrative form that summarizes the

work to be done on a project.
Scope verification. Ensuring the work is done and meets requirements.
Secondary risk. A risk that comes into existence as a result of your at-
tempt to solve the original risk.
Sensitivity analysis. The study of how the variation (uncertainty) in the

output of a mathematical model can be apportioned, qualitatively or quanti-
tatively, to different sources of variation.
Sharing. A risk management strategy involving transferring the value of

an opportunity elsewhere.
Slack. See float.
Spend plan. The accumulated planned expenditures of your project over

time.
Stakeholder. A person or a group who may affect or be affected by a de-

cision, activity, or outcome of a project.

Standard deviation (𝛔). A mathematical measurement of the variance in

a given normal distribution. In PERT calculations, the standard deviation for-
mula is 𝛔 = (P – O) / 6.
Start to start (SS). A situation in which one activity can’t start until its
predecessor has started.
Statement of work (SOW). A short narrative summary of the project and

the work to be accomplished.
Status reporting. Processes that gather information about the current

state of the project.
Threat. A risk with a potential negative impact.
Three-point estimate. The technique of creating separate estimates

based on optimistic, pessimistic, and most likely situations.
Time management. The knowledge area involving the processes of de-

veloping and managing the project schedule.
Tracking Gantt chart. A Gantt chart showing the planned schedule

compared to actual performance.
Transfer. In risk management, a strategy involving moving the ownership

of the risk to some other entity. In project closeout, the transfer of the product,
service, or result to its new owner.
Trigger. A description of the circumstances that tells us to put a partic-

ular contingency plan into effect.
Triple constraints. The three common boundaries of all projects: the

time constraint, the cost (resources) constraint, and the performance standard.
Value of early completion. The payoff for finishing a project early. See
critical path method (CPM).
WAG/SWAG. “Wildly aimed guess” and “scientific wildly aimed guess,”

respectively.
WBS. See work breakdown structure (WBS).
WBS dictionary. A form or template for each WBS component that

briefly defines the scope or statement of the work, defines deliverables, con-
tains a list of associated activities, and provides a list of recognized milestones
to gauge progress. See also work management form.

Weak constraint. The element of the triple constraint with the greatest
flexibility.
Work. The combination of projects and operations that make up your

area of responsibility.
Workaround. A reactive response to a problem or issue. See corrective ac-

tion.
Work breakdown structure (WBS). A hierarchical decomposition of the

total scope of work to be carried out by the project team to accomplish the
project objectives and create the required deliverables.
Work management form. See WBS dictionary.
Work package. Something specific that must be accomplished as part of

achieving your project goal. May be broken down into activities.
Z table. A statistical table of achieving a given result expressed in terms

of the standard deviation.

Appendix C:
Bibliography and Recommended Reading
Budd, Charles I. and Charlene S. Budd. A Practical Guide to Earned Value Project
Management. Vienna, Virginia: Management Concepts, 2005.
Crosby, Philip B. Quality Is Free: The Art of Making Quality. New York: Mentor,
1980.
Darmody, Peter B., PSP. “Henry L. Gantt and Frederick Taylor: The Pioneers
of Scientific Management.” AACE International Transactions, 2007, pp. 15.1–
15.3.
Dobson, Michael. Project: Impossible: How the Great Leaders of History Identified,
Solved, and Accomplished the Seemingly Impossible—and How You Can Too! Oshawa,
Ontario: Multi-Media Publications, 2013.
Dobson, Michael S. Streetwise Project Management: How to Manage People, Processes,

and Time to Achieve the Results You Need. Avon, Massachusetts: Adams Media
Corporation, 2003.
Dobson, Michael. Watergate Considered as an Org Chart of Semi-Precious Stones.

Bethesda, Maryland: Timespinner Press, 2003.
Dobson, Michael and Deborah Singer Dobson. Managing Multiple Projects

(AMACOM). New York: AMACOM, 2011.
Dobson, Michael and Deborah Singer Dobson. Project Risk and Cost Analysis
(AMACOM). New York: AMACOM, 2012.
Dobson, Michael S. and Heidi Feickert. The Six Dimensions of Project Manage-
ment: Turning Constraints Into Resources. Vienna, Virginia: Management Con-
cepts, 2007.

Dobson, Michael S. and Ted Leemann. Creative Project Management: Innovative

Project Options to Solve Problems On Time and Under Budget. New York: McGraw-
Hill, 2010.
Drucker, Peter F. Management: Tasks, Responsibilities, Practices. New York: Harper

& Row, 1973.
Goldratt, Eliyahu M. Critical Chain. Great Barrington, Massachusetts: North

River Press, 1997.
Gruebl, Tony and Jeff Welch. Bare-Knuckled Project Management. Arlington, Vir-
ginia: Gameplan Press, 2013.
Kerzner, Harold. Project Management: A Systems Approach to Planning, Scheduling,

and Controlling, 9th Edition. Hoboken, New Jersey: John Wiley & Sons, 2006.
Kozak-Holland, Mark. The History of Project Management. Oshawa, Ontario:

Multi-Media Publications, 2011.
Kuehn, Ursula, PMP. Integrated Cost and Schedule Control in Project Management.
Vienna, Virginia: Management Concepts; 2006.
Kwak, Young Hoon and Lisa Ingall, “Exploring Monte Carlo Simulation Ap-
plications for Project Management,” Risk Management (2007) 9, 44–57.
doi:10.1057/palgrave.rm.8250017
Leach, Lawrence P. Critical Chain Project Management. Norwood, Massachusetts:

Artech House, Inc., 2000.
Miller, Michael J. InfoWorld, April 18, 1988. Vol. 10, No. 16, p. 64.
Mooz, Hal, PMP, Kevin Forsberg, and Howard Cotterman. Communicating Proj-
ect Management: The Integrated Vocabulary of Project Management and Systems En-
gineering. New York: John Wiley & Sons, 2003.
Oracle Corporation. “Project Management Office Best Practices: A Step-by-

Step Plan to Build and Improve Your PMO.” White paper, April 2009. Re-
trieved from http://www.oracle.com/oms/eppm/project-magament-pmo-
wp-302976.pdf, July 30, 2013.
Parkinson, C. Northcote. Parkinson’s Law: The Pursuit of Progress. London, Eng-

land: John Murray, 1958.
Project Management Institute. A Guide to the Project Management Body of Knowl-

edge (PMBOK® Guide), 5th Edition. Newtown Square, Pennsylvania: Project Man-
agement Institute, 2013.

APPENDIX C: BIBLIOGRAPHY 211
Royer, Paul S. Project Risk Management: A Proactive Approach (Project Management

Essential Library). Vienna, Virginia: Management Concepts, 2002.
US Department of Transportation, Research and Special Programs Admin-

istration. “Effects of Catastrophic Events on Transportation System Manage-
ment and Operations: Northridge Earthquake, January 17, 1994.” Report,
submitted April 22, 2002. Retrieved from http://ntl.bts.gov/lib/jpodocs/
repts_te/13775.html on 5 August 2013.
US Food and Drug Administration, Center for Drugs and Biologics. “Guide-
line for the Format and Content of the Summary for New Drug and Antibiotic
Applications.” Rockville, Maryland: Office of Training and Communications;
1987. Retrieved from http://www.fda.gov/downloads/Drugs/GuidanceCom
plianceRegulatoryInformation/Guidances/UCM072058.pdf, 31 July 2013.

Appendix D:
Additional Resources
In addition to the many fine books (some listed in the bibliography) and sem-
inars available from a variety of sources, the Web is a rich source of informa-
tion on project management. The following list is not intended to be
comprehensive, and new resources appear on the Web all the time.
American Management Association
http://www.amanet.org
Earned Value Management:
Tutorial: http://www.tutorialspoint.com/earn_value_management/
Wikipedia:
http://en.wikipedia.org/wiki/Earned_value_management
Sidewise Insights (Michael Dobson, PMP)
http://sidewiseinsights.com
http://sidewiseinsights.blogspot.com
http://www.twitter.com/SideWiseThinker
Requirements Template Examples
www.hud.gov/offices/cio/sdm/devlife/tempchecks/frtemplate.doc
http://web.mit.edu/ssit/cis/CISRequirements.html
Risk Management Information

Department of Defense Acquisitions Community:
https://acc.dau.mil/CommunityBrowser.aspx?id=108201
NASA:
http://www.hq.nasa.gov/office/hqlibrary/ppm/ppm22.htm

Hulett & Associates:

http://www.projectrisk.com/Welcome/White_Papers/
white_papers.html
http://office.microsoft.com/en-us/templates/project-risk-
management-plan-TC001145558.aspx
Microsoft:
http://office.microsoft.com/en-us/templates/project-risk-
management-plan-TC001145558.aspx
Risk Management Policy and Planning Templates

Ethics and compliance risks:
http://www.ethics.org/files/u5/LRNRiskManagement.pdf
Information security risks:
http://www.sans.org/security-resources/policies/
Public safety/environmental health and safety/disaster preparedness:
http://policies.csusb.edu/riskmgmt.htm
Sport and recreation:
http://www.scribd.com/doc/31691777/Guide-to-using-SPARC’s-
Risk-Management-Tookit
Hazardous materials:
http://www.fpaa.com.au/licencing/docs/Risk_Management_
Planning_Tool.pdf
Project management information:
http://en.wikipedia.org/wiki/Project_management
http://www.projectmanagement.com/
http://www.achievemax.com/books/project-management/
index.htm
Project Management Institute (PMI):
http://www.pmi.org
Project Management Professional (PMP) Certification:
http://www.pmi.org/Certification.aspx

APPENDIX D: ADDITIONAL RESOURCES 215
Network Diagramming Methods

Arrow diagramming:
http://en.wikipedia.org/wiki/Arrow_Diagramming_Method
Precedence diagramming:
http://en.wikipedia.org/wiki/Precedence_Diagram_Method
Monte Carlo Simulation Software for Microsoft Project
@RISK for Project from Palisade Corporation: www.palisade.com
RiskyProject from Intaver Institute: www.intaver.com
Pertmaster software from Pertmaster Limited: www.pertmaster.com
Risk+ from S/C Solutions Inc.: www.cs-solutions.com
Quality Resources
The Basics of Project Quality Management:
http://blogs.attask.com/the-basics-of-project-quality-
management/
Project Quality Management Plan Template:
http://www.itplanning.org.vt.edu/pm/qualitymgmtplan.html
Measuring and Managing Project Quality:
http://sinche.uom.gr/sites/default/files/managingquality.pdf

Post-Test

Fourth Edition
Course Code 98004

INSTRUCTIONS: To take this test and have it graded, please email AMASelfStudy
@amanet.org. You will receive an email back with details on taking your test and get-
ting your grade.
FOR QUESTIONS AND COMMENTS: You can also contact Self Study at 1-800-225-3215
or visit the website at www.amaselfstudy.org.
1. In a PERT analysis, what is the probability that an activity will be

completed no later than the PERT estimate?
(a) 50.00%
(b) 84.13%
(c) 15.87%
(d) 61.79%
2. The triple constraints include:

(a) risk, quality, and procurement.
(b) time, risk, and quality.
(c) time, cost, and quality.
(d) time, cost, and performance.

3. A critical path activity can be compressed from eight weeks to four

weeks at a cost of $1,000 per week. The available float on the parallel
path is two weeks. There is a $1,200 bonus for each week early. How
would you crash this project?
(a) Crash four weeks from the critical path activity.
(b) Do not crash; it’s not financially appropriate.
(c) Crash two weeks from the critical path activity.
(d) Crash both critical and noncritical paths two weeks.
4. Which of the following is a step in project closeout?
(a) Charter
(b) Quality assurance
(c) Transfer
(d) Baseline
5. Which project management process includes activities needed to
define a new phase of an existing project?
(b) Project planning
(c) Project transfer
(d) Project initiation
6. What project management tool links resources to activities?
(a) WBS
(b) RAM
(c) PERT
(d) EVM
7. A particular business opportunity requires an investment of $150,000,
and has a 70% chance of success. If it succeeds, you will earn $275,000,
but if the investment fails, you will lose your entire investment. What is
the expected monetary value?
(a) $275,000
(b) -$150,000
(c) $125,000
(d) $147,500
8. What is a characteristic of a well-written requirement?
(a) Condition → Consequence
(b) Described in the project charter
(c) Unambiguous and verifiable
(d) Exists as a work package in the project’s WBS
9. The technique of adjusting your estimates as the project moves forward to
take advantage of improved knowledge and understanding is known as:
(a) the Monte Carlo simulation.
(b) the earned value method.
(c) rolling wave estimating.
(d) the program evaluation and review technique.

POST-TEST 219
10. Look at the WBS that follows this question. How is it organized?
(a) By department or work group
(b) By phase
(c) By cost account
(d) By difficulty or risk
Develop a Course
Design

Site Materials
Ship Materials to
Seminar Location

Market Course
Feedback Speakers
Finalize Course
11. For a particular activity, we determine that optimistically it will take 6

weeks, pessimistically it will take 30 weeks, but it will most likely take
12 weeks. What is the PERT estimated time and the standard
deviation?
(a) E = 12, 𝛔 = 6
(b) E = 14, 𝛔 = 4
(c) E = 8, 𝛔 = 4
(d) E = 30, 𝛔 = 12
12. An analogous estimate is considered accurate if the final project cost is

within the range:
(a) -25%, +100%.
(b) -10%, +25%.
(c) -5%, +10%.
(d) -5%, +0%.
13. The extent to which the project’s product, service, and result satisfy the
needs for which it was undertaken is known as:
(a) quality.
(b) scope.
(c) risk.
(d) WBS.

14. Look at the following network diagram. What is the critical path?
(a) A→B→D→H
(b) A→E→C→D→H
(c) A→E→F→G→H
(d) A→C→H
Activity B Activity D
4 days 3 days
Activity A Activity C Activity H

6 days 9 days 4 days
Activity E Activity F Activity G

2 days 3 days 1 day
15. Today, we were supposed to have completed four activities that were
planned to cost $2,500 each. We have actually accomplished only three
of those activities and we have spent $7,000 to date. In earned value
method terms, what is our cost performance index, rounded to the
nearest whole percent?
(a) 93%
(b) 107%
(c) 75%
(d) 133%
16. What document formally authorizes the existence of a project and

gives the project manager working authority to proceed?
(a) Project scope statement
(b) Project authorization document
(c) Project plan
(d) Project charter
17. What is “the application of knowledge, skills, tools, and techniques to

project activities to meet the project requirements”?
(b) Program evaluation and review technique
(c) Project management
(d) Iterative planning
18. What performance measurement baseline can serve as a metric for all
three triple constraints?
(a) Cost baseline
(b) Responsibility assignment matrix
(c) Tracking Gantt chart
(d) Weekly status reports

POST-TEST 221
19. The fundamental formula for risk is:

(a) P x I
(b) (O + 4M + P) / 6
(c) EV – AC
(d) BAC / CPI
20. How frequently should you hold status meetings or require status
reports?
(a) Preferably weekly, but no less often than monthly
(b) Whenever a problem or issue arises
(c) When the project sponsor or customer need an update
(d) Varies based on the speed of change within the project
21. What is defined as a “hierarchical decomposition of the total scope of

work to be carried out by the project team to accomplish the project
objectives and create the required deliverables”?
(a) Responsibility assignment matrix
(b) Work breakdown structure
(c) Critical path
(d) Project charter
22. What is one piece of information that should be included in a

communications and stakeholder management plan?
(a) To whom stakeholders report
(b) Ways to get around difficult stakeholders
(c) Stakeholder leadership roles in the project
(d) What we need/want from the stakeholder
23. The process of prioritizing risks for further analysis or action by

assessing and combining their probability of occurrence and impact is
known as:
(a) quantitative risk analysis.
(b) risk response planning.
(c) decision tree analysis.
(d) qualitative risk analysis.
24. What is a constraint?

(a) Something that limits your choices
(b) Something considered true for planning purposes
(c) Just the three elements of time, cost, and performance
(d) One of the nine knowledge areas of project management

25. You have identified a risk that the price of raw materials you need for
the project could potentially double in price by the time you would
normally purchase them. You decide you will buy the materials far in
advance of need to lock in the price. What risk response strategy have
you used?
(a) Avoid
(b) Mitigate
(c) Transfer
(d) Contingency plan

Index
AC (actual cost), 147–149, 195 in defining the project, 33–34 buy-in, obtaining, 37
acceptance, of risk, 114–115, 195 definition of, 195
activity(-ies) in project initiation, 8 Canceled projects, 10
assigning team members to, 81 recognizing, 33 CCB (change control board),
definition of, 195 authority, 195 133, 196
double-booked, 85–86 avoidance, of risk, 112, 195 CCPM (critical chain project
estimating, see estimating management), 74, 197
activities BAC (budget at completion), celebration, at project closeout,
finalizing, 158 196 158, 162–163
parallel, 51, 201 backward pass, 55–58, 199 change control board (CCB),
planning, see planning baseline(s) 133, 196
activity(-ies) cost, 126–128, 197 change log, 130
in project time management, definition of, 195 change management, 10, 124,
11 definitive estimates as, 69 130, 133, 196
in responsibility assignment and IPMA Competence change management system, 130
matrix, 84 Baseline certification, 2 change requests, 130
activity list, constructing, 50–52 performance management, checksheets, 146
“activity on arrow,” 50 124–126, 201 Chrysler, 161
“activity on node,” 50 schedule, 125–126 closeout, 196, see also project
actual cost (AC), 147–149, 195 updating, 153 closeout
actual cost of work performed BCWP (budgeted cost of work closeout checklist, 159–160, 196
(ACWP), 148 performed), 148 co-location, 196
Adamiecki, Karol, 2 Bell Telephone, 117 communications and stakeholder
administrative closeout, 158, 162 benchmarking, 119 management plan, 90–92,
Alesia, Battle of, 2 biases, of experts, 68 145
American National Standards blamestorming, 163, 196 communications management,
Institute (ANSI), 3 Booz Allen Hamilton, 2 see project communications
analogous estimates, 67, 195 bottom up approach (WBS), 48 management
APM (Association for Project bottom-up estimates, 68–69, 196 competitors, as stakeholders, 26
Management), 2 budget, closing, 162 condition consequence, 196
Apollo 13 rescue, 116 budget at completion (BAC), 196 configuration management, 133,
approval, obtaining, 37 budgeted cost of work 196
Association for Project performed (BCWP), 148 constraints
Management (APM), 2 buffers, 74 in defining the project, 29–32
assumptions business risks, 16, 97, 98, 196 definition of, 196

hierarchy of, 30–33, 66, 199 critical path method (CPM), 2, 152, 198
interplay of, 96 88, 197 early finish, 45, 55, 87, 198
in project initiation, 8 critical path method (CPM) early start, 55, 198
ranking, 31 analysis, 87–90 earned value (EV), 147–149
triple, 29–30, 96, 207 Crosby, Philip, 119 advanced, 152
contingency allowance, 13, 74, C/SCSC (Cost/Schedule applying, 151
109, 196 Control Systems Criteria), cost baseline in, 127
contingency plans, 114, 134, 196 147 definition of, 198
contingency reserve, 13, 196 customers earned value management
contingent response, to risk, 114 communication needs of, 13 (EVM), 147–153
continuous improvement, 15, as stakeholders, 25 cost and schedule
117, 196 CV (cost variance), 150, 197 performance indices in, 151
continuous process cost variance and schedule
improvement, 117 Deadline, 10–11, 158, 197 variance in, 150
contract closure, 158, 161–162 decision node, 110 definition of, 198
contracts log, 161 decision trees, 110–111, 197 planned value, earned value,
control, see project monitoring defining projects, 21–38 and actual cost in, 147–149
and control assumptions in, 33–34 effort, 198
control charts, 146 constraints in, 29–32 Eiffel, Gustave, 2
COQ (cost of quality), 119, 197 and obtaining approval and EMV (expected monetary
corrective actions, 134, 197 buy-in, 37 value), 108–110, 198
cost progressive elaboration and end users, 26
actual, 147–149, 195 project objective in, 37 enhancement, 113, 198
balancing time, resources, and, and project charter, 34–36 estimate at completion (EAC),
87–90 project initiation in, 23 152, 198
budgeted, 148 and projects vs. phases of estimates
PERT calculations for, 71 projects, 23–24 adjusting, 69
risk mitigation, 205 and reasons for projects, 22 definition of, 198
cost baseline, 126–128, 197 stakeholder considerations in, evolution of, 80
cost-benefit analysis, 119 24–28 three-point, 207
cost constraint, 29 definitive estimates, 67, 69, 197 estimating activities, 65–76
cost estimating, 197 deliverables, 50, 197 issues in, 74
cost management, 13, 202 Delphi technique, 68, 198 methodologies for, 67
cost of quality (COQ), 119, 197 department-based WBS, 45, with Monte Carlo simulation,
cost performance index (CPI), 47–48 73
151, 197 dependency relationships, with PERT, 70–72
Cost/Schedule Control Systems 52–53, 198 standard techniques for, 67–69
Criteria (C/SCSC), 147 design of experiments (DOE), three-point, 69–73
cost variance (CV), 150, 197 119 uncertainty in, 66
CPI (cost performance index), destructive testing, 147 EV, see earned value
151, 197 distribution, 198 EVM, see earned value
CPM, see critical path method documentation management
CPM (critical path method) of contracts, 161 execution, see project execution
analysis, 87–90 of lessons learned, 163 expected monetary value
crash, 197 of procurements, 161, 162 (EMV), 108–110, 198
crash cost, 88 of requirements, 15, 43–44 experiments, 119
crash duration, 88 retention policies for, 162 expert judgment, 68
crashing projects, 88–91 DoD (US Department of exploitation, of risk, 113, 198
critical chain project Defense), 147
management (CCPM), 74, DOE (design of experiments), Failed projects, 164
197 119 filtering, 199
critical path drivers, 30–32, 198 finish to finish (FF), 54, 199
definition of, 197 DuPont Corporation, 2, 88 finish to start (FS), 54, 199
determination of, 53–54 duration, 198 firefighting, 199
in network diagramming, float, 53, 88
58–60 EAC (estimate at completion), definition of, 199

INDEX 225
free, 58, 59, 199 Kennedy, John F., on forward and backward pass in,
in network diagramming, commitment to goal, 30 55–58
58–60 kickoff meeting, 129, 199 project layout in, 52–53
forward and backward pass, knowledge areas, 11–18, 200 scheduling relationships in, 54
55–58, 199 NIH (Not Invented Here)
free float, 58, 59, 199 Lag, 54, 200 syndrome, 163
FS (finish to start), 54, 199 late finish, 55, 200 Nixon, Richard, 37
functional organizations, 6, 199 late start, 55, 200 nondestructive testing, 147
functional requirements, 118, lead, 54, 200 nonfunctional requirements, 118,
199 lessons learned, 10, 117 200
definition of, 200 Northridge earthquake, 87
Gaius Julius Caesar, 2 documenting, 162 Not Invented Here (NIH)
Gantt, Henry, 2 in project closeout, 158, syndrome, 163
Gantt chart, 60–62 163–165
definition of, 199 leveling (term), 200, 204 OMB (US Office of
from network diagrams, 49 leveling the schedule, 85–86 Management and Budget),
origin of, 2 Liddy, G. Gordon, 37 147
tracking, 207 loading (term), 200, 204 one hundred percent rule, 49
goals loading the schedule, 85–86 ongoing work efforts, 3, 200
quality, 66 operations, 3, 200
for stakeholder and Make or buy decisions, 86, 87 opportunities
communication management, as scientific definition of, 16, 200
management, 90 discipline, 2 as positive risk, 16, 97
Godzilla principle, 199 managers, as stakeholders, 25, 26 risk responses for, 110–112
Godzilla Principle (Dobson), 97 matrix organizations, 7, 200 optimistic estimates, 70, 71
grade, 118, 199 McNeil, 164 organizational structure, 6–7
grading policy, xvi mean time between failures org chart format (WBS), 45, 46
groupthink, 68 (MTBF), 147 outline format (WBS), 45, 46
guesses, 67 Microsoft Project®, 73, 125, 152 outsourcing, 86–87
A Guide to the Project Management middle constraints, 31–32 overoptimism, in estimating, 74
Body of Knowledge (PMBOK® milestones, 56, 143, 145, 200
Guide), 3, 23, 100 Miller, Michael J., on project Parallel activities, 51, 201
management, xiii parametric estimates, 68, 201
Hierarchy of constraints, 30–33, mitigation, risk, 112, 200 Pareto diagrams, 146
66, 199 monitoring and control, see Parkinson’s Law, 74, 201
project monitoring and PDM (precedence diagramming
ICB ® (IPMA Competence control method), 50
Baseline) certification, 2 Monte Carlo simulation, 73, 108, performance constraint, 29
IEEE (Institute of Electrical and 200 performance evaluations, 163
Electronics Engineers), 3 most likely estimates, 70 performance management
-ilities (term), 118, 199 motivation, 163 baseline (PMB), 201
imposed dates, 54 MTBF (mean time between performance measurement
inspections, 142–143 failures), 147 baseline (PMB), 124–127,
Institute of Electrical and 153
Electronics Engineers Negative stakeholders, 14, 24 performance rewards, 162–163
(IEEE), 3 network diagram PERT, see Program Evaluation
insurable risks, 16, 97, 199 definition of, 200 and Review Technique
internal managers, evolution of, 80 PERT charts, 50, see also network
communication needs of, mapping assignments to, 85 diagramming
13 network diagramming, 49–60 PERT/COST, 147
International Project activity list construction in, pessimistic estimates, 70, 71
Management Association 50–52 phase (term), 201
(IPMA), 2 critical path and float in, phase-based WBS, 45, 47–48
IPMA Competence Baseline 58–60 phases of projects, projects vs.,
(ICB®) certification, 2 critical path determination in, 23–24
iterative activity, 3, 42, 199 53–54

planned value (PV), 147–149, Program Evaluation and Review project human resources
201 Technique (PERT), 70–72 management, 14–15, 203
planning activity(-ies), 41–63 CPM vs., 88 project initiation, 23
Gantt chart creation in, 60–62 creation of, 2 definition of, 22, 23, 203
iterative nature of, 42 definition of, 202 elements in, 23
for monitoring and control, as quantitative risk system, process of, 7–9
140 108 project integration management,
network diagramming in, program management, 202 16, 203
49–60 program(s) projectized organizations, 6–7
requirements document in, definition of, 6, 202 project layout, 52–53
43–44 projects grouped into, 6 project leadership, 117
risk management as, 100–101 progressive elaboration project life cycle, 143, 203
statement of work in, 42–43 concept of, 3 project management, 1–19
work breakdown structure in, definition of, 202 borders of, 3
44–49 in planning, 42 definition of, 3, 203
PMB (performance management and project objective, 37 growth of, 2
baseline), 201 and project plan, 80 knowledge areas in, 11–18
PMB (performance project charter, 34–36 organizational environment
measurement baseline), definition of, 202 for, 6–7
124–127, 153 elements of, 35 and organization structure,
PMBOK® Guide, see A Guide to the importance of, 9 6–7
Project Management Body of outline of, 35–36 origins of, 2–3
Knowledge project closeout, 157–167 process groups in, 7–11
PMI (Project Management administrative, 162 Project Management Institute
Institute), 3 celebration and reward in, (PMI), 3
PMO, see Project Management 162–163 Project Management Office
Office checklist for, 159–160 (PMO), 4, 66, 203
PMP® (Project Management for contracts and Project Management
Professional ), 3, 69 procurements, 161–162 Professional (PMP®), 3, 69
Polaris submarine project, 70 definition of, 158, 202 project management software, 73
portfolio, 6, 201 lessons learned reviews in, project management work, in
portfolio management, 201 163–165 WBS, 49
positive stakeholders, 14, 24 process of, 10–11 project managers
Post-it® notes, 114, 164 steps in, 158 knowledge areas for, 11–18
post-test, xv, 217–222 transfer of product in, 161 as project stakeholders, 25
precedence diagramming project communications as stakeholders in other
method (PDM), 50 management, 13, 90, 202 projects, 26
preliminary estimates, 67, 201 project control, 10, see also project monitoring and control,
preliminary project plan, 80 project monitoring and 139–154
pre-test, xv, xvii–xxii control definition of, 10, 203
pricing risk, 97–98 project cost management, 13, 202 earned value management for,
probability, 71, 201 project environment, 96, 145 147–153
probability and impact matrix, project execution, 123–136 planning for, 140
105, 201 change management in, 130, process of, 10
problem solving, 133–135 133 and project plan/baseline
process group, 201 definition of, 202 updating, 153
process maps, 146 and kickoff meeting, 129 project status monitoring in,
process quality, 117, 201 performance measurement 140–143
process quality control, 117 baseline in, 125–127 of quality, 146–147
procrastination, 74 plan approval in, 124–125 and reporting of project
procurement closure, 161–162 problem solving in, 133–135 status, 143–145
procurement management, 15, process of, 10 of risk, 100, 145–146
203 team and resource selection of schedule, 12
procurement planning, 86 in, 127–129 project objective, 37
procurements log, 161 team development in, 129 project plan, 79–93
product quality, 117–119, 202 work management in, 129–132 approval of, 124–125

INDEX 227
communications and in human resources requirements traceability matrix,

stakeholder management management, 14–15 44, 204
plan in, 90–92 limitations on, 142 reserves, managing, 146
CPM analysis in, 87–90 in project plan, 80–85 residual risk, 115, 204
neglect of closeout process in, project time management, 11, 12, resource leveling, 204
10 207 resource loading, 204
outsourcing in, 86–87 pure risks, 16, 97, 204 resource requirements, 80
and progressive elaboration, PV (planned value), 147–149, resources
80 201 balancing time, cost, and,
project schedule vs., 9 87–90
project team building in, QA/QC (quality for monitoring and control,
80–85 assurance/quality control), 140
schedule loading and leveling 204 selection and development of,
in, 85–86 qualitative risk analysis, 104–108, 127–129
staffing and resource 204 resource scheduling, 204
requirements in, 80 quality, 96, 116–119 responsibility assignment matrix
updating the, 153 definition of, 96, 116, 204 (RAM), 81–85, 128, 204
project planning, 9, 203 monitoring and control of, reviews
project procurement 146–147 of lessons learned, 163–165
management, 15, 203 process, 117 during project execution,
project quality management, 15, product, 117–119 142–143
117–119, 203 in project environment, 96 rewarding performance, 162–163
project risk management, 16, 203 scope vs., 116 risk analysis
project risk score, 97–98, quality assurance, 15, 117, 146 definition of, 205
107–108 quality assurance/quality qualitative, 104–108, 204
project(s) control (QA/QC), 204 quantitative, 104–105,
definition of, 3, 202 quality control, 15, 117, 147 108–111, 204
grouped into programs or quality goals, 66 risk appetite, 99, 205
portfolios, 6 Quality Is Free (Crosby), 119 risk audits, 145
ongoing work efforts vs., 3 quality management, 15, risk cycle, 145
phases of projects vs., 23–24 117–119, 203 risk identification, 101–104, 205
reasons for undertaking, 22 quantitative risk analysis, risk management, 16, 100–116,
project salvage, 164, 165 104–105, 108–111, 204 203
project schedule, project plan vs., definition of, 205
9, see also schedule RACI matrix, see responsibility identification of risks in,
project scope, 12, 203 assignment matrix (RAM) 101–104
project scope management, 12 RAM, see responsibility implementing risk responses
project sponsor, 13, 24, 203 assignment matrix in, 115–116
project stakeholder management, random numbers, for Monte philosophy of, 97
14, 204, see also stakeholder Carlo simulation, 73 planning of, 100–101
management Registered Project Professional planning risk responses in,
project status (RPP), 2 111–115
monitoring, 140–143 regulators, as stakeholders, 26 as proactive, 134
reporting, 143–145 Remington Rand, 2, 88 qualitative risk analysis in,
project team requirements 104–108
closeout celebration and definition of, 204 quantitative risk analysis in,
rewards for, 162–163 functional, 118, 199 108–111
communication needs of, 13 guidelines for writing, 44 uncertainty in, 98
development of, 129 nonfunctional, 118, 200 risk management plan, 205
locations of, 142 resource, 80 risk management policy, 101, 205
selection of, 127–129 setting, 117, 118 risk mitigation cost, 205
as stakeholders, 25 staffing, 80–81 risk monitoring and control, 100,
work management for, well-written, 43–44 145, 205
129–130 requirements document, 15, risk premium, 98, 205
project team building 43–44 risk reassessment, 145, 205
risk register, 103–104, 107, 205

risk response planning, 111–115, sharing, of risk, 113–114, 206 3M, 114, 164
205 Shewhart, Walter A., 117 three-point estimate, 207
risk responses skill set three-point estimating, 69–73
implementing, 115–116 for project team members, 81, with Monte Carlo simulation,
planning, 111–115 128–129 73
risk(s), 96–100 in responsibility assignment with PERT, 70–72
adjusting for, 69 matrix, 81–83 time
definition of, 16, 96, 204 slack, 53, 88, see also float balancing cost, resources, and,
fundamental formula of, SOW, see statement of work 87–90
97–98 SPC (statistical process control), PERT calculations for, 71
identifying, 101–104 146 time constraint, 29, 66
monitoring and control of, spend plan, 206 time management, 11, 12, 207
145–146 SPI (schedule performance top down approach (WBS), 48
pricing of, 97–98 index), 151, 206 total float, 58
in project environment, 96 sponsor, see project sponsor tracking Gantt chart, 125–127,
reassessment of, 145 SS (start to start), 54, 207 207
types of, 97, see also individual staffing requirements, 80–81 transfer
types stakeholder management, 14, 204 definition of, 207
risk score, 97–98, 107–108 in communications and of product, service, or result,
risk threshold, 99, 205 stakeholder management 158, 161
risk tolerance, 99–100, 206 plan, 90–92, 145 of risk, 112
risk triage, 105, 106, 206 goals of, 90 triggers
rolling wave estimates, 74, 206 issues in, 26–28 for contingency plans, 114,
rough order of magnitude stakeholder register, 26, 27 134
(ROM), 67, 206 stakeholders definition of, 207
RPP (Registered Project common, 24–26 triple constraint, 29–30, 96, 207
Professional), 2 communication needs of, 13 Truman, Harry, 113
and defining projects, 24–28 Tylenol® murders case, 164
Salvage, project, 164, 165 definition of, 14, 206
schedule getting plan approval from, Uncertainty, 66
baseline for, 125–126 124 about uncertainty, 98
loading and leveling the, identifying needs and of the future, 97
85–86 expectations of, 145 US Department of Defense
project plan vs., 9 impact levels of, 24 (DoD), 147
in project time management, standard deviation, 70–71, 207 US Navy, 2
11–12 start to start (SS), 54, 207 US Office of Management and
schedule compression, 206 statement of work (SOW), Budget (OMB), 147
schedule performance index 42–43, 80, 207
(SPI), 151, 206 statistical process control (SPC), Value of early completion, 88,
schedule variance (SV), 150, 206 146 207
scheduling, resource, 204 status meetings, 141, 142 vendors
scheduling relationships, in status monitoring, 140–143 closeout of contracts with,
network diagramming, 54 status reporting, 141, 207 161–162
Scientific Wildly Aimed Guess supervisors, as stakeholders, 25, as stakeholders, 26
(SWAG), 67, 207 26
scope SV (schedule variance), 150, 206 WAG, see Wildly Aimed Guess
project, 12, 203 SWAG (Scientific Wildly Aimed Watergate, 37
quality vs., 116 Guess), 67, 207 WBS, see work breakdown
scope constraint, 29 structure
scope creep, 37, 130, 206 Tangential stakeholders, 14, 24 WBS Dictionary, 130–132, 207
scope management, 12, 206 Taylor, Frederick W., 2 weak constraints, 31, 32, 208
scope statement, 12, 206 team, see project team weighted average, 70
scope verification, 126, 206 threats Wildly Aimed Guess (WAG), 67,
s-curve chart, 127, 128 definition of, 16, 207 69, 207
secondary risk, 115, 206 as negative risk, 16, 97 work, 208
sensitivity analysis, 109–110, 206 risk responses for, 110–112 workarounds, 134, 208

INDEX 229
work breakdown structure in project scope management,

(WBS), 44–49 12
closeout elements in, 158 as scope verification tool, 126
definition of, 44, 208 work management, for project
department-based vs. phase- team, 129–132
based, 45, 47–48 work management form,
evolution of, 80 130–132, 208
levels of decomposition in, 45 work maturity, 81
one hundred percent rule for, work packages
49 assigning team members to, 81
in org chart and outline definition of, 208
formats, 45, 46 tradeoffs with, 87–88
project management work in
the, 49 Z table, 71, 72, 208


(BusinessPro Collection) Dobson, Michael Singer - Successful Project Management - How To Complete Projects On Time, On Budget, and On Target-Ama Self-Study - American Management Association (2015)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(BusinessPro Collection) Dobson, Michael Singer - Successful Project Management - How To Complete Projects On Time, On Budget, and On Target-Ama Self-Study - American Management Association (2015)

Uploaded by

Copyright:

Available Formats

Successful Project Management

How to Complete Projects on Time,

How to Complete Projects on Time,

1 Understanding Project Management 1

2 Defining the Project 21

3 Planning the Activities 41

4 Estimating the Activities 65

© American Management Association. All rights reserved.

5 Preparing a Project Plan 79

6 Managing Risk and Quality 95

© American Management Association. All rights reserved.

7 Transition to Execution 123

8 Controlling Time, Cost, and Scope 139

© American Management Association. All rights reserved.

9 Evaluating and Reporting on 157

© American Management Association. All rights reserved.

Appendix B: Glossary 195

© American Management Association. All rights reserved.

Think About It…Monitoring and Control

© American Management Association. All rights reserved.

Exhibit 6–7 Decision Tree

FOR QUESTIONS AND COMMENTS:

© American Management Association. All rights reserved.

“Project management is one of those applications that everyone

© American Management Association. All rights reserved.

Michael S. Dobson, PMP, is an internationally known authority on proj-

© American Management Association. All rights reserved.

Pre- and Post-Tests

© American Management Association. All rights reserved.

Exercises and Activities

The Review Questions

Questions About Grading/Retaking the Test

© American Management Association. All rights reserved.

Successful Project Management

Course Code 98004

1. In a PERT analysis, what is the probability that an activity will be

2. The triple constraints include:

© American Management Association. All rights reserved.

3. A critical path activity can be compressed from eight weeks to four

© American Management Association. All rights reserved.

Research Topic Design Graphics Assign Presenter Determine Topic

Arrange Beta Test Develop Promotional

Incorporate Beta Test Train Additional

11. For a particular activity, we determine that optimistically it will take 6

12. An analogous estimate is considered accurate if the final project cost is

© American Management Association. All rights reserved.

Activity A Activity C Activity H

Activity E Activity F Activity G

16. What document formally authorizes the existence of a project and

17. What is “the application of knowledge, skills, tools, and techniques to

© American Management Association. All rights reserved.

19. The fundamental formula for risk is:

21. What is defined as a “hierarchical decomposition of the total scope of

22. What is one piece of information that should be included in a

23. The process of prioritizing risks for further analysis or action by

24. What is a constraint?

© American Management Association. All rights reserved.

© American Management Association. All rights reserved.

Estimated timing for this chapter:

© American Management Association. All rights reserved.

ORIGINS OF MODERN PROJECT

© American Management Association. All rights reserved.