Complex Project Management (CPM)

From apppm
(Difference between revisions)
Jump to: navigation, search
m
m
Line 16: Line 16:
  
 
= How should I approach a Complex Project? =
 
= How should I approach a Complex Project? =
=== The sources of complexity in PM ===
+
=== The sources of project complexity ===
 
The first step a practionioner should do for managing complexity is getting to know which are its sources. Projects present several aspects that should be kept in control. For each of these faces, an internal complexity can be identified. All elements belonging to one aspect are related each others and thus they can mutually influence each others. But which are these faces? As reported in the APPPM course material, the typical sources of complexity are:
 
The first step a practionioner should do for managing complexity is getting to know which are its sources. Projects present several aspects that should be kept in control. For each of these faces, an internal complexity can be identified. All elements belonging to one aspect are related each others and thus they can mutually influence each others. But which are these faces? As reported in the APPPM course material, the typical sources of complexity are:
 
*Technical/Task complexity
 
*Technical/Task complexity
Line 27: Line 27:
 
</br>
 
</br>
 
This approach to complexity results in a group of tools and startegies aiming to control the whole project. Nevertheless, as previously mentioned, complex projects are characterized by interdependencies across these aspects. Modelling all these relationships would require a substantial amount of resources, and still the output would be an approximation. Practitioners are still suggested to use all relevant tools for mapping their project, even when complex, but they need to be aware that their models will change while the project is running and thus tools and strategy should be seen as alive, in a constant state of mutation. But when my tools and strategies are not enough anymore for modelling my project? in the next paragrph we will see when we should consider our project as a complex one based on a model developed by Kathleen B. Hass in 2009.
 
This approach to complexity results in a group of tools and startegies aiming to control the whole project. Nevertheless, as previously mentioned, complex projects are characterized by interdependencies across these aspects. Modelling all these relationships would require a substantial amount of resources, and still the output would be an approximation. Practitioners are still suggested to use all relevant tools for mapping their project, even when complex, but they need to be aware that their models will change while the project is running and thus tools and strategy should be seen as alive, in a constant state of mutation. But when my tools and strategies are not enough anymore for modelling my project? in the next paragrph we will see when we should consider our project as a complex one based on a model developed by Kathleen B. Hass in 2009.
 +
 +
=== Project Complexity Model ===
 +
The Project Complexity Model has been developed by Kathleen B. Hass and presented for the first time in the book "Managing Project Complexity: A New Model" published in 2009. It has been tested with a quantitative, nonexperimental, descriptive research design on 66 project, programme or portfolio managers from 11 different industries, showing an appreciable level of reliability. </br>
 +
The model consist on a where columns identify different level of complexity and rows different project aspects. Three level of complexity are defined: high, medium and low. While, 11 rows identify 11 different project aspect, which are:
 +
*Time/Cost
 +
*Team size
 +
*Team composition and performance
 +
*Urgency and flexibility of cost, time and scope
 +
*Clarity of problem, opportunity and solution
 +
*Requirements/Volatility and risk
 +
*Strategic importance, political implocations, multiple stakeholders
 +
*Level of organizational change
 +
*Levele of commercial change
 +
*Risk, dependencies and external constraints
 +
*Level of IT complexity
 +
For each intersection cell, a serie of characteristics are listed so that practitioners can identify which level of complexity each of these areas has for their own projects. Once these atributes are identified, practitioners will use a formula table reporting which are the criterias for defining their project as higly or moderately complex, or a low risk project. The results can be displayed trough a spider-web chart. Doing this, the complexity profile of the project can be visualized and discussed by the team.

Revision as of 19:58, 20 February 2021

Contents

Abstract

The aim of this article is to introduce practitioners to the concept of Complex Project Management (CPM) and propose tools for analysing project complexity in the early stage of a project. As project become to include international stakeholders and interrelated activities, an increasing concern related to project complexity arises. Identifying sources of complexity turns to be crucial for achieving project's goals. As a matter of fact, complexity influences planning and control phases of a project, jeopardizing the three elements of the Iron Triangle (quality, cost and time). Therefore, it is crucial to define whether a project should be considered complex and why, starting from the early stage of the project life cycle. Introducing an analysis of project complexity in the initiation phase of a project helps project managers defining better goals and objectives, it guides in selecting the right resources, drives the definition of a project structure, and highlights soft spots where to strengthen control. In the last decades, the project management community has developed strategies and tools for spotting and managing these sources of complexity. Although a universal consensus on the definition of project complexity has not been yet achieved, this article guides practitioners from an introduction on the theoretical concept of complexity to widespread practical tools for analysing it in the initiation project stage.

A bit of background

What is complexity?

The concept of complexity is still not well defined by the academic community. Depending on the subject of research, different characteristics are identified and chosen to define the complexity of a specific topic. Nevertheless, several general definitions of complexity have been suggested and the researcher considers relevant reporting that one proposed by Sydney Dekker for differentiating Complicated and Complex systems. Complicated systems may be quite intricated and consist of a huge numbers of parts but they can always be taken apart and put together again. Complicated systems become complex when they are opened up to influences that lie way beyond engineering specifications and reliability predictions. Complex systems are held together by local relationships only. Each component is ignorant of the behaviour of the system as a whole and cannot know the full influences of its actions. The boundaries of what constitutes the system become fuzzy; interdependencies and interactions multiply and mushroom [Dekker et al., 2010]. From this definition it is possible to grasp some knowledge for identifying when we are dealing with a complex project but also which are the main characteristic that we should try to keep in control for avoiding complexity to grow.

