The AI delivery playbook (your actual job)

Ninety minutes. In the room: a user who does the work, a knowledge or system owner, you, optionally an engineer. Out of the room: a vendor. Agenda with times, not a free conversation that becomes a product pitch. Watch or walk the current task (15). Pain and frequency (10). Data where it lives and class (15). What 'good' means in their words (10). Thin-slice options including non-AI (15). Risks they fear (10). Score and next step (15).

Outputs you leave with: a job-to-be-done in one sentence, a corpus note (where, class, owner), a first eval definition in their words, a four-dimension score, and a no-AI alternative — process change, search, a form. If you cannot name a no-AI alternative, you did not understand the job. You understood a request for a chatbot.

Vendors do not belong in discovery. They belong later, on a scorecard, on your set. A vendor in the room will steer toward their object. You will leave with a feature list instead of a job. You already know not to invite a systems integrator to the problem-framing workshop if you want an honest problem. Same rule.

Watch the work if you can. A PM searching Slack, Confluence, and a slide deck for twenty minutes to find a decision is a different problem from 'we need a knowledge assistant.' The twenty minutes is the job. The three systems are the corpus. The definition of good is 'decision with a citation in under two minutes.' You cannot get that from a survey that asks whether people would use AI.

What 'good' means must be said in their words and then turned into an eval row. 'I would trust it if it showed the page' is a citation requirement. 'I would use it if it did not make up owners' is a groundedness and refuse requirement. Write the sentence they said, then the metric. This is how day 16 gets its first ten rows without you inventing them in a cafe.

End with a next step that is a score and a decision, not 'we will explore tools.' Fund a thin slice. Kill. Or send back for data-ready work with an owner and a date. Three exits. Meetings that end in 'this was great, let's keep talking' are how twelve POCs start. You are the person who puts a number on the board before people stand up.

Vendors do not belong in discovery. They belong later, on a scorecard, on your set. A vendor in the room will steer toward their object and you will leave with a feature list instead of a job. You already know not to invite a systems integrator to the problem-framing workshop if you want an honest problem. Same rule. If a sponsor brings a vendor anyway, park them in a later meeting and keep this ninety minutes on the work as it is done today.

Watch the work if you can. A PM searching Slack, Confluence, and a slide deck for twenty minutes to find a decision is a different problem from 'we need a knowledge assistant.' The twenty minutes is the job. The three systems are the corpus. The definition of good is a decision with a citation in under two minutes. You cannot get that from a survey that asks whether people would use AI. Time it. Write it. That sentence becomes an eval row the same afternoon.

Four dimensions. Value: frequency times time or money times willingness to change. Feasibility: data-ready, ACL path, a possible thin slice in four weeks, eval-able. Risk: blast radius, regulation, injection and write-tools. Change: a named owner and users who will do HITL. Score 1 to 5 with a one-line why. Publish the rubric. Let people argue with the rubric, not with you.

Kill anything that is high value but not eval-able. You will never know if you won. 'Executive assistant that just gets it' is not eval-able. 'Find the last recorded decision on a workstream in under two minutes with a citation' is eval-able. The second can be high value. The first is a wish that will consume a year. Feasibility includes eval-able. Do not hide that inside 'technical complexity.'

Feasibility is mostly data. If the corpus is not classed, owned, or ACL-mappable, the score is low no matter how pretty the demo. A four-week slice you cannot data-ready is not a four-week slice. It is a four-week wait plus a slice. Score the wait. Sponsors hate this dimension because it feels like obstruction. It is the dimension that predicts whether you go live.

Change is the dimension delivery leads forget to score, then relive in adoption failure. Is there a named owner who will spend hours. Are there users who will sit in shadow mode. Is HITL staffable. If the answer is 'the organization should want this,' the score is 1. Desire at the top with no roster in the middle is how copilots launch to silence.

HIPPO — highest paid person's opinion — is how you get twelve POCs. A published score does not stop a HIPPO from asking. It forces them to override in the open: 'I am funding the 2 despite the rubric because of X.' That sentence is governance. A quiet 'just do the CEO one too' is how the portfolio dies. You will still lose some of these. You will lose fewer, and you will have a paper trail.

