Epäonnistuneista IT-hankkeista uutisoidaan toistuvasti. Uutisissa annetaan tulosvaroituksia, toimitusjohtajia vaihdetaan ja miljoonainvestointeja hukkaantuu. Kuitenkin vain jäävuoren huippu ylittää uutiskynnyksen: tutkimusten mukaan vain vajaa kolmannes IT-projekteista onnistuu. Trendi ei ole muuttunut sitten 90-luvun puolivälin, josta lähtien Standish Group on tehnyt ohjelmistoprojektien laatuseurantaa.
Vain vajaa kolmannes IT-projekteista onnistuu.
Luvut ovat hurjia. Gartnerin analyysin mukaan IT-investoinnit olivat maailmanlaajuisesti vuonna 2018 noin 3,7 biljoonaa dollaria (biljoona on tuhat miljardia eli ykkönen ja 12 nollaa, tässä tapauksessa nollineen siis 3 700 000 000 000 dollaria). Kun summasta laskee hukatut dollarit, ollaan edelleen luvuissa, joita ei voi edes käsittää.
Tutkimusten havaintoja tukevat myös omakohtaiset kokemukset. Törmään työssäni toistuvasti tilanteisiin, joissa asiakkaiden IT-projektit ovat joko epäonnistuneet täysin tai joissa niiden kustannukset ovat moninkertaistuneet. Yhteistä tilanteille on se, että hukatut euromäärät ovat isoja – ja varsin usein ne ovat kaatuneet asiakkaan maksettavaksi.
Työskenneltyäni IT-alalla yli 20 vuotta minun on valitettavan helppo allekirjoittaa analyysien väitteet. Miten näin voi olla? Jos rakennettu silta sortuu, voidaan olla melko varmoja, että samaa virhettä ei tehdä toista kertaa – koko toimialalla. Ohjelmistojen tekemisessä huono laatu ”sallitaan”, koska näin on aina ollut.
Ja ongelma vain kasvaa.
Digitalisaation myötä tarve ohjelmistoille kasvaa jatkuvasti ja yhä uusilla toimialoilla. Koska laatuongelmaa ei ole lähdetty korjaamaan, tulee myös pieleen menneiden projektien ja hukattujen investointien määrä kasvamaan. Tilanne on yritysten kannalta kestämätön, sillä vahinkojen suuruus heiluttaa pahimmillaan koko yritystä. Romutetut hankkeet voivat viedä koko kehitysbudjetin mennessään, jolloin uusiksi tekeminen ei tule kysymykseen.
Mikä IT-projekteissa mättää?
Kun pieleen mennyttä projektia avaa, löytyy syitä tyypillisesti pöydän molemmin puolin. Projektinhallinnallisia ongelmia on helppo tunnistaa alkaen määrittelyjen heikkoudesta, osapuolten sitoutumattomuudesta, projektin seurannasta sekä teknisistä asioista. Mahdollisia syitä voi olla kymmeniä, ja niistä löytyy paljon tutkittua tietoa. Projektien koon rajoittaminen, osapuolten sitoutumisen varmistaminen ja ketteryys ovat tutkitusti hyviä lähtökohtia projektin varmistamisessa. Kyse on siitä, kenen pitäisi osata tarvittavat varmistukset tehdä ja/tai vaatia.
Ohjelmistot uivat digitalisaation myötä osaksi lähes kaikkea, mikä tarkoittaa lähes kaikkien yritysten muuttumista askel kerrallaan IT-yhtiöiksi. Ohjelmistojen tekeminen – ja niiden teettäminen – on kuitenkin erittäin vaativaa työtä, joka ei välttämättä ole asiakkaan ydinosaamista. Varsinkaan jos kokemusta aiheesta ei juuri ole. Pahimmillaan projektia tehdään pitkäänkin yhteisymmärryksessä toimittajan kanssa, vaikka suunta voi olla lähtökohtaisesti koko ajan vinossa. Vahingot paljastuvat aina viimeistään silloin, kun rahat loppuvat.
Kenen on vastuu?
Ohjelmistotoimittajan tulisi lähtökohtaisesti varmistaa, osaako asiakas ostaa ja pärjääkö yritys projektissa. On kohtuutonta vaatia, että täysin toisella toimialalla toimiva yritys muuttuu ammattimaiseksi IT-ostajaksi tai kooditaloksi hetkessä. Jos ohjelmistotoimittaja on projektinhallinnan sekä teknisen puolen ammattilainen ja osaa lisäksi varmistaa asiakkaan tarpeet ja kyvykkyyden sekä projektin alussa että sen aikana, on projektilla lähtökohtaisesti aika suuret onnistumisen edellytykset.
Ohjelmistojen ostaja – keskity näihin
Hyvä toimittaja suhtautuu hyvällä tavalla kriittisesti projektiriskeihin myös asiakkaan puolella ja erityisesti asiakkaan puolesta. Riskianalyysi tulee tehdä aina ennen varsinaisen projektin aloittamista.
Onnistumisen varmistaminen lähtee siitä, että ollaan ylipäätään hankkimassa oikeaa asiaa oikean ongelman ratkaisemiseksi – vieläpä toteutettuna oikealla tavalla. Ratkaisua tulee arvioida yrityksen liiketoiminnallisten tavoitteiden kautta. Kyse on ensimmäisestä kriittisestä pisteestä, joka varsin usein jää varmistamatta.
Ratkaisua tulee arvioida liiketoiminnallisten tavoitteiden kautta.
Kun ratkaisu on arvioitu päteväksi, siirrytään selvittämään projektinhallinnan edellytyksiä projektin läpiviemiseksi. Tämä on toinen kohta, jossa usein oikaistaan. Hyvä toimittaja tarkkailee oikeaa suuntaa ja asetettujen liiketoiminnallisten tavoitteiden täyttymistä asiakkaan puolesta aktiivisesti myös projektin aikana. Tämä ei ole asiakkaan kyseenalaistamista vaan asiakkaan puolesta hallinnointia palveluna. Vastaavan laadunvalvonnan pitäisi olla ehdoton vaatimus toimittajan suuntaan aina ja kaikissa IT-projekteissa, ja siihen panostaminen on erittäin halpa vakuutus.
Referenssit vastaavista ratkaisuista ja muista projekteista puhuvat myös puolestaan. Referenssit tulisi tarkistaa myös toimittajan asiakkailta. Selvitä aluksi, kehitettiinkö oikea ratkaisu oikeaan ongelmaan, ja sen jälkeen, miten projektin läpivienti onnistui ja hallinnoitiinko asiakkaan riskejä.
Tarkistuslista yksinkertaistettuna
- Ratkaisenko oikeaa asiaa?
- Hankinko oikeanlaisen ratkaisun?
- Tehdäänkö ratkaisu oikein?
- Onko projektinhallinta osaavaa ja kunnossa?
- Onko projektin tekninen osaaminen kunnossa?
- Ovatko toimittajan referenssit edellämainittujen osalta kunnossa?
Onnistuneiden projektien puolesta,
Kirjoittaja toimii ohjelmistokehitys-, analytiikka- ja digitaalisia markkinointipalveluita tuottavan Digital Talents Oy:n toimitusjohtajana, joka on Talentree Oy:n tytäryhtiö.
Lähteet: https://www.gartner.com/en/newsroom/press-releases/2018-10-17-gartner-says-global-it-spending-to-grow-3-2-percent-in-2019
https://www.scrumalliance.org/community/articles/2016/october/what-we-really-know-about-successful-projects
