The head of the organisation wanted to change how the public dealt with it. What those changes would look like, and what implementing them would mean for the organisation, had yet to be worked out.
Before the project received formal approval, a colleague who knew the system and I spent more than six weeks reviewing every point where the public met the organisation, and what would have to change behind each one.
The most important document we produced came before the business case. It was the impact document.
That analysis identified three options: the minimum, the middle and the full. It established the assumptions behind each and gave us a basis for understanding what the organisation would commit to.
The business case set out the investment decision, using what the impact analysis had established.
There was no project brief. The head of the organisation had already set the direction, so the need was established. In a small organisation, the business case was the logical next step.
The same work informed the design document. The design was complete enough that the programmers used it as their specification. And it informed the testing documents as well.
The people who approved, built and tested the system all worked from that one piece of work.
What Agile actually said
Today, admitting you wrote a complete design document can sound like a confession. Agile is supposed to have settled that.
The Agile Manifesto (2001) values “Working software over comprehensive documentation”. But it also says, “while there is value in the items on the right, we value the items on the left more”.
Documents still had value. Working software came first.
Nor was the Manifesto written to answer the question that comes first: should the organisation spend the money at all?
The frameworks built for larger organisations put that question into their processes. SAFe calls for a lean business case for large initiatives. PRINCE2 Agile retains continued business justification as a principle.
The investment decision hasn’t disappeared. Nor has the need to establish what the organisation is buying.
Where Agile is right
In The best business case he’d seen, I described the question that exposed a gap in our design: what happens when the user hits this key?
The answer was “We don’t know.”
The fix came from asking the people who were doing the work, not from the document.
The people mattered more than the paper. A document can be beautifully written and still describe something that won’t work. It can freeze the wrong answer. And it can go stale as the organisation changes.
An organisation chart is a map older than the ground.
Agile is right to challenge the assumption that writing something down makes it correct, or that a design should remain unchanged simply because somebody approved it.
The answer is to make the documents part of how we learn.
Iterate on paper first
Bent Flyvbjerg and Dan Gardner, in How Big Things Get Done (2023), put it in four words: “Think slow, act fast.”
Planning is cheap. Delivery is expensive. Do as much of the learning as you reasonably can before mistakes become costly.
A draft is a straw man. It can be quickly rejected, tested against the work people actually do, or used to identify what still needs to be investigated.
Sometimes the next step is another draft. Sometimes it’s talking to an operator, building a prototype or checking an assumption against what happens in practice.
The new information goes back in, and another draft comes out.
That’s iteration too.
Our impact analysis worked that way; no methodology asked for those six weeks. We spent them finding out what would have to change.
It gave the people approving the investment something to challenge, and the people building the system something to work from.
What a reviewer can ask
Is there an impact analysis behind the business case, or only a cost?
Were options considered, and are their assumptions written down?
Is there enough evidence for the people approving the investment to understand what they’re committing to?
Do the people delivering the project know what has been established, what remains uncertain and what they need to learn next?
Is the document being treated as a draft to argue over, or as something finished because it has been approved?
These questions matter whether the delivery team uses Agile, waterfall or something in between.
Write down what you know so others can challenge it, build on it and be held to it. Then keep rewriting it as you learn.
Want more like this? Rick writes about the go/no-go decision: for the people who assess business cases, and the founders who have to make them.
All writing