Anvendelse af iterativ risikostyring i IT projekter

Anvendelse af iterativ risikostyring i IT projekter En kombination af plandrevne processer og agile erfaringer Af Morten Haugaard Boldsen Vejleder: Tina Blegind Jensen Forår/sommer 2008 Kandidatafhandling Cand.merc.(it) Aarhus School of Business, University of Aarhus

English summary An IT project is a complex matter including many potential risk areas. The Standish Group International has for several years created reports stating disappointing statistics of IT project successes. In 2006 only 35 percent of all software projects were characterized as successes leaving 19 percent as complete failures and the remaining 46 percent as challenged. This combined with the fact that several authors recognize risk management as a crucial discipline for obtaining successes calls for a renewal of our view on risk management procedures in order to improve future results for IT projects. This thesis wishes: to examine the applicability of iterative risk management in IT projects. In order to seek clarification on this, the following sub-questions: Which risk management processes/methods does the literature state for plandriven and agile IT-projects? In the light of existing methods, how can a model for risk management, that takes the best of both worlds, be set up? What is the value of making iterative risk management in relation to the success in IT-projects? (Translated from Danish) Trough a thorough review of risk management literature for plan-driven and agile IT projects a large dissimilarity appeared between the two views of the world. Processes and explicit handling of risks through control tools are in focus in plan-driven projects whereas agile projects handle risks implicitly in the development methods. This is among other things possible through iterative deliveries and close customer collaboration which pick up risk indications early in the process. In this way, the thesis has reviewed and considered acknowledged literature for risk management on plan-driven and agile projects and based on this created a nuanced risk management process model. The process model is iterative by nature and consists of the sub-processes Risk pre-work, Risk identification, Risk analysis, Risk priorization, Risk reporting, Risk planning, Risk handling and Risk monitoring (all translated from Danish). The model also dictates production of two types of documents Risk plan and

Risk register. Furthermore a number of positively influencing project factors is presented, which will keep the probability of risks occurring at a minimum. These are small requirements, iterative processes, frequent feedback, low complexity, small project group, strict test-regulations, close customer collaboration and frequent partial deliveries. In the model treatment of individual risks are separated in order to increase focus possibilities for the assigned risk owners. The process model is also generic by nature which expresses itself in the fact that the operating organization on its own can plan the level of intensity, scope, character etc. that it wishes to use throughout the risk process. That way the process is always completely adapted to the organizations context and culture. Part of the process model is confirmed through comprehensive case work in the company AarhusKarlshamn. Especially the iterative aspect of the risk management measuring approach is tested and the applicability of the method is highly confirmed by the case project group. The mere presence of a repeated valuation of risks is according to the project leader a contributory factor in increasing focus in the project. However, there remain still several untreated areas of the model that has not been confirmed by the case and these are therefore unclarified as to practicability. The case also questioned the approach in more than one effect. For instance the risk assessments show to be more subjective than anticipated. In case of similar subjective selection of relevant risks for handling, the purpose of the risk process can be destructed. Also criticism was raised concerning the positively influencing project factors as these, in essence of their agile nature, favor project quality goals over time and budget goals. The thesis has in this effect produced a contribution to the existing risk management literature and in a yet unseen way it combines views from the plan-driven and the agile project processes. This results in an interesting, but still unverified, conclusion with the intention of implying that the two IT project worlds have still to learn from each other in order to increase the amount of project successes in the future.

Indholdsfortegnelse 1 Indledning... 3 1.1 Argumenter for problemområdet... 3 1.2 Problemformulering... 5 2 Metodemæssige overvejelser... 5 2.1 Videnskabsteoretisk tilgang... 5 2.2 Fremgangsmåde... 7 3 Litteraturstudie... 9 3.1 Risiko-processer i plandrevne IT-projekter... 11 3.1.1 Risikostyring i en PMBOK tankegang... 14 3.1.2 Risikostyring i en Ferma tankegang... 19 3.1.3 Risikostyring i Project Management for Information Systems... 23 3.1.4 Risikostyring i Software Project Management... 26 3.2 Risiko-processer i agile IT-projekter... 29 3.2.1 Den agile tankegang... 29 3.2.2 Risikostyring i agile projekter... 31 4 Opstilling af nuanceret procesmodel... 35 5 Case: iterativ risikostyring i et AAK projekt... 41 5.1 Virksomhedsbeskrivelse og IT-projektledelse i AAK... 42 5.2 Projektet og metode for undersøgelse... 44 5.3 Forventninger... 46 5.4 Resultater af undersøgelsen... 48 5.4.1 Årsager til risicienes udvikling over tid... 48 5.4.2 Fordele/ulemper ved at udføre iterativ risikostyring... 53 5.4.3 Respondenternes forskelligartede vurderinger... 55 6 Diskussion... 58 6.1 Kritik af den nuancerede procesmodel... 58 6.2 Procesmodellens anvendelsesområde... 59 6.3 Validitet i undersøgelsen... 60 7 Konklusion... 61 8 Perspektivering... 62 8.1 Generaliserbarhed... 62 8.2 Elementer til videre forskning... 63 9 Litteraturliste... 64 10 Appendix... 67 1

