Course Workbook

Volume
1
PMP PREPARATION COURSE
Workbook
PMP Preparation Course

Workbook
2010 Promantia Global Consulting LLP

Bangalore, INDIA.
Table of Contents
ORGANIZATION OF THE STUDENT GUIDE ...............................................................................1
PROJECT FRAMEWORK ...........................................................................................................1
PROJECT ...................................................................................................................................... 1
PROGRAM.................................................................................................................................... 2
PORTFOLIO .................................................................................................................................. 2
STAKEHOLDER............................................................................................................................... 2
CONSTRAINTS ............................................................................................................................... 3
ROLE OF A PROJECT MANAGER ........................................................................................................ 3
ORGANIZATION STRUCTURES ........................................................................................................... 4
Functional Organization ........................................................................................................ 4
Projectized Organization ....................................................................................................... 5
Matrix Organization .............................................................................................................. 5
PROCESS GROUPS ......................................................................................................................... 7
PROJECT PHASES ........................................................................................................................... 8
PROJECT LIFE CYCLE ....................................................................................................................... 9
COMMON INPUTS ....................................................................................................................... 10
Organization Process Assets ................................................................................................ 10
Enterprise Environment Factors .......................................................................................... 11
KNOWLEDGE AREAS IN PMBOK GUIDE......................................................................................... 11
FREQUENTLY ASKED QUESTIONS .................................................................................................... 14
PRACTICE QUESTIONS .................................................................................................................. 15
ANSWERS TO PRACTICE QUESTIONS ................................................................................................ 17
INITIATING PROCESSES ......................................................................................................... 19
DEVELOP PROJECT CHARTER ................................................................................................ 20
PREPARE BUSINESS CASE .............................................................................................................. 20
SIGN CONTRACT .......................................................................................................................... 21
PREPARE PROJECT CHARTER .......................................................................................................... 21
Identify a Project Manager.................................................................................................. 21
Authorize Project Manager ................................................................................................. 21
PROJECT SELECTION ..................................................................................................................... 22
Benefit Measurement Methods........................................................................................... 22
Constrained Optimization Models ....................................................................................... 25
IDENTIFY STAKEHOLDERS ..................................................................................................... 29
WHY IDENTIFY STAKEHOLDERS? ..................................................................................................... 29
COMMON MISTAKES MADE WHILE IDENTIFYING STAKEHOLDERS ........................................................... 31
i
PLANNING PROCESSES ......................................................................................................... 35

COLLECT REQUIREMENTS ..................................................................................................... 36
GATHER REQUIREMENTS FROM STAKEHOLDERS ..................................................................................36
MAKE QUICK DECISIONS.................................................................................................................37
USE CREATIVE TECHNIQUES ............................................................................................................38
OUTPUTS OF COLLECT REQUIREMENTS .............................................................................................38
Requirements Document ......................................................................................................38
Requirements Management Plan.........................................................................................40
Requirements Traceability Matrix ........................................................................................40
FREQUENTLY ASKED QUESTIONS .....................................................................................................41
PRACTICE QUESTIONS ...................................................................................................................41
ANSWERS TO PRACTICE QUESTIONS .................................................................................................43
DEFINE SCOPE ...................................................................................................................... 44
DEVELOPING DETAILED DESCRIPTION OF REQUIREMENTS .....................................................................44
CONTENTS OF A SCOPE STATEMENT .................................................................................................45
CREATE WBS ......................................................................................................................... 49
DEFINING WORK PACKAGES ...........................................................................................................50
DECOMPOSING A DELIVERABLE .......................................................................................................50
SIZE OF A WORK PACKAGE ..............................................................................................................50
OUTPUTS OF CREATING WBS .........................................................................................................51
DEFINE ACTIVITIES ................................................................................................................ 55
CREATING AN ACTIVITY LIST ...........................................................................................................55
DEFINE ACTIVITY - OUTPUTS ..........................................................................................................56
SEQUENCE ACTIVITIES .......................................................................................................... 60
TOOLS & TECHNIQUES TO SEQUENCE ACTIVITIES ................................................................................60
SEQUENCE ACTIVITIES - OUTPUTS....................................................................................................64
ESTIMATE ACTIVITY RESOURCES .......................................................................................... 67
DEVELOPING ACTIVITY RESOURCE REQUIREMENTS..............................................................................67
DEVELOPING A RESOURCE BREAKDOWN STRUCTURE ...........................................................................68
ii
ESTIMATE ACTIVITY DURATION ............................................................................................ 71

DEVELOPING ACTIVITY DURATION ESTIMATES ................................................................................... 72
ACTIVITY DURATION ESTIMATES OUTPUTS ....................................................................................... 74
DEVELOP SCHEDULE ............................................................................................................. 77
DEVELOP SCHEDULE TOOLS & TECHNIQUES ................................................................................... 77
Determining Critical Path .................................................................................................... 79
DEVELOP SCHEDULE - OUTPUTS ..................................................................................................... 81
ESTIMATE COSTS .................................................................................................................. 85
DEVELOPING ACTIVITY COST ESTIMATES .......................................................................................... 87
OUTPUTS ESTIMATE COSTS......................................................................................................... 89
DETERMINE BUDGET ............................................................................................................ 94
DEVELOPING THE PROJECT COST PERFORMANCE ............................................................................... 95
Contingency and Management Reserves ............................................................................ 95
DETERMINE BUDGET - OUTPUTS .................................................................................................... 96
PLAN RISK MANAGEMENT .................................................................................................... 99
PLAN RISK MANAGEMENT TOOLS & TECHNIQUES ......................................................................... 100
CONTENTS OF A RISK MANAGEMENT PLAN .................................................................................... 100
FREQUENTLY ASKED QUESTIONS .................................................................................................. 101
PRACTICE QUESTIONS ................................................................................................................ 102
ANSWERS TO PRACTICE QUESTIONS .............................................................................................. 103
IDENTIFY RISKS ................................................................................................................... 104
TOOLS AND TECHNIQUES FOR RISK IDENTIFICATION.......................................................................... 104
SWOT Analysis ................................................................................................................... 105
Wide Band Delphi .............................................................................................................. 106
Using Ishikawa Diagrams in Risk Identification................................................................. 107
OUTPUT FROM RISK IDENTIFICATION ............................................................................................. 109
PERFORM QUALITATIVE RISK ANALYSIS ............................................................................. 113
QUALITATIVE RISK ANALYSIS TOOLS & TECHNIQUES ...................................................................... 113
Risk Matrix or Risk Probability-Impact Matrix (PIM) ......................................................... 113
Problems with the Risk Matrix .......................................................................................... 114
iii
Suggested ways to use the Risk Matrix ..............................................................................115

KEY OUTPUTS FROM QUALITATIVE RISK ANALYSIS ............................................................................116
FREQUENTLY ASKED QUESTIONS ...................................................................................................117
PRACTICE QUESTIONS .................................................................................................................118
ANSWERS TO PRACTICE QUESTIONS ...............................................................................................119
PERFORM QUANTITATIVE RISK ANALYSIS .......................................................................... 120
QUANTITATIVE RISK ANALYSIS - TOOLS & TECHNIQUES ......................................................................120
Monte Carlo Simulation .....................................................................................................121
Decision Tree Analysis ........................................................................................................125
Interpreting the Decision Tree Correctly ............................................................................127
Sensitivity Analysis .............................................................................................................128
Risk Attitudes and Utility Functions....................................................................................128
Key Outputs from Quantitative Risk Analysis .....................................................................129
RISK RESPONSE PLANNING ................................................................................................. 133
FUNDING IMPLICATIONS FOR RISK RESPONSES .................................................................................134
Risk Response Planning An example ...............................................................................135
KEY OUTPUTS FROM RISK RESPONSE PLANNING ...............................................................................136
HUMAN RESOURCES PLANNING ......................................................................................... 139
TOOLS & TECHNIQUES FOR HR PLANNING.......................................................................................139
HR PLANNING - OUTPUTS............................................................................................................140
QUALITY PLANNING ........................................................................................................... 144
IMPACT OF POOR QUALITY ...........................................................................................................144
INPUTS TO QUALITY PLANNING .....................................................................................................144
QUALITY PLANNING TOOLS & TECHNIQUES .....................................................................................145
Benefit/Cost Analysis..........................................................................................................145
Benchmarking ....................................................................................................................145
Design of Experiments ........................................................................................................145
Cost of Quality ....................................................................................................................145
Statistical Sampling ............................................................................................................146
Control Charts ....................................................................................................................146
Flow Charting .....................................................................................................................146
OUTPUTS OF QUALITY PLANNING ..................................................................................................147
PLAN COMMUNICATIONS .................................................................................................. 151
PLAN COMMUNICATIONS TOOLS & TECHNIQUES ...........................................................................151
PLAN COMMUNICATIONS OUTPUTS ............................................................................................152
iv

PLAN PROCUREMENT ......................................................................................................... 156
PLAN PROCUREMENT TOOLS & TECHNIQUES ............................................................................... 157
PROCUREMENT PLANNING OUTPUTS .......................................................................................... 158
DEVELOP PROJECT MANAGEMENT PLAN............................................................................ 164
EXECUTING PROCESSES ...................................................................................................... 167
DIRECT AND MANAGE EXECUTION ..................................................................................... 168
Directing Execution............................................................................................................ 168
Managing Execution.......................................................................................................... 168
DIRECT & MANAGE EXECUTION - TOOLS & TECHNIQUES .................................................................. 169
OUTPUTS OF DIRECT & MANAGE EXECUTION ................................................................................. 169
ACQUIRE PROJECT TEAM .................................................................................................... 174
TOOLS AND TECHNIQUES TO ACQUIRE PROJECT TEAM ...................................................................... 174
OUTPUTS OF ACQUIRE PROJECT TEAM .......................................................................................... 175
DEVELOP PROJECT TEAM .................................................................................................... 178
TOOLS FOR DEVELOPING YOUR PROJECT TEAM ................................................................................. 178
Conflict Resolution ............................................................................................................. 178
Motivating your team ....................................................................................................... 179
Building a team ................................................................................................................. 179
OUTPUTS OF DEVELOP PROJECT TEAM .......................................................................................... 180
MANAGE PROJECT TEAM.................................................................................................... 183
TOOLS AND TECHNIQUES FOR MANAGING TEAM ............................................................................. 183
OUTPUTS OF MANAGE PROJECT TEAM .......................................................................................... 186
DISTRIBUTE INFORMATION ................................................................................................ 189
DISTRIBUTE INFORMATION TOOLS & TECHNIQUES ........................................................................ 189
v
DISTRIBUTE INFORMATION - OUTPUTS ...........................................................................................190

MANAGE STAKEHOLDER EXPECTATIONS ............................................................................ 193
MANAGE STAKEHOLDER EXPECTATIONS TOOLS & TECHNIQUES ........................................................194
MANAGE STAKEHOLDER EXPECTATIONS OUTPUTS .........................................................................194
PERFORM QUALITY ASSURANCE ........................................................................................ 197
PERFORM QUALITY ASSURANCE TOOL AND TECHNIQUES ...................................................................197
PERFORM QUALITY ASSURANCE OUTPUTS ....................................................................................198
CONDUCT PROCUREMENTS ................................................................................................ 201
CONDUCT PROCUREMENTS OUTPUTS ..........................................................................................202
MONITORING & CONTROLLING PROCESSES ....................................................................... 205
MONITORING & CONTROLLING .......................................................................................... 206
MONITOR & CONTROL PROJECT WORK ..........................................................................................206
PERFORM INTEGRATED CHANGE CONTROL ......................................................................................207
REPORT PERFORMANCE ...............................................................................................................208
CONTROLLING SCOPE, SCHEDULE, AND COSTS .................................................................................209
PERFORM QUALITY CONTROL V/S VERIFY SCOPE ..............................................................................211
MONITOR AND CONTROL RISKS ....................................................................................................212
CLOSING PROCESSES .......................................................................................................... 215
vi
Table of Figures
FIGURE 1: RELATION BETWEEN PROJECT, PROGRAM AND PORTFOLIO ..................................... 3
FIGURE 2: FUNCTIONAL ORGANIZATION ..................................................................................... 5
FIGURE 3: PROJECTIZED ORGANIZATION .................................................................................... 5
FIGURE 4: WEAK MATRIX............................................................................................................. 6
FIGURE 5: STRONG MATRIX ......................................................................................................... 7
FIGURE 6: BALANCED MATRIX ..................................................................................................... 7
FIGURE 7: PROCESS GROUP INTERACTIONS ................................................................................ 8
FIGURE 8: PROJECT LIFE CYCLE (BORROWED FROM PMBOK GUIDE 4TH EDITION PAGE 16) ..... 9
FIGURE 9: STAKEHOLDER INFLUENCE & RISKS ON PROJECTS (BORROWED FROM PMBOK
TH
GUIDE 4 EDITION PAGE 17) .............................................................................................. 10
FIGURE 10: PROCESS GROUPS DEFINED IN PMBOK .................................................................. 13
FIGURE 11: SCORING MODEL .................................................................................................... 23
FIGURE 12: PRESENT VALUE CALCULATION .............................................................................. 24
FIGURE 13: PROJECT SELECTION USING NPV ............................................................................ 24
FIGURE 14: PORTION OF A STAKEHOLDER REGISTER ................................................................ 31
FIGURE 15: A TYPICAL REQUIREMENTS DOCUMENT ................................................................ 39
FIGURE 16: REQUIREMENTS TRACEABILITY MATRIX ................................................................. 40
FIGURE 17: CONTENTS OF A TYPICAL SCOPE STATEMENT ........................................................ 45
FIGURE 18: PARTIAL WBS FOR PROJECT PERSIST ...................................................................... 49
FIGURE 19: CONTENTS OF WBS DICTIONARY ............................................................................ 51
FIGURE 20: ROLLING WAVE PLANNING ..................................................................................... 56
FIGURE 21: PRECEDENCE NETWORK DIAGRAM ........................................................................ 61
FIGURE 22: FINISH-START PRECEDENCE .................................................................................... 61
FIGURE 23: START-START PRECEDENCE .................................................................................... 62
FIGURE 24: FINISH-FINISH PRECEDENCE ................................................................................... 62
FIGURE 25: START-FINISH PRECEDENCE .................................................................................... 62
FIGURE 26: RANGE OF ACTIVITY DURATION ESTIMATES .......................................................... 73
FIGURE 27: FORWARD PASS - CALCULATE EARLY START AND EARLY FINISH TIMES ................. 80
FIGURE 28: BACKWARD PASS - CALCULATE THE LATE START AND LATE FINISH ....................... 81
FIGURE 29: COST PERFORMANCE BASELINE ............................................................................. 96
FIGURE 30: RISK BREAKDOWN STRUCTURE ............................................................................ 101
FIGURE 31: SWOT ANALYSIS .................................................................................................... 106
FIGURE 32: ISHIKAWA DIAGRAM............................................................................................. 108
FIGURE 33: PROBABILITY IMPACT MATRIX .............................................................................. 114
FIGURE 34: SAMPLE RISK MATRIX CALIBRATION..................................................................... 116
FIGURE 35: SUGGESTED ALTERNATIVE RISK MATRIX BASED ON ORDINAL SCALES ................ 116
FIGURE 36: MONTE CARLO ANALYSIS - INPUTS ....................................................................... 122
FIGURE 37: MONTE CARLO - SPREADSHEET CALCULATIONS .................................................. 123
FIGURE 38: CUMULATIVE PROBABILITY FROM MONTE CARLO ANALYSIS .............................. 123
FIGURE 39: TRIANGULAR DISTRIBUTION AND ITS USE IN A MONTE CARLO SIMULATION ..... 124
FIGURE 40: SAMPLE DECISION TREE ........................................................................................ 127
FIGURE 41: INTERPRETING DECISION TREE ............................................................................. 127
FIGURE 42: FINAL EXPECTED VALUES ...................................................................................... 129
FIGURE 43: RISK RESPONSE AND PROJECT FUNDING IMPLICATIONS ..................................... 135
FIGURE 44: RAM AND RACI...................................................................................................... 141
FIGURE 45: COMMUNICATIONS PLAN..................................................................................... 153
vii
FIGURE 46: WORK PERFORMANCE INFORMATION ..................................................................170

FIGURE 47: SAMPLE CHANGE REQUEST ...................................................................................170
FIGURE 48: CONFLICT RESOLUTION TECHNIQUES ...................................................................185
FIGURE 49: COMMUNICATION METHODS ...............................................................................190
FIGURE 50: SUMMARY - SCOPE, TIME AND COST CONTROL....................................................210
viii
Organization of the student guide

<Explain how this student guide is written>
P R O J E C T
F R A M E W O R K
Chapter
1
Project Framework
Project
A project is a temporary endeavor. It has a definite start date and a definite end date.
A project creates a unique product, service or result.
There are two important points you need to understand:
The temporary characteristic applies only to the project and not to the
output of the project. Outputs of most projects last for long. For example, a
project may be undertaken to build an Airport in the outskirts of a city. The
project may start, say on the 15th July 2009 and end on the 30th Oct 2011.
However, the outcome of the project the Airport itself will last for several
decades.
Projects may have some repetitive elements. However, it does not change
the uniqueness of the project
A project starts when an individual or an organization realizes a need for it the need
can be social, environmental, and economic (for-profit) or could be driven by external
factors (such as requested by customer) or factors internal to your organization. The
project ends when the need is met. In some cases a project may also end when you
realize that the need cannot be met by the outcome of the project.
Examples of projects include:
Developing the transmission system for a new electric vehicle
Acquiring a new MIS system for your company
Effecting a change in the organization structure of your company
Constructing a monument, building or a facility
Running an enhanced marketing campaign for a product

1
P R O J E C T
F R A M E W O R K
Implementing a new business process in your organization
Projects always have an end date. In contrast,

they dont have an end date.
operations
are repetitive and ongoing;
Program
A program is a collection of interrelated projects such that it makes sense to manage
them together rather than individually. Also, failure of one project may result in the
failure of the entire program. Lets say that Indian Space Research Organization
(ISRO) is planning to put in orbit the INTELLESAT satellite. This initiative to launch
the satellite can be managed individually as several projects one project to build the
satellite, one to setup a ground station to monitor the satellite in orbit once launched
one to build & commission a launch vehicle that would place the satellite in orbit.
However, since all projects share the same objectives that of putting in orbit the
satellite it makes sense for us to manage this as a program.
Portfolio
A portfolio is a collection of projects and programs. These projects and programs may
be or may not be related in that they may not share the same objectives; however there
is a common theme across all the projects and programs. The theme could be that
all projects and programs are being carried out for the same customer or the projects
and programs may be using the same technology or they may be in the same domain,
say, in the financial sector. When otherwise unrelated projects and programs have a
common theme they can be managed as a portfolio to obtain benefits of coordination.
FIGURE 1shows the relationship between Project, Program and Portfolio.
Stakeholder
A stakeholder is an individual (like the sponsor or the project manager), a group (like
the performing organization, the project team etc.), or an organization (like the
Government, the requesting organization etc.) that have a share or interest in the
project and are positively or negatively impacted by its outcome.
P R O J E C T
F R A M E W O R K
FIGURE 1: Relation between Project, Program and Portfolio
Constraints
Constraints are hindrances that may impact the objectives of the project. Primary
constraints on a project can be in terms of scope (features to be added to a product),
time (how soon can you implement these features), cost (can you reduce the costs of
implementing these features). These constraints are related to each other in that
changing, or acting on one of the three constraints can impact another. For example,
adding most features can increase the time and cost which would be undesirable.
Quality is yet another constraint which is impacted by changes to scope, time and cost.
Other project constraints that a project manager has to deal with are
risk.
resources
and
Role of a Project Manager

The project manager is responsible for the success or failure of the project. In order to
achieve the project outcomes a project manager must have:
Knowledge
techniques
Soft skills
motivation
as well as skills to apply project management practices, tools and
communication skills, interpersonal skills, negotiation, conflict resolution,
P R O J E C T
F R A M E W O R K
It is not sufficient if the project manager have skills in project

management. She must have knowledge of the domain or sector of the project. For
example, a project manager responsible to build a bridge must have skills in the
construction domain.
Domain skills
Begin with the end in mind - Stephen Covey.
A project manager must be able to visualize the projects product at the start of the
project. This is possible only if the project manager participates in requirements
gathering and understands the big picture of the project. If a project manager cannot
visualize it she would not be able to help the project team deliver the product.
To successfully achieve the projects objectives, a project manager must be able to
manage expectations of stakeholders. This can be possible only if the project
manager open communication channels with stakeholders and continuously provide
them the required information on the progress of the project.
And finally, to be a successful project manager, she must be able to deal with the
project constraints. Balancing the project constraints scope, time, cost, quality,
resources and risk is an absolute must in order to successfully achieve the project
objectives.
Organization Structures
Structure of an organization has a major influence on performance of projects. There
are 3 types of organizations Functional, Projectized and Matrix - that you need to be
aware of.
Functional Organization
A functional organization is one where employees are grouped by the skills they
possess or their specialization. In these organizations each employee clearly has one
supervisor and they are fiercely loyal to their department or group. Figure 2 shows a
typical structure in a functional organization. In these types of organizations employees
are attached to their home or the department they work for and rarely change
their home. Information flow between departments is very weak. Since performing
projects require significant exchange of information between departments execution of
projects in this type of organization is very difficult. Project co-ordination is, therefore,
at the functional managers level.
P R O J E C T
F R A M E W O R K
FIGURE 2: Functional Organization
Projectized Organization
A projectized organization is one where employees are grouped by the projects they
work on. Employees dont have a home since by definition a project has to end
someday. On completion of a project team members are assigned to a resource pool
and await allocation to another project. Team members can change projects unlike in a
functional organization where employees rarely change their departments. Figure 3
shows a typical projectized organization structure. Exchange of information between
projects is good. Project Managers often refer to lessons learnt database that stores
information about historical and ongoing projects to help them understand and
execute their current project better.
FIGURE 3: Projectized Organization
Matrix Organization
Both functional and projectized organizations have their share of good and bad things.
It is a known fact that most organizations world-wide are fast adapting a matrix
structure. Matrix organization is a mix of functional and projectized organizations
5
P R O J E C T
F R A M E W O R K
bringing together the good attributes of functional and projectized organization

together. Typically, an employee reports to more than one manager usually a
functional manager and a project manager should the employee be working on a
project. There are 3 types of matrix organization based on powers of the
project/functional manager. These are Weak Matrix, Balanced Matrix and Strong
Matrix.
is one where the attributes of the organization are similar to a functional
organization. Lets look at how projects are executed in weak matrix organizations.
Figure 4 shows an organization structure of an engineering company a weak matrix
organization - that wants to find out the cost and technical efficiency of a new welding
technology. A team is put together to execute this project and the team members as
shown in the figure are Accountant 3, Analyst 3 and Welder 1. Please note that these
three employees report to their respective functional managers but for the project one
of the three, say the Accountant, is chosen the project manager.
Weak Matrix
FIGURE 4: Weak Matrix
A project manager in a weak matrix is primarily responsible for communications and

can be an expediter or a coordinator depending on the level of her reporting
relationship. An expediter is one that reports to a lower level manager while a project
coordinator is one who reports into a slightly more senior level manager. Project
managers in weak matrix do not make any decisions; they only enforce the decisions
made by functional managers.
A strong matrix is one whose attributes are similar to a projectized organization. In a
strong matrix, project managers have relatively more power than their counterparts in a
weak matrix. They are responsible for the success and failure of the projects. Project
managers in this organization report into a functional manager who oversees execution
of all projects in the organization e.g. Head of the Project Management Office (PMO)
as shown in FIGURE 5.
6
P R O J E C T
F R A M E W O R K
FIGURE 5: Strong Matrix
Project managers in balanced matrix organizations share responsibilities with their

functional counterparts. Decisions are made jointly by the functional and project
manager. A typical structure of a balanced matrix is shown in FIGURE 6.
FIGURE 6: Balanced Matrix
Process Groups
PMBOK Guide 4th edition defines 5 categories of processes. These are referred to as
Process Groups. They are:
Initiating process group

7
P R O J E C T
F R A M E W O R K
Planning process group
Executing process group
Monitoring & controlling process group, and
Closing process group
Processes in the Initiating process group help you start a project or a phase of a
project. Process required to define the boundary of the project and establish as well as
refine objectives are part of the Planning process group. Executing process group
processes helps your teams perform the work for the project and attain the planned
objectives. Monitoring and controlling process group processes help you and
stakeholders track the progress of the project and take corrective or preventive actions
should there be a need to put the project on a desirable track. Closing group processes
help you perform the closure activities including documenting the lessons learnt as well
as providing feedback to the organizations process manager.
Project Phases
When the project is very large and you need extremely good control over deliverables
then you break the project into two or more phases. Each phase can be carried out
sequentially, or where possible with some overlapping elements. For each phase you
can perform the applicable processes in the 5 process groups. If a project is divided
into two or more phases the process groups would interact within each phase.
FIGURE 7 shows how the process groups interact in a phase or a project.
FIGURE 7: Process Group interactions
P R O J E C T
F R A M E W O R K
Project Life Cycle

The work that you do on a project is a collection of sequential and or overlapping
phases. The life cycle of a project can be decided based on the nature of the project as
well as your organizations policies on managing projects. Irrespective of the domain or
effort involved the project life cycle provides a basic framework for managing the
project.
At the beginning of the project the staffing levels are low. On an IT project, for
example, it is possible that the project is staffed with the just a project manager, an
architect and couple of developers. Therefore, the cost expended during the initial
stages of the project is low. But as the project gets into the execution phase more
developers are added to the team and the costs incurred start increasing. As the project
approaches closure the costs start going down. This is shown in Figure 8.
FIGURE 8: Project Life Cycle (Borrowed from PMBOK Guide 4th Edition Page 16)
At the beginning of the project the uncertainty and therefore the risk to the project is the greatest. However, as the project progresses this uncertainty reduces. Similarly,
the ability of stakeholders to influence changes to the project is the greatest at the
beginning and reduces as time progresses. These characteristics of the stakeholder
ability to influence and risks on the project over time are shown in FIGURE 9.
P R O J E C T
F R A M E W O R K
FIGURE 9: Stakeholder influence & Risks on projects (borrowed from PMBOK Guide 4th edition Page 17)
Common Inputs
The Organization Process Assets and Enterprise Environmental Factors are inputs to
a number of project management processes in the PMBOK Guide. These are
described briefly here:
Organization Process Assets
Organization Process Assets includes assets of the requesting organization and/or the
performing organization that influence the success of the project. Assets include:
Mature organizations have documented
policies, standards, guidelines, work practices, templates as well as communication
requirements for any project that is performed for internal purposes or for clients.
These influence the success of projects executed in the organization.
Organizations Processes and Procedures
This is a repository of data and information of past

projects that were executed by the organization. The data and information may be in
the form of project documents (requirements documents, design documents, test cases
etc.), records and measurements (defect data, issues log, minutes of meeting etc.),
financial data (business case document, project selection methods used, profitability
etc.) as well as registers (risk register showing movement of risk over the period of
execution of the project etc.). This information can be quite handy when project
managers embark on new projects.
Corporate Knowledge Base
10
P R O J E C T
F R A M E W O R K
Enterprise Environment Factors

These are internal or external factors that influence the success of the project. These
include:
Regulatory Requirement or Government Standards: E.g. the ISI standards for

products in India
Organization Structure We saw how an organizations structure influences

the performance of a project
Commercial Databases: These include commercially availability data and