The gap

In project contexts, the traditional project management paradigm assumes full pre-given knowledge about the project that is being managed. This, in accordance with the definition given above, is an approach that well fit a complicated project. In contrast to the traditional paradigm, more recent methodologies accept that not all information can be known before to start or in the initial phase of a project, pursuing a learning based approach [Terence et al., 2013]. Therefore, knowledge plays a central role for the definition of complex project. A complex project is characterized by continuously changing shape which requires to redefine goals and scope several times throughout the project life cycle. Methodologies such as Agile tried to address this problem through an iterative approach to projects. Agile project management perfectly fit the life cycle of product development (e.g. software development) since the outcome of one iteration can be accepted or declined, giving birth to a new iteration afterwards. Moreover, this technique address the issue of a changing surrounding environment that can continuously affect project goals' expectations. Nevertheless, this approach does not address the issue of complexity for project which requires a right-first-time outcome. When the goal of a project is to deliver a single outcome, such as the Eurovision Song Contest 2014 in Copenhagen, there is no space for testing and a different approach is required.

The inspiration

This article is inspired by the recent research made on the concept of Complex Project Management, specifically on the material presented during the course Advance Project, Program and Portfolio Management (APPPM) at DTU in the year 2021, a conference paper presented by Kathleen B. Hass and Lori B. Lindbergh in 2010 and two scientific paper written by Terence Ahern , Brian Leavy, P.J. Byrne and Alex Gorod, Leonie Hallo, Tiep Nguyen respectively published in 2013 and 2018. The overall goal is to point out which are the common sources of complexity in a project through the APPPM course material and address them to the project Complexity Model presented by Hass and Lindbergh. Afterwards, the main concepts of the approach explained by Ahern , Leavy and Byrne are presented and the gap on leading this complex project, mentioned in their paper, will be filled by the integrated approach of command-and-control and network governance propose by Gorod, Hallo and Nguyen. Doing this, the writer aims to enrich the practitioners, interested or involved in complex project, with practical knowledge regarding the strategies and the approach to apply on such projects.

How should I approach a Complex Project?

The sources of project complexity

The first step a practionioner should do for managing complexity is getting to know which are its sources. Projects present several aspects that should be kept in control. For each of these faces, an internal complexity can be identified. All elements belonging to one aspect are related each others and thus they can mutually influence each others. But which are these faces? As reported in the APPPM course material, the typical sources of complexity are:

  • Technical/Task complexity
  • Time complexity
  • Goal complexity
  • Social complexity
  • Organizational complexity
  • Legal complexity

From this list, we can distinguish three groups. The first one is composed of task and time complexities. For these two aspects, different tools have been developed in order to model or map them. It is possible to use Work Breakdown Structure or System mapping for modelling the project's activities or elements, while Gantt chart can be used for defining a timeline. The second group is composed of goal and legal complexities. For this group the approach is mainly strategy based. Prioritizing goals and defining the right contracts require discretionary decisions which cannnot be mapped. The decisions are made by the project manager in consensus with project stakeholders in order to satisfy stakeholders' needs. The last group can be defined as an hibrid of the first two. Social and organizational complexities include aspects that can be mapped and others that are driven by strategy. To make an example, social complexity can be model through a Stakeholder map which can be beneficial for identify people, teams, departments or businesses that can affect the project or be affected by it. On the other hand, a human resource startegy needs to be in place for defining who is responsible for what and for managing socio-cultural differences among people involved in the project. </br> This approach to complexity results in a group of tools and startegies aiming to control the whole project. Nevertheless, as previously mentioned, complex projects are characterized by interdependencies across these aspects. Modelling all these relationships would require a substantial amount of resources, and still the output would be an approximation. Practitioners are still suggested to use all relevant tools for mapping their project, even when complex, but they need to be aware that their models will change while the project is running and thus tools and strategy should be seen as alive, in a constant state of mutation. But when my tools and strategies are not enough anymore for modelling my project? in the next paragrph we will see when we should consider our project as a complex one based on a model developed by Kathleen B. Hass in 2009.

Project Complexity Model

The Project Complexity Model has been developed by Kathleen B. Hass and presented for the first time in the book "Managing Project Complexity: A New Model" published in 2009. It has been tested with a quantitative, nonexperimental, descriptive research design on 66 project, programme or portfolio managers from 11 different industries, showing an appreciable level of reliability. </br> The model consist on a where columns identify different level of complexity and rows different project aspects. Three level of complexity are defined: high, medium and low. While, 11 rows identify 11 different project aspect, which are:

  • Time/Cost
  • Team size
  • Team composition and performance
  • Urgency and flexibility of cost, time and scope
  • Clarity of problem, opportunity and solution
  • Requirements/Volatility and risk
  • Strategic importance, political implocations, multiple stakeholders
  • Level of organizational change
  • Levele of commercial change
  • Risk, dependencies and external constraints
  • Level of IT complexity

For each intersection cell, a serie of characteristics are listed so that practitioners can identify which level of complexity each of these areas has for their own projects. Once these atributes are identified, practitioners will use a formula table reporting which are the criterias for defining their project as higly or moderately complex, or a low risk project. The results can be displayed trough a spider-web chart. Doing this, the complexity profile of the project can be visualized and discussed by the team.

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox