Project Management Processes

PMBOK 8th Edition

[Link] [Link]
[Link] [Link]
 Initiate Project or
Phase
• The process of developing a document
to formally authorize a project or a
phase
• Outlines the project objectives
• Defines the authority of the project
manager
• Provides the project manager with the
authority to put the resources together
to project activities
• The approved project charter formally
initiates the project

[Link] [Link]
 Initiate Project or
Phase

[Link] [Link]
 Initiate Project or
Phase Inputs
• Business Documents - Contain specific
information as to why a project
should be initiated.
• There are two main documents the
business case and the benefits
management plan.
• Business Case - Necessary information
that determines whether or not the
project is worth the required
investment
• Market Demand, Customer
Request, Organizational Need,
Legal requirement
• Project Benefits Management Plan
• Describes the main benefits that the
project will produce once it is
completed and how to measure the
benefits. The project benefit could be
the product, service, or result.
• It maybe created by doing a cost-
benefit analysis a project.

[Link] [Link]
 Initiate Project or
Phase Inputs

[Link] [Link]
 Initiate Project or
Phase Inputs
• Agreements
• Service Level Agreements (SLA)
• Letters of intent
• Contract between internal and
external customer
• Work required to be
performed for Payment
• Enterprise Environmental
Factors
• Organizational Processes
Assets

[Link] [Link]
 Initiate Project or
Phase Tools
• Expert judgment
• Data gathering
• Brainstorming
• Focus groups
• Interviews
• Interpersonal and team
skills
• Conflict management
• Facilitation
• Meeting management
• Meetings

[Link] [Link]
 Initiate Project or
Phase Tools
• Responsibility assignment matrix
• A Responsibility Assignment Matrix
(RAM) shows which resources are
assigned to specific work packages.
• A common example of a RAM is a
RACI chart.
• RACI stands for Responsible,
Accountable, Consulted, and
Informed.
• Responsible means the person doing
the work.
• Accountable means the person who
makes sure the work gets done.
• Consulted means the expert or
stakeholder who provides input, while
Informed means the person who
needs updates.
• There should be only one accountable
person for each work package to avoid
confusion and blame.

[Link] [Link]
 Initiate Project or
Phase Tools

[Link] [Link]
 Initiate Project or
Phase Tools
• Project canvas
• A project canvas is a visual
tool used to outline and
plan the key parts of a
project.
• It gives the project
manager and stakeholders
a quick, high-level view of
the project.
• Early in the project, the
canvas may be simple and
high level.
• As the project progresses,
the canvas can become
more detailed.

[Link] [Link]
 Initiate Project or
Phase Tools

[Link] [Link]
 Initiate Project or
Phase Output
• Output
• Project Charter
• Formally authorizes the
existence of the project and it
assigns the Project Manager
and their Authority Level
• Signed by the organization
Senior Management
• High Level requirements & risks
• Preliminary Project Budget and
Schedule
• Project Purpose or justification
• Assumption Log
• A list of things that you
perceive to be true
(assumptions) and things that
might constrain the project.

[Link] [Link]
 Identify
Stakeholders
• Identifies the people, groups, or
organizations that have a stake in the
project.
• It includes analyzing stakeholder
interests, involvement, influence,
interdependencies, and impact on
project success.
• The key benefit is helping the project
team decide how to engage each
stakeholder or stakeholder group.
• Stakeholder identification should happen
regularly, not just once at the beginning.
• Continuous stakeholder identification
can support risk management as the
project environment changes.
• This process is performed periodically
throughout the project as needed.

[Link] [Link]
 Identify
Stakeholders
ITTO

[Link] [Link]
 Identify
Stakeholders Inputs
• Project Charter
• Identifies the key stakeholder list, sponsor, and
customer as a starting point for further
identification.
• Business Documents
• Business case - identifies the project objectives
and stakeholders who care about the business
value.
• Benefits management plan - identifies
stakeholders who will receive the benefits and
who are responsible for tracking them.
• Project Management Plan
• Communications management plan - if it exists,
lists previously identified stakeholders and
their communication needs.
• Stakeholder engagement plan - documents
currently identified stakeholders and
engagement strategies.

[Link] [Link]
 Identify
Stakeholders Inputs
• Project Documents
• Change log - changes may introduce new
stakeholders or alter existing ones' roles.
• Issue log - issues often surface affected
stakeholders previously overlooked.
• Requirements documentation - identifies
stakeholders with requirements that must be
met.
• Agreements
• Vendor contracts and partnership agreements
identify external stakeholders with formal
roles.
• EEFs and OPAs
• Organizational culture, government regulations
(which may create regulatory stakeholders),
stakeholder registers from prior projects, and
lessons learned.

[Link] [Link]
 Identify
Stakeholders Tools
• Expert Judgment
• Specialists with knowledge of the political
environment, industry, technology, and prior
project stakeholder lists.
• Data Gathering
• Questionnaires and surveys - efficient way to
gather views from a large or dispersed group of
potential stakeholders.
• Brainstorming - team-based ideation to identify
any stakeholder who could affect or be affected by
the project.
• Data Analysis
• Stakeholder analysis - examines who the
stakeholders are and how they feel about the
project: their role (sponsor, team member,
customer, etc.), how the project affects them
(positively or negatively), whether they are active
or passive, and their power and authority.
• Document analysis - reviews existing documents
(charter, agreements, lessons learned) to identify
stakeholders.

[Link] [Link]
 Identify
Stakeholders
Tools
• Data Representation
• Stakeholder
Mapping/Representation
• Power/interest grid,
power/influence grid, or
impact/influence grid

[Link] [Link]
 Identify
Stakeholders
Tools
• Data Representation
• Stakeholder
Mapping/Representation
• Stakeholder cube
• A three-dimensional
methodology to
support the mapping
of a stakeholder’s
interest, power, and
influence

[Link] [Link]
 Identify
Stakeholders
Tools
• Data Representation
• Method to categorize
stakeholders.
• Salience model:
• Power: Level of authority
• Urgency: Immediate attention
• Legitimacy: How appropriate is
their involvement
• Directions of Influence:
• Upward: Senior management
• Downward: Team members
• Outward: Vendors, government,
public, end-users
• Sideward: peers such as other
project managers
• Prioritization

[Link] [Link]
 Identify Stakeholders
Output
• Stakeholder Register
• stakeholder register is a project
document that stores information
about project stakeholders.
• It includes details used to identify,
assess, and classify stakeholders.
• Identification information includes
name, role, organizational position,
location, and contact details.
• Assessment information includes
stakeholder requirements,
expectations, influence, and impact.
• It may also show which project phase
the stakeholder has the most
influence or impact.
• Stakeholder classification may
include internal/external,
power/interest, impact/influence, or
other models chosen by the project
manager.

[Link] [Link]
 Identify Stakeholders
Output
• Change Requests
• Identification of new stakeholders (or changes to
previously identified ones) may trigger change
requests to management plans or project
documents.
• Project Management Plan Updates
• Requirements management plan - new
stakeholders may have new requirements.
• Communications management plan - new
stakeholders need tailored communication.
• Risk management plan - new stakeholders may
introduce or affect risks.
• Stakeholder engagement plan - updated to include
the new stakeholders and their engagement
strategies.
• Project Document Updates
• Assumption log - assumptions about stakeholders
documented.
• Issue log - issues raised by or about stakeholders.
• Risk register - risks involving stakeholders
identified during analysis.

[Link] [Link]
 Planning
Focus Area
• 19 Processes across all 7
domains
• Creates the Project
Management plan and
project documents used to
execute, monitor and control
and close the project

[Link] [Link]
[Link] [Link]
 Integrate and Align
Project Plans
• The process of bringing together all
subsidiary management plans,
baselines, and supporting project
documents into a single, integrated
Project Management Plan
• Defines how the project will be
executed, monitored, controlled, and
closed
• The approved Project Management
Plan becomes the baseline against
which performance is measured
throughout the project

[Link] [Link]
 Integrate and Align
Project Plans - ITTO

[Link] [Link]
 Integrate and Align
Project Plans - Inputs
• Project Charter
• Provides the high-level project description, key
deliverables, and assumptions used as the starting
point for the PM Plan
• Defines the authority of the project manager and
the success criteria
• Outputs from Other Planning Processes
• All subsidiary management plans
• All baselines
• Enterprise Environmental Factors
• Organizational culture, infrastructure, regulations,
and PMIS
• Organizational Process Assets
• Standard templates, lessons learned, configuration
management knowledge bases

[Link] [Link]
 Integrate and Align
Project Plans - Tools
• Expert Judgment
• Input from people with specialized knowledge in
the relevant management domains (scope,
schedule, cost, risk, procurement, etc.)
• Data Gathering
• Brainstorming - to elicit ideas and approaches for
integrating plans
• Checklists - to confirm all required components of
the PM Plan are addressed
• Focus groups - to gather feedback on the
proposed approach
• Interviews - one-on-one with subject matter
experts and stakeholders

[Link] [Link]
 Integrate and Align
Project Plans - Tools
• Interpersonal and Team Skills
• Conflict management - to resolve competing
demands among management plans
• Facilitation - to drive consensus across plan
owners
• Meeting management - to keep planning
meetings focused and productive
• Meetings
• Planning workshops to integrate the subsidiary
plans
• Project canvas
• A visual tool used to outline and plan the key
parts of a project.

[Link] [Link]
 Integrate and Align Project
Plans - Output
• Project Management Plan
• The integrated, approved master document
that defines how the project is executed,
monitored, controlled, and closed
• Includes development approaches (predictive,
iterative, hybrid) for each major deliverable
• References all subsidiary management plans:
• Scope, Schedule, Cost, Quality, Resource,
Communications, Risk, Procurement,
Stakeholder Engagement
• Approved by the sponsor before execution
begins
• Predictive Projects: Once plan is approved, any
changes to any component will require an
approved change request.

[Link] [Link]
 Integrate and Align Project
Plans - Output
Common Project Management Plan
Components
Scope Management Plan
Requirement Management Plan
Schedule Management Plan
Financial Management Plan
Quality Management Plan
Resource Management Plan
Communication Management Plan
Risk Management Plan
Procurement Management Plan
Stakeholder Engagement Plan
Change Management Plan
Configuration Management Plan
Scope Baseline
Schedule Baseline
Cost Baseline
Performance Measurement Baseline
Sourcing strategy plan
Project Life Cycle Description
Development Approach
[Link] [Link]
 Plan Sourcing Strategy
• The process of determining how the
project will obtain the goods, services, and
resources needed to deliver project
objectives
• Decides what work will be performed in-
house and what will be outsourced to
external sellers
• Establishes the source-selection criteria
the project will use to evaluate and choose
vendors
• Documents the overall sourcing approach
in a sourcing strategy plan that informs
subsequent procurement planning
• Performed early in planning so that
schedule, cost, and resource plans can
reflect make-vs-buy decisions

[Link] [Link]
 Procurement Process
1. Identify procurement needs
• Determine what goods, services, or results
the project needs from outside sources
• Perform make-or-buy analysis
• Decide whether the project team should do the
work internally or buy it from an outside seller
2. Create procurement strategy
• Decide the best delivery method, contract
type, and procurement phases
3. Prepare procurement documents
• Create documents such as:
• SOW — Statement of Work
• RFI — Request for Information
• RFP — Request for Proposal
• RFQ — Request for Quote
• Simple example
• A company needs a new training website and
decides whether to build it internally or hire a
vendor

[Link] [Link]
 Procurement Process
4. Advertise the opportunity
• Let qualified sellers know about the work

5. Hold a bidder conference

• Answer vendor questions and make sure everyone receives the same
information

6. Receive proposals or quotes

• Sellers submit their responses based on the bid documents

7. Evaluate sellers
• Compare vendors based on cost, quality, experience, technical ability, delivery
dates, and other criteria

8. Select seller and negotiate contract

• Choose the best vendor and agree on cost, schedule, scope, payment terms,
and responsibilities

9. Monitor contract performance

• Make sure the seller delivers the work on time, within budget, and according
to the contract

10. Close procurement

• Confirm all work is completed, obligations are fulfilled, and there are no
outstanding issues

Simple example
• After reviewing vendor proposals, the company chooses the best website
developer, signs the contract, tracks progress, and closes the contract when
the website is delivered

[Link] [Link]
 Contracts
• Contracts explains how goods, services, or
results are acquired from vendors
• They affect project risk
• Different contracts shift risk between the buyer and
the seller
• They affect cost and payment
• Contracts decide how the seller will be paid and who
pays for overruns
• Project managers must understand both sides
• The goal is a win-win agreement
• Contracts should protect both parties
• Good contracts encourage fairness, performance, and
project success

[Link] [Link]
 Contract Types
• Fixed-Price Contract Price is agreed
upfront for a clearly defined scope
• Buyer gets budget certainty
• Seller has more cost risk
• Best when the work is well understood
• Example: A contractor agrees to build a training
room for $50,000
• Cost-Reimbursable Contract Buyer pays
the seller’s actual costs plus a fee/profit
• Good when scope is unclear or high risk
• Buyer has more cost risk
• Seller has less financial risk
• Example: A company hires a research team and
agrees to pay all approved costs plus a fixed fee

[Link] [Link]
 Contract Types
• Time and Materials Contract Buyer pays for
labor hours and materials used
• Mix of fixed-price and cost-reimbursable
• Flexible, but costs must be monitored closely
• Common for consulting, IT support, and maintenance
work
• Example: A consultant charges $150 per hour plus
software expenses
• Target-Cost Contract Buyer and seller agree on
a target cost
• Savings or overruns are shared based on an
agreement
• Encourages cost control and efficiency
• Useful for large or complex projects
• Example: If the target cost is $1 million and the
project finishes under budget, both buyer and seller
share the savings

[Link] [Link]
 Plan Sourcing Strategy
ITTO

[Link] [Link]
 Plan Sourcing Strategy -
Inputs
• Project Charter
• Provides the high-level project description, key
deliverables, and constraints that influence sourcing
decisions.
• Identifies the project sponsor and the PM's authority to
commit to vendor agreements.
• Project Management Plan
• Scope management plan - defines how scope will be
managed.
• Quality management plan - sets quality standards a
vendor must meet.
• Scope baseline - define the work to be procured.
• Schedule management plan - drives delivery dates and
milestones the vendor must hit.
• Financial management plan - cost controls applied to
procurements.
• Resource management plan - identifies internal
resource availability, which informs make-vs-buy
decisions.

[Link] [Link]
 Plan Sourcing Strategy -
Inputs
• Project Documents
• Milestone list - key dates the sourcing plan must
support.
• Requirements documentation - the detailed
requirements that the procured product or service must
satisfy.
• Requirements traceability matrix - links each
requirement back to a deliverable so vendor work can
be traced.
• Quality metrics - measurable criteria a deliverable must
meet, used in source selection criteria.
• Resource requirements - skills, materials, and
equipment needed; gaps drive sourcing.
• Project team assignments - who is already assigned,
highlighting where external help is needed.
• Risk register - risks that influence sourcing strategy (e.g.,
vendor concentration risk, single-source risk).
• Stakeholder register - identifies stakeholders with
influence over sourcing decisions (e.g., procurement,
legal, finance).

[Link] [Link]
 Plan Sourcing Strategy -
Inputs
• Enterprise Environmental Factors
(EEFs)
• Marketplace conditions, supplier
performance data, regulatory requirements,
and contracting policies that constrain or
enable sourcing options.
• Organizational Process Assets (OPAs)
• Pre-approved vendor lists, prior contracts,
lessons learned from prior procurements,
and standard templates used to build the
sourcing plan.

[Link] [Link]
 Plan Sourcing Strategy -
Tools
• Expert Judgment
• Input from individuals with specialized
knowledge in procurement, contracting,
the relevant industry, and regulatory
requirements.
• Market Research
• Examination of industry and specific
vendor capabilities to determine what is
available, at what cost, and under what
terms.
• Includes reviewing trade publications,
supplier conferences, and online reviews
to understand market trends.

[Link] [Link]
 Plan Sourcing Strategy -
Tools
• Make-or-Buy Analysis
• A technique used to determine whether particular
work can best be accomplished by the project
team (make) or purchased from outside sources
(buy).
• Considers cost, capability, capacity, schedule,
risk, and strategic value of keeping the work in-
house.
• Source Selection Analysis
• Reviews the methods used to evaluate and
select sellers, such as least cost, qualifications
only, quality-based, fixed budget, or best value.
• Document Analysis
• Reviews existing documents (charter,
requirements, prior contracts) to extract
information that informs the sourcing approach.

[Link] [Link]
 Plan Sourcing Strategy -
Outputs
• Procurement Management plan
• Component of the PM plan that describes how the
team will acquire goods and services from outside
the performing organization, including the type of
bidding (international, national, local)
• Sourcing strategy plan
• Component of the PM plan that defines what work
will be insourced vs outsourced, with rationale tied to
value, schedule, risk, and cost
• Tailored to the project: can be formal or informal,
detailed or high-level, and may or may not include
procurement specifics
• Also include determining the type of contract to be
used on the project
• Two key components: insourcing/outsourcing
decisions and source selection criteria

[Link] [Link]
 Plan Scope Management
• The process of creating a scope management
plan that documents how the project and
product scope will be defined, validated, and
controlled
• Establishes how the requirements will be
elicited, analyzed, and documented through
the requirements management plan
• Defines how the WBS will be created
• Specifies how formal acceptance of
completed deliverables will be obtained and
how scope changes will be processed
• Provides guidance and direction on how
scope will be managed throughout the
project life cycle

[Link] [Link]
 Plan Scope Management
ITTO

[Link] [Link]
 Plan Scope Management -
Inputs
• Project Charter
• Documents the project purpose, high-level project
description, assumptions, constraints, and high-level
requirements that the scope management plan must
support.
• Project Management Plan
• Provides components such as the quality management
plan, project life cycle, and development approach that
influence how scope will be planned, defined, and
controlled.
• Project Documents
• Requirements documentation - existing documented
requirements that inform how requirements will be
managed going forward.
• Risk register - identified risks that may affect scope, such
as scope creep or unclear requirements, that the scope
management plan must address.
• Stakeholder register - identifies stakeholders who will help
elicit requirements and approve scope, and their level of
engagement.

[Link] [Link]
 Plan Scope Management -
Inputs
• Enterprise Environmental Factors
(EEFs)
• Organizational culture, infrastructure, and
personnel administration that shape how
scope can be planned and managed.
• Organizational Process Assets (OPAs)
• Policies and procedures, historical
information, lessons learned repository, and
templates that support building the scope and
requirements management plans.

[Link] [Link]
 Plan Scope Management -
Tools
• Expert Judgment
• Input from individuals with specialized knowledge
or experience in similar projects, prior
requirements, or scope management.
• Data Gathering
• Interviews - one-on-one discussions with
stakeholders to understand expectations,
requirements, and concerns about scope.
• Focus groups - bringing prequalified stakeholders
and subject matter experts together to learn about
expectations and attitudes regarding scope.
• Questionnaires and surveys - written sets of
questions used to gather information from a large
number of respondents quickly when stakeholders
are geographically dispersed.

[Link] [Link]
 Plan Scope Management -
Tools
• Data Analysis
• Techniques used to analyze the project
context and identify the best approach to
define, validate, and control scope.
• Test and Inspection Planning
• Determines how the product, deliverable, or
service will be tested or inspected to verify it
meets the stakeholder's needs and
acceptance criteria.

