Socio-Technical and Political Complexities: Findings from Two Case Studies of Large IT Project-Based Organizations

Abstract

Information technology (IT) projects are becoming more complex due to technological advancements, increased sociopolitical demand, and competition. In recent years, the project complexity field has attracted increasing attention with diverse strategies and methods proposed to identify, evaluate, and respond to various complexities. This study aims to identify and prioritize factors contributing to complexity in IT projects by reporting two case studies conducted on large IT organizations. The literature on project complexity informed and guided this exploratory research. The data were collected through 21 semi-structured interviews and analyzed by applying open and axial coding content analysis. Underpinned by complexity theories, 19 factors contributing to the complexity of IT projects were identified, and their importance was highlighted using the Friedman test. The top five factors contributing to IT project complexity were identified as follows: the diversity of stakeholders; technological newness of the project; conflicting goals of stakeholders; variety of product sub-systems and components; and uncertainty of project objectives. This study’s findings contribute to the project management literature and inform practitioners about how to achieve more effective management of complex IT projects.

1. Introduction

Industrial revolutions, with the fourth one happening in our era, make the nature of projects and the prevailing environmental conditions more complex [1,2]. Complexity hampers timely project delivery, stakeholder satisfaction, value delivery, and the realization of benefits. The success or failure of a project is directly related to the complexity inherent to that project and the ability of the management team to adopt relevant instruments [3,4,5]. Multiple projects fail to achieve their objectives and exhibit poor performance due to the inability of project management teams to recognize, evaluate, and manage complexity. Every recent project has exhibited some degree of complexity [4,5,6]. Constant technological advancements and fundamental developments in management complexity have been noted as essential aspects of project management [7].

Current research demonstrates the importance of recognizing complexity in project management [4,6,8,9]. Several reasons are identified, including challenges in determining planning, coordination, and control requirements; correct identification of the objectives in large IT projects; effectiveness in determining the appropriate form of organization; and the experience that project team members are required to have [10]. Complexity is a criterion used in selecting the most suitable project management set-up and has a significant effect on project success.

By their nature, IT projects have a high degree of complexity. They are highly capital intensive, involve a diversity of experts and stakeholders, endure over relatively long periods, soak up enormous amounts of components and resources, and are run in a competitive and inter-connected environment. As technology advances, IT projects grow in scale and scope and become more challenging to implement. Therefore, recognizing and managing their complexity is essential to, and challenging for, the industry [11]. Many researchers have investigated the correlation between complexity and other problems in IT projects, including high cost, probability of failure, inappropriate management styles, and increased risks [12,13,14]. Much has been written in this area of research; however, every single project and its context are unique. Therefore, it is worthwhile to understand more about project characteristics and complexity patterns in different contexts [5].

Considering the importance of recognizing and managing complexity in IT projects, this study aims to identify, prioritize, and categorize the key factors contributing to this complexity as it relates to their management, design, and implementation.

In recent years, research has been conducted to identify the complexity of projects in different industries [1,5] in many countries. However, the existence of unique political, economic, and social features in Iran amid the presence of various sanctions and the country’s governance structure has made it challenging to implement IT projects in Iran. This study is the first to investigate the complexities of IT projects in a country under the shadow of sanctions.

This study answers the following research question: What are the key complexity factors impacting large IT projects?

Two case studies of large-scale enterprise resource planning (ERP) system implementation projects in Iranian organizations were studied to answer this question. Twenty-one semi-structured interviews and 30 survey questionnaires were used to collect the data. Two forms of coding, open and axial, were applied to analyze and interpret the data and to develop a framework for identifying and ranking complexity factors in IT projects.

The rest of the paper is organized as follows: Section 2 introduces the theoretical underpinnings of this study. And reports and summarizes the literature review conducted on IT project complexity. This is followed by the presentation of the research design and methodology in Section 3. Two illustrative cases of complexity factors in IT projects are presented in Section 4. Section 5 discusses the findings, with the paper concluding with the study’s theoretical contributions and practical implications.

2. Contextual Background

2.1. Theoretical Underpinning

A theoretical lens is needed to make sense of and translate research findings into understandable messages [15]. This assists research in developing explanations that enable the audience to link the findings to broader aspects and to compare the findings with other cases. Universal issues include the identification of agreed definitions of project complexity and the conceptualization challenge presented by the term, with minimal industry specifications available. Before exploring complexity factors, the project hierarchy and simple, complicated, complex, and chaotic states needed to be considered. Simple projects can be defined as temporary activities undertaken to produce goods or provide services subject to clear and predefined cause–effect conditions; everyone who participates in these projects can appropriately respond to different situations by accessing the necessary information. This is the domain of ‘known unknowns’, which is self-evident, predictable, and repeatable. Some examples are food catering, manufacturing simple house appliances, and building small structures.

Complicated projects, with respect to the cause–effect relationships between tasks and elements, are open to debate. Knowledge and expertise are essential for realizing complicated projects, with these requiring appropriate expertise to overcome their drawbacks [16]. Complicated projects contain subsets of simple projects, but are not reducible to their scale. The nature of complicated projects is not always related to their scale, but to their coordination or need for specialized expertise [17]. Launching a rocket to the moon, building aircraft, and most large construction projects are in the complicated project category.

