Complexity
Volume 2018 (2018), Article ID 6058480, 19 pages
https://doi.org/10.1155/2018/6058480

Research Article

Measuring the Project Management Complexity: The Case of Information Technology Projects

Rocio Poveda-Bautista,¹ Jose-Antonio Diego-Mas,² and Diego Leon-Medina³

¹Institute of Innovation and Knowledge Management (INGENIO) (CSIC-UPV), Universitat Politècnica de València, Camino de Vera s/n, 46022 Valencia, Spain
²Institute for Research and Innovation in Bioengineering (I3B), Universitat Politècnica de València, Camino de Vera s/n, 46022 Valencia, Spain
³Departamento de Proyectos de Ingeniería, Universitat Politècnica de València, Camino de Vera s/n, 46022 Valencia, Spain

Correspondence should be addressed to Rocio Poveda-Bautista; ropobau@upvnet.upv.es

Received 27 October 2017; Accepted 27 February 2018; Published 13 May 2018

Academic Editor: José Ramón San Cristóbal Mateo

Copyright © 2018 Rocio Poveda-Bautista et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract.

Complex projects require specific project management (PM) competences development. However, while no complex projects have standards that are recognized to guide their management, complex projects do not have guides to deal with their complexity. To lead complex projects to success, this complexity must be measured quantitatively and, in our opinion, project management complexity assessment should be based on existing PM standards. In this work, the main project complexity assessment approaches based on PM standards are analyzed, observing that International Project Management Association (IPMA) approach is the closest to a tool that can be used as a complexity quantitative measurement system. On the other hand, several authors have shown that the inherent complexity of specific kind of projects must be measured in a particular way. The main objective of this research is to propose a project management complexity assessment tool for IT projects, providing a Complexity Index that measures the impact that complexity factors inherent to IT projects have under a specific complexity scenario. The tool combines the use of complexity factors defined by IPMA approach and the use of complexity factors found in the literature to manage inherent complexity of IT projects. All these factors were validated by expert survey and the tool was applied to a study case.

1. Introduction

Although complexity theory was applied to project management in the 90s, the discipline of complexity project management was unofficially launched at the 20th International Project Management Association World Congress in Shanghai [1]. Following Bosch-Rekveldt et al. [2] who argue that specific complexities in projects might require specific competence development, inherent complexity within projects must be studied in a particular way. In this sense, it is worth highlighting what Williams [3] pointed out, which indicates the increase in the complexity of projects as one of the main causes of project failure.

In 1991, Bennett [4] already noted the need for an exceptional level of management in complex projects, as well as the inadequacy of the implementation of conventional management systems developed for noncomplex or moderately complex projects in complex projects. As Shenhar [5] noted, different types of projects require different managerial approaches.

What does complexity means in project management? A complete review has been recently published which summarizes the development of this concept and the factors that affect project management complexity [6]. Some other authors have developed similar work prior to this one [7, 8].

Many studies and definitions have been developed on complexity; however, most of these studies focus only on the conceptual framework of project complexity and few of such studies have focused on projects complexity measurement systems. Moving a step beyond the definition of a conceptual framework of project complexity, the works of some authors have suggested factors that affect the complexity in projects, such as Geraldi et al. [7], Bosch-Rekveld et al. [8], and Chapman [9], which are based on a systematic review of the literature, Vidal and Marle [10] that proposed a complexity-driven approach of project management to assist project management in decision making defining a complexity-based criteria, and Ireland et al. [11] that classified projects (simple, complicated, and complex projects types A, B, and C) according their complexity and taking into account the systems of systems view. These last ones proposed different leadership styles and management tools for each type of project.

These studies mentioned above have focused on identifying project complexity factors and have built a framework that describes project complexity qualitatively [12, 13]. Despite the fact that several authors have focused on measuring project complexity quantitatively [13, 14], besides this and in our point of view, these project management complexity assessment systems should be based on existing project management (PM) standards to ensure implementation of recognized competencies and practices in managing complex projects. While no complex projects have standards supported by various bodies of knowledge (BoK), Project Management Institute (PMI), International Project Management Association (IPMA), and the Association for Project Management (APM), complex projects do not yet have a BoK to guide their development. However, some of these standards try to evaluate projects in order to assess their complexity and to look at project managers’ competence development in the view of complexity. These standards capture the different perspectives on complexity and encompass factors that contribute to project complexity considering different approaches.

The objective of this research is to propose a project management complexity assessment tool in Information Technology (IT) projects based on an adequate existing PM standard in order to measure the specific complexity in the management of this type of projects. To such end, the present work is developed following the following sections: in Section 2, we shall study the main project complexity assessment approaches based on PM standards as well as the complexity in IT projects, and the methodology followed to develop a tool for assessing the complexity of IT project management will be presented. In Section 3 the proposal of an IT project management complexity assessment tool is presented and in Section 4 this tool is applied to a study case. Finally, in Section 5, the conclusions and limitation of this study are shown.

2. Materials and Methods

2.1. Project Complexity Assessment Approaches Based on PM Standards

(i) PMI Approach. It focuses on structural complexity and uncertainty issues.

This approach is based on two main perspectives about structural complexity proposed by Baccarini [36], organizational complexity and technological complexity, and the perspective proposed by Turner and Cochrane [37] that considered uncertainty of objectives and uncertainty of methods used to achieve the projects goals as important factors of project complexity. Wood and Ashton [38] proposed a similar complete framework. Later Bosch-Rekveld et al. [8] added environmental complexity to Baccarini proposal giving rise to their TOE (technological, organizational, and environmental) framework and, in a similar way, Geraldi el al. [7] highlight structural complexity, uncertainty, and sociopolitical elements. Williams [39] complemented this complexity definition with other main aspects of complexity: the number and interdependence of elements and the uncertainty in goals and means. Dunović et al. [40] consider constrains as a third primary element of a new model of complexity, in addition to structural complexity and uncertainty.

Other works such as [5, 41–43] that focus their research on structural complexity and uncertainty can be integrated in the PMI approach.

From the perspective of structural complexity and uncertainty, Project Management Institute [44] published Navigating Complexity: A Practice Guide as a proposal providing guidelines to project managers in order to perform a check of the status of the project assessment in terms of complexity. Through a questionnaire for which the answer is affirmative or negative a scenario of complexity in which the project is located can be implied.

(ii) IPMA Approach. It is based on Crawford-Ishikura Factor Table for Evaluating Roles and focused on measures of competence development in complex project management by the project manager through complexity factors.

The first standard measurement tool for complexity in project management was developed by the Global Alliance for Project Performance Standards (GAPPS) whose approach characterises projects based on the management of their complexity. The framework developed by GAPPS used a tool called Crawford-Ishikura Factor Table for Evaluating Roles (CIFTER). This tool is used to differentiate project manager roles based on the complexity of managed projects. The development of such standard was carried out by members of the GAPSS [45]. CIFTER identifies seven factors that affect complexity project management.

