Industry and Organizational Context

This case examines a mid-scale manufacturing firm operating multiple domestic facilities. Procurement supports production, engineering, IT, facilities, and maintenance. Thousands of purchase requests are initiated annually by supervisors, engineers, and managers.

• Policies existed, but day-to-day execution varied by team and urgency. 

• Escalation behavior substituted for clear classification.

• Cycle time and outcomes were inconsistent even for seemingly similar requests.

Leadership wanted efficiency, but the deeper problem was that requests were being treated as equivalent when they were not.

How the Work Was Intended to Function 

Leadership believed the purchase request process operated as follows: 

• Requesters submitted a standardized intake form.

• Approvals were routed based on predefined policy thresholds.

• Procurement sourced items and coordinated fulfillment.

• Exceptions were rare and clearly defined. 

From an executive viewpoint, the system appeared predictable and controlled. 

What Was Actually Happening

Observed reality diverged materially:

• Requests with similar characteristics experienced very different cycle times.

• Escalations occurred without shared criteria.

• Teams developed informal workarounds to get things through.

• Approval paths were bypassed to avoid perceived delays.

• Confidence in procurement eroded across operating teams.

The underlying issue was the absence of a shared way to interpret individual requests.

How FLOW Was Introduced

Leadership sought a way to understand inconsistency without redesigning procurement. Specifically, they wanted:

• A common language to describe why requests behaved differently.

• A method to separate prioritization from urgency.

• A lens focused on individual decisions rather than averages.

FLOW was introduced as a classification lens to diagnose work before attempting optimization.

Identifying the Unit of Effort

The organization shifted analysis away from queues and averages and toward a single, stable unit of work:

• Unit of Effort: One purchase request requesting approval and fulfillment of a specific good or service.

• Each request is evaluated independently.

• Backlog size and throughput metrics 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 evaluate and fulfill a request.

• Low complexity: clear specifications and standard sourcing paths.

• Higher complexity: ambiguous requirements that require interpretation.

• Higher complexity: real tradeoffs between viable options.

• Higher complexity: specialized or cross-functional expertise required.

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

How Scale Was Determined

Scale was defined as the breadth of organizational impact created by a single purchase request (not the dollar value).

• Number of functional areas affected by the request’s outcome.

• Degree of downstream dependency created if the request is delayed or wrong.

• Coordination and visibility required to execute cleanly.

Requests impacting one team were treated as low scale; requests impacting multiple areas were treated as higher scale.

Other Measures of Scale Considered

The organization considered other scale indicators, but set them aside for this case because they were inconsistent predictors of impact breadth:

• Dollar value of the purchase request.

• Quantity of items ordered.

• Urgency or deadline pressure.

These measures can still be tracked operationally, but they were not used as the primary definition of scale in this walkthrough.

Applying FLOW to Real Purchase Requests

With complexity and scale definitions fixed, each individual purchase request was classified using the same logic:

• Classify complexity first (judgment required).

• Classify scale second (impact breadth).

• Assign the single FLOW classification that best fits the unit.

FLOW A — Local, Contained Requests

Example: standard office supplies for one department.

• Complexity: low (clear specifications; standard supplier options).

• Scale: low (impact contained to a single team).

• Handling implication: minimal oversight; fast routing is appropriate. 

FLOW B — Broader Operational Impact Requests

Example: a replacement component needed to keep a production line operating.

• Complexity: low (the item is known; the sourcing path is standard).

• Scale: moderate (multiple teams depend on the outcome; downstream impact is visible).

• Handling implication: greater visibility and coordination, even though the request itself is straightforward.

FLOW C — Complex, Judgment-Driven Requests 

Example: specialized equipment with unclear or evolving specifications. • Complexity: high (interpretation, tradeoffs, and expertise are required).

• Scale: low-to-moderate (impact breadth may be limited, but wrong decisions are costly). 

• Handling implication: slow down for analysis; speed-first handling increases rework and risk. 

FLOW D — System-Level Impact Requests

Example: a capital purchase supporting a multi-year expansion program. 

• Complexity: can be low or high (procedures may be standard). 

• Scale: high (organization-wide dependency; constraints on future options). 

• Handling implication: elevated governance and sequencing due to impact breadth. 

FLOW S — Exceptional Requests

Example: emergency safety-critical purchases or regulatory mandates. 

• Complexity and scale vary, but normal routing is inappropriate. 

• Handling implication: explicit exception handling with accountability under urgency. 

• Key risk: bypassing controls without a defined exception pathway. 

What Changed After FLOW Classification 

Once requests were classified consistently, execution stabilized: 

• Prioritization disagreements decreased because impact was visible and shared. 

• FLOW A work moved faster without unnecessary escalation. 

• FLOW C work received the judgment it required, reducing rework and risk. 

• FLOW D work gained governance appropriate to its systemic impact. 

Organizational Implications 

Over time, the classification lens reshaped how leaders and operators coordinated: 

• Escalation became purposeful and tied to impact breadth. 

• Ownership aligned to the type of request, not to who shouted loudest. • Trust improved because the system became explainable.