Stage Gate Process: Phases, Gates, and Steps Explained

McKinsey's 2025 analysis of a 16,000-project database found that 8.5 percent hit both their cost and schedule targets. Half a percent delivered every benefit promised at approval. Standish Group's CHAOS data says something similar, but more bluntly: 31 percent of software projects succeed outright, and half land in the "challenged" column. The stage gate process was built to attack that gap. It splits development into fixed stages and puts a formal decision point between each one.

Most teams meet the model when a project stops behaving. Requirements drift. A build scoped for four months is in month nine, the budget conversation has climbed two levels of management, and nobody can name the week the scope actually changed. A custom software development program running several workstreams at once makes that failure mode routine rather than unlucky. Stage gate governance answers that question directly by defining a point at which the project is halted, a cross-functional review board evaluates the evidence, and the project continues or is abandoned.

This article covers all six stages, the contents of a gate review, the criteria used by gatekeepers, the four decisions available, and where the stage gate model grinds against Agile delivery.

What Is the Stage Gate Process?

The stage gate process is a project management methodology which involves breaking down the development process into a number of definite stages with specific gates between them. At each gate, a management team reviews the results of the preceding stage and decides whether to move on to the next stage, abandon the project, halt it for some time, or make other recommendations.

Risk in a development program is front-loaded in ignorance and back-loaded in cost. The cheapest week to cancel a weak idea is week two. By week forty the work has an owner, a headcount plan, and a line in the quarterly review, so canceling it becomes a political act instead of a financial one. Gated review moves that decision onto a calendar. Money is released one stage at a time, and the next tranche depends on evidence the previous stage was supposed to produce. 

A project that can't produce it stops while stopping is still cheap. The framework came out of NPD research and still carries its vocabulary, which is why software teams meet terms like "business case" where they expected "requirements".

Where the Stage Gate Process Came From

Stage-Gate has an author. Dr. Robert G. Cooper, now professor emeritus at McMaster University's DeGroote School of Business, ran the NewProd studies on new product development through the 1980s. They compared new-product projects that won against ones that died — hundreds of them — scored on what the teams actually did rather than what the plan had promised. The winners kept repeating two habits. 

Homework came first: they settled the market case and the technical unknowns before development opened. And one cross-functional team carried the work end to end, with no handoff from marketing to engineering halfway through. Cooper named that sequence Stage-Gate in the mid-1980s. His 1994 revision loosened the stage-gate model — stages overlap, and a gate can issue a conditional Go rather than a binary verdict. Pharma and aerospace adopted it quickly. A failed compound or a failed airframe program isn't something either industry can absorb quietly.

How Is the Stage Gate Process Used in Software Development (SDLC)?

The stage gate process doesn't replace an SDLC but sits above one. A software development life cycle describes how code gets specified, built, tested, and released. Stage gate governance decides whether that cycle should run at all, and with how much money behind it.

The overlap is what confuses people. Every SDLC already carries milestones — a design freeze, a code freeze, a release readiness review. What a gate adds is the authority to stop. A design review asks whether the design is ready. A gate asks whether the business case still holds, then funds the next stage or refuses to.

The sharper difference sits at the front end. Most SDLC models open at requirements, which quietly assumes somebody already decided the product was worth building. A stage gate development process opens two steps earlier, at discovery and business case, so the requirements phase inherits a decision instead of a hunch.

Teams that adopt the model in software usually land somewhere hybrid, close to the Spiral Model or the Rational Unified Process: iterative inside each stage, gated between them. Sprints keep their normal two-week rhythm. The gate falls at the stage boundary, so a review board meets roughly every eight to twelve weeks rather than every sprint.

Which Projects Is the Stage Gate Process Good For?

• Large, complex projects: For major software development initiatives, Stage Gate can provide structure and control.
• Highly regulated industries: Some industries have strict compliance requirements that benefit from the structured approach of Stage Gate.
• Risk-averse companies: For companies prioritizing risk mitigation, the decision points of Stage Gate can offer reassurance.

Alternatives to the Stage Gate Process

Agile and Lean sit at the other end of the spectrum, trading documented checkpoints for shorter feedback loops, and several other software development methodologies split the difference. Ultimately, the best approach depends on the specific project and the company's needs. Keep in mind that unless you work in a heavily regulated industry, you don’t necessarily have to do everything by book. Your team can hybridize the Stage Gate Process to have some understandable structure to follow while keeping the flexibility options, for example.

The 6 Stages of the Stage Gate Process

Stage counts differ between organizations. Cooper's canonical sequence runs five stages with a discovery step in front of them, and most software teams settle on the six below. Every stage has a job, a fixed list of deliverables, and a gate waiting at the end. The stage gate process steps that follow use one running example: a general contractor upgrading its field app so crews can track materials across active sites.

Stage 1: Discovery

