How is a transformation framework different from a strategy framework?

The strategy framework shapes the decisions: posture, cost ceiling, timeline pressure, failure tolerance. The transformation framework shapes the execution of those decisions across time: which checkpoints, which artefacts at each checkpoint, which decisions are reserved for which milestones, and how the budget transitions from discretionary to operating. A strategy framework that does not translate into a transformation framework produces a document that is correct in October and orphaned by March. A transformation framework without a strategy framework is execution discipline applied to undecided questions.

Why six months as the checkpoint horizon rather than three or twelve?

Three months is too short for an AI capability to ship and produce evaluable evidence; the team is still in build mode and the assumptions cannot be checked. Twelve months is too long for the model market to hold steady; the underlying capability assumptions have shifted at least once. Six months is the horizon that lets a capability ship, produce evidence, and be evaluated against assumptions that were still valid when the work started. The cadence is empirical, drawn from the engagements I have run; if the model market stabilises, twelve months will become defensible again, but not in 2026.

What happens if the assumption-kill criterion fires at month three of the chunk?

The chunk ends. The team has already been told this might happen, so the news is not a betrayal. The work that was done up to month three is documented as research, the team is redeployed against the next-priority chunk, and the budget reservation for months four to six is freed up for the substitute work. The honesty about this in advance is what makes mid-flight cancellation politically affordable; without the criterion in writing, cancellation feels like failure even when it is the right operational call.

Is the executive-sponsor rotation pattern really necessary, or is it a hedge against bad sponsors?

Both, and the second more than the first. The rotation pattern — switching the executive sponsor at the eighteen-month mark by design — is a hedge against the structural problem that any executive who has championed a programme for eighteen months has prior beliefs they cannot easily revise. The fresh sponsor brings a fresh read on whether the programme deserves the next budget cycle. Most transformations that pivot into permanent consulting engagements do so under sponsors who have run out of dispassionate distance from their own programme. The rotation is the cheapest way to recover that distance.

AI Transformation Strategy Framework: The Six-Month Checkpoint Shape That Distinguishes Programmes from Engagements

Tom Prommer · CIO/CTOUpdated 2026-05-2912 min read

The transformation that survived its second checkpoint did so because the assumption-kill criterion fired exactly when it was designed to. A mid-sized industrial services firm I had been advising on a fractional basis had committed in October 2024 to an eighteen-month AI transformation programme — three phased capability streams, the standard shape — with an explicit assumption at the heart of stream two that the company’s field-services data was clean enough to train a predictive-maintenance model against without a year of remediation. The assumption was written into the roadmap. The data that would falsify it was named: a baseline accuracy threshold the model had to hit on a held-out evaluation set at month three of the stream. The decision-maker who would make the kill call was named: the divisional head of field services, not the IT team. At month three, the model hit 41% on the evaluation set against a threshold of 65%. The divisional head ended stream two on the Tuesday after the eval, signed off a six-week remediation sprint on the data, and the stream restarted in month five against a cleaner pipeline. The full programme finished four months late on the original deliverable but with a working model. The cost of the pivot, including the remediation sprint, was 19% of the stream’s original budget. The cost of running the stream to completion against bad data, which is what would have happened without the criterion, would have been the full stream budget plus a six-month operating cost on a model that did not work.

That is the transformation framework working as designed. The framework I want to lay out here is the structure that made the pivot affordable: a six-month checkpoint shape with four required artefacts and two optional ones, the assumption-kill criterion template that the divisional head referenced when she made the call, the discretionary-to-operating budget transition checklist that prevented the remediation sprint from breaking the next year’s budget, and the executive-sponsor rotation pattern that — though it did not apply in this case — distinguishes transformations that complete from transformations that pivot into permanent consulting engagements.

This is the framework piece for the transformation cluster. The parent hub covers why roadmap is its own cluster and the broad shape of the work; the transformation guide covers the operating-budget transition in detail; this piece is the structured framework that ties the two together at the level of programme design.

What a transformation framework is, and what it is not

A transformation framework is not a methodology. It is not Agile-for-AI or a re-branded SAFe stack with an LLM section bolted on. The methodology question — which sprint cadence, which ceremony shape, which estimation technique — is downstream of the framework. The framework is the shape of the programme at the level of milestones, artefacts, and decision authority. It answers the questions: what gets shipped when, what evidence is required at each shipment, who decides whether the evidence is sufficient, and what happens if the evidence is not sufficient.

