Osaatko tehdä projektille hyvän lähdön? 5 hyödyllistä ohjetta tietojärjestelmäprojektia suunnittelevalle tilaajalle!
Kokemukseni mukaan projektin kohtaloa maalataan isolla siveltimellä sen alkumetreillä ja tai jo silloin kun varsinainen projekti ei ole vielä alkanutkaan. Ratkaisevia projektin onnistumiseen vaikuttavia asioita linjataan jo hankinnan suunnittelun aikana ja hankintaprosessissa.
1. Pilko ja paloittele! Vältä liian monimutkaisia kokonaisuuksia!
Monesti tilaajaorganisaatiossa ajatellaan, että järjestelmäprojektin sisällöksi on väistämättä otettava valtavan suuri kokonaisuus. Monesti uskotaan, ettei kokonaisuutta vain voi pilkkoa pienemmiksi osa-kokonaisuuksiksi. Mieli voi kuitenkin muuttua viimeistään silloin kun projekti on ajautunut monimutkaisuuden vuoksi karikolle. Silloin huomataan pakon edessä, että kokonaisuutta voi sittenkin paloitella pienempiin ja paremmin hallittaviin osiin.
Usein asiantuntijat ovat tottuneet ajattelemaan kokonaisuuksia tietyllä tavalla eivätkä hahmota, että muitakin lähestymistapoja voi olla. Joskus voidaan ajatella, ettei paloittelua voida tehdä asiakaskokemuksen heikentymisen vuoksi. Joskus taas koko toimituksen sisällön mietintä tai hankintaa edeltävä vaatimusmäärittely on jäänyt kokonaan tai osittain tekemättä.
Mitä monimutkaisempi projektin kohteena oleva alue on, sitä tärkeämpää kokonaisuuden osittaminen onnistumisen kannalta on. Monimutkaista suurta kokonaisuutta on vaikea hallita jo yksinkertaisesti sen vuoksi, että sisällöllisiä riippuvuuksia on vain liikaa ja korttitalo romahtaa pienestäkin iskusta. Siksi projektitoimituksen hankintavaiheessa sisältöä suunniteltaessa kannattaa kiinnittää paljon huomiota siihen, miten kokonaisuuksia voi pilkkoa pienempiin osiin. Kunnollinen vaatimusmäärittely ja arkkitehtuurisuunnittelu kannattaa ja maksaa itsensä takaisin. Jos oma osaamien organisaatiossa ei riitä tällaiseen suunnitteluun, tähän on ehdottomasti rahanarvoista hankkia ulkoista apua.
2. Hyvää ja käsittämättömän halpaa tietojärjestelmäprojektia ei ole olemassa!
Olen nähnyt useat kerrat, kun asiakas on valinnut halvimman tarjouksen, mutta päätynyt maksamaan siitä lopulta huomattavasti enemmän kuin kalleimman tarjouksen hinta olisi ollut. Pelkästään hinta toimittajan ja toimituksen valinnassa on erittäin huono valintakriteeri.
Tarjouspyyntöjen analysointi on vaihe, joka kannattaa ottaa asiaankuuluvalla vakavuudella. Kun mietit toimituksen hintaa, yritä ymmärtää varsinaisen sisällön ja sen kattavuuden lisäksi hinnoittelun perusteet, toimittajan motiivit ja syyt siihen, miksi toimitus on halpa. Älä sumeilematta usko, että toimittaja on tehnyt emämunauksen ja tarjoaa nyt niin halvalla, että tilaisuuteen on pakko tarttua. Toimittaja ei ehkä ole tehnytkään emämunausta. Ehkä toimittaja laskee, että raha tulee myöhemmin muutospyynnöistä tai vaikka ylläpidosta. Tilaajan kustannukset tulevat nousemaan jotain kautta joka tapauksessa. Jos taas toimittaja on tehnyt emämunauksen, ja hinnoittelee toimituksen liian paljon kilpailijoita halvemmaksi, voi kyse olla vakavasta toimittajan osaamattomuudesta. Osaamattomuus taas on vaarallista eikä osaamattomuuden vaikutuksia kannata milloinkaan aliarvioida. Osaamattomissa käsissä projektitoimitus venyy ja sitä kautta koko projektin hinta nousee usein vielä hallitsemattomasti. Hinta on asia, johon kannattaa suhtautua suurella kriittisyydellä.
3. Älä säästä väärästä kohdasta!
Kun tuntuu, että kaikki tietojärjestelmäprojektissa ja hankinnassa on niin kovin kallista, ryhdytään yleensä säästämään jo hankintavaiheessa. Pienistä säästämisen puroista syntyy suuri virta, näin uskotaan. Yleensä säästetään projektinhallinnasta, ehkä määrittelystä, ehkä testauksesta tai käyttöönotosta. Näistä on kohtalaisen helppo karsia osuuksia vielä hankintavaiheessa. Mutta valitettavasti näistä säästämisen puroista syntyvä virta keikuttaa kaarnaveneen vaarallisille vesille. Näillä säästöillä karsitut työt on tavalla tai toisella kuitenkin tehtävä. On illuusio, että voidaan säästää välttämättömistä asioista kuten testauksesta. Heikosta testauksesta syntyy huonoa laatua, joka voi johtaa viiveeseen käyttöönottovaiheessa. Vielä pahempaa ja kalliimpaa on, jos puutteellisen testauksen seuraukset näkyvät vasta tuotannon häiriöinä. Fakta kuitenkin on, että tekemätön työ näkyy aina jossain ja valitettavasti huonosta laadusta kärsii viime kädessä aina tilaaja.
Suosittelen harkitsemaan tarkkaan, mistä asiasta kannattaa säästää. Kustannusten ollessa ohjaava tekijä, on mielestäni parempi rajata kokonaisuus laajuudeltaan mahdollisimman pieneksi ja tehdä se kunnolla.
4. Sopimus ei ole vakuutus!
Moni varmasti haluaisi ostaa vakuutuksen, joka turvaisi tietojärjestelmäprojektin onnistumisen. Joskus tuntuu, että projektin toimitussopimuksien toivotaan olevan se vakuutuskatalogista puuttuva tietojärjestelmäprojektivakuutus. Sopimuksia väännetään osapuolten taitavien juristien kesken joskus kuukausia ja sopimusneuvotteluissa osapuolet pyrkivät usein aggressiivisesti puolustamaan omia etujaan. Silti en ole koskaan nähnyt tilannetta, jossa sopimus olisi suojannut projektin epäonnistumiselta tai epäonnistumisesta johtuvilta kustannuksilta. Sopimus ei ole vakuutus.
Usein sopimusta laatiessa ei ole riittävää ymmärrystä siitä, mikä projektin tarkka sisältö tulee olemaan. Kuitenkin sopimuksessa pyritään suojaamaan osapuolten oikeuksia tyypillisesti hyvin tarkalla tasolla. Varsinkin ketterät toimitusprojektit tuovat sopimuksiin aivan uuden haasteen. Lopputulokset ja tuotokset kun eivät ketterässä toimintatavassa ole suunnitteluvaiheessa edes tiedossa. Sopimuksiinkin tarvitaan ketterässä maailmassa joustavuutta.
Yleisesti ottaen menetelmästä riippumatta sopimus olisi hyvä nähdä toimituksen win-win asetelman varmistavana dokumenttina eikä oman edun tavoitteluna tai vakuutuksena. Se luo terveen pohjan toimitukselle ja luo todellisia onnistumisen edellytyksiä. Jo sopimusvaiheessa syntyvä voittaja häviäjä asetelma tuo riskejä toimitukselle. Onnistuminen syntyy parhaiten yhteispelillä, läpinäkyvyydellä, avoimuudella ja sillä, että kaikilla osapuolilla on mahdollisuus onnistua.
5. Älä yliarvioi oman organisaatiosi resursseja ja kyvykkyyttä!
Kun suunnittelet tietojärjestelmähanketta tai projektia, arvioi realistisesti oman organisaation voimavarat. Vaikka projektin toimitus ostetaan muualta, ei toimittaja milloinkaan tee kaikkea työtä. Tilaajaorganisaation edustajilta vaaditaan osallistumista ja osaamista sekä yhä useammin vahvaa muutosjohtamiskykyä.
Osaaminen tietojärjestelmäprojektissa on tyypillisesti erilaista kuin linjatöissä. Tarvitaan ihmisiä, jotka toisaalta ymmärtävät oman liiketoiminnan ja järjestelmät, mutta toisaalta ymmärtävät miten tietojärjestelmäprojektissa toimitaan. Tarvitaan esimerkiksi määrittelijöitä ja testaajia, useiden toimittajien työn koordinoijia sekä ohjausryhmän jäseniä. Tyypillisesti tarvitaan ihmisiä, joilla on kyvykkyyttä irtautua vanhasta ja ajatella uudella tavalla. Tarvitaan myös johtajia, jotka kykenevät muutosjohtamiseen ja nopeaan päätöksentekoon. On hyvä arvioida jo hyvissä ajoin, mitkä ovat oman organisaation taidolliset valmiudet tietojärjestelmäprojektiin osallistumiseen.
Projektin osallistumiseen suhtaudutaan joskus yliolkaisesti. Ajatellaan, että tilaajaorganisaation asiantuntijat pystyvät hoitelemaan projektitoimituksen vaatimat tehtävät ”vasemmalla kädellä” omien töiden ohessa. Todellisuudessa panostus tietojärjestelmäprojektiin voi olla yllätys. Panostusta ja osaavia tekijöitä tarvitaankin paljon enemmän kuin oli kuviteltu. On hyvä olla realisti ja budjetoida jo suunnitteluvaiheessa riittävästi myös sisäiseen työhön projektitoimitukseen liittyen. Joskus viisas valinta on jo etukäteen kasvattaa omaa organisaatiota tulevan projektin tarpeisiin sopivaksi tai varautua konsulttiavun hankkimiseen.