Eleven Elements of an Effective Management of Change Program 

By Sam McNair, P.E.,CMRP

Although the details of implementation vary widely, all truly effective Management of Change (MOC) programs start from the same foundation and will contain the same basic elements, either singly or in combination. The following steps will give you the basic functional guidelines. 

1. Identify and Quantify Change

What am I really planning to do here? Quite often where no effective MOC process exists, requests for a change are rather vague. “Run a temporary line from here to there…” accompanied by some hand waving happens all too often. How big should the pipe be? What pipe material spec? What size and expected flow? Exactly where should it terminate? How about valves? Simple sketches, red lined drawings, marked up procedures, or whatever is necessary to convey the nature and extent of the change to a knowledgeable and competent third party is needed. Be clear, be concise, but be complete. If you cannot clearly communicate what it is that you wish to do, how can a team properly evaluate it, and how can you assure that what you intend to do will in fact be implemented properly? At this point in the process the change has to be well enough defined that you can make a good decision in subsequent steps.

2. Evaluate Risk and Reward 

The most important step in an established MOC process is asking the simple question: Should I be doing this at all? What concrete business objectives am I satisfying by this change? Is there truly a compelling business case, or is this simply a matter of convenience or expediency? If there is not a clear reward that can be stated in terms of accepted business goals, why are you using the resources and why are you taking the risk? Just how big are the risks? Again being clear and concise are the keys. “Increasing temperature by 2’C will increase yield by 0.07% resulting in 27,000 lbs per year of increased throughput at a variable margin of $0.20 per lb resulting in $5,400 per year gross revenue.” “This change in control strategy will decrease nuisance trips by four per year, reducing overtime by 400 hours, valued at $20,000 per year.” These fit both criteria quite well.

3. Select the MOC evaluation team

There is no change that is entirely risk-free. So get over it. And quite often the person who is proposing the change is the last person to be wholly objective in evaluating risk. And even where one person is wholly objective, they are rarely all-knowing. The evaluation of risk is where an MOC team is required. Use as a minimum the “three person rule” for assessing the risk of a proposed change. The criteria for selecting someone to be part of the team are very simple:

a.  Each member must represent a different discipline (i.e. a person representing operations, maintenance or reliability, engineering, S.H.E. or other disciplines as needed). What is needed is a balanced team that has the ability to look at the proposed change from many different viewpoints so that there is a complete picture of it. Keep in mind that the most serious mistakes come not as a result of where the person is not competent in their field, but where the person or team is ignorant of some bit of information outside of their area of expertise. That is, they didn’t know what they didn’t know. The best organizations develop a matrix of the required makeup of teams based on the nature of the proposed change.

b.  The team members must be knowledgeable enough about the proposed change and its implications to be able to make an objective evaluation of possible consequences. They need to know how things really are, not how they are thought to be. Therefore an experienced operator is often a far superior team member than a manager who is new to the area. Remember that this stage is all about knowledge, not approval authority. A team that is all technical people or all shop floor people is rarely a well-balanced team. 

c.  Team members must have credibility with their peers and with leadership. They must be willing to speak up about their concerns. Conversely a team member who dominates the situation and does not allow other team members to express their concerns is equally ill advised. Evaluating risk is very much a brainstorming exercise and the same rules apply.

Once all of the potential risks have been identified, then this is the first point where a “conditional go” or a “no go” decision can be made. There are simple tools and quite complex tools for performing risk-reward analysis. Choose the one that is right for your business and the circumstances. But having chosen the tool, never fail to be consistent in its use.

4. Develop Risk Mitigation Actions

Some of the risks that will be identified are acceptable and require no special actions other than awareness and proper dissemination of information.  However other risks are unacceptable and must be addressed, either prior to implementation (such as the need to train people before operating a highly modified process) and others may be addressed after implementation (such as final documentation).  Regardless of when these mitigation actions need to be taken, once they are identified as requirements for keeping the risk to an acceptable level, they must be completed at the appointed time. The use of checklists is most helpful in this phase of the MOC process as they can readily help the team identify possible appropriate mitigation activities. Consider important potential touch points such as: training, drawings, documents, HSE evaluations, permitting, spare parts, operating and maintenance procedures, inspection programs and QA. 

Keep in mind if you are not prepared to complete the mitigation, then you should not be making the change. 