As an assessment model of complexity project management, IPMA has developed an implementation guide for the assessment criteria, which transfers and adapts the CIFTER model to objectively demonstrate the degree of competence of project managers in complexity project management. Such adaptation was made under ICRG (IPMA Certification and Regulations Guidelines) [15]. The model suggests ten factors for the assessment of complexity.

Table 1 shows the different factors with the description and the criteria taken into account for the IPMA project management complexity assessment.

Table 1: IPMA Complexity assessment System for IPMA B (IPMA 4-L-C) [15].

Criteria
Description of the criteria
High Complexity
Low Complexity

(1) Objectives, Assessment of Results
Mandate and Objective
uncertain, vague
defined, obvious

Conflicting objectives
many conflicts
few conflicts

Transparency of mandate and objectives
hidden
quite transparent

Interdependence of objectives
very interdependent
quite independent

Number and assessment of results
large, multidimensional
low, monodimensional

(2) Interested Parties, Integration
Interested parties, lobbies
numerous parties
few parties

Categories of stakeholders
many different
few uniform categories

Stakeholder interrelations
unknown relations
few and well known relations

Interests of involved parties
divergent interests
comparable interest

(3) Cultural and social context
Diversity of context
diverse
homogeneous

Cultural variety
multicutural, unknown
uniform, well known

Geographic distances
distant, distributed
close, concentrated

Social span
large, demanding
small, easy to handle

(4) Degree of innovation, general conditions
Technological degree of innovation
unknown technology
known and proven technology

Demand of creativity
innovative approach
repetitive approach

Scope for development
large
limited

Significance on public agenda
large public interest
public interest low

(5) Project structure, demand for coordination
Structures to be coordinated
numerous structures
few structures

Demand of coordination
demanding, elaborate
simple, straighforward

Structuring of phases
overlapping, simultaneous
sequential

Demand for reporting
multidimensional, comprehensive
uni-dimensional, common

(6) Project organisation
Number of interfaces
many
few

Demand for communication
indirect, demanding, manifold
direct, not demanding, uniform

Hierarchical structure
multidimensional, matrix structure
uni-dimensional, simple

Relations with permanent organisations
intensive mutual relations
few relations

(7) Leadership, teamwork, decisions
Number of sub-ordinates
many, large control span
few, small control span

Team structure
dynamic team structure
static team structure

Leadersship style
adaptive and variable
constant and uniform

Decision-making processes
many important desicions
few important decisions

(8) Resources incl. finance
Availability of people, material, etc.
uncertain, changing
available, known

Financial resources
many investors and kinds of resources
one investor and few kinds of resources

Capital investment
large (relative to project of the same kind)
low (relative to project of the same kind)

Quantity and diversity of staff
high
low

(9) Risk and opportunities
Predictability of risks and opportunities
low, uncertain
high, quite certain

Risk probability, significance of impacts
high risk potential, large impact
low risk potential, low impact

Potential of opportunities
limited options for actions
many options for actions

Options for action to minimise risks
large potential of opportunities
low potential of opportunities

(10) PM methods, tools and techniques
Variety of methods and tools applied
numerous, manifold
few, simple

Application of standards
few common standards applicable
common standards applicable

Availability of support
no support available
much support available

Proportion of PM to total project work
high percentage
low percentage

This scheme is used to assess the project management complexity. Each indicator is rated according to four levels of complexity: very high complexity (4), high complexity (3), low complexity (2), and very low complexity (1).

On the other hand, the Association for Project Management (APM) considers, in the Registered Project Professional Candidate Guidance [46], that a project is considered “complex project” if it was highly rated in the following indicators/criteria (not in priority order): objectives, assessment of results, interested parties, integration, cultural and social context, degree of innovation, general conditions, project structure, demand for coordination, project organization, leadership, teamwork, decisions resources (including finance), risks (threats and opportunities), and project management methods, tools, and techniques. APM provides a project complexity questionnaire to help project managers to know if they are working on projects considered complex. It may therefore be stated that APM follows an approach similar to that of IPMA, and its assessment of complexity is performed following the same procedure.

(iii) The Complex Project Manager Competency Standards Approach. The International Centre for Complex Project Management of Australian Government develops in 2012 the Complex Project Manager Competency Standards [47]. This standard defines a methodology for the assessment of complexity and classification of projects based on their complexity and provides tools to categorize projects by their types of systems, determine the strategy and appropriate contracts for the project, and select competent project managers.

This approach is not without criticism, since it is a standard that, on the one hand, has not satisfactorily established any measure to assess complexity and, on the other, has been used as a requirement for project managers to establish contracts and subcontracts with the Australian government [1].

2.2. Complexity in IT Projects

As we have progressed in the study of complexity in projects several existing project management standards have been recognizing the need for an exceptional level of management in complex projects. In the same way, there is a need for specific competence development in specific complexities in projects. In this sense, several authors have developed measurement methods of project complexity taking into account different frameworks in specifics kinds of projects, such as large engineering projects [8], large infrastructure projects [48], construction projects [49], and design projects [50]. However, there are no reported researches that focused on the conceptualization of the IT project complexity construct and studies have not been found to deepen the complexity of the Information Technology (IT) industry.

While any industry is exposed to project failure, IT industry shows being more vulnerable to risk and failure than other industries. A number of areas related to project risk management and project failure provide useful study bases to define IT project complexity.

Thera are many studies around IT projects; however the years of experience of Standish Group developing the CHAOS report are known. As mentioned in the Standish Group CHAOS Report [20] made on 50000 IT projects, over 20% of projects failed or were cancelled. This report shows that large projects have less chance of success than small ones. On the other hand, agile or iterative development projects have more chance of success in comparison with waterfall or incremental projects. The first are those whose requirements and solutions evolve over time according to the need of the project. The last ones are those that sequentially follow the phases and deliverables of the project.

Other studies on IT projects go a step further by doing a root cause analysis and identifying factors which can be attributed to failure of IT projects [21, 30, 51]. Some of these factors are characteristic of observed tendencies in project with high extent of complexity. Project managers and researchers have attributed IT projects unsuccessful to the complexity of such projects [21] and propose the use of agile organizations and reduce the complexity to achieve success in IT projects.

After a systematic review of the literature, Table 2 summarizes the factors inherent to the complexity of IT projects, specific to IT sector, and different from the complexity factors used by standard tools to assess any other type of projects. These factors have been extracted from studies on project failure characteristics, abandonment factors, risk factors, and project factors that affect IT development projects. Then, these factors were grouped according to the IPMA project management complexity assessment criteria that best define them.

Table 2: IT Projects Complexity factors (literature review).

