PMN common mistakes
PMN · Understand the traps and how to avoid them.
Answering scenario questions with what the candidate's own organisation does rather than with the process the exam describes, e.g. choosing 'escalate to the sponsor immediately' because that is local practice, when the question tests the standard sequence of analysing impact, documenting the change request, and routing it through the change control board.
Experienced practitioners rely on habit and workplace shortcuts; the exam deliberately tests a generic, documented process, and local custom often skips steps such as formal impact assessment or written approval.
What to do instead
For every scenario, ask 'what does the process say happens next?' and pick the option that preserves documentation, analysis, and authorisation in order. Before the exam, write out the standard sequence for change control, issue escalation, and risk response, and rehearse applying it to two or three scenarios.
Confusing project, programme, and portfolio concepts, or misassigning roles in a matrix organisation - for example, treating the functional manager as the person who approves scope changes, or assuming the project manager controls resource allocation in a strong matrix.
The organisational context domain is abstract and candidates skim it, relying on job titles from their own workplace where responsibilities are drawn differently.
What to do instead
Build a one-page comparison table of project, programme, and portfolio (focus, time horizon, success measure, authority) and a second table of functional, weak, balanced, strong matrix and projectised structures showing who controls budget, resources, and the project manager's authority. Test yourself by classifying unfamiliar scenarios into these categories.
Skipping stakeholder analysis and jumping straight to communication planning, so answers ignore power/interest classification, engagement levels, or the need to re-analyse stakeholders as the project progresses.
Candidates treat stakeholder management as a one-off document produced at kick-off, and exam questions that describe a stakeholder becoming newly influential are answered with the original plan unchanged.
What to do instead
Memorise the sequence: identify, analyse (power, interest, influence, impact), plan engagement, manage, monitor. For any scenario mentioning a new or changing stakeholder, first check whether the answer re-analyses and updates the engagement approach before communicating.
Misreading the question stem's stage cue - answering a planning question with an executing tool, e.g. recommending a schedule compression technique when the project has not yet been baselined, or proposing a lessons-learned review as the fix for a scope creep problem mid-execution.
Stems are long and candidates pattern-match on keywords ('behind schedule', 'scope change') instead of locating where the project is in its life cycle and what output the process produces at that point.
What to do instead
Before reading the options, underline the life-cycle stage and the artefact the question asks about. Eliminate any option that belongs to a different process group, even if it sounds sensible, then choose among the remainder.
Confusing analogous, parametric, and bottom-up estimating, or applying contingency reserves and management reserves interchangeably when answering cost questions.
The terms sound similar and the distinctions are definitional; candidates who estimate informally at work never had to separate known-unknowns from unknown-unknowns explicitly.
What to do instead
Learn the three estimating techniques with a one-line example each and their accuracy/speed trade-off. Then fix the reserve rule: contingency reserve covers identified risks and sits within the cost baseline; management reserve covers unidentified risks and sits above it. Apply this to two numeric questions.
Treating quality assurance and quality control as synonyms, or choosing 'increase inspection' as the response to a process-caused defect rather than addressing the root cause through quality assurance.
In many workplaces quality is equated with testing, so candidates default to detection rather than prevention when a scenario describes recurring defects.
What to do instead
Anchor on the distinction: quality assurance is process-focused and preventive; quality control is product-focused and detective. For any defect scenario, ask whether the cause is the process (assurance, root cause analysis, process improvement) or the output (control, inspection, rework) before selecting.
Choosing 'avoid' or 'transfer' as the risk response whenever risk appears, or accepting a risk without checking whether the residual exposure is within tolerance and who owns it.
Candidates memorise the response list but not the selection logic, and they overlook that mitigation reduces probability or impact while acceptance must be documented and owned.
What to do instead
For each negative-risk scenario, state the probability, impact, and whether the project can influence the cause. Avoid removes the cause, mitigate reduces probability or impact, transfer shifts financial consequence (not ownership), accept is active only when documented with a reserve and an owner. Practise matching five short scenarios to responses with a one-sentence justification each.
Ignoring earned value interpretation - reading a negative cost variance as 'under budget', or failing to distinguish schedule variance from schedule performance index when judging whether a project is behind.
The sign conventions and index thresholds are easy to invert under time pressure, and candidates who rarely use earned value calculate mechanically without checking the meaning.
What to do instead
Write the formulas and their interpretations on one line each: CV = EV − AC (negative = over budget); SV = EV − PV (negative = behind schedule); CPI and SPI below 1.0 are unfavourable. Do ten quick interpretation drills where you state the verdict in words before computing.
Responding to a variance by immediately escalating or crashing the schedule, rather than first verifying the data, analysing the root cause, and selecting a corrective action proportionate to the threshold breach.
Escalation feels decisive and is often rewarded in workplaces, but exam scenarios test the control cycle: measure, compare against baseline, analyse, act, and only escalate when authority or tolerance is exceeded.
What to do instead
Memorise the control loop and apply it in order to every monitoring scenario. Eliminate options that act before analysis or that bypass the change control process when the corrective action alters the baseline.
Treating closure as an administrative afterthought - omitting benefits realisation, failing to obtain formal acceptance, or assuming lessons learned are only collected at the very end rather than throughout the project.
Closure is rushed in real projects, so candidates under-weight questions about transition, benefits ownership, and the distinction between product acceptance and project closure.
What to do instead
Learn the closure checklist: formal acceptance of deliverables, transition to operations, release of resources, financial closure, archive of records, lessons learned captured continuously and consolidated at closure, and a benefits realisation plan with an assigned owner after the project ends. For benefits questions, check whether the answer names an owner and a measurement method.