Discovery costs the least and decides the most. The work is problem definition — user interviews, a scan of what competing products already do, a first read on whether the technology even exists. No architecture yet.

On the contractor program, discovery started with two weeks of site visits. Foremen weren't complaining about the app's interface. They were complaining that material counts lived in three places — a warehouse ERP, a spreadsheet the site clerk kept, and whatever the delivery driver had scrawled on a paper docket — and none of the three agreed by Friday. That reframed the request. It had arrived as a UX refresh; discovery turned it into a data-reconciliation problem.

Deliverables: a written problem statement, evidence from real users, and a short list of concepts worth scoping.

Stage 2: Scope

Scoping draws the boundary. Which problems the build will solve, which it will leave alone, and what it would take technically. This is also where the team picks the artifact that answers the biggest open question first — the difference between a PoC, prototype, and MVP is which risk each one retires. Estimates here are deliberately rough — plus or minus half is normal, and pretending otherwise is how a business case ends up resting on fiction.

The contractor's scope of work produced a two-part answer. In scope: a single materials ledger, barcode scanning at delivery, an offline mode for sites with no signal, and a daily reconciliation report. Out of scope, and written down as out of scope: procurement, invoicing, and anything touching the ERP's write path. The feasibility question turned out narrower than expected. The ERP already exposed a read-only API, so nobody had to negotiate write access with the finance group.

As a result, you get a scoped feature set, a stack decision, a resourcing estimate, and a documented list of exclusions.

Stage 3: Business Case

This is the heaviest document in the sequence, and the one gate reviews spend most of their time on. It carries the market analysis, a defined product, a project plan, and a financial model with its assumptions left visible.

Modeled numbers from the contractor program:

• 41 active sites
• 6.5 hours a week lost per site to material searches and re-orders
• $58 fully loaded hourly cost
• 46 working weeks a year

That works out to 266.5 hours a week across the portfolio, or $15,457 a week, or $711,022 a year in recoverable time. Set against a build estimate of $312,400 and annual running costs of $74,000, the net first-year return is $637,022, and payback lands just under six months.

Precision isn't the goal of the exercise. Every input above is now a line somebody has to defend in front of the review board. Move the 6.5-hour figure down to 2.5 and payback stretches past a year, which is a different conversation entirely.

Stage 4: Development

Development is the longest stage in the stage gate development process, and it eats most of the budget. Sprints run normally inside it — two-week cycles, demos, the usual grooming — with the gate structure sitting outside that rhythm rather than interrupting it.

One thing gets missed here constantly. The test plan and the launch plan are built during development, not after it. A team that waits until code-complete to think about validation shows up at the next gate with nothing to review.

The contractor build spent its first four sprints on the materials ledger and the ERP read integration. Offline sync took another five and nearly broke the schedule: reconciling a scan taken in a basement with a delivery logged an hour later at the site entrance turned out to be a conflict-resolution problem rather than a caching one.

This stage leads to a working software, revised cost and schedule figures, a test plan, and a launch plan.

Stage 5: Testing & Validation

Validation covers more ground than QA. Four things get tested here: 

• the product itself;
• the delivery and support process behind it; 
• customer acceptance;
• the financial case now that real numbers exist.

The contractor ran a field trial on nine sites for six weeks, with supervisors and site clerks using it against live deliveries. Low-stock alerts came out of that trial. Nobody had asked for them during discovery, and within a fortnight they were the most-opened screen in the app. The revised business case came back showing 4.9 hours saved per site rather than 6.5 — still above the threshold, but enough to change the rollout order.

This will help you with test results, a validated financial picture, and a go-to-market plan the commercial side has signed off.

Stage 6: Launch

Launch is a continuous process, not a moment. Full deployment, training, support ramp-up, and the commercial push all live inside it.

The contractor rolled out across 41 sites over eleven weeks, region by region, with a two-day training block per region. Support tickets spiked in week three when the second region came online, mostly about barcode hardware rather than the software.

Then comes the step most teams skip: the post-launch review, usually held six to eighteen months after release. It compares what the business case promised against what the product delivered, and it's the only mechanism that tells an organization whether its stage gate process is producing good decisions. Skip it, and the next business case gets built on exactly the same untested assumptions as the last one.

What Happens at Each Gate: Review Criteria and Steps

A gate is a scheduled decision with named attendees, a fixed set of inputs, and an outcome that gets written down. The stage gate process steps below describe what happens in the room, and in what order.

What a Gate Review Covers

Every gate has the same three parts.

• Deliverables. What the team brings. These are agreed when the previous phase opens, not negotiated the week before the review — a gate where the board is still arguing about what should have been submitted has already failed.
• Criteria. What the submission is judged against. Written down, shared in advance, and identical for every project competing for the same budget.
• Outputs. What leaves the room: a decision, an approved plan for the next phase, a committed budget and headcount, and a date for the following gate.

