Miten valitsen osaavan IT-projektipäällikön, ja vältän huithapelit, jyrääjät ja tuuliviirit?

Mies meni eläinkauppaan. Häkissä oli kolme apinaa. ”Miten tuo apina voi maksaa 10.000 euroa?”, mies kysyi myyjältä. ”Se osaa koodata”, vastasi myyjä. ”Entä tuo toinen apina?”, kysyi mies. ”Se maksaa 15.000 euroa. Se osaa IT-arkkitehtuuria”, vastasi myyjä. ”Entä tuo kolmas sitten?”, kysyi mies. ”Se maksaa 20.000 euroa.”, vastasi myyjä. ”Mitä se oikein osaa?!?”, kysyi mies. Myyjä vastasi: ”En tiedä, mutta nuo kaksi muuta sanoo sitä projektipäälliköksi.”

Apina tietokoneella

Projektipäällikön valinta on yksi IT-projektin ohjausryhmän tärkeimmistä päätöksistä. Osaava projektipäällikkö on IT-projektin keskeinen menestystekijä. IT-projektipäälliköiden osaamisen arviointi ja vertailu on haastavaa, joten ohjausryhmät eivät useimmiten kiinnitä projektipäällikön valintaan riittävästi huomiota. IT-projekteihin liittyy useita epävarmuuksia, eikä edes osaava projektipäällikkö voi estää kaikkia ongelmia, minkä takia projektipäällikön merkitystä projektin onnistumiselle aliarvioidaan liian usein. Osaava projektipäällikkö osaa kuitenkin ennakolta estää monia ongelmia ja lieventää ennakoimattomien ongelmien vaikutusta, mikä näkyy pienempinä kustannus- ja aikatauluylityksinä.

Käytännön IT-arjessa kamppaillaan taivaita hipovien tavoitteiden, rajallisten resurssien ja tiukkojen aikataulujen ristipaineessa. Seuraavan kerran kun olet nimittämässä IT-projektiisi projektipäällikköä, pysähdy hetkeksi ja varmista, ettet ole tietämättäsi syyllistymässä johonkin seuraavista virhearvioista IT-projektipäällikön valinnassa:

  • valitset huithapelin, jolla on kirkas visio, mutta jolle työn suunnittelu on utopiaa ja prioriteetit turhuuksia
  • valitset ahertajan, joka ratkaisee ongelmat nopeasti, mutta ei estä niiden syntymistä ennakoimalla
  • valitset hurmaajan, joka uskoo ilmapiirin, fiiliksen, ja yhteishengen vievän vaikka läpi palomuurin
  • valitset kauppiaan, joka pitää ohjausryhmän ja sidosryhmät tyytyväisenä syöttämällä niille paskaa
  • valitset kylmäkallen, joka tehokkuuteen pyrkiessään kohtelee tiimiä mekaanisina suorittajina ja korvattavissa olevina resursseina
  • valitset ohjeistamispäällikön, jolle projektissa tärkeintä on hallinnollinen tarkkuus ja metodologinen kuri
  • valitset törmäysnuken, joka tietää kestävänsä palautetta, joten projektin onnistumisesta ei ole tarvetta stressata
  • valitset norsunluutornilaisen, jolle liiketoiminnan tavoitteet ovat selkeitä, mutta tekniikka-, arkkitehtuuri- ja vaatimusasiat on epämiellyttävää nippeliä
  • valitset propellipään, joka pyrkii edistykselliseen tekniseen ratkaisuun, mutta ei ymmärrä liiketoiminnan tarpeita
  • valitset höpöttäjän, joka osallistaa kaikki projektityöhön, mutta mittaa projektin etenemistä palaverien ja niiden osallistujien määrällä
  • valitset jyrääjän, joka toimittaa ala-arvoisen ratkaisun sovitussa aikataulussa ja budjetissa
  • valitset jokapaikanhöylän, joka on aina tekemisessä mukana ja ilmestyy mikromanageeraamaan myös silloin, kun ei tarvita
  • valitset tuuliviirin, joka etsii kompromisseja, mutta ei tee päätöksiä, koska ei halua sanoa kenellekään vastaan
  • valitset konkarin, jolla on pitkä kokemus teknisenä asiantuntijana, mutta jolle ei löydy enää muitakaan hommia
  • valitset juniorin, joka vakuuttaa olevansa motivoitunut IT-projektipäälliköksi, mutta ei ole aiemmin ollut IT-projektissa mukana

Vaikka IT-projektipäällikköjen osaamisen arviointi on haastavaa, kannattaa muistaa se tosiasia, että toiset projektipäälliköistä todella ovat osaavampia. Lisäksi erilaiset IT-projektit vaativat projektipäälliköltä erilaista osaamista riippuen esim. projektin liiketoimintakeskeisyydestä, ratkaisun teknisyydestä, projektin riskiprofiilista, projektiorganisaation muodosta tai ratkaisun loppukäyttäjistä. Nimenomaan vaativissa olosuhteissa projektipäällikön osaamisella on suurin vaikutus projektin onnistumiseen tai epäonnistumiseen.

Mount Everestin valloitus

Vaatii huomattavasti vähemmän osaamista retkenjohtajalta johtaa patikointia vehreälle kukkulalle kauniina kesäpäivänä kuin kiipeämistä Mount Everestille lumimyrskyn uhatessa. Kesäpäivänä kukkulalla voi olla vaikeaa nähdä eroja retkenjohtajien osaamisessa tai huonojen päätösten seurausten merkitystä. Sen sijaan Mount Everestilla jokainen retkenjohtajan päätös voi tehdä eron koko retkikunnan elämän ja kuoleman välillä. Valitsisitko itsellesi Mount Everestille retkenjohtajaksi joviaalin jutustelijan, joka patikoi ruohikolla kerran vuodessa aurinkoisessa säässä vai sherpan, joka on aiemmin vetänyt retken huipulle parikymmentä kertaa?

Kaikissa IT-projekteissa projektipäälliköltä vaaditaan monipuolista osaamista tasapainoisessa suhteessa. Projektinhallinnollisten menetelmien lisäksi mm. liiketoiminnan tavoitteiden syvällinen ymmärtäminen, organisaatiorajat ylittävät viestintätaidot, kokonaisuuden tilannekuvan säilyttäminen ja konkreettisten priorisoitujen toimintasuunnitelmien valmisteleminen ovat arvokkaita taitoja.

Älä ainakaan valitse seuraavan IT-projektiisi projektipäällikköä, jolta löytyy kovin monia edellä listatuista piirteistä. Muuten saatat pian löytää itsesi ja projektisi perinteisen sananlaskun kuvaamasta tilanteesta, jossa kyvyttömät yrittävät saada haluttomat tekemään mahdottomia.

Mihin tarvitaan ei-toiminnallisia IT-vaatimuksia?

