Someone proposes well control automation. Management asks for the business case. A consultant provides a number. Let’s say a flat 10% production increase. It sounds reasonable, doesn’t it? The business case gets approved, budget allocated, a pilot launched. Six months later, the pilot showed promising results. Twelve months later, it’s still a pilot. Eighteen months later, someone quietly archived it in the folder where good ideas go to die. The problem isn’t the technology. It’s that every critical decision was made before anyone actually built anything.
The uncomfortable truth is: if you only have resources to run two or three pilots a year, and 90% of those make it to production, you’re doing innovation theatre, not innovation factory.
The Data You Never Looked At
When someone proposes that well automation will deliver 10% production gain, ask them a simple question: have you examined the actual operational data?
Not the theoretical potential. Not the vendor’s white paper. The real, messy, noisy data from your operations.
What’s actually limiting production today? Is it reliability failures where equipment goes offline? Or is it optimisation opportunities where equipment runs suboptimally? These require completely different solutions. The first needs predictive maintenance and faster response times. The second needs real-time optimisation algorithms.
What could your operations team achieve without any machine learning model? Would they eventually capture that 10% gain through conventional methods, just more slowly? Would they get 7% of it? Or would they never reach it at all without automation?
What’s the time delay between identifying an issue and fixing it today? If your team already responds within 30 minutes, automation might save you 25 minutes. If the average response takes six hours because the right person isn’t available, you’ve got a much bigger prize.
Most of the data held by any enterprise is not economically useful, and much potentially valuable data requires substantial spending on quality assurance and data curation (JPT). But you don’t need perfect data to answer these questions. Some opportunities are obvious once you actually look.
The mistake is budgeting innovation on assumptions that were never stress tested against reality. You’re committing resources based on a number someone invented in a boardroom, not discovered in the field.
Prototype or Perish
There’s a dangerous pattern in how organisations curate ideas. Teams spend months evaluating concepts in PowerPoint. Consultants build business cases. Committees debate strategic alignment. Meanwhile, the one thing that would actually answer most questions sits unbuilt: a prototype.
Making mistakes quickly in order to learn must be the primary objective in the prototyping process, according to Talentgarden. A prototype reveals what’s feasible, what’s problematic, and what you completely misunderstood about the problem. It separates dreams from achievable innovation.
Consider the mathematics. You can fund the digital Agile teams to do two to three pilots per year. Against the odd of say 90% failure, how long before you’ve transformed anything meaningful?
Now run the alternative scenario. Rapid prototyping provides a framework that is lower-risk, lower-cost, lower-commitment, and helps to justify and prioritise product development initiatives (383 Group). What if you could run ten quick, cheap prototypes? Kill seven fast. Refine the remaining three. Scale one.
The constraint isn’t just budget. It’s speed and the know-how (organisations can buy the know-how). If you’re not failing, you’re not going to innovate. But you need to fail fast and economically that you can still afford to succeed.
Most organisations build Cadillacs when they should be building skateboards. Your first prototype doesn’t need enterprise architecture, full security reviews, or integration with every legacy system. It needs to answer one question: does this approach actually work for the specific problem we’re trying to solve?
Innovate Everything, Including How You Innovate
I’ve watched innovation teams follow the same bureaucratic processes they’re supposed to be disrupting. Monthly steering committees. Stage gate approvals. The same meeting cadence as legacy projects.
If your job title is Innovation Lead but you’re still running innovations through the standard project management playbook, you’re not leading innovation. You’re managing compliance with creative window dressing.
Companies leading digital transformation create an agile mindset by executing initiatives through innovation teams with a fail fast approach (Deloitte). That means innovating the tools, the culture, and the process itself.
Maybe you don’t need that monthly meeting. Maybe you need a swamp communication network, where everyone talks to one another without scheduling 45 minutes to discuss what could have been a Teams message. Are you aware of what your team has been up to without calling a meeting? If the answer is no, the problem isn’t frequency of meetings. It’s flow of information.
Maybe you don’t need the three-tier approval structure. Most business processes are sequential because that’s how we’ve always done it, which is the seven most expensive words in any organisation. Maybe it’s time you solve problems with parallel processes.
And the harder truth: if the project lead isn’t getting their hands dirty solving problems, you’re doing it wrong. Leaders who’ve never built anything tend to treat all technologies as commoditised and interchangeable. They don’t understand why things break, where complexity hides, or what separates vendors who’ve solved the hard problems from those with impressive sales decks.
Innovation leadership means understanding the problem at the technical level. Not every detail, but enough to ask the right questions, spot the gaps and be the gel for the team. That requires being in the prototype, testing it, breaking it, understanding why it failed.
Fail Fast Needs Learn Faster
70% of digital transformation initiatives failed to go beyond the pilot stage (Incentrik). Most organisations treated this as a technology problem. It’s not. It’s a learning problem, which is considerably harder to solve because you can’t just go with a different vendor.
Every pilot generates data. Not only whether the technology works, but also organisational readiness, data quality issues, integration challenges, user adoption barriers, and hidden dependencies. You paid for those lessons whether the pilot succeeded or failed. Make sure you and your organisation learned them, rather than filing them under the “lessons learned” folder.
The Fail Fast principle enables you to gather user feedback early and often, then refine and adjust features in alignment with actual user needs and market demands (UpTop). But learning fast requires deliberate practice. After each pilot, what changed about your approach? What assumptions proved wrong? What problems emerged that you’ll design around next time?
Technologies move fast. Something that isn’t feasible today might break through tomorrow. An approach that isn’t economic today could be the winner in 18 months. But you’ll only recognise those inflection points if you maintained visibility on the technology.
This is why killing pilots matters as much as running them. When you abandon an approach, document why. Why did your Integrated Network Models for 1000s of wells not meet expectations? Accuracy? Speed? Maybe both? Or maybe the model is simply technically impressive but operationally useless?.
Elon Musk relies on iterations and the concept of failing fast in order to succeed sooner GlobalSpec). Shortly after the first SpaceX Starship prototype broke apart during a pressurization test in November 2019, after the previous four test rockets exploded over the course of several months, SpaceX launched and landed a Starship rocket safely for the first time (GlobalSpec). That was prototype number 15.
The difference wasn’t that SpaceX finally got lucky. It’s that they learned from prototypes one through fourteen fast enough to build fifteen.
Innovate like Thomas Edison
As Thomas Edison famously said “I have not failed. I’ve just found 10,000 ways that won’t work”. Admittedly, most organisations don’t have Edison’s budget or patience, but the principle holds.
If you can only afford to try a few things, you’d better be right most of the time. But if you’re right most of the time without trying lots of things first, you’re not doing innovation. You’re doing incremental improvement with ambitious PowerPoints and perhaps some inspirational stock photos of people pointing at whiteboards.
Now imagine: your competitors run 15 prototypes while you’re still getting approval for number two. They learn what doesn’t work. They find what does. They scale it. Meanwhile, you’ve got a beautifully documented business case for an approach that would have worked 18 months ago. Then another 18 months pass, a committee meets to discuss why innovation didn’t deliver results.
The way out isn’t more rigorous upfront gated processes and guardrails. It’s cheaper, faster prototypes that fail loudly enough to teach you something, and an organisation capable of learning from them before the technology landscape shifts again.
How many prototypes did you kill last quarter? If the answer is zero, you’re either incredibly lucky or not actually innovating. My money’s on the latter.
#FailFast #LearnFaster #DataDrivenInnovation #DigitalTransformation