Change Management (Engineering)

In engineering, change management is the disciplined process for proposing, assessing, approving, carrying out and checking changes to a product, system or plant once its design has been agreed. Wikipedia describes the change request management process as covering the requesting, feasibility assessment, planning, implementation and evaluation of changes to a system, with the main goals of supporting the processing of changes and making them traceable across all the factors they touch.

The idea sounds bureaucratic, and engineers often experience it that way. But it exists for a hard-won reason. Almost every complex system changes after it is first designed: customers ask for new features, tests reveal faults, suppliers stop making parts, regulations change, or operators find a quicker way of doing a job. Each change, however small, can ripple through other parts of the system in ways that its proposer did not foresee. A formal change process forces someone to ask, before the change is made, what else it will affect, whether it is worth the cost, who needs to know, and how anyone will be able to tell later what was done and why.

The term covers several overlapping practices. In product development and manufacturing it is usually called engineering change management, built around engineering change requests and engineering change orders. In defence, aerospace and large systems engineering it sits inside configuration management, where the formal step is called configuration control. In software it overlaps with version control, release management and IT service management. In chemical plants, refineries and other hazardous processes it is called management of change (MOC), and in the United States it is a legal requirement for many facilities. This article covers all of these, explains the standard steps and roles, and looks at what happens when change is not managed, using documented accidents investigated by the UK Health and Safety Executive and the US Chemical Safety Board.

Note that "change management" in business usually means something different: helping people and organisations adapt to new structures, systems or ways of working. That organisational sense is not the subject here, although engineering change processes do depend on people following them.

Why engineering changes need managing

Systems keep changing

The need for change management follows from a basic fact about engineered systems: they rarely stay fixed. Wikipedia cites Lehman's laws of software evolution, formulated by the computer scientist Meir Lehman, which say that systems in real use must keep changing or become progressively less useful, and that as they change their complexity tends to increase unless work is done to reduce it. Lehman's observations were about software, but the same pattern holds in hardware. The Wikipedia article also notes that manufacturing faces frequent change because of global competition, advances in technology and demanding customers, and that in information technology the effort spent on maintenance and change can exceed the effort spent on building the system in the first place.

Changes interact

The main danger of a change is not the change itself but its interactions. A slightly stronger bracket may be heavier and push a vehicle over its weight limit. A new software library may fix one bug and expose another. A pump replaced with a different model may run at a different pressure and stress downstream piping. A procedure shortened to save time may skip a step that a safety analysis depended on. Engineers call the job of tracing these effects change impact analysis, and it is the heart of every formal change process.

Records matter

Even a good change becomes a problem if nobody can tell later that it was made. Maintenance staff need to know which version of a part is fitted, operators need procedures that match the equipment, and investigators need to reconstruct what the system looked like on the day something went wrong. The NASA Systems Engineering Handbook, discussing configuration management, warns that poor control can lead to the release of incorrect, ineffective or unsafe products, and advises that correcting systemic problems early is better than explaining later why incorrect or misidentified parts caused major problems.

History and context

Formal engineering change control grew out of large engineering projects in the twentieth century, especially in defence and aerospace, where thousands of contractors and engineers worked on the same systems and where a mismatch between drawings and hardware could be lethal or enormously expensive. The US Department of Defense developed configuration management standards and handbooks, of which MIL-HDBK-61A (dated 7 February 2001) is a well-known guidance document. Civil standards followed, notably the ANSI/EIA-649 family of configuration management standards (now published by SAE International), and ISO 10007, the international guideline on configuration management.

In the process industries, the decisive push came from disasters. The explosion at Flixborough in England in 1974, caused by an improvised and unchecked modification, became a landmark case study. In the United States, the Occupational Safety and Health Administration's Process Safety Management standard, 29 CFR 1910.119, published in 1992, made a written management of change procedure mandatory for facilities handling highly hazardous chemicals above set thresholds.

