PMP Decision Rules

These are decision rules, not exam trivia. Each one is a call you make on a real project — which is exactly why the exam tests it. Read the rule, learn the tell that says it applies, and remember the trap it rules out.

The set is not fixed. It grows every time you get something wrong.

Every rule below links back to the page it came from — 50 pages in all.

Test yourself first

Ten questions, no sign-in, no email: run the diagnostic.

Grow your own rules

Every wrong answer is one rule you do not have yet. After a miss, three lines:

I got question [N] wrong. I chose [X], correct was [Y]. Explain:

• Why [Y] is correct (PMBOK 8 / ECO reference)
• Why [X] is a common trap
• What mental model to use next time

The third line is the one that matters. Reading an explanation feels like learning; writing down the rule is learning. Keep your own file and append to it.

---

People — 33% of the exam

People Domain

• Conflict management: PMI consistently favors confronting/problem-solving (collaborative) over avoiding, accommodating, or immediately escalating — wrong answers escalate before the PM has tried to resolve it at the lowest level
• Leadership style: situational leadership — wrong = always apply servant leadership regardless of context; right = match style to team maturity (directing for new team, delegating for experienced self-organizing team)
• Knowledge transfer trap: wrong = document lessons learned only at project end; right = knowledge transfer is continuous throughout the project (retrospectives, lessons learned register updated in real time)
• Stakeholder alignment: when stakeholders disagree on scope or direction, wrong = take the sponsor’s side automatically; right = facilitate discussion, surface trade-offs, achieve shared understanding
• Task 7 (knowledge transfer) in agile: retrospectives are the primary knowledge transfer mechanism — not a formal lessons learned document

Source: 4.2. People

Process — 41% of the exam

Process Domain

• Development approach selection (Task 1): wrong = default to agile because it’s modern; right = match approach to requirements certainty, team experience, regulatory context, and stakeholder availability — justify the choice
• Integrated change control (Task 1 / Task 9): changes to baselines must be approved BEFORE implementation — scenarios where the team implements then asks for approval are always wrong
• Value-based delivery (Task 3): business value drives backlog priority — this is the product owner’s call, not the team’s and not the PM’s; wrong answers have PM or team deciding what to build next
• Schedule metrics by approach (Task 8): SPI/CPI apply in predictive (EVM-based); velocity and burndown apply in adaptive — mixing them in the same scenario is a trap
• Procurement (Task 5): contract type determines who bears cost risk — fixed price = seller bears risk; T&M = buyer bears risk; cost-plus = buyer bears most risk — contract selection scenarios test this logic
• Project closure (Task 10): formal acceptance must come from sponsor or customer — PM cannot self-certify completion; cancelled projects still require formal closure activities

Source: 4.3. Process

Business Environment — 26% of the exam

Business Environment Domain

• Compliance vs. schedule (Task 2): when regulatory compliance conflicts with the project schedule, compliance always wins — wrong = skip the compliance step to recover schedule; right = raise it, adjust scope or schedule, never skip compliance
• Change control framing (Task 3): this domain frames change control as a governance and environmental response, not just a process mechanic — scenarios describing sponsor-requested changes, regulatory changes, or market shifts are Business Environment questions, not just Process questions
• Risk vs. issue (Task 4/5): impediments and blockers that have already occurred are issues (active resolution needed now); risks are future and uncertain — wrong answers treat active problems as risks still needing analysis
• External environment changes (Task 8): assess impact on scope/backlog BEFORE adjusting plans — wrong = immediately update the project plan when news changes; right = analyze impact, engage stakeholders, then formally change through change control
• Organizational change (Task 7): supporting organizational change means assessing culture and managing resistance — wrong = treat it as a communications task only; right = address root causes of resistance and engage change agents
• Governance setup (Task 1): governance escalation paths and thresholds must be defined upfront — scenarios where the PM doesn’t know who to escalate to indicate a governance gap, not a stakeholder gap

Source: 4.1. Business Environment

The 7 performance domains — where the work happens

Governance Domain

• Structured vs. self-governance trap: A team making all governance decisions internally is valid self-governance for adaptive projects, not a governance failure — wrong answers escalate to a PMO that doesn’t exist or require formal CCB in an agile context
• Lagging vs. leading indicators: Schedule variance (CPI, SPI) are lagging — useful but reactive; leading indicators (backlog size, stakeholder engagement level, undefined success criteria) are preferred because they prevent problems before tolerance thresholds are crossed
• CCB authority in predictive projects: Changes impacting a baseline require CCB review; CCB approves, defers, or rejects — PM does not unilaterally approve baseline changes; sponsor/customer approval may be required after CCB approval unless they are CCB members
• Adaptive change management: In adaptive approaches, changes go to the backlog — there is no formal approval process; lower priority = deferred; removed from backlog = rejected; wrong answers apply formal change request language to agile contexts
• Measurement pitfalls: Hawthorne effect (measuring behavior changes it), vanity metrics, demoralization from unachievable goals, confirmation bias — exam scenarios test whether PM focuses on actionable SMART metrics rather than gaming the numbers
• Knowledge management nuance: Tacit knowledge (experience, intuition) cannot be captured in a lessons learned register alone — wrong answers assume all knowledge transfer is document-based; correct answers include mentoring, retrospectives, collaborative environments

