Tavoitehintamalli ohjelmistoprojektien hankinnassa – määritelmä ja eri variaatiot

Tässä blogissa on usein viitattu tavoitehintamalliin, esimerkiksi tuoreessa räätälöityjen web-sovelluksien ostamista käsittelevässä jutussa. Tavoitehintamalli ei kuitenkaan ole mitenkään yksiselitteinen asia, ja sitä sovelletaan myös alalla hyvin useilla eri tavoilla. Tässä jutussa avataan tavoitehintamallin erilaisia variaatioita siten kuin North Patrolissa tyypillisesti mallia käytämme.

Tavoitehintamalli vaatii melko aukottoman vaatimusmäärittelyn

Ensinnäkin, tavoitehintamallia ei tule käyttää tilanteissa, joissa ei vielä tiedetä oikein mitä ollaan ostamassa. Tavoitehintamalli ei näin missään tapauksessa ole korvike kunnollisen vaatimusmäärittelyn tekemiselle. Tähän kuitenkin joskus törmää, kun asiakkaat kertovat miten ovat aiempia hankintoja tehneet.

Harva toimittaja kun kovin mielellään sanoo asiakkaalle, että ”nyt kannattaisi vähän miettiä ennen kuin ryhdytään koodaamaan”.

Kovassa kilpailutilanteessa joku toinen kuitenkin ryhtyy sitten vain koodaamaan suoraan. Ehkä siksi moni alan toimittaja tuntuu preferoivan erilaisia ”budjetäärisiä arvioita”, joissa asiakkaan kanssa olevinaan sovitaan jonkinlaisesta tavoitehinnasta, mutta sopimuksellisesti tähän ei kuitenkaan sitouduta mitenkään. Yleensä asiakkaat sitten vain lopulta hyväksyvät asian, ja käytännössä toimitaan toteuman mukaan laskutuksella, ilman todellista toimitusvastuuta. Joskus taas asiakkaan lakiosasto tai julma tietohallintojohtaja pakottaa toimittajan hyväksymään kattohintaisen sopimuksen, jolloin tietysti toimittajan näkökulmasta ollaan hyvin vaarallisilla vesillä – ja todennäköisesti prosessista ei tule asiakkaan tiimillekään kovin kivaa.

Tavoitehintaisen mallin ideana on tuoda prosessiin joustavuutta, joka helpottaa esimerkiksi ketterien menetelmien käyttämistä. Samalla sopimuksellisesti kuitenkin nojataan vaatimusmäärittelyyn, joka asettaa jonkinlaisen yhteisen tavoitteen, jota kohti yhdessä mennään.

Vaatimusmäärittely ei tavoitehintaisessa mallissa ole kuitenkaan mikään yksityiskohtainen toiminnallinen määrittely, vaan se on liiketoimintatavoitteisiin keskittyvä proosallinen kuvaus tavoiteltavasta kokonaisuudesta ja sen tärkeimmistä osa-alueista. Ihanteellisesti tällöin ei puhuta yhdestäkään loputtoman tuntuisesta vaatimuslistasta, vaan mieluiten napakasta ja ymmärrettävästä ihan oikeasta vaatimusmäärittelydokumentista. Tällainen vaatimusmäärittely tunnistaa keskeiset, tavoiteltavat toiminnallisuudet ja kuvaa näiden toiminnallisuuksien tavoitteet, mutta ei määrittele näiden toiminnallisuuksien yksityiskohtaista toteutustapaa. North Patrolilla esimerkiksi nämä dokumentit harvoin ovat yli 30 sivun pituisia dokumentteja, ja onpa isoja kokonaisuuksia ostettu jopa 10-15 sivun mittaisilla, napakoilla vaatimusmäärittelyillä.

Erittäin räätälöidyissä kokonaisuuksissa vaatimusmäärittelyn rinnalle on suositeltavaa toteuttaa prototyyppi, joka kuvaa käyttöliittymän yleisperiaatteet sekä erikoisimpien osa-alueiden keskeiset toiminnot.

