riskhantering inom it-projekt - divalnu.diva-portal.org/smash/get/diva2:1110720/fulltext01.pdf ·...
TRANSCRIPT
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?