In some cases, one does not know what one does not know, with this layer of the mind termed the ‘unknown unknowns.’ Complex projects contain elements of ambiguity and uncertainty, interdependency, non-linearity, unique local conditions, autonomy, emergent behaviors, and undetermined boundaries. Examples of complex projects include most projects that relate to defense, health, and large-scale information technologies, as well as projects that manufacture satellites and nuclear-powered submarines [5].

Managing complex projects is a demanding and challenging task, with success based on project managers understanding their project’s chosen pathways and focusing on project complexity factors. Chaotic projects cannot be managed within project time frames, as these projects are subject to global crises and disasters [16,18]. It is further worth mentioning that many projects lie somewhere along the spectrum and rarely at one end or the other (Figure 1).

2.2. Review of Related Research

Project management is not exempt from, but is subject to, complexity with its decisive effects. Unlike traditional projects, which are self-organizing, unpredictable, uncontrollable, flexible, and autonomous, complex projects consist of many particularities [19]. Attempts are made to gain the best knowledge to explain project management practice, but project management cannot be practical in every context [20,21]. Complexity affects the entire life cycle of a given project, with ambiguous and unpredictable conditions having become one of the main concerns of researchers and practitioners [22,23,24]. Complexity is one of the critical factors in a project’s failure [9,25,26].

The issue of project complexity was first introduced by Turner and Cochrane [27], where uncertainty was assessed as one of the major factors of project complexity in the objectives and methods used in accomplishing projects. They focused on construction projects and arranged them within Types 1–4, ranging from Type 1, in which the objectives and methods are well defined, to Type 4, in which they are not well defined. Although they relied on Type 1, project complexity with a reductionist approach could be advantageous when establishing a fundamental background for a complex project. Therefore, it can be deduced that the focus of their paper is solely on uncertainty [27].

In 1996, Baccarini was the first to attempt to present project complexity by defining its two dimensions: (1) emphasize its differentiation and connectivity, and (2) introduce it as a subjective concept based on the difficulty and perception of the object. His emphasis was on structural project complexity, which is directly related to the integrity of communication, coordination, and control. In providing basic information about project complexity, his article makes a significant contribution. The structural aspect is viewed as the key element of complexity. However, in comparison, additional perspectives exist which should be of concern [28].

While many studies have been conducted on different aspects of project complexity, more accurate studies are needed in the contexts of various industries to better understand, assess, and respond to complex conditions. As the current study’s focus is solely on the IT industry, the available study factors and characteristics of complexity in IT projects were reviewed and assessed. Charette [29] identified unclear user requirements as a key factor contributing to IT project complexity. Jarvenpaa and Ives [30] highlighted the importance of executive management support as another complexity factor in IT projects, with this later discussed by other scholars [12].

J.P. Murray, in assessing the causes of IT project failure, identified complexity as a significant cause [31]. Agile philosophy and methodology are viable approaches to address IT project complexity and ensure project success. Scholars further identified the involvement of end-users as another complexity factor [31,32]. According to Nakatsu and Iacovou [33], problems associated with user involvement; unrealistic expectations; unclear statement of requirements; insufficient team familiarity with the project’s technical and business aspects; IT management support; and infrastructural constraints were considered key complexity factors. In 2013, the Project Management Institute (PMI) published PMI’s Pulse of the Profession In-Depth Report: Navigating Complexity which identified multiple stakeholders and ambiguity as two key characteristics of project complexity [20]. This approach has also been followed by many researchers, with other aspects of complexity, for instance, systems engineering, having been disregarded in this school of thought [5].

One of the common complexity factors in the IT projects discussed by scholars is the adoption of new technologies [31,32,34,35,36]. Ramasesh et al. [37] introduced a new term in project complexity, “unk unks”, a shortened form of ‘unknown unknowns’, to be applied to reduce project complexity, complicatedness, mindlessness, and pathologies. They focused on equivocality and dynamism in terms of complexity and sought to assist project managers in choosing the best project risk management styles. Poveda-Bautista [38] offered a classification of complexity factors in IT projects, with these divided into the following 11 groups: (1) objectives, requirements, and expectations; (2) interested parties, integration; (3) cultural and social context; (4) degree of innovation, general conditions; (5) project structure, demand for coordination; (6) project organization; (7) leadership, teamwork, decisions; (8) resources, including finance; (9) risks and opportunities; (10) project management (PM) methods, tools, and techniques, and (11) technology [38].

In total, 22 complexity factors in IT projects were extracted from the literature presented in

Table 1. Most cited complexity factors in IT projects.

