PFQ — APM Project Fundamentals Qualification Quick Reference

Last revised: July 1, 2026

Compact APM PFQ reference covering project lifecycle, roles, governance, planning, risk, quality, change and core exam distinctions.

How to use this Quick Reference

This independent Quick Reference is for candidates preparing for the Association for Project Management APM Project Fundamentals Qualification (PFQ), exam code PFQ. Use it to revise core project management terms, role distinctions, lifecycle concepts, and exam-style decision points.

Focus on:

Definitions: know the precise difference between similar terms.
Purpose: understand why an artifact, role, or process exists.
Sequence: know what happens before and after key controls.
Accountability: distinguish sponsor, project manager, team, users, and governance bodies.
Application: select the best next action in a simple scenario.

Core project environment terms

Term	Practical meaning	PFQ exam cue
Project	Temporary, unique work to create outputs that enable change	Has defined objectives, start/end, constraints, risk
Business as usual	Ongoing operational work	Repetitive, stable, service/operations focused
Programme	Coordinates related projects and change activities to achieve strategic outcomes	Benefits and change across multiple projects
Portfolio	Collection of projects/programmes managed to meet strategic priorities	Prioritisation, investment, balance, governance
Project management	Application of processes, methods, skills and knowledge to achieve project objectives	Delivery within agreed constraints
Output	Tangible or intangible deliverable produced by the project	“What the project creates”
Outcome	Change resulting from use of outputs	“What is different after use”
Benefit	Measurable improvement perceived as positive by stakeholders	Usually owned by the sponsor/business
Objective	Specific result the project is set up to achieve	Should be clear and measurable
Constraint	Limitation imposed on the project	Time, cost, scope, quality, resources, risk
Assumption	Something treated as true for planning	Must be recorded and validated
Dependency	Relationship where one activity, project, supplier or decision relies on another	Can affect schedule and risk
Risk	Uncertain event or condition that may affect objectives	Future uncertainty
Issue	Current problem or event affecting the project	Has happened or is happening
Change request	Proposed alteration to agreed baseline	Must be assessed and controlled

Project, programme, portfolio and operations

Situation	Best label	Why
Build and launch a new customer portal	Project	Temporary change with a defined output
Run the customer portal service desk every day	Business as usual	Ongoing operational service
Modernise all customer channels through several coordinated projects	Programme	Multiple related projects delivering broader outcomes
Decide which change initiatives receive funding this year	Portfolio management	Strategic prioritisation and investment balance
Deliver one product upgrade inside a larger transformation	Project within programme	Project contributes outputs to programme benefits

Common trap: a project may support benefits, but benefits often continue after project closure. Do not confuse delivering an output with realising a benefit.

Lifecycle reference

A project lifecycle provides a structured path from idea to closure. A typical project lifecycle can be viewed as: concept, definition, development, handover/closure, followed by benefits realisation where relevant.

Phase	Main purpose	Typical outputs/artifacts	Key exam question
Concept	Decide whether the idea is worth exploring	Initial need, outline business case, high-level risks, feasibility view	“Is there a viable reason to start?”
Definition	Define scope, approach, justification and controls	Business case, project management plan, scope, schedule, budget, risk register	“What exactly will be delivered and how?”
Development/delivery	Build or implement the outputs	Products, work packages, progress reports, issue/change records	“Are we delivering against baseline?”
Handover and closure	Transfer outputs, confirm acceptance, close work	Acceptance records, handover plan, closure report, lessons	“Has the project delivered and closed properly?”
Benefits realisation	Confirm outcomes and benefits from use	Benefits reviews, performance measures	“Did the change produce intended value?”

Lifecycle types

Lifecycle type	Best suited to	Characteristics	Watch for
Predictive / linear	Stable scope, known solution, regulated or sequential work	Plan first, then execute in controlled stages	Weak fit where requirements are uncertain
Iterative	Need learning and refinement	Repeated cycles improve solution	Scope may evolve through feedback
Incremental	Value can be delivered in parts	Usable increments released over time	Integration and prioritisation matter
Agile / adaptive	High uncertainty, fast feedback, evolving requirements	Short cycles, collaboration, reprioritisation	Still needs governance and business justification
Hybrid	Mixed certainty across workstreams	Combines predictive controls with adaptive delivery	Tailoring must be deliberate, not accidental

