Institutionen för informatik

Examensarbete i Informatik Kandidatnivå

Riskhantering inom IT-projekt - Ett nödvändigt ont?

Författare: Henrik Martinsson &

Frida Stjernfeldt

Handledare: Jan Aidemark

Termin: VT17

Kurskod: 2IK10E

Sammanfattning I takt med att samhällsstrukturen blir alltmer digitaliserat ökar kraven på att IT ska fungera

oklanderligt. IT spelar en fundamental förutsättning för våra liv och företag kan med IT

tillskansa sig konkurrensfördelar för att säkerställa sin position på marknaden. Detta är en

bidragande orsak till att nya IT-projekt startas på löpande band för att möta morgondagens

teknologiska paradigmskifte eller för att utveckla redan befintliga system. Samtidigt som en

relativt hög andel av IT-projekt fallerar som i sin tur påverkar involverade intressenter med

följdeffekter.

Utgångspunkten för den empiriska studien har varit att genomföra en kvalitativ

undersökning om hur fyra projektledare förhåller sig till riskhantering. Vidare kommer den

empiriska studien valideras mot det teoretiska ramverket. I det teoretiska ramverket har det

redogjorts för hur riskhantering tillämpas som verktyg samt hur riskhanteringsprocessen

förhåller sig i projektens olika faser. Ett genomgående tema har också varit att förklara de

svårigheter som uppkommer inom IT-projekt med olika infallsvinklar. Från empirin och

teorin har en komparativ analys bedrivits som ligger till underlag för att urskilja orsakerna

i hur arbetsgången med riskhantering genomförs i praktiken samt vilka svårigheter som

uppkommer för projektledarna.

Utifrån detta har studien fått en djupare överblick utifrån de olika orsakerna som har gett

incitament för hur dessa förekomster har påverkat riskhanteringsarbetet. Studien har lett

fram till en konkret slutsats som berör både interna och externa faktorer kring

riskhanteringsarbetet och de svårigheterna som infunnit sig. Studien konkluderar bland

annat att riskhantering prioriteras ned till förmån för andra åtgärder inom IT-projekt samt

att kunskapsöverföringen från tidigare IT-projekt är något som förbises.

Abstract As the structure of society is increasingly digitized, the requirement for IT to work perfectly

increases. IT plays a fundamental prerequisite for our lives, companies can with IT provide

competitive advantages to secure their position on the market. Digitization is a contributing

factor in launching new IT-projects on a regular basis to meet tomorrow's technological

paradigm shift or to develop existing systems. At the same time as a relatively large number

of IT-projects fail, which in return causes consequences for the involved stakeholders.

The basis of the empirical study has been to conduct a qualitative survey on how four project

managers relate to risk management. The empirical study will be validated against the

theoretical framework. The theoretical framework describes how risk management is used

as a tool and how the risk management process relates to the different phases of the projects.

An overall theme has also been to explain the difficulties that arise in IT-projects with

different approaches. From the empirical theory and theoretical framework, a comparative

analysis has been carried out that underpins the reasons for how the workflow with risk

management is implemented in practice and the difficulties that arise for project managers.

Based on this, the study has gained a deeper overview based on the various reasons that

have given incentives for how these occurrences have influenced risk management. The

study has led to a concrete conclusion that concerns both internal and external factors

regarding the risk management work and the difficulties that have ascended. The study

concludes, among other things, that risk management is prioritized in favour of other actions

in IT-projects and that knowledge transfer from previous IT-projects is something that is

overlooked.

Förord Vi vill passa på att tacka vår handledare Jan Aidemark för hans engagemang i vårt arbete

samt all vägledning under resans gång. Vi vill också berömma honom för hans snabba och

smidiga kommunikation. Vi vill även passa på att tacka alla tillgängliga projektledare för

tiden ni har givit oss och det professionella bemötandet. Slutligen vill vi även tacka de som

har tagit sig tid att läsa igenom arbetet under resans gång.

Slutligen vill vi slå ett slag för Google-Drive som är ett smidigt och interaktivt verktyg som

har huserat vårt arbete under skrivprocessen.

Innehållsförteckning

1 Introduktion ______________________________________________ 6 1.1 Inledning/bakgrund _______________________________________________ 6

1.2 Tidigare forskning ________________________________________________ 7 1.3 Problemformulering _______________________________________________ 8

1.4 Syfte och frågeställning ____________________________________________ 9

1.5 Avgränsning/Begränsning __________________________________________ 9 1.6 Målgrupp ______________________________________________________ 10

2 Bakgrund/Teori __________________________________________ 11 2.1 Riskidentifiering ________________________________________________ 11 2.2 Projekt som framgångsfaktor _______________________________________ 12

2.3 Agil utvecklingsmetod ____________________________________________ 14

2.4 Vattenfallsmodellen ______________________________________________ 15 2.5 Riskanalys _____________________________________________________ 16 2.6 Risker hänförda till projektets omfattning _____________________________ 18

3 Metod __________________________________________________ 21

3.1 Vetenskaplig ansats ______________________________________________ 21 3.2 Datainsamling __________________________________________________ 21

3.2.1 Urval ______________________________________________________ 22

3.2.2 Genomförande ______________________________________________ 22

3.3 Analys ________________________________________________________ 23 3.4 Tillförlitlighet __________________________________________________ 24 3.5 Etiska överväganden _____________________________________________ 24

4 Empiri __________________________________________________ 26

4.1 Arbetsgången med riskhantering ____________________________________ 26

4.1.1 Informant A ________________________________________________ 26

4.1.2 Informant B ________________________________________________ 27

4.1.3 Informant C ________________________________________________ 29

4.1.4 Informant D ________________________________________________ 29

4.2 Vikten av riskhantering ___________________________________________ 30

4.2.1 Informant A ________________________________________________ 30

4.2.2 Informant B ________________________________________________ 30

4.2.3 Informant C ________________________________________________ 31

4.2.4 Informant D ________________________________________________ 31

4.3 Svårigheter med riskhantering ______________________________________ 32

4.3.1 Informant A ________________________________________________ 32

4.3.2 Informant B ________________________________________________ 33

4.3.3 Informant C ________________________________________________ 33

4.3.4 Informant D ________________________________________________ 33

4. 5 Analys ________________________________________________________ 34 4.5.1 Riskidentifieringsprocessen ____________________________________ 34

4.5.2 Projekt som framgångsfaktor ___________________________________ 35

4.5.3 Agil arbetsmetod kontra vattenfallsmodellen _______________________ 35

4.5.4 Projektdokumentation och kunskapsåterföring _____________________ 37

4.5.5 Kundperspektivet ____________________________________________ 37

4.5.6 Projektets omfattning _________________________________________ 38

5 Diskussion ______________________________________________ 39 5.1 Resultatdiskussion _______________________________________________ 39

5.1.1 Diskussion från tidigare forskning _______________________________ 40

5.1.2 Slutlig diskussion ___________________________________________ 41

5.2 Metodreflektion _________________________________________________ 44

6 Avslutning ______________________________________________ 45 6.1 Slutsats ________________________________________________________ 45

6.2 Förslag till fortsatt forskning _______________________________________ 45

Referenser ___________________________________________________ 46

Bilagor 1. Intervjufrågor

Figurförteckning Figur 1 – Projekttriangeln s. 12

Figur 2 – Kombination av de två tillvägagångssätten för riskhantering s. 13

Figur 3 – Agile Model Life Cycle s. 15

Figur 4 – Vattenfallsmodellens livscykel s. 16

Figur 5 – Miniriskmetoden s. 16

Figur 6 – Riskanalys, utvärdering, bedömning och styrning s. 18

Figur 7 – Scope definition och bakomliggande orsaker s. 19

6 (50)

1 Introduktion

1.1 Inledning/bakgrund

Riskhantering har under de senaste åren blivit ett alltmer förekommande ämne både i

näringslivets och för den politiska agendan. Företagsledare anser att affärsmiljön successivt

har blivit mer volatil och riskabel som medför att denna osäkerhet behöver hanteras med

andra angreppssätt än tidigare (Toscha 2012). Riskhantering i projekt kräver ett

tillvägagångssätt där projektformen möjliggör ett brett användningsområde som omfattar

utveckling och leverans av tjänster, produkter, byggnader, koncept med mera. Projekt

bedrivs vanligen i en egen organisation och behöver följaktligen en separat riskhantering

(Wendenstam 2008). Orsakerna till att IT-projekt misslyckas beror enligt Charette (2005)

oftast på en kombination av teknik, projektledning och affärsbeslut där varje dimension

interagerar på ett komplicerat sätt med de övriga dimensionerna. Vilket leder till att

projektrisker och problem förvärras som då ökar risken för ett misslyckat projekt.

Författaren Charette (2005) gör en liknelse mellan orsakerna till att IT-projekt misslyckas

med att flygplan kraschar. Påstående förklaras av att piloter aldrig har som intention att

krascha likväl som mjukvaruutvecklare aldrig har inställningen att misslyckas med sina

åtaganden. Arbetsgången vid en flygkrasch genomsyras av att utredare analyserar ett flertal

faktorer som väderförhållanden, driftdokumentation, kulturella faktorer inom flygbolaget

med mera. Detta tillvägagångssätt går att omsätta även till IT-projekt där arbetsmiljön,

tekniska förvaltningen, projektledningen och organisationens kultur är faktorer som behöver

bearbetas för att komma till botten med mjukvarufel (Charette 2005). För att sätta detta i

perspektiv berättar författaren att det uppskattningsvis är 5-15% av de IT-projekt som

initieras världen över som överges direkt vid igångsättandet för att de är otillräckliga.

Samtidigt kommer andra IT-projekt levereras senare än planerat, över budget eller kräva

omfattande omarbetning. Detta indikerar att någonting är fel och vad som förbryllar

författaren är att det många gånger är möjligt att förutse projektavveckling i förväg. Tyvärr

har organisationer inte detta som högsta prioritet till förmån för andra ärenden. Att förstå

varför organisationer har detta förhållningssätt är viktigt då det resulterar i miljardbelopp i

kostnader varje år för näringsliv och samhälle (Charette 2005).

Det valda ämnet avser att undersöka skillnaden mellan verklighet och teori. Vilka är

bristerna hos projektledare vid deras arbete kring riskhantering. Samt att undersöka vilka

åtgärder projektledarna vidtar för att förhindra de potentiella risker som kan inträffa.

Inspirationskällan för det valda ämnet kommer från ett tidigare arbete skrivet i kursen

Projektledning och teknisk kommunikation vid Linneuniversitetet hösten 2016. Arbetet som

utfördes av Albertsson & Stjernfeldt (2016) kom fram till att fallföretag inte hade något

specifikt sätt att arbeta med kring risker utan det gjordes olika mycket beroende på kunden

av projektet. Rapporten resulterade i att fallföretaget inte gav några riktlinjer utan det var

upp till varje projektledare hur risker skulle hanteras i projekten (Albertsson & Stjernfeldt

2016). Detta väckte ett intresse till en större och djupare undersökning om försummandet

av riskhantering är en bidragande faktor till att många procent av projekt klassificeras som

7 (50)

misslyckade? En omfattande del av litteraturen genomsyras av att riskhantering är en viktig

del att ta hand om för att generera ett lyckat projekt.

1.2 Tidigare forskning

I CHAOS - rapporten från The Standish Group (2013) går det att urskilja att 18% av alla

IT-projekt under 2013 antingen blev avbrutna i förtid eller levererade med brasklappen att

de aldrig kom till användning. En annan siffra från undersökningen var att 43% av IT

projekten möttes av utmaningar i form av funktionalitet, begränsade ekonomiska resurser

samt svårigheter med den schemalagda tiden. Enbart 39 % av IT-projekten följde de

uppsatta ramarna och kunde levereras med uttalad funktionalitet. Vidare i undersökningen

framkommer det att implementeringen av småskaliga projekt som utmynnar i lyckat

projektresultat är nästan lika för den traditionella vattenfallsmodellen som med den agila

metoden. Dessutom jämfördes projektresultaten med projektens storlek som indikerade att

de mest framgångsrika projekten var småskaliga. Detta eftersom projekten hade en tydlig

projektvision, reducerad arbetsmängd, reducerad tidsåtgång gällande kravinsamling samt

att det gick snabbare att uppnå önskat projektresultat. Flera involverade företag i

undersökningen bekräftade att denna bild av projektoptimering ger incitament för att

genomföra uppdelning av storskaliga projekt till mindre projekt vilket resulterade i ökad

andel framgångsrika projekt (The Standish Group 2013).

Författarna de Bakker, Boonstra & Wortmann (2010) förklarar att det är den traditionella

synen på projektframgång som medför att många projekt misslyckas. Ramarna för det

traditionella förhållningssättet är att projekt ska omfattas av tidskrav och tillgängliga

resurser annars markeras projekten som misslyckade. Detta beskriver författarna som

ohållbart då dessa delar enbart tas i anspråk vid initieringen av projektet. Därför anses en

annan syn på projektframgång vara önskvärt för att undvika att projekt ses som misslyckade

trots att de egentligen inte är det (Bakker, Boontra & Wortmann 2012). Enligt Tonnquist

(2014) finns det svårigheter med det traditionella arbetssättet vilket bidrar till att IT-projekt

misslyckas. Problemet kan lösas med den agila metoden som är flexibel eftersom den kan

tydliggöra mål, involvera användare samt ha ett dynamiskt förhållningssätt till

måluppfyllelse under projekttiden. Vidare fokuserar den agila metoden på användbara

delresultat.

Från en undersökning genomförd av Scrum Alliance (2015) framkom det att den agila

arbetsmetoden Scrum används frekvent inom mjukvaru- och systemutvecklingsprojekt. Av

de 5000 respondenter som ingick i undersökningen svarade nästan hälften att Scrum

används 50% av tiden eller mer i organisationerna. Den totala andelen framgångsrika

projekt som levererades med hjälp av Scrum var 62%. Vidare var den rekommenderade

storleken på projektgruppen för Scrum fyra till nio deltagare där avvikelser från detta

intervall rapporterade sämre resultat. Två faktorer som respondenterna ansåg vara

utmanande för Scrum var dels att identifiera och mäta framgången för Scrum projekt som

52% uppgav, samt övergången från den traditionella vattensfallsmodellen till att följa praxis

för Scrum som arbetsmetod som 46% uppgav (Scrum Alliance 2015).

8 (50)

I en fallstudie genomförd av Taylor, Artman & Woelfer (2012) lyfts det fram tre

framgångsfaktorer för riskhantering i IT-projekt. Första faktorn är vikten av aktivt

deltagande av forskningsinriktade utövare som har en djup kunskap om de begränsningar

och tvetydigheter som råder i praktiska kontexter. Nästa faktor är övergången från

sammanställning av riskfaktorer i checklistor till en hanterbar uppsättning av

projektdimensioner som kan mätas vid uppkomsten av IT projekt. Avslutande faktorn är att

framställandet av informationen ska vara i ett format som överskådligt visualiserar

