Management of Change – Scoping the Change

Every organization, that has an MOC procedure, scopes out the work of the MOC in some way. In this paper, the MOC procedures of 15 companies are analyzed in detail, along with specific suggestions for improvement.

Objectives (of Scoping)

In the last newsletter [1], we came up with an operational definition of scoping:

• During [the] Scoping [state] one creates a list of things to do, in order to accomplish the change. These “things to do” are normally labeled “action items”. So, it is fair to say that scoping creates the list of action items needed to accomplish the objectives of the change.

We’re now going to take a good look at how companies scope out their MOCs to produce a list of action items.

Experimental Approach

Data Set

This review considers the MOC scoping techniques used by 15 different companies. This is a convenience sample (meaning: “here are 15 MOC forms that people have given me in the last few years”), and there’s no claim that this is statistically valid. The lack of statistical validity is not a problem, because this study isn’t about compiling statistics. The different MOC forms are really just used as a pedagogical tool, since they illustrate different approaches to scoping.

There are a few similarities among all the MOC forms:

1. Every MOC form is real. They are all in use today.
2. Each company, believes that its MOC form satisfies regulatory requirements, generally 29CFR1910.119(l) [2].
3. Every MOC form uses checklists for scoping.

Scoring

Each MOC form was evaluated, and all checklists were carefully evaluated. Each checklist item was evaluated on 5 criteria:

1. Information content (why is this being done?) Each scoping item contains some information, as in the following examples:
   • Does this change involve piping?
   • Does this change involve the plant firewater system?
   • Does this change involve the fail safe position of control valves?
   • Are tank grounding systems adequate for the new service?
   • What temperature does the process run at?
2. Actions (to be performed) Examples of actions include:
   • Redline the P&ID
   • Update the P&ID
   • Review the MOC
   • Approve the MOC
   • Modify the grounding system.
3. Role (of the person performing the action item) Examples of roles include:
   • Process Engineer
   • Mechanical Reliability Engineer
   • Area Environmental Rep.
   • Operator
   • Maintenance Rep.
   • Plant Manager
4. Action item type (perform, sign-off, etc.) Examples of action item types include:
   • Perform a task
   • Review an MOC or document
   • Sign-off on an MOC or task
   • Notify: i.e. be notified about something
5. State (during which the action item is supposed to be performed)
   • Change Design
   • Impact Analysis
   • Approvals
   • Etc.

The states during which an action can occur depend on the lifecycle. For a permanent, non‑emergency MOC, the states are shown in Figure 1.

Figure 1. LIfecycle states for permanent, non-emergency MOC.

In order to simplify comparisons between the different companies’ scoping approaches, a visual comparison technique was developed using ideograms. The construction of a scoped action item ideogram—let’s just call them “symbols”—is shown in Figure 2. So, a scoping question that specifies an action, e.g. “Redline the P&ID”, has the top triangle shaded. A scoping question that specifies a role, e.g. “Process Engineer”, has the lower left triangle shaded. A scoping question that provides additional information or specifies why something is being done, e.g. “does this change involve piping?” has the lower right triangle shaded.

Figure 2. Scoped action item symbol, showing the meaning of the shaded regions.

A “Perform” action item uses blue shading; a “Review” action item uses green shading, etc., as shown in Figure 3.

Figure 3. Color code for scoped action item symbol shading.

A “fully-formed” scoping question would contain all 5 elements:

1. Information: Does this change involve the plant firewater system?
2. Action: Review the MOC
3. Role: Area Safety Rep.
4. Action Item Type: Review
5. State: Approvals state

A fully-formed scoping question therefore would have all 3 regions shaded, in the appropriate color, and it would be allocated to a specific state.

A “partially-formed” scoping question contains 4 or fewer elements, and therefore its symbol is either partially shaded or not allocated to a state.

There are a total of 40 theoretically possible scoping question symbols (2 values for “Action Item specified” X 2 values for “Role specified” X 2 values for “Information specified” X 5 action item types [including information-only] ). However, in practice, only 15 scoping question configurations were seen.

