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

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

Complexity and its nature plays an important role in the area of project management. Despite a number of debates on this subject matter, studies suggest that there is still a lack of definition and reasonable understanding of complexity in relation to management of complex projects.[4][5]

As it is considered that project complexity and project performance are closely related, it is important to define and measure complexity of the project for project management to be effective.[6]

Types of complexity

Complexity can be:

  • Structural complexity (also known as detail complexity, or complicatedness), i.e. consisting of many varied interrelated parts.[7] 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]

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

Simple, complicated, complex, and really complex projects - based on the Cynefin framework.
  • 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.[9][10]
  • 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.[11]

By applying the discovery in measuring work complexity described in Requisite Organization and Stratified Systems Theory, Dr Elliott Jaques classifies projects and project work (stages, tasks) into basic 7 levels of project complexity based on such criteria as time-span of discretion and complexity of a project's output:[12][13]

  • Level 1 Project – improve the direct output of an activity (quantity, quality, time) within a business process with targeted completion time up to 3 months.
  • Level 2 Project – develop and improve compliance to a business process with targeted completion time from 3 months to 1 year.
  • Level 3 Project – develop, change, and improve a business process with targeted completion time from 1 to 2 years.
  • Level 4 Project – develop, change, and improve a functional system with targeted completion time from 2 to 5 years.
  • Level 5 Project – develop, change, and improve a group of functional systems / business function with targeted completion time from 5 to 10 years.
  • Level 6 Project – develop, change, and improve a whole single value chain of a company with targeted completion time from 10 to 20 years.
  • Level 7 Project – develop, change, and improve multiple value chains of a company with target completion time from 20 to 50 years.[14]

Benefits from measuring Project Complexity is to improve project people feasibility by:[15]

  • Match the level of a project's complexity with effective targeted completion time of a project
  • Match the level of a project's complexity with the respective capability level of the project manager
  • Match the level of a project task's complexity with the respective capability of the project members

Positive, appropriate (requisite), and negative complexity
The Positive, Appropriate and Negative complexity model proposed by Stefan Morcov [16]

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.[17][16]

  • Positive complexity is the complexity that adds value to the project, and whose contribution to project success outweighs the associated negative consequences.
  • Appropriate (or requisite) complexity is the complexity that is needed for the project to reach its objectives, or whose contribution to project success balances the negative effects, or the cost of mitigation outweighs negative manifestations.
  • 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

References
  1. Marle, Franck; Vidal, Ludovic‐Alexandre (2016). Managing Complex, High Risk Projects - A Guide to Basic and Advanced Project Management. London: Springer-Verlag.
  2. 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.
  3. 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.
  4. Abdou, Saed M; Yong, Kuan; Othman, Mohammed (2016). "Project Complexity Influence on Project management performance – The Malaysian perspective". MATEC Web of Conferences. 66: 00065. doi:10.1051/matecconf/20166600065. ISSN 2261-236X.
  5. Morcov, Stefan; Pintelon, Liliane; Kusters, Rob J. (2020). "Definitions, characteristics and measures of IT Project Complexity - a Systematic Literature Review" (PDF). International Journal of Information Systems and Project Management. 8 (2): 5–21. doi:10.12821/ijispm080201.
  6. Vidal, Ludovic-Alexandre; Marle, Franck (2008). "Understanding project complexity: implications on project management" (PDF). Kybernetes. 37 (8): 1094–1110. doi:10.1108/03684920810884928.
  7. 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.
  8. Snowden, David J.; Boone, Mary E. (2007). "A Leader's Framework for Decision Making". Harvard Business Review. 85 (11): 68–76.CS1 maint: multiple names: authors list (link)
  9. Maurer, Maik (2017). Complexity Management in Engineering Design – a Primer. Berlin, Heidelberg: Springer.
  10. 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.CS1 maint: multiple names: authors list (link)
  11. 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
  12. G., Morris, Peter W. (1994). The management of projects. London: T. Telford. p. 317. ISBN 978-0727725936. OCLC 30437274.
  13. Gower handbook of people in project management. Lock, Dennis., Scott, Lindsay, 1974-. Farnham, Surrey: Gower Publishing. 2013. p. 398. ISBN 978-1409437857. OCLC 855019788.CS1 maint: others (link)
  14. "PMOs". www.theprojectmanager.co.za. Retrieved 2018-03-01.
  15. Commission, Australian Public Service. "APS framework for optimal management structures". Retrieved 2018-03-01.
  17. 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.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.