# Measuring Information Systems Project Complexity: A Structural Equation Modelling Approach

Authors: Nazeer Joseph; Carl Marnewick
Journal: Complexity
 (2021)

---

## Abstract

Complexity has emerged as the new norm in the 21st century, and IS projects play a significant role in organisations to address various socio-political concerns. The purpose of this paper is to understand what are the relevant constructs for measuring IS project complexity. A model for measuring IS project complexity is developed using PLS-SEM. The model reveals that organisational complexity, technical complexity, and uncertainty underpin IS project complexity. Organisational complexity in terms of project team, stakeholder management, and strategic drive should be managed by the project manager. Technical complexity was established in terms of project goals, requirements management, technology management, and norms and standards. Uncertainty in IS projects exists in terms of skills management, the triple constraint, and activity management. Suggestions were provided to guide IS project managers on how to manage each construct and alleviate the level of project complexity. This paper presents an updated and different perspective on measuring and managing IS project complexity. The findings would serve as additional building blocks to further elucidate IS project complexity understanding and assist with improving the value of these projects. Furthermore, the suggestions for IS project managers can lead discussions around how IS projects should be managed to ensure complexity is under control.


---

## Body

## 1. Introduction

The Standish Group [1] showed that between 2013 and 2017, information systems (IS) projects fluctuated between a 17% and 14% success rate in terms of high customer satisfaction and high return on value to organisations. The extant literature contends that as a key reason for this is complexity [2–5]. However, the perennial argument of poor project performance and success rates is not the only manifestation of complexity. Complexity has emerged as the new norm in the 21st century [6]. IS projects are strategic endeavours that play a significant digital transformational role to address the evolving socio-political landscape organisations operate in [7, 8]. Conceptualising and articulating IS project complexity are therefore more imperative now than ever before. IS project complexity can be argued from two perspectives.Firstly, there is a need to identify and articulate the constructs that are relevant to IS projects. McKeen et al. [9] hypothesised two constructs which could arguably be considered an over simplistic view of the current IS project environment reality. In light of this, works such as Xia and Lee [10] and Williamson [11] continued to expand on what constructs are applicable to IS project complexity. These works are however dated and required a fresh take on the concept. Joseph [12] applied a conceptual approach and assimilated the project complexity literature across multiple industries and years to create revised view of IS project complexity. While the study took a conceptual approach, it did align to the view of Bosch-Rekveldt et al. [13] that it is better to have a rich and comprehensive view to truly understand the concept.Secondly, once the constructs have been identified, it is important to understand which underlying indicators should be measured and managed to alleviate complexity. Damasiotis and Fitsilis [14] argued that IS project complexity should be measured around the PMBOK® Guide knowledge areas. This is contentious as Hällgren et al. [15] argued that the PMBOK® Guide only provides a broad base for measuring and managing project complexity. Poveda-Bautista et al. [16] addressed this by incorporating multiple project management standards and literatures to develop the measures for IS project complexity. Their drawback however was that they maintained all constructs from this assimilation and did not determine which were relevant or not.The research goal of this paper is to understand what are the relevant constructs for measuring IS project complexity. Two research objectives were developed: (i) determine the relevant constructs of IS project complexity and (ii) determine what influence the constructs have on measuring IS project complexity.


## 2. Literature Review

Geraldi [17] emphasised that “mastering complexity is not a new challenge but an old challenge that is being increasingly recognized and accepted.” Complexity science has grown in stature in recent years as it provides researchers with a means to understand and interpret the world in which we live [18]. Simon [19] defined complexity as “the number of components that interact intensively within a system.” Oehmen et al. [20] identified four distinct characteristics of complexity: (i) multiple components, (ii) multiple connections between components, (iii) dynamic interactions between components, and (iv) emergent behaviour resulting from the output of these interactions is not necessarily explained through a “simple sum of the parts” analogy. These definitions imply that component interactions within a complex system are not minor since there are extensive relationships and intricacies within these systems. Unfortunately, there is no universally accepted definition of complexity which is also evident in the project management field [21, 22].


### 2.1. Project Complexity

Significant emphasis has been placed on successfully managing projects in project management research [22]. This has led to a plethora of tools, techniques, methods, and best practices to achieve project delivery success. Projects however continue to perform poorly and fail to meet their goals and realise organisational benefits [1, 21]. The extant literature contends that a key reason for projects failing is complexity [2–5].Baccarini [23] was one of the first to conceptualise the constructs of project complexity. This initial view conceptualised project complexity around organisational and technical complexity. Williams [24] expanded on the view of Baccarini [23] and included the concept of uncertainty. Uncertainty introduces the volatile dynamic which exists in every project. Vidal and Marle [25] argued that projects are not isolated from internal and external environment effects. They assert that project complexity must also consider environmental elements as this has a direct and indirect effect on delivering a project. Geraldi et al. [26] identified the proliferation of project complexity research and conducted a systematic literature review to contextualise the state of the topic. This assimilation recognised the value of the work of Baccarini [23], Williams [24], and Vidal and Marle [25] while categorising a fundamentally new component: dynamics. Dynamics recognises the inevitable changes that emerge in projects and the importance of dedicating attention on this underrated complexity component.The reality is that while there are multiple interpretations and perceptions around project complexity, research is continuously expanding and articulating what constitutes project complexity. This has led to the development of models designed to assist the management of complexity in projects [6, 13, 22]. Geraldi and Söderlund [27] argued that research must continue to investigate new typologies and taxonomies of project complexity, especially across different industries and research communities. This will enable crosspollination and illuminate new trends emerging in the project complexity field.


### 2.2. Information Systems Project Complexity

Project complexity research has navigated various industries and project types. De Rezende et al. [28] investigated project complexity research trends from 1965 to 2015 and showed that IS project complexity research grew from the mid-90s. Despite this growth, Bakhshi et al. [29] showed that IS project complexity only represents 8% of project complexity research dated to 2015. Furthermore, Bosch-Rekveldt et al. [4] was arguably not able to fully articulate IS project complexity as these projects only represented 5.5% (8/144 projects) of their research sample.Table1 shows notable IS project complexity research by McKeen et al. [9], Ribbers and Schoo [30], Xia and Lee [10], Williamson [11], and Joseph [12]. Each study conceptualised a number of IS project complexity constructs with inherent features in each construct. Further investigation of Table 1 reveals a number of potential conclusions.Table 1
IS project complexity constructs; a concise chronological overview of project complexity constructs specific to IS projects.
AuthorConstructs (features)No. of featuresMcKeen et al. [9](i) Task complexity (6)9(ii) System complexity (3)Ribbers and Schoo [30](i) Variety (3)9(ii) Variability (4)(iii) Integration (2)Xia and Lee [10](i) Structural organisational complexity (3)15(ii) Structural IT complexity (4)(iii) Dynamic organisational complexity (5)(iv) Dynamic IT complexity (3)Williamson [11](i) Objectives (1)26(ii) Opportunity (2)(iii) Solution (2)(iv) Team (2)(v) Methodology (2)(vi) Schedule (2)(vii) Requirements (2)(viii) Environmental (6)(ix) Information technology (2)(x) Technological change (1)(xi) Organisational change (2)(xii) Staffing (1)(xiii) IT integration (1)Joseph [12](i) Organisational complexity (34)75(ii) Technical complexity (12)(iii) Environmental complexity (13)(iv) Dynamics (6)(v) Uncertainty (10)McKeen et al. [9] investigated IS project complexity in terms of task complexity (environmental complexity) and system complexity (technological complexity). While still in the infant stages of IS project complexity, this research spoke directly to the theoretical propositions of Baccarini [23] in terms of organisational and technical complexity. This IS project complexity view argues that IS project managers should be mindful of nine complexity features and manage them accordingly. This is arguably an over simplistic view of the IS project environment reality. Furthermore, this view is dated and may not include new emerge IS project complexity constructs and features.Ribbers and Schoo [30] argued IS project complexity from three different constructs: (i) variety, (ii) variability, and (iii) integration. These three constructs speak to the dynamic and ever changing nature of IS projects where multiple activities and resources are interrelated. While this three dimensional view provides a modest update to the McKeen et al. [9], Ribbers and Schoo [30] argued that IS project complexity should be managed based on nine features. One must, however, query whether it is sufficient to focus on only nine features as it is plausible that this would omit crucial IS project complexity areas.In wake of a better understanding of IS project complexity, Xia and Lee [10] and Williamson [11] explored more robust views. Xia and Lee [10] conceptualised four IS project complexity constructs spanning 15 features. Alternatively, Williamson [11] explored 13 constructs spanning 26 features. This arguably shows that as IS project complexity matured from 1994 to 2012, researchers began to explore the concept from multiple perspectives in terms of constructs and features. This corresponds to the argument made by Geraldi and Söderlund [27] to continuously investigate new typologies and taxonomies in project complexity research.Previous research has provided multiple views of IS project complexity and expanded on what it entails over the years. Bosch-Rekveldt et al. [13], however, argued that research must not oversimplify the overall concept of project complexity. Rather, a rich description of the concept is best facilitated by a comprehensive approach. Joseph [12] adopted this approach and assimilated multiple project complexity studies to generate a comprehensive view of IS project complexity. It was argued that IS project complexity is best understood by including five complexity constructs spanning 75 features. The comprehensive approach by Joseph [12] is adopted in this paper as it provides the basis for empirically validating the constructs of IS project complexity in the real world.


