A phase gate is a formal decision checkpoint between phases of a project or organizational process, at which progress is evaluated against defined criteria before work in the next phase is authorized.
The gate is not a review in the sense of feedback and suggestions. It is a binary decision point: the criteria are either met or they are not, and the work either proceeds or it does not. That binary structure is the functional core of the mechanism. Remove it — make the gate advisory, make the criteria open to interpretation, allow the gate to pass with conditions — and you have a milestone, not a gate.
What a Phase Gate Contains
A well-designed phase gate has three components that must all be present for the mechanism to work.
Defined, evaluable criteria. Each criterion in the gate should be assessable with evidence, not judgment. "The architecture is well-designed" is not a phase gate criterion; it is an opinion. "The database schema is documented, reviewed by a second engineer, and confirmed to support all user stories in the current sprint backlog" is a phase gate criterion. The distinction matters because criteria that cannot be evaluated objectively will be evaluated by whoever is most motivated to advance the project — which is usually the project team, which is usually not independent.
A decision with authority. A phase gate is not a recommendation. It requires a decision-maker who has the authority to hold the gate — to say "this does not pass" — and who is not the same person who is most motivated to pass it. Gate authority that does not include the genuine ability to fail a gate is gate theater. The most common failure mode in phase gate implementation is placing gate authority with someone who has no practical capacity to fail a gate because of role, incentive, or relationship.
A clear outcome. Pass or fail. Not "conditional pass" or "pass with action items." Conditional passes are fails with extra paperwork — they allow the work to advance before the gate criteria are met, which is exactly what the gate was designed to prevent. If a gate cannot be evaluated as pass or fail, the criteria need to be rewritten.
What It Is Not
A phase gate is not a milestone. Milestones mark progress — the completion of a deliverable, the end of a period, the reaching of a target. They are informational. A milestone does not authorize the next phase of work; it records that something has been completed. A project can have a milestone at the end of architecture and a phase gate at the end of architecture, and they serve entirely different functions. The milestone says "architecture is done." The gate asks "is it done well enough to begin building?"
A phase gate is not a review. Reviews produce feedback. They may be valuable, they may improve the work, but they do not produce a binding decision about whether work proceeds. A design review that generates twelve comments and concludes with "thanks, team, let's incorporate this feedback as we move forward" is a review, not a gate. A gate that produces twelve failing criteria and concludes with "the work proceeds to implementation when these twelve criteria are met and verified" is a gate.
A phase gate is not a sign-off or approval. Approvals authorize specific actions — a budget expenditure, a contract, a personnel decision. A phase gate authorizes an entire next phase of work and requires that the previous phase meet defined standards before that authorization is granted. The scope is different.
A Concrete Example
A software team is building a new platform. They have defined a phase gate at the end of the architecture phase, before implementation begins. The gate has six criteria:
- Database schema documented and reviewed by a second engineer
- All API contracts defined with input/output specifications
- Security review completed — authentication model approved, no open critical findings
- All user stories in the implementation backlog traced to architecture components
- Technical risks documented with mitigation plans
- Estimated implementation timeline reviewed against resourcing
The gate evaluation is conducted by the CTO, who was not part of the architecture team.
Criteria 1, 2, 4, and 6 pass. Criterion 3 fails: the security review identified that the authentication model has not been finalized and has one open critical finding. Criterion 5 fails: two significant technical risks are identified in the review but have no documented mitigation plans.
The gate does not pass. The team is not authorized to begin implementation. The failing criteria are addressed over the following week, re-evaluated, and the gate passes. Implementation begins.
This is a phase gate functioning as designed. The gate found two real problems before the team invested six weeks of implementation effort building on an incomplete foundation.
Why Phase Gates Fail in Practice
Phase gates fail for three reasons, and they are almost always the same three reasons.
The criteria are too vague to evaluate. "The architecture is complete" is not a criterion. "The security posture has been reviewed" is not a criterion without specifying what the review included and what findings are acceptable. Vague criteria are evaluated by whoever controls the process, which is typically the project team, which means the gate always passes. Criteria need to be specific enough that two independent evaluators would reach the same conclusion about whether they are met.
The evaluators lack authority or will to fail a gate. Phase gates are often added to project processes as a governance signal without the organizational change needed to make them functional. A gate evaluator who is a peer of the project team, who will continue to work with the team after the gate, and who knows that the project is under delivery pressure has strong incentives not to fail the gate regardless of criteria. Gate authority without genuine independence produces the same result as no gate at all. Structurally, gate evaluators should be outside the project team, and should have organizational standing that makes a gate failure a legitimate outcome rather than a career risk.
Gates are added retroactively. One of the most common ways phase gates fail is that they are evaluated after the work they were designed to govern has already been completed or begun. A gate at the end of architecture that is evaluated after the development team has already started writing code is not a gate — it is a documentation exercise with a predetermined outcome. Phase gates must be enforced in sequence, in real time, before the next phase begins.
Why Phase Gates Matter
The value of a phase gate is not in the gate itself — it is in what happens because of the gate. Teams that know a gate is coming design their work to meet gate criteria. They document things that would otherwise be undocumented. They resolve ambiguities before they become implementation problems. They surface risks early, when they are cheaper to address, because the gate will surface them anyway and it is better to address them deliberately than to have them surface as blockers.
The gate changes behavior upstream of the gate. That is the real function.
Organizations that operate without phase gates — or with gates that are consistently waived or conditional — do not eliminate the decision about readiness. They defer it. The question "is the architecture complete enough to begin implementation?" does not go away because there is no gate. It answers itself, badly, when the development team hits the architectural gap six weeks into implementation that a gate would have caught at week two.
Related Concepts
Governance theater is what phase gates become when gate criteria are vague, gate authority is nominal, or conditional passes are routine. The gate exists; the accountability function does not.
Decision registers pair well with phase gates: significant decisions made during gate evaluations — including decisions to fail a gate and what would need to change to pass it — belong in the decision register.
Proportional governance applies to gate design: the depth and formality of a phase gate should match the scale and reversibility of the decision being made. A one-person project advancing from planning to writing does not need a six-criterion gate with an independent evaluator. An organization-wide platform deployment does.