Academic study of engineering change grew alongside. A 1999 paper by G. Q. Huang and K. L. Mak in the International Journal of Operations & Production Management drew on a 1996 investigation of 100 UK manufacturing companies, covering their change systems, organisation, activities, influencing factors, strategies, techniques and computer aids. In 2011, Jarratt, Eckert, Caldwell and Clarkson published a widely cited review, "Engineering change: an overview and perspective on the literature", in Research in Engineering Design, covering the stages of the change process, the tools that support it, the effects of product complexity and architecture, and the organisational side of change.

The core process

Wikipedia's account of change request management, drawing on academic sources, breaks the process into six main activities. Different organisations use different names, but nearly every formal process covers the same ground.

Step 1: identify the potential change

Changes arrive in different forms. Wikipedia distinguishes three: a customer may require new functionality (a requirement), encounter a problem (a problem report), or propose a change directly (a change request). In manufacturing, the formal document is often called an engineering change request (ECR). In defence contracting, a formal proposal from a contractor to the customer is called an engineering change proposal (ECP).

A good change request says what should change, why, and how urgent it is. It should also say what the current configuration is, so that everyone is talking about the same baseline.

Step 2: analyse the request

Two questions are asked here, and Wikipedia notes they can be answered in either order:

• Technical feasibility. Can the necessary resources be acquired or developed in the time required? Is the change technically possible without breaking something else?
• Costs and benefits. What effort, money and disruption will it take, and what will it gain? This is sometimes called economic feasibility.

Step 3: evaluate and decide

A decision-making body, usually called a change control board or configuration control board (CCB), reviews the request, the feasibility study and the cost–benefit case and makes a go/no-go decision. In smaller organisations the project manager may make the decision. The NASA Systems Engineering Handbook describes a CCB as chaired by the person with change authority for the programme or project, with members who represent stakeholders and can commit their teams' resources.

The change request's key attribute, in Wikipedia's model, is exactly this decision. A request can be rejected, deferred, or approved, sometimes with conditions.

Step 4: plan the change

Planning starts with a change impact analysis, which works out how far the change will reach: which parts, drawings, software modules, procedures, training materials, spare-parts stocks and suppliers are affected. The output is a change plan. Wikipedia notes that approved changes can be saved up and batched at this stage, so that several small changes are made together in one release instead of one at a time.

Step 5: implement the change

Implementation means more than making the edit. Wikipedia lists the activities as executing the change, propagating it to the other affected parts of the system (and possibly to other systems), testing, updating documentation and releasing a new system release. Execution and propagation are highly interdependent and usually happen at the same time, and testing may loop back if problems are found.

Step 6: review and close

Finally, the change is verified, which means confirming in the new release that it does what was required and meets earlier requirements. Only then is the record closed. In Wikipedia's model, the project manager performs the verification and closes the change log entry.

Roles

Wikipedia identifies four roles in the change process. One person can hold more than one role, especially in a small team.

In larger organisations, a configuration manager or configuration management function maintains the records, checks that changes are properly classified and makes sure the right people review them.

Key terms

The vocabulary of change management can be confusing because similar words mean slightly different things in different industries. The following table brings together the main terms.

Deviations and waivers

Deviations and waivers deserve a closer look because they are often misunderstood. Wikipedia describes a deviation as an authorisation to depart from a requirement for an item before it is created, and a waiver as the same kind of authorisation during or after its creation. It calls both a form of minimal change management, because they deal with an immediate case without solving the underlying problem. NASA's handbook adds that a waiver releases a programme from a requirement without changing the baseline, and notes that some NASA centres use "deviation" for departures known before implementation and "waiver" for those found during implementation.

In practice, a stream of waivers against the same requirement is a warning sign. Either the requirement is wrong and should be changed properly, or the design or process cannot meet it and needs fixing.

Change management inside configuration management

In systems engineering, change control is one of several linked functions of configuration management. The NASA Systems Engineering Handbook, which adopts the principles of the SAE/EIA-649 standards, lists five:

Baselines

Change control only makes sense against a baseline. NASA's handbook describes a series of baselines that are established at major reviews:

As a project moves from one baseline to the next, more of the design is under formal control, and changes become harder and more expensive to make, which is one reason engineers try to settle requirements early.

