You are on page 1of 9

Eight Common Misperceptions of

Management of Change
By Sam McNair, P.E., CMRP, Life Cycle Engineering
As appeared in the July Edition of RxToday

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 arent 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 dont 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 cars 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? Lets 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 programs 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

"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
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 wont be
coming home tonight.
2. I am so far behind I cant start doing MOC. Ill 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
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 dont 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
dont 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
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, its rare for one person to be competent in all
aspects or consequences of a given change. In an effective MOC process it is the
managers 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 dont 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 cant 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 wont 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 dont 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 dont 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. Its not like we were changing a pipe or something. We
dont 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

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 todays 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.

Sam McNair is a senior consultant with Life Cycle Engineering (LCE). A Professional Engineer and Certified
Maintenance and Reliability Professional, Sam has more than 32 years of experience in discrete
manufacturing, chemical process industries, mining, machine processes, automation, aviation, construction,
and utilities. Sam specializes in reliability engineering with a focus on the integration of maintenance and
manufacturing functions. You can reach Sam at

2010 Life Cycle Engineering, Inc.

For More Information

843.744.7110 |