The real cost of a failed pilot
If this pilot fails, what exactly have we lost? The invoice is often the smallest part of the answer.
Why the cost of failure needs its own ledger
A proof of concept or pilot is usually approved on the strength of its upside. The downside is rarely written down, so when a trial stalls nobody can say what it cost. Some published surveys on industrial digital programs report that a large share of pilots never scale, with figures around 70 percent cited for transformations that stay in early trials. Those figures differ in source and in how failure is defined, so they are warnings and not a base rate for any one plant. Even if a plant's own rate is lower, a failure is a plausible outcome and deserves a budget line like any other risk.
Two related articles sit on either side of this one. Pilot graveyards are the real maturity baseline treats failed trials as evidence about a plant's maturity. What a two-to-four-week hall pilot actually costs to learn prices a trial that is designed to teach something. The arithmetic below covers the case in between: a pilot that was supposed to work and did not.
Direct costs you can invoice
The first group is easy to find. It covers the license or subscription for the pilot period, any devices bought or rented, installation, configuration, and external consulting. For a bounded trial this group is small on purpose. It is also the only group that shows up in a project report, which is why failed pilots tend to be described as cheap.
The group grows quickly when a pilot is scoped like a rollout. A trial that instruments a whole building, connects every system, and builds a full 3D model before anyone has agreed on the question spends the budget of a program on the evidence of a trial. The unit that drives cost should be narrow. Pricing by data points rather than by named user seats keeps a narrow zone narrow, which is how twinzo prices, and the detail is on pricing.
Internal hours that never reach the project budget
The second group is larger and mostly invisible. It is the paid time of people who took part because the pilot needed them. Typical contributors are the shift lead who judged the picture, an industrial engineer who built the baseline, a planner who changed a routine for the test, an IT owner who opened a network path, and a sponsor who attended reviews. These hours come from existing payroll and never appear as an invoice.
They matter because they are opportunity cost in the narrow sense. Each hour spent on a trial that fails is an hour not spent on an improvement that was ready. A simple way to expose them is to ask every participant at the start to estimate their hours per week. Summed over the pilot, that can be larger than the direct group. If nobody is willing to name hours, the trial is likely to run on spare time and fail quietly.
Stranded work and what can still be reused
Not everything is lost when a pilot ends. A useful review sorts the work into reusable and stranded. The distinction decides how much of the cost is really a write-off.
Reusable work usually includes the facility geometry, the list of systems and owners that were mapped, interface specifications, naming rules, and the written baseline of the loss the pilot targeted. Those items hold value for any later attempt, even with a different tool. The additive logic behind this is described in each early layer must still earn money when the next one lands.
Stranded work usually includes custom integrations that fit only one tool, dashboards nobody opened, and feeds that were switched on but never used. It also includes data that was never stored in a form the next attempt can use. A pilot that ran live but kept no record produced a demonstration, not a dataset. For an operational digital twin trial, three outputs should survive even a failed pilot. The usage record of the live logistics view shows whether people acted on it. The spatially oriented dataset holds positions and events. Correlation and causality analytics can then ask what the record says, even if the pilot goal was missed. A failed trial that keeps the record is still a partial asset.
The cost of the lost months
The third group is time. A pilot that runs for a quarter and ends without a decision leaves the baseline loss running for that quarter and delays the next attempt. The plant pays the baseline cost described in the costs of doing nothing during the pilot, then again during the pause that usually follows a failure. Teams tend to stop for a while, change the sponsor, or wait for the next budget cycle.
The same period also costs lean work. Lean manufacturing teams that waited for pilot results to start a waste-reduction project lose the quarter, and teams that ran both in parallel have to separate which change caused which result. A pilot with no written pass line makes that separation hard, so even a good result can be disputed.
Credibility and the next proposal
The last group is the hardest to price. A failed pilot changes how the next proposal is heard. Operators may remember a screen that did not match their shift. Finance may remember a promise that was not met. Sponsors may remember who owned the result. The next honest proposal, even a small one, inherits that history.
This is not a reason to avoid pilots. It is a reason to design them so that failure is explicit and early. A trial that ends with a written finding, such as the zone picture did not match the floor or nobody acted on a confirmed loss, preserves credibility better than one that fades. A clear negative result is a comparatively cheap and honest asset. An ambiguous one is expensive.
Why pilots fail in cost terms
Most failed pilots can be traced to a handful of avoidable causes. The scope was wide. Nobody owned the decision the pilot was meant to support. The question was a technology question, such as whether a system could be installed, instead of a floor question, such as whether a lead could change a decision. Selection of a technology before the question is the pattern addressed in start with the decision, not the technology.
A fourth cause is isolation. A pilot on one asset class, such as asset management, can look good in isolation and then fail to connect to the systems that decide whether anyone acts. The same applies to inventory management data that does not match physical location. Pilots that do not connect to existing systems of record become demonstrations that nobody can adopt.
How to cap the loss before the pilot starts
1. Write the loss in money or hours you already have - A pilot with no baseline cannot prove anything, including failure.
2. Name hours as well as invoices - Ask each participant for weekly hours and sum them before approval.
3. Write the pass line and the kill line - Define what result continues the work and what result stops it, in advance, in one page.
4. Keep the record regardless of outcome - Make sure positions, events, and the baseline are stored so a failed pilot still leaves reusable evidence.
5. Keep the scope as small as the question - One zone, one owner, one loss. Widen only after a decision, not before.
6. Run a closing review in the first week after the end - Sort the work into reusable and stranded and record what the next attempt should not repeat.
A smart manufacturing program that treats failure as a managed outcome is likely to lose less, and learn more, than one that treats every pilot as a promise. Capability depth for a bounded zone is on the features overview and internal logistics optimization. Get in touch if you want to write the pass line, the kill line, and the hours for one pilot before it starts.