A project can be delivered on time, within budget and signed off, and still leave nobody sure whether it was worth doing. Closing the project and realising its benefits are two different events, and the second usually has no calendar entry unless someone creates one. That someone is usually the person who asked for the project in the first place, and the project manager can help them set it up.
Start with the outcome
I have built business cases and ROI analyses, on a multi-country retail platform and in a fixed-price delivery division. The method does not change much. At the start, before the scope is argued about, I ask what the organisation wants to be different. Usually the answer is one of three things: more revenue, more productivity, or lower internal costs.
If the answer is vague, the project will be judged on feelings later. A clear outcome also helps scope: a feature that does not move the outcome is a candidate for the next phase.
Benefits also arrive later than delivery. A new way of working can take months to show in the numbers, so I agree at the start when each indicator will be checked and who will check it.
Pick a few indicators
- Few. Three or four that people will actually look at beat a dashboard of thirty.
- Linked to the outcome. Each indicator should answer the question: did the thing we wanted change?
- With a starting value. Without a measurement from before go-live, there is nothing to compare with.
- With an owner on the business side, not only in the project team.
A generic example: if the outcome is lower internal cost, one indicator could be the time spent on a manual task that the system replaces, measured before and after. It is simple, the business owner can verify it, and it needs no complex model.
Usage is a signal, not the benefit
After go-live, usage monitoring is the first thing that moves. It is a useful leading signal: if people do not use the system, the benefit will not arrive. But heavy usage does not prove that revenue grew or that costs fell. I read usage as a sign to look further, and I measure the benefit itself against the goals set at the start.
Feed it into the roadmap
Ownership matters here. The project team can deliver the system, but only the business can change how the work is done. So the benefits owner sits on the business side, and the steerco reviews the indicators after go-live, not only the delivery status. I also keep the business case alive during delivery: a change that adds cost and moves no indicator is worth questioning.
The measurement is useful only if it changes a decision. Results go into the next roadmap discussion: invest more where the benefit is visible, rethink where it is not, and be honest when the original case was too optimistic. That honesty is uncomfortable once, and it makes every later business case more credible.