Engineering change management (ECM) is the formal process of proposing, reviewing, approving, and implementing changes to a product’s design, components, or manufacturing processes. It exists to make sure that when something about a product needs to change, whether to fix a defect, improve performance, or meet new regulations, that change happens in a controlled, documented way that doesn’t create downstream chaos. Every industry that designs and manufactures physical products relies on some version of this process, from aerospace and automotive to medical devices and consumer electronics.
How the Process Works
Engineering change management follows a structured lifecycle that moves a change from “someone noticed a problem” to “the fix is live in production.” The process typically begins with a problem report or opportunity: someone on the engineering team, manufacturing floor, or even a customer identifies an issue with the current design. That observation gets documented and evaluated to determine whether it warrants a formal change.
From there, the process flows through three core documents, each serving a distinct purpose:
- Engineering Change Request (ECR): A formal proposal submitted by the engineering team describing what needs to change and why. Cross-functional teams across the organization review the ECR and decide whether to accept or reject it based on its potential impact.
- Engineering Change Order (ECO): Once a request is approved, the ECO carries the actual design changes into production. It specifies exactly what will be modified, including updated drawings, part numbers, materials, or assembly instructions.
- Engineering Change Notice (ECN): The implementation and communication document. The ECN creates execution plans for delivering the change across the organization, tracks all actions taken, and allows for auditing and validation of results before updated data is formally released.
There’s also a less talked-about step: deviations and waivers. Sometimes a temporary change to a product or process is needed, perhaps while waiting for a permanent fix or to use up existing inventory. These get captured within the same change workflow so nothing slips through undocumented.
The Change Control Board
Most organizations route change requests through a Change Control Board (CCB), a group of people representing every function the change could touch. A typical board includes engineering leads, the project manager, manufacturing representatives, quality assurance, and often people from sales, finance, or supply chain depending on the scope of the change. Customers, suppliers, and end-user representatives sometimes participate as well.
The board’s job is to debate the pros and cons of a proposed change from every angle. An engineer might confirm the design is sound, while a finance representative flags the cost of retooling, and a supply chain manager raises concerns about existing inventory that would become obsolete. By having all these perspectives in one room, the CCB determines whether the change is worth the impact it will have on schedule, budget, and product quality. Once a decision is made, it gets communicated to the project team and, when relevant, the customer.
The most effective boards stay proactive rather than reactive. They set timelines for review, define clear criteria for approval, and align every change with broader organizational goals rather than treating each request in isolation.
Impact Assessment: What Changes Actually Cost
Before any change gets approved, a thorough impact assessment is essential. This is where organizations figure out the true cost of making a change, and the true cost is almost never just the engineering hours to redraw a part.
A proper assessment evaluates how the change affects functionality, performance, production cost, project schedule, and regulatory compliance. It also accounts for less obvious costs: existing inventory that may need to be scrapped, tooling that needs modification, supplier contracts that require renegotiation, and production downtime during the transition. Changes to business processes, workforce training needs, and the tools or technologies that support the wider organization all factor in. The total cost of change management activities, including training, needs to be fully understood before a change is approved to proceed.
Skipping this step is how companies end up with changes that solve one problem while creating three others. A redesigned bracket might improve durability, but if it doesn’t fit existing assembly fixtures, the downstream costs can dwarf the original savings.
Regulatory Requirements
For companies operating in regulated industries, engineering change management isn’t optional. It’s a compliance requirement.
ISO 9001:2015, the international quality management standard, addresses change control in several clauses. Clause 6.3 requires that changes to the quality management system be carried out in a planned manner. Clause 8.3.6 specifically covers design and development changes, requiring that identified changes be reviewed and controlled to ensure no adverse impact on product conformity. Clause 8.5.6 extends this to production, requiring organizations to review and control changes to ensure continuing conformity with requirements. The standard also mandates that organizations review the consequences of unintended changes and act to prevent or mitigate adverse effects.
Medical device manufacturers face additional scrutiny. The FDA’s 21 CFR 820.30(i) requires companies to establish and maintain procedures for the identification, documentation, validation (or verification where appropriate), review, and approval of design changes before their implementation. In practice, this means every design change to a medical device must have a documented trail showing it was properly evaluated and approved before it reached a patient.
How PLM Software Automates the Process
Running engineering change management through email chains and spreadsheets works until it doesn’t, which is usually around the time a change gets approved but never communicated to the manufacturing floor. Product Lifecycle Management (PLM) software automates the workflow to prevent exactly these kinds of failures.
Modern PLM systems let organizations configure formal and fast-track workflow processes tailored to their needs. When a change request is submitted, the system automatically routes approvals to the appropriate stakeholders based on predefined rules tied to organizational structure and procedures. Each stakeholder receives automatic notifications of their action items, whether that’s a review task, an approval, or an implementation step. Built-in dependencies and automated scheduling help teams close out change orders faster by giving each person exactly the tasks they need, in the right sequence.
The real value is visibility. Instead of wondering where a change request is stuck, everyone involved can see real-time status updates. This reduces the back-and-forth that typically stretches change cycles from days into weeks.
Measuring Performance
Two metrics matter most when evaluating how well your change management process is working. Cycle time, the duration from when a change is first proposed to when it’s fully deployed, is the clearest indicator of process efficiency. Tracking it week over week reveals delivery delays and bottlenecks that might not be obvious from any single change request. If your average cycle time is creeping upward, something in the review or approval chain is breaking down.
Change failure rate, the percentage of implemented changes that introduce new defects or require rollback, measures quality. A low cycle time means nothing if half your changes need to be reversed. Tracking this metric by initiative or product line can reveal whether certain types of changes or certain teams consistently produce cleaner results than others, giving you a concrete place to focus improvement efforts.
Seven Practices That Reduce Errors and Delays
Organizations that manage engineering changes well tend to follow a consistent set of practices. First, they establish clear, documented procedures outlining how changes are proposed, evaluated, approved, and implemented, with defined roles and responsibilities at every step. Second, they conduct thorough impact assessments before approving any change, examining effects on functionality, cost, schedule, and compliance.
Third, they perform explicit risk analysis, evaluating how a proposed change could affect existing systems, workflows, and dependencies. This includes preparing contingency plans in case an implemented change doesn’t produce expected results. Fourth, they prioritize cross-functional collaboration, keeping all relevant parties informed of approved changes, their implications, and expected outcomes.
Fifth, they establish a Change Control Board with key stakeholders who review and prioritize change requests against predefined criteria. Sixth, they test and validate proposed changes in a controlled environment or through simulations before full implementation. And seventh, they document everything: the rationale for the change, technical specifications, risk assessments, cost implications, and implementation schedules. That documentation isn’t just bureaucracy. It’s the audit trail that proves the change was managed responsibly, and it’s the institutional knowledge that prevents the same mistakes from being repeated.