Agile For Oil and Gas - mixing lifecycle models

Introduction

This post is about Implementing agile at the organizational level across multiple technical domains. I was in Bogotá, Colombia recently working with an oil and gas company to introduce agile to their organization. They were not looking to improve their IT delivery, they were seeing if it could bring benefits to their whole business value stream. Since moving to Calgary 13 years ago I have worked with many oil and gas companies, they are the major employers here and the predominant industry. Lots of energy companies employ lean approaches to exploration, facilities creation and operations to maximize efficiencies and optimize the value stream.

Applying agile techniques to lean processes are a natural compliment and fit especially well with the unique problem solving and collaboration needed to undertake complex projects. Yet, oil and gas projects present a mixture of both these knowledge worker challenges that are a great fit for agile, and industrial engineering that requires traditional approaches. The real benefits come in knowing how to mesh these approaches together and provide some mental models to facilitate planning and problem solving. This is still an emerging field and I don’t think we have all the answers yet, which makes it challenging and rewarding. At the end of the post I outline some questions that I am trying to solve.

The Bigger Picture

Oil and gas development is a long value chain engaging many different groups with unique specializations. Like designing a new car, bringing it to market, producing it, selling and then sustaining it, the skills needed along the way are diverse and often conflicting. Oil and gas development includes the following disciplines:

• Surveys – identifying areas with favourable geological conditions.
• Surface Rights Negotiation – arranging for land access with land owners, environmental surveys, native and community outreach.
• Exploratory Drilling – verifying the presence or absence of hydrocarbon reserves and quantifying the reserve.
• Facilities – creating the infrastructure for oil or gas extraction, initial processing and transportation to market.
• Operations – managing the safe extraction and operation of the well and associated facilities. Performing maintenance and projecting production declines and decommissioning work.

 Mixed Project Types

Some of these activities like the collaborative work of the G & G groups (Geologists and Geophysicists) are classic knowledge worker activities. Here specialists with subject matter expertise come together to share information and as a group and build consensus on the most likely areas for further exploration. No two regions are the same, no two geological formations are the same, and just like software teams use agile methods to collaborate on solving complex problems and gain consensus on the direction to move in, so too do G&G teams.

Further down the chain though, some pieces of work can be more traditional in nature. After determining an area to explore, the execution of a seismic survey might involve mobilizing a large workforce of several hundred people and scheduling constrained equipment. While this can be done in an iterative, prioritized manner, many of the benefits of short iterations, reviews and adaptation are diminished so a hybrid approach is preferable.

Agile Processes

Surface rights negotiation and exploratory drilling are very much expert driven, collaborative problem solving exercises. Starting the process with incomplete information and uncertainties is the norm. There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty. Activities progress with the acknowledgement of ambiguity and proceed through stages of:

1) Embrace ambiguity – getting stakeholder agreement of areas of uncertainty

• List areas of uncertainty
• Discuss and agree known scope boundaries

2) Sense making – collaboratively forming consensus on exploratory work to undertake

• Agree information gathering steps
• Prioritize sense-making exploratory work

3) Iterate through cycles of Plan, Explore, Learn, Adapt – Learn by doing rather than speculate via planning

• Plan – agree and assemble work plans, guidelines, objectives
• Explore – undertake short period of exploratory work
• Learn – collaboratively analyze findings and gather results
• Adapt – retune upcoming work plans, incorporate learnings

4) Maximize value – once it is agreed that the “Next Best Dollar Spent” is elsewhere on the project AND the iterative learnings have been maximized, finish the experiments

• Gain consensus that the exit criteria has been reached
• Articulate findings, learnings and decisions

Traditional Processes

In the oil and gas development process, the next stages of the process after exploratory drilling involve more traditional engineering work. The process of creating facility infrastructure varies from site to site, it starts with the problem solving design work that benefit from agile communications and decision making. Then comes  the activities of site preparation, fabrication and commissioning which are more defined / repeatable processes who’s execution is predominantly linear.

 

So, the challenge then is to combine the iterative, problem solving knowledge-work with the linear, predictive industrial-work in a way that stakeholders can understand and embrace. We need a holistic model, suitable for complex lifecycles that has consistent communications, but flexibility for specialization.

Mixed Models

In the lifecycle of a single well there will be a combination of project lifecycles used, as depicted below:

 

A large oil and gas company might drill 50 or more new wells a year so the model is replicated many times over.

Implicit and Explicit Processes as a Clue to Integration

If we examine the work conducted in any kind of project we can see it is comprised of:

1. Planning – preparation, estimation, sequencing
2. Doing – undertaking work, building value
3. Communicating – clarifying, confirming, reporting, co-ordinating
4. Problem solving – diagnosing, gathering data, deciding what to do