information that could help project team estimate the size or effort on a new
project, database of risks etc.
Risk Tolerances Stakeholders have varying levels of risk thresholds. A riskaverse stakeholder may have an opposite influence on a project that a risk
taker.
Personnel Policies These are guidelines for staffing, training, retaining and
exiting staff from an organization. These guidelines definitely have a influence
on the project staffing, and hence on the project success.
Project Management Software Availability of tools for scheduling,

monitoring progress, reporting is a big factor in managing projects successfully.
These tools can help project managers keep their stakeholders up-to-date with
the status of the projects.
Knowledge Areas in PMBOK Guide

PMBOK Guide 4th edition has 5 process groups and 9 knowledge areas. We have
already seen the 5 process groups earlier in this chapter. The 9 knowledge areas are:
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Project Human Resources Management
Project Communications Management
11
P R O J E C T
F R A M E W O R K
Project Risk Management, and
Project Procurement Management
PMBOK Guide 4th edition also defines project management 42 processes that are
categorized into 5 process groups and 9 knowledge areas. FIGURE 10 shows the
organization of project management processes.
As mentioned earlier in this book, while PMBOK Guide 4th edition is organized by
knowledge areas, this student guide is organized along the lines of process groups i.e.,
we will discuss the initiating process group processes first followed by planning process
group processes and so on.
12
P R O J E C T
FIGURE 10: Process Groups defined in PMBOK
13
F R A M E W O R K
P R O J E C T
F R A M E W O R K
Frequently Asked Questions

1. In what type of organization does the project manager have complete authority
over resources?
A project manager has complete authority to commit resources in a projectized
organization.
2. In what stage of the do stakeholders have maximum influence over the
project?
Stakeholders have maximum influence during the initial stages. See FIGURE 9.
3. State 2 differences between projects and operations
Projects are temporary initiatives and will always have an end date.
Operations are ongoing
Projects result in a unique outcome (result or service or product) while

operations are repetitive work
4. How is a project coordinator different from an expediter?

A project expediter does not have any authority to make decisions. She only
enforces a decision made by the project manager. A project coordinator is
someone similar except that this person reports to a higher level manager and
so may have some inherent potential to influence decisions.
14
P R O J E C T
F R A M E W O R K
Practice Questions
1.
Which of the following is a common characteristic of most project lifecycle descriptions?

a) Staffing levels & costs are low at the start. Costs increases as project
gets into execution and then drops as the project nears completion.
b) More staff is required at the initiation of the project, and then gradually
decreases as the project approaches execution and completion.
c) Stakeholders have maximum influence during the final stages of the
product development
d) Project risks are peaking as the project approaches completion.
2.
All of the following are characteristics of a project EXCEPT:

a) Has a definite start date
b) Is temporary in nature
c) Is repetitive
d) The product of the project is more permanent
3.
An example of a project is
a) Constructing a 3-storied building
b) Paying your electricity bill on the 3 of each month
rd
c) Fixing a bug in a software program

d) Providing technical support to your customer over phone
15
P R O J E C T
4.
F R A M E W O R K
Acquiring team is part of which process group?

a) Initiating
b) Planning
c) Execution
d) Monitoring & controlling
5.
Defining and setting quality standards for your project is part of which
process group?
a) Initiating
b) Planning
c) Execution
d) Monitoring & controlling
6.
You have taken up a full-time role in a newly formed projectized

organization and you have been asked to lead a project. What BEST
describes your current role?
a) Co-ordinator
b) Process Manager
c) Expeditor
d) Full-time project manager
16
P R O J E C T
F R A M E W O R K
Answers to Practice Questions

Question
Answer
Justification
See FIGURE 9
Repetitive is a characteristics of operations
All other options are operations
Acquiring team is an execution process. We will discuss

this later in the course.
Setting quality standards is a planning process. We will

discuss this later in the course.
Note the keyword projectized
17
Initiating Processes
LEARNING OBJECTIVES
19
D E V E L O P
P R O J E C T
C H A R T E R
Chapter
2
Develop Project Charter
You are a Senior Manager with Financial Software Private Ltd, a small company that
provides IT application development services to clients. The mission statement of your
company is to be a leading provider of IT application development services to
Banks and financial institutions.
A prospective client approaches you with a request for development of a customized

accounting application. The high-level features of the proposed accounting package are
documented in a Statement of Work (SOW). As a Senior Manager you need to quickly
analyze and determine if Financial Software Private Ltd. can, or cannot, take up this
work. All you have is an SOW that describes the high level customer requirements.
Prepare Business Case

In order to make a decision you must perform an in-depth analysis using the SOW. As
part of your analysis you would ask several questions, some of which are:
Do we have required skills or capacity to undertake the proposed work?
What benefits financial as well as others - do we stand to gain if we take up

the work?
What costs would be incurred?
What opportunity would be lost?
You would then formally put down answers to these questions in a Business Case
document. In general, a business case document is prepared in response to a customer
request. It may also be created as a result of a market demand, or to analyze an
organizational, legal or social need. As a Senior Manager you would have prepared
business case documents in the past. However, if you have never prepared a business
case earlier you may have to refer to sample business case documents in your
organizations process database. The organization process database is a repository
which contains process and procedure documents, templates as well as sample
documents. This process database is referred to as Organization Process Asset.
20
D E V E L O P
P R O J E C T
C H A R T E R
Additionally, you may have to consult experts in your organization to make sure you
have included all the costs and benefits of executing the proposed work. Getting
experts internal or external - to review your business case is not a bad idea.
that influence development of a project charter like
your organizations infrastructure, regulatory requirements etc. must be considered.
Sign Contract
Once completed, the business case document would help you decide if you can take up
the work or not. If you decide not to take up the work the process ends here and you
do not need to initiate any project.
Lets assume that you decide to take up the work. You would then approach the client
and let her know of your decision. Once you and the client agree on the terms and
conditions, including financials, you would then sign a Contract. A contract is a
formal document signed by the seller (the party that is agreeing to undertake the work)
and the buyer (the party that is agreeing to pay the seller for the work performed).
Prepare Project Charter

After signing the contract you may start the Project Initiation activities at Financial
Software. You need to
1. Identify a Project Manager, and
2. Authorize the project manager to commit resources
Identify a Project Manager
You may think identifying a project manager is an easy task but please remember this is
one of the most important decisions. You will have to look at several factors such as
competency, availability, knowledge of domain etc.
Authorize Project Manager
This can be achieved by issuing a Project Charter to the project manager. A project
charter is a document that contains:
a) Description of the project
b) Name of the project manager and level of authority
c) Why is this project being executed
d) Pre-assignments (resources that are pre-assigned to the project)
21
D E V E L O P
P R O J E C T
C H A R T E R
e) High-level requirements of the project work

f) Description of the projects output/deliverables
g) High-level schedule (key milestones)
h) Budget and funding authority
i) High-level project risks (threats and opportunities)
A project charter is a key document for any project, more so in a matrix organization.
In a matrix organization, a project charter will allow a project manager to procure
resources from different functional departments to work on the project.
The previous scenario had just one customer approaching your organization for a
service. In reality there could be situations when you would have multiple customers
approaching you with a request for service. Your organization would have constraints
in providing services to customers. Constraints could be in terms of resource capacity,
knowledge of domain etc. Also, your organizations mission statement to be a leading
provider of software development services to Banks & Financial Institutions. Given
this mission statement, your organization may not want to take up any work in the
domain of Media and Entertainment.
Project Selection
When you have multiple customers approaching you with a request for service, one of
your objectives is to determine which of the customer requests you would service. You
can use Project Selection Methods to help you decide. There are two broad categories
of project selection methods Benefit Measurement Methods and Constrained
Optimization Methods.
Benefit Measurement Methods
Benefit measurement methods are comparative methods in that you compare a
customer request with another customer request, and take up the one that would meet
your organizations goals and strategic plans. Murder Board, Scoring Models and
Economic Models are all type of benefit measurement methods.
is a method where a selection committee is setup to go through high
level objectives of customer requests/proposals. So if your organizations mission
statement is to be a leading provider of services for Banking and Financial Institutions,
then there is very little chance that a proposal for software development for a client in
the Media and Entertainment domain would get past this selection committee.
Murder Board
are more objective than murder board. Scoring models involve

identifying and objectively rating the needs and wants of each of the options. Lets
assume that your organization has received requests for service from 3 potential clients
Scoring Models
22
D E V E L O P
P R O J E C T
C H A R T E R
but your organization has capacity to execute only one. You would need to compare
the benefits of executing the projects against each other and select the one that gives
your organization the maximum benefit. FIGURE 11 shows an application of a scoring
model. In this example the proposal from Customer C is selected. Proposal from
Customer B is not evaluated as it does not meet mandatory criteria (or needs).
FIGURE 11: Scoring Model
You may use Economic Models to select a project amongst many projects. Several
economic models are available of which the following are more popularly used:
Net Present Value: A sum
of money offered now is more valuable than the same sum

of money offered later. Economists describe this as time value of money i.e., $ 1000
one year from today would be lesser than $1000. FIGURE 12 shows a sample
calculation of present value where the interest rate is known.
23
D E V E L O P
P R O J E C T
C H A R T E R
FIGURE 12: Present value calculation
While executing a project you may have to commit and expend resources (cash
outflows) through the duration of the project while you start getting benefits (inflows)
of the project usually after the projects product/service is implemented. While
analyzing the benefits of a project you would have to use Net Present Value (NPV) i.e.,
the present value of all cash inflows minus the present values of all cash outflows.
While selecting projects you would select the one that has a higher net present value.
FIGURE 13: Project selection using NPV
IRR is a measure of profitability of investment made

on a project. The higher a project's internal rate of return, the more desirable it is to
undertake the project
Internal Rate of Return (IRR):
Payback period is the duration or length of time required to recover

the investment made in a project. Shorter the duration of payback, better are the
chances of that project being selected. If a project costs $10,000 and the annual return
is $2,500 then the payback period is 4 years ($10,000/$2,500)
Payback Period:
24
D E V E L O P
P R O J E C T
C H A R T E R
BCR provides a numeric relationship between costs of a

project to its benefits. A ratio of 1 or more means the benefits are more that the costs.
When you have options select a project that has a higher BCR. A BCR of 3.0 means
the revenues from the project are 3 times its costs.
Benefit Cost Ratio (BCR):
Depreciation:
Assets are used to produce goods and hey indirectly bring in revenue.
Assets lose value over time due to usage, wear and tear, technological obsolescence etc.
This loss of value of an asset is called depreciation. There are several methods of
calculating depreciation.
Straight-line method:
Accelerated Depreciation:
This method assumes that an asset loses equal value

each year. For example if an asset costs $1000 and the useful life of the asset is
3 years, the asset will lose $1000/3 = $333 each year. At the end of 3 years the
asset loses its complete value.
This is more realistic method of calculating
depreciation. An asset is assumed to lose more value initially and slightly lower
values as each year passes by. Sum-of-digits-of-year is a method of calculating
accelerated depreciation.
Constrained Optimization Models

Constrained Optimization Models includes Operations Research techniques such as
Linear Programming, Goal Programming and Dynamic Programming.

1.
Who prepares the Project Charter?

Anyone who has knowledge of the proposed work can prepare a project
charter. In the scenario in this chapter we saw the project charter was
created by the Senior Manager. The Senior Manager may delegate the
creation of the project charter to a sub-ordinate. In some cases even a
customer can prepare a charter. However, the Senior Manager is
accountable to sign-off the project charter.
2.
Who issues a Project Charter?

A senior person external to the project is responsible for issuing a charter.
This could be the senior manager of the performing organization, the
sponsor, the project initiator, the Head of the PMO or any other person at
a senior level of authority.
3.
What are the common inputs to developing a project charter?

In the scenario we discussed the following input documents were used to
develop a charter:
25
D E V E L O P
4.
P R O J E C T
C H A R T E R
Statement of work, which describes the high level requirements.
A business case document, which describes why a project must be

executed.
A Contract, that lays out the terms and conditions as well as the
financial reward for executing the project.
Organization Process Assets, a repository of processes, procedures,

sample documents, templates etc. if the person creating a project
charter is doing so for the first time.
The culture of the organization is also a key input that needs to be

considered while developing a project charter. This is called the
Enterprise Environment Factor.
Does every project need a project charter?

Project charter is required for any project performed for an external
organization. For projects that are sponsored internally, an email from the
senior manager/sponsor describing the project, its objectives and
authorizing the project manager would fill in the need of a charter. No
separate charter would be required in this case.
5.
What is the significance of a project charter?

The primary objective of a charter is to authorize the project manager to
commit organizational resources
6.
What tools and techniques would you need to develop a project charter?
You may have to get inputs from experts (people that have developed
project charters earlier) while developing a project charter. You may also
have to get the charter reviewed by experts once complete. Expert
judgment is an important tool/technique for developing a project charter.
7.
You have been asked to select one of two projects Project A which has a
BCR of 2.5 and another Project B that has a BCR of 1.8. Which one
would you select?
You would select the project which has a higher BCR (Project A in this
case)
26
D E V E L O P
P R O J E C T
C H A R T E R
Practice Questions
1.
Your manager wants to authorize a new project in your organization. What

should she do FIRST?
a) Create a Project Management Plan
b) Identify all the risks that may impact he project adversely
c) Understand the detailed requirements of the project
d) Develop a project charter
2.
What does a BCR of 3.1 mean?

a) Project investment is 3.1 times the benefits
b) Internal Rate of Return is 3.1 times the current interest
c) Project revenue is 3.1 times the costs
d) Net profit is 3.1times the costs
3.
Double declining is an example of

a) Normal Depreciation
b) Accelerated Depreciation
c) Payback Period calculation
d) Straight line Depreciation
4.
A project charter contains all of the following except

a) Name of the project manager
b) High level project risks
c) Pre-assignments
d) Traceability matrix
27
D E V E L O P
P R O J E C T
C H A R T E R

Question
Answer
Justification
Development of the project charter is the first thing to be

done on any project
BCR is benefit cost ratio (so its benefits or revenues v/s

costs)
Double declining is an example of accelerated depreciation
Traceability matrix is an output of collect requirements

process. Others are part of a charter.
28
I D E N T I F Y
S T A K E H O L D E R S
Chapter
3
Identify Stakeholders
Your senior manager just walked up to you and asked you to be a project manager on
the new project to which you readily agreed. She also issued a project charter to you
authorizing you to commit the organization resources on your project. What do you do
next? Your next step is to identify ALL the stakeholders.
Identify Stakeholders is part of the Project Communications Management knowledge
area. Stakeholder identification is done as part of Initiating processes. Lets revisit the
definition of a stakeholder. A stakeholder
is an individual (like the sponsor or the project manager), a group (like
the performing organization, the project team etc.), or an organization
(like the Government, the requesting organization etc.) that have a share
or interest in the project
Why Identify Stakeholders?

It is important that you identify all the stakeholders of the project. This is because some
stakeholders like end-users (of the projects product), their heads of department and
others like them are responsible for specifying the requirements for the project. If you
miss even one the requirements what you and your team would be working on would
not be complete. You must also remember that implementing new requirements at a
later stage in the project is more expensive. Therefore it is best for you to spend a good
proportion of your time in identifying the stakeholders. The list of stakeholders will
vary with Project characteristics such as size, scope (impact on Business), Complexity.
A small departmental IT project for example may have just 2-3 stakeholders (Endusers, Middle Management, and Project Team) while a large IT project that has
dependencies on external organizations may have many stakeholders such as Legal
Team, Multi-departmental business users, Heads of Departments, Vendors, Company
Shareholders, Regulatory Authorities etc.
It is important when developing the list of stakeholders to focus on both who they
are and what their agenda is with respect to the project.
29
I D E N T I F Y
In order to identify the stakeholders you would need to review the Project Charter.
You would also need to review the high level requirements that were specified in the
statement-of-work. Documents like the SOW, Request for Proposal (RFP) and the like
are referred to as Procurement Documents and is another input to the identify
stakeholder process.
and Organization Process Assets are also inputs to
this process. In order to identify all stakeholders you will have to consider answers to
the following questions1:
Who are the people (or organizations) that may be affected by the project
activities?
Who are the people (or organizations) that would be contributing to the
project activities by providing resources, people, money etc.?
Who are the people (or organizations) that would be using the projects
product?
Identification of stakeholders involves writing down the names of your project

stakeholders along with their goals, interests, expectations and concerns. This will
require you to interview the stakeholders and this in turn will help you identify more
stakeholders. Once you are done interviewing and gathering information on the
expectations of the stakeholders you would need to analyze each one of them. This
involves studying the impact or support each of the identified stakeholders could
provide to your project. This will help you categorize the stakeholders into
homogeneous groups. The idea of categorizing the stakeholders into groups is to
develop strategies of managing these groups of homogeneous stakeholders rather
that developing a strategy for each stakeholder that will be very time consuming.
Power-Interest or Power-Influence grids2 are some of the models you may use to
categorize and develop strategies for the stakeholders.
As mentioned earlier you must identify ALL the stakeholders. It is best for you to
review the list of stakeholders with experts. Experts Judgment could be sought from
individuals like your senior manager, experienced project managers, key stakeholders
you have already listed in your stakeholder register and subject matter experts. This
review will help you assure that the stakeholder list is complete.
You document the names of stakeholders in a Stakeholder Register. A small portion
of a stakeholder register is shown in FIGURE 14.
Managing Projects: Expert Solutions to Everyday Challenges, Harvard Business School Press, 2006.
PMBOK Guide 4th edition Pg. 249
30
I D E N T I F Y
FIGURE 14: Portion of a Stakeholder Register
The stakeholder management strategy document you developed must at the

minimum have for each stakeholder the following information:
Name of the stakeholder
Interest and influence on the project
Possible impact to the project
Category / Group
Likely strategy you need to adopt
Be careful not to share the strategy document with other stakeholders because more
often than not you the document would contain some sensitive information.
Common Mistakes made while Identifying

Stakeholders
Some common issues and confusion that arises in the process of identifying
stakeholders that should be avoided are:
1.
Making the System-owner the primary stakeholder rather than the

User-owner. The User-owner is the person with direct P&L (Financial)
responsibility for the project outcomes (e.g., line managers) and they would
be primary stakeholders. System-owners on the other hand bring the
31
I D E N T I F Y
needed expertise to execute the project e.g., Technical, Managerial,

Sourcing. In projects System-owners who have long experience working
with the business and existing systems take over roles of user-owners
not always to the benefit of the project and should be flagged as a potential
source of increased risk.
2.
Not considering stakeholders that have an Indirect influence on the

project. In projects that are executed for public use, Press\Media has an
indirect strong influence on other stakeholders such as shareholders when

it highlights repeated delays and infighting within the project team. This in
turn can affect project funding. Large projects with uncertainties need to
employ suitable Media management experts to manage this risk.
3.
Incorrectly assuming agents of a Client such as Contractors to be

fully controllable by a Client. For example a major Government weapons
development project was considered to have low risk because it had

stringent contracts with its Prime Contractor (who was the agent of the
Client). When the prime contractor failed it was found they could pass on
their liability to their sub-contractors one of whom was owned by the
Government. As a result ownership of part of the liability came back to
rest with the Government.
4.
Not breaking down composite groups to understand roles of their

individual constituents. The assumption that all constituents of a
composite group have aligned interests is often not true. In an

organization where multiple departments are involved in a project each
will bring a different agenda Marketing may focus on speed and agility;
Legal\Audit on Compliance and Security; Finance on costs and revenues.
Any composite group consisting of people from different functions needs
to be assessed in terms of their individual functions.
5.
Wrongly assuming mapping of stakeholders is a one-time activity.
Stakeholders, their interest, influence is a function of time and stakeholder

mapping needs to be a continuous dynamic activity. In some cases primary
stakeholders leave and are replaced with new stakeholders that can
possibly have a different agenda and interest in the project.

1.
Some of your stakeholder changed in the middle of your project. What

would you do in this situation?
This scenario is quite possible. It is important that you categorized the new
stakeholder into the groups you have formed and start managing their
expectations including responding to their queries and ensuring your keep
them informed about the status of the project. If the new stakeholder
32
I D E N T I F Y
expects you to change the direction of the project make sure that you
include all other stakeholder in such discussions and decisions.
2.
Why do you need a stakeholder management strategy?

It is important for you to understand the influences of a stakeholder on
your project. Not all stakeholders will have positive influence on your
project. Your strategy must be to minimize the negative influences and
impact of your stakeholders.
Practice Questions
1.
Identify stakeholders is part of which process group?

a) Initiation Process Group
b) Planning Process Group
c) Execution Process Group
d) Monitoring Process Group
2.
Identify Stakeholders is part of which knowledge area?

a) Integration Management
b) Scope Management
c) Communications Management
d) Time Management
3.
A key output of Identify Stakeholders is

a) Project Charter
b) Stakeholder Management Strategy
c) Stakeholder Analysis Document
d) Power-Influence grid
33
I D E N T I F Y

Question
Answer
Justification
Identify Stakeholders is part of the Initiating Process

Group
Communications Management
Others are either tools or inputs
34
Planning Processes
LEARNING OBJECTIVES
35
C O L L E C T
R E Q U I R E M E N T S
Chapter
4
Collect Requirements
You must now be familiar with the process of identifying stakeholders on your project.
You must also be comfortable classifying your stakeholders into well-defined groups.
Next, you must figure out your stakeholders needs. This process is called Collect
Requirements. This is the first step in the Planning Process and is part of the Scope
Management Knowledge Area. The primary purpose of this process is to define and
document the needs of the stakeholders as they relate to meeting project objectives.
This process is critical because most of the other planning processes are directly
dependent on the outcome of this process. At the end of this process you must have a
document that contains all your stakeholders requirements as well as a document that
tells you how you would manage a change to these requirements.
This process involves understanding high level requirements of the project, speaking to
the right people and gathering detailed requirements from them. You must gather not
just the functional requirements (such as what features must the product contain) but
also the non-functional requirements (such as technical performance of the product,
reliability etc.).
As a project manager you can study the Project Charter to understand the high level
requirements. You need to speak to stakeholders to obtain detailed requirements. The
Stakeholder Register will help you identify the stakeholders you need to speak with.
The Project Charter and the Stakeholder Register are, therefore, key inputs to the
Collect Requirements process.
Gather requirements from stakeholders

If the number of people you need to talk to is small (i.e., 1 to 10 people) you may have
a 1-on-1 interview with each of those people and document the detailed requirements.
You can prepare the questions well before the interview. This allows you to be
structured and gather a lot of information in a short time. Interviews work well when
you have to get answers from subject matter experts and end users.
Doing a 1-on-1 interview would be very time consuming if the number of people you
need to speak to is a big (i.e., between 10 and 25 people). In this situation you are better
36
C O L L E C T
off getting all the stakeholders into one room and conducting either a requirements
gathering facilitated workshop or a focus group session. In a Focus Group, as a
facilitator, you may ask questions that relate to the project requirements. Stakeholders,
that are primarily subject matter experts, can interact with each other, debate on key
issues relating the project requirements and provide feedback.
When you have to collect requirements from stakeholders that belong to different
departments you may want to conduct a Facilitated Workshop. This is a forum which
provides cross-functional stakeholders to discuss and define requirements for the
project.
If the number of people you need to speak with is very big (i.e., more than 25 people)
then you can design questionnaires, send it to the respondents and solicit their inputs.
Dont expect all of those you sent the questionnaires to, to respond. Another way to
gather information would be to conduct surveys.
On some projects you may be in a situation where key stakeholders are just not capable
of specifying requirements clearly. In such situations, you will have to help by
developing prototypes with whatever initial information you have. Stakeholders will be
able to provide better feedback and more clear requirements after reviewing the
prototypes. You can also gather information by observing the end-users perform their
work and documenting those activities.
Make quick decisions

There is always a high probability of conflict when several stakeholders are involved in
providing requirements. As a project manager you need to ensure quick resolution to
such conflicts. There are many ways to make decisions in a group setting. Some of
these are:
Unanimity:
All members of the group may agree to a decision. This is called
Unanimity.
Majority:
As a Project Manager you can decide to choose an option that has

the support of more than half the number (more than 50%) of participants.
Plurality:
If there is no clear majority, you may decide on an option that has

the support of the largest number of participants
Dictatorship:
One person (preferably you) makes a decision on behalf of the
entire group.
37
C O L L E C T
Use creative techniques

Creative techniques can be used to collect and document requirements. Some of the
creative techniques you can use are:
Brainstorming:
Get together a group of people, put a theme (e.g., What

should the logo for the team look like?) on the table and get them to generate
ideas.
Delphi:
This technique utilizes expert opinion. Responses to questions on

requirements are sought from experts. Experts provide feedback on the
requirements anonymously.
Mind-mapping:
record ideas.
Mind-map is a diagramming technique used to generate and
Nominal Group:
This is a sort of brainstorming exercise where ideas are

generated. Further it is put to vote and ranked. Ideas that have low ranks are
eliminated.
Affinity Diagram:
This technique sorts ideas into groups that are analyzed
further
Outputs of Collect Requirements

Outputs of collect requirements process include Requirements Document, the
Requirements Management Plan and the Requirements Traceability Matrix. These are
discussed in detail.
Requirements Document
As discussed earlier in this chapter, all the requirements must be documented.
Documenting the detailed requirements is very important because this way you will
know what to build or deliver. This can also help you measure & track your teams
progress. The requirements document must be reviewed and signed-off by the key
stakeholders. This document, therefore, becomes the basis for planning the project.
FIGURE 15 shows the tables of contents of a typical requirements document for a
software development project.
38
C O L L E C T
FIGURE 15: A typical requirements document
There is a strong possibility that some of the requirements would be conflicting with
each other. As a Project Manager it is important that you manage and balance these
conflicting requirements. In most cases you will have to also prioritize requirements.
The Business Case and the Project Charter are two key documents that you can fallback on to make quick decisions on conflicting and competing requirements.
39
C O L L E C T
Requirements Management Plan

Requirements management plan is a document that specifies how changes to
requirements will be managed throughout the project. This document also states how
requirements would be analyzed, prioritized and tracked. Some of the benefits of
requirements management plan are:
It serves as a document that documents a common understanding of

requirements related activities
It communicates what requirements related activities will be completed, when

and by whom.
The requirements management plan is a subsidiary of the Project Management Plan

we would be discussing the Project Management Plan in more detail in Chapter XXX.
Requirements Traceability Matrix
A traceability matrix is a document that tracks the attributes of a requirement
throughout the project. It specifies how a requirement has been implemented in the
projects product. This is useful tool to help you verify that all agreed requirements
have been implemented and that no additional features are provided. A template for a
requirements traceability matrix is shown in FIGURE 16.
FIGURE 16: Requirements Traceability Matrix
40
C O L L E C T

1.
What is Job Shadowing?

Observation is also referred to as Job Shadowing. This is a technique to
gather requirements when stakeholders cant articulate the requirements
clearly.
2.
What are Joint Application Development sessions?

Joint Application Development is a facilitated workshop. It is quite
common in rapid software application development projects where a
customer/user representative participates full-time in requirements
collection exercise with the project team.
3.
What is the difference between Product Requirement and Project

Requirement?
Project requirements include business requirements, delivery requirements
etc. while product requirements include performance requirements,
security requirements etc.
Practice Questions
1.
Document that specifies how requirements will be analyzed, prioritized

and managed is:
a) Requirements Traceability Matrix
b) Requirements Document
c) Requirements Management Plan
d) Project Charter
2.
Which document helps the project team track a requirement from

specification through implementation?
d) Project Charter
41
C O L L E C T
3.
All of the following are group decisions making techniques EXCEPT

