Stage-gate model
Purpose
This document describes the AI Conveyor stage-gate model: which stages an initiative passes through, which checks are performed before a transition, and who is responsible for the decision.
The model relies on the capabilities of the AI Conveyor platform: the business funnel of initiatives, product delivery tracks, configurable transition rules, required fields, the similar-initiatives check, tasks, artifacts, and analytics.
Core ideas
- Stage — the state of an initiative in the business funnel: new, assessment, delivery, awaiting impact, support, closing, or rejection.
- Stage gate — a check before moving to the next stage. It must be clear, verifiable, and known to participants in advance.
- Transition rule — a platform setting that determines which stage can be moved to from which.
- Required fields — the minimum set of data without which a decision cannot be considered manageable.
- Product funnel — the delivery stages within a selected AI product. These stages may differ across products.
- Decision — the recorded outcome of a stage gate: continue, rework, stop, reject, or move to support.
How it works
An initiative moves along the business funnel:
New → Assessment → Delivery → Awaiting impact → On support / Closed
An initiative can be rejected if the value is not confirmed, the risk is too high, there is no data, there is no owner, or there is higher-priority work.
In the platform, these stages correspond to the states NEW, ASSESSMENT, DELIVERY, AWAITING_EFFECT, ON_SUPPORT, CLOSED, and REJECTED.
Stage gates are configured by the AI office administrator through transition rules, required fields, and field visibility. For the transition to delivery, the platform already supports important checks: a product must be selected, the similar-initiatives check must be completed, and the preliminary security review must not have a negative result.
Lifecycle details are covered in the initiative lifecycle.
flowchart LR
subgraph Stage gates
G1[Gate 1] --> G2[Gate 2] --> G3[Gate 3] --> G4[Gate 4] --> G5[Gate 5]
end
subgraph Stages
S1[New] --> S2[Assessment] --> S3[Delivery] --> S4[Awaiting impact] --> S5[Support or closing]
end
G1 -.-> S1
G2 -.-> S2
G3 -.-> S3
G4 -.-> S4
G5 -.-> S5
Stage-gate map
| Stage gate | Transition | Key question | Minimum criteria | Decision owner |
|---|---|---|---|---|
| Gate 1. Registration | problem → new initiative | Is the idea worth recording in the portfolio? | There is a problem, an initiator, a brief description, and an expected impact type | AI office or department head |
| Gate 2. Admission to assessment | new → assessment | Is there enough data to analyze the initiative? | Basic fields are filled in, the owner is clear, there is no obvious duplicate | AI office |
| Gate 3. Admission to delivery | assessment → delivery | Is it worth spending team and product resources? | A product is selected, the similar-initiatives check is done, security has not rejected it, there is an impact hypothesis and a priority | Committee or assigned owner |
| Gate 4. Start of awaiting impact | delivery → awaiting impact | Is the solution deployed enough to measure the result? | Delivery is complete, there is a process owner, metrics are defined, and the impact review date and data source are set | Initiative owner together with the AI office |
| Gate 5. Closing or support | awaiting impact → support/closed | Is the impact confirmed and is it clear what to do next? | Actual impact is calculated, there is a decision on closing, support, scaling, or rework | Business owner, finance, AI office |
| Rejection | any early stage → rejected | Why are we not continuing the initiative? | A reason is stated, the decision history is preserved, and a return or review is proposed if needed | Owner of the current stage |
Gate 1. Initiative registration
The goal is not to prove value, but to record the idea so that it is not lost and can be assessed.
Minimum input:
- a business problem;
- an initiator;
- a department or process;
- a brief description of the idea;
- a preliminary impact type.
Outcome:
- an initiative card is created;
- the stage is set to "New";
- the initiative is added to the portfolio;
- an initial set of tasks is created if needed.
How the AI assistant can help:
- gather missing fields through a dialogue;
- bring a vague description into the structure of a card;
- propose a problem statement and an impact hypothesis.
Gate 2. Admission to assessment
The goal is to separate the raw stream of ideas from initiatives worth analyzing in substance.
Minimum criteria:
- the problem is described through a process and a metric;
- there is a business owner or a clear candidate;
- the expected value is stated;
- the initiative is not an obvious duplicate;
- there is no explicit prohibition from security or data.
Decisions:
- move to assessment;
- return for clarification;
- reject with a reason;
- merge with a similar initiative.
Platform support:
- the initiative card;
- the similar-initiatives check;
- required fields by stage;
- the transition history.
Gate 3. Admission to delivery
This is the key stage gate. This is where the initiative stops being an idea and starts consuming team, product, and infrastructure resources.
Minimum criteria:
- an AI product is selected;
- the similar-initiatives check is done;
- the preliminary security review does not have a negative result;
- the impact hypothesis is clear;
- a priority is stated;
- a project lead or person responsible for moving it forward is assigned;
- the immediate delivery tasks are defined.
In the platform, the transition to delivery should be blocked if a product is not selected or the mandatory similar-initiatives check is not done. If the preliminary security review has a negative result, the initiative should not proceed to delivery without a separate decision.
Decisions:
- admit to delivery;
- send back to rework the assessment;
- change the product;
- defer due to lack of resources;
- reject.
Gate 4. Start of awaiting impact
The goal is to make sure the solution is not just developed, but ready to verify the result within the business process.
Minimum criteria:
- the required stage of the product delivery track is complete;
- the solution is available to users or embedded in the process;
- a process owner is assigned after rollout;
- the baseline value, target value, and actual metrics source are defined;
- the impact review date is stated;
- operational constraints and risks are recorded.
Decisions:
- move to awaiting impact;
- keep it in delivery for rework;
- move to support without impact only as an exception;
- reject the delivery if the solution is not fit for use.
Platform support:
- the product delivery track;
- the initiative tasks;
- the expected impact date;
- analytics on overdue initiatives awaiting impact.
Gate 5. Closing, support, or scaling
The goal is not to close a card for the sake of a clean registry, but to make a management decision based on the actual result.
Minimum criteria:
- the impact is calculated using an agreed methodology;
- it is clear which part of the impact is attributable specifically to the initiative;
- the financial or business owner has confirmed the calculation;
- a decision is made on the further mode: close, support, scale, rework, or stop.
Decisions:
- close as a goal achieved;
- move to support;
- scale to other processes or departments;
- return to delivery for rework;
- close without confirmed impact, with a reason.
Rejecting an initiative
Rejection is a normal outcome of the conveyor. The system should screen out weak, risky, and duplicate initiatives before they start consuming resources.
Typical reasons:
- the business problem is not confirmed;
- there is no owner;
- the impact is too small;
- there is no available data;
- a duplicate is found;
- the security or compliance risk is too high;
- there is no suitable product;
- the initiative does not pass the portfolio priority.
If the required rejection-reason field is enabled in the settings, the platform should require a reason to be filled in before moving to the rejected state.
Rules of a good stage gate
A good stage gate:
- checks readiness for the next stage, not the form;
- has a decision owner;
- relies on card data, tasks, and artifacts;
- can be verified in the platform;
- does not require an unnecessary committee for obvious decisions;
- leaves a trace in the initiative history.
A bad stage gate:
- requires a document for the document's sake;
- has no explicit criteria;
- depends on a verbal agreement;
- lets through initiatives without an owner and metrics;
- blocks progress without a clear reason.
Minimum configuration in the platform
For a working version of the conveyor, it is enough to configure:
- the allowed business-funnel transitions;
- the required fields for the "Assessment," "Delivery," and "Awaiting impact" stages;
- the rule for selecting a product before delivery;
- the rule for the mandatory similar-initiatives check;
- the rejection-reason rule;
- field visibility by stage;
- product delivery tracks for the key products;
- the list of roles allowed to change an initiative's stage.
Even this minimum already turns a registry of ideas into a manageable mechanism for selection, delivery, and impact confirmation.