projektipomo

”Sitä saat, mitä mittaat” – Ohjaavatko mittarit toimintaasi oikeaan suuntaan?

Havahduin miettimään mittareiden tärkeyttä, kun toimistotalomme kellariin tehtiin murto ja kaksi palo-ovea rikottiin. Sen sijaan, että standardimalliset peltiset palo-ovet olisi vaihdettu uusiin, niin huoltoyhtiö päätyi korjaamaan ne hitsaamalla ja maalaamalla. Ensin kävi yksi mittaamassa ja tutkimassa, seuraavana päivänä hitsattiin isot paikat ja kolmantena päivänä maalattiin. Vaikea kuvitella, että ovien korjaus tuli todellisuudessa halvemmaksi kuin niiden vaihtaminen uusiin.

Huoltoyhtiössä toimintaa varmaankin mitataan ulkoisten ostojen määrällä. Omalle työlle ei lasketa arvoa tai ainakaan sitä ei kohdisteta projektille. Mittareiden mukaan kannattaa siis tehdä kolme päivää työtä, kun mitattuina kuluina on vain muutama neliömetri peltiä ja purkki maalia.

Mittari on aina myös viesti

Mittarit kertovat mitä koetaan tärkeäksi. Vanha sanonta ”Sitä saat, mitä mittaat” on osuva.

Pitää olla tarkkana, etteivät mittarit kannusta vääränlaiseen osaoptimointiin. Salkunhallintablogissani pari kuukautta sitten kiinnitin jo huomiota mittareihin ja niiden tärkeyteen. ”Mittarit kertovat projektin tilasta. Niiden pitää olla yhteismitallisia ja kertoa olennaista projektista.”

Mittauksen ja ohjauksen tulee olla samalla tarkkuustasolla. On vaikeaa ohjata toimintaa, jos ei ole oikeaa tilannekuvaa eikä käsitystä siitä, mikä vaikutus tehdyllä ohjauksella oli. Toisaalta on turha mitata mitään sellaista, jota ei myös aktiivisesti seurata ja käytetä ohjaukseen.

Kulujen ja tuottojen oikea kohdistaminen on tärkeää. Yhdestä, paljaasta luvusta ei ole paljon iloa, jos pitää tietää, mikä osa projektista tuotti hyvin, mikä oli hädin tuskin kannattavaa ja mikä meni tappiolle. Mittareista pitää olla myös takaisinkytkentä esim. tarjouslaskentaan, jotta jatkossa vältyttäisiin samoilta virheiltä.

Mittaaminen ei ole välttämättä helppoa

Projektin aikataulun tai kulujen mittaamisen ja seuraamisen voisi kuvitella olevan helppoa. Usein kuitenkin projektin lopussa, kun verrataan suunnitelmia ja tuloksia, suunnitelmat näyttävät hämmästyttävän tarkoilta ja kulut olleen hyvin hallinnassa, vaikka projekti olisi myöhästynyt vuodella ja kulut tuplaantuneet. Tämä johtuu siitä, että usein suunnitelmia päivitetään projektin kuluessa, joten projektin lopussa suunnitelma ja toteuma vastaavat lähes identtisesti toisiaan.

Tässä yksinkertainen tapa tarttua mittaamisen ja seurannan problematiikkaan:

Ota suunnitelmista projektin päätöspisteessä kopio talteen (baseline) ja vertaa toteumaa, viimeisintä ennustetta ja baselinea keskenään. Näet miten suunnitelmat muuttuvat projektin edetessä ja mihin muutos kohdistuu.

Usean baselinen rinnakkainen seuranta ja vertailu vaatii kunnon työkalun, mutta se onkin jo toisen blogin aihe…

Projektinhallintaa pilvessä

Projektipomo veti taannoin tietojärjestelmäprojektin, johon osallistui ihmisiä useista organisaatioista. Projektin omistavan organisaation lisäksi mukana oli henkilöitä ratkaisun toimittavasta yrityksestä ja muilta yhteistyökumppaneilta. Projektitiimi oli kansainvälinen: Osallistujat edustivat viittä maanosaa ja tekivät töitä eri aikavyöhykkeillä.

