IT-projektijohtamisen ABC, osa 6:
IT-projektijohtamisen prinsiipit

Olen tänä vuonna kirjoittanut omien töideni ohessa tätä blogisarjaa ja astunut samalla omalle epämukavuusalueelle. Nämä kuukaudet ovat olleet opettavaisia, sillä vaikka kirjoitankin paljon työssäni, on OTO-bloggaamiselle löytyvä aika ollut välillä kiven alla. On myös ollut opettavaista huomata, miten oma päivittäinen tekeminen ja siihen vaadittava osaaminen eivät olekaan niin helposti tuotavissa muiden hyödyksi, kun puhutun sanan sijaan on onnistuttava pelkästään kirjoittamalla kommunikoimaan haluamansa tehokkaasti ja siten, että muutkin siitä kiinnostuvat ja saavat käytännön vinkkejä omaan työhönsä.

Ymmärränkin nyt entistä paremmin OTO-projektipäälliköiden tilannetta, jossa ihminen tempaistaan omalta osaamisalueeltaan tuntemattomalle maaperälle talsimaan. Vaikka substanssi on hallussa, ei aina ole niin yksinkertaista tuoda osaamistaan toisten saataville ja vieläpä siten, että muutkin sen ymmärtävät ja kokevat hyödylliseksi.

Kiitos sinulle arvoisa lukija, kun olet löytänyt kiireisestä päivästäsi hetken viettääksesi sen blogiani lukien! Tältä erää tämä on blogisarjani viimeinen osa, ja on aika kerrata, mitä kaikkea olen projektimaailman kulisseissa oivaltanut.

1. Yrityksillä on vielä paljon opittavaa ICT-hankkeiden ostajina

Väitän, että asiakkaan kannalta on järkevää ja kustannustehokasta ottaa IT-ostamisen ammattilainen mukaan jo silloin, kun ICT-hankinta on vasta pilkkeenä silmäkulmassa.
IT-järjestelmän tai sen uuden toiminnallisuuden ostajalla on kova tarve ostaa ja saada hankintansa mahdollisimman nopeasti käyttöön, jolloin kokematon IT:n ostaja voi ostohuumassaan olla lähes täysin ohjelmistotoimittajan konkarimyyjän vietävissä.

Tässä vaiheessa konsultin pitäisi olla jo tukevasti sisällä ostoprojektissa ja paikalla heiluttamassa IT-ostajan ostoslistaa eli liiketoiminnan vaatimuslistaa sekä teknistä vaatimusmäärittelyä, jotka hän on yhdessä asiakkaansa kanssa laatinut. On myös määritelty nykytila ja tehty tarvittavat tulevaisuuden tahtotilan kuvaukset, laadittu alustava riskikartoitus ja liiketoimintalaskelma. Konsultti tuo tolkun ostohuumaan, ja toimii asiakkaan lompakon vartijana.

Hyvin tehty esiselvitys- ja vaatimusmäärittelytyö ennen kilpailutusta voi tuntua turhauttavalta, mutta kärsivällisyys projektin tässä vaiheessa tuottaa aina hedelmää projektin päästyä kunnolla käyntiin. Konsultin mukaantulo ennen järjestelmätoimittajan valintaa tuo toki kustannuksia projektin alkupäähän, mutta olen valmis laittamaan pääni pantiksi, että on projektin aitojen kokonaiskustannusten kannalta edullisempaa, kun IT-hankinta tehdään ammattilaisen avustamana.

IT-projektijohtamisen ABC, osa 1 »

2. Projekteissa kannattaa käyttää asiantuntijoiden apua

Väitän, että ammattilaisen mukaan ottaminen ICT-hankkeisiin kannattaa aina. Asiakkaat ovat kuitenkin välillä arkoja ottamaan ulkopuolisia asiantuntijoita mukaan muutenkin hintaviin ICT-hankkeisiin. Olen samaa mieltä kollegani Lauri Harjulan kanssa, joka uskoo pienten asioiden suureen voimaan.

”Ulkopuoliset asiantuntijat tuovat virtaa ja tuoreen näkökulman tekemiseen. Mitä kokeneempi asiantuntija, sitä enemmän hänellä on hihassaan neuvoja ja parhaita käytäntöjä. Pienet asiat ratkaisevat aina projekteissa, ja kokenut ulkopuolinen asiantuntija tuo usein projektiin pieniä uusia asioita, joilla voi olla onnistumisen kannalta iso merkitys”, Lauri Harjula toteaa.