10.1 Appendix: Projekters succesrate... 68 10.2 Appendix: Vandfaldsmodellen... 69 10.3 Appendix: PMBOKs procesflow diagram... 70 10.4 Appendix: Boehms RBS fortolket af Hughes & Cotterell (2002)... 71 10.5 Appendix: Principper for Agile Manifesto... 72 10.6 Appendix: Projektdokumentation for Citrix-projektet... 73 10.7 Appendix: Resultater fra risikovurderingerne i Citrix-projektet... 79 10.8 Appendix: Respondenternes individuelle totalscore... 100 10.9 Appendix: Transskribering af interviews... 101 10.9.1 1. Risikovurdering MA 10-01-2008... 101 10.9.2 1. Risikovurdering EV 11-01-2008... 105 10.9.3 1. Risikovurdering CS 11-01-2008... 108 10.9.4 2. Risikovurdering MA 13-02-2008... 111 10.9.5 Anvendelsesvurdering indtil videre TJ 13-03-2008... 113 10.9.6 3. Risikovurdering CS 27-03-2008... 116 10.9.7 3. Risikovurdering EV 07-04-2008... 119 10.9.8 Endelig anvendelsesvurdering TJ, MA, CS, EV 09-05-2008... 122 2

1 Indledning 1.1 Argumenter for problemområdet Den stigende usikkerhed, som mange organisationer erfarer på de fleste forretningsområder i dag, er et klart resultat af en stærkt foranderlig verden. Denne usikkerhed og foranderlighed gælder ikke mindst for forretningsområder, der agerer indenfor en informationsteknologisk- (IT) og udviklingsorienteret verden (Cadle & Yeates, 2004). Såvel organisationer, der udvikler ny teknologi, som organisationer, der anvender denne teknologi, skal kontinuerligt varetage, at deres udviklingsretning er den mest gunstige og vil medføre de bedste fremtidige muligheder. Og det er meget svært at forestille sig en organisation, som i dag ikke anvender IT i en eller anden grad. Dermed medfører usikkerheden tillige et stort konkurrenceaspekt i organisationernes forretningsstrategier. For at være succesfuld i en dynamisk verden, er det nødvendigt at tilpasse sig og agere på konstante forandringer, og den organisation som mestrer dette bedst, vil ofte være den, som i det lange løb opnår flest konkurrencemæssige fordele. IT-projekter varierer i størrelse, varighed, kompleksitet, mål og mange andre dimensioner og udviklingshastigheden bevæger sig i større grad mod spring frem for tidligere kontinuerlige forandringer (Christensen & Kreiner, 2003). Således uanset projektets natur vil det ufravigeligt indeholde et risikoaspekt, idet alle IT-projekter kan blive ramt af uforudsete hændelser. Ifølge Standish Group International, Inc. (2006) er der grund til at behandle risici, idet kun 35 procent af alle softwareprojekter startet i 2006 kunne betegnes som succesfulde, hvilket vil sige, at de blev færdiggjort til tiden, på budgettet og mødte brugerkrav. 19 procent af projekterne var direkte fiaskoer, mens de resterende 46 procent var udfordret, hvilket betyder, at de ikke levede fuldt op til kravene 1. I appendix 10.1 ses, at siden 1994 er udviklingen gået i positiv retning, men alligevel er der stadig stor grund til at forfølge endnu bedre styring af risici. Mange forfattere har tillige bekræftet vigtigheden af grundig risikostyring i IT-projekter. Der er et stærkt positivt forhold mellem omfanget af risikostyring foretaget i projekter og projekternes succesgrad (Smallman & Elkington, 2002). Ligeledes er 1 Udviklingen i succesrater fra 1994 til 2006 kan ses i appendix 10.1. Her ses ligeledes definitioner på succeskategorierne. 3