Projektia käynnistettäessä oli selvää, että yksi projektin menestyksen avaimista tulisi olemaan tehokas viestintä ja tiedon jakaminen sekä projektitiimin sisällä että ulkoisten tahojen kanssa. Asian ratkaisemiseksi projektille perustettiin intranetissä projektisivusto, joka toimi projektitiimin yhteisenä virtuaalisena työtilana. Työtilaan koottiin projektin organisaatiokaavio yhteystietoineen, aikataulusuunnitelmat, työkokonaisuuksien kuvaukset, raportit, tehtävälistat, tekninen dokumentaatio, ynnä muuta tarpeellista.

Projektin työtila helpotti projektipomon tehtävää projektin ohjaamisessa ja seurannassa. Työtilaan oli julkaistu projektin aikataulu, josta projektin jäsenet saattoivat nähdä sekä omat tehtävänsä, että projektin aikataulun kokonaisuudessaan. Projektin jäsenten vastuulla oli päivittää työtilaan omien tehtäviensä edistyminen viikoittain ennen projektin viikkokokousta.

Käytännön haasteeksi yhteisen työtilan hyödyntämisessä osoittautui se, että toimittajan ja yhteistyökumppanien henkilöt eivät päässeet työtilaan ilman omistavan organisaation käyttäjätunnusta ja VPN-yhteyttä organisaation verkkoon. Organisaatiolla ei ollut käytössään keinoja intranetissä olevan projektisivuston julkaisemiseksi suoraan yhteistyökumppaneille. Tietoturvan ja viestinnän tarpeet olivat ristiriidassa keskenään, ja tietoturva voitti.

Nykyisin on tarjolla pilvipalveluratkaisuja, joissa yllä kuvatun kaltaisia projektisivustoja voidaan perustaa ja jakaa yhteistyökumppaneiden kanssa ilman VPN-yhdyskäytäviä ja kalliita ylläpitokustannuksia. Verkosta palveluna ostettu projektisivusto on hyvä väline yllä kuvatun kaltaisten projektien tueksi. Projektisivuille voi kutsua niin oman organisaation henkilöt kuin projektissa mukana olevat ulkopuolisetkin. Projektisivuston käyttöoikeudet voi määritellä ja rajata projektiorganisaation tarpeiden ja tietoturvavaatimusten mukaisesti.

Pilvestä hankittu projektinhallinnan järjestelmä ei sovi kaikkiin tilanteisiin. Jos projektinhallinnanjärjestelmä on tarpeen integroida vaikkapa taloushallinnon järjestelmään, voi järjestelmäintegraatio olla viisainta toteuttaa talon sisäisten järjestelmien välillä. Oman järjestelmän raportointimahdollisuudet ovat monipuolisemmat, koska tietokantaan voi tehdä suoria kyselyjä. Joskus myös projektissa käsiteltävä tieto on niin luottamuksellista, ettei sitä haluta jakaa verkossa. Tällöin organisaation sisäinen järjestelmä on edelleen paras ratkaisu.

Oman ja pilvestä palveluna hankitun järjestelmän välimuotokin on mahdollinen. Verkosta voi ostaa palvelinkapasiteettia, ja jättää palvelinten hallinnan palveluntarjoajan hoidettavaksi. Sovellusten ylläpidon ja hallinnan voi tässä mallissa pitää oman organisaation tehtävänä.

Pilvipalvelut ovat tuoneet uusia, kiinnostavia mahdollisuuksia projektityön ja viestinnän tehokkaaseen hoitamiseen monenvälisissä projekteissa. Projektipomo suosittelee omien projektinhallinnan tarpeiden kartoittamista ja tarjolla olevien mahdollisuuksien selvittämistä yhdessä kokeneen asiantuntijan kanssa.

Projektin aikataulu – vain piirros projektikansiossa?

Projektipomo on pannut huolestuneena merkille, että suomalaisten projektihenkilöiden kyky ja halu tehdä aikatauluja on pahasti rapautumassa. Onko niin, että aikataulun merkitystä työvälineenä ei enää ymmärretä?

