Build the Cost-Benefit Analysis
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.
The Financial Method
Four mechanics turn a list of benefits and costs into a number a governance forum can defend. They are stated here so the model can be reproduced on paper, without the tool.
Money arriving in year four is worth less than money arriving now. Apply a discount rate to every recurring flow. Use your organization’s cost of capital if finance publishes one. Waypoint defaults to 10 percent when they do not. State the rate on the analysis, because a case that looks strong at 5 percent can fail at 12.
Pick the number of years the analysis covers and apply it to every proposal in the same cycle. Waypoint defaults to five. One-time costs sit at year zero; recurring benefits and costs are discounted from year one forward. A horizon chosen per proposal is a horizon chosen to produce an answer.
Net present value is the discounted benefit stream less the discounted cost stream, less the one-time cost at year zero. Payback is the point at which cumulative discounted benefit overtakes cumulative cost. Report both. Net present value tells you whether the investment returns more than it consumes; payback tells you how long the organization is exposed before it does.
Risk-reduction investments have no revenue line, so the benefit is the loss avoided. Estimate it as the annual probability of the event, times the impact if it occurs, times the proportion of that impact the investment actually removes, less a haircut for estimation uncertainty. Every one of those four numbers is a judgment, so name the source. An expected-loss figure with no source is not evidence, and the Prioritizer will not accept the top two Risk Reduction ratings without one.
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
Where the Disciplines Show Up
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
The three to five assumptions whose failure would materially change the investment case. Recorded here so the governance forum approves a case it can revisit rather than a number it has to trust. Reviewed again at Step 11 against what actually happened.
Opened here, at the cost-benefit case, not after go-live. Every projected benefit gets a description, a baseline, a projection, a confidence level, a named outcome owner, a measurement method, and a confirmation date. A benefit with no owner and no measurement method is a budget justification, not a benefit. Carried forward to Steps 8 and 11.
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.
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.