No.	Complexity Factor	Morcov et al. (2020)	Montequín et al. (2018)	Poveda-Bautista et al. (2018)	Makui et al. (2018)	Deniss (2015)	Qureshi and Kang (2015)	PMI (2013)	Whitney and Daniels (2013)	Lee and Xia (2003)	Bosch-Rekveldt et al. (2011)	Vidal et al. (2011)	Azim (2011)	Nakatsu and Iacovou (2009)	Zolin et al. (2009)	Vidal and Marle (2008)	Müller et al. (2007)	Geraldi and Adlbrecht (2007)	Ewusi-Mensah (2003)	Murray (2003)	Schmidt et al. (2001)
1	New technologies	*	*	*		*		*			*		*	*	*	*		*		*	*
2	IT Manager/executive management support		*	*		*	*				*			*	*	*		*	*		*
3	Stakeholders’ technology illiteracy			*		*													*
4	Teams familiar with technical and business aspects of project		*	*										*						*	*
5	User involvement					*								*						*	*
6	Unclear statement of requirements	*	*	*		*			*						*
7	Unrealistic expectations	*	*	*		*								*
8	Transparency of mandate and objectives			*		*													*		*
9	Objectives’ dependency on the environment	*			*		*					*			*
10	Multiple stakeholders	*		*	*			*				*	*		*	*	*	*
11	Political issues		*				*				*				*	*		*
12	Stakeholder conflicts						*				*				*	*		*
13	New laws and regulations	*								*	*				*	*		*
14	Duration of the project	*					*	*			*						*	*
15	Number of departments involved	*		*							*				*
16	Number of project interfaces	*										*						*
17	High degree of dependency with the environment				*			*
18	Uncertainty in technical methods	*																*
19	Infrastructure constraints	*		*										*						*
20	Hidden mandate and objectives			*							*				*	*		*
21	Alignment of stakeholders’ interests										*
22	Iterative approaches and methodologies			*					*			*						*

. The critical factors of IT project complexity, identified from the literature, became the basis for the research design and development of the interview guide.

3. Research Design and Methodology

This study’s objective was the identification and prioritization of complexity factors in IT projects. Therefore, this research aimed to contribute to the knowledge of real-time events by enhancing the understanding of contexts, communities, and individuals through collecting data with a focus on discovering what is happening and capturing the picture of what is currently there [39]. To achieve this research objective, a multiple-case-study research design [40] was adopted to identify the factors that cause complexity in IT projects in two large Iranian organizations. The in-depth exploratory case study is among the popular research methods for investigating ICT projects and the complex issues associated with these projects, to mention a few [41,42,43]. As no appropriate criteria were available to evaluate the size of a project, large Iranian IT organizations were chosen, and their large projects characterized by a long duration, high cost, and a large number of stakeholders were examined. Cross-case comparison, combining theoretical propositions drawn from the literature with empirical data, was used to establish and refine key concepts and causal relationships [44] to develop a mid-range theory [45]. In the case selection, replication logic was followed, with each following case confirming or disproving the corollaries drawn from the previous case [46]. To maximize the possibility of developing plausible and rich mid-theory through understanding the key complexity factors in IT projects, within and cross-case thematic analysis and coding were applied [47].

Data analysis and interpretation were undertaken using thematic coding: after data collection, the coding process was applied [48], and the textual data were interpreted by identifying the themes/patterns [49]. The research process is shown below in Figure 2.

Step 1: Case and research interviewee selection

The cases were selected purposively, with the following criteria:

(1)

Providing access to face-to-face interviews and ensuring enough team members were willing to participate in the study.

(2)

Providing access to project reports that include delays, cost increases, lawsuits, etc.

(3)

The subject organization has an organizational structure of a project-based or strong matrix.

Two organizations that met the criteria were selected for the data collection. These are the dominant and leading companies in the IT industry in Iran, with more than 15,000 employees and a financial turnover of US$30 million.

In each case study, project team members with relevant managerial experience and expert knowledge of large IT projects were identified and invited to participate in the interviews. Interviewees were classified as service providers or clients based on their roles in the projects.

Table 2. Number of interviews conducted.

Interviewees	Case Study 1	Case Study 2	Total
Vendors	7	8	15
Clients	2	4	6
Total	9	12	21

presents the number of interviews conducted in each case study and category.

A pilot interview was conducted with a non-participating expert experienced in IT projects to improve the questions. According to Yin Robert, this measure contributes to adjusting the data collection in accordance with the data context [46].

Step 2: Data collection

Researchers collected data from multiple sources, which were triangulated to ensure the internal validity of the results [50]. Data were collected from three sources. The authors used archival materials and direct observations of projects as confirmatory evidence, in addition to 21 semi-structured interviews.

The 40–90 min semi-structured interviews were conducted with 21 interviewees, as summarized in

Table 3. Demographic profile of interviewees.

Demography		N	n (%)
Age	<32	2	9.5
	32–37	8	38
	37–42	8	38
	>42	3	14.5
Academic status	Graduate	0	0
	Postgraduate Doctoral	14 7	66.5 33.5
Total professional experience (years)	1–7	1	4.5
	7–12	11	52.3
	>12	9	42.8
Organization type	Private	12	57.1
	Public–Private	9	42.9
Total		21	100

, with nine from Case Study 1 and 12 from Case Study 2.

At the beginning of the interview, the interview guide, a short explanation of the research purpose, and a list containing the concepts with their definitions were provided to interviewees to ensure that they understood the questions. A brief summary of the research project was provided to each interviewee before the interview.

