Building the 90-Day AI Plan

Before reading on, make a guess. Ask the managers in your company whether every one of its strategic priorities has the money and the people it needs to succeed. What share would say yes?

When Donald Sull, Rebecca Homkes and Charles Sull put that question to nearly 8,000 managers in more than 250 companies, the answer was 11 percent. Nine managers in ten expected some of their organization’s major initiatives to fail for lack of resources. The same survey found that only 55 percent of middle managers could name even one of their company’s top five priorities. And when asked what got in the way of understanding the strategy, middle managers were four times more likely to blame the sheer number of priorities than unclear communication¹.

Those numbers describe ordinary strategy, not AI. But they describe exactly the conditions under which many first AI plans are written: an enthusiastic leadership team, a long list of good ideas from the portfolio, shared specialists who are already busy, and a board that wants visible progress by the end of the quarter. The previous five chapters gave you the inputs: a readiness assessment, a maturity target, a prioritized portfolio, an investment mix and the gates from pilot to scale. This chapter turns those inputs into the next ninety days.

A contract for one quarter

The ninety-day horizon is a management convention, popularized by Michael Watkins’s book on leadership transitions, The First 90 Days². It survives because it fits how organizations work. A quarter matches the budget and reporting cycle. It is long enough to put something real into operation and short enough that leaders can hold the whole plan in their heads.

The useful way to think about the plan is as a contract rather than a catalog. A catalog lists everything the organization hopes to do with AI. A contract names a small number of outcomes, the one person accountable for each, what must be true for them to happen, and the dates on which leadership will decide what happens next. A catalog can never be broken, because it never promised anything. A contract can be, which is why it is useful.

The contract is not the strategy, and it is not the roadmap. It is the first slice of a longer sequence, which the next chapter builds. Its job is narrower: to change what people do next Monday.

Deliver, learn, build

A first AI quarter usually needs three kinds of work at once, and each has a different kind of evidence at the end. Treat them as lanes, not as separate programs.

Deliver moves one or two of the portfolio’s most feasible, valuable initiatives toward production. Its Day 90 evidence is not a celebration but a decision, using the gates From AI Pilot to Production to Scale set out. Learn buys information about a strategic bet. As Quick Wins, Strategic Bets and Transformation Initiatives argued, a bet is an option, and an option is only worth funding if the quarter is designed to answer a specific question about it: is the accuracy good enough, will customers pay, does the unit cost work? Build supplies the capability the other two lanes cannot proceed without, such as a data connector, an approved route for model access or an evaluation set. Prioritizing the AI Portfolio gave the test for enablers: build what funded initiatives need, sized to their needs. In a quarter, the test is stricter still. If neither of the other lanes will use it by Day 90, it does not belong in this plan.

Few outcomes, written so Day 90 can settle them

A common defect of a first AI plan is size. In BCG’s 2024 survey of 1,000 senior executives, the companies furthest ahead with AI pursued only about half as many opportunities as their less advanced peers, and expected more than twice the return, an expectation the leaders reported and not a measured result³. Your own number comes from capacity, the arithmetic Prioritizing the AI Portfolio worked through: a shared team that finishes four things a quarter cannot run seven without slowing all of them. For a first quarter that usually means three to five outcomes.

Each outcome must also be written so that a review on Day 90 can settle whether it happened. That means naming the result, the baseline, the population and the date, which Baselines, Metrics and Measurement covers in detail.

Strong outcomes have a second property: each has one owner, and that owner is in the business, not in “the AI team”. Many people contribute. One person answers for the result. AI Roles, Ownership and Accountability explains why this matters beyond the quarter.

Plan for the quarter you will actually get

Even a short, well-written plan will run late, because people who plan are optimistic about their own work. Classic evidence comes from a study by Roger Buehler, Dale Griffin and Michael Ross. They asked students writing an honors thesis when they expected to finish. The average best guess was 33.9 days. The average actual time was 55.5 days, and fewer than a third finished by their own estimate. Most striking, when the students were asked for a date assuming everything went as poorly as it possibly could, fewer than half finished even by that⁴.

The psychologists call this the planning fallacy, and nothing about AI work makes it weaker. Integration, data access and security review are exactly the kinds of tasks that people underestimate. The practical response is to plan the quarter at less than full capacity, protect the slack, and decide in advance what will be cut first if the plan slips. A plan that only works if everything goes right is a plan to miss.

Start the long poles in week one

The critical path method, published in 1959 by James Kelley and Morgan Walker, rests on a simple idea: the longest chain of dependent tasks sets the earliest possible finish, so the tasks on that chain must start first⁵.

In AI plans the long poles are rarely technical. They are a security review with a backlog, a data access agreement with a system owner, a contract amendment with a software vendor, a legal assessment, or a consultation with employee representatives. Each sits in another function, and that is the problem. In the Sull survey, managers could rely on their boss and their own team most of the time, but colleagues in other departments were scarcely more reliable than outside partners¹.

So the first week of the plan is when the requests go in: the security review is booked, the data owner has agreed a date, procurement has the contract change, and legal has the use case description. Each request has a named person on the other side and a date. Executives earn their place in this step, because cross-functional commitments are the ones a project team cannot secure alone.

