The stage-gate process in manufacturing: phases, gates, and go/kill decisions

What is the stage-gate process

The stage-gate process is a governance framework for managing new product development, capital projects and other high-risk initiatives by dividing them into structured phases of work separated by decision points. Its distinguishing feature is not the phases themselves (many methodologies use phases) but the disciplined decision gates between them, at which a cross-functional committee decides whether the project continues, terminates, pauses or returns to earlier work. Manufacturers adopted stage-gate first because the asymmetry between the cost of stopping a bad project early and the cost of stopping it late is nowhere greater than in physical product development.

The literal definition: stages and gates

A stage is a defined block of work with specific deliverables to produce. A gate is a decision point at which those deliverables are reviewed against pre-defined criteria. Everything else in stage-gate is elaboration of these two concepts. Stages are not project phases in the ordinary project-management sense; they are hypothesis-verification blocks that convert uncertainty about a product into evidence for the next decision. Gates are not status update meetings; they are binary or four-way decisions that consume authorised resources for the next stage or release those resources to the portfolio. The framework’s power comes from treating the two concepts strictly: work happens in stages, decisions happen at gates, and mixing them (deciding during work, or working during decisions) breaks the discipline that makes the framework valuable.

Origin: Robert Cooper and forty years of stage-gate

Stage-gate was formalised by Robert G. Cooper, a Canadian innovation researcher at McMaster University in Hamilton, Ontario, whose first public description of the framework appeared in 1986 after benchmarking studies of hundreds of new product development projects across dozens of companies. Cooper’s original research identified drivers of NPD success that had previously been treated as luck: portfolio focus, front-end homework, cross-functional teams, and disciplined go/kill decisions. Those findings became the Stage-Gate framework, which has evolved through five generations since. First generation was the NASA-based phased project planning of the 1960s. Second generation was Cooper’s original 1986 version. Third generation added portfolio management in the 1990s. Fourth generation added agile hybridisation in the 2000s. Fifth generation, formalised in Cooper’s 2026 Official Version published in the PDMA community, adds the four Fs (fluid, adaptable, focused, flexible) to make the framework more responsive to fast-moving markets without sacrificing governance discipline. Cooper was recognised by PDMA in 2023 for the significance of the framework to innovation management practice worldwide.

Why manufacturing adopted stage-gate first

The asymmetry between early-stage and late-stage costs is nowhere greater than in manufacturing NPD, which is why manufacturers adopted stage-gate before other industries and why roughly 80% of North American companies use some version of it today according to Stage-Gate International’s tracking data. A software product killed after six weeks of development has consumed six weeks of engineering time. A physical product killed after tooling has been committed has consumed six-figure or seven-figure euro investments in steel and equipment that cannot be recovered. That cost gradient makes the discipline of killing bad projects early worth the overhead of gate meetings and deliverable reviews. Early adopters in the late 1980s and 1990s included Exxon, Procter and Gamble, and DuPont, whose success stories helped spread the framework across industries. The natural fit with capital approval processes and regulatory documentation requirements accelerated adoption in manufacturing sub-sectors such as pharmaceuticals, medical devices and automotive.

Anatomy of a stage and a gate

Understanding stage-gate at operational depth means understanding four things: what happens inside a stage, what happens inside a gate, what the possible gate outcomes mean, and who owns the gate decision. Each of these deserves careful attention because they are the elements most often diluted when organisations adopt stage-gate superficially.

Inside a stage: activities, deliverables, cross-functional work

A stage is a defined block of work with clearly specified deliverables to produce by its end. Work inside a stage happens in parallel across cross-functional teams: R&D on the product itself, engineering on manufacturability, quality on validation requirements, procurement on component sourcing, marketing on positioning and launch planning. Deliverables are the artefacts by which the stage’s completion is judged, not merely the work outputs; they exist to feed the next gate decision, not to document the work for its own sake. Stage work is not template-filling either; it is hypothesis verification. Each stage takes hypotheses about the product (market fit, technical feasibility, commercial viability) and converts them into evidence that supports or contradicts those hypotheses, which is what the next gate committee needs to make a real decision.

