Cost-Benefit Analysis: Size the Gain Before You Commit to a Pilot

Cost-Benefit Analysis quantifies the total costs and benefits of each solution so you can support go or no-go investment decisions. That is the whole job. It does not pick the solution for you. It puts a number on the one you are proposing.

In RDMAICS, the tool sits in the Improve phase. By the time you open it, you have already done the hard analytical work. You recognised a problem, defined its scope, measured the baseline and analysed the cause. You now have a candidate change. The question has shifted from "what is wrong" to "is fixing it worth the money".

Reach for the tool at the point where a diagnosed cause becomes a proposed change. Before you ask for budget. Before you book a pilot. Before anyone signs a licence. The analysis is cheap compared with the commitment it informs, which is exactly why it belongs early.

A second trigger is competition between options. When two or three changes could address the same cause, running each through the same structure gives you a comparable number instead of a comparable argument.

The example used throughout this guide is the sample data built into the tool. It is fictional. No real organisation, product or vendor is involved. It is there so you can see the mechanics without having to supply your own figures first.

The scenario is a finance team processing supplier invoices by hand. The analysis phase pointed at manual data entry as the cause behind three visible symptoms: high labour load, rework from keying errors and late payments attracting penalties. The proposed change is optical character recognition software that reads invoices and feeds the finance system.

That proposal has a price. It has a licence cost, an integration and implementation cost, and a training and change management cost. It also has three expected benefits, each tied to one of the symptoms the analysis identified. The tool puts all six on the same page over a three year horizon.

Note how closely the benefit rows mirror the diagnosis. That is deliberate. If a benefit line cannot be traced back to something you measured in the Measure phase, it is a hope rather than a benefit.

The worksheet is a table. Each row is one cost or benefit item. Each row carries a type, a Year 1 figure, a Year 2 figure and a three year total. The three year total column is the one the calculation reads.

The sample case uses seven rows. Three are typed as Cost, three as Benefit, and one is typed as Net. The type field is what tells the tool which side of the ledger each row belongs to, so it matters more than the wording of the item name.

Here is the full sample worksheet:

Look at the cost rows across the two visible years. The licence falls from 45000 to 12000. Integration is 60000 in Year 1 and 0 in Year 2. Training falls from 15000 to 3000. The costs are front loaded.

The benefit rows behave differently. Labour savings hold at 180000 in both years. Error rework savings hold at 65000. Penalty savings hold at 24000. The benefits are flat and recurring.

That contrast is the single most useful thing a cost and benefit table shows you. One side is a spike. The other side is a stream. If you only looked at Year 1, the picture would be far less generous than the three year view. If you only looked at the three year total, you would miss how much cash the first year demands.

This is why the tool asks for yearly columns as well as a total. Keep both. The total answers whether the change pays. The yearly split answers whether you can afford the start.

The result panel reports that it was calculated from seven numeric rows in the three year total column, and that the view is built from the worksheet. It returns three headline figures.

Benefits total 807000 dollars. Costs total 150000 dollars. Net benefit is 657000 dollars. A chart plots cost, benefit and net on a shared scale running from 0 to 1000000, so the relative size of each is visible at a glance rather than inferred from the digits.

Check the arithmetic yourself, because that check is part of using the tool well. The three benefit rows are 540000, 195000 and 72000, which sum to 807000. The three cost rows are 69000, 60000 and 21000, which sum to 150000. The difference is 657000, which matches the net benefit row already entered in the worksheet as row seven.

That agreement is the point. The worksheet carries a stated net benefit of 657000 and the calculation independently produces 657000 from the component rows. When those two numbers match, the table is internally consistent. When they do not, you have a data entry problem to find before you go any further.

The tool also offers an AI review that explains the result in plain language, which is useful when you are passing the analysis to someone who did not build it.

A net benefit of 657000 against costs of 150000 is a wide margin. That width is what gives you room to act. It means the proposal survives being wrong about some of its inputs, which is a more honest test than whether it looks good when every assumption lands.

The decisions the analysis supports are these:

The first mistake is counting a benefit that will not be realised. The largest benefit row here is 540000 from FTE reduction. That figure only lands if headcount actually changes or if the freed capacity is redeployed to work that has value. If neither happens, the saving is theoretical and the net benefit is overstated.

The second mistake is omitting costs that sit outside the project budget. Training and change management appears in this worksheet at 21000, which is good practice. Many analyses leave it out because it is absorbed by an existing team. Absorbed is not free.

The third mistake is mismatched horizons. The costs here are mostly spent in Year 1. The benefits accrue across three years. If you extend the benefit horizon without extending the cost horizon, the ratio improves for no real reason. Keep both sides on the same clock.

The fourth mistake is entering a net row and never checking it against the components. The sample worksheet contains a net row of 657000 and the calculation agrees. Treat that agreement as a test you run, not a formatting detail.

Cost-Benefit Analysis does not validate your inputs. The figure of 807000 in benefits is correct arithmetic performed on numbers you supplied. If the labour saving estimate is optimistic, the tool will still add it up neatly. The quality of the output is capped by the quality of the estimates, and the tool has no way to know the difference.

It does not account for the time value of money in this view. The totals are simple sums across the years. A dollar in Year 3 is treated the same as a dollar in Year 1. If your organisation requires discounted cash flow or a formal rate of return, this analysis is an input to that work rather than a replacement for it.

It does not measure risk, and it does not weigh anything that resists being priced. Implementation delay, staff resistance, data quality problems in the source invoices, vendor dependency, the effect on people whose roles change. None of those appear in a row. They still decide whether the change succeeds.

It also does not prove causation. The analysis assumes the diagnosed cause is the real one and that the proposed change addresses it. That assumption was made in the Analyse phase. Cost-Benefit Analysis inherits it without testing it.

Use the tool for what it is. It converts a proposal into a defensible number, it shows you the shape of the spend against the shape of the return, and it gives you a baseline to hold yourself to in Control and Sustain. The judgement about whether to proceed stays with you.