PMP Study Guide: PMBOK 8th Edition, Practice Questions & 6th/7th Reference

📖 Study Reference

📚 Universal Inputs: Know These for Every Process OPA · EEF · Expert Judgment · PMIS · Work Performance Data/Info/Reports · Change Requests · Lessons Learned

▾

Organizational Process Assets (OPA)

Plans, processes, policies, procedures, and knowledge bases specific to and used by the performing organization. Historical information from past projects.

Examples: Lessons Learned REPOSITORY (from previous projects), templates, historical cost data, process standards, configuration management knowledge bases. Key exam trap: The Lessons Learned REGISTER is a current-project document; the Lessons Learned REPOSITORY is an OPA from previous projects.

Enterprise Environmental Factors (EEF)

Conditions not under the project team's control that influence, constrain, or direct the project. Can be internal or external to the organization.

Internal: org culture, infrastructure, resource availability, employee capability. External: market conditions, legal/regulatory requirements, industry standards (ISO), political climate. EEFs are inputs only, never outputs (except when Acquire/Develop/Manage Team updates them).

Expert Judgment

Judgment provided by any group or person with specialized education, knowledge, skill, experience, or training. The most common tool across all 49 processes.

Sources: PMO, consultants, stakeholders, other org units, SMEs, professional associations. Appears in nearly every process as a tool.

Project Management Information System (PMIS)

Tools and techniques used to gather, integrate, and disseminate project management process outputs. Part of EEF.

Includes: scheduling software (MS Project), cost systems, configuration management systems, document management, collaboration tools, dashboards. Used in executing and M&C processes.

Work Performance Data → Information → Reports

Three distinct stages of project performance data, one of the most tested sequences on the PMP exam.

DATA = raw facts collected in Direct & Manage Project Work. INFORMATION = analyzed data from Control processes (Control Scope, Control Schedule, etc.). REPORTS = compiled information sent to stakeholders, output of Monitor & Control Project Work.

PM Plan vs. Project Documents

Two distinct input categories, every process uses one or both.

PM PLAN = formal, approved, baselined, changes require approved Change Requests through CCB. PROJECT DOCUMENTS = supporting docs NOT in the PM Plan (Risk Register, Issue Log, Lessons Learned Register, Stakeholder Register, Activity List). Updated more freely, no CCB needed.

Change Requests

Formal proposals to modify any document, deliverable, or baseline. Must be processed through Perform Integrated Change Control before implementation.

Types: Corrective Action (fix current deviation), Preventive Action (prevent future deviation), Defect Repair (fix non-conforming product). Anyone can SUBMIT, only CCB or PM (within authority) can APPROVE. Approved CRs → Direct and Manage Project Work.

Lessons Learned Register vs. Repository

A critical distinction tested frequently on the PMP exam.

REGISTER = current project document (Project Document), created in Manage Project Knowledge. Updated throughout the project. At close, becomes part of OPA. REPOSITORY = OPA from PREVIOUS projects, used as input to current project processes. "Lessons learned from previous projects" in a question = OPA, not Project Documents.

🎯 General Exam Fast-Track Tips: How to Approach Every Question 5-step method · timing · question strategy

▾

📋 The 5-Step Answer Method

Step 1: Read & highlight keywords. All the information you need is in the question. Read carefully, keyword clues like "project sponsor," "team member," or "vendor" tell you who is responsible.

Use the on-screen highlighter tool heavily. Both the test-center and online exam interfaces include a highlighter. Mark the tail question, the actor (PM, team, sponsor, PO), and any tense-gate word (may/is/was) as you read. Test-takers who lean on it report cutting through "word soup" scenarios faster, because the marked-up question does some of the re-reading for you when you circle back on a flagged item.

Step 2: Determine methodology. Is the project Predictive (Waterfall), Agile, or Hybrid? This changes the correct answer entirely. Look for keywords: iterations, sprints, backlog, retrospective = Agile. WBS, baselines, CCB = Predictive.

Step 3: Identify the PMBOK principle. Decide which topic the question is testing, scope, risk, stakeholders, conflict, change control, etc.

Step 4: Eliminate wrong answers. Cross out any answer that doesn't directly address the methodology or principle you identified. Usually 1-2 options are obvious eliminations.

Step 5: Select the best remaining answer. 2-3 answers may seem correct, pick the MOST correct. The exam wants the ideal PM behaviour, not what you'd do in real life.

⏱️ Timing Strategy

240 minutes for 180 questions. Per PMI's official Exam Content Outline, that's the full allotted time for the center-based exam, roughly 1 min 20 sec per question on average, though the case-study section and the independent questions are timed as one combined pool, not split evenly. Do NOT spend more than 2 minutes on any single question.

170 scored + 10 pretest. Of the 180 total questions, 170 count toward your score and 10 are unscored pretest items PMI is validating for future exams. They're randomly mixed in and you cannot tell which is which, so treat every question as if it counts.

Flag and move on. Answer every question, even if unsure. Flag it and revisit. Future questions sometimes contain hints that help you answer flagged ones.

Two built-in 10-minute breaks: The first break comes right after the case-study section ends. The second comes roughly midway through the independent question portion that follows. Once you start a break, you cannot go back to the section before it, so make sure you're done reviewing that section before you take it.

🆕 2026 Question Formats: Know What You'll See

Case or Scenario (NEW in 2026): A detailed situation, sometimes with a chart or graph, followed by a SERIES of questions all based on that same scenario. Read the whole case first, then work through its questions, later questions in the set sometimes hinge on details you'd otherwise skim past.

Graphic-Based (NEW in 2026): You're shown a chart, diagram, or spreadsheet excerpt and asked a question that requires reading it correctly, not just recalling a formula. Slow down and confirm what the axes or columns actually represent before answering.

Enhanced Matching / Matching / Pull-down List: Drag-and-drop or dropdown-based question types, computer-based testing only. Functionally the same skill as multiple choice, match the right concept to the right slot, just a different interface.

Drag-and-drop load varies by exam form. Test-takers on the same day have reported wildly different counts of drag-and-drop and matching items, some getting eight or more, others getting none. If your form leans heavy on these, don't read it as a sign something's wrong, it's normal form variation, not a harder standard. Practice a few matching/ordering-style question sets specifically, not just standard multiple choice, so the interface itself doesn't cost you time on exam day.

Point and Click: You click directly on the correct region of an image (e.g., the point on a chart where a described condition occurs) rather than picking from listed options. Computer-based testing only.

Multiple-Choice Single vs. Multiple-Response: Single response has one correct answer among the options. Multiple-response requires selecting more than one correct option, read the instruction line carefully, since picking only one when more are required loses the point.

Cases can interleave (firsthand report): With two case studies on your form, the questions may not stay grouped. You can answer a Case 1 question, get switched to Case 2, then jump back to Case 1. The context-switching is disorienting if you expect each case to run as one clean block. Anchor yourself by re-reading which scenario a question refers to before answering, rather than assuming it continues the last one.

The fatigue is real, take every break (firsthand report): A recent test-taker missed the first break (it comes right after the case-study section), kept going, and by question 95 described it as "torturing" and nearly fell asleep. 240 minutes is long. The breaks do not cost you exam time in a way that's worth skipping. Take both, stand up, reset. A tired brain misreads the tense gate and the "understand vs act" cue, which is exactly how careless points get lost late in the exam.

📊 Understanding Your Score Report

Proficiency bands, not raw percentages. Your report shows a band per domain (People, Process, Business Environment): Above Target, Target, Needs Improvement, or Below Target. PMI does not publish the exact score cutoffs, so don't try to reverse-engineer a percentage from the band, use it only to see which domain needs the most attention on a retake.

A weak band doesn't mean you didn't know the content. It's common to score Needs Improvement or Below Target in a domain you felt solid on, especially Business Environment now that it carries more weight. That's usually a mindset-application problem, not a knowledge gap, go back to the Playbook and the reading-strategy section before re-drilling content you already know.

Some exam forms are simply harder than others. PMI draws each candidate's exam from a large question bank, so two people testing the same day can get noticeably different difficulty, including how many drag-and-drop or unfamiliar-phrasing questions they see. If it feels much harder than your mocks, that's a known, normal experience, not a sign you're underprepared. Stick to the reading strategy and keep moving.

📅 Retake Policy: Official PMI Rules

Up to 3 attempts within your 1-year eligibility period. After a fail, you're free to schedule a retake within that same eligibility window. After 3 total attempts, you must wait 1 year from your last exam date before reapplying.

If your eligibility year expires before you pass (even with fewer than 3 attempts used), you must reapply for the certification, but you are not subject to the 1-year waiting period in that case, only after exhausting all 3 attempts.

🧠 Agile Keywords to Spot Immediately

Iteration · Product Owner · Scrum Master · Retrospective · Sprint Backlog · Stand-up · MVP · Epics · Spikes · Kanban Board · Product Roadmap · User Stories · Definition of Done · Definition of Ready · Velocity · Burndown/Burnup chart

Spike (know this one): A short, time-boxed investigation the team runs to reduce uncertainty before committing to work. When a story is too unclear or too technically risky to estimate, the team does a spike, a quick research or prototyping task, to learn enough to move forward. It is about reducing uncertainty and technical risk, not producing shippable deliverables. Exam trap: if a story cannot be estimated because the team does not understand it yet, the answer is often "run a spike," not "guess an estimate" or "start building anyway." Two types: a technical spike (investigate a technical approach) and a functional spike (explore how users would interact with something).

Product Backlog & Roadmap = high level. User Stories = detailed. Both are created collaboratively with the team.

Definition of Ready: Criteria for when work can begin. Definition of Done: Criteria for when a user story or feature is complete. Both created with the team.

🎓 Common Exam Traps to Avoid

Don't escalate too fast. The exam wants you to try to solve it yourself first before going to the sponsor or management.

Don't add resources or delay. Problem-solve first. Adding people or extending schedule are last resorts.

Don't suspend the project. The ultimate goal is to deliver value, only suspend if there is no other option.

Unfamiliar terms? If the question uses terms you don't recognize (e.g. "Fishbowl window," "marginal economic analysis"), ignore the jargon and focus on the keywords and the root cause of the problem.

Vendor disputes? Always check the Contract first. The vendor is responsible for their deliverable, not you. You can help problem-solve but you don't own their scope.

👥 Accountability Rules: Who Does What

PM: Ensures work gets done. Trains and supports team members. Integrates all components. Does NOT do the work themselves.

Project Sponsor: Provides funding. Initiates project via Project Charter. Signs off and formally accepts deliverables. Escalation target for PM.

Team: Provides estimates on their own work. Performs the work. Breaks down work packages (not the PM).

Vendors: Responsible for their deliverable as outlined in the Contract. Not the PM's responsibility once contracted.

Product Owner (Agile): ONLY person who can prioritize the Product Backlog. If they refuse, train them on benefits, do NOT do it yourself.

🔄 Change Management Process (Predictive)

Can't change a baselined plan without formal change control. Any baseline change requires this process:

1. Any stakeholder raises a change → 2. Log in Change Log → 3. Analyze impact to Cost & Schedule → 4. Take to approvers (CCB) → 5. Communicate outcome (approved/rejected/deferred) → 6. Update Change Log and proceed.

Closing Process Steps: Finalize open claims → Confirm formal acceptance → Ensure transition to operations → Formally release resources → Close accounts → Final lessons learned → Archive project info → Measure product benefits.

🧮 Calculations & Formulas: EVM, PERT, Float, Channels All formulas verified against PMBOK 6th Edition

▾

📏 Estimate Types & Accuracy Ranges, Know All Four

Estimate Type	Accuracy Range	When Used	How It's Done	Key Exam Notes
Rough Order of Magnitude (ROM)	−25% to +75%	Initiating / very early project, before detailed planning	Expert judgment, analogous data from past projects, high-level assumptions	Also called a "ballpark estimate." Wide range reflects high uncertainty. Used to get initial approval or funding. NOT suitable for budgeting. If a question says "early estimate" or "feasibility" → ROM.
Budget Estimate	−10% to +25%	Early Planning, after some scope definition but before detailed WBS	Analogous or parametric estimating using partial scope information	More refined than ROM. Used to establish initial budget authorization. Still significant uncertainty. Sometimes called a "preliminary estimate." Used when sponsor needs a budget range to proceed.
Definitive Estimate	−5% to +10%	Late Planning, after detailed WBS and resource plans are complete	Bottom-up estimating from detailed work packages. Most accurate method.	Most accurate estimate type. Requires the most time and effort to produce. Used for final budget approval and cost baseline. If a question asks for the "most accurate estimate" → Definitive using Bottom-Up.
Order of Magnitude	−50% to +100%	Pre-project / concept phase, before the project is formally authorized	Very rough judgment based on similar projects or industry benchmarks	Even less precise than ROM. Used for portfolio-level decisions, "should we even consider this project?" Sometimes used interchangeably with ROM on the exam, but technically wider range. Context determines which applies.

