Management of Change Attributes

When a change is initiated, the initiator typically enters data into an MOC form. The form may be the traditional paper form, or it may be an electronic form. This paper will methodically review every attribute that could reasonably appear on an MOC form, and provide insight into how best to use them.

The following discussion often makes reference to various states in the MOC lifecycle. The permanent, detailed, non-emergency lifecyce was presented in a prior newsletter, but is reproduced here for convenience.

Figure 1. Lifecycle for permanent, fully-detailed, non-emergency MOC.

Identification Attributes

MOCs need to be given a name, or identity. Sample identification attributes may appear as shown in Table 1.

Table 1. MOC identification attributes.

MOC Number

MOCs are typically assigned a tracking number, called an “MOC Number”. Examples include:

• MOC-12345: a simple tracking number
• MOC-10-1234: a tracking number which includes the initiation year

Two issues arise with MOC numbers:

1. When should an MOC number be assigned?
2. Should it be significant?

Number Assignment Time

There are divergent opinions about when an MOC number should be assigned. Traditionally, and particularly in paper-based systems, the MOC number wasn’t assigned until someone had accepted that the change idea has merit. Usually this was an area manager/operations superintendent who looked over the candidate MOC form and signed off after it was initiated. Note that the MOC is still far from being approved, but at least the concept has received preliminary acceptance, by the person who probably will fund the change. The argument in favor of this approach is that a certain number of MOCs will not be accepted once initiated, so it is unwise to assign number to them prior to acceptance. Otherwise, the unaccepted MOCs are treated as “cancelled” MOCs, and this would create a large increase in the number of cancelled MOCs, and draw attention from auditors. Better, the thinking goes, to pretend the MOC never existed by not assigning it a number.

Others have taken this logic even further and not applied an MOC number until the end of the Approvals state. The argument is that, “it’s not really an MOC until it’s approved.”

With electronic systems, every time an MOC is instantiated, it must be assigned a unique key. This could be an internal number or some other form of temporary number, but, more often than not, it’s the “real” MOC number.

All of the above numbering systems are in use, and all can be made to work in either paper or electronically. A best practice, in this regard, would likely be based on simplicity criteria, resulting in the following rules:

• Paper-based systems: An MOC number shall be assigned after the MOC initiation is accepted. This is because obtaining an MOC number usually requires requesting the number from the designated authority (e.g. document control center, MOC coordinator). Applying the MOC number can easily be performed at the end of initiation.
• Electronic systems: An MOC number is assigned as soon as a new MOC is instantiated in the system.

Significant Numbering

“Significant” numbering is also referred to as “intelligent” numbering. A significant number is structured in such a way that a person who knows the system can glean attribute information from the number.

This was more helpful in the past. For instance, engineering drawings were often given a number such as DWG-12345/E. The “/E” indicated that it was an ANSI E-size drawing (34” x 44”), which suggested in which filing cabinets the original might be found, in order to make a diazo or “blue” print. Nowadays, virtually all drawings are created in a CAD system, so a size designator wouldn’t help in locating a drawing. Over the last decades, drawing size designators have been universally dropped from drawing numbers.

There’s no limit to how much information could be encoded in an MOC number. For example:

MOC-10-DES-TMP-100408-12345 might mean: “An MOC, initiated in 2010, for the DESalter unit, that’s temporary, expiring April 8, 2010, with sequence number 12345”, to create a ridiculous example.

There are some arguments in favor of significant numbers:

• An significant number conveys useful information
• An significant number can provide site isolation: Suppose your company had 5 plants, and there’s some compelling reason for having unique MOC numbers across all sites. Obviously each site can’t start with MOC-00001, since there would 5 such MOC’s with the same number. However, if the numbering scheme were MOC‑A‑00001, MOC-B-00001, and so on, then the MOC numbers would be unique across all the sites. Each site could number its own MOCs in isolation from the other sites. It’s not uncommon for large companies to have document numbering standards like this.

There are more arguments against significant numbering:

• Significant numbers are inherently longer, which means there’s a greater probability in making a transcription error when they are written down.
• Although significant numbers are an occasional aid for certain people, they have diminishing importance in electronic systems, as the drawing size designator example indicated.
• Significant numbers are harder to deal with in electronic systems, particularly when the numbers have to be parsed into fields.
• The fields in the number can be redundant with other MOC attributes. Redundant attributes are generally discouraged.
• The fields can create unwanted constraints. For instance, in the above example the letters “TMP” designate a temporary MOC. What happens to the number if the temporary change is made permanent, as sometimes occurs?