The data were collected between November 2019 and May 2020. The findings were continuously refined until they reached saturation point. This stage finished when no new insights were obtained from the data, the data analysis reached saturation and the mid-range theory emerged. This was followed by axial coding, in which the conceptually identical and related ideas and views were grouped to establish the relationships between the concepts [48].

Step 3: Data analysis: thematic analysis and coding

Open and axial coding

This study used abductive logic referring to the existing frameworks of project complexity factors [4,5] to run an iterative series of coding on the empirical data collected through the series of interviews.

Abductive reasoning was used to develop a mid-range theory explaining how different management styles, particularly the holonic management style, impact megaproject performance, outcomes, and realization of benefits. Abduction allows the integration of deductive reasoning from existing theoretical frameworks with inductive reasoning grounded in the researcher’s interpretation of the empirical data [51]. The current study used open and axial coding. In accordance with Coleman and O’Connor [48], the interview data were first analyzed using open coding, with data having the same semantic load being assigned the same codes.

Selective coding

The core categories must be selected, and their relationship with other categories must be determined. This prerequisite is to identify the similarities and dissimilarities in the concepts and select the final classification [48]. Figure 3 shows the classification of the codes in three steps.

External and internal validity of findings can be an issue for the explanatory case study [52]. Nevertheless, the study used sound theoretical underpinning and pattern-matching techniques to provide a good evidence base for its propositions.

The next step was to ensure the validity of the findings. A group of experts was selected from data collection interviews to confirm the results. The experts were selected based on their willingness to participate and the level of expertise they had gained from the project environment. This process involved data collection through a survey questionnaire distributed among 30 IT project management professionals (see Appendix A for the questionnaire questions).

Two industry experts ensured the validity of the questions by excluding any ambiguities. To assess the reliability of this questionnaire, Cronbach’s alpha method was applied with a 0.835 outcome. Following this, a 5-point Likert scale (1 = very low, 2 = low, 3 = medium, 4 = high, and 5 = very high) was applied to the results. The obtained results were analyzed and prioritized through the Friedman test in IBM SPSS statistical software. The steps taken in the research process are shown in Figure 3, and acronyms can be found in Appendix B.

4. Data Analysis and Findings

In general, the data obtained from the two case studies were analyzed and coded. In total, 41 codes were obtained, with these classified into eight categories. The following section summarizes the data obtained from each case and how they were categorized.

4.1. Case Study 1

Case Study 1 is an IT project management consulting organization, a subordinate of a public-private holding. This organization’s projects are completely subject to the holding’s requirements; that is, the client and the vendor are constituents of one organization. One of the reasons for choosing this case is its organizational structure which, due to the intra-organizational nature of the projects, is expected to face different complexities. The case project is the customization and configuration of an SAP R/3 enterprise resource planning (ERP) system for this holding. The project duration was 15 months, during which the interviews were collected.

In a total of nine interviews, interviewees were asked to share their opinions on the complexity factors affecting the SAP R/3 customization project and the causes for each factor. The two common factors in most project managers’ answers were the number of stakeholders and the lack of transparency in project requirements. Due to the large size of the client organization, coordination became an issue, with multiple coordination meetings needed. According to interviewees, the involvement of multiple departments made it hard to schedule and convene meetings to discuss project requirements. Due to the decentralized structure of the holding, effective centralized coordination was not possible with multiple unplanned and emergent setbacks. About 35% of scheduled meetings were cancelled from the beginning of the project, and about 45% of the key authority figures and critical stakeholders were absent from meetings.

From the content analysis, 21 codes were identified, which in the axial coding stage, revealed nine main complexity factors: (1) multiple and diverse stakeholders; (2) variety of product sub-systems and components; (3) constant changes in the project scope; (4) lack of transparency in project requirements; (5) challenges in controlling project progress for the client due to intangible nature of project outputs; (6) uncertainty in project objectives; (7) insufficiently qualified team members; (8) interdependencies between departments and the organization; (9) lack of trust.

In IT projects, end-users are the key stakeholders with a high impact on the project’s implementation. Dealing with a diverse range of stakeholders with various requirements contributes to the complexity of the project. Regardless of the project’s simplicity or complexity, effective communication is vital; in complex projects, trilateral communication is essential. According to the Pulse of the Profession In-Depth Report: Navigating Complexity published by the PMI [20], multiple stakeholders are the most important complexity factor. Four second-level codes were identified in the current study for this factor.

Large and specific IT projects have complex modules/components, usually either with multiple and complex components or many complex modules. This factor is considered one of a project’s technical factors, with evidence and data showing that it greatly impacts this type of management project. Therefore, two second-level codes were identified for this factor.

Change is inherent in IT projects, and manifests more in certain projects. Due to their features, user-based projects are constantly changing in all phases of the project, accompanied by challenges and complexities. Three second-level codes were identified for this factor.

The client’s needs constitute the cause of a project. Accurate and complete disclosure of these needs is essential, as the objectives will not be met if the project is not delivered correctly. For many reasons, the transfer of demands in certain types of IT projects is not accurate and complete. Often, the client does not correctly convey his/her intentions and purpose when defining the project to the vendor, indicating that obstacles may exist. Three second-level codes were identified for this factor.

