Risikoanalyse (case 2) Hvorfor risikoanalyse Risikoanalysen i Simpsons-projektet De næste trin Spørgsmål og dialog Jeg vil tage udgangspunkt i case 2 – The Simpsons på mobiltelefonen – og tale om risikoanalyse. I rapporten er der identificeret en del risici. Jeg vil tale om hvordan man kommer videre derfra, dvs. hvad man kan gøre for yderligere at reducere kompleksiteten i forhold til risici. Hvorfor risikoanalyse Så vil jeg gå videre med risikoanalysen i Simpsons-projektet De næste trin i risikoanalysen – dvs. hvordan man kunne udvide risikoanalysen og gå videre med den. Spørgsmål og dialog

Hvorfor risikoanalyse? Det er bedre at forebygge end at helbrede! For at kunne estimere mere nøjagtigt. For at skabe dialog og ’lære noget’. For at reducere (eller forstå) kompleksitet. Hvorfor skal vi beskæftige os med risikoanalyse? En risiko er en mulighed for at lide tab. Logikken bag en risikonalyse er at hvis vi er forberedte har vi mulighed for at foretage de nødvendige foranstaltninger, dvs. planlægge os ud af risikoen, eller forholde os proaktivt til den. Risikoanalysen kommer derfor til at være en af grundlæggerne for tidsestimeringen – dvs. at vi kan imødegå nogle risici ved at indregne ekstra tid til løsning af den potentielle risiko. Derudover mener jeg at risikoanalysen i begyndelsen af projektet kan hjælpe til en dialog mellem projektgruppen, ledelsen og kunden om hvad vilkårene for projektet er. Det er i denne dialog at man opnår en fælles vision og at kunden ”uddannes” til at forstå vigtigheden af at der fx indgås aftaler om ansvarsfordeling, delleverancer og betaling osv. Jeg mener dermed man kan sige at risikoanalysen bidrager til at formindske projektets kompleksitet idet den hjælper os til at forstå projektets vilkår.

Risikoanalyse i case 2 Risikoanalyse ud fra intuition og common-sense. Risici identificerede, men ikke prioriterede. Generelt om risikoanalysen i case 2 kan siges at: Jeg har foretaget en samlet risikovurdering ud fra den model, der fandtes i opgaveforlægget. Dernæst har jeg nævnt en række udfordringer, der kunne medføre risici, Og udpeget nogle håndteringsteknikker. Risiciene og håndteringsteknikkerne er identificeret på baggrund af intuition og common-sense (i parentes bemærket er den bedste måde at identificere risici på nok gennem erfaring, hvilket jeg dog desværre mangler på det område). I rapporten har jeg identificeret, men ikke prioriteret risiciene. Christensen, Marie m.fl.: Udvikling af Multimedier

Risikoanalyse - Parametre Projektstruktur Mål – løst formuleret Planer – overordnede Ændringer – tilladte Erfaringer med teknologi og arbejdsformer Kendskab til software – ja Kendskab til hardware – ja Kendskab til arbejdsmetoder – måske (afhængig af beslutning om COPE) Projektstørrelse Varighed – usikkert Mandskab – formentlig få Økonomi – usikkert Berørte leverandører – usikkert Parametrene for risikoanalysen i case 2 er projektets struktur, erfaring med teknologi og arbejdsformer og projektets størrelse. I rapporten skriver jeg at projektet er løst struktureret, baseret på kendt teknologi og forholdsvist småt. Det bliver derfor kategoriseret som ”Meget lav risiko, men påvirkelig af svag ledelse” jf. modellen. Ved nærmere overvejelse har jeg dog ændret mening om bedømmelsen af risikoprofilen. Selvom projektet er løst struktureret nu, skulle det gerne blive strammere struktureret efter mødet med THQ, hvor projektets mål skal konkretiseres og kvantificeres, og vi bl.a. skal diskutere tidsplan, ansvars- og rollefordeling osv. Derudover skal projektet måske baseres på en ny produktionsstrategi – COPE – hvilket også indebærer en risiko. Sidst, men ikke mindst, er det stadig usikkert hvor omfangsrigt projektet bliver. Hvis projektet ender med at skulle benytte en COPE-strategi vil risikoprofilen være ”medium eller medium til lav risiko” afhængig af projektets størrelse. Hvis man ikke bruger COPE vil det være ”meget lav til lav risiko”.

De næste trin - risikovurdering Risikovurdering (udregning og prioritering) Netværk Evt. diskussion af risici på opstartsmødet Risiko Sandsynlighed (%) Alvor (1-10) Risikotal = SxA Nu vil jeg gå videre til at tale om de næste trin i risikoanalysen, nemlig risikovurdering og imødegåelse af risici. Dette er jo en øve-case og efter aflevering har jeg tænkt over hvordan man kunne gå videre med risikoanalysen. Kvantificere risiciene og give en risikovurdering (sandsynlighed i % gange alvor angivet i tal fra 1-10) og dermed prioritere risiciene. Tale med erfarne projektledere i mit netværk. Evt. opprioritere diskussionen af risici på opstartsmødet – dvs. inddrage kunden i diskussionen (så er alle parter med fra starten og føler ansvar og ejerskab). Eller som minimum diskutere det i projektgruppen.

De næste trin – værktøjskasser til at imødegå risici Ekstern integration (fx samarbejdsgrupper, ekstern projektleder eller andre eksterne interessenter i brugergruppen, få fælles vision, eksterne interessenter deltager i nøglebeslutninger) Intern integration (fx erfaren projektleder, sammentømret projektgruppe, hyppige møder og referater, daglig kontakt, kommunikation af visioner og mål, projektgruppen deltager i nøglebeslutninger) Formelle planlægningsværktøjer (fx planlægning af tid, aktiviteter, ressourcer og økonomi, brug af milepæle, projektstyringssystemer, ansvars- og opgavefordeling, estimeringsteknikker) Formelle styrings- og opfølgningsværktøjer (fx statusrapporter, reviews og evaluering undervejs (internt + eksternt), jævnlige møder omkring milepæle, projektstyringsprogrammer og dokumenthåndtering) Et strukturerende værktøj i risikoanalysen kunne være Marie Christensen og Louise Harders værktøjskasser til at imødegå risici. Værktøjskasserne er knyttet til den model, jeg talte om før. De giver fire konkrete værktøjskasser til at tænke risikoanalysen ud fra, og et forslag til hvilke værktøjskasser forskellige typer projekter skal tage i brug. Værktøjskasserne er ekstern integration, intern integration, formelle planlægningsværktøjer og formelle styrings- og opfølgningsværktøjer. Ifølge Christensen og Harders model skal der i Simpsons-projektet indgå meget intern integration, lidt til medium af de formelle værktøjer og kun lidt ekstern integration. Jeg har to bemærkninger til dette. I forhold til de formelle værktøjer: Det, kun at inddrage dem i begrænset omfang, forudsætter en erfaren projektleder, der kan tage de formelle ting mere på intuitionen. Hvis jeg skulle lede Simpsons-projektet ville jeg stadig holde mig forholdsvist stramt til de formelle værktøjer. I forhold til ekstern integration: Deres logik må være at hvis projektet er stramt struktureret så er det ikke nødvendigt med ekstern integration. I starten af forløbet vil jeg dog mene at det altid er en god idé at inddrage kunden og evt. brugerne i et stort omfang.