PMQ — APM Project Management Qualification Cheat Sheet

Last revised: September 17, 2026

Compact PMQ Cheat sheet for Association for Project Management candidates covering lifecycle, governance, planning, risk, change, quality, teams, and exam response decisions.

This Cheat Sheet is independent exam-prep support for candidates preparing for the Association for Project Management APM Project Management Qualification (PMQ), exam code PMQ. Use it to revise high-yield distinctions, management decisions, artefacts, and calculation logic likely to matter in written project-management questions.

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

Scope and study context

The main PMQ skill is not just remembering terminology. You need to show that you understand why a project management technique is used, when it is appropriate, who is involved, and what can go wrong if it is applied poorly.

PMQ answer discipline

Written-answer pattern

For most PMQ-style responses, avoid one-line definitions. Build concise applied answers.

If asked to…	Do this	Weak answer trap
Define	Give a precise meaning, then the project-management purpose	Listing examples only
Describe	State what it is and key features or steps	Explaining benefits but not features
Explain	Give reason and consequence: “because… therefore…”	Defining without cause/effect
Compare	Use explicit similarities/differences	Discussing only one side
Recommend / justify	State option, reason, condition, and risk	Giving an opinion without criteria
Calculate	Show method, substitute values, interpret result	Giving number only
Analyse scenario	Identify issue, link to PM principle, propose next action	Generic best practice with no scenario link

Notes and examples

Compact answer structure

Use this when stuck:

Identify the concept or problem.
State the principle: governance, risk, change control, stakeholder need, baseline, benefits, etc.
Apply to the scenario: who acts, what artefact/process is used.
Explain impact: time, cost, quality, risk, benefits, stakeholder confidence.
Give the next action if the question asks what the project manager should do.

Core project-management distinctions

Term	Practical meaning	PMQ distinction
Project	Temporary endeavour to deliver outputs, outcomes, or benefits	Unique and transient; not routine operations
Programme	Coordinated group of related projects and change activities	Focuses on strategic outcomes and benefits across projects
Portfolio	Collection of projects/programmes managed to meet strategic objectives	Prioritisation and investment-level governance
Output	Deliverable produced by the project	Tangible or measurable product/service capability
Outcome	Change resulting from using outputs	Often realised after handover
Benefit	Measurable improvement valued by stakeholders	Needs ownership, baseline, target, and realisation tracking
Objective	Specific target the project is set to achieve	Should align with business case and success criteria
Success criteria	Measures used to judge success	Can include time, cost, quality, benefits, stakeholder satisfaction
Constraint	Limitation within which the project must operate	Examples: budget cap, deadline, regulation, resource availability
Assumption	Something treated as true for planning	Must be validated; may become a risk
Dependency	Relationship between activities, deliverables, or external factors	Drives sequencing and risk exposure
Issue	Current problem requiring action	Different from risk, which is uncertain
Risk	Uncertain event or condition affecting objectives	Can be threat or opportunity

Lifecycle and governance reference

Lifecycle decision table

Lifecycle	Choose when	Strengths	Watch for
Linear / predictive	Requirements are stable, solution is understood, governance needs staged control	Strong baselines, clear approvals, easier supplier contracting	Weakness under high uncertainty or fast-changing requirements
Iterative	Solution needs repeated refinement	Learning through cycles; feedback improves quality	Scope creep if iteration goals are not controlled
Incremental	Useful parts can be delivered in releases	Early value; staged acceptance	Integration and dependency management
Agile / adaptive	Requirements are uncertain and user feedback is frequent	Flexibility, customer collaboration, prioritised backlog	Needs empowered product ownership and disciplined governance
Hybrid	Some work is predictable, some needs adaptation	Balances control and flexibility	Confusion if governance, roles, and baselines are not clear

Notes and examples

Generic project lifecycle control points

Stage	Management focus	Typical artefacts / decisions
Concept	Is there a justified need?	Strategic fit, initial business case, options, feasibility
Definition	What exactly will be delivered and how?	Project management plan, scope, schedule, budget, risk plan, governance, baseline approval
Deployment / delivery	Build, manage, control, report, and assure work	Work packages, progress reports, issue logs, change requests, quality records
Transition / handover	Move outputs into operational use	Acceptance, training, handover, support model, benefits ownership
Closure	Confirm completion and capture learning	Closure report, lessons learned, final accounts, release resources

Governance bodies and roles

Role / body	Main purpose	PMQ trap
Sponsor	Owns business case, secures funding, champions project, makes key decisions	Sponsor is not the day-to-day scheduler
Project manager	Plans, coordinates, monitors, controls, reports, manages delivery within delegated authority	PM escalates outside tolerance; does not unilaterally change approved baselines
Project board / steering group	Provides direction, decisions, and governance oversight	Not a substitute for the project manager’s daily control
User / customer representative	Defines needs and accepts outputs	Acceptance must be based on agreed criteria
Product owner, where used	Prioritises value and backlog in agile/adaptive delivery	Not the same as sponsor unless explicitly combined
Team members	Deliver work packages and provide estimates/progress updates	Need clear responsibilities and interfaces
PMO	Provides standards, support, assurance, reporting, methods, sometimes resource coordination	PMO can be supportive, controlling, or directive
Assurance role	Checks project is being managed properly and outputs are fit for purpose	Assurance is not the same as quality control testing
Change authority	Reviews and approves/rejects change requests within delegated limits	Change control protects baselines; it does not prevent all change

Project context, lifecycle, and governance