Classes of change

Most change systems sort changes by significance so that small corrections do not need the same scrutiny as a redesign. NASA's handbook distinguishes major changes, which have significant impact (for example on retrofits, specifications, cost, safety, interface compatibility or training), from minor changes, which correct or modify documentation without affecting interchangeability. It adds that changes affecting external interfaces need approval from all affected stakeholders.

US defence practice uses a similar split between Class I and Class II engineering change proposals. Under MIL-HDBK-61A, Class I changes must be dispositioned (approved or disapproved) by a properly constituted government configuration control board, while Class II changes, which do not affect the contract's key characteristics, are typically dispositioned by the government's administrative contracting officer or plant representative unless the contract says otherwise. A commonly used summary is that Class I changes are those affecting form, fit, function, cost, schedule, guarantees or safety. The handbook describes itself as guidance only and says it should not be cited as a requirement; contracts set the actual rules.

Management of change in process industries

Why process plants are different

In a chemical plant or refinery, a change that seems minor to an engineer at a desk can create a path to fire, explosion or toxic release. Wikipedia's article notes that changes to industrial process plants are critical to safety and that the discipline in this context is called management of change, or MOC.

The legal requirement in the United States

The US Process Safety Management standard (29 CFR 1910.119) requires covered employers to "establish and implement written procedures to manage changes (except for 'replacements in kind') to process chemicals, technology, equipment, and procedures; and, changes to facilities that affect a covered process." Paragraph (l) of the standard requires the procedures to address, before any change:

The standard also requires that affected operating, maintenance and contract employees be informed of and trained in the change before start-up, and that process safety information and operating procedures be updated where the change affects them. A related paragraph requires a pre-startup safety review for new facilities and for modified facilities when the modification is significant enough to require a change in the process safety information, confirming among other things that modified facilities meet the management of change requirements.

The phrase "replacement in kind" is important. Swapping a valve for an identical one does not need the full MOC process. Swapping it for a different model, material or rating does, because the replacement is no longer "in kind".

What the UK HSE found about control systems

The UK Health and Safety Executive's guidance Out of control: Why control systems go wrong and how to prevent failure (HSG238, second edition 2003) analysed 34 incidents involving control and safety systems. Some incidents had more than one cause, and 56 causes were identified in total. The HSE grouped each incident's primary cause by the phase of the system's life in which it arose.

Source: UK HSE, Out of control (HSG238, 2nd edition, 2003), Table 2.

Two findings stand out for change management. First, one in five primary causes was inadequate control of modifications after the system was in service, all seven of them under the heading "inadequate modification" (none were attributed to decommissioning). Second, the largest single category, inadequate specification, is also partly a change issue: HSG238 notes that many incidents involved faults whose impact had not been considered in the safety requirements specification, and it recommends formally reviewing upstream activities to check whether their results are affected by later decisions. In other words, changes made later in a project need to be checked against the assumptions made earlier.

One incident in HSG238 shows how this plays out. At a facility with shielded cells for radioactive work, three separate changes had been made to protective systems at different times: modifications to a key-exchange interlock system, a software change to the programmable logic controller that allowed two doors to be open together, and a temporary software override authorised under a temporary plant modification proposal. The PLC change had not been devised by the design staff, had not been tested, and contained a simple coding error that made the interlock ineffective. The software changes were regarded as minor because they were meant to improve matters, so they received only a local check, not a formal hazard assessment. The temporary modification was correctly recorded, then forgotten, and never reversed. HSE's conclusion was that both temporary and permanent modifications need to be correctly categorised for appropriate safety assessment, and the site arranged for hazard assessments of modifications to be reviewed by staff independent of operating management.

Case study: Flixborough, 1974

The explosion at the Nypro (UK) site at Flixborough on Saturday 1 June 1974, at about 16:53, is the textbook example of an unmanaged change. According to the HSE's case history, Reactor No. 5 in a chain of reactors had developed a vertical crack that leaked cyclohexane on 27 March 1974. Rather than repair it, the company removed the reactor and installed a 20-inch bypass pipe to connect Reactors No. 4 and No. 6 so that production could continue.

