Projektiryhmä Tete:n riskienhallintaryhmä
T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 2(8) Muutoshistoria Versio PVM Tekijä Kuvaus 0.10 11.01.2004 Mika Lindroos Ensimmäinen versio dokumentista riskienhallintasuunnitelman pohjalta. 2.00 16.02.2004 Mika Lindroos Toinen versio dokumentista I2-vaiheen kokemusten perusteella. 3.00 21.03.2004 Mika Lindroos Kolmas versio dokumentista I3-vaiheen kokemusten perusteella.
T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 3(8) Sisällysluettelo Muutoshistoria... 2 Sisällysluettelo... 3 1 Johdanto... 4 2 Riskienhallintakäytännöt... 4 3 Kokemuksia riskienhallinnasta... 5 3.1 I1-vaihe... 5 3.2 I2-vaihe... 6 3.3 I3-vaihe... 7 Viitteet... 8 Liitteet... 8
T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 4(8) 1 Johdanto Tämä dokumentti on kirjoitettu kurssia T-76.633 Ohjelmistotuotannon erikoiskurssi: Riskienhallinta varten. Tässä dokumentissa kuvataan T-76.115 Tietojenkäsittelyopin ohjelmatyö-kurssin projektiryhmä Teten projektin aikana käytettyjä riskienhallintakäytäntöjä ja kokemuksia niiden käytöstä. Projektin riskienhallinnan tarkoituksena on tunnistaa ja ennen kaikkea varautua projektin aikana mahdollisesti ilmeneviin ongelmiin. Tunnistamalla mahdolliset ongelmat eli riskit hyvissä ajoin on niihin mahdollista myös varautua hyvissä ajoin. Tällöin ongelmat voidaan mahdollisesti välttää kokonaan tai ainakin niiden vaikutusta voidaan pienentää. Varautumalla riskeihin jo ennakkoon vältytään toivon mukaan siltä, että kaikki aika menisi havaittuihin ongelmiin reagoimisessa, eikä varsinaisessa tavoitteellisessa kehitystyössä. 2 Riskienhallintakäytännöt Riskienhallinnasta yleisellä tasolla projektissa vastaa Mika Lindroos yhdessä muun riskienhallintaryhmän kanssa. Tähän ryhmään kuuluvat lisäksi Niilo Fredrikson, Tuomas Heino ja Marc Josefsson. Lisäksi yksittäisille havaituille riskeille on nimetty vastuuhenkilöt siten, että jokaisesta riskistä vastaa henkilö, jonka vastuualueeseen riski kuuluu. Riskienhallinnassa sovelletaan Riskit-menetelmää riskien identifioinnissa ja Riskit Paretoluokittelumenetelmää[1] niiden priorisoinnissa. Riskejä hallitaan riskienhallintaryhmän toimesta erillisissä kokouksissa. Näitä kokouksia pyritään järjestämään säännöllisesti kerran kuukaudessa (vastaa keskimäärin yhtä kertaa iteraatiota kohden). Tarpeen vaatiessa myös kuka tahansa muu ryhmäläinen, ryhmän asiakas tai ryhmän mentor voivat kutsua riskienhallintaryhmän koolle. Kokouksissa käydään läpi projektin ja seurannassa olevien riskien tila. Lisäksi käydään läpi onko tullut esiin uusia riskejä tai uusia tekijöitä, jotka vaikuttaisivat vanhoihin jo seurannassa oleviin riskeihin. Riskienhallinnalla pyritään seuraamaan projektin suorittamisen kannalta merkittäviä riskejä. Riskien hallinnassa mukana olevat riskit on valittu siten, että niiden todennäköisyys tai kriittisyys on merkittävä. Hyvin epätodennäköiset tai merkityksettömät riskit on jätetty kokonaan systemaattisen tarkkailun ulkopuolelle, koska näihin varautuminen voisi viedä huomattavan määrän resursseja verrattuna saavutettavaan hyötyyn. Ensimmäisessä vaiheessa on keskityttiin tunnistamaan mahdollisimman suuri määrä projektiin liittyviä riskejä. Riskienhallintaryhmä kokoontui ensimmäisen toteutusvaiheen (I1) aikana analysoimaan tunnistettuja riskejä ja luokitteli ne prioriteetin mukaan. Tunnistettujen riskien osalta käytiin myös läpi ovatko ne jo jollain tasolla toteutuneet ja riskiryhmän ennuste siitä, mihin suuntaan riskin prioriteetti on kehittymässä tulevaisuudessa. Prioriteetin kehittymiseen suuntaan tai toiseen vaikutti sekä riskin todennäköisyyden että riskin realisoitumisesta aiheutuvan vahingon muuttuminen ajan kuluessa. I2-vaiheen aikana riskienhallintaryhmä kokoontui jälleen käymään läpi projektin läpivientiin liittyviä riskejä. Riskejä identifioitaessa käytettiin hyödyksi projektin aiemmissa vaiheissa tunnistettujen riskien listaa yhdistettynä lisääntyneeseen kokemukseen projektin kokonaisedistymisestä. Tämä lähestymistapa osoittautui erittäin toimivaksi ja ryhmä kykeni sekä identifioimaan uusia riskejä että toteamaan joitakin vanhoja riskejä epärelevanteiksi tässä vaiheessa projektia. Tarkempaa analyysia riskienhallinan tuloksista seuraavassa kappaleessa. I3-vaiheen lopussa riskiryhmä toimi riskienhallintatoimenpiteiden suhteen lähes identtisesti I2-vaiheeseen verrattuna. Hyväksi havaittua menetelemää riskien identifioinnista ja seurannasta vanhojen riskien pohjalta
T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 5(8) hyödynettin myös tässä vaiheessa. Merkittävin havainto oli se, että tässä vaiheessa projektia suuria muutoksia itse projektiin ei enää tullut ja tämä puolestaa auttoi merkittävästi myös riskienhallinnasta. On huomattavasti helpompi käsitellä projektin riskejä suhteellisen staattisessa ympäristössä kuin nopeasti muuttuvien vaatimusten ja muiden tekijöiden keskellä. Suurempia yllätyksiä ei tullut koko iteraation aikana, mutta tästä taas tarkemmin seuraavassa kappaleessa. Seuraava vaihe eli toimitusvaihe (DE) on samalla myös koko projektin viimeinen vaihe ja siten luonteeltaan varsin erilainen aiempiin vaiheisiin verrattuna. Sen lopussa ei ole enää niinkään merkittävää tunnistaa projektin uusia riskejä, koska koko projekti periaatteessa päättyy iteraation loppuun. Sen sijaan on hyvä käydä koko projektin aikana identifioidut riskit läpi ja tarkastella niiden kehitystä. Näiden avulla voidaan mahdollisesti parantaa kyseisten riskien hallintamenetelmiä tulevia projekteja varten ja toivottavasti välttää tässä projektissa toteutuneet riskit kokonaan vastaisuudessa. Mikäli toimitusvaiheen aikana kuitenkin ilmenee jotain yllättävää, voidaan riskienhallintaryhmä toki edelleen kutsua kokoon tarvittaessa. 3 Kokemuksia riskienhallinnasta 3.1 I1-vaihe Ryhmän tähänastiset kokemukset riskienhallinnasta ovat melko positiivisia, vaikka toki joitakin ongelmiakin on esiintynyt. Riskienhallinta on paikoitellen toiminut erittäin hyvin ja merkittäviä ongelmia on onnistuttu välttämään, mutta myös parannettavaa on löydetty kurssin aikana. Yksi suurimmista toistaiseksi ilmenneistä ongelmista olisi voitu todennäköisesti välttää tehokkaampien riskienhallintamenetelmien käytöllä. Tämä kyseinen ongelma esiintyi kuitenkin aivan kurssin alkupäässä ja riskienhallintakaan ei ollut kunnolla käynnistynyt, joten liian suurena epäonnistumisena tätäkään ei voi pitää. Tiivistettynä ongelma piti sisällään kehitysympäristön pystyttämiseen kuluneen arvioitua suuremman työmäärän, joka olisi ollut mahdollista välttää tarkemmalla ohjeistuksella ja huolellisemmalla ryhmän sisäisellä viestinnällä. Tämä ongelma käytiin jälkikäteen läpi ja parannettiin toimintatapoja ohjeistuksen osalta myöhempiä tilanteita varten. Tämän jälkeen ohjeistus onkin toiminut huomattavasti paremmin ja vastaavia ongelmia ei ole kohdattu. Yhtenä merkittävä riskienhallinan osana voidaankin pitää toteutuneiden ongelmien tiedostamista ja niiden toistumisen ehkäisemistä tulevaisuudessa. Yhtenä riskienhallinan suurimmista menestyksistä toistaiseksi voidaan taas pitää testipalvelimen toimitukseen liittyneiden ongelmien käsittelyä. Lyhyenä yhteenvetona ongelmana oli asiakkaan lupaaman testipalvelimen toimituksen myöhästyminen sekä teknisten että logististen ongelmien takia. Tähän oltiin kuitenkin varauduttu riskienhallinan toimesta pystyttämällä jokaisen ryhmäläisen kotikoneelle täydellinen kehitysympäristö, jota voitiin käyttää myös testaustarkoituksiin. Tämän ansiosta ryhmä pystyi varsin tehokkaaseen työskentelyyn myös testipalvelimen viivästymisen aikana ja olisi hätätilassa kyennyt viemään jopa koko projektin läpi ilman kyseistä testipalvelinta. Nyt testipalvelin on kuitenkin täydessä toimintakunnossa ja siten riskienhallinnan voidaan todeta onnistuneen loistavasti kyseisen riskin käsittelyssä. Kaiken lisäksi ryhmäläisillä on ympäristöt kotikoneillaan edelleen käytössä, mikäli myöhemmässä vaiheessa testipalvelin aiheuttaisi vielä lisää ongelmia. Yhteenvetona ryhmän tähänastisista kokemuksista voisi todeta, että riskienhallinta on sopivassa mittakaavassa tehtynä hyödyllistä ja merkittävä osa projektin onnistumista. On tärkeää kiinnittää huomiota siihen, että käytettävät riskienhallintamentelmät ovat suhteessa projektin tarpeisiin. Ryhmämme projektissa ei ole kannattavaa käyttää kaikkein raskaimpia menetelmiä, koska kyseessä ei ole turvallisuuskriittinen järjestelmä ainakaan ihmishenkien tasolla. Käytössä olevat Riskit-menetelmät[1] ovat osoittautuneet varsin toimiviksi ja sopivaksi kompromissiksi mentelmän ilmaisuvoiman ja helppokäyttöisyyden suhteen. Riskien identifioinnissa brainstorming-tilaisuudet ovat osoittautuneet hyväksi menetelmäksi lukuisien ideoiden saamiseksi, mutta muutenkin olemme todenneet riskienhallinnan olevan tehokkaimmillaan ryhmässä. Erityisesti riskien vakavuuksien määrittämisessä tarvitaan useampi näkökulma, koska riskin merkitys saattaa vaihdella hyvinkin runsaasti riippuen siitä katsotaanko sitä esim. asiakkaan vai ryhmän näkökulmasta. Tässä
T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 6(8) priorisoinnissa käytetty Riskit Pareto menetelmä on mielestämme erittäin kätevä, koska se on riittävän helppokäyttöinen riskienhallintaryhmän käytettäväksi aktiivisesti ja lisäksi niin selkeä, että sen avulla voidaan kommunikoida myös asiakkaan suuntaan. Kaiken kaikkiaan luottamuksemme riskienhallintaa kohtaan on varsin hyvä tällä hetkellä, mutta jatkamme sen toimivuuden tarkkailua aktiivisesti ja teemme tarvittavia korjauksia projektin edetessä. 3.2 I2-vaihe I2-vaiheessa riskienhallinnassa jatkettiin samojen mentelmien käyttöä kuin aiemminkin ja niistä ei ole juurikaan uutta sanottavaa verrattuna edelliseen kappaleeseen. Riskien identifioinnissa käytettiin jonkin verran hyödyksi jo olemassa olevaa riskilistaa mm. uusien riskien identifioinnissa. Lisäksi vanhoja riskejä läpikäytäessä todettiin osan niistä muuttuneen projektin edetessä epärelevanteiksi ja osan olevan relevantteja vasta myöhemmässä vaiheessa projektia. Tämä vanhoihin riskeihin pohjautuva menetelmä vaikutti ainakin ensimmäisten kokemusten perusteella varsin hyvältä ratkaisulta ja tätä tultaneen käyttämään myös tulevissa vaiheissa. Seuraavaksi hieman tarkempaa läpikäyntiä riskien kehittymisestä I2-vaiheen aikana. Riskienhallinan helpottamiseksi käytiin identifioidut riskit huolella läpi epärelevanttien riskien löytämiseksi joukosta. Tällaisiksi riskeiksi luokittelimme seuraavat riskit: kehitysympäristön pystyttäminen kaikille viivästyy tai epäonnistuu Tässä vaiheessa projektia kehitysympäristö on jokaisella ryhmäläisellä käytössä ja lisäksi yhteinen testipalvelin on saatu toimintakuntoon. Näin ollen kyseinen riski ei ole enää ajankohtainen. testipalvelimen toimituksessa tulee ongelmia Testipalvelin on saatu täyteen toimintakuntoon ja ongelmia ei ole esiintynyt sen käytössäkään. Näin ollen testipalvelin voidaan katsoa toimitetuksi ja kyseinen riski on menettänyt merkityksensä. Mentorin aikatauluvaatimukset eivät sovi yhteen projektiyhmän kanssa Tässä vaiheessa projektia mentor-tapaamisten merkitys on muuttunut melko pieneksi ja näinollen jokaisen ryhmäläisen ei ole välttämätöntä päästä tapaamisiin, mikäli esteitä esiintyy. Lisäksi mentorin kanssa on löydetty yhteiset ajat hyvin helposti projektin aikaisemmissakin vaiheissa, joten tämän riskin käytännön merkitys oli muuttunut olemattoman pieneksi. Epärelevanttien riskien lisäksi totesimme muutaman riskin olevan ajankohtaisia vasta projektin myöhäisemmissä vaiheissa. Nämä riskit ovat: esiintyy yhteensopivuusongelmia kehitys- ja tuotantoympäristöjen välillä Vielä I3-iteraatiossa emme ole tekemisissä varsinaisen tuotantoympäristön kanssa, joten ainoat mahdolliset riskienhallintatoimenpiteet ovat yleistä yhteensopivuuden varmistamista koodi- ja järjestelmätasoilla. On mahdollista, että varsinaista tuotantoympäristöä ei saada käyttöön koko projektin aikana tai aikaisintaan toimitusvaiheen aikana. Tällöin riski on mahdollista ottaa uudelleen mukaan aktiivisempaan käsittelyyn. asiakkaan kanssa tulee sopimusoikeudellisia ongelmia Ryhmällä ei ole ollut ongelmia asiakkaan kanssa ja projektin ollessa jo tässä vaiheessa on asiakkaan vetäytyminen erittäin epätodennäköistä. Lisäksi kurssi olisi mahdollista viedä läpi tästä eteenpäin jo ilman asiakasta, joten tällä hetkellä sopimusongelmat eivät ole ajankohtaisia. On kuitenkin mahdollista, että projektin tuotosten oikeuksista syntyy epäselvyyttä projektin lopussa, joten siitä syystä tämä riski on syytä ottaa uudelleen lähempään tarkkailuun projektin loppupuolella. Riskienhallinan menestykseen I2-vaiheen aikana voidaan olla varsin tyytyväisiä. Useita potentiaalisia ongelmia, mutta tehokkailla riskienhallintatoimilla näistä aiheutuneet käytännön haitat onnistuttiin minimoimaan. Usean eri riskin osittaisesta toteutumisesta (mm. projektin jäsenen lyhytaikainen sairastuminen, joululoman aiheuttama ryhmän jäsenillä liian vähän aikaa käytettävissä kun tarvitaan ja tunteja ei ehditä tiukan kalenteriaikataulun takia käyttää) huolimatta projektin I2-vaihetta voidaan pitää aikaansaannosten valossa onnistuneena ja pysyneen budjetissa erittäin hyvin. Erityisen tehokkaana
T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 7(8) menetelmänä kyseisten aikatauluongelmien hallinnassa oli projektipäällikön käymät kehityskeskustelut kyseisten ryhmäläisten kanssa, joiden avulla onnistuttiin sovittamaan yhteen projektin tavoitteet ryhmäläisten aikataulujen kanssa suhteellisen onnistuneesti. Suurimpana havaittuna riskienhallinnan menestyksenä I2:ssa oli kuitenkin koulutuksen onnistuminen aikaisempien iteraatioiden aikana. Ryhmä käytti kohtuullisen suuren määrän työtunteja melko kattavan koulutuksen järjestämiseen ja tämä osoittautui kannattavaksi ratkaisuksi I2:sen aikana. Tämä koulutus yhdistettynä pariohjelmoinnin käyttöön projektin alkuvaiheessa tarjosi kokemattomammillekin ryhmän jäsenille erinomaisen keinon tutustua käytettäviin teknologioihin ja helpon sisäänpääsyn järjestelmän kehittämiseen. Näin ollen I2-vaiheessa useimmat ryhmäläiset kykenivät itsenäiseen järjestelmän kehittämiseen ja tätä voidaan pitää erittäin hyvänä suorituksena, ottaen huomioon käytettävien teknologioiden suurehkon määrän ja niiden tuntemattomuuden ryhmäläisten keskuudessa projektin alkaessa. 3.3 I3-vaihe I3-vaiheessa jatkettiin samojen riskienhallintamenetelmien käyttöä kuin projektin aikaisemmassakin vaiheessa. I2-vaiheessa hyväksi havaittu riskien identifiointi ja niiden seuranta olemassaolevien risien pohjalta jatkui I3-vaiheen aikana, eikä sen käytössä havaittu ongelmia tässäkään vaiheessa. I3-vaiheen aikana ei enää tunnistettu merkittäviä uusia riskejä, mutta muutaman vanhan riskin merkityksen todettiin jälleen muuttuneen. Näistä tarkemmin seuraavaksi. I3-vaiheen aikana merkittävät muutokset riskien tilassa: työasemien/työkalujen käyttö tuottaa ongelmia Tässä vaiheessa projektia käytetyt työkalut ovat jo niin tuttuja kaikille ryhmäläisille (tai ainakin omaan vastuualueeseen liittyviltä osiltaan), että tämän riskin todennäköisyys ja siten prioriteetti vähenivät entisestään. sähköpostiongelmat haittaavat viestintää Ryhmä käytti tiiviiden aikataulujen johdosta aiempaa enemmän puhelinta viestintään. Lisäksi sähköpostit ovat enimmäkseen toimineet hyvin viime aikoina. Ainoastaan asiakkaan suuntaan on ollut sähköpostiongelmia. Tästä syystä riskin todennäköisyyttä pienennettiin vähän. järjestelmän käyttö hankaloituu mahdollisten tietoliikenneongelmien ilmentyessä Tämä riski lisättiin uutena seurantaan, koska erityisesti iteraation lopussa tapahtuvassa demossa tämän merkitys voi olla varsin suuri. Mikäli demossa ilmenee tietoliikenneongelmia, voi tämä antaa täysin väärän kuvan itse ohjelman suorituskyvystä. Tämä riski on merkittävä ennenkaikkea viimeisessä iteraatiossa, koska palautusiteraation loppudemon tarkoituksena on esitellä käytännössä koko projektin lopputuloksena syntynyt ohjelmisto. ryhmän jäsenillä on liian vähän aikaa käytettävissä projektiin silloin kun tarvitaan Tämän riskin vahinkoa ja siten prioriteettia pienennettiin hieman. Tämä johtuu lähinnä siitä, että projektin ollessa jo näin pitkällä, ei yksittäisen ryhmäläisen panos enää ole yhtä kriittinen kuin aiemmin. Suurin osa ryhmäläisistä on jo käyttänyt merkittävän osan kokonaistyömäärästään ja siten loppuosan käyttämättä jääminen ei olisi kuin muutaman tunnin menettäminen projektin kokonaistyömäärästä. vaatimukset muuttuvat merkittävästi projektin aikana Tämän riskin todennäköisyyttä pienennettiin, koska asiakas tuntuu hyvin ymmärtäneen projektin olevan loppusuoralla ja siten keskitytään lähinnä nykyisten ominaisuuksien hiomiseen, eikä enää uusien vaatimusten toteuttamiseen. ryhmäläisten osaaminen ole ei riittävän korkealla tasolla kaikkien käytettävien tekniikoiden ja työkalujen osalta, ryhmän jäsenten erilainen kokemustausta ja osaaminen voi aiheuttaa ongelmia Tämän riskin todennäköisyyttä ja sen myötä myös prioriteettia pienennettiin, koska ryhmäläiset ovat perehtyneet projektin edetessä käytettäviin tekniikoihin, eivätkä ne siten ole enää uusia ja tuntemattomia kuten projektin alkupuolella. Toki vaikeammissa asioissa edelleen kaivataan kokeneempien ohjeistusta, mutta perusominaisuudet ovat jo lähes kaikilla hallussa.
T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 8(8) projektipäällikkö joudutaan vaihtamaan projektin aikana Tämän riskin vahinkoa ja prioriteettia pienennettiin. Myös projektipäällikkö on tässä vaiheessa projektia käyttänyt suurimman osan työmäärästään ja jäljellä olevan työn voisi tarvittaessa hoitaa myös joku muu ryhmäläinen. On kuitenkin huomioitava, että asiakas on tottunut kommunikoimaan projektipäällikön kanssa ja siten projektipäällikön vaihtuminen toki hankaloittaisi ryhmän toimintaa jonkin verran. I3-vaiheessa riskienhallinnan voidaan katsoa onnistuneen myös varsin hyvin. Tästä ehkä parhaimpana todisteena se, että riskienhallinnasta ei ole juurikaan uutta kerrottavaa enää tässä vaiheessa. Se toimi suhteellisen näkymättömissä, mutta ilmeisen tehokkaasti, sillä projektiin ei tullut odottamattomia muutoksia. Tarkemmin sanottuna projektiin ei itse asiassa tullut ylipäätänsä suurempia muutoksia. Tätä voidaan pitää hyvän projektin- ja riskienhallinnan merkkinä, sillä tietyssä määrin olisi syytä olla huolissaan, jos projektiin tulisi kovin merkittäviä muutoksia vain pari viikkoa ennen sen päättymistä. Jos joitain merkittävimpiä riskienhallintamenetelmiä kuitenkin halutaan huomioida niin esille nousevat lähes samat asiat kuin I2- vaiheessakin. Aikatauluongelmien välttämiseksi projektipäällikkö selvitti henkilökohtaisesti loppuprojektin työmäärien jakautumista sellaisten ryhmäläisten kanssa, joilla on vielä merkittävä osa työtunneista käyttämättä. Asiakkaan tyytyväisyyden takaamiseksi puolestaan järjestettiin asiakkaan organisaatiossa tapahtuvaa järjestelmän testausta, jota jatketaan myös projektin viimeisen vaiheen aikana. Lisäksi tässä iteraatiossa oli jälleen jonkin verran sähköpostiongelmia asiakkaan suuntaan, mutta tästä selvittiin projektipäällikön hoitaessa yhteydet asiakkaaseen tarvittaessa puhelimen välityksellä. Sen sijaan ryhmäläisten osaamistasosta ei enää tässä vaiheessa olla kovinkaan huolissaan kun suurin osa toiminnallisuutta on jo saatu toteutettua ja jäljellä on enää vain viimeinen hiominen. Viitteet [1] Risk Management T-76.633-luentokalvot, s.14, Jyrki Kontio, viitattu 21.11.2003, http://www.soberit.hut.fi/t-76.115/03-04/ohjeet/lectures/t-76.633_rm2nd.pdf Liitteet