Original Research

Conceptualising a multidimensional model of information communication and technology project complexity

Nazeer Joseph

Received: 14 Dec. 2016; Accepted: 26 July 2017; Published: 02 Nov. 2017

Copyright: © 2017. The Author(s). Licensee: AOSIS.
This is an Open Access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract

Background: Information communication and technology (ICT) projects are different from other projects, such as construction, and require a new perspective to determine their true nature. The lacklustre state of ICT projects has plagued researchers and practitioners for decades as they are yet to understand why ICT projects do not perform. Literature places significant emphasis on success criteria and success factors for determining project success, but this is a unilateral view as the level of complexity involved is underestimated. ICT projects, however, are multifaceted as there are a number of dimensions that influence the management and outcome of a project.

Objectives: This article aimed to illuminate how the dimensions are interdependent and interconnected through the construction of a conceptual model of ICT project complexity.

Methods: Content analysis was used to identify and understand the various dimensions and facilitated construction of the model.

Results: The article identified five dimensions that affect ICT projects, viz. project success, project lifecycle, project complexity, project types and project methods. Each dimension was analysed to understand the key constructs and elements that need to be considered. The dimensions were mapped in a multidimensional model.

Conclusion: The multidimensional model of ICT project complexity can be used by ICT project managers to more effectively manage projects as they are provided with a greater understanding of ICT project influences.

Introduction

Information communication and technology (ICT) projects require a new perspective to determine their true nature. This is particularly important considering that ICT projects are used to realise organisational strategies (Chari, Devaraj & David 2007; Hu & Quan 2005; Kim & Sanders 2002). Organisations invest significant capital into ICT projects with the intention of catalysing improved organisation performance (Kalkan, Erdil & Çetinkaya 2011; Kossaï & Piget 2014). Literature asserts that there is a positive relationship between ICT investment and organisational performance (Farhanghi, Abbaspour & Ghassemi 2013; Hu & Quan 2005; Kalkan et al. 2011; Osei-Bryson & Ko 2004;). ICT projects do, however, have a bad reputation of lacklustre performance rates both internationally and within South Africa (Curtis 2012; Joseph, Erasmus & Marnewick 2014; Joseph & Marnewick 2014; Hastie & Wojewoda 2015; Marnewick 2012). The constant struggle of understanding why ICT projects do not perform has plagued researchers and practitioners for decades.

Literature places significant emphasis on success criteria and success factors for determining project success, but this is a unilateral view as the level of complexity involved is underestimated (Bosch-Rekveldt et al. 2011; Cooke-Davies 2002; Dvir et al. 1998; Geraldi, Maylor & Williams 2011; Hyväri 2006; Ika 2009; Vidal & Marle 2008; Westerveld 2003). Similarly, ICT project research revolves around success criteria and success factors (Chow & Cao 2008; Milis & Mercken 2002; Purna Sudhakar 2012; Tan 1996). ICT projects, however, are multifaceted as there are a number of dimensions that influence the management and outcome of a project. Research is yet to identify and analyse the various dimensions of ICT projects to address their waning performance. Five dimensions were identified and analysed through content analysis, viz. project success, project lifecycle, project complexity, project types and project methods. Each dimension consists of multiple constructs and elements that need to be considered throughout an ICT project’s lifespan. Moreover, understanding the intricacies of each dimension is essential to reimagine ICT project understanding. The notion is that a conceptual model of ICT project complexity can be constructed to illuminate how the dimensions are interdependent.

The article is structured as follows. The first section details the research methodology used to construct the conceptual model. The second section analyses the five dimensions and discusses the various constructs and elements that constitute each dimension. The design and construction of the conceptual model are presented in the third section. The final section summarises and concludes with an outlook for future research.

Research methodology

A systematic literature review in the form of content analysis was used as it facilitates the analysis of textual material (Flick 2014:429; Martens & Carvalho 2017; Pade, Mallinson & Sewry 2008). Schreier (2014:170) asserts that qualitative content analysis is a method for systematically describing the meaning of qualitative data and [t]his is done by assigning successive parts of the material to the categories of a coding frame. The key concepts were first highlighted prior to grouping similar points and ideas (Flick 2014:436; He et al. 2015). Table 1 shows the search criteria used for conducting the content analysis and the initial results.

Schön, Thomaschewski and Escalona (2017) assert that a strict search protocol must be established when performing content analysis. This research first identified the key concepts to be investigated then precise keywords were defined to assist the content search process. The search space was limited to six databases which covered the identified project management concepts. Forward and backward snowballing was also employed when performing the content analysis. Forward snowballing searches literature which has cited the literature in question, while backward snowballing searches the reference list of literature (Badampudi, Wohlin & Petersen 2015; Jalali & Wohlin 2012; Schön et al. 2017). The final process was to conduct a manual scan of the literature sources to ensure adequate concept representation and enable conceptual model construction (Asher 2013; Dube & Marnewick 2016; Schön et al. 2017).

