Value & Cost: Make the Viability Case

The Value & Cost (Viability) domain asks a direct question: does this create more value than it costs?

Answer it before committing to build. A positive-looking proposal is not yet a viable one if its value has no baseline, its adoption assumption has no owner, its run costs are omitted, or its delivery choice has no exit plan.

This guide covers three connected Canvas elements:

• Value & Metrics of Success — the measurable change the project is meant to create.
• Cost Drivers — the full cost to build, operate, govern, support, and eventually change the solution.
• Build / Buy / Partner — the delivery choice that best fits the organization’s capability, differentiation, data control, and time horizon.

Use this page for an Experiment, Pilot, or Scale initiative. The evidence and budget should increase with the Horizon; the discipline does not change.

Start with accountable context

A viability case needs named people and a realistic operating context before it needs a spreadsheet.

Use these 1, 3, and 5 anchors rather than impressions; assess 2 and 4 as evidence-supported positions between them.

A low readiness score is not a reason to hide the project. It is a decision input: test readiness, reduce the scope, invest in the missing capability, or defer the project. Record the owner and due date for the chosen response, and do not advance a gate whose unresolved gap makes the current Horizon scope unsafe or unoperable.

Element: Value & Metrics of Success

Complete a mandatory Value Case Card

Do not call a value claim complete until every field in this card has an answer. Keep the card with the Canvas and update it at every gate.

A completed card makes a claim testable. It prevents teams from multiplying an estimated benefit by all possible users when only part of the eligible scope will use the solution.

Track three separate metric groups

A useful metric set distinguishes whether people are using the solution, whether the intended outcome is improving, and whether the solution remains trustworthy and safe. Do not allow a strong result in one group to cancel a warning in another.

Define each metric before launch: its numerator, denominator, data source, owner, cadence, baseline, target, and escalation threshold. A technical measure such as model accuracy may be useful for operation, but it is not by itself a business outcome. Likewise, high usage does not demonstrate value if the outcome metric does not move or trust and safety signals worsen.

Make the adoption assumption conservative

For an initial business case, AVC conservative planning guidance is 20–30% eligible-user adoption, not broad use from day one. This is distinct from workflow penetration: user adoption measures who uses the solution, while workflow penetration measures the share of eligible cases or steps completed through it and therefore drives benefit volume. Use a named adoption owner, usually the business owner or a delegated change lead, who can change the workflow, arrange training and support, remove local blockers, and report both measures by user group.

Model 20%, 25%, and 30% eligible-user adoption in the initial planning case, with an explicit workflow-penetration assumption for each. Before accepting the case, run at least these downside tests:

Also test delay to benefit recognition until adoption and workflow changes are in place, and any material run-cost change. These are planning cases, not predictions. Record the assumptions, the person who owns each assumption, and the evidence that would update it. If the case only works at high adoption or immediate benefit realization, label that dependency clearly and test it before scaling.

Complete an adoption plan

Before the decision gate, record the affected roles and the roles likely to resist or be disadvantaged; the workflow change for each; role-specific mitigations such as training, approvals, workload changes, or incentives; named champions; and the support route for questions, defects, and escalation. The adoption owner keeps this plan current and reports eligible-user adoption and workflow penetration separately.

Element: Cost Drivers

Count build costs and run costs

Separate one-time build costs from recurring run costs, and classify each as both an incremental cash cost and, where relevant, an economic cost. Classify each external invoice as an incremental cash cost and include it in the economic-cost view unless that would double-count another cost. Value internal effort that displaces other work using a documented opportunity-cost method, even where it produces no additional cash outflow. For a public-sector reference on opportunity cost, see HM Treasury, The Green Book (2026).

For a multi-step or agentic workflow, identify and cost the evaluation, approval, logging, retry, permission, and monitoring controls required by its risk assessment and operating design. Do not leave applicable controls uncosted. Also set a limit for the cost of one completed task and define what happens when the limit is reached.

Calculate unit economics at expected and half volume