risikostyringsinitiativer korreleret med overholdelse af tids- og budgetmål (Raz et al., 2002). Store pengesummer bliver således fortsat spenderet på projekter, hvis mål aldrig bliver realiteter (Jensen, D., 2008), og dette må være den primære motivation for en bedre risikostyring i IT-projekter. Efterhånden har risikostyring eksisteret i adskillige år og flere teknikker til udførelse heraf er udviklet. På trods af dette grundige forarbejde, har mange organisationer endnu ikke adapteret anvendelsen af teknikkerne og endnu flere anvender kun en lille del af de metoder og værktøjer, der er tilgængelige i litteraturen (Raz et al., 2002). I praksis benytter mange organisationer en klassisk IT-projekttilgang, når det angår usikkerhed, hvilken består af at etablere et overblik over risici tidligt i projektforløbet og derefter fastlægge en handlingsplan på baggrund heraf. Erfaringer med denne fremgangsmåde viser, at risici tenderer til hurtigt at blive forglemt, hvilket fører til de førnævnte lave succesrater. IT-projekters udvikling mod teknologibegejstring og resultatorienterings-iver som de primære drivkrafter frem for grundig forretningsanalyse og risikoetablering driver tankerne imod øget agilitet i markedet, hvilket muligvis kan være med til at understøtte den lave succesrate, såfremt dette ikke angribes korrekt 2 (Rostgaard, 2006). Agile projekter er nemlig blandt andet kendetegnede ved nedprioritering af struktur, design og dokumentation. Omvendt kan agilitet muligvis være en positiv faktor for håndtering af risici, idet agile udviklingsmetoder ofte er baseret på iterativitet, der kan være med til at fange problemområder tidligt i et udviklingsforløb 3. Dette sker eksempelvis på baggrund af, at mange agile udviklingsmetoder dikterer hyppige leverancer og justeringer til kunden i projektet, og fokus vil således ofte intensiveres i denne type ITprojekter. Således kan der være et behov for i øget grad at revurdere risici i løbet af et projektforløb for at opnå en gunstigere risikostyring. 2 Begrebet agilitet benyttes i denne afhandling om IT-projekter, som i en given grad anvender en agil tilgangsvinkel. Agile projekter karakteriseres blandt andet ved at være fleksible, simple og have hyppige leverancer (Agile Manifesto, 2008). Den agile tankegang belyses nærmere i afsnit 3.2.1. Jo mere agil tilgangsvinkel, der anvendes, jo højere agilitet. 3 Begrebet iterativitet benyttes i denne afhandling om IT-projekter, som i en given grad anvender en iterativ tilgangsvinkel, hvor arbejdsopgaver gennemføres af flere omgange. Jo mere iterativ tilgangsvinkel, der anvendes, jo højere iterativitet. 4

1.2 Problemformulering Med udgangspunkt i ovenstående erfaringer ønskes: at undersøge anvendeligheden af iterative risikostyringsmetoder i IT-projekter. For at søge afklaring på dette opstilles følgende underspørgsmål: - Hvilke processer/metoder til risikostyring opstiller litteraturen i forhold til plandrevne og agile IT-projekter? - På baggrund af eksisterende metoder, hvordan kan en model for risikostyring, som tager det bedste fra begge verdener, da se ud? - Hvad er værdien af at foretage iterativ risikostyring i forhold til IT-projekters succes? I afsnit 2 beskrives metodemæssige overvejelser omkring, hvordan besvarelsen af disse spørgsmål søges løst. 2 Metodemæssige overvejelser 2.1 Videnskabsteoretisk tilgang Denne afhandling skal opfattes som et bidrag til tidligere forskningsresultater inden for projektledelsesfeltet. For at placere mine grundlæggende antagelser som forfatter i forhold til samfundsvidenskaben afklares her den videnskabsteoretiske tilgang, som afhandlingen vil antage. Eksisterende projektledelseslitteratur og herunder litteratur om risikostyring har gennemgået flere iterationer for at være, hvor den er i dag. Selvom mange års forskning har etableret adskillige anerkendte teorier, oplever praktikere stadig, at arbejdet med projekter udfordres rigeligt og endda ofte fejler (Standish Group International, Inc., 2006). Dette kunne lede tankerne hen på, at eksisterende teorier er fejlbarlige (Bhaskar, 1997) og der er således et behov for fornyede teorier og mere tilgængelige 5

praktiske muligheder. Virkeligheden består ikke blot af observationer af begivenheder og fænomener, men også af mekanismer, kausale sammenhænge og tendenser (Bhaskar, 1997). Dvs. at vi opererer i en virkelighed, som kan påvirkes og som afhænger af indbyrdes kontekster. Dermed ønsker jeg at tage udgangspunkt i den eksisterende forskning, og herudfra udvikle og udforske både teorierne og anvendelsen heraf og på denne baggrund nuancere udsagnene. Således fokuseres der indirekte på at forklare de underlæggende mekanismer og påvirkninger, som styrer praktikernes dagligdag og som kan påvirke deres adaptation af teoriernes indhold. Samtidig skal det holdes for øje, at organisationernes verdener er forskellige og det kan dermed være svært at etablere ét samlet nuanceret udsagn, som passer på alle organisationer. Dog bør det være muligt at generalisere og definere nogle gentagne strukturer, mekanismer og tendenser, som hersker indenfor en ITprojektledelseskontekst, og på baggrund heraf opstille begrundede antagelser (abduktion). Det skal understreges, at der ved afhandlingens indledning endnu ikke var udviklet et forventet resultat, men at undersøgelserne undervejs og analyserne af den eksisterende teori skulle danne udgangspunkt for resultaterne løbende i arbejdsprocessen. Således vil afhandlingen danne et eksplorativt studie. Der er dog en tilstedeværende forventning om, at eksisterende teorier ikke tilstrækkeligt tydeliggør vigtigheden af iterativitet i risikostyringen, hvilket også afspejles i praksisanvendelse. Anvendelsen af denne kritisk realistiske tilgang betyder, at jeg vil se på og acceptere de realiteter, som utvivlsomt eksisterer indenfor projekters risikostyring i dag, både ud fra litteraturens og praktikernes synspunkt. Men omvendt vil jeg også forsøge at udfordre disse synspunkter, idet den kritiske realist anerkender, at virkeligheden ikke kan begribes totalt (Heldbjerg, 2003). Således tager jeg udgangspunkt i de objektive strukturer, som litteraturen benytter og henviser til, men med udgangspunkt i praktikernes erfaringer og mine egne værdier forsøger jeg subjektivt at udforske og udfordre disse strukturer for at øge egen og læserens begribelse af virkeligheden. Dermed ønsker jeg med afhandlingen at udforske antagelserne fra litteraturen og bidrage med en procesmodel, der delvist afprøves og diskuteres på baggrund af en case. På den måde skabes større indblik i en uopnåelig sandhed. I denne tilgang forlades verifikation og falsifikation i den positivistiske forstand til fordel for anvendelse af kvalitative vurderingskriterier (Heldbjerg, 2003). 6