On hyvä muistaa, että parhaimmillaan aikataulu on monipuolinen suunnittelun, seurannan ja kommunikoinnin väline. Aikataulu perustuu projektin ositukselle. Hyvin tehty ositus kuvaa meille, mitä loppu- ja välituloksia projektissa tuotamme ja miten. Oikein tulkittuna se kuvaa myös niitä asioita, joita emme projektissa toteuta. Toisin sanoen, se toimii rajauksena projektin sisällölle. Se voi kertoa, kenen vastuulla mikäkin asia projektissa on sekä myös kuka työn tekee ja mikä on siihen liittyvä työmäärä.

Aikataulu on seurantaväline. Se kertoo päivitettynä, mitkä työt on tehty ja mitkä tekemättä. Se kertoo myös, olemmeko epäonnistumassa tai myöhästymässä sovituista tavoitteista niin työmäärän kuin ajankin suhteen. Onko niin, että edellä mainittuja tietoja emme enää projektissa tarvitse?

Aikataulu toimii muutoksenhallinnan välineenä. Hallitusta muutoksesta esitetään aina kustannus-, aikataulu- ja tekninen vaikutus. Nämä siis pitäisi arvioida jokaisen muutospyynnön osalta. Viimeinen kohta eli tekninen vaikutus ottaa kantaa tai arvioi vaikutuksia jo tehtyihin ratkaisuihin. Tässäkin siis hyvin tehty aikataulu antaa tukea muutoksen vaikutusten arvioinnille ja riskienhallinnalle.

Projektipomo on pistänyt huolestuneena merkille myös piirteen, että jos aikataulu tehdään, se tehdään vain siksi, että asiakas sitä vaatii. Kun se on kerran tehty, se tulostetaan, taitetaan siististi projektimappiin eikä siihen koskaan enää palata. Näin se palvelee kyllä sopimuksen tekoa ja mahdollisesti toimituksen myöhästymisen sanktiointia, mutta se ei liene aikataulusuunnittelun päätarkoitus.

Projektipomo on nähnyt myös aikatauluja, jossa tehtävien kestot, logiikka sekä työmäärät on arvioitu, mutta aikataulun käytännön toteutuksen realistisuus on jäänyt analysoimatta. Tarkoitan tällä sitä, että tyypillisesti analysoimattoman aikataulun mukaan resurssitarve vaihtelee erittäin paljon viikosta toiseen. Käytännössä projektin henkilöstön lisääminen tai vähentäminen viikoittain ei ole mahdollista, joten lopputuloksena on ihan varmasti myöhästyvä projekti. Jos aikataulu jaksetaan analysoida kuormituksien kautta, toimii se myös apuna aikatauluriskien hallinnassa.

Suomalaisista yrityksistä puuttuvat muutamaa poikkeusta lukuun ottamatta aikatauluinsinöörit. Suomessa aikatauluja ylläpitää esimerkiksi projektipäällikkö kaikkien muiden töiden ohella – jos pitää. Aikatauluinsinöörejä on ollut suomalaisissa yrityksissä töissä vielä 1980- ja 1990-luvuilla. Kun keskustelen esimerkiksi norjalaisten projektiasiantuntijoiden kanssa, he kertovat ”plannereiden” ammattikunnasta, joka on erikoistunut aikataulusuunnitteluun, niiden analysointiin, edistymän seurantaan ja raportointiin projekteissa.

Olisiko meidänkin syytä palata vanhaan hyvään aikatauluinsinöörien aikaan? Projektipomon täytyy kuitenkin ensin varmistaa joulunalusaikataulunsa…

Projektisalkunhallinta ja tilannekuva

Pari blogia sitten Projektipomo kirjoitti tilannekuvan hahmottamisen tärkeydestä ja faktoihin perustuvasta päätöksenteosta. Kunnollinen projektisalkku ja siihen perustuva säännöllinen seuranta ovat ensiarvoisen tärkeää kokonaiskuvan hahmottamisessa.