The reason this is its own framework rather than a section of the strategy is that the answers shift across the life of the programme. A six-month checkpoint shape in month one looks different from the same shape in month thirteen. The artefact requirements thicken as the budget transitions from discretionary to operating. The decision authority shifts as the executive sponsor rotates. None of this fits cleanly in a strategy document, which holds for two to three years and cannot turn over its content every six months. The transformation framework is the artefact that turns over.

The distinction also matters because the consulting market has eroded it. “AI transformation strategy framework” as a phrase mostly appears in vendor copy where it means “the deck we sell you.” The substantive meaning — the structured framework for shaping a transformation programme so that it completes rather than pivots into permanent consulting — has been written about less, and that gap is what this page tries to close.

The six-month checkpoint shape

The six-month checkpoint is the load-bearing element of the framework. Every transformation programme I have run has been structured as a sequence of six-month chunks, each chunk shipping at least one capability that a real user touches, each chunk evaluable against a written assumption, and each chunk able to be terminated cleanly at the chunk boundary without breaking the chunks that follow. The chunks chain into the eighteen-month horizon that the parent hub names as the outer limit for an AI roadmap in 2026.

Each six-month chunk has four required artefacts and two optional ones. The required artefacts are what makes the chunk evaluable; without them, the checkpoint is theatre. The optional artefacts are the ones that mature the programme but are not load-bearing for the basic decision of whether to continue.

Required artefact one: the chunk thesis. A one-page document, written at the start of the chunk, stating the single load-bearing assumption the chunk depends on, the evidence that would falsify it, the threshold the evidence has to clear by month three, and the named decision-maker who will make the call at the threshold. The thesis is signed by the chunk owner and the named decision-maker before any code is written. The reason this is artefact one and not artefact four is that the thesis is what makes everything else possible. Without it, the chunk cannot be terminated cleanly because there is no agreed criterion for termination.

Required artefact two: the month-three evaluation pack. The evidence that the thesis pointed at, gathered between months one and three, presented to the named decision-maker at the start of month four. The evaluation pack is not a status report; it is a falsifiability check. The decision-maker either confirms the thesis (chunk continues), terminates the chunk (work documented, team redeployed), or extends the threshold for a defined further period (the third option is the dangerous one and should be the rarest; it is the option that lets political pressure substitute for evidence).

Required artefact three: the shipped capability. By month four to five of the chunk, at least one capability has been delivered into the hands of a real user — a customer, an operator, an internal team — and is producing evidence about whether it is being used. Not piloted, not demonstrated, not presented in a deck. Shipped. The capability does not have to be the final version; it has to be the version that produces real-world signal. Chunks that have not shipped a capability by month five are research projects; they are not transformation chunks, and the framework treats them differently.

Required artefact four: the chunk-end review. By month six, a one-page review document covering what shipped, what the real-world signal said, what the unit economics look like at observed usage, what the next chunk’s thesis should be (or whether the programme should pause), and what the team learned that the next chunk needs to know. The review is presented to the executive sponsor and the named decision-maker together. The format is rigid; the content varies; the discipline is that the review happens in writing and on time, not as a verbal update at the end of a longer meeting.

Optional artefact five: the cross-chunk retrospective. Every third chunk (so roughly every eighteen months) is followed by a retrospective that covers the patterns across the prior three chunks, the unit-economics trajectory across the full eighteen months, and the strategy refresh that the cumulative learning triggers. The retrospective is optional in the sense that the chunk can ship without it; it is not optional in the sense that a programme that never produces one is operating without institutional memory.

Optional artefact six: the external red-team. Some chunks benefit from an external review of the technical design, the evaluation methodology, or the governance posture. The red-team is most useful when the chunk is in a domain where the team’s prior experience is thin (a first customer-facing assistant, a first regulated use case, a first deployment into a market with a stricter regulator). The red-team is not a compliance gate; it is an extra falsifier that the team voluntarily subjects itself to. The chunks that include it generally produce better evidence at the month-three review.

The shape is not original to me; the chunked-delivery-with-evaluable-thesis pattern is well-established in modern programme management, going back at least to lean-startup vocabulary and the Brooksian observation that “the management question is not whether to build a pilot system and throw it away — you will do that — but whether to plan in advance to build a throwaway.” What is new is the application to AI transformation specifically, where the underlying capability assumptions shift on a six-month cadence and the framework has to absorb that shift without becoming agility theatre.

The assumption-kill criterion template

The chunk thesis from artefact one is short, but the template behind it is precise. The template has five fields. Filling all five honestly is the work; filling them with hedged language is the failure mode.