Results

The most common kinds of scoping questions are listed in the following table.

Symbol	Description	Samples
	This is a fully-formed Perform action item: The reason for the action is stated The action is properly described The intended role is identified hen the action is to be performed is identified	Example 1: Does this change involve a safety critical alarm? Perform a PHA Process engineer During the impact analysis state Example 2: Does this change introduce or modify the inspection frequency of new or existing equipment? Update inspection database Mechanical Integrity group During the Implementation state Example 3: Will this change exceed the relief capacity of individual pieces of equipment? Conduct pressure safety review Mechanical engineer During Change Design state
	This may be termed “brute force scoping”. The statement indicates what needs to be done, who should do it, and when to do it. What’s missing is the reason for the action, although the reason can often be determined by the context.	Example 1: Redline electrical drawings Electrical Engineer During Change Design During the impact analysis state Example 2: Complete the appropriate piping inspection. Inspector During Implementation Example 3: Update process flow diagram, by incorporating redlines. Process Engineer During Close-out
	These action items explain what is to be done, why and when. All that’s missing is an indication of the intended role.	Example 1: Is the change classified s a major change? Complete the Activity Screening form. During Impact Analysis Example 2: Do the changes in test methods require revalidation? Revalidate the test methods. During PSSR.
	These are commonly expressed as something to do. When the action is to be performed is indicated, but not why or by whom.	Example 1: Redline P&IDs During Change Design Example 2: Assess impact on electrical devices and disconnects During Impact Analysis Example 3: Update safe operating limits During Close-out
	These actions indicate what to do and who is supposed to do it, but not why or when.	Example 1: Update instrument specifications. Instrument Technician Example 2: Update Risk Management Plan Environmental Representative Example 3: Environmental Representative Control Systems Engineer
	These are commonly expressed as something to do. But there is no indication as to why, who or when?	Example 1: Update P&ID Example 2: Does the asset database need to be updated? Example 3: Test control system change
	This is a fully-formed Review action item: The reason for the action is stated The action is properly described The intended role is identified When the review is to be conducted is identified	Example 1: Does this change involve placing equipment or operators close to flares, fired heaters or other heat sources? Conduct a review Process Engineering During the Approvals state Example 2: Does this change involve increased Conduct a review Area Environmental rep During the Approvals state Example 3: Has the effect of potential contaminants been evaluated in the design of this relief valve? Conduct a review Pressure Safety group During the Change Design state
	This is a “review without guidance”. The MOC form lists who should participate in the MOC review, and when it occurs.	Example 1: Review MOC Operations During Approvals Example 2: Review MOC Process Safety During Approvals Example 3: Review MOC Laboratory During Approvals
	This is a well-formed sign-off. It includes an indication of who is to sign-off and why they are doing it.	Example 1: Does this change modify the relief system design for any equipment or piping? Sign-off Engineering Representative During Approvals Example 2: Does this change introduce a new chemical? Sign-off Quality Representative During Approvals Example 3: Does this change add, remove or alter piping or equipment? Sign-off Mechanical Integrity Representative During Approvals
	This is a “sign-off without guidance”. The MOC form lists who should sign-off on the MOC, and when the sign-off occurs.	Example 1: Sign-off on the MOC Engineering – Corrosion Control During Approvals Example 2: Sign-off on the MOC Operations – SCADA During Approvals Example 3: Sign-off on the MOC Finance During Approvals
	This is a well-formed notification. It includes an indication of who is to be notified, and why they are being notified.	Example 1: Notification of utility change: the steam system is being decommissioned The person is sent a notification Plant Operations During Implementation Example 2: Notification that unit is ready to start up. The person is sent a notification Plant Manager During PSSR
	This is a “notify without guidance”. A notification is sent to the recipient, but without any further explanation.	Example 1: Notify Operations During Implementation Example 2: Notify E&I Maintenance During Implementation Example 3: Notify Operations During PSSR
	This scoping question only provides information. It is not action-oriented. However, other information on the checklist (like a heading) indicate when these questions are to be addressed..	Example 1: Does this change require an Environmental Aspect Analysis? During Impact Analysis Example 2: Physically change vent configuration? During Impact Analysis Example 3: Does this change have the potential to increase production rates? During Impact Analysis
	This scoping question only provides information. It is not action-oriented. It’s possible to guess what might be needed, but the information provided simply doesn’t explain what is needed.	Example 1: Critical equipment added to Critical Equipment List Example 2: Maximum temperature Example 3: Does the change add or modify a tank larger than 50,000 liters?

