Riskeistä Luennon tavoitteista Luennon sisällöstä Motivointia Riskilistoja, tapoja käsitellä riskejä Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Tony Moynihan, Coping with IS/IT risk management Somerville, Software Engineering Alkuperäiset kalvot: Isto Aho, päivityksiä: Timo Poranen. 1
Tavoitteista Luentojen jälkeen opiskelijan tulisi osata: Tunnistaa eri riskikategorioita. Tietää riskienhallintaprosessin perusteet. Tunnistaa tärkeimpiä riskejä ja riskityyppejä. Arvioida riskienhallintaprosessin onnistumista. 2
Sisällöstä Tavoitekalvon asioita. Riskienhallintaprosessissa: Riskien havaitseminen. Riskien analysointi. Riskeihin varautuminen (riskien hallinta). Riskien seuranta (monitorointi). Lisäksi esitetään tavallisimpia projektiongelmia ja niiden syitä. 3
Motivointia Riskit voivat vaikuttaa projektiin aikatauluun ja tuotoksen laatuun. Tavallisia ongelmia: Kustannusten ylittyminen. Asiakastyytymättömyys (liittyy laatuun). Ei vastaa tavoitteita. Liiketaloudelliset menetykset. Takuutyön määrä (liittyy laatuun). 4
Tavallisimpia syitä ongelmille Työmääräarvio virheellinen. Vaatimusmäärittelyt puutteellisia. Muutosvastarinta. Liian suuri projekti. Asiakkaan/toimittajan kokemattomuus. Suunnittelematon käyttöönotto. Henkilöstövaihtuvuus. Huono projektipäällikkö. Ongelmat työvälineissä tai -laitteissa. 5
Riskikategoriat Projektiriskit vaikuttavat aikatauluun ja voimavaroihin Tuoteriskit vaikuttavat tuotteen laatuun tai tehokkuuteen Liiketoimintariskit vaikuttavat tuotekehitysorganisaatioon On muitakin tapoja muodostaa riskikategorioita. Edellisen sivun kalvolta löytyy lähinnä kahta ensimmäistä tyyppiä. Kolmatta tyyppiä voisivat edustaa teknologiseen muutokseen liittyvät riskit ja tuotekilpailuun liittyvät riskit. 6
Riskienhallintaprosessi Riskien tunnistaminen. Projekti-, tuote- ja liiketoimintariskit tunnistetaan. Riskien analysointi. Arvioidaan riskien todennäköisyydet ja vaikutukset. Riskeihin varautuminen (riskien hallinta). Välttämisen tai vaikutuksen minimoinnin suunnittelua. Riskien seuranta. Riskien jatkuvaa arviointia ja lieventämissuunnitelmia (sitä mukaa, kun tietoa riskeistä tulee esille). 7
Riskienhallintaprosessi Iteratiivinen prosessi, joka jatkuu läpi projektin. Riskien tunnistaminen Riskien analysointi Riskien hallinta Riskien seuranta Riski lista Priorisoitu riskilista Riskien välttämisen ja vaikutusten mini mointisuunnitelmat Riskien arviointi 8
Riskien tunnistaminen Aivoriihi. Tekijöiden tai projektipäällikön kokemukset. Listoja apuna. Riskityyppejä. Riskejä suoraan. 9
Riskityyppejä Teknologiariskit. Ihmisiin liittyvät riskit. Organisatoriset riskit. Asiakkaaseen liittyvät riskit. Työkaluihin liittyvät riskit. Vaatimuksiin liittyvät riskit. Arviointiriskit (estimointi-). Riippuen tarkkuustasosta, listaa voi supistaa tai laajentaa. Kunkin kohdalla: mitä yksittäisiä riskejä löytyy omasta projektista. 10
Riskien analysointi Kunkin löydetyn riskin kohdalla arvioidaan riskin todennäköisyys hyvin alhainen, alhainen, kohtuullinen, korkea, hyvin korkea. vakavuus katastrofi, vakava, siedettävä tai merkityksetön. havaittavuus (millä varmuudella riskin voi havaita) hyvin epävarma, alhainen, kohtuullinen, korkea, lähes varma Tulokset kootaan riskitaulukkoon. Taulukko järjestetään riskin vakavuuden mukaan. Lopuksi päätetään, mitkä ovat projektin kannalta tärkeimmät seurattavat riskit (esimerkiksi 10 20 kpl). 11
Riskeihin varautuminen; riskien hallintakeinot Tärkeimpien riskien kannalta. Perustuu paljolti projektipäällikön kokemukselle. Välttämisstrategiat riskin ilmaantumisen todennäköisyyden pienentäminen. Minimointistrategiat riskin vaikutuksen pienentäminen. Varasuunnitelmat riskiin ollaan varauduttu jotenkin. 12
Riskien seuranta Säännöllistä arviointia: Onko riskien todennäköisyydet tai vaikuttavuudet muuttuneet? Kussakin etenemisen tarkastuspisteessa (esim. katselmoinnit) voidaan tärkeimmät riskit käydä erikseen lävitse. Jotain edellisiin liittyviä riskitekijöitä, joita voi yrittää seurata: Ihmiset Työkalut Vaatimukset Huono työmoraali, työntekijöiden huonot välit. Haluttomuutta käyttää tiettyjä työkaluja, valituksia CASE-työkaluista, tehokkaampien koneiden vaatimukset. Runsaasti muutospyyntöjä, asiakas valittaa. 13
Riskien hallinnan onnistumisen arviointia Missä onnistuttiin hyvin? Mitkä riskit pystyttiin välttämään (jotka ehkä muutoin olisivat realisoituneet)? Kuinka realisoituneet riskit hoideltiin? Havaittiinko riittävän ajoissa? Olivatko toimenpiteet tehokkaita ja riittäviä? Minkä riskien suhteen toimet epäonnistuivat? Olisiko toisin toimien voitu riskit välttää tai ainakin vaikutuksia pienentää? Toteutuiko joitakin sellaisia riskejä, jotka selkeästi vaikuttivat ja joita ei oltu havaittu/pohdittu lainkaan etukäteen? 14
Lopuksi erilaisia (mahdollisia) toimintatapoja lyhyesti. Näillä voi vähentää joitain riskejä. (Ks. lisää Moynihanin kirjasta.) 1. Vastapuolelta ei löydy projektin omistajaa tai vastuuhenkilöä. Sellainen tulisi kuitenkin löytyä ja ohje kuuluu, että tällöin voi yrittää kysellä asiakkaan organisaatiosta ylemmiltä tasoilta, kunnes löytyy. Jos ei kuitenkaan löydy, niin asia on selkeästi otettava esille. Usein suositellaan, että projekti kannattaa omalta osalta kuopata, jos asiaa ei saa sovittua. 2. Asiakkaan projektipäälliköllä ei ole toimivaltuuksia. Pitäisi pyytää sellainen tilalle, jolla on. Jos ei löydy, niin taas voi kysellä ylemmiltä tasoilta ja viime kädessä olla valmis lopettamaan projekti omalta osaltaan. 15
3. Asiakkaan projektipäälliköllä ei ole taitoa tai aikaa (mutta toimivaltuuksia kyllä). Hänelle voi yrittää löytää tukea tai opetusta. Jos ei toimi, niin tulisi pyytää toista henkilöä, tai voi yrittää työskennellä jotenkin hänen ohitseen (esim. lisäämällä kontakteja asiakkaan muuhun henkilöstöön). 4. Kannattaa turvautua enemmän pääkäyttäjiin ja -esimiehiin ja vähemmän viralliseen projektipäällikköön tai projektin omistajaan. 5. Epärealistiset odotukset hinnasta, aikataulusta ja toteutettavissa olevasta tulee selvittää. Esim. kertomalla vastaavia esimerkkejä aiemmista projekteista, pitämällä palavereita, mikä on viimeisintä tietoa asiasta ( state of the art ) jne. Voi antaa esimerkkejä, mitä on mahdollista saavuttaa. Voi ehdottaa ulkopuolista konsulttia antamaan objektiivisen näkökulman. Jos ei saa muutoksia aikaan, projekti kiinni. 16
6. Ratkaisuehdotukselle tulee saada aikaisin palautetta. Ratkaisuideoista kannattaa tehdä mahdollisimman konkreettisia asiakkaalle ja käyttäjille. Ihmisiä tulee auttaa näkemään, miten ratkaisu vaikuttaa heidän työhönsä. Ihannetilanteessa prototyyppi, mutta myös paperinäytöillä simulointi auttaa. (Kaikki käyttäjät eivät ehkä halua uutta systeemiä.) 7. Organisaation muuttumiseen ja ihmisläheiset asiat (erimielisyydet, muutosvastarinta jne) tulisi selvittää aikaisessa vaiheessa. Niitä ihmisiä voi valmistaa muutokseen, joihin muutokset eniten vaikuttavat. 8. Toteutussuunnitelman tulisi olla myös aikaisessa vaiheessa huolellisesti tehty ja riittävän yksityiskohtainen. Toteutustehtävien ja -vastuiden tulisi olla hyvin selkeitä. Käyttäjien valmisteluun ja opettamiseen kannattaa laittaa riittävästi panoksia. Järjestelmän käyttöönotto kannattaa suunnitella hyvin. Täsmällisestä järjestelmän luovutushetkestä sovittava. 17
9. Jos asiakkaan puolella on erimielisyyksiä, haluttomia käyttäjiä tai epämieluisaa politiikkaa (esim. piilotavoitteellisia projekteja ), niitä voi yrittää ratkaista esim. opettamalla. Ongelma kannattaa antaa asiakkaalle (taholle, jolla on kykyä tai mahdollisuus ratkaista tuo ongelma). Ongelmaan sekaantumista kannattaa yrittää välttää. Voi neuvoa ottamaan konsultaatiota ongelmiensa ratkaisemiseen. 10. Tulisi varmistaa, että asiakas hyväksyy kokonaisvastuun organisaatiomuutoksien hallinnoinnista, ja että asiakas valmistaa organisaatiota uuden systeemin käyttöönottoon. Kannattaa hyvin tarkasti kertoa kaikista muutoksista, mitä uusi systeemi aiheuttaa sisäisiin prosesseihin. 11. Projektin laajuutta kannattaa rajata vastaamaan asiakkaan kapasiteettia muutosten omaksumiseen. 18
12. Projektin laajuutta ja sisältöä tulee rajata sen mukaan, mikä omin voimin on luotettavasti mahdollista toteuttaa ajan, kustannusten ja teknisten asioiden suhteen. 13. Käytä inkrementaalista- tai evolutionaarista elinkaarimallia. Projekti kannattaa osittaa useisiin vaiheisiin, jokaisella oma minitoteutuksensa. Pienimmän riskin tai kiireellisimmät toteutetaan ensin. Sen jälkeen voi tarkistaa edistymisen ja päättää, mitä tehdään seuraavaksi. 14. Neuvottele joustavuutta aikarajoihin. 15. Jos asiakaspäässä tapahtunee paljon muutoksia, tai jos on paljon ihmisiin liittyviä asioita käsiteltävänä, kannattaa ryhmään ottaa mukaan erilaisien ihmisten kanssa pärjääviä (hyviä kuuntelijoita, keskustelijoita). 19
16. Jos projektiin liittyy paljon oppimista (omalta osalta), kannattaa miettiä, josko kyseessä on itselle strateginen päätös. Esimerkiksi voi opettelemisen takia tehdä tappiolla ensimmäisiä kertoja, jotta tulevaisuudessa hallitsee jonkin tekniikan. 17. Jos kehittäjille vastaavasta tulee paljon oppimista, kannattaa yrittää erottaa esim. jokin pienempi osaprojekti, jonka avulla opittavan asian pystyy oppimaan alkuvaiheessa ennen kuin siirrytään pääprojektiin. Lennossa oppiminen on riskaabelia. 18. Jos johonkin asiaan liittyy paljon teknisiä riskejä, kannattaa niiden selvittämiseen varata erillinen selvitysjakso omalla budjetillaan. Tällaiseen asiaan ei kannata tehdä mitään sitoumuksia, ennen kuin riski on määritelty tarkemmin tai ratkaistu. 20
19. Jos omasta ryhmästä puuttuu osaamista, voi ostaa koulutusta, konsultaatiota, sopimuskehittäjiä (contract staff) jne. Jos ryhmään tuo mukaan liian monta ulkopuolista, voi ryhmän toiminta häiriintyä. Jos tämä on riski, voi osia antaa alihankinnan ratkaistavaksi. Tai voi yrittää edetä yhteisprojektina jonkin muun porukan kanssa. 20. Asiakkaan toimialan opiskelua viettämällä aikaa asiakkaan luona, esimerkiksi seuraamalla pääkäyttäjien toimintaa. Lisäksi voi selvittää, minkälaisia ratkaisuja muut ovat tehneet asiakkaan kilpailijoille. 21
21. Sovi ajankäyttö- ja materiaaliasioista sellaisiin asioihin liittyen, joihin liittyy paljon opiskelua tai muita asioita, joihin ei ole itsellä täyttä kontrollia, tai joihin liittyy erimielisyyksiä, epäsuotuisaa politiikkaa tai muita isoja ihmis- tai teknologiaepävarmuuksia. Tällaiset asiat voi käsitellä sopimuksissa erikseen. Kiinteä hinta kannattaa hyväksyä vain sellaisissa tapauksissa, joissa voi laittaa mukaan ison varmuusrahan tai jos projekti on erityisen tärkeä itselle (strategisesti esimerkiksi). 22. Käyttäydy byrokraattisesti, kirjaa kaikki asiat, sovi kaikesta täsmällisesti ja yksityiskohtaisella tasolla. 23. Dokumentoi ja sovi projektin laajuudesta ja rajoista: mitä sisältää ja mitä ei, mistä alkaa ja mihin loppuu. Kaikki ylimääräiset pyynnöt käsitellään muutospyyntöinä omilla budjeteillaan. 22
24. Neuvottele erillinen sopimus ensimmäiselle vaiheelle, jossa sovitaan laajuudesta, vaatimuksista ja toiminnallisesta määrittelystä. 25. Vaatimusmäärittelyn, toiminnallisen määrittelyn ja systeemimäärittelyn tulisi olla erityisen täsmällisiä ja yksityiskohtaisia. 26. Selvitä sekä suunnittelijan ja asiakkaan vastuut ja sitoumukset täsmällisesti ja selvästi. Etsi yhteisymmärrys ja selvyys, kuka tekee mitäkin ja milloin, ja resursseista, joita asiakas toimittaa, ja milloin. 27. Pidä kirjaa asiakkaan tekemistä virheistä/epäonnistumisista niiden asioiden suhteen, joista on sovittu. Liittyy vastuisiin, sitoumuksiin, aikatauluihin jne. Lisäksi voi kirjata myös ongelmia, jotka ovat lähtöisin asiakkaan toiminnasta. 23
28. Sovi etukäteen projektin onnistumiskriteereistä ja onnistumismittareista. Tämä sisältää mm. hyväksymistestit. 29. Pyydä asiakkaalta allekirjoitukset jokaiseen tuotokseen projektin eri vaiheissa. Ilman allekirjoituksia ei kannata jatkaa. 30. Hallinnoi alihankkijoitasi vähintään yhtä tiukasti kuin oma asiakkaasi hallinnoi sinua. Sopimuksiin tulisi lisätä sakkopykäliä tehottomuudesta (esim. myöhästymisistä). Vaadi allekirjoitukset kaikista tuotoksista. Varmista kommunikointiyhteyksien toiminta. Selvitä roolijaot ja vastuut. Tutki alihankkijoiden taustaa, kokemusta ja sopivuutta omien toimintatapojen kannalta. 31. Jos projektiin osallistuu kolmansia osapuolia, esimerkiksi muita konsultteja, varmista että roolijako, vastuut ja heidän suhde projektissa sinuun on selvästi määritelty. Tutki kolmannen osapuolen taustaa, kokemusta ja sopivuutta omien toimintatapojen kannalta. 24
32. Älä koske toisten toimittajien tai suunnittelijoiden tuotteisiin (koodiin, liittymiin jne.), jos sen voi välttää. Käsittele niitä mahdollisina matopurkkeina. Jos mahdollista, yritä saada alkuperäinen kehittäjä vastaamaan muutoksista, tai hyväksymään muutokset allekirjoituksella. Jos ei mahdollista, uudelleen kirjoita tai kehitä alusta, testaa runsaasti. Sovi selvästi, kuka ylläpitää sitä sen jälkeen, kun olet tehnyt muutokset. 33. Vahvista laadun varmistusta ja lisää kehitysprosessin muodollisuuden tasoa. 34. Paranna käyttäjien kuvausten tasoa liiketoimintojen testitapausten muodostamisessa ja testauksessa. 35. Jos sovellus on hyvin kriittinen asiakkaalle, varmista että ryhmästä löytyy teknistä- ja sovellusosaamista. 25
36. Lisää projektin hallinnan muodollisuutta ja täsmällisyyttä. Hallinnoi projektia muodollisemmin ja tiukemmin. Kontrolloi aikatauluin ja tuotoksin. Paljon valvontaa ja kontrollia. 37. Jos projekti ei ole strategisesti itselle tärkeä, kävele pois... (riippuu tilanteesta ja tähän ei ole helppo löytää yksinkertaisia tilanteita, milloin näin pitää reagoida). 26