The ECM Process Step by Step

Whether you’re working under ISO 10007, EIA-649, or another regulated design control framework, ECM processes generally follow the same basic steps, with variations in terminology and approval routing.

1. Submit an Engineering Change Request (ECR)

The process begins when someone identifies a need to modify an established baseline. Teams document the problem, the proposed fix, which configuration items are affected, and a preliminary assessment of technical, cost, and schedule impact. Teams then classify the change. EIA-649 and its military predecessor MIL-STD-973 distinguish between Class I changes (affecting form, fit, function, safety, or compliance, requiring full CCB approval) and Class II changes (minor corrections that the CCB can delegate).

2. Assess Impact and Risk

Before the CCB commits resources, the downstream effects need to be clear. Teams typically review a few key dimensions:

• Technical feasibility: Engineers confirm interface compatibility, safety constraints, and design integrity, and identify required updates to drawings, code, and specifications.
• Cost and schedule: Program owners estimate budget exposure and shifts to integration, verification, or release milestones.
• Risk: Quality and systems engineering update hazard analyses and failure mode and effects analyses (FMEAs), then confirm the remaining risk is still within acceptable bounds. Teams often manage this in a risk management workflow that keeps risk evidence linked to the change record.
• Regulatory: Regulatory teams determine whether the change affects submissions, standards conformance, or required verification per 21 CFR 820.30(i).
• Supplier: Supply chain teams evaluate effects on procurement and approved vendor lists, and confirm effectivity (the point at which the change takes effect by serial number, lot, or date) to prevent uncontrolled mixing of old and new parts.

These inputs give the CCB what it needs to make a decision backed by evidence rather than assumptions.

3. Review and Approve Through the CCB

Class I changes go to the CCB for a formal decision. The board can approve, reject, or defer, and who sits on it varies by industry, but it typically includes engineering, quality, manufacturing, and configuration management. If the CCB approves, it also approves effectivity, verification evidence requirements, and any rollout constraints.

4. Execute the Engineering Change Order (ECO)

Once approved, the ECR becomes an ECO that authorizes implementation. The ECO covers bill of materials (BOM) changes, affected drawings and specifications, process modifications, effectivity, and an implementation plan. Execution follows the approved plan with updates to documentation, quality inspection, and training. Teams in regulated environments also define rollback criteria so production doesn’t continue against a partially implemented baseline.

5. Verify, Validate, and Close

Once a change is implemented, formal audits confirm it meets functional requirements and documentation standards. In aerospace and defense, teams typically use a Functional Configuration Audit (FCA) for performance and a Physical Configuration Audit (PCA) to check that what was built matches what was approved. The cycle wraps up with status accounting updates, baseline revisions, and archiving. Closure should include verification evidence so the record captures both what was approved and proof that it was actually implemented.

Common ECM Challenges

Even teams with formal ECM procedures hit recurring obstacles, and most trace back to evidence that’s either missing or disconnected from the decision it was supposed to support:

• Siloed teams and poor visibility: When teams can’t see the same baseline, parallel updates become conflicting ones, and that usually means duplicate ECOs, mismatched BOMs, and verification gaps.
• Manual workflows and version control breakdowns: When change workflows run through email and spreadsheets, a team can approve the right change and still ship the wrong configuration because the documentation on the floor isn’t the approved set.
• Losing sight of downstream effects: Poorly defined requirements drive avoidable change orders, especially when ambiguity creates miscommunication between design and supplier teams. Without clear traceability, the evidence linking a change to its downstream impact often doesn’t exist until someone asks for it.

In every case, the gap between what was decided and what actually happened is where audit findings, rework, and compliance risk live.

Best Practices for Effective ECM

Good ECM comes down to governance. Every change needs a clear owner, cross-functional input before approval, and enough documentation to prove the decision was informed.

Define Clear Procedures and Assign Ownership

Assign a single owner to each change, someone responsible for moving it from ECR submission through verification and closure. That owner makes sure nothing stalls between handoffs, and when an auditor asks why a change was made, they can point to a single record that answers the question instead of pulling five people into a room to reconstruct what happened.