📊 Earned Value Management (EVM), Full Reference

Term (Abbr)	What It Means	Formula	Interpretation
Budget at Completion (BAC)	The original approved total budget for the project.	No formula, it's the baseline	Your starting budget number. Never changes unless a baseline change is approved.
Planned Value (PV)	The budgeted cost of work scheduled to be done by now.	PV = Planned % Complete × BAC	What you PLANNED to have done by this point, in dollars.
Earned Value (EV)	The budgeted cost of work actually performed.	EV = Actual % Complete × BAC	What you actually ACCOMPLISHED, valued at the budgeted rate.
Actual Cost (AC)	The actual cost incurred for work performed.	No formula, actual spend	What you actually SPENT. No formula, it's measured directly.
Cost Variance (CV)	Difference between earned and actual cost.	CV = EV − AC	Positive = Under budget ✓ · Negative = Over budget ✗
Schedule Variance (SV)	Difference between earned value and planned value.	SV = EV − PV	Positive = Ahead of schedule ✓ · Negative = Behind schedule ✗
Cost Performance Index (CPI)	Rate of cost efficiency, how much value per dollar spent.	CPI = EV ÷ AC	≥ 1.0 = Under budget ✓ · < 1.0 = Over budget ✗. CPI = 0.8 means you get $0.80 of work per $1.00 spent.
Schedule Performance Index (SPI)	Rate of schedule efficiency, how much work done vs. planned.	SPI = EV ÷ PV	≥ 1.0 = Ahead of schedule ✓ · < 1.0 = Behind schedule ✗
Estimate at Completion (EAC)	Forecasted total cost at project completion based on current performance.	EAC = BAC ÷ CPI (most common) EAC = AC + ETC EAC = AC + (BAC − EV) EAC = AC + [(BAC − EV) ÷ (CPI × SPI)]	Use BAC/CPI when current inefficiency is expected to continue. Use AC+(BAC−EV) when remaining work will be done at planned rate.
Estimate to Complete (ETC)	Expected cost to finish remaining project work.	ETC = EAC − AC	How much more money is needed from today to finish the project.
Variance at Completion (VAC)	Expected over/under budget at project end.	VAC = BAC − EAC	Positive = Under budget at completion ✓ · Negative = Over budget at completion ✗
To-Complete Performance Index (TCPI)	The efficiency that must be achieved on remaining work to meet a financial goal.	TCPI = (BAC − EV) ÷ (BAC − AC) to meet BAC TCPI = (BAC − EV) ÷ (EAC − AC) to meet EAC	TCPI < 1.0 = Easier than planned ✓ · TCPI > 1.0 = Must be MORE efficient than planned ✗

📐 Other Key Formulas

Three-Point Estimating, PERT (Beta Distribution)

Program Evaluation and Review Technique

tE = (O + 4M + P) / 6

O = Optimistic, M = Most Likely, P = Pessimistic. Weights the Most Likely estimate 4× more. Used when uncertainty exists.

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

Standard Deviation (PERT)

σ = (P − O) / 6

Measures the spread/uncertainty of the estimate. The larger the difference between P and O, the more uncertain the estimate.

Example: O=8, P=14 → (14−8)/6 = 6/6 = 1.0 day standard deviation

Triangular Distribution (Simple Average)

tE = (O + M + P) / 3

Simple average of all three estimates, no weighting. Less accurate than PERT Beta but faster to calculate.

Example: O=10, M=15, P=40 → (10+15+40)/3 = 65/3 = 21.67

Communication Channels

Channels = n(n−1) / 2

n = total number of people on the project (including PM). Shows how communication complexity grows exponentially as team size increases.

4 people → 4(3)/2 = 6 channels. 10 people → 10(9)/2 = 45 channels. Team grows from 5→10: channels grow from 10→45.

Expected Monetary Value (EMV)

EMV = Probability × Impact

Used in risk analysis (Decision Tree Analysis) to quantify risk value. Threats have negative impact; opportunities have positive impact.

Risk with 25% probability and $400,000 impact → EMV = $100,000. Sum all EMVs for overall project risk exposure.

Float / Slack (Critical Path)

Float = LS − ES = LF − EF

Total Float = how much an activity can be delayed without delaying the project end date. Free Float = how much an activity can be delayed without delaying the next activity's Early Start.

Critical Path activities have 0 float. Float > 0 = scheduling flexibility. Free Float = ES(successor) − EF(activity).

Forward Pass (Early Dates)

ES = max EF of predecessors
EF = ES + Duration

Calculate left-to-right through the network. Early Start = the latest Early Finish of all predecessor activities. Early Finish = Early Start + activity duration.

First activity: ES = 0 (or 1 depending on convention). All paths feed forward to the end of the network.

Backward Pass (Late Dates)

LF = min LS of successors
LS = LF − Duration

Calculate right-to-left through the network. Late Finish = the earliest Late Start of all successor activities. Late Start = Late Finish minus duration.

Last activity: LF = EF of the last activity (project end). Work backwards to find LS and LF for every activity.

Point of Total Assumption (PTA), FPIF Contracts

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

The cost point in a Fixed Price Incentive Fee (FPIF) contract above which the seller bears ALL cost overruns. Above PTA, the buyer pays only up to the Ceiling Price, the seller absorbs everything beyond that.

Example: Target Cost=$100K, Target Price=$110K, Ceiling Price=$130K, Share Ratio=80/20 (buyer/seller). PTA = (($130K−$110K) ÷ 0.80) + $100K = $25K + $100K = $125K. Any cost above $125K is 100% seller risk.

Contract Fee Calculations (Cost-Reimbursable)

Final Fee = Target Fee + (Target Cost − Actual Cost) × Seller Share
Final Price = Actual Cost + Final Fee

Used in CPIF contracts. If the seller comes in under target cost, they earn a higher fee. If they go over, their fee is reduced. Both parties share the risk based on the agreed share ratio.

Example: Target Cost=$200K, Target Fee=$20K, Actual Cost=$180K, Share=80/20. Seller savings=$20K × 20%=$4K bonus. Final Fee=$24K. Final Price=$180K+$24K=$204K (saves buyer $16K vs target).

🗺️ Patterns & Key Documents: Question Shortcuts The Big 8 Documents · Question type patterns · Plan vs. Actual rule

▾

📄 The Big 8 Documents, What They Do & When They're the Answer

Document	What It Does	Common Exam Trigger Question
Project Charter	Formally authorizes the project. Contains high-level scope, budget, risks, and sponsor sign-off.	"Who/what authorizes the project?" · "What gives the PM authority?"
Project Management Plan	The master plan, integrates ALL subsidiary plans. Describes how the project will be executed, monitored, controlled, and closed.	"Where is the overall plan?" · "How will the project be managed?"
Project Scope Statement	Defines what IS and IS NOT in scope. Includes deliverables, acceptance criteria, and exclusions.	"What work will NOT be done?" · "What is out of scope?"
Scope Management Plan	Defines HOW scope will be managed, including how to define scope, create WBS, validate, and control scope.	"How will scope be managed?" · "How will the WBS be created?"
Work Breakdown Structure (WBS)	Hierarchical decomposition of project deliverables into work packages. Deliverable-oriented (not activity-oriented).	"Where are deliverables broken down?" · "What is the hierarchy of work?"
WBS Dictionary	Defines each WBS element in detail, description, acceptance criteria, responsible party, cost estimate, resource requirements.	"Where do I find DETAILS about a WBS element/deliverable?"
Requirements Documentation	The detailed list of all stakeholder requirements, business, functional, non-functional, transition, quality requirements.	"Where are the detailed stakeholder needs?" · "What are the full requirements?"
Stakeholder Register	List of all stakeholders with their interests, power, influence, engagement level, and contact info. Treated as confidential.	"Where is stakeholder information stored?" · "Who are the stakeholders and their roles?"

❓ Key Question Type Patterns, Quick Lookup

Question Phrase	Answer Is Usually...
"How will we do [process]?"	[Something] Management Plan
"What work will NOT be done?"	Project Scope Statement
"Where is the breakdown of deliverables?"	WBS
"Where are the DETAILS of a deliverable?"	WBS Dictionary
"Who authorizes the project?"	Project Sponsor
"Who manages the project day-to-day?"	Project Manager
"Who approves changes?"	Change Control Board (CCB)
"Lessons learned from PREVIOUS projects?"	OPA (not Project Documents)
"Who owns the product backlog?" (Agile)	Product Owner
"Where to record an unresolved concern?"	Issue Log
"Where to record a future uncertain event?"	Risk Register
"Who is affected by the project?"	Stakeholder Register

⚖️ Pattern: The Plan vs. Actual Rule (Most Important Pattern)

Question Type	Look For
"How will we do this?"	→ [Something] Management Plan
"Where do we find the ACTUAL [list/register/data]?"	→ The document itself (not a plan)
"What is excluded / not in scope?"	→ Project Scope Statement
"What are the details of [a WBS element]?"	→ WBS Dictionary
"What are the specific needs/requirements?"	→ Requirements Documentation
"What was the original budget?"	→ BAC (Budget at Completion)
"What will it cost at the end?"	→ EAC (Estimate at Completion)
"How much more do we need to spend?"	→ ETC (Estimate to Complete)

Remember: Management Plans describe HOW something will be done. The actual document (Risk Register, Issue Log, WBS, etc.) contains the REAL data. When a question asks "where do we find [specific data]?", go to the document, not the plan.

⚠️ Pattern: Risk vs. Issue vs. Change Request

Situation	What It Is	Action
Something might happen in the future	Risk	Add to Risk Register → Analyze → Plan response
Something has already happened	Issue	Add to Issue Log → Review risk response plan → Take action
A stakeholder wants something different	Change Request	Document CR → Assess impact → Submit to CCB → Await approval
A deliverable doesn't meet quality standards	Defect / Change Request	Submit Defect Repair CR → Perform Integrated Change Control
An unplanned response to an unidentified risk	Workaround	Implement workaround → Document it → Submit as Change Request

🏃 Agile & Hybrid: Key Concepts for the PMP Exam Scrum · Kanban · Hybrid · Agile mindset · How these show up on the exam

▾

How Agile shows up on the PMP exam: Per PMI's official Exam Content Outline, approximately 40% of exam items reflect predictive project management approaches, with the remaining 60% split between adaptive/agile and hybrid approaches. Even if a question is about a process from the 49-process model, the correct answer may apply agile thinking. Watch for keywords like "iteration," "sprint," "backlog," "velocity," "retrospective," and "daily standup", these signal an agile context with its own rules.

👤 Scrum: 3 Roles

Product Owner (PO) Owns and prioritizes the Product Backlog. The ONLY person who can add, remove, or reprioritize backlog items. Represents the business/customer. If a stakeholder wants a change in an agile project → direct them to the PO, not the PM.

Scrum Master (SM) Servant-leader for the team. Removes blockers, facilitates Scrum events, coaches on Scrum practices. Does NOT manage the team or assign tasks. Similar to the PM role in an agile context.

Development Team Self-organizing, cross-functional team of 3–9 people who do the actual work. They decide HOW to do the work. No sub-teams, no titles within the team. Team estimates their own work.

📅 Scrum: 5 Events (Ceremonies)

Sprint A time-boxed iteration, usually 1–4 weeks. Scope is LOCKED once it starts. No changes mid-sprint unless the PO cancels it. Each sprint produces a potentially shippable product increment.

Sprint Planning Team selects backlog items from the Product Backlog and plans the work for the upcoming sprint. Creates the Sprint Backlog. PO clarifies items; team estimates effort.

Daily Scrum (Standup) 15-minute daily check-in. Team answers: What did I do yesterday? What will I do today? Any blockers? For the TEAM, not a status report to management. Scrum Master facilitates.

