Stage gates that make real decisions: go, hold, recycle or stop

Many organisations divide projects into stages separated by gates: formal points where someone decides whether the work should continue. Product developers use gates between concept, design, prototype, tooling and launch. Capital projects use them between idea, feasibility, design, procurement and construction. Software, research and improvement programs have their own versions. The idea is sound. Commit money and effort in increments, and stop to make a fresh decision before committing more.

In practice, many gates do not decide anything. The project team prepares a pack of documents, a meeting is held, questions are asked and the project proceeds as it always would have. Gates become a compliance ritual, a checklist of deliverables rather than an investment decision. Projects that should have been stopped continue, because nobody ever says no at a gate. Teams learn to treat gates as hurdles to clear rather than as moments to step back and think.

A stage gate is valuable only if it can change what happens next. This article explains, in general terms, what gates are for, the decisions they should be able to make, how to design criteria and choose gatekeepers, how to scale gates to the size of the work and the patterns that turn gates into rubber stamps. It is general information drawing on widely used stage-gate and project lifecycle practice.

What a gate is for

A gate is an investment decision. At each gate, the organisation decides whether to commit the resources needed for the next stage, given what it now knows. Each stage is designed to reduce uncertainty, through research, design, testing or market work, so that the next decision can be made on better information.

That framing has important consequences. The question at a gate is not “has the team done its work?” but “knowing what we know now, should we invest in the next stage of this project rather than in something else?” A team can have done excellent work that reveals the project should stop. That is a successful stage, not a failed one.

The cost of stages usually rises as projects progress. A concept study may cost a few thousand dollars; tooling and launch may cost hundreds of thousands. Gates are most valuable at the early, cheap stages, where stopping a poor project saves the expensive later stages entirely. The cost you commit before you spend article explains why most of a project’s cost is determined by decisions made early.

The four decisions a gate can make

A gate that can only say “go” is not a gate. Real gates have at least four possible outcomes:

A conditional go, approving the next stage subject to specific conditions being met by a stated date, is also common and useful, provided the conditions are tracked.

Organisations that never stop projects at gates should be suspicious of their gates. Some projects inevitably turn out to be poorer than expected. If none are stopped, they are being carried forward by momentum, not decided.

Deliverables and criteria are different things

Every gate has two components that are often confused.

Deliverables are what the team brings to the gate: market research, concept designs, cost estimates, risk assessments, test results, a business case, a plan for the next stage. They are the evidence.

Criteria are the questions the gatekeepers use to judge that evidence. A common structure separates:

• Must-meet criteria: knock-out questions that must be satisfied for the project to proceed, such as strategic fit, legal and safety feasibility, or availability of essential resources.
• Should-meet criteria: factors scored to judge attractiveness and rank the project against others, such as market attractiveness, competitive advantage, technical feasibility, return relative to risk and alignment with existing capabilities.

The most common failure is to treat the existence of deliverables as passing the gate. A gate pack that contains every required document can still describe a project that should stop. Criteria keep the attention on the decision.

Gatekeepers need authority

The people making gate decisions, often called gatekeepers, must have the authority to commit, withhold or redirect the resources the next stage needs. If they cannot, the gate is advisory and the real decision happens elsewhere.

Good gatekeeping practice includes:

• The right people. Senior enough to commit resources, and drawn from the functions the next stage will draw on, such as engineering, operations, sales and finance.
• Consistency. The same gatekeepers for a project across gates where possible, so they build understanding and hold the team to earlier commitments.
• Preparation. Reading the materials before the meeting, so the time is spent on judgement rather than presentation.
• Decisions on the day. A clear decision, recorded with reasons and conditions, rather than “let’s discuss it offline”.
• Accountability for the portfolio. Gatekeepers should see each project in the context of the others competing for the same people and money.

Gates and the portfolio

A gate decision is not only about the project in front of the gatekeepers. Every “go” commits resources that cannot be used elsewhere. Gates should therefore be connected to portfolio decisions: the gatekeepers need to know what else is waiting for the same engineers, the same capital or the same production capacity. The saying no to good projects article explains why good projects sometimes need to be declined in favour of better ones.

In practice, this means gate meetings benefit from a simple view of current commitments and capacity. A project that passes every criterion may still be held if launching it now would overload a critical team.

Scaling gates to the work

Applying the full gate process to every small project creates bureaucracy and pushes people to avoid the system. Scaling is essential:

• Major projects may use five or more gates with detailed deliverables and independent review.
• Moderate projects may combine stages, using three gates: approval to investigate, approval to develop and approval to launch or build.
• Small or low-risk projects may need a single approval with a simple checklist.

The criteria for choosing the track should be explicit, typically based on cost, risk, strategic importance and novelty. Some organisations also allow fast-tracking for urgent work, with the gates compressed rather than skipped.

What each stage should resolve

Stages are most useful when each is designed to resolve the most important uncertainties at that point. A generic product development sequence might look like this:

1. Idea screen. Is this worth a small amount of investigation? Strategic fit, rough market need, obvious show-stoppers.
2. Scoping. Quick, inexpensive research into the market, technical feasibility and likely cost.
3. Business case. Detailed definition of the product, customer validation, technical approach, financial analysis and a plan for development.
4. Development. Design, prototypes and initial testing.
5. Testing and validation. Field trials, production trials, certification and final costing.
6. Launch. Full production and market launch.