Source: 3.1. Governance

Stakeholders Domain

• Sponsor role scope: Sponsor approves the project charter AND the project management plan (and any changes to both) — wrong answers limit sponsor involvement to just the charter or just initial authorization; PMBOK8 lists 8 distinct sponsor activities including benefits realization and proposing termination
• Stakeholder identification is continuous: Not a one-time activity at project start — identifying new stakeholders throughout the project is an explicit risk management strategy; wrong answers close the stakeholder register after planning
• Monitor vs. Manage: Monitor Stakeholder Engagement = assess effectiveness and refine strategies; Manage Stakeholder Engagement = actual communication and issue resolution — wrong answers conflate the two or say monitoring is only for reporting
• Validate Scope vs. communications: Formal acceptance of deliverables (Validate Scope) involves stakeholders but is a Scope process, not a Stakeholder process — wrong answers route acceptance back to the stakeholder engagement plan
• AI in communications: PMBOK8 explicitly includes AI/LLMs as a tailoring consideration — but with required security and ethics assessment; wrong answers treat AI tools as freely applicable without governance review
• Neutral stakeholders: Effective stakeholder management includes neutral and opponent stakeholders — not just supporters; wrong answers focus only on engaging supportive stakeholders

Source: 3.2. Stakeholders

Scope Domain

• Project scope vs. product scope trap: Project scope = work performed to deliver the product; product scope = features and functions of the product itself — exam scenarios test whether you identify which is changing when a change request is submitted
• Validate Scope vs. quality control: Validate Scope = formal acceptance by stakeholders (external focus, customer signs off); quality control = checking deliverable meets specifications (internal focus, team checks) — wrong answers confuse these or say they’re the same
• WBS vs. product backlog: WBS = predictive/hybrid hierarchical decomposition; product backlog = adaptive prioritized list — wrong answers apply WBS logic (sequential decomposition, formal baseline) to agile contexts
• Scope baseline composition: Scope baseline = project scope statement + WBS + WBS dictionary together — exam traps omit the WBS dictionary or include the cost baseline in the scope baseline definition
• VBS distinction: VBS connects project scope to value; the top level includes major deliverables with value-based estimates — this is not the same as a WBS; VBS is used for value-based prioritization, not just decomposition
• Hybrid life cycle complexity: Hybrid projects have an overall scope/schedule/cost baseline AND subteam backlogs — wrong answers treat hybrid as purely predictive or purely adaptive; correct answers acknowledge the dual governance structure

Source: 3.3. Scope Domain

Schedule Domain

• Estimate types for duration: Exam scenarios present a PM needing a fast estimate — analogous estimating uses historical data (less accurate, faster); parametric uses statistical relationship; bottom-up is most accurate but most time-consuming; wrong answers choose bottom-up when the exam context specifies limited time or early-stage planning
• Critical path vs. critical chain: Critical path = longest path through the network (sequence of activities); critical chain = critical path adjusted for resource constraints plus feeding and project buffers — wrong answers confuse them or say critical chain ignores resources
• Schedule compression techniques: Crashing = adding resources to shorten critical path (increases cost); fast-tracking = overlapping sequential activities (increases risk) — wrong answers apply crashing when the scenario specifies no additional budget, or apply fast-tracking when activities have true mandatory dependencies
• Adaptive schedule monitoring: Velocity (story points per sprint) and burnup/burndown charts replace CPI/SPI in adaptive contexts — wrong answers apply EVM metrics to a pure agile scenario
• Rolling wave planning: Not a sign of poor planning — PMBOK8 explicitly endorses progressive elaboration of detailed schedules as a legitimate approach when details are evolving or timelines are shrinking
• Cognitive bias in estimating: Planning fallacy (underestimating), Hofstadter’s law (it always takes longer than you think, even accounting for this), end-of-story illusion — exam tests awareness that estimates from people closest to the work are preferred AND that biases must be acknowledged

Source: 3.4. Schedule Domain

Resources Domain

