ERRATA

A Guide to the Project Management Body of Knowledge

(PMBOK® Guide) – Sixth Edition
(Fifth Printing)

NOTE: This errata contains a list of the notable corrections that have been made since the
fourth printing of the PMBOK® Guide – Sixth Edition. In order to verify the print run of your
book (or PDF), refer to the bottom of the copyright page. The last numeral in the string
beginning with “10 9 8” etc., denotes the printing of that particular copy. Copies of the
corrected pages are attached for convenience.

Part 1: A Guide to the Project Management Body of Knowledge (PMBOK® Guide)

Page Correction
113 Figure 4-12. Added bullet under .2 Project documents for Change log.
114 Figure 4-13. (1) Added bullet under input .2 Project documents for Change log;
(2) Added process box for 6.5 Develop Schedule with the input Change requests.
116 Section 4.6.1.2. Added following bullet under Project documents:
● Change log. Described in Section 4.6.3.3. The change log is used to record all
submitted change requests.
190 Section 6.3.2.1. Revised first sentence of Start to finish (SF) bullet to read:
A logical relationship in which a predecessor cannot finish until a successor
activity has started.
426 Figure 11-10. Changed x-axis to read “high” on left side and “low” on right side.
438 Figure 11-17. Changed bullet under Project Documents from Resource
breakdown structure to Project team assignments.
4.5.3.4 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:
Cost forecasts. Described in Section 7.4.3.2. Changes in cost forecasts resulting from this process are recorded
uu
using cost management processes.
Issue log. Described in Section 4.3.3.3. New issues raised as a result of this process are recorded in the
uu
issue log.
Lessons learned register. Described in Section 4.4.3.1. The lessons learned register is updated with effective
uu
responses for variances and corrective and preventive actions.
Risk register. Described in Section 11.2.3.1. New risks identified during this process are recorded in the risk
uu
register and managed using the risk management processes.
Schedule forecasts. Described in Section 6.6.3.2. Changes in schedule forecasts resulting from this process are
uu
recorded using schedule management processes.

4.6 PERFORM INTEGRATED CHANGE CONTROL

Perform Integrated Change Control is the process of reviewing all change requests; approving changes and managing
changes to deliverables, project documents, and the project management plan; and communicating the decisions.
This process reviews all requests for changes to project documents, deliverables, or the project management plan
and determines the resolution of the change requests. The key benefit of this process is that it allows for documented
changes within the project to be considered in an integrated manner while addressing overall project risk, which often
arises from changes made without consideration of the overall project objectives or plans. This process is performed
throughout the project. The inputs, tools and techniques, and outputs of the process are depicted in Figure 4-12. Figure
4-13 depicts the data flow diagram for the process.

Perform Integrated Change Control

Inputs Tools & Techniques Outputs

.1 Project management plan .1 Expert judgment .1 Approved change requests
• Change management plan .2 Change control tools .2 Project management plan
• Configuration management .3 Data analysis updates
plan • Alternatives analysis • Any component
• Scope baseline • Cost-benefit analysis .3 Project documents updates
• Schedule baseline .4 Decision making • Change log
• Cost baseline • Voting
.2 Project documents • Autocratic decision making
• Basis of estimates • Multicriteria decision
• Change log analysis
• Requirements traceability .5 Meetings
matrix
• Risk report
.3 Work performance reports
.4 Change requests
.5 Enterprise environmental
factors
.6 Organizational process assets

Figure 4-12. Perform Integrated Change Control: Inputs, Tools & Techniques, and Outputs

113
 Project Enterprise/ 4.3
Management Organization Direct and
Plan Manage
• Approved change requests Project Work
• Enterprise
environmental
Project management plan factors
• Change management plan • Organizational
• Configuration management plan process assets 8.3
• Scope baseline Control
• Schedule baseline • Approved change requests Quality
• Cost baseline

Project 12.3
Documents Control
• Approved change requests Procurements

Project documents
• Basis of estimates
• Change log Project
• Requirements traceability matrix
• Risk report
Management
Project management Plan
4.6 plan updates
4.5 • Any component
Monitor and Perform
Control Integrated
• Project
Project Work Change Control
charter
Project
• Work performance reports Documents
• Change requests Project documents updates
• Change log
• Change requests

4.3
Direct and 6.6 9.4 11.6 13.1
Manage Control Develop Implement Risk Identify
Project Work Schedule Team Responses Stakeholders

13.3
5.5 7.4. 9.5 11.7 Manage
Validate Control Manage Monitor Stakeholder
Scope Costs Team Risks Engagement

13.4
5.6. 8.2 9.6 12.1 Monitor
Control Manage Control Plan Procurement Stakeholder
Scope Quality Resources Management Engagement

6.2 8.3 10.3 12.2

Define Control Monitor Conduct
Activities Quality Communications Procurements

6.5 9.3 11.5 12.3

Develop Acquire Plan Risk Control
Schedule Resources Responses Procurements

Figure 4-13. Perform Integrated Change Control: Data Flow Diagram

114 Part 1 - Guide

