AI implementation roadmap: a 90-day plan for mid-market companies

90 days is the right horizon

Six months is too long — strategy decays. Thirty days is too short — nothing real ships. Ninety days lets you discover, pilot, and ship one production use case while leadership keeps their attention on it.

The plan

Weeks 1–2: Discovery + audit

• Interview 8–12 people across product, eng, ops, finance, and support. Cheap insurance against building the wrong thing.
• Audit data accessibility: what lives where, what's stale, what's siloed.
• Score 30 use cases against impact / feasibility / data readiness.
• End of week 2: a ranked backlog and one pilot candidate that's ready to scope.

The interviews are the part most often cut for time and the part that most reliably changes the answer. Ask each person the same two questions: what takes longer than it should, and what do you not trust. The first surfaces automation candidates; the second surfaces where data quality will sink you. Both are more useful than asking people what they want AI to do, which produces a list of features rather than problems.

The data audit needs to be concrete enough to act on. For each candidate use case, answer three things: where the data lives, who owns access to it, and how long it takes to get. That third answer is the one that reorders backlogs — a high-impact use case behind a six-week access request is a worse first pilot than a moderate one you can start on Monday.

Score honestly, including on feasibility. A ranked backlog that puts the most exciting use case first, when it depends on data nobody can reach, produces a stalled 90 days and a conclusion that "AI didn't work here."

Weeks 3–4: Pilot scope + SOW

• Tight scope for the pilot — one workflow, one team, one measurable outcome.
• Define success metrics upfront. "We'll know it worked if X moves Y in 60 days."
• Build-vs-buy on the model layer. Default: hosted API. Don't reach for fine-tuning yet.
• Sign-off from the pilot owner and budget owner before any code lands.

The tight scope is the deliverable, not a constraint on it. A pilot that touches one workflow, one team, and one metric can be honestly evaluated in twelve weeks. One that spans three departments cannot, and the ambiguity is what leads to the familiar outcome where everyone agrees it was interesting and nobody can say whether it worked.

Define the success metric as a sentence with a number and a date in it, and get the budget owner to agree to it in writing before the build starts. Not because anyone is being difficult, but because a metric agreed afterwards is always chosen to fit the result.

Resist scope growth during scoping. Every stakeholder interviewed in weeks one and two will have a reasonable addition, and each one individually costs a few days. Collect them into a phase-two list, visibly, so people can see their idea was captured rather than ignored — that single move prevents most of the pressure to widen.

Weeks 5–10: Build

• Working code in week 5. If you don't have something to demo by end of week 5, the scope was wrong.
• Weekly demos to the pilot team. Not the leadership team — the pilot team.
• Eval suite from day one. Twenty test cases per use case, run weekly.
• Bi-weekly retros. Catch direction changes early when they're cheap.

Working code in week five means something crude and end to end, not a polished slice. The point is to prove the whole path — data in, model, output, somewhere a real user sees it — because that path is where the unknown problems live. Teams that spend weeks five to eight perfecting the model and only wire the integration in week nine discover their access problem with three weeks left.

Demo to the pilot team rather than to leadership, weekly. The pilot team will tell you the output is subtly wrong in ways leadership cannot see, and they will tell you early enough to act. Leadership demos produce approval, which is pleasant and uninformative.

The eval suite from day one is the difference between a pilot you can defend and a pilot you can only describe. Twenty cases is enough. It also settles the week-twelve conversation, because "here is what it got right and wrong, on cases we agreed in week four" is a much stronger position than a set of anecdotes.

Weeks 11–12: Ship + measure

• Production deploy to the pilot team. Real users, real tickets, real data.
• Daily readout for the first week. Catch regressions in hours, not days.
• Measure against the success metrics from week 4. Honest read-out at week 12.

Deploy to real users doing real work, not to a test group running scripted scenarios. Scripted testing tells you the system handles what you imagined; real traffic tells you what you failed to imagine, and that gap is the entire value of a pilot.

The daily readout in week one is not ceremony. Most of the failures you will ever see arrive in the first few days, when the input distribution is widest and nobody has learned to work around the system's weak spots yet. Catching those in hours keeps the pilot's reputation intact; catching them in a fortnight means the team has already decided it does not work.