Projektipomo on huomannut asiakkaissa liikkuessaan, että vaikka yksittäisen projektin saama huomio organisaatiossa on usein hyvällä tolalla, niin kokonaisuuksien hahmottamisessa ja portfolionhallinnassa on toivomisen varaa. Onpa jossain tehty suunnilleen samaa toiminnallisuutta kahdessa eri projektissa ja jouduttu yhdistämään ne kolmannessa. Lopputuloksena liki kolminkertainen työmäärä ja tuplaantunut toimitusaika.

Nykyisessä taloustilanteessa ei varmaan ole organisaatiota, jossa projektien aloitusta ei jouduttaisi harkitsemaan todella tarkasti. Pääsevätkö toteutukseen ne hankkeet, jotka huutavat kovimmin ja osaavat lobata asiansa parhaiten? Ajaudutaanko osaoptimointiin kokonaisnäkemyksen puutteessa?

Tilannekuva esiin

Projekteilla pitää olla sopiva määrä luokittelutekijöitä, jotta toisiinsa liittyvät tai vaikuttavat projektit on helppo seuloa samaan kuvaan. Toisaalta luokittelutekijöitä ei saa olla liikaa, koska tieto alkaa helposti rapautua vaadittaessa sellaista, jota ei tarvita eikä käytetä. Hyviä luokittelutekijöitä ovat esim. asiakas/tilaaja, toimittava organisaatio, teknologia/tuotealue, projektin koko ja vaihe.

Mittarit kertovat projektin tilasta. Niiden pitää olla yhteismitallisia ja kertoa olennaista projektista. Salkunhallinnassa erilaiset liikennevalot ja muutostrendit ovat tärkeitä seurattavia: Ne auttavat kiinnittämään huomion olennaiseen ja keskittämään toimenpiteet erityistä tukea vaativiin projekteihin. Terveesti johdetuissa projekteissa ei pitäisi tapahtua äkkinäisiä eikä yllättäviä muutoksia. Eräs Projektipomon linjanvetäjäystävä tokaisikin kerran, että ”Varmin tapa lentää pihalle on, kun projektipäällikön tilanneraportissa mennään vihreältä punaiselle peräkkäisissä statusseurannoissa”. Silloin ei projektipäällikkö ole todellisuudessa ymmärtänyt tilannetta tai vielä pahempaa: pyrkinyt piilottelemaan ikäviä asioita.

Salkunhallinnan työkalut

Salkunhallintaa voi pyörittää yksinkertaisimmillaan Excelissä. Parasta olisi, jos Exceliä ylläpitää korkeintaan pari henkilöä ja projektipäälliköt säännöllisesti antavat lukunsa heille kirjattavaksi. Näin varmistetaan etteivät excelin yleensä varsin herkästi rikki menevät laskentasäännöt korruptoidu. Historiatietojen tallentaminen on tärkeää paitsi trenditietojen laskemista varten niin myös oppimisen kannalta.

Jos pelkän seurannan lisäksi haluaa samalla tehdä ohjaavia toimenpiteitä, kuten resurssihallintaa tai jos päivitettävä massa kasvaa suureksi, on aika harkita oikeaan salkunhallintatyökaluun siirtymistä. Tarpeeton kopiontityö poistuu ja data on ajantasaisempaa, edellyttäen tietysti, että tiedot päivitetään ajallaan.

Parhaimmillaan projektisalkusta näkee yhdellä vilkaisulla kokonaistilanteen ja pystyy poimimaan mahdolliset ongelmatapaukset. Päätöksenteko perustuu ajantasaiseen tilannekuvaan ja faktapohjaiseen tietoon.

Tuloksen arvo, teoreettista roskaako?

Taloushallinnon mittarit ovat yleensä hyvin yksinkertaisia. Menikö rahaa enemmän kuin tuli?

Ne jotka tuntevat projektien seurannan menetelmiä ja erityisesti menetelmän, jota kutsutaan Tuloksen arvo -menetelmäksi (Earned Value, Earned Value Management), tietävät ettei projektin mittaaminen ole aivan noin yksinkertaista.

