Does Project Complexity Matter?

Howard Duhon recently posed a question in the SPE Connect Projects and Facilities Forum titled “Are our project overly complex? Can we define complexity?”. The question is relevant and I thought it worth examining more closely and sharing my own views on the matter.

In the E&P industry, it would be reasonable to draw the conclusion that our projects are indeed becoming increasingly complex. The frequency of megaprojects has increased to the extent that they are almost the norm, not the exception. If we choose to do so, then defining complexity is not hard; indeed this has been the subject of many academic and industry research efforts. However defining complexity alone does not answer the question, even if it does show that the E&P industry has some of the most complex projects in the world.

The truth of the matter is that the complexity of most projects is a given that arises from the very nature of their context, objectives and scope. This is the fundamental foundation of project complexity, and to that we can certainly be guilty of adding other layers of complexity through our management approach to the project. But without altering the context, objectives and scope it is impossible to reduce the underlying complexity.

So to some extent complexity is a red herring. There is not much we can do to reduce it, but we are able to understand it and we have the capability to plan to manage it appropriately. If we are able to anticipate the complexity inherent in a project, then it should not influence the outcomes as we have eliminated ability of a project’s complexity to upset the project. On the other hand, if we fail to recognise the true nature of a project’s complexity, then we have opened the door to a myriad of problems; under these circumstances it will almost certainly appear that complexity matters!

Does Complexity Matter?

Independent Project Analysis (IPA) has more than two decades of project knowledge on which to base its research. Whilst much of IPA’s research and work is unpublished, the main findings were published in 2011 in the book Industrial Megaprojects: Concepts, Strategies, and Practices for Success by Ed Merrow, the President and founder of IPA. Whilst the book is focused on the results of megaprojects in several industrial sectors, it is fair to say that the principles outlined in the book are relevant to almost all E&P projects, irrespective of size.

Anyone familiar with IPA, and hopefully most readers of Ed’s book, will be familiar with the concept of FEL, or front-end loading. This is the process by which a project is defined prior to execution (detailed design, construction and start-up), and includes all phases of a project leading up to and including front end engineering and design (FEED) and all associated project execution planning (PEP) aspects. I always think of FEL in terms of the phrase, “fail to plan, plan to fail” as that essentially sums it up. The more effort you put in to the project up front, the more likely you are to deliver a successful project. The crucial part of this is that it is not mere opinion, or good ideas. This relationship has been proven with actual project data and results.

A surprising consequence is that whereas FEL has been found to correlate very strongly with project outcomes, to the best of my knowledge no such relationship has been found whereby project outcomes are determined solely by complexity. This might initially seem counter-intuitive, but it’s simply recognising that it is possible to deliver successful complex projects, and on the other hand to turn simple projects into disasters. It is our level of planning and definition that determines the fate of a project, not its level of complexity.

This is good news. It means that we need not despair simply because we are faced with a challenging project. What it does mean is that we ought to be concerned about how we plan our projects.

One aspect of complexity that is hard to hide from is that the amount of effort involved in planning increases as a project increases in complexity. This means that it becomes harder to achieve the level of definition necessary to deliver a successful project. Furthermore the price of failure also increases. This is illustrated in Figure 1, taken from Oil and Gas Industry Megaprojects: Our Recent Track Record, a downloadable paper which summarises several of the key points raised in Ed’s megaprojects book. The x-axis shown is Asset FEL which is a measure of project definition. Projects in the Best or Good category are those with superior project definition. The y-axis shown is cost growth for the project between the original estimate at sanction versus the actual cost spent, adjusted for escalation over the project execution phase. The relationships illustrate that if FEL is improved, then a project has a lower level of cost growth.

E&P megaprojects tend to have worse outcomes, on average, compared to non-E&P megaprojects, even after controlling for FEL. This seems to suggest that complexity does play some role in project outcomes, since E&P projects generally tend to be more complex than non-E&P projects. We should therefore be concerned about complexity because if we get the project wrong, the more complex the project is, the worse the end result might be.

Achieving an appropriate level of FEL is also made harder by a project’s complexity. This does not imply any correlation between more complex projects and poorer FEL, but the investment of cost, time and resources required to achieve a Best level of FEL is much greater for a complex project than a simple one. What specifically are the aspects of complexity that we can address through our project definition efforts, and which aspects are beyond our control?

