Project Management Professional (PMP)

Project Management Professional (PMP)

Copyright © 2006 by PrepLogic, Inc.
Product ID: 010432
Production Date: June 7, 2006

All rights reserved. No part of this document shall be stored in a retrieval system
or transmitted by any means, electronic, mechanical, photocopying, recording, or
otherwise, without written permission from the publisher. No patent liability is
assumed with respect to the use of the information contained herein.
Warning and Disclaimer
Every effort has been made to make this document as complete and as accurate as
possible, but no warranty or fitness is implied. The publisher and authors assume
no responsibility for errors or omissions. The information provided is on an "as
is" basis. The authors and the publisher shall have neither liability nor
responsibility to any person or entity with respect to any loss or damages arising
from the information contained in this document.
Volume, Corporate, and Educational Sales
PrepLogic offers favorable discounts on all products when ordered in quantity.
For more information, please contact PrepLogic directly:
1-800-418-6789
[email protected]
 Project Management Professional (PMP)

The PMP will test your knowledge of these under one of the six following project domains:

1. Initiating the Project [11% of scored questions]

i. Conduct Project Selection Methods
ii. Define Scope
iii. Document Project Risks, Assumptions, and Constraints
iv. Identify and Perform Stakeholder Analysis
v. Develop Project Charter
vi. Obtain Project Charter Approval

2. Planning the Project [23%]

i. Define and Record Requirements, Assumptions, and Constraints
ii. Identify Project Team and Define Roles and Responsibilities
iii. Create the WBS
iv. Develop Change Management Plan
v. Identify Risks and Define Risk Strategies
vi. Obtain Plan Approval
vii. Conduct Kick-off Meeting

3. Executing the Project [27%]

i. Execute Tasks Defined in Project Plan
ii. Ensure Common Understanding and Set Expectations
iii. Implement the Procurement of Project Resources
iv. Manage Resource Allocation
v. Implement Quality Management Plan
vi. Implement Approved Changes
vii. Implement Approved Actions and Workarounds
viii. Improve Team Performance
 Project Management Professional (PMP)

4. Monitoring and Controlling the Project [21%]

i. Measure Project Performance
ii. Verify and Manage Changes to the Project
iii. Ensure Project Deliverables Conform to Quality Standards
iv. Monitor all Risks

5. Closing the Project [9%]

i. Obtain Final Acceptance for the Project
ii. Obtain Financial, Legal, and Administrative Closure
iii. Release Project Resources
iv. Identify, Document, and Communicate Lessons Learned
v. Create and Distribute Final Project Report
vi. Archive and Retain Project Records
vii. Measure Customer Satisfaction

6. Professional and Social Responsibility [9%]

i. Ensure Individual Integrity
ii. Contribute to the Project Management Knowledge Base
iii. Enhance Personal Professional Competence
iv. Promote Interaction among Stakeholders

PMBOK Overview
Information is presented in the PMBOK according to a logical scheme. The scheme presents the 44 Project
Management Processes (or activities) under one of five Project Management Process Groups (which are sometimes
referred to as project phases, though this is not strictly correct).
The five process domains are:
Initiating – comprising 2 processes
Planning – 21 processes
Executing – 7 processes
Monitoring & Controlling – 12 processes
Closing – 2 processes
 Project Management Professional (PMP)

The scheme also presents the 44 processes found under one of the nine Knowledge Areas to which they belong.
These are:
Project Integration Management – comprising 7 processes
Project Scope Management – 5 processes
Project Time Management – 6 processes
Project Cost Management – 3 processes
Project Quality Management – 3 processes
Project HR Management – 4 process groups
Project Communications Management – 4 processes
Project Risk Management – 6 processes
Project Procurement Management – 6 processes

Make a copy of this table. Use it as a guide to the content of each Process Group and Knowledge Area and the ways
in which these interact. Familiarize yourself thoroughly with its content.

It is recommended that you read the PMBOK twice. The first time, you should read the PMBOK in strict chapter
sequence as the book is written (i.e. in linear sequence from cover to cover). This will enable you to understand and
familiarize yourself with the processes as they relate to the Knowledge Area to which they belong. This is represented
by the vertical axis in Table 3-45. For example, under Project Quality Management, read sections 8.1, then 8.2, then
8.3. This is the sequence in which this study guide covers the PMBOK content. Note that this study guide also follows
the same chapter and sub-section numbering as PMBOK for quick and easy reference. The second time (as a prep
for the exam), you should read the PMBOK in Process Group sequence (i.e. in the order in which processes are
performed within the Process Group, represented by the horizontal axis in Table 3-45). For example, under Monitoring
& Controlling read and review sections 4.5 and 4.6, followed by 5.4 and 5.5, and then 6.6, 7.3, etc.
 Project Management Professional (PMP)

Table of Contents
PMBOK Overview ............................................................................................................................................................ 3
1. Introduction: the Project Management Framework ........................................................................................................ 7
2. Project Life Cycle and Organization ............................................................................................................................... 7
3. Project Management Processes ....................................................................................................................................... 7
4. Project Integration Management .................................................................................................................................... 8
4.1 Develop Project Charter.............................................................................................................................................. 8
4.2 Develop Preliminary Project Scope Statement ............................................................................................................. 10
4.3 Develop Project Management Plan............................................................................................................................. 10
4.4 Direct and Manage Project Execution ........................................................................................................................ 11
4.5 Monitor and Control Project Work ............................................................................................................................. 11
4.6 Integrated Change Control ........................................................................................................................................ 11
4.7 Close Project ............................................................................................................................................................ 12
5. Project Scope Management........................................................................................................................................... 13
5.1 Scope Planning ......................................................................................................................................................... 13
5.1 Scope Planning ......................................................................................................................................................... 14
5.2 Scope Definition........................................................................................................................................................ 14
5.3 Create WBS .............................................................................................................................................................. 14
5.4 Scope Verification ..................................................................................................................................................... 15
5.5 Scope Control ........................................................................................................................................................... 15
6. Project Time Management............................................................................................................................................ 15
6.1 Activity Definition ..................................................................................................................................................... 16
6.2 Activity Sequencing ................................................................................................................................................... 17
6.3 Activity Resource Estimating...................................................................................................................................... 18
6.4 Activity Duration Estimating ...................................................................................................................................... 19
6.5 Schedule Development............................................................................................................................................... 19
6.6 Schedule Control....................................................................................................................................................... 21
7. Project Cost Management............................................................................................................................................. 22
7.1 Cost Estimating......................................................................................................................................................... 23
7.2 Cost Budgeting ......................................................................................................................................................... 24
7.3 Cost Control ............................................................................................................................................................. 24
8. Project Quality Management ........................................................................................................................................ 27
8.1 Quality Planning....................................................................................................................................................... 28
8.2 Perform Quality Assurance ........................................................................................................................................ 28
8.3 Perform Quality Control............................................................................................................................................ 29
9. Project Human Resource Management ......................................................................................................................... 31
9.1 Human Resource Planning......................................................................................................................................... 31
9.2 Acquire Project Team................................................................................................................................................ 35
 Project Management Professional (PMP)

9.3 Develop Project Team ............................................................................................................................................... 35

9.4 Manage Project Team ............................................................................................................................................... 36
10. Project Communications Management........................................................................................................................ 38
10.1 Communications Planning ....................................................................................................................................... 38
10.2 Information Distribution .......................................................................................................................................... 39
10.3 Performance Reporting............................................................................................................................................ 39
10.4 Manage Stakeholders .............................................................................................................................................. 39
11. Project Risk Management ........................................................................................................................................... 40
11.1 Risk Management Planning...................................................................................................................................... 40
11.2 Risk Identification ................................................................................................................................................... 41
11.3 Qualitative Risk Analysis ......................................................................................................................................... 42
11.4 Quantitative Risk Analysis........................................................................................................................................ 43
11.5 Risk Response Planning ........................................................................................................................................... 44
11.6 Risk Monitoring and Control.................................................................................................................................... 45
12. Project Procurement Management.............................................................................................................................. 46
12.1 Plan Purchases and Acquisitions .............................................................................................................................. 46
12.2 Plan Contracting..................................................................................................................................................... 48
12.3 Request Seller Responses ......................................................................................................................................... 49
12.4 Select Sellers........................................................................................................................................................... 49
12.5 Contract Administration .......................................................................................................................................... 51
12.6 Contract Closure..................................................................................................................................................... 51
Professional and Social Responsibility .............................................................................................................................. 52
 Project Management Professional (PMP)

1. Introduction: the Project Management Framework

The PMP exam questions focus primarily on the knowledge covered by the nine Project Management Knowledge
areas (Chapters 3 thru 12). However, there is an implicit assumption in the exam of general project management
concepts that provides the foundation for understanding the purpose, application, and relationships between the
processes described in the nine knowledge areas. These general concepts are covered in Chapter 1 of the PMBOK
(pages 3-18). You should familiarize yourself with the following concepts:
A project is “a temporary endeavor undertaken to create a unique product, service, or result,” (page 5) in which
temporary means a finite (fixed) duration and unique denotes a set of circumstances (the project) that,
although resembling similar circumstances in many aspects, have not been previously encountered before.
A project proceeds through the process of progressive elaboration.
A project is distinguished from the operational activities of a company by the fact that it is both temporary and
unique. Operational activities are ongoing and repetitive (pages 6-7).

2. Project Life Cycle and Organization

Organizational factors influence how projects are performed and the outcomes of projects. Although projects are
temporary and unique, they are defined by a common life cycle whose general characteristics can be discerned in all
projects. These life cycle characteristics are described in Chapter 2 (pages 19-33). You should familiarize yourself
with the following life cycle concepts:
A project life cycle defines the phases through which the project progresses from beginning to end. Different
application areas have different life cycle models.
A product life cycle describes the phases through which a product progresses from inception (idea) to end-of-
life (obsolescence) (pages 22-23).
The project life cycle will intersect with the product life cycle at various points in the ongoing life of a product
Stakeholders are many and various. Their wants, needs, and desires shape project requirements and
influence project performance.
The culture and structure of a performing organization influences (constrains) the ways in which work on a
project can be performed.

3. Project Management Processes

Project management comprises a set of processes that are commonly used to perform project activities. These
processes can be grouped by the general function that they perform within the project life cycle. These groups are not
the same as project phases, although their nomenclature can often mislead one in making that assumption. The
general characteristics of these processes and their representation within the PMBOK are described in Chapter 3
(pages 37-70). You should familiarize yourself with the following:
The PMBOK Guide is a standard that describes the application of project management processes to project
activities that “have been recognized as good practice on most projects most of the time” (page 37). Good
practice, in this context, “enhances the chance of success.”
The PMBOK Guide is not an exhaustive standard. Processes may overlap and interact in ways not described
(page 37).
Project management processes that are iterated throughout the project generally conform to the “Plan-Do-
Check-Act” model of interaction (page 39).
 Project Management Professional (PMP)

There are five process groups to which all project management processes can be mapped. These are:
Initiating, Planning, Executing, Monitoring & Control, and Closing (page 40-67).

4. Project Integration Management

The PMBOK describes Project Integration Management as the “processes required to ensure that the various
elements of the project are properly coordinated. It involves making trade-offs among competing objectives and
alternatives to meet or exceed stakeholder needs and expectations.” Successful PMP candidates will need an arsenal
of experience to draw from in answering questions related to Project Integration Management, but equally as important
is a solid understanding of PMI’s view of critical processes, such as creating a project charter or managing change
control on a project.
The primary characteristic of a project is that it is an integrative endeavor. All of the elements of a project must be
successfully integrated for the project to succeed. Integration is necessary in order to combine, coordinate and control
project elements as they interact with one another in order to deliver project results. But no project proceeds to
completion without change. Integration management enables changes to be made to the project by actively managing
the trade-off between competing objectives and alternative options without impairing achievement of the project goals.
Integration is necessary to ensure that customer and other stakeholder requirements are met and satisfied so as to
manage stakeholder expectations.

4.1 Develop Project Charter

[Page 82, Figure 4-3. Develop Project Charter: Input, Tools & Techniques, and Output]

The Project Charter is a key concept or process because it initiates the start of a project. Project managers should
understand that the Project Charter is independent of deliverables, such as needs assessments or feasibility studies
that might be required before a project is approved. PMP candidates should also be aware that PMI’s definition of a
project charter may differ from what many project managers consider to be or not to be a project charter.

Many projects run into trouble in later phases for want of a charter. Why is a charter so important? A charter ensures
that the project will address needs and requirements in a way that is consistent with ongoing business operations and
is aligned with the performing organization’s strategic plans.
A charter is important because it:
formally authorizes the existence of the project;
signifies that the project has an active sponsor (or initiator) who is responsible for issuing the charter;
formally identifies the project manager to the performing organization; and
gives the project manager formal authority to apply organizational resources to project activities.

Whatever its source, before chartering a project the management of the performing organization must evaluate the
impact of the change on its business environment and then formulate a response appropriate to that change. If there
is more than one possible response, the performing organization will need to screen the alternatives in order to select
the best response (the project to be chartered).
 Project Management Professional (PMP)

Screening criteria fall into one of two categories:

Benefits measurement – which uses scoring models, comparative approaches, benefit contribution, and
economic models to compare project alternatives; and
Mathematical – which uses various mathematical algorithms (linear, non-linear, dynamic, integer, multi-
objective programming algorithms, etc.) to evaluate alternative projects.

Benefits measurements use scoring methods and economic analysis to focus on the cost and revenue aspects (and
hence, profitability) of the proposed responses. They answer the question: “What will this project return on our
investment?” The charter documents any business needs identified during this process as well as the needs, wants
and expectations (requirements) of the proposed project’s stakeholders. The results of benefits measurements also
provide insight into how the project will be funded (see page 170), as one of the functions of the charter is to authorize
initial funding of the project.
Definition: Statement of Work (or SOW) – A narrative description of products, services, or results to be supplied by
the project.
The SOW is important because it:
identifies the business needs that will be met by the project;
documents the product requirements and characteristics of the product or service that the project will
deliver; and
demonstrates how the product or service supports the performing organization’s strategic plan.

