The Effect of Expertise on Project Complexity

Project complexity has commonly been cited as a major cause of poor project performance (Alahmad et al, 2019). Although literature has identified various methods to measure and define project complexity, research insights did not find an explanation of how to reduce project complexity or its effect on project performance. Expertise has been identified as a potential solution; however, little is known about the extent of impact that expertise may have on project complexity. Using a multimethod approach inclusive of literature, survey and interview research we investigate the “effect’ of expertise on project complexity. We analyzed the effect of expertise on 22 unique project complexity factors. Data consists of 97 survey respondents and 15 interview participants. The research led to the following results which should be incorporated into future models: (1) expertise reduces project complexity, (2) experts do not perceive ICT projects as complex while nonexperts perceive ICT projects as complex, and (3) experts’ challenges that relate to project complexity factors correspond to project stakeholders as they ultimately fall outside the control of the expert.


Introduction
The information communications technology (ICT) industry has struggled with performance issues for years (Kashiwagi, 2018a) with failure to be completed on time and on budget as high as 84% (Standish Group, 1994). Many countries including the Netherlands, Australia and the United Kingdom have performed governmental inquiries due to massive losses on ICT projects (Legislative Assembly of the Northern Territory, 2014; Public Administration Committee, 2011; The House of Representatives of the Netherlands, 2014).
Project complexity has commonly been cited as the cause of poor project performance (Alahmad et al, 2019;Xia & Lee, 2004;Sauer & Cuthbertson). The Standish Group (2016) identified 14% of "very complex" projects are completed on time, on budget and with a satisfactory result for the client. Sauer and Cuthbertson (2003) analyzed data collected from 1,500 practicing ICT project managers and identified project complexity resulted in lower project performance in terms of being on time and on budget. As the ICT industry becomes more integrated into society through technological advances and automation, firms require approaches and solutions to handle project complexity in order to stay in operation (Bakhshi et al., 2016;Qureshi & Kang, 2014).

Project Complexity
Literature provides multiple definitions of project complexity; however, there is not a generally accepted definition (Vidal & Marle, 2008). The majority of research in project complexity has focused on measuring project complexity through the project conditions inclusive of structural, uncertainty, socio-political, and dynamic complexity. Structural complexity relates to the manyvaried interrelated parts of a project described by the attributes of size (number), variety and interdependence (Baccarini, 1996;Geraldi et al., 2011;Williams, 1999). Uncertainty includes the understanding of the current state; how current factors will interact and the impact of those factors on the future state of the project. Uncertainty factors can be described by the attributes of experience, novelty, ambiguity and availability of information (knowledge). Socio-political complexity relates to the people within a project which have potentially conflicting interests and difficult personalities (Geraldi et al., 2011;Maylor et al., 2008;Rolstadas et al., 2017). Sociopolitical complexity can be described by the attributes of the stakeholders' project priority, support, and agreement/fit. Dynamic complexity relates to changes which occur in a project. Dynamic complexity can be described by the attributes of adaptability, flexibility and alteration (Geraldi et al., 2011).
Complexity has been identified to not only deal with the project conditions but the perception of those conditions by the individual. Geraldi et al. (2011) performed an analysis on existing complexity measurements and identified that, in the end, project complexity is largely dependent on how an individual perceives and responds to the project conditions. In reflection they noted that the focus on the individual was not fully represented in existing complexity models. Tie and Bolluijt (2014) identified that the project team is usually responsible to manage project complexity. Based on this assumption, project complexity should not be solely defined based on the project conditions but should include the expertise of the individual or team executing the project. This is not a new idea, expertise has been regularly suggested to reduce complexity and improve performance (Arisholm et al., 2007;Buckland & Florian, 1991;Francis & Gunn, 2015;Qureshi & Kang, 2014). Based on the evident importance of expertise, some researchers have proposed to redefine project complexity by focusing on the expertise of the supplier or individual performing the project rather than the project conditions (Tie and Bolluijt, 2014;Vidal et al., 2011;Xia and Chan, 2012).

