The Importance of the Business Case

At Intelligent Plant, we're fascinated by data and want to build tools that operators can use to improve production efficiency. We frequently speak with enthusiastic engineers who see real value in what we offer, and that enthusiasm is genuine. But it only goes so far. Without a business case, and without numbers showing the value a product will deliver to a single asset or a whole fleet, even the best idea can die quietly in a boardroom.

Example - The deal that had everything, except a business case

We were chatting at length with an engineer working for a major operator that was dealing with a real and expensive problem. They had subsea valves failing unpredictably, causing costly production interruptions. They asked if our valve testing software could help identify potential failures early enough that replacements could be scheduled during planned shutdowns rather than forced ones.

It absolutely could. The software was able to identify potential failures months in advance, with a clear difference between an unplanned shutdown costing a fortune and a routine bit of maintenance during a window that was happening anyway.

They were really excited about this. The plan was to prove it out on one asset in the North Sea, then roll it out across their wider fleet, eventually being implemented globally. From where the engineer was sitting, this was hook, line, and sinker - the benefits were obvious. Our team was excited too, with it looking like a significant order for us.

The engineer took the proposal to their leadership team, expecting quick approval.

It got rejected.

It wasn't because the technology didn't work, and not because anyone doubted the problem was real. It was rejected because there was no detailed business case behind it.

Their leadership team weren't being difficult for the sake of it, they needed to see the actual cost-benefit numbers before committing budget, and those numbers hadn't been put together.

The business case is the key differential between the solution that gets approved and the solution that gets rejected

When we asked what their own business case would need to include, we hit another wall - the data that would inform it was commercially sensitive, and they weren't in a position to share it with us.

It wasn't about their valves, or our software. It was more about the gap between "this is a good idea" and "here is the quantified cost-benefit case that justifies the spend."

Enthusiasm isn't a business case. A confident engineer who can see the value clearly still needs numbers that someone in finance or leadership can independently verify. Numbers such as what unplanned downtime currently costs, how often it happens, what the software costs to deploy and run, and what the realistic reduction in failures looks like once it's in place.

The reality is that the party best placed to build that business case is usually the operator itself, because they hold the commercially sensitive data (failure rates, downtime costs, maintenance budgets, etc) that a vendor like us doesn't have access to. We can bring the technology and the evidence that it works. We can't build someone else's internal cost-benefit case for them, because we don't have their numbers.

What this means in practice

If you're the engineer who can see the value clearly, the work doesn't stop at getting a vendor to prove the technology works. It includes translating that proof into your organisation's own financial terms, ideally before you take it to those with control of the budget. That means going in with your own downtime costs, maintenance budget context, and a clear estimate of the return, not just a demonstration that the tool does what it says.

And if you're the vendor, it's worth remembering that the most compelling product demo in the world doesn't remove the need for that internal work. Being ready to help build the business case, rather than assuming the value speaks for itself, is often the difference between a project that gets funded and one that quietly disappears after a promising first conversation.