Table of Contents 1 Johdanto.................................................................................. 1 1.1 Versiohistoria........................................................................... 1 1.2 Dokumentin tarkoitus..................................................................... 1 1.3 Käytetyt termit ja lyhenteet................................................................. 1 2 Käytetyt menetelmät....................................................................... 2 2.1 Vastuut................................................................................ 2 2.2 Käytetty menetelmä....................................................................... 2 3 Riskiskenaariot............................................................................ 3 3.1 Riskin vakavuuden arviointi................................................................ 3 3.2 Mahdolliset skenaariot.................................................................... 3 3.3 Vakavimmat riskit........................................................................ 4 3.3.1 R018 Käytetään liikaa opiskeluun............................................... 4 3.3.2 R016 Ohjelmoijalle tuntematon teknologia aiheuttaa ongelmia................................ 4 3.3.3 R015 Toteutusteknologia aiheuttaa ongelmia.............................................. 5 3.3.4 R008 Ei ymmärretä asiakkaan tarpeita.................................................... 5 3.3.5 R002 Kommunikaatio ei toimi ryhmän sisällä.............................................. 6 3.3.6 R014 Vaatimuksia tulee merkittävästi lisää................................................ 6 3.3.7 R026 Ei toimita tarpeeksi proaktiivisesti.................................................. 6 3.3.8 R027 Asiakkaalle palautettava tuote on pahasti keskeneräinen................................. 7 3.3.9 R028 Ylläpitoliittymää ei ehditä tehdä valmiiksi............................................ 7 4.................................................................................. 8 5 Viitteet.................................................................................... 9
1 (9) 1 Johdanto 1.1 Versiohistoria Versiohistoria Versio Pvm Tekijä Kuvaus Hyväksyjä 1.0 13.10.2005 JI Dokumentin luonti, menetelmien selitys, ensimmäiset skenaariot. 1.1 16.10.2005 JI Menetelmien selitystä tarkennettu, valittu pahimmat skenaariot ja määritetty jatkotoimenpiteet I1-vaiheessa. 1.2 7.11.2005 JI Todennäköisimpien riskiskenaarioiden analysointi. - 1.3 17.11.2005 JI (kappale 4), hallintamenetelmien tarkentaminen (kappaleet 3.3.1, 3.3.2, 3.3.3 ja 3.3.5) 1.4 2.12.2005 JI (kappale 4) - 1.5 20.01.2006 TH Skenaarioita lisätty (R24-27).Sekä riskiloki päivitetty. - 1.6 06.02.2006 TH Skenaario lisätty (R28).Sekä riskiloki päivitetty. - - Petteri Hyytiäinen - 1.2 Dokumentin tarkoitus Tämän dokumentin tarkoituksena on sekä selittää käytetyistä riskienhallintamenetelmistä, että myös ylläpitää ajantasalla olevaa riskilokia havaituista ongelmaskenaariosta. 1.3 Käytetyt termit ja lyhenteet Projektisuunnitelmasta löytyvät projektin dokumentaatiossa käytetyt käsitteet ja lyhenteet.
2 (9) 2 Käytetyt menetelmät 2.1 Vastuut Riskienhallinnasta on ensisijaisesti vastuussa riskinhallintaryhmä, johon kuuluu projektipäällikkö, laatupäällikkö ja arkkitehti. Riskienhallintaryhmä kerää iteraation alussa tietoa tulevaan vaiheeseen liittyvistä riskeistä ja lisäävät ne mahdollisiin skenaarioihin. Noin iteraation puolivälissä tätä listaa päivitetään uudelleen ja katsotaan onko tapahtunut oleellisia muutoksia. 2.2 Käytetty menetelmä Riskienhallintaan käytetään kurssin ohjeistuksessa opetettua riskit-menetelmää /1/. Tämä menetelmä koostuu neljästä päävaiheesta, jotka ovat 1. Tunnistaminen 2. Analysointi 3. Hallinta 4. Seuranta Riskien tunnistaminen ja analysointi on riskienhallintaryhmän tehtävänä (asiakkaan avustuksella). Kun riskiskenaariot on tunnistettu ja analysoitu, voidaan tehdä suunnitelma niiden hallitsemiseksi. Tämä hallintasuunnitelma tehdään todennäköisimmille ja toteutuessaan eniten projektia haittaaville skenaarioille. Tämän suunnitelman noudattaminen on jokaisen toimittajan jäsenen vastuulla. Kun kuka tahansa projektin jäsenistä huomaa riskin toteutuneen, se lisätään riskilokiin, ja riskinhallintaryhmä kokoontuu viipymättä toteuttaakseen/suunnitellakseen tarvittavat hallintamenetelmät.
3 (9) 3 Riskiskenaariot 3.1 Riskin vakavuuden arviointi Riskienhallintaryhmä arvioi mahdollisille projektia uhkaaville riskeille kaksi lukua: todennäköisyyden ja vaikutuksen. Luvut saavat arvon väliltä 1-5, jossa todennäköisyydelle 1 tarkoittaa erittäin epätodennäköistä ja 5 erittäin todennäköistä toteutumista. Vaikutus saa arvon 1, jos se ei käytännössä vaikuta projektin etenemiseen mitenkään, ja 5 jos se tarkoittaa toteutuessaan projektin keskeytymistä. 3.2 Mahdolliset skenaariot Alla olevaan taulukkoon on kerätty riskienhallintaryhmän mielestä projektia mahdollisesti uhkaavat riskit. Mahdolliset skenaariot ID Riski Todenn. Vaikutus Tulo R001 Odottamaton pitkä poissaolo 3 2 6 R002 Kommunikaatio ei toimi ryhmän sisällä 3 3 9 R003 Yksi lopettaa kurssin kesken 2 2 4 R004 Kaksi tai useampi lopettaa kurssin kesken 1 5 5 R005 Ennalta tuntematon projektiryhmä, henkilökemiat ei toimi 4 2 8 R006 Tunteja ei kirjata 4 2 8 R007 Resurssointi tehty väärin 2 4 8 R008 Ei ymmärretä asiakkaan tarpeita 2 5 10 R009 Asiakas ei tiedä mitä haluaa 1 5 5 R010 Force major (tulipalo, meteoriitti, venäjä hyökkää) 1 5 5 R011 Asiakkaan avainhenkilö vaihtuu 1 3 3 R012 Asiakkaan tekninen asiantuntija vaihtuu 1 5 5 R013 Sovitut vaatimukset muuttuvat 2 4 8 R014 Vaatimuksia tulee merkittävästi lisää 3 3 9 R015 Toteutusteknologia aiheuttaa ongelmia 4 3 12 R016 Ohjelmoijalle tuntematon teknologia aiheuttaa ongelmia 5 3 15 R017 Olemassa oleva Rauinfo ympäristö aiheuttaa rajoitteita 1 5 5 R018 Käytetään liikaa opiskeluun 4 4 16 R019 Yksittäinen laite hajoaa 2 2 4 R020 Useampi laite hajoaa 1 4 4 R021 Käytössä olevat kolmet avaimet ovat yhtäaikaa "kaupungilla" 2 3 6 R022 CVS palvelin hajoaa (vanha backup?) 2 3 6 R023 CVS palvelin hajoaa, backup ei palaudu 1 5 5 R024 Resurssoituja tunteja ei ehditä käyttää 3 3 9 R025 Resurssoidut tunnit käytetään epätehokkaasti 3 3 9
4 (9) R026 Ei toimita tarpeeksi proaktiivisesti 4 3 12 R027 Asiakkaalle palautettava tuote on liian keskeneräinen 4 4 16 R028 Ylläpitoliittymää ei ehditä tehdä valmiiksi 4 4 16 3.3 Vakavimmat riskit Vakavimmat riskiskenaariot, ja niiden hallintasuunnitelmat ovat seuraavissa kappaleissa. Yleisesti sanottuna hyviksi riskinhallintamenetelmiksi näyttäisi osoittautuvan seuraavat käytännöt: - Pariohjelmointi - Yhteiset työajat Yllämainitut käytännöt liittyvät hyvin oleellisesti kommunikointiin, tietouden levittämiseen projektiryhmän kesken ja epäselvien asioiden mahdollisimman yksinkertaiseen selvittämiseen. 3.3.1 R018 Käytetään liikaa opiskeluun - Arkkitehtuurin suunnittelu venyy liikaa, jolloin kehittäjät eivät pääse "oikeisiin" töihin suunnitellun aikataulun mukaan. - Ei saada tietoa jakautumaan koko ryhmän kesken - Opiskellaan turhia asioita, joita ei itse tulla tarvitsemaan - ALL: Pyydetään apua epäselviin asioihin - ALL: Annetaan tukea arkkitehtuurin suunnitteluun - AA/KR/PS/JW: Pariohjelmoinnilla jaetaan kehittäjien osaamista - JI: lisätään arkkitehtuurin suunnitteluun - ALL: Työskennellään yhdessä jolloin tieto jakautuu helpommin - JI: Riittävän pieniin osiin jaettujen tehtävien vastuiden jakaminen oikeille ihmisille. - JI: Seurataan tuntiraportteja viikon tarkkuudella (torstain viikkopalaverin yhteydessä) Tilanne: Toteutunut ja hallinnassa. Tärkeimmät hallintamenetelmät lihavoituna yläpuolella. Skenaarion toteutumisen on aiheuttanut lihavoitu tekijä. 3.3.2 R016 Ohjelmoijalle tuntematon teknologia aiheuttaa ongelmia - Lähdetään joko suunnittelemaan tai toteuttamaan sovellusta väärästä näkökulmastä - Varsin dynaamisten lomaketietojen välittäminen Strutsin läpi aiheuttaa ongelmia - Perusarkkitehtuurin sovittaminen Rauinfoon vie paljon aikaa - AA/KR/PS/JW: Pariohjelmoinnilla estetään väärien valintojen tekemistä
5 (9) - ALL: Työskennellään yhdessä jolloin tieto jakautuu helpommin - ALL: Työskennellään yhdessä, asiakkaan tiloissa, jolloin saatavissa tukea asiakkaan tekniseltä asiantuntijalta - JI: Jakaa ryhmälle tietoutta SVG/XML-teknologioista Tilanne: Toteutunut ja seurannassa. Hallintamenetelmät lihavoituna yllä. Skenaarion toteutumisen on aiheuttanut lihavoitu tekijä. 3.3.3 R015 Toteutusteknologia aiheuttaa ongelmia - SVG:llä ei pysty tekemään haluttua toimintoa - SVG-grafiikka osoittautuu liian raskaaksi koko piirrustuksen pyörittämiseen. Monimutkaiset pohjapiirustukset kasvavat valtavan kokoisiksi. Yksi kerros asiakkaan pohjapiirustuksesta kääntyi 1 Mt kokoiseksi SVG-tiedostoksi. - KR: SVG-konversiotyökalujen kartoitus - KR: Mahdollisesti kompressio SVG-tiedostoille. - JI/ML: Proof of concept (Osoitti jo ketjun periaatetasolla toimivan) - KR: AutoCAD tietouden lisääminen (mm. "turhien" osien jättäminen pois COTOOLissa käytettävästä piirrustuksesta) - PS: Mahdollisesti liian raskaan pohjapiirustuksen huomioon ottaminen käyttöliittymäsuunnittelussa (mm. jakaminen pienempiin osiin) Tilanne: SVG-tiedostot saattavat tulla liian raskaiksi. Tutkitaan mahdollisuuksia, kts. yllä. 3.3.4 R008 Ei ymmärretä asiakkaan tarpeita - PP vaiheen tietous ei valu eteenpäin - Ei lueta PP-vaiheen dokumentaatiota (Projektisuunnitelma & vaatimusmäärittely) - Ei käytetä iteraatiodemojen palautetta hyväksi. - Ei kuunnella palautetta testauksesta - JI/TH/ML: Pyritään antamaan PP-vaiheen tietoutta mahdollisimman kattavasti myös suullisesti, ei pelkästään dokumentaation avulla. - AA/TH: Testauskäytäntöihin myös tapa saada palaute tekijöille. - JI/TH: Riittävä kommunikaatio asiakkaan kanssa - JI: Toteutusiteraatioiden jakaminen pienempiin osiin mahdollistaa myös asiakkaan tarpeiden helpomman ymmärtämisen (selkeä palaute useammin ja silloin kun asialle voi vielä tehdä jotain). - ALL: Luetaan dokumentaatio - ALL: Ollaan paikalla iteraatiodemoissa Tilanne: Hallinnassa.
6 (9) 3.3.5 R002 Kommunikaatio ei toimi ryhmän sisällä - Ei tunneta etukäteen toisiamme - Pelkkä sähköposti ei riitä tietouden levittämiseen - Ei työskennellä yhteissä sessiossa - ALL: Viikkopalaveri - AA/KR/PS/JW: Pariohjelmoinnissa myös kommunikaatio toimii paremmin - ALL: Sitoudutaan yhteisiin työsessioihin Tilanne: Hallinnassa, kunhan ihmiset sitoutuvat yhteisiin työsessioon. 3.3.6 R014 Vaatimuksia tulee merkittävästi lisää - Ei sitouduta vaatimusmäärittelyn ja iteraatiotavoitteiden määrittelemään sisältöön. - Ei osata sanoa "ei" - TH: Vaatimusten priorisointi - JI/TH: Riittävä kommunikaatio asiakkaan kanssa - JI: Toteutusiteraatioiden jakaminen pienempiin osiin pienentää myös riskejä vaatimusten osalta. - JI: Realistiset tavoitteet iteraatioille Tilanne: Hallinnassa. 3.3.7 R026 Ei toimita tarpeeksi proaktiivisesti - Ei saavuta yhteisiin työsessioihin - Kommunikaatio ei pelaa tarpeeksi hyvin ryhmän sisällä - JI/TH: Kannustaminen aktiivisuuteen, vastuunottoon ja itsenäisiin päätöksiin. - All: pyritään olemaan aktiivisempia ja kysymään tarvittaessa. Tilanne: Toteutunut. Ei olla uskallettu tehdä itsenäisiä päätöksiä eikä kysyä ongelmakohtia. Tilanne on kuitenkin nyt kuitenkin saatu paremmin haltuun.
7 (9) 3.3.8 R027 Asiakkaalle palautettava tuote on pahasti keskeneräinen - Ei saada tehtyjä tarpeeksi tunteja - Työtunnit käytetään epätehokkaasti - Teknologiset ongelmat - Pyritään toteuttamaan liian monia ominaisuuksia - Ryhmän jäsenen poisjääminen - JI: Huolehtii, että kaikki käyttävät resursoidut tunnit - All: Pyritäään työskentelemään tehokkaasti - TH: Priorisoi vaatimuksia - All: Tehdään tärkeimmät ominaisuudet ensin ja se mitä tehdään, pyritään tekemään kunnolla. - JI: Otetaan yhteyttä kurssin henkilökuntaan ja tiedustellaan toimintaneuvoja Tilanne: Osittain toteutunut. Ominaisuuksista ollaan jouduttu tinkimään. Rooleja jouduttiin vaihtamaan kesken työn, johon kului aikaa lisäksi eräs ryhmän jäsenistä ei ehtinyt panostamaan kurssiin sovittua määrää aikaa. Tällä hetkellä riski on kuitenkin hallinassa. Kurssin henkilökunnalta kysyttiin neuvoja, jotka auttoivat. Lisäksi asiakasta informoitiin tapahtuneesta ja vaatimuksia priorisoitiin. 3.3.9 R028 Ylläpitoliittymää ei ehditä tehdä valmiiksi - Ei saada tehtyjä tarpeeksi tunteja - Työtunnit käytetään epätehokkaasti - Ryhmän jäsenen poisjääminen - JI: Huolehtii, että kaikki käyttävät resursoidut tunnit - All: Pyritäään työskentelemään tehokkaasti - TH: Priorisoi vaatimuksia - JI/TH: Informoidaan asiakasta tilanteesta ja priorisoidaan toteutettavat ominaisuudet Tilanne: Toteutunut. Ylläpitokäyttöliittymästä joudutaan tinkimään todella paljon. Tarkoitus kuitenkin on, että pyritään toteuttamaan niin paljon kuin ehditään ja ainakin oleellisimmat ominaisuudet.
8 (9) 4 Alla olevaan taulukkoon kerätään realisoituneet riskit ID Riski Pvm Kuvaus Toiminta Tila R018 R016 R018 R016 R018 Käytetään liikaa opiskeluun Ohjelmoijalle tuntematon teknologia aiheuttaa ongelmia Käytetään liikaa opiskeluun Käytetään liikaa opiskeluun Käytetään liikaa opiskeluun 9.11.2005 Huomattiin, että arkkitehtuurin suunnittelu on venynyt liikaa 9.11.2005 Huomattiin, että tunteja on raportoitu valtavasti tehtäviin OP003, SU003 ja TO001. (Rauinfo opiskelu, Demo servletti kehitysympäristöön koulutusta varten ja staattinen demo rauinfoon) 24.11.2005 Huomattiin, että arkkitehtuurin suunnittelu venyy edelleen liikaa. 2.12.2005 Havaittiin, että edelleen sovellusosan sovittaminen Rauinfoon aiheuttaa turhan paljon palaneita tunteja.. 15.01.2005 Huomattiin, että edelleen aikaa kului liikaa opiskeluun. Lisättiin huomattavasti arkkitehtuurille. Annetaan apuja arkkitehdille työn alkuun saamiseksi. Tähdennetään parityöskentelyn tärkeyttä jotta tietous saataisiin mahdollisimman kevyellä työmäärällä valumaan eteenpäin. Rauninfon "hankaluus" kehittäjille on valitettava tosiasia, ja se vain pitää ottaa huomioon tehtäviä resursoitaessa. Seurannassa Seurannassa Sovelletaan Hallinnassa projektissa osittain "Evolutiivinen kehitys, yksinkertainen suunnittelu ja refaktorointi"-menetelmää. Rohkaistaan kehittäjiä pyytämään apua asiakkaan tekniseltä asiantuntijalta. Pyydettiin kehittäjiä kysymään Petriltä mahdollisimman paljon. Seurannassa Hallinnassa
9 (9) R016 Ohjelmoijalle tuntematon teknologia aiheuttaa ongelmia. 15.01.2005 Huomattiin ettei arkkitehdin kompetenssi ja aika riittänyt. Lisättiin huomattavasti arkkitehtuurille. Vaihdettiin kehittäjä arkkitehdin paikalle. Hallinnassa R026 Ei toimita tarpeeksi proaktiivisesti. 15.01.2005 Huomattiin että ryhmässä ei pystytty olemaan tarpeeksi oma-aloitteisia eikä tehdä itsenäisiä päätöksiä. Kannustettiin päätöksen tekoon ja tiedustelemaan asioista suoraan Petriltä. Hallinnassa R027 Asiakkaalle palautettava tuote on pahasti keskeneräinen. 06.02.2005 Huomattiin ettei tuotteeseen millään ehditä tehdä kaikkia sovittuja ominaisuuksia. Kannustettiin tehokkaampaa työntekoon. Informoitiin asiakasta ja sovittiin omaisuuksien priorisoinnista. Seurannassa R028 Ylläpitoliittymää ei ehditä tehdä valmiiksi 06.02.2005 Huomattiin ettei aika riitä toimivan ylläpitoliittymän tekemiseen. Kannustettiin tehokkaampaan työntekoon. Informoitiin asiakasta ja sovitiin tärkeimpien ominaisuuksien tekemisestä. Lisäksi pyritään tekemään muita ominaisuuksia niin paljon kuin ehditään. Seurannassa 5 Viitteet Kaikki internet-viittaukset avautuvat uuteen ikkunaan. 1. http://www.soberit.hut.fi/t-76.115/05-06/ohjeet/process.html#risk_management, 13.10.2005