09From pilot to product

Everything so far assumes the project is meant to go live. A system that answers technicians' questions is only worth something once they use it, every day, for years.

The pilot that cannot grow

Many pilots are built to impress, not to last: documents loaded by hand, access rights ignored, answers checked by eye, no record of which document an answer came from. Then the pilot succeeds, and the trouble starts. In our rail maintainer's depot, documents are updated every week and the system falls behind. Subcontractors must not see some supplier documents, and the system cannot tell them apart. After an incident, nobody can say which answer a technician received, or where it came from.

The organisation then faces two bad options: rebuild properly, a second project the business case never included, or go live as is, with risks nobody has assessed. Both are common, and both are avoidable.

Decide at the start, build from Walk

The question belongs at Crawl: is this meant to go live? A throwaway experiment can be worthwhile, as long as everyone knows that is what it is. If the answer is yes, the system starts in Crawl as a skeleton meant to grow, becomes a production foundation in Walk, and is funded as part of each stage rather than as a separate project after success. In management terms, that means:

• every answer can be traced to the exact version of its source, for an audit or after an incident;
• access rights are enforced as rigorously as in any other company system;
• knowledge is updated through a repeatable process, and quality is measured automatically on every change;
• the cost of each question is known, and the model or vendor can be changed without starting over;
• users know whom to call when something goes wrong.

"Could we operate this for years?" is part of the Run stage's exit criteria. Seen this way, the system is not a project that ends at delivery but a product, with an owner, a roadmap, releases, support, and a lifespan measured in years, like the engines it helps maintain. The disciplines of product development apply, and they are not new either.

How to build those foundations is the subject of the companion article for CTOs, CIOs and their teams, Building It.