samspelet mellan enskilda detaljer (Taylor, Artman & Woelfer 2012). På samma tema har

en studie genomförd av Hidding & Nicholas (2017) med utgångspunkt från författarnas

egna litteraturstudie där framgångsfaktorer har kartlagts för ett framgångsrikt IT-projekt.

Listan av framgångsfaktorer är omfattande vilket medför att författarna selektivt har valt de

som är vanligt förekommande. Några av de bidragande orsakerna för ett framgångsrikt IT-

projekt är tydligt uppsatta mål och krav, god kommunikation med involverade aktörer samt

realistiska estimat för ett färdigställande i tid (Hidding & Nicholas 2017).

Irfandhi (2016) har genomfört en studie om framgångsfaktorer för riskhantering. I den har

det konstaterats att en korrekt genomförd riskhantering kan leda IT-projekt till ett lyckat

resultat men bara om insikten kring riskerna har identifierats vid projektets uppstart. Om

detta anammas leder det till att det upprätthålls en kostnadseffektiv struktur och att

schemaläggningen följs eftersom dessa egenskaper korreleras och definieras under

projektets planeringsfas (Irfandhi 2016). En anledning till att många IT-projekt misslyckas

beror enligt Talet, Mat-Zin & Houari (2014) på den teknologiska framfarten. Komplexiteten

vid utveckling av programvara samt osäkerheten som uppstår i projektets utvecklingsmiljö.

För att råda bukt på detta föreslås det att IT-projekt ska vara mottagliga för ökade kostnader,

förseningar och schemaförändringar under projektets gång. Vidare förklaras det att IT-

projekt kan ha olika förhållningssätt till riskhantering (Talet, Mat-Zin & Houari 2014).

Aloini, Dulmin & Mininno (2012) fastställer att riskhantering för projektbaserade

affärssystem är komplexa då en vanligt förekommande företeelse är att beroenden mellan

riskfaktorer medför att indirekta effekter påverkar projektresultatet. Konsekvenserna av

detta ömsesidiga beroende underskattas vanligen av projektledare och beslutsfattare som

motiveras av att de är svåra att inkludera logiskt i någon riskbedömning. För detta ändamål

presenterats en lösning som kallas Colored Petri Nets (CPN) som kan användas för att

modellera riskfaktorer i projektbaserade affärssystem för att lösa problematiken med

ömsesidigt beroende i riskbedömning. Resultatet från forskningen antyder fördelen med

CPN eftersom det genererar ett värdefullt stöd vid modellering av riskfaktorer då den tillåter

en lämplig riskanalys, genom att inkludera riskfaktorer i algoritmer för riskbedömning som

ligger till underlag för att stödja chefer i riskkvantifiering och begränsningsåtgärder (Aloini,

Dulmin & Mininno 2012).

1.3 Problemformulering

De bakomliggande orsakerna till det praktiska problemet hänförs till avsnittet tidigare

forskning där det går att urskilja att 18% av alla IT projekt under 2013 antingen blev

avbrutna i förtid eller levererades med brasklappen att de aldrig kom till användning (The

9 (50)

Standish Group 2013). Vidare finns det brister i den traditionella synen på projektframgång

som medför att många projekt misslyckats enligt de Bakker, Boonstra & Wortmann (2010).

Idag finns det ett praktiskt problem där IT-projekt av olika anledningar misslyckas eller

försenas (The Standish Group 2013). Ett genomgående mönster i det teoretiska ramverket

är att det råder en allmän konsensus om att riskhantering är en kritisk framgångsfaktor för

ett lyckat projektresultat. Det ger incitament till att undersöka om de projektledare som

deltar i studien håller med om denna problematik. Därtill hur deltagarna ser på

riskhanteringsprocessen och hur deras förhållningssätt påverkar projektets utfall. Detta är

relevant att utforska då projekt är en relativt komplex sammansättning där ett flertal faktorer

kan påverka projektets utfall. Ett angreppssätt för att förstå detta fenomen är att undersöka

hur projektledare tillämpar och planerar riskhanteringsaktiviteter i praktiken.

Det praktiska problemet tar sin utgångspunkt i en empirisk studie som ligger till underlag

för att förstå komponenterna i riskhantering som påverkar projektets resultat. Vidare har den

empiriska studien validerats mot det teoretiska ramverket som forskningsfältet berör för att

sedan analyseras gentemot varandra. Genom att intervjua fyra projektledare har studien fått

insikt och förståelse kring projektledarnas arbetsmetodik med fokus på deras

riskmedvetenhet samt hur riskmodeller tillämpas.

Studien avser att få klarhet kring projektledarnas respektive syn på risker. Detta berörs också

av Rausand (2011) som förklarar att om du frågar tio individer vad de menar med begreppet

risk kommer det troligen avspeglas i tio olika utsagor. En förutsättning för detta

problemområde är att informanterna som deltagit i undersökningen arbetar med

riskhantering i sina projekt och själva arbetar som projektledare. Vi ämnar kartlägga de

likheter och diskrepansen som finns i hur de olika projektledare arbetar jämfört med hur

teorin förespråkar det.

1.4 Syfte och frågeställning

Syftet med detta examensarbete är att belysa hur riskhanteringsarbetet bedrivs inom ramen

för IT-projekt. Denna kunskap kan användas av företag som vill öka sin förståelse om

riskhantering och dess svårigheter.

Frågeställningar

- Hur ser riskhanteringsprocessen ut i praktiken?

- Vilka svårigheter anser projektledarna att det finns vid genomförande av

riskhantering?

1.5 Avgränsning/Begränsning

Undersökningens inriktning är mot företag som implementerar affärssystem i små till

medelstora företag som bedriver ett projektorienterat arbete. Vi har avgränsat

undersökningen till att enbart använda oss av intervjuobjekt som arbetar som

projektledare/verksamhetskonsulter.

10 (50)

1.6 Målgrupp

Studien riktar sig till projektledare inom det informationsteknologiska området. Den

inriktningen kommer ge en insikt i vad riskhantering är för något samt hur det involveras

för projektledare som arbetar i IT-projekt. Studien vänder sig även till studenter som genom

ett adekvat förhållningssätt vill få ökad kännedom om riskhantering. Ur ett

forskningsperspektiv kommer uppsatsen att tjäna som underlag och inspiration för den

framtida forskningen inom informatik vilket medför att forskare också kommer att omfattas

av den målgrupp som vi inriktar oss mot.

11 (50)

2 Bakgrund/Teori

2.1 Riskidentifiering

För att kunna genomföra denna studie behövs olika metoder för hur riskhantering ska

hanteras. Dessa metoder ska vara välkända eller vara en metod som speglar de olika

deltagarnas arbetssätt kring riskhantering.

Initialt är det relevant att skapa en konsensus för hur risk definieras. Enligt Hill (2010) går

det att fastställa tre fundamentala beståndsdelar för begreppet risk. Dessa tre komponenter

är:

● Sannolikhet - Bedömer möjligheten för att en specifik händelse kommer att äga rum.

● Händelse - Karaktäriserar riskens händelse och vad som riskerar att inträffa.

● Påverkan – Vad konsekvenserna blir om en händelse inträffar.

Detta diskuteras även av Rausand (2011) som förklarar begreppet risk som en kombination

av svaren på tre frågor: Vad kan gå fel? Vad är sannolikheten av att det händer? Vilka är

konsekvenserna? (Kaplan & Garrick 1981 se Rausand 2011, s.5).

Att besvara den första frågan om vad som kan gå fel innebär att identifiera alla faror och hot

som kan orsaka skada på en eller flera tillgångar. Det finns flera metoder som har utvecklats

för detta syfte och dessa metoder brukar kallas farlighets metoder - hazard identification

methods (Rausand 2011). Fråga två ska svara på vad som kan gå fel. För att göra detta krävs

det enligt Rausand (2011) att riskfyllda händelser identifieras och analyseras. För detta

behövs metoder som orsaks- och frekvensanalyser. Det som besvarar den tredje och sista

frågan utförs genom att se konsekvenserna som en riskfylld händelse och som ska leda till

ett visst mål. Genom utveckling av olycksscenarier kan detta genomföras då identifierade

händelser från risk till mål kartläggs och illustreras grafiskt.

Vidare förklarar Hill (2010) att risker kan vara situationsbaserade som klargöras av vad det

är för typ av projekt som berörs samt att riskerna kan vara relaterade till varandra.

På samma tema har Tonnquist (2014) redogjort för risker som är uppdelade i olika

kategorier:

● Kvalitets- och utföranderisker - Exempelvis orealistiska mål och skifte av teknisk

plattform.

● Projektledningsrisker – Exempelvis bristfällig disponering av tid och resurser.

● Organisatoriska risker – Exempelvis brist på prioriteringar och oviss finansiering.

● Externa risker – Exempelvis ägarbyte, arbetskonflikter och ändrade lagar och

regler.

12 (50)

Att kategorisera risker på detta sätt för respektive riskområde är något som Toscha (2012)

förespråkar. Kategorisering av risker ger en bra översikt samt att det säkerställer att

riskidentifieringsprocessen återspeglar en genomgång av relevanta riskområden.

Genom riskidentifiering går det enligt Tonnquist (2014) att identifiera tänkbara

riskhändelser. En riskhändelse ska betraktas som en enskild händelse som kan förorsaka

negativa effekter för ett projekt. Författaren lyfter fram flera tillvägagångssätt för att

kartlägga riskhändelser däribland brainstorming och SWOT-analysen. Det ger

förutsättningar till att välja en mindre riskfylld lösning eller att kompetensbrist undviks

genom att utbilda projektmedlemmarna.

Figur 1, Projekttriangeln (egen konstruerad) baserad på Tonnquist 2014 s.80

Projekttriangeln representeras av de tre hörnen kvalitet, tid och resurs. Kvalitén beskriver

vilken ambitionsnivå som projektet eftersträvar. Tid fastställer när projektet ska vara

genomfört samt tydliggör projektets deadline. Resurser handlar om faktorer som storleken

på budget, vilka deltagare projektet har och hur den disponibla arbetstiden ska fördelas för

projektet (Tonnquist 2014).

2.2 Projekt som framgångsfaktor

Traditionellt har framgången i IT-projekt bedömts utifrån tid, kostnad och kvalitetskrav som

benämns i projekttriangeln. Att bara utgå från detta kriterium leder inte till en rättvis bild

över projektresultatets påverkan hos organisationen (Atkinson, 1999). Detta är något som

även Shenhar & Dvir (2007) redogör för då många projekt färdigställs inom ramen för

tidsåtgången och budgetkrav men ändå visar sig vara misslyckade. Samtidigt som andra

projekt där både tid och kostnadskrav har överskridits visar sig ha bidragit positivt till

verksamhetens avkastning. En delförklaring till detta enligt Atkinson (1999) är att

projektledare har överskattat betydelsen av att hålla sig inom ramen för tid och budget.

Konsekvenserna blir följaktligen att verksamheten påverkas av projektet samt att

slutanvändarnas tillfredsställelse nedvärderas och nedprioriteras av projektledare.

Shenhar & Dvir (2007) förespråkar ett ramverk med fem dimensioner för att uppnå ett

framgångsrikt projekt:

1. Projekteffektivitet som avgör om ett projekt avslutades i tid och inom budget.

2. Påverkan på kunden bedöms av hur projektets produkt påverkade kundens omgivning och

verksamhet samt hur projektresultatet motsvarade kundens behov.

13 (50)

3. Projektets påverkan på involverade projektmedlemmar.

4. Affärsnyttan och direkta framgång genom att utvärdera projektets påverkan på

organisationen.

5. Förberedelse för framtiden genom att reflektera över hur projektresultatet kommer att

hjälpa organisationen att bygga konkurrensfördelar och delta i framtida insatser.

Författarna Bakker, Boonstra & Wortmann (2012) förklarar att riskhanteringsaktiviteter

bidrar till ett projekts framgång genom fyra olika effekter. Handlingseffekter är avgörande

för intressenters förmåga att orsaka och stimulera en effektiv åtgärd. Perception och

förväntningseffekter handlar om att involvera intressenters förmåga att etablera en

samstämmig syn av det förväntade resultatet. Den sista effekten berör

kommunikationseffekt genom att säkerställa en gemensam vision av projektets osäkerheter

och att förväntansbilden för projektets framgång är samstämmig. de Bakker, Boonstra &

Wortmann (2010) har de redogjort för olika infallsvinklar till riskhantering och hur det

korrelerar med projektets fortskridning och framgång. Utgångspunkten är en uppdelning

kring riskhantering som genomsyras av en utvärderingsmetod och en styrmetod. Med

utvärderingsmetod som tillvägagångssätt är syftet att kartlägga vad som orsakar problem

och där styrmetoden istället redogör för hur identifierade risker ska bearbetas.

Figur 2, Kombination av de två tillvägagångssätten för riskhantering (de Bakker, Boonstra & Wortmann 2010 s.496)

Ovanstående modell illustrerar att utvärderingsmetoden förutsätter att kända riskfaktorer

används som input i det aktuella projektet. I nästa steg ska processen för riskhanteringen

genomsyras av bearbetning av riskerna och scenarion för projekts misslyckande som

därefter ska utmynna i nya riskfaktorer. Detta förhållningssätt ska bidra till en bättre

styrning av projektet och sannolikt även en fördelaktig effekt för projektresultatet. Målet är

att skapa förutsägbarhet för kommande projekt genom att använda kunskaperna om riskerna

från tidigare projekt (de Bakker, Boonstra & Wortmann 2010).

14 (50)

En invändning mot detta kommer från Jaafari (2001) som beskriver att i verkligheten utsätts

projekt för regelbundna utmaningar. Projektet behöver då omprövas för att bedöma

projektets förutsättningar att nå målen. För detta behöver projektet ha en beredskap som är

redo att träda i kraft. Därför ska rationella beslut inte fattas i ett tidigt skede då det orsakar

suboptimering, utan ska istället verkställas när de verkligen behövs.

För organisationer är det viktigt att identifiera kritiska framgångsfaktorer hos IT-projekt, för

att säkerställa att projekt utmynnar i ett lyckat projektresultat. De identifierade orsakerna

ska inte bara vara funktionella för en viss typ av IT-projekt utan ska vara tillämpbar för alla

typer av IT – projekt (Imtiaz, Al-Mudhary, Mirhashemi & Ibrahim 2013).

2.3 Agil utvecklingsmetod

Ett flertal agila utvecklingsmetoder är baserade på det agila manifestet som publicerades av

en grupp mjukvaruutvecklare och konsulter (Agile Manifesto 2001). I manifestet definieras

ett antal principer som ska betraktas som praxis för tydliga rutiner från användning av agila

metoder;

● Prioriteten är att tillgodose kunden genom en kontinuerlig tillförsel av värdefull

mjukvara.

● Välkomna förändrade krav, även sent i utvecklingsfasen.

● Agila processer utnyttjar förändring för att säkerställa kundens konkurrensfördel.

