Sustainable Risk Management in IT Enterprises

Abstract

A synthesis of literature studies covering the determinants of agile project management methods, risk management processes as well as factors influencing the shaping of project success and failure clearly indicates that in most publications on risk in agile managed projects, the human factor is heavily underestimated at the expense of often excessive favoring of procedures. Meanwhile, after analyzing the risk factors that arise in agile-managed IT projects, it became apparent that in addition to aspects such as technology, hardware, system, or even project schedule and cost, the project team is highlighted, which is also the second concept with the GPM P5 Standard for Sustainability in Project Management. Thus, the purpose of this article is to develop a model for risk management in IT projects. As a result of the empirical research carried out by means of an expert interview (108 experts) and a questionnaire survey (123 respondents), a risk management model was developed and six original risk management areas were identified, describing 73.92% of all risk factors that may occur during the implementation of an IT project. Furthermore, empirical studies confirm that basic processes such as risk factor identification, impact assessment, and key risk factor management are used by managers and/or team leaders during the implementation of IT projects.

1. Introduction

The changes in project management approaches observed today (Garwood and Poole 2018; Bredillet et al. 2018; Cakmakci 2019), especially in the IT industry (Shafiq et al. 2018; Bergmann and Karwowski 2018; Bogdanova et al. 2020), are caused by operating in an environment often characterized by high levels of volatility and adaptation to market requirements (Appelo 2011; Fioravanti et al. 2018). In such an environment (Williams 2005; Kaim et al. 2019), conventional (traditional) project management methods may be inadequate and disadvantageous for uncertain and structurally complex projects (Rasnacis and Berzisa 2017; Trzeciak 2020; Zavyalova et al. 2020). As a result of these changes, new trends in project management are taking shape, emerging from the criticism of the traditional approach. In the literature, this new approach has been referred to as agile project management (Highsmith 2009; Layton et al. 2020; Bogdanova et al. 2020) consisting of freedom during project execution, using less formalized and rigorous approaches in favor of greater flexibility of activities to the circumstances in which the project is implemented (Schwaber and Sutherland 2017; Vallon et al. 2018; Schmitt and Hörner 2021).

Considering the specificity of IT projects often burdened with a high level of risk, the agile approach used to manage such projects and the recommendations contained in the literature providing research opportunities using quantitative and qualitative methods, this article focuses on IT projects implemented in an agile approach to project management.

In the first part of the article, a wide-ranging study of literature was conducted, including determinants of agile project management methods, risk management processes, and IT project stakeholders. In addition, attention was also paid to the importance of risk as a measure of the probability and effect of the impact of negative and positive events on the achievement of the project’s success. This allowed for the identification of a research gap relating to the model approach to risk management in the agile project management approach. In succession, the method and the conducted research including a questionnaire (123) and a structured interview (111) were presented. In addition, this section describes the statistical method of the PCA, thanks to which the risk areas of IT projects were identified, and it also contains the results of the conducted reliability test. The research part presents the results of the research, including the identification of risk areas of IT projects and analysis of risk management processes in IT projects. This allowed the author to obtain answers to the research questions and develop a risk management model in agile project management. A detailed description of the model components including recommendations for practitioners and a proposal to classify individual risk management processes that play a key role in integration, control, and monitoring, by following the GPM P5 Standard for Sustainability in Project Management concept was presented in the discussion section.

2. Literature Review

The development of agile project management approaches is directly related to the development of information technology—IT (Appelo 2011; Conforto et al. 2014), as well as to the increase in user requirements (Serrador and Pinto 2015; Hoda and Murugesan 2016). The beginnings of this concept emerged in 1986. At that time, in the “Harvard Business Review,” Hirotaka Takeuchi and Ikujiro Nonaka (Takeuchi and Nonaka 1986) published an article entitled “The New New Product Development Game”, in which they drew attention to the self-organization of project teams, the process of overlapping activities (iterations), but also pointed out that the cascade system proposed in 1968 by NASA was flawed, due to the long time required for software development. The above beliefs have led to combining software engineering techniques (i.e., change boards, metrics and inspections) with hands-on activities (i.e., intensive customer collaboration, prototyping, or iterative software development) (Gharajeh 2019; Heeager and Nielsen 2018).

By 2000, a number of concepts shaping the general principles of an agile approach to project management had emerged. Significant development of agile methods and their popularization took place in 2001. At that time, the forerunners of the idea of an agile approach to project management developed the Agile Manifesto (Beck et al. 2001) containing four main postulates and twelve principles. The aim of this paper was not to develop detailed methods, but to identify the characteristics they should have (Hohl et al. 2018; Hoda et al. 2018). The manifesto’s postulates have thus become the foundation of agile methods as an alternative to traditional project management approaches, while allowing for faster and successful software development (Tam et al. 2020; Bergmann and Karwowski 2018). Currently, the agile approach to project management is one of the most popular approaches to IT project management in the world (Orłowski et al. 2017), which can distinguish between both hard approaches (AgilePM, PRINCE2 Agile, PMI Agile Project Management) having a project management module and light approaches (Scrum, Extreme Programming, Lean Management concepts) mainly focused on project team work and product manufacturing (Raharjo and Purwandari 2020).

The topic of project risk management has been addressed for many years (Hottenstein and Dean 1992; Thamhain 2013), and yet remains relevant (Hopkin 2018; Buganová and Šimíčková 2019; Tavares et al. 2020). The occurrence of risk in a project is inevitable, and therefore occurs at all levels of project delivery. Depending on the scope, complexity, or nature of the project, risks may be greater or lesser, but should always be identified (Shrivastava and Rathod 2015). There are many definitions of risk in the literature, but for the purpose of this article, it has been assumed that “risk is defined as the probability of an action occurring that may have negative or positive effects on the implementation of the whole project or/and on its individual parts.” In the agile approach to project management, three distinct risk management trends can be identified depending on the hard or light methods used.