That last part gets dropped more often than any other. A gate that issues a decision but commits no resources has done half its job. The team walks out approved, then spends five weeks negotiating for engineers, and a four-month phase quietly becomes a six-month one.

Gatekeepers are the people who own the resources being committed on a mid-size program, that usually means an engineering leader, a commercial owner, a finance representative, and, in regulated sectors, a compliance officer. Seniority has to match the money on the table. A board that can't release a budget without escalating upward isn't a gate but a recommendation with a calendar invite.

Must-Meet vs. Should-Meet Criteria

Cooper's framework splits the criteria into two kinds, and conflating them is the most common implementation error.

Must-meet criteria are knockout questions with yes-or-no answers. One "no" is enough to stop the project regardless of how strong everything else looks. For the contractor program, the must-meet list at the business case gate ran to four questions: does this fit the portfolio strategy, is the technical path proven rather than theoretical, does the return clear the internal hurdle rate, and is there any data-protection blocker?

Should-meet criteria get scored and weighted. No single low score is fatal, but the total has to clear a threshold. The contractor's scorecard ran six factors on a scale of ten, weighted, with a pass mark of 6.0. The project came in at 6.8. Two scores sat well below the rest — support readiness at 4, competitive differentiation at 5 — and both came back as written conditions attached to the approval rather than as reasons to refuse it.

Scoring does something a discussion can't. It makes disagreement visible. When one gatekeeper scores market attractiveness at 8 and another scores it at 3, that gap is the actual agenda item, and it would have stayed buried in a conversation that ended with everyone nodding.

The Four Gate Decisions: Go, Kill, Hold, Recycle

Four outcomes, and the distance between the last two matters more than most teams expect.

Go. The technical path holds, the market evidence supports the case, and the numbers work. Budget and people are released for the next phase, and the plan for that phase is approved in the same session. Conditional Go is the common variant: the project proceeds, but named milestones have to be hit, a specific uncertainty resolved, or an external approval secured by a set date. The condition is written into the record with an owner against it; otherwise it evaporates by the following week.

Kill. Some projects shouldn't continue. The technical obstacle turns out to be structural, the market has moved, or the cost has climbed past what the return can carry. Stopping releases people and budget back to the portfolio, where they fund something with better odds. 

Hold. The work is sound, and the timing isn't. A partner dependency hasn't landed, the market needs another two quarters to mature, or the engineers are committed elsewhere until Q3. Held projects need a named owner and a review date. Without both, the hold list turns into a graveyard nobody opens again.

Recycle. The submission wasn't good enough to judge. Design gaps, financials that don't reconcile, user feedback that contradicts the assumptions in the business case — the phase runs again with the shortfalls named in writing. Recycle points at the deliverables; hold points at the calendar.

A portfolio where nothing ever gets stopped doesn't have a run of unusually good ideas. It has gates that only say yes. The clearest diagnostic in any gated organization is the stop rate at the first two gates: if every project entering discovery reaches development, the criteria aren't doing any work, and the review board is a formality in governance clothing.

What Are the Benefits of the Stage Gate Process?

The advantages of the stage gate process show up in three places. They hold whether the work is new product development or a platform rebuild inside an existing system.

• Transparency. Fixed review points push information into the open on a schedule instead of when someone thinks to ask. Everyone judging the project reads the same package against the same criteria. A sponsor learns about a slipping integration at the gate in month four, not from a status deck in month nine when the options have narrowed to two bad ones.
• Flexibility. Hold and recycle give a board something between approval and cancellation. A project can pause for a partner dependency and restart with its business case intact, or go back a phase to fix financials that didn't reconcile. Teams adapt to a shifted market without throwing away the work that still stands.
• Better outcomes. Weak projects get stopped early, while stopping is still cheap. The budget that would have funded eleven more months of a build nobody wanted goes to the next candidate in the portfolio, and the organization stops paying to discover things it could have learned in discovery.

Limitations of the Stage Gate Process

The disadvantages of the stage gate process all trace to one source: gates cost something, and the cost doesn't scale down with the size of the project.

Rigidity in fast-moving work. Phase boundaries assume the answer to "what are we building" stays stable for the length of a phase. On a product competing in a market that reprices quarterly, it doesn't. A team can be four weeks into a development phase, holding clear evidence the scoped feature set is now wrong. It can still face a choice between building something it no longer believes in or calling an off-cycle gate that nobody's calendar has room for. Agile teams resolve this at the sprint boundary. A gated program resolves it at the phase boundary, which may be nine weeks away.

Coordination overhead. Cross-functional review is the point of a gate, and it's also the expensive part. Take a board of seven people, four hours of individual preparation each, plus a two-hour session: that's 42 person-hours per gate. Across six gates, the program spends 252 person-hours, roughly 6.3 person-weeks, on governance alone. At a loaded $95 an hour, that's $23,940 — about 7.7 percent of the $312,400 build estimate from earlier, before anyone counts the calendar time lost waiting for six senior diaries to align.

