I once watched a single changed hole swallow an entire production week. A colleague — in a hurry, on a Friday — enlarged a hole on a mounting bracket from 10 to 12 mm in the CAD file, saved it, emailed the new file, and did not tell anyone. The fixture shop had already cut clearance for the 10 mm hole, the supplier had ordered studs for the 10 mm pitch circle, and the assembly line found out at 8:41 Monday morning when the part would not sit. Nobody had done anything malicious. There was just no change order, no impact review, no record that said “this one hole affects these five other things”. That afternoon began a long, slow project of mine: building an engineering change process boring enough to survive real projects.
Why ECOs fail when you need them most
The failure is never a lack of paperwork. Every shop has a change form; most shops have a change form that everyone resents and half-ignores. The real reasons change control breaks are simpler. The form is too long, so people skip it. It asks questions the engineer cannot answer yet, so they stall. It goes to reviewers who do not actually review, so signatures become decoration. And the time between the change and the check-in is long enough that the memory of why evaporates.
My claim, after years of this, is that an engineering change order has exactly one job: to force the person making the change to think about who else will be surprised by it. Every field on the form exists to serve that one job, and any field that does not serve it should be cut. That is the whole design philosophy of the workflow I use, and it is far less paperwork than you imagine.
A change order is not permission to change; it is an agreement about who will be surprised, and what they will do about it.
What a usable ECO actually contains
Here is the form I settled on, after shrinking several ceremonial versions. It is one page, and every field has a reason.
- Change identifier and revision level being changed — so the change is traceable to a specific released state.
- What changed, in one or two sentences, written for a stranger — not for the author’s own desk.
- Why — the justification, the customer requirement, the failure, or the cost. If the why is embarrassing, write it anyway.
- Impact list — the parts, drawings, BOMs, fixtures, programs, and suppliers that this one change touches. This is the field that prevents Monday mornings.
- Reviewers — named people from the disciplines the impact list names, not a bucket list of managers.
- Verification plan — how you will prove the change works before it reaches the floor.
- Status and dates — pending, approved, implemented, verified, closed.
You will notice there is no field for the author’s opinion of the change, and no field for the CEO’s signature. Both are the kind of decoration that makes forms feel important and work worse. What the form does have is a question at the bottom: “If this change ships tomorrow, who will be surprised?” It sounds naive. It is the single most effective question I have ever put on a form.
The impact review nobody wants to be the hero of
When a change order enters the review stage, the temptation is to set up a room and read the form aloud. My experience is that the review works best small and cross-functional: the designer, a manufacturing engineer, a procurement person, and the person who runs the affected process on the floor. That small group can answer the surprise question in fifteen minutes, because they each live in a different world that the change crosses.
I run the review in a fixed, fast order. First, the manufacturing engineer asks the killer question of their trade: can we still make it? Does the new tolerance demand a process we do not own, or a fixture we would have to buy this quarter? Second, procurement asks the supply question: is this a stocked item, a cut-to-length, or a special order with a lead time longer than the project? Third, quality asks the verification question: how will we know the change worked, and does the drawing carry the new inspection criteria? I forbid debates about style and preference; those are in someone else’s meeting. The review exists only to surface surprises.
One scheduling rule I hold firm: the review happens before the change is implemented, not after. The classic disaster is the shop that changes the design and then sends the form around for signatures as a courtesy, which is not review, it is notification, and notification after the fact costs exactly as much as the hole that grew on Friday. If the change is already in the file, the review is theatre and everyone knows it.
Version control for people who actually collide
The engineering change order is the policy layer; the PDM is the enforcement layer, and this is where versions stop colliding or start a riot. My hard rules are few. One: a released drawing never changes in place — it gets a new revision, and the old revision stays readable, because the shop floor is still cutting the old revision somewhere and will be for months. Two: the working file and the released file are separate states; an engineer can play with the working copy without implying the release moved. Three: check-out locks are a courtesy, not a guarantee — the real protection is that the released state only changes through the ECO, so even a reckless check-in cannot silently advance what the floor is building.
The branch question usually comes up here, and I have opinions. For most machine-design shops, a full branch-per-feature workflow is overkill and a source of confusion. I prefer a single release line with well-defined revisions, and I use branches only when two genuinely parallel lines must evolve at once — say, a current production design and a next-generation variant that share a base. When I do branch, I keep the merge discipline manual and documented, because a merge that nobody can explain later is a workshop full of unknowable parts.
| Versioning rule | Why I hold it |
|---|---|
| Released files never edit in place | The floor is still cutting the old revision |
| Working state separate from released state | Play must not imply release |
| Release only via ECO | Check-in accidents cannot advance the line |
| Branches only for parallel life lines | Branch-per-feature confuses machine shops |
| Merges documented by hand | An unexplained merge is a mystery part |
Implementation and the verification nobody skips safely
A change that is approved but not verified is a change that is not done. My implementation phase has a fixed shape. The designer implements the change in the working copy and bumps the revision. Then the verification happens against the specific plan written on the form — a dimension check, a first-article inspection, a dry run on the fixture — not against a vague hope. Only when the verification passes does someone who was not the author close the ECO with the result written in.
I have a particular hatred for the “ECOs closed by the author without evidence” habit, and I make it harder every year. The close-out requires the verification result and the date, and the reviewer’s name is on it. If the verification found a problem, the ECO goes back to pending and the story continues; it does not get magically closed because the deadline wants it closed. The discipline is not paperwork for paperwork’s sake — it is the difference between a change record you can trust for a warranty claim two years later and one you cannot even quote.
Mistakes I have made in change management, catalogued honestly
| Mistake | Result | The habit that fixed it |
|---|---|---|
| Change implemented before review | Review became notification; surprises still happened | Review is always gate, never courtesy |
| ECO form with fields nobody can answer | Engineers stalled and then cheated | Every field serves the surprise question or it is cut |
| Signatures from managers who never read | Decoration that laundered mistakes | Named reviewers by discipline, small group |
| Released file edited in place | Floor built to a revision that no longer existed | New revision in PDM, old one stays readable |
| Author closes own ECO with no evidence | Untrustworthy change history | Verification result required, reviewer named |
A change control story that ended quietly
I want to end with the quiet version, because the loud failures are easy to describe but the quiet successes are the point. A customer asked for the motor on a niche machine to be swapped for a higher-output unit. Under the old regime, that would have been an email, a spirited argument at the line, and two scrap lots. With the workflow, the ECO listed one mounting plate, one belt length, one guard opening, and one software parameter. The manufacturing engineer saw the belt change and flagged the existing tensioner range; procurement saw the motor lead time and ordered early; quality added a run-up test. The change was verified on a Friday, closed Monday, and nobody outside the small involved circle noticed anything at all. That is the signature of change management working: the absence of a fire drill.
You do not need an expensive PDM suite to start. You need a one-page form with the surprise question, a small named review group, and a rule that release only happens through the ECO. Shrink the ceremony, keep the discipline, and the hole that swallows production weeks stays firmly in your past. My colleague who grew the hole to 12 mm now writes impact lists before touching a file. We all learned together, as shops always do.
What about the legitimate emergency?
The question every engineer asks me is the one the Friday hole taught me to answer honestly: what happens when a change is genuinely urgent — a machine down, a customer on the phone, a part that simply must be different this afternoon? The wrong answer is “ship it and file the paper later”, because later never comes and the next engineer inherits a mystery. The right answer is a stated, limited fast track that still keeps the record intact.
My fast track looks like this: the change is declared as an emergency ECO, which moves it to the top of the review queue with a single named approver instead of the full group. The impact list is written in ten minutes — not twenty questions, just the surprise question answered out loud. The change is implemented and marked clearly as “provisional, pending full review”, and within three working days the full review runs and the ECO is either upgraded to a normal closure or rolled back. The point is not to do less paperwork on emergencies; it is to compress the review into the time the emergency actually has, and to keep the record alive so nothing disappears. I have never had that three-working-day review fail to find something worth finding.
The other half of the emergency is protecting the rest of the world from it. A provisional change stays out of the released line until the full review closes; the floor is told it is provisional, the drawing says provisional in the margin, and nobody mistakes a fast-track rescue for a new revision that is permanently true. That one sentence — “this is provisional” — has prevented more second disasters than any other habit in my toolkit.
Why the boring wins
I have spent the whole article defending a form, and I want to justify that to you plainly. Change control is not fun, and nobody gets a bonus for it, and it feels like overhead right up until the moment it is the only thing between your shop and a scrap pile. The hole that swallowed the production week cost us roughly four times the price of the form that would have described it in five minutes.
So if you take one thing from this, let it be the small shape of the habit: one page, one surprise question, a named reviewer per discipline, and a rule that release only travels through the ECO. Start with one product line, run it for a month, and count your quiet Mondays. When the dramatic failure becomes a quiet closed-out note in a folder, you will have discovered the only kind of change management that survives contact with a real project — the boring kind that simply never lets a 12 mm hole surprise the line again.
