PMQ — APM Project Management Qualification Quick Reference

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

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 thisWeak answer trap
DefineGive a precise meaning, then the project-management purposeListing examples only
DescribeState what it is and key features or stepsExplaining benefits but not features
ExplainGive reason and consequence: “because… therefore…”Defining without cause/effect
CompareUse explicit similarities/differencesDiscussing only one side
Recommend / justifyState option, reason, condition, and riskGiving an opinion without criteria
CalculateShow method, substitute values, interpret resultGiving number only
Analyse scenarioIdentify issue, link to PM principle, propose next actionGeneric best practice with no scenario link

Compact answer structure

Use this when stuck:

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

Core project-management distinctions

TermPractical meaningPMQ distinction
ProjectTemporary endeavour to deliver outputs, outcomes, or benefitsUnique and transient; not routine operations
ProgrammeCoordinated group of related projects and change activitiesFocuses on strategic outcomes and benefits across projects
PortfolioCollection of projects/programmes managed to meet strategic objectivesPrioritisation and investment-level governance
OutputDeliverable produced by the projectTangible or measurable product/service capability
OutcomeChange resulting from using outputsOften realised after handover
BenefitMeasurable improvement valued by stakeholdersNeeds ownership, baseline, target, and realisation tracking
ObjectiveSpecific target the project is set to achieveShould align with business case and success criteria
Success criteriaMeasures used to judge successCan include time, cost, quality, benefits, stakeholder satisfaction
ConstraintLimitation within which the project must operateExamples: budget cap, deadline, regulation, resource availability
AssumptionSomething treated as true for planningMust be validated; may become a risk
DependencyRelationship between activities, deliverables, or external factorsDrives sequencing and risk exposure
IssueCurrent problem requiring actionDifferent from risk, which is uncertain
RiskUncertain event or condition affecting objectivesCan be threat or opportunity

Lifecycle and governance reference

Lifecycle decision table

LifecycleChoose whenStrengthsWatch for
Linear / predictiveRequirements are stable, solution is understood, governance needs staged controlStrong baselines, clear approvals, easier supplier contractingWeakness under high uncertainty or fast-changing requirements
IterativeSolution needs repeated refinementLearning through cycles; feedback improves qualityScope creep if iteration goals are not controlled
IncrementalUseful parts can be delivered in releasesEarly value; staged acceptanceIntegration and dependency management
Agile / adaptiveRequirements are uncertain and user feedback is frequentFlexibility, customer collaboration, prioritised backlogNeeds empowered product ownership and disciplined governance
HybridSome work is predictable, some needs adaptationBalances control and flexibilityConfusion if governance, roles, and baselines are not clear

Generic project lifecycle control points

StageManagement focusTypical artefacts / decisions
ConceptIs there a justified need?Strategic fit, initial business case, options, feasibility
DefinitionWhat exactly will be delivered and how?Project management plan, scope, schedule, budget, risk plan, governance, baseline approval
Deployment / deliveryBuild, manage, control, report, and assure workWork packages, progress reports, issue logs, change requests, quality records
Transition / handoverMove outputs into operational useAcceptance, training, handover, support model, benefits ownership
ClosureConfirm completion and capture learningClosure report, lessons learned, final accounts, release resources

Governance bodies and roles

Role / bodyMain purposePMQ trap
SponsorOwns business case, secures funding, champions project, makes key decisionsSponsor is not the day-to-day scheduler
Project managerPlans, coordinates, monitors, controls, reports, manages delivery within delegated authorityPM escalates outside tolerance; does not unilaterally change approved baselines
Project board / steering groupProvides direction, decisions, and governance oversightNot a substitute for the project manager’s daily control
User / customer representativeDefines needs and accepts outputsAcceptance must be based on agreed criteria
Product owner, where usedPrioritises value and backlog in agile/adaptive deliveryNot the same as sponsor unless explicitly combined
Team membersDeliver work packages and provide estimates/progress updatesNeed clear responsibilities and interfaces
PMOProvides standards, support, assurance, reporting, methods, sometimes resource coordinationPMO can be supportive, controlling, or directive
Assurance roleChecks project is being managed properly and outputs are fit for purposeAssurance is not the same as quality control testing
Change authorityReviews and approves/rejects change requests within delegated limitsChange control protects baselines; it does not prevent all change

