How to Write Clear Entry and Exit Criteria for Each Stage Gate

## The short answer

Clear stage-gate criteria are **specific, evidence-based and binary**: for any item, the board should be able to answer "met" or "not met" without debate. Each gate needs *entry* criteria (what must be true to begin the next phase) and *exit* criteria (what the current phase must have produced). Vague criteria like "design is mature" cause arguments and rubber-stamping; precise criteria like "interface contracts agreed and signed off by both teams" make the decision obvious.

## Entry versus exit — and why both matter

People often define only exit criteria. But entry criteria are what stop a phase starting before it should:

- **Exit criteria** confirm the *current* phase did its job — the deliverables and evidence exist.

- **Entry criteria** confirm the *next* phase is set up to succeed — funding released, team in place, dependencies ready.

A gate is really the join between one phase's exit and the next phase's entry. Writing both halves prevents the classic problem of a phase technically "finishing" while the next phase has no realistic chance of starting cleanly.

## Make every criterion pass a simple test

Before you accept a criterion, check it against four questions:

1. **Is it binary?** Can someone honestly say met or not met? "Risks understood" fails; "all high risks have a named owner and mitigation" passes.

2. **Is it evidence-backed?** Each criterion should point to an artefact — a test result, a signed approval, a live metric — not an opinion.

3. **Is it necessary?** Would failing it actually change the decision? If not, drop it.

4. **Is it within the team's control or clearly assigned?** Avoid criteria that depend on something nobody owns.

## Examples by gate

Illustrative, not exhaustive — tailor to your context:

- **Concept gate exit** — Problem statement validated with users; rough cost and benefit envelope documented; a measurable success hypothesis stated.

- **Business-case gate exit** — Benefits identified with owners; cost estimate at a defined confidence level; key assumptions and risks logged.

- **Design / readiness gate exit** — Approach selected with options considered; major technical and integration risks assessed; team and skills confirmed for build.

- **Go-live gate exit** — Testing complete against agreed criteria; rollback plan exists; operational support and required compliance sign-offs in place.

- **Closure gate exit** — Benefits measured against the baseline; lessons captured; handover to business-as-usual completed.

Notice each is checkable. "Rollback plan exists" is verifiable; "we are confident in go-live" is not.

## Avoid the two big failure modes

- **Too vague.** Criteria full of words like "adequate", "mature" or "sufficient" push the real decision into the room, where the loudest voice or the deadline wins. Replace adjectives with thresholds and named artefacts.

- **Too rigid.** A wall of mandatory criteria with no room for judgement encourages box-ticking and document theatre. Distinguish *must-have* criteria (block the gate) from *should-have* ones (note as conditions or risks).

## Use conditional passes deliberately

Real initiatives are rarely perfectly ready. A mature gate process allows a **pass with conditions**: the must-haves are met, and the remaining items become tracked actions with named owners and dates. This keeps work flowing without pretending everything is perfect — provided the conditions are genuinely tracked and not forgotten the moment the meeting ends.

## Tie criteria to living evidence

The most reliable criteria reference artefacts the team already maintains — the risk log, the benefits map, test results, decision records — rather than bespoke documents produced solely for the gate. When criteria point to live evidence, the board reviews reality and the team avoids duplicate effort. This connected, evidence-first approach is central to enterprise delivery platforms like those neart.ai builds, where gate criteria are checked against the actual state of the work.

## Keep criteria proportionate

Match the depth of criteria to the initiative's risk tier. A low-risk internal tool needs a handful of light checks; a regulated, high-value programme warrants a thorough set, especially at the go-live gate. Reusing one heavyweight template everywhere is the fastest way to make teams resent and route around your gates.

## Takeaway

Write both entry and exit criteria, make every one binary and evidence-backed, and keep only those that would genuinely change the decision. Distinguish must-haves from conditions, allow tracked conditional passes, and point criteria at living delivery artefacts so the gate judges reality rather than rhetoric.