What is a stage-gate process, and what happens at each gate?

Stages, gates and gatekeepers

The idea is simple: do not commit the full budget on day one. Release money in steps, and at each step check whether the project still makes sense.

• Stage: a block of work that produces the information the next decision needs, such as a feasibility study or a detailed design.
• Gate: a scheduled decision meeting at the end of a stage. It has fixed entry deliverables and fixed criteria.
• Gatekeepers: the people with authority to release funding, usually the sponsor plus finance and operations leads, sometimes a PMO or investment board.
• Gate decision: one of four outcomes. Go (approve the next stage and its budget), Kill (stop and release the resources), Hold (pause, usually for funding or priority reasons) or Recycle (redo part of the stage and come back).

Stage-gate thinking came from new product development, but the same structure appears in capital projects, IT programmes and public investment reviews. PRINCE2 uses a similar idea with management stages and end stage assessments, and the PMBOK Guide describes phase gates.

What happens at each gate

The number of gates varies. Five gates after an initial idea screen is a common, workable pattern:

Gate	Question	Evidence the gatekeepers expect
Gate 0: Idea screen	Is this worth studying?	One-page proposal, rough benefit, sponsor named
Gate 1: Feasibility	Is there a viable option?	Options compared, order-of-magnitude cost, key risks
Gate 2: Business case	Should we commit to design and planning?	Preferred option, business case, high-level schedule, risk register
Gate 3: Ready to execute	Is the plan good enough to spend the main budget?	Baseline schedule, cost estimate, procurement plan, resources confirmed
Gate 4: Ready to hand over	Is the output ready for operations?	Acceptance tests, training, support arrangements, open issues list
Gate 5: Benefits review	Did we get what we paid for?	Benefits measured against the business case, lessons learned

Early gates are cheap and fast; later gates guard larger sums and need more evidence. The most valuable gate is often Gate 2 or 3, because it is the last point before most of the money is spent.

Worked example: a gate 3 decision

An organization approved a new internal platform at Gate 2 with an estimated cost of $600,000 and expected benefits of $1,000,000 over the evaluation period. Its gate rule says: if the cost estimate grows by more than 10% between gates, the business case must be re-tested before Go.

At Gate 3 the detailed estimate is $720,000.

• Cost growth: ($720,000 − $600,000) ÷ $600,000 = $120,000 ÷ $600,000 = 0.20, so 20%. That is above the 10% trigger.
• Benefit-cost ratio at Gate 2: $1,000,000 ÷ $600,000 = 1.67.
• Benefit-cost ratio at Gate 3: $1,000,000 ÷ $720,000 = 1.39.

The project is still worth more than it costs (the ratio is above 1), but the margin has shrunk. The gatekeepers have three sensible options: Go with the higher budget and a named owner for the cost risk; Recycle to look for scope that can be deferred to bring the estimate down; or Hold if a higher-scoring project now needs the money. What they should not do is approve $720,000 while the business case still quotes $600,000.

How to run a gate review

1. Publish the criteria in advance. The project team should know exactly what the gate will check, ideally as a checklist with pass, fail and not applicable.
2. Send the gate pack a few days early. Gatekeepers read it before the meeting, so the meeting is for questions and the decision, not a presentation.
3. Look forward, not only back. Ask about the next stage: its budget, its schedule, its top risks and who owns them.
4. Make one of the four decisions. "Go, but" with a list of conditions is fine if each condition has an owner and a date. Vague approval is not.
5. Record the decision. Write down the outcome, the approved budget for the next stage, and any conditions. This is the audit trail later reviews rely on.

A short gate checklist keeps the review honest. For an execution gate it might read: business case updated with the latest estimate; baseline schedule built with logic links and a credible critical path; cost estimate reviewed by someone outside the team; top ten risks have owners and responses; contingency sized from the risk register, not as a flat guess; key suppliers and people confirmed; and acceptance criteria for the output agreed with the future owner. Each item is answered with evidence, not with "in progress".

Common mistakes with stage gates

• Gates that never kill anything. If every project passes every gate, the gates are a formality. A stopped project is a success of the process, not a failure.
• Too much paperwork for small projects. Scale the gates. A two-month internal project may need two light gates, not five.
• Work running ahead of the gate. Teams start the next stage before approval "to save time", and the gate becomes a rubber stamp for money already spent.
• No baseline at the execution gate. Without a baseline schedule and budget, there is nothing to measure progress against after Go.
• Skipping the benefits review. Without Gate 5, the organization never learns whether its business cases were realistic.

How to do this in Critova

In Critova, model each gate as a milestone in the schedule so its date is driven by the work before it and visible on the Gantt chart. Use a custom status or field to record the gate outcome, and attach the gate pack and decision minutes as files on the project. At the execution gate, save a baseline: Critova keeps unlimited baselines, so you can compare the approved plan with later forecasts. The scheduling features handle the milestones and baselines, and once work starts the earned value guide explains the CPI and SPI figures that later gates should review.