- Management of change is not the same as change management.
- A successful management of change process requires significant front-end planning that makes the implementation go much more smoothly.
- The multi-disciplinary team assembled to run the change program need to be highly responsive, responsible and diligent.
Have you ever had one of those nights? The only spare parts in stock don’t fit because that little “midnight upgrade” you did last year failed to provide for new spares. Maybe your line has been down for hours as your electrician tries to troubleshoot using a hopelessly out-of-date drawing. Or did you suffer a near miss because of that uncapped line that was added as an undocumented afterthought and not included in the isolation plan? Have your operators ever damaged a new piece of equipment that they were not trained on? Have you ever had one of those great workarounds that was “just the answer” in the heat of the night, just to fall flat and create more problems than it solved? And I’m sure every one of you knows of some location that has suffered a terrible accident because of an unauthorized substitution or “minor” change. If any of these have been true for you, you need to learn about what effective management of change is and how it can protect your people, your plant and your bottom line.
Although implementation details vary widely, truly effective management of change (MOC) programs start from the same foundation and contain the same basic elements, either singly or in combination. The following 11 steps 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. It 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? You need 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. Be clear, be concise, but be complete. If you can’t communicate clearly what it is that you wish to do, how can a team evaluate it properly and how can you ensure that what you intend to do will in fact be implemented properly? At this point in the process the change must be defined well enough 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’s 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% and result in 27,000 lb per year of increased throughput at a variable margin of $0.20/lb resulting in $5,400/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
No change is entirely risk-free, so get over it. And quite often the person proposing the change is the last person to be wholly objective in evaluating risk. Even if one person is wholly objective, that person rarely is all-knowing. The evaluation of risk requires the MOC team approach. 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 simple.
- Each member must represent a different discipline (operations, maintenance or reliability, engineering, HSE or other disciplines as needed). You want a balanced team that can look at the proposed change from many different viewpoints to capture a complete picture of it. Keep in mind that the most serious mistakes come not as a result of people not being competent in their fields, but where the person or team is ignorant of some bit of information outside of their collective area of expertise. That is, they didn’t know what they didn’t know. The best organizations develop a matrix of the required team makeup based on the nature of the proposed change.
- 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 often is a far superior team member than a manager who’s new to the area. Remember that this stage is about knowledge, not approval authority. A team that has only technical people or only shop-floor people rarely is a well-balanced team.
- 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 doesn’t allow others to express their concerns is equally ill-advised. Evaluating risk is very much a brainstorming exercise and the same rules apply.
- Identifying the potential risks 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’s 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 information dissemination. However, other risks are unacceptable and must be addressed, either before implementation (such as the need to train people before operating a highly modified process) or after implementation (such as final documentation). Regardless of when these mitigation actions need to be taken, once they’re identified as requirements for keeping the risk to an acceptable level, they must be completed at the allocated time. Checklists are most helpful in this phase of the MOC process as they can help the team readily 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, though, if you’re not prepared to complete the mitigation, then you shouldn’t be making the change.
5. Differentiate ‘to approve’ from ‘to be informed’
The most common 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 either will become mired in approval and get nothing done or will spend its time and energy trying to circumvent the system. Every MOC doesn’t have to have the same approvers. The best approvers are those most competent to perform the specific risk analysis and make the decision 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 most competent to make the technical evaluation of the change — the maintenance manager, the store room superintendent or the rotating equipment engineer? The person with that authority doesn’t 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 bearing substitution, but certainly needs to know that it happened so that the vibration monitoring data files can be adjusted accordingly. Likewise, the planner need not approve the change, but does need to know of it and correct the 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 those 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 with documentation
If the previous steps have been done properly, this becomes the quickest and easiest step, rather than the big delay that it often can be. The list of required approvers is as short as the delegation of authority in your organization can allow it to be. Use whatever approval method — paper, shared documents or databases — that works well for your organization’s size, trust level and complexity. 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. Features and complexity often 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 none they’ll document. Keep it simple, keep it straightforward and it will be used. Excel-based applications abound.
A tip for approvers: if you have a 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. If you don’t have a proxy system for approvals in place, 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 time-critical business processes.
Effective communication is rare. If a position is designated on an MOC as one “to be informed,” it means that it’s important to your business that the person receives this information. Effective electronic communication can be facilitated in our data-overload environment if the information is flagged properly, it arrives in an expected format, the information is succinct and receipt is verified. For most of your “to be informed” persons, a simple message with a subject line containing “MOC xxxx” tells everyone who receives it what the change is and that it’s important to them.
The message always should contain at least 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 might 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 “Request a Read Receipt” is not an effective substitute for ensuring the information has been received. Your procedure should state and your organization must understand that an actual reply is expected. The person who is the single point of accountability (SPA) sending the communication is on the hook until its receipt is acknowledged. And the recipient is expected to act appropriately upon the information received.
Most organizations’ approach to communication with the people on the floor is sketchy at best. This is where it breaks down most often. The way to communicate with operators isn’t 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. Communication hasn’t happened until every specified person on that “to be informed” list has signed off to affirm that they’ve received and understood the communication. Then, and only then, the SPA for that task might confirm it as completed to the SPA for the change.
About now, I’ll bet you’re thinking I’m making a big hoopla over communication. You’re right. Persons would not be on the list of “to be informed” if it wasn’t necessary to manage the change, right? We aren’t broadcasting here. We’re conveying vital information to a select and necessary few. You’re far more likely to have adverse consequences if you fail to inform than by missing an entire approval.
7. Execute pre- and post-implementation change and mitigation
A serious problem facing many U.S. industries is lack of the ability to execute, or more simply, they can’t “git ‘er done.” This is the other common area in which MOC process implementations fail. If you don’t implement the mitigation tasks you identified, 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 easier and speed up your MOC process.
As you develop mitigating action items to address consequences of the change and to ensure its effectiveness, categorize them as those that must be completed before and those that might be completed after the change is implemented. Required pre-implementation items are “show stoppers.” You don’t proceed unless they’re done. Apply some good sense here. Do the operators need 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 don’t have to be completed before start in most industries. Without exception, these tasks must be completed before the MOC can be closed out. The process owner and change SPA are on the hook until every action is 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” doesn’t mean it’s unimportant or can be ignored. It simply means later.
Although the SPA for executing the change might be responsible for performing many of the tasks, in an effective MOC process it’s the owner of the system being changed who is accountable for ensuring that they’ve been done. “Accountable” in this context means the buck stops here. That individual’s organization is, after all, the one that will have to live with the change, for good or for bad. It might not be the pilot who fuels 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 important step in MOC. It’s 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 to gain some benefit. They expect to get it. The method of determining effectiveness is best developed and documented before approving the MOC.
Then, if the change isn’t 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 the change necessitated. Or execute a new MOC to address another option. What you must not do is keep on tinkering and changing the change until it’s 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. The MOC isn’t an open-ended license to experiment, although most experiments need to have an MOC performed.
9. Confirm mitigation and follow up
Figure 1. The most critical MOC question to ask is: “Should I make this change at all?” Avoid unintended consequences.
This is the part that everyone hates. Every last mitigation item, from document update to setting up spare parts and training the users, that was identified as a condition for approving the MOC must be completed and completed on time. There are several real reasons for doing this.
First of all, it’s how you ensure that you’ve not left behind any of those potential land mines to step on. It’s where you prevent introducing 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 didn’t set up the required lubrication PM and the correct spare isn’t in stock because you didn’t change the BOM or add the stock number, and the old bearing won’t fit the modified shaft, what do you do? 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 the change sticks and some or all of the new conditions don’t morph back into the conditions before 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 minor control system set-point range change. It absolutely fixed a problem that was costing more than $500,000 in losses each 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 returned. The relatively minor mitigation item — update SOP and re-train control room operators — almost got done. And no one continued to confirm effectiveness. Entropy is at work out there. When left to themselves, systems 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 didn’t require a formal MOC. If there’s an accident as a result of a not-too-well-thought-out change, you might 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 don’t complete the task, then your degree of negligence ratchets up to a 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.
Until all the stated risk control action items have been completed, we don’t 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 action items immediately to site management the minute that they’re 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 doesn’t have the resources to execute all the tasks necessary to control reasonable risk associated with changes, then you’re making more changes than you can control. And most likely, an appreciable number of the reactive situations 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 the MOC action items have been confirmed to have been completed, then, and only then, might the MOC be confirmed closed and records updated accordingly. Generally, at that time a closing notice is sent to those on the approver list and the must-be-informed list. Often the same persons who approved the MOC must sign off on the closure. The degree to 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. Stephen Covey Jr.’s approach is “trust, but verify.” One of the saddest, but most common, phrases that I hear when doing root cause failure analysis is: “We used to do that, but somehow we got away from doing it.” It means that someone failed to implement sustainability measures fully. And that means that they didn’t 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’s management’s responsibility upon implementing a new business system to ensure that the system is used as designed and achieving the intended results. Written policy and procedure are necessary and desirable. But they’re 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. Every one of these metrics is totally worthless if site management doesn’t look at them periodically, question them, perform a simple process audit and act on adverse trends. Trust, but verify.
A best practice is for 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 review the trends periodically 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 select randomly 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. A field audit not only reveals what’s really happening on the shop floor, but management presence and interest in the process signals to the organization that it’s important. This is an important element of sustaining change.
Management of change is a proactive business process focused on preventing losses. It might 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 MOC implementation can reduce reactivity and just plain makes financial sense.
When implementing MOC, focus on preventing the generation of future risk first and only then follow up with correcting past mistakes and omissions if a business case exists. The most serious problems facing a business implementing MOC are changing the organization’s behavior initially and then sustaining that change over time. Principles of change management must be applied to the human element of the management of change implementation.
Sam McNair, P.E., CMRP is senior consultant at Life Cycle Engineering, headquartered in Charleston, South Carolina. Contact him at firstname.lastname@example.org.