Use this project failure prevention checklist to test whether the conditions for delivery are actually in place. It is intended for kickoff, milestone reviews and material changes—not as a guarantee that a project will succeed. Record the evidence, owner and decision needed for each unresolved item.
This article focuses on checks and actions during a project. If a delivered project has not produced its expected value, start with why delivery can fall short of business outcomes.
How to use the checklist
Before a review, ask owners to bring current evidence rather than a traffic-light colour alone. Mark a check as confirmed, an open action or unknown. An unknown is a request for information; it should not silently become an assumption that everything is fine.
Use the appropriate decision authority for your project. Some gaps can be resolved by the delivery team; a change to funding, commitments or business purpose may require sponsor approval. Tailor the depth of review to the consequences of getting the decision wrong.
1. Confirm the outcome and sponsor
Check: Can the sponsor and delivery team describe the same business problem, intended outcome and success criteria? Who can authorize spending and resolve conflicting priorities?
Evidence: An approved charter or equivalent authorization, a named sponsor and a definition of success.
Act if missing: Record the disagreement and obtain a decision before making commitments that depend on it. Treat an unresolved objective as a governance gap, rather than expecting the team to guess.
2. Test scope and acceptance
Check: Are inclusions, exclusions and acceptance criteria explicit? Is there a person authorized to accept each important deliverable?
Evidence: A scope statement, requirements and examples of the acceptance tests. “User friendly” needs a more observable description before it can guide acceptance.
Act if missing: Walk through one representative workflow with the user and approver. Capture what must work and what is outside this release. Use the project plan guide to connect these details to the wider plan.
3. Check capacity and dependencies
Check: Do estimates reflect actual availability, review time, supplier inputs and other projects using the same people?
Evidence: Task owners, capacity assumptions, dependency dates and confirmation from external teams. A date in a plan does not establish a supplier commitment.
Act if missing: Ask the responsible teams to confirm availability and show the impact of late inputs. Present scope, date or resourcing options rather than hiding the gap by reducing testing.
4. Give risks and issues actionable owners
Check: Does each important risk have a response and trigger? Does each current issue have an action, owner and target date?
Evidence: A maintained risk and issue record connected to current milestones and decisions.
Act if missing: Assign the next action and escalation point. Escalate when the team lacks authority or capacity to manage the impact. Reporting a risk repeatedly is not the same as managing it.
5. Make decisions and changes traceable
Check: Can the team see which version of scope, budget and schedule is approved? Are change requests assessed for their effect on those commitments and the business outcome?
Evidence: A decision log, agreed reference versions and recorded approval for material changes.
Act if missing: Clarify the impact, approver and deadline. Keep an audit trail when commitments change. Use the definitions of baseline and change control to align the terminology across the team.
6. Review quality and operational readiness
Check: Have representative users tested the result? Are support, access, training, recovery arrangements and operating ownership ready for handover?
Evidence: Test results, unresolved defects, acceptance records and a handover checklist agreed with the operating team.
Act if missing: Identify what prevents a safe or usable release, agree who can accept residual risk and record the decision. A project should not treat a missing support owner as a task to discover after launch.
7. Assign benefits ownership and review dates
Check: Who will track adoption and benefits when the delivery team has moved on? What starting measure and data source will they use?
Evidence: An agreed benefit owner, measure, review period and response when results differ from expectations.
Act if missing: Arrange the business review before closure and confirm the handover of responsibilities. Some benefits take time to observe; record that timing instead of declaring them achieved at go-live.
A review record you can copy
| Check | Evidence or gap | Owner and next decision |
|---|---|---|
| Outcome and sponsorship | State the agreed objective or disagreement. | Name the decision-maker and date. |
| Scope and acceptance | Link the current criteria and unresolved questions. | Name the approver and next review. |
| Capacity and dependencies | List unconfirmed inputs and affected milestones. | Name the dependency owner and response date. |
| Risk and change | Identify the trigger, impact and current action. | Name the owner and escalation threshold. |
| Readiness and benefits | List handover gaps and benefit review commitments. | Name the operational owner and review date. |
Illustrative example: a supplier input slips
A supplier has not confirmed an integration needed for an upcoming release. The review identifies the affected workflow, the test window and the cost of keeping the team waiting. The project manager records the options: resequence independent work, reduce the first release or change the date.
The sponsor decides within their authority, and the team updates the agreed plan and informs affected stakeholders. The useful output is the decision and ownership—not simply marking the dependency red. This is an illustrative scenario, not a reported case study.
What this review can and cannot tell you
A checklist can expose missing information and unresolved decisions. It cannot eliminate uncertainty, compensate for withheld evidence or guarantee project success. Revisit the checks when assumptions change, and examine the results of earlier actions rather than merely repeating the meeting.
For the broader delivery practices behind these checks, read eight essential project management processes.
Further reading
For benefit measurement, see APM’s guide to measuring benefits. For investigation after delivery, return to our business-outcome diagnostic guide.