Tämänkaltainen liiketoimintatavoitteisiin ja palvelun konseptiin keskittyvä dokumentti varmistaa projektin loppuvaiheissa tai mahdollisissa ongelmatilanteissa sen, että kaikilla on yhteinen, selkeä kuvaus niistä asioista, jotka pitää valmistua sopimuksen puitteissa. Yksityiskohdista sopiminen kuitenkin jää tällaisessa mallissa projektin sisälle, eikä budjetillisestikaan tarvitse osua mihinkään yksittäiseen numeroon, vaan riittää kun osutaan sovittuun haarukkaan.

Tavoitehintamalli voi muistuttaa kiinteähintaista tai tuntilaskutteista

Tavoitehintamallin eri variaatioita on todella paljon, mutta käytännössä esimerkiksi North Patrol käyttää eniten 50/50/50-mallia. Tässä mallissa toimittajat antavat projektilleen tavoitetyömäärän, johon saakka heillä on oikeus laskuttaa toteuman mukaan täydellä tuntihinnalla. Kun tunnit ovat täynnä, tuntihintaa täytyy pudottaa 50 %, mutta edelleen voi laskuttaa toteuman mukaan. Laskutusoikeus loppuu, kun työmääräylitys saavuttaa 50 % sovitusta tavoitehintakokonaisuudesta.

Näin esimerkiksi 100 htp:n projektiksi arvioitu projekti voi venyä jopa 150 htp:n projektiksi. Jos toimittajan päivähinta on 1000 euroa, asiakkaan kannalta projekti tulee maksamaan korkeintaan 125 000 euroa. Kattohinta onkin yleensä olemassa, vaikka periaatteessa tavoitehintamallia voisi käyttää myös siten, että tuntihinta vain putoaa tasaisesti suhteessa työmäärien kasvuun – ja esimerkiksi pysähtyy jossain 400 euron päivähinnan kohdalla. Käytännössä useimmissa projekteissa on kuitenkin järkevintä soveltaa melko tiukkaa yläreunaa, koska tämä kannustaa kaikkia osapuolia saamaan projekti maaliin mahdollisimman tehokkaasti.

Viimeinen kohta tuossa 50/50/50-mallissa viittaa bonuskäytäntöön. Mikäli toimittaja saa sovitun kokonaisuuden valmiiksi tavoitetyömäärää alhaisemmassa työmäärässä, toimittaja saa bonuksena 50 % laskuttamatta jääneestä osuudesta.

Käytännössä useimmat toimittajat tuntuvat suhtautuvan 50/50/50-malliin melko kiinteähintaisen projektin kaltaisesti, mikä on tietysti tavoitteenakin. Tavoitehintamallin ideana on sitoa toimittaja selkeään toimitusvastuuseen, mutta antaa asiakkaalle ja toimittajan tiimille riittävästi pelivaraa yksityiskohdista sopimiseen ilman jatkuvien muutospyyntöjen laatimista.

Tavoitehintamalli ei sanele projektimenetelmää

Tavoitehintamalli ei varsinaisesti ota kantaa käytettävään projektimenetelmään, jolloin esimerkiksi ketterien menetelmien käyttö sopii hyvin. Hyvin tehty vaatimusmäärittely toimii suoraan syötteenä ketterille menetelmille, jolloin esimerkiksi Scrumia käyttävät tiimit voivat kääntää dokumentista suoraan tuotteen kehitysjonon.

Jopa tuoteomistaja voi tulla asiakkaalta, mutta tällöin esimerkiksi toimittajan projektipäällikön tai asiakkuusvastaavan rooliin kannattaa liittää alkuperäisen tuotteen kehitysjonon seurannan toteutuminen.

Toimittajien kannalta tavoitehintamallit ovat yleensä mieluisia, ja etenkin ketterien menetelmien periaatteisiin malli sopii varsin hyvin.

Myös kiinteähintaisiin projekteihin tottuneet toimittajat yleensä hyväksyvät tavoitehintaiset projektit mielellään, joskin he saattavat suhtautua näihin kuten kiinteähintaisiin projekteihin – mutta tämäkin on toisaalta sallittua, koska yleensä kannattaa mennä sillä projektimenetelmällä mikä on valitulle toimittajalle mieluisin ja tutuin.