● Leverera fungerande programvara frekvent, alltifrån några veckor till ett par

månader.

● Affärsmän och utvecklare måste arbeta tillsammans dagligen under hela projektet.

● Bygga projekt runt motiverade individer.

● Fungerande programvara är det primära måttet för framsteg.

● Agila processer främjar en hållbar utveckling.

● Involverade parter i projekt ska kunna upprätthålla en konstant takt på obestämd tid.

● Kontinuerligt fokus på den teknologiska framkanten.

● Det lösningsorienterade arbetet ska hållas simpelt och förbättras om behov uppstår.

● Den bästa arkitekturen, krav och design framträder genom självorganiserade

grupper.

● Med jämna intervall reflekterar involverade parter över hur de kan bli mer effektiva.

15 (50)

Figur 3, Agile Model Life Cycle (egen konstruerad) baserad på Balaji & Murugaiyan s. 29.

Enligt Tonnquist (2014) är Scrum en agil arbetsmetod som främst används inom

mjukvaru- och systemutvecklingsprojekt. I Scrum finns det sprintar som är på två till fyra

veckor. Tanken är att varje sprint ska leverera ett användbart resultat. Detta

förhållningssätt medför att krav bryts ner i delmål samt i korta aktiviteter som bidrar till att

täta leveranser uppnås och som säkerställer att kunden involveras i projektet. Scrum anses

fungera bäst i små team som utgörs av fem till sju deltagare som arbetar nära varandra.

Fördelarna med den agila arbetsmetoden enligt Balaji & Murugaiyan (2012) är dess förmåga

att snabbt reagera på förändrade krav i projektet. Dessutom reduceras tvetydigheter mellan

utvecklingsgruppen och kunden då parterna berörs genom ansikte mot ansikte

kommunikation som medför att kunden får kontinuerlig återkoppling.

Nackdelarna som infinner sig hos den agila arbetsmetoden är där projekt är av större storlek

eftersom det då blir svårt att bedöma insatserna och den tid som behövs tas i anspråk för

ändamålet. Vidare anses bara erfarna utvecklare ha positionen för att fatta beslut som krävs

vid utveckling. Detta medför att det finns inget utrymme för nya utvecklare med liten

erfarenhet förrän dessa individer involveras med de erfarna (Balaji & Murugaiyan 2012).

2.4 Vattenfallsmodellen

För det traditionella tillvägagångssättet är utgångspunkten att tillämpa vattenfallsmodellen,

där krav definieras i projektets inledning och där nödvändiga förändringar justeras efter att

utvecklings- och testverksamhet har genomförts. Vidare präglas vattenfallsmodellen av

Initial Requirements and Architecture Models

Iteration #1

Iteration #2

Iteration #3

Iteration #4

Iteration #N

Review

Lessons Learned

Review

Lessons Learned

Review

Lessons Learned

Lessons Learned

Close Poject

16 (50)

sekventiella faser där utfallet från respektive fas blir insatsen för nästkommande fas (Balaji

& Murugaiyan 2012).

Figur 4, Vattenfallsmodellens livscykel (egen konstruerad) baserad på Balaji & Murugaiyan s. 27.

2.5 Riskanalys

Tonnquist (2014) beskriver miniriskmetoden som ett sätt för att identifiera och

kategorisera de risker som identifieras inom ett projekt. För att prioritera riskerna används

två mätvärden som vardera går från 1 -5 där 1 är låg risk och 5 är hög risk. Dessa två

mätvärden är konsekvens och sannolikhet. Värdena som ligger uppe i högra hörnet efter

en genomförd miniriskmetod är risker som bör hanteras omgående, detta gäller även risker

med konsekvensvärde 5. Risker nere i vänstra hörnet är inte lika betydelse fulla och

behöver inte alltid hanteras. Var en risk hamnar i matrisen avgör det sammanlagda

riskvärdet, som symboliseras med en bokstav (Tonnquist 2014).

Miniriskmetoden

5 C A

4 D

3

2

1 B

1 2 3 4 5

Sannolikhet

Figur 5, Miniriskmetoden (egenkonstruerad) baserad på Tonnquist 2014 s.188.

Riskanalys används för att identifiera orsaken till skadlig händelse, att besluta den möjliga

konsekvensen av en skadlig händelse, att identifiera och prioritera hinder, samt att verka

Konse

kven

s

Analys

Design

Development

ment

Testing

Implementation

Maintenance

17 (50)

som underlag för beslut om risken med ett system är acceptabelt eller inte (Rausand 2011).

Riskanalysens huvudsakliga syfte är att stödja en specifik beslutsprocess. Resultatet av en

riskanalys är ett ramverk för intelligent och synlig riskhantering. Allt för ofta händer det att

riskvärdering genomförs utan involvering av de som gjort riskanalysen. Det kan bidra till

kommunikationsproblem och bristande slutsatser. Genom att låta samma personer delta i

riskvärdering som i riskanalys kan dessa missförstånd reduceras eller undvikas helt.

Anledningen till att projekt misslyckas enligt Aloini, Dulmin & Mininno (2007) är för att

ledningen inte utför en ordentlig riskanalys samt bortser från att genomföra de planer som

har utformats för att hantera riskerna. Det har också visat sig att i flera fall att projektledare

har erfarit att riskhantering tar mycket resurser i anspråk i form av tid och arbete, och vid

förseningar är detta något som riskeras att det dras in på.

Rausand (2011) beskriver riskhantering som en ständig process där syftet är att identifiera,

analysera och bedöma potentiella risker i ett system eller i samband med en aktivitet. Vidare

ska det identifieras och införas effektiva åtgärder för att eliminera eller reducera eventuell

påverkan. Riskhantering består av tre huvuddelar; riskanalys, riskvärdering och

riskkontroll. Riskbedömning är samlingsnamnet för riskanalys och riskvärdering. All

riskbedömning kräver stort utbud av data som kan vara mer eller mindre riktig. Den data

som används bör reflektera verkligheten. Riskvärdering beskrivs också av Rausand (2011)

som en process där bedömning av risker görs utifrån riskanalysen och med hänsyn tagen till

omvärldsfaktorer. Även identifiering och dokumentation av ytterligare riskreducerande

åtgärder är en viktig del av riskvärdering. Det finns två typer av riskkontroll och

riskreducerande åtgärder; förebyggande åtgärder och mildrande åtgärder. Förebyggande

åtgärder avser att reducera frekvensen av en risks uppkomst. Mildrande åtgärder avser att

undvika eller reducera konsekvensen av ett inträffande. Figur 1 illustrerar sambandet mellan

dessa begrepp. Riskkontroll avser att ta beslut angående de åtgärder som finns eller som ska

införas. Detta inkluderar implementera åtgärder i verksamhet och att utveckla dem vid

behov eller att utveckla redan existerande åtgärder (Rausand 2011).

18 (50)

Figur 6 Riskanalys, utvärdering, bedömning och styrning (Rausand 2011, s.10).

2.6 Risker hänförda till projektets omfattning

Författaren Kendrick (2009) grundar sina teorier från standarden PMBOK (Project

Management Body of Knowledge), som används som vägledning under processen med att

arbeta projektorienterat. Det som Kendrick (2009) berätttar är att många risker som är

kopplade till projekt kan identifieras tidigt i samband med att projektets scope definieras,

alltså där omfattningen av projektet bestäms. Vidare förklarar Kendrick (2009) att det finns

en bristfällig konsensus gällande innebörden av definitionen omfattning. Antingen finns det

breda definitioner som omfattar det mesta inom projektet eller smala definitioner som enbart

inkluderar vad som ska levereras vid framtagning för projektets produkt eller tjänst.

För detta ändamål har Kendrick (2009) tagit fram en egenutvecklad databas, kallad Project

Experience Risk Information Library (PERIL). Databasen synliggör de scope-risker som

frambringar svårigheter i ett projekt. Med en svensk översättning blir det således

omfattningsrisker. Riskerna som relaterar till scope är fördelade i de två kategorierna

förändringar och defekter. Vidare går det att urskönja att den största bristfälligheten hänförs

till hanteringen av förändringar i projekt. Den del av risker som omfattas av kategorin

defekter förblir för det mesta okända, trots det kan de ändå identifieras och bearbetas som

risker. I den sammanställning nedan som Kendrick (2009) har forskat fram, definieras

scope-riskerna samt de bakomliggande orsakerna för respektive risk.

19 (50)

Figur 7 - Scope definition och bakomliggande orsaker (Kendrick 2009, s.37).

Från Kendricks PERIL-databas går det som tidigare nämndes att urskilja två större

riskkategorier som är förändringar och defekter. Där den ena berör förändring som innefattar

scope gap och scope creep. Scope gap handlar om att processen med ett projekt fortgår innan

kraven är avklarade. När relevanta krav successivt uppkommer i projektet blir en justering

ofrånkomlig vilket medför att projektet utökas tidsmässigt. Detta kan i sin tur bero på att

projektet befinner sig i ett oprövat läge eller att det under projektets händelseförlopp

tillkommer fler intressenter som inte var inkluderat vid projektets uppkomst. Sådant riskerar

att inträffa när analysen genomförs hastigt eller när det på något annat sätt blir ofullständigt

som får till följd att projektet drabbas negativt (Kendrick 2009).

Scope creep anses vara en risk som påverkar samtliga projekt, framför allt tekniska projekt

där konstruktiva idéer eller andra oupptäckta alternativ genomsyrar handlingsutrymmet

under projektets gång. Det medför svårigheter i att stå emot lockelsen att vilja ändra

projektet till det bättre. För att motarbeta scope creeps, särskilt i mer komplicerade projekt

är det nödvändigt att kraven bearbetas och reflekteras för att åskådliggöra om

förändringarna verkligen leder projektet i rätt riktning (Kendrick 2009). Vidare förklarar

Kendrick (2009) skillnaden mellan scope-definition och scope-planering, där scope-

definition behandlar några av riskerna som förekommer och där scope-planering istället

genomsyras av en fördjupning för att få kännedom om ett bredare spektrum av risker.

Förutsättningarna för att nå en högre detaljnivå är att scope-rapporter eller andra

motsvarande rapporter används som underlag för att projektarbetet ska utföras mer

detaljrikt.

Vidare förklarar Kendrick (2009) skillnaden mellan scope-definition och scope-planering,

där scope-definition visar på några av riskerna som förekommer och där scope-planering

istället blir en fördjupning för att få kännedom om flera risker. Förutsättningarna för att nå

20 (50)

en högre detaljnivå är att scope-rapporter, produktdefinitionsdokument eller andra

motsvarande dokument används som grund för att projektarbetet ska utföras mer detaljerat.

Den andra riskkategorin berör defekta risker som enligt Kendrick (2009) har sin

utgångspunkt i att tekniska projekt är beroende av att många komplicerade komponenter ska

fungera som utlovat, vilket inte är en självklarhet när det gäller nya tekniska produkter eller

lösningar. Det finns tre kategorier av defekta risker som innefattar mjukvara, hårdvara samt

integration. Mjukvaruproblem och hårdvarufel var den vanligast förekommande typen av

defekta risker i PERIL-databasen. I flera fall visade sig orsaken vara ny oprövad teknik som

saknade nödvändiga funktioner eller pålitlighet. Den tredje typen av defekta risker är

integration som innebär brister i systemet som ligger ovanför komponentnivå. Detta

förekom dock inte speciellt ofta i PERIL-databasen, men orsakade en del skada eftersom de

vanligtvis identifieras och hanteras i slutskedet av projektet samt att de är resurskrävande

att åtgärda (Kendrick 2009).

21 (50)

3 Metod Detta arbete har genomförts med en kvalitativ metod. Med en kvalitativ metod ämnar vi att

samla in empirisk- och teoretisk data för att sedan beskriva och jämföra dem mot varandra,

detta för att urskilja mönster och samband. Det är förutbestämt vad som ska frågas och

vilken roll som informanterna i undersökningen ska besitta. För att undersöka förhållandet

mellan individ och kontext förklarar Jacobsen (2002) att en undersökning lämpligen ska ha

en kvalitativ ansats. På samma tema har även Kvale & Brinkmann (2014) förklarat att den

kvalitativa forskningsintervjun syftar till att förstå ämnen från den levda vardagsvärlden

utifrån den intervjuades perspektiv. Förståelseformen i en kvalitativ forskningsintervju kan

återspeglas i ett fenomenologiskt förhållningssätt som fokuserar på intresset av att förstå

sociala fenomen med utgångspunkt i deltagarnas perspektiv.

3.1 Vetenskaplig ansats

Detta arbete har använt sig av en deduktiv ansats. En deduktiv ansats går från teori till

empiri. Utlåtandet som ges till ett sådant arbete är att undersökarna letar efter specifika saker

och då överser annan relevant information (Jacobsen 2002). I denna undersökning är den

deduktiva ansatsen öppen eftersom det är en kvalitativ metod som används.

Enligt Jacobsen (2002) lägger den induktiva ansatsen vikt på varje uppgiftslämnare och vad

som skiljer dem åt. Nackdelen med detta är att det är resurskrävande. Jacobsen (2002)

beskriver att ansatsen är bäst lämpad för att tydliggöra ett begrepp eller ett fenomen.

Utgångspunkten för den induktiva ansatsen är att gå från empiri till teori, som innebär att

informationen som inhämtas inte ska begränsas. Kritiken mot denna ansats är att ingen kan

gå ut och undersöka något helt opåverkad.

3.2 Datainsamling

Insamlingen av teori har genomförts genom att tillämpa sökord som berör riskhantering via

de databaser Linnéuniversitetets har tillgång till. Detta tillvägagångssätt skapar

förutsättningar för relevanta sökträffar som därefter granskas för att selektivt välja litteratur

som är relevant för ändamålet. Denna iterativa process fortsätter tills en teoretisk mättnad

uppnås.

Den empiriska datainsamlingen har genomförts med intervjuer. Intervjuerna har gjorts med

fyra projektledare för att få insikt i deras arbetsmetodik och förstå komponenterna i

riskhanteringsprocessen som påverkar projektets resultat samt vad som är deras syn på

risker. Intervjuuttalanden från intervjuundersökningen ska mobiliseras för att säkerställa

förutsättningarna för ett rationellt kunskapsskapande genom kodning och tolkning

(Alvesson & Thorell 2010). Enligt Kvale & Brinkmann (2014) ska citat som presenteras

från intervjuundersökningen användas som underlag för analysfasen. Författarna har

förtydligat att intervjucitat bör relateras till texten samt tolkas för att ge den korrekta bilden

av det som ska belysas.

22 (50)

3.2.1 Urval

För intervjuundersökningen är det relevant med en diversifiering av företag som arbetar

med IT-projekt. Där storleken på företagen har varit medelstort. Med medelstora företag

menas företag med anställda mellan 50–249 anställda (EUR-Lex 2016). Studien har riktat

sig till företag som arbetar med affärssystem. De personer som varit avsedda att delta i

