Engineering Change Management (ECM) in Engineering Projects: Change Control, Impacts, and Traceability

Understand how to apply Engineering Change Management (ECM) in engineering projects, from ECR through approval, impact assessment, implementation, configuration control, and traceability.

Check it out!

Engineering Change Management (ECM) is the process used to identify, record, analyze, decide, implement, and verify changes affecting project engineering. Its purpose is to prevent changes to requirements, drawings, specifications, equipment, interfaces, or execution methods from being incorporated informally without a complete assessment of technical, safety, schedule, cost, contractual, documentation, and operational impacts.

In this article, ECM means Engineering Change Management, or engineering change management. The acronym does not refer to Enterprise Content Management or organizational change management. The focus is on technical control of changes that modify configuration, baselines, or engineering-project deliverables.

A consistent ECM process connects engineering, Project Controls, procurement, contracts, construction, commissioning, and operations. It turns a need for change into a traceable decision: the change is formalized through a request, analyzed by affected disciplines, submitted to the competent authority, converted into an authorized instruction, propagated to documents, and verified before closure.

What Is Engineering Change Management (ECM) in Engineering Projects

Engineering Change Management is a technical-governance discipline that controls changes during project development and implementation. Its scope begins when a new condition, incompatibility, improvement opportunity, or additional requirement may modify the approved solution. The process ends only when the decision has been implemented, verified, documented, and reflected in the current configuration.

A change may appear small in the document that originated it and still produce systemic effects. Changing equipment power may require revisions to electrical supply, protection, cables, ventilation, structure, automation, signal lists, budget, purchase orders, schedule, tests, and operating procedures. ECM exists to identify these dependencies before the change is released for implementation.

ECM, Integrated Change Control, Configuration, and Documents

Concept	Main function	Engineering application
Engineering Change Management — ECM	Control the complete engineering-change lifecycle	Requirements, solution, interfaces, equipment, execution, and final configuration
Integrated change control	Evaluate changes affecting the plan and baselines	Scope, schedule, cost, quality, risks, resources, and contracts
Configuration management	Keep functional and physical characteristics under control	Technical baselines, configuration items, versions, and approved state
Document control	Manage issue, revision, approval, and distribution	Drawings, design reports, specifications, lists, and records
Contractual change management	Formalize consequences between the parties	Scope, price, schedule, conditions, and responsibilities

ECM acts as a bridge among these systems. An approved technical change needs to update the configuration; when it affects the plan, it goes through integrated change control; when it changes contractual obligations, it requires the mechanism established in the contract; and in every case, it must be distributed through controlled documents.

ECR, ECN, ECO, and CCB

Terminology varies among organizations. The acronyms below are common, but the project procedure should define the terms adopted.

Acronym or term	Meaning	Function
ECR — Engineering Change Request	Engineering change request	Record need, justification, and initial assessment
ECN — Engineering Change Notice	Engineering change notice	Communicate an authorized or pending change
ECO — Engineering Change Order	Engineering change order	Technically authorize implementation
CCB — Change Control Board	Change control board	Evaluate and decide according to authority level
Change Register	Change register	Consolidate status, decisions, owners, impacts, and deadlines
Configuration Baseline	Configuration baseline	Represent the approved set of characteristics
Change Order	Contractual change	Formalize effects on obligations, price, schedule, or conditions

ECR and ECO do not need to be separate forms in small projects. The essential requirement is to separate request, analyze, authorize, implement and verify, while preserving history, responsibilities, and evidence.

Why ECM Is Critical in Engineering Projects

Engineering projects are multidisciplinary and progressive. Definition evolves from feasibility through detailed design, while successive decisions commit resources, contracts, equipment, and construction. The later a change occurs, the greater the number of elements that tend to depend on the previous configuration.

In early phases, a change may require only a new analysis. After procurement, it may require renegotiation with suppliers. During execution, it may cause rework, loss of productivity, or stoppage. Near commissioning, it may invalidate tests and acceptance evidence. This relationship should be considered together with the project lifecycle.

Which Changes Should Enter the ECM Process

Any change capable of modifying an approved requirement, expected performance, technical solution, interface, configuration item, baseline, safety condition, contractual obligation, or information used to manufacture, procure, install, test, operate, or maintain the system should enter ECM.

Not every editorial correction requires multidisciplinary analysis. However, classifying a change as “just a drawing revision” without examining its content is a mistake. The criterion should be the potential effect of the change, not the document format.

Sources of Engineering Changes

Changes may originate from the owner, designer, supplier, contractor, operator, oversight team, regulatory authority, or field condition. Major triggers include:

