Technology Strategy Lead — a six-week applied programme

Capability maps against application inventories, the system nobody owns, and why as-is is the hardest deliverable in the discipline.

• ✓
  learnRequired

  An inventory is not a capability map

  Read the brief~2 min

  Every strategy engagement starts with an as-is, and most as-is deliverables are application inventories with a diagram on top. The inventory is necessary and it answers the wrong question: it tells you what you run, not what the organisation is able to do.

  Capability, not application

  A capability is something the business does — onboard a customer, price a quote, close the month. Applications support capabilities, usually several to one and often one to several. The reason to work in capabilities is that they are stable: systems change every few years and the capability persists, so a target state expressed in capabilities survives the next vendor decision and one expressed in products does not.

  Three things a useful map has

  • A level that is consistent. Mixed granularity is the commonest defect — ‘finance’ beside ‘bank reconciliation’ on the same page, and every comparison after that is meaningless.
  • An owner per capability, named. This is the part that fails, and week three is about why.
  • A maturity or health read that somebody outside the team would recognise. Self-assessed green is worth very little; green with the evidence beside it is worth arguing about.

  As-is is the hard deliverable

  Target states are enjoyable to write and cheap to disagree with. The honest current-state map is the one that takes six weeks, upsets somebody, and does most of the work — because half the recommendations fall out of it before anyone designs anything. If your as-is took two days, you drew the org chart.

  The system nobody owns

  There is always one, usually more: inherited through an acquisition, kept alive by one person, absent from the CMDB, carrying a process nobody has documented. Finding them is not a side effect of the mapping exercise, it is one of its two main outputs, and the way you find them is by asking for a name rather than a team.

  Carry this into the drill

  The self-assessment is a structured pass over how a GRC programme is actually run. Used here as a capability baseline: the value is the questions it asks about ownership and operation, which transfer to any capability you are mapping.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 1 of 6: Where you are, and who decides — Two things have to be true before any recommendation is worth writing: an honest read of the estate you actually have, and a clear answer to who gets to choose. - Module 1.1: The estate you actually have - Today's topic: An inventory is not a capability map - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Capability, not application - Three things a useful map has - A level that is consistent. Mixed granularity is the commonest defect — ‘finance’ beside ‘bank reconciliation’ on the same page, and every comparison after that is meaningless. - An owner per capability, named. This is the part that fails, and week three is about why. - A maturity or health read that somebody outside the team would recognise. Self-assessed green is worth very little; green with the evidence beside it is worth arguing about. - As-is is the hard deliverable - The point I am meant to carry into practice: The self-assessment is a structured pass over how a GRC programme is actually run. Used here as a capability baseline: the value is the questions it asks about ownership and operation, which transfer to any capability you are mapping. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (grc-maturity): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A capability map for one domain, with the three capabilities you could not assign an owner. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  GRC Maturity Assessment

  Borrowed from the control-risk and privacy paths, where it is an enterprise GRC maturity read. It is here for its shape rather than its subject: a disciplined pass over whether a capability is owned, resourced, measured and operating — which is exactly the read a capability map needs and rarely gets.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A capability map for one domain, with the three capabilities you could not assign an owner

  Open the brief

  Map one domain as capabilities rather than applications. Keep the level consistent — if one box is a process and another is a department, split or merge until they match.

  Assign an owner to each. Name a person. Then list the three you could not assign, because those three are the most useful output of the exercise.

  What to produce

  • The domain, and why you chose it
  • Capabilities at one consistent level, twelve to twenty of them
  • Supporting applications per capability, many-to-many as it really is
  • A named owner per capability — a person, not a team
  • A health read per capability, with the evidence behind it
  • The three you could not assign an owner to

  Template · capability-map

Decision rights for technology choices: the architecture board that reviews nothing, the executive who over-rides on instinct, and the team that ships around both.

• ✓
  learnRequired

  The decision that was made by nobody

  Read the brief~2 min

  Technology decision rights are almost never written down, and everybody believes they know what they are. The gap between those two facts is where a strategy quietly dies: the paper is approved by a forum that had no authority, and eighteen months later nobody can say who agreed to it.

  Four failures, and all of them look like governance

  • The board that reviews and never refuses. Attendance, minutes, and an approval rate of one hundred per cent. It is a notification meeting wearing a governance badge.
  • The executive over-ride. Legitimate — executives are allowed to decide — and corrosive when it is undocumented, because everyone learns that the real path is the corridor.
  • The team that ships around both. Usually the rational response to a three-week approval queue and a daily release cadence, and it is a design finding rather than a discipline problem.
  • The decision made by nobody. The default that hardened into a standard because it went unchallenged for two years, and which everyone now assumes was chosen.

  The three questions that map a real decision right

  Who proposes, who decides, and who can veto. Most governance documents answer the first, imply the second and ignore the third — and the veto is the one that determines behaviour, because it is the only part with teeth. If nobody can refuse, the forum is advisory whatever the terms of reference say.

  Reconstruct from decisions, not from documents

  Take three real technology decisions from the last two years and trace who actually decided each. The map that comes out of that is nothing like the one in the governance pack, and it is the one you have to work with.

  Carry this into the drill

  The drill runs decisions that could belong to a board, a committee, management or shareholders, and counts over-reach — taking upward a decision that belonged lower down. Played here from the seat that has to route the recommendation.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 1 of 6: Where you are, and who decides — Two things have to be true before any recommendation is worth writing: an honest read of the estate you actually have, and a clear answer to who gets to choose. - Module 1.2: Who decides what - Today's topic: The decision that was made by nobody - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Four failures, and all of them look like governance - The board that reviews and never refuses. Attendance, minutes, and an approval rate of one hundred per cent. It is a notification meeting wearing a governance badge. - The executive over-ride. Legitimate — executives are allowed to decide — and corrosive when it is undocumented, because everyone learns that the real path is the corridor. - The team that ships around both. Usually the rational response to a three-week approval queue and a daily release cadence, and it is a design finding rather than a discipline problem. - The decision made by nobody. The default that hardened into a standard because it went unchallenged for two years, and which everyone now assumes was chosen. - The three questions that map a real decision right - The point I am meant to carry into practice: The drill runs decisions that could belong to a board, a committee, management or shareholders, and counts over-reach — taking upward a decision that belonged lower down. Played here from the seat that has to route the recommendation. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (whose-call): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A decision-rights map for your last three significant technology decisions. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Whose Call — a decision-rights drill

  Written for the executive path and used here from the other side of the table. The board version asks what a board should decide; the strategy version asks where to route a recommendation so it is decided by someone who can actually be held to it — same judgement, opposite chair.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A decision-rights map for your last three significant technology decisions

  Open the brief

  Take your last three significant technology decisions. For each, map who proposed, who decided, who could have vetoed, and who was consulted but had no authority.

  Then compare that to what your governance documentation says. The gap is the deliverable.

  What to produce

  • Three real decisions, named and dated
  • For each: proposer, decider, veto holder, consulted
  • What the documented process says should have happened
  • The gap, stated without blame
  • Which of the four failure patterns each gap matches
  • One change you would make to the forum that decides the next one

  Template · decision-rights
• ✓
  checkRequired

  The decision that was made by nobody

  Open the prompts

  1. Which technology decision in your organisation was made by nobody — a default that hardened into a standard?
  2. Name the forum with the highest approval rate in your governance landscape. When did it last refuse something?
  3. Where do teams route around the process, and what would the process have to look like for them not to?

Where technology choice is competitive and where it is table stakes, second-order effects, and the move that invites a response you cannot answer.