undersökningen är projektledare eller verksamhetskonsulter som arbetar med att

implementera affärssystem i verksamheter. Detta urval av informanter har givet en

helhetsbild av riskhanteringsprocessen och de olika perspektiv som respektive projektledare

förespråkade.

I denna undersökning har urvalet av informanter genomförts med hjälp av

bekvämlighetsurval. Bekvämlighetsurval beskrivs av Jacobsen (2002) som de personer som

är enklast att ta kontakt med. Eftersom informanterna har varit begränsade har vi använt oss

av snöbollsurval, som innebär att företaget rekommenderar en specifik person som är

lämplig för undersökningen. Jacobsen (2002) förklarar snöbollsurval som ett sökande efter

en passande kandidat genom hänvisningar av tidigare försök till att få tag i den person som

motsvarar kvalifikationerna.

Denna urvalskombination valdes att användas då undersökarna på ett personligt plan inte

hade några kontakter som passade för undersökningen. Undersökarna fick då börja med att

lokalisera vilka företag som ansågs lämpliga till undersökningen. Därefter påbörjades

sökandet efter lämpliga kandidater. Detta tillvägagångssätt upprepades tills att det var

tillräckligt många informanter med i undersökningen.

3.2.2 Genomförande

Under intervjuerna är studien intresserad av att få fram hur den intervjuade tolkar och

uppfattar det valda undersökningsämnet (Jacobsen 2002). I studien har det genomförts

intervjuer med projektledare som arbetar i företag med projekt inom affärssystem.

Projektledarnas verbaliseringsförmåga har varit fördelaktig för att få insikt i deras

arbetsmetodik som är en förutsättning för utförliga intervjusvar. Därför har intervjustudien

präglats av fyra intervjuobjekt. Informanternas utsagor har haft en stark påverkan på

studiens tolkning och resultat. Vidare har studien valt att benämna intervjuobjekten med

akronym som således är efter den kronologiska bokstavsordningen.

Enligt Kvale & Brinkmann (2014) är forskningsintervjuns öppna struktur både en tillgång

och en utmaning i undersökningssammanhang. Författarna förklarar att innan den första

intervjun genomförs ska ett teoretiskt klargörande av det tema som ska undersökas

fastställas. Det innebär att undersökarna har haft ett informerat frågande kring riskhantering

i IT-projekt under genomförda intervjuer med informanterna. Intervjumetoden som har varit

relevant för studien är den semi-strukturerade metoden som skapat ett strukturerat

förhållningssätt samtidigt som det eftersträvats en dynamisk interaktion med informanterna.

Detta förespråkas även av Galletta (2012) som skriver att den semi-strukturerade metoden

är ett fördelaktigt tillvägagångssätt då den möjliggör för ömsesidighet mellan intervjuaren

23 (50)

och informanterna samt att förutsättningen finns för intervjuaren att ställa följdfrågor

baserat på informanternas utsagor om det aktuella forskningsfältet.

Därför ska studiens intervjufrågor genomsyras av både tematiska samt dynamiska

dimensioner, där den tematiska relaterar till kunskapsproduktionen och den dynamiska till

att skapa en god intervjuinteraktion, genom att hålla samtalet flytande samt hålla frågorna

korta och lättförståeliga (Kvale & Brinkmann 2014).

Informationen som samlas in i denna kvalitativa studie är specifik och avser att belysa det

som är unikt i de intervjuades kontext. Intervjuerna har genomförts ansikte mot ansikte i

den mån som det var möjligt, resterande intervjuer genomfördes över telefon. Fördelen med

telefonintervju är att det ger ökad möjlighet att tala med människor som är geografiskt

avlägsna (Elmholdt 2006). Vidare har intervjuerna spelats in om ett samtycke från

intervjuobjekten infunnits. Har det inte varit accepterat av informanterna att bli inspelade

under intervjun, har undersökarna enbart att använt sig av anteckningar. Jacobsen (2002)

förklarar att en intervju kan använda sig av intervjuhandledning, en viss vägledning om det

ämne som undersökarna vill beröra under intervjuerna. Undersökarna har förutom att

använda en intervjuhandledning, låtit de deltagande informanterna förbli anonyma.

3.3 Analys

I undersökningen har det varit relevant med intervjuer för att få empirisk kunskap om

projektledarnas erfarenheter om ämnet riskhantering. Förkunskapen om ämnesområdet

riskhantering har genomförts för att generera en teoretisk förståelse. Vilket bidrar till att den

nya kunskapen kan integreras med den etablerade basen. Den här studien genomsyras av ett

samspel mellan teori och empiri som skapar incitament för analysen som därefter ska

utmynna i denna studies resultat.

Genomförda intervjuer har transkriberats för att tolka det underliggande budskapet som

informanterna har delgett oss från intervjuerna. Ett hermeneutiks perspektiv har använts för

att tolka och analysera intervjumaterialet. Genom att teorin och empirin har behandlats och

strukturerats utifrån varje underliggande forskningsfråga såsom återspeglas i empiri

avsnittet. Därför passar det bra att använda det hermeneutiska perspektivet som innebär att

det utgår ifrån ett flertal delar som ingår i helheten (Patel & Davidson 2011).

För detta avsnitt har det också varit relevant att utgå ifrån en narrativ analys som ämnar att

ta reda på människors subjektiva antaganden av en situation eller ett förlopp. Narrativ

analys fokuserar således på tidsförlopp och att människors upplevelser är intimt kopplade

till de processer som de är involverade i (Eriksson & Wiedersheim-Paul 2014). Genom att

undersökarna har intervjuat ett flertal informanter finns det förutsättningar för att få en

helhetsbild över hur riskhantering inom IT-projekt påverkar deras sätt att se på olika

förhållanden.

24 (50)

3.4 Tillförlitlighet

Validitet handlar om att mäta det som avses att mätas. Vilket innebär att undersöka om det

är relevant och giltigt för undersökningen. Den interna validiteten är situationsbunden och

handlar om huruvida de slutsatser som har dragits i den aktuella studien är trovärdiga eller

ej. Den externa validiteten undrar om undersökningens slutsatser är generaliserbara även till

andra sammanhang. Reliabilitet innebär att undersökningen som har genomförts är

tillförlitlig och trovärdig, som medför att samma resultat kommer att nås om

undersökningen genomförs ytterligare en gång (Jacobsen 2002).

Det resultat som uppstår från informanterna i undersökningen kan generaliseras men inte

för alla miljöer och situationer eftersom det bygger på informanternas egna tankar och

åsikter utifrån deras respektive IT-konsultbolag. Den redogörelse om riskhantering som

uppstod i litteraturstudien kan avvika i andra examensarbeten såvida det är andra författare

i den undersökningen. Detta innebär att resultatet från projektledarnas olika förhållningssätt

till riskhantering kan uppfattas olika då det i viss mån baseras på personliga kunskaper inom

ämnesområdet. Det betyder dock inte att resultatet är otänkbart att replikera. Från ett flertal

kvalitativa metoder har det enligt Bryman (2011) visat sig komplicerat att replikera eftersom

det finns flera variabler som behöver tas i beaktning.

För denna studie har datainsamlingsmetod och analysmetod varit anpassat efter studiens

syfte och frågeställningar. Vidare har kvalitetskontroll av data ägt rum i form av granskning

av sakkunnig handledare samt att studien har seminariebehandlats vid några tillfällen innan

studien blev publicerad.

3.5 Etiska överväganden

Studien har anammat riktlinjer gällande etiska aspekter som har avspeglat sig till

informanterna i form av att de har informerats om studiens syfte samt hur deras medverkan

bidrar till studien. Langemar (2008) redogör för riktlinjerna som omfattar de etiska

aspekterna enligt följande:

● Informationskravet - som innebär att informanterna dels ska informeras om studiens

syfte i allmänna ordalag samt vad informanterna förväntas göra och hur deras

medverkan bidrar till studien.

● Samtyckeskravet - som innebär att deltagande i forskningen är frivilligt, både

formellt och reellt. Det är alltså upp till informanterna att avgöra om de vill

medverka i studien eller ej. Informanterna har alltså rätt att när som helst avbryta sitt

deltagande utan att vi kan ha några invändningar mot det som efterfrågas.

● Konfidentialitetskravet - som innebär att allt material ska behandlas konfidentiellt.

Det innebär att information inte får lämnas ut som kan användas för att identifiera

informanter mot deras vilja. För att lösa detta problem har vi rådgjort med

informanterna och låtit dem avgöra hur konfidentiella de ämnar att vara.

25 (50)

● Nyttjandekravet - som innebär att material som insamlats för forskning endast får

användas för forskningsändamål. Det medför att materialet och empirin måste

kontrolleras och hållas tillgängligt för kommande forskningssammanhang enligt

Langemar (2008).

26 (50)

4 Empiri I detta avsnitt presenteras den insamlade empirin. Informanternas utsagor presenteras i

kronologisk ordning efter de underliggande rubrikerna som genomsyrar avsnittet. Detta

möjliggör för att kunna urskilja de likheter och skillnader som finns från den insamlade

empirin.

Informant A1 innehar rollen som projektledare och har varit verksam på företaget i två år.

Informanten arbetar på ett medelstort bolag som arbetar med att konsulta andra företags

lönesystem och har kunder inom en rad olika branscher. Informant B2 innehar rollen som

projektledare på produktutvecklingsenheten och har varit verksam där i ett flertal år.

Informanten arbetar på en IT-koncern som levererar IT-relaterad utvecklings- och

konsultverksamhet och som är exponerade mot kunder i norra Europa. Informant C3 innehar

rollen som projektledare och har varit verksam där i ett flertal år. Företaget som informanten

är verksam inom, arbetar med implementering av affärssystem mot den svenska marknaden.

Informant D4 innehar rollen som projektledare och är verksam på ett medelstort bolag som

utvecklar och stödjer mjukvarulösningar som ger organisationer och företag möjlighet att

planera, administrera och utveckla sina medarbetare.

4.1 Arbetsgången med riskhantering

4.1.1 Informant A

Informanten beskriver att initialt identifieras potentiella risker antingen från kunden eller

från de själva, för att därefter loggas och analyseras. Detta ger underlag för att utforma

åtgärder som ska exekveras. Ett viktigt sista moment är att följa upp insatserna som har

genomförts innan det markerats som avslutat. Vidare förklarar informantenen att

förhållningssättet till risker kan skilja sig från olika företag, exempelvis att det kan

förekomma ekonomiska möjligheter med att genomföra vissa ärenden som på förhand har

en högre risknivå.

Informanten förklarar att riskbedömning är en betydelsefull del av arbetet för en

projektledare, då risker förekommer på kort- respektive långsikt. Detta ställer i sin tur krav

på reflektion både i den aktuella situationen men även för en kommande fas. Informanten

framhåller också att det förekommer generella risker exempelvis som att kunder inte utför

tester eller att involverade personer avslutar sin anställning eller blir omplacerade under

projektets gång. Detta medför att projektledaren måste förhålla sig till olika typer av risker,

där vissa är specifika och andra beror på företagets nutida situation.

Enligt informanten är begreppet riskanalys en speciell metod som de använder sig av under

framtagningen av risker för ett IT-projekt. För detta ändamål tillämpar de en post-it övning

1 Informant A, Projektledare, intervju den 24 februari 2017. 2 Informant B, projektledare, intervju den 23 mars 2017. 3 Informant C, projektledare, telefonintervju den 13 mars 2017. 4 Informant D, projektledare, intervju 18 april 2017.

27 (50)

som är simpel men som möjliggör för de involverade personerna i projektet att få skriva ner

sina respektive risker på post-it lappar, för att därefter analysera riskerna utifrån en ett till

fem skala gällande sannolikhet och därefter samma procedur för konsekvensen. Detta ger

incitament för att bedöma riskerna sinsemellan och analysera samband. Vidare beskriver

informanten att de har en intern- respektive extern styrgrupp som sitter utanför

projektgruppen. Styrgrupperna har en viktig roll i att bistå vid bedömningen av risker,

exempelvis risken med att kunden inte utför tester och vad konsekvenserna av det blir.

Dessutom fattar styrgruppen beslut om att skjuta till mer resurser, beslutar om ja eller nej i

sakfrågor samt granskar vem som äger projektet i den givna kontexten.

I ett projekt är det enligt informanten viktigt att förhålla sig till det traditionella synsättet

med projekttriangeln och de tre tillhörande delarna: tid, kostnad och kvalitet. Detta eftersom

samtliga av dessa tre ben påverkar riskhanteringsarbetet. Informanten framhåller även att

deras avtal är beskrivet utifrån de tre delarna. Där du som projektledare har ett scope, alltså

projektets omfattning som ska levereras efter plan.

Ett viktigt moment enligt informanten är att deklarera vilken systemutvecklingsmodell som

ska tillämpas för att undvika ett misslyckat projekt. Det är projektets förutsättningar som

avgör om det blir ett agilt- eller traditionellt förhållningssätt. Agila projekt kräver ett stort

förtroende mellan leverantör och kund. Det är inte alltid kunden vet vad slutprodukten ska

bli och där av inte heller vad slutkostnaden resulterar i. En trend som har varit bland många

tidigare IT-projekt är att de har följt vattenfallsmodellen som enligt informanten kan vara

en bidragande orsak till antalet misslyckade IT-projekt som har förekommit. Ett exempel

som ges är att om det ska tas fram ett system som ska hantera 30.000 löner inom

detaljhandeln, där de inte kan kartlägga alla detaljer redan under förstudien. Istället är det

bättre att utgå från projektets fundamentala byggstenar och arbeta inkrementellt och iterativt

under utvecklingsprocessen. På detta sätt kommer också förändringar i projektet att hanteras

mer flexibelt än att använda vattenfallsmodellen där allt sker sekventiellt. Informanten anser

att projektledning handlar mycket om att hantera förändringar och risker som uppkommer.

4.1.2 Informant B

Informanten beskriver att inledningsvis när ett projekt skapas tillämpas mallar som är

anpassade för ändamålet. Vanligtvis arbetas det i löpande projekt där en produkt utvecklas

och då kan det antingen vara en ny version eller en adderad funktionalitet av produkten. I

verksamheten finns det dokumentation för hur tillvägagångssättet ska gå till. Ett exempel

på detta är det egenutvecklade qms (quality management system) som finns tillgängligt i

intranätet för involverade projektmedlemmar. När ett nytt projekt dras igång granskas vilka

personer som har medverkat i tidigare projekt med liknande inriktning som det aktuella

projektet. Detta för att försöka tillvarata erfarenhet som projektledare fått i samband med

liknande projekt.

Valet av systemutvecklingsmodell är ett viktigt moment för att undvika ett misslyckat

projekt. Informanten förklarar att de använder den agila arbetsmetoden som skapar

incitament för att vara förändringsbenägna i projekt. Ur ett historiskt perspektiv användes

28 (50)

den traditionella vattenfallsmodellen fram tills 2007 i företaget. Därefter har Scrum och

