Most business cases I've reviewed make the same error: they present a number. A single ROI, a single payback period, a single net present value, arrived at from a single set of assumptions chosen, consciously or not, to be the most persuasive version of the argument. The number looks precise. It is not. It is the output of a model, and the model's assumptions are doing almost all of the work, invisibly, behind a percentage sign.
A defensible business case shows the reasoning that produced the number, the assumptions it depends on, what happens when those assumptions are wrong, and whether the investment still makes sense in the most plausible adverse scenario. An executive who approves a business case built that way is making an informed decision. An executive who approves a single-scenario presentation is approving assumptions they haven't seen.
The components that must be present
A complete business case has four components. Omitting any of them doesn't make the case stronger; it makes it unfalsifiable, which is a different thing.
Investment. Total cost of implementation, broken down by category (technology, labor, external services, change management, training) and by period (what gets spent when). One-time costs and recurring costs separated. The investment side of a business case is usually more accurate than the benefits side, because costs are closer to known quantities, and being specific about them builds credibility for the benefit estimates that follow.
Benefits. Quantified benefits linked to the investment, with an explicit assumption for each. Cost reduction, revenue increase, risk reduction (monetized), productivity gain: each benefit requires a source (the process data or benchmark that justifies the estimate), a rate (by what percentage or amount), and a timing assumption (when it starts to accrue and at what ramp-up curve). Benefits that can't be quantified should be listed separately as qualitative benefits, with a description of the value they represent, not inflated into numbers by wishful calculation.
Risks. The assumptions that, if wrong, would significantly change the outcome. The cost estimate that could be exceeded and by how much. The benefit that depends on a behavior change that may not materialize. The timeline assumption that would shift the payback period from acceptable to marginal. Named, not buried in a single "risks and mitigations" paragraph at the end.
Timeline. When costs are incurred, when benefits begin, how long until breakeven. Presented as a cash flow projection by period, not as a single-row summary, so that the shape of the investment is visible: a business case with a three-year payback period looks very different when the benefits don't start until month eighteen than when they start in month one.
ROI and NPV: what they measure and what they don't
Return on investment is a ratio: (benefits minus costs) divided by costs. It is easy to calculate and easy to compare across alternatives. It is also a static number that treats all money as equivalent regardless of when it's received, which is a meaningful distortion when the investment timeline spans multiple years.
Net present value discounts future cash flows to their present value, using a discount rate that reflects the organization's cost of capital or the rate of return available from alternative investments. An NPV above zero means the investment returns more than the discount rate. A positive NPV does not mean the investment is the best use of capital: it means it clears the hurdle. Whether it clears it by a small margin or a large one, and whether a different option clears it by more, is the decision-relevant information.
Neither metric is wrong. Neither tells the full story. ROI is useful for simple comparisons; NPV is more honest about the time value of money. Use both, show the calculation, and state the discount rate used for NPV so that a reviewer with a different rate can recalculate rather than having to reverse-engineer it from the number.
Sensitivity analysis: finding the load-bearing assumptions
A sensitivity analysis answers one question: which assumption, if wrong by a given percentage, changes the investment decision? Not which assumption is most uncertain (that's a risk assessment), but which one matters most to the outcome.
The mechanics are straightforward: build the financial model with assumptions as inputs, then vary each assumption by plus or minus 10% or 20%, holding the others constant, and observe how much the ROI or NPV changes. The assumptions that produce the largest swing are the load-bearing ones: the analysis is most sensitive to them, and therefore the decision is most dependent on getting them right.
These are the assumptions worth investigating further before presenting the case, because they are where the greatest risk of being wrong lives. A cost estimate that is the largest single driver of sensitivity deserves a detailed breakdown and a second opinion. A benefit assumption that swings the ROI from positive to negative deserves a reference source and an explanation of why the base case is more plausible than the adverse case.
Three scenarios
Scenarios are distinct from sensitivity analysis. Sensitivity analysis varies one assumption at a time. Scenarios vary correlated clusters of assumptions that reflect coherent narratives about how the future might unfold.
The three scenarios I build for every business case:
Base case. The most likely outcome, based on the most supportable assumptions. Not the average of the optimistic and pessimistic cases: a separate, independently justified set of assumptions about costs, benefit realization, and timeline. The base case is the one the organization is committing to when it approves the investment.
Optimistic case. A coherent scenario in which things go better than the base case. Implementation runs on schedule, adoption is faster than expected, the benefit estimate turns out to be conservative. State explicitly what would have to be true about the world for this scenario to materialize, and note whether those conditions are within the organization's control.
Pessimistic case. A coherent scenario in which things go worse. Implementation is delayed by a quarter, adoption is slower, one of the major benefit assumptions is wrong. The same structure: what would have to be true, and what the outcome would be. If the pessimistic case produces a negative NPV, that is information the approving authority needs. It may still approve the investment, but it should do so knowing the downside.
The purpose of scenarios is not to bracket the future into three boxes. It's to make the range of plausible outcomes visible before the commitment is made, so that the decision includes the downside rather than implicitly assuming it won't arrive.
What to do when the case doesn't work
A business case that doesn't support the investment on its own terms is not a problem to be massaged. It is information. The options are: redesign the initiative to reduce cost or increase benefit, narrow the scope to what delivers positive returns, defer to a period when conditions are more favorable, or conclude that the investment isn't justified and say so clearly.
The option that is not available is adjusting the assumptions until the number comes out right. Not because that approach is dishonest, though it may be: because it produces a business case that was built to reach a predetermined conclusion, and those cases have a consistent track record of being right in the spreadsheet and wrong in production.
The executive summary should fit on one page, contain the three scenarios with their headline numbers, identify the two or three assumptions that matter most to the outcome, and state the recommendation clearly. The supporting model, with all assumptions visible and all calculations traceable, belongs in the appendix. A reviewer who trusts the summary should be able to verify it from the appendix without asking for anything not already in the document. That's what makes a business case defensible: not that it argues well, but that it shows its work.