PIKAOPAS Liiketoimintaan integroidumpi ja dynaamisempi projektien hallinta, osa I Tämä pikaopas sisältää virikkeitä miettiä projektien ja liiketoiminnan (toiminnan) suhdetta syvällisemmin. Samoin se antaa eväitä kehittää toimivampaa projektiriskien hallintaa. Tämä pikaopas painottuu yksittäisen projektin hallintaan. Toisessa osassa on tarkoitus pureutua enemmän moniprojektien ja projektiportfolioiden maailmaan. Free copy, but not copy free! Pvm: 21. toukokuuta 2010
SIVU 2 Miksi? Projektien hallintaa tapahtuu hyvin erilaisissa ympäristöissä. 1) Yritys, joka myy tekemiään ohjelmistoja, elää joka päivä projekteissa ja projekteilla, samoin useat rakennusliikkeet. 2) Organisaation ja toimittajan välinen yhteisprojekti esimerkiksi kiinteistön kunnostamiseksi tai ohjelmiston käyttöönotoksi on kertakäyttöinen, investointiluontoinen hanke muutaman vuoden välein. 3) Sitten on organisaatioita, joissa tapahtuu koko ajan hyvin monenlaisia, eritasoisia, eri motiiveihin perustuvia projekteja. Tämä opas käsittelee näkökulmia, jotka liittyvät pääasiassa tähän viimeiseen toimintaympäristöön. Kirjava projektien joukko on toteuttamassa organisaation muutosta eli strategiaa. Vaikka kirjoitan usein liiketoiminnasta, pätee havainnot kyllä julkisiinkin organisaatioihin. Lähtökohtanani on havainto, että useimmat projektit saavat johdon taholta liian vähän huomiota. Johto suhtautuu projektiin kuin laivan liikkeellelaskuun. Juhlan kunniaksi pidetään puheita ja kilistetään laseja. Juhlan jälkeen laiva lähtee avomerelle ja johto kääntää sille selkänsä ja kävelee muihin kiireisiin, korkeintaan lukee välillä kapteenin lähettämiä raportteja. Menettelylle on syynsä. Ensinnäkin perinteiset projektien hallinnan menettelyt ja työkalut eivät ole viritetty liikkeenjohdon näkökulmaan. Toisaalta strategisten muutosten hallinta oli toteutusorganisaatio sitten linja tai projekti on muuttunut yhä vaikeammaksi ja toiminnan kannalta kriittisemmäksi. Projektien huono hallinta on yksi merkittävä syy strategisten muutosten epäonnistumiseen. Tämä opas on suunnattu lähinnä liiketoiminnasta vastaaville henkilöille: heillä on vastuu integroida projektit paremmin toimintaan. Tässä oppaassa on paljon ajatusmalleja. Vaikka ne voivat tuntua teoreettisilta, silti jokaisen niiden takana on käytännön kokemus ja pitkä työstäminen. Näkemykseni integroidummasta projektien hallinnasta on kertynyt monessa roolissa ja se on yhdistelmä strategioiden, investointien, riskien, muutoksien ja projektien hallintaa. En ole vastaavaa nähnyt kirjallisuudessa enkä muuallakaan. Itse olen kouluttanut tätä oppia kehittyneille projektipäälliköille useamman vuoden ajan. Oppaan näkemykset ovat linjassa kirjamme kanssa: Dynaaminen johtaminen, (Jalava & Matilainen), Tammi PRO, 2010.
SIVU 3 Sisällysluettelo A. Projektien hallinnan ruumiinavaus 1. Liiketoiminnan puutteellisen integraation oireita 2. Vajaatehoisen riskienhallinnan oireita B. Omaksu uusi ajattelutapa 3. Tarkempia käsitteitä 3.1. Projekti 3.2. Ohjelma 3.3. Projektiportfolio 3.4. Projektiriski 4. Projektin vastuut 4.1. Projekti ja ohjelmapäällikön vastuu 4.2. Projektin asettajan (omistajan) vastuu 4.3. Linjaorganisaation (ohjausryhmän) vastuu 4.4. Projektisponsorin vastuu 5. Parempi projektisuunnitelma 5.1. Projektin merkitys, kriittisyys 5.2. Projektin tavoitteet ja projektiriskit 5.3. Projektin monimutkaisuus ja epävarmuuden aste 6. Projektin vaiheistus 6.1. Projektin vastuut vaiheittain 6.2. Projektin vaiheittainen riskienhallinta C. Jos haluat muutosta
SIVU 4 A. Projektien hallinnan ruumiinavaus Jos et organisaatiossasi törmää näihin oireisiin, sinun ei luultavasti kannata lukea tätä opastakaan. Joko organisaatiossasi asiat ovat hyvässä kunnossa tai sitten et oikein oivalla, mistä tässä on kyse. 1. Liiketoiminnan puutteellisen integraation oireita Projekti ei kytkeydy organisaation strategiaan, koska: Strategiat ovat niin abstrakteja, Projekti on niin pieni ja strategia niin laaja, Projekteista ei muodostu merkittäviä kokonaisuuksia, koska niiden vastuu on hajautettu eri puolille organisaatiota ja koska suurin osa projekteista syntyy alhaalta ylös operatiivisista tarpeista ja strategiat vyörytetään ylhäältä alas, Projektit jätetään palkitsemisessa tuloksien ulkopuolelle. Projekti ei kytkeydy organisaation pitkäjänteisempiin perusrakenteisiin, kuten esimerkiksi IT-arkkitehtuuriin ja prosessikarttaan, koska johto ei niitä ymmärrä eikä vaadi linkitystä. Monimutkaisuutta ei ole, kun siltä sulkee silmät. Projekti ei kytkeydy organisaatioyksikön tavoitteisiin, koska: Projektin merkitystä (kriittisyyttä) yksikön tavoitteille ei ole kuvattu, Projekteja tarkastellaan yksilöinä, ei merkityksellisempinä ryhminä (ohjelmina tai portfolioina), Projektisuunnitelmassa kuvattu liiketoiminnan hyöty on sumea. Projektin liiketoimintasuunnitelma on abstrakti ja teoreettinen eikä sitä päivitetä projektin toteutuksen aikana, Projektin kannattavuuslaskelma on taas rajattu tarkoitushakuisesti niin, että haluttu hyötytaso on kyetty esittämään. Joskus rationaalinen hyötytarkastelu on korvattu strategisen projektin leimalla, Projektin liiketoimintasuunnitelmia eikä niiden saavutuksia revisioida objektiivisesti. Projektin liiketoimintavastuu on epäselvä, koska: Liiketoiminta haluaa delegoida vastuun projektipäällikölle ja Ohjausryhmässä taas kukin vahtii vain omia etujaan.
SIVU 5 Projekteista ei synny liiketoimintaa hyödyttävää oppimista, koska: Projektin tuloksia (saavutuksia ja epäonnistumisia) ei analysoida kunnolla. Organisaation takapihalle kerääntyy huonosti menneiden projektien hautausmaa. Ei lupa kaivella! Projektit ovat ylimiehitetty konsulteilla ja tuottajien edustajilla, jotka vievät oppimisen hedelmät omaan organisaatioonsa. 2. Vajaatehoisen riskienhallinnan oireita Projektin riskienhallinta koetaan puhtaaksi muodollisuudeksi. Projektiriskit esitellään ohjausryhmän kokouksen agendalla viimeisenä. Yleensä kokouksen aika loppuu kesken ja riskejä ei ehditä käsitellä. Projektien riskienhallinta on kuin finni takapuolessa. Siitä ei ole merkittävää haittaa, mutta kukaan ei oikein näy sen hyötyjäkään. Riskiraporteissakin on pelkkiä itsestäänselvyyksiä. Riskinäkemys (yleensä mekaaninen riskiluettelo) naulataan projektin esisuunnitteluvaiheessa eikä sitä sen koommin kunnolla päivitetä. Projekti irrotetaan kokonaisuudesta vaikka yleensä projektilla on riippuvuuksia muista projekteista tai linjaorganisaation tekemisistä. Käsitteistö on hämärää: mikä on projekti ja mikä on projektiriski? Jokaisella vapaalla miehellä pitää olla oikeus määritellä ne omalla tavallaan? Tästä seuraa, että projektin riskiksi kelpaa melkein mikä tahansa rotusorrosta nälänhätään. Projektin toteutusriskit valtaavat koko huomion. Projektin asettajan liiketoimintariskit jäävät yleensä huomiotta. Projektin ohjausryhmän ohjaus irtautuu liiketoiminnan tavoitteista. Liiketoimintayksikön johtoryhmässä projekteja ei taas kunnolla käsitellä, koska ne ovat niin pieniä ja merkityksettömiä. Projektiriskien hallinnan menettelyjen pitäisi olla yliyksinkertaisia. Niin helppoja ja yksinkertaisia, että niiden tuottama sisältö on epämääräistä ja joskus käyttökelvotonta. Vaikka projekteja on hyvin erilaisia, metodien ja temppulevyjen pitäisi olla samat ja yksinkertaiset. Toisaalta, ollaan halukkaita kopioimaan kehittyneitä metodeja viehättävistä firmoista ilman omaa ymmärrystä niiden todellisesta tarpeesta ja käyttökelpoisuudesta. Asenteellisesti luotetaan sokeasti siihen, että jos menettely on yleinen, sen on pakko olla hyvä meillekin.
SIVU 6 B. Omaksu uusi ajattelutapa Täsmällisemmät käsitteet, toimivampi vastuujako, parempi projektisuunnitelma, projektin vaiheistuksen huomioon ottaminen... 3. Tarkempia käsitteitä 3.1. Projekti Projekti on tiettyä uniikkia tehtävää varten perustettu kertakäyttöorganisaatio. Aidolla projektilla ei ole historiaa. Projekti liittyy aina johonkin prosessiin ainakin yhteen. Projektille on myös tyypillistä, että se muuttaa prosessia tai prosesseja joko tilapäisesti tai pysyvästi. 3.2. Ohjelma Ohjelma on joukko toisistaan riippuvaisia projekteja, jotka tähtäävät saman päämäärän tai strategian toteuttamiseen. 3.3. Projektiportfolio Projektiportfolio on organisaation ohjelmien kokonaisuus, joukko, jota voi tarkastella, analysoida ja arvottaa eri näkökulmista. 3.4. Projektiriski Projektiriski on mikä tahansa epävarmuus (positiivinen tai negatiivinen), joka voi vaikuttaa merkittävästi projektin tavoitteisiin tai optimaaliseen tulokseen. 4. Projektin vastuut Huom! Jos projektin tavoitteet ovat epätarkat, abstraktit, epämääräiset, silloin vastaavat riskitkin ovat epätarkkoja, abstrakteja ja epämääräisiä. Näin ymmärrettynä projektien riskienhallinnan yksi tärkeä merkitys on testata projektille asetettujen tavoitteiden laatua. Kokemuksieni mukaan projektiin liittyvät vastuut välillä hämärtyvät pahasti tai sitten ehkä se yleisempi variaatio projektipäällikölle delegoidaan kaikki vastuu ilman riittäviä valtuuksia yms. eväitä. Vastuun tulisi olla hyvin konkreettinen: jos riski realisoituu, minä kärsin työssäni sen seurauksista. 4.1. Projekti ja ohjelmapäällikön vastuu Projektipäällikkö vastaa projektin toteutuksesta, tavoitteiden saavuttamisesta annettujen aikataulun ja budjetin rajoissa. Hänen vastuunsa alkaa silloin, kun projektilla on hyväksytty suunnitelma, sillä on projektiorganisaatio ja projektin asettaja tekee aloittamispäätöksen (GO decision). Projektipäällikkö voi olla mukana projektin esisuunnitteluvaiheessa, mutta hänellä ei ole päällikkövastuuta ennen kuin hänellä on organisaatio ja projekti käynnistetään.
SIVU 7 Projektin riskienhallinnasta projektipäällikön vastuulla on päivittäinen ongelmien ratkaiseminen (issue management) sekä projektiryhmän sisäinen muutoksenhallinta. Jos päivittäisistä ongelmista joku osoittautuu liian suureksi hänen hoitaa omilla valtuuksillaan, silloin hän raportoi riskistä projektin asettajalle. Pääsääntö on, että projektipäällikkö vastaa projektin sisäisestä maailmasta ja projektin asettaja sen ympäristöstä. 4.2. Projektin asettajan (omistajan) vastuu Projektin asettaja edustaa linjaorganisaatiota. Hän vastaa kaikesta projektiin liittyvästä ennen GO-päätöstä. Lisäksi hän vastaa projektin toteutuksen aikanakin projektin toiminnallisista tuloksista. Projektin omistaja tarkkailee toimintaympäristöä ja hänen vastuullaan on tarvittaessa päivityttää projektin toimintasuunnitelma ja tavoitteet. Hyvin yleisesti projektipäällikölle sälytetään projektivastuu jo ennen projektin olemassaoloa (esisuunnitteluvaiheessa). Menettely ei ole järkevä. Samoin projektipäällikölle usein vyörytetään vastuu valvoa toimintasuunnitelman päivitystarvetta., mikä on selkeästi asettavan linjaorganisaation vastuulla. Projektin omistaja on projektin ohjausryhmän puheenjohtaja. Johtoryhmän jäsenet antavat ryhmälle asiantuntemuksensa ja näkemyksensä, puheenjohtaja yksin vastaa johtopäätöksistä ja päätöksistä. Tällainen vastuu on ilmeisen poikkeavaa: usein ohjausryhmä muistuttaa breshneviläistä edunvalvontakomiteaa, eikä kukaan jäsenistä kanna projektista vastuuta. 4.3. Linjaorganisaation (sen johtoryhmän) vastuu Johtoryhmä organisoi strategioiden mukaiset ohjelmat sekä valvoo niiden toteutusta. Lisäksi johtoryhmä valvoo ohjelmista muodostuvaa yksikön omaa projektiportfoliota sekä integroi siihen investointihankkeet. 4.4. Projektisponsorin vastuu Projektisponsorin rooli on aikamoinen kummajainen. Sillä viestitään: Joko projektin rationaaliset perustelut (toiminnalliset & taloudelliset) eivät ole riittävät ja pönkäksi tarvitaan joku korkea-arvoinen johtaja tai sitten Se viestii projektien priorisoinnin laiminlyönnistä. Jos priorisointi tapahtuu villin viidakon säännöin, silloin on järkevää vahvistaa omaa taisteluasemaansa sponsorilla. Projektisponsorien käyttö viestii kolmannenkin seikan. Organisaatiokulttuuri on poliittinen. Päätöskriteerit eivät ole läpinäkyviä, vaan on tärkeää tuntea oikeat ihmiset. Voit varmaan helposti kuvitella mihin tällainen kulttuuri johtaa.
SIVU 8 5. Parempi projektisuunnitelma Projektisuunnitelman tulisi antaa realistinen ja vertailukelpoinen kuva projektista. 5.1. Projektin merkitys, kriittisyys Projektisuunnitelma kuvaa projektin merkitystä liiketoiminnalle (toiminnalle) ja esittää projektin toteutuksesta toivottavat hyödyt. Projektisuunnitelman perusteella lukijan pitäisi ymmärtää, kuinka tärkeä projekti on, mikä on sen prioriteetti suhteessa muihin projekteihin. Jos projekteilla ei ole selkeää prioriteettia, seurauksena on taistelu resursseista yms. tehottomuutta. Käytäntö on opettanut, että hyvin helposti kaikkien projektien prioriteetti nousee erittäin tärkeä -luokkaan. Jos kaikki on tärkeää, silloin mikään ei ole erityisen tärkeää. Tätä rankkauksen ongelmaa voi purkaa kysymällä: kenen kannalta projekti (ohjelma) on kriittinen? Onko se kriittinen tietyn asiantuntijan (IT-guru) tai pomon, tietyn prosessin (laskutus), oman yksikön tai sitten koko organisaation kannalta? Valveutunut johto integroi projektit (ohjelmat) strategioihin. Strategiahan on muutos, pyrkimys johonkin. Ne projektit, jotka liittyvät strategian toteutuksen kriittisiin menestystekijöihin, ne ovat kaikkein kriittisimpiä eli niiden prioriteetti on korkein. 5.2. Projektin tavoitteet ja projektiriskit Edellisen kappaleen merkityksestä johdetaan projektille tuotostavoite (deliverables), joka pitää saavuttaa annetulla resurssimäärällä (budjetti) annetussa ajassa (aikataulu). Aikatauluun eikä budjettiin pidä liittyä riskiä, sille ne ovat annettuja. Projektilla on myös muita tavoitteita, jotka on syytä tiedostaa. Projektin tulee olla (ulkoisten) lakien, asetusten, regulaation ja sopimuksien mukainen. Nämä tavoitteet unohtuvat helposti toimittaessa tutussa ympäristössä (kotimaassa). Ne nousevat huomattavaan arvoon toiminnan muuttuessa kansainväliseksi ja monikulttuuriseksi. Vastuumielessä näiden huomioiminen on projektin asettajan (linja-organisaation) vastuulla. Projektin tulee myös olla sopusoinnussa sisäisten normien kuten vision, arvojen, strategioiden, arkkitehtuurien, toimintaohjeiden yms. kanssa. Tämä jälkimmäinen tavoitealue on käytännössä vaikeampi kuin tuo edellinen. Jos projektin asettaja oikeasti kävisi kaikki nuo sisäiset normit lävitse, hänen mahdollisuutensa asettaa projekti olisivat erittäin rajoittuneet. Siksi nuo sisäiset normit niin useasti unohdetaan. Rationaalisempi menettely olisi tuoda julki toiminnan ja normien välisiä ristiriitoja. Paasikiven patsaassa lukee: kaiken oppimisen lähtökohta on tosiasioiden tunnustaminen. Projektin riskit liittyvät noihin kaikkiin tavoitealueisiin 1) projektin asettajan hyötyriski (benefit risks), 2) projektin tuotosriskit (deliverable risks) sekä 3) rajoiteriskit (compliance risks).
SIVU 9 5.3. Projektin monimutkaisuus ja epävarmuuden aste Projektit ovat hyvin erilaisia. Ne voidaan luokitella monimutkaisuuden perusteella esimerkiksi näin: PROJEKTIN MOTIIVI Täydennys tai tukiprojekti (yksinkertainen projekti) Ylläpito tai korjausprojekti TAVOITE Pieni täydennys olevaan hyvin toimivaan kokonaisuuteen Laadun tason säilyttäminen tai palauttaminen Rationalisointiprojekti Laadunparannusprojekti Merkittävä kustannustason alentaminen laatutaso säilyttäen Laadun merkittävä nosto Laajennusprojekti Kapasiteetin lisäys vastaamaan kasvavaa kysyntää Strateginen projekti (monimutkainen projekti) Uuden luominen, uudella tavalla, uudella teknologialla, uudelle kohderyhmälle tms. Täydennys ja tukiprojektit ovat yksinkertaisia ja niiden epävarmuuden aste on alhainen, koska lähes kaikki niissä on tuttua. Vastaavasti strateginen projekti on monimutkainen ja sen riskitaso on korkea, koska projektiin liittyy paljon epävarmoja asioita. Projektit ovat usein monikärkiohjuksia. Niillä on yhtä aikaa monta motiivia. Näissäkin tapauksissa on yleensä helposti osoitettavissa primaaritavoite eli se kaikkein tärkein projektin motiivi. Tällainen projektien luokittelu ei tarvitse olla tieteellisen tarkkaa. Robustimminkin toteutettuna se antaa arvokasta näkemystä. Yksinkertaista ja vähän epävarmaa täydennysprojektia ei kannata ohjata ja valvoa raskaimmilla metodeilla, kun taas strategisen projektin ohjaukseen ja valvontaan pitää ottaa käyttöön kaikki konstit. Käytännössä toimitaan usein päinvastoin. Strategista projektia ohjataan silkkihansikkain ja helpon projektin ohjaukseen ja valvontaan uhrataan suhteettomasti aikaa ja rahaa. Vain koska se on helppo kohde byrokraateille. Toinen merkittävä projektin monimutkaisuutta lisäävä tekijä on riippuvuus muista projekteista. Nämä riippuvuudet on kohtuullisen helppo selvittää ja hallita oman yksikön sisällä. Yksiköiden väliset riippuvuudet ovatkin jo huomattavasti haastavampi juttu. Tulosyksikköorganisaatio pilkkoo sekä vallan että vastuun yksiköiden rajoille. Samantasoisilla tulosyksiköillä voi olla yhteisiä motiiveja kehittää asioita, mutta toimiva yhteistyö edellyttää, että kehityskohteen prioriteetti on molemmille yksiköille sama (aika teoreettinen tapaus). Tulosyksikköorganisaatiossa yhteiset projektit (ohjelmat) tulisi huomioida näkyvästi tuloskorteissa. Tuloskortilla voi motivoida useammat yksikön toimimaan yhteisen tavoitteen hyväksi, vaikka se ei luontaisesti viehättäisikään.
SIVU 10 6. Projektin vaiheistus Useimmissa projektinohjausmalleissa projektia vaiheistetaan päätöksentekopisteillä. Päätöspisteiden määrä vaihtelee, mutta kaikista malleista löytyy seuraavat vaiheet: esisuunnittelu, projektin suunnittelu, toimeenpano, roll-out ja projektin päättäminen. Kullekin vaiheelle esitetään pitkiä tehtävälistoja ja dokumenttien mallipohjia. Ihan sinällään järkevää hommaa. Itse olen jäänyt kaipailemaan parannusta kahteen aiheeseen: vastuisiin vaiheittain sekä projektin riskienhallintaa vaiheittain. 6.1. Projektin vastuut vaiheittain Tämä kohta on pitkälti päällekkäinen varhaisemman luvun kanssa, mutta koska minusta tämä on tärkeää, toistan asiaa vähän eri näkökulmasta. Projektipäällikkö osallistuu usein sekä esisuunnitteluvaiheeseen että projektin suunnitteluun. Motiivina tälle on näkemyksien ja tiedon siirtyminen mahdollisimman saumattomasti projektin käyttöön. Projektipäällikön vastuu alkaa vasta projektin käynnistyksestä, sillä projektia ei ole ennen GO-päätöstä. Projektipäällikön vastuun tulisi myös loppua toteutusvaiheen lopussa. Projektin tuloksia siirto linjaorganisaatioon ei enää pitäisi olla projektipäällikön vastuulla, sillä linjaorganisaatiolla on roll-out:iin parhaat edellytykset. Samoin projektin tuloksien analysointi ja johtopäätöksien teko on linjaorganisaation vastuulla. Linja-organisaatio hyötyy projektista oppimisesta. Toki projektipäällikkökin oppii, mutta se ei ole organisaation kannalta yhtä arvokasta. Projektin esisuunnittelu on elimellinen osa linjaorganisaation normaalia toiminnan suunnittelua., joten sitä ei voi delegoida pois. Linjaorganisaatio myös antaa projektisuunnittelulle sen raamit: tuotostavoitteen, budjetin ja aikataulun. Projektipäällikkö ei voi tuosta vastata. Hän voi luonnostella suunnitteludokumentin, mutta vastuu linjauksista kuuluu linjaorganisaatiolle. Edelleen projektipäällikkö ei voi antaa omalle projektilleen prioriteettia. Moni sotku jäisi pois, jos organisaatiot jakaisivat vastuun esittämälläni tavalla.
SIVU 11 6.2. Projektin vaiheittainen riskienhallinta Projektin riskienhallinta latistuu helposti merkityksettömäksi muodollisuudeksi. Tällainen on huolestuttavaa, sillä projekti (muutos) merkitsee aina perusorganisaatiota korkeampaa riskitasoa. Projektiin pitäisi soveltaa parempia, älykkäämpiä menettelyjä kuin organisaation arkeen. Selityksiä vähämerkitykselliseen projektin riskienhallintaan: 1. Yleisesti projektiin sovelletut metodit antavat liikkeenjohdolle vain vähän heille sopivaa informaatiota. Projektien riskienhallintaa kuvastaa operatiivisen silpputiedon dominanssi. Siitä ei muodostu kokonaisuuksia eikä se kunnolla auta liikkeenjohtoa projektin ohjauksessa. 2. Menettely, jossa esisuunnitteluvaiheessa laaditaan vaikutus-todennäköisyys -matriisi ja jossa matriisia (mukamas) päivitetään koko projektin elinkaaren ajan, osoittaa projektin riskienhallinnan pinnallista ymmärrystä. 3. Riski ymmärretään vain negatiiviseksi asiaksi ja riskit koetetaan eliminoida. Ajatus on absurdi, sillä projekti on tietoinen riskinotto muutoksen aikaansaamiseksi. Projektissa riskejä yleensä optimoidaan vain poikkeustapauksissa eliminoidaan. Joskus on järkevää nostaa projektin riskitasoa. Liiketoimintaan integroituneessa projektien riskienhallinnassa pitää käyttää kuhunkin vaiheeseen soveltuvaa menettelyä ja prosessoida löydökset niin, että liikkeenjohto saa niistä käyttökelpoista informaatiota. 6.2.1. Esisuunnitteluvaihe Kuten aikaisemmin totesin, esisuunnitteluvaihe on elimellinen osa linjaorganisaation toiminnan suunnittelua. Esisuunnitteluvaiheessa projektilla ei ole organisaatiota, rakennetta eikä tavoitteita. Koska riski liittyy aina tavoitteisiin, esisuunnitteluvaiheessa on kyse vasta epävarmuuden kartoituksesta. Hyvä, helppo ja tuttu riskienhallinnan metodi tässä vaiheessa on SWOT. Liikkeenjohto arvioi projektin hyötyjä suhteessa organisaation vahvuuksiin ja heikkouksiin sekä ympäristön uhkiin ja mahdollisuuksiin. Esisuunnittelussa myös tutkitaan projektin monimutkaisuutta ja siitä johtuvaa epävarmuuden astetta. Kun linjaorganisaatio päättää jatkaa hyvin monimutkaisen projektin suunnittelua, johto ilmaisee silloin riskinottohalukkuutensa. Monimutkaisuus tarkoittaa myös, että seuraavassa suunnittelun vaiheessa täytyy käyttää enemmän aikaa ja osaamista suunnittelutyöhön. Viimeinen, mutta ei suinkaan vähiten tärkeä selvitys liittyy compliance-riskeihin. Linjaorganisaation tulee tarkistaa, onko ehdotettu projekti ulkoisesti lakien, asetusten, sopimuksien yms. mukainen ja onko projekti sisäisesti sopiva visioon, arvoihin, strategioihin, arkkitehtuureihin yms.
SIVU 12 6.2.2. Projektin suunnitteluvaihe Projektin suunnittelijat saavat esisuunnittelijoilta: SWOT tulokset, Näkemyksen projektin monimutkaisuudesta ja epävarmuuden tasosta sekä Selvityksen siitä, että projekti näyttäisi olevan sekä ulkoisten että sisäisten rajoitusten mukainen Suunnitteluvaiheen riskienhallinta kohdistuu: SWOT-tuloksien tarkentamiseen, Projektin tavoitteiden täsmentämiseen. Tavoitteisiin kuuluu budjetti ja aikataulu sekä Projektien välisten riippuvuuksien tutkimiseen. Käytännössä on osoittautunut hyödylliseksi laatia worst case scenario mielikuva siitä, mitä tapahtuisi, jos kaikki menisi pieleen. Tätä voisi kutsua myös projektin stressi-testiksi. Yleensä yksittäiset riskit eivät aiheita katastrofaalisia ongelmia projektille ja sen asettajalle. Ongelma muodostuu merkittäväksi, kun useampi riski laukeaa joko yhtä aikaa tai domino-tyyliin peräkkäin. Jos projektin asettajalla riittää usko projektiin likaisen skenarion jälkeenkin, silloin voidaan edetä projektin käynnistyspäätökseen. Kummassakaan suunnitteluvaiheessa ei ole ollut käyttöä vaikutus-todennäköisyysmatriisilla. Ulkoinen epävarmuus hallitaan normaaleilla liiketoiminnan suunnittelun välineillä. Projektin sisäistä epävarmuutta ei vielä ole, koska projektia ei ole käynnistetty. Usein näkee jo tässä vaiheessa riskiraportissa aikataulun ja resurssien menetyksen muille projekteille. Vahva viesti siitä, että suunnitelma ei joko ole realistinen tai sitten uskotaan johdon mielivaltaiseen käyttäytymiseen. Jos projekteilla ei ole todellisia prioriteetteja, silloin resurssien menettämisen uhka kesken toteutuksen on realistinen. 6.2.3. Projektin toteutusvaihe Projektin asettaja seuraa toimintaympäristön kehitystä ja tekee johtopäätöksensä projektin onnistumismahdollisuuksista (business risk). Samoin linja-organisaatio valvoo projektien välisistä riippuvuuksista johtuvia riskejä. Näiden riskienhallintaa ei pidä yrittää delegoida projektipäällikölle. Projektipäällikön päivittäinen riskienhallinnan tehtävä on ratkoa operatiivisia ongelmia, jotka liittyvät joko tuotokseen, aikatauluun tai budjettiin. Projektipäälliköllä on siis tasan tarkkaan kolmenlaisia riskejä. Päivittäinen ongelmanratkaisu on kompromissin vääntämistä näiden kolmen tekijän välillä. Jos tuotostavoite osoittautuu suunniteltua vaikeammaksi, silloin pitää lisätä resursseja tai pyytää toteutukselle lisäaikaa. Jos aikaa kuluu suunniteltua enemmän, silloin pitää joko lisätä resursseja tai sitten tinkiä tuotoksen laadusta.
SIVU 13 Jossakin vaiheessa päivittäisten kompromissien teko edellyttää suurempia valtuuksia kuin projektipäälliköllä on. Silloin hän tekee riskiraportin projektin omistajalle. Riskiraportti on hänen päätösesityksensä ohjausryhmälle. (Hän voi esittää perusteluineen, että: Tuotostavoitteeseen pitää puuttua, joko sitä keventämällä tai tiukentamalla, Aikatauluun pitää puuttua, joko antamalla lisäaikaa tai sitten tiukentamalla aikataulua tai Budjettiin pitää puuttua antamalla lisäresursseja. Kuten huomaatte, riski voi olla myös positiivinen. Projektiryhmä on ollut niin asiantunteva ja tehokas, että tuotos voisi olla kunnianhimoisempikin, tai aikataulua olisi vara tiukentaa. Linjaorganisaatio, ohjausryhmä, joka näkee myös projekteista muodostuvan kokonaisuuden arvostaa päätösesityksen muotoon laadittua riskiraporttia. Normaali projektin riskiraportti on pitkä lista atomistisia riskejä, ilman järkevää toiminnallista massoittelua. Atomististen riskien siirto ei paranna olennaisesti tilannetta. Riskit matriisin oikeassa yläkulmassa ovat ohjausryhmän jäsenille itsestäänselvyyksiä, joten ne eivät anna uutta arvokasta informaatiota. Ei ihme, ettei tuollainen riskiraportti kiinnosta johtoa. 6.2.4. Projektin roll-out vaihe Tämän vaiheen riskienhallinta ei enää ole projektipäällikön vastuulla. Linjaorganisaatio arvioi vielä kerran tuotokseen liittyvät riskit (business risk) sekä rajoitteisiin liittyvät riskit (compliance risk). Tälle vaiheelle tyypillisesti linjaorganisaatio tutkii muutoksen hallintaan liittyvät riskit.
SIVU 14 C. Jos haluat muutosta Edellisessä kappaleessa annoin joukon vinkkejä, joilla projektin hallintaa ja erikoisesti riskienhallintaa voidaan integroida lähemmäksi liiketoimintaa. Koska kyseessä on pikaopas, kaikkea mahdollista ei voi, eikä ole järkevää kirjoittaa tähän dokumenttiin. Jos kaipaat opastusta, koulutusta tai konsultointia, ota minuun yhteyttä. Olen myös aikaisemmin kirjoittanut pikaoppaan dynaamisesta riskianalyysista. Projektihallinnan muutos dynaamisempaan suuntaan voi tapahtua esimerkiksi seuraavasti Syventävä keskustelu projektien ja riskien hallinnan vastuuhenkilöiden kanssa. Wanha Dynamo organisoi tilaisuuden. Dynaamisemman projektihallinnan esittely johtoryhmälle. Esittelyn kesto olisi noin tunti. Wanha Dynamo valmistelee esittelyn. Mahdolliset tukevat koulutustilaisuudet. Niiden kesto olisi 1-2 tuntia / kohderyhmä. Wanha Dynamo hoitaa koulutuksen. Käytössä olleet projektien hallinnan metodit auditoidaan ja tehdään tarvittavat korjaukset ja selvennykset. Wanha Dynamo auditoi ja antaa suositukset. Projektihallinnan ja projektien riskienhallinnan muokkaaminen dynaamiseksi. Wanhalla Dynamolla on kokemus ja valmiita malleja prosessien kehittämiseksi. Dynaaminen ja rationaalinen projektien hallintaprosessi voi olla sekä helppo että tehokas yhtä aikaa. Kokonaisvaltainen ja ammattimaisesti prosessoitu projektien riskitieto tukee organisaation strategioita, päätöksentekoa sekä sisäistä että ulkoista viestintää. Yhä monimutkaisemmassa toimintaympäristössä toimittaessa hyvä riskienhallinta antaa selvän kilpailuedun. Millä organisaatiolla on varaa olla toimimatta näin?
SIVU 15 Lukijalle Tämä pikaopas on neljäs kirjoittamani. Jos havaitset siinä korjattavaa, kommentoitavaa tai haluaisit siihen jotain täydennystä, ole hyvä ja ota yhteyttä. Tekstiä tuli niin paljon, että jätin pois nipun aihetta selkeyttäviä kaavioita. Voi olla, että ne löytyvät seuraavasta kirjastamme. Opas on tietysti hyvin suppea lähestyminen laajaan ja monimutkaiseen aiheeseen. Jos haluat syvällisempää ja omaan organisaatioosi sovellettua konsultointia tai koulutusta, pyydä tarjous. Seuraavan pikaoppaan aihetta en ole vielä päättänyt. Koska tämä opas on painottunut yksittäisten projektien hallintaan, seuraava opas voisi olla projektiportfolioiden riskienhallinta. Jään odottamaan palautetta. Risto Matilainen Turussa 21. huhtikuuta 2010
Yliopistonkatu 31 C 20100 TURKU www.wanhadynamo.fi http://wanhadynamo.blogspot.com www.dynaaminenjohtaminen.fi Dynaaminen johtaminen