Project phases: when to start one, not a new project

Every long-running delivery reaches the same fork. The original scope is done, the next tranche is funded, and someone asks the question: do we carry on in the same project, or raise a new one?
Both answers are wrong most of the time. Carrying on buries the achievement of the first tranche under an ever-growing plan. Raising a new project throws away the history, the lessons and the stakeholder context that made the first tranche work. The answer is a phase.
Table of contents
- What a project phase is
- Phase or new project? A decision test
- What a phase should reset
- What a phase must keep
- Reporting across phases
- Common mistakes
- Frequently asked questions
What a project phase is
A phase is a bounded tranche of delivery inside a continuing initiative. It has its own scope, plan, budget envelope, milestones and closure. It shares the initiative's identity, its stakeholder map and its accumulated record.
Think of a programme of work to replace a finance system. Phase one is discovery and vendor selection. Phase two is core implementation. Phase three is rollout to overseas entities. Same initiative, same sponsor, same benefit case, three very different plans.
Phase or new project? A decision test
Use a new phase when:
- The sponsor and benefit case stay the same.
- The stakeholder map is broadly unchanged.
- The next tranche depends on what the previous one produced.
- You want the history visible in one place at closure.
Raise a new project when:
- Funding comes from a different budget with a different owner.
- The benefit case is genuinely separate and will be measured separately.
- Delivery is handed to a different team with a different governance route.
If two of those new-project conditions are true, split it. Otherwise a phase will serve you better and cost far less administration.
What a phase should reset
The point of a phase is a clean slate for the things that should be time-bounded:
- The plan. New milestones, new tasks, new baseline. The previous plan is archived, not deleted.
- The status narrative. RAG restarts from the new baseline. Carrying a red from a closed tranche into a fresh one tells the board nothing useful.
- The log. New decisions and actions belong to the phase, so closure reporting is honest.
- Progress. Percentage complete is meaningless if it spans tranches with different scopes.
What a phase must keep
Equally important is what carries forward:
- Open RAID items. A risk that is still live does not stop being live because a tranche closed. Migrate the open items, close the ones that expired with the scope, and record why.
- Lessons. The reason phases beat new projects is that the lessons from tranche one are exactly the lessons tranche two needs.
- Stakeholders and access. Same people, same permissions, no re-onboarding.
- The audit trail. Every decision and change from earlier tranches stays available, in context.
In Pocket PMO, starting a phase renames the project to reflect the current tranche, resets the plan and logs, migrates open RAID, and keeps the full history one toggle away. The AI can also draft the next phase plan from the previous tranche's outcomes and open items, which you then review and edit before anything is saved.
Reporting across phases
The reporting rule is simple: default to the current phase, allow the full initiative on request.
Sponsors want to know how this tranche is tracking. Boards occasionally want the whole story. A snapshot that quietly mixes the two produces the worst of both, a RAG that reflects a closed tranche and a milestone list nobody recognises.
Make the phase explicit in the report title, and offer an all-phases view as a deliberate choice rather than the default.
Common mistakes
- Never closing the previous phase. Closure is what makes the record honest. Do the closure report even if the next tranche starts the same week.
- Migrating everything. Open RAID migrates. Closed items stay closed. Do not drag a graveyard into the new plan.
- Renaming nothing. If the header still says the original project name, everyone reports against the wrong scope.
- Rebaselining silently. Record the new baseline as a decision, with the reason. Boards forgive a rebaseline, they do not forgive discovering one.
Related reading
- The complete guide to RAID reporting
- What is project governance? Frameworks and strategies
- Lessons learned that actually get used
- Project status report: AI-drafted in one click
Frequently asked questions
What is the difference between a project phase and a stage gate?
A stage gate is a decision point inside a plan. A phase is a bounded tranche of delivery with its own plan, budget and closure. A phase usually contains several stage gates.
Should a new phase get a new budget?
Usually yes. A phase is the natural unit for a funding envelope, which is part of why it is a cleaner boundary than simply extending the plan.
What happens to open risks when a phase closes?
Migrate anything still live to the new phase, and close anything that expired with the previous scope, recording the reason. Never let an open risk disappear because the tranche ended.
Does a phase need its own closure report?
Yes. Phase closure is where the benefit claims, the lessons and the final position get recorded while people still remember them.
