• No results found

Svårigheter med riskhantering

In document Riskhantering inom IT-projekt (Page 33-40)

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.

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

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

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

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

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

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.

5 Diskussion

In document Riskhantering inom IT-projekt (Page 33-40)

Related documents