Useimmiten uuden IT-ratkaisun määrittelytyö keskittyy ratkaisun toiminnallisiin vaatimuksiin: Tietojärjestelmältä haluttuja toimintoja kuvataan käyttäjätarinoiden (user story), käyttötapausten (use case) ja käyttöliittymän näköismallien (wireframe/mockup) avulla. Toiminnalliset vaatimukset kuvaavat kattavasti ja yksityiskohtaisesti käyttäjän vuorovaikutuksen tietojärjestelmän kanssa. Ne määrittelevät, millä tavalla ja mitä syötteitä käyttäjä antaa tietojärjestelmään sekä järjestelmän antamat vasteet käyttäjän syötteisiin.

Tietojärjestelmän ei-toiminnalliset tai laadulliset vaatimukset (non-functional requirements) sen sijaan määrittelevät miten tietojärjestelmä antaa vasteet syötteisiin tai millainen se on. Ei-toiminnallisia vaatimuksia ovat esimerkiksi:

  • Saatavuus (availability). Jos IT-ratkaisun tulee olla käytettävissä 99 % ajasta, saako se olla pois käytöstä 14 minuuttia päivässä vai yhtäjaksoisesti 3,5 päivää vuodessa? Miten IT-arkkitehtuurilla ja toimintatavoilla varmistetaan, että ratkaisun suunnitellut ylläpitotoimenpiteet ja yllättävät virhetilanteet hoidetaan saatavuusvaatimukset täyttäen?
  • Skaalautuvuus (scalability). Jos IT-ratkaisu toimii 100 yhtäaikaisen käyttäjän kuormalla, niin toimiiko se samalla suorituskyvyllä myös 500 käyttäjän kuormalla? Miten IT-arkkitehtuurilla varmistetaan, että ratkaisu voidaan pienillä muutoksilla (infrastruktuuriin, alustaan tai sovellukseen) saada toimimaan myös 10000 käyttäjän kuormalla?
  • Siirrettävyys (portability). Jos IT-ratkaisu toimii Windows PC:llä, niin toimiiko se myös Applen Mac-tietokoneella (OS X), Samsungin Galaxy-puhelimella (Android) tai Nokian Lumia-puhelimella (Windows Phone)? Miten teknologiavalinnoilla varmistetaan ratkaisun alustariippumattomuus tai minimoidaan työ, joka vaaditaan ratkaisun siirtämiseen uudelle alustalle?

Muita ei-toiminnallisia vaatimuksia ovat esimerkiksi tietojärjestelmän tietoturvaan (security), käytettävyyteen (usablity), ylläpidettävyyteen (maintainability), räätälöitävyyteen (modifiability), integroitavuuteen (interoperability) tai suorituskykyyn (performance) liittyvät vaatimukset. Kuten yllä olevat esimerkit auttavat ymmärtämään, ei-toiminnalliset vaatimukset määrittelevät rajoitteita ja reunaehtoja tietojärjestelmän tekniselle toteutukselle ja hallinnoinnille.

Tietojärjestelmän ei-toiminnallisia vaatimuksia on haastavaa määritellä selkeästi, koska ne liittyvät järjestelmän sisäisiin ja teknisiin ominaisuuksiin. Uuden tietojärjestelmän vaatimuksia määriteltäessä kiinnostavat tyypillisesti eniten ratkaisun käyttäjälle tarjoamat toiminnot eli toiminnalliset vaatimukset. Kuitenkin ei-toiminnalliset vaatimukset voivat työmäärällisesti vastata useita kymmeniä prosentteja ratkaisun toteutuksen kokonaistyömäärästä.

Ei-toiminnallisilla vaatimuksilla on kriittinen rooli tietojärjestelmän laadun, luotettavuuden ja kustannustehokkuuden takaamisessa koko elinkaaren ajan. Panostus ei-toiminnallisten vaatimusten määrittelyyn heti alussa on tärkeää, koska ratkaisun toteutuksen jälkeen ei-toiminnallisia vaatimuksia voi olla hyvin työlästä tai jopa mahdotonta täyttää.

Realististen ei-toiminnallisten vaatimusten määrittelyyn tarvitaan yhdistelmä teknistä ja liiketoiminnallista ymmärrystä. Ei-toiminnalliset vaatimukset laatii tyypillisesti projektin suunnitteluvaiheessa IT-arkkitehti, joka tasapainottelee liiketoiminnan ja tietohallinnon tarpeiden sekä teknologian mahdollisuuksien välillä. Ei-toiminnallisten vaatimusten määrittelyssä tarvitaan kompromisseja ja vaatimusten välistä priorisointia (trade-off), koska useimmiten kaikkia vaatimuksia ei ole mahdollista toteuttaa käytössä olevilla rajallisilla resursseilla. Esimerkiksi ratkaisun suorituskyvyn parantaminen saattaa vähentää ratkaisun siirrettävyyttä tai integroitavuus saattaa vähentää tietoturvaa.

Yksinkertaistaen voisi sanoa, että ratkaisun toiminnalliset vaatimukset määrittelevät ratkaisun liiketoiminnallisen hyötypotentiaalin (prosessien mahdollistaminen, tehostaminen, tukeminen), kun taas ei-toiminnalliset vaatimukset määrittelevät ratkaisun luotettavuuden, kustannustehokkuuden ja teknisen mukautuvuuden tulevaisuuden tarpeisiin. Usein määrittelyvaiheessa eniten keskustelua herättävä ei-toiminnallinen vaatimus on järjestelmän saatavuus, jonka voidaan erityisesti liiketoimintakriittiselle järjestelmälle suoraviivaisesti vaatia olevan 100 %. Keskusteluun tuo perspektiiviä se, että AT&T:n puhelinverkko USA:ssa on ainut tekninen järjestelmä maailman historiassa, jossa on tiettävästi paikallisesti päästy 99,999 % saatavuuteen. Esimerkiksi Google tähtää palveluissaan 99,99 %:n saatavuuteen, mutta ei uskalla luvata käyttäjille sitäkään.

Lisätietoa:
The New York Times
Wikipedia

Räätälöity valmisohjelmisto, kiitos!

Kaupallisten valmisohjelmistojen hyödyntäminen yrityksissä on nykypäivää. Kaukana ovat ne ajat alkaen 60-luvulta, kun liiketoimintaprosesseihin räätälöidyn liiketoimintalogiikan kehitystä tehtiin suurtietokoneympäristöissä COBOL- ja PL/1-kielillä. Tai siis tehtiin niissä suurissa organisaatioissa, joissa oli varaa investoida arvokkaaseen keskustietokoneeseen. 80-luvulta alkaen kaupalliset valmisohjelmistot ovat käytännössä tuoneet tietotekniikan myös pienempien yritysten ja kuluttajien saataville.

