Project complexity


Project complexity is the property of a project which makes it difficult to understand, foresee, and keep under control its overall behavior, even when given reasonably complete information about the project system.
With a lens of systems thinking, project complexity can be defined as an intricate arrangement of the varied interrelated parts in which the elements can change and evolve constantly with an effect on the project objectives. The identification of complex projects is specifically important to multi-project engineering environments.
The domain was introduced by D. Baccarini in 1996.

Types of complexity

Complexity can be:
  • Structural complexity, i.e. consisting of many varied interrelated parts. It is typically expressed in terms of size, variety, and interdependence of project components, and described by technological and organizational factors.
  • Dynamic complexity, which refers to phenomena, characteristics, and manifestations such as ambiguity, uncertainty, propagation, emergence, and chaos.
Based on the Cynefin framework developed by Dave Snowden, complex projects can be classified as:
  • Simple projects, systems, or contexts. These are characterized by known knowns, stability, clear cause-and-effect relationships. They can be solved with standard operating procedures and best practices.
  • Complicated: characterized by known unknowns. A complicated system is the sum of its parts. In principle, it can be deconstructed into smaller simpler components. While difficult, complicated problems are theoretically solvable with additional resources, with specialized expertise, with analytical, reductionist, simplification, decomposition techniques, with scenario planning, and following good practices.
  • Complex: characterized by unknown unknowns, and emergence. Patterns could be uncovered, but they are not obvious. A complex system can be described by Euclid’s statement that the whole is more than the sum of its parts.
  • Really complex projects, a.k.a. very complex, or chaotic: characterized by unknowables. No patterns are discernible in really complex projects. Causes and effects are unclear even in retrospect. Paraphrasing Aristotle, a really complex system is different from the sum of its parts.
Project complexity has different components and sources, including the product ; as well as the organization, its processes; the surrounding legal, ethical, and regulatory environment; stakeholder complexity and their objectives; market complexity. Thus, when operating in a complex organization, or when developing a complex product, it is likely that the project itself will encounter phenomena related to dynamic complexity.

Project complexity management

The IT-PCM project complexity management framework proposed by Stefan Morcov consists of 5 processes:
  1. Plan IT project complexity management: the process of red-flagging complex projects, and deciding on management strategies and tools.
  2. Identify IT project complexity: the process of determining what elements of complexity characterize the project. It has as objective the detection, inventory, and description of the problem.
  3. Analyze IT project complexity: the process of analyzing and prioritizing the project complexity elements and characteristics. This step is concerned with understanding the problem.
  4. Plan IT project complexity response strategy: the process of developing options and actions to enhance and use Positive Complexity, and to reduce or avoid Negative Complexity. This step involves modeling and design of potential solutions.
  5. Monitor and Control IT project complexity: the process of implementing response strategies, monitoring, controlling, and evaluating the overall effectiveness. It is a continuous activity.
The typical response strategies are:
  • Create, enhance, use - if the effects are positive.
  • Accept: for Positive, Appropriate, or Negative complexity.
  • Avoid/ eliminate, simplify /reduce: for Negative Complexity.

    Positive, appropriate (requisite), and negative complexity

Similarly with the Law of requisite variety and The law of requisite complexity, project complexity is sometimes required in order for the project to reach its objectives, and sometimes it has beneficial outcomes. Based on the effects of complexity, Stefan Morcov proposed its classification as Positive, Appropriate, or Negative.
  • Positive complexity is the complexity that adds value to the project, and whose contribution to project success outweighs the associated negative consequences.
  • Negative complexity is the complexity that hinders project success.
The concepts of Appropriate and Positive Complexity are similar to opportunities in risk management, and to antifragility in vulnerability management as introduced by Nassim Nicholas Taleb.