The demonstration went well. The tool summarized the documents, drafted the responses, and answered the questions. Six months later it is still a pilot, used by a handful of enthusiasts, and nobody can say whether it should be expanded, funded, or stopped.

This pattern is common, and the cause is rarely the technology. Pilots are usually set up to prove that a tool can do something. Production requires proving that a workflow runs better with it, and that the organization can operate it safely. Those are different questions, owned by different people.

Where pilots stall

  • No workflow owner. The pilot is run by an innovation or technology team, while the leader accountable for the workflow it affects is a spectator. When the pilot ends, nobody with authority over the work is ready to adopt it.
  • Success defined as a demonstration. There is no baseline for the current process, so there is no way to show that cycle time, quality, or cost changed.
  • Data and access settled late. Questions about confidential records, retention, and security review arrive after the pilot is built, and each one reopens the design.
  • Controls added afterward. Acceptable use, human review, and audit trail are treated as approvals to obtain at the end rather than design requirements from the start.
  • No path to production. Nobody has decided who will run the tool, support its users, pay for it, or retire the workaround it replaces.
A pilot without a decision date tends to run indefinitely, with a budget and no exit criteria.

Settle six things before starting

A one-page pilot charter, agreed before any build work begins, removes most of these stalls:

  1. The workflow and its owner. Name the process that will change and the leader accountable for it.
  2. A baseline measure. Record how the workflow performs today: cycle time, error rate, volume, or cost.
  3. A target. State the change that would justify moving to production.
  4. Data sources and access approvals. List the records the tool will use and obtain approvals before building.
  5. Review and control steps. Define where a person reviews output, how exceptions are handled, and what is logged.
  6. A decision date and criteria. Set the date on which leadership will decide to scale, adjust, or stop, and the evidence that decision will use.

Sequence the work

The most reliable sequence is the one that applies to any technology: map the workflow first, fix what does not need automation, then automate what is stable enough to hold. AI does not change that order. It raises the cost of skipping it, because a model applied to an inconsistent process produces inconsistent results faster. The same reasoning applies to conventional systems, as described in Map the work before you buy the software.