Motivointia avoitteista uentojen jälkeen opiskelijan tulisi osata: Tunnistaa eri riskikategorioita. Tietää riskienhallintaprosessin perusteet. Tunnistaa tärkeimpiä riskejä ja riskityyppejä. Arvioida riskienhallintaprosessin onnistumista. 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). 2 4 iskeistä Luennon tavoitteista Luennon sisällöstä Motivointia Riskilistoja, tapoja käsitellä riskejä ähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Tony Moynihan, Coping with IS/IT risk management Somerville, Software Engineering Sisällöstä Tavoitekalvon asioita. hallintaprosessissa: havaitseminen. analysointi. Riskeihin varautuminen (riskien hallinta). seuranta (monitorointi). Lisäksi esitetään tavallisimpia projektiongelmia ja niiden syitä. 1 3
iskikategoriat Projektiriskit vaikuttavat aikatauluun ja voimavaroihin Tuoteriskit vaikuttavat tuotteen laatuun tai tehokkuuteen hallintaprosessi Iteratiivinen prosessi, joka jatkuu läpi projektin. Liiketoimintariskit vaikuttavat tuotekehitysorganisaatioon tunnistaminen analysointi hallinta seuranta n muitakin tapoja muodostaa riskikategorioita. dellisen sivun kalvolta löytyy lähinnä kahta ensimmäistä tyyppiä. olmatta tyyppiä voisivat edustaa teknologiseen muutokseen ittyvät riskit ja tuotekilpailuun liittyvät riskit. Riski lista Priorisoitu riskilista välttämisen ja vaikutusten mini mointisuunnitelmat arviointi 6 8 avallisimpia 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. hallintaprosessi tunnistaminen. Projekti-, tuote- ja liiketoimintariskit tunnistetaan. analysointi. Arvioidaan riskien todennäköisyydet ja vaikutukset. Riskeihin varautuminen (riskien hallinta). Välttämisen tai vaikutuksen minimoinnin suunnittelua. seuranta. jatkuvaa arviointia ja lieventämissuunnitelmia (sitä mukaa, kun tietoa riskeistä tulee esille). 5 7
iskityyppejä Teknologiariskit. Ihmisiin liittyvät riskit. Organisatoriset riskit. Asiakkaaseen liittyvät riskit. Työkaluihin liittyvät riskit. Vaatimuksiin liittyvät riskit. Arviointiriskit (estimointi-). iippuen tarkkuustasosta, listaa voi supistaa tai laajentaa. unkin kohdalla: mitä yksittäisiä riskejä löytyy omasta projektista. rojektisuunnitelman mallista löytyy listoja erilaisia vastinpareja sioita), joihin voi liittyä riskejä. 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. 10 12 analysointi Kunkin löydetyn riskin kohdalla arvioidaan riskin iskien tunnistaminen Aivoriihi. Tekijöiden tai projektipäällikön kokemukset. Listoja apuna. Riskityyppejä. Riskejä suoraan. 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). 9 11
iskien hallinnan onnistumisen arviointia issä onnistuttiin hyvin? Mitkä riskit pystyttiin välttämään (jotka kä muutoin olisivat realisoituneet)? uinka realisoituneet riskit hoideltiin? Havaittiinko riittävän joissa? Olivatko toimenpiteet tehokkaita ja riittäviä? inkä riskien suhteen toimet epäonnistuivat? Olisiko toisin toimien oitu riskit välttää tai ainakin vaikutuksia pienentää? oteutuiko joitakin sellaisia riskejä, jotka selkeästi vaikuttivat ja ita ei oltu havaittu/pohdittu lainkaan etukäteen? 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. 14 16 iskien seuranta ää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. otain 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. 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. Usea suosittaa, 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. 13 15
. Jos asiakkaan puolella on erimielisyyksiä, haluttomia käyttäjiä i epämieluisaa politiikkaa (esim. piilotavoitteellisia projekteja ), iitä voi yrittää ratkaista esim. opettamalla. Ongelma kannattaa ntaa asiakkaalle (taholle, jolla on kykyä tai mahdollisuus ratkaista o ongelma). Ongelmaan sekaantumista kannattaa yrittää välttää. oi neuvoa ottamaan konsultaatiota ongelmiensa ratkaisemiseen. 0. Tulisi varmistaa, että asiakas hyväksyy kokonaisvastuun rganisaatiomuutoksien hallinnoinnista, ja että asiakas valmistaa rganisaatiota uuden systeemin käyttöönottoon. Kannattaa hyvin rkasta kertoa kaikista muutoksista, mitä uusi systeemi aiheuttaa säisiin prosesseihin. 1. Projektin laajuutta kannattaa rajata vastaamaan asiakkaan pasiteettia muutosten omaksumiseen. 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 riksi on määritelty tarkemmin tai ratkaistu. 18 20. Ratkaisuehdotukselle tulee saada aikaisin palautetta. atkaisuideoista kannattaa tehdä mahdollisimman konkreettisia siakkaalle ja käyttäjille. Ihmisiä tulee auttaa näkemään, miten tkaisu vaikuttaa heidän työhönsä. Ihannetilanteessa prototyyppi, utta myös paperinäytöillä simulointi auttaa. (Kaikki käyttäjät vät ehkä halua uutta systeemiä.). Organisaation muuttumiseen ja ihmisläheiset asiat rimielisyydet, muutosvastarinta jne) tulisi selvittää aikaisessa iheessa. Niitä ihmisiä voi valmistaa muutokseen, joihin uutokset eniten vaikuttavat.. Toteutussuunnitelman tulisi olla myös aikaisessa vaiheessa uolellisesti tehty ja riittävän yksityiskohtainen. Toteutustehtävien -vastuiden tulisi olla hyvin selkeitä. Käyttäjien valmisteluun ja pettamiseen kannattaa laittaa riittävästi panoksia. Järjestelmän äyttöönotto kannattaa suunnitella hyvin. Täsmällisestä rjestelmän luovutushetkestä sovittava. 12. Projektin laajuutta ja sisältöä tulee rajata sen mukaan, mikä omin voimin on luetettavasti 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). 17 19
1. Sovi ajankäyttö- ja materiaaliasioista sellaisiin asioihin liittyen, ihin liittyy paljon opiskelua tai muita asioita, joihin ei ole itsellä yttä kontrollia, tai joihin liittyy erimielisyyksiä, epäsuotuisaa olitiikkaa tai muita isoja ihmis- tai teknologiaepävarmuuksia. ällaiset asiat voi käsitellä sopimuksissa erikseen. Kiinteä hinta nnattaa hyväksyä vain sellaisissa tapauksissa, joissa voi laittaa ukaan ison varmuusrahan tai jos projekti on erityisen tärkeä selle (strategisesti esimerkiksi). 2. Käyttäydy byrokraattisesti, kirjaa kaikki asiat, sovi kaikesta smällisesti ja yksityiskohtaisella tasolla. 3. Dokumentoi ja sovi projektin laajuudesta ja rajoista: mitä sältää ja mitä ei, mistä alkaa ja mihin loppuu. Kaikki ylimääräiset yynnöt käsitellään muutospyyntöinä omilla budjeteillaan. 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. 22 24 9. Jos omasta ryhmästä puuttuu osaamista, voi ostaa koulutusta, onsultaatiota, sopimuskehittäjiä (contract staff) jne. Jos ryhmään o mukaan liian monta ulkopuolista, voi ryhmän toiminta äiriintyä. Jos tämä on riski, voi osia antaa alihankinnan tkaistavaksi. Tai voi yrittää edetä yhteisprojektina jonkin muun orukan kanssa. 0. Asiakkaan toimialan opiskelua viettämällä aikaa asiakkaan ona, esimerkiksi seuraamalla pääkäyttäjien toimintaa. Lisäksi voi lvittää, minkälaisia ratkaisuja muut ovat tehneet asiakkaan ilpailijoille. 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. 21 23
6. Lisää projektin hallinnan muodollisuutta ja täsmällisyyttä. allinnoi projektia muodollisemmin ja tiukemmin. Kontrolloi ikatauluin ja tuotoksin. Paljon valvontaa ja kontrollia. 7. Jos projekti ei ole strategisesti itselle tärkeä, kävele pois... iippuu tilanteesta ja tähän ei ole helppo löytää yksinkertaisia lanteita, milloin näin pitää reagoida) 26 2. Älä koske toisten toimittajien tai suunnittelijoiden tuotteisiin oodiin, liittymiin jne.), jos sen voi välttää. Käsittele niitä ahdollisina matopurkkeina. Jos mahdollista, yritä saada lkuperäinen kehittäjä vastaamaan muutoksista, tai hyväksymään uutokset allekirjoituksella. Jos ei mahdollista, uudelleen kirjoita i kehitä alusta, testaa runsaasti. Sovi selvästi, kuka ylläpitää sitä n jälkeen, kun olet tehnyt muutokset. 3. Vahvista laadun varmistusta ja lisää kehitysprosessin uodollisuuden tasoa. 4. Paranna käyttäjien kuvausten tasoa liiketoimintojen stitapausten muodostamisssa ja testauksessa. 5. Jos sovellus on hyvin kriittinen asiakkaalle, varmista että hmästä löytyy teknistä- ja sovellusosaamista. 25