The first change request that nearly sank one of my projects was eleven words long, and it taught me more about engineering change management than any training course. A customer’s field engineer sent an email asking us to “move the drain port to the other side, if possible.” That was it. No drawing, no reason, no date. Our design lead, who wanted to help, made the change in CAD that afternoon. Three weeks later, however, we found out the new port location collided with a bracket that a supplier had already started machining. As a result, the casting pattern needed a revision, and the customer had never actually committed to paying for any of it.
Nobody did anything wrong in that story, at least not on purpose. Everyone was trying to keep the customer happy and keep the job moving. What we lacked, though, was a shared, disciplined way to say “yes, but first let’s understand what this touches.” That is what engineering change management is for. After many years running industrial and equipment programs, I have come to believe it is the single most underrated skill in project delivery.
This article explains how I run it today. Not the textbook version, but rather the version that holds up on a real job with real deadlines, real suppliers, and real people who are tired of filling out forms.
What Engineering Change Management Really Is
At its simplest, engineering change management is the structured process for proposing, evaluating, approving, and implementing changes to a product, a process, or the documentation that defines them. For example, it covers design revisions, material substitutions, tolerance updates, routing changes on the shop floor, and a new supplier for a purchased part. In short, if it changes what the baseline says, it belongs in the process.
Here is the part people miss. Engineering change management is not a brake. Instead, it is a steering wheel. A good process does not exist to say no. Rather, it exists to make sure that when you say yes, you know what you are agreeing to, who pays for it, when it lands, and what else moves because of it.
When teams experience change control as bureaucracy, it is almost always because someone designed the process to protect themselves rather than to help the project make decisions. I have seen approval chains with nine signatures for a label font change. On the other hand, I have also seen shops with no process at all, where the “current revision” lived in whichever engineer’s head was still in the building. Both are failures. Therefore, the goal sits between them.
Change Is Not the Enemy. Creep Is.
I want to draw a line that took me an embarrassingly long time to learn to draw out loud with clients and sponsors.
Change is a modification to scope that the people accountable for the project have raised, assessed, and acknowledged. Creep, by contrast, slips in without that acknowledgment, and usually without any agreement on time or money. The Project Management Institute has made this same distinction for years: scope change is visible and approved, while scope creep happens outside the charter without sponsor approval or an agreement for additional payment.
Why the Distinction Matters
That distinction matters because it changes the conversation. When a customer asks for something new, I don’t treat it as a threat. In fact, change requests often show that the customer is engaged and the product is getting better. What I do treat as a threat is the quiet version. For instance, the engineer who “just fixes it,” the buyer who swaps a component because the usual one has a long lead time, or the technician who adjusts a fixture and never tells anyone. None of those people are villains. They are solving problems. Still, every untracked fix is a small loan against the project, and the interest comes due at integration or, worse, in the field.
So the first rule I set on every program is simple: nothing changes the baseline without a record. The record can be light. For example, a trivial change might need only a two line entry. But the record has to exist.
Why Timing Is Everything in Engineering Change Management
If you remember only one idea from this article, make it this one. The timing of a change drives its cost far more than its size does.
In product lifecycle circles, engineers talk about the rule of ten, which comes from German engineering guidance (VDI 2247). It holds that the effort to implement a change grows by roughly a factor of ten with each successive lifecycle phase. In other words, a tweak that costs an hour of engineering during concept can cost a week once you release drawings, and many times that once the toolmaker has cut steel and inventory sits on the shelf.
What the Research Shows
Academic research on engineering change in manufacturing puts some uncomfortable numbers behind this. One widely cited study from Saarland University noted that engineering change work can consume 30 to 50 percent of product development capacity, and in some organizations up to 70 percent. Similarly, another figure in that same body of work put the average cost of a single engineering change at around 1,400 euros, and that figure excluded organizational overhead. Multiply that across hundreds of changes a year, and you start to see why automotive suppliers treat this as a strategic issue rather than an admin task.
Systems engineering voices make the same point from the other direction. GoEngineer has written that early design decisions effectively lock in 70 to 80 percent of a product’s lifecycle cost. Consequently, the cheapest place to have a hard conversation about scope is at the beginning, before anyone cuts metal or buys parts.
In practice, this shapes how I sequence a job. I push hard for design reviews, supplier input, and manufacturability checks early, even when it feels slow. After all, frontloading the uncomfortable questions is how you avoid paying ten times for them later.
The Engineering Change Management Paper Trail: ECR, ECO, and ECN
Most industrial organizations use some variation of three documents. The names vary between companies and ERP systems; however, the roles stay consistent.
The Three Core Documents
Engineering Change Request (ECR). This is the proposal. Someone has spotted a problem or an opportunity and wants the team to evaluate it. A good ECR states the problem, the reason for the change, the proposed solution if one exists, the affected parts or documents, and who is asking. It does not need to be perfect. Its job, after all, is to start a conversation with enough facts to make that conversation productive.
Engineering Change Order (ECO). This is the decision package. Once the team assesses the request and defines the solution, the ECO lists every affected part, assembly, and document, along with the revision details, cost information, and how to handle existing stock and work in progress. Arena, one of the better known PLM providers, describes how the ECO goes to a change control board made up of engineering, quality, procurement, manufacturing, and often outside design partners or suppliers. Each member then judges the impact in their own area.
Engineering Change Notice (ECN). This is the announcement. Once the board approves the ECO, the ECN tells everyone who needs to act on it what changed and when it takes effect.
Discipline Over Names
Honestly, I care less about the names than about the discipline behind them. The request separates “someone noticed something” from “we are doing something.” Next, the order makes the decision explicit. Finally, the notice makes sure the people who build, buy, and inspect the product actually know about it. Skip any of the three, and you will eventually pay for it.
Engineering Change Management Triage: Not Every Change Deserves the Same Process
This is where most change processes stall projects. It is also the fix that has given me the biggest return.
When every change goes through the same full board review, the board becomes a bottleneck. Small, low risk changes sit in the queue behind big, complicated ones. As a result, engineers get frustrated and start working around the system. Then the system loses credibility, which is the beginning of the end for any control process.
The Three Lanes I Use
On my programs, I classify every incoming request within two working days into one of three lanes.
Lane 1: Administrative. Typos, title block corrections, and clarifying notes that do not change form, fit, or function. The owning engineer and a document control reviewer approve these. There is no meeting, so turnaround takes hours.
Lane 2: Contained technical change. These changes affect form, fit, or function but stay within one subsystem, have no customer facing impact, and stay below a defined cost and schedule threshold. A small review group handles them, usually the design lead, quality, and manufacturing engineering. Asynchronous approval works fine here, and the target turnaround is a few days.
Lane 3: Significant change. Anything that touches the customer’s requirements, the contract value, the schedule critical path, regulatory or safety obligations, or multiple subsystems. These go to the full change control board with a proper impact analysis.
Agree the Thresholds Early
The sponsor and I agree on the thresholds for each lane at project kickoff, and we write them into the project management plan. That way, nobody argues about process in the middle of a crisis. SPK and Associates put this well in their writing on late stage changes: not every engineering change should require weeks of approvals, but every change needs a consistent process. Consistency does not mean uniformity, though. Instead, it means everyone knows which path a change will take and why.
In my experience, roughly two thirds of change requests on an industrial program land in the first two lanes. Once you move those out of the board’s way, the board suddenly has time to think properly about the changes that actually matter.
Running an Engineering Change Management Board That Actually Decides
I have sat in change control board meetings that were essentially status updates where nobody decided anything. People read the ECO aloud, someone said “we need more information,” and the item rolled to next week. Then the cycle repeated for a month.
A change control board exists to make decisions. Here is how I keep mine honest.
Structure the Meeting
Fixed cadence, short meetings. We meet weekly, and sometimes twice weekly during peak design phases. Meetings last forty five minutes with a hard stop. If an item is not ready for decision, it does not get airtime. Instead, I send it back to the requester with a specific list of what is missing.
The right people with real authority. Every function that the change can affect needs a voice. Equally important, every person at the table needs authority to commit their function. If the procurement representative has to “check with their manager” on every item, then I need a different representative.
Pre reads, not live reading. I send the impact assessment out at least a day before the meeting. People come having read it. That way, the meeting focuses on discussion and decision rather than discovery.
Force a Clear Outcome
Four possible outcomes, written down. The board can approve, approve with conditions, reject, or defer with a named owner and date. Defer is the dangerous one, so I cap it. If the board defers an item twice, it comes to me personally to break the logjam.
The customer is in the room when it’s their scope. For contract changes, the customer’s representative, or at least their written position, needs to be part of the decision. This is exactly where the drain port story would have ended differently. If that request had gone through a proper review, someone would have asked the obvious question: is this a change to the contract, and if so, who pays?
Impact Analysis in Engineering Change Management Without the Three Week Wait
Impact analysis slows down most change decisions. Teams know they need to understand what a change touches. However, tracing that out across drawings, BOMs, routings, supplier orders, test procedures, and inventory can take forever when the data lives in five different systems.
A Standard Checklist
For that reason, I use a structured checklist for every Lane 2 and Lane 3 change. It asks the same questions every time:
- Which parts, assemblies, and documents does the change affect, including where used?
- What is the status of inventory and work in progress for each affected item?
- Which open purchase orders or supplier commitments does it touch?
- Does the change affect any test, inspection, or validation the team already completed?
- Are there regulatory, safety, or certification implications?
- What is the cost, broken out by engineering hours, material, scrap, tooling, and rework?
- What is the effect on the schedule, especially the critical path?
- What is the effect on the customer, both contractual and functional?
Each function answers its own questions. Engineering owns the where used analysis, supply chain owns inventory and supplier impact, quality owns the validation questions, and I own schedule and cost consolidation. Because we split the work this way, the analysis happens in parallel instead of in sequence.
Where Tools Help, and Where They Don’t
Tooling also helps enormously here. PTC has written about how PLM systems bring governance, visibility, and associativity to change data, so affected items surface automatically instead of someone hunting them down by hand. Likewise, CENIT has made the case that integrating PLM with ERP gives teams a fuller view of cost effects, because a change ripples into purchasing, production, and sales, not just engineering. If your organization still tracks changes in spreadsheets and email threads, the business case for a proper system usually writes itself within one bad quarter.
That said, tools do not replace judgment. The best impact analysis I ever saw came from a manufacturing engineer with a printed BOM, a highlighter, and twenty years on that product line. So use the tools to apply that kind of knowledge faster, not to substitute for it.
The Change Budget: A Simple Engineering Change Management Tool
One of the most useful ideas I picked up from the PMI community is the change budget. At project start, you agree with the sponsor on a defined reserve of money and schedule float specifically for approved changes. Every approved change then draws from it. When the reserve runs out, it is gone, and any further change requires a formal rebaseline with the sponsor.
This does two things. First, it gives the change control board real authority to say yes quickly, because small approved changes do not need to go back to the sponsor every time. Second, it makes the cumulative cost of change visible. Individually, a dozen small changes each seem harmless. Together, however, they can quietly eat a project’s entire margin. A change budget turns that slow leak into a number on a dashboard that everyone can see.
On fixed price industrial contracts, I also pair this with a clear contract clause that defines what counts as a customer driven change and how we price it. That clause has saved more relationships than it has damaged, because disagreements about money then happen early, calmly, and in writing.
Engineering Change Management on the Floor and With Suppliers
An approved change that nobody acts on is worse than no change at all, because now the documentation and reality disagree.
Implementation is where I see the most leakage. For example, the board signs the ECO and engineering revises the drawing in the system, yet somewhere a machinist still works from a printed copy taped to their station. Similarly, a supplier ships parts to the old revision because the notice went to a general inbox nobody reads.
My Implementation Checklist
To prevent this, my implementation checklist covers a few unglamorous but critical steps.
- Make effectivity explicit. Every change states exactly when it takes effect: by date, by serial number, by lot, or by “use up existing stock first.” In my experience, ambiguous effectivity causes more mixed builds than anything else.
- Decide disposition for every affected item. Use as is, rework, return to vendor, or scrap. Each decision also needs a cost owner.
- Pull obsolete documents physically. Superseding them in the system is not enough. Supervisors remove old copies from the floor and confirm they did it.
- Get direct acknowledgment from suppliers. I want a named contact at the supplier to confirm receipt and confirm their own effectivity. For critical parts, we also run a first article inspection on the first delivery at the new revision.
- Close the loop. Approval does not close a change. Instead, we close it once we verify it in production and the records reflect what the shop actually built.
The Engineering Change Management Metrics I Watch
You cannot manage what you never look at. Therefore, I track these numbers on every program, reviewing them weekly with the core team and monthly with the sponsor.
- Cycle time by lane. How long from request to decision, and from decision to implementation. If Lane 1 changes take a week, something is broken.
- Open change backlog and age. A growing pile of old requests means the board is not deciding, or the team is generating changes faster than it can absorb them.
- Change volume by source. Customer driven, design error, supplier driven, manufacturing improvement, and regulatory. This tells you where change comes from, which in turn tells you where to invest in prevention.
- Changes by lifecycle phase. If many changes show up after release to production, then your early design reviews are not catching enough.
- Change budget burn. How much of the reserve the team has used, and how fast compared to project progress.
Prevention Beats Process
The breakdown by source deserves extra emphasis. GrabCAD once framed cost control in engineering change as a two pronged effort: preventing avoidable change in the first place, and improving the process for the changes that do happen. Most teams pour all their energy into the second. Yet the bigger savings usually come from the first. For instance, if thirty percent of your changes trace back to drawing errors, a better design review checklist will save more money than any approval workflow ever could.
Engineering Change Management Mistakes I Still See (and Have Made)
A few patterns come up again and again across industrial projects.
Process Design Mistakes
Treating the process as engineering’s problem. Engineering change management is a business process. It touches procurement, finance, quality, production, and sales. So if only engineering owns it, the other functions will treat it as someone else’s paperwork.
Designing the process for the worst case. Teams that one bad change has burned often respond by putting every change through maximum scrutiny. Unfortunately, that slows everything down and pushes people to work around the system. Instead, design for the common case and escalate the exceptions.
Letting urgent changes skip the record. There will always be emergencies, such as a line down, a safety issue, or a customer shipment at risk. For those, have an expedited path that lets you act now and document within twenty four hours. What you cannot allow, however, is acting now and never documenting at all.
People and Mindset Mistakes
Forgetting the people. Every change asks someone to stop doing something the way they know and start doing it differently. Explaining why, briefly and respectfully, therefore goes a long way toward getting the change right.
Confusing activity with control. A process that generates a lot of forms does not necessarily control anything. The real test is whether, at any moment, you can say exactly what the current baseline is and which changes are in flight.
Final Thoughts on Engineering Change Management
Projects do not stall because of change. Rather, they stall because of unmanaged change, which shows up as surprises, rework, disputes, and that slow erosion of trust between the people building the product and the people paying for it.
Fortunately, the fix is not complicated. First, separate change from creep. Next, make the record mandatory but light. Then classify changes so small ones move fast and big ones get proper attention. In addition, give your change control board real authority and a real budget. Push decisions as early in the lifecycle as you can. Finally, measure the whole thing so you know where your changes come from.
Do that, and engineering change management stops being the thing that slows your projects down. Instead, it becomes the thing that lets you say yes to customers with confidence, because you know exactly what yes will cost.
Frequently Asked Questions
What is engineering change management?
Engineering change management is the structured process for proposing, evaluating, approving, implementing, and documenting changes to a product, process, or the documents that define them across the product lifecycle. Emeritus offers a good overview in this Emeritus guide.
What is the difference between an ECR, an ECO, and an ECN?
An ECR proposes a change and starts the evaluation. An ECO is the approved decision package that lists every affected item, cost, and disposition. Finally, an ECN communicates the approved change so teams can implement it. Arena explains the relationship in its ECO form glossary.
Who sits on a change control board?
Typically, representatives from engineering, quality, procurement, and manufacturing, and often external design partners or key suppliers, each assessing the impact on their own area. See Arena’s ECO overview.
How is scope change different from scope creep?
The people accountable for the project raise, assess, and approve scope change. Scope creep, however, happens outside the agreed scope without approval or agreement on cost. PMI covers this in Command and Control: Preventing Scope Creep.
Why do late engineering changes cost so much more?
Under the rule of ten, the effort to implement a change rises roughly tenfold with each lifecycle phase, because late changes ripple into tooling, inventory, suppliers, and production. CENIT explains this in its article on change cost risks.
How can you speed up engineering change management approvals without losing control?
Classify changes by risk so low impact changes follow a lighter path, run impact analysis in parallel, and support the process with PLM tools that surface affected items automatically. PTC outlines this in its PLM best practices post.
References
- PTC. 7 Best Practices in Engineering Change Management
- Arena Solutions. What is an Engineering Change Order (ECO)?
- Arena Solutions. What is an Engineering Change Order Form?
- Project Management Institute. Command and Control: Preventing Scope Creep
- CENIT. Leveraging Data and Transparency to Reduce Cost Risks in Engineering Change Management
- GoEngineer. The Hidden Cost of Late Engineering Changes
- Saarland University. Engineering Change Management and Change Impact Analysis (International Design Conference, 2008)
- GrabCAD Blog. Controlling the Cost of Engineering Change
- SPK and Associates. Late Stage Engineering Changes in Product Development
- Emeritus. Engineering Change Management: A Guide to Successful Product Changes
- Project Management Academy. Understanding and Managing Scope Creep