Field one: the assumption, stated as a falsifiable claim. Not “we believe data quality is sufficient for predictive maintenance.” That cannot be falsified. The falsifiable form is “the field-services dataset has labelling accuracy above 92% on the maintenance-event classification task, measured by manual review of a stratified sample of 400 events.” That can be checked. Most theses I read in initial drafts are at the first level; rewriting to the second is the most useful editorial work the framework asks for.

Field two: the evidence that would falsify the claim. Named explicitly. In the predictive-maintenance case: “the labelled accuracy measured on the sample is below 85%.” The threshold is not a guess; it is the level below which the downstream model cannot be expected to hit the production performance target. The threshold-to-production-target derivation is itself a paragraph in the appendix; the team that derives it is the team that knows the model architecture being used.

Field three: the deadline. Not a quarter or a phase; a specific date by which the evidence will be gathered. The deadline matters because evidence-gathering without a deadline expands to fill the chunk, and the chunk ends with no decision moment. Most chunks place the evidence-gathering deadline at week eight to ten, leaving the decision-maker week eleven or twelve to make the call before the chunk’s mid-point.

Field four: the named decision-maker. A person, with a job title, with budget authority over the chunk. Not a committee. Not the executive sponsor. The decision-maker is the person who can end the chunk with one sentence and have the end stick. In the predictive-maintenance case it was the divisional head of field services because she had operational responsibility for the use case the model was supposed to support. The wrong decision-maker is the chunk owner (structurally biased to continue), the executive sponsor (structurally biased toward the programme as a whole), or the AI lead (structurally biased toward the technology). The right decision-maker is usually the line owner of the function being transformed.

Field five: the action on falsification. Termination, remediation, or extension, named in advance with rough budgets attached. Termination ends the chunk; the team is redeployed; the work is documented as research. Remediation pauses the chunk for a defined sprint to address the falsified assumption (in the field-services case, the data-cleaning sprint), with a re-evaluation at the end of the sprint. Extension is the dangerous option: it pushes the threshold deadline out by a defined period without ending the chunk. Extension should be used only when the evidence pack at month three is genuinely inconclusive rather than negative; if the evidence is negative, the answer is termination or remediation.

I make the template intentionally dull. Clever templates invite creative writing; dull ones force the team to admit when they do not actually know whether the data is clean or the model behaves on edge cases. The dullness is the feature.

A useful aside on the Agile-versus-this question, since I get asked it on most engagements. Agile and SAFe optimise for velocity. This framework optimises for optionality — the ability to kill cheaply at month three. Both are real disciplines and they do not collapse into each other. A team that wants both runs the assumption-kill criterion inside the sprint structure; the kill criterion is the artefact that keeps Agile honest under AI conditions where the goalposts move faster than the sprint cadence.

The discretionary-to-operating budget transition checklist

The parent hub names the discretionary-to-operating budget transition as the single most predictable failure point in enterprise AI work. The transformation framework’s job is to make the transition deliberate rather than accidental, and it does so through a checklist that runs alongside the chunk artefacts in the second year of the programme.

Month seven: cost-engineering work begins. The chunk three through chunk four boundary is when the team starts re-architecting the cost stack of the first two chunks’ capabilities. Caching, batch inference, smaller fine-tuned models replacing prompted larger ones, the standard moves. The work is funded as a chunk in its own right, with its own thesis (the unit economics can be reduced by X% while holding capability constant).

Month nine: the operating-budget conversation begins. The CFO is briefed on which capabilities are candidates for the operating cost base, what the unit economics will be at production scale, and what the discretionary funding still covers. The briefing is not a request for sign-off; it is a heads-up that the request will arrive in three months. The early notice is what makes the eventual approval politically affordable.

Month ten: the operating-budget request lands. Specific capabilities, specific unit economics, specific multi-year operating costs, specific decommissioning of capabilities that did not earn the transition. The list of what gets cut is as important as the list of what gets continued; the CFO will trust the request more if it includes its own cuts.

Month twelve: the transition happens. Approved capabilities move into the operating cost base; rejected capabilities are decommissioned cleanly within a defined sunset window; discretionary funding shifts to the chunks still in build phase. The transition is not a single event; it is a quarter of overlap during which the funding source changes and the team learns to operate against the new constraints.

Month fifteen: the post-transition review. The team and the CFO review the first three months of operating-cost reality against the projections from month ten. Variances are documented; the next transition cycle (which begins around month eighteen for chunks five and six) is calibrated against the variances.

