GAQM PPM common mistakes
GAQM PPM · Understand the traps and how to avoid them.
Treating 'project' and 'programme' as interchangeable in scenario questions, so scope and success criteria are attributed to the wrong level of management.
Candidates skim the stem, see a large initiative with several workstreams, and default to the word 'project' because that is the term they use at work; the exam's distinction between temporary deliverable-producing work and coordinated benefit delivery is not reinforced by everyday usage.
What to do instead
Before answering, underline the subject of the sentence (project, programme, portfolio) and state its defining test in one line: a project is temporary and produces a unique output; a programme is a group of related projects managed together for benefits not available from managing them individually. Then check every option against that test rather than against how your employer labels things.
Answering role questions with the strongest-sounding authority rather than the role the process assigns, e.g. giving the project manager ownership of the business case or of benefit realisation.
In many organisations the project manager de facto owns the business case because no one else will, and candidates generalise that local practice to the exam; 'project manager' also feels like the safe answer whenever accountability is asked for.
What to do instead
Build a one-page role map and memorise the accountability split: sponsor owns the business case and benefits, project manager owns delivery within constraints, team manager owns resource allocation and performance, project assurance independently monitors. When a stem asks 'who is accountable', answer from the role map, not from intuition.
Choosing the 'do nothing and escalate' or 'stop the project' option whenever a scenario shows a constraint breach, instead of the option that follows the defined exception or change-control path.
Escalation and cancellation are the most dramatic options and feel like the responsible answer; candidates have not internalised that the exam rewards applying the documented procedure, and that escalation is only correct when the procedure says so or when tolerance is exceeded.
What to do instead
Learn the escalation trigger precisely: action within stage tolerance is the project manager's; beyond stage tolerance but within project tolerance it goes to the sponsor; beyond project tolerance it goes to the directing level. Practise sorting options into 'act within delegated tolerance', 'raise an exception', and 'escalate beyond the project', and pick according to the numbers in the stem.
Confusing outputs, outcomes and benefits when a question asks what a deliverable or a benefit profile describes.
The words are used loosely in industry, and candidates map 'output' to anything the team produces, including the change in business performance, which the exam treats as an outcome or benefit.
What to do instead
Fix three definitions with examples: output is the tangible product (a trained user base, a new system); outcome is the resulting operational state (staff process claims in half the time); benefit is the measurable improvement with an owner and a measurement method. Then classify the noun in the stem before reading the options.
Selecting the first plausible option that appears in a 'which should the project manager do FIRST' question instead of sequencing the options against the process order.
Under time pressure candidates stop reading after option A or B matches a keyword, and they do not compare the remaining options, so they miss that the correct first action is earlier in the sequence than the one they chose.
What to do instead
For any 'first' or 'next' question, read all four options and write a two- or three-step order next to them before choosing. Typical sequences to memorise: identify stakeholders then analyse then plan engagement; log the issue then assess impact then escalate if tolerance is breached; verify the change request then assess impact then decide.
Ignoring the tolerance figures embedded in a scenario and answering from the general principle alone.
Stems often contain numbers (budget, days of slippage, percentage variance) and candidates treat them as background colour rather than the decision rule; the habit comes from practice questions that are purely conceptual.
What to do instead
Adopt a numeric triage step: after reading the stem, extract every figure and label it as actual, planned, or tolerance limit. Compute the variance explicitly. Only then read the options, and eliminate any option whose action falls on the wrong side of the tolerance line.
Mixing up risk responses with issue management, for example treating an event that has already happened as a risk to be added to the risk register.
Risk and issue registers look similar and both are maintained throughout delivery; candidates do not check the tense of the stem ('may occur' versus 'has occurred'), so they apply the wrong process.
What to do instead
Read the verb tense first. If the event is uncertain and future, apply the risk process (identify, assess probability and impact, plan a response from avoid, reduce, transfer, accept, and for opportunities exploit, enhance, share). If it has already happened, log it as an issue, assess impact, and escalate if tolerance is exceeded.
Assuming quality is the test team's responsibility and that quality assurance equals testing, leading to wrong answers on who sets quality criteria and when.
In many delivery environments 'QA' does colloquially mean testing, and the exam's separation of quality planning, quality assurance (process-focused) and quality control (product-focused) is not part of everyday vocabulary.
What to do instead
Learn the three-way split with one example each: quality planning defines acceptance criteria and the quality register before work starts; quality assurance independently checks that the process is being followed; quality control inspects the product against criteria. Then answer 'who defines acceptance criteria' as the customer or user with the project manager, not the tester.
Treating the project plan as a fixed document produced once at initiation, and rejecting options that describe progressive elaboration or stage-boundary re-planning.
Candidates from waterfall-heavy backgrounds equate a baseline with immutability, and they have not seen that the exam expects plans to be refined at each stage boundary while the baseline changes only through change control.
What to do instead
Hold two ideas simultaneously and test options against both: plans are progressively elaborated at stage boundaries within delegated tolerance, and the approved baseline changes only via a formal change request with impact assessment and the correct authority. Options that freeze the plan and options that casually rewrite the baseline are both wrong.
Answering stakeholder questions with 'communicate more' or 'send a status report' rather than analysing influence and interest and choosing a tailored engagement approach.
Communication is the visible part of stakeholder management, so it becomes the default answer; candidates skip the analysis step and therefore cannot distinguish an option that manages the relationship from one that merely transmits information.
What to do instead
Force an analysis step: for the named stakeholder, classify power and interest, decide the required level of engagement (inform, consult, involve, partner), and only then judge the options. Reject any option that is a broadcast communication when the stem shows a high-power, high-interest stakeholder whose support is uncertain.