Governance and control

Governance is the framework of authority, accountability and decision-making that ensures the project remains justified, controlled and aligned with organisational objectives.

Governance element	Purpose	Candidate cue
Sponsor accountability	Owns business justification and senior-level support	“Who is ultimately accountable for the business case?”
Defined roles	Clarify who decides, manages, does, assures and accepts	Prevents gaps and duplication
Business case	Justifies investment and continued viability	Reviewed at key decision points
Project management plan	Integrates scope, schedule, cost, quality, risk, communications and controls	Main delivery control document
Stage/phase gates	Formal review points before committing further resources	Continue, change, pause or stop
Tolerances	Agreed limits for time, cost, scope, quality, risk or benefits	Exceeding tolerance triggers escalation
Assurance	Independent or semi-independent confidence that controls are effective	Not the same as delivery management
Reporting	Provides progress, forecast and exception information	Supports informed decisions
Change control	Protects baselines from uncontrolled change	Assess impact before approval
Lessons learned	Captures experience for current/future improvement	Should happen throughout, not only at the end

Basic control cycle

Step	Question	Typical action
Plan	What should happen?	Set baseline, responsibilities, controls
Monitor	What is happening?	Collect actual progress, costs, risks, issues
Compare	What is the variance?	Compare actuals to plan and tolerance
Forecast	Where will we end up?	Predict final time, cost, quality and benefit impact
Correct	What action is needed?	Adjust work, escalate, replan or request change
Report	Who needs to know?	Provide accurate status and decisions needed

Roles and responsibilities

Role	Primary responsibility	Not primarily responsible for
Project sponsor	Business case, funding support, strategic alignment, senior decisions	Day-to-day task management
Project manager	Plan, coordinate, monitor and control project delivery	Owning the business benefit alone
Project team member	Complete assigned work packages or tasks	Overall governance decisions
User/customer representative	Define needs, validate usability, accept outputs where appropriate	Managing the full project plan
Supplier/contractor	Provide contracted goods or services	Business ownership of the project
Steering group / project board	Governance direction, key approvals, escalation decisions	Performing detailed delivery work
PMO / project support	Methods, templates, reporting, configuration support, assurance support	Replacing the project manager’s accountability
Assurance role	Check that the project is being managed appropriately	Making routine delivery decisions
Change authority	Assess and approve/reject changes within delegated authority	Uncontrolled acceptance of all requests

RACI quick distinction

RACI term	Meaning	Exam cue
Responsible	Does the work	Can be multiple people
Accountable	Ultimately answerable for the result	Should be one clear owner
Consulted	Provides input before action/decision	Two-way communication
Informed	Kept updated after action/decision	One-way communication

Common trap: responsible and accountable are not the same. The project manager may be responsible for managing delivery, while the sponsor is accountable for business justification.

Business case and benefits

Concept	Purpose	Key contents or examples
Business case	Justifies starting and continuing the project	Need, options, costs, benefits, risks, timescale, investment rationale
Benefit	Measurable positive outcome	Reduced processing time, increased revenue, improved compliance
Disbenefit	Measurable negative consequence of change	Increased maintenance cost, temporary productivity dip
Benefit owner	Person accountable for benefit realisation	Often from the business, not the delivery team
Benefits management	Identifies, plans, tracks and reviews benefits	Links outputs to outcomes and value
Success criteria	Measures used to judge project success	Can include time, cost, quality, stakeholder satisfaction, benefits

Output-outcome-benefit chain

Example	Output	Outcome	Benefit
New CRM system	Implemented CRM platform	Sales teams use shared customer data	Faster sales cycle, better customer insight
Training project	Training materials and sessions	Staff apply new process	Fewer errors, improved productivity
Office relocation	New office ready for use	Teams operate from new location	Lower rent, improved collaboration

Planning artifacts and when to use them

