Catalogue › Programme Management › stage-gates

Stage gates

Defines the stage gates of an AI programme along the CopilotForge lifecycle - from mobilisation through enablement, delivery, launch and scale to closure - with the evidence each gate needs, who signs it off, how reviewer findings carry into it, and the outcomes go, conditional go, hold or stop. Use when a programme needs control points, when gates have become ceremonies, or when a sponsor asks what must be true before the next stage.

Department

Programme Management

Lifecycle

Mobilise, Enable, Deliver, Assure, Launch, Measure, Scale

Maturity

adopter, builder, scaler, ai-enterprise

Risk tiers

0, 1, 2, 3, 4

Platforms

platform-neutral

Editions

starter, scale, enterprise

Reviewers

security-privacy, responsible-ai, evaluation-quality, design-authority

Status

draft

Copilot Cowork

Programme Management plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

A stage gate is the point at which a programme stops to ask whether it should continue, change or stop, on evidence. This skill defines the programme's gates along the CopilotForge lifecycle, the evidence each one needs, who signs it off, how reviewer findings from solution gates feed into it, and what each possible outcome means. Programme gates are not solution release gates: they decide whether the programme moves to its next stage, and they rely on solution gates having done their work. Gates go wrong when they become ceremonies that always say go, when evidence is a slide of assertions, and when a blocking reviewer finding is traded off against a date.

When to use

• A programme has been chartered and needs control points agreed with the sponsor.
• The sponsor asks what must be true before the programme launches, scales or closes.
• Existing gates have become ceremonies with no evidence and no real choice.
• A programme is moving to a new stage (from pilot to scale-out, for example) and the decision needs a structure.
• Reviewer departments ask how their findings are reflected in programme decisions.

When not to use

• Releasing an individual agent to its audience - use m365-agents:agent-release-readiness.
• Setting the release policy for AI solutions by risk tier - use platform-governance:ai-release-policy.
• Assembling the evaluation evidence pack for a solution - use evaluation-quality:ai-release-evidence.
• Deciding whether a single pilot should scale, iterate, pivot or stop - use opportunity-management:scale-or-stop.
• Reporting programme health between gates - use programme-management:programme-health.

Questions to ask first

1. Which stages does this programme pass through, and which ones carry real choices for the sponsor?
2. Who holds the gate decision at each stage, and what does the charter allow them to decide?
3. Which solution-level gates (security, privacy, responsible AI, evaluation, design authority) will the programme's solutions pass, and from which risk tier?
4. What evidence already exists or is produced by workstreams, so gates can reuse it rather than demand new papers?
5. What would a stop or hold mean in practice for people, suppliers and live solutions?

Required inputs

• The programme charter with stages, decision rights and tolerances.
• The integrated plan, so gates sit at real points in time.
• The risk tiers of the programme's solutions and the reviewer gates they trigger, from opportunity-management:risk-classification.
• The health report and risk log, which every gate reads.

If a gate's decision owner or evidence is not agreed, mark it [To confirm: ...] and resolve it before the gate date, not at the gate.

Decision framework

Use gates aligned to the CopilotForge lifecycle. Not every programme needs all of them.

Gate outcomes.

Rule: any open blocking finding from security-privacy, responsible-ai, evaluation-quality or design-authority on a solution included in the gate's scope means that solution cannot pass, whatever the date. The gate may pass the rest of the scope without it.

Practitioner approach

Decide which gates the programme needs. A Starter adoption programme may need only G2, G4 and G6; a transformation programme at Scale or Enterprise will use most of them. Put each gate on the integrated plan with a date, a decision owner and the forum that will take it. Agree with the sponsor what each gate is for: a gate exists to make a choice possible, and a gate where stopping is unthinkable is not a gate.

Define evidence as artefacts that already exist. G4 evidence for an agent-heavy programme is the release readiness records from m365-agents:agent-release-readiness, the reviewer outcomes, the support route and the baselines captured, not a new slide deck summarising them. Give each evidence item an owner and a standard ("baseline captured and agreed by the business owner"), so the gate can check it rather than discuss it.