[Link] [Link]
 Plan Scope Management -
Output
• Project Management Plan Updates
• Scope Management Plan
• A component of the project management plan that
describes how the scope will be defined, developed,
monitored, controlled, and validated.
• Documents how the scope statement will be
prepared, how the WBS will be created from the
scope statement, and how the scope baseline will be
approved and maintained.
• Specifies how formal acceptance of completed
deliverables will be obtained.
• Requirements Management Plan
• A component of the project management plan that
describes how project and product requirements will
be analyzed, documented, and managed.
• Defines how requirements activities will be planned,
tracked, and reported.

[Link] [Link]
 Elicit and Analyze
Requirements
• The process of determining, documenting, and
managing stakeholder needs and requirements
to meet project objectives
• Provides the basis for defining and managing
the project scope, including product scope
• Captures requirements at multiple levels:
business, stakeholder, solution (functional and
non-functional), transition, project, and quality
• Engages stakeholders directly through
interviews, focus groups, workshops, and other
techniques
• Produces requirements documentation that is
traceable, complete, consistent, and acceptable
to key stakeholders

[Link] [Link]
 Elicit and Analyze
Requirements - ITTO

[Link] [Link]
 Elicit and Analyze
Requirements - Inputs
• Project Charter
• Documents the high-level project description,
success criteria, and stakeholder list - the
starting point for elicitation.
• Agreements
• Contracts and SLAs that contain stated and
implied requirements the project must satisfy.
• Business Case
• Documents the business need that drove the
project; helps validate that elicited
requirements truly support the value
proposition.

[Link] [Link]
 Elicit and Analyze
Requirements - Inputs
• Project Documents
• Assumption log - assumptions and constraints
affecting requirements.
• Lessons learned register - prior project insights
about elicitation techniques that worked or
failed.
• Stakeholder register - identifies who provides
which requirements and their level of influence.
• Project Management Plan
• Requirements management plan - defines how
requirements will be elicited, analyzed, and
managed.
• Scope management plan - defines how scope
(and therefore requirements) will be defined
and validated.
• EEFs and OPAs
• Industry standards, regulations, organizational
templates, and lessons learned that shape
elicitation approach.
[Link] [Link]
 Elicit and Analyze
Requirements - Tools
• Expert Judgment
• Specialists in business analysis, requirements
engineering, and the relevant subject matter help
shape and validate requirements.
• Decision-Making
• Techniques such as voting, autocratic, or
multicriteria analysis used to converge on a final
set of requirements.
• Data Gathering
• Benchmarking - comparing actual or planned
products to those of comparable organizations to
identify best practices.
• Brainstorming - rapid generation of ideas in a
group setting to surface candidate requirements.
• Focus groups - facilitated sessions with
prequalified stakeholders to learn about
expectations.
• Interviews - one-on-one or small-group discussions
to elicit detailed requirements.
• Questionnaires and surveys - written queries used
when stakeholders are dispersed or numerous.
[Link] [Link]
 Elicit and Analyze
Requirements - Tools
• Data Analysis & Representation
• Document analysis reviews existing artifacts
(contracts, policies, prior requirements) to extract
requirements.
• Data representation techniques such as affinity
diagrams and mind maps.
• Interpersonal and Team Skills
• Nominal group technique - structured method for
group brainstorming that encourages
contributions from everyone and facilitates quick
agreement.
• Design Thinking, Prioritization, Meetings
• Design thinking puts users at the center to
understand needs deeply before defining
solutions.
• Prioritization/ranking (e.g., MoSCoW, weighted
scoring) orders requirements by value and
constraints.
• Workshops and meetings bring stakeholders
together to elicit, refine, and approve
requirements.
[Link] [Link]
 Elicit and Analyze
Requirements - Output
• Requirements Documentation
• Requirements may start high level and become more
detailed over time.
• Before baselining, requirements should be clear,
measurable, testable, traceable, complete, consistent,
and accepted by key stakeholders.
• The acceptance criteria is a set of conditions that are
met before deliverables are accepted.
• Could include:
• Business requirements: strategic objectives and
high-level organizational needs.
• Stakeholder requirements: needs of
stakeholders or stakeholder groups.
• Solution requirements: features, functions, and
characteristics of the product, service, or result.
• Functional requirements: what the
product must do.
• Nonfunctional requirements: how the
product must perform, such as security,
reliability, safety, and performance.
• Transition/readiness requirements: temporary
needs such as training or data conversion.
• Project requirements: milestones, constraints,
and contractual obligations.
• Quality requirements: tests, certifications,
validations, and acceptance criteria.
[Link] [Link]
 Elicit and Analyze
Requirements - Output
• Requirements Traceability Matrix
• Links product requirements to the
deliverables that satisfy them.
• It helps ensure each requirement supports
business value and project objectives.
• It helps confirm that approved requirements
are completed by the end of the project.
• The matrix may link requirements to
business needs, project objectives, WBS
deliverables, design, development, and test
cases.
• Common attributes include requirement ID,
description, owner, source, priority, status,
and status date.
• Additional attributes may include stability,
complexity, and acceptance criteria.

[Link] [Link]
 Define Scope
• The objective is to describe the project,
product, and expected value to be delivered.
• The description may be detailed or high level
depending on the project approach.
• In predictive projects, scope is usually defined
early and structured in the WBS.
• In adaptive or hybrid projects, scope is
progressively defined through the backlog.
• This process also identifies quality
requirements and quality standards for
deliverables.
• It determines how the project will show that
quality requirements have been met.

[Link] [Link]
 Define Scope
ITTO

[Link] [Link]
 Define Scope - Inputs
• Project Charter
• Provides the high-level description of the project and
the product, the project objectives, and the success
criteria - the starting point for the detailed scope
statement.
• Assumption Log
• Lists assumptions and constraints that shape the
project scope and any decisions made about what is
in or out of scope.
• Project Management Plan
• The scope management plan within the PM Plan
documents the approach for defining scope and the
level of detail needed in the scope statement.
• Requirements Documentation
• The full set of analyzed requirements from which the
team selects the final project requirements to
include in the scope.
• EEFs and OPAs
• Organizational culture, infrastructure, personnel
administration, marketplace conditions, policies,
procedures, templates, and lessons learned from
previous projects.
[Link] [Link]
 Define Scope - Tools
• Expert Judgment
• Input from those experienced in similar
projects to ensure the scope is realistic,
complete, and feasible.
• Decision-Making
• Multicriteria decision analysis and voting to
select the final project requirements from the
broader requirements documentation.
• Data Analysis
• Alternatives analysis to evaluate ways to fulfill
the requirements and objectives identified in
the charter.

[Link] [Link]
 Define Scope - Tools
• Decomposition
• Breaking down the project deliverables into
smaller, more manageable components, lays
groundwork for the WBS.
• Interpersonal and Team Skills
• Facilitation - keeps key stakeholders aligned on
what is in scope and what is excluded; resolves
differences.
• Product Analysis
• Tools such as product breakdown,
requirements analysis, systems analysis, and
value engineering used to translate high-level
descriptions into tangible deliverables.

[Link] [Link]
 Define Scope - Output
• Project Documents
• Project Scope Statement
• The project scope statement describes the
project scope, product scope, major deliverables,
assumptions, and constraints.
• It helps determine whether change requests are
inside or outside the project boundaries.
• Key components include:
• Project scope description: details the
product, service, or result.
• Deliverables: unique and verifiable outputs
produced by the project.
• Acceptance criteria: conditions that must be
met before deliverables are accepted.
• Project exclusions: items that are specifically
out of scope.
• The project charter is high level, while the project
scope statement provides a more detailed
description of scope.

[Link] [Link]
 Define Scope - Output
• Project Documents
• Requirements Documentation (updated)
• May be updated as a result of decisions made
during scope definition (e.g., requirements
removed, refined, or reprioritized).
• Quality Management Plan
• Describes how quality policies, procedures, and
guidelines will be applied to the project.
• It explains how the project team will achieve the
project’s quality objectives.
• Early quality planning can reduce rework, lower
costs, and prevent schedule delays.
• The plan may include:
• Quality standards used by the project
• Quality roles and responsibilities
• Deliverables and processes subject to quality
review
• Quality control and quality management
activities
• Quality tools, methods, and procedures
• Nonconformance and continuous
improvement processes
[Link] [Link]
 Develop Scope Structure
• In predictive projects, the WBS breaks the
total project scope into smaller, manageable
work packages.
• The WBS helps define project deliverables
and supports planning, tracking, and control.
• Work packages make it easier to assign
ownership, measure progress, and manage
accountability.
• For complex projects, a WBS dictionary may
provide extra details for each WBS
component.
• Agile:
• In Agile projects, the WBS is represented
by the product backlog.
• The backlog breaks work into epics,
features, and user stories.

[Link] [Link]
 Develop Scope Structure
Work Breakdown Structure
(WBS)

[Link] [Link]
 Develop Scope Structure
Work Breakdown Structure (WBS)

[Link] [Link]
 Develop Scope Structure
ITTO

[Link] [Link]
 Develop Scope Structure
- Inputs
• Project Management Plan
• The scope management plan documents how the WBS
will be created, maintained, and approved.
• Project Documents
• Project scope statement - describes the deliverables,
acceptance criteria, and project boundaries that the
scope structure must reflect.
• Requirements documentation - the detailed requirements
that the WBS work packages must satisfy.
• Approved Changes
• Approved change requests that affect scope must be
incorporated into the WBS.
• EEFs and OPAs
• Industry standards (e.g., government regulations,
construction standards) and organizational templates,
policies, and lessons learned from prior WBS
development.

[Link] [Link]
 Develop Scope Structure
- Tools
• Expert Judgment
• Input from individuals who have experience developing
WBSs for similar projects.
• Brainstorming
• Group technique used to generate the components of
the scope structure when working from the project
scope statement and requirements.
• Decomposition
• The technique of dividing and subdividing the project
scope and deliverables into smaller, more manageable
parts.
• Activities for decomposition: identify deliverables;
structure and organize the WBS; decompose upper
levels into lower-level components; assign
identification codes; verify the decomposition is
correct.
• Each descending level represents an increasingly
detailed definition of the project work.

[Link] [Link]
 Develop Scope Structure -
Output
• Scope Baseline
• The approved version of the
• Scope statement
• WBS
• WBS dictionary
• Used as the basis for comparison.
• Can be changed only through formal change-control
procedures.
• Work Breakdown Structure (WBS)
• Hierarchical decomposition of the total scope of work to
be carried out by the project team.
• Lowest-level components are called work packages.

[Link] [Link]
 Develop Scope Structure -
Output
• WBS Dictionary
• Document that provides detailed information
about each WBS component (work description,
owner, schedule, cost, acceptance criteria, etc.).

[Link] [Link]
 Develop Scope Structure -
Output
• User Stories
• In adaptive projects, short descriptions of features
written from the user's perspective.
• Product Backlog
• An ordered list of features, requirements, and user
stories that represents the planned work for the
product.
• Reordered as priorities and understanding evolve.

[Link] [Link]
 Plan Schedule Management
• Establishes how the project schedule
will be planned, developed,
managed, performed, and
maintained.
• It provides guidance for managing the
schedule throughout the project.

[Link] [Link]
 Plan Schedule Management
ITTO

[Link] [Link]
 Plan Schedule Management
- Inputs
• Project Charter
• Defines the summary milestone schedule, project
approval requirements, and high-level constraints that
influence scheduling decisions.
• Project Management Plan
• Scope management plan - documents how the scope
will be defined, developed, and validated, which
directly impacts schedule planning.
• Development Approach
• Predictive, iterative, incremental, agile, or hybrid -
dictates how the project schedule is built and
managed.
• Enterprise Environmental Factors
• Organizational culture, marketplace conditions,
scheduling tools, and resource availability that
constrain or enable the schedule approach.
• Organizational Process Assets
• Schedule templates, scheduling methodology, lessons
learned from prior projects, and historical schedule
data.

[Link] [Link]
 Plan Schedule Management
- Tools
• Expert Judgment
• Specialists with experience in scheduling, scheduling
software, the specific industry, and similar previous
projects.
• Data Analysis
• Alternative analysis - evaluates different methods of
executing and accomplishing the work in a given level of
detail, time, and budget.
• Reviews multiple scheduling methodologies (CPM, critical
chain, iterative) to determine the best fit for the project.
• Meetings
• Planning meetings to develop the schedule management
plan, involving the PM, sponsor, team members, and
other relevant stakeholders.

[Link] [Link]
 Plan Schedule Management -
Output
Project Management Plan Updates:
• Schedule Management Plan
• Defines how the project schedule will be developed,
monitored, and controlled.
• It may be formal or informal, detailed or high level,
depending on the project needs.
• It establishes the scheduling method, tools, and
procedures the team will use.
• It may define release, wave, or iteration lengths for
adaptive projects.
• It identifies the level of accuracy for duration
estimates and any contingency allowances.
• It defines units of measure, such as hours, days,
weeks, or quantity-based measures.
• It explains how the schedule model will be updated
and maintained during execution.
• It sets control thresholds for acceptable schedule
variance before action is needed.
• It defines performance measurement rules, such as
percent complete
• It identifies the format and frequency of schedule
[Link] [Link] reports.
 Develop Schedule
• Creates the schedule model used to execute,
monitor, and control the project.
• It analyzes activity sequences, durations,
resource needs, and schedule constraints.
• The schedule identifies planned start and finish
dates for activities and milestones.
• Developing the schedule is an iterative process.
• The team may need to review and revise
duration estimates, resource estimates, and
schedule reserves.
• The goal is to create an approved project
schedule that can be used as the schedule
baseline.
• The schedule baseline is used to track progress
and measure performance.

[Link] [Link]
 Develop Schedule
Four Steps to Develop the Schedule
1. Define Activities: identify the specific work activities
needed to produce the project deliverables.
2. Determine Sequence: arrange activities in the correct
order based on dependencies and relationships.
3. Estimate Effort and Duration: estimate the work effort,
resources, and time needed to complete each activity.
4. Adjust: review and refine the schedule based on
constraints, resources, risks, and project priorities.

[Link] [Link]
 Develop Schedule
• Step 1: Define Activities
• Define Activities identifies the specific
work actions needed to produce the
project deliverables.
• Work packages are broken down into
schedule activities.
• These activities become the basis for
estimating, scheduling, executing,
monitoring, and controlling project work.

[Link] [Link]
 Develop Schedule
• Step 1: Define Activities
• Key artifacts (output) may include:
• Activity List: documented list of schedule
activities needed to complete project work.
• Includes activity ID, description, and
enough detail so the team understands
the work.
• Activity Attributes: extra details about each
activity, such as WBS ID, predecessors,
successors, relationships, leads/lags,
resources, constraints, and assumptions.
• Attributes help with sequencing,
scheduling, reporting, and organizing
work.
• Milestone List: identifies key project events
or checkpoints.
• Milestones have zero duration.
• Milestones may be mandatory, such as
contract requirements, or optional, such
as internal target dates.
[Link] [Link]
 Develop Schedule
Step 2: Determine Sequence
• Determine Sequence identifies the logical order in
which project activities should be performed.
• It defines dependencies and relationships between
schedule activities.
• Common relationships include:
• Finish-to-start
• Start-to-start
• Finish-to-finish
• Start-to-finish
• Leads and lags may be used to create a realistic and
achievable schedule.
• Uses Precedence Diagramming Method (PDM),
• A technique used for constructing a schedule
model in which activities are represented by
nodes and graphically linked by one or more
logical relationships.
• Outputs a Project Schedule Network Diagram

[Link] [Link]
 Develop Schedule

[Link] [Link]
 Develop Schedule
Step 2: Determine Sequence
• Activity Dependency Relationships
• Activity relationships show how schedule activities
depend on each other.
• The four common dependency relationships are:
• Finish-to-Start (FS): Activity A must finish before
Activity B can start.
• Most common relationship.
• Example: The first coat of paint must dry
before applying the second coat.
• Finish-to-Finish (FF): Activity B cannot finish
until Activity A finishes.
• Example: Editing an article can start before
writing is done, but editing cannot finish
until writing is complete.
• Start-to-Start (SS): Activity A must start before
Activity B can start.
• Example: Check-in cannot start until the
venue opens.
• Start-to-Finish (SF): Activity B cannot finish until
Activity A starts.
• Least common relationship.
• Example: The day guard cannot leave until
the night guard arrives.

[Link] [Link]
 Develop Schedule
Step 2: Determine Sequence
• Dependency Determination
• Dependencies can also be classified by their
nature and source.
• Mandatory Dependencies: required by the
nature of the work.
• Also called hard logic.
• Example: Memory must be installed
before the operating system can be
installed.
• Discretionary Dependencies: based on
preference, best practice, or experience.
• Also called soft logic or preferred logic.
• Example: Installing system updates before
office software because it is easier to
manage.
• External Dependencies: depend on something
outside the project team’s control.
• Example: Waiting for permits, approvals,
or supplier deliveries.
• Internal Dependencies: depend on work within
the project team’s control.
• Example: Software must be installed
before system testing can begin.

[Link] [Link]
 Develop Schedule
Step 2: Determine Sequence
• Leads and Lags
• Leads and lags are used to show overlap or delay
between activities.
• Lead: Lead creates overlap between activities.
• Example: Start taping fixtures after half the
furniture has been removed.

• Lag: creates a delay between activities.

• Example: Wait one day after painting before
moving furniture back.

• Leads can help shorten the schedule when activities

can safely overlap.
• Lags may be needed when work requires waiting
time, curing time, approvals, or delays.

[Link] [Link]
 Develop Schedule
Step 3: Estimate Effort and Duration
• Estimate Effort and Duration determines how much
work and time are needed to complete each activity.
• Estimates may be measured in hours, days, weeks, or
other work periods.
• Estimating uses information such as scope, resource
types, skill levels, resource quantities, and calendars.
• Common estimating techniques include:
• Expert judgment
• Delphi technique
• Analogous estimating
• Parametric estimating
• PERT
• Bottom-up estimating
• Estimates should be progressively elaborated as more
information becomes available.
• Duration can be affected by resource availability,
resource skill, constraints, risk, technology, and
assumptions.

[Link] [Link]
 Develop Schedule
Step 4: Adjust
• Adjust means reviewing the draft schedule to
determine whether it is realistic and acceptable.
• The draft schedule is reviewed against activity
sequences, estimates, resources, constraints, and risks.
• If the schedule is not acceptable, the team revises it
using alternative schedule options.
• Team members should review assigned activities to
confirm dates are realistic and do not conflict with
resource calendars.
• The schedule is analyzed for:
• Logical relationship conflicts
• Resource conflicts
• Need for resource leveling
• Schedule feasibility
• Once approved, the schedule becomes the baseline for
tracking progress.

[Link] [Link]
 Develop Schedule
• Common Estimation Techniques
• Expert Judgment: Uses people with experience to
estimate the work. Accuracy depends on the
expert’s knowledge and the quality of information
available.
• Analogous Estimating (Top-Down): Uses similar
past projects to estimate the current project. It is
usually faster but less accurate because it is based
on comparison.
• Bottom-Up Estimating: Estimates smaller work
components and adds them together. It is usually
the most accurate but takes more time because it
requires detailed information.
• Parametric Estimating: Uses formulas, historical
data, or statistical relationships. It can be highly
accurate when the data and formula are reliable.
• Relative Size Estimation: Compares work items by
size or complexity, often used in Agile. It is useful
for quick planning but is usually less precise than
detailed estimating.
[Link] [Link]
 Develop Schedule