Artifact	Purpose	Distinction to remember
Project management plan	Integrated plan for managing the project	Broader than a schedule
Scope statement	Defines what is included and excluded	Helps prevent scope creep
Product breakdown structure	Hierarchy of products/deliverables	Product-focused
Work breakdown structure	Hierarchy of work needed to deliver scope	Work-focused
Organization breakdown structure	Shows organisational units or reporting structure	People/organisation-focused
Responsibility assignment matrix	Maps work to roles or people	Often uses RACI
Schedule / Gantt chart	Shows activities over time	Good for communicating timing
Network diagram	Shows logical dependencies between activities	Good for critical path analysis
Milestone plan	Shows key decision or delivery points	Milestones have zero or minimal duration
Resource histogram	Shows resource demand over time	Helps identify overloads
Cost baseline	Approved time-phased budget	Used to monitor cost performance
Risk register	Records risks, assessments, responses and owners	Future uncertainty
Issue log	Records current problems needing action	Current reality
Change log	Records requested, approved and rejected changes	Protects baseline integrity

Scheduling essentials

Term	Meaning	Exam cue
Activity	Piece of work in the schedule	Has duration and dependencies
Duration	Calendar time taken to complete work	Not the same as effort
Effort	Amount of labour required	Example: 5 person-days
Milestone	Significant point or event	Usually no duration
Dependency	Logical relationship between activities	Determines sequencing
Lead	Allows successor to start earlier	Overlap
Lag	Delay between linked activities	Waiting time
Critical path	Longest path through the network	Determines shortest project duration
Float/slack	Time an activity can slip without affecting a defined date	Zero float often indicates critical activity
Baseline	Approved version of plan used for control	Change through formal control

Dependency types

Dependency	Meaning	Simple example
Finish-to-start	Successor starts after predecessor finishes	Build wall before painting wall
Start-to-start	Successor starts after predecessor starts	Start testing after development starts
Finish-to-finish	Successor finishes after predecessor finishes	Finish documentation after testing finishes
Start-to-finish	Successor finishes after predecessor starts	Rare; old service ends after new service starts

Core schedule formulas

\[ \text{Total Float} = \text{Late Start} - \text{Early Start} = \text{Late Finish} - \text{Early Finish} \]\[ \text{Free Float} = \text{Earliest Start of Next Activity} - \text{Early Finish of Current Activity} \]

Use these formulas only when the scenario provides the needed network data. For many PFQ-style questions, the main concept is that the critical path is the longest path and has the least scheduling flexibility.

Estimating and budgeting

Technique	Best use	Strength	Weakness
Analogous estimating	Early estimate based on similar past work	Quick	Less accurate if comparison is weak
Parametric estimating	Uses measurable rate or formula	Repeatable	Depends on valid data
Bottom-up estimating	Estimate detailed components then aggregate	More detailed and credible	Time-consuming
Expert judgement	Uses experienced input	Useful when data is limited	Can be biased
Three-point estimating	Uses optimistic, most likely and pessimistic views	Captures uncertainty	Still depends on estimate quality

Cost terms

Term	Meaning	Exam distinction
Budget	Approved funding for the project or work package	Control reference
Cost baseline	Approved time-phased budget	Used for performance comparison
Contingency	Provision for identified uncertainty	Linked to known risks
Management reserve	Provision for unforeseen work, if used by the organisation	Normally controlled at senior level
Committed cost	Cost committed but not necessarily paid	Example: purchase order placed
Actual cost	Cost incurred for completed work	Used in performance reporting
Forecast cost	Expected future or final cost	Updated as project progresses

Earned value and performance formulas

Earned value terms may appear as basic control concepts. Know the direction of good and bad variances.

Measure	Plain formula	Interpretation
Planned Value	PV = budgeted value of scheduled work	What should have been earned by now
Earned Value	EV = budgeted value of completed work	Value of work actually completed
Actual Cost	AC = actual cost of completed work	What has been spent
Cost Variance	CV = EV - AC	Positive is under budget; negative is over budget
Schedule Variance	SV = EV - PV	Positive is ahead; negative is behind
Cost Performance Index	CPI = EV / AC	Greater than 1 is cost efficient
Schedule Performance Index	SPI = EV / PV	Greater than 1 is ahead of plan
Estimate at Completion	EAC = forecast final cost	Several methods exist; use scenario guidance

