Costs vs. benefits: laying them out honestly
The numbers section is where business cases are won or lost. Decision-makers are trained to look for what you left out. A case with modest numbers that shows its working will beat a case with dazzling numbers that hides it — every time. Here is how to present costs and benefits so they hold up under scrutiny.
Capture the full cost, not just the purchase price
The most common failure in a business case is an incomplete cost picture. When you list costs, include:
- Direct costs: software licenses, equipment, contractor fees, materials — the line items with invoices attached.
- Implementation costs: setup, configuration, data migration, integration work. These are routinely underestimated.
- People costs: the hours your own staff will spend, including training time and the learning curve. Internal time is not free — it displaces other work.
- Ongoing costs: annual renewals, maintenance, support contracts, consumables. A proposal that costs X once and Y every year must say so.
- Change costs: communication, process redesign, temporary productivity dips while people adapt.
If an approver discovers a cost you omitted, they will assume there are more. If you volunteer the uncomfortable costs yourself, they will trust the rest of your numbers.
Compare over the same time horizon
Costs and benefits must cover the same period, or the comparison is meaningless. A three-year view is the most common default for internal projects: long enough to show ongoing benefits, short enough that estimates stay credible. State your horizon explicitly at the top of the section — "all figures below cover three years" — and apply it consistently to every option, including do-nothing.
Show your assumptions
Every number in a business case rests on assumptions. Write them down. "Assumes the team spends roughly two hours per week on manual reconciliation, based on the support lead's estimate" is honest and checkable. Unexplained precision — a benefit stated as $48,273 per year with no basis — invites suspicion, not confidence. Round your figures, label estimates as estimates, and keep the detailed workings in an appendix.
Treat benefits with the same rigor as costs
Benefits fall into two categories, and you should keep them clearly separated:
- Quantified benefits: time saved, errors reduced, capacity freed, revenue enabled. Each should connect to a stated problem and be traceable to an assumption.
- Qualitative benefits: better morale, lower risk, improved customer experience, strategic positioning. Real, but harder to measure — present them as supporting arguments, not as the financial justification.
Watch for double-counting: the same saved hour cannot be both "productivity gain" and "overtime avoided." And be careful with soft savings — "time saved" only becomes money if that time is actually redeployed or if overtime is genuinely reduced.
Consider: a generic example of a table that works
A simple comparison table often does more persuading than paragraphs of prose. Imagine a proposal to automate a manual reporting process. The table might look like this (figures are illustrative, not a real case):
| Do nothing (3 yrs) | Automate (3 yrs) | |
|---|---|---|
| Staff time on manual reports | High (ongoing) | Low (after setup) |
| Tool cost | $0 | License + setup |
| Ongoing maintenance | $0 | Annual renewal |
| Error rate in reports | Current level | Reduced |
The point of the table is not the specific numbers — it is that every option is measured on the same rows, over the same horizon, with costs and benefits side by side. An approver can see the trade-offs at a glance.
Common number traps to avoid
- Sunk costs in the comparison: money already spent should not influence the decision going forward. Compare future costs to future benefits.
- Ignoring the cost of delay: if doing nothing has a growing cost (a problem getting worse, a deadline approaching), say so — it is part of the baseline.
- Best-case benefits with worst-case costs: if you are optimistic about the upside, be equally honest about the downside. Better: show a conservative case and note what the upside scenario looks like.
- Inflated precision: "approximately $50,000 per year" is more credible than "$51,340" when the inputs are estimates.
The honesty test
Before you submit, ask yourself one question: if the approver funded this and the numbers came in worse than projected, would you still be comfortable defending the case? If the answer is yes — because your assumptions were reasonable and your costs were complete — the numbers will survive scrutiny. If the answer is no, the weak spot you are worried about is exactly where the approver will probe.