• Common Estimation Techniques
• Multipoint Estimating: Uses multiple estimates,
such as optimistic, most likely, and pessimistic. It
is usually more accurate than one-point
estimating because it considers uncertainty.
• Three-Point Estimating / PERT
• Three-point estimating uses three values to
estimate activity duration or cost.
• It is also known as PERT: Program Evaluation
and Review Technique.
• It helps account for uncertainty instead of
using only one estimate.
• The three estimates are:
• Optimistic (O): best-case estimate;
shortest possible time or lowest cost.
• Most Likely (M): realistic estimate; what
is most likely to happen.
• Pessimistic (P): worst-case estimate;
longest time or highest cost.

[Link] [Link]
 Develop Schedule
• PERT Formulas to Know
• Beta Distribution / Weighted Average
• Formula: (O + 4M + P) / 6
• Gives more weight to the most likely estimate.
• Usually more realistic than a simple average.
• Triangular Distribution / Simple Average
• Formula: (O + M + P) / 3
• Gives equal weight to all three estimates.
• Standard Deviation
• Formula: (P - O) / 6
• Measures uncertainty or variability in the
estimate.
• Example:
• O = 2 days, M = 4 days, P = 6 days
• Beta: (2 + 4(4) + 6) / 6 = 4 days
• Triangular: (2 + 4 + 6) / 3 = 4 days
• Standard Deviation: (6 - 2) / 6 = 0.67 days

[Link] [Link]
 Develop Schedule

[Link] [Link]
 Develop Schedule

[Link] [Link]
 Develop Schedule - Inputs
• Project Charter
• Defines summary milestone schedule and project approval
requirements that influence schedule development.
• Project Management Plan
• Scope management plan - drives how scope is decomposed and
scheduled.
• Schedule management plan – how to create the schedule
• Development Approach
• Predictive vs adaptive vs hybrid - drives whether you use a Gantt-
based schedule or a release plan with iterations.
• Project Documents - Activities & Estimates
• Activity list - activities that need to be scheduled.
• Activity attributes - successor/predecessor relationships,
leads/lags, resource requirements per activity.
• Assumption log & Basis of estimates - the assumptions and
rationale behind duration estimates.
• Duration estimates - time required for each activity.
• Lessons learned register - prior schedule-development experience
that should be applied here.

[Link] [Link]
 Develop Schedule - Inputs
• Project Documents (cont.)
• Milestone list - significant points or events whose dates
anchor the schedule.
• Project schedule network diagrams - graphical
representation of activities and their logical relationships.
• Project team assignments - who is performing each activity.
• Resource calendars - working days, shifts, and available
resources by date.
• Resource requirements - skills, materials, equipment
needed.
• Risk register - schedule risks and their planned responses.
• Agreements
• Vendor contracts that specify deliverable dates and
milestones the schedule must accommodate.
• EEFs and OPAs
• Government/industry standards, communication channels,
scheduling tools, scheduling methodology, calendar
templates, and historical project information.

[Link] [Link]
 Develop Schedule - Tools
• Expert Judgment
• Specialists in scheduling methodology,
scheduling software, and similar prior
projects.
• Decomposition & Rolling Wave Planning
• Decomposition - breaking down work
packages into activities.
• Rolling wave planning - near-term work is
planned in detail; future work is planned at a
higher level (progressive elaboration).
• Precedence Diagramming Method
(PDM)
• A technique used for constructing a schedule
model in which activities are represented by
nodes and graphically linked by one or more
logical relationships.

[Link] [Link]
 Develop Schedule - Tools
• Leads and Lags
• Lead – Overlap of activities
• Lag - delay between activities.
• Dependency Determination &
Integration
• Mandatory (hard logic), discretionary
(preferred), external (outside the project), or
internal dependencies.
• Estimation, Reserves, Data Analysis
• Estimation techniques
• Reserve analysis – adding additional
time for risk.
• What-if analysis - 'what if scenario X
happens?' to test schedule resilience.
• Simulation (Monte Carlo) - many
possible schedules generated to
assess probability of meeting target
dates.
[Link] [Link]
 Develop Schedule - Tools
• Critical Path & Critical Chain
• Critical Path Method (CPM) - longest path through
the network diagram
• Critical Chain Method - critical path approach that
focuses on managing buffers and constrained
resources.
• Schedule Compression
• Crashing - add resources to shorten duration
(typically increases cost).
• Fast tracking - run activities in parallel that were
originally sequential (typically increases risk).
• Resource Optimization & Leveling
• Resource leveling adjusts start/finish dates to
balance resource demand with availability; may
extend the schedule.
• PMIS, Agile Release Planning
• PMIS automates schedule modeling. Agile release
planning decomposes the product roadmap into
releases and iterations.
[Link] [Link]
 Develop Schedule - Output
• Schedule Baseline
• The approved version of the schedule model
that can be changed only through formal
change-control procedures.
• Used as the basis for comparison to actual
results.
• Project Schedule
• The output of the schedule model that
presents linked activities with planned dates,
durations, milestones, and resources.
• Presented as bar charts, milestone charts, or
network diagrams.

[Link] [Link]
 Develop Schedule - Output
• Schedule Data
• Information for describing and controlling the
schedule (milestones, activities, attributes,
identified assumptions and constraints, resource
histograms, alternative schedules).
• Project Calendars
• Identifies working days and shifts available for
scheduled activities.
• Change Requests & Updates
• Change requests submitted via Integrated Change
Control.
• Schedule management plan, activity list, activity
attributes, assumption log, basis of estimates,
duration estimates, lessons learned register,
milestone list, network diagrams, resource
requirements, and risk register may all be updated.

[Link] [Link]
 Plan Financial Management
• Defines how project revenues and
expenses will be estimated, budgeted,
managed, monitored, and controlled.
• It provides guidance for managing
project finances throughout the
project.
• This process is usually performed once
up front or at predefined points in the
project.
• It helps ensure the project team
understands how costs, budgets,
funding, and financial performance will
be handled.

[Link] [Link]
 Plan Financial Management

[Link] [Link]
 Plan Financial Management
- Inputs
• Project Charter
• Defines the high-level financial constraints, pre-
approved budget, and key sponsor approval
requirements that frame the financial plan.
• Project Management Plan
• Schedule management plan - drives the timing of
when funds will be needed across the project life
cycle.
• Risk management plan - influences the size of
contingency and management reserves built into
the financial plan.
• Project Documents
• Documents such as the stakeholder register and
assumption log inform stakeholder funding
expectations and assumptions underlying the
financial approach.

[Link] [Link]
 Plan Financial Management
- Inputs
• Enterprise Environmental Factors
• Marketplace conditions, currency exchange
rates, published interest rates, and the
organization's financial controls policies.
• Organizational Process Assets
• Financial controls procedures, billing and
accounting systems, financial reporting
templates, and historical financial data from
prior projects.

[Link] [Link]
 Plan Financial Management -
Tools
• Expert Judgment
• Specialists in finance, accounting, treasury,
risk, and the relevant industry help shape
the financial approach.
• Data Analysis
• Alternative analysis - evaluates different
funding options (self-funded, external loan,
grant, milestone billing) and selects the
most appropriate.
• Meetings
• Planning meetings with the sponsor,
finance team, and PM to agree on the
financial approach, controls, and reporting.

[Link] [Link]
 Plan Financial Management -
Output
Financial Management Plan
• The financial management plan describes how project
costs will be planned, structured, and controlled.
• It documents the financial management processes,
tools, and techniques the project will use.
• It may define:
• Units of measure: staff hours, days, weeks, or
currency amounts.
• Level of precision: how cost estimates are
rounded.
• Level of accuracy: acceptable estimate range, such
as ±10%.
• WBS/control accounts: links costs to the WBS and
accounting system.
• Control thresholds: acceptable cost variance
before action is required.
• Performance measurement rules: EVM methods,
control account measurement, and EAC
forecasting.
• Reporting formats: cost report format and
frequency.
• Additional procedures: funding choices, currency
exchange handling, and cost recording.
[Link] [Link]
 Plan Financial Management -
Output
• Funding Strategy
• Defines how the project will secure the money
needed to be successful.
• Funding may come from internal or external sources.
• Some projects may use one funding source, while
others may combine multiple funding approaches.
• Common funding strategies include:
• Fixed or reallocated internal budgets: using
existing organizational funds.
• Lump sum: allocating the full project budget and
reserves at once.
• Incremental disbursement: releasing funds by
phase, milestone, or need.
• External investment: receiving capital from
investors, often for ownership or future returns.
• Government or NGO grants: funding from
agencies, nonprofits, or philanthropists.
• Crowdfunding: collecting small contributions
from many supporters.
• Client contract: funding provided through a
customer or sponsor contract.
[Link] [Link]
 Estimate Costs
• The process of developing an
approximation of the monetary
resources needed to complete project
work
• Determines the cost required to
complete project work; estimates are
based on the information known at a
given point in time
• Cost trade-offs and risks must be
considered (e.g., make vs buy, buy vs
lease, sharing of resources)

[Link] [Link]
 Estimate Costs

[Link] [Link]
 Estimate Costs - Inputs
• Project Management Plan
• Quality management plan - identifies the level of
quality required, which influences the cost of
quality embedded in estimates.
• Scope baseline - the project scope statement,
WBS, and WBS dictionary define what work must
be costed.
• Project Documents
• Lessons learned register - applies prior
estimating lessons to improve current estimates.
• Project schedule - duration estimates and the
timing of activities affect cost (e.g., resources
costing more in peak season).
• Resource requirements - the type, quantity, and
characteristics of resources to be costed.
• Risk register - identified risks may require
contingency reserves built into the estimate.

[Link] [Link]
 Estimate Costs - Inputs
• Make-or-Buy Decisions
• Decisions made in Plan Sourcing Strategy on
what to build internally vs procure
externally directly drive where costs land.
• Work Package Estimation
• The granularity at which work has been
decomposed; smaller work packages enable
more accurate bottom-up estimates.
• EEFs and OPAs
• Marketplace conditions, published
commercial cost information, currency
exchange rates, cost-estimating policies,
templates, and historical cost data.

[Link] [Link]
 Estimate Costs - Tools
• Expert Judgment
• Specialists with knowledge in similar prior projects,
the industry, the discipline, and estimating
methods.
• Analogous Estimating
• Uses values from a similar previous project as the
basis for estimating the current project.
• Quick and inexpensive but generally less accurate;
useful early when little information is known.
• Parametric Estimating
• Uses a statistical relationship between historical
data and other variables (e.g., $ per page, $ per
square foot).
• Bottom-Up Estimating
• Estimating component work and aggregating up.
Most accurate but most time-consuming.
• Multipoint Estimating (Three-Point)
• Uses optimistic (O), most likely (M), and pessimistic
(P) estimates:
• beta = (O+4M+P)/6.
• triangular = (O+M+P)/3

[Link] [Link]
 Estimate Costs - Estimating Techniques
Analogous (Top-Down) Parametric Bottom-Up Three-Point

Use actual cost from a Use a statistical/unit-rate Estimate each work package Best, most likely, and worst
similar past project model (e.g. $/page, $/sqft) then aggregate up case: (O+4M+P)/6

PROS / CONS PROS / CONS PROS / CONS PROS / CONS

Quick. Low cost. Quick. Defensible. Most accurate. Accounts for uncertainty.
Less accurate. Needs historical data. Most time-consuming. Good for risky items.

TYPICAL ACCURACY TYPICAL ACCURACY TYPICAL ACCURACY TYPICAL ACCURACY

-25% to +75% -15% to +25% -5% to +10% -10% to +15%

Different techniques offer different trade-offs between speed, cost, and accuracy.

[Link] [Link]
 Estimate Costs - Tools
• Data Analysis
• Alternative analysis - evaluates options to balance
cost, schedule, scope, and quality.
• Reserve analysis - contingency reserves for known
risks; management reserves for unknown
unknowns.
• Cost of quality - includes cost of conformance
(prevention + appraisal) and non-conformance
(internal/external failure) in the estimate.
• PMIS & Decision-Making
• PMIS aids in calculating, recording, and reporting
estimates. Voting techniques converge multiple
expert estimates.

[Link] [Link]
[Link] [Link]
 Estimate Costs - Output
• Cost Estimates
• Quantitative assessments of the probable costs required
to complete project work.
• May be presented as a single value or in ranges (e.g.,
$10K +/- 10%).
• Includes direct labor, materials, equipment, services,
facilities, IT, contingency reserves, and indirect costs.
• Basis of Estimates
• Supporting documentation that explains how each
estimate was derived, including the assumptions,
constraints, estimating method, range of possible
estimates, and confidence level.
• Project Document Updates
• Assumption log - updated with new assumptions made
during estimating.
• Lessons learned register - captures effective and
ineffective estimating techniques used.
• Risk register - updated with new risks identified during
estimating, especially around uncertain costs.

[Link] [Link]
 Develop Budget
• The process of aggregating the
estimated costs of individual
activities or work packages to
establish an authorized cost baseline
• Includes all funds authorized to
execute the project
• Cost baseline is the approved
version of the time-phased budget,
excluding any management reserves
• Project funding requirements are
derived from the cost baseline and
may be incremental rather than
continuous

[Link] [Link]
 Develop Budget
ITTO

[Link] [Link]
 Develop Budget - Inputs
• Project Management Plan
• Financial management plan - establishes the rules
and controls under which the budget is built.
• Resource management plan - identifies what
resources are needed and at what cost.
• Scope baseline - WBS and work packages provide
the structure for aggregating costs.
• Project Documents
• Basis of estimates - explains how each cost was
estimated; needed to validate aggregations.
• Cost estimates - the activity- or work-package-level
figures that get aggregated into the budget.
• Project schedule - drives the time-phasing of costs
across the project life cycle.
• Risk register - identified risks drive the contingency
reserve included in the budget.

[Link] [Link]
 Develop Budget - Inputs
• Business Documents
• Business case - documents the financial
justification; the budget must support the expected
benefits.
• Benefits management plan - identifies the target
benefits and timing the budget must enable.
• Agreements
• Vendor contracts that fix portions of the budget at
specific values and payment milestones.
• EEFs and OPAs
• Currency exchange rates, market conditions,
budgeting templates, organizational financial
reporting standards, and historical budget data.

[Link] [Link]
 Develop Budget - Tools

• Expert Judgment
• Specialists in financial planning, cost
estimating, and the relevant industry refine
and validate the aggregated budget.
• Cost Aggregation
• Cost estimates are aggregated by work
package per the WBS, then by control
account, then to the project total.
• Data Analysis
• Reserve analysis - establishes contingency
reserves for known risks and management
reserves for unknown risks; both included
in the budget.

[Link] [Link]
 Develop Budget - Tools
• Historical Information Review
• Reviewing past similar projects to validate that
the budget magnitude and pattern are
reasonable.
• Funding Limit Reconciliation
• Reconciles planned expenditure with funding
limits set by the organization (e.g., quarterly
capital budgets) and may require schedule
adjustments to align spending with available
funds.
• Financing
• Acquiring funding for projects (loans, equity,
customer advance payments) - especially
relevant for long-duration or capital-intensive
projects.

[Link] [Link]
 Develop Budget - Output
• Cost Baseline
• The approved version of the time-phased project
budget, excluding any management reserves.
• Used as the basis for comparison to actual results; can
only be changed through formal change-control
procedures.
• Often visualized as an S-curve of cumulative cost over
time.
• Equals the sum of activity cost estimates +
contingency reserves; total project budget = cost
baseline + management reserves.

[Link] [Link]
 Develop Budget - Output
• Project Funding Requirements
• Total funding requirements + periodic funding
requirements (monthly, quarterly, etc.) derived
from the cost baseline.
• Funding often occurs in incremental amounts
that may not be evenly distributed; usually
drawn at decision gates or milestone completion.
• Project Document Updates
• Cost estimates, project schedule, and risk
register may be updated as the budget is
finalized and reconciled with funding limits.

[Link] [Link]
 Plan Stakeholder Engagement
• The process of developing approaches to involve
project stakeholders based on their needs,
expectations, interests, and potential impact on
the project
• Provides an actionable plan to interact effectively
with stakeholders throughout the project life
cycle
• Used to identify gaps between current and
desired engagement levels (Unaware, Resistant,
Neutral, Supportive, Leading)
• Iteratively reviewed and updated as new
stakeholders are identified or existing
stakeholders change

[Link] [Link]
 Plan Stakeholder Engagement
ITTO

[Link] [Link]
 Plan Stakeholder Engagement
- Inputs
• Project Charter
• Identifies the project sponsor, key
stakeholders, and high-level objectives that
the engagement plan must support.
• Project Management Plan
• Resource management plan - identifies
team members and the resources required
to engage stakeholders.
• Communications management plan - drives
how, when, and in what format
engagement-related communications occur.
• Risk management plan - identifies
stakeholder-related risks that the
engagement plan must mitigate.

[Link] [Link]
 Plan Stakeholder Engagement
- Inputs
• Project Documents
• Assumption log - assumptions about stakeholders'
expectations and engagement preferences.
• Change log - changes may shift stakeholder
engagement needs.
• Issue log - unresolved issues affecting stakeholder
engagement.
• Project schedule - timing of activities affects when
engagement actions are needed.
• Risk register - stakeholder-related risks to address.
• Stakeholder register - the master list of
stakeholders to be engaged.
• Agreements
• Contracts may dictate engagement approaches
with vendors and partner organizations.
• EEFs and OPAs
• Organizational culture, political climate,
governance framework, stakeholder engagement
policies, templates, lessons learned.

[Link] [Link]
 Plan Stakeholder Engagement
- Tools
• Expert Judgment
• Input from those experienced in engaging
similar stakeholder communities and on
similar projects.
• Data Gathering
• Benchmarking - compares stakeholder
engagement results from current and prior
projects to find effective practices.
• Data Analysis
• Assumption and constraint analysis - tests
assumptions about stakeholder behavior to
refine the engagement approach.
• Root cause analysis - identifies underlying
reasons for current stakeholder engagement
levels.

[Link] [Link]
 Plan Stakeholder Engagement
- Tools
• Decision-Making
• Prioritization/ranking - prioritizes stakeholders so
engagement effort goes where it has the most
impact.
• Data Representation
• Mind mapping - visually organizes stakeholders
and the relationships among them.
• Stakeholder engagement assessment matrix -
shows current (C) vs desired (D) engagement
levels across Unaware, Resistant, Neutral,
Supportive, and Leading.
• Meetings
• Workshops with the team and key stakeholders to
develop and validate the engagement strategies.

[Link] [Link]
Plan Stakeholder Engagement - Stakeholder Engagement Assessment Matrix
C = Current engagement level, D = Desired engagement level. Where C and D differ, communication and engagement actions must close the gap.

[Link] [Link]
 Plan Stakeholder Engagement
- Output
• Stakeholder Engagement Plan
• A component of the Project Management
Plan that identifies the strategies and
actions required to promote productive
involvement of stakeholders.
• Documents desired and current
engagement levels of key stakeholders.
• Identifies the scope and impact of change
to stakeholders.
• Identifies interrelationships and potential
overlap between stakeholders.