Measure against the week-four metric and nothing else. There will be a temptation to present the metrics that moved instead of the one that was agreed, and it is the single fastest way to lose credibility for the next project.

Week 12+: Decide

• The pilot succeeded? Pick the next two use cases and start over.
• The pilot didn't? Honest postmortem. Was it the model, the data, the workflow, or the framing?

The people who decide whether this works

The plan above is a delivery schedule. Whether it lands depends on three people, and identifying them in week one is worth more than any tooling decision.

The pilot owner. Someone in the affected team whose own work gets better, who will use the thing daily and complain when it is wrong. Not a project manager — a user. If you cannot name this person, you have picked a use case nobody asked for, and no amount of build quality will fix that.

The data owner. Whoever actually controls access to the system your use case depends on. They are almost never in the room at kickoff, and they are the most common source of a three-week delay in the middle of the build. Bring them into week one, tell them what you will need, and ask what their process requires.

The budget owner. The person who agrees the success metric and, later, decides whether to continue. Their involvement should be narrow and specific: agree the metric in week four, read the honest result in week twelve. Involving them weekly turns a pilot into a performance.

The one you cannot skip. If the pilot owner and the data owner are the same person, you have an unusually easy project. If neither exists, you do not have a 90-day plan, you have a 90-day research exercise — which can be a legitimate thing to fund, but should be called that.

What to NOT do in the first 90 days

• Don't build a platform. Build a use case. Platforms are what you wish you'd built after three use cases — not before.
• Don't fine-tune anything. Prompts + RAG covers 85% of the value with a 10x faster iteration loop.
• Don't try to centralize all AI procurement in week 1. You'll spend the 90 days writing a policy doc and shipping nothing.
• Don't try to govern what you haven't built yet. Governance comes after you've seen what production AI actually does.

What the second 90 days looks like

The first cycle is designed to prove one thing works. The second is where most organisations lose momentum, because the obvious next move — do the same again, faster — is usually wrong.

Take two use cases, not one, and not five. One means the team's second cycle teaches them nothing new about scaling. Five means the shared work — access, evals, deployment, ownership — gets built five slightly different ways by people in a hurry.

Extract the reusable half deliberately. After one pilot you know which parts were use-case-specific and which were not: the retrieval layer, the eval harness, the observability, the deployment path. That is the platform, and it is the right time to build it — not before the first use case, which is the mistake the previous section warns against.

Fund the first system's upkeep explicitly. The pilot from cycle one now needs eval review, corpus maintenance, and someone on call. If that is absorbed silently into the same team's capacity, cycle two runs late and cycle one degrades. Naming it as a line, however small, is what prevents both.

Expect the second cycle to be less exciting and more valuable. The first proves it can work here. The second proves it can work here repeatedly, which is the thing that actually changes how a company operates.

What usually goes wrong

Across the 90-day plans we have run and inherited, the failures cluster into four patterns, and none of them is technical.

Access arrives in week six. The single most common one. The use case was chosen in week two, the data request went in during week three, and the credentials landed after the build was supposed to start. The fix is in week one: ask what the access process requires before ranking the backlog, not after.

The pilot owner changes job halfway through. Reorgs, holidays, and promotions do not pause for a 90-day plan. Name a second person who uses the system from the start, so the project does not lose its only user at week seven.

The metric quietly moves. The agreed measure turns out to be inconvenient — hard to instrument, or moving the wrong way — and a friendlier one appears in the week-twelve readout. Everyone notices, and it costs more credibility than a plainly reported miss would have.

Success gets absorbed instead of extended. The pilot works, the team is pleased, and nothing happens next because no one owns the second cycle or the first system's upkeep. Deciding in week eleven who owns both, before the result is known, is what turns a successful pilot into a programme rather than an anecdote.

What this costs

For a mid-market company, plan on $40K–$120K for the pilot (depends on use case complexity). The strategy phase (weeks 1–4) can be $15K–$30K standalone if you want to scope before you commit to the build.

If you don't have the budget for both, do the strategy phase only. A 30-page report and a ranked backlog is worth more than a half-built agent.