Miten JulkICT-strategioilla voidaan tukea innovaatioiden käyttöön saamista sekä ketteryyttä

  • 0

Miten JulkICT-strategioilla voidaan tukea innovaatioiden käyttöön saamista sekä ketteryyttä

Tags : 

Kommenttini LinkedIn-keskustelussa “Miten edistämme ja erityisesti nopeutamme innovaatioiden käyttöön saamista? Miten hyödynnämme ketteriä (agile) menetelmiä?“, Timo Valli, tässä siitä vapaa kopio

Tämä Timo Vallin alustama aihe on innostava! Jo annettujen kommenttien perusteellakin voi havaita, että alustettua aihepiiriä voi lähestyä monella tavalla. Alustuksessa on johdattelevina näkökulmina mm.
a) toimintaa tukevien teknologiainnovointien kehittämisen ”organisointi”.
b) innovoinnin järjestäminen lähelle toimintaa kehittäviä käyttäjiä itseään.
c) käyttäjien tiivis osallistuminen ratkaisujen kehittämiseen koko kehittämisen ajan.
d) tarvitaanko ketterän kehittämisen osaamiskeskusta?
e) voisiko ketterän kehittämisen osaamiskeskus huolehtia yhteisistä innovaatioista?
f) voisiko ketterän kehittämisen osaamiskeskus huolehtia teknologiainnovaatioiden yleisestä ohjauksesta julkisessa hallinnossa?

Kun asiaan johdatellaan näin rikkaasti, hajautuu keskustelukin monin tavoin asian ympärille. Oma tarkastelukulmani tähän on nyt ratkaisutoimitusten hankkiminen ja toimittaminen ketterillä tavoilla. Itselläni on kokemusta tässä lähinnä scrum-toimituksista. Olen ollut muutamissa mukana myös julkisille toimijoille rakentamassa toimittajapuolella toimintaa vastaamaan ko. kysyntää, rakentamassa sopimukset vastaamaan ko. toimitusmallia ja havainnoimassa, ohjaamassa ja päättämässä hankkeiden toimitusvaiheissa hankejohtotasolla. Seuraavana on muutamia havaintoja ja näkemyksiä näistä.

Tässä ei nyt ole kyse näkökulmasta ja toimintamallista, että on esimerkiksi puitesopimuksilla tms. hankittu joukko asiantuntijoita tietyksi ajaksi vaikkapa vuodeksi kerrallaan tietyllä rahalla ja sitten erillisinä toimeksiantoina ja tehtävinä käytetään ja täytetään tätä ostettua aikaa ja osaamista ”ketterästi”. Pyrin sovittamaan ketterää mallia hankkeeseen, jossa rakennetaan ja otetaan käyttöön ict-järjestelmä/palvelu ja jolle on asetettu tietyt tavoitteet ja vaatimukset, jolle on aikataulu ja jolle on varattu tietty määrä rahaa. Nämä ovat mielestäni ”kulmakiviä”, jotka ovat olemassa lähes aina. Sellaiseen scrumin perusmuotoon, jossa annetaan/ostetaan resurssit tietylle ajalle ja hinnalla ja sitten katsotaan ”kuinka pitkälle näillä pääsee” täysin joustavin vaatimuksin, ei ole käytännössä olemassa. Vai onko? Rahaa on jokaisessa tapauksessa jokin ennalta sovittava määrä ja aikataulu on hyvin tärkeä ja hankkeella tavoitellaan tiettyjä tuloksia ja arvon tuotantoa. Ja kun aikataulu on täynnä, hankkeen tulokset halutaan aiottuun käyttöön.

Ketterä hanke, vaikkapa scrum-hanke, on mielestäni hankkeen ohjauksen näkökulmasta huomattavasti vesiputousmallista hanketta vaativampi ja aikaa vievempi kaikille osapuolille. Ketteryys ei tuo tähän joustavuutta vaan päinvastoin ohjauksen joustavuus voi johtaa syvälle pettymyksiin. Hyvin ja tiukasti ohjattuna ja ammattitaitoisesti toteutettuna scrum-hanke tuottaa hyvän tuloksen ja hyvän arvon käyttäjien näkökulmastakin sekä sallii ja jopa etsii innovaatioita.

Vaikka hanke toteutetaan ketterästi ja ”inkrementein” tai ”sprintein”, se ei mielestäni muuta hankkeen johtamisen ja sopimuskäytäntöjen näkökulmasta asiaa perinteisestä vesiputousmallista. Hankkeella on johtamismielessä ja päätöksentekomielessä sopimuksellisestikin aina aloitus vaatimuksineen, toteutusvaihe (vaikka ketterästikin) ja sitten päätös ts. hyväksymisvaihe. Viimeistään hyväksymisvaiheessa voivat alkaa sopimustekniset ja käytännön hallinnolliset ongelmat, kun tilaajan johto joutuu päättämään onko hanke hyväksyttävissä. Hankkeella on tyypillisesti ollut alkujaan kuitenkin vaatimusluettelo jossain muodossa. Jos hanke on sitten toteutettukin hyvässä yhteisymmärryksessä, mutta samalla vaatimuksia on matkalla muutettu, uusia tullut mukaan ja osa alkuperäisistä on vielä toteuttamatta ajan ja rahan tultua täyteen, voidaanko hanke hyväksyä ilman poistettuja vaatimuksia? Mikäli se on esimerkiksi julkisesti kilpailutettu? No lopulta kysymys on mielestäni ihan perinteisestä tiukasta muutoshallinnasta tässäkin, se vain tulee sovittaa hankkeen toteutuksen ja vaatimusten täsmennyksen rytmiin. Hankkeen johdon tulee voida olla mukana päätösten arvioinnissa ja tekemisessä riittävän tiiviisti, jotta se ei ylläty loppuvaiheessa. Sopimuksen tulee sallia vaatimusmuutokset joissain rajoissa.