[Link] [Link]
 Plan Communications
Management
• The process of developing an
appropriate approach and plan for
project communications based on
stakeholder information needs and
project requirements
• Identifies and documents the
approach to communicate most
effectively and efficiently with
stakeholders
• Considers what info is needed, when
it is needed, who needs it, who
provides it, who receives it, in what
format, and at what frequency

[Link] [Link]
 Plan Communications
Management - ITTO

[Link] [Link]
 Plan Communications Management
- Inputs
• Project Charter
• Identifies key stakeholders, sponsor, and the
project purpose, all of which inform
communication needs.
• Project Management Plan
• Resource management plan - identifies the team
members and resources who will produce or
consume project communications.
• Stakeholder engagement plan - identifies
stakeholders and their desired engagement levels
which drive what must be communicated to
whom.

[Link] [Link]
 Plan Communications
Management - Inputs
• Project Documents
• Requirements documentation - communication
requirements (reporting cadence, languages, formats)
may be explicitly stated.
• Stakeholder register - the master list of who must be
communicated with.
• Enterprise Environmental Factors
• Organizational culture, political climate, governance,
personnel administration, stakeholder risk thresholds,
and established communication channels.
• Organizational Process Assets
• Organizational policies and procedures for
communication, templates, historical communication
artifacts, and lessons learned.

[Link] [Link]
 Plan Communications
Management - Tools
• Expert Judgment
• Specialists with experience in communications,
organizational politics, and similar projects.
• Communication Requirements Analysis
• Determines the information needs of project stakeholders.
• Number of potential communication channels
• FORMULA: N(N-1)/2
• where N is the number of stakeholders.
• Adding stakeholders rapidly multiplies channels.

[Link] [Link]
 Plan Communications
Management - Tools
• Communication Technology
• Includes the tools, systems, and software used to
share information with project stakeholders.
• Common methods include meetings, conversations,
written documents, databases, social media,
websites, and collaboration tools.
• Factors that affect the choice of technology include:
• Urgency: how quickly the information is
needed.
• Availability and reliability: whether
stakeholders can access and use the
technology.
• Ease of use: whether the tool is simple enough
or requires training.
• Project environment: virtual teams, time
zones, languages, and culture.
• Sensitivity and confidentiality: whether
security or privacy controls are needed.

[Link] [Link]
 Plan Communications
Management - Tools
• Communication Models
• A communication model shows how information
moves between a sender and receiver.
• The basic model focuses on delivering the
message:
• Encode: sender turns the message into
words, symbols, or media.
• Transmit: message is sent through a
communication channel.
• Decode: receiver interprets the message.
• The interactive model adds understanding:
• Acknowledge: receiver confirms the message
was received.
• Feedback/Response: receiver responds to
confirm understanding.
• The sender is responsible for making the message
clear, complete, and properly understood.
• The receiver is responsible for receiving,
interpreting, and responding appropriately.
• Noise can interfere with communication, such as
distractions, technology issues, culture, language,
assumptions, or bias.
• Cross-cultural communication may be affected by
age, nationality, profession, gender, personality,
and background.
[Link] [Link]
 Plan Communications
Management - Tools

Communication Model

[Link] [Link]
 Plan Communications
Management - Tools
• Communication Methods
• Techniques used to share information with project
stakeholders.
• Interactive communication: real-time, two-way or
multidirectional communication.
• Examples: meetings, phone calls, IM
• Push communication: information is sent directly to
specific recipients.
• Examples: emails, reports, memos, voicemails
• Pull communication: recipients access information
when needed.
• Examples: intranet sites, web portals, eLearning.
• Communication can also occur as:
• Interpersonal: one-on-one communication.
• Small group: communication among 3–6 people.
• Public: one speaker or group addressing a large
audience.
• Mass communication: message sent to a large or
anonymous audience.
• Networks/social computing: many-to-many
[Link] [Link] communication using social tools and media.
 Plan Communications
Management - Tools
• Interpersonal and Team Skills
• Communication styles assessment - identifies the
preferred method, format, and content of
communication for each stakeholder.
• Political awareness - understands the power
relationships in and outside the project.
• Cultural awareness - understands cultural
differences and language barriers that affect
communication.
• Data Representation & Meetings
• Stakeholder engagement assessment matrix -
drives what info each stakeholder needs.
• Communication planning meetings with the team
and key stakeholders to develop and validate the
plan.

[Link] [Link]
 Plan Communications
Management - Output
• Communications Management Plan
• A component of the Project Management Plan that
explains how project information will be created,
shared, monitored, and updated.
• It defines who needs information, what information
is needed, when it is needed, and how it will be
delivered.
• It identifies stakeholder communication
requirements, message format, language, content,
and level of detail.
• It defines communication methods and
technologies, such as meetings, reports, emails,
dashboards, websites, or project software.
• It identifies who is responsible for communicating
information and who can approve confidential
information.
• It includes timing, frequency, escalation processes,
acknowledgments, and response requirements.
• It may include templates, meeting guidelines, report
formats, terminology, workflows, and
communication constraints.
• The plan should be updated as stakeholders, scope,
team structure, or project conditions change.
[Link] [Link]
[Link] [Link]
 Plan Communications
Management - Output
• Stakeholder Engagement Plan & Document
Updates
• Stakeholder engagement plan - updated as
communication needs are clarified.
• Project schedule - communication activities may need
to be added.
• Stakeholder register - updated with communication
preferences.

[Link] [Link]
 Plan Resource Management
• The process of defining how to estimate,
acquire, manage, and use physical and team
resources
• Establishes the approach and level of
management effort needed to manage
project resources based on the type and
complexity of the project
• Identifies the various roles needed for the
project, the responsibilities of those roles,
and the required competencies
• Considers cultural, geographical, and
organizational factors in resource planning

[Link] [Link]
 Plan Resource Management

[Link] [Link]
 Plan Resource Management -
Inputs
• Project Charter
• Identifies the high-level project description, key
milestones, and pre-assigned resources or
sponsors that frame resource planning.
• Project Management Plan
• Quality management plan - influences
resources needed (skills, certifications) to meet
quality standards.
• Scope baseline - WBS identifies the deliverables
that will require resources.

[Link] [Link]
 Plan Resource Management -
Inputs
• Project Documents
• Project schedule - timing of activities drives when
resources are needed.
• Requirements documentation - dictates the skills and
physical resources needed.
• Risk register - identified resource-related risks (e.g.,
key personnel loss).
• Stakeholder register - identifies stakeholders who
influence resource planning (HR, finance, vendors).
• EEFs and OPAs
• Organizational culture and structure, geographic
distribution, marketplace conditions, organizational
policies and procedures, role descriptions, and
templates.

[Link] [Link]
 Plan Resource Management - Tools
• Expert Judgment
• Specialists with expertise in negotiating for
resources, personnel administration, and the
discipline of the project.
• Data Gathering
• Interviews - one-on-one discussions with
stakeholders to understand resource availability
and needs.
• Data Analysis
• SWOT analysis - examines team strengths,
weaknesses, opportunities, and threats to inform
resource planning.

[Link] [Link]
 Plan Resource Management - Tools
• Data Representation
• Hierarchical charts - org charts showing reporting lines.
• Responsibility Assignment Matrix (RAM) - shows who is
responsible for what work; common form is RACI
(Responsible, Accountable, Consulted, Informed).
• Text-oriented formats - position descriptions, role-
responsibility-authority forms.

[Link] [Link]
Plan Resource Management - RACI Chart Example

[Link] [Link]
 Plan Resource Management -
Tools
• Organizational Theory
• Provides information regarding the way in which
people, teams, and organizational units behave.
• Meetings
• Resource planning meetings with the team and key
stakeholders.
• Green HRM & Resource-Based View
• Green Human resource management - integrates
environmental sustainability into HR practices (e.g.,
remote work to reduce travel).
• Resource-based view - views people and physical
resources as a source of competitive advantage.

[Link] [Link]
 Plan Resource Management -
Output
• Resource Management Plan
• The resource management plan explains how
project resources will be acquired, allocated,
monitored, and controlled.
• It may cover both team resources and physical
resources.
• It defines how resources will be identified,
estimated, acquired, managed, and released.
• It includes roles and responsibilities:
• Role: the function assigned to a person.
• Authority: the right to make decisions and
use resources.
• Responsibility: the work a team member is
expected to perform.
• Competence: the skills needed to complete
the work.
• It may include the project organization chart,
staffing approach, training, team development,
and recognition plan.
[Link] [Link]
 Plan Resource Management -
Output
• Team Charter
• A team charter defines the team’s values, agreements,
and operating guidelines.
• It sets clear expectations for acceptable team behavior.
• It helps reduce misunderstandings and improve
productivity.
• The team charter may include:
• Team values
• Communication guidelines
• Decision-making processes
• Conflict resolution processes
• Meeting guidelines
• Team agreements
• It works best when the team helps create it or has
input into it.
• All team members are responsible for following the
charter.
• The charter can be reviewed and updated as the team
changes or new members join.

[Link] [Link]
 Plan Resource Management -
Output
• Project Document Updates
• Assumption log - assumptions about resource availability
documented.
• Risk register - resource-related risks identified.
• Resource Breakdown Structure - organizes project
resources by category and type.

Resource Breakdown Structure

[Link] [Link]
 Estimate Resources
• The process of estimating team
resources and the type and quantities
of materials, equipment, and supplies
necessary to perform project work
• This process helps identify possible
resource shortages or surpluses early.
• It supports better resource allocation
and helps manage resource-related
risks.
• Estimate Resources is performed
once or at predefined points in the
project.
• It is closely connected to the schedule
because resource availability can
affect activity duration.
[Link] [Link]
 Estimate Resources
ITTO

[Link] [Link]
 Estimate Resources - Inputs
• Project Management Plan
• Resource management plan - guides how
resources are estimated, acquired, and managed.
• Schedule management plan - dictates timing of
resource needs.
• Scope baseline - WBS identifies the work to be
resourced.

[Link] [Link]
 Estimate Resources - Inputs
• Project Documents
• Activity attributes - successor/predecessor
relationships, leads/lags, resource requirements.
• Activity list - the activities requiring resources.
• Assumption log - assumptions about resource
availability and skill levels.
• Cost estimates - cost may influence resource
selection (e.g., contractor vs employee).
• Resource calendars - working days and shifts
when resources are available.
• Risk register - resource-related risks (skill gaps,
single points of failure).
• Project Schedule
• Activities and their dates determine when each
resource is needed.
• EEFs and OPAs
• Resource location, marketplace conditions,
published estimating data, lessons learned, and
historical info.

[Link] [Link]
 Estimate Resources - Tools
• Expert Judgment
• Specialists with experience in resource
planning, estimating, and the relevant skill
area.
• Bottom-Up Estimating
• Resource needs are estimated at the activity
or work-package level, then aggregated. Most
accurate but most time-consuming.
• Analogous Estimating
• Uses values from similar previous projects as
the basis for estimating resources for the
current project. Quick but less accurate.

[Link] [Link]
 Estimate Resources - Tools
• Parametric Estimating
• Uses statistical relationships (e.g., person-hours
per page, square feet per worker) between
historical data and other variables.
• Data Analysis
• Alternative analysis - evaluates options like make-
vs-buy, capability vs commodity resources, or
different mixes of skill levels.
• Project Management Information System
• Resource management software, scheduling tools,
and estimating systems used to model resource
needs.
• Meetings & Interviews
• Discussions with team members, subject matter
experts, and prior project teams to refine resource
estimates.

[Link] [Link]
 Estimate Resources - Tools
• Artificial Intelligence (AI): analyzes past project
data to recommend the type and quantity of
resources needed.
• Example: suggests the number of developers,
designers, and testers for a website project.
• Predictive Analytics: uses historical data and
trends to forecast future resource needs and
possible shortages.
• Example: predicts when extra developers
may be needed to meet a deadline.
• Virtual Reality (VR): simulates project
environments to help identify needed workers,
tools, and equipment.
• Example: simulates a construction site before
work begins.
• Augmented Reality (AR): overlays digital
information onto the real world to improve
resource planning.
• Example: estimates paint and labor needs by
projecting coverage onto walls.
[Link] [Link]
 Estimate Resources - Tools
• Branch and Bound: finds the best resource
allocation under constraints.
• A way to test different resource choices and
eliminate the bad options until you find the
best one.
• Example: assigns developers to tasks to
reduce delays.
• Genetic Algorithms: test many resource
scenarios to find the best mix of cost, time, and
workload.
• The tool may test many possible team plans:
• Plan 1: two developers on design, one
on backend
• Plan 2: one designer, two developers,
one tester
• Example: balances team assignments on a
large website project.
• COCOMO: estimates software development
effort, time, and resources based on project size
and complexity.
• Example: estimates how many developers
are needed for a website project.
[Link] [Link]
 Estimate Resources - Output
• Resource Requirements
• Resource requirements identify the types
and quantities of resources needed for
project work.
• They may be defined for each activity, work
package, WBS branch, or the entire project.
• Resources may include people, equipment,
materials, supplies, facilities, or technology.
• The level of detail depends on the project
and application area.
• The documentation may include assumptions
about resource type, quantity, and
availability.
• Basis of Estimates
• Documents how the estimates were derived:
the method, assumptions, constraints, range,
and confidence level.

[Link] [Link]
 Estimate Resources - Output
• Resource Breakdown Structure (RBS)
• Hierarchical representation of resources by category
(labor, materials, equipment, facilities) and type (skill
level, grade).
• Used to organize and report project resource data.

• Project Document Updates

• Activity attributes - updated with refined resource
requirements per activity.
• Assumption log - new assumptions documented.
• Lessons learned register - estimating insights captured.
• Risk register - resource-related risks identified during
estimation.

[Link] [Link]
 Plan Risk Management
• The process of defining how to
conduct risk management
activities for a project
• Defines the approach, tools, data
sources, roles and
responsibilities, budget, timing,
risk categories, definitions of
probability and impact, and the
probability/impact matrix

[Link] [Link]
 Plan Risk Management

[Link] [Link]
 Plan Risk Management - Inputs
• Project Charter
• Provides high-level project description,
summary milestones, and stakeholder list -
which all influence the level of risk
management effort.
• Project Management Plan
• All components of the PM Plan are inputs
because risk management cuts across
every aspect of the project.
• Especially the scope, schedule, cost,
quality, resource, communications,
procurement, and stakeholder plans - each
introduces specific categories of risk.

[Link] [Link]
 Plan Risk Management - Inputs
• Project Documents
• Stakeholder register - identifies
stakeholders whose risk attitudes and
tolerances must be reflected in the risk
management plan.
• Enterprise Environmental Factors
• Overall risk thresholds set by the
organization, regulatory requirements,
marketplace conditions, organizational
culture, and risk attitude of stakeholders.
• Organizational Process Assets
• Organizational risk policy, risk categories,
common definitions of risk concepts and
terms, risk statement formats, and
standard templates.

[Link] [Link]
 Plan Risk Management - Tools
• Expert Judgment
• Specialists with knowledge of the project's
industry, type of project, risk identification
techniques, and risk management
practices.
• Often includes input from senior
management, sponsors, and other PMs
experienced with similar projects.
• Data Gathering
• Interviews - one-on-one discussions with
key stakeholders to gather perspectives on
risk approach, risk attitudes, and any
concerns.

[Link] [Link]
 Plan Risk Management - Tools
• Data Analysis
• Stakeholder analysis - examines the risk
attitudes and tolerances of project
stakeholders, which inform the definitions
and thresholds in the risk management
plan.
• Meetings
• Risk planning meetings with the team,
sponsor, key stakeholders, and risk experts.

[Link] [Link]
 Plan Risk Management - Output
• Risk Management Plan
• A component of the PM Plan that describes how risk
management activities will be structured and performed,
can include:
• Risk strategy - general approach for managing risk on
the project.
• Methodology - specific approaches, tools, and data
sources used to perform risk management.
• Funding - identifies funds needed for risk management
and protocols for use of contingency and management
reserves.
• Timing - when and how often risk management will be
performed.
• Risk categories - groupings (e.g., technical, external,
organizational, project management) often shown in a
Risk Breakdown Structure (RBS).
• Definitions of risk probability and impact - explicit
definitions of each level (very low to very high).
• Probability and Impact Matrix - the prioritization
matrix used to qualitatively assess risks.
• Reporting formats - how outcomes of risk
management are documented, analyzed, and
communicated.
• Tracking - how risk activities will be recorded and
audited.

[Link] [Link]
 Identify Risks - Risk Breakdown
Structure (RBS)

A hierarchical decomposition of potential sources of risk used to organize identification efforts and to categorize risks in the register.
[Link] [Link]
 Identify Risks
• Identifying individual project risks as well as
sources of overall project risk
• Individual project risk: a specific
uncertain event or condition that could
affect one or more project objectives.
• Example: A key developer may
become unavailable, causing a
website feature to be delayed.
• Overall project risk: the combined
effect of all risks and uncertainty on the
entire project.
• Example: The website project may
miss the launch date because of
multiple risks, such as scope
changes, testing defects, and
stakeholder approval delays.
• Iterative because new individual risks
may emerge as the project progresses
through its life cycle
[Link] [Link]
 Identify Risks

[Link] [Link]
 Identify Risks - Inputs
• Project Management Plan
• Requirements management plan - identifies
areas of high uncertainty in requirements that
may introduce risk.
• Schedule management plan - identifies time-
related risks (e.g., aggressive deadlines).
• Financial management plan - identifies cost
and funding risks.
• Quality management plan - identifies areas
susceptible to quality risk.
• Resource management plan - identifies
resource availability and skill-related risks.
• Risk management plan - the playbook
governing the Identify Risks process: roles,
categories, definitions, and tools to use.
• Scope, schedule, and cost baselines -
establish the reference points; risks are
identified relative to what could threaten
meeting them.

[Link] [Link]
 Identify Risks - Inputs
• Project Documents
• Assumption log - assumptions and constraints
can become risks if proven wrong.
• Cost estimates / duration estimates -
estimates with wide ranges or low confidence
indicate risk.
• Issue log - existing issues may indicate
emerging or underlying risks.
• Lessons learned register - prior project risks
that may apply here.
• Requirements documentation - unclear,
complex, or novel requirements signal risk.
• Resource requirements - shortages or
specialized skill needs introduce risk.
• Stakeholder register - stakeholder conflict,
low engagement, or attitude shifts can be
risks.

[Link] [Link]
 Identify Risks - Inputs
• Agreements
• Vendor contracts may contain risk-
shifting clauses, penalties, or warranties
that affect identified risks.
• EEFs and OPAs
• Published material (industry studies,
benchmarks), academic studies, risk
databases, organizational risk registers,
lessons learned, and templates.

[Link] [Link]
 Identify Risks - Tools
• Expert Judgment
• Specialists with experience on similar
projects, in the same business area, or with
the relevant technology.
• Data Gathering
• Brainstorming - team or workshop session
focused on generating risk ideas (often using
risk categories from the RBS as prompts).
• Checklists - lists of risks identified on previous
similar projects; ensures common risks are
not missed.
• Interviews - one-on-one or small-group
discussions with stakeholders, SMEs, and
team members to surface risks.

