IMPLEMENTATION PLANNING · OCTOBER 2026
Ninety days is a planning window, not an ROI promise.
Use a 90-day roadmap to organize a bounded implementation with explicit acceptance gates. Advance when evidence, controls and operating capacity are ready; a calendar milestone alone should not authorize a wider deployment.
Answer five questions before day one
What exact task or decision will change? What is the current baseline? Which approved data supports the work? Who owns the business outcome? What happens when the system fails? If the team cannot answer these, begin with discovery rather than announcing a production date.
Name a sponsor with decision authority, a process owner, technical lead, data owner and operational reviewer. One person may hold several roles in a small team, but the responsibilities still exist. Allocate actual time and budget; a project staffed only between other commitments should not be planned as a dedicated implementation.
Write the boundaries: systems, customers, geography, permitted actions and excluded cases. Define the outcome and unacceptable behavior. An implementation can be successful when it creates reliable draft assistance; full autonomy is not a mandatory destination.
Days 1–14: establish evidence and access
Document the baseline process using representative cases, handling time, quality defects and current costs. Preserve case definitions and observation windows so later comparisons remain meaningful. Separate unusually easy examples from the normal workload.
Create a data inventory with owners, permissions, retention, update frequency and known quality problems. Reconcile important records and identify conflicting sources. McKinsey’s agentic foundations analysis emphasizes governed data; your project still needs to verify the actual permissions and reliability of its own sources. Governed data foundations
End this phase with a task contract, source register, baseline and named operating owners. The gate is readiness to build against trustworthy inputs, not the completion of a slide deck. If essential data or authority is missing, resolve that dependency before committing to broader scope.
Days 15–28: choose the smallest suitable architecture
Decide which steps should be deterministic, which need model interpretation and which require human approval. Compare managed platforms, automation builders and a custom service against the same task contract. Ask suppliers to show difficult cases, permissions and recovery, not just attractive demonstrations.
Estimate complete costs: implementation, subscriptions, usage, integration, review, maintenance and incidents. Record assumptions and downside sensitivity. Do not use an invented survey to claim that teams following a particular roadmap have a guaranteed success rate.
Choose acceptance criteria before procurement. For example: no unauthorized writes, correct source references, usable handoffs and successful recovery from a timeout. Have operations approve the criteria and confirm the fallback workflow. The gate is a feasible architecture with resources and a credible validation plan.
Days 29–56: implement and challenge the workflow
Build a thin end-to-end slice with read-only or draft behavior first. Implement schema checks, narrow tools, identity boundaries, action logs and exception queues. Use versioned prompts and configuration so a tested release can be reproduced.
Create evaluations from real task classes, including missing data, stale policy, conflicting evidence, duplicate events, malicious instructions and outages. OpenAI’s guardrail documentation describes input, output and tool checks; use them alongside deterministic business authorization. Guardrail documentation
Rehearse human takeover and rollback. An operator should be able to find an affected case, understand what happened and resume or stop it safely. DeepMind’s agent-security roadmap supports layered defenses and incremental permissions; test those boundaries before adding consequential tools. Agent security roadmap
The gate is accepted workflow behavior with documented limitations. Fix retrieval, authorization and integration defects at their source rather than treating every failure as a request for a different model.
Days 57–90: release narrowly and review the decision
Use days 57–70 for a controlled cohort or shadow mode suited to the risk. Keep the existing process available and staff exception handling. Record case-level outcomes, intervention time, complaints, latency and full operating cost. Stop or restrict the affected action when unacceptable behavior appears.
Use days 71–90 to compare against the baseline, investigate failures and decide whether to expand, revise or stop. Document changes in workload, staffing or policy that could affect the comparison. A pilot is not evidence for channels, languages or actions it never tested.
Close with a decision memo: accepted scope, measured result, limitations, maintenance owner, incident route, budget and next review date. Expansion requires the same authority and evidence discipline as the first release. If the project remains in draft mode at day 90 for a sound reason, report that status honestly rather than calling it production.
Compare the choices
| Phase | Required evidence | If the gate fails |
|---|---|---|
| Foundation | Baseline, task contract and approved sources | Resolve data and authority dependencies. |
| Selection | Feasible architecture, cost and acceptance criteria | Reduce scope or revise procurement. |
| Build | Workflow, adversarial and recovery results | Fix the failing layer before launch. |
| Controlled release | Case-level quality and operating workload | Pause the affected scope and use fallback. |
| Review | Measured outcomes and funded ownership | Revise, stop or conditionally expand. |
Worked example: make the decision concrete
Illustrative roadmap: a support team proposes automatic account changes but lacks reliable customer authentication. The first two weeks expose that dependency. The team changes the initial scope to approved-policy answers and draft assistance while engineering builds the authentication boundary.
By day 60, the draft workflow passes its case suite and saves observed preparation time, but account changes remain excluded. The review memo records both facts. This is a useful controlled implementation, not a failure to achieve a preselected autonomy label. The next release depends on authentication and recovery evidence rather than the calendar.
Failure modes to plan for
The pilot that never ends usually lacks an acceptance decision, owner or operating budget. Set review gates and require a concrete continue, change or stop decision. Endless experimentation is not a substitute for accountable delivery.
Other failures include stale knowledge, hidden review work and no staffed escalation route. A successful demo can fail immediately under normal exceptions. Keep a visible limitation register and a funded maintenance plan. Avoid making a promised ROI number the gate when the measurement method and baseline are not credible.
Your useful next step
Complete the five preflight questions for one bounded workflow. Assign owners and capacity, create a baseline and write pass-or-fail authority criteria. Use that brief to schedule the first two weeks rather than committing immediately to a wider launch.
Questions and answers
Can every AI project launch in 90 days?
No. The timeframe is a planning structure. Data, integrations, approvals and operational readiness can require more time; release only the scope that passes its gates.
How large should the pilot be?
Choose a cohort that represents the intended task and supports useful quality review. Risk, case diversity and operational capacity should determine scope rather than an arbitrary universal percentage.
Who should own the project?
A business process owner should own outcomes, with named technical, data and operating responsibilities. The sponsor must provide authority, resources and escalation support.
What counts as completion?
An accepted workflow with evidence, explicit limitations, funded maintenance and a working incident route. A prototype or vendor purchase alone is not a completed implementation.
Sources and evidence scope
Primary sources checked on 11 October 2026. Product pages establish vendor-described features; they do not establish independent comparative performance. Worked examples are explicitly illustrative. Implementation recommendations are editorial guidance.
- Mckinsey Data — Primary consultancy analysis supports governed data transformations and agent scaling, not guaranteed ROI.
- Guardrails — Documents input/output and tool guardrails; guardrails do not themselves replace authorization.
- Deepmind — June 18 roadmap supports insider-risk threat modeling, defense in depth, monitoring, prevention/response and incremental permissions.
Research Path