Risken med en riskworkshop är överhängande
När en anledning till att vi gör något är just att det ska göras är risken stor att resultatet inte leder oss framåt.
Så har jag flera gånger upplevt att riskworkshops initieras och genomförs, framförallt i vattenfallprojekt. Som en punkt i projektledarens checklista ligger att genomföra en riskworkshop. Den genomförs och resultatet hamnar i en Excel-fil. Kort därefter ”arkiveras” riskerna och de aktiviteter som skulle mitigera eller förhindra riskerna likaså. Och när projektet kör i diket (väldigt många IT-projekt kör i diket) är orörda gamla och nya risker en del av orsaken.
Det svåra behöver inte vara att se risker utan att leva med dem och agera på dem.
Med agila metoder med Lean UX och Lean-agile-principer finns bättre förutsättningar att kontinuerligt hantera risk. Genom att validera med användare tidigt, visualisera i hela utvecklingsprocessen inte bara som metod utan också som ett sätt att kommunicera och att styra om snabbt (pivot to change) visualiseras och hanteras risker löpande. ”Validate the innovation with customers, then pivot without mercy or guilt when the hypothesis needs to change.”
Utifrånperspektivet som användarcentrerad utveckling hjälper oss att ha är också en nyckel till att se och agera på risk. Vi har en förkärlek för inifrånperspektivet något som suboptimerande vattenfallprojekt inte automatiskt utmanar oss att hantera.
Om vi har problem att identifiera risker finns alternativa metoder till den traditionella riskworkshopen.
Daniel Kahneman beskriver en metod i hans bok ”Tänka snabbt och långsamt” som kan hjälpa oss att tidigt se och agera på risker. Han refererar till en metod som heter ”Pre mortem”. Den går ut på att samla sakkunniga (ta teamet och stakeholders) och be dem att utföra följande ”Tänk er att det har gått ett år. Vi genomför den plan som nu föreligger. Utfallet blev katastrofalt. Ta nu fem-tio minuter på er att skriva en kort berättelse om katastrofen.”
Pre mortem övningen har två fördelar skriver Kahneman: den motverkar det grupptänkande som drabbar många team när ett beslut verkar vara taget och den ger fantasin hos sakkunniga personer en skjuts i rätt riktning.
Övningen gör det enklare för de som har tvivel att komma till tals. Och de som inte ser några risker utmanas att undersöka om det finns möjliga hot som de kanske har förbisett. Formatet berättelse passar också bättre att sprida och kommunicera än risker i en excel-fil.
Att utveckla är en hypotesdriven process och i sakens natur ligger det att komma upp med “fel” svar. ”Fail fast and learn” är ett viktigt mantra. Demo varannan vecka, skissa som kommunikation, uppmuntra initiativ och beslut på golvet och validering med användare tidigt hjälper oss att se och hantera risker nu, inte vid nästa beslutspunkt som i vattenfallsprojekt.
En bock i en checklistan ”vi har haft en riskworkshop” är en risk i sig. Undvik den med motiverade team, modernt ledarskap, agila-principer och Lean UX.
2 svar på ”Risken med en riskworkshop är överhängande”
Hur många förstår ens syftet med riskhantering? När ska agile få att att från-gå hela ”check-i-boxen”-mentaliteten? När blir vi resultatdrivna och fokuserar på att nå ”Why”, inte ”What”?
Lurigt det där. Förändringen måste komma både från golvet och från management. Där ligger den stora utmaningen. Att få ett motiverat team på golvet att jobba crossfunktionellt med snabba releaser och aktiv riskhantering är inte den stora utmaningen. Utmaningen ligger i att förflytta kolossen. Och att hela skeppet taktar Lean-Agile 🙂