How to Build Project Phases That Hold Under Delivery Pressure

Project plans at most services firms have a predictable failure pattern: they look clean at kickoff and fall apart by week 4.

The usual diagnosis is “execution issues.” The actual problem is usually upstream: the phase structure was never realistic in the first place.

Phases that hold under delivery pressure have specific characteristics. They're condition-driven, not date-driven. They have entry and exit criteria, not just milestones. They're owned by named people, not by teams. And they flex around surprises rather than breaking under them.

This is our POV on how to structure project phases that actually survive contact with delivery.

Date-driven phases break

The most common phase structure is a Gantt chart with dates: Discovery March 1–15, Design March 16–April 5, Build April 6–May 3.

This looks clean and accomplishes almost nothing.

The problem is that dates don't describe what's actually supposed to happen in each phase. They just describe when it should have happened. When something slips — and something always slips — the dates are meaningless because the phase can't actually end without the work being done.

Teams either declare the phase complete by moving on anyway (accumulating technical debt in the project), or they extend dates and act like the plan is still intact (accumulating drift).

Either way, the phase structure stopped doing its job around week 3.

Condition-driven phases hold

Phases that hold define what has to be true to exit the phase, not when the phase ends.

“Discovery is complete when we have signed-off requirements, identified risks, and a staffing plan for Design.”

“Design is complete when approved deliverables exist for each requirement, dependencies are mapped, and Build has a detailed work breakdown.”

“Build is complete when all requirements are implemented, internal QA has passed, and client UAT is scheduled.”

These criteria don't care what the date is. They care what's been accomplished. A phase can end early (rare) or late (common), but it ends when the work is actually done, not when the calendar says so.

This changes the conversation when a phase is running behind. Instead of “we're 2 weeks late on Discovery,” the conversation becomes “Discovery's exit criteria aren't met — what do we need to finish to get there?”

The first version is a blame conversation. The second is a work conversation.

Entry criteria matter as much as exit criteria

Exit criteria get most of the attention. Entry criteria are where projects actually go wrong.

A project that starts Design without signed-off Discovery requirements is going to rework Design later. A project that starts Build without approved Design is going to build the wrong thing. A project that starts UAT without completed Build is going to embarrass everyone.

Each phase should have explicit entry criteria: what must be true before this phase can begin? If those criteria aren't met, the phase doesn't start — or the project goes back to finish the previous one.

This feels pedantic until you've seen the consequences of skipping it. Most rework on services projects comes from phases that started before they should have.

Five to six phases, not three or eight

Three-phase projects (Plan, Build, Deliver) don't give you enough checkpoints to catch drift. Eight-phase projects are overhead for their own sake.

The practical sweet spot is five or six:

1. Kickoff: alignment, objectives, team, plan agreement.
2. Discovery: requirements, research, risks, staffing.
3. Design: deliverable specifications, dependencies mapped.
4. Build: implementation of designs.
5. Delivery: QA, UAT, deployment, handover.
6. Close: retrospective, documentation, relationship transition.

Each phase is a few weeks. Each has entry and exit criteria. Each has a named owner.

Some projects need fewer phases (a 4-week sprint collapses Discovery and Design). Some need more (complex implementations add integration and rollout phases). But five or six is a good default.

Named owners beat team owners

“Design is owned by the delivery team” means nobody owns design.

Each phase needs one specific person whose name goes next to it. That person isn't necessarily doing the work — but they're the one who decides when the phase is complete, who surfaces issues, and who makes the go/no-go call on phase exit.

When a phase is owned by a role (“the project manager”) rather than a person (“Sarah”), decisions defuse across the team and nobody's accountable for them.

Two rules on phase ownership:

• One name per phase.
• Named owners have authority to pause their phase if entry or exit criteria aren't met.

Without the second rule, owners become reporters rather than decision-makers.

Phases need to flex, not break

Real delivery is messy. Scope shifts. Staff gets pulled. Dependencies drag. The question isn't whether a plan will be disturbed — it's whether the plan flexes intelligently when it is.

Plans that flex have three properties:

1. Buffer time built into each phase. Not at the end of the project (that gets consumed first) but inside each phase (which forces the team to confront slip as it happens).
2. Explicit “what gets cut” options. For each phase, what's the descope plan if we're running behind? This conversation has to happen at kickoff, not at week 6.
3. Clear escalation triggers. If a phase is 20% over plan, who's notified and what decision gets made?

Plans that don't flex break. And a broken plan produces a project that nobody trusts the plan of anymore — which is how project drift compounds from week 3 onward.

The three moves

If your project phase structure isn't holding:

1. Rewrite phase definitions around condition-driven entry and exit criteria.
2. Name one owner per phase with authority to pause.
3. Build explicit descope options into the plan, not the project.

Firms that do this see projects drift less, rework less, and deliver closer to plan. Not because their people are better, but because their plans can actually survive what real delivery throws at them.

A plan that can't flex is a wish. A phase structure that holds is infrastructure.

Octayne's Project Management tracks phase entry and exit criteria, named owners, and flex triggers so project plans actually hold under delivery pressure. Book a demo to see phase-based project management live on your data.