Älä osta sikaa paperilla
Me suomalaiset olemme hieman naiivia kansaa. Jos jotain on kirjoitettu paperille, niin oletamme sen olevan totta. Kun IT-hankkeen sopimukseen kirjoitetaan että halutuilla ominaisuuksilla varustettu järjestelmä on käyttökunnossa sovittuna päivänä, niin meillä on tapana uskoa tähän. Todellisuudessahan on ihan sama mitä sinne sopimuspaperiin on kirjoitettu, niin IT-hanke menee usein kiville.
Olen todistanut toistuvasti tilanteita, missä IT-projektin alussa on myyty epärealistinen sopimus, jossa luvataan kuu taivaalta. Sopimukseen on usein kirjattu erilaisia rangaistuksia ostajan mieltä rauhoittamaan. Todellisuudessa, sitten kun projekti on ajettu kiville, ei käytännössä kuitenkaan ole muuta tehtävissä, kuin jatkaa projektia. Rangaistusten käyttäminen olisi niin työlästä, että on helpompi vain yrittää puskea projekti maaliin. Rangaistukset ajaisivat pahimmillaan vain toimittajan konkurssiin. Tämähän ei ainakaan nopeuttaisi järjestelmän valmistumista. Usein ei myöskään paljon hidastaisikaan.
Väitän että alusta asti win-win ajattelulla prosessiin sisäänrakennettu läpinäkyvyys vie pidemmälle kuin vanhakantainen tiukka sopimusneuvottelu. Kokemuksen syvällä rintaäänellä väitän, että ajattelu lähtee luisumaan jommalle kummalle uralle heti tarjousprosessista alkaen. Väitän myös että kulttuurimuutoksen win-win ajatteluun ja läpinäkyvyyteen voi ostaa organisaatioon ulkopuolelta ulkopuolisen konsultin muodossa, ellei oma organisaatio siihen taivu. Ulkopuolinen pystyy ravistelemaan organisaatiota rohkeammin ja objektiivisemmin.
Ostoprosessi
Tietojärjestelmäprojekti ostetaan usein samalla kaavalla: Ylempi johto luo uuden bisnesvision, keskijohto kerää jonkinlaisen vaatimuslistan uudelle järjestelmälle ja hankintaosasto pyytää tarjousta tutuista IT-yrityksistä. Vastapuolella, tarjouksen antavassa yrityksessä, myyjä antaa vapaalle projektipäällikölle tehtäväksi arvioida paljonko työtä projekti vaatii. Tämän pohjalta myyjä hinnoittelee hankkeen toteutuksen ja jättää tarjouksen. Lopuksi tilaaja valitsee usein halvimman tarjouksen.
Projektipäällikön näkökulmasta tätä yleistä ostotapaa voi lähestyä karrikoiden kolmesta tulokulmasta, jotka esittelen seuraavissa kappaleissa.
1. Myy halvalla ja tinkaa jatkoa
Tämä perälauta-malli on klassinen toimintatapa, joka tuottaa kaikille osapuolille pahaa mieltä ja harmaita hiuksia. Tässä mallissa annetaan niin halpa tarjous, että asiakas ei voi olla tarttumatta siihen. Tämän jälkeen hankkeessa koodataan paljon, dokumentoidaan vähän ja käytetään yleisesti alhaisen kypsyystason systeemityömallia. Projekti ajetaan tietoisesti tai vahingossa sekä aikataulun että työmäärien puolesta perälautaan. Tämän jälkeen alkaa toimintamallin työläin vaihe. Kun aikataulu ja budjetti on käytetty, niin ensin etsitään syyllistä arvioiden ylittymiselle. Seuraavaksi pohditaan, onko projektille mahdollista ostaa pieni jatko-osa, jolla projekti saadaan pelastettua. Sillä ”Eihän jo tehtyä kallista koodia kannata hukkaankaan heittää”. Tämä työläs ja riitainen syyllisen etsimisen ja toistuvien jatkomaksujen vaihe jatkuu, kunnes hanke saavuttaa riittävän toiminnallisuuden tai hanke viimein lopetetaan rohkeasti kesken. Käytännössä toteutuneet hinta, aikataulu ja vaatimukset ovat muuta kuin mitä alun perin tarjottiin.
2. Myy puskuria
Laadukasta työtä tekevä IT-talo harvoin tekee halpaa tarjousta. Sen sijaan he pyrkivät tekemään realistisen tarjouksen. Sekä tarjous että siihen vastaava tarjouspyyntö kuvaavat lähes poikkeuksetta vain pienen osan järjestelmän todellisesta, lopullisesta toiminnallisuudesta. Ylätason vaatimukset kattavan tarjouspyynnön laatimisen yhteydessä unohdetaan usein kokonaisia käyttäjäryhmiä, puhumattakaan teknisemmistä ei-toiminnallisista vaatimuksista. Puskurin myymisellä pyritään ennakoimaan nämä tarjouspyynnöstä puuttuvat näkökulmat ja hinnoittelemaan projektin aidosti sille tasolle, mitä järjestelmän valmiiksi saattaminen oikeasti vaatii. Emme tiedä miten hanke etenisi käytännössä, koska tämä hanketarjous ei koskaan voita.
3. Myy ketteryyttä
Ketterässä ajattelussa myönnetään heti kärkeen että sen paremmin tarjouksen pyytäjä, kuin tarjouksen jättäjäkään, eivät pysty nykytiedon valossa arvioimaan hankkeen todellista laajuutta. Tämän vuoksi käytetään vaiheittaista projektimallia, jossa projektitiimi tekee muutaman viikon etapeissa järjestelmän toteutusta tiiviissä yhteistyössä tilaajan ja loppukäyttäjien kanssa. Joka etapista valmistuu demo, joka toteuttaa osan vaatimuksista. Vaatimukset toteutetaan korkean kypsyystason systeemityömallilla, niin että kokonaisuus on versiohallittu ja dokumentoitu. Kunkin etapin hinta ja etapissa valmistuneet vaatimukset ovat kaikille täysin läpinäkyviä. Hankkeen todellinen valmistumisvauhti ja suunta ovat läpinäkyviä niin asiakkaalle kuin toteuttavalle osapuolellekin. Ellei etapista tule jostain syystä mitään valmista pihalle, niin nopeus on asiakkaan näkökulmasta 0. No excuses. Hanke voidaan milloin vain lopettaa tai siirtää toiselle toimittajalle.
Sitoudu joustavuuteen
Tilanne ei ole todellisuudessa näin mustavalkoinen. Ketteryyden etuja voidaan hyödyntää, vaikka projekti haluttaisiinkin ostaa staattisella aikataululla ja hinnalla. Voidaan laatia ketterä tarjous, jossa vaatimukset priorisoidaan niihin jotka on pakko saada ja niihin jotka olisi hyvä saada. Ensimmäisten etappien vauhti antaa projektin alussa suuntaa siitä, minkä verran ominaisuuksia annetulla budjetilla ehditään toteuttamaan. Tämän pohjalta voidaan hienosäätää alussa annettuja prioriteetteja. Avoin keskustelu vaatimusten prioriteeteista toimittajan ja asiakkaan välillä on tärkeää. Alla olevaan listaan on hahmoteltu esimerkinomaisesti tasoja, joilla vaatimuksia voi hankkeen alussa jaotella. Jo yksinkertainen priorisointi avaa arvokkaan keskusteluyhteyden toteuttajan ja tilaajan välille vaatimusten riippuvuuksista, aikatauluista ja pidemmän aikavälin tavoitteista.
- Alfa 0.1: Teknologiademot asiakkaalle uusista sovellustavoista
- Beta 0.5: Arkkitehtuuridemot, joissa toiminnallinen ja ei-toiminnallinen perustoiminnallisuus todistettavasti toteutettu
- Tuotanto 1.0: Tärkeimpien käyttäjäryhmien tärkeimmät toiminnot
- Tuotanto 1.1: Kaikki ”pakolliset” toiminnot, joita ei vielä ole aivan pakko saada 1.0 versioon
- Tuotanto 2.0: Spekulatiiviset vaatimukset, jotka elävät voimakkaasti, eivätkä sellaisenaan välttämättä toteudu koskaan.
Kaikki alkaa tarjouspyynnöstä
Vai alkaako sittenkään? Tarjousprosessi määrittää hankkeen onnistumisedellytykset. Tarjousprosessin tavoitteena on hankkia oikeita asioita, oikealla tavalla. Tarjousprosessin aikana voidaan sitoa sellaisia muuttujia, jotka ajavat hankkeen myöhemmin karille. Prosessissa voidaan myös jättää sopimatta joitain, hankkeen onnistumisen kannalta elintärkeitä asioita. Jo ennen tarjouspyyntöä tulee tunnistaa muutoksen tavoitteet ja vasta sitten lähteä pohtimaan teknisiä vaatimuksia. Harvalta ihmiseltä löytyy kaikkea tarjousprosessin vaatimaa osaamista. Prosessi vaatii aina yhteistyötä; Organisaation sisäistä yhteistyötä ja yhteistyötä toimittajakandidaattien kanssa.
Yhteenveto
Artikkelin on tarkoitus rohkaista avoimeen kommunikaatioon IT-hankinnoissa. Tarjouksen sparraaminen mahdollisten toimittajien kanssa lisää kaikkien osapuolien ymmärrystä tavoitteista, tarpeista ja toteutusvaihtoehdoista. Paras tapa varmistaa hankkeen onnistuminen niin aikataulun, budjetin kuin vaatimusten suhteen, on aloittaa hanke laadukkaalla tarjousprosessilla. Usein on perusteltua käyttää ulkopuolista konsulttia jo tarjousprosessin läpiviennissä. Ulkopuolinen henkilö tuo objektiivista osaamista ja kokemusta, sekä uskaltaa haastaa mahdollisia haitallisia toimintatapoja ja ajatusmalleja puolin ja toisin. Toisaalta, on myös olemassa paljon esimerkkejä pelastetuista IT-hankkeista, joissa toimittajan vaihto on tehty vasta kun alkuperäinen sopimus on ajettu kiville. Avoin tosiasioiden tunnistaminen ja nopea, ketterä päätöksenteko ovat nykyaikaisen johtamisen peruskiviä.
