Project Phases: Useful Structure or False Comfort?
Most project plans arrive with their phases already drawn. Four or five coloured bands across the top of the schedule, named for the work that happens inside them, inherited from the last programme or from a template that predates everyone currently on the project. The phases feel like structure and the boundaries between them feel like control. Whether they provide either depends on what can be decided at the line that could not be decided on either side of it.
A phase boundary earns its place when it creates a genuine decision point. If the only thing that happens there is a change of label on the status report, the structure is doing no work, and it may be doing harm by suggesting a degree of control nobody actually holds.
What a phase boundary is supposed to do
Phases divide a project into stages that can be planned, funded, staffed and reviewed with some independence from each other. Section 4.1 of The Standard for Project Management treats them as a structuring choice that can support governance, funding decisions, technical progression, risk management or a logical delivery sequence, and it makes no assumption that every project uses the same structure. The practical implication is that phases should follow from what the project needs to decide and when, not from the order in which the activities happen to occur.
Funding is the most common reason for a boundary. An organisation releases money in tranches because the next commitment is large enough that somebody wants to see evidence before making it. The boundary exists to hold that evidence and to make the release of the next tranche a visible act.
Authority provides a second reason. Some decisions sit above the project: entering a market, accepting a regulatory position, committing an operational division to a change in how it works. Those decisions need people who are not in the project's weekly rhythm, and a phase boundary is a scheduled appointment with their attention.
Irreversibility gives the third and the one most often missed. Projects contain moments where a choice becomes expensive or impossible to undo: a data model that everything downstream will assume, a supplier appointed for four years, a foundation poured, a notice period served. A boundary placed just before one of those moments is worth the preparation it costs, because a decision genuinely exists there. Risk reduction works the same way in reverse, with a pilot, prototype or survey scheduled so that the most uncertain thing is resolved before the largest commitment is made.
The test that separates a working boundary from a decorative one is simple enough to apply to any plan. Ask what would happen if the answer at that point were no. If nobody can describe it, the project does not have a gate there.
When the gate arrives after the decision
A housing association replacing its repairs scheduling system had the familiar five phases and a formal go/no-go review before deployment. By the time the review took place, the contact centre had been retrained on the new screens, the incumbent supplier had been served notice that expired in seven weeks, and two years of historic job data had been migrated and reconciled twice. The review ran for ninety minutes, the pack was well written, and the sponsor signed it.
Nothing about the meeting was wrong except its position. The decision it appeared to make had been taken eleven weeks earlier, when the notice was served and the only remaining route back involved negotiating a new contract with a supplier who now knew exactly how much leverage they had.
The boundary had been placed where the delivery work changed instead of where the project's reversibility changed. On a building project those are often the same point, which is partly why the convention persists. On a system replacement with an operational cutover they usually are not, because the commercial and operational commitments run ahead of the technical ones.
The repair is not another gate. It is moving the one that matters to the week the notice decision is made, and giving it a pack that answers the questions live at that moment: whether the data has been proven at volume, whether the contact centre can work both ways for a period, what the fallback costs and how long it stays available. The pre-deployment review can stay where it is, as long as everyone calls it a readiness confirmation. Naming a checkpoint accurately costs nothing and removes most of the false comfort in one go.
Phases when the delivery is iterative
Teams working in short cycles sometimes conclude they have no phases, because nothing on the wall is called one. Iteration boundaries and phase boundaries answer different questions. An iteration boundary asks what the team should do next and what the last cycle taught. A phase boundary asks whether this work should continue at all, on whose authority, and with what money behind it.
Adaptive delivery has those moments even when it does not name them. The first public release, the point at which an architecture becomes load-bearing for everything after it, the end of a funding round, the decision to take a product into a second market or a second region. Initiating work recurs around them: scope, authority, stakeholder set and assumptions are all re-established, and pretending otherwise usually means the re-establishing happens informally and unevenly.
Hybrid delivery makes the distinction easier to see, because the fixed points are visible. A regulated programme may face immovable external dates: a submission window, an audit, a seasonal shutdown, a licence condition. Those are real phase boundaries, since something outside the project changes state at them regardless of how the team feels about progress. The iterative work then arranges itself to produce the evidence each boundary needs, which is a very different planning problem from spreading a predictive schedule over sprints.
How much phase structure a project actually needs
More boundaries are not safer. Each one costs preparation time, senior attention and a week or two of decision latency while diaries are found, and a gate that nobody has ever failed teaches the organisation that gates are administrative. Two well-placed boundaries on a nine-month project will do more than six placed where the workstreams happen to change shape.
Four questions usually settle it. What becomes hard to undo on this project, and roughly when. Who holds the authority to stop it, and will that person be in the room. What evidence would actually change their mind, as opposed to what evidence is easy to produce. And what the project does on the Monday after a no. Working these through against other people's projects is considerably easier than working them through against your own, which is one of the more useful things structured PMP® exam preparation provides: a supply of situations shaped nothing like the ones you already know how to handle.
For a PMP candidate, phases tend to appear inside scenarios instead of as a definition to recall. The 2026 Examination Content Outline spreads predictive, adaptive and hybrid approaches throughout all three of its domains, and recommending a development approach sits inside the process domain's planning task. A scenario that mentions a phase or a gate is usually testing whether the mechanism fits the situation, not whether the label can be identified.
On a live project the return comes from moving one boundary rather than redesigning the life cycle. Take the next gate in your plan and list what will already be irreversible by the time it happens. If most of the list is already committed, the meeting is a report, and the decision it claims to make is sitting somewhere earlier in the schedule with nobody watching it.
Interested in going further?
Placing a boundary where the reversibility changes is a judgement that has to be made in a specific project context, and it is the kind of reasoning the PMP exam tests through scenarios rather than definitions. Omega's preparation works through phase, gate and development-approach decisions in predictive, adaptive and hybrid settings.
The treatment of project phases and development approaches in the PMBOK® Guide Eighth Edition, which is published with The Standard for Project Management, is the underlying reference for this article.
Ad · Amazon affiliate link.
References
A007: The Standard for Project Management vs the PMBOK Guide
A020: Matrix, Functional or Projectised? How Structure Changes the PM’s Job
A057: How to Recognise Predictive, Agile and Hybrid PMP Scenarios
A066: How Project Characteristics Shape the Delivery Approach
A059: Hybrid Project Management Explained for Traditional Project Managers
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