Group of factors
Factors
References

Objectives, requirements and expectations
Clear statements of requirements
[16–22]

Realistic expectations
[20, 20–24]

Clear strategic objectives
[18–20, 25]

Uncertain and changing regulatory requirements
[16–20, 23]

Interested Parties, Integration
User involvement
[17, 18, 20, 21, 24, 26]

Executive management support
[18–20, 23–25]

Project Sponsor Committed with project methodology
[18, 19, 23, 27, 28]

Leadership, teamwork, decisions
Team motivated by the project
[17, 18, 26, 29]

Hard Working, focused staff
[17, 18, 20, 26, 29]

Near shore/off shore teams involved
[17, 18, 26, 29]

Offshore/near shore teams are familiar with technical and business aspects of project
[17, 18, 24, 26, 29]

PM methods, tools and techniques
Incremental or iterative methodology used in the project
[24, 30]

Technology
Incompetence on using/applying Technology
[20, 23]

New Technologies
[18, 20, 21, 26, 28, 31, 32]

IT Management Support
[20, 24]

Technology Illiteracy
[18, 20, 26, 28, 31, 32]

Infrastructure, Telecommunication Constraints
[23, 24, 33–35]

As conclusions of the literature review, it is important to mention that one of the main factors that affects the success of IT projects is related to the user involvement in project development. On the other hand, an adequate sponsorship of the executive management is also important. Another critical factor is requirements; most projects usually begin with a clear vision and objectives, but sometimes the requirements of IT projects are based on product iterations; therefore it is imperative to increase realistic expectations of project stakeholders to ensure project success.

Resources and skills are key factors in the success of the project as well as how new technologies work when applied (sometimes technologies are not mature enough to be implemented).

Several studies confirm that iterative and agile methods (project life cycles) have more success than traditional approaches. Therefore, the methodology used on project management must be present on any assessment of project complexity.

2.3. Methodology

From all the approaches used by the different recognized standards in project management, IPMA approach is the closest to a tool that can be used as a complexity quantitative measurement system, since it defines factors and suggests a measurement scale to measure the degree to which these factors affect the management complexity of the project. While it is part of the project manager certification system, this tool is useful for measuring complexity in projects as it attempts to confirm that the project manager is capable of managing complex projects.

For the purpose of our study, a framework for IT project management complexity assessment is designed. This framework has as baseline the IPMA project management complexity assessment, adding or removing (if necessary) some complexity factors in order to build an assessment template for IT projects. The proposed factors to be included on the assessment of IT project complexity were extracted considering the literature review carried out in section before and taking into account the fact that IPMA complexity factors do not focus exclusively on the scope of IT projects but cover a wider range of projects.

To propose an assessment template in order to build a tool that measures IT project complexity taking into account the inherent complexity of these projects, first, some IT complexity factors that are not covered by IPMA assessment will be added to the baseline IPMA assessment knowledge and, then, this template was validated by experts. This tool was called Complexity Index tool because it will allow measuring the complexity level of a project at one point under a scenario of concrete project complexity.

This proposal was validated with a survey fulfilled by experts. The selection of the experts was an important issue. We were looking for IT specialists with deep experience working in IT projects: IT chiefs technology officer, IT project/program managers, project team members, end users, and practitioners with enough expertise and knowledge on IT sector. These experts were involved in the survey under the below channels: personal contact and social networks.

2.3.1. Selection of IT Project Management Complexity Factors

We considered all the factors found in the literature as relevant factors in the complexity of IT projects (see Table 2), since all these factors were identified by several authors as inherent to the complexity of these projects. All of them were included in the template developed to design the complexity assessment tool (see columns 1 and 2 of Table 2).

2.3.2. Survey Design

The objective of the survey was to ask the experts to identify the main complexity factors that affect IT development projects. The sections below will describe more in detail the structure of the questions and their objectives.

Experts Profile Questions. These questions were designed to know the experts’ profile: industrial sector of the IT practitioner, years of experience working on IT projects, and professional profile.

Questions Related to Complexity Groups. Questions were raised about complexity groups, to find out those which were considered by experts as the ones which impacted the most the complexity of the project.

The complexity groups were assessed using a 5-point Likert type scale.

Questions Related to Complexity Factors within Each Group. The experts were asked about the groups in which new complexity factors were added. These are objectives, requirements and expectations, interested parties and integration, leadership, teamwork and decisions, PM methods, tools and techniques, and technology.

We considered that the other groups of complexity factors should be part of the tool since these are composed of complexity factors that affect any type of project.

Therefore, questions related to complexity factors are, all, based on allowing practitioner to rank the factors within their complexity group and discard them if required. These questions were used to find out which of these factors contributed most to the complexity within its group (relative complexity).

The complexity factors were assessed using a 5-point Likert type scale.

2.3.3. Survey Results

Of the total number of people that accessed the survey, 13 were not fully completed, so there were 37 responses in the end. Of these 50 responses, it was necessary to eliminate the thirteen partial answers since the study must be done with comparable items.

52% of the responses were answered from Spain, 22% from Colombia, 6% from United States, and 19% from more than 9 different countries.

Profile of the Respondents. Most of the practitioners are from technology, banking, and financial services sectors (see Figure 1).

Figure 1: Profile of the respondents. Industrial sector (%).

According to the results shown in Figure 2, more than 50% of the respondents had more than 10 years of experience working on IT projects, and almost the one-third part had at least 5–10 years. Only 1 respondent had 0 years of experience working on IT projects, since it was an end user, the answer was considered valid for the study. The results in terms of level of expertise suggest that the experts were well qualified.

Figure 2: Profile of the respondents. Years of experience (%).

According to the results shown in Figure 3, about 57% of the respondents had management profiles. The remaining percentage of experts is part of projects with a more technical and business oriented role. After screening the profiles, we selected all the experts to participate in the survey.

Figure 3: Professional profile of the respondents (%).

Complexity Factors Results. In this part, the specific survey questions related to complexity factors were analyzed. Through a brief analysis and taking as an example some answers from the survey (see Tables 3, 4, and 5), the impact of the new complexity groups/factors added was studied.

Table 3: Complexity groups, importance in IT projects.

1
2
3
4
5
Average
Total
Responses

Objectives, Requirements, Expectations
3 
8.11%
2 
5.41%
2 
5.41%
5 
13.51%
25 
67.57%
4.27
37

Interested Parties, Integration
1 
2.70%
1 
2.70%
7 
18.92%
12 
32.43%
16 
43.24%
4.11
37

Cultural and social context
3 
8.11%
3 
8.11%
22 
59.46%
8 
21.62%
1 
2.70%
3.03
37

Degree of innovation, general conditions
1 
2.70%
5 
13.51%
12 
32.43%
15 
40.54%
4 
10.81%
3.43
37