• ✓
  learnRequired

  Most technology choices are table stakes, and saying so is the valuable part

  Read the brief~2 min

  Most technology is table stakes. Saying so is unpopular in a strategy paper and it is the single most valuable classification you can make, because it decides where to spend attention rather than money.

  Three tiers, and what each deserves

  • Table stakes: everyone has it, nobody wins on it, and being below par costs you. Buy it, run it cheaply, and stop discussing it. Payroll, email, expense management.
  • Differentiating: it is visibly better than a competitor's and customers or margins notice. This is where build is defensible and where attention belongs.
  • Emerging: it might become one of the other two and nobody knows which. Small bets, short review cycles, and an explicit willingness to stop.

  The classification is a claim, and it should be evidenced

  ‘Differentiating’ is the word that gets applied to whatever the team most wants to build. The test is whether you can name what a customer would notice, or what margin would move, and whether the competitor who does not have it is visibly worse off. If the answer is that it makes internal life better, that is real value and it is not differentiation.

  Second-order effects

  Every visible move invites a response. If you build a capability that a well-resourced competitor can buy off the shelf in six months, the advantage is a six-month lead paid for with a permanent maintenance obligation. That is sometimes the right trade and it should be made knowingly, not discovered.

  Carry this into the drill

  The game is competitive strategy and second-order thinking rather than technology, and that is why it is here — the hardest part of a positioning read is anticipating the response rather than describing the move.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 1 of 6: Where you are, and who decides — Two things have to be true before any recommendation is worth writing: an honest read of the estate you actually have, and a clear answer to who gets to choose. - Module 1.3: Reading the competitive board - Today's topic: Most technology choices are table stakes, and saying so is the valuable part - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Three tiers, and what each deserves - Table stakes: everyone has it, nobody wins on it, and being below par costs you. Buy it, run it cheaply, and stop discussing it. Payroll, email, expense management. - Differentiating: it is visibly better than a competitor's and customers or margins notice. This is where build is defensible and where attention belongs. - Emerging: it might become one of the other two and nobody knows which. Small bets, short review cycles, and an explicit willingness to stop. - The classification is a claim, and it should be evidenced - Second-order effects - The point I am meant to carry into practice: The game is competitive strategy and second-order thinking rather than technology, and that is why it is here — the hardest part of a positioning read is anticipating the response rather than describing the move. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (five-moves-ahead): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A one-page positioning read for one capability. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Five Moves Ahead — a competitive-strategy war-game

  A competitive strategy and game theory piece, borrowed from the executive path. Used here for the discipline it drills: thinking past your own move to the response it invites, which is what separates a positioning read from a capability wish list.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A one-page positioning read for one capability

  Open the brief

  Take one capability and write a one-page positioning read: which tier it is in, and the evidence for that classification.

  Include the second-order question — if you invest here and it works, what does your strongest competitor do, and can you answer it?

  What to produce

  • The capability, and its tier
  • The evidence: what a customer notices, or what margin moves
  • What the tier implies for build-versus-buy and for attention
  • The competitor response if this works
  • Whether you could answer that response
  • One capability you are treating as differentiating that is not

  Template · positioning-read

Differentiating against commodity capability, the three-way frame, and total cost of ownership rather than of acquisition.

• ✓
  learnRequired

  Building the thing everyone buys, because this time it is strategic

  Read the brief~2 min

  The build-or-buy question is decided by the classification you made in week one, and it goes wrong in one direction far more often than the other: organisations build the thing everyone buys, because this time it is strategic.

  Three options, not two

  • Buy: a product, configured. Fast, bounded, and you inherit somebody else's roadmap and pricing power.
  • Build: yours, and permanently yours — which means the engineers who maintain it are part of the price, not an afterthought.
  • Borrow: a partner, a managed service, or an open-source foundation you extend. The middle option that gets left out of most papers, and frequently the right one for a capability that matters and is not differentiating.

  Why build wins arguments it should lose

  Building is more interesting, it is visible, it does not require a procurement process, and the cost that makes it expensive — the two engineers who keep it alive for the next eight years — sits in a different budget from the one the decision is made against. Every one of those is an organisational bias rather than an analytical error, which is why analysis alone does not fix it.

  The test that holds

  Would a customer notice if this were the market-standard product instead? If not, you are building a commodity, and the burden of proof should sit with build rather than with buy. That reversal of the default is most of the discipline.

  The exit belongs in the decision, not after it

  Whichever way it goes, write down what leaving would take: data in a portable form, contractual notice, switching cost, and how long the organisation could run without it. A decision with no exit is a decision made once, and it is worth knowing that at the point you make it rather than at renewal.

  Carry this into the drill

  No drill here — this module is the frame, and the two that follow put numbers under it. The decision record you write is the input to both.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 2 of 6: The case, and the number under it — Where recommendations are actually decided — and where they are most often wrong, because the analysis is careful about the wrong number. - Module 2.1: Build, buy, or borrow - Today's topic: Building the thing everyone buys, because this time it is strategic - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Three options, not two - Buy: a product, configured. Fast, bounded, and you inherit somebody else's roadmap and pricing power. - Build: yours, and permanently yours — which means the engineers who maintain it are part of the price, not an afterthought. - Borrow: a partner, a managed service, or an open-source foundation you extend. The middle option that gets left out of most papers, and frequently the right one for a capability that matters and is not differentiating. - Why build wins arguments it should lose - The test that holds - The point I am meant to carry into practice: No drill here — this module is the frame, and the two that follow put numbers under it. The decision record you write is the input to both. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - Finish by helping me plan my deliverable for this module: A build-buy-borrow decision record for one live choice, with the capability you classified as differentiating and the evidence for it. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  applyRequired

  A build-buy-borrow decision record for one live choice, with the capability you classified as differentiating and the evidence for it

  Open the brief

  Write a build-buy-borrow decision record for one live choice. All three options, even where one is obviously wrong — saying why it is wrong is part of the record.

  State the tier you assigned the capability in week one and the evidence for it, because that classification is doing most of the work in the recommendation.

  What to produce

  • The capability, its tier, and the evidence for the classification
  • Build: what it costs to make, and who maintains it afterwards
  • Buy: which products, and whose roadmap you inherit
  • Borrow: the partner or managed option, and what you keep control of
  • The recommendation, with the assumption that would reverse it
  • The exit position under the recommended option

  Template · bbb-record

Run cost, exit cost, switching cost and lock-in — and why a decision with no exit is a decision made once.

• ✓
  learnRequired

  What does this cost in year three, and who pays it

  Read the brief~2 min

  The analysis is usually careful. It is careful about the wrong number. Implementation cost is the one that is knowable at decision time, comparable across options, and owned by the person writing the paper — so it is the one that gets modelled, and the one that matters least.

  Four costs, and when each decides

  • Build — decides when the options genuinely differ there and the recurring lines are within noise of each other. It happens; it is not the common case.
  • Run — licences, consumption, and the people. Over a five-year term this dominates most technology decisions, and headcount is the part most often missing because it sits in another budget.
  • Exit — extraction charges, contractual notice, switching effort. Decides when the options are close on everything else, which is more often than it is priced.
  • Not comparable — a fixed fee against a per-transaction one with no volumes, or two quotes assuming different amounts of your own people. The honest answer is that the comparison is not ready.

  Lock-in is a price, and it is payable later

  A vendor who holds your data in their own schema and charges for extraction has not sold you a product, they have sold you a position. That may be perfectly acceptable — it is acceptable in most commodity purchases — and it should appear in the paper as a number and a date rather than as a risk bullet.

  The renewal you have no leverage in

  The moment to create leverage is at selection, not at renewal. Data portability written into the contract, a documented alternative, and a genuine internal understanding of what migration would take. Without those, the renewal conversation has one party in it.

  Carry this into the drill

  Twelve choices, each with a number that decides it. Two of them cannot be compared at all on what you are given — the counted mistake is deciding on the front number when the life cost differed.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 2 of 6: The case, and the number under it — Where recommendations are actually decided — and where they are most often wrong, because the analysis is careful about the wrong number. - Module 2.2: The number that decides it - Today's topic: What does this cost in year three, and who pays it - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Four costs, and when each decides - Build — decides when the options genuinely differ there and the recurring lines are within noise of each other. It happens; it is not the common case. - Run — licences, consumption, and the people. Over a five-year term this dominates most technology decisions, and headcount is the part most often missing because it sits in another budget. - Exit — extraction charges, contractual notice, switching effort. Decides when the options are close on everything else, which is more often than it is priced. - Not comparable — a fixed fee against a per-transaction one with no volumes, or two quotes assuming different amounts of your own people. The honest answer is that the comparison is not ready. - Lock-in is a price, and it is payable later - The point I am meant to carry into practice: Twelve choices, each with a number that decides it. Two of them cannot be compared at all on what you are given — the counted mistake is deciding on the front number when the life cost differed. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (run-the-number): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: An exit assessment for your most locked-in vendor. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Run the Number

  Built for this module. Whole-life costing is easy to agree with and hard to do under time pressure; the drill puts the two numbers side by side twelve times and counts how often you took the one at the front.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  An exit assessment for your most locked-in vendor

  Open the brief

  Take your most locked-in vendor and write the exit assessment: what leaving would cost, how long it would take, and what you would need from them that the contract does not currently oblige.

  Then the useful part — what you would have written into the original contract if you had done this before signing.

  What to produce

  • The vendor, the capability, and the contract term
  • Data: format, portability, and any extraction charge
  • Notice, and what the contract obliges them to do on exit
  • Migration effort, in people and elapsed time
  • What the organisation would do in the gap
  • The three clauses you would have negotiated at selection

  Template · exit-assessment
