How to Use This Quick Reference
This independent Quick Reference supports candidates preparing for the PMI Project Management Professional (PMP) - 2026 Exam Refresh, exam code PMP. Use it to review high-yield PMP decision logic, lifecycle distinctions, artifacts, formulas, and common scenario traps.
PMP questions often ask what the project manager, product owner, servant leader, sponsor, or team should do next. The best answer is usually the one that:
- Protects business value and project objectives.
- Follows the agreed governance approach.
- Uses collaboration before escalation.
- Assesses impact before acting.
- Respects the delivery approach: predictive, agile, or hybrid.
- Addresses root causes, not only symptoms.
- Maintains transparency with stakeholders.
PMP Scenario Mindset
| If the question says… | Think first | Usually avoid |
|---|
| “What should the project manager do first?” | Assess, review relevant artifact, consult team/stakeholders | Immediately escalate, replace people, approve change alone |
| “A stakeholder requests a change” | Log/evaluate the change; use change control if baseline is affected | Implementing without impact analysis |
| “An agile team receives a new feature request” | Product owner evaluates and prioritizes backlog | Forcing a fixed-scope change process unless governance requires it |
| “Team conflict occurs” | Facilitate discussion, identify root cause, collaborate | Punishment, avoidance, escalation as first step |
| “A risk occurs” | If identified, execute planned response; if not, create workaround and update records | Ignoring because it was not in the plan |
| “Performance is behind schedule” | Analyze causes and options; use approved compression or adaptive reprioritization | Adding people automatically |
| “Customer rejects deliverable” | Clarify acceptance criteria, validate scope/control quality distinction | Blaming customer or bypassing acceptance process |
| “Vendor problem occurs” | Review contract, procurement documents, and escalation path | Informal side agreements that bypass contract terms |
| “Regulatory, safety, or ethical concern” | Act transparently and responsibly; follow required reporting path | Concealment, shortcuts, retaliation |
Delivery Approach Selector
| Approach | Best fit | Planning style | Change handling | Team/customer interaction | Exam cues |
|---|
| Predictive | Stable requirements, known technology, regulated or contract-heavy work | Detailed upfront planning and baselines | Formal change control after baselines | Periodic reviews, phase gates, sign-offs | WBS, baselines, change control board, critical path |
| Agile | Evolving requirements, high uncertainty, need for frequent feedback | Adaptive planning, iterative/incremental delivery | Product backlog reprioritization | Continuous collaboration, frequent demos | Sprints, backlog, product owner, velocity, servant leadership |
| Hybrid | Some stable components and some adaptive components | Mix of upfront roadmap and iterative elaboration | Formal governance for fixed elements; backlog for adaptive elements | Combined phase gates and iterative feedback | Hardware plus software, fixed compliance needs with evolving features |
| Incremental | Deliver usable portions progressively | Release-focused | Future increments can change | Feedback after each increment | MVP, releases, value delivery |
| Iterative | Refine solution through repeated cycles | Learning-focused | Design evolves through feedback | Frequent inspection and adaptation | Prototypes, uncertainty, discovery |
| Lean/Kanban | Flow efficiency, operational or service work | Continuous prioritization | Pull-based flow; WIP limits | Visual workflow and bottleneck management | Cycle time, throughput, Kanban board, WIP |
“What Should the Manager Do Next?” Decision Table
| Situation | Best next action | Why |
|---|
| New issue appears | Analyze impact, document, engage appropriate people | PMP favors informed action |
| Stakeholder is unhappy | Meet to understand concern and expectations | Manage engagement before escalation |
| Sponsor asks for extra scope | Document request and assess impact | Sponsor authority does not bypass governance |
| Team member lacks skill | Coach, train, pair, or remove impediment | Servant leadership and team development |
| Functional manager pulls a resource | Discuss impact, negotiate, update plans if needed | PM manages constraints and relationships |
| Critical vendor delay | Review contract, assess schedule impact, discuss recovery options | Procurement terms matter |
| Agile team cannot finish sprint work | Facilitate team discussion; product owner may adjust scope | Team owns sprint plan; PO owns priority |
| Customer wants early value | Consider MVP, phased release, or backlog reprioritization | Value delivery over rigid output |
| Defect found before delivery | Follow quality process, fix root cause, update lessons learned | Prevention and continuous improvement |
| Risk trigger occurs | Execute risk response plan | Risk planning is actionable |
| Unknown risk becomes issue | Implement workaround, update issue/risk records | Unplanned risks need active management |
| Stakeholder bypasses PM and directs team | Clarify communication and decision paths | Protects team focus and governance |
| Ethical concern | Gather facts, act honestly, report through proper channels | PMI ethics emphasize responsibility, fairness, honesty, respect |
Role Reference
| Role | Primary responsibility | High-yield distinction |
|---|
| Project manager | Integrates work, stakeholders, constraints, risks, delivery approach | Does not make every technical or product decision alone |
| Sponsor | Provides authority, funding, strategic direction, escalation support | Owns business need and major approvals |
| Product owner | Maximizes product value and prioritizes product backlog | In agile, owns “what” and priority, not “how” |
| Scrum master / agile lead | Servant leader, removes impediments, coaches agile practices | Does not assign tasks command-and-control style |
| Project team | Performs work, estimates, self-organizes where appropriate | Cross-functional ownership is key in agile |
| Customer/user | Defines needs, provides feedback, accepts value | Acceptance criteria matter |
| PMO | Provides standards, governance, support, methods, or direct control depending on type | PMO authority varies by organization |
| Functional manager | Manages department resources and technical staff assignments | Common source of matrix conflict |
| Change control board | Reviews and approves/rejects significant changes in governed environments | Not used for every agile backlog reorder unless required |
| Business analyst | Elicits, analyzes, and manages requirements | Helps bridge stakeholder needs and solution requirements |
| Procurement officer/legal support | Supports contracting, compliance, claims, and seller management | PM should not ignore procurement process |
Lifecycle and Process Flow
| Stage / Process group concept | Main purpose | Common artifacts | PMP trap |
|---|
| Initiating | Authorize project or phase; identify key stakeholders | Business case, benefits documents, project charter, stakeholder register | Starting execution before charter/authorization |
| Planning | Define scope, approach, baselines, governance, risk responses | Management plans, scope baseline, schedule, budget, risk register | Treating the plan as static rather than progressively elaborated |
| Executing | Perform work and manage people, communications, quality, procurements | Deliverables, team assessments, issue log, work performance data | PM doing all work instead of enabling the team |
| Monitoring and controlling | Compare performance to plan; manage changes and variances | Work performance reports, change requests, forecasts | Skipping impact analysis |
| Closing | Confirm completion, transition deliverables, close contracts, capture learning | Accepted deliverables, final report, lessons learned, archived records | Forgetting formal acceptance and knowledge transfer |
Predictive Artifact Map
| Artifact | What it answers | Use when | Do not confuse with |
|---|
| Business case | Why should the organization invest? | Project selection and justification | Project charter |
| Benefits management plan | How and when benefits will be realized | Value tracking beyond delivery | Schedule baseline |
| Project charter | Who authorizes the project and PM? | Initiation | Detailed project management plan |
| Project management plan | How the project will be managed | Integrated planning | A single schedule file |
| Scope statement | What is included/excluded? | Scope definition | Requirements documentation |
| WBS | How is scope decomposed into deliverables/work packages? | Planning and control | Activity list |
| WBS dictionary | Details for WBS components | Clarifying work packages | Requirements traceability matrix |
| Requirements traceability matrix | How requirements map to deliverables/tests | Managing requirement changes | Stakeholder register |
| Schedule baseline | Approved schedule model | Measuring schedule variance | Preliminary timeline |
| Cost baseline | Approved time-phased budget excluding management reserve | Cost control | Total project funding |
| Risk register | Individual risks and responses | Risk management | Issue log |
| Issue log | Current problems requiring action | Execution/control | Risk register |
| Change log | Status of change requests | Integrated change control | Backlog |
| Lessons learned register | Learning captured during project | Continuous improvement | Final retrospective only |
| Stakeholder engagement plan | Desired engagement strategies | Stakeholder management | Communications management plan |
| Communications management plan | Who gets what information, when, how | Information flow | Stakeholder analysis itself |
Agile and Hybrid Artifact Map
| Artifact / concept | Purpose | Exam note |
|---|
| Product vision | Shared direction for product value | Aligns backlog decisions |
| Product roadmap | High-level expected evolution | Less detailed than release/sprint plan |
| Product backlog | Ordered list of product work | Product owner prioritizes |
| Sprint backlog | Work selected for current sprint | Development team owns execution |
| Increment | Potentially releasable product outcome | Must meet definition of done |
| Definition of done | Shared quality/completion standard | Prevents hidden unfinished work |
| Definition of ready | Optional readiness criteria for backlog items | Helps avoid sprint churn |
| MVP | Smallest useful release to validate value | Not low quality; it is minimal viable value |
| Burnup chart | Work completed vs total scope | Shows scope changes clearly |
| Burndown chart | Remaining work over time | Useful for sprint/release tracking |
| Cumulative flow diagram | Flow, WIP, bottlenecks | Kanban/flow-oriented |
| Information radiator | Visible project/team information | Promotes transparency |
| Retrospective action items | Improvement experiments | Should be acted on, not merely recorded |
Integrated Change Control
Use formal integrated change control when a requested change affects approved baselines, constraints, contracts, or governance commitments.
flowchart TD
A[Change request received] --> B[Document request]
B --> C[Assess impact on scope, schedule, cost, quality, risk, resources, procurement, stakeholders]
C --> D{Baseline or governance impact?}
D -- No --> E[Handle within team authority and update records]
D -- Yes --> F[Submit to change control process]
F --> G{Approved?}
G -- Yes --> H[Update baselines/plans and communicate]
G -- No --> I[Record decision and communicate]
H --> J[Implement and monitor]
I --> J
| Change scenario | Predictive response | Agile/adaptive response |
|---|
| Customer requests new feature | Log change, impact analysis, CCB/approval if baseline affected | Product owner evaluates and orders backlog |
| Defect against accepted criteria | Corrective action; may not be scope change | Fix according to definition of done/quality policy |
| Regulatory requirement changes | Analyze mandatory impact; seek approval and replan | Reprioritize backlog and adapt release plan |
| Team discovers better technical approach | Assess impact; may be preventive/corrective change | Team may adapt design if product goals and standards remain met |
| Sponsor demands faster finish | Analyze options: crashing, fast tracking, descoping, phased delivery | Reprioritize for highest value; consider MVP/release slicing |
Scope, Requirements, and Acceptance
| Concept | Definition | Exam distinction |
|---|
| Requirement | Condition or capability needed by stakeholder/product | Must be elicited, analyzed, prioritized, and traced |
| Scope | Work and deliverables required to meet objectives | Product scope plus project work |
| Product scope | Features/functions of product/service/result | Validated by customer/user needs |
| Project scope | Work required to deliver product scope | Managed through WBS in predictive work |
| Acceptance criteria | Conditions deliverable must meet to be accepted | Prevents subjective acceptance disputes |
| Validate scope | Formal acceptance of completed deliverables | Customer/sponsor acceptance focus |
| Control quality | Check correctness of deliverables | Internal quality verification focus |
| Gold plating | Adding unrequested features | Usually wrong even if intended to please customer |
| Scope creep | Uncontrolled expansion of scope | Prevent through change control/backlog discipline |
Schedule and Estimating Reference
| Topic | Key points | Exam use |
|---|
| Rolling wave planning | Plan near-term work in detail, future work at higher level | Uncertain or long projects |
| Progressive elaboration | Continuously refine information as more is known | Not uncontrolled change |
| Decomposition | Break deliverables/work into smaller components | WBS and activity planning |
| Analogous estimating | Uses similar past projects; fast, less precise | Early estimates |
| Parametric estimating | Uses statistical relationship, e.g., cost per unit | Scalable when data is reliable |
| Three-point estimating | Optimistic, most likely, pessimistic | Uncertainty-aware estimates |
| Bottom-up estimating | Estimate detailed components then aggregate | More accurate, more effort |
| Critical path | Longest path through network; determines shortest project duration | Activities on critical path usually have zero total float |
| Total float | LS - ES or LF - EF | Delay allowed without delaying project finish |
| Free float | Delay allowed without delaying successor | More local than total float |
| Lead | Acceleration/overlap between activities | “Start successor 2 days before predecessor finishes” |
| Lag | Waiting time between activities | “Wait 3 days after concrete pour” |
| Fast tracking | Perform activities in parallel | Adds risk/rework |
| Crashing | Add resources to shorten duration | Adds cost; only works on compressible critical path work |
| Resource leveling | Adjust schedule to resource constraints | May change critical path/end date |
| Resource smoothing | Adjust within float | Does not change critical path/end date |
| Formula | Meaning | Interpretation |
|---|
| EV = percent complete x BAC | Earned value | Budgeted value of completed work |
| PV | Planned value | Budgeted value of scheduled work |
| AC | Actual cost | Actual cost incurred |
| SV = EV - PV | Schedule variance | Positive = ahead; negative = behind |
| CV = EV - AC | Cost variance | Positive = under budget; negative = over budget |
| SPI = EV / PV | Schedule performance index | Greater than 1 = ahead; less than 1 = behind |
| CPI = EV / AC | Cost performance index | Greater than 1 = efficient; less than 1 = inefficient |
| EAC = BAC / CPI | Forecast if current cost efficiency continues | Common simple EAC |
| EAC = AC + ETC | Forecast using new estimate to complete | Use when original estimate is no longer valid |
| EAC = AC + (BAC - EV) | Future work expected at original rate | Past variance not expected to continue |
| EAC = AC + (BAC - EV) / (CPI x SPI) | Cost and schedule inefficiency both affect future | More conservative when both matter |
| ETC = EAC - AC | Estimate to complete | Expected remaining cost |
| VAC = BAC - EAC | Variance at completion | Positive = under budget |
| TCPI = (BAC - EV) / (BAC - AC) | Efficiency needed to meet BAC | If unrealistic, rebaseline/change may be needed |
| TCPI = (BAC - EV) / (EAC - AC) | Efficiency needed to meet EAC | Used against revised forecast |
| ROI = (benefit - cost) / cost | Return on investment | Higher is better |
| BCR = benefits / costs | Benefit-cost ratio | Greater than 1 generally favorable |
| PERT expected duration = (O + 4M + P) / 6 | Weighted three-point estimate | Most likely estimate has highest weight |
| Standard deviation = (P - O) / 6 | PERT uncertainty approximation | Larger means more uncertainty |
Quality Reference
| Concept | Meaning | PMP trap |
|---|
| Quality | Degree to which requirements are met | High grade is not the same as high quality |
| Grade | Category or rank of features | Low grade can still be high quality if requirements are met |
| Prevention | Build quality in | Preferred over inspection |
| Inspection | Find defects after work is done | Necessary but less efficient than prevention |
| Cost of conformance | Prevention and appraisal costs | Spending to avoid defects |
| Cost of nonconformance | Internal/external failure costs | Defects, rework, warranty, reputation loss |
| Quality assurance / manage quality | Process improvement and audit orientation | Focus on how work is performed |
| Quality control | Inspect/test deliverables | Focus on results |
| Accuracy | Closeness to true value | Different from precision |
| Precision | Repeatability/tight grouping | Can be precise but inaccurate |
| Control chart | Shows process stability over time | Out-of-control signals need investigation |
| Pareto chart | Prioritizes causes by frequency/impact | “Vital few” |
| Ishikawa/fishbone | Root cause analysis | Cause categories |
| Checksheet | Data collection tally | Not a trend chart |
| Scatter diagram | Relationship between variables | Correlation is not causation |
Risk and Issue Reference
| Item | Definition | Exam action |
|---|
| Risk | Uncertain event/condition that may affect objectives | Identify, analyze, plan responses |
| Issue | Current problem or event that has occurred | Assign owner, action, due date |
| Trigger | Warning sign that risk is about to occur | Execute response when trigger appears |
| Risk appetite | Organization’s general willingness to accept risk | Guides decisions |
| Risk threshold | Specific measurable limit | Escalate or act when exceeded |
| Risk register | Individual risks, owners, responses | Updated throughout project |
| Risk report | Overall risk exposure and trends | Useful for sponsor/governance |
| Residual risk | Risk remaining after response | May be accepted or further managed |
| Secondary risk | New risk caused by response | Add to risk register |
| Contingency reserve | For identified risks | Usually included in cost/schedule baseline |
| Management reserve | For unknown-unknowns | Controlled by management; not the cost baseline |
| Workaround | Response to an unplanned issue | Used when no planned response exists |
Risk Response Strategies
| For threats | Meaning |
|---|
| Avoid | Eliminate threat or protect objective from impact |
| Mitigate | Reduce probability and/or impact |
| Transfer | Shift ownership/impact to third party, often contract/insurance |
| Accept | Take no proactive action beyond monitoring or reserves |
| Escalate | Move outside project authority to appropriate level |
| For opportunities | Meaning |
|---|
| Exploit | Ensure opportunity occurs |
| Enhance | Increase probability and/or impact |
| Share | Partner to capture opportunity |
| Accept | Take advantage if it occurs |
| Escalate | Move outside project authority |
Stakeholder and Communications Reference
| Concept | Purpose | Exam distinction |
|---|
| Identify stakeholders | Find people/groups affected by or able to affect project | Revisit throughout project |
| Stakeholder register | Stakeholder information and attributes | Sensitive; handle appropriately |
| Power/interest grid | Prioritize engagement effort | High power/high interest = manage closely |
| Engagement assessment matrix | Current vs desired engagement | Supports engagement planning |
| Communications management plan | Information needs, format, frequency, sender, receiver | Not all stakeholders need all details |
| Push communication | Sent to recipients | Email, memo; does not guarantee understanding |
| Pull communication | Recipient accesses as needed | Portal, repository |
| Interactive communication | Real-time exchange | Best for complex or sensitive topics |
| Communication channels | n(n - 1) / 2 | More people means more complexity |
| Active listening | Confirm understanding | Essential for conflict and stakeholder resistance |
| Transparency | Make work/status visible | Especially high-yield in agile/hybrid |
Team, Leadership, and Conflict
| Topic | PMP-preferred behavior |
|---|
| Servant leadership | Remove impediments, coach, enable team ownership |
| Psychological safety | Encourage candor, learning, and early problem disclosure |
| Empowerment | Let competent teams decide how to do the work |
| Motivation | Understand individual needs; use recognition appropriately |
| Coaching | Develop capability before replacing/escalating |
| Training | Close skill gaps proactively |
| Colocation / virtual collaboration | Choose communication methods that support team effectiveness |
| Conflict | Address early, privately when appropriate, and collaboratively |
| Negotiation | Seek win-win agreements where possible |
| Decision-making | Use data, team input, and governance authority |
| Diversity and inclusion | Leverage different perspectives; avoid bias |
| Conflict technique | Use when | Caution |
|---|
| Collaborate/problem solve | Important issue, time available | Usually best long-term |
| Compromise/reconcile | Need acceptable middle ground | May not fully satisfy either side |
| Smooth/accommodate | Preserve relationship, low-stakes issue | Can leave root cause unresolved |
| Force/direct | Emergency or compliance need | Can damage commitment |
| Withdraw/avoid | Cooling-off or trivial issue | Usually weak if used to dodge real conflict |
Procurement and Contract Types
| Contract type | Buyer risk | Seller risk | Best fit |
|---|
| Firm fixed price (FFP) | Lower | Higher | Clear scope and stable requirements |
| Fixed price incentive fee (FPIF) | Low-medium | Medium | Cost/schedule incentives useful |
| Fixed price economic price adjustment (FP-EPA) | Medium | Medium | Long duration with inflation/price uncertainty |
| Cost plus fixed fee (CPFF) | Higher | Lower | Uncertain scope; seller fee fixed |
| Cost plus incentive fee (CPIF) | Medium-high | Medium | Shared cost targets/incentives |
| Cost plus award fee (CPAF) | Higher | Lower-medium | Subjective performance award criteria |
| Time and materials (T&M) | Medium-high | Medium | Staff augmentation or undefined level of effort |
| Procurement situation | Best response |
|---|
| Seller misses milestone | Review contract, communicate formally, assess remedies |
| Scope ambiguity in contract | Clarify through procurement process; avoid informal expansion |
| Claim/dispute | Follow contract claims administration path |
| Need specialized skill temporarily | Consider T&M or staff augmentation if appropriate |
| Well-defined commodity purchase | Fixed price often fits |
| Build-or-buy decision | Compare internal capability, cost, risk, schedule, strategic value |
Agile Events, Metrics, and Decision Points
| Agile item | Purpose | Exam note |
|---|
| Sprint planning | Select sprint goal and work | Team forecasts work; PO clarifies priority |
| Daily standup | Inspect progress toward sprint goal | Not a status meeting for the PM |
| Sprint review | Demonstrate increment and get feedback | Stakeholder collaboration event |
| Retrospective | Improve process and teamwork | Actions should feed future work |
| Backlog refinement | Clarify, split, estimate upcoming work | Ongoing, not a one-time phase |
| Velocity | Amount of work completed per iteration | Planning aid, not a performance weapon |
| Cycle time | Time for one item to move through workflow | Flow efficiency |
| Lead time | Time from request to delivery | Customer-facing responsiveness |
| WIP limit | Caps work in progress | Exposes bottlenecks and improves flow |
| Story points | Relative size/complexity | Not directly comparable across teams |
| MoSCoW | Must, Should, Could, Won’t | Prioritization support |
| WSJF | Weighted shortest job first | Prioritizes high value/time-critical small jobs |
Value, Benefits, and Product Thinking
| Concept | What it helps decide |
|---|
| Business value | Whether work contributes to desired outcomes |
| Benefits realization | Whether delivered outputs produce expected benefits |
| MVP | What is the smallest useful release for learning/value? |
| Prioritization | What should be done first when capacity is limited? |
| Opportunity cost | What value is lost by choosing one option over another? |
| Product roadmap | How value may evolve over time |
| Release planning | When increments of value may be delivered |
| Feedback loop | Whether assumptions are valid |
| Pivot/persevere decision | Whether to change direction based on evidence |
Tailoring Reference
| Tailoring question | Consider |
|---|
| How much documentation is enough? | Risk, compliance, stakeholder needs, team size, complexity |
| How formal should change control be? | Baseline stability, contract terms, governance, regulatory impact |
| Which lifecycle fits? | Requirement certainty, technology uncertainty, delivery cadence, customer availability |
| How should stakeholders be engaged? | Power, interest, influence, impact, current vs desired engagement |
| How should progress be measured? | Predictive baselines, agile value increments, flow metrics, hybrid reporting |
| How should risk be managed? | Risk exposure, thresholds, organizational appetite |
| How much planning upfront? | Uncertainty level and cost of change |
| What governance is needed? | Organizational standards, sponsor needs, compliance, funding model |
High-Yield Distinctions
| Distinction | Know this |
|---|
| Corrective action vs preventive action | Corrective fixes current variance; preventive reduces chance of future variance |
| Defect repair vs change request | Defect repair fixes nonconformance; change request may alter baseline/scope |
| Validate scope vs control quality | Validate scope gets formal acceptance; control quality checks correctness |
| Issue vs risk | Issue has occurred; risk is uncertain |
| Risk audit vs risk review | Audit checks effectiveness of risk process; review updates risk status/exposure |
| Manage communications vs monitor communications | Manage distributes information; monitor ensures needs are met |
| Manage stakeholder engagement vs monitor stakeholder engagement | Manage works with stakeholders; monitor assesses relationships/strategies |
| Work performance data/information/reports | Data = raw observations; information = analyzed; reports = formatted for decisions |
| Leadership vs management | Leadership inspires/enables; management plans/controls |
| Product owner vs project manager | PO prioritizes product value; PM integrates project delivery/governance |
| Agile change vs predictive change | Agile reprioritizes backlog; predictive protects baselines through control |
| Lessons learned register vs repository | Register is active during project; repository is organizational archive |
Common PMP Traps
| Trap answer | Why it is usually wrong |
|---|
| Escalate immediately | PM should often analyze, collaborate, or attempt resolution first |
| Fire or replace a team member | Coaching and root-cause analysis usually come first |
| Accept stakeholder demand without review | Bypasses governance and impact analysis |
| Ignore a minor stakeholder | Stakeholders can gain influence or create risk |
| Add resources to a late project automatically | May increase cost/communication burden and not help critical path |
| Compress schedule without checking critical path | Non-critical activities may not improve finish date |
| Use agile to avoid planning | Agile still requires planning, prioritization, and discipline |
| Use predictive control for every agile backlog item | Adaptive work expects reprioritization |
| Gold plate to satisfy customer | Adds unauthorized scope and risk |
| Hide bad news until fixed | Violates transparency and can worsen impact |
| Measure agile teams by utilization only | Value, flow, quality, and outcomes matter |
| Treat retrospective as optional | Continuous improvement is central to adaptive delivery |
| Confuse sponsor with customer | Sponsor funds/champions; customer/user accepts or uses deliverable |
Final Review Checklist
Before the exam, make sure you can quickly answer:
- Is the scenario predictive, agile, or hybrid?
- Is this a risk, issue, change request, defect, or stakeholder problem?
- Which artifact should be reviewed or updated?
- Who owns the decision: PM, sponsor, product owner, team, CCB, customer, or seller?
- Should the next step be assess, facilitate, update, escalate, approve, or implement?
- Does the answer preserve transparency, ethics, value, and governance?
- Are scope, schedule, cost, quality, risk, resources, procurement, communications, and stakeholders considered before acting?
- Would the best answer solve the root cause rather than the symptom?
Practical Next Step
Use this Quick Reference after each practice set: tag every missed PMP question by lifecycle approach, role, artifact, and decision type, then drill similar scenario questions until the correct “next action” becomes automatic.