Eight Common Misperceptions of Management of Change

By Sam McNair, P.E., CMRP

Introduction

Whenever I mention Management of Change to plant personnel, I generally get one of several predictable responses. The knowledgeable ones will cite the regulation OSHA 1910.119(a)(2) and tell me that they aren’t a “covered process” so that it does not apply to them – generally with a great sigh of relief.  Another frequent response is: “We have a drawing management procedure, but we are so far behind it would take years and resources we don’t have to catch up.” Others still will tell me that they have a perfectly fine procedure for their managers to approve small projects and alterations. And a few will sheepishly think about the pennies and nickels filling up their car’s ash tray.

So what is Management of Change (MOC)? Going back to the source, OSHA 1910.119(l)(1) sets the requirements for MOC as:

“The employer shall 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.” 

That short description covers a lot of territory but since it was promulgated solely to enhance process safety, it limits the legal applicability to “covered processes”. Readers whose facilities meet the OSHA requirements of a “covered process” are well aware of the detailed requirements of MOC. They have to be or they would not still be operating. And hopefully all of  you know that many of the worst industrial accidents in recent history have as a root cause the  failure of the MOC process. Some sources indicate that as many as 80% of the serious major accidents in industry are related to uncontrolled change. Thus one can think of MOC as a sort of life insurance, that pays off by preventing accidents.

But this paper is not focused on the intricacies of MOC for covered processes. And it is not solely directed towards safety. Why then are we discussing MOC if it is not “required” for your industry? In short, it is because every business, regardless of legal requirements needs to control potential losses. And MOC, appropriately applied, is an excellent, cost-effective loss prevention process for almost any business. It is the perfect complementary process to your loss elimination processes. And we all want to be safe and environmentally friendly as well – right?

Please note that MOC addresses only changes to things presently existing. Design of new processes or facilities is another issue entirely. And we have to assume for purposes of MOC discussion, that the level of performance of the existing system, if not adequate, at least has familiar and well known virtues and vices. 

So what is MOC in non regulatory terms and who does it really apply to? Let’s work with this simple definition: MOC is a process for preventing or mitigating business losses including degradation of safety, health or environment as the result of changes made to how you construct, operate, manage, or repair your facility or your processes. Regulatory requirements aside, there is no business intending to stay competitive that can afford to not have an appropriate MOC process in place. In short, MOC makes sense for safety and it makes financial sense. Does an MOC process make sense for your business?

What is a “Change”?

“The most difficult part of Management of Change is recognizing change.” The most important starting point for the program is clearly defining for the organization just what constitutes a “change” that you wish to manage. Or more simply, what change falls under the MOC process and what sort of changes do not? Lack of clear definition effectively cripples an MOC program’s effectiveness, inviting both unnecessary analysis paralysis and creating loopholes for those who wish to bypass the process. 

There are many definitions of change from many different sources. It is the responsibility of the site leadership to define change in terms consistent with the business interests and any regulatory precedents. What risks do you wish to control and what sorts of changes, if not controlled, increase those risks? Only then can those activities that might reasonably be defined as “changes” be clearly identified, and once identified must be conveyed in the most simple and straightforward language possible. Although a bit messy, the use of lists or tables of examples is often necessary to get the points across. Keep in mind that a “change” does not have to occur in a piece of hardware to qualify. Software, procedures, and process parameters are all examples of non-hardware changes that often must be rigorously controlled.

When dealing with hardware, the OSHA 1910 source document refers obliquely to a change as not being a “Replacement in Kind” (RIK) and further defining RIK as “a replacement which satisfies the design specifications.” RIK generally refers to equipment or components that are identical in Form, Fit, and Function (referred to as the F3). But there is more to change than this very narrow hardware-based approach. The OSHA definition of change also refers to technology, procedures, and chemicals (more broadly interpreted as raw materials.) Obviously more than just hardware is included in the definition of “Change”. I have found that the best formal definition in use for “Change” in the MOC process is found in a clarification published in OSHA 3313: “Change is an alteration or adjustment to any component, variable or property within an existing system (except those within clearly defined boundaries or responsibilities.)”

Since every business has different areas of risk exposure and different tolerance of undesired consequences, it is up to each business to assess risk and define its tolerance for uncontrolled change. A few (but by no means all inclusive) examples of the sorts of changes a business may wish to manage are:

• Addition of new process equipment or critical business system (including software)
• "Not in Kind" replacement of process equipment or parts
• Modifications or minor additions to process equipment
• Modifications or minor additions to critical business system (procedural or software)
• Modifications or minor additions to infrastructure / non-process equipment
• Changes to process control and / or instrumentation (includes control strategies)
• Changes in specifications or sourcing of technical MRO
• Changes in critical process parameter operating limits (outside of ranges specified in SOP)
• Alterations to safety systems (interlocks, shutdowns, fire or explosion suppression, etc)
• Revisions to standard operating procedures (including emergency procedures)
• Changes in site-level organizational structure
• Changes to maintenance procedures
• Changes in raw material / component specifications or sourcing
• Alterations or new connections to utilities systems (air, electrical, gas, water, steam, etc).
• Alterations or new connections to critical data networks
• Changes to QA procedures or critical test equipment