Business case and benefits

Business case essentials

ElementWhy it matters
Strategic alignmentShows why the project should exist
Options analysisDemonstrates alternatives were considered
CostsInvestment, delivery, lifecycle, and operating implications
BenefitsQuantified and non-quantified value expected
RisksUncertainty that could affect viability
TimescalesWhen outputs, outcomes, and benefits are expected
Investment appraisalSupports value-for-money decision making
OwnershipConfirms who is accountable for realising benefits
Review pointsConfirms 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

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

Scope, requirements, and configuration

Scope artefacts

ArtefactUseExam clue
Requirements documentationCaptures stakeholder needs and constraints“Users disagree on what is needed”
Product breakdown structureDecomposes the product/deliverables“What must be produced?”
Work breakdown structureDecomposes work required to deliver scope“What work packages are needed?”
Scope statementDefines included/excluded work and boundaries“Prevent misunderstanding of what is in scope”
Acceptance criteriaDefines conditions for acceptance“How will customer know it is acceptable?”
Configuration management recordsIdentify and control versions of products“Multiple versions, uncontrolled changes, traceability problem”
Requirements traceabilityLinks 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

SituationBest next actionTrap
Stakeholder asks for extra feature informallyRaise/log change request and assess impactAgreeing because it seems small
Change affects approved cost/time baselineEscalate to authorised decision-makerPM approving beyond authority
Urgent safety/regulatory issueTake appropriate immediate protective action, then formalise decision and recordsIgnoring governance or delaying necessary action
Supplier proposes technical substitutionAssess quality, risk, contractual, cost, and configuration impactAccepting based only on lower cost
Multiple uncontrolled product versions existApply configuration management and version controlTreating it as a communication issue only

Planning and scheduling

Planning hierarchy

LevelPurposeTypical content
Project management planIntegrated “how the project will be managed”Scope, schedule, cost, risk, quality, communications, resources, governance
Stage / phase planDetailed planning for a controlled sectionActivities, milestones, resources, controls
Work packageDelegated unit of workDeliverables, acceptance criteria, estimates, dependencies, reporting
ScheduleTime-based model of activitiesDurations, dependencies, milestones, critical path
BaselineApproved reference pointUsed to measure variance and control change

Estimating methods

MethodBest used whenStrengthWeakness
AnalogousSimilar previous work existsFastLess accurate if context differs
ParametricReliable productivity/cost rates existScalable and evidence-basedDepends on valid parameters
Bottom-upWork is well definedMore detailed and credibleTime-consuming
Expert judgementSpecialist knowledge is neededPractical where data is limitedBias risk
Three-point estimatingUncertainty is significantShows range and riskCan create false precision
DelphiNeed to reduce expert biasAnonymous convergenceTakes coordination

Network scheduling essentials

ConceptMeaningExam use
ActivityTask consuming time/resourcesBuild network from activities
DependencyLogical relationship between activitiesDetermines sequence
MilestoneZero-duration significant pointUsed for control and reporting
Critical pathLongest path through networkDetermines shortest project duration
Total floatTime an activity can slip without delaying project finishZero float often indicates critical activity
Free floatTime an activity can slip without delaying successorUseful for local scheduling flexibility
LeadAllows successor to start before predecessor fully finishesCan increase risk if overused
LagDelay between activitiesShould 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.

Cost management and earned value

Cost terms

TermMeaning
Direct costDirectly attributable to project work
Indirect costShared overhead not directly assigned to one activity
Fixed costDoes not vary with activity volume over relevant range
Variable costChanges with activity volume
ContingencyBudget allowance for known-unknown risk responses
Management reserveAdditional allowance usually controlled outside PM’s routine authority
Sunk costAlready incurred cost; should not justify continuing a poor investment
Whole-life costCost across acquisition, operation, maintenance, disposal

Earned value formulas

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

Interpretation:

MeasurePositive / above 1Negative / below 1
Schedule variance, SVAhead of planned valueBehind planned value
Cost variance, CVUnder budget for work performedOver budget for work performed
Schedule performance index, SPIProgressing faster than plannedProgressing slower than planned
Cost performance index, CPICost efficientCost 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

StepPurposeTypical artefacts
IdentifyFind threats and opportunitiesRisk register, workshops, checklists
AssessUnderstand probability, impact, proximity, severityProbability-impact matrix, scoring, EMV
Plan responsesDecide actions and ownersResponse plans, contingency, fallback
ImplementCarry out agreed responsesAction tracking
MonitorReview status, triggers, residual riskRisk reports, updated register
EscalateMove risks outside authority/tolerance to governance levelEscalation reports, sponsor decisions

Risk response strategies

For threatsMeaning
AvoidChange plan to remove threat
Reduce / mitigateLower probability or impact
TransferShift financial/contractual impact to another party, often at a cost
AcceptTake no proactive action beyond monitoring or contingency
For opportunitiesMeaning
ExploitEnsure opportunity happens
EnhanceIncrease probability or benefit
ShareWork with another party to capture opportunity
AcceptTake 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

SituationClassificationManagement response
“Supplier may miss the delivery date”RiskAssess probability/impact and plan response
“Supplier has missed the delivery date”IssueLog, assign action, assess impact
“Customer wants a different delivery date”ChangeRaise change request and assess baseline impact
“Assumption about resource availability is doubtful”RiskValidate assumption and add risk if uncertain
“Approved design is no longer correct”Issue and likely changeControl through issue management and change control

Quality management

Quality distinctions

TermMeaningTrap
Quality planningDefines standards, criteria, methods, and responsibilitiesNot the same as inspection
Quality assuranceConfirms processes are suitable and being followedFocuses on process confidence
Quality controlChecks outputs against criteriaDetects defects in deliverables
GradeCategory or level of featuresLow grade can still be high quality if it meets requirements
AcceptanceCustomer/user confirmation output meets agreed criteriaNot just internal testing
VerificationBuilt correctly against specification“Did we build it right?”
ValidationMeets user need/intended use“Did we build the right thing?”

Quality cost categories

CategoryExamples
PreventionTraining, standards, quality planning
AppraisalReviews, inspections, testing
Internal failureRework before delivery
External failureDefects found by customer, warranty, reputation damage

Procurement and contract selection

Contract typeSupplier riskBuyer riskChoose whenWatch for
Fixed priceHigherLower if scope is stableRequirements are clear and change is limitedSupplier may price risk or resist change
Cost reimbursableLowerHigherScope uncertain or innovation neededRequires strong cost control
Time and materialsMediumMedium to highFlexible support or unclear durationCan drift without caps and monitoring
Target cost / incentiveSharedSharedNeed collaboration and cost-performance incentivesIncentive structure must align behaviour
Framework agreementDepends on call-offDepends on termsRepeated procurement from pre-qualified suppliersStill 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

DimensionMeaningManagement implication
PowerAbility to influence projectHigh power needs active management
InterestLevel of concern or involvementHigh interest needs engagement and information
AttitudeSupportive, neutral, resistantTailor engagement approach
ImpactHow much the project affects themHigh impact may require change support
Influence networkFormal and informal relationshipsIdentify hidden blockers/champions

Engagement strategies

Stakeholder positionAimExample action
High power, high interestManage closelyRegular decision briefings, involve in trade-offs
High power, low interestKeep satisfiedConcise exception reporting
Low power, high interestKeep informedUpdates, workshops, FAQs
Low power, low interestMonitorPeriodic communications
Resistant but importantUnderstand cause and address concernsOne-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

AreaPractical PM behaviour
DirectionClarify objectives, priorities, constraints
MotivationUnderstand individual/team drivers and remove blockers
DelegationAssign work with authority, expectations, and reporting
CoachingBuild capability, especially in uncertain work
Conflict managementAddress causes early and constructively
Decision-makingUse evidence, authority limits, and governance
Ethics and professionalismAct transparently, fairly, and responsibly

Team development reference