• ✓
  checkRequired

  The renewal you have no leverage in

  Open the prompts

  1. Which renewal is coming up where you have no leverage? What would have had to be true at selection for that not to be the case?
  2. Look at your last recommendation. Did it price five years of running the option you chose, including people?
  3. Which of your vendors could you actually leave within twelve months, and which could you not?

Benefits that need a budget holder, the case whose savings never appear in anyone's plan, and sensitivity that admits the downside.

• ✓
  learnRequired

  A case that cannot be wrong cannot be right either

  Read the brief~2 min

  A business case is a promise about money, made by someone who will not be measured on it, to people who will not check. That is not cynicism — it is the structural reason most cases cannot be tracked, and the reason a case that can be tracked is worth disproportionately more.

  The only test that matters

  Whose budget falls, by how much, and on what date? If a saving cannot be answered in those terms it is not cash, and putting it in the cash column is how a case reaches a total nobody is accountable for.

  Three columns, and the discipline of using all three

  • Cash: a named line in a named budget, with an owner who has agreed to give it up. Rare and powerful.
  • Capacity: hours released, error rates down, onboarding faster. Genuinely valuable, and it converts to cash only if somebody removes a post or declines a hire — which is a separate decision nobody has taken.
  • Enabling: this makes something else possible. Real, unquantifiable without inventing a number, and best stated plainly rather than monetised badly.

  The unfalsifiable case

  If every benefit is directional and nothing has a baseline, the case cannot be wrong — and therefore cannot be right. A 30% improvement in something nobody has measured is a number chosen because it sounded credible, and you will still be held to it when someone finds the slide in two years.

  Sensitivity that admits the downside

  Every case has a range and most present a point. Show what happens at seventy per cent of the expected benefit, and name the assumption that, if wrong, reverses the recommendation. A paper that names its own failure condition is much harder to argue with than one that does not.

  Carry this into the drill

  Twelve lines from a real-shaped business case. The counted mistake is banking a saving no budget holder had agreed to give up — the flattering error that makes a case unfalsifiable.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 2 of 6: The case, and the number under it — Where recommendations are actually decided — and where they are most often wrong, because the analysis is careful about the wrong number. - Module 2.3: The business case somebody will own - Today's topic: A case that cannot be wrong cannot be right either - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The only test that matters - Three columns, and the discipline of using all three - Cash: a named line in a named budget, with an owner who has agreed to give it up. Rare and powerful. - Capacity: hours released, error rates down, onboarding faster. Genuinely valuable, and it converts to cash only if somebody removes a post or declines a hire — which is a separate decision nobody has taken. - Enabling: this makes something else possible. Real, unquantifiable without inventing a number, and best stated plainly rather than monetised badly. - The unfalsifiable case - The point I am meant to carry into practice: Twelve lines from a real-shaped business case. The counted mistake is banking a saving no budget holder had agreed to give up — the flattering error that makes a case unfalsifiable. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (benefit-owner): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A one-page case with every benefit assigned to a named owner. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Who Banks This?

  Built for this module. Benefits frameworks are taught as categories and fail in practice at the point of assignment; the drill supplies twelve lines and asks only which column each belongs in, including the ones with no baseline to measure against.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A one-page case with every benefit assigned to a named owner

  Open the brief

  Write a one-page business case for a live initiative with every benefit assigned to a named owner and a column — cash, capacity, or enabling.

  For each cash benefit, name the budget line and the date. If you cannot, move it to capacity. That single discipline is what this exercise is for.

  What to produce

  • The initiative, in one sentence
  • Costs across the life, not just to implement
  • Cash benefits: budget line, owner, date, amount
  • Capacity benefits: the measure, the baseline, and what would convert them
  • Enabling benefits: stated, not monetised
  • The assumption that would reverse the recommendation

  Template · business-case

Capability, process, people, technology and governance — and the box with a team in it and no decision-maker.

• ✓
  learnRequired

  Can they decide, can they fund it, can they say no

  Read the brief~2 min

  Target operating models fail in a specific and predictable way: every box has a name in it, so the model looks complete, and several of those names cannot decide anything. The model is signed off, and a year later the capabilities that never had a real owner are exactly the ones that have not moved.

  The three-part test

  • Can they decide? Not advise, not recommend, not review — choose, and have the choice stand.
  • Can they fund it? An owner without budget is dependent on somebody else's priorities, which means the capability moves at the speed of a negotiation.
  • Can they say no? The veto is the part with teeth. A standards owner who cannot block a non-conforming proposal owns documentation.

  Four states, and only one of them is ownership

  Owned. Named but powerless — a council that recommends, an architect with no funding gate. Split — two capable parties, each believing the other decides, which is worse than either owning it badly. Orphaned — usually inherited through an acquisition or left behind when a programme closed.

  The programme-owned capability

  A capability owned by a programme is orphaned on a date already in the plan. It is the easiest of the four to spot and the most often missed, because the model is drawn while the programme is still running and everything looks staffed.

  Org charts are not operating models

  The model describes how a capability is run — who decides, what the standard is, where the money comes from, how exceptions are handled. The reporting line is one input to that and it is routinely mistaken for the whole answer, which is why so many target operating models are a reorganisation with new labels.

  Carry this into the drill

  Twelve capabilities, each with a name against it. The counted mistake is reading a named party as an owner when they cannot decide — which the model itself encourages, because every box has somebody in it.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 3 of 6: Target state and operating model — A target state is only as good as the accountability inside it. Three modules on owners, shared capability, and governing the thing everyone is asking for at once. - Module 3.1: A target operating model with owners in it - Today's topic: Can they decide, can they fund it, can they say no - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The three-part test - Can they decide? Not advise, not recommend, not review — choose, and have the choice stand. - Can they fund it? An owner without budget is dependent on somebody else's priorities, which means the capability moves at the speed of a negotiation. - Can they say no? The veto is the part with teeth. A standards owner who cannot block a non-conforming proposal owns documentation. - Four states, and only one of them is ownership - The programme-owned capability - The point I am meant to carry into practice: Twelve capabilities, each with a name against it. The counted mistake is reading a named party as an owner when they cannot decide — which the model itself encourages, because every box has somebody in it. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (who-owns-it): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A target operating model for one domain, with the accountability for each capability named. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Who Owns It?

  Built for this module. Ownership is the field of a target operating model that is filled in fastest and examined least; the drill applies the three-part test twelve times, including the capabilities owned by a body that can only recommend.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A target operating model for one domain, with the accountability for each capability named

  Open the brief

  Build a target operating model for one domain, with an accountable owner named for every capability — a person, and the three-part test applied to each.

  Where you cannot fill a box, leave it empty and say so. An empty box is a finding; a box filled with a committee is a problem you have hidden from yourself.

  What to produce

  • The domain and its capabilities, carried from week one
  • For each: the accountable owner, named
  • The three-part test applied — decide, fund, refuse
  • How exceptions are handled, and by whom
  • The boxes you could not fill
  • Any capability currently owned by a programme, with the date it becomes orphaned

  Template · tom
