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 |
Swipe to see more →
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? |
Swipe to see more →
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 project business case, the next-stage plan and budget, the current risk register, 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 |
Swipe to see more →
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. Where the next stage is delivered by an outside firm, the conditions worth logging include the insurance and licensing checks set out in vendor and contractor compliance, because those lapse quietly between gates.
| 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 |
Swipe to see more →
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.
The gate pack: what gets circulated, and when
Most weak gate reviews are decided before anyone speaks, by the quality of what was sent out beforehand. If the pack lands the night before, the meeting becomes a reading session followed by a decision nobody had time to think about, and the default answer to a decision nobody has thought about is yes.
Set a circulation deadline in the template itself and treat a late pack as its own signal. A team that cannot assemble the evidence three working days ahead is usually a team that does not yet have the evidence, which is the finding the gate exists to surface.
| Item | Length | Who prepares it | Sent |
|---|---|---|---|
| Decision summary: what is being asked, and the recommendation | One page | Project manager | 3 working days before |
| Criteria scorecard with evidence referenced per criterion | One page | Project manager | 3 working days before |
| Cost position: spent, committed, forecast to complete | Half page | Finance business partner | 3 working days before |
| Business case position: has the case changed since approval | Half page | Sponsor | 3 working days before |
| Top risks, issues and open dependencies with owners | One page | Project manager | 3 working days before |
| Resource position for the next stage | Half page | Resource manager | 3 working days before |
| Supporting deliverables | Referenced, not reproduced | Project team | Linked, available on request |
Swipe to see more →
Reference the deliverables rather than attaching them. A gate pack that runs to eighty pages guarantees that the only people who read it are the ones who wrote it, and the point of the pack is to let a busy reviewer arrive with a position and a question, not to prove that work happened.
Who attends a gate review, and who actually decides
Confusion about the decision right is the most common reason gate outcomes fail to stick. Write the roles into the template so it is unambiguous before the meeting, because a decision that several people believe they can revisit afterwards is not a decision, it is an opinion with minutes.
| Role | At the gate |
|---|---|
| Gate chair or sponsor | Takes the decision and is accountable for it |
| Project manager | Presents the evidence; does not vote on their own gate |
| Finance | Confirms the cost position and whether the case still holds |
| Resource or delivery lead | Confirms the next stage can actually be staffed |
| Technical or quality assurance | Advises on whether deliverables meet the standard |
| PMO | Runs the process, checks the criteria were applied, records the decision and conditions |
| Receiving operational owner | Attends later gates, where handover readiness is the real question |
Swipe to see more →
Keep the group small enough to decide. Once a gate has more than about eight people in the room, attendance becomes a courtesy and the decision migrates to a conversation between two of them afterwards, which is the worst of both arrangements because the record no longer matches where the decision was made.
Making a conditional go mean something
Conditional go is the most used and most abused gate outcome. It feels like rigor and often functions as a yes with paperwork attached, because the conditions are recorded without an owner, a date, or any consequence for missing them, and the project proceeds exactly as it would have with a clean approval.
A condition is only real if three things are written down at the moment it is set: a named owner, a date, and what happens if the date passes unmet. That third element is the one almost always missing. Without it, an unmet condition produces a discussion at the next gate rather than any action, and everyone learns that conditions are advisory.
| Weak condition | Enforceable version |
|---|---|
| "Firm up the integration costs." | "Costed integration estimate from the vendor to the sponsor by 14 March. If not received, spend is capped at the current stage budget until the next board." |
| "Confirm resourcing." | "Named team confirmed by the resource manager by 7 March. If unconfirmed, the stage start moves and the gate is re-run." |
| "Address the security findings." | "High findings closed or formally accepted by the security lead before build starts. Build does not start otherwise." |
| "Keep an eye on the benefits assumption." | "Benefits owner validates the volume assumption against two months of actuals by 30 April and reports the effect on the case." |
Swipe to see more →
The pattern in the right hand column is that the consequence happens by default, without anyone needing to win an argument later. A condition whose enforcement depends on somebody remembering to object at the next meeting will not be enforced, because the person who would have to object is usually the person under most pressure to let it pass.
There is a simple diagnostic worth running once a year: the share of your gate decisions that were conditional. If nearly every gate ends conditional, the criteria are effectively being set after the evidence is seen rather than before, and the gate has stopped being a test. Read it against your own trend rather than any external figure, and treat a rising line as a sign that entry criteria need to be agreed earlier, at the previous gate.
How criteria tighten from the first gate to the last
Reusing one criteria list at every gate is the quickest way to make later reviews feel pointless. Early gates test whether the idea deserves more investigation, and the honest answer at that point rests on strategic fit and rough sizing. Later gates test whether the thing works and whether the organization is ready to run it, which is a different question with different evidence.
| Gate | The question being answered | Evidence that carries weight |
|---|---|---|
| Idea to concept | Is this worth spending time investigating? | Strategic fit, rough size, a named sponsor willing to fund the next step |
| Concept to plan | Is this the right option, and can we afford it? | Options compared, outline case, high level costs, capacity indication |
| Plan to build | Is the plan credible and the funding committed? | Full business case, detailed plan, named team, signed off requirements |
| Build to launch | Does it work, and is the business ready? | Test results, training and cutover plan, operational acceptance, support model |
| Launch to close | Did it deliver, and who owns the benefits now? | Benefits baseline handed to a named owner, lessons captured, project costs closed |
Swipe to see more →
The final gate is the one most often skipped, and skipping it is expensive in a way that shows up years later. Without it, benefits ownership never transfers, so nobody is accountable for the return the business case promised, and the organization loses the only feedback it has on whether its investment decisions are any good.
Six ways gate reviews stop working
- The pack arrives the night before. Reviewers cannot form a view, so the recommendation passes unexamined. Enforce the circulation deadline and defer rather than proceed.
- Criteria are scored on opinion. If "commercially viable" has no definition, each reviewer scores a different question. Write what evidence satisfies each criterion.
- Every outcome is conditional. Conditions with no owner, date or consequence are a way of avoiding a decision rather than making one.
- Work continues through the gate. If the next stage already started, the review is a formality and everyone present knows it.
- The same criteria at every gate. Later reviews add no information, so attendance and preparation quality fall.
- No record of why. Minutes that record the outcome but not the reasoning leave the next gate relitigating settled ground.
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. In practice the gatekeepers are usually the steering committee, meeting on the cadence set by the portfolio review meeting.
Standardize the template once, attach it to your intake and governance cadence, and reuse it everywhere. The first gate is really the tail end of the project intake process, so the criteria you score at Gate 1 should be the same ones intake used to let the request through. 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. When the template starts being retyped for every review, that is the point at which stage gate software earns its keep: the pack gets built from the initiative record and frozen, so the version circulated before the meeting is the version on the record afterwards. Consistent gates are one control inside the wider discipline of project portfolio management, which is what turns a set of individual go decisions into a steered portfolio.