Kanban tillämpats som båda har ett agilt förhållningssätt vid projektutvecklingen. Fördelen

med den agila systemutvecklingen är att risker finns inbyggt vilket underlättar arbetet och

det indikerar också att riskhantering utgör ett viktigt moment vid systemutveckling förklarar

informanten. I den agila världen gäller det att försöka anpassa sig till verkligheten där

verkligheten bara för en månad sedan har förändrats och det är den ständiga förändringen

som gör att även risken ökar. På samma tema går det även att konstatera att integrationer

med olika parter medför en ökad komplexitet och risk för att synkroniseringen blir försenad

anser informanten.

För dokumenthanteringen i ett projekt finns det ett system som heter Contrast som kan

förklaras som ett intranät där det finns nödvändiga dokument för ändamålet. Överlag är det

rätt sparsamt med dokument för riskhanteringen förklarar informanten eftersom både

omvärlden och projektet förändras är det oftast inte möjligt att söka stöd i

originaldokumenten. Det är istället främst vid uppstarten av ett projekt som det är viktigt att

dokumentera vad som beslutats. Sedan följs också kraven för certifiering som finns från

företaget. Kontentan när det gäller dokumentationen av riskhantering är att dokumenten

allokeras i ärendesystemen där de är taggade med rätt etikett och tilldelas till valda personer.

Projektet är uppdelat i olika grupper där varje grupp ansvarar för sin arbetsprocess och följer

det övergripande ramverket. Det finns handlingsutrymme för att fatta egna beslut för hur de

väljer att lägga upp ärenden och dylikt. Därför är det viktig att ha löpande avstämningar

med de olika grupperna som utgör projektet. Kravstudien blir här ett grundläggande

dokument att ha i projektet. Här måste det säkerställas att det inte går för snabbt eftersom

det utgör en risk i sig. Dessutom ska de löpande riskerna hanteras genom att tillämpa

automatiserade tester och granskningar innan de går vidare till nästa fas i projektet.

Informanten förklarar att verksamheten har ett flertal avdelningar som kräver en god

kommunikation internt. Den kommunikationen är en förutsättning som leder till att

producenterna tillverkar den produkt som marknadssidan har identifierat utifrån deras

intressenter. Kommunikation är en viktig del av ett projekt, det är den delen som är öppen

för tolkning både från avsändare och mottagare. En bra kommunikation behövs inom

arbetsgruppen för att informationen ska nå dit den är tilltänkt.

”Det är så lätt att tro att folk förstod det på det här sättet eller hade tillgång till samma

information.”

Informant B5

För att dela de anställdas tidigare erfarenheter om specifika projekt eller speciella aktiviteter

är kommunikation ett viktigt verktyg mellan de anställda för att tillvarata den kunskap som

finns. Det framkommer även att kommunikation är viktigt på individnivå för att undvika

5 Informant B, projektledare, intervju den 23 Mars 2017.

29 (50)

eventuella risker som kan uppstå i projekt. Under projektets gång är det upp till de individer

som arbetar att rapportera om eventuella risker och svårigheter som de identifierat.

4.1.3 Informant C

Vid uppstarten av IT-projekt förklarar informanten att de tillsammans med kunden

genomför en riskidentifiering av potentiella risker. Det händer att kunden själv har arbetat

med att identifiera risker och hyr in informantens företag för fortskridningen av ett projekt.

Informanten betonar också att storleken på projekten varierar såväl som storleken på kunden

vilket medför att arbetsgången varierar då en del kunder väljer att hantera projektledningen

internt för att hålla nere kostnader. Under arbetsgången med riskhantering arbetar företaget

med ett dokument som kallas projektdefinitionsdokument som senare även används som

beslutsunderlag och behandlas tillsammans med kunden under projektets gång. I början på

projektet läggs tonvikten på riskhantering. Tillsammans med kunden skapas förutsättningar

för att fånga upp problem innan de riskerar att bli mer omfattande och stjälper projektet. För

detta ändamål finns det ingen exakt styrning utan det sker relativt informellt enligt

informanten. Därefter genomförs en riskbedömning där tonvikten ligger på att åtgärda de

potentiellt värsta riskerna för projektet. Ett exempel är om kundens projektledare skulle

behöva avbryta sitt deltagande för att en person plötsligt har drabbats av sjukdom eller dylikt

förklarar informanten.

”Tillsammans med kunden sätter vi gränser och ramar för vad som ingår i IT-projektet,

men under resans gång så tillkommer det ofta önskemål från kunden som gör att projekten

växer, och det utgör en risk i sig.”

Informant C6

4.1.4 Informant D

Det inledande momentet som genomförs vid uppstarten av ett IT-projekt är att riskerna

identifieras tillsammans med kunden. Informanten förklarar att riskerna ska kontinuerligt

under projektets gång revideras och mitigeras för att säkerställa att risknivån under projektet

hålls på en normaliserad nivå. För att konkretisera arbetsgången med riskhantering använder

de en mall. Mallen visa hur de ska hantera ett antal risker genom att uppskatta sannolikheten

för riskhändelsen och konsekvensen på projektet om det inträffar. Den har en fördelning på

hög-, medium och låg nivå. Beroende på vilken nivå risken ligger på tilldelas den ett

riskvärde. Dessutom är det fördelat efter vilken risktyp det är, exempelvis om det är en

generell- eller teknisk risk. Detta skapar en bra struktur för att arbeta förebyggande med

risker enligt informanten. Det ger även styrgruppen möjlighet att ta del av de risker som har

ett högt riskvärde för att utforma åtgärder för att reducera riskernas omfattning.

Beträffande dokumentationen under riskhanteringsarbetet berättar informanten att det finns

en identifikation för varje IT-projekt som gör det möjligt att referera till ett projekt.

Dokumentationen används också till styrelsemöten för att rapportera lägesuppdatering för

projektet. Ett annat moment som genomsyrar riskhanteringsarbetet enligt informanten är att

6 Informant C, projektledare, telefonintervju den 13 Mars 2017.

30 (50)

risklistan uppdateras löpande för att se vilka risker som har reducerats i omfattning eller för

att urskilja vilka risker som har avklarats i föregående stadie av projektet.

Arbetsmetoden som tillämpas i projektform är det agila förhållningssättet förklarar

informanten. För de olika områden finns det processer specifikt för ändamålet, exempelvis

utvecklingsmässigt eller för kundimplementationer och därvid inkluderas även

riskhanteringen i det processarbetet. Det förekommer att kunder vill arbeta sekventiellt med

vattenfallsmodellen och då anpassas tillvägagångssättet till kundens önskemål.

4.2 Vikten av riskhantering

4.2.1 Informant A

Riskhantering är ett nödvändigt moment för att ett projekt ska utmynna i ett lyckat resultat

enligt informanten. Mycket av projektledning handlar om planering och är inte

projektledaren medveten om riskerna innan projektet startar kan inte åtgärder planeras innan

de inträffar, vilket också kan medföra ökade kostnader för projektet. Det är viktigt att

prioritera risker under projektet för att projektledaren inte ska riskera att missa några

fundamentala delar. En förutsättning enligt informanten är att regelbundna avstämningar

med projektgruppen genomförs ifall det har uppkommit nya krav eller förutsättningar. Detta

bör även i den utsträckning som är möjligt göras med kunden eller ledningen eftersom de

har helt olika perspektiv på risker eftersom de bedömer dem utifrån sin vardag. Detta

säkerställer att projektet fortsätter enligt plan innan nästa fas i projektet påbörjas.

En av de risker som informanten tycker är värd att framhålla i sammanhanget är projektets

scope. Alltså att projektets omfattning förändras, som kan vara orsakat av att kunden vill

addera en ökad funktionalitet till projektet och då är det viktigt som projektledare att hitta

en balansgång där.

“Som projektledare har man ett ansvar att hantera förändringar som uppkommer i projektet

för att säkerställa att projektet motsvarar kundens och leverantörens förväntningar.”

Informant A7

Informanten förklarar att det finns olika perspektiv när det kommer till vad som är ett

misslyckat projekt. Ett projekt kan exempelvis levereras efter deadline eller ha kostat mer

än vad som prognostiserats men ändå motsvara kundens förväntningar vilket resulterar i en

nöjd kund.

4.2.2 Informant B

Informanten förklarar att riskhantering är ett viktigt moment som ska utgöra en del av

arbetsprocessen i form av att risker ska beaktas och bearbetas. Dessutom ska förändringar i

projekt hanteras genom att varje grupp har en checklista. För att riskhantering ska bli

ändamålsenligt är det viktigt att hitta en balans mellan riskbenägenhet och riskmedvetenhet

7 Informant A, Projektledare, intervju den 24 Februari 2017.

31 (50)

enligt informanten. Båda har sina för- respektive nackdelar men det går ändå att konstatera

att det är enklare att vara riskbenägen om individen samtidigt är riskmedveten. Ytterligare

en infallsvinkel som är värd att belysa enligt informanten är kundperspektivet eftersom ett

förändrat beteende för produkten eller på funktionaliteten kräver en form av riskhantering

från företagets sida. Beroende på om det utgör högrisk vidtas åtgärder i form av att

involverade deltagare flaggar upp det och begär en extra granskning med andra som är

involverade. Fokus när det kommer till riskhantering är att hantera förändringar som uppstår

i projekt och det finns dokument som kan användas som stöd ifall förändringen påverkar en

viss beståndsdel. Men oftast räcker det med att fråga någon om vägledning i den aktuella

situationen enligt informanten.

4.2.3 Informant C

Informanten förklarar att riskhantering är grundläggande eftersom risker finns i alla typer

av IT-projekt, alltifrån personbortfall till programmeringslösningar som behöver testas.

Riskhanteringen utgör en vital del i projekten för att det ska utmynna i ett lyckat resultat för

kunden. Vidare berättar informanten att riskhantering är viktigt för att urskilja vilka delar

av ett projekt som är till nytta för kunden och fungerar därmed som ett underlag för att

bedöma vilka risker som ska accepteras och åtgärdas. En förutsättning som lyfts fram för

att riskhantering ska bli ändamålsenlig är att det införs i kundens verksamhet. Detta ska

generera en god insikt i struktur och flöden som genomsyrar verksamheten. Det krävs även

att kunden har avsatt tillräckligt med tid för projektet. Riskhantering är också essentiellt för

att belysa medvetenheten som ger involverade projektdeltagare möjlighet att redan initialt i

projektet allokera resurser till de som kan behöva avlastning vid situationer i projektet som

riskerar att utgöra en riskhändelse.

”Att man i förväg gör kunden medveten, genom att diskutera tillsammans om dom riskerna

som kan finnas gör att man är förberedd om de skulle inträffa, under förutsättning att man

är uppmärksam och har löpande avstämning ihop med kunden.”

Informant C8

4.2.4 Informant D

Informanten framhåller att riskhantering är viktigt att genomföra för att inte riskerna ska

falla ut och medföra konsekvenser i form av att projektet försenas av olika orsaker.

Exempelvis tids- eller kvalitetsbrist som i sin tur medför att projektet inte levereras enligt

vad som var avtalat med kunden.

”Är det risker som löper ut så är risken stor att mitt projekt blir försenat eller att timmarna

springer iväg, det försätter mig i en situation där jag inte har levererat det jag har åtagit

mig att göra gentemot kunden.”

Informant D9

8 Informant C, projektledare, telefonintervju den 13 Mars 2017. 9 Informant D, projektledare, intervju 18 April 2017.

32 (50)

Ett sätt att i förebyggande syfte undvika dessa orsaker är enligt informanten att ha

projekttriangeln i beaktning under riskhanteringsarbetet för att säkerställa att kvalitet, tid

och resurs tas i anspråk under projektets fortskridning.

Riskhantering är en vital del för samtliga projekt och är ett åtagande mot kunden. En viktig

förutsättning för att uppnå en bra riskhantering är att tillämpa en gemensam risklista för att

skapa en konsensus kring hur risker ska hanteras och hur åtgärder ska planeras. Informanten

påpekar att en del risker har låg sannolikhet och konsekvens som inte behöver åtgärdas men

som läggs under bevakning för att säkerställa att sannolikheten och konsekvensen inte

förändrats. Visar det sig att det finns risker som är centrala för projektet vidtas åtgärder för

att hantera dessa genom att projektets styrgrupp beslutar om åtgärder för att hantera riskerna.

Således berättar informanten att riskhantering är ett viktigt moment för att bevaka dessa

risker samt att det finns en framförhållning när det gäller planeringsarbetet av åtgärderna

eftersom projektet i en senare fas riskerar att råka ut för oförutsedda händelser.

4.3 Svårigheter med riskhantering

4.3.1 Informant A

När det gäller riskhantering är det enligt informanten upp till varje projektledare att

säkerställa att riskhantering utförs, detta begränsas dock av tiden som finns till förfogande.

Detta skäl anser informanten vara anledningen till att riskhantering inte genomförs i den

utsträckning som är rimligt då det beror på tidsbristen. En annan bidragande orsak som

poängteras är att riskhanteringen blir komplicerad samt att det krävs disciplin för att

upprätthålla risklistan under projektets gång.

“Riskhantering behöver en viss formalisering kan jag tycka, en minimum nivå där i alla

fall. Det är största risken att man struntar i den minimum nivån. En annan risk är väl att

det blir otydligt vilken aktivitet och åtgärd som ska utföras och vem som ska äga den och

när den behöver vara löst, det är också rätt svårt.”

Informant A10

Vid vissa tillfällen beskriver informanten att riskhanteringen finns med som ett moment

bara för att den anses vara en milstolpe under projektet istället för att vara något som

regelbundet omprioriteras och uppdateras på kontinuerlig basis. Informanten tror att det

beror på tidsfaktorn. Som projektledare är det svårt att avsätta tid till olika möten där risker

diskuteras och uppdateras i och med att projekt redan omfattas av många olika möten för

projektets olika faser.

Kommunikation är något som kan förbättras mellan involverade parter. Kunden kan tolka

det som har sagts på ett sätt som inte var avsett. Enligt informanten är detta ett hinder och

kan bidra till missförstånd som kan påverka vad kunden förväntar sig att få ut av projektet.

10 Informant A, Projektledare, intervju den 24 Februari 2017.

33 (50)

4.3.2 Informant B

Enligt informanten finns det flera skäl till att riskhantering förbises, huvudorsaken är

svårigheten i att få en nyanserad och samlad bild av de olika aktiviteterna i projektet. Mindre

justeringar i projektet kan få påverkan på delar längre fram och kan influera utfallet av

projektet. Beroende på infallsvinkeln kan små ändringar från kunden få konsekvenser som

inte räknats med eller tekniska konsekvenser.

En aspekt är tidsfaktorn som är en bidragande orsak till att riskhantering prioriteras bort till

förmån för andra åtgärder. Beroende på riskens värde kan mer resurser tas i anspråk eller

väljas att göras vid ett senare tillfälle för att den aktuella tidpunkten anses medföra en hög