På praktisk niveau kommer denne kritisk realistiske tilgang til udtryk i en case, hvor en organisation med lav erfaring med risikostyring afprøver nøje definerede iterative risikohåndteringsmetoder. Dette skal primært bidrage til at afdække teoriernes anvendelighed i praksis og samtidig afsløre faktorer, som man skal være opmærksom på i processen. I forskerrollen vil jeg såvel observere udviklinger, som jeg vil udfordre og interagere med forskningsobjektet (her en projektgruppe). Dette vil fungere som et processtudie, hvor fokus er på udviklingen i projektet, de tilhørende risici og håndteringen af disse. Der benyttes hovedsagligt kvalitative undersøgelsesinstrumenter i form af interviews for at belyse problemstillingen. 2.2 Fremgangsmåde Som tidligere nævnt omfatter afhandlingen flere undersøgelsesaspekter såvel teoretiske som empiriske. I dette afsnit gennemgås strukturen i afhandlingen og endvidere fremhæves argumenter for valg undervejs. Afhandlingen er opbygget omkring flere datakilder og følger tre skridt i analyse og diskussion: 1. Litteraturreview af eksisterende forskning omhandlende processer i plandreven og agil risikostyring 2. Opstilling af nuanceret procesmodel på baggrund af erfaringer fra litteraturreview 3. Casearbejde delvist afdækkende anvendeligheden af den nuancerede procesmodel Først udføres et grundigt litteraturreview af risikostyring. Mange forskere har beskæftiget sig med emnet, og behandler det sammenligneligt. Der fokuseres på processen, udviklingen i risikostyring og faktorer, som kan påvirke succesraten af den foretagne risikostyring. Eksisterende og anvendte teorier på området belyses, sammenholdes og diskuteres. I litteraturreviewet adskilles betragtninger vedrørende plandreven og agil projektudvikling. Dette gøres for senere at kunne sammenligne arbejdsmetoder og procesmodeller i projekter for de to udviklingstyper. På det agile område er det hidtidige litterære bidrag for risikostyring dog meget begrænset. Dette skyldes sandsynligvis blandt andet, at det agile manifest og den agile tankegang bygger 7

på nogle grundlæggende anderledes værdier, som netop ikke iscenesætter planer og styring i samme grad som plandrevne projekter (Agile Manifesto, 2008). Derfor søges håndteringen af problemstillingen belyst gennem analyse af agile udviklingskoncepter, foredrag og praktiske erfaringer. Således med udgangspunkt i denne række betragtninger, som sammenfattende vurderer den eksisterende teori for risikostyring, opstilles en nuanceret procesmodel, som varetager de mest gunstige betragtninger fra den plandrevne og den agile verden. Dernæst beskriver jeg gennemførslen af en case i organisationen AarhusKarlshamn (AAK), der skal klarlægge anvendeligheden af den nuancerede teori. Således foretages en undersøgelse i en større organisation, hvor et mindre IT-projekt udgør datagrundlaget. Det skal her nævnes, at frembringelsen af denne afhandling har været en work-in-progress, og ved casens indledende etablering var den nuancerede model endnu ikke opstillet. Således var det heller ikke muligt at påvise den komplette models anvendelighed, men blot aspekter af den, som indledningsvist var forudantagne. Her kan det afsløres, at en af mine antagelser til problemstillingen omkring utilfredsstillende succesrater i IT-projekter var, at man ikke aktivt re-risikovurderer og udvikler nye handlingsplaner løbende i projektet og dermed ikke fanger problemerne i opløbet. I praksis formår organisationerne ikke tilstrækkeligt at benytte denne iterativitet. Metoden vil dermed blandt andet omfatte etablering af en struktureret spørgeguide, som varetager de mest essentielle potentielle risikoområder inden for projekttypen samt selve den aktive vurdering, som foretages iterativt. Slutteligt samles der op på de erfaringer, der er draget i teorigennemgangen, opstillingen af modellen og den praktiske case. Således sammenfattes afhandlingen omkring en kombination af de teoretiske retningslinjer, som forskningen for plandrevne projekter hidtil har leveret, teorier og erfaringer fra agile projekter, en forskningsbidragende procesmodel for risikostyring og de praktiske erfaringer, som er gjort på baggrund af casen. Afhandlingen er struktureret således, at afsnit 3 beskriver og analyserer den litteratur, som danner grundlag for risikostyring i dag i plandrevne og agile IT-projekter. Afsnit 4 opstiller en nuanceret processuel model for risikostyring og afsnit 5 afprøver nogle af modellens aspekter gennem en case hos AAK. I afsnit 6 diskuteres aspekter af 8