### 2.3. Measuring Project Complexity

A major challenge in the project complexity landscape is whether project complexity can be measured. Multiple project complexity measurement models have spawned in response to the growth of increasingly complex projects. Table2 evaluates 9 project complexity measurement models from 2003 to 2020 in multiple industries. These models can be categorised into general project management, construction and engineering, logistics as well as IS and new product development.Table 2
Project complexity measurement models; a concise chronological overview of project complexity measurement models across various industries.
AuthorIndustryConstruct (indicators)No. of indicatorsKim and Wilemon [31]New product development(i) Technological complexities (2)30(ii) Market/environmental complexities (4)(iii) Development complexities (6)(iv) Marketing complexities (8)(v) Organisational complexities (7)(vi) Intraorganisational complexities (3)Sinha et al. [32]Engineering(i) Work (4)10(ii) Time (2)(iii) Motivational (2)(iv) Social (2)Vidal et al. [33] and Vidal et al. [34]General project management(i) Project size (1)17(ii) Project variety (3)(iii) Project interdependencies (10)(iv) Elements of context (3)Tie and Bolluijt [35]General project management(i) Contextual factors (11)21(ii) Inherent factors (10)Damasiotis and Fitsilis [14]IS(i) Project integration management (3)16(ii) Project scope management (2)(iii) Project time management (2)(iv) Project cost management (3)(v) Project quality management (1)(vi) Project human resources management (1)(vii) Project communication management (1)(viii) Project risk management (1)(ix) Project procurement (2)He et al. [36]Construction(i) Technological complexity (4)28(ii) Organisational complexity (4)(iii) Goal complexity (6)(iv) Environmental complexity (5)(v) Cultural complexity (4)(vi) Information complexity (5)Lu et al. [37]Construction(i) Task complexity (11)20(ii) Organisation complexity (9)Poveda-Bautista et al. [16]IS(i) Objectives, requirements, and expectations (10)61(ii) Interested parties and integration (7)(iii) Cultural and social context (4)(iv) Degree of innovation and general conditions (4)(v) Project structure and demand for coordination (4)(vi) Project organisation (4)(vii) Leadership, teamwork, and decisions (8)(viii) Resources incl. finance (4)(ix) Risk and opportunities (4)(x) PM methods, tools, and techniques (5)(xi) Technology (7)Kermanshachi et al. [38]Construction(i) Stakeholder management (2)30(ii) Governance (2)(iii) Fiscal planning (1)(iv) Quality (1)(v) Legal (3)(vi) Interface (3)(vii) Execution target (1)(viii) Design and technology (3)(ix) Location (4)(x) Scope definition (5)(xi) Project resources (5)General project management: The models by Vidal et al. [33], Vidal et al. [34], and Tie and Bolluijt [35] standout. Vidal et al. [33] and Vidal et al. [34] argued that four complexity areas should be assessed: (i) project size, (ii) project variety, (iii) project interdependencies, and (iv) project context-dependencies. A total of 17 indicators spanned the four constructs. The project complexity measurement model applied weightings and ratings based on team member perceptions to determine a complexity index for different project types. Furthermore, they argued that a measurement model’s input should be gathered directly from project team members involved. Although this is questionably a subjective input, multiple perceptions facilitate the generation of an overall understanding of the level of project complexity.Conversely, Tie and Bolluijt [35] applied a rudimentary approach to measuring project complexity and defined two constructs: (i) contextual factors and (ii) inherent factors. The former factor focused on 11 organisational complexities and the latter on 10 project specific complexities. While Tie and Bolluijt [35] assimilated project management standards and frameworks, they did contend that their view was not an exhaustive review of project complexity.Construction and engineering: Sinha et al. [32] proposed a measurement model for engineering project that focuses on work and materials used, time to complete project activities, team and stakeholder motivation, and team and stakeholder relationships. He et al. [36] looked at construction projects from five complexity constructs which are comparable to the general view of Bosch-Rekveldt et al. [13]. Conversely, Lu et al. [37] measured construction project complexity from two complexity constructs. The constructs focused on task and organisation complexity from a more simple perspective. Kermanshachi et al. [38] had a different view and articulated construction project complexity from 11 constructs spanning 30 indicators. Each construct was distinct and very specific to a project complexity area.IS and new product development: Software development projects are prolific within the IS project management field, and Damasiotis and Fitsilis [14] developed a complexity measurement tool for these projects. They extracted 16 indicators from the project management knowledge areas defined in the PMBOK® Guide. Although this foray into IS project complexity assessment was a good springboard for the IS project field, their assessment tool neglected the tenth PMBOK® Guide knowledge area of “Project Stakeholder Management.” This arguably excludes complexities associated with managing stakeholders throughout an IS project’s lifespan. Poveda-Bautista et al. [16] approached IS project complexity from a different perspective to Damasiotis and Fitsilis [14]. They applied the technological, organisational, and environmental framework of Bosch-Rekveldt et al. [13] rather than extracting complexity indicators from the PMBOK® Guide. This provided a more robust assessment of IS project complexity as 61 indicators were defined across 11 constructs. Practical application of the IS project complexity index tool showed the overall project complexity and the complex areas that required key decision making and attention. New product development projects are similar to IS projects as they have a strong technological development component which inherently makes them complex [31]. Kim and Wilemon [31] contended that these projects should be assessed around six measures and 30 indicators. Assessment cannot only be done by the project manager but also by the various departments working on the project at hand. This aligns to Vidal et al. [33] who argued a multiple perspective approach.As seen from the literature, there are many perspectives regarding measuring project complexity. Within the IS project domain, studies have shown varying views of the constructs and indicators to measure IS project complexity. This paper aims to build on the work of Joseph [12] and Poveda-Bautista et al. [16] to understand what constructs and indicators are applicable to IS projects. Although Poveda-Bautista et al. [16] did develop a more comprehensive model for measuring IS project complexity compared with previous studies, they did not establish if all indicators are relevant to IS projects. The goal of this paper is to establish the constructs and indicators relevant to measuring IS project complexity.


## 2.1. Project Complexity

