Walk into any oil and gas facility with a state of the art ERP system. Ask to see their well intervention schedule. Chances are, someone will sheepishly open a spreadsheet.
This was never about stubbornness or technophobia. It was about survival. And the reason said everything about why we built scheduling software that couldn’t beat Excel.
The constraint trap
When we designed scheduling systems, we thought the challenge was complexity. Operations had rules. Regulations. Dependencies. Resource limitations. So we built software that could handle constraints.
Lots of constraints.
“Crew A cannot work more than 14 days straight.” Encoded. “Rig 7 requires certified personnel only.” Encoded. “Minimum 12 hours between shifts.” Encoded. “Weather window required for offshore transfer.” Encoded.
We kept adding rules until the system captured operational reality. Or so we believed.
Then we wondered why schedulers kept a spreadsheet open on their second monitor. Why they treated the ERP output as a suggestion rather than a plan. Why the software that took eighteen months to configure was obsolete the moment operations changed.
We built a cage and called it a tool.
Constraints are not context
There was a difference between “Crew A cannot work more than 14 days straight” and “Crew A has been pushing hard, morale is shaky, and two of them have kids starting school next week.”
The first was a constraint. The second was context.
Traditional scheduling software could only digest the first. So we spent enormous effort translating rich operational reality into machine readable rules. We flattened judgment into logics. We converted experience into if-then statements.
The result was software that was technically correct and operationally useless.
I recalled standing on a workover site, telling a GM we would have a well online by end of week. Then a technician delivered the news: valves had failed fit for service. Repair kits from overseas might take two weeks. New valves would take two months.
Three paths opened. Order kits and hope. Order both kits and valves as insurance. Or wait for new valves and accept the delay. All three would have different schedules.
No constraint in our system captured “the commissioning team is already under pressure”, “technician is optimistic about repairing and delivery estimate” or “last time we rushed a valve job, we had a near miss.”
The rigidity paradox
We made scheduling software more sophisticated to handle more complexity. We added more constraints, more rules, more logic. And with each addition, the system became more brittle.
More constraints meant more interdependencies. More interdependencies meant more ways for a single change to cascade through the schedule. More cascades meant more time spent manually overriding the system when reality diverged from the model.
The software designed to handle complexity became the source of complexity.
Schedulers learned to work around it. They maintained shadow systems. They knew which constraints they could violate in practice even if the software would not allow it. They built relationships with operators who would tell them what was really happening on site, information that never made it into the system.
The ERP became a museum: a place to display the official version of the schedule after the real decisions had already been made elsewhere.
What context-aware scheduling looks like
Consider what happened when you handed a scheduling problem to an experienced operations coordinator. You did not start with giving them a constraint matrix. You gave them a situation.
“We need Wells 4, 7, and 12 back online. The workover rig finishes at Site B tomorrow. We are short one operator because Dave is on leave. The client is visiting Thursday, so nothing embarrassing at the main facility. Oh, and that supplier who promised parts last week still has not confirmed shipping.”
From that mess, a good scheduler produced something workable. Not mathematically optimal. But sensible. Defensible. Responsive to what actually mattered that week.
They did not solve a constraint satisfaction problem. They understood a situation and made a judgment. They knew which rules were hard and which were negotiable. They knew which stakeholders needed managing and which could be informed after the fact. They knew the difference between a deadline and a target.
That was context. And until recently, no software could work with it.
The shift that changes everything
What if we stopped trying to encode every possible rule and started describing the world instead?
What if scheduling software could weigh “we have had three HSE incidents this quarter” against “production targets are behind” without someone having to translate that into numerical weightings?
Building something that reasoned the way your best scheduler reasoned.
Software that could hold context, not just constraints. That could explain its suggestions in language you would use yourself. That could adapt when new information arrived without requiring a system reconfiguration.
The technology to work with abstraction exists now. Large language models can understand situational descriptions, weigh competing priorities, and generate recommendations that account for nuance. The question was not whether this was possible. The question was whether we would use it to build another constraint engine or something genuinely different.
The future is not more constraints
Your best scheduler already knew something the software vendors did not: the job was not just about optimisation. It was about judgment under uncertainty, communicated clearly, adapted continuously.
The AI that finally replaces their spreadsheet will not be the one with the most sophisticated solver. It will be the one that understands what they were actually doing in those cells.
And it will remember that a bad schedule was never just inefficiency. It was safety risk. It was production loss.
The future of scheduling is not more optimisation within constraints. It is optimisation with context.