Use the scores to sequence, not only to kill. High value, high feasibility, low risk, adequate change: fund now. High value, low feasibility: data-ready workstream, not a model workstream. High risk: shadow only, or kill. Low value: do not fund even if easy. Easy and pointless is how you spend a quarter proving you can ship trivia.

Feasibility is mostly data. If the corpus is not classed, owned, or ACL-mappable, the score is low no matter how pretty the demo. A four-week slice you cannot data-ready is a four-week wait plus a slice. Score the wait. Sponsors hate this dimension because it feels like obstruction. It is the dimension that predicts whether you go live. Change is the other one delivery leads forget: named owner, HITL hours, users who will shadow. 'The organization should want this' is a 1.

HIPPO is how you get twelve POCs. A published score does not stop a HIPPO from asking. It forces an override in the open: 'I am funding the 2 despite the rubric because of X.' That sentence is governance. A quiet 'just do the CEO one too' is how the portfolio dies. You will still lose some of these. You will lose fewer, and you will have a paper trail. Keep the rubric public so the argument is about the rubric, not about you.

You already write RAID. The novelty is the rows, not the template. Risks: hallucination on high-cost acts, ACL leak, stale corpus, cost runaway, vendor deprecation, prompt injection, HITL understaffed, adoption failure, secrets in logs, floating model pin. Issues: eval below bar, data-ready red, DPA unsigned. Assumptions: 'users will cite-check,' 'the corpus is current,' 'twelve users represent the firm.' Dependencies: identity provider, knowledge-owner hours, DPA, enterprise endpoint access, labeling time.

Write them as you would any other RAID: owner, likelihood, impact, mitigation, trigger. 'Prompt injection' without a mitigation is a keyword. The mitigation is the stack from day 15 and the HITL dial from day 17. 'Cost runaway' without a trigger is a worry. The trigger is the daily cap from day 18. Tie each row to a control you have already designed. Orphan rows are theatre.

Stale corpus is the risk sponsors underestimate. A wiki copilot that cites a 2022 SOP against a 2025 process is a confident wrong system. Mitigation: corpus owner, recrawl cadence, sample of twenty, a 'last touched' filter if you can. Issue when the owner is on leave and the recrawl is red. You already manage stale documentation on programs. Here the model will speak the stale page with more confidence than the page ever had.

HITL understaffed belongs in RAID, not only in the change plan. If the roster is two people and one leaves, you are in bound-auto you did not design, or you are in a queue that will overflow. Mitigation: backup names, a freeze-to-assist if coverage drops, a named trigger. This is the same as a single point of failure on a cutover. You already flag those.

Assumptions that users will cite-check should be treated as false until proven. Shadow and assist exist partly because they will not. If your mitigation for hallucination is 'the PM will notice,' you have an assumption, not a control. Put it in assumptions, then put a real control in risks. Mixing those columns is how RAID goes green while the design is hollow.

Review RAID on the same cadence as eval, not only at steering. A weekly fifteen minutes: which row moved, which trigger fired, which mitigation is late. AI RAID that is only a charter appendix is a dead document. You know this. Do not let the novelty of the rows make you forget the operating rhythm.

Stale corpus is the risk sponsors underestimate. A copilot that cites a 2022 SOP against a 2025 process is a confident wrong system. Mitigation: corpus owner, recrawl cadence, sample of twenty, a last-touched filter if you can. You already manage stale documentation. Here the model will speak the stale page with more confidence than the page ever had. Put the recrawl on the RAID trigger list so it is an operating item, not a folklore complaint.

Assumptions that users will cite-check should be treated as false until proven. If your mitigation for hallucination is 'the PM will notice,' you have an assumption, not a control. Put it in assumptions, then put a real control in risks: HITL, citations in the UI, groundedness bar. Mixing those columns is how RAID goes green while the design is hollow. HITL understaffed belongs here too, with a freeze-to-assist if coverage drops. Single points of failure on a cutover get flagged. Flag this.