The specific stages vary by industry and project type, but the principle holds: each stage buys the information needed to make the next commitment wisely. The notes on prototyping article explains how prototypes can be designed to answer specific questions rather than simply demonstrate progress.

Why gates become rubber stamps

Several forces push gates towards approval regardless of merit:

• Sunk cost. The more already spent, the harder it feels to stop, even though past spending is irrelevant to whether future spending is worthwhile.
• Advocacy. Teams present their projects as positively as possible, and gatekeepers may lack the time or information to challenge.
• Relationships. Stopping a colleague’s project feels personal.
• Executive sponsorship. A project championed by a senior leader can be hard to stop.
• No alternatives in view. Without seeing what else the resources could do, any reasonable project looks worth continuing.
• Gates held too late. If the gate occurs after the next stage’s commitments have already been made, such as tooling ordered before the tooling gate, the decision is a formality.

Countermeasures include independent review of key deliverables, explicit consideration of alternatives, criteria agreed in advance, separating the project’s advocate from the decision-makers and recording the reasons for each decision so patterns can be examined later.

Measuring whether gates work

A few simple measures help show whether gates are making real decisions:

• the proportion of projects stopped or held at each gate;
• the stage at which stopped projects were stopped, since earlier is cheaper;
• how often projects return to the same gate after recycling;
• forecast accuracy, comparing gate-stage estimates with outcomes; and
• the commercial results of launched projects compared with their gate-stage business cases.

An organisation where most stopped projects are stopped late, after major spending, has gates that are not working early enough.

A worked example

This is an illustrative example. The business, figures and events are hypothetical.

A small manufacturer of agricultural equipment uses four gates for new products. A proposed self-levelling trailer hitch passes the idea screen and a $6,000 scoping stage. At the business case gate, the team presents strong engineering work and a forecast of 1,200 units a year at a margin of $85 per unit. The development stage would cost $140,000, including prototype tooling.

The gatekeepers check the must-meet criteria: strategic fit, no safety or legal show-stoppers, engineering capacity available in the next quarter. All pass. On the should-meet criteria, they question the volume forecast. It rests on conversations with two dealers, and no farmers have been asked whether they would pay the proposed price. They also note that two other projects need the same design engineer.

Rather than “go”, they decide recycle with conditions: spend up to $8,000 and six weeks on customer validation, using a simple prototype and structured interviews with twenty farmers, and return with a revised volume and price assessment. The validation shows strong interest but at a lower price, which reduces the margin to $55 per unit, and suggests a realistic volume of about 900 units. Annual contribution falls from roughly $102,000 to roughly $49,500. At the second business case gate, the project still meets its return threshold, but ranks below one of the competing projects. The gatekeepers decide hold for one quarter, and approve the competing project first.

The gate process cost $8,000 and six weeks. It prevented a $140,000 development commitment based on an untested forecast and ensured the scarce design engineer worked on the stronger project first.

How this applies to a small Australian business

• Use a few simple gates. Three or four decision points are enough for most small businesses.
• Write down the criteria. Agree the must-meet and should-meet questions before projects arrive.
• Decide on the day. Record go, hold, recycle or stop, with reasons and conditions.
• Hold gates before commitments. Do not order tooling or sign contracts before the gate that is supposed to approve them.
• Look at alternatives. Keep a short list of other projects competing for the same people and money.
• Make stopping normal. Praise teams for surfacing evidence that a project should stop.

Common mistakes

• Gates that can only say yes. Without real hold, recycle and stop options, gates are rituals.
• Confusing deliverables with criteria. A complete pack is not a sound case.
• Gatekeepers without authority. If the real decision is made elsewhere, the gate is theatre.
• Gates after commitments. Approving a stage whose costs are already committed decides nothing.
• One process for everything. Full gates on small projects breed avoidance.
• Ignoring sunk cost bias. Past spending should not justify future spending.
• Not tracking conditions. Conditional approvals are meaningless if the conditions are never checked.

Frequently asked questions

How many gates should a project have? As many as there are major commitments worth deciding separately. For most small and medium projects, three or four is enough.

Should gatekeepers be independent of the project? They should be able to judge it objectively. The sponsor may attend, but decisions benefit from people who are not advocates.

Is a stage-gate process compatible with agile development? Yes. Many organisations use gates for investment decisions while teams work iteratively within stages. The gate decides whether to fund the next increment; the team decides how to do the work.

Questions to ask

• What can each of our gates actually decide, and when did we last stop a project at one?
• Are our criteria written down and used, or do we judge on presentations?
• Do our gatekeepers have authority over the resources the next stage needs?
• Are any commitments being made before the gate that is meant to approve them?
• Do gate decisions consider other projects competing for the same resources?
• Are our gates scaled to project size and risk?
• Do we track conditions attached to conditional approvals?

Bringing it together

A stage gate is an investment decision, not an inspection. It works when each stage is designed to resolve the most important uncertainties, when gatekeepers with real authority judge the evidence against agreed criteria, when the decision can genuinely be go, hold, recycle or stop, and when the gate happens before the next stage’s commitments are made. Organisations that make stopping and holding normal, scale gates to the size of the work and connect gate decisions to the wider portfolio spend less on projects that should never have continued, and more on those that deserve to.

---

Source: KEVOS editorial notes. Examples and figures in this article are illustrations.