resultaterne og validiteten i afhandlingen og afsnit 7 konkluderer afhandlingens vigtigste punkter. Slutteligt perspektiverer afsnit 8 med udgangspunkt i generaliserbarhed og aspekter til videre forskning. 3 Litteraturstudie Som nævnt i indledningen er IT-verdenen under konstant forandring, hvilket udløser stor usikkerhed i projekter, som fokuserer primært på IT-produkter. Selvom risiko og usikkerhed ofte benyttes i samme forbindelse, er det dog vigtig at adskille begreberne. Risikoelementer er forbundet med usikkerhed, men ikke alle usikkerheder er risici. Risici betegnes oftest om ikke-ønskelige udfald eller som Boehm (1989) udtrykker det: Muligheden for tab, skade, ulempe eller ødelæggelse - og det er forebyggelsen af dette, som afhandlingen her omhandler. På trods af adskillige års forskningsarbejde mod at opnå tilnærmelsesvis optimal styring af risici er disciplinen alligevel den mindst udøvede blandt de forskellige projektledelsesværktøjer (Kwak & Ibbs, 2000). Manglen på identifikation, forståelse og styring af risici er ofte bebrejdet som en væsentlig bidragsgivende faktor til ITprojektfiaskoer (Boehm, 1991), (Barki et al., 1993). Flere studier påstår endvidere, at dårlig risikostyring er skyld i de mest udbredte projektudfordringer, såsom forsinkelser, budgetoverskridelser og manglende opfyldelse af brugerkrav (Barki et al., 1993), (Drummond, 1996). Lyytinen et al. (1998) finder, at fordelene ved risikostyring i softwareprojekter er, at praktikere, ved at benytte dette, bedre kan fokusere på mange aspekter af problematiske situationer og det hjælper med til at tydeliggøre potentielle kilder til fiasko. Endvidere finder de, at risikostyring sætter sammenhæng mellem potentielle risici og mulige handlinger samt, at risikostyring faciliterer en fælles opfattelse af projektet blandt dets deltagere. Med dette i baghovedet, hvad er det så, der gør, at organisationerne ikke benytter de værktøjer, som er til rådighed? Boehm & DeMarco (1997) nævner, at det at indrømme, at et projekt er berørt af risici sidestilles med selvopgivelse og nederlagspolitik. I mange organisationer findes en tendens til, at det er ilde set at bringe potentielle problemer frem for ledelsen, og den negative opmærksomhed afholder formentlig mange fra at fokusere på risici. Ligeledes nævner de, at der er et problem i at have dokumenteret en grundig risikoplan, såfremt projektet 9

alligevel fejler, idet man i så fald burde have imødekommet de givne risici. Dette bør dog tolkes som en misforståelse af risikostyring, idet disciplinens mål ikke er at fokusere på projekters negative aspekter, men gennem fokus på potentielle udfordringer minimere risikoen for fiasko. Den klassiske projekttrekant består af tid, økonomi og kvalitet (Project Management Institute, 2004). Disse udgjorde de primære faktorer, når projekter skulle forandres i den tidlige projektledelseslitteratur, og anerkendes faktisk til stadighed. Dog medtager flere forfattere et fjerde element omfang. I den klassiske projekttrekant medgår omfang i elementet kvalitet. Såfremt kvaliteten (eller omfanget) skulle øges, ville det betyde en tilsvarende forøgelse af tiden eller budgettet (begge er nok mest sandsynligt). Såfremt levering skulle ske tidligere, ville det betyde flere ressourcer eller lavere kvalitet. Og tilsvarende for økonomifaktoren. Projekttrekanten har dog senere vist sig at tåle udvidelser til at inkludere faktorer som risiko, menneskelige ressourcer, kommunikation, interessenter deslige, som alle påvirker graden af projektsucces. Boehm (1991) har undersøgt projektfiaskoer og finder, at problemerne kunne have været undgået eller stærkt reduceret, hvis projekter havde haft tidlig og klar fokus på at identificere og løse høj-risiko elementer. Kwak & Stoddard (2004, s. 916) siger endvidere, at Effective risk management is the most important management tool a project manager can employ to increase the likelihood of project success. Således understreges vigtigheden af risikostyring igen og igen som en afgørende kritisk faktor for at opnå succes i IT-projekter. I de følgende afsnit gennemgås eksisterende anerkendt litteratur vedrørende arbejdsprocesserne benyttet i risikostyring af IT-projekter. Der adskilles mellem plandrevne projekter og agile projekter. Årsagen til dette er, som tidligere nævnt, at agile projekter benytter en grundlæggende usammenlignelig udviklingsmodel i forhold til plandrevne projekter. Endvidere fokuserer agile projekter her udelukkende på softwareudvikling, hvor plandrevne projekter også kan omfatte andre typer IT-projekter, som eksempelvis indførsel af en ny hardwareplatform. Det ligger uden for denne afhandlings problemområde at behandle, hvilken type IT-projekt, der er egnet i hvilke situationer. 10

