Risk Management AGILE/2I1281/2I4181 2006

Josef Cotaidis

jose-cot@dsv.su.se

10 april 2006

Innehåll

1 Syfte 3 2 Metod 3 3 Introduktion 3 4 Risk Management 3

4.1 Risk Identification . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Risk Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4 Risk Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Agile Risk Management 8 6 Slutsatser 8

1 Syfte

Syftet med detta arbete är att jag ska kunna behärska området risk management, i en sådan grad att jag skall kunna förmedla ny kunskap till mina kurskamrater på ett tillfredsställande sätt, samt att arbetet skall vara till stöd för projektarbetet.

2 Metod

Metoden som jag tänker använda för att uppfylla syftet, är att göra en litteraturstudie av böcker och vetenskapliga artiklar som behandlar ämnet.

3 Introduktion

Trots intensiv forskning inom området programvaruteknik, har man fortfarande problem med att leverera system i tid, inom budget och med önskad kvalitet. Risk Management är ett område bland andra som har utvecklats med avseende att ta itu med dessa problem. Postmortemanalyser av ett antal misslyckade mjukvaruprojekt, visar att problemen hade undvikits om man från början identifierat och hanterat potentiella högriskfaktorer. Om vi tittar från andra hållet så har Barry Boehms[1] observationer indikerat att goda projektledare varit bra på att identifiera och hantera risker, dock utan att medvetet tillämpa någon explicit metod utan oftast intuitivt. Att överlåta riskhanteringen till enstaka individers intuition kan funka ibland, men kan knappast betraktas som en ersättare till en formell, systematisk och konsekvent metod[2]. Detta tack vare att dagens mjukvara tenderar att bli väldigt komplex där många olika sorters risker är involverade.

4 Risk Management

Det finns två typer av övergripande strategier inom RM, nämligen reaktiva och proaktiva[5]. En reaktiv strategi innebär att man tar itu med problemen när de uppkommer. Denna strategi har komiskt kallats för Indiana Jones-strategin, av uppenbara skäl. Konstigt nog är det denna strategi som används, i majoriteten av alla mjukvaruprojekt. I bästa fall kontrollerar man projektet för potentiella risker, mer vanligt är det så att man inte tar några åtgärder alls, fören risken förvandlats till problem.

En reaktiv strategi innebär att risk management utförs långt innan det tekniska arbetet. Potentiella risker identifieras, dess sannolikhet och inverkan beräknas och man rangordnar dem efter vikt. Sedan uträttas en plan för att hantera eller undvika dessa risker var för sig. Slutligen följer man upp hur riskerna utvecklar sig och utför ytterligare analys och planering. Detta arbete kommer att i huvudsak behandla den proaktiva strategin, vilken kommer att beskrivas mer ingående i fortsättningen.

Det finns många definitioner på risk, en kortfattad sådan från Webster´ s dictionary är följande:

”The possibility of loss or injury”

Det råder dock oenighet kring definitionen av risk inom mjukvarukonstruktion. Det man är överens om i alla fall är att egenskaper som osäkerhet/sannolikhet och förlust/konsekvens är involverade[3]. När man analyserar risker är det viktigt att man kan kvantifiera dessa två egenskaper, mer om detta i kapitel 4.2. Det finns olika typer av risker, de kan antingen hota projektet, produkten eller företaget.

Projektrisk Om en sådan risk blir värklighet kommer troligtvis projektplanen hamna i obalans eller kostnaderna öka. Projektrisker omfattar eventuella problem som har att göra med projektets budget, schema, personal, resurser, köpare och krav. Exempel på sådana risker skulle bl.a. kunna vara att någon ur personalen lämnar projektet innan det är klart, eller att nödvändig hårdvara/mjukvara för projektet inte levereras i tid.

Produktrisk Om en produktrisk blir värklighet kommer troligtvis implementationen av systemet försvåras och produktens kvalitet sänkas. Produktrisker omfattar eventuella problem som har att göra med design, implementation, interface, verifikation, uppföljning, tvetydighet i kravspecifikationen och teknisk osäkerhet. Exempel på sådana risker skulle bl.a. kunna vara att fler krav behöver ändras än vad man tidigare trott, eller att specifikationer av interface inte levereras i tid.

Företagsrisk Om en företagsrisk blir värklighet kommer troligtvis projektet eller produkten att sväva i osäkerhet. Företagsrisker omfattar eventuella problem som bl.a. har att göra med att man bygger ett fungerande system som ingen egentligen vill ha, att man bygger ett system som inte längre passar in i organisationens strategi, att man bygger ett system som säljpersonalen inte kan sälja (p.g.a. brister i tekniska kunskaper) eller att en konkurrerande produkt hinner lanseras tidigare.

Bild 1 visar RM-processen, denna består av ett antal steg eller delprocesser enligt följande:

1. Risk Identifikation Eventuella risker identifieras.

2. Risk Analysis Sannolikheten och konsekvenserna för varje risk beräknas.