Topic	Fast review	What strong answers mention
Project	A temporary endeavour created to deliver defined outputs, outcomes, or change	Time-bound nature, uniqueness, uncertainty, objectives, constraints
Business-as-usual	Ongoing operational work	Repeatability, stable processes, operational performance
Programme	Coordinated related projects and change activities to deliver strategic outcomes	Interdependencies, benefits, transition, business change
Portfolio	Collection of projects and programmes managed to meet strategic priorities	Prioritisation, investment decisions, capacity, alignment
Project environment	Internal and external factors affecting delivery	Organisation culture, regulation, market, technology, politics, users
Success criteria	Measures used to judge project success	Time, cost, quality, scope, benefits, stakeholder satisfaction, strategic fit
Success factors	Conditions that help success happen	Sponsorship, clear objectives, capable team, governance, communication
Lifecycle	Phases from concept to close and transition	Decision gates, review points, deliverables, progressive definition
Governance	Framework for direction, control, accountability, and decision-making	Sponsor, board or steering body, assurance, escalation, tolerances
Assurance	Independent or semi-independent confidence that work is controlled and fit for purpose	Reviews, audits, health checks, compliance, recommendations
Project management plan	Integrated plan describing how the project will be managed	Scope, schedule, cost, quality, risk, communication, procurement, resources
Business case	Justification for undertaking or continuing the project	Options, costs, benefits, risks, assumptions, value, continued viability

Lifecycle traps

Linear does not mean unmanaged change. Even predictive projects need change control and review.
Iterative does not mean no governance. Adaptive approaches still need objectives, prioritisation, control, and assurance.
A gate is not just a meeting. It is a decision point based on evidence: continue, stop, defer, re-plan, or escalate.
Closure is not just delivery. It includes acceptance, handover, records, lessons, contract closure where relevant, and transition to operation.

Business case and benefits

Business case essentials

Element	Why it matters
Strategic alignment	Shows why the project should exist
Options analysis	Demonstrates alternatives were considered
Costs	Investment, delivery, lifecycle, and operating implications
Benefits	Quantified and non-quantified value expected
Risks	Uncertainty that could affect viability
Timescales	When outputs, outcomes, and benefits are expected
Investment appraisal	Supports value-for-money decision making
Ownership	Confirms who is accountable for realising benefits
Review points	Confirms the business case remains valid through the lifecycle

Notes and examples

Benefits management flow

    flowchart LR
	A[Identify benefits] --> B[Define measures and baseline]
	B --> C[Assign benefit owner]
	C --> D[Plan realisation activities]
	D --> E[Track during delivery]
	E --> F[Handover to operations]
	F --> G[Review realised benefits]

High-yield distinctions

Pair	Difference
Output vs outcome	Output is delivered by the project; outcome is the changed state from using it
Outcome vs benefit	Outcome is the change; benefit is the measurable improvement valued by stakeholders
Benefit owner vs project manager	Benefit owner is accountable for realisation; PM enables delivery and handover
Business case vs project management plan	Business case explains why; project management plan explains how
Success criteria vs acceptance criteria	Success criteria judge project success; acceptance criteria judge deliverable acceptability

Business case and benefits

The business case is a control document as well as a justification document. PMQ questions often test whether you understand that the project should remain viable throughout delivery, not just at approval.

Concept	Purpose	Watch for
Strategic alignment	Shows why the project matters to the organisation	A technically successful project can still fail strategically
Options analysis	Compares possible ways to meet the need	“Do nothing” or minimum-change options may be valid comparisons
Benefits	Positive measurable value expected from outputs or outcomes	Benefits need ownership, measurement, and adoption
Disbenefits	Negative consequences of the project or change	Ignoring them weakens decision-making
Assumptions	Conditions treated as true for planning	They should be tested and monitored
Constraints	Limits on choices, such as time, budget, regulation, or resources	Constraints create trade-offs
Benefits realisation	Process for achieving and measuring benefits	Often continues after the project team has disbanded
Review	Confirms continuing justification	Should occur when major assumptions, costs, risks, or benefits change

Benefits decision rule

If a question asks whether a project should continue, do not answer using delivery progress alone. Consider:

current and forecast cost;
remaining benefits and whether they are still achievable;
changed risks or assumptions;
stakeholder and operational readiness;
strategic relevance;
opportunity cost of using resources elsewhere.

Scope, requirements, and configuration

Scope artefacts

Artefact	Use	Exam clue
Requirements documentation	Captures stakeholder needs and constraints	“Users disagree on what is needed”
Product breakdown structure	Decomposes the product/deliverables	“What must be produced?”
Work breakdown structure	Decomposes work required to deliver scope	“What work packages are needed?”
Scope statement	Defines included/excluded work and boundaries	“Prevent misunderstanding of what is in scope”
Acceptance criteria	Defines conditions for acceptance	“How will customer know it is acceptable?”
Configuration management records	Identify and control versions of products	“Multiple versions, uncontrolled changes, traceability problem”
Requirements traceability	Links requirements to outputs and tests	“Prove each requirement has been addressed”

Requirements quality checklist

Good requirements are:

Clear and unambiguous.
Testable or verifiable.
Feasible within constraints.
Traceable to business need.
Prioritised where necessary.
Agreed by authorised stakeholders.
Controlled once baselined.

Change control

Change-control decision path

    flowchart TD
	A[Change request raised] --> B[Log and clarify request]
	B --> C[Assess impact on scope, time, cost, quality, risk, benefits]
	C --> D{Within PM authority?}
	D -- Yes --> E[Approve/reject and update plans]
	D -- No --> F[Escalate to change authority / sponsor]
	F --> G[Decision recorded]
	E --> H[Communicate and implement]
	G --> H
	H --> I[Update baselines, configuration, and reports]

Notes and examples

Change-control table

Situation	Best next action	Trap
Stakeholder asks for extra feature informally	Raise/log change request and assess impact	Agreeing because it seems small
Change affects approved cost/time baseline	Escalate to authorised decision-maker	PM approving beyond authority
Urgent safety/regulatory issue	Take appropriate immediate protective action, then formalise decision and records	Ignoring governance or delaying necessary action
Supplier proposes technical substitution	Assess quality, risk, contractual, cost, and configuration impact	Accepting based only on lower cost
Multiple uncontrolled product versions exist	Apply configuration management and version control	Treating it as a communication issue only

Scope, requirements, and change control

Scope management connects the customer need to what the project will and will not deliver. PMQ questions frequently test how well you control scope without blocking legitimate change.

