Kuusi tapaa välttää IT-projektin epäonnistuminen

Tivin loppukesästä julkaisema juttu Compilen kestävän ohjelmistokehityksen lähestymistavasta herätti kovasti kiinnostusta, minkä vuoksi ajattelin jakaa ajatuksiani siitä, mitkä tekijät meidän kokemustemme mukaan mahdollistavat onnistuneet IT-projektit. Tarpeeksi kauan kun näitä hommia tekee, alkaa näkemään toistuvia samankaltaisuuksia sekä onnistuneiden että epäonnistuneiden hankkeiden yhteydessä. 

IT-projektin onnistumiseen liittyy mielestäni erityisen vahvasti kuusi asiaa, joista jokaisesta tulen julkaisemaan oman lyhyen kirjoituksensa omakohtaisen tarinan kera. 

Onnistumisen edellytyksenä on, että

  1. ollaan avoimia eikä piilotella ongelmia
  2. halutaan oikeasti auttaa asiakasta
  3. tiimin jäsenet ovat oikeasti osaavia (ja haluavat miettiä esim. teknologioiden ja arkkitehtuurin kestävyyttä jatkokehityksen kannalta)
  4. osaamisen jatkuvaan kehittämiseen käytetään aikaa
  5. ollaan realistisia etenemisvauhdin kanssa (ei yli- eikä alimyyntiä)
  6. organisaation jäsenet tukevat toisiaan hankalissa tilanteissa eikä ketään jätetä ongelmien kanssa yksin.


Osa 1: Avoimuus ja ongelmista puhuminen

Aloitetaan ensimmäisestä kohdasta, eli ongelmien piilottelusta ja avoimuuden tärkeydestä. Siihen liittyen mieleeni palaa erityisen vahvasti eräs ikävä, mutta opettavainen kokemus muutaman vuoden takaa aikaisemmasta työstäni, jossa toimin asiakkaan roolissa konsulttiavun tilaajana. 

Palkkasimme projektiin kyvykkäältä vaikuttavan tiimin, jonka tehtävänä oli implementoida useaan tietolähteeseen perustuva ja dataa eteenpäin jalostava talousraportointijärjestelmä. Muutaman kuukauden kuluttua aloimme epäillä projektin etenemistä, mutta tiimi vakuutti kaiken olevan kunnossa ja projektin etenevän alkuperäisen aikataulun mukaisesti. Luotimme tiimin sanaan ja annoimme työskentelyn jatkua. Neljä kuukautta tilannetta seurattuani minun oli kuitenkin pakko puuttua tilanteeseen, sillä koodi oli täysin toimimatonta ja auttamattoman huonolaatuista: järjestelmä ei hakenut oikeaa dataa, rakenne oli epälooginen ja virheiden korjaaminen aiheutti vain lisää virheitä. Jos tiimi tai sen toimittaja olisi hyvissä ajoin myöntänyt, että heillä oli kehitystyössä ongelmia, olisimme voineet auttaa heitä. Jouduimme kuitenkin vaihtamaan toimittajaa, ja uuden tiimin piti luonnollisesti aloittaa projekti alusta, joten menetimme yhteensä kymmenen kuukautta arvokasta aikaa vain koska tämä toimija ei kehdannut, halunnut tai ymmärtänyt myöntää ongelmaa. 

Kuulostaako tutulta? Tämänkaltaisia tarinoita, joissa asiakkaalle ei uskalleta kertoa ongelmista, on valitettavasti lukemattomia. Ongelman laajuudesta kertoo hyvin erään nykyisen asiakkaamme kommentti, kun hiljattain totesimme projektin myöhästyvän kuukaudella. Asiakas kiitti meitä avoimuudesta ja totesi tämän olevan ensimmäinen kerta koskaan, kun toimittaja kertoo omatoimisesti projektin olevan myöhässä alkuperäisestä aikataulusta.

Läpinäkyvyys, luottamus ja toiminnan kestävyyteen pyrkiminen ovat arvoja, jotka moni allekirjoittaa, mutta ei käytännössä kuitenkaan toteuta. Uskotaan pystyvämme ratkaisemaan asiat itse, eikä ylpeys ehkä anna periksi pyytääksemme apua. Tällaiset tilanteet kuitenkin lisäävät huomattavasti kaikkien osapuolten tarpeetonta stressiä, eikä tieto siitä, ettei asetettuihin tavoitteisiin tulla pääsemään, ainakaan lisää kehittäjien motivaatiota. Kuukausia venynyt projekti tarkoittaa tottakai myös hurjaa määrää hukkaan heitettyjä taloudellisia resursseja. 

Tässä erityisen tärkeäksi muodostuu luottamukseen ja avoimuuteen perustuva yrityskulttuuri. Tuetaan toinen toisiamme ja pyritään ratkaisemaan ongelmat yhdessä, kun omat voimat eivät siihen yksin riitä. Mitä aikaisemmin orastavista haasteista puhuu (niin tiimin sisällä kuin asiakkaan kanssa), sen nopeammin niihin voidaan puuttua ja estää ongelman paisuminen. Sitä kautta voidaan parantaa koodin laatua, vähentää regressiota ja nopeuttaa tuotantoa, eli edistää muun muassa inhimillistä ja taloudellista kestävyyttä.

Seuraavaksi lisää kakkoskohdasta, eli aidosta halusta auttaa asiakasta. Mitkä asiat ovat sinun mielestäsi edellytyksenä onnistuneelle IT-projektille?

Seuraa meitä Linkedinissä niin tiedät aina, mitkä ovat ohjelmistokehityksen toimivimmat käytännöt juuri nyt.

Tuntuuko, että...

 …teidän softakehitystiimissä sekä palautteen antaminen että vastaanottaminen on vaikeaa?

Tilaa ilmainen miniopas tilanteen ratkaisemiseksi tästä:

    Kun tilaat oppaan, liityt samalla uutiskirjeemme tilaajaksi, ja saat lisää inhimillisen johtamisen vinkkejä. Voit poistua listalta koska vain.

    eNPS-mittaus perustuu Fred Reichheldin kehittämään Net Promoter Score -mittariin, jolla alunperin tutkittiin yritysten asiakaskokemusta ja asiakastyytyväisyyttä. Myöhemmin sitä on alettu käyttää myös työntekijätyytyväisyyden tutkimiseen (e niin kuin employee + NPS).

    Näin mittaus tehdään.

    Kysymme työntekijöiltämme kerran kertaa vuodessa, että “kuinka todennäköisesti suosittelisit työpaikkaasi ystäville tai tutuille asteikolla 0-10?”. Sen jälkeen pyydämme tarkennusta avoimella kysymyksellä: ”mistä syystä annoit tämän tuloksen?”.

    Niitä, jotka antavat luvuksi 9 tai 10, kutsutaan suosittelijoiksi. Niitä, jotka antavat luvuksi 0-6, kutsutaan kriitikoiksi.

    eNPS-tulos lasketaan vähentämällä suosittelijoiden suhteellisesta prosenttiosuudesta kriitikoiden suhteellinen prosenttiosuus. Muut vastaukset saavat arvon 0.

    Mittarin tulokset voivat olla mitä vain -100 ja +100 väliltä. Yli nollan nousevat tulokset ovat tyydyttäviä. +10 ja +30 välillä olevia tuloksia pidetään hyvänä, ja yli +50 olevia tuloksia pidetään erinomaisena.