4.6.1 PERFORM INTEGRATED CHANGE CONTROL: INPUTS

4.6.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to:
Change management plan. Described in Section 4.2.3.1. The change management plan provides the direction
uu
for managing the change control process and documents the roles and responsibilities of the change control
board (CCB).
Configuration management plan. Described in Section 4.2.3.1. The configuration management plan describes
uu
the configurable items of the project and identifies the items that will be recorded and updated so that the
product of the project remains consistent and operable.
Scope baseline. Described in Section 5.4.3.1. The scope baseline provides the project and product definition.
uu

Schedule baseline. Described in Section 6.5.3.1. The schedule baseline is used to assess the impact of the
uu
changes in the project schedule.
Cost baseline. Described in Section 7.3.3.1. The cost baseline is used to assess the impact of the changes to
uu
the project cost.

4.6.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:
Basis of estimates. Described in Section 6.4.3.2. Basis of estimates indicate how the duration, cost, and
uu
resources estimates were derived and can be used to calculate the impact of the change in time, budget, and
resources.
Change log. Described in Section 6.4.3.3. The change log is used to record all submitted change requests.
uu

Requirements traceability matrix. Described in Section 5.2.3.2. The requirements traceability matrix helps
uu
assess the impact of the change on the project scope.
Risk report. Described in Section 11.2.3.2. The risk report presents information on sources of overall and
uu
individual project risks involved by the change requested.

4.6.1.3 WORK PERFORMANCE REPORTS

Described in Section 4.5.3.1. Work performance reports of particular interest to the Perform Integrated Change Control
process include resource availability, schedule and cost data, earned value reports, and burnup or burndown charts.

116 Part 1 - Guide

 Finish-to-start (FS). A logical relationship in which a successor activity cannot start until a predecessor activity
uu
has finished. For example, installing the operating system on a PC (successor) cannot start until the PC hardware
is assembled (predecessor).
Finish-to-finish (FF). A logical relationship in which a successor activity cannot finish until a predecessor activity
uu
has finished. For example, writing a document (predecessor) is required to finish before editing the document
(successor) can finish.
Start-to-start (SS). A logical relationship in which a successor activity cannot start until a predecessor activity
uu
has started. For example, level concrete (successor) cannot begin until pour foundation (predecessor) begins.
Start-to-finish (SF). A logical relationship in which a predecessor activity cannot finish until a successor activity
uu
has started. For example, a new accounts payable system (successor) has to start before the old accounts payable
system can be shut down (predecessor).
In PDM, FS is the most commonly used type of precedence relationship. The SF relationship is very rarely used, but
is included to present a complete list of the PDM relationship types.
Two activities can have two logical relationships at the same time (for example, SS and FF). Multiple relationships
between the same activities are not recommended, so a decision has to be made to select the relationship with the
highest impact. Closed loops are also not recommended in logical relationships.

Finish to Start (FS)

Activity A Activity B

Activity A Activity A

Start to Start (SS) Finish to Finish (FF)

Activity B Activity B

Start to Finish (SF)

Activity A Activity B

Figure 6-9. Precedence Diagramming Method (PDM) Relationship Types

190 Part 1 - Guide

 Bubble size = Impact Value

High
Large
bubbles
in this
area are
unacceptable
Proximity

Low

High Low

Small bubbles Detectability

in this area are
acceptable

Figure 11-10. Example Bubble Chart Showing Detectability, Proximity, and Impact Value

11.3.2.7 MEETINGS

To undertake qualitative risk analysis, the project team may conduct a specialized meeting (often called a risk
workshop) dedicated to the discussion of identified individual project risks. The goals of this meeting include the review
of previously identified risks, assessment of probability and impacts (and possibly other risk parameters), categorization,
and prioritization. A risk owner, who will be responsible for planning an appropriate risk response and for reporting
progress on managing the risk, will be allocated to each individual project risk as part of the Perform Qualitative Risk
Analysis process. The meeting may start by reviewing and confirming the probability and impact scales to be used for
the analysis. The meeting may also identify additional risks during the discussion, and these should be recorded for
analysis. Use of a skilled facilitator will increase the effectiveness of the meeting.

426 Part 1 - Guide

 Project
Management
Plan
4.6
Perform
Project management plan Integrated
• Resource management plan • Change requests Change Control
• Risk management plan
• Cost baseline

11.5 Project
Project Plan Risk Management
Documents Responses
• Project Plan
Project management
charter plan updates
• Schedule management plan
Project documents • Cost management plan
• Lessons learned register • Quality management plan
• Project schedule • Resource management plan
• Project team assignments • Procurement management plan
• Resource calendars • Scope baseline
• Risk register • Schedule baseline
• Risk report • Cost baseline
• Stakeholder register
Project
Documents
Project documents updates
• Assumption log
Enterprise/ • Cost forecasts
Organization • Lessons learned register
• Project schedule
• Project team assignments
• Enterprise environmental factors • Risk register
• Organizational process assets • Risk report

Figure 11-17. Plan Risk Responses: Data Flow Diagram

438 Part 1 - Guide