Spend days 1 to 30 mapping where the team's week actually goes and killing weak ideas. Spend days 31 to 60 building the smallest system that pays back, in two-week sprints. Spend days 61 to 90 measuring days handed back and deciding what's next. No big-bang transformation, no tool sprawl.
Why do the first 90 days matter?
Because that is when you hold both the mandate and the momentum, and both fade. In the first quarter people expect change, will give you their honest account of where the time goes, and haven't yet formed a view on whether your plans come true. By month six you are defending a track record instead of building one.
The cautionary context is real and worth stating plainly. By some estimates, more than 80% of AI projects fail, twice the failure rate of comparable non-AI IT projects, according to practitioner interviews published by RAND. For generative AI specifically, MIT's NANDA initiative reported that about 95% of enterprise pilots deliver little or no measurable impact on profit and loss. Those numbers describe a way of working, not a technology: projects picked from the technology down, scoped as transformations, and measured by nothing in particular. The 90-day plan below is designed to be the opposite of that on every count.
What should days 1 to 30 look like?
Mapping, not building. The first month's output is an honest account of where the team's week actually goes, and a shortlist of jobs that might be worth automating, with arithmetic attached.
- Sit with the people doing the work. Not a survey, not a workshop: watch the month-end, the reporting cycle, the checking, the chasing. The jobs that eat the week are visible within days if you look at the work rather than the org chart.
- Write the honest arithmetic for each candidate. Hours per month, what a mistake costs, how sensitive the data is, and whether the job runs on rules a person can state. Small numbers disqualify a job, whatever the demo looked like.
- Kill bad ideas early, in writing. The cheapest AI project is the one you decide not to do in week three. A short "not doing" list buys you credibility and protects the quarter for the job that deserves it.
By day 30 you want one page: the jobs eating the week, the sums beside each, one chosen build, and a named owner for it.
What should days 31 to 60 look like?
Building the smallest thing that pays back. Take the one job with the strongest arithmetic from the map, and build only that: not the platform it could grow into, not the suite of tools around it, the one system that hands back the most days for the least build.
The working method matters as much as the choice. Two-week sprints, with working software at the end of each fortnight rather than a slide about progress. The people who do the job today stay involved throughout, because they are the ones who know the exceptions, and they are the ones who must trust the output. And the system is built with the guardrails that make it safe to run: a person in charge of anything that matters, a full audit trail, and data kept in your own environment rather than handed to a third party.
If a fortnight passes without something you can watch running, treat that as the first red flag of your tenure and act on it. Working software every two weeks is not a delivery preference; it is how you keep a build honest.
What should days 61 to 90 look like?
Proving it, then deciding. Put the system into a real working month, on real data, alongside the people who own the output, and measure what happens against the day-30 arithmetic.
Measure in days handed back, because that is the unit the business feels: how much of the week returned to the team, and what did they do with it? The audit trail makes the evidence cheap to gather: it shows what the system did, what it flagged, and what people decided, so the review is a reading exercise rather than an archaeology project.
Then decide, with numbers on the table. Scale it to the next team or the next job; adjust it where the month exposed rough edges; or stop, if the arithmetic didn't survive contact with reality. A 90-day plan that ends in a well-evidenced "stop" is a success: it cost you one quarter and one build, not three years and a programme. What it must not end in is a pilot that drifts on unmeasured, because that is how the failure statistics up top get made.
What should you not do?
Big-bang transformation and tool sprawl: the two moves that feel like leadership and behave like risk.
The big-bang transformation announces everything at once, touches every team, and shows a demo at month six instead of a result at month three. It concentrates all your credibility in one bet whose feedback arrives after your window closes. Sequenced small builds get to the same destination with evidence at every step.
Tool sprawl is the quieter failure: a dozen AI subscriptions signed in the first month, each solving a sliver of a problem, none owned by anyone, most unopened by summer. You inherit the invoices and the scepticism. Buy tools where a generic job genuinely fits one, and be honest about the difference; our guide to build versus buy is the arithmetic for that call.
How do you start?
Start the map before day one if you can, because it costs nothing but conversations. Reading the last three board packs and asking each team lead "what eats your week?" is diligence you can do from outside the building.
If you want a partner for it, the map is exactly what we do first. A free Impact Call gives you the arithmetic on one real job and a one-page opportunity map; a paid mapping phase turns that into the day-30 deliverable above, with a straight recommendation attached, including "don't build anything yet" when that's the honest answer. What we won't do is sell you a transformation, because we've read the same failure statistics you have. For the money conversation, the shape is in our guide to what custom AI costs.
Sources
Figures and claims in this guide draw on our own delivery work and the sources below. We only publish numbers we can stand behind.
- RAND Corporation, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed" (65 practitioner interviews): by some estimates, more than 80% of AI projects fail, twice the rate of comparable non-AI IT projects. rand.org. Published 13 August 2024, accessed 8 July 2026.
- MIT NANDA initiative, "The GenAI Divide: State of AI in Business 2025", reported by Fortune: about 95% of enterprise generative AI pilots deliver little or no measurable P&L impact. fortune.com. Published 18 August 2025, accessed 8 July 2026.
- AI Nativ.es delivery experience, 2026: client work is described without names until we have written permission to use them.