Traditional project management has explicit, high visibility processes for type 1 (Planning) and 2 (Doing) work and implicit, secondary visibility processes for type 3 (Communicating) and 4 (Problem Solving) work. These activities still happen, but are subservient to planning and doing the project work since the need to constantly communicate and solve problems should be small if the project is planned correctly. “Plan the work, work the plan, and tell me if anything goes wrong…” is the general philosophy.

 

Agile project management however, pays equal attention to communicating and problem solving as it does to planning and execution. There is upfront acknowledgment that requirements are not knowable in advance and that build feedback cycles will be necessary to surface true requirements.

To counteract this uncertainty, communicating and problem solving are as explicit in the process lifecycle as planning and executing. Demonstrations, retrospectives, reprioritization and daily stand-up meetings are core components of the lifecycle aimed at improving communications and problem solving.

 

 

A Model for Mixed Approaches Integration

Many companies today want to get the agile benefits of shorter development cycles by making early progress on what is known and then discovering the remaining work through experimentation. However, they face the project  challenges of having multiple execution models that frustrate widespread agile adoption.

A stepping stone to integration is to encourage traditional projects to be chopped into multiple short projects and adding an interim “Confirm” step.

 

 

The new Confirm step is an interim review of work done, an inter-project look back at what is working, and an opportunity to make recommended changes for the next portion of development. It is not unduly disruptive to project execution and explicitly introduces more Communicating and Problem Solving work.

The final Close processes still happen as normal after the final phase. So now the entire project lifecycle becomes multiple Initiate/Plan/Execute phases with a Confirm step and then a final Close step at the end of the project.

 

 

Agile projects can similarly be made more traditional project friendly by calculating a Schedule Performance Index (SPI) based on Completed Features / Planned features at this point in time.

This SPI metric is compatible with traditional project execution tracking and is a useful linking co-ordination metric for tracking mixed project type delivery.

Summary

Getting divergent groups to adopt a consistent methodology is difficult and potentially sub-optimal. Groups need the freedom to operate using their industry’s best practices and also have a say in work scheduling. Forcing a group to adopt a new approach whether it is agile or traditional is a sure fire way to generate resistance and obstacles.

However, asking for a segmentation of work and introduction of a Confirm step is a low disruption stepping stone towards agile adoption or integration if there is interest. The checkpoints provide useful insights into long lead-time endeavours and allow lessons learned to be incorporated while still actionable. If there is interest to proceed further, the segments of work can be made short and additional confirmation/feedback mechanisms introduced such as daily stand-up meetings and backlog prioritization. Likewise agile projects can translate their progress into more traditional tracking metrics like SPI, CPI and EAC earned value metrics which helps make an apples-to-apples comparison of progress and spend metrics.

Modern projects are complex endeavours involving multiple disciplines. While executives always want to go faster, we need to balance the mindsets and risks of “Look before you leap” and “cross that bridge when you come to it”. Engagement models that honour both approaches, but also provide integration points can help organizations effectively mesh these approaches together.

As I mentioned in the introduction, there are still many questions about how to best blend traditional and agile models within a diverse organization. Some things that still puzzle me and I would love to hear people’s thoughts on are:

1) The question if work has to be sequential or can use agile iterations seems to vary based on who you ask. Some drillers talk about changing the final down-hole location mid drilling based on reviewing core-sample data. Others talk about needing a complete plan before ordering materials and starting work. So is it work type dependant or mindset dependant? – I suspect the latter, but might be biased.

2) Frameworks like DAD and SAFe are useful for visualizing the management of portfolios and programs of projects, but they lack the drill down detail needed to guide teams in their day to day work. Should we try to create generic models to use consistently across organizations, or is a method per company, tailored to the processes and activities of that organization more likely to be successful

3) Is the executive goal of a single approach that allows for agile or traditional project execution in a consistent framework that promotes rapid delivery naive or simplistic? When we get to execution are some project domains so unique that they will suffer if forced to use a standard lifecycle - even if that lifecycle has been found to be productive in other fields? If so should we be focussing our efforts on executive education not organizational transformation?

 

Comments

[MargoWin]

Mike, very impressive and well explained article about specifics on how the Oil & Gas Industry can exploit Agile development and project management to increase efficiencies. Liked it so much, I reblogged it on my blog - Agilework.wordpress.com.

[Kevin Lonergan]

great article - years ago I worked in Oil & Gas development projects and these days I am total supporter of Agile methods for all sorts of projects.

My one key question is this: the biggest challenge I see in many businesses and cultures is for people to be able to focus on and even have the skills to identify the uncertainties (even though they will always be there) - how did you go about this?

[Mike Griffiths]

Hi Kevin,

Thanks for the feedback. I find the demonstration of partial solutions and discussion about next steps naturally identifies and explores uncertainties. We agree on the knows and pursue viable options for the unknowns. It falls out from the process and doing so in a group setting helps build consensus for the emergent solution.