Yritysten tietohallinnossa valmisohjelmistojen lisääntyminen on tarkoittanut, että aiemmin vallinnut toimintatapa kehittää liiketoiminnan tarvitsemat ratkaisut alusta asti on osin korvautunut valmisohjelmistojen käytöllä. Valmisohjelmistoilla on kiistaton liiketoiminnan tuottavuuden ja tehokkuuden kasvattamisen mahdollistava vaikutus. Niiden ansiosta yrityksillä on mahdollisuuksia valjastaa liiketoiminnan käyttöön tietoteknisiä ratkaisuja, joiden rakentamiseen organisaatioilla itsellään ei riittäisi resurssit tai osaaminen: kukaan ei nykypäivänä edes harkitsisi käyttöjärjestelmän, internet-selaimen, tietokantapalvelimen toteuttamista itse.

Toki kolikolla on myös kääntöpuoli. Tässä blogissa käsittelen haasteita, joita liittyy kaupallisten valmisohjelmistojen käyttöön liiketoiminnan tietojärjestelmien osana. Esitän näkökulmia, joita kannattaa pohtia, kun joutuu valitsemaan räätälöidyn ratkaisukehityksen ja valmisohjelmiston käytön välillä. Valmisohjelmistot lupaavat paljon ja niiden suurin haaste onkin, että ne lupaavat nopean tien korkeaan monimutkaisuuteen ja korkeaan laatuun ja samalla matalaan riskiin. Valitettavasti tämä on illuusio: asiakkaan tulee ymmärtää myös kompromissit, joita on pakotettu tekemään valitessaan valmisohjelmiston.

Käytännössä kaikissa liiketoiminnan tietojärjestelmissä on osana sekä valmisohjelmistoja (tietokannat, sovelluspalvelimet, integraatioalustat, verkkokomponentit) että räätälöityjä osia. Puhdas joko-tai valinta räätälöidyn ratkaisukehityksen ja valmisohjelmiston välillä tehdään melko harvoin. Seuraavia vinkkejä voikin hyödyntää myös pohdittaessa valmisohjelmiston räätälöinnin astetta tai räätälöidyn ratkaisukehityksen standardoinnin astetta.

Räätälöity ratkaisukehitys kannattaa erityisesti, kun

  1. projektin tavoitteet ovat strategisia (kilpailuetu, tulevaisuuden tarpeet) ja liittyvät ydinliiketoimintaprosessien kehittämiseen (esim. tilaus-toimitusprosessi tai asiakaspalveluprosessi)
  2. ratkaisun visio, konsepti ja vaatimukset ovat realistisia ja selkeitä, mutta monimutkaisia (kun valitsemalla valmisohjelmisto jouduttaisiin tekemään kompromisseja ratkaisun laajuuden, soveltuvuuden tai luotettavuuden suhteen)
  3. ratkaisun liiketoimintahyödyt ja laatu ovat tärkeämpiä kuin toteutuksen aikataulu ja kustannukset
  4. organisaatiolla on käytössä osaamista ratkaisun toteutukseen ja tukemiseen (työskentely on parhaiden teknisten käytäntöjen mukaista, tuottavaa, tehokasta ja ennakoitavaa)

Valmisohjelmiston valinta kannattaa erityisesti, kun

  1. projekti liittyy toimialalla käytännöiltään yhtenäiseen prosessialueeseen (esim. asiakastietojen hallinta) tai pientä liiketoiminnan lisäarvoa tuottavaan prosessiin (esim. matkalaskujen hallinta) tai ratkaisu on teknisiltä ominaisuuksiltaan erityisen vaativa
  2. ratkaisulle ei ole organisaatiossa selkeää visiota tai tarkkoja vaatimuksia ja organisaation toimintatapoja ollaan valmiita muuttamaan ratkaisun käyttöönoton seurauksena (valmisohjelmisto sisältää ”vision”)
  3. ratkaisun edellyttämät laadulliset kompromissit voidaan hyväksyä kustannussäästöjen ja nopean käyttöönoton saavuttamiseksi
  4. organisaation oma osaaminen ja mahdollisuudet ulkopuoliseen osaamisen käyttöön ovat rajalliset (riippuvuus ohjelmistotoimittajan tukipalvelusta tiedostetaan osana palvelutason ja riskien hallintaa)

Mikäli valinta tehdään väärin perustein ja päätetään valita valmisohjelmisto (kun tarvittaisiin räätälöity ratkaisu), ratkaisun karkeuden kompensoiminen räätälöimällä valmisohjelmistoa tai toimittajariippuvuuden vaikutusten väärinarviointi voi kasvattaa kustannuksia, aikataulua tai riskejä hallitsemattomasti. Mikäli valitaan räätälöity ratkaisu (kun riittäisi valmisohjelmisto) ratkaisun tekninen monimutkaisuus, realistisen ja selkeän ratkaisuvision puuttuminen, aikataulun/kustannuksen ylikorostaminen tai osaamisen puute voi johtaa kovinkin heikkolaatuiseen ratkaisuun.

Sekä valmisohjelmistoille että räätälöidylle ratkaisukehitykselle on edelleen paikkansa nykyaikaisessa liiketoiminnan tietojärjestelmäarkkitehtuurissa, vaikkakin yleinen ohjelmistoteknologioiden kypsyyden kehittyminen ja viimeaikainen pilvipalveluiden yleistyminen lisäävät vähitellen valmisohjelmistojen osuutta. Kaikki aidosti liiketoimintaa palvelevat korkealaatuiset, luotettavat ja joustavat IT-ratkaisut eivät kuitenkaan pilvestä tule – ainakaan vielä vähään aikaan.

IT-hankinnan sudenkuoppa #3: osaamisharha

Jatkan tässä blogissa IT-hankintojen käytännön haasteiden käsittelyä. Monet haasteista aiheutuvat riippumattoman näkökulman puuttumisesta hankkeen valmistelussa ja toimittajavalinnassa (ks. aiempi blogi Riippuvaisen IT-toimittajan keittokirjasta). Kerron näkemykseni tyypillisistä haasteista, mistä ne johtuvat ja miten sudenkuopat vältetään. Haasteisiin vaikuttavat sekä IT-toimittajan yksipuolinen etujen ajaminen että ostavan tahon puolella vallitsevat vääristyneet ajattelutavat tai osaamisen puute.

Kun aiemmissa blogeissa käsitellyt IT-hankinnan sudenkuopat monimutkaistaminen ja vähättely on onnistuttu välttämään, toteutettavalla IT-ratkaisulla on todellisen asiakastarpeen mukainen laajuus ja realistinen projektisuunnitelma. Tämän jälkeen projektiin pitää löytää resurssit eli asiantuntijat, jotka toteuttavat projektin. IT-hankintojen kolmas sudenkuoppa osaamisharha liittyykin näiden asiantuntijoiden nimittämiseen eli projektien resursointiin.

