Processes for Management of Change

1.      Overview

OSHA 1910.119 mandates all process facilities must have a Management of Change (MOC) process.

1.1.        Stages of Management of Change

The stages of the life cycle of a change are:

• Initiation

• Evaluation

• Development

• Review and Approval

• Authorization

• Implementation

• Documentation

• Continuance

This document describes the stages of Management of Change in life-cycle order; but first,

let’s bust a couple of common notions.

1.2.        What Comes First?

When processes are designed to manage change you usually get a system designed to manage change.  Although that certainly seems logical, it produces a poor system.  Rather than designing a system to manage change, change management system should be “wrapped” around the normal operational and work processes.  This makes the management of change system subordinate to the normal operational management systems.  This approach leads to a much more usable management of change system.

1.3.        Change what?

It seems remarkable that most MOC discussions never deal with “Change what?”  I believe that is a consequence of designing a MOC system rather designing a MOC system to wrap around the normal method of managing the operational and work process.  When the latter approach is taken it is necessary that “Change what?” be answered first since the method of managing the operation and work processes is slightly different for each “what”.

Here are the “What’s”:

Physical facilities

Procedures and resource materials

Maintenance activities and methodologies

Operating conditions

Process control methodologies

Staffing and personnel

After the general procedure for managing change is discussed the special impact of these different types of change are described.

2.      Change Stages

2.1.        Change Initiation

Changes start with several distinct ways.

2.1.1.         Suggestion or Request

Many changes start with someone suggesting or requesting a change.

Change suggestions and requests can be received by providing a Change Request Form to be filled out by the person suggesting the change.  The completed form needs to be routed to the appropriate person.

2.1.2.         Additional Change Initiation Mechanisms

While change suggestions or requests are typically the expected source of changes they are not the only source.  And they may not, in fact, be the most common source.

Common sources of change are revisions to procedures during periodic review or in order to incorporate new learning, facility change projects, and follow-up to problems.   It would be awkward to initiate a Change Request Form for many of these changes since the originator and the receiver would many times be the same person.

2.1.3.         Change Prevention

Managing intended change is important.  Avoiding un-intended change is equally important.  Initiation, evaluation, development, review and approval, and implementation of intended change have been given much more attention in the past than prevention of un-intended change.

This description is organized in life-cycle order.  In that order the last several steps are normally implementation of

the change and updating of documentation.  Most discussions of Management of Change stop there.  In this discussion preventing unintended change, or continuance, is added as the last, on-going step.

2.2.        Evaluation of Change Suggestion or Request

The first step in many change suggestions or requests is an evaluation of the desirability or benefit of the change.  A substantial number of suggested changes will not pass this screen.  The evaluation is based on rough benefit and cost estimates.

Many organizations may choose to put only the change proposals that pass this screen into a formal Change Management System.   Organizationally, the supervisor of the affected operating area may do this initial evaluation.  A portion of the change suggestions may be forwarded to one of the staff departments, such as safety or engineering, for this evaluation.

Suggestions that clear the initial screening may be put on a candidate list and evaluated against the other items on the list.  This is especially true of profitability improvement suggestions.

In the process industries, many of the changes can only be performed during shutdown of a unit.  Unit shutdowns may occur as infrequently as every 5 years.  Planning for such a shutdown begins a year ahead of time.  Change proposals requiring a shutdown are accumulated between shutdowns until start of shutdown planning.  Some changes require delivery of equipment with delivery times greater than a year.  These items have to be decided upon with an appropriate lead-time.

For the software development people reading this a similar circumstance occurs with application enhancement and bug fixes: all of the needs and ideas are collected and evaluated periodically.  Implementation of the changes is coordinated with the product version cycle.

During the process of evaluation, it is fairly common for the method of fixing a problem or achieving the desired benefit to change.   A better way of achieving the end may be found.  Or it may be decided that only part of the suggestion is economical.  With a succession of changes what is done in the end may have little resemblance to what was first suggested.  In these cases the logic of tracking through the history of a change gets strained.

2.3.        Change Development

Normally the specifics of a change proposal have to be developed before the change can be implemented.  Development is complex and typically a number of people are involved.  It is also an iterative process. Workflow processes can be used to facilitate the development process.   They can also be used to document the development. 

Each organization most likely has its own development process.  One effective means of managing the documentation is to capturethe documentation at the end of discrete stages in the development.  These stages frequently correspond to “turnover” of the project from one discipline or organization to another.  The stages may also correspond to various approval steps.  In any case a development process that is defined with specific nodes for documentation, review and approval provides an excellent model for workflow management.

It is appropriate to make a point of caution here.  The objective of Management of Change is normally to ensure that only appropriate changes are made and that the needed people and disciplines are actively involved to ensure the change does not create any process safety problems.  With this purpose the Management of Change process by nature slows down change and imposes a disciplined (and in the short term expensive) process compared to less formal processes.  Management of Change is an assurance process.

Some organizations wish to speed up the change process.  They wish t decrease the cycle time for a change.  If these organizations are already practicing a rigorous management of change process, application of workflow tools can indeed speed up and decrease the cost of changes.  However, if the organization is not practicing a rigorous management of change process, implementing a management of change project is most likely conflicted in its objectives.   The organization wants more rigorous change management and also faster and less costly change.  This organization is likely to be unhappy with the results of such a project. 

At the end of the change development process the change proposed should be fully developed and described with complete documentation of the change.

Contact me for the rest of the article or consulting on Management of Change (Contact).