Ketterän kehittämisen ostamisen dos and don’ts

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.

Toimittajan valinta

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:

1. Toimittajan referenssit

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.

2. Tarjottu projektitiimi

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.

3. Toimittajan (tunti)hinta

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.

Sopimusasiat – huomioi erityisesti nämä

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.

1. Sopimuksen exit-pykälä

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.

2. Tavoitteiden ja priorisoinnin selkeys

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.

3. Tiedonkulun ja aidon yhteistyön varmistaminen

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.

Sopimusasiat – ei näin

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.

• Sopimuksessa ei voi naulata kiinni kaikkia seuraavista kolmesta: laajuus, aikataulu, hinta. Jos näin tehdään, niin kysymyksessä ei enää ole toteutus ketterillä menetelmillä. Lisäksi näin toimittaessa ainoaksi joustavaksi tekijäksi jäi toteutuksen laatu, mikä tuskin johtaa hyvään lopputulokseen.
• Kiinteä hinta tai sen variaatiot, esim. tavoitehintamalli tai kattohintamalli, toimivat ketterän kehittämisen ostamisessa vain, jos toteutuksen laajuus on avoin. Näin ei useimmiten ole, vaan projektin tavoitteena on tuottaa toimiva palvelu tai toimiva ratkaisu tiettyyn tarpeeseen.
• Tavoiteasetanta ja määrittely tulee pitää selkeästi erillään. Projektilla tulee olla selkeät tavoitteet, jotka voidaan varmistaa/tarkentaa esimerkiksi projektin alkuun sijoittuvassa ”0-sprintissä”. Kattavaa määrittelyä sen sijaan ei kannata tehdä ennen hankintaan ryhtymistä tai projektin ensimmäisenä vaiheena: määrittely sisältyy ketterän kehityksen sprintteihin. Tekemällä määrittely paloissa juuri ennen kyseisen kohdan toteutusta taklataan liikkuvan maalin ongelma ja pidetään ovi auki tarpeiden tai näkemyksen muuttumiselle niin pitkään kuin mahdollista. Määrittelyn lisäksi sama pätee testaamiseen ja hyväksyntään: niitä ei tule suunnitella projektin viimeisiksi vaiheiksi toteutuksen jälkeen, vaan myös ne kannattaa tehdä paloissa (sprinteissä) toiminnallisuus kerrallaan.

Ketterää ostamista!