Benefits at Risk After On-Time Delivery
An invoice automation project was delivered on time and 4% under budget. The business case promised a 20% reduction in cycle time and €180,000 annual savings from 60 users. Six weeks after go-live, usage reports show 24 of 60 staff have logged in; only 9 use the tool weekly. The remaining staff still email PDFs to finance. The vendor has completed handover, and the sponsor wants to close the project and release the team. The operations manager says adoption is 'not a project problem'. The benefits owner was named in the business case but has not been involved since approval. The next benefits review is in three months. Finance has already included the savings in next year's budget. The project manager has two weeks before the team is reassigned.
1. Should the project manager agree to close the project now? Justify the decision.
Read the worked answer
Not unconditionally. The project has delivered its output, but the business case promised an outcome that is not yet being realised. Closing now would release the team before adoption is stable and would leave the benefits owner without support. The project manager should distinguish project closure from benefits closure.
A responsible closure needs: a named benefits owner who accepts accountability, a measured adoption baseline, a dated adoption plan, a support route for users, and a benefits review schedule. If those exist, the project can close with residual actions transferred to operations. If they do not exist, the project manager should recommend a short transition period or a formal benefits-realisation phase. On-time delivery is not evidence that the promised savings will happen.
2. What actions should the project manager take in the next two weeks to protect the benefits?
Read the worked answer
Meet the benefits owner, operations manager, and finance representative. Measure current adoption, cycle time, and manual rework so the baseline is factual. Identify why 36 users have not logged in: training, process design, access, habit, or management expectation. Address the top barriers with targeted training, clear process rules, and visible support.
Agree who owns each adoption action and when it will be reviewed. Set up a simple benefits dashboard: active users, invoices processed through the tool, cycle time, and exceptions. Ask finance to distinguish 'savings included in budget' from 'savings realised'. Transfer the adoption plan to the benefits owner before the team is reassigned. The project manager should not personally chase 60 users; the line organisation must own the change.
3. How should the project manager report this situation to the steering committee?
Read the worked answer
Report delivery success and benefit risk separately. State the facts: on time, 4% under budget, 24 of 60 users logged in, 9 weekly, and the promised savings not yet evidenced. Explain the consequence for the budget assumption and the risk of closing without an owner.
Present options: close with a signed transition plan, extend the project for a short adoption phase, or pause closure until the benefits review. Recommend the option that gives the benefits owner real accountability and a dated review. Ask the steering committee for an explicit decision and record it. Do not hide the adoption gap behind the on-time delivery, and do not accept the operations manager's claim that adoption is 'not a project problem' without testing it against the business case.