Inside a gate: deliverables review, decision criteria, decision outcomes

A gate is a decision meeting, not a status update meeting. The project team presents the deliverables produced in the previous stage and argues why the project is ready for the next stage. The committee evaluates those deliverables against pre-defined criteria known to everyone in advance, not invented during the meeting. The decision is recorded with reasoning attached and archived in the project’s history, which means anyone joining the project later can reconstruct why each gate ended the way it did. Gates that do not follow this discipline degrade into status meetings where sponsors report on how work is going and no real decision gets made, which is the most common failure mode of poorly implemented stage-gate.

Gate outcomes: go, kill, hold, recycle

Cooper’s framework defines four possible gate outcomes, not two. Go means proceed to the next stage with authorised resources for that stage. Kill means terminate the project definitively and release its resources to the portfolio; kill is not the same as pause, and organisations that treat kill as reversible undermine the framework. Hold means pause the project pending resolution of specific issues within a defined timeframe, with automatic termination if the issues are not resolved. Recycle means return to the previous stage with a specific list of what needs rework and why. Kill and recycle are as important as go; a healthy stage-gate implementation shows meaningful kill and recycle rates, and their absence signals that the framework is degenerating into rubber-stamping.

Who owns the gate decision (governance)

The gate decision belongs to a cross-functional gate committee, not to a single sponsor. Typical membership includes an operations lead, an R&D or engineering lead, a marketing lead, a finance representative, and for the largest gates a member of executive leadership. The composition reflects the functions the project intends to serve; a project meant to strengthen the manufacturing base needs operations at the table, and a project meant to enter a new market segment needs marketing at the table. Rotation of members is deliberately slow (two to three years) so that portfolio context accumulates and gate committee members can compare projects across cycles. A quorum requirement prevents ad hoc decision-making with missing critical functions, and the absence of a critical function from a specific gate means the gate is postponed rather than proceeded with, which is a discipline that takes time to establish but that is essential for the framework to work as designed.

The five canonical stages of Cooper’s classic model

Cooper’s five-stage five-gate model has been the reference implementation since 1986 and remains the starting point from which the variants described later depart. Five stages separated by five gates take a project from opportunity identification through to launch and post-launch review. Each stage builds on the previous stage’s deliverables, and each gate consumes those deliverables to authorise the next stage. The description below is the canonical version; specific companies adapt names and boundaries but the underlying flow is remarkably consistent across implementations.

Stage 1: Scoping

Scoping is a fast, low-cost preliminary assessment of an opportunity. A small team spends one to four weeks and a limited budget on desk research covering the market opportunity, technical possibility, competitive landscape and preliminary business attractiveness. Deliverables are a brief scoping document, a preliminary business case with rough numbers, and a first-pass risk list. Gate 1 (Idea Screen) filters incoming ideas against basic strategic fit and feasibility criteria; Gate 2 (Second Screen) filters the surviving ideas against tighter feasibility criteria after scoping work. Together these two gates typically reduce a pool of fifty to two hundred incoming ideas down to ten or twenty concepts worth developing further, with the survival criteria weighted toward strategic alignment and preliminary market attractiveness rather than detailed feasibility (which is what Stage 2 will test properly).

Stage 2: Business case (Gate 3 “Go to Development”)

The business case stage is the deepest analytical phase before major investment gets committed. Detailed market analysis quantifies the target segment, its size, growth and competitive dynamics. Technical feasibility study confirms that the intended product can be built with acceptable cost and quality. A detailed project plan sizes the development effort with milestones, resources and budget. Financial projections calculate NPV, IRR, payback period and breakeven volume with sensitivity analysis around key assumptions. The Product Definition Package specifies features, performance requirements, target cost and target price. Gate 3 (Go to Development) is the most consequential gate in the framework because it authorises the largest single investment commitment; kill rates of 50-70% at this gate are typical in healthy implementations, and organisations with kill rates below 30% at Gate 3 usually have soft gate discipline rather than exceptional idea quality.

