Industry and Organizational Context

This case examines a multi-site industrial organization where uptime is the primary constraint. Maintenance work is initiated through maintenance work authorizations (MWAs) that approve a specific maintenance action on a specific asset.

• Maintenance requests originate from operators, supervisors, reliability engineers, and safety teams.

• Authorized work competes for scarce resources such as technicians, parts, permits, and outage windows.

• Poor authorization discipline creates preventable downtime, rework, and safety exposure.

Leadership initially framed the problem as “maintenance backlog,” but the operational pain came from inconsistent handling of different kinds of work authorizations.

How the Work Was Intended to Function 

On paper, the maintenance work authorization process was intended to operate as follows:

• A request is submitted describing the asset issue and desired work.

• Maintenance planning reviews the request for completeness and feasibility.

• Approvals are collected based on safety, operational impact, and required permits.

• Work is scheduled, executed, closed out, and documented.

Leadership believed a single standardized workflow could reliably handle the full range of maintenance work.

What Was Actually Happening

In practice, authorizations behaved unpredictably:

• Low-impact work stalled behind high-impact items with unclear rationale.

• High-impact work was sometimes pushed through with insufficient hazard review.

• Operations and maintenance disagreed on what should be expedited versus deferred.

• Scheduling meetings became negotiation forums rather than decision forums.

• Technicians arrived at jobs without the right parts, permits, or isolation plans.

The failure mode was not a missing process. The failure mode was misclassification of individual work authorizations.

How FLOW Was Introduced

Leadership did not start by rewriting the maintenance program. They started by asking why “the same” authorization could produce wildly different outcomes. Specifically, they wanted:

• A shared language to distinguish simple maintenance from consequential maintenance.

• A way to stop over-governing low-impact work while under-governing high-impact work.

• A consistent basis for escalation that did not depend on who was asking.

FLOW was introduced as a classification lens to evaluate each individual authorization before routing, scheduling, or escalation.

Identifying the Unit of Effort

Instead of optimizing teams or backlog totals, the organization anchored on one stable unit of work:

• Unit of Effort: one maintenance work authorization approving a specific maintenance action on a specific asset.

• Each authorization is evaluated independently.

• Counts of requests and backlog volume are tracked separately, but they are not used to classify the unit.

How Complexity Was Determined

In this case, complexity was defined strictly as the amount of judgment required to plan and execute the work safely and correctly.

• Low complexity work has known steps, known hazards, and standard task plans.

• Higher complexity work involves uncertainty in failure mode, access, isolation, or verification.

• Higher complexity work requires tradeoffs, expert judgment, or iterative diagnosis.

• Higher complexity work increases the chance of unintended consequences during execution.

This definition of complexity was applied uniformly across all FLOW levels in this case.

How Scale Was Determined

Scale was defined as the breadth of operational impact created by a single maintenance work authorization. In this case, scale was not defined by cost. It was defined by impact reach.

• Number of operating areas affected by taking the asset down or restricting its use.

• Degree of downstream dependency affected by the asset’s availability.

• Coordination and visibility required to execute without disrupting production.

Work affecting one local area was treated as low scale. Work affecting multiple areas or critical throughput was treated as higher scale.

Other Measures of Scale Considered

The organization considered alternative indicators, but did not use them as the primary definition of scale in this walkthrough:

• Estimated labor hours for the job.

• Parts cost or contract cost.

• Urgency language used by the requester.

These measures were still useful for scheduling and budgeting, but they were inconsistent predictors of operational impact breadth.

Applying FLOW to Real Maintenance Work Authorizations

With complexity and scale definitions fixed, each authorization was classified before scheduling decisions were made:

• Determine complexity first (judgment required).

• Determine scale second (impact breadth).

• Assign a single FLOW classification that best fits the authorization.

FLOW A — Local, Contained Authorizations

Example: replacing a worn belt on a non-critical conveyor in a single work cell.

• Complexity: low (standard replacement procedure; known isolation steps).

• Scale: low (localized impact; alternative workarounds exist).

• Handling implication: fast authorization and standard scheduling without escalation.

FLOW B — Broader Operational Impact Authorizations

Example: replacing a standard motor on a shared conveyor that feeds multiple production lines.

• Complexity: low (known task; standard parts; standard lockout).

• Scale: moderate (multiple areas depend on the conveyor’s availability).

• Handling implication: coordination and visibility are required even though the task itself is straightforward.

FLOW C — Complex, Judgment-Driven Authorizations

Example: diagnosing and correcting intermittent vibration in a critical rotating asset with unclear root cause.

• Complexity: high (uncertain failure mode; diagnosis and tradeoffs required).

• Scale: low-to-moderate (impact may be localized, but wrong decisions risk repeat failure).

• Handling implication: slow down for diagnosis, verification, and expert review before execution.

FLOW D — System-Level Impact Authorizations

Example: planned shutdown work on a central utility system that affects every production area.

• Complexity: variable (tasks may be standard, but sequencing can be complex).

• Scale: high (organization-wide dependency and throughput impact).

• Handling implication: governance and sequencing are required due to impact breadth, not because the task is difficult.

FLOW S — Exceptional Authorizations

Example: emergency safety-critical work after an incident, where normal scheduling rules do not apply.

• Normal routing is inappropriate under urgent safety conditions.

• Exception handling must be explicit to preserve accountability.

• The key risk is bypassing controls without a defined emergency pathway.

What Changed After FLOW Classification

Once authorizations were classified consistently, execution stabilized:

• Low-impact work moved quickly without clogging planning meetings.

• Moderate-impact work gained visibility early enough to coordinate operations.

• Complex work received the judgment and verification it required.

• High-impact work was governed as a sequencing problem, not a speed problem.

Organizational Implications 

FLOW classification changed how operations and maintenance coordinated:

• Escalation became tied to impact breadth, not to personality or urgency language.

• Ownership aligned to the nature of the authorization and the coordination required.

• Maintenance planning shifted from negotiation to structured prioritization.