• ✓
  checkRequired

  The box you could not fill

  Open the prompts

  1. Which box could you not fill, and what would have to change organisationally for someone to be able to own it?
  2. Name a capability in your organisation owned by a body that can only recommend. What does that cost in practice?
  3. Which capabilities become orphaned when your current largest programme closes?

The centre that becomes a bottleneck, federated against centralised, and the capability that should stay in the business.

• ✓
  learnRequired

  A centre of excellence is a queue unless you say what it decides

  Read the brief~2 min

  A centre of excellence is the standard answer to a capability that several parts of the business need and none does well. It is sometimes right, and the failure mode is reliable enough to predict: it becomes a queue.

  What a centre is actually for

  Three things, and it should be explicit about which: setting a standard, providing scarce expertise, or delivering the work itself. The first two scale and the third does not — a centre that delivers becomes the constraint on everything that needs it, and the business routes around it exactly as it routes around a slow approval process.

  Federated, centralised, and the honest middle

  • Centralise where consistency is the point and volume is low. Architecture standards, contract terms, model governance.
  • Federate where speed matters and local context is real. Analytics, most product engineering, anything with a business owner who needs to move.
  • Hub and spoke where you need both: the centre sets the standard and holds the deep expertise, and the capability lives in the business. Most centres should be this and most are not, because the delivery version is easier to staff and to justify.

  The capability that should stay in the business

  If it needs domain knowledge that takes a year to acquire, centralising it moves the work away from the people who understand the problem, and the centre spends its first eighteen months learning what the business already knew. That is a real cost and it rarely appears in the case for the centre.

  Say what it decides

  The most useful sentence in any centre of excellence proposal is the one naming what the centre gets to decide and what remains the business unit's call. Without it, the centre is a queue with a mandate to advise, and everyone learns to skip it.

  Carry this into the drill

  The builder takes you through staffing and governance choices for a shared capability. Watch what happens to throughput as the centre takes on delivery rather than standards.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 3 of 6: Target state and operating model — A target state is only as good as the accountability inside it. Three modules on owners, shared capability, and governing the thing everyone is asking for at once. - Module 3.2: Centres of excellence, and when not to - Today's topic: A centre of excellence is a queue unless you say what it decides - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - What a centre is actually for - Federated, centralised, and the honest middle - Centralise where consistency is the point and volume is low. Architecture standards, contract terms, model governance. - Federate where speed matters and local context is real. Analytics, most product engineering, anything with a business owner who needs to move. - Hub and spoke where you need both: the centre sets the standard and holds the deep expertise, and the capability lives in the business. Most centres should be this and most are not, because the delivery version is easier to staff and to justify. - The capability that should stay in the business - The point I am meant to carry into practice: The builder takes you through staffing and governance choices for a shared capability. Watch what happens to throughput as the centre takes on delivery rather than standards. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (coe-builder): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A staffing and governance model for one shared capability. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Build a Business Analysis CoE

  A centre-of-excellence builder — one of two pieces in the catalogue that had never been required by any programme before this one. Native ground: it models the staffing and governance trade-off directly rather than by analogy.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A staffing and governance model for one shared capability

  Open the brief

  Design a staffing and governance model for one shared capability. State which of the three roles the centre plays — standard, expertise, delivery — and be explicit if it is more than one.

  Name what the centre decides and what the business unit decides. If you cannot draw that line, the design is not finished.

  What to produce

  • The capability, and why it is shared rather than local
  • The centre's role: standard, expertise, delivery, or a stated mix
  • What the centre decides; what the business unit decides
  • Staffing, and where the people come from
  • The throughput constraint, and what happens when it binds
  • How you would know within a year that it had become a queue

  Template · coe-model

Use-case gating, the model you cannot explain, and the difference between an AI policy and an AI decision.

• ✓
  learnRequired

  A gate that has never refused anything is not a gate

  Read the brief~2 min

  Every organisation is being asked for an AI policy and very few need one first. What they need is a gate: a route by which a use case gets looked at before it is built, by people who can say no.

  A policy is not a decision

  Policies describe the class of thing that is acceptable. Decisions are about this use case, this data, this vendor, this week — and the organisations that got into trouble had policies. The gate is where the policy meets a specific request, and it is the part that is usually missing.

  What a gate has to establish

  • What decision does this make or influence, and what happens to a person or a pound as a result. This determines everything that follows and it is one question.
  • Where the data comes from and where it goes — including what the vendor may do with it, which is a contract question rather than a technical one.
  • Who reviews the output, how they would know it was wrong, and whether they will still be looking in six months. Automation bias is the control failure and it is measurable.
  • What regulatory classification it attracts, if any. That is what the readiness assessment is for.

  A gate that has never refused anything is not a gate

  The single most useful metric about an AI governance process is its refusal rate, and the second is how many approved use cases match what was actually built. Both are cheap to collect and neither is usually collected — which means the organisation cannot tell a working gate from a rubber stamp.

  Regulation as a design constraint, not a compliance exercise

  Knowing early that a use case will land in a high-risk classification changes what you build, not just what you document. The cost of finding out late is the redesign, and it is much larger than the cost of the assessment.

  Carry this into the drill

  Two pieces here, and both are required. The first is the gate decision itself, from an AI committee's seat. The second is the regulatory readiness read that should feed into it — done before design rather than after.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 3 of 6: Target state and operating model — A target state is only as good as the accountability inside it. Three modules on owners, shared capability, and governing the thing everyone is asking for at once. - Module 3.3: Governing AI before you are asked to - Today's topic: A gate that has never refused anything is not a gate - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - A policy is not a decision - What a gate has to establish - What decision does this make or influence, and what happens to a person or a pound as a result. This determines everything that follows and it is one question. - Where the data comes from and where it goes — including what the vendor may do with it, which is a contract question rather than a technical one. - Who reviews the output, how they would know it was wrong, and whether they will still be looking in six months. Automation bias is the control failure and it is measurable. - What regulatory classification it attracts, if any. That is what the readiness assessment is for. - The point I am meant to carry into practice: Two pieces here, and both are required. The first is the gate decision itself, from an AI committee's seat. The second is the regulatory readiness read that should feed into it — done before design rather than after. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (ai-use-case-gate, eu-ai-act-readiness): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A use-case gate for your organisation, applied to two live requests. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  The Use-Case Gate — an AI governance committee sim

  Borrowed from the executive, control-risk and privacy paths, where it is an AI committee simulation. Used here from the seat that brings the use case to the gate rather than the one that sits on it — the judgement to practise is what a gate will ask.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  playRequiredTicks itself

  Are you EU AI Act-ready?

  A regulatory readiness self-assessment, and the second of the two pieces this programme rescued from being required by nothing. Used here as a design constraint: knowing the classification early changes what you build.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A use-case gate for your organisation, applied to two live requests

  Open the brief

  Design a use-case gate for your organisation: the questions, who sits on it, what it can refuse, and what evidence a requester has to bring.

  Then apply it to two live requests. If it approves both without difficulty, the gate is too loose — go back and find the question that would have made one of them harder.

  What to produce

  • The gate: questions, in the order they are asked
  • Who sits on it, and who can refuse
  • What a requester has to bring, and what happens if they cannot
  • Two live requests run through it, with the outcome for each
  • The regulatory classification each attracts
  • The two metrics you would publish: refusal rate, and build-versus-approved match

  Template · ai-gate