Over-processing small initiatives. The same 7.7 percent applied to a $40,000 internal tool is indefensible. Organizations that mandate the full sequence for everything end up with teams routing small work around the process entirely, which produces the worst available outcome: an unofficial shadow pipeline with no review at all. Mature implementations run a lighter track — two gates rather than six, a single approver, a one-page submission — for anything below a set threshold.

One honest note on the flexibility claim above. Hold and recycle give a program real room to change direction, but that room opens between phases. Inside a phase, a gated team is committed to a scope decision that a sprint-based team could revisit in a fortnight.

Best Practices for Implementing the Stage Gate Process

Implementing the stage gate process well comes down to five decisions, and none of them is about paperwork.

Write the criteria down, then apply them the same way twice

Gatekeepers making judgment calls in the room produce decisions the team can't predict or prepare for. Published thresholds, a shared scorecard, and the same bar for every project competing for the same budget remove most of that.

Give gatekeepers actual authority to stop things

A board that can only recommend produces zombie projects — initiatives that clear every gate on momentum, absorb budget for two years, and get quietly shelved without anyone recording a decision. If the board can't kill, the gates are theater.

Right-size the weight to the risk

An enterprise platform touching eleven downstream systems earns six gates and a full business case. A three-month internal tool earns two gates and a one-page submission. Running both through the same machinery is how the process loses the people who have to work inside it.

Staff every review across functions

Engineering, product, and finance each catch a different category of problem, and a single approver catches only the category they know. One cross-functional board also settles disputes in the room rather than through three weeks of escalation.

Treat the criteria as a living document

Post-launch reviews say which gate decisions turned out right. If projects that scored well at gate 3 keep underdelivering, the scorecard is measuring the wrong thing, and the fix belongs in the criteria rather than in the next project's roadmap. Revisit them annually at minimum.

Stage Gate vs. Agile: Can You Combine Them?

The two answer different questions. A gate asks whether the organization should keep funding this work. A sprint asks what the team ships in the next fortnight. Treating them as rival methodologies is a category error that costs real programs a lot of argument.

A hybrid stage gate approach puts the gates at program level and lets Agile methodology run inside the phases. The development phase in the contractor example held nine two-week sprints. Backlog grooming, demos, and mid-sprint scope calls all stayed with the team. The review board saw the work twice: once at the decision that opened the phase, once at the gate that closed it. Nobody asked a scrum master to produce a business case, and nobody asked a steering committee to prioritize a backlog.

Where hybrids fail is usually at the specification. A gate that demands a locked, complete requirements document before development opens has imported the worst part of waterfall and called it governance. The fix is to change what the gate reviews. Instead of a full specification, the business case gate takes a defined problem, a validated architecture direction, a budget envelope, and a list of the assumptions that development will test. Detail arrives sprint by sprint, and the gate holds the money rather than the design.

Two practical adjustments make the stage gate methodology work with iterative delivery. What the board reviews shifts from documents to evidence — a working prototype and eleven user sessions beat a forty-page spec at answering whether the thing is feasible. And phase length gets set as a multiple of the sprint cadence, so a review never lands mid-sprint and forces a team to stop work three days from a demo.

Most organizations that run both end up with fewer decision points than the canonical six. Discovery and scope collapse into one. Testing folds into development as continuous validation, leaving a business case gate, a pre-launch gate, and a post-launch review. That's three formal decisions across a program instead of six, which is usually the number a senior board can actually give attention to.

How Intellectsoft Applies the Stage Gate Process

Intellectsoft doesn't hand customers a six-stage template and ask them to fill it in. The decision points are built into how engagements run.

Every custom software development engagement opens with a discovery and systems-design sprint before anyone writes production code. That sprint does the work of the first two stages in the sequence above: it establishes what problem is actually being solved and what the architecture has to support. Skipping it is how organizations inherit technical debt they spend three years paying down. Where the goal is to test a market rather than build a full system, the same questions run through MVP development instead — a narrower scope, with the business case still answered before a delivery budget is committed.

The gatekeeper problem gets solved structurally. A principal architect stays on every active engagement rather than appearing in the pitch and rotating off afterward, so the person who can approve an architectural change sits in the review rather than being summoned to it. Decisions land in the meeting. Practice leads in AI, Cloud, Data, and Design cover the functions a review board needs represented.

Process discipline is audited rather than asserted: Intellectsoft holds ISO 9001:2015, which is usually what a regulated buyer wants evidence of before approving a vendor. On one growth engagement, the team was assembled in under two months and delivered three features within the first year, with the customer recording $8M in added revenue and $24M in added valuation.

If your organization is weighing a gated framework against iterative delivery, or trying to run both without one undermi