Step 05

Build the Cost-Benefit Analysis

In Brief — A complete investment case needs two legs: the financial leg, which projects the return, and the tangible leg, which names what operational change produces that return and who can confirm it happened. Most cases have one strong leg and one they hope nobody examines too closely. This step builds both. A case that cannot clear both tests is not ready for prioritization.

What’s Actually Happening

The financial model looks good. The numbers add up. The ROI is attractive and the payback period fits inside the planning horizon that leadership cares about.

But ask the sponsor what specifically will change in the operation when this investment works, and the answer gets vague. Ask who will confirm that the change happened. Ask when. Ask what you would look at to verify it. The answers get vaguer.

Every investment has two legs. The financial leg answers what the model projects. The tangible leg answers what will actually change for a real person doing real work, and who can confirm it happened. Most cost-benefit analyses are built with one strong leg and one they hope nobody examines too closely. That works until a project goes live and delivers the projected technical output while the business outcome never materializes. By then, the CBA is in a folder somewhere and nobody is comparing the actual results against the modeled ones.

Why This Step Exists

Because the financial model does not protect against the most common failure mode in portfolio investment: doing the wrong work efficiently.

An organization can hit every milestone, stay within budget, and deliver exactly what was approved — and still not produce the return the investment was supposed to generate. The return was always tied to an operational change that either did not happen or happened differently than the model assumed.

The CBA also exists because it is a forcing function. A well-constructed cost-benefit analysis requires the sponsor to make specific claims about specific outcomes, supported by specific evidence, owned by a specific person, confirmed by a specific date. Most proposals cannot survive that discipline in their original form. They get refined, reframed, or in some cases withdrawn — not because the governance process rejected them, but because the act of building the case honestly revealed that the case was not as strong as it appeared. That is not a failure. That is the process working.

What Good Looks Like

The CBA has two sections that are equally rigorous.

The financial case makes explicit claims about ROI, cost reduction, revenue impact, or risk mitigation. It includes a baseline. It separates hard savings from cost avoidance from productivity gains. It states the confidence level on each benefit category and the evidence behind the projection. It does not present estimates as certainties.

The tangible case names the specific operational change — not “improved efficiency” but “the underwriting team processes applications in X days instead of Y days.” It names who owns that outcome. It names the timeframe — a specific date, not “within a reasonable period.” And it names how the change will be confirmed.

A CBA that has both sections in full is a document the governance forum can use. A CBA with only the financial section is a model that will be difficult to hold accountable.

How to Do It

Start with the baseline. Before projecting what the investment will produce, establish what exists today. Without a baseline, the benefit projection is directionally interesting but not verifiable.

Build the financial case in sections by benefit type. Separate hard savings from cost avoidance from revenue protection or growth. Each category carries different levels of confidence. Presenting them separately allows the governance forum to evaluate which parts of the case are well-supported and which are speculative.

For each benefit projection, state the source of the estimate, the confidence level, the adoption assumption embedded in the projection, and the timeframe in which the benefit is expected to materialize.

Then build the tangible case. For each financial benefit projected, ask: what operational change produces this result? Name it specifically. Name the owner. Name the measurement and the date.

A single required field captures most of this discipline: Tangible outcome: [what specifically changes], confirmed by [owner], within [timeframe], measured by [source]. That one field turns a modeled benefit into a testable hypothesis.

What Breaks When You Skip It

The governance forum approves investments on attractive financial projections, and the organization has no way to know whether those projections were accurate after the projects close.

Benefits reviews happen — if they happen at all — against outcomes that were never defined clearly enough to measure. The investment is counted in the portfolio as successful because the project closed on time and on budget.

Repeat this pattern across a portfolio and the organization gradually loses the ability to learn from its investments. It keeps funding the same categories of work based on the same financial projections that have never been validated.

The Gotchas

False precision. A financial model that projects $1,847,500 in Year 3 savings looks more rigorous than one that projects $1.5M–$2.2M, but it is not. The precision of the output cannot exceed the precision of the inputs. State the range. State the confidence.

Double-counted benefits. Multiple work items in the portfolio may claim the same operational benefit. The portfolio review needs to catch this. Individual CBAs often do not.

Productivity benefits that assume full adoption. A projection that “employees will save two hours per week” is modeling a change in behavior, not technology. Productivity benefit projections should state explicitly what adoption rate they assume.

Benefits without owners. A benefit that is projected in the financial model but has no named owner is a benefit that will not be tracked after delivery. Someone in the business needs to own the confirmation. Name them before approval.

Where the Disciplines Show Up

→ Decision Discipline: The CBA is a decision document. It should answer: “do we have sufficient confidence in this investment to commit organizational resources to it?” If the governance forum cannot answer that question from what the CBA contains, it is not ready.

→ Change & Absorption: Most benefit projections embed an adoption assumption. If the benefit depends on people working differently, the CBA should state what the change management plan is and how adoption will be measured.

→ Enterprise Fit: The cost side of the CBA should include costs often omitted: ongoing support costs, integration maintenance, technical debt created, training costs, and decommission costs for whatever the new investment replaces.

→ Evidence: Three categories of CBA claim require different scrutiny: claims based on data (high confidence), claims based on benchmarks (medium confidence), and claims based on expert judgment or assumption (low confidence). All three are legitimate. All three should be labeled.

→ Political: Every financial model produces a number that someone will have an opinion about before they see it. A sponsor wants the return high enough to justify approval. A stakeholder competing for the same resources wants it low. The CBA must be technically credible enough to withstand challenge from both sides — built on methodology and sourcing, not on the authority of whoever is presenting it.

The Key
Every modeled benefit must connect to a real operational change, owned by a real person, measured by a real source, within a real timeframe. Not all value should be monetized. Name the value clearly and let the governance forum weigh it honestly.

You know this step is working when the governance forum starts asking “what is this based on?” before approving a benefit projection — and when submitters start including that answer without being asked.

The Artifacts

T2 — CBA Template

A structured document with two sections: the financial case (baseline, benefit projections by type, cost projections, confidence levels, ROI summary) and the tangible case (operational outcomes, owners, timeframes, measurement sources). Both sections are required.

T20 — Benefit Owner Register

Lists each projected benefit, the operational owner responsible for confirming it materialized, the measurement method, and the confirmation date. This document travels with the CBA into the benefits register at Step 11.