The pilot needs an exit

A pilot is useful when it reduces uncertainty that prevents a larger decision. It becomes wasteful when success is undefined, access is incomplete and nobody knows what follows. The project then continues because stopping feels awkward.

Specify the uncertainty first. Are you testing technical feasibility, user adoption, commercial value or delivery compatibility? One pilot rarely answers all four with equal confidence. Choose the decision it is meant to support.

Agree a baseline, observation period and success criteria. Include conditions that would justify stopping or changing direction. A pilot that can only be declared successful is a demonstration, not an investigation.

The environment matters. A carefully supported trial may perform well in conditions that will not exist at scale. Record the extra attention, manual work and exceptional access required. Those costs belong in the interpretation of the result.

A paid pilot should have a defined output and independent value. The client is buying a bounded learning process, not funding an indefinite attempt to earn the implementation contract. If the result is negative, the report should still help them avoid a poor decision.

Discuss the post-pilot route before starting: what must be true for expansion, who decides and what new commitments would be needed. This does not guarantee follow-on work. It ensures that the learning has somewhere useful to go.