Definition: Enterprise Environmental Factors – Any or all external environmental factors and internal organizational
factors that surround or influence the project’s success.
Definition: Organizational Process Assets – Any or all process-related assets, from any or all of the organizations
involved in the project that are or can be used to influence the project’s success.
These assets include such artifacts as formal and informal plans, policies, procedures, guidelines, standards,
templates, etc., covering all aspects of project planning, execution, control and closure. Also included in these are
Lessons learned and Historical information, maintained in the performing organization’s knowledge base.
When selecting a project, having the capability to succeed is a key criterion. In many respects, organizational process
assets represent the performing organization’s capability. This is why, for example, you must always review and
approve all change requests affecting organizational process assets because they directly influence project
performance. The extent to which organization process assets influence project outcomes can be judged by the
number of times they occur as Inputs (25) and as Outputs (12).
One of the key tools used to create the charter is the Project Management Information System [page 86]. A PMIS is
defined by PMBOK as a standardized set of automated tools and techniques that are used by the project team to
gather, integrate and disseminate the outputs of project management processes. It is an important tool for integrating
project management processes and is used in all of the major process areas to:
Create the Project Management Plan (page 90);
Direct and Manage Project Execution (page 93);
Monitor and Control the project (page 95);
Facilitate Integrated Change Control (page 99); and
Close the project (page 101).
 Project Management Professional (PMP)

Another important tool that is used to create the charter is Expert Judgment, where expertise in a specific knowledge
domain, application area or specialist discipline is applied to a project process, problem or issue. This is provided by a
group or an individual with the requisite knowledge, skills and experience to render an informed evaluation and
assessment (judgment). Expert judgment represents applied capability. Like the PMIS, Expert Judgment is used
across many process areas to:
Develop the Project Charter (page 85);
Develop the Preliminary Project Scope Statement (page 87);
Develop the Project Management Plan (page 90);
Monitor and Control the project (page 96);
Perform Integrated Change Control (page 99); and
Close the project (page 101).

4.2 Develop Preliminary Project Scope Statement

[Page 87, Figure 4-4. Develop Preliminary Project Scope Statement: Inputs, Tools & Techniques, and Output]

The Project Scope Statement, not the Project Charter, defines the project and identifies what it must accomplish. It
documents the project’s characteristics and boundaries and identifies how the project scope will be controlled and the
methods by which the products of the project will be accepted. Among other items, the Scope statement identifies the
product acceptance criteria, project constraints, assumptions, requirements for project configuration management, and
approval requirements. The project initiator, or sponsor, provides the initial input (information) to the preliminary scope
statement. Through progressive elaboration, the project team refines this preliminary statement into the Project Scope
Statement (see page 110).

4.3 Develop Project Management Plan

[Page 89, Figure 4-5. Develop Project Management Plan: Inputs, Tools & Techniques, and Output]

What is referred to as the “project plan” is another term that in the past caused some confusion. The term “project
plan” had become commonly used to describe a GANTT chart, or what PMI refers to as a “project schedule.” PMI
responded by changing the title from the “Develop Project Plan” process to the “Develop Project Management Plan”
process. As the name suggests, the resulting plan output (1) provides structure and a baseline; (2) facilitates
communication amongst groups; and (3) serves as a master plan, or book of record, for all of the project’s subsidiary
plans. By keeping this in mind, PMP candidates will be on their way to a better comprehension of this key process
area and, ultimately, success on the exam.

The project plan is maintained using the Configuration Management System, a sub-system within the PMIS. This sub-
system facilitates the:
Submission of proposed changes;
Tracking, review and approval of proposed changes;
Definition of relevant approval levels authorizing the proposed changes; and
Validation of approved changes.
 Project Management Professional (PMP)

4.4 Direct and Manage Project Execution

[Page 92, Figure 4-6. Direct and Manage Project Execution: Inputs, Tools & Techniques, and Output]

Project execution is primarily concerned with ensuring that the work defined in the project scope statement is
accomplished as described in the plan. The project manager and the project team are responsible for directing the
performance of the planned project activities. As part of the execution process, Work Performance Information about
how activities are being performed and the status of work accomplished (in the form of outputs and deliverables) is
collected, evaluated and reported. This includes both tangible and intangible project deliverables (for example,
delivering a training course is an intangible deliverable of the project). What kinds of information and data are
collected when creating Work Performance Information outputs? (See page 94.)
The evaluation and analysis of actual work performed versus the planned work may indicate the need for any of the
following:

Approved corrective actions – required to bring anticipated project performance back into conformance with the
project plan (affecting Scope, Schedule, Cost, Quality and Risk);
Approved preventive actions – required to reduce the probability of potential negative consequence (affecting
Quality, Risk and Human Resource Management); or
Approved defect repair requests – required to correct product defects found by the quality process (affecting
Quality).

4.5 Monitor and Control Project Work

[Page 95, Figure 4-7. Monitor and Control Project Work: Inputs, Tools & Techniques, and Output]

Monitoring is performed proactively and continuously throughout the project. It involves the collection, evaluation and
dissemination of performance information. This includes measurement and examination of performance trends over
time to determine if project performance is improving or deteriorating (see page 176). If the trend is deteriorating, the
analysis should identify those areas of project execution that require attention by the project management team to
bring the project back into conformance with the plan.

4.6 Integrated Change Control

[Page 98, Figure 4-8. Monitor and Control Project Work: Inputs, Tools & Techniques, and Output]

Changes occur in all projects, and Integrated Change Control occurs throughout the project (from inception to
completion). Because projects must be managed to plan (including any and all subsidiary plans), and projects rarely
run to plan, all change requests must be reviewed, approved (or rejected) and then implemented.

Once changes are approved, plans must be updated to reflect all approved changes. The update to the baseline plan
results in a revised baseline, which is a critical concept for this section and for PMI in general. Think for a moment
about the advantages of baselining projects. The value of cost variances, performance reporting and future duration
estimates would all be diminished without baselining projects. Keep this concept in mind as you review the Integrated
Change Control process group.
 Project Management Professional (PMP)

Other than maintaining the integrity of project baselines, Integrated Change Control is necessary in order to:
identify that a change has occurred or needs to occur;
ensure that only approved changes are implemented by influencing those elements that may circumvent
integrated change control; and
coordinate all approved changes across the project as they affect interdependent, interconnected or
related components of the project.

According to PMBOK (page 97), the Configuration Management System provides the performing organization with:
an evolutionary method to consistently identify and request changes, and to assess the value and
effectiveness of the requested changes;
opportunities to continuously validate and improve project performance by evaluating the impact of each
change requested; and
a mechanism for the project management team to consistently communicate all approved changes to
stakeholders.

Configuration management is comprised of:

Configuration Identification – provides the basis by which product configuration is defined and verified,
products and documents are labeled (i.e. version, series, etc.), changes are managed and accountability is
identified and maintained;
Configuration Status Accounting – assures the capture, storage and retrieval of configuration
management information required to effectively manage both the product and information about the
product; and
Configuration Verification and Auditing – establishes that the performance and functional requirements
defined in the configuration documentation have actually been met as specified.

4.7 Close Project

[Page 100, Figure 4-9. Close Project: Inputs, Tools & Techniques, and Output]

The Close Project process is the final process added to the Integration Management Process Group. Since PMI has
added it to the group, there clearly is value in knowing and understanding the process. For PMI, important concepts
can lurk in the mundane topic of project closure. Keeping in mind the value that PMI places on creating and
maintaining a historical record of project information that can be used for future projects, it should be clear why the
process can be so valuable for good management of projects.

The Close Project process establishes procedures to:

coordinate activities needed to verify and document the project deliverables;
coordinate and interact to formalize acceptance of those deliverables by the customer or sponsor; and
investigate and document the reasons for actions taken if a project is terminated before completion.
 Project Management Professional (PMP)

Early termination of a contract is a special case of contract closure. Note that the agreed contract closure procedure
should always be followed. Early termination may occur due to:
inability to deliver the project’s product;
a budget overrun; or
lack of required resources.

Note that early termination is an input to the Close Contract process.

5. Project Scope Management

As PMI explains in the chapter’s opening, Project Scope Management is the defining and controlling of what is and is
not in the project. In reviewing the components of the Project Scope Management Process Group, candidates will
begin to see two divisions between the processes – those focused on defining the scope and those focused on
controlling the scope. The first three process groups – Scope Planning, Scope Definition, and Create WBS – are
closely related to one another and all deal with the creation and definition of the project’s scope. The last two process
groups – Scope Verification and Scope Control – are also closely related and deal specifically with managing the
inevitable changes that emerge when managing a project.

Definition: Project Scope Management – includes the processes required to ensure that the project includes all the
work required, and only the work required, to complete the project successfully.
Project scope describes the work that needs to be accomplished in order to deliver the product, service or other
outcome, with the features and functions described in the product scope. The features and functions of the product or
service to be delivered are documented in the SOW. Completion of the project scope is measured against the project
management plan, Project Scope Statement and associated WBS and WBS dictionary. Completion of the product
scope is measured against the product requirements. PMP candidates need to be clear on the difference between
product and project scope. Questions on the PMP exam will focus primarily on project scope, but test takers should be
cautious not to confuse the two.
 Project Management Professional (PMP)

5.1 Scope Planning

[Page 107, Figure 5-3. Scope Planning: Inputs, Tools & Techniques, and Output]

Project scope influences the success of the project’s outcome. Most project managers have had some experience of
this in its negative aspect: scope creep.
To prevent this from happening, the project management team must identify and map out the total scope of work that
must be performed to a level of detail that is commensurate with the needs of the project. No more, no less. This
information is captured in the Project Scope Management Plan, which is a subsidiary or contributing plan to the Project
Management Plan. Note that one of the key functions of the project Scope Management Plan is to document scope
management decisions, that is, how the project scope will be defined, developed and verified as well as how the
project management team will manage and control the project scope. When disputes or questions arise over features
and functionality to be delivered by the project, what is defined in the Scope Management Plan will guide the team in
determining how the issue is resolved. To avoid ambiguity and misunderstandings among stakeholders, the Scope
Management Plan should always explicitly reference what is out of scope of the project as well as what is in scope.

5.2 Scope Definition

[Page 109, Figure 5-4. Scope Definition: Inputs, Tools & Techniques, and Output]

The detailed Project Scope Statement is created through progressive elaboration as information is collected from
stakeholders and analyzed by the project team. As we already know, progressive elaboration means that there will be
a succession of iterations to the scope definition. This, by definition, implies that the original scope statement will
change as the project progresses. For this reason, the shrewd PMP candidate will notice that Approved Change
Requests are considered inputs for the Scope Definition Process. Organizational Process Assets, the Project Charter,
the Preliminary Project Scope Statement and the Project Scope Management Plan are the other inputs for the
development of the Scope Definition.

Definition: Assumptions – Factors that, for planning purposes, are considered to be true, real or certain without the
need for proof or demonstration. In the absence of validation or verification, assumptions always imply a degree of
risk.

5.3 Create WBS

[Page 113, Figure 5-5. Create WBS: Inputs, Tools & Techniques, and Output]

Definition: Work Breakdown Structure (WBS) – A deliverable-oriented hierarchical decomposition of the work to be
executed by the project team to accomplish the project objectives and create the required deliverables. It organizes
and defines the total scope of the project.

The WBS provides the project team with a means of identifying and depicting all of the work that needs to be
performed to create the project deliverables, enabling them to organize work for each deliverable at a level
commensurate with the detail of the work required to create that deliverable. A WBS typically presents planned work
in a descending order of granularity. This means that very specific activities or work packages are represented at the
lowest levels of the WBS hierarchy (where the work is performed) and summary or rolled up activities are at higher
levels of the WBS. For example, if a project deliverable (e.g. Take delivery of jet engine) is to be created under
contract by an entity external to the performing organization, then this may appear as a rolled-up or summary activity
within the performing organization’s WBS. This would also appear in the contracting entity’s own WBS, though it will
show a greater degree of task granularity in the lower level work packages required to meet this deliverable (e.g.
 Project Management Professional (PMP)

Develop, test and manufacture the production-ready engine). In turn, each of these tasks might be composed of other,
more granular tasks (e.g. those required to develop the engine, those required to test the engine, etc.) that are
represented at a lower level within the WBS.

5.4 Scope Verification

[Page 118, Figure 5-9. Scope Verification: Inputs, Tools & Techniques, and Output]

Verification of project scope is the process whereby stakeholders formally accept the completed project scope and
associated deliverables. Deliverables are reviewed to ensure that they have been completed satisfactorily, meet the
project’s requirements and that they are acceptable to stakeholders.
Do not confuse scope verification with quality control (page 190), which is concerned with meeting the quality
requirements specified for each deliverable. The deliverables review process facilitating verification is called
inspection. Inspections include a variety of verification techniques, including measuring, examining, comparison with
the specified product requirements and applying acceptance criteria. Inspections may also be referred to as:
reviews;
product reviews;
audits; and
walkthroughs.

5.5 Scope Control

[Page 120, Figure 5-10. Scope Control: Inputs, Tools & Techniques, and Output]

The primary purpose of project scope control is to influence factors that create changes to project scope and to control
the impact of those changes if and when they occur. Control of scope changes is managed through the project
Integrated Change Control process (page 96). To facilitate this, a project scope Change Control System provides the
procedures by which the project scope and product scope may be changed. These procedures are documented in the
Project Scope Management Plan.

6. Project Time Management

“So how long is this going to take?” This is usually the question that management asks immediately after hearing the
answer to “How much is this going to cost?” In reality, however, one cannot answer the “how much” question without
first answering the “how long” question. As we know from our own experience, if you don’t have an answer to that
question, then management (or your sponsor, or your customer) will have an answer for you. All joking aside, this is
an important principle of Project Time Management: it is the responsibility of the project management team to
determine as accurately as possible the optimal duration of all activities that must be accomplished in order to meet
project requirements.
 Project Management Professional (PMP)