Dependency-led sequencing, the parallel workstreams that share one team, and why a roadmap ordered by enthusiasm fails in month four.

• ✓
  learnRequired

  Two of the blockers are people, not systems

  Read the brief~2 min

  A roadmap is a claim about order. Most are ordered by appetite — what the sponsor wants first, what the team is excited about, what looked good on the slide — and the ones that were actually blocked do not disappear. They surface in month four as slippage, and by then the reason is invisible.

  Three kinds of blocker

  • Technical: something has to be finished first. The easiest to see, the easiest to evidence, and the one people are most willing to gamble on — building against an interface mid-migration costs the work twice.
  • Decision: nothing technical is in the way and nobody has chosen. Starting anyway means you are making the choice on the board's behalf, which is how architecture ends up owning decisions the board believes it made.
  • Capacity: the same three people are on both workstreams. This is the one the plan hides, because it draws two parallel bars and one team underneath them.

  The people dependency is the one that is missed

  System dependencies are drawn; human ones are assumed away. The two engineers who know the billing API, the only person who understands the procurement rules, the architect on the cutover until March — each of those is as hard a constraint as a database migration, and none of them appears on a dependency map.

  Sequence, then negotiate

  Do the dependency pass first and honestly, then have the conversation about what to accelerate. Doing it the other way — agreeing the order and then discovering the blockers — means every constraint arrives as a surprise and reads as an excuse.

  The item that could start on Monday

  Every roadmap has three or four of these and they are rarely at the front, because nothing about them is exciting. Standard published, tooling licensed, team has it in objectives. Moving them forward is free progress and it buys credibility for the harder sequencing arguments.

  Carry this into the drill

  Twelve roadmap items and the specific thing standing in front of each. Two of the blockers are people rather than systems, which is why the plan they came from showed those items running in parallel.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 4 of 6: Sequencing and dependency — The gap between a strategy that is right and a strategy that lands: what has to happen first, where adoption actually breaks, and whether the pilot told you anything. - Module 4.1: The roadmap that survives contact - Today's topic: Two of the blockers are people, not systems - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Three kinds of blocker - Technical: something has to be finished first. The easiest to see, the easiest to evidence, and the one people are most willing to gamble on — building against an interface mid-migration costs the work twice. - Decision: nothing technical is in the way and nobody has chosen. Starting anyway means you are making the choice on the board's behalf, which is how architecture ends up owning decisions the board believes it made. - Capacity: the same three people are on both workstreams. This is the one the plan hides, because it draws two parallel bars and one team underneath them. - The people dependency is the one that is missed - Sequence, then negotiate - The point I am meant to carry into practice: Twelve roadmap items and the specific thing standing in front of each. Two of the blockers are people rather than systems, which is why the plan they came from showed those items running in parallel. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (sequence-it): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A re-sequenced roadmap with the dependency that forced each move. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Sequence It

  Built for this module, and reframed deliberately. A sequencing drill wants drag-and-drop ordering, which the engine behind every recent piece does not do; rather than open a second engine for one piece, each item asks what is actually blocking one initiative — which is the judgement, with the arranging removed.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A re-sequenced roadmap with the dependency that forced each move

  Open the brief

  Take your current roadmap and re-sequence it by dependency. For every item that moved, name the specific thing that forced the move — not ‘dependencies’, the actual system, decision or person.

  Include the capacity pass: list the people who appear under more than one workstream, and what that does to the parallel bars on the chart.

  What to produce

  • The current sequence, as published
  • Per item: the blocker, typed as technical, decision or capacity
  • The re-sequenced order
  • For each move: the specific thing that forced it
  • People appearing under more than one parallel workstream
  • The items that could start on Monday and are not at the front

  Template · roadmap
• ✓
  checkRequired

  The workstream you started first for the wrong reason

  Open the prompts

  1. Which workstream did you start first for a reason that was not dependency?
  2. Who in your organisation appears under two parallel workstreams on the current plan?
  3. Which item on your roadmap is waiting on a decision that has been outstanding more than three months?

The gap between decision and adoption, change capacity as a hard constraint, and the initiative that is technically complete and used by nobody.

• ✓
  learnRequired

  Delivered is not adopted, and only one of them is the point

  Read the brief~2 min

  The gap that matters is not between plan and delivery, it is between delivery and use. A capability that is technically complete and used by nobody has consumed the whole cost and produced none of the benefit, and it will still be reported green because the delivery milestone was met.

  Change capacity is a hard constraint

  An organisation can absorb a finite number of changes to how people work, and it is much smaller than most portfolios assume. Three transformation programmes landing in the same quarter on the same population is not three times the benefit; it is one adopted change and two that people wait out. The constraint is real, measurable in a rough way, and almost never in the portfolio model.

  Four things adoption needs, and technology is one

  • The thing works and is available. Necessary, and the only one most programmes track.
  • People know it exists and that it is for them. The distribution list three reorganisations out of date is a real and common cause of nothing happening.
  • The old way is closed, or the new way is genuinely better. If both remain open and the old one is faster for an experienced user, you have built an option nobody takes.
  • Somebody local is accountable for the change landing. Not the programme — the manager whose team has to work differently.

  Delivered-but-unused is diagnosable

  Usage data exists for almost everything and is rarely looked at after go-live. Pull it for the last three things your organisation delivered, and the pattern will tell you more about where execution breaks than any retrospective.

  Carry this into the drill

  The game is about the distance between a decision and its effect, and where that distance is created. Played here for the adoption half rather than the strategy half.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 4 of 6: Sequencing and dependency — The gap between a strategy that is right and a strategy that lands: what has to happen first, where adoption actually breaks, and whether the pilot told you anything. - Module 4.2: Where execution actually breaks - Today's topic: Delivered is not adopted, and only one of them is the point - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Change capacity is a hard constraint - Four things adoption needs, and technology is one - The thing works and is available. Necessary, and the only one most programmes track. - People know it exists and that it is for them. The distribution list three reorganisations out of date is a real and common cause of nothing happening. - The old way is closed, or the new way is genuinely better. If both remain open and the old one is faster for an experienced user, you have built an option nobody takes. - Somebody local is accountable for the change landing. Not the programme — the manager whose team has to work differently. - The point I am meant to carry into practice: The game is about the distance between a decision and its effect, and where that distance is created. Played here for the adoption half rather than the strategy half. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (mind-the-gap): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: An adoption plan for one delivered-but-unused capability. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  Mind the Gap — a transformation-sequencing game

  A strategy execution and change piece from the executive path. Used here because the gap it models — between what was decided and what actually changed — is the same gap a technology roadmap falls into, and the mechanisms are identical.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  An adoption plan for one delivered-but-unused capability

  Open the brief

  Find one capability your organisation delivered in the last two years that is not being used, and write the adoption plan that would fix it — or the honest recommendation to retire it.

  Start with the usage data. If none is collected, that is the first finding and the first action.

  What to produce

  • The capability, its cost, and its current usage
  • Which of the four adoption conditions failed
  • Whether the old way is still open, and what it would take to close it
  • The local accountable owner — named, or the fact that there is none
  • The plan, or the case for retiring it
  • What you would measure in ninety days to know it worked

  Template · adoption-plan

Success criteria set before the pilot, the pilot that succeeds because it was staffed by volunteers, and scale conditions written in advance.

