Management of Change – Capital Projects and Turnarounds

There are often multiple business processes taking place at the same time in a refinery or chemical plant. Major business processes include:

• (large) capital projects,
• small projects,
• turnarounds,

and each of these interacts with MOC’s in some way. It’s important to position these business processes appropriately, so that there are no gaps (“I thought you were doing that”, “No, YOU were supposed to do that”) at there is no duplication of effort. We’ll take a closer look at each of these processes, in order to determine the best practice.

Taking a “closer look” may be easier said than done, since each of the aforementioned business processes is quite complex, in its own right. Comparing and contrasting them may be intractable. In order to manage the complexity of these comparisons, it’s necessary to reduce each of process to its simplest form. For MOC’s we’ll introduce the notion of “Extreme MOCs”.

Extreme MOC

The notion of “extreme” has become more prominent nowadays, and examples from popular culture are given in Table 1. Although Extreme Fighting is used as the competitive sports example, there are indeed many sports which have evolved an “extreme” format. Note that there’s a recurring theme of taking some aspect of the activity to the limit.

Table 1. Extreme activities in modern culture.

An interesting thought experiment would be to see if there is an extreme MOC format. Let’s coin the acronym “xMOC” for extreme MOC. An xMOC would contain the absolute bare minimum of elements. Figure 1shows the OSHA 1910.119 wording for Management of Change. Paragraph (l)(1) indicates that a procedure must be in place to manage changes, which is a governing requirement. Each MOC instance must have the nine essential elements highlighted in the figure.

An xMOC form could be created from these 9 elements, as indicated in Figure 2. Just as Extreme Fighting and be hazardous to your health, and Extreme Snowboarding is potentially life-threatening, using the xMOC form in a real company has all kinds of risks associated with it. We’ve only developed the xMOC form as a thought experiment, since it will help illustrate certain points discussed in the following sections.

(Large) Capital Projects

Introduction to Large Projects

Refineries and chemical plants are often expanded or upgraded via large capital projects. These projects typically range from $1 million to $1 billion in today’s currency.

The nomenclature is sometimes confusing. At most plants, these are called “capital projects”. True, but the word “capital” refers to an accounting designation. The important attribute of these projects, from a business process standpoint, is that they are large. We could call them “large capital projects”, but let’s simplify and just call them “large projects”.

A great deal has been written about how to effectively manage large projects. The Project Management Institute is a professional organization and advocacy group for project management, has many resources available on their website: www.pmi.org, and promotes the notion of a “Project Management Body of Knowledge1”. Ref. [1] begins with a generic 3 phase model: “Initial”, “Intermediate” and “Final”. These phases are then fleshed out with details more common to MOC, including Initiation, Planning and Execution.

Project Management Institute, Inc., A Guide to the Project Management Body of Knowledge, Third Edition, Project Management Institute, Inc., Newtown Square, PA, 2004.

Figure 1. Annotated Management of Change regulation, showing the 9 essential elements.

Figure 2. Extreme MOC form.

Another resource, in this domain is Kepner‑Tregoe, Inc. which provides consulting services and training in project management. Kepner-Tregoe employees, including the eponymous Messrs. Kepner and Tregoe, have authored books on the topic of project management1.

The Kepner-Tregoe, “KT”, model represents a project in 3 large phases. Note that KT do not use the word “capital” to label the phases.

Longman, A., and Mullins, J., The Rational Project Manager, John Wiley & Sons, New Jersey, 2005.

Figure 3. The 3 phases in the Kepner-Tregoe project model.

Most large organizations understand the need for a systematic project process, and have taken the KT or similar model and adapted it for local usage. Figure 4 shows how Company A has decomposed the 3 phases of the KT model, into 7 lifecycle states for large projects; Company B uses 8 states to achieve the same goals. Note also that, while “Initiation” and “Close-Out” are widely accepted as the names for start and finish, the intermediate state names are different, even though the work is very similar.

Figure 4. Adaptations of the KT model by various companies.

It turns out, that the relationship between the MOC process and the Large Projects process can be illustrated at the phase level. This avoids the problem of trying to identify which Large Project lifecycle is the “correct” one and which set of terminology is preferred.

