Medecins Sans Frontieres Doctors Without Borders

Join the PM.com.au Community

Project Manager

Australia's online resource for project management professionals


Is project complexity an excuse for bad management?

The Project Management Institute’s ‘Pulse of the Profession In-Depth Report: Navigating Complexity’ and several other recently published reports seem to be confusing ambiguity and complexity. I would suggest this is a clear sign that complexity is poorly understood in management circles. The fundamental difference is ambiguity can be managed and controlled; complexity is an innate characteristic of the ‘project system’ and can only be influenced.

Complexity is a property of a system; in projects this includes the network of stakeholders within and around the project team influenced by factors such as structural, technical and temporal complexity. Complexity is associated with the lack of stability and emergent issues that change the dynamics of the project and its stakeholder community. Kaye Remington and Julien Pollack in their 2011 book Tools for Complex Projects suggest four primary sources of complexity:

  1. Structural complexity associated with large-scale projects and programs that have many interrelated and interdependent parts. The elements of the project can interact with each other in unpredictable and unexpected ways.
  2. 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.
  3. 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 Concorde program a well-documented historical example.
  4. 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 revised 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.

Ambiguity is discrete from complexity

Ambiguity on the other hand can be identified, measured and managed. Ambiguity, or more accurately a lack of consensus on the degree of ambiguity in a project is a factor of poor communication and/or bad management.

There’s nothing wrong with ‘going on a quest’ or for a ‘walk in the fog’ provided all of the key stakeholders understand the project is a journey of discovery. For more on these project typologies see: Projects aren’t projects—Typology.

Provided the objective is clear, journeys of discovery simply need regular reappraisals of the current plan based on what’s been learnt to date and the willingness to re-plan and refocus based on the learned experience. This type of uncertainty is normal in research project of all types.

Situations where ambiguity becomes a problem include:

  • Projects where the strategic objective is unclear, in this circumstance the ambiguity is caused by bad management wasting money and effort. Fix the management deficiencies and you remove the ambiguity. This is a different level of issue to one where a subset of stakeholders want a changed objective or different priorities, small ‘p’ politics within the stakeholder network is a source of complexity.
  • A more common cause of problems associated with ambiguity is where some stakeholders expect certainty in situations where the technical solution to the problem has not been developed. Asking for detailed schedules and fixed prices before the project team has had a chance to design the solution is asking for problems. The solution is better communication and trust.
  • Another situation frequently defined as ambiguity is where different stakeholders in positions of influence have varying expectations of the project’s outcome. Aligning expectations needs effective leadership and communication in the senior management team.

Unresolved ambiguity will lead to project failure and may influence the complexity of the relationships within the stakeholder network but as demonstrated above, ambiguity is a resolvable problem through the application of better communication, leadership and management. Complexity, on the other hand, is an innate characteristic of the system and cannot be resolved or managed, only influenced.

The worrying trend is seeing situations caused by management’s failure to manage classified as complexity (and therefore by definition unmanageable). Failing to specifying clear objectives for a project or program is a management failure. Failing to recognise uncertainty is a management failure. And failing to deal effectively with differences of opinion in the wider stakeholder community is a management failure. Management failures can be fixed, but not at the project level: these are senior management issues.

Then, once the manageable issues around ambiguity are resolved, the project team will be in a much stronger position to deal with the innate characteristics of ‘real complexity’ as they emerge through the life of the project.

Ambiguity is certainly a significant contributor to project failure, it’s very difficult to succeed if you don’t know what you have to achieve, but let’s recognise the problem for what it is!

admin
Patrick Weaver is the managing director of Mosaic Project Services and the business manager of Stakeholder Management Pty Ltd. He has been a member of both PMI and AIPM since 1986 and is a member of the Asia Pacific Forum of the Chartered Institute of Building. In addition to his work on ISO 21500, he has contributed to a range of standards developments with PMI, CIOB and AIPM.
has written 57 articles for us.

Comment



Need a Gravatar (the image next to your comments)? Visit Gravatar.com

Comments from the community

  • […] Patrick Weaver explains the difference between complexity and ambiguity.  No excuses! […]

  • […] Complexity is a property of a system; in projects this includes the network of stakeholders within and around the project team influenced by factors such as structural, technical and temporal complexity.  […]