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
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
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).
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
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.
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.
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.
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.
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).
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.
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
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
Konsekvens
Analys
Design
Development ment
Testing
Implementation
Maintenance
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).
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.
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å
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).
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.
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
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.
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.
● 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).
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.
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
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.
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.
