I’ve watched AI transformation teams spend their whole first quarter producing documents about the transformation: a strategy deck and a use case backlog, a vendor shortlist and a communications plan. Each document is real work, and none of it runs anything. The transformation itself won’t finish in ninety days, and nobody serious expects it to. The first quarter has to produce the machinery the company will use to run it: who makes which decisions, who owns each workflow, how finance counts the value, and what it takes to stop weak work.
Start with the mandate. Whoever runs the transformation needs it on paper: which decisions they can take alone and which need the executive team, how much money they control and where their authority stops. Leave it unwritten and they’ll negotiate their authority one decision at a time, and that takes the quarter. The boundary questions are predictable, like whether they can stop a function’s pet project and whether they can commit the company to a vendor. Settle those in week one.
Spend the first thirty days getting to operating truth, and build the workflow inventory before anything else. The tool inventory the company already has shows it pays for forty licenses, and not much more. The workflow inventory shows the claims team handling eleven thousand claims a month with four people touching each one, and the intake step a model could do tomorrow. That’s the unit the whole transformation will manage, so it has to be counted in workflows.
Each workflow the program might touch needs a baseline measured before anything changes: what the work costs, who does it, how long it takes, and how often it goes wrong. Baselines are boring, and they’re also the only way to settle the arguments later, because a pilot without a baseline can only be judged on enthusiasm. Write the evidence bar down at the same time. Trust a number the team measured itself. A sampled number is weaker, and a vendor’s number is the weakest of the lot. A number nobody can check doesn’t count as evidence, and projected savings don’t count either.
Every workflow on the inventory also needs two names against it: the functional owner whose number depends on the work, and the technical owner who can change the system underneath it.
Committees don’t count.
A workflow owned by a working group is a workflow nobody has to answer for, and month one is when this is cheapest to fix, because nobody’s budget has been touched yet.
The constraints are part of that first month’s picture too. Data quality, identity and access, what the systems can connect to, regulatory and policy limits: companies have this map whether anyone has written it down or not, and when a transformation stalls, one of these is usually the reason while the model takes the blame. In month one the map only needs to show which constraints block which workflows, so nobody picks a pilot in month two that a policy question will kill in month four.
In the middle month, decide what to do with each workflow on the inventory. Some get pilots, and some get a written reason they’re not worth doing yet. Agree on the value categories with finance before any of that: costs coming out, people freed up for other work, new revenue, or less risk. Settle which category a pilot claims, and how finance will count it, before the pilot starts. Get finance in from month two, or the savings the transformation reports won’t hold up when someone checks them.
Write every pilot’s gates before it runs: the numbers that send it to scale, and the numbers that kill it. A middle result holds it for one more cycle, and only one. Criteria written after the results come in always fit the results, which is why the writing has to happen first. I think the kill gate is the one to watch. A transformation that hasn’t killed anything by day ninety hasn’t set a real bar, and it has to be easy for people to call for a kill, or they’ll keep weak pilots alive to avoid the conversation.
Somebody also gets named in month two to own agent permissions, because pilot teams will start proposing systems that act on their own. That owner decides what a system may read and change without a person, and what always waits for approval. The integration mechanics are a separate topic. By day ninety the company just needs the named owner, and the grant should feel like delegating spending authority, because that’s what it is.
By the third month the mechanisms should be running on a schedule. The main one is a monthly portfolio review that takes an hour or two. The review applies the gates, and owners answer in their own numbers against their own baselines. Every review decides something. One that doesn’t was a status meeting the deck had already covered.
Cross functional conflicts need a path with a clock on it. A pilot that needs security and the data team to agree can sit for a month with everyone behaving reasonably, and by the time it resolves the quarter is gone. Write the rule plainly: a disagreement between functions that stays open past two weeks goes to the executive sponsor, who decides it inside the week after. The clock is the point; the exact days are adjustable.
The executive team sees the portfolio monthly from month three: what moved through a gate and what got killed, with measured value against baseline. The board sees a quarterly version built from the same numbers. A report assembled straight from the portfolio review costs an hour. When reporting takes a special effort instead, the operating system doesn’t exist yet.
By day ninety the reviews should be folding into the meetings the COO already runs, with function owners answering for their own workflows. A cadence that can only run inside a special program dies with the program, and the point of building it as ordinary management is that line managers already know how to run it.
Write down, too, what the team won’t touch in the first ninety days. A full data cleanup. A company wide platform decision. Agents acting alone inside anything that touches money or customers. Retraining the whole workforce. Each of these is a year of work, and a team that promises any of them inside a quarter ends up explaining in month four.
If the use case list keeps growing while the kill count stays at zero, the mandate is still a program of presentations. The same goes for projected savings built on baselines that were never measured, and for a pilot on its third demo. Watch the meetings too: the ones about the transformation that end with alignment and without decisions. And the clearest check: ask what would keep running if the transformation team disappeared tomorrow. If the answer is nothing, the quarter produced a team and some slides.
I think ninety days is enough time to install all of this, and not enough time for much else, and that’s fine. A transformation that ends its first quarter with owners on every workflow, baselines measured before anything changed, gates written in advance, and a review that decides things has become part of how the company runs. The roadmap can be written later, and writing it is the easy part.