A Review of Human Factors in Remote Software Project Management: A Progressive Look at Human Based Issues in Remote Software Development Environments

There is a documented high rate of project failure within the software engineering community. Many researchers have discussed what the issues are and how to solve them using novel processes, technology, and tools, but the statistics remain mostly unchanged. We explored these issues from another perspective focusing on human based factors and how it affects remote software teams. Using a systematic literature review approach with selected criteria we explored the issues under several clusters. We found there exists a relationship between human based factors in remote software teams and success/failure, which, if better understood and managed could be used to reduce the challenges experienced by remote teams. We also identified a limitation in the availability of empirically tested data and suggest further research in understanding human based factors in remote teams as a precursor to reducing the rate of failure.


INTRODUCTION
The need to refine the software engineering (SE) process to improve software reliability is a critical endeavor [69].One way of achieving this is to address the causative factors that contribute to errors and reduce their effect.While error free systems would be the ideal, cost and time dependencies make this unrealistic [1].As business and organizational agility gain ground, Agile based methodologies are being explored to achieve success.But success as a construct is dependent on complex human logic that includes usability, value, preference, and not just functional adaptability, hence are difficult to quantify [52].There is also a growing community of observers that are looking at going "Beyond Agile" by exploring safe management principles and being simultaneously broader but ruthlessly selective in applying its recommendations [60].
Methodologies such as Agile, (scrum, kanban, lean thinking and Xtreme programming) have documented benefits [37], but as the business landscape continually evolves, the need to reevaluate/refine these methods becomes paramount [37].In an environment where remote working is now mainstream (post COVID19), the challenges faced by industry and academia have taken different turns.This work explores issues surrounding the SE community with emphasis on human factors' (HF) challenges within remote agile environments.Its purpose was to evaluate what the issues are from multiple perspectives, investigate what has been ignored and suggest ways of reducing them subject to further research as the contextual elements of business and SE evolves.We plan to determine if there exists a correlation between HF and software project success within remote development environments.How these factors can be perceived/used as an enabler rather than an inhibitor in SE processes to improve success rates.
This paper is structured as follows: -Section 2 gives a background to the study and outlines its objectives.Section 3 defines the search methodology and strategy used.The actual data retrieved from the review further divided into logical sub-headings is represented in section 4. A general summary of findings both as a contribution to knowledge and as an under-researched area that should not be overlooked is shown in section5.

BACKGROUND
Software is a major component of business and organizational efforts to manage processes and optimize workflows.But software themselves are by-products of human activities which are flawed, complicated and at best unpredictable.Therefore, the complexity of human personality gives rise to intricate dynamics in software development (SD), ones that cannot be ignored but which have often been overlooked [4] [32].The factors that affect project success have been a topic of research for the SE and larger project management (PM) community for the last thirty years.While most researchers focus on project methodologies [11] [12], others are focused on management defects [20][21] [29][63], while some pay attention primarily to processes and technology [54] [25], and others on people [7].The problems software projects (SP) face, however, cannot be tied to singular causative factors [11] [31], as the size of project, domain, complexity, and mode of delivery amongst others  [67].Moreso, the terms success, lack of success, and failure are difficult to define and perceived to be vague [9][49] [70].
In every SD process, there are attributes that must be present.Understanding these attributes and the roles they play forms a doorway to some of the problem context within software PM which can give us better insights on how to tackle them [41] [58].These attributes are people, processes, technologies, and environment, most of which are controllable except people which constitute HF.HF while a necessity introduces a considerable amount of risk which cannot be easily quantified or mitigated due to a large matrix of reasons for which there exists little solution [27].HF as used in this work relates to risk/errors based on the people, personality and emotional maturity indexes, soft skills, social skills, and other non-technical skills needed for SD.