A few hours of quality “what if” brainstorming by a multi-disciplinary team early in the process design to develop the definitions and examples that are right for your business will pay huge dividends.

What About “Temporary” Changes?

Remember this important concept to apply when implementing MOC: just as there is nothing in the world as permanent as a temporary tax; there is no more permanent a change than a “temporary change” which escaped the MOC process. Experience shows that there are really only permanent changes that are intended to be temporary until they have been restored to original conditions. Of all of the uncontrolled changes that occur, “temporary” changes are the most pernicious and the most frequent cause of accidents and incidents. Thus “temporary” changes of a controlled system should never be exempted from the MOC process.

So what do I do to deal with temporary changes that must be made to perform routine business, such as an interlock bypass to perform periodic maintenance? If it is truly routine, then what you have is a permanent state of a periodic deviation from the SOP. And the right way to deal with that is to treat the situation as a permanent change, incorporating it into approved procedures with appropriate safeguards. If something is intended as a non routine temporary change, treat it as a change. OSHA 3133 in a clarification says: “MOC procedure should ensure that equipment and procedures are returned to their original conditions at the end of a temporary change.” History and prudence would suggest that “temporary” changes should be managed as “permanent” with special attention to the MOC procedure because they present the highest risk to your business.

Eight Common Misconceptions of MOC

1. “But I am not making a real modification. I am just making it a little better.”
If you are not leaving the part / equipment / business system exactly the way that it was prior to starting the work (absent of course any damage that was the object of the repair), then you have made a change. Whether or not the change is one that falls under the scope of your MOC process is determined by the criteria set in your procedures. The default approach to take is to assume that any change in configuration, form, fit, function, materials, or procedure are covered under MOC until an examination of the criteria in the procedure proves otherwise.   

Second to uncontrolled “temporary changes”, well-intentioned minor improvements rank as the next largest cause of incidents that fall under the failure-of-MOC category. Without a thorough evaluation of the total operating context and environment, who is to say that “better” in one way is not really much, much worse in another? The same drug given to one patient can be a powerful cure; to another it may be a deadly poison. The same applies to well-intentioned but uncontrolled minor “improvements”, especially materials substitutions which are particularly risky. Teach your personnel at all levels to be aware of and avoid this common pitfall and then enforce it strictly. No one likes to discipline people for breaking the rules, especially when they do it the spirit of improvement. But it is infinitely worse to have to tell a family that someone won’t be coming home tonight.

2. “I am so far behind I can’t start doing MOC. I’ll never catch up with all of those unrevised drawings.”
Document control is a process that complements a well designed MOC process, and is often the first thing people think of when you mention MOC. The need to update documents is certainly a frequent outcome of an MOC and necessary for the long-term integrity of your processes and facilities, but it is not MOC. It is merely a frequent outcome.

Often when implementing MOC with a document control process, you inherit quite a mess from those who preceded you:  no drawings, inaccurate drawings, out of date documents, you name it. If the situation is dire, you may be forced to prioritize your corrective actions – if any are based on the criticality of the systems. Some may not need to be and will never get corrected. Certainly a method to correct vital information when it is discovered can and should be easily incorporated into your work control procedures. But do not add to the task by continuing bad habits.

You cannot change what has happened in the past. If the business case exists to correct or mitigate past mistakes, then do so. MOC is about future loss prevention. So the one thing that any organization can do is to start implementing MOC right now. Today is the day to stop creating more problems for tomorrow.  A succinct piece of folk wisdom says: “If you have to fill in a real big hole, the first thing to do is to stop digging it deeper.” The same applies to a gap created by poor MOC. Stop making it bigger.

3. “I don’t have time to wait for the MOC evaluation. This is an emergency!”
During an emergency is precisely when the self discipline imposed by a well-established MOC process is most necessary. When an airliner has an in-flight problem, the pilots don’t do the first thing that comes to mind. Rather they pull out the checklist and they think, then they act. When there is an “emergency” so should you. Is this “minor modification” to allow a substitution really going to save that much downtime compared to getting the correct part? Often minor changes take much more time than expected.  

Be realistic in your evaluation of how long, how much money, and how much risk increase this “fast work around” will really take.  It is good to be optimistic in an emergency. It is best to be prepared for the worst. As the saying goes: “If you are in a leaky boat far out to sea, it is best to pray towards Heaven, but to row towards shore.”  Is the risk to your business associated with a “temporary” bypass worth the savings in time? Can you really control the risk to an acceptable level by “special operating procedures”?

Accident reports show that hasty decisions, made under pressure, without a balanced evaluation, have been at the root of many serious problems. Time to think in a disciplined manner is not time wasted. And if your MOC process is efficient, it will not unduly impede progress on the rare occasion when it is a true emergency. Just as there is a procedure to authorize and issue an emergency work order when needed, a good MOC procedure will have a mechanism to address real emergencies. But that mechanism should not be to ignore MOC. Do not allow expediency during one “emergency” to set you up for a bigger and more serious second emergency. Do not defuse a bomb just to plant a landmine.