Project structure, demand for coordination
3 
8.11%
3 
8.11%
7 
18.92%
19 
51.35%
5 
13.51%
3.54
37

Project organisation
4 
10.81%
3 
8.11%
5 
13.51%
14 
37.84%
11 
29.73%
3.68
37

Leadership, teamwork, decisions
3 
8.11%
3 
8.11%
3 
8.11%
15 
40.54%
13 
35.14%
3.86
37

Resources incl. finance
2 
5.41%
3 
8.11%
12 
32.43%
9 
24.32%
11 
29.73%
3.65
37

Risk and opportunities
1 
2.70%
2 
5.41%
9 
24.32%
17 
45.95%
8 
21.62%
3.78
37

PM methods, tools and techniques
3 
8.11%
6 
16.22%
12 
32.43%
10 
27.03%
6 
16.22%
3.27
37

Technology
2 
5.41%
6 
16.22%
13 
35.14%
9 
24.32%
7 
18.92%
3.35
37

Table 4: Factors within Objectives, Requirements and Expectations, relative complexity ranking.

1
2
3
4
5
Does not apply
Average
Total Responses

Mandate and objective uncertain, vague
1 
2.70%
0 
0.00%
4 
10.81%
15 
40.54%
16 
43.24%
1 
2.70%
4.25
37

Many conflicting objectives
1 
2.70%
5 
13.51%
4 
10.81%
17 
45.95%
8 
21.62%
2 
5.41%
3.74
37

Hidden mandate and objectives
0 
0.00%
1 
2.70%
5 
13.51%
19 
51.35%
11 
29.73%
1 
2.70%
4.11
37

Very interdependent objectives
0 
0.00%
6 
16.22%
13 
35.14%
9 
24.32%
8 
21.62%
1 
2.70%
3.53
37

Large number of objectives and multidimensional assessment of results
1 
2.70%
4 
10.81%
12 
32.43%
13 
35.14%
6 
16.22%
1 
2.70%
3.53
37

Unclear requirements
1 
2.70%
3 
8.11%
1 
2.70%
7 
18.92%
25 
67.57%
0 
0.00%
4.41
37

Expectations unlikely to be achieved
0 
0.00%
2 
5.41%
6 
16.22%
15 
40.54%
11 
29.73%
3 
8.11%
4.03
37

Strategic Objectives (organizational) uncertain, vague
0 
0.00%
0 
0.00%
10 
27.03%
18 
48.65%
8 
21.62%
1 
2.70%
3.94
37

Uncertain and changing regulatory Requirements
2 
5.41%
1 
2.70%
8 
21.62%
12 
32.43%
11 
29.73%
3 
8.11%
3.85
37

Table 5: Factors within Technology, relative complexity ranking.

1
2
3
4
5
Does not apply
Average
Total Reponses

Incompetence on using/applying Technology
1 
2.70%
3 
8.11%
6 
16.22%
10 
27.03%
16 
43.24%
1 
2.70%
4.03
37

Too many new technologies in place
1 
2.70%
9 
24.32%
9 
24.32%
15 
40.54%
3 
8.11%
0 
0.00%
3.27
37

No IT management support
2 
5.41%
1 
2.70%
7 
18.92%
15 
40.54%
12 
32.43%
0 
0.00%
3.92
37

Stakeholders technology illiteracy
1 
2.70%
4 
10.81%
16 
43.24%
11 
29.73%
5 
13.51%
0 
0.00%
3.41
37

Many Infrastructure, Telecommunication Constraints
1 
2.70%
4 
10.81%
12 
32.43%
17 
45.95%
3 
8.11%
0 
0.00%
3.46
37

Table 3 shows the information of the percentages of the total of the answers and the average column that was used to compare between complexity groups. These average ratings showed the relative importance of each complexity group to the experts.

Then, a survey’s example of the questions related to complexity groups is shown.

Questions (groups of factors). “Please rank each complexity group from 1 (the least complex group of factors) to 5 (the most complex group of factors) considering its impact on IT projects.”

Table 6 summarizes the average ratings of each complexity group (rating range from “1, the least complex factor,” to “5, the most complex factor”).

Table 6: Summary of Questions related to complexity groups.

Complexity
Average

Objectives, Requirements, Expectations
4.27

Interested Parties, Integration
4.11

Leadership, teamwork, decisions
3.86

Risk and opportunities
3.78

Project organization
3.68

Resources incl. finance
3.65

Project structure, demand for coordination
3.54

Degree of innovation, general conditions
3.43

Technology
3.35

PM methods, tools and techniques
3.27

Cultural and social context
3.03

Similar analysis was made within each complexity group in order to classify the factors that make up each group. A survey’s example of the complexity group “objectives, requirements, and expectations” is shown in order to clarify the procedure applied in the survey to validate the proposal.

Questions (factors of complexity group “objectives, requirements, and expectations”). “Please rank each complexity factor from 1 (the least complex factor) to 5 (the most complex factor) considering its impact on IT projects. Please mark ‘Does not apply’ if you think that this factor it is not applicable to IT projects.”

Moreover, the results of the survey obtained for the new IT complexity group “Technology” are shown in Table 5 in order to know the relevance of its factors in comparison with factors of other complexity groups.

Most of the new IT complexity factors suggested are in the first half of the relative complexity ranking. As shown in the analysis of survey results, there are no factors considered out of the scope of the Complexity Index tool. The maximum value of the responses indicating that this factor does not apply was close to 10%, which is not considered by the researchers sufficient to remove them from the tool.

Table 7 shows together all the factors studied in the survey and ranked by level of complexity.

Table 7: Summary of Questions related to complexity factors within each group.

Order
Relative Complexity of Complexity Factors
Average

(1)
Unclear requirements
4.41

(2)
Mandate and objective uncertain, vague
4.25

(3)
User uncommitted with the project
4.19

(4)
Hidden mandate and objectives
4.11

(5)
Dispersed team, not focused
4.05

(6)
Expectations unlikely to be achieved
4.03

(7)
Executive management uncommitted with the project
4.03

(8)
Incompetence on using/applying Technology
4.03

(9)
Little motivation of the project team
3.95

(10)
Strategic Objectives (organizational) uncertain, vague
3.94

(11)
No IT management support
3.92

(12)
Numerous interested parties and lobbies
3.91

(13)
Offshore/Near shore teams are not familiar with technical and business aspects
3.91

(14)
Uncertain and changing regulatory Requirements
3.85

(15)
Divergent interest of involved parties
3.78

(16)
Many conflicting objectives
3.74

(17)
Unknown stakeholders interrelations
3.71

(18)
Sponsor uncommitted with project methodology
3.64

(19)
No assistance to project management available
3.57

(20)
Numerous/manifold, variety of methods and tools applied
3.56

(21)
Very interdependent objectives
3.53