• Lead the Team vs. Monitor and Control Resourcing: Lead the Team covers human resources (team performance, conflict, development); Monitor and Control Resourcing covers physical/virtual resources (equipment, materials, software) — wrong answers route team performance issues to the wrong process
• Tuckman ladder (forming-storming-norming-performing-adjourning): Listed as a Lead the Team tool — exam scenarios ask which stage a team is in and what the PM should do; storming = expect conflict and provide direction, not suppress it; adjourning = intentionally celebrate and release
• Servant leadership vs. autocratic leadership: PMBOK8 lists servant leadership as a Lead the Team tool alongside centralized and distributed leadership — wrong answers say servant leadership means the PM has no authority; correct answers recognize it means removing impediments and enabling the team
• Alternative resources: If required resources are not available, alternative resources are allowed IF risks are acknowledged and legal/regulatory criteria are not violated — wrong answers say the PM must always escalate or cancel; correct answer documents impact and acknowledges risk
• Virtual teams as risk: Virtual teams are a valid Acquire Resources tool but also create collaboration risks — exam scenarios test that PMs proactively address these with technology and team charters, not just assume virtual works the same as colocation
• Quiet quitting and burnout: Explicitly named in PMBOK8 tailoring — well-being considerations are a legitimate PM concern, not soft/optional; wrong answers treat these as HR-only topics

Source: 3.5. Resources Domain

Finance Domain

• Reserve authority trap: Contingency reserve = PM can use (known risks); management reserve = typically senior leadership, but PMBOK8 says some organizations allow PM discretion — right answer acknowledges the org context, not a blanket rule
• Two cost baseline variations: Exam scenarios may describe a baseline that includes or excludes contingency reserve — both are valid per PMBOK8; identify which scenario is described before calculating
• CapEx vs. OpEx: CapEx = physical assets (capitalize and depreciate); OpEx = ongoing operations (expense immediately) — wrong answers confuse the two when a scenario involves buying equipment vs. hiring contractors
• Agile budgeting: Quarterly allocation replaces annual baselines; contracts must reflect iterative cadence — wrong answers apply predictive cost baseline logic to adaptive projects
• Monitor and Control Finances outputs: Change requests and funding proposals are outputs — budget problems trigger change control, not unilateral PM adjustment
• Life cycle cost: Reducing project cost (fewer design reviews) may increase product operating cost — total cost of ownership thinking is the right frame, not just project budget

Source: 3.6. Finance Domain

Risk Domain

• Risk vs. issue trap: A risk is a future uncertain event (not yet occurred); an issue has already occurred — exam scenarios describe a situation that has already happened and ask the PM to log it as a risk; correct answer is the issue log, not the risk register
• Opportunities are risks too: Positive risks (opportunities) have explicit response strategies (exploit, enhance, share, accept, escalate) — wrong answers say risk management is only about threats; exam scenarios ask what to do with a cost-saving opportunity that emerged
• Known-unknown vs. unknown-unknown: Known-unknowns are covered by contingency reserve (PM can access); unknown-unknowns are covered by management reserve (typically senior leadership) — wrong answers reverse these or say management reserve covers all risks
• Qualitative vs. quantitative analysis: Qualitative analysis is always done; quantitative analysis is only done “when required” per PMBOK8 — wrong answers say quantitative analysis is always required; correct answer reads the scenario for whether probability + impact assessment alone suffices
• Adaptive risk management: In agile projects, risk assessments occur at the beginning of each sprint and risk-adjusted backlogs are used — not just during initial planning; wrong answers apply predictive risk planning process to agile contexts
• Risk appetite and threshold: Risk threshold quantifies risk appetite as an acceptable variation around an objective — a tight threshold (±5%) signals lower appetite than a loose one (±10%); exam scenarios test whether PM escalates a variance that is within vs. outside the threshold

Source: 3.7. Risk Domain

The standard — principles that decide the close calls

Introduction (PM Standard, Section 1)

• Temporary ≠ short. A 10-year project is still temporary because it has a defined end. Wrong answers conflate “temporary” with “quick.”
• Five ways a project ends — not two. Memorizing only “objectives met” and “terminated” leaves three traps: resources exhausted, need no longer exists, and legal/regulatory/compliance termination. Scenarios that describe an external regulation change forcing project shutdown test condition #5.
• Operations are ongoing, projects are unique-and-temporary. Recurring work (maintenance windows, monthly payroll, customer support) is operations — not a project — even when complex.
• Governance is two layers. Organizational governance directs the whole org; project governance directs the project. Answer choices that mix them up are testing this distinction.
• Programs are not big projects. Programs deliver benefits unavailable from independent projects. If a scenario describes “coordinated benefits realization across several efforts,” the right answer is program.
• Portfolios optimize at the strategic level. Portfolio decisions are about which programs/projects to fund, not how to run them. A “stop this project because strategy changed” decision is a portfolio-level call.
• Engage operations early. Wrong answers wait until handover; right answers engage operations during planning to influence long-term sustainability.

Source: 1.1. Introduction

A System for Value Delivery (PM Standard, Section 2)

