Category Archives: Complexity

Differentiating normal, complex and megaprojects

The days when projects were simply projects and project success was defined by the ‘iron triangle’ are long gone.  The intention of this post is to try and bring together four aspects of current thinking and their embedded concepts into an overall model of project management in the 21st century.  The starting point is traditional project management as defined in the soon to be published 6th Edition of the PMBOK® Guide; the major change (incorporated in the 6th Ed.) is ‘Agile Project Management’.  The two significant extensions to traditional project management that go beyond the PMBOK® Guide are ‘Complex Project Management’ and ‘Megaproject Management’. The focus of this paper is on the skills and competencies needed by the ‘managers’ of these different classifications of ‘projects’ rather than the scope of the different concepts (more on this later).

As a starting point, there seems to be a generally accepted view that the competencies needed to be a successful project manager underpin all of the other concepts. There are some distinctly different techniques used in Agile, only some of which flow into traditional project management, but in other respects ‘agile’ and ‘good project management’ are very closely aligned.  Managing complexity requires a significant additional set of competencies that build onto the traditional requirements.  Then, whilst many complex projects do not meet the definition of a ‘megaproject’, every megaproject is by definition a complex project with an additional layer of management capabilities needed to deal with its impact on society.  This basic framework is outlined below:

Stakeholders

All forms of project management recognise the importance of the project stakeholders. Projects are done by people for people and the ultimate success or failure of a project is defined by people – all ‘stakeholders’.  My work on the PMBOK® Guide 6th Edition core team was very much focused on enhancing the sections on stakeholder engagement and communication (which is the primary tool for engaging stakeholders). And as the scale of projects increase, the number of stakeholders and the intensity of public focus increases dramatically.

A heuristic suggested by Prof. Bent Flyvbjerg is as a general rule of thumb: ‘megaprojects’ are measured in billions of dollars, ‘major projects’ in hundreds of millions, and ‘projects’ in tens of millions or less. To quote the late Spike Milligan, ‘Money can’t buy you friends but you do get a better class of enemy’ – and while many stakeholders may not be ‘enemies’, the ability of stakeholders to organise around a megaproject tends to be far greater than around a small internal project. Consequently, the focus on stakeholders should increase significantly in excess of the increment in cost as you flow from small to megaprojects.

However, regardless of size, the need to identify, engage, manage, and deliver value to stakeholders, through the realisation of beneficial change, is consistent through all of the concepts discussed below. This and the temporariness of each ‘project organisation (ie, team)’ are the two consistent factors that underpin the concept of project management; and ‘temporariness’ is the key factor that separates projects and programs from other forms of management and ‘business as usual’.

 

Traditional Project Management.

The recognised guide for traditional project management is the PMBOK® Guide augmented to a degree by ISO 21500. The publicly released information on the 6th Edition highlights the need for flexibility in applying its processes, including the requirement to actively consider ‘tailoring processes’ to meet project requirements, and the value agile thinking can bring to the overall management of projects (see below).

The frame of traditional project management starts once the project is defined and finishes once the project has delivered is objectives. While this scope is somewhat limited and there may be a need to expand the scope of project management to include project definition at the ‘front end’, and benefits realisation and value creation after the outputs have been delivered (this will be the subject of another post), the knowledge, skills and competencies required to manage this type of project management are well understood.

Each project has four basic dimensions, size (usually measured in $), technical difficulty, uncertainty and complexity (these are discussed in detail in: Project Size and Categorisation). In the right circumstances, Agile can be an effective approach to resolving uncertainty. However, at an undefined point, the increase in complexity reaches a point where the concept of ‘complex project management’ becomes significant and really large projects are the realm of ‘megaproject management’. But the underpinning capabilities required to manage all of these extensions remains the conventional project management skills.

 

Agile Project Management

