How Do You Measure ROI on a Completed Project Without Overclaiming?

## The short answer

To measure ROI on a completed project credibly, compare the net benefits realised against the full cost of delivery and ongoing run, using a measured baseline, after stripping out value you cannot attribute to the project and subtracting any disbenefits. The formula is simple; the integrity lies in the inputs. Most overclaiming comes from a missing baseline, weak attribution, ignored running costs, or counting forecast benefits as if they were realised.

## The basic calculation

Return on investment is, at its core:

**ROI = (Net realised benefit − Total cost) / Total cost**

Where net realised benefit is the value actually delivered, attributable to the project, minus disbenefits, and total cost includes both the cost to deliver and the cost to run the new capability over the period being measured. Each of those qualifiers is where rigour is won or lost.

## Get the costs complete

Understated costs inflate ROI just as much as overstated benefits. A complete cost picture includes:

- Delivery costs: people, software, infrastructure, third parties.

- Internal effort that is easy to forget: business SME time, change management, training.

- Ongoing run costs: licences, support, maintenance, the team needed to operate the capability.

- Decommissioning or transition costs where the project replaces something.

Measuring benefits over a year while only counting delivery costs is one of the most common ways ROI gets quietly exaggerated.

## Establish what would have happened anyway

Attribution is the hardest and most important part. The question is not "what changed?" but "what changed *because of this project*?" Some of the improvement you observe may have happened regardless, due to market conditions, other initiatives, or seasonal effects.

Approaches that strengthen attribution:

- **Baseline comparison.** Measure the metric before the change and after, ideally over a like-for-like period.

- **Control groups.** Where possible, compare a group exposed to the change against one that was not.

- **Documented assumptions.** Where clean isolation is impossible, state the assumption explicitly and apply a conservative discount to the claimed benefit.

If you cannot defend the attribution, do not claim the full benefit. A smaller, defensible number beats a large, challengeable one every time.

## Count the disbenefits

Every change has downsides, and an ROI that ignores them is not trustworthy. Typical disbenefits include:

- A temporary productivity dip during adoption.

- New running costs the old process did not have.

- Effort diverted from other work.

- Risks introduced by the new way of working.

Netting these off makes the claim more believable, not less, because reviewers know they exist and will discount any figure that pretends they do not.

## Separate realised from forecast

At the point of measuring a completed project, distinguish clearly between:

- **Realised benefits**, which have actually occurred and can be evidenced.

- **Forecast benefits**, which are still expected but not yet delivered.

Report them separately. Folding forecasts into the ROI headline is the classic overclaim, because it presents an estimate as an outcome. The honest framing is: "X realised to date, Y forecast over the next period, on a total cost of Z."

## Choose the right time horizon

ROI depends heavily on the period you measure over. A capability with high upfront cost may look poor at six months and strong at two years. Be explicit about the horizon, justify it against the expected benefit profile, and avoid cherry-picking the window that flatters the number. For longer horizons, consider whether to discount future benefits to present value rather than treating a pound next year as equal to a pound today.

## Make it evidenced and repeatable

A credible ROI statement can be traced back to source data: the baseline measurement, the cost ledger, the attribution assumptions, and the realised-benefit evidence. If the calculation lives only in one analyst's spreadsheet, it will not survive challenge and it cannot be repeated for the next project. Holding baselines, costs, and realised benefits in a connected, auditable system is the area neart.ai builds enterprise-grade products for, which is what makes an ROI claim defensible months later.

## A quick credibility checklist

- Is there a measured baseline, not an estimate?

- Do costs include run and internal effort, not just delivery?

- Is attribution argued, with conservative discounts where uncertain?

- Are disbenefits netted off?

- Are realised and forecast benefits reported separately?

- Is the time horizon stated and justified?

## Practical takeaway

Honest ROI is built from honest inputs: a real baseline, complete costs, defensible attribution, netted disbenefits, and a clear split between realised and forecast value. Claim the number you can evidence and defend under challenge, not the one that looks best on a slide. A modest, bulletproof ROI builds the credibility that lets your PMO be trusted with the next investment.