Three dates that are decisions

A 90-day plan has three dates on which leadership decides something. They are not status meetings, and the operating rhythm around them, the weekly and monthly reviews, belongs to AI Change Management, KPIs and Operating Rhythm.

Day 30 asks whether the contract is real: owners acting, baselines recorded, every long pole moving. If a security review has not started, the cheapest fix is now, by re-sequencing or cutting. Day 60 compares evidence with assumptions. Some outcomes are on track and deserve protection; others have learned enough to change shape. This is the moment to drop an outcome deliberately rather than let it fail quietly. Day 90 is the decision the plan was written to reach. For each Deliver outcome, the question is go or no-go for production: has the use case passed the value gate, and is the organization ready to run it? For each Learn outcome, it is whether the bet’s question was answered and whether to fund the next step or stop.

The Day 90 decision is deliberately not a scale decision. Scale is a separate proof that needs production evidence, which a system that has just entered production cannot yet supply. A first quarter that promises scale has promised something it cannot keep.

Say “not yet”, in writing

The plan’s most protective element is a list of what it will not do. Every portfolio contains more good ideas than a quarter can hold, and new requests arrive every week. Without a written list, each one is negotiated afresh, and the plan grows by small concessions.

Each entry carries its reason and the quarter in which it will be reconsidered. That turns refusal into sequencing, which is easier for the people whose ideas waited to accept. It also gives the next quarter’s plan its starting inventory: at Day 90, the not-yet list and the decisions together become the input to the next contract, so the organization never plans from zero.

Story: the launch that tried to do everything

One of the clearest documented post-mortems of an overfull plan comes from outside AI. HealthCare.gov is the US federal website through which residents of states without their own marketplaces buy private health insurance under the Affordable Care Act. It launched on 1 October 2013 and failed in public. In 2016 the Office of Inspector General of the Department of Health and Human Services published a case study of what went wrong, based on interviews with 86 officials, staff and contractors and on thousands of documents⁶. It is not an AI project, but its findings read like a list of the ways a first AI quarter goes wrong.

What happened. The inspector general judged the absence of clear leadership the most critical failure: it delayed decisions, blurred who was responsible for what, and left the agency unable to see how badly the project was deteriorating. Policy work took so long that too little time remained to build the website, and changing requirements compressed the build further. By August 2013 staff and contractors knew the system would not be fully tested before launch; complete end-to-end testing was never done, because the pieces arrived too late. On 24 September the agency’s chief information security officer raised concerns about incomplete security testing, and three days later the administrator signed a short-term authorization to operate that required the testing to be finished within six months. On 26 September, limited performance tests showed that the site could support far fewer simultaneous users than planned, and the infrastructure contractor was asked to double capacity within 72 hours. Leadership never formally discussed a delay; some staff wrongly believed the launch date was set in law, when the law required coverage to begin by 1 January 2014. On launch day about 250,000 people tried to use the site at once, outages began within two hours, and only six consumers managed to apply and select a plan⁶.

What changed. The recovery was organized differently. Agency staff and contractors worked as one team, performance was measured, and by 1 December 2013 the site was up more than 90 percent of the time and could handle more than 35,000 simultaneous users. The day after the first enrollment period closed, in April 2014, managers met for three days of what they called ruthless prioritization. They listed what they wanted, estimated the people and time each item needed, and cut about half of it, including an automated financial management system that had to wait. New functions went live only when they were ready, and a new application was soft-launched before the next enrollment period⁶.

Why it matters for a 90-day plan. Map the findings onto this chapter. The plan was sized to the ambition rather than to capacity, and scope was cut only in the final weeks. No single owner answered for the result. The long poles, testing, security authorization and computing capacity, surfaced in the last days instead of the first week. Warnings were raised and not acted on, which is what a Day 30 or Day 60 decision exists to prevent. And launch day promised the whole service to everyone at once, rather than a production decision on something smaller. The recovery used the tools of the contract under other names: a list sized to the people available, a written record of what would wait, and a rule that nothing goes live before it is ready.

What this means for leaders

The executive’s job in a 90-day plan is to keep it a contract. That means sizing it to capacity rather than ambition, assigning each outcome to a business owner, using executive weight to secure cross-functional long poles in week one, and defending the not-yet list when the next good idea arrives. It also means accepting a no-go on Day 90 as a kept contract. The plan promised a decision, not a success.

Check yourself

1. A good 90-day AI plan includes every high-priority initiative in the portfolio.MythFact
2. AI leaders tend to pursue fewer AI opportunities than their less advanced peers.MythFact
3. Asking planners for a worst-case estimate removes the planning fallacy.MythFact
4. Security reviews and data access agreements should be requested in the first week of the plan.MythFact
5. Day 90 is the right moment to decide whether a use case should scale across the company.MythFact
6. Reaching Day 90 with a no-go decision means the plan failed.MythFact

Reflection: price your current plan

What comes next

A 90-day plan is the first slice of a longer sequence. It cannot show when the platform should be built, how the workforce should change, or which bets should become transformations in later years. The next chapter, Building the Multi-Year AI Roadmap, extends the horizon, so that each quarter’s contract moves the organization in a deliberate direction.