ECR, ECO, ECN: What the Change Process Is Actually For

A test engineer writes: "U7 runs hot. I think we need a bigger regulator."

That sentence is the start of a change. Between it and a different part arriving on a different board there is a sequence of decisions, and the three-letter acronyms — ECR, ECO, ECN — are just names for the documents that record each one.

They have a reputation for bureaucracy, largely deserved in the places where they are applied without thought. But the underlying sequence is not bureaucratic. It is the minimum set of distinct questions any change has to pass through, and a one-person team answers all of them too, usually in their head.

Here is the sequence, followed by what it looks like when scaled down.

The three stages

ECR — Engineering Change Request. Something might need to change.

A request describes a problem, not a solution. "U7 reaches 95 °C at full load, derating limit is 85 °C." It can come from anyone: test, production, a customer, purchasing, the designer. At this point nothing is decided and no work is authorised.

ECO — Engineering Change Order. We have decided to change it, here is what and how.

An order describes the agreed solution, its impact, and what happens to existing stock and existing units. It is the decision record, and it is what authorises the work. Approval belongs here.

ECN — Engineering Change Notice. The change is done; here is what you need to know.

A notice tells everyone affected what changed, from which revision, and what it means for them. It is communication, not decision.

Request, decide, tell. Three different jobs that often get collapsed into one document, which is where the trouble starts.

The names are not standard. Plenty of companies run only two documents, or call the decision record an ECN, or add a deviation or waiver for a one-off departure that is approved without changing the design. Treat the three acronyms as labels for three questions rather than as a specification, and check what your own supplier or customer means before assuming you agree.

Following one change through

Sample numbers. The useful detail is that investigation happens after the request and before the decision — which is the stage most informal processes skip, deciding and investigating at the same time and discovering the cost afterwards.

What each document should actually contain

An ECR that works is short:

what was observed, with evidence; where and when; why it matters; how urgent, and what happens if nothing is done.

Note what is missing: the proposed fix. A request that arrives with a solution already chosen tends to get that solution, whether or not it was the best one.

An ECO is longer, because it carries the decision:

the problem, referencing the ECR; the chosen solution, and briefly why, including what was rejected; every item affected, with old and new revision; the impact analysis; disposition of existing material — use as is, rework, scrap, return; effectivity — from which build, date or serial the change applies; * who approved it, and when.

Disposition and effectivity are the two fields people leave blank, and they are the two that cost money. "Change the part" without "and the 300 in the warehouse are used up first" is an incomplete decision.

An ECN is shortest of all, and is written for people who did not take part:

what changed, in one sentence; which revisions supersede which; from when; what the reader has to do.

The scaled-down version

Most teams reading this are not going to run three document types with approval boards. They should not. But the three questions still have to be answered, and the scaled-down form is this:

One file per change. Numbered, with a date. It contains: what was wrong, what we decided, why, what it affected, what happens to existing stock, from when, and who agreed.

That is a single page. It collapses ECR, ECO and ECN into one record while preserving every field that matters. The acronyms are not the point; the fields are.

For a solo engineer, the same page is still worth writing, for a reason that has nothing to do with process: you are writing it for yourself in two years, when you have forgotten that the bigger regulator was chosen over the better heatsink because the enclosure could not take the height.

Where change processes go wrong

Approval theatre. Four signatures, none of whom read it. Approval should be by the people who can say no for a real reason, and nobody else.

No triage. Every request becomes an order. The process becomes a queue nobody trusts, and people start going round it.

Effectivity left vague. "From now on" is not a date, a build or a serial range, and in six months nobody will be able to say which units have the change.

The notice that nobody reads. If the ECN is a 12-page PDF, the one person who needed the second sentence will miss it.

Changes made without any record at all. The most common of all, and the one that makes every later question unanswerable. A badly written change record beats a perfectly executed undocumented change, because the record survives the people.

The minimum that is still worth having

If you take one thing: number your changes and keep one page per number.

Numbering alone gives you something to reference from a BOM comment, a drawing note, an email to a supplier. It converts "we changed that at some point" into "see change 041", and that single step does more for a project's memory than any amount of process design.

A change record is only as useful as its links to the things it changed. The page is worth little if the revision it produced cannot be found from it, or if the item cannot be traced back to the change that created it.

Each version of a board or a BOM in XKEMA is stored with its own history, so a change can point at the revision it produced.

Hardware configuration management Hardware engineering change checklist * Hardware revision control: a practical guide