The representation of Gantt charts and progress reports for IT projects comprises activities of an abstract nature for the client. In IT projects, clients have difficulty tracking the project’s progress due to the iterative and incremental nature of IT project delivery, which often follows an exponential pattern. Most clients expect to observe linear progress and regular deliverables throughout the project, sometimes causing challenges in the project manager’s relationships with clients. Two second-level codes were identified for this factor.

Project goals are often not appropriately defined. One of the important and necessary measures in the project initiation stage is to devise a project charter in which the project’s purpose is clearly expressed clearly, with this often not the case. Two second-level codes were identified for this factor.

Lack of relevant skills and expertise is another challenge in the project delivery process. One code was identified for this factor.

In some cases, the IT project covers several organizational departments, and their collective involvement creates additional pressure to deliver on time and to the standard. The involvement of senior management creates complex stakeholder relationships that negatively affect project parameters, such as quality, cost, or safety. Two second-level codes were identified for this factor.

Many IT projects handle classified network security or deal with access to sensitive data. In these projects, relevant levels of clearance and a level of trust between project team members are critical. The absence of trust between key stakeholders and project team members can significantly increase a project’s complexity. Therefore, trust between those in authority and project stakeholders is crucial, as is trust between the client organization and the vendor team members. Two second-level codes were identified for this factor.

4.2. Case Study 2

Case Study 2 is a holding company established in 1987, specializing in IT and communications technology projects, software production, and IT solutions. It comprises about 60 related organizations, which constitute the company’s subordinates, and is one of the largest active establishments in the IT area in Iran. The company specializes in IT projects, with one of the largest ERP projects in the country being implemented through this organization. The company’s organizational structure is a strong matrix type.

The organization delivers projects for external customer organizations, making the nature of its projects different from those in the first case, while some common factors are evident.

From the results of 12 interviews, content analysis and open coding, 20 s-level codes were identified, with these categorized into 13 complexity factors after axial coding. Among these, only four were common to both cases, while the rest were as follows: (1) technological newness of the project; (2) non-compliance of state regulations with the rapid change in IT; (3) multiple offshore teams; (4) cultural and regional variety of project teams; (5) traditional environment of the project context; (6) impacts of sanctions; (7) fitness of the managerial approach for the project; (8) number of interfaces in the project’s organization; (9) conflicting stakeholder objectives; and (10) lack of client-side knowledge and literacy of the project. Among these, multiple and diverse stakeholders, a variety of product sub-systems and components, constant changes in project scope, and lack of transparency in project requirements were common factors in Case Study 1.

The higher the novelty of the project, the higher the potential for risk and uncertainty. When a new technology with no antecedent is applied, complexity is inevitable, thus presenting the project manager with an unprecedented challenge. According to the experts, the newer the module(s) of a project, the more advanced the technologies applied therein, thus the greater the complexity created. Three second-level codes were identified for this factor.

One of the critical complexity factors that project managers had to address in this case was state regulations in the IT industry. With IT being a dynamic industry, regulations in this space have not been able to keep up with recent developments, creating uncertainty in the business environment and leading to unpredictable situations and unforeseen risks. In this context, one of the key factors is the incompatibility of Iran’s laws with the current industrial technology landscape, adding to the complexity of IT projects. Two second-level codes were identified for this factor.

The IT industry is a young and advancing industry; thus, new legislative rules and regulations have been imposed regarding some of its applications. This factor has a dramatic impact on project completion and, in some cases, enhances the project’s complexity. Two second-level codes were identified for this factor.

In large projects, teams are often distributed geographically. This imposes constraints and creates challenges in coordination and establishing communication between team members and across multiple teams. Two codes were identified for this factor.

Projects are implemented in different conditions, organizations, and environments. In IT projects, the context in which the project is being prepared for implementation has a significant impact on future issues, including society, the organization, or the corporation where the IT project is implemented. If these are subject to a traditional context, this will pave the way for complications in the project. Two codes were identified for this factor.

Most of the IT knowledge in Iran is imported, and easy access to those with this knowledge and the services therein is a vital issue. The existence of regulations and restrictions in this industry, to a certain degree, adds to the challenges for active organizations in this industry. With these limitations and/or the imposition of new constraints, certain types of IT projects are severely affected, thus presenting more challenges and complexities. Two codes were identified for this factor.

Projects in the Iranian IT industry often do not follow a specific project management (PM) methodology. Based on the evidence presented in the study’s interviews, following an inappropriate managerial approach to the project would lead to future challenges. One code was identified for this factor.

Most large-scale IT industry projects include multiple modules and sub-systems implemented by specific operational teams with different areas of expertise. In large-scale IT projects where each module is composed of different components, developer teams work on different sub-systems following the project’s master schedule. Difficulties arise during the integration of the interfaces of the project’s sub-systems. The components of a system constitute the prerequisite for another component, requiring the collective efforts of many teams with a variety of expertise. Two codes were identified for this factor.

