Ketterät menetelmät ottavat harvoin kantaa riskienhallintaan. Yleinen väärinkäsitys onkin, että kun projekti tehdään ketterillä menetelmillä, riskienhallinnasta ei tarvitse välittää, kuvitellaan että se kuuluu ainoastaan vanhanaikaisiin vesiputousmallilla tehtäviin projekteihin.
Syy ketterien menetelmien syntyyn aikoinaan oli se, että perinteinen suunnitelmavetoinen malli ei toiminut ICT-projekteissa. Vanhalla mallilla tehdyt ICT -projektit epäonnistuivat aina. Epäonnistumisien syynä oli se, että ICT-projektit ovat usein kompleksisia, muutosalttiita, uniikkeja, korkean riskitason projekteja, joilla ei ole onnistumisen mahdollisuuksia suunnitelmavetoisella projektimallilla.
Ketterissä malleissa on siis hyviä käytäntöjä, jotka pienentävät projektin riskitasoa. Se ei kuitenkaan tarkoita sitä, että ketterässä projektissa ei tarvita riskienhallintaa. Ketterät menetelmät eivät käsittele riskienhallintaa siksi, ettei sitä tarvitsisi tehdä, vaan siksi, koska niiden fokus on projektin elinkaarimallissa, eikä projektinhallintamallissa.
Projektissa kannattaa siis käyttää ketteriä menetelmiä silloin, kun projekti on kompleksinen, uniikki, muutoksia on odotettavissa ja sen riskitaso on korkea. Tällaisessa projektissa ei riskienhallintaa voi jättää huomioimatta.
Suunnitelmavetoisessa projektissa ja ketteriä menetelmiä käyttävässä projektissa riskienhallinnan prosessit ja käytännöt ovat suurin piirtein samat. Riskit tunnistetaan, analysoidaan ja toimenpiteet suunnitellaan riskien pienentämiseksi tai poistamiseksi.
Jokaisen eri tyyppisen projektin riskienhallinnassa on kuitenkin huomioitava projektin erityispiirteet. Ketterän projektin riskienhallinta on onnistuneempaa ja tarkoituksenmukaisempaa, kun seuraavat asiat huomioidaan:
- Ketterässä projektissa projektin laajuudesta ei ole projektin alussa selkeää kuvaa eikä sitä tarkoituksella edes yritetä määritellä. Projektin vaatimukset ja laajuus tarkentuvat ja muuttuvat projektin aikana. Seurauksena projektin riskitilanne muuttuu jatkuvasti, jolloin on erityisen tärkeää, että myös riskienhallintaa tehdään jatkuvasti projektin aikana.
- Ketterässä projektissa toiminnallisuus on tyypillisesti kuvattu käyttäjätarinoina, jotka ovat prioriteettijärjestyksessä tuotteen kehitysjonossa. Käyttäjätarinat ovat juuri tärkeimpiä kohteita riskienhallinnassa. Kullekin käyttäjätarinalle voidaan tehdä riskianalyysi ja riskitaso merkitään tuotteen kehitysjonoon. Kun seuraavaan toteutusjaksoon eli iteraatioon valitaan käyttäjätarinoita toteutettavaksi, pelkkä liiketoiminta-arvo ei riitä priorisoinnin perusteeksi. Huomioon tulee ottaa myös työmäärä ja riskitaso, jolloin priorisoinnissa voidaan käyttää kaavaa: Prioriteetti = Liiketoiminta-arvo / työmäärä*riskitaso
- Toteutustiimillä on keskeinen rooli riskienhallinnassa. Tiimin jäsenet ovat teknisen työn tekijöitä, jotka eivät välttämättä tunne riskienhallinnan käytäntöjä, joten he tarvitsevat riskienhallinnassa koulutusta ja fasilitointia.
- Riskienhallintaprosessien perusteella syntyneet toimenpiteet kannattaa mahdollisuuksien mukaan sisällyttää kehitysjonon tehtäviksi, jolloin ne tulevat hoidetuksi toteutustiimin toimesta työjaksoissa eli iteraatioissa.
- Osa projektin riskeistä on kuitenkin projektitason riskejä ja näihin liittyvät tehtävät hoidetaan muiden sidosryhmien toimesta.
- Riskien tunnistamisessa kannattaa käyttää useita menetelmiä kattavan riskilistan aikaansaamiseksi. Näitä ovat mm.
- Analyysi riskiluokkien perusteella käyttäen apuna ketterille projekteille tehtyä RBS-kaaviota (Risk Breakdown Structure)
- Tarkistuslistat
- Sidosryhmien osallistaminen riskien tunnistamiseen (esim. asiakas, loppukäyttäjät, liiketoiminnan edustajat)
- Riskit menneistä samankaltaisista projekteista
- Pre-mortem. Kuvitellaan, että projekti on epäonnistunut ja tiimi miettii mitkä olivat epäonnistumisen syitä.
- Riskitason seurannassa voi käyttää projektin tavoitekohtaisia graafisia esityksiä (Risk Burndown Chart), jotka kuvaavat jäljellä olevaa riskien vaikutusta projektin tavoitteisiin ajan funktiona
- Pyörää ei tarvitse keksiä Hyväksi todetut riskienhallinnan prosessit ja käytännöt, joita kuvataan esim. PMI:n (Project Management Institute) PMBOK® teoksessa ja ISO 21500 standardissa, kannattaa ottaa käyttöön. Kuitenkin muistaen, että on parempi mukauttaa prosessit projektille eikä päinvastoin.
Ehkä kaikkein tärkeintä on kuitenkin varmistaa se, että ketterien menetelmien hyvät riskitasoa alentavat käytännöt ovat käytössä. Näitä ovat mm. fokus toimivaan tuotteen aikaansaamiseksi, toiminnallisuuden jatkuva priorisointi, nopea arvonmuodostus, läpinäkyvyys, asiakkaan osallistuminen ja muutosystävällisyys.
Projektin riskienhallintaa käsitellään ilmaisessa webinaarissamme Projektin riskienhallinnan prosessit.
Myös kaikissa projektinhallinnan luokkakoulutuksissamme käsitellään riskienhallintaa
Tervetuloa koulutuksiin
Projektinhallinta ketterässä projektissa
Projektin riskienhallinnan käytännöt
Hannu Blomqvist
Kirjoittaja toimii hankejohtajana Codemen Oy:ssä. Hänellä on yli 20 vuoden käytännön kokemus projektien ja ohjelmien johtamisesta. Hän on johtanut laajoja kansainvälisiä hankkeita ja ohjelmia, joilla on ollut useita osapuolia useasta yrityksestä ja monesta kansallisuudesta. Hannu tuntee hyvin sekä projektijohtamisen perinteiset että ketterät menetelmät. Hannu on kokenut projektinhallinta-alan kouluttaja ja puhuja kansallisissa ja kansainvälisissä tilaisuuksissa ja on luennoinut myös Aalto-Yliopistossa.