Significant emphasis has been placed on successfully managing projects in project management research [22]. This has led to a plethora of tools, techniques, methods, and best practices to achieve project delivery success. Projects however continue to perform poorly and fail to meet their goals and realise organisational benefits [1, 21]. The extant literature contends that a key reason for projects failing is complexity [2–5].Baccarini [23] was one of the first to conceptualise the constructs of project complexity. This initial view conceptualised project complexity around organisational and technical complexity. Williams [24] expanded on the view of Baccarini [23] and included the concept of uncertainty. Uncertainty introduces the volatile dynamic which exists in every project. Vidal and Marle [25] argued that projects are not isolated from internal and external environment effects. They assert that project complexity must also consider environmental elements as this has a direct and indirect effect on delivering a project. Geraldi et al. [26] identified the proliferation of project complexity research and conducted a systematic literature review to contextualise the state of the topic. This assimilation recognised the value of the work of Baccarini [23], Williams [24], and Vidal and Marle [25] while categorising a fundamentally new component: dynamics. Dynamics recognises the inevitable changes that emerge in projects and the importance of dedicating attention on this underrated complexity component.The reality is that while there are multiple interpretations and perceptions around project complexity, research is continuously expanding and articulating what constitutes project complexity. This has led to the development of models designed to assist the management of complexity in projects [6, 13, 22]. Geraldi and Söderlund [27] argued that research must continue to investigate new typologies and taxonomies of project complexity, especially across different industries and research communities. This will enable crosspollination and illuminate new trends emerging in the project complexity field.


## 2.2. Information Systems Project Complexity

Project complexity research has navigated various industries and project types. De Rezende et al. [28] investigated project complexity research trends from 1965 to 2015 and showed that IS project complexity research grew from the mid-90s. Despite this growth, Bakhshi et al. [29] showed that IS project complexity only represents 8% of project complexity research dated to 2015. Furthermore, Bosch-Rekveldt et al. [4] was arguably not able to fully articulate IS project complexity as these projects only represented 5.5% (8/144 projects) of their research sample.Table1 shows notable IS project complexity research by McKeen et al. [9], Ribbers and Schoo [30], Xia and Lee [10], Williamson [11], and Joseph [12]. Each study conceptualised a number of IS project complexity constructs with inherent features in each construct. Further investigation of Table 1 reveals a number of potential conclusions.Table 1
IS project complexity constructs; a concise chronological overview of project complexity constructs specific to IS projects.
AuthorConstructs (features)No. of featuresMcKeen et al. [9](i) Task complexity (6)9(ii) System complexity (3)Ribbers and Schoo [30](i) Variety (3)9(ii) Variability (4)(iii) Integration (2)Xia and Lee [10](i) Structural organisational complexity (3)15(ii) Structural IT complexity (4)(iii) Dynamic organisational complexity (5)(iv) Dynamic IT complexity (3)Williamson [11](i) Objectives (1)26(ii) Opportunity (2)(iii) Solution (2)(iv) Team (2)(v) Methodology (2)(vi) Schedule (2)(vii) Requirements (2)(viii) Environmental (6)(ix) Information technology (2)(x) Technological change (1)(xi) Organisational change (2)(xii) Staffing (1)(xiii) IT integration (1)Joseph [12](i) Organisational complexity (34)75(ii) Technical complexity (12)(iii) Environmental complexity (13)(iv) Dynamics (6)(v) Uncertainty (10)McKeen et al. [9] investigated IS project complexity in terms of task complexity (environmental complexity) and system complexity (technological complexity). While still in the infant stages of IS project complexity, this research spoke directly to the theoretical propositions of Baccarini [23] in terms of organisational and technical complexity. This IS project complexity view argues that IS project managers should be mindful of nine complexity features and manage them accordingly. This is arguably an over simplistic view of the IS project environment reality. Furthermore, this view is dated and may not include new emerge IS project complexity constructs and features.Ribbers and Schoo [30] argued IS project complexity from three different constructs: (i) variety, (ii) variability, and (iii) integration. These three constructs speak to the dynamic and ever changing nature of IS projects where multiple activities and resources are interrelated. While this three dimensional view provides a modest update to the McKeen et al. [9], Ribbers and Schoo [30] argued that IS project complexity should be managed based on nine features. One must, however, query whether it is sufficient to focus on only nine features as it is plausible that this would omit crucial IS project complexity areas.In wake of a better understanding of IS project complexity, Xia and Lee [10] and Williamson [11] explored more robust views. Xia and Lee [10] conceptualised four IS project complexity constructs spanning 15 features. Alternatively, Williamson [11] explored 13 constructs spanning 26 features. This arguably shows that as IS project complexity matured from 1994 to 2012, researchers began to explore the concept from multiple perspectives in terms of constructs and features. This corresponds to the argument made by Geraldi and Söderlund [27] to continuously investigate new typologies and taxonomies in project complexity research.Previous research has provided multiple views of IS project complexity and expanded on what it entails over the years. Bosch-Rekveldt et al. [13], however, argued that research must not oversimplify the overall concept of project complexity. Rather, a rich description of the concept is best facilitated by a comprehensive approach. Joseph [12] adopted this approach and assimilated multiple project complexity studies to generate a comprehensive view of IS project complexity. It was argued that IS project complexity is best understood by including five complexity constructs spanning 75 features. The comprehensive approach by Joseph [12] is adopted in this paper as it provides the basis for empirically validating the constructs of IS project complexity in the real world.


## 2.3. Measuring Project Complexity

A major challenge in the project complexity landscape is whether project complexity can be measured. Multiple project complexity measurement models have spawned in response to the growth of increasingly complex projects. Table2 evaluates 9 project complexity measurement models from 2003 to 2020 in multiple industries. These models can be categorised into general project management, construction and engineering, logistics as well as IS and new product development.Table 2
Project complexity measurement models; a concise chronological overview of project complexity measurement models across various industries.
AuthorIndustryConstruct (indicators)No. of indicatorsKim and Wilemon [31]New product development(i) Technological complexities (2)30(ii) Market/environmental complexities (4)(iii) Development complexities (6)(iv) Marketing complexities (8)(v) Organisational complexities (7)(vi) Intraorganisational complexities (3)Sinha et al. [32]Engineering(i) Work (4)10(ii) Time (2)(iii) Motivational (2)(iv) Social (2)Vidal et al. [33] and Vidal et al. [34]General project management(i) Project size (1)17(ii) Project variety (3)(iii) Project interdependencies (10)(iv) Elements of context (3)Tie and Bolluijt [35]General project management(i) Contextual factors (11)21(ii) Inherent factors (10)Damasiotis and Fitsilis [14]IS(i) Project integration management (3)16(ii) Project scope management (2)(iii) Project time management (2)(iv) Project cost management (3)(v) Project quality management (1)(vi) Project human resources management (1)(vii) Project communication management (1)(viii) Project risk management (1)(ix) Project procurement (2)He et al. [36]Construction(i) Technological complexity (4)28(ii) Organisational complexity (4)(iii) Goal complexity (6)(iv) Environmental complexity (5)(v) Cultural complexity (4)(vi) Information complexity (5)Lu et al. [37]Construction(i) Task complexity (11)20(ii) Organisation complexity (9)Poveda-Bautista et al. [16]IS(i) Objectives, requirements, and expectations (10)61(ii) Interested parties and integration (7)(iii) Cultural and social context (4)(iv) Degree of innovation and general conditions (4)(v) Project structure and demand for coordination (4)(vi) Project organisation (4)(vii) Leadership, teamwork, and decisions (8)(viii) Resources incl. finance (4)(ix) Risk and opportunities (4)(x) PM methods, tools, and techniques (5)(xi) Technology (7)Kermanshachi et al. [38]Construction(i) Stakeholder management (2)30(ii) Governance (2)(iii) Fiscal planning (1)(iv) Quality (1)(v) Legal (3)(vi) Interface (3)(vii) Execution target (1)(viii) Design and technology (3)(ix) Location (4)(x) Scope definition (5)(xi) Project resources (5)General project management: The models by Vidal et al. [33], Vidal et al. [34], and Tie and Bolluijt [35] standout. Vidal et al. [33] and Vidal et al. [34] argued that four complexity areas should be assessed: (i) project size, (ii) project variety, (iii) project interdependencies, and (iv) project context-dependencies. A total of 17 indicators spanned the four constructs. The project complexity measurement model applied weightings and ratings based on team member perceptions to determine a complexity index for different project types. Furthermore, they argued that a measurement model’s input should be gathered directly from project team members involved. Although this is questionably a subjective input, multiple perceptions facilitate the generation of an overall understanding of the level of project complexity.Conversely, Tie and Bolluijt [35] applied a rudimentary approach to measuring project complexity and defined two constructs: (i) contextual factors and (ii) inherent factors. The former factor focused on 11 organisational complexities and the latter on 10 project specific complexities. While Tie and Bolluijt [35] assimilated project management standards and frameworks, they did contend that their view was not an exhaustive review of project complexity.Construction and engineering: Sinha et al. [32] proposed a measurement model for engineering project that focuses on work and materials used, time to complete project activities, team and stakeholder motivation, and team and stakeholder relationships. He et al. [36] looked at construction projects from five complexity constructs which are comparable to the general view of Bosch-Rekveldt et al. [13]. Conversely, Lu et al. [37] measured construction project complexity from two complexity constructs. The constructs focused on task and organisation complexity from a more simple perspective. Kermanshachi et al. [38] had a different view and articulated construction project complexity from 11 constructs spanning 30 indicators. Each construct was distinct and very specific to a project complexity area.IS and new product development: Software development projects are prolific within the IS project management field, and Damasiotis and Fitsilis [14] developed a complexity measurement tool for these projects. They extracted 16 indicators from the project management knowledge areas defined in the PMBOK® Guide. Although this foray into IS project complexity assessment was a good springboard for the IS project field, their assessment tool neglected the tenth PMBOK® Guide knowledge area of “Project Stakeholder Management.” This arguably excludes complexities associated with managing stakeholders throughout an IS project’s lifespan. Poveda-Bautista et al. [16] approached IS project complexity from a different perspective to Damasiotis and Fitsilis [14]. They applied the technological, organisational, and environmental framework of Bosch-Rekveldt et al. [13] rather than extracting complexity indicators from the PMBOK® Guide. This provided a more robust assessment of IS project complexity as 61 indicators were defined across 11 constructs. Practical application of the IS project complexity index tool showed the overall project complexity and the complex areas that required key decision making and attention. New product development projects are similar to IS projects as they have a strong technological development component which inherently makes them complex [31]. Kim and Wilemon [31] contended that these projects should be assessed around six measures and 30 indicators. Assessment cannot only be done by the project manager but also by the various departments working on the project at hand. This aligns to Vidal et al. [33] who argued a multiple perspective approach.As seen from the literature, there are many perspectives regarding measuring project complexity. Within the IS project domain, studies have shown varying views of the constructs and indicators to measure IS project complexity. This paper aims to build on the work of Joseph [12] and Poveda-Bautista et al. [16] to understand what constructs and indicators are applicable to IS projects. Although Poveda-Bautista et al. [16] did develop a more comprehensive model for measuring IS project complexity compared with previous studies, they did not establish if all indicators are relevant to IS projects. The goal of this paper is to establish the constructs and indicators relevant to measuring IS project complexity.


