PFQ — APM Project Fundamentals Qualification Quick Review

Last revised: July 1, 2026

Quick Review for Association for Project Management APM Project Fundamentals Qualification (PFQ) candidates: key concepts, traps, and practice focus.

Quick Review purpose

This Quick Review is for candidates preparing for the Association for Project Management APM Project Fundamentals Qualification (PFQ), exam code PFQ. It is PM Mastery review support: use it to refresh core project management concepts before moving into topic drills, mock exams, original practice questions, and detailed explanations.

The PFQ mindset is not “memorise every possible project document.” It is:

know the language of project management;
recognise who is responsible for what;
understand how projects are justified, planned, controlled, changed, and closed;
distinguish similar terms such as risk vs issue, quality assurance vs quality control, and output vs benefit;
choose the most disciplined next step in scenario-style questions.

For current exam rules, policies, and official information, always refer to the Association for Project Management.

High-yield PFQ mindset

Exam situation	Best PFQ instinct
A project is proposed	Ask why it is needed, what benefits it supports, and whether there is a business case.
Scope is unclear	Clarify requirements, deliverables, acceptance criteria, and boundaries before detailed delivery.
Work needs organising	Break scope into manageable components, define responsibilities, then schedule and resource the work.
A future uncertainty appears	Treat it as a risk or opportunity; assess probability and impact; assign an owner and response.
Something has already gone wrong	Treat it as an issue; record, assess impact, act, and escalate if needed.
A stakeholder asks for a change	Do not “just do it”; assess impact and follow change control.
Performance differs from plan	Compare actuals with the baseline, forecast impact, take corrective action, and report.
Deliverables are complete	Confirm acceptance, hand over, close formally, and capture lessons learned.

Core concepts to know cold

Project, programme, portfolio, and operations

Term	Fast definition	Common trap
Project	A temporary endeavour to create a defined output or change.	Treating routine operations as a project just because they are important.
Business-as-usual operations	Ongoing, repeatable activities that run the organisation.	Forgetting that projects often hand outputs into operations.
Programme	Coordinated management of related projects and change activities to deliver outcomes/benefits.	Thinking a programme is just a very large project.
Portfolio	Collection of projects and programmes managed to meet strategic objectives and balance investment.	Confusing portfolio prioritisation with day-to-day project control.
Output	The product, service, or capability delivered by the project.	Calling an output a benefit.
Outcome	The changed state or behaviour after the output is used.	Assuming outcomes automatically happen at handover.
Benefit	A measurable improvement valued by stakeholders or the organisation.	Making the project manager solely accountable for benefits that depend on business use.

Decision rule: projects deliver outputs and enable change; benefits are realised when the organisation uses those outputs effectively.

Project life cycle review

A life cycle structures the project from idea to closure and, where relevant, benefits realisation. Names and phase boundaries vary, but the logic is consistent.

Stage	Main question	Typical focus	Candidate trap
Concept	Should we do this?	Need, objectives, options, initial business case, key stakeholders.	Starting detailed planning before the reason for the project is clear.
Definition	How will we do this?	Scope, plans, governance, roles, risks, budget, schedule, quality approach.	Treating the plan as only a schedule.
Delivery/development	Are we producing the agreed outputs?	Work execution, monitoring, control, reporting, issue and change management.	Ignoring baselines and relying on informal progress updates.
Handover/transition	Can the outputs be accepted and used?	Acceptance, training, operational readiness, support arrangements.	Thinking delivery is complete before acceptance.
Closure	Have we closed the project properly?	Final checks, contract/admin closure, lessons learned, release resources.	Skipping closure because the team is busy with the next project.
Benefits realisation	Did the change create value?	Measuring benefits and outcomes, often in the business/operations environment.	Assuming benefits are guaranteed because outputs were delivered.

Lifecycle types

Lifecycle approach	Works well when	Watch for
Linear/predictive	Requirements are relatively stable and work can be planned sequentially.	Late discovery of changing stakeholder needs.
Iterative/incremental	Learning, feedback, and evolving detail are important.	Weak control if increments are not governed.
Hybrid	Some work is predictable while other parts benefit from iteration.	Confusion if governance, roles, and decision points are unclear.

PFQ questions often test the purpose of lifecycle control: it supports decision-making, governance, learning, and progressive commitment. It is not just an administrative diagram.

Roles and responsibilities

