självständigt arbete på avancerad...

Optimization combined with process mapping for maximizing product utilization - Investigating the utilization of products in sawmills, a case study Jonas Höglund 2018-10-17

1

Självständigt arbete på avancerad nivå

Independent degree project – second cycle

Master of Science in Engineering Industrial Engineering and Management The Subjective Perception of Risks by individual key stakeholders within SCRUM A qualitative case study at an IT firm Aydin Sergen Yesilkayali, Nils Patrik Sidén Eriksson

The Subjective Perception of Risks by individual key stakeholders

within SCRUM – A qualitative case study at an IT firm

Aydin Sergen Yesilkayali, Nils Patrik Sidén Eriksson

2018-08-20

MID SWEDEN UNIVERSITY

Department of Information Systems and Technology (IST)

Examiner: Leif Olsson, [email protected]

Supervisor: Olof Nilsson, [email protected]

Authors: Aydin Sergen Yesilkayali ([email protected], Nils Patrik Sidén

Eriksson ([email protected])

Degree programme: Master of Science in Engineering: Industrial Engineering and

Management, 300 ECTS

Semester, year: 10, 2018

mailto:[email protected]

mailto:[email protected]




2018-08-20

Abstract The lack of knowledge regarding the perception of risks in agile project

management is evident in research. With this knowledge, this study sets

out to address this issue and close the gap in knowledge regarding this

issue by identifying the individual perception of risk by a project leader,

SCRUM master, and two system developers, and comparing the

individual appetite matrices to a unified appetite matrix created by a

Delphi panel. A case study at an IT consulting firm, working with several

projects in parallel, in Sweden is conducted. A risk register is used to

collect the data, with the principle of assisting in creation of the risk

appetite matrices. The result shows that the individual risk appetites

differ significantly from the group’s unified risk appetite. The group

showed itself far more risk aggressive than the individual appetite which

was risk aversive in relation to the group’s appetite. The lack of RM

practices is evident in smaller IT firms such as these, as there are no clear

standardized approaches to the mapping or classification of risks; a far

more informal approach is taken.

Keywords: Risk management, Risk perception, agile methodologies,

SCRUM, Agile project management.




2018-08-20

2

Sammanfattning Bristen på kunskap gällande uppfattningen av risker inom agila

förvaltningsprojekt uppenbarligas från tidigare forskning. Med detta i

åtanke, så eftersträvar denna studie till att ta uti med detta faktum och

bidra med ytterligare forskning inom forskningsområdet subjektiv

riskuppfattning inom agila projekt. I denna studie identifieras den

individuella uppfattningen av risker hos en projektledare, SCRUM

master och två systemutvecklare. Dessa riskuppfattningar illustreras och

jämförs med en unifierad aptitmatris vars data samlats genom

individuella intervjuer samt en Delphi-panel. Fallstudien utfördes på en

IT-konsultfirma i Sverige. Ett riskregister användes i syfte att strukturera

uppsamlad data. Resultatet av studien påvisar att den individuella

riskuppfattningen skiljer sig markant med gruppens unifierade

riskuppfattning. Gruppen visade sig vara mer riskaggressiva än den

individuella attityden, som prevalent var riskaversiv. Ett tydligt tecken

som uppvisade sig var att mindre IT-firmor kan ha problem inom

riskområdet i och med bristen på någon sorts standardiserad hantering

av risker.




2018-08-20

3

Acknowledgements We would like to thank our supervisor at Mid Sweden University, Olof

Nilsson for his helpful input on this study. We would also like to thank

the anonymous IT firm that the case study was conducted within.




2018-08-20

Table of contents

MID SWEDEN UNIVERSITY .............................................................................................................................................. 1

ABSTRACT ............................................................................................................................................................................. 1

SAMMANFATTNING .......................................................................................................................................................... 2

ACKNOWLEDGEMENTS .................................................................................................................................................... 3

1 INTRODUCTION ................................................................................................................................................................ 2

1.1 BACKGROUND AND PROBLEM MOTIVATION .................................................................................................................... 3 1.2 PURPOSE OF THE STUDY................................................................................................................................................ 4 1.3 DELIMITATIONS OF THE STUDY ....................................................................................................................................... 5 1.4 OVERVIEW ...................................................................................................................................................................... 5 1.5 THE AUTHORS’ CONTRIBUTIONS .................................................................................................................................... 6

2 THEORETICAL BACKGROUND ............................................................................................................................................ 7

2.1 AGILE METHODOLOGIES ........................................................................................................................................................ 7 2.1.1 Agile software development ........................................................................................................................................... 8 2.1.2 SCRUM ............................................................................................................................................................................. 9 2.1.3 Phases within agile projects start-end .......................................................................................................................... 11

2.2 RISK MANAGEMENT ........................................................................................................................................................... 13 2.2.1 Risk framework.............................................................................................................................................................. 13 2.2.2 Risk identification .......................................................................................................................................................... 16 2.2.3 Risk analysis .................................................................................................................................................................. 20 2.2.4 Risk evaluation .............................................................................................................................................................. 25

2.3 PREVIOUS RESEARCH .......................................................................................................................................................... 28

3 METHOD ........................................................................................................................................................................ 30

3.1 DATA COLLECTION ........................................................................................................................................................ 30 3.2 DESIGN ......................................................................................................................................................................... 30

3.2.1 Risk Management methodology ................................................................................................................................... 32 3.2.2 Risk identification .......................................................................................................................................................... 33 3.2.3 Risk analysis .................................................................................................................................................................. 34 3.2.4 Risk evaluation .............................................................................................................................................................. 34 3.2.5 Communication and consultation ................................................................................................................................. 35

3.3 QUALITATIVE METHODOLOGY .............................................................................................................................................. 35 3.3.1 Semi-structured interviews ............................................................................................................................................ 35 3.3.2 Coding of interviews ...................................................................................................................................................... 36 3.3.3 Delphi technique ............................................................................................................................................................ 36

3.4 CASE STUDY...................................................................................................................................................................... 39 3.5 Social and ethical principles ................................................................................................................................ 40 3.6 Validity and reliability ............................................................................................................................................ 40

4 RESULTS ......................................................................................................................................................................... 42

RISK IDENTIFICATION .................................................................................................................................................................. 42 4.1 First phase ............................................................................................................................................................. 42 4.2 Second phase ........................................................................................................................................................ 45 4.3 Third phase ............................................................................................................................................................ 50




2018-08-20

1

5 ANALYSIS ........................................................................................................................................................................ 54

RISK IDENTIFICATION ........................................................................................................................................................................ 54 RISK ANALYSIS ................................................................................................................................................................................. 55

5.1 Comparison of risk appetite matrices ................................................................................................................. 55 RISK EVALUATION ............................................................................................................................................................................ 60

5.1.3 Evaluation ..................................................................................................................................................................... 60

6 CONCLUSIONS ................................................................................................................................................................ 62

FUTURE RESEARCH ........................................................................................................................................................................... 63 REFERENCES ................................................................................................................................................................................... 64

ANNEX A: CASE STUDY INTERVIEWS ........................................................................................................................................ 67

PERSON A ...................................................................................................................................................................................... 67 PERSON B ...................................................................................................................................................................................... 72 PERSON C ...................................................................................................................................................................................... 75 PERSON D ...................................................................................................................................................................................... 80

ANNEX B: PUTTING POSSIBILITY AND IMPACT ONTO RISKS ..................................................................................................... 86




2018-08-20

2

1 Introduction Complexity in software development has been an issue that most IT

organizations have been struggling with for over 60 years. Common

complexities in software development projects are e.g. delays within the

partial and end deliveries of the project and misleading project goals.

This also implies increasing costs and lead times within the project – in

worst case even project cancellations. The usage of agile software

development has been increasing frequently since the establishing of the

Agile Manifesto, 2001. The nowadays called mainstream development

methodology has been approved by large software providers as

Microsoft, Adobe et al. (Schmidt, 2016)

The rate of success in software development projects is still an issue to

deal with. Recent year’s rate of successful projects is still remarkable low,

which implies a need for further research regarding potential issues.

(Haas, 2007; Hastie, 2015).

Low rate of success in traditional projects has led to increasing popularity

of the agile management project approach. Software development is built

upon the adeptness of processes which are both unpredictable and

complex, implying a low possibility of planning. Within the

organizational management, concerning about managing risks within

projects affects the actual insight of the organizations environment. In the

organizations environmental basis, most difficultness lies within the

management strategies of handling risks. These strategies are priority and

resources which are directly related to the handling of the risks. (Ribeiro,

2008)

Identifying and handling these risks in agile projects may be vital to the

success rate and reduce the cost in further projects. This can be done by

applying risk management analysis upon a case study that makes use

methodologies of agile software development.




2018-08-20

3

1.1 Background and problem motivation

Risks in relation to agile development methods are often neglected or

rarely intricately focused upon. Available literature in, e.g. Scrum, does

not delve in detail into the risks that may be apparent in a project by an

agile development team. (Smith & Pichler, 2018)

One parameter that is inherently fundamental in every organization is

resource saving. These “resources” can be defined as liquidity. Every risk

is likely to be tied to monetary value, e.g. risk that implies a time loss will

eventually imply an increased cost of the project. A risk analysis is done

in order to raise risk awareness and prepare for potential course of actions

to take in order to either reduce the probability of the risk occurring or to

mitigate it after its occurrence. (Hopkin, 2010)

There is disagreement among agile project owners whether explicit

methods of risk management should be applied within agile projects

(Walczak & Kuchta, 2013). To put the problem of IT projects and risks in

context of project failure; organizations in the United States spends $250

billion a year on IT projects, distributed among 175 000 projects. 31.1% of

these projects are cancelled before completion. 52.7% of the projects reach

costs of over 189% of their original estimates. The success rate is 16.2%

(i.e. completed on- time and on-budget) (Standish Group, 2014).

Previous studies that have been carried out shows that carrying out an

analysis of underlying and potential risks can reduce the waste of

resources. (Elbana & Sarker, 2016) Some studies fail to find how risk

management implicitly helps the mitigation (or reduction) of risks, while

others find apparent outcomes from the use of risk management. These

previous studies have suggested that further case studies to be done in

order to identify the necessity of risk management in context to agile

methods. (Walczak & Kuchta, 2013)




2018-08-20

4

The main study approach is to look into how risk management can be

applied within agile maintenance projects, and to give insight into how

this can be done efficiently without compromising the efficient work ethic

that is inherent within the agile approach. The main aim of agile methods

is to be fluid and flexible without compromising on time or cost. Risk

management adds another dimension to these two variables, which

makes some agile stakeholders question the necessity of applying a risk

methodology at all. By conducting a case study at an IT consulting firm

with an ongoing maintenance project (conducted with an agile Scrum

approach), it is of interest to expand the knowledge and provide new

insight into the compatibility of risk management and agile maintenance

projects.

1.2 Purpose of the study

This thesis aims to study what the general risks are within agile

maintenance projects, and to see if and in which extent risk management

methodology is compatible with such projects. Additionally, it is of

interest to study how the subjective perception of risk is classified by the

stakeholders within projects.

The research questions are formulated in order to answer the aim of the

study:

• What are the general risks within agile maintenance projects?

• In which ways is the used risk management methodology in this

study suitable respectively unsuitable for agile maintenance

projects?

• How does the perception of the general risks within agile projects

differ between key individuals?

The results of this study intend to add to the knowledge of the differing

perception of risks by different relevant stakeholders within agile work

methodologies. This study intends to add a wider awareness to if and

how this differing perception may look like and why.




2018-08-20

5

1.3 Delimitations of the study

This thesis will only dwell into the ongoing maintenance and

development project ongoing at a consulting firm where the case study is

done. The limitations of the research will be done in accordance to general

risks, and inherent risks in agile software development maintenance

projects. While this study is done relative to one case, the conclusions and

discussions will nevertheless be general and applicable to other agile

maintenance and development projects in general, and for projects where

differing perception of risks by important stakeholders might cause issues

or loss of trust for the project.

This study does not intend to look at intra-organizational risks, but rather

at specific general and common risks found within agile maintenance and

development projects.

Note that the case studied project is ongoing since 2014, and is

continuous until the firm’s customer decides to contract another firm

1.4 Overview

Chapter 2 describes the theoretical reference frame which the study is

based on.

Chapter 3 describes the methodology and its components used in the

study.

Chapter 4 describes the construction and alternative solutions of the

study.

Chapter 5 describes the results of the study.

Chapter 6 describes the conclusion drawn of the study.




2018-08-20

6

1.5 The authors’ contributions

This study is done by two students studying Master of Science in

Engineering in Industrial Engineering and Management at the University

of Mid Sweden University. The study is written equally by both writers.

Both writers have an equal contribution in every chapter and sub chapter.

As the interest and focus of one author is towards one field, and the other

towards the other field, the authors have been able to help and learn from

each other, as well as provide more in-depth insight into respective fields,

rather than focusing on fundamental parts of respective field. The cultural

background of the authors have contributed as well, as both agile work

ethics and perception of risk management can be argued to have a

cultural variable, this has given rise to interesting discussions and helped

with the conclusions of this study.




2018-08-20

7

2 Theoretical background Today’s organizations face efficiency goals mainly consisting of cost and

resource efficiency. Close relationships between stakeholders and

customers have to be ensured through identification and tracking of

those. Due to these restricted environments management of uncertainty

has to work properly. Also, customers have to be satisfied with fewer

resources. (Augustine, 2008)

2.1 Agile methodologies

The fundamentals of agile methodologies are based on the terms of

agility. These implies delivering value to the customer while handling

unpredictability and dynamisms within projects in the form of

recognizing and being adaptive to change. Direct related to agility is

also to sustain flexibility and stability, dealing with chaos, performance

planning and explorative optimization. Ability to adjust the speed of

value added deliveries to the customer with respect to changes and

uncertainty. Techniques related to agile methods are divided into

partial workflow blocks to get feedback from customers and end users

in an early stage to provide managing of complexities. Sprints and

releases are commonly finished within a period of one-three months.

The processes and tests are iterative and incremental carried out to

incubate requirements, plans, code and design. Iterations are set up with

a fixed length of usually two weeks. This is due to ensure information is

achieved through feedback and maintain stability. Collocation in open

work cell is performed to permeate the whole team with included onsite

custom to facilitate face to face communication and sufficient

interactions between team members. (Augustine, 2008)

Provided team rooms make extempore meetings possible to discuss

design procedures and both informal and formal activities within the

groups. A plan backlog is used to define high level desired features

whose prioritization is set by the customer. A release planning game is

performed to let developers handle prioritization through collaborative.

The effort estimates are soon provided by the developers and business

priority is set by the customer. An iteration plan backlog handles part of




2018-08-20

8

the release plan such as features of high level which are prioritized

along and elaborated upon within tasks of implementation in the

desired plan backlog. Developers set up prioritization through

collaborative during an iteration planning game. Effort estimates are

soon provided by the developers and business priority is set by the

customer.

(Augustine, 2008)

Team members are self-organizing through collaborative, continuous

finishing of tasks within the backlogs excluding a top to down control

management. While iteration is active, tracing of tasks and features is

carried out. Tracing is active until 100 percent is finished and there is no

room for partial completions. All work related to Agile methodologies

has to be of simple, lean character and adaptable to maintain value

added processes to customer and adapting to change. (Augustine, 2008)

2.1.1 Agile software development

Since the early 2000’s Agile Software Development has seen major

changes in relation to software development. This is a result of new

ideas among developers through the global community which has been

shared through the World Wide Web. This has also meant that the

requirement for the ability to change and adapt to the customers wishes

has changed. As the global market has emerged from the birth of

internet, the global community has given rise to more thoughts of

abstract and different character; one project can during its lifetime

require several different requirements and customer wishes to the

functions that the end-product will contain. This means that the

functionality of the product must be flexible but also strictly follow the

criteria set by the customer’s order. (Schmidt, 2016)

The Agile Software Development (ASD) incorporates from its four core

values; Individuals and interactions; Working software; Customer

collaboration; Responding to change. The main processes and activities

are based on iterative, incremental software development. (Highsmith,

2002)




2018-08-20

9

As collection concepts “agile methods” is formed by software

engineering methods introduced in the beginning of 2000’s and the core

values within the engineering of ASD. As the agile method developed it

can be derived that two integrated methods has become the most

popular ones: SCRUM and eXtreme Programming. (Maruping et al,

2009).

2.1.2 SCRUM

Scrum is an agile project management methodology produced as a

framework for product development with adaptiveness to different

complex projects. The framework structure is shown in figure 1

consisting the fundamentals of SCRUM and its contents including roles,

artifacts and events. (Schwaber & Sutherland, 2013; Cervone, 2011;

Misra et al, 2009)

Figure 1: The Agile SCRUM process. (Agileforall, 2015)




2018-08-20

10

A scrum project is introduced with a kick-off, following with a sprint

planning consisting a deposited time scale per sprint and month up to

eight hours. Sprint planning includes the estimation of work duration

and time needed to complete the highest prioritized items within the

Product backlog by dint of planning poker. After estimation is done, the

development team will select items to be done within the sprint,

initiated with the most prioritized; selecting items will be done from a

list named Sprint backlog. Inherently the development team will

iteratively query themselves how necessary the work is to reach the

goal. This is done every time when items within the sprint backlog are

considered, thus the goal must be defined. As soon as the sprint

planning is completed, the development team will start working on

items. A sprint is defined to have a fixed time scale where the goal is to

complete involved items within the deposited time. No changes will be

made to the items within an active sprint except in special cases if the

extent or value is changed. Items within the Sprint which are not

finished will be restarted and replaced into the product backlog and

taken care of in further coming sprint planning. (Schwaber &

Sutherland, 2013; Cervone, 2011;

Misra et al, 2009)

Inherent to the sprint, daily scrum meetings consisting of 15 minutes per

session are being performed every day. As prerequisite for the meetings

is that all individuals attend at the meeting and being well prepared,

answering three questions; What have I done since last meeting; What to

do until next meeting; What obstacles prevents me to reach the goal?

Responsible for the meetings is the Scrum Master which intends to that

all three questions being answered and that all members are attended.

After completing each sprint a sprint review is performed with a time

scale of four hours per month and a sprint to review the performed

sprint. (Schwaber & Sutherland, 2013) The latter presented by the

framework is the Sprint retrospective meeting where used techniques,

processes and all involved parties are being evaluated with a critical

vision. This generates answers to how the work was done within the

performed sprint in order to find improvements and suggestions to

further sprints.

(Schwaber & Sutherland, 2013; Cervone, 2011; Misra et al, 2009)




2018-08-20

11

2.1.3 Phases within agile projects start-end

Agile software development and its inherent project phases build upon

the agile project management. Within the agile project team, the

assessment of possibilities and the vital project phases are crucial to the

value creating processes. Availability to be included or excluded in the

team will permeate composting in the Organic Team implying

adaptability to changes in surrounding conditions. Due to construction

of small teams, communication flows will function properly and

sustaining a low interaction penalty. In case of larger scale where larger

teams are needed, the project will be organized into smaller organic

teams which performing work in parallel to each other. (Augustine,

2008)

Adaptation and anticipation is directly related as a mechanism to the

mental models of the team members involved. A shared mental model

has the highest magnitude of the member’s behaviors’ when a project

statement purpose is translated in accordance to the vision of the

project. These principles build upon the U.S army’ commanders’ intent

and the Army’s awareness of that the leader can’t be omnipresent. The

manager of an agile project relates to these principles by constantly

guidance of the team and supporting the team to consistently make

right choices. A “good enough” vision is created by input change and

assumptions instead of time consuming detailed plans. This implies that

focus may be directed and applied to desirable outcomes and tasks

associated to the plan will appear during time plan. Within

methodologies, rules appear as a constant underlying supporting

process. It’s common that these rules being seen as burdensome and as

an impact not being followed throughout the workflow. The

fundamentals of APM (Agile Project Management) are constructed so

that the team members follow simple rules, over time complex

behaviors’ occurs within these. Information flow is the causal agent for

enabling adaptation and change within agile projects. Most exchange of

information occurs when members interact with each other and it

appears that openness has the most impact of how rich the information

is. (Augustine, 2008)




2018-08-20

12

Adaptability of an agile team is directly related to dependency of a well-

functioning information flow. To prevent disruptions within the

information flow caused by organization bottlenecks, these obstacles has

to be constantly identified and removed. Due to inherent uncertainties

in the world and its circumstances, control and stability is hard to

achieve. Managers has nowadays realized and accepted how unrealistic

it is to foreseen knowledge about future outcomes. This has resulted in a

control methodology called “Light touch” which is built on the terms

that increased control does not imply less uncertainty and higher

income. This method is moreover used in the APM where requisition of

some control is made which leads to greater income. (Augustine, 2008)

Creativity and work that meets agile principles occurs when the very

sensitive balance between interest and structure is reached. Optimal

balance occurs when work is satisfyingly interesting due to non-

predictableness and enough structured to not collapse. Principles of

APM ensuring optimal workflow and outcome when managing a

project as following: Guiding Vision; Organic Teams; Simple Rules;

Open Information; Light Touch. Furthermore it’s not excluding the risk

of teams working in wrong direction when constructing new ways of

team interactions. Unintended outcomes are possibly to result in both

positive and negative consequences due to non-linear behaviors’.

Adaptive processes to leadership are carried out to imbue desired

results through observations and assessment of practices. To enable the

imputation of the results it requires the project manager to have an

overseeing understanding of the entire project and its mutual

interactions and being susceptible for learning and adaptability.

(Augustine, 2008)




2018-08-20

13

2.2 Risk management

2.2.1 Risk framework

There are many risk management standards to choose from. These

standards illustrate and explain the process of managing risks. It is

important to note that the authors of this study use the word risk

management as an umbrella term; it contains the identification,

assessment, and classification of risks. These frameworks take different

approaches. Some are suitable for certain things; others are more

applicable in other general areas. (Hopkin, 2010)

There are several risk management standards, one of which are ISO

31000.

Figure 2: The process of risk management according to ISO 31000.

(Hopkin, 2010)




2018-08-20

14

The process begins with establishing the context of the risk process. This

continues with the risk assessment part of the process, which contains

identifying, analyzing and evaluating the risk. The next part is

generating recommendations on risk treatment. In parallel with these

processes, there is communication and consultation with relevant

stakeholders that are experts in the context (i.e. the process at risk). All

the same while monitoring and reviewing every step of the way. (ISO,

2009)

The principles and framework of the ISO 31000 standard is illustrated

below.

Figure 3: A more in-depth illustration of the ISO 31000 standard. (ISO,

2009)




2018-08-20

15

2.2.1.1 Project risk management

There is no clear approach to risk management within agile projects.

Many project stakeholders feel that working purely with an agile

method is sufficient when it comes to handling risks. (Moran, 2012)

Some experts are of the opinion that a more individual approach to risk

management is suitable in agile projects. For example, an agile project

risk management methodology would allocate the ownership of risks to

individuals, rather than having one risk manager who handles all of the

risks accordingly. The traditional form of risk manager becomes to

facilitate attention to risk management and work together with

individual risk owners in order to manage risks. This risk management

role can be assumed by, e.g., the Scrum Master or the Project

Leader/Manager.

(Moran, 2012)

Risk management applied to traditional projects often look at risks

upfront and identifies issues that may affect the project as a whole. As

traditional projects are very rigid (function is fixed, while cost and time

are variables), this approach towards risk management suffices. This is

not the case for agile projects. Agile, as previously mentioned, considers

time and cost to be fixed, while the function (of the product) is a

variable. This makes the traditional risk management less suitable for

agile projects. To solve this, agile risk management needs to look at

potential risks throughout the lifecycle. Although this may seem like a

major difference, it does not make general risk management less suitable

to be used in agile projects. It is important to note that even though

many projects state that they are purely Agile, this is rarely the case.

There is no consensus regarding risk management in relation to agile

methodologies. (Moran, 2012)




2018-08-20

16

Project risks have three fundamental risks in them, all three tied to the

failure of keeping or achieving the project parameters, i.e.: staying

within cost or completion date parameter, or to achieve quality and/or

functionality requirements. These risks are, suggested, to be influenced

by several different associations, such as: the size and scope of the

project, technological know-how of team members and the complexity

of the projects structure. (Merna, 2010)

These general risks are portrayed in the table 1 below.

Table 1: General project risks. (Merna, 2010)

Too many project members

Complex administration

Complex management

Lack of communication amongst project participants

Inaccurate forecasts

Late deliveries

Equipment/technology issues and break-down

2.2.2 Risk identification

Every aspect in an organization contains some proportion of risk.

Independent of the process, risks are inherent and should be analyzed

and classified in relation to cost and benefit. It is of interest when to

balance risk management and when not to. Managing too much will

cost a lot, managing too little will cost a lot. (Newton, 2015)

ISO 31000 defines “risk” as the “effect of uncertainty in objectives”. Risk

management (RM) is the “coordination activity of directing and

controlling an organization with regard to risk”. There are many

different definitions, but the fundamental essence of every definition is

more or less the same. (ISO, 2009)




2018-08-20

17

Risks are often categorized and classified with the help of RM. This is

done in order to handle these risks and work with them. These risks can

be classified into three different types (Hopkin, 2010):

• Hazard risks

• Control risks

• Opportunity risks

Hazard risks are risks that can only have a negative consequence. Risks

such as these are considered insurable risks, i.e. the only way to avoid

these risks is by applying mechanisms that, if the risk is apparent, there

will be a buffer in order to minimize the impact of consequence.

Risk hazards are closely related to issues within health and safety work,

damage to property, and consequence of defective products. This

category of risk is disruptive to the workings of an organization.

Examples in relation to IT, these risks can be hacking attempts,

destruction and interruption of software development, or malicious

software. (Hopkin, 2010)

Another type of risk is Control risk. These are the risks which are

apparent when the outcome of the situation has given rise to

uncertainty. These are often associated with the project methodology.

Control risks are risks that may affect the fixed parameters of a process.

Examples of these fixed parameters (which are often tied to resources)

are time and cost. With respect to this uncertainty, a risk manager

should strive to control these risk rather than insure against them (too

costly), or avoid them completely (infeasible). (Hopkin, 2010)

The third category of risks is the risks that organizations strive to take

because of their positive outcome. These are the Opportunity risks.

The category of Opportunity risk is defined of having an expected

positive outcome (in a more or less state of degree). Examples of this risk

could be the purchase of new software for a more effective value

producing process. (Hopkin, 2010)




2018-08-20

18

How the categorization of these risks occurs, depends on the risk

appetite of the organization.

These three risk categories can be broken down into two different

subtypes. The authors of this paper have decided to categorize these

risks into the two following sub-types

• Inherent risks

• Artificial risks

Inherent (fundamental) risks are risks that are inherent in every aspect of a

specific process. These risks are equal in equal processes.

Artificial (overall) risks are risks that are artificially perceived, i.e. risks

that are not inherent in a process but rather are a result of actions by

stakeholders. These risks are unique for equal processes.

If we are to properly work with these risks, we need to collect the correct

information in order to be able to categorize these risks into one of three

possible risk categories. This is done by describing these risks in a Risk

description. (Hopkin, 2010)

Table 2: Table of risk description (Hopkin, 2010).

Name of risk

Statement of risk (scope, details of possible events and

relations)

Details of risk classification and potential impact

Internal and external stakeholders

Risk tolerance for the risks

Consequence of risks

Control mechanism for these risks




2018-08-20

19

2.2.2.1 Risk assessment and techniques

In order to classify risks, they first need to be assessed, categorized and

analyzed. There are several different methodologies and models that can

be used - either individually or in tandem. We will present available

models that are available in order to document recorded risks from

gathered data. There are several techniques in place in order to collect

data regarding risks. Respective data collection methodology has pros

and cons, related to their techniques. The study will convey the most

relevant data collection methods in relation to risks in this sub-chapter.

2.2.2.2 Questionnaires and checklists

This risk data collection methodology uses structured questionnaires

and checklists in order to collect data regarding risks. This method helps

the risk manager identify existing risks. (Merna, 2010) The risk manager

can identify hazards, risks or control failures, with the help of data

collected from relevant stakeholders. This method is at its strongest

when applied as a data check (i.e. combined with another data collection

method) in order to confirm collected data. (Valis & Koucky, 2009)

2.2.2.3 Workshops and brainstorming

Workshops and brainstorming combined consists of a free-flowing

conversation among peers with knowledge regarding the risk

containing process. These peers discuss and identify potential problem

areas that are associated with risks. Criteria regarding probabilities,

consequences, and options for diminishing (or completely removing)

likelihood or impact, are generated. (Valis & Koucky, 2009; Hopkin,

2010; Merna, 2010)




2018-08-20

20

2.2.3 Risk analysis

Table 3: Qualitative and quantitative character of different risk data

collection methodologies.

Qualitative Quantitative

Questionnaires and checklists

Workshops and brainstorming

Flowcharts and dependency analysis

Delphi technique

SWOT and PESTLE analysis

Monte Carlo simulations

Markov analysis

HAZOP and FMEA

Delphi technique

2.2.3.1 Delphi technique

The Delphi technique consists of brainstorming or interviewing relevant

stakeholders (in this case, experts). This is especially useful in order to

obtain intricate information regarding risks, such as in cases where one

desires to reach a group consensus on risk classification. This procedure

is done by obtaining a reliable consensus from stakeholders who are

very invested and knowledgeable within the area of interested. This

technique is used both in quantitative cases and qualitative cases; in

order to generate actual tangible risks, stakeholders are interviewed - in

the same way, in order to generate likelihoods (i.e. probabilities of a

certain risk occurring), stakeholders (experts) are interviewed, and

hence these numerical probabilities are generated.

(Valis & Koucky, 2009; Hopkin, 2010; Merna, 2010)




2018-08-20

21

2.2.3.2 Flowcharts and dependency analysis

This methodology makes use of flowcharts in order to identify

dependencies between sub-systems. With the help of this analysis, the

risk manager can identify which areas are interdependent. (Hopkin,

2010)

2.2.3.3 HAZOP and FMEA approaches

HAZOP (Hazard and Operability) and FMEA (Failure Modes and

Effects Analysis) is a combined approach that is very similar to each

other. These methodologies identify how processes can cause failure in

their designed system. It is of interest to identify potential failures, how

these failures may affect the whole process (or system), the mechanism

of failure, and how to avoid or mitigate the negative effects of a failure.

(Valis & Koucky, 2009; Hopkin, 2010; Merna, 2010)

2.2.3.4 Monte-Carlo simulation

A Monte-Carlo simulation consists of randomly generating numbers

within and interval and entering it into a defined function. The results of

the function is summed up, thereon taking the mean of the total sum

and extrapolating the most likely probability of a certain event

happening. It is of quantitative character. (Merna, 2010)

2.2.3.5 Risk register

The purpose of a risk register is to record and document significant risks

that have been identified. It serves as a record in order to control

processes that are ongoing. Additionally, it is used to control certain

risks. There is no fixed format for how a risk register looks or what it

contains, so an arbitrary model is chosen. (ISO, 2015; Schwalbe, 2009;

Merna, 2010)




2018-08-20

22

Illustration 1: Illustration of a risk register. (Merna, 2010)

This risk register contains a unique ID for a specific risk, its risk author,

the registered date, which organizational category the risk may affect,

the description of the risk, its probability and impact, response category,

its current binary status (active/inactive), and relevant stakeholders.

(ISO, 2015; Schwalbe, 2009; Merna, 2010)

2.2.3.6 Risk score card

Risk score cards are done in order to summarize the main risks within a

process. Most score cards have the same main parameters, while the

secondary parameters are different. The vertical matrix consists of the

main parameters, which is the same for every different framework. The

horizontal matrix contains the sub-parameters, which is different

depending upon the selected framework. There are several different

frameworks. (Hopkin, 2010):

2.2.3.10 Risk matrix

A risk matrix consists of a two dimensional diagram where the x-axis

denotes likelihood of risk, and the y-axis consisting of the magnitude of

impact of said risk. The risks are plotted on the diagram accordingly to

its x- and y-variables. Figure 4 below denotes an exemplified illustration

of this.

A risk matrix helps the risk manager to visualize the relation of different

risks to its likelihood and impact. In this case, likelihood denotes the




2018-08-20

23

likeliness of a certain risk to occur, while the impact denotes the impact

to the organization (or project) - i.e. not the magnitude itself. (Merna,

2010; Hopkin, 2010; Wendestam, 2008)

Figure 4: Example of risk matrix.

With the help of this risk matrix in figure 4, we can categorically decide

upon a suitable action to take in order to mitigate said risk. This

categorization is explained and illustrated in the next sub-chapter: Risk

appetite.

2.2.3.12 Risk appetite

Risk appetite denotes an individuals or a group's tendency towards risk

behavior and decisions, e.g. if one should take a decision that has a less

expected value than not. This concept fits into the RM Strategy and long

term RM. (Hopkin, 2010) It is a concept strongly tied to the financial

services sector, where banks develop a risk appetite matrix (or diagram)

and bases its decisions upon this appetite “framework”. The Institute of

Risk Management defines risk appetite as “the amount and type of risk

that an organization is willing to take in order to meet their strategic




2018-08-20

24

objectives”. Her Majesty’s Treasury (governmental body in the UK)

recommends having a clear risk appetite laid out in order to sufficiently

assist managers in taking the correct risk decisions, which will improve

the organizations’ performance. (HM Treasury, 2006)

The illustrative matrix contains three different colors denoting the risk

zone; green being comfortable, yellow being cautious, and red being

concerned. The wording on the zones is decided upon by the authors of

this paper. These three zones differ between individuals because of the

difference in perception of the same risks. Figure 5 displays how such a

risk appetite matrix might be portrayed.

Figure 5: Example of a risk appetite matrix (low risk appetite)

(RIMS, 2012)




2018-08-20

25

Figure 6: Example of a risk appetite matrix (high risk appetite) (RIMS,

2012)

2.2.4 Risk evaluation

2.2.4.1 SWOT and PESTLE analysis

SWOT (Strength, Weakness, Opportunity and Threat) and PESTLE

(Political, Economic, Social, Technological, Legal, and Environmental)

analysis are very similar in their approach. This methodology looks at

specific categories and analyses information through a categorical

approach. It is argued that respective method contains vital categories

that the relevant stakeholders must have in mind when working with

risks. (Hopkin, 2010)

2.2.4.2 BS 31100

British Standard 31100 looks at five different sub-parameters, these

being: Strategic, Programmer, Project, Financial, and Operational. In

contrast to SWOT/PESTLE, the sub-parameters are different, therefore

suitable for different research areas. (Hopkin, 2010)




2018-08-20

26

Table 4: Example of a risk score card for British Standard 31100.

(Hopkin, 2010)

Strategic Project Financial Operational

Description

Internal/external risk

Quantifiable

Measurement (performance

indicator)

Performance gap

Control mechanisms

2.2.4.3 4T Risk mitigation

4T refers to the four different courses of actions that can be taken in

order to mitigate risks “Transfer, Terminate, Tolerate and Treat”.

(Hopkin, 2010) The categorization is done by first identifying, followed

by classifying the risks. After plotting it on a diagram (such as the one

found in figure 4), we can categorize the action. Depending on which

quadrant the risk exists in, a consequent action can be decided upon.

(Merna, 2010) This categorization is illustrated in both table 5 and figure

4.




2018-08-20

27

Table 5: Risk matrix categorization with respect to the 4T’s of hazard

management. (Hopkin, 2010)

Risk Probability of

occurrence

Probability of

consequence

Response

Risk

1

Medium High Treat

Risk

2

Medium Medium Treat

Risk

3

High Medium Terminate

Risk

4

Low High Transfer

In order to understand the thought process behind the nominal values

on occurrence and consequence in table 5, these need to be

operationalized.

Table 6: Operationalizing nominal values for table 5.

Nominal

value

Occurrence Adverse effects magnitude

LOW Once a year Low impact upon daily

operations

MEDIUM Once every financial

quarter

Medium impact upon daily

operations

HIGH Once every month Strong impact upon daily

operations




2018-08-20

28

The impact in table 6 denotes financial losses (most likely loss of

liquidity, trust towards customer, and time loss).

The risks contained in table 5 are the risks gathered from the risk

identification process. The operationalization of nominal values in table

6 is done with respect to stakeholders (i.e. what the relevant

stakeholders perceive as low/medium/high occurrence respectively

adverse effects of impact).

2.3 Previous research

The problem of integrating RM (Risk Management) practices with agile

methodologies is well known, and has been attempted previously. The

research done regarding the area looks at the application itself and not

whether RM is applicable or not, and what the general risks are in the

agile methodology. It is this gap in knowledge that this study attempts

to fill. (Ribeiro, 2009) As RM inherently requires relevant key

individuals to hold intricate knowledge of specific projects, it is

required, of them, to know the general risks (in order to go into more

detailed risks), to be able to apply RM successfully. (Elbana & Sarker,

2016; Urvashi & Suprika, 2016)

A study conducted at the Princess Sumaya University of Technology

(Albadarneh, 2015) attempts to research risk management within agile

development projects. The paper discusses RM activities in agile

software development, and shows how RM process can help within the

usage of agile methodologies. The aim of the study is identification of

the outcome when combining agile practices with the RM process and

further finds solutions for solving difficulties during the combination.

Basic software risk management strategies and inherent risk processes

in agile methods is studied to build the theoretical reference frame. In

conclusion, the study finds that SCRUM offers a wider range of RM

application, and the outcome to be improvement of communication and

awareness within the team. Addressing of risks within SCRUM incubate




2018-08-20

29

more analyzing details inherent to the capacity of risk management.

Further on the practices of SCRUM provides a wider range of

combining with practices of risk management than eXtreme

Programming.

One previous study attempts to apply an Agile Risk Management

Process in multiple projects environments in order to focus on the

organizational environment in relation to project risks. The method used

is combined with mPRIME process (similar to a PDCA cycle). The

conclusion of the study shows that successful implementation mitigated

the main theorized risks that could have a negative impact on the

projects. The issues of the study, identified by the authors of the study,

were that the used methodology did not hinder the occurrence of

residual risk (risks that remain after a response to a risk has been taken).

They argue that this variable can impact larger projects. The difficulties

with the case study that was conducted were the lack of knowledge and

experience by the risk manager and project leaders in relation to the

environmental and project risks identification. The study concludes that

the success of the projects are directly related to the risk management

that was applied, and that one of the main reasons why some projects

could not finish in time was because of a lack of risk management

application upon the projects. (Ribeiro, 2009)




2018-08-20

30

3 Method This chapter represents the methodology that will be used in order to fulfil the

aim of the study and answer the research questions.

This study makes use of a qualitative approach. The reason for this choice

is because of the exploratory approach to the problem of general risks

within agile maintenance and development projects, as well as the

difference in perception of risks by stakeholders within this project. As

there has not been a study into this field of research previously, an

exploratory approach is the most suitable.

3.1 Data collection

This study mainly looks at the agile methodology Scrum and the inherent

risks within this methodology, stakeholders in the form of the Scrum

master, project leader, and developers are the people with data that is

required to answer the questions in this study. Collection of data from

these stakeholders can be done in several ways. The approaches that have

been chosen for this study contains of the Delphi technique (elaborated

upon in the previous chapter) and interviews (semi-structured

interviews). The main argument, when it comes to the chosen data

collection method, is because the data is inherently subjective (e.g. the

subjective perception of the impact or occurrence of a risk), therefore it is

of importance to take into account that the wider the data collection is - in

regards to this certain case -, the more reliable the data becomes.

3.2 Design

The data collected in the first phase will consist of interviews done with

relevant key stakeholders – in this case, the project leader, the SCRUM

master, and two system developers. The interviews will be transcribed

and coded, in order to identify the relevant general risks within agile

projects.

The second phase consists of individual interviews with the same key

stakeholders. The collected data will be portrayed in risk score cards and

risk appetite matrices. The risk score cards will assist the researchers in

acquiring a simplified version of an illustrative figure which will be used




2018-08-20

31

in the results chapter. The risk appetite matrices will act as a visual aid in

order to give an easier overview of the individual appetite for risks.

The third phase consists of using a Delphi approach with the same

stakeholders. This Delphi technique will be applied as a panel, where

both the four different and same key stakeholders are interviewed

together and asked the same questions as in the second phase. The panel

will be asked to discuss the individual risks and decide upon its

likelihood and magnitude of impact. The collected data will be portrayed

as a summary of how the respective risks are classified, as well as a

unified appetite matrix. This third phase is conducted in order to see if

and/or how the unified appetite matrix differs from the individual

appetite matrices.

Figure 7: The three phases of data collection in this study.

Three phases is used for the reason of simplifying the paper and its data

collection process throughout the risk identification, as well as making it

easier for the reader to distinguish between collected data and portrayed

data, as some readers may find only the general risks interesting while

others may find one of the two other phases interesting. First phase

generates general risks, second phase classifies these general risks and

generates a risk appetite matrix, the third phase classifies the same risks

but within a group and generates a group appetite matrix. When these

three phases are concluded, the Results chapter is generated followed by

the Analysis chapter. Lastly, concluded in the Conclusions chapter.

Throughout the whole study, theme follows the ISO 31000 standard.

Which means the process is followed as such: context of the research is

established, risk identification occurs (results chapter), followed by the

risk analysis (analysis chapter), and is concluded in the Conclusions

chapter. The Risk Treatment (or Risk Evaluation) process is not




2018-08-20

32

included, as this is outside the scope of the study. The study follows a

clear theme of following this specific process throughout the paper.

3.2.1 Risk Management methodology

One inherent problematic area within the integration of RM into Agile

processes is that there are no consensus on frameworks (in reality, there

are not that many RM frameworks that has the sole purpose to be used

with Agile). (Edzreena, 2018) Having the knowledge of this fact, the only

frameworks which are available are those identified within the

“traditional” RM school.1

Choosing a suitable framework is up to the risk manager; depending on

which parameters and variables containing risks should be looked at. In

the case of this study will be looking at an IT consulting firm that is using

SCRUM to manage a large IT system. The chosen framework is ISO 31000.

ISO 31000 is used by organizations in order to manage risks. The standard

also has a sub-parameter where it includes risks tied to projects, while

other frameworks do not. Even though ISO 31000 was not made with

agile projects in mind, it is a suitable framework in assisting risk

managers in handling risks. This choice can be seen as arbitrary, as there

are no specific frameworks made specifically applicable with agile

methodologies.

3.2.1.1 Establishing the context

Establishing the context is important in order for the risk manager to

understand what kind of risks and within what area it is of interest to look

at. This context generation is done by data collection with the relevant

stakeholders.

The context, in our case, is pre-established in the form of several

research questions.

1 Traditional in the sense that it is widely accepted within other risk managers and

literature




2018-08-20

33

3.2.2 Risk identification

The risk identification will be done by interviewing these key individuals.

Their answers will be collected in a risk register. The reasoning for

choosing a risk register is because of the amount of answers generated

during these interviews, as a larger amount of answers (and identified

general risks), makes the summarizing of these risks easier and more

understandable with the help of a risk register.

3.2.2.1 Risk assessment and techniques

In order to classify risks, they first need to be assessed, categorized and

analyzed. There are several different methodologies and models that can

be used - either individually or in tandem. We will present available

models that are available in order to document recorded risks from

gathered data. There are several techniques in place in order to collect

data regarding risks. Respective data collection methodology has pros

and cons, related to their techniques. The study will convey the most

relevant data collection methods in relation to risks in this sub-chapter.

3.2.2.2 Questionnaires and checklists

This risk data collection methodology uses structured questionnaires

and checklists in order to collect data regarding risks. This method helps

the risk manager identify existing risks. (Merna, 2010) The risk manager

can identify hazards, risks or control failures, with the help of data

collected from relevant stakeholders. This method is at its strongest

when applied as a data check (i.e. combined with another data collection

method) in order to confirm collected data. (Valis & Koucky, 2009)

3.2.2.3 Workshops and brainstorming

Workshops and brainstorming combined consists of a free-flowing

conversation among peers with knowledge regarding the risk




2018-08-20

34

containing process. These peers discuss and identify potential problem

areas that are associated with risks. Criteria regarding probabilities,

consequences, and options for diminishing (or completely removing)

likelihood or impact, are generated. (Valis & Koucky, 2009; Hopkin,

2010; Merna, 2010)

3.2.2.3 Interviewees

Four people have been determined of interest for the data collection.

These being the four most relevant parties within this IT project: the

SCRUM master, the project manager, two system developers (front- and

back-end). The testing of the system (for Q&A reasons) are done by both

system developers and the SCRUM master.

3.2.3 Risk analysis

After data has been collected from relevant stakeholders and presented in

both a risk score card and a risk register, it will be portrayed in a risk

matrix. This is done in order to relate respective risks magnitude of

impact to their occurrence probability, and to give an easy-to-understand

illustration of the impact-to-consequence relation. The risk matrix will be

laid over a risk appetite matrix. The next step will consist of collecting

data on how respective stakeholder perceives the individual risks; i.e. if

they are within a comfort, cautious, or concerned zone. This will help the

authors of this study to identify the subjective risk perception between

different stakeholders within an organization.

3.2.4 Risk evaluation

The risk evaluation is a process that this study will not go too much into

depth into. The reason for this is because the risk evaluation process

does not contain much data collection, but purely confirming collected

data. This will be done together with said stakeholders as well as in the

analysis and discussion chapter of this study.




2018-08-20

35

3.2.5 Communication and consultation

The communication and consultation process is ongoing at all times

parallel to every part of the frameworks process. (ISO 31000)

Communication between risk managers and project stakeholders is

always ongoing, during consultation, information collecting, confirming

assessments and identifications. This is done because of the wide

knowledge the stakeholders have regarding their processes. The risk

manager is mostly focused on tying the knowledge of the experts to a

risk process. This process is especially important in this study, as it is

vital for the authors to gather the correct information and then confirm

the collected and summarized information and data in the study. This

communication and consultation mainly consists of the said relevant

key stakeholders within the case study (in order to clarify or confirm

collected data and the perception of it).

3.3 Qualitative methodology

A qualitative methodology has been chosen in order to answer the

research questions. The combination of RM and agile methodologies is a

relatively new area that has not had much insight into it. It is of interest

to enlighten the research community as well as stakeholders such as other

risk managers, project leaders, and scrum masters, regarding the general

risks within agile methodologies such as SCRUM. In other words, an

explorative approach has been taken - as it is a relatively non-researched

area (which is evident from previous research).

3.3.1 Semi-structured interviews

The purpose of the interviews is to get a general view of what certain

stakeholders perceive regarding risks. In order to collect such data, the

semi-structured interview form has been chosen. This implies that the

researchers of this study begins the interview with a couple of

predetermined questions, and continues the interview with not

predetermined questions. This is done in order to generate the correct

area of discussion at genesis. Semi-structured interviews will assist the

researchers in collecting data that are generated through the interviewee

in a subjective manner. In other words, the data collected will be




2018-08-20

36

summarized and analyzed, and assist in creating an individual risk

appetite matrix. This risk appetite matrix is highly individual. With these

facts in mind, a semi-structured interview form is most suiting;

generating the area of interview (risk management) with the first

questions, and later moving on to spontaneous questions in order to gain

more in depth data.

The reason for semi-structured interviews is because of the fact that the

interviewees might not make themselves comprehendible because of

terminologies etc, and thus needs to be asked further questions in order

to generate a more generalizable answer.

3.3.2 Coding of interviews

The coding of interviews will be done by respective individually listening

to recordings of the interviews and summarizing different identified risk

areas. After this is done, both researchers will, together, go through their

individually identified risks areas and determine - by looking at

keywords (e.g. “problem”, “risk”, “issue”, or any other keyword tied to

such words) - if the certain risk is relevant and actually a risk (e.g. “work

is hard” is equivalent to “there is too much [work] to do”)

After this is done, the researchers will put up their respective keywords

up against another and discuss which risks are mentioned and in

contradiction, thus only needs to be brought up once and which risks are

brought up by two or more different stakeholders. This coding of data

collected from interviews will be presented in an appendix.

3.3.3 Delphi technique

The Delphi technique is interesting for data generation because of the

flexible approach it takes for different stakeholders to have a discussion

regarding different risks and their importance. The Delphi technique will

be the last data collection method used in this research, and will be done

in order to compare previous risk appetite to the current appetite (i.e. the




2018-08-20

37

“current appetite” being the risk appetite after discussions with their

peers).

The Delphi technique will be applied in a form of a panel.

3.3.4 Risk illustration tool

Because of the qualitative approach to this study, a fitting illustrative

framework has been used in order to convey collected data and therefore

been made easier to visualize for the reader. The used tool consists of

EXCEL, where VBA coding has been used. The tool contributes to the

majority of the tables and illustrative figures within this study.

3.3.5 Likelihood & Consequence

In order to do this study and answer the research questions, one needs to

dwell more in-depth into the two fundamental terminologies within risk

management: Likelihood and Consequence.

These two terminologies need to be quantified. 2 They need to be

operationalized if one is to relay and illustrate the collected data in

matrices. The operationalization of these two variables has been chosen

to be, Likelihood and Order of Impact.

Likelihood - The subjective perception by a stakeholder that event X will

occur with the probability of P.

Order of Impact - The degree of impact which the events X will affect the

organization.

In order to illustrate the placement of both these variables, we need

nominal output functions. These are illustrated in table 7. It is important

to note that these nominal values, in relation to their individual risks, are

data gathered from interviewed stakeholders. This data is inherently

subjective, which the authors will map in a risk appetite matrix.

Furthermore, in order to make it easier and illustrative in a plot, the

chosen numerical values for both variables were decided to an interval of

0 to 10.

2 In a qualitative sense.




2018-08-20

38

Table 7: Operationalizing of numerical values in relation to likelihood

and impact.

Numerical

interval

Likelihood Impact

0-3 Low probability to occur

under one fiscal year. Low impact upon

individual projects during a

fiscal year.

4-6 Medium probability to

occur under one fiscal

year.

Medium impact upon


fiscal year.

7-10 High probability to

occur under one fiscal

year.

High impact upon


fiscal year.

3.3.6 Risk appetite matrix

In order to create a risk appetite matrix, the interviewees were asked to

declare which zone they felt the respective risks belonged to (comfortable,

cautious, or concerned). With the help of this information, the

approximation of the color zones were decided and portrayed in the

respective individual risk appetite matrices. These color zones were

decided to be as green, yellow and red. Green denotes a comfortable zone,

where the interviewee perceives that the risks are at, as it is not a large

threat to the project. Yellow denotes a cautious zone, which is defined as

to be a medium threat to the project and may affect it in a negative way.

Red denotes a cautious zone, implying that if it would occur, it would

have a detrimental effect on the project – not necessarily that it may have

to be shut down, but that it would generate a lot of problems. These zones

do not have a tangible definition outside how the interviewee wishes to

act against the certain risk. For example, risks determined to be in the red

zone (concerned) would imply that the interviewee wishes to work

actively or insure against these kinds of risks. Green would imply that the




2018-08-20

39

interviewee is not worried about the risk and can take a course of action

when and if it eventually arrives.

These zones are determined by the interviewee in the second and third

phase of the data collection method. These color zones are determined by

asking the interviewee to decide the nominal impact of a risk and its

likelihood, as well as which comfort zone said risk would be perceived at.

When the data points of risk (R1 through R22) have been plotted, a visual

Green-Yellow-Red zone is created in order to assist the reader in reading

out and understanding the risk appetite matrix. The reason why this

methodology has been chosen is because it makes it easier for the authors

of this study to generate a risk appetite matrix, as without it, there would

be no way to determine whether a interviewee is risk aversive, neutral, or

aggressive.

3.4 Case study

In order to generate the general risks within the SCRUM methodology

and the subjective perception of risk by stakeholders, it is of interest to

conduct a case study at an organization that conducts work with SCRUM.

The case study is conducted at an IT consulting firm in Sundsvall,

Sweden. Initially the data collected will help answer the questions

regarding the general risks within SCRUM, the following data collections

will portray, with the help of interviews, different stakeholders

perception of risk. When this has been done, the same stakeholders will

be involved in a Delphi panel and in tandem create a unified risk appetite

matrix. When this has been done, the same stakeholders will then be

interviewed once again, individually, in order to see if and how their risk

appetites have changed. In order to limit the large amount of potential

data that may be collected, only a chosen few stakeholders will be chosen.

The most relevant ones being the SCRUM master, product owner, and a

system developer.




2018-08-20

40

3.5 Social and ethical principles

Due to the research being a case study applied to an organization it is of

great importance to be consistent and keeping the ethical considerations

in mind throughout the study. Initially the organization within the case

study will be informed that all data collection will be secured and only

used for research purposes. Furthermore, any data about employees or

other sensitive information will be stored safely and anonymous unless

otherwise specified. Respondents’ identity will be secured and their

rights will be told, a form about information and consent will make it

possible. The respondents admit their participation after signing this

form. Each interview begins with the basics that respondent has

opportunity to quit their participation and a query for accepting

recording of the interview. When the results of the interviews are

concluded the respondents will have the opportunity to investigate them

in order to provide insight of what their answers will be used for. Finally

the used language will exclude all types of victimization and

discrimination and to show respect to all involved parts.

3.6 Validity and reliability

In order to strive for high validity and reliability it is important to ensure

that the authors measures what is relevant in the context of the study and

in a reliable manner. Validity is ensured throughout using the intended

measurement tools at the right time, while reliability implies how

trustworthy the tool is. Therefore a high reliability does not imply a high

validity itself but a high validity requires a high reliability. (Eliasson,

2006) In purpose to vouch an arbitrary validity within this study,

interviewed employees within the business case will sustain informed

about schedule and definitions of concepts. This in accordance to what

seems to be the indispensable for the study due to tight schedule and

unforeseen meetings may affect presence and answers to interviews.

Beyond interviews within the management, variation of included product

developers may also affect the result due to subjective influences. Product

developers within the business case have a few years of experience and

are incorporated to the business and well conjunct to the others.

When performing interviews to identify risks within the chain of agile

processes, four respondents tied to the ongoing project were chosen. This




2018-08-20

41

seems arbitrary due to the business case having about 15 employees

including management, working with the project. Employees has

different roles and purpose to the project; Product Owner; Scrum master;

Product developers, and others. An information and consent form were

used to increase the respondents understanding and insight about the

purpose and aim of the study.

The methods risk register and risk appetite was used in the study due to

the distance and complement of these methods seems important. Another

way of identifying risks and their relevance could yield a different result,

on the other hand they could not make considerations about the aspects

of distance between the both methods.

Interviewing only four people in a project of 15 people may imply a hit to

both validity and reliability. It is important to note that the most relevant

stakeholders are of interest here and how their risk perception is differing

from each other. It is not of interest (nor does it add any particular added

value) to interview and collect data from the, e.g., economic advisors or

auditor within the project.




2018-08-20

42

4 Results In this chapter the results of the study are presented. Firstly the three phases of

interviews which fulfil the data collection and secondly the methodologies of risk

management applied to the identified risks inherent to the SCRUM process of the

case study.

Risk identification

4.1 First phase

The data collected points out several different risk areas mainly tied the

failure to collect the ultimate objective of the project. The different

stakeholders mention different risks tied to their respective areas of

workspace

Person A, whom has the SCRUM master role (See Annex A), mentions

the incapability of not collecting all the requirements needed for a

sprint, this implies that the project group would need to make

assumptions on functions etc. Said person also mentions other risk areas

such as developers and tester’s lack of competence, loss of competent

workers, unclear end goal, vaguely commented code, loss of expert

consultation, and the Snowball effect when changing around in the

code.

Person B which has a system developer role conveyed the difficulty of

estimating time for user cases and stories because of the unclear end

goal. Other mentioned risks were: the lack of customer involvement in

the SCRUM process, potentially bad team chemistry, contracts and

agreements not being fully done, issues with prioritization (e.g.

indefinite or unrealistic priorities), customers lack of ability to identify

general functions (categorized into “good-to-have” and “must-have”

functions), and manual testing of systems. Person B also brings up risks

that person A has brought up, such as lack of requirements (vague end

goal), and the Snowball effect mentioned at the end in the previous

paragraph.




2018-08-20

43

Person C which has a system developer role, identifies risks such as

contradictory requirements from customer, bad estimation of cost and

time (which affects time efficiency), and security risks tied to treatment

of sensitive personal information (tied to PUL/GDPR laws), lack of risk

analysis, identification and management, as well as risk awareness. This

person also identified risks which the previous persons have brought

up, specifically: change of requirements (cause-effect from external

stakeholders); external incidents or events that affects the planning;

unclear, vague, or non-existent end goals.

Person D which has a product owner role, identified risks in the form of

misunderstanding customer requirements, and issues related to

misunderstanding events in the testing phase. Other risks are the

assumption by developers on how the acquis communautaire is to be

applied in certain areas, lack of testing, lack of personnel.

The risks identified by phase one interviews are portrayed in table 8.




2018-08-20

44

Table 8: Risks identified within phase one

Risk No.

Risk description

R1

R2

R3

R4

R5

R6

R7

R8

R9

R10

R11

R12

R13

R14

R15

R16

R17

R18

R19

R20

R21

R22

Not collecting all requirements from customers.

Lack of knowledge.

Bugs in the system.

Unclear and vague end goals.

Relying on expert consultation Loss

of expert (acquis) consultation.

Time estimation problems.

Customer not sufficiently involved in the development process.

Agreements and contracts not realized.

Prioritization issues (stories and functions).

Customers lack of identification of necessary functions.

Manual testing.

Parallel ongoing projects.

Contradictory demands from the customer.

Handling of personal information.

Lack of risk identification, analysis, management, and awareness.

Misunderstanding customer demands.

Misunderstanding testing events.

Assumptions of acquis and functions.

Lack of testing.

Lack of competent personal.

Too many or too few developers.




2018-08-20

45

4.2 Second phase

4.2.1 Risk register

By presenting the compilation of various risks collected during phase 1

within a risk register. Each respondent could respond with their

perception of each risk and risk register questionnaires could be carried

out to set values on likelihood of the risk and which impact it would

yield if the risk itself occurs. Additionally, after receiving values on

likelihood and impact per risk and individual, respondents were asked

how comfortable they would be in case of exposure of each risk;

Comfortable; Cautious; Concerned. Understanding the likelihood and

impact of each identified risk yields a deeper knowledge on the

frequency of occurrence and the projects vulnerability of the risk.

4.2.2 Interview answers

Table 9: Answers from the individual interviews with the four

stakeholders.




2018-08-20

46

The colours in table 9 denotes the risk perception of the individuals

derived from the interviews. Red denotes the highest level of risk,

yellow denotes a mediocre risk perception, while green denotes a

comfortable approach to the risk. Together with these answers, we can

create four individual risk appetite matrices.

4.2.5 Risk classification and appetite

In order to classify the risks and to understand the risk appetite of the

respondents, risks identified per individual were mapped onto a risk

appetite matrix with likelihood as x-axis and impact as y-axis. With a

scale from 0-10 were 0 is no likelihood and 10 is very high likelihood on

the x-axis. On the y-axis 0 is no impact and 10 is very high impact, were

non-impact does not affect the project and very high impact will affect

the project in such a high grade that it could be necessary to quit the

project. Risks are given a number 1-22 in following order by the table 11.

The appetite matrix helps us in understanding how different

stakeholders perceive risks. Some stakeholders are more risk aggressive

towards higher likelihoods than impacts, and vise-versa. The way to

read this fact out is by looking at the color coding of either the Y-axis or

the X-axis. If we look at figure 8, the risk appetite matrix for person A,

the green zone is around f_impact(6.5) and f_likelihood(8.5), which

gives us a certain visual area that makes it easier to compare this

persons’ risk appetite compared to its counterparts

Person A

Person A’s risk appetite matrix was created by plotting out the data

points unto a program and giving these data points the color of the

majority of that point (i.e. R20, R7, R16 are all the same point but since

yellow is the majority of these three risks’ zones, yellow is the chosen

color). The approximation of mapped zones can be likened to linear

regression, where we try to approximate lines (instead we do it with a

zone).




2018-08-20

47

Figure 8: Risk appetite matrix for person A.

Person B

Person B is considered to be risk aversive, as the universe of risk is quite

large while the comfortable zone (green area) is relatively smaller than

its counterparts.

Figure 9: Risk appetite matrix for person B.

R1

R2

R3R4

R5

R6

R7

R8 R9R10

R11R12

R13

R14

R15

R16 R17

R18R19

R20R21

R22

0

1

2

3

4

5

6

7

8

9

10

0 2 4 6 8 10

IMP

AC

T

LIKELIHOOD

Person A

R1

R2

R3R4

R5

R6R7

R8

R9

R10

R11R12

R13

R14

R15

R16

R17R18

R19

R20

R21

R22

0

1

2

3

4

5

6

7

8

9

10

0 2 4 6 8 10

IMP

AC

T

LIKELIHOOD

Person B




2018-08-20

48

Person C

The universe of risk (the red zone) for person C is relatively small

compared to the three other risk matrices, and hence could be

considered to be risk aggressive (more prone to take higher risks). This

can be seen by looking at the largeness of the green area, where a risk

such as R12 is considered comfortable, and R6 cautious.

Figure 10: Risk appetite matrix for person C.

Person D

Person D has a larger appetite for risk in relation to impact compared to

likelihood (a risk with 0/10 [likelihood/impact] is considered

comfortable while a risk with 7/0 is considered comfortable as well). As

person D has a very angled appetite matrix, it may be a bit hard to

correctly classify whether it is risk neutral or aggressive, as there is no

clear framework upon deciding this. In this case, we will consider it

somewhat risk aggressive.

R1

R2 R3R4

R5

R6

R7R8R9

R10

R11 R12R13

R14

R15

R16

R17

R18

R19R20

R21

R22

0

1

2

3

4

5

6

7

8

9

10

0 1 2 3 4 5 6 7 8 9 10

IMP

AC

T

LIKELIHOOD

Person C




2018-08-20

49

Figure 11: Risk appetite matrix for person D.

These four individuals have differing risk appetite matrices. From tables

Person A to Person D, we can see that person D has the largest universe

of risk, followed by person B, person C and lastly person A. In unclear

cases of which individual has a larger or smaller universe matrix,

Euclidean methods can be used in order to calculate and evaluate the

area of risk universe.

Data points plotted out on each illustration shows the classification of

individual risks by respective stakeholder. It is apparent that risks are

very diversely classified. In two of these four cases, both have the same

job role at the firm (person A and person B).

Another interesting point found within these risk matrices is how the

angles are different between all of them, which we will discuss in the

analysis chapter.

R1

R2

R3

R4

R5R6

R7

R8 R9

R10

R11

R12

R13

R14

R15

R16R17

R18

R19

R20

R21

R22

0

1

2

3

4

5

6

7

8

9

10

0 2 4 6 8 10

IMP

AC

T

LIKELIHOOD

Person D




2018-08-20

50

4.3 Third phase

The third phase of the interviews was conducted with all four

previously interviewed individuals in group. These individuals were

instructed to discuss among themselves regarding respective risks and

determine a consensus on how to classify them. The collected data is

summarized in appendix C, and is visualized in table 12.

Table 12: Delphi panel results.




2018-08-20

51

Table 13 shows the group’s result of the perception of the risks

identified in table 8. The group reached a consensus that 8 risks were

considered cautious while 14 were deemed comfortable. It was noted

during the interview that one of the interviewees had more to say than

the other three (namely person D, the project leader), while person B

had the least to say. Naturally, as person D is the project leader, he holds

most of the responsibility and demands more respect in relation to the

three other individuals. Person A (the first system developer) was the

second most vocal individual and had differing opinions on some of the

risk classifications compared to the rest of the group. Person B (second

system developer) and C (the SCRUM master) mostly followed the

project leaders lead and classifications on their probabilities and

magnitudes of impact.

Another interesting point was brought up by the interviewees; the

realization that their risk perceptions before and after the interviews had

changed after an internal discussions (i.e. the conducted interview) had

occurred.




2018-08-20

52

Table 13: Comparison of group answers to individual answers.




2018-08-20

53

Figure 12: The risk appetite of the four individuals together.

Figure 12 represents the risk appetite that was created with the help of

the data collected from the collaborated interviews that occurred with

the four different key stakeholders simultaneously.




2018-08-20

54

5 Analysis In this chapter an analysis of the study’s results will be carried out to create a

deeper understanding of the studied area.

Risk identification

Merna (2010) conveys the general project risks in table 1. Looking at the

risks generated in this study, we can see an apparent relation to the more

general risks portrayed in table 1. Comparing the risks analyzed by

Merna (2010) and the ones generated by this study implies relationships,

see figure 13. In other words, the general risks brought up by Merna

(2010) can be broken down into further general risks, such as the ones

generated in this study. This means it is important for the RM practitioner

to be able to identify till what point the general risks are sufficiently

broken down enough to be able to classify them and get a desirable

outcome.

Figure 13: Comparison of risks




2018-08-20

55

In figure 13, the color markings denotes the connection between the data

collected from this study together with the theoretical general risks of

agile project management (above table is the theoretical risks). Clearly,

arriving at general risks when looking at one project can be quite

difficult, as one project is a negligible subset of a larger potential dataset.

Therefore, we decided to categorize the risks we have collected in this

study into different “color” categories tied to the theoretical general

risks. Figure 13 shows that most of the general risks are relevant,

although it would be preferable to categorize some of the theoretical

risks together in order to make drawing parallels easier.

Risk Analysis

5.1 Comparison of risk appetite matrices

We can clearly see apparent deviations between the stakeholders’

perception of likelihoods and magnitudes of impact. Although these are

very subjective in nature (as the answers were not based on empirical

observations but rather on “feeling”), the risk appetite were somewhat

similar between them see figure 14. The outlier in Person A- Person D

risk appetite matrices in is only apparent in Person C, where the

universe of risk is far smaller than the rest. Another interesting

observation is the fact that the angle of attack of the Green-Yellow-Red

differs between every individual stakeholders risk appetite. The fact that

Person C is an outlier has no apparent reason besides the likely fact that

this stakeholder was considered to have the least ownership of risks (see

Annex B). The most risk aversive is the stakeholder with the largest

universe of risk (i.e. the red area) - this is apparent in Person D, who

concurrently holds the least amount of ownership in regard to different

risks. The ownership of risks were established during the interviews

during phase two and three. One could easily deduce why Person D (the

project leader) would easily be the most risk aversive of the chosen

interviewees; the responsibility falls on the project leader more often

than not, thus implicating him or her in potential backlash in case of

project failure. Another interesting point in this scenario is the complete

different impact and likelihood (I&L) classification of these four. The

two most similar ones (although similar in layout; not particularly

similar in specific risk classification) are one of the system developers




2018-08-20

56

and the SCRUM master (Person B and Person C). This does not seem to

be a cause-and-effect relationship, as there are no apparent reasons for

the appearance of similarity between these two. Although, the

discrepancy between these two (same argument can be made in relation

between all of these) is the lack of communication in regard to risk.

The two system developers Person A and Person B are very different in

their classifications. For example, R15 for Person A was classified as “not

particularly likely to occur, but if it did occur it would have an

enormous impact”, while Person B classified it as “not particularly likely

to occur, and if it did occur it would not have a particularly strong

impact”. I.e. the perception of some risks were inverse of each other.

Meanwhile, some risks were categorized as being in their cautious

(yellow) zone but in reality being classified as being in their comfortable

(green) zone. An example of this is Person B-R15, Person A-R15, Person

A-R10, etc. This is likely because of a lack of knowledge regarding RM

practices neither the project group nor the IT firm do not currently apply

any RM solutions.

The risk appetite for the unified appetite matrix would imply, according

to the risk appetite theory that they would need to follow this matrix

when taking decisions. These decisions would be of aggressive

character, as the appetite matrix shows a tendency towards risk

aggressiveness. This tendency is determined by the apparent lack of a

red zone in figure 14 (group interview), where the risk universe is

minimal. When it comes to working on individual assignments, the

individuals are far more risk aversive than in a group. In other words,

they’re less likely to take a high-risk-high-reward approach in their

individual work.




2018-08-20

57

Figure 14: Overview risk appetite matrices for individual and group

interviews.




2018-08-20

58

5.1.1 Group interview

The four individuals, when interviewed together, had an easier and

more approachable way of classifying the general risks. As the group

started discussing the different risks, many different and variegated

approaches and views were taken. One difference between the group

appetite and the individual appetite was that no risks were considered

to be in their concerned (red) zone. This is interesting, as every

individual previously had decided upon at least one concerned risk.

This is likely due to two facts: the group discussed respective risk and

reached a consensus that their highest impact and likely risk was not to

be considered cautious as there were no risk that was likely or

impacting enough (realization); or – another explanation – is that the

group gained more courage because the burden of the risk would shift

from the individual to the group instead (wolf pack mentality).

Naturally, every wolf pack has an alpha, which was apparent during the

interview – where the project leader was the one to get the group to start

discussing, as well as lead the group, and to be the first one to give his

input on probability, impact, and perceived comfort zone.

The fact that the project leader was such a vocal and strong presence

may have skewed the results towards his risk appetite matrix, but

looking at Person D and the group interview-matrix, this does not

necessarily seem to be the cased. Even if this is the case, the project

leader was influenced anyway and thus the difference in the risk

appetite matrices. If this is not the case, the risk appetite matrix is the

groups’ true perception of the general risks.

The group appetite matrix clearly shows a relatively large appetite for

risk – the risk universe is close to non-existent. As the stakeholders did

not reach a consensus nor discuss it particularly in depth, the risk

universe was estimated to be very small. The suggestion that the risk

universe would be smaller is amplified by the fact of wolf pack

mentality that seems to be apparent.




2018-08-20

59

5.1.2 Difference in classification

Table 13 shows us something interesting that was not to be expected. We

see that even though the perception of the individual and group comfort

zones does not differ significantly.

Table 13: Comparison of group answers to individual answers.

The only fully misclassified risks are R2, R3, R16, and R15. This shows a

tendency that the group was more benign towards the general risks than

they would be individually. The reason for this may be the same two

previous reasons where it was argued that it was either because of

realization or pack mentality.




2018-08-20

60

Risk Evaluation

5.1.3 Evaluation

During the interviews, the interviewees often questioned the name

classification of the several specific risks. For example for the risk “not

enough testing”, the answer was often that their answer would change

depending on the circumstances and on the project. It was important to

denote, by the researchers, that the general articulation of the risks were

more important than going into detail on specifics of these risks, as the

aim of the study is not to research how a IT firm specifically categorizes

and perceives risks in one specific project but rather give a

comprehensive and exploratory view of subjective risk perception

within IT projects.

In the case study, the firm has explained that their RM practices are

integrating into the sprint process. The approach is neither standardized

nor comprehensive, as is clearly shown in the fact that even though it

implicates that the overlying appetite matrix does not agree upon the

individual risk matrices. This means that the group is not aware in

relation to the respective individual, thus a discrepancy occurs and the

perception of risk (whether in group or individual) does nothing to add

value to the organization unless properly standardized. New attempts

have been made by the firm to standardize this process but further

attempts have been neglected. Integrating RM into the SCRUM process

is understandable a hard process, as it can take a long time – which is

contradictory to the fluent and lean process of agile methodologies.

As mentioned by Ribeiro (2009), some methodologies do not identify

residual risks. It is apparent that none of the risks general risks

conveyed in this study identifies any residual risks. The likely

explanation to this is the lack of knowledge regarding risk identification

by the key individuals within the studied project, and that the used

methodology did not make it possibly. The earlier explanation is

amplified by the fact that the lack of RM practices is apparent when

comparing their individual risk appetite matrices to the unified appetite




2018-08-20

61

matrix. The latter explanation is backed up by Ribeiro (2009) which

arguments that identifying residual risk is dependent on the used RM

methodology.

Elbana & Sarker (2016) and Urvashi & Suprika (2016) mention the

requirement for the key individuals to hold expert knowledge of the

systems and processes in order to assist in a proper RM process. This is

understandable, as this study that was conducted had issues in regard to

the differing perception of risks by the stakeholders, which in turn made

it harder in understanding the differing perception and which

perception could be the most likely and valuable for a RM practice. In

this case, the differing perception is the most likely explanation rather

than the lack of knowledge.




2018-08-20

62

6 Conclusions In this chapter the research questions are once again relayed and answered in

relation to the collected data within the results chapter and the analyzed data

from the analysis chapter.

• What are the general risks within agile maintenance projects?

Naivety and short-sightedness is a potential issue within agile projects.

Most of the general risks this study has found are of short-term character.

The lack of RM practices is explained by this short-term thinking, where

the project leader is focused completely on the ongoing project. If the

project leader is not expected to think forward, the individuals working

under him cannot be expected to do so. Thus, the short-term risks are far

more prevalent than long-term, and as such, they are easier to work with

and are put under more scrutiny rather than long-term risks.

This study compared theoretical risks within agile projects with practical

risks. We found that the theoretical risks do overlay with the practical

risks. For example, the general risks by Merna (2010), in figure 13, the

theoretical risks are rather categorized than specifically conveyed such as

in the lower part of figure 13. The general risks are rather to be categorized

into different subcategories such as complexity of tasks and processes, as

well as lack of synergy between dynamic entities within projects – in our

case: the project members.

• In which ways is the used risk management methodology in this

study suitable respectively unsuitable for agile maintenance

projects?

With the applied RM methodology, the main idea was to create more

knowledge about RM within the case study project. The second phase of

interviews – where the individual risk appetite matrices were produced –

gave interesting answers. Compared to the group risk appetite matrix,

which changed dramatically to the individual ones, the goal to create

more knowledge about RM succeeded.

It is understandable that using time-consuming RM practices such as

these are not particularly interesting, as the main goal of SCRUM is to

work according to Agile, which implies reducing wastefulness (Muda).

Combining RM and SCRUM can be an issue. This study proves that there




2018-08-20

63

are discrepancies between individual thought and group thought, and

since SCRUM puts emphasis on working in teams, it is a necessity to for

the group as a whole to inform themselves internally regarding potential

risks and what their perception of respective risks are. A first approach

would be not to apply full on RM immediately (such as large decision

trees with quantitative character), but rather a more standardized

approach to it before each sprint; e.g. similar to the Delphi panel used in

the third phase of data collection within this study.

• How does the perception of the general risks within agile

projects differ between key individuals?

The interviewed individuals had three different roles: system developer,

SCRUM master, project leader. Two different system developers were

interviewed in each of the three phases. Between the four individuals,

the difference in risk perception was different. This is likely attributed to

the fact that no standardized methodology to inform the group about

risks has been established. The role with the largest risk universe (i.e. the

most risk aversive individual) is the one that owned the most risks.

Between all four interviewed individuals, the risk owner was in strong

majority attributed to the project leader. Meanwhile, the least attributed

risk owner was the SCRUM master, concurrently the most risk

aggressive.

Future research

The issues found in this study have helped in understanding what

research fields would be of interest in further studies. Finding a suitable

tangible RM model to apply on agile methodologies without

compromising the fundamentals of Agility, would be of interest. This

study also found discrepancy between individual risk appetites and the

unified groups risk appetite; what is interesting is if this is caused by

realization or because of a wolf pack mentality (as both previously

mentioned).




2018-08-20

64

References

Albadarneh, A et al. Risk Management in Agile Software Development a

Comparative Study. Princess Sumaya University for Technology. 2015.

[www]:

http://ieeexplore.ieee.org.proxybib.miun.se/stamp/stamp.jsp?arnumber=

7360573

Agileforall. Scrum Framework. 2015. [www]: http://agileforall.com/wp-

content/uploads/2015/12/Scrum_Framework_lg-e1456358707313.jpg

Augustine, S. Managing agile projects. Upper Saddle River (N.J.):

Prentice Hall. 2008.

Cervone, H. Understanding agile project management methods using Scrum.

International digital library perspectives. 2011. p.18-22.

Edrzeena, O. Agile risk management using software agents. Journal of

Ambient Intelligence and Humanized Computing. 2018. p.823-841.

Elbana, A & Sarker, S. The Risks of Agile Software Development. 2016.

Eliasson, A. Kvantitativ metod från början. Lund. 2006. Studentlitteratur.

Haas, K. B. The blending of traditional and agile project management. PM

World Today. 2007.

Hastie, S. Standish Group 2015 Chaos Report. Standish Group. 2015.

[www]:

https://www.infoq.com/articles/standish-chaos-2015

HM Treasury. Managing your risk appetite a practitioners guide. 2006. [www]:

https://assets.publishing.service.gov.uk/government/uploads/sys

tem/uploads/attachment_data/file/191520/Managing_your_risk_appetite

_a_practitioners_guide.pdf

Highsmith, J. A. Agile software development eco systems. Addison-Wesley

Professional. 2002.

http://ieeexplore.ieee.org.proxybib.miun.se/stamp/stamp.jsp?arnumber=7360573



http://agileforall.com/wp-content/uploads/2015/12/Scrum_Framework_lg-e1456358707313.jpg












https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/191520/Managing_your_risk_appetite_a_practitioners_guide.pdf








2018-08-20

65

Hopkin, P. Fundamentals of Risk Management. 2010. United states: Kogan

Page Limited.

ISO. Quality Management Systems: 9001:2015. 2015. [www]:

https://www.iso.org/standard/62085.html

ISO. Risk Management: 31010:2009. 2009. [www]:

https://www.iso.org/iso-31000-risk-management.html

Ribeiro, L et al. Implementation of an Agile Risk Management Process in

Multiple Projects Environments. PICMET. 2009. [www]:

https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5262002

Maruping, L et al. A control theory perspective on agile methodology use and

changing user requirements. Information Systems Research. 2009. p.377–

399.

Merna, T. Corporate Risk Management. Wiley, John & Sons, Incorporated.

2010.

Misra, S et al. Identifying some important success factors in adopting agile

software development practices. 2009. Journal of System and Software.

p.1869– 1890.

Moran, A. Risk Management in Agile Projects. Agile alliance. 2012. [www]:

https://www.agilealliance.org/wp-content/uploads/2016/01/Agile-

RiskManagement-Agile-2012.pdf

Newton, P. Managing Project Risk: Project Skills. 2015. [www]:

http://www.free-management-ebooks.com/dldebk-pdf/fme-

projectrisk.pdf

Project Smart. The Standish Group Report Chaos. 2014. [www]:

https://www.projectsmart.co.uk/white-papers/chaos-report.pdf

Radburn, A. An introduction to AGILE Project Management. 2014. [www]:











https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5262002

https://www.agilealliance.org/wp-content/uploads/2016/01/Agile-Risk-Management-Agile-2012.pdf












http://www.free-management-ebooks.com/dldebk-pdf/fme-project-risk.pdf


















https://www.branded3.com/blog/introduction-agile-project-management/




2018-08-20

66

https://www.branded3.com/blog/introduction-agile-projectmanagement/

Ribeiro, L et al. Exploring agile methods in construction small and medium

enterprises: a case study. Emerald Group Publishing Limited. 2008.

[www]: https://www-emeraldinsight-

com.proxybib.miun.se/doi/full/10.1108/17410391011019750

RIMS. Exploring risk appetite and risk tolerance. 2012. [www]:

https://www.rims.org/resources/ERM/Documents/RIMS_Exploring_Ris

k_Appetite_Risk_Tolerance_0412.pdf

Schmidt, C. Agile Software Development Teams – The impact of Agile

Development on Team Performance. 2016. [www]:

https://link.springer.com/content/pdf/10.1007%2F978-3-319-26057-0.pdf

Schwaber, K. Sutherland, J. The definitive guide to Scrum: The rules of the

game. 2013. [www]:

http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

Schwalbe, K. Information Technology PROJECT MANAGEMENT. Edition

7. Cengage learning. 2009.

Smith, G & Pichler, R. Agile Risks/Agile Rewards. Sd magazine. 2018. p.50-

53. [www]: http://romanpichler.com/articles/pdfs/AgileRiskManagement.pdf

Suprika, V & Urvashi, R & Metti2face. A risk management framework for

distributed agile projects. 2016.

Valis, D & Koucky, M. Selected Overview of Risk Assessment Techniques.

2009.

Walczak, W & Kuchta, D. Risks Characteristic of Agile Project Management

Methodologies and Responses to Them. 2013. Institute of Organization and

Management; Wroclaw University of Technology.

Wendestam, L. Ta kontroll över riskprojekten!: PRM-metoden - ett praktiskt

arbetssätt för riskhantering i projekt. 2008. Stockholm; Ekerlid.









https://www-emeraldinsight-com.proxybib.miun.se/doi/full/10.1108/17410391011019750






https://www.rims.org/resources/ERM/Documents/RIMS_Exploring_Risk_Appetite_Risk_Tolerance_0412.pdf




















http://romanpichler.com/articles/pdfs/AgileRiskManagement.pdf




2018-08-20

67

Annex A: Case study interviews Person A R:

I1: Vilken omfattning har du på organisationen?

R: Ja vi är ju IT-konsulter, jag sysslar mest med systemutveckling.

I1: Vad ingår i ditt dagliga arbete?

R: Det är mest utveckling men även förvaltningsrelaterat, kan vara

register i databaser och lite blandat. Jag sysslar mest med allt från back

end till front end.

Vilka risker förekommer under en sprint?

R: Inom en sprint, ja alltså åtagandet vi har är ju ganska

verksamhetsorienterat, vi utgår ju från regler och sånt som

myndigheterna bestämmer angående pension då. Men jag vet inte om

jag skulle kunna säga att det är en risk för sprint då men om dom ändrar

någonting som vi redan har gjort så blir det ju en risk så. Hela tiden kan

komma in och göra verksamhetskrav liksom vi måste anpassa oss efter

och ska genomsyras i hela systemet. Men just per sprint, skulle väl vara

om vi missar nånting, vi har ju krav för utvecklingen, det skulle väl vara

om man missar någonting så att inte de uppfylls då.

I2: Och när du menar missa nånting, menar du missa en funktion som

kommer med i stories

R: Det kan ju vara, det kan vara att jag har missuppfattat ett krav eller

test. Vi har sån här överlämning från utveckling till test om man

glömmer någon detalj där men då är det ju bra att man har ett stabilt

krav, annars känns det som att dom delarna är svåra att missa om man

gör rätt ifrån början. Det tycker jag att sprintarna bidrar med liksom

såhär kort och konsist; Det här ska vi göra den här sprinten.

I1: Jag tänkte överlag om nånting skulle missas i kravspecifikationen där

ni lägger ut tasks i sprinten och så är det någonting som skulle missas,

kan det vara en risk att ni frångår kravspecifikationen?

R: Om möjligheten finns menar du? Ja fast ja, det är klart möjligheten

finns men det känns inte som att vi har ju, vi tilldelar alla stories och




2018-08-20

68

tasks så vi inte ska missa något. Vi vet ju redan i början av sprinten att

det här ska jag göra och så kan vi ju ha en kontinuerlig dialog hela tiden.

I2: Hur ofta får ni krav från kunden eller produktägaren som ändras

under utvecklingen, tex någon funktion?

R: Det är svårt att säga hur ofta, generellt.

I2: Men det sker?

R: Ja det sker ju att dom har tagit något beslut eftersom att det är en

verksamhetsorienterad bransch då, så vi får ju anpassa oss ifrån den

andra delen.

I1: Om man tänker sig inom tidsramen för en kravspec, tycker du att det

är risk att man inte hinner klar, att man haft för stort åtagande i en

kravspec och att tidsestimeringen är för liten?

R: Jo det är ju alltid en risk och det är ju svårt att estimera när det är så

stora delar, när man ska bygga ett system så kan man ju uppskatta fel

liksom. Det förekommer ju även i vårt projekt då.

I2: Vad skulle du säga är de mest förekommande riskerna som uppstår i

din omfattning som systemutvecklare?

R: Det är väl när det kommer ett nytt krav eller nånting som gör att vi

måste ändra något som påverkar redan befintliga grejor, kan ju vara, då

är det ju en risk att se till att allting fungerar som det ska fortfarande

samtidigt som den nya funktionaliteten då. Det är ju lite... Det är viktigt

att man har koll på alla delar funkar fortfarande.

I2: Och de nya kraven som kommer från myndigheten gällande

regelverk och sånt där, i och med att ni är systemutvecklare så kanske

man inte kan förvänta sig att ni ska kunna dom fullt ut. Får ni någon

konsultering kring det liksom, att det här är det ramverket och så här ser

det ut och det är så det funkar eller får ni anta det själva?

R: Vi har ju pensionsexperter här som sitter och jobbar med kundservice

så att det finns alltid någon att fråga. Jag har ju inte så mycket erfarenhet

av pension just innan men kan ju alltid fråga någon om det är någon

regel eller nånting jag är osäker på. Sen är det ju många som har jobbat i

projektet länge så det finns alltid expertis att gå på.




2018-08-20

69

I2: Känner du att det finns några risker knytna till den

kunskapspecialiserade pension som ni systemutvecklare har? Ni har ju

expertis men finns det några risker knytna till det området?`

R: Ja det gör det ju, det är typ om jag, säg att jag antar att det funkar så

här men så funkar det inte så. Men jag brukar alltid eliminera den risken

genom att gå till någon som vet. Även om jag känner här är nog jag

väldigt säker så kan man ju fråga. Vi har ju ett öppet landskap, även om

jag inte är involverad i de diskussioner de har bredvid mig så snappar

man ju upp grejor liksom, man hör ju och lär sig så också. Öppen dialog

är väldigt bra.

I2: Sen har vi ju ytterigare problemområden, ni har ju servrarna för

självaste för kunden här på plats, visst är det så? Servrar och sånt här?

R: Ja alltså våra testmiljöer är ju här men vi har outsourcat vår

produktionsmiljö till...

I2: Håller du också på med testing?

R: Nej

I2: Men om vi går in på IT-säkerhetsrelaterade risker, det har ju blivit ett

återkommande problem hos företagen. Vilka säkerhetsrelaterade risker

gentemot det ser du?

R: Det tror jag kan vara en fördel i och med att nu har vi ju antlitat

externa, så de är ju experter på det viset. De har ju serviceavtal och läser

man deras policy så känns det ju som att det är ganska bra angående

det. Jag tror att ska man både systemutveckla och drifta så tror jag att

det kan vara större chans att man missar någonting, man kan ju inte dra

på sig för mycket.

I2: Men det är också en risk att man kan ta på sig för mycket?

R: Ja jag tror det.

I1: Ja det är ju också ett problem om man ska både drifta och underhålla

ett system, det kräver mycket.

I2: Skulle du kunna påstå att outsourcing har både positiva och negativa

aspekter? De negativa aspekterna skulle kunna vara om det finns risker

med att outsourca det.

R: Ja det gör det ju också, och sen är det ju liksom att man, då kan ju inte

vi kontrollera om något har gått fel hos dom, då måste vi kontakta dom




2018-08-20

70

och det är liksom, det är ju liksom mellansteg då. Men jag tycker att

fördelarna väger upp nackdelarna.

I2: Vad skulle du säga är de största anledningarna till att det sker

förseningar i att man ska utveckla en viss funktion?

R: Generellt, det skulle jag nog säga att något är felestimerat gällande tid

då, man får göra någon form av uppskattning och gå igenom vad som

ska göras och så här lång tid tror vi att det tar. Men det är ju svårt att

veta exakt när det kommer till kritan. Kanske man märker andra grejer

som att det är viktigt med lagkrav också, så får man ju minimera de

upptäckter man gör i efterhand.

I1: Vi har identifierat tidigare i mötet med er Scrum master att sen ni

blev klar med det stora projektet så vet ni inte riktigt mot vilken mål ni

jobbar med kunden, kunden vet inte riktigt vad dom vill ha för nånting,

upplever du som systemutvecklare att det är ett problem, nu när du

sitter och utvecklar saker, att de inte riktigt är målmedvetna om vad

dom vill ha?

R: Ja alltså jag kände, när vi höll på med det här stora projektet som

Scrummastern pratar om, då var det ju mer tydliga mål, då visste man

alltid att det här ska jag göra, nu är det lite mer otydligt. Det är klart att

det känner jag av ibland, att ibland vet jag inte riktigt vilken riktning jag

ska gå när jag utvecklar men vi kravar ju så gott vi kan utifrån det vi vet.

Det har varit lite nu, nya verksamhetskrav då så dom vet inte riktigt, då

kan inte vi utveckla till fullo heller så att det har varit lite mycket nu så

här att preppa, då det här händer då kanske det ska se ut så här.

I1: Om man tänker sig utifrån ett subjektivt perspektiv, om vad man

tycker själv, och vad kunden egentligen vill ha. Man vet inte riktigt vad

kunden vill ha men att man utvecklar själv för vad ni tror att kunden vill

ha i ett senare skede, men sen när ni släpper systemet och kunden vill

ändra på det. Har det då varit en risk att kunden inte är målmedveten,

att ni får omarbeta saker och ting som kostar tid och resurser?

Jag upplever inte det, men det är också en fördel med agil utveckling, vi

har ju kontinuerlig kontakt med kunden. Genom att ha en sån

utvecklingsmetod så minimerar man dom riskerna. Istället för att dom




2018-08-20

71

kommer 5 månader senare och säger att vi vill ha så här. Jag känner att

det är ganska bra att göra så, involvera kunden i det mesta.

I2: Kommer du på några andra generella risker förutom de du tagit

upp?

R: Ja det kanske är en risk att jobba agilt att man inte har ett långsiktigt

mål utan man jobbar och är så fokuserad på sprintarna för sig att man

tänker att den är sprinten ska göra såhär och inte ser den röda tråden.

Jag tror att vi har ju en utvecklingsboard och en förvaltningsboard, vi

försöker ju hålla samman mellan dom då och jag känner ju att man får ju

det ändå. Jag tror att det kan vara en risk i just agil utveckling då.

I2: I och med att ni hålle på med både systemutveckling och förvaltning,

det är en komplexite i sig. Ser du det som ett riskområde i och med att

man tar båda begreppen och jobbar med dom parallellt?

R: Både ja och nej, alltså förvaltning då kan vi ju upptäcka nya behov

och då kan vi ju utveckla efter det då . Men samtidigt som jag sa tidigare

så får man ju se till att det inte förstör något i den gamla koden. Det

måste ju alltid finnas nå röd tråd i vad som ska göras och förstå liksom

komplexiteten i just pension då.

I2: Självaste risker relaterat till buggar och buggar som dyker upp efter

testingen, existerar dom?

R: Ja det förekommer, sen lite som jag pratade innan om att det är

komplext och att det är en bugg som inte fanns i testing kan uppstå i och

med att vi lägger till en annan funktionalitet och det är därför det är

viktigt att vi har bra krav, vi tänker hela vägen liksom att det här kanske

påverkar det där, vi måste kontrollera att det faktiskt inte förfaller det

här. Det tycker jag att man löser med en bra teknisk arkitektur och bra

krav.

I2: Hur många systemutvecklare är ni här som håller på med den djupa

programmeringen?

R: Ja vi har ju, det mest tunga är ju back end och beräkningar för

pension och jag har suttit mest med front end men även lite med back

end, jag tycker att det är bra att man får lite grepp om hela systemet.

Men vi är en utvecklare som blir pappaledig nästa vecka och då




2018-08-20

72

kommer det bli jag som jobbar fulltid. Sen har vi ju två till som jobbar,

dom kan ju systemutveckling men dom jobbar med förvaltning.

I2: Tycker du att ni är för många eller för få systemutvecklare?

R: Just nu är vi lagom, jag tror att när den här killen går så kommer vi

behöva en till. Vi har grejor att göra, det tror jag också är en trygghet i

sig att veta att det finns saker som ska göras.

I2: Skulle du kunna påstå att det finns risker i och med att man är för

många eller för få?

R: Ja det gör det utan tvekan, det är ju beroende på, från projekt till

projekt, hur många det behövs. Det kan ju vara för många och det är ju

inte heller bra, kanske är värre om man är för få, jag vet inte.

I2: Skickligheten av programmerare, lite bakgrund till det är att jag har

snackat med några som outsourcat sina koder till indien, och de är

väldigt otydliga, dom ser risker med det. Men nu är ju ni

svenskutbildade kodare, är det bättre att ha det så i och med att det blir

lättare att förstå koder och så här, ser du några risker relaterat till det?

R: Ja jag tror att det är bra att det är samma personer som skriver

koderna hela tiden för då fårman så här överblick på ett annat sätt, tex

den här modulen ska vi outsourca till indien. Då kanske dom missar att

den här ska funka till det här också. Finns väl fördelar och nackdelar

tror jag, men jag tror att just här är det bra att vi kör alla på samma plats

liksom.

Person B PS: Vilka risker ser du existera i en sprint?

A: Under sprinten bara eller utanför också?

SY: Specifikt under sprinten.

A: Att man inte får in alla kvar. Att vi saknar någonting och att det inte

täcker in allt. Fel som inte upptäcks kan vara en risk. PS: Då tänker du

på kravspecifikationen specifikt eller? Ni som systemutvecklare tar del

av kraven att dom inte upptäcks eller att någonting missas?

A: Att man inte har tillräckligt med kunskap kanske.




2018-08-20

73

SY: Vem är det som har brist på kunskapen som blir en risk (riskägare)?

A: Det kan vara både utvecklare och dom som testar. Hela kedjan, så att

säga.

PS: Vilka risker skulle du klassificera som generella risker respektive

specifika risker?

SY: Du var inne lite på dom specifika riskerna. Hur ser dom generella

riskerna?

A: Generellt? Att kompetens försvinner, kanske. Vi är väldigt

kompetensberoende. Bugrelaterade risker finns det också; att saker blir

fel.

SY: Hur ser du på dom potentiella säkerhetsrelaterade riskerna? A:

Vi har inte direkt någon direkt bevakning på det. Vi har ett internt

system för det. Vi skulle behöva fokusera mer på det, känner jag. SY:

Hur ställer du dig till outsourcingen av säkerhetsrelaterade

komponenter?

A: Jag tycker det är bra. Sen kan man ju tycka om dom aktörerna är bra

eller dåliga. Vi slipper ju hålla på med det själva, då det kostar mer

resurser, kostnader och kräver bredare kunskap. Sen har vi ju

infrastrukturen för det.

PS: Ni hade nyligen ett stort omfattande projekt tidigare. Nu vet kunden

inte vad dom vill ha, i slutmål och krav, systemstöden till systemet som

levereras. Kunden verkar inte vara riktigt medveten om vad dom vill ha

och kan inte sätta mål och krav; ni vet inte vad ni jobbar emot. Tror du

att det är vilseledande nu; att ni sätter många timmar på utveckling som

inte genererar något: A: Till viss del kanske.

PS: Hur påverkas du av att inte ha tydliga slutmål som

systemutvecklare?

A: Då får vi bestämma själva lite hur vi ska göra och hur det sker. PS:

Så ni uppskattar om hur saker skall göras och måste ändra på dom

sen igen?

A: Ja, till viss del; man tar det iterativt. Kunden har ett förslag om hur

det skall fungera sen sker det en lagförändring om hur det skall fungera.

SY: Har du någon uppfattning om risker knutna till att kunden kommer

med ett krav, ni levererar det kravet och kunden påpekar att det inte är

det dom vill ha. Missuppfattning mellan kunden och

systemutvecklingsteamet.




2018-08-20

74

A: Jag upplever inte att det sker. Dock är det tredjepartsleverantörer

som är inblandade och då kan det bli otydligheter. Om vi ska integrera

mot en bank till exempel.

SY: Du ser det som en risk också? Om en yttre intressent – en tredje part

– är delaktig också?

A: Ja, det kan bli stökigt då.

SY: Ser du någon risk knutet till komplexiteten av ditt arbete?

A: Det är om någon inte förstår koden t.ex., det är en risk.

SY: Vad är utfallet av en sån risk? T.ex. om projektledaren inte förstår

koden och det som sker i den.

A: Kanske att något blir felestimerat. Det blir lite långsiktiga effekter; att

man behöver bygga om längre fram.

PS: Kommunikation. Om ni har kravspecifikation om att något behöver

ändras i systemet. Som att en ändring påverkar en annan del i systemet.

Att det slår på andra ställen?

A: Det händer absolut, det är en risk. En ändring kan slå på ett helt

annat ställe.

SY: Ser du någon risk kring systemutvecklarnas konsultation av experter

om specifika områden som ni behandlar inom kundens ramar? A: Jo, då

är man personberoende. Och då är systemutvecklaren beroende av

konsultation i vissa fall så som regelverk, matematiska formler specifikt

för beräkningar och så vidare. Vi använder standardformuleringen i

formler och sånt, så det går ju ta in en annan om vi tappar en expert

inom det område.

PS: Om flera är inne och håller på med systemet då? Flera kockar i

köket.

A: Ja, då är ju inte heller så jättebra.

PS: Hur upplever du tidsestimeringen med kravspecifikationerna? Är

det ofta ni överskrider den?

A: Jag har dålig uppfattning om det. Det finns ingen riktig

tidsestimering.

SY: Hur många systemutvecklare här skulle klara av göra det du gör?

A: Kanske en.

SY: Hur tror du projektet skulle påverkas av att tappa en sådan

nyckelperson?

A: Det skulle påverkas men inte stanna upp helt. Det skulle vara bra om

det fanns fler systemutvecklare, på grund av uppsägning eller sjukdom,




2018-08-20

75

så att projektet inte stannar upp helt eller tappar effektivitet. Jämnare

kompetensspridning.

SY: Skulle projektet flyta på bättre?

A: Kanske. Det kan ju vara en utmaning om man är fler.

Person C SY: Vilken omfattning har du på företaget?

Q1: Min roll? Jag är SCRUM master för åtagandet, jag är också ansvarig

testledare för åtagandet. Jag är ansvarig för alla tester och för dom som

testar, så att det görs på rätt sätt enligt våran metod. Jag testar även

systemet. [<Denna del kanske skall tas bort, då den intervjuade enkelt

kan identifieras?>]

SY: Vilken metod arbetsmetod är det ni tillämpar?

Q1: Vi arbetar med SCRUM.

SY: Vad ingår i ditt dagliga arbete?

Q1: Som SCRUM master ingår det att hålla i dagliga möten på femton

minuter, stämmer av vad man ska göra under dagen och hur det går –

om det finns några hinder. Det är jag som styr mötet och ser till att det

inte styr över och att gruppen inte fokuserar på för många detaljer. Sen

håller jag även i andra möten, kallar till återblickar, demon av det vi har

gjort under sprinten och sprintplaneringarna. Vi har även

sprintplaneringar och försprintplaneringar som jag håller i och kallar in.

I själva åtagandet jobbar jag med test och planerar upp tester av

systemet och jobbar med krav om systemet och dokumenterar. [<Denna

del kanske skall tas bort, då den intervjuade enkelt kan identifieras?>]

SY: Vilka risker upplever du inom den generella arbetsformen av

SCRUM. Det övergripande genom hela processen, så kan det uppstå

diverse olika risker i relation till tiden, till exempel att man inte hinner

med tiden. Hur upplever du det?

Q1: I SCRUM, då ska man under en sprint jobba i 3 veckors sprintar. Då

tar man på sig att man klarar av det man tagit på sig under sprinten. Det

som kan vara en risk i det är att det kan vara svårt att estimera tiden för

varje story; hur lång tid den tar. Så att man kanske inte hinner med det

man åtagit sig, då har man misslyckats enligt SCRUM. För oss nu, vi har

inte kunden riktigt med oss – kunden har inte en riktig syn in på dessa

sprintar – det är mer för teamet för att veta hur vi ska hinna med det vi

åtagit oss. Men jag kan tänka mig att om man har en kund som är

väldigt involverad och förväntar sig att man levererar, så kan det bli




2018-08-20

76

problem om det är svårt att estimera hur lång tid varje del tar. Sen

jobbar man nära teamet, om teamet inte kan arbeta tillsammans blir det

också problem. Det spelar stor roll vilka som är i teamet.

SY: Gällande tidsestimeringen för varje story; approximerar ni tiden som

kommer krävas för varje sprint eller för varje story?

Q1: Just nu gör vi inte det, eftersom allt är osäker gällande krav från

kunden i och med det nya avtalet. Vi lägger inte ner någon tid på att

estimera. Men till exempel det tidigare projektet vi höll på med

(SKAPA), då estimerade vi tiden genom att lägga poäng kring story för

att sedan bryta ner det till tid och bestämma tidsdisponeringen. Men då

hade vi större krav från kund att leverera i viss tid. Mer som en

deadline, men det har vi inte nu, så vi är inte lika noga på att estimera.

SY: Ni har alltså inga specifika krav i dagsläget från kunden? Q1: Nej,

inte på arbetssättet eller att vi ska leverera visst många i varje sprint.

Det är bara inom teamet som vi vill leverera.

SY: Skulle du kunna konstatera, enligt dig, att ni inte har ett krav från

kunden är ett problemområde?

Q1: Ja, anledningen till att vi inte har ett krav från kunden är att vi inte

har ett avtal som inte är klart än.

SY: Med kunden?

Q1: Mellan kunden och organisationerna runt om. Men det är absolut en

risk att kraven inte är tydliga; vi har inget slutmål.

PS: Om man ser på det sett till mål; ni vet inte riktigt vad kunden vill ha

egentligen?

Q1: Nej, vi vet inte vad kunden vill ha. Det var mer tydligt i det tidigare

projektet, då skulle vårt system från ett ställe till ett annat; vi visste

tydligt vad slutmålet var och då var det enklare att både estimera och

planera.

PS: Det stora systemet i det hela är klart men det är systemstödet som

inte är klart?

Q1: Det är dom nya pensionsavtalen som inte är klara. Det är en massa

yttre faktorer; det pågår förhandlingar på en massa ställen.

SY: Dom här avtalen; är det kundens avtal gentemot yttre intressenter?

Inte gentemot er? En indirekt intressent.

Q1: Precis, pensionsavtalen. Men så är det, har man inte tydliga krav, så

blir det svårt hela vägen.

SY: Vilka ytterligare risker har du upplevt inom processen? Andra risker

som kan potentiellt uppstå eller har uppstått.




2018-08-20

77

Q1: Inte vad jag kommer på nu så där, faktiskt. Det är väl att man har en

produktägare som inte är aktiv, så blir det svårt. Det blir svårt att

prioritera vad som ska göras.

PS: Så det är väl en risk också; alla vitala medarbetare i teamet, som

produktägaren; om alla inte är aktiv, så kan man inte producera en bra

outcome?

Q1: Nej, precis så är det.

SY: Produktägaren/projektledaren är för tillfället inte här hela tiden.

Finns det någon risk förknippat med det? Det vill säga tillgängligheten

av den ledarrollen.

Q1: Så är det men vi har andra som tar på sig den rollen. Dom andra i

teamet vet redan så pass mycket ändå. Men jag kan tänka mig vid andra

projekt, där produktägare är lite utanför, så blir det viktigare att ha en

aktiv produktägare som även kan prioritera det vi ska göra. Det kanske

finns en jättelång lista på krav men vi kommer inte kunna gör allting, då

är det jätteviktigt att produktägaren föder teamet med ”den här

ordningen skall ni göra det här, för ni kommer inte kunna göra det här

längst nere”. Finns det inte där, då kanske vi levererar det som är minst

viktigt. Vi vet inte det, det är produktägaren som vet det.

[9:55]

SY: Vilka risker förknippar du för projektet relativt mot kostnaden? Q1:

Kunden har ju – vi har ju bara en viss budget. Kostnaden är alltid något

vi måste ta hänsyn till. Då är det extra viktigt att kunna prioritera, så att

vi inte lägger ner tid på sådant som vi inte egentligen behöver utan bara

önskemål.

SY: Önskemål från kundens sida eller från teamet?

Q1: Det kan ju vara kunden också egentligen men det kanske är ”meratt-

ha-bra”-saker.

PS: Så ni lägger inte ner tid och resurser icke-värdeskapande arbeten?

Q1: Ja, precis. Men sen har du lagkrav som måste vara uppfyllda, det

måste kunden säga åt oss – vad som är det viktiga och vad som är mer

”bra-att-ha”-grejer.

SY: Gör ni prioriteringen tillsammans med kunden?

Q1: Ja, det är kunden som får bestämma vad som ska göras först och vad

som ska göras i mån av tid.

SY: Hur ofta bestämmer prioriteringen överens med vad kunden vill ha?

Q1: Vi gör inte prioriteringen, kunden är med hela tiden.




2018-08-20

78

SY: Hur ofta anser du att kunden överensestimerar resurserna? Q1:

Kunden kan se att kostnaden blir för högt och då dras den

funktionen ner i prioriteringslistan.

SY: Så det uppstår inte några större problem med prioriteringen? Q1:

Nej, oftast inte. Men ofta är det svårt för det är så mycket vi vill göra.

SY: Men när det väl uppstår problem, vilka sorters problem upplever ni?

Tid, kostnad?

Q1: Jag vet inte, jag är oftast inte med på dom mötena.

SY: Om ni ser en värdeskapande process som kunden skulle ha nytta av

men dom inser inte detta, hur ställer ni er till väga då?

Q1: Då får man försöka sälja in det till kunden men om dom ser att det

blir för dyrt – kunden har det avgörande ordet.

SY: I relation till medarbetarna. Får du någon information gällande

riskfyllt agerande gällande t.ex. ett åtagande om en story som tog för

lång tid eller kostade för mycket. Får ni någon återkoppling? Q1: Vi har

ju sprintplaneringar där vi sitter och diskuterar storyn. Nu har vi ingen

tidsestimering men när vi inte hade det, så hade vi en tid att uppskatta.

Sen om det drar iväg på tiden märks det vid dom dagliga mötena vi har

på morgonen. Möjligheten att återkoppla finns alltid – det finns alltid en

dialog kring en story om det uppstår ett problem. Sen har vi även

återblickar när vi tittar tillbaks på sprinten – ser man då att alla storys

drar iväg på tiden, så kanske vi måste göra om tidsestimeringen och

lyfta upp det. Sen kan det vara man måste börja dra ner på

funktionaliteten eller hur mycket vi ska testa, så det inte drar iväg för

mycket. Det går att skruva på hela tiden.

SY: Brukar ni prata något om risker kring sprintplaneringen. Q1: Vi

kanske inte direkt nämner det som risk. Vi vet vilka processer och

flöden som är mer kritiska än andra som det absolut inte får bli fel i. Vi

kanske måste lägga ner lite mer tid eller testa på flera håll. Vi har en

ganska bra koll på vilka delar som är mer sårbara och riskfyllda. PS:

Samtliga medarbetare är alltså medvetna om dom risker som ingår i

processerna.

Q1: Alla kanske inte är det men det brukar oftast framgå, sen brukar det

bli att vissa utvecklare från vissa delar – beroende på hur erfaren man är

– man kanske inte får börja med dom mest kritiska delarna i början utan

får börja med något enklare. Dom erfarna får gå in på det mer komplexa

då det kan slå fel på flera ställen.

SY: Risker knutna till testingfasen då?




2018-08-20

79

Q1: Man kan ju inte alltid testa allt. Vi har inte automatiska tester som

andra har, där man gör allt om och om igen. Vi kör manuella tester där

vi verkligen måste in i systemet och testa.

PS: Ser ni det som en risk, att ni kör på manuellt testande?

Q1: Ja, så är det. Vi har varit inne på automatiserad men det tar väldigt

mycket tid. Är det någon ändring, så måste man ändra i det

automatiserade testet. Vi satsade inte på det. Om det fanns

välfungerande automatiserade tester, så skulle det varit bra. Tar vi in

någon ny som ska testa så kan ju det också vara en risk.

SY: Några risker gällande systemutvecklingen?

Q1: Det finns alltid risker med att peta i koden och se vart det slår. En

ändring kan påverka ett helt annat ställe, så det är ju en risk.




2018-08-20

80

Person D I2: Vilken omfattning har du på organisationen?

R: Omfattning, du tänker tid eller roll eller?

I2: Roll

R: Projektledning och förvaltningsledning jobbar jag med.

I2: Vad ingår i ditt dagliga arbete?

R: Mycket att styra arbete antingen i projektform eller i åtaganden,

långsiktigt åtagande. Säkerställa att vi har rätt personal som fyller att vi

uppfyller de kontraktuella åtagandena då i projektform eller

förvaltningsåtaganden.

I2: Vilka generella risker upplever du knutet till din roll här på

organisationen?

R: Väldigt öppen fråga, svår att svara på såhär direkt. Vi har en ganska

förändlig verksamhet i mitt åtagande som jag sitter i, vi styrs ju mycket

av omvärldskrav och såntdära. Så planeringen tenderar till å, vi måste

styra om planeringen ganska ofta på ett normalt verksamhetsår över

projekt som vi själva inte styr över utan det kommer omvärldskrav ifrån

finansinspektionen det finns parter, fackliga och arbetsgivarparter som

förhandlar och tar beslut som vi måste leverera. Det är väl en planering

som förändras ganska mycket, det är väl en generell risk som jag kom

att tänka på då.

I2: Finns det risker i och med den risken, att det kostar mer eller tar mer

tid?

R: Så är det ju alltså, effekterna blir ju oftast ringar på vattnet, dvs om

man beslutar att ta in då ett nytt projekt på kort varsel så då kanske man

tappar effektivitet i det befintliga, det där blir en uppstartsfas. Man

kanske har levererat funktionalitet i systemlösningen som inte blir i och

med att man då, säg att vi har levererat ett projekt till 50% och får inte

ett ”Måsteprojekt” som gör att vi lägger det första åt sidan, då kanske vi

måste ändra systemlösningen i det vi redan hade levererat 50% av det

första då. Det blir sådana ringar på vattnet effekter. Nu är väl det

kanske, jag menar jag har jobbat med många olika verksamheter där det

alltid är att man styrs av omvärldshändelser men det har varit väldigt

mycket i det här åtagandet på sistone.

I2: Det har varit väldigt mycket externa händelser som påverkar

planeringen?

R: Ja sista åren har det varit så, första åren var det inte så.




2018-08-20

81

I2: Har du något exempel på någon yttre händelse som har påverkat

projektet?

R: Ja, förhandla ett nytt pensionsavtal, det är ju inom pensionsbranchen

så dom har ju förhandlat ett nytt pensionsavtal och där har dom ingen

DEADLINE på när det ska vara klart. Så vi hade ju information om att

förhandlingar pågick men inte när det ska vara klart och när dom väl

beslutar så ska det vara klart med ett halvårs varsel. I det exemplet

också så är man trots allt, det är ju ett halvår snart sedan vi skulle vara

klar så har man fortfarande inte satt ner verksamhetskraven då. Du

sätter ju i stort sett ramarna via ett pensionsavtal men detaljplanen är

dom fortfarande inte 100% med. Det skickar vi tillbaka till ett forum där

de tolkar hur de tänkte själva. Säg att vi har motfrågor, vi får ett avtal, vi

har massvis med motfrågor hur man ska lösa det operativt och då har

dom fortfarande inte satt ned foten på den.

I2: Vilka specifika risker har du upplevt som har uppstått eller kan

uppstå i det här projektet och åtagandet?

R: Ineffektivt leveransmässigt, jag menar vi börjar leverera fast än att vi

inte vet den slutgilitiga målbilden. Det blir ju både svårt att

prognostisera kostnad och när det ska vara klart och därmed blir det

ganska tidsineffektivt kontra till att man jämför ett projekt där man vet

att det här är verksamhetskraven och dom inte är tvetydliga eller något

sådant då. Projekt kan ju aldrig kravställas till 100% och åtminstone inte

att ramarna är motsägelsefulla, det har de ju varit i det här uppdraget

man har dragit igång projektet och börjat leverera och redan där ser

man att krav A och B är fullt motsägelsefulla då.

I2: Om vi kollar i relation till funktioner och om dom kommer med krav

på en funktion och ni levererar, ser du någon tendens och risk med att

den funktionen inte stämmer överens med vad de vill ha?

R: Jag skulle snarare exemplifiera det med att dom kommer med krav på

x antal funktioner och sen ska vi börja leverera men de kan inte stå

parallellt med varann, du kan inte ta in ett underlag från ena hållet och

ett från det andra, med helt olika förutsättningar. Vad vi har gjort är att

vi har tillsatt resurser och börjat titta på grejorna sedan måste vi skicka

tillbaka frågor och vänta på svar. Så vi får ibland resurser som har lite

att göra och lite sådana grejor då. Det är mycket med kostnad och sen så

risker att kvalitén blir därefter då.

I2: Är det du som hanterar budgeteringen för åtagandet?




2018-08-20

82

R: Jag är med i en projektledarroll men i det här uppdraget så har vi i

samförstånd med kund sagt att vi kan inte lägga prognoser förrän vi vet

vad kravbilden är. ”Vi ser inte ritningen på bilen, eller vi ser inte ens en

skiss på bilen”, vi har ju idéstadiet på bilen om man nu ska göra en

sådan jämförelse då. Så jag det ligger på min roll men nu har vi ju på

strategisk nivå diskuterat med kunden att det inte är förrän vi har

kraven vi kan sätta oss och titta på en budget då, eller en prognos, det

blir ju inte budget för vi har ju redan kanske förbrukat halva och

kostnaden den vet vi ju inte heller. Just nu dock börjar vi komma och de

har några möten nästa vecka och förhoppningsvis efter dom skulle vi

kunna sätta oss ned och titta på en prognos då. Då bör kraven inte vara

motsägelsefulla

I1: Ser du någon sannolikhet och risk med att ni kan överskrida

budgeten?

R: Normalt sätt så sätter vi en budget vid projektstart, vi har inte gjort

det i år, sen har ju kunden en budget i bakgrunden på ett år vad vi

ungefär omsättningsmässigt kan ha. Så vad som händer nu det är ju

effekten av vad vi får plats med i övrigt då. Alltså vi ligger ju inom

budgeten för året men vi kanske inte hinner leverera andra projekt som

vi vill, så det är en ganska speciell situation det också då. Vi har en

accept från kunden, normalt sätt så måste du ju ha kostnaden för det

enskilda uppdraget innan du startar projektet, men här har vi ju en

förmån att ha en kund som redan avsatt en budget så inom dom

ramarna ligger vi resursmässigt. Sen får vi se hur stor del av årets totala

budget som går åt för det enskilda projektet och effekten blir ju att andra

projekt då trycka på foten.

I1: Det finns ju både positiva och negativa aspekter kring att både

utveckla och förvalta ett system, ni både utvecklar och förvaltar ju

systemet gentemot kunden, ser du några risker med det?

R: Inte kanske på grund av tidspressen vi befinner oss i utan det är mer

hur projektet är utformat och vad verksamhetskraven är. Normalt sett

så har vi i projektet, inom pensionbranchen då så är det ju olika

ålderskullar och olika förutsättningar. Nu kommer man med ett nytt

pensionsavtal som ger nya förutsättningar för en viss ålderskull,

normalt så lägger man ner dom gamla kraven, dvs att en viss del av det




2018-08-20

83

nya beståndet ligger kvar på det gamla och sen så migrerar man över till

det nya kravet då men här har man lagt till en liten abrovinkel. För att

det då inte ska slå negativt så gör man jämförelseberäkningar som

motsvarar det gamla, så här ligger vi ju kvar på både de gamla kraven

och de nya, varav det ena är en skuggberäkning som man gör i

bakgrunden. Det är ju ett exempel på något som ökar risken med

förvaltningsbarheten, dvs att du har flera olika verksamhetskrav som

gäller samtidigt då, det har vi inte haft förut. Det är ju inte tidspressen

utan hur det nya avtalet är utformat som gör att man ökar

komplexiteten i att underhålla, du ska ha mer beräkningar parallellt än

du normalt har på en individ. Där ökar ju risken ur ett

underhållsperspektiv.

I2: Hur ser du på säkerhetsriskerna på det systemet ni har idag som ni

förvaltar?

R: Det är ju framförallt om branchsamverkan, dvs vi är ju inte i en sluten

bubbla utan vi pratar ju med andra i branchen och det sättet vi hanterar

bla personuppgifter öppet är ju ett problem då. Men det är ingenting vi

kan lösa själva utan det är ju något inom pensionsbranchen då, dvs att

man kanske inte har krypterade överföringar och allt underlag som

skickas mellan olika parter. Tittar vi på det intern som vi administrerar

själv så, vi är ju en sån liten grupp och det är ju inte samma krav som

behörighetsstrukturen så det är snarare, i en revision kan vi ju få väldigt

mycket sådana här generella frågor varför man inte har olika nivåer på,

men vi är ju 10+ pers som jobbar med det så vi måste medvetet ha öppet,

alltså vi har inte fler a lager på inloggningar. Alla har personliga konton

så att det blir spårbart och sådana saker, det fanns inte i början då vi tog

över åtagandet då. Då hade man adminkonton så alla hade samma

inloggning men det har vi stärkt. Vi kan inte gå på en mall som har tio

olika lager för det innebär att, vi är ju så få resurser så skulle någon bli

sjuk så skulle ju den personen som har en viss behörighet inte fungera

om denna ligger hemma och är sjuk. Det får vi ofta förklara i samband

med revision då, då kör man en checklista som säger att man ska ha

exempelvis viss många behörighetsrutiner. Vi har stöd för det men vi

använder det inte i praktiken, inte internt men sen mot alla

slutanvändare har vi ju, dom har inte alls samma behörighet.




2018-08-20

84

R: Nu tänker jag högt kring risker och sådant men det viktiga tycker jag

är att man jobbar med dom. Att man inte prata om risk som något som

är separerat från det du gör utan det ska finnas med i din projektmetod

eller i vårt fall våran förvaltningsmetod och sådana saker. Vi pratar ju

oftast i termer om incidenter och problem kopplat till risker då, vi har ju

med det löpande i avrapporteringen så det är ingenting vi någon gång

då och då. Sen att man där fångar upp rutinen när det uppstår när en

risk har inträffat hur man hanterar det. Rutiner hur man distribuerar

information till kund, hur vi försöker förebygga saker och hur man

lägger upp spårbarheten.

I2: Har ni allt sådant dokumenterat? Allt i relation till risk.

R: Ja på någon nivå, sen hur vi termmässigt har skrivit in det, men vi har

rutiner för incidenthantering, vi pratar om avrapportering och vad vi

kan göra förebyggande. Vi för protokoll på både strategiska och

operativa möten, vad vi tar för beslut för att gå vidare och så. Jämfört

med det andra uppdraget vi hade förut så är det väldigt bra

dokumenterat. Sen om vi arbetar ur ett relaterat riskperspektiv eller om

det är mer speglat i övriga processer då tror jag det sistnämnda är, vi har

ju liksom inte en separat riskrubrik utan det bakas ju in i det övriga

arbetet.

I2: Det är inte något som ni gör löpande i sprintplaneringen?

R: Nej inte separerat så utan det är för de enskilda uppdragen.

I2: Hur tror du att din uppfattning av risker skiljer sig från de andras? R:

Att det skiljer det är ju alltid på individ nivå men vi pratar ju och tar

oftast upp då på de forum och scrummöten och sådant där vad man

tycker om det är en risk så oftast är det en individ som lyfter något men

vi får ju gruppens uppfattning

I1: Man finner väl risker på olika nivåer ändå, beroende på vilken roll

man har inom projektet

R: Så kan det ju vara, alltså det är ju systemutvecklaren sitter med en

detalj och teknisk lösning som jag i min roll inte kan hålla koll på medan

jag i min roll sitter i samverkan av olika parter som systemutvecklaren

inte är med på så visst, så är det ju att det är andra perspektiv så.




2018-08-20

85

I1: Men dessa lyfts fram av varje individ i möten?

R: Vi brukar lyfta upp dom på forumen, och sen att man inte pratar om

just att nu har jag sett en risk utan att nu pratar man kanske kring en

incident eller att man pratar i ett utvecklingsbehov i ett projekt eller

nånting sådant där det finns en risk. Men vi har ingen speciell punkt där

vi ska prata bara risker eller nåt sånt på möten men vi har forum då där

vi lyfter riskrelaterade saker och incidenter.




2018-08-20

86

Annex B: Putting possibility and impact

onto risks

Response Risk Description Risk Probability Impact Category Risk Owner

Inte får in alla krav R1

R2

R3

R4

R5

R6

R7

R8

R9

R10

R11

Response Risk Description

Probability Impact Category Risk

Owner


Brist på kunskap

Buggar i systemet

Otydliga slutmål

Beroende av

expertkonsultation

Förlust av

expertkonsultation

Tidsestimeringsproblem

Kunden inte delaktig i

processen

Avtal inte klara

Prioriteringsproblem

(stories, funktioner)

Kundens brist på

identifiering av

nödvändiga funktioner

4 5 Projektledaren (halft produktägare

3 1 Personen som har brist.

7 6

Systemutvecklare (tillsammans me

met)

3 6 Produktägare

6 3 Personen.

1 2

5 8 Projektledaren.

1 7 Produktägare.

6 7 Produktägare.

5 7 Projektledare/produktägare.

3 8 Produktägare.




2018-08-20

87

R2

R3

Brist på kunskap

Buggar i systemet

Otydliga slutmål

Beroende av

expertkonsultation

Förlust av

expertkonsultation


4 5 Projektledare.

3 3 Projektledare.

7 5 Produktägare.

3 5 Produktägare.

2 3 Projektledare.

2 5 Projektledaren.




2018-08-20

88

R4

R5

R6

R7

Response

4 5 Team.

Manuellt testande

(mänskliga faktorn)

R12

R13

R14

R15

R16

R17

R18

R19

R20

R21

R22

4 8 Systemutvecklare/testare.

Parallellt löpande

projekt (flera projekt

samtidigt) 5 3 På individen.

Motsägelsefulla krav 4 8 Kravfångaren.

Hantering av

personuppgifter 0 10 Systemutvecklare/chef.

Brist på riskanalys och

management 5 8 Individen (lyfter upp det).

Missuppfattning av krav 6 7 Systemutvecklare/produktägare.

Missuppfattning av test

4

6

5

4

7

7

8

9

Systemutvecklare/testare.

Produktägare tillsammans med ind

Systemutvecklare och testare.

Systemutvecklare, projektledare, ch

Antaganden (både

regler och funktioner)

Brist på testing

Brist på utvecklare

För många utvecklare 0 6 Systemutvecklare.




2018-08-20

89

4 4 Projektledare.


processen

R8

R9

R10

R11

R12

R13

R14

R15

R16

R17

R18

R19

R20

R21

R22

5 3 Kund.

Avtal inte klara 4

5

7

5

Kund. Kund.



Kundens brist på

identifiering av

nödvändiga funktioner 7 7 Kund.

Manuellt testande

(mänskliga faktorn) 3

5

6

5

Testare.

Projektledare.

Parallellt löpande


samtidigt)

Motsägelsefulla krav 4 4 Kund.

Hantering av

personuppgifter 2

3

2

5 Projektledare. Projektledare.


management

Missuppfattning av krav

3

3

3

4

5

5

Teamet.

Testare.

Kravfångaren.


Antaganden (både


Brist på testing 3 7 Testare.

Brist på utvecklare 2

1

5

2

Projektledare. Projektledare.

För många utvecklare




2018-08-20

90

Risk Description Probability Impact Category Risk Owner





2018-08-20

91

Brist på kunskap

Buggar i systemet

Otydliga slutmål

Beroende av

expertkonsultation

Förlust av

expertkonsultation



processen

Avtal inte klara



Kundens brist på

identifiering av


Manuellt testande


Parallellt löpande


samtidigt)

Motsägelsefulla krav

Hantering av

personuppgifter


management

Missuppfattning av krav




2018-08-20

92

R2

R3

R4

R5

R6

R7

R8

R9





2018-08-20

93

2 5 Individen.

10 5 Testare.

5 6 Projektledare.

4 4 Individ.

5 8 Chef.

5 4 Projektledare.

3 4 Produktägare.

3 4 Projektledare.

6 6 Produktägare.

3 3 Kundansvarig.

5 3 Testare.

3 3 Projektledare.

2 2 Kravfångare.

2 5 Produktägare.

3 5 Projektledare.

2 5 Projektledare.




2018-08-20

94

R10

R11

R12

R13

R14

R15

R16

R17

R18 Response Risk Description Probability Impact Category Risk Owner


3 5 Testare.




2018-08-20

95

R2

R3

R4

R5

R6

Brist på kunskap

Buggar i systemet

Otydliga slutmål

Beroende av

expertkonsultation

Förlust av

expertkonsultation



processen

Avtal inte klara



Kundens brist på

identifiering av


Manuellt testande


7 4 Projektledare

4 6 Projektledare

6 5 Testare

6 4 Projektledare

6 5 Projektledare

6 6 Projektledare

8 5 Projektledare

4 4 Projektledare

6 4 Projektledare

3 5 Projektledare/kravställare

6 4 Kravställare

7 5 Testare




2018-08-20

96

R7

R8

R9

R10

R11

R12

Intervju med alla 4

Response Risk Description Probability Impact Category Risk Owner


Antaganden (både


R19

R20

R21

R22

5 5 Projektledare.

Brist på testing 4 4 Testare.

Brist på utvecklare 5 6 Projektledare.

För många utvecklare 2 2 Projektledare.




2018-08-20

97

R2

R3

R4

R5

R6

R7

Brist på kunskap

Buggar i systemet

Otydliga slutmål

Beroende av

expertkonsultation

Förlust av

expertkonsultation


7 5 Projektledare

5 4 Projektledare

7 5 Testledare

4 3 Projektledare

4 4 Projektledare

5 7 Chef

6 4 Projektledare

Parallellt löpande


samtidigt)

R13

R14

R15

R16

R17

R18

R19

R20

R21

R22

6

3

6

5

Kund

Kravställare Motsägelsefulla krav

Hantering av

personuppgifter 6

8

8

5

Kund

Projektledare


management

Missuppfattning av krav 5 4 Kravställare

Missuppfattning av test 7 7 Testare

Antaganden (både

regler och funktioner) 7

3

7

4

Projektledare

Testare Brist på testing

Brist på utvecklare 5 6 Utvecklingsledare

För många utvecklare 5 4 Utvecklingsledare




2018-08-20

98


processen

R8

R9

R10

R11

R12

R13

R14

R15

R16

R17

R18

R19

R20

R21

R22

9

3

2

3

Projektledare

Projektledare Avtal inte klara


(stories, funktioner) 7 5 Projektledare

Kundens brist på

identifiering av

nödvändiga funktioner 2 3 Projektledare

Manuellt testande

(mänskliga faktorn) 7 6 Testledare

Parallellt löpande


samtidigt) 5

3

3

3

Projektledare

Kravställare Motsägelsefulla krav

Hantering av

personuppgifter 6 3 Projektledare


management 5

3

3

3

Chef

Kravställare Missuppfattning av krav

Missuppfattning av test 7 5 Testledare

Antaganden (både

regler och funktioner) 3 4 Projektledare

Brist på testing 4

6

7

7

Testledare

Chef Brist på utvecklare

För många utvecklare 2 3 Chef