• modification of owner or user requirements;
• correction of error, omission, conflict, or incompatibility;
• need identified through risk or safety analysis;
• standards, regulatory, or licensing change;
• equipment unavailability or substitution;
• value engineering or constructability improvement;
• field condition differing from design information;
• interference among disciplines or systems;
• change of supplier, technology, material, or method;
• result of inspection, FAT, SAT, or commissioning;
• schedule, budget, logistics, or operational constraint;
• RFI, nonconformity, or pending item whose resolution changes the engineering.

An RFI may clarify without changing anything; a nonconformity may be corrected in accordance with the design; a risk may be treated without changing the baseline. When the response modifies the approved solution, the case should be linked to a controlled change.

Classification by Nature

Class	Example	Analyses normally required
Requirement	New capacity, availability, or operating condition	Business case, architecture, validation, and acceptance
Technical	Change in sizing, topology, or specification	Calculations, compatibility, safety, and performance
Configuration	Substitution of component, material, firmware, or model	Equivalence, interoperability, documentation, and maintenance
Interface	Change in boundaries among disciplines or suppliers	Responsibilities, connections, data, sequence, and tests
Construction	Change in method, access, sequence, or assembly	Constructability, safety, resources, schedule, and quality
Regulatory	New legal, standards, or environmental requirement	Compliance, licenses, and evidence
Contractual	Addition, removal, or modification of an obligation	Scope, price, schedule, risks, and notices
Operational	Change in operation, maintenance, or contingency	Procedures, training, availability, and assets
Emergency	Immediate action to control severe risk	Exceptional authorization, temporary control, and regularization

The same change may belong to several classes. Equipment substitution may affect interfaces, electrical consumption, heat dissipation, protocol, schedule, cost, warranty, and spares.

Change, Deviation, Nonconformity, and Revision

Record	Characteristic	When to trigger ECM
Change	Proposes changing an approved condition or baseline	Always
Deviation	Records departure from a requirement or plan	When its acceptance changes the approved configuration
Nonconformity	Shows noncompliance with a requirement	When disposition is not simply correction according to the baseline
RFI	Requests clarification	When the response introduces a technical change
Pending item	Records an open action or decision	When the solution modifies a requirement or configuration
Document revision	New document version	When technical content is modified
Redline	Records a proposed or executed condition	When it differs from the released document
Editorial correction	Adjustment with no technical effect	Normally document control only

The distinction avoids bureaucratizing simple corrections while preventing relevant changes from being executed as clarifications or field adjustments.

Materiality and Project Phase

A change is material when it affects function, safety, compliance, interfaces, budget, critical path, committed equipment, executed work, testing, operations, or released documents.

Phase	Predominant impact	Recommended control
Feasibility and FEL	Assumptions, benefits, CAPEX, and risks	Update business case and continuation decision
Conceptual Design	Architecture, capacity, and interfaces	Compare alternatives and selection criteria
FEED and Basic Design	Requirements, bases, specifications, and estimates	Multidisciplinary analysis and contracting maturity
Detailed Design	Calculations, details, lists, and coordination	Strict configuration control
Procurement	Requisitions, equipment, manufacturing, and delivery	Assess commitments and suppliers
Execution	Field, method, rework, safety, and productivity	Approve before execution, except in emergencies
Commissioning	Tests, logic, performance, and evidence	Revalidate procedures and criteria
Closeout	Actual configuration and final documentation	Update As-Built, manuals, and asset records

The content on FEED, Basic Design and Detailed Design detail maturity evolution. ECM should prevent late decisions from being treated as if the project were still in the conceptual phase.

How the Request, Analysis, and Approval Flow Works

An ECM workflow needs to be formal enough to protect configuration and agile enough not to paralyze decisions. The recommended structure separates identification, recording, triage, integrated analysis, decision, authorization, implementation, and verification.

ECR: Identification and Recording

The need should be recorded before being incorporated into documents or construction. The ECR receives a unique code and links origin, requester, date, discipline, affected item, current condition, proposal, justification, urgency, and evidence.

Coding may reflect project, system, and sequence, such as PRJ-ECM-ECR-001. The code remains stable even if the change results in several documents or orders.

Triage and Alternatives

Triage confirms whether the case is a change, checks for duplication, defines priority, identifies disciplines, and selects the workflow. It may return an incomplete request or link it to an RFI, nonconformity, risk, contract, or pending item.

Relevant changes should not reach decision with only one assumed solution. Engineering should compare alternatives, including maintaining the current configuration, explicitly stating requirements met, risks, interfaces, cost, schedule, reversibility, and operational implications.

Integrated Impact Analysis

