A Small Change, Nine Months of Delay

I once had to swap out a PLC controller. Sounded like a simple component replacement — newer version, better availability, lower procurement risk. It ended up being 9 months of work, 7 affected areas, and a UL recertification.

That’s what a “small change” looks like in a HW+SW company without ECR/ECO control.

The domino effect

The reason for the swap was mundane: the old controller was approaching end of life. The company had to deploy its successor. On paper it looked like a reasonable decision — one component for another, newer, with better availability.

But that’s where the problem started. It turned out this wasn’t just a PLC replacement.

It required:

testing the new controller in the lab,
updating the technical documentation, because the pin layout in the electrical diagrams was different,
building a new system image,
maintaining parallel software for both the old and new PLC versions,
testing both variants, because devices with the previous version were still running in the field,
going through UL recertification, because the PLC was a safety-critical component.

One component change. One small hardware change.

The effect: work for engineering, software, documentation, testing, compliance, production, and service. The entire organization spent months handling the consequences of a decision that lived in emails and conversations — never in a formal approval.

9 months. And nobody said at the start: “this is going to be expensive.”

In hardware+software products, the most costly changes don’t always look dangerous up front. They often look like a sensible technical decision: newer component, better availability, simpler procurement.

The problem starts when nobody asks before implementation:

What does this change actually bring in its wake?

In software, a change leaves a trace in the repository. In HW+SW, it has to leave a trace in documentation, production, system configuration, certification, service, and the devices already running at customer sites. When that trace doesn’t exist, the company starts guessing.

The most expensive changes aren’t the biggest ones. They’re the ones someone decided were too small to formally review.

Why “small change” sounds innocent

“It’s just a small change” — that’s a sentence you hear in every company right before a disaster.

Because, after all:

we’re not changing the product’s function,
the customer won’t even notice,
software can be switched over quickly,
we’ll fix the docs later,
the tests will be the same,
production will “figure it out.”

And sometimes all of that is true. Just not the whole truth.

A small change in a hardware+software product rarely ends in one place. It leaves a trace in code, configuration, schematics, instructions, test procedures, the BOM, quality documents, and service. If that trace is deliberately tracked, the company pays once. If not, it starts paying on every subsequent decision.

There are two kinds of debt here.

The first is technical debt. It builds when the product works but becomes increasingly hard to develop. Code has exceptions. Configurations differ between versions. Tests stop being definitive. The team knows “for this version you have to do it differently” — but that knowledge lives in a few people’s heads.

The second is documentation debt. More boring, but often more expensive. There are no decisions in the change history — only effects. Nobody recorded why this component and not another. The impact on certification, production, and service got lost along the way. The hardware change and the software change are two events with no connection drawn between them.

With the PLC controller swap, the biggest cost didn’t show up in any schedule — not under “new controller,” not under any specific line of code.

The cost was living for many months in two parallel worlds.

The old PLC was still running in field devices. The new PLC was going into subsequent product versions. That meant two software branches, two test paths, two sets of behaviors to understand and maintain.

Every fix required asking: does this apply to the old version, the new version, or both? If both — it had to be implemented twice, tested twice, and you had to make sure documentation and service hadn’t drifted apart along the way.

That doesn’t look dramatic on any single status meeting. One fix here, one test there. But after a few months it becomes a daily tax on an earlier decision. Invisible in the plan. Very visible in the team’s workload.

A schedule doesn’t fall apart on the day a bad decision gets made. It falls apart when the company has to reconstruct a change history it never recorded.

ECR/ECO — what it is and why small companies skip it

Companies that have figured this out don’t rely on engineers’ memories. They have a mechanism that stops a change for 30–60 minutes before it generates 3 months of chaos. That mechanism is ECR/ECO: an Engineering Change Request (a document describing the change and its impact) and an Engineering Change Order (an approved implementation decision with dates, versions, and owners).

Small companies often skip this:

“We’re too small.” “Too much paperwork.” “We don’t have time.”

That last argument is the most expensive one: 1.5 hours to assess a change’s impact vs. 20 hours to fight the fire it starts. Or 200 hours if the problem surfaces at a customer site or during certification.

If you’re thinking “we have a small team, conversations are enough” — run a simple test. Ask three different people at your company what PCB version is installed at client X. If you get different answers or “you’d need to check with Tom,” conversations aren’t enough. Your knowledge lives in people, not in a system.

A lightweight process is an hour, maybe two, per change. No process means dozens of hours for every fire that results from one. From personal experience: UL recertification isn’t free, and “swapping out a PLC” took over 9 months — and nobody put that in the schedule as the cost of the change.

ECR/ECO doesn’t have to mean SAP or Windchill. It’s one question asked before every change: What does this change actually bring in its wake?

A lightweight change control process — how to start without bureaucracy

A 20–80 person company doesn’t need a heavy system. It needs four things.

1. Three questions before every change:

What exactly is changing? — not “we’re fixing a connector,” but: which one, in which revision, and why. If it can’t be described in one paragraph, the change probably isn’t that small.
What does this change affect? — a short checklist: hardware, firmware, BOM, suppliers, documentation, certification, production, service, sales. The most important answer is “I don’t know” — it doesn’t block the change, it just means: someone needs to check before we deploy.
Who approves and takes responsibility? — one specific person, not “everyone.”

2. One change record — number, description, reason, affected products and versions, impact assessment, owner, approval, date, links to documents. Tool is secondary: Notion, Jira, a spreadsheet — whatever you have.

3. One change register — all approved changes in one place, with the serial number or revision from which the change applies. Not in emails, not in Slack.

4. A definition of closed — a change isn’t closed when an engineer “pushed the fix.” It’s closed when updated: design, BOM, firmware, tests, manufacturing instructions, customer and service documentation, version markings.

The hardest part isn’t creating a template. The hardest part is figuring out where a change actually originates, who genuinely approves it, and how it reaches production, documentation, and service. Every company looks different here.

Warning signs your company has a change problem

Check which of the following apply to your company:

Service technicians don’t know what product version is at a client site — they ask three people, search through emails
Documentation doesn’t keep up with hardware — “almost current” isn’t the same as current
“Fixes” are discovered during customer deployment, not by the company
Every change requires a five-person meeting because there’s no decision register
Nobody knows which changes went into which production batch
Purchasing swaps components due to availability, and engineering finds out after the fact
A new engineer spends their first weeks reconstructing the product’s history from conversations, not documents
The team is afraid to touch the product because “no one knows what will break”

3+ items: the problem already exists — the next change will probably enter production without an impact assessment.
5+ items: you’re risking series delays and wrong service calls in the field.
7–8 items: you’re not managing changes — you’re just putting out fires.

The best time to fix this was before your first major production run. The second best time is now.

If 3+ of these apply to your company, the next change will enter production without an impact assessment. The question isn’t whether — it’s which change.

Product Control Review is a 90-minute session for HW+SW companies with a growing number of revisions, changes, and devices in the field. We take the last 3–5 real changes from your company and trace where control slipped: the decision, the impact, the approval, the serial number, the documentation, the service.

No SAP, no Windchill, no procedures about procedures.

After the session you have: a map of your change flow, 3–5 specific gaps, a prioritized risk list, and a checklist to use on the next change.

Book a Product Control Review →