Stage 3: Development

Development turns the Product Definition Package into a working product. Detailed design produces engineering drawings, CAD models and bills of materials. Prototyping produces functional units for internal testing and iteration. Marketing develops the launch plan, positioning and pricing strategy. Operations develops the production plan, tooling requirements and supplier arrangements. Deliverables include working prototypes, draft marketing plans, draft production plans and updated business case reflecting what has been learned in development. Gate 4 (Go to Testing) evaluates whether the product is ready for external validation with customers and whether the surrounding plans are ready for the testing stage’s demands.

Stage 4: Testing and validation

Testing and validation is where the product meets the real market. Field trials with lead customers produce feedback on performance in actual use conditions. In-house testing covers safety, reliability (typically through accelerated life testing simulating years of use in weeks), and functional performance. Market testing validates pricing, positioning and messaging with target customer segments. Pilot production produces small volumes on production-representative equipment to surface manufacturing issues before full-rate production. Deliverables include test results, refined business case, launch readiness assessment and any remaining risk register updates. Gate 5 (Go to Launch) is the final commit before market entry; kills at this gate are rare but not zero, and problems discovered at Gate 5 are still substantially cheaper to address than problems discovered post-launch.

Stage 5: Launch

Launch executes the plans developed in earlier stages. Marketing rolls out positioning, communications and channel strategy. Production ramps from pilot to full-rate output. Sales teams get trained and start selling. Service teams handle installation, warranty and support. Regulatory approvals must be confirmed and documented before launch commences. Deliverables include the executed launch itself and a scheduled Post-Launch Review. The Post-Launch Review, held six to twelve months after launch, is not always treated as a gate in the strict sense but is canonically part of the framework because it compares actual performance against the business case that authorised the project, and its lessons learned feed a repository that improves subsequent projects’ scoping and business case work. Organisations that skip Post-Launch Review lose the framework’s most important learning mechanism.

Five variants of the stage-gate process

The classic five-stage five-gate model is the baseline, not the only option. Cooper and practitioners have developed variants that adapt the framework to different project types, industries and organisational maturity levels. Choosing the right variant matters as much as executing whichever variant is chosen, because misapplying a variant designed for a different project type is one of the most common causes of stage-gate frustration in organisations that thought they had adopted the framework correctly.

Classic 5-stage stage-gate (baseline)

The classic five-stage version is Cooper’s 1986 model and remains the reference implementation for new product development in most manufacturing organisations. It suits products with meaningful innovation content, moderate-to-high development risk, and lifecycle expectations of several years or more. End-to-end timelines are typically twelve to thirty-six months from Gate 1 through launch, with the exact duration depending on product complexity and industry regulatory context. Organisations approaching stage-gate for the first time should default to the classic version rather than reaching for a variant, because the discipline of the framework is easier to establish with the reference implementation before adapting it to specific circumstances.

Extended 7-stage for regulated manufacturing

The extended variant adds two stages for regulated products: a Regulatory Approval stage before launch and a Post-Launch Compliance stage covering ongoing regulatory obligations. Medical devices under FDA 510(k) or CE MDR, pharmaceuticals under FDA or EMA, automotive components under IATF 16949 and ISO 26262, and aerospace components under FAA or EASA all benefit from this variant because the regulatory work is substantial enough to deserve its own stage and gate rather than being folded into existing stages. Deliverables at the additional gates include design history file completion, verification and validation reports, regulatory submission dossier, and post-market surveillance plan. Timelines extend accordingly, with typical cycles running three to seven years for complex regulated products.

Express 3-stage for line extensions

