Every implementation reaches moments where a decision is hard, a requirement is messy, or scope is under pressure. And there is a sentence that resolves all of them, instantly and comfortably: we will handle that in Phase 2. It ends the difficult conversation, it keeps Phase 1 on schedule, and it feels responsible, like prioritisation. In our opinion it is usually the opposite. It is the project agreeing to ship a known problem.
What "Phase 2" actually means in the moment
When something is moved to Phase 2, it is worth being honest about what just happened. A decision that needed to be made was not made. A piece of scope that was real was set aside. And the reason was not that it is genuinely a later concern; the reason was that it is hard, or contested, or inconvenient now. "Phase 2" is doing the work of "not now, and please stop asking." It converts an unsolved problem into a scheduling item, which makes it feel solved when it is only postponed.
Why Phase 2 rarely arrives
The deferral assumes Phase 2 is a real, funded thing that will happen. Often it is not:
- Phase 1 consumes the budget and the goodwill. By the time Phase 1 is live, the appetite, and frequently the funding, for a second project is gone.
- The deferred items were the hard ones. Phase 2 inherits, by construction, everything that was too difficult for Phase 1. It is not a fresh start; it is a backlog of the worst problems, which makes it expensive to quote and easy to keep postponing.
- It becomes a negotiation, not a project. Phase 2 gets re-scoped, re-quoted, and re-argued, often as if it were new work rather than deferred work. It can sit in that negotiation indefinitely.
Meanwhile the system is live. The problem that was supposed to be fixed in Phase 2 is now in production, being worked around by the people who use it every day.
The deferrals that are legitimate
This is not an argument against phasing. Phasing is sound, and a genuine Phase 2, a real next set of capabilities, planned and architected for, is good practice. The trap is specifically the use of Phase 2 as a place to put things that are not later work but unwanted work. The test is simple: is this being deferred because it genuinely belongs in a later stage, or because it is hard and deferring it ends an uncomfortable meeting. The first is planning. The second is the trap.
The position, stated plainly
When "Phase 2" is proposed, push on it once. Ask whether the thing being deferred is later work or just hard work, and ask what happens, in production, if Phase 2 never comes, because it might not. A problem deferred to a phase that never arrives was not deferred. It was shipped, quietly, with everyone's agreement not to look at it.