Research Question and Methodology
Kashiwagi (2018b) analyzed 19 different project complexity models and identified that researchers have built various methods to measure and define project complexity. Research has not yet found an explanation of how to reduce project complexity or its effect on project performance. Expertise has been identified as a potential solution (Kashiwagi, 2014); however, little is known about the extent of impact that expertise may have on project complexity.
The aim of our research is to develop a better understanding of the "effect" of expertise on ICT project complexity, measuring the "effect" through project performance. This research avenue may open new insights to handle project complexity and consequently improve project performance. In order to achieve our aim, our research questions (RQs) to be explored include: ~ 101 ~ • RQ1: What factors define project complexity? • RQ2: What is the effect of the supplier's expertise on project complexity factors? • RQ3: What challenges do experts and nonexperts have with respect to project complexity?
To meet our aim, a multi-method approach was taken using a literature review, survey and interview research. First, a literature review was conducted as a suitable method to identify relevant factors by which ICT project complexity can be defined (RQ1). The literature review identified publications which have already defined a unique list of project complexity factors. Secondly, through survey research and interviews (RQ2 and RQ3) the effect of the supplier's expertise on individual project complexity factors was measured using project performance as the scale to measure the "effect", see Figure 1.

Literature Review Methodology
A literature review was performed, inclusive of four research databases (Engineering Village, Emerald Insight, ProQuest, Google Scholar). The terms "project complexity" + "complexity models" + "complexity factors" were used as keywords. The keywords were searched in each of the four databases within the first 500 publications. Publications were selected through the following process: 1. The publications had to be available in full text English. 2. The abstracts were reviewed and filtered based on the relation to project complexity factors. 3. The publications were fully reviewed and filtered based on the contribution of a unique list of project complexity factors.
The search resulted in the review of 2,000 publications' abstracts of which 19 publications were identified to relate to our research as they provided a unique listing of project complexity factors. When studying the 19 publications, we identified 623 project complexity factors. The publications' factors were refined through an exclusion/exclusion process. Factors included were directly related to the project including stakeholders and the scope of work. This corresponds to Azim et al. (2010), which identified the distinction between project complexity factors which relate to the people component of the project (stakeholders) and the product/service (scope) being delivered. Factors we excluded were contextual factors and ambiguous factors.
To analyze the factors, we built on Miles and Huberman (1994) by using a two-stage coding process to identify a broad range of "project complexity factors" as a proxy to measure ICT ~ 102 ~ project complexity. In the first stage of coding, the factors were clustered into two components of the project relating to the project stakeholders or project scope. After the coding of data within the designated components, the second stage involved coding the factors into subgroups based on the similarity of wording and content to create a coherency.

Survey Methodology
To answer our second research question, we conducted a survey (based on the factors identified in our literature review) and asked respondents to individually rate each of the project complexity factors' likelihood to be a cause of low project performance in two situations: (1) with an expert supplier and (2) with a nonexpert supplier. The survey included the responses of 97 practitioners involved in ICT projects. The scale ranged from 1 = Extremely Unlikely, 2 = Unlikely, 3 = Neutral, 4 = Likely, and 5 = Extremely Likely (See Figure 2). We then measured the effect of expertise on project complexity using project performance (on time, on budget and client satisfaction) as the scale of measurement.
In our analysis we first used the Wilcoxon signed-rank test to compare the expert scores with the nonexperts scores to determine if there was a significant difference between the effect on project complexity factors and expertise. We then compared the differential between the expert and nonexpert scores and the frequency of scores for the expert and nonexpert. Lastly, we examined the scores of the expert and nonexpert using the median, mode and mean to prioritize and compare factors.

