Risk management of projects. Theoretical foundations and approaches for Scrum

Research Paper (undergraduate) , 2017 , 20 Pages , Grade: 1.0

Business economics - Business Management, Corporate Governance

As a result of global networking, software development projects are carried out in cooperation with foreign specialists. This increases efficiency, but also increases the probability of personnel, cultural and legal risks. The software industry is highly dynamic and the market situation is changing due to the rapid development of new technologies.

To complete projects efficiently, companies rely on agile development procedures such as Scrum. Although Scrum is not part of the project management procedures, it takes over some points from classic project management: work packages must be prioritized, estimated and planned for the individual sprints. Scrum has few risk management approaches, which means that gaps can be identified, e.g. risks due to missing fixed prices, planning reliability. Thus, software vendors are in the dilemma of having to balance the pace of product development and product quality while considering the risks. This paper provides an exemplary elaboration on how Scrum can be expanded with little time and cost input through risk management.

TABLE OF CONTENTS

I LIST OF ILLUSTRATIONS

II. LIST OF ABBREVIATIONS

III LIST OF TABLES

1. INTRODUCTION

2 THEORETICAL BASICS
2.1 Definition of "risk" and "risk management"
2.2 Project Risk Management Process
2.3 Categorization of risks
2.4 Risk management in project procedure models

3 THE RISK MANAGEMENT APPROACHES FOR SCRUM
3.1 Current point of view and problem description
3.2 Practical relevance
3.3 Methods and tools
3.3.1 Risk identification tools
3.3.2 Risk assessment tools
3.3.3 Distribution of roles
3.3.4 Documentation
3.4 Implementation phase

4. CONCLUSION AND OUTLOOK

BIBLIOGRAPHY

I LIST OF ILLUSTRATIONS

Fig. 1: Risk matrix with risk values

II LIST OF ABBREVIATIONS

Abbildung in dieser Leseprobe nicht enthalten

III LIST OF TABLES

Table 1. risk list

Table 2: Integration of risks in Scrum

1. INTRODUCTION

This thesis deals with the task of supplementing a Scrum based project with risk management approaches using an example case of a medium-sized international company. As a consequence of global networking, software development projects are carried out in cooperation with foreign specialists. This increases efficiency, but also increases the probability of personnel, cultural and legal risks. The software industry is highly dynamic and the market situation is changing due to the rapid development of new technologies. To complete projects efficiently, companies rely on agile development procedures such as Scrum. Although Scrum is not part of the project management procedures¹, it takes over some points from classic project management: work packages must be prioritized, estimated and planned for the individual sprints. Scrum has few risk management approaches, which means that gaps can be identified, e.g. risks due to missing fixed prices, planning reliability. Thus, software vendors are in the dilemma of having to balance the pace of product development and product quality while considering the risks. This paper provides an exemplary elaboration on how Scrum can be expanded with little time and cost input through risk management. Even though there are already initial approaches by other authors² to complement Scrum with risk management, there is still no approach for role allocation, framework supplementation and risk assessment as a uniform elaboration within the project. After the introduction in chapter 1, chapter 2 provides the basics of the technical terms and the methods of risk management (limited to two process steps), as well as a list of risk types. In chapter 3 the implementation of risk management in a Scrum based project is demonstrated with a constructed case study. The conclusion of the work in chapter 4 summarizes the results and provides suggestions for further research. It is not possible to work out a basically optimal solution, because the procedure is strongly influenced by situational peculiarities.

2. THEORETICAL BASICS

2.1 Definition of "risk" and "risk management”

The success of a project depends on various factors, under consideration of which future events with negative (risk) or positive effects (opportunity) can be controlled. "A risk is an uncertainty that endangers the project goals"³ and will occur with a certain probability. According to Patzak's definition⁴, a risk represents a characteristic of a future situation, which is recorded as the probability of the occurrence of an undesired event. The planned results can also result with positive consequences (chances), but this thesis will not go into this aspect in detail. A risk from the IT area (IT risk) "...represents a subset of general risks and is not defined differently in principle. "⁵ The term risk management in Wallmüller⁶ 's definition is "a systematic process for identification, analysis and control in the sense of monitoring and controlling risks in projects or organizations". Ebert⁷ regards it as "a management technique that deals with the systematic identification, analysis, documentation and treatment of risks". In terms of a project, risk management is part of project management; in terms of a product line or market, it is part of operational or strategic management⁸. The present paper focuses on project-related risk management, which is oriented towards the consequences of project deviations and aims to identify risks and their potential consequences in time and to intervene when they occur. Project risk management and IT risk management are to be regarded as components of enterprise risk management, the aim of which is to identify, assess and deal with project and IT risks at an early stage at the operating level using suitable methods and documentation.

2.2 Project Risk Management Process