Build a Cross-Functional CCB

A CCB pulled from a single discipline will miss things. A material substitution might pass engineering review but create a procurement problem, or a design change might clear quality but break a supplier qualification. Staffing the board with engineering, quality, manufacturing, and regulatory affairs is how those blind spots get caught before approval, and it’s also where effectivity, training needs, and production constraints get validated.

Document Everything and Maintain a Full Audit Trail

Every change record should capture what changed, why it changed, who approved it, what was affected, and how the change was verified. When an auditor or a new team member pulls up an ECO six months later, those five pieces should be there without anyone having to chase them down.

This is also how teams protect themselves from tribal knowledge loss, because when the reasoning is in the record, new engineers don’t have to reopen old debates to understand why a decision was made.

Measure ECM Performance with KPIs

KPIs give engineering leadership early warning when the change system is getting inconsistent or under-documented. Four metrics are worth tracking:

• ECO cycle time: The elapsed time from ECR submission to completed implementation, with targets that typically differ for routine versus major changes.
• Change effectiveness rate: The percentage of changes approved without rework or rejection, where a low rate signals weak upfront analysis.
• Implementation accuracy: The percentage of approved changes executed correctly the first time, tracked closely in regulated programs because errors trigger repeat validation.
• Audit trail completeness: Whether ECM records contain justification, risk evidence, dated approvals, verification results, and documented regulatory impact.

Tracking these metrics helps teams catch process drift before it shows up in an audit.

How Requirements Management Supports ECM

Requirements are change-controlled configuration items, which means every engineering change should link to the requirements it modifies and the test cases that verify it. That traceability is what turns a change log into a proof chain. When any part of it is missing, teams tend to find out through a failed test or an auditor asking for evidence the record doesn’t contain.

That proof chain only works if traceability stays current. Spreadsheet-based matrices fall out of date as soon as a requirement changes, and when upstream requirements shift, downstream artifacts like test cases, risk items, and design elements need to be flagged immediately so owners can assess the consequences before gaps grow.

Bringing ECM Under Control

The teams that run ECM well have one thing in common. They can trace any production configuration back through verification results, approval decisions, and evidence to the original change request. That traceability is what keeps configuration baselines credible and audit evidence current, and it’s what separates engineering governance from paperwork.

Jama Connect^®, a requirements management platform for regulated product development, supports this through Live Traceability™, which links requirements, design elements, test cases, and risk items in a single traceable record. When a requirement changes, the system flags each linked artifact so teams can run change impact analysis before the effects spread. Try Jama Connect free for 30 days and see how it connects change decisions to requirements, risk evidence, and verification records in one place.

Frequently Asked Questions About Engineering Change Management

What is the difference between an ECR, ECO, and ECN?

An ECR proposes a change and packages the rationale and impact analysis, but it doesn’t authorize any work to begin. An ECO is the formal go-ahead to implement, issued after the CCB reviews and approves the change. An ECN documents what was done and communicates the final revision details to everyone who needs to know.

What industries rely most on ECM?

Aerospace and defense programs tend to have the most rigorous ECM expectations because configuration audits and effectivity control are central to certification. Medical device manufacturers rely heavily on ECM because FDA design controls and ISO 13485 require documented approval of design changes before implementation. Automotive programs with ISO 26262 requirements face similar pressure.

How does ECM relate to configuration management?

ECM is one of the core functions within configuration management, alongside planning, configuration identification, status accounting, and verification and audit. Configuration management defines what the baseline is and how it’s identified, and ECM controls how that baseline is allowed to change and how you prove each change was properly evaluated.

What should you look for in ECM software?

Engineering teams typically look for software that enforces change workflows, approvals, and effectivity while keeping artifacts linked to the change record. In regulated work, strong traceability, signature control, and audit-ready reporting are common priorities, along with integration into existing application lifecycle management (ALM) and product lifecycle management (PLM) toolchains so change control doesn’t fall apart where one team’s tools end and another’s begin.