Industry and Organizational Context

This case examines a mid-scale manufacturing organization producing complex electromechanical products across multiple facilities. Engineering Change Orders (ECOs) are used to modify product designs, materials, specifications, or processes after initial release.

• ECOs originate from engineering, quality, suppliers, and operations.

• Approved ECOs affect design documentation, tooling, procurement, and production.

• Poor ECO handling creates cost overruns, rework, and delivery delays.

Leadership viewed ECO delays as an execution problem, but the deeper issue was inconsistent treatment of fundamentally different changes.

How the Work Was Intended to Function 

On paper, the ECO process was intended to operate as follows:

• An ECO is submitted with a description of the proposed change.

• Impact is reviewed by engineering and affected functions.

• Approvals are collected through a standard workflow.

• The change is implemented and released to production.

Leadership believed this single process was sufficient for all engineering changes.

What Was Actually Happening

In practice, ECO handling varied dramatically:

• Minor documentation fixes stalled behind major design changes.

• High-impact changes moved forward without adequate review.

• Teams disagreed on which ECOs required escalation.

• Production and procurement were surprised by downstream effects.

The problem was not the existence of an ECO process, but the absence of a shared way to interpret each change.

How FLOW Was Introduced

Leadership was not looking to redesign engineering governance. They were looking for a way to explain why ECO outcomes were inconsistent.

• A common language to distinguish simple changes from consequential ones.

• A way to prevent over-processing low-impact ECOs.

• A method to slow down changes that could affect multiple systems.

FLOW was introduced as a classification lens to evaluate individual ECOs before routing or approval.

Identifying the Unit of Effort

The organization anchored analysis on a single, stable unit:

• Unit of Effort: one engineering change order proposing a specific modification.

• Each ECO is evaluated independently.

• Batching, queues, and averages are not used for classification.

How Complexity Was Determined

Complexity was defined as the amount of technical and judgment-based uncertainty introduced by the change.

• Low complexity changes modify known parameters without altering system behavior.

• Higher complexity changes affect interfaces, tolerances, or interactions.

• Higher complexity changes require expert judgment or tradeoff analysis.

• Higher complexity changes increase the risk of unintended consequences.

How Scale Was Determined

Scale was defined by the breadth of organizational and system impact caused by a single ECO.

• Number of parts, assemblies, or documents affected.

• Number of functional areas impacted.

• Degree of downstream disruption if the change is wrong or late.

Other Measures of Scale Considered

Several alternative indicators were considered but rejected for classification:

• Cost delta associated with the change.

• Number of units already built.

• Schedule urgency.

Applying FLOW to Real Engineering Change Orders

Each ECO was classified using the same logic:

• Determine technical complexity.

• Determine impact scale.

• Assign a single FLOW classification.

FLOW A — Local, Contained Changes

Example: correcting a drawing note or tolerance typo.

• Complexity: low.

• Scale: low.

• Handling implication: fast approval with minimal review.

FLOW B — Broader Operational Impact Changes

Example: substituting an equivalent material across multiple subassemblies.

• Complexity: low.

• Scale: moderate.

• Handling implication: coordinated review without deep technical escalation.

FLOW C — Complex, Judgment-Driven Changes 

Example: redesigning a component to address a recurring field failure.

• Complexity: high.

• Scale: low-to-moderate.

• Handling implication: deliberate analysis before release.

FLOW D — System-Level Changes

Example: architectural changes affecting core product platforms.

• Complexity: variable.

• Scale: high.

• Handling implication: formal governance and sequencing. 

FLOW S — Exceptional Changes

Example: emergency safety or regulatory-driven changes.

• Normal routing is inappropriate.

• Explicit exception handling is required.

What Changed After FLOW Classification 

Once ECOs were consistently classified:

• Low-impact changes moved quickly.

• High-impact changes received visibility.

• Downstream surprises decreased. 

Organizational Implications 

FLOW classification reshaped engineering governance:

• Escalation tied to impact, not authority.

• Review effort matched the nature of the change.

• The ECO process became explainable.