PFQ — APM Project Fundamentals Qualification Exam Blueprint
Practical PFQ exam blueprint for the Association for Project Management APM Project Fundamentals Qualification.
How to Use This PFQ Exam Blueprint
Use this checklist as an independent study map for the Association for Project Management APM Project Fundamentals Qualification (PFQ), exam code PFQ. It is designed for final review and gap-finding, not as a replacement for the official syllabus or training materials.
For each topic area, ask:
- Can I explain the term in plain project-management language?
- Can I identify the right artifact, role, or process in a short scenario?
- Can I distinguish similar concepts, such as risk vs issue, quality assurance vs quality control, or project vs programme?
- Can I choose the most appropriate next action when a project situation changes?
- Can I apply simple schedule, cost, risk, or governance logic without overcomplicating the question?
Because official weights can change, the table below avoids implied percentages. Treat each area as part of your readiness coverage.
PFQ Topic-Area Readiness Map
| Readiness area | What to be ready to explain | What to be ready to do in a scenario | Common weak spot |
|---|---|---|---|
| Project context and definitions | Project, programme, portfolio, operations, project environment, constraints | Decide whether work should be managed as a project or business-as-usual activity | Treating any task list as a project |
| Project life cycle | Stages/phases, handovers, reviews, approval points, closure | Identify what should happen at concept, definition, delivery, handover, and closure | Confusing stage-end review with final closure |
| Governance and sponsorship | Governance, accountability, sponsor role, approvals, escalation | Choose when a project manager should escalate to the sponsor or board | Assuming the project manager approves every major change |
| Business case and benefits | Justification, value, expected benefits, costs, risks, options | Recognize when the business case should be reviewed or updated | Thinking the business case is only created at the start |
| Project success and objectives | Success criteria, objectives, benefits, acceptance, constraints | Distinguish successful delivery from successful benefits realization | Equating “on time” with total project success |
| Stakeholder management | Stakeholder identification, analysis, engagement, communication needs | Select suitable engagement actions for high-interest or high-influence stakeholders | Sending the same communication to everyone |
| Communication | Communication plan, reporting, channels, feedback, barriers | Choose the right communication method for urgency, sensitivity, and audience | Treating communication as only status reporting |
| Roles and responsibilities | Sponsor, project manager, team, users, suppliers, governance bodies, PMO | Match responsibilities to the correct role | Assigning sponsorship duties to the project manager |
| Teamwork and leadership | Team development, motivation, leadership, conflict, collaboration | Identify appropriate responses to team conflict or poor performance | Jumping straight to escalation before clarifying causes |
| Scope and requirements | Scope, requirements, deliverables, exclusions, acceptance criteria | Detect scope creep and identify change-control needs | Confusing requirements with solution design |
| Work breakdown and planning | Product breakdown, work breakdown, milestones, dependencies, planning assumptions | Break high-level deliverables into manageable work or identify missing planning detail | Planning activities before deliverables are clear |
| Scheduling | Network logic, dependencies, milestones, critical path, float, Gantt charts | Interpret simple schedule changes and identify impact on completion | Assuming all delayed tasks delay the project |
| Resource management | Resource types, availability, allocation, leveling, responsibility assignment | Identify resource conflicts and practical planning responses | Ignoring capacity limits when building a schedule |
| Estimating and budgeting | Estimating approaches, cost categories, contingency, budget baseline | Recognize unrealistic estimates or missing cost elements | Treating estimates as fixed commitments too early |
| Risk management | Risk identification, assessment, response planning, ownership, contingency | Distinguish risk from issue and select avoid, reduce, transfer, or accept responses | Writing vague risks with no cause or effect |
| Issue management | Issue logging, ownership, impact, escalation, resolution | Choose what to do when a risk has occurred or a problem blocks delivery | Leaving issues unmanaged because they were not in the plan |
| Change control | Change requests, impact assessment, approval, baseline updates | Decide what artifact to update and who should approve a change | Accepting informal scope changes |
| Quality management | Quality planning, assurance, control, acceptance, defects | Distinguish prevention activities from inspection activities | Confusing quality with “gold-plating” |
| Procurement and suppliers | Make-or-buy, contracts, supplier selection, supplier management | Identify supplier-related risks, responsibilities, and control points | Forgetting that supplier work still needs project oversight |
| Information and configuration management | Version control, document control, configuration items, records | Identify why baselines and controlled documents matter | Using outdated plans or uncontrolled versions |
| Progress monitoring and reporting | Baselines, actuals, forecasts, status reports, exception reporting | Interpret variance and decide when corrective action or escalation is needed | Reporting activity completed instead of progress toward outcomes |
| Handover and closure | Acceptance, transition, lessons learned, final report, release of resources | Identify closure activities that must happen before the project is formally closed | Ending the project when delivery finishes but before acceptance |
| Delivery approaches | Predictive, iterative, agile, hybrid, tailoring | Choose which approach characteristics suit uncertain requirements or stable scope | Treating one delivery approach as always best |
Core Concepts You Should Be Able to Distinguish
| Concept pair | Ready means you can say… | Scenario cue |
|---|---|---|
| Project vs operations | A project is temporary and delivers change; operations are ongoing and repeatable | “Ongoing monthly reporting” is likely operations; “implement a new reporting system” may be a project |
| Project vs programme | A programme coordinates related projects and change to achieve broader outcomes | Multiple connected projects delivering a strategic capability suggest programme context |
| Programme vs portfolio | A portfolio groups work for strategic prioritization and investment control | The question mentions selection, balancing, and prioritizing investments |
| Output vs outcome vs benefit | Output is delivered product/service; outcome is changed capability or behavior; benefit is measurable value | New software is an output; faster processing is an outcome; reduced cost may be a benefit |
| Objective vs requirement | Objective states what the project aims to achieve; requirement states a need the solution must satisfy | “Reduce processing time” vs “system must support online approvals” |
| Risk vs issue | Risk is uncertain; issue has happened or is happening | “May happen” is risk; “has occurred” is issue |
| Assumption vs constraint | Assumption is treated as true for planning; constraint limits choices | “Supplier will be available” vs “must finish before regulatory deadline” |
| Quality assurance vs quality control | Assurance checks processes; control checks outputs | Audit the testing process vs inspect a deliverable |
| Contingency vs management reserve | Contingency addresses identified uncertainty; broader reserves may address unknowns depending on governance | Use cautious wording and follow the scenario’s approval rules |
| Change request vs defect | Change request alters agreed scope/baseline; defect is failure to meet agreed requirement | “Add a new feature” vs “feature does not meet acceptance criteria” |
| Stakeholder interest vs influence | Interest is concern or attention; influence is ability to affect the project | High influence/low interest often needs targeted, efficient engagement |
| Baseline vs forecast | Baseline is approved plan; forecast is current expectation | A slip against baseline needs analysis and possible action |
Project Life Cycle Readiness
Be ready to place activities in the right part of the project life cycle. PFQ-level questions often test whether you know what should happen before, during, or after delivery.
| Life-cycle point | Purpose | Typical artifacts or decisions | Readiness check |
|---|---|---|---|
| Concept / initiation | Confirm need, outline justification, identify options | Initial business case, high-level scope, sponsor support | Can you identify why the project exists? |
| Definition / planning | Define what will be delivered and how it will be controlled | Project management plan, scope, schedule, budget, risk approach, governance | Can you spot missing planning assumptions or controls? |
| Development / delivery | Build, test, control, and report progress | Work packages, issue log, risk register updates, change requests, progress reports | Can you decide what to monitor and when to escalate? |
| Handover / transition | Transfer outputs into use and gain acceptance | Acceptance records, training, operational readiness, support arrangements | Can you tell whether the deliverable is ready for use? |
| Closure | Confirm completion, release resources, learn lessons | Closure report, lessons learned, final accounts, archived records | Can you distinguish closure from delivery completion? |
| Benefits realization | Confirm whether expected value is achieved | Benefits review, performance measures, ownership after handover | Can you separate project closure from benefits tracking? |
Governance, Roles, and Accountability Checklist
Can you identify the right role?
| Role or group | Typical responsibility | What the exam may test |
|---|---|---|
| Sponsor | Owns business justification, champions the project, provides direction, secures support | Who approves major decisions or resolves business-level conflict? |
| Project manager | Plans, coordinates, monitors, controls, reports, manages day-to-day delivery | Who updates plans, manages issues, and coordinates the team? |
| Project team | Produces deliverables and provides technical or specialist input | Who completes assigned work packages? |
| Users / customers | Define needs, review outputs, accept deliverables where appropriate | Who confirms whether the solution meets practical needs? |
| Suppliers | Provide goods or services under agreed arrangements | Who is responsible for supplier deliverables and performance management? |
| Governance board / steering group | Provides oversight, decision-making, and escalation route | Who considers exceptions, major risks, or changes beyond delegated authority? |
| PMO / support office | Provides standards, reporting support, methods, tools, or assurance | Who supports consistency and information management? |
Governance readiness checklist
- I can explain why governance is needed on a project.
- I can identify who should approve major scope, cost, schedule, or risk changes.
- I can tell when a project manager should act within authority and when to escalate.
- I can distinguish project assurance from routine project control.
- I can explain why stage gates, reviews, or approval points reduce uncontrolled commitment.
- I can identify the purpose of delegated authority.
- I can explain why governance should be proportionate to project size, risk, and complexity.
Business Case, Value, and Benefits
The business case is a recurring PFQ concept because it links project work to organizational value.
| Topic | Ready means you can… | Watch for |
|---|---|---|
| Business need | Explain the problem, opportunity, or driver behind the project | Starting with a solution before understanding the need |
| Options | Compare possible ways to meet the need | Assuming the first option is automatically best |
| Costs and benefits | Recognize financial and non-financial factors | Ignoring intangible benefits or ongoing costs |
| Risks | Explain why risks affect business justification | Treating risk management as separate from value |
| Continued justification | Know that the business case may need review when circumstances change | Thinking approval at the start is permanent |
| Benefits ownership | Identify that benefits may be realized after project closure | Assuming the project manager always owns long-term benefits |
Can you do this?
- Explain why a project should not continue if its justification is no longer valid.
- Identify a benefit, an output, and an outcome in a short scenario.
- Decide when a business case should be updated.
- Recognize when a requested change improves value and when it only adds scope.
- Explain why benefits need measures, owners, and timing.
Stakeholder and Communication Readiness
Stakeholder analysis checklist
- Identify stakeholders affected by the project or able to influence it.
- Consider internal, external, senior, operational, supplier, customer, and user groups.
- Assess interest, influence, attitude, expectations, and information needs.
- Plan engagement actions, not just one-way communications.
- Reassess stakeholders when scope, risk, or organizational context changes.
- Recognize that stakeholder conflict may require negotiation, prioritization, or escalation.
| If the scenario says… | Best first thought |
|---|---|
| A senior stakeholder is surprised by a decision | Check engagement and communication planning |
| Users resist the new process | Understand concerns, involve users, clarify benefits and impacts |
| Two stakeholder groups want conflicting features | Clarify priorities, constraints, and decision authority |
| A stakeholder has high influence but low interest | Keep communication concise, relevant, and timely |
| A stakeholder has high interest but low influence | Provide appropriate updates and channels for feedback |
| Misinformation is spreading | Use planned communication routes and confirm the message has been understood |
Communication readiness checklist
- I can choose between meeting, report, workshop, email, dashboard, or informal conversation based on purpose.
- I can explain why communication requires feedback, not just transmission.
- I can match communication frequency and detail to stakeholder needs.
- I can identify barriers such as jargon, culture, distance, assumptions, and information overload.
- I can distinguish routine reporting from urgent escalation.
- I can explain why sensitive issues may need direct or formal communication.
Scope, Requirements, and Work Breakdown
| Area | What to review | Scenario skill |
|---|---|---|
| Scope definition | Inclusions, exclusions, deliverables, boundaries | Spot unclear or expanding scope |
| Requirements | Business, user, technical, regulatory, operational needs | Identify missing or conflicting requirements |
| Acceptance criteria | Conditions for accepting deliverables | Decide whether output is complete |
| Product breakdown | Decomposition of products/deliverables | Focus planning on what must be produced |
| Work breakdown | Decomposition of work needed to create deliverables | Link tasks to deliverables and responsibility |
| Scope baseline | Approved scope used for control | Recognize when change control is needed |
Scope-control prompts
Ask these questions when a scenario introduces a new request:
- Is the request already within agreed scope?
- Does it change deliverables, quality criteria, schedule, cost, risk, or benefits?
- Who has authority to approve it?
- What impact analysis is needed?
- Which baseline or plan must be updated if approved?
- How will the decision be communicated?
Common traps
- Assuming a useful idea should be added immediately.
- Treating unclear requirements as a delivery problem rather than a definition problem.
- Ignoring exclusions in the scope statement.
- Forgetting that quality criteria and acceptance criteria are part of scope control.
- Confusing stakeholder preference with approved requirement.
Planning, Scheduling, and Estimating
Planning artifacts to recognize
| Artifact | Purpose | Readiness cue |
|---|---|---|
| Project management plan | Integrates how the project will be managed and controlled | The question asks how work, risk, quality, communication, and change will be coordinated |
| Milestone plan | Shows key decision or delivery points | The question focuses on major events, not detailed tasks |
| Network diagram | Shows logical dependencies between activities | The question asks which tasks affect timing |
| Gantt chart | Shows activities over time | The question asks about dates, overlaps, or visual schedule tracking |
| Resource plan | Shows people, equipment, or materials needed | The question mentions shortages, conflicts, or availability |
| Budget / cost plan | Shows expected costs and funding needs | The question asks whether the project remains within approved cost |
| Risk management plan | Defines how risks will be identified, assessed, and controlled | The question asks how risk work should be carried out |
| Communication plan | Defines stakeholder information needs | The question asks who needs what information and when |
Scheduling concepts checklist
- I can identify predecessor and successor activities.
- I can interpret finish-to-start logic when one activity must finish before another begins.
- I can recognize parallel activities and dependencies.
- I can identify a milestone as a significant point, not a duration-based task.
- I can explain the critical path as the sequence affecting the earliest project completion.
- I can explain float as scheduling flexibility.
- I can identify when a delay does or does not affect the project end date.
- I can tell the difference between schedule compression by adding resources and by overlapping work, without assuming either is always appropriate.
- I can recognize that changes to scope, resources, or risk may require schedule re-planning.
Estimating readiness
| Estimating topic | What to know | Exam-style cue |
|---|---|---|
| Analogous estimating | Uses comparison with similar previous work | Early estimate based on past project |
| Parametric estimating | Uses rates or unit costs | Cost per unit, time per item, effort per square metre |
| Bottom-up estimating | Estimates detailed components and aggregates them | More detail available after breakdown |
| Expert judgment | Uses specialist knowledge | Uncertain work needing experienced input |
| Contingency | Allowance for identified uncertainty | Risk-informed planning |
| Estimate uncertainty | Estimates become more reliable with better information | Early plans should not be treated as exact |
Calculation and Interpretation Checks
PFQ preparation should include comfort with simple project data. Do not memorize formulas without understanding the project meaning.
Useful formulas and relationships
Risk exposure is often expressed as:
\[ \text{Risk Exposure} = \text{Probability} \times \text{Impact} \]A simple variance can be interpreted as:
\[ \text{Variance} = \text{Actual or Forecast} - \text{Baseline} \]Float can be understood as available scheduling flexibility before a delay affects a dependent milestone or finish date.
Practical interpretation checklist
| Data shown | Can you interpret? | Watch for |
|---|---|---|
| Baseline vs actual cost | Whether spending is above or below plan | Direction of variance may depend on wording |
| Baseline vs forecast completion | Whether the project is expected to finish late or early | Forecast is not the same as actual |
| Activity durations and dependencies | Which path controls completion | Not every delayed task is critical |
| Risk probability and impact | Which risks need priority attention | A low-probability risk can still matter if impact is severe |
| Resource availability | Whether the plan is feasible | People cannot be scheduled beyond realistic capacity |
| Change impact | Effects on scope, time, cost, quality, risk, and benefits | Do not assess only one constraint |
Risk and Issue Management
Risk process readiness
| Step | What it means | Candidate readiness |
|---|---|---|
| Identify | Find uncertain events that could affect objectives | Can write or recognize clear risk statements |
| Assess | Estimate probability and impact | Can prioritize without false precision |
| Plan responses | Decide what to do before the risk occurs | Can choose avoid, reduce, transfer, or accept where appropriate |
| Assign owner | Give responsibility for monitoring and response | Can identify why unowned risks are weak control |
| Monitor | Track triggers, changes, and response effectiveness | Can update the risk register as the project changes |
| Escalate | Raise risks beyond authority or tolerance | Can identify when governance input is needed |
Risk response decision table
| Response | Meaning | Scenario cue |
|---|---|---|
| Avoid | Change the plan so the threat cannot occur or no longer affects the project | Remove a risky approach or requirement |
| Reduce / mitigate | Lower probability or impact | Add testing, training, backup supplier, extra review |
| Transfer | Shift some impact to another party | Insurance, contract terms, specialist supplier |
| Accept | Take no immediate action beyond monitoring or contingency | Low-level risk or response cost exceeds value |
| Exploit / enhance / share | For opportunities, increase likelihood or impact where beneficial | Positive uncertainty with potential value |
Issue management checklist
- I can explain that an issue is current, not merely possible.
- I can record issues with owner, impact, priority, action, and target date.
- I can identify when an issue should trigger a change request.
- I can distinguish fixing a defect from approving a scope change.
- I can decide when an issue must be escalated.
- I can connect issue resolution to schedule, cost, quality, risk, and stakeholder impact.
Change Control and Configuration Management
Change control is a frequent source of exam traps because candidates often choose the fastest action rather than the controlled action.
Change-control sequence
| Step | Purpose | What to avoid |
|---|---|---|
| Record the request | Ensure the request is visible and traceable | Accepting informal change verbally |
| Clarify the change | Understand what is being requested | Assessing a vague request |
| Assess impact | Evaluate scope, schedule, cost, quality, risk, benefits, resources, and stakeholders | Looking only at time impact |
| Recommend / decide | Use agreed authority and governance | Letting the wrong person approve |
| Update baselines and plans | Keep project information consistent | Delivering from outdated documents |
| Communicate decision | Ensure affected parties understand the outcome | Leaving stakeholders with different expectations |
| Implement and monitor | Deliver approved change and track results | Treating approval as completion |
Configuration and information checks
- I can explain why controlled versions of plans and deliverables matter.
- I can identify when a document or deliverable becomes a baseline.
- I can explain why configuration management supports change control.
- I can spot problems caused by using outdated requirements or drawings.
- I can distinguish document storage from active control of versions and approvals.
Quality Management Readiness
| Quality concept | Meaning | Exam cue |
|---|---|---|
| Quality planning | Define standards, criteria, responsibilities, and methods | “How will the project ensure outputs meet requirements?” |
| Quality assurance | Provide confidence that processes are suitable and followed | Reviews, audits, process checks |
| Quality control | Inspect or test deliverables against criteria | Testing, inspection, defect detection |
| Acceptance | Formal confirmation that deliverables meet agreed criteria | User sign-off, acceptance record |
| Continuous improvement | Learn and improve practices | Lessons learned, process improvements |
| Cost of poor quality | Rework, delay, defects, dissatisfaction | Scenario mentions repeated fixes or failures |
Can you do this?
- Distinguish “building the right thing” from “building the thing right.”
- Identify whether a scenario requires prevention, inspection, or corrective action.
- Explain why quality criteria must be defined before acceptance.
- Recognize gold-plating as adding unapproved features or quality beyond requirements.
- Explain why defects may affect schedule, cost, risk, and stakeholder confidence.
People, Teamwork, and Leadership
PFQ-level people questions often test practical judgment: communicate, clarify, involve, motivate, resolve, or escalate.
| Topic | What to review | Scenario skill |
|---|---|---|
| Team roles | Different contributions needed in a project team | Avoid assuming technical skill is the only factor |
| Leadership | Direction, support, decision-making, motivation | Choose an approach suited to the situation |
| Team development | Teams may form, experience conflict, normalize, and perform | Recognize that conflict can be part of development but still needs management |
| Motivation | People respond to purpose, recognition, autonomy, growth, and fair treatment | Identify why poor motivation affects performance |
| Conflict | Sources include priorities, resources, personality, role ambiguity, and change | Choose clarification or negotiation before unnecessary escalation |
| Delegation | Assign work with authority, clarity, and accountability | Avoid delegating responsibility without support |
| Virtual or distributed teams | Communication, trust, coordination, and documentation challenges | Select deliberate communication and clear expectations |
Team scenario cues
| If the question says… | Consider first |
|---|---|
| Team member is unclear about responsibilities | Clarify roles, work package, or responsibility assignment |
| Conflict arises over priorities | Check objectives, constraints, and decision authority |
| Team morale is low | Understand causes, communicate purpose, support the team |
| Specialist is overloaded | Review resource plan, priorities, dependencies, and alternatives |
| Supplier and internal team disagree | Check contract, requirements, acceptance criteria, and communication route |
| A team member bypasses change control | Reinforce process and assess impact |
Procurement and Supplier Management
| Area | Ready means you can… | Watch for |
|---|---|---|
| Make-or-buy decision | Explain why work may be done internally or externally | Choosing a supplier does not remove project accountability |
| Supplier selection | Recognize criteria such as capability, cost, quality, risk, and fit | Lowest price is not always best value |
| Contract awareness | Understand that terms define obligations and controls | Do not assume informal changes are acceptable |
| Supplier risk | Identify dependency, availability, quality, and delivery risks | Supplier delay may affect critical path |
| Acceptance of supplier outputs | Link supplier deliverables to requirements and quality criteria | Payment or delivery is not the same as acceptance |
| Relationship management | Maintain communication and performance monitoring | Ignoring early warning signs |
Progress Monitoring, Reporting, and Control
Monitoring checklist
- Compare actual progress with the approved baseline.
- Track forecast completion, not only work already done.
- Monitor cost, schedule, scope, quality, risk, issues, resources, and stakeholder sentiment.
- Use exception reporting when tolerance or authority limits are exceeded.
- Update plans and records after approved decisions.
- Keep status reports factual, concise, and relevant to the audience.
- Recommend corrective action when performance deviates from plan.
| Control question | What a ready candidate considers |
|---|---|
| Is the project late? | Which activities are late, whether they are critical, and what forecast impact exists |
| Is the project overspending? | Baseline, actual cost, forecast cost, causes, and corrective options |
| Is quality acceptable? | Criteria, test results, defects, acceptance status |
| Are risks increasing? | Probability, impact, triggers, response effectiveness, escalation thresholds |
| Are stakeholders aligned? | Engagement, communication, unresolved concerns, decision authority |
| Is the plan still valid? | Approved changes, assumptions, constraints, and current forecasts |
Handover, Closure, and Lessons Learned
| Closure area | What to review | Common mistake |
|---|---|---|
| Acceptance | Confirm deliverables meet agreed criteria | Assuming delivery equals acceptance |
| Handover | Transfer outputs to users or operations | Forgetting training, support, documentation, or ownership |
| Final reporting | Summarize performance, outstanding items, and approvals | Reporting only schedule completion |
| Financial closure | Confirm costs, invoices, and commitments where relevant | Leaving supplier or budget items unresolved |
| Resource release | Return people and assets to normal allocation | Keeping resources tied up unnecessarily |
| Lessons learned | Capture what worked and what should improve | Waiting until people have moved on |
| Records archive | Preserve controlled project information | Losing decision history and approvals |
| Benefits review | Confirm how benefits will be measured after closure | Assuming all benefits are realized immediately |
Delivery Approach and Tailoring
The PFQ is a fundamentals exam, so be ready to recognize delivery approach characteristics without turning every answer into a method debate.
| Approach | Characteristics | Good fit when… | Watch for |
|---|---|---|---|
| Predictive / linear | Scope and plan are defined early; control focuses on baseline management | Requirements are stable and solution is well understood | Too rigid if uncertainty is high |
| Iterative | Solution evolves through repeated cycles and feedback | Understanding improves through exploration | Needs active stakeholder involvement |
| Incremental | Deliver value in usable parts | Benefits can be released progressively | Requires clear integration and prioritization |
| Agile | Emphasizes adaptability, collaboration, and frequent delivery | Requirements are uncertain or changing | Not an excuse for no governance |
| Hybrid | Combines approaches | Some elements are stable while others need flexibility | Must be deliberately tailored, not accidental |
Tailoring readiness prompts
- What is the size, complexity, risk, and uncertainty of the project?
- Are requirements stable or evolving?
- How much governance and documentation is proportionate?
- What level of stakeholder involvement is needed?
- Are suppliers, regulators, or operational teams constraining the approach?
- What controls are still required even in an adaptive approach?
Artifact Checklist for Final Review
| Artifact | Purpose | Can you recognize when it is needed? |
|---|---|---|
| Business case | Justifies the project and supports continued decision-making | Value, benefits, costs, options, risks |
| Project brief / initiation information | Captures high-level project definition | Early clarity before detailed planning |
| Project management plan | Describes how the project will be delivered and controlled | Integrated planning and governance |
| Stakeholder register / analysis | Identifies stakeholders and their needs | Engagement and communication planning |
| Communication plan | Defines messages, audiences, timing, and channels | Avoiding missed or inappropriate communication |
| Requirements documentation | Captures what the solution must satisfy | Scope definition and acceptance |
| Product breakdown structure | Breaks down deliverables/products | Product-based planning |
| Work breakdown structure | Breaks down work packages/tasks | Estimating, scheduling, responsibility |
| Schedule | Shows timing, dependencies, and milestones | Tracking and forecasting time performance |
| Budget / cost plan | Shows planned cost and funding | Cost control and forecasting |
| Risk register | Records risks, assessments, responses, and owners | Active risk management |
| Issue log | Records current problems and actions | Resolution and escalation |
| Change log | Tracks requested, approved, rejected, or implemented changes | Scope and baseline control |
| Quality plan | Defines quality standards and control methods | Assurance, control, and acceptance |
| Responsibility assignment matrix / RACI | Clarifies who is responsible, accountable, consulted, and informed | Role ambiguity |
| Lessons learned log | Captures learning during and after the project | Continuous improvement |
| Closure report | Confirms closure position and remaining actions | Formal completion |
High-Value “Can You Do This?” Checklist
Use this as a fast self-test. If any item feels uncertain, revisit the topic before doing more timed practice.
Project fundamentals
- Define a project and distinguish it from operations.
- Explain how projects support organizational change.
- Distinguish project, programme, and portfolio.
- Identify outputs, outcomes, and benefits.
- Explain the purpose of project constraints such as time, cost, quality, scope, risk, and benefits.
- Recognize why projects operate in an internal and external environment.
Life cycle and governance
- Place activities into initiation, planning, delivery, handover, closure, or benefits review.
- Explain why approval points and reviews are used.
- Identify sponsor, project manager, team, user, supplier, and governance responsibilities.
- Decide whether a scenario needs project-manager action, sponsor decision, or escalation.
- Explain why governance should be proportionate.
Planning and control
- Identify the purpose of a project management plan.
- Explain the link between scope, schedule, resources, budget, risk, and quality.
- Interpret a simple milestone or dependency scenario.
- Recognize the critical path and float conceptually.
- Explain why baselines are used for control.
- Identify when a plan must be updated.
Stakeholders and communication
- Identify stakeholders from a project scenario.
- Select appropriate communication methods for different audiences.
- Explain why feedback matters.
- Recognize stakeholder resistance and choose a constructive response.
- Distinguish engagement from one-way reporting.
Risk, issue, and change
- Write or recognize a clear risk statement.
- Distinguish risk from issue.
- Match risk responses to scenario needs.
- Explain why risk owners are needed.
- Follow a sensible change-control sequence.
- Identify the impact areas affected by a change.
Quality, procurement, and closure
- Distinguish quality assurance from quality control.
- Explain acceptance criteria and formal acceptance.
- Recognize supplier-management responsibilities.
- Identify handover requirements.
- Explain why lessons learned and closure records matter.
- Distinguish project closure from benefits realization.
Scenario Decision-Point Checks
PFQ questions often reward the most controlled, proportionate, and role-appropriate response. Use these decision prompts while reviewing practice items.
| Scenario | Ask yourself | Likely readiness principle |
|---|---|---|
| A stakeholder requests a new feature | Is it within agreed scope? What is the impact? Who approves? | Use change control |
| A risk has occurred | Is it now an issue? What response or escalation is needed? | Move from risk monitoring to issue management |
| A deliverable fails testing | Is this a defect against agreed criteria? What corrective action is needed? | Use quality control and issue resolution |
| The project is forecast to exceed budget | What is the cause, forecast impact, tolerance, and authority level? | Analyze variance and escalate if needed |
| A team member is unclear what to do | Are responsibilities, work packages, and priorities defined? | Clarify roles and planning information |
| Users are unhappy with the solution | Were requirements, engagement, and acceptance criteria clear? | Revisit stakeholder and scope management |
| Supplier delivery is late | Does it affect critical path, cost, quality, or risk? | Manage supplier performance and project impact |
| Sponsor asks for faster completion | What options affect scope, cost, quality, risk, and resources? | Balance constraints before committing |
| A project stage is ending | What review, approval, or updated justification is required? | Use governance and stage control |
| Project outputs are delivered | Have acceptance, handover, closure, and lessons learned been completed? | Do not skip formal closure |
Common PFQ Weak Areas and Traps
| Trap | Better exam habit |
|---|---|
| Choosing the fastest action instead of the controlled action | Check governance, authority, and impact first |
| Treating risks and issues as the same | Ask whether the event is uncertain or already happening |
| Assuming the project manager owns all decisions | Identify sponsor, board, user, supplier, or team responsibility |
| Forgetting the business case after initiation | Review justification when major change or risk occurs |
| Confusing communication with stakeholder engagement | Look for two-way understanding and involvement |
| Treating quality as inspection only | Include planning and assurance |
| Accepting scope changes informally | Record, assess, approve, update, communicate |
| Focusing only on schedule | Consider cost, quality, scope, risk, benefits, and stakeholders |
| Confusing outputs with benefits | Ask what value is realized after the output is used |
| Closing the project too early | Confirm acceptance, handover, records, lessons, and resource release |
| Over-applying agile or predictive assumptions | Use the approach described in the scenario |
| Ignoring assumptions and constraints | Check whether planning depends on something uncertain or limiting |
Final-Week PFQ Review Plan
| Timeframe | Focus | What to produce |
|---|---|---|
| 7 days out | Broad topic coverage | Mark each topic area green, amber, or red |
| 6 days out | Definitions and distinctions | Flash review of key pairs: risk/issue, QA/QC, output/outcome/benefit |
| 5 days out | Artifacts and roles | One-page map of artifact purpose and role responsibility |
| 4 days out | Scenario judgment | Practice “what should the project manager do next?” questions |
| 3 days out | Planning, risk, change, quality | Review control sequences and common traps |
| 2 days out | Mixed practice | Timed set, then review every missed question by topic |
| 1 day out | Light consolidation | Re-read weak-area notes, avoid cramming new material |
Final readiness checklist
- I can explain every topic-area row in the readiness map without looking up definitions.
- I can answer “who owns this?” for common project roles.
- I can answer “which artifact should be updated?” for scope, risk, issue, change, schedule, and quality scenarios.
- I can interpret basic schedule, cost, and risk information.
- I can choose proportionate actions rather than extreme responses.
- I can identify when escalation is appropriate.
- I can explain why business justification, benefits, stakeholders, and controls remain connected throughout the project.
- I have reviewed my missed practice questions and linked each miss to a topic weakness.
Practical Next Step
Turn this checklist into an action list: mark each section green, amber, or red, then practice PFQ-style questions starting with the red areas. After each practice set, record the missed topic, the mistaken assumption, and the rule or concept you will apply next time.