Analysis

Let’s take a look at what different companies are doing… The scoping items were analyzed for 15 companies were analyzed and plotted in and Figure 5. The symbols are scaled so that the area is proportional to the number of items. For example, a triangle with a base length of 0.1” represents 1 item, while a triangle with a base length of 0.2” represents 4 items. The largest blue triangle for company N represents 221 items; the large information symbol for Company O represents 428 items.

Minimalist Scoping Approach

Companies A, B and C have a very minimalist approach to MOC. The MOC Initiator creates a list of things to do, guided by a checklist. Since there’s no indication of who, why or when the action items are to be conducted, we can only assume that the Initiator acts as project manager and schedules all the tasks individually.

Minimalist Scoping; The PHA is Where the Action Is

Company D operates a large refinery. The MOC scoping process produces action items: what and when are specified, but not who or why. A review of the MOC procedure reveals that the logic that this company uses is that the scoping process produces a minimal list of action items. Every MOC goes through a PHA process (usually HAZOP). It’s up to the PHA team to decide what “really” needs to be done on this MOC. The obvious flaws from this process are:

1. The PHA isn’t conducted until after the important drawings are redlined, so redlining of some design documents may be overlooked, and,
2. the PHA team is (appropriately) focused on safety, so administrative aspects of the change (e.g. update the PSV database) may be overlooked.

Inspection is Where the Action Is

Company E also runs a similarly-sized refinery to Company D. The design work is “stateless”; the scoping process does produce a list of what documents need to be updated, and by whom, but not when the updates are supposed to occur.

Recall that company D used the PHA as the “sanity check” on the MOC; similarly company E uses inspection as a sanity check on the MOC. Inspections are identified and scoped at a very granular level, including making over 100 inspection forms available to the MOC process.

Always the Same Approvers

One might wonder why there aren’t any approval actions indicated for companies A thru E? The reason is that a specific set of approvers is specified by the MOC procedure, and the same approvers sign-off on every MOC. So, the approvers are not selected by scoping; a standard set of approvers is simply part of the process.

The obvious shortcomings of a static approver list are:

• Not enough approvers: New circumstances may arise, that require additional approvers. No doubt the extra person(s) are invited into the process, which is technically a process exception.
• Too many approvers: Oftentimes, approvers sign-off on MOCs that have little to do with their specific area of expertise.

Approvals is Where the Action Is

Companies G, H and J all depend on the approvers to assure the success of an MOC, so a great deal of effort is spent on identify the proper approvers based on the characteristics of the change.

Company G represents the first rather complete example of scoping, since action items are created for all states. The MOC procedure at Company H gathers a lot of information (see large stateless information symbol), but makes no attempt at scoping the MOC beyond the reliance on approvers.

Impact Analysis is Where the Action Is

Company K’s MOC process is singularly focused on risk avoidance. The scoping process identifies lots of things that need to be looked at during the impact analysis state. Specifically, the scoping activity identifies items of concern for the PHA, the environmental review, the personnel safety review, the industrial hygiene review, etc. The impact analyses are then reviewed by a standard set of approvers.

Interestingly, the scoping activity doesn’t provide any helpful guidance on what documents need to be updated, or any activity that has to be performed.

Company L also has exhaustive questionnaires related to impacts (especially environmental) of the change. However, the scoping activity at Company L covers the entire lifecycle, a much better arrangement than the overly restrictive approach of Company K.

