Opetuksia yli 30 sote-projektista: mikä todella ratkaisee onnistumisen?
Blogin on kirjoittanut vanhempi projektipäällikkö Päivi Kähönen-Anttila, jolla on yli 25 vuoden kokemus vaativien IT-, käyttöönotto- ja muutosprojektien johtamisesta sekä vahva kokemus sote-ICT-projekteista ja monitoimittajaympäristöistä.
Olen johtanut yli 30 sosiaali- ja terveydenhuollon ICT-projektia ja kerännyt järjestelmällisesti oppeja yhdessä projektitiimien kanssa. Silti tietyt ongelmat palaavat yhä uudelleen: vastuut jäävät epäselviksi, tarvittavia ihmisiä ei tunnisteta ajoissa ja puutteet huomataan vasta, kun aikataulu jo painaa päälle.
Kokosin viisi oppia, jotka ovat muuttaneet omaa tapaani johtaa projekteja, ja joiden avulla samoja virheitä voidaan välttää.
Oppi 1: ”Ei kuulu minulle” saa sanoa, mutta…
Olen törmännyt projekteissa yllättävän usein tilanteeseen, jossa asia kuuluu asiakkaalle, toimittajalle, ICT:lle, palvelulle tai jollekin toiselle tiimille. Lopulta kenellekään ei ole selvää, kuka oikeasti vastaa siitä, että asia tulee hoidetuksi.
Jokaisella kriittisellä tehtävällä pitää olla yksi nimetty omistaja. Ei viittä vastuullista tahoa. Projektissa saa sanoa ”ei kuulu minulle”, mutta jos asia ei kuulu minulle, seuraavan kysymyksen pitää olla ”Kenelle se kuuluu ja miten varmistamme, että se päätyy sinne?”
RACI ja vastuunjakotaulukot ovat hyödyllisiä, mutta taulukkoon kirjoitettu nimi ei vielä tarkoita, että vastuu olisi oikeasti sovittu. Esimerkiksi: ei riitä, että suunnitelmassa lukee ”asiakas vastaa lähtötiedoista”. Kuka asiakkaalla toimittaa ne? Mitkä lähtötiedot? Kenelle? Mihin mennessä? Ja kuka huomaa, jos niitä ei tule?
Oppi: Integraatiotesti epäonnistuu perjantaina juuri ennen käyttöönottoa. Kuka ottaa asian hoitoon? Kuka kontaktoi toimittajan? Kuka tekee päätöksen jatkamisesta? Jos tässä kohtaa alkaa hiljaisuus, vastuunjako ei ole vielä valmis.
Kuinka virhe vältetään: Emme jätä kriittisiä vastuita organisaatioiden tai tiimien nimille, vaan viemme ne riittävän konkreettiselle tasolle ja varmistamme ne vastuuhenkilöiden kanssa.
Jos omistajaa ei löydy, asia tehdään näkyväksi ja ratkaistaan oikealla tasolla. Projektipäällikön tehtävä ei ole kerätä organisaation väliin putoavia vastuita omalle työpöydälleen.
Oppi 2: Suurin riski voi olla se, joka puuttuu palaverista
Kuvittelemme projektin alussa tietävämme, ketä tarvitsemme. Sitten vastaan tulee asia, johon tarvitaan taloushallintoa, tietosuojaa, viestintää, käyttötukea, järjestelmäomistajaa tai kokonaan toista toimittajaa. Ja siinä vaiheessa ollaan usein jo kiireessä.
Sidosryhmien kartoittaminen ei ole projektin aloitustehtävä. Se jatkuu koko projektin ajan.
Esimerkiksi: Projektiin tulee muutos, jonka tekninen toteutus näyttää olevan hallinnassa. Sen sijaan että lähdetään vain toteuttamaan, pysähdytään hetkeksi: Kehen muutos vaikuttaa? Kenen pitää tietää tästä? Kenen hyväksyntää tai osaamista tarvitaan? Onko joku, joka huomaa tämän vasta käyttöönotossa?
Kuinka virhe vältetään: Kun projektiin tulee uusi muutos, päätös tai riippuvuus, kysymme samalla: Puuttuuko jokin osapuoli? Kuka?
Oppi 3 Vaarallisimpia eivät ole puuttuvat lähtötiedot
Vaarallisimpia ovat tiedot, joiden emme tiedä puuttuvan.
Projektin alussa pyydämme lähtötiedot ja teemme suunnitelman niiden perusteella. Mutta mistä tiedämme, että saimme kaikki tarvitsemamme tiedot? Emme välttämättä mistään.
Olen oppinut epäilemään lähtötietoja. Tiedän ehkä, mitä tietoa minulta puuttuu. Siksi lähtötietoja ei pitäisi koskaan kuitata projektissa sanoilla ”lähtötiedot saatu”. Lähtötietojen ongelmaa ei voi ratkaista vain pyytämällä ”kaikki tarvittavat tiedot”, koska projektin alussa emme vielä edes tiedä, mitä kaikkea emme tiedä. Tietoja täydennetään, haastetaan ja tarkistetaan sitä mukaa, kun ymmärrys projektista kasvaa.
Yhdessä suuressa hankkeessa suunnittelu aloitettiin niillä lähtötiedoilla, jotka siinä vaiheessa olivat käytettävissä. Projektin edetessä tarvittavaa tietoa tuli lisää pala kerrallaan.
Ongelma ei ollut vain puuttuva tieto. Emme alussa vielä tienneet, mitä tietoa tulisimme tarvitsemaan.
Oppi: Lähtötieto ei ole valmis siksi, että se on kerran kerätty.
Kuinka virhe vältetään: En kuittaa lähtötietoja “saaduiksi”. Pidän niitä projektin aikana tarkentuvana kokonaisuutena ja erotan toisistaan sen, minkä tiedämme, minkä oletamme ja mitä emme ole vielä pystyneet varmistamaan.
Oppi 4: Testaus ei hidasta projektia, vaan ehkäisee yllätyksiä
Projektipäällikön ei tarvitse olla testauksen tekninen asiantuntija. Hänen pitää kuitenkin varmistaa, että tiedetään mitä testataan, kuka testaa, kuka hyväksyy tulokset ja mitä jäi testaamatta.
Olen itse oppinut tämän kantapään kautta: testaamatta jäänyt asia ei katoa. Se vain siirtyy myöhemmäksi, yleensä paljon huonompaan ajankohtaan. Onnistunut testi ei ole se, jossa kaikki menee vihreäksi. Jos testauksessa löytyy ongelma ennen tuotantokäyttöä, testaus on tehnyt tehtävänsä.
Oppi: Testausta ei voi jättää projektin loppuun eikä olettaa, että kaikki voidaan testata samalla tavalla.
Kuinka virhe vältetään: Testaus käydään läpi jo suunnitteluvaiheessa: mitä testataan, kuka testaa, arvioidaan testaukseen kuluva aika, missä testataan ja miten hallitaan ne asiat, joita ei voida todentaa ennen tuotantoa.
Oppi 5: Opit eivät auta, jos toimintaa ei muuteta
Projektien päätteeksi kerätään oppeja siitä, mikä onnistui ja mikä olisi pitänyt tehdä toisin. Silti samoja asioita tulee vastaan projektista toiseen.
Projektin tärkeimmät opit pitää tunnistaa silloin, kun projekti on vielä käynnissä. Jos opit kerätään vasta projektin päättyessä, niiden hyöty jää helposti seuraavan projektin varaan. Silloin ihmiset, projektipäällikkö ja koko projektin konteksti voivat jo olla vaihtuneet.
Varaan jo projektin alkuvaiheessa, esimerkiksi kuukauden kohdalle, erillisen keskustelun sille, mikä tekemisessämme toimii ja mikä ei. Tarkoitus ei ole tehdä loppuarviointia etuajassa, vaan pysähtyä miettimään, mitä voisimme tehdä toisin projektin aikana.
Jos projekti kestää vuoden tai pitempään, pidämme toisen session, jossa kokoamme mitä olemme tehneet hyvin (positiiviset huomiot jaettaviksi) ja asiat, jotka vaativat muutosta. Havaitut asiat eivät jää opittujen asioiden listalle, vaan niille sovitaan korjaava toimenpide, vastuuhenkilö ja seuranta.
Projektien onnistuminen syntyy arjen valinnoista
Selkeät vastuut, oikeiden ihmisten osallistaminen, lähtötietojen epävarmuuden tunnistaminen, riittävä testaus ja oppien hyödyntäminen jo projektin aikana eivät yksin takaa onnistumista. Ne kuitenkin auttavat ehkäisemään ongelmia ennen kuin niistä tulee aikataulu- tai resurssikriisejä.
Yli 30 sote-ICT-projektin jälkeen tärkein oppini on tämä: Älä oleta, että asia on kunnossa siksi, että se lukee suunnitelmassa. Projektinhallinta ei ole vain suunnitelmien tekemistä, vaan jatkuvaa kysymistä, varmistamista ja toiminnan muuttamista.