A Useful Chunk
A big project rarely gets done in one move. There is not enough money, people, information, or any way to stop the current work until the new thing is finished.
In such cases a project is better split not simply into stages but into useful states. After each stage the system should already be able to do something.
A bad split looks like this:
1. tear down everything that exists;
2. spend several months building the new thing;
3. hope at the end that it works.
A good one looks like this:
1. launch a minimal working part;
2. test it;
3. migrate a small volume;
4. fix what turns up;
5. expand the system;
6. shut down the old one only after the new one is confirmed.
Sometimes an interim solution will have to be thrown away later. That is not necessarily a loss. Temporary scaffolding does not become pointless because it was removed once the building was finished.
The cost of an interim stage is justified if it:
- already delivers something useful;
- reduces risk;
- produces data;
- lets you stop without a catastrophe;
- keeps the existing system running;
- reveals an error before full scale.
Half-built things are dangerous precisely because they consume resources while producing no result yet. Ten almost-finished projects can create the impression of enormous activity and remarkably little benefit.
A small working result is usually worth more than a grand construction that will start paying off right after one more quarter, one more approval and a favourable alignment of the planets.
Interim usefulness matters especially when replacing a system in service: you cannot destroy the old thing merely because the new one has already been drawn up nicely.
All the windows can be taken out in a day. The new ones will be three weeks late. The old program can be switched off with a single decision. Then it turns out the new one cannot perform an operation “nobody uses any more,” apart from accounting, the warehouse and half the customers.
Until the replacement works, the old system is the insurance. It may be awkward, inefficient and a long-standing irritant to everyone involved. But its faults are known. The new solution’s faults still exist mainly in the future tense.
So where possible it is useful to replace gradually:
- one window;
- one section;
- one team;
- one data type;
- one function;
- one workflow.
Running two systems in parallel costs more. In exchange it lets you compare results and go back.
A full cutover is justified when a gradual one is impossible, when the old system is itself a hazard, or when the cost of running in parallel is unacceptable. But such a decision should be a deliberate risk, not a side effect of wanting to see a clear site sooner.
A kitchen gets rebuilt exactly this way, only rarely to plan. First the old units go out because they are in the way, and for three weeks the family washes up in the bathroom, heats food in a microwave on the windowsill and eats standing. That stage delivers nothing: it does not cook and it does not bring the new kitchen closer, but it does show how many operations rested on the old sink. The other sequence — assemble and connect the new units along a free wall, and take the old ones out after the first dinner is cooked — costs more and looks absurd for exactly the three days when both are standing in the kitchen.
The difference between these two renovations is not tidiness, it is who pays for the schedule. In the first case the family pays for the uncertainty, daily, with dinner on the windowsill. In the second the client pays, once, with money. That is usually cheaper.