The Technical Review is the Heart of the MOC

Company M has one of the lengthiest MOC scoping questionnaires. And, the questions are very complete with full consideration regarding what needs to be review, by whom, and why. Most of the scoping activity is focused on identifying the proper technical reviewers. Compared to Company I, the large green symbol for Company M indicates that the technical concerns are considered at a very granular level.

Additional action items, like redlining certain drawings, etc., are scoped, but there’s indication of when they are to be done. Presumably they need to be completed in time for the review?

Perfect MOC Scoping is Achievable

Company N has the best quality AND most comprehensive scoping activity, of all those considered. Notice how every scoped element, whether a call to perform an action (blue), a review (green) or a notification (yellow) is fully scribed. There’s a statement of why the item needs to be done, what role is supposed to do it, what kind of action it is, and when it should be performed. The symbols in Figure 5 represent a total of 611 scoped items. Note also that there are no stateless tasks—every task is clearly identified as to when it needs to be performed.

There are no sign-offs (red) because the sign-offs during the Approval state are part of the process; they are not scoped into the MOC.

Figure 4. MOC scoping practices of 11 companies.

Redlining vs. Updating

Normally, MOCs are performed on existing assets in the plant (or an existing product, etc). Obviously, there are existing documents which describe those assets. Modification of documents, in the MOC context, is a two-step process: the documents are first redlined, generally during the Change Design state; once the change is made to the plant, the documents are updated, generally during the Close-Out state.

The processes of Company N, and to a lesser extent J and L, clearly show this characteristic. There are many action items that take place during Change Design, and many during Close-Out. The fact that not every company’s process has these features is an additional indication of vagueness.

Information is Where the Action Is

Company O has a detailed questionnaire for each MOC. The large symbol with the black shading in the lower right, in Figure 6, indicates that there are 485 information gathering questions that must be addressed during the scoping activity. The company has structured the questions sensibly, so that only the relevant categories of questions are answered during scoping. Someone has gone to a lot of trouble to put these lists together. Wouldn’t it make sense to complete the job by identifying associated action items?

To some extent they have done that. There are an additional couple of hundred scoping questions which do identify actions that need to be performed. But, as shown by the blue symbols in Figure 6, the company didn’t go all the way—specifically, there’s no indication of when these actions need to be performed.

To the credit of Company O, the process does produce a good list of technical reviewers (green symbol) for each MOC.

Figure 5. MOC scoping practices of 4 companies.

Case Study: An Ideal, Scoped MOC

The quality of scoping, illustrated in the previous section, ranges from marginal (Company A) to superb (Company N). Most companies had clearly identifiable gaps in their MOC scoping approaches. For the record, none of the companies A thru O were Gateway clients, when they created their MOC procedures, so I can’t take responsibility for their failures or claim credit for the successes (Company N)!

But, I would like to share with you a project which we completed last month.

The client is a global chemical company. They have about 100 sites worldwide, a few are quite large (hundreds of employees), and the majority are quite small (less than 10 people per site). Highly hazardous chemicals, of the kind found in Appendix A of the PSM regulations [2], exist at a few, but not the majority of sites. Everyone is obliged to use the MOC process, whether they are at a PSM-regulated site or not.

At the start of the project, the existing MOC procedure was similar to Company H, shown in Figure 4, although I must emphatically state, the client is not Company H.

The company had already assembled a team of about 6 key stakeholders, who participated in face-to-face meetings, with an additional 5 in Europe who initially participated by teleconference, but also in-person for the final meeting.
The scoping redesign took place during 3 facilitated team meetings and individual work in the interim.

The first team meeting was a full day. The team “tore apart” the existing process. Every item was questioned, and, after having read this newsletter, you already know what the questions are: what? what kind? who? why? when? This highlighted data gaps, like the lack of an official list of units for all the plants.

Between the first and second meetings, the facilitator reconstituted the scoping process based on the input from the first meeting. The second meeting was again, face-to-face, but this time only a half day.