risk. På arbetsplatsen hålls det inga specifika riskmöten utan utgångspunkten är att det ska

involveras i det dagliga arbetet vilket genererar en hög riskmedvetenhet. Därför finns det

inga möten som är öronmärkta för riskhantering. Anledningen till att projekt försenas enligt

informanten är en bristande medvetenhet om konsekvenserna vid projektets uppkomst vilket

kan härledas till att projekt har en tendens att växa sig större och förändras över tiden.

En annan infallsvinkel som informanten lyfter fram är att kunden kan utgöra en risk, kunden

kan ändra sina prioriteringar vilket medför att deras förväntansbild påverkas. Detta är

svårhanterat för involverade parter då ett sådant beslut från kunden kan medföra en ökad

risk för projektet. Följden kan bli att budgeten överskrids och tidsåtgången förlängs men

ändå uppfyller kundens kriterier och utmynnar i ett lyckat projektresultat.

4.3.3 Informant C

En orsak till att riskhantering förbises enligt informanten är att kunden kan ha svårigheter

med att förstå hur viktigt riskhanteringsarbetet är i projektsammanhang. Därför är det av

vikt att projektledaren förklarar varför riskhantering utgör en central del av ett IT-projekt.

Beroende på storleken på projektet tenderar projektledare i mindre projekt att bistå

utvecklingsgruppen och att söka lösning på programmeringsorienterade risker. I en sådan

situation läggs mindre fokus på projektledandet och således även riskhanteringen.

Projektledaren eller kunden kan komplicera eller försvåra delar av projektet som i sin tur

påverkar riskhanteringen. Informanten förklarar att det är bättre att göra saker på enklast

möjliga sätt och tillföra resurser där det behövs för att projektet ska fortsätta enligt plan. I

detta sammanhang är det också värt att lyfta fram omprioriteringar i projektet till följd av

tidsbrist som medför en viss begränsning på riskhanteringens omfattning berättar

informanten.

4.3.4 Informant D

Intressenterna har sina egna perspektiv att förhålla sig till. Det kan finnas svårigheter i att

skapa en samsyn om vilka risker som infinner sig i projektet. Här förklarar informanten att

en projektledares erfarenhet spelar in kring vilka risker som borde belysas samt vilka

åtgärder som ska utföras under projektets arbetsgång. Det är erfarenheten som blir

avgörande för vilka risker som ska prioriteras och åtgärdas. Erfarenheten som en

34 (50)

projektledare besitter från tidigare projekt är olika och därmed ser individer olika på

situationer. Informanten nämner även att i en del projekt förekommer det uppemot 50–100

risker som förutom att det tar mycket tid i anspråk även kan medföra att de mer specifika

riskerna hamnar i skymundan till förmån för de mer irrelevanta riskerna.

En annan orsak till att riskhantering förbises enligt informanten är att erfarenheter och

lärdomar från tidigare IT-projekt inte dokumenterats. Istället tillvaratas kunskapen genom

en kvalitetssäkringsprocess där de sammanfattar de avslutade projekten för att urskilja vad

som exekverades enligt leveransplanen och vad som kunde ha genomförts bättre.

Informanten påpekar också att dokumentation från tidigare IT-projekt beror på storleken på

projektet och att bland större företag är det mer angenämt att tillskansa sig kunskapen från

tidigare IT-projekt som underlag för framtida projekt.

4. 5 Analys

4.5.1 Riskidentifieringsprocessen

Informanterna som har intervjuats berättar att riskhanteringen är viktig för att hantera

förändringar som uppkommer under projektets gång. Riskhantering är ett nödvändigt

moment för att det ska utmynna i ett lyckat projektresultat enligt informanten. Genom

riskidentifiering kan enskilda händelser med potentiell negativ effekt kartläggas (Tonnquist

2014). Risk består av de tre beståndsdelarna sannolikhet, händelse och påverkan (Hill 2010).

Informant A och informant D pratar om sannolikhet och konsekvens som ett sätt att besluta

värdet på en risk. Riskvärdet framställs av Rausand (2011) som en process där bedömning

av risker genomförs utifrån riskanalysen och med hänsyn tagen till omvärldsfaktorer. Vad

informanterna beskriver är miniriskmetoden som förklaras av Tonnquist (2014).

Informanterna använder sig av metoden för att bedöma vilken påverkan de identifierade

riskerna kan ha på projektet, se figur 5 i avsnitt 2.5. Samtliga risker som identifierats

placeras in i metoden där det sedan beslutas vilka som behöver åtgärdas snarast och vilka

som eventuellt blir aktuella i ett framtida scenario. Informant B är också inne på detta

område i form av att det är upp till individerna att flagga när de ser en potentiell risk för

projektet. Hos informant D har riskerna utöver att placeras i miniriskmetoden delats upp i

risktyper. Risktyperna ger en bra struktur och bidrar till en enkelhet vid presentation av

risker till styrgruppen. Enligt informanterna går det att urskilja ett arbetsmoment som

involverar brainstorming, som är ett sätt att belysa risker och låta de olika styrgrupperna få

uttrycka vad de anser är risker. Brainstorming är något som även Tonnquist (2014)

förespråkar eftersom det resulterar i en mindre riskfylld lösning. Informant C förklarar att

riskhantering är viktigt för att urskilja vilka delar av ett projekt som skapar nytta för kunden

och därmed ha underlag för att bedöma vilka risker som ska accepteras och vilka som ska

åtgärdas.

Tonnquist (2014) delar upp sina risker i kategorier för att enklare skilja dem åt. Detta stödjer

även Toscha (2012) genom att de bidrar med en översikt om vad som har identifierats.

Informanten A förklarar också att det finns olika typer av risker där vissa är specifika för en

viss kontext och där andra beror på företaget som sådant. Detta rimmar väl med teorin där

35 (50)

Hill (2010) förklarar att risker kan vara situationsbaserade beroende på vad för typ av

projekt som berörs. Även Tonnquist (2014) förklarar att risker är uppdelade i olika

kategorier som utföranderisker, projektledningsrisker, organisatoriska risker samt externa

risker. Genom att ta fram sannolikhet och konsekvens finns möjligheten att se vad som kan

gå fel (Kaplan & Garrick 1981 se Rausand 2011, s.5). Enligt informant D är riskhantering

viktigt för att kunna leverera det som avtalats i tid, kostnad och kvalitet. Detta genom att

tänka på de tre grundpelarna i projekttriangeln. Informant A berättar att ett avtal bygger på

projekttriangelns tre delar som identifieras som tid, kostnad och resurs enligt Tonnquist

(2014). Rausand (2011) berättar att riskhantering är en ständig process där syftet är att

identifiera, analysera och bedöma potentiella risker i ett system eller i samband med en

aktivitet. Informant A berättar hur den konstanta processen med uppdatering av risker

brister när riskhantering betraktas som en milstolpe istället för något som regelbundet

förändras. Som projektledare kan det vara svårt att avsätta tiden som behövs. Informanten

förklarar att det är upp till varje projektledare att säkerställa att riskhantering utförs.

Aloini et al. (2007) berättar att riskhantering bortprioriteras vid eventuella förseningar på

grund av att det kräver mycket resurser. Informant A uttrycker att anledningen till att

riskhantering inte genomförs är att det begränsas av den tid som finns till projektets

förfogande. Detta är något som informant B bekräftar genom att tidsfaktorn är viktig och

det som ofta bortprioriteras blir riskhanteringen. Informant C berättar att ibland kan det till

och med vara på det viset att kunden inte förstår varför riskhantering ska göras och vill inte

betala för resurserna som riskhanteringen kräver.

4.5.2 Projekt som framgångsfaktor

Både Atkinson (1999) och Shenhar & Dvir (2007) berättar att ett lyckat projekt inte enbart

kan dömas utifrån projekttringels tre variabler, se figur 1 i avsnitt 2.1. Atkinson (1999)

berättar istället vikten av slutanvändarnas tillfredsställelse med vad som levereras.

Informant A ser ett projekt som lyckat där kundens förväntningar motsvarar vad som har

levererats. de Bakker, Boonstra & Wortmann (2010) förespråkar en utvärderingsmetod vars

syfte är att kartlägga varför ett problem finns. Därefter tillämpas en styrmetod som redogör

för hur de identifierade riskerna ska bearbetas. Organisationer ser ett värde i att identifiera

kritiska framgångsfaktorer som kan tillämpas på alla IT-projekt (Imtiaz et al. 2013).

Informant B talar istället om att de arbetar med det agila arbetssättet för att undvika

misslyckade projekt. Det agila arbetssättet bidrar med drivkraft för att vara

förändringsbenägna i ett projekt. Jaafari (2001) talar särskilt för att inga förhastade beslut

ska tas i början av ett projekt då förutsättningarna för projektet kan förändras. Informant B

berättar att huvudorsaken till att riskhantering förbises är svårigheten i att få en nyanserad

och samlad bild av de olika aktiviteterna i projektet. Mindre justeringar i projektet kan få

påverkan på delar längre fram och kan influera utfallet av projektet.

4.5.3 Agil arbetsmetod kontra vattenfallsmodellen

Informant B framhäver att den agila arbetsmetoden ger incitament för involverade

projektdeltagare att vara förändringsbenägna under projektet samt att risker i viss mån finns

inbyggt i ett sådant förfarande. Den agila arbetsmetoden förespråkas även av informant D

36 (50)

som förklarar att de har processer specifikt för områden som kundimplementation och för

utveckling, där riskhantering ingår som en del av den processen som skapar incitament för

att arbetet underlättas.

I det Agile Manifesto (2001) förklaras den agila arbetsmetoden efter ett antal principer och

riktlinjer som genomsyrar det agila förhållningssättet. Några likheter med informant B går

att urskilja i form av att agila processer utnyttjar förändringar för att säkerställa kundens

konkurrensfördel, samt att involverade deltagare måste arbeta lösningsorienterat och

effektivt. Även författarna Balaji & Murugaiyan (2012) framhäver att en fundamental fördel

med den agila arbetsmetoden är dess förmåga att snabbt reagera på förändrade krav i

projektet vilket reducerar tvetydigheter mellan involverade parter. Författarna poängterar

en nackdel som är värd att beakta är i fall projekten är av större storlek då det blir svårt att

bedöma insatserna och den tid som behövs tas i anspråk när projekten blir mer omfattande.

Vilket också informant A stödjer genom att det är projektledarens ansvar att hantera

förändringar för att kunna motsvara kundens förväntningar samtidigt som det krävs ett stort

förtroende mellan leverantören och kunden enligt informanten. Informant B bygger på detta

genom att berätta att verkligheten ständigt förändras och det är en risk i sig. Shenhar & Dvir

(2007) berättar att hantering av förändring för att leva upp till kundens behov är en av fem

dimensioner för att uppnå ett framgångsrikt projekt.

Informant B berättar hur företaget arbetade enligt vattenfallsmodellen fram till 2007, sedan

gick de över till att arbeta enligt Scrum och Kanban. Vattenfallsmodellen arbetar utifrån

sekventiella faser där utfallet från respektive fas blir insatsen i nästkommande fas (Balaji &

Murugaiyan 2012). Informant A tror att trenden som har varit med att arbeta enligt

vattenfallsmodellen kan ha bidragit till antalet misslyckade IT-projekt. Det finns svårigheter

med att kartlägga allt i förstudien. För att lyckas krävs det att ett arbete utförs inkrementellt

och iterativt under utvecklingsprocessen. Genom att arbeta på det viset kan förändringar

som dyker upp anpassas berättar informant A. Arbete som sker i sprintar kallas Scrum och

förklaras av Tonnquist (2014) med att varje sprint ska leverera ett användbart resultat.

Från de informanter som har intervjuats framgår det att samtliga applicerar konceptet med

riskhantering initialt vid projektets uppkomst. Informant C förklarar att tonvikten läggs i

början av projektet tillsammans med kunden som skapar incitament för att fånga upp

problem innan de riskerar att bli mer omfattande och stjälpa hela projektet. Informant B

berättar att de hanterar potentiella risker genom att de har löpande avstämningar med

grupper som ingår i IT-projektet. Där varje grupp har ansvar för sin arbetsprocess och följer

företagets övergripande ramverk, men där det ändå finns handlingsutrymme för gruppen att

fatta egna beslut för att prioritera ärenden eller dylikt. Enligt författarna Bakker, Boonstra

& Wortmann (2012) ska arbetet med att involvera intressenterna bidra till ett projekts

framgång genom att skapa en samstämmig syn och förväntansbild hos de involverade

intressenterna om IT-projektets förväntade resultat. Informant A förklarar regelbundna

avstämningar som en förutsättning ifall något nytt behöver hanteras. Vidare trycker

informanten på vikten av att prioritera risker för att inte missa några fundamentala delar.

Informant D förklarar att det kan finnas en viss svårighet i att få en samsyn bland

37 (50)

involverade intressenter. Hur risker prioriteras och åtgärdas beror på den aktuella

projektledarens erfarenheter. Rausand (2011) berättar att prioritering av risker är en del av

riskanalysen som ska utmynna i ett ramverk för intelligent och synlig riskhantering.

4.5.4 Projektdokumentation och kunskapsåterföring

Rausand (2011) säger att dokumentation är en viktig del som bidrar till riskreducerande

åtgärder. Flertalet av informanterna lyfter fram att det finns en brist av dokumentation i

varierad utsträckning. Informant C arbetar med projektdefinitionsdokument som sedan

används som beslutsunderlag. Dokumentering sker under riskhanteringsarbetet som bland

annat används till styrelsemöten enligt informant D. Hos informant D dokumenteras inte

erfarenheter och lärdomar från tidigare projekt. Istället arbetar företaget med att tillvarata

kunskapen genom en kvalitetssäkringsprocess där de urskiljer vad som gjorts enligt plan

samt vad som kunde gjorts bättre. Informant B berättar implicit att informationen som finns

angående tidigare projekt inte dokumenteras ned utan den finns hos de individer som

deltagit i dessa projekt. Vill ett projekt åt tidigare information om hur ett projekt hanterades

får denna fråga personen som deltagit i det tidigare projektet. Informant B talar om att

dokumentationen är som viktigast i början av ett projekt eftersom att besluten som tas där

följer med genom hela projektet. Rausand (2011) förtydligar begreppen inom riskhantering

samt vad de innebär, se figur 6 i avsnitt 2.5. Detta används vid förebyggande åtgärder vid

reducering av en risk och dess uppkomst. Det framgår från informant B att när ett nytt

projekt påbörjas försöker de sätta ihop en konstellation av personer som har tidigare

erfarenhet från projekt med liknande inriktning.

4.5.5 Kundperspektivet

Informant A belyser att kunden i varierad utsträckning kan bidra med identifiering av

potentiella risker. Informanten berättar också att förhållningssättet till risker kan skilja sig

år mellan företag. Informant C berättar att det kan förekomma situationer där de inte arbetar

med risker utan kunden har valt att göra det på egen hand för att sen hyra in projektledare