Conceptualising a multidimensional model of information communication and technology project complexity

Project success

Project success is a misnomer in literature as multiple definitions and interpretations exist. Project success was initially determined based on the triple constraint of time, cost and quality (Ika 2009; Jugdev & Müller 2005; Todorović et al. 2015). However, it was realised that this perception was incomplete and stakeholder views had to be included, as well as benefits realisation (Baccarini 1999; Chih & Zwikael 2015; Joseph & Marnewick 2014; Lappe & Spang 2014; Marnewick 2016; Serra & Kunc 2015; Serrador & Turner 2015; Wateridge 1998). The proliferation of project management led to the inception of various standards and methodologies such as PMBOK^® Guide, P2M, APMBOK^®, PRINCE2 and ISO 21500. Table 2 indicates the varying perspectives regarding project success as each standard and methodology define the concept differently. The lack of consistency creates ambiguity around project success and distorts how it should be measured.

Researchers have embarked on expelling ambiguity around project success by empirically investigating what constitutes project success. Two distinct concepts encapsulate project success, viz. project management success and project product success (Baccarini 1999; Cooke-Davies 2002; De Wit 1988; Ika 2009; Jugdev et al. 2013; Van der Westhuizen & Fitzgerald 2005).

Two-dimensional view of project success

Project management success emphasises the project management process itself and how it was executed (Baccarini 1999). Project management success consists of 3 key criteria (Baccarini 1999; Camilleri 2011:18; Cooke-Davies 2002; Ika 2009; Pinkerton 2003:337):

• time, cost and quality
• quality of project management process
• stakeholder satisfaction regarding expectations during the project lifecycle.

Project product success places emphasis on the final output of a project and consists of 3 key criteria (Baccarini 1999; Camilleri 2011:18; Cooke-Davies 2002):

• realising project goal
• realising project purpose
• stakeholder satisfaction regarding the final project output.

While project management success may be differentiated from project product success, they are inseparable. Pinkerton (2003:344) asserts that [i]f the venture is not a success, neither is the project. Conversely, there is contention that the relationship between the two concepts is actually weak (Markus et al. 2000:344–345; Pinkerton 2003; Van der Westhuizen & Fitzgerald 2005; Young & Poon 2013). For example, there have been many cases (e.g. Sydney Opera House, Thames Barrier, Concorde) where projects were not delivered on time or within budget but were still deemed successful (Munns & Bjeirmi 1996; Pinto & Slevin 1988; Shenhar et al. 2005). Nevertheless, the contribution of project management success to project product success cannot be underestimated (Baccarini 1999; Ika 2009).

Four-dimensional view of project success

Shenhar et al. (2001) believed that the concept of project success was multidimensional in nature. The study revealed that project success constitutes four dimensions:

• Project efficiency: The constraints of time and cost are the focus of this dimension. There is a direct relationship between project success and project efficiency as the latter contributes considerably to the former (Serrador & Turner 2015). Mir and Pinnington (2014) however, argue that more emphasis should be placed on the other dimensions as project efficiency is the least important.
• Impact on the customer: This dimension focuses on the importance of meeting customer requirements and needs (Shenhar 2001). Achieving customer satisfaction hinges on meeting their expectations and ensuring they use the final product (Joseph et al. 2014; Jugdev & Müller 2005; Turner 1999; Wateridge 1998).
• Business success: Projects are a tool to realise organisational strategies and subsequently business success (Chih & Zwikael 2015; Peterson 2002; Serra & Kunc 2015). This agrees with the notion that project and organisational strategy should align as project performance has a significant impact on organisational performance (Aubry & Hobbs 2011; Longman & Mullins 2004; Mir & Pinnington 2014).
• Preparing for the future: A successful project should facilitate future developments for the organisation such as creating new markets, creating new products and/or services, as well as development of new technology (Shenhar 2001). This dimension not only focuses on long-term organisational benefits but also on positioning the organisation to exploit future opportunities.

This article sought to provide a comprehensive interpretation of project success and thus includes an expanded five-dimensional view to provide more insight.

Five-dimensional view of project success

Bannerman (2008) developed a five-dimensional view to further solidify what constitutes project success. The five dimensions are:

• Process success: Emphasis is placed on the project management lifecycle specifically (Bannerman 2008). Various processes around a project are assessed including generic processes such as risk management and specific processes such as software quality certification for ICT projects (Chrissis et al. 2007).
• Project management success: This dimension is comparable to Baccarini (1999) and Shenhar et al. (2001). Time, cost and scope are used as measurement criteria.
• Product success: Meeting the needs of the various stakeholders is at the core of product success (Bannerman 2008). For example, Van der Westhuizen and Fitzgerald (2005) and Petter, Delone and Mclean (2013) contend that ICT project success is directly influenced by the output of the projects such as an information system.
• Business success: Similar to the view of Shenhar et al. (2001), business success must be assessed to determine whether the project provided value and long-term benefits.
• Strategic success: Alignment between project and organisational strategy is paramount given that projects play a pivotal role in strategic success (Young & Grant 2015). A project must be clearly defined initially as this facilitates the organisational strategy alignment (Turner 1999:82).

