📋 PMP Master Study Guide

Built to take you to 100% — PMBOK 6 & 7 + Agile Practice Guide

Everything you need for the PMP exam in one place: 70+ deep-dive sections, the 12 Principles and 8 Performance Domains, all 49 processes, EVM & formulas, agile/hybrid, ethics, scenarios, cheat sheets, and a 200+ term glossary. Hover any underlined word for an instant English/Arabic hint, click highlighted keywords for definitions, and click the principle & domain cards for full pop-out detail.

70+Study Sections

12Principles

8Performance Domains

49Processes

200+Glossary Terms

How to use this guide

🟡 Click keywords

Yellow-highlighted terms open a definition pop-out with an exam tip.

🃏 Click the cards

Principle & domain cards open full pop-outs: what, why, how, examples, traps.

ع / EN Hints

Use the toggle (top-right) to switch hover hints between Arabic, English, or Off.

✅ Quizzes unlock ✓

Score ≥ 80% on a section quiz to mark it mastered and grow your progress bar.

12 Principles 8 Domains Process Groups EVM & Cost Control Formula Sheet Mega Cheat Sheet Agile Code of Ethics

🚀 Start Studying — Section 1 →

1. Project Management Fundamentals

🔷 What is a Project?

A project is a temporary endeavor that produces a unique product, service, or result.

Temporary — definite beginning AND end
Unique — different from routine operations
Progressively Elaborated — developed step by step

⚙️ Operations vs. Projects

Operations: Ongoing, repetitive, no end date
Projects: Temporary, unique, defined end

Example: Running a factory = Operations. Building the factory = Project.

Portfolio → Program → Project Hierarchy

Level	Definition	Focus
Portfolio	Collection of projects, programs, sub-portfolios to meet strategic objectives	Strategic (long-term goals)
Program	Group of related projects managed together for benefits not achievable individually	Benefits realization
Project	Temporary endeavor producing unique output	Deliverables & scope

A project CAN exist without a program, but a program ALWAYS has projects. Portfolio always contains programs and/or projects.

Project Constraints (Triple Constraint + 3 More)

📐 Scope 📅 Schedule 💰 Cost ⚠️ Risk ✅ Quality 👥 Resources

Changing one constraint impacts ALL others. If scope increases → cost and schedule increase too.

Project Lifecycle Approaches

Approach	Also Called	Key Traits	Best For
Predictive	Waterfall / Traditional	Sequential, detailed upfront planning, limited changes	Well-defined requirements, stable scope
Adaptive	Agile	Iterative, incremental, customer collaboration, welcomes change	High uncertainty, changing requirements
Hybrid	—	Combination of predictive + adaptive	Mixed certainty environments

Key Stakeholders You Must Know

Project Manager — manages the project day-to-day
Sponsor — provides funding & resources; formal authority above PM
Customer/User — receives and uses the deliverable
Project Team — does the actual work
Functional Manager — controls resources in a functional org
PMO — standardizes PM processes across the organization

PMO Types

Type	Authority Level	What It Does
Supportive	Low	Templates, training, lessons learned — advisory only
Controlling	Moderate	Sets framework/methodology, requires compliance
Directive	High	Controls projects; PM reports to PMO

PMO type = authority level. Supportive = least control. Directive = most control. PM always reports to Directive PMO.

Organizational Structures

Structure	PM Authority	Resource Availability	Budget Control	PM Role
Functional	Little/None	Little/None	Functional Manager	Part-time
Weak Matrix	Low	Low	Functional Manager	Part-time
Balanced Matrix	Low–Moderate	Low–Moderate	Mixed	Part/Full-time
Strong Matrix	Moderate–High	Moderate–High	PM	Full-time
Projectized	High/Total	High/Total	PM	Full-time

In a Functional org, the PM has the LEAST power. In Projectized, the PM has the MOST power. The BIGGEST conflict is between PM and Functional Manager in a Matrix org.

Risks vs. Issues

⚠️ Risk

A potential future event that has NOT happened yet. May be positive (opportunity) or negative (threat).

🚨 Issue

A problem that has already occurred. Needs immediate resolution, tracked in the Issue Log.

My Study Notes

2. 12 Principles of Project Management (PMBOK 7)

Principles serve as foundational guidelines for strategy, decision-making, and problem-solving. These replaced the knowledge areas as the organizing framework in PMBOK 7.

12 Principles Acronym: S-T-S-V-S-L-T-Q-C-R-A-C
Some Teams Serve Value, Systems Lead To Quality. Complex Risks Are Changeable.

👉 Click any principle card below to open a full pop-up window with its complete details — what it means, why it matters, how to apply it, real examples, scenarios, exam tips, and common traps.

🤝 Stewardship

Be a diligent, respectful, caring steward. Act with integrity, care, trustworthiness, compliance. Consider financial, social, environmental impacts.

👥 Team

Create a collaborative project team environment. Teams with diverse skills accomplish shared objectives more effectively than individuals working alone.

🎯 Stakeholders

Effectively engage with stakeholders. Proactive engagement advances value delivery. Stakeholders influence outcomes and performance.

💡 Value

Focus on value. Value is the ultimate indicator of project success. Value can be quantitative OR qualitative. Realized throughout, at end, or after project.

🔄 Systems Thinking

Recognize, evaluate, and respond to system interactions. A project is a system of interdependent domains. Systems are always changing — stay holistic.

🌟 Leadership

Demonstrate leadership behaviors. Effective leadership promotes success. ANY team member can lead. Adapt style to situation. Model honesty, integrity, ethics.

✂️ Tailor

Tailor based on context. Each project is unique. Tailor the approach iteratively throughout the project to fit the unique needs.

✅ Quality

Build quality into processes and deliverables. Quality = satisfying stakeholder expectations AND fulfilling project/product requirements.

🌀 Complexity

Navigate complexity. Complexity results from human behavior, system interactions, uncertainty, and ambiguity. Complexity can emerge at any point.

⚖️ Risk

Optimize risk responses. Risks can be positive (opportunities) or negative (threats). Address risks continually. Responses must be cost-effective & realistic.

🌱 Adaptability & Resiliency

Adaptability: respond to changing conditions. Resiliency: absorb impacts and recover quickly. Build both into the team's approach.

🔮 Change

Enable change to achieve the envisioned future state. Prepare stakeholders for adoption of new behaviors. Too much change too fast = change fatigue.

PMBOK 7 shifted from Process Groups → Principles + Performance Domains. The PMP exam tests BOTH PMBOK 6 process knowledge AND PMBOK 7 principles. Know both!

3. 8 Performance Domains (PMBOK 7)

Performance Domains are groups of related activities critical for effective delivery of project outcomes. They operate as an integrated system.

👉 Click any domain row below to open a full pop-up window with its complete details — what it is, why it matters, key activities, outcomes, examples, scenarios, exam tips, and common traps.

#	Domain	Focus	Key Activities
1	Stakeholder	Engagement with stakeholders	Identify, analyze, engage, monitor stakeholders throughout
2	Team	People responsible for deliverables	Team development, leadership behaviors, high performance culture
3	Development Approach & Life Cycle	How and when to deliver	Predictive vs adaptive vs hybrid selection; delivery cadence
4	Planning	Organizing & coordinating work	Upfront and ongoing planning; evolving throughout project
5	Project Work	Establish processes & manage resources	Communication, engagement, procurement, physical resources
6	Delivery	Delivering scope & quality	Meet requirements, scope, quality; deliver expected outputs
7	Measurement	Assess performance & respond	Metrics, forecasting, corrective actions for optimal performance
8	Uncertainty	Risk & uncertainty	Identify threats/opportunities; ambiguity; complexity management

Performance Domains are interdependent — they do NOT operate in isolation. Think of them as 8 wheels on the same vehicle.

4. Process Groups & Knowledge Areas (PMBOK 6)

PMBOK 6 organizes 49 processes across 5 Process Groups and 10 Knowledge Areas.

👉 Click any Process Group (the tags or the overview-table rows) or any Knowledge Area (the left-column names in the 49-process map) to open a full pop-up window with complete details, processes, examples, scenarios, and exam tips.

5 Process Groups

🚀 Initiating (2) 📋 Planning (24) ⚙️ Executing (10) 📊 Monitoring & Controlling (12) 🏁 Closing (1)

Process Groups Overview

Process Group	Purpose	# Processes
Initiating	Authorize the project/phase; assign PM	2
Planning	Establish scope, objectives, course of action	24
Executing	Complete work defined in the PM Plan	10
Monitoring & Controlling	Track, review, regulate progress; initiate changes	12
Closing	Formally complete or close the project/phase	1

49 Processes — Full Map

KA	Initiating	Planning	Executing	M&C	Closing
Integration	Develop Charter	Develop PM Plan	Direct & Manage Work; Manage Knowledge	Monitor & Control Work; Integrated Change Control	Close Project
Scope	—	Plan Scope; Collect Requirements; Define Scope; Create WBS	—	Validate Scope; Control Scope	—
Schedule	—	Plan Schedule; Define Activities; Sequence Activities; Estimate Durations; Develop Schedule	—	Control Schedule	—
Cost	—	Plan Cost; Estimate Costs; Determine Budget	—	Control Costs	—
Quality	—	Plan Quality	Manage Quality	Control Quality	—
Resource	—	Plan Resource; Estimate Activity Resources	Acquire Resources; Develop Team; Manage Team	Control Resources	—
Communications	—	Plan Communications	Manage Communications	Monitor Communications	—
Risk	—	Plan Risk; Identify Risks; Qual. Analysis; Quant. Analysis; Plan Responses	Implement Responses	Monitor Risks	—
Procurement	—	Plan Procurement	Conduct Procurements	Control Procurements	—
Stakeholder	Identify Stakeholders	Plan Stakeholder Engagement	Manage Stakeholder Engagement	Monitor Stakeholder Engagement	—

Planning has the most processes (24). Closing has only 1. The only KA that appears in ALL 5 process groups is Integration Management.

5. Common ITTOs — Inputs, Tools, Techniques, Outputs

👉 Click any item — the common inputs (EEF, OPA, PM Plan, Project Documents), the EEF/OPA cards, the Work Performance rows, every tool in "Common Tools You MUST Know" (with all sub-techniques), and the change-request types — to open a full pop-up window with details, sub-items, examples, scenarios, and exam tips.

Common Inputs (appear in many processes):
• EEF — Enterprise Environmental Factors
• OPA — Organizational Process Assets
• Project Management Plan
• Project Documents

EEF vs. OPA

🌐 Enterprise Environmental Factors (EEF)

Things that IMPACT the project but are NOT part of the project. Cannot be controlled by the team.

Internal: Culture, org structure, existing resources, IT software, employee capability

External: Government standards, commercial databases, legal restrictions, market conditions

🏢 Organizational Process Assets (OPA)

Assets FROM the organization used BY the project. Templates, policies, procedures, historical info.

Examples: Risk procedures, change control procedures, project templates, lessons learned from past projects, software tools

EEF = external or internal factors you CANNOT control. OPA = organizational assets you CAN use and update. Team UPDATES OPA throughout the project.

Work Performance: Data → Information → Report

Term	What It Is	Produced By	Used By
Work Performance Data	Raw, unanalyzed data. Status of work done.	Executing processes	M&C processes
Work Performance Information	Analyzed data compared to plan. Actual vs. baseline.	M&C processes	Monitor & Control Work
Work Performance Reports	Comprehensive status report. All info combined.	Monitor & Control Work	Stakeholders

Flow: Data → (analysis) → Information → (compilation) → Reports

Common Tools You MUST Know

Tool	Description
Expert Judgment	Most common tool in planning. Hire SME or use team expertise.
Data Gathering	Brainstorming, Interviews, Focus Groups, Checklists, Questionnaires/Surveys
Data Analysis	Alternative Analysis, Root Cause Analysis (RCA), Variance Analysis, Trend Analysis
Data Representation	Charts, matrices, diagrams (Flowcharts, Fishbone, Histograms, Scatter)
Decision Making	Voting (majority, unanimity, plurality), Multicriteria analysis, Autocratic
Interpersonal & Team Skills	Active listening, conflict management, facilitation, meeting management

Change Requests — Types

🔧 Corrective Action — gets project back on track (past) 🛡️ Preventive Action — keeps project on track (future) 🔄 Defect Repair — fixes broken component

ONLY the Change Control Board (CCB) approves or rejects change requests. After approval, PM updates the PM Plan. Changes must be submitted in WRITING.

6. Develop Project Charter (Initiating)

INITIATING

The process of developing a document to formally authorize a project or phase. It assigns the PM and grants authority to apply resources.

Your company just received approval to build a new bridge. Before any work begins, the sponsor signs the Project Charter, officially naming you as PM and authorizing the $5M budget and 18-month timeline.

DEVELOP PROJECT CHARTER — ITTOs
📥 Inputs	🔧 Tools & Techniques	📤 Outputs
Business Documents (Business Case, Benefits Mgmt Plan) Agreements EEF OPA	Expert Judgment Data Gathering (Brainstorming, Focus Groups, Interviews) Interpersonal & Team Skills Meetings	Project Charter ✓ Assumption Log

Project Charter Contents

Project purpose/justification
Measurable project objectives & success criteria
High-level requirements & risks
Preliminary project budget & schedule
Assigned PM and their authority level
Sponsor name and signature
Key stakeholders

The Project Charter is the ONLY document signed by SENIOR MANAGEMENT (Sponsor). It formally authorizes the project and gives PM authority. No charter = no project!

The Assumption Log (first created here) lists ASSUMPTIONS (things believed to be true) and CONSTRAINTS (restrictions that limit options).

7. Identify Stakeholders (Initiating)

INITIATING

Identifying, analyzing, and documenting information about individuals, groups, or organizations that may affect or be affected by the project. Done REGULARLY throughout the project.

📥 Inputs	🔧 Tools & Techniques	📤 Outputs
Project Charter; Business Documents; PM Plan; Project Documents; Agreements; EEF; OPA	Expert Judgment; Data Gathering; Data Analysis; Data Representation; Meetings	Stakeholder Register ✓; Change Requests; PM Plan Updates; Project Docs Updates

Stakeholder Analysis Tools

Power/Interest Grid

Plots stakeholders by Power (authority) vs. Interest in the project.

	Low Interest	High Interest
High Power	Keep Satisfied	Manage Closely
Low Power	Monitor	Keep Informed

Salience Model

3 dimensions: Power (authority), Legitimacy (right to be involved), Urgency (immediate attention). Produces 7 stakeholder classes — see deep-dive below ↓

🎯 Salience Model — Complete Deep Dive (All 7 Classes)

The Salience Model (Mitchell, Agle & Wood, 1997) classifies stakeholders using three attributes: Power, Legitimacy, and Urgency. The combination of attributes a stakeholder holds determines their salience class — and therefore how much PM attention they require.

🔵 Power = Can they ACT? 🟢 Legitimacy = Right to be INVOLVED? 🟡 Urgency = Need attention NOW?

👆 Click any region in the diagram to see details about that stakeholder class.

All 7 Classes — Quick Reference

Class	Power	Legitimacy	Urgency	PM Strategy	Priority
Definitive ⭐	✅	✅	✅	Engage IMMEDIATELY	🔴 Highest
Dominant	✅	✅	❌	Engage regularly	🟠 High
Dangerous	✅	❌	✅	Address carefully	🟠 High (caution)
Dependent	❌	✅	✅	Advocate for them	🟡 Medium
Dormant	✅	❌	❌	Monitor periodically	🟡 Medium
Discretionary	❌	✅	❌	Engage at discretion	🟢 Low
Demanding	❌	❌	✅	Acknowledge, minimal resources	🔵 Lowest

Detailed Class Profiles (click to expand)

Who: The MOST SALIENT stakeholders — they have ALL three attributes. Must receive immediate, high-priority PM attention without exception.

PM Strategy: Drop lower-priority work and engage immediately. Continuous, high-touch management.

Project sponsor (Power + Legitimacy) discovers a regulatory penalty will trigger in 5 days (Urgency) → DEFINITIVE. Engage within hours.

EPA issues emergency stop-work for contaminated soil find (Power + Legitimacy + Urgency) → DEFINITIVE. Act within hours.

If a question says a powerful, legitimate stakeholder suddenly has a pressing urgent issue → they are DEFINITIVE → PM must engage IMMEDIATELY. This is always the correct PMP answer.

Who: Key stakeholders with authority AND a formal role, but no current pressing demands. Sponsors, regulatory bodies, major clients with contractual rights.

PM Strategy: Engage regularly and proactively. Build strong relationships. Keep satisfied. They become Definitive the moment urgency appears.

Project sponsor with budget authority and charter role, project currently on track, no pressing issues → DOMINANT. PM meets bi-weekly.

State DOT with highway approval authority — no current time-sensitive submittals pending → DOMINANT. Engage through regular formal submittals.

Dominant = Power/Interest Grid "Manage Closely" or "Keep Satisfied." Add urgency → they instantly become DEFINITIVE.

Who: Stakeholders who can act powerfully and urgently WITHOUT a legitimate role. Coercive by nature. Can cause real harm without official sanction.

PM Strategy: Take seriously. Address urgent concerns to neutralize threats. Do NOT grant them formal authority. Involve legal/management if needed.

Workers from an adjacent project block your trucks over their own labor dispute — Power (can stop work) + Urgency (happening now), no legitimate role → DANGEROUS. Alert management; do not give them a seat at your project table.

Politically connected activist pressures city council to halt permits — Power (political) + Urgency + no formal project role → DANGEROUS. Engage through official public channels only.

"Dangerous" = COERCIVE power. They can harm without the right to do so. Never ignore; never give illegitimate authority.

Who: Stakeholders with a real stake and real urgency but NO power to enforce their claims. They DEPEND on the PM or powerful allies to advocate for them.

PM Strategy: Be their advocate. They have legitimate urgent claims — support them ethically. Keep them informed and involved.

Residents near a construction site — legally affected (Legitimacy), urgently impacted by dust and noise (Urgency), but cannot stop the project (no Power) → DEPENDENT. PM implements dust controls and holds community briefings.

End users needing a critical bug fix urgently (L + U) but no authority over the project → DEPENDENT. PM advocates for their issue in sprint review.

Dependent stakeholders depend on YOUR advocacy as PM. Even though they lack power, their urgency and legitimacy make them morally significant. Ethical PMs do not ignore them.

Who: Stakeholders with authority but no current role and no urgent claims. Their power is "sleeping" — they don't use it right now.

PM Strategy: Monitor occasionally. Don't ignore — they could wake up! Keep communication channels open.

A senior VP owns 30% of project budget authority but has no direct project role and hasn't raised issues → DORMANT. PM sends monthly summary reports as a courtesy.

A neighboring municipality has legal authority over shared utility easements but no active stake in your road project → DORMANT. Monitor; if your project touches those easements, they could become Definitive overnight.

Dormant stakeholders can ACTIVATE and become Dangerous or Definitive if circumstances change. A dormant regulator becomes Definitive the moment your project triggers a required review.

Who: Stakeholders with a legitimate interest but no power to enforce and no urgent demands. Engagement is at the PM's discretion.

PM Strategy: Engage voluntarily. Building goodwill is smart; ignoring them is usually safe short-term but can damage reputation.

A local environmental non-profit has a moral stake in a bridge rehabilitation project (Legitimacy) but no regulatory authority and no urgent protests → DISCRETIONARY. PM holds a community open house to maintain goodwill.

A junior quality reviewer has team legitimacy but no authority to change scope and no pressing issue → DISCRETIONARY. Involve as appropriate.

"Discretionary" does NOT mean "unimportant." It means the level of engagement is YOUR CHOICE as PM. Only Legitimacy = Discretionary.

Who: Stakeholders who make urgent demands but have NEITHER power NOR legitimacy. They are vocal but cannot actually impact the project.

PM Strategy: Low priority. Acknowledge politely. Don't let their urgency distort project priorities or drive change control decisions.

A passerby calls daily demanding construction stop because they dislike the building aesthetics — no role, no authority, just persistent urgency → DEMANDING. PM sends a form letter and moves on.

A blogger urgently demands a software product's color scheme change — no contractual role, no authority → DEMANDING. Note the feedback; it does NOT enter change control.

Demanding = LOWEST salience. Don't let the squeaky wheel drive project decisions. If a question describes a "very vocal stakeholder with no formal role" → Demanding → minimal resources allocated.

Salience Model vs. Power/Interest Grid

Feature	Salience Model	Power/Interest Grid
Dimensions	3 (Power, Legitimacy, Urgency)	2 (Power, Interest)
Categories	7 distinct classes	4 quadrants
Dynamic?	✅ Yes — attributes change over time	Usually static per phase
More comprehensive?	✅ Yes	No
PMBOK classification	Both are Data Representation techniques in Identify Stakeholders

🗺️ SALIENCE MASTER CHEAT SHEET:
P only → Dormant | L only → Discretionary | U only → Demanding
P+L → Dominant | P+U → Dangerous | L+U → Dependent | P+L+U → DEFINITIVE ⭐
Memory: "Do Dominant Disc · Def Dang Dep Dem" — 7 D's!
Key fact: Salience = 3D (vs Power/Interest = 2D). Attributes are DYNAMIC — re-assess throughout project.

Directions of Influence

⬆️ Upward — Senior Management ⬇️ Downward — Team Members ↔️ Outward — Vendors, Government, Public ↗️ Sideward — Peer Project Managers

Stakeholder Register Contents

Contact info • Role on project • Communication requirements • Expectations • How affected by project • Power/influence level

Stakeholder identification is done at the START and THROUGHOUT the project — not just once! New stakeholders can be identified any time. The Stakeholder Register is NOT public; it's confidential.

7B. Develop Project Management Plan (Planning)

PLANNING

The process of defining, preparing, and coordinating all plan components and consolidating them into an integrated project management plan. This is the FIRST process in the Planning Process Group (PMBOK 6 process 4.2) and the master roadmap for HOW the entire project will be executed, monitored, and closed.

You just got your Project Charter signed. Now you sit down with your team and key stakeholders to answer one critical question: "How are we going to run this project?" — Develop Project Management Plan is that answer. Every subsidiary plan (scope, schedule, cost, quality, resource, communications, risk, procurement, stakeholder) rolls up into ONE integrated document: the Project Management Plan (PMP Plan).

DEVELOP PROJECT MANAGEMENT PLAN — ITTOs (PMBOK 6 § 4.2)
📥 Inputs	🔧 Tools & Techniques	📤 Outputs
Project Charter ✓ Outputs from Other Processes (subsidiary plans from all KAs) Enterprise Environmental Factors (EEF) Organizational Process Assets (OPA)	Expert Judgment Data Gathering (Brainstorming, Checklists, Focus Groups, Interviews) Interpersonal & Team Skills (Conflict Management, Facilitation, Meeting Management) Meetings	Project Management Plan ✓ (Subsidiary plans + Baselines + Additional components)

What Is the Project Management Plan?

The Project Management Plan (PM Plan) is NOT a project schedule — it's the comprehensive document that describes how the project will be planned, executed, monitored, controlled, and closed. It integrates all subsidiary plans into one coherent document.

Key fact: The PM Plan is progressively elaborated — it starts high-level and gains detail as planning progresses. It is formally approved (baselined) before execution begins, and any changes go through Integrated Change Control.

The 18 Components of the Project Management Plan

The PM Plan has 10 Subsidiary Plans + 3 Baselines + 5 Additional Components:

📋 10 Subsidiary Plans (one per Knowledge Area)

Scope Management Plan — how scope will be defined, validated, controlled
Requirements Management Plan — how requirements will be collected and tracked
Schedule Management Plan — how schedule will be developed and controlled
Cost Management Plan — how costs will be estimated, budgeted, controlled
Quality Management Plan — quality standards, QA/QC approach
Resource Management Plan — team acquisition, development, management
Communications Management Plan — who needs what info, when, how
Risk Management Plan — risk approach, thresholds, categories
Procurement Management Plan — make-or-buy decisions, contract types
Stakeholder Engagement Plan — strategies for stakeholder engagement

📐 3 Baselines (Frozen for Change Control)

Scope Baseline = Project Scope Statement + WBS + WBS Dictionary
Schedule Baseline = Approved project schedule
Cost Baseline = Approved budget (S-curve / time-phased)

Together = Performance Measurement Baseline (PMB)

🔧 5 Additional Components

Change Management Plan — how changes will be processed
Configuration Management Plan — version control for deliverables
Performance Measurement Baseline (PMB) — integrated scope/schedule/cost baseline
Project Life Cycle Description — phases used
Development Approach — predictive, agile, or hybrid

How It Connects to Every Other Process

Develop Project Management Plan is unique — it receives outputs from virtually every other Planning process. As each subsidiary plan is created (e.g., Schedule Management Plan from Plan Schedule Management, Cost Management Plan from Plan Cost Management), it feeds BACK into the PM Plan and updates it. The PM Plan is therefore the last Planning document to be fully completed.

Subsidiary Plan	Created By Process	Goes Into
Scope Management Plan	Plan Scope Management	PM Plan
Schedule Management Plan	Plan Schedule Management	PM Plan
Cost Management Plan	Plan Cost Management	PM Plan
Quality Management Plan	Plan Quality Management	PM Plan
Resource Management Plan	Plan Resource Management	PM Plan
Communications Management Plan	Plan Communications Management	PM Plan
Risk Management Plan	Plan Risk Management	PM Plan
Procurement Management Plan	Plan Procurement Management	PM Plan
Stakeholder Engagement Plan	Plan Stakeholder Engagement	PM Plan

Key Characteristics of the PM Plan

✅ What It IS

A formal, approved document
The single source of truth for HOW the project runs
Progressively elaborated throughout planning
A living document — but changes need formal approval
An input to virtually EVERY executing and monitoring process
Baselined before execution begins

❌ What It Is NOT

