How to Fix a Broken Change Management Process

Change Management - Make Things Better

Is your change management process broken? If you work for a typical engineering firm, the answer is probably “yes” — in an Aberdeen Group study, 85% of respondents answered this question in the affirmative.

Below are a few questions that will help you assess your change management process.

Have you ever….

  • Made a change to a drawing, but then forgotten to update the title block?
  • Made a change to a drawing and the title block, but then overlooked some of the other sheets your change affected?
  • Spent a whole day (or a whole week) combing through drawings to make sure the cross-references are correct?
  • Discovered while installing a machine at a client’s facility that your production unit was working with version 7, while everyone else was on version 9?
  • Lost money on a project because you didn’t have accurate change records and your customer wouldn’t accept some of the extra charges?
  • Sent a client the wrong documents?
  • Missed a deadline?
  • Lost a client because of inconsistent product quality?

These situations are all indicative of a broken change management process.

At the very least, poor change management process can be frustrating for everyone involved in a project. At the worst, it can be disastrous. The problems at the top of the list — little mistakes that even the most detail-oriented engineer could make — can lead to the consequences at the bottom of the list — missed deadlines, incorrect documentation, and clients going elsewhere.

Why is change management so hard?

There are many answers to this question. Which one you get usually depends on who you ask. Increasing project complexity is certainly one reason. A lack of an industry standard process is another.

For the clients we talk to, however, the main culprit is a lack of communication. While many projects involve engineers across multiple disciplines, there is very little collaboration among them.

Engineering departments are siloed. They — and the tools and systems they use — don’t talk to one another. That makes it nearly impossible to maintain consistency across all of the deliverables on an engineering project, especially with change requests coming in from every which way.

Learn how Emerson Process Management synchronized their control system and process automation data

Let’s look at the different phases of product development that typically involve changes and how those changes flow through the system.

Design changes

All changes are design changes in some sense. Here, we’re talking about changes made in the development environment before the documents are released for the first time.

In a file-based drawing system, design changes often look like this:

  1. Open a drawing file and make a modification.
  2. Next, go to the title block and write a note indicating that you modified the drawing and detailing what you changed.
  3. Then, open another file affected by your change to make the same modification and write the same note in the title block.
  4. Repeat Step 3 as many times as necessary.
  5. Cross your fingers and hope you got them all!

In more intelligent systems, such as electrical CAD software, the sheets are interconnected. You don’t have to open every sheet to make a modification — all of the documents are updated automatically. But, even in many of these systems, there is no way to see what other changes have taken place. In addition, there may be thousands of changes, most of which aren’t relevant to most engineers working on the project. So, you’ve still got to cross your fingers and hope that the other engineers will easily be able to access the information they need to complete their part of the project.

At some point, the decision will be made to release the documents to the ERP team. This is when the project comes under revision control and the change management process kicks off for real. From this point forward, any and all change requests need to be tracked to ensure they are implemented properly. Even more important, you need accurate records because the changes may have implications for billing.

Changes from the purchasing department

The next department that may submit change requests is purchasing. The usual reason for this is that they can’t get the specified parts or they have to switch suppliers.

The request will go to the design team to review and make sure it doesn’t impact the design intent. If the design team deems the change appropriate, they’ll then determine whether it will affect drawings, panel layouts, wiring lists, terminal numbers, and so on.

Design will then release the documents under a new revision number. (We won’t repeat this every time, but keep in mind that every significant revision means a new version of the documentation.)

Changes due to logistics

Next up is the production design department.

These engineers will often request changes for logistical reasons, such as saving time. For example, they may decide that rerouting wires or altering the location of components in a panel will make the build easier. Depending on the change, production may have the authority to make the modifications themselves, or they may feed the changes back to design to make the revisions.

It’s absolutely crucial that changes in this stage are tracked because they likely have purchasing implications. For example, logistical changes often require new parts, which the purchasing team will then need to source.

Changes during the build-out

The build phase is when things get serious. Now someone is actually assembling and wiring the system. Changes made at this point may be necessary for a variety of reasons, such as problems in the supply chain.

This phase is particularly important, because, from this point on, changes become exponentially more costly. In some cases, they can represent the difference between making money on a project and ending up in the red.

It’s extremely crucial that any changes requested during the build phase are communicated across departments. The proposed changes might necessitate further modifications in the field, or they may need to be approved by the customer.

In any case, once the product goes from development to build-out, the change management process must kick into high gear.

Changes from the customer

Changes from the customer can come in at any time. Unfortunately, it often happens here — after production has already started.

This is usually because the customer is late reviewing the design documentation, but the production department launches the build phase anyway in an attempt to keep the project on track to meet the deadline.

