Kuusi tapaa välttää IT-projektin epäonnistuminen, osa 6: Organisaation jäsenten tuki

Olen julkaissut blogissamme artikkelisarjaa aiheesta IT-projektin onnistumisen edellytykset, ja jäljellä on enää yksi meidän kokemuksemme mukaan erittäin tärkeä osa-alue. Aiemmat artikkelit käsittelivät avoimuuden tärkeyttä, aitoa halua auttaa asiakasta, kovaa ja syvää osaamista, osaamisen kehittämiseen käytettävää aikaa sekä realistisuutta etenemisvauhdin suhteen. Luonnollisena jatkeena tälle ihmislähtöisyyttä ohjelmistokonsultoinnissa korostavalle listalle pureudutaan vielä organisaation jäsenten toisilleen tarjoamaan tukeen.

Kuten aiemminkin olen todennut, inhimillinen kestävyys luo perustan kestävän ohjelmistokehityksen toteuttamiselle. Meidän tavoitteemme Compilella on pitää asiakastyytyväisyytemme korkealla, ja se onnistuu vain, jos työntekijämme ovat tyytyväisiä. Työntekijöidemme tyytyväisyyden ja hyvinvoinnin pyrimme takaamaan kolmella tavalla: osaamisen jatkuvalla kehittämisellä, työstä maksettavalla reilulla korvauksella sekä yksilöä tukevalla yrityskulttuurilla. Näistä kahdesta ensimmäisestä kirjoitinkin jo aiemmin, mutta avataan vielä tuota kolmatta osa-aluetta konkreettisen esimerkin avulla.

Meiltä aloitti kaksi kehittäjää erään uuden asiakkaan projektissa, johon tiimi oli koostettu useamman eri konsulttiyrityksen konsulteista. Kaikki vaikutti alkuun hyvältä, mutta muutamien viikkojen jälkeen huolestumisen tunne alkoi kasvaa. Projekti oli hyvästä tekemisen meiningistä huolimatta sekava eikä tiimi pelannut yhteen, vaan tiimin sisälle oli syntynyt “mikrotiimejä”, joista kukin teki asiat itselleen parhaimmaksi katsomallaan tavalla. Aikataulut sakkasivat, mutta kukaan ei oikein nostanut epäkohtia esille. 

Sen sijaan, että olisimme taputtaneet konsulttejamme selkään ja sanoneet, että kyllä se siitä, pyysimme heidät toimistollemme sisäiseen palaveriin, jossa koko projekti käytiin omalla porukalla läpi. Tuon muutaman tunnin aikana muodostimme omasta mielestämme realistisen näkymän siitä, mitä projektissa voi oikeasti saavuttaa. Kun olimme luoneet suunnitelman, johon totesimme pystyvämme sitoutumaan, mietimme, miten eri sidosryhmille kannattaisi tilanteesta viestiä. Päädyimme siihen, että konsulttimme kävivät löydökset läpi tiiminsä kanssa ja asiakkuuspäällikkömme nosti asian esille ensimmäisessä ohjausryhmätapaamisessa. Asiakas otti asian vakavasti ja ryhtyi välittömästi pohtimaan, kuinka tilanne saataisiin korjattua. Lisäksi he kiittivät meitä kissan nostamisesta pöydälle ja tekivät konkreettisia toimia tarvittavilla tasoilla kurssin kääntämiseksi. 

Helpoin ratkaisu siinä hetkessä olisi tietysti ollut vain konsulttiemme tsemppaaminen tai heidän vetämisensä pois projektista hankalan arjen iskiessä, mutta se ei olisi loppujen lopuksi auttanut ketään. Kaveria eikä sen puoleen asiakastakaan jätetä, vaan tehtävämme on tukea toisiamme yhteisen menestyksen ja hyvinvoinnin takaamiseksi. Konsultit ovat usein aika yksin asiakkaalla, ja meille 1-3 kuukauden välein pidettävät ohjausryhmätapaamiset ovat toimineet erinomaisena tapana olla apuna projekteissa ja varmistaa niin konsulttiemme kuin asiakkaan tyytyväisyys. Myös konsulttien toisilleen tarjoama tuki on äärettömän arvokasta, ja sitä pystytään tukemaan hyvin erilaisten formaalien ja vähemmän formaalien tapaamisten muodossa sekä Slackin välityksellä. 

Monesti tuntuu, että etenkin isommissa yrityksissä unohdetaan ohjelmistokehityksen olevan 100%:sti ihmisala. Tämän kun pitäisimme kaikki mielessä, muistaisimme puhua asioista avoimesti ja ajoissa sekä tukea ja auttaa toisiamme, meidän ei tarvitsisi jatkuvasti lukea epäonnistuneisiin IT-projekteihin viittaavia otsikoita.

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.