Praktisk Risikostyring i 5 trin (3/3)

I to tidligere blogindlæg har jeg slået til lyd for at tage risiko i IT-projekter lidt mere alvorligt, end tilfældet er i dag og skønner mere på de medarbejdere der er sensitive overfor risiko.

Her følger de fem trin i en metode til proaktiv, letvægts risikostyring:

  • Identifikation
  • Kvantificering
  • Prioritering
  • Mitigering
  • Gentagelse, igen og igen

Identikation. Ikke umiddelbart en let opgave; Som Storm P sagde "Det er svært at spå, især om fremtiden". Dog er man ikke helt dårligt stillet, når man i organisationen har erfaring fra tidligere projekter/releases at tære på. Selv uden en krystalkugle, er det muligt at indfange en stor del af de truende begivenheder, der kan forhindre en vellykket projekt gennemførelse.

Sæt jer sammen i teamet, eller hvis ikke hele teamet, sørg i hvert fald for at have "pessimisterne" eller "kanariefuglene" på holdet med, da de kan yde uvurderlige bidrag til denne proces.

Gennemgå de sidste par projekter eller releases I har gennemført, og lav en liste over de ting, der gik mindre godt.

Tilføj så til denne liste resultatet af en brainstorm, hvor I forsøger at forestille jer, hvad der kan gå galt indenfor hvert af følgende områder: Teknologi, eksterne forhold og interne forhold

Teknologiske risici kan f.eks være uafprøvede features eller nye versioner af den valgte platform, ukendskab til produkter der skal integreres, lovede opdateringer eller hardware problemer.

Eksterne forhold kan f.eks være stakeholders - vil de stadig støtte projektet? Eller afhængigheder af eksterne leverandører og samarbejdspartnere, samt lovgivning og regler.

Interne forhold vedrører selve projektet: Medarbejdere, har vi problemer, hvis nøglepersoner forlader projektet? Er der nogen kompetencer vi får brug for, som ikke er i teamet?

Hermed er bruttolisten for jeres risikostyring etableret. Er listen meget lang (>50 risici), er det en god idé at reducere antallet. Bed f.eks hver deltager udpege, hvad hun mener er de 10 vigtigste risici. Mange vil se de samme risici, så når I kombinerer valgene, vil listen være betydeligt mindre end den oprindelige.

Når listen er reduceret til en håndterbar mængde, på ikke mere end 25 risici, er næste skridt kvantificering. Hver risiko skal have to estimater: Hvor sandsynligt er det at dette sker? og hvor alvorligt (impact) er det ?

Anvend en skala fra 1-5 til at estimere både sandsynlighed og impact. Gennemgå listen og bed deltagerne med én hånd at vise det antal fingre svarende til deres estimat. Er der stor uenighed, så tag en kort snak og stem igen, og vælg derefter flertallets stemme. De, der kender til Planning Poker vil nikke genkendende til processsen.

Når I har impact og sandsynlighed for hver risko, skal risikotallet beregnes som sandsynlighed x impact (så det er en god ide at starte med at skrive risikolisten ind i et regneark)

Risikotallet er et tal mellem 1 og 25. sorter nu regnearket efter faldende risikotal, hvorefter I har prioriteringsrækkefølgen for mitigering af risici. I starten vil man ofte vælge at arbejde med nogle få af de vigtigste risici fra toppen af listen, men med mere erfaring, kan man indføre en regel om, at alle risici med et risikotal større end f.eks 9 altid skal mitigeres.

Mitigering betyder at mildne. Det kan man gøre på 2 måder: Enten ved at gøre sandsynligheden for at risikoen udløses mindre, eller ved at sørge for, at skulle risikoen blive udløst, vil effekten være knapt så katastrofal.

I nogen tilfælde er det den rette strategi at påvirke sandsynligheden, mens det i andre tilfælde vil være rigtigt at påvirke effekten.

Eksempler: Våbenkapløbet, der varede indtil Sovjetunionens sammenbrud i begyndelsen af 1990'erne, havde den bizarre logik at det var stort set umuligt at forsvare sig mod et nukleart angreb (mindske impact), og at den eneste farbare vej var at mindske sandsynligheden for et angreb, ved at gøre det totalt ødelæggende for modparten at starte et kernevåbenangreb.

Den globale opvarmning er et eksempel på et område, hvor man i vækstens navn, stort set har opgivet at påvirke sandsynligheden for at katastrofer af større og mindre omfang indtræffer, men i stedet arbejder på at formindske de negative effekter, f.eks ved at forbedre kloaksystemerne så de kan klare langt mere vand.

Et par mere IT-nære eksempler kan vi tage fra tabellen ovenover. Det er fra et tænkt projekt, hvor man både både har estimeret en lille sandsynlighed for et server-nedbrud på udviklingsserverne, og en integration med SAP, som vurderes til med stor sandsynlighed at komme til at volde store problemer.

For den første risiko, kan det vise sig være det mest fordelagtige at arbejde på at reducere effekten af et nedbrud, med bedre backup-rutiner og test af indlæsning af backup data, med jævne mellemrum. I tilfældet med SAP integrationen, kan strategien være at mindske sandsynligheden for problemer, ved at starte tidligt på integrationen og finde nogle hardcore specialister man på forhånd ved, man kan trække på med kort varsel.

Det sidste trin er den gentagne overvågning af processen. Med jævne mellemrum skal listen løbes igennem af teamet. Risici på listen skal overvåges for at se om estimaterne har ændret sig, og man skal være på udkig efter nye risici. Det kan man f.eks gøre på et kort møde 1 eller 2 gange om måneden, eller oftere, helt afhængigt af tidshorisonterne for projektet.

Jeg har ofte hørt påstanden at projekter der gennemføres med agil softwareudvikling, ikke har brug for risikostyring, da agil udvikling i sig selv er risikominimerende. Det er både rigtigt og forkert.

Det er rigtigt, at visse ellers almindelige risici er små i agile projekter: Man bliver ikke overrasket med en oplysning om at projektet må skydes flere måneder kun en uge før deadline, og man får heller ikke af vide af kunden, når man laver den store overdragelse, at "det da ikke var det vi bestilte". Problemer af den karakter bliver håndteret langt tidligere i forløbet.

På den anden side kan tendensen til ikke at ville beskæftige sig med den fremtid der ligger mere end 14 dage væk, som man kan opleve i alle agile projekter, men særligt støder på i den mere vulgære aftapning, medføre at nogle alvorlige problemer pludselig kan komme højt op på projektets dagsorden. Derfor kan agile projekter have rigtig stor gavn af letvægt risikostyring, som tilmed meget let kan integreres i eksisterende processer og rytmer.

Se mere om agil udvikling og risikostyring her:

http://michaellant.com/2010/06/04/five-simple-steps-to-agile-risk-manage...

http://www.mountaingoatsoftware.com/blog/managing-risk-on-agile-projects...

Relateret indhold

Kommentarer (2)
Søren Cosmus

I forbindelse med agil udvikling er risikoanalyse en super-god måde at identificere behov for at udføre spikes eller early proof of concepts - som så kan planlægges ind i udviklingsforløbet.

For eksempel udføre faktiske systemintegrationer fra a-z - i lille skala, for at få tidligt bevis for om man skal vælge løsning A eller B.

Vi bruger aktivt risikostyring i forbindelse med agil udvikling. Det giver stor værdi i projekterne.

PRINCE2 har faktisk et udemærket rammeværk til analyse, identificering og styring.

Log ind eller Opret konto for at kommentere