A stage gate is a scheduled decision point in a project where a sponsor decides whether the work continues, changes, or stops. This article covers the six stages of a technology investment, how gates fit with agile delivery, and where they go wrong.
A stage gate is a scheduled decision point in a project where a sponsor decides whether the work continues, changes, or stops. The project is divided into stages, and between each stage sits a gate, where someone with the authority to spend money looks at what the stage produced and makes a call.
The method came out of Robert Cooper’s research on product development in the 1980s, and the vocabulary has since spread to capital projects, technology programs, drug development, and government portfolios. The specifics vary from industry to industry. The shape stays the same: work, then a decision, then more work, and nobody carries on by default. That last clause matters most. It is also the first thing a committee gives up.
A gate is a decision with three conditions attached. Take any one away and you are left with a status meeting that has a calendar invite.
Someone can say no. If the only available outcomes are “continue” and “continue with concerns”, the gate is theatre, and a real gate has stop on the menu where everyone in the room can see it.
Evidence sits in front of the decision-maker. That evidence is the business case, the current cost against the baseline, the risks that have materialised, and the changes approved since the last gate, and a summary of it, assembled by the person seeking approval, sits one step removed from all four.
The decision is recorded with its reasoning. The record shows who decided, when, on what basis, and what they were looking at. Two years later, when someone asks why the program went the way it did, the answer is either written down or it is folklore.
Frameworks differ on the number of stages, and the names change by industry. Five and six are both common. A version that holds up for technology investments runs six stages, and each one ends at a gate.
Discovery asks whether there is a problem worth solving and roughly what it would cost to solve. Keep this work cheap on purpose.
Approval is where the sponsor weighs the business case, which covers what the investment is, what return it underwrites, and who is accountable for delivering it, and the money is committed here and the baseline is set.
Initiation breaks the scope into work packages with owners, budgets, and dates. The governance seats get filled.
Delivery is the work itself, often the longest stretch by months, and gates recur at intervals during it, so the question shifts from should we start to is this still worth finishing.
Close-out asks what we built and what it cost.
Benefits realisation comes months later, with the thing in production, and asks whether the return arrived. It is the easiest stage to drop, because it happens after the team has dispersed. Skipping it is why the numbers in the next business case earn so little trust.
Teams that deliver in an agile way often object to stage gates, and the objection mostly rests on a misreading.
Agile methods govern how work gets done. They rely on small increments, continuous delivery, and decisions pushed to the team closest to the problem. Stage gates govern whether the investment continues. That is a different question, asked by a different person, on a different clock.
A team can ship continuously all quarter and still owe its sponsor an answer about whether the thing is worth the next quarter’s funding, because the two methods work at different altitudes.
The failure mode people remember is real. Someone bolts a stage-gate process onto a delivery team as a series of documents to produce and meetings to attend, and the team pays it like a tax. The test is whether the gate changes a decision. If the answer at every gate was always going to be yes, the gate was overhead and the team was right to resent it.
A gate that cannot say no ratifies a choice somebody already made. By the time the meeting happens, the money is committed and the team is hired. The decision was made three months ago.
Evidence assembled by the person being assessed is a curated argument. The project manager builds the pack, which is reasonable because they know the detail, but a pack built on a Tuesday for a Thursday meeting is out of date by the time the sponsor decides.
A missing baseline makes cost variance meaningless, because variance needs a number that was agreed and frozen, and if someone quietly resets the baseline every time the forecast moves, everything is always on budget.
An unowned benefit leaves the return with nobody accountable. The gate that approves the spend names a sponsor, while the stage that checks whether the return arrived often names nobody, because it happens after the team has dispersed and leaves no record.
A gate that can only block gets routed around, because teams avoid a gate whose one power is to stop work, and a gate that shapes the next decision is one they will turn up to, with better evidence in hand.
A sponsor should be able to answer three questions at any moment, without commissioning anything:
If answering those means someone spends a day pulling delivery status out of one system, budget out of a spreadsheet, and the original case out of a slide deck, the governance record does not exist. What exists is a reconstruction, rebuilt monthly, accurate on the day it is presented and decaying from then on.
The better arrangement makes the record the source. It stays current as a by-product of the work, and the meeting reads straight from it.
Tollgate runs stage-gated investment governance inside Jira. It holds the business case, whose financial case calculates NPV, IRR, and payback from the cashflows you enter. The approved baseline stays fixed, and changes go through change control. Risks & Opportunities, an append-only decision log, and Changes sit on the same record, and during Benefits Realisation the sponsor sets realised benefits beside what the approved case expected. Gate states are advisory, so the sponsor makes the call and the record shows it. Tollgate is built on Forge. The data stays in your own Atlassian tenancy.
Tollgate keeps the business case, the gate decisions and the payoff in one record, next to the delivery they pay for.