How to measure the ROI of an IT project after go-live

Most IT project ROI is calculated once, before the project is approved, and never again. That pre-approval number is a forecast, often an optimistic one, written to secure funding. The ROI that matters is the one you measure after go-live, when real costs and real benefits can be compared.

Measuring it isn't complicated. It just requires deciding up front what you'll measure and coming back to measure it.

The basic formula

Return on investment compares net benefit with cost:

ROI = (total benefits − total costs) ÷ total costs

For multi-year investments, net present value (NPV) is often more useful because it accounts for the timing of costs and benefits. A project that pays back in year one is worth more than one that pays back the same amount in year four.

The formula is the easy part. The hard part is getting honest numbers for both sides.

Step 1: Count the real costs

Pre-approval estimates usually include build costs and miss much of the rest. Include:

• Delivery costs: internal labor, contractors, licenses, infrastructure.
• Change costs: training, process redesign, data migration, temporary productivity loss.
• Run costs: ongoing licenses, hosting, support and maintenance for the period you're measuring.
• Opportunity cost: not always included in ROI, but worth noting. What else could the team have built?

Internal labor is the cost most often left out, because it doesn't appear on an invoice. Estimate it from time spent and a loaded rate.

Step 2: Measure benefits against a baseline

Benefits fall into a few types:

The key is a baseline: the value before the change. Without it, any benefit claim is a guess. See Benefits realization.

Be careful with "hours saved." Saved hours only become financial benefit if they're redeployed to valuable work or reduce spending. Record what actually happened to the time.

Step 3: Pick the right measurement window

Benefits ramp up over time as adoption grows. Measuring at go-live understates them; waiting two years makes it hard to attribute changes to the project. For most IT projects:

• measure adoption at 30 to 60 days;
• measure benefits at 90 to 180 days;
• project the remaining period from the measured run rate, and say so clearly.

Step 4: Compare with the original case

The point isn't only the ROI number. It's the comparison:

In this example the project still broke even, but the gap tells you a lot. Costs ran 27 percent over, mostly from change management that wasn't planned. Benefits ran 30 percent under because adoption reached only 70 percent. Both lessons should change how the next business case is written.

Common pitfalls

• Attribution errors. If sales rose 10 percent the same quarter a CRM launched, the CRM didn't necessarily cause it. Compare with a control group or a trend line where you can.
• Counting benefits twice. Two projects can't both claim the same reduction in headcount.
• Ignoring run costs. A system with a great first-year ROI can turn negative once support costs accumulate.
• Treating ROI as pass or fail. A low ROI on a regulatory project may be fine; the alternative was a fine. Be clear about which objective the investment served.

When ROI is the wrong measure

Not every investment is best judged by ROI. Compliance work, security improvements and foundational platforms often have value that is real but hard to express in a single return figure. For these, measure against the objective they served, such as audit findings closed or recovery time achieved. See Outcome metrics vs. output metrics.

How Aizu helps

Aizu records financials such as NPV with each initiative and keeps them visible as part of the value case, alongside explicit gaps where cost or benefit evidence is still missing. After release, outcome targets and actual measurements sit with the same initiative, so the measured result can be compared directly with what the decision assumed. Related: Closing the loop.