Management by exception is the operating model behind every credible field-efficiency number published this decade, and most implementations of it still stall. This guide covers what the model actually requires (four things, not forty), why the stall happens (alarm floods, exceptions with no dollar figure, a field that stopped trusting the plan), the two starting positions operators arrive from, and the productized path that gets a ranked plan into the truck cab in weeks instead of quarters.
What Management by Exception Actually Requires
The operating model of management by exception is the one where the field organization stops working a fixed calendar and starts working the deviations that matter, ranked by what each one is worth. The pumper route is built from the overnight signal, not from the day of the week. The workover schedule is built from the failure forecast, not from the failure. The superintendent's morning is spent adjudicating the top of a ranked list, not rebuilding a spreadsheet.
Stated that way, the model sounds like a software purchase. It is not. It is an operating change with four hard requirements, and every stalled implementation we have walked into was missing at least one of them.
Requirement one: a data foundation, which you already own. The signal that drives the model is in the SCADA or the historian, the production accounting system, and the EAM or CMMS. Read-first integration onto those systems is the foundation. A data lake is not. A sensor refresh is not. The operators that published the strongest exception-based results, including the deployments Alvarez & Marsal documented when it put the canonical numbers on exception-based surveillance in 2015, ran on the instrumentation they already had.
Requirement two: exception definitions that carry economic context. An exception without a dollar figure attached is an alarm, and every operator already has more alarms than the field can answer. A working exception definition reads like this: deferred production at risk on this well, at this working interest, at this strip, net of the truck roll it takes to respond. When exceptions carry dollars, a 350 BOPD well drifting 8% off forecast outranks a threshold trip on a 30 BOPD well. When they do not, the two look identical, and the field learns to ignore both.
Requirement three: a ranked plan the field will actually run. The output of the model has to land in the truck cab as a drivable day, sequenced against real constraints: crew qualifications, geography, hours of service, which lease roads are passable this week. A ranked list that ignores those constraints is a report, and reports get reviewed in the office on Friday while the pumper runs the same fixed route on Tuesday. In WellOPS, this is Willie's job: Willie builds the ranked plan your pumpers run, and takes the field update back by voice so nobody types at a windshield.
Requirement four: closed-loop feedback. When the pumper finds the backside leak on the well the score flagged, or finds nothing at all, that outcome has to flow back into the model before tomorrow's ranking runs. Without the loop, the plan is exactly as wrong next month as it is today, and the field notices. With the loop, the plan gets sharper every shift, and the field notices that too.
What Management by Exception Is Not
Half the stalled implementations we see began as something adjacent that got sold under the same name. Three impostors are worth naming before the build starts.
It is not a dashboard project. A surveillance screen in the office is exception reporting, and exception reporting changes nothing until it changes how the pumper's Tuesday gets built. If the deviation still travels to the field by phone call and sticky note, the operating model has not changed, no matter what the screen cost.
It is not an alarm system upgrade. Adding smarter thresholds to the same flood produces a smarter flood. The constraint was never detection. Most operators already detect far more than the field can answer. The constraint is ranking, routing, and feedback, and no alarm package ships those.
It is not a headcount play. The published exception-based results, including the reference deployment below, were delivered on the same crew. The model does not remove people from the field. It removes low-value truck rolls from their day and puts the recovered hours on the wells where the money is. Selling it internally as a staffing cut is the fastest known way to guarantee the field kills it.
Want case studies and benchmarks like these?
For upstream + midstream operations leaders. Share your work email and our team will follow up with case studies, benchmarks, and what's changing in the field.
Why Implementations Stall
The management-by-exception idea has been in the industry for decades, and the graveyard of stalled implementations is large enough that most operations VPs have personally buried one. The failure modes are consistent.
The alarm flood. The first-generation implementation, pump by exception, wired SCADA thresholds to a callout list. The result at most operators is 200-plus alarms a day with no ranking, no economic context, and no dedupe. Pumpers numb out. The real exception drowns in the flood, and the operating model quietly reverts to the fixed route because at least the fixed route is drivable.
All exceptions look equal. Without economic scoring, the exception list is sorted by timestamp or by severity codes an engineer set five years ago. The field cannot tell the $2,000-a-day deviation from the $20-a-day one, so it works them in windshield order. The unit operating cost does not move, and leadership concludes the model does not work. The model was never actually running.
The field stopped trusting the plan. A ranked plan that is wrong three mornings in a row, that routes a crew past a tank it knows is about to run over, or that ignores the road ban every pumper knows about, loses the field permanently. Trust is a track record. Implementations that lead with mandates instead of adoption evidence spend their credibility before the model has a chance to earn any.
The mid-journey stall. This is the large-operator version. The surveillance team was built, the engineers write exception logic, the dashboard shipped, and the field never changed how the route gets built. The deviation gets detected in the office and still travels to the field by phone call, sticky note, and hallway conversation. The MIT finding that 95% of GenAI pilots fail to deliver measurable P&L impact, and McKinsey's observation that roughly 70% of oil and gas operators remain stuck in pilot phase, are both describing this stall: detection without execution, a model that never reached the truck cab.
Starting Position One: The Large Operator Stuck Mid-Journey
If you run a large operation, the odds are you are not starting management by exception. You are restarting it. The surveillance investment exists. The exception reports exist. What is missing is the back half of the loop: economic ranking, constraint-aware routing, and the feedback path from the field.
The rescue pattern that works keeps everything already built. The historian tags, the exception logic, the engineering hours already sunk into surveillance all stay. What gets added is the layer the original build never got to: every open exception scored in dollars, sequenced into a drivable plan, delivered to the crew that will run it, with the outcome captured the same day.
The field-resistance problem gets solved the same way it has always been solved in the field: by being right. Start on one field with one crew that opted in. Publish the plan next to the old route and let the results argue. When the ranked plan finds the deferment the fixed route would have missed by three days, the crew on the next field asks for it. Mandates produce compliance theater. Track records produce adoption.
Starting Position Two: The Small Operator Starting From Spreadsheets
If you run a smaller operation, the starting position is different and, honestly, simpler. There is no half-built surveillance program to rescue and no internal faction defending it. The morning plan lives in a spreadsheet, a phone tree, and the superintendent's memory, and all three are working harder every quarter.
The mistake at this starting position is believing the vendors who say the prerequisite is an infrastructure project: a data team, a warehouse, an 18-month integration roadmap. The prerequisite is the data you already generate. SCADA if you have it, gauge sheets and production accounting if you do not. The scoring runs on what exists, and the data quality improves as a byproduct of operating on it, which is the same order of operations the large operators that succeeded actually followed.
The full playbook for this starting position is in how to start management by exception without a data team. The compressed version: one module, one field, one signed metric, four weeks.
Sequencing: Deploy the Loop, Not the Layers
The classic implementation mistake is sequencing the four requirements as phases: integrate everything this year, define exceptions next year, touch the field workflow the year after. That sequence is how a two-year roadmap becomes a mid-journey stall, because value only shows up when the loop closes, and the loop is the last thing on the roadmap.
The sequencing that works inverts it: deploy a thin version of the whole loop on a narrow scope, then widen. One field's worth of wells, integrated read-only, scored in dollars, sequenced into a route, with outcomes captured. Every requirement is live in week three, at small scale, and the operating model is producing evidence while the rollout is still young.
Narrow-then-widen also solves the political problem that kills wide-then-deep. A thin full loop on one field produces a number a controller can check: deferment caught, truck rolls avoided, response time cut. A wide integration layer with no loop produces a status update. Numbers survive budget season. Status updates do not.
The other sequencing decision is where the exception definitions come from. Do not convene a committee to write the perfect exception library up front. Start with the deviations the field already chases (downs, off-forecast drift, tank levels, failed communications), attach dollars to those, and let the closed loop grow the library from what the crews actually find. The committee version is six months of meetings. The closed-loop version is running in week three and sharper every shift after.
The Productized Path: Weeks, Not Quarters
The reason implementations used to take quarters is that every operator was assembling the model from parts: an alarming project here, a routing pilot there, a BI layer on top, and a change-management program to force the field to use all three. The reason it now takes weeks is that the assembled version exists as a product. This is what WorkSync productized in WellOPS: the scoring, the routing, the field surface, and the learning loop, pre-integrated, deployed one module and one field at a time.
The productized rollout follows a fixed shape. Week 0: the operations leader and the controller pick one metric and sign the threshold on one page. Week 1: read-only integration on the existing SCADA or historian, production accounting, and EAM. Weeks 2 and 3: the score runs nightly and the ranked plan is in the truck cab by 6 AM. Week 4: measure against the Week 0 baseline and decide. The Impact Guarantee carries the risk: we charge when your number moves, and the walk-away clause is in writing. Pricing is published, floors to approachable numbers, and the entry tier clears without a procurement committee.
The deployed reference for the full model is a top 25 private producer running 5,000+ wells across the Western Anadarko, Permian, and Wyoming: 15% FCF uplift on the same crew, 35% of site visits moved out of the field, TRIR from 1.8 to 0.3. Same wells, same people, different operating model.
The One-Page Checklist
Before you sign anything, including with us, walk your plan against the four requirements. Can you name the systems the model reads from, and is the integration read-only? Does every exception carry a dollar figure a controller would defend? Does the output land in the truck cab as a sequenced, constraint-aware day, or in a dashboard? And when the crew works the plan, does what they found change tomorrow's ranking?
Four yes answers and the implementation is a four-week exercise. Any no, and you are about to fund another stall.
See This on Your Data: a four-week management-by-exception pilot on the stack you already own. One module, one field, one signed metric. Walk-away clause in writing.