från ett annat företag. Informant D berättar att det kan förekomma risker i form av att kunden

inte levererar den input som krävs till projektet. Informant B belyser att kundperspektivet

medför ett förändrat beteende för produkten eller att funktionaliteten kräver en form av

riskhantering från företagets sida. Med detta avses att kunden i sig utgör en risk enligt

informant B då den kan ändra sina prioriteringar och det förväntade utfallet av projektet. En

sådan situation riskerar projektets estimerade budget och tid, men kan ändå resultera i att

kunden blir nöjd med utfallet. Informant C förklarar situationen som följande:

”Tillsammans med kunden sätter vi gränser och ramar för vad som ingår i IT-projektet,

men under resans gång så tillkommer det ofta önskemål från kunden som gör att projekten

växer, och det utgör en risk i sig.”

Informant C11

11 Informant C, projektledare, telefonintervju den 13 Mars 2017.

38 (50)

4.5.6 Projektets omfattning

Informant A berättar att projektets scope är viktigt att bearbeta initialt, eftersom det påverkas

ifall kunden gör bedömningen att de behöver utökad funktionalitet till projektet, det är då

projektledarens ansvar att hitta en balansgång där. Detta förhållningssätt får stöd av

litteraturen där Kendrick (2009) förklarar att många risker som är kopplade till projekt kan

identifieras tidigt i samband med att projektets scope, alltså där projektets omfattning

definieras och fastställs. För detta ändamål har Kendrick (2009) utvecklat en databas över

vilka scope-risker som frambringar svårigheter i projekt, se figur 7 under avsnitt 2.6.

Eftersom IT-projekt till sin natur är komplexa är det en förutsättning att i god tid arbeta

förebyggande med risker, detta är något som informanten C ger uttryck för på följande sätt:

”Att man i förväg gör kunden medveten, genom att diskutera tillsammans om dom riskerna

som kan finnas gör att man är förberedd om de skulle inträffa, under förutsättning att man

är uppmärksam och har löpande avstämning ihop med kunden.”

Informant C12

Vad som också framgår från informanterna är att riskhantering är ett lämpligt verktyg som

används för styrning av projekt i form av löpande avstämningar för att säkerställa att

projektet fortlöper genom faserna. de Bakker, Boonstra & Wortmann (2010) förklarar att

om kända riskfaktorer används som ingångsvärde till ett projekt och därefter bearbetas i

riskhanteringsarbetet för att till sist utmynna i nya riskfaktorer skapas incitament till en

bättre styrning samt förutsägbarhet för kommande projekt, se figur 2 i avsnitt 2.2.

12 Informant C, projektledare, telefonintervju den 13 mars

39 (50)

5 Diskussion

5.1 Resultatdiskussion

Resultatet av analysen utmynnar i fyra punkter.

Projektets komplexitet

Tidsaspekten

Kundens involvering

Kunskapsåterföring

Från ovanstående genomgång av teori och empiri går det att konstatera att den fundamentala

kunskapen om riskhantering återfinns hos samtliga informanter och riskhanteringsarbetet är

ett moment som ingår inom IT-projekt. Således har studien urskilt vilka svårigheter som

förekommer med riskhantering. Värt att understryka är att tidsaspekten är en av orsakerna

till att IT-projekt misslyckas i något hänseende, som också bekräftas från informanterna vid

ett flertal tillfällen under intervjuerna. Tidsaspekten ska inte betraktas som en isolerad

händelse frånkopplad från de andra orsakerna som komplexiteten som infinner sig i IT-

projekt, eller bristfällig prioritering i form av att den disponibla tiden inte utnyttjas till fullo

till förmån för andra åtgärder. För att tidsplanen ska fungera krävs det att riskhantering

bedrivs ändamålsenligt. Annars får det till följd att projekt försenas och som i sin tur

genererar ett sämre utfall för projektet i förhållande till vad som estimerats på förhand. Vad

som går att fastslå är att samtliga av de identifierade orsakerna kan direkt eller indirekt

påverka tidsutrymmet som ett projekt omfattas av i varierande utsträckning. Detta är viktigt

att ha i åtanke för inblandade parter redan vid uppstarten och styrningen av IT-projekt då

det är många faktorer som påverkar den tillgängliga tiden som finns till förfogande.

Från de projektledare som har intervjuats går det att konstatera att rollen som projektledare

innefattar en hel del administrativt i form av att projektstyrningen ska genomsyras av

finansiell rapportering, tidsrapportering, riskhantering med mera. Vilket medför att det blir

en prioriteringsfråga av vad som anses vara viktigast för stunden. En annan viktig insikt

som går att urskilja i detta avseende är de involverade intressenterna där flera viljor gör det

svårare att skapa en samsyn samt att det riskerar att bli både merarbete och ökad komplexitet

inom projektet. Intressenten som har en central roll under projektstyrningen är kunden som

dels ska deklarera vad de vill få ut av projektet samt att de ska hållas uppdaterade under

projektstyrningsarbetet. En situation som många av informanterna har funnit sig i är den

bristande kunskapen hos kunden gentemot riskhanteringsprocessen. Där kunden antingen

inte förstår vikten av riskhanteringens betydelse för projektet eller är villiga att betala för

den tid som krävs under projektets gång. Detta bidrar till att riskhantering prioriteras bort

under projektet till förmån för andra åtgärder.

En annan viktig orsak till att riskhantering inom IT-projekt förbises är den bristfälliga

kunskapsåterföringen för framtida projekt som kan lösas genom att inneha en databas över

40 (50)

vilka lärdomar som drogs från tidigare IT-projekt. Som tidigare nämnts är detta inget som

ges uttryck från informanterna. Däremot anser vi att granskningar av tidigare IT-projekt

borde vara ett koncept som anammas av informanterna då det ger incitament till att fånga

upp erfarenheter från tidigare IT-projekt som kan användas i kommande projekt. Vad som

också blir viktigt är att projektledaren verkligen lägger ner tid och kraft på

datakvalitetsarbetet som sedermera kommer till nytta för framtida IT-projekt.

Vi nämnde tidigare att bristande kunskap är en av orsakerna till att riskhantering förbises

och det kan härledas till att kunden vill använda en riskhanteringsmetod som inte är lämpad

för just det ändamålet. Därför är en viktig förutsättning att samtliga involverade i ett projekt

har insikt om riskhantering. Denna insikt är något som växer fram genom erfarenhet varpå

det är en fördel med projektmedlemmar som har erfarenhet från liknande IT-projekt.

5.1.1 Diskussion från tidigare forskning

Från (The Standish Group 2013) under avsnittet tidigare forskning, går det att urskilja att

implementeringen av småskaliga projekt som utmynnar i lyckat projektresultat är nästan

lika för den traditionella vattenfallsmodellen som med den agila metoden. Detta är relevant

att belysa då informanterna förespråkar det agila tillvägagångsättet som skapar incitament

för att vara förändringsbenägna och där risker finns inbyggt i arbetsmetoden. Detta

tillvägagångssätt ser även Tonnquist (2014) som fördelaktigt då den agila arbetsmetoden är

flexibel samt involverar användarna under projekttiden. Från informanterna hade det varit

relevant med utsagor om varför vattenfallsmodellen anses vara ett sämre alternativ inom IT-

projekt till förmån för det agila arbetssättet.

Vad som också framgår från (The Standish Group 2013) är att storleken på projektet

påverkar projektresultatet. Där småskaliga projekt har de bästa förutsättningarna i form av

reducerad arbetsmängd, reducerad tidsåtgång samt en snabbare process för att nå önskat

projektresultat. Detta förklarades även av informant A och C som betona att storleken på

projektet avgör komplexiteten i projektet och hur väl rustat projektet är för att hantera

förändringar som dyker upp under projektets gång.

Från studien genomförd av Hidding & Nicholas (2017) går det att urskilja att uppsatta mål,

god kommunikation med involverade aktörer samt realistiska estimat under projekttiden är

viktiga framgångsfaktorer för ett IT-projekt. Dessa framgångsfaktorer stöds också i viss

mån av informanterna som implicit förklarar att när ett IT-projekt initieras ska involverade

parter medverka som i sin tur skapar incitament för att projektet fortskrider efter de uppsatta

målen och estimaten.

I en studie genomförd av Aloini, Dulmin & Mininno (2012) konstateras de att riskhantering

för projektbaserade affärssystem till sin natur är komplexa eftersom att det finns beroenden

mellan riskfaktorer som genererar indirekta effekter som i sin tur påverkar projektresultatet.

Detta är något som inträffar när projektets storlek utökas eller när oförutsedda händelser

påverkar resultatet i form av en ökad komplexitet. Riskbedömning är ett moment som utförs

av informanterna som tar sig i uttryck att risker kategoriseras och prioriteras utifrån det

beslutsunderlag som projektledaren förfogar över. Projektledare tenderar att underskatta

41 (50)

vissa risker som i sin tur inte inkluderas i riskbedömningen (Aloini, Dulmin & Mininno

2012). Från informanterna framgår det att projekt tenderar att bli komplexa när projektets

storlek utökas eller när oförutsedda händelser inträffar som resulterar i en ökad komplexitet.

Resultatet från undersökningen indikerar ett samband med den teori som Irfandhi (2016)

presenterar. En korrekt genomförd riskhantering kan leda IT-projekt till ett lyckat resultat,

under förutsättning att riskerna har identifierats vid projektets uppkomst. Den synen vill vi

komplettera genom att risker behöver revideras och omprövas kontinuerligt för att

säkerställa projektets fortskridning.

5.1.2 Slutlig diskussion

Under detta avsnitt kommer ett tolkningsperspektiv att intas på antagandena från föregående

avsnitten.

Målgruppen som beskrevs i avsnitt 1.6 kan med denna studie, få en ökad kännedom kring

riskhanteringsarbetet samt vilka svårigheter som uppkommer under ett projekt.

Informationen kan användas till att ge en ökad kunskap om konsekvenserna kring bristfällig

riskhantering samt varför riskhantering är en vital del av ett projekt. Både från den

insamlade teorin och empirin har det implicit och explicit kunnat konstaterats att

riskhantering är ett viktigt moment inom IT-projekt. Vidare finns det ett antal

nyckelbegrepp som ligger till grund för detta. Dessa begrepp har varit erfarenhet,

kunskapsåterföring, styrning och komplexitet som har varit ett genomgående mönster och

tema under forskningen. Vidare framgår det från empirin att projektledarna har ett proaktivt

förhållningssätt som genomsyras av kvalitetssäkring då samtliga projektledare genomför en

riskanalys som i sin tur skapar incitament för en ändamålsenlig riskhantering.

Forskning från The Standish Group (2013) visar att 18% av alla IT-projekt antingen blir

avbrutna i förtid eller inte har levererat vad som avtalats på förhand. Detta arbete har belyst

riskhanteringens inverkan på problemsituationen. Huruvida ett projekt betraktas som lyckat

baseras på vad som faktiskt har levererats till kunden. Det är inte nödvändigtvis att projektet

bedrevs inom den budget eller tid som avtalades på förhand. Riskhantering utgör en

fundamental grund för ett projekt. Det ska följa med projektet under dess fortskridning där

projektmedlemmar ska kunna ha riskhanteringen som underlag för hur ett projekt ska

fortskrida. Risker ska dokumenteras i den form att det står hur de ska åtgärdas och vems

ansvar det är att åtgärda dem. Dokumentet ska sedermera uppdateras och bearbetas under

hela projektet. Detta ska genomföras på kontinuerlig basis i förebyggande syfte. Vi anser

att riskhantering är en fundamental pusselbit för involverade projektmedlemmar att

efterfölja. Under studiens gång har det framkommit att riskhantering är en del av

projektarbetet som flera av informanterna önskar att de hade ytterligare tid för.

Efter att ha gjort denna undersökning frågar vi oss varför scope creep som förklaras av

Kendrick (2009) inte är ett etablerat fenomen hos projektledarna. Samtidigt går det att

urskilja en likhet mellan begreppet och informanternas sätt att hantera förändringar som

uppkommer under projektets gång. Ingen av informanterna hade direkt kännedom om

42 (50)

begreppet scope creep som dock ges stöd från litteraturen i form av Kendrick (2009) som

förklarar att scope creep är vanligt förekommande i framförallt tekniska projekt. Scope

creep handlar om att hantera oförutsedda händelser som kan resultera i överdragen

tidsåtgång för IT-projekt. För att motverka scope creep är det viktigt att bearbeta kraven för

att urskilja om förändringarna leder projektet i rätt riktning resonerar Kendrick (2009). Från

informanten A framkom det att i deras riskhanteringsarbete försöker de att hålla sig inom

ramen för projektets storlek för att det inte ska expandera till följd av utökad funktionalitet

eller liknande. Det var förvånande att begreppet inte hade en större genomslagskraft bland

informanterna. Alternativt att de skulle förstå det underliggande budskapet som avses med

scope creep. Vi anser att scope creep har blivit ytterligare en teoretisk redogörelse som finns

till förfogande för att underlätta riskhanteringsarbetet. Vidare ställer vi oss frågande till hur

stort handlingsutrymme är för projektledarna gentemot de interna och externa

styrgrupperna. I detta sammanhang kan det också vara relevant att huruvida ansvarsområdet

för detta är kopplat till projektledaren eller företagsledningen. Förmodligen är det mest

fördelaktigt att arbeta på den redan inslagna och rutinmässiga vägen som finns etablerade i

verksamheterna.

Riskhantering är en process som kan förebygga ett projekts potentiella negativa utfall under

förutsättning att en adekvat riskanalys har genomförts. Riskanalysen kan förhindra projekt

från att misslyckas i olika avseenden. För att genomföra det krävs både tid och kunskap hos

involverade parter. Tidigare har det benämnts att kunden utgör en risk. En infallsvinkel är

att det finns en motpartsrisk när det gäller betalningsförmågan vid beställning och uppstart

av projekt. Ur ett riskbaserat synsätt är det fördelaktigt om projektledarna öronmärker mest

tid och resurser åt de risker i verksamheten som utgör de mest väsentliga hoten för projektets

fortskridning. Detta förutsätter regelbundna riskgenomgångar med involverade aktörer.

Från undersökningen framgår det att möten med involverade aktörer äger rum med jämna

mellanrum, däremot förekommer det i varierande utsträckning hur mycket tid som

öronmärks för riskgenomgång. Det framgår från informanterna att riskhantering påverkas

av tidsbrist som influerar projektet och som berör huruvida utsträckningen av möten

genomförs. Detta kan i sin tur påverka mötets agenda och potentiella utfall.

Det som har framgått är att projektledarna har olika rutiner kring

riskidentifieringsprocessen. Både genom hur de själva väljer att arbeta och vilka riktlinjer

som företaget anser är relevanta för ändamålet. Det framgår från informant A och D att de

har instruktioner som styr hur sannolikhet och konsekvens korrelerar med varandra. Vidare

framgår det från informant C att hur riskhantering bedrivs är upp till varje projektledare att