A feature of IT projects is that they have many stakeholders, both individuals and groups, with different objectives being pursued. Project changes affect the interests of the groups involved. Often, stakeholders have conflicting goals, and this mismatch promotes complexity in IT projects. In projects where conflicts of interest or disagreement on the project’s goals are present, the management of the project can face unresolvable challenges even before the project begins. Two second-level codes were identified for this factor.

IT projects are implemented in different industry contexts, such as mining, infrastructure, or construction. Often, when an IT project manager does not fully understand the specifics of the industry for which the IT project is being implemented, complexity is created in terms of the difficulties faced by the client, contractor, or technical team. Three second-level codes were identified for this factor.

Projects are implemented subject to a variety of conditions, depending on the organization’s context and environment. The context in which the project is implemented dictates the project execution flow. The context is one of the factors which may lead to ‘soft issues’, including organizational hierarchy, politics, and internal dynamics, which ultimately affect IT project implementation. Two second-level codes were identified for this factor.

4.3. Findings

After content analysis and coding the interviews, 19 of 41 codes of complexity factors were identified. After selective coding, the complexity factors were grouped into the following eight broad categories: diversity, context, transparency, knowledge and skills, interdependency, trust, regulations, and sanctions, as shown in

Table 4. Project complexity factors and associated concepts in IT projects.

Complexity Domain	Coding Level 1	Coding Level 2
1 Diversity	Cultural and regional variety of project teams	1. Disagreements due to cultural differences among teams 2. Inconsistency in organizational rules and regulations with some cultures
	Technological newness of the project	1. Existence of new technology in the project 2. Inconsistency due to newness 3. Lack of previous experience
	Multiple and diverse stakeholders	1. Cultural and regional variety among stakeholders 2. Conflicts of interest between stakeholders 3. High number of involved groups and departments 4. Massive end-user population
	Multiple offshore teams	1. Lack of coordination between members of offshore teams 2. Difficulty in accurately controlling offshore teams
	Variety of product sub-systems and components	1. Applying specific modules for the first time 2. Complicated modules with high inter-component dependency
	Conflicting stakeholder objectives	1. Conflicts of interest between executive managers of the client team 2. Conflicts of interest between the client and vendor team
2 Context	Constant changes in project scope	1. Changes due to system feedback 2. Change orders issued from the client’s side 3. Changes regarding creep of project scope
	Traditional environment of the project context	1. Authorities’ resistance to change 2. Lack of organizational flexibility in accepting new technologies
3 Transparency	Lack of transparency in project requirements	1. Incomplete transfer of requirements on the customer’s side 2. Indirect connection of customer with the project team (existence of middlemen) 3. Client choice approach (inter-organizational executive authorities) to the project
	Challenges to controlling the project’s progress for the client due to intangible nature of project outputs	1. Lack of transparency of the project’s progress for the client 2. Non-linear nature of the IT project’s progress
	Unclear project objectives	1. Insufficient clarity of the project objectives 2. Poor definition of the requirements by the client
4 Knowledge and Skills	Lack of knowledge and literacy of the project on the client side	1. Extensive and destructive involvement on the client’s part 2. Non-cooperation with the project team due to lack of sufficient information 3. Unrealistic expectations of project results on the client side
	Insufficiently qualified team members	1. Insufficient skills and qualifications of team members
	Fitness of the managerial approach to the project	1. Lack of observance of a fixed methodology appropriate to the project’s dynamics
5 Interdependency	Interdependencies between departments within the organization	1. Different departments being affected due to disturbances in the project 2. Putting pressure on the project team from the client side
	Number of interfaces in the project organization	1. Undiagnosed roots of the problems in project interfaces 2. Lack of acceptance of responsibility by the teams after a problem occurs
6 Trust	Lack of trust	1. Lack of trust between key stakeholders 2. Lack of trust between the client and contractor teams
7 Regulations	Lack of compliance with state regulations with the rapid change in IT	1. Regulations adopted with delays 2. Lack of regulation in some IT fields
8 Sanctions	Impact of sanctions	1. Challenges with clearance and certification due to sanctions 2. Difficult and expensive access to support services of foreign vendors

.

A total of 19 key factors contributing to the complexity of IT projects were identified after assessing the common codes and categorizing them. Due to the richness of the data, an example of open and axial coding for only one complexity factor is shown in

Table 5. Open and axial coding for the factor “multiple and diverse stakeholders”.

