This Quick Reference 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.
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 |
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 |
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 |
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 |
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 |
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]
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 |
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 |
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 |
\[
\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.
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 |
\[
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”.
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 |
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 |
\[
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 |
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 |
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 |
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.
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 |
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 |
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
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 |
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 |
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.
Practical next step
Choose one weak area, such as earned value, change control, benefits, or risk. Do three timed written practice answers: one definition, one scenario decision, and one calculation or comparison. Mark each answer for accuracy, application, and consequence before moving to the next topic.