Ninety days is a decision window, not a deadline
I use ninety days as a window for gathering enough evidence to make a funding decision. It is usually enough to learn whether a carefully chosen workflow deserves more investment. It is not a promise that procurement, security and data preparation will all finish on schedule. I want those dependencies visible at the start so the team can spend the time testing useful work rather than explaining a late launch.
Define the decision the program must enable: expand a particular workflow, revise it, or stop. Then make dependencies visible early. What follows is the sequence I use with clients rolling out Claude and governed analytics, adapted from two decades of running digital transformation in regulated environments.
Days one to thirty: choose the workflow and secure the environment
In the first fifteen days, pick one or two recurring workflows with accountable business owners. Document the current process, a small set of representative questions, the measures and time boundaries that matter, and who controls access to the systems involved. Establish a baseline from a manageable sample of real work. Finish with a written problem statement that also says what the pilot leaves out.
From day sixteen to thirty, settle identity, permissions, data boundaries and support before any user logs in. Security first is my most consistent field lesson. Use synthetic or approved test data while access decisions finish. Decide how the team will log issues without spreading customer data or protected health information into general project tools. If a required capability is unavailable, revise the pilot openly. A roadmap item must never become an unstated launch assumption.
Days thirty-one to sixty: run bounded work and fix causes
Introduce the workflow to a small group whose everyday job includes the task, with ordinary access levels rather than administrator privileges. Provide examples and a short review routine. Track completed work, checking time, exceptions and requests for help. Keep the existing process available so people can compare and recover.
From day forty-six, group issues by cause rather than treating each as a prompt problem: unclear definitions, inaccessible sources, stale data, confusing presentation, missing training. Assign each cause an owner. Retest changes against a stable evaluation set as well as new cases, and record what changed, so later improvements are understood rather than credited vaguely to a better model.
Days sixty-one to ninety: test ownership, then decide
Ask whether the workflow can run without constant attention from the launch team. Confirm who supports users, maintains definitions, reviews access and handles incidents. Test the escalation route with a realistic exception. Review cost and capacity under expected usage. A pilot that works only because its creators watch every interaction is not yet an operating service.
In the final two weeks, compare results with the original acceptance criteria, including failures and review time. Choose expansion, revision or closure with a named sponsor. Expansion needs a support plan and a next cohort. Revision needs a specific hypothesis and a new decision date. Closure should preserve definitions, evidence and lessons without dressing the experiment up as a success story.
How the plan changes by organization size
Adjust the schedule to the constraint you actually have. A small team may choose a workflow quickly but struggle to cover support alongside delivery. An organization with established review processes may need more lead time for procurement and validation. Identify those dependencies in the first planning session and put their owners on the schedule. If a prerequisite slips, narrow the evaluation or move the decision date rather than pretending the dependency disappeared.
Across all of them, the hardest problem is rarely technical. When platform ambitions and departmental quick wins compete and nobody owns data governance, the pilot stalls. Solve the org design problem first, then the technology problem.
Leave a record that outlives the project
Maintain a concise decision log, a source and permissions map, a question library and a scorecard. These records explain to new team members, auditors and examiners why the workflow behaves as it does. Publish only approved, substantiated claims externally. An enterprise AI assessment can structure the first fifteen days, and a tailored Nexatron demonstration can test the analytics questions that belong inside the plan.