The express variant compresses the framework for projects that do not need its full weight: line extensions, packaging changes, minor product improvements, or SKU proliferations that reuse existing platforms. Three stages replace five: Assessment (combining scoping and business case), Development (combining development and testing), and Launch. Two gates replace five. Timelines run three to nine months typically. The critical distinction is that Express is a deliberate variant with its own discipline, not shorthand for ad hoc skipping of gates in the classic model. Organisations that shortcut the classic model on individual projects (“this is a small one, we can skip Gate 3”) are undermining the framework; organisations that adopt Express as a documented variant for defined project types are applying stage-gate correctly.

Agile-Stage-Gate (Cooper 2016 hybrid)

Agile-Stage-Gate is Cooper’s own formalised adaptation of stage-gate for fast-moving product environments, published in 2016 and refined through subsequent case studies. The outer structure remains stage-gate with its familiar gates and cross-functional governance. Inside each stage, work happens in agile sprints of two-to-four weeks with iterative customer or stakeholder reviews. Gates become lighter, accepting agile artefacts such as demos and sprint results alongside traditional deliverables, but the governance discipline remains. Cooper and colleagues published a 2025 case study on Tetra Pak in Research-Technology Management showing how a major manufacturer with substantial hardware content adopted Agile-Stage-Gate, offering practical lessons on transformation methodology and change management for other manufacturers considering the variant. Best fit is products combining hardware and software, such as Internet of Things devices, wearables and consumer electronics.

Adaptive Stage-Gate (Cooper 5G, 2020s)

Adaptive Stage-Gate is Cooper’s Next Generation framework, published as the Official 2026 Version in the PDMA community. It builds on the four Fs: fluid (permitting overlapping stages and parallel work streams where classical stage-gate insisted on strict sequence), adaptable (allowing organisations to configure the framework per project type without leaving the framework), focused (reducing bureaucratic overhead in favour of decision quality), and flexible (accepting parallel processing and spiral development within the overall structure). Adaptive Stage-Gate also incorporates sustainability considerations through the related Eco-Stage-Gate variant published by Cooper in 2024, adding environmental criteria to gate scoring alongside traditional strategic, market, technical and financial dimensions. Adaptive suits mature organisations that have outgrown the classic framework and need a version that adapts to modern realities without abandoning the governance discipline.

Deliverables and go/kill criteria at each gate

A gate only means something if its criteria are known in advance and applied consistently. Ad hoc decisions made in the room during a gate meeting are not governance; they are politics dressed up as process. The three sub-sections below describe the discipline that separates working stage-gate from theatre: what must appear as a deliverable, how deliverables get scored, and when kill becomes the right answer.

Deliverable checklists: must-have versus should-have

Deliverables at each gate divide into must-have and should-have. Must-have deliverables are absolutely required for the gate decision to proceed: business case at Gate 3, test results at Gate 5, regulatory sign-off at the regulatory gate in the extended variant. Without a must-have deliverable, the gate goes to automatic hold without debate; the decision cannot be made without the information. Should-have deliverables strengthen the decision but do not block it: customer feedback samples, competitive analysis updates, market data refreshes. Missing should-have deliverables can result in a conditional go with agreement to complete the missing item in the early weeks of the next stage, or in recycle if the missing information is likely to change the go decision. The distinction matters because it prevents both extremes: gates that refuse decisions over minor deliverable gaps, and gates that approve projects without the information needed to make a real decision.

Scoring criteria: strategic fit, market attractiveness, technical feasibility, financial return

Cooper’s standard scoring model uses four dimensions: strategic fit with the organisation’s direction and portfolio, market attractiveness in terms of size, growth and competitive position, technical feasibility given current and attainable capabilities, and financial return in terms of expected NPV, IRR and payback against expected investment. Each dimension is scored on a one-to-ten scale with weights defined in the portfolio scoring model, and the composite weighted score is the primary input to the gate decision. Threshold scores for go decisions typically sit in the 6.5 to 7.5 out of 10 range for the composite; projects below that threshold at a gate get killed or recycled rather than proceeding. The scores themselves are less important than their consistency across projects: the framework’s value comes from applying the same scoring discipline to every project so that portfolio comparison is meaningful.