Each affected area records its assessment in a common basis. The coordinator consolidates contributions, highlights disagreements, and confirms whether interfaces were consulted. The RACI matrix defines participation but does not replace technical, financial, or contractual authority levels.

Decision and ECO

Decisions should be standardized: approved, approved with conditions, rejected, returned, suspended, deferred to a future phase, or canceled. The record should identify the version analyzed, participants, justification, and conditions.

Approval needs to be converted into an executable instruction. The ECO — Engineering Change Order — defines the authorized alternative, affected documents and items, owners, deadline, restrictions, verifications, effects on baselines, and linkage to any contractual change order.

Implementation and Closure

The status “approved” does not mean “implemented.” Implementation includes engineering revision, document issue, procurement, manufacturing, construction, parameterization, testing, and communication. When several packages are involved, the change may be decomposed and linked to the WBS.

Closure confirms current documents, withdrawal of obsolete versions, consistency of materials and equipment, completion of tests, updates to contracts and baselines, As-Built documentation, manuals, asset records, and communication to stakeholders.

Minimum ECR Checklist

• ☐ Unique identification and date
• ☐ Requester, origin, and owner
• ☐ Current condition
• ☐ Proposed change
• ☐ Justification and expected benefit
• ☐ Affected requirements and items
• ☐ Related documents, contracts, and assets
• ☐ Disciplines and interfaces involved
• ☐ Criticality and urgency
• ☐ Alternatives considered
• ☐ Preliminary impacts
• ☐ Attachments and evidence
• ☐ Required decision and deadline

Emergency Changes

An emergency may justify immediate action when there is severe risk to people, the environment, the asset, continuity, or compliance. This does not eliminate ECM; it only changes the sequence. The emergency workflow should define authority, intervention limits, temporary controls, preservation of evidence, regularization deadline, verification, and update of the final configuration.

How to Assess Technical, Contractual, Schedule, and Cost Impacts

Impact analysis is the core of ECM. Deciding solely on direct cost can overlook incompatibilities, rework, delays, productivity loss, additional testing, contractual obligations, and operational consequences.

Dimension	Main questions	Typical evidence
Requirements	Are function, capacity, and acceptance still satisfied?	Requirements matrix, Basis of Design, and calculations
Safety	Does the change introduce risk or alter compliance?	Risk analysis, technical opinions, and approvals
Engineering	Which disciplines, calculations, and interfaces change?	Document list and multidisciplinary analysis
Constructability	Can the solution be executed under the available conditions?	Method, field conditions, resources, and sequence
Procurement	Does it affect supplier, purchase order, manufacturing, or logistics?	Requisitions, orders, and promised dates
Schedule	Does it affect logic, critical path, float, or milestones?	Schedule, fragnet, and path analysis
Cost	What direct, indirect, and lifecycle costs arise?	Estimate, quotations, and forecast
Contract	Does it change obligations, price, schedule, or risk?	Contract, notices, and administrative opinion
Testing	Does it invalidate inspections, FAT, SAT, or acceptance?	ITP, protocols, and records
Operations	Does it affect training, maintenance, or continuity?	Manuals and operational analysis
Configuration	Which baselines and documents must be updated?	Propagation matrix and master list
Risks	Which risks are introduced or removed?	Risk register and responses

The risk management in engineering projects must be updated. Risk and change are not synonymous: risk is uncertainty; change is a proposed or actual alteration. A change can be a response to risk and can also create new risks.

Schedule, Cost, and Cumulative Impact

Schedule analysis should insert the change into the current schedule and evaluate logic, resources, procurement, float, critical path, milestones, mitigation, and acceleration. The physical-financial schedule shows why schedule, measurement, and cost cannot be assessed separately.

The estimate should state scope, assumptions, exclusions, base date, sources, and degree of definition. It may include engineering, materials, order cancellations, manufacturing, logistics, labor, supervision, mobilization, rework, testing, extended presence, productivity, and lifecycle costs.

Direct impact belongs to the changed work. Indirect impact results from effects on other activities. Cumulative impact arises when several changes produce a combined effect that cannot be attributed to a single change. Successive small changes can fragment work fronts, reduce productivity, and consume engineering capacity.

Technical Change, Change Order, and Claim

An engineering change is not automatically a contractual change. First the technical need is identified and analyzed; then responsibilities are verified, effects are quantified, and the contractual mechanism is applied.

When there is agreement, the effect may be formalized through a change order, amendment, work order, or equivalent instrument. When there is disagreement over entitlement, responsibility, price, or schedule, the case may evolve into a claim. The content on EPC and EPCM helps explain risk allocation.