[Link] [Link]
 Identify Risks - Tools
• Data Analysis
• Root cause analysis - examines a problem to
determine underlying causes that may also
represent risks.
• Assumption and constraint analysis - tests the
validity of assumptions and constraints; if
invalidated, they become risks.
• Document analysis - structured review of project
documents may reveal areas of risk.
• SWOT analysis - examines Strengths, Weaknesses,
Opportunities, and Threats from the project

[Link] [Link]
 Identify Risks - Tools
• Interpersonal and Team Skills
• Facilitation - improves the effectiveness of
brainstorming, workshops, and interviews
used to identify risks.
• Prompt Lists
• Predetermined lists of risk categories that
might give rise to risks
• Meetings
• Risk-identification workshops with the team
and key stakeholders, often facilitated and
time-boxed.
• Artificial Intelligence
• AI-assisted risk identification using historical
project data, pattern recognition, and natural
language processing of project documents.

[Link] [Link]
 Identify Risks - Output
• Risk Register
• Contains the list of identified individual
project risks.
• List of identified risks - each with a
unique identifier, category, brief
description.
• Potential risk owners - the person
responsible for monitoring and
responding to each risk.
• List of potential responses - any
preliminary response ideas surfaced
during identification.

[Link] [Link]
 Identify Risks - Output
• Risk Report
• Presents information on sources of overall
project risk and summary information on
identified individual project risks.
• Project Document Updates
• Assumption log - new assumptions
documented during risk identification.
• Issue log - existing issues that turn out to be
risks moved or linked.
• Lessons learned register - effective and
ineffective techniques for risk identification
captured.

[Link] [Link]
 Perform Risk Analysis
• Perform Risk Analysis evaluates project risks to
understand their probability, impact, and effect
on project objectives.
• This process is iterative and may be repeated
throughout the project.
• It includes both qualitative and quantitative risk
analysis.
• Qualitative risk analysis assesses individual
risks based on probability, impact, urgency,
manageability, timing, and relationships to
other risks.
• Qualitative analysis helps prioritize
which risks need the most attention.
• Quantitative risk analysis numerically
analyzes the combined effect of risks and
uncertainty on overall project objectives.
• Quantitative analysis may not be
required for every project.

[Link] [Link]
 Perform Risk Analysis
• Risk Characteristics
• Urgency
• How quickly we must respond to the risk
• Example: A key server may fail today, so the team must act
immediately
• High: A response must happen immediately to be effective.
• Low: The response can wait and still be effective.
• Proximity
• How soon the risk may impact the project
• Example: A supplier delay could affect the project next week
• High: The risk may impact the project very soon.
• Low: The risk may not impact the project until much later.
• Dormancy
• How long it takes to discover the impact after the risk
happens
• Example: A software bug occurs today, but the team does
not notice it until customers complain later
• High: The risk occurs, but the impact may not be discovered
for a long time.
• Low: The risk occurs, and the impact is discovered quickly.
• Manageability
• How easy it is to manage the risk or reduce its impact
• Example: If one team member is unavailable, the PM can
assign another trained person
• High: The risk owner can easily manage the risk or reduce its
impact.
• Low: The risk owner has limited ability to manage the risk or
reduce its impact.

[Link] [Link]
 Perform Risk Analysis
• Controllability
• How much control the project team has over the
risk outcome
• Example: The team can control internal testing
quality, but cannot control a major storm
• High: The risk owner has strong control over the
risk’s outcome.
• Low: The risk owner has little or no control over
the risk’s outcome.
• Detectability
• How easy it is to notice the risk before or when it
occurs
• Example: A schedule delay is easy to detect when
tasks are not being completed on time
• High: The risk can be detected and recognized
easily.
• Low: The risk is difficult to detect or recognize.
• Connectivity
• How much the risk is connected to other risks
• Example: A vendor delay can also cause schedule
delays, cost increases, and quality issues
• High: The risk is connected to many other project
risks.
• Low: The risk is mostly independent and not
connected to many other risks.

[Link] [Link]
 Perform Risk Analysis

[Link] [Link]
 Perform Risk Analysis - Inputs
• Project Management Plan
• Risk management plan - defines roles, the
methodology, and the probability/impact definitions
used during analysis.
• Scope, schedule, and cost baselines - the reference
points against which risk impacts are measured.
• Project Documents
• Assumption log - assumptions still in play that could
drive risk.
• Cost and duration estimates - their ranges feed into
quantitative risk analysis (e.g., Monte Carlo).
• Resource requirements - resource gaps may amplify
specific risks.
• Risk register - the primary input; provides the list of
individual risks to be analyzed and prioritized.
• Stakeholder register - identifies stakeholders whose
judgment will be used in probability/impact
assessments.
• EEFs and OPAs
• Industry studies, benchmarks, published risk
databases, organizational risk policies, and historical
risk data from similar projects.

[Link] [Link]
 Perform Risk Analysis - Tools
• Expert Judgment
• Specialists with prior experience in similar projects
estimate probability, impact, and other risk
parameters where data is limited.
• Data Gathering and Analysis
• Interviews - structured discussions with risk owners
and SMEs to elicit probability, impact, and other
parameters.
• Interpersonal and Team Skills
• Facilitation - improves the effectiveness of risk
workshops where probability and impact are
assessed.
• Risk Categorization
• Risks are grouped by sources, areas affected, or
other useful categories (often by RBS) to identify
areas of the project most exposed to risk.

[Link] [Link]
 Perform Risk Analysis - Tools
• Data Analysis - Qualitative
• Risk probability and impact assessment - examines the
likelihood of each risk and its potential effect on project
objectives.
• Data Analysis - Quantitative
• Simulations (typically Monte Carlo) - model the combined
effect of risks on project outcomes by running thousands of
trials with input variables sampled from probability
distributions.
• Sensitivity analysis - determines which individual risks have
the most potential impact on project outcomes (often
visualized as a tornado diagram).

[Link] [Link]
 Perform Risk Analysis - Tools
• Decision tree analysis - structures decisions under uncertainty by mapping options, probabilities, and outcomes to compute
Expected Monetary Value (EMV).

[Link] [Link]
 Perform Risk Analysis - Tools
• Influence diagrams - graphical aids for decision making
under uncertainty showing causal influences and time
ordering of events.
• Data Representation
• Probability and impact matrix - a grid that maps risk
probability against impact and assigns an overall risk rating
(low/moderate/high/very high).

[Link] [Link]
 Perform Risk Analysis - Output
• Project Document Updates
• Assumption log - new assumptions identified during
analysis.
• Issue log - issues identified during the analysis process.
• Risk Register Updates
• Probability and impact assessment for each individual
risk.
• Risk score and risk rating (low/moderate/high/very
high).
• Risk priority - the order in which risks should be
addressed.
• Risk categorization - which categories show the most
exposure.

• Risk Report Updates

• Assessment of overall project risk exposure.
• Prioritized list of individual project risks.
• Trends in quantitative risk analysis results.
• Recommended risk responses (input to Plan Risk
Responses).

[Link] [Link]
 Plan Risk Responses
• The process of developing options,
selecting strategies, and agreeing on
actions to address overall project risk
exposure and to treat individual project
risks
• Identifies appropriate ways to address
individual risks and the overall project risk
• Risk responses must be appropriate, cost-
effective, agreed upon, owned by a
responsible person, and timely

[Link] [Link]
 Plan Risk Responses

[Link] [Link]
 Plan Risk Responses - Inputs
• Project Management Plan
• Resource management plan - shows what
resources can be allocated to risk responses.
• Risk management plan - the playbook for
response planning, including roles and
contingency reserve rules.
• Cost baseline - establishes the funding
envelope; responses requiring additional
funding may need a baseline change.

[Link] [Link]
 Plan Risk Responses - Inputs
• Project Documents
• Lessons learned register - prior responses that
worked or didn't.
• Project schedule - drives when risk responses must
be implemented.
• Project team assignments - identifies who is
available to own and execute responses.
• Resource calendars - confirms when resources will
be available for response actions.
• Risk register - the prioritized list of risks awaiting
response strategies.
• Risk report - overall project risk exposure that must
be addressed at the project level.
• Stakeholder register - identifies stakeholders who
must approve or be involved in responses.
• EEFs and OPAs
• Stakeholder risk appetite, organizational risk
policies, templates for risk response plans, lessons
learned, and historical response strategies.

[Link] [Link]
Plan Risk Responses - Risk Response Strategies

[Link] [Link]
 Plan Risk Responses - Tools
• Expert Judgment
• Specialists with experience handling similar risks
(financial, technical, contractual, legal, negotiation).
• Data Gathering & Interpersonal Skills
• Interviews - structured conversations with risk owners
and SMEs to develop and refine response options.
• Facilitation - improves the effectiveness of response-
planning workshops.
• Contingent Response Strategies
• Pre-defined responses that are only executed if specific
trigger conditions occur.
• Strategies for Overall Project Risk
• Address total project risk exposure rather than
individual risks (may include adjusting the project
scope, schedule, cost, or quality plan).
• Data Analysis & Decision-Making
• Alternative analysis - compares response options.
• Cost-benefit analysis - quantifies whether the response
is worth the cost.
• Multicriteria decision analysis - selects among
responses by weighting multiple criteria.

[Link] [Link]
 Plan Risk Responses - Output
• Change Requests
• Planned responses often require changes
to baselines or other PM Plan components;
submitted via Integrated Change Control.
• Project Management Plan Updates
• Schedule, financial, quality, resource, and
procurement management plans may all be
updated to incorporate risk responses.
• Scope, schedule, and cost baselines may
change to reflect approved responses (e.g.,
adding contingency buffers).

[Link] [Link]
 Plan Risk Responses - Output
• Project Document Updates
• Assumption log - assumptions related to
chosen responses.
• Cost forecasts - updated to reflect cost of
responses.
• Lessons learned register - response-planning
lessons.
• Project schedule - response activities added.
• Project team assignments - owners assigned to
risk responses.
• Risk register - updated with chosen response
strategies, specific actions, owners, due dates,
and any residual or secondary risks.
• Risk report - updated with the agreed
responses for individual and overall project
risk.

[Link] [Link]
 Executing
• 8 Processes across all 4
domains
• Executes the project
management plan to build the
deliverables

[Link] [Link]
[Link] [Link]
 Manage Project Execution
• Where the team performs the work defined in the
project management plan.
• Complete deliverables and meet project
objectives.
• The project manager leads the team, coordinates
work, and aligns team knowledge and skills.
• Approved changes are implemented
• Deliverables are created as the team performs
planned project activities.
• Work performance data is collected and shared for
monitoring and controlling.
• Quality is managed by ensuring processes are
effective and deliverables meet agreed
requirements.
• In adaptive projects, work is executed based on
prioritized requirements or the sprint backlog.

[Link] [Link]
 Manage Project Execution

[Link] [Link]
 Manage Project Execution -
Inputs
• Project Management Plan
• Any component of the PM Plan may be an input -
the plan and its baselines guide what is executed
and how.
• Project Documents
• Change log - tracks all change requests and their
dispositions.
• Lessons learned register - captures and applies
knowledge gained earlier in the project.
• Milestone list - shows scheduled milestones the
execution work must hit.
• Project communications - prior reports,
presentations, and notes from stakeholders.
• Project schedule - identifies activities, dates, and
resources for execution.
• Requirements traceability matrix - links
requirements to deliverables being produced.
• Risk register and risk report - inform risk-based
execution decisions.
[Link] [Link]
 Manage Project Execution -
Inputs
• Approved Change Requests
• Change requests already approved by
Integrated Change Control are scheduled for
implementation as part of execution.
• EEFs and OPAs
• Stakeholder risk thresholds, infrastructure,
communication channels, organizational
policies, and templates that influence
execution.

[Link] [Link]
 Manage Project Execution -
Tools
• Expert Judgment
• Specialists with expertise in technical knowledge of the
industry and the focus of the project guide execution
decisions.
• Project Management Information System (PMIS)
• Software tools and infrastructure such as scheduling tools,
work authorization systems, configuration management
systems, information collection and distribution systems,
and dashboards.
• Provides automated access to information needed to
manage the project effectively.
• Meetings
• Used to discuss and address project issues during
executing.
• Daily coordination meetings (stand-ups in adaptive
projects) keep the team aligned on what was done, what is
being done, and any blockers.
• Other meetings include kickoff, technical, planning, and
status meetings.

[Link] [Link]
 Manage Project Execution -
Output
• Deliverables
• Any unique and verifiable product, result, or
capability to perform a service produced by the
project.
• Work Performance Data
• Raw observations and measurements
identified during activities (e.g., percent
complete, technical performance measures,
start/finish dates, costs, defects).
• Issue Log
• Documents project issues - what they are, who
is responsible, target resolution dates, and
status.

[Link] [Link]
 Manage Project Execution -
Output
• Change Requests
• Formal proposals to modify any document,
deliverable, or baseline. Submitted to Integrated
Change Control.
• May include corrective actions, preventive actions,
defect repairs, and updates to PM Plan.
• Project Management Plan Updates
• Any component of the PM Plan may be updated
based on changes resulting from execution.
• Project Document Updates
• Activity list, assumption log, lessons learned
register, requirements documentation, risk register,
and stakeholder register may all be updated during
execution.
• OPA Updates
• Updates to standards, guidelines, templates, and
lessons learned in the organization's process asset
library.

[Link] [Link]
 Manage Quality Assurance
• Manage Quality Assurance ensures project
processes are performed according to stakeholder
expectations.
• The key benefit is increasing the likelihood of
meeting project objectives.
• It helps identify ineffective processes and causes of
poor project performance.
• Quality assurance focuses on whether the project
processes are being followed effectively.
• It includes standards, compliance, regulations,
audits, and process improvement.
• Quality control focuses on whether the
deliverables meet defined specifications and
quality thresholds.
• Quality control includes testing, inspections,
defects, and product acceptance.

[Link] [Link]
 Manage Quality Assurance

[Link] [Link]
 Manage Quality Assurance -
Inputs
• Project Management Plan
• The quality management plan defines acceptable levels of
project and product quality, how to ensure they are met, and the
metrics used.
• Other components inform what processes are being executed
and how they should be assessed.
• Project Documents
• All relevant project documents - including the lessons learned
register, quality control measurements, quality metrics, and risk
report - feed quality assurance activities.
• Organizational Process Assets
• Policies - corporate quality policies, audit policies, and
compliance policies the project must follow.
• Procedures - standard processes used by the organization for
ensuring quality.
• Regulations - external rules (industry, government, legal) the
project work must comply with.

[Link] [Link]
 Manage Quality Assurance -
Tools
• Audits
• A structured, independent process used to
determine if project activities comply with
organizational and project policies, processes, and
procedures.
• Identifies all good and best practices being
implemented; identifies all gaps and shortcomings;
shares good practices with similar projects.
• Checklists
• A structured tool used to verify that a set of
required steps has been performed.

[Link] [Link]
 Manage Quality Assurance -
Tools
• Data Representation
• Affinity diagrams - organize potential causes of defects into
groups showing common areas to focus on.

[Link] [Link]
 Manage Quality Assurance -
Tools
• Data Representation
• Cause-and-effect diagrams (Ishikawa/fishbone) - break
down the causes of a problem into discrete branches that
help identify the main or root cause.

[Link] [Link]
 Manage Quality Assurance -
Tools
• Data Representation
• Flowcharts - show the steps of a process and help identify
quality issues or process improvement opportunities.

[Link] [Link]
 Manage Quality Assurance -
Tools
• Decision-Making, Problem-Solving, Process
Improvement
• Decision-making techniques (multicriteria, voting)
help select the best quality improvement option.
• Problem-solving uses methodical, structured
techniques to address quality issues.
• Process improvement (Six Sigma, Kaizen) identifies
activities that add no value and removes them.

[Link] [Link]
 Manage Quality Assurance -
Output
• Quality Reports
• Documents the results of quality assurance
activities, including issues that need to be
addressed, recommendations for improvement, and
information about quality findings.
• Change Requests
• Submitted when quality issues require process or
product changes; routed through Integrated Change
Control.
• Project Management Plan Updates
• The quality, scope, schedule, and cost management
plans may be updated based on the results of
quality assurance.
• Project Document Updates
• Issue log, lessons learned register, and risk register
may be updated as a result of quality assurance
activities.
[Link] [Link]
 Manage Project Knowledge
• Uses existing knowledge and creates new knowledge to
help achieve project objectives.
• It also captures new knowledge from the project for future
projects and organizational learning.
• Knowledge management includes both:
• Explicit knowledge: documented knowledge such as
manuals, procedures, databases, lessons learned, and
templates.
• Tacit knowledge: personal experience, insights, skills,
and judgment that are harder to document.
• Tacit knowledge is often shared through
conversations, mentoring, collaboration,
workshops, and team interactions.
• AI can help capture and organize knowledge, but AI
outputs must be validated and sensitive information must
be protected.

[Link] [Link]
 Manage Project Knowledge

[Link] [Link]
 Manage Project Knowledge -
Inputs
• Project Management Plan
• All components of the PM Plan are inputs because knowledge
must be managed across every aspect of the project.
• Project Documents
• Lessons learned register - captures knowledge gained so it can be
applied during the project and shared after closure.
• Project team assignments - identifies who has what knowledge
and skills.
• Resource breakdown structure - identifies team composition and
may help locate experts.
• Stakeholder register - identifies stakeholders who can provide
knowledge or who need to receive it.
• Deliverables
• Each deliverable's creation generates knowledge about how it
was produced and what worked.
• EEFs and OPAs
• Organizational culture and structure (impacts knowledge sharing
willingness), geographic distribution of facilities, knowledge
management systems, and lessons learned databases.

[Link] [Link]
 Manage Project Knowledge
- Tools
• Expert Judgment
• Specialists in knowledge management, information
management, organizational learning, and
knowledge and information management tools.
• Knowledge Management
• Connects people so they can work together to
create new knowledge, share tacit knowledge, and
integrate knowledge of diverse team members.
• Tools include networking, communities of practice,
meetings, and shadowing.
• Information Management
• Tools and techniques used to create and connect
people to explicit knowledge - including methods for
codifying explicit knowledge, lessons learned
register, and library services.

[Link] [Link]
 Manage Project Knowledge
- Tools
• After-Action Reviews & Postmortems
• After-action reviews - structured reviews after a phase or
milestone to capture what happened, why, and what to improve.
• In-progress postmortems - similar but conducted during the
project rather than at the end.
• Storytelling
• Sharing experiences, especially failures and successes, in narrative
form to transfer tacit knowledge.
• Retrospective Meetings
• Regular meetings (often used in adaptive projects) where the
team reflects on recent work and identifies improvements.
• Interpersonal and Team Skills
• Active listening - genuinely engaging with the speaker to
understand their full message.
• Facilitation - guiding group sessions to productive outcomes.
• Leadership - inspiring and motivating others to share knowledge.
• Networking - building relationships across the organization to
surface and share knowledge.
• Political awareness - understanding power and influence
dynamics that affect knowledge sharing.

[Link] [Link]
 Manage Project Knowledge -
Output
• Lessons Learned Register
• Created early in the project and updated
throughout.
• At project closure, finalized and added to the
organizational lessons learned repository.
• Project Management Plan Updates
• Any component of the PM Plan may be updated as
a result of new knowledge gained.
• Organizational Process Asset Updates
• Process documentation, templates, knowledge
bases, and lessons learned repositories are
updated for use by future projects.