From the definition of the term, the structure of risk management can be recognized as a cyclical process with several phases. Thus, the conceivable risks are identified, evaluated, designed and monitored before the project start and during the course of a project. The phases of risk management cannot be clearly assigned to the phases of the management process⁹, which is why risk management must be carried out as an accompanying process. In the literature there is no uniform structural specification with regard to individual steps. Ebert divides¹⁰ the risk management process into identification, evaluation, mitigation and tracking. According to Bea¹¹, a risk management process includes risk identification, risk analysis, risk evaluation, risk design and risk monitoring. Wanner¹² begins with risk management planning, followed by risk identification, risk analysis, action planning, monitoring and control, accompanied by communication. Gaulke¹³ distinguishes between risk identification, risk analysis and evaluation, risk communication, risk monitoring. Becker¹⁴ points out that documentation and communication are important parts of risk management. The case study of this thesis deals with project risk management in a medium-sized company, where the biggest methodological differences in the area of risk identification and -rating.¹⁵ These two stages of the risk management process are therefore discussed in more detail. Risk identification" aims to identify and collect all possible risks that may arise during the course of a project at an early stage. Difficulties may arise in the identification of risks, e.g. that not every team member is able to recognize and name risks.¹⁶ As a result, the assessment of risks in internationally staffed project teams can vary. To identify risks, IT risk management uses methods from quality assurance, project management and enterprise risk management: Failure/event tree analysis, FMEA, risk-based testing, stress testing, Delphi method, evaluation, IT risk inventory, IT risk indicators, HRA, PAAG/HAZOP, sensitivity analysis, SWOT analysis, brainstorming, risk checklists, risk matrix, brainwriting, etc. Risk assessment and analysis follow directly after risk identification. Following the literature sources from chapter 2.2, they are to be considered either as parts of one stage or as separate consecutive stages. Burghardt¹⁷ describes the first process stage as a risk analysis consisting of risk identification and assessment. In the risk assessment, the identified risks are to be located, assessed with regard to probability of occurrence and extent of damage and classified in order to estimate the possible hazard potential. The analysis is carried out in the next step or, depending on the method, simultaneously. The risk assessment provides the basis for risk prioritization, monitoring and minimization through measures that either reduce the probability of occurrence or intervene when the risk occurs. Risk indicators are important to indicate an upcoming or already occurred project risk. The evaluation and analysis can be carried out using numerous methods, which are divided into qualitative (evaluation scale, risk matrix), quantitative (sensitivity analysis, decision tree analysis) and hybrid methods that support¹⁸ both evaluation methods (Delphi method, Monte Carlo simulation). The presented possibilities for risk assessment represent only a small part of the variety of risk assessment methods. The discussion of the subsequent stages of the risk management process such as risk prioritization, risk planning, risk monitoring, risk treatment and controlling can be found in the literature sources mentioned in chapter 2.2. However, this paper deals with risk management in the identification and evaluation phase, other phases are not discussed in detail.

2.3 Categorization of risks

Project risks can be assigned to different risk categories, which help to systematically identify risks and contribute¹⁹ to the effectiveness and quality of risk identification. Burghardt²⁰ divides the risks into market and industry risks, management risks, process risks, product risks, personnel risks, financial and legal risks. Werner²¹ categorizes the risks into political, economic, social and cultural, technical and country risks. Ebert²² distinguishes between technical, economic, industrial, operational, strategic, implementation and business risks. It can be seen that there is no uniform catalog of risk types in the literature. In addition to the risks that are identified on a project­specific basis using various methods, the sector-related core risks must also be taken into account. Several literature sources²³ provide a list of the core risks of software projects. In this thesis the list "Top 10 Software Risk Items" by Boehm²⁴ is used, which contains not only the risks of product-technical origin, but also the risks from the social or organizational area. However, some risks remain outside the consideration, such as market and industry risks: Technological change, product innovation by competitors, price decline in the target market; management risks: unexpected change of strategy, choice of unsuitable sales channels; process risks (unclear task definition) etc. Software development projects involve many risks, but it would go beyond the limits of this work to create a risk catalog from all areas of activity.

2.4. Risk management in project procedure models

The process organization of a project is recorded in a process model, which is made up of different phases. The main task of such models is to increase the efficiency and traceability of the project process. The process models decompose the complex development process of a software product into partial activities and define their results in a logical and temporal context. In addition²⁵ to the classical linear (waterfall model, V-model XT) and cyclic (RUP, spiral model), agile software development with flexible design of the development process is added (Extreme Programming (XP), Crystal, Scrum).²⁶ According to Bea's recommendation, agile methods should be used for small projects with high dynamics. Scrum represents an extension of the incremental software development method, whose process organization is divided into individual sprints (cycles). The compact design of the internal roles (Product Owner, Scrum Master, Development Team), the documentation (Product Backlog, Sprint Backlog, Burndown Chart) contribute to agility.

3. THE RISK MANAGEMENT APPROACHES FOR SCRUM

3.1 Initial situation and problem description

The following data is used for this work: A medium-sized international software company conducts its development projects using Scrum. The Scrum Master proposes to add risk management to the new project in order to minimize errors and reduce development costs. The managing director agrees, but excludes the change to classical process models, as well as the development of combination models. The risk management should be adapted to Scrum without loss of agility, since the medium­sized company has limited time, financial and personnel resources. The staff consists of technology experts and all-rounders, who perform several tasks from different areas. The projects are uniquely designed, there are no experience reports or risks based on previous projects. A deviation from the project goals can cause additional costs for the company, therefore risk management should be implemented continuously. However, the implementation itself is an extensive project, so this work is reduced to an example project. The following goal is derived from the described situation: By means of an exemplary case the risk management approaches for the identification and evaluation of risks will be demonstrated as a supplement for a Scrum based project.

