GPM First
Chapter 1 of Second Order Project Management (978-1-4094-1094-2) by Michael Cavanagh

What Makes Projects Complex?

CHAPTER 1

 

Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.

Dr Laurence J. Peter

 

Let’s begin by understanding what ‘complex’ means in project terms – and the easiest way to do this is to start with what it isn’t. Clearly, complexity isn’t simple; but neither is it complicated. The difference is in the degree of uncertainty. Complicated things are difficult to produce; they are usually made up of a large number of components; they may take a long time to build – but they are capable of being described in detail, down to the last brick, rivet or connection. Because of that, their design and construction can be accurately and precisely articulated and planned; they can be built even by people who don’t fully understand what they are doing, so long as they comply – to the letter – with the engineering processes that are laid down by those who do. Any failure is due to either lack of compliance or an inadequacy in the process description.

I tried to build a kit car once – a Westfield Speedsport – and got stuck at a very early stage. The salesman claimed that it would take 150 hours to build. What he meant was that it would take someone who knew what they were doing 150 hours. After 150 weeks, I gave up and got some expert help. In my (admittedly rather pathetic) defence, I submit that the reason I ended up having to get outside assistance lies at the feet of the author of the build manual, who clearly didn’t understand just how great was my lack of understanding of even the first principles of mechanical engineering. Putting the car together wasn’t a complex task – it was just complicated. Given a set of instructions at my level of experience and previous knowledge, I could have built it on my own. I think.

Complexity arises when a design or a plan contains unknowns and uncertainties. Although it may very well be broadly accurate, it will almost certainly be precisely wrong. The real reason it took me years instead of hours to build the car wasn’t only how complicated were the nuts, bolts and wiring – it was the external elements that I hadn’t bargained for, the main one being the million and one unpredicted distractions and a failure to realise how unpleasant and demotivating it would be to work in an unheated garage. This was actually the worst kind of complexity – it’s bad enough if the uncertainties are expected (‘known unknowns’ to use a Rumsfeldism). When the unknowns are unknown (‘things we don’t know we don’t know’), and therefore unacknowledged, there could be a few surprises in store …

To an extent, then, every project – indeed every future venture – has its element of complexity, since we live in a constantly changing world. (viz. Heraclitus of Ephesus – ‘you can’t stand in the same river twice’) No one can predict the changes in the external ‘PEST’ (Political, Economic. Social, Technological) environment with 100 per cent certainty. In the simplest projects, such changes are unlikely to have much effect; but the level of project complexity grows in direct proportion to the number of areas of uncertainty, and there is a point at which possible changes in both the external environment and the capability of the internal organisation demand that the level of complexity is identified and addressed. We term these areas of uncertainty ‘Complexity Drivers’ – not all of which affect every project to the same extent. They comprise any element of the project that interacts with its environment and other components, whether these be people, organisations, technologies and/or processes. The Project Complexity Measure (PCM) will thus be the combination of any given project’s Complexity Drivers, their depth, the number of interactions between them, and the organisational capability to deal with these.

If complex projects are to be successfully planned and managed, it therefore becomes necessary (and in my opinion should be mandatory) to perform a PCM Assessment (essentially an additional component of a pre-project risk identification phase) at the earliest stages of the project lifecycle, and to maintain the currency of this assessment throughout.

There are two Complexity Driver dimensions.

Capability drivers are relevant to the organisation and the individuals who make up the project team, and will include:

  • leadership style/experience and behavioural attributes such as wisdom, action orientation, inspiration, focus, courage, ability to influence;

  • team experience, structure and track record;

  • platform/technology novelty;

  • learning culture; flexibility and creativity;

  • Risk aversity/risk seeking organisational culture;

  • internal and external environmental turbulence;

  • process/method/tool experience.

 