Sprint Review End of sprint. Team demos the working product increment to stakeholders. Stakeholders give feedback. PO decides what goes back to the backlog. NOT a status meeting, it's about inspecting the increment.

Sprint Retrospective Team reflects on their PROCESS (not the product). What went well? What to improve? Creates actionable improvement items for the next sprint. Happens AFTER Sprint Review, BEFORE next Sprint Planning.

📋 Scrum: 3 Artifacts

Product Backlog The ordered list of everything that might be needed in the product. Owned by the PO. Never complete, evolves throughout the project. Items are called User Stories. Higher priority items are more detailed (refined).

Sprint Backlog The subset of Product Backlog items selected for the current sprint, plus the plan for delivering them. Owned by the Development Team. Updated daily. Visible to everyone.

Product Increment The sum of all completed Product Backlog items at the end of a sprint. Must meet the Definition of Done. Must be usable/shippable, even if the PO decides not to release it.

📖 Key Agile Terms to Know

User Story A short, simple description of a feature from the user's perspective. Format: "As a [user], I want [something] so that [benefit]." User stories are NOT the same as requirements documents.

Definition of Done (DoD) A shared agreement on what "complete" means for any work item. If it doesn't meet the DoD, it cannot be called done. Prevents partial or untested work from counting as complete.

Velocity The amount of work a team completes in a sprint, measured in story points. Used to forecast future sprints. Stabilizes after a few sprints, typically 3-4. Don't compare velocity between teams, it's team-specific. Formula: Velocity = Total Story Points Completed ÷ Number of Sprints. Example: a team closes 20, 24, 28, and 24 points over four sprints. Average velocity = (20+24+28+24) ÷ 4 = 24. If 96 points remain in the backlog, expect roughly 4 more sprints at that pace, a forecast, not a promise.

Story Points Relative units of effort/complexity used to estimate user stories. Not hours. A 5-point story is roughly twice as complex as a 2-point story. Team estimates collectively (Planning Poker).

Burndown Chart Shows remaining work (story points or tasks) over time in a sprint. Ideal line goes from top-left to bottom-right. If actual line is above ideal → behind schedule for the sprint.

Backlog Refinement (Grooming) Ongoing process where the PO and team review, estimate, and clarify backlog items. Happens continuously, not just at sprint boundaries. Ensures top backlog items are sprint-ready.

MVP (Minimum Viable Product) The smallest version of the product that delivers value and can be tested with real users. Used to validate assumptions before building the full product. Core agile concept.

Information Radiator / Kanban Board A visible display of project status (task board, burndown chart). Everyone can see it. Promotes transparency. Replaces lengthy status reports in agile environments.

📊 Kanban Basics

What it is A visual workflow management method. Work items move through columns (e.g., To Do → In Progress → Done). No sprints, work is pulled continuously as capacity allows.

WIP Limits (Work in Progress) Maximum number of items allowed in any column at one time. Prevents overloading. If a column hits its limit, the team must finish something before starting something new.

Pull System Team members pull work when they have capacity, rather than having work pushed to them. Reduces bottlenecks and multitasking.

Cycle Time The time a work item takes through part of the process, typically measured from when work actually starts on it to when it's done. Key metric in Kanban. Shorter cycle time = more responsive team.

Lead Time vs. Cycle Time Lead Time is the full clock: from the moment a request enters the system (e.g., added to the backlog) to the moment it's delivered. Cycle Time is a subset of that: only the active-work portion, from "started" to "done." A request can sit in the backlog for two weeks (adding to lead time) before work even begins (starting the cycle-time clock). If a stakeholder asks "how long until my request is done," they're asking about lead time, not cycle time.

Cumulative Flow Diagram (CFD) A stacked area chart showing how many items sit in each workflow column (To Do, In Progress, Done) over time. A widening band in the middle of the chart means work is piling up in that stage faster than it's being cleared, that's how a CFD visually exposes a bottleneck before it becomes a crisis.

vs. Scrum Kanban has no sprints, no fixed roles, no defined ceremonies. Better suited for teams with unpredictable or continuous work (e.g., support, ops). Scrum is better for product development with planned iterations.

📐 Backlog Hierarchy & Story Quality

Theme A broad strategic focus that groups related work together (e.g., "improve checkout conversion"). Unlike an Epic, a Theme isn't broken into user stories itself, it's a label that helps prioritize across many Epics pointed at the same goal.

Epic A large body of work too big to finish in one iteration. Gets decomposed into smaller user stories before it can enter a sprint. Epics under the same Theme are usually delivered in a meaningful order, since later stories often build on earlier ones.

User Story → Task A User Story is sized to finish inside a single sprint. A Task is a step inside that story (e.g., the story "as a shopper, I want to save items for later" might break into tasks like "add save button," "wire up storage," "write tests"). Tasks are the smallest unit tracked day to day.

INVEST A quality checklist for a well-written user story: Independent (little overlap with other stories), Negotiable (details can flex until built), Valuable (delivers something a user or customer cares about), Estimable (the team can size it), Small (fits in one sprint), Testable (there's a clear way to confirm it's done). A story failing INVEST is usually too vague or too big, slice it further.

The 3 C's Card (a short written placeholder for the story, not the full spec), Conversation (the real detail emerges through discussion between the team and the Product Owner), Confirmation (acceptance criteria that prove the story works as intended). The card is a reminder to talk, not a replacement for talking.

🔀 Hybrid Approach

What it is A blend of predictive (waterfall) and agile techniques. Some phases are planned upfront (requirements, architecture) while others are delivered iteratively (development, testing).

When to use it When some parts of the project have fixed requirements (regulatory, compliance, hardware) and other parts benefit from flexibility and iteration (software, features, UX).

PM role in hybrid The PM may manage the overall project using predictive planning while enabling teams to work in sprints. The PM focuses on governance, stakeholder alignment, and removing organizational blockers.

Exam tip Hybrid questions often ask: what do you do when a stakeholder requests a change mid-project? In predictive phases → formal Change Request. In agile phases → submit to Product Backlog via Product Owner. Know which phase you're in before answering.

🧠 Agile Exam Mindset: The Rules That Override Everything in an Agile Context

Stakeholder change request? → Send to the Product Owner to evaluate and prioritize into the backlog. Not the PM's decision.

Urgent change during a sprint? → Add to product backlog for NEXT sprint. Only the PO can cancel the current sprint if the goal is obsolete.

Who estimates work? → The Development Team. Always. Never the PM or PO alone.

Team conflict? → The Scrum Master facilitates. Team resolves it, self-organization is a core principle.

Stakeholder unhappy with progress? → Invite them to the Sprint Review. Get them engaged with working demos, not documents.

Documentation? → Working software over comprehensive documentation (Agile Manifesto). Keep it lightweight.

How to show progress? → Demo working software. Use burndown charts and Kanban boards. Not Gantt charts or status reports.

Team underperforming? → Retrospective is the place to address it. Not a management meeting. The team identifies and owns the fix.

🏢 Org Structures, Leadership & People: Heavily Tested Topics Org types · PM authority · Power · Conflict · Leadership · Tuckman · PMO · Motivation theories

▾

🏗️ Organizational Structures: PM Authority Varies

Functional Organized by department (IT, Finance, Marketing). PM has little or no authority. Resources report to functional managers. PM acts more as a coordinator or expediter. Most traditional orgs.

Weak Matrix PM role exists but authority is limited. Resources primarily report to functional managers. PM may be called "Project Coordinator." Low PM control over budget and resources.

Balanced Matrix PM and functional manager share authority roughly equally. Resources report to both. Can create conflict over priorities. PM has moderate authority and budget control.

Strong Matrix PM has significant authority. Resources report primarily to PM. PM controls budget. Closer to projectized but functional departments still exist and provide resources.

Projectized PM has full authority. Team is dedicated to and co-located on the project. Resources report directly to PM. Best for large, complex, long-term projects. Team is released at project end.

Composite / Hybrid Org Most real organizations use a mix. A projectized team may exist within a functional org. The exam may describe a scenario requiring you to identify which structure applies based on the PM's authority level.

Exam tip: "PM has difficulty getting resources" → Functional or Weak Matrix. "PM controls the budget" → Strong Matrix or Projectized. "Team members report to two managers" → any Matrix structure.

🏛️ PMO Types: 3 Levels of Control

Supportive PMO Low control. Provides templates, best practices, training, and access to lessons learned. Acts as a repository. PMs have full autonomy. Best for organizations that want consistency without centralized control.

Controlling PMO Moderate control. Requires PMs to use specific frameworks, tools, and templates. Conducts reviews and audits. PMs must comply with PMO standards but retain decision-making authority.

Directive PMO High control. Directly manages projects and assigns PMs. PMs report to the PMO. PMO is responsible for outcomes. Very centralized, most authority sits with the PMO.

Memory trick: Supportive = advises. Controlling = requires compliance. Directive = manages directly. "PMO assigns the PM to the project" → Directive. "PMO provides templates" → Supportive.

⚡ Types of Power: How PMs Influence

Formal / Legitimate Authority from your title/position. Works well in projectized orgs. Weakest when PM has no formal authority (functional org). "Do this because I'm the PM."

Reward Ability to give people things they value, bonuses, recognition, good assignments. Effective when rewards are meaningful, achievable, and within your control.

Penalty / Coercive Ability to punish or withhold rewards. Creates fear and resentment. Almost always the wrong answer in people-management exam scenarios.

Expert ⭐ Influence based on your knowledge and skill. One of the BEST types. Works in any org structure. Earns respect without needing formal authority. PMs in functional orgs rely on this heavily.

Referent ⭐ Influence based on personal charisma, trust, and relationships. Also one of the BEST types. People follow you because they like and respect you, not because they have to.

Informational Influence through control of data and information. Useful but can be misused. Hoarding information is unethical, sharing it appropriately builds trust.

Persuasive Convincing others through logical arguments and compelling reasoning. A soft power type used frequently in stakeholder management.

Best on exam: Expert and Referent. Worst: Penalty/Coercive. "PM in matrix org with no formal authority, what type of power should they use?" → Expert or Referent.

🤝 Conflict Resolution: Best to Worst

1. Collaborate / Problem Solve ⭐ BEST Both parties work together to find a solution that fully satisfies everyone. Win-win. Takes time but creates lasting resolution. Always the first choice on the exam.

2. Compromise / Reconcile Each party gives something up. Lose-lose but balanced. Neither party fully satisfied but both can accept the outcome. Use when collaboration isn't possible.

3. Smooth / Accommodate Emphasize agreement, downplay disagreement. Preserves relationship temporarily but doesn't resolve the issue. Conflict will resurface.

4. Force / Direct One person imposes their will. Win-lose. Quick but damages trust. Only use in emergencies when a decision absolutely must be made immediately.

5. Withdraw / Avoid ❌ WORST Walk away and hope it resolves itself. It almost never does. Conflict festers. Almost always the wrong answer on the exam.

Exam trap: "The PM smoothed over the conflict, what should they have done?" → Collaborate. "A conflict keeps coming back" → originally resolved with Smooth or Avoid. Need to Collaborate properly this time.

👑 Leadership Styles

Servant Leadership ⭐ Focus on serving the team. Remove blockers, provide resources, protect from interference. The default style the exam expects in most scenarios, especially agile.

Transformational Inspires through vision. Encourages innovation and growth. Best for teams needing motivation or during organizational change.

Transactional Goals + rewards for performance + consequences for failure. Works for routine, well-defined tasks. Less effective for creative or complex work.

Democratic / Participative Involves team in decisions. Builds ownership and buy-in. Best for experienced teams. Takes longer but produces better commitment.

Laissez-faire Hands-off. Team has full autonomy. Only appropriate for highly experienced, self-directed teams. Usually the wrong answer, looks like the PM is absent.

Autocratic / Directive PM decides alone and directs. Only appropriate in emergencies or with brand new teams needing clear direction. Generally wrong in collaborative exam scenarios.

Default on exam: Servant Leadership (agile), Transformational (change/vision), Transactional (routine tasks). "PM is not involving the team in decisions" → autocratic → wrong behavior.

📈 Tuckman's Team Development Stages

Forming First meeting. Polite, cautious, uncertain about roles. PM should provide clear direction and set expectations. PM role is most directive here.

Storming Conflict emerges. Personalities clash. Trust not yet built. Productivity drops. PM should facilitate conflict resolution and keep team focused. Most difficult stage.