Axial Coding	Open Coding	Quotations
CF1 Multiple and diverse stakeholders	CF1.1 Cultural and geographic variety among stakeholders	CF1.1.3 “Cultural variety among the stakeholders in large IT projects would face unpredictable challenges. Because the personnel requirements grow with the increase in variety, measuring and adapting this factor in projects is complicated. If we consider this factor, this cultural difference associated with different provinces would lead to high complexities”, Project executive officer, Case 1
		CF1.1.10 “One of the issues effective in IT projects complexity is the human factor. When individuals of different discriminations gain power, [they] seek to impose changes in the project management, which adds to the inherent complexities therein”, the IT manager, Case 1
	CF1.2 Stakeholders’ conflicting interests	CF1.2.6 “For instance, in a set-up with stakeholders having similar profit and loss, regardless of their volume, the task performance will be simple, while the same does not hold if they vary in their cultural backgrounds. Thus, complexity [occurs] in performance. This is evident in architectural organizations where stakeholders vary, thus, more complexity,” Project manager, Case 2
	CF1.3 Multiple users	CF1.3.6 “The magnitude of the project, its goal(s), purpose and service target in any society were indispensable. Sometimes projects were in the state, cartel, holding, corporation, and institution (company) orientation. Consequently, the complexity level varies according to the subject body. There exists a direct relation between project size and the challenges regarding complexity,” Project manager, Case 1
	CF1.4 High number of groups and departments involved in the project	CF1.4.8 “The departments’ involvement is so vital which can present the project with challenges. Assume that the HR department announces that ‘we do not accept this software,’ then the project would face problems regarding either the HR manager being fired or resigning or the segment of the project related to HR being eliminated”, Project manager, Case 2

. The coding process and the connections between interviewees and the complexity factors are demonstrated in Figure 3a,b.

After identifying the complexity factors, the next step was to determine the intensity of effects of each factor on project complexity. Questionnaires were distributed to the group of 30 experts to verify the identified factors and rank their importance using a Likert scale ranging from 1 to 5. The data were then analyzed using the Friedman test in the statistical package SPSS, with the output details presented in

Table 6. Results of Friedman’s test used to prioritize complexity factors.

Code	Factors	Very Low	Low	Moderate	High	Very High	Mean Rank	Priority
CF2	Variety of product sub-systems and components	0	6.7	20.8	53.3	19.2	15.38	4
CF3	Technological newness of the project	0	7.2	7.2	41.3	41.3	18.58	2
CF1	Multiple and diverse stakeholders	0	0	14.7	33.2	52.1	21.46	1
CF13	Constant changes in project scope	0	10.5	42.8	20.8	25.9	13.72	7
CF8	Lack of transparency in project requirements	0	19.2	11.3	26.7	42.8	14.3	6
CF15	Lack of knowledge and literacy of the project on the client side	0	14.9	58.5	12.3	14.3	6.81	17
CF6	Challenges to controlling the project’s progress for the client	7.2	0	54.3	31.3	7.2	5.73	18
CF17	Unclear project objectives	0	13.3	26.7	17.2	42.8	14.86	5
CF7	Insufficiently qualified team members	0	19	28.8	19	33.2	13.1	8
CF18	Interdependencies between departments and the organization	0	14.3	19	52.3	14.3	12.74	9
CF16	Lack of trust	0	7.2	31.3	53.8	7.2	8.51	15
CF4	Multiple offshore teams	0	7.2	42.8	35.2	21.4	12.2	10
CF11	Fitness of managerial approach to the project	15.4	23.1	31.3	7.2	23.1	5.31	19
CF9	Number of interfaces in project organization	15.8	14.1	14.1	33.2	25.9	11.28	11
CF19	Conflicting stakeholder objectives	0	7.2	14.1	42.8	35.9	16.84	3
CF12	Lack of compliance of state regulations with the rapid change in IT	0	7.2	42.8	28.6	21.4	9.82	13
CF5	Cultural and regional variety of project teams	0	19	31.3	30.7	19	10.7	12
CF10	Impact of sanctions	0	14.1	23.2	58.5	7.2	7.47	16
CF14	Traditional project environment	19.2	19.2	14.1	14.1	33.4	9.16	14

. As shown in Table 6, the factor with the highest priority was “multiple and diverse stakeholders”, with a mean rank of 21.46, followed by the “technological newness of the project” and “conflicting stakeholder objectives” factors, with mean ranks of 18.58 and 16.84, respectively. Conversely, the “fitness of managerial approach to the project” factor, with a mean rank of 5.31, is the lowest priority among all the complexity factors.

The interactions of the IT project complexity factors and their relationship to interviewees are presented in Figure 4.

The numbers and codes shown in Figure 4 correspond to Table 5 and Table 6. Complexity categories 1–8 indicate (1) diversity, (2) context, (3) transparency, (4) knowledge and skills, (5) interdependency, (6) trust, (7) compliance to regulations, and (8) sanctions, respectively.

Multiple and diverse stakeholders (CF1) have the following six factors categorized in “diversity (1)”: the variety of product sub-systems and components (CF2); technological newness of the project (CF3); multiple teams offshore (CF4); cultural and regional variety of project teams (CF5); and conflicting stakeholder objectives (CF19). This category includes the most important factors of complexity in IT projects which affect “trust,” “context,” and “interdependency.” An increase in diversity in different dimensions due to a lack of trust, extra-programmatic changes, and interdependencies between project elements leads to an increase in the complexity of project management. Management complexities due to factors relating to diversity are influenced by the project’s lack of knowledge and literacy on the client side.

As observed in the complexity factors in the IT (ITCF) model, complexities affected by the “context” category, consisting of the factors, constant change in project scope (CF13) and traditional environment of the project context (CF14), are partly affected by all categories, except the “interdependency” category. The category of “sanctions”, formed subject to (CF10), is ranked 18 of 19 factors according to the Friedman test prioritization ranking shown in Table 6. However, according to the ITCF model, this category has the greatest impact on other categories and especially has an impact on the “context”, “transparency”, “trust”, and “regulations” categories. The lack of knowledge and skills, which is considered one of the effective categories, is not affected by other categories but affects the complexities caused by the “context,” “trust,” and “diversity” categories.

