AI Strategy Development: The Six-to-Sixteen-Week Operator's Calendar
A CTO at a mid-cap industrial company emailed me on a Tuesday in 2024 with sixteen weeks to produce an AI strategy and a board date he could not move. The previous attempt, run through a Big-4 firm, had produced a 140-page deck in week twelve and stalled in week fourteen when the CFO refused to sign the cost projection. The CEO had given him one more cycle. He asked, reasonably, whether there was a faster way to produce a document the board would actually sign. There is. It runs on a calendar, not a methodology. We produced the document in eight weeks, the board signed it, the programme is now in its second eighteen-month roadmap cycle, and the document has been re-cut twice without losing its parent posture. The accelerator was not a framework. It was the calendar.
This page is the operator’s calendar for AI strategy development. Six weeks if someone has run a programme before, twelve to sixteen weeks if no one has. Written for the CTO or CIO who has been handed the file. It is the operational complement to the parent frameworks hub, which decides what the document contains; this page tells you how to actually produce it on time. If the calendar is the constraint and the framework choice is the question, this page is the answer.
Why most strategy development takes nine months and ships a brochure
The most common failure mode in AI strategy development is the McKinsey-shaped engagement that runs for nine months and ships a transformation roadmap-shaped artefact that the engineering leadership has not read. The mechanism is structural: consultancies are incentivised to maximise billable months; this calendar is designed to minimise them.
A consultancy engagement at this scale runs in stages: discovery (six to eight weeks), framework selection (four weeks), capability mapping (six to eight weeks), roadmap (four to six weeks), governance overlay (four weeks), board presentation (two to four weeks). Add the inter-stage reconciliation and the schedule lands at nine months. The artefact at the end is comprehensive, internally consistent, and almost always wrong on the cost ceiling because the discovery stage did not include the CFO as a first-class participant. The CFO signs reluctantly, the engineering leadership reads the executive summary, and the programme begins with a document the executors do not own.
The operator alternative inverts the sequence. The CFO is in the room in week one. The engineering leadership co-owns the document from week two. The framework is selected in week three from the vocabulary the board already speaks. The capability mapping is done against the cost ceiling, not before it. The governance overlay is written by the divisional owners, not retrofitted from a template. The board presentation is a check-in, not a reveal. Eight weeks if the team is sharp, twelve if not. The artefact at the end is shorter, less comprehensive, and survives execution because the executors helped write it.
To be clear, I am not attacking the McKinsey framework itself. The frameworks are fine. The mistake is that the engagement structure is shaped to maximise billable months rather than to ship the document the engineers will actually use. That is not a moral failing of consultancies; it is the predictable consequence of who pays the bills, the same structural point made elsewhere on this site about consulting-authored governance documents. The operator alternative is faster because the incentive structure is different.
Week zero: the four questions, on a single sheet of paper
Before week one starts, write answers to the four questions from the parent hub on one piece of paper. Posture (leader, follower, absentee, with the reasoning). Cost ceiling (a number, a year, who has signed it). Timeline pressure (a quarter, a year, three years, with the external forcing functions named). Failure tolerance (high, medium, zero, per capability category).
If you cannot fill the sheet on a single working day, stop. The bottleneck is not framework choice; it is that the organisation has not yet decided what it wants from AI. Spend the next week resolving that. The strategy document will then take eight weeks instead of sixteen, because the decisions it contains have already been made. The document is just the act of writing them down.
This is the highest-leverage step in the calendar and the one most teams skip. The single working day spent on the four questions saves four to six weeks of analysis whose purpose is to surface answers the team could have written down at the start. Goodhart’s law applies in the other direction here: the moment the analysis becomes a substitute for the decision, the analysis stops measuring what it was supposed to measure. It becomes the artefact instead of the input to the artefact.
Week one: the stakeholder map, and the CFO
Week one is one meeting and one document. The meeting is between the named owner (CTO, CIO, CAIO, programme director) and the CFO. The agenda is the cost ceiling. Not the strategy, not the framework, not the capabilities — the ceiling, in euros or dollars, with a year. The CFO will not commit to a final number in week one; that is fine. The CFO will commit to a range and a process for tightening it, which is what week one needs.
The document is the stakeholder map. Three columns: name, the decision they own, the cadence at which they will see drafts. The owners are not stakeholders; they are co-authors. The divisional heads who will own per-business-unit sub-strategies (if this is an enterprise — see the enterprise frameworks piece). The head of risk if the failure-tolerance section is non-trivial. The general counsel if the EU AI Act exposure is material. The CISO and the DPO if the governance overlay is going to be more than a paragraph. The CHRO if hiring is in scope, which it usually is in 2026 because the CAIO recruitment timeline runs ahead of the strategy.
The stakeholder map matters because the failure mode in week six — covered in the FAQ above — is divisional heads producing shadow drafts in parallel with the main document. The fix is to recruit them as co-authors in week one, not stakeholders to be informed. Co-authors do not write shadow drafts; they edit the shared draft. The discipline is to convert every stakeholder who has decision rights into an owner with a named section by the end of week one.
Week two: the inventory of existing AI work
Week two produces the first of the three required documents: a complete inventory of existing AI work in the organisation. Every active pilot, every productionised model, every signed vendor contract that includes an AI component, every shadow-IT experiment a divisional team is running on a corporate card. The inventory is harder to produce than it sounds because most enterprises have no central register; the AI work has accumulated in pockets, paid for by different budgets, with different governance regimes.
The inventory is the most useful single artefact in the entire strategy development process. It surfaces what already exists, which constrains what the strategy can plausibly add. It surfaces the divisional initiatives that the parent strategy will need to either incorporate or kill. It surfaces the vendor contracts that will need to be renegotiated when the procurement standards land in week six. And it surfaces the shadow-IT experiments that the governance section will need to either bring under control or explicitly sanction.
The inventory is also the document that most reliably embarrasses the CIO who thought they knew what was running. The shadow-IT shape of AI adoption in 2024-2026 means that almost every enterprise inventory I have produced has turned up at least three significant initiatives the central IT function did not know about. This is not a governance failure to be punished; it is signal about where the organisation actually wants to use AI. The strategy should respect the signal, not suppress it.
By the end of week two, the inventory is circulating in draft. Divisional owners are asked to validate the entries for their division. Corrections come in through week three.
Week three: posture statement, cost ceiling memo, framework selection
Week three is dense. Three outputs.
The one-page posture statement. Written by the named owner, in one paragraph per posture decision (overall posture, per major business unit if relevant), with the reasoning explicit. This is the document the board will read first; if it does not survive a non-technical board member’s Sunday-evening read, the rest of the document does not matter.
The cost-ceiling memo from the CFO. A number, a year, the funding source mix (discretionary vs. operating vs. transformative — see the root hub for the distinction), and the explicit named conditions under which the ceiling tightens. Without this memo signed by the CFO, the strategy is not engineerable; every subsequent decision is contingent on a number that has not been agreed.
The framework selection. Microsoft CAF if the organisation is on Azure. Gartner labels if the reporting line runs through analyst subscriptions. McKinsey horizons if that is the CEO’s consulting accent. The operator-built diagnostic overlaid on top of whichever vocabulary wins. The choice is made in week three and not revisited; revisiting framework choice in week eight is one of the failure modes that pushes the schedule past sixteen.
The three documents from weeks one to three — posture, inventory, cost-ceiling memo — are the gating artefacts. If they are not in place by the end of week three, the schedule has already slipped silently, because the remaining weeks will be spent rewriting earlier sections rather than building toward sign-off. The honest test is at the week-three checkpoint: do all three exist, in writing, signed by the right people? If not, stop and resolve. Do not push forward; the cost of resolving later is higher than the cost of resolving now.
Weeks four through six: capability mapping against the ceiling
Weeks four through six are the bulk of the analytical work. The capability list — what to build, what to buy, what to govern, what to discontinue — is developed against the cost ceiling and the posture, not against an abstract vision of what AI can do. The discipline is to write the cost of each capability before writing its value, not after. Cost first; value justified against cost; capability included only if the ratio survives the cost-ceiling test.
The reason for the cost-first sequence is that the cost projections are the section most likely to be optimistic. A capability whose value is written first will accumulate a cost projection that fits the value; a capability whose cost is written first will accumulate a value justification that has to survive the cost. The order matters. The optimism is asymmetric, and the antidote is to constrain the optimistic side first.
Week four also brings in the first round of vendor evaluation, against the procurement standards that will be formalised in week six. The vendor evaluation is bounded — three to five vendors per capability category, evaluated against the eight criteria from the framework comparison, with the scoring sheet published internally. The evaluation is not exhaustive; it is sufficient. An exhaustive vendor evaluation is the move that runs the schedule from sixteen weeks to nine months.
Week six is the failure-mode checkpoint. The known failure modes at this stage: divisional shadow drafts (already addressed by recruiting divisional heads as co-authors in week one); cost projections that exceed the ceiling (force the capability list to shrink, do not loosen the ceiling); framework re-litigation (refuse, the choice was made in week three); and the request to expand scope to include “transformation” or “operating model” (refuse, those live in the roadmap and are the next document). If any of these are surfacing at week six, the fix is to name them in writing at the week-six review, not to absorb them silently into the schedule.
Weeks seven and eight: governance overlay, procurement standards, board pre-read
Week seven is the governance overlay. Written by the divisional risk owners, the CISO, and the DPO. Not retrofitted from a template. The overlay binds the failure tolerance from the posture statement to the capability list — each capability gets a governance tier, with the controls required at that tier explicit. The NIST AI RMF is the right reference document; the EU AI Act high-risk obligations apply to specific capabilities and need to be named explicitly where they apply.
Week seven also formalises the procurement standards. The three contract clauses from the enterprise frameworks piece — usage caps with renegotiation triggers, data-residency that survives model-provider changes, exit terms that do not assume the vendor’s model will still exist in eighteen months — get written into the parent document as binding requirements. The procurement function will reference these for every AI vendor contract signed after sign-off; without them in the strategy, every contract becomes an ad-hoc negotiation.
Week eight is the board pre-read. The board sees a draft a week before the meeting, not on the day. Board members who have not read AI strategies before are given a one-page reading guide pointing them to the three pages that matter for non-technical readers (posture, cost ceiling, the capability list at the highest level). The board meeting itself is then a sign-off conversation rather than a reveal, which is the only board format that produces clean sign-offs on AI strategies in my experience. Reveals produce defensive sign-offs that get re-litigated mid-programme.
If the calendar runs to twelve or sixteen weeks rather than eight, the additional weeks slot between week four and week seven — more time on capability mapping, more rounds of divisional reconciliation, more vendor evaluation. The week-zero, week-one-to-three, and week-seven-to-eight structure is invariant; the middle stretches.
What ships on the day of the board meeting
The document at sign-off has three layers. The first three pages are the executive read — posture, cost ceiling, the capability list, the timeline. The next fifteen to twenty pages are the engineering read — per-capability detail, governance tiers, procurement standards, divisional sub-strategies if this is an enterprise context. The fifty-page appendix is the analytical read — vendor evaluations, cost projections with the working, the failure-mode analysis, the assumption register, the EU AI Act mapping.
The executive read survives a board member reading it on a Sunday. The engineering read survives the engineering leadership reading it in week one of execution. The analytical read is read by two people, the head of strategy and the CFO’s analyst, and it is the section that gets re-cut every six months as assumptions are tested. The three-layer structure is what makes the document hold for two to three years at the executive layer while being re-cut twice a year at the analytical layer.
The date on the document matters. So does the author’s name. A strategy with no date is read as evergreen and aged badly; a strategy with no named author is read as committee-produced and defended weakly. The dated, named, executive-summary-shaped document is the one that survives the first cut conversation in month nine. The undated, anonymous, deck-shaped document is the one that gets quietly replaced after twelve months because nobody owns the previous version.
What I would do on Monday morning
If you are starting development tomorrow with a sixteen-week deadline: spend Monday writing the four-question sheet, Tuesday meeting the CFO, Wednesday onward building the stakeholder map and recruiting co-authors. The calendar above starts on Friday. If you are already in week six and the cost projections exceed the ceiling, do not loosen the ceiling; shrink the capability list. If you are at week ten and the framework is still being re-litigated, kill the re-litigation in writing at the next checkpoint. The decisions you defer in week six are the decisions you absorb at higher cost in week fourteen.
The calendar is not the strategy. The strategy is the answers to the four questions, written down, dated, signed by the named owner. The calendar is what gets you to the document in eight weeks instead of nine months. The document is what survives the first mid-programme cut. The cuts are what makes the document worth writing.
Sources & methodology
- NIST AI Risk Management Framework, v1.0 — the governance overlay reference
- EU AI Act, Regulation (EU) 2024/1689 — high-risk obligations referenced in week seven
- Microsoft Cloud Adoption Framework — AI workloads — the most commonly chosen vocabulary in week three, with caveats
- McKinsey State of AI 2025 — the three-horizon vocabulary, in case that is the consulting accent the CEO is fluent in
- Brooks, F. (1975), “The Mythical Man-Month” — the staffing-late-in-a-late-programme reference, applies recursively to late strategy development
- Methodology: the calendar is drawn from fifteen fractional CTO and CIO strategy-development engagements 2023-2026, anonymised. The week-by-week template is published CC-BY-4.0 alongside the effective-framework scoring sheet.
If a step on the calendar runs longer or shorter than the time stated for your engagement, send the variation and I will include the data in the next refresh.