## 3. Materials and Methods

This paper adopts a postpositivist theoretical lens for a number of reasons. Postpositivism does not aim to achieve the single truth for measuring IS project complexity as multiple measurement approaches could exist in reality [39]. This facilitates critical realism as the researcher can explore different methods for measuring IS project complexity through the perspective of humans involved in these environments. More importantly, postpositivism generates an objective view for measuring IS project complexity by assimilating the multiple perspectives of humans involved in these environments [40].The postpositivist lens of this paper was implemented through predictive modelling as multiple perspectives inform a probable truth of how IS project complexity could be measured. The application of predictive modelling in IS project management has yielded models such as de Barcelos Tronto et al. [41], López-Martín and Abran [42], and Cerpa et al. [43]. The underlying principle of predictive modelling is to identify and analyse the latent constructs and influencing relationships in a phenomenon. While multiple predictive modelling techniques have been used in the project management domain, this paper adopts partial least squares structural equation modelling (PLS-SEM). Reinartz et al. [44] found that PLS-SEM is better suited when predictive relationships are the key aim of research. PLS-SEM was subsequently chosen for three reasons. Firstly, PLS-SEM is well versed for complex models with over 6 constructs (latent factors) and over 50 indicators (observed variables) [45, 46]. Secondly, PLS-SEM allows the researcher to use nonnormal data when developing models as the distribution does not play a significant role during the modelling process [46, 47]. Finally, PLS-SEM facilitates assessment of unobserved heterogeneity where unobservable model traits that influence indicators and constructs are determined and measured [45, 46].Data were collected using a web-based closed questionnaire as gaining a wide range of quantitative data was imperative for the predictive modelling goal of this paper. Significant data would provide key insights into underlying relationships and constructs of IS project complexity. Rhetoric in the project discipline has led to arguments around the complexity in and of projects [13, 48, 49]. The questionnaire operationalised the theoretical constructs for IS project complexity based on the constructs defined by Joseph [12]. While Joseph [12] did not explicitly make the distinction between the complexity in and of IS projects, interrogation of the paper reveals a coherent and comprehensive articulation of both perspectives. This research subsequently adopted this comprehensive approach by articulating and including indicators relating to the complexity in and of IS projects. The questionnaire was targeted at project team members who were actively involved in and had implemented any IS projects across any industry. The reasoning was that these individuals would have first-hand experience and knowledge regarding IS project complexity given their vested involvement [50, 51]. Respondents were asked to indicate how complex they believed each of the 75 IS project complexity indicators were on the last IS project they worked on. The questionnaire presented the indicators based on the various features of Joseph [12] but was mapped to the five constructs and not the underlying elements as presented in Joseph [12]. The aim was to articulate indicators at the construct level and analyse the PLS-SEM results to reveal latent themes. A total of 612 valid responses were received from respondents in various positions across multiple domains and industries. Table 3 provides a demographic overview of the respondents.Table 3
Respondent demographics; the demographics include respondent job title, employment domain, and industry.
CharacteristicN%Job TitleProject manager11418.7%Other9715.9%Senior project manager8013.1%Business analyst6610.8%IT manager599.7%Project leader406.5%Programme manager365.9%Portfolio manager264.3%Assistant project manager254.1%Project coordinator233.8%Iteration manager213.4%Project implementation manager142.3%Project consultant101.6%Employment DomainIT management20834.1%Programme, portfolio, and project management13321.8%Consulting8113.3%Financial management447.2%General management437.0%Other345.6%Business development325.2%Training/education233.8%commercial management122.0%IndustryFinancial services21835.9%ICT & communication services12620.7%Public administration7412.2%Education & training457.4%Logistic services315.1%Wholesale & retail233.8%Healthcare223.6%Energy213.5%Building & construction183.0%HR services122.0%Facility & real estate services111.8%Legal services50.8%Agriculture20.3%


### 3.1. Developing a Model to Measure IS Project Complexity

This paper used SmartPLS 3.2.8 to perform the PLS-SEM [52]. The Consistent PLS (PLSc) algorithm was used as it provides more consistent results during model estimation and improves model reliability and validity [53]. Consistent PLS (PLSc) bootstrapping provides results regarding the statistical significance of the results generated by the PLSc algorithm [53].The research model (Figure1) was defined in SmartPLS 3.2.8 as a formative model for a number of reasons [53, 54]. This paper proposes that there is causality between the construct and the indicator. The constructs are a combination of indicators, and the indicators cause the outcome of the construct. Finally, the indicators are uniquely distinctive to each construct. When defining a complex model for PLS-SEM, Hair et al. [53] argues that a higher order construct (HOC) should be defined. In this paper IS project complexity is viewed as a HOC, which is a composite construct informed by the five lower order constructs (LOCs) of organisational complexity, technical complexity, environmental complexity, dynamics, and uncertainty. Creating a HOC is practically sound and results in a model that is more comprehensible within the research context at hand [55]. That is, the LOCs will provide insight into the true contributors to and their impact on the IS project complexity HOC. When defining a HOC, it is important to detail which indicators are assigned to it. The repeated indicator approach was used where all the indicators from the LOCs are assigned to the HOC [53, 56]. All 75 IS project complexity indicators associated with the LOCs are therefore assigned to the HOC.Figure 1
IS project complexity research model. The research model depicts the constructs influencing overall IS project complexity.