a) Unanimity
b) Majority
c) Creativity
d) Dictatorship
4.
All of the following are outputs of Collect Requirements process

EXCEPT
d) Work breakdown structure
5.
When stakeholders are unable to articulate their requirements you would

use this technique to collect requirements:
a) Interview
b) Job Shadowing
c) Brainstorm
d) Delphi
42
C O L L E C T

Question
Answer
Justification
Primary contents of a Requirements management plan
Function of a Requirements Traceability Matrix
Creativity is not a decision making technique
WBS is not an output of Collect Requirements process
Observation is also called Job Shadowing
43
D E F I N E
S C O P E
Chapter
5
Define Scope
You have now completed gathering and documenting the project requirements. You
now need to get a clear picture of all the work that needs to be done by the project as
well as work that will not be done by the project. You will do this as part of Define
Scope process. This process follows the Collect Requirements process and is also part
of the Scope Management Knowledge Area. The Requirements Document you
created in the previous process can be considered to be a wish list of ALL the features
that stakeholders would want in the final product. You need to review the
requirements you have just gathered along with the Project Charter and identify and
prioritize only those that are specified in the charter.
In some cases you would find it difficult to understand if a particular requirement is
specified in the charter or not. In such instances you will need to build upon and
develop detailed description of the requirements/deliverables. You would also need to
analyze the project constraints and assumptions.
Once you are done reviewing the requirements, you need to separate out those
requirements that will be done (inclusions) and those that will not be done
(exclusions). The inclusions and exclusions are documented in the Scope Statement
In addition to the Project Charter and Requirements Document that are key inputs to
the Define Scope process as seen above, you will also need to refer to your
Organizations Process Assets such as standard templates for preparing scope
statement, scope statements of previous projects and any other documents that would
help you in completing the scope statement for your project.
Developing Detailed Description of Requirements

The tools required to develop scope definition include:
This is a moderated forum provided to cross-functional
stakeholders to discuss and define requirements for the project.
Facilitated Workshops:
Product Analysis involves designing methods for translating project

objectives into tangible deliverables and requirements.
Product Analysis:
44
D E F I N E
S C O P E
Alternatives Identification:
Stakeholders may have different approaches to solving a

given problem. Alternatives Identification is a used to identify different methods of
accomplishing project work, or part of a project. Techniques such as brainstorming
and lateral thinking (or thinking outside the box) can be used to identify alternative
solutions.
Expert judgment means using someone an individual or an
organization - who has been through this earlier. This person (or organization) could
be internal to the performing organization or could be external like a consultant or a
professional body. Experts can help you analyze the scope of the project and their
participation in the review of scope statement will help you eliminate grey areas.
Expert Judgment:
Contents of a Scope Statement

A Scope Statement documents the project objectives, the project deliverables and the
work required to achieve the objectives. It is important that all the objectives of the
project be quantified and when deliverables would be considered complete, as much as
listing what work will not be done as part of the project. A well-written, clear scope
statement is an effective tool in managing project scope creep and be used effectively
in managing changes as well as disputes related to the scope of the project. You may
have to update project documents such as the Requirements Document and the
Requirements Traceability Matrix.
FIGURE 17: Contents of a typical scope statement
45
D E F I N E
S C O P E

1.
What is the difference between Product Scope and Project Scope?

Product scope means the features of the product or service that your team
would be building while project scope means figuring out what all the
work that needs to be performed to build the product or service.
2.
What does the term scope creep mean?

Scope creep means uncontrolled changes that require the team to work
extra. You can avoid scope creep by completing planning approved
changes
3.
What is the difference between Requirements Document and a Scope

Statement?
Requirements document contains functional as well as non-functional
requirements.
Scope Statement states all the work that will be done as part of the project.
It states what would be done and what would not be done.
Practice Questions
1.
One of the inputs to define scope process is

a) Requirements Document
b) Requirements Traceability Matrix
c) Scope Statement
d) Facilitated Workshop
2.
Project Scope is
a) The same as product scope
b) The work that needs to be done to complete the product or service
c) Features that characterize the product or service
d) Subset of the product scope
46
D E F I N E
3.
S C O P E
A project scope statement contains

a) Alternative approaches to creating the product or service
b) Detailed description of the projects deliverables & work to be
performed
c) Work packages complete with the code of accounts
d) Estimates for each component in the WBS
4.
General management techniques that can be used for identifying

alternatives include all of the following EXCEPT:
a) Brainstorming
b) Lateral Thinking
c) Pair-wise comparisons
d) Organization process assets
5.
A project scope statement has been created jointly by all stakeholders.

However project requirements have been changing after the start of
execution. What is the cause of the problem? BEST answer is that the
a) Customer did not approve the scope statement
b) Customer requirements were not properly gathered
c) Project Scope statement was created before the requirements
d) Project Manager should have been more assertive when framing
scope statement
47
D E F I N E
S C O P E

Question
Answer
Justification
Other options are not inputs
Project Scope is the work to be accomplished, and is

different from Product Scope
See contents of a scope statement
Organization process assets are not general management

techniques
Requirements were not collected completely resulting in

changing requirements Customer does not have to
approve the scope statement. Option C and D are not
something that can be concluded based on the given
information
48
C R E A T E
W B S
Chapter
6
Create WBS
The Scope Statement developed in the previous process states what deliverables the
project will need to produce. You now need to define all the work you and your team
would need to perform in order to produce the deliverables. The Create WBS process
helps you define all the work that the project will need to perform by hierarchically
breaking down the project deliverables into smaller, manageable components with each
descending level of WBS representing an increasingly detailed definition of work
specified in the scope statement3. The idea is if any work is not part of the WBS then it
is not part of your project work.
FIGURE 18 shows the WBS for Project Persist. You must note that some of the nodes
(eg. 3.0 Sub-project X and 4.0 Phase 2) of the WBS are yet to be broken down into
more detailed components. They would need to be analyzed and broken down further
to get a complete picture of the project. Also, the connection between the nodes does
not mean the WBS shows dependencies and constraints. We will learn more about
dependencies in the later lessons.
FIGURE 18: Partial WBS for Project Persist
PMBOK 4th Edition, Pg. 116

49
C R E A T E
W B S
Defining Work Packages

The lowest level of WBS components is called work packages. Work packages are units
of work that you and your team can use to organize your project. In other words, work
packages are components at a level of detail that the project team can associate time
and cost estimates independently. The higher levels of the WBS are used to organize
the work packages. Once the WBS for your project is complete you would be able to
visualize the work that would need to be performed by you and your team. The WBS
can also be used as an effective aid for communications amongst all stakeholders.
The inputs to the Create WBS process are the Scope Statement and the Requirements
Document.
In addition, you would also need to refer to your Organizations Process Assets such as
standard templates for WBS, sample WBS created by previous projects, lessons learnt
etc.
Decomposing a Deliverable
The tool to create the WBS is called Decomposition. Decomposition involves4
1.
Identifying and analyzing the deliverables and related work
2.
Structuring & organizing the WBS
3.
Breaking down the upper WBS levels into lower level detailed components
4.
Developing and assigning identification codes to the WBS components,

and
5.
Verifying that the degree of decomposition of work is sufficient
Size of a work package

How small or big can a work package be? There is no definitive answer to this
question. A general thumb rule is that a task should not be more than 5 days
duration (or 40 work hours) and not smaller than 8 hours. (Remember, in this
process we are only talking about work packages and not tasks tasks and
activities will be defined in the next chapter).
How many levels can a work break down structure have? Again, there is no
specific and definitive answer to this question. The WBS of a simple project could
PMBOK 4th Edition, Pg. 118
50
C R E A T E
W B S
have between 3 to 5 levels while that for a complex, large project would need
between 15 and 20 levels of decomposition to help you get the detail.
Outputs of Creating WBS

The WBS, shown in FIGURE 18, is the primary output of the Create WBS process.
However, the WBS alone will not meet your needs because it only show the names of
the nodes and work packages. You and your team will need much more information
about what each of the work packages mean. This is where the WBS Dictionary comes
into play. The WBS Dictionary (see FIGURE 19) contains all the information you and
you team need to perform work on each of the work packages.
FIGURE 19: Contents of WBS dictionary

1.
What is the 100% rule?

The work breakdown structure represents all the work to be performed on
the project including project management work. The total of the work at
51
C R E A T E
W B S
the lowest levels must roll-up to the higher levels so that nothing is left out
and no extra work is performed. This is called the 100% rule5.
2.
What is Decomposition?
Decomposition is a tool/technique used to create the WBS. It involves
hierarchically breaking down a projects product into lower level
components up to the level of work packages.
3.
What is a work package?

Work package is the lowest level of components in a WBS. This is the
level at which a project team can associate realistic cost and effort
estimates.
4.
What is a Scope Baseline, and what does it consist of?

Generally speaking, baselines are snapshots that you can measure your
projects performance against. Scope baseline is a snapshot of approved
work that needs to be performed by a team. The scope statement, the
work breakdown structure and the work breakdown structure dictionary
put together is referred to as scope baseline.
5.
Why should we assign identification codes to components in the WBS?

Assigning identification codes help stakeholders identify not just the level
at which a given component of project work is at but also its category.
Practice Questions
1.
Decomposition is:
a) An input to the define scope process
b) A tool to create the work breakdown structure
c) Part of the scope baseline
d) The lowest level of component in the WBS
2.
You have been asked to sell the concept of WBS in your organization.
What amongst the following is the BEST selling points:
PMBOK Guide, PMI, USA, 4th Edition. Pg 121
52
C R E A T E
W B S
a) WBS will help PMs and stakeholders identify what is required and
what is not
b) WBS is a great graphical tool that can be used to collect requirements
c) WBS represents what cannot be illustrated in a project charter
d) WBS can be used to help induct staff into your project
3.
Scope baseline consist of all of the following EXCEPT:

a) Requirements Document
b) Scope Statement
c) WBS Dictionary
d) Work breakdown structure
4.
You have been appointed the project manager of a project that is in its
execution phase. You realize that the project does not have a WBS. What
is the BEST thing for you to do?
a) Call for a team meeting to discuss the crisis and then document the
actions
b) Let your senior manager know and continue with the project
c) Stop the project, document the WBS first and then re-start the project
d) Do nothing different, let the project continue as it was
53
C R E A T E
W B S

Question
Answer
Justification
PMBOK Guide, 4th Edition, Pg. 118
Generally, the idea is if it is not in the WBS it must not be

done.
PMBOK Guide, 4th Edition, Pg. 122
If you have not defined and baseline the scope and started
execution then this is a recipe for disaster. Best is to stop
the project, get the WBS done and then re-start the project.
54
D E F I N E
A C T I V I T I E S
Chapter
7
Define Activities
You must now know the importance of a WBS and must be familiar with creating
WBS. While creating WBS we broke the project deliverables down into work packages.
The next step is to break these work packages further into activities. You can break a
work package into smaller components by identifying specific actions required to be
carried out to complete the work package. These actions, listed with an identifier and
description, are called activities.
S C O P E
B A S E L I N E
Scope Statement
WBS
WBS Dictionary
The Scope Baseline is a key input to identifying and defining activities. The project
deliverables, the constraints and assumptions will need to be reviewed while defining
activities. Other inputs are:
- an example would be the Project Management
Information System (PMIS) which is a computer-based application that helps you
define, store, manage and report the activities
You might want to refer to an activity list of a

historical project just to get some ideas on definition of activities.
Creating an Activity List

An activity list can be developed using different techniques or tools. Following are a
few of them.
In order to define activities you need to analyze and break down the work packages
into smaller components. You also need to refer to the scope statement, constraints
and assumptions and analyze any actions required to meet them. Team members that
would be partaking in the delivery of the work package can also be consulted to
determine actions required to complete the work package. Team members
contribution will improve accuracy of the definition of activities. The technique of
identifying activities by breaking down a work package is called as Decomposition.
It is generally understood that if each activity in the work package can be estimated
independently then the work package decomposition is complete. The sum of effort of
all activities determines the effort required to create the work package.
55
D E F I N E
A C T I V I T I E S
In situations where the team members are not very experienced decomposition of the
work packages can be carried out in consultation with experts or people in other
project teams. This technique of utilizing experienced, skilled resources to define
activities is called Expert Judgment.
Reviewing the activity list a complete list or a list of a section- of historical projects is
also quite useful. This would help you identify activities for your project quickly.
Organizations that have a mature process may have standard templates for defining
activities. Templates are tools that help improve productivity while executing repetitive
work. For example, templates can be used to define activities for construction of multistoried buildings where multiple floors are similar to each other.
Not all project requirements are clearly defined on day 1. In most projects
requirements evolve gradually. As such you may have complete and clear information
only on some of the deliverables, not all. Work packages for which you have the
required information are decomposed into activities. The work packages that you do
not currently have complete & clear information are represented by milestones. They
are decomposed at a later point in the project when you have more information. This
form of activity planning is termed as progressive elaboration or iterative planning or
agile planning or rolling wave planning (shown in FIGURE 20). This type of planning
is most suited to risky IT projects or R&D type of projects.
FIGURE 20: Rolling Wave Planning
Define Activity - Outputs

The activity list obtained by decomposing the work packages is the key output of the
define activity process. It is the basis for all the cost and effort estimates. An activity list
56
D E F I N E
A C T I V I T I E S
includes an identifier and a description that reflect the scope of work to be performed
as part of that activity.
An activity list alone cannot provide complete information. Activity attributes is the
metadata of an activity. It provide information about the activity such as the person
responsible for completing the activity, the predecessor and successors of the activity,
constraints such as start or finish date etc.
As you start executing your project and performing activities you would need to
continuously check if your project is on track. Milestones are planned review points
they have no effort and are used to indicate the start or completion of significant
activities. A general thumb rule is to plan one or two milestones every week. Milestone
can also be used to indicate work that is still not very clear. As discussed earlier, there is
a high degree of probability that information about project requirements would evolve
at a later date. However, the unavailability of clear requirements must not distract you.
You must schedule deliverables that you do not have much clarity on currently as
milestones. These can be expanded into activities later when you have sufficient
information to progress with their decomposition. The milestone list is therefore an
important output of the define activities progress.

1.
How do we know that decomposition of a work package into activity is

complete?
It is generally understood that if each activity in the work package can be
estimated independently then the work package decomposition is
complete.
2.
How do you improve the accuracy of the activities defined?

You can improve the accuracy of the definition of activities by:
3.
Reviewing activity lists of historical projects, and including those that

you may have missed out.
Consulting with experts or persons that have executed similar work

earlier
Consulting with project team members that are responsible for

executing those activities
How do you improve the productivity of activity definition?
Reviewing and using templates meant for activity definition

57
D E F I N E
A C T I V I T I E S
Reviewing the organizations knowledge base regarding activities used

by previous projects
Practice Questions
1.
Some of the work packages in a big project involving construction of

national highways can be for now reduced to a milestone level and later
decomposed into activities. This technique is best known as
a) Rolling Wave Planning
b) Decomposition
c) Define Activities
d) Develop Schedule
2.
Milestones are:
a) Activities with large duration
b) Activities with small duration
c) Activities with no duration
d) Two activities added together
3.
Milestone charts are used

a) To discuss progress of project with team members
b) To discuss progress of project with senior management
c) To analyze project risks
d) To perform detailed planning
58
D E F I N E
A C T I V I T I E S

Question
Answer
Justification
Decomposition means breaking down deliverables into

components while rolling wave is planning when more
information becomes available
Milestone has no effort or duration
Milestone charts do not have much details so best used

for discussing status with senior managers
59
S E Q U E N C E
A C T I V I T I E S
Chapter
8
Sequence Activities
Once you have an activity list, an attribute list and a milestone list you can start
sequencing the activities. Sequencing means arranging the activities in an order based
on relationships and dependencies between each other. For example, the activity
Prepare the System Test Plan will be followed by a Review of the System Test Plan. The review
cannot precede the preparation of the system test plan. It is important that you arrange
all the activities in the required sequence. All activities and milestones except the first
and last must be connected. Activities that do not have a successor or a predecessor are
called hammocks and are not recommended. Hammocks are only used in representing
higher level summary without showing the detailed relationships. Note that a single
activity can be linked to multiple activities (i.e. two or more successors or predecessors)
or milestones (dependencies)
To perform sequencing of the activities you can use any of the commercially available
project management software applications such as MS Project or Primavera.
The Activity List, Activity Attributes and Milestone List are inputs to the sequencing
process. The Scope Statement, that includes product description, may contain details
that may dictate sequencing of activities to some extent and is, therefore, also an input
to the sequencing process. Organization Process Assets such as project scheduling
templates, procedure for preparing scheduled etc. will also be helpful in the sequencing
process.
Tools & Techniques to Sequence Activities

Sequencing the activities can be done in 3 stages. The 1st stage is to examine and
determine the precedence between activities. Precedence Diagramming Method
(PDM) is one of the techniques to determine the precedence. It involves creating a
diagram which shows activities in rectangles and relationships as arrows. . This method
is also known as Activity on Node (AON) and is an extension of scheduling
methodology for projects known as Critical Path Methodology (CPM). A sample
diagram drawn using PDM is shown in FIGURE 21.
60
S E Q U E N C E
A C T I V I T I E S
FIGURE 21: Precedence Network Diagram
PDM includes 4 types of precedence relationships between activities:

The start of the successor activities depends on the completion of the
predecessor activity. For example, you can decorate a cake only after the cake has been
baked. This type of dependency is shown in FIGURE 22.
Finish-Start:
FIGURE 22: Finish-Start precedence
Start of the successor activity depends on the start of the predecessor

activity. For example, icing required for decoration of the cake can be start
simultaneously as baking the cake. This type of dependency is shown in FIGURE 23.
Start-Start:
61
S E Q U E N C E
A C T I V I T I E S
FIGURE 23: Start-Start precedence
The completion of the successor activities depends on the completion

of the predecessor activity. For example, while delivering cakes to customers over-thecounter you can consider delivery of a cake to be complete the moment you have
completed decorating it to the specification of the customer as shown in FIGURE 24.
Finish-Finish:
FIGURE 24: Finish-Finish precedence
The completion of the successor activities depends on the start of the

predecessor activity. This is not a very common dependency. For example, you can
consider delivery of a cake to be complete the moment you have issued the bill to the
customer. This type of dependency is shown in FIGURE 25.
Start-Finish:
FIGURE 25: Start-Finish precedence
62
S E Q U E N C E
A C T I V I T I E S
The 2nd stage of sequencing involves determining dependencies. 3 types of

dependencies commonly used in sequencing activities are described below.
These are referred to as
nature of work. These can be determined by:
Mandatory Dependency:
hard-logic
and are inherent in the
Looking at the basic nature, standard processes of the product or service or

result to be delivered at the end of the project.
Asking the people who will work on each of the activities or experts in the
industry, as to what they need to complete their work on time.
Looking at the proposals, contracts and requirements documents agreed with

the customers who require your product, service or result.
Discretionary Dependency:
determined by:
These are referred to as
soft-logic.
These can be
Looking at the best practices followed in your organization for development of

the product or service or result to be delivered at the end of your project. The
order of these best practices could be changed during the project based on the
unique needs of the project. For example, the reports are generally tested after
the online display of a module, but this is just a best practice and not a
standard rule.
Asking the people who will work on each of the activities or internal experts in
your organization, as to what is the best way to complete the project with a
balance of speed, quality, cost efficiency.
These are relationships between project activities and

activities outside your project. External type of dependencies are found out by
External Dependencies:
Looking at the links between activities identified so far on the project and
activities outside the project. For example, to perform system testing on a
banking application we are dependent on the delivery of specialized pass book
printing hardware which is to be supplied by the customer prior to start of
system testing.
Looking at external demand factors or external time factors for availability of

material or common external infrastructure, suppliers or human resources.
The 3rd stage of sequencing involves performing some fine-tuning on the

relationships between activities determined so far. The most common way is to start
the successor activity after the predecessor activity is completed. This is also known as
the Finish-Start (FS) relationship. However, you can adjust the relationships of the
successor activities to start a few days earlier (accelerate) or few days later (delay) to the
completion of the first activity. Accelerating the start of a successor activity is called
63
S E Q U E N C E
A C T I V I T I E S
and delaying the start of the successor activity by a few days later is known as lag.
Please note that applying leads and lags must not replace the schedule logic.
lead
Applying of leads technique helps in development of realistic project schedule. In some

cases you can apply leads to compress the schedule by overlapping sequence of
activities
In order to expedite the development of a schedule network for your project you may
use a schedule network diagram templates. Parts of schedule network diagrams are
referred to as sub-network or fragment network.
Sequence Activities - Outputs

The output of this process is the Project Schedule Network Diagram. The schedule
network diagram is a graphical display of all project activities with the logical
relationships.
In this process you may also have to update activity list and activity list attributes
because you may discover new activities as you work through the project relationships.
You may also have to create new activities to mitigate or avoid risks that you and your
team would have identified while determining the sequence of activities.

1.
How do we know that the sequencing of the activities is complete?

Ideally, it is recommended that every activity and milestone should be
connected to two other activities (Successor and Predecessor) except for
the start and end activities. This provides a good indication of the
completion of the process of sequencing activities.
2.
How do you improve the productivity of the process of activity

sequencing?
You can improve the productivity by using standardized scheduled
network templates.
3.
What are hammocks?

Hammocks are activities that do not have any relationships defined in the
schedule network. Hammocks are not recommended.
64
S E Q U E N C E
Practice Questions
65
A C T I V I T I E S
S E Q U E N C E
A C T I V I T I E S

Question
Answer
Justification
1
2
3
4
66
E S T I M A T E
A C T I V I T Y
R E S O U R C E S
Chapter
9
Estimate Activity Resources
You have now completed sequencing the activities for your project. Next, you need to
estimate the type and quantity of people, material, equipment required for each of the
activities. This activity is close coordinated with the estimate costs processes explained
later in this book.
The Activity List and Activity Attributes are key inputs to this process. Yet another
key input is Resource Calendar. Resource Calendars provide information on potential
availability of physical raw material, equipment and human resources including their
grade, capacity and skill. This serves as a reference for the timing of booking of critical
resources in the project. For human resources this may reflect the planned leave and
trainings during the course of the project. For equipment this may reflect the
maintenance shutdown timings. For raw materials this may reflect the seasonal timings
when material is easily available. The Resource Calendar may or may not be fully
complete during planning and is continuously updated during the executing process
group. It is commonly updated as soon as the process of acquiring the team and
conducting the procurement is complete. Other inputs to this process are:
Enterprise Environmental Factors
An example of these factors would be

the easy access to skilled resources near cities that have lot of educational
institutions. Another example is the availability of commercial estimating and
risk databases in certain industries.
These would include access to your
organizations knowledge repository for procedures and policies related to
renting, procuring materials and human resources. It may also involve access to
past projects that used a particular skill of resources, type of equipment.
Developing Activity Resource Requirements

As stated earlier the primary intention of this process is to document the type and
quantities of resources required for each of the activities we defined in the earlier
processes. You can use any of the several tools or techniques to make this happen. A
common technique is to obtain Expert Judgment. This is a technique where you
consult experts in a domain, technology, industry for their inputs to estimate resources.
67
E S T I M A T E
A C T I V I T Y
R E S O U R C E S
You may also analyzing alternatives in order to find the optimal resourcing for the
activities. Alternatives Analysis is a technique for evaluating different options for
resource usage which include using experienced or inexperienced people, using manual
or automated tools, deciding to in-source or out-source.
You can review Published Estimating Data. Commercially available data or data
internal to your organization can help you handle new equipment or manage a new
resource skill at a new location. It is better to use or factor in the locally published data
when available, rather than use the global available data.
In case of complex activities you may use Bottom-up Estimating technique that helps
in decomposing an activity. The purpose of decomposing further is to estimate the
resources at a more detailed level. The decomposition is done till the resource estimates
can be done with a degree of confidence.
The basis of estimates is documented along with the activity resource requirements
so that any assumptions made during this process of preparing estimates are captured.
Developing a Resource Breakdown Structure

You may also prepare a resource breakdown structure (RBS). The RBS is a
hierarchical view of the names, quantity of resources deployed in the project by
category (labor, material, equipment) and type (skill, grade, capacity). The RBS can be
consolidated at an organization level and is useful for optimizing and allocating
resources to different projects. Commercially available project management software
is useful in managing the resource utilization through the defining, managing and
generating views of the RBS.
and the Resource Breakdown Structure you
produced using project management software are the key outputs of this process. You
will need to update the resource calendars based on refinements made during
estimation and additional new bookings of critical resources. You would learn more
about resource calendars n the Develop Human Resources Plan section of this guide.
Activity Resource Requirements

1.
When will you deploy a higher percentage of experienced resources,

typically?
The experienced resources are deployed at the beginning and the end of
the project during the high level design and test support.
2.
What documents are you likely to update during this process?
68
E S T I M A T E
A C T I V I T Y
R E S O U R C E S
Resources calendars would possibly be updated. As part of bottom-up

estimating you may decompose complex activities further. If you do you
will have to update the activity list and activity attributes.
3.
Resources Calendar was never produced during planning processes but

this is used as an input to this process?
Resource Calendar is generated during the Acquire Project Team &
Conduct Procurement processes. These are part of executing process
group. At this stage of planning you will have some basic information
about availability of resources. You will have to use that information. You
will have to continuously update the resource calendar as more
information becomes available.
Practice Questions
69
E S T I M A T E
A C T I V I T Y
R E S O U R C E S

Question
Answer
Justification
1
2
3
4
70
E S T I M A T E
A C T I V I T Y
D U R A T I O N
Chapter
10
Estimate Activity Duration
At this stage of your project you now have with you the following:
An Activity List
Activity Attributes, and
You now need to estimate the duration or work periods required for each activity. For
each of the activities you have identified, given the resources, you will have to estimate
the duration required to complete each of the activities. You will need to use available
information on project/activity scope (from the Scope Statement), required type of
resources and the quantity (available from Activity Resources Requirements) and
resource availability (from Resource Calendars). Other inputs are:
Enterprise Environmental Factors-
For example, the presence of skilled

resources in the organization or with accessible vendors, and the productivity
of latest computing equipment may significantly impact the duration of the
activity.
You may need to refer the corporate
knowledge repository for a policy, procedure documents related to calculating
duration based on average productivity. It may also involve access to past
projects for lessons learnt and buffers to apply.
Remember that Activity Duration Estimates are contributing to the duration of each
activity in the Project Schedule and Schedule Baseline that will be prepared at the
end of planning activities related to Time or Schedule. Remember also that the Activity
Duration Estimates are progressively elaborated using better input data of work effort
and number of resources available.
71
E S T I M A T E
A C T I V I T Y
D U R A T I O N
Developing Activity Duration Estimates

Activity duration estimates can be developed using different techniques or tools in
different means:
The Expert Judgment is a technique by which a project
manager consults the experts in a domain, technology, and industry for their inputs to
estimate duration. Also judgments can be made on which technique to use for which
activities.
Getting Expert Opinion
The Analogous Estimating technique is used for

estimating the duration of current activities based on past project activities due to
similarities in functionality or feature or complexity. For example, we review the effort
expended on similar activities on historical projects. Also, it is to be noted that we are
exercising expert judgment when deciding that an activity is similar to a past activity.
Reviewing historical information
This type of estimating technique is quick but not accurate.
The Parametric Estimating technique is used