(22)
Large number of objectives and multidimensional assessment of results
3.53

(23)
Many Infrastructure, Telecommunication Constraints
3.46

(24)
Few common standards applicable
3.44

(25)
Stakeholders technology illiteracy
3.41

(26)
Many different categories of stakeholders
3.36

(27)
Dynamic team structure
3.34

(28)
High percentage/proportion of PM work from total project work
3.33

(29)
Too many new technologies in place
3.27

(30)
Many sub-ordinates, large control span
3.19

(31)
Totally Iterative methodology used
3.19

(32)
Many important decisions in place
3.15

(33)
Adaptive and variable leadership style
3.14

(34)
Offshore teams/Near shore teams involved
2.91

In Table 7 the new IT complexity factors proposed are shown in italics.

From the results obtained in the survey it can be concluded that all factor groups and all factors within each group should be included in the complexity measurement tool, since the experts thought that they are factors that affect the complexity of IT projects.

3. The Complexity Index Tool in IT Project Management Complexity Assessment: Description, Interface, and Functionality

This section describes the tool and the functionality that is provided.

The tool was designed taking into account all the new complexity factors extracted from the literature and validated by experts. A table with all the factors to be included in the assessment tool is presented as shownin Table 8.

Table 8: Complexity Index tool Draft.

Criteria
Description of the criteria
Low Complexity
High Complexity

(1) Objectives, Requirements and Expectations
Mandate and Objective
defined, obvious
uncertain, vague

Conflicting objectives
few conflicts
many conflicts

Transparency of mandate and objectives
quite transparent
hidden

Interdependence of objectives
quite independent
very interdependent

Number and assessment of results
low, monodimensional
large, multidimensional

Clear Statement of Requirements
Requirements perfectly clear
Unclear requirements

Realistic Expectations
Easily achievable
Expectations unlikely to be achieved

Clear Strategic Objectives (organizational)
defined, obvious
uncertain, vague

Uncertain and changing regulatory Requirements
available, known
uncertain, changing

(2) Interested Parties, Integration
Interested parties, lobbies
few parties
numerous parties

Categories of stakeholders
few uniform categories
many different

Stakeholder interrelations
few and well known relations
unknown relations

Interests of involved parties
comparable interest
divergent interests

User Involvement
User available and committed to the project
User uncommitted wth the project

Executive Management Support
Executive management committed to the project
Executive management uncommitted to the project

Project Sponsor committed with project methodology
Sponsor committed with project methodology
Sponsor uncommitted with project methodology

(3) Cultural and social context
Diversity of context
homogeneous
diverse

Cultural variety
uniform, well known
multicultural, unknown

Geographic distances
close, concentrated
distant, distributed

Social span
small, easy to handle
large, demanding

(4) Degree of innovation, general conditions
Technological degree of innovation
known and proven technology
unknown technology

Demand of creativity
repetitive approach
innovative approach

Scope for development
limited
large

Significance on public agenda
public interest low
large public interest

(5) Project structure, demand for coordination
Structures to be coordinated
few structures
numerous structures

Demand of coordination
simple, straightforward
demanding, elaborate

Structuring of phases
sequential
overlapping, simultaneous

Demand for reporting
uni-dimensional, common
multidimensional, comprehensive

(6) Project organisation
Number of interfaces
few
many

Demand for communication
direct, not demanding, uniform
indirect, demanding, manifold

Hierarchical structure
uni-dimensional, simple
multidimensional, matrix structure

Relations with permanent organisations
few relations
intensive mutual relations

(7) Leadership, teamwork, decisions
Number of sub-ordinates
few, small control span
many, large control span

Team structure
static team structure
dynamic team structure

Leadership style
constant and uniform
adaptive and variable

Decision-making processes
few important decisions
many important decisions

Team motivated by the project
Highly Motivated
Little motivation

Hard-Working, Focused Staff
Focused team
Dispersed team

Near shore/Offshore teams involved
Domestic teams
Offshore teams/Near shore teams involved

Offshore/Near shore teams are familiar with technical and business aspects of project
Good know how in offshore/near shore teams
Teams unfamiliar with business/Technical aspects of the project

(8) Resources incl. finance
Availability of people, material, etc.
available, known
uncertain, changing

Financial resources
one investor and few kinds of resources
many investors and kinds of resources

Capital investment
low (relative to project of the same kind)
large (relative to project of the same kind)

Quantity and diversity of staff
low
high

(9) Risk and opportunities
Predictability of risks and opportunities
high, quite certain
low, uncertain

Risk probability, significance of impacts
low risk potential, low impact
high risk potential, large impact

Potential of opportunities
many options for actions
limited options for actions

Options for action to minimise risks
low potential of opportunities
large potential of opportunities

(10) PM methods, tools and techniques
Variety of methods and tools applied
few, simple
numerous, manifold

Application of standards
common standards applicable
few common standards applicable

Availability of support
much support available
no support available

Proportion of PM to total project work
low percentage
high percentage

Incremental or iterative methodology used in the project
Totally Incremental Methodology used
Totally Iterative methodology used

(11) Technology
Incompetence on using/applying Technology
Technological competence in all of the project chain links
Technological Incompetence in any of the project chain links

New Technologies
Well known technologies used
Too many new technologies in place

IT Management Support
Full IT Management support
No IT management support

Technology Illiteracy
Stakeholders technology literacy
Stakeholders technology illiteracy

Infrastructure, Telecommunication Constraints
Few
Many

Table 8 gathers “low complexity” and “high complexity” values for each factor. Please note that “high complexity” value is the one used to formulate the survey questions (see Tables 4 and 5).

The next step to develop was how to really measure the complexity based on the items shown in Table 8. IPMA complexity assessment considers a project complex if the measure of complexity reaches a complexity level of 62,5%.

Following IPMA framework, complexity is measured against that of similar projects in the singular professional environment of the project manager, scoring each complexity factor. IPMA claims that a project can be considered complex when the average of the assessments’ score of the 10 groups of complexity factors that make up the general assessment tool is higher than 2.5. This value was chosen because it is between low complexity (2) and high complexity (3) (see Section 2.1). Thus, the minimum score obtained for the evaluation of any project considered complex should be 25. This supposes 62.5% of the maximum value of the complexity measurement. This maximum value would be 40 if all the factors that contribute to the project’s complexity are assessed with the highest score (4) [52].

Therefore, the Complexity Index tool is based on the same score to define the Complexity Index. The new tool is focusing on the measure of the complexity of IT projects including new specific factors in calculation of the Complexity Index.

Complexity Index tool is based on the complexity groups and factors validated by the experts as a result of the survey (see Table 8).

The interface of the designed tool is shown in Figure 4.

Figure 4: Complexity Index tool interface.