The Relationship between Large Projects and MOCs

A large project process generally requires the performance of a full Process Hazards Analysis. So, it looks like essential element 2 is already addressed by the large project process, so there’s no need to redo it for MOC purposes.

The design of a large project would, if relevant, consider how current operations might be impacted, so essential element 3 is addressed.

Project management has time as one it’s three critical variables (scope and cost being the other two), so essential element 4 is addressed.

A large project generally has a large budget requiring multiple approvals to cover the technical and financial aspects of the project. So, essential element 5 is also addressed.

Informing affected persons, training, updating and releasing documentation into productive use are all tasks normally conducted during a large project. So, essential elements 6, 7, 8 and 9 are addressed by a major project.

Figure 5. How the essential MOC elements are addressed in a large project.

It appears from Figure 5 that all of the essential MOC elements are already covered by the Large Project process. So if an MOC were initiated to “cover” a large project, the role of the MOC would simply be to record, in some concise manner, that all the essential elements of the MOC regulations have been addressed.

As shown in Figure 6, the large project controls the scope of the MOC and controls the timing of the MOC, and from Figure 5 the “real” work is already covered by the large project process itself. Since the MOC is entirely dependent on the large project, we can call the MOC a passive process and the large project an active process. Therefore, we can arrive at the interesting conclusion that:

“In a large project environment, the MOC process is generally a passive process, focused on quality assurance concerns”.

There may be projects related to, but not contained by, the large project and these related projects may be active (instead of simply quality assurance) and independent, but these will be discussed in the section on “Stand-Alone MOCs”.

Figure 6. The relationship between large projects and MOCs.

Is An MOC Even Needed For A Large Project?

Shortly after the PSM regulations were promulgated, a Ms. Susan Tolley acting on behalf of Chevron, asked OSHA for an interpretation about when a project is large enough to be considered “new construction” and therefore exempt from the MOC requirements. She writes:

How can we determine the point where changes to an existing facility have become so extensive that it should be considered a ‘new’ facility? We find the PSM standard to be very clear in the definition of ‘replacement in kind’ and how to determine the point when a facility is considered ‘modified’, but less clear on the issue of when changes have progressed beyond ‘modification’.

The question presents a “bottom-up” perspective: we start with a small change (MOC required), and imagine increasingly larger changes until we reach the point of “new facility” (no MOC required).

The OSHA response1, in contrast, provides a “top-down” perspective. Here it is:

“Please note under paragraph 1910.119(b), ‘Definitions’ that a ‘facility’ means buildings, containers and equipment which contain a process. A facility constructed on a work site where there are no other facilities is considered a new facility…A facility, subsequently constructed on the work site such that it is physically separated from and otherwise independent from existing facilities, is considered a new facility. (A facility is considered independent when the facility including the process(es) contained in the facility would not affect or be affected by an existing facility including the process(es) it contains. Otherwise the facility is considered a dependent facility.) …A facility, subsequently constructed on the work site such that the facility or the process(es) it contains is connected to or otherwise dependent on an existing facility including the process(es) it contains, is considered collectively to be a modified facility.”

The first highlighted text indicates that construction on a green-field site, “where there are no other facilities”, is a new facility, and therefore exempt from MOC requirements.

The last sentence states that any construction that is “connected” or “dependent on” an existing part of the plant IS INDEED a modified facility. There is a common belief that a new unit that gets all of its feedstock from tanks, and discharges all its product to tanks is therefore not dependent on other units. However, since the first sentence in the quote “ ‘facility’ means buildings, containers…” identifies containers, i.e. tanks, as being facilities, it’s hard to imagine a scenario where an expansion at an existing site would not be dependent on or connected to the existing facility. In other words, every plant expansion, no matter how large and no matter how new, is subject to MOC.

The title of this section is “is an MOC even needed for a large project?” The answer appears to be yes, with exceptions only in extremely rare cases.

Stand-Alone MOCs

Introduction

In the previous discussion we saw that, generally speaking, for large projects:

• The WORK of the change is driven by the active process: the large projects process,
• MOC is a passive process, and entirely dependent on the large project.

Is the same thing true for small projects, say, in the $1,000 – $10, 000 range?

3 OSHA Standard Interpretation, 01/11/1996—Process safety management at what point a work site change would no longer be considered a modification but a new facility.

In a word, “no”.

In theory, small projects could be treated like large projects, and the relationship between small projects and MOC could be the same as the relationship between large projects and MOC, but that’s not observed in practice.

In order for the relationship between small projects and MOC to be the same as the relationship between large projects and MOC, there would have to be a similarly robust small projects process. That’s generally not found in practice; what we do observe is one of the following:

1. Company policy states that “all projects should follow the same process”. However, the large project process introduces formality, reporting, etc. which is perceived to be excessively burdensome for small projects. So the (large) project methodology is simply ignored for small projects.
2. A company has a separate process for small projects. However, if you asked people at the site what the process was, how it works, where the data is, etc., you would receive blank stares. A quick investigation may reveal that the process was only used sporadically and hasn’t been used for a decade.
3. A company has a separate process for small projects, but it’s really just an extension of the work order system. These small project processes tend to be followed, but they begin too late (i.e. they begin during implementation, not planning) for them to actually be comparable to the large project process. However, this is a common approach at non-US (i.e. non-OSHA regulated) sites.

Without a complementary process to “do the work of the change”, as would be the case for large projects, it’s now incumbent upon the MOC process to actually do the work of the change, or cause the change to happen.

Figure 7 depicts active MOCs: there is no associated large or small project process to move the MOC through its lifecycle, so the MOC process must cause the change to progress from one state to the next. The MOC process must cause the change to be designed, the impact to be assessed, approvals to be obtained, the PSSR to be conducted, etc. So,

“In a small project environment, the MOC process is generally an active process, not simply a quality assurance process”.

Figure 7. MOC as a small project.

MOC Relationship With Action Item Management

Many plants have a centralized action item, or “issue”, management system. This system would contain issues, recommendations, and findings from events like:

• environmental, PSM, safety or records management audits,
• PHAs
• PSSRs
• incident investigations
• gap analyses associated with complying with new regulations
• efficiency improvement ideas.

These issues are reviewed periodically and appropriate actions are taken to resolve the issues. Often an MOC is necessary to resolve an issue. As shown in Figure 7, we could consider that the action item has “triggered” an MOC. The action item does not control the MOC, since the action item has no inherent resources to do the work of the change like a large project does. The action item can set the scope of the MOC (i.e. state what needs to be done), and the action item may set the timing of the MOC (i.e. state when the MOC needs to be done).

Turnaround Projects

Introduction to Turnaround Projects

Turnarounds constitute the largest single maintenance expenditure in a plant. Not surprisingly, there’s a large body of knowledge on how to conduct an efficient turnaround.

Figure 8. The 3 phases of a turnaround project, analogous to the Kepner-Tregoe project model.

Various authors have written about the phases of a turnaround, and they mirror the large capital project process quite well. Figure 8 shows the KT project model adapted for turnaround use. Brown1 uses the terms: Work Identification, Work Planning & Scheduling, and Project Execution to refer to the 3 phases. Lenahan2 uses the terms Initiation, Planning and Execution to refer to the 3 phases. Both authors specifically mention that the Definition phase is, unfortunately, commonly overlooked, which then causes later problems.

Turnarounds are implementation task oriented. In contrast to large projects, which employ substantial design resources, turnarounds employ minimal design resources.

The Relationship between Turnarounds and MOCs

Turnarounds are the most complex to analyze in regards to their relationship with MOCs, because there are several different kinds of relationships among them.

The first case, and possibly the most common, occurs when MOCs proceed (partially or completely) through the MOC Request Phase, but cannot proceed because implementation requires the unit to be shut down. In other words, these changes, indicated by the 1 symbol in Figure 9, must wait for a turnaround. These are typically stand‑alone MOCs, as described in the previous section. The scope of the MOC is determined from any reason other than the needs of the turnaround itself. Only the timing of the change is determined by the turnaround plan.