Osaamisharha-sudenkuoppaan ajaudutaan, jos projekti resursoidaan tekijöillä, joilla ei ole tarpeeksi tai oikeanlaista osaamista projektin läpi viemiseksi projektisuunnitelman mukaisesti. Parhaiden osaajien saaminen projektiin on usein haastavaa, joten tärkeää on, että resursointiin liittyvät kompromissit tehdään oikealla tavalla ja samalla tiedostetaan päätösten vaikutukset projektin aikatauluun ja laadunvarmistustarpeisiin. Osaamisharha pätee myös organisaation sisäisten resurssien osaamiseen, eikä pelkästään IT-toimittajan resursseihin.

Mikä sitten aiheuttaa osaamisharhan? Se, että projektiin tarvittavan osaamisen hahmottaminen ja tarjolla olevien resurssien osaamisen arviointi on erittäin haastavaa. Kukapa asiakas ei haluaisi projektiinsa parhaita mahdollisia osaajia? Toimittajat saattavatkin myyntivaiheessa esitellä asiakkaalle projektin tulevia toteuttajia osaavammat ja kokeneemmat resurssit. Jos asiakas tilaa projektin, resurssit muutetaan kokemattomampiin ja kokeneet resurssit katoavat vähin äänin taka-alalle.

Joskus resurssien osaamisen arvioinnissa ajaudutaan numero- ja termipeliin eli lasketaan ja vertaillaan resurssien CV:iden perusteella kokemusta kuukausissa tai etsitään tiettyjä IT-alan erikoistermejä pyrkimättä sen syvemmin tai laajemmin ymmärtämään tarvittavaa tai tarjolla olevaa osaamista. Projektit ovat aina erilaisia (vaikka olisi sama teknologia), joten myös tiimityötaidot sekä kokonaisuuksien ymmärtäminen ovat arvokasta osaamista. Harvoin ymmärretään, että asiantuntija, joka on aiemmin tehnyt teknologian X versiolla Y viisi projektia ei ole (useimmiten) viisi kertaa parempi osaaja kuin asiantuntija, joka on tehnyt samalla teknologialla vain yhden projektin ja neljä muuta projektia.

Miten osaamisharha-sudenkuoppa voidaan sitten välttää? Pitämällä mielessä kolme käytäntöä:

  1. arvioimalla kattavasti resurssien kokemusta ja toiminnallista osaamista (kokemuksen kesto vs. sisältö, tekninen erikoistuminen vs. monipuolisuus, prosessiosaaminen, organisaatio-osaaminen)
  2. ottamalla huomioon myös resurssien ei-toiminnallinen osaaminen (tiimityö, viestintä, projektityö, kokonaisuuksien ymmärtäminen) sekä motivaatiotekijät (asenne, oppimishalu, oppimiskyky)
  3. valitsemalla ja sitouttamalla projektin avainhenkilöt (esim. projektipäälliköt, ratkaisun tekninen omistaja, laadunvarmistusroolit) sekä sopimuksellisilla että johtamistekijöillä.

IT-hankinnoissa usein tahattomastikin syntyvän osaamisharha-sudenkuopan kiertämiseksi organisaatioiden on hyvä pyytää hankintavaiheeseen avuksi ulkopuolinen neuvonantaja, jolla on vankka sekä tekninen että projektinjohtokokemus vaativista tietojärjestelmähankkeista. Ulkopuolisen neuvonannon avulla organisaatio saa hankkeen valmisteluun riippumattoman näkökulman, jolla varmistetaan hankkeen onnistuminen.

IT-hankinnan sudenkuoppa #2: vähättely

Jatkan tässä blogissa IT-hankintojen käytännön haasteiden käsittelyä. Monet haasteista aiheutuvat riippumattoman näkökulman puuttumisesta (ks. Riippuvaisen IT-toimittajan keittokirjasta). Esittelen IT-toimittajien usein käyttämien kikkojen sisältöä, mistä ne johtuvat ja miten sudenkuopat vältetään. Ongelmiin myötävaikuttavat myös ostavan tahon puolella vallitsevat vääristyneet ajattelutavat tai osaamisen puute.

Kun toteutettavan ratkaisun laajuuteen liittyvä IT-hankintojen ensimmäinen sudenkuoppa monimutkaistaminen on vältetty, seuraavaksi pitää suunnitella, miten varsinainen toteutusprojekti ja tekeminen suunnitellaan. Laajuuden ja laadullisten tavoitteiden lisäksi projektilla on määritelmän mukaisesti aikataulu (kalenteriaikaa) ja budjetti (euroja). IT-hankintojen toinen sudenkuoppa onkin aikataulun ja/tai budjetin vähättely eli aliarviointi: toteutukseen varataan vähemmän aikaa tai euroja kuin mikä on realistisesti mahdollista. Kuten mediasta on voinut seurata, IT-projektien aikataulujen venähtäminen kaksin-, kolmin- tai nelinkertaiseksi alkuperäisestä suunnitelmasta ei valitettavasti ole niin harvinaista, kuin se voisi olla, mikäli IT-projektien laadun- ja riskienhallinnasta tehtäisiin kunnolla.

Miksi sitten toimittaja tarjoaisi asiakkaalle epärealistista projektisuunnitelmaa? Siksi, että projektisuunnitelman realistisuuden arviointi on ennen ratkaisun toteutustyön aloittamista toimittajalle ja etenkin asiakkaalle erittäin haastavaa. Jos taas toimittaja kysyy asiakkaalta, suunnitellaanko projektin kestoksi kolme kuukautta korkealla riskitasolla vai kuusi kuukautta matalalla riskitasolla, asiakkaan vastaus on (useimmiten): yritetään tehdä kolmessa kuukaudessa ja jossei tule valmista, niin sitten pidennetään projektia kolmella kuukaudella. Käytännössä tästä on lopputuloksena, että projektin lopullinen kesto asettuu tehottomuuksien takia 7-9 kuukauden välille riippuen siitä kuinka paljon ensimmäisen kolmen kuukauden aikana tehdystä työstä on tuottanut käyttökelpoisia tuotoksia.

Jos asiakas haluaa projektin valmiiksi ”mahdollisimman pian” ja ”mahdollisimman halvalla” (kukapa ei haluaisi), tämä asettaa IT-toimittajan ja asiakkaan yhteistyölle valtavat paineet ajautua vähättely-sudenkuoppaan. Tarjousprosessit vaativat IT-toimittajilta merkittäviä panostuksia, joten asiakkaan vaatiessa epärealistisia vaatimuksia, aikatauluja tai budjetteja, IT-toimittajalla on suuri kiusaus luvata nyt ja selvitellä myöhemmin. Projektin kustannusbudjetista voidaan toki neuvotella toteutusvaiheen aikana ja siihen voidaan liittää sopimusehtoja riskien siirtämiseksi asiakkaalta toimittajalle, mutta mikään ei tuo menetettyä kalenteriaikaa takaisin.