As project requirements are derived from stakeholder wants and expectations, stakeholders often express desired
dates for when they would like project activities to be completed. However, the project management team should
never accept such dates without first analyzing their basis and then assessing whether (and how) they can be
accommodated within the project schedule. If accepted, these dates are then treated as constraints in the
development of the project schedule and any expectations that are subsequently held by stakeholders around such
dates must be actively managed by the project manager throughout the duration of the project (see page 26).

6.1 Activity Definition

[Page 127, Figure 6-3. Activity Definition: Inputs, Tools & Techniques, and Outputs]

Activity Definition involves identifying and documenting the work that is planned to be performed by the project. Work
is performed at the lowest level of the Work Breakdown Structure (WBS). That is, at the work package level. This
level is defined as the level at which the project’s deliverables are created. Work packages are analyzed (or
decomposed) to identify the activities that will themselves create the project’s deliverables. These are known as
schedule activities. These schedule activities are the building blocks that are used to develop the project’s schedule.
They represent all of the activities that are required to meet the project’s objectives.
To summarize, these elements are generally represented within the hierarchy of the WBS as follows (top-down view):
Level 1 – represents the total scope of the project;
Level 2 – represents the project’s high level (or rolled-up) deliverables;
Level 3 – represents the project’s work packages (or deliverables); and
Level 4 – represents the project’s schedule activities.

Together with the WBS Dictionary, the WBS is one of the primary inputs to the activity definition process. Additionally,
information about the project’s deliverables, constraints and assumptions contained in the Project Scope Statement
are also taken into account in the activity definition process.

The development of schedule activities from the analysis of this information is achieved by subdividing work packages
into their smallest constituent elements, otherwise known as decomposition. Subdividing continues until the point at
which no further subdivision of the activity is possible. This point defines the schedule activity by the following
characteristics:
the duration of the activity can be discretely estimated;
the cost of the activity can be discretely estimated;
the resource requirements of the activity can be discretely estimated; and
the activity can be connected to other schedule activities via a logical relationship.
 Project Management Professional (PMP)

6.2 Activity Sequencing

[Page 130, Figure 6-4. Activity Sequencing: Inputs, Tools & Techniques, and Outputs]

The objective of Activity Sequencing is to identify and document the logical relationships between schedule activities.
Analysis of these logical relationships enables the project management team to assess alternative sequences of
performing the project work and to develop a project schedule that is realistic and achievable within the scope of the
project.

The sequencing of project activities in their logical relationships is modeled in the structure of the project schedule
network diagram. A network diagram depicts the chronology of project activities from left (start of project) to right (end
of project). There are two diagramming techniques commonly used to construct the network diagram. These are the
Precedence Diagramming Method and the Arrow Diagramming Method.

The Precedence Diagramming Method (PDM), also known as activity-on-node (AON), uses a node and arrow
convention to model the relationships between schedule activities. The nodes are depicted using boxes or rectangles
that represent activities. Activities are connected with arrows that represent dependencies between the activities (see
Figure 6-5 on page 131). The PDM can be used to model four different types of dependency relationships in which
one activity cannot commence or finish until the preceding activity has either started or ended. These relationships are
defined as:
Finish-to-Start – The predecessor activity must finish before the successor activity can commence;
Finish-to- Finish – The predecessor activity must finish before the successor activity can finish;
Start-to-Start – The predecessor activity must start before the successor activity can start; and
Start-to-Finish - The predecessor activity must start before the successor activity can finish.

A lag applies a delay to the successor activity. For example, in a finish-to-start relationship with a five day lag, a
successor activity cannot start until five days after the finish of the predecessor activity. If the predecessor activity
starts on day 1 and finishes on day 3, when does the successor activity start? On day 8 (3 + 5 = 8).

A lead accelerates the successor activity. For example, in a finish-to-start relationship with a five day lead, a
successor activity can start five days before the finish of the predecessor activity. If the predecessor activity starts on
day 1 and finishes on day 8, when can the successor activity start? On day 3 (8 – 5 = 3). Note that a negative lead is
the same as a positive lag.

The Arrow Diagramming Method (ADM), also known as activity-on-arrow (AOA), uses an arrow and node convention
to model the relationship between schedule activities. Arrows represent the schedule activities. The connection of
arrows to nodes represents dependencies (see Figure 6-6 on page 132). Note that this is the opposite of the PDM
convention. ADM is less commonly used than PDM diagramming and is characterized by the following features:
ADM diagrams incorporate dummy relationships (using dummy activities); and
only finish-to-start dependencies are used in ADM diagrams.
 Project Management Professional (PMP)

A dummy activity is a schedule activity of zero duration with no actual work content. A milestone in the project
schedule is an example of a dummy activity. It simply denotes the completion of a time-phased portion of the project.
A dummy activity is used to complete a logical relationship between two schedule activities that is either incomplete or
cannot be correctly described by the existing relationship. A dotted arrow convention is used to denote a dummy
relationship.

Project Schedule Network Templates based on previous projects may be used by the project team to create the
schedule network diagram. These can be used to construct the network diagram for the entire project or a contributing
part of the project (or subnet).
Templates are used throughout the project in a number of process areas. They provide project teams with
readymade artifacts, usually applicable to the needs of specific application areas or are based on projects of similar
scope and magnitude. They help to reduce the amount of effort required to perform work and improve the quality of
the outputs from the process area in which they are used. Templates are an important organizational process asset.
Examples of templates commonly used include:
Work Breakdown Structure (WBS) (page 113);
Activity Definition (page 128);
Activity Sequencing (page 133);
Cost Estimating (page 162);
Human Resource Planning (page 204); and
Risk Management Planning (page 242).

There are three types of logical relationships or dependencies:

Mandatory (hard logic) –dependencies that are defined by the inherent or physical characteristics of the work
to be performed.
Discretionary (soft logic) – also referred to as preferred or preferential logic, are dependencies established by
best practices generally followed in a specific application area or may be preferred according to the
circumstances of the project.
External –dependencies that arise from the relationship between project schedule activities and non- or
external project activities.

The output from the activity sequencing process is the Project Schedule Network Diagram, which is a schematic
display of the logical relationships among the project schedule activities.

6.3 Activity Resource Estimating

[Page 136, Figure 6-7. Activity Resource Estimating: Inputs, Tools & Techniques, and Outputs]

The Activity Resource Estimating process is closely linked with the Cost Estimating process (see pages 161-167), with
which it is closely coordinated. It is concerned with estimating what kind and quantity of resource will be required, and
when it will be required for each schedule activity. Activity resource estimating uses the bottom-up estimating
technique (see page 353 and section 7.1 Cost Estimating below). Decomposition of the schedule activity helps to
improve the accuracy of the estimate and enables estimates to be aggregated (or rolled-up) to derive a total quantity
for the resources required for each schedule activity. The estimate should also take account of any logical
relationships or dependencies between schedule activities where such relationships might influence resource
utilization.
 Project Management Professional (PMP)

6.4 Activity Duration Estimating

[Page 139, Figure 6-8. Activity Duration Estimating: Inputs, Tools & Techniques, and Outputs]

Activity Duration Estimating is performed by the project staff responsible for the work required to complete the
schedule activity whose duration is being estimated. The estimate is developed and refined through progressive
elaboration as more detailed information about the activity is gathered and analyzed. The process focuses on
estimating:
the amount of work effort required to perform the schedule activity;
the amount of resources needed to complete the schedule activity; and
the number of work periods that are required to complete the schedule activity.

Estimating the number of work periods often needs to take account of elapsed time affecting the schedule activity in a
specific application area. Most project scheduling software tools are designed to handle elapsed time through the use
of a Project Calendar. The Project Calendar defines the work periods that are used to manage and schedule project
activities with respect to work periods (during which schedule activities are worked) and non-work periods (during
which schedule activities are idle or dormant). Note that overall project duration is an output from the Schedule
Development process, not from the Activity Duration Estimating process. The latter focuses on individual components
of the project, or schedule activities.

The three types of estimates used in this method are:

Most likely – representing the duration of the schedule activity on the basis of most likely resource availability
and assignment, known dependencies and realistic expectations about the performance of the required
task(s);
Optimistic (or best case) – representing the duration of the schedule activity on the basis of uninterrupted and
optimal performance of the required task(s) (the perfect realization of circumstances in the most likely
scenario); and
Pessimistic (or worst case) – which represents the duration of the schedule activity on the basis of disrupted
and imperfect performance of the required task(s).

The Third edition of the PMBOK removes explicit reference to the PERT (Program Evaluation and Review Technique),
which uses a four-point estimating method. This is because PERT is based on a mean (or most likely) value. PERT
uses the following formula: O plus 4, times M, plus P and divided by 6 equals E, where O = the Optimistic value, M =
the Most Likely value, P = the Pessimistic value and E = the Expected Value. The PMBOK emphasizes the fact that
an average estimate provides a more accurate activity duration estimate than a single-point, mean estimate and
therefore an activity duration estimate should be based on an average of the three estimated durations (most likely,
optimistic, and pessimistic).

6.5 Schedule Development

[Page 143, Figure 6-9. Schedule Development: Inputs, Tools & Techniques, and Outputs]

The objective of the Schedule Development process is to identify start and finish dates for all schedule activities such
that a start-to-finish baseline schedule can be created against which project progress can then be tracked and
monitored.
 Project Management Professional (PMP)

The development of the project schedule by the project team is limited by the
constraints documented in the project scope statement. Constraints that
most affect schedule development are:
project start and finish dates that are imposed by the
circumstances of the project and arise from the logical
precedence of tasks in an application area or external factors
that dictate when activities can be performed; and
stakeholder dates that typically represent preferred dates or key
milestones that are desired (or required) by the customer,
sponsor or other project stakeholders.

Schedule Network Analysis techniques are applied to the sequence of

schedule activities to create a project schedule, of which the most widely
used technique is the Critical Path Method (CPM).

The CPM is a schedule network analysis technique that allows for the
calculation of both theoretical early start and finish dates, and late start and
finish dates for project activities. Calculating these dates enables scheduling
flexibility to be identified across alternative network paths running through
the project schedule network diagram. The objective of this is to identify the
project path with the minimum total duration. The dates calculated provide a
framework of time periods from which the project schedule is then
constructed on the basis of the logical relationships, durations, leads, lags
and other constraints on the tasks. Two methods are used to calculate the
earliest and latest dates possible for the start and finish of activities:
Forward pass – involves calculating the early start (ES) and early
finish (EF) dates by moving forward, from left (start) to right (finish),
through the network diagram.
Formula: EF = ES + duration
The early finish date is calculated by adding the duration of the
activity to the early start date.
Backward pass – involves calculating the late start (LS) and late
finish (LF) dates by moving backward, from right (finish) to left (start)
through the network diagram.
Formula: LS = LF – duration
The late start date is calculated by subtracting the duration of the
activity from the late finish date.

Flexibility in the project schedule is represented by float (or slack) in the

network paths. Float is defined by the amount of time that a schedule
activity can be delayed without delaying the project. Float can be calculated
using either late start and early start dates or late finish and early finish
dates. Remember these for the exam:
Formula: Float = LS – ES or
Formula: Float = LF – EF
 Project Management Professional (PMP)

There are two kinds of float. Memorize these. Do not confuse the two:
Free float – represents the amount of time that a predecessor schedule activity can be delayed without
delaying the early start of the successor schedule activity;
Total float – represents the amount of time that a schedule activity can be delayed from its early start date
without delaying the project completion date.

Where a project needs to meet imposed dates or other schedule constraints, schedule compression techniques can be
used to shorten the project schedule while maintaining the scope of the project. Two compression methods are
commonly used:
Crashing – in which additional resources are applied to shorten the duration of critical path tasks. This
usually implies an increase in cost to pay for additional staff, buy additional work hours (overtime) or purchase
technology.
Fast Tracking – in which tasks that are normally performed serially are performed in parallel. This can result
in tasks being removed from the critical path.

The output from the schedule development process is the Project Schedule, which can be presented in one or more of
the following formats:
Milestone chart – presents the start and end dates for the project’s major deliverables (milestones) in a
bar chart format;
Bar (or GANTT) chart – presents both the start and end dates for project schedule activities and their
durations in a bar char format.
Project schedule network diagram – presents both the critical path and the network logic relationships
using an AON diagram format.

Note that for tracking and monitoring schedule performance, a schedule baseline is created as one of the outputs from
this process.

6.6 Schedule Control

[Page 152, Figure 6-11. Schedule Control: Inputs, Tools & Techniques, and Outputs]

Like project cost control, Schedule Control is a critical part of Integrated Change Control (see pages 96-99). Time
intersects with both Cost (=budget) and Scope (=requirements, including quality), and involves tradeoffs between
these elements when controlling the project schedule.
The Schedule Baseline is defined by the following characteristics:
it is agreed and formally approved by the project team;
it is maintained under formal change control;
it is updated in response to approved change requests; and
it is archived as and when approved changes are applied, and an updated baseline is issued.
 Project Management Professional (PMP)

Schedule performance and progress are monitored and reported by the project management team, including the
completion percent of all current in-flight activities. Different conventions can be used to report progress on project
activities. For example, an absolute measure only counts an activity as complete when it is 100% finished, whereas
an 80:20 measure counts a task as 20% complete when it has started and the remaining 80% of the task is credited as
complete when it is finished. Project schedule software tools support these kinds of conventions to enable “percent
complete” tracking of project activities.

7. Project Cost Management

“How much is this going to cost?” is the question that management usually asks immediately after hearing the answer
to: “Do we have the capability to do this successfully?” The primary objective of Project Cost Management is to
determine the cost of the resources required to deliver the project according to schedule, and then to manage those
costs according to the approved budget (the baseline). Funding for the project is limited to the amount required to do
that, and only that. The funds allocated must therefore map as accurately as possible to the activities required to
deliver the project. By extension, how well the project scope is defined will determine the limits of the project funding.