Defining Complexity

I am not aware of any scale that quantifies the overall absolute complexity of a project through a systematic methodology. By this I mean that if we had a perfect scale, then a project with a complexity rating of X would require a certain effort, say investment in terms of cost, time and resources, to execute successfully, and a project with a complexity rating of 2X would require twice as much effort. On the surface such a specific scale probably does have much additional utility over a simple comparison using cost. A $1 billion project should be more complex than a $100 million project. But this assumes we know what the true cost of the project really is. Given the cost growth on projects can easily exceed 50 percent, we might delude ourselves into underestimating a project’s complexity just by looking at the cost in isolation.

There are many approaches that have been used to measure the relative complexity of different projects through assessment of several different elements. One such approach was suggested by Jacques de Salis in a response to Howard’s original question, and is described by the business school IMD in a paper Managing complexity in global organizations. The categorisation of complexity into different sources is one that can logically be applied to understanding complexity in projects.

Complexity results from system behaviour that can be grouped into four different categories. These are Diversity, Interdependence, Ambiguity and Flux which we define as the “source of complexity”:

• Diversity: The presence of a side variety of issues and challenges that must be addressed will lead to complexity. Managing a single task is (usually) simpler than managing hundreds.
• Interdependence: Always be wary of the rule of unintended consequences. Where fixes to one aspect of the project only leads to further problems developing elsewhere. Project systems are built up from a network of interdependent elements. The more networked the project system is, the more complex its behaviour.
• Ambiguity: Correct and timely information is needed to support appropriate decision making. Where that information is vague or missing, assumptions must be made. It is often easier to make an assumption than it is to deal with reality, which has an annoying tendency to get in the way of our projects. The irony is that whilst assumptions might make a project appear simple, they are actually adding to the complexity. This is because our assumptions are tainted by human bias and optimism.
• Flux: If a system is changing, then this adds to complexity. It is easier to manage a single fixed task than one where there are a myriad of potential paths.

Elements Of Complexity

These four sources of complexity can arise for a variety of different reasons. I attempt to describe six different areas from which project complexity can arise. I have designated these elements as forming the “basis of complexity”.

At the heart of any capital project are a set of objectives that the project is designed to satisfy. The project will be executed in a known environment, with physical and human-imposed constraints. The combination of the project’s context and objectives will drive the choice of scope that is selected to deliver the project. This trio of context, objectives and scope define the foundation of a project’s complexity. It is hard to reduce the inherent complexity that arises from these three factors without fundamentally changing the context, objectives or scope; in effect pursuing a different project altogether.

• Context: This is the project’s setting. It encompasses the physical and human environment e.g. the landscape, environmental conditions, regulatory and political requirements, local landowners etc. Essentially anyone and anything that will be effected by the project.
• Objectives: What is the project aiming to achieve? Any project should seek to satisfy a tangible goal, for a given budget and schedule.
• Scope: In order to satisfy the objectives, a project will need to implement a set of actions. For an E&P project this typically involves the drilling of wells and construction of surface facilities.

Layered on top of the foundation complexity for a project are three additional areas that arise from our management approach to the project. It is these areas over which a project team has degree of control to manage the amount of additional complexity that is added to the project.

• Organisation: Scope for E&P projects takes time to plan, design and construct. Managing these activities is the job of the project team and the organisation within which that team sits.
• Technology: The expression “there is more than one way to skin a cat” is very applicable to E&P projects. Choices abound between fit-for-purpose versus gold-plated, new technology versus off-the-shelf, standardised versus bespoke.
• Execution Planning: Preparing for the project execution phase might seem tedious, but it will hopefully smooth the way for the project. Planning is the one area in which any project team has arguably the most influence and control over a project’s destiny.

Managing Complexity

By cross-referencing the basis of complexity against the sources of complexity, we can start to identify different types of complexity that arise. I have shown this graphically in Figure 2, where each type of complexity has been coded to reflect the significance of that complexity type with respect to successful capital project delivery. The shading is a subjective measure, based on my experience at IPA, of where E&P projects frequently encounter problems. All complexity types can generate problems for projects, but there are differences as to whether a complexity type is readily recognised and how severe the consequences of the complexity can be.

It can be seen that there are three complexity black spots. These are Objectives-Interdependence, Execution Planning-Interdependence and Execution Planning-Ambiguity.

