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; between each stage sits a gate.
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; between each stage sits a gate. At the gate, someone with the authority to spend money looks at what the stage produced and makes a call.
The method came out of product development research in the 1980s, and the vocabulary has spread well beyond it — capital projects, technology programs, drug development, government portfolios. The specifics vary. The shape does not: work, then a decision, then more work, and nobody carries on by default.
That last clause is the whole point, and it's the first thing a committee gives up.
A gate is not a status meeting. Three things have to be true or it isn't a gate at all.
Someone can say no. If the only available outcomes are "continue" and "continue with concerns", the gate is theatre. A real gate has a stop on the menu, and everyone in the room knows it.
There is evidence in front of the decision-maker. Not a summary of the evidence assembled by the person seeking approval. The business case, the current cost against the baseline, the risks that materialised, the changes approved since the last gate.
The decision gets recorded with its reasoning. 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. Five and six are both common, and the names change by industry. A version that holds up for technology investments runs like this:
Discovery. Is there a problem worth solving, and roughly what would it cost to solve? Cheap work, deliberately.
Business case. What is the investment, what return does it underwrite, and who is accountable for delivering it? This is the gate where the money gets committed and the baseline gets set.
Initiation. Scope broken into work packages, budgets and dates baselined, governance seats filled.
Delivery. The work. Gates here are periodic rather than terminal — the question shifts from should we start to is this still worth finishing.
Close-out. What did we actually build, what did it cost, and what happens to the loose ends.
Benefits realisation. Months later, with the thing in production, did the return arrive? This is the stage almost everyone skips, and skipping it is why nobody believes the numbers in the next business case.
This is worth addressing directly, because the objection is common and mostly based on a misreading.
Agile methods govern how work gets done — small increments, continuous delivery, decisions pushed to the team closest to the problem. Stage gates govern whether the investment continues — 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. Those are not competing methods. They're different altitudes.
The failure mode people remember is real, though: a stage-gate process bolted onto a delivery team as a series of documents to produce and meetings to attend. That's not governance, it's tax. The distinction 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.
The gate that cannot say no. By the time the meeting happens, the money is committed, the team is hired, and the decision was made three months ago. The gate ratifies rather than decides.
Evidence assembled by the person being assessed. The project manager builds the pack. Reasonable — they know the detail. But a pack is a curated argument, and it's usually built on Tuesday for a Thursday meeting, which means it's already out of date by the time the sponsor decides.
No baseline to compare against. Cost variance is meaningless without a number that was agreed and frozen. If someone quietly resets the baseline every time the forecast moves, everything is always on budget.
Nobody owns the benefit. The gate that approves the spend names a sponsor. The stage that checks whether the return arrived often names nobody, happens after the team has dispersed, and produces no record.
Gates that block rather than inform. Teams route around a gate whose only power is to stop work. They use a gate that shapes the next decision.
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 doesn't exist. What exists is a reconstruction, rebuilt monthly, accurate on the day it's presented and decaying from then on.
The alternative is that the record is the source, kept current as a by-product of the work, and the meeting reads from it rather than about it.
Tollgate runs stage-gated investment governance inside Jira — the business case with its financial model, work packages baselined at approval, the risk register, an append-only decision log, and benefits realisation against the case that was originally approved. Forge-native, so 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.