Agile has many facets. The concepts contained in the Agile Manifesto basically reflect a shift away for a ridged focus on process towards a focus on people (stakeholders) and adapting to change to achieve a successful outcome.  These concepts are now firmly embedded in the PMBOK® Guide 6th Edition and apply to every project. Where agile projects separate from traditional projects is recognising that in a range of soft projects, including software development, taking an iterative and adaptive approach to understanding the scope can often achieve a better outcome. Understanding what is actually helpful to the client develops based on learned experience from earlier iterations and these needs are incorporated into the next iteration of the development allowing a better outcome to be delivered to the client. This is not significantly different to much older concepts such as ‘rolling wave planning’ and progressive elaboration – there really is little point in making detailed plans for work you don’t know much about. The difference is Agile actively expects the scope to be adapted to the emerging requirements of the client, the other approaches seek to add detail to the plans at an appropriate point in time whilst the overall scope remains fundamentally unchanged.

Agile does not even need a project to be useful. Many of the Agile techniques work in any situation where there is a backlog of work to get through and can be effectively used outside of the concept of a ‘project’, this particularly applies to routine maintenance work of almost any kind.  A discussion on the value of Agile, and its limitations, are contained in our paper Thoughts on Agile.

However, for the purposes of this post, the key aspects Agile brings to the discussion, that are essential for effectively managing most types of project, are contained in the Manifesto – a preference for:

  • Individuals and interactions over processes and tools.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

The Manifesto recognises there is value in the items on the right, but values the items on the left more.

 

Complex Project Management

Complexity is a facet of every project and program. Complex project management skills become important at the point where complexity becomes a significant inhibitor affecting the delivery of a successful outcome from the project (or program). This point may occur well before ‘complexity’ becomes the defining feature of the project.

Complexity is a very different concept to a complicated project, technically complicated work can be predicted and managed; launching a new communication satellite is ‘rocket science’, but there are highly skilled rocket scientists available that undertake this type of work on a routine basis. As with any traditional project, the costs, resources and time required can be predicted reasonably accurately.

The dominant feature of complexity is the non-predictability of outcomes. Non-linearity, ‘the tipping point’, and emergence describe different ways outcomes from a slightly different starting point can vary significantly compared to previous experience or expectations (for more on the concepts of complexity see: Complexity Theory).  Complexity arises from various forms of complex system, these may be organic (eg, a river’s eco-system), man-made (eg, an overly complicated system-of-systems such as too many interconnected software applications automatically interacting with each other), or interpersonal (eg, the web of relationships within and between a project team and its surrounding stakeholder community).  In all of these situations, the ‘system’ behaves relatively predictably, dealing with the effects of stresses and stimuli up to a point (and normal management approaches work satisfactorily); but after that point adding or changing the situation by a small increment creates completely unexpected consequences.

Interestingly, from the perspective of managing a project, these three areas of complexity are closely interlinked, the complex behaviour of the environment and/or man-made systems-of-systems feeds back into the perceptions of stakeholders and the activity of stakeholders can impact on both the environment, and the way complex systems function. Similarly, dealing with emerging anomalies in the environment or in a complex system needs the active cooperation of at least some of the project’s stakeholders. Consequently, the focus of complex project management is dealing with the consequences of the inherently unpredictable and complex behaviours and attitudes of stakeholders, both within the team and within the surrounding stakeholder community.

Some projects and programs, particularly large ones, are obviously complex from the outset and can be set up to make effective use of the ideas embedded in complex project management. Others may be perceived as non-complex ‘business-as-usual’ and tip into complexity as a result of some unforeseen factor such as a ‘normal accident[1]’ occurring or simply because the perception of ‘straightforward’ was ill-founded. Underestimating complexity is a significant risk.

Where the project is perceived to be complex from the outset, a management team with the competencies required to deal with the nuances of managing a ‘complex project’ can be appointed from day one (and if appropriately skilled people are not available, support and training can be provided to overcome the deficiencies) – this maximises the probability of a successful outcome.  When a project unexpectedly falls into a state of complexity the situation is far more difficult to manage primarily because the people managing the work are unlikely to be skilled in complex project management, will try to use normal management techniques and most organisations lack the resources needed to help rectify the situation – skilled complex project managers are in short supply globally.

One initiative designed to overcome this shortage of ‘complex project managers’ and build an understanding of ‘complex project management’ is the International Centre for Complex Project Management (ICCPM).  ICCPM’s approach to complex project management is to see this capability as an extension of traditional project management (as inferred in the diagram above). The ICCPM view is that while traditional approaches are insufficient to effectively manage a complex project on their own, you cannot manage a complex project without a strong foundation based on these traditional skills and processes. The relationship is described by the ICCPM as:

What changes is in part the way the traditional capabilities such as scheduling and budgeting are used, overlaid with the expectation these artifacts will need to adjust and change as the situation around the project changes, augmented with a range of ‘special attributes’ particular to the process of managing a complex project. These ‘special attributes’ are valuable in the management of any project but become essential in the management of complex projects.  These capabilities and competencies are defined in the ICCPM’s Complex Project Manager Competency Standard available from: https://iccpm.com/.

Complex projects can vary in size from relatively small undertakings involving factors such as updating a complex systems-of-systems, or a high level of political sensitivity, through to the megaprojects discussed below. A complex project may not be a megaproject or even a major project, but every megaproject and many major projects will also be a complex project requiring complex project management capabilities for a successful outcome.

 

Megaproject Management

Megaprojects are defined as temporary endeavours (i.e. projects or programs) characterised by:

  • A large investment commitment;
  • Vast complexity (especially in organizational terms); and
  • A long-lasting impact on the economy (of a country or region), the environment, and society.

They are initiatives that are physical, very expensive, and public. By definition, megaprojects are complex endeavours requiring a high degree of capability in the management of complex projects.  In addition megaprojects typically involve a number of other facets:

  • Megaprojects are by definition a program of work (see: Defining Program Types).
  • Many are implemented under government legislation, requiring skills and knowledge of government processes and the ability to operate within the ambit of ‘government’. This is a very different space in terms of accountability and transparency compared to private enterprise.
  • Most interact with a range of government agencies at all levels of government from local to national. These stakeholders often have a very different set of agendas and success criteria compared to the organisation running the megaproject.
  • The size of a typical megaproject involves large amounts of money and therefore increases the risk of corruption and other malfeasance – governance and controls need to be robust[2] to maintain high ethical standards.
  • The ‘political attractiveness’ of doing a megaproject (eg, hosting the Olympics) distorts decision making; care in the megaproject development process is required to reduce the effect of optimism bias and strategic misrepresentation (see: The reference case for management reserves).
  • Megaprojects are financially fragile[3] and fragility is typically irreversible. Once broken the fragile entity cannot be readily restored to its original function. Financial (or investment) fragility is defined as the vulnerability of a financial investment to becoming non-viable, i.e., losing its ability to create net economic value. For example, the cost risks for big dams are significant; the actual costs more than doubles the original estimate for 2 out of 10 dams; triples for 1 out of every 10 big dams. But managers do not seem to learn; forecasts today are likely to be as wrong as they were between 1934 and 2007.

Recognising the scope and complexity of managing a megaproject and training people appropriately can mitigate the risks, the UK experience around Terminal 5 and Cross Rail (both £4 billion projects) suggest that achieving a good outcome is viable provided the organisation commissioning the megaproject is prepared to invest in its management. It’s probably no coincidence the management of megaprojects and their associated risk has been the focus of the Saïd Business School, University of Oxford for many years.

 

Summary

The competencies needed to manage projects grows in line with the increase in complexity and the increase in size. There are definitely additional elements of competency needed at each step in the framework outlined above.  What is far less clear is how to demarcate between normal, complex and megaprojects! Every project has a degree of complexity and a degree of size.  The values suggested above to separate normal, major and mega projects are arbitrary and there is even less clarity as to the transition between normal and complex projects.

I suspect the domain map demarcating the different disciplines will end up looking something like this but there’s a lot of research needed to define the boundaries and assign values to the axis (especially in terms of measuring the degree of complexity).  Hopefully, this blog will serve to start the discussion.

______________________

 

[1] Normal accidents are system accidents that are inevitable in extremely complex systems. The three
conditions that make a system likely to be susceptible to Normal Accidents are:
–  The system is complex
–  The system is tightly coupled
–  The system has catastrophic potential
The characteristic of the system leads to multiple failures which interact with each other, despite efforts to avoid them.

[2] For more on governance and ethics see: http://www.mosaicprojects.com.au/PM-Knowledge_Index.html#OrgGov1

[3] From: Big Is Fragile: An Attempt at Theorizing Scale, in Bent Flyvbjerg, ed., The Oxford Handbook of Megaproject Management (Oxford: Oxford University Press)