Technical approval does not replace commercial authorization, and commercial approval does not dispense with technical validation.

When to Revise the Baseline

Not every change justifies rebaselining. Changing the reference simply to eliminate variances destroys performance history. Revision is appropriate when a formally authorized change makes the previous baseline inadequate by changing scope, budget, schedule, milestones, or strategy.

History must be preserved. The system distinguishes the original baseline, authorized revisions, current schedule, and forecast. The Earned Value Management depends on this discipline.

How to Control Configuration, Documents, and Implementation

ECM produces results only when the decision reaches all affected elements. The change does not end in the CCB minutes or with issuance of a drawing. Requirements, documents, materials, equipment, software, parameters, construction, and operational records all need to be controlled.

Configuration Items and Baselines

A configuration item is a controlled element whose characteristics need to be identified, approved, and traceable. It may be a requirement, system, equipment, component, software, logic, parameter, interface, document, model, or installed assembly.

The configuration baseline represents the approved state. It may be functional, design, manufacturing, construction, or As-Built. The procedure defines when it is established, who approves it, and which changes require formal control.

Document Propagation Matrix

Changed element	Potentially affected documents
Functional requirement	URS, OPR, Basis of Design, requirements matrix, and acceptance
Capacity or load	Calculations, balances, diagrams, lists, and specifications
Equipment	Datasheet, requisition, materials, drawings, and maintenance
Layout	Drawings, sections, supports, access, and safety
Electrical supply	Single-line diagram, demand, cables, protection, and selectivity
Automation	Narrative, I/O, cause and effect, software, and tests
Communications	Architecture, addressing, protocols, and cybersecurity
Execution method	Procedure, risk, planning, and inspection
Test criterion	ITP, FAT, SAT, commissioning, and acceptance
Operating condition	Manual, training, maintenance, and asset record

In BIM projects, the ISO 19650 series supports information management, but ECM also applies without BIM.

Information States and Implementation Package

The system should distinguish states such as drafting, review, approved, released for procurement, manufacturing or construction, canceled, superseded, and As-Built. There must be no doubt about which version is valid for each purpose.

Relevant changes should generate a package containing the ECO, drawings, analysis memorandum, method, safety, materials, responsibilities, implementation window, inspection, testing, rollback where applicable, and completion criteria.

Field, Redlines, and Commissioning

The field team should not alter the solution for convenience without authorization. Redlines document a proposed or executed condition but do not constitute automatic approval. The final configuration needs to be consolidated in the As-Built.

Changes after testing may invalidate evidence. The commissioning should indicate which verifications need to be repeated and how the change affects technical acceptance.

Closure should distinguish physical, documentary, technical, contractual completion, and communication to operations.

How to Structure ECM Governance, Metrics, and Audit

Governance defines policy, roles, authority levels, criteria, workflow, information, and oversight. ECM should be integrated with processes and governance, rather than operating as a parallel register disconnected from documents, schedule, costs, and contracts.

Policy, CCB, and Authority Levels

The policy establishes principles and responsibilities; the procedure describes types, materiality, urgency, status, documentation, roles, authority levels, deadlines, CCB, integrations, rebaselining, emergencies, metrics, and audit.

The CCB evaluates changes above delegated authority levels or with relevant multidisciplinary impact. It may include the owner, manager, engineering, Project Controls, contracts, procurement, construction, commissioning, operations, safety, and quality. The matrix should indicate who recommends, who decides, and who is consulted.

Authority levels may consider safety, requirements, value, schedule, critical path, disciplines, contracts, shutdown, reversibility, and operational exposure. A safety or compliance change should not be simplified merely because it has low cost.

Recommended Roles

Role	Main responsibility
Requester	Record need and initial information
ECM Coordinator	Manage workflow, deadlines, and integration
Technical Lead	Develop alternatives and consolidate engineering
Affected disciplines	Evaluate interfaces and consequences
Project Controls	Analyze schedule, cost, baseline, and forecast
Procurement	Evaluate suppliers, orders, and logistics
Contracts	Verify obligations, change orders, and claims
Construction	Evaluate field conditions, method, safety, and rework
Commissioning	Evaluate tests and acceptance criteria
Operations	Evaluate maintenance, training, and assets
CCB or authority	Approve, reject, or impose conditions
Verifier	Confirm implementation and closure

In projects with Owner’s Engineering, the role may include independent analysis, impact consolidation, evidence verification, and support for owner decisions without replacing the responsibilities of designers, suppliers, and contractors.

Metrics

