Ketteristä hankinnoista ja toteutusprojekteista julkishallinnossa

Tässä kirjoituksessa pohditaan ohjelmistojärjestelmän kehityshanketta – miten sellaiseen päädytään ja miten sellaisen voisi toteuttaa ketterästi. Koska Netumilla toimimme usein julkishallinnon parissa, keskityn tässä julkisiin projekteihin. Samat periaatteet pätevät toki mihin tahansa ohjelmistohankkeeseen.

Motivaatio: missä ollaan ja miksi?

Oleellinen osa mitä tahansa hanketta on tunnistaa tarve, syy ja motivaatio, joka meitä ylipäätään ajaa kehittämään järjestelmiä. Organisaation toimintaa ohjaava lainsäädäntö esimerkiksi muuttuu, käyttäjät ilmaisevat muutostarpeita tai organisaation toimintaa muuten kehitetään – eivätkä nykyiset järjestelmät enää palvele optimaalisesti.

Kun nämä syyt ja motivaatio ovat tiedossa, voidaan tarkemmin kartoittaa missä ollaan nyt ja missä halutaan olla tulevaisuudessa.

Visio: minne halutaan päästä?

Visiota muodostettaessa tunnistetaan tarkemmin järjestelmän kohderyhmä ja käyttäjät, tarpeet mihin järjestelmä vastaa ja hyödyt, joita se tuo käyttäjilleen. Voidaan määritellä, mikä järjestelmä on kyseessä, miten se eroaa muista vastaavista – samalla voidaan tarkistaa, olisiko riittävä hyöty saatavissa esimerkiksi valmisohjelmistoa käyttämällä tai toimintatapoja säätämällä.

Lopuksi mietitään, miten järjestelmä auttaa kehittäjäorganisaatiotaan, mitä liiketoimintahyötyjä tai muita etuja kuten säästöjä tai toiminnan nopeutumista se toisi. Tällä tavalla voidaan muodostaa järjestelmän visio. Miten organisaatio toimii sen jälkeen, kun tämä uusi järjestelmä on käytössä? Miten järjestelmä liittyy laajempaan kokonaisuuteen?

On tärkeää tunnistaa ja osallistaa kaikki asianosaiset mukaan jo tässä vaiheessa – henkilöt, joiden työhön järjestelmä vaikuttaa tai jotka hallinnoivat organisaation budjettia. Vision tulee olla yhteinen, jotta vältetään myöhemmässä vaiheessa turha muutosvastarinta, kampitus ja sabotointi.

Apuna vision muodostamisessa voidaan käyttää ulkoista liiketoimintakonsulttia, jollaista palvelua myös Netum tarjoaa.

Toteutuskelpoisuus

Jotta järjestelmä voidaan toteuttaa, hankinta pitää tyypillisesti kilpailuttaa. Jotta tämä olisi mahdollista, tulee edellä mainittu visio, tarve järjestelmälle, kommunikoida potentiaalisille toteuttajille mahdollisimman tarkasti.

Olisi lisäksi hyvä muodostaa jo etukäteen käsitys siitä, miten suuri hanke on kyseessä, ja miten toteutuskelpoinen suunnitelma on ylipäätään. Tässä voidaan käyttää apuna erillistä määrittelyprojektia, prototyyppejä ja Proof-of-concept -tyyppisiä toteutuksia ja kokeiluita. Näillä varmistetaan, että valittu lähestymistapa toimii. Nämä voidaan kilpailuttaa erikseen, esimerkiksi jonkin puitesopimuksen sisäisenä minikilpailutuksena, jolloin prosessi on nopeampi.

Koska ollaan tekemässä ketterää projektia, käytetään määrittelyyn ja kokeiluihin vain riittävä määrä aikaa, jotta voidaan perustella varsinaisen toteutusprojektin budjetti sekä toteuttaa sen kilpailutus riittävillä lähtötiedoilla.

Kilpailutus

Tässäkin vaiheessa muistetaan, että kaikkea ei voi määritellä etukäteen ja että tarpeet muuttuvat jatkuvasti. Siksi ei kilpailuteta kiinteää työpakettia ja valita sille halvinta tekijää. Edeltävien vaiheiden ansiosta toimittajakandidaateille pystytään kertomaan selkeä tarina organisaation toiminnasta ja tarpeista, motivaatiosta ja visiosta. Lisäksi voidaan jakaa aiempien kokeilujen tulokset.

Pyritään löytämään sellainen toimittaja, jolla on riittävästi toimialakokemusta ja osaamista teknologioista, joiden parissa töitä tullaan tekemään. Sellainen toimija, johon voi luottaa – oleellista on löytää oikea kumppani, ei niinkään pyrkiä saamaan tiettyä etukäteen määriteltyä pakettia mahdollisimman halvalla.

Toteutus

Usein alkuperäisten tarvekartoitusten ja visioiden kehittämisen sekä toimitusprojektin alkamisen välillä menee aikaa, esimerkiksi vuosi. Miten todennäköistä on, ettei mikään organisaation kokoonpanossa tai toimintaympäristössä ole tällä välillä muuttunut? Onkin tarpeen toistaa projektin aluksi riittävässä laajuudessa vision muodostaminen ja asianosaisten osallistaminen.

