APM PMQ common mistakes
APM PMQ · Understand the traps and how to avoid them.
Answers 'explain why this is a project' questions with a memorised definition ('a unique, transient endeavour to achieve planned objectives') and never applies those features to the facts in the scenario, so the answer could belong to any case study.
Candidates revise the Body of Knowledge definitions in isolation and under exam pressure reproduce them verbatim, because a definition feels like a safe, complete answer and they fear misreading the case.
What to do instead
Turn the definition into a checklist and work it against the case: for each of unique / transient / defined objectives and deliverables / team and resources / uncertainty, quote the specific fact from the scenario that satisfies or contradicts it. Practise by taking any past case study and writing five one-line 'because in this case...' justifications rather than a paragraph of theory.
Lists governance bodies and roles ('sponsor, project manager, steering group, PMO') side by side as if they were interchangeable, without stating the decision rights, accountability or escalation route attaching to each, and often places budget ownership with the project manager.
Role titles are easy to recall and feel substantive, so candidates pad answers with names. The distinction between accountability and delegated responsibility is genuinely subtle and is rarely tested by simply reading the manual.
What to do instead
For every role in an answer, write three things: what they are accountable for, what decision only they can make (e.g. authorising the use of contingency, approving a change above tolerance), and who they escalate a breach of tolerance to. Anchor it to the scenario's own board or sponsor and state explicitly where the project manager's delegated authority stops.
Draws or describes a power/interest grid, then stops. The engagement strategy for each quadrant is omitted, or every stakeholder gets the same treatment ('regular updates'), and the communication plan is reduced to a list of channels with no owner, frequency or feedback mechanism.
Grids are visual, memorable revision content and candidates treat plotting the stakeholder as the answer. The applied step - converting a position on the grid into a tailored set of actions - is the part that carries the marks and is the part candidates skip when time is short.
What to do instead
For each named stakeholder in the case, complete a one-line profile: position on power/interest, what they need to know, preferred channel and frequency, who owns the relationship, and how their reaction is captured and fed back. Answer 'how would you engage X' with actions specific to X, not a generic comms list.
Confuses closely paired scheduling and resource concepts and swaps them in the answer - product breakdown structure with work breakdown structure, resource levelling with resource smoothing, or 'create a Gantt chart' offered as scope definition with no decomposition of deliverables.
The pairs sound similar, are taught close together, and both halves of each pair are legitimate tools, so a half-remembered answer still reads plausibly to the candidate. There is no immediate penalty for the confusion in practice, so it survives revision.
What to do instead
Build a contrast table for each confusing pair with three columns: what it is, what it does to time/cost, and when you would use it instead of its partner. Learn one worked micro-example for each (e.g. smoothing keeps the end date fixed and moves float; levelling may extend the end date to respect resource limits) and quote that example in the exam.
Uses 'contingency', 'management reserve', 'budget' and 'cost baseline' as synonyms, and misstates earned value formulae - commonly writing CV = EV − PV, or presenting a negative variance without saying what it means for the project.
The terminology overlaps in ordinary business speech, and the formulae look interchangeable when recalled by shape rather than by meaning. Candidates also forget that the marker wants an interpretation, not just an arithmetic output.
What to do instead
Memorise each term with who holds it and who authorises its use (contingency held by the project manager for identified risks; management reserve held above the project for unidentified risks), then learn the four formulae as sentences: 'cost variance is earned value minus actual cost'. In any EV answer, state the value, whether it is favourable or adverse, and the action it triggers.
Treats risks and issues as the same thing, describing a problem that has already happened as a risk; omits the distinction between the risk owner (accountable for managing the risk) and the risk action owner (delivers the response); and offers 'monitor it' as a response instead of naming avoidance, reduction, transfer, acceptance, exploitation or sharing.
In everyday language 'risk' covers bad things that have occurred. The owner/action-owner split is a fine-grained point that is easy to skim, and 'monitor' feels prudent and safe when a candidate is unsure which response category applies.
What to do instead
Before writing, classify each item in the question as a threat or opportunity that has not yet happened (risk) or something that has already occurred (issue), and say so explicitly. For every risk named, give the response category, the action, the action owner and the owner who reports it, plus the trigger that would escalate it to an issue.
Answers quality questions with quality control only - inspecting and testing the finished work - and never mentions quality planning (standards, acceptance criteria) or quality assurance (process review and audit). Quality gates and acceptance criteria are absent from answers about sign-off.
Testing and inspection are the visible, familiar end of quality, so they come to mind first and fill the answer. Assurance is abstract activity that happens in the background, so it is under-revised and easily forgotten under time pressure.
What to do instead
Structure every quality answer around the three-part cycle: plan (which standard, whose acceptance criteria, defined at what point), assure (how you will confirm the process is capable, who reviews it, how often), control (what is measured, against what tolerance, what happens on a fail). Then attach each part to a named activity from the scenario so the answer is specific.
Describes change control as 'fill in a change request form and get it approved', omitting impact assessment across scope, schedule, cost, risk and quality, the decision by the change authority against tolerances, and the baseline update. Configuration management is either ignored or treated as an inbox for change requests.
Change control is remembered as a paperwork route because that is the visible artefact. Configuration management (identification of items, status accounting, verification) is the least familiar of the ten areas and is often revised last or not at all.
What to do instead
Write the change process as a numbered chain every time: raise, log, assess impact on all five constraints, recommend, decide at the correct authority, implement, update the baseline and the configuration record, inform stakeholders. Keep configuration management separate and answer it with its own three elements plus an example of a configuration item from the scenario.
Answers motivation and team questions with a list of desirable leader traits or an unattributed 'I would motivate the team', without naming a model or linking it to evidence in the case; or names Tuckman's stages but does not say which stage the team is in or what the manager should therefore do differently.
Leadership feels like common sense, so candidates write plausible generalities. Trait language is also reinforced by everyday writing about leadership, making it feel like the register the marker expects.
What to do instead
Use a fixed three-part structure: name the model, cite the evidence from the case that places the team in a particular state or the leader in a particular style, then state the concrete action that follows. For example, 'the situation is storming because two workstream leads are competing for the same tester, so I will clarify roles and set ground rules rather than delegate'.
Uses 'benefit', 'output', 'outcome' and 'deliverable' interchangeably, so a project deliverable is presented as the benefit; and names a contract type (fixed price, time and materials, cost reimbursable) without saying how cost and performance risk are allocated between buyer and seller.
The words are close in ordinary usage and the distinction only bites in benefits-management questions. Contract types are memorised as a list of names because the risk-allocation rationale behind each one is not obvious unless it has been explained.
What to do instead
Define each term once in your revision notes with a worked example from a project you know, and check that benefits answers include an owner, a measure, a baseline and a point at which realisation is reviewed. For contracts, always add the consequence: who carries the risk of cost overrun, who carries the risk of scope change, and what that does to the price and to the buyer's incentive to specify well.