People do not adopt a copilot that was wrong twice in week one with no citation. Trust is earned in order: shadow mode earns traces and a quiet comparison to the old path. Assist mode earns a habit because the human still sends. Champions, office hours, and a visible kill switch earn permission to keep going when it misses. Benefits tracking — time, quality, avoided rework — earns the second year of funding. Skip the order and you will ask for adoption with nothing in the bank.

Who loses a task, and who is afraid they lose a job, belongs in the change plan. If you skip it, you will meet it as resistance and call it 'culture.' A status-email draft that saves twenty minutes is a gift. A copilot that looks like it might replace the PMO's reporting role is a threat. Tell the truth about the job design. v1 is assist. v1 is not a headcount plan. If someone is planning headcount off v1, that is a different conversation and it should not hide inside your charter.

Champions are named users who will do the ugly first weeks and tell you when it is wrong. Three is enough. They need time, not a title. Put the time in their manager's view so it is real. Office hours — thirty minutes twice a week for the first month — catch the cases that would otherwise become Slack mockery. You already run this pattern on system rollouts. Copy it. Add 'bring the bad answer' as the agenda.

The kill switch is a change artifact, not only an ops artifact. Users who know you can turn it off in minutes are more willing to try it. Users who think they are stuck with a bad copilot until next quarter will not try it, or will try it once and campaign against it. Show them the switch. That is part of the launch, not a secret runbook.

Communications should say what it will refuse, not only what it will do. 'It will not answer HR salary, it will not email customers, it will show sources or it will say it does not know.' Those sentences prevent the first wrong expectation, which is the first lost champion. Over-promising 'it knows our company' is how you get the magical mental model from week 1 all over again.

Benefits tracking starts in week one of assist, not at the annual review. Time on a sampled task, rework on status emails, tickets opened that did not bounce. Small n is fine. Direction is what funding needs. A delivery lead who cannot say 'we timed eight tasks and saved four minutes on six of them, with two misses we put in the golden set' will lose the second year to a shinier vendor.

Who loses a task, and who is afraid they lose a job, belongs in the change plan. A status-email draft that saves twenty minutes is a gift. A copilot that looks like it might replace the PMO's reporting role is a threat. Tell the truth about job design. v1 is assist. v1 is not a headcount plan. If someone is planning headcount off v1, that is a different conversation and it should not hide inside your charter. Hidden headcount plans are how champions become opponents.

Champions are named users who will do the ugly first weeks and bring you the bad answers. Three is enough. Put their time in their manager's view. Office hours twice a week for the first month catch the cases that would otherwise become Slack mockery. Communications should say what it will refuse, not only what it will do. Over-promising 'it knows our company' recreates the magical mental model from week 1. The kill switch is a change artifact: users who know you can turn it off will try it.

Default sequence: shadow for two weeks, assist for four, then maybe confirm on one write. Kill if eval or adoption misses the bar. Put that on the charter tomorrow. A sequence without kill criteria is a roadmap that cannot fail, which means it cannot be managed. You already put kill criteria on troubled programs. Put them on healthy ones too, while people are calm.

Shadow exit: recall and groundedness at the bar on the golden set, plus traces from real work, plus a champion who will say out loud whether it would have helped. If you cannot exit shadow, you do not enter assist. Entering assist because the calendar moved is how week one of assist becomes two public misses and a trust hole you will not fill this quarter.

Assist exit to confirm: the same quality bar, plus reject reasons that are not dominated by 'wrong source,' plus a roster that actually reviewed, plus a written envelope for the write. If reject reasons are mostly retrieve fails, you do not have a confirm problem. You have a retrieve problem, and adding a click will not fix it.

Kill criteria examples, written in numbers. Eval: groundedness under 0.8 on two consecutive weekly samples, or must-refuse fail. Adoption: fewer than eight of twelve named users active after three weeks of assist, without a reason you accept. Risk: an ACL leak, or a SEV on a send. Cost: daily cap hit three days in a week. Any one of these pauses. Two of these kill unless a named exec waives with an expiry. Copy the waiver language from day 16.