\[ \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}} \]

Common trap: a project can be under budget but behind schedule, or over budget but ahead of schedule. Read both cost and schedule indicators separately.

Risk, issue and change control

Risk process

Step	Purpose	Typical output
Identify	Find threats and opportunities	Risk descriptions
Assess	Estimate probability and impact	Prioritised risk list
Plan responses	Decide what to do	Response actions and owners
Implement responses	Carry out agreed actions	Updated plans and risk status
Monitor and review	Track exposure and effectiveness	Updated risk register and reports

Risk terms

Term	Meaning	Exam cue
Threat	Uncertain event with negative effect	May increase cost, delay work, reduce quality
Opportunity	Uncertain event with positive effect	May reduce cost, save time, improve value
Probability	Likelihood of occurrence	Often scored high/medium/low
Impact	Effect if it occurs	Time, cost, quality, scope, benefits, reputation
Proximity	How soon the risk may occur	Near risks need urgent attention
Risk owner	Accountable for managing a risk	Ensures response is planned and monitored
Risk action owner	Completes a specific response action	May differ from risk owner
Residual risk	Risk remaining after response	Must still be accepted or managed
Secondary risk	New risk created by a response	Do not ignore side effects

\[ \text{Risk Exposure} = \text{Probability} \times \text{Impact} \]

Risk response choices

Risk type	Response	Meaning
Threat	Avoid	Change plan so the threat cannot occur or no longer affects objectives
Threat	Reduce / mitigate	Lower probability and/or impact
Threat	Transfer	Shift financial or delivery impact to another party, often by contract or insurance
Threat	Accept	Take no immediate action beyond monitoring or contingency
Opportunity	Exploit	Make the opportunity happen
Opportunity	Enhance	Increase probability or impact
Opportunity	Share	Work with another party to realise the opportunity
Opportunity	Accept	Take advantage if it occurs, without active pursuit

Risk vs issue vs change

Scenario wording	Correct classification	First response
“Supplier may be late next month”	Risk	Assess probability/impact and plan response
“Supplier has missed the delivery date”	Issue	Log, analyse impact, assign action/escalate if needed
“User wants an extra feature”	Change request	Record and assess impact before approval
“Approved scope is no longer achievable within tolerance”	Exception / escalation need	Escalate to governance or sponsor
“A risk response requires extra budget”	Potential change	Raise change request if baseline impact is expected

Change control quick path

Step	Question	Output
Capture request	What is being requested and why?	Change request logged
Initial screen	Is it valid and clear?	Accepted for assessment or rejected/returned
Impact assessment	What is the effect on scope, time, cost, quality, risk and benefits?	Impact analysis
Decision	Approve, reject, defer or request more information?	Decision record
Update baselines	What approved plans must change?	Revised baseline/configuration records
Communicate	Who needs to know?	Stakeholder updates
Implement and verify	Has the change been delivered correctly?	Completed change record

Common trap: do not implement a scope change just because it seems useful. First assess impact and obtain the required approval.

Quality management

Concept	Meaning	PFQ distinction
Quality	Degree to which outputs meet requirements and fitness for purpose	Not “gold-plating”
Quality planning	Defines standards, criteria, responsibilities and methods	Done before delivery/control
Quality assurance	Confidence that processes are appropriate and followed	Process-focused
Quality control	Inspection/testing of outputs against criteria	Product/output-focused
Acceptance criteria	Conditions that must be met for acceptance	Should be defined early
Verification	Checks output meets specification	“Built right”
Validation	Checks output meets user need	“Built the right thing”
Defect	Non-conformance with requirement	Triggers correction or acceptance decision
Cost of quality	Cost of prevention, appraisal and failure	Prevention is usually preferable to late correction

Quality examples