The template proposes assessing the complexity groups according to the 4 defined levels of complexity, considering the level of complexity of the factors that make up each group. The sum of the normalized values of each complexity group provides the final score of complexity of the project under evaluation.

The next section will describe the functionality of the tool for the complexity group assessment.

3.1. Complexity Group Assessment Functionality

The example shown in Figure 5 shows how a user of the tool can measure the complexity of a particular complexity group.

Figure 5: Complexity group functional description.

The numbers in Figure 5 colored in green indicate the fields described below:

 Field type: meaning(1)Read only: complexity group description(2)Read only: criteria (complexity factors) within the complexity group(3)Read only: 4 levels of complexity from very low to very high(4)Read only: description of what represents a very low value(5)Read only: description of what represents a very high value(6)User input field: user field to rank complexity of a group(7)User input bar: another option to slip within the rank of complexity measure(8)Read only: graph of the complexity group.

3.2. Assessment Result

The bottom part of the interface’s tool shows a graph which provides to the user the result of the assessment (Complexity Index score), advising finally if the project under evaluation is complex or the practitioner has skills to drive complex projects.

Figure 6 is an example of the assessment result.

Figure 6: Complexity Index tool assessment result graph.

At the same time that the user changes the values of the assessment of any complexity group, the graph will reflect the new Complexity Index value.

4. Study Case

In order to validate the tool, it was applied to assess the complexity of an IT project.

This study case is divided into two parts; the first one is the description of the taxonomy of the IT project with the objective of understanding what is the starting point of the assessment. The duration of the project was two years; thus two scenarios were considered: 2015 scenario and 2016 scenario (slight differences between these will be recognized in Section 4.1.1).

The second part is the application of the Complexity Index tool to the project in 2015 and 2016 status. The assessment was performed by the project manager of this project during these 2 years, who led this project towards success despite the complex environment.

4.1. Project Overview

The project analyzed in the study case is a software development project in a banking sector company, with maintenance and support operations. The project could be described as a consolidation layer of information from external systems, which will adjust the data to a predefined standard format, in order to report risk measures to downstream systems.

The project is part of a wholesale banking system and customers are all over the world. Different suppliers are subcontracted to handle different aspects of the project.

The project organization chart is shown in Figure 7.

Figure 7: Project organization chart.

Locations. Human resources and the three main suppliers of the project were allocated in 5 countries. Project management was located in United Kingdom.

Stakeholders. From the point of view of the main stakeholders of the project, we could describe its infrastructure as a synthesis of 36 upstream systems and 4 support systems that provide reference data and another 10 downstream systems to which risk measures need to be reported. On the other hand, there were audit systems reviewing the project; therefore, some ad hoc audit teams asked for new requirements.

It is important to mention that each system is an external team, with its own organization chart. In many cases, these organizations are working with offshore teams. Therefore, communication matrix between stakeholders is not easy to build.

Figure 8 provides a brief overview of the project relationships and dependencies within stakeholders’ information flows.

Figure 8: Data flow and external stakeholders.

Constraints

(i)Communication issues: very complex communication matrix(ii)Cross-national cultural and legal differences(iii)High rotation of team members(iv)Slow learning curve due to the amount of components of the project

4.1.1. Differences between 2015 and 2016

In 2016, some downstream systems were integrated into the project; therefore, deliverables were more complex. By the end of 2015, there was an initiative to move some tasks of the project to offshore teams. Afterwards, there was a transition phase and knowledge transfer to work with them.

4.2. Complexity Index Methodology: A Case of Study Applied to a Software Project

The Complexity Index tool was applied to the study case assessing the complexity of this IT project. In this section, the profile of the project manager was explained and then the results obtained comparing 2015 assessment with 2016 assessment were exposed.

The project manager who assessed the complexity of the project has more than 15 years working on IT projects. He has Ph.D. in chemistry and is PMI-certified. He is an IT professional with consulting experience and he worked as industry leader across public and private sectors, including managing multimillion budgets and complex program organizations. He was contacted by email and how the Complexity Index tool works but without any interference on performing the assessment was explained to him. His responses were impartial about the project complexity.

4.2.1. 2015 Project Complexity Assessment Results

Figure 9 shows the result of IT project manager’s assessment of the project in 2015.

Figure 9: 2015 project assessment with Complexity Index tool.

According to the project manager’s assessment, we can observe the following.

Very High Complexity Groups. Most of the complexity highlighted by the expert is in “project organization” due to the number of interfaces the project had, the communication demand, and the hierarchical structure of the project and the teams.

In addition, the other group that contributed to the complexity was the “cultural and social context.” As mentioned in the project description, the great diversity of the project context, together with the cultural variety of the teams involved, local teams and near shore and offshore teams working together, as well as geographical distances of teams, made this group very complex.

High Complexity Groups. Two groups had high complexity; the first one was “interested parties, integration” of the project, which highlighted the variety of stakeholders and interrelationships that were present in the project.

The second group was “leadership, teamwork, and decisions” that reflected the adaptive leadership style required to adequately drive dynamic structures of the teams that were built depending on the level of requirements.

Figure 10 shows the 2015 assessment results.

Figure 10: Study case Complexity Index score for 2015.

Complexity Index score was 56,82%. Therefore, according to the definition of the Complexity Index tool, the project cannot be considered complex. As a reminder, the minimum defined is 62,5%.

4.2.2. 2016 Project Complexity Assessment Results

Figure 11 shows the result of IT project manager’s assessment of the project in 2016.

Figure 11: 2016 project assessment with Complexity Index tool.

According to the project manager’s assessment, we can observe the following.

Very High Complexity Groups. The groups assessed with a very high level of complexity were the same as those in the 2015 project complexity assessment.

High Complexity Groups. The groups assessed with a very high level of complexity were the same as those in the 2015 project complexity assessment. However, there was one new group under this complexity level: “objectives, requirements, and expectations”; since the project expands in scope, with the inclusion of downstream systems as part of the project, it was more difficult to manage this group in 2016. More stakeholders also meant that project expectations were slightly changed. On the other hand, strategic expectations about changes in scope were increasing pressure on the project by top management.

Figure 12 shows the 2016 assessment results.

Figure 12: Study case Complexity Index score for 2016.

Complexity Index score was 63,64%; therefore project can be considered as complex.

Subsequently, the results were presented to the project manager so that he may express his qualitative opinion on the complexity of the project and, thus, analyze the level of agreement with the results obtained from the implementation of the tool. The project manager expressed his agreement with these results in general terms, since he acknowledged an increase in complexity in 2016 that forced him to implement complex project management competences.

5. Discussion and Limitations

