IT-projektijohtamisen ABC, osa 5:
Projektin loppuraportti ei ole projektin loppu!

Tämä saattaa kuulostaa tulta monille teistä lukijoista:

Alussa oli positiivinen business case-laskelma, jolla pystyttiin aukottomasti osoittamaan projektin lopputuloksena syntyvät hyödyt: ”Liiketoiminnalle syntyy säästöjä, kun ylläpidettävien IT-järjestelmien määrä laskee. IT-osasto pääsee vanhoista, harmaita hiuksia aiheuttavista legacy-järjestelmistä eroon. Talousosasto saa vihreää viivan alle.” Käynnistyslupa liiketoiminnan sisäiseen kehityshankkeeseen heltiää vaivatta ja vielä projektityön alkaessa kaikki näkevät ruusunpunaisten lasien läpi edessä häämöttävän autuaamman tulevaisuuden.

Nooh, siinä projektin edetessä tulee vastaan pari muuttujaa ja joudutaan hieman antamaan budjetin osalta periksi, mutta onneksi niitä sisäisiä työtunteja ei kirjata sen tarkemmin. Saadaan projekti maaliin lähes aikataulussa ja eiköhän niistä uuden järjestelmän parista purkkavirityksestäkin kohta päästä eroon, sitten jatkokehitysprojektissa viimeistään.

Loppuraportin ja todellisuuden välinen kuilu

On aika kirjoittaa projektin loppuraportti ja koota yhteen se, mitä projektin aikana opittiin: ”Projektin tavoitteet saavutettiin muutama kuukausi aikataulusta jäljessä ja budjetti ylittyi muutamalla kymmenellä prosentilla. Opittiin, että vaatimukset olisi ollut hyvä kirjata tarkemmalla tasolla ja määrittelyihin liittyenkin oli muutama opittava asia. Tärkeintä kuitenkin: Business case on yhä vihreällä ja elämä hymyilee. Projektiryhmä siirtyy uusien töiden kimppuun ja linjatyö jatkuu.”

Sehän kuulosti kivalta. Todellisuudessa liiketoiminta tuskailee, kun projektin aikana ei saatukaan sitä, mitä oikeasti tarvittiin. Kiireen ja aikataulupaineen vuoksi oli pakko hyväksyä toimittajan ehdottama väliaikaisratkaisu, joka runnottiin projektin muutoshallintaprosessin läpi puoliväkisin. IT-osasto mennä nilkuttaa purkkavirityksellä vielä puoli vuotta, kunnes saadaan päivitetty versio tuotantoon ja räikeimmät bugit korjattua. Talousosasto ihmettelee, miksi IT-kulut eivät laske, vaikka business case -laskelmien mukaan niin piti käydä.

Älä ota kesäkiss…projektia

Projektien pitäisi tuottaa määriteltävissä olevia hyötyjä, jotta ne kannattaa käynnistää. Teoriassahan vastuu näiden hyötyjen mittaamisesta ja todentamisesta on viimekädessä projektin omistajalla. Sillä, jonka liiketoimintaa projektin lopputuotos eniten hyödyttää ja jonka budjetilla projektin kulut katetaan. Miksi sitten niin harva projektin omistaja hoitaa vastuunsa ja seuraa projektin suunniteltujen hyötyjen toteutumista?

Oman kokemukseni mukaan yksi merkittäväimmistä syistä on se, että kaikki muu päivittäinen – ns. normaali linjatyö – vie ihmisten työajan koko lailla sataprosenttisesti. Ne tehtävät, joihin ei riitä tarpeeksi kiinnostusta – esimerkiksi sen vuoksi, että oma osaaminen ei ole ajan tasalla – putoavat helposti työlistalta pois. Jos sinne koskaan edes päätyvät.

Projektien seuraaminen on monimutkaista ja aikaa vievää. Usein ei ole edes selvää, kenen tai keiden se tulisi tehdä. Kas, siinäpä on kaikki elementit ö-mappiin päätymiselle.

Miksi KUKAAN ei seuraa projektin hyötyjen konkretisoitumista?

Kävin kiinnostavia keskusteluja tehdessäni taustatyötä tätä blogikirjoitusta varten. Vain aniharva juttukumppanini kertoi olleensa töissä yrityksessä, jossa ihan oikeasti oltaisiin panostettu ja sitouduttu projektien jälkiseurantaan. Ei, vaikka projektinhallinnan elinkaarimalli-teoriat sisältävät poikkeuksetta jokin asteisen projektien jälkiseurannan. Miksi sitten niin harvassa yrityksessä kuitenkaan tätä tehdään?

Näiden yli 15 vuoden aikana, jotka olen projektien parissa viettänyt, olen tullut siihen tulokseen, että me ihmiset tuppaamme menemään sieltä missä aita on matalin. Nämä ns. IT-projektit, joiden parissa minäkin päiväni puurran, mielletään helposti IT-osaston vastuulla oleviksi kokonaisuuksiksi. Ne ovat kuin ihmisten kiusaksi langetettuja tuomiopäivän tehtäviä, joista ei osata eikä haluta ottaa liiketoiminnassa aitoa vastuuta. Ymmärrän tämän hyvin. Liiketoiminnan substanssiosaaminen on ihan jossain muualla kuin IT-painotteisissa kehityshankkeissa. Toisaalta IT-osaston on vaikea ottaa vastuu liiketoiminnan kehityshankkeesta ja sen business casen toteutumisesta. He kun ovat vain yksi osa projektia ja itseasiassa se projektin merkittävin osuus tapahtuu heidän näkökulmastaan liiketoiminnan päivittäisessä työssä ja siihen liittyvissä prosesseissa. Niihinhän IT-osastolla ei ole osaa eikä arpaa.

Entä jos JOKU seuraisikin?

Isommissa yrityksissä PMO on se taho, jonka vastuulla on varmistaa projektien hyötyjen mittaaminen. On kuitenkin iso joukko yrityksiä, joihin PMO on turhan järeä ratkaisu. Olenkin usein pohtinut, voisiko yksi ratkaisu olla se, että nimetään yksi henkilö jo projektin aikana vastaamaan jälkiseurannasta? Ja nimenomaan siten, että tehtävä löytyy hänen tuloskortistaan. Toki täytyy muistaa, ettei projektin hyötyjen toteutuminen ole tämän yksittäisen henkilön vastuulla, vaan vain mittaaminen ja poikkeamiin reagointi. Tämä tietysti vaatii sen, että taustaprosessit ja vaadittava tuki ovat henkilön käytettävissä. Pelkkä poikkeamista raportoiminen kun ei vielä korjaustoimenpiteisiin johda.

Samaisen henkilön vastuulla voisi olla myös uuden toimintamallin jalkauttamisen varmistaminen ja uuden tietojärjestelmän käyttäjäkokemusten kerääminen ja eteenpäin raportointi. Onkohan tämä koko idea konsultin haihattelua, vai voisiko toimia ihan käytännössä? Mitä sanotte?

Kuka seuraa yrityksesi projektien hyötyjen konkretisoitumista?

Ninna Linnainmaa
johtava konsultti
ninna.linnainmaa@project-it.fi

Jaa artikkeli:

Soita:

020 7348 790

tai jätä yhteydenottopyyntö:

  • Kenttä on validointitarkoituksiin ja tulee jättää koskemattomaksi.