3. Risk Planning En plan uträttas och dokumenteras för att undvika eller minimera riskernas konsekvenser.

4. Risk Monitoring Riskerna bedöms kontinuerligt och nya planer på hur man ska minimera riskerna uträttas i takt med att ny information blir tillgänglig.

Figur 1: Riskhanteringsprocessen 5

4.1 Risk Identification

Identifiering av risker är det första steget i RM-processen. Man försöker upptäcka så många eventuella risker som man ställs inför som möjligt. Man måste dock tänka på att det kan finnas hur många risker som helst, med olika stora sannolikheter och konsekvenser. Det är därför ingen idé att ta med de risker som har låg sannolikhet att inträffa eller de risker som ger försumbara konsekvenser. Den teknik man kan använda sig av är brainstorming i grupp, gärna bestående av individer med olika intressen, eller så kan projektledarens erfarenhet räcka i vissa fall. Till sin hjälp kan man använda sig av checklistor med eventuella risker som kan förekomma. Checklistor finns det gott om i litteratur och vetenskapliga artiklar, det är viktigt att man inte följer dem slaviskt utan är med och ändrar i dem så att de passar ens egen typ av projekt[5].

Det finns två olika typer av risker för varje kategori som pressenterats i kapitel 4, nämligen generiska och produktspecifika risker[3]. Generiska risker kännetecknas av att de existerar i varje projekt, medan produktspecifika risker kännetecknas av att de är aktuella för det specifika projektet med avseende på teknologi, personalbesättning och omgivning. De bör därför hälst identifieras av personer som innehar kompetens inom respektive teknologi, personalbesättning och omgivning. För att identifiera produktspecifika risker försöker man besvara frågan: ”Vilka speciella karaktärsdrag för denna produkt kan hota vår projektplan?”. Generiska risker kan ytterligare delas in i följande kategorier:

• Product size Risker som har att göra med storleken av produkten som man tänker utveckla.

• Business impact Risker som har att göra med restriktioner från ledningen eller marknaden.

• Customer characteristics Risker som har att göra med utvecklarens möjligheter till kommunikation med kunden.

• Process definition Risker som har att göra med hur klar definitionen av processen är.

• Development environment Risker som har att göra med tillgängligheten av verktyg som kommer att användas till systemkonstruktionen.

• Technology to be built Risker som har att göra med komplexiteten av det tänkta systemet och teknologi som är ny.

• Staff size and experience Risker som har att göra med erfarenheter inom projektgruppen med avseende på teknik och projekt.

Pressman[3] presenterar en metod för hur man skapar sig en egen checklista baserad på ovanstående generiska kategorier som naturligtvis kan användas i varje projekt. Man kan antingen framställa relevanta frågor för respektive kategori som man sedan besvarar eller rada upp egenskaper som är relevanta för varje kategori. Om man väljer det första tillvägagångssättet så kan svaret på frågorna även fungera som en estimering av effekten (konsekvenserna), som vi kommer att se i kapitel 4.2. Produkten från detta steg är en lista med alla risker som man har identifierat.

4.2 Risk Analysis

Under delprocessen Risk Analysis bearbetas varje identifierad risk i tur och ordning. Man försöker beräkna sannolikheten och förlustomfattningen för varje risk. Det finns återigen ingen magisk formel för att beräkna dessa attribut, utan man får helt enkelt förlita sig på projektledarens erfarenhet. Man kan dock använda sig av data från tidigare projekt för att göra estimeringen lite säkrare. Det är även klokt att inte försöka göra exakta estimeringar men istället komma överens om intervall för dessa två attribut. Exempelvis om vi räknar sannolikheten i procent så kan skalan vara (1-10%), (10-25%), (26-50%), (51-75%), (76-99%). Om vi räknar förlustomfattning i kronor så kan vi göra estimeringar i hundratusental.

När estimeringarna är klara är det dags att rangordna riskerna med avseende på viktighet eller riskexponering. Riskexponering definieras enligt följande formel:

RE = P (UO) ∗ L(UO)

Där RE är förkortningen för Risk Exposure, P för probability, L för loss och UO för unsatisfactory outcome. När man har beräknat RE för varje risk kan man rangordna dem[1]. Denna rangordning är inte slutgiltig. I takt med att projektet fortgår och mer information blir tillgänglig kan rangordningen bli missvisande. Därför måste den uppdateras under varje iteration av RM-processen enligt Bild 1. Innan man fortsätter till nästa steg måste man även bestämma sig för hur många utav dessa risker man skall behandla. Det är inte alltid realistiskt att behandla allihop beroende på resurser. Barry Boehm[1] rekommenderar att man tar de 10 högst rankade, andra menar att detta beror på projektets natur[5].

4.3 Risk Planning

