T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 1 (11) T-76.115 Riskienhallintadokumentti ExtraTerrestriaLs Versio Pvm Tekijä Kuvaus 0.1 Mika Suvanto Alustava versio 0.9.10.2004 Mika Suvanto Riskilokia täytetty 0.3 21.10.2004 Mika Suvanto Kosmeettisia muutoksia 1.0 21.10.2004 Mika Suvanto Kirjoitusvirheitä ym. korjattu Riston kommenttien perusteella 1.1 27.10.2004 Timo Sallinen Lisätty hallintakeinoja, korjauksia 1.8.10.2004 Mikko Ruokojoki Muokattu ulkonäköä ja lisätty vastuut riskeihin 2.0 29.10.2004 Mikko Ruokojoki Versio 2 2.1 Mika Suvanto Riskiloki päivitetty ja lokin muutokset -taulukko lisätty Sisältö 1. Dokumentin tarkoitus... 1 2. Riskienhallinnan osapuolet ja vastuut... 2 3. Riskienhallintaprosessi... 2 3.1. Prosessin kuvaus... 2 4. Riskiloki... 3 5. Seuranta... 4 5.1 Seurantaprosessi... 4 5.2 Toimenpiteistä päättäminen... 5 6. Lähteet... 5 1. Dokumentin tarkoitus Tämä dokumentti määrittelee ExtraTerrestrials ryhmän riskienhallintaprosessin Teknillisen korkeakoulun kurssin T-76.115 ohjelmistoprojektissa. Tarkempi kuvaus ohjelmistoprojektista löytyy projektisuunnitelmasta [1]. Dokumentin keskeistä sisältöä ovat erityisesti riskienhallintaprosessin kuvaus, jossa kerrotaan kuinka ryhmä hallitsee projektiin luontaisesti kuuluvaa epävarmuutta, sekä riskiloki, jossa yksittäiset riskit on eritelty, analysoitu ja vastuutettu. Tätä dokumenttia päivitetään tarpeen mukaan projektin edetessä. Tämä sisältää tarpeellisiksi koetut muutokset prosessiin sekä toistuvat päivitykset riskilokiin aina uusia riskejä tunnistettaessa tai kun jo tunnistetuista riskeistä saadaan lisää tietoa.
T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 2 (11) 2. Riskienhallinnan osapuolet ja vastuut n sisäisen työnjaon mukaisesti riskienhallinnasta on päävastuussa Mika Suvanto. Projektipäällikkö Mikko Ruokojoki toimii tässä varahenkilönä. Heidän tehtäviään riskienhallinnassa ovat: prosessin määrittäminen riskienhallinnan dokumentointi riskien analysointi riskien seuranta Koko projektiryhmä osallistuu myös riskienhallintaan: riskien tunnistaminen toimenpiteistä päättäminen Muut riskienhallinnan osapuolet: asiakas mentor ja mentor muodostavat projektin ohjausryhmän. 3. Riskienhallintaprosessi 3.1. Prosessin kuvaus Käyttämämme riskienhallinnan prosessi pohjautuu Jyrki Kontion RiskIt menetelmään [2, 3]. Emme kuitenkaan sovella menetelmää koko laajuudessaan, vaan pyrimme toteuttamaan menetelmää tarpeisiimme soveltuvin osin. Tähän päädyttiin projektin suhteellisen pienuuden ja vähäisten resurssien takia. Kuvassa 3.1.1 on esitetty iteratiivinen riskienhallintaprosessi, jota sovellamme projektissa. Keskeistä on riskienhallinnan iterointi projektivaiheissa. Jokaisen vaiheen alussa pidetään palaveri, jossa tunnistamme ja analysoimme mahdollisia uusia riskejä ja muutostarpeita riskienhallintaprosessiin. Mikäli projektissa tapahtuu suuria muutoksia esimerkiksi tavoitteiden osalta, palaveri voi olla syytä pitää myös tällöin. Tapaamisten tuloksena syntyneet muutokset päivitetään tähän dokumenttiin. Riskejä tunnistetaan kolmen neljän hengen työryhmässä. n kokoonpanoon kuuluvat riskienhallinnan vastuuhenkilöt sekä mahdollisesti vaihtuva kolmas (ja neljäs) jäsen. Työryhmän tarkoitus on tunnistaa projektiin liittyvät riskit, analysoida ne, määrätä vastuuhenkilöt riskien seurantaan, suunnitella toimenpiteet riskin toteutuessa ja kirjata tulokset riskilokiin. Palaverin jälkeen riskienhallinnan vastuuhenkilöt käyttävät tarkistuslistamenetelmää varmistuakseen tulosten kattavuudesta. Koko projektin ajan koko ryhmä voi tunnistaa uusia riskejä ja esittää muutoksia nämä pyritään käsittelemään välittömästi. Projektin ensimmäisen vaiheen riskintunnistuksessa käytetään myös hyväksi edellisten vuosien projektiraportteja näissä voi olla konkreettista tietoa projekteja kohdanneista riskeistä. Riskienhallinnassa keskitytään ennen kaikkea suurimpiin riskeihin, ja nämä pyritään tunnistamaan ja analysoimaan varhaisessa vaiheessa. Kaikkia pienempiä riskejä tuskin pystymme edes tunnistamaan ja niihin keskittyminen ei ole tehokasta; projektiin liittyy kuitenkin normaalia epävarmuutta. Prosessissa onkin keskeistä, että projektin kannalta tärkeimpiä riskitekijöitä
T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 3 (11) hallitaan ja seurataan säännöllisesti. Kuva 3.1.1. Riskienhallintaprosessi 4. Riskiloki Riskien luokittelussa olennaista on kaksi tekijää riskin vakavuus ja riskin toteutumisen todennäköisyys. Nämä käsitteet on määritelty taulukoissa 4.1 ja 4.2. Varsinainen riskiloki on taulukossa 4.4. Riskit on jaettu eri kategorioihin niiden tyypin mukaan. Näitä kategorioita ovat: henkilöriskit (projektiryhmä, asiakas, kurssihenkilökunta) infrastruktuuririskit (laitteistot, työkalut ym.) sopimusriskit (oikeuksista sopiminen ym.) suunnitteluriskit (ohjelmistosuunnittelu) laaturiskit (tuotteiden laatu) force majeure (katastrofit, sodat ym. Näihin ei varauduta ollenkaan.) vaatimusmäärittelyriskit (vaatimusmäärittelyn taso)
T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 4 (11) Taulukko 4.3 kuvaa todennäköisyyden ja vakavuuden suhdetta. Tärkeimmät riskit kuuluvat oikeaan ylänurkkaan (merkitty punaisella) ja vähäisimmät riskit vasempaan alanurkkaan (merkitty vaaleansinisellä). Taulukko kertoo myös todennäköisyyden ja vakavuuden pisteytyksen, joita käytetään riskilokissa vastaavissa sarakkeissa. Vakavuus Kriittinen Kohtalainen Matala Kuvaus Tapahtuma aiheuttaa toteutuessaan suuria ongelmia projektin suorittamiselle tavoitteiden mukaisesti, jopa vaarantaen koko projektin. Tapahtuma aiheuttaa toteutuessaan paljon työtä ja vaatii huomiota useilta ryhmän jäseniltä. Matalan prioriteetin vaatimukset vaarantuvat. Tapahtuma aiheuttaa lähinnä ylimääräistä työtä ja vaatii huomiota, mutta ei vaaranna projektiin kohdistuvia vaatimuksia. Vaikutukset kapea-alaisia; vähän työtä tai vaikuttaa vain yhteen kahteen henkilöön. Taulukko 4.1. Vakavuuden määritelmä Todennäköisyys Suuri Kohtalainen Pieni Kuvaus Tapahtuma toteutumista voidaan pitää hyvin todennäköisenä projektin aikana, muttei kuitenkaan varmana. Tapahtuman toteutuminen on varsin mahdollista. Tapahtuma on varsin epätodennäköinen, mutta kuitenkin mahdollinen projektin aikana. Taulukko 4.2. Todennäköisyyden määritelmä Vakavuus Todennäköisyys Matala (1) Kohtalainen (2) Kriittinen (3) Suuri (3) 3 6 9 Kohtalainen (2) 2 4 6 Pieni (1) 1 2 3 Taulukko 4.3. Todennäköisyys / Vakavuus 5. Seuranta 5.1 Seurantaprosessi Riskienhallinnan vastuuhenkilöt vastaavat riskien seurannasta. Seuranta käsittää: toteutuneiden riskien havainnoinnin valittujen toimenpiteiden vaikutusten seurannan tapahtumasta opittujen asioiden analysoinnin ja kirjaamisen dokumentoinnin päivittämisen
T-76.115 Riskienhallintadokumentti ETL-työkalu (Aureolis Oy) Sivu 5 (11) Jokaisen ryhmän jäsenen vastuulla on uusien riskien tunnistaminen ja oman vastuualueensa riskien ennakointi ja toimenpiteiden seuranta. Riskien seurannan tuloksena riskilokiin tulleet muutokset kirjataan taulukkoon 4.5. Tässä taulukossa esitetään muuttuneet kohdat sekä toteutuneet riskit ja reagointi niihin. 5.2 Toimenpiteistä päättäminen Riskitapahtuman toteutuessa seuraukset riippuvat riskin vakavuusasteesta: matala Työryhmä / projektipäällikkö päättää toimenpiteet kohtalainen Päätetään koko ryhmän tapaamisessa kriittinen Päätetään yhdessä ohjausryhmän kanssa, välitön raportointi kaikille projektin osapuolille Toimenpiteistä päätettäessä pohjaudutaan riskilokissa määriteltyihin toimintatapoihin. Kuitenkin on todennäköistä, että näitä on tarpeellista soveltaa vielä yksityiskohtaisemmin. Toteutuneista riskeistä on kaikissa tapauksissa raportoitava riskienhallinnan vastuuhenkilöille seurantaa varten. 6. Lähteet [1] ExtraTerrestrials ryhmän projektisuunnitelma [2] J. Kontio: The Riskit Method for Software Risk Management, version 1.00, http://www.soberit.hut.fi/~jkontio/riskittr.pdf, viitattu 14.10.2004 [3] Jyrki Kontio, Risk management intro, T-76.663 lecture slides, http://www.soberit.hut.fi/t-76.115/03-04/ohjeet/lectures/t-76.633_rmintro.pdf, viitattu 14.10.2004
ID Kategoria Vakavuus (1-3) R1 R2 R3 R4 R5 R6 R7 R8 Vaatimus Suunnittelu Todennäköisyys (1-3) 3 2 Tiedustellaan asiakkaalta ulkopuolisia tietolähteitä. Tehdään määrittelyistä riittävän tarkat ryhmän mahdollisimman itsenäisen työskentelyn mahdollistamiseksi. Altistavat tekijät Yksi ryhmän jäsen jättää kurssin kesken Useampi ryhmän jäsen jättää kurssin kesken Vaatimusten määrittely ei onnistu Projektipäällikkö ja vaatimusmäärittelyn vastuuhlö Arkkitehtuurin vastuuhlö ja projektipäällikkö Suunnitteluvirhe Asiakkaan henkilöresurssit puutteelliset Versionhallintapalvelin vikaantuu News/kalenterikone vikaantuu n keskeinen kommunikointi ei toimi Riskitapahtuma Vaikutus Omistaja Hallintakeinot Vastuu Päivitetty viimeksi n henkilöresurssit vähenevät n henkilöresurssit vähenevät olennaisesti Vaatimusmäärittel yyn jää olennaisia puutteita Valitaan väärä toteutustekniikka Kommunikointi asiakkaan kanssa jää liian vähälle Versionhallinta ei ole käytettävissä Newssit / kalenteri ei ole käytettävissä Erimielisyyksiä, väärinymmärryksiä Projektin laajuus supistuu tai työmäärä lisääntyy Projektin laajuus ja läpivienti joudutaan miettimään uudestaan Lopputulos ei vastaa asiakkaan tarpeita Joudutaan tekemään asioita uudelleen / työmäärä lisääntyy Lopputulos ei vastaa asiakkaan tarpeita, ryhmän motivaatio kärsii Ohjelmointi / dokumentointi viivästyy n kommunikointi vaikeutuu Motivaatio kärsii, työmäärä lisääntyy Tehtävien uudelleenjako, tarvittaessa muutoksia projektin laajuuteen. Neuvotellaan asiakkaan kanssa projektin laajuuden supistamisesta, mahdollisesti asiakkaan tiiviimpi osallistuminen. Tiivis yhteistyö asiakkaan kanssa vaatimusmäärittelyä tehdessä. Riittävä yhteistyö asiakkaan teknisen asiantuntijan kanssa merkittävistä teknisistä ratkaisuista. Siirretään versionhallinta koulun palvelimelle riskin toteutuessa Varaudutaan varmuuskopioinnilla, hoidetaan kommunikointi sähköpostitse tai siirrytään TikiWikiin riskin toteutuessa Mietitään kommunikointikäytännöt uusiksi, lisätään jäsenten välisiä tapaamisia. Projektipäällikkö Projektipäällikkö Projektipäällikkö Projektipäällikkö ja ko. asiasta vastaava News-vastaava 21.10.2004 Projektipäällikkö
ID Kategoria Vakavuus (1-3) R9 R10 R11 R12 R13 R14 R15 R16 R17 Sopimus Sopimus Todennäköisyys (1-3) 1 2 2 3 Altistavat tekijät n tavoitteet epäselviä Lisenssien kanssa ongelmia Oikeuksista sopiminen ei onnistu SoberIT:llä laiteongelmia ATK-keskuksella laiteongelmia ATK-keskuksella / muilla ISP:llä ongelmia sähköpostin kanssa n jäsenellä laiteongelmia ko. ryhmän jäsen Motivaatio-ongelmia Liian paljon töitä Riskitapahtuma Vaikutus Omistaja Hallintakeinot Vastuu Päivitetty viimeksi Erimielisyyksiä, väärinymmärryksiä Jotain lisämoduulia ei voida käyttää ohjelmistossa SoberIT sivut alhaalla Projektin kotisivut alhaalla Sähköpostiongelmat kohtainen tietokone hajoaa Projekti ei kiinnosta Projektille ei pystytä järjestämään riittävästi aikaa Motivaatio kärsii, työmäärä lisääntyy Toimintoja joudutaan karsimaan ja/tai tekemään itse Projekti ei käytännössä pääse käyntiin Dokumenttien teko viivästyy tai vaikeutuu Kotisivut tilapäisesti poissa käytöstä Sähköposti ei kulje tai kulkee hyvin hitaasti Työnteko vaikeutuu, osa tehdystä työstä menetetään, aikaa kuluu Työt viivästyvät, laatu heikkenee, arvosanat putoavat Työt viivästyvät, viivästyttää myös muiden työtä, arvosanat putoavat / Mentor Selkeä ja säännöllinen viestintä tehtävistä töistä, ja näiden jaosta. Selvitetään etukäteen asiakkaan kanssa minkälaiset lisenssit ovat mahdollisia ulkopuolisissa moduuleissa. Otetaan lokaalit kopioit kurssisivujen materiaalista. Tarvittaessa sivut voidaan helposti siirtää muualle, pidetään sisältö CVS:ssä Käytetään muita palveluntarjoajia (mm. työpaikat) ja puhelinta riskin toteutuessa Pidetään kaikki koodi ja dokumentit CVS:ssä, tarvittaessa käytetään koulun tarjoamia koneita Neuvotellaan ryhmän kesken henkilökohtaisita tavoitteista, mahdollinen tehtävien uudelleenjärjestely. Tehtäviä jaetaan uudelleen, riittävä osaamisen jakaminen varmistettava. Projektipäällikkö Työkaluista vastaava Projektipäällikkö SoberIT atk HUT atk HUT atk Projektipäällikkö n jäsenet ja projektipäällikkö
ID Kategoria Vakavuus (1-3) R18 R19 R20 R21 R22 R23 Todennäköisyys (1-3) Laatu Vaatimus R24 / Vaatimus R25 R26 R27 Laatu Kaikki 1 2 1 2 Altistavat tekijät Sairastumiset SoberIT:llä laiteongelmia Liian korkeat tavoitteet resursseihin nähden Testaus ei riittävän laadukasta Asioiden piilottelu ja peittely, tahallinen / tahaton Asiakkaan vaatimukset muuttuvat toistuvasti Kommunikointi asiakkaan suhteen ei toimi Dokumentoinnin laatu heikkoa Asioista sovitaan vain suullisesti Puutteellinen tietotaito ryhmällä Riskitapahtuma Vaikutus Omistaja Hallintakeinot Vastuu Päivitetty viimeksi Projektille ei pystytä järjestämään riittävästi aikaa Trapoli alhaalla Työmäärä arvioidaan liian pieneksi Virheet ja puutteet jäävät löytämättä Tieto ongelmista ei kulje Toistuvat muutokset vaatimuksiin t eivät tule toimeen keskenään Dokumentoinnin hyöty vähäistä Päätökset unohtuvat Tekniset haasteet osoittautuvat liian suuriksi Työt viivästyvät, tärkeä henkilö poissa Tuntiraportteja ei saada ajoissa Hommat jäävät puolitiehen Laatu alhainen Ongelmat tulevat esille liian myöhään Suunnittelu ja töiden jakaminen vaikeutuu, työnteko hidastuu, tehdään vääriä asioita Suunnittelu ja töiden jakaminen vaikeutuu, työnteko hidastuu, tehdään vääriä asioita tyytymätön, ohjelman jatkokäyttö vaarassa Pidetään turhia palavereja, tehdään turhaa työtä, sovittuja asioita jää hoitamatta Tavoiteltua toiminnallisuutta ei pystytä toteuttamaan Riittävä redundanssi jokaisen projektin osaalueen osaamisessa. Tehtävien uudelleenjako. Otetaan raportit riittävän ajoissa (2 päivää ennen) Neuvotellaan asiakkaan kanssa ajoissa tavoitteiden muuttamisesta. Määrittelyt käydään riittävän selvästi läpi asiakkaan kanssa, jotta epäselvyyksiä ei tule. Kokeillaan vaihtoehtoisia kommunikointitapoja, muutetaan yhteysti- Laaditaan muistiot jokaisesta tapaamisesta, dokumentoidaan sovitut asiat Haetaan asiakkaalta opastusta, tarvittaessa muutoksia projektin laajuuteen. Projektipäällikkö Projektipäällikkö n jäsen, joka on työmäärät arvioinut Otetaan käyttöön systemaattiset testausprosessit. Viikoittaiset raportit edistymisestä, edistymättömyydestä. Testausvastaava ja projektipäällikkö Testausvastaava ja projektipäällikkö Projektipäällikkö ja vaatimusmäärittelyn vastuuhlö Projektipäällikkö heyttä. Pidetään katselmuksia tärkeimmistä dokumenteista Katselmointivastaava Kokouksen sihteeri Projektipäällikkö
ID Kategoria Vakavuus (1-3) R28 R29 R30 R31 R32 R33 R34 Altistavat tekijät Suunnittelu Suunnittelu Laatu Todennäköisyys (1-3) Tekniset ongelmat muiden (lähde-) järjestelmien suhteen kemia ryhmän kesken ei toimi Rajapinnat huonosti määritelty tai kommunikointi ohjelmoijien välillä puutteellista Siirtyminen suunnittelusta toteutukseen hidasta Arkkitehdillä tuntimäärä varsin suuri Muutamalla ryhmän jäsenellä varsin vähän tunteja Koodin laatu heikkoa Riskitapahtuma Vaikutus Omistaja Hallintakeinot Vastuu Päivitetty viimeksi Löytyy bugeja tms. ominaisuuksia joihin ei voida vaikuttaa Tavoiteltua toiminnallisuutta ei pystytä toteuttamaan, työmäärä lisääntyy, suunnitelmia täytyy tarkistaa Yhteistyö ei suju Motivaatio kärsii Järjestelmäintegrointi eri moduulien välillä vaikeaa Arkkitehtuuri kärsii, suunnittelua ja ohjelmointia joudutaan miettimään uudelleen Toteutus viivästyy Toteutus viivästyy Arkkitehti ei osallistu aktiivisesti I2 ja FD -vaiheisiin Vaikeuksia löytää tarpeeksi aikaa myöhemmissä vaiheissa Ohjelman toimintaa ei ymmärretä Jatkokehitys vaikeaa, muiden ryhmän jäsenten vaikea saada selvää / Ratkaisuja ei sidota tiettyyn järjestelmään. kohtainen panostus, riittävä ajanvaraus projektille. UML-kaaviot ja/tai kirjalliset määrittelyt kaikista rajapinnoista ryhmän saataville. Pyritään jakamaan toteutusvastuuta ryhmälle, pidetään aivoriihi aiheesta Vastuutetaan tehtäviä uudelleen (johtuu osittain projektin luonteesta, mm. testausta ei olla pystytty juurikaan tekemään) Jaetaan itsenäisiä tehtäviä mm. joululoman ajaksi Pidetään koodikatselmointeja, käytetään suunnittelumalleja Arkkitehtuurista vastaava ja projektipäällikkö n jäsen yhdessä projektipäällikön kanssa Arkkitehtuurista vastaava Projektipäällikkö organisoi työt Toteutus vaikeutuu, muut joutuvat ottamaan vastuuta enemmän Tuntimäärät voivat ko. henkilöiden osalta jäädä vajaiksi, seurauksena heikompi lopputulos Projektipäällikkö, arkkitehtuurista vastaava Projektipäällikkö, ko. henkilöt Katselmointivastaava, arkkitehtuurista vastaava Taulukko 4.4. Riskiloki
Muuttunut kohta Muutos Tilanne Toteutetut / päätetyt toimenpiteet Päivämäärä R1 Laskettu todennäköisyys 2 -> 1 Ei merkkejä toteutumisesta - R3 - Osittain toteutunut pieniä puutteita löydetty R6 - Osittain toteutunut versiohallinnan kanssa pieniä ongelmia Päätetty tehostaa muutostenhallintaa 24.11 toimii ok. Pidetään yllä valmiutta siirtää CVS progress:iin R7 - - Varmuuskopiointi on järjestetty. R8 - Osittain toteutunut informaatiotulva ongelmana, kaikki eivät ole päässeet kokouksiin kenties riittävästi R11 - Lisenssistä / salassapidosta ei ole saatu sopimusta aikaan R12 - Osittain toteutunut aiheuttanut ylimääräistä odottelua palautuksen aikoihin R15 Nostettu todennäköisyys 1 -> 2 Toteutunut nettiyhteys poikki, bussilakko vaikeuttanut koulun koneiden käyttöä R16 Nostettu todennäköisyys 1 -> 2 Todennäköisesti pienissä määrin esiintyy jokaisella projektin aikana R17 Nostettu todennäköisyys 2 -> 3 Muut kiireet ovat rajoittaneet osallistumista projektiin R26 Nostettu todennäköisyys 1 -> 2 Muutama tehtävä unohtunut / viivästynyt, epävirallisimmissa työpalavereissa luvattuja asioita ei aina muista, kokouksen sihteeri ei huomaa kirjata kaikkia päätöksiä - Projektipäällikkö on yhteydessä asiakkaaseen välittömästi Projektipäällikkö määrittelee lokaalin kopion teon kurssisivuista jollekin tehtäväksi - - - Jokaisen pyrittävä kiinnittämään tähän enemmän huomiota
Muuttunut kohta Muutos Tilanne Toteutetut / päätetyt toimenpiteet Päivämäärä R30 - Osittain toteutunut kaikki eivät ole täysin selvillä miten edetä toteutuksessa Pidetään 25.11. aivoriihi toteutuksesta R31 Uusi riski - - R32 Uusi riski - - R33 Uusi riski - - R34 Uusi riski - - Taulukko 4.5. Riskilokin muutokset