Glossary

ECO (engineering change order)

An engineering change order (ECO) is a formally approved document that describes and authorizes a change to a product and its approved configuration documentation — the drawings, parts, and specifications that define a released design. It records what changes, why, which documents and departments are affected, who approved it, and when the change takes effect.

In one sentence

The moment a design is released, it stops belonging to engineering and starts belonging to everyone — the ECO is the control that keeps manufacturing, procurement, quality, and service all working from the same truth.

Why it matters

A change made without an ECO is a change nobody can trace — and untraceable changes are how factories build the wrong revision, purchasing orders obsolete parts, and field failures become unrepeatable mysteries. The ECO also draws the line between iteration and commitment: before release, engineers change things freely; after release, every change carries consequence, and the ECO is the mechanism that makes consequence explicit and approved.

How it works in practice

A typical ECO starts with a trigger: a component goes end-of-life, a field failure reveals a design weakness, a cost target demands a cheaper part, or a supplier changes a process. An engineer raises a change request describing the problem; once reviewed, the ECO is authored — then it routes for approval through the owning engineer, affected disciplines, manufacturing, and quality.

Example: a 10 µF capacitor on a motor-controller board goes end-of-life. The ECO lists the board part number, the schematic sheet, the PCB layout revision, and the BOM line. The replacement part has the same capacitance but a taller package, so the ECO also flags the mechanical enclosure clearance as an impacted item. Only then does the change become the new truth.

Common failure modes

The ECO lives in email. Approvals arrive as “looks good” replies scattered across threads. Months later, nobody can reconstruct who approved what, and the audit trail — the thing the ECO exists to create — doesn’t exist.

The ECO is approved but never fully implemented. The BOM is updated and the schematic is re-released, but the assembly drawing still shows the old part, or the Gerbers sent to the fab are one revision behind. Each artifact was changed; the set was not. This is the reconciliation tax compounding inside the change process itself.

Effectivity is ambiguous. “Cut in when convenient” means the factory builds a mix of old and new with no record of which serial numbers carry which change. When a field issue appears, the investigation starts from zero.

Emergency ECOs skip the process. A line-down situation gets a verbal approval and a promise to “paper it later.” Later never comes, and the undocumented change becomes tribal knowledge held by one engineer.

How ProductFlo handles it

ProductFlo treats the ECO as what it is: a proposed change to a shared product definition that must be validated before it commits. It builds a live graph over your schematics, firmware, CAD, and BOMs, and its automated ECR/ECO workflows track every design change with full traceability — impact analysis powered by the engineering graph, reviewed and approved before implementation. Agents watch the graph and flag cross-discipline impacts before a change ships, and every finding is routed to the right owner as a reviewable diff. Then the merge gate does its job: no hardware change ships until every affected discipline has been checked and a human has approved the diff. Agents propose diffs. Humans approve. No migration, no rip-and-replace — the ECO process stays, the archaeology goes away.

Questions about ECOs

What does an ECO contain?+
The affected part numbers and the drawings or documents that define them, the reason for the change in plain language, a description of the change, the departments and documents impacted, the disposition of existing inventory (use as-is, rework, or scrap), and the effectivity — when the change takes hold.
What is the difference between an ECO and an ECN?+
The ECO authorizes the change; the ECN broadcasts it. The change order is the approved document describing what changes and why. The engineering change notice tells procurement, manufacturing, quality, service, and often the customer that the approved change is now in effect.
Who approves an ECO?+
Typically the owning engineer, the affected disciplines, manufacturing, and quality, with a final sign-off from whoever owns the product line. The exact routing varies by company, but the principle is constant: every function the change touches gets a say before it becomes the new truth.
How does ProductFlo handle ECOs?+
ProductFlo treats the ECO as a proposed change to a shared product definition that must be validated before it commits. Automated ECR/ECO workflows track every change with full traceability, agents flag cross-discipline impacts as reviewable diffs, and the merge gate holds the change until every affected discipline is checked and a human approves.

Related concept

ECN →

The notice that broadcasts an approved ECO to every affected team.

The evidence

ECO methodology →

How we measure change performance: ECO cycle time, from trigger to released truth.

Eight definitions, zero marketing. Browse the full glossary.

All glossary terms →

Stop letting ECOs rot in email.

A 30-day pilot on one active product. Fixed $8k. Live on your own BOM in week one.

Book a demo →