• Two-dimensional success. Wrong = judge success only by on-time/on-budget. Right = also evaluate whether intended outcomes and benefits were realized. The Sydney Opera House example anchors this — process failure + outcome success.
• Counter-example matters too. Montreal Highway 15: well-managed construction (process success) but no outcome success — wrong scope for the broader context. Process success without outcome success is still failure.
• Disbenefits exist. Outcomes can also create negative consequences. Answers that assume “outcomes = benefits only” miss this.
• Operations are not separate from value delivery. Operations support and interact with PPP within the same system. Wrong answers silo operations from projects.
• EEFs ≠ OPAs. EEFs are conditions the project team doesn’t directly control (some internal, some external). OPAs are internal assets (templates, processes, knowledge repositories) the team often consumes and can update. Mixing them up is a common trap.
• Product life cycle ≠ project life cycle. A product can outlive multiple projects. A project initiates work at points in the product’s life cycle. Wrong answers conflate the two.
• Title ≠ function. PM responsibilities can be carried out by a scrum master, product owner, project lead, or team. Wrong answers fixate on the formal title.
• Sponsor presence matters. Sponsors are not optional figureheads — their active engagement raises success likelihood; absence drags projects down. Wrong answers reduce the sponsor to a name on the charter.
• End-user engagement is continuous. Verification and validation are iterative throughout the life cycle, not a one-shot acceptance test at the end.

Source: 1.2. Value Delivery System

Project Life Cycles (PM Standard, Section 4)

• Life cycle is chosen, not assumed. Wrong answers default to “agile because it’s modern” or “waterfall because it’s safe.” Right answers justify the choice from scenario context — requirements clarity, change rate, regulatory pressure, stakeholder availability.
• Hybrid is frequently correct. PMBOK 8 explicitly states most modern projects benefit from hybrid. Scenarios with mixed certainty often eliminate pure predictive or pure adaptive.
• “Process Groups” is PMBOK 6 language. If an answer choice talks about “the five Process Groups,” that’s the old name. PMBOK 8 says Focus Areas.
• Focus Areas are not phases. A question that treats Initiating-Planning-Executing-M&C-Closing as a sequential phase model is wrong. They overlap; M&C runs in parallel with the others.
• Iterations are time-boxed. When the time-box ends, the iteration ends regardless of what’s done. Unfinished work returns to the backlog — wrong answers extend the iteration to fit the work.
• Delivery cadence is independent of life cycle. A predictive project can deliver multiple times; an adaptive project can deliver once. Wrong answers automatically conflate “agile” with “frequent delivery.”
• Incremental ≠ adaptive. Predictive projects can deliver incrementally (e.g., a building’s floors completed one at a time) while still being predictive. Incremental describes delivery cadence; adaptive describes how requirements are managed.
• Disciplined Agile is a tool kit, not a method. Methods prescribe steps; tool kits offer choices. Questions that treat DA as a prescriptive method are testing this distinction.

Source: 1.3. Project Life Cycles

Adopt a Holistic View

• Fix the symptom, not the system (wrong) vs. investigate root cause across domains (right). Schedule slippage often has a resource or scope root cause.
• Siloed decision-making trap. Approving a change that helps schedule but damages risk or cost is wrong — always evaluate impact across all 7 performance domains first.
• Snapshot vs. pattern thinking. Track trends over time, not just point-in-time status. Wrong answers default to a single status report; right answers seek patterns.
• NGO/grant scenario. When an external initiative aligns with project goals, adapting to integrate is the holistic-view answer — pure focus on the original plan is wrong.
• Adaptive application. Cross-functional collaboration plus ongoing backlog review keeps the product vision aligned with organizational goals.

Source: Adopt a Holistic View

Be an Accountable Leader

• Authority vs. leadership. PM is asked to “use authority” to resolve a conflict — wrong. Right = facilitate discussion, build consensus, use interpersonal skills.
• Solo decision-making trap. PM takes all decisions alone to “be accountable” — wrong. Shared leadership empowers the team and still maintains ownership.
• Shared leadership ≠ no accountability. Empowering team members doesn’t mean the PM escapes accountability for outcomes.
• Conflict escalation shortcut. Wrong = immediately escalate to sponsor; right = address at lowest level, investigate root cause, facilitate resolution.
• Cross-vendor conflict (PMBOK example). When contracts say one thing but team experience is broken, dialogue across the silos is the leadership move — enforcement alone is wrong.
• Situational leadership. Match style to context — directing for a new team, delegating for a self-organizing one. Always-servant or always-directive is wrong.

Source: Be an Accountable Leader

Build an Empowered Culture