The cost of the project is therefore determined with respect to:

Resources – What resources are required (technical, human), and are they available (technology, skills,
expertise, quantity)?
Time – How long will it take for those resources to complete activities and tasks to deliver the project?
Scope – What are the project’s boundaries and limits? What is not included (and therefore will not be
funded)?
Quality – What are the quality requirements of the project’s products or services?

Present value – the discounted value (i.e. the current value) of a future sum or stream of cash flows. This value is
expressed by the formula PV = FV divided by 1 + r multiplied by n, where PV = Present Value, FV = Future Value, r =
the interest rate and n = the number of time periods;
Net Present Value (NPV) – equal to the present value of the total benefits (which can be expressed as either
revenue or income) of the project, minus the costs.
Internal Rate of Return (IRR) – the rate (expressed as an interest or discount rate) at which the value of the
project inflows (revenues) and the project outflows (costs) are exactly equal, or the rate at which the net
present value = 0.
Payback Period – the length of time (usually expressed as time periods or number of years/months) required
of a company to recover its initial investment in the project before it starts generating a profit, i.e. the time it
takes to pay back the cost of the project.
Benefit Cost Ratio (BCR) – compares benefits to costs. Benefits can be expressed as either revenue or
payback (not profit). If the BCR value is greater than 1, then the benefits of the project outweigh the costs; if
the BCR value is less than 1, then the costs outweigh the benefits.
 Project Management Professional (PMP)

The Cost Management Plan defines how the following criteria will be applied to the project:
Units of measurement – identifies the base units that will be used for measuring resource utilization; for
example, hours, days, weeks, etc. for staff; dollars, euros, etc. for costs;
Level of precision – prescribes the precision to which schedule activity cost estimates will be recorded;
for example, to within the nearest $100, $1,000, etc.
Control thresholds – prescribes the agreed variances in costs or time (schedule) that are tolerated when
measurements are taken;
Earned value rules – describes the basis on which earned value techniques (EVT) will be applied to
monitor project performance;
Control account (CA) – prescribes how work packages in the WBS will be linked to and tracked through
the performing organization’s accounting system.
Report format – defines the formats for the project’s cost reports;
Estimation, Budget & Control processes – describes how the cost estimation, budget and control
processes will be applied to the project.

7.1 Cost Estimating

[Page 162, Figure 7-3. Cost Estimating: Inputs, Tools & Techniques, and Outputs]

The objective of the Cost Estimating process is to develop Activity Cost Estimates, which are quantitative
approximations of the likely costs of the resources required to successfully complete scheduled project activities.
Two important factors determine the accuracy of those estimates:
estimating must be carried out by the person(s) responsible for performing the tasks that are being cost
estimated; and
estimating should take into account the possible causes of variance in those costs, including risks.

As the project progresses, and as more detail and better quality information about the project tasks becomes available,
the accuracy of project estimates improves. This is reflected in the range of accuracy of the estimates produced. The
following are the most commonly quoted ranges used when preparing project cost estimates. You should remember
these ranges for the exam:
Rough Order of Magnitude (ROM) – is in a range of -50% to +100% from the expected or actual value;
Order of Magnitude – is in a range of -25% to +75% from the expected or actual value;
Budget estimate – is in a range of -10% to +25% from the expected or actual value; and
Definitive estimate – is in a range of -5% to +10% from the expected or actual value.

At what point in the project life cycle would you expect a definitive estimate to be given? Definitive estimates are
provided at the end of the planning phase, or early in the execution phase, when the level of detail in the plan allows
for greater accuracy in estimating costs than at project inception (where a ROM estimate might be used).
The accuracy of project cost estimates is determined by the completeness and quality of the information used to
prepare the estimates.
 Project Management Professional (PMP)

The PMBOK identifies a number of inputs that are used in the estimating process (see pages 162-164), of which the
following are the most important:
Project Scope Statement – covers the totality of those elements that determine what the project will
deliver and how it will deliver the project’s products and services.
Work Breakdown Structure (WBS) – defines the scope and interrelationship of the project’s component
work packages.
Risk register – considers information on risk responses. The response to each risk identified in the
project’s Risk register will have a cost associated with it that needs to be taken into account when
estimating costs.
Schedule Management Plan (page 374) – Uses schedule activity resources and their respective
durations as key inputs.
Lessons Learned – provides input to estimates based on the performance of previous, comparable
projects.
Project team knowledge – Project team members can provide input to estimates based on their own
experience and knowledge of similar projects.

Various estimating methods are used to develop the project’s costs estimates. You should familiarize yourself with the
following methods. Note how and when it is most appropriate to use each of the following methods:
Analogous (or Top-Down) estimating – uses the actual costs of similar, previous projects as the basis for
estimating the cost of the current project.
Parametric (or unit cost) estimating – uses mathematical models to derive a scaled cost for the project,
based on the parameters of the work to be performed.
Bottom-Up estimating – involves estimating the cost of individual work packages or individual schedule
activities with the lowest level of detail.

7.2 Cost Budgeting

[Page 167, Figure 7-4. Cost Budgeting: Inputs, Tools & Techniques, and Outputs]

The objective of Cost Budgeting is to establish a total cost baseline to measure the performance of the project, as
based on the aggregation of the estimated costs for each of the project’s constituent schedule activities (or work
packages). Cost budgeting uses aggregation and parametric estimating to derive an overall project cost. An
allowance is also made for unplanned but potentially required changes to the project (“unknown unknowns”). This is
accounted for in the Management Contingency Reserves. These reserves are included in the project budget but are
not part of the project’s cost baseline.

7.3 Cost Control

[Page 171, Figure 7-6. Cost Control: Inputs, Tools & Techniques, and Outputs]

Project Cost Control is a critical part of Integrated Change Control (see pages 96-99). Cost intersects with both Time
(=schedule) and Scope (=requirements, including quality). Take a moment to think about what that means and how it
affects the project. If any one of these changes, then at least one of the other two is affected. For example, if the
schedule increases, and resources are used for longer than planned, then project costs will also increase; if funding is
reduced, then the scope of the requirements will also contract or change.
 Project Management Professional (PMP)

How is project cost control performed? It involves:

influencing the factors that cause variance in the parameters that determine the project costs as detailed in
the baseline;
when variances occur, assessing if any corrective actions are required to bring future project performance,
and the costs associated with that performance, back into line with the approved baseline;
when changes occur, assessing what effect, if any, they have had on project performance, and if
corrective action is required;
updating the baseline to reflect all approved changes; and
ensuring that unapproved changes are not included in the baseline and are not included in project
performance measurements.

The following performance reporting techniques are used by the team to assess the project’s performance:
Variance analysis – in which the actual performance of project work is compared to planned or expected
performance, and any variations are assessed as to their impact on the project. Variance analysis is most
often performed on cost and schedule data, but can also include scope, quality, resource and risk
assessment;
Trend analysis – in which project performance is assessed over time to determine if the project’s
performance is improving or deteriorating, or is within an acceptable range of variation;
Earned value – in which planned performance (the baseline) is compared to actual performance.

PMI places great emphasis on the use of Earned Value (EV) to objectively assess project performance, because it is
the most effective technique for integrating both cost and time when measuring project work. But it is the PMP exam
topic that many candidates find the hardest to master, because it is not widely applied by project managers to their
own projects.

The main objective of EV is to:

measure any variances in work performed from the planned or expected work;
assess the extent and impact of the observed variances on the project;
make any necessary adjustments or corrections resulting from these observed variances to bring the
project back into line with the plan; and
apply any approved changes to the plan and update all affected baselines to correctly reflect the approved
changes.

There are three main concepts in EV analysis. The purpose of these is to measure whether the value of project work
performed at a given moment in time (when measurements are taken) is as planned.
Earned Value (EV) – the estimated value of the budgeted amount of the work actually accomplished or
performed when performance is measured. This is alternatively known as the Budgeted Cost of Work
Performed (BCWP);
Planned Value (PV) – the estimated value of the scheduled work that is to be accomplished or completed
during the next reporting period. This is alternatively known as the Budgeted Cost of Work Scheduled (BCWS)
; and
Actual Cost (AC) – the total cost of the work actually accomplished in performing the project work when
performance is measured. This is alternatively known as the Actual Cost of Work Performed (ACWP).
 Project Management Professional (PMP)

Variances in both project cost and schedule are measured using the following formulae:
Cost Variance (CV) – measures the difference between the estimated value of the budgeted work
accomplished and the actual cost of the work accomplished. It answers the question “Are we on budget?”
Formula: EV minus AC = CV
A negative CV value (-) indicates that the project is over budget, while a positive value (+) indicates that the
project is under budget; and
Schedule Variance (SV) - measures the difference between the estimated value of the budgeted work
accomplished and the estimated value of the scheduled work that is to be accomplished. It answers the
question “Are we on schedule?”
Formula: EV minus PV = SV
A negative SV value (-) indicates that the project is behind schedule, while a positive value (+) indicates
that the project is ahead of schedule.

The following indices are used to measure the project’s cost and schedule performance:
Cost Performance Index (CPI) – indicates the rate of return that the project spend is yielding. It answers the
question “For every project dollar we spend, what is the project returning?”
Formula: EV divided by AC = CPI
A CPI value greater than 1 indicates that for every dollar spent, the project is earning more than the project
spend (that is, costs are running below estimated levels). A CPI value of less than 1 indicates that the project
is spending more than it is earning (that is, costs are running ahead of the estimated levels). The CPI value
indicates how efficiently the project is being run with respect to costs; and
Schedule Performance Index (SPI) – indicates the rate of project progress compared to the scheduled or
planned progress. It answers the question “If we continue at this rate, will we achieve our project end date as
planned?”
Formula: EV divided by PV = SPI

EV is also used to forecast performance, to help assess the cost, or amount, of the work remaining to complete the
project.
Budget at Completion (BAC) – represents the total planned value of the project work, and it is therefore the
sum of all of the budgeted work.
Formula: total cumulative PV at completion (PVc) = BAC
Estimate at Completion (EAC) – represents the currently expected total cost of the project when
performance is measured and applies the current spend rate (expressed in the CPI value) to the total budget,
to derive an estimate of what the project will cost at this rate.
Formula: BAC divided by CPI = EAC
Estimate to Complete (ETC) – represents an estimate of how much it will cost to complete the project from
this point (when performance is measured) forward. The cost of the work actually accomplished is subtracted
from the expected total cost of the project, to derive an estimate of how much more it is now expected to cost
to complete the project.
Formula: EAC minus AC = ETC
 Project Management Professional (PMP)

8. Project Quality Management

Quality influences all projects at two levels. It affects how the project is performed and what is delivered by the project.
Why is quality so important to projects?
The scope of a project is defined by stakeholder needs, wants and expectations. These represent the requirements
the project must meet, no more and no less. Quality in projects is therefore often defined as conformance to
requirements (delivering what is required) plus fitness for use (satisfying real needs), which generally equals customer
satisfaction.
Familiarize yourself with the following:
Quality emphasizes prevention over inspection – the principle that the cost of preventing mistakes earlier
in the product creation process is generally much less than the cost of correcting mistakes that are revealed by
inspection of the product later in the process; and
Quality implies continuous improvement – the principle that all processes involved in project performance
and creating the project’s product should be continually improved to reduce costs and improve consistency to
attain an optimal state.
Plan the task or activity, specifying the desired outcome;
Do the task or activity, as defined in the plan;
Check the results of the task or activity against the desired outcome; and
Act to correct or amend the task or activity if the results did not meet the desired outcome.

Quality means satisfying customer requirements – the principle that customer requirements define the
scope of the quality attributes that need to be met by the project. Because customer satisfaction is based on
subjective needs, the PMBOK considers them to be unquantifiable expectations (page 110), which are difficult
to successfully satisfy.
Quality is a management responsibility – the principle that management is ultimately responsible for quality
within the performing organization delivering the project. Once again, W. Edwards Deming is influential in
defining the standards associated with this principle.
 Project Management Professional (PMP)

Quality is not the same as grade – the principle that grade is a category or rank that is used to distinguish
items that have the same functional use but do not share the same requirements for quality (as defined by ISO
standard 8402).
Precision and accuracy are not equivalent – the principle that precision is defined by observed consistency
that the value of repeated measurements are closely clustered and exhibit minimal scatter or dispersion when
plotted.
The Cost of Quality (COQ) includes all of the costs related to quality – the principle, formulated by Joseph
M. Juran, that the cost of quality includes both the cost of conformance and the cost of nonconformance.
Conformance costs include all prevention and appraisal costs associated with investing in proactive measures
designed to assure delivery of quality requirements (validated by customer acceptance).
ISO 9000 – provides for the establishment of quality systems within organizations, and it is administered by
the International Organization for Standardization (ISO).
Total Quality Management (TQM) – based on the principle that if quality requirements are met, then
customer requirements are met, TQM provides the primary focus for the ways in which a performing
organization will strive to meet those requirements.
Six Sigma – an approach to quality management that emphasizes continuous process improvement using
statistical measurement to guide improvements and focuses on identifying and solving the root causes of
problems.

8.1 Quality Planning

[Page 184, Figure 8-3. Quality Planning: Inputs, Tools & Techniques, and Output]

The PMBOK approach to quality management emphasizes one of the key principles formulated by Dr. Genichi
Taguchi. According to Taguchi, quality is planned in, not inspected in. Clearly the PMBOK agrees. In fact, according
to the PMBOK, the primary purpose of Quality Planning is to identify which kinds of quality standards are relevant to
the project, and then determine how best to satisfy them. This is performed in parallel with other project planning
processes because meeting quality requirements often implies changes to the project costs or schedule.
When quality is achieved, both the processes required to create the project’s product or service, and the actual product
or service itself, are optimal. An optimal state is one in which the process or product is as effective or as functional as
required by the user of the process or product. Optimization is performed by influencing and adjusting those factors
affecting the variables in the process or product that affect quality. A key methodology for identifying and adjusting
those factors, also developed by Taguchi, is Design of Experiments (DOE). DOE provides a statistical basis for
systematically adjusting all factors affecting quality variables in a process or product by examining alternatives.