5. Identify Approvers and “To Be Informed”

The commonest mistakes made in setting up an MOC process are those of confusing approval authority with the knowledge necessary to evaluate, and mixing the need to approve with the need to inform. If you botch this step, your MOC process can still work with modest effectiveness, but it will be so cumbersome and inefficient that your organization will either become mired in approval and get nothing done, or spend its time and energy trying to circumvent the system. Every MOC does not have to have all the same approvers. And the best approvers are those who are most competent to perform the specific risk analysis and decision that their approval implies.  Do this part right and your approval time will be minimal.

For instance should every MOC be approved by the maintenance manager or the operations manager? How about the procurement manager? Or the IT manager? And what if the decision is, for instance, to substitute bearing # 1234 for bearing # 5678 to radically reduce downtime in machine ABC? Who then is the most competent to make the technical evaluation of the change, the maintenance manager, the store room superintendant, or the rotating equipment engineer? Who has the authority does not matter nearly so much as who knows the consequences.

The best MOC processes use an approval matrix (or list ) that references the types of changes to be made with the positions necessary for approval. The best of the best include “must be informed” in that matrix and minimize the approval list. The best organizations push decision making down to the lowest, effective level. Very often MOC documents are routed for approval, when the intent is merely to ensure that the right person is informed.  As Steven Covey said, “Start with the end in mind.”

Using the bearing example, the PdM technician has no need to approve the substitution of the bearing, but he certainly needs to know that it has happened so that he can adjust the vibration monitoring data files accordingly. Likewise, the planner need not approve the change, but he does need to know of it and correct his BOM accordingly. So when you limit your approval to only those with the hierarchical authority and require approval in lieu of “ information only” you are: lengthening the approval process, involving those who have no need of involvement, not involving the persons most competent to make some of the decisions, and often failing to get necessary information to those who need it most.

6. Approve and Communicate (Document)

If all of the previous steps have been done properly, this is the quickest and easiest step, rather than the big delay that it often is. The list of required approvers will be as short as the delegation of authority in your organization can allow it to be. Use whatever approval method works well for the size, trust level, and complexity of your organization: paper, shared documents, or databases. I urge you to use restraint in setting up highly automated software applications. 

Often the needs of your MOC process become secondary to the design of the “big MOC database” and nothing gets done for the year it takes to develop and roll it out. Often features and complexity multiply until only a few power users can access or use the system. When the “Quick Start User’s Guide” for your MOC application runs to 32 pages, as it did at one corporate giant, the work process breaks down. Then no one makes a change (or at least one that they will document.) Keep it simple, keep it straight forward and it will be used. Excel-based applications abound. 

A tip for approvers: if you have a very dynamic organization with lots of changes and other things going on that require approvals, often the need can’t wait for someone to come back from vacation. So if you do not have a proxy system in place for approvals, by all means develop one. Your proxy is the person with your specified delegated approval authority in your absence. Everyone in the approval chain should have a designated proxy for all of your time critical business processes.  

A word on “to be informed”: effective communication is rare. If a position is designated on an MOC as one “to be informed” it means that it is important to your business that they receive this information. Effective electronic communication can be facilitated in our data overload environment if the information is properly flagged, arrives in an expected form, is succinct, and receipt is verified. So for most of your “to be informed” persons, a simple message with a title containing MOC xxxx will tell everyone who receives one what the change is and that it is important to them. 

The message should always at least contain the position of the person to whom it is directed (people do change jobs and emails do get misdirected), the MOC Title, the change effective date, and the specific information to be conveyed. It should end with a receipt confirmation request. You may attach a copy of the MOC document as a courtesy but the key information must be in the email, not buried in the MOC. Flagging the message by clicking the “Request a Read Receipt” is not an effective substitute for assuring that the information has been received. Your procedure should state and your organization must understand that an actual reply is expected. The SPA sending the communication is on the hook until receipt is acknowledged. And the recipient is expected to act appropriately upon the information received. 

In most organizations communication with the people on the floor is sketchy as best. And this is where it breaks down most often. The way to communicate with your operators is not with a Post It note on the control console, or an all hands email. For important changes communication needs to be made by the method that works best for your organization and culture. But communication has not happened until every specified person on that “to be informed” list has signed off to affirm that they have received and understand the communication. Then and only then the SPA for that task may confirmed it completed to the SPA for the change. 

