How do you build a robust decision brief for modernisation?

Many modernisation efforts fail neither on the technology nor on the budget, but because nobody can justify them internally. Everyone involved agrees something has to happen — but the paper you would take into a decision meeting does not hold.

What a decision brief has to do

It has to answer four questions that come up in every decision meeting:

What happens if we do nothing? Without this answer the effort competes with every other effort that lacks urgency — and loses.

Why exactly this scope? Present one option and you will be asked why not more or less. Present three options and explain why one is recommended, and the question is answered in advance.

What does it cost, and where does that come from? A number without a traceable derivation gets doubted. A number with stated assumptions gets discussed — which is the better state.

Who owns it in the business? An effort without a named business owner reads as an IT effort and is prioritised accordingly.

What is usually missing

In practice it is rarely the technical detail that is missing. What is missing is the link between the technical state and the business consequence.

“The platform is no longer supported” is a technical statement. “After that date we can no longer safely roll out changes to the pricing logic, and the department head would have to sign off approvals by hand” is a business one. Both describe the same situation. Only the second can be decided on.

A structure that supports a robust decision

A paper that survives internally usually follows the same structure:

1. The situation in one paragraph — what the process delivers and what no longer holds.
2. Cause, not symptom — what the actual problem is, separated from its effects.
3. Risks with timing — what happens when, if nothing is done.
4. Target state — how the business process and the application should work together in future.
5. Options with assessment — benefit, effort, risk and internal viability for each option.
6. A recommendation with reasoning — a clear statement, not a menu.
7. The next step with scope — what concretely would be commissioned first.

These seven points fit on a few pages. Length is not a quality signal; traceability is.

Why this comes before delivery

Such a paper cannot be written retroactively. It is the result of a clarification — and that clarification is the same step that keeps the delivery from missing the actual problem.

With it, you can let the organisation decide. Without it, the discussion stays about technology.