Kill criteria: when to definitively stop a project

Kill criteria are distinct from hold criteria and need to be documented separately, because kill releases resources to the portfolio while hold reserves them. Explicit kill criteria include: strategic misalignment confirmed at a level that recycle cannot address, technical infeasibility discovered that cannot be engineered around within acceptable cost, market opportunity that has disappeared or shifted decisively away from the product’s positioning, and financial return that has dropped below the cost of capital such that continuing the project destroys value. Organisations without documented kill criteria develop zombie projects that neither progress nor terminate; the framework’s discipline requires that kill be a routine, non-punitive decision when the evidence supports it, and the way to make it routine is to define in advance what evidence supports it.

Governance of the gate committee

Governance is where stage-gate implementations succeed or fail. The framework itself is straightforward; making it work in an organisation requires disciplined governance of the gate committee, the rhythm at which it meets, and the political dynamics that surround every gate decision. The three sub-sections below cover the three governance areas that separate serious stage-gate implementations from ones that produce templates but no decisions.

Who sits on the gate committee

The gate committee membership typically includes an R&D or engineering head, an operations head, a marketing head, a CFO or finance representative, and for the largest gates a CEO or general manager representing overall business direction. The composition reflects the functions the project intends to serve rather than the functions the project consumes: a project meant to strengthen manufacturing base needs operations at the table with authority to accept or reject the plan; a project meant to enter a new market needs marketing similarly empowered. Membership rotation is deliberately slow, typically two to three years, so that portfolio context and cross-project comparison capability accumulate in individual committee members. A critical rule: if a function essential to a specific gate decision cannot attend, the gate is postponed rather than proceeded with, which prevents ad hoc decision-making that lacks the perspective needed for a real decision.

The rhythm of gate meetings

Working stage-gate runs on a rhythm rather than as one-off events. Monthly portfolio review meetings typically include the gate decisions due that month, with individual gate reviews taking thirty to sixty minutes per project when the deliverables are properly prepared in advance. Quarterly strategic reviews cover the whole portfolio composition and strategic alignment. The anti-pattern to avoid is gate meetings that happen only when someone calls them, which lets projects drift and prevents the portfolio-level conversations that make individual gate decisions meaningful. The other anti-pattern is treating gate meetings as status updates where the sponsor reports on progress rather than the committee making decisions; the difference between the two is subtle in tone but decisive in effect.

The politics of gate decisions: how to avoid rubber-stamping

Rubber-stamping is the failure mode where the gate committee approves everything that comes before it without genuine analysis or challenge. Signals of rubber-stamping include kill rates below ten percent across all gates, absence of recycle decisions across a full year, project briefs distributed after the meeting rather than five business days in advance, and gate committees composed of the same people who lead the projects being reviewed (a conflict of interest that destroys the framework). Counter-measures that work: scoring criteria written and shared in advance, deliverables distributed at least five business days before the gate meeting so committee members have time to analyse them, silent scoring by each committee member before open discussion (which prevents anchor bias where the loudest voice sets the tone), and mandatory challenging questions built into every gate meeting so that at least one committee member is assigned to argue against the project’s assumptions. These practices take work to establish but produce the difference between a gate committee that governs and one that observes.

How stage-gate fits manufacturing specifically

Manufacturing was the first industry to adopt stage-gate widely and remains the reference application for the framework. Three specific manufacturing contexts benefit from stage-gate in ways that require some adaptation but validate the underlying framework: regulated products, capital projects, and new product development portfolios.

Regulated products (medical, pharmaceutical, automotive, aerospace)

