Phase gate process — stages and SAGE implementation
What phase-gate and stage-gate mean, how gate reviews work, where the model helps, where it becomes rigid, and how SAGE applies the pattern.
What is a phase-gate process?
A phase gate process divides work into phases separated by formal decision points. The basic idea is simple: do not let a team spend the next block of time, money, and attention until the current evidence is strong enough to justify moving forward. A gate may approve the work, stop it, hold it for more evidence, recycle it to an earlier activity, or approve it with conditions.
The model is common in product development, capital planning, business transformation, technology delivery, and regulated work because it creates explicit moments where leaders can test risk, value, readiness, and ownership. The phrase stage gate process is often used for the same pattern. Some organizations say "phase gate process" because their lifecycle is organized by phases; others say "stage gate process" because the classic product development literature uses stages.
The pattern is documented broadly in project and product-development sources. Wikipedia's phase-gate process overview describes the general structure, and PMI's phase-gate process paper discusses criteria and installation factors. SAGE applies the same decision pattern in a program management context, using BEARINGS artifacts to make the evidence reviewable.
A useful phase gate process is not only a sequence diagram. It defines what evidence is required, who can approve, what decisions are available, what happens when conditions are attached, and where the decision record lives. Without those details, a gate becomes a calendar event. With them, the gate becomes a control point that can protect capacity and make trade-offs explicit.
The five or six classic phases
Classic stage gate process descriptions often include discovery, scoping, business case, development, testing, and launch. Some models count five stages by combining discovery and scoping or by treating launch as the result of the final gate. The exact labels matter less than the control logic: each stage creates information, and each gate asks whether that information supports the next investment.
Discovery asks whether the opportunity or problem is worth initial attention. Scoping tests the boundaries, stakeholder context, risks, and early value claim. The business case stage develops the recommendation and investment logic. Development builds the product, service, process, or capability. Testing validates readiness and quality. Launch moves the change into real operation, where benefits and defects become visible.
In SAGE, the names are different but the control idea remains. P0 Intake filters requests. Scope defines the problem and causes. Assess builds the business case, delivery strategy, governance, and measurement plan. Generate builds and prepares for cutover. Embed stabilizes the change and verifies benefit. Gates A, B, and C make the main approvals visible.
Phase-gate vs stage-gate — is there a difference?
In everyday use, phase-gate and stage-gate usually mean the same thing. Both describe a lifecycle with work stages and approval gates. The difference is mostly vocabulary. Product development teams often say stage gate process. Program and project teams often say phase gate process. Either way, the method asks teams to finish the right evidence before asking for the next commitment.
The naming can still reveal how an organization thinks. "Stage" often emphasizes market, product, or development maturity. "Phase" often emphasizes governance and lifecycle transition. SAGE uses phases because Scope, Assess, Generate, and Embed describe the program's movement from problem to benefit. The gates approve specific artifacts rather than a vague sense of progress.
The case for and against phase-gate
The strongest case for a phase gate process is decision quality. It creates a routine for asking whether a proposal still deserves investment. That can improve risk mitigation, resource allocation, stakeholder alignment, quality, and executive visibility. It can also reduce the common pattern where a weak idea survives because nobody created a real moment to say no.
The criticism is equally real. A stage gate process can become slow, performative, and bureaucratic. Teams may produce documents for the gate rather than evidence for the decision. Approvers may review polish instead of risk. Delivery teams may wait for committees that add little value. In fast-moving work, a rigid gate model can hide learning rather than support it.
The practical answer is not to abandon gates or worship them. The answer is to make each gate approve the right evidence. If a gate requires a hundred-page deck but no one can see the owner, benefit target, risk, or unresolved assumption, the gate is weak. If a gate requires concise artifacts that expose the decision, it can protect speed and quality at the same time.
The best implementations also make no a legitimate answer. A phase gate process that only ever says yes is just a ritual. Gates should help the organization stop weak work, hold work that needs more evidence, approve work with conditions, or redirect capacity to a better option. The stage gate process earns trust when teams believe the decision is real and the criteria are known before the review.
Gate decisions: Go, Kill, Hold, Recycle
Many phase-gate models describe gate decisions as Go, Kill, Hold, or Recycle. Go means the work has enough evidence to proceed. Kill means the work should stop because the value, risk, readiness, or fit no longer justifies investment. Hold means the work may still be valid but should pause because timing, capacity, dependency, or evidence is not ready. Recycle means the team should return to specific work before asking for approval again.
SAGE uses the same decision logic in practical terms. Gate A may approve the BRD, decline the request, hold for more evidence, or approve with conditions. Gate B may approve the FD, require delivery-planning changes, or hold for unresolved readiness risks. Gate C may approve go-live, hold for cutover fixes, or reject launch readiness. The important point is that the decision and conditions are recorded.
Conditional approvals deserve special care. If a gate approves the next phase with open conditions, the team should capture the condition, owner, due date, evidence required, and reviewer who can close it. Otherwise conditional approval becomes a quiet yes with hidden risk. The phase gate process should make conditions visible enough that they can be managed like real work.
Common gate criteria
Gate criteria vary by organization, but most useful models test value, evidence, risk, readiness, ownership, and fit. Value asks whether the work still matters. Evidence asks whether the recommendation is supported. Risk asks what could harm the organization or the outcome. Readiness asks whether the team can execute the next step. Ownership asks who is accountable. Fit asks whether the work still belongs in the portfolio or program.
In a stage gate process, criteria should be known before the review. If teams learn the standard only during the gate, the model rewards presentation skill more than preparation. SAGE handles this by tying each gate to named artifacts. Gate A reviewers know they are testing the BRD and pre-Gate-A BEARINGS evidence. Gate B reviewers test the FD and post-Gate-A readiness. Gate C reviewers test go-live readiness.
The criteria should also be narrow enough to use. A gate with twenty vague criteria will not create better control than a gate with six clear ones. The reviewer should be able to say exactly which criterion is not met and what evidence would close the gap. That clarity helps teams improve the work instead of guessing what the gate wanted, and it keeps the next review focused on evidence rather than broad debate. It also makes the gate easier to teach to new teams and easier to audit later when decisions are questioned by sponsors, operators, or auditors.
A modern phase-gate implementation — SAGE's three gates
SAGE uses three primary governance gates. Gate A is the Initiation Gate. It approves the BRD Part A business case after Scope and the pre-Gate-A BEARINGS artifacts are complete. Gate B is the Planning Gate. It approves the FD Part B delivery plan after Navigation, Governance, and Signals are complete. Gate C is the Execution Gate. It approves go-live after cutover readiness.
That makes SAGE a phase gate process with fewer, sharper approvals. The work between gates is not a blank space. It is structured by BEARINGS, the artifact framework that turns problem framing and planning into reviewable evidence. Gate A approves whether to proceed with a recommended route. Gate B approves whether the delivery plan is ready for build. Gate C approves whether the change is ready for production.
How SAGE handles the rigidity problem
SAGE handles the rigidity problem by making gates artifact-backed rather than theater- backed. The artifacts are small enough to review and specific enough to challenge. Scope and Roots define the problem. Stakeholders names the human system. Goals defines the value claim. Options & scoring and Scorecard explain the recommendation. Strategy, Accountability, Decision rights, and Measurement plan prepare the delivery model.
This lets a gate review focus on evidence instead of ceremony. The reviewer can ask: Where is the proof? Who owns the decision? Which option was rejected? What trade-off was accepted? What assumption remains? What metric will verify benefit? Those questions keep the phase gate process useful without turning it into a paperwork ritual.
SAGE also separates the program governance layer from delivery cadence. A team can use Agile delivery inside Generate while still using gates for business approval, delivery readiness, and go-live readiness. That distinction helps the methodology avoid a common false choice. The organization can have disciplined approvals without forcing every delivery team into a rigid task sequence.
When phase-gate is the right fit (and when it is not)
A phase gate process is the right fit when the work has meaningful investment, risk, cross-functional ownership, regulatory exposure, customer impact, or executive decision needs. It is useful when the organization must decide whether to keep funding an option, change direction, or stop. It is also useful when a team needs a durable record of why a decision was made.
It is a weaker fit for small, low-risk work with one owner and a known path. A simple task list, lightweight project plan, or product backlog may be enough. The stage gate process becomes harmful when the cost of review is larger than the risk being controlled. SAGE is designed for program work where the decision record matters.
One practical test is reversibility. If the next step creates a commitment that is hard to reverse, a gate is useful. Funding a build team, selecting a vendor, changing policy, migrating data, launching to customers, or altering operations are all commitments that deserve evidence. If the next step is a low-cost experiment that can be undone easily, the gate can be lighter or unnecessary.
How to run a gate review
- Circulate the pre-read. Send the artifact pack, decision request, criteria, known risks, and open questions before the gate review.
- Review gate criteria. Compare the work against the gate entry criteria and the decision standard defined by the methodology.
- Test the evidence. Ask whether the recommendation is supported by artifacts, data, stakeholder review, and unresolved assumptions.
- Capture the decision. Record Go, Kill, Hold, Recycle, or conditional approval with approver, date, rationale, and conditions.
- Assign conditions and owners. If approval is conditional, name the owner, due date, evidence required, and path back to the approver.
- Update the running record. Link the gate decision to artifacts, actions, problems, and alignments so the decision remains traceable.
A good gate review ends with a decision, not a discussion summary. Record the decision, conditions, owners, and evidence links in the program record and the TAP Log where relevant.
Phase-gate FAQ
What are the 5 stages of the stage-gate process?
Classic stage-gate models often include discovery, scoping, business case, development, testing, and launch. Some versions count five stages by combining discovery or launch activities.
What is the phase gate process?
The phase gate process divides work into phases separated by formal decision points. At each gate, approvers decide whether the work should go forward, stop, pause, or return for more evidence.
What are the 4 stages of project management?
Many project management references describe initiation, planning, execution, and closure. SAGE uses Scope, Assess, Generate, and Embed, preceded by P0 Intake and governed by Gates A, B, and C.
How do phase gates work?
Phase gates work by requiring evidence before a team moves from one phase to the next. The gate review checks criteria, risk, ownership, readiness, and the requested decision.
Stage-gate vs phase-gate — what is the difference?
Stage-gate and phase-gate usually describe the same pattern: phases or stages separated by decision gates. The naming differs by organization and industry.