About now you are thinking that I am making a very big hoopla over communication. You’re right. Persons would not be on the list of “to be informed” if it were not necessary to manage the change, right? We aren’t broadcasting here, we are conveying vital information to a select and necessary few. You are far more likely to have adverse consequences if you fail to inform than by missing an entire approval. 

7. Execute Change and Mitigation (Includes Pre and Post-implementation Actions) 

A serious issue facing many U.S. industries today is lack of the ability to execute, or more simply, they can’t “Git ‘er done.” And this is the other very common area where MOC process implementations fail. If you fail to implement the mitigation tasks that you have identified, then you have cast away much of the benefit of the MOC process. Some planning in how you develop your tasks can help make this job much easier and speed up your MOC process.

As you develop mitigating action items to address consequences of the change and to assure its effectiveness, categorize them into those that must be completed before and those that may be completed after the change is implemented. Required pre-implementation items are “show stoppers”. You do not proceed unless they are done. So apply some good sense here. Do the operators have to have marked up temporary SOPs and training before they push the start button on a new piece of equipment of a new type? Definitely! 

The post-implementation tasks, such as permanent procedure updates and updating the operator training manual, are just as critical, even if they do not have to be completed prior to start in most industries. But they are just as critical to success. Without exception, all of these tasks must be completed before the MOC can be closed out.  The process owner and change SPA are “on the hook” until every last one of the actions are completed. Every omission here is an opportunity for a failure or an incident to occur for the life of the change that was made. Omissions at this stage are the equivalent of planting land mines in your facility for the next generation to step on. “Later“ does not mean it’s unimportant, or can be ignored. It simply means later.

Although the SPA for executing the change may be responsible for performing many of the tasks, in an effective MOC process it is the owner of the system being changed that is accountable for ensuring that they have been done. Accountable in this context means “the buck stops here!” Their organization is, after all, the one that will have to live with the change, for good or for bad. It may not be the pilot who fuels up the airliner, but you can be sure he confirms the fuel level before taking off, and for the same reasons. 

8. Confirm Effectiveness  

At first look this strikes most people as silly. “Of course it did what we planned it to do!” This is an often overlooked but very important step in MOC. It is simply verifying that the change worked as intended. Not all changes give the intended results. And many, despite the best planning, result in unintended and often undesirable consequences. The organization expended resources and possibly incurred some increased risk in order to gain some benefit. They expect to get it. The method of determining effectiveness is best developed and documented prior to approving the MOC.  

Then, if the change is not going as planned, the options are simple: restore the system to the original configuration, which includes all of the necessary follow up actions and communications necessitated by the change. Or execute a new MOC to address another option. What you must not do is keep on “tinkering” and changing the change until it is outside of its original approved scope, hoping to get it right without a repeat of the previous steps. This defeats the purpose of the original MOC. An MOC is not an open-ended license to experiment, although most experiments need to have an MOC performed.

9. Confirm Mitigation and Follow Up

This is the part that everyone hates. Every last mitigation item, from document update, to setting up spare parts, to training the users, that was identified as a condition for approving the MOC must be completed and completed on time. There are several very real reasons for doing this: 

First of all, it is how you will ensure that you have not left behind any of those potential landmines to step on. It is where you prevent creating or worsening future emergencies. Have you ever tried to troubleshoot an electrical system problem with out-of-date prints? Or done the same with software that has undocumented changes? How about when that new, improved bearing that was supposed to last five years, reaches five years in service? When it fails because you have not set up the required lubrication PM, and the correct spare isn’t in stock (because you did not change the BOM, or add the stock number), and the old bearing won’t fit the modified shaft, what do you do now? To those without good MOC processes in place, it becomes another emergency and another opportunity for an undocumented midnight modification.

Secondly, this is how you ensure that the change “sticks” and that some or all of the new conditions do not morph back into the conditions prior to the change. Sustainability is a critical element of a successful change.  In this step you build the foundation for sustainability. How important is sustainability? The best example of this is a very minor control system set-point range change. It absolutely fixed a problem that was costing well over $500,000 in losses per year. As a loss elimination exercise it was fantastic: teamwork, structured problem-solving, an enormous ROI measured in orders of magnitude. And one month after the problem was “cured”, the problem was back. The relatively minor mitigation item: “update SOP and re-train all control room operators” almost got done. And no one continued to confirm effectiveness. Entropy is at work out there. When left to themselves, systems will always degrade to the lowest state.