### 3.2. Assessing the IS Project Complexity Formative Model

Hair et al. [46] explicitly warned against incorrect assessment criteria being used for formative models as there are instances where reflective measures are used to assess formative models. Formative models should be assessed based on collinearity between indicators as well as the significance and relevance of each indicator. Collinearity is achieved by a variance inflation factor (VIF) below 5. A decision tree was developed to assess the significance and relevance of each indicator [46]. Figure 2 presents the decision tree adopted for this paper. The PLSc bootstrapping algorithm provided the significance values, and the PLSc algorithm provided the outer loading values for each indicator.Figure 2
A decision tree to determine the significance and relevance of indicators (adapted from Hair et al. [46]).After four iterations of formative model refinement, all criteria were met for IS project complexity. Collinearity was achieved as all indicator VIF values were below the threshold of 5. Furthermore, the remaining indicators met the criteria stipulated in Figure2, implying that indicator significance and relevance were achieved.Table4 compares the number of indicators for the initial and final IS project complexity formative model. Overall, the 75 indicators were reduced to 39 as follows: organisational complexity (6), technical complexity (8), environmental complexity (9), dynamics (6), and uncertainty (10). This is comparable to previous studies such as Vidal et al. [33] and Kermanshachi et al. [38] where an initial number of indicators were reduced to produce the most relevant measures for project complexity. The final indicators presented in this paper align to the study of Poveda-Bautista et al. [16]. They argue that it is not necessary to measure IS project complexity across all possible indicators as this process is inherently complex to execute.Table 4
Comparing the number of indicators from the initial and the final IS project complexity formative model.
ConstructNumber of initial model indicatorsNumber of final model indicatorsSignificantOrganisational complexity346✓Technical complexity128✓Environmental complexity139✗Dynamics66✗Uncertainty1010✓Total7539Once the formative model determined the valid indicators for each construct, the final model was assessed to establish which constructs statistically influenced the HOC of IS project complexity. The model is presented in Figure3. This was assessed by analysing the significance and relevance of model relationships [57, 58]. Constructs were deemed valid if their p value was below 0.05. The results showed that organisational complexity (0.355, p = 0.023), technical complexity (0.567, p = 0.002), and uncertainty (0.474, p = 0.002) all have significant relationships with IS project complexity. This implies that these three constructs influence the level of IS project complexity.Figure 3
The final model for measuring IS project complexity. The model includes thep value in parenthesis to illustrate the valid and relevant constructs of IS project complexity.


## 3.1. Developing a Model to Measure IS Project Complexity

This paper used SmartPLS 3.2.8 to perform the PLS-SEM [52]. The Consistent PLS (PLSc) algorithm was used as it provides more consistent results during model estimation and improves model reliability and validity [53]. Consistent PLS (PLSc) bootstrapping provides results regarding the statistical significance of the results generated by the PLSc algorithm [53].The research model (Figure1) was defined in SmartPLS 3.2.8 as a formative model for a number of reasons [53, 54]. This paper proposes that there is causality between the construct and the indicator. The constructs are a combination of indicators, and the indicators cause the outcome of the construct. Finally, the indicators are uniquely distinctive to each construct. When defining a complex model for PLS-SEM, Hair et al. [53] argues that a higher order construct (HOC) should be defined. In this paper IS project complexity is viewed as a HOC, which is a composite construct informed by the five lower order constructs (LOCs) of organisational complexity, technical complexity, environmental complexity, dynamics, and uncertainty. Creating a HOC is practically sound and results in a model that is more comprehensible within the research context at hand [55]. That is, the LOCs will provide insight into the true contributors to and their impact on the IS project complexity HOC. When defining a HOC, it is important to detail which indicators are assigned to it. The repeated indicator approach was used where all the indicators from the LOCs are assigned to the HOC [53, 56]. All 75 IS project complexity indicators associated with the LOCs are therefore assigned to the HOC.Figure 1
IS project complexity research model. The research model depicts the constructs influencing overall IS project complexity.


## 3.2. Assessing the IS Project Complexity Formative Model

Hair et al. [46] explicitly warned against incorrect assessment criteria being used for formative models as there are instances where reflective measures are used to assess formative models. Formative models should be assessed based on collinearity between indicators as well as the significance and relevance of each indicator. Collinearity is achieved by a variance inflation factor (VIF) below 5. A decision tree was developed to assess the significance and relevance of each indicator [46]. Figure 2 presents the decision tree adopted for this paper. The PLSc bootstrapping algorithm provided the significance values, and the PLSc algorithm provided the outer loading values for each indicator.Figure 2
A decision tree to determine the significance and relevance of indicators (adapted from Hair et al. [46]).After four iterations of formative model refinement, all criteria were met for IS project complexity. Collinearity was achieved as all indicator VIF values were below the threshold of 5. Furthermore, the remaining indicators met the criteria stipulated in Figure2, implying that indicator significance and relevance were achieved.Table4 compares the number of indicators for the initial and final IS project complexity formative model. Overall, the 75 indicators were reduced to 39 as follows: organisational complexity (6), technical complexity (8), environmental complexity (9), dynamics (6), and uncertainty (10). This is comparable to previous studies such as Vidal et al. [33] and Kermanshachi et al. [38] where an initial number of indicators were reduced to produce the most relevant measures for project complexity. The final indicators presented in this paper align to the study of Poveda-Bautista et al. [16]. They argue that it is not necessary to measure IS project complexity across all possible indicators as this process is inherently complex to execute.Table 4
Comparing the number of indicators from the initial and the final IS project complexity formative model.
ConstructNumber of initial model indicatorsNumber of final model indicatorsSignificantOrganisational complexity346✓Technical complexity128✓Environmental complexity139✗Dynamics66✗Uncertainty1010✓Total7539Once the formative model determined the valid indicators for each construct, the final model was assessed to establish which constructs statistically influenced the HOC of IS project complexity. The model is presented in Figure3. This was assessed by analysing the significance and relevance of model relationships [57, 58]. Constructs were deemed valid if their p value was below 0.05. The results showed that organisational complexity (0.355, p = 0.023), technical complexity (0.567, p = 0.002), and uncertainty (0.474, p = 0.002) all have significant relationships with IS project complexity. This implies that these three constructs influence the level of IS project complexity.Figure 3
The final model for measuring IS project complexity. The model includes thep value in parenthesis to illustrate the valid and relevant constructs of IS project complexity.


## 4. Results and Discussion of the Model for Measuring IS Project Complexity

The literature reveals the need for understanding and incorporating organisational complexity when executing projects [4, 12, 33]. The model presented in this paper is similar to findings of Xia and Lee [59] who empirically validated the influence of organisational complexity in the IS project context. This paper validates that complexities regarding the number of different nationalities, experience with involved parties, project drive, stakeholder interrelations, team cooperation and communication, and work hours are all indicators contributing to organisational complexity. It can therefore be argued that if IS project managers, team members, and stakeholders are aware of these underlying indicators, they can manage and mitigate them accordingly. The reality is that these organisational complexities should not be prevented but rather embraced as they will occur regardless. Knowing the existence of these organisational complexities will ensure that the IS project maintains its trajectory and delivers its intended strategic goals.The next significant relationship is that of the technical complexity construct on IS project complexity. This implies that technical complexity contributes to the level of complexity faced in IS projects. The initial conceptualisation of technical complexity focused on technological complexities that could arise during a project [23]. Research has, however, evolved to be more inclusive and aware of other technical aspects associated with project execution [4, 60]. The contributing indicators of technical complexity are clarity of goals, conflicting norms and standards, experience with technology, goal alignment, number of goals, number of tasks, quality requirements, and scale of scope. Floricel et al. [61] validated that technical complexity influences a project’s performance, and Eriksson et al. [60] and Zaman et al. [62] had proven the influence of this construct on software project performance.Furthermore, Marnewick et al. [63] were of the view that technical complexity influences the process and project management success of an IS project. This paper therefore supports and echoes these studies by proving that technical complexity influences IS project complexity. A holistic understanding of technical complexity will assist stakeholders in tackling its indicators during an IS project [13, 62].The final significant relationship was that of the uncertainty construct on IS project complexity. The level of complexity in IS projects is therefore influenced by the level of uncertainty during an IS project. Project uncertainty poses multiple risks during a project and can negatively affect the performance of the project [61, 64]. It is, however, argued that uncertainty is inherently prevalent in projects and that there should be increased awareness of the various uncertainty indicators [12, 26, 65, 66]. This paper argues that the following uncertainty indicators are applicable to IS projects: uncertainties in scope, uncertainties in cost, uncertainties in time, uncertainty in methods, task uncertainty, uncertainty of goals and objectives, technological maturity and novelty, undisclosed participants, competency, and incomplete information. Walker et al. [65] and Um and Kim [67] stressed that uncertainty should not be viewed negatively as awareness of it creates an opportunistic environment for collaboration in terms of knowledge sharing and learning. Being more cognisant of uncertainty, its underlying indicators indirectly influence project performance and increase the need for information sharing between stakeholders [67]. Mitigating strategies can therefore be developed to address any ambiguity during an IS project [65].