Publish the kill before go-live so it is not personal later. When you kill, you are executing a plan, not attacking a sponsor's idea. When you pause, you are executing a plan. The difference between a delivery lead and a mascot is whether those sentences were written when everyone still liked each other.

Killing a slice is not killing AI at the company. It is how you keep the next slice fundable. A zombie copilot that nobody uses and nobody will turn off poisons the portfolio. You have seen zombie tools. Do not add one with a model in it. The death date from day 19 and the kill criteria from today are the same instinct applied to POC and to production.

Shadow exit is a gate: recall and groundedness at the bar, traces from real work, a champion who will say out loud whether it would have helped. If you cannot exit shadow, you do not enter assist. Entering assist because the calendar moved is how week one becomes two public misses and a trust hole you will not fill this quarter. Assist exit to confirm needs reject reasons not dominated by wrong source, a roster that actually reviewed, and a written envelope for the write.

Write kill criteria in numbers while people still like each other. Groundedness under 0.8 two weekly samples in a row, or must-refuse fail: pause. Fewer than eight of twelve named users active after three weeks of assist, without a reason you accept: pause. ACL leak or SEV on a send: kill unless waived. Daily cap hit three days in a week: pause. Two pauses without a fix: kill unless a named exec waives with expiry. Copy the waiver shape from day 16. Publish it before go-live so using it is not personal.

HIPPO is not always wrong. It is always unaccountable unless you make it accountable. When the highest-paid person wants the chatbot of everything, you score it in the open, you show the feasibility 1 and the risk 5, and you offer the thin slice that is adjacent and fundable. If they still override, they override in writing. You run the slice they funded, with the bar, or you refuse if it violates a control you cannot waive (restricted data with no path). Refusing a control violation is the job. Sulking about the override is not.

A portfolio of more than three active AI slices with the same HITL roster is a fantasy. Capacity is math, again. Score, sequence, park. Parking is a decision. 'Later, after Atlas is in assist and the roster has slack' is a date. 'On the backlog' is a grave. You already run intake this way. Do not let AI ideas skip intake because they are exciting.

Saying no without theatre means a short written no: the score, the missing dimension, the door back in ('data-ready checklist complete and we re-score'). A long slide about strategy is theatre. People need the door. Without a door, they will go around you to a vendor POC, and you will meet them on day 19 with a leaked production. Give them a door that is real.

Keep a public board: funded, data-ready waiting, parked, killed. Four columns. Update it when you score. Sponsors can see their idea. You can see the volume. Steering can see that kill is a column that sometimes has cards in it. A board that only shows funded work is how HIPPO assumes everything lives.

Your credibility is the rubric plus one shipped slice. A delivery lead who scores everything to death and ships nothing is a bottleneck. A delivery lead who ships without scoring is a mascot. This week is the operating system. Tomorrow's charter is the first slice. Do both. The playbook that never produces a charter is a blog.

When a hiring manager says 'walk me through how you would intake AI use cases,' this day is the answer: 90-minute discovery, four-dimension score, RAID rows, shadow-assist-confirm, kill criteria, HIPPO in the open. Draw it. Do not talk about frameworks with names. Talk about the meeting, the table, and the death of a bad idea. That is the job.

A portfolio of more than three active AI slices on the same HITL roster is a fantasy. Capacity is math. Score, sequence, park. Parking is a decision with a date: later, after Atlas is in assist and the roster has slack. 'On the backlog' is a grave. Keep a public board: funded, data-ready waiting, parked, killed. A board that only shows funded work is how HIPPO assumes everything lives. Saying no without theatre is a short written no plus a door back in: finish the data-ready checklist and we re-score.

Your credibility is the rubric plus one shipped slice. A delivery lead who scores everything to death and ships nothing is a bottleneck. A delivery lead who ships without scoring is a mascot. This week is the operating system. Tomorrow's charter is the first slice. Do both. The playbook that never produces a charter is a blog. When you say no, give a door that is real, or people will go around you to a vendor POC and you will meet them on day 19 with a leaked production.