Julkisten IT-hankkeiden epäonnistumiset päätyvät yhä 2020-luvulla otsikoihin. Mediassa kerrotaan kaatuvista hankkeista ja kriittisistä julkishallinnon järjestelmistä, jotka viivästyvät tai kärsivät vakavista laatuongelmista.
Olen seurannut alan kehitystä läheltä yli kymmenen vuotta. On huolestuttavaa nähdä, kuinka uusia IT-järjestelmiä edelleen kilpailutetaan samoilla tarjouspyynnöillä ja johdetaan samalla tavalla kuin projekteja, jotka jo aiemmin menivät pieleen. Tämä on erityisen murheellista talouden myrskyissä, kun epäonnistuviin investointeihin ei olisi varaa.
Tämä ei kuitenkaan ole koko totuus julkisista IT-hankinnoista. Viimeisen kymmenen vuoden aikana julkishallinnon IT-projektit ovat kehittyneet merkittävästi. Viranomaisten digiosaaminen on kasvanut, ja julkishallinnossa on kehitetty satoja palveluita onnistuneesti. Suuri yleisö ei näistä kokemuksista useinkaan kuule – on vaikea keksiä vetävää lehtiotsikkoa projektista, joka valmistui ajallaan ja jonka lopputuloksena syntyi järjestelmä, jota virkamiehet tai kansalaiset käyttävät tyytyväisinä.
Hankintalaki ei onneksi ole este ketterälle, onnistuvalle projektille. Onnistuminen ei ole sattumaa eikä salatiedettä, vaan näitä hankkeita yhdistää kerrasta toiseen kuusi asiaa.
Kokosimme tähän artikkeliin oppimme ja havaintomme julkisten projektien onnistumisista viimeisen 10 vuoden ajalta. Mitkä ovat kolme tärkeintä tekijää onnistuneen projektin kilpailutuksessa? Entä mitkä ovat kolme keskeisintä asiaa, kun hanketta johdetaan ja organisoidaan?
Kolme tärkeintä asiaa hankintavaiheessa
1. Projektin sopimus on joustava
Sopimukset eivät luontaisesti ole asia, joka sytyttää ihmisissä sisäisen liekin (ellei lasketa lakimiehiä – heille laatikollinen sopimusdokumentteja tietysti on kuin pallomeri). Julkisen IT-projektin kannalta sopimukset ja tarjouspyyntödokumentit ovat kuitenkin niin tärkeä asia, että niiden sisällöstä kannattaa kiinnostua. Sopimus on kohtalokas dokumentti, jonka kanssa asiakas joutuu elämään vuosia eteenpäin, sillä hankintalaki ei salli sopimusten merkittävää muuttamista myöhemmin.
Oikeustieteellisen tiedekunnan saleissa on perinteisesti julistettu, että toimitussopimuksessa tulisi määritellä tarkasti IT-järjestelmän vaatimukset, aikataulut ja työmäärät. Modernin IT-ostajan hankintajuristi ymmärtää kuitenkin, että tämä lähestymistapa ei sovi yhteen ketterän ohjelmistokehityksen kanssa. Sen sijaan, että lukitaan lopputulos, on parempi ostaa osaava tiimi. Kun ammattilaiset luovat uniikkia ohjelmistoa ja työskentelevät ainutkertaisessa projektissa, kaikkea ei voida mitenkään tietää etukäteen.
Julkisessa hankinnassa sopimus ja tarjouspyyntö kannattaa jättää joustaviksi, jotta tiimi ja asiakas voivat ratkaista kysymyksiä ja tehdä päätöksiä projektin aikana. On huolestuttavaa, jos tekemisen sisältöä eivät määritä kokeneet ohjelmistokehityksen ammattilaiset vaan sopimus, jonka liian innokas lakiosasto on ennen projektia kirjaillut. Joustamattomuus turhauttaa myös asiakasta, joka kehitettävän digipalvelun omistaa.
2. Asiakkaan ja tiimin välille rakentuu vahva luottamus – ei pakkoavioliittoa
Sami Kuronen puhuu Temptation Island -ohjelmassa luottamuksesta ja yhteisestä tulevaisuudesta lahtelaisille pariskunnille, mutta samat opit soveltuisivat myös IT-projekteja koskeviin seminaareihin. Ohjelmistoprojektit perustuvat lopulta luottamukseen.
Ihanteellista on, jos asiakas voi arvioida yhteistyötä ja toimittajan osaamista jo tarjousvaiheessa. Pelkkien tarjousdokumenttien lisäksi valveutunut ostaja yleensä haastattelee tiimin. Hyvä ostaja kiinnittää huomiota paitsi tekniseen osaamiseen myös tiimin dynamiikkaan, ongelmanratkaisukykyyn, innostukseen ja kykyyn kommunikoida asiakkaan kanssa.
On tärkeää huolehtia siitä, ettei asiakkaan ja toimittajan välille synny pakkoavioliittoa. Jos asiakas menettää luottamuksensa, parasta, mitä voi tapahtua, on päästä toimittajasta nopeasti eroon. Pakkoavioliitto voi syntyä, jos asiakas on sidottu tiettyihin tilausmääriin tai pitkiin irtisanomisaikoihin tai jos toimittajalla on yksinoikeus muokata koodia.
3. Asiakas painottaa laatua tarjousten arvioinnissa ja onnistuu saamaan kovimman tiimin
IT-järjestelmän onnistuminen riippuu viime kädessä siitä, kuinka taitavat ja motivoituneet ihmiset projektia tekevät. Piste. Hyvä kehittäjä ei ole vain teknisesti taitava, vaan ymmärtää myös asiakkaan liiketoimintaa ja käyttäjiä, osaa luovia asiakasorganisaatiossa ja viestii hyvin.
Tarjousten vertailussa painotuksina voi käyttää esimerkiksi 80 % laatua ja 20 % asiantuntijan tuntihintaa. Tuntihinnan sijaan kannattaa painottaa kokonaistaloudellista edullisuutta. Projekti tulee lopulta kalliiksi, jos eteneminen jumittuu tai järjestelmä kärsii vakavista laatuongelmista. Lisäksi väärät tekniset ratkaisut voivat pahimmillaan kaataa koko hankkeen.
Laatuvertailussa pelkkä CV-papereiden tuijottaminen ei kerro asiantuntijoiden osaamisesta riittävästi. Sen sijaan tiimille kannattaa järjestää haastattelu tai jopa koodauskoe. Surullisinta on, jos asiakas haluaisi painottaa laatua, mutta päätyykin lähinnä vertailemaan asiantuntijoiden CV:itä. Niistä kaikki toimittajat saavat nykyisin lähes täysiä pisteitä, jolloin kisa ratkaistaankin lopulta hinnalla.
Kolme tärkeintä tekijää projektin johtamisessa ja organisoinnissa
1. Projektilla on osaava ja innostunut omistaja asiakkaan puolella
Onnistunut julkinen IT-projekti vaatii loistavan tiimin lisäksi selkeää ohjausta asiakkaan puolelta. Kokemuksemme mukaan tyypillisiä syitä hankkeen epäonnistumiselle ovat projektin epäselvät tavoitteet tai asiakasorganisaation sisäiset ristiriidat.
Asiakkaalla on oltava projektille innostunut omistaja, joka tuntee henkilökohtaista vastuuta kehitettävästä järjestelmästä ja osaa johtaa vaativaa IT-projektia. Hän ymmärtää projektin ison kuvan, osaa viestiä tavoitteet tiimille ja sovittaa yhteen asiakasorganisaation sisäisiä tarpeita. Taitava toimittaja osaa tukea asiakasta siinä, että hanketta johdetaan oikeaan suuntaan.
2. Käyttäjälähtöinen suunnittelu on jatkuva osa projektia
Vaikeaan hankkeeseen ei kannata lähteä hankkimalla pelkästään koodaajia. Ilman käyttäjälähtöistä suunnittelua on riski, että ohjelmisto ei vastaakaan todellisia tarpeita. Tiimissä on hyvä olla alusta alkaen mukana suunnittelija, joka varmistaa yhdessä kehittäjien kanssa, ettei riviäkään koodata, ennen kuin ollaan varmoja, mitä halutaan saada aikaiseksi.
Jos ohjelmisto ei ratkaise virkamiesten tai kansalaisten ongelmia tai paranna käyttäjien työnkulkuja, sitä ei tulla käyttämään. Tässä hukataan suoraan veronmaksajien rahoja. Loppukäyttäjien työnkulkuja tulee analysoida, jotta voidaan priorisoida työn alle ne tehtävät, joilla on eniten vaikutusta ja joita käytetään useimmin.
IT-kehityksessä on aina tasapainoiltava käyttäjätarpeiden, liiketoiminnnan tavoitteiden ja kustannustehokkuuden välillä. Kokemuksemme julkishallinnosta osoittaa, että projekti on vaarassa epäonnistua, jos yksikin näistä puuttuu. Osaava suunnittelija varmistaa, että kaikki nämä kolme näkökulmaa huomioidaan kehityksen aikana.
3. Asiakas ja toimittajat ovat samassa veneessä ja juttelevat paljon
Onnistuneessa IT-projektissa asiakas ja toimittaja ovat aidosti samassa veneessä – projektia ei ole rakennettu vastakkainasettelulle ja sille, kuka sopimuksen mukaan korvaa vahingot sitten, kun kaikki kuitenkin menee pieleen. Asiakkaan ja toimittajan ihmiset ovat projektille yhtä tärkeitä. IT-projektit kestävät usein vuosia, ja yhteisillä tavoitteilla, hyvällä yhteishengellä ja ajoittaisilla donitseilla tiimitilassa on valtava merkitys onnistumiselle.
Yllättävän usein laatu- ja aikatauluongelmat johtuvat kommunikaation puutteesta. Riskejä on ilmassa, kun virkamiehet ja kehittäjät eivät työskentele yhdessä tai juttele riittävästi projektin etenemisestä, tarpeista ja riskeistä. Onnistuneessa projektissa keskustelu käy vilkkaana tiimitilassa, ohjausryhmissä ja päivittäisissä status-synkkauksissa – unohtamatta tiimin yhteisiä afterworkeja ja karaokeiltoja, joilla myös on tärkeä rooli.
Tarjouspyyntö on julkisen projektin kohtalonhetki – se kannattaa valmistella poikkitieteellisessä yhteistyössä!
Kriittiset julkiset tietojärjestelmät eivät ole hyllytavaraa. On tärkeää muistaa, että julkisissa projekteissa onnistumisen edellytykset luodaan – tai jätetään luomatta – jo hankintavaiheessa.
”Annetaan lakimiesten hoitaa kilpailutus ja paperihommat, ja palataan varsinaiseen tekemiseen sen jälkeen”, on houkuttelevan kuuloinen ajatus, joka kuitenkin sopii kehnosti julkisiin hankkeisiin. Hankintalain mukaan tarjouspyyntö ja sopimus ovat kohtalonhetkiä, jotka määrittävät koko projektin suunnan. Kuka voittaa tarjouskilpailun? Mahdollistaako sopimus ketterän ja fiksun projektitekemisen?
IT-hankinnat kannattaa valmistella ja suunnitella hyvässä yhteistyössä eri osastojen välillä. Hyvässä projektissa niin johdolla, liiketoiminnalla, ohjelmistoammattilaisilla kuin juristeilla on yhteinen näkemys siitä, miltä onnistuminen näyttää. Porukasta jokainen on henkilökohtaisesti sitoutunut sen saavuttamiseen - ja myös sopimus on viritetty onnistumista, ei käräjäoikeutta varten.
Kirjoittaja työskentelee johtajana ja julkishallinnon liiketoimintaan erikoistuneena juristina Reaktorilla.
