The short answer
Phase when each release is useful to somebody on its own. If phase one has no users until phase three arrives, you have split the project without reducing the risk, and you have added the cost of running two versions.
The benefit of phasing is feedback and reduced blast radius. Both need real users on the earlier phases.
What phasing actually buys
- Feedback while there is still budget to act on it
- A smaller thing to go wrong on any given day
- Value arriving before the end of the project
- A decision point where you can stop or change direction
- Real usage data rather than opinion about what matters next
The fourth is the one that justifies it commercially. A project that can be stopped after phase one with something useful delivered is a different risk from one that produces nothing until the end.
Where big bang is the honest answer
| Situation | Why phasing struggles |
|---|---|
| Replacing a system that must switch wholesale | Two systems of record is worse than either |
| Regulatory change with a fixed date | Partial compliance is not compliance |
| Data model change affecting everything | Hard to split without migrating twice |
| Small project, few weeks | Coordination cost exceeds the benefit |
Where one of these applies, phasing is not automatically wrong, but it needs to be done on a technical axis rather than a feature one: build it all, release behind a switch, and cut over once.
Slicing well
- Slice by user journey rather than by layer. A thin end-to-end path beats a finished database with no interface.
- Make each slice releasable, even to a small group.
- Put the riskiest thing in the first slice, not the easiest.
- Keep each slice short enough that feedback arrives while it is still relevant.
- Agree what would make you stop after each one.
Point three is the one teams get backwards. Starting with the easy parts feels productive and leaves the uncertainty until the budget is spent.
The cost of phasing
It is not free. Each release has testing, deployment and communication overhead. Running old and new in parallel costs money and creates reconciliation work. Users experience change repeatedly rather than once.
Where the phases are small, that overhead can exceed the benefit. The judgement is whether the feedback and risk reduction are worth the repetition.
Pilot groups
A middle path: build it fully but release to a small group first. You get real feedback and a limited blast radius without splitting the build.
It works well where the software replaces something people already do, because the pilot group can fall back. It works less well where there is no fallback.