Role	Primary contribution	Do not confuse with
Project sponsor	Owns the business justification, champions the project, secures support, makes or supports key decisions.	The project manager’s day-to-day planning role.
Project manager	Plans, coordinates, monitors, controls, communicates, manages risks/issues/changes, leads delivery.	Owning the business case in isolation.
Project team	Performs the work and contributes technical expertise.	Governance approval authority.
Users/customers	Define needs, validate outputs, accept or use deliverables.	Passive recipients with no engagement role.
Steering group/project board	Provides governance, direction, decisions, and escalation route.	A substitute for regular project management.
PMO/project support	Supports standards, reporting, tools, assurance, information, and coordination.	Automatically being the final decision-maker.
Suppliers/contractors	Provide goods or services under agreed arrangements.	Internal project governance ownership.

RACI-style thinking

Letter	Meaning	PFQ use
R	Responsible	Does the work.
A	Accountable	Owns the result or decision; should be clear and usually singular for a task.
C	Consulted	Provides input before action.
I	Informed	Kept updated after decisions or progress.

Common trap: if a question asks who is accountable, do not choose the person who merely performs the task unless the scenario supports that accountability.

Business case and justification

The business case is the continuing reason for investing in the project. It normally connects the project to organisational objectives, costs, risks, expected benefits, and options.

Business case element	Why it matters
Strategic fit	Shows why the project supports organisational goals.
Options	Demonstrates that alternatives were considered.
Costs and resources	Helps judge affordability and value.
Benefits	Explains the improvement expected from the change.
Risks	Shows uncertainty and potential exposure.
Timescales	Helps assess urgency, feasibility, and benefit timing.
Ownership	Clarifies who maintains and approves the justification.

Decision rule: if the business case is no longer valid, the correct answer is rarely “continue because the plan says so.” Review, escalate, and make a governed decision.

Planning: from purpose to controlled work

Planning is more than drawing a Gantt chart. It creates a shared view of what will be delivered, how, by whom, when, at what cost, and under what controls.

Planning hierarchy

Planning area	Key question	Typical outputs
Objectives and success criteria	What are we trying to achieve?	Objectives, success measures, business case links.
Scope and requirements	What is included and excluded?	Scope statement, requirements, deliverables, acceptance criteria.
Product/work breakdown	How can the work be decomposed?	Product breakdown structure, work breakdown structure.
Schedule	In what sequence and when?	Network logic, milestones, Gantt chart, critical path view.
Resources	Who and what is needed?	Resource plan, responsibility assignments.
Cost	What will it cost and how will spending be controlled?	Estimates, budget, cost baseline.
Risk	What uncertainty could affect objectives?	Risk register, responses, owners.
Quality	How will fitness for purpose be defined and verified?	Quality plan, standards, review/testing approach.
Communications	Who needs what information and when?	Communication plan, reporting approach.
Change control	How will proposed changes be assessed and approved?	Change process, authority levels, change log.

Work breakdown and product breakdown

Technique	Focus	Watch for
Product breakdown structure	Breaks down the products/deliverables.	It is product-oriented, not a timeline.
Work breakdown structure	Breaks work into manageable work packages.	It should cover the agreed scope, not extra “nice-to-have” work.
Organisation breakdown structure	Shows organisational structure or reporting relationships.	It is not the same as a schedule.
Cost breakdown structure	Organises costs for estimating and control.	It does not define quality acceptance by itself.

Trap: a WBS is not simply a task list in chronological order. It is a structured decomposition that helps estimate, assign, schedule, and control work.

Scheduling essentials

Concept	Meaning	Exam trap
Activity	A unit of work that consumes time/resources.	Confusing activities with deliverables.
Milestone	A significant point or event, often zero duration.	Treating a milestone as work effort.
Dependency	Logical relationship between activities.	Ignoring dependencies when compressing a schedule.
Critical path	Longest path through the network that determines the earliest completion date.	Assuming “critical” means highest cost or highest risk.
Float/slack	Time an activity can be delayed without delaying a defined date.	Thinking all non-critical tasks are unimportant.
Gantt chart	Bar chart showing activities over time.	Assuming it always explains dependency logic clearly.
Network diagram	Shows activity sequence and dependencies.	Forgetting that network logic supports critical path analysis.

Schedule compression logic

Option	What it means	Risk
Fast-tracking	Doing activities in parallel that were originally sequential.	Rework if dependencies are not respected.
Crashing	Adding resources to shorten duration.	Higher cost or reduced efficiency.
De-scoping	Removing or deferring scope through approved change.	May reduce benefits or stakeholder satisfaction.