The arguments surrounding the merits or detriments, of significant MOC numbers, correspond to the issues surrounding significant part numbers in discrete manufacturing. Even in discrete manufacturing there’s not necessarily a consensus among accomplished practitioners in the field[5], as to which is better.

This author has spent countless hours in meetings debating the merits of significant vs. non‑significant1 numbering schemes. These discussions often proceed with religious fervor, so it’s unlikely that all the participants will ultimately agree. If we accept that disagreement will occur, then the following two guidelines are reasonable and may be helpful:

1. Significant number should not be categorically prohibited.
2. Always strive to minimize the number of fields in an significant MOC number.

Title/Name

Each MOC requires a brief, say, one-line title or name: e.g. “Install and rerate relief valve on exchanger inlet” provides some reasonable information to distinguish this MOC from others.

Other Identifying Numbers

In a prior newsletter[6], it was shown that an MOC is really a small- to medium-sized project. As a result, certain project management (rather than regulatory) information is often helpful, like a work order number, capital approval request number, etc.

Ownership and Responsibility Attributes

Attributes describing ownership and responsibility are shown in Table 2

Table 2. MOC ownership and responsibility attributes.

Initiator/Originator

The Initiator is the person who has taken responsibility for initiating the MOC.
What kind of person should be allowed to initiate an MOC? With no intention at humor, there are 3 possibilities: one person, a few people, everybody.

One Person Initiates All the MOCs at a Unit

Some sites permit only one person per unit to initiate MOCs. This is essentially a specialist position, which goes by various names, but will be labeled “Unit PSM Coordinator” for the purposes of this discussion. If someone else wants to create an MOC, they must solicit cooperation from the Unit PSM Coordinator, otherwise the change will never begin. This person often also conducts the process hazards analyses, and pre‑startup safety reviews.

The advantages of this approach are1:

1. There is focus on MOC, which increases the probability that MOCs will be done properly
2. The Unit PSM Coordinator must throttle his/her workload so that neither too many nor too few MOCs are in process at any given time.

The disadvantages of this approach are:

1. A large site needs many Unit PSM Coordinators. While all of these resources are performing their function, things work well. But “many” of anything is often a target for consolidation when a wave of staff reductions hits the site. So this arrangement is organizationally unstable over long periods of time.
2. Work is, at best, optimized on a per-unit basis. In reality, the maximum benefit to the plant may occur when the PSM Coordinators are assigned to where the need is the greatest, at any given time, rather than permanently assigned to just one unit.

A Few People Initiate MOCs at a Unit

This is the most common approach.

These individuals could be:

• persons who are assigned to work in the unit: e.g. board operator
• persons who are assigned to work in organizational structure (like areas, zones, complexes) which include the specific unit: e.g. area environmental rep.
• persons who have site-wide responsibility: e.g. process engineer

Any of the above could reasonably be expected to initiate an MOC at a particular unit. The persons who are normally excluded from initiating an MOC, under this approach, are:

• persons assigned to different units
• persons who are assigned to work in organizational structures that don’t include the specific unit.

Everyone Can Initiate MOCs at a Unit

This is a well-intentioned, but poorly thought-out approach.

The logic for universal MOC initiation is often expressed in terms like this:

• “We are serious about process safety.”
• “Anyone who sees an unsafe condition can initiate an MOC, so that it will be looked after.”

This last approach generates many more MOCs than can reasonably be executed. So, either many of them are cancelled, due to lack of resources, or they founder in the MOC system—neither outcome is good.

What’s lacking in this environment is an issue tracking system. Issues should be tracked on a site-wide basis. Issues can be grouped into two categories:

• Opportunities
  • people’s ideas for safety improvements
  • ideas for efficiency improvements
  • ideas for new products
  • ideas for new customers, grades, which necessitate process changes
  • employee suggestions
• Problems
  • PHA findings
  • audit findings
  • PSSR findings
  • new regulatory needs
  • recalls
  • CAPA
  • deviations
  • incident investigation recommendations
  • consent decree action items

Everyone should have the ability to create issues and add them to a consolidated list or system. With a proper system to track issues, regardless of the source, the need for everyone to be able to generate MOCs goes away.

