introduction
Agile project management approaches, including flavours such as Scrum and Extreme Programming, have taken the software development world by storm. Proponents praise the flexibility and speed of the method which has gathered ardent followers across the globe. Furthermore, penetration into other industries, such as construction, has begun.
As the exploration and production (E&P) industry cautiously emerges from the recent downturn, facing the new reality of low commodity pricing and rising threats from alternative energy sources, it is imperative that innovative means to continue efficiency and competitiveness improvement are sought. Could Agile methodologies also bring value to E&P, specifically to the project development process?
what is agile?
Agile was created to address the failings of traditional project management approaches for the delivery of software. It has become de rigueur within the software industry, with success heralded widely and enthusiastically. Agile has become a metaphor for cool, young, flexible, adaptive and disruptive.
The Agile approach is characterised by succinct iterative cycles called sprints that execute agreed packages of prioritised scope, over a short timeframe. These short sprints ease the rapid incorporation of change and allow the early creation of a minimum viable product, which is built upon in subsequent sprints. At the end of each sprint, a retrospective review of the team’s performance is carried out to capture and implement learning. The cone of uncertainty [1] / fuzzy front-end [2], present in all innovative endeavours, is managed by the Agile methodology by fixing time and cost via the sprints, to control requirements.
A manifesto was created by a group of Agile pioneers that encapsulates the desired project management mindset and values for a successful Agile approach.
the agile manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools;
Working software over comprehensive documentation;
Customer collaboration over contract negotiation;
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left. [Ref.1]
application to E&P
The prevailing project development process in E&P is Front-End Loading (FEL), managed by a stage gate process. FEL deals with the cone of uncertainty / fuzzy front-end by seeking to fix requirements up-front and hence control the project time and cost. E&P is probably the most capital-intensive industry in the world; with underlying uncertainties commonly large enough to torpedo economic viability, therefore most would rightly argue that a clear plan, and adherence to it, are essential for success.
The initial impression is that FEL and Agile are ideologically opposed. FEL favours the right-hand side of the Agile manifesto introduced above. For example, the following aspects are not atypical within E&P project development processes.
Processes and tools are used to achieve collaboration between disciplines, with value improvement processes often mandated at various project phases. Due to the relatively long durations of conventional E&P projects personnel turnover, is almost inevitable, combined with the substantial necessary growth in project team size from project; development through to execution: tools and processes are applied to ensure continuity.
For similar reasons, documentation is obligatory to capture the decision audit trail and to scope and plan the next project phase, sometimes establishing (inflexible) checklists of deliverables at each stage gate;
Increasingly large and prescriptive work scopes, with fixed price contracts designed to transfer implementation risk to consultants and contractors, often create a potentially confrontational master-slave arrangement, obstructing collaboration;
Emphasis on preparation and planning for project execution to fix project requirements and manage uncertainty before commitment of major expenditure. Once the plan and monies have been committed, change is both difficult and costly.
So, is the answer clear, Agile project management approaches have little to bring to E&P? Or is there a golden mean[3] to be found? Perhaps a union between the rigour of FEL with the flexibility of Agile to accelerate the early phase project development (FEL 0/1/2) is possible. A less structured approach during FEL 0/1/2 is of minimal financial risk; costs incurred at these stages are dwarfed by subsequent project execution expenses; and the benefit of accelerated project delivery is self-evident.
In the spirit of W. Edwards Deming[4], we must know what to do, before doing our best: perhaps a manifesto for the hybrid Agile-FEL project management approach might look something like this:
manifesto for Agile-FEL
integrated teams
Build small multi-discipline teams that cover all aspects (technical, commercial and strategic), are truly collaborative and thereby can rapidly iterate and progress. This Agile mentality in the FEL 0/1/2 area may be exactly what is required to pick and through the fuzziness and land on the best path forward.
model early and model smart
Support analysis and decision making with robust models that, to paraphrase Einstein, are as simple as possible, but not simpler. Complexity is added only when it is necessary. Such models provide early insight, helping a project understand what is important, concentrate effort and avoid waste, ultimately enhancing the quality and minimising the quantity of the FEL activities. Smart models are by their very nature adaptable to change and retain usefulness through FEL 3 by serving as a check that the evolving project plan will deliver the promised business value.
decision maker collaboration
Frequent (i.e. not just at the stage gates) and effective decision maker engagement is required. After all, the decision makers are also the client from a business perspective. Admittedly, this is already a key aspect of successful applications of FEL. However, the adoption of the Agile approach, where collaboration with the client (commonly called the Decision Review Board) is advocated, suggests a level of trust and intimacy unusual in the E&P world. A true collaborative relationship will allow a more complete understanding of mutually agreed requirements; a forum to share findings, insights and explore decision trade-offs as they arise; and, once sufficient mutual trust has been gained, a vehicle to air and resolve candid project performance feedback from all parties.
sprint when you can
In the early project phases (FEL 0/1 and to some extent FEL 2), given the fuzzy nature of the work, organising by sprints (rather than defining large packages) would help maintain project pace and provide flexibility to respond to the inevitable change. Sprints would force regular discussion about requirements and assist in maintaining cost and schedule discipline; the customer only commits to a few sprints at a time.
conclusion
The E&P industry is a conservative beast; the FEL project approach was first adopted by a few in the ‘90s and has yet to be wholly adopted throughout. This is somewhat surprising given the wealth of data captured, analysed and disseminated by the likes of the IPA that support FEL’s virtues. Consequently, it is hard to imagine a sudden, wholesale rush to become Agile as there is much inertia to overcome, despite the possible benefits in the early project phases.
At io, though we firmly believe in the merits and applicability of FEL (especially when combined with a Decision Quality framework), we also recognise there is always opportunity to be had in learning and adapting from other industries. Bringing the appropriate facets of the Agile approach into the early project development phases might just disrupt and unlock new opportunities, helping to make our industry more competitive in a dynamic world. Accordingly, we strive to be Agile in the way we engage with our clients and execute work: such as starting with the end in mind; using integrated multi-discipline teams; applying Decision Quality to guide and judge our work; and incorporating systems thinking to better model assets/projects. We are even considering having the odd scrum.
To find out how io can bring agility to your opportunities, contact us at hello@ioconsulting.com.
[Ref.1] The Agile Manifesto is the statement of principles that support agile software development, agile methodologies and agile project management. Written by Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie van Bennekum,
Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunningham, Jon Kern, Dave Thomas, Martin Fowler, Brian Marick (2001) http://agilemanifesto.org/.
[1] The cone of uncertainty refers to the fact that estimates (e.g. on duration, costs or quality) are inherently very vague at the beginning of a project which necessitates that estimates and project plans are recreated on a regular basis. Assumptions that later prove to be mistakes are major factors in uncertainty.
[2] The fuzzy front-end is a concept used in the product development world. Fuzzy summarises the indistinct, uncertain and vague nature of the innovation process that is non-sequential and iterative.
[3] An ideal moderate position between extremes.
[4] “It is not enough to do your best, you must know what to do, and then do your best.” – W. Edwards Deming.