Norming Conflict resolves. Norms established. Trust builds. Cohesion and productivity improve. PM should step back and encourage collaboration.

Performing Team is highly functional and self-organizing. Little PM intervention needed. PM focuses on removing blockers and delegating. The goal of every team.

Adjourning Project ends. Team disperses. Can be emotional. PM should celebrate success, capture lessons learned, and help members transition. Also called "Mourning."

Exam tip: "Team is arguing about roles" → Storming. "Team works independently without PM guidance" → Performing. New team member joins mid-project → may regress to Forming/Storming temporarily.

💡 Motivation Theories

Maslow's Hierarchy Bottom to top: Physiological → Safety → Social/Belonging → Esteem → Self-Actualization. People must satisfy lower needs before higher ones motivate them. A team member worried about job security won't be motivated by recognition.

Herzberg's Two-Factor Hygiene Factors (salary, job security, work conditions) prevent dissatisfaction but do NOT motivate. Motivators (achievement, recognition, responsibility, growth) actually drive performance. Fixing a salary issue removes dissatisfaction, it doesn't create motivation.

McGregor's Theory X / Y Theory X: people are lazy, need supervision and threats. Theory Y: people are self-motivated and seek responsibility. The exam strongly favors Theory Y, aligns with servant leadership and agile.

McClelland's Theory of Needs People are motivated by varying levels of: Achievement (nAch, driven by accomplishment), Power (nPow, driven by influence), Affiliation (nAff, driven by relationships). Managers tend to be high nPow.

Vroom's Expectancy Theory Motivation = Expectancy (can I do it?) × Instrumentality (will it lead to reward?) × Valence (do I value the reward?). If any factor = 0, motivation = 0. The reward must be achievable, linked to performance, and valued.

Exam traps: "PM gave bonuses but morale didn't improve" → Herzberg (salary is a hygiene factor, not a motivator). "Team member isn't motivated because they don't think the reward is achievable" → Vroom Expectancy Theory.

📊 Stakeholder Engagement Levels

Unaware Doesn't know the project exists. First step: make them aware before trying to engage.

Resistant Aware but actively opposed. May try to block or undermine the project. Must be engaged directly, never ignored. Understand their concerns and address them.

Neutral Aware but neither for nor against. Not helping or hurting. Goal: move toward Supportive through information and involvement.

Supportive Aware and actively in favor. Wants the project to succeed and will help when asked. Target state for most stakeholders.

Leading Fully engaged and actively promoting the project. Acts as a champion. Ideal for key stakeholders like sponsors. Highest level.

Stakeholder Engagement Assessment Matrix: Maps Current (C) vs. Desired (D) engagement level per stakeholder. The gap between C and D drives your engagement strategy. Sponsor should always be Leading. Key stakeholders = Supportive minimum.

📘 PMBOK 7th Edition: 12 Principles & 8 Performance Domains The principles-based model, both 6th and 7th Ed thinking is tested on the current PMP exam

▾

Why PMBOK 7 matters for the PMP exam: The current PMP exam blends PMBOK 6 process knowledge with PMBOK 7 principles-based thinking. Scenario questions test whether you're thinking in alignment with value delivery, stakeholder engagement, systems thinking, and tailoring. PMBOK 7 is the WHY and MINDSET. PMBOK 6 is the WHAT and HOW.

📐 The 12 Project Management Principles (PMBOK 7)

Principles 1–4: Foundation

1. Stewardship Act with integrity, care, and trustworthiness. Consider the broader impact of decisions on the organization, society, and environment. Think beyond just delivering the project.

2. Team Create a collaborative environment. Build accountability, mutual respect, and shared ownership. The team is your most important resource, not tools or processes.

3. Stakeholders Engage stakeholders proactively and continuously. Understand their needs and concerns. Stakeholder engagement is ongoing, not a one-time activity.

4. Value Focus on delivering value, not just completing work. Outcomes matter more than outputs. Continually evaluate whether the project is on track to deliver the intended business value.

Principles 5–8: Execution

5. Systems Thinking Think holistically. Projects exist within larger systems. Changes in one area ripple through others. Understand how your project affects the broader organizational and market environment.

6. Leadership Anyone can lead. Leadership is not about title. Motivate, inspire, and support rather than command and control. Adapt your style to what the team and situation needs.

7. Tailoring Adapt your approach to fit the situation. No one-size-fits-all methodology. Choose the right blend of predictive, agile, and hybrid based on context, team, stakeholders, and constraints.

8. Quality Build quality in from the start. Quality applies to both processes and products. Prevention is always cheaper than correction. A focus on quality reduces rework, waste, and cost.

Principles 9–12: Outcomes

9. Complexity Navigate complexity with awareness. Complex projects have many interdependencies and emergent behaviors. Use systems thinking and adaptive approaches rather than rigid plans.

10. Risk Proactively address risks and opportunities continuously. Risk management is ongoing, not a one-time exercise. Both threats and opportunities deserve attention.

11. Adaptability & Resiliency Build the ability to pivot when circumstances change. Resiliency means absorbing disruption and recovering quickly. Embrace change as an opportunity, not a failure.

12. Change Projects exist to create change. Help stakeholders transition from current state to desired future state. The human side of change, adoption and behavior, matters as much as the deliverable.

🎯 The 8 Performance Domains (PMBOK 7)

Performance Domains are NOT sequential steps, they run simultaneously throughout the entire project. Think of them as ongoing lenses you apply continuously. They replace Knowledge Areas in PMBOK 7.

1. Stakeholders

Continuously identify, analyze, and engage stakeholders. Build trust and manage expectations throughout.

Outcome: Stakeholders are actively engaged and support the project direction.

2. Team

Foster high-performing team culture. Develop team members, resolve conflicts, build trust, create psychological safety.

Outcome: A collaborative, self-organizing, motivated team that delivers results together.

3. Development Approach & Life Cycle

Choose and tailor the right development approach (predictive, agile, hybrid) for the project context.

Outcome: The chosen approach optimizes value delivery and fits the project situation.

4. Planning

Plan enough to be useful, not so much that planning becomes the work. Planning is iterative and adapts as the project evolves.

Outcome: Plans that are realistic, useful, and flexible enough to accommodate change.

5. Project Work

Manage resources, procurement, communications, and day-to-day operations. Keep the engine running while navigating uncertainty.

Outcome: Efficient, sustainable operations that let the team focus on delivering value.

6. Delivery

Ensure the project delivers intended scope, quality, and value. Outcomes (benefits realized) matter more than outputs (deliverables produced).

Outcome: Deliverables that meet requirements and generate the intended business benefits.

7. Measurement

Establish meaningful metrics to assess project health. Measure what matters. Use data to make decisions, not just to report status.

Outcome: Reliable understanding of project status with data-driven decisions.

8. Uncertainty

Identify, assess, and respond to risk, ambiguity, and complexity throughout. Build resilience and adaptability into the approach.

Outcome: The team can absorb disruption, pivot when needed, and continue delivering value.

PMBOK 6 vs. 7: PMBOK 6 = process-based (49 processes, 5 process groups, 10 knowledge areas, ITTOs), prescriptive. PMBOK 7 = principles-based (12 principles, 8 performance domains), outcome-focused, methodology-agnostic. Both are tested on the current exam. PMBOK 8th Edition (6 principles, 7 performance domains, 38 processes) applies to exams from July 9, 2026, see the 8th Edition tab above.

📝 Contract Types: Procurement & Risk Allocation FFP · FPIF · FP-EPA · CPFF · CPPC · CPIF · T&M, who bears the risk and when to use each

▾

Core rule: More defined scope = more risk the SELLER can accept (Fixed Price). Less defined scope = more risk the BUYER must accept (Cost-Reimbursable). T&M is a hybrid, for short, undefined work. Contract type questions appear frequently on the PMP exam.

Type	Full Name	Risk	When to Use	Key Exam Notes
FFP	Firm Fixed Price	Seller	Well-defined stable scope. Most common type.	Seller absorbs cost overruns. Buyer knows total cost upfront. Most preferred by buyers. Seller motivated to be efficient.
FPIF	Fixed Price Incentive Fee	Mostly Seller	Well-defined scope + want to incentivize performance. Has target cost, target fee, ceiling price, share ratio.	Above the PTA (Point of Total Assumption), seller bears 100% of overruns. PTA = ((Ceiling − Target Price) ÷ Buyer Share Ratio) + Target Cost.
FP-EPA	Fixed Price w/ Economic Price Adjustment	Mostly Seller	Long-term contracts where inflation could affect costs.	Price adjustments pre-defined based on index (CPI, labor rates). Protects seller from economic changes while giving buyer cost predictability.
CPFF	Cost Plus Fixed Fee	Buyer	Scope not well-defined. Seller reimbursed all costs plus a fixed fee that doesn't change with performance.	Seller has little incentive to control costs, gets paid regardless. Fixed fee only changes if scope changes. Buyer takes full cost risk.
CPPC	Cost Plus % of Cost	Buyer (ALL risk)	Rarely used. Seller reimbursed for costs plus a % of actual costs as fee.	Seller is incentivized to INCREASE costs (higher costs = higher fee). WORST contract type for the buyer. Illegal in US government contracts. Almost always the wrong answer.
CPIF	Cost Plus Incentive Fee	Mostly Buyer	Undefined scope where you want to incentivize cost efficiency. Both parties share overruns/savings via share ratio.	Seller beats target cost → both share savings (seller gets higher fee). Seller exceeds → both share overrun (seller gets lower fee). Fee has min/max bounds. Better than CPFF for buyer.
T&M	Time and Material	Shared	Scope undefined. Short-term work, staff augmentation, or when needing to start immediately.	Fixed rate per hour + reimbursed materials. No incentive to finish quickly. Usually has a "not-to-exceed" clause. Common for consulting. Hybrid of FP and CR.

Risk Spectrum (Most Seller → Most Buyer Risk)

FFP → FPIF → FP-EPA → T&M → CPIF → CPFF → CPPC
More defined scope = left. Less defined = right.

Procurement Documents

RFI = gather market info (no commitment). RFQ = price-based (commodities). RFP = full solution + price (complex work). IFB = government price-based bids.

RFP is most common on the exam for complex procurements. Use RFI first when you don't know what the market offers.

Claims & Disputes (Control Procurements)

Disagreements between buyer and seller on contract terms or compensation are called claims, disputes, or constructive changes.

Resolution order: Negotiation (preferred) → Mediation/ADR → Arbitration → Litigation (last resort). The contract should specify the dispute resolution method upfront.

🔄 Project Life Cycle Types & Development Approaches Predictive · Iterative · Incremental · Adaptive · Hybrid, when to use each

▾

Predictive (Waterfall)

Scope, schedule, and cost defined upfront. Sequential phases. Changes tightly controlled via CCB. Best when requirements are stable.

Use when: Requirements are well-known and stable. Regulatory compliance required. Fixed price contract. Examples: construction, manufacturing, compliance projects.

Iterative

Scope defined early but product is refined through repeated cycles. Each iteration improves on the previous one. Good when learning and refinement are key.

Use when: Requirements not fully clear but overall scope is understood. Product needs rounds of refinement. Example: software prototyping, design projects.

Incremental

Divided into smaller pieces. Each increment delivers a usable portion of the final product. Scope defined upfront but delivered in slices.

Use when: Stakeholders want to use parts of the product before it's complete. Large systems deployed in stages. Example: phased software rollout.

Adaptive (Agile)

Scope evolves through collaboration. Short iterations deliver working product frequently. Requirements refined continuously. Change is expected and welcomed.

Use when: Requirements uncertain or rapidly changing. Customer needs frequent feedback. Innovation required. Team is experienced and self-organizing.

Hybrid

Combines predictive and adaptive. Some phases use waterfall (requirements, compliance), others use agile (development, UX). Tailored to the project context.

Use when: Part of the project has fixed regulatory requirements, other parts benefit from flexibility. Hardware + software combined. Most large real-world projects.

Choosing the Right Approach

Based on: degree of requirement uncertainty, rate of change, need for early value delivery, team experience, regulatory constraints, stakeholder availability for feedback.

"Requirements unclear and changing" → Adaptive. "Regulatory compliance, fixed deliverables" → Predictive. "Some parts fixed, some flexible" → Hybrid. PMBOK 7 emphasizes tailoring to the situation.

