The third in a four-part guide for domain experts navigating the full software buyer journey.
You’ve spotted the problem. You’ve looked at your options. Now comes the part that shapes everything else: writing your software requirements.
This is where a lot of energy teams quietly set themselves up to fail. Not out of carelessness. Out of habit. The safe instinct is to describe the current system. List what it does, document the workarounds, and fold all of it into the software requirements document.
The problem is that your workarounds come with you. If your team is emailing spreadsheets to reconcile volumes or raising IT tickets every time allocation logic needs updating, those constraints will survive the procurement process and land in whatever comes next.
The problem with familiar software requirements.
Legacy hydrocarbon accounting systems were designed for a different world. Static asset portfolios. Predictable reporting cycles. No real pressure to move quickly.
Your world probably looks different now. Assets come online or go offline overnight. Deferred production can skew allocations mid-month. New contracts mean rapid changes to equity splits and back-allocation logic. Regulators want faster reporting, full transparency, and zero tolerance for error.
If your software requirements are built around what you’ve always done, they’ll produce a system built around what you’ve always done.
Write software requirements for what you can actually do.
Here’s a better starting point: instead of documenting constraints, describe the outcome you want when the right system is in place.
When did you last wait weeks for a vendor to make a change you could describe in ten minutes? What would it mean to make that change yourself, the same day you needed it?
That’s the shift worth building software requirements around. Not features on a list. The freedom to adapt your system to your operations, rather than adapting your operations to your system.
In practice, that means asking different questions during scoping:
- Can domain experts update allocation logic directly, without waiting for a developer?
- Can new facilities or contracts go live in days rather than months?
- Can your team access validated data without reworking it in Excel first?
- Can the system scale as assets change, without a costly rebuild each time?
These aren’t feature requests. They’re the conditions that determine whether the system still works for you in three years.
What the shift looks like in practice.
After a major acquisition of North Sea assets, Harbour Energy found its existing production data management system couldn’t keep up. They needed high flexibility, automation, and a fast turnaround. The replacement went live within tight deadlines. When Harbour later merged with another company, the transition was handled within the same system, with no rebuild required.
That’s what software requirements written for change look like in practice. Not just a faster implementation. A system your own team can extend as your business moves.
What comes next.
In part four, we look at the questions that separate vendors who talk about flexibility from those who actually deliver it. Read part four.
