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?
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.
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.
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ä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.