### 4.1. Implications of the Model for Measuring IS Project Complexity

The practical application of research is often not clear or sufficient in academic research [68]. In light of this, this section presents practical suggestions for IS project managers to consider based on the results of the model for measuring is project complexity. IS project managers face a multitude of decisions on a daily basis, and this research can aid in the decision making process. Awareness of the relevant IS project complexity constructs is one dimension. Another dimension is to assist IS project managers during the multiple decisions they face and provide recommendations regarding the course of action they can adopt to manage IS project complexity effectively. Table 5 focuses on the relevant IS project complexity constructs and the underlying management themes identified during the data analysis process. The themes were inductively classified based on the indicators of each construct. Each theme is matched to their respective variables and recommended course of action for IS project managers. While Table 5 is not an exhaustive list of actions the project manager can follow, it does provide a solid basis for them to manage IS project complexity effectively.Table 5
IS project manager’s course of action recommendations. IS project managers may apply the recommended course of action based on results for each construct theme and their respective variable.
ConstructManagement themeObserved variablesCourse of actionOrganisational complexityProject team(i) OC_Different_Nationalities-different nationalities(i) Develop and facilitate a multicultural environment that encourages team members to learn various member cultures and languages [69](ii) OC_Team_Cooperation-team cooperation and communication(ii) Create an adaptable project communications plan that considers various team cooperation and communication methods and channels [70](iii) OC_Workhours-work hoursStakeholder management(i) OC_Experience-experience with involved parties(i) Understand and create awareness of stakeholders’ project goal expectations amongst all stakeholders [71](ii) OC_Stakeholder_Interrelations-stakeholder interrelations(ii) Define and agree on communication approaches best suited for stakeholders involved [72](iii) Allocate team members who are responsible for continuous engagement with stakeholders [73]Strategic drive(i) OC_Project_Drive-project drive(i) Communicate how the project aligns to strategic goals amongst the project team [74](ii) Evaluate and select appropriate techniques for measuring the project drive to ensure organisational value alignment [74]Technical complexityProject goals(i) TC_Clarity_Goals-clarity of goals(i) Translate stakeholders’ project goal expectations to language the project team can understand [75](ii) TC_Goal_Alignment-goal alignment(ii) Communicate the purpose of the project amongst stakeholders and team members to enforce common understanding [75](iii) TC_Number_Goals-number of goals(iii) Continuously reflect and update project goals to maintain strategic alignment [76]Requirements management(i) TC_Number_Tasks-number of tasks(i) Identify stakeholders who are knowledgeable about the areas the project will be deployed in [77](ii) TC_Quality_Requirements-quality of requirements(ii) Categorise, delegate, and monitor stakeholder engagement [77](iii) TC_Scale_Scope-scale of scope(iii) Continuously reflect and update requirements to manage project scope [78]Technology management(i) TC_Experience_Technology-experience with technology(i) Identify the team members and stakeholders knowledgeable of the technology being implemented in the project [79](ii) Regularly upskill and train team members and stakeholders on new technologies outside and inside the project environment [80]Norms and standards(i) TC_Conflicting_Norms-conflicting norms and standards(i) Develop unambiguous project management standards and policies that can be adapted to multiple projects [13](ii) Communicate the project management standards and policies applicable to the project at hand [81](iii) Reflect and update project management standards and policies regularly [81]UncertaintySkills management(i) U_Competency-competency(i) Understand the current state of technology used in the project [82](ii) U_Technological_Maturity-technological maturity(ii) Regularly upskill and train team members and stakeholders on business operations and project management principles [83]Triple constraint(i) U_Time-uncertainties in time(i) Evaluate and select methods for improving project schedule, budget, and scope monitoring [84](ii) U_Cost-uncertainties in cost(ii) Identify and engage with team members and stakeholders who can assist with monitoring and managing the project schedule, budget, and scope [85](iii) U_Scope-uncertainties in scopeActivity management(i) U_Goals-uncertainty of goals and objectives(i) Regularly engage with team members and stakeholders to understand their project goals and objectives concerns [80](ii) U_Undisclosed_Participants-undisclosed participants(ii) Monitor the execution of project management standards and policies and direct the project team accordingly [81](iii) U_Incomplete_Information-incomplete information(iii) Monitor and reflect on the stakeholders required during the various phases of the project [72](iv) U_Tasks-task uncertainty(v) U_Methods-uncertainty in methodsOrganisational complexity was found to have three themes: (i) project team, (ii) stakeholder management, and (iii) strategic drive. IS project managers must develop a multicultural environment that encourages team members to learn new cultures and languages [69]. Furthermore, it is important that team members communicate effectively, and this is best done through the creation of a robust project communications plan [70]. Stakeholder management should be facilitated by understanding and creating awareness of stakeholders’ project goal expectations [71]. It is also important to define the communication approaches best suited for the stakeholders involved and allocate team members to maintain a high level of rapport with them [72, 73]. IS projects will not succeed unless there is alignment between the project and strategic goals. Alsudiri et al. [74] argued that it is important to communicate with the project team how the project aligns to strategic goals. The project manager must evaluate and select the appropriate techniques to measure the project drive to ensure organisational value alignment.Four themes were identified in the technical complexity construct: (i) project goals, (ii) requirements management, (iii) technology management, and (iv) norms and standards. Project goals should be understandable by team members as this ensures they are able to accomplish them [75]. This is achieved by translating the project goals into a language the team members can understand as it creates a sense of common understanding of what is required of them [75]. Terlizzi et al. [76] also argued that there must be continuous reflection on project goals as they should be updated to maintain strategic alignment. From a requirements management perspective, the project manager must facilitate the identification of knowledgeable stakeholders as they will provide key insights regarding the problem or opportunity the IS project aims to address [77]. Sperry and Jetter [77] subsequently argued that stakeholders must be categorised and monitored by delegated team members to ensure requirements are correctly articulated. Continuous reflection around project scope and requirements must exist to effectively manage the project scope [78]. Technology management is another technical complexity area the project manager must be aware of. It is important to identify the team members and stakeholders with knowledge concerning the technology to be implemented as part of the IS project solution [79]. This knowledge can also be facilitated by upskilling and training team members and stakeholders on new technologies [80]. The final theme in technical complexity focuses on project management norms and standards. Bosch-Rekveldt et al. [13] argued that these norms and standards should be clearly articulated whilst being unambiguous. Wiewiora et al. [81] further contended that project management standards and policies must be clearly communicated to ensure there is consistency across the entire project. It is natural for project management standards to evolve over time and thus require regular reflection to update them accordingly [81].Three themes were identified in the uncertainty construct: (i) skills management, (ii) triple constraint, and (iii) activity management. Skills management focuses on competency as the team must able to complete their jobs while stakeholders must be knowledgeable to assist IS project development. As technology is a fundamental component of any IS project, it is important to understand the current state of technology being used in the project [82]. Another aspect of competency the project manager must be aware of is the need to regularly upskill and train team members and stakeholders on business operations and project management principles [83]. This ensures they are able to solve problems associated with the IS project being implemented. The triple constraint is discussed in the project literature ad nausem and was still identified as a complexity area in this paper. Ziek and Anderson [84] argued that various methods must be evaluated and selected to effectively monitor the triple constraint. The project manager does not have to solely be responsible for monitoring the triple constraint as it is better to identify and engage with team members and stakeholders who can assist [85]. Activity management requires regular engagement with team members and stakeholders to understand their project goals and objective concerns [80]. It is also important to monitor the execution of project management standards and policies as this will ensure the team is correctly directed during the IS project [81]. Finally, activity management must also monitor and reflect on the stakeholders required during the various project phases as it is possible to omit key stakeholders when executing the project [72].