Metric	What it reveals
Open changes by status	Volume and bottlenecks
Backlog age	Risk of delayed decisions
Time from ECR to decision	Analysis efficiency
Time from approval to implementation	Execution capacity
Returned requests	Input quality
Emergency changes	Exposure and planning maturity
Unauthorized changes	Serious control failure
Cost and schedule impact	Cumulative consequence
Origin and discipline	Sources of instability
Reopening	Implementation quality
Documentation pending	Configuration discrepancy
Recurring causes	Effectiveness of lessons learned

Audit, Errors, and Maturity

The audit should make it possible to reconstruct origin, baseline, analysis, decision, instruction, revisions, execution, tests, impacts, and closure. Independent assurance is useful for critical changes, significant rebaselining, disputes, or changes close to acceptance.

Recurring errors include executing before approval, analyzing only the originating discipline, ignoring procurement and operations, estimating only direct cost, changing the baseline to eliminate variance, closing without field verification, and failing to update As-Built documentation or manuals.

Level	Characteristics
Reactive	Changes identified after execution and scattered records
Controlled	Form, register, and basic approval
Integrated	Engineering, schedule, cost, risk, contracts, and configuration connected
Managed	Authority levels, metrics, audit, and cause analysis
Optimized	Historical data, prevention, automation, and continuous improvement

Implementation can start simply as long as essential controls are preserved. A complex form does not compensate for undefined authority or lack of verification. Recurring causes should feed lessons learned.

Technical References

[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21500:2021 — Project, programme and portfolio management — Context and concepts.

[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management.

[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21505:2017 — Project, programme and portfolio management — Guidance on governance.

[4] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge — PMBOK Guide. 8. ed.

[5] AACE INTERNATIONAL. Recommended Practice 10S-90: Cost Engineering Terminology.

[6] AACE INTERNATIONAL. Recommended Practice 39R-06: Project Planning as Applied in Engineering and Construction for Capital Projects.

[7] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Information management using BIM.

[8] FIDIC. Conditions of Contract for EPC/Turnkey Projects. 2. ed. Silver Book, 2017.

[9] FIDIC. Client/Consultant Model Services Agreement. 5. ed. White Book, 2017.

Frequently Asked Questions

What Is Engineering Change Management (ECM)?

It is the process of identifying, recording, analyzing, approving, implementing, and verifying changes affecting requirements, configuration, documents, equipment, interfaces, or execution of an engineering project.

What Is the Difference Between ECR and ECO?

ECR is the request that describes and justifies the change. ECO is the authorization to implement the approved alternative. Terminology varies, but requesting and authorizing should remain separate.

What Is a CCB in Engineering Projects?

CCB is the committee or governance body that evaluates relevant changes and recommends, approves, conditions, or rejects their implementation according to authority levels.

Does Every Drawing Revision Need to Go Through ECM?

No. Editorial corrections may remain within document control. Revisions that modify requirements, solution, interfaces, configuration, manufacturing, construction, testing, or operations should be evaluated through ECM.

Is ECM the Same as a Change Order?

No. ECM controls the technical change and its impacts. A change order is a contractual instrument when the change alters obligations, price, schedule, or conditions.

How Should Emergency Changes Be Handled?

Through an exceptional workflow defining authority, intervention limits, temporary controls, evidence, regularization deadline, subsequent verification, and configuration update.

When Does a Change Require Rebaselining?

When an authorized change materially alters scope, budget, schedule, milestones, or strategy and makes the previous baseline inadequate. History should be preserved.

Is Specific ECM Software Required?

No. The process can begin with controlled records. Complex projects benefit from platforms that relate changes to requirements, documents, schedules, costs, contracts, risks, and configuration.

Complementary Technical Materials

Whitepapers

• Owner’s Engineering: framework executivo para contratação, governança e aceite
• Projeto: o investimento que reduz riscos, custos e retrabalho

Technical Articles

• Engineering Projects
• Project Lifecycle
• Project Controls
• Processes and Governance in Engineering Projects
• Risk Management in Engineering Projects
• Procurement in Engineering Projects
• Engineering Construction Execution
• As-Built in Engineering

Technical Guides

• Project Management: Complete Guide to Engineering, Governance, and Control
• Complete Guide to Engineering Consulting

Related Services

• Project Management: Owner’s Engineering from Start to Technical Acceptance
• Project Management: Schedule, Costs, and Earned Value
• EPCM: Integrated Implementation Management

Related Solutions

• Project, Program, and Portfolio Governance
• Contract, Scope, and Deliverables Management
• Requirements, Evidence, and Acceptance-Criteria Management
• Engineering Metrics, Dashboards, and Executive Reports
• Engineering PMO Implementation and Structuring