StageSymptomsPM focus
FormingPolite, uncertain, dependent on leaderClarify purpose, roles, ways of working
StormingConflict, challenge, tensionFacilitate, resolve issues, reinforce objectives
NormingWorking practices emergeEncourage collaboration and accountability
PerformingProductive, self-managingEmpower, remove blockers, sustain performance
AdjourningWork ends, team disbandsRecognise contribution, capture lessons, release resources

Conflict-handling options

ApproachUse whenRisk
CollaborateImportant issue, need durable solutionTakes time
CompromiseNeed workable middle groundMay not fully satisfy either party
AccommodateIssue is low importance to you or relationship matters moreCan create imbalance
Force / directUrgent decision or safety/compliance issueCan damage trust
AvoidIssue is trivial or cooling-off is neededProblem may grow if substantive

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

Reports and records

ArtefactPurposeAudience
Highlight / status reportSummarise progress, forecast, risks, issues, decisions neededSponsor, board, PMO
Exception reportEscalate forecast breach of tolerance or major issueGovernance body
Risk registerRecord risks, owners, assessments, responsesPM, sponsor, risk owners
Issue logTrack current problems and actionsPM and team
Decision logPreserve decision rationale and accountabilityPM, governance, audit
Lessons logCapture learning during the projectCurrent and future teams
Change logTrack requested, approved, rejected, implemented changesPM, change authority
Configuration recordsTrack versions and status of productsTeam, quality, assurance

Agile and adaptive concepts in PMQ context

ConceptMeaningPMQ distinction
BacklogPrioritised list of work or requirementsDynamic; needs active ownership
TimeboxFixed period for focused deliveryScope may flex to protect time
IncrementUsable addition delivered at end of cycleSupports early feedback
Iteration reviewDemonstrates completed work and gathers feedbackNot just a status meeting
RetrospectiveImproves team processFocuses on how the team works
Product ownerMaximises product value and prioritises needDifferent from project sponsor governance role
Minimum viable productSmallest useful release to validate valueNot low-quality delivery

Predictive vs agile decision points

QuestionPredictive leaningAgile/adaptive leaning
Are requirements stable?YesNo
Is solution well understood?YesNo
Is customer feedback needed frequently?Less frequentlyVery frequently
Is regulatory/stage approval dominant?Stronger fitStill possible, but governance must be tailored
Can outputs be released incrementally?Not necessaryPreferable
Is contract scope fixed?EasierNeeds flexible commercial model

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

Scenario clueBest next stepWhy
Forecast exceeds agreed toleranceEscalate with options and impactPM authority is limited by governance
Stakeholders disagree on prioritiesFacilitate prioritisation using objectives/business casePrevents unmanaged scope and conflict
Benefits no longer justify costReview and escalate business case viabilityProject should remain justified
Team member reports hidden delayUpdate schedule forecast, assess critical path, communicate impactControl requires accurate data
Risk has occurredTreat as issue, implement contingency, update risk/issue recordsRisk uncertainty has become current problem
Customer rejects deliverableCompare against acceptance criteria; manage defect or changeDistinguish non-conformance from new requirement
Sponsor asks to skip quality checksExplain risk and governance impact; seek formal decision if necessaryQuality controls protect acceptance and benefits
Supplier underperformsCheck contract, document issue, engage supplier, escalate if neededEvidence and commercial route matter
User adoption is weakReview change management, training, communications, benefits planOutputs alone do not guarantee outcomes
Multiple teams use different plansIntegrate schedules, dependencies, assumptions, and reportingProject control needs a single coherent view

High-yield PMQ distinctions

Do not confuse…Correct distinction
Risk and issueRisk is uncertain; issue is happening now
Contingency and management reserveContingency is for identified risks; management reserve is usually broader and more controlled
Assurance and controlAssurance checks process confidence; control checks outputs/performance
Product breakdown and work breakdownProduct breakdown shows deliverables; work breakdown shows work
Milestone and activityMilestone has no duration; activity consumes time/resources
Change request and issueChange request proposes baseline alteration; issue is a current problem
Benefit and deliverableBenefit is value realised; deliverable is output produced
Stakeholder communication and engagementCommunication sends/receives information; engagement manages relationship and commitment
Progress and performanceProgress is work completed; performance compares progress/cost/time against plan
Leadership and managementLeadership 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.