--- name: ai-fmo-procedure description: > A guided, gated interview that takes an organisation from its current mode of operations to a designed future mode of operations with AI used to its practical maximum. Built on the four Ps of strategy (Purposes, Players, Partnerships, Processes), the Oxford Scenario Planning Approach, and the SPOC organising framework. Produces two linked documents: a strategy playbook and a future mode of operations blueprint. Run it with an AI as interviewer, or facilitate it manually from the same question set. metadata: author: Bogdan Rynkowski version: "1.7" date: "2026-08-29" tags: strategy, ai-transformation, four-ps, scenarios, target-operating-model --- # Redesigning the Organisation for AI *A guided procedure for producing a strategy playbook and a future mode of operations.* Version 1.7, August 2026. Method developed by the author during the Oxford AI-Driven Business Transformation Executive Programme, Saïd Business School, and tested against a live clinical-AI playbook (Rynkowski, 2026). Changes in this version are listed at the end. Independent work by a programme alumnus. Not endorsed by, affiliated with, or published on behalf of the University of Oxford, Saïd Business School, or any other organisation named here. --- ## What this is Most AI transformation programmes fail in the same place. The pilots work, the production estate stalls, and the gap between the two is an execution layer nobody owned. The plan was written against a single assumed future, and when that future moved, the plan had no second move to make. This procedure closes both gaps at once. It is an interview: a setup stage and ten working stages, each with a gate that blocks progress until the answer is good enough to act on. The output is two documents that reference each other, so every organisational change can be traced back to a strategic play, and every play back to a future the organisation might actually get. **What it produces** 1. `playbook.md`: a strategy playbook in the format set out below. Scope, scenarios, plays across the four Ps, the moves that pay in every future, signals, breakpoints, agility, synthesis. 2. `fmo.md`: the future mode of operations. Redesigned decisions, human involvement model, roles and decision rights, governance and model lifecycle, sequencing, and a traceability matrix. 3. `state.md`: the working record, so the procedure can be paused and resumed across weeks. **What it will not do** It will not tell you which future arrives. It will not produce a business case for a specific tool. It will not survive being run by one person alone, and the procedure says so at the point where that becomes the binding constraint. --- ## The engine Six moves, in order. Everything below is the detail. Name the future your current strategy already assumes. Build two to four contrasting external futures next to it. For each future, work the four Ps and force each play to state what it demands of Systems, People, Organisation and Culture. Read across the futures to find the moves that pay in all of them, and commit those now. Assemble the operating model from the accumulated demands. Attach signals to the futures so the pre-built plays have a trigger. The discipline that makes it work: strategy is multiplicative rather than additive (Powell, 2017). Plays that merely sit next to each other are weak. Plays that each make the next one possible compound, and the order of compounding is itself a finding. --- ## How to run it **Time.** Eleven stages, numbered 0 to 10. Budget 45 to 90 minutes per stage of live questioning, plus evidence-gathering between stages. Stage 2 and Stage 7 will overrun. Let them. **Cadence.** Two stages per week works. Faster than that and the evidence requests between stages go unanswered, and the gates start passing on opinion. **Who is in the room.** Stated per stage. The default is wrong for most stages. One person cannot produce a playbook the organisation will accept, and open strategy processes are a source of quality rather than a courtesy. Relevant knowledge sits close to the ground, with the people running the decisions being redesigned. Bring them in. **Resuming.** After each stage the interviewer writes the stage record to `state.md`. To resume, load `state.md` and this file, and continue at the first stage marked OPEN. **Manual facilitation.** Every question below is written to be asked out loud. Drop the interviewer contract and run the gates as a review at the end of each session. --- ## Interviewer contract *Rules for the AI conducting this procedure. Read before Stage 0.* 1. **One question at a time.** Wait for the answer. Do not batch a stage into a single wall of questions. 2. **Do not answer for the user.** If asked for candidates, provide them, clearly marked as candidates for the user to accept, reject or edit. Candidates are never recorded as answers. 3. **Gates block.** When a gate fails, say which criterion failed, quote the answer that failed it, and ask the specific question that would fix it. Do not proceed to the next stage. Do not soften a gate because the user is short of time. 4. **Never invent.** Figures, dates, names, quotes, citations, regulatory positions and market claims come from something actually read: a document the user supplied, a search result, or the user's own words. If it is not there, mark it OPEN in the state file and move on. A stage record with a stated gap is complete. A stage record with an invented gap-filler is a failure, however well it reads. 5. **Separate what was said from what was inferred.** In every stage record, keep two headings: `Stated` and `Inferred`. Inference about structure, ordering and consequence is welcome. Inference about facts is not. 6. **Name assumptions out loud.** Where a question is ambiguous and the answer would change the output materially, ask. Where it is minor, choose, and flag the choice in one line. 7. **Push on vagueness.** "Invest in AI" is not a play. "Improve data quality" is not a play. A play names what changes, who owns it, what triggers it, and what stops it. Send it back. 8. **Do not claim verification you did not perform.** If the user says a number is right, record it as user-supplied, not as verified. 9. **Run the closing audit.** Stage 10 is not finished until the silent-failure audit at the end of this document has been run and reported. --- ## Stage 0. Setup **Purpose.** Establish who is doing this, at what cadence, with what authority, and create the state file. **In the room.** The sponsor. **Questions** - 0.1 Who is sponsoring this work, and what decision rights do they hold over budget, headcount and portfolio? - 0.2 Who else must be in the room for Stages 2, 5 and 7? Name people, not functions. Stage 2 needs the people who currently make the decisions in scope. Stage 5 needs someone who will lose power in the redesign. Stage 7 needs whoever owns production systems. - 0.3 What is the cadence, and what is the date by which the playbook must exist? - 0.4 What has already been tried here, and what happened to it? - 0.5 What would make this exercise a waste of time? - 0.6 **Literacy check.** For each participant, what have they personally built, bought or governed in AI? Not what they have read or attended. The room is about to judge where the technology genuinely helps and where it fails, and executive teams routinely overestimate their standing to make that call. **Gate 0.** A named sponsor with stated decision rights, a date, and at least three named participants beyond the sponsor. If the answer to 0.2 is "just me", record that as the first known weakness of the playbook and carry it into Stage 9 as an agility finding. Second criterion, and it blocks: at least two participants must clear 0.6 with direct experience rather than exposure. Where the room does not clear it, a literacy session runs against this organisation's own systems and data before Stage 2 opens. Grounding the session in the actual business beats abstract training (Hoque, Davenport & Scade, 2026). A room that cannot say what AI does in its own operation will produce a confident redesign built on what it read in the press. **Record.** Participants with literacy standing, cadence, deadline, prior attempts, known weaknesses. --- ## Stage 1. Scope and the decisions in play **Purpose.** Narrow the playbook to something a leader can act on. Sharp and narrow beats broad. This is the single most common failure of an AI strategy document. **In the room.** Sponsor plus one commercial and one technical leader. **Questions** - 1.1 Who is this playbook for? Name the person or body that will read it and act on it. - 1.2 Which part of the organisation is in scope? State what is explicitly out of scope. - 1.3 Name the two or three decisions this playbook must make possible within twelve months. - 1.4 Why is this an AI and innovation problem now rather than in three years? What changed in the last eighteen months? - 1.5 What budget and headcount can the sponsor actually move without a further approval? A scope with no number attached is a discussion, not a decision. - 1.6 What is the capital constraint? Most incumbents cannot fund new platform capex, which pushes the answer toward recurring revenue from assets already owned. - 1.7 **The honest driver.** Is this genuinely about what AI can now do, or is it a cost programme that has adopted AI language? Answer it in the room, once, out loud. Restructuring dressed as transformation is common and it is legible to the workforce long before it is legible to the board. If the answer is the second one, this procedure is the wrong tool. Stop here and run the cost programme honestly. **Gate 1: the sharpness test.** The scope statement must name four things: the reader, the part of the organisation, the strategic question, and the shift being attempted. Miss one and it fails. > Fails: "This playbook covers AI across our insurance business." > > Passes: "This playbook is for the executive committee of a mid-market insurer, focused on how underwriting and claims decisions are made once AI carries the first pass, so that adoption moves from isolated pilots to a governed production estate under a single accountable owner." If the scope statement would fit another company in the same sector without editing, it is too broad. Send it back once. If the second attempt is also broad, stop and split the work into two playbooks. **Record.** Scope statement, decisions in play, capital constraint, out-of-scope list. --- ## Stage 2. The ghost scenario and the current mode of operations **Purpose.** Two things at once. Surface the future the current strategy already assumes, and build a factual baseline of how decisions are made today. Both are needed before any redesign, and both are usually missing. Every strategy rests on an implicit view of the future context. Left unexamined, those assumptions come back to haunt execution (Lang & Ramírez, 2023). Naming them is cheap. Not naming them is how a plan gets taken out of context and becomes expensive. **In the room.** The people who currently make the decisions in scope. Not their managers. ### Part A: the ghost - 2.1 Write the future your current strategy assumes, in five sentences, in the past tense, as though it already happened. - 2.2 List the assumptions holding it up. Aim for eight to twelve. For each, mark: evidenced, contested, or untested. - 2.3 Which single assumption, if false, breaks the largest part of the plan? - 2.4 When was that assumption last tested against evidence, and by whom? - 2.5 Who in the organisation already disagrees with it? What do they say? ### Part B: the baseline - 2.6 **Decision inventory.** List the ten to twenty recurring decisions inside the scope. For each: who decides, on what evidence, how often, how long it takes, and the cost of getting it wrong. This is the spine of the whole procedure. A process map is not a substitute. Sort each entry by the question the supporting system was built to answer. Systems of record answer what happened. The redesign in Stage 7 will ask them what should happen next, which is a different question and frequently a different system (Panda & Soller, 2026). - 2.6a **Connective work.** Under each decision, list the work that carries it and is not itself a decision: who gets informed, who escalates, who translates between functions, who notices when it is drifting, who holds the relationship that makes the answer acceptable. This is the work that does not appear in a job description and does not survive a role-level cut. Organisations that lose critical expertise in a restructuring generally did not know what the removed role was doing (Hoque, Davenport & Scade, 2026). - 2.7 Where does judgement actually live? Mark each decision as rule-following, pattern-matching, or genuinely judgemental. Be honest: most work labelled judgement is pattern-matching under time pressure. - 2.8 What data do you own outright, what do you rent, and what do you hold usable rights to for training and inference? Name the contracts that decide this. - 2.9 What AI is in production today, and what has it measurably changed? Separate production from pilots. A pilot that has run for two years is not a pilot, it is an unowned system. - 2.9a **The architecture ceiling.** What does the current technical estate make impossible, as opposed to slow? Name the specific limits: batch cycles that delay a decision by hours, data that cannot be joined, latency that rules out an in-flow answer, systems with no event stream to listen to. Ask what the estate is preventing the business from doing, and quantify what that prevention costs. A decision inventory built without this produces redesigns that cannot run. - 2.9b What proportion of technology spend goes to running what already exists rather than to building anything new? Where that share is high, the modernisation cost of any redesign is understated by default. - 2.10 What proportion of budget and people sit on exploit work versus explore work today? - 2.11 What was tried and abandoned, and why? **Gate 2.** Passes when: at least five load-bearing assumptions are named, each phrased so it could be shown false; the decision inventory has at least ten entries with volume and cycle time attached; the architecture ceiling in 2.9a names specific limits rather than general dissatisfaction with legacy systems; the connective work in 2.6a is documented by the people doing it rather than by their manager; and the data rights answer names contracts rather than systems. An inventory without volumes and cycle times cannot support the viability test in Stage 7. Send it back. **Record.** Ghost scenario narrative, assumption register with status, decision inventory table including connective work, architecture ceiling, data rights position, run-versus-build spend split, exploit/explore split, abandoned attempts. --- ## Stage 3. Scenarios **Purpose.** Build two to four contrasting external futures. These are contexts around the organisation, not plans for it. **In the room.** Widest group of the whole procedure. Include people from outside the function, and at least one person who talks to customers or regulators weekly. **Method note.** Adapt a published set rather than inventing one. Public scenario sets carry research weight the room cannot replicate in a workshop, and adapting them is faster and more defensible than starting from a blank page (Lang & Ramirez, 2021). Compressing a five-scenario set to the two poles that dominate capital allocation is legitimate, provided the compression is declared as a simplification rather than presented as the source's own conclusion. **Questions** - 3.1 Which published scenario set will you adapt? Name it and its author. - 3.2 What single uncertainty most decides capital allocation inside your scope? State it as an axis with two poles. - 3.3 For each pole, describe the world in 2030 (or your chosen horizon) under six headings: what the rules are, who holds power, where value sits, what counts as evidence, how money moves, and where talent goes. - 3.4 In each future, what does AI change about the rules of the sector? If AI is mentioned once and then forgotten, the scenario is not AI-rich and the whole playbook weakens. - 3.5 What is the horizon date, and why that date? - 3.6 Name three things that are true in both futures. Those are your certainties, and they belong in the FMO regardless of which future arrives. **Gate 3: three tests.** - **Externality.** Delete your organisation's name from the scenario. Does it still describe a plausible future for the wider environment? If the scenario contains your response, it is a plan wearing a costume. Rewrite it. - **AI-richness.** Does AI change power, rules or value inside the scenario, or is it decoration? - **Plausibility parity.** Could an intelligent colleague argue seriously for each one? A scenario nobody believes is a straw man, and its plays will be straw too. > Worked example. A clinical-AI playbook compressed the UK Government Office for Science AI 2030 set to a single axis: whether clinical and regulatory trust in AI holds or fractures by 2030. Frozen Trust is the world where a run of AI-assisted clinical errors triggers moratoriums, procurement withdrawal and mandatory human sign-off, and power moves to regulators and liability insurers. Full Commitment is the world where the clinical evidence lands, regulation shifts from pre-market certainty to post-market surveillance, and power concentrates at the integration layer and the outcome data. Neither names a company. Both are equally plausible (Government Office for Science, 2025; Rynkowski, 2026). **Record.** Source set and adaptation, axis, two to four scenario narratives, horizon, shared certainties. --- ## Stages 4 to 7: how the four Ps work here Each of the next four stages produces two things. **The play.** What the organisation does under each scenario. Outward-facing, strategic, per future. **The deltas.** What that play demands of the organisation, sorted into four buckets: Systems (routines, gates, pipelines, tooling), People (roles, skills, hiring, incentives), Organisation (structure, decision rights, reporting), Culture (norms, what gets rewarded, what gets tolerated). The four buckets follow the building blocks of Tushman and O'Reilly's congruence model, the critical tasks, the people, the formal organisation and the culture, used here as the receiving structure for strategic plays (Tushman & O'Reilly, 1997). The deltas accumulate across the four stages and become the future mode of operations in Stage 10. A play with no deltas is either already executable today, which is rare, or it has not been thought through, which is common. Ask which. --- ## Stage 4. Purposes **Purpose.** Establish what AI changes about why the organisation exists, what it sells, and who grants it permission to operate. **In the room.** Sponsor, commercial lead, and someone who represents a purpose that is not profit. **Questions** - 4.1 State the purpose of the organisation in one sentence a front-line employee could act on this week. - 4.2 Under each scenario, what does AI change about where value comes from? Follow the value: from units shipped to recurring service, from product to governed decision, from output to outcome. - 4.3 Under each scenario, who grants legitimacy, and what do they require? Legitimacy is often the scarce input while capability is abundant and getting cheaper. - 4.4 What would you sell under each scenario that you do not sell today? - 4.5 What would you stop selling? - 4.6 **Plurality.** Which purposes inside the organisation compete with each other? Profit, survival, mission, employment, safety, and local commitments rarely align neatly. Name the two that conflict most sharply once AI scales. - 4.7 Whose purpose loses when AI wins here? Answer with a function and a name. - 4.8 **Tenets.** State the three to five beliefs that will govern every recommendation in this playbook. Each one must be capable of ruling a candidate play out, otherwise it is a slogan. Revisit this list at Gate 8 and cut any tenet that never rejected anything. **Deltas.** What must be measured differently. What P&L logic changes. What has to be said out loud to the workforce, and by whom. **Gate 4.** Passes when the plurality question has a real answer and the losing purpose is named. A purpose statement that everyone in the organisation would endorse without argument has not been tested. Send it back with question 4.7 alone. **Record.** Purpose statement, tenets, per-scenario value shift, legitimacy holders, start-selling and stop-selling lists, competing purposes, deltas. --- ## Stage 5. Players **Purpose.** Identify who really matters, per scenario, outside and inside. Players are defined by two things: power, meaning the ability to influence strategy, and attention, meaning how closely they watch what you do. **In the room.** Someone who will lose decision rights in the redesign. If that person is not in the room, this stage produces a map that will be quietly ignored later. ### Outside - 5.1 List stakeholders across market and non-market: owners, customers, customers' customers, suppliers, competitors, regulators, standards bodies, insurers, professional associations, works councils and unions, media, campaign groups, academic institutions, cloud and model suppliers. - 5.2 Score each on power and attention, and place them on the map. Both can change without warning, so record the score with a date. - 5.3 Under each scenario, who gains power and who loses it? Move them on the map and keep both versions. - 5.4 Under each scenario, who is the real buyer? It is frequently not the end user. Where liability gates a sale, the risk officer and the insurer are the buyers, and the person using the tool is not. - 5.5 For the top three players in each scenario, what is the engagement move, who owns it, and at what cadence? ### Inside - 5.6 Which roles gain decision rights in the future mode of operations, and which lose them? - 5.7 Who has to agree for the redesign to proceed, and what do they want that is not on the table yet? Separate their stated position from their underlying interest. The workable solution is almost always at the interest level. - 5.8 What happens to the people whose work the redesign removes? Answer before the design goes further, not after. **Deltas.** Roles created and retired. Decision rights moved, with the document that records the move. Incentive and KPI changes. Who communicates the change. **Gate 5.** Passes when internal losers are named with a mitigation each, and when at least one non-market player appears in the top three for at least one scenario. A redesign that names no losers has not been designed. It has been described. **Record.** Power and attention map per scenario, real buyer per scenario, engagement moves with owners, internal decision-rights shifts, deltas. --- ## Stage 6. Partnerships **Purpose.** Set the boundary of the firm under each future. What you build, what you buy, what you ally on, and what you refuse to give away. **In the room.** Procurement or vendor management, plus legal. **Questions** - 6.1 Which relationships confer credibility under each scenario? Credibility-conferring partners are different from revenue-generating ones, and under a low-trust future they decide whether you trade at all. - 6.2 Which current dependencies become dangerous under each scenario? For each: how quickly could it strand a product line, how substitutable is it, and what is the notice period in the contract? - 6.3 Where are you a node in someone else's stack, and where are you the orchestrator? Name the layer you will not give up, and say why. - 6.4 Which capability must stay in-house because it is the basis of trust or margin? - 6.5 What positive-sum structure is available? Revenue share, co-investment, shared standard, data cooperative. Partnerships can be accretive rather than depletive, and platform logic inverts the usual assumption that a powerful supplier is a threat. - 6.6 Which partner, if they moved one layer up the stack, would own your customer relationship? What is in the contract to prevent it? - 6.7 Where would you accept liability for someone else's model? The correct answer is usually nowhere, and the contract should say so. **Deltas.** Contract clauses to add: data rights, notice periods, liability walls, orchestration boundaries. Partner governance cadence. Dual-sourcing where single-source risk is unacceptable. **Gate 6.** Passes when every dangerous dependency has a stated strand risk and a named response, and when the make/buy/ally boundary is stated as a rule rather than a list. Lists go stale within a year. Rules survive. **Record.** Credibility partners, dependency register, boundary rule, positive-sum structures, contract deltas. --- ## Stage 7. Processes and the future mode of operations **Purpose.** The largest stage. Redesign the decisions from the Stage 2 inventory with AI used to its practical maximum, then build the governance that keeps the redesign safe, funded and honest. Run 7A and 7B in separate sessions. **In the room.** 7A: the decision owners from Stage 2 plus a data or ML lead. 7B: whoever owns production systems, plus risk, plus finance. ### 7A. Decision redesign - 7.1 Take the top five decisions from the Stage 2 inventory, ranked by volume multiplied by cost of error. For each, design the target state: what the machine decides alone, what it proposes for approval, what a human must decide unassisted, what evidence travels with the decision, and what the cycle time becomes. - 7.2 For each decision, set the human involvement model and justify it by cost of being wrong. - **Above the loop:** humans set the rules the machine enforces, and audit the enforcement. Highest leverage, hardest to build. - **In the loop:** a human approves each output. Expensive, and worthless if the human cannot trace what they are approving. Blanket sign-off on outputs nobody can interrogate is theatre with an audit trail. - **Out of the loop:** fully automated, with a stop threshold. - 7.3 **Redeployment ledger.** Do not list what disappears. Build a ledger that balances: capacity released by function, capacity absorbed by function, capacity removed, netting to a total. A redesign that releases capacity and cannot say where it lands has not finished. The ledger is the first thing a CFO, a works council and the workforce will each ask for, and they will ask for it in that order. - 7.3a **Reversibility.** For every workforce change in the ledger: what does unwinding it cost, how long does it take, and what is lost for good. Rehiring runs slower than cutting, costs more, and returns someone who does not carry the institutional knowledge that walked out. Reversibility is priced here, before the change, rather than discovered afterwards. Attrition and internal redeployment are exhausted before elimination, and phased reduction is the default where the evidence is still accumulating (Hoque, Davenport & Scade, 2026). - 7.4 **Architecture delta.** What must the technical estate do that it cannot do today for this design to run in production rather than in a demonstration? State it against the ceiling recorded in 2.9a: data joined, event published, latency met, access granted. Then cost it and carry that cost into 7.5. An architecture change priced outside the viability test is a redesign that will be approved and then quietly fail to ship. - 7.5 **Viability test, per redesigned decision.** Cost to build, cost to run (including compute, licences, retraining and the people who operate it), the benefit expressed in the unit the business already reports, and the payback period. Automation that is technically feasible is not automatically worth doing. The economics turn on the cost of what is displaced, and that cost varies by market. - 7.6 Which redesigned decisions use existing, tested tooling, and which require building something new? Prefer the former. The risk of a novel build frequently outweighs its advantage over an existing tool. ### 7B. Governance, lifecycle and proof - 7.7 Who owns each model in production, by name? What are their standing duties, and how often do they report? - 7.8 What pulls a model from production? State a numeric threshold, not a judgement call. Ambiguity in decision rights is an execution defect, and it shows up first at the moment something goes wrong. - 7.9 How is drift detected, who is funded to retrain, and on what cadence? A model that is never reviewed after deployment will degrade, and the degradation will be invisible until it is expensive. - 7.10 What check runs before an AI output informs a real decision? Specify it. Clean output is not evidence of a correct result, and the failures that matter do not announce themselves. - 7.11 What is measured to prove the gain is real, in the unit the business already reports? AI is only real if it produces measurable gains. Check where the benefit is being claimed. Modernisation cases are habitually built on run-cost reduction because it is the easiest number to defend, while the larger pool sits in decision quality applied across volume (Panda & Soller, 2026). If the case rests entirely on cost taken out, the redesign is being sold as an infrastructure project and will be measured as one. - 7.12 Which number would move the opposite way if you were quietly optimising a proxy instead of the goal? Put it on the same dashboard as the headline number. - 7.13 What is the audit trail for a decision made six months ago, and would it survive an external examination? - 7.14 What is the escalation path when the model and the human disagree, and who arbitrates? **Deltas.** This stage generates the bulk of the FMO. Sort every answer into Systems, People, Organisation, Culture before closing the stage. **Gate 7.** Passes when every redesigned decision has: a named owner, a stated human involvement model, a numeric stop threshold, a benefit measured in an existing business unit, and a viability answer that includes the architecture delta from 7.4. The redeployment ledger must balance, and every removal must carry a reversibility cost. A design the current estate cannot carry is a requirement on somebody else's roadmap, and it fails here until that roadmap is named, dated and funded. Any decision failing the viability test returns to the current mode of operations and is recorded as tested and rejected. That record has value. It stops the same idea being re-proposed every eighteen months. Reject at this gate: any play phrased as an intention. "Invest in AI" fails. "Route every AI build through a risk-tiered gate: a named business owner, an evaluation threshold the model clears before production, and a stated condition that pulls it back out" passes. **Record.** Redesigned decision table, human involvement model per decision class, viability results including rejections, governance model, ownership register, measurement set, deltas. --- ## Stage 8. Robustness **Purpose.** Find the moves that pay in every future, and establish how the plays compound. **Questions** - 8.1 Read across the scenarios rather than down them. Which moves appear in every future? These are the no-regret core, and they belong in the plan now, before any signal lands. - 8.2 For each core move, state how it pays under each future. The same move usually earns its place for different reasons, and naming both reasons is what makes it defensible to a CFO. - 8.3 **Multiplicativity.** For each scenario, state the chain: which play makes which other play possible, in order. If the plays are merely a list, they are additive and therefore weak. - 8.4 Which play, if removed, causes the others to fail? That is the load-bearing one, and it gets funded first. - 8.5 Which play could undermine another? Short-term cost reduction in one place regularly destroys a long-term position somewhere else. - 8.6 **Stop list.** What stops, and what money and capacity does that release? A plan with no stop list is a wish list. - 8.7 **Devil's advocate.** State the three strongest arguments that this entire plan is wrong. If they cannot be answered, the plan is not ready. **Gate 8.** Passes when the no-regret core has between three and seven moves, each with a stated payoff under every scenario, and when the compounding order is stated for each scenario. If every play is no-regret, nothing has been decided and the scenarios were not contrasting enough. Return to Stage 3. > Worked example. The clinical-AI playbook found five moves that pay in both futures: governed execution, clinician oversight, accountability architecture, silent-failure discipline, and a clinical validation platform. Under Frozen Trust they function as a regulatory moat. Under Full Commitment the same five function as a scaling engine. The compounding order reverses between the two futures, which is itself the finding (Rynkowski, 2026). **Record.** No-regret core with dual payoff, compounding chain per scenario, load-bearing play, conflicts, stop list, counterarguments and responses. --- ## Stage 9. Signals, breakpoints and agility **Purpose.** Make the playbook live. Pre-built plays with no trigger are shelfware. **Questions** - 9.1 For each scenario, name four to six signals that would indicate it is arriving. For each signal: the source, the named watcher, the review cadence, and the threshold that counts as movement. - 9.2 Where does the signal review sit on the calendar? The recommendation is a standing item at every executive meeting where AI is on the agenda. Signals are cheap to watch and expensive to miss. - 9.3 **Breakpoints.** What would invalidate the map itself rather than favour one scenario? A breakpoint is not a signal. It means the scenario set needs rebuilding. - 9.4 What is pre-authorised to happen when a signal crosses its threshold, without a new business case? Anything requiring a fresh approval cycle is not a pre-built play. - 9.5 **Agility diagnostic.** Score each on 1 to 5 with evidence, not opinion (Doz & Kosonen, 2008; 2010). - **Strategic sensitivity.** Does leadership surface AI possibilities and convert them into action, at executive level, on a standing cadence? - **Leadership unity.** Does stated priority translate into resource decisions below the top two layers, or does it stop at communications? - **Resource fluidity.** Is transition capacity ring-fenced, or do the same people carry existing KPIs and the AI build at once? - 9.6 Where the score is low, what move raises it? Those moves go into the playbook as plays in their own right. - 9.7 If resource fluidity is the weak lever, which capacity is ring-fenced, whose KPIs are rebalanced, and who signs that off? In most incumbents this is the binding constraint and it is structural rather than attitudinal. **Gate 9.** Passes when no signal is unowned, every signal has a threshold rather than a direction, and each agility score cites evidence. "We are quite agile" is not a score. **Record.** Signal set per scenario with owners and thresholds, breakpoints, pre-authorisations, agility scores with evidence, agility moves. --- ## Stage 10. Sequencing, assembly and assurance **Purpose.** Turn the material into two documents and one decision. **Questions** - 10.1 What happens in the first 90 days, inside existing mandates and budgets? - 10.2 What happens in twelve months, and what does it depend on? - 10.3 What is the 36-month position, stated as a capability rather than a project list? - 10.3a **Renewal pattern.** State how you get from the current mode to the future one without a single cutover. Three patterns cover most cases and the choice turns on regulatory exposure, scale, vendor position and risk appetite. Wrap the existing estate in modern interfaces and migrate capability out of it piece by piece until the old one can be retired. Or stand up a clean environment for one business line and move selected books onto it. Or keep the existing estate and decouple decisioning from it through an integration layer, simplifying the legacy underneath over time. Name the pattern, name what gets decommissioned, and name the date it stops costing money (Panda & Soller, 2026). - 10.4 What is built now, and what is pre-built and held pending a signal? Apply the same split to headcount, and state the asymmetry when you do. A capability held in reserve costs money and can be released later. A person released takes knowledge that does not come back at any price. The two do not sequence the same way and should not sit in the same column. - 10.5 **The one proposal worth sizing first.** Name the single move that deserves its own decision. State the question a sizing study must answer, what it costs, how long it takes, and what happens if the answer is no. A study whose negative result still leaves you better off is the easiest yes a sponsor will ever give. - 10.6 **Traceability.** For every change in the FMO, name the play it serves and the scenario that play answers. Anything that traces to nothing gets cut or gets a reason. **Gate 10.** Passes when the traceability matrix is complete with no orphans, the 90-day plan sits inside existing authority, and the sizing proposal has a stated cost and a stated question. --- ## Assembly: the two documents ### `playbook.md` Assemble in the order below, whatever order the interview took. ``` 1. Purpose and scope <- Stage 1 2. Tenets <- Stage 4.8, pruned at Gate 8 3. Where the market stands <- Stage 2 Part B, plus evidence gathered 4. Scenarios <- Stage 3 5. The plays <- Stages 4-7, per scenario, ending with the multiplicity chain 6. The robust core <- Stage 8 (table: move | payoff under each scenario) 7. Signals, breakpoints, agility <- Stage 9 8. Strategic synthesis <- multiplicity, common plays, signals, agility, in that order 9. The proposal worth sizing first <- Stage 10.5 10. Method and authorship Appendix A: anticipated questions, including what would falsify the playbook Appendix B: references ``` ### `fmo.md` ``` 1. Current mode of operations <- Stage 2 decision inventory, connective work, architecture ceiling 2. Design principles <- human involvement model, governance stance 3. Future mode of operations 3.1 Systems <- accumulated deltas 3.2 People 3.3 Organisation 3.4 Culture 4. Redesigned decisions <- Stage 7A table, including tested and rejected 4.1 Redeployment ledger <- Stage 7.3, released | absorbed | removed | net 4.2 Reversibility register <- Stage 7.3a, cost and time to unwind each removal 5. Governance and lifecycle <- Stage 7B 6. Measurement <- headline metrics plus the counter-metrics from 7.12 7. Transition <- Stage 10 sequencing, renewal pattern, ring-fenced capacity, KPI rebalancing 8. Traceability matrix <- FMO change | play | scenario | owner ``` ### Quality checks before release - Would the scenarios still stand with the company name removed? - Is AI visible throughout the scenarios and the plays, rather than mentioned once at the front? - Is every play specific enough for a named person to act on Monday? - Does the synthesis show common plays, signals and agility rather than restating the plays? - Does the FMO name what stops, who loses, and where the money comes from? - Does the redeployment ledger balance, and can every removal state what unwinding it would cost? - Can a reader reconstruct why any single FMO change exists? --- ## Closing assurance pass Run this before the documents are released. It is adapted from a silent-failure audit designed for AI output, and it transfers directly, because a strategy document has the same failure mode: it looks clean, it reads well, and it is wrong underneath. **Right question.** State the goal in one sentence. Is the headline benefit in Stage 7.11 causally tied to it, or merely correlated and easy to measure? Name the result that would change the decision. If no possible finding would change what happens next, the analysis is decoration. **Values that exist.** Every figure in both documents: does it come from something read, or was it filled in because the section needed a number? Mark user-supplied figures as user-supplied. A blank is not a zero. **Combined claims.** Where a benefit is attributed to two causes, verify both contribute. Benefits labelled "AI and process redesign" are frequently process redesign alone, which changes the investment case entirely. **What was filtered out.** Read the decisions rejected at Gate 7 and the plays cut at Gate 8. Is anything there that should have survived? Trace one rejection all the way back to the reason. **Why it looks clean.** Pick the finding you are most tempted to accept on faith. Verify it by hand from the source. If you cannot, say so in the document rather than implying it was checked. **Signal against noise.** Any number from a pilot, a sample or a short window is a hypothesis. Name the larger test that would confirm it before it enters the business case. **Comparability.** Every before-and-after claim: same period, same scope, same population, same definition. A pilot measured on selected cases against a baseline measured on everything is an artifact that looks perfectly clean. **Report.** Close with four short sections: assumptions made and gaps flagged rather than filled; which checks were actually run and with what evidence; what was found; what could not be verified and why. Then a verdict, and the one thing a human should personally check before acting. --- ## How this procedure fails Six failure modes, observed or anticipated. Watch for them. **One person runs it alone.** The output will be internally consistent and disconnected from what the organisation will accept. Gate 0 flags this. Stage 5 is where it becomes fatal. **Gates get waived under time pressure.** The document still gets written. It just stops being a decision tool. Waiving a gate is a decision in itself and belongs in the record. **Scenarios turn into plans.** The most common technical failure. The externality test at Gate 3 exists for this reason and should be applied twice, once at drafting and once at assembly. **The FMO detaches from the playbook.** Operating-model work has its own gravity and will pull toward a generic target operating model. The traceability matrix is the countermeasure. Orphaned changes get cut. **Everything becomes no-regret.** A symptom of scenarios that were not genuinely contrasting. Return to Stage 3 rather than proceeding. **The playbook is completed and never reviewed.** Without the standing signal review from Stage 9.2, the pre-built plays expire quietly and the organisation is back to a single-future plan, now with a document that says otherwise. --- ## Rights and provenance This procedure is original work. The stages, questions, gates and assembly formats are the author's. Where it rests on established frameworks, those are attributed to the people and the institutions that developed them: the four Ps of Purposes, Players, Partnerships and Processes from Saïd Business School's own model of strategy, the open strategy position from Whittington, the scenario approach from Ramírez and Wilkinson, the ghost scenario from Lang and Ramírez, the agility triad from Doz and Kosonen, multiplicative strategy from Powell, and the congruence model building blocks from Tushman and O'Reilly. All are published, and all are in the reference list. Frameworks are ideas and travel freely with credit. The expression here is the author's own. No third-party material is reproduced. No course material, article text, exhibit, table or figure from any source appears in this document, in whole or in part. This was verified rather than assumed: a seven-word sequence comparison was run against the full text of the sources consulted, including roughly 490,000 words of programme material across 274 files. The matches are the names of the programme and of the frameworks it credits, and the bibliographic entries in the reference list. Cited works are named so a reader can go to the originals, which is the point of a reference list. The worked examples are drawn from the author's own published playbook, cited in the references and available openly. The author completed the Oxford AI-Driven Business Transformation Executive Programme at Saïd Business School, a non-credit-bearing executive programme. This document is independent work produced after it. It is not endorsed by, affiliated with, accredited by, or published on behalf of the University of Oxford, Saïd Business School, or any other organisation named in the references. Use it freely. Any organisation that runs this procedure keeps full use of what it produces. Attribution is welcome and not required. --- ## References Doz, Y. & Kosonen, M. (2008). The dynamics of strategic agility: Nokia's rollercoaster experience. California Management Review, 50(3), pp.95-118. Doz, Y. & Kosonen, M. (2010). Embedding strategic agility: a leadership agenda for accelerating business model renewal. Long Range Planning, 43(2-3), pp.370-382. Hoque, F., Davenport, T. & Scade, P. (2026). AI transformation requires redesigning work, not cutting roles. Harvard Business Review. [online] Available at: https://hbr.org/2026/08/ai-transformation-requires-redesigning-work-not-cutting-roles [Accessed 29 August 2026]. Government Office for Science (2025). AI scenarios 2030: helping policymakers plan for the future of AI. [online] Available at: https://www.gov.uk/government/publications/ai-scenarios-2030-helping-policymakers-plan-for-the-future-of-ai [Accessed 29 August 2026]. Panda, C. & Soller, H. (2026). Core banking in the age of AI: crafting intelligent financial engines. McKinsey and Company, 27 August. Lang, T. & Ramirez, R. (2021). Getting the most from publicly available scenarios: 5 ways to avoid costly mistakes. California Management Review. [online] Available at: https://cmr.berkeley.edu/2021/04/getting-the-most-from-publicly-available-scenarios/ [Accessed 29 August 2026]. Lang, T. & Ramírez, R. (2023). How ghost scenarios haunt strategy execution. MIT Sloan Management Review, reprint 65208. Powell, T. (2017). Strategy as diligence: putting behavioral strategy into practice. California Management Review, 59(3), pp.162-190. Ramírez, R. & Wilkinson, A. (2016). Strategic reframing: the Oxford scenario planning approach. Oxford: Oxford University Press. Rynkowski, B. (2026). Winning either way: an open playbook for scaling clinical AI in medtech, 2026-2030. [online] Available at: https://bogdanrynkowski.com/files/Winning-Either-Way-Clinical-AI-Playbook.pdf [Accessed 29 August 2026]. Saïd Business School (n.d.). Oxford Executive Strategy Programme. University of Oxford. [online] Available at: https://www.sbs.ox.ac.uk/programmes/executive-education/online-learning/oxford-executive-strategy-programme [Accessed 29 August 2026]. Tushman, M.L. & O'Reilly, C.A. (1997). Winning through innovation: a practical guide to leading organizational change and renewal. Boston: Harvard Business School Press. Whittington, R. (2019). Opening strategy: professional strategists and practice change, 1960 to today. Oxford: Oxford University Press. --- ## Changelog **v1.7, 29 August 2026.** The three frameworks that carried a name but no source now carry both, and looking the sources up corrected two attributions. The four Ps are Saïd Business School's own model of strategy rather than any one academic's, and are now credited to the school. Tushman and O'Reilly did not coin the SPOC acronym; the four buckets are the building blocks of their congruence model, and the text now says that. Whittington is credited for open strategy, which is his, and Ramírez and Wilkinson for the scenario approach. Four references added, and the hedge about citing frameworks only where a reference was available is gone, because every framework named now has one. The overlap check was re-run against the edited file and the rights statement updated to match what it returns. **v1.6, 29 August 2026.** Two corrections, both found by re-running the overlap check rather than citing the earlier one. The rights statement claimed the only match was the name of the programme. The bibliographic entries match as well, which is what a reference list is for, and the statement now says so with the size of the corpus attached. The description block still carried the framing that was removed from the body at v1.4, and now names the four Ps without attributing them to a programme. **v1.1, 29 August 2026.** Six changes, all prompted by assessing Hoque, Davenport & Scade (2026) against v1.0. None touched the spine. The scenario logic, the four Ps and the traceability requirement hold. - **Stage 0.6 and Gate 0, literacy precondition.** v1.0 made the interviewer rigorous and assumed the room was qualified. It is frequently not, and a room that cannot describe AI in its own operation will still produce a confident redesign. - **Stage 1.7, the honest driver.** Cost programmes wearing AI language are common enough to be worth a scoping question. This procedure cannot fix one and should not be used to dress one. - **Stage 2.6a and Gate 2, connective work.** The decision inventory was too coarse on its own. Work that carries a decision without being one does not appear in a job description and does not survive a role-level cut, which is how organisations lose expertise they did not know they had. - **Stage 7.3, redeployment ledger.** Replaced a question about what disappears with a ledger that has to balance. Capacity released without a stated destination is not a finished design. - **Stage 7.3a and Gate 7, reversibility.** v1.0 inherited scenario planning's assumption that plays can wait and be triggered later. That holds for capital and fails for people. Reversibility is now a design criterion. - **Stage 10.4, asymmetry in sequencing.** Capability and headcount were being sequenced in the same column. They release differently and only one of them comes back. **v1.5, 29 August 2026.** Programme described as non-credit-bearing in the rights statement, and "accredited by" added to the disclaimer. The provider's student terms state that its courses are non-credit-bearing and not accredited by the collaborating institution, and that enrolment establishes only a limited relationship with it. Saying so plainly costs nothing and removes any suggestion of a claimed qualification. **v1.4, 29 August 2026.** Independence statement moved into the header block so it sits on the first screen. Reference to programme course materials removed, along with the two citations that pointed at it. SPOC now attributed directly to Tushman and O'Reilly in prose, and the viability point in 7.5 stands on general economics, which needs no source. References to the programme's own document format and section ordering replaced with neutral wording. The document names the frameworks it uses and the people who developed them, and no longer describes how any programme is organised. **v1.3, 29 August 2026.** Rights review ahead of publication. A seven-word overlap check was run against the full text of every cited source held locally, covering roughly 405,000 words of programme material plus both articles. Two body-text phrases shared wording with one source and were rewritten. Everything else that matched sat in the reference list, where matching is the intent. SPOC attribution corrected to name Tushman and O'Reilly rather than only the notes where it was read. Rights and provenance section added. **v1.2, 29 August 2026.** Five changes from assessing Panda and Soller (2026). The article works one layer below this procedure, on the technical substrate that decides whether a redesigned decision can execute at all. v1.1 covered that in a single question. - **Stage 2.6, record against decision.** Systems built to answer what happened are being asked what should happen next. Sorting the inventory this way exposes which redesigns need a different system rather than a better model. - **Stage 2.9a and 2.9b, architecture ceiling and run-versus-build spend.** The technical constraint has to surface in the baseline. Discovering it at Stage 7 means the inventory was built blind. - **Stage 7.4 and Gate 7, architecture delta.** v1.1 could pass a decision redesign that the estate cannot carry, because the viability test only caught costs somebody had already thought to calculate. The delta is now named against the 2.9a ceiling and priced inside viability. - **Stage 7.11, where the benefit is claimed.** Cases built on run-cost reduction get measured as infrastructure projects. The larger pool sits in decision quality across volume. - **Stage 10.3a, renewal pattern.** Horizons without a transition pattern invite a single cutover. Three generic patterns named, with a decommissioning date attached. Two things in the source were rejected deliberately. Its five characteristics of a target architecture are a technology checklist that will date, and this procedure stays architecture-agnostic on purpose. Its three-stage maturity model implies one path to one destination, which is the single-future thinking the scenario logic exists to prevent. **v1.0, 29 August 2026.** First version.