The HSE lists the failings of that modification. Only limited calculations were done on the integrity of the bypass line. None were done for its dog-leg shape or for the bellows used to connect it. No drawing of the modification was produced. The pipework was never pressure tested. In the late afternoon of 1 June, the bypass ruptured, releasing a large quantity of cyclohexane that formed a flammable cloud and found an ignition source, causing a massive vapour cloud explosion.

Source: UK Health and Safety Executive, Flixborough (Nypro UK) explosion case history.

Eighteen of those killed were in the control room, where windows shattered and the roof collapsed; no one there escaped. Fires burned on the site for about ten days. The HSE notes that the main office block was unoccupied at the time, which probably limited the number of casualties. Wikipedia's article on change management cites Flixborough specifically: the improvised bypass was neither documented nor risk-assessed.

Every element of a basic change process was missing. There was no formal request, no engineering analysis of the new design, no review by a competent board, no drawing, no test and no verification before restart.

Case studies: Equilon and CONDEA Vista, 1998

The US Chemical Safety and Hazard Investigation Board (CSB) issued a Safety Bulletin on management of change in August 2001 (No. 2001-04-SB). It discussed two incidents from 1998 and made a point that is easy to miss: MOC should apply to operational deviations and variances, not only to planned changes in technology, processes and equipment.

Equilon, Anacortes, Washington. On 25 November 1998, a fire at the Equilon Enterprises refinery's delayed coking unit caused six deaths. A storm had cut electric power and steam about 37 hours earlier, leaving one coke drum only partly filled with hot, tarry oil. No written procedure existed for handling a partly filled drum, even though an internal team had recommended one after a similar interruption in 1996. Supervisors and operators, without engineers present, decided that because the outside of the drum felt cool and temperature sensors read about 230°F (against about 800°F for a typical full drum), it was safe to open. In fact only the material near the walls had cooled; the core remained hot. When the bottom head was lowered, hot petroleum vapour escaped and ignited, killing the supervisor, an operator and four contract workers. The CSB noted that heat-transfer calculations would have shown that weeks were needed for the drum contents to cool by losing heat to the surroundings, and concluded that the incident could have been avoided if the "change" had been managed by a team with hands-on operating experience, safety knowledge and engineering calculation skills.

CONDEA Vista, Baltimore, Maryland. On 13 October 1998, a reaction vessel explosion and fire at the CONDEA Vista detergent alkylate plant injured four people. About three months earlier, the plant had changed its process technology, replacing the direct addition of aluminium chloride catalyst with powdered aluminium that formed aluminium chloride in the reactor. Soon afterwards, the reactor became fouled with sludge-like catalyst residue that plugged its bottom outlet. Staff decided to clear the plug with water and then steam, even though a sample of the sludge had reacted with water, producing hydrochloric acid gas and heat. The instruction to the night shift was a one-line note written after a telephone conversation.

The CSB stressed that in neither case was there an emergency requiring rapid decisions. Time was available to look into the circumstances more thoroughly. The bulletin quotes guidance from the Center for Chemical Process Safety (1989) that a variance procedure should require an explanation of the planned deviation, the reasons for it, the safety, health and environmental considerations, the control measures, and the duration, with approval at a level of management that matches the risk.

Change management in product development and manufacturing

The engineering change in practice

In manufacturing, an engineering change usually means a change to a part, assembly, drawing, bill of materials or specification after it has been released for production. Wikipedia's article gives a hypothetical automotive example: if airbags were found to inflate spontaneously after long drives, customer complaints or problem reports from testing would generate a change request. After cost–benefit analysis, approval, impact analysis and scheduling, the fix would be implemented and tested before release.

The practical work of an engineering change in a factory typically includes:

• deciding when the change takes effect (the effectivity), for example from a serial number, a date or when current stock runs out;
• deciding what to do with existing stock, work in progress and parts already in the field;
• updating drawings, the bill of materials, routings and inspection plans;
• notifying suppliers and, where required, customers or regulators;
• updating spares, service manuals and training.