Inom delprocessen Risk Planning försöker man utveckla strategier för att hantera riskerna som man extraherat från Risk Analysis-processen. Återigen finns det ingen exakt vägledning till hur detta skall göras utan man får förlita sig på projektledarens omdöme och erfarenhet[5]. Barry Boehm[1] har sammanställt en tabell med de vanligaste riskerna ett projekt kan stå inför, och föreslagit tekniker som man kan använda vid planering av åtgärder, för vardera utav dessa, men de kan närmast betraktas som överskådliga. Slutligen försöker man integrera alla dessa planer med varandra och i projektplanen. Ian Sommerville[5] har identifierat tre strategier inom riskplanering enligt följande:

1. Avoidance strategies Dessa strategier går ut på att man reducerar sannolikheten för att något oönskat skall inträffa.

2. Minimisation strategies Dessa strategier går ut på att man försöker minimerar förlusten om något oönskat inträffar.

3. Contingency strategies Dessa strategier går ut på att man är bered på det värsta som kan hända, och har en plan för att bemöta detta.

4.4 Risk Monitoring

RM-processen är precis som bild 1 visar, en iterativ process. Risk Monitoring är det sista steget i varje sådan iteration. Det som görs i detta steg är att man följer upp riskerna som man har extraherat från tidigare steg. Med hjälp av ny information kan man beräkna om sannolikheten för en risk har ökat eller minskat på samma sätt som man kan beräkna om effekterna för från den har blivit starkare eller svagare[1]. Ibland kan det vare svårt att få tag på denna information, det gäller därför att leta efter ledtrådar om hur sannolikheten och effekten har utvecklat sig. Ian Sommerville[5] har utvecklat en tabell med eventuella indikatorer for ett antal risktyper som kan vara till hjälp. När man är klar med detta börjar nästa iteration där man åter analyserar och planerar dessa risker, eventuellt men inte nödvändigt med en ny rangordning.

5 Agile Risk Management

Förespråkare för de flesta lättrörliga metoderna hävdar att dessa metoder är risk-drivna[4], vilket man skulle kunna uppfatta som att RM är inbyggt i metoden på något sätt. Konstigt nog finns det inte så mycket skrivet om hur man skall utföra RM i dessa metoder. Problemet som man står inför, är på vilket sätt man ska kunna applicera konventionell RM menat för projekt som varar ett antal år, på lättrörliga iterationer som endast varar mellan en vecka och en månad. Detta kan låta som en omöjlighet men enligt Smith[4] är det inte det. De menar att lösningen för att göra RM-processen lättrörlig är att utnyttja styrkorna i de lättrörliga metoderna, såsom nära samarbete med kunden, snabb återkoppling, gruppstyrkan o.s.v. Medan man i konventionell RM går igenom ett antal långa och tidskrävande steg, så kan man utnyttja styrkan och kunskaperna inom gruppen för att analysera och planera för riskerna på ett muntligt och icke formellt sätt. Om man har missbedömt någon risk så ger de korta iterationerna och återkopplingen möjligheten för korrigerande åtgärder vid näste iteration, när färsk information finns tillgänglig. RM inom lättrörliga metoder bör ske innan utvecklingsarbetet inom en iteration. Det man måste sträva efter är att integrera RM-processen i planeringen utav varje iteration och tillämpa RM på ett sådant sätt att hela gruppen skall kunna utföra det tillsammans på ett snabbt sätt.

6 Slutsatser

Det är praktiskt omöjligt att ta reda på, om man har tagit hänsyn till varje risk som man står inför. Det är heller inte syftet med RM, det vore ju ett projekt i sig självt att försöka göra det. Målet med RM är att försöka upptäcka alla de risker som hotar projektets överlevnad och inte att upptäcka dem alla. Man kan betrakta risker som organiska enheter p.g.a. att man inte kan förutspå hur de kommer att utveckla sig. Genom att kontinuerligt följa upp riskerna i enlighet med RM-processen kan man få dem under kontroll. Vid projekt liknande den på kursen kan det vara viktigt att beakta risker som har att göra med tidsbudget (ekonomiska intressen existerar inte i detta fall), kompetenssammansättning, teknisk osäkerhet, kund, tvetydighet i kraven, resurser, att man utvecklar systemet som verkligen efterfrågas etc. Användning av lättrörliga metoder påverkar riskhanteringen på det sättet att man inte kan tillämpa den på det konventionella sättet. Tack vare att varje iteration är så liten i jämförelse med ett helt plandrivet projekt, så medför detta att även riskerna är väldigt små inom varje iteration. Det gäller därför att utföra RM på ett snabbt och mindre formellt sätt. För den övergripliga planen kan man däremot utföra RM som ligger åt konventionella sättet, dock på ett övergripligt sätt.

Referenser

[1] Barry W. Boehm. Software risk management: Principles and practices. IEEE Software, 8:32–41, January 1991.

[2] Jyrki Kontio. Risk management in software development: A technology overview and the riskit method. In ICSE, pages 679–680, 1999.

[3] Roger S. Pressman. Software Engineering A Practitioner’s Approach, sixth edition. McGraw-Hill, 2005.

[4] Preston G. Smith and Roman Pichler. Agile risks/agile rewards. 2005.

[5] Ian Sommerville. Software Engineering, 6th edition. Addison-Wesley, 2001.