Kuusi tapaa välttää IT-projektin epäonnistuminen, osa 2: Aito halu auttaa asiakasta

Kirjoitin edellisessä artikkelissani siitä, kuinka onnistuneen IT-projektin edellytyksenä on avoimuus tiimin kesken ja asiakasta kohtaan. Vähintään yhtä tärkeää on kuitenkin aito halu auttaa asiakasta. Kuulostaa itsestäänselvyydeltä, mutta kokemustemme mukaan oma etu tuntuu menevän valitettavan usein asiakkaan tarpeiden edelle.

Kerron tästä omakohtaisen esimerkin.

Meillä oli edellisessä työssäni (jossa toimin siis projektissa asiakkaan roolissa) mittava kahden vuoden kehitysprojekti, johon käytettiin miljoona euroa. Projekti oli lopulta oikein onnistunut, mutta matkan varrella yhdestä osiosta vastuussa oleva toimittaja aiheutti yhteistyölle ongelmia omilla käytännöillään, jotka ajoivat vain kyseessä olevan yrityksen etuja. Toimittajalla oli siis käytäntö, jonka mukaan heiltä tulisi aina osallistua projektiin vähintään kaksi työntekijää. Kun projektin edetessä tarve ja budjetti muuttuivat niin, että työtä oli vain yhdelle kehittäjälle, toimittaja kieltäytyi joustamasta ja vetämästä toista kehittäjää pois projektista. Käytännössä siis jouduimme edelleen maksamaan kahdesta kehittäjästä, vaikka toiselle ei riittänyt hommia. 

Tässä mennään asiakastyytyväisyyden ja kestävyyden kannalta pahasti metsään, jos omista käytännöistä ei olla valmiita joustamaan. Tällainen resurssien tuhlaaminen on yksinkertaisesti järjetöntä. Edellä kuvatun kaltainen käytäntö voi toki työntekijöiden ja yrityskulttuurin kannalta olla hyödyllinen, mutta systeemin tulee olla toimiva sekä toimittajan että asiakkaan näkökulmasta, muuten toiminta ei ole kestävää.

Toinen ongelmallinen käytäntö, johon olemme törmänneet, on kieltäytyminen projektin jakamisesta muiden toimittajien kanssa. Kaikki asiakkaat eivät halua ostaa jokaista projektin osaa samalta toimittajalta, eivätkä resurssitkaan välttämättä siihen taivu. Ns. vendor lock-in muodostuu ongelmaksi, jos asiakas haluaisikin tuoda projektiin muita toimittajia, mutta projektia hallitseva toimittaja ei siihen suostu. Jos projektin jakaminen useamman toimittajan kanssa on asiakkaan etujen mukaista, yhteistyön tekemisen ei pitäisi olla ongelma. Vendor lock-in -riskin välttämiseksi tiettyjä avainrooleja ei edes kannattaisi antaa konsulttien hoidettavaksi, vaan ohjat tulisi pitää yrityksen omissa käsissä.

Projektin onnistumisen, asiakastyytyväisyyden sekä ohjelmistokehityksen kestävyyden varmistamiseksi toimittajilla on oltava aitoa halua laittaa asiakkaan tarpeet ja toiveet etusijalle ja valmiutta joustaa sen mukaan, mikä on projektin kannalta järkevintä. Vaikka kaikki päätökset eivät olisikaan juuri sillä hetkellä meille toimittajana kaikista kannattavimpia, on asiakkaan asettaminen etusijalle ollut kokemustemme mukaan pitkällä tähtäimellä palkitsevaa ja osaltaan auttanut Compilea kasvamaan.

Seuraavassa blogikirjoituksessa lisää keskustelua onnistumisen edellytyksistä, kulmana osaavat tiimin jäsenet.

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.