Skip to content

Phase-Gate Review

Stage-gate readiness review — instantiates Transition Readiness Assessment

A recurring gate between program phases that names the next state, fixes the criteria for entering it, and checks whether current conditions actually clear that bar before work is allowed to advance.

A Phase-Gate Review is a standing checkpoint placed at the boundary between two phases of a multi-stage program — design to build, pilot to scale, trial to registration. Its defining move is that each gate is written for one specific crossing: it names the next state the work is trying to enter, fixes the criteria that entering it safely requires, and then tests whether current conditions clear that bar. Unlike a milestone that merely marks that scheduled work is finished, a phase-gate review asks a sufficiency question — are the conditions for the next phase actually present? — and refuses to accept the calendar, or the fact that the previous phase is "done," as the answer.

Example

A biotech is deciding whether a drug candidate advances from Phase II into the far more expensive Phase III. The gate is written for that exact crossing, not for progress in general: an efficacy signal above a pre-set effect size, a safety profile inside agreed bounds, a manufacturing process demonstrated at commercial scale, and a viable regulatory path. At the gate the team shows evidence against each criterion. Efficacy and safety clear. But the scale-up criterion fails — the process still only works at bench scale. The review's verdict is not "the drug is bad"; it is "one entry condition for Phase III is not yet met," and it routes the program to prepare further rather than advance. The gate says nothing about the science's promise — only whether the specific conditions for the next phase are in place, which stops a program from spending Phase III money on a Phase II readiness state.

How it works

  • One gate, one crossing. Each gate's criteria are specific to the next phase being entered, so readiness is judged against that state rather than against generic progress.
  • Sufficiency, not completion. The question is whether conditions for the next phase are present — a finished task list is not evidence that they are.
  • Criteria fixed in advance. Must-have entry conditions are separated from nice-to-have improvements before the gate, so the bar can't be quietly redrawn under deadline.
  • Threshold comparison with named shortfalls. Current conditions are checked against the minimum, and any unmet criterion is named specifically, not rolled into a soft overall score.
  • Re-run at every boundary. Clearing one gate says nothing about the next; readiness is re-judged afresh for each crossing.

Tuning parameters

  • Gate stringency — how much proof each criterion demands. High stringency stops premature advance but can stall a program against its horizon; low stringency turns the gate into a formality.
  • Must-have vs. nice-to-have split — which criteria block advance and which merely inform. Draw the line too wide and everything blocks; too narrow and real risks pass through.
  • Number and cadence of gates — more gates catch drift earlier but add overhead and can fragment momentum into checkpoint theater.
  • Recycle vs. kill options — whether a failed gate can send work back to improve (recycle) or terminate it. Richer options reduce sunk-cost escalation but complicate governance.
  • Evidence bar — demonstration versus assertion per criterion. A higher bar is more honest but slower to clear.

When it helps, and when it misleads

Its strength is that it forces a sufficiency judgment the calendar would otherwise make by default, and it localizes what is missing: a held gate names the specific unmet criterion, so the fix is targeted rather than a blanket delay.

Its classic degeneration is the gate as bureaucratic rubber stamp — a checkbox ceremony that waves through whatever arrives on schedule, which is exactly the failure the discipline of stage-gating was built to prevent and keeps slipping back into.[1] The mirror-image misuse is running the gate backwards: convening the review to bless an advance already decided, then waiving whatever fails. Over-gating is the opposite failure — so many gates, so stringently applied, that a program strangles on its own governance. The guard is criteria agreed in calm before the pressure arrives, must-haves that cannot be silently waived, evidence that is demonstrated rather than asserted, and treating "not ready" as a preparation map handed to remediation rather than a dead end.

How it implements the components

  • transition_target_state — each gate names the specific next phase or state the work is trying to enter, so readiness is judged against that destination rather than against general progress.
  • readiness_criteria — the gate fixes the must-have conditions for that crossing and separates them from nice-to-have improvements.
  • threshold_check — its core act: comparing current conditions against the minimum required and naming any that fall short.

It evaluates sufficiency but does not convene the accountable decision or poll the stakeholders — that formal proceed / delay / abort call is the Go / No-Go Meeting; it does not turn unmet criteria into a scheduled fix (that's Gap Remediation Plan); and it does not itself gather the underlying test evidence (that's the assessments and a Readiness Scorecard).

  • Instantiates: Transition Readiness Assessment — the recurring gate each phase must clear before the work is released into the next.
  • Consumes: the per-criterion evidence and scores assembled before the gate — a Readiness Scorecard or the assessments supply them.
  • Sibling mechanisms: Go / No-Go Meeting · Readiness Scorecard · Gap Remediation Plan · Launch Readiness Review · Operational Readiness Review · Preflight Checklist · Clinical Discharge Readiness Check · Disaster Reentry Check

Editorial Notes

Form Classification

Form family: Assessment, Review & Assurance

Rationale: The gate evaluates current evidence against predeclared next-phase entry criteria and returns a readiness finding.

Nearest alternative: Decision, Gate & Allocation — Advancement is allowed or held, but that disposition is specifically produced by assessment.

Review outcome: Adjudicated after independent review; high confidence.

Origin Attribution

Primary origin: Innovation & Entrepreneurship

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Multi-domain

Rationale: Phase-Gate Review is rooted in innovation and entrepreneurship: Stage-Gate innovation management formalized criteria-based reviews between product-development phases.

Related originating lineages:

  • Engineering & Design — Engineering lifecycle reviews materially shaped entry criteria, readiness evidence, and technical gating.
  • Organizational & Management Science — Organizational and management science materially shaped Phase-Gate Review through coordination, organizational learning, performance, and change practice. Stage-gate reviews were institutionalized in project and product-development management.

Review resolution: Light authoritative-source research resolves the primary-origin disagreement in favor of innovation and new-product-development practice. Robert G. Cooper: The Stage-Gate Model directly documents the defining practice or theory described in the selected origin rationale. Other listed domains are retained only where the blind reviews identify material co-development or translation; broader adoption remains separate as domain_reach=multi_domain.

Attribution caveat: The boundary with organizational and management practice is real because that field materially developed or translated the practice, but the cited provenance places the defining form in innovation and new-product-development practice.

Review outcome: Researched adjudication after independent review; high confidence.

Sources consulted:

Notes

A phase-gate review is not stage progression. Stage-gate progression structures how work moves through stages; this mechanism judges whether the conditions for a specific crossing are sufficient. Confusing the two lets a program treat "we reached the gate on schedule" as if it were "we are ready to pass it" — which is the exact substitution the gate exists to block.

References

[1] Cooper, R. G. "Perspective: The Stage-Gate® Idea-to-Launch Process—Update, What’s New, and NexGen Systems". Journal of Product Innovation Management 25(3), 213–232 (2008). Documents the recurring 'gates with no teeth' failure in which projects are rarely killed, post–Gate 1 reviews become rubber stamps, and the intended go/kill funnel becomes a tunnel. registry