Activity	Quality planning, assurance or control?	Why
Define test approach and acceptance criteria	Planning	Sets standards before work
Audit whether project processes are being followed	Assurance	Checks process compliance
Inspect delivered equipment against specification	Control	Checks actual output
Review supplier quality procedures	Assurance	Focuses on supplier process capability
Run user acceptance testing	Control / validation	Confirms product meets user need

Stakeholder and communication management

Term	Meaning	Exam cue
Stakeholder	Person or group that can affect, be affected by, or perceive itself affected by the project	Includes internal and external parties
Stakeholder analysis	Identifies interests, influence, attitudes and needs	Supports engagement strategy
Engagement	Building support and managing expectations	More than sending information
Communication plan	Defines message, audience, timing, channel, owner and feedback method	Tailor communication to stakeholder needs
Power-interest grid	Prioritises engagement based on influence and interest	High power/high interest need close management
Communication barrier	Anything that distorts or blocks understanding	Language, culture, noise, assumptions, poor channel
Feedback	Confirmation that message was received and understood	Essential for effective communication

Stakeholder engagement choices

Stakeholder situation	Better approach
High power, high interest	Manage closely; involve in decisions
High power, low interest	Keep satisfied; concise senior updates
Low power, high interest	Keep informed; use appropriate detail
Low power, low interest	Monitor; avoid over-communication
Resistant but influential	Understand concerns, engage early, escalate if blocking
Supportive and influential	Use as advocate or champion where appropriate

Teamwork and leadership

Concept	Meaning	Exam distinction
Leadership	Sets direction, motivates, influences and enables people	Not only formal authority
Management	Plans, organises, monitors and controls work	Complements leadership
Delegation	Assigning authority and responsibility for work	Accountability must remain clear
Motivation	Factors that encourage commitment and performance	Different people value different motivators
Conflict	Disagreement over goals, priorities, resources or approach	Can be constructive if managed
Collaboration	Working jointly toward shared objectives	Important across functions and suppliers
Team development	Building capability and working relationships	Needs time, clarity and trust

Team development cues

Stage cue	Likely need from project manager
New team, uncertain roles	Clarify objectives, roles, ways of working
Disagreement and tension	Facilitate conflict resolution and clarify priorities
Team establishes norms	Reinforce standards and collaboration
High-performing team	Remove blockers, empower, monitor outcomes
Project closing	Recognise contribution, capture lessons, release resources

Procurement and supplier management

Concept	Meaning	Exam cue
Procurement strategy	Decides what to buy, how to buy, and how suppliers will be managed	Aligns with risk, schedule and capability
Make-or-buy decision	Decide whether work is done internally or externally	Consider capability, cost, risk, time
Tendering	Process for inviting and assessing supplier proposals	Requires clear requirements and evaluation criteria
Contract	Legally binding agreement for goods/services	Defines obligations, scope, price, terms
Fixed-price contract	Price agreed for defined scope	More supplier cost risk if scope is clear
Cost-reimbursable contract	Buyer pays allowable costs, often plus fee	More buyer cost risk; useful for uncertain scope
Time and materials	Pay for time and materials used	Flexible but needs strong control
Supplier management	Monitors performance, quality, changes and relationships	Contract does not remove need for active management

Procurement decision cues

Scenario	Likely contract/control emphasis
Scope is clear and stable	Fixed price may be suitable
Scope is uncertain or exploratory	Cost-reimbursable or flexible arrangement may fit
Need specialist skill not available internally	External procurement may be justified
Supplier deliverable affects critical path	Strong monitoring and escalation routes
Contracted work changes	Use formal change control

Configuration, information and document control

Term	Meaning	Why it matters
Configuration management	Identifies and controls versions of project products and documents	Prevents confusion over approved versions
Configuration item	Product, document or component under control	Has identity, version and status
Baseline	Approved reference point	Enables variance and change control
Version control	Tracks revisions and current approved version	Avoids using outdated information
Document control	Manages creation, review, approval, storage and access	Supports auditability and communication
Information management	Ensures information is accurate, timely, secure and usable	Supports decisions and compliance
Lessons log	Records learning during the project	Feeds improvement and closure reporting

Reporting and escalation