Figure 1 provides a comprehensive overview of the three views of project success. Each project success element is mapped showing the overarching relationship between each view. Project management success maps to project efficiency and impact on customer of the four-dimensional view and process success, project management success and product success of the five-dimensional model. Project product success maps to business success and preparing for the future elements of the four-dimensional model, as well as business success and strategic success of the five-dimensional model.

FIGURE 1: Mapping project success dimensions.

Project success was initially defined by two dimensions but later progressed to include more dimensions to address ambiguity around the concept. Figure 1 implies that project success is not simply articulated as a number of dimensions should be assessed to determine true project success.

Project lifecycle

The ultimate goal of project management is to deliver an output whether a product, service or both. A project’s output is delivered via the execution of project management processes (Burke 2011:40–41; Project Management Institute 2013). The systematic structure of these processes constitutes the project lifecycle (Pinto & Winch 2016; Ward & Chapman 1995; Wideman 1989). Although literature is consistent regarding processes within a project lifecycle, the sources identified in Table 1 continuously direct to project management standards and methodologies and their perspectives regarding the project management process (Pinto & Winch 2016; Varajão et al. 2017; Wideman 1989). This article followed this route and subsequently discusses the project lifecycle as defined in two of the most prolific standards and methodologies (Grau 2013; Hällgren et al. 2012; Starkweather & Stevenson 2011; Svejvig & Andersen 2015), viz. PMBOK^® and PRINCE2.

Project management standards and the project lifecycle

The PMBOK^® Guide modelled project management processes around five systematic processes (Project Management Institute 2013): (1) initiating, (2) planning, (3) executing, (4) monitoring and (5) controlling and closing. PMBOK^® provides a generic approach to project management but does not detail specific process activities depending on project type. This does not bode well for ICT projects as they vary in terms of type, size and complexity. ICT projects require a more flexible and adaptive project management approach (Fernandes, Ward & Araújo 2014; Malach-Pines, Dvir & Sadeh 2009; Sheffield & Lemétayer 2013; Söderlund 2011).

PRINCE2 was designed specifically for ICT projects (White 2014). Similar to PMBOK^®, PRINCE2 provides various systematic processes and activities to be performed during a project’s lifecycle (The Stationery Office 2010). PRINCE2 details seven key processes when performing a project (Office of Government Commerce 2009): (1) starting up a project, (2) directing a project, (3) initiating a project, (4) controlling a stage, (5) managing product delivery, (6) managing a stage boundary and (7) closing a project. An initial comparison of PMBOK^® and PRINCE2 reveals that the processes differ marginally, and although there are more processes in PRINCE2, they can be directly mapped to the processes within PMBOK^®. PRINCE2’s systematic nature arguably implies that it also suffers from the same inflexibility as PMBOK^® even though it was designed for ICT projects.

The literature analysis revealed a limited view regarding ICT project’s lifecycle and processes. The content analysis was subsequently expanded to include industry-related project management methodologies to further enlighten ICT project lifecycles and processes.

Industry project management methodologies and the project lifecycle

Major ICT organisations took it upon themselves to develop project management methodologies, from practice and experience, for ICT projects. The three most widely used methods are: Accelerated SAP (ASAP), Oracle Unified Method (OUM) and Microsoft Sure Step.

SAP designed ASAP to facilitate the implementation of various SAP solutions and modelled it around PMBOK^® (Jain 2013; Musil & Hoeliner 2009; SAP 2010). This methodology focuses on six processes (Jain 2013; Musil & Hoeliner 2009; SAP 2010):

• Project preparation: Understanding project expectations and business needs, as well as initial planning, is the core of this process. Project preparation is analogous to the initiation and starting up process of PMBOK^® and PRINCE2, respectively.
• Business blueprint: The main focus is on gathering business requirements and developing detailed documentation. This process is analogous to the planning process of PMBOK^® and initiating process of PRINCE2.
• Realisation: This process has two sub-processes, viz. baseline configuration and final configuration. Baseline configuration ensures primary scope requirements are met while final configuration deals with scope exceptions not previously dealt with. Realisation is analogous to executing and monitoring and controlling process of PMBOK^®, as well as controlling and managing product delivery of PRINCE2.
• Final preparation: Activities included in this process are technical testing, end-user training and system management and cutover activities. Final preparation is analogous to the monitoring and controlling process of PMBOK^® and then closing a project process of PRINCE2.
• Go-live support: This process is analogous to the closing process of PMBOK^® and PRINCE2 as the main concern is to move the solution from a controlled project environment to operational environment.
• Operate: This process expands on the processes within PMBOK^® and PRINCE2 as continuous support is emphasised. Focus is on refining lifecycle standards, processes and procedures while ensuring they align with the organisation’s ICT and business strategy.

