Rolling it out

T13-L04 | Adoption & enablement | Level 4 Integrator | 42 minutes

At Level 4, your choices affect a group rather than one willing user. A poor rollout can waste a shared budget, move support work onto an unprepared colleague, normalize unsafe workarounds, or make people feel that a decision about their jobs has already been made without them.

2. The budget is approved, but the plan is not

You are asked to equip a six-person team before the end of the month. Two colleagues want access today, three are indifferent, and the person everyone trusts for difficult work is openly opposed. Leadership has approved a headline software budget and expects you to buy six seats.

The quote does not include your setup time, a walkthrough, participant time, internal support, or the licences that may sit unused. Nobody has defined which work should improve, what quality must remain unchanged, or what would make the pilot stop. If you buy first, every later question becomes pressure to justify the purchase.

You need an eight-week pilot with selected participants, an all-in cost model, a support route, and decision gates. The respected sceptic must be able to challenge quality and job-impact assumptions without being treated as an obstacle. At the end, evidence about accepted work, safety, burden, and cost will decide whether to expand, change, or stop.

3. After this you can

• Choose seat, usage, or hybrid pricing against a measured pattern of work.
• Calculate software, setup, training, participant, support, and unused-capacity costs reproducibly.
• Select a pilot group that represents users, reviewers, support needs, and credible resistance.
• Run an eight-week rollout with quality, safety, adoption, support, and stop gates.
• Decide whether to expand, revise, or stop from accepted outcomes rather than logins.

4. Prerequisites

• T13-L03 | Your AI usage policy, adopted for the participating team.
• A named rollout owner, budget owner, policy or security contact, task-quality reviewer, and internal support owner.
• Current written quotes or published rates for every shortlisted tool, including billing unit, tax treatment, minimum term, cancellation route, and date checked.
• A spreadsheet or Python 3.11 or later for the synthetic calculator in Section 6.
• Permission to ask participants about task categories, time, quality, and support without collecting prompt bodies or covert productivity data.
• One manual fallback for every pilot task and authority to pause access if a gate fails.

Use public, synthetic, or explicitly approved inputs during setup and training. Do not put employee records, customer or participant data, unpublished findings, contracts, credentials, raw prompts, or identifiable performance histories into the exercise files. Involve the responsible procurement, privacy, security, research, employment, and works-council routes where they apply. A team rollout plan does not override them.

5. The idea in one page

A rollout is a controlled service change, not a licence order. Define the work, boundary, people, cost, support, evidence, and stop conditions before assigning seats. Pilot narrowly enough that you can reverse the change without disrupting ordinary work.

Choose pricing from the expected use pattern:

Compare terms as well as the headline rate. Record minimum seats, included usage, overage, support, tax, renewal, cancellation, data controls, and the date each fact was verified. Do not share one personal credential to imitate flexible licensing; use only account patterns the provider and your organisation permit.

Count all material work:

all-in pilot cost = seats + metered use + setup + trainer time
                    + participant training time + support + other approved costs

cost per accepted outcome = all-in pilot cost / accepted outcomes

An accepted outcome is a completed instance of a named pilot task that meets the existing quality and safety check. A login, prompt, generated draft, or enthusiastic comment is not an outcome. Record zero accepted outcomes honestly; division by zero means the unit cost is not yet measurable, not free.

Select for evidence, not enthusiasm. Include the task owner, the person who checks quality, someone likely to need support, and a respected sceptic when they consent. Ask resistance what risk it identifies: job security needs an accountable employment conversation; quality needs preserved criteria and comparison; a failed earlier rollout needs ownership, support, and exit evidence. Do not make adoption compulsory merely to improve a metric.

Use five gates: policy boundary confirmed, baseline measured, safe task completed, quality preserved, and burden plus cost acceptable. Pause on a policy breach, missing owner, material quality regression, uncontrolled spend, or unavailable fallback. At week eight, expand only if named outcomes pass without hiding review or support work.

6. The worked example: one eight-week pilot, costed end to end

The Lab and Company lanes use the same plan structure, calculator, tests, and gates. Every amount below is an invented planning unit, not a current vendor price. Replace it only with an approved, dated source. The examples do not use real staff names, prompts, records, or performance data.