avgöra.

Undersökningen indikerar att det finns inga tydliga rutiner gällande kunskapsåterföring. Det

framgick inte heller några rutiner för hantering av oförutsedda risker som dyker upp under

projektets gång. Den bristande kunskapsåterföringen bidrar till att kunskap inte tas till vara

från tidigare avklarade projekt. Vidare kan bristen även bidra till att kunskap försvinner när

anställda lämnar företaget av diverse anledningar. Risken att en anställd eventuellt lämnar

verksamheten betraktas som obefintlig och därför anses det inte vara ett problem i dagsläget.

43 (50)

Även verksamheten behöver vara förändringsbenägen inför ett sådant scenario för att

undvika att kunskap går till spillo när en anställd av olika anledningar väljer att lämna

verksamheten.

Vi ser också ett behov av att projektledare genomför realistiska tidsuppskattningar för de

olika aktiviteterna under projektets gång. Vikten av att lägga tillräckligt med tid på en

aktivitet är att projektgruppen inte stressar med att ta sig igenom viktiga delar för att hålla

tidschemat. Realistiska tidsmått vid olika faser av projektet är en förutsättning för ett lyckat

projektresultat. Vi tycker att deltagarna i denna undersökning beaktar tidsåtgången. Men att

de borde ta mer lärdom från tidigare projekt där erfarenheter och kunskaper ska samlas.

Kundperspektivet är värt att belysa då kunden har en avgörande roll vid projektets uppstart.

Kundens riskmedvetenhet påverkar hur kunden ser på riskhanteringsarbetet under projektets

livslängd. Detta är relevant då kunden har handlingsutrymmet att tillföra mer resurser samt

har möjligheten att addera funktionalitet som är nödvändig för projektets fortskridning. Det

varierar hur kunderna är involverade i riskhanteringsarbetet. Samtidigt talar informanterna

för att det finns en bristfällig kunskap hos kunderna när det kommer till riskhantering.

Informant C berättar att det förekommer tillfällen då kunden istället har valt att identifiera

de risker som finns inom projektet. Därmed är det relevant att förstå vikten av den samsyn

som krävs mellan kundens projektledare och för det anlitade projektteamet. Ett sådant

potentiellt händelseförlopp blir en bedömningsfråga för projektledarna att förhålla sig till.

Det framkommer i undersökningen att de adderade krav som tillkommer utgör en risk för

projektet. Bara för att nya krav tillkommer betyder det inte att budgeten eller tiden som finns

till förfogande ökar i omfattning. Därför ställs projektledaren inför utmaningen att kunna

hantera förändringar som uppkommer från kunden under projektets olika faser.

44 (50)

5.2 Metodreflektion

Undersökningen var initialt avsedd att inneha induktiv ansats. Under arbetets gång blev det

allt mer en kvalitativ undersökning med en deduktiv ansats i den mening att det togs fram

ett omfattande underlag av teori innan intervjuerna genomfördes. Hade undersökningen haft

intervjuer tidigare i arbetet hade det blivit induktivt men eftersom att det blev mer

tidskrävande än ursprungsplanen utmynnade det istället i en deduktiv ansats.

Urvalsmetod som har använts går att ifrågasätta, eftersom att bekvämlighetsurval inte är den

mest lämpade metoden till att få tag i rätt kandidater. Däremot är det ett urval som är

lämpligast när studien inte på förhand vet vilka personer som ska intervjuas.

Tillvägagångsättet har alltså varit öppet för att hitta företag som har passat undersökningens

kriterier. Kriterierna som fanns på informanterna var att de skulle inneha en projektledarroll

och därtill vissa arbetsuppgifter och tillhörande befogenheter. Förhoppningen var att dessa

informanter hade tillräcklig insikt över riskhanteringsarbetet vid projektstyrningen. Det

förekom tillfällen där potentiella informanter inte ansåg sig ha tillräckligt god kännedom

för att kunna delta i undersökningen. En svårighet som infann sig vid kontakten av företag

var att få till en säljtext som företagen fann intressant och givande. Ett hinder var

tillträdesproblematiken där vissa intervjupersoner inte är disponibla vilket istället medför

att alternativa intervjupersoner som är socialt frikopplade från varandra används som en

alternativ lösning på problemet. Intervjufrågorna var utformade för att generera en

helhetsbild genom olika infallsvinklar till riskhantering från informanterna. Detta har

åstadkommits genom de fyra intervjuer som genomförts.

Undersökarna anser att studien har en hög grad av replikering när det kommer till

ämnesområdet. Replikeringen reduceras däremot när det kommer till den sociala kontexten

och den teknologiska framfarten som ständigt förändras inom ramen för IT-projekt.

45 (50)

6 Avslutning

6.1 Slutsats

Syftet med detta examensarbete var att belysa hur riskhanteringsarbetet bedrevs inom ramen

för IT-projekt. Denna kunskap kan nyttjas av företag som vill få en ökad förståelse om

riskhantering samt dess svårigheter. Frågeställningarna kommer att behandlas i den ordning

som de förekommer i avsnitt 1.4.

Riskhantering inom IT-projekt bedrivs av samtliga tillfrågade intervjuobjekt som en del av

projektstyrningen, således råder det inga tvivel om den fundamentala kunskapen om

arbetsgången kring riskhantering. Däremot förkommer vissa fluktuationer gällande

momenten för riskhanteringsarbete som skiljer sig åt mellan projektledarnas utsagor.

Riskhanteringsarbetet påverkas av interna såväl som externa faktorer vilket ökar

komplexiteten i form av att hantera förändringar som uppkommer under projektets gång.

Erfarenheter och kunskap är två viktiga egenskaper hos projektledare för att kontinuerligt

revidera risker samt att involvera intressenter löpande genom projektets gång. För att

hantera förändringar inom IT-projekt arbetar projektledarna efter det agila

tillvägagångssättet där arbetet med risker är inkluderade i viss mån. Det råder en viss

samstämmighet hos informanterna att IT-projekt tenderar att bli komplexa samt att det finns

svårigheter med att bearbeta kunders förändrade krav under projektets gång. Kunden utgör

en risk i sig när dennes kunskap och insyn i vad som behöver göras är varierande. Vidare

går det att konkludera att riskhantering prioriteras ned till förmån för andra åtgärder inom

IT-projekt samt att kunskapsöverföringen från tidigare IT-projekt är något som förbises.

6.2 Förslag till fortsatt forskning

Denna studie har enbart inriktat sig mot hur riskhanteringsarbetet ser ut i praktiken samt

vilka svårigheter som infinner sig vid riskhantering Under studiens gång har det urskilts

några relevanta områden för vidare forskning.

Under arbetets gång har det framkommit att det skulle vara relevant att utgå ifrån kundens

infallsvinkel i arbetet med riskhantering. Hur kunden involveras i riskhanteringsarbetet och

hur pass riskmedveten kunden är. Ett annat förslag till vidare forskning skulle vara att

bedriva en fallstudie hos ett företag som arbetar med riskhantering. En sådan fallstudie

skulle generera en djupare insikt kring ledningens förhållningssätt gentemot riskhantering

och vilka rutiner som de efterföljer i företaget. Vad som också har vuxit fram under studiens

gång är att det skulle vara relevant att undersöka riskhanteringsarbetet utifrån ett

internationellt perspektiv och hur de tillämpar vedertagna principer inom

riskhanteringsområdet. Till syvende och sist skulle det vara intressant med en vidare

forskning kring en fördjupning om scope creep för att förstå dess bakomliggande orsaker

men även dess inverkan på projektets olika faser.

46 (50)

Referenser Agile Manifesto. (2001). Manifesto for Agile Software Development.

http://agilemanifesto.org/ [Hämtad 2017-02-21]

Albertsson, J. & Stjernfeldt, F. (2016). Riskanalysmetod vid implementering av

affärssystem. B-uppsats.

Aloini, D., Dulmin, R., & Mininno, V. (2007). Risk management in ERP project

introduction: review of the litterature. Information & Management, (44), s. 547-567.

Aloini, D., Dulmin, R., & Mininno, V. (2012). Modelling and assessing ERP project

risks: A petri Net approach. European Journal of Operational Research. Vol. 220, s. 484-

495.

Alvesson, M., &Thorell, S. (2011). Intervjuer – genomförande, tolkning och reflexivitet.

Malmö: Liber.

Atkinson, R. (1999). Project management: cost, time and quality, two best guesses and a

phenomenon, its time to accept other success criteria. International Journal of Project

Management, vol. 17, no. 6.

Bakker, K., De, A. Boonstra., and H. Wortmann. (2012). Risk Managements

Communicative Effects Influencing IT Project Success. International Journal of Project

Management.

de Bakker, K., Boonstra, A. & Wortmann, H. (2010). Does risk management

contribute to IT project success? A meta-analysis of empirical evidence. International

Journal of Project Management, vol. 28, no. 5.

Balaji, S., & Murugaiyan, M.S. (2012). Waterfall vs v-model vs agile: a comparative study

on sdlc. International Journal of Information Technology and Business Management, vol.

2.

Bryman, A., Nilsson, B. (2011). Samhällsvetenskapliga metoder. 2nd edn. Malmö: Liber.

Charette, R. (2005) Why software fails. IEEE Spectrum, vol. 42, no 9.

Elmholdt, C. (2006). Cyberspace alternativer til ansigt-til-ansigt interviewet. Tidsskrift

for kvalitativ metodeudvikling, 41:70-80.

Eriksson, L-T & Wiedersheim-Paul, F. (2014). Att utreda forska och rapportera. Uppl, 10.

Stockholm: Liber.

47 (50)

EUR-Lex (2016). EU law and publications.

http://eur-lex.europa.eu/legal-content/SV/TXT/?uri=uriserv%3An26026 [Hämtad: 2017-

04-25]

Galletta, A. (2012). Mastering the Semi-Structured Interview and Beyond: From Research

Design to Analysis and Publication. New York University Press, New York.

Hidding, G, & Nicholas, J. (2017), A new way of thinking about IT project management

practices: Early empirical results, Journal Of Organizational Computing & Electronic

Commerce, 27, 1, pp. 81-95, Business Source Premier.

Imtiaz, A., Al-Mudhary, A. S., Mirhashemi, M. T., & Ibrahim, R. (2013). Critical Success

Factors of Information Technology Projects. World Academy of Science, Engineering and

Technology, International Journal of Social, Behavioral, Educational, Economic, Business

and Industrial Engineering.

Hill, Gerard M. (2010). The complete project management methodology and toolkit, CRC

press, First Edition.

Jacobsen, D-I. (2002). Vad, hur och varför? - Om metodval i företagsekonomi och andra

samhällsvetenskapliga ämnen. Studentlitteratur, Lund.

Jaafari, A. (2001). Management of risks, uncertainties and opportunities on projects: time

for a fundamental shift. International Journal of Project Management, 19.

Kornelius Irfandhi, S. (2016). Risk Management in Information Technology Project: An

Empirical Study, Comtech, Vol. 7, Iss 3, s. 191-199.

Kendrick, T. (2009). Identifying And Managing Project Risk : Essential Tools For

Failure-Proofing Your Project. New York: AMACOM Books.

Kvale, S. & Brinkmann, S. (2014). Den kvalitativa forskningsintervjun. Studentlitteratur,

Lund.

Langemar, P. (2008). Kvalitativ forskningsmetod i psykologi. Malmö: Liber AB.

Patel, R. & Davidson, B. (2011). Forskningsmetodikens grunder: att planera,

genomföra och rapportera en undersökning. 4. uppl. Lund: Studentlitteratur.

Rausand, M (2011). Risk Assessment: Theory, Methods, And Applications, n.p.: Hoboken,

N.J. : Wiley, c2011.

Shenhar, A. J. & Dvir, D. (2007). Reinventing Project Management - The Diamond

Approach to successful growth and innovation, Harvard Business School Press, USA.

48 (50)

State of Scrum Report, (2015). How the world is succesfully applying the most popular

Agile approach to projects. Scrum Alliance.

https://www.scrumalliance.org/scrum/media/scrumalliancemedia/files%20and%20pdfs/sta

te%20of%20scrum/scrum-alliance-state-of-scrum-2015.pdf [Hämtad 2017-02-14]

Talet, A. N., Mat-Zin, R., & Houari, M. (2014). Risk Management and Information

Technology Project. International Journal of Digital Information and Wireless

Communications, 4(1), 1- 9.

Taylor, H., Artman, E., & Woelfer, J. J Inf Technol. (2012). Information technology

project risk management: bridging the gap between research and practice. Vol. 27, s. 17-

34.

The Standish Group, (2013). CHAOS manifesto.

http://www.immagic.com/eLibrary/Archieves/General/Genref/S130301C.pdf [Hämtad

2017-02-04]

Tonnquist, B. (2014). Projektledning. uppl, 5. Stockholm: Sanoma utbildning AB.

Toscha, A. (2012). En introduktion till organisations-övergripande riskhantering. Lund:

Studentlitteratur.

Wendestam, L. (2008). Ta kontroll över riskprojekt - PRM-metoden - ett praktiskt

arbetssätt för riskhantering i projekt. Stockholm: Ekerlid.

Rausand, M. (2011). Risk analysis, assessment, and management. Risk assessment: -

Theory, Methods, and Applications. n.p.: Hoboken, N.J. : Wiley, c2011.

Institutionen för

informatik

351 95 Växjö / 391 82 Kalmar

Tel 0772-28 80 00

Lnu.se

Bilagor Bilaga 1 - Intervjufrågor

Riskhantering

Har företaget något bestämda mallar för hur risker ska hanteras? – Vilken? Hur ser den

ut?

- Arbetar hela företaget efter samma modell med risker i projekt?

- Hur hanteras risker i projekt av företaget?

Hantering av dokumentation vid riskhantering

- Vilka dokument görs? – varför?

- När används dem?

- Hur ser hantering av åtgärdsplaner ut?

Tillämpar ni systemutvecklingsmodell för att hantera risker i projekt, formell/informell?

- Vilken/vilka befintliga modeller använder ni vid systemutveckling?

- Finns det risk inbyggt i systemutvecklingsmodellen?

Riskhantering

- Vilka moment ingår i ert arbete kring risker från början till slut. -Tillvägagångssätt

- Vad anser du är de viktiga aspekterna i varför man bör använda sig av riskhantering?

- Har du identifierat några kritiska framgångsfaktorer?

- Vilka svårigheter anser ni att det finns med riskhantering?

- Vilka svårigheter har ni stött på när ni arbetat med riskhantering?

- Hur arbetar ni med prioritering av risker?

- Hur mycket tid läggs på risker?

Projekt genomförda enligt plan

- Vanligaste orsakerna och bristerna till att projekt försenas?

- Har ni någon gång avbrutit ett projekt i förtid?

- Vad är ett misslyckat projekt enligt dig?

Hur bedömer ni förbättringspotentialen inom riskhantering?

- Finns det något ni anser behöver förbättras? Hur ska man tänka?