Regulated manufacturing was a natural fit for stage-gate because regulatory regimes require documentation at every phase of product development, and stage-gate produces exactly that documentation as a byproduct of its normal operation. FDA design controls for medical devices map directly to stage-gate deliverables. ISO 14971 risk management activities integrate cleanly into gate reviews. IATF 16949 automotive quality management and its APQP (Advanced Product Quality Planning) sub-process align with stage-gate phases essentially by design. The design history file that regulators expect is precisely the collection of deliverables from each gate, kept versioned and audit-traceable. Manufacturers of regulated products who try to comply with regulations without a stage-gate framework typically end up reconstructing the required documentation retroactively, which is expensive, error-prone and sometimes not accepted by regulators.

Capital projects (production line investments, factory expansion)

Capital projects are not new product development, but the stage-gate framework maps to them almost as cleanly. Typical stages for capex projects: feasibility, concept design, detailed engineering, construction, commissioning and ramp-up. Each gate authorises the next tranche of capital: feasibility gate authorises concept design budget, concept design gate authorises detailed engineering budget, detailed engineering gate authorises construction commit, and so on. The sponsors on the gate committee shift from R&D-led to operations-led, with CFO representation more central than in NPD stage-gate because capex projects deal with capital commitments that need financial governance at every gate. The variant is sometimes called capital project stage-gate or capex stage-gate to distinguish it from the NPD version, but the underlying framework is the same.

NPD in manufacturing

Stage-gate is the governance framework that makes new product development in manufacturing work as an organised portfolio rather than as a collection of ad hoc projects. It is the governance backbone for managing projects in a manufacturing company at scale. The eight-stage NPD process typical of physical product development, from opportunity discovery through post-launch review, needs stage-gate governance to prevent the drift, sunk-cost thinking and scope inflation that otherwise plague NPD portfolios. Manufacturing organisations running five to thirty parallel NPD projects need portfolio-level stage-gate governance to compare projects, kill the weakest ones and reallocate resources to the strongest, decisions that individual project reviews cannot support. The combination of manufacturing NPD process and stage-gate governance is one of the reasons manufacturing organisations pioneered stage-gate and still produce most of the framework’s success cases decades later. Stage-gate governs which new products and capital projects advance through decision gates; it is distinct from shop-floor improvement methods such as lean management in production and the SMED method, which streamline existing operations rather than gate new-product decisions.

Common pitfalls and how to avoid them

Four failure patterns account for most stage-gate implementations that produce templates without producing decisions. PDMA benchmarks show that top-quartile organisations reach NPD success rates around 76% versus roughly 51% for the rest, and disciplined stage-gate governance is one of the levers separating those groups. Each of the four pitfalls below is preventable once the organisation names it and builds explicit counter-measures into its governance.

Gates as rubber stamps

The first pattern is rubber-stamping: the gate committee approves everything that comes before it without genuine analysis, and kill rates across a full year drop below ten percent. Healthy stage-gate implementations show cumulative kill rates of thirty to fifty percent across all gates, driven mostly by kills at Gate 3 (Go to Development) and Gate 5 (Go to Launch). Signals of rubber-stamping include zero recycle decisions across a year, gate meetings that always end within twenty minutes, and post-launch reviews that consistently show projects meeting the letter of their business cases while missing their strategic intent. The counter-measure is measuring kill rate as an explicit key performance indicator of the gate committee itself and reviewing it regularly at board or executive level, which transforms kill rate from a hidden signal into an observable metric with accountability attached.

Deliverables never rejected

The second pattern is deliverable acceptance without discipline: the gate committee accepts incomplete or low-quality deliverables rather than sending the project back for rework. This pattern degrades the framework because project teams learn quickly that partial deliverables will pass, which lowers the quality bar over time and eventually reaches a point where deliverables no longer support real decisions. The counter-measure is a hard-stop mechanism for must-have deliverables: if a must-have deliverable is missing or fails minimum quality standards, the gate goes to automatic hold without debate. Project teams recalibrate quickly once they experience the hard stop; the framework requires that the committee be willing to enforce it a small number of times to establish the pattern.

Skipping stages under time pressure

