7.4 Project Assurance
Key Takeaways
- Assurance provides confidence to the governance board that a project is on track to deliver its objectives.
- Assurance is independent of the delivery team, which is what makes its opinion worth having.
- Quality control checks deliverables against specified requirements; assurance checks that the processes and controls producing them are adequate and being followed.
- The scope, priorities, and strategic aims of assurance should be proportionate to project value, risk, novelty, and profile.
- Assurance findings must be escalated with an owner, an action, and a date, or the review becomes an unread report.
What Assurance Means on the APM PMQ
The APM PMQ defines assurance as the ability to provide confidence to the governance board that a project is on track to deliver its objectives. Assurance answers a board-level question: Can we trust that this project will achieve what we funded it to achieve, under an acceptable level of control and risk?
Assurance is a governance support function. It does not replace the project manager, sponsor, or board. It gives those roles a more reliable basis for decisions by testing plans, controls, evidence, and forecasts with an appropriate degree of independence.
High-yield trap: Do not treat assurance as a synonym for quality control. Quality control inspects or tests deliverables against agreed criteria. Assurance provides confidence about the project’s management and trajectory toward objectives. Related ideas appear in quality management, but LO7 is about governance confidence, not product inspection alone.
Purpose of Assurance Within a Project
The purpose of project assurance is to:
- Give the board/sponsor justified confidence (or justified concern) about delivery of objectives.
- Challenge assumptions that delivery teams may under-report (optimism bias, incomplete risk, weak benefits logic).
- Test whether controls are operating — change control, reporting integrity, financial authority, risk escalation, supplier management, and compliance obligations.
- Highlight gaps early so corrective action is cheaper and still effective.
- Support investment decisions at gates and major change points with independent insight, not only the project manager’s narrative.
- Protect organisational standards so local delivery pressure does not quietly bypass mandatory process.
Confidence is not the same as cheerleading. Effective assurance is willing to report amber or red findings when evidence is weak. False confidence is worse than no assurance because it delays escalation.
Scope, Priorities, and Strategic Aims of Assurance Activities
Assurance resources are limited. Good practice is risk-based: focus where failure would hurt objectives, benefits, safety, compliance, reputation, or money the most.
Scope
Typical assurance scope may include:
| Scope area | What assurance examines | Why boards care |
|---|---|---|
| Objectives and business case | Clarity of success criteria; ongoing viability evidence | Investment may no longer be justified |
| Plans and baselines | Realism of schedule, cost, resource, and dependency plans | Forecasts drive funding and commitments |
| Controls and governance | Whether delegated authority, change control, and escalation actually work | Uncontrolled change destroys baselines |
| Risk and issue management | Completeness, ownership, and action effectiveness | Hidden exposure becomes crisis |
| Benefits and transition readiness | Benefits measures, ownership, and BAU preparedness | Outputs without outcomes waste investment |
| Compliance and standards | Mandatory methods, safety, security, procurement, regulatory needs | Breaches create legal and operational risk |
| Reporting integrity | Whether status data is complete, timely, and not misleading | Boards cannot decide on fiction |
| Supplier and interface control | Contract performance, acceptance, and dependency management | External failure often drives project failure |
Scope should be documented (terms of reference, assurance plan, or mandate) so everyone knows what is in and out of review. Unscoped assurance becomes random checking; overscoped assurance becomes noise.
Priorities
Prioritise assurance effort by:
- Impact on objectives and benefits if the area fails.
- Uncertainty and novelty (first-of-kind technology, new supplier, new market).
- Control history (previous findings, weak process maturity, prior overruns).
- Life-cycle moment (before major gates, contract awards, go-live, or regulatory submissions).
- Organisational risk appetite and regulatory exposure.
A low-risk internal process tweak may need light-touch assurance. A safety-critical infrastructure upgrade needs deeper, earlier, and more independent assurance even if the schedule is tight.
Strategic aims
Strategic aims of assurance activities typically include:
- Protect value — keep the link between spend, outputs, and intended outcomes under honest scrutiny.
- Enable better decisions — give the board options and residual-risk visibility, not only problem lists.
- Improve organisational learning — feed systemic weaknesses (estimating, benefits ownership, supplier onboarding) back into the PMO or portfolio.
- Maintain proportionate control — enough challenge to manage risk without paralysing delivery.
- Support confidence for external stakeholders where funders, regulators, or partners need evidence of control.
Assurance strategy should align with project strategy and life cycle. Linear capital projects often front-load assurance before each gate. Iterative product work may assure the product management system, release readiness, and benefits hypotheses more frequently in smaller slices. Hybrid work needs clear coverage maps so neither the gated nor the iterative stream escapes challenge.
How Assurance Differs from Quality Control
This distinction is a classic PMQ trap. Keep the language precise.
| Dimension | Project assurance | Quality control |
|---|---|---|
| Primary question | Are we on track to meet project objectives under effective control? | Does this product/deliverable meet the specified criteria? |
| Object of scrutiny | Management system, plans, forecasts, risks, benefits, governance | Deliverables, components, documents, tests, inspections |
| Typical techniques | Independent review, health checks, gate assurance, process compliance sampling | Inspection, testing, measurement, defect logging, acceptance checks |
| Main customer of the result | Sponsor, board/steering group, sometimes portfolio or audit committee | Project manager, team, user/acceptor against quality criteria |
| Success look like | Justified confidence (or justified concern) for governance decisions | Defects found/fixed; acceptance criteria met |
Quality assurance (in the quality-management sense) is related but still not identical to LO7 project assurance: quality assurance builds confidence that processes will produce conforming products. Project assurance is broader: it covers whether the project as a whole remains on track for its objectives, including benefits, risk, schedule, cost, and governance — not only product conformity.
Mini example
A software release passes functional tests (quality control is green). Assurance still raises a red finding because benefits owners are undefined, training is unfunded, and the cost forecast ignores licence renewal — so the project is not on track for its stated business objectives even if the code works.
How Assurance Differs from Day-to-Day Project Management
| Dimension | Project management (day-to-day) | Project assurance |
|---|---|---|
| Role | Plan, lead, and control delivery within tolerances | Independently review and provide confidence/challenge |
| Accountability | Project manager accountable for managing the project | Assurers accountable for objective assessment within mandate |
| Relationship to work | Inside the delivery engine | Outside or semi-independent of delivery line management |
| Decisions | Directs work and implements approved changes | Recommends; does not normally take over delivery decisions |
| Reporting line for findings | Status to sponsor/board as manager of the work | Findings to sponsor/board (and often via PMO/audit routes) with management response expected |
The project manager wants the project to succeed and may filter bad news unconsciously. Assurance exists partly to counter that bias. Independence can be structural (separate assurance team, internal audit, external reviewer) or procedural (peer review from another project, PMO health check with a clear mandate). Absolute independence is not always possible in small organisations, but some independence from the people who created the plan being reviewed is essential for credibility.
Three Lines of Defence Framing (PM Practice)
Many organisations describe control using a three lines of defence model. Used carefully, it helps PMQ answers about who does what:
| Line | Who | Project example | Assurance contribution |
|---|---|---|---|
| 1st line | Delivery management | Project manager, team, suppliers managing work and first-level controls | Own day-to-day control; respond to assurance findings |
| 2nd line | Risk, compliance, PMO, specialist control functions | Project assurance reviews, methodology compliance, risk oversight | Provide ongoing challenge and framework assurance |
| 3rd line | Internal audit (and sometimes external audit) | Independent audits of project control environment | Periodic independent opinion to senior governance |
Not every organisation labels roles this way, and the PMQ will not always use the phrase. The useful idea is hierarchical independence: management controls work; assurance challenges management; audit independently verifies the control system. Collapsing all three into the project manager removes the challenge LO7 expects.
Escalation of Assurance Findings
Findings only create value when they drive action.
Good practice flow
- Agree facts — evidence-based findings, not personality conflicts.
- Rate severity — impact on objectives, compliance, benefits, and residual risk.
- Agree management response — accept, mitigate, transfer, or (rarely and consciously) accept residual risk within appetite.
- Assign owners and dates — corrective actions enter the plan and risk/issue logs.
- Escalate when needed — if the project manager cannot resolve the issue within tolerance, if independence is being blocked, if findings invalidate the business case, or if mandatory controls are bypassed.
- Track to closure — re-assure critical findings before the next major gate or go-live.
Escalate to the sponsor/board when findings show: systemic reporting distortion; breaches of financial or regulatory authority; benefits no longer plausible; critical path risk beyond tolerance; or management unwillingness to act. Escalation is part of assurance purpose — protecting the board’s ability to govern — not disloyalty to the team.
Scenario A — independence and confidence
A programme board receives only green reports from a project manager under intense deadline pressure. An independent assurance review samples the risk register and finds three unowned critical supplier risks and a benefits map with no operational owner. Assurance reports limited confidence in go-live readiness. The board delays cutover, funds supplier contingency work, and assigns benefits owners. Assurance did not "manage the project"; it restored truthful confidence for a governance decision.
Scenario B — assurance is not quality control
Testers reject a batch of civil drawings that fail dimensional checks (quality control). Separately, project assurance reviews whether design review gates, competency records, and change control for drawing revisions are operating. Even after drawings are corrected, assurance may still find that the process for issuing revisions is weak and must be fixed to prevent recurrence. Product fix and system confidence are both needed; they are not the same activity.
Scenario C — prioritised scope
A portfolio can fund only limited external assurance. For a low-risk intranet refresh, assurance is a light PMO health check on plan realism and stakeholder readiness. For a clinical systems cutover, assurance prioritises clinical safety controls, data migration confidence, fall-back plans, and benefits/operations ownership before go/no-go. Strategic aim: put deepest challenge where organisational harm would be greatest.
Putting It Together for Exam Answers
When a scenario asks about assurance:
- State the purpose: confidence to the governance board that objectives remain on track.
- Define scope and priority by risk to objectives, compliance, and benefits.
- Separate assurance from quality control and from day-to-day project management.
- Explain the value of independence and constructive challenge.
- Show how findings lead to management response and escalation when residual risk exceeds tolerance.
That structure matches LO7 and avoids the two common failures: equating assurance with testing, and treating assurers as substitute project managers.
What is the primary purpose of project assurance on the APM PMQ?
Which statement best distinguishes project assurance from quality control?
An independent assurance review finds that critical benefits have no operational owner and go-live risk is understated in board reports. What should happen next?