The adoption of software has been driving more efficient field operations for some oil and gas companies yielding OPEX savings, boosting production and ensuring compliance. This trend is leading other producers to evaluate operations technology – assessing whether to build or buy it. Many development managers and production and operations executives are building business cases, and looking to learn from operations technology rollouts that failed in the past. 

We chatted with Nic Lefebvre, Chief Product Officer and Co-founder of EZ Ops, on how to calculate the true cost of building oil and gas field operations software and what considerations make in-house development a fit, or not. 

Is there a scenario where building your own software makes sense? 

Absolutely. Build makes sense if nothing on the market solves your needs, and developing software is truly core to your business. Generally that means you are one of a few major producers with a full stack development team including interface design. It’s a common blind spot to underestimate ease-of-use among field operators. Ask: does your team have usability design strength internally? And do you also have teams that will do in-the-field implementation, training and provide support? If you check all those boxes, and have the budget to maintain the software over 5 plus years, then build is a viable option.

What do you hear from people who have built their own operations technology? 

The software is 100% custom, which sounds appealing, but you lose out on borrowing knowledge of other producers and can get deep into use cases that exist today. It’s also costly. We’ve yet to meet anyone who’s invested less than $10M and that’s before maintenance.

It really comes down to an honest assessment of the strengths and weaknesses of your in-house development team. Be careful not to overestimate your capabilities, for example, what the team knows about building APIs and connections to other apps and data.

What do you find challenging when developing software for oil and gas field operations? 

The hardest part of developing oil and gas field operations software is creating a product that works for the different operating realities and team behaviours. Plant to plant operations can vary significantly with different team members running different assets – even within one company. There’s also data inconsistency across plants or assets. Many operators use Excel spreadsheets without standard conventions or labeling and information can easily be lost. No software is going to eradicate these inconsistencies – it needs to work with them.

What’s essential to successfully develop field operations software in-house? 

Access to end-users. The field operations team will be using the product, so you need to get input directly from them and observe their practical realities of weather, mud, offline work, chaotic schedules, and so on. Operations software needs to be built on an understanding of real field operator user behaviour, which is unlike your day to day or anyone in head office.

How do you get development requirements and user input from field operations teams?

You’ll need direct input from users with boots on the ground early in the development process. Unfortunately, a development manager showing up in the field and asking questions won’t get you there. 

It often works to engage operations management, like a foreman as well as one or two field guys willing to look more often at stuff. The foreman will act as your liaison to gather field worker requirements as you eavesdrop. They will serve as a translator, formulating the right questions to help development get valid direction. 

Then back to the field with early feature testing, and build up to a full pilot. You need to guarantee that the trial of your full product in the field goes well – there’s no second shot at getting adoption if the operations teams hate it then.

If you were tasked to calculate the cost to develop field operations software today – how would you do it?

Well, every development team has records of historic costs to build solutions to draw from. I can share some of my own ballparks below. But you can’t just look backwards right now.

How the oil and gas industry operates is at a turning point. Producers are being challenged to demonstrate cost efficiency and commitment to cleaner energy, but we are at the limit of asking workers to do more with so much data and communication coming at them. 

That brings us to Industry 5.0 where we need to equip people with smart machines to help them better perform. The cost to build an ML/AI enabled platform is much higher, and now you need data scientists, and often different IT infrastructure, but every developer needs to avoid the risk of building something immediately obsolete. 

Sometimes executives tell development teams to build a custom solution – they don’t ask if it’s smart. How do you constructively provide feedback?

The best way is often to provide a true cost calculation to build and maintain the solution along with options/costs of what’s available on the market, and what industry peers are using.  Just do this as part of your due diligence in dev planning. Provide both options and avoid the trap of sunk costs “we’ve already invested so much into the project, just keep going” mindset. 

A word of caution here. Even if you already have a set of requirements from your boss to develop operations technology to reduce operating costs or streamline compliance monitoring or standardize production optimization – be open to expanding that list. Consult with field teams early on their day-to-day pains to ensure that what you budget fits their reality.

Why consider off-the-shelf field operations software when building custom can mean job security for dev teams?

Haha – we can all have job security and more satisfying work than building spiderweb code that we are hostage to maintain. I wasn’t always with EZ Ops and there are times when a narrow-scope application makes total sense to build in-house for producers. But producers don’t always have time or excess capital to invest in product development roadblocks. 

In the early stages of building EZ Ops we guessed wrong on how much flexibility we’d need in certain workflows and had to rebuild. When you buy software – costs like that are offloaded. If there’s someone five years ahead of you, with a long term vision, consider their product.

For field operations software, EZ Ops provides an affordable solution trusted by 10% of Canada’s E&P companies with a 100% adoption record in the field.  Our new platform is utilizing machine learning and AI to synthesize vast data and prioritize the highest-value tasks up for every role in operations. We’d be glad to give you a tour.  

About Nic Lefebvre, Chief Product Officer

As the Chief Product Officer, Nic leads EZ Ops rapidly-growing team of software developers, data scientists, and design and usability experts. Nic and the product team bring industry-leading machine learning and AI, data analytics, and geospatial technology to the EZ Ops operations intelligence platform to equip producers to meet or exceed production and environmental goals reliably. Nic has applied his product expertise to architect and build EZ Ops from the very beginning, resulting in the industry’s most advanced SaaS-based operations platform.

Previous post:

An operator’s Basic Guide to better oil and gas operations scheduling

Next post:

Take the guesswork out of field operations. Lessons from an operator.