Factor	Predictive	Iterative / Incremental	Adaptive (Agile)
Requirements	Fixed upfront	Partially defined, refined over time	Emergent, evolve continuously
Deliverables	One final delivery	Multiple refined versions	Frequent small working deliveries
Change	Tightly controlled via CCB	Expected, managed per iteration	Welcomed, prioritized by Product Owner
Customer Involvement	At start and end	At iteration boundaries	Continuous throughout the project
Risk Exposure	High, problems discovered late	Moderate, discovered per iteration	Low, discovered early via rapid feedback
Documentation	Heavy and formal	Moderate	Lightweight, just enough
Team Structure	Specialized roles, PM directs	Cross-functional teams	Self-organizing, cross-functional

📊 Charts & Graphs: What Each One Is For Gantt · Network Diagram · Control Chart · Pareto · Fishbone · Burndown · Tornado

▾

Gantt Chart

A horizontal bar chart showing each activity's start and end date along a timeline. The single most common way to visualize a schedule.

Exam trap: a Gantt chart shows duration and overlap clearly but does not show dependency logic well, that's what a network diagram is for.

Network Diagram (PDM)

Boxes connected by arrows showing how activities depend on each other. Used to find the critical path, the longest dependent chain through the project.

Precedence Diagramming Method (PDM) is the standard notation. Critical path activities have zero float, delaying any of them delays the whole project.

Milestone Chart

Shows only major milestones (diamonds) on a timeline with no duration or task detail. Built for executives who want the headline dates, not the mechanics.

S-Curve

Plots cumulative cost or progress against time. Named for its shape: slow start, steep middle, flattening finish. The standard way to visualize EV, PV, and AC together over the life of the project.

Control Chart

Plots a process's results over time against upper and lower control limits, with a centerline. Used to judge whether a process is stable or producing unpredictable results.

The "rule of seven": seven consecutive points on the same side of the mean signals a non-random pattern, an out-of-control process, even if every point is technically within the limits.

Histogram

A bar chart showing how often different values occur, the frequency distribution of a data set. Used to spot where most defects or delays cluster.

Pareto Chart

A histogram sorted largest to smallest, with a cumulative percentage line overlaid. Built around the 80/20 rule: roughly 80% of problems usually trace back to 20% of causes.

Use it to decide which defect category to fix first, the tallest bars give the biggest return on effort.

Scatter Diagram

Plots two variables against each other to reveal whether they're correlated, for example hours of testing versus defects found. A tight diagonal pattern suggests a real relationship.

Fishbone (Ishikawa) Diagram

A cause-and-effect diagram shaped like a fish skeleton: the problem sits at the head, and major cause categories branch off the spine. Used to organize root cause analysis.

Burndown / Burnup Chart

Agile tools tracking work over a sprint or release. A burndown shows remaining work trending toward zero. A burnup shows completed work trending up toward total scope, and makes scope changes visible as the total-scope line itself moves.

Exam trap: if scope keeps changing, a burnup chart tells the real story better than a burndown, since burndown alone can hide scope growth.

Probability/Impact Matrix

A grid plotting each risk's likelihood against its severity. Risks landing in the high/high corner get prioritized for an active response; low/low risks may just get watched.

Tornado Diagram

A type of sensitivity analysis: horizontal bars ranked widest to narrowest, showing which variables have the biggest impact on an outcome like total cost. The widest bar at the top creates the tornado shape.

📂 Knowledge Areas, 49 Processes

This is the exam edition. All PMP exams from July 9, 2026 test the PMBOK 8th Edition. The notes below are an original study summary written in plain language, not a reproduction of PMI's copyrighted guide. The Exam Content Outline (ECO) remains the authoritative exam blueprint, so always confirm details against the official PMBOK Guide and the current ECO. The 6th/7th tab stays available as a reference, since the formulas, agile concepts, and many process fundamentals carry straight over.

Your Study Path

Start Here, this guide isn't meant to be read top to bottom

Everything below is reference material, built to be jumped around and searched, not read start to finish in page order. Here's the order that actually works, do Step 1 first, then keep the rest as a lookup you return to, and circle back to Step 1 repeatedly as exam day gets close.

The Playbook (aka Mindset) read this in full before anything else, then come back to it constantly. This is the single highest-leverage section in the guide, especially if you have real-world PM experience you'll be tempted to answer from instead.

6 Principles & 7 Domains the framework everything else hangs off of, including PMI's own official 3-dimension mindset model (Proactive, Ownership, Value-Driven).

How to Read the Question the mechanical test-taking rules (tense gate, act vs. understand, EVM signs) that turn Playbook knowledge into correct answers under time pressure.

Worked Scenarios watch the Playbook and the reading strategy actually get applied to real questions, step by step.

Process reference & Artifact Register use these as a lookup when a term or process trips you up, not as something to memorize front to back in one sitting.

The Gauntlet practice questions. Read every explanation, right or wrong; the explanations teach the reasoning pattern, not just the answer.

The night before and the morning of your exam: skip everything else and re-read Step 1. That's the section people who've failed keep saying, in hindsight, they underweighted.

🧠 The Playbook (also known as: Mindset) How to think like the exam expects, both predictive and agile scenarios

▾

Read this first, and come back to it often, especially the week of and the morning of your exam. If you have years of real project management experience, this section matters more for you, not less. Practitioners with a decade-plus of real-world experience consistently report failing not because they didn't know the material, but because they answered from what actually works on the job instead of what PMI's idealized world expects: assess before acting, communicate before escalating, collaborate before directing, follow the formal process even when a shortcut is obviously faster in real life. On exam day, deliberately set aside "what I'd actually do" and ask "what does PMI want the ideal PM to do here." That's what this entire section trains.

🎯 If You Already Have Real PM Experience, Read This Group First

Trap: inventing complexity the question never stated. Years of real projects going sideways trains you to imagine every complication that could be lurking behind a scenario. The exam wants the opposite: take the stem at face value. If it doesn't mention a budget constraint, a difficult stakeholder, or a hidden political angle, don't assume one. Answer the scenario that's actually written, not the messier one your experience expects.

Trap: assuming you can skip process taxonomy because you "just do the work." After years on the job, you stop consciously labeling what you're doing as "Plan Quality Management" versus "Manage Quality", you just do quality work. The exam still tests the taxonomy: which named process a scenario belongs to, and roughly when in the project it happens. Knowing the outcome isn't the same as knowing the label, and the exam asks for the label.

Translation exercise: take three recent real decisions you made on a project and, for each, ask: which PMI process or knowledge area does this map to, and what sequence would PMI say comes first? Running a kickoff meeting maps to chartering and early stakeholder identification. Sending a status update maps to monitoring and controlling. Handling a scope dispute maps to integrated change control. Wherever your actual steps differ from PMI's preferred sequence, you've found a real gap worth studying, not a knowledge gap but a sequence gap.

Self-diagnostic for Gauntlet misses: for every practice question you get wrong, write down two things: what you instinctively would have picked based on real experience, and what the PMI-preferred answer actually was. After 30-50 questions, look for a pattern. Most experienced PMs find that two or three recurring real-world habits, like skipping a written change request because "everyone already agreed verbally," or routing around a slow procurement process, account for the majority of their misses. Once you can name the habit, it's much easier to catch yourself overriding it on exam day.

🔍 Problem-Solving & Investigation (Traditional)

1. Investigate before acting. Never implement or escalate immediately. Perform root-cause analysis, talk to team members privately, or review the relevant management plan first.

2. Review existing baselines first. Before proposing a fix, check the PM Plan, risk register, or issue log, the scenario may already be anticipated.

3. Risk vs. Issue. Might happen = Risk → update Risk Register. Already happened = Issue → update Issue Log and review the Risk Response Plan.

4. Proactive over reactive. Choose answers where the PM identifies risks and engages stakeholders early rather than reacting to a crisis.

5. Don't delegate your core job. Exhaust all options to resolve issues at your level first. Do not ask the sponsor, HR, or executives to handle conflicts for you.

6. Only escalate to sponsor when necessary. Go to the sponsor only for formal budget approvals, scope baseline modifications, or issues that truly exceed your authority, and always bring analyzed data and solutions.

7. Identify the methodology first. Before selecting an answer, determine if the question is Predictive, Agile, or Hybrid, each has different rules.

8. Never act without a plan. Do not take any significant action before creating or reviewing a plan. Every response should be grounded in what the PM Plan or relevant subsidiary plan says.

9. Your main job is integration. Do not concentrate time and effort on one area while ignoring others. The PM is an integrator of scope, schedule, cost, quality, resources, communications, risk, procurement, and stakeholders, all at once.

10. Final decisions must benefit project objectives. When there are conflicting methods or approaches, always choose the one that delivers the most value to the project outcome, not the easiest or fastest option.

11. Use inclusive tools. Favor tools that involve the whole team, like a whiteboard and markers, over complex software that creates barriers to participation.

👥 People Management & Servant Leadership (Traditional)

12. Lead as a servant. Remove blockers, facilitate communication, protect the team from external distractions. Don't command or dictate.

13. Enforce psychological safety. Prioritize answers that build a safe environment for open disagreement and collaboration over top-down decisions.

14. Resolve conflicts privately first. Before resolving a conflict, understand the SOURCE of it. Encourage team members to resolve it themselves. If you step in, address them privately, always aim for a win-win (Collaborate/Problem Solve). Resolve for the benefit of project objectives, not to satisfy one person over another.

15. Address performance privately. Never fire, publicly embarrass, or complain about a team member to their manager. Coach and mentor privately first.

16. Empower the team. The team estimates the work and determines the technical approach. The best people to break down work AND to determine when activities should happen is the project team. The PM facilitates, does not dictate.

17. No overtime or corner-cutting. Reject answers that suggest forcing late hours, weekend work, or bypassing quality checks to meet a deadline.

18. Share recognition jointly. Recognize team achievements frequently and include the entire team in celebrations.

19. Use emotional intelligence. Analyze your own feelings and those around you to respond to stakeholder and team needs more effectively. Emotional intelligence allows you to solve problems quicker and build trust.

20. Consult the team before deciding. The project team will have a more practical approach. Include them in decisions that affect their work.

📐 Scope, Change & Quality (Traditional)

21. Strict formal change control. Any change to a baseline must go through a formal Change Request. Never implement a change just because a stakeholder asks. All change requests must be reviewed and assessed.

22. Assess scope changes holistically. All scope changes should be evaluated for impact on ALL other areas: schedule, cost, quality, resources, communications, risk, procurement, and stakeholder engagement.

23. Follow the exact CR sequence. Document → Assess impact → Present to CCB → Await approval → Update PM Plan → Implement.

24. Verify schedule logic. Every dependency, logic tie, and critical path calculation must be deliberately verified, not guessed.

25. Spend money to save time. On the critical path, it's generally preferred to crash or fast-track (spend more) rather than delay the delivery date.

26. Define quality early and check often. Quality requirements should be defined at the start of the project and verified regularly, not just at the end.

27. Customers verify scope and quality. The customer is the best person to check a deliverable for scope conformance and quality requirements being met, they are the ones who will actually use the product. This is Validate Scope.

28. Use bottom-up estimating. When estimating, use bottom-up (detail first, then roll up) rather than top-down. It takes more time but produces more accurate estimates.

⚠️ Risk, Procurement & Stakeholders (Traditional)

29. Identify risk early and often. Identify as much risk as possible as early as possible. All identified risks, both threats and opportunities, should be documented in the Risk Register with corresponding responses.

30. Negative risk = threat. Positive risk = opportunity. Risk management covers both. Ensure responses are planned for opportunities just as much as threats.

31. Choose mutually beneficial contracts. When selecting a contract type, always choose one that is mutually beneficial to both seller and buyer, in service of the overall project objectives.

32. Engage stakeholders often and regularly. Use meetings, one-on-one conversations, phone calls, and presentations. Don't wait for stakeholders to come to you.

33. Tailor communications to each stakeholder. Before sending communications, analyze stakeholder needs: what do they need, how often, in what format, and who delivers it. Ensure they understand what they receive.

34. Keep stakeholders engaged. If a stakeholder is resistant or disengaged, review the Stakeholder Engagement Plan, meet with them, understand their concerns, and update your communication strategy.

35. Never hide bad news. Report variances, delays, and risks transparently, always with an impact analysis and a remediation plan.

