A project can deliver its agreed scope on time and still leave the business problem unresolved. When that happens, diagnosing project failure requires more than asking whether the schedule slipped. Examine whether the assumptions connecting the deliverable to its intended outcome were correct, and whether someone owned the change after handover.
This article focuses on why delivery may not produce business value and how to investigate the gap. For checks to use before and during delivery, see the companion project failure prevention checklist.
Separate delivery, outcomes and benefits
Delivery produces outputs: a system, report, service or completed change. An outcome is the change those outputs enable, such as customers completing a process without assistance. A benefit is the resulting value, such as less handling effort or improved service reliability.
These are connected, but they are not interchangeable. A new application does not by itself establish that users adopted it or that operating costs fell. Conversely, a late project may still create value; that does not erase the effects of its delay. Assess delivery performance and business results separately.
Our project management terms guide explains related concepts such as scope, deliverables, baselines and change control.
Seven reasons the expected value may not appear
1. The objective described an output
“Launch a portal” describes delivery. It does not state whose problem the portal solves, what behaviour should change or how the organization will check the result. Ask the sponsor to describe the intended outcome in observable terms.
2. The business-case assumptions were never tested
Expected demand, adoption, savings or supplier capacity may have been treated as facts. Identify the assumptions that mattered most and compare them with evidence gathered during and after delivery. A weak assumption can make a well-built solution ineffective.
3. Users were involved too late
Requirements can be technically complete while missing the way work happens in practice. Review whether representative users tried the workflow and whether their feedback affected scope, training or rollout decisions. Approval from a sponsor is not a substitute for usable delivery.
4. Scope changed without revisiting the outcome
Adding features may increase effort without improving the intended result. Removing a difficult dependency may make a deadline achievable while leaving the business workflow incomplete. Trace material changes back to the benefit they were expected to enable.
5. Operational readiness was outside the plan
Training, support, data quality and ownership can determine whether the delivered solution is used. Check the handover record and the operating team’s capacity. If these activities had no owner or budget, the gap may be in transition planning rather than implementation quality.
6. No one owned benefits after closure
A delivery team may disperse before benefits can be measured. Agree who in the business will monitor the result, act on adoption problems and report progress. The project manager can coordinate this agreement; accountability depends on the organization’s governance.
7. The measures could not answer the question
A green dashboard can reflect completed tasks while outcomes remain unknown. Without a baseline, a defined population and a measurement period, a change in a headline number is difficult to interpret. Missing evidence should be reported as unknown, rather than automatically labelled success or failure.
Worked example: a delivered portal with weak adoption
Illustrative scenario: An internal service portal launches on schedule. The intended outcome is for employees to complete routine requests without email follow-up. After launch, staff still send emails and the service team continues entering requests manually. No real organization or measured result is claimed in this example.
Do not jump straight to “users resist change.” Check whether the portal supports the common requests, whether staff know it exists, whether approvals work and whether teams still accept email as the easier route. Each explanation suggests a different response.
| Question | Evidence to inspect | Possible response |
|---|---|---|
| Can users complete the workflow? | Representative task tests and error records | Fix the blocking step and retest with users. |
| Do users know when to use it? | Training coverage, communications and user interviews | Clarify the route for requesting help. |
| Does the operating model reinforce it? | Support procedures and responsibility for follow-up | Agree ownership and remove contradictory instructions. |
| Is there evidence of benefit? | Comparable pre-launch and post-launch measures | Agree a baseline and review period; disclose gaps. |
Choose measures that test the outcome
For each intended benefit, record a definition, an owner, a starting measure, a target, the data source and a review date. Choose the measures that support a decision. A long list of KPIs can obscure the question as easily as a short list of task counts.
- Delivery: Were the agreed outputs accepted, and what happened to scope, schedule, cost and quality?
- Adoption: Is the intended group using the new workflow, and how often do they need assistance?
- Operational result: Has handling effort, error frequency or service reliability changed?
- Business value: Does the result justify the investment under the assumptions agreed in the business case?
Interpret results in context. Changes in demand, staffing or other initiatives can also affect an outcome. Separate observed results from estimated benefits, and avoid attributing every improvement to one project. For more detail, see project success metrics and business value.
Run a diagnostic review without blame
- Agree which outcome is in question and the period being reviewed.
- Reconstruct the decisions, assumptions and handover commitments from records.
- Compare stakeholder accounts with delivery and operational evidence.
- Identify a testable explanation, then assign a corrective action and an owner.
- Choose whether to improve adoption, correct the solution, revise the business case or stop further investment through the appropriate governance decision.
Record uncertainty and review the response at an agreed date. The purpose is to improve the next decision, rather than produce a single cause that conveniently blames one person or team.
Further reading
APM explains the relationship between benefits management and project success. To turn the diagnostic questions into delivery controls, use our prevention checklist.
