Why One-Size-Fits-All Processes Fail Maintenance

Written on: July 08, 2026

THE REAL COST OF WORK

In one week, I watched two completely different events get shoved through the exact same process.

At one site, a 10-hour outage to swap a single critical valve had to clear the full corporate turnaround gate model. Multi-week deliverables. Thick checklists. Reviews built for a 30-day shutdown, all of it landing on a one-shift job.

At another site, a multi-week outage with major inspections and capital tie-ins was being run on the same light-touch routine we use for weekly maintenance. A few planning meetings. Some spreadsheets. A basic schedule. No real readiness checks. No structured risk review.

Two events, opposite ends of the complexity scale, and neither one had a process that fit.

We'd done what a lot of organizations do. We standardized by building one process and stamping it on everything. The intent was consistency, which is a good intent. The effect in the field was not.

Standardization Is Not Sameness
Let me be clear up front. I believe in standardization.

Common language, common templates, and common expectations: you need all of it to lift maintenance and turnaround performance across a fleet of sites. Without some standard, every site invents its own universe and you can't learn, compare, or improve anything systematically.

But somewhere along the line, "standard" quietly gets read as "same." Same process steps for every event. Same required documents. Same planning depth. Same governance cadence, whether it's a corrective job or a month-long shutdown.

That's where it goes wrong. A small corrective task, a mini-outage, and a major turnaround are not the same kind of problem, and they don't deserve the same amount of process. Standardization should mean consistent principles: how you think about risk, readiness, and roles. It was never supposed to mean identical procedures for every situation.

Different Work, Different Complexity
Picture three broad buckets of work you see in almost any plant. Routine daily and weekly maintenance: regular PMs and small corrective tasks, usually done with the unit running. Small outages and minor projects: single-system events measured in hours or a few days, with contained scope. Major STOs and capital tie-ins: multi-week beasts loaded with inspections, repairs, modifications, and serious integration risk.

They don't behave alike, so they can't be run alike.

Daily maintenance lives on flow and responsiveness. It needs just enough structure to prioritize and coordinate, and not one ounce more. Make routine work jump through turnaround-sized hoops and people will either stop doing it or quietly route around the process entirely.

Small outages sit in the awkward middle. Too big to wing, too small to deserve the full turnaround machine. They need somebody thinking hard about constraints, access, and interactions. They don't need a three-inch binder.

Major STOs are their own animal. High asset and production risk. Heavy scope and work-mix complexity. A small army of contractors and vendors. Stacks of concurrent work crammed into tight space. Push that through a daily-maintenance process and you've signed up for surprises and overruns. Same company, same assets, wildly different complexity. They earn different ways of working.

The Symptoms of One-Size-Fits-All
Force one process onto everything and the symptoms show up fast, at both ends.

On the small work, you get over-bureaucracy. Too many approvals, too many forms, too much lead time for a job that should take an afternoon. So crews build a shadow process, the way we really do it, while feeding the official one just enough to keep it quiet. Operations stops believing maintenance can move at plant speed, and more work slips off the books.

On the big work, the failure runs the other direction. The same generic templates and reviews that smother a small job leave a major event under-planned. Readiness checklists get ticked without ever testing whether the prep is deep enough for the risk. And governance stays vague, so the hard calls during execution get made on the fly because nobody ever defined who owns what under pressure.

The cultural damage is the worst part. People learn the wrong lesson: the process is something you survive, not something that helps you.

Match the Rigor to the Complexity
The fix isn't to throw out the process. It's tiered rigor. Keep the consistent principles and language, and scale the expectations to the complexity in front of you. The simplest version is a few tiers:
  • Tier 1, simple and low risk. Routine jobs where a slip or failure costs little. Lightweight planning, minimal paperwork, fast approvals. Get out of the crew's way.
  • Tier 2, moderate complexity. Small outages and bigger jobs. Standard planning, some field validation, a few targeted readiness checks, and roles that are actually defined.
  • Tier 3, high complexity and high risk. Major STOs, complex outages, capital tie-ins. Full planning rigor, multi-discipline reviews, formal readiness gates, and real governance during execution.
The trick is a quick, honest way to drop an event into a tier. A short set of questions about scope, risk, and concurrency usually does it. Once you know the tier, you know how much process you need. Now your standard isn't "same process for everything." It's "same logic for matching rigor to complexity." That's a standard worth keeping.

Right-Sizing Without a Rebuild
You don't have to tear the whole system down to start. A few moves carry most of the value.

Build a simple complexity check, five to ten questions anyone can answer about an event's size, risk, and constraints, and use the result to set the tier. Define a playbook for each tier so "good enough" is spelled out: planning detail, required reviews, readiness checks, documentation. Pin down governance by tier, because who can change scope, who authorizes a deviation, and how often you review progress should all be heavier at Tier 3 than Tier 1. Then pilot it on one site or one class of work, and let the results make the case: less friction on the simple jobs, better outcomes on the complex ones.

This is a lot of what we do with clients. Not handing them a thicker binder. Helping them build the logic that decides how much process a given event actually earns, so the simple work moves fast and the hard work gets the scrutiny it needs.

The Bottom Line
When your process doesn't match your complexity, good people do one of two things. They fight the system, or they quietly go around it. Neither one lasts, and both bury risk.
Standardization matters. But the standard you actually want isn't "everyone follows the same process." It's "we always match the rigor of the process to the complexity and risk of the work." One of those smothers your simple jobs and starves your hard ones. The other fits.

Next in the series, we cross back to the debt side and follow it onto the plant floor. All this mismatched process and quiet borrowing surfaces somewhere eventually: in the bad actors everyone can name, the budget that lurches from cheap years to brutal ones, and the failures that look like mysteries until you read the history.

John Crager is Principal Advisor at APVantage LLC. He has spent more than 30 years in industrial maintenance, capital project, and turnaround operations.

APVantage helps industrial organizations optimize their maintenance execution practices by helping teams not only understand the problem but develop solutions that actually fit their unique situations.

Interested in learning more?

Contact us today to discuss the details of your project or maintenance event needs. We look forward to working with you.

Contact Via Email
Call Us at +1 832-240-4994