Similar to SAP, Oracle designed OUM to deploy Oracle solutions. OUM applies an iterative approach to managing ICT projects and is based on Unified Software Development Process (Oracle 2015). OUM revolves around five processes (Oracle 2015):

• Inception: Establishing project goals and objectives amongst the various stakeholders is the aim of this process. Inception is analogous to the initiating process of PMBOK^®, starting up process of PRINCE2 and project preparation process of ASAP.
• Elaboration: Initial scope and requirements are expanded during the elaboration process as more details are emphasised. These serve as the project benchmark. Elaboration is analogous to the planning process of PMBOK^®, initiating process of PRINCE2 and business blueprint process of ASAP.
• Construction: Developing and testing the solution are important during this process. Construction performs the same purpose as the executing and monitoring and controlling process of PMBOK^®, directing, controlling, managing product delivery and managing a stage boundary of PRINCE2 and realisation process of ASAP.
• Transition: During the transition process, the solution is either operationalised as a new system or replaces an older system. This process aligns to the monitoring and controlling as well as the closing process of PMBOK^®, directing, controlling, managing product delivery and managing a stage boundary of PRINCE2 and final preparation process of ASAP.
• Production: This process focuses on providing continuous support by monitoring the system and addressing any inherent issues not previously identified. Support, error and feature requests are continuously evaluated and prioritised for future release.

Microsoft Sure Step was designed to implement Microsoft Dynamics solutions (Microsoft 2013). The methodology includes both waterfall and iterative project management approaches. Sure Step includes six processes (Microsoft 2013; Shankar & Bellefroid 2011):

• Diagnostic: Gap analysis is performed as this facilitates the development of a business case for the proposed solution. Diagnostic is analogous to the initiating process of PMBOK^®, starting up process of PRINCE2, project preparation process of ASAP and inception process of OUM.
• Analysis and design: The analysis process is considered the official start of the project while the design process focuses on formulating a complete solution design. Although these are two separate processes, they do overlap. Both processes include the following activities, viz. developing a detailed project plan, functional requirements, communication and training plans, quality and testing standards, change control plan, technical design, core team training, prototyping and data migration design. Both processes are analogous to the planning process of PMBOK^®, initiating process of PRINCE2, business blueprint of ASAP and elaboration process of OUM.
• Development: Building, configuring and testing the functions and data underpin the development process. This process is analogous to the executing and monitoring and controlling process of PMBOK^®, directing, controlling, managing product delivery and managing a stage boundary of PRINCE2, realisation process of ASAP and construction process of OUM.
• Deployment: Focus is on transitioning to the new solution through user acceptance testing and training prior to final sign off. Deployment serves the same purpose as monitoring and controlling as well as closing process of PMBOK^®, directing, controlling, managing product delivery and managing a stage boundary of PRINCE2, final preparation process of ASAP and transition process of OUM.
• Operation: The final process performs the exact function as the operate process of ASAP and production process of OUM. The notion is to provide post-implementation support while addressing any inherent issues.

Traditional project management standards differ from industry project management methodologies as the latter include an operation or production process. This suggests that ICT projects should include a post-implementation process which focuses on ongoing support. ICT projects are considered more complex than other projects as there are multiple intangible elements which are difficult to assess. This influences the overall quality of ICT projects and could possibly be why they are often considered challenged or failures. The quality of an ICT project has a direct impact on expected organisational benefits (Gichoya 2005). It could, therefore, be argued that ICT projects should include an ongoing support process to address inherent issues.

Mapping project management standards’ and industry methodologies’ processes

Figure 2 maps the various project management processes and reveals that ICT projects should include the process of operating as they include a post-implementation process which focuses on ongoing support. The five standards and methodologies are arguably the same once mapped. Furthermore, although ASAP and OUM were created for ICT projects, they are still based on existing standards and methodologies such as PMBOK^® and Unified Software Development Process, respectively. This implies that all project management standards and methodologies apply the same principles and do not achieve the desired result of improved ICT project performance.

FIGURE 2: Mapping the various project management processes.

Projects are directly influenced by the increased level of complexity experienced today, especially ICT projects. The next section discusses the concept of project complexity and its inherent constructs.

Project complexity

Project complexity has been debated extensively in extant literature (Baccarini 1996; Cooke-Davies et al. 2007; Floricel et al. 2016; Geraldi & Adlbrecht 2007; Geraldi et al. 2011; Vidal & Marle 2008; Vidal, Marle & Bocquet 2007; Williams 1999; Whitney & Daniels 2013). Baccarini (1996:201) proclaims that complex projects demand an exceptional level of management, and that the application of conventional systems developed for ordinary projects have been found to be inappropriate for complex projects. This is further reiterated by Levin and Ward (2011:3) who argue that projects should be managed as complex systems to ensure they perform correctly. A consistent definition for project complexity is yet to emerge in literature regardless of the considerable research around the topic.