[Link] [Link]
 Manage Stakeholder
Engagement
• The process of communicating and working
with stakeholders to meet their needs and
expectations, address issues, and foster
appropriate stakeholder engagement
• Allows the PM to increase support and
minimize resistance from stakeholders
• Involves activities such as engaging
stakeholders at appropriate stages,
managing expectations, addressing
concerns, and clarifying issues

[Link] [Link]
 Manage Stakeholder
Engagement

[Link] [Link]
 Manage Stakeholder Engagement -
Inputs
• Project Management Plan
• Communications management plan - dictates how engagement
communications are delivered.
• Risk management plan - guides handling of stakeholder-related
risks.
• Stakeholder engagement plan - identifies engagement strategies
and required engagement levels.
• Change management plan - prescribes how stakeholder concerns
leading to changes are processed.
• Project Documents
• Change log - lets stakeholders see what has changed and how
their concerns were addressed.
• Issue log - tracks stakeholder issues and resolutions.
• Lessons learned register - applies prior engagement lessons.
• Stakeholder register - the master list of who to engage.
• Risk register - identifies stakeholder-related risks.
• Status report - the artifact often delivered during engagement
activities.
• Project schedule - establishes timing for engagement activities.
• EEFs and OPAs
• Organizational culture, political climate, governance,
communication policies, change-management procedures, and
lessons learned.
[Link] [Link]
 Manage Stakeholder
Engagement - Tools
• Expert Judgment
• Specialists with knowledge of senior management,
the industry, communication and business analysis,
and the organization's political dynamics.
• Communication Skills
• Feedback - provides information about reactions to
communications, deliverables, and current project
status; essential for adjusting engagement.

[Link] [Link]
 Manage Stakeholder
Engagement - Tools
• Interpersonal and Team Skills
• Conflict management - the PM addresses conflict in a
timely and constructive manner to achieve a high-
performing team.
• Cultural awareness - helps the PM and the team to
communicate effectively by considering cultural
differences.
• Negotiation - achieving support or agreement that
supports the project work or its outcomes.
• Observation/conversation - keeps the PM in touch with
the work and attitudes of the team and stakeholders.
• Political awareness - understands the strategies of the
organization, who wields power and influence, and how to
leverage these strategies.
• Ground Rules
• Defined in the team charter; set expected behavior for
team members and stakeholders during engagement.
• Meetings
• Used to discuss and address any concerns or issues, report
on project performance, and engage stakeholders.

[Link] [Link]
 Manage Stakeholder
Engagement - Output
• Change Requests
• May result from engagement activities (e.g., a stakeholder raises
a concern that requires a change to scope, schedule, or another
aspect).
• Project Management Plan Updates
• Communications management plan - revised to fit lessons
learned during engagement.
• Stakeholder engagement plan - updated as engagement
experience reveals what works and what does not.
• Project Document Updates
• Change log - documents new change requests resulting from
engagement.
• Issue log - new issues raised by stakeholders are added; resolved
issues are closed.
• Lessons learned register - what worked and what did not in
engaging stakeholders.
• Stakeholder register - updated with new engagement levels or
new stakeholder information.

[Link] [Link]
 Manage Communications
• The process of ensuring timely and
appropriate collection, creation,
distribution, storage, retrieval,
management, monitoring, and
ultimate disposition of project
information
• Enables an efficient and effective
information flow between the project
team and stakeholders

[Link] [Link]
 Manage Communications

[Link] [Link]
 Manage Communications -
Inputs
• Project Management Plan
• Resource management plan - identifies the team members
responsible for producing and distributing communications.
• Communications management plan - the playbook driving what is
communicated, how, and when.
• Stakeholder engagement plan - identifies who to communicate
with and at what level.
• Project Documents
• Change log - communicated to relevant stakeholders.
• Issue log - issues and their statuses are communicated.
• Lessons learned register - useful for shaping future
communications.
• Quality report - quality status communicated to stakeholders.
• Risk report - overall risk exposure and individual risks
communicated.
• Stakeholder register - identifies recipients of each
communication.
• Work Performance Reports
• Performance information formatted for distribution to
stakeholders (status reports, dashboards, memos).
• EEFs and OPAs
• Organizational culture, regulatory requirements, communication
channels, communication policies, templates, and historical
communication artifacts.
[Link] [Link]
 Manage Communications -
Tools
• Communication Technology
• Email, instant messaging, video conferencing, intranets,
portals - the tools that physically transmit
communications.
• Communication Methods
• Interactive (face-to-face, calls, video), push (email,
reports), pull (portals, repositories).
• Communication Skills
• Communication competence - tailored communications
that consider stakeholder attitudes, knowledge level, and
expertise.
• Feedback - confirms the message was received and
understood; enables two-way communication.
• Nonverbal communication - tone, body language, and
appearance influence how messages are received.
• Presentations - formal delivery of information to
stakeholders, often with visual aids.

[Link] [Link]
 Manage Communications
- Tools
• PMIS & Project Reporting
• PMIS provides standard tools for distributing reports,
dashboards, and notifications to all stakeholders.
• Project reporting - the act of collecting and distributing
project information.
• Interpersonal and Team Skills
• Active listening - acknowledges and confirms
understanding.
• Conflict management - resolves communication conflicts.
• Cultural awareness - tailors messages to cultural norms.
• Meeting management - keeps meetings productive.
• Networking - builds informal communication channels.
• Political awareness - navigates organizational dynamics.
• Meetings
• Daily, weekly, milestone, and ad-hoc meetings to deliver
and discuss project information.

[Link] [Link]
 Manage Communications -
Output
• Project Communications
• Performance reports, deliverable status, schedule progress, and
cost incurred - the actual artifacts delivered to stakeholders.
• Format and frequency depends on the urgency and complexity of
the message and the audience.
• Project Management Plan Updates
• Communications management plan - updated when current
approach is shown to be ineffective.
• Stakeholder engagement plan - updated as engagement evolves
through communication.
• Project Document Updates
• Issue log, lessons learned register, project schedule, risk register,
and stakeholder register may all be updated based on
communication activities.
• Organizational Process Asset Updates
• Communication artifacts (presentations, reports, templates) may
be added to the OPA repository for use by future projects.

[Link] [Link]
 Acquire Resources
• The process of obtaining team
members, facilities, equipment,
materials, supplies, and other
resources necessary to complete
project work
• Outlines and guides the selection of
resources and assigns them to their
respective activities

[Link] [Link]
 Acquire Resources

[Link] [Link]
 Acquire Resources - Inputs
• Project Management Plan
• Resource management plan - identifies how resources are to
be acquired, the rules of preassignment, and the training
plan.
• Procurement management plan - guides external resource
acquisition through procurement.
• Cost baseline - provides the budget envelope for resource
acquisition.
• Project Documents
• Project schedule - identifies when each resource is needed;
drives acquisition timing.
• Resource calendars - existing or assumed availability
windows.
• Resource requirements - what skills, materials, and
equipment must be acquired.
• Stakeholder register - identifies stakeholders who can
influence or provide resources (functional managers,
vendors).
• EEFs and OPAs
• Existing information on organizational resources, personnel
administration policies, marketplace conditions,
organizational structure, geographic locations, and templates
for staff hiring/contracting.
[Link] [Link]
 Acquire Resources - Tools
• Decision-Making
• Multicriteria decision analysis - selects among candidate
resources by weighting criteria such as availability, cost,
experience, ability, knowledge, skills, attitude, and international
factors.
• Interpersonal and Team Skills
• Negotiation - used with functional managers (for internal
resources), vendors (for external), and other PMs competing for
the same resources.
• Problem-solving - addresses resource conflicts and shortages as
they arise.
• Preassignment
• When physical or team resources for a project are determined in
advance (e.g., named in the charter, promised in a proposal, or
required by contract).
• Virtual Teams
• Groups of people with a shared goal who fulfill their roles with
little or no time spent meeting face-to-face.
• Allows acquisition of resources from anywhere geographically;
requires good communication tools.

[Link] [Link]
 Acquire Resources - Output

• Physical or Virtual Resource Assignments

• Documents the actual physical resources (materials,
equipment, facilities) and virtual resources assigned
to the project.
• Project Team Assignments
• Documents the team members and their roles and
responsibilities for the project.
• Resource Calendars
• Identifies the working days, shifts, and start/end of
normal business hours when each specific resource
is available.

[Link] [Link]
 Acquire Resources - Output
• Change Requests
• May result when resource acquisition leads to
changes to the project plan (e.g., a different skill mix
requires schedule or cost adjustments).
• Project Management Plan Updates
• Resource management plan - reflects actual
experience.
• Cost baseline - may change due to actual resource
costs.
• Project Document Updates
• Lessons learned register, project schedule, resource
breakdown structure, resource requirements, risk
register, and stakeholder register may all be
updated.
• EEF & OPA Updates
• Resource availability information updated in the
organizational systems for use by future projects.
[Link] [Link]
 Lead the Team
• The process of tracking team member performance,
providing feedback, resolving issues, and managing
team changes to optimize project performance
• Encompasses developing the team and managing
team conflicts to improve interactions and overall
team performance
• Provides leadership, motivation, and support that
increases team performance
• Influences team behavior, manages conflict, and
resolves issues

[Link] [Link]
 Lead the Team

[Link] [Link]
 Lead the Team - Inputs
• Project Management Plan
• Resource management plan - guidance on how to manage and
release team members.
• Project Documents
• Issue log - documents issues that the leader must address.
• Lessons learned register - prior leadership lessons applied.
• Project schedule - drives when team activities occur and when
team development opportunities exist.
• Resource calendars - identify when team members are available.
• Team charter - documents team values and operating guidelines.
• Work performance reports - communicate status to the team and
identify areas needing leadership intervention.
• Project team assignments - identify team composition.
• Team Performance Assessments
• Formal or informal evaluations of team effectiveness used as the
basis for actions to improve performance.
• EEFs and OPAs
• HR management policies, performance management systems,
rewards programs, employee development, training records, and
security clearance procedures.

[Link] [Link]
 Lead the Team - Tools
• Colocation & Virtual Teams
• Colocation - placing many or all of the team in the
same physical location to enhance ability to
perform.
• Virtual teams - distributed teams enabled by
communication technology; expand the talent pool
but require deliberate engagement.
• Communication Technology & Virtual
Collaboration
• Email, chat, video conferencing, shared portals, and
collaboration platforms keep the team aligned
across geography and time zones.

[Link] [Link]
 Lead the Team - Tools
• Interpersonal and Team Skills
• Influencing - shaping team behavior without formal
authority through persuasion, building trust, and
demonstrating expertise.
• Motivation - providing reasons for team members to act;
intrinsic (autonomy, mastery, purpose) and extrinsic
(rewards, recognition).
• Negotiation - resolving competing demands and
agreements between team members.
• Team building - activities that enhance the team's social
relations and build a collaborative working environment.
• Decision-making - selecting between alternatives.
• Critical thinking - evaluating evidence and reasoning.
• Coaching and mentoring - developing team members'
skills and confidence.
• Training - formal skill development for team members.

[Link] [Link]
 Lead the Team - Tools
• Problem-Solving
• Six Thinking Hats: This is a problem-solving and decision-
making technique that encourages teams to look at a
situation from multiple perspectives.
• Each “hat” represents a different way of thinking,
helping teams avoid bias and consider all angles before
making decisions.
• The blue hat manages the process and focuses on the
big picture
• The white hat looks at facts and data
• The red hat expresses emotions and intuition
• The black hat identifies risks and potential problems
• The yellow hat focuses on benefits and positive
outcomes
• The green hat encourages creativity and new ideas
• Retrospectives
• Periodic team reflections to identify what is working and
what should change.

[Link] [Link]
 Lead the Team - Tools
Emotional Intelligence and Cultural Intelligence
• Emotional intelligence is the ability to understand and manage
your own emotions and the emotions of others.
• Project managers need emotional intelligence to stay calm, lead
effectively, manage conflict, and build trust.
• Daniel Goleman’s five elements of emotional intelligence are:
• Self-awareness: understanding your emotions and how they
affect others.
• Self-regulation: controlling reactions and staying calm under
pressure.
• Motivation: having the drive, persistence, and optimism to
achieve goals.
• Empathy: understanding other people’s feelings and
perspectives.
• Social skills: communicating, influencing, and building strong
relationships.
• Organizational cultural intelligence is the ability to work effectively
with people from different cultures and backgrounds.
• It means recognizing communication and work-style differences
without making assumptions or stereotypes.

[Link] [Link]
 Lead the Team - Tools
• Leadership Approaches
• Distributed Management and Leadership
• Decision-making and authority are shared across the team.
• Team members take ownership of work in their areas.
• Useful for collaborative, Agile, and self-organizing teams.
• Example: designers, developers, and testers make
decisions within their expertise.
• Centralized Management and Leadership
• Decision-making authority stays with one person or a small
leadership group.
• Work is directed from the top down.
• Useful when control, consistency, or fast direction is
needed.
• Example: the project manager assigns tasks and makes key
decisions.
• Servant Leadership
• The leader supports the team instead of controlling the
team.
• Focuses on removing blockers, providing resources, and
helping people succeed.
• Useful for empowering teams and improving collaboration.
• Example: the project manager helps the website team
solve issues so they can deliver quality work.

[Link] [Link]
 Lead the Team - Tools
Individual and Team Assessments
• Individual and team assessments help the project manager
understand how the team is performing.
• The project manager assesses both:
• Individual team members: strengths, weaknesses, skills,
behavior, and development needs.
• The team as a whole: collaboration, trust,
communication, conflict resolution, and decision-making.
• These assessments help identify performance gaps and
improvement opportunities.
• They can also help the project manager assign work, provide
coaching, build trust, and improve teamwork.
• Data Analysis & Meetings
• SWOT analysis applied to the team identifies strengths to build
on and weaknesses to address.
• Meetings - regular team meetings, one-on-ones, and all-hands
• PMIS & Virtual Tools
• Resource management, scheduling, performance reporting
tools, and virtual collaboration platforms.

[Link] [Link]
 Lead the Team - Tools
• Interpersonal and Team Skills
• Conflict management:

[Link] [Link]
 Lead the Team - Tools
• Conflict management steps:
• Identify the root cause of the problem
(not just the symptoms).
• Analyze the problem (cause-and-effect
diagram).
• Identify solutions.
• Implement the selected solution.
• Review the solution.
• Confirm that the solution solved the
problem.

[Link] [Link]
 Lead the Team - Tools
• Recognition and Rewards
• Maslow’s Hierarchy of Needs
• Maslow’s theory explains that people are motivated by
different levels of needs.
• Lower-level needs must usually be satisfied before
higher-level needs become strong motivators.
• The needs move from basic physical needs to higher
psychological and personal growth needs.

[Link] [Link]
 Lead the Team - Tools
• Recognition and Rewards
• Herzberg’s Hygiene and Motivational Factors
• Hygiene factors prevent dissatisfaction, such as salary,
policies, and work environment.
• Motivational factors create satisfaction, such as
achievement, growth, recognition, and advancement.
• Intrinsic vs. Extrinsic Motivation
• Extrinsic motivation comes from outside rewards, such
as pay or bonuses.
• Intrinsic motivation comes from inside the person, such
as autonomy, mastery, and purpose.
• McClelland’s Theory of Needs
• Achievement: motivated by challenging goals and
accomplishment.
• Power: motivated by leadership, influence, and
responsibility.
• Affiliation: motivated by belonging, teamwork, and
relationships.
• Theory X, Theory Y, and Theory Z
• Theory X: assumes people dislike work and need close
supervision.
• Theory Y: assumes people are self-motivated and want to
do good work.
• Theory Z: focuses on meaning, values, loyalty, well-being,
and long-term commitment.
[Link] [Link]
 Lead the Team - Tools