Decision rule: do not compress a schedule casually. Assess impacts on cost, quality, risk, scope, and stakeholder expectations.

Cost and resource control

Concept	Review point
Estimate	An informed forecast of cost, duration, or resource need. Accuracy should improve as detail increases.
Budget	Approved financial allocation for the project or part of it.
Baseline	Approved reference point used to measure performance.
Actual cost	What has been spent.
Forecast	Current prediction of future cost or completion position.
Contingency	Allowance for known uncertainty or risk exposure, managed under agreed rules.
Resource levelling	Adjusting schedule/resource use to address over-allocation or constraints.

Common mistake: treating the original budget as automatically correct after major change. Approved changes may require revised baselines.

Risk, opportunity, issue, and change

Fast distinctions

Term	Timing	Meaning	Typical record
Risk	Future uncertainty	Threat that may affect objectives if it occurs.	Risk register.
Opportunity	Future uncertainty	Positive uncertainty that may improve objectives if it occurs.	Risk/opportunity register.
Issue	Current fact/problem	Something that has happened or needs resolution now.	Issue log.
Change request	Proposed alteration	Request to change an approved baseline, scope, product, plan, or requirement.	Change log/request form.

Risk management flow

Identify uncertainty.
Assess probability and impact.
Plan responses and assign owners.
Implement responses.
Monitor and review risk status.
Communicate and escalate as needed.

Risk response examples

Threat response	Meaning
Avoid	Change approach so the threat no longer applies.
Reduce/mitigate	Lower probability or impact.
Transfer/share	Move or share exposure, often contractually or through insurance-like arrangements.
Accept	Take no proactive action beyond monitoring or contingency planning.

Opportunity response	Meaning
Exploit	Act to make the opportunity happen.
Enhance	Increase probability or impact.
Share	Work with others to improve the opportunity.
Accept	Take advantage if it occurs, without major proactive investment.

Event handling decision path

    flowchart TD
	    A[New information appears] --> B{Has it already happened?}
	    B -- No --> C[Record as risk or opportunity]
	    C --> D[Assess probability and impact]
	    D --> E[Assign owner and response]
	    E --> F[Monitor and communicate]
	    B -- Yes --> G{Does it require a baseline change?}
	    G -- No --> H[Manage as issue or action]
	    H --> I[Record, resolve, and report]
	    G -- Yes --> J[Raise change request]
	    J --> K[Assess impact on scope, time, cost, quality, risk, and benefits]
	    K --> L[Decision by agreed authority]
	    L --> M[Update plans and communicate if approved]

PFQ trap: once a risk occurs, it is no longer merely a risk; it becomes an issue or event requiring action.

Change control

Change control protects the project from uncontrolled scope, cost, time, risk, quality, and benefits impacts. It does not mean “never change”; it means change deliberately.

Step	Purpose
Raise request	Capture what is being proposed and why.
Log request	Create visibility and traceability.
Impact assessment	Understand effects on scope, time, cost, quality, risk, resources, and business case.
Decision	Approve, reject, defer, or request more information through agreed authority.
Implement	Update baselines, plans, documents, and communications.
Review	Confirm the change was applied and controlled.

Common mistake: choosing an answer that implements a stakeholder’s requested change immediately. The better answer is usually to assess and follow the agreed change process.

Quality management

Quality is about fitness for purpose and meeting agreed requirements, not simply “gold-plating” the deliverable.

Concept	Meaning	Trap
Quality planning	Defines standards, criteria, responsibilities, and methods.	Waiting until the end to decide what “good” means.
Quality assurance	Provides confidence that appropriate processes are being used.	Confusing process assurance with product inspection.
Quality control	Checks outputs against requirements and acceptance criteria.	Assuming inspection alone creates quality.
Acceptance criteria	Conditions deliverables must meet to be accepted.	Using vague stakeholder preference instead of agreed criteria.
Continuous improvement	Learning and improving methods over time.	Treating lessons learned as a closure-only formality.

Decision rule: build quality in through planning and process, then verify through control activities.

Stakeholder and communication review

Stakeholders are individuals or groups who can affect, be affected by, or perceive themselves to be affected by the project.

Stakeholder engagement steps

Step	Key question
Identify	Who matters to the project and why?
Analyse	What are their interests, influence, needs, and likely attitude?
Plan engagement	What information and involvement do they need?
Communicate	How, when, and through which channels?
Monitor	Is engagement working, and have stakeholder positions changed?