8.2 Perform Quality Assurance

[Page 188, Figure 8-4. Perform Quality Assurance: Inputs, Tools & Techniques, and Output]

Quality Assurance (QA) is the application of planned, systematic quality activities to ensure that the project utilizes all
of the processes required to meet project requirements. Note that continuous process improvement is facilitated by
QA and that many performing organizations have dedicated QA or similar functional departments who are responsible
for oversight of QA activities. The primary focus of process improvement is the performing organization’s business
processes, although it can often be applied to other process areas and functions within the organization. The two main
tools and techniques used during QA are Quality Audits and Process Analysis.
 Project Management Professional (PMP)

8.3 Perform Quality Control

[Page 191, Figure 8-5. Perform Quality Control: Inputs, Tools & Techniques, and Output]

Quality Control (QC) focuses on the correctness of work performed. The objectives of QC are to verify that as project
work is performed, results comply with the relevant quality standards and actions are taken to eliminate the causes of
any unsatisfactory results. QC is performed throughout the project using statistical sampling techniques to
continuously monitor project results. Statistical sampling is a technical skill that requires both relevant knowledge and
competency to apply correctly within a QC environment. Project management teams need to be knowledgeable about
such techniques in order to evaluate the results of QC activities and to take appropriate action as indicated by the
results. In order to assess the results of QC activities correctly (and as preparation for the PMP exam), you need to
understand the following statistical sampling concepts and terminology:
Attribute – a defining characteristic of a process or product. The attribute is measured to determine if the
item or component sampled is acceptable.
Variable – the characteristic of the process or product that is measured, such as size, shape, weight, etc.;
Sample size – the number of items, or representatives, selected in the sample set;
Range – the limits of a population, defined by the difference between the largest measurement or value
and the smallest in the population distribution;
Variance – a measurement of how far the variable being measured is from the expected value typically
associated with that variable (the norm);
Standard deviation – a statistical measure of dispersion of a sample, represented by the square root of
the average of the squares of deviations about the mean of a set of measurements or data. Standard
deviation is used to identify the range of accuracy that is applied to the results of a defined measurement.
It is commonly represented by the sigma (or standard deviation) scale in ascending order of magnitude, as
follows:
o +/- 1 sigma = 68.26%,
o +/- 2 sigma = 95.46%,
o +/- 3 sigma = 99.73% (representing 27 in 10,000 occurrences),
o +/- 6 sigma = 99.99% (representing 1 in 10,000 occurrences);
Normal distribution – across a statistical sample is depicted by a bell curve distribution, in which 50% of
the curve occurs above the mean (to the right-hand side of the mean point, usually a line dividing the bell
curve), and 50% occurs below the mean (the left-hand side of the mean point);
Mean – the arithmetic average expressed by the sum of the measurements in a sample set, divided by the
number of measurements (the sample size);
Median – the value in a range of data points representing the midpoint in the range, and having as many
data points above the midpoint as it does below;
Mode – the value in a range of data points that represents the most frequently observed value in that
range;
Statistical sampling – involves selecting a sub-set of the total population for inspection (the sample set).
Attribute sampling – an audit technique in which representatives of a population are selected (the
sample set) and assessed for absolute conformance (yes or no);
Variables sampling – an audit technique in which the degree of conformity of a sample representative is
measured and rated on a continuous scale;
Special causes – unusual events or results observed in a process indicating that it is not in control;
 Project Management Professional (PMP)

Common causes – also known as random causes, these are events or results that are attributable to a
known variation within the normal working of the process.
Assignable cause – a single data point, or a pattern of data points, that indicates investigation is required
to determine the cause of variation in the process (see Control charts below);
Tolerances – specify the acceptable variations in the attributes of a process, and provide measurement of
the degree of accuracy within the tolerable range of variation (acceptable margin of error);
Control limits – define the variable limits (upper and lower) within which a process is observed to be in
control. Control limits are dynamic and should be adjusted when required, to reflect the normal range of
operation of the process;
Prevention – includes all of the actions taken to keep errors out of the process; and
Inspection – includes all of the actions taken to keep errors out of the hands of the customer.

According to the PMBOK (pages 192-196), there are Seven Basic Tools of Quality. These are the most commonly
used QC statistical analysis tools and techniques. Familiarize yourself with these so that you know how they function,
what purpose they serve, and how to interpret their results. For example, you should know how to recognize the
occurrence of a rule of seven (see below), and what such an occurrence means in terms of quality.
Control Charts – are used to determine whether or not a process is stable or exhibits predictable
performance (is in control). The chart depicts the behavior of a process observed over time. It is a tool for
detecting trends. The data points gathered in a control chart are used to identify special cause variation, that
is, evidence that the process is inconsistent or unpredictable in its behavior (it is not in control).
Flowcharting – is used to analyze how problems occur through the depiction of the interrelation of elements
within a process.
Cause and Effect Diagrams – also known as fishbone or Ishikawa diagrams, cause and effect diagrams are
used to depict and aid analysis of how various factors may contribute to, or be linked to, potential problems or
effects.
Histograms – are bar charts that show the distribution of variables where each bar (or column) represents an
attribute or characteristic of a problem or event.
Pareto Chart – is a specific kind of histogram in which the causes of a problem or event are ordered by
frequency of occurrence, and displayed by category or type of cause. Pareto charts are used to identify and
evaluate nonconformities in processes.
Run Chart – is used to track and analyze trends in performance over time. Data points are plotted in the
order in which they occur on a line graph so that patterns of variation in the process or results (including both
improvement and deterioration) are captured over time.
Scatter Diagram – depicts the pattern of relationships between two variables, and is used to analyze the
possible relationships between changes observed in the two variables. Dependent versus independent
variables are plotted.

If any defects are detected during QC, these must be repaired so that the process, product or component can be
brought back into compliance with the relevant requirements or specification. This is accomplished using Defect
Repair Review, performed by the QC department.
 Project Management Professional (PMP)

9. Project Human Resource Management

One of the most important questions a performing organization must answer when selecting and initiating a project is:
“Do we have the capability to do this successfully?” This does not mean just financial and technical, but also human
resource capability, in terms of availability of the necessary skills, knowledge, experience and manpower to satisfy the
requirements of the project and to meet them successfully. Effectively managing a project’s human resources is
therefore critical to the success of the project.
The PMBOK approach to project human resource management emphasizes the important role that both the project
management team and project manager play in influencing, directing and managing all project activity. The PMBOK
uses the following definitions to describe the relationships and roles of the various staff engaged in a project. In
particular, note the difference between “project team” and “project management team.” You do not need to memorize
these definitions, but as you read the PMBOK, you should note which resource group is responsible for which activities
or processes.
Project staff – alternatively referred to as project team members, they include all staff performing project
work as a regular part of their assigned duties. Project staff report directly or indirectly to the project
manager;
Project team – includes the project manager, the project management team and, on some projects, the
sponsor, too;
Project management team - a sub-set of the project team, alternatively known as the core, executive or
leadership team, who are responsible for project management activities. On small scale projects the
project management team may be comprised of most of the project staff; and
Project manager – the person assigned by the performing organization to achieve the project objectives.

9.1 Human Resource Planning

[Page 203, Figure 9-4. Human Resource Planning: Inputs, Tools & Techniques, and Output]

The objectives of Human Resource planning are to determine the roles, responsibilities and reporting relationships of
project participants (both individuals and groups), and to create the project’s staffing management plan. The plan must
address all of the factors that determine the effectiveness of the project’s human resource capability that will, in turn,
influence how the project is performed and the success of its results.
Therefore, the scope of the plan must address such issues as:
Staff acquisition - How and when are staff acquired by the project (to achieve optimal resource utilization)?
Staff release - How and when are staff released from the project (to give back resources to benefit other
projects)?
Organizational influence - What effect will the project’s staffing requirements have on the performing
organization (on normal business operations or on other projects)?
Training - What new or enhanced skills may be required by staff to complete the project (by identifying
training needs and promoting skills acquisition)?
Motivation - How will staff be recognized and rewarded for their efforts (to encourage positive behaviors
that meet the needs of the project’s requirements)?
Compliance - What kind of compliance considerations need to be taken into account when planning how
staff will be used on the project (for example, health and safety, statutory or union regulations, etc.)?
 Project Management Professional (PMP)

When planning how human resources will be used, the project management team needs to be aware of how
Enterprise Environmental Factors specific to the project might influence the development of roles and responsibilities,
and how the performing organization might be involved in the project. These factors include:
Organizational – identifying which functional units or departments will be involved in the project, how those
departments interact and interrelate, what methods of working they use, etc.;
Technical – identifying the technologies and technical resources available to meet the projects needs,
including technical operating standards, mandated technology use, standard operational workflow processes,
etc.;
Interpersonal – identifying candidates for the project team, including their job descriptions, how they interact
with other staff and departments (formal and informal), reporting relationships, supervisor-subordinate
relationships, customer-supplier relationships, levels of cooperation, trust, respect, etc.;
Logistical – identifying the logistical constraints that may determine the effectiveness of team member
interactions and cohesion, including geographical proximity (collocation) or dispersion (different areas of the
country or different countries), time zone differences, etc.; and
Political – identifying different stakeholder agendas and goals, informal relationships that support such
agendas and goals, how and where stakeholders exert influence within the organization (especially informally)
and how that might affect project performance.

In addition to the above factors, the project management team may also find its human resource planning constrained
by the following:
Collective bargaining agreements – union and other employee agreements with the performing
organization may limit the project management team’s ability to flex roles and working arrangements to
meet project needs;
Economic conditions – may impact the kind of human resources that can be secured and utilized
effectively.
Organizational structure – the performing organizational structure directly impacts how the project is
performed with respect to the amount of influence and authority that the project manger and project
management team can exert in securing and directing the necessary resource and priority to successfully
complete project activities.

Organizational structures are defined by the interactions and relationships between the various constituent functions or
departments of the performing organization. The relationships are generally determined by the business needs of the
organization. Interactions between functions or departments often create relationships in which the outputs, resources
or activities of a group or department are interdependent, or shared across the organization. These relationships are
typically represented in a matrix diagram. A matrix organization is one in which the project manager shares
responsibility with the various functional managers for assigning priorities and for directing the work of staff who are
assigned to the project.
Organizational structures can be categorized according to an ascending scale of project management influence and
authority. Note that as you ascend the scale,
the authority and influence of the project manager increases;
resources allocated to the project increases; and
the number and scale of projects sponsored by the performing organization increases.
 Project Management Professional (PMP)

The PMBOK recognizes five types of organizational structures that can be distinguished according to the extent to
which they support and promote projects within a performing organization (see pages 28-32). You must be able to
recognize these types, and understand how they limit or enhance the ability of the project manager and project
management team to influence and direct organizational resources to meet project needs.
Functional – in a functional organization, each specialist department or group has ultimate authority over any
project work performed by its staff, and will defer to other departments for work outside of its specialization.
Projects are performed in accordance with the hierarchical structure of the company.
Weak Matrix – functional departments still exert strong control over resource allocations and budget, and the
project manager’s authority is limited.
Balanced Matrix – the project manager begins to share authority with functional managers for directing and
assigning staff to project work, as well as sharing in control over the project budget.
Strong Matrix – control and influence over resources and budget assigned to projects is shared with
functional managers, though the project manager exerts the stronger authority over these.
Projectized – Performing projects is the business of the organization, and functions and departments are
primarily aligned to support the execution of projects.

Roles and responsibilities are typically described and depicted in the following formats:
Hierarchical-type chart – in which project activities and deliverables are mapped to the functional group
or department responsible for executing those activities and delivering artifacts in accordance with the
project management plan.
Matrix-based chart – in which the level of responsibility for a project task or deliverable is explicitly
identified with a team member or group.
Text format – in which much more detailed descriptions of roles, responsibilities, levels of authority,
qualifications, competencies, etc., can be provided than in a hierarchical or matrix chart format.

Whichever format is selected, the purpose of these is the same: to ensure that each work package has an accountable
owner assigned, and that all project participants have clearly defined roles and responsibilities. A key source of
conflict within projects is ambiguity over who is responsible for what. This problem can be further exacerbated by
ambiguity regarding authority over project activities and the assignment of priorities where trade-offs may need to be
made to ensure delivery of an expected contribution.
At a lower level of granularity, matrix-based charts are generally used to identify which project members are
responsible for which project activities or deliverables (although this is sometimes done at the group or department
level). A Responsibility Assignment Matrix (RAM) is a chart that shows not only who is responsible for what, but also
the level of authority they exert over the task or activity. Using the project WBS or similar structural breakdowns, the
RAM lists project tasks or activities along one axis, and the team members’ names along the other axis of the matrix.
For each activity, a responsibility is assigned to a team member according to the level of authority that they have over
that activity. This is sometimes called a RACI chart, after the names of the levels of authority identified as follows:
Responsible – the team member who has ultimate authority for executing the task or activity meeting the
needs of the project;
Accountable – the team member who has ultimate responsibility for ensuring that a task or activity has been
completed as required by the needs of the project;
Consult – the team member who must be consulted about the performance of the task or expected outcome,
as it may impinge or directly affect the performance of activities or tasks for which they are responsible; and
Inform – the team member who must be made aware of the performance of a task or outcome so that they can
respond, if appropriate, from an informed perspective.
 Project Management Professional (PMP)

All roles and responsibilities required by the project must be identified and
defined as a result of the human resource planning process. At the very
least, the following must be documented:
Role – the part that the team member will play in the project.
Each team member is ultimately accountable for the role
assigned to them;
Authority – confers rights to make decisions, apply resource
and sign approvals. The level of authority exercised by each
team member derives from their designated and agreed upon
project responsibilities;
Responsibility – is defined by those accountabilities which the
team member must perform or execute to meet project needs;
and
Competency – is defined by a team member’s skills and
capacity to perform tasks assigned to them to meet project
requirements. Team member competency impacts, both
positively and negatively, project performance.

