Use this guide when choosing between AI initiatives or deciding whether one should move from an Experiment to a Pilot or Scale. It turns a collection of AI Value Canvas (AVC) proposals into explicit choices about investment, ownership, evidence, and operating capacity.
For AVC portfolio decisions, do not advance an initiative on technical merit alone. Assess the user need, solution and data feasibility, risks, value and costs, and the organization’s capacity to operate the work after launch.
Set the context for every initiative
Complete the following metadata before comparing initiatives or funding the next Horizon: Experiment, Pilot, or Scale.
State a measurable Strategic Intent
Strategic Intent connects the initiative to a defined organizational outcome. Write it as a measurable statement, not a technology ambition.
Format: Improve [business or user outcome] for [defined group or workflow] from [baseline, unit, and date] to [target, unit, and date], while meeting [material guardrail].
For example: “Reduce the median time for claims assessors to prepare a first review from the current measured baseline to the agreed target by the end of the Pilot, without increasing the rate of material review errors.” The actual baseline, target, measurement method, and acceptable guardrail must be agreed for the team’s context before the stage begins.
If the outcome cannot be measured yet, record the uncertainty and make establishing the baseline an Experiment objective. Do not describe “using AI” or “building a chatbot” as Strategic Intent.
Name accountable owners
Record one named person for each role. The same person may hold more than one role only if they have the authority and capacity to do so.
| Role | Accountable for and decision rights |
|---|---|
| Executive sponsor | Strategic fit, senior decisions, removing organizational barriers, and authorizing stage advancement or a material-change decision. Names or confirms the budget holder and funding decision. |
| Project lead | Delivery across the Canvas, evidence plan, decision records, coordination, and initiating the material-change review. Accountable for a complete, accepted gate handoff. |
| Technical lead | Technical approach, data and integration design, evaluation, reliability, technical risk, and accepting the technical-operating handoff. |
| Business owner | Workflow adoption, operating policy, benefit realization, and accepting business ownership after launch. This role is accountable for realizing benefits, not for authorizing spend unless also named as budget holder. |
Name a budget holder and cost centre for every Horizon; this may be the executive sponsor but must be explicit. The budget holder is accountable for affordability, funding source, spending authority, and spend control, while the business owner remains accountable for benefit realization.
Ownership is a gate, not an administrative detail. All four named roles must be committed before any stage advancement. Any named owner may raise a material change; the project lead starts the revalidation, the technical and business leads assess their respective effects, and the executive sponsor approves or rejects the resulting decision. The project lead may close a gate handoff only after the business and technical leads have accepted their responsibilities and the sponsor has recorded the advancement decision.
Manage the portfolio, not isolated ideas
Compare initiatives using the same evidence standard and score anchors. A score informs discussion; it does not replace a decision. Keep the scorecard, evidence references, assumptions, and decision record with each Canvas.
Portfolio scorecard
Score each dimension from 1 to 5 using the anchors below. A score of 2 or 4 can be used when the evidence sits between anchors, but the rationale must be recorded. Scores should be based on current evidence, not forecast confidence alone.
| Dimension | 1 | 3 | 5 | Evidence required |
|---|---|---|---|---|
| Strategic Alignment | No clear link to an approved priority or the initiative conflicts with it. | Link to a priority exists, but the contribution, owner, or trade-off is not yet clear. | Direct, documented contribution to an approved priority with sponsor confirmation and a measurable Strategic Intent. | Strategy reference, sponsor confirmation, Strategic Intent, and stated trade-offs. |
| Expected Value | No measured baseline, credible value mechanism, documented benefit-realization approach and Malaysian ringgit (RM) value-conversion method, or identified beneficiary. | A value mechanism and beneficiary are defined, with a proposed benefit-realization approach and RM value-conversion method plus adoption assumptions; baseline, lifecycle-cost, time-horizon, or downside evidence remains incomplete. | Baseline, target, unit, beneficiary, documented benefit-realization approach and RM value-conversion method, adoption assumptions, lifecycle costs, time horizon, and base-case net benefit are documented and testable at the current Horizon. Pilot and Scale decisions also show a quantified downside case. | Value & Metrics of Success, Cost Drivers, baseline source, benefit-realization approach, RM value-conversion method, adoption assumptions, lifecycle model, time horizon, net-benefit and downside evidence, and benefits owner. |
| Delivery Effort | The current-Horizon scope is bounded, uses available capability, and needs limited new integration, data, or change work. | The scope needs moderate new capability, integration, data preparation, or workflow change, with manageable dependencies. | The scope needs substantial new capability, complex integration, material data work, or broad workflow change. | Delivery plan, dependency register, capability assessment, integration assessment, and budget basis. |
| Risk Exposure | Outputs and actions have low consequence, with limited residual user, operational, legal, security, safety, or vendor exposure after defined controls. | Material but bounded exposure remains; controls, owners, and escalation paths are defined, although some must be tested or approved. | High-consequence, difficult-to-reverse, or cross-jurisdictional exposure remains even after controls; the risk may require rescoping, deferral, or an explicit senior decision. | Risks & Guardrails, pre-mortem, approvals, test evidence, monitoring plan, and residual-risk record. |
| Leadership commitment | No active sponsor or decision authority; priorities and funding are uncertain. | Sponsor is named and engaged, but decisions, funding, or cross-functional support remain conditional. | Sponsor has confirmed the Strategic Intent, decision rights, resource commitment, and escalation support for the Horizon. | Sponsor confirmation, funding decision, governance record, and decision rights. |
| Change capacity and skills | Affected teams have no capacity, ownership, training plan, or skills path to change the workflow. | Adoption impacts and capability gaps are known, but capacity, training, or change ownership needs validation. | Affected teams have an adoption owner, practical capacity plan, role-specific skills support, and feedback process. | Stakeholder and workflow map, change plan, skills assessment, training/support plan, and adoption evidence. |
| Data infrastructure maturity | Required data is unavailable, unusable, or cannot be accessed and governed for the use case. | Required data is accessible for a limited use, but quality, lineage, access, integration, or monitoring gaps remain. | Data access, quality controls, governance, integration, and operational monitoring are sufficient for the Horizon’s defined scope. | Data assessment, access approvals, quality findings, lineage, architecture or integration plan, and monitoring design. |
How to use the scorecard
- Agree the evidence required and score anchors before scoring proposals. For Pilot and Scale decisions, include the documented benefit-realization approach and RM value-conversion method, adoption assumptions, lifecycle costs, time horizon, expected- and half-volume unit economics, and base-case net-benefit and downside evidence. Apply the Value & Cost scenario set: half expected volume or adoption while retaining fixed costs, build cost +30%, value per completed case −20%, the combined case, delayed benefit recognition, and any material run-cost change.
- Interpret Delivery Effort and Risk Exposure as constraints to manage, not benefits to maximize. A lower score indicates less effort or residual exposure.
- Do not score an initiative with an unowned material risk, missing guardrail, or missing required approval as viable. Resolve it, rescope, defer, or stop first.
- A composite may help sort the portfolio, but it must not override individual evidence. Before weighting, transform every input to the same attractiveness direction: for Strategic Alignment, Expected Value, and readiness dimensions, use
score ÷ 5; for Delivery Effort and Risk Exposure, use(6 − score) ÷ 5. Never sum raw 1–5 scores across these dimensions. Record each weight, transformed score, formula, applicable hard gates, and rationale. - A weak Organizational Readiness dimension, an unfilled ownership gate, or an economics hard gate cannot be outweighed by an attractive composite score. Beyond Experiment, a composite must not advance an initiative with a missing lifecycle model or a downside case the budget holder cannot afford. A negative base case may proceed only as a documented, time-bounded strategic investment approved by both executive sponsor and budget holder, with quantified strategic benefit, funding and loss cap, next review date, and explicit stop or continue conditions.
- An Experiment may be approved as a capped learning investment for a named uncertainty; it does not need to meet positive base-case economics.
- Consider portfolio balance: near-term workflow improvements, learning investments, and longer-term strategic bets can each be appropriate when their intent, budget, and risk are explicit.
Use Horizons with decision gates
Every initiative has a current Horizon: Experiment, Pilot, or Scale. Define the stage objective, scope, pre-agreed, context-specific gate criteria and budget bands, evidence needed, decision makers, and decision gate before committing work. Teams must set thresholds appropriate to their context; this guide does not prescribe universal numerical thresholds.
Horizon economics matrix
| Horizon | Required economics and evidence |
|---|---|
| Experiment | A capped learning budget, time boundary, and named uncertainty. It may be approved as a learning investment rather than on positive base-case economics. |
| Pilot | Measure adoption, realized benefit, actual run cost, and operating readiness in the bounded live workflow. Use these observations, stated adoption assumptions, lifecycle costs, time horizon, and net benefit and downside evidence for the next decision. |
| Scale | Observed Pilot evidence; a time-bound lifecycle model covering build, run, and exit; expected and downside unit economics; funding and payback expectations; and an approved operating budget. |
For every Horizon, record the budget holder and cost centre, funding source, committed and contingent amounts, spending cap and approval authority, and exit reserve. Reapproval is required when a material change affects these records.
Horizon 1: Experiment
An Experiment tests a limited, high-uncertainty assumption. It may test whether users find a proposed interaction useful, whether data can support a task, whether a model approach meets a defined quality bar, or whether an integration is possible.
Keep the scope narrow and avoid treating a prototype as a production commitment. Define:
- the named uncertainty, assumption, and why it matters;
- the test method, sample or test cases, and evidence owner;
- success, failure, and safety criteria appropriate to the use case;
- a capped learning budget, funding record, and time boundary; and
- the pre-agreed gate decision criteria and authorized decision makers.
At the gate, update the Canvas with observed user, workflow, data, model, risk, cost, and delivery findings. Record one outcome: proceed to Pilot, test another assumption, rescope, or stop or defer.
Horizon 2: Pilot
A Pilot tests the complete workflow in a bounded live setting. It is not simply a longer Experiment. It should show whether defined users adopt the solution, whether the human and AI interaction works in practice, whether guardrails operate, and whether realized benefit, actual run cost, and operating readiness support further investment.
Before the Pilot, agree:
- the user group, workflow boundary, and business owner;
- baseline, target, unit, measurement method, benefit-realization owner, documented benefit-realization approach and RM value-conversion method, and adoption assumptions;
- data permissions, integration scope, model or vendor configuration, and evaluation plan;
- user support, training, monitoring, incident response, and risk controls;
- Pilot budget, expected run costs, lifecycle-cost/time-horizon assumptions, and base-case and downside evidence; and
- pre-agreed evidence-based decision criteria for the next gate.
At the gate, replace projections with observed adoption, realized benefit, actual run cost, and operating-readiness evidence where possible. Record proceed to Scale, test, rescope, or stop or defer, including the evidence, dissent or uncertainty, decision makers, date, funding decision, and next review date.
Horizon 3: Scale
Scale expands a validated solution into an owned operating capability. It requires more than a successful Pilot: the organization must be able to support adoption, control risk, fund ongoing operations, and revise the solution as conditions change.
Before scaling, confirm observed Pilot evidence, the time-bound build/run/exit lifecycle model, expected and downside unit economics, funding and payback expectations, an approved operating budget, and the Scale operating model below. The decision gate records proceed, test, rescope, or stop or defer using the pre-agreed criteria. If the evidence is insufficient, do not relabel the work as Scale to resolve the uncertainty.
Mandatory Pilot and Scale pre-mortem
At every Pilot and Scale gate, complete an actionable pre-mortem before advancement and update it after a material change. For each plausible failure scenario, record the named owner, mitigation, leading signals, escalation route, and the authority to pause or disable the solution (kill switch). Neither a Pilot nor a Scale initiative may advance without this record and its agreed response actions.
Make the Canvas a living decision record
The Canvas must be revalidated at each decision gate and after any material change. A material change includes a change to:
- the user, user segment, or user need;
- the workflow, decision rights, or human approval design;
- a named executive sponsor, project lead, technical lead, business owner, adoption owner, operating owner, or other accountable owner;
- the budget holder, cost centre, funding source, spending authority, exit reserve, or approved loss exposure;
- the post-launch operating-model responsibility or the acceptance of a business, technical, support, operations, vendor, or partner handoff;
- staffing, protected capacity, change capacity, skills, training, support capability, or any adoption assumption that affects the ability to operate the changed workflow;
- the data source, access, quality, retention, or governance;
- the model, model configuration, vendor, or tool use;
- build or run cost, pricing, budget, or value assumption;
- an integration, dependency, or operating environment; or
- a risk, control, incident, regulatory requirement, or residual-risk decision.
Revalidation means reviewing the affected Canvas elements and metadata, updating evidence and assumptions, reconsidering the Horizon, and recording the decision. Do not carry forward a prior approval when its underlying assumptions have materially changed.
Decide how to deliver and how to exit
Build / Buy / Partner is a portfolio decision as well as a delivery choice. Compare every viable option for the current Horizon, including retaining the current process or stopping the initiative where relevant, using the same Strategic Intent, evidence standard, operating period, demand cases, and build/run/exit lifecycle boundaries.
| Consideration | Questions to answer |
|---|---|
| Differentiation and control | Is the workflow or data a source of advantage? Which capabilities must remain under organizational control? |
| Capability and time | What skills, capacity, delivery time, and integration work does each option require? |
| Economics | Over the same operating period and demand cases, what are the build, license, implementation, support, inference or usage, data, security, change, and exit costs? Show expected and downside unit economics, price-change exposure, migration or wind-down cost and duration, and any parallel-run need. |
| Data and risk | What data leaves the organization, who can access it, and what controls, approvals, and audit evidence are required? |
| Partner delivery and dependency | For a Partner, what is its delivery scope, which responsibilities and decision rights are shared, how will knowledge transfer occur, what dependencies remain, and what exit support is required? For any vendor or partner, what happens if pricing, product capability, service levels, terms, or a model changes? |
| Exit viability | Can the organization export needed data and configurations, transition users and integrations, retain required records, and operate or replace the capability within the quantified exit cost and duration? |
Record a costed side-by-side comparison for every viable option: the common operating-period, demand, price-change, unit, and payback assumptions; build, run, governance, support, transition, and exit cash and economic costs; the exit reserve; and the resulting expected and downside lifecycle net benefit. Record the chosen option, rejected options, material assumptions, exit trigger, migration or wind-down owner, the authority that can invoke exit, and the budget holder who can release exit funding. A lower-cost option is not viable if it creates an unacceptable dependency or makes a future exit impractical.
Establish the Scale operating model
A Scale decision needs an operating model that makes post-launch responsibilities visible. The business owner remains accountable for realization of the Strategic Intent; technical ownership alone is not sufficient. At the Scale gate, retain an auditable post-launch (Day-2) acceptance record from the business owner, technical owner, and support or operations owner; where a vendor or partner has an operating responsibility, retain its named acceptance and agreed handoff as well. Acceptance must state the scope, service or operating responsibility, capacity commitment, dependencies, decision rights, and escalation route. An unaccepted responsibility is a gate blocker, not a delivery detail to resolve after launch.
| Operating area | Define before Scale |
|---|---|
| Adoption | Target users and workflows; a change owner; communications, training, feedback channels, and adoption measures; and a role-specific view of likely resistance, concerns, workload effects, and mitigations. For each material affected role, name the mitigation owner, protected capacity or time, support route, and escalation path. State the action if adoption is below the context-specific expectation. |
| Support | User support route, service expectations, knowledge materials, triage process, and named ownership for business, technical, support or operations, and vendor issues where applicable. Record each owner’s Day-2 acceptance, capacity commitment, dependencies, decision rights, and escalation route. |
| Monitoring | Measures for user outcomes, quality, errors, safety or risk signals, data quality, model behavior, latency or availability where relevant, and run costs. Define owners, thresholds, response actions, and the authority to pause or roll back the service. |
| Model, source, prompt, rule, and vendor stewardship | Explicitly decide whether model or source refresh, retraining, prompt or rule updates, or vendor re-evaluation are applicable. For each applicable activity, name the owner, review cadence, evidence required, approval path, funding, and triggers for change. For an activity that is not applicable, record the rationale and the event that would require reconsideration. |
| Review cadence | Operational and executive review frequency, required inputs, decision rights, and the triggers that require an out-of-cycle Canvas revalidation. |
| Incident and escalation ownership | Named incident owner, severity and escalation process, business and technical contacts, communication responsibilities, and decision authority for pausing or disabling the solution. |
| Budget | Approved operating-budget owner and funding for licenses or vendors, infrastructure, inference or usage, data, integrations, support, monitoring, training, risk controls, model or source stewardship, maintenance, and exit or migration work. |
Review the operating model at the agreed cadence and after material changes or incidents. Use the evidence to improve the solution, adjust scope, change the delivery choice, or stop the capability when it no longer supports its Strategic Intent.
Portfolio decision record
For every stage gate and material portfolio decision, record:
- Initiative name, Canvas version, current Horizon, and date.
- Strategic Intent; all four named owners; the budget holder and cost centre; and the decision makers present.
- Scorecard ratings, evidence references, assumptions, readiness or ownership blockers, and composite weights, normalization direction, hard gates, and rationale if a composite is used.
- The pre-agreed gate criteria, budget band, and observed evidence against them, including the benefit-realization approach, RM value-conversion method, adoption assumptions, lifecycle costs, time horizon, and net benefit and downside evidence where required.
- The actionable Pilot or Scale pre-mortem where applicable, including failure scenarios, owners, mitigations, leading signals, escalation, and kill-switch authority.
- The decision: proceed, test, rescope, or stop or defer.
- The rationale, funding source, committed and contingent amounts, spending cap and approval authority, exit reserve, actions, accountable owners, and next review date.
- Any changes required to the Canvas, operating model, Build / Buy / Partner choice, or exit plan.
A decision record preserves learning for the portfolio. It also makes it possible to revisit a deferred idea when the user need, organizational readiness, data, economics, or technology context has changed.