Communication planning

Factor	Review point
Audience	Different stakeholders need different detail.
Purpose	Inform, consult, decide, escalate, or gain commitment.
Timing	Communication must be timely enough to influence action.
Channel	Match channel to importance, complexity, urgency, and sensitivity.
Feedback	Communication is not complete just because a message was sent.
Records	Important decisions and approvals should be documented.

PFQ trap: “communicate more” is not always the answer. Communicate the right information to the right people at the right time using an appropriate method.

Governance, assurance, and control

Governance provides the framework for decision-making, accountability, escalation, and alignment with organisational objectives. Assurance gives confidence that the project is being managed appropriately.

Concept	Purpose
Governance	Defines authority, accountability, reporting, escalation, and decision routes.
Tolerances	Define limits within which the project manager can manage without escalation.
Escalation	Raises matters that exceed authority or tolerance.
Assurance	Independent or structured confidence that processes and controls are effective.
Reporting	Provides timely information for decisions and stakeholder confidence.
Audit/review	Checks compliance, performance, or readiness at specific points.

Project control cycle

Step	Question
Set baseline	What are we measuring against?
Collect actuals	What is happening now?
Compare	How does actual performance differ from plan?
Analyse	Why is there a variance and what is the likely impact?
Forecast	What will happen if no action is taken?
Act	What corrective or preventive action is needed?
Report/escalate	Who needs to know or decide?

Common mistake: reporting variance without explaining impact or proposing action.

Leadership and teamwork

PFQ candidates should recognise basic leadership and team concepts in project situations.

Area	Review point
Leadership	Provides direction, motivation, decision support, and a productive environment.
Management	Plans, organises, monitors, and controls work.
Team development	Teams may need time and support to become effective.
Motivation	People are influenced by purpose, recognition, autonomy, competence, fairness, and working conditions.
Conflict	Can be constructive if managed openly and focused on project objectives.
Delegation	Assigns responsibility with clarity on authority, expectations, and reporting.

Team-stage thinking

Stage	Typical behaviour	Project manager focus
Forming	Unclear roles, polite uncertainty.	Clarify objectives, roles, and ways of working.
Storming	Conflict, challenge, disagreement.	Facilitate, resolve issues, reinforce purpose.
Norming	Better cooperation and shared norms.	Support collaboration and accountability.
Performing	Productive, self-managing team behaviour.	Remove obstacles and maintain alignment.
Adjourning	Team disbands or transitions.	Close, recognise contribution, capture lessons.

Trap: conflict is not automatically bad. Poorly managed conflict is harmful; constructive disagreement can improve decisions.

Procurement and supplier awareness

Even at fundamentals level, recognise that supplier work must be planned, specified, managed, and accepted.

Concept	Review point
Make-or-buy decision	Determines whether work is done internally or sourced externally.
Specification	Defines what is required from a supplier.
Contract	Establishes obligations, deliverables, cost/payment basis, and terms.
Supplier management	Monitors performance, communication, issues, and changes.
Acceptance	Confirms supplied outputs meet agreed requirements.

Common mistake: assuming outsourced work no longer needs project management. Supplier deliverables still affect the project’s schedule, cost, quality, risk, and stakeholders.

Documentation and information management

Project documents are useful because they support decisions, alignment, control, and learning.

Document/record	Main purpose
Business case	Justifies the project and supports continue/stop decisions.
Project management plan	Integrates how the project will be managed and controlled.
Scope statement	Defines included and excluded work/deliverables.
Risk register	Records risks, assessment, responses, owners, and status.
Issue log	Tracks current problems and actions.
Change log	Tracks requested, approved, rejected, and implemented changes.
Stakeholder register	Records stakeholder information and engagement needs.
Communication plan	Defines communication audiences, messages, timing, and channels.
Quality plan	Defines quality standards, checks, and responsibilities.
Lessons learned log	Captures learning during and at the end of the project.
Closure report	Summarises final status, acceptance, performance, and lessons.

Decision rule: if a project fact affects decisions or accountability, it should usually be documented and controlled.

Common PFQ confusion pairs