Topic	What to know	Exam trap
Requirements	Statements of need or capability expected by stakeholders	Accepting vague requirements without validation
Scope definition	Boundaries of what is included and excluded	Failing to document exclusions
Product breakdown structure	Breaks the product or deliverable into components	Confusing product components with project activities
Work breakdown structure	Breaks project work into manageable work packages	Turning it into a schedule too early
Work package	Defined chunk of work with scope, owner, estimates, and controls	Assigning work without acceptance criteria
Acceptance criteria	Conditions outputs must meet to be accepted	Treating acceptance as subjective approval
Configuration management	Identifies and controls versions of project products	Losing control of document or product versions
Change control	Evaluates proposed changes to baselines	Approving changes before impact analysis
Scope creep	Uncontrolled growth in scope	Calling it “customer service” instead of controlling it

Change control quick path

For a proposed change:

Record the request.
Clarify what is being requested and why.
Assess impact on scope, schedule, cost, quality, risk, resources, benefits, and contracts.
Identify options, including reject, defer, approve, or approve with conditions.
Submit to the correct authority.
Update baselines, plans, records, and communications if approved.
Monitor implementation.

The most common wrong answer is to implement the change because it appears small. Small changes can accumulate into major cost, schedule, quality, or benefits impacts.

Planning and scheduling

Planning hierarchy

Level	Purpose	Typical content
Project management plan	Integrated “how the project will be managed”	Scope, schedule, cost, risk, quality, communications, resources, governance
Stage / phase plan	Detailed planning for a controlled section	Activities, milestones, resources, controls
Work package	Delegated unit of work	Deliverables, acceptance criteria, estimates, dependencies, reporting
Schedule	Time-based model of activities	Durations, dependencies, milestones, critical path
Baseline	Approved reference point	Used to measure variance and control change

Notes and examples

Estimating methods

Method	Best used when	Strength	Weakness
Analogous	Similar previous work exists	Fast	Less accurate if context differs
Parametric	Reliable productivity/cost rates exist	Scalable and evidence-based	Depends on valid parameters
Bottom-up	Work is well defined	More detailed and credible	Time-consuming
Expert judgement	Specialist knowledge is needed	Practical where data is limited	Bias risk
Three-point estimating	Uncertainty is significant	Shows range and risk	Can create false precision
Delphi	Need to reduce expert bias	Anonymous convergence	Takes coordination

Network scheduling essentials

Concept	Meaning	Exam use
Activity	Task consuming time/resources	Build network from activities
Dependency	Logical relationship between activities	Determines sequence
Milestone	Zero-duration significant point	Used for control and reporting
Critical path	Longest path through network	Determines shortest project duration
Total float	Time an activity can slip without delaying project finish	Zero float often indicates critical activity
Free float	Time an activity can slip without delaying successor	Useful for local scheduling flexibility
Lead	Allows successor to start before predecessor fully finishes	Can increase risk if overused
Lag	Delay between activities	Should be explicit, not hidden padding

Key scheduling formulas

\[ \text{Expected duration} = \frac{O + 4M + P}{6} \]\[ \text{Total float} = LS - ES = LF - EF \]\[ \text{Free float} = \text{earliest start of successor} - \text{earliest finish of activity} \]

Where used: O = optimistic, M = most likely, P = pessimistic, ES/EF = early start/finish, LS/LF = late start/finish.

Planning and scheduling

Planning is iterative. Early plans may be high level; later plans should become more detailed as information improves.

Tool or concept	Use	Candidate mistake
Milestone	Significant point or event	Treating milestones as activities with duration
Network diagram	Shows logical dependencies between activities	Ignoring mandatory versus discretionary dependencies
Critical path	Longest path through the network, determining minimum project duration	Thinking it is the path with the most activities
Float	Time an activity can slip without delaying a defined point	Assuming all float is available to any one activity
Gantt chart	Time-phased visual schedule	Using it without understanding dependencies
Rolling wave planning	Near-term work planned in more detail than later work	Treating early uncertainty as poor planning
Resource levelling	Adjusts schedule to match resource availability, often affecting end date	Forgetting it can extend duration
Resource smoothing	Adjusts activities within float to improve resource use without changing end date	Using it when no float exists
Baseline	Approved reference for measuring performance	Confusing baseline with current forecast
Forecast	Current prediction of final outcome	Reporting the baseline as if nothing has changed

Critical path and float

Total float can be reviewed as:

\[ \text{Total float} = \text{Latest finish} - \text{Earliest finish} = \text{Latest start} - \text{Earliest start} \]

Key interpretation points:

An activity on the critical path normally has zero total float.
Delay on a critical activity usually delays the project unless action is taken.
Reducing duration on a non-critical activity may not shorten the project.
Float can change when progress, logic, or estimates change.
Near-critical paths matter because small delays can make them critical.

Estimating review

Estimating approach	Best use	Limitation
Analogous	Early estimate using similar past work	Less accurate if differences are not understood
Parametric	Uses rates or statistical relationships	Depends on reliable data and valid parameters
Bottom-up	Builds estimate from detailed work packages	Time-consuming and depends on scope clarity
Three-point	Uses optimistic, most likely, and pessimistic values	Can create false precision if inputs are guesses
Expert judgment	Uses specialist experience	Can be biased without challenge or evidence

Three-point expected duration is often reviewed as:

\[ \text{Expected duration} = \frac{\text{optimistic} + 4(\text{most likely}) + \text{pessimistic}}{6} \]

Do not just calculate. Explain what uncertainty the estimate captures and how it affects planning, contingency, or risk management.

Cost management and earned value

Cost terms

Term	Meaning
Direct cost	Directly attributable to project work
Indirect cost	Shared overhead not directly assigned to one activity
Fixed cost	Does not vary with activity volume over relevant range
Variable cost	Changes with activity volume
Contingency	Budget allowance for known-unknown risk responses
Management reserve	Additional allowance usually controlled outside PM’s routine authority
Sunk cost	Already incurred cost; should not justify continuing a poor investment
Whole-life cost	Cost across acquisition, operation, maintenance, disposal

Notes and examples

Earned value formulas

\[ SV = EV - PV \]\[ CV = EV - AC \]\[ SPI = \frac{EV}{PV} \]\[ CPI = \frac{EV}{AC} \]\[ EAC = \frac{BAC}{CPI} \]

Interpretation:

Measure	Positive / above 1	Negative / below 1
Schedule variance, SV	Ahead of planned value	Behind planned value
Cost variance, CV	Under budget for work performed	Over budget for work performed
Schedule performance index, SPI	Progressing faster than planned	Progressing slower than planned
Cost performance index, CPI	Cost efficient	Cost inefficient

PMQ trap: earned value compares value of work performed against planned and actual cost. It is not simply “money spent versus budget”.

Cost control and earned value basics

Cost management is not only accounting. It links estimates, budgets, funding, commitments, actual spend, forecasts, and value delivered.

Concept	Review point
Estimate	Prediction of cost based on information and assumptions
Budget	Approved funding or cost baseline
Actual cost	Cost incurred for completed or in-progress work
Committed cost	Cost agreed or contractually committed but not necessarily paid
Forecast	Expected final cost based on current information
Contingency	Allowance for identified uncertainty or risk, depending on the organisation’s approach
Cost baseline	Approved reference for measuring cost performance

If earned value is in scope for your preparation, focus on both calculation and interpretation:

\[ \begin{aligned} \text{CV} &= \text{EV} - \text{AC} \\ \text{SV} &= \text{EV} - \text{PV} \\ \text{CPI} &= \frac{\text{EV}}{\text{AC}} \\ \text{SPI} &= \frac{\text{EV}}{\text{PV}} \end{aligned} \]

Metric	Plain meaning	Interpretation trap
CV	Earned value minus actual cost	Positive is favourable; negative is unfavourable
SV	Earned value minus planned value	It measures value progress, not necessarily calendar days
CPI	Cost efficiency ratio	Below 1 suggests cost inefficiency
SPI	Schedule efficiency ratio	Below 1 suggests progress is behind planned value
EAC	Estimate at completion	Formula choice depends on assumptions about future performance

Risk and issue management

Risk process reference

Step	Purpose	Typical artefacts
Identify	Find threats and opportunities	Risk register, workshops, checklists
Assess	Understand probability, impact, proximity, severity	Probability-impact matrix, scoring, EMV
Plan responses	Decide actions and owners	Response plans, contingency, fallback
Implement	Carry out agreed responses	Action tracking
Monitor	Review status, triggers, residual risk	Risk reports, updated register
Escalate	Move risks outside authority/tolerance to governance level	Escalation reports, sponsor decisions

Notes and examples

Risk response strategies

For threats	Meaning
Avoid	Change plan to remove threat
Reduce / mitigate	Lower probability or impact
Transfer	Shift financial/contractual impact to another party, often at a cost
Accept	Take no proactive action beyond monitoring or contingency

For opportunities	Meaning
Exploit	Ensure opportunity happens
Enhance	Increase probability or benefit
Share	Work with another party to capture opportunity
Accept	Take advantage if it occurs, without proactive investment

Risk formulas

\[ EMV = \text{probability} \times \text{impact} \]\[ \text{Risk exposure} = \text{probability} \times \text{impact} \]

Use expected monetary value for comparing options under uncertainty, not as a guarantee of actual outcome.

Risk vs issue vs change

Situation	Classification	Management response
“Supplier may miss the delivery date”	Risk	Assess probability/impact and plan response
“Supplier has missed the delivery date”	Issue	Log, assign action, assess impact
“Customer wants a different delivery date”	Change	Raise change request and assess baseline impact
“Assumption about resource availability is doubtful”	Risk	Validate assumption and add risk if uncertain
“Approved design is no longer correct”	Issue and likely change	Control through issue management and change control

Risk, issue, and opportunity management

Risk management is proactive. Issue management is reactive. Both need ownership, escalation, and tracking.

Concept	Definition	PMQ trap
Threat	Uncertain event that would have a negative effect	Treating all risks as negative only
Opportunity	Uncertain event that would have a positive effect	Ignoring positive risk responses
Issue	Current problem or event requiring action	Calling an issue a risk after it has occurred
Cause	Reason the risk may happen	Writing vague risks without a cause
Event	The uncertain occurrence	Describing a general concern instead of an event
Effect	Impact on objectives if it occurs	Not linking to time, cost, quality, benefits, or safety
Probability	Likelihood of occurrence	Overstating precision
Impact	Consequence if it occurs	Ignoring multiple impact types
Risk owner	Person accountable for managing the risk	Assigning ownership to a group with no accountable person
Risk response	Chosen action to change probability or impact	Listing responses but not implementing them

Threat response review

Response	Meaning	Example logic
Avoid	Change the plan so the threat cannot occur or no longer affects the project	Remove a risky requirement or choose a safer method
Reduce	Lower probability or impact	Add testing, training, prototyping, or extra review
Transfer	Shift some financial or delivery impact to another party	Insurance or contractual allocation
Accept	Take no immediate action beyond monitoring or contingency	Suitable when cost of response exceeds expected impact

Opportunity response review

Response	Meaning	Example logic
Exploit	Make the opportunity happen	Allocate best resources to secure a beneficial outcome
Enhance	Increase probability or impact	Improve conditions that make the opportunity more likely
Share	Work with another party to capture value	Partnership or joint initiative
Accept	Take advantage if it occurs, without active pursuit	Monitor when active pursuit is not justified

Risk wording template

A strong risk statement is specific:

Because of cause, there is a risk that event may occur, leading to effect on project objectives.

Weak risk statement: “Supplier risk.”

Better risk statement: “Because the supplier is using a new component, there is a risk that test failures may occur, leading to rework, delayed acceptance, and increased cost.”

Quality management

Quality distinctions

Term	Meaning	Trap
Quality planning	Defines standards, criteria, methods, and responsibilities	Not the same as inspection
Quality assurance	Confirms processes are suitable and being followed	Focuses on process confidence
Quality control	Checks outputs against criteria	Detects defects in deliverables
Grade	Category or level of features	Low grade can still be high quality if it meets requirements
Acceptance	Customer/user confirmation output meets agreed criteria	Not just internal testing
Verification	Built correctly against specification	“Did we build it right?”
Validation	Meets user need/intended use	“Did we build the right thing?”

Quality cost categories

Category	Examples
Prevention	Training, standards, quality planning
Appraisal	Reviews, inspections, testing
Internal failure	Rework before delivery
External failure	Defects found by customer, warranty, reputation damage

