PMP Master Study Guide — Eng. Ahmad Safi, PE

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.

🤝 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.

#	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.

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

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 of stakeholder classification:

Power — Level of authority
Urgency — Immediate attention needed
Legitimacy — Appropriateness of their involvement

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.

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

💥 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.

If asked to compress schedule and keep costs same → Fast Track. If budget is available → Crash. Both only work on critical path activities.

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

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

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

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

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

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.

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

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

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.

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.