The Three Complexity Black Spots

In my view the complexity that arises from these three elements is the main reason that projects run into problems and should be the first areas that must be addressed in any attempt to reduce or manage project complexity.

1. Projects are a cost, schedule and quality trilemma. Choose any two (as long as one of the choices isn’t schedule). (Objectives-Interdependence) Ask many projects what their most important priority is between cost, schedule and quality (delivering reserves and production), and one of the most frequent answers is, “all of them”. Well, yes, they are all important, but if you don’t have any idea what the order of priority is, then the chances are that is because you have no firm idea what the project is really trying to achieve. Personally I believe that there are only two sensible choices for this trilemma: a project that is cheap and good, but not fast, or one that is fast and good, but not cheap. However many projects emphasis schedule and then cost, meaning that their choice is a project that is fast and cheap, but not good. Aggressive schedule is an effective way to destroy value as chasing schedule tends to lead to unintended consequences.
2. Owner schedules are often inadequately developed to fully appreciate the hidden interdependence between activities. (Execution Planning-Interdependence) Use of resource-loaded schedule often reveals true relationship between activities in a schedule, but very few E&P projects bother to create one. After all, the common ‘wisdom’ is that this is the responsibility of the contractor. I remember a discussion with a project manager who initially held this view, but I managed to convince him that this was not Best Practice. When I next spoke, the project had implemented a resource-loaded schedule, and as a result had recognised that their previous construction sequence was flawed because the engineering resource constraints meant that there was no way all the engineering could be completed on time. Our industry needs more project managers who are willing to go the extra mile with schedule development.
3. Recognising risks but then failing to plan for them is stupid. (Execution Planning-Ambiguity) Planning is more than just putting together a pretty schedule. Understanding the risks that face a project, and mitigating those risks, is a sensible approach and one that must take place during the planning phase. Waiting until the risk manifests itself is a case of too little too late. Scenario planning is an effective tool to mitigate risks, and involves creation of a Plan B, Plan C etc. The trouble is that this is not always done. For many projects the risk register is created before project execution commences, and then is promptly forgotten. Which leads to the rather embarrassing situation whereby the project runs into the risks that it had recognised before it started, but then failed to plan around those risks and was caught out.

Other Complexity Problem Areas

Although no less important than the black spots, these areas have issues that time and again cause a project to become more complex than it really needs to be. This complexity is often a source of problems for the project. In all cases this is complexity that the project team can reduce; it is not beyond the team’s control.

1. “Hands off” approach which leaves decisions up to contractors is a bad idea. (Organisation-Ambiguity) Owner project teams seem to have this strange idea that their chosen contracting strategy is the silver bullet that will save the project. It isn’t. Almost any contracting strategy can succeed, and any contracting strategy can fail; some are just more likely to fall into one category or the other. A huge source of project complexity can arise from a misguided notion that the project can safely be handed over to the contractor who will then deliver according to the bid cost and schedule. Remember, it’s your project, not the contractor’s project, and both organisations will fundamentally hold different views on what the correct course of action will be for any given decision. Project teams that take a hands off approach usually end up having to take a hands on approach to fix the problems created.
2. Fit-for-purpose choice rather than new technology or adherence to multitude of different standards. (Technology-Diversity) It has become apparent to me that one of the reasons for rising costs in the E&P project world is that organisations are layering standards and specifications on top of each other. Whilst each requirement in isolation makes perfect sense, the combination of them can lead to emergent cost, where the total cost increment is greater than the sum of the individual cost increments. One project told me that the combination of all the specifications they had introduced led to a vendor complaining that they only way to meet all of them was to fabricate out of “unobtainium”.
3. Cannot just focus on the ‘sexy’ part of the scope. Must also pay attention to OSBL and ancillary scope. (Technology-Interdependence) The more expensive and technically challenging the main process is in an E&P project, the more likely it is that the utilities and infrastructure scope, or outside battery limits (OSBL) scope, will become the poor cousin. Forgotten and ignored right up until the moment of commissioning when it is realised that the plant needs some crucial utility to start up and that scope suddenly finds itself on the critical path.
4. Missing stakeholders or failure to understand context can be disastrous. (Context-Ambiguity) Whilst we can rarely change a project’s context, we can definitely fail to appreciate aspects of it. If we fall into this trap then we risk taking decisions that will later need to be undone, or worse accept a compromise to the project. This category is one where complexity can take on the form of a “butterfly flapping its wings in the Amazon”, with consequences that are far more significant than they might initially appear. A classic example here is an LNG plant that utilised air cooling but because the data on prevailing wind direction and ambient temperature was wrong, the design of the cooling panels was well below optimum efficiency. Unfortunately the cramped plot plan meant that it was not possible to redesign the layout when the error was realised.
5. Project context should be agreed before FEL 3. Ongoing negotiations are a recipe for disaster. (Context-Flux) Usually it’s not the physical context but the human context that can change and in doing so effect a project. In particular, if a project manages to run ahead of any negotiations and discussions that may be taking place, it can find out to its surprise that it has simply run ahead into a corner. It is very difficult to negotiate from a position of strength when the other party knows that you stand to lose a lot.
6. Care must be taken to avoid letting secondary objectives dominate e.g. ‘strategic’ projects. (Objectives-Diversity) Objectives should be straightforward, understandable and quantifiable. When they are not, then it is likely that complexity will rear its head. Often the word strategic is used to cover up the fact that a project makes no sense at all. Trying to reconcile the strategic objective with economic realities is like trying to fit a square peg into a round hole.
7. Open scope and incomplete engineering will drive late changes. (Scope-Flux) Late changes are widely recognised as a source of added complexity to manage during a project that can be problematic. What is less recognised is that those late changes arise because the project team failed to close its scope before starting execution. Often this is because the open scope appears to be innocuous. However it must be remembered that project systems are interdependent, and a small change can easily cascade into a major issue.