Finally, there are sound legal and ethical reasons. Let’s say you were in the habit of making changes without an MOC process and as a non-hazardous industry your business did not require formal MOC. If there is an accident as a result of a not-too-well-thought-out change, you may be found to be guilty of ordinary negligence. If, on the other hand, you make a well thought-out change, clearly identify a risk and the mitigation tasks to control it, but do not complete the task, then your degree of negligence ratchets up to a whole new level.  You just might be found guilty of culpable or criminal negligence. And regardless of the legal outcome, if someone is injured, your conscience leaves you nowhere to go if you failed to do what you knew needed to be done.

So until all of the stated risk control action items have been completed, we do not proceed.  A best practice is to publish a list of outstanding action items that are within one month of being due for completion. Another is to report all action items immediately to site management the minute that they are overdue or at risk of becoming so. Legal reasons aside, the potential risk to your business generated by overdue action items can be considerable. The best practice is a zero tolerance policy for overdue action items. If your organization does not have the resources to execute all of the tasks necessary to control reasonable risk associated with changes, then you are making more changes than you can control. And most likely, an appreciable number of the reactive situations that are tying up your valuable human resources are the results of past uncontrolled changes.

10. Close Change Activity

When the change has been confirmed to be effective, and all of the MOC action items have been confirmed to have been completed, then and only then, may the MOC be confirmed closed and records updated accordingly. Generally at that time a closing notice is sent out to the persons on the “approver” and the “must be informed” list. Often the same persons who approved the MOC must sign off on the closure.  The degree with which you need to check and double check is a function of the level of consequences and your organization’s level of trust.  

11. Audit Process Compliance

Even the best organizations can slip a little. Steven Covey Jr.’s approach is “trust, but verify.” One of the saddest, but most common phrases that I hear when doing an RCFA is: “We used to do that, but somehow we got away from doing it.” It means that you failed to fully implement sustainability measures. And that means that you did not execute proper change management. Change management (as opposed to MOC) is the art and science of permanently changing the behaviors of people and organizations. One essential element of change management is to install the necessary elements to sustain the change.

It is management’s responsibility upon implementing a new business system to ensure that the system is used as designed and achieving the results that were intended. Written policy and procedure are necessary and desirable. But they are not enough. Measurements and audits are necessary. Leading measurements such as number of MOC opened and closed, number of action items generated, percent of late action items and late MOC closures tell you if people are conforming to the process. Lagging measures such as a summary of the benefits realized by the changes, and net resources expended, give a picture of the activity level and effectiveness of the MOC process. And every one of these metrics is totally worthless if site management does not periodically look at them, question them, perform a simple process audit and act on adverse trends. “Trust, but verify”.

A best practice is for the site management to appoint someone to be the steward of the MOC process to generate the agreed-upon metrics and monitor them. Also, the management team as a group should periodically review the trends and select a few MOCs to perform an audit. The frequency is best determined by the level of change activity, how long the process has been in place, and how well the data is trending, but never less than every six months. 

An effective audit starts with reviewing the numbers, but it always includes “going walk-about”. A best practice is to randomly select a few recently completed changes covered by your MOC process and step through them from start to finish taking care to establish if the process was complied with and the correct behaviors present.  An audit in the field not only reveals what is really happening on the shop floor, but management presence and interest in the process signals to the organization that it is important. This is an important element of sustaining change. 

Summary 

Management of Change is a proactive business process that is focused on preventing losses. It may be applied to almost any industry that has assets and systems that it wants to protect regardless of the perceived safety of the process. MOC is an ideal complementary process for a business with an active loss elimination or continuous improvement process. In most businesses an appropriate implementation of MOC can reduce reactivity and just plain makes financial sense.

When implementing MOC it is important to focus on preventing the creation of future risk first and only then follow up with correcting past mistakes and omissions if a business case exists. The most serious issues facing a business implementing MOC are changing the organization’s behavior initially, then sustaining that change over time. Principles of Change Management must be applied to the human element of the Management of Change implementation. 

© Life Cycle Engineering, Inc.

For More Information

843.744.7110 | info@LCE.com