Olisitpa nähnyt sen talousjohtajan ilmeen, jolle kerroin, että projektin onnistumista pitäisi ehdottomasti mitata katteen sijasta mittareilla: ACWP, BCWS, BCWP. Näiden kumulatiivisten ja aikajaksotettujen mittareiden perusteella voidaankin sitten helposti laskea CV ja SV -mittarit, jotka sitten oikeastaan jo näyttävät projektin kokonaistilanteen.

No, kommentti oli selkeä: ”Tuollaista teoreettista roskaa ei kannata konsulttien tänne tulla höpöttämään.”

Kuitenkin projektien onnistumisen seurantaan kaivataan kipeästi mittareita ja indikaattoreita. Mittareita tarvitaan, jotta voidaan arvioida projektien kannattavuutta ja onnistumista toteutuksen päätyttyä. Projektin johtamisen kannalta tärkeämpää kuitenkin olisi löytää mittareita, jotka auttavat reagoimaan jo projektin aikana. Onko aikataulu myöhästymässä? Ovatko kustannukset ylittymässä? Pitäisikö vapauttaa tai lisätä resursseja, vai pyrkiä neuvottelemaan paremmat tuntihinnat? Johtuuko kustannusylitys kasvaneista kustannuksista, vai siitä että olemme edellä aikataulusta?

Onkin olennaista arvioida mittarien tarve erikseen projektisalkun hallinnan ja liikkeenjohdon näkökulmasta ja erikseen projektin läpiviennin johtamisen näkökulmasta.

Päättynyttä projektia voidaan arvioida sen mukaan, ylittikö se budjettinsa. Jos projekti ylitti budjettinsa, tiedämme, että se ylitti alkuperäisen kustannusarvion. Mutta mitä tämä merkitsee? Oliko kustannusarvio alun pitäen liian matala? Tehtiinkö projektin aikana tarkennuksia ja muutoksia, joiden vuoksi alkuperäiseen budjettiarvioon ei ollut enää järkevää tavoitella?

Toimitusprojektin osalta voidaan laskea kate. Tuliko rahaa enemmän kuin meni? Kate voidaan laskea projektin päätyttyä, mutta voidaanko sitä käyttää projektin ohjauksen tukena? Auttaako projektin aikana laskettu kate tekemään paremman ennusteen projektin lopputulemasta? Projektin toteutuksen aikana katteen arviointi on haastavaa, sillä tulot ja menot ajoittuvat eri aikajaksoille ja lisäksi lopputuloksiin vaaditaan muutoksia, jotka osaltaan muuttavat myös aikataulua ja kustannuksia.

Myös aikataulussa pysymistä käytetään paljon projektin mittarina. Jos projekti pysyy aikataulussa, on sillä toki paremmat mahdollisuudet muodostua onnistuneeksi. Aikatauluseuranta ei kuitenkaan kerro lopputuloksen laadusta tai siitä, jouduttiinko käyttämään ennakoitua enemmän kustannuksia, jotta aikataulu saatiin pidettyä.

Projektin ennustaminen vaatii aikajaksotettua suunnitelmaa ja toteutuneiden kustannusten seuraamista aikajaksoittain. Ennusteen laatimiseksi pitää kyetä osoittamaan: 1) Paljonko suunnitelman mukaan kustannuksia piti kulua tähän mennessä ja mitä niillä piti saada aikaiseksi? 2) Paljonko kustannuksia todella on syntynyt ja mitä niillä on saatu aikaan? 3) Paljonko nyt valmistuneen tuloksen piti maksaa suunnitelman mukaan?

Jos projektijohtamisen yksi tavoite on arvioida toteutuksen aikana projektin lopputulemaa ja tarvittaessa päivittää ennuste projektin lopputulemasta, tarvitaan kunnollinen suunnitelma ja seurantakäytännöt. Jos tarvittava tieto on saatavilla, tarjoaa Tuloksen arvo -menetelmä oivat välineet projektin todellisen tilanteen arviointiin ja ennusteen tekemiseen.

Tilannekuva ja päätöksenteko