There are multiple views regarding what constitutes project complexity. Two decades of literature culminates in the identification of five project complexity constructs (Baccarini 1996; Bakhshi et al. 2016; Bosch-Rekveldt et al. 2011; Dunović et al. 2014; Floricel et al. 2016; Geraldi et al. 2011; Remington & Pollack 2007; Senescu et al. 2013; Vidal & Marle 2008; Williams 1999). The five constructs are shown in Table 3. These constructs represent the most frequently used terms and categories to define project complexity. Comparable underlying elements and features were identified, understood and logically mapped where different terms and categories were used.

Organisational complexity

Complexity surrounding the organisation itself is often underestimated (Baccarini 1996; Bosch-Rekveldt et al. 2011). A multitude of elements forms the foundation of organisational complexity:

• Vertical differentiation: This element assesses the number of levels in the organisational hierarchical structure, viz. structure depth (Baccarini 1996; Beyer & Harrison 1979).
• Horizontal differentiation: Organisational units and task structure are observed within this element (Baccarini 1996). Firstly, organisational units relate to a number of formal units such as departments, groups and functional units (Baccarini 1996; Dunović et al. 2014). Secondly, task structure is broken down further into two divisions, viz. division of labour and personal specialisation (Baccarini 1996).
• Size: Many features are included in this element. Emphasis is placed on project duration, variety of project management methods and tools, capital expenditure, work hours, project team, site area and number of locations (Bakhshi et al. 2016; Bosch-Rekveldt et al. 2011; Geraldi et al. 2011; Xia & Lee 2004; Padalkar & Gopinath 2016; Vidal & Marle 2008).
• Resources: Projects cannot be performed without organisational resources. This element pays attention to project drive (time, cost and quality), resource and skills availability, experience with involved parties, Health, safety, security and environment (HSSE) awareness, interfaces between different disciplines, number of financial resources and contract types (Bosch-Rekveldt et al. 2011; Brady & Davies 2014; Floricel et al. 2016; Geraldi & Adlbrecht 2007; Senescu et al. 2013; Vidal & Marle 2008).
• Project team: A fundamental component of projects is the project team. Various considerations around the project team include the number of different nationalities, number of different languages, cooperation with joint-venture partners and overlapping office hours (Baccarini 1996; Bakhshi et al. 2016; Geraldi & Adlbrecht 2007; Maylor, Vidgen & Carver 2008).
• Trust: Trust is a fundamental social construct required in project management that is based on trust in project team and trust in contractor (Bosch-Rekveldt et al. 2011; Geraldi et al. 2011; Killen & Kjaer 2012; Maylor et al. 2008; Smyth, Gustafsson & Ganskau 2010).
• Risk: Organisational risk influences project complexity, and risk management must be in place to mitigate risk (Bosch-Rekveldt et al. 2011; Floricel et al. 2016; Thamhain 2013).
• Interdependencies: Various interdependencies exist in organisational complexity, viz. environmental dependencies, resource sharing, schedule dependencies, interconnectivity and feedback loops in task and project networks, dependencies between actors, information system dependencies, objective dependencies, process interdependencies, stakeholder relations and team cooperation and communication (Brady & Davies 2014; Baccarini 1996; Lu et al. 2015; Padalkar & Gopinath 2016; Senescu et al. 2013; Tatikonda & Rosenthal 2000; Vidal, Marle & Bocquet 2011).

Technical complexity

Technical complexity was initially classified as technological complexity by Baccarini (1996). Extant literature has subsequently reclassified technological complexity as technical complexity after further investigation of project complexity constructs (Bosch-Rekveldt et al. 2011; Floricel et al. 2016; Remington & Pollack 2007; Nguyen et al. 2015). This construct consists of:

• Differentiation: Projects follow processes which require various inputs and outputs during their lifecycle. This element specifically considers the number and diversity of inputs and/or outputs (Baccarini 1996; Brown 2008; Geraldi et al. 2011; Green 2004).
• Goals: Multiple goals are pursued when performing a project. This element takes an expanded view of goals and considers the number of goals, goal alignment and clarity of goals (Baccarini 1996; Bosch-Rekveldt et al. 2011; Floricel et al. 2016; Geraldi & Adlbrecht 2007; Maylor et al. 2008; Tatikonda & Rosenthal 2000; Vidal & Marle 2008; Williams 1999).
• Scope: Various technical features influence the scope of a project, viz. scale of scope and quality requirements (Bosch-Rekveldt et al. 2011; Floricel et al. 2016; Geraldi & Adlbrecht 2007; Vidal & Marle 2008).
• Tasks: Project tasks can be more technical in nature as the number of tasks, variety of tasks and conflicting norms and standards influence project complexity (Bosch-Rekveldt et al. 2011; Geraldi & Adlbrecht 2007; Senescu et al. 2013; Vidal & Marle 2008).
• Experience: Project teams are particularly influenced by this element as experience is essential when performing projects. Newness of technology and experience with technology are two experience features which must be consider (Baccarini 1996; Bosch-Rekveldt et al. 2011; Dunović et al. 2014; Geraldi & Adlbrecht 2007; Nguyen et al. 2015; Tatikonda 1999; Thomé et al. 2016; Vidal & Marle 2008).
• Risk: Risks associated with technology is at the core of this element (De Bakker, Boonstra & Wortmann 2010; Bosch-Rekveldt et al. 2011; Schwalbe 2013; Javani & Rwelamila 2016; Tatikonda & Rosenthal 2000).