The third pattern is stage skipping under schedule pressure: the argument that a specific project is obviously worth doing, so skipping the business case stage will save time and money. The consequence is that the business case gets written retroactively to justify an investment that has already been committed, which defeats the purpose of the business case. The counter-measure is offering Express Stage-Gate as a legitimate variant for projects that genuinely do not need the classic five-stage discipline (line extensions, minor improvements, SKU proliferations reusing existing platforms), while enforcing the classic framework strictly for projects that do fall within its intended scope. The distinction between Express as a documented variant and ad hoc skipping matters: the former is disciplined adaptation, the latter is discipline collapse.

No portfolio view above the projects

The fourth pattern is stage-gate operating at project level without portfolio context: each gate decision considers the individual project on its merits rather than considering it against alternative uses of the same resources. The consequence is drift toward incremental projects that are individually reasonable but collectively fail to advance the manufacturer’s strategic direction, because no forum exists at which projects compete against each other for finite investment capacity. The counter-measure is embedding gate decisions within portfolio review meetings so that the committee sees the full portfolio dashboard before evaluating any individual project, and adding explicit portfolio-level questions to every gate decision: is this project the best use of the resources it is requesting, or would those resources produce more value on a different project already in the portfolio.

How FlexiProject supports stage-gate execution

FlexiProject sits in the project portfolio management layer of the manufacturing technology stack, above operational systems and below the strategic direction layer. It does not implement stage-gate decisions themselves; it provides the operational infrastructure that makes stage-gate governance workable at scale across a portfolio of projects.

Phase templates aligned to stage-gate

FlexiProject provides stage-gate phase templates out of the box, configurable per project type (NPD, capital projects, IT initiatives). Each template carries the phase structure, deliverable checklists, gate criteria and scoring dimensions appropriate to its project type, so project teams work inside a consistent framework rather than reconstructing it for each new project. Templates for the classic five-stage, express three-stage and extended seven-stage variants are available and configurable, and organisations can add their own variants when their process maturity warrants it.

Acceptance workflows for gate decisions

Gate decisions are implemented as acceptance workflows in FlexiProject with automated notifications to the gate committee members and structured deliverable review. The go, kill, hold or recycle decision is recorded with reasoning attached, and the versioned history of the project charter and deliverables is preserved for later reference. Committee members can review deliverables in advance of the gate meeting through the workflow rather than seeing them for the first time in the room, which is the practice that supports genuine decisions rather than rubber-stamping.

Deliverable versioning and audit trail

Every deliverable in FlexiProject is versioned automatically, and the audit trail records who submitted, reviewed, approved or rejected each version. The audit trail meets the documentation requirements of regulated industries: FDA design controls, ISO 14971 risk management records, IATF 16949 automotive quality documentation, and the audit expectations of most regulatory regimes reviewing manufacturing NPD documentation. Reconstructing the state of a project at any historical gate is a routine query rather than an archaeological exercise, which is what regulators expect and what internal governance benefits from as well.

What FlexiProject does not do

FlexiProject does not make gate decisions; that is human work that cannot be automated, and organisations that expect a tool to replace committee judgment are misunderstanding what stage-gate is about. It does not produce deliverables either; project teams still write business cases, run test programmes and generate the artefacts that gates review. It does not replace domain-specific systems such as CAD for design, PLM for product data management, MES for production execution or ERP for financial transactions. It sits in the governance and portfolio management layer, integrating with the operational systems around it rather than trying to become them.

Frequently asked questions

How many gates should we have?

The answer depends on the project type and stage-gate variant. Classic five-stage stage-gate has five gates. Express three-stage has two or three gates. Extended seven-stage for regulated products has seven gates. Adding gates beyond what the project type requires does not improve governance; it adds bureaucracy without adding decision quality. Reducing gates below the variant’s design compromises the discipline the framework was built to enforce. The right number is the number defined by the variant appropriate to the project type, applied consistently across projects of the same type in the portfolio.

Can we skip gates for simple projects?

