How Do You Write a Business Case Stakeholders Actually Read?

Somewhere in most organisations there is a business case sitting at forty-odd pages, built carefully over several weeks, that a sponsor will open in a committee meeting and read for ninety seconds before asking a question the document technically answers on page thirty-one. The project manager who wrote it will feel, not unreasonably, a flash of frustration. The analysis was there. The options were weighted properly. The benefits were mapped against strategic objectives with genuine care. And still the conversation in the room starts from confusion rather than confidence.

This is not a rare failure. It is close to the default outcome for business cases written the conventional way, and it has very little to do with the quality of the thinking inside them.

The instinct, when a business case lands badly, is to assume the fix is more rigour. Tighter benefits realisation logic. A cleaner options appraisal. Another round of stakeholder consultation folded into the strategic case. Sometimes that instinct is right. More often it produces a document that is more defensible and no more readable, because the actual problem was never depth. It was sequence.

A business case is usually built in the order the analysis happened: strategic context first, then the case for change, then the options considered, then the preferred option, then costs, then benefits, then risk, then management arrangements. That is a sound order for building an argument. It is close to the wrong order for a sponsor reading one, because a sponsor rarely opens the document holding the question "is this strategically justified." They open it holding a much narrower question, usually some version of "what will this cost me, what do I get back, and what happens if it goes wrong." Everything else in the document exists to support an answer they are trying to find on page one, and in a document built the conventional way, that answer is often thirty pages away.

A composite example makes the pattern easier to see than any abstract description of it. A programme manager working across two capital projects submitted a business case that had taken several weeks to build, structured cleanly against the Five Case Model, with a strategic case that ran to nine pages before a single figure appeared. The sponsor, reading it the night before committee, got as far as the second page and stopped, then arrived the next morning having formed his own version of the ask from a two-line summary someone else had circulated, not from the document itself. The meeting spent its first fifteen minutes on a cost question the business case answered clearly, just forty pages later than the sponsor had patience for. Nothing in the case was wrong. The order in which it revealed itself was.

Writing a business case stakeholders actually read means treating sequence as a design decision rather than a byproduct of how the analysis was assembled. The reader's real question, whatever it happens to be for that particular sponsor and that particular ask, needs to be answerable within the first page, not proven across the whole document. That does not mean skipping the strategic case, the options appraisal, or the benefits management arrangements. It means moving the headline answer to the front and treating everything that follows as the evidence for a conclusion the reader has already been given, rather than a slow build toward a conclusion they are made to wait for.

In practice this looks like a short summary, no more than a page, that states the ask, the cost, the expected return, and the principal risk in plain terms before the reader reaches a single section header. It looks like costs and benefits appearing near the front rather than buried past the halfway point, because for most readers those two figures are the actual decision, not supporting detail for one. It looks like moving the fuller options analysis, the detailed risk register, and the governance arrangements into appendices the reader can go to if they want depth, rather than forcing them through that depth before they are allowed to reach the point. None of this weakens the discipline behind the Five Case Model. It simply stops asking the reader to walk through the model in the order it was built, and lets them walk through it in the order they think.

A business case is not, in the end, a record of how carefully you worked. It is an instrument built to help someone make a decision they will have to stand behind afterward, often in a room, often under time pressure, often having read less of it than you hoped. Writing it in the order they think, rather than the order you built it, is not a concession to a busy reader. It is the difference between a document that gets filed and one that gets acted on. If you're working through how to make a business case, a risk register or a benefits case actually land with the people who have to sign off on them, get in touch about business case and benefits training.

Andre Malowney is a project management trainer accredited across PMI, APMG, APM and PeopleCert frameworks, working with both traditional plan-driven practitioners and Agile delivery teams. Find him on LinkedIn: www.linkedin.com/in/andremalowney.