Notes and examples

Quality management

Quality is about fitness for purpose and conformance to requirements. It must be planned, built in, checked, and improved.

Quality concept	Purpose	Common confusion
Quality planning	Defines standards, criteria, methods, and responsibilities	Assuming quality can be handled later
Quality assurance	Provides confidence that processes are appropriate and being followed	Confusing assurance with inspection
Quality control	Checks outputs against defined criteria	Inspecting without clear acceptance standards
Acceptance	Formal confirmation that deliverables meet agreed criteria	Treating acceptance as informal satisfaction
Cost of quality	Balances prevention, appraisal, and failure costs	Cutting prevention and creating expensive rework
Continuous improvement	Learns and improves processes	Capturing lessons but not applying them

Quality traps

Quality does not always mean “highest specification”; it means meeting agreed needs and standards.
Late inspection may detect defects but does not prevent them.
Poor requirements create quality problems even if the team works hard.
Quality responsibilities should be clear across the project team, suppliers, reviewers, and customer representatives.

Procurement and contract selection

Contract type	Supplier risk	Buyer risk	Choose when	Watch for
Fixed price	Higher	Lower if scope is stable	Requirements are clear and change is limited	Supplier may price risk or resist change
Cost reimbursable	Lower	Higher	Scope uncertain or innovation needed	Requires strong cost control
Time and materials	Medium	Medium to high	Flexible support or unclear duration	Can drift without caps and monitoring
Target cost / incentive	Shared	Shared	Need collaboration and cost-performance incentives	Incentive structure must align behaviour
Framework agreement	Depends on call-off	Depends on terms	Repeated procurement from pre-qualified suppliers	Still need clear work orders

Procurement exam trap: the “best” contract depends on certainty, risk allocation, buyer capability, urgency, and need for collaboration. Do not default to fixed price for uncertain work.

Stakeholder and communication management

Stakeholder analysis

Dimension	Meaning	Management implication
Power	Ability to influence project	High power needs active management
Interest	Level of concern or involvement	High interest needs engagement and information
Attitude	Supportive, neutral, resistant	Tailor engagement approach
Impact	How much the project affects them	High impact may require change support
Influence network	Formal and informal relationships	Identify hidden blockers/champions

Notes and examples

Engagement strategies

Stakeholder position	Aim	Example action
High power, high interest	Manage closely	Regular decision briefings, involve in trade-offs
High power, low interest	Keep satisfied	Concise exception reporting
Low power, high interest	Keep informed	Updates, workshops, FAQs
Low power, low interest	Monitor	Periodic communications
Resistant but important	Understand cause and address concerns	One-to-one engagement, benefits explanation, change impact support

Communication planning checklist

A good communication plan defines:

Audience and information need.
Purpose of communication.
Format and channel.
Frequency and timing.
Sender and owner.
Feedback mechanism.
Confidentiality or sensitivity.
Escalation route.
How effectiveness will be reviewed.

Common trap: communication is not just sending reports. It requires feedback, understanding, and stakeholder-specific content.

Stakeholders and communication

Stakeholder work is high-yield because it appears in almost every project scenario: unclear requirements, resistance, conflict, delay, benefit failure, and governance issues.

Activity	Review point	Trap
Identify stakeholders	Find people or groups affected by or able to affect the project	Missing indirect stakeholders
Analyse stakeholders	Assess influence, interest, attitude, needs, and expectations	Using a matrix once and never updating it
Plan engagement	Decide how to involve, inform, consult, or manage stakeholders	Treating all stakeholders the same
Communicate	Provide the right message through the right channel at the right time	Sending information without checking understanding
Manage expectations	Align what stakeholders believe with what will be delivered	Avoiding difficult conversations
Monitor engagement	Track changes in support, resistance, and information needs	Assuming early support will continue

Communication decision rule

Choose communication method by considering:

sensitivity of message;
urgency;
complexity;
need for feedback;
stakeholder influence and interest;
record-keeping requirements;
geographic or cultural constraints;
risk of misunderstanding.

A dashboard may be suitable for routine status reporting. A major scope conflict may require direct discussion, negotiation, and formal decision records.

Leadership, teams, and conflict

Project manager leadership focus

Area	Practical PM behaviour
Direction	Clarify objectives, priorities, constraints
Motivation	Understand individual/team drivers and remove blockers
Delegation	Assign work with authority, expectations, and reporting
Coaching	Build capability, especially in uncertain work
Conflict management	Address causes early and constructively
Decision-making	Use evidence, authority limits, and governance
Ethics and professionalism	Act transparently, fairly, and responsibly

Notes and examples

Team development reference

Stage	Symptoms	PM focus
Forming	Polite, uncertain, dependent on leader	Clarify purpose, roles, ways of working
Storming	Conflict, challenge, tension	Facilitate, resolve issues, reinforce objectives
Norming	Working practices emerge	Encourage collaboration and accountability
Performing	Productive, self-managing	Empower, remove blockers, sustain performance
Adjourning	Work ends, team disbands	Recognise contribution, capture lessons, release resources

Conflict-handling options

Approach	Use when	Risk
Collaborate	Important issue, need durable solution	Takes time
Compromise	Need workable middle ground	May not fully satisfy either party
Accommodate	Issue is low importance to you or relationship matters more	Can create imbalance
Force / direct	Urgent decision or safety/compliance issue	Can damage trust
Avoid	Issue is trivial or cooling-off is needed	Problem may grow if substantive

Leadership, teamwork, conflict, and negotiation

PMQ preparation should connect people concepts to project situations. Avoid writing abstract theory only.

Topic	Practical review	Candidate mistake
Leadership style	Adapt approach to urgency, team maturity, uncertainty, and risk	Claiming one style is always best
Motivation	Understand what helps people commit and perform	Assuming money is the only motivator
Team development	Teams may need time to form, clarify norms, and perform	Expecting immediate high performance
Delegation	Assign authority and responsibility appropriately	Delegating tasks without decision rights or support
Conflict	Can be constructive if managed	Treating all conflict as negative
Negotiation	Seeks agreement between parties with different interests	Entering without objectives, options, or limits
Collaboration	Builds shared ownership and problem-solving	Calling every meeting collaboration