5. Discussion and Conclusions

This exploratory study presents the analysis of the key complexity factors and their interdependency drawing on two case studies of large-scale IT projects, highlighting the role of context in specific manifestations of complexity factors. The proposed framework highlights 19 factors in eight complexity categories specific to the country and industry; this is an incremental step towards deeper understanding of project complexity in different contexts [4,5].

The existing literature defines a multiplicity of factors contributing to IT project complexity. Using the Friedman test, this study identified and prioritized 19 factors in eight categories. Multiple and diverse stakeholders, technological newness of the project, and conflicting stakeholder objectives have been ranked as the highest priority among the complexity factors. According to [20], the factor, multiple and diverse stakeholders, is the most important contributory factor creating complexity in IT projects. According to [53], the number of stakeholders is the most important factor in creating complexity after, the degree of interaction of working teams.

New technologies and incompetence in the use of technology [38] were the two project complexity factors which correspond with our findings, namely, lack of knowledge and literacy of the project on the client side and technological newness of the project.

The current study confirms the specificities of the IT project environment, verifying that the project complexity factors were greatly influenced by the context in which the project is implemented. The importance of technical, environmental, cultural, and geographic factors is recognized [54]. The model of IT project complexity factors prioritizes complexity factors and shows their interactions. Figure 4 shows the relationship between complexity factors in the two cases, highlighting aggregated non-linear impacts. Undoubtedly, sanctions as an external factor have significant impact on all other factors. It indirectly affects the law and regulations, causes changes in the project scope, overshadows the project goals, and creates uncertainties.

Thus, the question is ‘what PM approach is most efficient in driving project success in complex environments’? This is specifically important in developing leverage mechanisms and complex project management methodologies, to reduce project complexity and mitigate negative impacts on project success. For example, variety (1) manifests itself in the multiplicity of technologies driven by the number of distributed teams and resulting stakeholder conflicts requiring complex project methodologies to be applied to tackle complexity, such as, for example, Checkland or Rich Picture methodologies; specific context (2) in the observed cases suggests that there is an need to make provisions in the traditional ways of doing things to be able to cope with the fast pace changes in complex projects. The need for improving transparency (3) calls for adopting traditional process-driven or Agile Project Control Methodologies, such as Requirement Traceability Matrix, or User Stories. Insufficient knowledge both on the client and project execution teams’ side (4) exacerbates the issue. Project interdependencies (5) have a strong cross effect with the traditional environment, since change in one part of the system triggers the need for updates across other parts of the project and this is particularly challenging in the traditional conservative environments. The lack of trust (6) emerges as the underlying cause of the project complexity, while challenges to meeting the compliance requirements (7) are underpinned by insufficient knowledge and skills. Both factors require development of hard and soft skills in project teams, improving planning and control mechanisms. Finally, sanctions (8) as an external factor must be dealt with by means of improving existing behavioral and procedural characteristics of the project.

The analysis clearly highlights the leverage points in the project: transparency (3), knowledge (4) and trust (6). Project Managers, by focusing on improving PM practices to tackle identified issues, will be able to tackle internal and external complexity imposed by variety (1), context (2), interdependencies (5), regulations (7), and sanctions (8) to make a positive change and increase the rate of project success.

The existing literature discusses a range of complexity factors pertaining to various geographies and industry contexts, with the current study contributing to the understanding of complexity arising from traditional cultures. A range of factors specific to the context of the analyzed case studies have not been discussed in sufficient detail in previous studies, which makes this study’s findings a unique and incremental contribution to the existing body of knowledge. These factors comprise: the variety of product sub-systems and components; constant changes in project scope; lack of transparency in project requirements; challenges in controlling the project’s progress for the client due to the intangible nature of project outputs; insufficiently qualified team members; multiple offshore teams; lack of trust; lack of compliance of state regulations with the rapid change in IT; impact of sanctions; and the traditional environment of the project’s context.

This study informs and is useful for practitioners and software vendors operating in traditional cultures. It draws attention to the complexity arising from the IT project environment specific to large organizations. It also advises senior management of organizations about the necessity to devise and utilize alternative management approaches, as opposed to hierarchical approaches, to increase the rate of successful implementation of IT projects.

Due to the exploratory nature of the study and its geographic confinement to Iran, the proposed framework has limitations. It has to be tested in other geographic and cultural contexts. The proposed methodology for identifying complexity factors is replicable for testing in a variety of project organizations. Furthermore, strategies for the management of complexity in IT projects, managerial and leadership competencies to handle highly complex projects, and examining the relationship between project leadership in an uncertain environment, could be subjects for investigation in future research. This study aimed to address socio-technical and political complexities in the context of a special and unique country; other aspects of complexity, such as autonomy, connectivity, emergence, and structural complexities, could be further investigated, offering prospects for future research.