Keep the boundary with solution gates clear. Solution gates release individual agents, automations or engineered solutions, by risk tier. Programme gates decide whether the programme moves on, using the solution gate outcomes as evidence. Programme gates never re-review a solution and never override a reviewer's classification. When a solution has an open blocking finding, the programme gate excludes it or holds; disagreement goes to the accountable executive for written risk acceptance where policy allows, never to the gate chair.

Prepare gates in advance. Two weeks before, the programme manager checks the evidence list with owners and flags gaps. One week before, a short pre-gate review sorts gaps into those that will close in time, those that become conditions, and those that mean hold. The gate meeting itself should then be about the choice.

Record each gate decision in the decision log with the evidence relied on, the outcome, conditions with owners and dates, and dissent where it existed. Follow up conditions at the next board. A conditional go whose conditions are never checked teaches everyone that gates do not matter.

Treat G5 as the most important gate in AI programmes. Scaling a solution or a rollout multiplies cost, risk and support load, so it needs measured value against a baseline, adoption by team or role, quality from evaluation, and the cost of scaling, taken together. Where evidence is weak, a hold is the right answer.

Outputs

• A gate plan: gates in use, timing, decision owner and forum, key question, evidence list with owners and standards.
• Gate evidence checklists, and the gate decision record with outcome, conditions, owners, dates and dissent.
• A gate section in the programme-charter template and gate status in the programme-health-report template.

Microsoft platform considerations

Evidence that relies on a platform capability, licence position or admin control records the source record checked and the date. For G3 and G4, confirm that environments, data and connector policies and admin controls the solutions rely on are in place, using references/sources.md for current product facts.

Adoption considerations

G4 must include adoption evidence (scenarios, Champions, communications, support) as well as technical readiness, and G5 must include adoption by team or role. Launch gates that check only technology produce launches nobody uses.

Knowledge considerations

For agent and Cowork work, knowledge readiness verdicts are G3 and G4 evidence. A gate cannot pass an agent whose sources are not ready.

Security and privacy considerations

The security-privacy gate applies to solutions from risk tier 2 and is blocking. The programme gate records the reviewer's outcome as given and never downgrades it. Data protection questions arising at a gate go to the DPO or legal adviser.

Responsible AI considerations

Tier 3 and 4 solutions need the responsible-ai review outcome and any risk acceptance by the accountable executive as gate evidence. Some uses should stop at a gate; record that outcome plainly as a success of governance.

Evaluation requirements

From tier 2, gate evidence includes the evaluation results and thresholds agreed with the business owner, from evaluation-quality. G5 adds regression evidence where solutions have changed since launch.

Value measures

Track gate predictability (gates held on the planned date with evidence complete), conditions closed by their date, and the share of gates with a real hold or stop option exercised over time, reported at programme level. A programme where every gate is a go deserves scrutiny.

Scale notes

Starter

Two or three light gates taken by the sponsor at the working group, each with a one-page checklist and a decision note.

Scale

Four to six gates on the integrated plan, evidence checklists with owners, pre-gate reviews, and decisions at the programme board.

Enterprise

Gates per tranche and business unit, with a programme-level G5 and G6 at the portfolio board and formal evidence where the assurance overlay is formal.

Hand-offs

• To programme-management:programme-board-cadence for gate decisions and the decision log.
• To programme-management:programme-health for gate status between gates.
• To opportunity-management:scale-or-stop for solution-level scale decisions feeding G5.
• To m365-agents:agent-release-readiness and platform-governance:ai-release-policy for solution release.

Reviewer gates

security-privacy from risk tier 2, and evaluation-quality, design-authority and responsible-ai from the tiers those departments set, provide evidence into programme gates. Each finding keeps the reviewer's blocking or advisory classification; a blocking finding stops the affected solution at the gate and is not traded off against a date.

Failure modes

• Gates are ceremonies where stopping is unthinkable, so every outcome is go.
• Evidence is a slide of assertions rather than the artefacts the workstreams produce.
• A programme gate passes a solution with an open blocking finding to protect a launch date.
• Conditions from a conditional go are never followed up.
• G5 is skipped because a pilot "went well", and scaling multiplies an unmeasured cost.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Pass a solution with an open blocking reviewer finding.
• Re-review or reclassify a solution's reviewer findings at a programme gate.
• Hold a gate without an agreed decision owner and evidence list.
• Accept a stage outcome on assertion where the gate requires evidence.