for estimating the duration of current activities based on a historical statistical
relationship between duration in working days (or hours) and a unique productivity
parameter or variable. For example, based on past experience if 2 user interface screens
with an average 50 screen fields can be captured into user manuals in 1 working day(8
hours) by 1 person, then 100 such user interface screens can be done in 5 working
days(40 hours) by 10 person working as a user manual team. This type of estimating
Considering parametric information
is more accurate and is based on the data captured in the parametric estimating
model.
The Three-point
technique helps to improve the accuracy of estimates. This is done by
finding out the three estimates (optimistic, most likely, pessimistic) for the same activity
and then taking the weighted average of the three points. The most likely point is given
a weight of 4, compared to 1 for optimistic and 1 for pessimistic. This type of
estimating is also known as the PERT estimate. This is given by the PERT activity
estimate formula
Considering best case, most likely, worst case scenarios
Estimating
Estimate
Optimistic 4.MostLikely Pessimistic

6
If a simple average is used then the three point estimate is given by the formula
Estimate
Optimistic MostLikely Pessimistic

3
The PERT activity estimates are summed up at the project level to give the Project
PERT estimate.
72
E S T I M A T E
A C T I V I T Y
D U R A T I O N
The range of possible variation in activity estimates are calculated and documented
along with the activity duration estimates. The standard deviation can be calculated
using the simplified formula
Pessimisti c Optimistic
6
These are then used to calculate the activity variance
2
The activity variances for all the activities are summed up and then the square root of
the total sum is taken to give the project standard deviation.
Based on statistical probability relationship for a close to normal bell shaped curve
variations or Beta Distribution curve around the mean (project PERT estimate), we
can provide a probability of,
99.73% confidence in the estimate with a range of 3
FIGURE 26: Range of Activity Duration Estimates
The reserve analysis technique helps

to calculate time buffers or time contingency reserves and then added to the project
duration estimate. The EMV (Expected Monetary Value) analysis is a quantitative
technique for calculating the cost contingency reserve by multiplying the probability of
a risks and their cost impact for a given scenario. Here a variation of the same analysis
Considering project schedule uncertainty
73
E S T I M A T E
A C T I V I T Y
D U R A T I O N
can be used replacing the cost impact with the time duration impact for a given activity.
The value for the duration impact is taken based on type of risk as positive
(opportunity) or negative (threat). The net value of all such values is used as the
duration contingency reserve. A simple way to calculate the activity duration
contingency reserve for those activities that have uncertainty is to calculate it as a fixed
percentage of the activity duration estimates.
Activity Duration Estimates Outputs

Outputs of this process are:
These could be ranges of activity durations (between
63 and 78 days as shown in FIGURE 26 or a value based on confidence levels (such as
15% chance that the duration will not exceed 2 weeks).
Activity Duration Estimates
Includes updating assumptions you may have made

regarding some of the activities, or updating any other document that is impacted by
the duration estimates
Project Document Updates
74
E S T I M A T E
Practice Questions
1.
Activity Duration estimates include one of the following

A. Lag
B. Resources assigned
C. External Dependencies
D. Range or Confidence level
75
A C T I V I T Y
D U R A T I O N
E S T I M A T E
A C T I V I T Y
D U R A T I O N

Question
Answer
Justification
1
2
3
4
76
D E V E L O P
S C H E D U L E
Chapter
11
Develop Schedule
In the previous sections you learnt how to identify and define activities, sequence them,
estimate activity resources requirements and durations. Next, you need to analyze these
inputs to develop a project schedule. In a project schedule network diagram an activity
is used as the basic building block of the project schedule. The resources and duration
are then assigned to each activity. If a start date is given to the first activity in the
project schedule network diagram, then it is possible to generate a schedule using a
scheduling tool, which will assign a start and an end date to each activity, and an event
date for each of the milestones. This will also help you determine a project end date.
Inputs to this process are Activity List, Activity Attributes, Project Schedule
Network Diagram, Resource Calendar, Activity Resource Requirements; and
Activity Duration Estimates. We have discussed these in the previous chapters.
Other inputs you would need to develop a schedule are:
Project Scope Statement
To Refer to Assumptions and Constraints

Assumptions on the capability of resources, approvals of external authorities
are again validated during the simulations and changes in project schedule.
- an example would be the availability and
use of scheduling tool. This software application will help you to define
activities, resources, activity relationships between activities and display the
final project schedule for sponsor approval.
A key guideline document in the repository
will advise on the recommended scheduling methodology to be used under
different circumstances. Another key document would be the project files in
which project calendars are defined. The project calendar will define the
working hours in a working day, the holidays applicable during the project.
Develop Schedule Tools & Techniques

The schedule could be prepared using different techniques or tools in different stages,
77
D E V E L O P
S C H E D U L E
You can use the Scheduling tool to set the start date of the first
activity or starting milestone in the project. The duration of all activities and the
resources that will perform the activity are entered. Then all other activities are linked
to each other using the project schedule network diagram. Remember not to use any
hammock activity (free hanging activity). Now the Automatic Schedule option in the
tool can be triggered to determine the end date of the project.
Automation stage
You can apply different scheduling network analysis techniques to

different parts of the default project schedule generated by the Scheduling tool. You
can then analyze or integrate, or balance both the resource utilization and to develop
the schedule. This analysis is based on the applicability of following scheduling network
analysis techniques - Critical path method, Critical chain method, Resource leveling,
What-if-scenario analysis and Schedule Compression
Balancing stage
Critical path method (CPM)
Critical chain method (CCM)
is a technique with a focus on float availability so

that activities can be assigned schedule start dates with flexibility. The aim is to
have only one critical path with zero float (or flexibility) at any point of time
and manage its speedy completion. This will ensure that majority of the
activities in other network paths in the network diagram will have some float
(or slack). This will enable those activities to be delayed purposefully or to be
allowed to start later than planned, without delaying the project end date. This
method is useful in drawing attention of the Project Manager to what is critical
in achieving the timely project completion.
is a technique with focus on buffer placements
following the identification of a bottleneck activity with critical resources. The
activities on the path of the network which includes the resource constrained
bottleneck activity form the critical chain. This bottleneck activity is the weak
link that has to be strengthened. Normally this critical chain lies on the critical
path that is identified using the CPM method. The duration of the time buffers
added before (feeding buffers) and after (end buffers) the bottleneck activity
are monitored. This is done to prevent over-loading or under-loading of the
critical resource assigned to the bottleneck activity while at the same time
completing the project on schedule. This method is useful in achieving
maximum throughput with maximum utilization of critical resources (hence
minimum cost) along with achieving project schedule. This technique is based
on the Theory of Constraints proposed by Dr. Eliyahu M Goldratt who has
contributed significantly in the last 25 years towards its development and
application.
Another analogy from the healthcare industry where heart surgeries performed in a
given day is looked at as a project with a deliverables of maximum successful
surgeries and minimum time spent by patient at hospital. The resource constrained
bottleneck activity becomes the operation theatre in a critical chain. The physical
feeding buffers similar to the time buffers are the critical care units and the physical
end buffers are the critical care units or intensive care units. This will ensure that
the operation theatre is used efficiently to increase the throughput of surgeries. The
78
D E V E L O P
S C H E D U L E
hospital also saves cost by using the high cost surgeons for more surgeries
compared to another hospital which uses high cost surgeons for fewer surgeries.
Resource leveling
What-if-scenario-analysis
Schedule compression can be achieved in two ways:
is a technique with a focus on balanced loading of the

resources assigned to a project. The resource loading is viewed using the
resource histogram view after allocating the resources to the project activities
in Scheduling tool. The resources that are overloaded can be seen as peaks
above or valleys below the average level of loading of say 8 hours. Thus the
resource allocation can be modified to spread out or flatten the resource
loading. This may result in an increase in the project duration.
is a technique with a focus on simulating and
finding out the probability distribution of the most likely project schedule end
date. This is also known as the Monte-Carlo analysis
Crashing
Fast tracking
Here we balance the feasibility of a decrease in project

duration with an increase in cost. In reality, this is achieved by allocating
more resources in shifts, in overtime to achieve a tight deadline. However
it carries the risk of introducing burnout, low productivity and hence
increased cost in the project. Some standard or routine activities in a
project like construction of a road, installation of standard software on
computers are suitable to put a lot of people, where as other activities like
design are not suitable. In general, the law of diminishing return applies
when adding more people to IT projects due to overheads of training,
communication.
Here we balance the feasibility of a decrease in project
duration with an increase in risk of re-work. In reality, this is achieved by
performing as many activities as possible, in parallel with a lead. This leads
to overlapping of activities and hence increases the risk of re-work due to
changes in preceding activities.
The fine-tuned and realistic view of the project schedule can be

obtained by applying the following techniques:
Fine tuning stage
applying leads and lags
to reflect opportunity or threat scenarios in real life
projects,
the reality of being able to start an activity ahead of time(lead) or
the reality of having to wait for an input before starting an activity(lag)
Determining Critical Path

Determining the critical path involves determining the Early Start and Early Finish (as
well as the Late Start and Late Finish) for each of the activities in the network. A
79
D E V E L O P
S C H E D U L E
Forward Pass (FIGURE 27) helps you determine these early start and early finish times
as you work your way from the start towards the finish points. The early start for a task
that depends on completion of two tasks (i.e., that has two or more predecessor tasks)
is the maximum of the early finish of the predecessor tasks.
FIGURE 27: Forward Pass - Calculate Early Start and Early Finish times
A Backward Pass (FIGURE 28) helps you determine these late start and late finish
times as you work your way back from the finish towards the start point. The late start
for a task that depends on completion of two tasks (i.e., that has two or more successor
tasks) is the minimum of the late finish of the predecessor tasks.
80
D E V E L O P
S C H E D U L E
FIGURE 28: Backward Pass - Calculate the Late Start and Late Finish
The critical path which is the longest time required to complete all tasks - for this
network diagram is 18 weeks. The slack (or float) is the difference between the Early
Start and Late Start (or Early Finish and Late Finish). For example, the slack for task
T3 is the above example is 8 3 (or 14-9) = 5 weeks.
Develop Schedule - Outputs

The outputs of this process are the Project Schedule and Schedule Baseline
The Project Schedule includes the activities, milestones with a specific start or
completion dates. It is represented in multiple formats as below
It is a graphically represented view of the sequence of activities in a project

shown on the y-axis against a time line on the x-axis called as Gantt chart or
a Horizontal bar chart format. This format is useful in reporting the progress
or status of the project but is not effective in planning.
It could also be shown in a table format with activity name, start date, end
date, predecessor, and successor columns. This is useful when a simple view of
81
D E V E L O P
S C H E D U L E
the open or closed activities in a project is required for a span of one week.
This is useful in monitoring or tracking the activities.
It could also be represented graphically as a network diagram format that

shows the various connections and paths between activities. This view is useful
in displaying the various dependencies of a set of activities and importantly the
critical path of the project at any point in time. This format is very effective
in planning.
The Schedule Baseline is the version of the Project Schedule that is accepted and
approved by the Sponsor or Senior Management.
The other outputs of this process are
Schedule data
Project Document updates
This includes additional supporting detail for the Project

Schedule such as Resource Histogram, Schedule Templates, Activity and
Milestone Notes based on assumptions and constraints
This may include Activity List, Activity List
Attributes updates due to addition of a newly identified activity, Project
Calendar updates due to change in calendar units from default days to hours or
weeks, Risk Register updates due to scheduling changes.

1.
2.
What is the key feature of preparing a Schedule Baseline using Critical path
method?
Determining the early start date, early finish date, latest finish date,
latest start date for each activity and hence the float of the activity.
Discovering the critical path (path with zero float) among the all the
network paths in the project schedule network diagram.
Ensuring that only one critical path exists in the project schedule
network diagram.
What is the key use of identifying the critical path?
The senior experienced resources can be allocated on the critical path

and the junior resources can be allocated on the non-critical path or
near critical path (close to zero float).
The identification of the critical path will ensure that the path is in the
close scrutiny or burning attention of the Project Manager and the
82
D E V E L O P
S C H E D U L E
Sponsor. This will ensure that the required resources for activities on
the critical path are protected.
3.
How do you compress the duration of the project schedule?

We can achieve schedule compression by:
Crashing Assign more resources to get the activities completed

faster. This will increase cost. At times it may simply not be able to
assign more resources to an activity
Fast Tracking Do work in parallel. This increases risk
Practice Questions
83
D E V E L O P
S C H E D U L E

Question
Answer
Justification
1
2
3
4
84
E S T I M A T E
C O S T S
Chapter
12
Estimate Costs
After completing the first draft of the project schedule you must estimate the likely cost
for each of the activities. Let us try and estimate the cost for one of the activities using
this process. Let us further assume that the activity involves Preparing a System Test
Cases for a large IT application that you are building. In the Estimate Activity
Resource Requirements process you would have estimated the type of resource
required for this activity say, a Business Analyst. Next, in the Estimate Activity
Durations process you would have estimated the likely effort say, 5 days to
complete the Prepare System Test Cases activity. This piece of information (1
Business Analysts for 5 days) would then be documented in the project schedule and
used to developing the project schedule.
In this process we are interested in estimating the cost of the activity. The cost would
be the daily rate of 1 business analyst for 5 days, and if the daily charge out rate is $500
then the cost for this activity is 5 * $500 = $2,500.
This way the costs for each of the activities are estimated. You must include the cost
for all resources used on the project and not just the human resources.
At this point in planning, you are ready with the Project Schedule which will form the
key input to this process. You would also have with you a Cost Management Plan
which is a subsidiary of the project management plan.
The Cost Management Plan will contain:
Procedures on how to identify the direct, indirect costs of the project,
Procedures on which techniques to use during the cost planning, monitoring &
controlling processes.
Criteria to specify the variance limits beyond which a formal escalation and
controlling action is required.
Standard format of reporting the cost estimates, budgets and reports.
85
E S T I M A T E
C O S T S
Stakeholder requirements for recognizing the costs based on cost accounting

principles. For example, costs can be recognized when orders are booked or
when actual payments are made based on default performing organization
standards or customer requirements.
The Project Schedule will contain
Information on the quantity of resources, type of resources assigned to an

activity.
Unit cost resource rates for each resource required for an activity.
A view of the time period or season for resource requirements. For example,
the project schedule will provide details of the timing of the requirement of
raw materials or human resources. The costs of steel, raw materials for food
industries, hospitality and travel industries are highly seasonal and knowing the
timing is important to estimate the costs.
Inputs to estimating the costs are:
Scope Baseline - The scope statement is useful in determining the direct

costs (primarily customized product, service, result related like product testing
costs) and indirect costs (primarily generic product, service, result related like
organization administration costs) of the activity. It may also include

constraints like the cost or expense limits imposed on the project by the
customer, project sponsor. The scope statement may also identify the nonfunctional requirements related to health, safety, security, environment, legal
which will help us to calculate the costs related to those areas for some
activities in the project.
Human Resource Plan
Risk Register
Enterprise Environmental Factors-
- These are information regarding the human

resources cost rate or resource daily charge out rate unit based on designation
level or experience level (say $300 per day for a Web Designer with 5 years of
experience). This plan may additionally be the source of cost information
related to internal funds required for rewarding, recognizing high performers
during the course of the project. For example, the human resource costs may
include fixed costs (fixed part) and variable costs (variable part based on
performance).
The risks that have been identified in the risk register are
analyzed to estimate the mitigation costs. The estimating process is closely
linked with the risk planning processes.
For example, the availability of large
number of skilled human resources in the location of the project can reduce
the project costs because of demand-supply factors.
86
E S T I M A T E
C O S T S
This repository can be reference to the

lessons learnt from past experience of estimating on similar projects. This will
help in considering all the cost components associated to each activity in a
project. For example, this will help us link travel cost components to any
implementation activity at the customer site.
Developing Activity Cost Estimates

This key output of Activity Cost Estimates could be prepared using different
techniques or tools in different circumstances. These are similar to the tools and
techniques used in Estimate Activity Resource Requirements and Activity Duration
Requirements.
The Expert Judgment is a technique by which a project
manager consults the experts in a domain, technology, industry environment for their
inputs to estimate costs. The project manager could also consult his own team
members who are experts in their domain o come up with cost estimates for the
activities assigned to them. The experts can directly prepare the estimates or provide
advice on which estimation techniques to use for individual project activities given the
situation of the project, the urgency of the estimates and the cost limits for preparing
estimates itself.
Considering experts
The Analogous Estimating

technique that helps a project manager to estimate current project activities based on
past project activities. The keywords here are comparing and similarities. The basis of
comparison is using a measure of scale like the overall size, magnitude, complexity of
the project. This type of estimating technique is quick but not accurate.
Considering data of historical, similar projects
This technique depends on two factors which are the capture of historical information
of projects as part of the organizational process assets and the expertise of the team
members making the estimate. For example, the system testing activity for a past
project on a similar product of roughly the similar size in terms of number of user
interface screens (100 in numbers), took about 3 months with 10 people. So the same
team lead who performed the last project estimates that the system testing activity for
the current project of 90 user interface screens will take about 3 months with 10
people.
This technique of estimating is used to develop high-level, ROM type of estimates at
the initial phases of the project. This kind of estimating technique is also known as
top-down estimating.
The
project
activities by developing a mathematical model that builds a relationship between a
project parameter (like size) and cost. The keywords here are parameters and
relationship between costs and parameters. This technique can be used to estimate the
Considering relationship between project activity parameters and cost
Parametric Estimating technique helps a Project Managers to estimate
87
E S T I M A T E
C O S T S
whole project or a project activity. This type of estimating is more accurate and the
accuracy is based on the past data captured in the parametric estimating model.
For example, in function point estimation technique used in IT projects, the size of the
project is given in function points. Knowing the relationship between 1 function point
and the cost of 1 function point based on the past project records can help in
estimating costs for the current project.
In a highway construction project, the relationship between 1 kilometer of road and
the cost of constructing a road over 1 kilometer is determined based on past project
records. This helps in estimating the cost of a new highway.
Considering best case, most likely, worst case scenarios in likely costs The
Three-point Estimating technique helps to improve the accuracy of estimates. This
is done by finding out the three cost estimates (optimistic, most likely, pessimistic) for
the same activity and then taking the weighted average of the three points. The most
likely point is given a weight of 4, compared to 1 for optimistic and 1 for pessimistic.
This type of estimating is also known as the PERT estimate. This is given by the PERT
activity estimate formula
Estimate
Optimistic 4.MostLikely Pessimistic

6
If a simple average is used then the three point estimate is given by the formula
Estimate
Optimistic .MostLikely Pessimistic

3
The PERT activity estimates are summed up at the project level to give the Project
PERT estimate.
The Bottom-up Estimating technique helps
to decompose an activity to further details with a purpose of estimating the costs at a
more detailed level. The decomposition is done till the cost estimates can be done with
a degree of confidence.
Considering complexity of activities
technique helps
to calculate cost buffers or cost contingency reserves at the project level or at the
project activity level. If the cost contingency reserves are calculated at the project
activity level, then they are summed up at the project level and used in the next process
while preparing the project budget. The EMV (Expected Monetary Value) analysis is a
quantitative technique for calculating the cost contingency reserve by multiplying the
probability of a risks and their cost impact for a given scenario. The value for the cost
impact is taken based on type of risk as positive (opportunity) or negative (threat). The
net value of all such values is used as the cost contingency reserve. A simple way to
calculate the project activity cost contingency reserve for those activities that have
uncertainty is to calculate it as a fixed percentage of the project activity cost estimates.
Considering project schedule uncertainty
88
The
reserve analysis
E S T I M A T E
C O S T S
Considering the cost associated with increasing quality or reducing defects The
cost of quality technique helps to calculate 2 types of costs associated with improving
quality at the project level or at the project activity level. The 2 types of costs are cost of
conformance (preventing defects by planned reviews, audits, tests) and cost of nonconformance (correcting defects by re-work or replacement).
The project
management estimating software tool helps to calculate the costs of a project by the
pre-definition of soft parameters and entry of actual values for the soft parameters. For
Example, the soft parameter for data storage size, vendor could be defined. When the
actual storage size in Giga bytes and a selected specific vendor like IBM is provided, it
calculates the number of servers required and the costs associated with building a
server cluster for data storage.
Considering software tools that can calculate cost estimates
Considering the cost estimates provided by external parties The vendor bid
analysis technique helps to analyze, validate the cost estimates or cost bids by external
parties like vendors. The bids are provided as part of the RFP or RFQ updated and
sent by the vendor. This may be internally validated by the organization experts or by
third party consultants. This may involve modifying the scope handled by the vendor,
comparing the details of one quote with another quote, comparing the details of the
quote with the overall project costs.
Outputs Estimate Costs

Activity Cost Estimates - Activity Cost Estimates can be documented in detail as a list
with the related components as shown below:
Activity Level (Activity id, Activity Description, Activity Cost)
Direct/Indirect component level(direct, indirect components)
Fixed/Variable component level(fixed, variable components)
Lifecycle component level (Includes the cost of maintenance or support till the end of
the deliverable or products useful life). Many times this component is ignored because
these costs are not seen upfront. For example, while looking at the coding activity, we
may use less experienced resources to save costs but do not foresee the support
expenses by experienced resources due to the bug fixes during the lifecycle of the
product.
All the component levels are not mandatory, but are identified as applicable.
Other outputs of this process are
This can be a separate section in the activity cost

estimates documentation or a separate documentation. This will give the details
Basis of estimates
89
E S T I M A T E
C O S T S
of how the estimates were done, highlighting the methodology used, the
assumptions made, the constraints introduced by any cost limits, the range of
cost estimate figures with a specific confidence level.
- An example update would be the update

required to risk register based on identification of new cost components and
their dependencies.
Project Document updates
Remember that the activity cost estimates are contributing to the detailed
Baseline that will be prepared at the end of planning activities of cost.
Cost
Also note that cost estimates are progressively elaborated and integrated with other
processes like Time, Risk, HR, Procurement, and Integration Management. For
example, the estimation of cost contingency reserves needs integration with Risk
Management. Also exploring human resource options needs interaction with the
Human Resource Management and Procurement Management. The evaluation of
change requests will require the Perform Integrated Change Control process in
Integration Management to interact with the Estimate Cost process to estimate the
cost impact of changes. The cost estimate at the initial stages of the project, like in
initial phases may have low accuracy but increases as the project progresses in the
detailed planning phase. The type of estimate provided at the initial stages is known as
Rough Order of Magnitude (ROM) estimate which are given typically with a range of
50%. The type of estimate provided at the detailed planning phases is known as
Definitive estimates which are given typically with a range of 10%.

1.
What is the use of identifying the cost of activities as direct or indirect

costs?
It is used to determine the sharing ratio when indirect costs (say
organization administration support costs) are identified and take only the
part of the total indirect costs towards your project costs. This will help the
project manager in planning and tracking the project costs accurately.
2.
Identify the following project activity costs as direct and indirect costs
a) Costs incurred towards providing security for the premises where your
IT project to deliver a customized product to your customer, along
with other IT projects.
b) Costs incurred towards travel of your team members for implementing
the customized product at the customer location.
The first one is an indirect cost because the security costs are normally
shared among all the IT projects in your organization. Hence the security
90
E S T I M A T E
C O S T S
costs are to be equitably distributed among all the IT projects based on

some criteria like the number of staff working.
The second one is a direct cost because the travel costs are directly or
uniquely towards the final implementation of the deliverable of your
project.
3.
What is the use of identifying the cost of activities as fixed and variable
cost components?
Let us look at an example related to manufacturing industries, for renting
the latest textile machinery which have a high fixed cost but low variable
cost due to better machine quality and efficiency. But it may require a
minimum quantity of fabric materials to be produced to be profitable. For
lower fabric quantities it may be cost effective to continue with the old
textile machinery. Here the fixed costs are the machinery costs and the
variable costs are daily operating cost per unit of fabric (which includes
basic raw material costs, re-work costs, and daily power consumption
costs).
Thus identifying the fixed and variable cost components will help us to
operate the project at optimum efficiency based on the volume of
deliverables, service or result of each activity.
4.
What is the main purpose of the basis of estimates?

The basis of estimates is documented along with the activity cost estimates
so that any assumptions, ranges, confidence levels are captured for
justifying estimates to project sponsor, customer or explaining estimates to
stakeholders. In short, the basis of estimates is a supporting document to
the activity cost estimates.
5.
What is the advantage of estimating at the project activity level?

This type of estimating is also known widely as activity based costing
method. This will help identifying costs at a granular level, so that
unnecessary activities and hence costs can be easily eliminated from the
project costs. It will also help us in identifying the key high cost activities to
be monitored closely from a cost control perspective. Remember that
many projects are stopped after starting, because the rising costs of the
project offset the benefit margins of the project.
This type of estimating also helps the customer in reviewing, removing,
changing the project scope, at the planning phase before proceeding to the
executing phase. Many times, customers select the work packages with
high benefit cost ratio and hence the need for identifying the low cost
91
E S T I M A T E
C O S T S
activities. Remember that the activity costs can be summed at the work
package level.
Practice Questions
1.
Rough Order of Magnitude estimates are in the range

a) 5 to + 5percent
b) -10 to +10 percent
c) -20 to +20 percent
d) -50 to +50 percent
2.
Your project has just been initiated and you are discussing project
estimates with your senior manager. What type of estimate would you have
at this stage of planning?
a) Accurate Estimate
b) Parametric Estimate
c) ROM Estimate
d) Definitive Estimate
3.
Supporting detail for cost estimates may include all of the following except:
a) Basis of Estimates
b) Indication of range of cost estimates
c) Confidence Level of estimates
d) Push, Pull and Interactive Estimates
4.
Tools and techniques for estimating costs include all of the following
except:
a) Cost of Quality
b) Reserve Analysis
c) Vendor Bid Analysis
d) ROM estimates
92
E S T I M A T E
C O S T S

Question
Answer
Justification
PMBOK Guide Page 168
At the beginning you may only have a ROM estimate.

Estimates are refined and are more definitive after you
complete the WBS.
All others are part of supporting detail.
ROM estimates are not part of tools and techniques
93
D E T E R M I N E
B U D G E T
Chapter
14
Determine Budget
At this stage you have the Activity Cost Estimates and Resource Calendar for your
project. You now need to determine the project budget. You can do this by rolling-up
or aggregating the estimated costs of each of the defined activities to the next higher
level (work package level) and finally to the project level. But that is just the amount of
work we would definitely be doing. There could be activities we may be required to do
that are uncertain at this point in planning. These costs also need to be added up to the
cost of performing the activities to obtain the cost performance baseline.
The Activity Cost Estimates and Resource Calendar are the key inputs to this
process. As mentioned earlier, Resource Calendars are reference information regarding
the number and timing of resource availability (physical raw material, equipment and
human resources). This information is required at this stage to determine the timing of
the total cost funding requirements.
Other inputs to this process are
Scope Baseline
Project Schedule
Contracts
- The Scope statement has references to funding constraints

that are mandated by the sponsoring organization. The Work Breakdown
Structure is also used to aggregate the costs at Work Package levels, Control
Account levels, and Project levels.
Reference is made to aggregate the costs by project
schedule periods, so that project funding requirements can be shown against
time periods.
The costs related to procurement of resources, deliverables,
services and results are confirmed using the contract documents.
An example reference is to access the
corporate knowledge repository for a policy, procedure documents related to
calculating cost budgets based on access to past projects for lessons learnt and
reserves to apply.
94
D E T E R M I N E
B U D G E T
Developing the Project Cost Performance

