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.
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.
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).
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.
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.
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 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”).
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.