Joillekin hyvin tiukkaan raportointiin tottuneille asiakkaille tavoitehintamalli voi tuntua erikoiselta, koska siinä ei välttämättä tarvita viikkotason raportointia vaikka laskutus perustuukin tunteihin. Tämä on kuitenkin yleensä vain hyvä asia asiakkaiden näkökulmasta. Tavoitehintamallissa kun ainakaan projektin alku- ja keskivaiheilla ei tarvitse toimittajan työtä valvoa kovin tarkkaan.

Tavoitehintamallin tyypilliset variaatiot

Aiemmin esitelty 50/50/50-malli on yleensä kohtuullisen joustava, koska esimerkiksi aiemmin esitellyssä 100 000 euron projektissa loppuhinta on todennäköisesti 90 000 ja 125 000 euron välillä – mikä on jo kohtuullisen leveä maali osuttavaksi.

Jos prosessiin haluaa vielä enemmän joustavuutta, niin tyypillisesti tuntihinnan laskua porrastetaan. Porrastuksen voi esimerkiksi tehdä kaksitasoiseksi: ensin tuntihinta putoaa 80 %:iin alkuperäisestä, ja sitten vasta 50 % ylityksen kohdalla 50 %:iin alkuperäisestä. Tällöin loppuvaiheen tehtävistä ja sovelluksen yksityiskohdista sopiminen todennäköisesti onnistuu varsin joustavasti. Toisaalta tämänkaltainen malli ei välttämättä ole toimittajille kiinnostava, koska käytännössä kyse on lähinnä paljousalennuksesta, ei enää toimintaa ohjaavasta hintamallista. Joihinkin tapauksiin tämä kuitenkin toimii, etenkin jos epäillään julkaisuvaiheessa tulevan paljon pieniä muutostoiveita, joiden toteutukseen halutaan varautua – ja näin jatkotyöt voidaan saada hieman halvemmalla.

Ehkä järkevimmät muokkaukset tavoitehintamallin peruskaavaan liittyvät bonuskäytäntöön. Peruskaavan malli ei ole kovin joustava, ja ei toimi kaikkiin tapauksiin kovin hyvin. Usein jonkinlainen bonusmalli on kuitenkin ihan järkevä, etenkin jos julkaisulla esimerkiksi on kiire. Tällöin bonus kannattaa mieluummin sitoa aikatauluun, ja tehdä ehdolliseksi. Joskus bonuksen voi sitoa myös asiakastyytyväisyyteen, tai uuden palvelun saamaan palautteeseen ensimmäisen kolmen kuukauden aikana. Tämänkaltaiset bonusmallit ovat tyypillisesti parempia kuin puhtaasti työmääriin liittyvät bonusmallit. Näistä on kuitenkin vaikea antaa yleisohjeita.

Ylipäätään mitä enemmän uskoo projektin loppuvaiheessa, tai julkaisun jälkeen, tulevan pieniä muutostoiveita, niin sitä enemmän kannattaa harkita tavoitehintamallin säätämistä joustavampaan suuntaan. Esimerkiksi tuntihinnan pudottaminen vain 60 %:iin tai 70%:iin tavoitehinnan täyttyessä on jo huomattavasti joustavampi malli.

Mitä isommasta projektista on kuitenkin kysymys, ja mitä paremmin on omat tavoitteensa osannut asettaa, niin sitä järkevämpää on kuitenkin käyttää 50/50/50-perusmallia, koska isoissa projekteissa joustavuutta kyllä löytyy varsinaisen kokonaisuuden sisältäkin.

Lue lisää:

• Ketterä hankinta vaatii hyvän valmistelun ja ensimmäisen vaiheen (MVP) suunnittelua
• Tavoitehintamalli käytännössä – case VTT

PS. Jos kaipaat riippumatonta asiantuntijan näkemystä verkkopalvelun jatkokehitykseen, uudistukseen tai teknologian vaihtamiseen, kannattaa tutustua North Patrolin konsultointipalveluihin. North Patrol tuntee Drupalin, WordPressin sekä monet muut teknologiat ja auttaa lukuisia asiakkaitaan uudistuksissa ja verkkopalveluiden jatkokehityksen suunnittelussa.