Haastavat IT-hankkeet – miksi ne ajautuvat vaikeuksiin ja miten suunta käännetään?

IT-hankkeet eivät epäonnistu teknologian vaan johtamisen takia. Jos IT-projektisi epäonnistuvat niin katso mieluummin peiliin, älä järjestelmään. Huono IT-hanke on lähes aina johtamisongelma. IT-hankkeet ovat modernin liiketoiminnan elinehto. Silti onnistuneet hankkeet harvoin ylittävät uutiskynnyksen. Uutisten perusteella moni projekti myöhästyy, ylittää budjettinsa tai epäonnistuu kokonaan. Harvemmin syy on teknologiassa. Yhteistä epäonnistumisille on, että syyt liittyvät ihmisiin, päätöksentekoon ja johtamiseen.

Oma työurani on IT-projektien täyttämä. Olen suunnitellut, johtanut ja ollut osa toteutustiimiä lukuisissa projekteissa. Mukaan mahtuu muutama painajainen, pari pelastusretkeä ja onneksi lukuisia onnistuneita projekteja. Tässä kirjoituksessa käyn läpi, miksi IT-hankkeet ajautuvat vaikeuksiin, ja ennen kaikkea, miten niiden suunta voidaan vielä kääntää.

Miksi IT-hankkeet epäonnistuvat?

Vaikka jokainen projekti on erilainen, epäonnistumisten taustalla toistuvat samat syyt. Tässä on minun subjektiivinen TOP 10 lista projektin vaikeuksiin johtaneista syistä:

• Epäselvät tai jatkuvasti muuttuvat vaatimukset. Projektissa ei ole yhteistä ymmärrystä siitä, mitä ollaan rakentamassa. Vaatimukset elävät jatkuvasti ilman hallintaa.
• Huono projektinhallinta. Aikataulut ovat epärealistisia, priorisointi puuttuu ja kokonaiskuva hämärtyy.
• Heikko viestintä. Liiketoiminta, kehittäjät ja johto eivät puhu samaa kieltä. Oletuksia tehdään ilman varmistusta.
• Liian laaja tai paisunut scope. Jos yritetään tehdä liikaa kerralla, mikään ei valmistu kunnolla.
• Tekninen velka ja heikko arkkitehtuuri. Nopeat ratkaisut kasaavat ongelmia, jotka hidastavat kehitystä myöhemmin.
• Puutteellinen testaus. Virheet löydetään liian myöhään – usein vasta tuotannossa.
• Väärä teknologian valinta. Valitaan trendikäs tai muuten käyttötarkoitukseen sopimaton ratkaisu.
• Tiimin ongelmat. Osaamispuutteet, vaihtuvuus tai huono yhteistyö heikentävät tekemistä.
• Sidosryhmien sitoutumattomuus. Asiakas tai johto ei ole aktiivisesti mukana projektissa.
• Liiallinen optimismi. Aikataulut ja budjetit perustuvat toiveisiin, eivät realismiin. Yllätyksille ei ole varattu aikaa eikä budjettia.

Miten käännetään ongelmiin joutuneen projektin suunta?

Vaikeuksiin ajautunut projekti ei ole automaattisesti menetetty. Usein suunta voidaan kääntää, mutta se vaatii päättäväisiä ja joskus epämukavia toimia.

• Pysähdy ja arvioi tilanne rehellisesti. Ensimmäinen askel on hyväksyä todellisuus. Missä mennään oikeasti? Mitkä asiat eivät toimi? Mitä riskejä on edessä? Ilman tätä projektia ei voi korjata.
• Rajaa scope uudelleen. Usein suurin ongelma on liian laaja kokonaisuus. Leikkaa ominaisuuksia. Keskity kriittiseen ytimeen ja siirrä “nice-to-have” ominaisuudet myöhemmin toteutettaviksi. Vähemmän, mutta valmista, on aina parempi kuin paljon keskeneräistä.
• Selkeytä vastuut ja päätöksenteko. Epäselvä omistajuus tappaa projektin. Varmista, että päätöksiä tehdään nopeasti ja poista turhat hyväksymiskerrokset. Nimeä Product Owner, joka johtaa projektin arkea. Varmista, että projektilla on omistaja/sponsori, joka voi tarvittaessa tehdä vaikeimmatkin päätökset.
• Rakenna toimiva rytmi. Kaaos korjataan rytmillä. Palastele tehtävät siten, että niiden etenemistä voidaan seurata joka päivä. Lyhyet sprintit ja säännölliset demot mahdollistavat nopean reagoinnin, jos asiat ovat menossa väärään suuntaan.
• Panosta viestintään radikaalisti. Lisää läpinäkyvyyttä. Näytä edistyminen konkreettisesti, kerro ongelmista ajoissa ja varmista yhteinen ymmärrys.
• Korjaa tekninen perusta tarvittaessa. Jos arkkitehtuuri on rikki, sitä ei voi ohittaa. Tee kriittiset refaktoroinnit ja stabiloi järjestelmä. Ilman tätä kehitysnopeus ei koskaan parane.

Milloin projekti voidaan pelastaa?

Usein ongelmiin joutuneen projektin pelastaminen on tuskaista taistelua loppuun saakka. Aina projektin suunnan oikaisu ei onnistu. Projektin pelastaminen edellyttää, että johdolla ja asiakkaalla on aito halu tehdä muutoksia. Jos johto tai asiakas ei ole valmis tekemään muutoksia, mikään ei muutu. Projektin johtajuus tulee määrittää selkeästi ja johtajalla tulee olla valta tehdä päätöksiä. Realistinen uudelleensuunnittelu on pelastustoimien ydin. Projektille tarvitaan uusi ja realistinen aikataulu, scope ja resurssisuunnitelma.

Projektin pelastaminen vaatii riittävää osaamista, sitoutumista ja yhteistyökykyä. Usein tämä tarkoittaa muutoksia projektitiimissä. Lähes aina muutosten tarve on nähtävissä paljon aikaisemmin ennen kuin päätöksiä tehdään. Päätösten lykkääminen harvoin parantaa tilannetta. Luottamus palautuu vain tulosten kautta. Tee etenemisestä näkyvää ja vie toiminnallisuuksia tuotantoon nopealla syklillä.

Yhteenveto

Haastavat IT-hankkeet eivät epäonnistu sattumalta. Syyt ovat lähes aina ennakoitavissa ja usein myös vältettävissä. Syyllisten etsintä ei tee projektista valmiimpaa. Tärkeintä on keskittyä toimiin, joilla projektin suunta käännetään.

Hyvä uutinen on tämä: Suurin osa projekteista on pelastettavissa, jos ongelmiin puututaan ajoissa ja riittävän rohkeasti.

Lopulta kyse ei ole teknologiasta, vaan siitä, kuinka hyvin ihmiset tekevät yhteistyötä, kuinka selkeästi tavoitteet määritellään ja kuinka kurinalaisesti projektia johdetaan.