The present work describes a new tool, based on IPMA approach, to assess IT project management complexity in an efficient and reliable way. It includes complexity factors adapted to this particular industrial sector since it is considered that the development of projects in this sector is more prone to failure than in other sectors, due to the complexity of its projects. The tool combines the use of complexity factors defined by IPMA approach to measure complexity of any kind of project and revised following a systematic literature review and the use of new complexity factors found in the literature to manage inherent complexity of IT projects. The use of all these factors were validated by IT experts by means of a questionnaire. The experts were chosen according to their experience and knowledge of IT industrial sector. The use of IPMA approach can be justified by its ability to obtain quantitative scores of project management complexity.

The tool allows obtaining a Complexity Index that measures the level of global impact that the complexity factors inherent to IT projects have on the project, under a specific complexity scenario. For its validation the tool was applied to a software development project in a banking sector company.

With the implementation of the tool to the case study it can be observed that, by increasing the assessment of some factors towards greater complexity, the Complexity Index increased and the overall percentage in which the project could be considered complex could be measured.

On the other hand, the project manager in charge of the project acknowledged greater complexity in 2016 and expressed, through a satisfaction survey with the tool, his agreement that the rate of increase in the percentage reflected the increase in complexity that the project had suffered. The expert also showed agreement and satisfaction with the project complexity assessment process. In addition, he acknowledged that, in this second year, he had had to manage project situations in complex contexts due to a greater number of downstream systems that were integrated into the project, increasing deliverables complexity and including offshore teams.

The weighting of complexity groups of factors provides some important insights into the overall philosophy and underlying project manager conception of how complex the study case project is. Of all the new specific complexity factors for IT projects, added to the IPMA framework, “project organization,” “cultural and social context,” “interested parties, integration,” “leadership, teamwork, and decisions,” and “objectives, requirements, and expectations” are those that have contributed the most to a greater increase in complexity. These factors represent, overall, a 63.64% contribution to the complexity of the project against 62.5% of the minimum index in which a project is considered complex.

Regarding the results obtained by the scores of the project complexity assessment, each of them, obtained during different periods of the same project, showed how high their complexity degree was with respect to the other complexity scenario. It allowed comparing project complexity in 2015 with project complexity in 2015.

Based on the review of the literature and the findings of the present study, we can conclude that it is not so important for an organization to measure all particular factors in a project complexity assessment system since it may become a difficult process; by contrast, it is relevant for any organization to know key complexity areas (groups of complexity) and their metrics (factors) as well as their corresponding weights that directly contribute to the complexity of the project.

On the other hand, an organization would benefit from the use of the Complexity Index tool by applying it in project portfolio prioritization. To implement the methodology in this case would consist of one-to-one calculation of the Complexity Index of each project within a portfolio. Thereby, the focus is placed on the most complex projects or the most complex areas and main project complexity sources. These are the ones where more complexity related project management competences are needed. These assessments should be done in the most complex scenario of each project so that the cost/time of implementing it in a project portfolio is not excessive and the comparison is conclusive. In this sense, a risk-benefit analysis in the evaluation of the project portfolio could be used as additional information source when implementing the Complexity Index tool in project portfolio. In this way, the assessment of each project within a portfolio could be carried out only in cases where the overall risk (technological-commercial)/benefit (economic-strategic) balance is below a threshold value since the rest of the projects could be discarded. Projects that have not passed the risk-benefit analysis filter would obtain a high expected Complexity Index (the higher the risk, the greater the complexity of the project), but their evaluation would no longer be necessary since they would have been discarded, thus reducing the cost/time of the implementation of the methodology.

The main objective of the methodology used for the development of the tool was the validation of an already verified approach in the professional use of the complexity assessment of several projects across different sectors, since it has been used in project manager certification systems for many years in order to demonstrate their ability to lead complex projects. This validation was firstly performed through a systematic review of the literature and, secondly, through an expert survey in IT project management. This survey only aimed to validate the adequacy of all these factors (IPMA approach factors and new factors found in the literature for IT projects) to find out whether they should be included in a tool that measures the complexity of IT projects. Therefore, the purpose of the survey used in the methodology was not to find a statistical significance of the results but a threshold value from which each factor should be included in the tool or, below which, it should not be included. Thus, the statistical analysis performed to process the results of the survey is merely descriptive and uses the mean value as threshold value.

Conflicts of Interest

There are no conflicts of interest.

References

S. J. Whitty and H. Maylor, “And then came complex project management (revised),” International Journal of Project Management, vol. 27, no. 3, pp. 304–310, 2009.

C. Bosch-Rekveldt, M. Mooi, H. Verbraeck, A. Sjoer, E. Wolsing, and B. Gulden, “Mapping project managers competences to project complexity,” in IPMA 23rd WorldCongress, Research Track Human Side of Projects in Modern Business, 2009.

T. Williams, “Assessing and moving on from the dominant project management discourse in the light of project overruns,” IEEE Transactions on Engineering Management, vol. 52, no. 4, pp. 497–508, 2005.

J. Bennett, International Construction Project Management: General Theory and Practice, Oxford, 1991.

A. J. Shenhar, “One size does not fit all projects: exploring classical contingency domains,” Management Science, vol. 47, no. 3, pp. 394–414, 2001.

A. Bakhshi, J. Ireland, and V. Gorod, “Clarifying the project complexity construct: Past, present and future,” International Journal of Project Management, vol. 34, no. 7, pp. 1199–1213, 2016.

J. Geraldi, H. Maylor, and T. Williams, “Now, let's make it really complex (complicated): A systematic review of the complexities of projects,” International Journal of Operations and Production Management, vol. 31, no. 9, pp. 966–990, 2011.

A. Bosch-Rekveld, M. Jongkind, Y. Mooi, H. Bakker, and H. Verbraeck, “Grasping project complexity in large engineering projects: The TOE (Technical, Organizational and Environmental) framework,” International Journal of Project Management, vol. 29, no. 6, pp. 728–739, 2011.

R. J. Chapman, “A framework for examining the dimensions and characteristics of complexity inherent within rail megaprojects,” International Journal of Project Management, vol. 34, no. 6, pp. 937–956, 2016.

L. Vidal and F. Marle, “Understanding project complexity: implications on project management,” Kybernetes, vol. 37, no. 8, pp. 1094–1110, 2008.

V. Ireland, B. Rapaport, and A. Omarova, “Addressing wicked problems in a range of project types,” Procedia Comput. Sci, vol. 12, pp. 49–55, 2012.

D. Owens, J. Ahn, J. Shane, J. Strong, and K. C. Gransberg, “Defining Complex Project Management of Large U.S,” Transportation Projects, vol. 17, no. 2, pp. 170–188, 2012.

B. Xia and A. P. C. Chan, “Measuring complexity for building projects: A Delphi study,” Engineering, Construction and Architectural Management, vol. 19, no. 1, pp. 7–24, 2012.

