First and foremost it is important to understand that in most companies the engineering change management process is not just one process. There are several processes that make up the engineering change management process framework. The reasons why one change management process typically is not enough are that there are multiple steps between noticing that there is something wrong and implementing a change to fix what’s wrong, and that changes get more complex as a product, part or document matures and moves to the later stages of the life cycle. And that should be reflected in the processes for each stage of the life cycle. But let’s take it one step at a time.

1. Not every problem requires an engineering change

The first step to making the ECM process more efficient is to acknowledge that not every problem will result in an engineering change. There can be different reasons why a peg doesn’t fit into a hole, and hence there are also different ways to get to a solution. One reason certainly is that engineering made a mistake and maybe added a wrong dimension on the drawing, and so the peg was manufactured too big. This situation would be solved with an engineering change. But it could also be because the hole was drilled too small, maybe also because the dimension was wrong, or maybe because a wrong or a worn-out tool was used. That may or may not require an engineering change. If someone just picked the wrong tool that would be solved not through an engineering change, but through a non-conformance report (NCR) resulting in rework of the hole and making it bigger so that it conforms again to the specified design. Another possibility could be that someone on the shop floor wanted to put the peg into the wrong hole. That’s a human error that cannot be solved either with an engineering change nor an NCR, but instead will require better training or better work instructions. Another reason could be that the wrong peg was delivered to the assembly station. This could be because the wrong pegs were placed in the right inventory location, or the pegs were picked from the wrong inventory location. Both would again be human errors that cannot be fixed with an engineering change, but likely with better training or marking inventory locations more clearly.

What does that mean though for the engineering change process? It means that not everything should start with the assumption that it’s going to be an engineering change. Instead the process should start with giving anyone inside or outside of the organization the ability to report a problem or an issue without already knowing or having to guess how to fix it. And that can be done through a simple Issue Report (IR) process that becomes the first step of the ECM process. In the example above, the person on the shop floor who cannot fit the peg into the hole should be able to easily report the problem he or she is having without knowing the solution, i.e. whether it will require an engineering change or something else. And the analysis of the reported problem should happen very quickly and unbureaucratically, i.e. without involving a large number of people. It is not practical to expect the person to now wait a few days until a change board analyzed the issue as part of a change request and then decides that it doesn’t actually require an engineering change.

2. Not every requested engineering change can or should be implemented

If the analysis of the problem shows that an engineering change might indeed be required, the ECM process should proceed to the second step, the Engineering Change Request or ECR. However, at this point it is important to recognize that not every requested change can or should be implemented, and that any work should only be done after the requested change and its impact are thoroughly analyzed and approved.

I have seen companies where after an engineering change is initiated, the models, drawings and documents are immediately modified and then the change is reviewed and hopefully approved. But what if the engineering change isn’t approved? And not because the drawing hasn’t been modified correctly, but because it turns out it can’t be done technically, it’s too expensive, or the decision is simply made not to do it. Now all the work to do the modifications was done for nothing. And not only that, but it now may even require more work to undo the modifications again and put everything back to how it was before.

A properly defined ECR process will avoid this inefficiency and wasted effort. The first step of an ECR should be to determine what exactly needs to be changed. Going back to the example, does the peg have to be changed or the hole? Or maybe both?

Then the requested changes should be documented using light weight visualization files, such as 3D PDF models or 2D PDF drawings, that are marked up indicating what exactly needs to be changed. In the above example, assuming the dimension on the peg was wrong, that wrong dimension should be highlighted on the model or the drawing and if possible at this point it should be indicated what the correct dimension is.

Now that it is clear what exactly needs to be changed, the requested changes should be reviewed by usually a cross-functional change review board (CRB). This CRB will determine 1) whether the change can be technically implemented, 2) how the change should be implemented, 3) what the impact is of the change if it is implemented, 4) what the effort and cost is of the change and whether it is possible and worth implementing it considering everything that will be affected, 5) when the change should be effective if it is implemented, and 6) what should happen to parts and products that have already been manufactured or ordered and are in inventory in a wrong state.

During this review it may turn out that the change cannot be implemented as it was requested. Or it cannot or should not be implemented at all, for whatever reason. And that’s okay. Fortunately nothing has been changed yet.

3. Implement only after the requested engineering change is approved

If on the other hand the CRB approves the engineering change, it can now move to the last step, and that is the implementation of the change through the engineering change order (ECO) or engineering change notice (ECN) process. The terms ECO and ECN are used interchangeably, often based on preference. I personally like ECO better, because we are now asking (ordering) the affected parties to implement everything that needs to be done as part of the requested and approved engineering change. But again, that’s semantics.

The first step is now usually to plan the implementation of the change. All the different tasks need to be determined and in case of more complex changes, an actual implementation plan should be created with tasks, completion dates and assigned resources. The change should basically be handled like a project, and it is often advisable to assign a change implementation lead. Having a change implementation lead assigned can help to significantly speed up the implementation of engineering changes.