The Staffing Management Plan is the formal planning document that

describes how and when the project’s human resource requirements will be
met and is comprised of the following components:
Staff acquisition – addressing how and where project staff will be
added to the project, including costs of acquisition (determined by
the skills, knowledge, and experience required to meet project
needs);
Timetable – identifying when staff will be added to the project and
how long they will be utilized on project activities.
Release criteria – defining when and how staff will be released from
the project and returned to their functional department or transitioned
to another project.
Training needs – identifying how required competencies will be
acquired by staff to meet the project’s needs;
Recognition and Rewards (R&R) – defining criteria and behaviors
by which team members will be rewarded for their project efforts.
The scope of an effective R&R scheme must be based on those
activities that a team member can personally influence and control.
Compliance – identifying how the project will ensure that it meets
the requirements of human resource policies, statutory regulations,
union agreements, etc.;
Safety – identifying relevant health and safety policies and
procedures that may affect staff in the performance of their project
work.

Behaviors arise from our needs and wants. The relative importance and
influence of these needs and wants changes over time as they are met. This
insight underpins a model of behavioral development known as Maslow’s
Hierarchy of Human Needs, in which the individual progresses from
 Project Management Professional (PMP)

satisfying basic physiological needs to satisfying higher, cognitive needs. The levels of progression are usually
represented in the form of an ascending pyramid, beginning with physiological needs at the lowest level.
Physiological needs – representing the basic or fundamental needs of existence, such as shelter, food,
clothing, etc. The primary objectives of these needs are self-preservation and comfort;
Safety needs – representing the avoidance of risk, pain or harm. These needs are met by anything that
promotes and assures stability, order and security;
Social needs – representing companionship, family and social relationships;
Esteem needs – represented by our sense of status, derived from achievements and responsibilities that
are recognized, acknowledged and rewarded; and
Self Actualization – representing the cognitive level at which the individual realizes their full potential,
attaining self-fulfillment.

9.2 Acquire Project Team

[Page 209, Figure 9-7. Acquire Project Team: Inputs, Tools & Techniques, and Output]

Building the project team involves acquiring staff with the right level of skills, knowledge and experience to complete
project activities according to the needs and requirements of the project. The project management team’s ability to
select the right staff to do this may be constrained by enterprise environmental factors, such as staff availability, the
competencies of the staff available (inc. relevant experience of similar projects), the cost of acquisition (salaries,
overtime, bonus payments, fees for external contractors, etc.) and the interests of staff (inc. motivation in working on
the project).

9.3 Develop Project Team

[Page 212, Figure 9-8. Develop Project Team: Inputs, Tools & Techniques, and Output]

Maximizing team performance is therefore focused in two areas: assuring the successful execution of project tasks
through skills improvement actions, and improving team working using techniques that will create and maintain team
cohesion and trust. Developing the project team is a continuous process that occurs throughout the project life cycle.
Team formation and development tends to follow a commonly observed dynamic in which performance improves as
trust increases and conflict among team members decreases.
On an increasing scale of team cohesion, the phases through which the team members progress in this process are
referred to as:
Form – the initial stage of team development in which team members are unsure of their peers, are relatively
reserved or guarded about expressing their opinions and views, relationships have not yet been established
and the team needs a high degree of direction in order to function;
Storm – in which team members are actively establishing their position in the team, are openly expressing
their views, will challenge and confront other viewpoints and will try to influence and shape the direction of the
team to suit their own agendas.
Norm – in which differences and conflicts between team members are being resolved or accommodated,
effective relationships are becoming more established and individual agendas are increasingly focused on
meeting the needs of the project.
Perform – in which trust between team members guides action, individual performance is enhanced and
supported by strong cohesion, the team is self-directed and requires a minimum of support from the project
management team and it is completely focused on meeting the goals of the project;
 Project Management Professional (PMP)

Adjourn – during the closing stages of the project, in which team members are moving on to new projects or
returning to their functional department and may be reluctant to leave or sever relationships with the team.

Project managers in particular, but also project management team members, need to develop and apply their own
general management skills to help reduce problems and increase cooperation. These soft skills include:
Empathy – the ability to step into another team member’s shoes, not just to see their perspective on an
issue or problem, but to “understand with feeling” what the issue or problem really means to that team
member.
Influence – the ability to achieve a desired outcome or state in the mind of a project participant, without
having to give explicit direction or exert overt pressure to achieve that result.
Creativity – the ability to find solutions to problems using available resources in imaginative or ingenious
ways.
Group facilitation – comprises various interpersonal techniques that are used to mediate the
contributions of individuals to ensure balanced and full participation in team activities by each individual.

9.4 Manage Project Team

[Page 215, Figure 9-9. Manage Project Team: Inputs, Tools & Techniques, and Output]

Managing the project team is a continuous process that involves

monitoring the performance of team members;
providing active feedback to team members on their performance;
resolving issues among team members; and
coordinating changes that may impact the team to enhance project performance.

The power that project managers exert derives from a combination of the limits of their influence and the level of their
authority. There are five commonly recognized sources for this power. These are:
Reward – in which bonus, promotion and other incentives are used to encourage positive behaviors that
enhance project performance;
Expert – in which knowledge and expertise (technical or specialist) are used to establish credibility and build
confidence among team members in the leadership abilities of the project manager.
Referent – in which reference to the authority of someone in a higher position or via association is used to
establish leadership. Such reference may also be based on personality or knowledge;
Penalty (or Coercive) – in which rewards are withheld or actions are penalized on the basis of non-
performance, usually via formal disciplinary procedures. In all cases, the objective of these actions is to
correct negative behaviors that impair or disrupt project performance; and
Legitimate (or Formal) – in which the leadership of the project manager is officially recognized by the
performing organization. The level of authority exerted is based on a hierarchical position.
 Project Management Professional (PMP)

Conflict can arise in many areas of the project. The main sources of conflict are:
Schedule – created by the tension between the desire to complete project tasks according to an idealized
timetable, and the performance of those tasks according to the constraints of the actual project
environment;
Priority – divergent or conflicting views on the order of accomplishment of the project activities, or
between one project assuming (or being assigned) precedence over another;
Resource – lack of availability or access to the right kind of resources to perform project tasks; and
Technical viewpoint – divergent opinions regarding the best way to perform project activities, especially
those involving alternative choices over technology decisions.

The project’s schedule will be impacted due to lack of required resource at the planned time. As a result, the project
may be forced to revisit technical decisions based on availability of those technical specialists. If those resources are
critical to the project’s deliverables, then they may need to be acquired externally, requiring unbudgeted funding. Note
how each one of these sources compounds and intensifies conflict within the project environment. Other sources of
conflict may include:
Administrative – which involves not being able to successfully navigate or understand how the
performing organization’s business processes operate (perceived negatively as bureaucracy or red tape);
Cost – which may arise in relation to overspend on budgeted or unbudgeted activities, or contention over
limited funds; and
Personality – in which personal styles and preferences become a barrier to effective working
relationships.

Conflict between project staff should always be resolved by those staff directly involved in the conflict, because conflict
resolution is a collaborative process. Ultimately, the staff affected must resolve and reconcile any difficulties
themselves, in order for the source of the conflict to be acknowledged and addressed. Without the involvement and
commitment of all parties involved, the root causes of the conflict will not be identified and resolved.
Approaches to dealing with conflict may vary according to management style and personal preference, but there are
six commonly recognized approaches. These are:
Avoidance (or withdrawing) – in which management ignores the conflict, and the problem continues
unresolved;
Accommodation (or smoothing) – in which common ground between the protagonists is identified by
emphasizing those areas on which there is agreement, but does not address areas of disagreement. The
source of the conflict is deemphasized but is not resolved;
Compromise (or bargaining) – in which the protagonists negotiate over the issues causing conflict, and jointly
arrive at a win-win position by giving something up in return for gaining something.
Forcing (or dictating) – in which a specific solution to the conflict is imposed on the protagonists. One party
usually gains more than the other (win-lose). The source of the conflict is only partially addressed, and may
re-surface, but in a different form;
Collaboration (or consensus) – similar to compromise but more effective, because the multiple viewpoints of
the protagonists are acknowledged and accommodated within the solution. Collaborative solutions emphasize
working together, and this is a very effective way of resolving conflict; and
Confrontation (or problem solving) – in which the sources of the conflict are discussed and examined by the
protagonists in an open-minded dialogue. The root causes are identified and acknowledged, and alternative
solutions to the conflict are accepted. Confronting directly the root causes of the problem is the most effective
way of resolving conflict.
 Project Management Professional (PMP)

10. Project Communications Management

Communications comprises a substantial body of knowledge in itself that is outside the scope of the PMBOK.
However, as a minimum, you should be familiar with the following communications concepts:
Sender-receiver models – the mechanics of successful communication. This includes understanding the
dynamic of active feedback loops (between sender and receiver) and barriers to successful communication.
Choice of media – selecting the optimal form in which the message is sent to ensure that it is correctly
understood by the receiver. For communications to be successful, it is necessary to deliver the message in a
form appropriate to the nature of the content.
Writing style – selecting the appropriate components of written communication to ensure that the correct
message is delivered.
Presentation techniques – using a variety of techniques to enhance and assure that information is
interpreted in the correct manner.
Meeting management techniques – using a variety of techniques to ensure that group communications
among project participants contribute to the project’s purpose.

The five components are:

1. Encode – the process by which thoughts or ideas are translated into a public language (i.e., can be
commonly understood and transmitted to others);
2. Message – the output of the encoding process (i.e., the message to be transmitted);
3. Medium – the method used to carry the message from the sender to the receiver;
4. Noise – anything that may impede or distort the transmission of the message or the interpretation
(understanding) of the message by the receiver (for example, using excessive technical terminology
when communicating with a non-technical audience); and
5. Decode – the process by which encoding is reversed and the received message is translated back
into thoughts and ideas.

10.1 Communications Planning

The purpose of Communications Planning is to identify the information needs of stakeholders and determine the best
means by which the project will meet those communications needs (hence, the importance to the project manager of
understanding how communications work, and being adept at communications skills). Planning begins with an
analysis of the project’s communications requirements.
To a large extent, a project’s communications requirements are influenced and shaped by the project’s organizational
structure. Other factors influencing project communication requirements include:
External interfaces – to identify how the project will meet the communication needs of stakeholder groups
external to the performing project organization. For example, keeping local communities appraised of
construction work that may impact their environment;
Company and departmental organization charts – to identify how and where potential project resources are
organized by the performing project organization, including understanding the interactions between
departments and groups (as documented in methods of working or operational procedures);
Roles & responsibilities – to understand the functions and activities for which individuals and groups are
accountable for within the performing project organization;
 Project Management Professional (PMP)

Internal communications – to identify mandatory or other regularly required communications requirements

within the performing project organization, for example, monthly project status reports for the Project
Management Office;

Formula: n(n-1)/2 where n = number of stakeholders

If there are 10 project stakeholders, then the potential number of communications channels is 45. If you double the
number of stakeholders to 20, does the number of channels double? Increasing the number of stakeholders not only
increases the complexity of the communications channels numerically, but also increases how the communications
requirements of those additional stakeholders will be met. Identifying all of the project’s stakeholders is critical to
ensuring successful project communications.

10.2 Information Distribution

Information Distribution results from executing the Communications Management Plan, and is dependent on
competently exercising general communications skills, as well as the means by which project information is collected
and retrieved and the use of appropriate distribution channels and other mechanisms to disseminate project
information to stakeholders. Accuracy, completeness, timeliness and appositeness (“Am I using the best or right
communications method to provide information to this stakeholder?”) are key criteria when distributing project
information.

10.3 Performance Reporting

Performance Reporting is one of two Monitoring and Controlling processes within Project Communications
Management. Its purpose is to ensure that all stakeholders receive timely information about current project
performance relative to baseline planning information. Performance reports focus on how project resources are being
utilized to achieve project results and on any variances from forecast (planned) results. They provide stakeholders
with relevant information on the status of project deliverables in addition to scope, schedule, cost and quality, as well
as risk and procurement. Work Performance Information provides details on what has been achieved at the point in
time when performance measurements are taken, versus expected results at that same point in time (and as detailed
in the Performance measurement baseline that integrates scope, schedule, cost and quality). As a result of these
measurements, corrective actions may be recommended to bring project performance back into line with expected
results as documented in the Project Management Plan. Any consequent changes to project scope, cost estimates
(budget) or activity durations are raised and approved through the Integrated Change Control process.
Some typical performance report formats include:
Bar charts
S-curves
Histograms
Tabular

10.4 Manage Stakeholders

Before opening the PMBOK, a project manager should know that in order to influence project performance, he or she
must proactively manage the project’s stakeholders and their needs. The most important aspect of this process is
managing communications to satisfy stakeholder needs. Additionally, the project manager must actively address and
resolve all stakeholder issues that may threaten to impair or disrupt project performance. To do this effectively, the
project manager must be fully aware of the stakeholders’ goals, objectives and expectations with respect to the project.
These are identified, analyzed and documented in the Communications Management Plan.
 Project Management Professional (PMP)

11. Project Risk Management

“If it can go wrong, it will go wrong.” This is how many project managers view the threat from risks to the successful
outcome of their projects. Although risk generally has a negative connotation, it also has an upside that is often
neglected when performing risk management.

Definition: “Risk – An uncertain event or condition that, should it occur, has either a positive or a negative effect on
the project’s objectives”.
[Glossary, page 373.]