Why changes are costly

Engineering changes are often described as expensive because their effects multiply: one changed part can require new tooling, new testing, revised documentation, scrapped stock and retrofits. The literature reviewed by Jarratt and colleagues in 2011 explores how product complexity, architecture and the degree of innovation influence how far changes propagate, and how organisational structure and people's attitudes affect how well changes are handled. Products with tightly coupled components tend to spread changes more widely; modular designs with clean interfaces tend to contain them.

Tools

Modern change management in manufacturing is usually supported by product data management (PDM) or product lifecycle management (PLM) software, which holds the current and past versions of parts and documents, routes change requests for approval and records decisions. Wikipedia's references include a book on integrating product data management with software configuration management, reflecting the fact that many products now combine hardware and software that must change together.

Change management in software

Software teams face the same problems at higher speed. Wikipedia's software example follows the same steps: users report bugs or request features; the company assesses feasibility and cost; the work is planned (for example using function points to estimate size); code is changed and the change is propagated to dependent code; the result is tested; documentation is updated; a new release is issued; and the change log entry is closed.

Several tools and practices carry out parts of this process:

Software also illustrates a tension in change management. Very heavy approval processes slow teams down and can encourage people to work around them. Very light processes allow changes that break things. Many teams address this by classifying changes by risk, so that low-risk, routine changes follow a pre-approved path and only higher-risk changes go to a board, much as NASA and defence practice separate major and minor or Class I and Class II changes.

A worked example (hypothetical)

The following example is invented to show how the steps fit together. It is not based on a real company.

A small company makes a wall-mounted electric heater. Field reports show that a plastic knob occasionally cracks in cold warehouses. A service engineer raises a change request to replace the knob material with a tougher grade.

1. Identify. The change request records the problem, the affected part number, the current drawing revision and the field reports.
2. Analyse. Engineering confirms the new material can be moulded in the existing tool (technically feasible). Purchasing reports that the new material costs more per knob. The cost–benefit case compares that extra cost with the cost of warranty replacements.
3. Evaluate. The change board, made up of engineering, quality, production, purchasing and service, approves the change.
4. Plan. The impact analysis finds that the knob drawing, the bill of materials, the material specification, the moulding process sheet and the spare-parts listing all need updating. The colour of the new material is slightly different, so the marketing photographs also need checking. The board sets effectivity from the next production batch and decides that existing knobs in stock will be used up in a warm-climate market rather than scrapped.
5. Implement. The drawing is revised, the material changed, sample knobs are cold-tested, documents are released and suppliers are notified.
6. Review and close. Quality confirms that the first production batch passes the cold test and that the documents match what is being built. The change record is closed.

Even this simple case touches seven or eight documents and five departments. A change made by a single engineer phoning the moulding supplier would have fixed the knob but left the drawings, spares and records wrong.

Good practice

Across the standards and case studies above, a consistent set of good practices emerges:

Common problems

Changes made outside the process. The most dangerous changes are the ones that never enter the system: an operator's workaround, a maintenance fitter's substitute part, a quick software patch. Training staff to recognise what counts as a change is as important as having a procedure.

"Minor" changes that are not minor. In the HSG238 shielded-cell case, software changes were judged minor because they were intended to improve safety, so they escaped a formal hazard assessment. Categorisation rules should be based on what a change could affect, not on its intent or apparent size.

Forgotten temporary changes. Temporary modifications need an expiry date and a named owner responsible for reversing them.

Process overload. If every trivial change needs a board meeting, people will avoid the process or rush reviews. Risk-based classification helps.

Poor records. If the change log, drawings and physical product disagree, the configuration is effectively unknown. Configuration audits exist to catch this.

Overlap and confusion. Wikipedia's own article notes that change request management overlaps with change control and configuration management, and that the three are not yet fully integrated in its account. In practice, organisations need to decide which process owns which kind of change.

Misconceptions