Environmental complexity

Organisations operate in environments which can be considered more volatile in recent years (Heaslip 2015; Kappelman, Mckeeman & Zhang 2007). Projects are subjected to these environments as they both directly and indirectly influence project complexity and outcomes (Cooke-Davies et al. 2007; Geraldi et al. 2011; He et al. 2015). Environmental complexity consists of the following elements:

• Stakeholders: There are a number of stakeholder features which influence project complexity, viz. number of stakeholders, variety of stakeholder perspectives, political influence, internal support and required local content (Baccarini 1996; Bosch-Rekveldt et al. 2011; Dunović et al. 2014; Geraldi & Adlbrecht 2007; Geraldi et al. 2011; Remington & Pollack 2007; Vidal & Marle 2008; Williams 1999).
• Location: It is paramount to understand the location dynamic of a project and the following should be considered, viz. interference with existing site, weather conditions, remoteness of location and experience in country (Bosch-Rekveldt et al. 2011; El-Rayes & Moselhi 2001; Floricel et al. 2016; Nguyen et al. 2015; Sohi et al. 2016; Yang, Huang & Hsu 2014).
• Market conditions: Market conditions play internal and external influencing roles in projects. Specific attention should be paid to internal strategic pressure, stability of project environment and level of competition (Bosch-Rekveldt et al. 2011; Dunović et al. 2014; Floricel et al. 2016; Geraldi & Adlbrecht 2007; Geraldi et al. 2011; Maylor et al. 2008; Senescu et al. 2013).
• Risk: Environmental risks which are either manmade or natural must be considered within any project type (Bosch-Rekveldt et al. 2011; Dunović et al. 2014; Floricel et al. 2016; Remington & Pollack 2007).

Uncertainty

The concept of uncertainty was originally observed in general management and subsequently propagated to project complexity (Geraldi et al. 2011; Williams 1999). Both the present and the future are captured by uncertainty as both the current and future states of each of the elements that make up the system being managed (Geraldi et al. 2011:976). Six underlying elements underpin uncertainty:

• Triple constraint: This element assesses uncertainty by focusing on the features of time, scope and cost (Bosch-Rekveldt et al. 2011; Geraldi & Adlbrecht 2007; Geraldi et al. 2011; Maylor et al. 2008; Remington & Pollack 2007; Thomé et al. 2016).
• Activity: Regardless how well a project is planned, there is always a level of uncertainty regarding activities to be performed. Activity uncertainty focuses on uncertainty in methods as well as task uncertainty (Bosch-Rekveldt et al. 2011; Dunović et al. 2014; Geraldi & Adlbrecht 2007; Geraldi et al. 2011; Maylor et al. 2008; Tatikonda & Rosenthal 2000; Vidal & Marle 2008; Williams 1999).
• Goals: This element focuses on one feature, viz. uncertainty of goals and objectives (Dunović et al. 2014; Geraldi et al. 2011; Lu et al. 2015; Maylor et al. 2008; Williams 1999).
• Technology: Technology changes and evolves at a rapid rate. Technological maturity and novelty are two key features which contribute to technology uncertainty within a project (Dunović et al. 2014; Geraldi & Adlbrecht 2007; Geraldi et al. 2011; Maylor et al. 2008; Remington & Pollack 2007; Tatikonda & Rosenthal 2000).
• Stakeholders: Stakeholders uncertainty is driven by undisclosed participants and stakeholder competency (Geraldi 2008; Geraldi et al. 2011; Maylor et al. 2008).
• Information: Projects thrive on information and the more complete and accurate the information, the greater the chance of delivering the expected benefits (Geraldi et al. 2011; Maylor et al. 2008; Vidal et al. 2007). Incomplete information stifles project progress and project success (Babar, Ghazali & Jawawi 2014; Dekkers & Forselius 2007; Marnewick 2013).

Dynamics

The project complexity construct of dynamics encapsulates complexity around project change management (Geraldi et al. 2011; Maylor et al. 2008). Change management is inevitable during projects as goal and scope changes are particularly evident (Hwang & Low 2012; Ibbs, Wong & Kwak 2001;). Internal and external factors influence project change (Love et al. 2002). Internal factors include inter alia, poor budgeting, shortage of resources, lack of departmental integration and poor stakeholder engagement (Hwang & Low 2012; Ibbs et al. 2001). External factors include inter alia, government interference, economical challenges, legal disputes and weather anomalies (Hwang & Low 2012). These factors are arguably related to the elements and features discussed within environmental complexity. Change management is the core element of this construct with focus on the change process, number of changes, scope of changes, frequency of changes, impact of changes and change over time (Geraldi & Adlbrecht 2007; Geraldi et al. 2011; Love et al. 2002; Muller, Geraldi & Turner 2012; Remington & Pollack 2007; Whyte et al. 2016).