• ✓
  learnRequired

  Ask what the rollout will not have

  Read the brief~2 min

  A pilot measures its conditions at least as much as it measures the thing being piloted. That is not a flaw to be minimised, it is the nature of the exercise — and the discipline is naming, in advance, which conditions the rollout will not reproduce.

  The volunteer effect

  Pilots staffed by teams who asked to be in them measure enthusiasm, which is the single variable adoption depends on most and the one that varies most across an organisation. Ninety-four per cent adoption among volunteers predicts almost nothing about the teams who did not put their hands up, and it is the number that gets quoted in the rollout case.

  Three conditions a rollout will not have

  • The population. Volunteers, the most experienced users, one unusually well-run department, suppliers who agreed to participate. Each of these selects on exactly the variable you are trying to measure.
  • The support. A vendor engineer embedded for six weeks, a project team on hand, a human silently correcting every output. If it will not exist at scale it should not exist in the pilot, or the result has to be discounted for it.
  • The attention. A director reviewing usage weekly is a control, and it is the control doing the work. It disappears the week the pilot ends.

  Criteria before, or it did not happen

  ‘It went well and people liked it’ is the commonest pilot outcome and it is not a result. Write the measure, the baseline and the threshold before starting — and write what would make you stop, because a pilot that cannot fail is a rollout with a rehearsal in front of it.

  Design for the boring case

  The most informative pilot is a randomly selected, ordinarily supported, representative slice with a pre-agreed measure. It is less exciting, harder to staff, and it is the only kind whose result you can spend money on.

  Carry this into the drill

  Twelve pilots that succeeded. Three were designed to be believed and the rest succeeded because of who was in them or who was helping — the counted mistake is reading a result as transferable when its conditions were not.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 4 of 6: Sequencing and dependency — The gap between a strategy that is right and a strategy that lands: what has to happen first, where adoption actually breaks, and whether the pilot told you anything. - Module 4.3: Pilots that can leave the lab - Today's topic: Ask what the rollout will not have - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - The volunteer effect - Three conditions a rollout will not have - The population. Volunteers, the most experienced users, one unusually well-run department, suppliers who agreed to participate. Each of these selects on exactly the variable you are trying to measure. - The support. A vendor engineer embedded for six weeks, a project team on hand, a human silently correcting every output. If it will not exist at scale it should not exist in the pilot, or the result has to be discounted for it. - The attention. A director reviewing usage weekly is a control, and it is the control doing the work. It disappears the week the pilot ends. - Criteria before, or it did not happen - The point I am meant to carry into practice: Twelve pilots that succeeded. Three were designed to be believed and the rest succeeded because of who was in them or who was helping — the counted mistake is reading a result as transferable when its conditions were not. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (the-pilot-trap): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A pilot design with its scale conditions stated up front. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  The Pilot Trap

  Built for this module. Pilot design is normally taught as a checklist and fails at the point of interpreting a result; the drill supplies twelve successful pilots and asks the one question that matters, which is what the rollout will not have.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A pilot design with its scale conditions stated up front

  Open the brief

  Design a pilot for something your organisation is considering. State the population and how it is selected, the support model and whether it matches rollout, and the success criteria with their baseline.

  Then write the scale conditions: what has to be true for this result to transfer, and what would make you stop.

  What to produce

  • What is being piloted, and the decision it informs
  • Population: how selected, and why that is representative
  • Support model, and whether the rollout would reproduce it
  • Success criteria, with baseline and threshold, written before
  • The stop condition
  • Scale conditions: what must hold for the result to transfer

  Template · pilot-design

Selection beyond the scorecard, concentration, and the vendor whose roadmap is now your roadmap.

• ✓
  learnRequired

  Concentration is a strategy decision, not a procurement one

  Read the brief~2 min

  Vendor selection is run as a scoring exercise and decided by the things the scorecard cannot hold: whether their roadmap points where yours does, whether they will still exist, and what happens to you if either answer changes.

  What a scorecard cannot see

  • Roadmap alignment. You are buying their next five years of priorities, not the demo. If the capability you need is on their roadmap rather than in the product, you are buying a promise.
  • Concentration. Four capabilities from one vendor is a commercial position and a single point of failure, and it is nobody's job to notice because each purchase was individually sensible.
  • Viability. Eleven staff and two of your competitors as customers is a real risk and it is not a reason to refuse — it is a reason to price the migration you might have to do.
  • Power. What leverage do you have at renewal, and what did you do at selection to create it?

  Their roadmap becomes your roadmap

  When a vendor deprecates a feature, changes a pricing model or is acquired, your plan changes and you were not consulted. That is the actual meaning of a strategic vendor relationship, and it argues for knowing which of your capabilities are exposed to which vendor's decisions — which is a map most organisations do not have.

  Concentration is a strategy decision

  Single-vendor estates are cheaper, more integrated and easier to run, and they hand the pricing power over completely. Multi-vendor estates cost more to operate and preserve leverage. Both are defensible; the failure is arriving at either by accumulation rather than by choosing.

  Carry this into the drill

  The self-assessment is a structured pass over third-party risk. Read it here commercially rather than as compliance — the questions about concentration and exit are the same ones a strategy function should be asking.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 5 of 6: Delivery risk, vendors and the estate — Three places a good strategy is undone by someone else's constraints: the vendors you chose, the estate you inherited, and the cutover you cannot pause. - Module 5.1: Choosing and holding a vendor - Today's topic: Concentration is a strategy decision, not a procurement one - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - What a scorecard cannot see - Roadmap alignment. You are buying their next five years of priorities, not the demo. If the capability you need is on their roadmap rather than in the product, you are buying a promise. - Concentration. Four capabilities from one vendor is a commercial position and a single point of failure, and it is nobody's job to notice because each purchase was individually sensible. - Viability. Eleven staff and two of your competitors as customers is a real risk and it is not a reason to refuse — it is a reason to price the migration you might have to do. - Power. What leverage do you have at renewal, and what did you do at selection to create it? - Their roadmap becomes your roadmap - The point I am meant to carry into practice: The self-assessment is a structured pass over third-party risk. Read it here commercially rather than as compliance — the questions about concentration and exit are the same ones a strategy function should be asking. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (third-party-risk): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A concentration assessment across your top five vendors. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  How ready is your data privacy function?

  A GRC third-party risk self-assessment, borrowed from three other paths. Used here for the commercial read rather than the compliance one: concentration, substitutability and exit are strategy questions that happen to be asked best by a risk instrument.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A concentration assessment across your top five vendors

  Open the brief

  Map your top five technology vendors against the capabilities they support. Look for concentration — one vendor under several capabilities, or several capabilities with no alternative.

  For the most concentrated, state what you would do if they doubled the price at renewal. That answer is your actual negotiating position.

  What to produce

  • Top five vendors, with annual spend and contract end dates
  • Capabilities each supports, and which are business-critical
  • Concentration: any vendor under three or more capabilities
  • Substitutability per capability, honestly assessed
  • The renewal position for the most concentrated relationship
  • One action to create leverage before that renewal

  Template · vendor-concentration

Technology due diligence in an acquisition: integration cost, technical debt priced as synergy, and the platform that does not survive the merger.