Stakeholders in complexity

The new CPM is ‘Complex Project Management’ and whilst most of the current project management tools and practices including risk management, scheduling and EVM remain important, they are not sufficient to successfully manage a complex project according to Stephen Hayes, from the Canberra based International Centre for Complex Project Management ICCPM.

ICCPM Ltd was established by Australian, UK and US government bodies and major defence industry corporations, and is now a substantial network of global corporate, government, academic and professional organisations committed to the better management of complex projects across all industry and government sectors focused on improving the success of complex projects.

ICCPM

Whilst all projects have a degree of complexity (see: Project Size and Categorisation) CPM is focused on the major projects undertaken in response to ill-defined and often mutually-incompatible stakeholder requirements and are subject to uncontrollable external influences and almost continuous change.

Successfully managing this type of project needs outcome focused leadership that is capable of developing context specific innovative approaches to issues backed by the tenacity to deliver ‘no matter what’!

The latest report facilitated by ICCPM in conjunction with Global Access Partners and a range of leading public and private sector organisations is entitled “Complex Project Management: Global Perspectives and the Strategic Agenda to 2025” (available from https://iccpm.com/).

This report has developed a framework for on-going research into CPM under six broad themes:

  • Delivery leadership – the ability to navigate through uncertainty and ambiguity to achieve the desired outcome.
  • Collaboration – working as one team to a mutually agreed goal and equitable reward (including operating the entire supply chain as a single entity).
  • Benefits realisation – understanding and delivering through-life product value.
  • Risk, opportunity and resilience – taking good risk, seizing emergent opportunity, and successfully responding to the unexpected.
  • Culture communication and relationships – maximising the effectiveness of the human asset by understanding and responding to human behavioural need.
  • Sustainability and education – continuous learning, maintaining currency in leadership capability and knowledge transfer across generational boundaries in order to sustain through-life capability.

Against each of these a basic set of policies and actions have been developed to define the future work and research agenda of ICCPM, its partners and academia.  To this end ICCPM is working to develop a permanent, co-ordinated global specialist research agenda for CPM.

With support from the UK Cabinet Office, the Australian Government, universities including QUT and DAU, professional associations including IPMA and APM, and companies such as BAE Systems and Thales (to name but a few) this initiative may prove successful.  Two glaring omissions from the list of supporters though are the AIPM and PMI –maybe this blog will trigger some action.

Certainly the emergence of stakeholders at the centre of complexity means stakeholder management and engagement will be a topic of increasing importance which is only to be encouraged.

Note: The contents of this post are based on the executive summary of the ICCPM – GAP CPM Task Force report: www.iccpm.com

Poor Governance creates complexity

All projects and programs have four dimensions that in aggregate determine how difficult they will be to manage. The four basic dimensions are:

  • Its inherent size usually measured in terms of value;
  • The degree of technical difficulty in creating the output (complication);
  • The degree of uncertainty involved in the project; and
  • The complexity of the relationships (‘small p’ politics) both within the project team and surrounding the project.

These aspects are discussed in our White Paper: Project Size and Categorisation

Of the four, size and technical difficulty are innate characteristics of the project and are not affected by governance, they simply need to be properly understood and managed.

Uncertainty always exists to a degree and can affect what techniques and what processes should be used for the best effect (what to do) and how to achieve the objective (how to do it). The biggest challenge with uncertainty is making sure all of the key stakeholders are ‘on the same page’ and understand what the currently level of uncertain is, and how the project team are planning to resolve the uncertainties. In combination, these uncertainties create four basic project typologies requiring different management approaches (also discussed in WP 1072). Most residual uncertainties can be managed through risk management processes.

Uncertainty is not the same as ambiguity – at the start of the construction process for the London Olympics there was a very high level of uncertainty concerning the extent and types of contamination affecting the ground and waterways, the best techniques for removing the contaminates, and the total cost and time that would be required to complete the work. However, there was absolutely no ambiguity about the requirement to fully decontaminate and remediate the site and the waterways. As the work progressed, the uncertainties reduced, the extent of the problem was defined, the site was fully remediated and the requirement was achieved.

AmbiguityComplexity is similar to uncertainty; there is always a degree of complexity associated with the many and various stakeholder relationships in and around the project. Internal ‘politics’ can be managed, controlled and used in a positive way provided the organisations governance and internal management disciplines are effective. External stakeholder relationships are more difficult to control and tie into the organisation’s overall corporate social responsibilities (CSR) and public relations (PR) activities.

But this is not the way many practitioners are experiencing complexity. The Project Management Institute (PMI) has recently published its latest Pulse of the Profession® In-Depth Report: Navigating Complexity

The worrying finding is that among the organisations surveyed whose portfolios were filled with what they defined as ‘highly complex projects’, 64 percent cited ambiguity as a defining characteristic of complexity in their projects while 57 percent cited the issue of managing multiple stakeholders. I would suggest neither of these characteristics is a true measure of complexity; but that allowing either to exist to the detriment of a project is a clear indication of weak or non-existent governance.

Ambiguity generally means the people working on the project do not know what they are supposed to achieve or there are different interpretations of what is to be achieved. Given unresolved ambiguity is a guaranteed way to ensure project failure, the open governance question is why are so many organisation allowing their managers to waste money working on a ‘project’ when there is no clearly defined objective? Good governance would require the waste to be stopped until the objective of the project is defined and the associated uncertainties understood. This does not require masses of detail, but does require clarity of vision.

When JFK stated in 1961 that “the United States should set as a goal the landing a man on the moon and returning him safely to the earth by the end of the decade”; no one knew how to achieve this in any detail but there was absolutely no ambiguity associated with what had to be accomplished and when it had to be achieved. What Kennedy did was not ‘rocket science’ (that came later); what he did was to create an unambiguous objective against which all future management decisions could be judged and empower everyone to keep asking “is this decision supporting the achievement of the objective (or not)?” Being a ‘good governor’ Kennedy had sought and received assurances that the goal was achievable before issuing the challenge, but he did not try to tell his engineers and scientists how to do their work. And as the saying goes, ‘the rest is history’.

The second area of complexity, identified in the PMI report, involving diverse politics and views will in part be resolved by creating a clear vision. However, the frequently occurring ‘turf wars’ between executives are very much a symptom of poor governance and control. A well governed and disciplined management team should vigorously debate concepts at the initiation stage, but once an investment decision has been made, recognise that working against the success of the initiative is counterproductive and damages the organisation. A key aspect of governance is creating a management culture that supports the organisation in the achievement of its objectives, turf wars and destructive politics are a symptom of weak executive management and poor governance.

Within the PMI findings, the one area where genuine complexity exists is where a project (or program) has multiple external stakeholders with divergent views and expectations that are frequently ‘unreasonable’ from the project’s perspective. A typical example is the motorists who will appreciate the reduced congestion and travel times after a freeway is widened but complain about the delays caused by the road works and the environmentalists who are opposed to the whole project ‘on principle’, knowing the money would be better spent on ‘clean’ public transport upgrades. Thousands of stakeholders, hundreds of different positions, wants and needs and everyone ringing their local papers and politicians…… this is real complexity.

In these situations there are no easy options, the only way to minimise the damage is carefully planned and implemented stakeholder engagement strategies that combine traditional communication options with more sophisticated corporate social responsibility (CR) and public relations (PR) initiatives. This is hard work and never 100% successful but essential to minimising the effect of complexity and to contribute to achieving a successful project outcome. The Stakeholder Circle® has been designed to provide the data management and analysis needed for this type of heavy duty stakeholder engagement.

The limitations of root cause analysis

Learning lessons from projects is not as simple as you may think! Projects are complex adaptive systems linking people, processes and technology – in this environment, useful answers are rarely simple.

Certainly when things go wrong stakeholders, almost by default, want a simple explanation of the problem which tends to lead to a search for the ‘root cause’. There are numerous techniques to assist in the process including Ishikawa (fishbone) diagrams that look at cause and effect; and Toyota’s ‘Five Whys’ technique which asserts that by asking ‘Why?’ five times, successively, can you delve into a problem deeply enough to understand the ultimate root cause. The chart below outlines a ‘Five Whys’ analysis of the most common paint defect (‘orange peel’ is an uneven finish that looks like the surface of an orange):

These are valuable techniques for understanding the root cause of a problem in simple systems (for more on the processes see WP1085, Root Cause Analysis); however,  in complex systems a different paradigm exists.

Failures in complex socio-technical systems such as a project teams do not have a single root cause. And the assumption that for each specific failure (or success), there is a single unifying event that triggers a chain of other events that leads to the outcome is a myth that deserves to be busted! For more on complexity and complex systems see: A Simple View of ‘Complexity’ in Project Management.

Complex system failures typically emerge from a confluence of conditions and occurrences (elements) that are usually associated with the pursuit of success, but in a particular combination, are able to trigger failure instead. Each element is necessary but they are only jointly sufficient to cause the failure when combined in a specific sequence. Therefore in order to learn from the failure (or success), an approach is needed that considers that:

  • …complex systems involve not only technology but organisational (social, cultural) influences, and those deserve equal (if not more) attention in investigation.
  • …fundamentally surprising results come from behaviours that are emergent. This means they can and do come from components interacting in ways that cannot be predicted.
  • …nonlinear behaviours should be expected. A small change in starting conditions can result in catastrophically large and cascading failures.
  • …human performance and variability are not intrinsically coupled with causes. Terms like ‘situational awareness’ or ‘lack of training’ are blunt concepts that can mask the reasons why it made sense for someone to act in a way that they did with regards to a contributing cause of a failure.
  • …diversity of components and complexity in a system can augment the resilience of a system, not simply bring about vulnerabilities.

This is a far more difficult undertaking that recognises complex systems have emergent behaviours, not resultant ones. There are several systemic accident models available including Hollnagel’s FRAM, Leveson’s STAMP that can help build a practical approach for learning lessons effectively (you can Google these if you are interested…..)

In the meantime, the next time you read or hear a report with a singular root cause, alarms should go off, particularly if the root cause is ‘human error’. If there is only a single root cause, someone has not dug deep enough! But beware; the desire for a simple wrong answer is deeply rooted. The tendency to look for singular root causes comes from the tenets of reductionism that are the basis of Newton physics, scientific management and project management (for more on this see: The Origins of Modern Project Management).

Certainly starting with the outcome and working backwards towards an originally triggering event along a linear chain feels intuitive and the process derives a simple answer that validates our innate hindsight and outcome bias (see WP1069 – The innate effect of Bias). However the requirement for a single answer tends to ignore surrounding circumstances in favour of a cherry-picked list of events and it tends to focus too much on individual components and not enough on the interconnectedness of components Emergent behaviours are driven by the interconnections and most complex system failures are emergent.

This assumption that each presenting symptom has only one cause that can be defined as an answer to the ‘why?’ is the fundamental weakness within a reductionist approach used in the ‘Five Whys’ chart above. The simple answer to each ‘why’ question may not reveal the several jointly sufficient causes that in combination explain the symptom. More sophisticated approached are needed such as the example below dealing with a business problem:

The complexity of the fifth ‘why’ in the table above can be crafted into a lesson that can be learned and implemented to minimise problems in the future but it is not a simple!

The process of gathering ‘lessons learned’ has just got a lot more complex.

Defining Complex Projects

There has been a lot written about ‘complex project management’ over the last few years much of which as confused projects with programs, complexity with big and complexity with complicated technology. For an overview of complexity theory see: A Simple View of ‘Complexity’ in Project Management.

A sentence in the paper ‘Translation and Convergence in Projects: An Organisational Perspective on Project Success’ (Project Management Journal, Sept.2011) triggered this post and sums up project complexity nicely: “The key difficulty with complex projects is that those managing them will often be ‘feeling their way’ towards a solution rather then following a reliable blueprint or project plan”.

Our view has consistently been that complexity is a function of complexity theory and it is a dimension of every project and program. This means every project has a degree of complexity in the same way that it has a defined size, a degree of technical difficulty and a degree of uncertainty, and all 4 dimensions interact and affect each other. These four dimensions are discussed in the Mosaic White Paper at: http://www.mosaicprojects.com.au/WhitePapers/WP1072_Project_Size.pdf.

What the thought from the paper above highlighted is the very close linkage between complexity which we see as being primarily a function of the project’s stakeholder community and the degree of uncertainty associated with the project outcome. Our blog post, Projects aren’t projects – Typology outlines one way of measuring uncertainty based on a model by Eddie Obeng.

I’m not sure how to measure this empirically yet, but I do have a feeling there is a need to define a measurement system that incorporates the type of uncertainty within the overall matrix of stakeholder engagement and supportiveness already embedded in the Stakeholder Circle® methodology – any thoughts will be appreciated.

See our earlier posts on Complexity.

If it can go wrong……

One derivative of Murphy’s Law is: If it can go wrong it will go wrong, usually at the most inconvenient moment!

Planning the assault

This post may be old news to many European’s but in November 2009, the 27-kilometer (16.8 mile) Large Hadron Collider (LHC), buried under fields on the French/Swiss border, suffered serious overheating in several sections after a small piece of baguette landed in a piece of equipment above the accelerator ring. Dr Mike Lamont, the LHC’s Machine Coordinator, said that “a bit of baguette”, believed to have been dropped by a passing bird (other sources suggest a malicious pigeon), caused the superconducting magnets to heat up from 1.9 Kelvin (-271.1C) to around 8 Kelvin (-265C), close to the level where they stop superconducting.

In theory, had the LHC been fully operational, this could cause a catastrophic breakdown similar to the one that occurred shortly after it was first switched on. Fortunately, the machine has several fail-safes which would have shut it down before the temperature rose too high.

Part of the LHC

Given the total cost of the project to build and commission the accelerator is of the order of 4.6 billion Swiss francs (approx. $4400M, €3100M, or £2800M as of Jan 2010) with an overall budget of 9 billion US dollars (approx. €6300M or £5600M as of Jan 2010), making the LHC is the most expensive scientific experiment in human history. Politicians are probably asking how a bungling bird could target a critical part of the machine with a small piece of bread and shut the whole system down?

A more realistic question for project practitioners is how could design engineers and risk managers be expected to foresee this type of problem? Failure Mode Analysis (FMA) may help but I can just see the reaction to someone in a risk workshop hypothesising that a bird would fly over the machine and drop its dinner precisely on target to cause the maximum damage. Theoretically possible, but hardly plausible would be a polite reaction……until after it happened.

One of the messages from books like ‘The Black Swan’ and from complexity theory  is the future is inherently unpredictable. This is probably as good an example of a ‘Black Swan’ as any I’ve heard of.

For more on the LHC see: http://en.wikipedia.org/wiki/Large_Hadron_Collider

Complex Decision Making Explained

Complex decision making is a vital project management skill; required not only by the project manager but also by the project’s sponsor and client / customer among others.

Some of the key areas involving complex decisions include risk management, many aspects of planning (particularly optimising choices) and dealing effectively with issues and problems in a range of areas from scope and quality to cost and performance.

There is an underlaying assumption in project management (derived from traditional scientific management) that decisions will be based on a rational assessment of the situation to optimise outcomes. Unfortunately this is not true! As complexity increases assuming a ‘rational decision making paradigm’ becomes increasingly unrealistic. Human decision makers become ‘predictably irrational’.

Understanding the built in biases and ‘predictable irrational’ decision making processes used by people confronted with complex decisions can help managers requiring optimised decisions to craft strategies to minimise suboptimal outcomes. But where can busy project managers access this information?

I have just finished reading the most amazing paper on the subject that canvases the whole spectrum from risk aversion to behavioural economics in a practical, easy to read format; and it is free!

Behavioural economics and complex decision making: implications for the Australian tax and transfer system has been written by Andrew Reeson and Simon Dunsttall of the Australian national science agency, CSIRO. The report was commissioned by the ‘Henry Review’ into the Australian taxation system and is published on their web site. Whilst you can safely skip the last section which focuses on applying the knowledge to our tax system. The preceding 7 sections are focused on how people make complex decisions in any sphere and are just as relevant to complex project decisions as to complex investment and taxation decisions.

You can download this free resource from the review panel’s website: download the paper (a copy is also on the Mosaic web site on the assumption the Government site is temporary and will close once the Henry Review has reported: download from Mosaic).

If you find the report useful and you don’t live in Australia, you can buy the next Australian you meet a beer; it was his or her taxes that paid for this amazingly useful report. I know I will be keeping my copy handy for a very long time to come.