Well Managed Foundation Complexity Elements

Several aspects of the project foundation have aspects that could obviously lead to complexity if not managed appropriately. Generally these are areas that tend to be well managed as a result. For example project teams tend to be staffed by engineers, and thus the engineering aspects (scope) are typically better defined in comparison to the non-technical areas.

1. Many different aspects of project to consider. Can be very time consuming. Don’t rush! (Context-Diversity) This is an aspect that the project team has little influence over. By this I mean that the team cannot really change where the project is located, the regulatory and political environment, the fiscal terms etc. Care must be taken to ensure that all the contextual elements of a project are recognised and understood otherwise the project is exposed to complexity issue number 4.
2. Crucial to involve all stakeholders and understand different perspectives towards the project. (Context-Interdependence) Accommodating all the context elements that are recognised is required before a project can proceed. The more elements that must be accommodated, the more complex the project will be.
3. Clarity of objectives is one of the main drivers of successful project outcomes. (Objectives-Ambiguity) Where projects have understood the trade-offs inherent in their objectives, it is easier to express those objectives clearly. Projects with vague objectives like, “maximise NPV” will be inherently more complex because I could meet that objective by cutting cost, accelerating schedule (the joys of financial engineering) or producing more hydrocarbons. Which one to choose. Ironically for some projects in that situation, the optimal choice is probably to not do the project in the first place, because an NPV of zero is higher than a negative NPV. Of course, in suggesting this I admit I am failing to assign any value to the strategic elements of these projects.
4. Setting unrealistic objectives will lead to late changes. Must set realistic objectives up front. (Objectives-Flux) A guaranteed way to introduce changes to your project, is to start out with unrealistic objectives. Inevitably the charade will give way to reality, and when it does it will be accompanied by an ugly mess of complex changes that need to be made to the project, typically masquerading as ‘re-baselining’.
5. E&P Projects by their nature will have diverse scope involving reservoir, wells, facilities, commercial disciplines. (Scope-Diversity) The more elements of scope that need to be managed, the more skills, resources and contractors are required. The number of technical interfaces will also increase. In short the complexity increases with the amount of scope. This phenomenon is so obvious that for most projects there is an unwritten goal to simplify the scope.
6. Interdependence can be managed through effective team integration and limiting the number of scope elements. (Scope-Interdependence) For some aspects the nature of the interdependence is obvious. For example the well trajectories (wells discipline) are a function of the bottom-hole targets (reservoir discipline) and surface locations (facilities discipline). This means that different disciplines will need to work together. With larger projects more niche expertise can be required to solve some problems, and this increases the complexity.
7. Basic data and basis of design must be clear. This is a fundamental FEL aspect. (Scope-Ambiguity) This is also similar in some respects to complexity issue number 4, and can lead to complexity issue number 7. However the definition of scope is rarely imprecise. Whereas the reservoir engineering discipline tends to think probabilistically in terms of a range of outcomes, it is (allegedly) quite difficult to design and build a range of facilities. This means that a single deterministic realisation is what will be built. Some flexibility can be accomodated in the design, but the more flexibility that is required, the more complex the design is likely to be.

