The third prototype doesn't work, and nobody knows why.
The first two were fine. The firmware was locked, the hardware was solid, you and the other engineer were proud of it. Then you built another iteration, changed a few things, and now it's dead on the bench. So you start digging. You go through the bill of materials. You go through the code. Both are a little messier than you remembered. Somewhere in there is the change that broke it, and you cannot find it because nothing was tracked.
That moment is what the Engineering Change Order exists to prevent. The harder question is when you should start running one, because turn it on too early and you've bought yourself paperwork with no payoff. Turn it on too late and you're debugging blind during the most expensive phase of your program.
The Acronyms Are Stuffy For a Reason
Before the advice, a short detour into where this came from, because the history explains why the process feels so heavy by default.
The ECO is a descendant of military configuration management. That discipline started inside the U.S. Department of Defense in the 1950s, credited mostly to the Air Force, as a way to keep control of complex hardware: missiles, aircraft, weapon systems. The problem they were solving is one you'd recognize. Prototypes were getting built with little or no documentation, parts were duplicated or quietly swapped, and nobody could say with confidence what configuration a given unit actually was. That cost money and, in their world, lives.
The first real ancestor of the ECO showed up in 1953, in an ANA Bulletin numbered 390, which defined the Engineering Change Proposal: the proposed change, plus the documentation describing it in full. That is the grandfather of the modern request-then-order split you see in every PLM tool today.
It hardened into a formal discipline through the late 1960s and 1970s with a run of DoD standards, the "480 series," which were later consolidated, then replaced, then eventually civilianized into ANSI/EIA-649, the configuration management standard most industries reference now.
So when you meet the stuffy acronyms, the ECR, the ECO, the ECN, the CCB, remember they were forged in aerospace and defense, where one undocumented change to a frozen design could put an aircraft into the ground. The rigor is not bureaucratic theater. It is the residue of a context where getting it wrong was catastrophic.
Your twelve-person robotics company is not Boeing. That is the whole point of deciding when to turn this on, rather than assuming you need the full apparatus on day one.
What an ECO Actually Is
Strip away the lineage and an ECO is simple: it is the formal act of changing something that has already been declared correct.
A change request comes first; it describes the problem and the proposed fix. Once that's vetted, the change order defines and authorizes the actual change. In an enterprise the order carries a fixed set of fields: a unique number, the rationale, the affected items (part numbers, drawings, BOM lines, work instructions), the effectivity (which units the change applies to, by date or serial or lot), and the disposition of existing inventory, meaning whether you use the old parts as-is, rework them, or scrap them. A Change Control Board signs off before anything moves.
Look at that field list and you can see what it's built for. Effectivity matters when you have units already in the field and need to know which serial numbers the change touches. Disposition matters when you have a warehouse of old inventory and a real dollar decision about whether to scrap it. A Change Control Board matters when engineering, quality, manufacturing, and procurement each own a piece of the outcome and none of them can be surprised. Every one of those fields is the answer to a problem you get at scale.
A two-engineer startup has none of those problems yet. You have no field units, no inventory warehouse, no procurement team to keep in the loop. Running the full enterprise ceremony at that stage is filling in fields that describe a company you aren't.
You do not need all of that to start. You need the core idea: a change is tracked, described, and validated against a known-good baseline, instead of happening silently inside someone's CAD session at eleven at night. The fields you add later, as the problems that justify them actually show up.
The Real Trigger: You Have Something Worth Preserving
Here is the rule that actually matters. You turn on ECOs when you have something that works that you want to preserve.
Early on, you are not preserving anything. You are in the validation phase, fighting to make the thing function at all. Every part is provisional. Tracking changes formally during this stretch is like writing meeting minutes for a brainstorm; the whole point of the phase is that things are supposed to move fast and break.
Then it works. The hardware behaves, the firmware is locked, you have a prototype you trust. That is the inflection point. From here, changes are no longer about discovery; they are about not losing what you already earned. And changes at this stage are sneaky. You and one other engineer build the next iteration, swap a connector, bump a firmware version, and the system that worked yesterday is broken today. Without traceability, you are reverse-engineering your own product to find the one change that did it.
With an ECO in place, you track the change as you make it, and you validate the system after each one. The next time something breaks, you have a diff and a date instead of a mystery.
EVT Is When. PVT Is the Latest.
In practical NPI terms, this lands at EVT, the engineering validation stage, once your design is working and consistent. Not the first time it powers on; the point where you know it holds up.
You can wait longer. You can push it to DVT, even into PVT if you want. But PVT is the latest you should ever turn it on, and that is a hard line. Once you are in production, every change ripples outward. It hits your supply chain. It changes how your contract manufacturer builds the unit. And your CM may well require a formal change process anyway, because they need you to control your revisions; they are not going to build to a moving target they can't trace.
Think about what a single change costs at each stage. At EVT, a bad change means you rebuild a prototype on your own bench over a weekend. At DVT, it means re-running a validation test you've already paid for. At PVT, it means a revision to the documentation your contract manufacturer is building from, possibly mid-run, possibly after they've already pulled components for a batch. The change is the same edit. The blast radius is not.
If you wait until production to start practicing change control for the first time, you will do it badly at the exact moment doing it badly is expensive.
Start Early Enough to Be Bad At It First
This is the part most founders miss. The reason to turn it on at EVT, rather than the last possible moment, is that you will not run the process well the first time. Nobody does.
Treat the window between EVT and PVT as practice. You start tracking changes while the stakes are still internal, you find the workflow that fits how your team actually works, and you make your sloppy first attempts at a stage where a sloppy attempt costs you a rebuild, not a production run. By the time you reach PVT and the process becomes load-bearing, it is muscle memory.
Starting a little early is not the same as starting too early. Too early is paperwork over a design that doesn't exist yet. A little early is rehearsing the process on a design that finally works, so it's solid before your company's success depends on it.
The ECO didn't come from people who loved process. It came from people who learned, expensively, what happens without it. You get to learn that lesson cheaply, on your own bench, if you turn it on at the right time.
oroForge gives small hardware teams a place to run change orders against a real baseline without the enterprise overhead. See how it works →