Miten vähättely-sudenkuoppa voidaan sitten välttää? Pitämällä mielessä kolme käytäntöä:

  1. tekemällä työmäärien arviointi ja projektisuunnittelu parhaiden käytäntöjen mukaisesti (mm. aika vs. pisteet, työnopeus, top-down, bottom-up, koordinaatiohukka, projektointi),
  2. eriyttämällä kaupalliset sopimusneuvottelut asiantuntijoiden arviointityöstä ja muodostamalla asiakkaan ja toimittajan välille yhteisymmärrys projektin aikatauluun ja budjettiin liittyvistä riskeistä,
  3. yhteistyöhön ohjaavat sopimukselliset win-win-ehdot (esim. kiinteähintaiset elementit, kustannusbudjetin bonus/malus, myöhästymissakko, time-boxing, takuut)

IT-hankinnoissa usein tahattomastikin syntyvän vähättely-sudenkuopan kiertämiseksi organisaatioiden on hyvä pyytää hankintavaiheeseen avuksi ulkopuolinen neuvonantaja, jolla on vankka sekä tekninen että projektinjohto kokemus vaativista tietojärjestelmähankkeista. Ulkopuolisen neuvonannon avulla organisaatio voi tehostaa viestintää IT-toimittajien kanssa ja saada hankkeeseen riippumattoman, puhtaasti oman etunsa mukaisen näkökulman.

IT-hankinnan sudenkuoppa #1: monimutkaistaminen

Esittelin aiemmassa blogissa Riippuvaisen IT-toimittajan keittokirjasta käytännön haasteita, joita kohdataan erityisesti riippumattoman neuvonannon puuttuessa IT-ratkaisuiden hankinnoista. Tässä ja muutamassa seuraavassa blogissa esittelen tarkemmin riippuvaisten IT-toimittajien usein käyttämien kikkojen sisältöä, mistä ne johtuvat ja miten sudenkuopat vältetään. Useimmat IT-toimittajat eivät johda asiakastaan tarkoituksellisesti harhaan. Ongelmiin myötävaikuttavat myös ostavan tahon puolella vallitsevat vääristyneet ajattelutavat tai osaamisen puute.

Uutta tietojärjestelmää hankittaessa monimutkaistaminen on usein ensimmäinen eteen tuleva sudenkuoppa, johon on vaara ajautua. Kyse on siitä, että IT-toimittaja tarjoaa asiakkaalle monimutkaisempaa ratkaisua kuin asiakas oli alunperin ajatellut hankkivansa ja todellisuudessa olisi asiakkaan etu. Ratkaisun monimutkaisuus voi syntyä esimerkiksi laajemmasta toiminnallisuudesta, edistyneemmästä teknisestä toteutuksesta tai heikosta sopivuudesta kokonaisarkkitehtuuriin. Joka tapauksesa ratkaisun monimutkaisuus vähentää sen luotettavuutta ja kustannustehokkuutta.

Miksi sitten toimittaja tarjoaa monimutkaisempaa ratkaisua asiakkaalle? Siinä, missä asiakkaan etu on saada liiketoimintatarpeen täyttävä, luotettava ja kustannustehokas ratkaisu, IT-toimittajan yksioikoinen etu on myydä ratkaisu, jonka toteuttaminen ja ylläpito vaativat mahdollisimman paljon laskutettavaa työtä. Tähän tavoitteeseen toimittaja pääsee monimutkaistamalla. Monimutkaistaminen tapahtuu huomaamatta, koska ratkaisun luotettavuuden ja kokonaiskustannuksen (total cost of ownership) arviointi ennen ratkaisun toteutustyön aloittamista ja osin myös toteutuksen jälkeen on erittäin haastavaa.

Varsinkin silloin, kun tietojärjestelmähanke on liiketoimintakriittinen ja investointina suuri, niin myös liiketoimintajohto on mukana hankinnassa. Kun kyseessä voi olla yrityksen tärkein IT-investointi vuosikymmeneen, asiakas joskus jopa haluaa kuulla IT-toimittajalta, että ratkaisua voidaan laajentaa uusilla toiminnallisuuksilla, joita ei alun perin ollut otettu huomioon määrittelyssä. Koska asiakkaan odotuksena on, että hankkeesta tulee suuri ja haastava, toimittaja mielellään ruokkii tätä odotusta tarjoutumalla toteuttamaan ratkaisun teknisesti edistyneemmin (esim. korkean käytettävyyden arkkitehtuurilla (high availability architecture, HA) tai geneerisin palvelurajapinnoin (service-oriented architecture, SOA)).

Miten monimutkaistaminen voidaan sitten välttää? Pitämällä mielessä kolme käytäntöä:

  1. tekemällä ratkaisun vaatimusmäärittely toimittaja- ja teknologiariippumattomasti sekä liiketoimintalähtöisesti (sis. toiminnalliset ja ei-toiminnalliset vaatimukset),
  2. arvioimalla tarjousvaiheessa toimittajien vaatimusmäärittelyyn ehdottamat laajennukset/muutokset sekä ratkaisun luotettavuuden että projektitoteutuksen kustannustehokkuuden kannalta,
  3. panostamalla projektityöskentelyn tuottavuuteen ja tehokkuuteen sekä laadun ja riskien hallintaan edistyneiden teknisten ratkaisuiden sijaan (jos tekniset ratkaisut eivät kriittisesti arvioiden läpäise listan kohtaa 2).

IT-hankinnoissa usein tahattomastikin syntyvän monimutkaistamis-sudenkuopan kiertämiseksi organisaatioiden on hyvä pyytää määrittely- ja hankintavaiheeseen avuksi ulkopuolinen neuvonantaja, jolla on vankka sekä tekninen että projektinjohto kokemus vaativista tietojärjestelmähankkeista. Ulkopuolisen neuvonannon avulla organisaatio voi tehostaa viestintää IT-toimittajien kanssa ja saada hankkeen valmistelu- ja toteutusvaiheisiin riippumattoman, puhtaasti oman etunsa mukaisen näkökulman.

Valhe, emävalhe, IT-KPI?

Usein sanotaan, että et voi johtaa, mitä et mittaa. Tämä pätee myös IT-projekteihin, tietojärjestelmiin ja tietohallintoon. Hyvin valittuja ja jalkautettuja mittareita (Key Performance Indicator, KPI) seuraamalla voidaan varmistaa, että tiettyyn IT-projektiin, IT-palveluun tai tietojärjestelmään sijoitetut resurssit tuottavat odotettuja tuloksia odotetulla riskitasolla. Jotta KPI:sta saadaan maksimaalinen hyöty, organisaation tavoitteisiin ja toimintatapoihin kytkeytyvien KPI:den valitseminen ja määrittely tulee tehdä huolellisesti.

