Engineering change management is the controlled process for changing a released part, drawing or document. Someone requests the change, the team analyses its impact, the right people approve it, and a new revision goes out to everyone who builds from it. Done well, it leaves a record of why something changed, who approved it, what it affected and when it took effect.
ECR, ECO, ECN and deviations
Companies use different vocabulary, but most teams work with some version of these four terms.
| Term | What it is | Typical question it answers |
|---|---|---|
| ECR (engineering change request) | A proposal to change something, with the reason and the problem it solves | Should we change this? |
| ECO (engineering change order) | The approved instruction to make the change, listing affected items and new revisions | What exactly are we changing, and who approved it? |
| ECN (engineering change notice) | The notification that tells production, purchasing and suppliers the change is released | Who needs to know, and from when? |
| Deviation | A temporary, limited permission to depart from the released design, for example for one batch | Can we ship this lot as is, without changing the design? |
Some organisations merge the ECR and ECO into one change record that moves through states. That works, as long as you record and link the request, the decision and the release. A deviation leaves the released revision unchanged, so never use one as a quiet substitute for an ECO.
A typical change process
Paper-based or software-based, most change processes follow the same steps.
- Raise the request. Anyone affected can propose a change: an engineer, a quality lead after a nonconformance, a supplier who cannot hold a tolerance. The request states the problem as well as the proposed solution.
- Triage. A change owner checks the request is complete, assigns it and decides whether it needs full review.
- Analyse impact. Identify every affected part, assembly, drawing, specification, test and label, plus inventory, work in progress and supplier commitments.
- Prepare the change. Engineers update the design and documents as working versions. Released items stay as they are.
- Review and approve. The defined approvers review the change package and sign off, in sequence or in parallel.
- Release. New revisions become effective and old revisions are marked superseded.
- Notify and implement. Production, purchasing and suppliers receive the change and confirm they are working to the new revision.
- Close. Someone verifies the change is implemented and closes the record, with evidence attached.
Impact analysis
Most change processes succeed or fail at impact analysis. A change to one part rarely stays with that part. Before approving, your team should be able to answer:
- Where is it used? Every assembly and product that contains the part.
- Which documents reference it? Drawings, specifications, work instructions, test procedures, labelling and technical documentation.
- What is in the pipeline? Stock on hand, open purchase orders and work in progress built to the old revision.
- What does it do to risk and verification? Whether the change affects risk analysis, requires new testing or invalidates earlier verification results.
- Who outside engineering is affected? Suppliers, contract manufacturers, service and customers who receive documentation.
Sub-components in neo. 1: the assembly uses PCB revision 5, but a newer revision exists. The label shows where a change has not yet been carried through.
If these answers depend on someone's memory, the analysis will be incomplete. The fix is in your data: the links between parts, documents and changes need to exist before anyone raises the change.
Approval roles and change boards
Most teams define approvers by role rather than by name, so the process survives holidays and reorganisations. A common set:
- Change owner, who drives the change to closure.
- Design authority, usually the responsible engineer or engineering lead.
- Quality, who checks that verification, risk and documentation are complete.
- Manufacturing or operations, who confirms the change can be built and plans the cut-in.
- Supply chain, when suppliers or purchased parts are affected.
- Regulatory, when the change may affect a submission, certification or declaration of conformity.
Larger organisations route significant changes through a change control board (CCB) that meets on a schedule. Smaller teams often do better with role-based approvals in parallel, where a change waits for the slowest approver instead of the next meeting.
Classifying changes
Classification lets minor changes move fast while major ones get full review.
| Class | Typical criteria | Typical handling |
|---|---|---|
| Minor | Documentation corrections, clarifications, no effect on form, fit or function | Short approval path, revision bump on the document |
| Major | Affects form, fit or function, safety, performance, regulatory status or interchangeability | Full impact analysis, cross-functional approval, planned cut-in |
For part numbers, the usual rule of thumb is the form, fit, function test. If the changed part is still interchangeable with the old one in every use, a new revision is usually enough. If it is not interchangeable, it normally needs a new part number, so nobody can confuse old and new in stock or in the field. Write your criteria down; arguing classification case by case is slow and inconsistent.
Common failure modes
Teams that outgrow their change process tend to hit the same problems.
- Approvals in email. You cannot show sign-offs scattered across threads to an auditor as a controlled approval, and nobody can tell which version of the attachment was approved.
- Untracked downstream effects. A part changes, but the assembly drawing, the test procedure or the label artwork does not.
- Suppliers on old revisions. You release the change internally, and the supplier keeps building from the PDF they received months ago.
- Changes made before approval. Someone edits the released file in place and writes the change record afterwards.
- Changes that never close. Open changes accumulate, and nobody knows which ones are implemented.
- Deviations that become permanent. Someone renews a temporary deviation until it is, in practice, the design.
What auditors look for
Auditors pick a change and follow it from request to production. For regulated hardware, their expectations come from a few sources:
- ISO 9001:2015 requires control of changes to documented information (clause 7.5.3), control of design and development changes (clause 8.3.6) and, for production, review and control of changes with retained information on the results of the review, the person authorising the change and any necessary actions (clause 8.5.6).
- ISO 13485:2016 clause 7.3.9 requires documented procedures for design and development changes, an evaluation of their significance and their effect on product, including product already delivered, and records of changes, their review and any necessary actions.
- FDA 21 CFR Part 820, now the Quality Management System Regulation, incorporates ISO 13485:2016 by reference since 2 February 2026, so the ISO 13485 change requirements apply to device manufacturers selling in the US.
- 21 CFR Part 11 applies when those approvals are electronic records and electronic signatures.
Expect the auditor to ask for the request, the impact assessment, the approvals with names and dates, the released revisions and evidence that the change reached production and suppliers. If producing that takes a day of searching, expect follow-up questions.
How neo handles engineering change
In neo, change requests, approvals and release dossiers are first-class objects, each linked to the documents and items it affects.
- Propose change from any item. The change starts from the part or document it concerns.
- Attach impacted documents to the change; impact analysis shows what is blocking release.
- Approval chains are configured per workflow. neo notifies reviewers in the app and by email.
- Parallel approvals let engineering, quality and suppliers review at the same time.
- Electronic signatures and audit trails are designed to meet 21 CFR Part 11 requirements, and neo logs every action with who, what and when.
- Release dossiers: neo assembles them automatically on approval, with metadata, signatures and artifacts, and you can export them to PDF for auditors.
- Supplier portals give external partners access to the released revisions they need, and nothing else.
Metadata links every artifact to the change that produced it, so you can answer "why is this revision different?" in one click. To see the flow with your own data, take the product tour or talk to us. For the document side of the same process, read engineering document control explained.