The facilitator presented the updated scoping process at the start of the second meeting. The team critiqued what the facilitator had prepared. This meeting was considerably more enjoyable, since it’s always more fun to critique the facilitator’s work than it is to critique one’s own work (meeting 1).

Between the second and third meetings, the facilitator quickly updated the scoping materials, and distributed them. Each team member was asked to be extremely critical and identify any scoping detail that they did not entirely agree with. This feedback was consolidated, and the final scoping ruleset was updated by the facilitator.

The third meeting was only 2 hours, and really served to ratify the work that the team had accomplished.
What was the outcome?

Using the evaluation approach, described in the previous sections, the new MOC scoping approach at this company is as shown in Figure 6. In order to make the symbols in all the diagrams comparable, they are sized to the same scale; that is, a symbol with a given area in Figure 6 represents the same number of action items as a symbol with the same area in Figure 5.

The new scoping approach at this company incorporates all of the positive attributes previously identified:

• 100% of action items are fully-formed: the action, the type of action, the role, the reason for the action and the timing are all specified
• All the action items that can be specified1 up front, are specified. Little is left to individual’s memories.
• The separation between redlining (blue actions during Change Design) and document updating (blue actions during Close-Out) is recognized.
• The quantity and extent of hazards at this company are less than Company N. So, it’s reasonable that there are fewer scoping items, as indicated by the area of the symbols in Figure 6 being smaller than the area of the symbols in Figure 5.

Figure 6. An ideal, scoped MOC.

Can You Do This at Your Site?

The critical resource at most sites today is manpower. People have “too much to do” and are often resistant to taking on a new, perhaps open-ended initiative.

The team’s contribution to this activity was as follows:

1. Initial meeting: 8 hours each team member.
2. Interim data gathering: 8 hours for the team leader
3. Second meeting: 4 hours for each team member
4. Interim review: 2 hours for each team member. 8 hours for the team leader
5. Third meeting: 2 hours for each team member.

In order to achieve this optimized level of team involvement, a properly-experienced facilitator is a necessity. If you and your team are able to make this time commitment, better-scoped MOCs may be within your grasp, as well!

Final Note

The new scoping process has been implemented in the client’s electronic MOC system. The users are very, very enthusiastic about the improvements to the MOC system.

Certain action items, like PHA follow-up items and PSSR punchlist items can obviously not be determined during scoping, and are added into the process later, as needed.

Reference

[1] Hoff, R., 2011, “Scoping – Action Items,” MOC Best Practices, 5(2).

[2] OSHA, 1992, “Process safety management of highly hazardous chemicals,” 29CFR1910.119, OSHA, Washington.

Appendix A: MOC Scoping Coding

As stated in the body of this newsletter, a “fully-formed” scoping question would contain all 5 elements:

1. Information: Does this change involve the plant firewater system?
2. Action: Review the MOC
3. Role: Area Safety Rep.
4. Action Item Type: Review
5. State: Approvals state

While the information, action and role can be directly determined from the scoping questions, the “action item type” and “state” usually couldn’t be extracted from the MOC procedures, because many would regard action item type and state to be the author’s terminology, and perhaps not industry standard.

Most of the time, the form/procedure gives no indication as to when the task is to be performed. But we’ll assume that the people running the process are sensible, and will behave reasonably. So, certain things are allocated to certain states, even if the procedure doesn’t explicitly spell it out. Specifically:

• Anything labeled “approval” will be a sign-off type action item, performed during the Approvals state,
• Anything labeled “review” will be a review type, conducted in the Approvals state,
• Anything labeled “redline” will be a perform type, conducted in the Change Design state,
• Anything labeled “update” will be a perform type, conducted in the Close=Out state,
• Anything related to impact analysis with be in Impact Analysis state, if it uses a verb. If it’s informational, we leave it as informational,
• Anything using the word “PSSR” will be in the PSSR state,
• Anything that is described as a plant notification, will be in the PSSR state,
• Anything that is described as training will be in the Implementation state.