Onko IT-projektimenetelmistä hyötyä vai haittaa?

IT-projektit ovat haastavia. Pahimmillaan projektille asetetut tavoitteet ovat mahdottoman monimutkaisia, projektilta vaaditut valmistumisajat epärealistisia ja projektiin allokoidut resurssit riittämättömiä. IT-projektipäällikön arkea onkin taiteilu projektin laajuuden, aikataulun ja budjetin välillä kompromisseja tehden. Tasapainoisen projektinhallinnan tuloksena syntyy liiketoiminnalle hyötyjä tuottava tietojärjestelmäkokonaisuus, joka on siirrettävissä jatkuvaan palvelutuotantoon ja mahdollistaa jatkokehityksen.

Kuka sitten on vapaaehtoinen lähes mahdottomalta kuulostavaan IT-projektipäällikön tehtävään?

Kuka sitten on vapaaehtoinen lähes mahdottomalta kuulostavaan IT-projektipäällikön tehtävään? Ei juuri kukaan ja siksi osaavista IT-projektipäälliköistä pula. Monet varsinkin teknisen asiantuntijan tehtävissä toimivat välttelevät projektipäällikön tehtävän epämiellyttävältä kuulostavaa painetta ja vastuuta sekä sen edellyttämää ammatillista kasvua.

Tästä syystä erityisesti ketterät menetelmät ovat tulleet täyttämään IT-projektien johtamistyhjiötä. Nämä menetelmät ovat mahdollistaneet teknisille asiantuntijoille oman työnsä lisäksi enemmän vaikutusmahdollisuuksia myös projektikokonaisuuden osalta ilman todellista vastuuta projektista (esim. aikataulusta, kustannuksista, laajuuden hallinnasta ja riskeistä).

Metodologiat, menetelmät ja viitekehykset

Projektinhallinnan osaamisvajeen kompensoimiseksi eri tahot ovat kehittäneet erilaisia omiin näkemyksiinsä ja tarpeisiinsa IT-projektinhallinnan metodologioita, menetelmiä ja viitekehyksiä. Metodologioiden tarkoituksena on tarjota yleisluontoisia ohjeita siihen, mitä projektissa yleensä kannattaa tehdä ja miten.

Määrittelytavasta riippuen projektinhallinnan metodologioita voidaan listata kymmeniä (esim. SCRUM, Prince2, PMBOK, SAFe; täältä löytyy yksi lista metodologioita tai täältä toinen). Lisäksi sekä toimittajilla että asiakasorganisaatioilla on omiin tarkoituksiin räätälöityjä metodologioita, jotka voivat olla joko yksityiskohtaisia tai käsitteellisiä, ja joiden soveltamista valvotaan enemmän tai vähemmän kurinalaisesti.

Metodologioiden haasteena on se, että ne eivät pysty täyttämään vajeita projektin onnistumisen kannalta kriittisessä osaamisessa esim. liiketoimintavaatimusten määrittelyn, ratkaisuarkkitehtuurin suunnittelun tai konkreettisten tilanne- ja organisaatiokohtaisten työsuunnitelmien laatimisen osalta.

Projektimetodologia voi esimerkiksi ohjeistaa laatimaan viestintää ja vastuita selkeyttävän RACI-matriisin, mutta metodologia ei kerro mille projektin osa-alueille se kannattaa laatia, eikä myöskään millä tiedoilla matriisi pitää täyttää, jotta siitä olisi suurin hyöty. Metodologian kehittäjät eivät ole maanneet laakereilla, vaan RACI-matriisin tilalle on kehitetty ”parempia vaihtoehtoja” mm. PARIS-, PACSI-, RASCI-, RASI-, RACIQ-, RACI-VS-, CAIRO-, DACI-, RAPID- ja RATSI-matriisit (katso Wikipediasta, josset usko!). Kaikki tämä metodologia on olemassa ja silti mikään näistä ei kerro, miten matriisi kannattaa käytännön projektitilanteissa täyttää.

Johtajan osaaminen ja kyky soveltaa metodologiaa

Johtaja tarvitsee syvällisen perehtyneisyyden ja käytännön kokemuksen kautta muodostunutta osaamista myös johdettavan toiminnan sisällöstä. Samasta syystä sotilasorganisaatiotkin ovat hierarkkisia, eikä upseeriksi voi päätyä ilman, että on ensin ollut alokas. Oheisessa kuvassa on ote Hannes Olkkosen kirjasta Taktiikan perusteet, joka on julkaistu vuonna 1928. Kirjan sivulla 286 on esitetty jalkaväkirykmentin kiilaryhmitys hyökkäyssuuntaan.

Jääkärieversti Olkkosella oli merkittävä rooli talvi- ja jatkosodan upseereiden ja aliupseereiden kouluttamisessa.  Jos olisit ollut silloin päämajassa päättämässä, olisitko luottavaisena antanut rykmentin komentoon kenelle tahansa (sotilaskokemuksesta riippumatta) ja hoitamaan ”homman” noudattamalla piirrosta ja Olkkosen kirjan muita ohjeita? 

Avarasti ja luovasti ajateltuna projektimenetelmissä voidaan nähdä mm. seuraavat käytännön ”hyödyt”:

  1. Erilaiset yhdistykset voivat mahdollistaa olemassaolonsa jakaen oman projektimetodologiansa palvojille papukaijamerkkejä tai sertifikaatteja.
  2. Menetelmäkoulutuksia järjestävät yritykset voivat tehdä kannattavaa liiketoimintaa lupaamalla muutaman päivän koulutuksen tuottavan projektiammattilaisia, koska teoriassa käytännöllä ja teorialla ei ole mitään eroa.
  3. Organisaatiot voivat vaivatta ja hyvin perustein kuluttaa henkilöstön koulutusbudjetin helposti toistettavaan kirjainlyhenteeseen, jonka taakse uskotaan tiivistyvän kaikki projektit mullistava osaaminen.

Ei projektimetodologioista haittaa ole niin kauan, kun ohjausryhmä muistaa varmistaa, että projektipäälliköllä on riittävä osaaminen soveltaa metodologiaa konkreettisella tasolla kyseisen projektin erityistarpeet huomioiden. Liiallinen projektimetodologiaan nojautuminen on kuitenkin vaarallista. Projektin ohjausryhmä ei saa virheellisesti olettaa, että tietty projektimetodologia valitsemalla voitaisiin merkittävästi vähentää projektin riskejä tai että metodologia toisi suoraan ratkaisuja projektin konkreettisiin haasteisiin. Metodologian sijaan projektin onnistumisen tärkein avain on projektipäällikön osaaminen ja kyky soveltaa metodologian tarjoama viitekehys projektin tarpeisiin.

Haluatko tietää tarkemmin, miten voit parantaa IT-projektityön laatua soveltamalla projektimenetelmiä tarkoituksenmukaisesti? Tutustu neuvonanto- ja koulutuspalveluihini ja ota yhteyttä!

Kirjoittaja on Cheetah Consulting Oy:n perustaja ja johtava konsultti Teemu Leppänen. Teemulla on yli 15 vuoden monipuolinen käytännön kokemus IT-ratkaisujen toimittamisesta kansainvälisissä teknologiayrityksissä ja tarjoaa yrityksensä kautta erilaisia IT-neuvonanto- ja koulutuspalveluita.