Build the plan before choosing a product

Start one document named rollout-plan.md. It will become the single exit artifact. Use these headings:

# Eight-week AI pilot rollout plan
Decision owner and date
Scope and non-goals
Policy and approved data boundary
Baseline task, quality check, and fallback
Pilot roles and consent
Options and dated commercial assumptions
All-in cost calculation
Week-by-week implementation
Support and objection routes
Measures, gates, stop conditions, and final decision
Appendix: calculator input, command, test result, and output

The calculator input, command output, and test result belong in the appendix of that same plan. They are supporting components, not separate submitted artifacts.

Implement a reproducible all-in calculation

Create cost_model.py in a disposable synthetic working folder:

import json
import sys
from decimal import Decimal, ROUND_HALF_UP

MONEY = Decimal("0.01")

def amount(value):
    return Decimal(str(value))

def calculate(data):
    required_nonnegative = (
        "pilot_weeks", "billed_months", "seat_count", "monthly_seat_cost", "metered_usage_cost",
        "setup_hours", "setup_hourly_cost", "training_hours_per_person",
        "participant_hourly_cost", "trainer_hours", "trainer_hourly_cost",
        "weekly_support_hours", "support_hourly_cost", "other_costs",
        "target_accepted_outcomes",
    )
    for field in required_nonnegative:
        if field not in data or amount(data[field]) < 0:
            raise ValueError(f"{field} must be present and non-negative")
    if int(data["seat_count"]) != amount(data["seat_count"]):
        raise ValueError("seat_count must be a whole number")

    seats = (amount(data["seat_count"]) * amount(data["monthly_seat_cost"])
             * amount(data["billed_months"]))
    usage = amount(data["metered_usage_cost"])
    setup = amount(data["setup_hours"]) * amount(data["setup_hourly_cost"])
    participants = (amount(data["seat_count"]) * amount(data["training_hours_per_person"])
                    * amount(data["participant_hourly_cost"]))
    trainer = amount(data["trainer_hours"]) * amount(data["trainer_hourly_cost"])
    support = (amount(data["pilot_weeks"]) * amount(data["weekly_support_hours"])
               * amount(data["support_hourly_cost"]))
    other = amount(data["other_costs"])
    total = seats + usage + setup + participants + trainer + support + other
    target = amount(data["target_accepted_outcomes"])

    return {
        "currency_label": data["currency_label"],
        "seat_cost": str(seats.quantize(MONEY, rounding=ROUND_HALF_UP)),
        "metered_usage_cost": str(usage.quantize(MONEY)),
        "setup_cost": str(setup.quantize(MONEY)),
        "participant_training_cost": str(participants.quantize(MONEY)),
        "trainer_cost": str(trainer.quantize(MONEY)),
        "support_cost": str(support.quantize(MONEY)),
        "other_costs": str(other.quantize(MONEY)),
        "all_in_pilot_cost": str(total.quantize(MONEY, rounding=ROUND_HALF_UP)),
        "target_cost_per_accepted_outcome": (
            None if target == 0 else str((total / target).quantize(MONEY, rounding=ROUND_HALF_UP))
        ),
    }

if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as source:
        print(json.dumps(calculate(json.load(source)), indent=2))

Add test_cost_model.py:

import unittest

from cost_model import calculate

BASE = {
    "currency_label": "invented units",
    "pilot_weeks": 8,
    "billed_months": 2,
    "seat_count": 6,
    "monthly_seat_cost": 24,
    "metered_usage_cost": 80,
    "setup_hours": 12,
    "setup_hourly_cost": 55,
    "training_hours_per_person": 2,
    "participant_hourly_cost": 45,
    "trainer_hours": 5,
    "trainer_hourly_cost": 55,
    "weekly_support_hours": 2,
    "support_hourly_cost": 50,
    "other_costs": 120,
    "target_accepted_outcomes": 30,
}

