↓ Download as PDF

It starts with a reasonable instinct. An engineer spots a problem, works out the fix, updates the drawing, and emails procurement to order the new part. Helpful. Fast. And the beginning of an expensive mess — because nobody told Quality, whose inspection plan now checks the wrong dimension; nobody told the supplier already building to the old revision; nobody told the project manager whose customer contract requires notice of exactly this kind of change. Three weeks later there are two revisions of the same part number in the field, the as-built record matches neither, and nobody can say with confidence what you are actually shipping. The change itself was probably fine. The way it was made is what cost you.

This is the most common failure in a growing hardware company, and it is not a discipline problem in the way people mean it. Your engineers are not careless. The problem is that there is no process for a change to travel through — or there is one, and it is so heavy that people route around it to get anything done. Both failure modes end in the same place: changes that happen without anyone downstream finding out in time to do something about it.

Three words, because three different people are involved

The first move is to stop using “change” as one word, because a change is really three events with three different owners. A request is anyone noticing that something ought to change; it commits you to nothing — a numbered entry that triggers an assessment, no more. An order is Engineering deciding what the change actually is, in full technical detail, and getting it approved. And a notice is the release: the single signal that fires every downstream action — the bill-of-materials update, the drawing release, the supplier’s new revision, the procurement order. Request, order, notice. Anyone can request. Engineering owns the solution. Operations executes from the notice — and never before it.

The bit between the request and the order

The step everyone skips is the one that makes the rest safe: the impact assessment. A request is not approved because the engineer who raised it is confident. It is approved because someone has worked out what it actually costs to make — the bill-of-materials and part-qualification impact, the schedule slip, the price and lead-time change from the supply base, the effect on the approved vendor list, the quality and safety classification. That assessment is cross-functional by necessity: the engineer cannot see the customer contract, and the project manager cannot see the tolerance stack. So the board is not there to admire a change. It is there to look at an assessment that already exists and decide, with the downstream cost in front of it, whether the change is worth what it will take to make.

Not all changes are equal — so stop treating them as if they were

The fastest way to kill a change process is to make every change go through the same gate. Route a label correction through the same board that reviews a safety recall and one of two things happens: the safety change waits behind the trivia, or the board learns to rubber-stamp everything to keep the queue moving. So classify first — because the classification, not the change, is what sets the timeline and the approvers.

Get the classification right and the heavy machinery only runs when the stakes justify it. Get it wrong — in either direction — and you have either a bottleneck or a rubber stamp, and both train people to work around you.

Formality should rise with commitment, not with company policy

Here is the part most change processes get backwards. Early, before you have committed money or cut a purchase order, a change should be nearly free — an afternoon’s work, logged for traceability but not gated, because speed and iteration are the entire point of that phase. Then, as commitment rises — design freeze, tooling, the purchase order, production, the field — the same change should get progressively harder, and visibly so. The trigger is not the calendar; it is the money at risk. After the purchase order is cut, every change touches schedule, cost or warranty, and the process has to be at its strictest exactly when the pressure to skip it is highest.

The board, and who gets to say no

A change that crosses functions needs a body that represents them: a change control board with a named chair, real membership, and the authority to block. Who chairs it should shift with the stage. Before the contract, Engineering chairs, because the questions are still mostly technical. After the purchase order, the project manager chairs, because now every change is a schedule and cost event first and a technical one second. Two roles need explicit blocking authority once you are in execution — the project manager and the project engineer — because they are the ones holding the customer commitment and the field reality. A block is not an argument in a hallway; it is logged, in writing, with a justification, inside the review window. And when the board cannot agree, the tie does not sit unresolved for a fortnight — it escalates, once, to a single executive who decides. Deadlock is itself a decision, and a bad one.

And the project manager’s job on that board is not to attend. It is to produce the schedule-impact statement on every significant change before the vote, and to decide whether the change trips a notification clause in the customer contract. A change that slips a committed date or triggers a contractual notice is a project event before it is an engineering one, and the person who owns the customer relationship has to see it coming — not read about it in a released notice after the fact.

One system, nothing verbal

None of this runs on goodwill. It runs because there is one system of record — ideally the one that already has an owner in your business, the product-data or quality system, not a new tool bolted on for the purpose — and the rule is absolute: a change that is not a closed record in that system did not happen. No verbal approvals. No engineer updating a bill of materials without an open, approved order behind it. No procurement ordering to a revision that has no notice against it. No telling a supplier about a change before the notice is issued. The rules read as bureaucratic right up until you have watched a six-figure inventory write-off trace back to a supplier who built to a revision they were told about verbally, ahead of a notice that then changed.

---

None of this is heavy if it is proportional. The whole design goal is a process that is freewheeling when a change is cheap and formal when a change is expensive; that tells everyone who needs to know at the moment the decision is made, not three weeks later; and that leaves a record clean enough to answer the only question that finally matters — what, exactly, are we shipping, and who approved it. Get that, and engineering change stops being the thing quietly eroding your margins and becomes a controlled, visible, boring part of how the business runs. Boring is the goal.

And notice that none of it is a form you fill in once. It is a process you have to stand up, staff and hold — a classification rule, a board with a chair who will actually block, a system with a single owner, and a short list of behaviours the organisation agrees are simply not done — inside a business that is already changing things every day. Knowing the process is the easy half. Making it proportional enough that people use it, and firm enough that it holds after the purchase order, is the work.

That is the work I do.