Interview Methodology
We conducted interviews with 15 practitioners involved in ICT projects to elaborate on the research findings from the survey research. Three criteria were used to determine eligibility inclusive of background (country, role and position), years of experience (minimum of five) and nonresponsive to the survey.
All interviews were conducted via video conferencing due to the geographical location of the participants in the period of October and November of 2018. Interviews varied from 25 to 50 minutes in length and we used a semi structured design. Applying a semi-structed interview method as a research instrument allowed us to elaborate on the findings through probing and discussion. The primary objective of the interviews was to elaborate on the research findings. Survey protocol instructions were sent to all interviewees prior to being interviewed. The protocol contains background and purpose of the research, instructions to the interviewee and the research findings which would be discussed.

Literature Review Results
Based on our analysis and coding of the 623 factors, we derived a summarized list of 22 factors that influenced project complexity (see Table 1). These factors can be divided into two main components of the project, namely factors that relate to project stakeholders (8) and project scope (14). With the identification of the 22 project complexity factors it allows a more objective and standardized way to understand and quantify project complexity. ~ 104 ~

Survey Results
The Wilcoxon signed-rank test showed that the expertise of the supplier elicits a statistically significant change in the likelihood to be a cause of low project outcomes in the case of all 22 project complexity factors (α of .05, p = 0.000), see appendix A for full tables results. Upon further comparison of the respondents' scoring between the expert and nonexpert it was identified that expertise reduced the likelihood of poor performance caused by the project complexity factors. On average for each of the 22 individual project complexity factors 79% of respondents identified expertise to reduce performance issues caused by the project complexity factors, 19% identified no effect and 2% scored the expert more likely (see Table 2). Expertise has no effect on performance issues caused by project complexity factor. 19% 7% 44% Expertise increases performance issues caused by project complexity factor. 2% 1% 7% Analyzing the frequency of the respondents scoring it was identified that on average for each of the 22 factors, the expert would unlikely have poor project performance due to the project complexity factors (58% unlikely, 22% neutral, 20% likely). In contrast, it was identified that the nonexperts would likely have poor project performance due to the project complexity factors (81% likely, 16% neutral, 3% unlikely). (See Table 3, for full results see Appendix A). Lastly, we examined expert and nonexpert scores by the median, mode and mean (see Table 4). It was identified that the majority of expert scores were below three (unlikely a cause of low performance) while all of the nonexpert scores were above three (likely a cause of low performance). In further analyzing the expert scores, it was identified that 5 out of the 8 stakeholder related factors were within the top scores of the median, mode and/or mean. In contrast 2 of the 14 scope related factors were within the top scores for the mode and mean. In analysis of the nonexpert scores it was identified that the nonexpert struggles with all 22 project complexity factors (above neutral scoring), more so with scope factors than stakeholder factors. For the nonexpert, in the case of stakeholder factors, six out of eight of the factors were within the lowest scores for the median, mode and/or mean. Based on the survey findings the following four results were identified: 1. Expertise reduces project complexity: On average the 22 project complexity factors are less likely to cause poor project performance when working with an expert than a nonexpert. Using project performance as the scale to measure the effect of the supplier's expertise on project complexity, we conclude that expertise reduces project complexity. 2. Experts do not perceive ICT projects as complex while nonexperts perceive ICT projects as complex. It is reasonable to assume that the majority of respondents perceive that project complexity factors are likely to cause poor project performance with a nonexpert. We argue that if a supplier is unable to deliver a project on time, on budget and with a satisfied client that it recursively proves the project was perceived as complex. In contrast the opposite is arguably true, experts do not perceive ICT projects as complex. 3. Expert challenges that relate to project complexity factors correspond to project stakeholder factors. In general, project complexity factors do not seem likely to cause poor project performance with an expert. In prioritization of the project complexity factors, within the context of an expert, we determined that the factors most likely to cause low project performance would be stakeholder related factors. 4. Nonexpert challenges that relate to project complexity factors correspond to project scope factors. In general, all 22 project complexity factors seem likely to cause poor project performance with nonexperts, but many of these same factors were not likely the cause of poor project performance with experts. In prioritization of the project complexity factors, within the context of a nonexpert, scope related factors were determined a greater issue to performance than stakeholder related factors.

