Skip to main content

Initiative card

Purpose​

The initiative card is the main artifact of AI Conveyor. It holds the management context of an initiative: the problem, the owners, the stage, the product, the tasks, the verifications, the expected impact, the actual result, and the history of decisions.

If the other documents can be considered attachments, the card is the single source of truth for the portfolio.

Card structure​

Identification​

  • Identifier — the unique number of the initiative.
  • Title — a short, business-friendly name.
  • Initiator — the employee or unit that submitted the idea.
  • Business owner — the person responsible for the business result.
  • Project manager — the person responsible for moving the initiative through tasks and stages.
  • Registration date — the date the card was created.

Description​

  • Business problem — which problem the initiative solves, in which process.
  • Solution hypothesis — an assumption about how AI will change the process and the metrics.
  • Current indicators — values of key metrics before deployment.
  • Expected impact — target metric values, type of impact (cost reduction, revenue growth, quality improvement).
  • Constraints — known constraints on data, security, architecture, timelines, and resources.

Management​

  • Business funnel stage — new, assessment, delivery, awaiting impact, on support, closed, or rejected.
  • AI product — the product or perimeter through which the initiative is implemented.
  • Delivery stage — the position of the initiative within the product delivery track.
  • Priority — the importance of the initiative for the portfolio.
  • Reason for rejection — if the initiative is stopped.
  • Transition dates — when the initiative passed the stage gates.
  • Assigned team — participants and areas of responsibility.

Data and risks​

  • Data sources — which data is required.
  • Data owner — who is responsible for the source.
  • Data class — internal, confidential, sensitive, critical.
  • Preliminary security check — status and restrictions.
  • Solution impact class — hint, draft, recommendation, automatic action, or critical impact.

Impact​

  • Baseline value — the state of the indicator before deployment.
  • Target value — the expected result.
  • Actual value — the result after deployment.
  • Impact check date — when the result should be measured.
  • Calculation methodology — how the impact is calculated.
  • Impact owner — who confirms the result.

Tasks and artifacts​

  • Tasks — actions, responsible parties, deadlines, statuses, effort.
  • Artifacts — use case document, experiment report, architecture review, value report.
  • Decision history — who changed the stage, priority, or status, and why.

Card lifecycle​

Creation​

The card is created manually, in bulk based on a company profile, or through the AI assistant.

The minimum fields to fill in are:

  • title;
  • initiator;
  • business problem;
  • description of the idea;
  • expected type of impact.

The stage is set to "New".

Updates at each stage​

  • New → Assessment. The problem, owner, expected impact, and similar initiatives are refined.
  • Assessment → Delivery. The chosen product, priority, check for similar initiatives, preliminary security, tasks, and delivery route are added.
  • Delivery → Awaiting impact. Delivery results, the architecture review, the impact check date, and the measurement methodology are added.
  • Awaiting impact → Support / Closed. Actual indicators, the value report, and a decision on the further mode are added.
  • Any early stage → Rejected. The reason for rejection is recorded.

Responsibility​

  • The business owner is responsible for keeping the business description and metrics up to date.
  • The project manager is responsible for tasks, deadlines, and progress.
  • The product owner is responsible for the delivery route and technical feasibility.
  • The data owner is responsible for the data sources and limitations.
  • Security is responsible for processing and access restrictions.
  • The architect is responsible for integrations and operational readiness.
  • The AI office controls the completeness of the card, the correctness of transitions, and the quality of the portfolio.

Minimum fields by stage​

StageRequired minimum
Newtitle, initiator, problem, description, expected type of impact
Assessmentbusiness owner, impact hypothesis, similar initiatives, preliminary product or selection task
Deliverychosen product, project manager, tasks, data and security check, priority
Awaiting impactcheck date, baseline indicator, target indicator, calculation methodology
Closed / supportactual indicator, decision, support owner or reason for closure
Rejectedreason for rejection

What makes a card high-quality​

A good card:

  • describes the problem through a process and a metric;
  • has an impact owner;
  • contains a check for similar initiatives;
  • is linked to an AI product;
  • shows the current stage and the next step;
  • contains tasks and responsible parties;
  • makes it possible to understand what is blocking the transition;
  • stores the actual result after deployment.

A poor card:

  • is named after a technology rather than a problem;
  • has no owner;
  • contains a generic impact without a baseline indicator;
  • went into delivery without a product;
  • does not record the reason for rejection;
  • is not updated after deployment.

Storage and access​

Cards are stored in the initiative registry. Access to a card depends on role, permissions, and membership in an organization or unit.

The data structure is described in the data model. A detailed description of fields and relationships is in the initiative entity.