Author

The initiator is the person who takes responsibility for initiating the MOC. However, s/he may not be the person who created the MOC—particularly in electronic MOC systems, the person, whose account was used to initiate the MOC, is captured by the electronic system. This person may be a colleague or administrative assistant working in the unit, who created the MOC under the direction of a much busier supervisor.

This creation role is termed the “author”, to distinguish it from the initiator.

Owner/Responsible Person

At all times, the MOC must have a responsible person assigned. The responsible person, often called the “owner”, performs the following important functions:

• generally monitors progress of the MOC, to ensure that it is proceeding properly and on‑time,
• intervenes in the process when an approval task results in a rejection. The intervention may require creating new work items,
• intervenes in the process in the event an MOC is suspended or cancelled, particularly if that suspension or cancellation produces unacceptable risks.

During the Initiation state, the initiator is the owner of the MOC. Ownership may change as the MOC progresses. The important point is that there must always be an owner for each MOC.

Change Lifecycle

Attributes describing the change lifecycle are shown in Table 3. There are 3 dimensions and each typically has two values, resulting in a total of 8 possible lifecycles. A prior newsletter [7] elaborated on these lifecycle possibilities.

Table 3. MOC lifecycle attributes.

Permanence

Changes can be either:

• permanent, in the sense that the change has no intended duration at the time the change is made,
• temporary, meaning that the change will only be effective for a limited time. Temporary change durations of 90 to 180 days are common. Temporary changes that persist for years, will draw attention during regulatory audits.

Detail

Change can be either:

• fully-detailed, where the entire MOC process is executed, and all the documentation is completed.
• short form. Certain, common changes, with well-understood risks, (e.g. installing a temporary flex hose, installing a temporary pipe clamp) can be streamlined with more succinct documentation.

Urgency

Changes can be either:

• normal, which follow the typical prescribed process, and are not impacted by urgent circumstances,
• emergency: which are normally initiated off-hours in order to respond to an urgent and unanticipated circumstance in the plant.

Priority and Timing

Attributes describing priority and timing are shown in Table 4.

If there are going to be any dates on an MOC, then they should be meaningful. When a date is added, then something should happen on or before that date. The significance of the dates derives from the context and priority of the MOC:

• context: this is how the MOC related to other things going on, specifically turnarounds and capital projects,
• priority: this is how important the MOC is. An MOC that produces a $million/year benefit is clearly more important to the plant owner than one with a $hundred/year benefit.

Table 4. MOC identification attributes.

Context

A stand-alone MOC is one that is initiated on its own and proceeds on its own. It is not, in any way, dependent on a turnaround or capital project. Even with this independence, it’s still necessary to implement the MOC at some point. There are several options:

• some changes can be implemented at any time because they do not involve shutting down any part of the unit,
• some changes can be implemented at any time, but they do require the isolation and shutdown of a certain part of the unit. These changes are important enough that they warrant the shutdown of the affected equipment.
• some changes can be implemented at any time, but they do require the isolation and shutdown of a certain part of the unit. However, these changes are not so vital/critical that it’s worth shutting the equipment down, just to implement this change. The change is more logically implemented when the equipment is shut down for some other reason, which may be a turnaround, but doesn’t have to be.

As discussed in a previous newsletter [6], large capital projects in an existing plant usually require an MOC for regulatory purposes. However, the key MOC activities of demanded by OSHA (hazards analysis, proper approvals, procedure updates, PSSR, etc.), are not triggered or even performed under the umbrella of the MOC; they are triggered by the capital project process. So, in the capital project context, all the dates are governed by the capital project, not by the MOC.

Turnarounds are more complex. As discussed previously [6], any MOC conducted in conjunction with a turnaround, will have its schedule determined by the turnaround. In most cases the scope of the MOC will also be determined by turnaround planning.

This discussion is summarized in Table 5; the values listed in the “Context Label” column, would be reasonable choices to use in an MOC process.

Table 5. MOC context, relevant to MOC implementation timing.

Priority

This attribute is intended to convey the importance of the proposed change. Common choices for priority include “high”, “medium” and “low”, which generally leads to all of them being rated “high”, in fact making this attribute moot.

A better approach is to focus on the reasons for the priority ranking. Here are some reasons for a high priority:

• an MOC which resolves a regulatory compliance issue,
• an MOC which resolves a quality issue, where, without the change, it would not be possible to produce product on-spec.,
• an MOC which allows a customer requirement to be resolved,
• an MOC which produces a substantial financial benefit, say, > $100,000/yr

A medium priority change might include:

• an MOC which produces an important financial benefit, say, between $10,000 and $100,000/yr

A low priority change might include:

• a plant trial of some kind
• an MOC which produces some financial benefit, say, < $10,000/yr

These possibilities might be summarized onto an MOC form, or eMOC user interface, using a scheme like, “High: regulatory”, “Medium: benefit between $10k and $100k”, “Low: plant trial”.

Initiation Date

The initiation date is the date that the change was initiated. In electronic systems, it is automatically captured and stored. In paper-based systems, it should be a truthful date: if the change was initiated on Jan 15th, then this value shouldn’t read Jan 8th simply because the initiator intended to do it the prior week.

Target Temporary Operations Begin

When a temporary change is contemplated, then it’s important that some idea is provided about when the temporary operations stage is supposed to begin. During initiation, the best that can be provided is a target for temporary operations—the actual date is determined when the change is implemented in the plant.

Target Temporary Operations End

When a temporary change is contemplated, then it’s important that some idea is provided about when the temporary operations stage is supposed to end. Again, during initiation, only a target date can be established, not the actual date.

A short duration for a temporary change, doesn’t generally cause a regulatory concern. However, an excessively long duration for a temporary change is problematic. Most companies have a standard for temporary changes in the 90 – 180 day range.

Target Approval Date

When MOCs are conducted in conjunction with a turnaround, or capital project, they must be approved prior to implementation. That requires some coordination between the MOC and the other, larger, business process. A good way of communicating the constraints imposed by the larger business process is to set the target approval date prior to when implementation begins.

Target Close Date

Mostly MOC users are concerned with when the unit or equipment can be started up again, after the change is implemented. That requires an indication of when the PSSR is to be completed. This attribute could just as well be called “Target PSSR Completion Date”. The label “Target Close Date” is more common, even though it refers to the close-out state, which occurs after PSSR.

Location

Attributes describing which locations in the plant are going to be affected by the MOC are shown in Table 6.

Table 6. MOC location attributes.

Unit

The basic building block of a plant is the process unit. MOC’s are usually associated with a process unit, and the persons responsible for the unit are normally approvers of the MOC. Therefore, if a change is taking place to a unit, then it’s important that the unit be identified.

For changes that are not unit-specific, there may be other, comparable physical elements that an MOC can refer to. These include products and customers.

Area

Process units are often aggregated into “areas”. Often a change will involve an area, rather than a unit. A common example is a pipe going from one location in the plant to another, and, in the process, crossing a couple of areas.

Not every plant resource is assigned at the unit level (e.g. area manager vs. unit supervisor), so the area must be identified in order to permit the proper area resources to review and approve the MOC.

Affected Equipment

A unit is composed of a large number of equipment items. It’s useful to understand, more specifically, where the change is going to take place, hence the equipment attribute. Most plants identify equipment location using a “tag number”, which often follow a sequence: pumps P-101, P2320, …; exchangers E-303, E-304, …; heaters H-2701, H4410, …, for example.

Labeling systems also exist for instruments, pressure safety valves, pipes, electrical lines, etc.

This information is useful to help orient the reader of an MOC. Furthermore, this facilitates later statistical analysis: for instance, determining how many MOCs involve pressure safety valves.

New Equipment

An MOC, which involves a unit expansion invariably also involves new equipment. New equipment is different from pre-existing equipment, since all pre-existing equipment has the necessary identifiers (e.g. tag numbers), whilst new equipment does not.

It may be beneficial to identify new equipment on the MOC. When the MOC is created or while the MOC engineering process is taking place, one could simply provide a text string, “Acme X1000PSX pump”. Once the permanent equipment identifier is determined, often by someone updating the site’s maintenance management system, then the final identifier can be applied to the MOC. So, in this example, “Acme X1000PSX” becomes “P-7708”.

Generalizing the “Location” Attributes

The use of location attributes provides a number of benefits:

• Change impact. Indication of where the change is to take place, which immediately indicates what physical elements of the plant will be affected by the change. This is the obvious benefit.
• Authorized persons. Information useful to determine who shall work on the change, and who shall approve the change. Recall that the PSM regulation [1] requires that the MOC procedure identify “(v) Authorization requirements for the proposed change”. Change approvers would typically be different depending on the location in the plant where the change takes place.
• Metrics. Any continuous improvement initiative requires historical data. In the case of MOC, information about location, kinds of equipment, etc. are useful for trending and identifying potential problem areas.

This is, admittedly, an equipment-centric view of MOC. There are other, equally-legitimate change characterizations, which acquire all the same benefits. For instance, in addition to location characterization, changes could also be characterized, by:

• Product line
• Product
• Intended application
• Geographic region
• Customer

Each of these potential characterizations determines change impact and authorized persons, as well as providing useful metrics.

So, using location attributes is useful for characterizing MOCs, and it may be the most common way of characterizing MOCs, but it’s certainly not the only useful way of characterizing MOCs.

Technical Basis of Change

The PSM regulation states, “(l)(2) The procedures shall assure that the following considerations are addressed prior to any change: (i) The technical basis for the proposed change;”

In response to this requirement, the first generation of MOC forms often contained a field called, “Technical Basis of Change”. But “technical basis of change” is not common vernacular, and many did not understand what as required. Curt, but obvious answers like “added a valve”, “changed an instrument” or the extremely obvious, “made a change”, often appeared on MOC forms. Auditors responded that this was completely inadequate, and therefore improvements were sought.

The next generation of MOC forms, in an attempt to improve on the shortcomings identified above, expanded the “Technical Basis” section to two questions, usually labeled “Description” and “Justification”. While this provides a better structure for documenting the Technical Basis, the keywords “description” and “justification” can be broadly interpreted.

A better approach is to replace “description” and “justification” with more specific keywords or key phrases. This is shown in Table 7, where “Technical Basis of Change” is broken into more narrowly-targeted fields.

Table 7. MOC “Technical Basis of Change” attributes.

What is to be changed?

This is a narrative description of the object of the change. For example:

This change replaces all the rubber seals on this pump with neoprene seals.

This serves the same function as the keyword “Description”, but overcomes its vagueness. After all, there can be “descriptions” of many things. What this attribute tries to elicit is a clear identification of the object of the change, i.e. the “what”.

What is to be achieved by the change?

This is a narrative description of the intended results. For example:

This pump will be less susceptible to leaking and therefore more reliable. This will reduce maintenance costs and reduce unplanned outages.

This serves the same function as the keyword “Justification”, but overcomes its vagueness.

This attribute is sometimes improperly left blank on MOC forms—the implication is that it should be obvious why the change is being made. Often a change is implemented months after it was proposed, and the initiator may no longer be involved, prompting others to ask, “why are we doing this change?”

Why will the change achieve the intended goal?

This is a narrative description of why the proposed change approach will achieve the intended goal. For example:

Neoprene is well-known to be more _________ than rubber in this service.

A particular change may be effected in a variety of different ways. Is the approach that is chosen for the change likely to achieve the intended goal?

This is actually a second aspect of the “justification” notion: not only is it necessary to justify why the change is needed (previous point), but also why the proposed approach is likely to be successful.

Change Impact Pre-Screening

A change can have many impacts: process safety impacts, environmental impacts, financial impacts, customer impacts, and so on. The motivation for a disciplined and reliable MOC process can be attributed to the desire for avoiding undesirable impacts. A great deal of effort is often expended in carefully analyzing the impacts of a proposed change, normally during the Impact Analysis state.

However, the Impact Analysis state (see Figure 1) occurs much later in the MOC lifecycle. It appropriately follows the Change Design state since much of the information needed to conduct a proper impact analysis is unavailable until someone has documented it, either in redline form or in a new document.

Deferring any thought about change impact until the Impact Analysis state is problematic, since anyone looking at or working on the MOC can benefit from some knowledge of the potential impacts, right up front. This appears like a circular argument where it’s desirable to know the impacts during Initiation, yet the MOC has to be initiated in order to put into motion the process that will cause the impacts to be analyzed.

The solution to this dilemma is to recognize that information often exists at several levels of detail. For instance, it’s common to provide a rough-order-of-magnitude, “ROM”, cost at the start of a project, say, $10,000 ± 100%. Later, as the project details become more refined, costs are stated with greater accuracy, say, $12,500±20%.