Yleisimmin käytössä olevat IT-KPI:t liittyvät kustannus- ja aikatauluseurantaan tai esimerkiksi toimittajasopimusten kriteereihin, kuten tietojärjestelmän palvelutasoon tai tukipalvelun vasteaikoihin. Varsinainen hyöty KPI:sta syntyy laajentamalla mittaristo kattamaan myös tietohallinnon muita tavoitteita sekä määrittelemällä seuranta- ja raportointiprosessi KPI:den ympärille.

KPI:ta voidaan luokitella ylätason kategorioihin esim. IT:n liiketoimintahyödyn (strateginen, taktinen, operatiivinen), IT-elinkaaren vaiheen (konsepti, projekti, palvelu) tai raportin käyttäjän (liiketoimintajohto, IT-johto, IT-päällikkö) mukaan. Organisaation tavoitteita vastaava mittaroinnin kehittämisen painopistealue on hyvä määritellä KPI-kategorian tasolla. Kun fokus on selvillä, olemassa olevia viitekehyksiä ja KPI-kirjastoja voidaan käyttää pohjana organisaatiolle parhaiten sopivien KPI:den määrittelemiseksi.

KPI:t eroavat muusta raportointitiedosta niiden jalostusasteen ja kontekstuaalisuuden kautta. KPI:t jalostetaan saatavilla olevasta tiedosta siten, että ne tiivistävät tietyn toiminnon tavoitteiden kannalta keskeiset tiedon yhteen tai muutamaan arvoon (esim. satojen erillisten numerojen sijaan). Toisaalta, KPI:hin liittyy aina konteksti, joka kertoo onko KPI:n arvo tavoitetason yläpuolella vai alapuolella, ja kuinka paljon (esim. meneekö hyvin vai erittäin hyvin).

KPI:den haasteet liittyvät usein esimerkiksi tiedon laatuun tai mittarointiprosessin jalkauttamiseen. Mittaroinnin keskeisin tavoite on tuottaa tietoa päätöksenteon tueksi. Tätä tavoitetta ei saavuteta, jos KPI-arvot eivät ole uskottavia raportin käyttäjälle (validiteetti) tai luvut heittelevät viikosta toiseen (reliabiliteetti). Tällöin voidaan ajautua tilanteeseen, jossa KPI:t eivät toimikaan tehokkaan viestinnän ja johtamisen välineenä, vaan ovat jatkuvan väittelyn kohteena esimerkiksi niiden vaikean tulkitsemisen tai epäluotettavuuden takia.

Reliabiliteetti ja validiteetti ovat erityisesti haasteena, jos mittarointia lähdetään kehittämään liian massiivisesti (mahdollisimman paljon KPI:ta) tai työkalukeskeisesti (mahdollisimman visuaalisia raportteja). Tällöin oikeiden KPI:den valitseminen ja tehokas raportointi- ja seurantaprosessin jää liian vähälle huomiolle. Lisäksi KPI:iden tulkinnanvaraisuuksia ja keskinäisiä riippuvuuksia ei tällöin useinkaan ymmärretä tarpeeksi hyvin korjaavia toimenpiteitä ja johtamista varten.

Hyvin määriteltyjen ja jalkautettujen KPI:den avulla yritys voi seurata suunnitelmien ja budjettien toteutumista, hallita suorituskykyä ja riskejä sekä varmistaa korjaavien kehitystoimenpiteiden vaikutukset. KPI:sta on suurta hyötyä myös toiminnan tavoitteiden asettamisessa ja viestinnässä IT:n suorituskyvystä organisaatioin eri sidosryhmille.

Tärkeintä on muistaa, että IT:n mittarointiinkin pätee: sitä saa mitä mittaa.

Tietojärjestelmäintegraatioiden ihanuus ja hurjuus

Kaikki nykypäivän tietojärjestelmäkokonaisuudet sisältävät integraatioita useiden eri tietojärjestelmien välillä. Käytännössä tietojärjestelmäintegraatiossa on kyse järjestelmissä olevan tiedon (datan) siirtämisestä järjestelmien välillä tietoverkon avulla. Integraatiossa tieto luetaan ohjelmallisesti lähdejärjestelmästä, jonka jälkeen tietoa voidaan muokata ennen sen tallentamista kohdejärjestelmään.

Integraatioiden avulla useista tietojärjestelmistä koostuva kokonaisuus saadaan tarjoamaan käyttäjilleen haluttu toiminnallisuus. Esimerkiksi verkkopankissa asioidessaan käyttäjän käyttöliittymä integroituu useisiin taustajärjestelmiin, joista yhdessä voi hallita maksuja, toisessa tehdä osakekauppaa ja kolmannessa käsitellä laina-asioita. Lisäksi kaikki edellä mainitut taustajärjestelmät integroituvat tilitransaktioiden hallintajärjestelmään, joka edelleen integroituu mm. vähittäiskauppojen maksupäätteisiin, pankkiautomaatteihin ja toisten pankkien tietojärjestelmiin.

Tietojärjestelmäintegraatiot ovat haastavia, koska integroitavat tietojärjestelmät voivat käyttää samaa tietoa eri tarkoituksiin, käsitellä samaa tietoa eri tavoin ja perustua eri teknologioihin. Halutun kokonaistoiminnallisuuden varmistamiseksi integraatioita toteutettaessa täytyy määritellä:

  1. tietosisällön rakenne (tietomalli, keskinäiset suhteet, attribuutit)
  2. tiedon käsittelysäännöt (tiedon oikeellisuus, omistajuus, transaktiosäännöt)
  3. tiedonsiirron tekniset periaatteet (väylät, standardit, protokollat, tilallisuus)

Esimerkkinä tietosisällön rakenteeseen (kohta 1 yo. listassa) liittyvistä integraatiohaasteista toimii e-reseptin suunnitteluvirhe, jonka takia osa reseptille tarkoitetusta tekstistä voi jäädä puuttumaan reseptiltä. Ongelman syynä lienee, että tietosisältö (mm. tietokenttien pituudet) ei ollut yksiselitteisesti ja yhtenäisesti määritelty kaikille e-reseptin tietoja käsitteleville järjestelmille ja osassa tietoa käsittelevistä järjestelmistä reseptin tekstikenttien merkkimääriä on rajoitettu (ks. YLE). Tästä seuraa, että vaikka lääkäri pystyykin onnistuneesti syöttämään reseptin tiedot järjestelmään käyttöliittymänsä kautta, jossain integraatioketjun vaiheessa järjestelmä ei pystykään tallentamaan tiedosta kuin esim. ensimmäiset 50 merkkiä. Tämän seurauksena apteekin käyttöliittymässä näkyy tietyssä kentässä vain 50 merkkiä.