"Change management is just paperwork." The paperwork is a means to an end: making sure someone has thought about the effects of a change and that others can find out later what was done. The Flixborough bypass had no drawing, no calculations on its critical features and no pressure test; the absence of paperwork reflected the absence of engineering.

"Only hardware changes need managing." OSHA's standard covers changes to process chemicals, technology, equipment and procedures. The CSB bulletin explicitly extends MOC to operational deviations and variances.

"A like-for-like replacement is always exempt." Only a true "replacement in kind" is exempt under PSM. A part that is different in material, rating or design is a change.

"A waiver fixes the problem." A waiver or deviation lets one item through. It does not change the requirement or the design. Wikipedia calls this minimal change management for that reason.

"Emergencies justify skipping review." Sometimes a real emergency requires immediate action, and good processes include an emergency path with review afterwards. But in both of the 1998 incidents the CSB examined, there was no emergency; time was available to look more carefully.

Frequently asked questions

What is the difference between change management and configuration management?

Configuration management is the broader discipline of identifying, controlling, recording and auditing a system's configuration over its life. Change management (or change control) is the part of configuration management that handles proposed changes to that configuration.

What is an engineering change order?

It is the document that authorises and describes an approved change, typically listing the affected parts and documents and when the change takes effect. It usually follows an engineering change request that has been reviewed and approved.

Who sits on a change control board?

Typically representatives of the groups affected by changes: engineering, quality, manufacturing or operations, safety, purchasing, service and project management. NASA's handbook says members should represent stakeholders and be able to commit their teams' resources, with the board chaired by the person holding change authority.

Is management of change required by law?

In the United States, OSHA's Process Safety Management standard (29 CFR 1910.119) requires written MOC procedures for covered processes involving highly hazardous chemicals. Other industries and countries have their own regulatory requirements; contracts and quality standards often require change control even where the law does not.

What is a "replacement in kind"?

A replacement that satisfies the design specification of the item it replaces, such as an identical spare. Under PSM, replacements in kind are excluded from the management of change requirement.

How is a deviation different from a waiver?

A deviation is permission given before manufacture to depart from a requirement; a waiver is permission given during or after manufacture to accept an item that does not meet a requirement. Neither changes the baseline.

How long should a change take to approve?

It depends on the risk and complexity. Low-risk, routine changes may be pre-approved; complex changes to safety-critical systems may require extensive analysis and multiple reviews. OSHA's list of required considerations includes the necessary time period for the change, which means planning time is part of the process, not an afterthought.

Summary

Engineering change management is the set of practices that keeps a complex system understandable and safe as it evolves. Its core steps are to identify the change, analyse its feasibility and costs, decide formally, plan with a proper impact analysis, implement and propagate the change with testing and documentation, and verify and close the record. It sits within configuration management in systems engineering, appears as engineering change requests and orders in manufacturing, as version control and release management in software, and as legally required management of change in hazardous process industries. The UK HSE found that inadequate control of changes after commissioning was the primary cause in 20% of the 34 control-system incidents it analysed, and accidents such as Flixborough in 1974 and the Equilon refinery fire in 1998 show what happens when changes, whether to hardware or to operating practice, bypass engineering review.

Sources

• Change management (engineering) — Wikipedia)
• UK Health and Safety Executive — Out of control: Why control systems go wrong and how to prevent failure (HSG238, 2nd ed., 2003)
• UK Health and Safety Executive — Flixborough (Nypro UK) explosion, 1 June 1974: case history
• US OSHA — 29 CFR 1910.119, Process safety management of highly hazardous chemicals
• US Chemical Safety Board — Safety Bulletin No. 2001-04-SB: Management of Change
• NASA Systems Engineering Handbook — 6.5 Configuration Management
• Huang, G. Q. and Mak, K. L. (1999). Current practices of engineering change management in UK manufacturing industries. International Journal of Operations & Production Management 19(1)
• Jarratt, T. A. W., Eckert, C. M., Caldwell, N. H. M. and Clarkson, P. J. (2011). Engineering change: an overview and perspective on the literature. Research in Engineering Design 22, 103–124