REVIEW METHODS AND SEARCH STRATEGY
Due to time constraints and unavailability of primary data, only secondary data was used for this research.Owing to the nature of the objective and the type of data in context, we conducted a qualitative thematic analysis rather than quantitative following the Saunders' prescribed benefits [50][62].To get a reasonably representative across cross-sections, we used multiple databases relevant to practitioners and academics.We also carried out an initial search to determine keywords and search combination criteria to be used for the research [35].The research methodology follows an interpretivist approach in examining relevant studies to determine gaps or relationships that supports/answers the research question.From this, we were able to deduce a claim of the relationship between HFs and SD in remote environments or the lack thereof.The systematic review of literature considers mainly relevant publications within the last decade covering selected keywords and structures.
Literatures explored are to ascertain the HFs that contribute to the success/failure of remote SP and how if not checked/managed, could potentially lead to even greater issues in the future.To achieve this, we set out to determine if there exists a direct relationship between HF and software success/failure as a precursor to improving the SE processes.Initially, different search criteria were used on different databases.The search criteria as used were: "Software PM Issues and Human Factors in Software Development, Soft Skills in Software Development, Knowledge Management and Business Agility and Global Software Development".The main databases explored were Scopus and Google Scholar.A combination of relevant studies published on the subject matter alongside other books and practitioner papers were considered.These databases were chosen as they are more widely used by industry experts and academics within these broad fields of computer science and SE.Table 1 gives the overall results from the different search strings.
Owing to the results in Table 1, it became clear to further refine the search results and to narrow the finds based on different selection criteria.To achieve this, we used string combinations to include articles and publications that are of subject interest.The resultant strings to satisfy the primary theme and finds as used are shown in Table 2 while the research questions generated to meet the objectives and overall paper considered for each are shown in Table 3.
We also developed exclusion guidelines by asking relevant questions on all results.
• Is the paper relevant to SW PM within the human and remote context?• Does it discuss issues relevant to success and failures in software projects?• Is the full text of the publication readily available and accessible?• Other quality assessment criteria -Authors and references relevant to work? • Does it comply with relevant standards, and validated approaches?

DATA ANALYSIS AND ASSESSMENT
There is a distinction between project success and project management success [1], both of which are subject to human interpretations.That distinction, however, was not considered during this research due to the fluid concept of project success and the many variables that determine success within separate domains as highlighted in section 2 of this work.Researchers agree on the issues that affect most SP but not on the process of solving the issues [24].Different methodologies and guidelines within the SD community are mostly tied to creating more reliable software and process enhancement [55][62] [73].As SE migrates to more of a social process, the effects of people and their actions become more and more pronounced [28][46].Their characteristics, actions, interactions, and relationships shape the development trajectory and project outcomes in multiple ways, so an understanding of their roles and actions during SD is also necessary [54].In remote environments, there is little research and a lack of empirical data to determine how HF can contribute to or determine success/failure, Table 2: Search strings and publication outputs (("Software Project Management") AND ("Human Factors") AND (challenges OR issues)) (("Software Development" OR "Software Engineering") and ("Human Factors") AND ("Challenges or Issues")) ("Distributed Software" AND "agile development")) AND (business AND agility) (("Software Development" OR "Software Engineering") and ("Human Factors") AND ("Challenges OR Issues")) AND (("Knowledge Management") AND ("Global Software Development")) Table 3: Research questions generated and related articles.

RQ1
What are the primary causes of failure in remote software projects?48 RQ2 Is there a direct correlation between these human factors and software project success/failure in remote environments?

RQ3
Can success or failure become predictable due to changing human based factors in remote environments?9 especially in agile environments.This section looks progressively at the issues with software PM in progressive themes.

General PM based issues (GPMI)
For most projects within the general PM domain, quality, cost, and time are the three most important components that determine success [39], and thus define error prone aspects of methodologies or systems.Since most projects are team-based efforts, the team dynamics and how they work together is also of utmost importance [1], thus elements like communication and cohesiveness play important roles in determining project success.As highlighted in section 2, technical issues dominated accounts of SD outcomes.However, there has been increasing recognition that project failures are rarely caused by technical problems alone [11]

