A Business Case That Held Up When the Questions Got Hard
The following is a composite drawn from projects we have seen; names and details are invented. A mid-sized public agency wanted to replace an aging records system. Two teams, a year apart, brought essentially the same proposal to the same approval board. The first was sent back. The second was approved in one sitting. The technology was identical. What differed was the business case behind it.
The first attempt
The first business case was confident and thin. It led with a number — a large annual saving — and a vendor's glossy estimate of payback. When a board member asked where the saving came from, the answer was a wave at "efficiency." When another asked what would happen if the rollout slipped, as so many had during the disruptions of the previous year, there was no answer prepared. The case assumed the best of every variable at once, and the board could feel it. They did not reject the idea; they rejected the case for it, and asked the team to come back with something they could defend.
What the second team did differently
The second team treated the business case as an argument that had to survive a hostile reading, not a sales document. The structure was unglamorous and that was the point.
They named the problem before the solution. One page on what the old system was costing in real terms — staff hours, error rates, a compliance risk — so the project had a reason to exist independent of the product.
They showed the options, including doing nothing. A credible case compares alternatives. "Do nothing" and "do the minimum" were costed honestly, which made the recommended option look chosen rather than assumed.
They tied every benefit to an owner and a measure. Each claimed saving had a name beside it — the manager who would be accountable for realizing it — and a way it would be measured after go-live.
They built in ranges and sensitivities. Instead of one heroic forecast, they showed a likely case, a cautious case, and what had to be true for each. Remote delivery and supply delays were named as risks, not ignored.
Why the second case survived
The board's job is to find the weak point in an argument before money is committed. The first case gave them a single number to attack and nothing behind it. The second case had already done that attacking itself: every figure was traceable, every benefit had an owner, and the risks were on the table instead of hidden. A reviewer who tried to poke a hole found that the team had been there first. That is what "surviving scrutiny" actually means — not that no one questions the case, but that the questions have answers.
The lesson generalizes well beyond records systems. A business case is not a pitch you win once; it is a promise you will be held to. Write it so that the person most skeptical of the project would still recognize it as honest, and you will spend far less time defending it and far more time delivering.
If you are preparing a case that has to clear a tough board, XNM's program & project delivery advisory can help you build one that holds up under the questions that matter.