NOT the project schedule (that's a schedule model)
NOT static — it changes through change control
NOT created by the PM alone — team input required
NOT completed before all planning — it's built iteratively
NOT a guarantee — it's the plan, not the outcome
NOT approved by the PM — approved by sponsor/CCB

Real-World Scenarios

Highway Bridge Rehab: After the charter is signed, Ahmad (PM) calls a planning kickoff meeting with IDOT, the design firm, construction firm, and utility companies. Together they define the development approach (predictive/waterfall), agree on phase gates, and begin drafting subsidiary plans. As each plan is finalized — schedule, cost, risk, procurement — it's added to the master PM Plan. The PM Plan is then formally approved by the sponsor before any construction work begins.

Software Project (Agile): A PM uses a hybrid approach. The PM Plan documents the development approach as "Agile/Scrum" with 2-week sprints. The scope baseline captures the initial product backlog strategy. The schedule management plan explains how the release roadmap functions as the schedule. Even in agile, a PM Plan exists — it just describes the adaptive approach.

Change During Execution: Six months into a building project, the client requests a 10,000 sq ft addition. Since the scope baseline is part of the PM Plan, this change requires a formal change request, CCB review, and an approved update to the PM Plan (scope, cost, and schedule baselines all change). The PM cannot just accept the change — it must go through Integrated Change Control.

Exam Tips & Cheat Sheet

The PM Plan is an INPUT to virtually every Executing and Monitoring & Controlling process. If a question asks "what do you consult when managing execution?" → Project Management Plan.

Baselines (scope, schedule, cost) can ONLY be changed through FORMAL change control — not by the PM's authority alone. Any unauthorized change to baselines is a violation.

The PM Plan is approved by the Project Sponsor (not the PM). The PM creates it; the sponsor approves it. In some organizations, the CCB approves changes to baselines.

PMBOK exam favorite: "Who can approve changes to the PM Plan?" → Changes to baselines require CCB approval. Minor updates (non-baseline) may require PM + Sponsor only.

Develop Project Management Plan = first Planning process (4.2). It uses the Project Charter as the primary input. Output = the PM Plan (most comprehensive project document).

🗺️ Cheat Sheet — Develop Project Management Plan

Item	Answer
Process Group	Planning
Knowledge Area	Integration Management
PMBOK 6 Process #	4.2
Primary Input	Project Charter
Primary Output	Project Management Plan
Key Tool	Expert Judgment + Meetings
Subsidiary Plans Count	10 (one per KA)
Baselines Count	3 (Scope + Schedule + Cost)
Who Approves PM Plan	Project Sponsor (changes via CCB)
How to Change Baselines	Formal Integrated Change Control ONLY
Is PM Plan a Living Document?	Yes — updated through change control
Performance Measurement Baseline	Scope + Schedule + Cost baselines combined

Top Exam Keywords — Click to Learn

Project Management Plan Scope Baseline Performance Measurement Baseline Change Control Configuration Management Plan Progressive Elaboration

8. Scope Management (Planning)

PLANNING

Scope Management Processes (4 in Planning)

Plan Scope → Collect Requirements → Define Scope → Create WBS

Creates the Scope Management Plan (how scope will be defined, developed, monitored, controlled, verified) and the Requirements Management Plan.

Output: Scope Management Plan + Requirements Management Plan. Only tool is Expert Judgment, Data Analysis, and Meetings.

Determining, documenting, and managing stakeholder needs to meet objectives.

Key Tools: Prototypes (working model for feedback), Context Diagrams, Interviews, Focus Groups, Questionnaires, Brainstorming

Outputs: Requirements Documentation + Requirements Traceability Matrix (RTM)

You're building a mobile app. You interview 20 users (interviews), run 3 focus groups, and create wireframe prototypes to show stakeholders — this is collecting requirements.

The RTM links each requirement back to its source stakeholder and tracks status. It's used to manage scope changes.

Developing a detailed description of the project and product. The detailed scope statement is critical — more detail = less risk of scope creep.

Key Tool: Product Analysis (decomposing the product)

Output: Project Scope Statement

Less detail in scope statement = MORE risk and chance of scope creep!

Subdividing deliverables into smaller, manageable components. The WBS is deliverable-oriented, NOT activity-oriented.

Key Tool: Decomposition

Output: Scope Baseline = Project Scope Statement + WBS + WBS Dictionary

WBS Example

1.0 Phone System Upgrade
  1.1 Collect Requirements
    1.1.1 List Stakeholders
    1.1.2 Interview Stakeholders
  1.2 Select Phone System
  1.3 Install System
  1.4 Test System
  1.5 Train Users

WBS Dictionary: Details each WBS node — who, what, how long, how much, quality requirements.

Work Package: Lowest level of WBS. Can be estimated and assigned. Control Accounts are higher.

100% Rule: The WBS must include 100% of the work — no more, no less. The WBS is NOT a task list — it's a DELIVERABLE breakdown.

Scope Baseline = 3 Components

📄 Project Scope Statement 🌲 WBS 📚 WBS Dictionary

Scope Creep

Scope Creep: Uncontrolled expansion of project scope without adjustments to time, cost, and resources. Controlled through Control Scope.

During construction, the client keeps asking for "small additions" — an extra bathroom here, a bigger garage there — without formal change requests. This is scope creep.

ANY change to scope MUST go through Integrated Change Control. Even small changes = formal change request.

9. Schedule Management (Planning)

PLANNING

5 Planning Processes: Plan Schedule → Define Activities → Sequence Activities → Estimate Durations → Develop Schedule

Estimating Techniques

Technique	Accuracy	Time/Cost	Description
Analogous (Top-Down)	Lowest	Cheapest/Fastest	Uses historical data from similar projects. Best when info is limited.
Parametric	Moderate	Moderate	Statistical relationship between variables. E.g., $50/sq ft × 2,000 sq ft = $100K
Three-Point (PERT)	High	Moderate	Uses Optimistic, Most Likely, Pessimistic values
Bottom-Up	Highest	Slowest/Costliest	Estimate each activity, aggregate up. Most accurate.

PERT Formulas

Beta Distribution (PERT): (O + 4M + P) / 6
Triangle Distribution: (O + M + P) / 3
Standard Deviation: (P − O) / 6

Example: O=8, M=10, P=14 → PERT = (8 + 40 + 14)/6 = 62/6 = 10.33 days
SD = (14−8)/6 = 1.0 day

Sequencing: Dependency Types (PDM)

Dependency Types

Type	Meaning
Finish-to-Start (FS)	B can't start until A finishes (most common)
Finish-to-Finish (FF)	B can't finish until A finishes
Start-to-Start (SS)	B can't start until A starts
Start-to-Finish (SF)	B can't finish until A starts (rare)

Leads & Lags

Lead — Acceleration of successor. A NEGATIVE lag. E.g., start painting 3 days before wall is 100% done.
Lag — Delay in successor. Waiting period. E.g., wait 7 days for concrete to cure before framing.

Critical Path Method (CPM)

The Critical Path is the LONGEST path through the network. It determines the shortest possible project duration.

Float/Slack = LF − EF or LS − ES. Activities on critical path have 0 float.

Forward Pass: ES = max(EF of predecessors); EF = ES + Duration
Backward Pass: LF = min(LS of successors); LS = LF − Duration
Float: LF − EF = LS − ES

Critical Path activity with 0 float = any delay delays the whole project. You CRASH or FAST-TRACK activities on the critical path to compress schedule.

Schedule Compression

👉 Click either card below (Crashing or Fast Tracking) to open a full pop-up window with details, pros & cons, examples, scenarios, and exam tips. A side-by-side comparison table follows.

💥 Crashing

Add resources to shorten duration. ALWAYS adds cost. May add risk. Done on critical path activities with cheapest cost/time ratio.

⚡ Fast Tracking

Perform activities in parallel that were sequential. May NOT add cost. Increases risk due to rework. Done on critical path only.

⚖️ Crashing vs. Fast Tracking — Side-by-Side

Aspect	💥 Crashing	⚡ Fast Tracking
Definition	Add resources to critical-path activities to shorten duration.	Perform sequential activities in parallel (overlap them).
How it works	More people, overtime, extra equipment, or paying for faster delivery.	Start a successor before its predecessor fully finishes.
Effect on Cost	ALWAYS adds cost (more resources / overtime).	May NOT add cost (uses existing resources).
Effect on Risk	Lower added risk; but watch quality and resource conflicts. Can hit diminishing returns.	Higher risk — rework if the predecessor changes; more coordination.
Applies to	Critical path activities only (lowest cost-slope first).	Critical path activities only (those that can overlap).
Best when…	Budget IS available and you must hit the date.	Budget is FIXED / cannot add cost, and activities can safely overlap.
Pros	Predictable time savings; keeps original sequence/logic; lower rework risk.	Often free (no extra cost); can shorten schedule quickly.
Cons	Increases cost; diminishing returns; possible resource conflicts & team burnout.	Increases rework risk & complexity; needs heavy coordination.
Example	Add a 2nd crew to pour concrete in 3 days instead of 5 — paying overtime.	Begin electrical rough-in before all framing is done, overlapping the two.
Scenario	Sponsor says "hit the date, budget approved" → Crash.	Sponsor says "hit the date, no extra money" → Fast Track.

If asked to compress schedule and keep costs same → Fast Track. If budget is available → Crash. Both only work on critical path activities. Tip: try Fast Tracking first (it may be free), then Crash if more compression is needed.

Schedule Baseline

The approved version of the schedule model. Only changed through formal change control. Used to measure performance.

Estimate Types & Ranges

Estimate Type	Range	When Used
Rough Order of Magnitude (ROM)	−25% to +75%	Early project initiation
Budget Estimate	−10% to +25%	Planning phase
Definitive Estimate	−5% to +10%	Detailed planning, late project

The later in the project, the more accurate (and narrow range) the estimate. ROM is worst, Definitive is best.

10. Cost Management (Planning)

PLANNING

Cost Planning Processes

Plan Cost → Estimate Costs → Determine Budget

Budget Components

Project Budget = Cost Baseline + Management Reserves
Cost Baseline = Activity Costs + Contingency Reserves

Contingency Reserve: For KNOWN risks (identified in risk register)
Management Reserve: For UNKNOWN risks (unknown-unknowns)
Only PM needs approval to use Contingency Reserve
Management Reserve requires higher authority approval

Cost Baseline displayed as an S-Curve. Cost Baseline includes contingency reserves. Management Reserves are NOT in the baseline.

Cost Estimate Types — Same as Schedule Estimates

Type	Range
ROM (Rough Order of Magnitude)	−25% to +75%
Budget Estimate	−10% to +25%
Definitive Estimate	−5% to +10%

11. Quality Management (Planning)

PLANNING

Quality vs. Grade

Quality

Degree to which characteristics fulfill requirements. Low quality is ALWAYS a problem.

Grade

Category for products with the same use but different technical characteristics. Low grade may be acceptable.

Cost of Quality (COQ)

Conformance Costs (Prevention + Appraisal): Money spent PREVENTING defects

Prevention: Training, process improvement, design reviews
Appraisal: Testing, inspection, audits

Non-Conformance Costs (Internal + External Failure): Money spent FIXING defects

Internal Failure: Rework, scrap (found before delivery)
External Failure: Warranty, liability, lost customers (found after delivery)

The BEST approach = invest in Prevention. Prevention costs LESS than failure costs. "Quality is free" — Phil Crosby means investing in quality prevention saves money long-term.

Quality Tools — Data Representation

👉 Click any tool below to open a full pop-up window with a labeled diagram/sketch, what it is, how to read it, when to use it, an example, an exam scenario, and exam tips.

Tool	Use
Fishbone (Ishikawa/Cause & Effect)	Identify root causes of defects
Pareto Chart (80/20)	80% of problems from 20% of causes. Prioritize biggest issues first.
Control Chart	Monitor process stability. Shows UCL (Upper Control Limit) & LCL (Lower Control Limit).
Scatter Diagram	Shows relationship/correlation between two variables
Histogram	Distribution of data (bar chart)
Flowchart	Process flow and improvement opportunities
Affinity Diagram	Groups ideas into categories

Control chart: 7 consecutive data points on one side of mean = Rule of Seven = out of control even if within limits! Process is unstable.

Quality Management vs. Quality Control

Manage Quality (Executing)

Also called Quality Assurance (QA). Audits processes. Confirms processes are correct. Process-oriented. Done THROUGHOUT project.

Control Quality (M&C)

Inspects deliverables. Confirms outputs meet requirements. Product-oriented. Produces Verified Deliverables (input to Validate Scope).

QA (Manage Quality) = process audit. QC (Control Quality) = product inspection. QC → Verified Deliverables → Validate Scope → Accepted Deliverables.

12. Resource Management (Planning + Executing)

PLANNINGEXECUTING

RACI Chart

Letter	Meaning
R	Responsible — does the work
A	Accountable — owns the outcome (only one per activity)
C	Consulted — provides input (two-way)
I	Informed — kept updated (one-way)

Tuckman's Ladder — Team Development Stages

👉 Click any stage below to open a full pop-up window with a stage diagram, the PM's role, conflict level, signs to watch for, an example, an exam scenario, and exam tips.

Forming — Team meets, polite, uncertain, getting to know each other. Little conflict.
Storming — Conflict emerges. Ideas clash. Most conflict happens here. PM must manage.
Norming — Agreement reached. Team starts working well together.
Performing — High performance. Team is productive with minimal conflict.
Adjourning — Project ends. Team disbands.

The goal is to reach PERFORMING. Most conflict occurs in STORMING. PM should focus on getting through storming quickly. The best team is performing!

Motivation Theories

👉 Click any theory below to open a full pop-up window with a diagram/sketch, the full concept, how a PM applies it, an example, an exam scenario, and exam tips.

Theory	Key Concept
Maslow's Hierarchy	5 needs: Physiological → Safety → Social → Esteem → Self-Actualization. Must fulfill lower needs first.
Herzberg's Two-Factor	Hygiene factors (salary, environment) prevent dissatisfaction. Motivators (achievement, recognition) drive motivation.
McGregor Theory X	People are lazy, avoid work, need micromanagement. Negative view.
McGregor Theory Y	People are self-motivated, creative, want responsibility. Positive view. Agile teams.
Theory Z	Increased loyalty and well-being at work leads to higher productivity. Japanese management style.
Expectancy Theory	People behave based on what they EXPECT as a result of their behavior.
McClelland 3 Needs	Achievement, Power, Affiliation — what motivates a person depends on their dominant need.

Types of Power

🏆 Reward — give incentives (positive) 🧠 Expert — based on knowledge (best) 📜 Legitimate — formal position authority 💫 Referent — respect & charisma ⚡ Punishment — punish non-compliance (least desirable)

Expert Power and Referent Power are the BEST forms of power. Punishment Power is the WORST. PMs should strive for Expert/Referent power.

Conflict Resolution Methods

👉 Click any method below to open a full pop-up window with a conflict-mode grid, the win/lose result, when (and when NOT) to use it, an example, an exam scenario, and exam tips.

Method	Result	When to Use
Problem Solving (Confronting)	Win-Win ✅ BEST	Always the FIRST choice. Address root cause.
Compromising	Lose-Lose (partial win)	When both parties give something up
Smoothing	Lose-Lose (temporary)	Emphasize agreements, minimize differences. Temporary fix.
Forcing	Win-Lose	Emergency, quick decision needed
Withdrawal (Avoiding)	Yield-Lose (unresolved)	WORST — conflict not resolved

ALWAYS choose Problem Solving/Confronting first on the exam. Avoid Withdrawal. The goal is Win-Win. Biggest project conflicts = between PM and Functional Manager (schedules, priorities, resources).

13. Communications Management

PLANNING

Communication Channels Formula

Channels = N(N-1) / 2
N = number of people on the project

Example: 10 people → 10(10-1)/2 = 45 channels
Example: 4 people → 4(4-1)/2 = 6 channels
Adding 1 person → complexity increases significantly!

The PM must manage ALL channels. More team members = exponential increase in complexity. This is why small teams are preferred in agile!

Communications Management Plan Contents

Who should receive • What to receive • Who sends it • How (method) • How often • Definitions/glossary

Communication Methods

Method	Description	Example
Interactive	Two-way, real-time	Meetings, phone calls, video conferences
Push	Sent without confirming receipt	Emails, memos, reports
Pull	Receiver retrieves when needed	Intranet, shared drives, databases

Most EFFECTIVE communication = Interactive (two-way). Most EFFICIENT for large audiences = Pull. PM should match method to stakeholder need.

Meeting Best Practices

Always have an agenda distributed before the meeting
Invite only relevant stakeholders
Set start & end times and stick to them
Stay on topic
Distribute meeting minutes with action items afterward

14. Risk Management (Planning)

PLANNING

6 Risk Processes: Plan Risk Management → Identify Risks → Qualitative Analysis → Quantitative Analysis → Plan Responses → (Executing: Implement Responses) → (M&C: Monitor Risks)

Risk Types

⚠️ Negative Risk (Threat)

May harm the project. Strategies: Escalate, Avoid, Transfer, Mitigate, Accept

✅ Positive Risk (Opportunity)

May benefit the project. Strategies: Escalate, Exploit, Share, Enhance, Accept

Risk Response Strategies

👉 Click any row below to open a full pop-up window covering BOTH the threat strategy and its mirror opportunity strategy — with a diagram, descriptions, examples, scenarios, and exam tips.

Threat Strategy	Opportunity Strategy	Description
Escalate	Escalate	Outside project team's authority — go higher
Avoid	Exploit	Threat: Eliminate risk entirely \| Opp: Remove uncertainty, ensure opportunity happens
Transfer	Share	Shift risk to 3rd party (insurance, contracts) \| Share ownership of opportunity
Mitigate	Enhance	Reduce probability/impact \| Increase probability/impact of opportunity
Accept	Accept	Deal with if/when it occurs (active=contingency plan, passive=do nothing)

Risk strategies mirror each other: Avoid↔Exploit, Transfer↔Share, Mitigate↔Enhance. Both sides have Escalate and Accept. Know these cold!

Risk Register Contents

Risk ID • Risk Description • Category • Root Causes • Probability • Impact • Priority (score) • Planned Response • Risk Owner • Status

Risk Probability & Impact Matrix

Probability ↓ / Impact →	Low (1-2)	Medium (3)	High (4-5)
High (4-5)	Medium	High	High
Medium (3)	Low	Medium	High
Low (1-2)	Low	Low	Medium

Qualitative vs. Quantitative Risk Analysis

Qualitative

Prioritizes risks using Probability × Impact. Creates risk ranking. Done FIRST. Always performed. Faster & cheaper.

Quantitative

Assigns numeric values to risks. Uses Monte Carlo simulation, decision trees. Done for HIGH PRIORITY risks only. Requires specialized software.

Qualitative first, then Quantitative for high-priority risks. Not all projects do quantitative analysis. SWOT Analysis is used in Identify Risks process.

Contingency Reserve vs. Management Reserve

	Contingency Reserve	Management Reserve
For	Known risks (identified)	Unknown risks (black swans)
In baseline?	YES (in cost baseline)	NO (above baseline)
Who approves use?	PM can use	Senior management required

15. Procurement Management (Planning)

PLANNING

Make-or-Buy Analysis

Make (Internal)

Use internal resources. Better control, proprietary info stays in-house. Higher upfront cost, uses capacity.

Buy (External)

Hire outside vendor. Specialized expertise, transfer risk, may be cheaper. Less control, dependency on vendor.

Bid Documents

📋 RFI — Request for Information 📝 RFP — Request for Proposal 💰 RFQ — Request for Quote 📊 IFB — Invitation for Bid

RFP = when you need the vendor to propose HOW to do the work. RFQ = when you know what you want and need a price. IFB = for government contracts, most competitive.

Source Selection Criteria

Must be defined BEFORE selecting a seller: Cost, Location, License, Certification, References, Warranty, Experience, Technical capacity.

16. Stakeholder Engagement Planning

PLANNING

Stakeholder Engagement Assessment Matrix

Stakeholder	Unaware	Neutral	Supportive
Mary		C→D
Jane	C		→D
Bob			C/D

C = Current level, D = Desired level. Goal = move all stakeholders to Supportive or Leading.

The 5 engagement levels: Unaware → Resistant → Neutral → Supportive → Leading. PM's goal: move stakeholders from wherever they are to at least Supportive.

17. Direct & Manage Project Work (Executing)

EXECUTING

The PRIMARY executing process. Performing the work defined in the PM Plan. The "summary" of all other executing processes.

Outputs to Know

Deliverables: Unique products/services/results required by the project
Work Performance Data: Raw status data (% complete, start/end dates, # defects, # change requests)
Issue Log: All issues documented, assigned, prioritized, and tracked to resolution
Change Requests: Corrective action, preventive action, defect repair

Manage Project Knowledge

Explicit Knowledge

Can be formally documented and shared: Data, Documents, Records

Tacit Knowledge

In people's heads: Experience, Thinking, Skills — harder to capture

Output: Lessons Learned Register — gathered THROUGHOUT the project, NOT just at the end.

Lessons Learned Register is updated throughout the project! At close, it becomes part of OPA. Knowledge management is critical for organizational learning.

18. Manage Quality (Executing)

EXECUTING

Translating the Quality Management Plan into executable quality activities. Also called Quality Assurance. Process-focused (not product-focused).

Key Quality Tools in Execution

Tool	Purpose
Audits	Structured review of quality processes by independent team
Design for X (DfX)	Design product for specific characteristic (reliability, safety, manufacturability)
Problem Solving	5 Whys, Root Cause Analysis, PDCA cycle
Quality Improvement Methods	PDCA (Plan-Do-Check-Act), Six Sigma, Kaizen

PDCA Cycle (Deming Cycle)

Plan → Do → Check → Act → (repeat)

Manage Quality (QA) = process audits = are we following the right processes? Control Quality (QC) = product inspection = does the product meet requirements?

19. Acquire & Develop Team (Executing)

EXECUTING

Acquire Resources Tools

Pre-Assignment

Resources assigned before project starts. Written into charter or contract.

Virtual Teams

Team members in different locations. Need strong communication tools.

Develop Team — Key Tools

Tool	Description
Training	Formal or informal — improves team competencies
Team-Building	Activities to improve cohesion and performance
Colocation	War room — team works physically together. Best for communication.
Recognition & Rewards	Reward desirable behavior. Only reward what you WANT more of.
Individual & Team Assessments	360° feedback, personality assessments (MBTI)

Output: Team Performance Assessments

Evaluates team effectiveness. Used to identify: training needs, skill gaps, mentoring needs, team cohesion issues.

The PM is primarily responsible for developing the team. Recognition and rewards only for DESIRED behaviors — don't reward the wrong things!

20. Manage Team (Executing)

EXECUTING

Tracking team member performance, providing feedback, resolving issues, and managing team changes. Combination of communication, conflict management, negotiation, leadership.

⚠️ Manage Team vs. Develop Team (don't confuse!)

Aspect	👥 Develop Team	🛠️ Manage Team
Goal	Improve competencies, team interaction & environment — build the team UP.	Track performance, give feedback, resolve issues, manage changes — keep the team ON TRACK.
Main focus	Capability & cohesion (the future).	Performance & problems (the present).
Key tools	Team building, training, recognition & rewards, colocation, ground rules, individual/team assessments.	Conflict management, emotional intelligence, influencing, leadership, decision making, PMIS.
Signature output	Team Performance Assessments.	Change Requests (e.g., staffing changes).
Process group	Executing	Executing

Memory hook: Develop = build them UP (training, team-building) → output is team performance assessments. Manage = keep them ON TRACK (feedback, issues, conflict) → output is change requests. Team performance assessments are an INPUT to Manage Team.

Conflict Sources (Most Common First)

Schedules (most common)
Project Priorities
Resources
Technical Opinions
Administrative Procedures
Cost
Personality (least common)

Biggest conflict = between PM and Functional Manager in Matrix org. Most common conflict source = SCHEDULES. Problem Solving/Confronting is always the BEST resolution.

Emotional Intelligence (EQ)

Ability to recognize, understand, and manage emotions in oneself and others. Key PM skill for:

Resolving conflicts faster
Building stronger team relationships
Engaging stakeholders effectively
Making better decisions under pressure

4 components (Goleman): Self-Awareness, Self-Management (self-regulation), Social Awareness (empathy), Relationship Management (social skills).

Inbound vs. outbound EI: Inbound = understanding your own and others' emotions; Outbound = managing relationships and influencing others' emotions.

Manage Team — Tools & Techniques

Interpersonal & Team Skills:

Conflict Management — resolve disagreements (Problem Solving/Confronting is best). See §12 for the 5 methods.
Decision Making — voting, multicriteria analysis; involve the team appropriately.
Emotional Intelligence — read and manage emotions to defuse tension.
Influencing — persuade and build consensus, especially with little formal authority (matrix orgs).
Leadership — set vision, motivate, and adapt style to the situation.

Plus: Project Management Information System (PMIS) — to track and report on team performance.

Influencing & the 5 Forms of Power

🎓 Expert — knowledge/skill (BEST) 🏆 Reward — give incentives (strong) 🏛️ Formal / Legitimate — by position 🌟 Referent — respect, charisma, relationships ⚡ Punishment / Coercive — penalties (WORST)

Expert and Reward power are the most effective and build commitment. Punishment/Coercive is the least desirable and erodes trust. New PMs often start with formal power but should earn expert and referent power over time. (Also covered in §12 Resource Management.)

Issue Log — Track Issues to Resolution

The Issue Log is the central project document for recording and tracking issues (current problems needing resolution) during Manage Team. It is both an INPUT and an OUTPUT of the process.

Typical fields: Issue ID, type/category, description, who raised it, assigned owner, priority, target resolution date, status, and final resolution.

A team member raises a recurring blocker. The PM logs it in the Issue Log, assigns an owner and a target date, and tracks it to closure — rather than letting it linger (which would let conflict escalate).

Key Inputs & Outputs (Manage Team)

Key Inputs	Key Outputs
Resource Management Plan; Issue Log; Lessons Learned Register; Project Team Assignments; Team Charter; Team Performance Assessments; Work Performance Reports; EEF/OPA	Change Requests (e.g., staffing changes); PM Plan updates; Project Document updates (issue log, lessons learned, team assignments); EEF updates

If managing the team leads you to add, move, or replace people, that is a change request — route it through Perform Integrated Change Control. Managing the team can change the resource plan, schedule, and cost.

21. Manage Communications & Implement Risk Responses

EXECUTING

Manage Communications

Ensuring timely and appropriate gathering, creation, distribution, storage, retrieval, and monitoring of project information. Follow the Communications Management Plan.

Output: Project Communications (performance reports, deliverable status, baseline reporting)

Implement Risk Responses

Execute risk response plans when a risk HAS occurred (threats) or to capture opportunities. Minimizes threats, maximizes opportunities.

Output: Change Requests (when response affects baseline), Project Document Updates

Implement Risk Responses is an EXECUTING process — it executes the plans made in Plan Risk Responses. Monitor Risks is in M&C — it watches for new risks and checks if responses worked.

22. Conduct Procurements (Executing)

EXECUTING

Obtaining seller responses, selecting a seller, and awarding a contract.

Key Tools

Advertising: Required for some government contracts. Broader pool of sellers.
Bidder Conferences (Pre-bid/Vendor conferences): Meeting between buyer and ALL potential sellers at same time. Ensures equal information access. ALL Q&A must be documented and shared with everyone.
Proposal Evaluation: Using source selection criteria
Negotiations: Used to finalize contract terms

Outputs: Selected Sellers + Agreements (contracts)

Bidder conferences ensure ALL sellers get the SAME information. No private conversations with individual sellers. All questions answered publicly in writing.

23. Monitor & Control Project Work

MONITORING & CONTROLLING

Tracking, reviewing, and recording progress against the PM Plan. Identifies areas needing change. Creates Work Performance Reports from Work Performance Information.

Monitor & Control Work ≠ Integrated Change Control. M&C Work identifies changes needed. ICC evaluates and approves/rejects change requests. They work together.

Control Schedule Key Concepts

Compare actual progress vs. schedule baseline
Output: Schedule Forecasts (EAC, ETC — see EVM section)
Use Critical Path, Schedule Compression, Resource Optimization to fix variances

24. Perform Integrated Change Control

MONITORING & CONTROLLING

Reviewing, evaluating, approving, deferring, or rejecting all change requests. The CCB (Change Control Board) makes decisions.

Change Control Process

Stakeholder identifies need for change
Written Change Request submitted to PM
PM assesses impact on scope, schedule, cost, quality, resources, risk
Submitted to Change Control Board (CCB)
CCB approves OR rejects
If APPROVED: PM updates PM Plan and baselines → manages to new plan
If REJECTED: team revisits the issue

ANY stakeholder can REQUEST a change. ONLY the CCB can APPROVE changes (except for emergency situations where PM may act). ALL change requests must be documented in writing.

After an approved change, baselines are UPDATED. The PM then manages to the NEW baseline. The PM does NOT work to the old baseline after an approved change.

25. Control Scope & Control Schedule

MONITORING & CONTROLLING

Control Scope

Monitoring status of project & product scope. Managing changes to scope baseline. Identifies Scope Creep — uncontrolled expansion without time/cost adjustments.

Output: Work Performance Information (planned vs. actual), Change Requests

Control Schedule

Compare schedule to baseline
Schedule Forecasts using EVM (EAC, VAC, SPI)
Use Crashing or Fast-Tracking to recover
Schedule Variance = EV − PV

Scope Creep = uncontrolled scope change without a change request. GOLD PLATING = adding features the customer didn't ask for — also WRONG! Both must be avoided.

26. EVM — Earned Value Management (Control Costs)

MONITORING & CONTROLLING

EVM is the #1 most-tested calculation topic on the PMP exam. Master these formulas!

EVM Base Values

Acronym	Name	What It Means
PV	Planned Value	Budgeted cost of work PLANNED to be done by this point
EV	Earned Value	Budgeted cost of work ACTUALLY DONE (% complete × BAC)
AC	Actual Cost	Actual money SPENT on work done
BAC	Budget at Completion	Total planned budget for the project

Variances & Indices

CV = EV − AC    (Cost Variance: positive=under budget, negative=over budget)
SV = EV − PV    (Schedule Variance: positive=ahead, negative=behind)

CPI = EV / AC    (Cost Performance Index: >1 = good, <1 = bad)
SPI = EV / PV    (Schedule Performance Index: >1 = ahead, <1 = behind)

Forecasting Formulas

EAC = Estimate at Completion (expected total cost)

EAC = BAC / CPI                    (if current CPI continues)
EAC = AC + ETC                  (if original estimate no longer valid)
EAC = AC + (BAC−EV)           (if future work at planned rate)
EAC = AC + (BAC−EV)/CPI (if future work at current CPI)

ETC = EAC − AC    (Estimate to Complete: how much MORE to spend)
VAC = BAC − EAC (Variance at Completion: positive=under budget)
TCPI = (BAC−EV)/(BAC−AC) or (BAC−EV)/(EAC−AC)
        (Efficiency needed to finish on budget; >1 = harder)

EVM Interpretation Table

Metric	> 0 or > 1	= 0 or = 1	< 0 or < 1
CV	Under budget ✅	On budget	Over budget ❌
SV	Ahead of schedule ✅	On schedule	Behind schedule ❌
CPI	Under budget ✅	On budget	Over budget ❌
SPI	Ahead ✅	On schedule	Behind ❌

EVM Example — Practice!

Project data: BAC = $100,000 | PV = $40,000 | EV = $35,000 | AC = $42,000

CV = EV−AC = 35K−42K = −$7,000 (OVER budget)
SV = EV−PV = 35K−40K = −$5,000 (BEHIND schedule)
CPI = EV/AC = 35/42 = 0.83 (spending $1.20 for every $1.00 of work)
SPI = EV/PV = 35/40 = 0.875 (only 87.5% of planned work done)
EAC = BAC/CPI = 100K/0.83 = ~$120,482 (over budget at completion)
ETC = EAC−AC = 120,482−42,000 = ~$78,482 remaining to spend
VAC = BAC−EAC = 100K−120,482 = −$20,482 (will be over budget)

If CPI < 1 = over budget. If SPI < 1 = behind schedule. TCPI > 1 means you need to be MORE efficient to finish on budget. The most common EAC formula = BAC/CPI (assumes current performance continues).

27. Validate Scope (M&C)

MONITORING & CONTROLLING

Formalizing acceptance of completed project deliverables. Done with customer/sponsor. Concerned with correctness of the deliverable.

Flow

Control Quality (verify product) → Verified Deliverables → Validate Scope (customer acceptance) → Accepted Deliverables → Close Project

Key Difference

Control Quality = internal check (does it meet specs?)
Validate Scope = external check (customer formally accepts it)

Validate Scope = CUSTOMER signs off. Control Quality = internal team inspects. Deliverables go to QC first, then to customer for validation. If customer rejects → Change Request for defect repair.

28. Control Quality & Control Resources

MONITORING & CONTROLLING

Control Quality

Inspects deliverables. Produces Verified Deliverables and Quality Control Measurements.

Tools: Inspection, Testing/Product Evaluations, Statistical Sampling, Control Charts, Checklists

Control Resources

Manages PHYSICAL resources only (not HR — that's Manage Team). Ensures physical resources assigned and released per plan.

Tools: Data Analysis, Problem Solving, Interpersonal & Team Skills, PMIS

Control Resources = physical resources (equipment, materials). Manage Team = human resources (people). Both are in M&C and Executing respectively.

29. Close Project or Phase (Closing)

CLOSING

The ONLY closing process. Finalizes ALL activities for the project, phase, or contract. The most important thing to remember about closing.

Close Project Activities

Verify all documents and deliverables are up to date
Confirm formal customer acceptance of deliverables
Close project accounts and release resources
Formally confirm acceptance of seller's work; finalize open claims
Audit project success or failure
Document lessons learned and archive project information
Transfer deliverables to operations or next phase
For terminated projects: document reasons for termination — still must be FORMALLY CLOSED

Close Project Outputs

Final Report

Summary of what took place: how successful, baseline variances, final costs, lessons learned

Final Product/Service/Result Transition

Official transfer of the deliverable to the organization/operations

Projects terminated early MUST still be formally closed! Closing happens for EVERY phase too, not just at project end. Lessons Learned Registry becomes OPA at close.

30. Agile Mindset & Manifesto

Agile Manifesto — 4 Values

We Value MORE…	…Over
Individuals & Interactions	Processes & Tools
Working Software	Comprehensive Documentation
Customer Collaboration	Contract Negotiation
Responding to Change	Following a Plan

Note: Items on the right HAVE VALUE, but items on the left are valued MORE.

12 Agile Guiding Principles (Summary)

Customer satisfaction through early & continuous delivery
Welcome changing requirements, even late in development
Deliver working software frequently (weeks to months)
Business & developers work together DAILY
Build around motivated individuals; trust them
Face-to-face conversation = most effective communication
Working software = primary measure of progress
Sustainable development pace — indefinitely maintainable
Continuous attention to technical excellence & good design
Simplicity — maximize work NOT done
Best architectures emerge from self-organizing teams
Regular reflection & adaptation at intervals (retrospectives)

Agile vs. Traditional PM

Aspect	Traditional (Predictive)	Agile (Adaptive)
Planning	Upfront, comprehensive	Throughout, just-in-time
Scope	Fixed scope, variable time/cost	Fixed time/cost, variable scope
Change	Discouraged, formal process	Welcomed, expected
Delivery	All at end	Increments throughout
Customer	Involved at start and end	Involved throughout
Team	Follows PM direction	Self-organizing
Documentation	Comprehensive	Barely sufficient

The Iron Triangle — Inverted in Agile

Agile Mindset Key Behaviors

✅ Welcome change 📦 Work in small increments 🔄 Feedback loops 🧪 Fail fast & learn 💎 Value-driven delivery 🚀 Continuous improvement

In Agile, the triangle is INVERTED: Time & Cost are fixed; Scope is variable. In Traditional: Scope is fixed; Time & Cost are variable.

When Agile Fits Best vs. When Predictive Fits

✅ Lean toward Agile when…

Requirements are unclear, evolving, or likely to change
High uncertainty, complexity, or innovation
Fast feedback and early/incremental value are important
Customer can engage continuously
Team is empowered, collaborative, and self-organizing
Work can be split into small, deliverable increments

📐 Lean toward Predictive when…

Requirements are stable, clear, and well-understood
Low expected change; sequential dependencies
Regulatory / compliance or fixed-scope contracts
Deliverable is best released all at once
Familiar, repeatable work with proven methods

Many real projects are Hybrid — agile for uncertain/evolving parts, predictive for stable/regulated parts. Choosing the approach is Tailoring (PMBOK 7 principle).

⚠️ Agile Myths vs. Reality

Myth (wrong)	Reality (exam-correct)
Agile means NO planning	Agile plans continuously — just-in-time and more often (rolling wave)
Agile means NO documentation	Agile produces "barely sufficient" documentation — not zero
Agile has no discipline or process	Agile is highly disciplined — cadence, Definition of Done, reviews, retrospectives
Agile has no leadership	Leaders serve the team (servant leadership); the team self-organizes
Agile is automatically faster/cheaper	Agile delivers value sooner and reduces risk — not guaranteed cheaper
Scope is unlimited / anything goes	Scope is variable but bounded by fixed time/cost and priority order

Servant Leadership — the Agile Leader's Role

In Agile, the leader (PM / Scrum Master / team facilitator) leads by serving the team — flipping the traditional org pyramid so the leader supports the people doing the work.

Remove impediments and blockers for the team
Shield the team from interruptions and distractions
Facilitate, coach, and mentor rather than command
Empower the self-organizing team to make decisions
Lead with a "How can I help?" mindset

A blocker stalls the team. The servant leader doesn't dictate a fix — they remove the obstacle and let the empowered team decide how to proceed.

Linked concept: servant leadership aligns with McGregor's Theory Y (people are motivated and seek responsibility).

31. Scrum Framework

Scrum Three Pillars

👁️ Transparency — visible to all 🔍 Inspection — timely checks on progress 🔧 Adaptation — adjust when deviating

Scrum Roles

Role	XP Equivalent	Responsibilities
Product Owner	Customer	Owns product vision; prioritizes backlog; defines features; represents business value
Scrum Master	Coach	Facilitates process; removes impediments; servant leader; protects team from interruptions
Development Team	Team	Cross-functional; self-organizing; 3-9 members ideal; does actual work

Scrum Events (Activities)

Event	Time	Purpose
Sprint Planning Meeting	Before sprint	What to build & how to build it. Outputs Sprint Backlog.
Sprint	1-4 weeks (timebox)	Build potentially shippable increment. No changes during sprint.
Daily Standup/Scrum	15 min/day	3 questions: What did I do yesterday? Today? Any impediments?
Sprint Review	End of sprint	Stakeholders see demo. Gather feedback. Inspect increment.
Sprint Retrospective	After review	Team improves: What went well? Wrong? Do more/less of? ~2 hours.

Scrum Artifacts

Artifact	Description	Who Manages
Product Backlog	Prioritized list of ALL work to be done. Dynamic. Most valuable = first.	Product Owner
Sprint Backlog	Work selected for THIS sprint + plan. Only dev team updates.	Development Team
Product Increment	Done portion of product after each sprint. Must meet Definition of Done.	Dev Team delivers

Definition of Done (DoD)

Shared understanding of what "done" means. Defined at project start. Applies globally. Examples: Unit tests pass, documentation complete, code reviewed.

Sprint = Iteration. Daily Standup = Daily Scrum = 15 min. Product Owner = only person who prioritizes backlog. Scrum Master = servant leader, removes impediments. Backlog Grooming = refinement.

Only the PRODUCT OWNER can prioritize the product backlog. If PO refuses to prioritize — coach/train them on the benefits. NEVER prioritize yourself as PM/Scrum Master!

32. XP, Kanban & Lean

Extreme Programming (XP)

Software-centric agile method. Focus on good software development practices.

5 Core Values: Simplicity, Communication, Feedback, Courage, Respect

Key Practices:

Test-Driven Development (TDD): Write tests BEFORE writing code
Pair Programming: 2 developers work together; real-time code review
Continuous Integration: Integrate code frequently to catch issues early
Collective Code Ownership: Any dev pair can change any code
Refactoring: Continuously improve code quality
Sustainable Pace: No prolonged overtime (40-hour week)

Kanban

Visual workflow management system. Derived from Toyota lean production.

5 Core Principles:

Visualize the workflow (Kanban board)
Limit WIP (Work in Progress) — reduce bottlenecks
Manage flow — track work through system
Make process policies explicit — everyone understands rules
Improve collaboration — scientific measurement & experimentation

Kanban Board columns: To Do | In Progress | Testing | Done

Lean Software Development

Derived from Toyota Production System. 7 principles:

🗑️ Eliminate Waste 📚 Amplify Learning ⚡ Deliver Fast 🌐 Optimize the Whole ✅ Build Quality In 🕐 Defer Decisions 💪 Empower the Team

7 Wastes of Lean: Partially done work, Extra processes, Extra features, Task switching, Waiting, Motion, Defects

Scrum Term	XP Equivalent	Definition
Sprint	Iteration	Fixed-length timebox
Release Planning	Planning Game	Agile planning meetings
Product Owner	Customer	Business representative
Retrospective	Reflection	Lessons-learned meeting
Scrum Master	Coach	Agile PM/facilitator
Daily Scrum	Daily Standup	15-min daily status

33. Agile Planning & Metrics

User Stories

Format: As a <user type>, I <want/need> <goal>, So that <value/reason>

Example: "As a payroll clerk, I want to view a report of all payroll taxes, so that I can pay them on time"

INVEST Criteria for Good User Stories

I — Independent N — Negotiable V — Valuable E — Estimatable S — Small (4-40 hours) T — Testable

Estimation Techniques

Technique	Description
Planning Poker	Team uses Fibonacci cards (1,2,3,5,8,13,21) to estimate independently then discuss. Prevents anchoring.
Story Points	Relative sizing using Fibonacci sequence. Team-owned definition.
T-Shirt Sizing	XS, S, M, L, XL — quick relative estimation
Affinity Estimating	Group stories into similar-sized buckets
Wideband Delphi	Anonymous expert panel. Prevents bandwagon/groupthink/HIPPO effect.

Agile Metrics

Velocity

Story points completed per sprint. Used to forecast how many sprints needed.

Iterations = Total Points / Average Velocity
Example: 250 points / 18 velocity = ~14 more iterations

Burn Charts

Burndown: Work REMAINING over time (going down = good)
Burnup: Work COMPLETED over time (going up = good)

MoSCoW Prioritization

🔴 M — Must Have 🟠 S — Should Have 🟢 C — Could Have ⚪ W — Won't Have (this time)

Sprint Retrospective Stages (~2 hours)

#	Stage	Duration	Activity
1	Set Stage	6 min	Focus team, encourage participation, ESVP
2	Gather Data	40 min	Timeline, Mad/Sad/Glad, Triple Nickels
3	Generate Insights	25 min	5 Whys, Fishbone, dot voting
4	Decide What to Do	20 min	Start/Stop doing, SMART Goals
5	Close Retrospective	20 min	Plus/Delta reflection

Retrospective is different from Sprint Review. Review = show work to customers. Retrospective = internal team improvement meeting. Both happen at end of sprint.

34. Hybrid Approaches

Uses a combination of traditional (waterfall) methods with agile. Can be implemented many ways based on project risk and uncertainty.

When to Use Each Approach

Approach	Best For
Predictive	Well-defined requirements, clear procedures, proven processes, low uncertainty (car manufacturing)
Adaptive/Agile	High uncertainty, high change rate, new/complex work, software development
Hybrid	Mix of definable and uncertain work. Most real-world projects.

4 Hybrid Methods

Agile development then predictive rollout — Build in sprints, deploy traditionally
Combined simultaneous — Parts of project use agile, others predictive, running together
Predominantly predictive with some agile — Waterfall with agile sprints for uncertain parts
Predominantly agile with some predictive — Agile with traditional planning for certain parts

The PMP exam has ~50% predictive and ~50% agile/hybrid questions. Know BOTH well. The exam tests situational judgment — pick the approach that fits the context!

Iteration Types

Type	Purpose
Iteration 0	Set stage for development; no actual product built; setup infrastructure
Development Iteration	Build the product increment
Iteration H (Hardening)	Clean up code, produce documentation, final testing
Spike	Research/proof of concept for uncertain technical elements

35. Leadership & Motivation Theories

Situational Leadership

Effective leaders ADAPT their style to the situation and individual team member's skill/motivation level.

OSCAR Model (coaching tool):

Outcome — identify the desired outcome
Situation — assess current skills/knowledge
Choices/Consequences — identify options and consequences
Actions — commit to specific steps
Review — regular check-ins for support

Drexler/Sibbet Team Performance Model

7 Steps:

1️⃣ Orientation (Why?) 2️⃣ Trust Building (Who?) 3️⃣ Goal Clarification (What?) 4️⃣ Commitment (How?) 5️⃣ Implementation (Start!) 6️⃣ High Performance 7️⃣ Renewal (Changes)

Steps 1-4 = creating the team. Steps 5-7 = sustaining performance.

Maslow's Hierarchy of Needs

Level	Need	Project Example
5 (Top)	Self-Actualization	Growth opportunities, challenging work
4	Esteem	Recognition, awards, performance reviews
3	Social/Love	Team building, belonging, good team culture
2	Safety	Job security, safe working conditions
1 (Base)	Physiological	Pay (salary), basic working conditions

Must satisfy LOWER levels before higher ones become motivators. You can't motivate someone with recognition (esteem) if they're worried about keeping their job (safety).

Servant Leadership (Agile PM)

Shield team from interruptions/distractions
Remove impediments to progress
Re-communicate project vision
Provide what the team needs (tools, training, support)

In Agile, the PM is a SERVANT LEADER — they serve the team, not direct them. The team is self-organizing and self-directing. PM enables, not commands.

36. Change Models

ADKAR Model

Individual change model — 5 sequential steps:

Awareness — Why the change is needed
Desire — Desire to support the change
Knowledge — How to make the change
Ability — Hands-on practice of the change
Reinforcement — Rewards to sustain the change

Kotter's 8-Step Model

Top-down organizational change model:

Create urgency
Form a powerful coalition
Create a vision for change
Communicate the vision
Remove obstacles
Create short-term wins
Build on the change
Anchor changes in corporate culture

Virginia Satir Change Model

1. Late Status Quo 2. The Foreign Element 3. Chaos 4. Transforming Idea 5. Practice & Integration 6. New Status Quo

Helps team members understand their emotional journey through change.

Bridges Transition Model

Ending, Losing, Letting Go — Accepting the old way is gone
The Neutral Zone — Between old and new; confusion and opportunity
The New Beginning — Embracing the new way

Focuses on psychological experience of transition, not just the external change.

Know ALL 4 change models: ADKAR (individual steps), Kotter (8 steps, top-down), Satir (6 stages, emotional journey), Bridges (3 transitions, psychological).

37. Contract Types

Three Main Contract Types

Type	Risk Holder	When to Use	Subtypes
Fixed Price (FP/Lump Sum)	SELLER has risk	Well-defined, stable scope	FFP, FPIF, FP-EPA
Cost Reimbursable (CR)	BUYER has risk	Poorly defined scope, research	CPFF, CPIF, CPAF
Time & Material (T&M)	BUYER has risk	Scope not clear, labor + materials	(no subtypes)

Fixed Price Subtypes

FFP (Firm Fixed Price): Price is set, cannot change. Maximum seller risk.
FPIF (Fixed Price Incentive Fee): Fixed price plus bonus for meeting targets (early finish, under cost).
FP-EPA (Fixed Price Economic Price Adjustment): Fixed price adjusted for economic conditions over long contract period (inflation).

Cost Reimbursable Subtypes

CPFF (Cost Plus Fixed Fee): Buyer pays costs + fixed fee to seller. Seller fee doesn't change.
CPIF (Cost Plus Incentive Fee): Buyer pays costs + bonus if targets met (e.g., finish 2 weeks early).
CPAF (Cost Plus Award Fee): Buyer pays costs + award based on subjective satisfaction rating.

T&M Contract

Buyer pays for time (labor hours × rate) AND materials. Buyer has ALL risk of overrun. Only use when scope is high-level or unknown. Should include a "not-to-exceed" clause.

Fixed Price = seller has risk. Cost Reimbursable = buyer has risk. The BEST contract is mutually beneficial to buyer AND seller. FFP = most seller risk. CPAF = most buyer risk.

38. Complete EVM Formula Sheet

Master these 15 formulas = master the PMP cost & schedule performance questions!

Formula	Acronym	Meaning	Good / Bad
EV − AC	CV	Cost Variance	+ = under budget; − = over budget
EV − PV	SV	Schedule Variance	+ = ahead; − = behind
EV / AC	CPI	Cost Performance Index	>1 = good; <1 = bad
EV / PV	SPI	Schedule Performance Index	>1 = good; <1 = bad
BAC / CPI	EAC	Estimate at Completion (most common)	Compare to BAC
AC + (BAC−EV)	EAC	EAC if future work at planned rate	Optimistic
AC + (BAC−EV)/CPI	EAC	EAC if future work at current CPI	Realistic
EAC − AC	ETC	Estimate to Complete (remaining)	Less = better
BAC − EAC	VAC	Variance at Completion	+ = under budget at end
(BAC−EV)/(BAC−AC)	TCPI	To Complete Performance Index (vs BAC)	<1 = achievable
(BAC−EV)/(EAC−AC)	TCPI	TCPI (vs EAC)	<1 = achievable
N(N−1)/2	Channels	Communication channels	More people = more complexity
(O+4M+P)/6	PERT	Three-point estimate (Beta)	More accurate
(P−O)/6	SD	Standard Deviation	Smaller = more certain
(O+M+P)/3	Triangle	Three-point estimate (Triangle)	Less weighted

Quick-Reference Mnemonics

CV & SV both use EV first: EV-AC (cost), EV-PV (schedule)

CPI & SPI both divide BY something: EV/AC (cost), EV/PV (schedule)

"Is negative = BAD": Negative CV = over budget. Negative SV = behind schedule.

"Less than 1 = BAD": CPI < 1 = spending too much. SPI < 1 = going too slow.

EAC most used = BAC/CPI (assumes current efficiency continues)

39. PM Mindset — Key Exam Behaviors

Traditional PM Mindset — Key Rules

Identify & analyze stakeholders THROUGHOUT the project, not just at beginning
NEVER take actions without first creating a plan
All change requests must go through change control — no exceptions
Consult project team before making decisions (bottom-up estimates)
PM is an INTEGRATOR — manage all aspects, not just one
Update Lessons Learned THROUGHOUT the project
When closing — ensure all bills paid, resources released
Terminated projects still need FORMAL CLOSE
ALL scope changes impact cost, schedule, quality, resources, risk
Best people to break down work = PROJECT TEAM (not PM alone)
Best people to determine estimates = PROJECT TEAM
Best people to check deliverable quality = CUSTOMERS

Agile PM Mindset — Key Rules

Be a SERVANT LEADER — empower, enable, remove impediments
Only PRODUCT OWNER prioritizes backlog — never do it yourself
Use co-location; face-to-face communication is best
Information radiators: burndown/burnup charts, Kanban boards
Team solves problems — coach & support, don't dictate solutions
Provide safe environment for disagreement & experimentation
Limit Work in Progress (WIP)
Re-communicate project vision consistently
Understand team needs and motivators
Review methods via retrospectives — continuous improvement

Critical "Always/Never" Rules for the Exam

✅ ALWAYS proactively identify stakeholders throughout the project
✅ ALWAYS resolve conflicts with Problem Solving/Confronting first
✅ ALWAYS get change requests in writing
✅ ALWAYS consult the team before making decisions
✅ ALWAYS update Lessons Learned throughout the project (not just at end)
❌ NEVER skip formal change control for "small" scope changes
❌ NEVER add unrequested features (gold plating)
❌ NEVER prioritize the agile backlog yourself — that's the Product Owner's job
❌ NEVER punish people who report bad news
❌ NEVER accept a project without a Project Charter

40. Mega Cheat Sheet — Last-Day Review

5 Process Groups: Initiating(2) → Planning(24) → Executing(10) → M&C(12) → Closing(1) = 49 processes
10 KAs: Integration, Scope, Schedule, Cost, Quality, Resource, Communications, Risk, Procurement, Stakeholder
Only KA in ALL 5 PGs: Integration
12 Principles (PMBOK 7): Stewardship, Team, Stakeholders, Value, Systems Thinking, Leadership, Tailor, Quality, Complexity, Risk, Adaptability, Change

Quick Reference — Key Terms

Term	Key Fact
Project Charter	Signed by SPONSOR. Formally authorizes project. Gives PM authority.
WBS 100% Rule	Must include 100% of work — no more, no less
Scope Baseline	= Scope Statement + WBS + WBS Dictionary
Schedule Baseline	Approved schedule. Only changed via formal change control.
Cost Baseline	= Activity costs + Contingency Reserves. NOT management reserves.
Project Budget	= Cost Baseline + Management Reserves
PERT	(O+4M+P)/6. SD=(P-O)/6
Critical Path	Longest path = shortest project. Float = 0 on critical path.
Crashing	Add resources. ALWAYS adds cost. On critical path only.
Fast Tracking	Parallel activities. May NOT add cost. Adds rework risk.
CPI < 1	OVER budget (spending more than earned)
SPI < 1	BEHIND schedule (less work done than planned)
QA vs QC	QA = process audit (Executing). QC = product inspection (M&C).
Validate Scope	Customer formally accepts deliverables. Output = Accepted Deliverables.
Tuckman's stages	Forming→Storming→Norming→Performing→Adjourning. Most conflict = Storming.
Best conflict resolution	Problem Solving/Confronting = Win-Win. Always first choice.
Best power type	Expert Power. Worst = Punishment Power.
Channels formula	N(N-1)/2
Best communication	Interactive (face-to-face)
FFP contract	Seller has ALL risk. Use when scope is well-defined.
CPFF contract	Buyer pays ALL costs + fixed fee. Buyer has most risk.
Product Owner	ONLY person who prioritizes product backlog in Scrum.
Scrum Master	Servant leader. Facilitates. Removes impediments. Protects team.
Sprint	1-4 weeks timebox. NO changes during sprint. Same team throughout.
Daily Scrum	15 minutes. 3 questions: yesterday/today/impediments.
Retrospective	Team improves. ~2 hours. After sprint. Internal.
Sprint Review	Demo to customers. Get feedback. External facing.
ADKAR	Awareness→Desire→Knowledge→Ability→Reinforcement
Kotter's 8 steps	Urgency→Coalition→Vision→Communicate→Remove obstacles→Short wins→Build→Anchor
Theory X	Bad. People lazy, need micromanaging.
Theory Y	Good. People self-motivated. Agile teams.
Herzberg Hygiene	Prevent dissatisfaction (salary, environment). Not true motivators.
Earned Value (EV)	% complete × BAC. What was ACTUALLY accomplished.
Contingency Reserve	For known risks. PM approves use. IN cost baseline.
Management Reserve	For unknown risks. Senior mgmt approves. NOT in baseline.
Scope Creep	Uncontrolled scope expansion. Always bad. Needs change request.
Gold Plating	Adding unrequested features. Always wrong in PM.
Risk Register	Lists all identified risks with responses and owners.
Risk Avoid	Eliminate threat entirely. Most aggressive threat response.
Risk Exploit	Ensure opportunity happens. Most aggressive opportunity response.
Lessons Learned	Updated THROUGHOUT project. Becomes OPA at close.
PMO Directive	Highest authority PMO. PM reports to PMO. PM assigned by PMO.
Projectized Org	PM has highest authority. Full-time team. Team reassigned at end.

You've covered all the major PMP topics! The PMP exam is situational — read questions carefully and pick the BEST answer for the PM approach. When in doubt: Plan first, consult team, follow change control, protect project objectives.

41. Agile Declaration of Interdependence (DOI) & Shared Vision Tools

Agile Declaration of Interdependence (DOI)

The DOI is a companion to the Agile Manifesto, written by project leaders for linking people, projects, and value. Six commitments:

Continuous flow of value — Increase ROI through continuous delivery
Frequent customer interactions — Deliver reliable results via shared ownership
Expect uncertainty — Manage through iterations, anticipation, and adaptation
Unleash creativity — Individuals are the ultimate source of value; create an empowering environment
Group accountability — Boost performance through shared responsibility
Situationally specific strategies — Improve effectiveness through context-specific processes

DOI = for PROJECT LEADERS (not just developers like the Manifesto). It links people, projects, and VALUE. Focus: continuous flow + customer interaction + uncertainty management.

Setting a Shared Vision — Tools

Both customers and agile teams must have the SAME vision. Tools to establish this:

Tool	Description	Purpose
Agile Charter	High-level project overview for agile projects	Aligns team and stakeholders on goals
Definition of "Done"	Shared criteria for what completed work looks like	Applied to user stories, releases, final deliverables
Use Case Diagrams	Visual showing HOW users will interact with a system	Requirements clarity
Data Models	How data is structured in tables and their relationships	Technical alignment
Wireframes	Quick mock-up / "low-fidelity prototype" of the product UI	Clarify what "done" looks like before coding; validate approach
Personas	Quick guides describing key users — their goals, context, needs	Help team focus on valuable features

Wireframes

Purpose: Low-fidelity prototyping of the product interface

Quick sketches or digital mockups — no final styling
Clarify what "done" looks like BEFORE any coding begins
Validate the approach before full execution
Stakeholders can see and react to the layout/flow early

Personas

Purpose: Fictional but realistic descriptions of key users to guide feature development

Provide context: who uses the product, how, and why
Be grounded in reality (based on research)
Be goal-oriented, specific, relevant
Help the team focus on what features TRULY matter to users

Example Persona: "Andrew Jones, Certified Accountant — wants automated bill payments and weekly receivables/payables reports for clients."

Wireframes = visual prototype BEFORE building. Personas = user profile cards. Both help the team and customer agree on what to build BEFORE the sprint starts. They establish shared vision.

42. SAFe, Feature-Driven Development & Crystal

SAFe® — Scaled Agile Framework

Implements Scrum at an enterprise level. For large, distributed organizations running many agile teams simultaneously.

Consumes the whole enterprise — not just one team
Deals with big global teams
All aspects of the organization are managed together
Three important parts:
1. Lean Product Development — eliminate waste, deliver fast
2. Agile Software Development — iterative, collaborative
3. System Thinking — optimize the entire value stream, not just one team

Feature-Driven Development (FDD)

Agile method focused on designing and building features (user-valued functions).

Process:

Develop an overall model for the product
Build a features list
Plan by feature
Design by feature
Build by feature

Each feature is small — can typically be completed in 1–2 weeks. Strong emphasis on code ownership and inspections.

Crystal

A family of customized methodologies coded by color, scaled to team size and project criticality.

Color	Team Size	Project Type
Crystal Clear	Small (1-6 people)	Non-critical projects
Crystal Yellow	Small-medium	Moderate criticality
Crystal Orange	Medium (10-40)	Business-critical
Crystal Magenta/Red	Large teams	Mission/life-critical work

Core properties: Frequent delivery, Reflective improvement, Osmotic communication, Personal safety, Focus, Easy access to expert users, Technical environment.

Agile Methods Comparison

Method	Key Focus	Best For
Scrum	Iterative sprints, roles, ceremonies	Most project types
XP	Technical practices (TDD, pair programming)	Software teams
Kanban	Visualize flow, limit WIP	Operations, support, maintenance
Lean	Eliminate waste	Manufacturing-influenced software
SAFe	Enterprise-scale agile	Large organizations
FDD	Feature-by-feature delivery	Larger teams with strong modeling
Crystal	Right-sized methodology	Varied team sizes

The exam may reference SAFe for enterprise-scale agile. Know that SAFe = Scrum at enterprise level with Lean + System Thinking. Crystal = color-coded by team size/criticality.

43. Agile Team Spaces, Osmotic Communication & Distributed Teams

Co-located Teams (Ideal Agile Setup)

All team members work together in the same location
Enables face-to-face interaction and real-time collaboration
Team should be within 33 feet (10 meters) of each other for osmotic communication
No physical barriers between team members
Sometimes "virtual co-location" through video tools is acceptable

Optimal Team Space Design

Low-Tech, High-Touch Environment:

Whiteboards and task boards everywhere
Sticky notes, flip charts, round tables
No barriers to face-to-face communication

Caves and Common:

Caves — Private spaces for individual focus work
Common — Open spaces for group collaboration

Osmotic Communication

Information flows naturally as part of everyday conversations and background listening — team members "absorb" knowledge without formal meetings.

Only works within 33 feet / 10 meters
Overhearing conversations, casual hallway exchanges, open office layout
One of the biggest BENEFITS of co-location
Impossible in distributed/remote teams — must compensate with other tools

Osmotic Communication is LOST in distributed teams. This is why agile strongly prefers co-location. When teams go remote, use video, IM, virtual whiteboards to replicate it.

Tacit Knowledge

Information that is NOT written down — lives in people's heads. Experience, intuition, judgment.

Supported through collective group knowledge and osmotic communication
Hard to capture in documents — must be shared through collaboration
Risk: lost when team members leave the project

Distributed Teams

At least one team member working off-site. Need strategies to replicate co-location benefits.

Challenges: Time zones, cultures, native languages, communication styles

Digital Tools for Distributed Teams:

📹 Video conferencing 🖥️ Interactive whiteboards 💬 IM / VoIP 📋 Virtual card walls (Kanban) 📷 Web cams

Global & Cultural Diversity Considerations

Time Zones — Overlap hours for meetings; async communication for off-hours
Cultures — Different attitudes toward hierarchy, conflict, directness
Native Languages — Clear, simple communication; avoid idioms
Communication Styles — High-context vs. low-context cultures differ greatly

Agile prefers co-location. Remote teams must DELIBERATELY compensate for lost osmotic communication. Face-to-face beats all other methods. Use video > phone > text.

44. Agile Conflict Levels & Participatory Decision Models

5 Levels of Conflict (Agile)

All projects will have conflicts. Some conflict is HEALTHY — drives better decisions. The goal is NOT zero conflict, but keeping it at productive levels.

Level	Name	Behavior	PM Action
1	Problem to Solve	Sharing information constructively	Facilitate discussion
2	Disagreement	Personal protection; cautious	Encourage dialogue
3	Contest	"Must win" mentality	Mediate actively
4	Crusade	Protecting one's group; coalition building	Escalate if needed
5	World War	Must destroy the other side	Escalate immediately; separate parties

Level 1-2 conflict = healthy and productive. Level 5 = must be immediately escalated and resolved before work can continue. PM should create a SAFE environment for Level 1-2 disagreement.

Participatory Decision Models

Engage ALL stakeholders in the decision-making process — builds buy-in and commitment.

Method	How It Works
Simple Voting	Vote "for" or "against." Majority wins. Simple and fast.
Thumbs Up/Down/Sideways	👍 Support \| 👎 Oppose \| 👉 Undecided/neutral. Quick visual poll.
Fist of Five	1 finger = Strong support. 2 = Support. 3 = Willing to go along. 4 = Reservations. 5 = Block/Oppose. Anything ≤ 3 = discuss further.
Dot Voting / Multi-voting	Each person gets N dots to place on options they prefer. Visual & democratic.
100-Point Method	Each person distributes 100 points across requirements based on priority.
Monopoly Money	Give equal "play money" — distribute to what you value most. Forces trade-offs.

Building Team Commitment

Welcome Constructive Disagreement — leads to better decisions and stronger buy-in
Avoiding conflicts causes them to ESCALATE (level 2 → 3 → 4)
A safe environment for disagreement leads to successful problem solving
Create experiments — allow team to try new methods without fear of punishment

Fist of Five: anything less than 3 fingers = discussion needed. Participatory models ensure team members commit to decisions rather than grudgingly complying. Increases team engagement.

45. Skill Mastery Models, Three C's of Stories & Agile Roles

Shu-Ha-Ri Model of Skill Mastery

A Japanese martial arts concept applied to learning agile (and any skill):

Stage	Japanese	Meaning	Agile Team Behavior
Shu	守 (Obey)	Follow the rules exactly	New team: follow Scrum rules strictly, no customization
Ha	破 (Break)	Consciously break the rules	Experienced team: adapt practices, try variations
Ri	離 (Transcend)	Find individual paths	Mastery: create own approach from principles

New agile teams should start at Shu — follow the framework strictly. Don't customize too early. Mastery comes from understanding WHY before changing WHAT.

Dreyfus Model of Adult Skill Acquisition

5 stages of skill development — applicable to team members learning new technologies or processes:

1. Novice — rule-based, needs guidance 2. Advanced Beginner — recognizes context 3. Competent — plans & prioritizes 4. Proficient — sees holistic picture 5. Expert — intuitive, transcends rules

Use this to calibrate training, coaching, and work assignment for each team member.

Three C's of User Stories

User stories are written on index cards — deliberately brief to spark conversation, not replace it.

C	Name	Meaning
Card	Card	Physical or digital card with brief story description. Minimal detail — just enough to trigger discussion.
Conversation	Conversation	Discussion between team and product owner to clarify details, assumptions, and constraints.
Confirmation	Confirmation	Acceptance criteria agreed upon — how we confirm the story is DONE.

The Card doesn't contain all details — it PROMPTS the Conversation. The Confirmation = acceptance criteria = Definition of Done for that story. All three C's are needed.

Agile Delivery Team Responsibilities

The Development/Delivery Team in Scrum:

Build product in increments
Update information radiators (burndown charts, Kanban boards)
Self-organize and self-direct — no command from PM
Share progress through daily stand-up meetings
Demo completed product increments at sprint review
Hold retrospectives at end of sprints
Do release and sprint planning AND estimation

Generalizing Specialists (T-Shaped Skills)

Ideal agile team members have:

Depth in one primary skill (the vertical bar of the T)
Breadth across multiple skills (the horizontal bar of the T)
Can fill in for teammates → reduces bottlenecks
Promotes knowledge sharing and reduces single points of failure

46. Timeboxing, Parkinson's Law & Value Stream Mapping

Timeboxing

Short, fixed-duration periods of time in which activities or work are undertaken. If work is NOT completed within the timebox, it moves to the NEXT timebox — the timebox does NOT extend.

Event	Timebox Duration
Daily Stand-up	15 minutes (maximum)
Sprint Retrospective	~2 hours
Sprint Review	Max 1 hour per week of sprint length
Sprint	1–4 weeks (fixed)
Sprint Planning	Max 8 hours for a 4-week sprint

Parkinson's Law

"Work tends to expand to fill the time given."

If you give someone 2 weeks for a 3-day task → it will take 2 weeks
Timeboxing COUNTERACTS Parkinson's Law by constraining available time
Fixed sprint length forces prioritization and focused execution

You tell a developer to fix a bug "whenever they get a chance." It never gets done. You instead put it in the sprint backlog with a 2-day estimate. It gets done in 2 days. Timeboxing works!

Parkinson's Law is the ENEMY of efficiency. Timeboxing is the SOLUTION. Sprints are fixed — no extension. Incomplete work rolls to the next sprint's backlog.

Value Stream Mapping (VSM)

A Lean tool to optimize the flow of information or materials through a process. Identifies and eliminates waste (waiting times, unnecessary steps).

Steps to Create a Value Stream Map:

Identify the product or service being delivered
Create a current-state value stream map (draw the actual process)
Review the map to find WASTE (delays, rework, handoffs)
Create a future-state map with desired improvements
Develop a roadmap to implement the improvements
Plan to revisit and improve again (continuous improvement)

Current State: Get course info (2 min) → Call (12 min wait) → Register (10 min) → Attend (20 min) → Get Certificate (44 min total)
Future State: Get info (2 min) → Call (5 min) → Register (5 min) → Attend → Get Certificate (15 min) — waste eliminated!

Value Stream Mapping = Lean tool used in BOTH traditional and agile contexts for continuous improvement. It's about reducing the total time from request to delivery by eliminating non-value-adding steps.

Agile Continuous Improvement (PDCA & Agile Cycle)

PDCA Cycle (Deming)

Plan → Do → Check → Act → (Repeat)
Foundation of continuous improvement in quality and process management.

Agile Cycle

Plan → Develop → Evaluate → Learn → (Repeat)
Each sprint is one PDCA cycle. Retrospectives close the learning loop.

47. Complete Value Prioritization Techniques & MVP

Why Prioritize?

Value-based prioritization is one of the core practices in agile planning. Features are prioritized by business value, risk, and dependencies. The end result must always be a prioritized list — regardless of which technique is used.

All Prioritization Techniques

Technique	How It Works	Pros/Cons
Simple Scheme	Priority 1, 2, 3… Many items become P1. Easy to understand.	Simple but problematic — everything becomes urgent
MoSCoW	Must Have / Should Have / Could Have / Won't Have (this time)	Clear categories; widely used; easy stakeholder discussion
Monopoly Money	Give each stakeholder equal play money to distribute to features	Forces real trade-offs; fun; reveals true priorities
100-Point Method	Each person gets 100 points to distribute across requirements	Quantifiable; forces trade-offs; democratic
Dot Voting / Multi-voting	Each person places N dots on options they value most	Visual, fast, collaborative; good for workshops
Kano Analysis	Categorizes features by type of customer satisfaction they deliver	Reveals hidden value; requires customer research
Requirements Prioritization Model	Weighs value vs. cost vs. risk for each feature	More rigorous; data-driven

Kano Analysis — Deep Dive

Helps understand customer satisfaction relative to product features. Four categories:

Category	Description	Example
Delighters / Exciters	Unexpected features that create delight. High satisfaction when present. No dissatisfaction when absent (customer didn't expect them).	Apple's fingerprint sensor when first released
Satisfiers (Linear)	More = more satisfied. Less = less satisfied. Linear relationship.	Faster car, more storage space, better camera
Dissatisfiers (Must-Be)	Expected basics. Absence causes high dissatisfaction. Presence creates no excitement — it's just expected.	A car must start. App must not crash. Hotel must have clean towels.
Indifferent	Customer doesn't care either way. No impact on satisfaction.	Color of internal cables in a server

Kano key insight: Delighters today become Satisfiers tomorrow and Dissatisfiers eventually. Today's wow = tomorrow's expectation. Continuously find new Delighters!

Minimum Viable Product (MVP)

A set of functionality that is complete enough to be useful, but small enough to not be a full project.

Usually one module or core capability of a larger product
Released to gather real customer feedback before building more
Reduces risk of building the wrong thing
Core agile principle: deliver value early, learn, and iterate

Instead of building a full e-commerce platform in 18 months, the team releases an MVP with just product listing + checkout in 2 months. Real users test it → feedback drives next sprint priorities.

Product Roadmap

A high-level visual timeline showing when features will be delivered and what is included in each release.

Converts the story map / backlog into a delivery timeline
Shows releases across time — Release 1, Release 2, etc.
Managed and updated by the Product Owner
Subject to change as priorities shift and feedback comes in
NOT a fixed commitment — it's a plan that evolves

MVP ≠ low quality. MVP = smallest VALUABLE increment. The goal is learning with minimum investment. Product Roadmap = the "when" of feature delivery across multiple releases/sprints.

48. ESVP & Deep Retrospective Activities

ESVP — Retrospective Check-In Activity

Used in the Set the Stage phase of retrospectives. Team members anonymously identify their attitude/engagement level:

Letter	Name	Attitude	PM Action
E	Explorer	Excited to discover new ideas. Eager to learn and improve.	Leverage their energy; give them tasks
S	Shopper	Looking for useful items. Will adopt what makes sense.	Good — let them evaluate options
V	Vacationer	Just happy to be away from regular work. Not fully engaged.	Gradually pull them in; find their interest
P	Prisoner	Forced to attend. Would rather be elsewhere. Resistant.	Address privately; find root cause of resistance

Results are tallied anonymously. Many Prisoners = retrospective itself needs improvement!

ESVP helps the facilitator calibrate the retrospective before it begins. Many Vacationers/Prisoners = team not finding value in retros → change the format! Many Explorers = great session ahead.

Gather Data Activities (Retrospective Phase 2)

Activity	Description
Timeline	Team builds a visual timeline of sprint events — what happened and when. Captures facts and feelings over time.
Triple Nickels	Break team into 5 groups. Each group spends 5 minutes writing 5 ideas. Rotate papers 5 times. Generates many ideas quickly.
Mad, Sad, Glad	Team members share: What made you MAD (frustrated)? SAD (disappointed)? GLAD (happy)? Captures emotional data from the sprint.
Start/Stop/Continue	What should we START doing? STOP doing? CONTINUE doing? Simple and effective for action planning.

Generate Insights Activities (Retrospective Phase 3)

Activity	Description
Five Whys	Ask "Why?" 5 times to drill down to the root cause. E.g., "Why were we late? → Wrong estimate → Why? → No historical data → Why? → We don't track velocity → Why? → No tool…"
Fishbone / Ishikawa	Cause-and-effect diagram. Categories (People, Process, Tools, Environment) show contributing causes of a problem.
Dot Voting / Prioritize with Dots	After brainstorming, each person places dots on the issues they feel are most critical. Most dots = address first.

Decide What to Do Activities (Retrospective Phase 4)

Activity	Description
Short Subjects	Team decides: Start doing / Stop doing / Do more of / Do less of. Generates specific, actionable commitments for next sprint.
SMART Goals	Each improvement action is: Specific, Measurable, Attainable, Relevant, Timely. Vague goals → no change.

Retrospective vs Sprint Review — Must Know Difference!

Sprint Review

Who: Team + stakeholders/customers
What: Demo of completed work
Goal: Inspect the PRODUCT increment; gather external feedback
Output: Updated product backlog

Sprint Retrospective

Who: Scrum team only (internal)
What: Discuss what went well/wrong
Goal: Improve the PROCESS/teamwork
Output: Improvement plan for next sprint

Review = about the PRODUCT (external). Retrospective = about the PROCESS/TEAM (internal). Both happen at end of sprint. Review happens BEFORE retrospective.

49. PMIS & Communication Models

Project Management Information System (PMIS)

An automated system used by the PM to support all aspects of the project throughout its lifecycle. Appears as a tool in MANY processes across the 49 processes.

Functions of PMIS:

Scheduling software (Microsoft Project, Primavera P6)
Resource management tools
Configuration management systems
Collecting and distributing information
Interface to other automated systems (accounting, procurement)
Work authorization systems
Reporting and dashboard tools

PMIS appears as a tool in: Develop Schedule, Control Schedule, Control Costs, Monitor Communications, Control Resources, Manage Team, Direct & Manage Work. Know it = automated project management software.

Communication Model (Sender-Receiver)

The basic communication model — critical for effective project communications:

Element	Description
Sender	Person initiating the message. Responsible for encoding the message clearly.
Encode	Translating thoughts into symbols, language, or gestures that can be transmitted
Message	The actual content being communicated
Medium/Channel	How the message travels (email, phone, meeting, written report)
Noise	Anything that interferes with or distorts the message (language barriers, distractions, assumptions, cultural differences)
Decode	Receiver interprets the symbols back into meaning
Receiver	Person who receives the message. Must acknowledge understanding.
Feedback/Acknowledgment	Receiver confirms understanding — completes the communication loop

The SENDER is responsible for ensuring the message is understood. Noise = any interference. Active Listening = the receiver confirms understanding and asks clarifying questions. Communication is INCOMPLETE without feedback!

Communication Technology Factors

When selecting communication technology, consider:

Urgency — How quickly is the information needed?
Availability — What tools are available to all parties?
Ease of use — Are stakeholders comfortable with the technology?
Project environment — Collocated vs. virtual? Sensitive information?
Sensitivity — Is the information confidential?

Communication Skills — Active Listening

Active Listening: Understanding, acknowledging, and clarifying what others are saying to you.

Focus fully on the speaker — no distractions
Paraphrase to confirm understanding ("So what you're saying is…")
Ask clarifying questions
Watch non-verbal cues
Avoid interrupting
Most important interpersonal skill for a PM

Communicating with Agile Stakeholders

Method	Description
Face-to-face	BEST. Two-way, richest communication. Body language visible. Preferred by agile.
Information Radiators	Highly visible displays of project information (burndown, Kanban). Passive pull communication.
Social Media	Twitter, Instagram — quick updates to broad audience. Not for sensitive information.
Two-way communication	Don't just send — actively listen and incorporate feedback.
Knowledge sharing	Pair programming, whiteboard sessions, osmotic communication, shared tools.

50. Control Procurements, Claims Administration & Close Contracts

MONITORING & CONTROLLING

Control Procurements

Managing procurement relationships; monitoring contract performance and making corrections; closing out contracts.

Key activities:

Review and approve seller invoices against work performed
Inspect seller work to verify compliance with contract terms
Manage changes to the contract through change control
Resolve disputes and claims between buyer and seller
Formally close completed contracts

Control Procurements — Key Tools

Tool	Description
Inspections	Physical review of seller's work product to verify it meets contract specifications
Audits	Structured review of the procurement process for compliance and lessons learned
Claims Administration	Handling disputed changes between buyer and seller that cannot be agreed upon
Performance Reviews	Structured review of seller's progress against schedule, cost, and quality requirements
Data Analysis	Earned value analysis applied to procurement contracts; trend analysis

Claims Administration — CRITICAL TOPIC

Claims (also called disputes or constructive changes) arise when the buyer and seller CANNOT reach agreement on a change or compensation for a change.

Examples of claims:

Seller claims the buyer changed the scope without a formal change order
Buyer claims seller's work is defective and demands cost reduction
Disagreement over who caused a delay and who owes compensation

Resolution Order (preferred to least preferred):

Negotiation — Both parties discuss and reach agreement. PREFERRED method. Fastest, cheapest.
Mediation — Neutral third party helps parties negotiate. Non-binding.
Arbitration — Neutral third party makes binding decision. Like a private court.
Litigation — Court system. Slowest, most expensive. Last resort.

ALWAYS try negotiation FIRST for claims. Litigation is ALWAYS the last resort. The contract should specify the claims resolution process. Claims = disputed changes = must be documented even if unresolved at contract close.

Close Procurements (within Close Project)

In PMBOK 6, closing contracts is part of the Close Project or Phase process:

Buyer provides seller with formal written notice that the contract is complete
Must go through the authorized procurement administrator (not just the PM)
All open claims must be resolved before formal closure
All contract documentation archived for future reference
Lessons learned from procurement documented

Output: Closed Procurements — official record that contract obligations have been met

Seller Performance Records

Documentation of seller performance becomes part of OPA for future procurement decisions:

Quality of work delivered
On-time and on-budget performance
Responsiveness to issues
Claims history
Used for pre-qualification lists in future projects

Contract Breach vs. Constructive Change

Term	Definition	Example
Contract Breach	One party fails to meet contract obligations	Seller delivers late; buyer doesn't pay
Constructive Change	Buyer's actions (or inactions) effectively change the contract without formal change order	Buyer gives vague instructions that cause seller to redo work
Force Majeure	Unforeseeable event beyond both parties' control	Hurricane destroys construction site; neither party at fault

Complete Procurement Flow:
Plan Procurement (Planning) → Conduct Procurements (Executing) → Control Procurements (M&C) → Close Procurements (within Close Project)

Dispute Resolution Order: Negotiation → Mediation → Arbitration → Litigation
Claims must be: Documented in writing, submitted per contract process, adjudicated if unresolved
Contract closure: Written notice from buyer to seller. Must be from procurement administrator.

51. Advanced Risk Tools — SWOT, Prompt Lists, Contingent Response & Risk Breakdown

SWOT Analysis (Identify Risks Tool)

Used during Identify Risks to look at the project from all four angles to find risks:

Strengths (Internal +)	Weaknesses (Internal −)
Expert team, management support, proven technology, adequate budget	Limited free time, high cost structure, skill gaps, high team turnover
Opportunities (External +)	Threats (External −)
New market, new IT systems, partnership potential, regulatory change	Regulations, staff shortage, competitor actions, economic shifts

Strengths/Weaknesses = internal. Opportunities/Threats = external. Use all four quadrants to generate both positive risks (opportunities) and negative risks (threats).

SWOT = used in IDENTIFY RISKS, not just planning. It systematically surfaces both threats AND opportunities. Don't forget — positive risks are opportunities you want to exploit or enhance!

Prompt Lists (PESTLE, TECOP, VUCA)

Predetermined lists of risk categories used to prompt brainstorming during Identify Risks. The most common:

Acronym	Categories
PESTLE	Political, Economic, Social, Technological, Legal, Environmental
TECOP	Technical, Environmental, Commercial, Operational, Political
VUCA	Volatility, Uncertainty, Complexity, Ambiguity — describes the risk environment, not just categories

How to use: Go through each category and ask "What risks could arise from this area?"

PESTLE is the most tested prompt list. Use it to ensure you haven't missed a whole risk category. VUCA describes the project environment — high VUCA = use more adaptive approach.

Contingent Response Strategies

Risk responses that are triggered only when a specific event occurs. Sometimes called fallback plans.

Only activated if a predefined trigger condition is met
Example: "If the concrete supplier delays by more than 5 days, activate the alternate supplier agreement"
The trigger event must be clearly defined upfront
Also called risk triggers or warning signs

A software project has a risk that a key developer might leave. The contingent response: "If the developer gives notice, immediately begin recruitment and assign knowledge transfer for 2 weeks." The trigger = notice given.

Individual Risk vs. Overall Project Risk

Individual Project Risk

An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. These are listed in the Risk Register.

Analyzed using Qualitative and Quantitative analysis.

Overall Project Risk

The total risk exposure of the project as a whole. Sum of all individual risks plus other sources of uncertainty. Captured in the Risk Report (not Register).

Overall strategies: Avoid, Exploit, Transfer/Share, Mitigate/Enhance, Accept.

Risk Register = Individual risks. Risk Report = Overall project risk + summary of individual risks. Both are outputs of Identify Risks and updated throughout risk processes.

Risk Breakdown Structure (RBS)

A hierarchical chart that organizes risks by category. Used to ensure comprehensive risk identification.

Example RBS Categories:

⚠️ External (Vendors, Regulation, Market) 🏢 Organizational (Funding, Resources, Priorities) 👥 People (Skills, Availability, Culture) ⚙️ Technical (Technology, Interfaces, Performance)

Each top-level category breaks down into specific sub-risks. Helps ensure no major risk area is overlooked.

Risk Attitude Terms

Term	Definition	Example Behavior
Risk Appetite	Degree of uncertainty an org is willing to accept in pursuit of value	"We're willing to accept up to $50K of additional cost risk for this project"
Risk Tolerance	Specific range of acceptable risk — how much deviation is OK	"Schedule can slip up to 2 weeks without escalation"
Risk Threshold	The point at which a risk becomes unacceptable — must act	"Any cost overrun above 15% triggers executive review"

Appetite → broad organizational attitude. Tolerance → acceptable range. Threshold → the line that triggers action. Know all three — the exam distinguishes between them!

52. Critical Chain Method, Resource Optimization & Rolling Wave Planning

Critical Chain Method (CCM)

An alternative to Critical Path Method that puts more emphasis on resources required to execute project tasks. Developed by Eliyahu Goldratt.

Key differences from CPM:

CPM ignores resource constraints when calculating the critical path
CCM accounts for resource limitations and availability
CCM removes individual task buffers and adds project buffers at the end
Uses Feeding Buffers where non-critical chains feed into the critical chain
Protects the project end date using buffers instead of task padding

In CPM, each activity has 20% padding for safety. In CCM, you remove all that padding from activities and put a single 10% buffer at the project end. Total duration actually shrinks — and the buffer is visible and managed.

Critical Chain vs Critical Path: CPM = resource-unconstrained longest path. CCM = resource-constrained longest path + uses buffers instead of individual task safety margins. CCM is better at managing resource conflicts.

Resource Optimization Techniques

Resource Leveling

Adjusts start and finish dates to ensure resource demand never exceeds resource availability. Resources are used at a constant, sustainable level.

Can extend the project schedule
May delay the project end date
Addresses resource over-allocation
Often used after CPM when schedule is resource-constrained

Resource Smoothing

Adjusts activities within their float/slack to reduce resource peaks. Resources stay within limits without extending the project duration.

Does NOT change the project end date
Uses available float (slack) to shift activities
May not fully resolve all resource conflicts
Less disruptive than resource leveling

Leveling = may extend duration. Smoothing = does NOT extend duration (uses float). If asked to optimize resources WITHOUT delaying → Smoothing. If duration extension is acceptable → Leveling.

Rolling Wave Planning

A form of progressive elaboration where near-term work is planned in detail and future work is planned at a higher level. The plan "rolls" forward as time passes.

Used when future details are not yet known
Near-term sprints: fully detailed
Future phases: high-level milestones and rough estimates
Plan is updated as more information becomes available

A construction PM knows exactly what happens in Month 1 (site preparation, permits). Months 6-12 (interior finishes) are planned at high level. As Month 6 approaches, detailed planning begins — "rolling" the wave forward.

Rolling Wave = progressive elaboration of the schedule. It's an output of Define Activities (via Decomposition). Used when you can't plan everything in detail at the start. Agile teams use this every sprint.

Agile Release Planning

A technique used in Develop Schedule for agile projects. Provides a high-level summary of the release schedule based on the product roadmap and the team's velocity.

Determines how many sprints are needed to complete features in the product backlog
Based on: Backlog size (total story points) ÷ Average velocity (points/sprint)
Gives stakeholders a roadmap of WHEN features will be available
Subject to change as velocity is measured and priorities shift

Number of Sprints = Total Story Points / Average Velocity
Example: 300 story points / 20 velocity = 15 sprints = ~7.5 months (2-week sprints)

53. Cost Baseline, S-Curve, Funding Requirements & Cost Aggregation

How the Cost Baseline Is Built (Bottom-Up)

The cost baseline is built by aggregating (summing) costs upward through the WBS hierarchy:

Activity Cost Estimates
→ aggregated to → Work Package Costs
→ aggregated to → Control Account Costs
→ aggregated to → Project Cost Estimate
+ Contingency Reserves
= COST BASELINE

Cost Baseline + Management Reserves = PROJECT BUDGET (BAC)

Cost Baseline Displayed as S-Curve

The cost baseline is displayed as a cumulative cost curve over time — it looks like an "S" because:

Slow start — initial planning and mobilization phases have lower spending
Steep middle — peak execution; most resources deployed; highest spending
Flatten at end — closeout activities; fewer resources; spending tapers off

The S-curve shows the Planned Value (PV) at any point in time. EVM compares actual performance against this curve.

When asked to identify the cost baseline in EVM: Cost Baseline = PV cumulative curve = the S-Curve. Points above the S-curve (higher AC than PV) = OVER budget or ahead of schedule.

Project Funding Requirements

Output of Determine Budget. Documents WHEN and HOW MUCH funding is needed during the project.

May be tied to milestones, phases, or calendar periods
Includes both the cost baseline AND management reserves
Helps the organization plan cash flow and budget releases

A $10M project may receive funding in tranches: $2M at project start, $4M at design completion, $3M at construction start, $1M at final closeout. These are the Project Funding Requirements.

Funding Limit Reconciliation

A tool used in Determine Budget when the organization cannot release all funds at once.

Compares planned spending against the org's funding limits (when money can be released)
If planned spending exceeds funding limit in a period → adjust schedule (delay work) to smooth the expenditure profile
May require rescheduling activities to match available funding

Funding Limit Reconciliation = when your spending plan doesn't match when money is available. Fix = adjust the schedule (delay or accelerate work) to match funding availability.

Cost Aggregation

The primary tool in Determine Budget. Summing up cost estimates for individual activities/work packages to establish a total project cost baseline.

Work package costs roll up to control accounts
Control accounts roll up to the total project
The sum represents the undiscounted project cost (before contingency and management reserves)

Types of Cost — Must Know Distinctions

Type	Definition	Example
Direct Costs	Costs attributed directly to one project	Project team salaries, project-specific equipment
Indirect Costs	Shared overhead costs allocated across multiple projects	Office rent, utilities, admin support
Variable Costs	Change with the amount of work done	Materials, fuel, hourly labor
Fixed Costs	Do not change regardless of work volume	Equipment purchase, software license
Sunk Costs	Money already spent — CANNOT be recovered	Research already done before project cancel decision
Opportunity Cost	Value of the NEXT best alternative foregone	Choosing Project A over Project B = Project B value is the opportunity cost

SUNK COSTS should NOT factor into project continuation decisions. You cannot recover them. Opportunity cost is relevant when SELECTING between projects — always pick the higher NPV/BCR project.

54. Configuration Management Plan, Change Management Plan & Performance Measurement Baseline

Project Management Plan — The 4 Baselines

The PM Plan contains 4 baselines that serve as the benchmark for project performance:

Baseline	Created In	What It Measures
Scope Baseline	Create WBS	Approved scope statement + WBS + WBS Dictionary
Schedule Baseline	Develop Schedule	Approved project schedule with start/end dates
Cost Baseline	Determine Budget	Approved time-phased budget (S-curve)
Performance Measurement Baseline (PMB)	Develop PM Plan	Integration of Scope + Schedule + Cost baselines for EVM

PMB = the integrated baseline used for EVM calculations. It combines scope, schedule, and cost into one measurement framework. Changes to PMB require formal change control.

Performance Measurement Baseline (PMB)

The integration of the scope, schedule, and cost baselines. Used as the reference for measuring project performance using EVM.

Allows calculation of PV (Planned Value) at any point in time
Compared against EV and AC to compute CPI, SPI, CV, SV
Can only be changed through formal change control
When a change is approved — PMB is RE-BASELINED

Configuration Management Plan

Describes how configuration management will be applied on the project. Configuration management ensures that project documents and deliverables are:

Identified — every document/item has a unique identifier
Controlled — changes are tracked through a formal process
Tracked — audit trail of all changes and their impacts
Verified & Audited — confirm conformance to requirements

Configuration Item: Any project deliverable, document, or component subject to version control (code, plans, specifications, hardware).

In a software project, the configuration management plan ensures that version 2.3.1 of a module is tracked separately from version 2.3.2, and any change requires a formal change request and testing cycle.

Configuration Management is about VERSION CONTROL and CHANGE TRACKING for project deliverables and documents. Not the same as change control (which is about project decisions). Often a component of IT and engineering projects.

Change Management Plan

Describes how changes will be managed throughout the project. Part of the PM Plan, created during Develop Project Management Plan.

Defines the change request process (who submits, who reviews, who approves)
Defines the Change Control Board (CCB) composition and authority
Specifies what types of changes require CCB approval vs. PM approval
Documents how approved changes are communicated and implemented
Defines escalation path for urgent changes

Team Charter

Output of Plan Resource Management. Documents acceptable behavior, working norms, and expectations for project team members.

Contents of a Team Charter:

Team values and ground rules
Communication guidelines (how, when, what tools)
Decision-making processes
Conflict resolution approach
Meeting protocols (frequency, attendance expectations)
Work hours and availability expectations

Team Charter ≠ Project Charter. Team Charter = how the TEAM will work together (norms). Project Charter = formal project authorization document signed by sponsor. Know both!

The 18 Components of the PM Plan

14 Subsidiary Plans: Scope Mgmt Plan, Requirements Mgmt Plan, Schedule Mgmt Plan, Cost Mgmt Plan, Quality Mgmt Plan, Resource Mgmt Plan, Communications Mgmt Plan, Risk Mgmt Plan, Procurement Mgmt Plan, Stakeholder Mgmt Plan, Change Mgmt Plan, Configuration Mgmt Plan, Project Life Cycle Description, Development Approach

4 Baselines: Scope Baseline, Schedule Baseline, Cost Baseline, Performance Measurement Baseline

PM Plan = 14 plans + 4 baselines = 18 components. The PM Plan is the MASTER document. All changes to it require formal change control and CCB approval.

55. 12 Principles for Leading Agile Projects & Leadership Tools

12 Principles for Leading Agile Projects (Pinto)

From Jeffery Pinto, Project Leadership from Theory to Practice (2002). These are PM-focused leadership principles for agile environments:

Learn the team members' needs
Learn the project requirements
Act for the simultaneous welfare of the team AND the project
Create an environment of functional accountability
Have a vision of the completed project
Use the project vision to drive your own behavior

Serve as the central figure in project team development
Recognize team conflict as a positive step
Manage with an eye toward ethics
Remember: ethics is integral, not an afterthought
Take time to reflect on the project
Develop the trick of thinking backwards (start with end in mind)

Key principle #8: Recognize conflict as a POSITIVE step — consistent with Agile's view that healthy conflict drives innovation. Key #12: "Thinking backwards" = begin with the end goal, work backwards to plan.

Leadership Tools & Techniques for Agile PMs

Agile PMs use these tools — but always with a soft-skills approach:

Tool	Description
Modeling Desired Behavior	Lead by example in 4 areas: Honesty, Forward-Looking, Competent, Inspiring
Communicating Project Vision	Consistently re-communicate WHY the project matters to keep team motivated
Enabling Others to Act	Switch from exclusive tools (PM-only decisions) to inclusive tools (team decisions). Empower the team.
Being Willing to Change Status Quo	Challenge existing processes and norms if they don't serve the project well

Leadership Tasks for Agile PMs

Practice Transparency through Visualization — Information radiators, burndown charts, open workspaces
Create a safe environment for experimentation — No punishment for trying new approaches
Experiment with new techniques and processes — Retrospectives are the vehicle for this
Share knowledge through collaboration — Pair programming, workshops, osmotic communication

Methods of Stakeholder Engagement in Agile

Agile stakeholder engagement is ongoing and proactive:

Method	Purpose
Get the right stakeholders	Ensure decision-makers are engaged, not just observers
Cement stakeholder involvement	Make participation a contractual or organizational expectation
Actively manage stakeholder interest	Monitor engagement level; intervene when disengagement occurs
Frequently discuss definition of "done"	Shared clarity on acceptance criteria prevents late surprises
Show progress and capabilities	Sprint reviews, demos, burndown charts keep stakeholders informed
Candidly discuss estimates and projections	Honest forecasting builds trust even when news is bad

Agile PM leadership style = Servant Leader + Coach + Facilitator. NOT a commander or controller. The Scrum Master's primary job is removing impediments, not assigning tasks. The team assigns their own work.

Educating People About Agile — Overcoming Resistance

Stakeholder	Common Concern	PM Response
Senior Management / Sponsor	Fear of failure; loss of predictability	Show incremental delivery, early ROI, risk mitigation via short cycles
Functional Managers	Fear of losing control of their people	Show collaboration model; they gain visibility through sprint reviews
Project Team	Resistance to new agile methods	Training, gradual adoption, safe experimentation, Shu-Ha-Ri approach
End Users / Customers	Worry they won't get all features	MoSCoW prioritization; MVP shows value early; they guide priorities

56. Exam Strategy, Test-Taking Tips & Final Review

PMP Exam Format

Item	Detail
Total Questions	180 questions
Time Allowed	230 minutes (~3 hours 50 min)
Question Types	Multiple choice, drag-and-drop, matching, hotspot, fill-in-blank
Domain Split	~50% Predictive (Waterfall/PMBOK 6) + ~50% Agile/Hybrid
Domains Tested	People (42%), Process (50%), Business Environment (8%)
Breaks	2 optional 10-min breaks (after Q60 and Q120)
Passing Score	Not publicly stated — PMI uses "above target/target/below target" per domain

3 PMP Exam Domains

Domain	%	Key Focus
People	42%	Leadership, stakeholder engagement, team building, conflict management, EQ
Process	50%	All 49 processes, ITTOs, EVM, risk, scheduling, quality, procurement
Business Environment	8%	Strategic alignment, governance, compliance, benefits realization, organizational change

Exam-Taking Strategy

Read the LAST sentence first — Questions often have long scenarios. The last sentence is the actual question.
Eliminate obviously wrong answers — Usually 2 answers are clearly wrong; choose from the remaining 2.
Look for "PM best practice" clues — Answers that follow the PM plan, consult the team, and use formal change control are almost always correct.
Beware of "real world" thinking — The PMP exam tests PMI's ideal world. "I'd just talk to the PM" ≠ correct. "Submit a written change request" = correct.
Agile questions — Look for servant leader behavior, team empowerment, customer collaboration, continuous feedback.
Situational questions — "What should the PM do FIRST?" → Assess, analyze, then act. Never jump straight to action.

The 10 Golden Rules for PMP Exam Answers

1. ALWAYS follow the PM Plan — Don't deviate without a change request
2. ALWAYS identify/analyze before acting — Assess the situation first
3. ALWAYS use formal change control — Even for "small" changes
4. ALWAYS consult the project team — They have the most practical knowledge
5. ALWAYS document everything — Lessons learned, change log, issue log
6. NEVER skip planning — Even urgent situations need some planning
7. NEVER work around the sponsor — Escalate through proper channels
8. NEVER accept gold plating — Extra features = scope change = change request
9. NEVER prioritize the agile backlog yourself — That's the Product Owner's job
10. NEVER punish people who report problems — Create a safe, open culture

Most Common Traps & How to Avoid Them

Trap	Wrong Answer Pattern	Correct Approach
Scope Change	"Just do it — it's a small change"	Always submit a formal change request
Schedule Pressure	"Ask team to work overtime"	Assess impact, crash or fast-track with change request if needed
Team Conflict	"Separate the parties" / "Tell the sponsor"	Problem solve / confront directly; understand root cause first
Stakeholder Unhappy	"Ignore them" / "Escalate immediately"	Engage them; analyze their concern; update stakeholder register
Risk Occurs	"Deal with it now from scratch"	Execute the pre-planned risk response from the risk register
Project Behind Schedule	"Add more resources" (always)	Analyze root cause → consider fast-tracking, then crashing, then change request
Customer Requests Change	"Do it — customer is king"	Document the request; submit change request; analyze impact; CCB approves

Key Number Facts for the Exam

Fact	Number
Process Groups	5
Total Processes (PMBOK 6)	49
Knowledge Areas	10
PMBOK 7 Principles	12
PMBOK 7 Performance Domains	8
Agile Manifesto Values	4
Agile Guiding Principles	12
Stakeholder Engagement Levels	5 (Unaware→Leading)
Tuckman Stages	5 (Forming→Adjourning)
Conflict Resolution Methods	5 (Problem Solving = best)
PMO Types	3 (Supportive, Controlling, Directive)
Org Structure Types	5 (Functional→Projectized)
Contract Types (main)	3 (Fixed Price, Cost Reimb., T&M)
Risk Response Strategies (threats)	5 (Escalate, Avoid, Transfer, Mitigate, Accept)
Daily Standup Duration	15 minutes
Sprint Length	1–4 weeks
Osmotic Communication Distance	33 feet / 10 meters
PM Plan Components	18 (14 plans + 4 baselines)
Processes in Planning PG	24 (most of any group)
Processes in Closing PG	1 (fewest)

Final Day Reminders

The PMP exam tests JUDGMENT, not memorization. For every question, ask: "What would a professional, ethical, PMI-certified project manager do in this situation?" Then pick the most proactive, collaborative, process-following answer.

Last-minute review priority order:
1. EVM formulas (Section 26 & 38)
2. Process Groups & Knowledge Areas map (Section 4)
3. Risk response strategies — threat vs. opportunity (Section 14)
4. Conflict resolution — Problem Solving first (Section 12)
5. Contract types — who bears risk (Section 37)
6. Agile Scrum terms & roles (Section 31)
7. ADKAR, Kotter, Tuckman models (Sections 35, 36)
8. Stakeholder engagement levels (Section 16)
9. Change control process (Section 24)
10. PM Mindset golden rules (Section 39 & this section)

57. Four Life Cycle Types, Leadership vs. Management & Agile Benefits

Four Project Life Cycle Types

Life Cycle	Requirements	Activities	Delivery	Goal
Predictive	Fixed early	Sequential, one pass	Single, at end	Manage cost & schedule
Iterative	Dynamic	Repeated until correct	Single, at end	Correctness of solution
Incremental	Dynamic	One pass per increment	Frequent smaller deliveries	Speed / frequency
Agile	Dynamic	Repeated until correct	Frequent smaller deliveries	Customer value via frequent delivery & feedback

Key insight: Agile leverages BOTH iterative AND incremental approaches simultaneously.

Agile = Iterative + Incremental. Iterative alone = repeat work until right but deliver once. Incremental alone = deliver in pieces but each piece is built once. Agile = repeat AND deliver frequently.

Leadership vs. Management — Key Distinctions

🌟 Leadership

About people and vision
Inspires and motivates
Focuses on doing the right things
Creates followers willingly
Challenges the status quo
Long-term, strategic focus
Uses influence and vision
Deals with change

⚙️ Management

About systems and processes
Plans, organizes, coordinates
Focuses on doing things right
Directs through authority
Maintains the status quo
Short-term, operational focus
Uses formal power and control
Deals with complexity

PMs need BOTH leadership AND management skills. The PMP exam increasingly tests leadership behaviors over pure management mechanics. When in doubt — pick the leadership-focused answer.

Phases & Deliverables

Phase: A collection of logically related project activities that culminates in the completion of one or more deliverables
Number of phases depends on: industry type, project size, and complexity
Deliverable: Any unique and verifiable product, service, or result — tangible or intangible
Each deliverable must be accepted by the customer/sponsor at phase end
Phase Gate (Kill Point/Stage Gate): Review at end of each phase to decide: Continue → next phase, Redirect → change course, or Stop → terminate project

Phase Gate = Go/No-Go decision point. Sponsor/steering committee makes the call. Each phase end = formal review of deliverables. Project can be terminated at any phase gate.

Agile Benefits Summary

Customer involved throughout the entire life cycle (not just start and end)
Greater customer interaction with all stakeholders
Constant feedback is required to stay current and successful
Greater value delivered up front (early sprints deliver working product)
Change is welcomed by all stakeholders — not feared

Agile Concurrent Development Principles

Fund incrementally — opt to extend, redirect, or cancel at a very granular level
Deliver and realize value steadily — each sprint has business value
Validate designs with users and customers — sprint reviews provide this
Continuously adapt to risk and change — retrospectives drive this
Integrate early and often — continuous integration prevents late surprises

Business Documents (Inputs to Develop Project Charter)

📋 Business Case

Justifies the investment in the project. Answers: WHY should we do this?

Business need or problem being solved
Cost-benefit analysis
Feasibility assessment
Alternative options considered
Recommended approach

Created BEFORE the project charter. Owned by the sponsor.

📈 Benefits Management Plan

Describes how and when the project's benefits will be delivered and measured.

Target benefits (financial and non-financial)
Timeline for benefits realization
Metrics to measure benefits
Assumptions and risks to benefits
Who is responsible for benefits realization

Benefits may be realized after the project closes — operations phase.

Business Case = WHY (justification). Benefits Management Plan = HOW and WHEN benefits will be measured. Both are inputs to Develop Project Charter. The PM does NOT own the business case — the SPONSOR does.

58. PMI Talent Triangle

PMI Talent Triangle (Updated 2022)

PMI defines three skill areas every PM must continuously develop. Updated in 2022 to reflect modern PM needs:

Skill Area	Old Name	What It Covers
Ways of Working	Technical PM	Predictive, agile, hybrid methods; schedule/cost/scope management; risk; tools like MS Project, JIRA, Primavera
Power Skills	Leadership	Communication, collaboration, problem-solving, stakeholder engagement, EQ, conflict management, negotiation, motivation
Business Acumen	Strategic & Business Management	Understanding business strategy, finances, industry trends, organizational context, benefits realization, market awareness

PDUs (Professional Development Units) earned for PMP renewal must be spread across all three areas.

The Talent Triangle reflects that PMs need MORE than just process knowledge. Power Skills = what most PMs lack and what the new exam tests heavily. Business Acumen = understanding the strategic "why" behind every project decision.

Talent Triangle in Practice

Skill Area	Exam Question Type	Example Behavior
Ways of Working	Which process/tool/technique to use?	Choosing between crashing vs. fast-tracking; selecting the right contract type; applying EVM
Power Skills	How should the PM handle this situation?	Resolving team conflict; engaging a resistant stakeholder; communicating bad news to sponsor
Business Acumen	What is best for the organization?	Recommending project termination when BCR drops; aligning project to strategic goals; benefits realization tracking

Project Expeditor vs. Project Coordinator

Project Expeditor

Works in a Functional Organization. Has almost NO authority. Acts purely as a communication coordinator and progress checker. Cannot make decisions. Essentially a staff assistant to the functional manager.

Closest to: a glorified note-taker with no power.

Project Coordinator

Works in a Weak Matrix organization. Has some authority — slightly more than Expeditor. Can make some minor decisions. Reports to a higher-level manager but has limited formal power over the project.

Closer to: a junior PM with a narrow scope of authority.

Expeditor = ZERO decision power (Functional org). Coordinator = SOME decision power (Weak Matrix). Full PM = meaningful authority (Balanced Matrix → Projectized). The stronger the matrix, the more PM authority.

59. Project Selection Methods — NPV, BCR, IRR & Payback Period

Project selection questions appear on EVERY PMP exam. These are straightforward IF you know the rules. Higher NPV/BCR/IRR = better. Shorter payback = better.

Net Present Value (NPV)

The present value of future cash flows minus the initial investment. Accounts for the time value of money.

NPV = Present Value of Benefits − Present Value of Costs

Decision Rules:
NPV > 0 → Project ADDS value → ACCEPT
NPV = 0 → Project breaks even
NPV < 0 → Project DESTROYS value → REJECT

If comparing projects: Choose the one with the HIGHER NPV

Project A: NPV = $250,000 | Project B: NPV = $180,000 → Choose Project A (higher NPV = more value created)

NPV is the BEST project selection method — accounts for time value of money AND total profitability. If only one number to use → use NPV.

Benefit-Cost Ratio (BCR)

BCR = Total Benefits / Total Costs

BCR > 1 → Benefits exceed costs → ACCEPT (worthwhile)
BCR = 1 → Break even
BCR < 1 → Costs exceed benefits → REJECT

Comparing projects: Higher BCR = better value per dollar spent

Project A: BCR = 2.5 (returns $2.50 per $1.00 spent) | Project B: BCR = 1.8 → Choose Project A

BCR = benefits DIVIDED by costs. Sometimes called Cost-Benefit Ratio (CBR). If CBR format is used, it's the same formula. > 1.0 = go. Also called "Benefit Cost Analysis" in some contexts.

Internal Rate of Return (IRR)

The discount rate at which NPV = 0. Represents the expected return rate of the investment.

Decision Rule: Choose the project with the HIGHER IRR
If IRR > required rate of return (hurdle rate) → ACCEPT
If IRR < required rate of return → REJECT

Company hurdle rate = 12%. Project A IRR = 18%. Project B IRR = 9%. → Choose Project A (IRR exceeds hurdle rate AND is higher than Project B)

You do NOT need to calculate IRR on the PMP exam. Just know: Higher IRR = better. IRR must exceed the company's minimum acceptable return (hurdle rate) to be worth doing.

Payback Period

How long it takes to recover the initial investment from project cash flows.

Payback Period = Initial Investment / Annual Cash Flow

Example: $500,000 investment / $100,000/year = 5 years payback

Decision Rule: Shorter payback period = better (recover money faster)
Weakness: Does NOT account for time value of money

Payback Period is the SIMPLEST but WEAKEST method — ignores time value of money and cash flows beyond the payback period. Use NPV for a complete picture. On the exam: shorter payback = always preferred.

Opportunity Cost

The value of the best alternative foregone when choosing one project over another.

Your company can do Project A (NPV = $300K) OR Project B (NPV = $200K). You choose Project A. The opportunity cost = $200K (what you gave up by not doing B).

The opportunity cost of choosing the BEST project = the value of the SECOND-best project. It's what you gave up. Higher opportunity cost = your rejected project was valuable — you'd better be sure about your choice!

Quick Decision Rules Summary

Method	Better Project Has…	Accounts for Time Value?
NPV	Higher NPV	Yes ✅ (Best method)
BCR	Higher BCR (above 1.0)	Sometimes
IRR	Higher IRR	Yes ✅
Payback Period	Shorter period	No ❌ (Weakest method)
Opportunity Cost	N/A — it's what you gave up	Sometimes

60. Quality Gurus & Control Chart Rules

The Quality Gurus — Must Know All Four

Guru	Famous For	Key Concept
W. Edwards Deming	PDCA Cycle, 14 Points, TQM father	"Quality is management's responsibility — not workers." 85% of quality problems are management's fault. Continuous improvement through PDCA.
Joseph Juran	Juran Trilogy, Fitness for Use, Pareto	Quality = "Fitness for use/purpose." Three components: Quality Planning, Quality Control, Quality Improvement. Introduced Pareto Analysis to quality.
Philip Crosby	"Quality is Free", Zero Defects	Prevention is cheaper than inspection. "Do it right the first time." The cost of poor quality far exceeds the cost of prevention.
Kaoru Ishikawa	Fishbone/Cause-Effect Diagram, Quality Circles	Created the Ishikawa (fishbone) diagram. Quality is everyone's job — introduced quality circles. Customer focus is primary.

Deming = PDCA + management's fault. Juran = Fitness for use + Pareto. Crosby = Quality is FREE + Zero Defects + Prevention. Ishikawa = Fishbone diagram. Know which guru goes with which concept!

Control Charts — Deep Dive

Control charts monitor process stability over time. They have:

Upper Control Limit (UCL) — typically +3 sigma from mean
Lower Control Limit (LCL) — typically -3 sigma from mean
Mean — center line (average)
Upper Specification Limit (USL) — customer's maximum acceptable
Lower Specification Limit (LSL) — customer's minimum acceptable

Control Limits ≠ Specification Limits. Control limits come from process data. Specification limits come from customer requirements.

The Rule of Seven (7)

If 7 consecutive data points fall on ONE side of the mean (all above OR all below), the process is considered out of control — even if all points are within the control limits.

Your bridge concrete strength measurements: 4,500 / 4,510 / 4,480 / 4,520 / 4,495 / 4,505 / 4,488 psi — all 7 are above the 4,450 mean. UCL = 4,600. All within limits but STILL out of control by Rule of Seven.

Rule of Seven = 7 points on one side = out of statistical control = INVESTIGATE even if within limits. Something systematic is happening. The process is not random anymore.

Special Cause vs. Common Cause Variation

Special Cause Variation

Also called assignable cause. Unusual events that cause abnormal variation — a specific cause can be identified and fixed.

Data point outside control limits
Rule of Seven triggered
Non-random patterns in data

Action needed: Investigate and eliminate the cause

Common Cause Variation

Also called random cause. Normal variation that is always present in a process. No single assignable cause.

Data fluctuates randomly within control limits
Expected and acceptable
Represents the process's natural variability

Action needed: Process improvement (redesign) — NOT investigation

If a process has ONLY common cause variation → it is "in statistical control" (stable and predictable). Special cause variation = something is WRONG → investigate. Never tamper with a process that only has common cause variation — tampering makes it WORSE.

Statistical Sampling

Testing a representative subset of the population rather than every item. Used in Control Quality.

When to use: When 100% inspection is too costly or time-consuming
Attribute sampling: Result is a YES/NO — item conforms or doesn't
Variable sampling: Measured on a continuous scale (length, weight, temperature)
Sampling risk: Chance that the sample doesn't represent the population

A factory produces 50,000 bolts daily. 100% inspection is impossible. Instead, test 500 random bolts (1% sample). If quality is acceptable in the sample → accept the batch.

Benchmarking

Comparing your project's or organization's practices, metrics, and performance to best-in-class standards from within or outside the industry.

Used in Plan Quality Management to identify quality targets
Can benchmark against: past projects, industry peers, or world-class organizations
Gap between current performance and benchmark = improvement opportunity

Design of Experiments (DOE)

A statistical method that identifies which factors influence specific variables of a product or process. Systematically tests combinations of variables to find the optimal settings.

Used in Plan Quality Management
Helps determine what factors cause quality problems
Example: Testing different combinations of temperature, pressure, and material to find optimal manufacturing conditions
More efficient than testing one variable at a time

61. FPIF Contract Pricing Formula & Communication Types

FPIF — Fixed Price Incentive Fee Contract Pricing

The FPIF contract has a pricing formula with several key components:

Term	Definition
Target Cost	Estimated cost of the project (what seller expects to spend)
Target Fee	Profit the seller expects to earn if at target cost
Target Price	Target Cost + Target Fee
Ceiling Price	Maximum the buyer will EVER pay — absolute cap
Sharing Ratio	How cost savings OR overruns are split between buyer and seller (e.g., 80/20 = buyer takes 80% of variance, seller takes 20%)
Point of Total Assumption (PTA)	Cost level at which the seller assumes ALL additional cost risk. Above PTA, seller pays 100% of overruns (up to ceiling).

PTA Formula:
PTA = ((Ceiling Price − Target Price) / Buyer's Share Ratio) + Target Cost

Example:
Target Cost = $100K, Target Fee = $10K, Target Price = $110K
Ceiling Price = $120K, Sharing Ratio = 80/20 (Buyer/Seller)
PTA = (($120K − $110K) / 0.80) + $100K = $12,500 + $100K = $112,500

If actual cost exceeds $112,500 → seller bears ALL additional cost up to ceiling of $120K

PTA = the point where the seller starts losing money fast. Above PTA, every extra dollar of cost comes ENTIRELY from the seller's profit. The seller's effective fee goes to zero and then negative at the ceiling price. Know the PTA formula!

Contract Incentive Fee vs. Award Fee

Feature	Incentive Fee	Award Fee
Basis	Objective, measurable targets (cost, schedule)	Subjective — buyer's satisfaction rating
Determination	Mathematical formula — clear in contract	Buyer's discretion/judgment
Disputable?	Yes — can be disputed mathematically	No — buyer's subjective opinion is final
Used in	FPIF, CPIF	CPAF

Communication Types — Four Combinations

Type	Description	Examples	When to Use
Formal Written	Official, documented, structured	Contracts, project charter, formal reports, legal notices, RFPs	Legal matters, project baselines, official decisions
Informal Written	Casual, documented but not structured	Emails, text messages, chat messages, memos	Day-to-day coordination, quick updates
Formal Verbal	Official spoken, usually structured	Presentations to executives, public speeches, structured briefings	Stakeholder presentations, status meetings
Informal Verbal	Casual spoken, unstructured	Hallway conversations, phone calls, team discussions	Quick questions, relationship building, osmotic communication

Conflicts or disputes → always use FORMAL WRITTEN communication. Change requests → ALWAYS formal written. Performance issues with vendor → formal written. Complex technical issues → formal written first, then verbal for discussion.

Communication Direction Types

Direction	Description	Example
Upward	PM to senior management, sponsor, executive team	Status reports, escalation of issues, change requests
Downward	PM to project team members	Work assignments, feedback, direction, recognition
Horizontal (Lateral)	PM to peers — other PMs, functional managers at same level	Resource sharing, coordination, lessons learned exchange
External	PM to vendors, customers, regulators, public	Contract communications, press releases, regulatory filings

Paralingual Communication

The meaning conveyed through pitch, tone, inflection, and pace of voice — beyond the actual words spoken.

The same words said with different tone = completely different message
"That's a great idea" (enthusiastic) vs. "That's a great idea" (sarcastic)
PMs must be aware of paralingual cues — their own and their team's
Particularly important in cross-cultural settings where tone norms differ

55% of communication is body language. 38% is tone/paralingual. Only 7% is the actual words. This is why face-to-face is ALWAYS the richest communication medium — you get all three channels.

62. Requirements Categories, Force Field Analysis & More Key Tools

Requirements Categories (Collect Requirements)

Requirements are not all the same. PMI categorizes them into six types:

Category	Definition	Example
Business Requirements	Higher-level needs of the organization — WHY the project is needed	"We need to reduce customer wait time by 30%"
Stakeholder Requirements	Needs and expectations of specific stakeholders or groups	"The sales team needs a mobile-compatible interface"
Solution Requirements	Features and functions the product must have	Functional: "The system shall process 1,000 transactions/second" Non-Functional: "The system shall be available 99.9% of the time"
Transition Requirements	Needed to move from current state to future state — temporary	"Data must be migrated from the old system before go-live"
Project Requirements	Actions, processes, or conditions the project itself must meet	"Project must be completed by Q4 within $500K budget"
Quality Requirements	Conditions or criteria to validate successful completion	"Zero critical defects at launch; pass all user acceptance tests"

Functional requirements = what the product DOES. Non-functional requirements = how the product PERFORMS (quality, reliability, security, usability). Both must be captured. Transition requirements are often forgotten — don't skip them!

Force Field Analysis

A tool for analyzing forces that support or oppose a change. Developed by Kurt Lewin. Used in change management and decision-making.

Driving Forces (For Change)

Customer demand for new features
Competitive pressure
Regulatory requirement
New technology opportunity
Management mandate

Restraining Forces (Against Change)

Cost of change
Team resistance
Lack of skills
Organizational inertia
Risk/uncertainty

Strategy: Strengthen driving forces OR weaken restraining forces (or both). Change happens when driving forces outweigh restraining forces.

Influence Diagrams

A graphical tool used in Quantitative Risk Analysis. Shows cause-and-effect relationships and how variables influence each other and project outcomes.

Nodes = variables (decisions, uncertainties, outcomes)
Arrows = influence/causal relationships
Helps understand complex interdependencies
Input to Decision Tree Analysis and Monte Carlo simulation

Assumptions & Constraints Analysis

Assumptions

Things believed to be true for planning purposes but not yet confirmed. If an assumption proves FALSE → it becomes a risk or issue.

Example: "We assume the vendor will deliver materials by March 1."

Tracked in the Assumption Log (created in Develop Project Charter).

Constraints

Restrictions or limitations that affect project options. Non-negotiable boundaries.

Example: "The system must go live before the fiscal year end." or "Budget is capped at $1M."

Also tracked in the Assumption Log.

Every assumption is a potential risk! If an assumption fails → it becomes an issue (if already happened) or a risk (if it might happen). Review assumptions regularly. Assumptions Log updated throughout the project.

Document Analysis (Collect Requirements Tool)

Reviewing existing documentation to identify requirements:

Business plans, marketing literature, agreements, current processes
Policies, procedures, regulatory requirements
Previous project files, lessons learned
Training materials, current system documentation

Less intrusive than interviews — good starting point before engaging stakeholders directly.

Context Diagram (Collect Requirements Tool)

A visual that shows the product scope — the system being built and its interactions with external actors (people, other systems, organizations).

Shows what flows IN to and OUT of the system
Helps define the boundary of the product
Used early to confirm scope boundaries with stakeholders
Example: A payroll system diagram showing: Employees → (time sheets) → Payroll System → (paychecks) → Bank → (records) → HR

Complete Glossary — Final Terms You Must Know

Term	Definition
Decomposition	Breaking work into smaller, manageable components. Used in both WBS (Create WBS) and activities (Define Activities)
Progressive Elaboration	Continuously improving and detailing the project plan as more information becomes available
Analogous Estimating	Top-down estimating using historical data. Fastest but least accurate. Good when little info available.
Parametric Estimating	Statistical relationship between variables. E.g., cost per square foot × area. More accurate than analogous.
Bottom-Up Estimating	Most accurate. Estimate each work package, then roll up. Most time-consuming.
Accepted Deliverables	Output of Validate Scope. Customer formally signs off. Input to Close Project.
Verified Deliverables	Output of Control Quality. Internally inspected. Input to Validate Scope.
Work Breakdown Structure	Hierarchical decomposition of total work scope. Deliverable-oriented. Lowest level = Work Package.
Work Package	Lowest level of WBS. Can be estimated, scheduled, monitored, and controlled.
Control Account	Management control point where scope, budget, and schedule are integrated and compared to EVM.
Planning Package	WBS component below control account with known work content but without detailed schedule activities yet.
Milestone	Significant point or event in a project. Has zero duration. Used for tracking key dates.
Dummy Activity	Used in ADM (arrow diagramming) to show dependency. Has zero duration and no resources.
Hammock Activity	Summary activity that spans several related activities. Shows aggregate duration.
Gold Plating	Adding extra features beyond what customer asked for. Always wrong — wastes resources and risks problems.
Scope Creep	Uncontrolled scope changes without formal process. Always wrong.
Workaround	Unplanned response to an unidentified risk that has occurred. Ad hoc. Should be documented afterward.
Residual Risk	Risk remaining AFTER a risk response has been implemented. Some risk always remains.
Secondary Risk	New risk created BY implementing a risk response. Must be identified and managed.
Risk Trigger	Warning sign or event that indicates a risk is about to occur or has occurred.
Watch List	List of low-priority risks monitored but not actively managed. Reviewed periodically.
Information Radiator	Highly visible display of project information (burndown, Kanban). Supports transparent communication.
Definition of Done (DoD)	Shared understanding of when work is complete. Defined at project start. Applied to all user stories.
Velocity	Story points completed per sprint. Used to forecast remaining iterations needed.
Spike	Short research iteration to reduce technical uncertainty before committing to a solution.

Workaround ≠ Risk Response. Workarounds are unplanned — they happen when an UNIDENTIFIED risk occurs. If the risk was in your register, you should have a planned response ready, not a workaround.

63. PMI Code of Ethics & Professional Conduct — Complete

The PMI Code of Ethics and Professional Conduct applies to all PMP holders, PMI members, and PMI credential candidates worldwide. It is mandatory — violations can result in disciplinary action up to credential revocation. The Code has four core values, each with an official Vision Statement, Aspirational Standards (what we strive toward — "should" language), and Mandatory Standards (non-negotiable requirements — "must/shall not" language).

The 4 Values: R — R — F — H → Responsibility · Respect · Fairness · Honesty
Each value has: Vision Statement + Aspirational Standards + Mandatory Standards

1. Responsibility

Official Vision: We make decisions and take actions based on the best interests of society, public safety, and the environment.

📋 Aspirational Standards (1.2)

1.2.1 — We make decisions and take actions based on the best interests of society, public safety, and the environment
1.2.2 — We accept only assignments consistent with our background, experience, skills, and qualifications
1.2.3 — We fulfill the commitments we undertake — we do what we say we will do
1.2.4 — When we make errors or omissions, we take ownership and correct promptly. When we discover errors or omissions caused by OTHERS, we communicate them to the appropriate body as soon as discovered. We accept accountability for any resulting consequences
1.2.5 — We protect proprietary or confidential information entrusted to us
1.2.6 — We uphold this Code and hold each other accountable to it

⚠️ Mandatory Standards (1.3)

1.3.1 — We inform ourselves and uphold the policies, rules, regulations, and laws that govern our work, professional, and volunteer activities
1.3.2 — We report unethical or illegal conduct to appropriate management and, if necessary, to those affected by the conduct
1.3.3 — We bring violations of this Code to the attention of the appropriate body for resolution
1.3.4 — We only file ethics complaints when they are substantiated by facts. We do not use the ethics complaint process in a frivolous manner
1.3.5 — We pursue disciplinary action against any individual who retaliates against a person raising ethics concerns

Scenario 1: A team member falsifies inspection results. What do you do?
✅ Address directly first; then escalate. Per 1.3.2, you MUST report — not optional. Per 1.2.4, discovering others' errors triggers the same reporting obligation as your own.

Scenario 2: You report an ethics concern and your manager starts giving you poor performance reviews in retaliation. What does PMI say?
✅ Per 1.3.5, PMI requires disciplinary action against those who retaliate against ethics reporters. Retaliation is itself a Code violation.

Scenario 3: You made a scheduling error that will delay the project 3 weeks. What do you do?
✅ Per 1.2.4, acknowledge immediately to sponsor. Develop a recovery plan. Do NOT hide it or blame others.

Standard 1.2.4 is critical — it covers BOTH your own errors AND others' errors. Both must be reported. Standard 1.3.5 on anti-retaliation is commonly tested — protecting those who speak up is a mandatory duty.

2. Respect

Official Vision: We show a high regard for ourselves, others, and the resources entrusted to us. Resources entrusted to us may include people, money, reputation, the safety of others, and natural or environmental resources.

📋 Aspirational Standards (2.2)

2.2.1 — We inform ourselves about the norms and customs of others and avoid engaging in behaviors that others might consider disrespectful
2.2.2 — We listen to others' points of view, seeking to understand them
2.2.3 — We approach directly those persons with whom we have a conflict or disagreement
2.2.4 — We conduct ourselves in a professional manner, even when it is not reciprocated

⚠️ Mandatory Standards (2.3)

2.3.1 — We negotiate in good faith
2.3.2 — We do not exercise the power of our expertise or position to influence the decisions or actions of others in order to benefit personally at their expense
2.3.3 — We do not act in an abusive manner toward others
2.3.4 — We respect the property rights of others

Scenario 4: A team member from another culture has a very different communication style. What do you do?
✅ Per 2.2.1, learn their cultural norms. Adapt your approach. Respect requires understanding and accommodating differences — not imposing your own norms.

Scenario 5: A vendor is being difficult in contract negotiations. What do you do?
✅ Per 2.3.1, continue to negotiate in good faith. Never use threats, power abuse, or coercion — even if the other party does.

2.2.3 — approach conflict DIRECTLY first. Don't go around people or immediately escalate. 2.3.4 — property rights include intellectual property, software, and confidential data.

3. Fairness

Official Vision: We make decisions and act impartially and objectively. Our conduct must be free from competing self-interest, prejudice, and favoritism.

📋 Aspirational Standards (3.2)

3.2.1 — We demonstrate transparency in our decision-making process
3.2.2 — We constantly re-examine our impartiality and objectivity, taking corrective action as appropriate
3.2.3 — We provide equal access to information to those who are authorized to have that information
3.2.4 — We make opportunities equally available to all qualified candidates

⚠️ Mandatory Standards (3.3)

3.3.1 — We proactively and fully disclose any real or potential conflicts of interest to appropriate stakeholders
3.3.2 — When a real or potential conflict exists, we refrain from decision-making or attempting to influence outcomes unless or until: (a) full disclosure has been made, (b) an approved mitigation plan is in place, AND (c) stakeholder consent to proceed has been obtained
3.3.3 — We do not hire or fire, reward or punish, or award or deny contracts based on personal considerations including favoritism, nepotism, or bribery
3.3.4 — We do not discriminate based on gender, race, age, religion, disability, nationality, or sexual orientation
3.3.5 — We apply the rules of the organization (employer, PMI, or other group) without favoritism or prejudice

Scenario 6: Your brother-in-law's company is bidding on your project contract. What do you do?
✅ Per 3.3.1 & 3.3.2: IMMEDIATELY disclose in writing. You must then: (a) make full disclosure, (b) get an approved mitigation plan, AND (c) get stakeholder consent before you can stay involved in procurement decisions at all.

Scenario 7: A functional manager asks you to favor a specific team member in assignments. What do you do?
✅ Per 3.3.3, refuse. Assignments based on favoritism = Code violation — even if the manager outranks you.

Scenario 8: You disagree with a PMI policy. Can you apply it differently for your project?
✅ No. Per 3.3.5, you must apply organizational rules without favoritism or prejudice — even when you personally disagree.

Standard 3.3.2 has THREE conditions that ALL must be met before you can continue after a conflict of interest: disclosure + mitigation plan + consent. Not just disclosure alone! Standard 3.3.3 explicitly names bribery — a commonly tested scenario.

4. Honesty

Official Vision: We are truthful in our communications and in our conduct.

📋 Aspirational Standards (4.2)

4.2.1 — We earnestly seek to understand the truth
4.2.2 — We are truthful in our communications and in our conduct
4.2.3 — We provide accurate information in a timely manner
4.2.4 — We make commitments and promises, implicit or explicit, in good faith
4.2.5 — We strive to create an environment in which others feel safe to tell the truth

⚠️ Mandatory Standards (4.3)

4.3.1 — We do not engage in or condone behavior designed to deceive others, including but not limited to: making false statements, stating half-truths, providing misleading information, or selectively omitting information that — if known — would render our statements misleading
4.3.2 — We do not engage in dishonest behavior with the intention of personal gain or at the expense of another

Scenario 9: Your sponsor asks you to report the project as "on schedule" to executives when it's 3 weeks behind. What do you do?
✅ Per 4.3.1, refuse. Reporting a false status = making a false statement. Honesty is MANDATORY. Report accurately and offer a recovery plan.

Scenario 10: You tell stakeholders only the parts of the risk report that are favorable, leaving out the critical risks. Is this acceptable?
✅ No. Per 4.3.1, selectively omitting information that would make your statements misleading = deception. This is a mandatory violation even though no false words were spoken.

Scenario 11: A contractor offers you a referral fee for directing more business to them. You accept. Is this a Code violation?
✅ Yes. Per 4.3.2, this is dishonest behavior with intention of personal gain. It is also a conflict of interest under Fairness 3.3.3 (bribery).

Standard 4.3.1 explicitly covers four forms of deception: false statements, half-truths, misleading information, AND selective omission. The exam tests all four. You can violate Honesty without saying a single false word — by omitting key information.

Complete Standards Reference Table

Value	Standard #	Type	Key Requirement
Responsibility	1.2.1	Aspirational	Decisions in best interests of society, public safety, environment
	1.2.2	Aspirational	Accept only assignments matching your qualifications
	1.2.3	Aspirational	Fulfill commitments — do what you say you will do
	1.2.4	Aspirational	Own your errors; report others' errors promptly
	1.2.5	Aspirational	Protect proprietary/confidential information
	1.2.6	Aspirational	Uphold and enforce this Code with others
Responsibility	1.3.1	Mandatory	Know and follow applicable laws, rules, regulations
	1.3.2	Mandatory	Report unethical/illegal conduct to management
	1.3.3	Mandatory	Report Code violations to appropriate body
	1.3.4	Mandatory	File ethics complaints only on substantiated facts
	1.3.5	Mandatory	Pursue disciplinary action against ethics retaliation
Respect	2.2.1–2.2.4	Aspirational	Learn cultural norms; listen; address conflict directly; stay professional
	2.3.1	Mandatory	Negotiate in good faith
	2.3.2–2.3.3	Mandatory	No power abuse; no abusive behavior toward others
	2.3.4	Mandatory	Respect property rights of others
Fairness	3.2.1–3.2.4	Aspirational	Transparency; impartiality; equal access; equal opportunity
	3.3.1–3.3.2	Mandatory	Disclose conflicts; get disclosure + mitigation plan + consent before proceeding
	3.3.3–3.3.4	Mandatory	No favoritism/nepotism/bribery; no discrimination
	3.3.5	Mandatory	Apply org rules without favoritism or prejudice
Honesty	4.2.1–4.2.5	Aspirational	Seek truth; be truthful; accurate & timely info; good-faith commitments; safe environment for truth
	4.3.1	Mandatory	No false statements, half-truths, misleading info, or selective omission
	4.3.2	Mandatory	No dishonest behavior for personal gain or at another's expense

Critical Ethics Exam Rules — All Scenarios

🔴 Conflict of interest discovered → Disclose + get mitigation plan approved + get consent — all 3 required (3.3.2)
🔴 Bribe/kickback offered → Refuse AND report. Both steps required (3.3.3 + 1.3.2)
🔴 Others' errors discovered → You MUST report them — same as your own errors (1.2.4)
🔴 Someone retaliates against ethics reporter → Pursue disciplinary action (1.3.5)
🔴 Sponsor orders false reporting → Refuse. Honesty is mandatory (4.3.1)
🔴 Selectively omitting bad news → Violation — same as lying (4.3.1)
🔴 Personal gain from dishonesty → Explicit violation even if no false words spoken (4.3.2)
🔴 Favoritism/nepotism in contracts or hiring → Violation — bribery also explicitly listed (3.3.3)
🔴 Applying org rules differently for favorites → Violation under 3.3.5
🔴 Taking assignment beyond your skills → Violation under 1.2.2
🔴 Filing unfounded ethics complaint → Violation under 1.3.4
🔴 Cultural gift norms conflict with PMI Code → PMI Code first, then law, then org policy
🔴 Sharing confidential info → Only to authorized parties (1.2.5)

Aspirational vs. Mandatory — Full Distinction

Feature	Aspirational Standards	Mandatory Standards
Language	"We should…" / "We strive to…"	"We must…" / "We shall not…" / "We do not…"
Nature	Ideals — best practices to move toward	Non-negotiable minimum requirements
Violation consequence	Not directly punishable — a goal	Disciplinary action up to credential revocation
Exam behavior	"What SHOULD a PM do?" questions	"What MUST a PM do?" or "What is the PM REQUIRED to do?" questions
Example	Seek to understand cultural norms (2.2.1)	Do not act abusively toward others (2.3.3)

Ethics Priority Order (When Values Conflict)

Public safety, health, and welfare — ALWAYS first, overrides everything
PMI Code of Ethics — governs professional conduct
Applicable laws and regulations — legal requirements
Organizational policies — internal company rules

Your company policy says never publicly disclose project failures. But a structural failure on your bridge project poses a safety risk to the public. → Public safety OVERRIDES company policy. Report immediately. (1.2.1)

The PMI Code of Ethics is publicly available for free at PMI.org — only 8 pages. Reading the original document once is the best exam prep for ethics questions. Every standard listed here maps directly to the official numbered text.

64. Contract Types, Point of Total Assumption & Procurement Deep Dive

PLANNINGEXECUTINGM&C

Contract type selection determines who bears cost risk — the buyer or the seller. This is one of the most-tested procurement topics on the PMP exam. Know each type cold, when to use it, and who takes the risk.

Key Rule: Fixed Price = Seller risk. Cost Reimbursable = Buyer risk. T&M = Shared risk. The more uncertain the scope, the more cost-reimbursable you go. The clearer the scope, the more fixed-price you use.

Contract Types — The Full Picture

Type	Acronym	Who Bears Risk?	Best Used When	Key Feature
Firm Fixed Price	FFP	Seller (most)	Scope is very well-defined, stable, low uncertainty	Price never changes regardless of seller's actual costs. Most common govt contract. Seller maximizes profit by controlling costs.
Fixed Price Incentive Fee	FPIF	Seller (mostly)	Well-defined scope with flexibility for performance incentive	Has a Target Cost, Target Profit, Target Price, Ceiling Price, and a Share Ratio. Seller earns bonus for beating targets.
Fixed Price Award Fee	FPAF	Seller (mostly)	Performance on subjective criteria matters (quality, innovation)	Award fee is based on buyer's subjective assessment. Not disputable by seller.
Fixed Price Economic Price Adjustment	FPEPA	Shared	Long-term contracts where inflation/market changes expected	Price adjustments allowed based on pre-agreed economic indexes (CPI, material cost indices).
Cost Plus Fixed Fee	CPFF	Buyer (most)	Scope is unclear; research, innovation, new territory	Buyer pays ALL costs + a fixed fee (profit). Fee stays the same even if cost changes. Least incentive for seller efficiency.
Cost Plus Incentive Fee	CPIF	Buyer (mostly)	Unclear scope but seller efficiency matters	Buyer pays costs + fee that adjusts based on performance against target. Shares savings and overruns per share ratio.
Cost Plus Award Fee	CPAF	Buyer (mostly)	Performance on subjective criteria + unclear scope	Buyer pays costs + an award based on subjective performance evaluation. Award at buyer's discretion.
Time & Material	T&M	Shared	Scope can't be defined; staff augmentation; short-term work	Hybrid: fixed labor rates (like FP) but open-ended quantities (like CR). Highest admin burden. Requires close monitoring.

FFP = safest for buyer (seller takes all cost risk). CPFF = safest for seller (buyer absorbs all overruns). T&M = riskiest for buyer long-term if no ceiling placed. On exam: "uncertain scope" → Cost Reimbursable. "Well-defined scope" → Fixed Price.

Point of Total Assumption (PTA) — FPIF Formula

The PTA is the cost point in an FPIF contract above which the SELLER assumes 100% of additional costs (up to the ceiling price). Above the PTA, the contract behaves like FFP.

PTA = ((Ceiling Price − Target Price) ÷ Buyer's Share Ratio) + Target Cost

🔢 Worked Example:

Given: Target Cost = $100K | Target Profit = $10K | Target Price = $110K | Ceiling Price = $130K | Share Ratio = 80/20 (buyer/seller)

PTA = ((130K − 110K) ÷ 0.80) + 100K = (20K ÷ 0.80) + 100K = 25K + 100K = $125,000

✅ If actual cost = $120K (below PTA): seller pays 20% of overrun. Buyer pays 80%.
❌ If actual cost > $125K (above PTA): seller absorbs 100% of all additional costs. Ceiling Price is $130K absolute max buyer pays.

PTA formula is frequently tested! Memorize: PTA = ((Ceiling Price − Target Price) ÷ Buyer's Share) + Target Cost. Above PTA → seller eats all cost. Ceiling Price is the absolute maximum the buyer ever pays.

Solicitation Documents — Which to Use When?

Document	Full Name	Use When	Seller Responds With
RFI	Request for Information	Market research only — no procurement decision yet	Capabilities statement
RFP	Request for Proposal	Scope is unclear; need seller to propose HOW to do the work	Proposal (technical + price)
RFQ	Request for Quotation	Scope is clear; need a price quote only	Price quotation
IFB	Invitation for Bid	Government construction; most competitive; price only basis	Sealed bid (price only)
SOW	Statement of Work	Describes what the seller must do — scope of contract work	N/A (it's a buyer document)
NDA	Non-Disclosure Agreement	Before sharing proprietary info with potential sellers	Signed agreement

Procurement Process Flow (PMBOK 6)

Plan Procurement Management (Planning): Make-or-buy decision, contract type selection, SOW creation, source selection criteria
Conduct Procurements (Executing): Issue solicitation docs, receive bids/proposals, evaluate sellers, select seller, negotiate & sign contract
Control Procurements (M&C): Manage contract performance, approve payments, manage changes, resolve claims, close contracts

Source Selection — Evaluation Criteria

Must be defined BEFORE seeing any proposals. Criteria include:

💰 Cost / Price 🎓 Technical Expertise 📋 Management Approach 🔒 Risk 📍 Past Performance 📜 Certifications / Licenses 🤝 References 🏭 Capacity & Facilities

Contract Claims & ADR

⚖️ Claims Administration

Contested changes or potential constructive changes where buyer and seller cannot agree. Handled per contract terms. Unresolved claims go to Alternative Dispute Resolution (ADR).

🤝 ADR Methods (Best to Last Resort)

Negotiation — fastest, cheapest, preferred
Mediation — neutral 3rd party facilitates
Arbitration — 3rd party decides (binding)
Litigation — courts; most expensive & slowest

Claims are always handled in procurement's Control Procurements. The preferred order: Negotiate → Mediate → Arbitrate → Litigate. Negotiation is ALWAYS the first attempt. Litigation is always the LAST resort.

Contract Types — Buyer vs. Seller Risk Summary

FFP
Safest for Buyer

FPIF
Mostly Seller

T&M
Shared

CPIF
Mostly Buyer

CPFF
Safest for Seller

← Buyer Risk Increases → ← Seller Risk Increases

Scenario A: You're hiring a firm to develop a new AI product — scope is highly unclear, requirements will evolve, and failure risk is high. Which contract type? → CPFF or CPIF — cost reimbursable because scope is undefined. Fixed price would expose seller to unacceptable risk.

Scenario B: You need 500 office chairs by April 1st. Which contract? → FFP — perfectly well-defined scope, quantity, and delivery date. No need for flexibility.

Scenario C: You need IT consultants for surge support but can't predict how many hours. Which contract? → T&M — you know the labor rate but not the hours. Perfect T&M scenario. Add a not-to-exceed cap to limit buyer risk.

65. PMP Exam Mindset & Situational Question Strategy

🧠 EXAM STRATEGY

~50% of the PMP exam is Predictive (PMBOK 6) and ~50% is Agile/Hybrid. Most questions are situational — they describe a scenario and ask what you should do. Getting these right requires a specific PMI mindset, not just memorized facts.

The PMI Mindset in 5 Words: Proactive. Ethical. Stakeholder-First. Process-Driven. Value-Focused.
When in doubt, ask: "What would a perfect PM who always follows PMI standards do?" — That's almost always the answer.

The PMI Hierarchy — Who to Go to When

Situation	Who Do You Go To?	Why
Scope / schedule / budget change needed	Change Control Board (CCB)	ALL changes require formal approval
Issue beyond PM's authority	Project Sponsor	Sponsor owns the project above PM level
Team member performance issue	Address with team member directly FIRST	Direct communication before escalation
Conflict between team members	PM facilitates; guide toward compromise/collaborate	PM is responsible for team environment
Ethical violation by stakeholder	Report per PMI Code of Ethics (don't ignore)	Ethics must be upheld — non-negotiable
Customer wants extra features (scope creep)	Submit formal change request; evaluate impact	Never add scope without formal approval
Functional manager won't release resources	Negotiate first; escalate to sponsor if needed	PM has limited authority in matrix orgs

The "What Do You Do FIRST / NEXT?" Framework

Step 1 — Assess/Investigate: Before taking action, understand the situation. Gather data, assess impact.

Step 2 — Communicate: Inform relevant stakeholders (especially sponsor and team).

Step 3 — Plan/Analyze: Develop options and a response plan.

Step 4 — Execute/Implement: Carry out the approved response.

Step 5 — Monitor: Ensure the response is working. Document lessons learned.

When asked "What do you do FIRST?" — almost always the answer involves ASSESSING/INVESTIGATING before acting. Never jump to fixing, escalating, or blaming without understanding the situation first.

Eliminating Wrong Answers — 7 Rules

Eliminate "blame someone" answers — PMI never blames people; focus on the process
Eliminate "do it yourself without telling anyone" answers — PMs communicate and document everything
Eliminate "just ignore it" or "do nothing" answers — PMI PMs are always proactive
Eliminate answers that skip the process — e.g., going straight to execution before planning
Eliminate answers where PM makes unilateral decisions — stakeholders are always involved
Eliminate "accept scope changes without formal process" — all changes = change request
Eliminate "hide bad news from the sponsor" — transparency is mandatory in PMI ethics

Agile Situational Questions — Key Rules

Situation	Best PMI-Agile Answer
Customer wants to change requirements mid-sprint	Add to the product backlog; evaluate in next sprint planning (don't disrupt current sprint)
Team member is blocked on a task	PM/Scrum Master removes the impediment immediately — this is the SM's primary job
Velocity is dropping sprint over sprint	Hold a retrospective; identify and address root causes
Stakeholder wants a feature not in the backlog	Product Owner adds/prioritizes it in the backlog; team doesn't take it directly
Team disagrees on story point estimate	Use Planning Poker; discuss outliers until consensus
Sprint ends with incomplete items	Incomplete items return to the backlog (do NOT roll them over automatically)
Definition of Done not met for a story	Story is NOT accepted; it goes back to the backlog for completion

Conflict Resolution — PMI's Preferred Order

When asked how to handle conflict, PMI's preferred methods in order:

Collaborate / Problem Solve — 🥇 BEST. Win-win. Both parties work together to find a solution. Takes most time but lasts longest.
Compromise / Reconcile — 🥈 Both parties give up something. Lose-lose or half-win. Acceptable short-term.
Smooth / Accommodate — Emphasize agreement, downplay differences. Temporary fix only.
Force / Direct — One party wins, other loses. Use only when time-critical. Damages relationships.
Withdraw / Avoid — 🚫 WORST. Postpone or retreat. Never resolves the problem.

Always pick Collaborate first. Withdraw is always wrong as a long-term solution. If the question says "time is running out" and you need a fast decision → Forcing/Directing may be acceptable. Otherwise always go with Collaborate.

Power Types — Influence Without Authority

Power Type	Source	PMI View
Formal / Legitimate	Position title (PM, Director)	Acceptable but limited alone
Expert	Technical knowledge & skill	✅ Highly respected by PMI
Referent	Personal charisma, likability, relationships	✅ Very effective long-term
Reward	Ability to give bonuses, promotions, recognition	Acceptable; use carefully
Coercive / Penalty	Ability to punish, fire, threaten	🚫 PMI considers this least effective
Informational	Control of data and information flow	Neutral; avoid weaponizing

Expert and Referent power are PMI's FAVORITES. Coercive power is the WORST in PMI's view. Even when you have formal authority, use Expert and Referent power to build collaboration.

When to Use Which Lifecycle

Situation / Signal in Question	Correct Approach
"Requirements are well-defined, scope is stable"	Predictive (Waterfall)
"Requirements are unclear, expected to change"	Agile / Adaptive
"Regulatory compliance is required, but some phases need flexibility"	Hybrid
"Customer needs to see working product frequently"	Agile / Iterative
"Large, complex infrastructure project with government client"	Predictive (regulatory + defined scope)
"New technology, innovation, R&D project"	Agile (high uncertainty)
"Physical construction project" (building, bridge, etc.)	Predictive — physical work can't be iterative

Communication Formula — Always Know Your Channel Count

Communication Channels = N × (N−1) ÷ 2 (N = number of people in the project)

🔢 Worked Examples:

Team Size (N)	Channels = N(N-1)/2	Change if N grows by 3?
5	10	—
8	28	—
8 → 11 (add 3)	28 → 55	+27 new channels
10	45	—
15	105	—

When the team grows from N to M: new channels = M(M-1)/2 − N(N-1)/2. The exam often asks "how many NEW channels were added" — calculate both and subtract.

Story Points & Agile Estimation Quick Reference

📋 User Story Format

"As a [role], I want [feature], so that [benefit]."

Example: "As a project manager, I want a dashboard showing all risks, so that I can prioritize responses efficiently."

INVEST Criteria: Independent · Negotiable · Valuable · Estimable · Small · Testable

🃏 Planning Poker

Team members estimate story points simultaneously using cards (Fibonacci: 1, 2, 3, 5, 8, 13, 21…). Outliers discuss rationale. Repeat until consensus. Prevents anchoring bias.

Velocity Formula: Average story points completed per sprint.
Release Planning: # Sprints = Total Backlog Points ÷ Velocity

Definition of Done vs. Definition of Ready

✅ Definition of Done (DoD)

A shared agreement on what "complete" means for a user story or sprint. Examples: code written, unit tested, peer reviewed, deployed to staging, acceptance tested. If DoD is not met → story is NOT done.

🚦 Definition of Ready (DoR)

The criteria a user story must meet before the team will accept it into a sprint. Examples: story is written, acceptance criteria defined, dependencies identified, story is estimated.

Top 15 Exam Traps — Never Fall For These

The PM does NOT sign the Project Charter — the Sponsor signs it
Scope changes must ALWAYS go through formal change control — even if the customer asks nicely
Lessons Learned are documented throughout the project — not just at the end
The WBS is decomposed to work packages — activities are NOT part of the WBS
Control Quality produces Verified Deliverables → these go to Validate Scope → Customer accepts → Accepted Deliverables
In a Functional org, the Functional Manager controls resources — PM has little authority
The most common source of conflict in projects is Schedule (not personality)
The critical path has zero float — activities on it cannot be delayed
SPI and CPI both use EV first in the formula (EV/PV and EV/AC)
Management Reserve is for unknown-unknowns — NOT in the cost baseline
Gold Plating (adding extra features without approval) is wrong — even if the customer would like it
A project terminated early STILL must be formally closed
The Scrum Master is a servant leader — they do NOT assign tasks or make decisions for the team
Risk Register is created during Identify Risks — not Plan Risk Management
A residual risk is what remains AFTER a risk response. A secondary risk is a NEW risk created BY the response itself

Full Scenario Practice:
Your project is 60% complete (EV=$600K, AC=$750K, PV=$700K, BAC=$1,000K). The sponsor just asked for a progress report. A team member mentioned the scope is being exceeded because the client keeps requesting small additions informally.

Q1: What is the CPI? → EV/AC = 600/750 = 0.80 (over budget)
Q2: What is the SPI? → EV/PV = 600/700 = 0.857 (behind schedule)
Q3: What is the EAC (using CPI)? → BAC/CPI = 1000/0.80 = $1,250K
Q4: What should the PM do about scope additions? → Immediately implement change control. All additions — no matter how small — require a formal change request. This is textbook scope creep prevention.
Q5: What document tracks the performance above? → Work Performance Reports (the comprehensive report given to stakeholders)

66. Interpersonal Skills — Active Listening, EQ, Negotiation & More

PEOPLE SKILLS

Interpersonal and team skills appear as a Tool & Technique in more than 20 PMBOK processes. The PMP exam tests these heavily in situational questions. A PM who lacks people skills fails — even with perfect technical knowledge.

PMI People Skills Acronym: ANCELPC — Active Listening · Negotiation · Cultural Sensitivity · Emotional Intelligence · Leadership · Political Awareness · Coaching

1. Active Listening

What It Is

Fully concentrating, understanding, responding, and remembering what is being said — not just waiting for your turn to speak. The PM demonstrates understanding before responding.

Techniques:

Paraphrasing — restate in your own words: "So what I'm hearing is…"
Clarifying questions — "Can you tell me more about…?"
Non-verbal cues — eye contact, nodding, open body posture
Summarizing — recap key points at end of discussion
Avoiding interruptions — let the speaker finish completely

🎭 Exam Scenarios

A team member comes to you frustrated about a workload issue. What do you do first?
✅ Listen actively — let them speak fully, paraphrase, ask clarifying questions before offering solutions.

A stakeholder says "I'm not sure this project will meet our needs." What is the PM's best first response?
✅ Ask an open-ended question — "What specific concerns do you have?" Not: defend the project or reassure without data.

On the exam: whenever a conflict or disagreement scenario appears, active listening (understand first, respond second) is almost always the FIRST step.

2. Emotional Intelligence (EQ)

The ability to recognize, understand, and manage your own emotions AND the emotions of others. Developed by Daniel Goleman. Higher EQ = more effective PM.

EQ Component	What It Means	PM Application
Self-Awareness	Know your own emotions and triggers	Recognize when you're stressed; don't let it affect decisions
Self-Regulation	Control your emotional responses	Stay calm in crisis; don't react impulsively to bad news
Motivation	Inner drive beyond money/status	Stay committed to project goals through adversity
Empathy	Understand others' feelings/perspectives	Sense team morale, adapt communication style per person
Social Skills	Build relationships, manage networks	Influence without authority, resolve conflict, build alliances

EQ is more important than IQ for project success according to PMI. A PM with high EQ notices a team member is disengaged BEFORE it becomes a problem, and addresses it proactively.

Scenario: During a status meeting, you notice a senior developer is unusually quiet and seems withdrawn. EQ tells you to:
✅ Speak with them privately after the meeting. Ask open questions. Listen without judgment. Discover the issue early — a burned-out developer is a project risk.

3. Cultural Sensitivity & Diversity

What It Is

Awareness and respect for cultural differences in communication styles, decision-making, hierarchy, time, and conflict resolution across global or diverse teams.

Hofstede's Cultural Dimensions (exam aware):

Power Distance — comfort with hierarchy and authority
Individualism vs. Collectivism — "I" vs. "We" orientation
Uncertainty Avoidance — comfort with ambiguity
Long vs. Short Term Orientation — future vs. present focus

🎭 PM Application

Adjust communication style — some cultures prefer indirect communication
Never assume silence = agreement (especially in high power-distance cultures)
Be aware of time zone differences, holidays, and religious observances
Avoid slang, idioms, or humor that may not translate across cultures
In high-power-distance cultures, team members may not challenge a PM directly — create safe channels for feedback

When a global virtual team has communication breakdowns — first assess cultural differences before assuming incompetence or bad intent.

4. Negotiation Tactics

PMs negotiate constantly: with sponsors (budget), functional managers (resources), vendors (contracts), and team members (priorities). PMI's approach is principled negotiation (win-win focus).

Tactic	Description	PMI View
BATNA	Best Alternative to a Negotiated Agreement — know your walk-away point	✅ Always know your BATNA before negotiating
Separate people from problem	Focus on interests, not positions	✅ Core PMI negotiation principle
Focus on interests, not positions	Ask "why" not just "what"	✅ Uncovers real needs, enables creative solutions
Invent options for mutual gain	Brainstorm before deciding	✅ Builds win-win outcomes
Anchoring	First offer sets the reference point	Neutral — be aware of it
Good cop/Bad cop	One party is tough, other is sympathetic	🚫 Manipulative — PMI doesn't endorse
Deadline pressure	Create artificial urgency	🚫 Can damage long-term relationship

PMI always prefers negotiation approaches that: preserve the relationship, focus on interests (not positions), and seek win-win outcomes. Avoid manipulation tactics on the exam.

Scenario: The functional manager refuses to release a key engineer to your project. You have been negotiating for 2 weeks with no progress.
✅ PMI answer: Try to understand the manager's underlying concern (interest, not position). Offer alternatives (part-time, phased schedule). If still stuck, escalate to the sponsor — do not go around the manager or threaten.

5. Coaching vs. Mentoring vs. Training

Approach	Who Leads	Focus	Goal	PM Role
Coaching	Coachee (with facilitation)	Specific performance or behavior	Unlock existing potential — person finds their own answer	Ask powerful questions; don't give answers
Mentoring	Mentor	Career development & wisdom	Transfer knowledge and experience	Share your own journey, lessons, advice
Training	Trainer/Instructor	Specific skill or knowledge gap	Build new capability	Send team to formal training

Coaching in Practice

A team member struggles with stakeholder communication. Instead of telling them what to do, you ask: "What do you think is causing the disconnect? What have you tried? What options do you see?" — They arrive at their own solution, which they own and implement.

Mentoring in Practice

A junior PM asks how to handle a difficult sponsor. You share your personal experience: "When I had a similar situation, I found that weekly one-page status updates helped build trust — let me show you the template I used."

Coaching = ask questions, don't give answers — person finds their own solution. Mentoring = share your experience and advice directly. Training = structured skill-building with a curriculum. PMI loves coaching as a leadership approach in agile teams.

6. Conflict Resolution — Deep Dive with Scenarios

Method	PMI Name	Outcome	When to Use	Exam Trap
🥇 Collaborate	Problem Solve / Confront	Win-Win ✅	ALWAYS first. Enough time, both parties willing	Often called "confronting" — not aggressive, it means facing the issue directly
🥈 Compromise	Reconcile	Partial Win/Lose	Both parties give something. Useful when collaboration isn't possible	Not ideal — both parties lose something. Better than forcing or avoiding
Smooth	Accommodate	Temporary	When preserving harmony short-term matters. NOT a permanent solution	Only defers the conflict — problem still exists
Force	Direct	Win-Lose	Emergency, time-critical decision needed. PM uses authority	Damages relationships. Use only when necessary
🚫 Withdraw	Avoid	Unresolved	Almost never — conflict remains unresolved	WORST option. Never the PMI answer unless temporarily stepping back to let emotions cool

Scenario Bank — Pick the Right Method:

Scenario A: Two developers disagree on the technical architecture for a module. Both are experienced and passionate. The project isn't time-critical on this decision.
✅ Collaborate — have them problem-solve together. Bring in a third technical expert if needed. Win-win solution protects quality and team morale.

Scenario B: Two team members argue during a meeting, getting personal. The meeting is disrupting everyone else.
✅ Smooth then Collaborate — acknowledge both views briefly (smooth to restore calm), then schedule a separate one-on-one with each and a joint session later to resolve properly.

Scenario C: A production server is down. The team argues about which recovery approach to use. Every minute costs money.
✅ Force — PM makes the call. No time for collaboration. After the crisis, debrief and collaboratively improve the process.

Scenario D: A stakeholder constantly interrupts team meetings to re-litigate decisions already made.
✅ Confront directly — have a private conversation. Understand their concern. Revisit the decision formally if warranted. Don't avoid or let it fester.

Biggest Sources of Project Conflict (PMI's research order):

1️⃣ Schedule 2️⃣ Project Priorities 3️⃣ Resources 4️⃣ Technical Opinions 5️⃣ Administrative Procedures 6️⃣ Cost 7️⃣ Personality

The #1 source of conflict in projects is SCHEDULE — not personality. This surprises many students. Personality conflicts rank last. If the exam asks "what is the most common source of project conflict?" → answer is Schedule.

67. Change Management Models — ADKAR & Kotter Deep Dive

CHANGE MANAGEMENT

Section 36 introduced the four change models. This section provides the deep-dive detail — with step-by-step application, diagnostic use, real scenarios, and exam comparisons — that the PMP exam requires for 50%+ exam questions involving organizational change and resistance.

ADKAR Model — Prosci Framework (Individual Change)

Created by: Jeff Hiatt / Prosci. Focus: WHY individual change succeeds or fails. Used to diagnose where a person is "stuck" in their change journey. Works bottom-up — one person at a time.

Key principle: All 5 steps are sequential and cumulative. You CANNOT skip a step. If someone is at Knowledge but hasn't achieved Desire, more training will NOT help — you must go back and address Desire first.

Step	Letter	What it means	Barrier at this step	PM Action
1. Awareness	A	Person understands WHY the change is needed and what happens if nothing changes	Lack of information; misinformation; poor communication from leaders	Communicate clearly and repeatedly. Explain the burning platform — what's the cost of NOT changing?
2. Desire	D	Person WANTS to support and participate in the change. Personal motivation	Personal risk, WIIFM ("What's in it for me?"), distrust of management, past change failures	Address personal concerns individually. Find champions. Involve people in the design. Show personal benefits.
3. Knowledge	K	Person knows HOW to change — skills, processes, behaviors required in the new state	Insufficient training, unclear new role expectations, too much information at once	Provide targeted training, job aids, and clear process documentation. Pilot programs.
4. Ability	A	Person CAN demonstrate the new skill or behavior. Knowledge ≠ Ability (practice required)	Lack of practice time, psychological barriers, physical/technical constraints	Provide coaching, hands-on practice, simulations, and a safe environment to make mistakes.
5. Reinforcement	R	Change is SUSTAINED. New behaviors become the default way of working	No accountability; old behaviors creeping back; lack of recognition	Celebrate successes. Remove old system/workarounds. Performance metrics tied to new behavior. Recognition.

🎭 ADKAR Diagnostic Scenario

Situation: Your organization is rolling out a new project management software. You've provided 3 training sessions, but only 30% of the team is using it consistently.

ADKAR Analysis: Training addresses Knowledge — but the real barrier is likely Desire ("I'm comfortable with Excel, why change?") or Ability ("I know what to do but make errors under pressure").

Action: Survey the team. Address Desire by connecting the tool to their specific pain points. Increase coaching for Ability. Add Reinforcement by making the new tool required for status reporting.

🎯 ADKAR Exam Tips

ADKAR = individual change, not organizational
It is sequential — diagnose which step is the barrier
Training only helps at the Knowledge step
If training failed, the problem is probably Desire
Prosci owns ADKAR — Hiatt created it in 1998
"Change failed because people didn't know how" → Knowledge gap
"Change failed because people went back to old habits" → Reinforcement gap

Kotter's 8-Step Model — Organizational Change (Top-Down)

Created by: Dr. John Kotter, Harvard. Focus: HOW to lead large-scale organizational change. Top-down model — leadership drives it. Sequential — skipping steps causes failure.

Key principle: Most change fails at steps 1 (no urgency), 4 (no communication), or 8 (not anchored). Step 1 is the most critical — without urgency, change never gains momentum.

#	Step	What to Do	Why It Fails	PM/Leader Action
1	Create Urgency	Show stakeholders why change must happen NOW — not later	Complacency; "we're doing fine" mindset	Present market data, competitor threats, customer pain. Make the status quo feel riskier than the change.
2	Build a Coalition	Assemble a team with enough power, credibility, and diversity to lead the change	Change led by one person who loses momentum when they leave	Identify change champions across departments. Include informal leaders, not just managers.
3	Create a Vision	Develop a clear, compelling picture of the future state	Too many plans, not enough clarity; vision is vague or confusing	Write a vision that anyone can understand in 5 minutes. Test: can you explain it in under 2 minutes?
4	Communicate the Vision	Share it relentlessly — use every channel, every meeting, every conversation	One email and one town hall — then silence	Kotter's rule: leadership must communicate the vision 10x more than they think necessary.
5	Remove Obstacles	Identify and eliminate barriers: structures, processes, people resisting change	Middle managers block change; outdated systems remain	Empower employees to act. Reward change leaders. Restructure if necessary.
6	Generate Short-Term Wins	Create visible, meaningful milestones within 12 months	Change takes too long; cynics use lack of results to undermine	Plan for quick wins deliberately. Recognize and reward participants in those wins.
7	Build on the Change	Keep the momentum going; use early wins to tackle bigger issues	Declaring victory too early after the first win	"We won!" is the enemy. Use credibility from wins to tackle the next wave of change.
8	Anchor in Culture	Make the new approaches stick — embed in norms, values, processes	Old culture absorbs the change and reverts	Connect new behaviors to organizational success stories. Change personnel processes, hiring, and onboarding to reinforce.

ADKAR vs. Kotter — Side-by-Side Comparison

Feature	ADKAR (Prosci)	Kotter's 8 Steps
Level	Individual person	Organizational / leadership
Direction	Bottom-up (one person at a time)	Top-down (leadership drives)
Creator	Jeff Hiatt / Prosci (1998)	John Kotter / Harvard (1996)
Primary Use	Diagnose WHY someone resists or fails to adopt change	Plan and execute large-scale organizational change
Steps	5 (sequential, diagnostic)	8 (sequential, prescriptive)
Key Insight	Training doesn't fix a Desire problem	Urgency is the essential first step
Fails When	Steps are skipped or order ignored	Step 1 or 8 is weak
Exam Trigger Words	"individual," "adoption," "resistance," "training didn't work"	"organization-wide," "leadership," "urgency," "culture"

When the exam asks about change management in projects, ADKAR covers WHY individuals resist and HOW to help them adopt. Kotter covers HOW leadership drives and sustains large organizational transformation. Both are tested — know the trigger words to pick the right model.

68. Stakeholder Register & Power/Interest Grid — Complete Templates

INITIATING

The Stakeholder Register is the PRIMARY output of the Identify Stakeholders process. It must be created during Initiating and updated throughout the project. The Power/Interest Grid is the most common data representation tool used to categorize stakeholders.

📋 Stakeholder Register — Full Template

The register must capture all information needed to manage stakeholder engagement throughout the project. It is a confidential document — not shared with stakeholders themselves.

ID	Name	Role / Title	Organization	Contact Info	Power	Interest	Influence	Impact	Current Engagement	Desired Engagement	Requirements / Expectations	Potential for Resistance	Strategy
SH-01	Jennifer Walsh	Project Sponsor / VP Operations	Internal	jwalsh@co.com	H	H	H	H	Leading	Leading	Project on time & budget; monthly executive summaries; approval of >$50K changes	Low — champion of project	Bi-weekly 1:1; formal status reports; early escalation of issues
SH-02	Mark Torres	Functional Manager — IT	Internal	mtorres@co.com	H	M	H	H	Neutral	Supportive	Resource allocation commitments; advance notice for team scheduling	Medium — protecting his team's time	Negotiate resource agreements early; involve in milestone planning
SH-03	Priya Nair	End User Representative	Customer	pnair@customer.com	L	H	M	H	Resistant	Supportive	User-friendly interface; minimal disruption to current workflow; training before go-live	High — change adverse, prior bad experience with IT projects	Involve in UAT; address concerns early; provide dedicated training
SH-04	City Regulator (EPA)	External Regulatory Body	Government	permits@epa.gov	H	L	H	H	Unaware	Neutral	Full regulatory compliance; timely permit applications; environmental impact assessment	Medium — unaware = potential surprise intervention	Early permit filing; quarterly compliance updates; retain environmental consultant
SH-05	Alex Kim	Lead Developer	Internal	akim@co.com	L	H	M	H	Supportive	Leading	Clear technical requirements; realistic timelines; recognition for quality work	Low — highly motivated	Weekly team meetings; involve in design decisions; public recognition of contributions

H = High | M = Medium | L = Low | Engagement levels: Unaware → Resistant → Neutral → Supportive → Leading

The Stakeholder Register is CONFIDENTIAL — never share it with stakeholders (it contains assessments of their resistance). Update it regularly throughout the project — new stakeholders emerge; existing ones shift engagement levels.

📊 Power/Interest Grid — Visual with All 4 Quadrants

The Power/Interest Grid (also called Influence/Impact Grid) plots stakeholders on two axes to determine the engagement strategy. It is a Data Representation tool in the Identify Stakeholders process.

🎭 Power/Interest Grid Scenarios

Scenario A: A government regulator has power to shut down your project but rarely asks for updates (low interest). Strategy → Keep Satisfied: ensure compliance, proactively send required reports. Don't wait for them to ask.

Scenario B: End users will use the system daily and care deeply about usability, but have no authority to approve or reject (low power, high interest). Strategy → Keep Informed: involve in UAT, gather frequent feedback, communicate changes early.

⚠️ Grid vs. Salience Model

Feature	Power/Interest Grid	Salience Model
Dimensions	2 (Power, Interest)	3 (Power, Legitimacy, Urgency)
Output	4 quadrant strategies	7 stakeholder classes
Best for	Quick prioritization, large groups	Complex stakeholder situations
Dynamic?	Less so	Yes — attributes change over time

Stakeholders can move between quadrants during the project — a "Monitor" stakeholder who discovers the project impacts their department can quickly become "Manage Closely." Re-assess regularly.

69. Communications Formula — Worked Examples & Scenarios

PLANNING

The communication channels formula is one of the most frequently tested math questions on the PMP exam. It also appears in situational questions about team expansion and communication complexity. Master both the formula and the logic behind it.

The Formula

Communication Channels = N × (N − 1) ÷ 2
where N = total number of people on the project (including the PM)

Why This Formula Exists

Every person on a project can communicate with every other person. With N people, each person has N−1 potential communication partners. Since each channel is shared by two people, we divide by 2 to avoid double-counting. The result grows exponentially — not linearly — with team size.

📊 Quick Reference Table

Team Size (N)	Channels = N(N-1)/2	Growth from previous
2	1	—
3	3	+2
4	6	+3
5	10	+4
6	15	+5
8	28	+13 (from 5)
10	45	+17 (from 8)
11	55	+10
12	66	+11
15	105	+39 (from 12)
20	190	+85 (from 15)
25	300	+110 (from 20)

🔢 Worked Exam Scenarios

Scenario 1 — Basic Calculation

Q: Your project team has 10 people including yourself. How many communication channels exist?

Channels = 10 × (10 − 1) ÷ 2 = 10 × 9 ÷ 2 = 90 ÷ 2 = 45 channels

Scenario 2 — Adding Team Members (Most Common Exam Trap)

Q: Your project team has 8 people. You add 3 more members. How many new communication channels were added?

Before: 8 × (8−1) ÷ 2 = 8 × 7 ÷ 2 = 28 channels
After: 11 × (11−1) ÷ 2 = 11 × 10 ÷ 2 = 55 channels
New channels added = 55 − 28 = 27

The trap: students answer "55" (total) instead of "27" (new channels added). The question asks for the INCREASE, not the total. Always subtract before from after.

Scenario 3 — Removing a Team Member

Q: A team of 12 loses 2 members. How many communication channels were eliminated?

Before: 12 × (12−1) ÷ 2 = 12 × 11 ÷ 2 = 66 channels
After: 10 × (10−1) ÷ 2 = 10 × 9 ÷ 2 = 45 channels
Channels eliminated = 66 − 45 = 21

Scenario 4 — Find Team Size from Channel Count

Q: Your project has 45 communication channels. How many people are on the team?

N(N−1)/2 = 45 → N(N−1) = 90
Try N=10: 10 × 9 = 90 ✅
Answer: 10 people

Tip: Memorize key N→channels pairs: 5→10, 8→28, 10→45, 11→55, 12→66, 15→105. The exam usually uses "nice" numbers.

Scenario 5 — PM Joining an Existing Team

Q: A project has 9 team members working independently (no PM). A new PM is assigned. How many new communication channels does the PM create?

Before (9 people, no PM): 9 × 8 ÷ 2 = 36 channels
After (10 people including PM): 10 × 9 ÷ 2 = 45 channels
New channels = 45 − 36 = 9 (= N − 1 = 10 − 1)

When ONE person is added, the number of new channels equals exactly N − 1 (where N is the new total). Adding 1 person to a team of 9 creates 9 new channels (the PM can communicate with each of the 9 existing people).

🧠 The Shortcut Rule

When adding 1 person to an existing team of M people: New channels = M (the new person creates one channel with each existing member).

When adding K people to a team of M: new channels = (M+K)(M+K-1)/2 − M(M-1)/2. No shortcut — must calculate both.

Why This Matters for PM Decision-Making

⚠️ Adding People ≠ Faster

Brooks's Law (from "The Mythical Man-Month"): "Adding manpower to a late software project makes it later." More people = exponentially more channels = more coordination overhead = slower throughput initially. New members need ramp-up time and create communication burden on existing team.

✅ PM Strategies

Keep teams small when possible (agile prefers 5–9 people)
Use a communication management plan to structure channels
Not every channel needs to be active — the PM manages which ones matter
Use formal reporting to reduce ad-hoc channels
Virtual teams need explicit communication protocols

Three common exam traps: (1) Forgetting to include the PM in N. (2) Answering "total channels" when asked for "new channels added." (3) Not memorizing N=10→45 and N=5→10 as quick checks.

70. Who & What — Documents, Authority & The Complete Change Sequence

👤 WHO & WHAT — 100% PMBOK 6 VERIFIED

This section is one of the highest-yield areas on the PMP exam. Questions ask: Who develops a document? Who approves or signs it? Which PMBOK 6 process produces it? Master this table and you lock in 10–20 correct answers. Every entry below is verified against PMBOK 6 and the PMP Exam Content Outline.

PMI Authority Hierarchy: PMI Code of Ethics → Applicable Laws & Regulations → Project Charter → Project Management Plan → CCB Decisions → PM Authority → Team
Golden Rule: Sponsor signs the Charter | CCB approves ALL baseline changes | PM does NOT sign contracts | Customer accepts deliverables | PM owns and updates the PM Plan

📋 Master Document Authority Table — PMBOK 6 Verified

Column guide: ■ Red = Sponsor / Customer / Senior Mgmt authority | ■ Orange = PM authority | ■ Green = CCB authority | ■ Blue = Shared / Any Stakeholder

Document	Developed / Created By	Approved / Signed By	PMBOK 6 Process (Section)	Critical Exam Notes & Common Traps
🚀 INITIATING PROCESS GROUP
Business Case	Business Analyst or Sponsor's team; PM may assist	Senior Management / Sponsor	Pre-Project / Portfolio; Input to Develop Project Charter (4.1)	Created before the Charter to justify the investment. The Sponsor OWNS it — PM does not. It is an EEF/OPA input to initiating. PM does not sign it.
Benefits Management Plan	Sponsor / Business Owner; PM may assist	Sponsor	Pre-Project; Input to Develop Project Charter (4.1)	Sponsor is accountable for benefits realization — which continues AFTER project closes. PM executes work to enable benefits but does not own this plan.
Project Charter	PM drafts it; Sponsor reviews and finalizes	Sponsor (or Initiating Authority / Senior Mgmt)	Develop Project Charter — Initiating (4.1)	EXAM TRAP #1: The PM does NOT sign the Charter. The Sponsor signs it. The Charter grants the PM formal authority. Without a signed Charter there is no authorized project and the PM has no authority.
Assumption Log	PM (initiated with Charter; updated throughout)	PM	Develop Project Charter (4.1); updated in all processes	Started at Initiating — key assumptions and constraints from the Charter are logged here. If an assumption proves false, it becomes a RISK or ISSUE. PM owns and updates this throughout.
Stakeholder Register	PM (with team input)	PM	Identify Stakeholders — Initiating (13.1); updated throughout	CONFIDENTIAL — do not share with the stakeholders it describes. Contains power/interest analysis and engagement strategies. Updated throughout project as stakeholders change.
📋 PLANNING PROCESS GROUP
Project Management Plan (PM Plan)	PM (with input from the whole team and subject matter experts)	PM creates & owns; Sponsor formally approves	Develop Project Management Plan — Planning (4.2)	The PM OWNS the PM Plan — the single most important planning document. Contains all 10 subsidiary plans and 3 baselines. Changes to the PM Plan require formal Integrated Change Control (CCB). The PM Plan is the baseline for measuring project performance.
Scope Management Plan	PM (with team)	PM (as part of PM Plan)	Plan Scope Management — Planning (5.1)	Subsidiary plan within PM Plan. Describes HOW scope will be defined, validated, and controlled. Does not define scope itself — that is the Scope Statement.
Requirements Documentation & RTM	PM and team (from Collect Requirements process)	PM / Customer validates requirements	Collect Requirements — Planning (5.2)	RTM (Requirements Traceability Matrix) links every requirement to its business objective and tracks it through design, development, and testing. It is the tool used to PREVENT scope creep and ensure completeness.
Project Scope Statement	PM (with team and customer input)	PM (part of Scope Baseline)	Define Scope — Planning (5.3)	Describes what IS and what is NOT in scope. Contains deliverables, constraints, assumptions, and acceptance criteria. Part of the SCOPE BASELINE along with WBS and WBS Dictionary.
WBS & WBS Dictionary	PM and the PROJECT TEAM (not PM alone)	PM (part of Scope Baseline in PM Plan)	Create WBS — Planning (5.4)	EXAM TRAP: The TEAM creates the WBS — not the PM alone. This is deliberate: team involvement creates buy-in and better estimates. WBS Dictionary defines each work package (owner, duration, cost, resources). 100% Rule: WBS must capture 100% of scope — no more, no less.
Scope Baseline (Scope Statement + WBS + WBS Dictionary)	PM and team	CCB for any changes; PM approves initial baseline in PM Plan	Create WBS (5.4); part of PM Plan (4.2)	One of the 3 performance measurement baselines. Changes to Scope Baseline require a formal Change Request approved by CCB — no exceptions, even for small additions. Scope Baseline + Schedule Baseline + Cost Baseline = Performance Measurement Baseline (PMB).
Schedule Baseline	PM and Scheduler (with team estimates)	CCB for any changes; PM approves initial baseline in PM Plan	Develop Schedule — Planning (6.5); part of PM Plan (4.2)	The approved version of the schedule model. Activities on the Critical Path have ZERO float. Any change to the schedule baseline requires a formal CCB-approved Change Request. Used to calculate SV and SPI in EVM.
Cost Baseline (S-Curve / PMB)	PM and Cost Estimator (with team)	CCB for any changes; PM approves initial baseline in PM Plan	Determine Budget — Planning (7.3); part of PM Plan (4.2)	Cost Baseline = Work Package estimates + Contingency Reserves. Does NOT include Management Reserves. Cost Baseline + Management Reserves = Project Budget (BAC). Changes require CCB. Used to calculate CV and CPI in EVM.
Risk Management Plan	PM (with risk team and SMEs)	PM (as part of PM Plan)	Plan Risk Management — Planning (11.1)	Describes HOW risk will be managed — not the actual risks. Risk methodology, risk categories (RBS), probability/impact scales, and risk tolerance thresholds are defined here. The Risk Register is a separate document.
Risk Register	PM and team (created in Identify Risks; updated continuously)	PM (Risk Owners assigned per risk)	Identify Risks — Planning (11.2); updated throughout	Living document — updated at EVERY phase gate and whenever risks change. Contains: risk description, probability, impact, risk score, response strategy, risk owner, triggers, and residual/secondary risks. NOT the same as the Risk Management Plan.
Quality Management Plan	PM and Quality team / QA specialist	PM (as part of PM Plan)	Plan Quality Management — Planning (8.1)	Describes quality standards, metrics, and QA/QC approach. Quality STANDARDS come from the customer or regulatory bodies — PM does not set standards, PM ENSURES they are met. Gold Plating (adding features beyond requirements) is forbidden.
Resource Management Plan	PM (with functional managers in matrix orgs)	PM (as part of PM Plan)	Plan Resource Management — Planning (9.1)	Defines how resources will be acquired, managed, and released. In FUNCTIONAL orgs, the Functional Manager controls resources and the PM has limited authority. In PROJECTIZED orgs, the PM has full authority.
Communications Management Plan	PM (with stakeholder input)	PM (as part of PM Plan)	Plan Communications Management — Planning (10.1)	Defines WHO gets WHAT information, WHEN, HOW, and in what FORMAT. Poor communication is cited as the #1 cause of project failure. This plan is built from the Stakeholder Register.
Procurement Management Plan	PM with Procurement / Legal team	PM (as part of PM Plan)	Plan Procurement Management — Planning (12.1)	Defines what to make vs. buy, contract types to use, and source selection criteria. Source selection criteria must be defined BEFORE seeing seller proposals — defining them after is a PMI ethics violation.
Stakeholder Engagement Plan	PM (with team input; based on Stakeholder Register)	PM (as part of PM Plan)	Plan Stakeholder Engagement — Planning (13.2)	Different from the Stakeholder Register. The Register identifies who stakeholders are; the Engagement Plan describes the STRATEGY to move stakeholders from current to desired engagement level. Uses the Stakeholder Engagement Assessment Matrix.
Procurement Documents (SOW, RFP, RFQ, IFB)	PM with Procurement / Legal team	PM / Procurement Officer	Plan Procurement Management — Planning (12.1)	The Project SOW (Statement of Work) describes what the seller will provide. The SOW becomes part of the signed contract. RFP = unclear scope; RFQ = clear scope, need price; IFB = government sealed bid; RFI = market research only.
Change Management Plan	PM (with team)	PM (as part of PM Plan)	Develop Project Management Plan (4.2)	Describes the process for submitting, evaluating, approving, and implementing changes — including CCB composition and authority levels. This plan is what makes Integrated Change Control work.
⚙️ EXECUTING PROCESS GROUP
Deliverables (Work in progress / completed work products)	Project Team (builds/produces the deliverables)	PM (manages production); QC verifies; Customer accepts	Direct and Manage Project Work — Executing (4.3)	Flow: Team produces Deliverable → Control Quality (QC inspects) → Verified Deliverables → Validate Scope (customer review) → Accepted Deliverables. QC always runs BEFORE customer validation. Never give deliverables directly to the customer without QC.
Change Requests (Corrective, Preventive, Defect Repair, or Scope addition)	ANY stakeholder can submit (team member, PM, customer, sponsor, anyone)	CCB (Change Control Board) approves or rejects	Created in many processes; approved in Perform Integrated Change Control (4.6)	EXAM TRAP #2: The PM cannot approve their own change requests — only the CCB can. Even if the change saves money or time. Verbal approvals are NEVER acceptable — all changes must be in writing. Any stakeholder can SUBMIT; only CCB can APPROVE.
Contracts / Agreements (with sellers / vendors)	PM with Legal / Procurement team prepares the contract	Authorized Procurement / Contracting Officer (NOT the PM)	Conduct Procurements — Executing (12.2)	EXAM TRAP #3: The PM does NOT sign contracts. A legally authorized procurement/contracting officer signs on behalf of the organization. The PM negotiates and manages, but cannot legally bind the organization to a contract. This is the most-tested procurement rule.
Issue Log	PM (created when first issue occurs; team contributes)	PM (owns and updates throughout)	Direct and Manage Project Work (4.3); used across many processes	Tracks problems that have ALREADY OCCURRED (vs. Risk Register = future events). Every issue gets an owner and resolution date. When a risk materializes it moves FROM the Risk Register INTO the Issue Log.
Quality Reports	Quality team / PM	PM	Manage Quality — Executing (8.2)	Output of Manage Quality (QA process). Contains information about quality audits, process improvements, and defects found. Input to Control Quality. QA audits PROCESSES; QC inspects PRODUCTS.
Team Performance Assessments	PM (evaluates team performance against defined metrics)	PM	Develop Team — Executing (9.4); Manage Team — M&C (9.5)	PM evaluates team effectiveness: collaboration, conflict resolution, issue resolution, communications. Used to identify training needs and improve team performance. NOT the same as individual performance reviews (which may involve functional managers).
Lessons Learned Register	PM and ALL team members (captured throughout — NOT just at close)	PM (documents and updates)	Manage Project Knowledge — Executing (4.4); updated throughout; becomes OPA at Close (4.7)	EXAM TRAP #4: Lessons Learned are captured THROUGHOUT the project — at phase gates, after major events, when risks materialize. NOT only at project close. At project close, the register is transferred to the organization and becomes an OPA (Organizational Process Asset) for future projects.
📊 MONITORING & CONTROLLING PROCESS GROUP
Work Performance Reports (Status Reports, Dashboards, Forecasts)	PM (compiles and distributes)	PM	Monitor and Control Project Work — M&C (4.5); distributed via Manage Communications (10.2)	Information Flow: Raw Data (measurements) → Work Performance Information (analyzed vs baseline) → Work Performance Reports (distributed to stakeholders). PM creates the reports; Manage Communications distributes them. The PM owns the reporting process end-to-end.
Approved Change Requests	PM submits and facilitates; CCB evaluates and decides	CCB (Change Control Board) — ONLY the CCB	Perform Integrated Change Control — M&C (4.6)	After CCB approves: PM must update ALL affected plans and baselines, then manage to the NEW baseline. CCB may also include the sponsor on major changes. Rejected CRs are documented — not destroyed. Deferred CRs come back to the next CCB meeting.
Verified Deliverables	Quality Control team inspects (against quality standards)	QC / PM (internal verification before customer)	Control Quality — M&C (8.3)	QC produces Verified Deliverables = confirmed to meet requirements. These are then sent to Validate Scope for CUSTOMER acceptance. If QC finds defects → defect repair Change Request is submitted through Integrated Change Control.
Accepted Deliverables	Customer / Sponsor formally reviews verified deliverables	Customer / Sponsor (formal sign-off)	Validate Scope — M&C (5.5)	Customer FORMALLY accepts deliverables in Validate Scope. Accepted Deliverables are the primary input to Close Project or Phase. If customer rejects: submit a defect repair Change Request. EXAM TRAP: Validate Scope = Customer acceptance; Control Quality = QC inspection. QC always comes FIRST.
Change Log	PM (creates and maintains)	PM	Perform Integrated Change Control (4.6); updated throughout	Audit trail for ALL change requests — approved, rejected, and deferred. Every CR gets a unique ID and its status is tracked from submission to closure. PM closes each CR entry after implementation is confirmed.
EVM Forecasts (EAC, ETC, VAC, TCPI)	PM / Cost Control team (calculated from actual performance data)	PM (reports to sponsor and stakeholders)	Control Costs — M&C (7.4)	EAC = BAC/CPI (most common formula — assumes current efficiency continues). If EAC > BAC: negative VAC = project is projected to overrun. This may trigger a Change Request for additional budget (requires Sponsor and CCB). PM cannot unilaterally increase the budget.
🏁 CLOSING PROCESS GROUP
Final Project / Phase Report	PM (compiles final performance summary)	PM prepares; Sponsor receives and acknowledges	Close Project or Phase — Closing (4.7)	Documents final status: scope achievement, cost and schedule performance, quality results, outstanding risks and issues, and lessons learned summary. Required for ALL projects — including those terminated early.
Formal Project / Phase Acceptance (Sign-off that project is complete)	PM facilitates the closeout process and prepares the documentation	Customer and/or Sponsor formally sign	Close Project or Phase — Closing (4.7); preceded by Validate Scope (5.5)	EXAM TRAP #5: Even a TERMINATED project must be formally closed. The PM cannot simply walk away. Resources must be released, contracts closed, lessons learned captured, and documents archived — regardless of how the project ends.
Contract Closeout	PM coordinates; Procurement / Legal team executes	Authorized Procurement Officer (same officer who signed)	Control Procurements (12.3); formally closed in Close Project (4.7)	ALL contracts must be formally closed before the project can close — even if terminated early. Includes final payments, performance records, and formal closure letters. Unresolved claims go to ADR (Negotiate → Mediate → Arbitrate → Litigate).
OPA Updates (Lessons Learned, Templates, Historical Data)	PM (transfers documents to organizational repository)	PM (responsible for ensuring transfer)	Close Project or Phase — Closing (4.7)	Lessons Learned Register, final reports, templates, and project archives become OPAs. PM is responsible for ensuring this transfer happens. These OPAs improve future projects — a direct link between project close and organizational learning.

The 5 Biggest Authority Traps on the Exam:
1. PM does NOT sign the Project Charter → Sponsor does.
2. PM does NOT sign contracts → Authorized Procurement Officer does.
3. PM cannot approve change requests alone → CCB approves.
4. PM cannot access management reserves alone → Sponsor/Senior Mgmt must approve; requires a Change Request.
5. PM cannot terminate the project → Sponsor/Senior Mgmt terminates; PM must still formally CLOSE it.

✅ Who Approves What — Decision Authority Reference

Decision / Item	Who Has Authority	Rule & Exam Notes
Any change to Scope, Schedule, or Cost Baseline	CCB	ALL baseline changes require a CCB-approved Change Request — no exceptions. Not the PM alone, not the Sponsor verbally, not the customer informally. Written CR + CCB decision.
Use of Contingency Reserves	PM (within their authority)	Contingency reserves are INSIDE the cost baseline — pre-approved for identified risks. PM can draw on them without escalating. However the use must be documented and the risk register updated.
Use of Management Reserves	Sponsor / Senior Management	Management reserves are ABOVE the cost baseline — for unknown risks. PM must submit a Change Request to access them. The budget baseline itself changes when management reserves are tapped.
Corrective / Preventive Actions (within baseline)	PM	If the action stays within current baselines → PM can implement directly (no CCB needed). If the action would change a baseline → formal Change Request to CCB first.
Defect Repair	CCB (if it affects scope/schedule/cost baseline)	Defect repair is a formal type of change request — it goes through Integrated Change Control. QC identifies the defect; PM submits the repair as a CR; CCB approves; then PM implements.
Contract Changes	Both Buyer AND Seller (bilateral written agreement)	No unilateral contract changes — BOTH parties must agree in writing. PM cannot change contract terms. Must involve the same authorized procurement officers who signed the original contract.
Project Termination	Sponsor / Senior Management / Portfolio Board	The PM CANNOT terminate a project. Only the authorizing body (Sponsor or above) can terminate. After termination: PM must still formally CLOSE the project — release resources, close contracts, archive documents.
Scope Additions / Gold Plating	CCB (Change Request required)	Even customer-requested "improvements" require a formal CR. Gold Plating (PM adds extras not requested) = wrong. Scope Creep (informal additions without CR) = wrong. ALL additions need a CR approved by CCB.
Resource Assignments	PM (strong matrix/projectized) OR Functional Manager (functional/weak matrix)	In Projectized orgs: PM has full resource authority. In Functional orgs: Functional Manager controls people; PM has little resource authority. In Balanced Matrix: PM and FM negotiate.
Acceptance Criteria (defining them)	Customer / Sponsor defines in Planning	Acceptance criteria are defined by the CUSTOMER in Collect Requirements and Define Scope. PM ensures deliverables MEET them. PM does not set them unilaterally. Changing them requires a CR through CCB.
PMI Ethics Violations	PMI Ethics Review Committee	All Code of Ethics complaints and violations are handled by PMI's Ethics Review Committee — not by the PM, the company, or the Sponsor. PM must report; PMI decides. PM is responsible for reporting violations they observe.

🔄 The Complete PM Sequence: Issue / Change / Problem — Start to Close

PMI Golden Rule: Whether it is a change request, risk event, quality defect, stakeholder complaint, scope addition, or schedule slip — the PM always follows the same sequence: Assess → Document → Communicate → Submit CR → CCB Decides → Update Plans → Implement → Monitor → Close & Learn.
Skipping any step = wrong answer on the exam.

#	Action	What the PM Does	Key Documents	Exam Rule / Trap
PHASE A — DETECT & ASSESS FIRST (before any action)
1	Detect the Event	Discover the problem / change request / risk trigger through monitoring, team report, audit, or stakeholder input. Log it immediately.	Work Performance Data; Issue Log (if issue); Risk Register (if risk trigger)	Do NOT act yet. Identification ≠ action. Log it. The correct "first step" is always to assess — not to escalate, not to submit a CR.
2	Assess Full Impact	Analyze impact on ALL project constraints: scope, schedule, cost, quality, resources, and risk. Determine root cause. Quantify the change needed.	Work Performance Information; Risk Register; Issue Log; Assumption Log; Baselines	"What do you do FIRST?" = ASSESS. This is the #1 tested question type. Never communicate or escalate before you understand the full impact.
3	Check Existing Plans	Review PM Plan, Risk Register, and contingency plans. If a pre-approved contingency plan exists for this event — implement it directly (no new CR needed for pre-approved responses).	PM Plan; Risk Register; Contingency Plans (pre-approved responses)	Pre-approved contingency responses do NOT require a new change request. This is a time-saver the exam tests. If no plan exists → move to Step 4.
PHASE B — COMMUNICATE (transparent, timely)
4	Communicate to Sponsor & Stakeholders	Inform the Sponsor and key stakeholders of the situation, impact assessment, and planned next steps. Be transparent — even if the news is bad.	Work Performance Reports; Status Reports; Meeting Minutes; Emails (documented)	Hiding bad news from the Sponsor = PMI ethics violation. Communicate EARLY — even before full analysis is done. "Proactive communication" is always rewarded in PMI answers.
5	Escalate If Above PM Authority	If the issue is outside the PM's authority (budget, scope, or strategic decision) → escalate to Sponsor immediately. If it is a risk above project level → use Escalate as the risk response.	Issue Log update; Risk Register update; Escalation communication to Sponsor	Escalation is NOT failure — it is the right thing to do. Waiting too long to escalate is a common wrong answer. Escalate early; let the Sponsor decide.
PHASE C — FORMAL CHANGE REQUEST PROCESS
6	Submit Written Change Request	Create a formal written Change Request documenting: what needs to change, why, impact on all constraints, options considered, and recommended action. Any stakeholder can submit.	Change Request (CR) — formal written document; all 4 types: Corrective, Preventive, Defect Repair, Scope Update	ALL changes must be in writing. Verbal approvals are NEVER valid. Even the Sponsor's verbal "just do it" is not acceptable. Written CR protects everyone and creates an audit trail.
7	Log in Change Log	Record the CR in the Change Log with unique ID, date, description, priority, and status = Pending. Every CR is logged — even those that will be rejected.	Change Log — complete audit trail of all CRs from submission through closure	Every CR gets logged regardless of outcome. The Change Log provides an auditable history of all changes requested during the project — required for project governance.
8	CCB Review (Integrated Change Control)	PM presents the CR to the CCB. CCB evaluates impact and alternatives. CCB decides: Approve, Reject, or Defer. PM FACILITATES — PM does NOT vote or decide.	All Baseline Documents; PM Plan; Risk Register; Change Log; Perform Integrated Change Control (4.6)	PM is a SERVANT of the CCB process — not the decision-maker. The PM presents the analysis; the CCB decides. If deferred → re-submit at next CCB with updated analysis. Rejected CRs are documented, not destroyed.
9	Communicate CCB Decision	PM formally communicates the CCB's decision to ALL affected stakeholders. Approved CRs move to implementation. Rejected CRs: original plan continues; stakeholder is informed why.	Change Log (status updated to Approved/Rejected/Deferred); Stakeholder notifications; Meeting minutes	Do NOT implement a rejected CR even under stakeholder pressure. Communicate the rejection professionally. If the stakeholder disagrees, they can re-submit with additional justification.
PHASE D — IMPLEMENT (ONLY after CCB approval)
10	Update ALL Affected Plans & Baselines	Revise EVERY affected subsidiary plan and baseline. A scope change also impacts schedule, cost, resource, risk, and communications plans. Missing even one is an error.	PM Plan (all affected subsidiary plans); All 3 Baselines if changed; Risk Register; Stakeholder Engagement Plan	ALL affected plans — not just the obvious one. A scope change ripples into schedule, cost, resources, risks, and communications. The exam will test whether you update ALL or just the most obvious.
11	Update All Project Documents	Update: Risk Register (new risks from the change?), Issue Log (mark issue resolved if applicable), Assumption Log (if assumptions changed), Stakeholder Register, Lessons Learned Register	Risk Register; Issue Log; Assumption Log; Stakeholder Register; Lessons Learned Register	Document updates happen in PARALLEL with plan updates — not after. Keeping all registers current is part of every change implementation. This is ongoing — not a one-time task.
12	Re-baseline If Required	If the approved CR changes any baseline: formally re-baseline. The NEW baseline is the reference for all future EVM calculations. Future variance = actual vs. NEW baseline (not original).	New Scope Baseline; New Schedule Baseline; New Cost Baseline; Updated PMB	Re-baselining is the CORRECT and professional response to an approved change — it is NOT an admission of failure. After re-baselining, ALL EVM metrics (PV, EV, AC, CPI, SPI) use the new baseline.
13	Direct & Manage Work — Implement the Change	Execute the approved corrective/preventive action or scope change. Assign resources, update schedule, and direct the team's work to implement the approved change.	Work packages; Updated schedule; Resource assignments; Direct and Manage Project Work (4.3)	This is the ONLY step where actual project work happens. ALL steps before Step 13 are assessment, communication, and approval. Doing work before CCB approval = project risk and PMI ethics issue.
PHASE E — MONITOR, VERIFY & CLOSE THE CHANGE
14	Monitor & Control Against New Baseline	Track whether the change implementation is producing expected results. Compare actual performance to the new baselines. Check if new risks emerged from the change.	Work Performance Data → Information → Reports; Updated Risk Register; EVM Forecasts	Monitoring after a change is mandatory — do not assume the change worked. New problems may emerge (secondary risks). Keep Sponsor informed of progress against the new baseline.
15	Verify Quality of the Result	If the change produced or modified a deliverable: run Control Quality (QC inspection → Verified Deliverables), then Validate Scope (customer acceptance → Accepted Deliverables).	QC Inspection results; Quality Metrics; Verified Deliverables; Accepted Deliverables	QC verifies → Verified Deliverables → Customer validates in Validate Scope → Accepted Deliverables. Never give a modified deliverable directly to the customer without first running it through QC.
16	Document Lessons Learned	Record what happened, what worked, what did not work, and recommendations. Update the Lessons Learned Register. This must happen continuously — not just at project close.	Lessons Learned Register (updated; becomes OPA at project close)	Lessons Learned throughout the project — at EVERY significant event, not just at closing. This is one of the most tested misconceptions. Continuous capture is required by PMBOK 6.
17	Close the Change — Update Change Log	Mark the CR as CLOSED in the Change Log. Mark the Issue as RESOLVED in the Issue Log. Confirm with all affected stakeholders that the matter is fully resolved to their satisfaction.	Change Log (status = Closed); Issue Log (status = Resolved); Final stakeholder confirmation	A change is not closed until ALL affected parties confirm resolution. PM must close the loop — silence does not mean acceptance. The closed Change Log entry is part of the project's governance record.

⚡ Quick Trigger — "What Do You Do FIRST?" (Most Tested Scenarios)

Scenario	PMI Correct First Action
Stakeholder requests a new feature verbally	Ask them to submit a formal written Change Request — do NOT start work
Project is behind schedule	ASSESS full impact on cost, scope, quality, and resources — THEN determine options
Team member reports a defect in a deliverable	ASSESS scope and impact of defect → document in Issue Log → submit defect repair CR
Sponsor says "just do it" for a scope change	Explain that ALL changes require written CR and CCB approval — even Sponsor verbal approval is not valid
A risk trigger fires (risk has occurred)	Check if a pre-approved contingency plan exists → if yes, implement it → if no, assess and submit CR
Team member consistently underperforms	Address directly and privately with team member FIRST — understand root cause before escalating
Project needs additional budget above baseline	Assess if contingency reserves cover it → if not, submit CR to CCB and escalate to Sponsor for management reserves
Customer informally asks for an "improvement"	Require a formal CR — implementing informally = scope creep; adding it yourself = gold plating. Both are WRONG.
Two team members have a serious conflict	Address directly with both parties together (Collaborating/Problem Solving) — privately, not publicly
Approved change is not producing expected results	ASSESS the new situation → document → submit a NEW Change Request for further corrective action
You discover a colleague violated the PMI Code	Report it through appropriate channels to PMI's Ethics Review Committee — you CANNOT ignore it
After CCB approves a CR, next step is:	Update ALL affected plans and baselines FIRST — then implement the change against the new baseline

The 3 PMI Answer Patterns to Always ELIMINATE First:
❌ Any answer that BYPASSES formal change control ("just do it," "get verbal approval")
❌ Any answer that takes action BEFORE assessing the full impact
❌ Any answer where the PM acts UNILATERALLY on something requiring CCB, Sponsor, or Customer authority