• ✓
  learnRequired

  Three questions that would change the price

  Read the brief~2 min

  Technology due diligence in an acquisition is run under time pressure with incomplete access, and it has one job: find the three things that would change the price or the plan. Everything else is detail that can wait until after completion.

  Where the money actually is

  • Integration cost. Almost always understated, because it is estimated by people who have not seen the target's estate and it is politically inconvenient during a deal.
  • Technical debt priced as synergy. ‘We will consolidate onto our platform’ assumes a migration nobody has scoped, and the synergy number is usually the migration cost with its sign reversed.
  • Key person dependency. If three engineers hold the working knowledge of the core platform and none of them has retention, that is a valuation issue rather than an HR one.
  • Licence and contract change-of-control. Terms that reprice or terminate on acquisition, which is a real and frequently missed line.

  The platform that does not survive the merger

  Ask early which of the target's systems you intend to keep. If the answer is none, then the acquisition is people and customers, the technology is a cost to be migrated, and the diligence should be about how hard that migration is rather than how good the platform is.

  Three questions that would change the price

  That is the deliverable. Not a hundred-page assessment — three questions, each with the number attached, that a deal team can act on. Everything you find that does not change the price or the integration plan belongs in a post-completion list.

  Carry this into the drill

  The game is an M&A diligence dossier under time pressure. What transfers is triage: which questions to ask first when you cannot ask all of them.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 5 of 6: Delivery risk, vendors and the estate — Three places a good strategy is undone by someone else's constraints: the vendors you chose, the estate you inherited, and the cutover you cannot pause. - Module 5.2: Diligence on somebody else's estate - Today's topic: Three questions that would change the price - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Where the money actually is - Integration cost. Almost always understated, because it is estimated by people who have not seen the target's estate and it is politically inconvenient during a deal. - Technical debt priced as synergy. ‘We will consolidate onto our platform’ assumes a migration nobody has scoped, and the synergy number is usually the migration cost with its sign reversed. - Key person dependency. If three engineers hold the working knowledge of the core platform and none of them has retention, that is a valuation issue rather than an HR one. - Licence and contract change-of-control. Terms that reprice or terminate on acquisition, which is a real and frequently missed line. - The platform that does not survive the merger - The point I am meant to carry into practice: The game is an M&A diligence dossier under time pressure. What transfers is triage: which questions to ask first when you cannot ask all of them. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (acquisition-dossier): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A technology diligence checklist with the three questions that would change the price. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  The Acquisition Dossier — 7-day M&A diligence sim

  Borrowed from the executive and privacy paths, where it is read as corporate and data diligence. Here it is technology diligence, and the discipline is the same: limited access, limited time, and finding the small number of facts that move the number.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A technology diligence checklist with the three questions that would change the price

  Open the brief

  Write a technology diligence checklist for an acquisition in your sector, ordered by what would change the price rather than by domain.

  End with the three questions you would ask first if you had one day and one meeting.

  What to produce

  • The deal shape, and what is actually being bought
  • Which target systems you would expect to keep
  • Integration cost drivers, in order of size
  • Change-of-control terms to check, and where they live
  • Key person dependency, and how you would test for it
  • The three questions that would change the price

  Template · diligence-checklist

Go/no-go criteria, contingency, and the migration that has no way back.

• ✓
  learnRequired

  Ask on day one what happens if this goes wrong on day three

  Read the brief~2 min

  Cutover is the moment a strategy becomes irreversible, and it is planned by people who are exhausted, on a date chosen for commercial reasons, with a rollback plan nobody has tested.

  Go/no-go criteria have to exist before they are needed

  Written in advance, measurable, and agreed by someone with authority to hold the line. Criteria written the week before go live are negotiated rather than assessed, because by then the cost of stopping is visible and the cost of going is not.

  The waiver is the control

  Every cutover has criteria that are not met. What matters is whether the waiver is explicit, who signed it, and whether they had the authority — an unrecorded waiver by someone improvising under pressure is the most common single cause of a bad cutover being unexaminable afterwards.

  Data migration, again

  • Record counts and control totals reconciled before and after, by someone independent of the migration team.
  • The treatment of records that failed to migrate — there always are some, and ‘we will fix them later’ is a decision that needs an owner.
  • A named person signing that the result is complete, not just that the job ran.

  Ask on day one what happens on day three

  If the legacy system is decommissioned at go-live, there is no rollback, and everyone should know that months in advance rather than discovering it in the war room. A programme with no way back is a legitimate choice and it changes what contingency has to look like — usually a great deal more parallel running than the plan allows.

  Carry this into the drill

  The simulation runs an ERP cutover with its decisions in sequence. Played here from the delivery seat — the audit path plays the same piece from the assurance one.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 5 of 6: Delivery risk, vendors and the estate — Three places a good strategy is undone by someone else's constraints: the vendors you chose, the estate you inherited, and the cutover you cannot pause. - Module 5.3: The cutover you cannot pause - Today's topic: Ask on day one what happens if this goes wrong on day three - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Go/no-go criteria have to exist before they are needed - The waiver is the control - Data migration, again - Record counts and control totals reconciled before and after, by someone independent of the migration team. - The treatment of records that failed to migrate — there always are some, and ‘we will fix them later’ is a decision that needs an owner. - A named person signing that the result is complete, not just that the job ran. - The point I am meant to carry into practice: The simulation runs an ERP cutover with its decisions in sequence. Played here from the delivery seat — the audit path plays the same piece from the assurance one. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (s4hana-cutover): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A go/no-go framework for one live programme. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playRequiredTicks itself

  S/4HANA Cutover Sim

  Shared with the Internal Audit Lead path, and read from the opposite chair. There the question is what you would want evidenced before each decision; here it is what you would decide, with the same information and less time.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A go/no-go framework for one live programme

  Open the brief

  Write a go/no-go framework for one live programme: criteria, measurable, with thresholds agreed before the date approaches.

  Include the waiver process — who can grant one, and what gets recorded. And answer the day-three question explicitly.

  What to produce

  • The programme, its go-live date and its go/no-go date
  • Criteria, each measurable, with a threshold
  • Who decides, and who can hold the line
  • The waiver process: who signs, and what is recorded
  • Data migration checks, and who signs completeness
  • What happens if it goes wrong on day three

  Template · gonogo

Writing the option you rejected, the deck that hides its own assumption, and what a sceptical CFO asks second.

• ✓
  learnRequired

  Lead with the assumption that would reverse it

  Read the brief~2 min

  The paper is the product. Six weeks of analysis reach the organisation as a document read in fifteen minutes by people who will decide on it, and most of what separates a good recommendation from an ignored one happens in how it is written.

  Write the option you rejected

  A paper presenting one option is a request for approval; a paper presenting three with a reasoned choice is a recommendation. The rejected options are what demonstrate the thinking, and they are also what stops the room re-litigating them — the question ‘did you consider buying it?’ is answered on the page rather than in the meeting.

  Lead with the assumption that would reverse it

  Every recommendation rests on something that could be wrong. Naming it in the first half page does two things: it makes the paper much harder to attack, because the strongest objection is already acknowledged, and it gives the organisation a trigger to revisit the decision rather than discovering in two years that the ground moved.

  What a sceptical CFO asks second

  • First: what does it cost. Everyone prepares for this one.
  • Second: what does it cost to run, and whose budget does that land in. Week two exists for this question.
  • Third: what happens if we do nothing. A real option, and a paper that has not costed it looks like advocacy.
  • Fourth: who is accountable for the benefits. If the answer is the programme, the benefits will leave with it.

  The deck that hides its own assumption

  Charts with no baseline, ranges presented as points, five-year projections with a growth rate nobody sourced. These are not usually dishonest, they are the residue of a process where the assumption was made early and stopped being visible. Reading your own deck for its hidden assumptions is a worthwhile hour before it goes anywhere.

  Carry this into the drill

  No drill here — this module is writing, and the deliverable is the paper. The two rejected options and the reversal trigger are the parts that make it a recommendation rather than a request.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 6 of 6: Recommending it, and being held to it — The work only counts if somebody acts on it. Writing the recommendation, choosing what you will be measured on, and defending both. - Module 6.1: The recommendation that survives the room - Today's topic: Lead with the assumption that would reverse it - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Write the option you rejected - Lead with the assumption that would reverse it - What a sceptical CFO asks second - First: what does it cost. Everyone prepares for this one. - Second: what does it cost to run, and whose budget does that land in. Week two exists for this question. - Third: what happens if we do nothing. A real option, and a paper that has not costed it looks like advocacy. - The point I am meant to carry into practice: No drill here — this module is writing, and the deliverable is the paper. The two rejected options and the reversal trigger are the parts that make it a recommendation rather than a request. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - Finish by helping me plan my deliverable for this module: A recommendation paper with two rejected options and the trigger that would reverse it. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  applyRequired

  A recommendation paper with two rejected options and the trigger that would reverse it

  Open the brief

  Write a recommendation paper for a live decision: the recommended option, two rejected ones with the reason for each, and the assumption that would reverse the recommendation.

  Two pages. If it needs more, the analysis goes in an appendix and the paper stays two pages.

  What to produce

  • The decision, and who is being asked to take it
  • The recommendation, in the first paragraph
  • The assumption that would reverse it, named early
  • Two rejected options, with the reason for each
  • Whole-life cost, including run and who pays it
  • Do-nothing, costed
  • Who is accountable for the benefits, by name

  Template · recommendation