Projektipomon käsiin ajautui Jalkaväen Taisteluohjesäännön JVO:n toinen painos vuodelta 1996. Kirjan valmistumisen aikaan puolustusvoimien komentajana toimi kenraali Gustav Hägglund, joka oli vahvistanut sen allekirjoituksellaan käyttöönotettavaksi 13.4.1995.

JVO:n luvussa 3, ”Vihollistiedustelu”, ja sen jakeessa 140 silmiini osui sana ”tilannekuva”. Jakeessa on kirjoitettu viisaasti: ”Henkilökohtaisten havaintojensa ja eri tahoilta saamiensa tiedustelutietojen perusteella pataljoonan komentaja muodostaa itselleen oikean ja ajan tasalla olevan tilannekuvan, joka on välttämätön taistelujen oikea-aikaisessa johtamisessa.”

Jakeen viesti on tarkka ja osuu suoraan myös projektin johtamisen arjen ytimeen. Jakeen voikin lausua pienin muutoksin seuraavasti:

”Henkilökohtaisten havaintojensa ja eri tietolähteistä saamiensa tietojen perusteella projektipäällikkö muodostaa itselleen oikean ja ajan tasalla olevan tilannekuvan, joka on jatkuvasti välttämätön projektin johtamisessa.”

Edellä oleva voi tuntua itsestään selvältä. Totta kai! Nehän ovat Dashboard, Projektin raportti, Projektin tilannekatsaus, Portfolion liikennevalot tai muu vastaava projektin tilannekatsaus. Tarkka lukija huomaa kuitenkin nyanssit ja sen merkittävän eron, johon usein sorrumme projektien johtamisessa. Se ero on ”muodostaa itselleen oikean ja ajan tasalla olevan tilannekuvan”.

Tämän vastine projektimaailmassa on tilannetietoisuus. Tilannetietoinen projektipäällikkö tietää, mitä ympärillä tapahtuu ja osaa toimia tietojensa perusteella. Tähän sisältyy tietojen havaitseminen, niiden ymmärtäminen ja niiden tulevaisuuden tilan ennakointi. Tilannetietoisuuden ylläpitäminen on jatkuvaa toimintaa ja projektipäällikön elinehto pystyäkseen johtamaan projektiaan onnistuneesti tavoitteet saavuttaen, kustannuksia halliten ja aikataulun mukaan.

Projektipäällikön ympäristö on täynnä välineitä ja ohjeita projektin johtamiseen ja tilannekuvan ylläpitoon. Saatavilla on lukuisia käsikirjoja ja ohjelmistoja dashboardeineen. Näissä piilee kuitenkin se vaara, että käytännöt ja välineet jäävät metodologioiksi ja projektiprosesseiksi, eli pakkopullaksi, jossa irtaudumme helposti tilannetietoisuuden perusajatuksesta – vaatimuksesta ”muodostaa itselleen oikean ja ajan tasalla olevan tilannekuvan”.

Projektin johtamisessa ja ohjaamisessa tilannetietoisuus on onnistuttava luomaan projektipäällikön/-johtajan, projektin ohjausryhmän ja liikkeenjohdon tasolla. Tämä on vaativa tehtävä ja edellyttää projektipäälliköltä erityistä paneutumista oman tilannekuvan ja tilannetietoisuuden ylläpitoon. Muutoin sitä ei voi välittää projektille eikä projektin sidosryhmille.

Tilannekuva ja tilannetietoisuus eivät ole itseisarvoja vaan on hyvä pitää mielessä, että ne liittyvät saumattomasti päätöksentekoprosessiin: ”Havaitseminen – Ymmärtäminen – Ennakointi – Päätöksenteko – Toiminta” ja paluu takaisin alkuun ”Havaitseminen – Ymmärtäminen – Ennakointi …”

Lopuksi vielä yksi siteeraus JVO:sta. ”Pataljoonan komentaja johtaa pataljoonaa saamansa tehtävän ja tilanteen mukaisesti ottaen huomioon ylemmän johtoportaan taisteluajatuksen.” Mikä onkaan tätä parempi ohje myös meille siviileille!

