Contrary to my post a few years ago asserting that project complexity does not matter, and that it is instead project definition and planning that is at the heart of project success, I am now of the view that complexity does matter. Does this mean that my earlier post was wrong? Not quite, but it appears that in writing the blog post I have since been introduced to some novel thinking regarding “complexity”. Whereas I had used the word merely to contrast with “simplicity”, others in the project management field have recognised that projects don’t just fall into two categories of simple versus complicated. Specifically the word “complexity” is used to describe projects with complicated interactions, and where uncertainty in those interactions can lead to emergent problems which are hard to predict using deterministic methods.
So my more enlightened view is that project complexity does matter, and should be avoided wherever possible through effective project definition and planning. In this blog post I explain why and how I have arrived at this different viewpoint.
Complexity Versus Complication
I should thank Stephen Grey who responded to my original post and introduced me to current academic and industry thinking about complexity. A useful concept that has been proposed is the Cynefin framework, which is a technique for categorising complexity. This breaks a system down into four different domains, each of which behave differently and therefore require a different approach to managing the system effectively.
Source: Based on conceptual framework by Dave Snowden.
From a projects perspective, the nature of the project, its scope, location and the resources available define whether a project is “straightforward” or “involved”. In other words there is a sliding scale that captures the overall effort required for all of a project’s activities. For example a very straightforward project might be making a cup of tea, and a very involved project would be landing a man on the moon. These are extreme examples, but hopefully you get the gist of the idea.
Complexity then defines the route taken in delivering the project according to the original plan. There are many ways in which a system can be complex, but it is clearly distinct from a system that is ordered. In an ordered system, every action taken will have a predictable outcome. Small projects with limited routine scope should most often fall into this category. At the other extreme is an unpredictable system, where every action may or may not have its intended effect due to the interplay of many parts. Megaprojects with multiple scopes, new technology and large dispersed teams mean that the project is evidently difficult to control simply because there are a larger number of activities that may not proceed according to plan, and which can have a knock-on effect on subsequent activities. However, both the small projects and megaprojects could behave in the same fashion. There is no law that states all small projects will behave like ordered systems, and that all megaprojects will be unpredictable systems. It is just more likely that this is the case, especially if we don’t do anything to stack the odds in our favour.
So for our projects, we can think of the project behaviour in terms of how we expect cause and effect to relate to each other. This will drive how we manage the project.
- Simple: Cause and effect are directly related. These are the “known knowns”. We can simply determine what the most appropriate approach is, based on past experience, and then apply standard industry Best Practice to deliver the project.
- Complicated: Cause leads to effect and is understandable. These are the “known unknowns”. By carefully thinking and analysing the situation, we can detemine an effective approach to the project. It is likely that Good Practice is required to implement similar effective strategies that have previously been demonstrated to work based on first principles.
- Complex: Relationship between cause and effect is initially unclear, but can be determined in retrospect. This is the effect of “unknown unknowns”. Something occurs that was not anticipated, and the project is effected by it. Because the project’s behaviour is emergent, a flexible approach to project execution is necessary so that changes can be accomodated.
- Chaotic: Cause and effect are apparently unrelated. There is a great deal of uncertainty involved and the best approach is to take action – ANY action. This is the approach typically taken during emergency response situations.
Can We Measure Complexity or Predictability?
In the context of the Cynefin framework, which is a categorisation approach, it would be counter-productive to attempt to quantify the degree of project predictability. The outcomes determine which project behaviour is evident. The main issue for projects is in ensuring we remain within a predictable environment, and therefore increase our chance for delivering a successful project.
As a project becomes more involved, with multiple scope elements, it becomes increasingly likely that the project behaviour will tend towards a complex one with emergent issues. The problem is not recognising that the project has become less predictable, and blindly sticking to the original plan. For complex and chaotic environments, a certain degree of replanning will be necessary, and this must happen quickly and be communicated to the whole project team. In order to avoid this situation, it is imperative to eliminate as many of the unknown unknowns as possible.
One of the great risks facing projects today is the imposition of project processes. Generally these are necessary and a good thing. The processes exist for good reasons, to impart some degree of predictable project delivery within large organisations. The problem with them is that they all too easily devolve into a “tick the box” exercise, particularly with weaker project teams. This lulls the team (and the owner company) into a false sense of security. Thinking that they have a “Simple” project, authorisation is given and then the problems start to emerge. There is a cliff between “Simple” and “Chaotic”, and once you go over the edge it is a viscous circle as the project team is unable to implement the necessary project management approach for a project that is behaving fundamentally different to expectation.
The Role Of “Agile” Philosophy For Industrial Projects
For a long time I was of the view that the Agile philosophy often used for IT projects, simply had no place in the world of industrial projects. After all, whilst it is all very well and good to forge ahead and get some code up and running, and then respond to user feedback, the difference between IT and industrial projects is fundamental: to implement a change to feedback in software requires a patch to be pushed out, but to achieve the same with a capital project will involve reworking steel and physical equipment that has already been installed. It is several orders of magnitude more difficult.
I was recently made aware of a specific kind of project in the oil and gas industry that is perfectly suited to this philosophy. This is the application of new technology. The oil and gas industry is very risk averse, and introducing a new technology will typically involve lots of testing and quality checks – just to do a trial field run, let alone put it into practice on a real field development. This slows the feedback loop from gathering of performance data, and thus making improvements to the technology. When viewed in that context, it is perhaps not so surprising that technology takes forever to be introduced in the oil and gas industry.
An Agile approach would see smaller ‘proof of concept’ applications of the new technology pushed out. As the technology is demonstrated in use, improvements can be made, and revised versions of the technology introduced in subsequent projects. There is nothing wrong with such an approach, provided that the operator recognises that this approach is inherently “Complex”. That is to say, there will be unexpected results, and an Emergent Practice approach to managing the project is necessary.
Strategies To Eliminate Complexity
There are many project processes in existence, and several different schools of thought concerning what constitutes Best Practice when it comes to project management. These are three recommended approaches that I pursue based on my experience from actual projects and my time consulting to many large oil and gas projects.
Don’t Bite Off More Than You Can Chew
Keep the project scope and technology simple whereever possible. Minimise the number of interfaces to be managed, identify all interfaces, and scale up the size of the project team to be able to handle those interfaces.
First and foremost, it must be clear what it is the project aims to achieve. Nothing will drive scope growth and bloat faster than unclear objectives. Be ruthless. If you don’t need it for the project to deliver the required results, then don’t allow it a fertile environment in which to spring into existence. “Nice to have…” should be clarified as “… in someone else’s project”.
Assuming we have realistic and achievable objectives that are well defined, then the next step involves ensuring that the chosen scope of work to meet those objectives does not over-extend the available resources. Generally this means sticking to scope that can be effectively managed by the organisation, or if the scope exceeds the capability of the organisation, then expanding the resources available.
Resources alone will not be sufficient. Keeping an eye on the interfaces between different scope elements is essential. If the interfaces are not identified and managed, then there is the very real risk that known unknowns will become unknown unknowns. e.g. we might know that the physical interface between a platform’s topsides and jacket exists, but the exact method of installation and construction is not known because the engineers (from two different engineering contractors) have not got together to produce a single compatible design. This is a known unknown. We know that there is uncertainty, and the nature of that uncertainty. This leads to a “Complicated” project behaviour, but one which can be managed using Good Practice, and through ensuring there is good communication between the contractors etc.
However, if the project team is not willing or able to manage the interface closely, there is a risk that unknown unknowns will emerge. e.g. in allowing the contractors to push ahead with their designs the weight of the topsides and jacket was allowed to grow. However no-one had thought to check that a heavy lift vessel actually existed to manage the planned offshore installation. This wasn’t discovered until engineering was nearly complete and fabrication had already started. The solution therefore was to ‘cut’ the platform topsides in half, leading to a vast number of offshore connections for piping and cabling that would be required (quite apart from the compromise to structural integrity). The late change itself then leads to consequential issues for a myriad of other related scope elements, none of which were originally anticipated when the design (on paper) was for a single topsides unified deck. Essentially the project team thought they were dealing with a “Complicated” project, but ended up biting off more than they could chew without realising it, and were left trying to manage a “Complex” project for which they were ill-prepared.
By the way, I can’t make this stuff up. That last example is based on a real project that I consulted on…
Fail To Plan, Plan To Fail
Define the project’s execution and anticipate known uncertainties and their potential effect on the project. Consider all reasonable risks that could effect the project, and for those that could have considerable effects, either mitigate them or plan for how the project would respond if the situation emerges.
An alternative description for this strategy is a phrase I came across whilst in cadets at school: “prior planning and preparation prevents piss poor performance”. Trust the military to come up with an expression that should be memorable to a squaddie capable of using alliterative language like, “f**king hell, the f**king f**ker’s f**king f**ked”. For the record I didn’t make that up. I genuinely heard a squaddie say that in the ordinary course of a day.
Apologies to those offended by the language.
Understanding the effectiveness of our planning can be achieved by measuring the level of project definition. There are several different ways to do this, including my own proposed method for a project definition rating. Logically we might conclude that if we attempt to measure our project definition, then it forces us into a better understanding of our project drivers: the ‘why’, ‘where’, ‘what’ and ‘how’ of our project. In doing so we are more aware of what could happen during project during execution and the likely behaviour mode for the project, and we are thus better prepared to manage any unexpected eventualities.
The answers to all four questions are important aspects of project definition:
- Why are we doing the project? This is the basis of the project. Do we understand the objectives as set out by the business, for the project and indeed for our own discipline. What are the trade-offs such as those between capex and opex? Should we prioritise cost, schedule or production outcomes? Do we understand the basic data that will guide our choice of concept such as metocean or soil conditions, reservoir volumes, fluid properties etc.? Do we need to define the project carefully as the economics are marginal, and what about the significance of the project to our company or the host government? Should we expect interference?
- Where is the project located? This is the project context and is the second foundation for any project definition. Is our location remote which might require complicated logistics? What about the contractors and vendors? Are there any available in the country or will fabrication need to be done elsewhere? Will doing so cause a problem for any local content requirements? Do we understand all the environmental, regulatory requirements in the host country and are we on track to obtain all necessary permits in a reasonable timeframe?
- What will the project involve? This refers to the technical evaluation work that has been performed. Based on our knowledge of the basis of the project and the project context, we are able to design an appropriate solution that meets the project objectives whilst honouring and meeting all known constraints. Clearly defining the ‘why’ and ‘where’ of the project early is important as otherwise we might design the wrong ‘what’. Have we captured and defined all the the scope necessary to meet the required functionality and capacities? Do we need to use new technology or can we use an existing standardised solution? Have we completed all the technical work necessary to build accurate cost and schedule estimates? Does our design include ancillary utilities and infrastructure or have we neglected this whilst we focused on the sexy process part of the scope? Have we incorporated input from HSE, operations etc? Is all our work documented?
- How will we execute the project? This is the execution planning necessary to ensure the vision of the ‘what’ becomes a reality. Have we created our own schedule that incorporates input from all disciplines in the project, or will we just rely on whatever the contractors tell us? Do we understand what resource constraints we might face, and have we used that knowledge to help guide our development of the schedule? Are we actively managing risks and opportunities so that we mitigate the risks and try to realise the opportunities? Do we have effective project control plans so that won’t just be a passenger on the Titanic and instead have the ability to anticipate trouble and steer the ship back on the right course? Have we worked out scenario plans (a.k.a. Plan B) to manage the risks that we have not been able to mitigate? Do we have a team where everyone is working towards a common goal?
Exactly how these project definition categories can be quantified and used to help identify areas of emergent complexity is something I am currently working on as part of my Pyrus Suite software. The goal is to create an integrated project simulation environment which will model all aspects of an oil and gas project from the reservoir to export point, including reservoir, wells and facilities across cost, schedule and production outcomes. An integrated tool should allow the effects of definition shortcomings to be simulated, so that it is possible to understand where there may be higher risk of emergent complexity in any project. As far as I know no such tool to do this exists today.
Are We Singing From The Same Hymn Sheet?
Ensure an integrated project team is in place that understands all aspects of the project. If everyone is working towards a common objective, then it is more likely that the goal will be reached as planned.
Complexity arises where there is uncertainty regarding the interaction between different system components. In the case of an oil and gas project, one interpretation of that is whether or not project team members appreciate and understand how their part of the project interacts with another. In particular, are they aware that choosing a less optimal solution for their particular scope is a potentially better choice because it eliminates problems in other parts of the system? If not then the chances are that discipline might start a chain reaction of problems elsewhere in the project.
When a group of people are working together towards a common goal then tremendous achievements can be accomplished. Complexity can be subdued. If there are separate ‘warring factions’ within a project, or silos of functional expertise that do not interact with each other, then the project is likely to take on a life of its own that is very difficult to control. Complexity will win.
It is said that people do projects, not processes. It is very true. A project process is a tool to ensure that projects are delivered to consistent standards, and to facilitate comparison between different projects (an important aspect of portfolio management). But the process does not do the project, nor will it ensure that the project is done well if the project team is merely gaming the system to appease management and merely appear to be managing the project well.
So if a project process is not the answer to achieving high performing teams that work well together, then what is? I don’t believe there is a single answer to this question. There appear to be various strategies that work. However in all cases the strategies are compatible with the cultural sensitivities of the project team. Perhaps that is the key.
The two examples that I have are both project teams that I interviewed whilst working at Independent Project Analysis. For confidentiality reasons I cannot disclose the companies or the projects.
- This team was from a western company that brought all its team members together at the project location. The head office didn’t like it because of the cost involved, but the project manager believed it was in the best interest of the project. The capability of the team was exceptional, and I used the project anonymously as a ‘gold standard’ example with many other projects during my time at IPA. The culture of the project was one where everyone was encouraged to contribute, and information sharing was a part of the daily routine. Case in point: one of the facilities leads was able to explain the reservoir characteristics and uncertainties to me. Although this was far from the largest project in the company, the project leads had elevated the profile of the project by emphasising its importance to all team members, and by making it known that their contributions mattered. This was a ‘touchy feely’ approach that appealed to the sensibilities of people by recognising and rewarding individual input. In some respects this approach reminds me of a donkey being led along by a carrot.
- This team was dealt a bad hand with their project. Difficult location, business-imposed schedule pressure that limited the project definition achieved, and just to add icing to the cake: it was a megaproject. By any measure of complexity, this was almost off the scale. Yet against all the odds, the project team delivered. There is perhaps some element of luck in the result that was achieved, but I suspect that the project culture had a part to play too. Where the previous project team was using the ‘donkey and carrot’ strategy, this project team was using the alternative ‘donkey and stick’ strategy. Actually I don’t believe they did so by choice, but management had imposed this upon them, and the company came from a country where rigid hierarchical structures are normal. When the big boss says that the public holiday next week does not apply for the project because the project schedule does not allow it, then the project team naturally asks, “what public holiday?”. By the way, that wasn’t an illustrative example, it actually happened. Whilst this approach may not appeal to western sensibilities, it has to be recognised that it forced everyone to work together, and in doing so they were able to contain the emergent complexity in the project.
Closing Thoughts
Areas of complication in a project, and how they might be affected by emergent complexity, also are discussed in an earlier post on “Does Complexity Matter”. I have updated this post to better adhere to the distinction between complication and complexity, and I feel that the post now does a better job at explaining why particular aspects of a project need to be heeded in order to minimise the chance of emergent complexity. This post contains some worthwhile guidance on where to emphasise effort with respect to project definition.
Emergent complexity in a project can and often will lead to poor outcomes. Any sane project management strategy should therefore seek to eliminate the potential for any complexity to emerge in a project, or failing that should ensure that the project team is capable to respond to a constantly evolving situation. In this post I have proposed three strategies that could be applied. These strategies are not mutually exclusive. Nor are they they only possible solutions, let alone necessarily the best solutions.
As a final thought I would draw your attention to the header image for this post. This is a scene from the original The Italian Job movie where Michael Caine protests with the classic line, “You’re only supposed to blow the bloody doors off!” in response to a test of the effectiveness of their explosives. The movie is a wonderful demonstration of how planning might lead to an excellent result, yet still emergent complexity manages to make an appearance towards the end.