Software PM based issues (SPMI)
One of the major differences between traditional projects and SP is the intangibility of software, that is, major components of the SP' errors, progress and defects remain hidden until the final stages of the SE process.Because defects in the product cannot be observed and examined easily, it introduces a different set of risks and challenges [2].Most SP meets a service need as identified by stakeholders or end users, however, a lack of understanding of the project context by stakeholders is seen as one of the major reasons behind SP failure.[15].Lack of understanding, however, is not only limited to stakeholders.Developers make poor decisions leading to poor outputs based on preconceived ideas or a lack of understanding [3][42].Sometimes, this outputs as technical depth and sometimes, it is dependent on system processes and methodologies [65].The challenges relating to methodology center around documentation, less attention to human factors, rigorous process disciplines and technological gap [2].In their work on the factors affecting SD, khan A. et al discussed communication gaps among teams, a lack of understanding and a lack of inclusion of relevant stakeholders in the decision-making process of SD [33][44] [61].This posits that a more focused look at these indices can help us better understand software failures/success.

Human Software PM based issues (HSPMI)
Human software PM based issues refers to those challenges whose characteristics are dependent on and can be traced to the individuality of the people working on the SP.These characteristics include technical skills, expertise, and experience; interpersonal, communication and social skills; application domain knowledge; commitment, motivation, and trustworthiness; and norms, values, and beliefs [68] [69].Since every human is unique, psychological theories assert that not everybody is fit for every task, as people have different personality traits and abilities [4], therefore, not choosing the right set of people for work could lead to failure.In their work Faheem Ahmed et al. found out that although the software industry is paying attention to HFs to some extent, there is a need to further acknowledge the role of these factors in SD [4].
Several studies have explored the relationship between HFs to software PM from multiple perspectives.A study by Karn et al used ethnographic methods to explore this relationship and found out that certain personality types are more suited for certain roles [43].By looking at how decisions are made based on personalities using statistical analysis, researchers have found out that success/failure can be predicted based on the composition of the software team [8][18] [26].There is however an ongoing debate on the relevance and importance of soft skills or HFs.Goleman believes the possession and use of soft skills contributes more to an individual's ultimate success/failure than technical skills [4][17].This view is supported by Bolton who reports that 80 percent of individuals who fail at work do not fail due to their lack of technical skills but rather because of their inability to relate well with others [33][54] [64].While there are others who posit that the relevance of HFs is negligible when compared with hard skills [10][34] [45], most of the recent findings assert that there is a correlation between HF and project success/failure.

