Jump to content

Project complexity

Add links
From Wikipedia, the free encyclopedia

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.[1] 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.[2] The identification of complex projects is specifically important to multi-project engineering environments.[3]

The domain was introduced by D. Baccarini in 1996.[4]

Types of complexity

[edit]

Complexity can be:

  • Structural complexity (also known as detail complexity, or complicatedness), i.e. consisting of many varied interrelated parts.[5] 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.[1]
Simple, complicated, complex, and really complex projects - based on the Cynefin framework.

Based on the Cynefin framework developed by Dave Snowden,[6] complex projects can be classified as:

  • Simple (or clear, obvious, known) 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.[7][8]
  • 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.[9]

Project complexity has different components and sources, including the product (typically expressed in terms of structural or technological complexity); as well as the organization, its processes; the surrounding legal, ethical, and regulatory environment; stakeholder complexity and their (often conflicting) 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

[edit]
The IT-PCM Project Complexity Management framework

The IT-PCM project complexity management framework proposed by Stefan Morcov consists of 5 processes:[10]

  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 (exploit) - if the effects are positive (i.e. Positive Complexity).
  • Accept: for Positive, Appropriate, or Negative complexity.
  • Avoid/ eliminate, simplify /reduce: for Negative Complexity.

Positive, appropriate (requisite), and negative complexity

[edit]
The Positive, Appropriate and Negative complexity model proposed by Stefan Morcov [9]

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.[11][9]

  • 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 (requisite) and Positive Complexity are similar to opportunities in risk management, and to antifragility in vulnerability management as introduced by Nassim Nicholas Taleb.

See also

[edit]

References

[edit]
  1. ^ a b Marle, Franck; Vidal, Ludovic‐Alexandre (2016). Managing Complex, High Risk Projects - A Guide to Basic and Advanced Project Management. London: Springer-Verlag.
  2. ^ Bakhshi, Javad; Ireland, Vernon; Gorod, Alex (1 October 2016). "Clarifying the project complexity construct: Past, present and future". International Journal of Project Management. 34 (7): 1199–1213. doi:10.1016/j.ijproman.2016.06.002. S2CID 113426565.
  3. ^ Vidal, Ludovic-Alexandre; Marle, Franck; Bocquet, Jean-Claude (2011). "Measuring project complexity using the Analytic Hierarchy Process" (PDF). International Journal of Project Management. 29 (6): 718–727. doi:10.1016/j.ijproman.2010.07.005. S2CID 111186583.
  4. ^ Baccarini, David (1996). "The concept of project complexity—a review". International Journal of Project Management. 14 (4): 201–204. doi:10.1016/0263-7863(95)00093-3.
  5. ^ Baccarini, D. (1996). "The concept of project complexity, a review". International Journal of Project Management. 14 (4): 201–204. doi:10.1016/0263-7863(95)00093-3.
  6. ^ Snowden, David J.; Boone, Mary E. (2007). "A Leader's Framework for Decision Making". Harvard Business Review. 85 (11): 68–76.{{cite journal}}: CS1 maint: multiple names: authors list (link)
  7. ^ Maurer, Maik (2017). Complexity Management in Engineering Design – a Primer. Berlin, Heidelberg: Springer.
  8. ^ Kurtz, C.F.; Snowden, David J. (2003). "The new dynamics of strategy: Sense-making in a complex and complicated world". IBM Systems Journal. 42 (3): 462–483. doi:10.1147/sj.423.0462. S2CID 1571304.{{cite journal}}: CS1 maint: multiple names: authors list (link)
  9. ^ a b c Morcov, Stefan (2021). Managing Positive and Negative Complexity: Design and Validation of an IT Project Complexity Management Framework. KU Leuven University. Available at https://lirias.kuleuven.be/retrieve/637007
  10. ^ Morcov, Stefan; Pintelon, Liliane; Kusters, Rob J. (2021). "A Framework for IT Project Complexity Management". International Journal of Information Technology Project Management. IADIS IS 2021: 14th IADIS International Conference Information Systems: 61–68.
  11. ^ Morcov, Stefan; Pintelon, Liliane; Kusters, Rob J. (2020). "IT Project Complexity Management Based on Sources and Effects: Positive, Appropriate and Negative" (PDF). Proceedings of the Romanian Academy - Series A. 21 (4): 329–336.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Project_complexity&oldid=1226747708"