Not in the classic five-stage model, and doing so undermines the framework. For projects that genuinely do not need the classic framework’s weight, the correct approach is the Express three-stage variant, which is a documented and disciplined reduction of the framework rather than ad hoc skipping. The distinction matters: Express is a deliberate variant with its own gates and criteria; skipping is discipline collapse dressed up as pragmatism. Organisations adopting stage-gate should decide in advance which project types get Classic, which get Express and which get Extended, then enforce those choices strictly.

What is the difference between stage-gate and Waterfall?

Waterfall is a linear execution approach that treats projects as sequences of phases without explicit decision points between them. Stage-gate looks superficially similar because it also treats projects as sequences of phases, but the decision gates between phases are the essential difference. In Waterfall, projects proceed from phase to phase automatically because the plan says so; in stage-gate, projects proceed from stage to stage only if the gate committee decides they should, and the gate can kill or recycle the project instead. Stage-gate is effectively Waterfall plus governance plus the option to stop, which changes the framework’s character significantly even if the diagrams look alike.

How do we transition from ad hoc to stage-gate?

Start with a pilot involving one or two projects rather than converting the whole portfolio at once. Copy an existing stage-gate implementation (Cooper’s classic five-stage is well-documented and freely available) rather than designing your own from scratch, because the framework’s discipline comes from decades of refinement and reinventing it locally usually produces a weaker version. Establish the gate committee with real authority from the first day, because a stage-gate framework without decision authority at the gates degrades to templates and status meetings. Measure kill rate from the beginning as an explicit metric of gate committee performance, because kill rate is the earliest signal of whether the framework is working as designed or degenerating into rubber-stamping.

Is stage-gate compatible with Agile?

Yes, through Agile-Stage-Gate, which is Cooper’s own 2016 hybrid combining stage-gate governance with agile execution inside individual stages. Pure agile without stage-gate governance rarely works well for manufacturing NPD because hardware iteration cycles are too long for meaningful sprint cadence and because regulated manufacturing needs the documentation discipline that stage-gate produces naturally. Classic stage-gate without agile works well for pure hardware development where iteration inside stages does not add much value. The combination that works well in mature manufacturing organisations depends on the product mix, with Agile-Stage-Gate favoured for hardware plus software products and classic stage-gate favoured for pure hardware.

The stage-gate process is the reference governance framework for managing new product development, capital projects and other high-risk initiatives in manufacturing, developed by Robert G. Cooper in 1986 and now in its fifth generation with roughly 80% of North American companies using some version of it. Its anatomy is simple: stages hold structured cross-functional work with specific deliverables, gates hold decisions taken by a cross-functional committee against pre-defined criteria, and the four possible gate outcomes (go, kill, hold, recycle) treat termination and rework as decisions as important as continuation. Cooper’s five canonical stages run Scoping, Business Case, Development, Testing and Validation, and Launch, with Gate 3 (Go to Development) being the most consequential and kill rates of 50-70% at that gate typical in healthy implementations. Five variants of the framework adapt it to different project types: Classic 5-stage as the baseline, Extended 7-stage for regulated manufacturing, Express 3-stage for line extensions, Agile-Stage-Gate for hardware plus software products, and Adaptive 5G published in Cooper’s 2026 Official Version incorporating the four Fs. Governance is where implementations succeed or fail: a gate committee with real authority, deliverable checklists and scoring criteria known in advance, and a monthly rhythm treating gates as decisions rather than status updates separate working stage-gate from theatre. Four common pitfalls (rubber-stamping, weak deliverable discipline, ad hoc stage skipping, absence of portfolio view) are all preventable with named counter-measures. FlexiProject provides the project portfolio layer that makes stage-gate governance workable at scale, with phase templates, acceptance workflows, versioned deliverables and audit-grade documentation for regulated products, without trying to make gate decisions itself or to replace the operational systems around it. If a manufacturer’s stage-gate implementation has outgrown spreadsheets and email and needs a portfolio system that supports the classic, express or agile variants, thirty days of full access with no credit card is a practical way to test the fit.