It is the uncertain characteristic of an event or condition that defines it as a risk, not the fact that it could have a
negative impact on the project. Risk management actually means managing uncertainty. The Risk Management
Knowledge Area processes focus on identifying and managing those aspects of the project where uncertainty is
highest. These aspects typically have the largest impact on project outcomes because they are unknown, and their
effect is uncertain. Risks include both threats and opportunities. Why would an opportunity be considered a risk? It
sounds like a good thing. An opportunity may be just as disruptive or challenging to the agreed project outcomes as a
threat. Just as a threat can distract and divert resources from focusing on achieving project objectives, so can an
opportunity. Risks can emanate from anywhere within the project environment, can result from more than one cause
and can have more than one impact on the project. Because of the inherent complexity in both the causes and effects
of risk events, a systematic and comprehensive approach to risk management is required that addresses:
the probability of the risk event (how likely is it to occur?);
the consequences or outcomes of the risk event (what will the cost to the project be?);
the causes or circumstances of the risk event (what will trigger it, and how will it become manifest?);
the response appropriate to the risk event (what actions are required if it occurs?);
the timeframe in which the risk event is likely to become manifest (when is it likely to occur?); and
the likelihood of repetition of the risk event (is it a one-time event or is it likely to recur?).

11.1 Risk Management Planning

[Page 242, Figure 11-3. Risk Management Planning: Inputs, Tools & Techniques, and Outputs]

The Risk Management Planning process establishes the specific approach to managing risk that the project will take.
It ensures that the approach taken:
aligns with the performing organization’s tolerance for risk;
provides a consistent and comprehensive basis for evaluating project risks; and
allocates time and resources to meet the requirements of risk management activities identified in the plan.
 Project Management Professional (PMP)

Risk management planning is an inclusive and collaborative process. This is usually facilitated via planning and
analysis meetings in which the project manager, project team and stakeholders create the framework for the risk
management plan. The Risk Management Plan describes the framework for how risk management will be performed
throughout the duration of the project, and covers:
Risk Categorization – defining which kind of categories and the criteria that will be used to identify, analyze
and assess the impact of risks to the project.
Roles and Responsibilities – describing who is responsible for which parts of the risk management activities;
Timing – identifying when risk management processes will be performed throughout the project, including
when risk management activities will be included in the project schedule;
Budgeting – identifying the resources and costs associated with the project’s risk management approach,
accounted for in the cost baseline;
Stakeholder tolerances – identifying the risk tolerance profile of each stakeholder, as revised by the risk
management planning process;
Methodologies – describing the tools, techniques and processes that will be used to manage risk;
Definition of Risk Probability and Impact – defining how probability and impact will be applied during the
Qualitative Risk Analysis process (see 11.3 Qualitative Risk Analysis)
Probability and Impact matrix – defining how risks will be prioritized according to their probability and impact
on the project’s objectives;
Tracking – describing how risk activities such as outputs and artifacts will be recorded and documented,
including lessons learned. Also included is reference to how risk management activities will be audited; and
Reports – describing the content and format of the Risk Register and project risk reports.

11.2 Risk Identification

[Page 246, Figure 11-6. Risk Identification: Inputs, Tools & Techniques, and Outputs]

A number of different techniques are used to gather information on potential risks. These include:
Delphi technique – in which ideas and opinions about potential risks are collected from experts, and a
consensus view on the risks is developed. The steps involved in this process are:
a questionnaire is circulated to the experts to solicit risk ideas;
responses are summarized and then circulated to the experts for review and comment; and
 Project Management Professional (PMP)

updated responses which are re-circulated for further review and comment.

Brainstorming – in which idea-generation is facilitated with the project team and relevant subject matter
experts to explore, uncover and identify areas of potential project risk.
Interviews – in which project participants, subject matter experts and stakeholders are interviewed to identify
project risks based on their experience.
SWOT (Strengths, Weaknesses, Opportunities, and Threats) analysis – in which potential risks are
identified by looking at each of the SWOT characteristics as they apply to the project.
Root Cause analysis– in which the underlying causes of risks are identified and analyzed. Causation
characteristics can be used to categorize similar risks and formulate responses.

Note that assumptions also need to be assessed as a source of risk. Why? Because the Project Management Team
must identify what the potential impact on the project might be if any assumption made during planning is subsequently
proved to be invalid.
Diagramming techniques are also used to identify how process flows, interactions, activity sequences and other project
interactions may give rise to risks. These include:
Cause and Effect Diagrams – also referred to as fishbone or Ishikawa diagrams; and
Flowcharting – also referred to as system or process flow charts.

Where else in the project would you use these techniques for problem identification? When performing quality control
(see pages 192-193). Influence Diagrams are also used to depict the relationships between variables that can
influence the outcome of events, processes or other interactions.
The output from the risk identification process is the project Risk Register. This is a component part of the project
management plan that is used as both an input and output in the subsequent Qualitative Risk Analysis, Quantitative
Risk Analysis, risk response planning and risk monitoring and control processes. The initial risk register provides:
An initial list of all risks identified from the risk identification techniques enumerated above;
A list of responses to those risks where risk identification also generated a potential response to that risk;
Any root causes that were identified during risk identification; and
Any updates to risk categories resulting from the list of risks identified.

11.3 Qualitative Risk Analysis

[Page 250, Figure 11-7. Qualitative Risk Analysis: Inputs, Tools & Techniques, and Outputs]

Qualitative Risk Analysis answers the question, “Where should we focus our attention?” when considering the order in
which risks should be addressed, by considering both the probability of occurrence and the magnitude of impact on the
project’s objectives. The objective of qualitative risk analysis is therefore to prioritize risks. The risks that present the
biggest threat to the project in terms of highest probability of occurrence and biggest impact to project objectives must
be addressed by the Project Management Team before risks with a lower probability and lower impact. Prioritizing
risks helps to focus resources and responsiveness to areas that may have the biggest impact on project performance
and objectives. It is a relatively quick and cost-effective way to rank risks. However, there is a degree of subjectivity in
the process that derives from the risk tolerance of the project team and the performing organization and, hence, it is a
qualitative assessment of risk.
 Project Management Professional (PMP)

The output from qualitative risk analysis is an updated Risk Register that provides:
Ranking – providing a relative ordering of the significance of the risks evaluated on the project. This
should include sufficient information about the risk event, and how it has been evaluated to enable
decisions about how to respond;
Categorization – identifying root causes or patterns of risk for further evaluation;
Trend analysis – noting any observed trends in risks events;
Low priority risk watchlist – identifying low probability and/or low impact risks that do not require
immediate attention but should be monitored by the project team;
Near term risk responses – identifying those risk events that require urgent attention by the project
management team; and
Additional analysis and response – identifying those risks that do not pose an immediate threat to the
project but require further evaluation.

11.4 Quantitative Risk Analysis

[Page 254, Figure 11-9. Quantitative Risk Analysis: Inputs, Tools & Techniques, and Outputs]

Quantitative Risk Analysis answers the question “What is the cost of this risk to the project?” The process takes the
prioritized list developed during Qualitative Risk Analysis and, focusing on those risks that have the highest impact,
assigns a numeric value that denotes the potential magnitude of the risk event’s consequences on project objectives.
Impact is primarily evaluated with respect to its effect on project cost and time, but may also include scope and quality.
The Quantitative Risk Analysis process should be repeated after Risk Response Planning and performed as a part of
Risk Monitoring and Control. Why? To determine if the probability or impact of risks events has changed, and if so, in
what ways (increasing or decreasing?).

The steps involved in Quantitative Risk Analysis are:

gather probability and impact data on the high priority risks identified;
apply sensitivity analysis to risks to identify risks that are likely to have the biggest impact on the project;
perform expected monetary value (EMV) analysis to determine what the cost to the project is of the risk
event;
perform decision tree analysis to determine alternative EMV and other consequences of the risk event
under different scenarios for that event; and
model the project outcomes (for cost and schedule) under repeated simulations using, for example, the
Monte Carlo technique, to derive a distribution of multiple outcomes.
 Project Management Professional (PMP)

11.5 Risk Response Planning

[Page 260, Figure 11-14. Risk Response Planning: Inputs, Tools & Techniques, and Outputs]

The objective of Risk Response Planning is to develop options that are appropriate to the specific risks faced, and to
identify actions that will reduce the threat of negative risks and enhance the opportunity of positive risks.
Effective risk response planning involves:
assigning ownership for each risk identified (the Risk Response Owner);
ensuring that the response is cost effective;
agreeing upon the response with all parties involved;
ensuring that the response is timely; and
confirming that the response is commensurate with the significance and potential impact of the risk to the
project.

The PMBOK identifies the seven most commonly used strategies for responding to risks. The first three strategies
address negative risks (or threats), the second three address positive risks (or opportunities) and the last strategy
listed can address either kind. Remember these for the exam. You must be able to understand how these strategies
are used to address project risk and to identify the appropriate response to either a negative or a positive risk event.
Mitigation (threat response) – in which either the probability and/or the impact of the risk event (and hence, its
consequences on project objectives) are reduced.
Avoidance (threat response) – in which the threat is eliminated by changing the circumstances that invite the
threat.
Transference (threat response) – in which ownership of the risk is transferred to a third party. Note that this
does not remove the threat. It is a means for engaging a third party in the management of a specific risk.
Enhancing (opportunity response) – in which the size of the opportunity is enhanced by increasing either the
probability and/or impact of the positive event. Like mitigation, enhancing is most effective where it is used to
exert influence over outcomes before they occur;
Sharing (opportunity response) – in which the ownership and rewards of the positive risk are shared with a
third party.
Exploitation (opportunity response) – in which the performing organization deliberately acts to enhance the
occurrence of the opportunity.
Acceptance (both threat & opportunity response) – in which the risks, either positive or negative, are accepted
by the performing organization.

Following risk response planning, updates to the Risk Register include:

prioritized list of risks on the basis of Qualitative and Quantitative Risk Analysis;
detailed descriptions of each risk, including causes and impact on project;
identified risk owners, assigned responsibilities for each risk;
agreed risk response plans or strategies;
identified actions to implement risk responses selected;
list of triggers (symptoms or warning signs) for each risk event;
contingency plans identified for specific risks, including triggers that will invoke such plans;
 Project Management Professional (PMP)

list of risks that have been accepted, either actively or passively

contingency reserves (time, cost) identified, that are commensurate with stakeholder risk tolerances and
the expected value of project risks;
fallback plans identified in the event that the primary response is ineffective;
list of residual risks that may persist after responses have been implemented; and
identified secondary risks that may arise in response to implementing a primary risk response

Contracting or other arrangements to transfer risk to a third party should also be established.

11.6 Risk Monitoring and Control

[Page 265, Figure 11-15. Risk Monitoring and Control: Inputs, Tools & Techniques, and Outputs]

Risk Monitoring and Control is a continuous and iterative process that is performed throughout the project as project
tasks are executed and work is completed. The variables and circumstances that influence risk, and upon which
project risk assessments (probability, impact, consequences, etc.) are made, must be constantly analyzed and
evaluated as work is performed to determine if and how the risk profile of the project has changed. Risk monitoring
and control is a proactive process that includes:
monitoring variances in work results to identify if risk factors are affecting outcomes;
analyzing trends in work results to identify if risk factors are causing an improvement or deterioration in
project performance (remember: risks can result in positive and negative outcomes);
verifying that project assumptions are still valid;
monitoring low level risks on the watchlist to ensure that they have not changed or increased in the
significance of their impact, requiring immediate attention;
monitoring risk response triggers for contingency plans;
checking if contingency reserves (cost, schedule) need to be modified in alignment with any changes to
the risk profile of the project;
reviewing risk responses after corrective actions have been taken (are the responses still applicable or
appropriate to the risks identified? If not, how should they be modified);
evaluating the effectiveness of risk responses executed, ensuring that they achieved the desired result as
planned in the response and did not create any new risks;
identifying new risks and responses as the project progresses and changes;
ensuring that the risk management policies and procedures defined in the risk management plan are being
followed and adhered to;
updating lessons learned and organizational process assets (for example, risk management templates) to
reflect actual results and experience of project risks;
monitoring residual risks;
reevaluating risks using qualitative and quantitative analysis;
running Monte Carlo analysis simulations to determine if the probability of delivering the project on time
and to budget has changed (has uncertainty increased or decreased?);
communicating the status of project risks to stakeholders;
executing contingency plans when triggers are invoked;
 Project Management Professional (PMP)

executing fallback plans if primary risk responses do not achieve the planned mitigation of the risk; and
executing workarounds in response to unexpected risk events. Note that unlike a contingency plan, a
workaround is an unplanned response to a risk event.

12. Project Procurement Management

What did you notice about the introductory summary of Project Procurement Management processes above? Read
through them again. Note that every process domain is represented except for Initiating (which is unique to Project
Integration Management). Which other project management process group (or groups) covers these four domains? If
you’ve already memorized these, you know that none of them do. Project Procurement Management is unique in so
far as all four domain processes are engaged, from start to finish, to enable the project team to acquire capability,
products, services, resource or work from an external party that the project cannot provide internally to meet project
objectives. These processes define the contract life-cycle. Procurement forms a project within the project. Any of the
required external elements can be contracted in by the project team. As we saw in the previous chapter on project risk
management, contracting may also be used to transfer risk or to share risks and rewards, both of which are strategies
for achieving project objectives. You may think you know what a contract is, but here is the PMBOK definition:

Definition: “A contract is a mutually binding agreement that obligates the seller to provide the specified product or
service or result and obligates the buyer to pay for it.” [Glossary, page 355.]

From the contracting entities’ perspective, this concept is very important. A contract provides legal remedy in the
event of non-performance by either party, if the seller fails to deliver or the buyer refuses to pay. Project work or even
completed projects that are performed under contract need to be specified in detail to prevent misunderstanding about
performance. Contracts are a tool for managing both parties’ expectations about performance. Because of this, the
development of the contracting relationship and of the contract itself must be:
formal – systematically and accurately documented, and subject to extensive commercial and legal review
and approval;
specific – the contract must be sufficiently detailed to ensure that there is no ambiguity about what meeting
the terms of the contract means (for both parties);
time-bound – the contract should refer not only to how the terms of the contract will be met (the products,
services, results or other deliverables), but also when they will be met. Contracts incorporate schedules
specifically for this purpose, to ensure that milestones are being met. For lengthy projects, the contract
may make a provision for mutual renewal on, for example, a specified anniversary date, at which point
performance may be reviewed and the contract terminated (according to the termination process
documented in the contract); and
managed – changes to the contract terms of conditions must be reviewed, approved, and administered
according to formally agreed change control processes and procedures.