Project-specific drivers are made up of elements such as:

  • urgency/business criticality;

  • outcome novelty;

  • intricacy;

  • scope, cost/budget, duration;

  • safety criticality;

  • requirements maturity and stability;

  • stakeholder numbers/geographical separation;

  • stakeholder organisational stability;

  • external regulation/governance;

  • platform/technology interactions;

  • number of component (subsystem and stakeholder) interactions and relationships;

  • contracting models.

 

An expanded description of a PCM Assessment process, and the generic assessment questionnaire, can be found on the authors website www.mcavanagh.com.

As complexity increases in respect of either or both of the above types of driver, so the necessary response must also change; and this introduces the concept of ‘first’ and ‘second’ order tools, methods and techniques. The appropriate responses can best be illustrated by means of placing them on a Complexity Assessment Matrix, as in Figure 1.1.

 
Figure 1.1 Complexity Assessment Matrix

graphics/fig1_1.jpg

 

Low Experience, Low Complexity – An example of which could be any ‘Black Box’ component such as ‘Plug-and Play’ software, where the complexity and experience all lie with the provider and all the end user has to do is load a CD or connect an interface. If an organisation were even to contemplate building such a product for themselves, it would not only be a culpable waste of money, but would also result in a sub-standard product (though it has been tried, with risible results!).

High Experience, Low Complexity – These are the routine, bread and butter, cash cow products – possibly tailored to individual customer preference, but essentially standardised. Projects in this domain will have been successfully executed many times before (and they may in fact be ‘complicated’) but the performance of the deliverable will be known and proven. However, that does not mean that they should be allowed to run outside a controlled project framework. They still demand rigorous application of what we shall term ‘First Order’ PM tools such as Earned Value Management, Lifecycle Management and Gateway Reviews, alongside PRINCE 2, CMM-I and similar ‘process’ guidelines. The quality of the delivered product or service will be a function of process compliance and competent management.

Low Experience, High Complexity – This is where things begin to get difficult, and the ‘can-do’ organisation is in danger of biting off more than it can chew. It takes courage to admit that a project is too complex for the existing team experience level to undertake – but that is where real leadership kicks in, over and above simple management tasks. It may be that herein lies the strongest argument for PCM Assessment – the danger lies in a lack of appreciation of the true complexity of the task, and this is likely to be most strongly the case where the project-at-hand is novel to the organisation. All too often, however, the assessment is not performed, and uninformed commitments are made out of eagerness to please, enthusiasm to get going and a reluctance to spend time and money on an exercise that may eventually prove not to have been needed. It is worth quoting Admiral Chester Nimitz, C-in-C Pacific, in evidence to the Court of Enquiry on the 1944 typhoon which resulted in the loss of three ships and almost 800 officers and men: ‘The time for taking all measures for a ship’s safety is while still able to do so. Nothing is more dangerous that for a seaman to be grudging in taking precautions lest they turn out to be unnecessary. Safety at Sea for a thousand years has depended on exactly the opposite philosophy.’ Projects in this quadrant are the ones that make the headlines when they, almost inevitably, go wrong.

At an extreme level, the correct response is to get out quick. Where this is not possible, for whatever reason (political or commercial pressure being the most usual), then it becomes imperative to acquire the necessary experience from outside the team, either through recruitment (unlikely to be quick enough) or external consultancy. This does not mean that the project can simply sit back and watch – unless the consultancy intervention incorporates a managed knowledge/skill/ wisdom transfer, the situation won’t improve and next time will be no better. Opportunities for developing internal repertoire must be grasped when they arrive, so that the sum of team experience/repertoire is increased and future projects placed in the top right quadrant.

High Experience, High Complexity – This is where the glittering prizes lie for those individuals and organisations who possess the repertoire and experience to dare to undertake complex tasks – not without risk, but with eyes wide open to the expectation that the unexpected is inevitable. In addition to their mastery and deployment of first order tools and techniques, they place huge importance in operating at a second order level.

So what is Second Order PM? And how does it differ from First Order PM? Can it be performed by the same people?

Submit your own content for publication

Submit content