A Tale of Two CPMs
The sources of complexity are also starting to be more clearly understood. Remington and Pollack in their 2011 book Tools for Complex Projects suggest four primary sources:
- Structural complexity associated with large-scale projects and programs that have many interrelated and interdependent parts. The 2012 Olympics was a god example where several emergent issues made headlines before the delivery team adapted to the challenges. This does not mean every large project is structurally complex (some can be very simple) but massive size is a good starting point.
- Technical complexity is associated with doing something fundamentally new, where the technology either has to be developed from scratch or no one is sure how existing technologies will be combined into the new product or system. Almost every new development in the ICT arena falls into this category to a greater or lesser extent.
- Directional complexity is caused when there is a lack of clarity or agreement among the key stakeholders on either the ultimate objective, or how to best achieve the objective. This can arise from a genuine ‘walk in the fog’ where most people can agree on the problem (for example, traffic congestion in a city) but have different ideas about the optimum solution; or from situations where different stakeholders perceive quite different problems and have quite different needs from the project: the Joint Strike Fighter is a good current example; the different objectives and needs of the French and British governments from the Concord program a well-documented historical example.
- Temporal complexity is created when the environment outside of the project undergoes a fundamental shift. The change in the environment introducing massive uncertainty and complexity into the project. Nokia’s failure to deal with the shift to smartphones leading to its sale to Microsoft is one example. The problems NBN Co will experience if the new Australian government implements its policy to downgrade the network’s capability by 75% or more to save around 20% of the build cost is potentially another. Factor in the costs associated with unpredictable complexity to the NBN equation and potentially the cost savings evaporate to $0 but the build will still only have 25% of the original design capability.
And to make matters even more complex… these different aspects of complexity interact with each other in completely unpredictable ways.
Managing complexity
Applying more process and more ‘controls’ to an uncontrollable situation compounds the lack of control. It makes the situation worse, not better!
Managing complexity requires:
- Leadership, providing the team with a sense of direction and purpose.
- Distributed decision making that encourages bounded initiative on the part of people who are confronting the problem.
- Support and training to help the team deal with uncertainty.
This is a paradigm shift in thinking and approach from the command and control approach embedded within scientific management, traditional project management and ‘old CPM’.
Many of the traditional tools including budgeting, scheduling, risk and scope management still have a role in managing complex projects, the difference in a shift away from static control tools to dynamic and flexible collaboration tools.
In conclusion, the ‘far, far better thing that [you] do, than [you] have ever done’ should be to stop expecting certainty, recognise your ‘old CPM’ is a best a representation of a desirable objective/outcome and start embracing the inevitable uncertainty associated with the complexity inherent in every project.
The question is not ‘Is my project complex?’ rather, it is ‘How much complexity will emerge today?’ and when it emerges, ‘What am I going to do to embrace and influence it?’