Tällä kertaa myös toimittajan edustajat ovat mukana muodostamassa ja jakamassa yhteisen vision. Oikein valittu toimittaja pääsee nopeasti sisään organisaation toimintaan, haastaa sopivasti vanhoja näkemyksiä ja yhteistyö tilaajan ja toimittajan välillä käynnistyy ja luottamus lähtee muodostumaan.

Visiota säädetään tarpeen mukaan hallitusti, ohjausryhmätasolla. Budjetti mielessä pitäen tarkistetaan, että järjestelmän tiekartta ja julkaisusuunnitelmat ovat realistisia ja sopivat laajempaan kokonaisuuteen edelleen. Varmistetaan, että ollaan tekemässä oikeita asioita, oikeassa järjestyksessä. Tämä on jatkuvaa ja iteratiivista toimintaa, kuten ketterä kehityskin.

Järjestelmälle muodostetaan yhdessä näille perustuksille priorisoitu lista ominaisuuksia, jotka voidaan pilkkoa toteuttamiskelpoisiksi käyttäjätarinoiksi.

Ketteryys

Ketterässä hankkeessa mitään ei ole hakattu kiveen, kiinteää ketterää hanketta ei ole olemassa. Budjetti pitää ja läpinäkyvä, ketterä hanke nimenomaan mahdollistaa tämän. Hankkeen aikana kehitettävän järjestelmän nykytilasta mahdollistetaan reaaliaikainen näkyvyys tilaajan edustajille, jotta voidaan säätää suunnitelmaa, adaptoitua ajoissa – ei vasta siinä vaiheessa, kun ajateltiin hartaasti määritellyn ja kiinteänä tilatun toimituksen saapuvaksi postilaatikkoon.

Tilaajan tuoteomistaja ylläpitää aktiivisesti visiota ja ohjaa koko hanketta tiekartasta julkaisusuunnitelmiin ja työjonoon asti siten, että visio toteutuu mahdollisimman hyvin. Hyvää toteutustiimiäkin oleellisempi hankkeen onnistumiselle on hyvä tuoteomistaja, joka pystyy valvomaan vision toteutumista, kommunikoimaan tiimille ja organisaatiolle laajemmin sekä tekemään tarvittavat päätökset.

Hankkeessa julkaistaan käytettävää ohjelmistoa säännöllisesti siten, että jo alustavassa kehitysvaiheessa syntyy järjestelmä, jota asianosaiset voivat kokeilla käytännössä. Uudet toiminnot tuodaan mukaan heti kun mahdollista, ja työjonoa kehitetään jatkuvasti saadun palautteen perusteella.

Kun järjestelmän nähdään tuottavan riittävästi lisäarvoa käyttäjilleen, se viedään tuotantoon. Kehitys ei kuitenkaan pääty tähän, vaan vision ohjaamana ja budjetin sekä erilaisten tavoitepäivämäärien muodostamissa raameissa järjestelmää kehitetään palautteen perusteella edelleen, tuoden uudet ominaisuudet ja muutokset käyttöön saman tien, kun ne valmistuvat.

Hanke päättyy, kun tilaaja toteaa saavuttaneensa sille asettamansa tavoitteet. Viimeistään myös silloin, kun budjetti on käytetty. Koska järjestelmä on kehitetty tärkeimmät asiat kärjessä ja julkaistu säännöllisesti, on

tässäkin tapauksessa käytössä paras mahdollinen järjestelmä. Jos ja kun kehitystarpeita on jatkossakin, haetaan jatkuvaa kehitystä varten lisäbudjettia ja toteutetaan tarvittaessa uusi kilpailutus.

Vaaranpaikat

• Huomataan, että on budjettia, hankitaan jotain, että se tulisi käytettyä.
• Yhteinen näkemys, visio puuttuu
  • ei osallisteta järjestelmän käyttäjiä, henkilöitä, joiden toimenkuvaan se tulee vaikuttamaan.
  • ei osallisteta budjetin omistajaa.
• Ei kommunikoida kokonaistilannetta, motivaatiota ja visiota toimittajalle, vaikka se sisäisesti olisikin saavutettu. Hehän vaan tekevät, mitä pyydetään.
• Pyritään minimoimaan riskit määrittämällä sopivan monitulkintainen vaatimuslista, jolla voidaan siirtää riski toimittajalle ja pyrkiä toteuttamaan todennäköiset muutostarpeet vetoamalla alkuperäisiin vaatimuksiin.
• Ei kokeilla eikä tutkita, vaan lähdetään liikkeelle epärealistisen pienellä budjetilla, jolla ei saa ensimmäistäkään hyödyllistä ominaisuutta käyttöön asti.
• Varmistetaan epäonnistuminen yhdistämällä pieni budjetti ja kiinteä vaatimuslista.

Loppusanoina voisi todeta, että oleellisin asia hankkeen onnistumiselle on ymmärtää, miksi ja mitä hankkeessa ylipäätään pyritään saavuttamaan – ja kommunikoida tämä kaikille asianosaisille selkeästi. Toiseksi tärkeintä on löytää mieluiten tilaajan omasta organisaatiosta motivoitunut tuoteomistaja hanketta vetämään ja hänelle kumppaniksi osaava toteutustiimi.