PMPA common mistakes
PMPA · Understand the traps and how to avoid them.
Treating the PMPA as a generic agile or generic waterfall exam and answering from habit - for example, assuming every change request must go through a formal CCB, or that every requirement must be captured in a WBS - instead of reading what the scenario's project life cycle and governance actually imply.
Candidates often have deep experience in one delivery model and pattern-match scenarios to it. The exam deliberately mixes predictive, hybrid, and adaptive contexts, and the 'best' answer depends on the stated environment, not on the candidate's home methodology.
What to do instead
Before choosing, extract two facts from the stem: the life cycle type (predictive/hybrid/adaptive) and the governance constraint (who approves change, who owns scope). Eliminate any option that contradicts those two facts, even if it is a textbook best practice in another context. Practice by rewriting 20 stems into a one-line 'context summary' before answering.
Jumping to the project charter or scope statement without first confirming the business case, benefits, and the sponsor's authority - answering 'write the charter' when the stem shows the business case is unapproved or the sponsor has not committed funding.
Charter creation feels like the obvious 'first step' in initiation, so candidates select it reflexively. The exam tests whether you sequence authorization correctly: no charter without an approved business case and an identified sponsor who can authorize it.
What to do instead
Memorize the authorization chain - need/opportunity → business case → benefits and funding commitment → sponsor designation → charter. When a stem shows a missing upstream element, the correct action is to obtain or validate that element, not to proceed. Build a one-page flow and check every initiation question against it.
Confusing stakeholder analysis outputs: producing a power/interest grid when the scenario calls for engagement assessment (current vs. desired engagement), or treating a resistant stakeholder as a communications problem rather than an engagement problem.
Both tools live in the same knowledge area and both produce 'stakeholder documents', so candidates blur them. The exam distinguishes classification (who matters) from engagement planning (how to move someone from resistant to supportive).
What to do instead
Learn the distinct purpose of each artifact: stakeholder register = identify and classify; power/interest grid = prioritization; engagement assessment matrix = current vs. desired engagement with named strategies. When a stem mentions resistance, look for an option that changes engagement level through targeted involvement, not one that merely increases reporting frequency.
Accepting scope changes informally - choosing 'update the scope statement' or 'notify the team' when the scenario shows an unapproved change already being built - instead of selecting the option that routes the change through integrated change control and assesses impact on scope, schedule, cost, and risk.
Candidates want to be helpful and keep the project moving, and 'do the work then document it' sounds pragmatic. The exam scores process integrity: changes are evaluated before implementation, and approval precedes baseline updates.
What to do instead
Apply a fixed three-step test to every change scenario: (1) evaluate impact across baselines, (2) obtain approval from the authorized body or person, (3) update baselines and documents. Any option that reverses this order is wrong. Also check whether the change is a defect (rework, no change request) versus a scope change (change request required).
Using the critical path method as a cost or resource tool - assuming the critical path is the most expensive path, the riskiest path, or the path with the most resources - and misreading total float as free float when computing schedule flexibility.
Critical path, critical chain, and float terminology overlap, and candidates memorize 'longest path' without internalizing what float measures. Stems that add resource constraints or lag/lead tempt answers based on the wrong concept.
What to do instead
Anchor on definitions: critical path = longest total duration path, zero total float; total float = how long an activity can slip without delaying the project finish; free float = slip without delaying the next successor. Recompute float from the network in the stem rather than recalling a rule. When resources are constrained, recognize that critical chain (not critical path) accounts for resource contention and buffers.
Choosing 'crash' or 'fast-track' as a schedule-compression answer without checking whether the stem permits added cost, added risk, or rework - and without first confirming that the critical path, not a non-critical path, is being compressed.
Compression techniques are taught as the standard remedy for late schedules, so candidates apply them unconditionally. The exam tests the trade-offs: crashing costs money and can add risk; fast-tracking adds rework risk; compressing a non-critical path shortens nothing.
What to do instead
Before selecting compression, verify three things in the stem: the delay is on the critical path, budget or risk tolerance allows the trade-off, and the option names the trade-off explicitly. If the stem says budget is fixed and risk appetite is low, look for scope negotiation or re-baselining instead.
Treating quality control and quality assurance as interchangeable - choosing 'inspect the deliverables' when the stem describes a process problem causing repeated defects, or choosing 'audit the process' when a finished deliverable must be verified against acceptance criteria.
Both are 'quality', and candidates default to inspection because it feels concrete. The exam separates prevention (assurance, process-focused) from detection (control, product-focused) and expects the answer to match the source of the problem.
What to do instead
Ask: is the problem in how work is done (process → quality assurance, audits, process improvement) or in what was produced (product → quality control, inspection, testing)? Also distinguish cost of prevention/appraisal from cost of internal/external failure when the stem discusses quality costs.
Answering resource or communications scenarios with a document instead of an action - writing a RACI chart, updating the communications plan, or sending a status report when the stem shows an unresolved interpersonal conflict, an overloaded team member, or a stakeholder who has never been consulted.
Documentation is safe and easy to justify, so it becomes a default. The exam rewards the direct interpersonal or managerial action first (meet, negotiate, coach, escalate with evidence), with documentation as a follow-up.
What to do instead
Rank options by directness: talk to the person and resolve, then apply the tool or document, then escalate. Escalation is correct only when the stem shows the PM lacks authority or the issue exceeds their control. For communications, check whether the stem's problem is content, timing, channel, or relationship - the fix differs.
Handling risk by responding to a realized issue as if it were still a risk - or choosing 'avoid' when the stem's only feasible response is 'mitigate' or 'transfer' - and ignoring secondary and residual risks created by the chosen response.
Risk and issue management share vocabulary, and candidates pick the strongest-sounding strategy. The exam tests whether you match the response to probability, impact, and feasibility, and whether you recognize that a response itself creates new risk.
What to do instead
First classify: has the event happened? If yes, it is an issue (use the issue log and corrective action); if not, it is a risk (use the risk register and a response strategy). Then test feasibility: avoid only if the activity can be eliminated; transfer only if a third party accepts the risk for a price; mitigate only if probability or impact can be reduced. Always ask what secondary risk the response introduces.
Closing the project or phase without verifying that contractual and acceptance obligations are complete - releasing the team, archiving documents, and celebrating before final acceptance, procurement closure, and lessons-learned capture are done.
Closure feels like an administrative formality, so candidates pick 'release resources' or 'celebrate' as the final step. The exam sequences closure: verify acceptance, settle contracts and claims, transition the product, capture lessons, then release resources.
What to do instead
Memorize the closure order: confirm all deliverables accepted against criteria → close procurements and resolve claims → obtain formal sign-off → transition/operational handover → capture and share lessons learned → release team and archive records. When a stem shows an unfinished contract or unaccepted deliverable, no closure action is correct until that is resolved.