Miten ketterä IT-projekti ostetaan? Lue, mitkä näkökulmat on syytä ottaa huomioon ketterän kehityksen ostamisessa, jotta vältät pahimmat sudenkuopat.
Yritysten toimintaympäristö ja asiakkaiden tarpeet ja arvostukset muuttuvat jatkuvasti eikä tämän muutoksen vauhti ole hidastumassa. Niinpä IT-järjestelmiä ja digitaalisia palveluita kehitetään yhä enemmän ketterän kehityksen malleilla (agile, scrum...), jolloin pystytään vastaamaan liikkuvan maalin haasteeseen paremmin kuin vesiputousmallisella projektilla. Vesiputousmallilla tarkoitetaan perinteistä tiukasti vaiheittaista toteutusmallia: ensin suunnitellaan, sitten toteutetaan, testataan ja lopuksi toimitetaan.
Ketterä kehittäminen on kehittäjien näkökulmasta jo paikkansa lunastanut: se on normaali tekemisen moodi, arkea ja tuttua. Organisaatioiden ostajien kohdalla asennemuutos tai sukupolvenvaihdos on edennyt hitaammin, sillä edelleen tulee vastaan tapauksia, joissa ketterää kehittämistä halutaan ostaa vesiputousmallin sopimuksilla ja käytännöillä. Nuo hyviksi havaitut vesiputousmallisten projektien ostokäytännöt eivät valitettavasti päde ketterän kehityksen ostamiseen. Alla on muutama näkökulma ketterän kehityksen ostamiseen ja pahimpien sudenkuoppien välttämiseen.
Heti alkuun on oleellista ymmärtää, ettet ole hakemassa IT-toimittajaa vaan yhteistyökumppania IT-projektisi toteutukseen. Niinpä liikkeelle kannattaa lähteä perusasioista, joilla varmistetaan pohja menestykselliselle yhteistyölle projektissa:
Mitä enemmän toimittajalta löytyy referenssejä vastaavista ratkaisuista sitä parempi, aivan kuten vesiputousprojektienkin maailmassa. Ketterää kehitystä ostettaessa yhteistyöllä on entistäkin voimakkaampi painotus ja siksi referenssejä tarkistettaessa tulee pyrkiä selvittämään myös yhteistyönäkökulmaa: miten helppoa ja kitkatonta yhteistyö toimittajan kanssa on tai ei ole ollut.
Ketterä kehittäminen tapahtuu tiiviissä yhteistyössä toimittajan projektitiimin kanssa. Tästä syystä henkilövalintoihin tulee kiinnittää suurempaa huomiota kuin vesiputousmallin (melko kasvottoman) toimittajan projektitiimin tapauksessa. Tarjottujen projektihenkilöiden haastatteleminen ei ole yliampuvaa varmistelua, vaan päinvastoin järkevää tutustumista tuleviin yhteistyökumppaneihin, millä pyritään varmistamaan toimivat kemiat ja kommunikaatio. Tässä, kuten missä tahansa rekryhaastattelussa, pitää muistaa, ettei supliikki ja sulava käytös ole tae kehittäjän osaamisesta tai tehokkuudesta. Kannattaa myös varmistaa, että tarjottu tiimi on ainakin osittain ollut toteuttamassa tärkeimpiä edellisessä kohdassa mainittuja referenssitoimituksia.
Tuntihinnan tarkistus on sanity check, joka tulee tehdä varhaisessa vaiheessa toimittajavalintaa. Tämä siksi, että hinnan rooli sopimusneuvotteluissa on ketterän kehittämisen tapauksessa vanhaa mallia pienempi: valituksi ei enää tule se toimittaja, jolta saadaan puristettua matalin kiinteä hinta projektin toteutukselle. Tuntihintaa arvioitaessa kannattaa miettiä, miten se vertautuu muihin tarjoajiin sekä toimittajan ja tarjotun projektitiimin kyvykkyyksiin ja vahvuuksiin. Hyvin yhteenpelaavan tiimin tehokkuus voi olla moninkertainen heikompaan verrattuna.
Kun potentiaalinen yhteistyökumppani on löytynyt ja päästään sopimusneuvotteluihin, tulee edelleen pitää mielessä, että tavoitteena on toimiva ja saumaton yhteistyö. Voittaja ei ole se, joka saa kiristettyä vastapuolelta itselleen paremman sopimuksen, vaan voittajia ovat sopimuksen molemmat osapuolet, kunhan sopimuksella onnistutaan varmistamaan toimiva yhteistyö ja projektille onnistunut lopputulos.
Tämä on toivottavasti vain hygieniatekijä, mutta tärkeä sellainen. Ketterän kehityksen projektille ei useinkaan ole järkevää asettaa kiinteää hintaa tai kattohintaa, etenkin jos projektin laajuus (scope) on kiinteä, esimerkiksi toimiva palvelu. Selkeä exit-klausuuli onkin ostajan paras pelastusrengas silloin, kun asiat menevät pieleen: aikaa kuluu, mutta toteutus ei etene tai tulosten laatu ei tyydytä ostajaa. Jos yhteistyökumppaniksi valittu toimija ei syystä tai toisesta ole tehtäviensä tasalla, niin paras vaihtoehto on myöntää virhevalinta ja viheltää peli poikki mahdollisimman pikaisesti.
Ketterässäkin kehittämisessä pitää tehdä valintoja ja priorisointia projektin laajuuden (scope), toteutuksen laadun, aikataulun ja hinnan välillä. Kaikkia neljää ei voi maksimoida samaan aikaan, ja koska laadusta tinkiminen ei yleensä ole voittava vaihtoehto, jäljelle jäävät laajuus, aikataulu ja hinta. Toimittajayhteistyön varmistamisessa yhteinen ymmärrys tavoitteista on isossa roolissa. Niinpä nämä priorisoinnit tai sidotut asiat (esim. aikataulu, hinta) kannattaa viestiä avoimesti ja kirjata sopimuksiin: tavoitteiden saavuttamista auttaa se, että tavoitteet ovat kaikille osapuolille kirkkaita.
Jo sopimuksessa tulee huomioida tiedonkulun varmistaminen: palaveri- ja viestintäkäytännöt. Tavoitteena on aito yhteistyö ja luottamus eri osapuolien välillä. Näiden tavoitteiden toteutumista tukee täysi läpinäkyvyys projektin edistymiseen ja tilanteeseen, niin voittoihin kun haasteisiinkin.
Loppuun vielä muutama tunnistettu sudenkuoppa: ei näin. Moni tämän listan asioista on mainittu käänteisenä jo ylläolevissa suosituksissa, mutta kieltolauseiden kautta asiat saavat vielä lisää konkretiaa.
Ketterää ostamista!