Lupasin aiemmassa blogikirjoituksessani valaista hieman tarkemmin sitä, minkälaisiin pohjatietoihin tuloksen arvo - eli Earned Value -tarkastelu voi perustua. Sanasta miestä.

Olenkin muutamaan kertaan maininnut projektin ositusrakenteen (WBS (work breakdown structure)) eduista. Tällainen rakenne on monille projektiammattilaisille tuttu ja uskoisin myös monien muiden käyttävän sitä tietämättä, että kysymys on nimenomaan WBS:stä. Jos tällainen rakenne on tehty hierarkkiseksi ja tarkimman tason tehtäväpakettien laajuus asetettu sopivaksi, on tuloksen arvo -tarkastelu varsin helppoa. Tehtäväpakettien laajuus kannattaa sovittaa projektin seurantakokousten tiheyteen. Jos kokouksia pidetään parin viikon välein, niin sopiva laajuus WBS:n alimman tason tehtäväkokonaisuuksille on noin 1-2 henkilötyöviikkoa. Tällöin tehtäväpakettikohtaiseksi tiedoksi kullakin tarkasteluhetkellä riittää usein tieto siitä, onko kyseinen kokonaisuus aloittamatta, kesken vai valmis. Tuloksen arvo -laskennassa aloittamatta olevien tehtäväpakettien valmiusaste on 0%, keskeneräisten 50% ja valmiiden 100%. Vaikkei keskeneräisten tehtävien valmiusastetieto olekaan täysin tarkka, on koko projektin valmiusaste ja sen pohjalta edelleen tuloksen arvo (valmiusasteella korjattu budjetti) tiedossa kuitenkin riittävällä tarkkuudella, koska kunakin tarkasteluhetkenä projektissa on joukko aloittamatta olevia ja valmiita tehtäviä.

Entä jos riittävän tarkkaa ositusrakennetta ei ole mahdollista tehdä? Tällainen tilanne on usein tuote- ja palvelukehityksessä, jossa tehdään useita tarkentuvia suunnittelu- ja toteutuskierroksia. Kullekin kierrokselle voidaan ja on usein syytäkin budjetoida tietty osuus koko projektin kustannuksista ja toisaalta budjetti voidaan samoin jakaa projektissa tehtävien laajan tason työ- eli tehtäväalueiden mukaan. Tällaisia voivat olla esimerkiksi ohjelmistokehitys, laitekehitys ja koulutus. Näin meillä onkin tarvittava rakenne tuloksen arvo -tarkastelua varten. Ohessa esimerkki, jossa tarkastelu rajoitettu tilanpuutteen vuoksi yhteen työalueeseen.

Edelleen vaihtoehtona on sovittaa tarkastelu erillisiin katselmuskohtiin, jolloin kussakin tarkastelukohdassa lasketaan saavutettu toiminnallisuus tai valmisteltu suunnitteludokumentaatio ja tällainen valmiusastetieto toimii tuloksen arvo -laskennan pohjana. Edellytyksenä on luonnollisesti tieto siitä, kuinka suuri budjetti on alunperin suunniteltu ja varattu kuhunkin katselmuspisteeseen mennessä.

Viimeisimmät mainitut menetelmät eivät välttämättä ole aivan tarkkoja, mutta tarkoitus onkin saada edes jonkinlaista tietoa projektin edistymisestä ja valmiusasteesta ja käyttää hyväksi aikataulu- ja kustannuspoikkeamien sekä ennusteiden tarkastelussa.

Projektinhallinnan kustannus- ja myös aikatauluseurannassa on käytetty jo 1960-luvun lopulta lähtien ns. Earned Value - eli tuloksen arvo -menetelmää. Tosin termistö on vakiintunut nykyiseen muotoon vasta 1990-luvulla. Menetelmä on kuvattu projektinhallinnan standardeissa ja sitä testataan sertifikaatteja suoritettaessa. Projektinhallinnan ammattilaiset siis tuntevat menetelmän aika laajasti, mutta kovinkaan monet yritykset eivät sitä järjestelmällisesti käytä. Lisäksi siihen liittyy muutamia väärinkäsityksiä tai -ymmärryksiä, joita pyrin tässä kirjoituksessa oikaisemaan.

