Blogi

Poteroituminen kävi kalliiksi Kajaanille

Daniel Wellner

Kajaanin IT-hanke sai toukokuussa valitettavaa julkisuutta. SAP HCM -projekti päätettiin keskeyttää budjetin noustessa yhdestä miljoonasta 3,5 miljoonaan euroon, TIVI:n artikkelissa kerrotaan.

Sivusta on tietenkin helppo huudella – jälkiviisastelusta puhumattakaan – mutta muutama kohta pisti TIVI:n artikkelissa silmään. Olisiko farssi voinut olla vältettävissä tiiviimmällä yhteistyöllä?

Iteratiivinen kehittäminen nojaa avoimeen viestintään

Nykyään suurimmassa osassa IT-hankkeita suositaan iteratiivisen kehittämisen mallia, jossa kommunikaatio asiakkaan ja toimittajan välillä on keskeisessä roolissa. Iteratiivisen mallin idea on se, että projektin tai hankkeen osapuolet istuvat alas esimerkiksi kahden viikon välein keskustelemaan: 

  • Missä ollaan nyt?
  • Mitä ollaan opittu ja millaisia ongelmia on tullut vastaan?
  • Miten niihin reagoidaan yhdessä?
  • Vaikuttavatko ne projektin etenemiseen?

Näin molemmat osapuolet ovat aina kartalla siitä, missä mennään, ja suunnitelmia voidaan tarvittaessa kehittää ja parantaa opitun pohjalta.

Iteratiivinen malli soveltuu hyvin IT-hankkeisiin, joissa lopputulos ei ole alusta alkaen selvillä. Jos se olisi, softa olisi jo luotu, eikä sitä tarvitsisi enää kehittää. Uutta luodessa edetään tuntemattomalla maaperällä, jolloin yksityiskohtaista tietoa päämäärästä ei ole.

Koska kartoittamattomalla maaperällä eteen voi ilmaantua yllättäviä esteitä, suunnitelmia on voitava muuttaa tai päivittää hyvinkin nopealla aikataululla. Näin hanke saadaan ohjattua oikealle raiteelle ennen kuin on liian myöhäistä. Tämä kuitenkin vaatii jatkuvaa viestintää toimittajan ja asiakkaan välillä.

Projekti ei etene poteroista käsin

Jos Kajaanin hankkeessa olisi edetty iteratiivisen mallin mukaan, haasteiden ja viivästysten ei olisi pitänyt tulla asiakkaalle yllätyksenä. Niistä olisi keskusteltu säännöllisin väliajoin yhteisissä tapaamisissa.

TIVI:n artikkelista saa kuitenkin kuvan, ettei projektin tilanteesta ja haasteista oltu viestitty asiakkaalle riittävän selkeästi. Toimittajan mukaan “projektissa oltiin jo loppusuoralla” kun asiakas päätti viheltää pelin poikki. 

Tässä vaiheessa kunnan henkilöstö alkoi olla jaksamisen äärirajoilla, mistä toimittaja ei puolestaan ollut riittävän tietoinen. Jos tämä ei kerro kommunikaation ja luottamuksen puutteesta, niin mikä sitten? Luottamusta on vaikea säilyttää, jos asiakas pettyy toistuvasti huonosti hoidetun viestinnän vuoksi.

Silloin kun töitä tehdään yhdessä, myös ongelmat ratkotaan yhdessä. Vaikeistakin asioista on puhuttava avoimesti ja rehellisesti, jotta molemmat ymmärtävät, mistä kenkä puristaa. Poteroituminen ei auta ketään.

Mitä case Kajaanista voi oppia?

Onnistuneen IT-hankkeen ehdoton edellytys on avoin ja läpinäkyvä viestintä. Asioita pimittämällä päädytään vain luottamuspulaan, josta ei enää ole paluuta.

Jos jokin yhdessä sovituista asioista osoittautuukin odotettua vaikeammaksi toteuttaa, siitä on viestittävä selkeästi. Näin asiakas näkee, ettei yllättävä viivästys tai muutos suunnitelmassa ole kenenkään syy. Avoin kommunikointi tulee varmistaa jo sopimuksissa, jottei poteroasetelmaa pääse syntymään.

Lisäksi toimittajan on oltava aktiivisesti läsnä asiakkaan arjessa ja ymmärrettävä, mihin ongelmaan järjestelmällä haetaan ratkaisua. Muuten ei päädytä molempia tyydyttävään lopputulokseen. On toimittajan vastuulla ottaa selvää, mitkä asiakkaan kipupisteet ovat – ja pyrkiä selättämään ne.

Ja kun ongelmia ilmenee, niitä täytyy tuoda esiin ja suunnitelmia on uskallettava muuttaa. Sinnikäs eteneminen hammasta purren väärään suuntaan johtaa vain entistä syvemmälle suohon. Tai tässä tapauksessa 3,5 miljoonan euron laskuun.

IT-hankkeiden riskejä voi kuitenkin pienentää – kun valmistautuu niihin etukäteen ja tietää, mitä tekee. Lue lisää Minimoi riskit -oppaastamme!

Minimoi ohjelmistokehityksen riskit

Aiheet: Ohjelmistokehitys, Asiakaskokemus

Daniel Wellner
Daniel Wellner

Sysartin kehityksen kaasujalka ja toivoton maailmanparantaja.