(Myers-Briggs Type Indicator
MBTI helps project managers understand different
personality types and work preferences.
• It can improve communication, teamwork, conflict
management, and leadership.
• MBTI groups people into 16 personality types based
on four areas:
• Extroversion vs. Introversion: how people
focus their energy.
• Sensing vs. Intuition: how people take in
information.
• Thinking vs. Feeling: how people make
decisions.
• Judging vs. Perceiving: how people approach
structure and flexibility.
• In the Lead the Team process, MBTI can help the
project manager adapt their leadership style.
• Diagram:
• [Link]
riggs_Type_Indicator
[Link] [Link]
(Myers-Briggs Type Indicator Lead the Team - Tools

• Diagram:
• [Link]

[Link] [Link]
 Lead the Team - Tools

[Link] [Link]
 Lead the Team - Tools
Common Schedule Behaviors
• Student Syndrome: delaying work until the last possible
moment.
• Example: A developer has 5 days to finish a task but
waits until day 4 to start.
• Parkinson’s Law: work expands to fill the time available.
• Example: A task that could take 2 days stretches to 5
days because 5 days were scheduled.
• Self-Protection: hiding delays or problems to avoid blame.
• Example: A team member knows a website feature is
behind but does not report it until the last minute.
• Sandbagging: intentionally overestimating time or effort to
look better later.
• Example: A developer says a task will take 10 days
even though it can be done in 5.
• Dropped Baton: work is handed off poorly and information
is missed.
• Example: A designer does not clearly explain
requirements to the developer, causing rework.

[Link] [Link]
 Lead the Team - Output
• Team Performance Assessments
• The PM evaluates and addresses team performance regularly.
• Indicators include improvements in skills, improvements in
competencies, reduced staff turnover rate, and increased team
cohesiveness.
• Change Requests
• Resource changes (additions, removals) and other leadership-
driven adjustments processed through Integrated Change
Control.
• Project Management Plan Updates
• Resource management plan, schedule baseline, and cost baseline
may be updated.
• Project Document Updates
• Issue log, lessons learned register, project schedule, resource
calendars, team charter, and project team assignments may all be
updated.
• EEF & OPA Updates
• Input to organizational performance appraisals, personnel skill
updates, lessons-learned templates, and training needs.

[Link] [Link]
 Implement Risk Responses
• The process of implementing agreed-upon
risk response plans
• Ensures that planned risk responses are
executed as planned to address overall
project risk exposure, minimize threats, and
maximize opportunities
• Without implementation, risk responses are
merely good intentions on paper - this is
where the actual risk-reduction work
happens

[Link] [Link]
 Implement Risk Responses

[Link] [Link]
 Implement Risk Responses -
Inputs
• Project Management Plan
• Risk management plan - documents the roles,
responsibilities, and authority of each team member
when implementing risk responses.
• Project Documents
• Lessons learned register - prior implementation lessons
applied (what worked, what failed during execution).
• Risk register - documents the agreed response strategies
for each risk along with the assigned owner and any
specified actions to take.
• Risk report - documents the current overall project risk
exposure and the agreed response strategy.
• Organizational Process Assets
• Lessons learned repository from similar completed
projects with details of risk implementation.

[Link] [Link]
 Implement Risk Responses -
Tools
• Expert Judgment
• Specialists with expertise in validating or modifying risk
responses if needed and deciding how to implement them
most efficiently and effectively.
• Interpersonal and Team Skills
• Influencing - the PM may need to influence the risk owner
(or others involved) to take the necessary action on time.
Especially important when the PM lacks formal authority
over the owner.
• Project Management Information System
• PMIS includes scheduling, resource, and cost software to
ensure agreed risk response plans and their associated
activities are integrated into the project alongside other
project activities.

[Link] [Link]
 Implement Risk Responses -
Output
• Change Requests
• Implementing risk responses may require changes to the
cost or schedule baselines, or other components of the
PM Plan; processed through Integrated Change Control.
• Project Document Updates
• Issue log - new issues raised during implementation (e.g.,
a planned response failed) are recorded.
• Lessons learned register - updated with effective and
ineffective responses to inform future projects.
• Project team assignments - team member assignments
may be updated as risk responses are executed.
• Risk register - updated with the results of executing the
responses (including any secondary or residual risks).
• Risk report - updated to reflect the current status of
significant agreed-upon risk responses and current overall
project risk exposure.

[Link] [Link]
 Monitoring and
Controlling
• 10 Processes
• Ensures the work follows the
project management plan
• Reports on the progress of the
project

[Link] [Link]
[Link] [Link]
 Monitor and Control Project
Performance
• Monitoring is ongoing throughout the project and
focuses on collecting, measuring, and assessing
project data.
• Controlling means taking corrective or preventive
action, replanning when needed, and following up to
resolve issues.
• This process compares actual performance against
the project plan.
• It tracks work completed, resources used, budget
spent, risks, changes, and deliverable status.
• It provides stakeholders with accurate information
about project health and progress.
• It helps determine whether deliverables are on track
to meet planned benefits and acceptance criteria.

[Link] [Link]
 Monitor and Control Project
Performance
• Measurement should focus only on useful, relevant,
and actionable metrics.
• Metrics should be SMART: specific, measurable,
achievable, relevant, and time-bound.
• Common measurement pitfalls include:
• Hawthorne effect: people change behavior
because they know they are being measured.
• Vanity metrics: data that looks good but does
not help decision-making.
• Demoralization: unrealistic goals can hurt
morale.
• Misusing metrics: focusing on the wrong
measures or short-term numbers.
• Confirmation bias: interpreting data to support
what you already believe.
• Correlation vs. causation: assuming one thing
caused another without proof.
[Link] [Link]
 Monitor and Control Project
Performance

[Link] [Link]
 Monitor and Control Project
Performance - Inputs
• Project Management Plan
• Any component of the PM Plan, especially the baselines (scope,
schedule, cost, performance measurement) used as the
comparison reference.
• Project Documents
• Assumption log - assumptions and constraints to be monitored.
• Basis of estimates - reference for evaluating cost and schedule
variances.
• Cost forecasts - projections of future costs based on current
performance.
• Issue log - tracks open project issues that may affect
performance.
• Lessons learned register - captures and applies learning during
monitoring.
• Milestone list - milestones being tracked for schedule status.

[Link] [Link]
 Monitor and Control Project
Performance - Inputs
• Project Documents (cont.)
• Quality reports - quality status that may affect overall
performance.
• Risk register and risk report - identified risks and overall risk
exposure.
• Schedule forecasts - projected future schedule performance.
• Work Performance Information
• Performance data analyzed and integrated based on comparisons
across knowledge areas (e.g., status of deliverables, status of
change requests, forecasted estimates to complete).
• Agreements
• Contracts that govern work and contain performance metrics that
must be monitored.
• EEFs and OPAs
• Project management information systems, stakeholder
expectations and risk thresholds, monitoring policies and
templates.

[Link] [Link]
 Monitor and Control Project
Performance - Tools
• Expert Judgment
• Specialists in interpretation of information, techniques to
identify project performance trends, and statistical
analysis.
• Data Analysis
• Alternative analysis - selects corrective or preventive
actions when variances occur.
• Cost-benefit analysis - determines best corrective action in
terms of cost and benefit.
• Earned value analysis - integrates scope, schedule, and
cost measures (PV, EV, AC) to assess performance and
progress.
• Root cause analysis - identifies the main reason for
variances.
• Trend analysis - examines past results to predict future
performance.
• Variance analysis - reviews differences between planned
and actual performance.

[Link] [Link]
 Monitor and Control Project
Performance - Tools
• Decision-Making
• Voting and other techniques used to converge on
corrective or preventive actions.
• Meetings, Dashboards, Visual Controls
• Status meetings, project review meetings, and
inspection meetings used to communicate
performance.
• Project dashboards consolidate KPIs in real time.
• Visual controls and information radiators (kanban
boards, burn-down charts) make project status
visible to all stakeholders.

[Link] [Link]
 Monitor and Control Project
Performance - Output
• Work Performance Reports
• Physical or electronic representation of work performance
information intended to generate decisions, actions, or
awareness.
• Examples: status reports, memos, justifications, information
notes, electronic dashboards, recommendations, and updates.
• Change Requests
• Generated when actual performance deviates from the plan
beyond thresholds.
• Includes corrective actions, preventive actions, defect repairs, and
updates to plan/baselines.
• Project Management Plan Updates
• Any component of the PM Plan may be updated based on
performance findings (often after change-request approval).
• Project Document Updates
• Cost forecasts, issue log, lessons learned register, risk register, and
schedule forecasts are updated to reflect current performance
and projections.

[Link] [Link]
 Assess and Implement
Changes
• The process of reviewing all change requests,
approving and managing changes to deliverables,
project documents, and the project management
plan, and communicating the decisions
• Also known as Perform Integrated change control
• Reviews requests on the impact on scope, schedule,
cost, quality, resources, and risks before approval
• Approved changes are implemented through the
executing processes; rejected changes are recorded
in the change log

[Link] [Link]
 Assess and Implement
Changes
• Predictive Approach
• In predictive projects, changes are formally controlled after baselines are
established.
• Once a baseline exists, changes to scope, schedule, cost, resources, risk, or
other controlled artifacts require a formal change request.
• Change requests should be documented in writing and entered into the
change control system.
• Each change request should include impact analysis, such as cost, schedule,
scope, resource, stakeholder, and risk impacts.
• A change request may involve:
• Corrective action
• Preventive action
• Defect repair
• Updates
• The change may be approved, rejected, deferred, or sent back for more
information.
• A change control board may review and decide on changes when required.
• While waiting for a decision, the project team should continue approved
project work.
• Approved changes may require updates to the project management plan,
project documents, cost estimates, schedule, resources, and risk responses.

[Link] [Link]
 Assess and Implement
Changes

[Link] [Link]
 Assess and Implement
Changes
• Adaptive Approach
• In adaptive projects, changes are usually managed
through the product backlog, not a formal change
request process.
• Stakeholder change ideas are captured as backlog
items.
• Changes are continuously reviewed, assessed, and
prioritized during the project.
• Impact analysis is still performed to understand
effects on value, scope, time, cost, risk, and priorities.
• There is usually no formal approval process like in
predictive projects.
• If the change has value, it can be added to the
backlog and prioritized.
• If the change is low priority, it is effectively deferred.
• If the change is not added or is removed from the
backlog, it is effectively rejected.
[Link] [Link]
 Assess and Implement
Changes

[Link] [Link]
 Assess and Implement Changes
- Inputs
• Project Management Plan
• Change management plan - defines how changes will be managed and
controlled.
• Configuration management plan - defines those items that are
configurable, those that require formal change control, and the
process for controlling changes.
• Scope, schedule, and cost baselines - the references against which
changes are evaluated.
• Project Documents
• Basis of estimates - shows how the cost, duration, and resource
estimates were derived; used to evaluate the impact of changes.
• Change log - records all change requests and their current
dispositions.
• Requirements traceability matrix - tracks impact of changes on
requirements.
• Risk report - identifies overall project risk and impacts of proposed
changes on risk exposure.
• Work Performance Reports
• Used by the CCB to assess change requests in the context of current
project performance.
• Change Requests
• Formal proposals to modify any document, deliverable, or baseline -
the main work item for this process.
• EEFs and OPAs
• Government and industry regulations, change control procedures,
configuration management knowledge base, and templates.
[Link] [Link]
 Assess and Implement Changes -
Tools
• Expert Judgment
• Specialists in technical knowledge of the industry,
legal/regulatory matters, change control, configuration
management, risk, and quality assess change requests.
• Change Control Tools
• Change control tools can be manual or automated and
should be selected based on stakeholder needs,
organizational rules, and project constraints.
• Configuration control focuses on identifying, tracking,
verifying, and auditing project deliverables and processes.
• Change control focuses on documenting, reviewing,
approving, rejecting, or deferring changes to project
documents, deliverables, or baselines.
• These tools help ensure changes are registered, assessed,
communicated, and controlled so the project maintains
accountability and alignment.
• Data Analysis
• Alternative analysis - evaluates options for implementing
the change.
• Cost-benefit analysis - determines if the change is
worthwhile based on cost vs benefit.
[Link] [Link]
 Assess and Implement Changes -
Tools
• Decision-Making
• Voting - reaching a decision through unanimity, majority, or plurality.
• Autocratic decision-making - one person decides for the group (used when
speed is critical).
• Multicriteria decision analysis - evaluates change requests against multiple
weighted criteria.
• Meetings,
• Change control meetings - convened by the CCB to review change requests
and decide on approval, deferral, or rejection.
• Backlog management
• in adaptive projects, ongoing reprioritization and refinement of the backlog
handles many change requests.
• Integrated change control
• Integrated change control ensures project changes are managed in a
coordinated and controlled way.
• Change requests are reviewed and analyzed before decisions are made.
• Impact analysis helps evaluate effects on scope, schedule, cost, resources,
risk, and stakeholders.
• Decisions are documented, communicated, and implemented only after
approval.

[Link] [Link]
 Assess and Implement Changes - Integrated Change Control
Process
1 Submit 2 Log 3 Assess 4 CCB Decide

Anyone submits a Change Request: PM logs in Change Log. Team analyzes impact on Change Control Board reviews
what, why, impact, urgency. Assigns CR ID and status. scope, schedule, cost, quality, and decides:
resources, risk. Approve / Defer / Reject.

APPROVED DEFERRED REJECTED

Update baselines + plans. Hold for later review. Document the rationale.
Implement via executing Keep on the change log. Notify the requester.
processes.

Every change request follows the same flow: Submit -> Log -> Assess -> CCB Decide -> Communicate. Decisions branch to Approved, Deferred, or Rejected.

[Link] [Link]
 Assess and Implement Changes -
Output
• Approved Change Requests
• Change requests that have been processed and approved by the
responsible party (PM, sponsor, or CCB).
• Become inputs to the executing processes for implementation.
• Project Management Plan Updates
• Any component of the PM Plan may be updated as a result of
approved changes - including baselines, which can only be
changed via formal change control.
• Project Document Updates
• Change log - updated to reflect dispositions of all change requests
(approved, deferred, rejected, withdrawn).
• Notification of disposition is sent to the requestor and all affected
stakeholders.

[Link] [Link]
[Link] [Link]
 Monitor and Control
Scope
• Monitor and Control Scope is the ongoing
process of tracking and managing project
scope.
• It ensures changes to scope are reviewed,
controlled, and processed properly.
• It checks that deliverables remain aligned
with the scope baseline and quality
requirements.
• The process monitors results to determine
whether deliverables meet stakeholder
expectations.
• It helps prevent uncontrolled scope
changes and scope creep.
[Link] [Link]
 Monitor and Control Scope

[Link] [Link]
 Monitor and Control Scope -
Inputs
• Project Management Plan
• Scope management plan - defines how scope changes will be
processed.
• Quality management plan - defines how product quality will be
verified, supporting scope monitoring.
• Project Documents
• Requirements documentation - basis for confirming actual
deliverables match what was requested.
• Performance measurement baseline - the integrated scope,
schedule, and cost baseline used as the comparison reference.
• Quality test and evaluation documents - test plans, test results,
and inspection records.
• Quality Metrics
• Specific measurable attributes a deliverable must satisfy.
• Approved Change Requests
• Requests already approved through Integrated Change Control
that affect scope.
• Deliverables
• Output of project work that must be measured against the scope
baseline.
• EEFs and OPAs
• Quality control standards, scope-related policies, checklists,
lessons learned, and historical information.
[Link] [Link]
 Monitor and Control Scope -
• Data Analysis
Tools
• Variance analysis - compares baselines to actual results to
determine if variances are within acceptable thresholds.
• Trend analysis - examines project performance over time
to determine whether performance is improving or
degrading.
• Root cause analysis - identifies the underlying cause of
any scope variance so corrective action can address the
source.
• Performance Reviews
• Comparison and analysis of work performed against the
scope baseline at scheduled intervals.
• Audits and Inspections
• Examination of work products and processes to confirm
scope is being followed and quality standards are being
met.

[Link] [Link]
 Monitor and Control Scope -
Tools
• Testing/Product Evaluations
• Structured tests and evaluations to confirm
deliverables meet documented requirements before
acceptance.
• Data Representations
• Charts and graphs (control charts, scatter diagrams,
histograms) used to visualize scope status and
detect patterns.
• Process Automations
• Automated tools (CI/CD, automated testing,
monitoring systems) that continuously verify scope
compliance.

[Link] [Link]
 Monitor and Control Scope -
Output
• Quality Reports
• Document the status of quality activities and any scope-
related quality issues.
• Verified Deliverables
• Deliverables that have passed quality control and are
ready to be sent to Validate Scope for customer
acceptance.
• Change Requests
• Submitted to Integrated Change Control for any required
corrective actions, preventive actions, or defect repairs.
• Quality Control Measurements
• Documented results of QC activities used to evaluate the
quality processes.

[Link] [Link]
 Validate Scope
• Validate Scope is the process of formally
accepting completed deliverables.
• It confirms that deliverables meet the
agreed requirements and quality standards.
• Stakeholders review the deliverables and
provide formal acceptance.
• This process helps increase the chance that
the final product, service, or result will be
accepted.
• It also helps ensure the delivered work
provides value and meets expectations.

[Link] [Link]
 Validate Scope

[Link] [Link]
 Validate Scope - Inputs
• Project Documents
• Requirements documentation - the detailed requirements
against which deliverables are validated.
• Scope baseline - the approved scope statement, WBS, and
WBS dictionary used to confirm what was supposed to be
delivered.
• Quality reports - results of QA activities that may highlight
issues affecting acceptance.
• Work performance data - actual progress data on each
deliverable.
• Quality control measurements - inspection results that
support objective acceptance.
• Verified Deliverables
• Project deliverables that have been verified by Control
Quality and are ready for formal acceptance by the
customer or sponsor.
• EEFs and OPAs
• Customer review processes, project management
information systems, organizational acceptance
procedures, and templates.

[Link] [Link]
 Validate Scope - Tools
• Data Gathering
• Techniques like interviews and questionnaires used to collect
customer feedback on deliverables.
• Data Analysis
• Comparison of deliverables against acceptance criteria
documented in the scope statement and requirements.
• Inspection
• Examining a work product to determine whether it conforms to
documented standards (also called walkthroughs, audits,
reviews).
• Decision-Making
• Voting or other techniques used to reach a conclusion on
whether to accept, reject, or request changes to deliverables.
• Customer Talks and Tests
• Discussions with the customer and structured tests (including
UAT) to confirm deliverables meet expectations.
• Process Analysis
• Examination of the validation process itself to identify
improvements.
• Review Meetings
• Formal sessions where deliverables are walked through with the
customer or sponsor for sign-off.

[Link] [Link]
 Validate Scope - Output
• Accepted Deliverables
• Deliverables that meet acceptance criteria and are formally
signed off by the customer or sponsor.
• Documentation of acceptance is sent to the Close Project or
Phase process.
• Change Requests
• Deliverables that are not accepted may have a change request
submitted, which is then processed via integrated change control.
• Project Document Updates
• Quality reports - updated with validation outcomes.
• Work performance information - documents which deliverables
were accepted, rejected, or returned with feedback.
• Requirements documentation - updated to reflect any approved
changes.
• Lessons Learned Updates
• Captures techniques that were effective at validating scope,
common reasons deliverables were rejected, and improvements
for future projects.

[Link] [Link]
 Monitor and Control
Schedule
• Tracks project progress and updates the schedule
based on actual or forecasted performance.
• The key benefit is keeping the project schedule
realistic throughout the project.
• In predictive projects, changes to the schedule
baseline must go through integrated change control.
• In adaptive projects, the focus is on velocity, backlog
reprioritization, retrospectives, and accepted work
per iteration.
• For contracted work, supplier status reports,
milestone updates, and walkthroughs help verify
schedule progress.

[Link] [Link]
 Monitor and Control
Schedule

[Link] [Link]
 Monitor and Control Schedule -
Inputs
• Project Management Plan
• Schedule management plan - defines how schedule will be managed
and controlled.
• Scope baseline - reference for assessing scope-related schedule
impacts.
• Performance measurement baseline - integrated scope, schedule, and
cost baseline used for variance analysis.
• Product Backlog
• In adaptive projects, the prioritized list of features that drives sprint
planning and release scheduling.
• Project Documents
• Lessons learned register - applies prior schedule-control lessons.
• Project calendars / Resource calendars - identify working days and
resource availability.
• Project schedule - current approved schedule against which actuals
are compared.
• Risk register - identifies schedule risks and their responses.
• Schedule data - supplementary data used to model the schedule.
• Work Performance Data
• Raw observations: which activities have started, percent complete,
finish dates, and duration of completed activities.
• EEFs and OPAs
• Schedule control standards, project management information
systems, schedule monitoring policies, templates, and lessons
learned.
[Link] [Link]
 Monitor and Control Schedule -
Tools
• Data Analysis
• Earned value analysis - schedule variance (SV) and
schedule performance index (SPI) measure schedule
performance.
• Burnup/burndown chart - visualizes work remaining over
time vs the ideal trajectory in adaptive projects.
• Performance reviews - measure, compare, and analyze
schedule performance against the baseline.
• Trend analysis - examines project performance over time
to determine if schedule performance is improving or
deteriorating.
• Variance analysis - investigates differences between
baseline and actual performance.
• What-if scenario analysis - assess feasibility of the
schedule under adverse conditions.
• Critical Path & Critical Chain Methods
• Used to update the schedule and confirm whether the
critical path has shifted.

[Link] [Link]
 Monitor and Control Schedule -
Tools
• PMIS & Resource Optimization
• PMIS provides schedule reporting and tracking. Resource
optimization adjusts schedule based on availability.
• Schedule Compression
• Crashing or fast tracking applied to recover slipped
schedule (with cost or risk impact).
• Adaptive Techniques
• Velocity - average story points completed per sprint, used
to forecast remaining work.
• Daily coordination meetings (stand-ups), sprint reviews,
backlog refinement keep the team aligned and the
schedule current.

[Link] [Link]
 Monitor and Control Schedule -
Output
• Work Performance Information
• Performance data analyzed in context: SV, SPI, schedule forecasts,
completed activities, and current critical path status.
• Schedule Forecasts
• Estimates or predictions of conditions and events in the future
based on current performance information.
• Change Requests
• Variance analysis, performance reviews, and progress meetings
can lead to change requests for corrective or preventive actions.
• Project Management Plan Updates
• Schedule management plan, schedule baseline, cost baseline, and
performance measurement baseline may all be updated through
change control.
• Project Document Updates
• Assumption log, basis of estimates, lessons learned register,
project schedule, resource calendars, risk register, and schedule
data are updated to reflect current state.

[Link] [Link]
 Monitor and Control
Finances
• Monitor and Control Finances tracks and
manages the project’s financial health
throughout the project.
• It compares actual costs against planned
costs to identify variances.
• It includes tracking expenditures, updating
financial records, and monitoring the cost
baseline.
• It may also involve updating revenue
forecasts, cost savings projections, or
financial benefits.
• Corrective actions are taken when costs,
forecasts, or financial risks move off track.
[Link] [Link]
 Monitor and Control Finances

[Link] [Link]
 Monitor and Control Finances -
Inputs
• Project Management Plan
• Financial management plan - the rules under which monitoring
and controlling are performed.
• Cost baseline - the reference against which actual costs are
compared.
• Performance measurement baseline - the integrated scope,
schedule, and cost baseline used in EVA.
• Project Documents
• Lessons learned register - applies prior cost-control lessons.
• Project funding requirements - includes projected and actual
funding consumed.
• Work Performance Data
• Raw observations on costs incurred, work completed, and
schedule progress used to calculate EVA metrics.
• Organizational Process Assets
• Existing financial controls, cost variance thresholds, monitoring
policies, financial reporting templates, and lessons learned.

[Link] [Link]
 Monitor and Control Finances -
Tools
• Expert Judgment
• Specialists in financial analysis, EVA, forecasting, and the relevant
industry interpret cost performance.
• Data Analysis
• Earned value analysis (EVA) - integrates PV (Planned Value), EV
(Earned Value), and AC (Actual Cost) to compute CV, SV, CPI, and
SPI.
• Trend analysis - examines project performance over time to
determine if performance is improving or deteriorating; feeds
forecasting.
• Reserve analysis - monitors the use of contingency and
management reserves; reserves may be reduced or returned as
risks pass.
• To-Complete Performance Index (TCPI)
• Measures the cost performance required to be achieved on the
remaining work to meet a specified management goal.
• TCPI = (BAC - EV) / (BAC - AC) - the efficiency that must be
maintained to complete on the original budget.
• Project Management Information System (PMIS)
• Software tools used for monitoring PV, EV, and AC; graphical
displays; trending; and reporting forecasts.
[Link] [Link]
 Monitor and Control Finances -
Output
• Work Performance Information
• Performance data analyzed in context: cost variance (CV),
schedule variance (SV), CPI, SPI, EAC, ETC, VAC, and TCPI
calculations and analyses.
• Revenue and Cost Forecasts
• Estimate at Completion (EAC) - what the project will cost
at completion based on current performance.
• Estimate to Complete (ETC) - the cost expected to be
incurred to complete the remaining work.
• Change Requests
• Variance analyses or trend analyses lead to change
requests for corrective or preventive actions.

[Link] [Link]
 Monitor and Control Finances -
Output
• Funding Proposals
• When the project requires additional funding (e.g., scope
increase, risk realization), formal proposals are submitted
to the funding authority.
• Project Management Plan Updates
• Financial management plan, cost baseline, and
performance measurement baseline may be updated
through change control.
• Project Document Updates
• Assumption log, basis of estimates, cost estimates, lessons
learned register, and risk register may all be updated
based on cost performance and forecasts.

[Link] [Link]
 Monitor Stakeholder
Engagement
• Monitor Stakeholder Engagement checks whether
stakeholder engagement efforts are working
effectively.
• It helps identify when stakeholder relationships,
communication, or participation need
improvement.
• The process is performed throughout the project as
stakeholders and project conditions change.
• It may require updating engagement strategies,
communication approaches, or project plans.
• The key benefit is maintaining or improving
stakeholder support and involvement.

[Link] [Link]
 Monitor Stakeholder
Engagement

[Link] [Link]
 Monitor Stakeholder
Engagement - Inputs
• Project Management Plan
• Resource management plan - identifies team members and their roles
in monitoring engagement.
• Communications management plan - frames the communications
used to monitor engagement.
• Stakeholder engagement plan - documents the desired engagement
levels against which actuals are compared.
• Project Documents
• Issue log - issues raised by or about stakeholders indicate engagement
quality.
• Lessons learned register - prior monitoring approaches that worked or
did not.
• Project communications - actual communications delivered to
stakeholders.
• Risk register - identifies stakeholder-related risks that may have
changed.
• Stakeholder register - the list against which engagement is monitored.
• Work Performance Data
• Raw observations: which stakeholders attended meetings, responded
to communications, raised issues, or are actively supporting/resisting
the project.
• EEFs and OPAs
• Organizational culture, communications expectations, stakeholder
feedback channels, monitoring tools, and lessons learned.

[Link] [Link]
 Monitor Stakeholder
Engagement - Tools
• Data Analysis
• Alternative analysis - evaluates options for adjusting
engagement when the current approach is not working.
• Root cause analysis - identifies underlying reasons for
engagement gaps.
• Stakeholder analysis - reassesses stakeholder positions,
interests, and influence as the project evolves.
• Decision-Making
• Multicriteria decision analysis - prioritizes engagement
interventions across multiple criteria.
• Voting - converges on the best response to an
engagement issue.
• Data Representation
• Stakeholder engagement assessment matrix - updated to
show current vs desired engagement and any gaps.

[Link] [Link]
 Monitor Stakeholder
Engagement - Tools
• Communication Skills
• Feedback - actively solicited from stakeholders to gauge
satisfaction and understanding.
• Presentations - used to share status and elicit
engagement.
• Interpersonal and Team Skills
• Active listening - reduces misunderstandings and improves
engagement.
• Cultural awareness - tailors monitoring approach to
cultural norms.
• Leadership - inspires and motivates stakeholder
engagement.
• Networking - builds informal channels to gauge
engagement quality.
• Political awareness - navigates organizational dynamics.
• Meetings
• Status meetings, retrospectives, and one-on-ones used to
monitor and adjust engagement.
[Link] [Link]
 Monitor Stakeholder
Engagement - Output
• Work Performance Information
• Status of stakeholder engagement: which stakeholders are
supportive, which are resistant, and where engagement gaps
exist.
• Change Requests
• May include corrective actions to engagement strategies or
preventive actions to reduce stakeholder-related risks.
• Project Management Plan Updates
• Resource management plan - may need additional resources to
engage stakeholders.
• Communications management plan - revised based on what is
and is not working.
• Stakeholder engagement plan - updated with revised engagement
strategies.
• Project Document Updates
• Issue log - new stakeholder issues added.
• Lessons learned register - updated with monitoring lessons.
• Risk register - updated as stakeholder-related risks change.
• Stakeholder register - updated with new engagement levels and
any new stakeholders identified.

[Link] [Link]
 Monitor
Communications
• The process of ensuring the information
needs of the project and its stakeholders are
met
• Determines whether the planned
communication artifacts and activities are
having the desired effect of increasing or
maintaining stakeholder support for the
project

[Link] [Link]
 Monitor Communications

[Link] [Link]
 Monitor Communications -
Inputs
• Project Management Plan
• Resource management plan - identifies the resources available to
monitor communications.
• Communications management plan - the reference for what
should be happening.
• Stakeholder engagement plan - documents stakeholder
engagement and communication strategies.
• Project Documents
• Issue log - communications-related issues are tracked here.
• Lessons learned register - prior monitoring lessons applied.
• Project communications - actual communications delivered to
stakeholders, used as evidence of effectiveness.
• Work Performance Data
• Raw observations on what was communicated, when, to whom,
and the responses received.
• EEFs and OPAs
• Organizational culture, project management body of knowledge
for similar projects, established communication channels,
monitoring policies, and templates.

[Link] [Link]
 Monitor Communications -
Tools
• Expert Judgment
• Specialists in communications, public relations, and the
relevant subject matter help interpret communication
effectiveness.
• Project Management Information System
• Provides a set of standard tools for the PM to capture,
store, and distribute information; metrics from the PMIS
show whether communications are being read and acted
on.
• Data Representation
• Stakeholder engagement assessment matrix - shows
current engagement levels which can be tracked against
desired.
• Interpersonal and Team Skills
• Observation/conversation - direct dialogue with team
members and stakeholders to identify communication
issues.
• Meetings
• Discussions with stakeholders to confirm communications
are reaching them and being understood.
[Link] [Link]
 Monitor Communications -
Output
• Work Performance Information
• Information on how project communication is performing:
stakeholder feedback, response rates, channel effectiveness, gaps
in coverage.
• Change Requests
• Change requests submitted via Integrated Change Control to
revise communication processes, technology, or content.
• Project Management Plan Updates
• Communications management plan - updated to reflect what was
learned about the effectiveness of various approaches.
• Stakeholder engagement plan - updated as engagement patterns
are observed.
• Project Document Updates
• Issue log - communications issues recorded and tracked.
• Lessons learned register - what worked and what didn't in
monitoring communications.
• Stakeholder register - updated with new communication
preferences uncovered.

[Link] [Link]
 Monitor and Control
Resourcing
• Monitor and Control Resourcing ensures project resources
are available as planned.
• It focuses on physical and virtual resources, not team
member performance.
• Resources may include equipment, materials, supplies,
facilities, software, licenses, infrastructure, testing
environments, and services.
• The process compares planned resource use against
actual resource use.
• Corrective action is taken when resources are unavailable,
overused, underused, or causing delays.

[Link] [Link]
 Monitor and Control
Resourcing

[Link] [Link]
 Monitor and Control Resourcing
- Inputs
• Project Management Plan
• Resource management plan - the reference for monitoring and
controlling resource use.
• Project Documents
• Issue log - resource-related issues raised and tracked.
• Lessons learned register - prior monitoring lessons applied.
• Physical or virtual resource assignments - shows what should be
in place.
• Project schedule - drives expected timing of resource use.
• Resource breakdown structure - the organized view of resources
to monitor.
• Risk register - resource-related risks (key person, vendor failure)
being monitored.
• Work Performance Data
• Raw data on resource use: hours worked, materials consumed,
equipment usage, idle time.
• Agreements
• Vendor contracts that specify resource availability and
performance requirements.
• Organizational Process Assets
• Resource policies and procedures, monitoring templates, control
thresholds, and historical resource utilization data.

[Link] [Link]
 Monitor and Control Resourcing
- Tools
• Data Analysis
• Alternative analysis - evaluates options for adjusting
resource allocation when shortages or surpluses occur.
• Cost-benefit analysis - determines best corrective action
based on cost vs benefit.
• Performance reviews - measures, compares, and analyzes
planned vs actual resource utilization.
• Trend analysis - examines resource utilization over time to
predict future needs.
• Problem-Solving
• Structured techniques (5 Whys, root cause analysis) to
address resource issues.

[Link] [Link]
 Monitor and Control Resourcing
- Tools
• Interpersonal and Team Skills
• Negotiation - used to renegotiate resource availability
with functional managers and vendors.
• Influencing - used when the PM lacks formal authority
over resources.
• PMIS & Optimization Techniques
• PMIS - resource management dashboards and utilization
reports.
• Value stream mapping - identifies waste in the resource-
to-deliverable workflow.
• Continuous improvement - ongoing optimization of
resource use (Lean, Kaizen).
• Theory of constraints - identifies and improves the
bottleneck resource.
• Branch and bound - mathematical optimization of
resource allocation.

[Link] [Link]
 Monitor and Control Resourcing - Tools
• Control Charts
• Used to determine if a process is stable and predictable
• Shows whether performance is normal or out of control
• Tracks results over time
• Examples: defects, cost variance, schedule variance, or scope
changes
• Control limits
• Based on statistical calculations
• Show the normal range of process performance
• Specification limits
• Based on customer or project requirements
• Show the maximum and minimum values allowed
• Corrective action
• If results go outside the control limits, investigate and correct the
process
• Rule of Seven
• If 7 data points in a row are on the same side of the mean,
investigate
• The points do not have to be outside the control limits
• This may show a pattern, trend, or process problem

[Link] [Link]
 Monitor and Control
Resourcing - Output
• Work Performance Information
• Resource utilization status: actual vs planned, variances, future
resource needs, and recommendations.
• Change Requests
• Submitted via Integrated Change Control to revise resource
assignments, baselines, or processes.
• Project Management Plan Updates
• Resource management plan - updated to reflect lessons from
monitoring.
• Schedule and cost baselines - may be updated through approved
change requests.
• Project Document Updates
• Assumption log - assumptions about resources updated.
• Issue log - resource-related issues recorded and tracked.
• Lessons learned register - what worked and what didn't in
resource monitoring.
• Physical resource assignments - updated as resources are
reallocated.
• Resource breakdown structure - updated as resource categories
or types change.
• Risk register - resource-related risks updated.
[Link] [Link]
 Monitor Risks
• Monitor Risks tracks identified risks
and watches for new risks
throughout the project.
• It ensures risk response plans are
being implemented as planned.
• It evaluates whether risk responses
are effective or need to be changed.
• This process is performed
throughout the project.

[Link] [Link]
 Monitor Risks

[Link] [Link]
 Monitor Risks - Inputs
• Project Management Plan
• Risk management plan - provides guidance on monitoring and
controlling risk: when to use reserves, how to verify assumptions,
how often to monitor.
• Project Documents
• Issue log - tracks issues that may have evolved from risks; helps
identify whether responses have been effective.
• Lessons learned register - applies prior monitoring lessons.
• Risk register - the master list being monitored.
• Risk report - current overall project risk exposure being tracked.
• Work Performance Data
• Raw observations on the status of risks: which have occurred,
which are no longer applicable, the status of agreed responses,
and any new risks identified.
• Work Performance Reports
• Performance information on cost, schedule, scope, and quality -
the basis for assessing whether the risk responses and overall risk
approach are working.

[Link] [Link]
 Monitor Risks - Tools
• Data Analysis
• Technical performance analysis - compares technical
accomplishments during execution to the schedule of technical
achievement.
• Reserve analysis - throughout execution, monitors the amount of
contingency reserve remaining versus the amount of risk
remaining.
• Audits
• Risk audits - examine and document the effectiveness of risk
responses in dealing with identified risks.
• Meetings
• Risk reviews - held periodically to examine the status of risk
responses, identify new risks, reassess current risks, close out
outdated risks, and discuss risk-related issues.

[Link] [Link]
 Monitor Risks - Output
• Work Performance Information
• Information on how risk management is performing: how the actual
risks differ from those that were predicted; and how effective the
responses have been.
• Change Requests
• Recommended corrective actions - bringing the project back into
compliance with the project management plan (e.g., implementing
contingency plans).
• Project Management Plan Updates
• Any component of the PM Plan may be updated as a result of
monitoring.
• Project Document Updates
• Assumption log - updated with new assumptions or invalidated ones.
• Issue log - new issues uncovered during monitoring.
• Lessons learned register - what worked or didn't in monitoring risks.
• Risk register - new risks added; existing risks reassessed; outdated
risks closed; outdated assumptions and impacts updated.
• Risk report - updated to reflect current overall project risk exposure.
• Organizational Process Asset Updates
• Templates for risk management plans, risk registers, risk reports, and
risk breakdown structures may be updated based on lessons learned.

[Link] [Link]
 Closing
• 1 Process
• Bring the phase or project to a
official end

[Link] [Link]
[Link] [Link]
 Close Project or Phase
• Close Project or Phase finalizes all
activities for a project, phase,
release, iteration, or contract.
• It applies to both successful and
unsuccessful work.
• The process confirms that planned
work has been completed or
properly ended.

[Link] [Link]
 Close Project or Phase

[Link] [Link]
 Close Project or Phase - Inputs
• Project Charter
• Documents the project's success criteria, exit criteria, approval
requirements, and the assigned project manager - all of which are
confirmed at closure.
• Project Management Plan
• All components of the PM Plan are inputs because closure must
verify that every aspect of the plan has been completed.
• Project Documents
• Assumption log - documented assumptions confirmed or
invalidated during the project.
• Basis of estimates - used in performance review and lessons
learned.
• Change log - records all changes made during the project.
• Issue log - records of all issues raised; all should be resolved or
transferred at closure.
• Lessons learned register - finalized at closure for transfer to
organizational repositories.
• Milestone list - basis for confirming all major milestones were
achieved.

[Link] [Link]
 Close Project or Phase - Inputs
• Project Documents (cont.)
• Project communications - record of communications during the
project; archived at closure.
• Quality control measurements - documented results of QC activities.
• Quality reports - status of quality activities.
• Requirements documentation - confirms all requirements were met or
formally addressed.
• Risk register and risk report - documents risks and their outcomes.
• Accepted Deliverables
• Deliverables formally signed off by the customer or sponsor through
Validate Scope.
• Business Documents
• Business case - reviewed at closure to confirm the business need was
met.
• Benefits management plan - basis for handing off benefit realization
tracking to operations.
• Agreements & Procurement Documentation
• Contracts must be formally closed; procurement records (statements
of work, change requests, deliverables, payments, inspection results)
are archived.
• OPAs
• Organizational closure procedures and templates, lessons learned
repositories, configuration management knowledge bases.

[Link] [Link]
 Close Project or Phase - Tools
• Expert Judgment
• Specialists in management control, audit, legal and
procurement, and regulations help ensure all closure
activities are performed correctly.
• Data Analysis
• Document analysis - assessing project documentation to
identify lessons learned and knowledge sharing for future
projects.
• Regression analysis - examining the relationships between
different project variables that contributed to project
outcomes.
• Trend analysis - validating project models and adjusting
for future projects.
• Variance analysis - improves the metrics of the
organization by comparing what was originally planned
and the end result.
• Meetings
• Closeout meetings, lessons learned meetings, and final
stakeholder meetings used to confirm closure activities,
document lessons, and celebrate success.

[Link] [Link]
 Close Project or Phase - Output
• Project Document Updates
• Lessons learned register - finalized to include final
information on closure activities, used as input for the
organizational lessons learned repository.
• Final Product, Service, or Result Transition
• Formal handoff of the final product, service, or result to
the operating group or customer who will support, use, or
sustain it.
• Includes operations and maintenance documentation,
training, and warranty terms.

[Link] [Link]
 Close Project or Phase - Output
• Final Report
• Provides a summary of project performance: scope,
quality, cost, schedule, summary of validation against
objectives, summary of risks, and summary of issues
encountered and how they were resolved.
• Confirms the project's business need has been met and
that benefits will be tracked beyond project closure.
• Organizational Process Asset Updates
• Project documents, operational documents, project or
phase closure documents, and historical information all
added to the organization's process asset repository.
• Lessons learned, templates, and process improvements
available for future projects.

[Link] [Link]
 Close Project or Phase - Project Closure Checklist

Deliverables & Acceptance Contracts & Procurement

✓ All deliverables formally accepted by sponsor/customer ✓ All vendor contracts formally closed

✓ Final product, service, or result transitioned to operations ✓ Final payments processed; warranties documented

✓ All requirements traced to deliverables and confirmed ✓ Procurement audit completed

Documentation People & Resources

✓ Final project report completed and shared ✓ Team members released to other assignments

✓ Lessons learned register finalized ✓ Performance assessments completed

✓ All project documents archived per policy ✓ Recognition and rewards delivered

✓ OPA repository updated with templates and artifacts ✓ Equipment / facilities released

Financial

✓ Final cost reconciliation completed

✓ Outstanding invoices paid; budget closed

✓ Any unused contingency reserves released

Standard closure activities organized by category. All items must be completed before the project can be formally closed.
[Link] [Link]