Well Managed Added Complexity Elements

Sometimes projects will add to their woes through creating additional complexity that was not inherent in the project to begin with. Fortunately these areas are not sources of complexity that occur frequently, but they can occur.

1. Delegation of decision making is needed to counter unwieldy organisations. (Organisation-Diversity) Some organisations are structured in a manner than it seems they actually want their projects to fail. For some organisations communication between disciplines is hindered by rigid organisational structures that force teams to inevitably find ways to circumvent their internal rules. In other organisations no-one seems to be in charge – oh wait, that’s not a problem because the contractor will take care of it (see complexity issue number 1). If the project team has to fight its own parent organisation or suffer because of it, clearly the project will be more complex.
2. Large number of interfaces to manage increases number of points at which problems can be introduced. (Organisation-Interdependence) The more things there are that need to be kept track of, the more chances there are that something will be missed.
3. Continuity, particularly amongst team leads, is important. Project manager turnover is associated with worse outcomes. (Organisation-Flux) Generally organisations don’t change often in the middle of a project. Very rarely a project is being pursued when there is a takeover or merger, or a contractor might be on the verge of going bankrupt during the project. More commonly the project manager and other leads will change before the project is completed. This adds disruption to any project. As one of my former colleagues used to eloquently explain, “whenever you get a new project manager coming into a project, it’s like a dog coming along and having a sniff – they all want to mark their territory and piss all over the project.”
4. Use of standardization, if done properly, reduces large amount of complexity. It’s been done before. (Technology-Ambiguity) Using off-the-shelf solutions, with no customisation, would help reduce complexity. Indeed it is an approach that has been used successfully by some companies. Yet it remains hard for many projects as they appear unable to resist the temptation to tinker.
5. Failure to prove new technology frequently reveals problems during execution. (Technology-Flux) Unproven technology is clearly more complicated than established technology. Indeed it is such an elephant in the room that it tends to attract a great deal of management attention. The problems come when the technology is new, but small in scale relative to the project. In such cases it can fly under the radar until it is perfectly placed to wreak havoc during hook-up and commissioning. Needless to say, fixing the problem at this stage in a project is very complex indeed.
6. Large projects clearly have more activities and scope elements to manage. Thus more planning is required. (Execution Planning-Diversity) This one is so obvious that management will usually take an appropriate response by assigning more resources to larger projects. Unfortunately the allocation of additional resources is not always accompanied by additional time, which can lead to complexity black spots numbers 2 and 3.
7. Late changes kill projects through a cascading domino effect. Effective project control is needed to limit changes. (Execution Planning-Flux) Changes introduce complexity. It would be hard to find a project manager who disagrees on that point. However the complexity that is introduced is not because the execution planning changes during execution, but rather because the execution plan was ill-conceived and inadequate to begin with. Occasionally however there are projects that plan effectively prior to sanction, but then somehow manage the clutch defeat from the jaws of victory. These are the projects for which their implementation of their plans was not carried out effectively. Both effective planning and effective execution are required for project success.

Dealing With Complexity

If you have managed to read this far, then congratulations. Hopefully some of what I wrote was interesting.

What this does not address is what we should do about complexity. In understanding the origin of complexity in our projects, is there a fix to the problem? The answer is, unhelpfully, yes and no.

Forget about an easy fix. Dealing with complexity in projects is itself complex. It involves time and effort to prevent complexity becoming an issue, and to manage it where there is irreducible complexity. The ten problem areas I have highlighted are a good place for any project to start. Some project teams are already very aware of the challenges and taking approaches that reduce and manage the inherent project complexity. Unfortunately such teams are few and far between. In my time at IPA, I kept a record of every project I worked on, and I can thus quantify that from my experience the number of project teams that fell into this category is less than two percent.

The issue is not one of adopting a different approach, but of raising awareness. This is a path that I note the Projects, Facilities and Construction discipline in SPE has been taking recently. I can only hope that this blog post has, in some small way, helped contribute to that awareness.