The same logic can be used to characterize MOC impacts during Initiation. A preliminary assessment can be made of process safety, environmental, and other impacts, during the Initiation state. It’s understood that a more refined analysis will occur later on. The preliminary assessment of impacts can be termed “Change Impact Pre-Screening”. One presentation of this is shown in Table 8. MOC change impact pre-screening attributes.Table 8.

This notion of progressively more refined assessment is also promoted in Guidelines for Risk-Based Process Safety [8]: “[Hazard Identification and Risk Analysis] HIRA reviews may be performed at any state in a project’s life cycle.. In general, the earlier that a hazard is identified, the more cost-effectively it can be eliminated or managed”. Early hazard identification, which might be termed “pre-screening”, is less detailed, less costly, but also less certain. Highly detailed risk analysis, which might be termed “impact analysis” is more detailed and costly, but also much more certain.

Table 8. MOC change impact pre-screening attributes.

From a best practice perspective, it’s critical that change impact pre-screening differ dramatically from detailed impact analysis. Otherwise, pre-screening (which is supposed to be a 1 minute operation) will morph into its own business process and slow down the entire MOC initiation process. Screening questions should be designed so that all the screening questions should normally be answerable by one person, typically the initiator.

Table 9. Impact pre-screening vs. analysis.

Pre-screening Process Safety Risks

Pre-screening is often used to determine the following:

• what kind of impact analyses will be performed during the Impact Analysis state: HAZOP, what-if, etc.?
• does the change involve a topic where the company has received a prior citation? The intent is to identify these cases early in order to avoid a “willful negligence” citation.

Pre-screening Environmental Risks

Pre-screening is often used to identify the following:

• does the change have the potential to create a situation which will cause permit limits to be exceeded? If so, then the Environmental group will demand immediate input on the change proposal.

Pre-screening Costs

Pre-screening is often used to determine the following:

• if this is a discretionary change, does the change cause a budget limit to be exceeded? The person, paying for the change, may not actually have sufficient funds to allow it to proceed.

The cost attribute captures this information. But costs are not well known this early in the change process, so it’s necessary to indicate the cost accuracy, e.g. ± 100%.

Most of the pre-screening attributes, but particularly costs, can be interpreted in multiple ways. Does the cost attribute represent just the material costs? material plus labor? or, some other variation? Some guidance on the form would be helpful, otherwise this data will not be provided in a consistent manner.

Comments

Additional information, that the initiator believes is important and/or relevant, can be put into the comments section, see Table 10.

Table 10. MOC comments.

This is “a” mechanism for capturing commentary during a change. The benefit of comments is that this typically appears on the front page of an MOC.

In electronic implementations, comments are also possible and desirable. However, other techniques, like Wikis, threaded discussions, “team sites”, and so on, may provide the same benefits as a comments field.

Figure 2. Sample completed MOC initiation form.

Summary

This newsletter has presented a representative list of attributes for a Management of Change instance. A sample of a completed change initiation form appears in .

References

1. OSHA, 1992, “Process safety management of highly hazardous chemicals,” 29CFR1910.119, OSHA, Washington.
2. Hoff, R., 2010, “Covered Processes,” MOC Best Practices, 4(1).
3. Hoff, R., 2010, “What’s a change?,” MOC Best Practices, 4(2).
4. Hoff, R., 2009, “Replacement in Kind,” MOC Best Practices, 3(4).
5. Garwood, D., 2004, Bills of Material for a Lean Enterprise, Dogwood Publishing Company, Inc., Marietta, GA.
6. Hoff, R., 2009, “MOCs, Capital Projects, Turnarounds,” MOC Best Practices, 3(2).
7. Hoff, R., 2007, “Lifecycles,” MOC Best Practices, 1(2).
8. American Institute of Chemical Engineers. Center for Chemical Process Safety., 2007, Guidelines for risk based process safety, Wiley-Interscience, Hoboken,N.J.

Standard Disclaimer

It is sincerely hoped that the information presented in this document will lead to an even more impressive safety record for the entire industry; however, Gateway Consulting Group, Inc., its employees, consultants, the document’s authors disclaim making or giving any warranties or representations, express or implied, including with respect to fitness, intended purpose, use or merchantability and/or correctness or accuracy of the content of the information presented in this document. As between (1) Gateway Consulting Group, Inc., its employees, consultants, the document’s authors and (2) the user of this document, the user accepts any legal liability or responsibility whatsoever for the consequence of its use or misuse.