Use a unit that matches the Value Case Card, such as a completed eligible case or an approved decision. Calculate both the incremental cash cost and the full economic cost, including documented displaced internal capacity where material.

Monthly cash run cost = fixed cash platform and operating costs
                       + (variable cash cost per completed case × completed cases)

Monthly economic run cost = monthly cash run cost
                           + valued displaced internal effort and other non-cash economic costs

Cash unit cost = monthly cash run cost ÷ completed cases
Economic unit cost = monthly economic run cost ÷ completed cases

Monthly gross value = realized value per completed case × completed cases

Monthly net benefit = accepted monetized benefit − monthly economic run cost

Calculate these at the expected completed volume and at half that volume. Fixed costs should not be cut in half unless there is a documented reason they would fall. Compare both relevant unit-cost views with the realized value per completed case; a solution that loses money on an economic basis at a plausible volume needs a different design, scope, delivery choice, or decision.

A 24-month financial model that decision-makers can read

Build actual 24-month cases in monthly rows: Month 0 for setup, then Months 1–24 for operation. The model must show a month-by-month eligible-user adoption ramp, workflow-penetration ramp, and benefit-realization ramp; do not assume a flat 24-month result unless the evidence supports each month. Keep source assumptions in a separate, dated assumptions tab or section.

Enter incremental cash costs and economic costs as positive inputs, then subtract the applicable costs in the cash-flow and net-benefit calculations. An internal cost that displaces other work belongs in economic cost even when it creates no new cash payment. Use the following fields in each row.

Use these definitions consistently:

• Cash flow in this Canvas model shows the timing of realized cash benefits and incremental cash payments. It answers: “How much funding is needed, and when?” This is a planning convention; for the formal accounting definition of cash flows, see International Accounting Standards Board, IAS 7: Statement of Cash Flows (2026 issued edition).
• Net benefit in this Canvas model is total accepted, monetized benefit less total economic cost. It may include a validated non-cash capacity benefit and valued displaced effort, so it is not automatically the same as cash flow.
• Return on investment (ROI) in this Canvas model is (cumulative net benefit ÷ cumulative total economic cost) × 100. State the time period, valuation basis, and cost categories included. This model convention is not a cash-payback date.
• Payback in this Canvas model is the first month in which cumulative cash flow is zero or positive. If it does not occur within 24 months, say so rather than extrapolating it away.

Do not combine these labels. A project can show a positive net benefit while needing funding for longer, or show apparent time savings without a realized cash benefit.

Horizon-neutral, simplified illustrative RM calculation

The following is a worked arithmetic example, not a forecast, benchmark, or Horizon-specific budget. It uses RM (Malaysian ringgit) and assumes that each RM10 of value per completed case is realized as cash in the same month. It uses a steady-state monthly volume and immediate benefit realization solely to illustrate the arithmetic; an actual case must use the required month-by-month adoption, workflow-penetration, and benefit-realization ramps, and replace every input with the Value Case Card’s measured baseline, target, scope, and evidence.

Assumptions

• Eligible scope: 12,000 cases per month.
• For this simplified volume illustration, workflow penetration is 25%; eligible-user adoption is not modelled, and expected completed volume is therefore 12,000 × 25% = 3,000 cases per month. An actual case must model the 20–30% eligible-user adoption planning guidance separately from workflow penetration.
• Value: RM10 realized cash value per completed case, with immediate benefit realization in every illustrated month.
• One-time build cash cost in Month 0 (positive input): RM130,000.
• Monthly fixed run cash cost (positive input): RM3,000 platform + RM5,000 operations and monitoring + RM2,000 adoption support = RM10,000.
• Variable run cash cost (positive input): RM2 per completed case.
• No displaced internal effort is assumed in this simple illustration, so cash and economic costs are the same. An actual case must show any difference.

Under the example’s cash-realization assumption, expected-volume cumulative cash flow is −RM130,000 + (9 × RM14,000) = −RM4,000 at the end of Month 9 and −RM4,000 + RM14,000 = RM10,000 at the end of Month 10. For the other cases, payback follows the same monthly net-cash-flow calculation: RM169,000 build cost at RM14,000 per month reaches payback in Month 13; RM130,000 build cost at RM8,000 per month in Month 17; and the half-volume and combined cases do not repay within 24 months.

