A stage gate review template is the standing structure that turns a gate meeting into a real decision. Without one, gate reviews drift into status updates: the team presents, everyone nods, the project continues by default. With one, the same five questions get asked at every gate, the required evidence shows up before the meeting, and "kill" stays on the table as a genuine outcome. This page gives you that structure: the agenda, the criteria checklist, the deliverables each gate expects, and the decision log that records what was actually decided.
The template here is deliberately framework-neutral. It works whether you run a classic five-stage model, a leaner three-gate flow, or an agile stage gate hybrid. For the underlying model these reviews sit inside, see the stage gate process; this page is the operational paperwork that makes each of its gates run the same way every time.
Key takeaways
- A stage gate review template standardizes the agenda, criteria, deliverables, and decision so every gate runs the same way.
- The criteria checklist separates must-meet knockout questions from should-meet scorecard items.
- Every gate ends in one of four logged decisions: go, kill, hold, or recycle.
- Required deliverables are agreed in advance so the meeting reviews evidence, not opinions.
- A decision log captures the outcome, owner, conditions, and date so the next gate starts from a known position.
What is a stage gate review template?
A stage gate review template is a reusable document that defines how every gate meeting runs: the agenda, the pass/fail criteria, the deliverables the project must present, and the decision the gatekeepers record. It exists so that gates are judged on consistent evidence rather than on who presents most confidently. The same project, reviewed against the same criteria each time, is far harder to wave through on momentum alone.
The template is not the gate. The gate is the decision; the template is the scaffolding that keeps the decision honest. A good one fits on two pages and gets reused at every gate in the project, with only the stage-specific criteria changing. If your template needs a facilitator to interpret it, it is too complicated to survive contact with a busy steering group.
What should a stage gate review template include?
A stage gate review template should include five sections: a gate header, a timed agenda, a criteria checklist split into must-meet and should-meet items, the list of required deliverables, and a decision log. Those five pieces cover the full life of a gate, from what is being reviewed to what was decided and who owns the follow-up. Everything else is optional detail.
Here is the structure laid out as a single reusable table. Copy it, rename the stages to match your model, and fix the criteria once so the wording does not shift meeting to meeting.
| Section | What it captures | Why it matters |
|---|---|---|
| Gate header | Project name, gate number, date, sponsor, gatekeepers present | Identifies which decision this is and who owns it |
| Agenda | Timed blocks: summary, criteria review, risks, decision, next steps | Keeps a go/kill meeting to 45 to 60 minutes |
| Criteria checklist | Must-meet knockout questions and should-meet scored items | Makes the pass standard explicit and repeatable |
| Required deliverables | Business case, plan, budget, risk log, stage outputs | Forces evidence to exist before the meeting, not during it |
| Decision log | Outcome, conditions, owner, date, next gate | Records what was decided so nothing reopens by accident |
What are the gate review criteria?
Gate review criteria fall into two groups: must-meet knockout questions that fail the gate outright if unmet, and should-meet questions that are scored and weighed. The split matters because not every criterion deserves equal power. A failed legal or safety check should stop a project regardless of how strong the business case looks, while a slightly weak market estimate is a discussion, not an automatic kill.
Keep the criteria list short enough that the group can actually work through it in the meeting. A practical set covers five dimensions: strategic fit, business case, delivery readiness, risk, and capacity.
| Dimension | Knockout question (must-meet) | Scored question (should-meet) |
|---|---|---|
| Strategic fit | Does this still map to a current portfolio priority? | How strongly does it support the priority versus alternatives? |
| Business case | Is the case still positive on updated numbers? | How confident are we in the cost and benefit estimates? |
| Delivery readiness | Are the prior stage deliverables complete and approved? | How realistic is the plan for the next stage? |
| Risk | Are there any unmitigated red risks? | How well understood and owned are the open risks? |
| Capacity | Do we have the people to staff the next stage? | What does funding this displace in the portfolio? |
Capacity is the criterion most teams forget, and it is the one that protects the rest of the portfolio. A project can clear every other gate and still be the wrong thing to fund this quarter because the people it needs are already committed. Tie this criterion to your resource and capacity planning so a gate "go" cannot quietly overcommit a team that is already full.
What deliverables are required at a gate review?
The required deliverables at a gate review are the evidence the gatekeepers need to judge the criteria: an updated business case, the next-stage plan and budget, the current risk log, and the completed outputs of the stage just finished. Agreeing this list in advance is what separates a real review from a presentation, because the team cannot improvise its way past a missing budget or an unsigned prior deliverable.
Required deliverables change by gate. The early gates lean on the case and the plan; the later ones lean on test results and readiness evidence. A reusable checklist per gate keeps everyone honest about what "ready to review" means.
| Gate | Decision in focus | Required deliverables |
|---|---|---|
| Gate 1 (after scoping) | Is this worth a business case? | Scope statement, rough sizing, strategic fit note |
| Gate 2 (after business case) | Do we fund development? | Full business case, plan, budget, risk log |
| Gate 3 (after development) | Do we fund testing? | Build status, updated case, test plan, open issues |
| Gate 4 (before launch) | Are we ready to release? | Test results, readiness checklist, support plan |
What are the possible gate review decisions?
A gate review ends in one of four decisions: go, kill, hold, or recycle. Go releases funding for the next stage; kill stops the project for good; hold pauses it pending a named condition; and recycle sends it back to rework specific gaps before it can pass. Naming all four out loud matters, because a template that only offers go and not-yet quietly trains the group to never actually stop anything.
The decision is only useful if it is recorded with its conditions. A "conditional go" with no written condition is just a go, and the condition is forgotten by the next status meeting. Capture the outcome, the condition, the owner, and the date in a decision log so the next gate opens from a known, agreed position.
| Decision | Meaning | What gets logged |
|---|---|---|
| Go | Fund the next stage as planned | Approved budget and next gate date |
| Conditional go | Proceed once a named condition is met | The exact condition, owner, and deadline |
| Hold | Pause pending a decision or dependency | What the project is waiting on and the review date |
| Recycle | Rework specific gaps, then re-present | The gaps to close and the re-review date |
| Kill | Stop the project and release its resources | The reason and where the freed capacity goes |
What does a stage gate flow chart look like?
A stage gate flow chart shows stages as boxes and gates as diamonds between them, with each diamond branching into the possible decisions. Work flows left to right through a stage, hits a gate, and either continues to the next stage on a go, loops back on a recycle, pauses on a hold, or exits the flow on a kill. The diamond is the visual reminder that progress is conditional, not automatic.
You do not need software to draw it. The core sequence is: Stage 1, Gate 1, Stage 2, Gate 2, and so on, with a "kill" exit arrow leaving every gate and a "recycle" arrow returning to the stage just completed. Putting the kill arrow on the diagram, in front of the steering group, is a quiet but real governance act. It makes stopping a visible, designed option rather than a failure nobody planned for.
How long should a gate review meeting take?
A gate review meeting should take 45 to 60 minutes when the deliverables are circulated in advance. The reading happens before the meeting, so the time in the room goes to the decision, not to a walkthrough of slides everyone could have read. If your gate reviews routinely run two hours, the problem is almost always that evidence is being presented live instead of reviewed beforehand.
Protect the format by sending the required deliverables at least two business days ahead and opening the meeting at the criteria, not at a project recap. The agenda in the template above is built for this: a short summary, straight into the criteria, then risks, then the decision. The discipline of the clock is part of what makes the gate a control rather than a ceremony.
How a gate template fits the wider portfolio
A single project's gate template only pays off when every project uses the same one. Consistency across the portfolio is what lets leadership compare a "go" on one initiative against a "hold" on another and trust that both were judged the same way. That is a governance outcome, not a project one, which is why the template belongs to the PMO and not to any one project manager.
Standardize the template once, attach it to your intake and governance cadence, and reuse it everywhere. For the decision rights and cadences these reviews plug into, see project portfolio governance; for the model the gates structure, see the stage gate process; and for how a gate "go" should respect what teams can actually deliver, tie it back to capacity planning.