IT-alalla on menty viime vuosina vauhdikkaasti eteenpäin monella rintamalla. Yksi kuuma aihe on ollut siirtyminen projektimalleissa perinteisestä vesiputousmallista ketterän kehittämisen malleihin. Tämän kehityksen osalta alalla ollaankin ajoittain jopa liikuttavan yksimielisiä, ainakin jos keskustelupiirissä on vain toimittajapuolen edustajia.

Ketterän kehittämisen laatuedut ja hallittavuus on todistetusti omaa luokkaansa vesiputousmalleihin verrattuna. Riskejä ja reunaehtoja on toki ketterässäkin kehittämisessä, mutta ne ovat vesiputousmalleihin verrattuna astetta helpommin hallittavia. Ketterässä kehittämisessä esimerkiksi tarvittavan budjetin ennakointi etukäteen on yhtä lailla haasteellista kuin muissakin malleissa, mutta ainakin ennuste tarkentuu matkan varrella.

Asiakkaan näkökulmasta ketterän kehittämisen etuna ovat etenkin monenlaiset hallittavuus- ja näkyvyyshyödyt. IT-toimittajan tekemiset voivat kerrankin tuntua ymmärrettäviltä asiakkaan näkökulmasta.

Ketterä kehittäminen kuitenkin liittyy valtaosin isojen räätälöintityönä tehtävien tietojärjestelmien saralle. Esimerkiksi alle 30 000 euron web-projekteissa ei yleisesti ottaen kannata ketterää kehittämistä soveltaa. Todennäköisesti sen kokoisessa projektissa kun pystytään ennakkoon varsin hyvin lopputulos määrittelemään ja ennustamaan, niin ostajan kannalta ketterä kehittäminen ei tuo välttämättä erityishyötyjä. Ketterässä kehittämisessä on myös paljon asioita, jotka edellyttävät asiakkaalta tavallista korkeampaa sitoutumista toteutukseen, joten tämäkin yleensä edellyttää astetta isomman projektin olemassaoloa. Nyrkkisääntönä voikin pitää, että alle 100 000 euron budjetilla ei kannata yleensä ketterää kehittämistä olla ostamassa.

Viime vuosina on kuitenkin tapahtunut myös toinen iso mullistus it-alalla.

Monia ohjelmistoja on nykyisin mahdollista ostaa palveluna ja jopa ns. pilvipalveluna. Monella sektorilla myös tietojärjestelmätuotteet ovat kehittyneet markkinointipuheesta lähemmäksi todellisia vakioituja tuotteita, joilla on systemaattinen versiokehitys ja tietty ”filosofia” takanaan.

Tämä tuotteistuminen ja ylipäätään tarjonnan vakioituminen on osittain aivan vastakkainen trendi ketterälle kehittämiselle. Siksi ketterästä kehittämisestä ei ainakaan tulisi puhua liian herkästi silloin kun on ottamassa käyttöön jotain tuotetta. Ketterän kehittämisen rinnalla tulisi nykyisin puhua tuotevetoisista projektimalleista. Tällaisista projektimalleista ei ole vielä IT-alalla syntynyt kovin selkeätä yhteistä näkemystä, mutta yhteistä näille malleille ovat pilottivetoisuus ja ylipäätään tuotteiden kokeileminen ja sovittaminen organisaatioon.

Tuotevetoisia projektimalleja voisi kärjistäen pitää jopa vesiputousmallin ja ketterän kehittämisen vastakohtana. Vesiputousmalli ja ketterä kehittäminen kun lähtevät aina liikkeelle asiakkaan tarpeista, ja siitä kuinka mahdollisimman hyvin voitaisiin ymmärtää asiakkaan ainutlaatuiset tarpeet.

Tuotevetoinen ajattelu lähtee liikkeelle oletuksesta, että asiakas on ratkaisemassa jotain sellaista ongelmaa jonka joku toinenkin on joskus aiemmin ratkaissut. Ja vielä edelleen tuotevetoinen malli olettaa oikeastaan, että sama ongelma on ratkaistu jo satoja kertoja aiemmin, ja tähän ongelmaan löytyy vakiintuneita ratkaisuja, eli tuotteita. Ja tässähän ollaan esimerkiksi pilvipalveluiden ytimessä. Pilvipalvelut ovat vakiintuneita ratkaisuja tunnettuihin, yleisiin ongelmiin. Ja tällaisten tuotteiden ja palveluiden kohdalla tulee asiakkaan sovittaa omat toimintamallinsa tuotteen toimintamalleihin.

Parhaimmillaan tämä tuotteen sovittaminen tapahtuu pilotin avulla ilman raskaita sitoumuksia valittuun tuotteeseen. Lisäksi sovitusvaiheessa käydään dialogia liiketoiminnan kanssa ja selitetään kaikille tahoille miksi organisaatio ottaa käyttöön tuotetta eikä räätälöi itselleen omaa, erityistä tietojärjestelmää.

Tuotevetoisten projektimallien omaksumisessa kenties isoin este on IT-alan kulttuurissa joka on vuosikymmeniä painottanut projektimalleja joissa ongelmat ratkaistaan hyvässä yhteistyössä tehtävillä fiksuilla räätälöinneillä ja asiakaskohtaisilla toteutuksilla. Tämä kulttuuri on johtanut siihen, että organisaatiomme ovat täynnä tietojärjestelmiä, jotka on mukautettu, väännetty ja muovailtu organisaation tarpeisiin sopiviksi. Pahimmillaan nämä samat organisaatiot maksavat korkeita lisenssimaksuja ohjelmistotuotteiden tekijöille, ja lisäksi kärsivät erittäin korkeista ylläpitokustannuksista, koska järjestelmiä on räätälöity niin rajusti.

Mikä ratkaisuksi? Hopealuotia tuskin on olemassa tähän ongelmaan, mutta ainakin organisaatioiden tulisi aikaisemmassa vaiheessa miettiä, että milloin ongelma on todella ainutlaatuinen ongelma omalle organisaatiolle ja milloin on taas kyseessä yleinen, vakiintunut ongelma. Esimerkiksi intranet tai verkkosivuston ylläpito ovat asioita jotka eivät ole useimmille organisaatioille ainutlaatuisia ongelmia. Joillekin ne voivat olla erityisen kriittisiä asioita, mutta todennäköisesti yli 90% organisaatioista selviää ottamalla käyttöön tuotteita jotka ratkaisevat yleisesti tunnistettuja ongelmia.

Miten näitä tuotteita sitten otetaan fiksusti käyttöön? Vastaus: Painottamalla valintaprosessia, pilotointia ja tuotevetoista käyttöönottoprosessia.

Mitä jos markkinoilta ei löydy sopivia tuotteita tai piloteissa havaitaan tuotteiden epäsopivuus? Vastaus: Tällöin kannattaa tutustua ketterän kehittämisen menetelmiin, ja lähteä ostamaan enemmän pätevää tiimiä kuin teknologiaa.

Perinteisen vesiputousmallin mukaisesti tehtävät projektit kannattaa ihan oikeasti unohtaa.

Tilaa blogin Parhaat palat -kooste, uutiskirje, joka ilmestyy noin neljä kertaa vuodessa.