The purpose of the downside cases is not to reject every lower-volume project. They show the dependency openly. The team may decide to rescope, lower fixed run costs, increase validated value per case, select a different delivery option, or keep the work at a smaller Horizon.

Element: Build / Buy / Partner

Build / Buy / Partner is a viability decision, not only a technical procurement decision. Compare every viable option, including retaining the current process or stopping the initiative where relevant, against the same scope, demand cases, time horizon, and cash/economic cost basis. A lower first-year invoice can still have a higher lifecycle cost or a dependency that is unacceptable for the workflow.

Do not select an option with a generic statement such as “buy is faster” or “build gives control.” Complete this decision record for every viable option before choosing one.

Require an exit and migration plan before committing

Every Build / Buy / Partner choice needs a proportionate plan for changing course. Include:

1. Dependency register — models, platforms, data stores, application programming interfaces (APIs), partner-owned tools, and key skills the solution relies on.
2. Ownership and export rights — what data, prompts, configurations, workflow definitions, evaluation cases, logs, and documentation the organization can retrieve in usable formats.
3. Portability design — interfaces and data structures that reduce unnecessary coupling where this is practical for the Horizon.
4. Migration path — the likely destination or fallback workflow, the required data transformation, testing, and a named migration owner.
5. Exit trigger and cost — events that would cause reconsideration, such as a material pricing, capability, risk, or service change; estimate the time, cash, economic cost, and operating disruption to exit, and name the authority that can invoke the trigger and authorize the spend.
6. Operational continuity — how the business process continues if the vendor, partner, model, or integration is unavailable during migration.
7. Exit/fallback test — the most important export or fallback step, its success criteria, the test date, and the named test owner.

Run the exit/fallback test during the appropriate Horizon and record the result against its success criteria. An exit plan that has never been checked is only an intention.

Complete risks, guardrails, and operating readiness

Before a Proceed decision, complete a Risks & Guardrails pre-mortem: identify how the initiative could fail to realize value, harm users, breach a guardrail, or become unoperable; record the evidence or trigger to watch, a named owner, and a mitigation for each material scenario. A pre-mortem without named owners and mitigations is incomplete.

Before Pilot or Scale, prepare an operating-readiness plan. Name the operating owner and confirm the handoffs, support route and service expectations, monitoring measures and escalation thresholds, review cadence, incident response, guardrail operation, and budget stewardship needed for that Horizon. Record whether model, source, prompt, or rule updates or retraining are applicable; if they are, name the owner, cadence, approval path, and trigger, and if they are not, record that decision and why. The plan must state what is ready, what remains open, who owns each open item, and the gate decision it affects.

Write a decision-ready conclusion

End the Viability section with a conclusion that an executive can act on. It should state the current Horizon, the selected delivery option, the evidence from the Value Case Card, the expected and half-volume unit economics, readiness constraints, material risks, accountable owners, and the next decision date.

Use one of these four decisions:

• Proceed — the current Horizon case has a measured baseline and target, a funded cost model, acceptable expected and downside economics, named operating and adoption owners, a completed Risks & Guardrails pre-mortem with named owners and mitigations, and a workable Build / Buy / Partner and exit plan. For Pilot or Scale, it also has the required operating-readiness plan.
• Test — one or more material assumptions remain unproven. Name the assumption, the smallest test, the metric and threshold, the owner, budget, and the decision date.
• Rescope — the opportunity may work with a smaller eligible scope, different user group, simpler solution, reduced fixed cost, changed delivery option, or different Horizon. State exactly what changes and rerun the case.
• Stop or defer — the value cannot be measured or realized, the downside is unacceptable, readiness is insufficient, or another option better serves the Strategic Intent. Record what would need to change before reconsideration.

A defensible conclusion does not force a “proceed” outcome. It makes the value, costs, adoption dependency, delivery choice, and uncertainty visible enough to choose the right next move.