class CostModelTests(unittest.TestCase):
    def test_counts_all_cost_categories(self):
        result = calculate(BASE)
        self.assertEqual(result["seat_cost"], "288.00")
        self.assertEqual(result["support_cost"], "800.00")
        self.assertEqual(result["all_in_pilot_cost"], "2763.00")
        self.assertEqual(result["target_cost_per_accepted_outcome"], "92.10")

    def test_zero_outcomes_are_not_reported_as_free(self):
        data = {**BASE, "target_accepted_outcomes": 0}
        self.assertIsNone(calculate(data)["target_cost_per_accepted_outcome"])

    def test_rejects_negative_or_fractional_seats(self):
        with self.assertRaisesRegex(ValueError, "seat_count"):
            calculate({**BASE, "seat_count": -1})
        with self.assertRaisesRegex(ValueError, "whole number"):
            calculate({**BASE, "seat_count": 2.5})

if __name__ == "__main__":
    unittest.main()

Save pilot.json with the BASE fields and values as valid JSON. Run:

python -m unittest -v
python cost_model.py pilot.json

All three test methods must report ok. The result must include:

seat_cost: 288.00 invented units
participant_training_cost: 540.00 invented units
support_cost: 800.00 invented units
all_in_pilot_cost: 2763.00 invented units
target_cost_per_accepted_outcome: 92.10 invented units

These values are planning evidence, not a promise. At the end of the pilot, replace estimates with approved actual invoices or usage totals and recorded hours, then divide by actual accepted outcomes under the same acceptance rule. Keep raw prompts and identifiable activity out of the cost record.

Lab framing: improve one group reporting task

Mira plans an eight-week pilot for six roles in a fictional research group: rollout owner, two researchers who prepare weekly literature summaries, one technician who reviews traceability, one administrator who handles access, and one respected senior researcher who doubts that generated summaries preserve qualifications. Participation is voluntary; the sceptic is invited as quality challenger, not appointed as unpaid support.

The scoped task is prepare a first-draft evidence table from public papers already selected by a researcher. The baseline sample is ten wholly synthetic paper cards. A completed outcome is accepted only when every identifier and supplied number matches its card, every missing value is marked, no conclusion is invented, and a researcher signs the review. Selection, interpretation, citation, and publication remain human work. The fallback is the current manual table.

Mira records a 32-minute median baseline over six synthetic runs and a target of 30 accepted tables during the pilot. For the worked fixture she chooses the invented Northstar Team Assistant under six named managed accounts and two billed months. This is not a recommendation or a live commercial claim. She inserts the synthetic cost output above into the plan, then records the real quote fields as blank pending procurement confirmation. She does not copy the invented 24 into a purchase request. The budget owner must date every real rate and billed quantity before the plan can move from draft to approved.

Weeks 1-2 cover accounts, the T13-L03 rule, safe fixtures, and baseline checks. Weeks 3-4 run two participants while the technician compares every table with its source cards. At the first gate, one of eight drafts drops a limitation. The quality criterion therefore fails. Mira pauses expansion, changes the workflow instruction and review checklist, and reruns the fixed synthetic cases. Weeks 5-6 proceed only after all fixed cases pass; the remaining three participants join and support questions go to a named channel for two scheduled hours each week. Weeks 7-8 measure accepted tables, correction time, support time, abandoned attempts, and incidents.

The senior researcher's objection becomes a test: Does the assisted route preserve every supplied limitation at least as reliably as the baseline, after counting review time? Their concern improves the gate. It does not require them to use the tool or defend the rollout. If quality is lower, review burden rises, or a data-boundary incident occurs, Mira pauses and uses the manual route.

At the final review, suppose 27 tables were attempted, 23 met the acceptance rule, median end-to-end time fell from 32 to 24 minutes, review time rose by three minutes, support used 19 hours rather than the planned 16, and no policy incident was reported. These invented observations do not automatically justify expansion. The outcome target of 30 was missed, support exceeded plan, and cost per actual accepted table must be recalculated. The decision owner records revise and extend narrowly, with no additional seats until the support cause and limitation failure are addressed.

Company framing: improve the parallel reporting task

Jonas applies the same design to a fictional customer-operations department. The six pilot roles are rollout owner, two agents who prepare weekly issue summaries, one quality reviewer, one access administrator, and a respected senior agent who expects generated text to hide exceptions. He uses the same invented Northstar Team Assistant, six managed accounts, and two billed months so the comparison stays parallel. The tool receives only synthetic tickets during setup. Any later internal use remains within the adopted policy; customer messages, account actions, refunds, and employee monitoring are out of scope.