3.1 Risiko-processer i plandrevne IT-projekter IT-projekter udført i et klassisk plandrevet regi vurderes her som strukturerede projekter, bygget op omkring en planlagt sekventiel analyse/design tankegang, hvor så meget som muligt planlægges tidligt i processen. Indenfor softwareudvikling er vandfaldsmodellen den mest anvendte plandrevne udviklingsmodel, hvor projekter gennemløber faserne system requirements, software requirements, analysis, program design, coding, testing og operations (Royce, 1970) 4. I senere versioner af vandfaldsmodellen og andre plandrevne modeller er der indført et aspekt af iterativitet, som tillader at gå tilbage i faserne og udbygge eller ændre tidligere arbejde. Denne måde at arbejde på lægger samtidig op til tilladelse af en stringent risikostyring. I plandrevne IT-projekter består risikostyring af en række proaktive handlinger (Gray & Larson, 2006). Metoder til risikostyring drejer sig om forebyggende at tage handlinger, således sandsynligheden for, at opståen af operationer forbundet med negative konsekvenser, minimeres. Succesfuld risikostyring hjælper dermed med til, at projektlederen bedre kan tage hånd om fremtidige udfordringer, og således i højere grad leve op til budgetmål, tidsestimeringer og kvalitetskrav. Dermed er det også essentielt, at projektet så tidligt som muligt påtager sig opgaven med at håndtere risici. Figur 1 på side 12 afspejler her de fordele, ifølge Gray & Larson (2006), der er ved at angribe problemstillinger så tidligt i projektet som muligt. Jo tidligere i projektforløbet man er, jo større er sandsynligheden for, at udfordringer opstår. Det er her, de vigtigste beslutninger træffes. Det er også her, at man smertefrit (og omkostningsfrit) kan rette op på problemerne, idet man endnu har håndteret faktisk igangsættelse af projektet. Jo længere projektet fremskrider, jo dyrere bliver fejlene at rette op på. Her er der allerede spenderet mange penge og meget tid, og opståede fejl vil derfor betyde forspildt tid plus ekstra tid på at rette op på fejlen. Således er der klare fordele ved at arbejde aktivt med potentielle problemområder og opdage eventuelle fejl så tidligt som muligt i processen. 4 Grafisk fremstilling af vandfaldsmodellen ses i appendix 10.2. 11

Lav Høj Tid Sandsynlighed for at problem opstår Omkostninger ved at rette op på problem Figur 1: Risikoomkostninger og sandsynlighed gennem et projekts livscyklus - (egen tilpasning fra Gray & Larson (2006)). Dettee understreges yderligere af det fundamentale dilemma, som komplekse projekter underligger, nemlig at beslutningers betydninger er betragteligt højere tidligt i projektet, men desværre er tilgængeligheden af den nødvendige information, som beslutningerne skal træffes på baggrund af, også lavest i projektets tidlige start (Mikkelsen & Riis, 2006). Når vi ser på den plandrevne risikostyringsproces, er der ganske mange bud på, hvilke faser processen skal inkludere og hvorledes de skal udføres. Dog er der en vis sammenhæng i de bagvedliggende tanker og handlinger. Boehm (1991) er meget citeret for forskning om risikostyring, og Boehm identificerer følgende faser i styringsprocessen (oversat fra engelsk): Risikoidentifikation, risikoanalyse, risikoprioritering, risikoplanlægning, risikohåndtering og risikoovervågning. I forsøget på at generalisere på litteraturen i dag er det relevant at benytte Boehms resultater, da de, som nævnt, er yderst anvendte som referenceramme, når risikostyring behandles i forskningsøjemed. Dog har Boehms processer efterhånden eksisteret i nogle år, og det er derfor hensigtsmæssigt at vurderee nogle nyere resultater, for at tage hensyn til eventuelle ændringer, der måtte have været i forhold til Boehms daværende verdensbillede. I Tabel 1 på side 13 findes et overblik over, hvorledes nyere projektledelseslitteratur ser på risikostyringsprocesserne i dag. Overblikket er opstillet i 12

Project Management Institute (2004) Federation of European Risk Management Associations (2003) Cadle & Yeates (2004) Hughes & Cotterell (2002) - The Project Management Body of Knowledge - Standarden for risikostyring - Project Management for Information Systems Risikoforarbejde Risk Management Planning Plan risk management approach - Software Project Management Risikoidentifikation Risk Identification Risikoidentifikation Identify risks Hazard identification Risikoanalyse Qualitative Risk Analysis* Quantitative Risk Analysis* Risikobeskrivelse Assess risks* Hazard analysis* Risikoprioritering Qualitative Risk Analysis* Quantitative Risk Analysis* Risikokvantificering Risikoevaluering Risikorapportering Assess risks* Plan risk responses* Hazard analysis* Risikoplanlægning Risk Response Planning Risikostrategi Plan risk responses* Risk planning and control* Risikohåndtering Gennemførsel af risikostrategi Carry out risk reduction actions Risk planning and control* Risikoovervågning Risk Monitoring and Control Fortsat risikorapportering Overvågning Tabel 1: Overblik over risikostyringsprocesser i nyere projektledelseslitteratur. (*: Nogle processer fremstår mere end et sted, idet de dækker over indholdet af flere faser). 13