Cost Performance Baseline for a project could be prepared using different techniques
or tools based on the information source,
The information from the Work Breakdown structure can be used to sum up Costs
upto the project level. This is also known as the Cost Aggregation. The cost estimates
are summed up (aggregated) starting from the work package level using the WBS as an
aggregation template or container. The aggregation then continues to the control
account level and finishes with the project level.
The information analyzed from the risk perspective is used to keeping aside cost
buffers for known and unknown risks and is also termed as the Reserve Analysis.
Two types of reserves Contingency Reserves and Management Reserves - are
determined. The contingency reserves cater to the known-unknown risks and are
added to the project costs to obtain the cost performance baseline. The management
reserves are not part of the cost performance baseline but are kept aside for unknownunknown risks. However the management reserves are added to the cost performance
baseline to obtain the project cost budget. (See FIGURE 29)
Contingency and Management Reserves
Contingency reserves are cost buffers kept aside for risks of the type known
unknowns. These risks are identified in the risk register and attempts to mitigate them
have been taken. However the cost impact of the risks, when they happen is unknown
or uncertain. These buffers are to be utilized when these kind of risks actually happen.
The utilization of these reserves is contingent (dependent) on the future happening of
the risk. For example, if a product is newly developed and released in to the market, we
would expect that some products would be returned back. The unknown in this case
is the number of products that are returned back. We would plan for a contingency
reserve to provide funds for the replacement of the products.
Management reserves are cost buffers that are kept aside for risks of the type
unknown unknowns. These are risks not identified in the risk register that include
situations that are almost impossible to foresee or predict. These would include default
or bankruptcy of vendors the performing organization deals with. These buffers are to
be utilized when these risks happen with the approval of the senior management.
The information from experts in the organization or the industry is shared in preparing
the cost budgets and is also known as Expert Judgment. This is usually done by
constituting a budget preparation committee involving the project managers in an
organization.
The information from previous projects is utilized in validating the cost estimates while
preparing the cost budgets for current projects. This technique is also known as
Historical Relationships.
95
D E T E R M I N E
B U D G E T
FIGURE 29: Cost Performance Baseline
The information from the finance department needs to be obtained for reconciliation
of expenses and income. This technique is also known as funding limit reconciliation.
The project expenses that need to be funded are to be balanced with the project
funding commitments by the customer or the project sponsor. This will mean that the
timing of the completion of work and the timing of the funding commitments have to
be synchronized. The plotting of the project funding or income against time period
resembles ascending steps. Each horizontal level of the step indicates the funding limit
for a given period.
Determine Budget - Outputs

The outputs of this process are
Cost Performance Baseline
and
Project Funding
Requirements.
The cost performance baseline is a plotting of the cumulative value of the project
budgets on the y axis and the time period on the x axis. The shape of the project
budgets is S shaped indicating that the project costs initially are flat or low and rise
96
D E T E R M I N E
B U D G E T
steeply after the initial phases. The project costs then flatten toward the closing phases
of the project. This curve is used in monitoring the performance of the costs in
project using the earned value management technique. Hence the name cost
performance baseline.
The project funding requirements is shown as plotting of the cumulative project
income required on the y-axis and the period (weeks, months, and quarters) on the xaxis. The shape of these requirements is stepped indicating that the funds are required
in steps based on the procurement of a sub deliverable or the completion of a
deliverable.
The other output of this process is Project Document updates. An example would be
the update required to activity cost estimates during the preparation of the project
budget.
Practice Questions
97
D E T E R M I N E
B U D G E T

Question
Answer
Justification
1
2
3
98
P L A N
R I S K
M A N A G E M E N T
Chapter
14
Plan Risk Management
This is the first process in Risk Management and is where you decide how to approach,
plan and execute the risk management activities for the project. This process meets the
following objectives:
Ensures there is a common understanding of the Risk Tolerances of key

stakeholders which includes identifying the stakeholders contributing to the
risk, their risk tolerances, and resolving any differences they have by
communicating the common conclusions to the project teams
Defines common terms such as of probability and impact such as medium,

low, used later in the qualitative analysis, to provide a consistent framework
for assessment.
Defines potential sources of risk for the project also known as Risk
Categories often represented as a Risk Breakdown Structure (RBS). These
are only broad indicative sources the Risk Identification process is where the
list is expanded further.
The major inputs for the Plan Risk Management process include:
Scope Statement
Cost Management Plan, Schedule Management Plan and Communications

Management Plan These are sections of the project management plan you
used to understand project boundaries and assumptions.

For example what is not in scope if not well defined and agreed often becomes
a major bone of contention with stakeholders at a later stage of the project.
are creating as part of planning your project. These plans states how the
schedule reserves and contingency reserves would be accessed, utilized and
reported should risk events occur. The WBS needs to be assessed to determine
possible areas where risks can occur. For example project plans that have time
allocated for testing but none for fixing and rework that follows. Testing and
rework is a loop process which is not possible to implement in most project
planning tools (e.g., MS Project) so project managers get around this by
padding other task estimates. This would be a planning risk.
99
P L A N
R I S K
M A N A G E M E N T
Organization process assets These are the standards and policies around
risk including risk categories, roles and responsibilities, and definitions of the
decision making process. For example the RBS shown in FIGURE 30 is a
typical process asset used by risk planning teams.
Enterprise Environmental Factors
This defines the organizations tolerance

for risk. Risk tolerance translates into 3 types of risk attitudes within an
organization or project groups:
this group is uncomfortable with uncertainty, has low
tolerance for ambiguity. Such a group tends to focus mostly on how to
minimize or avoid risks and looks for ways to reduce threats and in the
process they tend to ignore opportunities.
1.
Risk Averse
2.
Risk Neutral
3.
Risk Seeking
see risk-taking as a price for future payoffs and is neither

risk averse nor risk seeking. They take action on a risk only if they know it
is likely to lead to significant benefit and therefore have a balanced
approach to threats and opportunities.
they will pursue opportunities aggressively and take big
risks to achieve these. They are often likely to underestimate the
probability and\or impact of a risk and will tend to accept the risk as a
response.
Plan Risk Management Tools & Techniques

You and the project management team would need to conduct planning meetings to
discuss and develop a risk management plan. Invitees to this meeting could include key
stakeholders, key team members and risk management team members of your
organization.
Contents of a Risk Management Plan

The output from this step is the Risk Management Plan which forms an integral part
of the Project management plan and should be reviewed and updated during the
course of the project if a risk process is modified. The final Risk Management plan
should describe the 5W + H Who, What, When, Where, Why and How and
includes:
Roles and Responsibilities defines who does what activity in the Risk
activities
Budget provisions for risk management activities approved funds available

for risk management activities to be tracked against actual
100
P L A N
R I S K
M A N A G E M E N T
Schedules for risk management revised schedules (to the project plan) to
include risk management activities
Categories of risk to be addressed either an RBS or a list used to categorize

and prioritize risks. FIGURE 30 shows a typical RBS.
Probability-Impact scale definition definition of what is considered low and

what is considered high etc.
FIGURE 30: Risk Breakdown Structure

1.
Stakeholders & Project Complexity are two major sources of project risk.
Discuss.
Many popular published reports6 testify to senior management support
and customer involvement being the single largest contributor to a
projects success. Interpreting this in converse we can conclude that
stakeholders are a major source of project risk resulting in its success or
failure that needs to be identified and managed as a risk.
Earlier in Chapter 1 we described how complexity is a source of
uncertainty and can be caused by multiplicity of stakeholder interactions
sometimes leading to unexpected risks. Not understanding the nature of
CHAOS Report, 2009

101
P L A N
R I S K
M A N A G E M E N T
different stakeholders and how they impact a project can often lead to
spectacular project failures
Practice Questions
1.
The Plan Risk Management Process should be completed

a) Late during project planning
b) Early during project planning
c) Early during project execution
d) Late during project initiation
2.
The Risk Management Plan may be developed by which of the following

BEST option?
a) Project Manager
b) Project Manager, Selected project team members
c) Project Manager, Selected project team members and Stakeholders
d) Project Manager and Project Management team
3.
The following provides a structure that ensures a comprehensive process

of systematically identifying risks using categories?
a) Probability and Impact Risk
b) Risk Identification checklist
c) Risk Register
d) Risk Breakdown Structure
102
P L A N
R I S K
M A N A G E M E N T

Question
Answer
Justification
Risk planning is to be must be done as early as possible in

planning
Stakeholders select project team members, PM and other

key stakeholders must participate
RBS
103
I D E N T I F Y
R I S K S
Chapter
15
Identify Risks
In this step you and your project team explicitly identify risks that have the potential to
affect the project and document their characteristics. This step follows after the risk
management plan is constructed and continues iteratively through planning. In some
cases an identified risk can have an immediate candidate response which should be
captured and implemented provided it is cost-effective and feasible.
The key input to this step is the Risk Management Plan which provides the details of
roles\responsibilities of managing different risk activities, budgets and schedules for
risks management related tasks, risk categories such as the RBS. Other inputs are as
follows and we have seen all of these in the previous chapters:
Activity Cost Estimates
Activity Duration Estimates
Scope Baseline
Stakeholder Register
Cost Management Plan
Schedule Management Plan
Quality Management Plan
Other Project Documents
Tools and Techniques for Risk Identification

Tools and techniques used for Risk Identification are based on:
104
I D E N T I F Y
Review of Documents
Information gathering
Analysis of Checklists, and
Diagramming techniques.
R I S K S
A structured review of project documents including plans, assumptions, contract and

other information can help uncover potential project risks.
Information gathering is done through Interviewing and Brainstorming whereby
specific risks can be identified using SWOT (Strengths, Weaknesses, Opportunities,
Threats), Wide Band Delphi method to name two (a number of other methods exist
such as Risk Checklists, Brainstorming, Nominal Group Technique (NGT), Crawford
slip). (INCOMPLETE STATEMENT xxxxxxxxxxxxxxxxxxxx)
Diagramming methods include the Ishikawa cause-and-effect diagram which can be
used to determine risks.
For each of these techniques it is important to have SMEs (Subject Matter Experts)
involved from diverse groups. It is also important to combine different methods where
possible for example using a Risk checklist developed from previous projects as a
starting point for a Brainstorming session or using a Brainstorming session to complete
the SWOT analysis or using an RBS with a Cause-Effect Diagram is a good practice.
SWOT Analysis
SWOT is an acronym for Strengths, Weaknesses, Threats and Opportunities - considers
risk from both the internal and external environment. This technique is useful specially
when considering both Risks (Threats) and Opportunities. Users of the SWOT analysis
identify and list risks under the SWOT headings.
Strengths
Weaknesses
Internal factors related to the project or organization that helps to

achieve objectives.
- Internal factors that obstruct achieving objectives and can be
improved.
Opportunities
Threats
Factors that are not currently present in the project or

organization, but could reflect positively on achieving our objectives.
Factors that are not currently present in the project or organization,
but could reflect negatively on achieving our objectives if they occur.
A typical SWOT analysis is shown in FIGURE 31 for a software project involving

changes to an existing application
105
I D E N T I F Y
R I S K S
FIGURE 31: SWOT Analysis
The process of completing the 4 quadrants can be done by brainstorming, using risk
checklists or an existing RBS. It can be done one quadrant at a time which works well
with first time users or all at the same time for more experienced teams.
Wide Band Delphi
This is based on the standard Delphi method (called wide band as the modified
version allows for interaction of greater number of participants) and is a technique that
involves
Interviewing SMEs
Interviews are anonymous reduces the effect of individual and group bias in
responses
Can be used when there may be conflicts or confrontation or when

brainstorming is not recommended
Can be used to get comments even from competitors
It uses an iterative, refinement method to reach a statistical group response

where the opinion of each SME is represented in the final response.
106
I D E N T I F Y
R I S K S
Some limitations of the Delphi method are that it is slow and time consuming
sufficient time and effort need to be devoted to it. In some cases extreme views may be
dropped in a drive to get to a consensus thereby losing its value in Risk identification
(where extreme views are important), and a final consensus can sometimes be
manipulated by a large group\facilitator (groupthink).
The process steps involved in the exercise are:
1.
Define the Scope of the Activity in this case Identification of Risks
2.
Identify a Facilitator or Moderator the moderator in turn determines the

stakeholders (SMEs) for this project that need to participate in this exercise
3.
The moderator develops a series of questions based on the Risk

Management plan, Project Scope, Plan and other documents existing at
this point
4.
The questions are sent to the stakeholders participating individually to

answer
5.
The facilitator collects the responses and consolidates the answers to create
a summary which includes most common as also divergent themes while
retaining anonymity of contributors
6.
The facilitator distributes this summary back to the stakeholders for

another round of answers
7.
The facilitator iterates through Steps 4 to 6 till a consensus is reached when

the final list of risks is documented
Using Ishikawa Diagrams in Risk Identification

Also called the Fishbone or a Cause-and-Effect diagram (CAED), the Ishikawa
diagram is a tool with its origins in quality management but can be used for identifying
risks with a caution on watching out for potential confusion in interpreting it.
The tool is easy to use, allows for different opinions from a team and goes beyond risk
identification to provide causes to which responses can be formulated. Limitations of
the tool include the inability to handle complex problems, inability to handle
interactions and chronological dependency (i.e. time dependency) between different
causes.
The term fishbone arises from the fact that the diagram connects a series of causes
depicted as branches of the fishbone with a resulting effect in the form of the head
of the fish. The tool visually depicts causes and their resulting effects, but it must be
understood that risks are not explicitly visible in this diagram they need to be
derived from the uncertainties introduced by a cause - this is explained in detail a
little later.
107
I D E N T I F Y
R I S K S
FIGURE 32 shows an Ishikawa diagram for a typical project problem i.e. low
productivity during the development cycle (the effect) due to multiple causes often
addressed as the 4M +E i.e. Materials, Manpower, Methods, Machine PLUS
Environment.
FIGURE 32: Ishikawa Diagram
Envrionment
Manpower(Staff)
Lack of
Skills
Distributed
Facilities
Poor Productivity
Lack of
Standardization
New
Hardware
Methods
Contracted
Staff
Machine
Materials
Whilst identifying risks a common mistake is confusing causes and effects as potential
risks. This obscures genuine risks and diverts management attention to non-risk events.
Therefore it is useful to define causes and effects in the context of risk
Effects are unplanned variations from a stated objective that arise as result of
risks. Being late for a milestone, exceeding an authorized budget, not meeting
system performance targets are all examples of effects. An effect is a
Contingent event i.e. they occur only if a risk occurs and therefore they cannot
be managed by a Risk Management process since they do not exist till a Risk exists.
is a definite set of events or circumstances which already exists in a

project or environment and can cause uncertainties and risks. The need to use
new technology for a project, having inexperienced staff, working in a new
organization culture are all possible causes of risks. Causes themselves are
not uncertain and are not the main focus of risk management. However
knowing about and tackling the cause can avoid or mitigate a threat or allow an
opportunity to flourish.
Cause
108
I D E N T I F Y
R I S K S
In interpreting the Ishikawa diagram for identifying risks a useful technique to avoid
this confusion is to use the following risk-meta language7 to describe each branch of
the fishbone
As a result of a <CAUSE> an <UNCERTAIN EVENT\RISK> may
occur which would lead to an <EFFECT positive or negative> on
some performance objective.
We can now interpret FIGURE 32 by constructing the following sentences to isolate
the risks as opposed to Causes and Effects.
1.
..As a result of using new Hardware(the cause), unexpected system

performance issues may occur (Performance Risk) leading to spending
time fixing the issues and lowering productivity (the effect on an
objective)
2.
..As a result of a lack of skills amongst Staff (the cause), the time allocated
in our plans for Testing many not be sufficient (Planning Risk) leading to
poor productivity(the effect)
3.
..As a result of using contracted staff from a partner (the cause), more
effort and time may need to be spent on communicating our standards
and procedures (Resourcing, Communications, Planning Risk) leading to
overall poor productivity(the effect)
Output from Risk Identification

The Risk Register is the primary output of this step. The Risk register is created in this
step and traces its flow throughout all the PRM processes and will ultimately contain all
identified risks, including description, category, and cause, probability of occurrence
and impact on objectives, proposed responses, owners, and current status.
However at the conclusion of risk identification it will contain only the following
details
Lists of identified risks
List of potential responses this is optional and relevant only for immediate
known responses for some risks
Hillson David Risk Management in Practice, The AMA Handbook of Project Management / book auth.
AMA. - 2nd Edition, Jan 2006. - Vols. Chapter 14, Page 184.
7
109
I D E N T I F Y
R I S K S
Root causes for the risk which are the fundamental conditions which cause
the risk
Updates to the Risk Categories The process of identifying risks can often
lead to new risk categories being added.
Practice Questions
110
I D E N T I F Y
111
R I S K S
I D E N T I F Y
R I S K S

Question
Answer
Justification
1
2
3
4
112
P E R F O R M
Q U A L I T A T I V E
R I S K
A N A L Y S I S
Chapter
16
Perform Qualitative Risk Analysis
The Identify Risks process may produce a long list of risks that cannot all be addressed
due to time and cost constraints. Therefore, there is a need to identify the risks and
opportunities deserving the highest priority for further attention this is the objective
of the qualitative risk analysis. The work done in this process step provides a
narrowed down list for quantitative risk analysis (if needed) and risk response
planning.
Key inputs to this process include the Organization Process Assets (can provide an
insight on how some risks were handled in the past), Project Scope Statement (e.g.,
may indicate a technology or process may be new to the project raising risk), Risk
Management Plan and the Risk Register.
Qualitative Risk Analysis Tools & Techniques

Key tools and techniques used in this process are the Risk Probability-Impact
Assessment, and the Probability-Impact Matrix (PIM) or Risk Matrix.
The risk probability is a value assigned to the likelihood that a specific risk will occur
and is expressed in a range from 0 %( will not occur) to 100% (certain to occur). Risk
impact assessment is a value that defines the effect of the risk on a project objective
usually time, cost, quality, regulatory compliance, performance and many others. For
threats the impacts are negative e.g., lost time, extra cost and for opportunities they are
positive e.g., saved time or cost.
As an example if the current attrition in the company is high there is an equally high
probability that people from the project may leave and its impact on the project could
be high. On the other hand if there is adequate cover for these resources (say through
contracted staff) the probability of the risk is still high but its impact may be moderate
or low as it can be managed, the overall risk will also be lower.
Risk Matrix or Risk Probability-Impact Matrix (PIM)
A sample Probability-Impact matrix from the PMBOK Guide is shown in FIGURE
33. Each risk is rated on its probability of occurrence (0.10 low to 0.90 high along
113
P E R F O R M
R I S K
A N A L Y S I S
the Y-Axis) and impact upon an objective such as cost, time etc. also expressed as a
number between 0 and 1 along the X-Axis. The resultant product of ProbabilityImpact called the Risk Index is stored in the cells of the matrix.
For example a high probability risk with a value of 0.9 and posing a high threat with a
value 0.8 will have a Risk Index value of 0.72 marked red indicating high risk for the
project. The same holds for other cells in red. Cells with amber can represent moderate
risks and green low risks that need only to be kept in a watch list.
FIGURE 33: Probability Impact Matrix
A recent innovation to the PIM has been to divide the matrix into 2 mirror images
covering Threats and Opportunities with similar scales both are assessed and
captured at the same time.
Problems with the Risk Matrix
The Risk matrix presented above has some shortcomings that need to be understood
especially when using numeric values and performing mathematical operations. Among
the issues to watch out for are8:
By using the matrix original unambiguous data is compressed
into a narrow range of numbers resulting in a loss of key information. This means we
could get two risks that are quantitatively different being assessed as the same. For
example in FIGURE 33:
Range Compression
Anthony Cox Louis Jr What's wrong with Risk Matrices?, Society for Risk Analysis , 2008. - No 2, Vol 28.
114
P E R F O R M
R I S K
A N A L Y S I S
A 1% and a 29% probability will fit into a single probability of 0.10 i.e. low
If the X-axis is a cost objective and if $ 100 million is assumed to be the

maximum i.e. value of 0.8, then a $250 million impact will also have the same
value of 0.8 since there is no higher number for impact
A 1% chance of losing $ 100 million and a $29% chance of losing $ 250

million will both translate to a Risk Index = 0.1 x 0.8 = 0.08 (amber) i.e. a
moderate risk.
However a simple EV (Expected Value) comparison would indicate that 29%

x 250 mill = $ 72.5 million is far greater than 1% x 100 million = $ 1 million
risk!
The matrix uses an ordinal scale (High, Moderate

and Low) which is translated into cardinal values (0 to 1) and gives rise to an
impression that numbers used roughly approximate the relative importance of the
factors. An impact value of 0.8 is considered 2 times higher than one of 0.4 or a
Probability of 0.6 is considered 3 times more likely than one with 0.2.
Presumption of Regular Intervals
In reality the actual values for Probability -Impact may be much closer or farther away
relative to each other than these numbers indicate giving rise to wrong assessment of
risk priorities.
The risk matrix given above when used to plot
multiple risks ignores the effect of the correlation between different risks since it
assumes they are independent leading to an over or under assessment of risk priorities.
It is possible for two different risks both in green cells (i.e. low to moderate likelihood
and impact) to become a high risk if they occur together.
Presumption of Independence
As an example we consider loss of an office working facility due to bad weather as a

moderate risk and unavailability of some staff due to bad weather also as a moderate
risk. If both events happened at the same time (quite likely if the weather affects the
facility and people located in the same geography) then the overall risk is cessation of
all work since there is no place to work even if some staff is available which would
be high risk.
Suggested ways to use the Risk Matrix
Though there are issues with the Risk Matrix and many leading texts on risk
management advocate doing away with them completely9, they are easy and intuitive to
use and still widely employed and will continue to be used. A suggested way of
developing and using this matrix is to convert all numbers to an ordinal scale by
9
Chapman Chris and Ward Stephen, Project Risk Management, Process Techniques and Insights, John Wiley & Sons,
2003, 2nd Edition.
115
P E R F O R M
R I S K
A N A L Y S I S
calibrating the real Probability-Impact values to this ordinal scale. To do the conversion
each organization needs to calibrate its Probability-Impact values into ordinal scales
such as VHI Very High, HI-High etc. as shown in FIGURE 34. This is part of the
Organization Process Assets and is specific to each organization.
FIGURE 34: Sample Risk Matrix Calibration
Scale
VHI
HI
MOD
LOW
VLOW
NIL
Probability
61-99%
41-60%
21-40%
11-20%
1-10%
<1%
Time
> 40 days
21-40 days
11-20 days
6-10 days
1-5 day
No change
Impact on Project Objectives()

Cost
Quality
>$ 200K Very significant impact on overall functionality
$101K-$200K Significant impact on overall functionality
$51K-$100K Some impact on key functional areas
$11K-$50K Minor impact on key functional areas
$1K-$10K Minor impact on secondary functions
No change No change in functionality
Once this is done a risk matrix can be developed where the Risk Index cells are now
risks with a High, Moderate and Low values where H > M > L as shown in FIGURE
35.
FIGURE 35: Suggested alternative Risk Matrix based on Ordinal Scales
Probability and Impact Matrix

Probability
Threats
Opportunities
VHI
L
M
H
HI
H
H HI
H
M
L
HI
L
M
M HI
H
H HI
M
M
L
MOD
L
L
M HI
H
H HI
M
L
L
LOW
L
L
M M
H
H M
M
L
L
VLOW
L
L
L
L
M M
L
L
L
L
VLOW LOW MOD HI VHI VHI HI MOD LOW VLOW
Impact (Oridnal Scale)
- in spite of the improved method of using the Risk
matrix, it is best used for coarse, distinct (no overlapping of risk boundaries), well
identified risks keeping the shortcomings mentioned in the previous section in mind.
Caveat Emptor (buyer beware)
Key Outputs from Qualitative Risk Analysis

The key output from this step is the updated Risk Register which would now contain
116
P E R F O R M
R I S K
A N A L Y S I S
Relative ranking or priority of risks based on the color coding and scales
Risk categories this is where the individual risks are grouped into categories
such as those in the RBS which helps determine hot spots of exposure. This
can be further mapped to the WBS to identify project areas that could be
affected by the risk.
Risks requiring immediate or near term responses - i.e. the time dependency of
the risk.
117
P E R F O R M
R I S K
A N A L Y S I S
Practice Questions
Which of the following is NOT a tool and technique of Perform Qualitative Risk
Analysis
A. Risk Categorization
B. Expected Monetary Value analysis
C. Risk urgency assessment
D. Probability and impact matrix
Risks which have low priority

A. are not addressed in detail but kept in a watch list
B. are addressed in triggers
C. are addressed as part of contingency plans
D. are same as residual risks
118
P E R F O R M

Question
Answer
Justification
1
2
3
4
119
R I S K
A N A L Y S I S
P E R F O R M
Q U A N T I T A T I V E
R I S K
A N A L Y S I S
Chapter
17
Perform Quantitative Risk Analysis
The qualitative risk analysis step deals with one risk at a time which may occur over
different times in a projects duration. Many risks are correlated i.e. they may move
together/opposite at the same time and their combined effect on project outcomes
such as Cost and time is difficult to understand. In such cases a qualitative analysis in
itself may not be sufficient.
This is where the use of a quantitative model which uses probability distributions
(continuous and discrete) and techniques such as Monte Carlo simulation, Decision
Trees and Sensitivity Analysis is done to quantify the risks from multiple factors.
Because this method requires data collection & verification, skilled staff, expensive
tools it is often not justified for use if the qualitative analysis step reveals simple risks
with sufficient detail. Quantitative risk analysis is often used in highly complex projects,
where quantitative decisions such as a bid price, milestone, delivery dates have to be
given under uncertainty.
The key input for this step is the updated Risk Register. However, Organization
Process Assets, Risk Management Plan, Cost Management Plan and the Schedule
Management Plan are also inputs to this process.
Quantitative Risk analysis - Tools & Techniques

The primary tools used in this process step are:
Data Gathering & Representation Techniques
Quantitative Risk Analysis Tools such as
These include data

gathering techniques such as interviewing and modeling datasets using discrete
and continuous probability distributions.
Decision Trees
Monte Carlo Simulation
and
Expert Judgment.
Monte Carlo Simulation and Decisions Tress are explained in detail later in this section.
120
P E R F O R M
R I S K
A N A L Y S I S
Irrespective of the tool or technique used these have the following prerequisites:
The data quality and integrity must be ensured to avoid a GIGO (Garbage InGarbage Out) situation
It is necessary to interpret the outputs produced from the models since the
quantitative analysis in itself will not tell the manager what decision to take
Monte Carlo Simulation

Consider the following scenarios:
A new product is to be released to market will it succeed? Sales could be low

