Initiative Lifecycle
Why the lifecycle is needed
In companies, AI initiatives often live chaotically. Some ideas remain in chats and meetings. Some pilots launch without a clear business goal. Some solutions are technically ready but unused. Some initiatives may have created value, but no one confirmed it. Some tasks remain in the portfolio long after they have lost relevance.
The lifecycle gives every initiative a clear path: how it enters the portfolio, who evaluates it, when it becomes an initiative, through which AI product it is implemented, who decides launch, how the result is validated, and when the initiative is considered complete.
This turns the AI initiative portfolio from a list of scattered requests into a managed system.
General lifecycle scheme
New idea
↓
Evaluation
↓
Delivery
↓
Awaiting impact
↓
Completed
Side outcomes are also possible: rejected, needs rework, paused, handed over to operations.
Important: the initiative lifecycle is not a technical implementation plan. The technical plan depends on the selected AI product: LLM, RAG, ML platform, code agent, workflow automation, or applied AI service.
The initiative lifecycle answers a different question: where is the business need now, and what management decision is needed next?
The previous model described this as a combination of two loops: the business funnel for value and management decisions, and the delivery track for implementation inside the selected AI product. The unified part should be the management path, not a single technical route for every solution type.
Stage 1. Idea
The idea stage records an initial request, hypothesis, or business pain that could potentially be solved with AI.
An idea can come from a business sponsor, users, AI champions, the AI function, process audit, idea mining, recurring manual operations, or the arrival of a new AI product.
At this stage, the idea does not need to be detailed. The main thing is not to lose it and to quickly decide whether it deserves further analysis.
Minimum fields: short description, business unit, expected sponsor, problem or opportunity, potential users, initial benefit hypothesis, and idea source.
Main question: is there a real business problem or opportunity worth analyzing?
| Decision | Meaning |
|---|---|
| Send to evaluation | The idea is meaningful enough |
| Return for clarification | Basic context is missing |
| Merge with another idea | A similar request already exists in the portfolio |
| Reject | No business meaning, owner, or connection to AI |
Output: the idea either becomes a candidate for evaluation, is rejected, or returns for clarification.
Stage 2. Evaluation
At evaluation, an idea becomes a structured AI initiative.
The team clarifies the problem, owner, expected impact, users, data/documents, candidate AI products, security/architecture/integration/operations constraints, and whether the initiative should enter delivery.
This is the key filtering stage, where weak, unconfirmed, or low-value requests are removed.
| Block | What needs to be understood |
|---|---|
| Problem | What currently works poorly, slowly, expensively, or riskily |
| Sponsor | Who wants the result |
| Users | Who will actually use the solution |
| Impact | What benefit is expected |
| Product route | Which AI product or applied service should be used |
| Data | Which sources are needed and whether they are available |
| Constraints | Security, architecture, access, compliance, data quality |
| Feasibility | Whether a working solution can be achieved with reasonable effort |
| Priority | How important the initiative is relative to others |
Main question: should the initiative be implemented and through which product route?
| Decision | Meaning |
|---|---|
| Start delivery | Initiative is clear and valuable enough |
| Send for rework | Data, sponsor, impact, or route is missing |
| Merge with another initiative | There is a similar or broader case |
| Transfer to AI product portfolio | The request requires product development, not a one-off initiative |
| Reject | No value, feasibility, or priority |
Minimum output: problem stated, business sponsor identified, initiative lead assigned, impact hypothesis described, preliminary AI product or route chosen, next gate defined, and decision made on delivery.
Stage 3. Delivery
In delivery, the initiative becomes a working solution, pilot, or service.
Delivery should not be identical for all initiatives. LLM, RAG, ML, code agent, and applied AI service initiatives all require different implementation routes.
The lifecycle does not describe every technical step. It records that the initiative is in implementation and must move toward a verifiable result.
During delivery, the target solution is clarified, a work plan is formed, AI product owners and adjacent functions join, data/documents/integrations are prepared, a prototype/pilot/first version is created, quality is checked, user launch is prepared, and risks are recorded.
Main question: can we get a working solution that can be tested with real users?
| Decision | Meaning |
|---|---|
| Move to pilot / usage | Solution is ready to validate |
| Continue delivery | Rework is needed |
| Change product route | Initial AI product does not fit |
| Return to evaluation | Inputs, impact, or constraints changed |
| Stop initiative | Implementation is not viable or not reasonable |
Output examples: configured LLM scenario, working RAG base, AI assistant prototype, validated model, automated agentic workflow, pilot applied service, user guide, and impact validation plan.
Stage 4. Awaiting impact
This is one of the most important stages and is often skipped.
Many companies consider an initiative complete when a pilot launches or a solution is technically ready. For the initiative portfolio, that is not enough.
After delivery, the company must understand whether the solution is used, solves the original problem, creates expected value, can have its impact confirmed, and should be scaled, improved, or closed.
Impact often appears not at release, but after a period of use.
At this stage, users work with the solution, feedback is collected, quality metrics are checked, expected and actual results are compared, constraints are recorded, economic or qualitative impact is clarified, and a decision is made on scaling, operations, or closure.
Main question: is the solution used and does it deliver the expected value?
| Decision | Meaning |
|---|---|
| Confirm impact | Benefit is recorded |
| Extend observation | More time or data is needed |
| Improve solution | There is benefit, but quality or adoption is insufficient |
| Scale | Solution should expand to other groups |
| Hand over to operations | Solution became a stable service |
| Close without impact | Hypothesis was not confirmed |
Output: confirmed impact, unconfirmed impact, handover to operations, rework decision, closed initiative, or new initiative/product development task.
Stage 5. Completed
An initiative is completed when a final management decision has been made.
Completion does not always mean success. It means the initiative no longer hangs in the portfolio without status or next step.
It can end with confirmed impact, handover to operations, scaling, unconfirmed hypothesis, rejection, merger with another initiative, or transformation into AI product development.
The final initiative card should record final status, what was implemented, which AI product was used, expected impact, confirmed impact, who confirmed the result, discovered constraints, what happens next, and what knowledge can be reused.
Main question: what outcome was recorded and what did the company learn?
| Final status | Meaning |
|---|---|
| Completed with confirmed impact | Benefit proved and recorded |
| Completed without confirmed impact | Solution was tested, but hypothesis was not confirmed |
| Handed over to operations | Solution became a stable service or process component |
| Rejected | Initiative stopped for a clear reason |
| Merged | Initiative included in a broader loop |
| Converted to product development | Request became part of an AI product roadmap |
Gate logic
The lifecycle should be managed through gate decisions.
A gate is not bureaucratic approval for its own sake. It is a management point where the company decides whether there is enough evidence to move the initiative forward.
| Transition | What is checked |
|---|---|
| Idea → Evaluation | There is a problem, sponsor, or at least a clear hypothesis |
| Evaluation → Delivery | Value, route, constraints, and owners are clear |
| Delivery → Awaiting impact | There is a working solution, users, and validation method |
| Awaiting impact → Completed | Outcome is recorded: impact, no impact, operations, or rejection |
Typical rejection reasons
Rejection is a normal lifecycle result. A bad system pushes every idea into pilots. A good system quickly filters initiatives that should not be implemented.
Typical reasons: no business sponsor, unconfirmed problem, weak impact, no users, missing data/documents, poor data quality, risks exceed value, the task does not require AI, the task is already solved by an existing tool, duplicate request, implementation too expensive compared with impact, or no resources for post-launch support.
It is important to record rejection reasons so the portfolio does not become a black box.
Special attention to "the task does not require AI": many AI initiatives could actually be solved by process changes or system optimization.
What changes through the lifecycle
Early initiatives can be described briefly. As they move forward, they should become more concrete.
| Stage | Detail level |
|---|---|
| Idea | Short problem or opportunity description |
| Evaluation | Problem, sponsor, users, impact, product route |
| Delivery | Work plan, participants, data, integrations, risks, artifacts |
| Awaiting impact | Usage facts, feedback, metrics, benefit confirmation |
| Completed | Outcome, impact, operations decision, learnings |
This prevents two extremes: requiring a heavy project passport for a raw idea, and launching delivery without understanding impact, owner, and route.
Role of the initiative lead
The initiative lead owns movement through the lifecycle.
They do not have to be the AI product owner, architect, developer, or business sponsor. Their job is to ensure the initiative does not get lost between participants.
They ensure idea formalization, preparation for evaluation, synchronization of business/AI function/adjacent functions, delivery organization, gate preparation, risk and dependency recording, next-step control, transition to impact validation, and closure with a clear outcome.
In other words, the initiative lead is the owner of management movement, not the only executor.
Typical artifacts by stage
| Stage | Possible artifacts |
|---|---|
| Idea | Idea card, problem description, idea source |
| Evaluation | Initiative card, impact hypothesis, product route, initial feasibility assessment |
| Delivery | Work plan, requirements, prototype, test cases, approvals, user guide |
| Awaiting impact | Usage metrics, feedback, impact calculation, pilot report |
| Completed | Final decision, impact confirmation, operations decision, learnings and reusable knowledge |
Artifacts should be sufficient for decisions, but should not turn the initiative into a bureaucratic project for its own sake.
Mapping to application states
In the AI Conveyor product, these stages may map to system states such as NEW, ASSESSMENT, DELIVERY, AWAITING_EFFECT, ON_SUPPORT, CLOSED, and REJECTED.
This technical representation should not replace the methodology: the system status exists to record the management stage, next step, and expected decision.
Lifecycle anti-patterns
1. Jumping from idea straight to pilot
Without problem, impact, and user evaluation, a pilot often ends as a nice demo without adoption.
2. Treating delivery as the finish line
Technical readiness is not business outcome. Impact validation must follow delivery.
3. Never closing initiatives
If an initiative has no next step, it should be returned for rework, paused, rejected, or closed.
4. Using one route for all initiatives
LLM, RAG, ML, code agent, and applied services require different delivery tracks. The management lifecycle should be unified, not the technical implementation.
5. Not recording rejection reasons
Rejected initiatives are an important source of knowledge. They show which requests lack impact, where data is missing, which products need development, and which business expectations need correction.
Core idea
The AI initiative lifecycle exists to manage movement toward impact, not activity.
An initiative should not live forever as an idea, pilot, or development effort. It must always have a clear stage, next step, and transition criterion.
The right logic is not "we tried something with AI," but "we moved a business need from idea to solution and recorded the outcome."
That is how the AI initiative portfolio becomes a managed instrument of change, not a list of experiments.