Interview Results
The interviews were coded into three major themes including: 1. Experts understand the project.
The interviewees' identified that experts understand how to execute and manage the project. Past experience on similar projects was a primary method which allowed suppliers to gain their expertise. Results would suggest that being an expert is a project specific title and not a general overarching title. In contrast nonexperts were perceived to have the opposite effect, increasing the complexity of a project. The primary source of complexity was confirmed by interviewees to be dependent on the supplier's expertise not the project itself.

Limitations of an expert's influence.
The expert's ability to reduce project complexity and reduce project performance issues was perceived as limited. Interviewees identified that project stakeholder complexity factors are to a degree outside the control of the expert and dependent on client stakeholders. In contrast, scope related factors are within the expert's control, which explains why they are not a challenge for an expert. To a degree the expert can reduce the project complexity caused by stakeholder related factors due to their ability to simplify their actions and decisions to client stakeholders. Ultimately, the project complexity derives from the control the stakeholders have to disregard and not utilize the expert's counsel.

Nonexperts have a challenge with scope and stakeholder factors.
Nonexperts were confirmed to have challenges with both scope and stakeholder related factors. It is difficult to determine which one is of higher priority in terms of the effect it has on project complexity. Interviewees identified that nonexperts may place more importance on project scope complexity factors due to the requirement and chronology of a project. Nonexperts main focus resides in completing the project scope, hence stakeholder related factors may not be encountered till later in the project. Lastly, nonexperts, due to their lack of knowledge, may increase the need for the client to have personnel with the technical knowledge and/or experience.
Substantiation and support of these three themes are described in the preceding subsections.

Experts Understand the Project
The interviews identified that a key characteristic to an expert is that they understand the project. The understanding allows the expert to know how to manage and execute the project and have sufficient capability to properly do it. Experts were identified to understand the project based on past experience. The experience is gained due to performing similar projects, lessons learned and repeated actions. One interviewee gave an example of cycling in the city of Amsterdam to explain his logic. If you cycled every day you find it normal and noncomplex. In contrast if you are visitor and rent a bicycle for the first time and ride around Amsterdam, the ride would be quite complex. Similarly, the interviewee referred his example to his job description.

'I don't think I do a difficult job. But our clients still hire our company to help them with these projects because they say, we need help because it is very complex. And we say it's everyday work, this is what we are good at and this is why we come in and help' (Interviewee R10).
Interviewees compared the contrast between experts and nonexperts within the same field or project to emphasize the difference between an expert and nonexpert. The nonexpert was identified to have the opposite effect of an expert. Nonexperts who don't understand how to manage and execute a project increase the effect of complexity because they add to the degree and possibly cause the complexity.

'If I were to go in and say this is what you are going to do, and this is how you are going to do it, I don't actually understand all the backend relational complexities that could be there, so then I'm making it inherently more complicated… I'm adding the complexity because I don't know what I'm talking about.' (Interviewee R3).
One interviewee gave an example of an ICT project which required the creation of a website. The project initially failed, costing the client over two million Euros. A second supplier was hired shortly after, who successfully built the project in three months for 200,000 Euros. The interviewee identified the difference between the two situations. In the first situation the client, was telling a nonexpert how to build the website. The second situation involved hiring an expert and letting the expert tell the client how to build the website.
'This is a good example of first spending years and millions of EUROs with a nonexpert on a project and making it very seemingly complex. Then moving it around, leaving the experts telling us how to build it.' (Interviewee R15).