Report/control	Purpose	Typical audience
Progress/status report	Current performance against plan	Project manager, team, stakeholders
Highlight report	Summary of progress, risks, issues and decisions	Sponsor or governance body
Exception report	Warns that tolerances may be or have been exceeded	Sponsor/governance decision-makers
Risk report	Summarises key threats/opportunities and exposure	Project manager, sponsor, governance
Issue log/report	Tracks current problems and actions	Project team and decision-makers
Change log/report	Tracks requested and approved changes	Change authority, sponsor, PM
Closure report	Confirms completion, performance, open items and lessons	Sponsor/governance
Benefits review	Checks whether intended benefits are being realised	Sponsor/business owners

Escalation cues

If the scenario says…	Best next action
Variance is within tolerance	Manage within project manager authority
Forecast exceeds tolerance	Escalate with options and impact
A risk threatens business justification	Inform sponsor/governance promptly
A team member lacks clarity	Clarify role, task, acceptance criteria
A stakeholder requests extra scope	Raise/assess change request
A supplier misses a contractual milestone	Log issue, assess impact, follow contract and escalation route
Information is incomplete	Seek facts before deciding

Common PFQ distinction table

Pair	Difference
Risk vs issue	Risk is uncertain and future; issue is current or has occurred
Output vs outcome	Output is delivered product; outcome is change caused by using it
Outcome vs benefit	Outcome is changed state; benefit is measurable positive value
Sponsor vs project manager	Sponsor owns business justification; PM manages delivery
Assurance vs control	Assurance checks processes/confidence; control monitors and corrects performance
Quality assurance vs quality control	Assurance is process-focused; control is product-focused
Scope creep vs approved change	Scope creep is uncontrolled; approved change follows formal process
Product breakdown structure vs work breakdown structure	PBS shows deliverables; WBS shows work
Effort vs duration	Effort is labour amount; duration is elapsed time
Baseline vs forecast	Baseline is approved plan; forecast is expected outcome
Dependency vs assumption	Dependency is reliance; assumption is something treated as true
Contingency vs risk response	Contingency is provision/plan; response is chosen action
Programme vs portfolio	Programme coordinates related change; portfolio prioritises investments
Management vs leadership	Management controls work; leadership motivates and directs people
Handover vs closure	Handover transfers outputs; closure formally ends the project

Exam-style “what should happen next?” cues

Scenario	Better answer pattern
New project idea appears promising	Develop/confirm initial justification before full commitment
Requirements are unclear	Engage stakeholders and clarify scope/acceptance criteria
A major change is requested	Log request and assess impact before approval
Forecast completion exceeds approved tolerance	Escalate with impact and options
A future supplier delay is possible	Record as risk and plan response
The supplier has already missed delivery	Manage as issue and assess schedule impact
Product fails acceptance test	Record defect/non-conformance and take corrective action
Stakeholders complain they are not informed	Review communication needs and update communication plan
Team is overloaded in one period	Review resource plan, smooth/level resources, escalate if needed
Business case no longer appears valid	Escalate for governance decision
Project is complete but users are not ready	Manage handover/transition readiness before closure
Lessons are identified mid-project	Record and apply them where useful, not only at the end

Final revision checklist

Before sitting the Association for Project Management APM Project Fundamentals Qualification (PFQ), check that you can:

Define project, programme, portfolio, BAU, output, outcome and benefit.
Identify who owns the business case, who manages delivery, and who accepts outputs.
Explain the purpose of the business case, project management plan, risk register, issue log and change log.
Sequence lifecycle phases and explain gate reviews.
Distinguish risk, issue and change in short scenarios.
Choose suitable risk responses for threats and opportunities.
Read basic schedule terms: dependency, milestone, float, critical path and baseline.
Interpret simple cost/schedule performance indicators.
Distinguish quality planning, assurance and control.
Select appropriate stakeholder communication and escalation actions.
Recognise when to use formal change control instead of informal agreement.

Next step: practise with short PFQ-style scenario questions and force yourself to justify each answer using the role, artifact, lifecycle phase or control principle involved.

Scenario Guide

Project Management and the Operating Environment