## 4.1. Implications of the Model for Measuring IS Project Complexity

The practical application of research is often not clear or sufficient in academic research [68]. In light of this, this section presents practical suggestions for IS project managers to consider based on the results of the model for measuring is project complexity. IS project managers face a multitude of decisions on a daily basis, and this research can aid in the decision making process. Awareness of the relevant IS project complexity constructs is one dimension. Another dimension is to assist IS project managers during the multiple decisions they face and provide recommendations regarding the course of action they can adopt to manage IS project complexity effectively. Table 5 focuses on the relevant IS project complexity constructs and the underlying management themes identified during the data analysis process. The themes were inductively classified based on the indicators of each construct. Each theme is matched to their respective variables and recommended course of action for IS project managers. While Table 5 is not an exhaustive list of actions the project manager can follow, it does provide a solid basis for them to manage IS project complexity effectively.Table 5
IS project manager’s course of action recommendations. IS project managers may apply the recommended course of action based on results for each construct theme and their respective variable.
ConstructManagement themeObserved variablesCourse of actionOrganisational complexityProject team(i) OC_Different_Nationalities-different nationalities(i) Develop and facilitate a multicultural environment that encourages team members to learn various member cultures and languages [69](ii) OC_Team_Cooperation-team cooperation and communication(ii) Create an adaptable project communications plan that considers various team cooperation and communication methods and channels [70](iii) OC_Workhours-work hoursStakeholder management(i) OC_Experience-experience with involved parties(i) Understand and create awareness of stakeholders’ project goal expectations amongst all stakeholders [71](ii) OC_Stakeholder_Interrelations-stakeholder interrelations(ii) Define and agree on communication approaches best suited for stakeholders involved [72](iii) Allocate team members who are responsible for continuous engagement with stakeholders [73]Strategic drive(i) OC_Project_Drive-project drive(i) Communicate how the project aligns to strategic goals amongst the project team [74](ii) Evaluate and select appropriate techniques for measuring the project drive to ensure organisational value alignment [74]Technical complexityProject goals(i) TC_Clarity_Goals-clarity of goals(i) Translate stakeholders’ project goal expectations to language the project team can understand [75](ii) TC_Goal_Alignment-goal alignment(ii) Communicate the purpose of the project amongst stakeholders and team members to enforce common understanding [75](iii) TC_Number_Goals-number of goals(iii) Continuously reflect and update project goals to maintain strategic alignment [76]Requirements management(i) TC_Number_Tasks-number of tasks(i) Identify stakeholders who are knowledgeable about the areas the project will be deployed in [77](ii) TC_Quality_Requirements-quality of requirements(ii) Categorise, delegate, and monitor stakeholder engagement [77](iii) TC_Scale_Scope-scale of scope(iii) Continuously reflect and update requirements to manage project scope [78]Technology management(i) TC_Experience_Technology-experience with technology(i) Identify the team members and stakeholders knowledgeable of the technology being implemented in the project [79](ii) Regularly upskill and train team members and stakeholders on new technologies outside and inside the project environment [80]Norms and standards(i) TC_Conflicting_Norms-conflicting norms and standards(i) Develop unambiguous project management standards and policies that can be adapted to multiple projects [13](ii) Communicate the project management standards and policies applicable to the project at hand [81](iii) Reflect and update project management standards and policies regularly [81]UncertaintySkills management(i) U_Competency-competency(i) Understand the current state of technology used in the project [82](ii) U_Technological_Maturity-technological maturity(ii) Regularly upskill and train team members and stakeholders on business operations and project management principles [83]Triple constraint(i) U_Time-uncertainties in time(i) Evaluate and select methods for improving project schedule, budget, and scope monitoring [84](ii) U_Cost-uncertainties in cost(ii) Identify and engage with team members and stakeholders who can assist with monitoring and managing the project schedule, budget, and scope [85](iii) U_Scope-uncertainties in scopeActivity management(i) U_Goals-uncertainty of goals and objectives(i) Regularly engage with team members and stakeholders to understand their project goals and objectives concerns [80](ii) U_Undisclosed_Participants-undisclosed participants(ii) Monitor the execution of project management standards and policies and direct the project team accordingly [81](iii) U_Incomplete_Information-incomplete information(iii) Monitor and reflect on the stakeholders required during the various phases of the project [72](iv) U_Tasks-task uncertainty(v) U_Methods-uncertainty in methodsOrganisational complexity was found to have three themes: (i) project team, (ii) stakeholder management, and (iii) strategic drive. IS project managers must develop a multicultural environment that encourages team members to learn new cultures and languages [69]. Furthermore, it is important that team members communicate effectively, and this is best done through the creation of a robust project communications plan [70]. Stakeholder management should be facilitated by understanding and creating awareness of stakeholders’ project goal expectations [71]. It is also important to define the communication approaches best suited for the stakeholders involved and allocate team members to maintain a high level of rapport with them [72, 73]. IS projects will not succeed unless there is alignment between the project and strategic goals. Alsudiri et al. [74] argued that it is important to communicate with the project team how the project aligns to strategic goals. The project manager must evaluate and select the appropriate techniques to measure the project drive to ensure organisational value alignment.Four themes were identified in the technical complexity construct: (i) project goals, (ii) requirements management, (iii) technology management, and (iv) norms and standards. Project goals should be understandable by team members as this ensures they are able to accomplish them [75]. This is achieved by translating the project goals into a language the team members can understand as it creates a sense of common understanding of what is required of them [75]. Terlizzi et al. [76] also argued that there must be continuous reflection on project goals as they should be updated to maintain strategic alignment. From a requirements management perspective, the project manager must facilitate the identification of knowledgeable stakeholders as they will provide key insights regarding the problem or opportunity the IS project aims to address [77]. Sperry and Jetter [77] subsequently argued that stakeholders must be categorised and monitored by delegated team members to ensure requirements are correctly articulated. Continuous reflection around project scope and requirements must exist to effectively manage the project scope [78]. Technology management is another technical complexity area the project manager must be aware of. It is important to identify the team members and stakeholders with knowledge concerning the technology to be implemented as part of the IS project solution [79]. This knowledge can also be facilitated by upskilling and training team members and stakeholders on new technologies [80]. The final theme in technical complexity focuses on project management norms and standards. Bosch-Rekveldt et al. [13] argued that these norms and standards should be clearly articulated whilst being unambiguous. Wiewiora et al. [81] further contended that project management standards and policies must be clearly communicated to ensure there is consistency across the entire project. It is natural for project management standards to evolve over time and thus require regular reflection to update them accordingly [81].Three themes were identified in the uncertainty construct: (i) skills management, (ii) triple constraint, and (iii) activity management. Skills management focuses on competency as the team must able to complete their jobs while stakeholders must be knowledgeable to assist IS project development. As technology is a fundamental component of any IS project, it is important to understand the current state of technology being used in the project [82]. Another aspect of competency the project manager must be aware of is the need to regularly upskill and train team members and stakeholders on business operations and project management principles [83]. This ensures they are able to solve problems associated with the IS project being implemented. The triple constraint is discussed in the project literature ad nausem and was still identified as a complexity area in this paper. Ziek and Anderson [84] argued that various methods must be evaluated and selected to effectively monitor the triple constraint. The project manager does not have to solely be responsible for monitoring the triple constraint as it is better to identify and engage with team members and stakeholders who can assist [85]. Activity management requires regular engagement with team members and stakeholders to understand their project goals and objective concerns [80]. It is also important to monitor the execution of project management standards and policies as this will ensure the team is correctly directed during the IS project [81]. Finally, activity management must also monitor and reflect on the stakeholders required during the various project phases as it is possible to omit key stakeholders when executing the project [72].


