The short answer
The risk in a long build is not that it fails technically. It is that you find out at the end that the requirements were wrong, having spent everything.
Getting a genuinely useful piece into real use early converts that into a series of small corrections.
How to choose the first phase
- Find the step causing the most pain today.
- Check it can be improved without everything else being built.
- Confirm it has a clear user who will actually use it.
- Make sure it works alongside the current process rather than replacing all of it.
- Keep it small enough to be live in months.
Point four is what makes early phases possible. New software running alongside existing process is normal and temporary, not a failure of design.
What early use tells you
| Discovery | Why it only appears in use |
|---|---|
| Missing cases | Nobody remembered them in a meeting |
| Wrong assumptions | Looked right on paper |
| Actual volumes | Estimates are usually wrong |
| Real workflow | People work differently than described |
| Where it is slow | Only visible with real data |
The fourth row is the most valuable. Watching people use the first phase reveals more about requirements than any amount of specification.
Do not phase into uselessness
A first phase so small that nobody adopts it teaches you nothing. It has to be genuinely better than what people do today, or they will carry on as before.
The test is whether users would be annoyed if you took it away. If not, it was not a real phase.
Plan the phases, commit to one
- Sketch the full direction so decisions are not made blind
- Detail only the next phase
- Reassess priorities after each one
- Expect later phases to change, and say so up front
- Keep each phase independently valuable
Detailing phase four in advance is wasted effort. What you learn in phases one and two will change it.