Hankkeen koosta riippuen ICT-projekteissa on usein tarvetta eri osa-alueiden asiantuntijoille, kuten ratkaisuarkkitehdille, järjestelmäkouluttajalle, laadunvarmistajille ja ammattitaitoiselle projektipäällikölle. Johtamissani ICT-hankkeissa ammattitaitoinen prosessien mallintaminen sekä oikeanlainen testauksen suunnittelu ja läpivienti ovat olleet avainasemassa. Jokainen projekti tai hanke, jossa on ollut mainitsemieni alojen ammattilaiset mukana, on saatettu maaliin ajallaan ja vieläpä siten, että asiakas on ollut lopputulokseen tyytyväinen.

IT-projektijohtamisen ABC, osa 2 »

3. Päätöksenteko on vaikeaa

Väitän, että päätöksien tekemättä jättäminen lähes poikkeuksetta potkaisee kaikkia projektin sidosryhmiä nilkkaan. Pahimmassa tapauksessa seurauksena on koko projektin näyttävä mahalasku. Jotta tällaiseen tilanteeseen ei päädyttäisi, vaaditaan molemmilta osapuolilta rohkeutta ja ammattitaitoa. Mutta mikä siinä päätöksenteossa on niin vaikeaa?

Projektipäällikön tehtäviin kuuluu päätöksenteon valmistelu. Se tarkoittaa päätettävään asiaan liittyvien asioiden kartoittamista ja skenaarioiden luomista vaihtoehtoisten päätösten seurauksista. Kerromme siis etukäteen, mitä mahdolliset päätökset tarkoittavat. Silti joskus tuntuu, että vaikka päätöksenteko olisi miten hyvin valmisteltu, ovat ihmiset arkoja tekemään päätöksiä. Niin, ihmiset, sillä päättäjätason johtajatkin ovat inhimillisiä ihmisiä.

Minun ja kollegoideni kokemusten mukaan päätöksenteon ytimenä ovat luottamus ja ammattitaito. Lue viisi vinkkiäni päätöksenteon helpottamiseen alkuperäisestä kirjoituksestani.

IT-projektijohtamisen ABC, osa 3 »

4. Sisäiset tunnit ovat tärkeitä

Väitän, että jos projektin sisäisiä tunteja ei seurata, aikataulut pettävät ja ihmiset palavat loppuun. Tyypillinen virhe projektia suunniteltaessa ja sen ollessa käynnissä onkin, että ulkoiset kulut ja työtunnit tiedetään hyvin, mutta omien asiantuntijoiden kuormituksesta ei ole kenelläkään kokonaiskuvaa. Kuitenkin odotetaan, että projektiin osallistumisen lisäksi myös varsinaiset ”linjatyöt” hoituvat, mielellään entiseen malliin. Tästä aiheutuukin projektin työntekijälle nopeasti uuvuttavaa piilokuormaa.

Harmillisinta näissä projektiongelmissa on se, että tarjolla olisi helppo, halpa ja nopea ratkaisu: sisäisten työtuntien suunnittelu ja seuraaminen. Tällöin on helpompaa konkreettisesti osoittaa esimerkiksi se, että johonkin työpäivään tai -viikkoon ei enää mahdu lisäsuorituksia. Kun tietty tuntimäärä on varattu täyteen, se on siinä.

IT-projektijohtamisen ABC, osa 4 »

5. Projektin loppuraportti ei ole projektin loppu

Väitän, että kukaan ei seuraa projektinsa hyötyjen konkretisoitumista. Suuri kysymykseni kuuluukin, että miksi ei? 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 työ vie ihmisten työajan koko lailla sataprosenttisesti. Projektien seuraaminen on monimutkaista ja aikaa vievää, eikä useinkaan edes ole selvää, kenen tai keiden se tulisi tehdä.

Olenkin usein pohtinut, voisiko yksi ratkaisu olla se, että nimetään yksi henkilö jo projektin aikana vastaamaan sen jälkiseurannasta? Toki täytyy muistaa, ettei projektin hyötyjen toteutuminen ole tämän yksittäisen henkilön vastuulla, ainoastaan mittaaminen ja poikkeamiin reagoiminen. 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 koko idea konsultin haihattelua, vai voisiko tämä toimia ihan käytännössä?

IT-projektijohtamisen ABC, osa 5 »

Minkä alan ammattilaisia sinun projektisi kaipaa?

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.