🔒 Closing & Lessons Learned (Traditional)

36. Update lessons learned throughout the project. Don't wait until the end. Update the Lessons Learned Register continuously so knowledge can be transferred to future projects in the organization.

37. Close every phase formally. Always obtain formal sign-off, release resources, ensure all bills are paid, archive lessons learned, and transfer deliverables, even if the project was terminated prematurely.

38. Terminated projects still need formal closure. Projects that end early must still go through the Close Project or Phase process. Skipping closure is never acceptable.

39. Business value over compliance. Always evaluate choices based on delivering the highest business value to the customer, not just checking boxes in a document.

🏃 Agile: Servant Leadership & Team

A1. Be a servant leader at all times. Empower the team and remove impediments. Give them the tools they need to succeed while staying out of their way. Be a central figure, not a dictator.

A2. Product Owner owns the backlog, always. Only the PO can prioritize features in the product backlog. If the PO refuses to prioritize (feeling all items are equally valuable), train them on the benefits of doing so. Do NOT prioritize yourself.

A3. Never disrupt a sprint. Once a sprint starts, scope is locked. New requests go to the product backlog for the next sprint, unless the PO cancels the sprint entirely because the goal is no longer valid.

A4. Let the team solve problems. Any problem that occurs should be resolved by the project team. Let them choose the solution while you coach and support. Do not impose solutions.

A5. Provide psychological safety. Create a safe environment for disagreements. Do not punish anyone for a difference of opinion. Understand that conflict in agile is a positive, healthy step and an opportunity to learn.

A6. Understand what motivates each team member. People are motivated differently. Learn what drives each person and use that knowledge to support their performance and wellbeing.

A7. Have good ethical values. Transparency, honesty, and integrity are core to the agile mindset. Do not cut corners or hide problems.

A8. Make success and failure criteria clear. Ensure the team understands the Definition of Done, what success looks like, and what failure looks like, before the sprint starts.

📊 Agile: Communication & Visibility

A9. Face-to-face is best. Face-to-face communication with a whiteboard and markers is the most effective form of communication in agile. Use co-location wherever possible.

A10. Radiate information visually. Use large charts, graphs, burnup/burndown charts, and Kanban boards to make project status visible to everyone on the team at all times. Prefer physical boards (whiteboard) over digital monitors where possible.

A11. Limit work in progress (WIP). Use Kanban to limit WIP. When a column hits its limit, the team must finish something before starting something new. Prevents overloading and bottlenecks.

A12. Deliver value early via demos. Deliver working software or prototypes at the end of every iteration. Use MVPs to validate assumptions, reveal risks, and gather rapid feedback.

A12b. Use a spike to resolve uncertainty. A spike is a short, time-boxed investigation the team runs when a story is too unclear or too technically risky to estimate. Instead of guessing, the team does a quick research or prototyping task to learn enough to move forward. Its purpose is reducing uncertainty and technical risk, not producing shippable work. Exam trap: when a story cannot be estimated because the team does not yet understand it, the answer is often "run a spike," not "guess an estimate" or "start building." Two types: a technical spike (investigate an approach) and a functional spike (explore how users would interact). On charts, a "spike" can also mean a sudden jump in the data, for example on a run chart or cumulative flow diagram, so read which sense the question intends.

A12c. Prioritize with MoSCoW or Kano. MoSCoW sorts backlog items into Must have, Should have, Could have, and Won't have (this time), a fast way to force ranking when everything feels critical. Kano classifies features by customer reaction: basic expectations (their absence angers, their presence goes unnoticed), performance features (more is better), and delighters (unexpected joy). Exam cue: "the product owner cannot decide what goes in the release" points at a prioritization technique, not at the PM deciding for them.

A12d. Estimate as a group, improve as a cycle. Wideband Delphi is group estimating through anonymous rounds that converge on consensus, killing anchoring and boss-bias. Planning poker is its familiar cousin, and affinity estimation does the same job faster by grouping stories into relative size buckets. Kaizen is the culture of small continuous improvement, and PDCA (Plan, Do, Check, Act) is its engine: plan the change, try it small, verify it worked, then standardize it. Exam cue: "the team wants to improve its process" rarely means a big-bang overhaul; it means the retrospective feeding small PDCA cycles.

A13. Lightweight documentation. Working software over comprehensive documentation (Agile Manifesto). Avoid heavy formal plan updates. Prefer sprint backlog, user stories, and information radiators.

A14. Consistently re-communicate the project vision. Regularly remind the team WHY they are doing the work. A shared vision keeps the team aligned and motivated.

🔄 Agile: Continuous Improvement

A15. Run retrospectives. After every sprint, review how the work was completed, not what was delivered. What went well? What should change? Create actionable improvement items for the next sprint.

A16. Use feedback loops. After completing a task, take what you learned and apply it to the next task or sprint. Feedback loops are the engine of continuous improvement in agile.

A17. Identify methodology first. Before answering any agile exam question, confirm it's an agile context. Agile rules override traditional rules in an agile scenario, different answers apply.

📖 8th Edition Study Reference

🔄 What Changed from 6th/7th to 8th

▾

Aspect

6th / 7th Edition

8th Edition

Core structure

6th: 49 processes, 5 process groups, 10 knowledge areas. 7th: 12 principles, 8 performance domains.

6 principles, 7 performance domains (Governance, Scope, Schedule, Finance, Stakeholders, Resources, Risk), and 5 Focus Areas describing when work happens across the project life cycle.

Philosophy

6th was prescriptive and process-heavy. 7th swung to high-level principles and outcomes.

A deliberate blend: keeps principle-based thinking but restores the practical "how to" structure many practitioners missed.

Process style

Each of the 49 processes had its own fixed Inputs, Tools, and Outputs list, repeated process by process.

Named processes live inside the 7 performance domains. Inputs/outputs and tools/techniques are now catalogued once each, alphabetically, and reused in context rather than repeated per process.

New emphasis

Limited coverage of AI; quality and sourcing treated as separate Knowledge Areas.

AI as a cross-cutting support tool, sustainability as a core principle, and quality and sourcing folded into Scope and Resources respectively.

Exam driver

Exam Content Outline (ECO), with PMBOK as reference.

Still the ECO. The 2026 ECO reweights the domains. PMBOK 8 is the supporting reference, not the exam itself.

🎯 The 2026 ECO Shift: Business Environment is now 26% read this first

▾

The exam is scored against the Exam Content Outline (ECO), not the PMBOK Guide. The ECO groups everything into three domains, and the 2026 update reweights them dramatically. The single biggest change: Business Environment tripled from 8% to 26%, absorbing risk, governance, change control, and impediments from the other two domains. If you studied the old split, your instinct for where to spend time is now wrong. Match your study hours to these weights.

Domain	2021 ECO	2026 ECO	Shift	~Scored Qs
People	42%	33%	−9	~56
Process	50%	41%	−9	~70
Business Environment	8%	26%	+18	~44

Roughly 170 scored questions total. Business Environment goes from about 14 questions to about 44, so it is no longer a domain you can skim.

Why the jump? PMI reframed risk, governance, change control, and impediment removal as things that connect the project to its wider organization, rather than purely internal mechanics. So those tasks moved into Business Environment from People and Process. The work did not change, its filing did. That also means much of your old Process-domain study still applies, it just counts under a new heading now.

The 8 Business Environment tasks

1 · Establish Project Governance

Set the structure, decision rights, escalation paths, reporting, and ethics for the project, using organizational process assets. New as a standalone task; moved from Process.

Exam angle: choosing structured governance (steering committee, formal escalation) vs a self-governing empowered team. The answer depends on size, complexity, culture, and regulation.

2 · Plan & Manage Compliance

Identify and satisfy regulatory, security, health-and-safety, and sustainability requirements; assess threats to compliance and consequences of noncompliance. Retained from the old domain, now with sustainability named explicitly.

Exam angle: a new regulation surfaces mid-project. Assess impact, update the plan, communicate. Never "ignore until it takes effect."

3 · Manage & Control Changes

Run the change control process: log the request, assess impact, route for approval, communicate the decision, implement if approved, update documents. Moved from Process.

Exam angle: predictive uses a formal CCB; agile handles change through backlog refinement and the product owner. Match the process to the approach.

4 · Remove Impediments & Manage Issues

Evaluate, prioritize, and clear blockers; recognize when a risk has become an issue; collaborate with stakeholders to resolve. Combines old People and Process tasks.

Exam angle: know risk (uncertain, future, in the risk register) vs issue (already happened, in the issue log). Servant-leader move: assess, escalate to the right level, collaborate to remove.

5 · Plan & Manage Risk

The full risk life cycle: identify, analyze, plan responses, execute, monitor, and communicate. Moved from Process, and the single most heavily tested topic on the exam.

Threats: Escalate, Avoid, Transfer, Mitigate, Accept. Opportunities: Escalate, Exploit, Share, Enhance, Accept. Know appetite vs tolerance vs threshold, and be able to run an EMV calculation under pressure.

6 · Continuous Improvement

Capture lessons learned, keep improvement processes current, and update organizational process assets. Elevated to a standalone task.

Exam angle: after a phase or a major issue, run a lessons-learned session and update OPAs. In agile this is the retrospective.

7 · Support Organizational Change

Assess organizational culture and manage how the project's deliverables land on the people and processes receiving them. Distinct from project change control. Retained.

Exam angle: the deliverable is done but the org resists adopting it. The project succeeds only when the organization adopts and benefits, so engage, train, and address resistance.

8 · Evaluate External Changes

Survey and assess shifts in the external environment (regulations, technology, geopolitical, market) and their impact on scope or backlog. Retained.

Exam angle: an external event lands (new law, competitor move, downturn). Assess the impact on scope/backlog, communicate, adjust. Never "proceed as planned."

Three question stems that repeat

"A new regulation affects the project"

Compliance / external-change stem. Attack it: assess impact first, then route through change control if scope or schedule moves. Wrong answers say "ignore" or "continue as planned."

"The team is blocked by [external dependency / vendor / constraint]"

Impediments stem. Attack it: separate risk from issue, then assess, escalate to the right level, and collaborate to remove. Wrong answers say "work around it" or "wait and see."

"The organization is undergoing [restructure / leadership change / merger]"

Organizational-change stem. Attack it as a stakeholder-and-value problem: revisit the business case, update the stakeholder register, re-engage, adjust the plan. Wrong answers say "continue and wait for the dust to settle."

Study allocation: put roughly 25–30% of your hours into Business Environment, and inside it, prioritize risk first (most-tested), then governance models, then change control. This maps to the 8th Edition too: governance and change align to the Governance domain, risk to the Risk domain, and compliance and risk both touch the Sustainability principle.

⚖️ The 6 Principles (8th Edition)

▾

The 8th Edition refines the 7th Edition's twelve principles into six, merging some and migrating two (Tailoring and Risk) into their own dedicated sections. These are plain-language summaries; verify exact wording against the official guide.

🎯 The 7 Performance Domains

▾

Performance domains are the interactive areas of project work that, taken together, deliver outcomes. Quality now lives inside Scope; Communications now lives inside Stakeholders; Procurement is reframed as Resources/sourcing.

🗂️ The 5 Focus Areas

▾

Focus Areas are the 8th Edition's answer to the old Process Groups: they describe when work happens across a project's life cycle, not a fixed list of processes. The 38 named processes (in the grid below) live inside the 7 performance domains and naturally fall into one or more of these five areas as the project moves forward.

✨ New & Expanded Emphasis

▾

🧠 The 8th Edition Mindset: 3 Dimensions

▾

The 8th Edition frames the six principles as three working dimensions of mindset, a useful lens for exam scenario questions that test attitude as much as mechanics.

Proactive Dimension

Plan and act ahead of problems rather than reacting to them. Aimed at meeting or exceeding target business objectives before issues force your hand.

Ownership Dimension

Leadership accountability plus a high-performance team culture. Combines Be an Accountable Leader and Build an Empowered Culture: decisions are owned, and the team shares responsibility for outcomes.

Value-Driven Dimension

Maximize value while weaving sustainability through the project. Combines Focus on Value and Integrate Sustainability Within All Project Areas, aiming for the triple bottom line: people, profit, and planet.

Quick recall

Proactive = before it's a problem · Ownership = who's accountable · Value-driven = why it's worth doing