• Virtual / remote team trap. Wrong = enforce same rules as co-located teams. Right = tailor engagement, set explicit collaboration norms, ensure inclusive communication channels — PMBOK 8 calls this out directly.
• Conflict in diverse team. Wrong = manager resolves top-down. Right = facilitate empowered team resolution using ground rules and team agreements.
• Team wants to change approach mid-project. Wrong = reject citing the plan. Right = assess value of the change, involve the team in the decision.
• Empowerment ≠ absence of governance. Clear boundaries, agreements, and accountability structures enable empowerment — they don’t contradict it.
• Team agreements timing. Created at the beginning, not after the first conflict. Late-creation answers are usually wrong.
• Stakeholders determine success (per the figure callout). Wrong answers narrow “success” to scope/schedule/cost; right answers track stakeholder satisfaction and engagement.

Source: Build an Empowered Culture

Embed Quality Into Processes and Deliverables

• Late-defect trap. Defects found in final testing: wrong = “we’ll fix in the next phase”; right = shift-left quality, catch defects as early as possible to reduce cost of correction.
• Gold plating as quality. Adding extras beyond acceptance criteria framed as “high quality” — wrong. Quality means meeting acceptance criteria, not arbitrarily exceeding them.
• QA vs. QC. QA = process-focused (audits, prevention); QC = product-focused (inspections, defect detection). Exam scenarios test which to apply.
• Customer standards > regulatory minimum (shipping example). When stakeholder expectations exceed regulatory thresholds, the quality answer matches the higher bar.
• Adaptive application. DoD replaces standalone acceptance criteria; quality is embedded in every iteration via peer review, testing, and DoD validation — not a separate quality phase at the end.

Source: Embed Quality Into Processes and Deliverables

Focus on Value

• Gold-plating trap. Adding extras framed as “helping the customer” is wrong — gold plating adds risk, cost, and scope without confirmed value.
• Scope creep as customer care. Adding a feature the customer will “love” without change control — always wrong. Assess value contribution and route through change control.
• Project behind schedule. Wrong = crash schedule at any cost. Right = re-evaluate whether the project still delivers intended value; involve sponsor.
• Termination is valid. If the project can no longer deliver intended value, recommend termination. Pushing on for sunk-cost reasons is wrong.
• Features ≠ value (PMBOK rollout example). The simpler solution can deliver more value when it matches organizational culture.
• Adaptive application. Backlog prioritization is by business value; the product owner decides what to build next — not the team, not the PM.

Source: Focus on Value

Integrate Sustainability Within All Project Areas

• Sustainability not in charter trap. Wrong = ignore it because it wasn’t requested. Right = raise it with sponsor; encourage stakeholder discussion; flag sustainability risks. PMBOK 8 is explicit that sustainability goals SHOULD be in formal documents — if absent, the PM still drives the conversation.
• Cost vs. sustainability trade-off. Wrong = always choose lowest cost. Right = consider long-term value, regulatory risk, stakeholder impact.
• Sustainability Pyramid direction. Wrong = compensate is the “responsible” answer. Right = avoid is most desirable; compensate is the last resort. Push responses up the pyramid.
• TBL ≠ ESG. PMBOK 8 uses Triple Bottom Line (people/planet/profit). Don’t pick ESG as the framework name on PMBOK questions.
• Joint accountability. Sustainability is jointly accountable across PM, team, and sponsor. Wrong answers put it on a single role (often the sponsor or “the company”).
• Construction materials example. When cheapest material harms the environment, the right answer evaluates alternatives (recycled concrete, wood substitutes) AND involves local communities — not just picks the next-cheapest option.
• Adaptive application. Sustainability considerations live in the DoD and in backlog refinement — not bolted on at the end.

Source: Integrate Sustainability Within All Project Areas

The 5 focus areas — initiating through closing

Initiating (Focus Area)

• PM assignment timing: PM should be assigned BEFORE planning begins — wrong answers assign PM after the charter is already written or after planning starts
• Charter = PM authority: the project charter grants the PM authority to apply resources — without it, PM cannot commit team members or budget; charter is not optional
• Business case before charter: business case is written first, approved by the sponsor, and then the charter references it — sequence is tested on the exam
• Agile initiating: a formal charter may be replaced by a project canvas or equivalent lightweight artifact, but some form of documented authorization is always expected — “no documentation needed in agile” is always wrong

Source: 2.1. Initiating

Planning (Focus Area)

• Planning is ongoing: plans are progressively elaborated throughout the life cycle — wrong answers treat planning as a one-time upfront activity that ends when execution begins
• Amount of planning matches complexity: over-planning on a simple project is waste; under-planning on a complex, high-risk project is negligence — tailor the depth
• Adaptive planning is intentional: absence of a detailed upfront scope baseline in agile is a deliberate and valid choice — not a sign of poor discipline
• Plan vs. baseline: a working estimate can be updated freely; a baseline is the approved version — changing a baseline requires formal change control through the CCB