Tuloksen arvolla tarkoitetaan tehtyä työtä sille alunperin suunnitelluilla kustannuksilla. Englanninkielen termi 'Earned Value' onkin varsin valaiseva, koska se voitaisiin kääntää projektissa ansaituksi arvoksi tai aikaansaaduksi tulokseksi. Kun laskettua tuloksen arvoa (EV = Earned Value) verrataan todellisiin kustannuksiin (AC = Actual Cost), saadaan laskettua kustannuspoikkeama (CV = Cost Variance) kaavalla CV=EV-AC. Projektin alkuperäisen suunnitelman mukaista etenemistä taas kuvaa Planned Value (PV), joka tarkoittaa suunniteltua työtä alunperin suunnitelluilla kustannuksilla. Tästä sekä tuloksen arvosta saadaan laskettua aikataulupoikkeama (SV = Schedule Variance) kaavalla SV=EV-PV. Tuloksen arvo -menetelmän hyötynä onkin jakaa projektissa syntyneet poikkeamat yhteismitallisiksi eli samoissa yksiköissä (yleensä rahassa) lasketuiksi kustannus- ja aikataulupoikkeamaksi. Edelleen voidaan laskea sekä kustannus- (CPI = Cost Performance Index) että aikataulutehokkuusindeksit (SPI = Schedule Performance Index) kaavoilla CPI=EV/AC ja SPI=EV/PV.

Kuulostaa hienolta ja eräs sudenkuoppa onkin ajatella, että sekä kustannus- ja aikatauluseuranta hoituvat tuloksen arvo -menetelmän avulla. Se antaa aikataulupoikkeaman kuitenkin vain yleisellä tasolla, eikä kerro vielä mitään siitä, minkälaisissa tehtävissä myöhästyminen on tapahtunut. Mikäli myöhästyminen on tapahtunut aikataulun kannalta ei-kriittisissä tehtävissä, ei laskennallisesta aikataulupoikkeamasta huolimatta ole välttämättä vielä mitään ongelmaa. Mikäli se on syntynyt kriittisen polun tehtävissä, ollaan sen sijaan pahasti suunnitellusta aikataulusta jäljessä. Aikatauluseuranta vaatii mielestäni aina myös aikajanalla tehtyä tarkastelua, jossa huomioidaan kriittisen polun edistyminen. Tiivistettynä voi sanoa projektin olevan hyvällä mallilla, mikäli laskettu kustannuspoikkeama on korkeintaan lievästi negatiivinen ja kriittisellä polulla ei ole pahoja myöhästymiä.

Tuloksen arvon käyttämättä jättämistä on myös perusteltu sillä, että kustannukset - esimerkiksi yksikkökustannukset - muuttuvat niin usein, ettei menetelmästä ole hyötyä, mutta tällaiset asiat menetelmän onkin juuri tarkoitus tuoda esiin. Jos projektissa ollaan edetty alkuperäisen aikataulun mukaisesti, mutta yksikkökustannukset ovat kasvaneet alkuperäisestä projektisuunnitelmasta, ei aikataulupoikkeamaa ole syntynyt ollenkaan, koska sen molemmat tekijät (EV = Earned Value ja PV = Planned Value) lasketaan alunperin suunnitelluista kustannuksista. Syntynyt kustannuspoikkeama taas antaa tietoa siitä, kuinka iso ongelma kustannusten arvioinnissa on.

Usein väitetään myös, ettei tuloksen arvo -menetelmää voida soveltaa, koska projekteista ei ole mahdollista laatia selvää ositusrakennetta (WBS = Work Breakdown Structure). Ositusrakenne onkin varsin tärkeä projektin onnistumiselle ja se kannattaa aina tehdä, kun vain mahdollista. Osituksen tärkeyttä tarkastelen myös aiemmassa blogikirjoituksessani. Tuloksen arvo -menetelmän ei kuitenkaan välttämättä tarvitse perustua tällä lailla määriteltyihin tehtäväpaketteihin, vaan muitakin vaihtoehtoja on. Niistä lisää myöhemmin.

Niinpä. Lausahduksesta jotenkin paistaa läpi, että projekti tai projektit ovat jo käynnissä siinä vaiheessa, kun näitä toiveita esitetään. Ensin kannattaisi ehkä ohjeistaa kaikille projektiryhmille projekteissa käytettävät työskentely- tai menettelytavat, jolloin uutta projektipäällikköä ei kenties tarvittaisi ollenkaan.

Miksei tällaisia ohjeistuksia sitten aina ole luotu? Toistuvassa 'rutiinimaisessa' työskentelyssähän ohjeet ovat melko lailla itsestäänselvyys. Kyse ei välttämättä ole laiskuudesta, vaan siitä, että projektit saatetaan kokea siinä määrin ainutkertaisiksi työkokonaisuuksiksi, ettei erillistä ohjeistusta pidetä tarpeellisena. Menettelyjen ja ohjeiden koetaan usein myös jäykistävän toimintaa liiaksi. Kiistatta kuitenkin ohjeistusten ja projektitoiminnan muulla kehittämisellä on saatu erittäin hyviä tuloksia aikaiseksi. Muutamia esimerkkejä järjestelmällisen projektinhallinnan eduista on edellisessä blogikirjoituksessani.

