To run stage gates in Jira, define each gate and the evidence it needs, name who can approve it, and record the decision against the Jira project with its reasoning and date. Stage gate software inside Jira keeps that record next to the delivery work, so nobody rebuilds it in slides before each review.
Jira already holds the evidence most gate reviews need: what was delivered, what slipped and what is blocked. What Jira lacks out of the box is the gate itself, meaning the criteria, the approvers and the decision record. Tollgate's page on stage gate software sets out three tests for any tool: the evidence at the gate is live, the decision is recorded with its reasoning, and each gate has a due date. This guide walks through the steps.
Step 1: Design the gates and their evidence
Start with as few gates as your governance needs. Most organisations need a gate to commit funding, a gate to confirm the project is set up to deliver, a gate to close delivery, and a later check on benefits. Phase gate software uses the same idea under a different name.
For each gate, write down two things. The entry criteria say what must be true before the gate is reviewed, such as an approved business case or a baselined schedule. The evidence list says what the approvers will look at. Tollgate's stage-gate page suggests five things belong on the table at every gate: scope, schedule, cost and earned value, risks and issues, and the decisions already made.
Keep the evidence in Jira where you can. If a gate depends on a document that lives in a shared drive, the version the approvers see is rarely the latest one.
Step 2: Name the approvers and the other seats
A gate decision is only as good as the authority behind it. Name the person who decides at each gate, usually the sponsor, before the gate is due.
Gate reviews often involve people beyond the approver: the project manager, a customer or supplier representative, the owner of adoption, and steering committee members. Treat each of these as a named seat on the project with a clear role.
Expect some of these people to have no Jira licence. A divisional executive or a board member may never log in to Jira, and the gate process has to work for them anyway.
Step 3: Hold the gate review
Send the approver the evidence ahead of the meeting, with a link to the live project. In the review, focus on the decision in front of the group, which is usually one of four: proceed, proceed with conditions, return for more work, or stop.
Record any conditions carefully. A gate passed on the condition that a risk is closed within a month is a different decision from an unconditional pass, and the record should show the difference.
Step 4: Record the decision against the project
Record what was decided, who decided, when, and the reasoning. Attach the evidence the decision rested on, such as an email reply or signed minutes. If someone enters a decision on the approver's behalf, the record should show both names.
Treat recorded decisions as permanent. When a decision is later revised, add a new entry that refers to the old one and leave the original entry as it was. Two years later, an auditor or a new sponsor will want to see what was known at the time.
Running stage gates in Tollgate
Tollgate is a Forge app for Jira Cloud that adds gates, governance seats and a decision record to each Jira project. You keep your existing issue hierarchy.
Its default method, SAM, has six stages grouped into three acts: Commit, Run and Realise. You don't set the stage from a dropdown. The stage follows from the governance acts you perform, such as submitting and approving the business case. A stage rail in the project header shows each gate's position: passed with recorded evidence, current, or passed without recorded evidence. That last state is a statement of fact, and Tollgate reports it without blocking you. There are only two hard stops, both deliberate: the Adoption and Change inputs at business case submission, and a lessons field when benefits are judged not realised.
Each project has governance seats for the sponsor, project manager, customer or supplier representative, adoption owner and steering committee members. You fill a seat with a Jira user, or with someone outside your site by giving their name, email and title. The title matters because it shows why that person's approval settles the question.
When an approver has no Jira seat, Tollgate gives you a prefilled email and a review link to send from your own mail client, because Tollgate never emails anyone. When the reply comes back, you enter the decision through the Record dialog and attach the reply as evidence. The log stores who decided, who entered it, when, by what channel and the artefact that proves it. The governance seats guide and the guide to moving through the stages cover each step.
The first gate in SAM is the commit decision at the end of intake, covered in Tollgate's guide to project intake.
Frequently asked questions
Can you run stage gates in Jira without an add-on?
You can approximate gates with custom statuses, approval fields and linked documents. The hard parts are recording who decided and why, and involving approvers without a Jira licence, which is where an app helps.
What is the difference between a stage gate and a phase gate?
The terms are used interchangeably. Both describe a decision point between stages of a project where someone with authority decides whether it continues.
Should a gate block work in Jira?
Tollgate's documentation names only two places where it refuses to let you proceed. Everywhere else, it reports each gate's position and leaves the call to the people in the governance seats.
Who should approve a stage gate?
The sponsor, as the person accountable for the investment, usually approves. Name them before the gate is due and record their title with the decision.
Tollgate is free for up to 10 users. Install free for up to 10 users.
Want to talk through how this applies to your team? Book a call with Softwired.