Limitation of an Expert's Influence
Experts were identified to perceive projects as noncomplex and be able to reduce the effect of project complexity on project outcomes. However, the interviews identified that there were limitations to the expert's influence. The stakeholder aspects were identified as a challenge for an expert because to an extent, they are outside of the expert's control.
'That's the thing when a project becomes bigger, the number of stakeholders and the number of people involved becomes bigger. So, on the project content part, size doesn't really matter… what becomes complex is more people trying to influence or become involved.' (Interviewee R13). 'The larger the scale, the larger the number stakeholders there will be, which are things outside the control of even the expert. However, depending on the maturity of the expertise of the expert there is a scale by which this will start.' (Interviewee R14).
This is not to say that an expert has absolutely no control, but the amount is limited. Experts, due to their expertise, are able to reduce the effect of project complexity on project performance. Their minimizing effect is attributed to their ability to justify and explain their actions in laymen's terms. Interviewees suggest that the greater the expertise, the greater capacity to handle client stakeholder issues. The stakeholder factor may still be an issue if the stakeholders are unwilling to listen or unwilling to change their direction. Regardless of how well it is explained or presented, since the stakeholder is outside of the supplier's control, the end decision is out of the supplier's hands. An interviewee explained a major reason of resistance is that the client often feels attacked and does not want to admit to their internal organization that they have made a mistake. Another interviewee described it can be more than just shame but active resistance due to a power struggle.
'…we have the experts from the client side (the IT staff) and the experts from the IT provider. I have seen challenges for the provider because the IT staff think they know it better than the IT provider... that's a struggle for the expert.' (Respondent R9).

Nonexperts have a challenge with Scope and Stakeholder Factors
The interviews identified that the nonexpert has a challenge with scope related factors. Since nonexperts do not understand a project, they perceive it as complex and do not have clear vision of what to do. Nonexperts will encounter issues, many of which are self-inflicted mistakes, that an expert would never have to deal with.
'The challenges of a nonexpert is not being able to oversee the different processes of the project right. If you don't oversee the priorities, risk and time then each one of those would lead to inefficiency. (Interviewee 14). 'If you're a nonexpert you are bound to be making mistakes along the way. It is going to exacerbate; it's going to create bad feeling with the client. They are going to feel like they are paying you for expertise and they are not getting it and you are going to run into a lot of issues that an expert would not have to make' (Interviewee R6).
The challenge with scope related factors does not mean the stakeholder factors are not a challenge for the nonexpert. The interviewees indicated that the question is a matter of priority of challenges. The nonexperts will first focus on delivering the project scope. One interviewee explained the scope related factors are prioritized higher because it is more acceptable to have a poor or broken product or service than to not have a product at all.
'The thing is when you are a nonexpert you are trying to struggle so much with the technology that you are totally forgetting the client aspects…' (Interviewee R11). That is true because they don't get to the stage of the client. The client challenges are always there. It's just that for a nonexpert the project scope complexity dwarfs the client aspects. And so, it seems like an immaterial thing because that's a problem but it's not as a problem as the scope content factors' (Interviewee R5).
Interviewees identified nonexpert supplier's priority with the project scope may be related to the chronologically of an expert's activities. A nonexpert is prone to jump right into working on the scope of the project. They are unable to see potential risks or mistakes which they will encounter nor the stakeholder issues that may arise. An interviewee gave an example of a client with too small of a budget or an unrealistic goal. An expert would be able to identify this problem early on and encounter possible stakeholder pushback. In contrast the nonexpert would only focus on working on the project scope and may never get to the stakeholder issues due to their inability to finish the project scope.
'If a client defines a certain scope, an expert supplier will understand if that the scope is too big, cannot be handled or cannot be done within the given timeframe. An expert would see this and warn the client, the nonexpert doesn't even know it.' (Interviewee R15).
The nonexpert may eventually have to deal with the stakeholder factors. If this occurs, the nonexpert will have a more difficult time with stakeholder factors than an expert. Interviewees explain that experts have their expertise to mitigate stakeholder factors. Since experts understand the project they can justify and reason with the stakeholder. Nonexperts on the other hand have no method to mitigate stakeholder factors. This will result in the nonexpert being outranked by a stakeholder due to their inability to explain their recommendations and then be forced to perform whatever actions the stakeholder dictates.
~ 110 ~ 'Nonexpert will have an even harder time I think with client aspects. They will be blown right away by the IT staff of the buyer. He has from the beginning a difficult time. I certainly think a nonexpert is not successful in this business.' (Interviewee R9).
The interviewees further identify that nonexpert suppliers eventually place the requirement of expertise on the stakeholders. In cases with a nonexpert, someone has to manage the tasks and actions to complete the project. If the supplier is a nonexpert, they will require the stakeholders to direct them on what to do. One interviewee explains the danger of this, as the accountability would then lie with the stakeholder. In cases of project failure, the supplier would be able to blame the stakeholders, as they were the entity responsible for every decision.

