Onnistunut IT-hanke muutoksen mahdollistajana

​Onnistunut IT-hanke?

IT-järjestelmän pystyttäminenhän on helppoa. Tilaaja vain määrittelee, mitä haluaa ja valvoo, että toimitus on sen mukainen. Mutta miksi vain kolmasosa it-hankkeista onnistuu? Halusin pohtia dilemmaa yleisellä tasolla, sillä olenhan ollut monessa järjestelmän käyttöönotossa mukanakin eri rooleissa.

Järjestelmähanke mielletään useasti monimutkaisen työkalun hankinnaksi tai rakennusprojektiksi. Kyse on kuitenkin ennen muuta organisaation kehittämisestä ja sen toiminnan muutoksesta. Ei järjestelmähanketta ilman muutosta. Vaikutukset ovat tällöin monimutkaisempia ja näkymättömämpiä: miten vastuut ja tehtäväkuvaukset muuttuvat, miten se vaikuttaa yrityskulttuuriin.

Määrittelyvaihe on tärkeä, siinä speksataan onnistumisen avaimet. Määrittely konkretisoi tavoitteet IT-hankkeelle. Usein käy vain niin, vaikka määrittelydokumenttia on työstetty huolella niin tilaajalla ja toimittajalla on tiukan paikan tullen eri kuva tahtotilasta ja määrittelyitä tulkitaan omalla tavallaan. En ole vielä osallistunut määrittelyvaiheeseen, jossa toimittaja ohjeistaisi tilaajaa kiinnittämään määrittelyvaiheessa huomiota tiettyihin asioihin. Päätelmäni onkin, että mitään ei määrittelyvaiheessa kannata pitää itsestäänselvyytenä. Se, joka on toiminut joskus ei automaattisesti ole ominaisuutena uudessa järjestelmässä. Myöskin toimintaympäristö saattaa muuttua käyttöönottoprojektin aikana. Tai tilaaja ei määritellessään keksi järjestelmän kaikkia hienoja ominaisuuksia. Määrittelydokumenttia ei yleensä päivitetä uudestaan käyttöönottoprojektin aikana. Kannattaako kuitenkaan lukittautua siihen, mitä projektin alussa on sovittu? Olisiko sittenkin mahdollista siirtyä jatkuvan kehittämisen malliin – tehdä osa-alue ja tarkastella sen toimivuutta, viestiä heti muutostarpeista ja korjata aikatauluja, jos ne oli laadittu liian kunnianhimoisiksi?

Määrittely on siis tavoiteasetantaa. Tämä pitää sisällään myös sen, mikä projektissa määritellään laadukkaaksi toimitukseksi. Onko toimitus sovitun kaltainen, skaalautuva, yhdistettävissä organisaation muuhun tuotantoympäristöön? Onko resurssointi ollut riittävää ja tasapainoista? Resurssointia kannattaa ajatella muunakin kuin kustannustekijänä: kun ihmisiä ottaa varhaisessa vaiheessa projektiin mukaan, tulee sitouttaneeksi heidät ja opetettua järjestelmän kieleen ja ajatusmaailmaan. Niin siinä se tuli sanottua: jokainen järjestelmä tuo toimintaympäristöömme oman ajatusmallinsa.

Järjestelmän mukana muuttuu yleensä myös toimintatapa. Tämä voi tulevista käyttäjistä tuntua hypyltä tuntemattomaan. Kaikki eivät ole kiinnostuneita “laskuvarjohypyistä.” Esimiehen rooli korostuu tällöin kuuntelijana ja ohjaajana. Muutoksen mahdollistaminenkin on siten kohtaamista ja aitoa näkemistä, yhteistyön mahdollistamista ja hengen luomista. Pahin pelko, mitä työntekijällä voi olla on se, että työ katoaa muutoksessa.

Työt eivät katoa, sillä työ on ongelmien ratkaisemista.

Kirjoittajana Merja Rintamäki, IT- ja rahoitusjohtaja