## 5. Conclusions

Dealing with complexity has become the new norm in today’s world. This has had a knock-on effect on organisations and implementing their strategic goals. IS projects have become a critical means for organisations to implement and realise their strategic goals. This paper presented a model for measuring IS project complexity and identified three key areas to measure and manage throughout an IS project.Firstly, the model revealed organisational complexity as a contributing factor of IS project complexity. It was argued that organisational complexity in terms of project team, stakeholder management, and strategic drive should be managed by the project manager. It is important for IS project managers to manage these three areas as they directly influence each other. Effective management of the project team and stakeholder management will manage the project’s level of complexity while ensuring there is transparency and a common understanding to achieve strategic success. Organisations invest significantly in IS projects, and it is important that this investment yields short- and long-term benefits to all parties within the organisations.Secondly, technical complexity was argued in terms of project goals, requirements management, technology management, and norms and standards. IS projects cannot be of value if its goals are not aligned to the strategic goals. This paper argues that the project manager must involve the relevant project participants to ensure the goals are correctly defined and understood by all involved. A similar argument is made for requirements management as the requirements must be reflected on and updated accordingly to facilitate strategic alignment. Gaining the correct knowledge is pivot as this drives quality requirements that are understood and implemented for the IS project. IS project managers must also be able to identify involved participants who are knowledgeable about possible technologies to be implemented. Alternatively, it is important to provide a platform for continuous upskilling and training for technology advancements. The greater field of project management has evolved to include multiple approaches to execute projects. This is particularly true in IS projects where agile and lean approaches are becoming more prevalent. IS project managers must ensure that there is single consistent understanding amongst all participants regarding how the project is executed regardless of the adopted approach.Finally, uncertainty in IS projects exists in terms of skills management, the triple constraint, and activity management. Skills management focuses on the need for IS project managers to ensure project participants grow their skills and knowledge around the business operations and project management principles. Managing the triple constraint has traditionally been the sole responsibility of the project manager. However, this should change as the project manager should select and include participants who can assist with managing the triple constraint. In terms of activity management, IS project managers regularly engage with participants to hear their concerns. Moreover, it is important to reflect on who is best suited for providing this information and include them where necessary.There are multiple similarities and differences to various project complexity models in the literature. While the Complexity Assessment Tool assesses similar structural and socio-political indicators, it only asked whether an indicator is complex or not [86]. This paper presents several weightings (Figure 3) for IS project complexity that assist in categorising and prioritising complexity management activities and tasks. Furthermore, the model has a generalised view of project complexity while this paper presents a specific IS project view given the increasing importance of these projects. Similarly, Shenhar et al. [87] assessed complexity via the Diamond of Innovation and arguably had a strong focus on product delivery which is not limited to IS products. Poveda-Bautista et al. [16] argued project complexity from an IS project perspective by applying the Crawford–Ishikura Factor Table for evaluating the role model through the IPMA project management complexity assessment. While providing a comprehensive view of IS project complexity through 34 indicators, the relevance and significance of each indicator were not statistically articulated as in this paper. Ironically, this paper contributes by providing a simplified view of IS project complexity and statistically determining the relevance, significance, and importance of 10 IS project complexity themes and 24 indicators. Using the strategies in Table 5, this would assist effectively managing the complexity of and in IS projects. Similar to Maylor et al. [86] and Shenhar et al. [87], models by Kim and Wilemon [31], Hass [88], and Xia and Lee [59] are arguably dated and require an updated perspective as presented in this paper.This paper has reiterated that IS projects are no longer purely technologically focused endeavours as the complexity in and of IS projects has multiple implications. Given the strategic nature and implications of IS projects [8], measuring the three areas mentioned above are pivotal to ensure the effective management and delivery of an IS project. Pinkerton [89] asserts, “If the venture is not a success, neither is the project.” IS projects have short-, medium-, and long-term implications [90]. Moreover, Joseph [12] and Marnewick et al. [63] argued a symbiotic connection and flow between IS project implications over time. Daniels and LaMarsh [91] and Whitney and Daniels [92] argued expanding the worldviews of IS project management by conceptualising the reality of complexity and the dangerous assumption of linearity in a nonlinear environment.


### 5.1. Limitations and Future Research

The first limitation is that the model dataset could have several constraints. There arguably is response bias towards certain roles and job positions. For example, project managers were the majority of respondents and they may provide bias positive perceptions towards their environments. Having more views across other roles and job positions could change how the model estimated the relationships and indicators of each construct. Future research should endeavour to gain data from respondents in different roles and job positions.Another limitation is that the model can only be generalised to IS projects in general. The dataset did not distinguish between the various IS project methodologies, e.g., agile vs traditional. It is plausible that project complexity and its relationships to project success could vary in different implementation environments. Future research should explore this possibility, which would add to the debate whether the agile philosophy is more effective for IS projects.The third limitation is that this paper did not explore possible reasons why the constructs of environmental complexity and dynamics are not applicable to IS projects. Given that IS projects are arguably prone to environmental factors and dynamics around change management, it is interesting why these are seen as insignificant in this paper. Future research should explore possible reasons why they should be neglected or possibly be included in other complexity constructs.The fourth limitation concerns the lack of sensitivity analysis within the IS project complexity measuring model. Currently, the model does not accommodate for changes between projects as is fixed for all IS projects. While the model serves as a foundation for measuring IS project complexity, future research should endeavour to integrate a sensitivity analysis dimension where the ranking of construct indicators adapt to each IS project instance for a more accurate measurement of complexity.Although this paper argued a revised view of IS project complexity compared with previous models, it did not empirically compare and validate this paper’s model to previous models. Future research should thus embark on practical- and action-based studies to determine the performance of this paper’s model relative to previous models as this could aid in developing a robust IS project complexity model built from multiple perspectives over time.


## 5.1. Limitations and Future Research

The first limitation is that the model dataset could have several constraints. There arguably is response bias towards certain roles and job positions. For example, project managers were the majority of respondents and they may provide bias positive perceptions towards their environments. Having more views across other roles and job positions could change how the model estimated the relationships and indicators of each construct. Future research should endeavour to gain data from respondents in different roles and job positions.Another limitation is that the model can only be generalised to IS projects in general. The dataset did not distinguish between the various IS project methodologies, e.g., agile vs traditional. It is plausible that project complexity and its relationships to project success could vary in different implementation environments. Future research should explore this possibility, which would add to the debate whether the agile philosophy is more effective for IS projects.The third limitation is that this paper did not explore possible reasons why the constructs of environmental complexity and dynamics are not applicable to IS projects. Given that IS projects are arguably prone to environmental factors and dynamics around change management, it is interesting why these are seen as insignificant in this paper. Future research should explore possible reasons why they should be neglected or possibly be included in other complexity constructs.The fourth limitation concerns the lack of sensitivity analysis within the IS project complexity measuring model. Currently, the model does not accommodate for changes between projects as is fixed for all IS projects. While the model serves as a foundation for measuring IS project complexity, future research should endeavour to integrate a sensitivity analysis dimension where the ranking of construct indicators adapt to each IS project instance for a more accurate measurement of complexity.Although this paper argued a revised view of IS project complexity compared with previous models, it did not empirically compare and validate this paper’s model to previous models. Future research should thus embark on practical- and action-based studies to determine the performance of this paper’s model relative to previous models as this could aid in developing a robust IS project complexity model built from multiple perspectives over time.



---

*Source: 5907971-2021-01-19.xml*