to high an unknown; unit price to produce the product (i.e. the cost to make
plus a fixed margin) could vary between low to high another unknown; rivals
can enter with a competing product that may impact sales by a certain negative
factor could be high or low again unknown. How do we determine our
overall strategy when faced with multiple unknowns that are possibly related?
There are three parallel critical tasks in a project plan all due to end at the same
time i.e. to merge. These are 3unknowns with values initially decided through
expert judgment with varying levels of confidence. So how do we find out the
probability that the 3 tasks will finish at the same time?
Your project Risk Matrix has defined over 10 critical risks for the project each
with its Probability-Impact ratings. You are unsure of the actual probability
ratings for each risk believing that it may vary by 20%. Additionally you want
to evaluate the overall Probability-Impact of the project for all risks combined.
How can this be done?
In each of these cases the Monte Carlo simulation technique can be used. The way a
Monte Carlo simulation works is that it generates a large number of scenarios based on
varying probabilities as inputs. For each scenario a specific value will be generated
randomly for each unknown probability value. These values then go into the formula
to compute the output for a single scenario; the output can be revenues, cost, time,
resources or any other numerical factor. The same process is repeated for all scenarios
producing a distribution of the output values from which decisions can be made using
statistical analysis.
Consider the sample Risk Matrix (FIGURE 36), it consists of the top 3 risks identified
and each risk has the effect of causing project delays. Experts from the project have
been asked to provide an Optimistic, Most likely and a Pessimistic value for the delay
in days for each risk. The last column contains the PERT estimate for each risk.
121
P E R F O R M
R I S K
A N A L Y S I S
FIGURE 36: Monte Carlo Analysis - Inputs
Based on this if the 3 risks occurred at the same time there is a chance according to the
PERT estimates that the schedule will be pushed back by 15 days, the maximum delay
due to project dependencies. Of course it will be worse if the events happened in
sequence.
Since there are 3 unknowns we can double check the PERT estimate using a Monte
Carlo simulation. The steps for the simulation are:
1.
Determine the probability distribution that will be used for the range of
delay values. In this case the Triangular distribution formula (refer
FIGURE 39) is an appropriate one as it is often used when sufficient data
points are not available. Other popular distributions include Normal,
Uniform, Bernoulli and Poisson.
2.
Use an MS-Excel random number generator to produce probability values

that are fed into the formula (for the Triangular distribution refer FIGURE
39) to produce an expected value of delay for each risk. The maximum
value is the overall project delay. A set of generated values is shown in
FIGURE 37, normally this table will have over 10,000 rows for the number
of scenarios tested.
3.
The cumulative probability values for the overall delays is derived from the
table and shown in a graphical form this is the main output from the MC
analysis.
122
P E R F O R M
R I S K
A N A L Y S I S
FIGURE 37: Monte Carlo - Spreadsheet Calculations
Probability
(Random
Number)
0.00
0.39
0.63
0.76
0.06
0.51
0.46
Delays due to
Project
Scope
Dependency Screep
9
6
15
9
17
11
19
12
11
7
16
10
15
9
Resource
Availability
8
12
14
15
10
13
13
Overall
Delay
9
15
17
19
11
16
15
FIGURE 38: Cumulative Probability from Monte Carlo Analysis
100%
90%
Probability
80%
70%
60%
50%
40%
30%
20%
10%
0%
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Days
123
P E R F O R M
R I S K
A N A L Y S I S
Looking at this graph it becomes evident that
There is a 40% probability or confidence value (oval number 1) that the overall
delay will be 15 days, in other words our PERT estimate has a confidence level
of 40% or P40.
There is a 50% chance that the overall delay will be 16 days (oval 2)
To reach an 80% confidence level of the impact of the risks the actual delay
could be 19 to 20 days oval number 3
At a P90 or 90% confidence level the delay will be 21 days, a 140% negative
variance from our PERT estimates.
It is evident that in spite of the best knowledge and trusted sources for information at
our service, presence of multiple unknowns greatly alters our risk assessment and the
Monte Carlo simulation technique provides much greater insight into the real risks.
FIGURE 39: Triangular Distribution and its use in a Monte Carlo Simulation
124
P E R F O R M
R I S K
A N A L Y S I S
Decision Tree Analysis

This is a useful tool for determining Expected Values of a decision where multiple
outcomes are possible. A decision tree is built around each possibility or an uncertainty
following a separate path leading to an overall expected outcome. By comparing the
final Expected outcomes of the different paths a decision can be made on choosing a
path depending on the Expected Value objective e.g., lowest costs, highest revenues,
least time and so on.
Decision trees are useful since:
They identify contingent actions as a response to Risk occurrence by providing

a less risky alternative (or one with greatest opportunity)
They help identify the value of preventive and mitigating action useful when
deciding the appropriate Risk response(refer section on Risk Response
planning later)
They show the dependence among the risks, for example if the first one occurs
it shows that future ones as well as contingent actions may become irrelevant.
Decision trees are typically used for projects with small number of risks or to focus on
a particular set of important risks they become impossible to use when number of
risks are very large.
A decision tree is shown in FIGURE 40. The following terms are used with decision
trees and are useful to know:
Expected Monetary Value (EMV)
Decision Nodes and Event (Probability) nodes
this is defined as the sum of the products

of the Probability of an event with the value of this event. For example an
event having a probability of occurrence of 50% and a value of the outcome of
$ 1000 cost has an Expected value of = 50% x 1000 = $ 500.
There are two types of
nodes created in decision trees. Decision nodes are used to present different
alternatives of which only one can be chosen finally for e.g., if there are 2
alternatives given of (a) Buying a product and (b) Building a product this is a
decision node since choosing one means abandoning the other. Event or
probability nodes are used to present uncertainties contained within the event
using probabilities for each path i.e. the different paths are all possible.
The example below illustrates the use of a decision tree

You are responsible for presenting and implementing a new ERP system
which if approved has a total value (in terms of net of costs saved,
productivity benefits etc.) of $ 100 million if fully successful. The chance
125
P E R F O R M
R I S K
A N A L Y S I S
of this occurring is estimated at 60%. On the other hand it could have a

limited success and produce a net value of $ 30 million. The other
possibility is that the project can fail implementation and result in a loss
of $20 million with a 50% probability.
We draw the decision tree in FIGURE 40 starting from left to right
1.
The Decision node titled ERP Project has two alternative paths either
the project is approved and we build the ERP system or it is abandoned by
Upper Management. Decision nodes are often shown as squares.
2.
The path to abandon the project leads to a net cost of 0 and this is the end
of this path. Note that the EMV for this path is actually = 100% x $ 0 = $
0 (since if this path is chosen it has a probability of 100% and a Value of
$0)
3.
On the other hand if the project goes ahead then we reach an

Event\Probability node titled Project Decision where 2 alternative paths
exist i.e. a 50% chance of Moving Forward and a 50% chance of failure.
Event nodes are indicated by circles.
4.
At this point if the project fails then we lose $20 million and this is the end
of this path
5.
If the project is successful we reach another Event\Probability node titled

Project Success that has two paths one for a fully successful ERP
implementation with a 60% probability and a partly successful result with a
40% chance. For both these paths we note the final values of success i.e. $
100 million and $ 30 million which is the end of the tree traversal.
6.
To evaluate the decision tree we use a technique called Folding Back

where we work backwards from the rightmost ends of the tree as follows
7.
For the node Project Success we determine the EMV for this node
as the sum of the Product of Probability and Value for its 2 legs i.e
EMV2 = 60% x $ 100 + 40% x $ 30= $ 72 mill
For the node Project Decision applying the same logic as in point (a)
we determine the EMV as EMV1 = 50% x EMV2 + 50% x (-20
million) = $ 36 million - $ 10 million = $26mil
Finally for the node ERP Project (the starting point) since it is a
Decision node we compare the EMVs of each leg i.e. Build ERP system
has a value of $26 million and Abandon has $0, the final decision would be
to go ahead and build the ERP system.
126
P E R F O R M
R I S K
A N A L Y S I S
FIGURE 40: Sample Decision Tree

Fully Successful
60% Probability
Project
Success
Project moves forward

50% Probability
Build the
ERP System
Project
Decision
EMV1 = 50% x 72 - 50% x

20 = $ 26 mill
$ 100 mill Full

Success
EMV2 = 60% x 100 + 40% x 30 = $ 72 mill
Partly Successful
40% Probability
$30 mill Part

Success
EMV0 = $ 26 mill
Project Fails
50% Probability
ERP Project
-$20 mill Project

Failure
Legends
EMV0 = $ 0 mill
Do not build
the ERP system
Decision
Node
$0 mill Project
Abandoned
Event or
Probability
Node
Interpreting the Decision Tree Correctly

Decision trees provide us a method to choose one path when presented with multiple
alternatives having uncertainties. However, the real value of a decision tree does not
end here for the manager looking to quantify risk. For the sample decision tree we used
earlier the build a table shown in Error! Reference source not found.. Note the
conditional probability for full and partial success. They are conditional because the
60% or 40% success probability depends on a 50% prior probability that the project
goes forward.
FIGURE 41: Interpreting Decision Tree
What the table indicates in simple terms is that there is a 20% chance of making $ 30
million or less, a 50% chance of making $ 100 million or less and a 50% chance of
making a loss of $ 20 million if we decide to build the ERP system. Thus the tree
provides us with a range of impact values with different levels of confidence; it also
indicates that risk is not a single number but a range of possibilities.
127
P E R F O R M
R I S K
A N A L Y S I S
Sensitivity Analysis
Using the data in Error! Reference source not found. it is possible to determine what
value, for some or all of the uncertain variables such as probability of success\failure,
probability of full\partial success or amount lost on failure in the tree, can change our
decision in the ERP project to abandoning it instead of building. This is a case where
the EMV for the Build ERP system becomes negative.
This can be done through Sensitivity Analysis where we choose one uncertain
variable keeping others constant and try different values to determine at what point we
get an overall EMV less than 0.
For illustration let us choose the variable of interest to be p=Probability of Project
Success (so 1-p = Probability of Failure). We can solve for p by specifying that the
following equation must be less than 0
(1-p) x -20 million + p x 60% x 100 million + 40% x p x 30 million < 0
Solving this we get p < 22% i.e. at 22% or less chances of success the ERP project
should be abandoned. The PM now has a lower limit on the chances of full success i.e.
22% and can either take appropriate action to increase these chances or avoid\mitigate
risks that reduce the impact value.
Risk Attitudes and Utility Functions
A decision tree normally leads to a path with an optimized EMV or EV, one that
signifies least risk or the maximum opportunity. However the final decision is often
taken by an individual, a group or even an organization that has certain risk attitudes
that may alter the final decision. We discussed risk attitudes in Risk Management
Planning, and here we look at quantifying their effect on project decisions.
To understand the effect of risk attitudes we relook at the ERP system example from
the perspective of a risk-averse organization. Such an organization would avoid project
decisions that had the possibility of failure leading to a large loss even if such a decision
had a chance of substantial gain. In other words they would seek a much higher gain
for a given chance of loss when compared to a Risk-Neutral group. Remember a RiskNeutral group is balanced and looks to maximize its value or minimize its cost to
them the ERP build would make sense.
A risk-seeking organization on the other hand would seek relatively small gains
compared to a Risk Neutral group in order to take the project decision to go ahead.
One method to express these different risk attitudes is through the use of Utility
Functions which is applied to all monetary values in the decision tree when it is built.
What the utility function does is to decrease (for Risk Averse) or increase (for Risk
seeking) or leave unchanged (for Risk Neutral) the real value of money (or any other
unit of uniform measure) per unit increase in risk.
128
P E R F O R M
R I S K
A N A L Y S I S
The Square Root - x function for example is a simple utility function that can be used
to express Risk Aversion using this we can redo the risk table for our example as
shown in FIGURE 42.
FIGURE 42: Final Expected Values
The final expected value is now reduced to $1.9 million, still greater than abandoning
the project, so the earlier decision to build the system remains unchanged. Clearly for
this type of risk-averse group any changes to either the chance of success\failure or the
quantum of loss can quickly change the final decision.
For example for this Risk Averse group doing a Sensitivity analysis on p=Probability of
Success shows
(1-p) x -4.47 mill + p x 60% x 10 mill + 40% x p x 5.5 mill < 0
And we find that p needs to be 35% or more, higher than the 22% for a Risk Neutral
group. PMs in such organizations need to go to greater lengths to ensure risk
avoidance and mitigation steps are in place.
Key Outputs from Quantitative Risk Analysis
The key outputs from this process step is the Updated Risk Register which should
contain the following
A probabilistic analysis of the project using the tools mentioned includes

ranges of schedule and cost estimates with associated confidence levels. The
example output showing potential impact values and associated confidence
levels from the Monte Carlo and decision tree methods is an example of this
data.
Contingency reserves calculations based on the Probabilistic analysis. This is a

way to quantify and justify to management the need and amount of
contingency reserves to cover shortfall. For example the Monte Carlo
simulation shows that the maximum potential delay at 90% confidence is 21
days compared to a most likely PERT estimate of 15 days a wise PM would
then add a contingency buffer of an extra 3 to 6 days to their 15 day estimate.
129
P E R F O R M
R I S K
A N A L Y S I S
Prioritized list of quantified risks which builds on earlier risk prioritization to

identify the risks that pose the greatest threats or opportunity to the project by
giving them a quantifiable measure and allowing finer comparison between
them.
Trends in quantitative risk analysis when this step is done regularly as new
information comes the PM can spot trends in the values that indicate if some risks are
growing or diminishing over time.
130
P E R F O R M
Practice Questions
131
R I S K
A N A L Y S I S
P E R F O R M
R I S K
A N A L Y S I S

Question
Answer
Justification
1
2
3
4
132
R I S K
R E S P O N S E
P L A N N I N G
Chapter
18
Risk Response Planning
This is the step taken to develop options and scenarios to mitigate or eliminate risks
and threats to the project. The risk response should be in line with the significance of
the risk, be cost-effective, and realistic. Normally a collaborative discussion needs to
occur to assure the best option is the response.
The key input for this step includes the Risk Management plan and the Risk Register.
The Risk Management plan provides definitions of roles and responsibilities for who
owns a risk and who owns the budgets, and thresholds to decide on risks while the
Risk Register contains the resulting risks from the qualitative and quantitative analysis
to which responses need to be determined.
The key to a Risk Response is to approach it strategically by focusing on both threats
and opportunities. Typically the responses to a Threat\Opportunity are
Avoid\Exploit For threats the aim of avoidance is to make the risk impossible
or irrelevant. For example choosing not to use a new development tool with
an associated risk of time lost due to steep learning curves is a case of
Avoidance. For opportunities exploit means making sure this opportunity
happens benefiting the project.
Transfer involves another person or a 3rd party whereby part

of the risk, both the impact and the responsibility for managing any downside,
is transferred to this other group. Buying Insurance is an example of how risk
can be transferred to an Insurer, the risk premium charged by the Insurer is
a function of the risk characteristics (probability, impact), whether the insurer
has a portfolio of similar risks they can use to reduce their overall risk.
Transfer\Share
A notable feature of the transfer strategy of risk is that
Worst case scenarios will become better e.g., insurance against fire will
ensure recovery in case of a serious damage
"Best or Expected case scenarios will become slightly worse i.e. the value will
decrease since a risk premium (i.e. extra cost) has to be paid to the 3rd party
133
R I S K
R E S P O N S E
P L A N N I N G
So the transfer option should be chosen only when the improvement in the worst
case scenario is greater than the reduction in the best or expected case.
The case of share is when an organization wishes to share the risks with others
while seeking a big opportunity that it could not have attained on its own. Very
large scale project opportunities are often sought by companies forming
consortiums (partnerships), sharing the risk in return for a large slice of the
opportunity pie.
Mitigate\Enhance
Accept
Mitigation of a threat aims to reduce its probability

and\or impact, enhancing an opportunity seeks to increase it. This often needs
to be justified with a cost-benefit analysis exercise.
For residual threats and opportunities (i.e. the threat or opportunity
remaining after controls are in place) where cost of proactive action is more
than the risk impact i.e. risk response is not cost-effective, accepting the risk is
the best option.
Acceptance of risks can be of two types:
Accept Passively
Accept Actively
when impact of a Risk is well below the organization

threshold, no prior plans are put in place
- when impact, if the event occurs has to be reduced. In
this case a contingency plan is required to reduce the overall impact. Plans
are made but not executed unless the event occurs.
Funding Implications for Risk Responses

Any process of responding to risks may have a funding\cost and time implication
which needs to be understood since an efficient solution implies that it is less expensive
to implement than the risk it is trying to solve. Typically an organization has different
types of budgets that it maintains to execute projects
amount of money (or time) estimated for all
normal activities planned for in a project. This is normally within the control of the
Project Manager and is the one tracked for performance assessment.
Operating or Performance budget
is the money (or time) that is set aside for risks and
unplanned activities (for the known Unknowns). When a risk takes place this fund is
used to transfer money to the Operating budget. Sometimes a Project Manager may
require approvals from higher authorities (e.g., a Project Steering Committee) to do this
transfer accompanied with justifications.
Contingency Reserves
134
R I S K
R E S P O N S E
P L A N N I N G
this is a set of funds that are available only to the senior

management and are meant to tackle the unknown unknowns i.e. extreme risk
conditions for activities not identified. This is the last line of defense against risk.
Management Reserves
FIGURE 43 captures the different budget implications for each type of Risk response
strategy chosen
FIGURE 43: Risk Response and Project Funding Implications
Risk Response Planning An example

The following example demonstrates the different risk responses that can be chosen
for a given situation:
Below are some suggested risk response actions:
135
R I S K
R E S P O N S E
P L A N N I N G
1.
Threat (a) can be Accepted Passively and nothing may be done about
this need for security outweighs the issue of staff dissatisfaction.
2.
Threat (b) falls into the unacceptable or Avoid response, we need to

reduce the impact. We can implement an alternative security access
mechanism working at all times to double up in case of any failures. If the
bio-metric device fails we switch over to the alternative this is a
Contingent action i.e it is invoked after a Risk event has occurred.
3.
Threat (c) falls into the Mitigate\Avoid category where we need to focus
on both preventing the Risk (i.e reduce the probability of the event) and
Impact (financial reputation loss).
We can install a parallel security access system independent to the biometric system. Both need to pass for any access permission to be
given. This reduces probability of the risk.
We can also use a Transfer strategy by insuring the contents of the

research facility against information or material loss to counter Threat
(c) reduces the impact of this Threat.
Note that by taking these Risk Response actions there is either an impact on other risks
or secondary risks arise
Risk due to threat (a) may now increase since staff dissatisfaction is likely to be
higher. They are expected to use 2 access systems instead of one. This could
require a Response to move from Accept Passively to Accept Actively, for
example prepare training programs explaining why this is being done and
provide these as needed.
There is a risk the insurance company does not pay in the instance of loss or
there are protracted legal issues we could consider this to be low and
Accept Passively
At this point since no other risk remain that are not contained our risk responses are
complete.
Key Outputs from Risk Response Planning

The key outputs from Risk Response planning include:
Risk Register updates with the appropriate risk response
Project Management plan updates occur as response actions are added through
change control
136
R I S K
R E S P O N S E
P L A N N I N G
Risk related contractual agreements such as ones for Insurance, Contractors, Suppliers
specifying each partys responsibilities and risk ownership.
137
R I S K
R E S P O N S E
P L A N N I N G
138
H U M A N
R E S O U R C E S
P L A N N I N G
Chapter
19
Human Resources Planning
In the Estimate Activity Resources process you looked at the Activity List and
Activity Attributes to come up with resource requirements for performing each of
those activities. You documented this in the Activity Resources Requirements. In the
Develop Human Resources plan process you would be reviewing these resource
requirements and would document a plan on how you would go about acquiring the
skills required and optimally staffing your project. You would also be documenting the
roles, responsibilities and reporting relationships. The activity resource requirement is
therefore a key input to the Develop Human Resources Plan process.
Your organization may have policies on how to acquire people and what roles are
appropriate for your organization. These policies would greatly influence your plan.
Your experience on previous projects and historical information available from your
organizations process asset repository which provides lesson on successful project
organization structures will help you plan your human resources requirements better.
Your organizations process assets is also an input to the development of the
Human resources plan for your project.
also influence development of human resources plan.
For example, the market conditions may be fluid with high attrition rates. You would
need to build in redundancies in your organization structure to mitigate the impact of
resources leaving in the middle of the project. Enterprise Environment Factors are also
key inputs to developing the human resources plan.
Enterprise environment factors
Tools & techniques for HR Planning

Several tools and techniques exist to determine the optimal staffing levels for a project
team. One method is to develop an organization chart - at this time you will have just
the boxes and the relationships between the boxes. The idea is to come up with a
structure such that each and every work package defined in the WBS has a clear owner.
It is also important to develop descriptions for each of the position in your team.
Other formats of doing the same thing include:
RACI chart:
This chart is a matrix that has work packages or activities on one

dimension and role assignment on another. Role assignments could be Responsible,
139
H U M A N
R E S O U R C E
P L A N N I N G
Accountable, Information and Consultative. You need to ensure you hold only
one person accountable for an activity. Responsibility-Assignment Matrix (RAM) is a
similar matrix that states that references team members and work-packages.
Text-oriented:
This is a textual representation of the roles and responsibilities along

with positional description.
is a very good way of keeping yourself abreast of what is happening in the
market with regards to resourcing. Networking with peer project managers in your
organization, social or informal meetings with project managers and experts from the
industry and well as formal meetings and conferences will help you increase your
awareness and understanding of staffing management options.
Networking
Knowledge of Organization Theory will help you understand how teams work
together and this in turn will help you define an optimal structure for your project. You
will learn more about Organization Theory in the Develop Project Team process.
HR Planning - Outputs
A human resources plan is the main and only output of this process. It must, at the
minimum, contain the project organization chart as well as the roles and responsibilities
for each category of staff. Staffing Management Plan is a key constituent of the HR
plan. A typical Staffing Management Plan contains:
Staff acquisition plan
Training needs for staff
Criteria for rewards and recognition, and
Staff release plan

1.
What is the difference between a RACI chart and a RAM?

Both RACI and RAM are used to reference work packages and
responsibility. RAM is a matrix that shows primary and secondary
responsibilities. RACI describes the role assignment a bit more clearly that
the RAM. FIGURE 44 shows a sample RAM and RACI matrix. Please
note that at the time of HR planning you will not have names of your team
members so the RAM and RACI matrix will have only roles or
designations.
140
H U M A N
FIGURE 44: RAM and RACI
141
R E S O U R C E S
P L A N N I N G
H U M A N
R E S O U R C E
P L A N N I N G
Practice Questions
142
H U M A N
R E S O U R C E S

Question
Answer
Justification
1
2
3
4
143
P L A N N I N G
Q U A L I T Y
P L A N N I N G
Chapter
20
Quality Planning
Quality is defined as conformance to requirements. Quality is achieved when a
product or a service completely meets not exceeds - a customers requirements.
Exceeding the customer expectations is commonly referred to as Gold Plating and is
undesirable in projects. Quality has also been defined as fitness to use. An product or
service is fit for use if
It meets all the end-users functional and non-functional requirements (scope

baseline)
It is affordable i.e. within the cost expectation of the end-users (cost baseline)
It is available on time (schedule baseline)
Impact of Poor Quality

Poor quality always results in lower customer satisfaction, higher rework, lower
productivity and increased costs. It may also result in low morale of staff producing as
well as using the product.
Benefits of meeting quality requirements include increased customer satisfaction, lower
costs and lower probability of cost increases, increased productivity.
Inputs to Quality Planning

You and your project team would need to perform the planned activities in order to
meet the requirements; however, uncertain events may impact quality of the product or
service. You would therefore need to review the risk register to understand the
impact of risks on quality of the product or service. Stakeholder Register is also to be
reviewed because it may contain information of stakeholders that may have a particular
interest on quality of the projects product. The project manager has the ultimate
responsibility for the quality of the product or service. However, each team member is
responsible for quality of his/her work.
144
Q U A L I T Y
P L A N N I N G
The key inputs for quality planning are the Scope Baseline, Cost Baseline, Schedule
Baseline, Stakeholder Register and Risk Register. Other inputs are Organization
Process Assets (such as your organizations quality policies, processes and procedures)
and enterprise environment factors.
Quality Planning Tools & Techniques

Tools and techniques described below will help you define quality standards for your
project.
Benefit/Cost Analysis
Cost benefit analysis is a powerful tool for planning. Project Managers use this to make
rational decisions on implementing change to an existing system. This tool involves
measuring the value of the benefits of implementing a change, and subtracting the
costs of implementing the change.
Benchmarking
It is a process of comparing previous similar activities to the current project activities
and to provide a measure of quality performance.
Design of Experiments
This is a statistical technique that identifies the variables that will have the greatest
effect on the project outcomes.
Cost of Quality
The cost of quality is the total cost to produce the product or service according to the
quality standards. It includes:
Prevention costs
Appraisal costs
Failure Costs
these are costs associated with satisfying customer

requirements by producing a product or service without defects. Costs
expended on activities such as Quality planning, Design reviews, Education
and training of stakeholders are examples of prevention costs.
these are costs associated with examination of the product
or process and making sure that the customer requirements are being met.
Costs expended on activities such as inspection or testing are examples of
appraisal costs.
these are costs associated with fixing issues in the product or
process. These are of two types internal and external.
costs occur when customer requirements are not satisfied
while the product is still in the control of the organization. Costs resulting due
to rework and scrapping are result of internal failures. External failure costs
Internal failure
145
Q U A L I T Y
P L A N N I N G
result when the product reaches the customer and the customer then
determines that the product does not meet their requirements. Product returns,
inspection and repair at customer site are results of external failure costs.
Statistical Sampling
Statistical sampling involves performing some checks on randomly selected items
produced by the project. While the actual execution is carried out as quality control
processes, as far as quality planning is concerned you would determine sampling
parameters such as sample size, variable of measurement and frequency of
measurement.
Control Charts
A control chart is a time-phased representation of a process. It helps you determine if
the projects process is in control or if it requires attention. You must note that every
process has variation some variations require attention, some do not. A control chart
has the following components:
It has a horizontal line the X Axis - that identifies the time scale
It has a vertical line the Y Axis - that identifies the scale of measurement for
the variable of interest.
It has a horizontal center line (centerline) that corresponds to the mean of

the process
In addition to these, a control chart also has two horizontal lines called the upper
control limit and the lower control limit. These horizontal lines are equidistant from
the centerline the upper control limit being above the centerline and the lower
control limit below the centerline. The control limits are 3 standard deviations away
from the centerline
In quality planning you will not have the data to determine the mean, upper and lower
control limits. You would need to specify how you would use control charts to plan
quality.
Flow Charting
Flow charts, or process flow diagrams, are used to understand a process by
documenting its steps. Understanding a process is essential for quality improvement
since you must understand a process before you can control it. By documenting the
entire process, flow charts can help teams identify areas in the process in which
improvements can be made.
Proprietary quality management methodologies such as the Six Sigma, Quality
Function Deployment and CMMi can also be used for planning. Other quality planning
tools include
Brainstorming, Affinity Diagram, Force Field Analysis and Nominal

Group Techniques.
146
Q U A L I T Y
P L A N N I N G
Outputs of Quality Planning

The quality management plan is a key output of the quality plan process. It describes
what standards your project would implement, what quality tools and techniques
would be used and how.
that define the attributes of the projects product is also an output of
the quality plan process. Metrics can also describe the overall project quality.
Quality metrics
In order to ensure your project implements the defined standards you would need to
prepare checklists. Checklists are structured tools used to verify that a set of planned
steps/procedures have been carried out and would be used in the quality control
process.
147
Q U A L I T Y
P L A N N I N G
148
Q U A L I T Y
Practice Questions
149
P L A N N I N G
Q U A L I T Y
P L A N N I N G

Question
Answer
Justification
1
2
3
4
150
P L A N
C O M M U N I C A T I O N S
Chapter
21
Plan Communications
Plan Communications is part of the Planning Process Group
Communications Management Knowledge Area
and the Project
Large projects have many stakeholders and it is important you keep all of them
informed about the status of the project. A clear communications plan is vital in
successfully managing a project. The primary purpose of this process is to plan
communications related activities and document it.
In the Identify Stakeholder process you developed a Stakeholder Register and a
Stakeholder Management Strategy. In the Plan Communications process you will use
these documents to decide on who to send what information, in what detail and how
frequently. This process helps you keep your stakeholders informed and also helps you
communicate a consistent message to your target audience.
The
Stakeholder Register, Stakeholder Management Strategy, Organization
and Enterprise Environment Factors are inputs to planning