The next step of course is to create new revisions or entirely new parts and documents in the PLM system and create new or modify all affected models, drawings and documents to reflect the requested change. Then suppliers need to be notified, manufacturing may need to change tools, fixtures, as well as work and assembly instructions, quality may need to update test procedures and equipment, operations may need to disposition the inventory based on the decision made by the CRB, which could be discarding everything, reworking existing inventory, or using everything as is, if the latter two are possible.

To summarize, a best-in-class engineering change management process consists of three stages: It starts with an issue report (IR) that, if a change can fix the problem, turns into an engineering change request (ECR) to review, analyze and approve the change, which if approved turns into an engineering change order or notice (ECO or ECN) to implement the changes.

But does every engineering change always go through all three stages? The short answer is no. The long answer is it depends on the life cycle phase of the part or product that needs to be changed, on the person who initiates the process and on the complexity of the potential change.

4. Each lifecycle phase has its own engineering change process

Each product, part and document usually goes through several phases during its life or existence. It may start in a concept phase, then go to planning, design, prototype or testing, validation, production, support, and lastly to recycling or obsolescence. Typically the definition matures and more parties or business functions are involved as the product, part or document moves to later phases.

During the concept phase, only very few people or functions are involved in creating the concept. It may simply exist as a sketch, a set of high-level requirements and maybe a rough model and drawing. If something needs to change, only the few people that know about the concept would have to be involved in the change. Consequently, the change process in the concept phase can consist of only a few steps that can be completed in minutes, if we even need one. Most likely we don’t need an IR because nobody outside of the engineering team even knows about the concept, we probably don’t need an ECR because there is very little impact a change would have at this point, and we may not even need an ECO because the part or product is not yet under official change control, i.e. it is not revision controlled.

In the design phase the product is now well defined. Detailed requirements, models, drawings and specifications exist that may have been shared with different business functions and maybe even external parties, such as suppliers or a customer. Changing the product now involves all the parties with which the product information has been shared, and it usually requires buy in and approval by everyone. Hence the process to change something in the design phase is significantly more involved and complex. Maybe we still don’t need an IR, because if something is wrong at this point, it has very likely to do with the design. But we may need a simple ECR because the product that is being designed could be at least partially using production parts that have already been released and are in production.

Once in the production phase, the part or product is now of course fully defined, and most internal business functions, as well as suppliers and customers must be involved in a change. Production and testing equipment may be affected, finance may be affected, other products using the part may be affected, etc. And, as described earlier, someone on the shop floor or a supplier encountering a problem may not know what the solution is, i.e. whether an engineering change is required or not. Hence in this phase we definitely need an IR to enable everyone to quickly report a problem they have with the part or product. We also need an ECR, because if an engineering change is a possible solution, the impact of that change will have to be carefully analyzed before we approve the change. And then of course we need the ECO to actually implement the change.

5. The process should take into consideration who is involved

When defining a process it should always be done considering who needs to perform a certain task and what they are able to do. If someone one the shop floor, a supplier or a customer encounters a problem, it is not realistic to expect them to know how to solve the problem, i.e. whether an engineering change is required or not. All they know is that it doesn’t work the way they think it should work. So it not practical to ask them to submit an ECR, because that would assume they know a change is a possible solution. That’s why in this instance the affected party should simply start the process by submitting an IR and be able to leave the rest to the experts.

If on the other hand an engineer identifies a wrong dimension on a drawing of a part that is in the design phase, it may suffice to just create an ECO because no impact will have to be analyzed as part of an ECR.

However, the process should never allow a user to make the decision which part they need to perform. The process needs to be defined so that, based on their role, a user always follows the same process. As Murphy’s law states, if something can go wrong, it will go wrong. So if we leave it up to the user to make that decision, they will eventually make a wrong decision.

So someone on the shop floor for example should only be given the option to submit an IR. An engineer involved in developing a product that is still in the concept phase should only be able to submit an ECO. And a designer who is working on a customer project that uses a product that is in the production phase should always start an engineering change by submitting an ECR.

6. The engineering change management process should not be used for other purposes

Lastly, the engineering change management process should only be used for engineering changes. I have seen many times that companies use the ECM process also to create new parts and documents and to promote parts and documents to different release states, like from In-Work to Review to Frozen, or whatever those states are called in the different PLM systems, and even to release parts to different life cycle phases.

However, creating parts and documents as well as promoting and releasing parts are different activities with different business purposes, that usually require different participants and different tasks. If that is all combined into the engineering change management process, the result usually is an unnecessarily complex ECM process that is difficult to define, to configure in the system, to execute, to manage and also to maintain.

By following these six best practices for engineering change management outlined above companies I have worked with have been able to reduce average processing times, efforts and costs of engineering changes by up to 60%.