Most digital programmes fail before the first model is trained
The failure is almost never the algorithm. It is that the history the algorithm needed was never recorded.
7 min read
A pattern repeats across upstream digitalisation projects. A twelve-month programme is approved. Months one to four go to procurement and infrastructure. Months five and six go to data extraction, and this is where the project quietly changes shape: the historian turns out to have compressed its tags to a dead band, the maintenance records do not identify failure modes, and the well names in three systems do not reconcile.
By month seven the team is negotiating a scope reduction. By month twelve there is a dashboard, and the conclusion recorded in the closeout is that the machine learning did not deliver the expected benefit.
That conclusion is wrong in a specific and expensive way. The models were never the constraint. The constraint was that the data required to train and run them had not been captured, and nobody checked before the budget was committed.
This is why we sell a paid data-readiness assessment before anything else, and why that assessment frequently concludes that an operator should spend six months on remediation before buying another thing from us. It is an uncomfortable proposal in a sales conversation and it is far less uncomfortable than the alternative, which is discovering the same facts in month seven with a year of budget spent.
The practical test is simple enough to run internally. Pick the capability you most want. Write down the exact inputs it needs, at what frequency, over what history. Then go and find them. The answer is usually instructive, and it is always cheaper to get it now.