Uncertainty and risk in projects may significantly affect the overall implementation of projects’ goals (Ismael and Shealy 2018; Ghasemi et al. 2018). Uncertainty and risk related to project management events can be assessed by prior assessment of possibilities (Maceika et al. 2021), risk combinations, and their possible impact on the overall achievement of objectives (Bakos and Dumitrașcu 2017; Woźniak 2021). The processes of managing risk and uncertainty are important from the sustainable project management perspective (Wang et al. 2020; Zaleski and Michalski 2021). Decisions and approaches that are efficient and effective in managing both risk and uncertainty assure that the project will reach permanent and sustainable goals (Doskočil and Lacko 2018; Xue et al. 2018). This also translates into a reduction in capital expenditure, maintaining standards in projects, etc. (Ahn et al. 2020; Armenia et al. 2019). Risk management is considered to be an integral part of the decision process, rather than just an additional technical analysis (Taherdoost 2018). Taking into account the characteristics of IT project management (a multi-level process that covers the entire life cycle), the human factor should be considered in risk management for sustainable IT project management as a critical factor for project success (Woźniak 2021).

There are many definitions of risk in the literature, relating to both threats and opportunities, but for the purpose of this article, it has been assumed that “risk is defined as the probability of an action occurring that may have negative or positive effects on the implementation of the whole project or/and on its individual parts.” In the agile approach to project management, three distinct risk management trends can be identified depending on the hard or light methods used.