Toisaalta projekteilla voi jo hyvin olla ainakin nimellinen projektipäällikkö, jolloin tuosta lauseesta jää ennen projektipäällikköä sanomatta 'osaava' tai 'ammattimainen'. Osaavalla voidaan tarkoittaa joltain alalta paljon asiantuntemusta ja kokemusta hankkinutta tai sitten projektinhallinnan osaavaa henkilöä. Tässä mielessä 'ammattimainen' on kenties parempi ilmaisu. Edelleen ongelmaksi jää se, miten tällainen ammattimaisuus määritetään.

Asiasta on monenlaisia mielipiteitä. Jotkut painottavat ryhmänjohtamis- ja toiset menettelytaitoja. Eräs lähestymistapa on arvioida projektipäällikön osaamista tiettyjä standardeja ja niiden pohjalta laadittuja sertifikaatteja (esim. IPMA, PMI tai PRINCE2) vastaan. Näissä vain harvemmin käsitellään todella vaikeita asioita, kuten huonontuvaa työskentelyilmapiiriä tai ristiriitatilanteita.

Entä jos jostain löytyy alansa asiantuntemusta omaava ammattimainen projektipäällikkö? Eräs kouluttajakollegani on muistuttanut tällaiseen ratkaisuun liittyvistä vaaroista useaan otteeseen. Kuilu muihin projektiryhmäläisiin voi vain olla liian suuri. Projektipäällikkö nähdään vähintäänkin outona tyyppinä, joka puhuu ihan omaa kieltään, eikä muu projektiryhmä välttämättä ymmärrä, miksi tiettyjä yhteisiä menettelytapoja ja ohjeistuksia olisi noudatettava. Kehittämisen täytyy koskettaa kaikkia projekteissa mukana olevia henkilöitä.

Hieman tarkoitushakuinen otsikko, myönnetään. On kuitenkin kiinnostavaa arvioida, kuinka paljon hyvät projektipäälliköt voivat yrityksen tai organisaation tuloksellisuutta ja kannattavuutta parantaa. Tähän liittyen sain seurata erinomaista Kone Oyj:n projektinhallintaa koskevaa esitystä muutaman vuoden takaisilla Projektipäivillä. Yritys oli lähtenyt järjestelmällisesti sekä kehittämään projektinhallinnan menettelytapoja ja ohjeistuksia että kouluttamaan projektipäälliköitään, jotka olivat aiemmin tyypillisesti työskennelleet asennustehtävissä.

Arvioitu vaikutus kannattavuuteen oli 7 prosenttiyksikköä. Tuolloin Koneen tilauskanta oli arvoltaan noin 1,5 Mrd €, joten jokainen voi itse laskea tulosvaikutuksen. Tuollaisella kannattavuusparannuksella voi jo muutaman miljoonan tällaiseen kehityshankkeeseen sijoittaakin.

Muita esimerkkejä on lukuisia. Isoissa avaruushankkeissa työskentelevän suomalaisyrityksen projektipäälliköt totesivat yksituumaisesti, että "Project management is mission critical". Yrityksellä ovatkin käytössä projektinhallintastandardien kuten PMBOK^®-oppaan määrittelemät projektin suunnittelu-, ohjaus- ja seurantamenetelmät. Suomalaistaustaisessa maailmanlaajuisesti isoja toimitusprojekteja tekevässä yrityksessä taas on luotu oma samaiseen PMBOK®-oppaaseen pohjautuva projektinhallinnan 'raamattu', jonka pohjalta projektipäälliköille koulutetaan eri projektinhallinnan aihepiirejä säännöllisesti.

Projektipäälliköiden sertifioinnilla on näissä yrityksissä merkittävä rooli. Sertifiointi pohjautuu joko yleisiin IPMA:n, PMI:n tai PRINCE2:n sertifikaatteihin tai sitten yritykset ovat luoneet omat sertifiointiohjelmansa. Sertifikaatit ovat vaatimuksena projektinjohdollisiin tehtäviin. Usein niitä vaaditaan myös alihankkijoilta ja kumppaneilta. Tällaisella menettelyllä varmistetaan se, että kaikki osapuolet ymmärtävät projektinhallinnassa käytetyt menettelyt ja sanaston mahdollisimman samalla tavalla.

Miten tämä näkyy palkkauksessa? Projektinhallinnan ja projektipäälliköiden kehittämiseen panostavissa yrityksissä ja organisaatioissa projektipäälliköt ovat yrityksen parhaiten palkattuja työntekijöitä siitä yksinkertaisesta syystä, että heidän osaamisensa tai osaamattomuutensa vaikuttaa merkittävästi yrityksen tai organisaation tulokseen. Onko sinun organisaatiollasi tai yritykselläsi varaa olla kehittämättä tai sertifioimatta projektipäälliköitä?