Stage-Gate Process
Stage-Gate Process
What is the Stage-Gate process?
- Gates that decide go or kill at each stage
- Only works if Kill decisions are actually made
- Publish decision criteria before the review
The first thing Stage-Gate changes is who gets to say 'let's stop.' Until then, whether a project continued was effectively up to the project owner and their direct executive, and stopping meant admitting failure. Gates hand that judgment to a review panel outside the project and put the decision dates on the calendar in advance. The real effect is turning termination from a personal failure into a routine organizational task, which is why who you appoint as gatekeepers determines half of the process.
Gate criteria come in two kinds. Must-meet criteria eliminate a project on the spot if it fails even one; should-meet criteria score market attractiveness, technical difficulty, and fit with the existing business, then add them up to rank projects against each other. Early gates decide pass or fail on just a few days of preliminary research, while the later gates, where development spending really begins, lock in financial verification. Running every low-investment project through all 5 gates makes the management cost exceed the benefit, so it is more realistic to run projects below a set amount through an abbreviated 2-gate version.
A gate is not a progress report meeting; it is a resource allocation meeting. A pass decision must also settle the budget, staffing, and target completion date for the next stage. A gate with no budget allocation behind it hardens into a forum that adds meetings but makes no decisions. This is also where the claim that it clashes with Agile falls apart: running sprints inside a stage and keeping the gates are problems at different levels.
The most common breakdown in practice is a gate where no project is ever killed. Holds pile up instead. A hold sounds gentle, but in reality it means a project left idling with one or two owners still attached. Even five or six of these zombie projects leave no one to assign to the projects that actually have a chance. Another pitfall is tying a kill decision to the owner’s performance review. Once that happens even once, unfavorable data starts disappearing from the materials at the next gate, and the review degrades into a process for approving well-made slide decks.
John KimInstructor John Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”
Kwangdong MinExpert in business models, revenue models, and market researchDeveloped by Robert G. Cooper in the 1980s, based on his research into the success and failure factors of new product development.
Consider a hypothetical case. Company A, an auto parts maker, has 320 employees and annual revenue of about KRW 90 billion (≈ US$67,335,000). Over three years its new-product projects grew to 11, yet only 2 reached mass production, and a KRW 4.3 billion (≈ US$3,217,100) annual development budget was spread across projects at two or three people each, so none moved fast. The project began when management asked for 'a forum for choosing projects.'
- When the head of R&D laid all 11 active projects out on one page, 4 had been 'in development' for more than two years since kickoff, and one team leader said, "No one ever told me to finish, so I kept holding on to it."
- They set the CFO, the head of Sales, and the head of R&D as permanent gatekeepers, fixed the must-meet criteria for the business-case gate at KRW 3 billion (≈ US$2,244,500) in cumulative 3-year revenue and payback within 24 months, and announced them to every project team two months before the review.
- At the first review, 4 projects were terminated, and in 2 of them the team leader proposed stopping first. It mattered that the CEO stated at the start of the meeting: "No one who proposes stopping a project will be penalized in their performance review."
- Inside each stage they ran two-week sprints, but opened the gates only on fixed quarterly dates, limited review materials to a six-page template, and required submission five days in advance. The aim was to stop development from grinding to a halt while teams built slide decks.
- Eighteen months later, concurrent projects had dropped from 11 to 5, and average staffing per project had risen from 2.1 to 4.3 people. Time from kickoff to launch fell from an average of 26 months to 15, and three new products entered mass production in the same period.