Conflict management traps

Avoiding conflict may preserve short-term harmony but allow risks to grow.
Forcing a decision may be necessary in a crisis but can damage commitment if overused.
Compromise may be practical but can produce a weak solution if core needs are ignored.
Collaboration is powerful but takes time and requires trust, information, and willingness.

Information, reporting, and control

Control cycle

    flowchart LR
	A[Set baseline and tolerances] --> B[Measure actual progress]
	B --> C[Compare with plan]
	C --> D[Forecast outcome]
	D --> E{Within tolerance?}
	E -- Yes --> F[Take corrective action if needed]
	E -- No --> G[Escalate for decision]
	F --> B
	G --> H[Re-plan or approve change]
	H --> B

Notes and examples

Reports and records

Artefact	Purpose	Audience
Highlight / status report	Summarise progress, forecast, risks, issues, decisions needed	Sponsor, board, PMO
Exception report	Escalate forecast breach of tolerance or major issue	Governance body
Risk register	Record risks, owners, assessments, responses	PM, sponsor, risk owners
Issue log	Track current problems and actions	PM and team
Decision log	Preserve decision rationale and accountability	PM, governance, audit
Lessons log	Capture learning during the project	Current and future teams
Change log	Track requested, approved, rejected, implemented changes	PM, change authority
Configuration records	Track versions and status of products	Team, quality, assurance

Reporting, control, and assurance

Project control compares actual performance with the plan, identifies variance, forecasts outcomes, and triggers corrective action.

Control item	Good PMQ answer includes
Progress reporting	Actual progress, forecast, variance, issues, risks, decisions needed
Exception reporting	Breach or forecast breach of agreed limits requiring escalation
Trend analysis	Direction of performance, not just current status
Corrective action	Action to bring performance back toward plan
Preventive action	Action to reduce likelihood of future problems
Replanning	Controlled update to plans when assumptions or constraints change
Assurance review	Confidence that management processes and outputs are adequate
Lessons learned	Captured during and after the project, then applied

Control traps

Reporting a delay is not the same as controlling it.
A green status without evidence is not useful.
Corrective action should have an owner and due date.
Replanning without approval can hide variance.
Escalation is not failure; it is part of governance when authority limits are reached.

Agile and adaptive concepts in PMQ context

Concept	Meaning	PMQ distinction
Backlog	Prioritised list of work or requirements	Dynamic; needs active ownership
Timebox	Fixed period for focused delivery	Scope may flex to protect time
Increment	Usable addition delivered at end of cycle	Supports early feedback
Iteration review	Demonstrates completed work and gathers feedback	Not just a status meeting
Retrospective	Improves team process	Focuses on how the team works
Product owner	Maximises product value and prioritises need	Different from project sponsor governance role
Minimum viable product	Smallest useful release to validate value	Not low-quality delivery

Notes and examples

Predictive vs agile decision points

Question	Predictive leaning	Agile/adaptive leaning
Are requirements stable?	Yes	No
Is solution well understood?	Yes	No
Is customer feedback needed frequently?	Less frequently	Very frequently
Is regulatory/stage approval dominant?	Stronger fit	Still possible, but governance must be tailored
Can outputs be released incrementally?	Not necessary	Preferable
Is contract scope fixed?	Easier	Needs flexible commercial model

Integrated “what should the project manager do next?” table

Scenario clue	Best next step	Why
Forecast exceeds agreed tolerance	Escalate with options and impact	PM authority is limited by governance
Stakeholders disagree on priorities	Facilitate prioritisation using objectives/business case	Prevents unmanaged scope and conflict
Benefits no longer justify cost	Review and escalate business case viability	Project should remain justified
Team member reports hidden delay	Update schedule forecast, assess critical path, communicate impact	Control requires accurate data
Risk has occurred	Treat as issue, implement contingency, update risk/issue records	Risk uncertainty has become current problem
Customer rejects deliverable	Compare against acceptance criteria; manage defect or change	Distinguish non-conformance from new requirement
Sponsor asks to skip quality checks	Explain risk and governance impact; seek formal decision if necessary	Quality controls protect acceptance and benefits
Supplier underperforms	Check contract, document issue, engage supplier, escalate if needed	Evidence and commercial route matter
User adoption is weak	Review change management, training, communications, benefits plan	Outputs alone do not guarantee outcomes
Multiple teams use different plans	Integrate schedules, dependencies, assumptions, and reporting	Project control needs a single coherent view

High-yield PMQ distinctions

Do not confuse…	Correct distinction
Risk and issue	Risk is uncertain; issue is happening now
Contingency and management reserve	Contingency is for identified risks; management reserve is usually broader and more controlled
Assurance and control	Assurance checks process confidence; control checks outputs/performance
Product breakdown and work breakdown	Product breakdown shows deliverables; work breakdown shows work
Milestone and activity	Milestone has no duration; activity consumes time/resources
Change request and issue	Change request proposes baseline alteration; issue is a current problem
Benefit and deliverable	Benefit is value realised; deliverable is output produced
Stakeholder communication and engagement	Communication sends/receives information; engagement manages relationship and commitment
Progress and performance	Progress is work completed; performance compares progress/cost/time against plan
Leadership and management	Leadership influences people; management plans, organises, and controls work

Final revision checklist

Before the exam, make sure you can quickly:

Explain why a project needs a business case and when it should be reviewed.
Distinguish project, programme, and portfolio.
Link outputs, outcomes, benefits, and success criteria.
Select lifecycle approach based on uncertainty, requirements, and governance need.
Identify sponsor, project manager, PMO, user, supplier, and assurance responsibilities.
Build or interpret simple network logic, float, and critical path.
Use earned value terms and interpret CPI/SPI direction.
Explain risk responses for threats and opportunities.
Distinguish risk, issue, assumption, dependency, and change.
Describe change control from request to decision to baseline update.
Explain quality planning, assurance, control, verification, and validation.
Choose procurement route based on uncertainty and risk allocation.
Analyse stakeholder power/interest and choose engagement actions.
Explain team development, motivation, leadership, and conflict response.
Write answers that include reason, consequence, and project context.