The task is prepare a first-draft issue table from tickets already selected by an agent. A completed outcome is accepted only when ticket IDs and supplied quantities match, missing information is visible, policy exceptions are retained, and an agent approves the internal table. No output is sent to a customer or written back. The fallback is the existing manual report. The same six-card baseline takes a synthetic median of 32 minutes, and the plan uses the same 30-outcome target and invented calculator assumptions so the two framings remain comparable.

The senior agent reframes resistance as Does the assisted route preserve every supplied service exception after review, without transferring hidden correction work to agents? In week 3, one draft drops an exception, so Jonas pauses exactly as Mira did. After repair and a full synthetic rerun, the pilot resumes. He records accepted internal tables, total task time, reviewer corrections, support hours, unused seats, opt-outs, and policy events, not keystrokes or private prompt histories.

At week eight, Jonas records the same fictional outcome pattern and chooses the same revise and extend narrowly decision. Company vocabulary does not change the gates. Leadership receives the evidence that missed the target as well as the time reduction. The plan names the quality owner, support owner, budget owner, objection route, next decision date, and conditions for reclaiming seats. It does not label the sceptic resistant, rank individual workers, or convert the pilot into an employment assessment.

Integrate procurement, access, support, and evidence

Before week 1, the rollout owner checks that the selected account type matches the approved data boundary, procurement terms, identity controls, support route, retention requirement, and cancellation plan. Access is assigned to named pilot members only. The owner records who can add or remove seats and tests one removal with a synthetic account where permitted.

Each week, the same short operating loop runs:

perform named task -> apply existing quality check -> accept or reject outcome
                  -> record duration and support category -> review gate

The record needs task ID, lane, date, accepted yes/no, total duration, review duration, support category, tool incident yes/no, and optional non-identifying note. It does not need source content, prompt text, employee sentiment attached to a name, or generated output. Aggregate only after checking that small groups will not expose individuals.

The owner reviews spend against the cap, support demand against available hours, quality against baseline, and every incident against the adopted policy. At the final gate, they choose exactly one state: expand, revise and rerun, or stop and reclaim access. A leadership preference is an input, not a substitute for the declared gate.

7. What goes wrong

You buy for everyone before the pilot

Symptom: a large seat count creates pressure to call the rollout successful before one task or quality bar has been tested.

Fix: buy or assign the smallest permitted pilot allocation, record minimum terms, and make later seats conditional on accepted outcomes and manageable support.

Logins are reported as adoption

Symptom: the dashboard shows active accounts, but nobody can name a completed task that passed its normal review.

Fix: count accepted instances of one declared task. Report attempts, rejections, review time, and abandoned runs beside the accepted count.

The respected sceptic is ignored or recruited as decoration

Symptom: concerns appear late as blocked approvals, quiet workarounds, or refusal, while the plan says stakeholders were consulted.

Fix: invite the sceptic to name a testable concern, give it a gate and owner, allow refusal, and report the result even when it weakens the expansion case.

Headline software price hides labour

Symptom: the business case counts seats but setup, participant time, review, training, support, procurement, and retries appear as free.

Fix: run the all-in model, reconcile estimates with actual hours, and show both total cost and cost per accepted outcome under a fixed quality rule.

Questions go to the busiest helpful person

Symptom: one colleague answers private messages, repeats fixes, and becomes an invisible support desk.

Fix: name the support owner, channel, service hours, escalation route, and capacity. Record categories and time; pause expansion when demand exceeds the plan.

Quality checks disappear to make time savings look larger

Symptom: assisted task time excludes source checking while baseline time includes it.

Fix: measure end to end under the same acceptance condition. Keep review time visible and reject outputs that do not meet the existing standard.

The pilot has no end state

Symptom: week eight arrives, seats renew, temporary permissions persist, and nobody makes a decision.

Fix: schedule the decision owner and date at the start. Require expand, revise and rerun, or stop and reclaim access, then execute access and renewal changes.

8. Do it yourself: write the rollout plan in 90 minutes