12.1 Plan Purchases and Acquisitions

[Page 274, Figure 12-3. Plan Purchases and Acquisitions: Inputs, Tools & Techniques, and Outputs]

The objectives of the Plan Purchases and Acquisitions process are to determine which project needs can be best met
internally by the performing organization and which needs can be best met by an external third party. Additionally,
having identified what products, services or other work is to be acquired externally, the most appropriate contracting
arrangements to do this must be selected.
 Project Management Professional (PMP)

You should familiarize yourself with these contract types, understand their characteristics (advantages and
disadvantages to seller or buyer), and be able to distinguish whether the seller or the buyer is assuming the most risk
when choosing between different types of contract.
Fixed Price (FP) (also known as firm fixed price (FFP) or lump sum (LP)):
seller carries most risk (cost of work can increase);
strong focus on controlling scope (to contain and manage costs);
seller requires detailed scope specification;
seller may price risk into the cost of performing the work (contingency against scope creep);
used by risk-averse buyers to cap costs; and
purchase order is the most common form of this contracting arrangement.
Fixed Price Incentive (FPI):
reduction in risk assumed by the seller;
seller requires detailed scope specification;
same as FP but includes incentives to the seller for meeting schedule and cost targets (for example, early
completion or reduction in costs); and
uses a ceiling price in the contract formula which represents the point of total assumption. This is the point
after which the seller assumes all responsibility for increasing costs (this is the incentive mechanism to cap
costs);
Cost Plus Incentive Fee (CPIF):
some risk sharing between seller and buyer;
specified costs are reimbursable to the seller;
a bonus (incentive fee) is paid to the seller for meeting performance targets (usually based on cost
reduction);
contract specifies formula to be used to calculate bonus and sharing of cost savings (seller component
may include a fixed or capped fee); and
scope focuses more on performance of the work rather than on the technical aspects (which is what the
buyer is purchasing from the seller).
Cost Plus Fixed Fee (CPFF):
risk more evenly balanced between seller and buyer;
seller is reimbursed allowable project costs;
seller receives a fixed fee payment (based on a percentage of costs); and
fixed fee is tied to project scope (fee does not change unless there is an approved change of scope or the
incentive is on the seller to control costs).
Time & Materials (T&M):
more risk carried by buyer;
combines elements of both cost reimbursable and fixed price contracts;
scope can be simply defined (usually repetitive work activities or tasks);
T&M based on a fixed per unit (or per hour) cost, but duration is indeterminate;
total cost (to buyer) is unknown;
 Project Management Professional (PMP)

potentially open-ended unless expected effort (duration) or output (unit quantities) are well defined by the
buyer before work commences; and
most cost effective for repetitive, well defined tasks of short duration (for example, filling a gap in human
resources to cover absence).
Cost Plus Percentage Cost (CPPC) (also known as cost plus percentage of cost (CPPC)):
buyer carries most risk;
favored by risk averse sellers;
costs are reimbursed to seller for performing contract work;
fixed fee is payable by the buyer, calculated as a percentage of the estimated project costs. Percentage
formula is defined in the terms of the contract;
the actual fee varies with actual costs (thus, the seller has little vested interest in controlling costs);
used when the scope is indeterminate and the buyer is willing to pay for a solution whose benefit may
accrue in the future. For example, developing intellectual property the rights to which become the property
of the buyer when the contract is completed; and
cannot contract with the federal government using this type of contract.

12.2 Plan Contracting

[Page 281, Figure 12-4. Plan Contracting: Inputs, Tools & Techniques, and Outputs]

The objective of the Plan Contracting process is to prepare the documents that will be used in the Request Seller
Responses and Select Sellers processes. Templates and standard forms from previous procurement life cycles are
used as the basis for the Procurement Documents that will be used to solicit proposals from prospective sellers.
Terminology for the solicitation documents varies by application area and by usage. A distinction can be made,
however, between soliciting bids on the basis of price (or cost) and on the basis of technical approach. “Proposal” is a
generic term that is generally used for the latter, while such terms as “tender,” “quotation,” or “bid,” tend to be used to
denote the former. In general, however, there is no strict usage and the content of the procurement document should
be clear about what is being solicited and the basis of the solicitation.
Some common types of procurement documents include:
Request for Proposal (RFP)
Invitation for Bid (IFB)
Request for Information (RFI)
Request for Quote (or Quotation) (RFQ)
Tender Bid (TB),
Etc.

Whichever format or type is selected, the procurement document should contain:

a clear and unambiguous scope statement, including an explicit statement about what is not in scope,
which will help manage seller expectations once the contract is awarded;
a response format for how the prospective seller is to respond;
the timeframe for responses to be received by the buyer from prospective sellers;
 Project Management Professional (PMP)

any contracting provisions will be made in the contract, for example, non-disclosure agreements, payment
cycles, etc.;
the constraints the contracted work will be subject to, for example, pipelines can only be laid during the
spring and summer;
the selection criteria that will be used to identify the prospective sellers and award the contract;
details about any bidder conferences that may be conducted by the buyer, including formats for presenting
information at the conference;
details about any due diligence to be performed by the buyer to verify the seller’s technical competency;
and
details about the level of financial disclosure required of the seller to prove financial capability.

12.3 Request Seller Responses

[Page 284, Figure 12-5. Request Seller Responses: Inputs, Tools & Techniques, and Outputs]

Solicitation of seller proposals is conducted by the Request Seller Responses process. Advertising in newspapers or
in specialist trade, industry or other publications (“Invitation for Bids”) is used to solicit proposals. This is a common
method used for government tenders. The advertisements provide summary information about the scope of the work,
a tender reference number and contact details for further information. Alternatively, a Qualified Sellers List is created
by the project management team from a variety of sources. This is usually based on in-house lists of previous sellers
with which the buyer’s organization may have previously contracted on similar work or similar projects, and can be
supplemented with other qualified contact sources, such as company directories, trade association membership lists,
etc. Bidder Conferences are also held with prospective sellers to help them prepare proposals. This provides a forum
for prospective sellers to meet with the buyer, to share information, clarify requirements and to answer any seller
questions. As a result, procurement documents may be updated to incorporate additional information collected during
the conferences, and re-circulated to all bidders to ensure a level playing field in the proposals submitted to the buyer.
Sellers respond with their proposals. Proposals must provide information in the format and as requested in the seller’s
procurement document. They need to be able to demonstrate that, should the contract be awarded to the prospective
seller, that they can meet all of the contract requirements. This is an important consideration when selecting the seller.
A seller may have the technical capability and the financial resource to meet the requirements, but if its management
approach is weak or is not congruent with the management approach of the buyer’s performing organization, it may
not be able to operate efficiently to deliver against the buyer’s schedule, for example.

12.4 Select Sellers

[Page 287, Figure 12-6. Select Sellers: Inputs, Tools & Techniques, and Outputs]

A contract is a two-way relationship. Although the Select Sellers process emphasizes the fact that it is the buyer who
selects the seller, you need to be aware that the seller, in some sense, also selects the buyer when presenting
themselves as a prospective contractor. If the seller misunderstands the expectations of the buyer, or vice versa, then
the outcome for both parties will be unsatisfactory and the (legal) consequences may be costly. How the selection
process is conducted, therefore, is important to assuring the satisfactory completion of the work to be performed under
contract.
 Project Management Professional (PMP)

Initial evaluation of the proposals submitted by the sellers may establish a

short list of qualified suppliers, who the buyer may then wish to interview
further. This meeting can, in turn, lead to more detailed negotiations until a
winning bid is finally selected from among the competing sellers by the
buyer. Whichever process is used, the procurement documents must be
very clear on how the final selection will be made. If there are preferred
bidders from the solicitation process, the buyer must be explicit about this.
As with personal relationships, trust is important to a successful contracting
relationship (and is especially so when disputes arise between contracting
parties). Although trust cannot be legally mandated in the contract, such
elements as transparency, openness and fair dealing during the selection
process will help to promote a productive contracting relationship.

All proposals submitted are reviewed against the criteria listed in the
procurement documents. Proposals may be screened to ensure that they
meet the minimum requirements for performing the work. As part of the
screening process, an initial ranking of the best qualified bidders may be
established. A scoring and weighing system can be used to quantify the
extent to which each bidder satisfies the selection criteria. The result of each
criterion is scored (weighted numerically), and is then combined with other
scores via multiplication to derive an overall score. Most scoring systems
are qualitatively based, representing a degree of subjectivity that
emphasizes the importance to the buyer of each of the criteria. These
mainly focus on performance characteristics (budget, technical capability,
schedule, risk management, etc.). Weighting converts these qualitative
assessments into a quantitative measure. Results may also be validated
with reference to independent estimates, for example, comparing the seller
costs submitted to estimates (and actual costs) for similar work performed in
the past. Expert judgment is also used as part of the proposal review
process to ensure the right level of competent scrutiny and specialist
knowledge is applied. The past performance of sellers can also be
evaluated using a seller rating system. This information should be available
to the project team from performance and other data collected and archived
during Contract Administration on previous projects (page 295). A part of
this process, in which the seller actively participates as a selector, is during
contract negotiation. The structure and terms and conditions of the final
contract (the binding agreement that is to be signed by both parties) are
mutually agreed upon by the seller and the buyer. There is a substantial
body of guidance and opinion on the art of negotiating. A successful
outcome to negotiation is a win-win situation for both parties. This is
important from a seller motivation perspective: the buyer wants and needs
the seller to perform the work to completely meet all requirements.

The select seller process ends with the contract award. The form, scope,
structure and content of the final contract will be determined by the specific
circumstances of the work to be contracted. Complex requirements will need
to be specified to a much greater level of detail than simple requirements
(page 289). How the contract is to be administered also needs to be agreed
upon and documented before any work can commence. Note that the
contract management plan is a subsidiary or component plan of the project
management plan.
 Project Management Professional (PMP)

12.5 Contract Administration

[Page 290, Figure 12-7. Contract Administration: Inputs, Tools & Techniques, and Outputs]

The processes involved in Contract Administration ensure that the contractual obligations of both parties to the signed
contract are being met. This means that the seller is performing to meet the contractual requirements of the buyer
and, in return, the seller is receiving the agreed consideration (usually in the form of monetary payments) from the
buyer for meeting those performance requirements. Contract administration also ensures that the legal rights of the
contracting parties are being observed and met.
Contract Administration is comprised of the following activities:
Performance review – in which the buyer reviews the performance of the seller to ensure that work is being
performed as specified in the contract SOW and to meet the agreed budget, schedule and quality parameters
of the project work.
Change Control - The contract must be maintained and updated according to a formal change control
process, as agreed by both seller and buyer and as defined in the project procurement management plan. All
authorized changes are applied to the contract;
Performance reporting – in which information about the performance of the seller in meeting the contract
work objectives is collected and evaluated. Project performance measures, such as EVM, may be applied;
Seller payment – in which payments are made to the seller according to the agreed contract terms.
Audits – or inspections, may be conducted by the buyer, and as agreed with the seller, to ensure that the
seller’s work processes and deliverables continue to meet the buyer’s requirements and are in conformance
with the representations made by the seller during the solicitation and bidding phases of the contract life cycle;
Record administration – provides for the systems, processes and procedures required to manage,
administer, archive and retrieve contract and related documents, such as correspondence.
Claims administration – involves those processes required to document, process and archive claims arising
from disputes between the seller and the buyer.

12.6 Contract Closure

[Page 296, Figure 12-8. Contract Closure: Inputs, Tools & Techniques, and Outputs]

Closing out the contract is an input to the Close Project process (see section 4.7). Close out occurs when either the
contract work is completed or when the contract is terminated early, prior to completion of the contract work. In either
case, the same process is applied. Just as the contract specifies how disputes will be resolved, so it also identifies the
conditions under which early termination can take place and how early termination will be performed. As well as
providing for administrative closure (the payment of final invoices, archiving of documents, etc.), contract closure
documents the final state of the deliverables that were created by the work under contract. In early termination, the
same applies: deliverables are documented, to the fullest extent possible, in the state that they had achieved when
termination occurred. Why is that important? Because product verification is a part of customer (that is, buyer)
acceptance of the deliverables, and payment will only be made to the seller for those parts of the scope of work that
have been satisfied. Note that early termination can occur either by mutual consent of the contracting parties, or if one
of the parties is in default (a failure to fulfill an obligation of the contract). Even in cases where the contract is
completed and contract closure has occurred, contested claims can still arise, especially if there is a final lump sum
paid by the buyer which is less than the seller anticipated. Note that administrative closure cannot occur after the
contract has been closed out.
 Project Management Professional (PMP)

Professional and Social Responsibility

The PMBOK Guide does not address Professional and Social Responsibility, although the PMP exam will test you on
this. You should read and understand the PMI’s PMP Code of Professional Conduct before you take the exam.
The code describes the professional standards that are expected of a project manager.

Professional and social responsibility covers four areas. The project manager should:
ensure individual integrity and professionalism;
contribute to the project management knowledge base;
enhance individual professional competence; and
promote interaction among and balance stakeholders’ interests.

A project manager should act in confidence on behalf of their client and respect confidentiality. If the project manager
cannot resolve a conflict of interest, then they should avoid it. Why? Because it will compromise project performance.
Look at the PMBOK processes. Their aim is to promote transparency, clarity and objectivity in performing project
work. Likewise, similar ethical qualities in the project manager, such as truthfulness, reinforce the successful
execution of these processes.