PMO – valmisvaate vai räätälinpuku?

Ovatko eri organisaatioiden projektitoimistot yhdenkoon valmisvaatteita? Pukineita, jotka on valmistettu kustannustehokkaasti ja poimitaan vain hyllyltä tai henkarista, mutta jotka istuvat vain pienelle osalle kantajistaan kuin nakutettu, kun taas muiden päällä ne monesti joko kirraavat kiinni saumoista tai sisältävät aivan liikaa kasvuvaraa? Vai voidaanko projektitoimiston ajatella olevan kuin räätälinpuku, joka on leikattu käyttäjänsä mittojen mukaan?

Projektitoimiston eli PMO:n tarkoituksena on projektiorganisaation tuottavuuden nostaminen ja projektien parempi onnistuminen organisaatiossa. Projektitoimistot voidaan jakaa projektien johtamisen näkökulmasta kahteen ryhmään:

Toimintaa tukeva, konsultoiva PMO, jonka vastuulla on projektipäälliköiden kouluttaminen, projektijohtamisen prosessit, käytännöt ja työvälineet sekä näiden kehittäminen.
Projektien toteuttamisesta vastaava PMO, jossa projektipäälliköt ovat osa projektitoimiston organisaatiota ja heitä lainataan liiketoiminnoille tarpeen mukaan.

Projektitoimistojen tehtäviä ja vastuita voidaan kuvata yleisten toimintamallien avulla (esim. P3O ja PMI PMOSIG). PMO:n tarkoitus toteutuu käytännössä kuitenkin kovin eri tavoin eri organisaatioissa. Investointi-, tuotanto-, tuotekehitys-, rakennemuutos- ja ICT-projektit asettavat kukin erilaisia vaatimuksia PMO:n toiminnalle. Lisäksi PMO:t poikkeavat toisistaan niin tehtäviensä kuin organisaationsakin osalta. Yksikertaisimmillaan PMO on muutamien projektitoiminnan avainhenkilöiden muodostama virtuaalinen tiimi; laajimmillaan se on useiden projektiammattilaisten muodostama kiinteä toimintayksikkö.

Organisaatiot ovat rakentaneet PMO:t omien tavoitteidensa ja tarpeidensa mukaan. Ja niin sen pitääkin olla. Erilaiset PMO-toimintaa kuvaavat mallit ja viitekehykset on tehty sovellettaviksi. Ei ole syytä rajoittaa projektitoimiston tehtäväkenttää eikä ole oikeaa tai väärää PMO:ta, kunhan sen organisaatio ja toimintatavat palvelevat organisaation asettamia tavoitteita. Projektitoimistojen kehittämisen täytyy lähteä liikkeelle organisaation tarpeista. Näin täytetään PMO:n toimintaan kohdistuvat odotukset ja saavutetaan halutut hyödyt.

PMO:n kehittämiseen on tarjolla toiminnan sisällön, laadun ja kyvykkyyden kehittämiseen tähtääviä asiantuntijapalveluita. Toiminnan perustaksi voi asettaa jonkin yleisen viitekehyksen (esim. PMI, IPMA, PRINCE2), joka tarjoaa sovellettavia prosessikuvauksia ja toimintamalleja.

Omissa toimeksiannoissani olen osallistunut hyvin erilaisiin tilanteisiin projektitoimistoa perustettaessa. Kun lähtökohtina ovat yhteisön tavoitteet, PMO:n organisaatio ja tehtävät pitää sovittaa niihin sopiviksi. Kehittämisponnistus valuu hukkaan, ellei toimintamallia saada käyttöön tai sitä ei noudateta. Osallistumisen, käytännöllisyyden ja valmennuksen avulla voidaan luoda muutokselle välttämätön motivaatio.

Viitekehykset ovat vain lähtökohta projektitoimiston kehittämiselle. Lopputulos on aina ainutlaatuinen, organisaation tavoitteisiin sovitettu projektijohtamista tukeva toiminto. Yhtä sopiva ja hyvin istuva kuin räätälinpuku.