• Login
• Contact Us
• SPE.org

Building Blocks for Change Management

Whatever a project’s scope, most managers agree that “the devil is in the details.” Yet few take any positive action toward taking control of or changing that dynamic; instead, many managers avoid details in general. Taking the entire issue a step backward, some even suggest that detail-oriented management is not necessarily a good idea in the first place. But detail-oriented management impacts oilfield companies and includes a proven and scalable set of methods.

As with the business world at large, E&P companies require a defined set of outcomes, and to achieve desired outcomes consistently, a defined set of processes is required. That translates into a lot of details, but that is critical to achieving what every oil company should want: repeatable processes, consistent results, lowest unit cost of oil and gas, and the opportunity for continuous improvement.

If those positive gains sound appealing, why isn’t everyone aligned with this concept? The reasons are endless, including the lament that working out the details takes too long, is too difficult, and/or costs too much. Additionally, management is not charging ahead to leverage these proven approaches for a very basic reason: Dealing with change is difficult, and all kinds of individual and corporate inertia must be overcome. But the good news for management everywhere is that using simple building blocks can cut the challenge down to size. That is because only four layers are involved, with each layer building on the other. Plus, it is scalable to meet each company’s requirements.

However, management must see that change is necessary, top-down support must exist, a disciplined systematic cross-functional approach must be taken, and skilled resources must be in place to implement the new methodology. But how does management find and capture the benefits of taking a new approach? It involves leadership, communication, methodology, and skills, and it has four layers: context, node tree, money, and data.

Using definable layers allows a drill-down approach to success. In other words, the business value or need is the detail driver, and each layer is directly tied to the next, so it is all interrelated. First, the context layer both helps to identify the process boundary and provides a quick read on the process condition. In this layer, three types of knowledge are important toward moving ahead: the group agrees on scope, understands relationships and interdependencies, and reaches a consensus on details necessary to improve the complex problem.

Although information may be collected one-on-one, experience shows that the best approach is group discussion, for a couple of reasons. One, it provides a more robust view; and two, it lets group members get actively involved in analysis. Side benefits include a deeper and quicker analysis and buy-in. But each problem and each group is unique and must be assessed and addressed in terms of each respective case. Essentially, the context layer is a checkpoint or gate providing early warning of potential problems. For instance, if a solid consensus cannot be reached on the context model, the group should not go forward with analysis; that would be counterproductive.

The Node Tree

The second layer, node tree, is simply the connection of several context models into a more complex structure, or node tree, but only after a consensus. Note the recurrence of the word consensus. As with a zoom-out view, this lets group members comprehend more visually and broadly the scope of process activities, relationships, and dependencies so that everyone can reach a common understanding.

While node trees can be as complex as desired, simplicity is the best bet. That is because advancing too quickly into a web of details can jeopardize the venture instead of taking it to the next stage. The more complex node tree results from a context model (Fig. 1).

                     Fig. 1—The four different levels.

Here is how it works. First, list the processes in a simple Plan, Do, Check, and Improve order, organizing them to look like an organizational chart. But take note that both risks and benefits are involved, with the key risk being that the process model is not technically how the model should be developed and represented, precisely because it is not an organizational chart.

For practical purposes, that is not a real problem, given that most people think organizationally anyway. In fact, it is good if the group realizes this difference and becomes aware of potential “disconnects” in how things are managed and directed. Also, avoid showing real dynamics or recycles in the process-structure model, while continuing to gain an understanding of overall process structure and relationships; just show a series of process steps intended to yield a specific result. It is the equivalent of using slow motion to see an event’s details.

The Money Layer

Workflow is the third level or layer, otherwise known as the money layer. Preceding this level, process-model development has been helpful in four ways: identifying process boundaries, listing key issues, getting consensus within large groups, and prioritizing areas needing more drilling down. This knowledge translates into significant business value and cost savings. But, the detail level necessary to calculate activity-based costs and quantify additional potential major savings is associated with operational processes.

Yet that is not surprising, because drilldown involves expending energy and efforts. By design, the reward is proportional to the investment. But using a simple node structure indicates where to drill down, and that knowledge is a dual advantage. It both helps to expedite benefits of detailed analysis and greatly lowers the risk of looking in the wrong place.

Workflow-model templates, such as the simple Excel-based one, can capture detailed process information including dimensions and measures needed to characterize process accurately. Examples of information capture are steps, participants, comments, business rules, and nature of steps.

Significantly, the information should not be collected in a vacuum but through groups including subject matter experts and process operators. Each should be asked to provide information and estimates of cycle and work time required, as well as information about interaction with information technology (IT) systems.

This information capture helps provide a balanced perspective of the detailed process and how IT systems interact within the overall process. In turn, the improvement team synthesizes input into a model and validates results with the interview group. In estimating activity costs, total costs are calculated by simply multiplying unit costs times the number of transactions.

Information Flow

Data is the last of four levels or layers. Information flow is the lifeblood of any process and that is precisely where IT plays a key role, as most complex operations use computer-based software to help capture, calculate, and store information. Although relationships can be quite complex, it is best to select the simplest possible path.

Therefore, the process step to data-element relationship is described through a simple Create, Read, Update, and Destroy approach. Specifically, that process describes steps that create new data elements, read/access data elements in the process, update an existing data element with new values or information, and destroy unneeded data elements.

What does this simple building-block approach add up to? Basically, it lets an E&P company’s improvement design team systematically analyze the current process, identify good opportunity areas for optimizing use of people, align IT systems, and improve cycle time and activity-based costs for current processes. As a result, some have wondered if these same building blocks can be used to implement process changes. And the answer is “yes.”

It is also noteworthy that the “as is” models allow the team to test concepts and see potential implications to determine value/issues associated with actually making the changes. That subsequently helps secure understanding and buy-in from all impacted parties, a fundamental requirement for successful implementation of change. It just makes sense that implementing changes without a good understanding and honest buy-in usually points to impending failure and/or confusion. In contrast, using this model to simulate the impact of change produces both buy-in and active participation.

Ultimately, multiple benefits result. Upon design completion, the implementation team can develop a systematic approach for making the transition from the “as is” to the “to be” state. Toward that end, the process model helps the team and members visualize both states and to develop plans to move to the new design. This includes evolving the design model into a training/communication tool.

• Archives
• SPE.org
• Advertising
• Contact Us