The same document comes past every year. Sixty pages, nicely laid out, with a functional description of everything the new system has to do. People who meant well spent months on it. And it is wrong.

That is not a reproach. It cannot be right, because it was written by people who did not yet know what they would only learn once someone actually used the system.

Why a list of requirements misleads

A requirements list feels like certainty. You wrote it down, everyone read it, there are signatures under it. But what it contains are assumptions in the imperative. "The planner must be able to merge trips" sounds like a fact. It is a guess about how someone will work later.

We only meet that guess once it is built. Then it turns out the planner does merge trips, but always based on something that appears nowhere in the system: one of the drivers has a key to that one distribution centre. Nobody wrote that down, because everybody already knew.

What we do instead

We build the smallest piece that delivers something on its own, put it into use and watch what happens. Usually within a few weeks. Not because it is finished then, but because that is the first moment you get real information instead of opinions.

What that buys you:

  • You see after three weeks whether it works instead of after nine months.
  • You do not pay for features nobody ends up using. Every system we take over has a corner nobody has clicked in two years.
  • When it goes wrong, a small piece goes wrong. That is repairable without a crisis meeting.

"But then I do not know what it costs"

This is the real objection, and it is a fair one. A budget wants a number, and a series of small amounts is harder to sell than one large amount with a date under it.

Except: that one large amount was not right either. Of all software projects that overrun, the fully specified ones are the champions. You did not buy certainty, you postponed the moment you find out.

What we do is price each piece and say where the uncertainty sits. An integration between two systems can be estimated fairly precisely. A planning module with seven exceptions in it cannot, and then we say so.

When a big plan is genuinely needed

When external parties are attached to it who need a date. A migration where an old contract expires, an integration with a supplier who has to build as well, an audit that has to be passed by a certain moment.

Then we plan ahead, still in pieces that can stand alone. The difference is not whether you think about the future. The difference is whether anyone sees anything in the first year.