The first 100 days should produce an informed operating decision: a bounded system ready for supported use, a narrower scope, or evidence that the proposed work should wait. It is not a promise to transform a company on a fixed date.

Before starting the implementation clock, confirm a sponsor, a business owner, access to the relevant people and systems, and authority to approve changes. Procurement, data remediation, security review, and integration constraints may extend the sequence.

This plan applies the five Meru stages to one complete workflow: understand the operation, define the priority, design the solution, implement the system, and support and improve. Passing a readiness gate matters more than keeping a calendar milestone.

Observe the workflow with the people who perform it. Follow representative records from the initial trigger through completion, including escalation, handoffs, and failures. Establish which system holds the authoritative record.

• Document inputs, decisions, outputs, users, systems, and exceptions.
• Measure a representative baseline, with its period, source, and limitations.
• Confirm approved data use, vendor constraints, account access, and decision rights.
• Compare AI with process repair, existing features, and rules-based alternatives.
• Choose one priority and agree quality, cost, adoption, and business acceptance criteria.

Gate: Management can explain the problem, the owner, the expected operating change, and what would disprove the proposal. Do not move into a build with unresolved data rights or no route into the core system.

Agree the design before scope expands. Specify permitted inputs, where outputs land, required review, integration behavior, and the fallback when a dependency or model fails. Establish an evaluation set from authorized, representative examples.

• Test missing, contradictory, stale, and malformed information, not just ideal records.
• Test permission boundaries and isolation between accounts or companies.
• Confirm retries cannot create duplicate writes or unapproved downstream actions.
• Measure the cost and latency of the full workflow, including review and rework.
• Prepare operating instructions, support ownership, logging, and rollback.

Gate: The business and technical owners have evidence against the agreed tests and understand remaining limitations. Use shadow mode or a restricted group where appropriate; do not turn a test result into permission for unrestricted deployment.

Roll out to a defined group with trained reviewers and a named escalation route. Compare actual work with the baseline, retaining enough context to explain changes in workload, staffing, or business mix.

• Inspect use, abandonment, overrides, exceptions, and completed work.
• Review output quality and permission behavior during representative live demand.
• Track recurring costs, review effort, and support burden.
• Have someone other than the builder demonstrate routine operation and recovery.
• Keep an improvement backlog and decide what merits further investment.

Gate: The owner can accept supported production use against the agreed criteria. If volume is too low or performance remains uncertain, extend controlled use. A calendar date is not evidence.

Set acceptance thresholds before testing and justify them for the workflow’s risk. There is no universal accuracy percentage or sample size that makes every AI system safe.

Access or ownership is still unresolved.

The build depends on accounts, data, or decisions nobody can legitimately authorize.

What to do: Pause the dependent work and resolve permissions or scope. Do not work around controls with personal credentials.

The baseline keeps changing to justify the result.

The program has no agreed comparison method or ignores shifts in workload.

What to do: Freeze definitions, document changed conditions, and separate observed results from estimates.

The system produces consequential outputs without review.

The release scope moved beyond tested decisions and acceptable risk.

What to do: Restrict usage, restore the approved review path, and retest before expansion.

Everyone is waiting for a portfolio-wide launch.

Too many companies and dependencies were tied to one deadline.

What to do: Separate company readiness gates and complete one operating implementation before replication.

During delivery, use a regular working review for blockers and a separate sponsor review for scope, investment, and risk decisions. Agree the frequency around the work rather than adding meetings by default.

Keep one decision log with the issue, evidence, owner, due date, and consequence of delay. At the end of controlled live use, choose explicitly: expand, improve within scope, maintain, defer, or stop. Record why.

Released time should be reported as capacity until management can show how it was redeployed or converted into realized savings. Do not turn an estimated time saving into a financial result by multiplying it by payroll alone.

1. What workflow are we improving, and where does it begin and end?
2. Who owns the operating result and who can approve the release?
3. What baseline will we use, and what is still unknown?
4. Which systems, permissions, and people are dependencies?
5. What quality and cost conditions must the system meet?
6. How will exceptions, failures, and rollback be handled?
7. What evidence will authorize the next stage?