Literature argues that technology is the key driving factor determining project type (Müller & Turner 2007a, 2007b; Shenhar 2001; Shenhar & Dvir 1996; Shenhar et al. 1997, 2001, 2016). Project type, therefore, plays an influential role when managing ICT projects. Furthermore, this compounds the level of project complexity as it adds another management dimension.

Project types

The evolution of project management brought about the notion that all projects are the same. In reality, there are stark differences between projects. Pinto and Covin (1989) assert that

the prevailing tendency among the majority of academics has been to characterize all projects as fundamentally similar…the implicit view of many academics could be represented by the axiom ‘a project is a project is a project. (p. 49)

Shenhar and Dvir (1996) subsequently developed a model which details four types of projects: (1) low tech, (2) medium tech, (3) high tech and (4) super high tech. These project types follow a sliding scale based on the level of technological uncertainty. Low tech projects have a low level of technological uncertainty while super high tech projects have a very high level of uncertainty. The four project types are characterised as follows:

• Low tech projects: These projects employ existing and familiar technologies which can be reused (Shenhar 2001; Shenhar & Dvir 1996; Shenhar et al. 2016). Low tech projects exhibit very low technological uncertainty. For example, ICT infrastructure projects, such as local area network deployment, primarily use standardised networking equipment.
• Medium tech projects: Medium tech projects are similar to low tech projects as they use existing technology but adapt them accordingly (Shenhar 2001; Shenhar & Dvir 1996; Shenhar et al. 2001). These projects also incorporate a restricted amount of new technology to facilitate competitive advantage. For example, customisation projects often aim to update existing systems and technologies to meet project needs, for example, upgrading a wired network to include wireless access points to allow wireless connectivity.
• High tech projects: High tech projects implement a number of new technologies for the first time (Shenhar 2001; Shenhar & Dvir 1996; Shenhar et al. 2016). Greater uncertainty exists as the project manager and team have minimal experience using new technologies (Dvir, Sadeh & Malach-Pines 2006; Tatikonda & Rosenthal 2000). For example, enterprise resource planning projects are often implemented to replace current systems and employ a vast amount of new technologies which work in tandem to create a fully integrated organisational ICT system.
• Super high tech projects: Super high tech projects use untested technologies to achieve project goals (Shenhar 2001; Shenhar & Dvir 1996; Shenhar et al. 2001). An extreme degree of uncertainty exists during these projects as emerging and/or non-existent technology is developed for the project. For example, Nvidia and Microsoft aim to reshape servers to incorporate deep learning and artificial intelligence as this would enable organisations to exploit data and automate functions for improved organisational performance (Freund 2016).

Project methods

ICT projects make use of various project management methods or approaches. Software development projects, in particular, have catalysed the development of new methods. This section aims to illuminate four prevalent methods adopted for ICT projects, viz. software development lifecycle (SDLC), agile, DevOps and Lean:

• SDLC primarily relied on the waterfall model as it provided a systematic procedure for developing software solutions. The waterfall model is implemented in a sequential manner, and each phase is completed before moving onto the next (Sommerville 2011:30–31). The phases include (Sommerville 2011:30–31; Tsui & Karam 2011:76–77) requirements definition and agreement, system and software design, coding, testing and integration. Waterfall, however, does not accommodate for ongoing requirement changes which are inevitable. Furthermore, iterations can be costly and require significant rework which results in incomplete or omitted requirements.
• Agile methods were introduced to address weaknesses of waterfall. Extreme programming (XP) and Scrum are the two most prevailing methods (Dingsøyr et al. 2012; Misra et al. 2009; Van Waardenburg & Van Vliet 2013). XP and Scrum have different lifecycles but maintain the essence of iterative project development (Leffingwell 2010:14; Schwaber 2004:9). XP and Scrum may be considered independent methods but Sommerville (2011:72) asserts that they can be used together. This implies that other agile methods can be used together when deemed applicable.
• DevOps was developed to address the disjoint between development and deployment (De Bayser, Azevedo & Cerqueira 2015; Fitzgerald & Stol 2017; Virmani 2015). DevOps was created to meet the needs of large organisations which are developing large, complex ICT solutions (Fitzgerald & Stol 2017). This method focuses on software and infrastructure development, deployment and integration (Cois, Yankel & Connell 2014). DevOps centres around four principles (Fitzgerald & Stol 2017): (1) culture, (2) automation, (3) measurement and (4) sharing.
• The philosophy of lean is embodied by five principles (Browaeys & Fisser 2012; Putnik 2012; Wang, Conboy & Cawley 2012; Womack & Jones 2013): (1) value, (2) value stream, (3) flow, (4) pull and (5) perfection. Lean project management contrasts traditional project management not only in the goals it pursues, but also in the structure of its phases, the relationship between phases and the participants in each phase (Ballard & Howell 2003:119). Reusch and Reusch (2013) assert that the following principles should be included alongside the above five principles for lean project management to exist: increase learning, make timely decisions, empower the project team and establish integrity, as well as have a holistic view.

