Budget an AI Capability Program by Adoption Depth: Decision Worksheet

An AI budget gets vague when the target is “company-wide adoption.” That phrase hides three different purchases: people learning individual tasks, a team making one workflow repeatable, and several functions operating a governed capability.

At the Orange workshop I led, we started from the work people already did. (Public workshop account) I use the same test here: name the job, define the next outcome, then pay for the next adoption depth you can support.

Choose the adoption depth before you choose the budget

Fund the shallowest depth that can answer the next business decision. Microsoft’s maturity guidance moves from initial, inconsistent experimentation toward repeatable, defined, capable, and efficient operation across strategy, process, governance, technology, and organization. The worksheet compresses that progression into three buyer-sized funding choices. (Microsoft’s adoption maturity model)

Depth	What you are buying	Required readiness evidence	Next funding decision
D1: Individual use	Access, task-specific enablement, safe practice, and a way to check outputs	Named jobs, named users, protected practice time, a human review boundary	Fund enablement only, then inspect real work samples
D2: Repeatable team workflows	Workflow observation, redesign, shared patterns, evaluation, minimum risk controls, and an owner	One bounded process, repeatable examples, a team owner, outcome measure, practice cadence	Add workflow and governance work for that slice, not a broad rollout
D3: Governed cross-functional capability	Cross-functional process redesign, integration, measurement, governance, maintenance, and leadership accountability	Multiple owners aligned, risk inventory, operating rules, monitoring, recurring capacity, evidence across functions	Expand only when the operating model can carry the capability

The distinction matters because Microsoft's AI planning guidance asks buyers to match use cases to current skills, data, infrastructure, and resources, then use proof-of-concept evidence to refine the roadmap. It does not treat a higher ambition as proof that the organization can execute it. (Microsoft’s AI adoption planning guidance)

Use one-time and recurring cost lines

The worksheet has two totals because learning and implementation are not the same expense as keeping a capability alive.

Let N be participating people, L the monthly access cost per person, P protected practice hours per person per week, H the number of practice weeks, and u the internal capacity value per person-hour. Replace every input with your own finance or capacity data.

D1 one-time = u × (facilitator hours + enablement hours per person × N)
D1 recurring = (L × N) + (P × H × N × u) + office-hours capacity

D2 one-time = D1 one-time + workflow mapping + evaluation/runbook + risk review
D2 recurring = D1 recurring + workflow maintenance + monitoring

D3 one-time = D2 one-time + cross-functional redesign + integration
               + measurement/control design + cross-functional training
D3 recurring = D2 recurring + owner capacity + governance review + cross-functional review

These are budget formulas, not claims about what a supplier should charge. Keep external cash and internal capacity in separate columns. A proposal can look inexpensive in cash while consuming the operators who were supposed to practice the new workflow.

The readiness gate is equally simple:

fund the target depth only if:
owner = yes
AND protected practice time = yes
AND readiness evidence = yes
AND risk control = yes when the use case requires it

If any required input is “no,” the next funding decision is defer and collect the missing evidence, not “buy a bigger program and hope adoption catches up.” The OECD reports that skills shortages constrain AI adoption and that training is associated with better reported outcomes for workers using AI. That supports paying for enablement, but not treating a training event as proof of workflow capability. (OECD, AI and skills)

What belongs in each depth’s work package?

Use this table as the worksheet you take into a funding meeting.

Depth	One-time work	Recurring work	Accountable owner	Evidence of readiness
D1	Define 1-3 existing jobs, set access rules, run task-specific enablement, create a review checklist, record a baseline	Licenses, practice time, office hours, light measurement, access review	Enablement lead with a line manager	People can name the job and outcome, have protected practice time, and can explain when to check or stop
D2	Observe the workflow, remove unnecessary steps, design a bounded slice, create shared patterns, evaluate examples, assign minimum risk controls	Workflow owner time, maintenance, monitoring, correction review, recurring practice	Process owner, with an enablement partner	The same slice can be run repeatedly, the owner can inspect outcomes, and the team has examples of accepted, corrected, and escalated work
D3	Map cross-functional handoffs, redesign the end-to-end process, integrate systems, define governance and measurement, rehearse incidents and retirement	Governance reviews, monitoring, maintenance, cross-functional owner time, training refresh, incident handling	Executive sponsor plus named operational and risk owners	Multiple functions agree on decision rights, risk inventory, metrics, controls, support model, and recurring capacity