Remote Human SW PM based issues (RHSPMI)
Without a doubt, there is an extensive library of benefits associated with remote working and distributed teams [36], but empirically tested data and literature is sadly sparse on how HFs are contributory to success/failure within remote environments.Most methodologies have been tested and reworked within co-located environments but not with remote and distributed teams [66], and the efforts to address this are still in their early developmental stages.Most of the data available show that the disadvantage of an unchecked remote team carries more weight than its advantages [36].While Christian suggests negligible difference in failures for remote teams [6], the Standish group in their report shows a 23% failure for remote teams when compared to a 4% failure for co-located teams [69].This view is also supported by others who listed culture, communication, and coordination as the major contributors to failure [5][16][59] [71].Also, while it is true that agile based methodologies are efficient for enhancing communication, they have not been fully adapted for remote working conditions.Herbsleb et al in their work attributes this to the challenge of coordination, management, and control needed for remote teams [36].Gomez et al further highlighted that even though the challenges are known, we see a trend of them being repeated and suggests a lack of historical reference and poor knowledge management (KM) principles as a causative factor to this [33].One challenge that is heightened with remote teams is the definition of "complete" which affects performance and quality.Agile based co-located teams can agree on the definition which helps in evaluating every piece of work, sprint, or backlog but this is difficult for remote teams as the satisfaction/derived value for work is lost in meshed processing [23].Nguyen attributes this to a lack of process synchronization [57][66], while Gomez aligns it to the communication and cultural difference amongst team members [33][36] [66].
Communication is also hindered by trust as developers not located together have very little informal, spontaneous conversation (corridor talk) across sites [40][56].This is traced to different reasons; first organizations are seen to have restricted or filtered communication due to the fear of loss of intellectual property or other proprietary information about products or schedules [36], within remote environments.Gaps with delayed responses and information truncation with change requests [66], as well as the lack of cordiality of feedback and relationship building in a remote setting leading to misalignment and rework [33][66].This also leads to poorer testing, quality checks and modular integration into live system environments as well as poor transference of knowledge and inadequate documentation [19].Another setback with remote teams is the KM deficiencies that cause teams to miss many reuse opportunities that otherwise would have saved cost and time.This causes developers to repeat the same mistakes and inhibits growth in organizations and models which in turn cause them to remain static rather than evolve continually toward process improvement [36] [66].There is also a knowledge acquisition and distribution challenge for new team members due to a lack of effective collaboration in remote environments which further affects the assessment of technical skills of team members and how to distribute task based on technical ability [19] [72].
Technology is also seen as a challenge especially in locations and teams that are surrounded with poor infrastructure, examples are internet (India, Nigeria), security restrictions (China) or when knowledge/use of specific technology is a prerequisite to team functions.Poor documentation may also lead to ineffective collaborative development.[19].There is however a lack of sufficient primary data to empirically test these factors with weighted metrics on how they influence success/failure in remote software teams.Table 4. Shows a summarized distribution of the main themes of the research papers.

DATA ANALYSIS AND ASSESSMENT
Many of the factors in section 4 have become well established in the SD culture and are frequently covered in software systems practitioner literature [12].What is difficult to explain is why SP fail despite the apparent knowledge of these factors in SD practice.As Cobb's Paradox states, "We know why projects fail, we know how to prevent their failure -so why do they still fail?"[54].
Also, the reviewed literature shows that all the challenges highlighted in sections 4.1 to 4.3 were greatly increased in section 4.4 owing to the changing dynamics of remote and distributed teams.The information provided in section 4 paints a clear picture of trends and dependencies.

CONCLUSIONS
For organizations to evolve, they need to learn from past mistakes.Most solutions in solving software related issues have been focused on process and technological enhancements during the lifespan of the project; however, most organizations do not see preventing failure as an urgent matter neither is it well documented.It is not understood why this attitude persists [30].It is important to note that every variable that can contribute to project success has a potential of derailing that success as well.The one variable that is constant irrespective of how novel the technology, methodology or process, is the human factor.Timo A.O et al noted that the prevention of a software project failure requires a case-specific analysis and controlling causes outside the process area where the failure surfaces [48].
The research shows that HF are responsible for a greater number of SD success/failure but also exposes a lack of empirically tested primary data for HF, their indicators and traceability matrixes within remote and distributed environments and asks the following question.

Figure 1 :
Figure 1: Direct dependence to project outcomes on human based factors

Table 1 :
Initial search strings and publication outputs

Table 4 :
Analysis of Reviewed Papers and Distribution of Key Finds

Table 5 :
Mapping Issues to PM Segments Issues as reviewed in literature Severity to success Most affected segments Scope creep and Understanding requirements High GPMI, SPMI, HSPMI, RHSPMI Budget restrictions and schedule High GPMI, SPMI, HSPMI, RHSPMI Communications among teams and other stakeholders High GPMI, SPMI, HSPMI, RHSPMI Frictions due to team conflicts High GPMI, SPMI, HSPMI, RHSPMI Process, accountability, and management Medium GPMI, SPMI, HSPMI, RHSPMI