Notes and examples

High-yield PMQ checklist

Area	You should be able to do quickly	Common trap
Project context	Distinguish projects from business-as-usual, programmes, and portfolios	Describing every change initiative as a standalone project
Success	Separate success criteria from success factors	Treating “on time and on budget” as the only success measure
Lifecycle	Explain phases, decision gates, reviews, and handover	Assuming one lifecycle suits all project types
Governance	Identify decision rights, escalation routes, assurance, and sponsorship	Making the project manager approve everything alone
Business case	Link objectives, costs, benefits, risks, and continued justification	Writing the business case once and never reviewing it
Benefits	Explain identification, planning, ownership, realisation, and review	Assuming benefits are automatically delivered at project closure
Stakeholders	Analyse interest, influence, expectations, and engagement needs	Producing a stakeholder list with no engagement strategy
Communication	Match message, audience, channel, timing, and feedback	Communicating more often without communicating better
Scope	Connect requirements, deliverables, WBS/PBS, acceptance, and change	Confusing product scope with project management activities
Schedule	Use dependencies, critical path, float, milestones, and baselines	Thinking the critical path is simply the shortest route
Resources	Plan capability, availability, levelling, smoothing, and team constraints	Treating resource allocation as a purely mathematical exercise
Cost	Understand estimates, budgets, forecasts, reserves, and cost control	Quoting figures without explaining assumptions
Risk and issue	Distinguish uncertain events from current problems	Managing an issue as if it were still a risk
Quality	Explain planning, assurance, control, acceptance, and continuous improvement	Treating quality as inspection at the end
Procurement	Understand make-or-buy, supplier selection, contracts, and supplier risk	Selecting the cheapest supplier without considering whole-life value
Leadership and teams	Apply leadership style, motivation, conflict management, and collaboration	Giving theory names without project application
Change control	Assess impact before approval, rejection, or deferral	Accepting “small” changes informally
Closure	Cover acceptance, handover, lessons, records, and post-project review	Closing when delivery ends but before learning is captured

Final quick checklist before practice

Before moving to full mock exams, confirm that you can:

explain the difference between project, programme, portfolio, and business-as-usual;
link project decisions to the business case;
describe lifecycle phases, gates, assurance, and closure;
distinguish sponsor, project manager, team, user, supplier, and PMO responsibilities;
build a clear risk statement with cause, event, and effect;
select suitable risk responses for threats and opportunities;
explain change control from request to implementation;
interpret critical path, float, and schedule impact;
understand estimate types and uncertainty;
interpret basic cost and earned value indicators if included in your study scope;
explain stakeholder analysis and engagement planning;
distinguish quality planning, assurance, control, and acceptance;
describe procurement decisions beyond lowest price;
connect handover and transition to benefits realisation.

Next step: choose your two weakest PMQ areas, complete focused topic drills in the PM Mastery question bank, and read the detailed explanations until you can explain both the correct answer and the most tempting wrong answer.

Decision rules that answer many PMQ questions

Start with objectives and the business case. If a decision affects scope, time, cost, benefits, risk, or viability, connect it back to the business case.
Do not bypass governance. Significant decisions should follow agreed authority, escalation, and approval routes.
Baseline first, then control. You cannot control schedule, cost, scope, or quality effectively without an agreed baseline or acceptance standard.
Analyse before acting. For risks, issues, changes, delays, or supplier problems, first understand impact, options, urgency, and ownership.
Differentiate risk, issue, and change. Risk is uncertain, issue is happening, change is a proposed alteration to an agreed baseline.
Engagement is more than communication. Stakeholders may need involvement, negotiation, consultation, resistance management, or formal approval.
Quality is designed in. Quality planning and assurance reduce the need for late rework.
Benefits often outlive the project. The project may deliver outputs, but the organisation normally realises benefits through use and change adoption.
The project manager integrates. PMQ answers often require showing how scope, schedule, cost, risk, quality, resources, and stakeholders interact.
A good answer includes limits. Techniques have assumptions, costs, and weaknesses; explaining these shows judgment.

Organisation, roles, and accountability

Role or structure	PMQ review point	Common mistake
Sponsor	Owns business justification, champions the project, supports decisions	Treating the sponsor as a passive figurehead
Project manager	Plans, integrates, coordinates, controls, reports, and leads delivery	Assuming the project manager owns all benefits alone
Project team	Produces deliverables and provides specialist expertise	Ignoring team capability and availability constraints
Users	Define needs, validate outputs, support adoption	Involving users only at final acceptance
Suppliers	Provide goods, services, or expertise under commercial arrangements	Treating supplier performance as outside project control
PMO	May provide standards, reporting, assurance, tools, or resource coordination	Assuming every PMO has the same authority
Functional organisation	Staff report through departments	Can create priority conflicts and slow decisions
Matrix organisation	Shared authority between project and functional lines	Requires clear roles, negotiation, and escalation
Projectised organisation	Teams organised around projects	Can improve focus but may create resource continuity issues

Notes and examples

Role clarity traps

Confusing accountability with activity: a person may be accountable for an outcome without doing every task.
Escalating every problem to the sponsor: the project manager should manage within agreed authority.
Leaving users out of requirements and acceptance: this increases rework and adoption risk.
Ignoring functional managers in a matrix environment: they often control specialist resources.

Procurement and supplier management

Procurement questions often test whether you consider value, risk, clarity of requirements, and governance rather than just price.

Procurement topic	What to know	Trap
Make-or-buy	Decide whether work should be internal or external	Ignoring capability, risk, time, and strategic control
Procurement strategy	Defines how goods or services will be acquired	Starting tendering before requirements are clear
Supplier selection	Evaluates capability, value, risk, quality, and commercial fit	Choosing only on lowest price
Contract type	Allocates responsibilities, incentives, and risks	Assuming the contract removes the need to manage the supplier
Tender process	Provides fair and structured supplier competition	Changing criteria informally
Supplier performance	Monitors delivery, quality, cost, and relationship	Waiting until final delivery to identify problems
Contract change	Controls changes to agreed commercial scope	Letting informal scope changes bypass contract control

Notes and examples

Procurement decision points

Ask:

Is the requirement clear enough to procure?
What risks should remain with the buyer, and what risks can realistically be transferred?
How will supplier performance be measured?
How will changes be controlled?
What dependencies does the supplier create for schedule, quality, integration, and acceptance?
What happens if the supplier fails, delays, or delivers below standard?

Handover, transition, and closure

A project can produce a technically complete output that still fails if transition is poor.

Closure or transition item	Review point
Acceptance	Confirms deliverables meet agreed criteria
Handover	Transfers outputs, documentation, support arrangements, and responsibilities
Training	Prepares users or operations to use the output
Operational readiness	Confirms people, processes, systems, and support are ready
Benefits handover	Ensures benefit owners understand measures and responsibilities
Contract closure	Confirms supplier obligations, payments, claims, and records
Final report	Summarises performance, issues, lessons, and remaining actions
Lessons learned	Captures what should be repeated or changed
Post-project review	Evaluates delivery performance and may inform future projects
Benefits review	Checks whether intended value is being realised after use

Notes and examples

Closure traps

Closure is not just “the work is finished.”
Benefits may require business adoption after the project team leaves.
Lessons are only valuable if accessible and used by future projects.
Outstanding defects, risks, or support needs should be transferred clearly, not hidden.

Calculation and interpretation traps

When calculations appear in practice, candidates often lose marks through interpretation errors rather than arithmetic.

Situation	Correct thinking
Activity has float	It may slip up to the float limit before affecting the relevant completion point
Critical path activity slips	The project completion date is at risk unless action changes the network or duration
Non-critical activity is shortened	The project may not finish earlier unless it affects the critical path
CPI is below 1	The project is earning less value per unit of cost than planned
SPI is below 1	The project has delivered less planned value than expected at that point
Forecast cost exceeds budget	Analyse cause, options, authority, business case impact, and stakeholder communication
Estimate is precise	Precision is not the same as accuracy; assumptions and confidence matter

Common PMQ candidate mistakes

Giving definitions without explaining purpose or application.
Listing documents without saying how they are used.
Treating the project manager as the sole decision-maker for strategic or commercial decisions.
Ignoring the sponsor’s role in business justification and senior stakeholder support.
Confusing risks, issues, assumptions, constraints, and changes.
Forgetting to assess impact before approving a change.
Discussing schedule delay without considering cost, quality, risk, resources, and benefits.
Treating stakeholder communication as one-way broadcasting.
Assuming quality is only final inspection.
Choosing procurement options based only on price.
Describing benefits without measures or owners.
Closing the project without handover, acceptance, lessons, or transition.
Writing generic answers that could apply to any project, instead of using the scenario or context.
Memorising theory names but failing to explain how they guide action.

Answering PMQ-style prompts efficiently

For most practice prompts, build your answer around this structure:

Define the concept briefly.
State the purpose: why it matters to project control or success.
Apply it to the situation or project phase.
Identify roles involved, such as sponsor, project manager, team, user, supplier, or governance body.
Mention evidence or documents, such as business case, project management plan, risk register, schedule, issue log, or change request.
Add a limitation or trap where relevant.

Example pattern for “explain the importance of stakeholder analysis”:

It identifies people or groups affected by or able to influence the project.
It helps the project manager understand interests, power, expectations, and likely support or resistance.
It informs communication and engagement planning.
It reduces risk of missed requirements, opposition, late change, or poor adoption.
It should be reviewed as stakeholders and attitudes change.

Mini self-check

Prompt	Your answer should mention
A major user group requests extra functionality after scope baseline approval. What should happen first?	Record the change, clarify it, assess impact, and route through change control
A supplier delivery has failed quality testing. Is this a risk or an issue?	It is an issue now; related future consequences may create risks
The business case benefits are no longer achievable. What should be reviewed?	Continuing justification, options, governance decision, costs, risks, and strategic fit
A non-critical task finishes early. Does the project finish earlier?	Not necessarily; only changes affecting the critical path reduce overall duration
Stakeholders say they were “kept informed” but still resist adoption. What was missing?	Engagement, involvement, expectation management, and readiness planning
A project is under budget but delivering outputs that users do not accept. Is it successful?	Not fully; quality, acceptance, outcomes, and benefits matter
A risk response is listed but nobody owns it. What is wrong?	No clear accountability for monitoring and action
A project team captures lessons only at final closure. What is the weakness?	Lessons are captured too late to improve current delivery
A fixed-price contract is signed. Is supplier risk gone?	No; integration, quality, change, delay, relationship, and contract management remain
A project manager updates the baseline to match actual delay. What is the issue?	Baseline changes need approval; otherwise variance is hidden

Independent question-bank practice plan

Use this Cheat Sheet before starting intensive practice, then let the question bank expose weak areas.

Run topic drills first. Start with lifecycle, governance, business case, planning, risk, quality, stakeholders, and change control.
Review detailed explanations, not just scores. For every missed question, identify whether the error was terminology, application, calculation, or exam technique.
Create a trap log. Record repeated mistakes such as risk versus issue, assurance versus control, or baseline versus forecast.
Practise mixed sets. PMQ questions often combine topics; for example, a change request may affect business case, schedule, cost, stakeholders, risk, and procurement.
Use mock exams after topic confidence improves. Timed practice is most useful when you already understand the core concepts.
Re-drill weak topics. Do not simply read the explanation once; answer similar original practice questions until the decision rule becomes automatic.

Put the review into practice

PM Mastery

Start Cheat Sheet practice on Web

Tip: Use the web app to preview question style, then practise the topics you need to revisit.

Use the web app for Cheat Sheet scenario practice, topic drills, timed mock exams, detailed explanations, and saved progress. Original PM Mastery practice only; not official questions, copied live-exam content, or exam dumps.

Current alignment Mapped to the current exam content outline, domains, tasks, learning outcomes, or syllabus areas for this exam.

Practice modes Use topic drills, timed mocks, scenario practice, and focused pages before deeper mixed practice.

Teaching explanations Explanations teach the project, agile, governance, or delivery rule that makes the best option stronger.

Stable bank Questions are prebuilt and reviewed before publication, so practice is stable and inspectable, not improvised during a quiz.

Study Plan