Esimerkkinä tiedon käsittelysääntöihin (kohta 2 yo. listassa) liittyvistä integraatiohaasteista toimii Puolustusvoimien SAP HR –järjestelmän käyttöönotto puutteellisesti testattuna, jonka takia tuhansien työntekijöiden palkanmaksussa oli virheellisyyksiä ja viivästymisiä. Ongelman syynä lienee, että tiedon käsittelysäännöt (mm. tiedon oikeellisuuden varmistaminen) oli puutteellisesti määritelty ulkoisen tiedon tuonnin kannalta (toisista järjestelmistä), jonka takia uudessa järjestelmässä oli työntekijöiden peruspalkassa, tehdyissä työtunneissa ja pankkitileissä virheellisyyksiä (ks. HS tai Tietokone ). Tästä seurasi, että ajettaessa palkanlaskenta-ajo SAP HR –järjestelmässä tulokset olivat virheellisen tiedon takia väärin, vaikka itse ajon logiikka olisikin oltu testattu toimivan täydellisesti.

Esimerkkinä tiedonsiirron teknisiin periaatteisiin (kohta 3 yo. listassa) liittyvistä haasteista toimii suomalaisten teleoperaattoreiden kapasiteetin, VR:n maksupäätelaitteiden ja maksukorttien EMV-standardin vaatimusten keskinäiset riippuvuudet, jonka takia VR:n päätti lopettaa Visa Electronin hyväksymisen junissa (ks. YLE). Ongelman syynä lienee, että joko Visa Electron-kortille pankin online-tarkistuksen vaativa EMV-standardi tai VR:n maksupäätelaite ei salli sellaisia teknisiä viiveitä (latensseja), pakkausta tai protokollaa, jolla tietojärjestelmäkokonaisuus toimisi varmuudella suomalaisten mobiiliverkkojen kattavuudella ja kapasiteetilla. Tästä seuraa, että Visa Electron ei toimi aina junassa, vaikka tietosisällön rakenne ja tiedon käsittelysäännöt onkin pilkuntarkkaan määritelty.

Riippuen IT-projektista tietojärjestelmien väliset integraatiot saattavat muodostaa jopa puolet projektin kokonaistyömäärästä (verrattuna siihen, että tehtäisiin yksi monoliittinen sovellus, mikä ei usein ole edes käytännössä mahdollista). Siksi on tärkeää, että järjestelmän toiminnalliset vaatimukset ja käyttötapaukset kytketään integraatioiden suunnitteluun jo projektin aikaisessa vaiheessa. Tietojärjestelmäintegraatioissa onnistumisen varmistamiseksi on olemassa lukuisia teknisiä ja metodologisia hyviä käytäntöjä. Mikään ei kuitenkaan korvaa tärkeintä menestystekijää eli avointa, selkeää ja tehokasta osapuolten (usein eri toimittajien) välistä viestintää.

Onko tavoitteenasi IT:n tuottavuus vai tehokkuus?

Edellisessä blogissani kirjoitin IT-hankintojen arvioimisesta kolmen keskeisen kriteerin eli laadun, kustannusten ja riskitason kannalta. Tässä blogissa käsittelen IT:n laatua, jossa voidaan erottaa kaksi ulottuvuutta: tehokkuus ja tuottavuus. Käytännön kannalta voidaan ajatella, että tehokkuus liittyy IT-projektin (= järjestelmän aikaansaamiseksi tehtävä työ) laatuun ja toisaalta tuottavuus liittyy IT-ratkaisun (= tekninen tietojärjestelmä) laatuun.

Ensimmäinen laadun ulottuvuus, tehokkuus, liittyy siihen, että tehtäväksi päätetyt asiat tehdään oikein (”do the things right”). Tehokkuuteen liittyviä käytännön tavoitteita ovat esimerkiksi IT-projektin pysyminen aikataulussa, parhaiden käytäntöjen mukainen tekninen työ (esim. toteutettavan IT-ratkaisun ylläpidettävyys ja skaalautuvuus) sekä riittävä ratkaisun toiminnallisen laadun varmistaminen kattavalla ja järjestelmällisellä testauksella.

Toinen laadun ulottuvuus, tuottavuus, liittyy siihen, että lähtökohtaisesti suunnitellaan tehtävän oikeita asioita (”do the right things”). Tuottavuuteen liittyviä käytännön tavoitteita ovat esimerkiksi IT-ratkaisun toimintojen kattavuus ja helppokäyttöisyys, järjestelmässä käsiteltävän tiedon oikeellisuus sekä investoinnin takaisinmaksuajan (business case) toteutuminen konkreettisten hyötyjen kautta.

Seuraavaksi kaksi projektiesimerkkiä, joista ensimmäisessä on haasteita tehokkuuden ja jälkimmäisessä tuottavuuden kanssa.

Arevan Olkiluotoon rakentama ydinreaktori on myöhästymässä seitsemän vuotta (YLE). Projektin tilanne on seurausta tehokkuuteen liittyvistä laadullisista haasteista. Projektin aikataulu venyy, koska vaadittuja asioita ei ole tehty oikein eli tehokkaasti. Projektin haasteena ei ole varsinaisesti tuottavuus, koska (toivottavasti) projektin tuotoksena lopulta saadaan toimiva ja vaatimukset täyttävä ydinvoimala. Osin nimenomaan tuottavuuteen liittyvän riskin minimointi (eli sen välttäminen, että saadaan epäluotettavasti toimiva ydinvoimala) vähentää tehokkuutta. Näennäisesti projektin kustannusriski on hallittu kiinteähintaisella sopimuksella. Mutta kai tilaajaorganisaation omien resurssien sitominen projektiin suunniteltua pidempään, investoinnin rahoituskustannukset ja menetetty sähkön myynnin liikevaihto maksavat jotakin? Kyllä, TVO:n ja Arevan meneillään olevasta välimiesmenettelystä päätellen noin kaksi miljardia euroa.

Toinen käytännön esimerkki edustaa tuottavuuteen liittyvää laadullista haastetta. Yhdysvalloissa on ollut viime vuosina meneillään mittava armeijan ERP-järjestelmien uudistus. Viimeisimpänä ”virstanpylväänä” voidaan pitää sitä, että ilmavoimat päätti lopettaa projektinsa kesken seitsemän vuoden jälkeen (Tietoviikko). Projektin tilanne on seurausta realisoituneesta tuottavuus-riskistä, mikä on jokaisen projektin tilaajan painajainen: joudutaan palamaan takaisin lähtöruutuun. Ilmavoimien projektin tapauksessa aikaa menetettiin noin 7 vuotta ja rahaa yli miljardi dollaria. Projektin haaste ei ollut, että lopputuloksena olisi saatu laadullisesti huonompi ratkaisu kuin mitä tavoiteltiin, vaan se, ettei saatu yhtään mitään.

Usein tuottavuuteen liittyviin haasteisiin yhdistyy myös tehokkuus-haasteita, mutta ei aina. Se, että projekti ei tuota oikeita tuotoksia, ei tarkoita välttämättä sitä, etteikö tekeminen olisi itsessään voinut olla tehokasta. Esimerkiksi tehokkaasti toteutetut osakokonaisuudet voidaan saada valmiiksi ajallaan (=tehokkaasti) ja tekemään suunniteltuja asioita (=tuottavasti) kokonaisuuden silti toimimatta.