forhold til Boehms processer fra 1991 (disse ses i kolonnen yderst til venstre), dog med tilføjelse af risikoforarbejde, som gennemgangen af litteraturen udløste et behov for. To af de gennemgåede værker i Tabel 1 opstiller en proces, der afspejler det indledende arbejde, som udføres umiddelbart før igangsættelse af den egentlige risikostyring. Disse processer samler jeg således under en sammenfattende overskrift kaldet risikoforarbejde. For bedst at belyse, hvorledes litteraturen generelt anskuer risikostyringsprocessen i dag, har jeg udvalgt og opstillet værker, der kan betragtes som almindelige anvendte, idet de består af to standarder og to lærebøger. Nedenfor gennemgås indholdet af de fire værker hver for sig med speciel fokus på uligheder imellem resultaterne. Boehms førnævnte faser behandles således ikke direkte i denne afhandling, men kun indirekte igennem de tilsvarende faser for de fire værker. 3.1.1 Risikostyring i en PMBOK tankegang The Project Management Body of Knowledge (PMBOK) er en af de mest refererede værker indenfor projektledelseslitteratur, idet den udgør en amerikansk standard for information om og udførelse af projektledelse (Project Management Institute, 2004). Guiden til PMBOK er blevet en anerkendt international standard (IEEE Std 1490 TM - 2003), og henvender sig ikke udelukkende til IT-projekter, men kan også anvendes til bygningskonstruktion m.v. PMBOK anskuer dog risici som både positive og negative muligheder og trusler. Dvs. i forhold tidligere diskussion om forskellene mellem usikkerhed og risiko, antager PMBOK altså usikkerhedsperspektivet, hvor usikre faktorer også kan udvikle sig til projektets fordel. PMBOK vælger dog alligevel at benytte ordet risk om både positive og negative faktorer. Idet denne afhandling udelukkende beskæftiger sig med risici som potentielle negative faktorer, vælger jeg her at se bort fra PMBOKs risikostyring af positive elementer. Ifølge PMBOK består risikostyringsprocessen af seks processer: 1. Risk Management Planning - (fastlæggelse af aktivitetsplan for gennemførelsen af risikostyringsprocessen). 2. Risk Identification - (fastlæggelse af hvilke risici, der kan påvirke projektet og dokumentation af deres karakteristika). 14

3. Qualitative Risk Analysis (prioritering og kategorisering af risici ved vurdering af sandsynlighed og konsekvens). 4. Quantitative Risk Analysis (numerisk analyse af effekten af identificerede risici på projektets målsætninger). 5. Risk Response Planning (udvikle handlinger til reducering af trusler mod projektets målsætninger). 6. Risk Monitoring and Control (opfølgning på identificerede risici, identifikation af nye risici, udførsel af handlingsplaner og evaluering af effektivitet gennem hele projektets livscyklus). Indholdet af ovenstående processer vil blive gennemgået nedenfor, men forinden vil jeg kort berøre iterativiteten i processerne. Hver proces kan forekomme mere end en gang, såfremt projektet er opdelt i flere faser, hvilket stemmer godt overens med den vej litteraturen har bevæget sig senere år. Siden 1995 har der været fokus på, at risikostyring i projekter skal være en kontinuerlig proces gennem hele projekters levetid (Carnegie Mellon, Software Engineering Institute, 2008), (Hughes & Cotterell, 2002). Det er muligt at identificere nogle risici ved projekter opstart, men risicienes karakter og sandsynlighed for opståen vil udvikle sig over et projekts livsforløb. Det er derfor vigtigt hele tiden at videreudvikle på handlingsplaner, for at opnå den største bevågenhed over nye, men også gamle, forandrede risikoområder. PMBOK nævner dog ikke, hvor lang en fase må være, og det kan derfor være uhensigtsmæssigt, at processerne kun må gennemgås én gang pr. fase. Der nævnes dog, at organisationer skal være forpligtet til styre risici proaktivt og konsistent gennem hele projektet. Risk Management Planning er processen, hvor tilgangsvinklen af risikostyringen planlægges og dokumenteres i form af en Risk Management Plan. Her fastlægges et niveau for, hvor intensivt forløbet skal være, og blandt andet hvordan det specifikke projekt bedst håndteres i forhold til gennemsigtighed af undersøgelser. Her sikres ligeledes personlig ansvarshavelse for specifikke områder og en tilstrækkelig opbakning fra ledelsen, således ressourcer til at gennemføre risikostyringen ikke bliver et potentielt problem i sig selv. I processen indgår også, at der skal opstilles en sandsynlighed/omfang-matrix, som fastlægger niveauerne for den kommende 15