Source: 2.2. Planning

Executing (Focus Area)

• Work performance data vs. information: raw data (measurements, counts, observations) is collected in Executing; analyzed work performance information is produced in 2.4. Monitoring and Controlling — wrong answers conflate the two
• Issue management: issues are actively resolved in Executing (already occurred); risks are managed proactively — wrong answers treat current active problems as future risks
• PM’s role: enabling the team, removing obstacles, maintaining stakeholder alignment — not just task assignment and status tracking
• Change request gate: changes must go through integrated change control and be approved BEFORE implementation — generating a change request during execution does not authorize the change

Source: 2.3. Executing

Monitoring and Controlling (Focus Area)

• Monitoring is continuous and parallel: M&C runs alongside Executing at all times — wrong answers treat it as a phase that happens after work is done or only at milestones
• Corrective vs. preventive action: corrective = bring back on track after a variance occurred; preventive = take action to avoid a future variance — both require change requests through the CCB
• EVM acronyms: BCWS = PV (planned value), BCWP = EV (earned value), ACWP = AC (actual cost) — wrong answers frequently misidentify these; CPI < 1 = over budget, SPI < 1 = behind schedule
• Change request gate: changes identified during M&C must be formally approved before implementation — urgent changes are not exempt; submit, approve, then implement

Source: 2.4. Monitoring and Controlling

Closing (Focus Area)

• Early termination still requires closing: wrong = skip formal closure when project is cancelled; right = closing activities are always required even for terminated projects — archive, release resources, document lessons
• Lessons learned are continuous: wrong = capture lessons learned only at closure; right = lessons are captured throughout and compiled at closing — the register is a living document
• Formal acceptance cannot be self-certified: acceptance must come from the sponsor or customer — PM cannot declare their own deliverables accepted
• Early positive closure: projects can and should close early when the target value has been achieved ahead of schedule — this is a valid success scenario, not a failure or shortcut
• Benefits realization extends beyond closure: sponsor is accountable for ensuring benefits are realized after the project ends — PM delivers the product, sponsor delivers the ongoing value

Source: 2.5. Closing

Key concepts

AI Adoption Strategies

• Match the level to the task: reporting/summarization = automation; drafts of registers and plans = assistance (must be reviewed); strategic forecasting/portfolio trade-offs = augmentation (iterate as a partner)
• Assistance output is never final: wrong = accept an AI-drafted risk register or plan as complete; right = review, refine, and validate before use
• Neither worship nor prohibit: PMI’s pattern is “govern and verify” — blanket bans on AI and blind acceptance of AI output are both wrong answers
• Complexity drives supervision: if a scenario emphasizes strategic stakes or unpredictability, expect more human iteration, not less

Source: AI Adoption Strategies

AI Ethics and Responsible Use

• Data leakage scenarios: confidential data pasted into a public AI tool = an active privacy/compliance issue — first assess exposure and respond per the organization’s privacy/AI policies, not “add it to the risk register” or “ban all AI”
• Accountability can’t be delegated to the machine: when asked “who is accountable for an AI-made decision”, the answer is always a clearly defined human role, never the system or the vendor
• Validate before acting: AI forecasts and analyses are inputs to be checked (reliability), not triggers for immediate rebaselining or escalation
• Bias needs systemic fixes: right answers pair human review with diversified data and periodic bias testing — not arbitrary mechanical fairness rules and not quietly abandoning the tool

Source: AI Ethics and Responsible Use

AI Use Cases in Project Management

• “PM drowning in admin” scenarios: the best answer adopts the approved AI tool for the repetitive work (reports, minutes, scheduling) with review, and reinvests the time in stakeholder engagement or team leadership — not delegating the burden to a team member or refusing the tool
• AI recommendations are inputs: monitoring alerts, forecasts, and assignment suggestions get validated against the team’s own analysis before the PM acts on them
• Adoption is a change, not an install: when a team resists a mandated AI tool, treat it as organizational change — address fears, show the shift to higher-value work, involve the team — rather than escalating non-compliance or forcing training first

Source: AI Use Cases in Project Management

Adaptive Development Approach

• Adaptive ≠ no planning: release planning and sprint planning are still required — adaptive doesn’t mean chaotic or unplanned
• Fixed time/budget, variable scope: in adaptive, when unexpected change occurs, the team adjusts what they deliver, not when or for how much
• Product owner controls scope: the team does not decide backlog priority — that’s the product owner’s responsibility

Source: Adaptive Development Approach

Backlog Management

• Product owner controls priority: the development team does NOT decide what to build next — that is exclusively the product owner’s responsibility
• Backlog is not fixed: it changes continuously as the product evolves, market changes, or new information emerges — a backlog is always a living artifact
• Sprint backlog vs. product backlog: sprint backlog = committed work for one sprint (team owns it); product backlog = entire future scope (product owner owns it)