The mindset in practice: how PMI wants you to think

Most scenario questions are really testing attitude. The "PMI mindset" is a specific default posture, and when two answers both look reasonable, the one that fits this posture almost always wins. These are ordered by how many questions they decide, learn the top ones cold first. It is a lens, not memorization: read every situation as a servant leader who is proactive, collaborative, and value-driven.

1Understand before you act

The single most common tiebreaker. When the situation is genuinely unclear, gather information first (assess, analyze, meet the person). But when the fix is obvious, acting is the right move and "analyze" becomes a stall. Master reading which situation you are in.

2Servant leadership first

Decides most people-domain questions. Your job is to remove blockers, coach, and empower the team, not command or punish. Team problems get understood and facilitated, never solved by hiring, firing, or escalating.

3Collaborate and face conflict directly

Talk to people directly and early. Address conflict at the source rather than avoiding it or routing around it. Direct, respectful engagement beats email trails and escalation almost every time.

4Follow the process, honor decision rights

Changes go through change control. Decisions go to whoever governance says owns them. Never bypass the process even for a good reason, and never let seniority override defined authority.

5Be proactive, not reactive

Act on early signals while options are still cheap. A forecast warning is a gift, not something to wait on. "Monitor and revisit later" is usually the weaker answer when you could act now.

6Protect value and the team

The lens behind all the others. Every choice ladders up to delivering value and sustaining a healthy team. Answers that sacrifice long-term value or burn the team for a short-term win are the ones to eliminate.

Two special-case overrides: a genuine safety hazard or mandatory regulation is the one time "stop work" beats "assess first": halt the affected work immediately, then run the impact through change control. And escalation culture differs by approach: predictive treats escalation as a governed last resort along a defined path, while adaptive teams surface blockers fast and escalate quickly when something exceeds team authority, because a blocked sprint is value not delivered.

The elimination shortcut: a huge share of wrong answers are wrong because they violate the mindset. Learn to strike on sight anything that says: hire, fire, ask for more money or time as a first move, escalate before trying, hand off work you should own, do nothing or defer, or act without understanding. Removing those usually leaves you with two options, and then you pick the one that best solves the actual problem.

Read the question the right way: read the last sentence first so you know the actual ask, then read the scenario with that in mind and mentally highlight the keywords. Most stems are padded with detail that does not matter. Find the real problem, then ask of each surviving answer, "does this actually solve that?"

🧑‍🤝‍🧑 People & Team: Models That Decide Questions

▾

The People domain is 33% of the exam, and a handful of named models keep deciding its questions. None of these changed in the 8th Edition. Learn the model, then learn the cue that tells you a question is testing it.

Tuckman's stages of team development

Teams move through predictable stages, and the PM's leadership style should shift with each one. The exam loves giving you a team behavior and asking for the matching response.

1. Forming

Team is new, polite, and unsure of roles. PM leads with directing: clear structure, clear expectations. Cue: "the team just came together."

2. Storming

Conflict surfaces as working styles collide. PM leads with coaching: facilitate, address conflict directly, do not suppress it. Cue: "members are clashing over approach." This stage is the most tested.

3. Norming

The team settles into shared habits and trust. PM leads with supporting: encourage collaboration, step back from directing. Cue: "the team is starting to work well together."

4. Performing

The team is self-managing and effective. PM delegates and removes blockers. Interfering with a performing team is a classic wrong answer. Cue: "high-performing, autonomous team."

5. Adjourning

Work completes and the team releases. PM ensures recognition, closure, and lessons learned. Cue: "the project is wrapping up."

Exam trap: a team can slip backward, for example a performing team that regresses to storming when a new member joins. When membership changes, expect the stages to partially restart, and lead accordingly.

Motivation theories: what actually drives people

Maslow's hierarchy

Needs stack from physiological and safety up through social and esteem to self-actualization. Lower needs must be reasonably met before higher ones motivate. Cue: a burned-out or insecure team member will not respond to "growth opportunities."

Herzberg's two factors

Hygiene factors (pay, conditions, policies) only prevent dissatisfaction; they never motivate. Motivators (achievement, recognition, growth, the work itself) create satisfaction. Cue: "we raised salaries and morale still did not improve." That is hygiene doing exactly what hygiene does.

McGregor's Theory X / Y

Theory X managers assume people avoid work and need control; Theory Y assumes people are self-motivated and seek responsibility. The exam rewards Theory Y leadership: trust, empowerment, delegation.

McClelland's three needs

People are driven primarily by achievement, power, or affiliation. Match assignments to the driver: give achievers stretch goals, give affiliation-driven people collaborative roles. Cue: "how should the PM motivate this specific person?"

Vroom's expectancy theory

Motivation = belief that effort leads to performance, performance leads to reward, and the reward is actually valued. Break any link and motivation dies. Cue: "the team stopped trying because the target feels impossible."

Personality assessments (MBTI, DISC)

Tools for understanding working-style differences, never for labeling or "fixing" people. Exam cues: with introverts on the team, send agendas in advance so they can process before being asked to speak; when a detail-focused person clashes with a big-picture person, facilitate mutual understanding rather than picking a winner; when assembling a team, seek a balance of types.

Stakeholder engagement assessment matrix

Classify each stakeholder's current engagement, compare against the level you need, and close the gap deliberately: Unaware → Resistant → Neutral → Supportive → Leading. Exam cue: when a question gives you a stakeholder's attitude and asks what to do, the answer usually starts with assessing current versus desired engagement, then engaging directly to move them one step, not from Resistant straight to Leading.

🤖 AI on the 2026 Exam: What You Actually Need

▾

AI questions are new to the 2026 exam, and firsthand reports agree they are mostly common sense plus mindset. You need three things: the vocabulary ladder, the three levels of use, and the governing principle.

The vocabulary ladder

Each term is a subset of the one before it. Artificial intelligence: systems that reason, learn, and act. Machine learning: AI that learns patterns from data to make predictions. Deep learning: machine learning built on multilayer neural networks. Generative AI: deep learning that produces new content such as text, images, or audio. Know the nesting; a question may ask which is a subset of which.

Three levels of use

Automation handles repetitive low-stakes work: status reports, meeting summaries, task tracking. Assistance supports human analysis: scheduling options, risk analysis, forecasting. Augmentation enhances strategic thinking: brainstorming, portfolio trade-offs, sentiment analysis. The higher the level and the higher the stakes, the more human judgment stays in the loop.

Where it helps by domain

Schedule: dynamic scheduling and conflict detection. Risk: identification and impact analysis across more data than a workshop can hold. Stakeholders: sentiment analysis and tailored communication. Governance: reporting, monitoring, compliance tracking. AI is a capability that threads through domains, not a domain itself.

The governing principle

AI is a tool under proportional human oversight. The PM stays accountable for every decision an AI touches; outputs get reviewed before they drive action; higher-stakes decisions get more scrutiny, not less. Wrong answers to spot on sight: fully delegating people decisions to a tool, banning AI outright, or adopting without defining what it may and may not decide.

✂️ Tailoring: Fit the Approach to the Project

▾

The 8th Edition gives tailoring its own dedicated section, and the exam treats it as a default assumption: no process, template, or approach is applied just because it exists. Three things get tailored, and a handful of factors drive how.

What gets tailored

The development approach (predictive, adaptive, or hybrid, chosen per component, not per fashion), the processes (add, remove, blend, or simplify to fit), and the engagement model (how much empowerment, collaboration, and oversight the situation needs).

What drives the tailoring

Size and complexity set how much governance and planning weight you need. Risk and uncertainty push toward flexibility and tighter feedback loops. Regulatory and compliance demands can make certain processes mandatory. Team capability sets how much autonomy is safe. Criticality of the product raises the quality and validation bar. Stakeholder complexity shapes communication and decision paths.

How it shows up in questions

Stable requirements and fixed infrastructure point predictive; evolving requirements and fast feedback point adaptive; a mix points hybrid, split by component. A safety-critical or regulated element keeps formal controls even inside an otherwise agile project. Cue: any question offering "use agile because agile is better" or "follow the template because it is required" is testing whether you tailor on fit, not fashion or habit.

Tailoring is transparent

Adapting an ill-fitting organizational template or process is legitimate, but it happens with the PMO or governing body, not by quietly ignoring the rule. Feed what you learned back so the standard improves. Tailor openly, never unilaterally.

📚 New & Changed Terms: Know These

▾

Five Whys

Root cause analysis by asking "why" repeatedly (about five times) until the answer stops being a symptom. Pairs with the fishbone diagram; the exam rewards fixing the root cause it finds, not the first symptom.

Decision Tree

Maps decision options with their probabilities and payoffs, then multiplies through (EMV) to compare paths. The classic make-or-buy and choose-a-vendor analysis tool.

Dependency Types