Leading and lagging measures for a strategy, and the metric that goes green while the outcome does not.

• ✓
  learnRequired

  Name the metric you expect to be gamed

  Read the brief~2 min

  The measures chosen at the start of an initiative decide what it becomes. That is not a warning about gaming, it is a description of how organisations work: people optimise what is reported, and if the reported thing is a proxy, the proxy is what improves.

  Leading and lagging, and why you need both

  Lagging measures are the outcome you wanted and they arrive too late to steer with. Leading measures move early and are proxies, which means they can move without the outcome moving. A measurement set with only lagging measures cannot be managed; one with only leading measures cannot be trusted.

  Name the metric you expect to be gamed

  • Usage counts. Optimised by making something mandatory rather than useful.
  • Ticket closure time. Optimised by closing tickets.
  • Adoption percentage. Optimised by narrowing the denominator.
  • Migration completion. Optimised by declaring the difficult ten per cent out of scope.

  The metric that goes green while the outcome does not

  This is the failure worth designing against, and the defence is a paired measure: alongside every leading indicator, one measure that would move in the wrong direction if the indicator were being gamed. Closure time paired with reopen rate. Adoption paired with the denominator. It costs nothing and it makes the report readable.

  Say in advance what would make you stop

  Initiatives are almost never stopped, and the reason is that nobody wrote down what stopping would look like. A stop condition agreed at the start is much easier to invoke than a judgement made at month nine against sunk cost and personal investment.

  Carry this into the drill

  The optional drill is a general risk-rating piece, useful here for the calibration habit: measurement sets drift the same way risk ratings do, one reasonable adjustment at a time.

  Go deeper — with your own AICopy-paste prompt

  The brief above is the spine. This is a full study prompt for whichever assistant you already use — it carries your programme, this module and what the brief just covered, so the lesson comes back tailored rather than generic. Pick how you want it, edit anything, then copy.

  WrittenInfographicBoth

  You are an experienced control-risk practitioner and an exceptional teacher. Teach me one topic properly — the way a senior colleague would over a long coffee, not the way a textbook would. MY CONTEXT - Programme: Technology Strategy Lead — a six-week applied programme (6 weeks, ~10h a week, self-paced). - Level: People who recommend technology decisions and have to live with them: internal strategy and architecture functions, transformation and portfolio leads, and anyone who writes the paper somebody else will run for five years. - Week 6 of 6: Recommending it, and being held to it — The work only counts if somebody acts on it. Writing the recommendation, choosing what you will be measured on, and defending both. - Module 6.2: What you will be measured on - Today's topic: Name the metric you expect to be gamed - I am studying alone, applying this to my own organisation, and nothing I produce is graded. Assume I am a working professional, not a student: skip the motivational framing and the history lesson unless the history changes what I should do. WHAT I ALREADY HAVE (do not simply repeat this — go past it) - Leading and lagging, and why you need both - Name the metric you expect to be gamed - Usage counts. Optimised by making something mandatory rather than useful. - Ticket closure time. Optimised by closing tickets. - Adoption percentage. Optimised by narrowing the denominator. - Migration completion. Optimised by declaring the difficult ten per cent out of scope. - The point I am meant to carry into practice: The optional drill is a general risk-rating piece, useful here for the calibration habit: measurement sets drift the same way risk ratings do, one reasonable adjustment at a time. WHAT I WANT FROM YOU 1. The core idea in five sentences, in plain language, including the one distinction practitioners most often get wrong here. 2. Why it matters in practice: what actually goes wrong when this is done badly, with two realistic short scenarios — one financial services, one outside it. 3. The mechanics, step by step, at the level of detail I could follow at my desk tomorrow. Show the judgement calls, not just the procedure, and say what a good answer looks like versus a defensible-but-weak one. 4. At least one fully worked example with realistic specifics — names, numbers, evidence, dates. Show your reasoning as you go, including where you would push back on your own conclusion. 5. The five most common mistakes, each with the tell that gives it away and the correction. 6. How this connects to the rest of control risk: what it depends on upstream and what breaks downstream if I get it wrong. 7. What competent practitioners genuinely disagree about here, and how I should decide for my own context. 8. A short glossary of any term you use that a regulator, an auditor and a business owner would each define differently. 9. Six self-test questions that require judgement rather than recall — hold the answers back until I have attempted them, then mark my reasoning, not just my conclusion. OUTPUT FORMAT: written explanation. Long-form prose with headed sections, worked examples and tables where a table genuinely helps. No images. HOW TO WORK WITH ME - Ask me up to three questions about my sector, my organisation's size and my current maturity BEFORE you start, then tailor everything to my answers. - Prefer concrete specifics over hedged generalities. If something depends on context, say which context and why. - Flag anything that is genuinely contested, jurisdiction-specific or changing, and tell me what would make you change your answer. - If I have got something wrong in what I said I already know, correct me directly. - Do not invent standards, clause numbers, statistics or citations. If you are unsure of a reference, say so plainly instead. - After the lesson, quiz me the way this module's drill would (calibrate-risk): give me a situation, make me decide, then challenge the decision I make. - Finish by helping me plan my deliverable for this module: A measurement set for one initiative, with the metric you expect to be gamed. Ask what my process is, then outline what mine should contain and what would make it weak.

  Copy promptYours to edit — changes stay in this box

• ✓
  playOptionalTicks itself

  Which Is Riskier? — a calibration drill

  Optional, and borrowed. A general risk-calibration drill rather than a measurement one; it earns a place here because the failure it models — competent people scoring the same thing differently without noticing — is exactly what happens to a measurement set over a year.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  A measurement set for one initiative, with the metric you expect to be gamed

  Open the brief

  Design the measurement set for one initiative: leading and lagging measures, with a baseline for each.

  For every leading measure, add the paired measure that would expose gaming. And write the stop condition.

  What to produce

  • The initiative and the outcome it is for
  • Lagging measures, with baselines and the date they become readable
  • Leading measures, with baselines
  • For each leading measure: the paired measure that exposes gaming
  • The metric you expect to be gamed, named
  • The stop condition, agreed now

  Template · measures

Six weeks of decisions brought into one contested session.

• ✓
  playRequiredTicks itself

  Road to the Final — a knockout tournament

  A multi-domain knockout tournament, and the capstone Play step. Two of the six programmes carry no Play step at their capstone; this one does deliberately, because the tournament is the only piece in the catalogue that makes you move between domains under pressure — which is what the final session of this programme is about.

  Open the drill

  Ticks itself when the drill records a result

• ✓
  applyRequired

  Capstone: a strategy-on-a-page for your own domain

  Open the brief

  Bring the six weeks together into a strategy-on-a-page for your own domain: where you are, where you are going, what you decided, and what would change your mind.

  One page. Everything you built — the capability map, the decision-rights map, the whole-life costing, the operating model, the sequenced roadmap — exists to make that one page defensible.

  What to produce

  • Current state, in three lines, with the honest weakness named
  • Target state, expressed in capabilities rather than products
  • The three decisions that get you there, each with its owner
  • The sequence, and the dependency that set it
  • What it costs across its life, and whose budget it lands in
  • The assumption that would change the whole page

  Template · capstone
• ✓
  checkRequired

  Sign-off against the six-week outcomes

  Open the prompts

  1. Against the seven outcomes for this programme, which two have changed how you actually work, and which two did you agree with and change nothing for?
  2. What is the one recommendation you have made in the past that you would now write differently, and what specifically would change?
  3. If your CFO read your strategy-on-a-page and asked what it costs to run in year three, could you answer without going away?