Source: Backlog Management

Benefits Management Plan

• Benefits management continues post-closure: the plan often specifies benefit realization activities that happen months or years after the project ends — the PM may not be involved
• Sponsor owns benefits: the sponsor (not the PM) is ultimately accountable for ensuring benefits are realized — PM delivers the product, sponsor delivers the value
• Different from project management plan: Benefits Management Plan is a business document, not a project management subsidiary plan

Source: Benefits Management Plan

Benefits Management

• Benefits ≠ deliverables: delivering the product (output) is not the same as realizing the benefit (outcome) — the benefit comes from using the deliverable
• Benefits after closure: benefits realization often extends beyond project close; PM may hand off benefit tracking to operations or benefit owners
• Business case checkpoint: if benefits are no longer achievable mid-project, the business case is no longer valid and the project should be re-evaluated

Source: Benefits Management

Business Case

• Business case validation is ongoing: wrong = write the business case once and file it; right = re-validate the business case at key decision points throughout the project
• Invalid business case = recommend termination: if the business case is no longer valid (market changed, costs exploded, benefits unreachable), the right answer is to inform the sponsor and recommend stopping the project
• Sequence: business case is written and approved BEFORE the charter — the charter references and links to the approved business case

Source: Business Case

Change Management Plan

• All baseline changes need change control: no exceptions — even urgent changes require a change request before implementation; implement first is always wrong
• CCB is not always a committee: on small projects, the PM may be the CCB for low-impact changes; on large projects, it’s a formal governance body
• Change log vs. change request: change requests are individual submissions; the change log is the running record of all change requests and their status

Source: Change Management Plan

Earned Value Management (EVM)

• Positive vs. negative: CV > 0 = under budget (good); SV > 0 = ahead of schedule (good) — positive variances are favorable
• CPI < 1 = over budget; SPI < 1 = behind schedule — interpret indices the same way: < 1 is bad, > 1 is good
• EAC formula selection: BAC/CPI = assumes past performance continues (most common on exam); AC + (BAC − EV) = assumes remaining work performed at original estimate
• TCPI: the efficiency required to complete within budget — TCPI > 1 means you need to do better than you have been; rarely achievable if CPI is already poor

Source: Earned Value Management (EVM)

Engage Stakeholders

• Engagement is proactive and continuous — not a one-time kickoff activity
• Resistant stakeholders need more engagement, not less — wrong answer is to work around them
• The product owner in agile IS a formal stakeholder engagement mechanism — sprint reviews are stakeholder engagement events

Source: Engage Stakeholders

Generative AI

• Know the nesting: GenAI ⊂ deep learning ⊂ ML ⊂ AI — a question may test that GenAI is the content-generating LLM subset, not a synonym for all AI
• Free vs. paid tools: when proprietary or sensitive data is involved, the deciding factor is data-retraining restrictions (privacy/IP), not cost or output quality
• Unpredictable output is a planning fact: scenarios with GenAI components often reward adaptive/hybrid responses (plan an iteration to analyze results) over fixed predictive specs

Source: Generative AI

Hybrid Development Approach

• Integration overhead: hybrid requires extra effort to integrate adaptive subteam outputs into a predictive reporting baseline — this is a real risk on the exam
• Tailoring justification: choosing hybrid requires explaining which project elements justify each approach — not a default choice
• Governance alignment: hybrid projects often need dual reporting: sprint velocity for agile components + EVM or milestone reports for predictive components

Source: Hybrid Development Approach

Integrated Baseline

• PMB composition: scope + schedule + cost baselines ONLY — management reserve is NOT part of the PMB; contingency reserve IS included in the cost baseline
• Baseline vs. plan: the baseline is the approved snapshot requiring change control; working estimates can be updated without formal change control
• EVM requires a baseline: you cannot calculate SV, CV, SPI, or CPI without the PMB — scenarios asking about performance measurement imply an established baseline

Source: Integrated Baseline

Inverted Triangle

• Adaptive context only: the inverted triangle applies to adaptive/agile projects — wrong answers apply it to predictive scenarios
• Trade-off decision owner: in adaptive, the product owner decides what to cut or defer when constraints are hit — not the PM, not the team
• Budget overrun in adaptive: wrong = expand scope to justify the budget; right = the budget constraint means you deliver less scope, not that you add more

Source: Inverted Triangle

Navigate Complexity

• Complexity is a driver for choosing adaptive or hybrid approaches — high complexity + unclear requirements = adaptive
• Complex projects require more frequent stakeholder engagement and tighter feedback loops, not more detailed upfront plans
• Complexity sources: many stakeholders, unclear requirements, regulatory environment, novel technology, cultural/geographic spread — recognizing these in scenarios is the first step to the right answer

