The stage gate process splits a project into a sequence of phases, with a formal go/kill decision point, called a gate, between each one. At every gate a small group of decision-makers reviews the project against agreed criteria and chooses to fund the next phase, stop the project, hold it, or send it back for rework. It is the mechanism that stops weak work from quietly consuming budget for months because nobody scheduled the moment to question it.
The model is sometimes called phase gate, and it was popularized for new product development by Robert Cooper. It applies just as well to any sizable initiative inside a portfolio: a system migration, a facility build, a regulated program. This guide walks through the five stages, what actually happens at a gate, who approves them, and where stage gate fits next to agile.
Key takeaways
- A stage gate process alternates work phases (stages) with go/kill decision points (gates).
- The classic model has five stages: scoping, build the business case, development, testing and validation, and launch, with a discovery step before stage one.
- At each gate, a predefined group of gatekeepers decides go, kill, hold, or recycle against criteria set in advance.
- Stage gate and agile are not rivals. Use gates for the few irreversible funding decisions and iterate inside each stage.
What is the stage gate process?
The stage gate process is a project management framework that divides an initiative into defined phases separated by decision gates, where stakeholders review progress against set criteria and decide whether to continue, stop, pause, or rework the project. The point is to make funding a series of conditional commitments rather than one upfront bet. You release money one phase at a time, and you only release the next tranche if the phase you paid for actually earned it.
That structure does two useful things. It catches weak projects early, before they have absorbed most of their budget, and it forces the project team to produce evidence on a schedule instead of asking leadership to take delivery on faith. The discipline is most valuable exactly where it is hardest to apply: large, expensive, multi-department efforts where the cost of running a bad project to completion is enormous.
What are the 5 stages of the stage gate process?
The five stages of a classic stage gate process are scoping, build the business case, development, testing and validation, and launch, usually preceded by a discovery stage where ideas are generated and screened. Each stage does a distinct job and feeds the gate that follows it, where the work is judged before more money is committed.
| Stage | What happens | Gate that follows |
|---|---|---|
| Discovery (Stage 0) | Ideas are generated, screened for obvious fit, and the most promising are nominated. | Idea screen |
| 1. Scoping | A quick, low-cost investigation of the opportunity, market, and technical feasibility. | Second screen |
| 2. Build the business case | Detailed research produces a defined project, a justification, and a plan. | Go to development |
| 3. Development | The actual solution is designed and built; production and launch plans take shape. | Go to testing |
| 4. Testing and validation | The solution is verified through tests, trials, and limited market validation. | Go to launch |
| 5. Launch | Full-scale rollout, production, and the marketing and sales push. | Post-launch review |
Swipe to see more →
Notice that the early stages are deliberately cheap. Scoping is meant to be a few weeks of light investigation, not a full study. The investment ramps up only as the project survives gates, which is the entire economic logic of the model: spend little to learn whether a project deserves the spend that comes next.
What is a gate review?
A gate review is a formal checkpoint where a governance group examines the project against pre-agreed criteria, such as the updated business case, the risk profile, and technical results, then decides whether the project proceeds to the next stage. It is not a status update. It is a funding decision with the authority to stop the work. The review usually moves through three parts: the team prepares deliverables, the gatekeepers evaluate them against the criteria, and a decision is recorded.
The decision at a gate is one of four outcomes:
- Go. The project clears the bar and is funded into the next stage.
- Kill. The project is stopped. This is the outcome that justifies the whole process, and a stage gate model that never kills anything is not working.
- Hold. The project is paused. It is still viable but something (capacity, a dependency, market timing) means now is not the moment.
- Recycle. The work is sent back for more development before the gate is revisited. The deliverables were not strong enough to decide on yet.
Good gates publish their criteria before the stage begins, so the team knows exactly what evidence it must bring. A gate that invents its standard on the day is just an opinion poll, and teams quickly learn to game it. The agenda, criteria checklist, and decision log that keep every gate consistent are set out in our stage gate review template.
Who approves a gate in the stage gate process?
A predefined group of senior decision-makers, called gatekeepers, approves each gate, and they are chosen because they own the resources the project needs for its next stage. For early, low-cost gates this can be a single sponsor or a small portfolio board. For the expensive later gates, three through five, the gatekeepers are usually the business leadership team, sitting as the steering committee, because the resources at stake are theirs to commit.
The reason ownership of resources matters is that a gate decision is only real if the people making it can actually grant or withhold the money and people for the next phase. A gate run by reviewers who cannot say no, or cannot fund a yes, produces decisions nobody honors. This is the same principle that makes project portfolio governance work: decision forums need genuine decision rights, not just a calendar invite.
Stage gate vs agile: which should you use?
Stage gate and agile solve different problems, so the honest answer for most portfolios is both. Stage gate governs the few large, irreversible funding decisions through sequential gates; agile delivers the work inside a stage through short iterations with continuous adjustment. Stage gate protects a big upfront investment from running unchecked. Agile protects you from building the wrong thing in the first place.
| Dimension | Stage gate | Agile |
|---|---|---|
| Cadence | Sequential phases with formal gates | Short, repeating sprints |
| Decisions | Go/kill at scheduled gates | Continuous reprioritization |
| Best for | Large, costly, irreversible commitments | Evolving requirements, fast feedback |
| Main risk it controls | Funding a weak project to completion | Building something nobody wants |
Swipe to see more →
The practical pattern, often called agile stage gate, keeps the gates for the irreversible money decisions and runs each stage as a series of agile iterations. You get the financial discipline of gates and the responsiveness of sprints. The mistake is treating them as a binary choice. A portfolio that uses only gates moves too slowly inside each stage; one that uses only sprints loses the ability to kill a project before it has spent its budget.
When is the stage gate process the right fit?
Stage gate earns its overhead when the cost of a wrong project is high and the decision to continue is genuinely worth pausing for. New product development, capital projects, regulated programs, and large system changes all fit, because each involves rising investment and a real option to stop. The gate structure gives leadership controlled exit points instead of a single all-or-nothing bet.
It is a poor fit for small, fast, low-cost work where the gate ceremony costs more than the risk it manages. If a project is cheap enough that running it to completion wastes little, do not wrap four gate reviews around it. Reserve the discipline for the work where stopping early actually saves something. And size the gates to the project: a small initiative might face one lightweight gate, while a major program faces all five with full review boards.
What happens inside each stage, and what does the gate need to see?
Each stage exists to answer one question and to produce the evidence that answers it. The gate at the end is where someone with authority decides whether that answer justifies more spending. Stages without a single defining question tend to sprawl, and gates that do not name their evidence in advance turn into presentations rather than decisions.
| Stage | The question it answers | The work that happens | What the gate needs to see |
|---|---|---|---|
| Discovery | Is there a problem worth solving? | Problem definition, rough sizing, strategic fit check | A one page case: problem, rough value, rough cost, fit |
| Scoping and feasibility | Can we solve it, and roughly what does it take? | Options analysis, technical feasibility, high level estimate | Options with a recommendation and the cost of each |
| Business case | Is this the best use of the money against everything else competing for it? | Detailed estimate, benefit definition, risk assessment, resource ask | A full business case with measurable benefits and a named owner |
| Development and delivery | Are we building it as planned? | Execution, controlled change, progress and risk reporting | Progress against baseline, live risks, forecast to complete |
| Launch and handover | Is it ready to run, and who owns it now? | Readiness checks, cutover, transition into operations | Readiness evidence and a named, funded operational owner |
| Benefit gate (optional) | Did we actually get what we paid for? | Benefit measurement against the approved business case | Measured benefits and lessons that feed the next case |
Swipe to see more →
Notice how the evidence tightens as you move down. Early gates should be cheap to pass and cheap to fail, because their job is to kill weak ideas before they consume estimating effort. Late gates are expensive to fail, which is exactly why their criteria have to be visible from the start of the stage rather than revealed at the meeting. The evidence checklist itself belongs in the stage gate review template, and the final row is where a post implementation review attaches to the lifecycle.
How many gates should your process actually have?
Match the number of gates to the size of the decision, not the size of the budget. Work that is easy to reverse needs fewer gates than work that locks in a vendor for five years, even when the second one costs less. Most organizations get this wrong by running one heavy track for everything, which pushes small projects to route around the process entirely.
| Project tier | Gates | What gets skipped | Who decides |
|---|---|---|---|
| Small and reversible | One: approve and go | Formal options analysis and the separate feasibility gate | Delegated to a portfolio manager within a published spend limit |
| Standard | Three: idea, business case, launch readiness | The feasibility gate, folded into the business case | Portfolio board |
| Major or hard to reverse | The full set, plus a benefit gate after go live | Nothing | Executive committee, with the sponsor presenting in person |
| Regulatory or mandated | A compliance gate on the solution, not on the funding | Prioritization scoring, because the work is not optional | Compliance owner, plus the board for sequencing only |
Swipe to see more →
Set the tier at intake, publish the thresholds, and let the tier select the track automatically. If people have to negotiate which track applies, you have added a decision instead of removing one. This is why the gate track and the project intake process have to be designed together rather than bolted to each other later.
Where does the time actually go between gates?
When people say a stage gate process is slow, the elapsed time is usually not in the work. It is in waiting: waiting for the next scheduled gate, waiting for a decision after the gate has been held, and redoing deliverables after a vague conditional approval. Measure those buckets separately before you start removing gates, because removing gates does nothing at all to queue time.
| Time bucket | What it is | Usual cause | The fix |
|---|---|---|---|
| Stage work | Real analysis and delivery effort | The actual work | Estimating and resourcing, not process change |
| Gate queue | Ready for review, waiting for the next scheduled meeting | Gates held on a fixed calendar regardless of demand | Meet more often with a shorter agenda, or allow out of cycle approval below a threshold |
| Decision latency | The gate was held and no decision came out of it | A missing attendee with authority, or missing evidence | Name one decider and a standing deputy, and publish the evidence list in advance |
| Rework | Deliverables redone after a conditional go | Conditions written vaguely, or criteria revealed at the gate | Every condition gets an owner and a date, and criteria are published at stage start |
| Pack assembly | Building the gate pack itself | Evidence spread across tools and rebuilt by hand each time | Report from the same source the project already updates |
Swipe to see more →
The distribution is the diagnostic, not the total. If most of the elapsed time sits in gate queue and decision latency, the problem is your governance calendar and your decision rights. Cutting gates in that situation makes the portfolio less controlled without making it any faster, and it is the single most common overcorrection.
How do you adapt the stage gate process for internal IT and change projects?
The original model was built for new product development, where the risk is market risk and the decision is whether to keep funding an uncertain payoff. Internal IT and business change projects carry different risk: the value is often mandated or assumed, and the real uncertainty is delivery and adoption. The stages survive, but the questions have to be re-pointed.
| What the product model tests | What an internal project should test instead |
|---|---|
| Will the market want it? | Will the intended users adopt it, and who has agreed to make that happen? |
| Can we build it at a competitive cost? | Can we run it after go live, and is the operating owner named and funded? |
| Is the revenue forecast credible? | Is the benefit measurable in a system somebody already owns, or only in a slide? |
| Is it technically feasible? | What does this depend on, and what else in the portfolio depends on it? |
| Is the product ready to launch? | Is the business ready: training, process change, and the cutover it has to absorb? |
Swipe to see more →
The most common failure here is keeping the product model's gates while quietly dropping its questions. A gate that asks whether the build is on schedule, but never asks who will own the system in production, will pass projects that go live on time and then decay within a year.
Stage gate process best practices
A few habits separate a stage gate process that protects the portfolio from one that becomes theater.
Define gate criteria before the stage starts. The team should know on day one of a stage exactly what it must prove to pass the next gate. Criteria invented at the review are unfair and unworkable.
Be willing to kill. The single most valuable thing a gate does is stop a project. If your gates only ever say go, they are decorative. Track your kill rate; a healthy process stops a meaningful share of what enters it.
Keep early stages cheap and fast. The economics depend on learning a lot for a little in scoping and the business case. If your early stages cost as much as development, you have lost the protection the model exists to provide.
Right-size the ceremony. Match the weight of the gate to the size of the bet. A uniform heavyweight process applied to every project teaches teams to route around it. How much gating an organization can absorb tracks closely with where it sits on the PMO maturity model, so introduce gates at the level the office can actually enforce today.
Connect gates to the portfolio view. A gate decision is also a capacity decision. Saying go to one project means saying not yet to whatever its people would otherwise do, which is why gating works best inside a clear picture of resource and capacity planning across the portfolio.
Check readiness, not just the plan. For any project that leans on outside suppliers, make vendor and contractor compliance a gate criterion before delivery starts, so a lapsed certificate of insurance is caught at the review rather than during an incident.
How stage gate fits the wider portfolio
Gates do not run in isolation. The work that reaches a stage gate process has usually already passed through an intake process and been ranked in prioritization, most often on the weighted grid described in the project prioritization matrix. Intake decides what is worth considering, prioritization decides where it sits against everything else, and the gates then govern each surviving project as it spends real money phase by phase. Together they turn a portfolio from a list of things in flight into a managed set of conditional commitments, each one funded only as far as it has earned. That is the difference between a PMO that steers and one that simply records what already happened, and it is the whole point of treating project portfolio management as a discipline rather than a reporting chore. To run each gate consistently, give every project the same stage gate review template so the agenda, criteria, and decision log never shift from one meeting to the next.
Gates also run out at the wrong end. Most stage gate models stop at launch, so the question of whether the project actually delivered what it was funded for never gets asked. Adding a post implementation review a few months after go-live closes that loop, and it is the gate that most often improves how the next business case is written.
Whether you run the gates on paper or in a tool, the part that decides if the process survives contact with a busy portfolio is the record. A gate that leaves behind a slide deck and a memory is not a control. Running the five gates through stage gate software keeps the score, the business case figures and the capacity demand frozen as they stood at each review, so the trail from Gate 1 to Gate 4 reads as a sequence of decisions rather than a folder of attachments.