Hankkeessa on myös eriluonteisia tehtäviä, joista osa on ”joustavia” ja osa ei ole. Joustaviin sopii scrum-päätösmalli hyvin. Ei-joustavat vaatimukset ja tehtävät voivat sotkea koko toimituksen, kun ne laitetaan yhteen samaan scrum-toteutukseen ja tiimiin suoritettavaksi. Esimerkiksi saattaisi tapahtua, että toimittajan yksikkötestausta ei sprinteissä ”ehditä” suorittamaan riittävästi, kun sprinteissä halutaan tilaajan kanssa yhteiselläkin päätöksellä tuottaa sen sijaan mahdollisimman paljon uusia ominaisuuksia. Ja kun aikataulu ja raha loppuvat, huomataan, että käsissä on ”yhteisellä päätöksellä” vielä keskeneräinen tuotos. On monia asioita, joissa ei voisi joustaa, mutta osassa vaatimuksia taas voi. Mitä jos hanke mallinnettaisi ja hankittaisi siten, että määritellään huolella ei-joustavat ja ihan pakolliset vaatimukset erikseen ja itse ”ratkaisun joustava ydin” erikseen? Joustava ratkaisutoimituksen osuus tehtäisi scrumilla ja mahdollisimman innovatiivisestikin. Mutta tähän liittyvät ei-joustavat tehtävät ja ihan pakolliset vaatimukset voitaisiin sopia vaikkapa ihan kiinteällä sopimuksella, ovathan ne kiinteästi määriteltävissä. Ja ne voidaan ottaa haluttaessa asian osaavimmalta toimijalta normaalein hankintamenettelyin.

Mielestäni esimerkkeinä pakollisista vaatimuksista ja ei-joustavista tehtävistä ovat testaus ja tietoturva –asiat kokonaisuudessaan ohjattuina ja johdettuina. Testaaminen voisi olla hyvinkin tarkoituksenmukaista ottaa erikseen kokonaisuudessaan siihen erikoistuneelta toimijalta, ulkoa tai sisältä, ammattitaitoisesti määriteltynä, konsultoituna hankkeen ajan ja toteutettuna sekä jopa johdettuna. Tavoitteena on laatu ja arvokas arvoa tuottava lopputuotos. Tietoturvaan toimii sama ajatus. Hankkeen ”ytimen” toteutustiimi saisi tietoturvakonsultoinnin ja ohjauksen ja tarkistukset tiiminsä ulkopuolelta ja mahdollisesti tietoturva olisi kokonaisuudessaan johdettu hankkeen ”ytimestä” erillään.

Ajatukseni edellisissä siis on, että eriytetään toteutuksissa ne osat, joissa joustavuus ja innovatiivisuus ovat toivottavia niistä, joissa ei toivota joustoa eikä ”lipsumista” tapahtuvan.

Paluuna alkuperäiseen Timon esittämään kysymykseen ja keskustelun avaukseen – Voisiko ”ketterän kehityksen osaamiskeskus” toimia tässä kuviossa (lisä)arvoa tuottaen? Mitä tehtäviä ja mikä osaaminen ko. osaamiskeskuksessa olisi? Miten osaamiskeskus osaajineen osallistuisi julkisten toimijoiden ict-hankkeisiin? – Hankkeiden tilaajan tulee osallistua itse tiiviisti ketteriin hankkeisiin koko hankkeen ajan, näin on jo todettu. Hankkeiden ohjaaminen on tiivistä ja vaativaa, myös niiden alkuun saattaminen. Mm. tietoturva ja testaaminen kokonaisuudessaan ovat erityistä ammattiosaamista edellyttäviä tehtäviä. Voisiko osaamiskeskus olla esimerkiksi näissä asioissa käytännössä hankkeissa mukana ja tukemassa ja ehkä johtamassa niiden toteutumisen? Samalla sen tehtävään kuuluisi varmistaa ”ratkaisujen ydinten” toteutuksista innovaatioiden koostamisen ja tiedon jakamisen?

Tässä oli muutamia ajatuksia. Ei maailma ihan valmiiksi, onneksi, vielä näistä tule. Huomenna meillä on jo taas vielä parempia ajatuksia.

Published on: Nov 18, 2011 / Petri Hakanen


About Author

Petri Hakanen

at Your service. Development & Strategy. Lead. Design. Coach. Speaker. Transformation. execution-to-strategy

Leave a Reply

*