The second case, 2, occurs when Turnaround Planning is taking place and the turnaround team decides to make a change to the unit. The purpose of these MOCs is to make the turnaround itself proceed more quickly or better in some way. These MOCs are intimately tied to the turnaround, with both the scope and timing of the MOC determined from the turnaround plan.

4 Brown, M.V., Managing Shutdowns, Turnarounds & Outages, John Wiley & Sons, Indianapolis, IN, 2004.

5 Lenahan, T., Turnaround, Shutdown and Outage Management, Butterworth-Heinemann, Burlington, MA, 2006.

One of the most common reasons, for making a change, is to correct deficiencies that are found once the unit is shut down and opened up. Technically, this would be considered the Implementation phase. But, once such a deficiency is found, a planning exercise must take place to specify and schedule the resolution of the problem. The associated MOC is as shown by the 2 symbol in Figure 9.

Finally, there is a possibility that the design engineering activities of a turnaround are so extensive that new designs are created, hazards assessed, and so on. This stream of activities is analogous to the large capital project discussed previously. If the essential elements of an MOC are already addressed by the large project activities, then the MOC process is passive, as shown by the 3 symbol.

Figure 9. The relationship between turnarounds and MOCs.

Discussion

The previous discussion is summarized in Table 2. It appears that MOCs work their way through an organization quite differently, depending on the context.

Table 2. Typical positioning of MOC in the context of other business processes.

Implications for Design of the MOC Process

Designing a business process is easiest when the same actions occur each time the process is executed. For instance, submitting an expense claim has certain commonality each time it’s performed:

• Initiator opens an expense claim form
• Initiator completes the form listing each expense item
• Initiator attaches receipts substantiating claims.
• Supervisor approves the claim
• Accounting issues payment
• Initiator receives payment

A similar business process description cannot be created for MOC since who does what depends on the context. For instance:

• for stand-alone MOCs, drawing update is triggered by the MOC process, and performed by designers or engineers “working on change”,
• for large projects, drawing update is performed by the engineers designing the project, with little or no concern about the existence of an associated MOC,
• during turnarounds, drawings may be updated as for stand-alone MOCs or large projects,
• furthermore, during turnarounds, drawings may already have been updated by a stand-alone MOC that’s waiting on the turnaround for implementation.

Lifecycle Model: The first implication, of these observations, is that the MOC business process MUST be able to accommodate these difference circumstances. As a consequence, any attempt to automate a step-by-step approach to MOC is bound to fail. Either it will be too unwieldy for passive MOCs, or be totally inadequate for active MOCs. The solution is to avoid step-by-step automation altogether, and to represent MOCs using a lifecycle model. This has been discussed in previous newsletters (especially vol. 1, no. 2, Dec. 2007).

Metrics: The second implication deals with metrics. Metrics are key to business process efficiency measurement and improvement1. The authors of Risk Based Process Safety2 make a strong case for metrics and provide almost 20 metrics that may be relevant to MOC. However, target values for some of the metrics would be quite different for the various MOC cases listed in Table 2. Examples include:

• The average backlog of MOCs: Normally a large backlog would point to inefficiency. However, an increasing backlog of MOCs is desirable prior to a turnaround, since it indicates that turnaround planning is actually taking place.
• The average amount of calendar time taken between MOC origination and authorization. Passive MOCs and turnaround-related MOCs have no control over their execution time. Only stand-alone MOCs do.

To be fair to the authors of ref [6], they state several times that these are only suggested metrics, which, “the reader will need to determine how to track and present data to most effectively monitor the health of the RBPS management systems at their facility.”

Extension to Other MOC Circumstances

The foregoing discussion focused on plant applications. Of course, not all MOCs occur at plants. Companies use the MOC process to manage changes at off‑shore platforms, land-based wells, remote processing facilities, and piping and gathering systems. Management of change under these circumstances will fall into one of the 5 contexts listed in Table 2.

6 Creveling, C.M., et al., Design for Six Sigma, Prentice Hall, Upper Saddle River, NJ, 2003

7 Center for Chemical Process Safety, Guidelines for Risk Based Process Safety, John Wiley & Sons, Inc., Hoboken, NJ, 2007.