Conclusion
The study's aim was to better understand the "effect" of expertise on ICT project complexity, measuring the "effect" through project performance. The three research questions investigated include: (RQ1) What factors define project complexity? (RQ2) What is the effect of the supplier's expertise on project complexity factors? And (RQ3) What challenges do experts and nonexperts have with respect to project complexity? The first research question identified 22 unique project complexity factors through literature review. The second and third research questions were answered through survey and interviews. The studies identified that (1) expertise reduces project complexity, (2) experts do not perceive ICT projects as complex while nonexperts perceive ICT projects as complex, (3) experts' challenges that relate to project complexity factors correspond to project stakeholder factors due to stakeholders, to an extent, being outside the control of the expert. (4) nonexpert's challenges that relate to project complexity factors correspond to project scope factors.

Discussion and Future Research
This research identified that the role of an expert (expertise) has the potential to reduce project complexity. In contrast, based on our results from this paper, the nonexpert is unable to reduce project complexity and may be the source of complexity. Existing models such as Azim et al. (2010), Tatikonda and Rosenthal (2000) and Florciel et al. (2015) measure project complexity factors which describe the project conditions inclusive of the technology, size, stakeholders, interrelations, and interdependence. Our findings from the current study suggest the need to expand the modelling of complexity to include project performance. We argue that factors which do not affect project performance should be excluded from the definition of project complexity as they do not align with the current industry practical use of the word complexity. The new definition of complexity should be connected to project performance as its primary indicator of complexity.
Literature suggests that expertise is a key component to handling and reducing project complexity. To the best of our knowledge, ICT project complexity models have not been studied by using the lens of expertise. Literature, such as Bakhshi et al. (2016), has addressed project team factors which may pertain to expertise, including competencies, knowledge, experience, education, and training; however, these models do not focus on expertise or place a priority on factors which may pertain to expertise (Abdou et al., 2016;Bakhshi et al., 2016;Qing-hua et al., 2012;Xia & Chan 2012). Based on our findings from this paper, we claim that existing project complexity models should be adjusted to have the primary focus on measuring expertise. The findings also reveal that project stakeholders are the greatest challenge for expert suppliers. Project stakeholders have been identified as a great risk to experts as they are outside of the control of the expert. Project complexity models should not only focus on identifying the expertise of the supplier but also stakeholder factors which may impede the utilization of the supplier's expertise.
The theoretical modelling of existing project complexity models can be enhanced by incorporating (1) the effect that project complexity factors have on project performance, (2) the supplier's expertise and, (3) stakeholder factors which impede the utilization of the supplier's expertise. For example, Xia and Lee (2004) introduce a model to measure the complexity within Information System Development Projects (ISDP) through 20 factors. In analyzing the 20 factors, 11 (55%) are related to the project scope, six (30%) are related to the project stakeholders, and two (10%) are related to the expertise of the personnel executing the project. Based on our research findings from this paper, the 11 factors related to the project scope may measure a traditional definition of complexity however, the factors (which comprise 55% of the cited factors) would be of minimal effect to project performance when an expert supplier is present. This model could be adjusted by emphasizing factors which measure the expertise of the supplier executing the project and the stakeholder factors which impede the supplier from executing the project.