risikovurdering. I Risk Management Planning består nogle af inputfaktorerne af organisationens foruddefinerede politikker eller kulturer i forhold til risikotolerance og antal projektdeltagere pr. projekt. Disse er afgørende for, hvorledes risici angribes, idet nogle organisationer er mere villige til at acceptere et vist niveau af risici for til gengæld at spare nogle ressourcer i håndteringen heraf. Andre organisationer er af den opfattelse, at hvis de udelader risikostyring, så har de mulighed for at færdiggøre projektet hurtigere eller fokusere mere på produktet. Disse tilgangsvinkler er dog ligeledes et udtryk for manglende indblik i virkelighedens successtatistikker for gennemførte projekter. Udeladelsen af risikohåndtering er, som tidligere nævnt, den primære faktor for forsinkelser, overskridelse af budget og manglende performance. I Risk Identification processen bør så mange af projektdeltagerne som muligt deltage i afgørelsen af, hvilke risici der kan påvirke projektet og dokumentationen af risicienes egenskaber. Dette minimerer selvsagt risikoen for at forglemme vigtige risikoområder, men det bidrager også til projektdeltagernes ejerskab overfor potentielle risici og det blotte fokus på disse områder bidrager til, at hver enkelt føler ansvar overfor risiciene og vil arbejde videre med håndteringen heraf. Identifikation af risici kan blandt andet ske ved brainstorming, delphi-teknik, interviews, root cause identifikation, SWOTanalyse eller på basis af historiske risici. Sidstnævnte skal dog anvendes med omhu, idet det ikke er muligt at udfærdige en udtømmende tjekliste over potentielle risici. Risk Identification udmunder i et Risk Register, som indeholder alle identificerede risici, potentielle håndteringer, årsager til risiciene og eventuelt en Risk Breakdown Structure (RBS), der opdeler risiciene i kategorier. Qualitative Risk Analysis er processen, hvor risici vurderes og prioriteres for, at projektgruppen kan fokusere på de vigtigste risici og derved effektivt optimere på projektets performance. Risiciene vurderes primært med udgangspunkt i et skøn af sandsynlighed for problemets opståen og omfanget af problemet, såfremt det skulle blive aktuelt. Hver risiko kan vurderes ud fra flere kriterier, således at eksempelvis omkostning, tid og kvalitet vurderes forskelligt. Derudover er der andre faktorer, såsom tidsramme for håndteringseffekt, risikotolerance, symptomer og advarselstegn, som kan påvirke prioriteringen. Hvis en af disse faktorer udgør en skærpende omstændighed, så kan prioriteringen af risikoen opjusteres. Samlet set udmunder Qualitative Risk Analysis i en risikoprioritering, som synliggør vigtigste og mest akutte risici. Endvidere 16

kan risiciene opdeles i kategorier efter projektfase, område der påvirkes eller årsag til risiko. Sidstnævnte kan være meget anvendelig, såfremt flere risici har samme årsag, således at ved at fjerne én årsag, kan flere risici elimineres. Quantitative Risk Analysis er en særdeles detaljeret analyse af de mest kritiske risici udpeget i Qualitative Risk Analysis. Quantitative Risk Analysis bidrager med effektmålinger på individuelle risici og fastlægger, hvorledes de numerisk påvirker projektmålene. Detaljeringsgraden i analyserne er høj, idet der tages højde for usikkerheder i beregningerne. Praktisk kan målingerne foretages som Monte Carlo simulationer, decision tree analyser, følsomhedsanalyser eller expected monetary analyser. Dette er komplekse beregningsmetoder, som ikke beskrives nærmere her, men som på baggrund af analyse af potentielle risici fastlægger mulige udfald for projektet i form af omkostninger, tidsplan, opnåede resultater og tilhørende sandsynligheder. Slutteligt opstilles endnu en detaljeret oversigt i projektplanen over prioriterede risici og deres trusselseffekt på projektmålene. Risk Response Planning udgør processen af at udvikle og fastlægge interventioner, som reducerer truslerne mod projektets målsætninger. Her spiller risikoejeren en stor rolle i at tilrettelægge håndteringer, så de passer ind i projektet i forhold til ressourcer, tidsplan og budgetter. Håndteringsforslagene skal naturligvis understøtte omkostningseffektivitet på den måde, at andre aktiviteter eller personer ikke bliver påvirket, således at projektet samlet belastes af risikohåndteringen. PMBOK identificerer fire muligheder for at påvirke risici: Avoid: Foretag en ændring i projektplanen, så risikoen fjernes. Dette kan eksempelvis være en forøgelse af tidsplanen eller en formindskelse af scope. Andre risici fjernes ved at forøge information, kommunikation eller ekspertise. Transfer: Overfør risikoen til en anden part. Dette kan ofte benyttes ved finansielle risici, hvor betalinger kan påvirkes på mange måder. Garantier, forsikringer og kontrakter er også justerbare, og ved ændringer heri kan risici hurtigt flyttes mellem parter. 17