Are you experiencing frequent failures that require a work-around to deal with, constantly having to make midnight parts substitutions to recover from an unexpected failure, or constant process alterations to accommodate unstable components or raw materials? Then your challenge is not to ignore MOC or to design an MOC process that supports anarchy. Rather you should focus your efforts on eliminating these situations by implementing an effective RCFA process and PM/PdM programs to eliminate the chronic failures. Next, focus on correcting the deficiencies in your MRO processes to ensure you always have the right parts. And finally, you should be stabilizing your process with standard work procedures and materials supplier qualification programs.

4. “Routing this form for approval takes so long we can never get anything done.”
An effective MOC process requires an appropriate level of approval and communication. Poorly designed MOC approval procedures confuse the need to be informed of a change after it happens with the need to approve a change before it happens. The levels of approval required need to be both appropriate to the change and the potential risk associated with it. They also need to be flexible enough so that they can be tailored to the situation at hand. Minimize the number of approvers, and make them the right ones. Your MOC process can then be safely streamlined.

5. “But my area manager already has to approve funds for changes.”
Do not confuse the authority to make a decision with possession of the knowledge necessary to make that decision. Not all changes, and often the most critical ones, even pass through funding approval. Often the persons most competent to evaluate the risk of making a change or the technical validity of a change are not the area manager but the operators, mechanics, supervisors, or engineers most familiar with it.  

Even if the manager is very competent, it’s rare for one person to be competent in all aspects or consequences of a given change. In an effective MOC process it is the manager’s responsibility to ensure that the appropriate designated resources are involved in a well-balanced evaluation of the proposed change. Approval authority is secondary to competence to evaluate and a well-balanced team will give more consistently good results than depending upon one smart individual.  

6. “We are a warehouse / light manufacturing / data center / repair facility…  We don’t have anything that could be dangerous.”
Remember, MOC is a process for preventing or mitigating all potential self-inflicted business losses associated with a change. There are other losses besides just process safety. It is a loss if an uncontrolled process change causes you to lose a valued customer because of contaminated or faulty product. It is a loss if your data center is down and troubleshooting takes several hours instead of minutes because electrical drawings have not kept up with changes. It is a loss if the automatic stacker is down and you can’t ship product because a midnight part substitution requiring a “small modification” caused the only replacement part you have in stock to no longer fit. It is a loss if an undocumented modification to the control software causes your automatic testing machine to fail when the latest security patch is installed. All of these are real examples and the list is endless. Even though the potential for changes to create dangerous situations in your environment are small, we all have something to lose when our facility or processes fail in their primary missions.

7. “But MOC won’t catch every possible problem, so why do it?”
You are absolutely right. Despite your best efforts some problems will slip by undetected. But how many will slip by if you don’t do MOC? Risk management is all about changing the odds to be more in your favor. This argument does not hold water. No more than the argument some people use against air bags: “They might deploy and cause an accident, so I turn them off.” The statistics just don’t support that line of thinking any more than they support not having MOC.
 
So what if you miss an unintended consequence? A valuable additional benefit of MOC in complex systems is when doing an RCFA. If there are adverse consequences from a change and the cause is not immediately discernable, the RCFA goes much quicker if you have a list of all of the deliberate changes that have been made. And that time can be real money. In one case researching MOC records cut weeks off of the time necessary to find the root cause of a string of process plant failures. At $250,000 per day in avoided downtime losses, the MOC effort had quite a good return on investment even though it did not prevent the problem.

8. “This is just a software / procedure change. It’s not like we were changing a pipe or something. We don’t need to approve or document”
Some extremely serious incidents and severe losses have occurred in a number of industries because of software or procedure changes that were not subject to MOC. Furthermore just because a document or code has been altered and reflects the change does not mean that the change is documented. I know that comments in the code and revision flags in the document allow the searcher to look for changes. But when unexpected problems occur because the software or procedure change was not adequately reviewed, then what good is it?

Have you had a production line down while you searched desperately though thousand of lines of code looking for the change that was made by the control engineer two months before he left for another job? Programmers and control engineers in particular tend to “play around” with software without due regard for MOC. This applies not only to your process control but to your critical business systems software as well. If the potential risk exists and justifies it, then treat changing a line of code no differently than rewiring a safety shut-down system; it should receive the same level of scrutiny and control.

Conclusion

In conclusion, a well-designed MOC process is an essential loss prevention tool for any business. It is not just for certain hazardous industries. The process applies to any company that wishes to avoid future losses resulting from today’s changes. MOC does not have to be overwhelming or so difficult to use that it inhibits change. It cannot effortlessly compensate for past omissions, only reduce your future risk. So the time to start developing and implementing an effective and efficient MOC process is today.

© Life Cycle Engineering, Inc.

For More Information

843.744.7110 | info@LCE.com