S. Sinha, B. Kumar, and A. Thomson, “Complexity measurement of a project activity,” International Journal of Industrial and Systems Engineering, vol. 8, no. 4, pp. 432–448, 2011.

I. AEIPRO, NCB-Bases para la Competencia en Dirección de Proyectos, 2006.

R. N. Charette, Software Engineering Risk Analysis and Management, Intertext Publications, New York, NY, USA, 1989.

S. Sakthivel, “Managing risk in offshore systems development,” Communications of the ACM, vol. 50, no. 4, pp. 69–75, 2007.

R. Schmidt, K. Lyytinen, M. Keil, and P. Cule, “Identifying software project risks: An international Delphi study,” Journal of Management Information Systems, vol. 17, no. 4, pp. 5–36, 2001.

M. H. A. Tafti, “Risks factors associated with offshore IT outsourcing,” Industrial Management & Data Systems, vol. 105, no. 5, pp. 549–560, 2013.

Standish Group, The Chaos Report, M. A. Dennis, Ed., Standish Group International, Inc., 2015.

J. P. Murray, “Reducing IT project complexity,” Information Strategy: The Executive's Journal, vol. 16, no. 3, pp. 30–38, 2000.

K. Lyytinen, R. Hirschheim, and R. Hirschheim Paper, “Lyytinen K and Hirschheim R Paper 1987.pdf,” Oxford Surveys in Information Technology, vol. 4, pp. 257–309, 1987.

K. Ewusi-Mensah, Software development failures anatomy of abandoned projects, 2003.

R. T. Nakatsu and C. L. Iacovou, “A comparative study of important risk factors involved in offshore and domestic outsourcing of software development projects: A two-panel Delphi study,” Information and Management, vol. 46, no. 1, pp. 57–68, 2009.

S. L. Jarvenpaa and B. Ives, Executive Involvement and Participation in The Management of Information Technology, vol. 15, Management Information Systems Research Center, 1991.

L. Wallace, M. Keil, and A. Rai, “Understanding software project risk: A cluster analysis,” Information and Management, vol. 42, no. 1, pp. 115–125, 2004.

B. Bahli and S. Rivard, “The information technology outsourcing risk: a transaction cost and agency theory-based perspective,” Journal of Information Technology, vol. 18, no. 3, pp. 211–221, 2003.

H. Taylor, “Critical risks in outsourced it projects: The intractable and the unforeseen,” Communications of the ACM, vol. 49, no. 11, pp. 75–79, 2006.

F. P. Brooks, “Essence and accidents of software engineering,” Computer (Long. Beach. Calif), vol. 20, no. 4, pp. 10–19, 1987.

K. M. Whitney and C. B. Daniels, “The root cause of failure in complex it projects: complexity itself,” Procedia Computer Science, vol. 20, pp. 325–330, 2013.

M. J. Earl, “The Risk of Outsourcing IT,” MIT Sloan Management Review, vol. 37, no. 3, pp. 26–32, 1996.

C. F. Kemerer and G. L. Sosa, “Systems development risks in strategic information systems,” Information and Software Technology, vol. 33, no. 3, pp. 212–223, 1991.

B. W. Boehm, “Software risk management: principles and practices,” IEEE, vol. 8, no. 1, pp. 32–41, 1991.

C. A. Brown, “The opt-in/opt-out feature in a multi-stage delphi method study,” International Journal of Social Research Methodology, vol. 10, no. 2, pp. 135–144, 2007.

R. Kliem, “Managing the risks of offshore It development projects,” Information Systems Management, vol. 21, no. 3, pp. 22–27, 2004.

D. Baccarini, “The concept of project complexity a review,” International Journal of Project Management, vol. 14, no. 4, pp. 201–204, 1996.

J. R. Turner and R. A. Cochrane, “Goals-and-methods matrix: coping with projects with ill defined goals and/or methods of achieving them,” International Journal of Project Management, vol. 11, no. 2, pp. 93–102, 1993.

H. L. Wood and P. Ashton, “The factors of project complexity,” in Proceedings of the CIB World Building Congress, pp. 69–80, Salford, UK, 2010.

T. M. Williams, “The need for new paradigms for complex projects,” International Journal of Project Management, vol. 17, no. 5, pp. 269–273, 1999.

K. A. Dunović, I. B. Radujković, and M. Škreb, “Towards a new model of complexitythe case,” Procedia-Social and Behavioral Sciences, vol. 119, pp. 730–738, 2014.

P. Austin, S. Newton, A. Steele, and J. Waskett, “Modelling and managing project complexity,” International Journal of Project Management, vol. 20, no. 3, pp. 191–198, 2002.

M. V. Tatikonda and S. R. Rosenthal, “Technology novelty, project complexity, and product development project execution success: A deeper look at task uncertainty in product innovation,” Heating, Piping, and Air Conditioning, vol. 72, no. 2, pp. 74–87, 2000.

T. Little, “Context-adaptive agility: Managing complexity and uncertainty,” IEEE Software, vol. 22, no. 3, pp. 28–35, 2005.

Project Management Institute, “Navigating Complexity: A Practice Guide,” 2014.

A. Aitken and L. Crawford, “A study of project categorisation based on project management complexity,” in Proceedings of the International Research Network for Organizing by Projects Conference (IRNOP VIII), Brighton, United Kingdom, 2007.

S. Seeman, “River Protection Project (RPP) Project Management Plan,” Association for Project Management Registered Project Professional – RPP Candidate Guidance RPP – the standard for extraordinary project professionals from the Association for Project Management 2 APM Registered Project Professional – RPP Candidate Guidan, 2015.

Australian Government, Complex Project Manager Competency Standards, vol. 1, 2012.

D. Lessard, V. Sakhrani, and R. Miller, “House of Project Complexity—understanding complexity in large infrastructure projects,” Engineering Project Organization Journal, vol. 4, no. 4, pp. 170–192, 2014.

R. M. Lebcir and J. Choudrie, “A Dynamic Model of the Effects of Project Complexity on Time to Complete Construction Projects,” International Journal of Innovation, Management and Technology, vol. 2, no. 6, p. 477, 2011.

K. Shafiei-Monfared and S. Jenab, “A novel approach for complexity measure analysis in design projects,” Journal of Engineering Design, vol. 23, no. 3, pp. 185–194, 2012.

T. O. A. Lehtinen, M. V. Mäntylä, J. Vanhanen, J. Itkonen, and C. Lassenius, “Perceived causes of software project failures - An analysis of their relationships,” Information and Software Technology, vol. 56, no. 6, pp. 623–643, 2014.

J. Alba, D. Cron, M. El Ouarti, G. Pugliese, W. Schmehr, and L. Simonelli, “IPMA International Certification and Regulations for the Assessment of Individuals in Project, Programme and Portfolio Management,” in Proceedings of the International Project Management Association, Zurich, Switzerland, 2016.