Tietotekninen hanke. Helppo homma! Tilaaja määrittelee, mitä haluaa. Toimittaja tekee sitten työtä käskettyä. That’s it!
Paitsi ei tietenkään. Karkeasti ottaen – ja määritelmästä sekä lähteestä riippuen – vain kolmasosa it-hankkeista onnistuu. Niissä budjetti sekä aikataulu pitävät, ja lopputulos on tilaajan odotusten mukainen. Vastaavasti, karkeasti noin 10–15 prosenttia hankkeista epäonnistuu täysin.
Ääripäiden väliin jäävissä projekteissa on päästy maaliin, mutta ainakin yksi aspekti on piiputtanut: aikataulu tai kustannukset ovat karanneet, tai lopputulos ei ole odotusten mukainen.
”Vaikka onnistumisen ja epäonnistumisen tekijät ovat tiedossa, silti niitä toistetaan yhä uudestaan”, LUT-yliopiston professori Kari Smolander sanoo. Miksi?
”Ei ole tutkimustietoa siitä, miksi näin tapahtuu. Oma mielipiteeni on, että tietojärjestelmäkehittämisen luonne ymmärretään helposti väärin”, Smolander sanoo. Hänen mukaansa it-hankkeet mielletään usein rakennusprojektin kaltaiseksi toiminnaksi.
”Kyse on kuitenkin organisaation kehittämisestä ja sen toiminnan muuttamisesta. Tämä on merkittävästi vaikeampaa kuin fyysisen rakennuksen tekeminen”, Smolander sanoo. ”Näkisin, että teknologiaongelmat eivät ole suurin it-hankkeiden epäonnistumisen syy. Vaan pikemminkin vastuukysymykset, omistusoikeudet ja kommunikaatio epäonnistuvat tyypillisesti”, Smolander sanoo.
ONNISTUNEEN IT-HANKKEEN kaavaa on vaikea määritellä. On lukemattomia tapoja mokata se. Ja, mikä ehkä ikävintä:
”Onnistumista ei voi kopioida mutta epäonnistumisen kyllä voi”, konsultti Reino Myllymäki sanoo.
Miten vaikeaa projektissa onnistuminen sitten voi olla? Katsotaan.
TYÖ ALKAA MÄÄRITTELYISTÄ. Projektin tilaaja speksaa onnistumisen kriteerit. Mitä hankkeelta halutaan, miten kauan se saa kestää ja minkä verran maksaa. Hanke toteutetaan, ja katsotaan sitten kriteerien perusteella, miten siinä onnistuttiin.
”Tämä on yleinen tapa toimia. Mutta sen staattisuus on ongelmallista”, Smolander sanoo. Tässä mallissa oletetaan, että maailma pysyy samana kriteerientekohetkestä tuotantoon asti.
It-hankkeiden epäonnistumiset liittyvätkin Smolanderin mukaan usein siihen, että vaikka toimintaympäristö muuttuu, projekti etenee junan tavoin – niin kuin oli alun perin suunniteltu.
Fiksumpaa olisi siirtyä jatkuvan kehityksen malliin. Siinä maailma järjestyy suurien projektien sijaan päivittäiseksi kehitystyöksi. ”Projektinhallinta on tässä mallissa siten tärkeämpää kuin etukäteissuunnittelu”, Smolander sanoo.
Goforen projektipäällikkö Jari Hietaniemi on samoilla linjoilla ”Ei kannata lukittautua siihen, mitä on projektin aluksi sovittu”, hän sanoo. Tilanne kun muuttuu projektin edetessä – yleensä ensimmäisestä päivästä lähtien.
”Projektin johdon pitää jatkuvasti viestiä muutoksista nöyrästi ja läpinäkyvästi, muutettava aikatauluja ja jatkettava uudella suunnitelmalla eteenpäin”, Hietaniemi sanoo.
PROJEKTIPÄÄLLIKKÖ ON PILALLA Hietaniemen mukaan, jos hän ajattelee pitkän kokemuksensa ansiosta voivansa suunnitella projektin kertaheitolla niin, että mikään ei voi mennä vikaan.
”Höpön löpön. Sitten tulee korona, ja kaikki menee uusiksi”, Hietaniemi sanoo.
Jatkuvan, aktiivisen tilanteen seurannan nimeen vannoo myös Digi- ja väestötietoviraston kehitys- ja tietohallintojohtaja Mira Holmroos-Kolari. Hän mainitsee esimerkkinä omakohtaisesta onnistumisestaan Digi- ja väestötietoviraston käynnistämishankkeen.
Yhdistyvien virastojen olemassa oleviin järjestelmiin ja Valtorin tarjoamiin palveluihin tehtiin kahden vuoden aikana paljon muutoksia, joilla oli paljon keskinäisiä riippuvuuksia. Epäonnistumisen mahdollisuuksia oli siis ilmassa. Mutta:
”Panostimme yhteistyöhön todella paljon. Hankkeen etenemisen seuranta oli tiivistä, ja yhteistyö eri organisaatioiden ja osapuolten välillä lisääntyi hankkeen aikana”, Holmroos-Kolari sanoo. ”Harjoitus ei ollut tosiaankaan helppo, mutta onnistuimme tekemisessä. Kaikki toimi suunnitellusti alkuperäisen aikataulun mukaan.”
HAAVEET ONNISTUMISESTA voi haudata käytännössä, jos yhteinen tilannekuva ja seuranta unohtuu.
”Jos ostajan liiketoimintapuolen tuoteomistaja häipyy kuvioista puoleksi vuodeksi, teknologiatiimi jää tuuliajolle”, Jari Hietaniemi sanoo. ”Tuoteomistajalla on visio siitä, miten hanke uudistaa liiketoimintaa. Ohjelmistokehittäjät taas ovat ehkä lähtökohtaisesti insinöörejä, jotka vievät toteutusta mielellään vähempiriskiseen, tuttuun suuntaan. Jos se propellihattuinen tuoteomistaja siis ei ole läsnä vaatimassa, että tehdään jotain ennennäkemätöntä”, Hietaniemi kuvailee.
Hankkeen jämäkkä omistaja tilaajan päädyssä estää myös keisarin uudet vaatteet -tyyppisen tilanteen syntymistä. Kun omistajalla on selkeästi määritelty vastuu hankkeen kohtalosta ja erityisesti sen myötä saatavista hyödyistä, hänen mielenkiintonsa seurata tilanteen kehitystä realistisesti kasvaa kummasti.
”Ei ole lainkaan tavatonta, että projektiorganisaatiossa syntyy valheellinen konsensus. Vaikka joka ikinen näkee, että hanke ei voi onnistua, kukaan ei uskalla ottaa asiaa esille. Ikään kuin kissan pöydälle nostaneesta tulisi syypää epäonnistumiselle”, Myllymäki sanoo. Myös Hietaniemi tunnistaa tämän tilanteen.
”Usein hierarkkinen paine ja valta-asetelmat pakottavat olemaan jotain muuta kuin avoin ja rehellinen projektin tilanteesta”, Hietaniemi muotoilee. ”Voi olla suuren korporaation projektipäällikölle ammatillinen itsemurha mennä toteamaan, että projekti on kehnossa jamassa.”
Avoimen ja keskustelevan ilmapiirin syntymiseen auttaa, jos projektin osapuolet ovat toisilleen entuudestaan tuttuja – tai tutustumiseen panostetaan erityisesti hankkeen alkuvaiheessa.
”Tilaaja–toimittaja-mallissa voi tosiaan olla joskus vaikeata jakaa tilannekuvaa tiiviisti. Mutta pitkäkestoisissa kumppanuuksissa vaikeidenkin asioiden nostaminen keskusteluun ja yhteisten päätösten sekä tarvittaessa isompienkin suunnanmuutosten tekeminen on helpompaa”, Holmroos-Kolari sanoo.
TEKNOLOGIAN OSAAMISEN MERKITYSTÄ projektin onnistumiselle ei voi toki vähätellä.
”Sellainenkin muutos on meneillään, että erilaiset tietojärjestelmät liittyvät toisiinsa yhä monimutkaisemmin ja kiinteämmin. Ja tämä järjestelmäintegraatio tapahtuu yhä enemmän muualla kuin yrityksen sisällä”, LUT:n Kari Smolander sanoo.
Syntyy aivan uudenlaisia omistusoikeuksiin ja vastuisiin liittyviä ongelmia, joiden tutkimus- ja kehitystyötä tarvitaan.
”Nykyisissä kompleksisissa ympäristöissä on paljon rajapintoja ja sisäistä tietoliikennettä. Nimenomaan järjestelmien väliset integraatiot ovat usein se kompastuskivi”, Reino Myllymäki sanoo.
LUT:ssa onkin meneillään aihetta koskeva tutkimushanke, jonka ensimmäisiä tuloksia on lähiaikoina saatavilla.
Selvää on kuitenkin se, että paraskaan teknologinen osaaminen ei enää tänään riitä viemään projektia menestyksellisesti maaliin.
”It-hanke ei ole vuosikausiin ollut pelkkä it-hanke”, Myllymäki sanoo.
Vielä takavuosikymmeninä hankkeiden epäonnistumisen syynä oli hänen mukaansa tyypillisesti kyvyttömyys saada järjestelmää kasaan ja toimimaan halutusti. Nyttemmin epäonnistumisissa on taustalla yhä useammin liikkeenjohdon muutosjohtamisen puute.
”Olin erään erp-hankkeen johtoryhmässä ulkopuolisena. Toimitusjohtaja pyysi minua selvittämään, miksi yksi käyttäjäryhmä ei pidä uudesta järjestelmästä. Selvisi, että he yrittivät sovittaa uutta järjestelmää vanhaan prosessiinsa, ilman toimintatapamuutosta”, Myllymäki kertoo.
Muutosjohtamista tarvitaan alusta alkaen selvittämään ihmisille, että sekä järjestelmä että toimintatapa muuttuvat samanaikaisesti.
”Ja rauhoittelemaan, että tulette kyllä oppimaan molemmat. Ihminen on peloissaan väliaikaisen osaamattomuuden edessä. On kiva pysyä tutussa ja turvallisessa järjestelmässä, vaikka se olisi miten huono”, Myllymäki päivittelee.
YKSI TAPA TORPATA ongelmat on estää niiden syntyminen kokonaan. Vaikka sekin voi olla vaikeaa.
”Meillekin tulee tarjouspyyntöjä, joihin vastaamme, että ei kiitos, emme pysty esittämään tarjousta”, Goforen Hietaniemi sanoo. Vaatimuksissa voi olla jotain, joka ei kuulu toimittajan valikoimiin – tai tarjouspyyntö on aseteltu sellaisilla parametreilla, joihin toimittaja ei halua sitoutua.
”Tällaiset casethan eivät koskaan epäonnistu, kun niistä uskaltaa kieltäytyä jo tässä vaiheessa”, Hietaniemi sanoo.
Epäonnisia projekteja niistä tulee nopeimmin silloin, jos myyjää kiinnostaa vain päästä provikoille jättiprojektista. Hän tekee miljoonakaupat ja valuttaa hankkeen eteenpäin projektiorganisaation riesaksi. Kun mahdoton projektipommi viimein räjähtää tekijöiden käsiin, myyjä on jo vieraillut nauraen pankissa.
”Ongelmat ovat usein seurausta edellisessä vaiheessa tehdyistä virheistä tai tekemättömyyksistä. Käyttöönottovaihe kärsii huonosta toteutuksesta, toteutus huonosta suunnittelusta ja suunnittelu huonosta valmistelusta”, Myllymäki sanoo.
”On kiva pysyä tutussa ja turvallisessa järjestelmässä, vaikka se olisi miten huono.”
OLISIKO KETTERYYDESTÄ APUA? Kyllä – johonkin mittaan asti. Ketterän kehittämisen menetelmät parantavat Standish Groupin mukaan onnistumisen todennäköisyyttä vesiputousmalliin verrattuna. Kari Smolander tuumii samoin:
”Ketterät menetelmät ovat jossain määrin parempia vastaamaan muutoksiin ja muutostarpeisiin. Hanke kannattaa pilkkoa mahdollisimman pieniin yksikköihin, mikä lisää myös joustavuutta ja mahdollisuuksia seurata projektin onnistumista.”
Mikään hopealuoti ei ketteryyskään kuitenkaan ole. Projektiorganisaatio voi toimia fiksusti, vaikka ohjelmistokehityksen menetelmä noudattelisi perinteisempää vesiputousmallia.
”Tiedän, että moni sanoo, että projekti voi onnistua vain ketterää menetelmää käyttämällä. Mutta jos tavoite on kirkas koko hankkeeseen osallistuvalle kaartille, siitä pidetään kiinni ja tehdään yhteistyötä, niin kyllähän se on tärkeämpää onnistumisen kannalta kuin käytetty menetelmä”, Holmroos-Kolari sanoo.
Lopputulos ratkaisee. Digi- ja väestötietoviraston onnistuneessa käynnistyshankkeessa sovellettiin ketterää kehitystä, mutta osa osallisista käytti perinteistä kehitysmallia.
”Jos organisaatio haluaa siirtyä kokonaisketterään malliin, se ei onnistu yhden hankkeen aikana. Voi olla järkevää miettiä, mikä on oman organisaation parasta osaamista, ja keskittyä siihen”, Holmroos-Kolari sanoo.
Ja jos ollaan korvaamassa vanhaa järjestelmää uudella, jokaisen ketterän kehitysjakson jälkeen ei ole edes mahdollista tehdä todellista käyttöönottoa, Myllymäki muistuttaa. ”Vesiputousmallin ja ketterän kehittämisen välillä ei ole suurta ristiriitaa, jos projekti pidetään suppeana ja varsinkin sen pituus lyhyenä. Kukaan ei muista, mitä on speksannut kaksi vuotta sitten”, hän sanoo.
Goforen Hietaniemi muistuttaa, että ketterästikin voi mokata.
”En näkisi ketteryyttä ja vesiputousmallia janan ääripäinä. Kummassakin mallissa voidaan epäonnistua täydellisesti. Ketterässä mallissa voidaan ajaa täysin metsään, jos jatkuvan kehityksen tulokset hyväksytään löperösti ’joojoo, ihan hyvä’ -tyyliin”, Hietaniemi sanoo.
VALMISRATKAISUN HYÖDYNTÄMINEN on yksi tapa vähentää kehitystyötä ja siihen liittyviä epäonnistumisen riskejä. Siis jos sopiva sellainen markkinoilta löytyy. Holmroos-Kolari suosittelee valmiiden ratkaisujen huolellista markkinakartoitusta ennen kilpailutusta.
”Jos valmisratkaisuja halutaan käyttää, on ymmärrettävä, että ratkaisu tulee sellaisenaan, niine karvoineen. Kaikista pahin tilanne syntyy, jos valmisratkaisua lähdetään muokkaamaan räätälöidyn kehittämisen mindsetillä”, Holmroos-Kolari sanoo.
Hän neuvoo vaatimaan kilpailutuksessa toimittajilta käytännön esitystä siitä, miten valmisratkaisu tuottaa halutun toiminnallisuuden. ”Näin ratkaisun mahdolliset rajoitteet tulevat konkreettisesti ilmi, ja toimittajat joutuvat osoittamaan, että ominaisuus ylipäänsä on olemassa ja toimii.”
Valmisjärjestelmien räätälöinti on myös kompastuskivi. Valmisjärjestelmät pitäisi ottaa käyttöön mahdollisimman vähin räätälöinnein ja punnita tarkkaan, milloin toimintaa voidaan muuttaa järjestelmän standarditoiminnallisuuden mukaiseksi
PROJEKTIN LOPETTAMINEN voi olla paras – tai vähiten huono – ratkaisu, jos näyttää siltä, että lopputuloksesta ei ole tulossa toivotun kaltainen, ja realistisia korjauskeinoja ei ole olemassa.
”Miettimistauon ottaminen on parempi ratkaisu kuin edetä kenties väärään suuntaan”, Holmroos-Kolari sanoo.
”Projektin keskeyttämisen jälkeen on päätettävä, voiko projekti jatkaa, vai tarvitaanko kokonaan uusi alku”, Myllymäki sanoo.
”Jos esimerkiksi aika on yksinkertaisesti ajanut hankkeen ohi, kyllä sen voi lopettaa”, Holmroos-Kolari sanoo. Luopumisen tuska vain on melkoinen.
Projektin keskeyttämistä pelätään, koska keskeyttäminen ei ole onnistumista, vaikka keskeyttämispäätös olisikin projektin paras päätös. ”Ajatellaan, että projektia on jatkettava, koska siihen on laitettu niin paljon rahaa. Ajaudutaan tilanteeseen, jota sijoittajat kutsuvat hyvän rahan heittämiseksi huonon perään”, Myllymäki sanoo.
”On päivitettävä business case ja pohdittava, voidaanko jatkaa. Jos projektin jäljellä olevat kustannukset ovat suuremmat kuin projektin nähtävissä olevat hyödyt, projekti on keskeytettävä heti. Tämä perustuu ajatteluun, että kulutettuja rahoja on lähes mahdotonta saada takaisin, jolloin niiden arvo on nolla”, Myllymäki sanoo.
10 avainta it-hankkeen onnistumiseen
It-hankkeen onnistumista ei voi monistaa. Reino Myllymäen mukaan seuraavat tekijät kuitenkin usein yhdistävät onnistuneita projekteja.
1 Tavoite on realistinen, perusteltu ja rajattu. Taustalla on aito muutostahto ja henki on hyvä.
2 On mietitty, mistä voidaan joustaa ja mistä ei. Mikä on kilpailukyvyn kannalta tärkeää, mitä voidaan toteuttaa standarditoiminnallisuuksilla? Mitkä kaksi näistä pidetään, jos pitää tinkiä: budjetti, aikataulu vai ominaisuudet?
3 Resursointi on riittävää ja tasapainoista. Kustannusarvio on realistinen.
4 Projektiin ja sen tuloksiin liittyviä odotuksia hallitaan. Ymmärretään, ettei projekti voi ratkaista kaikkia ongelmia.
5 Projektitoiminta on läpinäkyvää. Liturgiat ja mystifioinnit on siivottu pois.
6 Lopputulosten hyödyntämiseen liittyvä muutosjohtaminen on tehty kunnolla.
7 Ymmärretään nyky- ja tavoitetilat sekä niiden välinen ero. Viestitään asioiden ymmärtämiseksi erityisesti ruohonjuuritasolla.
8 Päätöksentekomalli on selkeä. Muutospyynnöt hallitaan, päätöksiä tehdään, niitä ei jätetä pöydälle. Yhteisten päätösten takana seisotaan.
9 Ohjausryhmä mieltää roolinsa. Sen tehtävä ei ole haastaa tehtäviä ratkaisuja vaan tukea projektia ja varmistaa, että muutosjohtaminen tehdään kunnolla.
10 Kokonaisuutta hallitaan, yllätyksineen ja vastoinkäymisineen.
Miten onnistuminen määritellään?
Jos sekä tilaaja, toimittaja että loppukäyttäjät ovat it-hankkeeseen tyytyväisiä, sitä ei voi pitää epäonnistuneena.
Onnistumisen ytimessä ovat kuitenkin projektin vaikutukset tilaajan liiketoimintaan.
Hanke voi valmistua kriteerien mukaisesti – ja osoittautua käytännössä sudeksi. Tilaajan speksit voivat olla typeriä. Se voi haluta verkkokaupan, jollaista kukaan ei halua käyttää. Niinpä toimittajan olisi katkaistava peli alkuunsa, jos ostaja on tilaamassa älyttömyyksiä.
Myös ulkoiset olosuhteet voivat viedä perikatoon. Jos koronaepidemia vie liiketoiminnalta pohjan, ei valmistuvaa it-hanketta voi pitää liiketoiminnallisesti onnistuneena, vaikka kaikki olisi mennyt muuten suunnitelmien mukaan. Yksi onnistumisen kriteeri onkin, miten hyvin hanke sopeutuu ympäristön yllättäviinkin muutoksiin.
Toisaalta, vaikka aikataulu tai budjetti olisi ylittynyt tai loppukäyttäjiltä kuuluisi jupinaa, hanke on riittävän onnistunut, jos liiketoiminnan johto on siihen tyytyväinen.
Onnistunut it-projekti voi myös epäsuorasti poikia uutta liikevaihtoa, kun aikaa ei enää pala vanhan, huonon järjestelmän kanssa taistelemiseen. Liiketoiminnan johto voi keskittyä paremmin ydintekemiseensä ja pyöräyttää vaikka uuden hittituotteen markkinoille.
Kirjoita kommentti
Sinun on oltava kirjautunut sisään kirjoittaaksesi kommentin.