Ajankohtaista

Myytti 2 - Kiinteähintainen sovelluskehitysprojekti on paras

Kirjoittanut Alfame | 14.10.2015

Yleisesti ajatellaan, että kiinteähintainen sovelluskehitysprojekti on paras vaihtoehto ostajalle. Nykyään useimmiten ostetaan ketterää toimintamallia, joka on liki de facto -standardi sovelluskehityksessä. Ketteryyden edut ovat kiistattomat, kuten nopea arvontuotto ja joustavuus muuttuvia tarpeita kohtaan. Ketteryyden taloudellista riskiä pyritään minimoimaan kiinteähintaisella vaatimuksella. Mutta onko kiinteähintaisuus ostajalle oikeasti paras vaihtoehto?

Ketterissä projekteissa taloudellinen puoli koetaan kuitenkin usein haasteelliseksi tyyliin

Kuin avoimen shekin myöntäisi.

Projekti jatkuu ja jatkuu, ja rahaa on mennyt jo vaikka kuinka paljon!

Ketterään kehitykseen tarvitaan luottamus ostajan ja toimittajan välille. Kun tätä ei vielä ole syntynyt, pyritään taloudellista riskiä minimoimaan kiinteähintaisella vaatimuksella. Mutta onko kiinteähintaisuus ostajalle oikeasti paras vaihtoehto?

Kiinteähintaisuus ostajan silmin

Ostaja tavoittelee kiinteällä hinnalla yksinkertaisesti sitä, että haluttuun ratkaisuun päästään budjetilla, joka ei ylity. Ajatus on tietenkin taloudellisen riskin minimoinnissa. Jos (ja kun) toimittajat toteuttavat ohjelmistoja nykyään ketterällä mallilla, niin tällöinhän tarjoukset annetaan yleensä tyyliin: ensimmäisille sprinteille tarkemmat työmääräarviot ja kokonaisuudelle hahmotelma ja budjetäärinen karkea arvio, riippuen toki projektin koosta. 

Ostajan vaatiessa kiinteähintaista budjettia tämän odotetaan tarkoittavan, että edellä mainitut arviot vain muutetaan kiinteäksi budjetiksi. Mutta avataanpa vähän mitä kiinteähintaisuuden vaatimus todellisuudessa tarkoittaa.

Kiinteähintaisuus toimittajan silmin

Myönnetään, kiinteän hinnan vaatiminen (ketterältä) ohjelmistotoimittajalta, nostaa yleensä niskakarvat pystyyn. Tämä ei niinkään johdu siitä, että riskikin kasvaa toimittajalla, vaikka tämäkin toki vaikuttaa. Suurin syy on kuitenkin se, että kiinteähintaisuus minimoi jo vaatimushetkellä ketteryyden olennaiset edut.

Jotta tarjous voidaan tehdä kiinteähintaisena, on vaatimukset pyrittävä määrittämään niin tarkkaan kuin pystyy etukäteen ja sitten ne on lukittava. Vesiputousmalli, poteroissa koodaaminen, byrokraattinen yhteistyö ja satasta puuta päin... tervemenoa!

Ohjelmistotoimittajat tietävät, että ohjelmistokehitys ei vain pelaa niin, että aluksi pystyttäisiin tietämään kaikki mahdollinen mitä tullaan haluamaan ja tarvitsemaan ohjelmistolta. Tarkoitushan ketterässä kehityksessä juuri on, että saadaan nopeasti näkyvää ja arvoa tuottavaa aikaan, että pystytään tarkentamaan tarpeita ja tekemään muutosliikkeitä ajoissa. Ja jos kiinteähintaisuutta vaaditaan, edellä mainitun tietäen, lisätään tarjoukselle helposti reilulla kädellä ”riskikerrointa” (eli kustannukset kasvavat). Mikä ei sekään takaa, että projektista tulee loppupelissä kannattavaa toimittajallekaan.

Mitä kiinteällä hinnalla saadaan?

Kiinteähintaisella projektilla saadaan siis alkuperäisten speksien mukainen ratkaisu sovitulla taloudellisella panostuksella.

Käytettävälle rahalle ei kuitenkaan saada todennäköisesti samaa vastinetta kuin toteutuneen työmäärän mukaisesti määräytyvällä investoinnilla, sillä:

  • Kiinteähintaisessa pitää rahallisen satsauksen sisältö määritellä etukäteen. Se on ”luonnotonta” arvontuottoon fokusoituneessa ja muuttuvan maailman huomioivassa ketterässä ohjelmistokehityksessä. Näin arvontuoton täsmentäminen muutoksilla matkan varrella on vähintäänkin haastavaa.
  • Kiinteään hintaan lisätään ”bufferia”, joilla pyritään ennakoimaan parhaan mukaan määritysten epäselvyyksiä ja pieniä muutostarpeita yhteistyön joustavoittamiseksi (eli ettei jokaista pientä kiveä polulla jouduta koluamaan, kuuluiko sen olla siinä vai ei).
  • Projektin edetessä, eteen tulee suurella varmuudella muutostarpeita, jotka kiinteähintaisessa on rajattu projektin ulkopuolelle. Nämä vaativat sitten lisäbudjetin, aiheuttaen byrokratiaa lisää ja sitä myöden kustannuksia. 
  • Luotettavan yhteistyön synty on astetta vaikeampaa, kun ostaja ja toimittaja kumpikin varmistelee omaa selustaansa ja ajaudutaan pahimmillaan väittelemään kuuluuko joku työ hintaan vai ei.

Lopputulos

Kiinteähintaisen ohjelmistokehitysprojektin ainut odotusarvo on siis, että investointi ja se mitä rahalla saadaan, tiedetään eurolleen etukäteen. Budjetin pitämisestä ei tarvitse erikseen huolehtia. Mutta jos mietitään onko se paras vaihtoehto, niin suurella todennäköisyydellä investoinnin arvo jää pienemmäksi kuin potentiaalia olisi. Ja budjettiakin täytyy kuitenkin seurata ja todennäköisesti myös muokata.