Use one real team and one permitted task, but use public, synthetic, or explicitly approved records for baseline and setup. Produce one plan; do not purchase, invite users, or change production access during this exercise.

Minutes 0-10: name the decision, rollout, budget, policy, quality, and support owners. Copy the active policy boundary and manual fallback. State who is affected if quality, access, or support fails.

Minutes 10-20: define one recurring task and one accepted outcome. Write the existing quality check, baseline procedure, out-of-scope actions, and stop conditions. Do not define adoption as account activity.

Minutes 20-30: choose four to eight pilot participants by role. Include task performance, review, access, support need, and credible challenge. Record consent and accommodations without collecting protected personal explanations.

Minutes 30-45: obtain dated pricing facts through the approved route. Record seats, usage, minimums, included allowances, overage, support, tax, term, renewal, and cancellation. Put unknowns in the plan with an owner; do not estimate them away.

Minutes 45-57: adapt pilot.json, run the three tests, and calculate the plan. Replace invented amounts only with approved values. Paste input, command, test result, and output into the plan appendix. Label estimates and actuals separately.

Minutes 57-70: write weeks 1-8, including account setup, policy walkthrough, safe baseline, staged participation, support hours, weekly reviews, a midpoint gate, final measurement, access reclamation, and decision meeting.

Minutes 70-80: ask the respected sceptic or an independent reviewer for one quality, job-impact, or prior-rollout concern. Convert it into a test, owner, route, or explicit unresolved item. Do not demand tool use as the price of being heard.

Minutes 80-90: inspect the plan against the exit check. Recalculate one boundary case with zero accepted outcomes, confirm it returns null, and verify that no real prompt, source content, credential, personal performance record, or unsupported price remains. Ask the decision owner to mark the plan approved, rejected, or draft with reasons.

If Python reports a missing field, compare pilot.json with every required name rather than changing the script to assume zero. If a decimal uses a comma, store it as a JSON number with a decimal point and render local formatting only after calculation. If the total differs, run the tests unchanged, then inspect pilot weeks, billed months, seat count, hourly rates, and whether participant time was counted twice. Do not prorate a monthly price unless the dated quote permits it. If pricing cannot be verified, leave the plan in draft with the unknown and owner; an invented amount is not approval evidence.

9. Exit check

Deliver exactly one artifact: one rollout plan with per-seat or metered cost, chosen tool and account boundary, all-in pilot cost, and a named path for objections.

It passes when the same document names the decision and operating owners; affected team; eight-week scope; task and non-goals; adopted policy boundary; pilot roles; dated commercial assumptions; seat, usage, setup, trainer, participant, support, and other costs; tested calculation and expected output; baseline; accepted-outcome rule; support route; objection route; quality, safety, cost, and stop gates; fallback; final decision date; and access-reclamation action. A third party must be able to rerun the calculation and tell what would cause expand, revise and rerun, or stop.

It fails if it counts logins as outcomes, omits participant or support time, uses unverified live prices, forces the sceptic to participate, hides failed outcomes, lacks a quality-preserving baseline, or contains raw prompts, sensitive records, credentials, or identifiable performance monitoring.

10. Rule to remember

Win the respected sceptic, not the eager volunteer.

11. Further reading & tools

• Taught: T13-L03 | Your AI usage policy - supplies the adopted tool, account, data, question, and incident boundaries that the pilot must not broaden.
• Taught: What AI really costs - separates model or licence charges from retrieval, retries, platform work, human review, and cost per accepted outcome.
• Taught: Python unittest documentation (opens in a new tab) - primary reference for reproducing the standard-library calculator tests.
• Catalogued: FinOps Framework (opens in a new tab) - allocation, planning, measurement, and unit-economics practices that can extend the pilot model.
• Catalogued: FinOps for AI overview (opens in a new tab) - current FinOps Foundation overview of AI cost and value practices; apply it with local quality and governance requirements.
• Catalogued: NIST AI Risk Management Framework (opens in a new tab) - voluntary governance framework for mapping, measuring, and managing risk; it does not approve a purchase or workplace use.
• Catalogued: Tools index - compare approved products only after task, data boundary, pricing pattern, support capacity, and decision gates are defined.