communications for your project. These inputs have been discussed in detail in the
earlier chapters.
Process Assets
Plan Communications Tools & Techniques

You need to analyze your stakeholders communication requirements. You can
review the organization charts of the requesting organization, key stakeholder
responsibilities and relationships and the stakeholder management strategy document
you prepared in the Identify Stakeholders process to analyze your stakeholders
communications requirements.
Global locations, distributed teams and distributed stakeholders mean that you would
have to rely to communication technology to keep in constant touch with your
stakeholders. Sophistication and investment in technology would depend on several
factors such as urgency (if you dont communicate immediate you run the risk of
project failure), availability (the customer organization does not have a video
conferencing facility and though you have it in your office you cant use it) and project
151
P L A N
environment (does your type of project require online demonstration of the product
every time you meet?)
Face-to-face meeting is an excellent means of communicating information to your
stakeholders. However when your stakeholders are located in different parts of the
world it is impossible to have face-to-face meeting every now and then. In such
situations you would have to rely on communication technology. Holding electronic
meetings (i.e. telephone, chats etc.) have its own advantages (i.e. costs) and challenges
/limitations (i.e. inability to elicit information through body language etc.). As a project
manager you need to understand the basics of communications models. You as a
sender are responsible for making sure your stakeholders (receivers) have understood
the information. Receivers (your stakeholders) are responsible for understanding and
acknowledging the receipt of information. You must also be aware of the noise in the
communication processes. Noise is a term that is used to describe barriers in
communication that may destroy information.
There are several communication
with your stakeholders. These are:
Push Communications:
Pull Communications:
Interactive Communications:
methods
that you may use to share information
This is a method that you use to send required

information to stakeholders. This includes emails, memos, voice mails, faxes
etc.
This method is used for large volumes of information
or for large amount of recipients. This includes intranet sites such as your
project SharePoint portal, knowledge repositories etc.
While the above two methods are one-way,
these types of communication involve parties performing multi-directional
exchange of information. This includes tele-conferencing, video conferencing,
meeting etc.
Plan Communications Outputs

A Communications Plan is an output of the Plan Communications process. The
Communications Plan outlines who should communicate with whom and how often.
A communication matrix, which is part of a typical Communications Plan, is as shown
in FIGURE 45. Other inputs are project document updates.
152
P L A N
FIGURE 45: Communications Plan

1. What amount of time does a project manager spend in communications?
Roughly about 80% of the project managers time is spent in communications.
This includes reading and compiling emails, collecting data, preparing status
reports, conducting meetings, managing relationships with stakeholders etc.
2. What is a communication channel?
Communication channel is a means of communication. The channels increase
exponentially as the number of stakeholders. The number of communication
channels (c) in a project can be determined by the following formula.
n.(n 1)
2
Where n is the number of stakeholders.

3. Your team has 5 members. Two new members are added to your team. What
is the change in number of communication channels?
Using the formula above, we can find the number of communications
channels in a team of 5 which is 10.
The team size becomes 7 when 2 new members get added. The number of
communication channels, using the formula above, is 21. The difference in
number of communication channels is 21-10 = + 11
Practice Questions
153
P L A N
154
P L A N

Question
Answer
Justification
1
2
3
4
155
P L A N
P R O C U R E M E N T
Chapter
22
Plan Procurement
Plan Procurement is part of the Planning Process Group
Procurement Management Knowledge Area
and the Project
The term procurement refers to obtaining products, services, materials or any other
resources from outside the performing organization. The Plan Procurement process
deals with documenting procurement related decisions of acquiring outside support for
your project including identifying potential sellers.
Inputs to this process are:
This includes a detailed description of the product or service that
needs to be procured along with acceptance criteria
Scope Baseline
The requirements document contains functional as

well as non-functional requirements that need to be mapped on to the product or
service that is to be procured.
Requirements Documentation
When two or more parties are working together on a project

(say a joint venture) the contract between the parties defines the roles of a seller and
buyer. The contract significantly impacts the planning process and therefore is a key
input to this process.
Teaming Agreements
Risk Register The risk register contains risks identified with the procurement work.
These are in response to the identified risks and

include things such as procuring insurance, hedging funds to mitigate risk of currency
fluctuations etc.
Risk-related Contract Decisions
This identifies people, type of people and

numbers required on the procurement work
Project Schedule
are needed.
Contains information on dates by which the required deliverables
Activity Cost Estimates -
156
P L A N
Cost Performance Baseline Planned budget for procurement related work

and Organization Process Assets are also inputs to
this process.
Plan Procurement Tools & Techniques

is a technique that is used to decide if a product or service can
be built internally or it is best to procure it from external sources. Factors that influence
a make-or-buy decision include budget, availability of skills and time constraints.
Make or Buy Analysis
In a situation where you decide to procure the product or service from external sources
you will need to decide on the type of contract to award. Decision on type of contract
is driven by several factors such as clarity of the requirements, availability of vendor
options and of course time and schedule constraints.
Fixed Price Contract: This type of contract is one in which the buyer agrees to pay the
seller a fixed amount of money on completion of the agreed work. This type of
contract is preferred when the work is not very specialized, requirements are very well
defined and many vendors have the capability to provide the required service. Since the
amount is fixed the seller has to bear the risk of costs exceeding the contract amount.
Variants of this type of contract are:
Fixed-price Plus Incentive Fee:
Firm Fixed Price:
Fixed Price with Economic Price Adjustment:
While the contract has a fixed amount the

buyer may provide financial incentives over the fixed amount in order to get
the work done faster and better. Criteria or a formula to calculate the incentive
amount is worked out and the incentive amount is actually calculated at the
end of the project based on criteria.
This is the most common type of contract preferred by the
buyers. The price of contract is set and is not subject to changes unless the
scope changes.
These contracts are
appropriate for projects that span several years. This is a fixed price contract;
however, the final price is determined by changes to economic conditions such
as increase in inflation, interest rates, changes to foreign currency exchange
rates etc.
This type of a contract involves the buyer paying the

seller costs at actuals for the amount of work completed. In addition a fee (representing
seller profit) is also given on completion of the project. In these types of contracts the
buyer has more risk since the price of the project is not known upfront. Variants of
this type of contract are:
Cost Reimbursable Contract:
157
P L A N
Cost plus Fixed Fee:
Cost plus Incentive Fee:
Cost plus Award Fee:
Actual costs are paid to the seller for the amount of

work completed. A fixed fee is paid on completion of the project.
Actual costs are paid to the seller for the amount of
work completed. A predetermined incentive fee is also given to the seller and is
determined based on how much lower the final costs are from the original
project estimates.
While all legitimate costs are paid to the seller on
actuals, a higher proportion of amount if awarded to the seller based on the
project performance and meeting established project criteria.
Time & Material Contract:
This is a hybrid arrangement that has characteristics of

fixed price as well as cost reimbursable contracts. These are used usually when the
statement of work cannot be clearly defined. This type of contract is used to hire
consultants and outsourcing of lower end work. In these types of contracts the unit
labor costs and material costs are preset.
is also one of the tools to assess the inputs and outputs of the
procurement planning process. Legal, technical and other specialist are often used to
develop proposal evaluation criteria and for other services related to the procurement
planning area.
Expert Judgment
Procurement Planning Outputs

is one of the key outputs of this process. A
procurement management plan, amongst others, contains:
Procurement Management Plan
Types of contracts that would be awarded
Process of make-buy decision making
Issues related to risks with procurement of the service in question
Scope and brief of the project management team
Process of managing multiple suppliers
Constraints and assumptions
is a procurement document that is prepared using

the scope baseline of the entire project. This document must clearly state the portion
of work to be done by the contractor. Any other collateral service required such as
support for post project delivery etc. must also be stated in this document.
Procurement Statement of Work
158
P L A N
Key decisions leading to procuring the services from an outside agency must be
documented. This document must clearly provide details of the make-buy decision.
required to solicit information from prospective
vendors/suppliers is also a key output of this process. Documents such as Request for
Proposal (RFP), Request for Bid (RFB) etc. may be used to solicit information from
suppliers.
Procurement
documents
is a key constituent of procurement documents. These

criteria are used to evaluate proposals sent in by prospective vendors. A scoring model
such as the one we saw in FIGURE 11 (Page 23) can be used to evaluate the proposals.
Some criteria for evaluation of vendors could be
Source Selection Criteria
1.
Technical capability and proof of work done for other customers
2.
Management approach
3.
Size of vendors business in terms of revenue and number of staff
4.
Number of years in existence
5.
Past performance
6.
References provided by vendor
Any changes to the procurement process must be documented and raised as a change
request that must be put forward to the CCB for approval, and actioned based on
recommendations of the CCB.
159
P L A N
Practice Questions
160
P L A N

Question
Answer
Justification
1
2
3
4
161
P L A N
Practice Questions

Question
Answer
Justification
1
2
162
3
4
163
D E V E L O P
P R O J E C T
M A N A G E M E N T
P L A N
Chapter
23
Develop Project Management Plan
In the previous section you planned your project work and documented your ideas in
the project
164
D E V E L O P
P R O J E C T
M A N A G E M E N T
165
P L A N
Executing Processes
LEARNING OBJECTIVES
167
D I R E C T
A N D
M A N A G E
E X E C U T I O N
Chapter
24
Direct and Manage Execution
In the previous section you planned your project work and documented your ideas in
the project management plan. In this section you will need to start putting those ideas
to work i.e., get your team to perform the work defined in the project management
plan. In addition to this you would also get change requests. This process helps you
integrating the work involving approved change requests to the project.
Directing Execution
Direct and Manage Project Execution can be considered to be the master process for all
other execution processes. In this process you transform the plan by executing activities, and
generate the final output/deliverable. As a project manager you start execution by
acquiring resources, training them if required, committing and authorizing them to
work on activities and tasks defined in your Project Management Plan. You will need
to interact with suppliers and vendors and procure resources for your project. You will
need to oversee implementation of standards and establish communication channels
with your stakeholders.
As you and your team perform the defined work you start expending money and
generating output. Your stakeholders, more so the sponsor would want to know the
status of accomplishment of the project. As the project manager it is your
responsibility to keep track of not just utilization of resources but also the amount of
money you are spending to accomplish the defined work. In this phase of the project
your job as a project manager will involve more of overseeing progress of the project,
collecting project performance data and reporting progress to stakeholders.
Managing Execution
Not many projects are executed as per plan. Things go wrong during execution some
of the resources may not join your project on time, or the vendor may not supply the
required material as planned, or an activity planned for completion may be delayed for
some reason. As the project manager you are responsible for taking corrective actions
and getting the project back on track. Corrective actions may involve making changes
to the project scope, schedule, budget, resourcing or any other factor that will put the
project back on track. You may also have to take some preventive actions to avoid
recurrence of undesirable events on the project. Preventive actions usually involve
making changes to the project policies, processes or procedures. In some cases the
168
D I R E C T
A N D
M A N A G E
E X E C U T I O N
output generated by your team may not fully meet the functional requirements as
requested by the customer. In such cases you will need to get your team to rework on
the defective output and fix it.
Executing corrective actions, preventive actions and defect repair activities may, in
most cases, require a Change Request and must, therefore, be done post its approval.
As seen from the discussion above, the Project Management Plan and Approved
Change Requests are key inputs to the Direct and Manage Execution process. Other
inputs are Enterprise Environment Factors and Organization Process Assets.
Direct & Manage Execution - Tools & Techniques

or opinion must be sought if you want to assess the inputs needed
to execute the project plan. Expert advice can be sought from peer project managers,
consultants, professional bodies etc.
Expert Judgment
During execution you would rely a lot on automated project management / scheduling
software referred to in the PMBOK Guide as Project Management Information
System (PMIS). This is part of the Enterprise Environmental Factors and is also one
of the tools to direct and manage project execution.
Outputs of Direct & Manage Execution

As discussed earlier, in the Direct and Manage Project Execution process you execute
the project management plan and produce deliverables. By definition of project, a
deliverable is a unique product or service. Once all deliverables of a phase or project
are approved by stakeholders the phase or project is considered complete.
Final deliverables are not the only things that would be of interest to stakeholders.
During execution you will need to retrieve data from the project management
information system, process it and distribute it to stakeholders. The information you
send to stakeholders may include status of deliverables and the overall project, costs
incurred and progress on schedule. You may also need to send information, with a
certain degree of confidence, forecasting the expected completion date of the
project/deliverables and expected costs at completion. You may also need to send
information that key stakeholders demand during the execution of the project. This
package of information is referred to as work performance information. A sample
report (without forecast information) is shown in FIGURE 46.
169
D I R E C T
A N D
M A N A G E
E X E C U T I O N
FIGURE 46: Work Performance Information
Changes or change requests are inevitable on any project. As your team executes the
work you will come across changes that have been requested by stakeholders as well as
sources external to the project (government regulations etc.). Changes can be dictated
because of advancement in technology as well. It is incorrect to accept a change and
ask your team to implement it. FIGURE 47 shows a sample change request.
FIGURE 47: Sample Change Request
170
D I R E C T
A N D
M A N A G E
E X E C U T I O N
The right thing to do is to analyze each and every change, study its impact on the
project (impact on schedule, cost and quality at a minimum) and present it to a group
that is responsible for making a decision on implementing the change in the project.
This group is referred to commonly as the Change Control Board (CCB) and its
members consist of key stakeholders including you, the project manager. The project
can implement only those changes that are approved by the CCB.
Acceptance of a change request by the CCB will require you to update the project
management plan and/or other project document such as requirements document,
risk register, issue log etc. The updates to the project management plan and the project
documents are also output of this process

1. What is a deliverable?
A deliverable is a unique verifiable product, result or outcome that must be
developed to consider a project or its phase complete.
2. Do I need to raise a change request to repair a defect?
A change request must be raised to change or update any component of the
project that is baselined. If a defect is documented in a delivered component of
the project you must raise a change request. If the work is in process you need
not raise a change request
3. What are some of the documents that help you and your key stakeholders have
a common understanding of the project
Common understanding means that all key stakeholders of the project are on
the same page as far as the project objectives are concerned. Some of the
documents produced that reinforce this common understanding are the Scope
Statement, WBS & WBS Dictionary, Project Schedule and the Project
Management Plan.
Practice Questions
1. You are a project manager on Project X that is currently in execution. Your
customer asks you to add a small new feature to the projects product. You
know that the addition will not change the schedule but will increase the cost.
What is the correct thing to do?
a) Inform the team and get the new feature added in the scope
b) Discuss with your senior manager
171
D I R E C T
A N D
M A N A G E
E X E C U T I O N
c) Ask the customer to submit a change request that will be looked into by
the CCB
d) Tell the customer that the new feature can be added in the next phase of
the project.
2. Inputs to the Direct and Manage Execution process are all of the following
EXCEPT:
a) Approved change requests
b) Change requests
c) Organization process assets
d) Enterprise environment factors
3. Outputs of the Direct and Manage Execution process are all of the following
EXCEPT:
a) Approved change requests
b) Change requests
c) Project Management Plan updates
d) Project Document updates
172
D I R E C T
A N D
M A N A G E
E X E C U T I O N

Question
Answer
Justification
Any changes to the project scope that has an impact on the

cost or schedule must be reviewed by the CCB
Change requests must be approved before being

implemented on a project.
Approved change requests are inputs
173
A C Q U I R E
P R O J E C T
T E A M
Chapter
24
Acquire Project Team
In the Develop Human Resources Plan process you created a human resources plan
(part of the Project Management Plan) in which you documented your projects
staffing needs. The Acquire Project Team process deals with obtaining the human
resources necessary for your project and in this process you would be executing this
plan. You must note that this process is part of the executing process group. This,
however, does not mean that you obtain resources after the completion of the planning
process group. You would have already got critical resources on your project much
earlier to work on planning the project. In this process we deal with acquiring people
that we would need to execute the project work. For example, on an IT project you
would acquire developers and testers. The project management plan is a key input to
this process. Other inputs are:
You will need information about who is available to
work on your project, what skills they possess, their costs etc.
Enterprise Environment Factors:
Organization Process Assets: These are staffing policies in your organization that you
need to work with while acquiring people for your project.
Tools and Techniques to Acquire Project Team

In a matrix organization it would be relatively difficult to obtain internal resources. You
would need to negotiate with, and influence functional managers, peer project
managers and senior managers that are in a position of authority to provide the
resources for your project.
In situations where resources are to be obtained from outside the organization you
must be able to negotiate effectively with vendors and suppliers of human resources.
This is called Acquisition. You may hire full-time staff or contractors depending on
your plan.
In some cases your senior manager would have proposed staffing a prospective project
with named people. If a project is initiated as a result of that competitive bid then
those named people must be made available to the project. The names of such
174
A C Q U I R E
P R O J E C T
T E A M
people are already indicated in the Project Charter. This is called Pre-Assignment and
is one of the techniques of acquiring human resources to a project.
Traditionally projects have been executed with all team members co-located. However,
the advent of technology and an increasingly global nature of projects have created
possibilities of a global project team. Virtual teams are groups of people that are
located in different parts of the globe. While the team members share the goals and
responsibilities of the project they spend very little time face-to-face. Most interactions
happen electronically (emails/chats) or over the phone or via video conference.
Communications becomes even more important in situations where virtual teams exist.
Availability of technology makes it possible for you to acquire virtual team members.
Outputs of Acquire Project Team

Staffing is considered complete when all identified roles on your project are assigned to
the people you just acquired using tools and techniques that we just described. It is
quite important that you document these project staff assignments. The organization
structure in the project management plan is the best place for such documentation.
You must also provide a team member an Assignment Brief which is a document that
contains all mutually agreed goals and objectives to be achieved during the course of
the project. Later in the Manage Project Team process you would be using this
assignment brief as a basis to perform and document the appraisal or the actual
performance of the individual team member.
It is also important that you document the availability of your resources. In other
words some of your team members may have planned their holidays, some others may
be shared between your team and another. Once you have determined the resources
that would be working on your project you need to quickly develop a project resource
calendar indicating the availability of your resources for an appreciable period of your
project duration.
In some case you may not get the required resources as planned. You may get
resources that may not be an exact fit on your project but nevertheless they would be
suitable for your project with a bit of training. You must update the project plan with
this information.

1.
As a Project Manager what would you do immediately after you have

identified the resources for your project?
Once you have identified the resources for your project you need to
confirm their availability and develop a resource calendar.
2.
What does the term Acquisition mean?

175
A C Q U I R E
P R O J E C T
T E A M
The term Acquisition in the context of Acquire Human Resources

process means acquiring people from outside the organization.
3.
10% of your team members work out of another building that is about 2
kms from where you and the rest of the team work. Do you consider that
part of the team to be a virtual team?
Teams are virtual teams when they are not co-located. Instead of meeting
in person they use the phone or electronic means such as chats, video
conferences etc. If the team collaborates online and not face-to-face it
could be considered a virtual team. Team members working in different
shifts are also considered virtual team members.
Practice Questions
1. You are a project manager in a matrix organization. Who would negotiate with
for additional resources?
a) Peer Project Manager
b) Functional Manager
c) Senior Manager
d) Customer
2. The following are outputs of the Acquire Project Team process, EXCEPT
a) Project Management Plan updates
b) Resource Calendars
c) Virtual Teams
d) Project Staff Assignments
3. The first document where Pre-assignments are listed is
a) Project Charter
b) Scope Statement
c) Resource Calendars
d) Project Management Plan
176
A C Q U I R E
P R O J E C T
T E A M

Question
Answer
Justification
In a matrix organization you would share responsibilities

and power with a functional manager
Virtual Teams is an not output
Pre-assignments are first listed in a project charter.
177
D E V E L O P
P R O J E C T
T E A M
Chapter
25
Develop Project Team
Develop project team process deals with improving the team interaction, increasing
staff competencies and improving the overall performance of the team. This process
will require you to use your soft skills in motivating, leading and inspiring your staff.
The success of a project depends on how well your team works in cohesion, and
getting the team working together is one of your primary responsibilities as a project
manager. As your team performs work you must continuously motivate them, provide
instantaneous feedback and recognize and reward great performance.
Inputs required to develop your team include project staff assignments, resource
calendars and the project management plan. We discussed these in detail in the
previous processes.
Tools for developing your project team

As discussed earlier this process requires you to use soft skills or interpersonal skills to
help develop the project team. Key tools amongst these are:
Conflict Resolution
Motivation
Team Building
Leadership
Ability to influence
Conflict Resolution
Conflict is a clash of interest between two parties (eg. team members) and can
significantly reduce team productivity. Conflicts can occur because of scarce resources,
priorities between competing activities or schedules. It can also occur because of
personalities or disagreement on technical solutions. There are techniques to resolve
conflicts and you must be aware of these techniques.
178
D E V E L O P
P R O J E C T
T E A M
Motivating your team

It is important that you create a team environment that is conducive to all team
members to perform and give their best. There are different theories to motivate your
team and create a good working environment
Maslows Theory of Needs:
The philosophy is all people have needs. These needs can

be categorized into 5 levels. People start thinking of upper levels when the need at the
level they are currently is completely met.
Herzbergs Hygiene Theory:
This theory states that there are two factors hygiene

factors and motivating factors. Hygiene factors are like good working environment,
good working relationship with team members and boss etc. Absence of these factors
in a workplace could, however, be de-motivating. Motivating factors include things like
promotions, rewards etc. People will not care about motivating factors if hygiene
factors are not satisfied in their workplace.
McGregors theory states that there are two types of
supervisors one that believes that team members are responsible and are mature
enough to get their work completed on time (Theory Y), and another that believes
team members are lazy and cannot be trusted and that they need to be driven to
complete their work on time.
McGregors X & Y theory:
Building a team
You acquire individuals to staff your team. Success of the project depends to a great
extent on how you get these individuals to work together in a team environment.
Getting to a stage where a team that is working together efficiently does not happen by
chance and requires you to do a lot of work referred to as team building. Each team
undergoes 4 stages of development as described below:
Forming:
This is the first stage. Resources, on joining your team will try and find out
their exact roles in the team. At this stage they will tend to work almost independently
at times trying to work with a few of their colleagues.
Storming:
This is the second stage. Team members would still work individually and
will try and form opinions on team members. This is a stage where team members
would have dis-agreements would each other on how to execute the project.
Norming:
This is a stage where individuals being to trust team members and start
working with others by making small adjustments to their work habits. They are still
not performing at their peak.
Performing:
This is the best stage to be in. All team members are working together to
meet the project objectives. Each team member understands the others strength and
weaknesses as well as their own roles clearly.
179
D E V E L O P
P R O J E C T
T E A M
Adjourning:
The project team completes the assigned work and moves on to the
resource pool awaiting re-assignment to another project.
are project level policies or expectations established to maintain
acceptable level of behavior by project team members. The objectives of establishing
such ground rules are to prevent misunderstandings amongst team members and
prevent conflicts which in turn results in enhancing team productivity.
Ground Rules
Face-to-face interaction between team members is best when it comes to enhancing

communications. These interactions are possible only when the entire team is colocated. Interactions between team members on the corridor or around the coffee
table can increase communications and prevent misunderstandings.
While compiling the Human Resources plan you documented the criteria for
rewarding project team members. In this process you will be implementing the plan.
While instantaneous (or on-the-spot) rewards are the best recognizing and rewarding
team members during a town hall will have a greater impact on your teams
productivity.
Outputs of Develop Project Team

One of the outputs of this process is the Team Performance Assessment. The
project management team (or the steering committee) evaluates the effectiveness of the
team that has been put together for the project and also the probability of achieving the
project objectives. The formal evaluation report will help you put together a plan for
training your team members and putting in place changes that would increase the
effectiveness of your team in general.
Employee training records and formal reports on evaluation of skills, that are part of
the Enterprise Environmental Factors, are updated during this process

1.
Would you reward a project team member for working overtime?

It is a good practice to reward a team member who works overtime in
order to meet an aggressive schedule. However, it would not be a great
idea to reward a team member who is working overtime due to
inefficiencies in work practice and lack of self-management.
2.
You know about the different team building stages. Do they occur in the
order of Forming-Storming-Norming-Performing?
Usually, yes. These stages of team building do occur in order. However, in
it not uncommon for a team to be at, say the Storming stage, for a long
180
D E V E L O P
P R O J E C T
T E A M
period of time. It is also possible that a team behavior regresses. A team

can slip from say a norming stage to a storming stage.
Practice Questions
1.
Two developers are in a verbal duel over project estimates. One of the
developers walks out of the meeting angrily. What conflict management
technique has just been observed?
a) Smoothing
b) Avoidance
c) Forcing
d) Confronting
2.
Which of the following is NOT a motivating agent?

a) Recognition
b) Professional Growth
c) Working Conditions
d) Additional Responsibilities
3.
A team member is not performing well on your project. You would like to
communicate one of the following messages to him. Which of the
following is the worst choice?
a) I will nominate you to attend the next conference at Agra
b) I will not invite you to the lunch meeting with the customer
c) I will give additional responsibilities
d) I will approve your leave that you asked me for this morning
181
D E V E L O P
P R O J E C T
T E A M

Question
Answer Justification
Not opening a communication channel for conflict

resolution is a bad thing. Avoidance is also known as
Withdrawal.
Working conditions is a hygiene factor. Others are

motivating agents.
This is a penalty. Penalty power is the worst of the lot and

must be used only in exceptional circumstances. You will
learn more about powers in the Manage Team chapter.
182
M A N A G E
P R O J E C T
T E A M
Chapter
26
Manage Project Team
Manage Project Team is part of the Execution Process Group
Human Resources Management Knowledge Area
and the Project
Manage Project Team process follows the Acquire Project Team & Develop Project
Team processes. This process involves reviewing individual performances of team
members, providing them constructive feedback and resolving outstanding issues. The
following are inputs to this process:
Staff Assignments - provides list of staff assigned to your project
Project Management Plan
Performance Reports-provides
-provides templates for performance appraisals

as well as contains policies and procedures
project deliverables
a comparison of plan versus actuals for all
Yet another input to this process is the Team Performance Assessment, an

assessment of the project performance carried out by the Project Steering Committee
containing the project manager, sponsor and other key stakeholders. We saw this in the
previous chapter.
Tools and Techniques for Managing Team

As part of this process you would prepare, document and deliver performance
appraisals for your team members. You would have observed the behavior of your
team members during the course of the project. These observations are recorded in
an individuals appraisal or performance document (also called Assignment Brief in
some organizations). It is important you obtain feedback of the performance of the
individual in question from a random cross section of stakeholders. Conversation is a
common way to obtain such feedback. The feedback obtained must also be recorded
in the appraisal document. The consolidated feedback is delivered to individual team
members. It is a normal practice for project managers to schedule delivery of
183
M A N A G E
P R O J E C T
T E A M
performance appraisals (also called Assignment De-brief in some organizations). The
objective of documenting and delivering performance appraisal is to help team

