Ninety days is long enough to prove an enterprise AI initiative can create value and short enough that the organisation has not yet lost interest. It is also the window in which most initiatives quietly decide their fate — not at a launch event, but in a series of small, unglamorous choices about ownership, data, gates, and the work that happens after the model ships. The blueprint that follows is the structure I use to make those choices deliberately rather than by default.

The core idea is simple and unfashionable: front-load the hard part. The technology questions in AI — which model, which framework, which infrastructure — are now the easy part. They are commodified and well-documented. The hard part is everything around them: defining the outcome sharply enough to fail, getting the data into the form the model needs, naming an owner who is accountable for the result, gating the work so it can be stopped, and doing the embed work that turns a model into a capability the organisation actually owns. A 90-day plan that spends its first weeks on model selection has already mis-prioritised. A plan that spends them on the constraint is set up to land.

The phases are not just delivery milestones. Each gate is also an off-ramp — and the team that designed the gates must also have the authority to pull them.

— Phase one

Days 1–21 · Diagnose.

The first three weeks produce no model and no code, and this is the single most counter-intuitive thing about the plan. They produce a sharper problem. The deliverable of Diagnose is a one-page constraint document, written collaboratively and signed by the executive sponsor and operating owner: the single business outcome, its measurable baseline today, the target at 90 days and beyond, the constraints that cannot change, the named owner, and the go/no-go criterion for the end of this phase.

The exercise of writing it is most of the value. Half the time, the act of trying to state the outcome surfaces that the leadership team does not actually agree on what they are trying to change — and that disagreement, surfaced in week two, costs only time. Surfaced in month seven, it costs a quarter of wrong-built engineering. Alongside the constraint document, Diagnose runs a fast data audit: an inventory of the data the use case actually requires, a quality and labelling assessment, and an honest estimate of cleanup work as a share of total effort. That estimate, not optimism, sets the rest of the plan.

Gate 1
End of day 21 · continue or stop?
Did Diagnose produce a sharper, signed constraint than we had at the start, and a data picture we can build on? If yes, continue. If no, stop — the cheapest possible place to stop, with the least sunk.
— Phase two

Days 22–45 · Design.

Design turns the constraint into a buildable solution. This is where model and architecture choices are finally made — quickly, because by now the problem is sharp enough that the choices are mostly obvious. The harder work of Design is organisational. The eventual users of the AI output are brought in as co-designers, not as user-research subjects, because the interaction shape they help create is what produces adoption later. In domains where senior professionals have correctly trained themselves never to defer to a tool they cannot reason about, the fix for adoption is almost never a better model — it is an interaction in which the human retains authority and the AI surfaces context. That is a Design decision, and getting it wrong here is unrecoverable later.

Design also produces the ROI envelope and the gated build plan: what gets built, in what order, with which dependencies, and at which points the work can be reviewed and stopped. The output is concrete enough that the named owner can look at it and commit to operating the result.

Gate 2
End of day 45 · is the owner willing to commit?
Did Design produce a buildable solution the eventual owner will commit to operating, with users bought in and an ROI basis the board accepts? If yes, build. If no, stop or re-scope.

A plan that spends its first weeks choosing a model has already mis-prioritised. The first weeks belong to the constraint.

— Phase three

Days 46–75 · Build.

Now the model gets built — and it is, deliberately, the phase the plan treats as roughly 20% of what determines whether the initiative lands. The build is real work and it is well-understood work. What the plan guards against here is the failure mode where the model becomes the whole project: progress is reported in accuracy metrics, the team celebrates hitting target accuracy, and the deployment pipeline, monitoring, drift detection, downstream integration, and operator runbooks are all left for “later.” The blueprint pulls those forward, building the evaluation harness and the monitoring layer alongside the model rather than after it, because a model with no harness is a model that degrades silently.

Build runs against the constraint document, re-read at the start of every weekly check-in. Scope changes route back to the Outcome row; disputes route back to the Constraints row. The discipline keeps the build pointed at the outcome rather than at model performance for its own sake.

— Phase four

Days 76–90 · Embed.

Embed is the phase most likely to be cut for time, which is exactly why initiatives fail so often: it is where the model becomes a capability the organisation actually owns. In the final two weeks the work is operator training, runbooks for the operations team, escalation paths for when the model is uncertain, the post-launch feedback loop, and the handover that makes the capability survive the team that built it. None of this is glamorous. All of it is the difference between a model that compounds and one that fades to uselessness within six months of launch.

Embed is also where the audit trail closes: the reasoning, the gates passed, the owner, and the monitoring in place are all documented, so that a regulator, an acquirer, or a future CFO can reconstruct why the system was deployed and on what basis. Under tightening regimes like the EU AI Act, that trail is not optional for higher-risk systems — and built in from the start, it costs almost nothing.

Gate 3
End of day 90 · capability, not pilot?
Is the initiative owned, monitored, adopted, and operable without the build team — and did it move the number in the constraint document? This is the gate that decides whether you have a capability or just a launch.
— See the artifactThe 90-Day Execution Blueprint — phased plan, gates & sample View →— What the blueprint really enforces

Gates are off-ramps, not just milestones.

The structure of the blueprint matters less than the discipline it enforces, and that discipline reduces to one idea most plans get wrong: the gates are real. A milestone you always pass is not a gate; it is a ceremony. For these gates to mean anything, “stop” has to be a genuine, pre-committed option, and the people who designed the gates must have the authority to pull them. Without that, every continuation decision drifts toward continuation under sunk-cost pressure, and the initiative becomes the thing it was built to avoid — a permanent line item that no longer aspires to its original outcome.

Ninety days, four phases, three gates, one named owner, and a constraint document re-read at every check-in. It is unglamorous, and it is the difference between an AI initiative that earns its budget and one that quietly burns it. The model is roughly 20% of the work. The other 80% — the diagnosis, the design, the embed, and the willingness to stop — is what this blueprint is for.

Stand up a gated 90-day plan

Thirty minutes with Liron to map the first 90 days of an enterprise AI initiative — and whether a paid diagnostic that produces a phased, gated 90-Day Execution Blueprint is the right next step.

Book an AI Decision Call