keskiviikko, 26.1.2022
Laita nämä seikat kuntoon – Onnistuneen IT-projektin edellytykset
Aikataulu laahaa perässä. Budjetti on poltettu loppuun jo puolimatkassa. Maaliin päästään vasta reklamoinnin jälkeen. Lopputulos on jotain ihan muuta kuin mitä tavoiteltiin. Todennäköisesti kaikki tietävät tai ovat vähintään kuulleet epäonnistuneista IT-hankkeista.
Miksi epäonniset hankkeet ovat niin yleisiä? Olen työskennellyt tähän päivään mennessä Biitillä konsulttina erilaisten projektien parissa jo rapiat viisi vuotta. Olen siis nähnyt kaikenlaisia projekteja, oppinut matkan varrella paljon ja oppinut samalla keskittymään olennaisimpiin asioihin.
Käyn tässä tekstissä kokemusteni pohjalta ja käytännön esimerkkien kautta läpi keinoja välttyä epäonnistumisilta. Esittelen samalla viisi aihealuetta, joihin kannattaa ehdottomasti kiinnittää huomiota kaikissa teknologiaan liittyvissä projekteissa.
1) Vision kirkastaminen
Aloitetaan kaikkein ilmeisimmästä asiasta, eli visiosta. On ehdottoman tärkeää, että jokaisella projektilla on jokin selkeä visio.
Yksinkertaisuudessaan visio kertoo, miksi projektia tehdään ja mitä sillä pyritään saavuttamaan. Onnistuneesti rakennettu visio määrittää ylätasolla yhteisen käsityksen siitä, mikä projektin lopputulos (IT-hankkeissa siis yleensä jokin työkalu) tulee olemaan.
Visio myös auttaa projektin vastuuhenkilöitä tekemään oikeansuuntaisia päätöksiä projektin aikana siitä, mitä toimintoja ja ominaisuuksia työkaluun kehitetään ja mitä jätetään kehittämättä.
Voimme ajatella, että visio on kuin matkan määränpää. Se auttaa etenemään oikeaan suuntaan silloinkin, kun tekisi mieli poiketa reitiltä.
”Houkutus poiketa suunnitelmista on suuri. Näissä tilanteissa kirkkaan vision merkitys korostuu.”
Salesforce-projekteissa nimittäin käy toisinaan niin, että asiakas havahtuu jossain vaiheessa siihen, kuinka paljon Salesforce-alustalla voisi saada aikaan. Tällöin houkutus poiketa suunnitelmista on suuri. Näissä tilanteissa kirkkaan vision merkitys korostuu.
Vision määrittämisen jälkeen projektitiimin vastuulle jää toteuttamistavasta päättäminen. Visio siis ohjaa oikeaan suuntaan, mutta ei kuitenkaan kahlitse tekemään asioita tietyllä ennalta sovitulla tavalla.
Ilman visiota projektilta puuttuu selkeä tavoite. Tämä johtaa usein siihen, että projektin aikana tehdään päämäärättömästi kaikenlaista ja lopputuloksena saadaan sillisalaattia.
Tavoitteena on siis, että kaikki ymmärtävät ja hyväksyvät suunnan, jota kohti pyritään. On hyvä pitää mielessä, että samassa organisaatiossa esimerkiksi myyntiorganisaatio voi nähdät asiat hyvin eri tavalla kuin IT-osasto. Nämä osastot nimittäin saattavat tarkastella asioita hyvinkin erilaisesta näkövinkkelistä. Myös saman osaston sisällä voi olla erilaisia näkemyksiä siitä, mihin pitäisi pyrkiä.
2) Liiketoimintaprosessien määritteleminen
Valitettavan usein projekteissa lähdetään liikkeelle tietotekniset toiminnallisuudet tai ominaisuudet edellä. Tätä ennen tulisi kuitenkin määritellä yrityksen liiketoimintaprosessit, joita valitun ratkaisun tulisi tukea.
Liiketoiminnan prosessien pitäisi siis ohjata ratkaisuja, eikä toisin päin.
Mikäli liiketoiminnan prosesseja ei ole määritelty, on projektin lopputuloksena usein ratkaisu, joka ei palvele loppukäyttäjien todellisia tarpeita. Pahimmassa tapauksessa ratkaisu saattaa jopa hidastaa tai haitata työntekoa.
Myyntimaailmassa puhutaan esimerkiksi toisinaan perjantaitalkoista eli kokonaisista työpäivistä, jotka pitää käyttää tietojen syöttämiseen järjestelmään. Se on seurausta järjestelmästä, jota ei ole toteutettu oikein.
Tarvitaan siis sellainen ratkaisu, joka pystyy mukautumaan liiketoiminnan eri prosesseihin. Asioita olisi myös syytä miettiä riittävän pitkäjänteisesti, sillä yrityksen prosessit saattavat muuttua ajan myötä. Tällöin myös järjestelmien ja työkalujen pitäisi pystyä mukautumaan näihin muutoksiin.
”Asioita olisi myös syytä miettiä riittävän pitkäjänteisesti, sillä yrityksen prosessit saattavat muuttua ajan myötä.”
En voi tässä kohtaa olla mainostamatta hieman Salesforcea, sillä yksi sen suurimmista vahvuuksista on nimenomaan sen mukautuvuus ja skaalautuvuus. Se on alusta, joka on suunniteltu kasvamaan ja kehittymään liiketoiminnan mukana. Kun liiketoiminnan prosessit muuttuvat, yritys kasvaa tai uusia työkalun tarpeita ilmenee, ei edessä ole uusi suuri IT-hanke, vaan yksinkertaisimmillaan vain muutama hiiren napsautus.
Me Biitillä puhumme paljon datalla johtamisesta, mikä tarkoittaa päätösten pohjautumista mutun sijaan dataan. Jotta pystyt johtamaan käytännön tekemistä datalla, niin työntekijöidesi pitäisi noudattaa suurin piirtein samanlaisia prosesseja. Mikäli työn käytäntöjä määrittävät prosessit puuttuvat, niin ne on määriteltävä projektin alkuvaiheessa. Tämä on usein erinomainen harjoitus yrityksille, sillä se auttaa kehittämään toimintaa järjestelmällisemmäksi.
Esimerkiksi markkinoinnin automaatioon keskittyvässä projektissa voitaisiin lähteä liikkeelle markkinoinnin prosessien määrittelystä. Minkälaisin keinoin vaikkapa verkkosivuvierailijasta jalostetaan ostava asiakas? Kuinka potentiaalinen asiakas lämmitetään siihen pisteeseen, että markkinointi voi tehdä hänestä liidin myynnille? Kuinka tämä handover hoidetaan?
Tällaisessa projektissa tekniseen toteutukseen syvennytään vasta sitten, kun nämä markkinoinnin prosessit on saatu määriteltyä ja kirkastettua.
Toinen varsin tyypillinen esimerkki, johon CRM-järjestelmien maailmassa törmää usein, liittyy myyntiprosesseihin. Monien CRM-järjestelmien helmasynti on se, että ne tukevat lähtökohtaisesti vain yhdenlaista myyntiprosessia – usein geneeristä uusmyynnin suppiloa. Se ei sellaisenaan taivu kaikkiin myynnin tarpeisiin, joten lopputuloksena on valitettavan usein työkalu, joka ei tue myyjiä tai myynnin johtoa heidän tärkeimmissä myyntitilanteissa.
3) Projektin toimintamallin valitseminen
Projektin toimintamalli on kriittinen osa kaikkia projekteja, sillä se määrittää projektitiimin päivittäisen tekemisen mallin. Voisin kirjoittaa projektien toimintamalleista loputtomiin, mutta tiivistän mielestäni tärkeimmät näkökulmat aiheesta.
Aloitetaan tärkeimmästä: ketterät toimintamallit ovat nykyaikaa. Suosittelen näihin toimintamalleihin perehtymistä kaikille yrityksille ja IT-projektien osallistujille, mikäli ne eivät vielä ole tuttuja.
Me Biitillä pyrimme ensisijaisesti toteuttamaan projektit ketterän ohjelmistokehityksen periaatteiden mukaisesti.
Haluatko oppia lisää ketterästä kehityksestä? Lataa aiheesta kirjoittamamme opas ”Salesforcea. Ketterästi.”
Ketterän ohjelmistokehityksen mallissa projekti toimitetaan pala kerrallaan, jotta eniten arvoa tuottavat kokonaisuudet saadaan varmasti valmiiksi sekä samalla ensimmäiset iteraatiot saadaan käyttöön mahdollisimman ripeästi.
Ketterä toimintamalli mahdollistaa myös mukautumisen jos ja kun alkuperäiseen projektisuunnitelmaan tulee muutoksia sekä mahdollisuuden hyödyntää kaikkea matkan varrella opittua.
Ketterän toimintamallin etuna on myös nopea palautteen saanti loppukäyttäjiltä, kun he pääsevät testaamaan työkalua jo mahdollisimman aikaisessa vaiheessa projektia. Tämä mahdollistaa korjaavien toimenpiteiden teon sekä tekemisen optimoinnin projektin aikana.
Mikäli loppukäyttäjät päästetään testaamaan ja antamaan toteutuksesta palautetta vasta projektin loppuvaiheessa, kun projektin aika ja budjetti on jo käytetty loppuun, on riski projektin epäonnistumiselle kohtuuttoman suuri.
Ketteriä toimintamalleja on varsin paljon. Muutamina niminä voisin pudottaa Kanbanin ja Scrumin. Arvioi aina projektikohtaisesti, mikä metodologia ja lähestymistapa sopisi projektiin parhaiten. Projektin toimintamallin tulisi myös sisältää toteutukseen liittyvät käytännöt, kuten palaveri- ja kommunikaatiotavat ja dokumentoinnin. Etenkin hyvän, avoimen ja tehokkaan kommunikaation merkitystä en voi tässä kohtaa korostaa tarpeeksi.
Tärkeintä on, että projektille ylipäätään valitaan jokin yhteinen toimintamalli. Ilman sitä projekti ajautuu nopeasti melkoiseksi häröilyksi.
Olen ollut mukana monissa projekteissa, joissa ratkaisusta on tehty ketterästi uusia iteraatioita parin viikon välein. Olemme saaneet näissä projekteissa asiakkaan puolelta loppukäyttäjiltä jokaisen iteraation kohdalla palautetta sekä usein uusia ideoita, joita asiakkaan varsinainen projektitiimikään ei ollut aiemmin hoksannut.
Kun olemme näissä projekteissa sitten lähteneet hyödyntämään loppukäyttäjien ideoita, olemme pystyneet tekemään ratkaisuista niin hyviä, ettei näiden projektien päätyttyä ole enää ollut tarvetta tehdä ratkaisuun mitään korjaus- tai muutostöitä.
4) Projektitiimin kasaaminen
Jääkiekkotermejä lainaten: kun tavoitteet, pelisuunnitelmat sekä ylivoimakuviot ovat kunnossa, tarvitaan enää kaukaloon oikeat pelaajat.
On ensisijaisen tärkeää, että projektitiimiin saadaan kasattua oikeat henkilöt oikeisiin rooleihin. Onnistunut IT-projekti tarvitsee luonnollisesti osaavat asiantuntijat ratkaisun kehittämiseen sekä projektin vetämiseen. Pelkkä konsulttifirma tai yrityksen oma IT-osasto ei voi tätä kokonaisuutta saada yksin toimimaan.
Tämän lisäksi projektiin tarvitaan myös loppukäyttäjiä eli liiketoiminnan asiantuntijoita. Esimerkiksi myynnin työkalua kehittäessä projektiin tarvitaan sekä myyjiä että myynnin johtoa. Ratkaisun pitää pystyä palvelemaan heitä kaikkia – ei ainoastaan myynnin johtoa tai yksittäistä myyjää.
Usein projektiimiin saattaa kuulua myös asiantuntijoita muilta osastoilta, kuten esimerkiksi markkinoinnin tai IT:n puolelta.
Oikean kokoonpanon lisäksi tulee varmistaa, että kaikilla projektiin osallistuvilla henkilöillä on riittävästi aikaa suoriutua projektivelvoitteistaan. Esimerkiksi palavereille, testaamiselle sekä liiketoiminnan prosessien ja tarpeiden validoinnille tulee löytyä riittävästi aikaa.
”Projektihenkilöillä tulee olla riittävän osaamisen lisäksi valtuudet tehdä päätöksiä.”
Projektiin osallistuvien henkilöiden pitää myös olla motivoituneita ja sitoutuneita projektiin ja sen tavoitteisiin. Ja viimeisenä muttei vähäisimpänä: projektihenkilöillä tulee olla riittävän osaamisen lisäksi valtuudet tehdä päätöksiä. Sujuvan projektityön edellytys on, ettei jokaisen kysymyksen kohdalla jouduta kyselemään mielipidettä tai päätöstä ylempää ja jäädä sitten odottelemaan vastauksia viikkokausiksi.
5) Muutosjohtaminen (ja muutoksen jalkauttaminen)
Viimeisenä seikkana mainitsen vielä muutosjohtamisen. Usein IT-maailmassa projektin ajatellaan päättyvän pilkulleen siihen, kun uusi järjestelmä otetaan käyttöön. Monesti muutoksen johtaminen valitettavasti loistaa poissaolollaan.
Ajatellaanpa elämää yleisesti ottaen hetken aikaa. Tiedät varmaan omasta lähipiiristäsi, kuinka eri tavoin ihmiset suhtautuvat muutoksiin. Joku innostuu uusista asioista aina aluksi, mutta kyllästyy nopeasti. Joku toinen pelkää kaikenlaisia muutoksia ja haluaa asioiden säilyvän ennallaan. Kolmas vastustaa periaatteesta kaikkea uutta. Projektimaailmassa törmää tähän samaan ilmiöön.
Muutosjohtamisen tavoitteena on varmistaa, että uudet toimintamallit todella omaksutaan sekä uudet työkalut otetaan käyttöön onnistuneesti. Tehokkaimmillaan muutosjohtaminen on silloin, kun se aloitetaan jo projektin aikana.
Tavoitteena on siis välttyä siltä ikävältä tilanteelta, että sinänsä onnistuneen projektin hyödyt jäävät saavuttamatta, koska alkuinnostuksen jälkeen ihmiset eivät muuttaneetkaan toiminnassaan mitään tai eivät ottaneet uusia työkaluja arkiseen käyttöön.
Käytännön tekemisen tasolla tämä voi tarkoittaa esimerkiksi työkalun julkaisua porrastetusti eri osastoille tai käyttäjäryhmille, uuden työkalun ja prosessien koulutusta henkilöstölle, työkalun käytön tukemista tai hyötyjen todentamista esimerkiksi liiketoiminnan tuloksia mittaamalla.
”Tärkeintä on jo projektiin lähtiessä hyväksyä, ettei projekti pääty minään tiettynä päivämääränä tai kellonlyömällä.”
Tärkeintä on jo projektiin lähtiessä hyväksyä, ettei projekti pääty minään tiettynä päivämääränä tai kellonlyömällä kuin seinään.
Kerron tähän loppuun yhden esimerkin onnistuneesta muutosjohtamisesta. Se alkoi jo itse asiassa projektin alkumetreillä.
Olin mukana eräässä projektissa, jossa asiakkaan puolelta valiteltiin sitä, että useat aikaisemmat projektit olivat edenneet hitaasti työntekijöiden muutosvastarinnan vuoksi. Tällä kertaa päätimme yhdessä asiakkaan kanssa ottaa mukaan jo aikaisessa vaiheessa innokkaimpien ihmisten lisäksi myös äänekkäimpiä vastustajia.
Myös asiakasyrityksen muu henkilöstö sitoutettiin projektiin keräämällä heiltä palautetta säännöllisesti sekä huomioimalla olennaisimmat esille nousseet seikat.
Muutos henkilöstön asenneilmapiirissä oli merkittävä. Kun projektiin otettiin mukaan mahdollisimman kirjava joukko työntekijöitä, niin projektille saatiin aiempia projekteja laajempi hyväksyntä jo alkuvaiheessa. Monista muutokseen epäilevästi suhtautuneista tyypeistä tulikin projektin tärkeimpiä puolestapuhujia.
Tällaisella osallistavalla lähestymistavalla koko projekti saatiin vietyä onnistuneesti maaliin. Samalla uudet toimintatavat saatiin jalkautettua nopeasti koko organisaatioon, sillä projektiin osallistuneet henkilöt olivat erittäin innokkaita opettamaan kollegoilleen uusia tehokkaampia työskentelytapoja.