Confusion pair	How to separate them quickly
Risk vs issue	Risk is uncertain and future; issue is current or has occurred.
Output vs outcome	Output is delivered; outcome is the changed state after use.
Outcome vs benefit	Outcome is change; benefit is measurable value from that change.
Quality assurance vs quality control	Assurance checks the process; control checks the product/output.
Sponsor vs project manager	Sponsor owns business justification and senior support; project manager manages delivery.
Stakeholder vs customer/user	Customers/users are stakeholders, but not all stakeholders are customers/users.
Milestone vs activity	Milestone is a point/event; activity is work over time.
Baseline vs forecast	Baseline is the approved reference; forecast is the current prediction.
Tolerance vs contingency	Tolerance is an allowed variance threshold; contingency is provision for uncertainty.
Change control vs configuration management	Change control decides and authorises changes; configuration management protects product/document versions and status.
Acceptance criteria vs success criteria	Acceptance criteria apply to deliverables; success criteria judge overall project success.
Programme vs project	Programme coordinates related change to deliver broader outcomes/benefits; project delivers defined outputs.

Scenario-answering rules

Use these rules when a question feels ambiguous:

Do not skip governance. If a decision exceeds authority or tolerance, escalate through the agreed route.
Do not implement unapproved change. Assess impact first.
Do not treat documentation as bureaucracy. The right record often enables control and accountability.
Do not confuse the loudest stakeholder with the most authorised stakeholder.
Do not close before acceptance, handover, and closure actions are complete.
Do not manage risks only once. Risks are monitored throughout the project.
Do not assume benefits are delivered automatically. Outputs must be used to create outcomes and benefits.
Do not choose a technical fix before understanding the project impact.
Do not treat the project plan as static. It is controlled, updated, and baselined through proper process.
Do not ignore lessons learned until the end. Learning can be captured and applied during the project.

Quick self-test prompts

Use these prompts before starting a topic drill:

Can I explain the difference between a project, programme, portfolio, and operations?
Can I identify the sponsor’s responsibilities versus the project manager’s?
Can I describe why a business case is reviewed throughout the project?
Can I list the normal steps for handling a change request?
Can I distinguish risk, opportunity, issue, and change?
Can I explain quality planning, assurance, and control without mixing them up?
Can I read a simple schedule and identify dependencies, milestones, float, and the critical path concept?
Can I explain why stakeholder communication must be planned, targeted, and two-way?
Can I describe what happens at handover and closure?
Can I choose the most governed next step in a scenario?

How to use question-bank practice effectively

Independent companion practice is most valuable when you review why an answer is right, not just whether you selected it.

Practice mode	Goal	What to review in detailed explanations
Topic drills	Fix one weak area at a time.	Definitions, role boundaries, process sequence, and traps.
Mixed sets	Build recognition across topics.	Why similar options are wrong.
Mock exams	Practise timing, endurance, and exam-style judgement.	Patterns in mistakes, not isolated misses.
Missed-question review	Turn errors into rules.	Was it a vocabulary error, role error, sequence error, or overthinking?
Re-drills	Confirm the weakness is fixed.	Whether you can answer similar original practice questions without memorising.

Error log categories

When you miss a PFQ practice question, tag it:

Error type	Example	Fix
Term confusion	Picked issue when it was a risk.	Build a confusion-pair flashcard.
Role confusion	Chose project manager for sponsor accountability.	Review responsibility table.
Process order	Implemented change before assessment.	Memorise the control flow.
Scenario overreaction	Escalated before checking tolerance.	Ask: who has authority at this level?
Too technical	Chose a delivery action when governance was needed.	Re-read the question for “next best step.”
Weak lifecycle logic	Closed project before acceptance.	Review handover and closure steps.

Final rapid review checklist

Before your next PFQ practice session, confirm you can:

define project, programme, portfolio, operations, output, outcome, and benefit;
explain the purpose of the business case;
match key responsibilities to sponsor, project manager, team, users, governance, PMO, and suppliers;
outline a typical project life cycle and the purpose of each stage;
distinguish WBS, schedule, milestone, dependency, float, and critical path;
apply the basic control cycle: baseline, actuals, variance, forecast, action, report;
handle risks, issues, opportunities, and changes using the correct records and processes;
separate quality planning, assurance, control, and acceptance;
plan stakeholder engagement and communication based on need, influence, and timing;
recognise when to escalate and when to manage within authority.

Practical next step

Start with a focused PFQ topic drill on your weakest area, then review the detailed explanations for every missed or guessed item. After that, move into mixed original practice questions and a timed mock exam to test whether you can apply the concepts under exam conditions.

Continue in PM Mastery

Use this Quick Review as a final concept map, then move into PM Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original PM Mastery practice items; they are not official APM questions, copied live-exam content, or exam dumps.

Study Plan