Why “Engineering Change” No Longer Describes How Change Really Works
Did you know that studies repeatedly show that up to 30 percent of engineering effort can be consumed by change-related rework when downstream consequences are discovered late?
In many engineering-led organisations, the term “engineering change” is still widely used. However, it increasingly fails to describe how change actually unfolds in modern product companies.
What begins as a change to a product design often triggers further design changes. These, in turn, propagate into development activities, verification and approval processes, production, service, and the supply chain. As a result, changes rarely remain confined to engineering.
This is why many organisations are no longer dealing with engineering change in isolation, but with enterprise change management: changes whose consequences span multiple functions, systems, and stages of the value chain.
Studies and industrial experience consistently indicate that when the impact of change is not understood early, organisations pay for it later. Longer lead times, increased rework, quality issues, and avoidable costs are common outcomes. In some environments, it has been observed that up to 30 percent of engineering effort may be consumed by change-related rework when downstream consequences emerge late.
In most cases, the issue is not the change itself, but the point at which its impact becomes visible.
Planning and Time-to-Market: Why Plans Often Break Down Without Impact Analysis
In Lean Product Development, optimistic planning assumptions are recognised as a source of waste. Decisions made without sufficient understanding of consequences may appear reasonable initially, but tend to unravel during execution.
Change planning is particularly exposed to this risk. Without impact analysis, it becomes difficult to estimate lead time, assess resource availability, sequence work effectively, or anticipate downstream constraints.
Changes compete not only on importance, but also on when and how they consume scarce competencies. An organisation may have the necessary skills available in principle, yet find them fully committed elsewhere. The resulting waiting time contributes directly to longer lead times and reduced predictability.
Without a clear understanding of change propagation, time-to-market estimates often rest on hope rather than control.
Change Propagation in Design
Change propagation frequently begins in design, but not all design impacts are equally visible.
Some impacts are relatively straightforward to identify, such as direct changes to the bill of materials. Others are more subtle. Geometric and interface-related changes often require detailed CAD analysis, while system-level or architectural impacts demand broader system understanding rather than inspection of individual artefacts.
The more abstract the dependency, the easier it is to overlook. Research into change propagation suggests that design changes can spread in non-linear ways, where seemingly minor modifications give rise to disproportionately large downstream effects.
Propagation into Development, Verification, and Approval
Design changes seldom end with updated drawings or models. They propagate into development work, affecting task definitions, sequencing, and resource allocation.
Changes frequently influence test scope, verification activities, and formal approval processes, particularly in regulated environments. When such implications are identified late, rework and retesting become unavoidable, often under significant time pressure.
Many schedule delays attributed to “engineering issues” originate at this stage, rather than in the initial design activity.
Propagation into Production and Service
Once the consequences of a change reach production or service, organisational flexibility is significantly reduced.
Typical impacts include modifications to tooling and fixtures, changes to production processes, updates to work instructions and documentation, and adjustments to service procedures and spare parts.
At this stage, even modest oversights can prove costly. Late discoveries are difficult to reverse and may result in temporary workarounds, quality risks, or delayed product launches.
Logistics and Supply Chain Effects
The effects of change on logistics and the supply chain are often underestimated.
Changes may result in obsolete or scrapped inventory, updated supplier specifications, altered lead times, and additional coordination or transport effort. Many of these costs can be avoided if downstream functions are aware of forthcoming changes early enough to respond.
In the absence of early impact analysis, organisations are frequently forced into reactive responses rather than planned adjustments.
Impact Analysis as a Cross-Organisational Capability
Impact analysis is, by its nature, cross-organisational.
Although PDM, PLM, and ERP systems all provide forms of change management functionality, each remains largely confined to its own domain. PDM systems focus on design data, PLM systems on development workflows, and ERP systems on production, inventory, and cost. None of these systems, on their own, offers a complete view of enterprise-wide impact.
As a result, impact analysis often falls between systems and between organisational boundaries.
To be effective, impact analysis must draw input from engineering, production, supply chain, quality, and service, and must be applied before, during, and after change execution.
Before development, impact analysis supports informed prioritisation based on propagation risk, resource availability, anticipated lead time, and expected financial return.
During development, it enables coordination and adjustment as new information emerges, reducing waiting time, replanning, and the need for emergency changes.
After development, comparing actual outcomes with expected impact helps close the learning loop and improve future decision-making.
Impact analysis is not a checklist. It is an organisational capability.
Conclusion: Impact Analysis as a Means of Enterprise Control
Enterprise changes cross functional boundaries, systems, and responsibilities. They cannot be effectively managed through isolated workflows or approvals alone.
Impact analysis should not be understood as documentation, CAD analysis, or a software feature. Rather, it provides decision support, underpins planning, supports risk management, and protects capital investment.
Organisations that understand the consequences of change early are better positioned to move quickly and predictably, not by working harder, but by avoiding unnecessary rework, delays, and surprises.