Multidimensional model of information communication and technology project complexity

The content analysis revealed that achieving project success is more difficult than initially perceived as there are many dimensions to ICT projects. A multidimensional view should be considered to illuminate and understand the complex nature of ICT projects. A multidimensional model of ICT project complexity is depicted in Figure 3.

FIGURE 3: Multidimensional model of information communication and technology project complexity.

The first dimension represents ICT project complexity and its inherent constructs. The second dimension addresses the four ICT project types while the third dimension focuses on the four project methods employed. The fourth dimension focuses on an ICT project’s lifecycle and its processes. As argued above, ICT projects are naturally complex which should include a post-implementation process (operating) that focuses on ongoing support. The fifth and final dimension is the mapping of project success components to the preceding four dimensions.

As this is a conceptual model, a logical mapping approach was used to map the project success components. Table 2 shows the mapping of different views of project success. The components within the model were extracted from the two-dimensional view of project success as Baccarini (1999) explicitly detailed what each dimension constitutes. The components were subsequently mapped as follows:

• The time, cost and quality are mapped to the methods dimension as the project methods primarily dictate how the resources of time and cost are utilised. Furthermore, quality can also be determined by the method/s adopted. For example, significant focus is placed on delivering quality solutions when agile is adopted for ICT projects.
• Quality of project management process is mapped to the entire project lifecycle as quality is determined by the effectiveness of each process. The notion is that each process will perform as required if they are understood and implemented correctly.
• Stakeholder satisfaction relating to the project management process is mapped to initiation, planning, executing and monitoring and controlling. Similar to quality of project management process, stakeholders should be satisfied that these four processes were performed correctly to realise the project goal.
• Stakeholder satisfaction relating to the output of the project is mapped to the lifecycle processes of closing and operating. During these processes, stakeholders have a different view of success as more emphasis is placed on the final outcome of the project. Furthermore, stakeholders begin to evaluate whether the projects’ output meets their goal and objectives as determined during the preceding processes of initiation and planning.
• Similarly, project purpose is mapped to the closing process as this process focuses specifically on whether stakeholders’ requirements and expectations were met and benefits were realised. Project purpose is a short-term view of project success as immediate benefits and expectations are measured.
• Project goal centres on meeting the strategic goals and objectives. This aligns to the operating process where refinement is pivotal to ensure alignment with the organisation’s ICT and business strategy. Project goal, therefore, has a long-term view of project success as long-term benefits and expectations are measured.

Conclusion

ICT projects are infamous for their lacklustre performance and thus require a new perspective to understand the various complexities facing ICT projects. Achieving ICT project success is more difficult than initially perceived as there are many dimensions to consider. This article applies content analysis to illuminate and understand the various dimensions of ICT projects. Five concepts were investigated, viz. project success, project lifecycle, project complexity, project types and project methods. The article established that each concept constitutes a dimension effecting ICT projects. A multidimensional model of ICT project complexity was developed to illustrate how the dimensions are interdependent.

A number of contributions exist in this article. Firstly, the article identifies five dimensions which affect ICT projects. Secondly, each dimension is analysed to understand the key constructs and elements which need to be considered. Thirdly, the dimensions are mapped in a multidimensional model which can be used by practitioners to more effectively manage projects as they are provided with a greater understanding of ICT project influences. Finally, the conceptual model serves as the foundation for future research to reimagine ICT project management and move away from the unilateral view which is commonly depicted.

The research article does, however, have limitations. Firstly, the qualitative nature of content analysis has inherent issues around subjectivity as the dimensions, and constructs thereof, could be interpreted and understood differently by various individuals. In-depth conceptual mapping workshops with ICT project managers could be performed to gain a more comprehensive view of the dimensions and their constructs. Secondly, the content analysis cannot be considered exhaustive as not all academic databases were searched. It could be argued that there are other literature sources relevant to the search concepts which are yet to be discovered. Future research could consult other databases to validate, expand or contest this article’s analysis. Finally, a drawback of a conceptual model is that it has not been empirically validated thus questioning its viability. Future research should test the model and update it accordingly to ensure real-world practicality.

ICT project management research has increased over the past years yet no practical improvement has been realised. This begs the question: Has ICT project management research stagnated or reached a limit? This stagnation can only be resolved by embarking on initiatives which boldly rethink and reimagine the concept of ICT project management.

Acknowledgements

The authors declare that they have no financial or personal relationship(s) that may have inappropriately influenced them in writing this article.

References