Stage gates without bureaucracy

Stage gates have a bad reputation, and often a deserved one. Many organizations use them as document checkpoints: submit the charter, the plan, the risk register and the architecture diagram, wait for six signatures, then proceed. Teams learn to produce the documents and ignore the questions.

But the idea behind gates is sound. At certain points in an investment, it's worth stopping briefly to ask whether it still makes sense to continue. The trick is to make each gate a short set of sharp questions rather than a pile of paperwork.

What a gate is for

A gate is a decision point where you confirm that:

• the investment is still worth what remains to be spent;
• the conditions for the next stage are in place;
• the risks are understood and acceptable.

Every gate should end in one of three decisions: go, adjust (go with changes), or stop. If a gate can never produce "stop," it isn't a gate. It's a formality.

How many gates?

Fewer than you think. For most technology investments, three are enough:

Small changes may need only the first gate, often handled by a product owner. Large programs may add a mid-delivery checkpoint to re-validate the value case.

Write gates as questions, not documents

Instead of "submit a project charter," ask the questions the charter was meant to answer. For the commit gate, for example:

1. Is the problem and objective clear, with a measure and target? See How to write an IT problem statement.
2. Is there a named owner who has agreed to the role?
3. Have all impacted teams confirmed their part and timing? See Cross-team dependencies.
4. Is capacity available without displacing higher-value work?
5. Are the key assumptions written down?
6. Are the major risks identified, with owners?

Each question can be answered with "yes," "no," or "yes, with a note." A team can often pass a well-prepared gate in 20 minutes.

Make gates continuous where you can

Many gate questions can be answered as you go rather than all at once. If the owner, objective and dependency estimates are captured during intake and assessment, the commit gate becomes a quick confirmation. Gates feel heavy when evidence is gathered at the last minute. They feel light when the evidence already exists.

Gates in agile environments

Agile teams sometimes reject gates entirely. But even teams delivering continuously make investment decisions: whether to start a new initiative, whether to release a major change, whether to keep funding a product area. Gates fit at those points, above the sprint level. They govern the investment, not the team's daily work.

What doesn't fit agile delivery is a gate that requires a detailed upfront plan. Ask for the decision evidence instead: objective, owner, value, risks and current forecast.

Signs your gates have become bureaucratic

• Teams spend more time preparing for gates than the gates take.
• Gates never produce "stop" or "adjust."
• The same information is requested at every gate.
• Approvers sign without discussion.
• Teams schedule work around the gate calendar.

If you see these signs, cut the questions back to the essentials, move evidence collection earlier, and make sure each gate has a real decider.

Recording gate outcomes

Each gate outcome should be recorded with the decision, any conditions, and who decided. Over time, these records show where investments typically struggle. If many initiatives fail the dependency question at the commit gate, your intake process needs to identify dependencies earlier. See Designing a project approval workflow.

How Aizu helps

Gates in Aizu are short readiness checks attached to each initiative, written as questions with a clear status rather than documents to submit. A commit gate can confirm product placement, the accountable owner, funding and capacity, and the release commitment. The portfolio shows which initiatives have open gates, approval decisions are recorded with their rationale, and evidence captured during intake carries forward so gates confirm rather than collect. Related: Decision rights.