The literature on hard agile methods (AgilePM; Prince2 Agile) distinguishes models based on a three-step process of risk management (i.e., identification, impact assessment, countermeasure planning) with ongoing project execution and monitoring from the project management level. Two approaches have emerged for lightweight agile methods (Shore and Warden 2008; Schwaber and Sutherland 2017). The former highlights the importance of risk analysis in the project management process (Little 2006, as an additional element performed by the team leader (Shore and Warden 2008; Schwaber and Sutherland 2017); however, it does not present risk management models that could be used in practice. In contrast, the latter approach treats project risk as a natural element (Highsmith 2009), built into agile methods through transparency, prioritization, an iterative approach, or constant contact with the contracting entity and almost immediate response to changes, whether in requirements, technology, or even scope elements (DeMarco and Lister 2013). One aspect of risk that receives some attention in the agile approach is the balance between risk and delivering value to customers when prioritizing tasks (Moran 2014). For example, (Cohn 2010) advocates a strategy of addressing high-value and high-risk tasks, high-value and low-risk tasks, and then in that order, low-value and low-risk tasks, while avoiding low-value and high-risk tasks altogether. The argument is that working on high-value, high-risk tasks first eliminates significant risk at an early stage. This approach treats risk as an aspect of the task that may prove too limiting. For example, some of the risks that a project has to face are not inherent in the performance of specific tasks.

The paper focuses on IT projects implemented in an agile approach to project management, considering their specificity, often with a high level of risk, the agile approach used, and the recommendations in the literature providing research opportunities using quantitative and qualitative methods.

The agile approach to project management largely comes down to the human factor, placing particular emphasis on communication (Malik et al. 2021), engagement (Koch and Schermuly 2020), collaboration (Batra et al. 2017), or proactivity of stakeholders closely linked to project implementation (Trzeciak 2020). Key success factors for IT projects, presented in reports that refer both to the state of the IT industry and to agile methods, emphasize the increasing influence of the project team or the individuals involved in the project, on shaping the level of project risk (Trzeciak 2020). Moreover, it is increasingly emphasized that project success in contemporary reasoning should not only take into account the efficiency dimension, the business impact on the organization and on the customer (benefits), but also new perspectives for all stakeholder groups, directly related to the adequate achievement of their desired level of satisfaction, perceived from the perspective of organizational, personal, and technical project implementation (Khalifeh et al. 2019; Mughal et al. 2019; Trzeciak 2020).

An analysis of the literature on IT project management methods, implemented in an agile approach to project management, indicates that there is an existing paucity of methodical approaches to risk management. Furthermore, most of the factors influencing success are often due to overlooking the human aspects (Trzeciak 2020). The research undertaken in this paper aims to fill an identified gap in the paucity of the presence of a model approach to risk management in an agile project management approach that takes into account stakeholders closely involved in project delivery. Thus, the aim of this paper is to develop a proposal for a risk management model for IT projects implemented in an agile approach to project management.

3. Materials and Methods

A synthesis of literature studies including determinants of agile project management methods (Highsmith 2009; Stare 2014; Niazi et al. 2016), risk management processes (Thamhain 2013; Hopkin 2018; Buganová and Šimíčková 2019; Tavares et al. 2020), and IT project stakeholders (Orłowski et al. 2017; Vallon et al. 2018) as well as the factors that shape project success and failure (The Standish Group) clearly indicates that in most publications on risk in agile-managed projects, the human factor is heavily underestimated at the expense of sometimes over-favoring procedures. Meanwhile, after analyzing the risk factors that arise in agile-managed IT projects, it became apparent that in addition to aspects such as technology, hardware, system, or even project schedule and cost, the project team is highlighted. According to practitioners, risk analysis in agile project management conducted as a separate process seems redundant, and reliance on customer decisions relating to feature selection and short iterations is supposed to be a built-in risk reduction strategy. Reports outlining key success factors for IT projects highlight the vital importance of both the functioning of the project team as a whole and the personal individuality of individual members. Accordingly, the article poses the following research questions:

• Which risk areas have the most significant impact on the success of the project?
• What processes are used to manage risk and how is the risk of an agile-managed IT project assessed?

Answering such research questions will allow verifying the following hypothesis: “Identifying risk areas is crucial for risk management in an agile approach to project management”.

In order to answer the research questions, a process for the course of empirical research was developed based on a generally applicable procedure (Weber 2011). In order to answer the research questions concerning the identification of risk factors with the most significant impact on the success of the project, an expert interview questionnaire was used first. The interview is a research technique used in qualitative research in which questions are developed in advance and asked to respondents, in a predetermined order (Shao and Müller 2011). The structure of the interview questionnaire was based on expert consultation and generally applicable principles. The questionnaire consisted of three parts. The first was a metric (five questions), the second covered issues related to the identification, assessment, and management of project stakeholders (eight questions), while the third related to issues concerning the identification of risk factors (ten questions) and tools and methods for the quantitative and qualitative assessment of risk factors (six questions).

A survey questionnaire was then used to assess the identified groups of risk factors. The survey questionnaire consisted of four parts. The first was a metric (6 questions), the second included general questions about stakeholders, risk, and IT project success (15 questions), the third consisted of questions about the impact of selected risk factors on IT project success (27 questions), and the fourth included questions about the impact of key stakeholder groups and their characteristics on the development of risk levels (42 questions). The survey questionnaire consisted mostly of closed questions, which were arranged in a matrix format based on a five-point Likert scale, making the time to complete it comfortable.

A commonly used principal component analysis (PCA) was used to dimension the risk areas present in IT projects. The main objective of conducting a factor analysis is to extract all the factors that are directly correlated with a given set of variables, while keeping as much information as possible contained in the original variables, and subsequently reducing them (Mishra et al. 2017).

The research was carried out by means of an expert interview questionnaire and surveys addressed to the target group, but implemented in Polish IT companies. In order to obtain the widest possible research sample, the invitation to participate in the research, in the form of a letter of intent, was mainly addressed to enterprises by means of direct contacts (meetings or telephone calls) and direct mailing, using a contact database (120 entities).

In addition, the research was conducted with a focus group that included project managers and/or project team leaders and members who had the following characteristics:

• Had practical and theoretical knowledge in the field of IT project management in agile project management,
• Had participated in at least one project in the last three years,
• Held a managerial position or of a member of the project team,
• Worked in an agile approach to project management.

As a result of the activities undertaken, a total of 111 interviews, based on criteria describing the target group, were conducted with managers and project team members from 31 IT companies. Analyzing the correctness of all data contained in the completed interview questionnaires, 108 correct questionnaires were accepted for further analysis. In conducting the survey, key importance was attached to informing respondents about the purpose of the survey, explaining the meaning of the terms used, and assuring them of the confidentiality of the survey and the intention to use the data collected.

The research was conducted using an anonymous survey questionnaire that was distributed in hard copy at community meetings promoting agile approaches to project management and electronically using a prepared email database. The size of the target group targeted by the research can be estimated at 2500. On the other hand, the return of completed questionnaires amounted to 173, which was 6.92%. Moreover, while performing a preliminary analysis of the collected results, it was noticed that some of the questionnaires (11) were not fully completed, which resulted in 162 records being accepted for further analysis of the obtained data. Based on the verification of the adopted characteristics of the target group, it was noted that in 39 cases one or more of the characteristics were not fulfilled. Moreover, in as many as 36 cases, this involved working in an agile-managed team, which is crucial given the nature of the research and the assumptions of the work. A total of 123 cases were adopted for the principal analysis of the research results obtained (

Table 1. Characteristics of the experts participating in the study.

Characteristics	Category	Number of Experts (Interview)	Percentage	Number of Experts (Survey)	Percentage
experience	less than 1 year	0	0.00%	0	0.00%
	from 1 to 4 years	37	34.26%	54	43.90%
	from 5 to 10 years	49	45.37%	48	39.02%
	over 10 years	22	20.37%	21	17.07%
number of completed projects in the last 3 years	under 1 project	0	0.00%	0	0.00%
	from 1 to 4 projects	50	46.29%	60	48.78%
	from 5 to 10 projects	52	48.15%	48	39.02%
	more than 10 projects	6	5.56%	15	12.20%
role in the project structure	team member function	70	64.82%	54	43.90%
	team leader function	18	16.67%	42	34.15%
	project manager function	20	18.52%	27	21.95%

).

Given the exploratory nature of the study, which makes it impossible to examine representativity (qualitative research), it is assumed that it should be characterized by reliability. Reliability derives from the magnitude of the error that is associated with the measurement tool used, and that in subsequent measurements using a given tool arises randomly (Cresswell 2009). Furthermore, if the survey instrument includes a rating scale, the data obtained should be checked for internal consistency. The most common technique used to measure reliability is Cronbach’s alpha coefficient.

Cronbach’s alpha coefficient primarily indicates whether the responses of the scale items are similar. According to the accepted interpretation of the literature, a coefficient score above 0.6 is considered satisfactory, above 0.8 indicates very good, and 0.9 indicates excellent reliability of the study (Cresswell 2009).

$$\propto =\frac{k}{k-1}\left[\frac{{{\displaystyle \sum }}_{j-1}^k{S}^2\left(x_j\right)}{S^2\left(x_s\right)}\right]$$

(1)

where:

• $\propto$—Cronbach’s alpha coefficient.
• $S^2\left(x_j\right)$—variances k of individual questions.
• $S^2\left(x_s\right)$—variance of the sum of all questions.

All components described according to the commonly used Likert scale of the structured interview questionnaire were found to be reliable (

Table 2. Measuring the reliability of the expert interview questionnaire.

Specification	Cronbach’s Alpha Coefficient Value
Identification, assessment and management of project stakeholders	0.78
Identification, assessment and management of project risk	0.79

and

Table 3. Measuring the reliability of the survey questionnaire.

Specification	Cronbach’s Alpha Coefficient Value
Assessment of the impact of risk factors on project success	0.82
Assessment of the impact of key stakeholder groups on the level of project risk	0.67
Impact of stakeholder characteristics (attributes) on the project risk level	0.63

).

4. Results

4.1. Identification of Risk Areas of IT Projects

In the study sample (108 exerts), 409 potential risk factors were identified. The obtained data were then sorted and duplicate results were removed, assigning a correspondingly increasing number of indications of a defined risk factor. This resulted in 207 potential risk factors. Then, the obtained results were grouped according to the features they related to. This yielded 27 potential risk factor groups for an IT project managed in an agile project management approach.

According to the methodological assumptions relating to the fulfillment of the basic requirements for entering factor analysis, it is first necessary to verify that the number of variables is adequate in relation to the number of respondents taking part in the study. The literature (Mishra et al. 2017) indicates that the number of respondents should be at least twice the number of variables being analyzed. On the basis of the identified risk factors through an interview questionnaire, a list of 27 factors was developed, which in turn were assessed, based on their impact on the success of the project, through a questionnaire survey. In contrast, the number of respondents’ survey results analyzed was 123, more than four times the number of variables analyzed.

The next step is to verify the variables for their suitability to be analyzed. For this purpose, it is recommended to verify the variables for correlations between them. It is also pointed out that if there are any variables that are weakly or completely uncorrelated, they should be removed from the analysis without any hesitation. On the basis of the reliability and the item analysis also showing the total position of the correlation between the examined variables, 4 variables characterized by a very low level of correlation (below 0.2) were singled out. When reducing the number of variables analyzed, it is important to remember that their dependency structure also changes. To prevent errors that might occur during factor analysis, an item analysis of the total correlation between the study variables was again performed. The analysis performed also had the measurable effect of identifying 3 variables with a very low level of total correlation in relation to the other variables analyzed. These variables were also removed from the set of risk factors under analysis.

In the literature, in order to confirm the validity of the use of factor analysis, it is also suggested to calculate the determinant of the correlation matrix and to perform Bartlett’s sphericity test. In the case under consideration, the value of the coefficient was 4.60 × 10⁻⁷. A low coefficient value indicates the existence of significant correlations between the variables under study. The same information is obtained by testing the null hypothesis in Bartlett’s sphericity test.

Hypothesis 1 (H1).

R = I (the correlation matrix is a unitary matrix).

Hypothesis 2 (H2).

R ≠ I (the correlation matrix is not a unitary matrix).

The H1 hypothesis is rejected when p-value < 0.05.

In the example analyzed, the empirical Chi2 is equal to 1675.54. Based on the obtained result on degrees of freedom (171), the theoretical Chi2 was also calculated, assuming the following: p = 0.95; df = 171. The value obtained was 202.51. Furthermore, the ratio of the empirical value to the theoretical value of Chi2 is more than eight times higher. Based on the above calculations, it can be concluded that the probability of the obtained result, assuming that the correlation matrix is a unitary matrix, is close to zero. Furthermore, the hypothesis H1 should then be rejected, while recognizing that the data analyzed are fully suitable for performing factor analysis.

The purpose of conducting the factor analysis was to isolate areas of risk by analyzing the assessment of the impact of identified risk factors on the success of the project. On this basis, it can be concluded that the risk areas identified by performing a factor analysis contain 73.92% of all risk factors that may occur during the implementation of an IT project in an agile project management approach (

Table 4. Percentage of explained variance by individual factors after rotation.

Value	Eigenvalues of Factors Extracted: Main Components
	Eigenvalue	Percentage of Total Variance	Cumulative Own Value	Cumulative Percentage
Factor 1	5.56	29.28	5.56	29.28
Factor 2	2.50	13.17	8.06	42.45
Factor 3	1.91	10.08	9.98	52.52
Factor 4	1.59	8.37	11.57	60.90
Factor 5	1.36	7.17	12.93	68.06
Factor 6	1.11	5.85	14.04	73.92

). Furthermore, the impact of each risk area on the success of the project is the same as the percentage of the total variance of the six factors identified during the analysis (

Table 5. Matrix of rotated components by the EQUAMAX method.

Variable	Agent Landings (Equamax Standardized) Extracted: Main Components (Marked Loads Are > 0.50)
	Factor 1	Factor 2	Factor 3	Factor 4	Factor 5	Factor 6
communication within the project team	0.80	–	–	–	–	–
customer/user involvement in functionality development	–	–	–	–	0.58	–
equipment and technology	–	–	–	–	–	0.77
company culture	0.75	–	–	–	–	–
estimation of labor intensity	–	0.84	–	–	–	–
resource estimation	–	0.77	–	–	–	–
lack of specific requirements on the customer side	0.78	–	–	–	–	–
communication with the project environment	0.75	–	–	–	–	–
misunderstood, misinterpreted customer needs	0.79	–	–	–	–	–
emotional maturity of the team	–	–	–	0.79	–	–
reprioritization of requirements	0.58	–	–	–	–	–
project management method	–	–	0.51	–	–	–
project coherence (integration)	–	–	0.73	–	–	–
test environment or lack thereof	–	–	–	–	–	0.62
business objectives	–	–	–	–	0.76	–
cooperation in the project team	–	–	0.77	–	–	–
project budget estimation	–	0.71	–	–	–	–
non-functional requirements	–	–	–	–	0.74	–
cooperation between the team and the project manager	–	–	–	−0.56	–	–
Output variances	4.50	2.67	1.77	1.53	1.90	1.67
Content	0.24	0.14	0.09	0.08	0.10	0.09

).

Based on the analysis of the components of the identified six factors and the interpretation of the above sets, the identified areas were named as follows in the literature on IT project management:

• Factor 1—risk area concerning the organizational culture of the company implementing the project (organizational culture).
• Factor 2—risk area concerning the time and cost of project implementation (schedule/cost).
• Factor 3—risk area concerning the methods, techniques, and tools used for project management, team organization, and project integration (project organizational environment).
• Factor 4—risk area resulting directly from the human factor, which is the team (project team).
• Factor 5—risk area shaped by the project’s business objectives, attitude, and involvement of the customer/user in the implementation process (user/customer).
• Factor 6—risk area related to the technology used (technical and technological environment).

4.2. Analysis of Risk Management Processes in IT Projects

The study was conducted by means of an expert interview. In order to present an overall view of the research results obtained regarding the identification, assessment, and management of project risks, the respondents’ answers were grouped according to their function in the project team.

Considering that risk management is a process consisting of identification, assessment, monitoring, and response, where individual component processes follow in succession (Buganová and Šimíčková 2019; Tavares et al. 2020), restrictions for the obtained test results were adopted. The following restrictions are intended to provide a broader view of the obtained research results and to define guidelines for the development of individual component processes on the proposed risk management model in agile project management:

• The identification of risk factors in IT projects occurs in most cases.
• Assessment of project risk factors in quantitative and qualitative terms occurs more often than sometimes.
• Management of key project risk factors happens more often than sometimes.

4.2.1. Identification of Risk Factors

Risk recognition consists of identifying potential threats or opportunities (risk factors) that may negatively or positively affect the implementation of the project (Moran 2014). Unlike the traditional (cascading) approach, agile methods treat risk as a natural element, although, in the literature on the subject, there is a critical approach to treating risk management used as a different process—with excess, agile methods directly focused on project management (e.g., AgilePM) draw attention to the importance of this process, which is also confirmed by research in this area (Trzeciak 2020). The Identified risk factors that occur during project planning have been shown in Figure 1.

In the case of criticism, it should be emphasized that light methods (e.g., Scrum) relate directly to the management of the project and production team. At the same time, attention is paid to the implementation of risk management processes in the light method in the form of e.g., daily meetings or frequent product deliveries and constant contact with the customer. This contributes to the elimination of risk factors resulting from the constantly changing project environment. Given the restrictions, the following were excluded from further analysis: Four team members, four team leaders, and two project managers.

4.2.2. Assessment of Risk Factors

When carrying out a comprehensive analysis of the results regarding the assessment of project risk factors in both qualitative and quantitative terms, in nine cases, the respondents’ answers were given the value 2 (sometimes). This means that there is practically no assessment of risk factors in these cases. This is most often due to the complexity of the implemented project or a light approach to agile project management (e.g., Scrum), which does not provide for processes related to the identification and assessment of risk factors. In such cases, the risk is identified during the implementation process, i.e., review, retrospective or daily scrum.

In addition, in 15 cases, respondents indicated that they always assess risk factors, both in qualitative and quantitative terms. In 11 cases, it was indicated that the assessment of risk factors occurs only in qualitative terms. However, using only the assessment in quantitative terms was declared by only one respondent.

The presented research results (Figure 2) are consistent with the literature on the subject, which also emphasizes the departure from quantitative assessment in favor of qualitative with a simplified scale of implementation of risk exposure. This fact is justified by the time-consuming process of assessing risk factors in relation to short implementation stages, during which the majority of risk factors directly related to the technology used, product complexity, or teamwork are constantly identified. Given the restrictions, nine team members were excluded from further analysis.

4.2.3. Risk Management during Project Implementation

The management of key project risks is only addressed in the literature when describing the risk management process in hard methods referring to the foundations included in the cascade approach. Referring to the obtained research results to the literature on the subject, it should be noted that in most of the analyzed cases, respondents declare that they plan to manage key risk factors, which is not mentioned in light methods in the agile approach to management projects. Therefore, it should be emphasized that even if it is proposed to move away from the project risk management processes in the scope of using these methods, executives mostly (although with different frequency depending on the nature, requirements, and the complexity of the project being implemented) use risk management processes both when planning and implementing the project (Figure 3).

In the vast majority of cases analyzed, the delegation of activities related to monitoring and responding to risk factors occurring during project execution to the software development team occurs sometimes (Figure 4). A frequent justification for the experts’ answers was that if you increase the responsibility of individual members or the whole team with additional activities not directly related to the manufacturing process, the number of elements that should be implemented in the current iteration will proportionally decrease in relation to the labor intensity of the additional activities entrusted.

In the surveyed sample, 55.55% of respondents declare that in projects with their participation, the management of key risk factors is escalated at the project management level, where in the case of 33.33% of respondents this occurs often and in 22.22%, always. The results obtained also highlight the relevance of monitoring and how to respond to the occurrence of key risks at the project level. Referring to the results where 7.41% of respondents believe that the management of key risk factors is not transferred to the project management level in projects with their participation, it should be noted that the project management level may not be present and all responsibility for additional risk management processes will be transferred to the team leader.

5. Discussion

The analysis of the literature (Highsmith 2009; Thamhain 2013; Stare 2014; Niazi et al. 2016; Hopkin 2018; Buganová and Šimíčková 2019; Tavares et al. 2020) and the results of the research obtained through the expert interview questionnaire provided a complete picture of the issue under study and identified the following components (sub-processes) of the risk management model:

• Identification of risk factors taking place at the software development team level and in the project planning and requirements verification stages at the project team level.
• Assessment of the impact of risk factors also taking place at the project and production team level.
• Response to the risks incurred at the level of the production team and to the key risks incurred at the project level.
• Risk monitoring as an overall process at the project level.
• Planning risk management activities at project level as the selection of appropriate methods, techniques, and responsibilities resulting from the adopted project management approach.
• Communication as a linking and emphasizing transparency element understood as the visibility of individual risk factors to stakeholders closely involved in the project.

The relevance of the data discussed above is also confirmed by the risk areas of the IT project identified using the principal components method. Furthermore, due to the importance in the project implementation process of the number of stakeholder interests presented in them and the analysis of the factors included in the individual risk areas, an additional area concerning the project requirements was also adopted as an element combining these risk areas. The IT project risk management model including all the components described above is presented graphically in Figure 5.

5.1. Planning of Risk Management Activities

Planning of risk management activities is a process that illustrates how to carry out risk management activities taking into account the importance of the project for the organization (its priority) and the nature of its activities or the complexity of the project. In addition, it includes a procedure diagram, the choice of the method to integrate the risk management process into the project cycle, and the persons responsible for the process at the project and production team level.

The procedure diagram allows to allocate adequate time to the risk management processes in an iteration. According to the approach in agile methods, attention is paid to the duration of the iteration, which should not exceed four weeks. The authors of the Scrum method additionally specify precisely the maximum time the team should spend on each activity (Schwaber and Sutherland 2017). As a result of deviating from Scrum’s methodological recommendations, the time involved in planning and reviewing and summarizing a sprint should not take up more than 5% of the total iteration time. Practitioners note, however, that this is reasonable for goal setting, planning, and review, but rare for retrospectives, with less than 2 h spent on it. Given that the “maximum” duration of individual activities within an iteration is assumed, it is possible, in line with the AgilePM approach, to set aside a separate time for risk analysis. Specific requirements and functionalities or features of the product are divided into user stories, which, arranged according to priority, form one of the most important documents (Product Backlog), which the team must complete when starting to work on the project. Therefore, it is necessary to consider the possibility of developing additional user stories related to risk analysis included in the Product Backlog, prioritizing them, and treating them analogously to other product functionalities specifying their size and value.

5.2. Identification and Assessment of the Impact of Risk Factors

Identifying risk factors is the process of determining how to identify potential opportunities and threats (that may affect the various stages of the project) and documenting the characteristics of these risk factors (PMI 2017). On the other hand, the assessment of the impact of risk factors on the project implementation consists in the estimation of the magnitude of probability and consequences of the occurrence of previously identified risk factors. At this stage, a prioritization of the identified risk factors is performed according to their potential impact on the project implementation process. The identification and assessment of risk factors at a fixed point in time (at the beginning and end of an iteration) include the identification and assessment of the impact of factors related to both the project and the manufacturing process. Only in the case of a hybrid approach, combining traditional and agile approaches, is it possible to disregard risk factors arising from the nature of the project, as these should be identified during the project planning phase. The continuous process includes the identification and evaluation of only those factors that arise directly from the product manufacturing process within each iteration. Then the team leader (e.g., Scrum Master) should note and report the issues communicated by the team during the daily meetings.

The result of the risk factor identification and assessment processes is a list of identified risk factors, which in turn should be assessed in terms of their impact on the project (effect) and the likelihood of occurrence. Furthermore, the list of identified and assessed risk factors should be described in as much detail as seems reasonable from the point of view of the project team in a given situation.

5.3. Risk Response

Risk response is a process involving the preparation of courses of action (responses) to be used in the event that the risk materializes. Regardless of the method by which the project is conducted, if a strategy other than acceptance is chosen for risk management, the project plan should be adjusted. In an agile approach to project management, this should also be done. If a risk avoidance strategy is chosen, it is recommended that the associated activities are assigned to be implemented in the closest possible iteration. The risk factor in question will then have a lower probability of occurrence. Agile methods, due to the short lead times of individual iterations, daily meetings of team members, or constant contact with the customer, have a built-in risk mitigation strategy with an almost immediate response. However, if a risk transfer strategy is chosen, decision-making and actions should be transferred to the project management level. It is also worth pointing out that decisions on the use of given sets of risk mitigation actions should be made in iteration planning, then the time in which the team takes executive actions is not limited.

5.4. Risk Monitoring

Risk monitoring is the process of implementing a risk management plan, continuously observing and overseeing identified risks, identifying newly emerging risks, and systematically evaluating the effectiveness of preventive actions taken (PMI 2017).

Methods, project management standards (PMBoK, PRINCE2, ICB4.0), and risk management models dedicated to specific industries indicate single responsibility for specific areas, categories, or risk factors. The named person responsible for monitoring and managing all aspects related to the assigned risk, including the application of appropriate responses, is referred to as the risk owner (PMI 2017). Taking into account the way the risk management process is integrated into the software development process and the adopted phase model (project life cycle), the responsibility for risk or its individual areas or risk factors will be different.

In the case of the light approach (e.g., Scrum), the responsibility for risk factors related to areas such as project requirements/scope including product quality, user/customer, or organizational culture including decision-making time will lie with the Product Owner. However, other risks belonging to areas such as schedule/cost, project team, technical and technological environment, or project organizational environment will be the responsibility of the Scrum Master. In the case of the hard approach (e.g., AgilePM), the responsibility should be the same as in the light approach except for the monitoring of key risks, which should then be escalated to the project level, where the responsible person should be the project manager.

5.5. Organizational Culture

The implementation of IT projects should fit into the organizational culture (Gheni et al. 2017). The way decisions are made, the definition of frameworks, methods, and techniques of communication within the team as well as with the project environment, or the prioritization of requirements without a proper organizational culture are the basic factors relating to project failure. Organizational culture itself may also be perceived differently by persons performing particular functions inside and outside the company (Kunda and Van Maanen 1999). The literature distinguishes the following types of organizational culture: Management level, specialists, departments, IT managers, IT team, customer.

Taking into account areas such as maturity, experience, project methods, or the way of escalation and decision-making, it can be concluded that the implementation of IT projects in a company usually influences and verifies many aspects related to the company’s organisational culture, which translates at later stages into project success (Gheni et al. 2017). The main risk factors arising in this area can be: Double subordination, inconsistency of decision making, social implications often due to cultural differences, awareness of the way the project is run by the customer and the management, support from senior management, project organization, consistency of project objectives and priority, identification of staff with the structure and project approach, developed so-called “project thinking,” organizational values and principles, flexibility and pro-activity of staff, development orientation, etc.

5.6. Schedule/Cost

In the literature, project timing as one of the components of objectives is interpreted in two ways (Frame 2002). Firstly, it is defined as the time within which the project is carried out. Secondly, it is defined in relation to the calendar dates of the project. Meanwhile, cost in the project management literature is defined as the value, expressed in monetary units, of the resources consumed in connection with the preparation and implementation of a project (Frame 2002). So, looking at the cost of a project as a whole, on the one hand, it is the total project budget and its source of funding—often external (the company commissioning the software development)—and on the other hand, is the associated project priority of external suppliers and contractors. In the agile approach to project management, from the customer’s perspective, project delivery time and cost are one of the main areas of risk.

Thus, the above area includes such risk factors as: Maintaining financial liquidity of the project, stability of financing, the level of project priority, the amount of committed resources for implementation or the scope of signed contracts with suppliers and underestimation or overestimation of time consumption of particular tasks, the availability of specific resources within specified deadlines, the period of decision-making on the part of the customer and the organization, or the detail of planning, as well as risk factors directly related to the project management process (i.e., fixed iteration duration or team meeting time).

5.7. Project Organizational Environment

In the literature, the term project organizational environment (project context) is defined as the set of conditions in which a project is implemented (Rozhkov et al. 2013). Furthermore, the perception of the project organizational environment is highlighted in two aspects:

• Operational—taking into account the project’s conditions resulting from its environment (Gu et al. 2014).
• Systemic—consisting of adjusting the used methods, techniques, and tools of project management to the level of project maturity of the organization (Besner and Hobbs 2008).

In agile project management, the project organizational environment (contextual approach) is expressed through applying the principals of the methods used, relating to the principles of the Agile Software Development Manifesto, and integrating the project into the user and environment (stakeholders) including the team producing the solution (Collyer and Warren 2009). In connection with the above, the awareness of the methods used to conduct projects, the incremental delivery of the final product, or the lack of detailed plans and the frequency of changes that occur during the project, but also the principles of cooperation and communication inside and outside the project team, undoubtedly characterize the project organizational environment.

5.8. Project Team

The success of IT project management largely depends on the customer’s obtained satisfaction with the end product of the project (Gheni et al. 2017). These products are the result of the work of an experienced, expert project team headed by a project manager or project leader. The risk resulting from the functioning of the project team or stakeholders closely related to the project is undoubtedly one of the most significant (Trzeciak 2020), which is confirmed by reports on successes and failures of projects in the IT sector.

The risk factors for the project team area are directly related to its functioning. The most frequently indicated risk factors directly related to the team include, among others: Communication and team cooperation, number of specialists, experts, knowledge and experience, involvement, availability, or increasingly indicated personalities, i.e., emotional maturity, resistance to stress, proactivity.

5.9. User/Customer

Meeting the expectations and requirements of all users and customers is not a small challenge, as evidenced by the project success data for tens of thousands of IT projects collected and published by the Standish Group. In addition, one of the reasons for such circumstances is the failure to ensure an adequate level of usable quality for the manufactured product and the lack of acceptance of the product in the user environment (Gheni et al. 2017).

Therefore, user participation in an IT project can positively or negatively affect the quality of the product produced, which will contribute to its performance in the user environment and the fulfillment of requirements by the production team. Ensuring a high level of user satisfaction is therefore clearly one of the important areas of project risk. The main factors belonging to this area include the definition of responsibility between the customer and the project team, underestimation of the time required for product integration on the customer side, multi-tasking of the team within the customer organization, verification and decision-making time on the customer side, knowledge of the product logic by the implementation team on the customer side, commitment and availability of the customer, etc.

5.10. Technical and Technological Environment

Some of the elements that distinguish IT projects from others include: Dynamic development of technology, uniqueness of solutions, often resulting from dynamic changes in technology and an environment not encountered in other areas where changes are implemented, creativity, prototypicality or multidimensionality of implementation and complexity of IT systems requirements (Trzeciak 2020). Furthermore, the technical and technological aspect is also raised as a component that builds the success of an IT project (Iqbal et al. 2019).

5.11. Categorization of Risk Management Processes in the Context of the GPM P5 Sustainable Development Standard

Taking into account the obtained results, one might get the impression that the same factors determine the failure or success in all complex IT projects. This would indicate that, in the context of risk management, it is not only necessary to control the success factors, but the failure factors as well. Moreover, there is also the possibility to classify individual risk management processes that play a key role in integration, control, and monitoring, by following the GPM P5 Standard for Sustainability in Project Management concept (

Table 6. Risk management processes and GPM P5 Standard for Sustainability in Project Management.

P5	Risk Management Processes
Presiding	Planning of risk management activities
People	Assessment of risk factors
Process	Risk response; Identification risk factors
Pragmatic	Communication
Performance	Risk monitoring

).

Presiding: The planning of risk management activities is a process that illustrates how to carry out risk management activities taking into account the importance of the project for the organization and the nature of its activities or the complexity of the project. Undoubtedly, the risk factors described in the six identified risk areas induce critical thinking and optimization of operations in complex IT projects (Woźniak 2021).

People: The assessment of the impact of risk factors on the project implementation consists in the estimation of the magnitude of probability and consequences of the occurrence of previously identified risk factors. One can find literature that provides empirical proof for people not only being a valuable resource in every project but foremostly them being a sensitive asset (Gharajeh 2019; Heeager and Nielsen 2018, p. 30.; Raharjo and Purwandari 2020). Moreover, the key to achieving success in a project is people (Malik et al. 2021; Koch and Schermuly 2020; Batra et al. 2017), who are presented as the second concept with the GPM P5 Standard for Sustainability in Project Management. In consequence, human skills should be integrated with the sustainable development of IT projects and the project team (Woźniak 2021; Zaleski and Michalski 2021).

Process: A process concept is an important part of risk management in the P5 concept, first and foremost as it might help to narrow down the range by focusing only on few critical factors, that require an appropriate reaction. Moreover, risk response is a process involving the preparation of courses of action (responses) to be used in the event that the risk materializes. Regardless of the method by which the project is conducted, if a strategy other than acceptance is chosen for risk management, the project plan should be adjusted. In an agile approach to project management, this should also be done.

Pragmatic: The pragmatic conception focuses on technical perspectives in risk management, by identifying the context and consequences. Having an effective means for expression and communication, without doubt, provides clarity and integrity. Moreover, communication is a core aspect of every project, because it is a binding element and emphasizes transparency (understood as the visibility of individual risk factors for stakeholders closely involved in the implementation of the project).

Performance: An efficiency factor, that is used to measure efficiency and the projects’ progress. Risk monitoring is the process of implementing a risk management plan, continuously observing and overseeing identified risks, identifying newly emerging risks and systematically evaluating the effectiveness of preventive actions taken (PMI 2017).

6. Conclusions

The aim of this paper was to develop a model for risk management in agile project management. Following the research effort undertaken, including the empirical research conducted, the stated aim was achieved. The research presented in this article has both theoretical and practical contributions. In particular, this study builds knowledge in the area of IT project risk management.

In the theoretical part of the work, the literature was reviewed in terms of:

• Evaluation of the agile approach to project management.
• Characteristics of agile methods used to manage IT projects.
• Risk management processes in an agile project management approach.

The analysis of the literature allowed the identification of a gap in the current state of knowledge and to formulate the research problem.

Research on verification of IT project risk management processes implemented underline the importance of the impact of risk analysis on the project’s success. The analysis of the results obtained also confirms the belief that basic processes, such as recognition (identification) of risk factors, impact assessment, and management of key risk factors, are used by managers and/or team leaders during the implementation of IT projects.

In addition, 68.52% of respondents who declared that, in most projects with their participation, identify, assess impact, and manage key risk factors, believe that risk analysis is significant for the success of the project. Identification and assessment of risk factors as components of risk analysis, depending on the light or hard agile methods used, take place at the level of the development team and/or design team. In light methods (e.g., Scrum), in the absence of a precise (additional) function of a project manager, which is not mentioned in the Scrum Guide, all responsibility for project risk management (including activities related to identification, impact assessment, response, and monitoring of risk factors) is escalated to the team leader. However, if there is a formal function of a project manager or a related one with a similar scope of competence, then activities related to the monitoring of and response to the occurrence of key risk factors and risk factors directly resulting from the implementation of the project will take place at the level of the project team. On the other hand, activities related to the risk analysis of the production process (e.g., software) will take place at the level of the development team, which is also suggested in hard agile methods.

Another value achieved in this paper was the empirical identification of the most common groups of risk factors found in IT projects. Following an established research process using expert interviews with 108 experts, 409 potential risk factors were identified. By successively grouping them according to the characteristics to which they referred and counting the occurrence of identical cases, a list of 27 potential IT project risk factor groups was obtained. In the further research process, the impact of the identified and grouped risk factors on the success of the project was measured on the basis of the results obtained from the survey, using a questionnaire survey. In addition, using the principal components method, six proprietary risk management areas were identified that describe 73.92% of all risk factors that may occur during an IT project, such as organizational culture, schedule/cost, project organizational environment, project team, user/customer, and technical and technological environment.

This also allowed for positive verification of the research hypothesis: “Identifying risk areas is crucial for risk management in an agile approach to project management”.

It is recommended to carry out research on the verification of the developed model in practice and to verify the influence of selected areas on the development of IT project success—which will be the subject of the author’s next study. In addition, taking into account the innovative solutions and proposals presented in this article, future studies might focus on:

• Verification of internal processes and procedures that build organizational culture, with a significant emphasis on eliminating its impact on the risk level of projects implemented by the organization.
• Empirical determination of the relations between the project and/or production team and the external client, taking into account the possibility of minimizing the occurrence of potential project risk factors.