Source: Navigate Complexity

Optimize Risk Responses

• Residual and secondary risks must be planned for — a response that creates a new risk isn’t complete
• Opportunity responses are equally tested: exploit, share, enhance, accept — not just threat responses
• “Accept” is a valid response when cost of response exceeds the risk’s expected monetary value
• Risk response must be proportionate — gold-plating the risk response is as wrong as ignoring the risk

Source: Optimize Risk Responses

Organizational Project Management (OPM)

• PM role in selection: project selection decisions are made at portfolio/program level — the PM implements, not selects; wrong answers have PM pushing back on project selection
• PMO functions: PMO can be supportive (guidance), controlling (compliance), or directive (direct management) — context determines which model applies
• Strategic alignment: projects not aligned with organizational strategy should be flagged; this is a Business Environment Domain responsibility

Source: Organizational Project Management (OPM)

Predictive Development Approach

• Not suitable for high uncertainty: if requirements are unclear or expected to change frequently, predictive is the wrong choice — adaptive or hybrid is more appropriate
• Scope change = change control: in predictive, any change to scope, schedule, or cost baseline requires a formal change request through the CCB
• Inverted triangle distinction: predictive fixes scope; schedule and budget absorb changes — opposite of adaptive

Source: Predictive Development Approach

RACI Chart

• R ≠ A: the person doing the work (Responsible) is not always the owner (Accountable) — they can be different people; wrong answers conflate them
• Only one A per row: multiple people can be Responsible for a deliverable, but accountability must be singular — diffused accountability leads to no accountability
• C vs. I distinction: Consulted = input is sought before the decision/work (two-way); Informed = notified after (one-way) — exam scenarios test whether you’ve selected the right designation

Source: RACI Chart

Requirements Documentation

• Traceability is required: requirements must be traceable — the RTM connects requirements to scope deliverables; when a change is proposed, the RTM shows what else is affected
• Requirements vs. scope: requirements describe the WHAT (stakeholder needs); scope describes the WORK to deliver it — scope is derived from requirements
• Elicitation techniques: interviews, focus groups, facilitated workshops, prototypes, observations — the exam tests which technique fits which situation

Source: Requirements Documentation

Retrospectives

• Retrospective vs. sprint review: retrospective = process improvement (team internal); sprint review = product feedback (with stakeholders) — these are separate events with different participants and purposes
• Wrong answer: “hold a retrospective to gather stakeholder feedback on the product increment” — that describes a sprint review, not a retrospective
• Continuous improvement mechanism: retrospectives are how agile teams improve their velocity, quality, and collaboration over time; skipping them is a process risk

Source: Retrospectives

Risk Register

• Created in Identify Risks, not Plan Risk Management: Plan Risk Management produces the risk management plan (methodology, thresholds); the register is populated when risks are identified
• Residual and secondary risks must be documented: wrong = ignore risks that couldn’t be fully eliminated; right = document and monitor residual risks; also document secondary risks that your responses create
• Risk owner vs. PM: risk owners are responsible for monitoring and triggering their risk responses — the PM does not own all risks; delegation is intentional

Source: Risk Register

Stakeholder Engagement Assessment Matrix

• Current vs. desired: the matrix has two marks per stakeholder — where they are now (C) and where you need them to be (D); gap = engagement action needed
• Leading is not always the target: not every stakeholder needs to reach “Leading” — appropriate engagement level depends on the stakeholder’s role and influence; forcing stakeholders to be more engaged than necessary wastes resources
• Living document: updated throughout the project as engagement levels change; used in monitoring to detect when previously supportive stakeholders become resistant

Source: Stakeholder Engagement Assessment Matrix

Tailoring

• Tailoring is expected: every project should be tailored — the question is HOW MUCH and in what ways, not WHETHER to tailor
• More process ≠ better: wrong = apply all PMBOK processes to every project; right = apply only processes that add value for this specific project’s context
• Tailoring is justified: in exam scenarios, choosing to skip a formal process must be justified by project context (size, risk, complexity) — arbitrary simplification is wrong

Source: Tailoring

Work Breakdown Structure (WBS)

• WBS is deliverable-oriented, not activity-oriented: activities belong in the activity list and schedule; the WBS shows WHAT will be produced, not HOW
• 100% Rule: the WBS must capture 100% of project scope — anything not in the WBS is out of scope; anything in scope must appear in the WBS
• Work packages: the lowest level of the WBS; activities are decomposed FROM work packages, not shown in the WBS itself
• Adaptive equivalent: in agile, the product backlog replaces the WBS as the scope decomposition tool

Source: Work Breakdown Structure (WBS)

---

Plain-text copy, for sending or printing: https://pmpilot.devops4pm.com/pmp-rules.txt