NIST’s AI RMF is useful here because it treats govern, map, measure, and manage as lifecycle functions, with governance cross-cutting and risk work continuous. Its core also calls for clear roles, training, inventory, monitoring, and safe decommissioning. Those are not D3 decorations. They are cost inputs that appear earlier when the use case is sensitive or irreversible. (NIST AI RMF Core)

Worked decision: an operations team with uneven adoption

Assume an eight-person operations team wants to use AI to prepare an internal intake triage and follow-up draft. Three people already use AI regularly. Five use it occasionally. The team wants a repeatable workflow, but it does not yet have cross-functional ownership.

These assumptions are deliberately transparent:

• N=8 people.
• L=30 budget units per person per month for access. This is an illustrative input, not a market rate.
• P=1 protected practice hour per person per week for H=4 weeks.
• u=1 budget unit per internal person-hour.
• D1 enablement uses 4 facilitator hours plus 2 hours per person.
• D2 adds 24 hours for workflow mapping, 12 hours for evaluation and a runbook, and 6 hours for a minimum risk review.
• D3 adds 60 hours for cross-functional redesign, 24 for integration, 18 for measurement and controls, and 12 for cross-functional training.

The calculation is:

Target	One-time	Recurring monthly	Funding decision
D1 individual use	4 + (2 × 8) = 20	(30 × 8) + (1 × 4 × 8) + 4 = 276	Approve enablement for all eight, with extra practice support for the five occasional users.
D2 repeatable workflow	20 + 24 + 12 + 6 = 62	276 + 6 + 2 = 284	Approve one bounded intake slice with the three regular users if they can supply repeatable samples and accept ownership.
D3 governed cross-functional capability	62 + 60 + 24 + 18 + 12 = 176	284 + 12 + 8 + 6 = 310	Defer. The example has no evidence of cross-functional decision rights or recurring governance capacity.

The recommendation is not “train everyone” or “launch transformation.” It is a staged decision: fund D1 enablement, fund D2 for one slice, and defer D3. If the three regular users cannot name an owner or produce usable samples, approve D1 only and stop there.

That operating-model boundary is consistent with the World Economic Forum’s 2026 report, which describes the move from isolated use cases to connected systems and highlights human accountability, end-to-end operating-model redesign, scalable talent systems, transparency-driven trust, and disciplined experimentation. (World Economic Forum, Organizational Transformation in the Age of AI)

Run the sensitivity check before approving the target depth

With the same illustrative inputs, changing team size changes recurring access and practice capacity. Changing target depth adds fixed design, governance, integration, and measurement work.

Team size	D1 one-time / monthly	D2 one-time / monthly	D3 one-time / monthly
4	12 / 140	54 / 148	168 / 174
8	20 / 276	62 / 284	176 / 310
16	36 / 548	78 / 556	192 / 582

The smallest team does not automatically qualify for D3. A four-person group can still have multiple process owners, missing measurement, or no time to maintain controls. Conversely, a larger team does not automatically need D3. If the work remains individual and low-risk, D1 may be the correct budget.

Use the veto when readiness is missing

Use this decision tree after the arithmetic:

1. Can you name the job and the outcome? If no, fund discovery or observation before enablement.
2. Can you name one accountable owner? If no, do not fund workflow expansion.
3. Is practice time protected inside the normal work week? If no, fund capacity or defer. Unprotected practice is not a plan.
4. Do you have evidence from real work samples? If no, fund a bounded test or D1 practice, not a cross-functional rollout.
5. Does the risk require stronger controls than the target depth includes? If yes, add governance before adoption, even if the team is otherwise small.
6. Can the team pay the recurring operating cost after the launch budget ends? If no, defer expansion until the owner can carry maintenance, review, measurement, and retirement.

My practical rule is to budget the next depth, not the most impressive destination. The worksheet gives a buyer a number, a readiness test, and a reason to stop. That is more useful than a transformation estimate that quietly assumes ownership and practice will appear later.

If you’re comparing outside help for the next depth, use this worksheet beside my guide to comparing AI consulting proposals. If the immediate gap is practice rather than implementation, the guide to making AI training stick in a small team is the closer fit. The assigned commercial parent is AI consulting and tutoring buying, and my AI learning and consulting work is the next step when you want help turning the worksheet into a bounded capability decision.