Customer requests tend to be more in-depth and have a much deeper reach than changes from the various engineering departments. For example, they may require the production unit to remove parts of a machine, rewire circuits, or change panel layouts. These are the types of changes that can make or break the profitability of a project. Since they come from the customer, they should be billed to the customer — but that only works if you have detailed and accurate change records to pass along to the billing department.

Changes from the field

In terms of work performed by the various engineering departments, the final round of revisions comes after the machine is shipped or the plant is built.

At this stage, the field engineers start to actually install the equipment on the machine or at the plant. In the best case scenario, everything works as planned. However, it can happen that the pieces don’t fit or don’t interface well with one another, and the engineers in the field need to figure out how to make the machine work.

Typically, the field engineers will feed these changes back to the design team, though sometimes they have access to the design system and can make the changes themselves.

In any case, the costing department needs to know so they can decide if any remedial charges need to be made. For example, if the need for modifications arises because the field engineers encounter unexpected conditions at the customer’s facility, the charges for those modifications will be passed on to the customer.

Changes from the customer, Part 2

The very final round of change requests comes in when the customer takes possession of the equipment and starts to use it. The machine might not work exactly as expected — for example, the cycle time of the process may be too long.

Here again, the customer will feed the information back to the supplier or engineering organization to decide what changes need to be made, if there are any cost implications, and what kind of manpower is required.


The process outlined above is obviously an oversimplification of what really goes on over the course of a project. It attempts to illustrate the flow of change requests through the system, from where they’re introduced to the many departments they impact.

We haven’t addressed the number of people and systems that can be involved and the communication processes that are required to keep everyone on the same page.

And then, of course, there’s the sheer amount of data.

We toss around terms like engineering change requests and release as if they are simple things. But they’re not.

In a manual system, for every change, an engineer must write an engineering change notice. For complex products, the documentation can reach thousands of pages. That means that every single time a change is made, an engineer has to manually type it out on every affected drawing and spreadsheet. When the changes rise to the level of a new version, hundreds or thousands of pages must be updated and re-released.

You can see how one small mistake can quickly propagate across an entire project.


How to make change management more efficient — and less painful

The engineering change process is cumbersome because, in most organizations, different engineers working on different parts of the process use different tools.

As a very simple illustration, imagine five people collaborating on a manuscript:

Author A writes the first draft using the latest version of Microsoft Word and then sends it off to Author B, who edits it using Pages for Mac. She highlights some passages that are unclear and inserts several comments using the Comments function. Then, she forwards the file to Author C, who opens the document using a plain text editor, thus wiping out the highlights and comments.

Author C emails the document to Authors D and E at the same time. Author D prints it out so he can make notes by hand and then has his assistant type them up and print out a clean copy. Author E uses WPS Office to edit the document on her Android phone.

By the time the document finds its way back into Author A’s hands, there are multiple versions running around (one of which is a hard copy), and it’s impossible to tell who did what because the changes weren’t tracked from one version to another.

Can Author A say with any confidence whatsoever that all of the changes have been implemented and reviewed? If he has a question about a particular edit, who should he ask?

This scenario isn’t so far removed from the reality of what happens with design documentation in many engineering organizations. Each department uses a different tool. This means every time the documents change hands, the data has to be exported out of one tool and imported into another. And the tools don’t always talk to one another very well.

To further complicate the situation, even in this digital age where the majority of the work is done on a computer, it’s still common to see an engineer bent over a stack of drawings with a red pen in hand.

The problem may seem complex, but the solution is deceptively simple. In the case of the five authors, the answer is practically screaming off the page. Use one tool for the entire process.

For manuscript writing, you can use Google Docs, which allows multiple people to collaborate on a document, all at the same time. You can highlight, comment, and edit. You can incorporate tables and charts from a linked Google Sheet, and if you edit the sheet, all of the tables and charts update automatically. Best of all, you can view the revision history to see all of the changes that have been made — and who made them. What Google Docs gives you is a single source of truth for writing projects.

Obviously, engineering projects are more complex. But that doesn’t mean they need to be a documentation nightmare.

Engineering Base is like Google Docs for engineering. It connects engineering processes across disciplines, so process engineers, instrumentation engineers, and electrical engineers can all work together. Later down the line, the same system can be used for maintenance. All changes automatically propagate across all drawings, and the revision history is automatically tracked. Just like Google Docs, Engineering Base provides a single source of truth.

Changes are inevitable. Inefficiencies and mistakes are not. Learn more about Engineering Base.

Leave a Reply

Your email address will not be published. Required fields are marked *