Edellä kerrotut projektiesimerkit ovat äärimmäisiä ja vastaavanlaisia tilanteita kohdataan melko harvoin. Esimerkit kuitenkin auttavat konkreettisesti ymmärtämään tehokkuuden ja tuottavuuden eron. IT-projekteissa tuottavuus on tyypillisesti tehokkuutta tärkeämpää, kun tuotettavan IT-ratkaisun hyödyt ovat merkittäviä (lyhyt takaisinmaksuaika) tai investointi on erittäin suuri (ei varaa epäonnistua). Tehokkuus on puolestaan usein tuottavuutta tärkeämpää, kun projektin tuotos on liiketoiminnan kannalta vähämerkityksellinen (kunhan se toimii) tai projekti nähdään suurena kulueränä (tiukka ja suurehko budjetti).

Helppo nakki: 1,8 miljardin IT-projekti

Pääkaupunkiseudun kunnat ja HUS ovat lyöneet viisaat päänsä yhteen ja alkavat nyt toden teolla valmistelemaan kaikkien aikojen suomalaista IT-hanketta: uutta potilastietojärjestelmää, jonka kokonaisarvoksi on arvioitu Sitran selvityksessä 1,2-1,8 miljardia euroa 10 vuoden ajalle. IT-alan mediassa ja blogeissa hanketta on ihmetelty, ja virkamiesten kunnianhimoisia suunnitelmia on verrattu mm. avaruussukkulan rakentamiseen. Käyn tässä blogissa hanketta läpi kolmen aiemmin esittelemäni IT-hankinnan tyypillisten sudenkuoppien valossa. Sudenkuopat aiheutuvat oikeanlaisen osaamisen ja riippumattoman näkökulman puuttumisesta hankkeen valmistelussa (ks. aiempi blogi Riippuvaisen IT-toimittajan keittokirjasta).

IT-hankinnan 1. sudenkuoppa: monimutkaistaminen

Tässä sudenkuopassa kyse on siitä, että päädytään monimutkaisempaan ja/tai laajempaan ratkaisuun kuin todellisuudessa olisi asiakkaan etu. Potilastietojärjestelmä-hankkeessa monimutkaistaminen on nähtävissä mm. siten, että

  • yksioikoisesti pyritään valmisohjelmiston (COTS) käyttöön arvioimatta niiden soveltuvuutta kokonaisuuden kannalta (kun pitäisi harkita myös vaihtoehtoa kehittää koko ratkaisu tai osia ratkaisusta räätälöitynä ohjelmistokehityksenä)
  • tavoitellaan maantieteellistä (kaikki kunnat) ja 100% toiminnallista kattavuutta alusta asti (kun pitäisi aloittaa ratkaisun pilotoinnilla yhdessä kunnan osassa / rajatulla toiminnallisuudella, ja laajentaa siitä)

IT-hankinnan 2. sudenkuoppa: vähättely

Tässä sudenkuopassa kyse on siitä, että projektin aikataulua ja/tai budjetin arvioinnissa tehdään vääriä arvioita ja päätöksiä ilman perusteita. Potilastietojärjestelmä-hankkeessa arviointivirheet ovat nähtävissä mm. siten, että

  • hankkeen suurta budjettia perustellaan vertaamalla sitä Suomen terveydenhuollon kokonaiskustannuksiin (kun pitäisi arvioida hanketta itsenäisesti top-down ja bottom-up sekä benchmarkata muihin vastaaviin IT-hankkeisiin)
  • vertailut Viroon, jossa vastaavia hankkeita on tehty muutamien kymmenillä miljoonien euron budjeteilla teilataan epäsopivina (kun pitäisi ymmärtää, että Virosta voitaisiin oppia parhaita käytäntöjä lain, toimintatapojen, toimittajien arvioinnin ja hankejohtamisen suhteen).

IT-hankinnan 3. sudenkuoppa: osaamisharha

Tässä sudenkuopassa kyse on siitä, että projektin vaatimaa osaamista arvioidaan väärin perustein ja projektiorganisaatio resurssoidaan tekijöillä, joilla ei ole tarpeeksi tai oikeanlaista osaamista projektin läpi viemiseksi. Potilastietojärjestelmä-hankkeessa arviointivirheet ovat nähtävissä mm. siten, että

  • hankkeen ohjaus on hajautettu kuntien terveyslautakuntiin ja hankejohtajana toimii lääketieteen tohtori, jonka tausta on terveysasemien operatiivisella puolella (kun valtion pitäisi ottaa hanke keskitettyyn ohjaukseen ja resurssoida projektitoimisto osaavilla tietohallinnon, toimialan prosessien ja tietojärjestelmäkehityksen ammattilaisilla).
  • ratkaisun pohjaksi vahvimpana kandidaattina oleva Epic-ohjelmisto perustuu 60-luvulla kehitettyyn MUMPS-ohjelmointikieleen, joka on rakenteeltaan monimutkainen, ohjelmointiprosessiltaan vanhanaikainen ja jonka osaamista ei ole Suomessa, eikä sitä ole järkevää hankkia (kun pitäisi harkita modernimpia esim. J2EE tai .NET-pohjaisia teknologioita).

Lopuksi

Julkisuudessa esitettyjen tietojen valossa täytyy valitettavasti todeta, että hyväntahtoisimmankin mahdollisen arvion perusteella Suomen potilastietojärjestelmä-hankkeeseen liittyy erittäin todennäköisiä ja vaikutuksiltaan katastrofaalisia riskejä. Esimerkiksi Iso-Britanniassa terveysministeriö kuoppasi viime syksynä vastaavanlaisen hankkeen sen jälkeen, kun siihen oli käytetty 10 vuotta ja yli 15 miljardia euroa. Mutta: mitä isot edellä, sitä pienet perässä!

Suurtenkaan tietojärjestelmähankkeiden toteuttaminen ei ole mahdotonta, mutta se on haastavaa. Tärkeintä on tehdä hankkeen valmistelutyö hyvin, määritellä projektin laajuus yksiselitteisesti tavoitteiden mukaiseksi, suunnitella projektin aikataulu ja tuotokset realistisesti sekä löytää projektiorganisaatioon oikeanlaista osaamista kuhunkin rooliin. Aloittaminen pilotoimalla ratkaisua paikallisesti, ratkaisun iteratiivinen kehitys ketterillä menetelmillä (agile), jämpti projektin laajuuden hallinta (scope management), keskitetty projektiohjaus sekä oikeaoppinen toimittajien työn johtaminen ja laadunhallinta takaavat suurenkin projektin onnistumisen. Näiden saavuttamisessa kokenut ulkopuolinen neuvonantaja voi olla tarpeen.