Mandatory (hard logic, cannot change), discretionary (preferred order, can change), external (outside the project's control), internal (within it). Exam cue: only discretionary dependencies are candidates for fast-tracking.

Osmotic Communication

Team members absorbing useful information simply by overhearing a co-located team's conversations. One of the quiet arguments for co-location in agile settings.

Benefits Realization

Value is not delivered when outputs ship; it is realized when the organization actually uses them and the promised benefits show up, often after project close. The benefits management plan defines who measures this, how, and when.

Premortem

Before work starts, the team imagines the project has already failed and works backward to name what killed it. Surfaces risks that optimism hides.

ESVP check-in

Retro opener asking each person to identify as Explorer, Shopper, Vacationer, or Prisoner. Reveals how engaged the room really is before you rely on its input.

Shu-Ha-Ri

Skill maturity in three phases: obey the rules, adapt the rules, transcend the rules. Tailor coaching to the phase, not the title.

Dreyfus model

Skill acquisition from novice to expert. Novices need recipes; experts need context and autonomy. Same lesson as Shu-Ha-Ri: coach to the level.

Focus Area

The 8th Edition's replacement for "Process Group." Describes when work happens (Initiating, Planning, Executing, Monitoring & Controlling, Closing), not a fixed sequence of named processes.

Performance Domain

An interactive area of project work. Eighth edition has 7: Governance, Scope, Schedule, Finance, Stakeholders, Resources, Risk. Carried forward from 7th edition with refinements.

Non-Prescriptive Process

A named practice meant to be tailored to context rather than followed as a fixed recipe. The 38 named processes are written this way.

Triple Bottom Line

People, profit, and planet. The standard 8th edition uses for weighing a project's social, financial, and environmental impact under the sustainability principle.

Sourcing Strategy

The 8th edition's reframing of procurement planning: deciding how to acquire outside capability (make-or-buy, contract type) as part of the Resources domain rather than a standalone procurement function.

Tailoring Section

A dedicated section covering how to adapt approach and process to context. Migrated out of the principles list in 7th edition into its own section, on the reasoning that practitioners wanted concrete mechanics, not a one-line principle.

Models, Methods & Artifacts

The 8th edition's catalog of reusable techniques and deliverables, referenced from within the performance domains rather than tied to one specific process.

Development Approach

Predictive, iterative, incremental, agile, or hybrid. Chosen early and revisited as the project life cycle unfolds; still a foundational tailoring decision in 8th edition.

🧮 Earned Value Formulas: Carried Over Unchanged

▾

Earned value management is math, not edition-specific narrative, so none of this changes in the 8th Edition. It is repeated here so 8th-edition study is self-contained; full detail lives in the 6th/7th tab's Calculations panel.

Formula	Equation	Meaning
Cost Variance (CV)	EV − AC	Negative = over budget
Schedule Variance (SV)	EV − PV	Negative = behind schedule
Cost Performance Index (CPI)	EV ÷ AC	Below 1.0 = inefficient spending
Schedule Performance Index (SPI)	EV ÷ PV	Below 1.0 = behind schedule
Estimate at Completion (EAC)	BAC ÷ CPI	Forecast total cost at current efficiency
Estimate to Complete (ETC)	EAC − AC	Forecast remaining cost
To-Complete Performance Index (TCPI)	(BAC − EV) ÷ (BAC − AC)	Efficiency required on remaining work to hit BAC

Estimate accuracy ranges (also unchanged)

Estimate type	Typical range	When
Rough Order of Magnitude (ROM)	−25% to +75%	Initiating, very early screening
Budget estimate	−10% to +25%	Early planning
Definitive estimate	−5% to +10%	Late planning, well-understood work

The pattern to remember: ranges narrow as knowledge grows. A question offering false precision early ("give a definitive estimate at kickoff") is testing whether you know these bands.

🧠 How to Read the Question: Test-Taking Strategy the difference between knowing it and passing

▾

Most people who fail the PMP know the material. They lose on how the question is worded. These are decision rules for the moments where two answers both look right. Drill them until they're automatic, because you will not have time to reason them out fresh 180 times on exam day.

1. The Tense Gate: future vs present vs past

PMI buries the deciding detail in the verb tense of the stem. Before you read the answers, find the verb and ask: has this happened yet? That one distinction often decides the whole question.

may / might / could / potential

Hasn't happened yet = future/uncertain = a RISK → Risk Register.

is / are / currently / now

It's happening = present/certain = an ISSUE → Issue Log.

was / did / has happened / completed

It's done = past → act on it, or record a Lesson Learned.

The trap in action: "A supplier reports they may be unable to deliver on time. What should the PM update?" Your eye grabs "supplier can't deliver!" and wants the Issue Log. But the gate word is may: it hasn't happened, so it's the Risk Register. Change one word to "the supplier is unable to deliver" and the answer flips to the Issue Log. Same scenario, different tense, different answer.

It extends past risk vs issue: "CCB has approved the change" (done) means implement it, don't re-analyze. "The team is blocked" (now) means act to remove the impediment. "A regulation will take effect next quarter" (future) means plan and assess, don't react yet.

Answer the verb, not the mood. "The team is frustrated," "urgent!" and so on: the emotional tone is bait. The tense tells you what's actually being asked. Getting the topic right but the timing wrong still loses the question.

2. Act vs Understand: the "analyze first" tiebreaker

So many questions come down to: should the PM do something, or go learn more first? Both options sit right there looking correct. The tiebreaker:

Obvious owner / decision already made → ACT

"A functional manager reassigned two of your resources." The fix is obvious: the functional manager controls them, so go negotiate with them. You can name the person who resolves it, so act. "Perform a risk analysis" here is a stall.

New / ambiguous / unapproved → UNDERSTAND first

"A new regulation is introduced mid-project that may affect the product." The impact is genuinely unknown, so assess it before doing anything. Nothing is obvious yet.

Gut check: can I name the exact person or step that fixes this? Then do it. If I can't, go understand it. The phrase "assess the impact / analyze / perform risk analysis" is a real PMI answer, but only when something is genuinely unknown. When the fix is obvious, "analyze" is just stalling and it's wrong. Same phrase, opposite correctness. It cuts both ways: don't over-act either (jumping to "recalculate the whole schedule" before reviewing an approved change).

3. EVM Signs: kill the "two unders" trap

People blow EVM not on the formulas but on the plus/minus direction. One rule covers all four metrics:

Above the line, doing fine. Under one, on the run.
Index above 1.0 = good. Variance above 0 = good. Below = bad. Always. CPI and SPI use the line 1.0; CV and SV use the line 0. There is no metric that is good when it is low, so stop hunting for an exception. That hunt is the trap.

The one thing that sounds like an exception but isn't: "under budget." A high CPI (say 1.2) is good, and you describe that good situation as "under budget." So it isn't a reversal, it's just high-CPI wearing a costume. The only good "under" is "under budget."

Formulas, EV always first: cost pairs with AC, schedule pairs with PV. Variance subtracts, index divides. CV = EV − AC · SV = EV − PV · CPI = EV ÷ AC · SPI = EV ÷ PV.

Elimination trick: C = Cost = money (AC), S = Schedule = time (PV). If a question asks about SV (schedule) but an answer talks about budget, that answer mixed the wrong variable. Strike it on sight. Many EVM distractors are wrong simply because they answer the wrong dimension.

4. Reading & elimination discipline

Read the last sentence first

Read the actual question before the scenario. Knowing the real ask lets you weed out the irrelevant fluff as you read the rest. Most stems are padded with detail that doesn't matter.

Does this answer solve the actual problem?

After eliminating the two obviously un-PMI options, ask this of the remaining two. Identify the real problem first, then pick the answer that addresses it rather than a side issue.

Look for: collaborate, analyze, empower, facilitate

PMI rewards proactive, value-driven, team-oriented thinking. These verbs often mark the intended answer, though never blindly: it still has to fit the tense gate and solve the real problem.

The "don't" list, usually wrong

Don't hire, don't fire, don't ask for more money, don't escalate (usually), don't hand off work you should do, don't do nothing or defer, don't act without understanding first. Answers built on these are typically the eliminations.

These are exam-technique heuristics, not PMI doctrine. They're pattern shortcuts for the pressure of exam day; the study panels above are where the actual knowledge lives.

🔬 Worked Scenarios: Watch the Reasoning how to think, not just what to know

▾

The Gauntlet tests you. This section teaches. Each scenario below is worked out loud, step by step, so you can see the reasoning that separates the best answer from the three that look right. Read these before you drill the Gauntlet, then do the Gauntlet to see if the thinking stuck. The goal is to make this reasoning automatic.

💡 Transition Tips & Traps

▾

Know your test date first

If you sit before July 9, 2026, the exam runs on 6th/7th edition content. After that date, it's 8th edition. Studying the wrong edition's specifics is the single biggest avoidable mistake right now.

Most processes didn't vanish, they got renamed

21 of the 38 confirmed 8th-edition processes are functionally identical to a 6th-edition process. Don't relearn from scratch, map the new name to what you already know.

ITTOs aren't gone, they're reorganized

The artifacts (Risk Register, Change Requests, etc.) still exist. They're now catalogued once, alphabetically, instead of repeated under each of 49 processes. The underlying knowledge transfers directly.

Math doesn't change editions

EVM formulas, critical path method, and similar quantitative techniques are identical regardless of which edition you're tested on. Don't waste study time worrying these changed, they didn't.

Two principles moved, they didn't disappear

Tailoring and Risk are no longer in the principles list, but they're more thoroughly covered than ever: Tailoring has its own dedicated section, and Risk is a full performance domain.

🔗 Still Tested: Carried-Over Reference Topics

▾

These topics did not change enough between editions to need rewriting, but they are absolutely still on the 8th Edition exam. The full reference for each lives in the 6th/7th tab, kept in one place so it never drifts out of sync. Tap any topic to jump straight to it.

Jumping switches you to the 6th/7th reference tab. Use the edition toggle up top to come back to the 8th Edition.

🔗 External Resources: Where to Go Deeper

▾

These are the study resources that consistently come up among people who pass. This guide is independent and not affiliated with, sponsored by, or endorsed by any of them. Free resources are marked; the rest are paid. Always confirm a resource is updated for the 2026 / 8th Edition exam before relying on it.

On reading the PMBOK Guide directly: Opinion is split in the PMP community, and both sides have a point. Reading the PMBOK cover to cover can feel convoluted and doesn't by itself teach you how to answer scenario questions. But skipping it entirely and only doing mocks can leave real gaps in the underlying concepts. The pattern among people who pass isn't "read it" or "don't read it," it's volume of timed, full-length mock exams combined with deliberate mindset drilling (the Playbook, worked scenarios, and reviewing every explanation, right or wrong), with the PMBOK and Agile Practice Guide used as a reference to fill specific gaps mocks reveal, not as the primary study method.

Third3Rock (ThirdRock) Notes

Third3Rock study notesFree · community-sharedA condensed set of study notes that circulates in the PMP community. They are shared informally rather than from one official page, so search "Third3Rock PMP notes" and you will find the current copy on Reddit's r/pmp or the community Discord/Drive links. Verify they match the 2026 ECO before relying on them.

Links were current when this guide was last updated. If one breaks, search the creator's name plus "PMP" to find the moved page. Nothing here is required to pass, and none of it is a substitute for the official PMBOK Guide and Exam Content Outline.

📊 Charts & Graphs: What Each One Is For

▾

These chart types are universal project management tools, not specific to one edition, so nothing here changes with the transition. In 8th edition they live under the unified Models, Methods & Artifacts reference instead of being tied to one named process, but the charts themselves and what they're for are identical. Each card has a small example so you can recognize the shape on sight.

Gantt Chart

A horizontal bar chart showing each activity's start and end date along a timeline. The standard way to visualize a schedule at a glance.

Network Diagram

Boxes connected by arrows showing how activities depend on each other. Used to find the critical path, the longest dependent chain through the schedule.

S-Curve

Plots cumulative cost or progress against time. The standard way to visualize earned value trends over the life of the project.

Control Chart

Plots results over time against upper and lower control limits. Used to judge whether a process is stable, part of the Quality work inside the Scope domain. Remember the rule of seven: seven consecutive points on one side of the mean signal a non-random pattern, so investigate even if nothing crossed a control limit.

Pareto Chart

A sorted bar chart with a cumulative percentage line, built around the 80/20 rule. Used to prioritize which defect category to fix first.

Fishbone (Ishikawa) Diagram

A cause-and-effect diagram organizing root cause analysis into major categories branching off a central spine.

Burndown / Burnup Chart

Agile tracking tools. Burndown shows remaining work trending to zero; burnup shows completed work against total scope, making scope changes visible. A risk burndown variant plots total risk severity over time, showing whether risk responses are actually reducing exposure.

Probability/Impact Matrix

A grid plotting each risk's likelihood against its severity, used inside the Risk domain to decide which risks need an active response.

Tornado Diagram

A sensitivity analysis chart ranking variables by how much they affect an outcome, widest impact at the top, creating the tornado shape.

RACI / RAM (Responsibility Assignment Matrix)

A grid mapping people against tasks, marking who is Responsible, Accountable, Consulted, and Informed for each. Used to remove ambiguity about who does what. Exactly one Accountable per row.

Cumulative Flow Diagram (CFD)

An agile chart showing how much work is in each state (to-do, in-progress, done) over time, as stacked bands. Widening bands reveal bottlenecks and work piling up. A "spike" or sudden jump in one band flags a flow problem.

Velocity Chart

A bar chart of how many story points a team completes each sprint. Used to forecast how much the team can take on. Trends matter more than any single sprint; a stable average is what you plan against.

Run Chart

A simple line of data points over time, without the control limits of a control chart. Used to spot trends, shifts, or a sudden spike in a measure before deciding whether deeper analysis is needed.

Histogram

A bar chart showing how often each value or category occurs, for example how many defects fall into each severity band. Reveals the shape and spread of a dataset at a glance.

Scatter Diagram

Plots two variables against each other to reveal whether they correlate, for example overtime hours versus defect rate. A visible trend suggests a relationship worth investigating; scattered noise suggests none.

Power/Interest Grid

Maps stakeholders by their power over the project against their interest in it, giving each quadrant a strategy: high power and high interest get managed closely; high power, low interest kept satisfied; low power, high interest kept informed; low power, low interest simply monitored.

📂 The 38 Named Processes

Each card shows its 6th-edition equivalent where one exists, an original purpose summary, and key practices in place of a fixed ITTO table, since 8th edition processes are written as adaptable practices rather than rigid input/tool/output recipes. Click a process to expand it, or click ⓘ for the full study tooltip with tips and traps.

Group by:

Grouped by the 7 performance domains, the 8th Edition's own structure.

🗄️ The Artifact Register: All 64 Project Documents

▾

Every document PMI expects you to recognize, filed by where it first enters the project. These are edition-independent: the 8th Edition catalogs them once in its unified Inputs & Outputs reference instead of repeating them per process, but what each one holds is unchanged. Click any row to reveal what it contains, or quiz yourself by guessing first. The standalone visual version has the phase-spine view and print mode.

📁 Case Study: New 2026 Format

The 2026 exam opens with a case-study section: one scenario, several linked questions. On the real thing the questions from two cases can interleave (a Case 1 question, then Case 2, then back to Case 1), so practice anchoring yourself to the scenario before each answer. Read the whole case first. Below is one original case with three linked questions in that style, each with full explanations.

🔥 The Gauntlet: 52 Hard Questions

Original scenario questions written in the real exam's nastiest style: every option is defensible, and only one is best. Each targets an 8th Edition concept, and every wrong answer comes with the reason it loses, because knowing why the almost-right answer is wrong is the skill the exam actually tests. These are practice drills built from the 8th Edition framework and the exam mindset, not recycled or leaked exam content, so treat them as training, not prediction.

Not started

PMP Study GuidePMBOK 8th Edition