3.2 Practical relevance

Risk management as a supplement to Scrum enables the consideration of conceivable IT project risks before the start of the project and the control of their impact on the course and outcome of the project. For medium-sized companies with limited financial resources, neglecting risks can have a direct impact on the entire company. Especially for companies where no project manager for IT risks is foreseen as a position, the results of this work are important in order to still make project-related decisions in time, to rethink the corporate strategy (e.g. a marketing campaign for certain product features that are currently under development) and to make further development projects more efficient. This work does not represent a final, static and optimal solution. It should lead to a learning cycle with continuous improvement of risk management. Changes to the process itself or to the methods and tools used are conceivable.

3.3 Methods and tools

3.3.1 Risk identification tools

For a medium-size enterprise an employment of an expert questioning is recommendable²⁷, this is rejected however for cost reasons. To identify the core risks, the "Top 10 Software Risk Items" list from Boehm is used. Additionally, risks from international projects are considered in the case study. With the help of brainwriting, a list of project-relevant risks is recorded, because the "pure" checklist is not related to work packages. This method is used because of its simplicity and resource conservation. It offers an optimal way of expression for employees who are not so good at expressing themselves in a foreign language or who do not want to address "sensitive risks" for cultural reasons. The role of the project manager is divided into several roles, thus reducing cultural differences and hierarchies. The disadvantage of a loss of spontaneity in this method is mitigated by the Scrum Master moderation in a chat conference. The risk list is supplemented by consequence descriptions to avoid culture-dependent interpretations.²⁸

3.3.2 Risk assessment tools

According to²⁹ Wanner's recommendation, more time is invested in risk identification and qualitative methods, quantitative methods are not used. A risk matrix is created for the quick evaluation of risks. For the employees with large culture-specific power distance a moderated evaluation session is to be accomplished³⁰, which is organized as video conference. In this way a lack of exchange of experience between the participants is avoided. The risks are evaluated by each participant and visualized on a virtual pinboard. There will be 10 minutes time to give an individual evaluation, long discussions are avoided by the moderator.

3.3.3 Distribution of roles

In an international environment, it is recommended to fill the role of the project manager (risk manager, if applicable), who does not take on any other tasks in the project and is exclusively responsible for the implementation of risk management³¹. This role is not provided for in Scrum and its introduction can destroy the hierarchical structure of Scrum. The "classic" project manager is not able to control and plan the process in very short cycles. Furthermore, the team's way of working cannot be integrated linearly into a classic project planning. For these reasons the risks have to be distributed between the existing roles and inserted into the process flow. The external and functional risks are assigned to the Product Owner, the Scrum Master monitors the optimal implementation of the adapted process. In addition, he takes over the recording of internal risks. The development team assumes the risks from the cooperation between departments and technology risks.

[...]

---

¹ Cf. war (2015), p.108

² Nelson et al. (2008) p.190 ff, Nyfjord (2008), Brandstäter (2013)

³ Wanner (2015), p.29

⁴ Cf. Patzak et al. (2014), p.49

⁵ Knoll (2014), p.8

⁶ Wallmüller (2014), p.13

⁷ Ebert (2006), p.7

⁸ See Ebert (2006), p.7

⁹ Cf. Bea et al. (2011), p.350

¹⁰ See Ebert (2006), p.13

¹¹ Cf. Bea et al. (2006), p. 351 ff

¹² Cf. Wanner (2015), p.26

¹³ Cf. Gaulke (2002), p. 12

¹⁴ Cf. Becker et al. (2015), p.14

¹⁵ Cf. Becker et al. (2015), p.25

¹⁶ See Hoffmann et.al (2004), p.277

¹⁷ Cf. Burghardt (2013), p.175

¹⁸ Cf. Wanner (2015), p.68

¹⁹ Cf. Wanner (2015), p.55

²⁰ See Burghardt (2013), p.177

²¹ Cf. Werner (2015), p.45

²² See Ebert (2006), p.17

²³ Sliger et.al (2008), p. 178 ff; DeMarco (2003), p. 109; Jalote (2000) p. 168 ff.

²⁴ Cf. Selby (2007), p.392

²⁵ See Abts (2011), p. 365

²⁶ Cf. Bea et. al (2011), p.437

²⁷ Cf. Becker et al. (2015), p.63

²⁸ Cf. Hoffmann et. al (2004), p.280

²⁹ Cf. Wanner (2015), p.79.

³⁰ Cf. Hoffmann et.al (2004), p.285

³¹ Cf. Hoffmann et.al (2004), p.276

• College: AKAD University of Applied Sciences Stuttgart
• Grade: 1.0
• Author: Larissa Petersen (Author)
• Publication Year: 2017
• Pages: 20
• Catalog Number: V954671
• ISBN (eBook): 9783346297952
• Language: English
• Tags: scrum, risk management