In one line: Once a design is released, every change goes through a controlled path (request, evaluation, approval, implementation, verification), so that everyone builds, tests and supports the same configuration.
Core idea
Products change constantly after release: parts become obsolete, defects are found, customers ask for features, costs must come down. Uncontrolled change is dangerous. Manufacturing builds one version, test verifies another, and service supports a third. Configuration management keeps the official definition of the product, and the engineering change order (ECO) process controls how it changes. The engineering release process is the gate where a design first becomes official.
How it works
The questions every ECO process answers:
| Question | Typical answer |
|---|---|
| Who can request a change? | anyone, through an engineering change request |
| How is it evaluated? | impact analysis on form, fit, function, cost, schedule, safety, certification, inventory and documentation |
| Who signs off? | a change control board with engineering, manufacturing, quality, supply chain, service and program representatives; customer approval for some classes |
| How is it validated and approved for implementation? | analysis and test evidence, updated drawings and software, first-article inspection |
| How is it implemented? | an effective date or serial number, what happens to existing inventory and fielded units, and communication to everyone affected |
Classifying changes keeps the process proportionate. Minor documentation fixes move fast; changes that affect form, fit, function or safety get full review.
In practice
Engineers often experience change control as bureaucracy, until the day a change slips through without it. A related, quieter problem is knowledge continuity. When past designs and their rationale are scattered across shared drives, teams redo work that has already been done, or repeat past mistakes. A searchable catalog of previous designs, used as the first place to look before starting new work, is a simple change that saves a great deal of effort. It is a good example of an organizational change any engineer can champion (see Leading Change).
Questions to ask yourself
- Can I describe my company’s ECO path from request to implementation?
- Who sits on our change control board, and which function is missing?
- Before I start a new design, where do I look for what has already been done?
Connections
- Part of: Systems Engineering Process (configuration management). Feeds: Risk Management.
- Organizational parallel: Adaptive and Transformational Change, Leading Change. Software side: Software in Engineered Products.
- Capabilities exercised: Responsibility and Urgency to Deliver, Decision Making, Ethical Actions and Integrity.
Sources
- NASA (2007) Systems Engineering Handbook [1]
- Course assignment on change management and engineering release; no public source.