members identify their strengths and areas of development. The team member gets an
opportunity to document future training needs and growth plans while the project
manager gets an opportunity to clearly understand ongoing conflicts and confirm roles
and responsibilities.
During the course of project execution several conflicts arise most of those would be
over schedules or resources. Some of the conflict management techniques that you
must be aware of are:
Confronting:
Compromise:
Forcing: This is also referred to as win-lose situation. One party forces (or puts
This is also referred to as collaborating or win-win. This involves

dealing with the conflict head-on and works out a solution that completely
fixes the problems of everyone involved in the conflict. This is the best conflict
resolution technique.
In this technique the conflict is resolved with each party giving
up something. This means that both the parties are not fully satisfied with the
outcome while the conflict is temporarily resolved.
her foot down!) a decision and gets the conflict resolved in her favor, the other
party loses out. This situation is likely when there is a conflict between people
at different levels in the organization or project team.
Smoothing:
Withdrawal:
This occurs when one party in conflict has low concern for self
and high concern for the other party. This technique may not really solve the
conflict but nevertheless may keep tempers down allowing people to step back
and figure out the real cause for the conflict giving them time to think about
alternative solutions.
This is the worst of all techniques. Both parties neither have
concern for self nor for the other party. If one party withdraws from the
resolution discussions then the resolution is simply not arrived at.
184
M A N A G E
P R O J E C T
T E A M
FIGURE 48: Conflict Resolution Techniques
During execution you and your team members would identify issues that may impact
your project objectives. You must document the issues in an Issues Log and assign an
owner to resolve it. Note that only project related issues must be recorded. Behavioral
issues and personal issues must be kept out of it.
A Project Manager has 5 types of power and would need to use it effectively to manage
the team. These are:
Formal Power
Manager
This power comes with the title/designation of Project
A Project Manager is expected to be experienced and

knowledgeable in managing people related issues and can be considered an
expert when it comes to solving these issues.
Expert Power
A PM can reward team member for performing well on a

project. This is the best power that a PM can use to motivate team members.
Reward Power
The PM can use the relationships with his superiors and

customers to effectively manage his team members.
Referent Power
The PM has the power to penalize his staff for not

performing well on the project. This is the worst type of power and must be
used only if other ideas have not worked.
Penalty Power
185
M A N A G E
P R O J E C T
T E A M
leadership, ability to influence, decisiveness will help you

manage the skills of your team effectively and thus ensure your team delivers as
planned.
Interpersonal skills
Outputs of Manage Project Team

As you resolve conflicts in your team you will identify need to change a few processes
that may prevent recurrence of undesirable events. This will need to be raised as
change requests which need to be approved by the CCB. Changes can also occur due
to movement of your staff. This can result in you having to change your baseline
schedule again something that you can implement only after your change request is
approved by the CCB.
Conducting performance appraisals of your staff may help you give more insights into
the process. Process or procedural changes to the system of performance appraisal
could be considered as your Organizations Process Asset updates.
Performance appraisals also give you an opportunity to update the skills database this
is an update to the Enterprise Environmental Factors.
The Project Management Plan may also need to be updated should there be any staff
movements from your project during the course of project execution.

1.
What are the common causes of project conflict?

The common reasons for conflict on project teams are:
2.
Project Schedules
Priorities
Resources, including availability of human resources
Technical approach to solving a given problem
Costs
Ego and personality
Two of your team members have differences in opinion. As their project

manager what should you do?
186
M A N A G E
P R O J E C T
T E A M
Initially you must encourage your team members to resolve the issues
themselves. However, if the issue escalates, you must get involved and
facilitate a satisfactory resolution.
Practice Questions
1.
Team members always listen to the Team Lead because he has the ability
to solve any technical problems. Which type of power is being observed?
a) Referent
b) Expert
c) Formal
d) Reward
2.
A conflict has divided a project team into two groups, one that says code
review must follow coding and another that says these activities must be
done in parallel. The PM advises that while code reviews are mandatory he
would not bother if it is done in parallel or after coding. What conflict
resolution technique has been observed?
a) Forcing
b) Confronting
c) Compromising
d) Smoothing
3.
A new recruit just out of college is not performing to expectations. What

should you do as his manager?
a) Consult with customer and see if he can be exited
b) Consult with Senior Manager and see if he can be shifted to a nonpriority project
c) Arrange for more training
d) Replace him with a more experienced developer
187
M A N A G E
P R O J E C T
T E A M

Question
Answer
Justification
Expert power gained due to experience and knowledge
This is compromising behavior
This is the best thing to do. Dont always consult with

senior manager and customers on problems you can solve
188
D I S T R I B U T E
I N F O R M A T I O N
Chapter
27
Distribute Information
Distribute Information is part of the Execution Process Group
Communications Management Knowledge Area
and the Project
Distributing Information is a process that deals with getting the required information
to your stakeholders in a regular and timely manner. The Communications
Management Plan (which is now part of the Project Management Plan) you
developed in the Planning processes states the information you planned to make
available to your stakeholder. As the project progresses you will need to execute the
activities stated in the communications management plan.
Information you need to distribute relates to the project performance. It should not
just include current information such as percentage of project deliverables complete till
date but also include forecasts such as Estimates to Complete and Budget at
Completion. Inputs you need to get this information are available from the
Performance Reports.
are also inputs to this process. These include templates

required to prepare status reports, lessons learnt on distribution of information from
previous projects etc.
Distribute Information Tools & Techniques

While planning communications for your project you identified the methods you
would be using to distribute the information. We discussed different communication
methods Push Communication, Pull Communication and Interactive
Communication - in the Plan Communications process. You would have to use one of
these communication methods to distribute information to your stakeholders. There
are different ways of getting your message across to your stakeholders. FIGURE 49
shows examples of a few methods of formal-informal & verbal-written
communications.
189
D I S T R I B U T E
FIGURE 49: Communication Methods
You can distribute the information to your stakeholders using variety of distribution
formats (referred to in PMBOK as Distribution Tools) such as hard-copy, softcopy/electronic format etc.
Distribute Information - Outputs

While executing the project you and your team would have acquired more knowledge
both of processes as well as in the product/domain. It is important that you and your
team members update the organizations process repository. This could be in form
of notifications you may have sent to your customers as well as their response, if any.
The submissions to the repository could also be in form of project reports and
presentations and any other documents that could be of value to future project
managers.
190
D I S T R I B U T E
Practice Questions
191
D I S T R I B U T E

Question
Answer
Justification
1
2
3
4
192
M A N A G E
S T A K H O L D E R
E X P E C T A T I O N S
Chapter
28
Manage Stakeholder Expectations
Manage Stakeholder Expectations is part of the Execution Process Group
Project Communications Management Knowledge Area
and the
Manage Stakeholder Expectation process is concerned about working with

stakeholders to understand and meet their needs and addressing their issues as and
when they occur. This process heavily relies on communication activities as well as the
interpersonal skills of the project manager. This process requires the project manager
to:
help increase the probability of acceptance of the project deliverables by the

requesting organization
anticipate concerns that could become issues, and addressing those well in time
You as the project manager would be overall responsible for managing stakeholder
expectations. Inputs to this process are:
Stakeholder Register
Stakeholder Management Strategy
Issues Log
Change Log
Each of these inputs has been discussed earlier in this book.
193
M A N A G E
S T A K E H O L D E R
Manage Stakeholder Expectations Tools &

Techniques
As discussed earlier this process heavily relies on the communication as well as the
interpersonal skills of the project manager. Interpersonal skills include:
This is a communication technique in which you listen and make
notes on whatever the speaker is talking about, and then providing feedback or
responding to the speaker.
Active listening:
Standard techniques are available that could help you resolve

conflicts with stakeholders. Best amongst the techniques is confronting or
collaborating with stakeholders to resolve outstanding issues.
Resolving conflicts
This is the most difficult part. People that are

emotionally involved in any work would not want to change. The best method is to
communicate why the current processes need to change and getting those people
themselves involved in the change process.
Overcoming resistance to change
You would also need to use her General Management Skills in order to manage the
stakeholders expectations. This includes:
Negotiations
Presentation Skills
Public Speaking skills
Communications Methods
push, pull and interactive are also used to manage
stakeholder expectations.
Manage Stakeholder Expectations Outputs

As you interact with your stakeholders and implement the communications plan and
strategy you may discover new methods of managing stakeholder expectations. You
would need to update the stakeholder strategy document with this new
information. The communication management plan, which is part of the project
management plan, would also need to be updated.
Organization process updates (update the lessons learnt from managing
expectations) and Change request are other outputs of this process.
194
stakeholder
M A N A G E
S T A K H O L D E R

1.
What are communication blockers?

Projects involve people from several nationalities and cultures. During
conversations, project managers and team members often (unknowingly)
use statements (slangs) that can cause miscommunication between team
members. These can hamper effective communication and are referred to
as blockers. Conflicts are the most common cause of communication
blockers.
2.
What project documents are updated as part of this process?

Some of the project documents that may be updated are:
Stakeholder strategy document you may discover new methods of

managing expectations of stakeholders
Stakeholder register new stakeholders may join and some may leave.
Issues Log Issues may get resolved, new issues may be raised.
Practice Questions

Question
Answer
Justification
1
195
M A N A G E
S T A K E H O L D E R
2
3
196
P E R F O R M
Q U A L I T Y
A S S U R A N C E
Chapter
29
Perform Quality Assurance
Perform Quality Assurance is part of the Execution Process Group
Quality Management Knowledge Area.
and the Project
In the Plan Quality chapter you saw how you can use quality tools and techniques to
identify and set standards for your project. In the Perform Quality Assurance process
you and your team would be executing the planned activities in order to meet the set
standards. The Perform Quality Assurance process is concerned about improving your
project processes. You would not only be applying the tools and techniques you
defined in your quality plan but also be auditing your project processes and see if your
project has been implementing the defined standards. Inputs you need for this process
are:
Work Performance Information
Quality Metrics These are product and project attributes
Quality Control Measurements
You documented the standards and stated how

your project would implement these standards
As you project progresses you are your
team will collect data that includes such as status of project deliverables,
schedule performance, cost performance and any other data that is useful for
the project.
These are results of quality control activities

such as testing and reviews. Example of measurements could be 15 defects
found in the requirement review, 5 in the design review etc.
Perform Quality Assurance Tool and Techniques

are independent reviews performed by people outside your project. They could
be internal to the performing organization or external. The purpose of the audit is to:
Audits
Measure the degree of compliance or non-compliance to the defined processes
197
P E R F O R M
Q U A L I T Y
A S S U R A N C E
Identify best practices in your project and hare them across the performing
organization
Provide feedback to the managers of the organizations process assets
Audits are usually planned and scheduled activities and are important in assuring quality
of project outcome.
The quality management plan for your project contains not just what standards your
project would follow but also how you and your team would improve the project
processes. This is documented as part of the process improvement plan. Process
Analysis is a Quality Assurance tool that you would use to help improve your current
process.
In addition to audits and Process Analysis, all the quality planning tools and techniques
(and quality control tools & techniques that you would visit in the next section of this
book) would be used in this process.
Perform Quality Assurance Outputs

An outcome of an audit may be that the current defined processes are unable to help
you meet the quality standards. Or, your team members would have found an easier
method of implementing a standard. This will require you to provide feedback to your
organizations process manager usually in form of a Change Request - and may
result in updating the organization process assets.
Project Management Plan and Other project documents would also need to be
updated as part of this process.

1.
QA managers in my organization use the word Kaizen. What does this

mean?
Kaizen is a Japanese word and it means Improvement. The Kaizen
philosophy is to make small improvements and study its impact on the
product.
2.
Is Audit an Assurance Tool or a Quality Control Tool?

Audits are systematic examination of the quality system. The focus is not
just to find if the project is adhering to defined standards but to find out
how effective the organizations quality system is, and if it is not how the
organization goes about improving it and making it more effective. In this
sense it is an assurance tool.
198
P E R F O R M
Q U A L I T Y
A S S U R A N C E
Practice Questions
1.
A tool used to study the effectiveness of the organizations quality system

is:
a) Inspection
b) Audit
c) Review
d) Control
2.
All are outputs of the Perform Quality Assurance process EXCEPT:

a) Updates to Schedule Management Plan
b) Updates to Cost Management Plan
c) Updates to Organization Process Assets
d) Updates to HR database on the new skills acquired by team members
3.
An objective of a quality audit is:

a) To design and determine process variables that gives the best output.
b) To review changes to projects requirements
c) To inspect the project deliverables and accept those that meet the
requirements
d) To identify best practices implemented in a project
199
P E R F O R M
Q U A L I T Y
A S S U R A N C E

Question
Answer
Justification
Audit is a tool used to study the effectiveness of the QMS
Updating HR database in not part of QA process this is

more applicable to project closure or when a team member
leave the team.
This is just one of the objectives. This is the best answer.
200
C O N D U C T
P R O C U R E M E N T S
Chapter
29
Conduct Procurements
Conduct Procurements is part of the Execution Process Group
Procurements Management Knowledge Area.
and the Project
Conduct procurements is the process of obtaining responses from prospective sellers,

evaluating the seller proposals, selecting one or more sellers and awarding the contract.
You can use this process to conduct several rounds of evaluations till you find the
suitable seller and award the contract.
Inputs to this project include:
Procurements Documents
Source Selection Criteria
Qualified Seller List
Seller Proposals
Project Documents
Make-Buy Decisions
Teaming agreements
Organization process assets
These inputs have been discussed in the earlier chapters. Qualified seller list is a list of
sellers you may have shortlisted after the first round of evaluation. You may need more
evaluations to determine the final seller.
Once the procurements documents are released to the prospective sellers they may
review those documents. Some of the prospective sellers may have a few questions to
ask and may direct those questions to you. The best option is to ask all prospective
vendors to attend a bidder conference where you and your team can address any
201
C O N D U C T
questions the vendors may have. This is called a bidder conference and helps a great
deal in ensuring all vendors understand the requirements completely before they bid.
Your organization may have defined procurement policies that need to be followed in
awarding contracts. As a project manager you may be able to shortlist 3 tops vendors
for the award while the award itself may be made by a committee comprising of senior
managers. It is important you consider such procurement evaluation techniques and
policies.
As a requesting organization you may get an independent estimate for the proposed
work done by consultants. These estimates serve as a benchmark for you while
evaluating the proposals from prospective sellers.
Other tools and techniques for conducting procurements are:
Advertising:
Government rules may require placing advertisements for procurements

items beyond a particular value. This can also help you expand the list of preferred
suppliers.
Internet Search: If items to be procured are available off-the-shelf, you may search the
internet for vendors offering this product or service.

Expert Judgment: Can be used in evaluating seller responses.
is a key skill in procuring items for your project or organization. This skill
can help you decide on all terms and conditions that need to be put into the contract.
This culminates in a contract being prepared and signed.
Negotiation
Conduct Procurements Outputs

Outputs of this process are:
Selected Sellers:
As part of this one or more sellers is selected and a contract is

awarded to them. Complex project may require your senior management to approve
the award of contract.
The contract awarded to the selected seller(s) can be in
form of a purchase order if it is a standard procurement. Complex procurements will
need to include items such as a brief statement of work, schedule baseline, reporting
criteria, roles and responsibilities of buyer and seller as well as the pricing details and
payment terms. Post project support, warranty etc. may also be part of the contract.
Procurement Contract Award:
Resource Calendars, Change Requests, Project Management Plan Updates

Project Document Updates are other outputs.
202
and
C O N D U C T
203
Monitoring & Controlling Processes
LEARNING OBJECTIVES
205
M O N I N O R I N G
&
C O N T R O L L I N G
P R O C E S S E S
Chapter
29
Monitoring & Controlling
In this chapter we will review all the Monitoring & Controlling Group processes.
Monitoring and Controlling Process Group consists of the following processes. The
primary objective of these processes is to track the progress of the project, identify
changes to the plan and initiate those changes.
Monitoring and Controlling Project Work (Integration Management

Knowledge Area)
Perform Integrated Change Control (Integration Management Knowledge

Area)
Report Performance (Communications Management Knowledge Area)
Control Scope (Scope Management Knowledge Area)
Control Schedule (Time Management Knowledge Area)
Control Costs (Cost Management Knowledge Area)
Control Quality (Quality Management Knowledge Area)
Verify Scope (Scope Management Knowledge Area)
Monitor & control risks (Risk Management Knowledge Area)
Administer Procurements (Procurements Management Knowledge Area)
Monitor & Control Project Work

Monitoring and Controlling Project Work process involves tracking the progress of the
project, reviewing the status of the project at regular intervals and, if the project is
lagging behind, taking corrective actions to put it back on track. Inputs to this process
are the Project Management Plan, Performance Reports, Enterprise Environment
206
M O N I T O R I N G
&
P R O C E S S E S
and Organization Process Assets. Each of these inputs has been discussed
earlier in this book.
Factors
As a Project Manager you need to interpret and apply your Expert Judgment to the
information provided by this process and must determine the actions in order to bring
the project work back on track should there be a need.
The outputs of this process are:
These are the outcome of comparing the plan against the actual
performance. These could be corrective actions meant to bring project performance on
track or Preventive actions meant to reduce the probability of negative consequences.
It could also be due to need for repairing defects.
Change Requests
Approved changes may have an impact to the Project Schedule, Project Costs/Budget
or the Project Scope. The project baselines and the Project Management Plan will need
to be reviewed and updated should there be a change. Other project documents such
as issues log and performance reports may need to be updated.
Perform Integrated Change Control

Changes are inevitable on any project. As discussed earlier Change Request is an
outcome of comparing the actual performance of the project with the plan. Changes
can lead to 3 types of responses in situations detailed as below:
Reactive response
Uncontrolled response
Controlled and Proactive response
- if the change is handled without any planning then this

would result in issues needing workarounds and fixes.
- Alternatively, if the change is handled without any
control it will lead to scope creep and chaos.
if the changes are evaluated, analyzed
and smoothly accepted, rejected or delayed, then it is termed as change
management
The last mentioned is desirable on any project i.e., the response to every change request
must be managed and controlled. The process that helps you manage and control
changes to your project is Perform Integrated Change Control.
Changes can be requested by any of the stakeholders; however it is important that all
change requests are documented, reviewed, analyzed, approved (by the CCB) and then
implemented. Inputs to this process are the Project Management Plan, Work
Performance Information, Change Requests, Enterprise Environment Factors and
Organization Process Assets. Each of these inputs has been discussed earlier in this
book.
207
M O N I N O R I N G
&
P R O C E S S E S
and Change Control Meetings are tools and techniques to this

process. All change requests raised on the project must be discussed by the members
of the change control board that meets regularly. Discussions primarily revolve over
the necessity of the change, the impact of the change in terms of additional costs and
time etc. are discussed and decisions made collectively.
Expert Judgment
Changes may be Accepted or Rejected. It is important that only those that have been
reviewed and approved by the CCB be implemented. When a decision is made to
implement a change request you must update the status of the Change Request in
the CR log. Project Plan and other project documents may also need to be updated
to keep it in synch with approved changes.
The remaining processes in the Monitoring and Controlling process group can be
categorized into the following:
Processes that require collecting data, creating reports and distributing it to

stakeholders (Report Performance)
Processes that require you to manage changes to the performance baselines

(Control Scope, Control Schedule, Control Costs)
Process that require you to XXXXX
We discuss these processes in some detail.
Report Performance
One of your responsibility as a Project Manager is to communicate the status of the
project to stakeholders. This involves the following actions:
Collect information about the project
Analyze the information and use it to forecast
Distribute it to stakeholders so that they can make informed decisions quickly
Each type of Stakeholder requires different levels of information. The Project

Management Plan states the type of information by each of the stakeholders. It also
states the format and the detail required and is therefore the key input to this process.
The Work Performance Information, also one of the inputs to this process, tells you
the status of your project deliverables. Using this information you can determine what
the project team has accomplished and what remains to be accomplished. Stakeholders
can also use this to make decisions. Econometric Methods and Time Series Methods
(Earned Value Management) can help you forecast the project budget and the
estimate at completion.
208
M O N I T O R I N G
&
P R O C E S S E S
can help you measure the project performance

against planned performance. This also forms the basis to stakeholders to make
informed decisions.
Work Performance Measurements
is one of the most popular tools to help compare planned

performance against actuals. Forecasting methods such as Econometric models and
Time Series methods, as well as Communications Methods are other tools of this
process.
Variance Analysis
summarizes the results of project performance compared to the

project baseline. Typically, a project performance report would contain information on
the milestones achieved during the reporting period, milestones missed and why we
these milestones were missed, outstanding issues, status of project deliverables, status
on risks and forecasts of time/schedule and costs. These reports are distributed
regularly to stakeholders using communication methods that were determined in
Communications Planning process.
Performance Reports
Analysis of project performance and comparison against plan can require the project
manager make changes to the plan. These will result in the project manager raising new
change requests that will need to be taken to the Change Control Board for approval
and if approved, executing these changes through the Integrated Change Control
process.
Controlling Scope, Schedule, and Costs

These processes are meant to help you monitor the status of your project and manage
changes to the baselines. These processes involve the following steps:
Determining the status of the project in terms of Scope, Schedule and Costs as
the case may be
Influencing the factors that create changes to the Scope, Schedule and Cost as
the case may be
Ensuring that all change requests that impact the project are reviewed and only
those that are approved are implemented.
Managing the changes to the Scope, Schedule and Cost as the case may be
The inputs, tools and outputs for these processes are as shown in FIGURE 50.
209
M O N I N O R I N G
&
P R O C E S S E S
FIGURE 50: Summary - Scope, Time and Cost Control
The Project Management Plan is a common input to all the 3 processes. This
document contains the Scope baseline, Schedule baseline, Cost Performance baseline
and hence all the 3 processes use this as a basis for measurement, comparison, reports,
and decisions. The Work Performance Information and Organization Process Assets
are other common inputs. In this section we will discuss only specific tools; most of
the other common tools have been discussed elsewhere in this book. Specifically, if
there is a change to:
-you would have to review the requirements document and the
requirements traceability matrix
Requirements
you would need to review the current schedule baseline and see how the
change impacts the schedule. Change to schedule usually would require addition of
new tasks and re-arranging current tasks and resource assignments. There is a
possibility that resources may get over allocated while re-planning. You can use
scheduling tool (such as MS Project or Clarity) to level resource allocation. The
scheduling tool can also help you perform simulation or what-if analysis.
Schedule
Changes to schedule will most likely cause the end-date of your project to shift. Your
objective must be to see that the dates are not very different from the originally
planned. Schedule compression techniques (such as fast-tracking such as
210
M O N I T O R I N G
&
P R O C E S S E S
manipulating the lads and lags - or crashing) that you initially used during scheduling
will have to be used to minimize the impact of this change.
You would need to review the funding requirements. Earned Value
Management can be used to not just review and report current performance but can be
used to forecast and predict costs and cost indices such as T-CPI. Please read the
Chapter on Earned Value Management to understand the concept and process of
calculating the cost indices.
Costs
Common outputs of these 3 processes are:
Work Performance Measurements
Change Requests
Project Management Plan Updates
Organization Process Assets Updates, and
Project Document Updates
A specific output of Cost Control is Budget Forecasts. As part of this a new value for
EAC is calculated, documented and communicated to the customer.
Perform Quality Control v/s Verify Scope

Your team would be able to record results of executing quality activities. This is part of
Perform Quality Control process. This process deals with recording results of quality
activities and assessing the performance and recommending change, if any.
Inputs to this process are:
Quality metrics
Work Performance Information
Quality Checklists
Approved Change Requests
Deliverables, and
Quality Control Tools include:

211
M O N I N O R I N G
&
P R O C E S S E S
Pareto Chart:
Also called the 80-20 rule. This involves rearranging a histogram on the
basis of frequency of occurrence. Pareto principle states that relatively a small number
of causes result in majority of problems.
Run Chart:
These charts are similar to the control charts except that the observation
horizon is large and is often used for trend analysis.
Scatter Diagram:
This is a diagram that shows relationships between two variables
under study
Other tools are Flow charting, Ishikawa Diagram, Control Charts, Histograms,
Inspection and Statistical sampling. Each of these has been discussed in the earlier
chapters.
Outputs of the Perform Quality Control process are:
Quality Control Measurements, Organization Process Assets Updates, Project
Management Plan updates and other project Document Updates.
On completion of a quality control activity, deliverable are inspected by the internal

team and are passed (Accepted) or failed (Rejected) for release to customer for
acceptance testing. Other outputs of this process are Validated Changes and
Validated Deliverables. In situations where a deliverables is not passed for release it is
sent back to the development team for correction. This may require raising a change
request and is therefore yet another output of the Perform Quality Control process.
is part of the Scope Management Knowledge Area. This process
involves finalizing and accepting the deliverables of the project. This process involves
reviewing the project deliverables with the customer and obtaining a sign-off from the
customer for the work performed.
Verify Scope
The Project Management Plan, the Requirements Document and the Requirements
Traceability Matrix are key inputs to this process. Yet another input is the validated
deliverables. Validated deliverables are outputs of Quality Control process.
Physical inspection is the tool used to verify the deliverables. If the deliverables are
found to be acceptable the customer you must obtain a sign-off on the accepted
deliverables from the customer. There is a possibility that the customer may find some
gaps between the requirements and functions actually implemented. These identified
gaps are documented and change requests are raised that need to be put through the
Integrated Change Control process. Project Documents would also need to be updated
Monitor and Control Risks
212
M O N I T O R I N G
213
&
P R O C E S S E S
Closing Processes
LEARNING OBJECTIVES
215
C L O S I N G
P R O C E S S E S
216

Course Workbook

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Course Workbook

Caricato da

Copyright:

Formati disponibili

Volume

PMP Preparation Course

2010 Promantia Global Consulting LLP

PLANNING PROCESSES ......................................................................................................... 35

ESTIMATE ACTIVITY DURATION ............................................................................................ 71

Suggested ways to use the Risk Matrix ..............................................................................115

ANSWERS TO PRACTICE QUESTIONS .............................................................................................. 155

DISTRIBUTE INFORMATION - OUTPUTS ...........................................................................................190

FIGURE 46: WORK PERFORMANCE INFORMATION ..................................................................170

Organization of the student guide

Developing the transmission system for a new electric vehicle

Acquiring a new MIS system for your company

Effecting a change in the organization structure of your company

Constructing a monument, building or a facility

Running an enhanced marketing campaign for a product

Implementing a new business process in your organization

Projects always have an end date. In contrast,

are repetitive and ongoing;

FIGURE 1: Relation between Project, Program and Portfolio

Role of a Project Manager

as well as skills to apply project management practices, tools and

communication skills, interpersonal skills, negotiation, conflict resolution,

It is not sufficient if the project manager have skills in project

Begin with the end in mind - Stephen Covey.

FIGURE 2: Functional Organization

bringing together the good attributes of functional and projectized organization

FIGURE 4: Weak Matrix

A project manager in a weak matrix is primarily responsible for communications and

FIGURE 5: Strong Matrix

Project managers in balanced matrix organizations share responsibilities with their

Initiating process group

Planning process group

Executing process group

Monitoring & controlling process group, and

Closing process group

Project Life Cycle

This is a repository of data and information of past

Enterprise Environment Factors

Regulatory Requirement or Government Standards: E.g. the ISI standards for

Organization Structure We saw how an organizations structure influences

Commercial Databases: These include commercially availability data and

Project Management Software Availability of tools for scheduling,

Knowledge Areas in PMBOK Guide

Project Integration Management

Project Scope Management

Project Time Management

Project Cost Management

Project Quality Management

Project Human Resources Management

Project Communications Management

Project Risk Management, and

Project Procurement Management

FIGURE 10: Process Groups defined in PMBOK

Frequently Asked Questions

Projects result in a unique outcome (result or service or product) while

4. How is a project coordinator different from an expediter?

Which of the following is a common characteristic of most project lifecycle descriptions?

All of the following are characteristics of a project EXCEPT:

c) Fixing a bug in a software program

Acquiring team is part of which process group?

You have taken up a full-time role in a newly formed projectized

Answers to Practice Questions

Repetitive is a characteristics of operations

All other options are operations