The checklist looks bureaucratic. The bureaucracy is what prevents the alternative, which is a budget cliff at month eighteen when discretionary funding ends and operating funding has not been approved. The cliff is the failure mode the framework is designed to prevent. Programmes that hit it lose months to scrambling for bridge funding, and the team’s trust in the transformation framework — and in the named owner — does not survive intact.

The executive sponsor at month one of an eighteen-month transformation is rarely the right sponsor at month eighteen. The reason is structural rather than personal. Sponsors who have championed a programme for eighteen months have prior beliefs about whether the programme is working that they cannot easily revise. The beliefs are not necessarily wrong; they are simply the beliefs of someone with a sunk-cost relationship to the programme’s success. The next eighteen months — chunks four through six, the transition into operating-budget reality, the decisions about scaling versus consolidating — need a sponsor with dispassionate distance.

The rotation pattern is to identify, at month nine or ten, the executive who will sponsor the second half of the programme. The handover happens at month fifteen to eighteen, with a three-to-six-month overlap during which both sponsors are informed and engaged. The original sponsor moves to an advisory role; the new sponsor takes operational authority. The new sponsor has the political distance to make the cuts that the second half of the programme requires, and the original sponsor’s continued involvement preserves the institutional knowledge that the cuts depend on.

This pattern is not universal. Programmes with strong original sponsors who have demonstrated dispassionate decision-making — including a willingness to cut chunks they had championed — do not need the rotation. The signal that the rotation is needed is when the original sponsor’s response to a negative month-three evaluation pack is to extend the threshold rather than terminate the chunk. One extension is judgement; two is pattern; three means the rotation is overdue.

The transformations that pivot into permanent consulting engagements — the failure mode this framework is built to prevent — almost all share the same shape. The original sponsor remained for the full programme. The consulting partner remained for the full programme. The chunks that should have been terminated were extended. The operating-budget transition was deferred. The transformation became a recurring engagement with no end state. The rotation pattern, more than any other element of the framework, is the structural answer to that failure mode.

What I would do on Monday morning

If you are starting a transformation programme, begin with the chunk thesis for chunk one before any other artefact. The thesis is what the rest of the framework hangs on; without it, the checkpoint shape is theatre and the assumption-kill criterion has nothing to anchor against. The thesis takes about three days to write honestly. Do not skip it.

If you have a transformation programme already running, audit the most recent chunk for the four required artefacts. If two or more are missing, the chunk is not running against the framework — it is running against an unstructured plan with chunk vocabulary. The fix is not to retrofit the artefacts after the fact; the fix is to write a clean thesis for the next chunk and structure the next six months against it. The current chunk runs to its natural end; the next one is the first one inside the framework.

If you are mid-programme and approaching the month-nine budget transition, the checklist above is overdue if you have not started it. Start it this week. The cost of starting the operating-budget conversation three months late is roughly a six-month delay in the eventual transition, because the CFO’s planning cycle does not bend to the programme’s calendar. The programme bends to the CFO’s.

If you are running a transformation under an executive sponsor who is approaching month eighteen of involvement, the rotation conversation is overdue. Identify the next sponsor. Plan the handover. Do not present the rotation as a vote of no-confidence in the current sponsor; present it as the framework’s standard pattern. Most original sponsors I have worked with appreciate the rotation when it is presented as design rather than as critique. The few who resist it are the ones whose programmes most needed it.

Sources & methodology

Microsoft Cloud Adoption Framework — AI workloads — the closest published framework to the chunked-delivery pattern, though the Microsoft framing is more vendor-shaped than the operator version on this page
NIST AI Risk Management Framework, v1.0 — the reference for the post-deployment monitoring discipline that the chunk-end review artefact draws on
Brooks, F. (1975), “The Mythical Man-Month” — the original “plan to throw one away” argument that underwrites the assumption-kill criterion
Conway, M. E. (1968), “How do committees invent?” — the law underneath why the named decision-maker is usually the line owner of the function being transformed, not the chunk owner
Methodology: the six-month checkpoint shape and the assumption-kill criterion template are published CC-BY-4.0 alongside the effective-framework scoring sheet. Drawn from approximately fifteen transformation engagements run or audited 2023–2026, anonymised; the budget-transition checklist is the median pattern, with sector-specific variations noted on the published sheet.

If you have run a transformation that succeeded or failed against a different framework shape, send the description and I will publish the comparison from the next refresh. The publicly-available transformation-framework material is thin; the operator community benefits from more of it.