Ai delivery

• 21 May, 2026
• • AI Strategy

How to Set Realistic AI Delivery Timelines When the Board Expects 90 Days

The gap between what boards expect from AI programs and what those programs can actually deliver in a given timeframe is one of the most consistent management problems I encounter. It is not a communication failure exactly. It is a structural feature of how AI investment decisions get made. A board approves AI investment based on presentations that show capability: what the technology can do, what other organizations have achieved, what the business case looks like over a three-year horizon. The approval is often accompanied by an expectation of visible results within a quarter or two — a reasonable expectation given that the presentation showed impressive capability, and unreasonable given what it actually takes to deploy that capability in a specific organizational context. The job of the program sponsor — usually a CTO, a CDO, or a COO — is to close that gap without losing the organizational momentum the board's enthusiasm creates. This requires a specific kind of honesty that is harder to deliver than it sounds. Why 90-day AI delivery is usually the wrong framing Ninety days is enough time to demonstrate AI capability in a controlled proof-of-concept. It is not enough time to deliver an AI system that is running in production, integrated with existing workflows, validated for the organization's specific data, and supported by the change management that makes adoption stick. The difference matters because boards typically want the latter and are shown the former. A proof-of-concept demonstrates that the technology works as advertised and that the use case is viable. It does not demonstrate that the organization can operate the system at scale, that the data quality is sufficient for production use, or that the business process changes required for adoption have taken hold. When a program delivers a proof-of-concept at 90 days and presents it as AI delivery, the gap between expectation and reality tends to surface three to six months later. The proof-of-concept did not scale. The production system encountered data quality issues. Adoption is lower than expected. The program has entered a second phase that was not in the original plan, against a backdrop of board impatience that is harder to manage because expectations were already set too high. The better framing: what can be delivered and operated in production at 90 days, what can be delivered at 6 months, and what is the full program trajectory? Most boards, presented with this honestly, will accept it. The resistance usually comes not from boards demanding the impossible but from sponsors who have not had the conversation clearly. How timelines actually break down The components that make AI delivery take longer than boards anticipate are predictable. Understanding them makes it easier to plan and explain. Data preparation. The most consistent source of delivery delay. Data that looks usable on a brief assessment turns out to require cleaning, labeling, transformation, or pipeline work before an AI system can use it effectively. This is not a failure of planning — it is a feature of enterprise data environments. Build it into the timeline as a defined workstream, not as an asterisk. Model validation. Validating that an AI model performs acceptably on the organization's specific data, in the organization's specific context, takes longer than validating it against vendor benchmarks. Edge cases appear. The performance envelope is narrower than the benchmark suggested. Iteration takes time. Three to six weeks is typical; six to twelve is not unusual. Integration. Connecting an AI system to production infrastructure — identity management, existing software systems, data pipelines, monitoring and alerting — is software engineering work that takes time regardless of how capable the AI model is. AI programs that underestimate integration effort routinely miss timelines. Change management and adoption. Process changes and user adoption do not happen automatically after a system goes live. Training, workflow adjustment, performance management changes, and sustained change management support are all required. The timeline for meaningful adoption is typically measured in months, not weeks. Governance and compliance. For AI systems that affect regulated processes, customer interactions, or personal data, governance review and compliance sign-off are sequential steps, not parallel work. Build them into the critical path. How to have the timeline conversation with the board The conversation is easier than it feels, because the content is not primarily about managing expectations down — it is about setting expectations clearly. The structure that works: present the full delivery plan at three stages. What can be demonstrated in proof-of-concept at 90 days. What will be in production at six months. What the full program delivers by 12 months. Connect each stage to specific business outcomes that the board can assess against the investment. The proof-of-concept stage is not meaningless — it validates technical feasibility, surfaces data issues, and creates organizational confidence. Frame it as what it is: a necessary step in the program, not the program's deliverable. At each stage, be specific about what "delivered" means. A production system with 200 users in one department has a different value proposition than a proof-of-concept with 10 users in controlled conditions. Make the distinction visible, not implicit. If the 90-day board expectation is already in place, the conversation is harder but still necessary. The choice is between a hard conversation now — explaining that the timeline needs adjustment and why — and a harder conversation later, when the program has failed to deliver what was implicitly promised. The earlier conversation is always less expensive. The pilot-to-production gap The specific transition that fails most often is the move from a successful pilot to production deployment. A pilot can look excellent in controlled conditions and then struggle significantly in production for reasons that are predictable in retrospect. Pilot conditions tend to involve enthusiastic early adopters, clean data for the test cases, simplified integration with existing systems, and high-touch support from the delivery team. Production conditions involve the full user population, real data complexity, full integration requirements, and standard support levels. The gap between pilot and production performance is not a project management failure. It is an inherent feature of the transition that requires explicit planning. Build a production readiness assessment into the program that specifically asks: what will be different in production from what was true in the pilot, and what does the program need to do to address those differences? What to take from thisNinety-day AI delivery usually produces a proof-of-concept, not a production system. Be explicit about the distinction when setting board expectations. Present the full program trajectory in three stages — proof-of-concept, production, full scale — each with specific outcomes. This is clearer than a single timeline with a single milestone. Data preparation, integration, change management, and compliance review are the predictable sources of AI delivery delay. Build them into the timeline explicitly, not as contingency. The transition from pilot to production requires a dedicated readiness assessment. The conditions that made the pilot successful need to be replicated or explicitly addressed in production planning. The hard conversation about timeline adjustment is always less expensive when it happens before the missed milestone, not after. Have it early.

Read full article