An engineering change order (ECO) is the controlled process by which a released design gets changed: someone proposes the change, the affected people assess its impact, an approver accepts or rejects it, and the drawings, models, bill of materials, and factory instructions are all updated together under a new revision. It sounds like bureaucracy until the first time a factory builds a thousand units from a superseded drawing. The point of an ECO system is not paperwork — it is making sure that everyone building, testing, and buying is looking at the same version of the truth.

The problem that looks administrative until it costs money

Before release, changes are cheap and informal. After release, a design exists in many places at once: your CAD system, the fabricator's quoting file, the molder's tool, the assembler's work instructions, the purchasing system's part numbers, the test lab's certified sample, and the manual in the box. Change one and you have created an inconsistency.

Typical failures look like this:

  • A hole moves 2 mm, the mechanical team updates the model, and the PCB fabricator keeps building to the old outline.
  • A resistor value changes on the schematic but not on the purchasing bill of materials, and five thousand wrong parts arrive.
  • A supplier substitutes an "equivalent" component and nobody assesses whether the product still meets the certification it was tested under.
  • Two engineers email revised files to the factory the same week, and the factory builds a mixture.

The three failures behind almost every case

1. Ambiguous versions

Files named housing_final_v3_REV2_new.step are a symptom of a missing revision scheme. Nobody can tell which is current, so people guess, and eventually someone guesses wrong.

2. No single source of truth

When the authoritative design lives in one person's laptop, in a shared drive, and in an email thread simultaneously, it lives nowhere. There must be exactly one place where "current released" is defined.

3. Changes with unassessed consequences

Every change touches more than the drawing it appears on. Moving a boss changes the mold. Changing a material changes the flammability rating. Changing a connector changes the cable, the assembly instructions, and possibly the packaging.

The minimum system that actually works

Small teams do not need enterprise PLM software. They need four habits.

Explicit revision numbering

Adopt one scheme and use it everywhere: part number plus revision, with revision recorded on the drawing, in the file name, in the model properties, and ideally molded or marked on the part itself. A common convention uses letters for released revisions and numbers for pre-release iterations. Consistency matters far more than which scheme you pick.

A single source of truth

One repository holds released files, read-only, with a documented current revision for every part number. Everything else — email attachments, supplier portals, chat threads — is a copy, and copies are never authoritative. This repository is essentially your manufacturing data package under version control.

A short change form

One page is plenty. What is changing and why; which part numbers, drawings, and bill of materials lines are affected; cost and lead time impact; whether existing inventory and in-transit units are affected; whether retesting or recertification is required; the disposition of existing stock (use, rework, or scrap); who approved it; and the effective date or serial number. If the change form is longer than a page, people will stop filling it in.

Design freeze points

Define stages where the design locks and changes require approval rather than a Slack message. Natural freeze points align with build phases — the EVT, DVT, and PVT gates exist precisely to create them. Before a freeze, iterate freely. After it, use the process.

What triggers retesting

This is the question that catches teams out, and it should be a checkbox on every change form. Changes that commonly require re-verification include:

  • Anything affecting an enclosure that carries a safety or ingress rating.
  • Changes to power supplies, batteries, chargers, or protection circuits.
  • Changes to antennas, radio modules, shielding, or PCB layout near a radio — small layout changes can invalidate an existing radio authorization.
  • Material substitutions where flammability, food contact, or biocompatibility was part of the original evidence — the underlying logic is in product safety testing requirements.
  • Firmware changes that alter radio behavior, safety interlocks, or measurement accuracy. Because updates can be pushed silently, OTA firmware updates need the same change control as hardware, not less.

Assume retesting is required until someone competent documents why it is not. This article is general engineering practice information, not regulatory or legal advice; for a regulated product, confirm change-control obligations with a qualified specialist for your product class.

Revisions in the field, not just in files

Once units exist in the world, you need to know which revision each one is. Serial numbers linked to a build record, revision markings on parts, and firmware version reporting all let you answer the question that eventually arrives: "which units have the old bracket?" Without that traceability, a targeted fix becomes a blanket recall, and incoming inspection sampling of the kind described in AQL inspection cannot tell you what it was even inspecting against.

Who owns the files

Change control assumes you can actually change the design, which assumes you hold the source files — native CAD, schematics, firmware source, not just PDFs and Gerbers. Settle that in the development agreement rather than discovering it during your first urgent change; the stakes are covered in who owns the IP in product development. A design you cannot revise is a design you do not control.

Where it fits

ECO discipline starts the moment a design is released and continues for the product's whole life. It is the downstream half of the same rigor that produced your requirements document, and it is what keeps a shipping product from slowly drifting away from the one you validated.

Managing a product that is already in production and starting to accumulate undocumented changes? Contact us through the form and we will help you put a revision and change-control system in place that a small team can actually maintain.