Onnistumisen määritelmä

Sytyke Ry:n ja Agile Finlandin ‘booksprintissä’ kirjoitettiin kirja ketteryydestä kahdessa päivässä. Tässä maistiaisena kappaleeni onnistumisen määritelmästä.

Mitä sinulle tarkoittaa onnistuminen? Miltä se näyttää, kuulostaa ja tuntuu? Jotta voidaan onnistua, tulee ensin sopia mitä onnistuminen käytännössä tarkoittaa. Perinteisessä projektinhallinnassa määritelmä on muuttunut viime vuosikymmenten aikana:

1960: Projektin lopputulos on toimiva. 1980: Projekti pysyy aikataulussa, budjetissa ja täyttää tavoitellun sisältö/laatutason. 1990: Projekti täyttää sisäiset suoritusvaatimukset (aikataulu, kustannukset ja määritelty sisältö) ja ulkoiset (projekti ja sen tuotos on asiakkaiden hyväksymä). 2010: Kokonaisvaltainen onnistuminen, joka sisältää projektin ja tuotteen onnistumisen sekä tiedon luomisen ja levittämisen organisaatiossa.

Perinteisen projektinhallinnan uudemmat näkökulmat lähestyvät ketterää kehitystä, jossa korostetaan lopputulosten hyödyllisyyttä käyttäjille sekä kehittämisen jatkuvuutta. Tällöin onnistuminen on luontevaa määritellä käyttäjille tuotetun arvon ja tuotteen elinkaaren kautta. Arvontuotto varmistetaan viimeistään liiketoiminnan menestymisellä tai epäonnistumisella, johon vaikuttaa lisäksi tuotteen lanseeraus, markkinointi ja myynti.

Projekti vai prosessi

Koko projektin käsitteen voi säännöllisesti kyseenalaistaa kysymällä mihin projektia tarvitaan. Projektista voi helposti tulla itsetarkoitus, joka vaatii huomiota, paperityötä ja puuhastelua sen sijaan, että keskitytään käyttäjille hyödylliseen ja arvokkaaseen lopputulokseen. Esimerkiksi jo syntyessään vanhentunut projekti voidaan toteuttaa, jos sille on saatu rahoitus. Perinteinen projektimyynti johtaa usein vaatimusten lukitsemiseen etukäteen, jolloin looginen tarve vaatimusten keskinäiselle priorisoinnille poistuu. Ilman priorisointia tuotamme väistämättä turhia ominaisuuksia eli hukkaa. Ongelman voi välttää sopimuksella, jossa ostetaan kehitystiimin työaikaa etukäteen määritellyn sisällön sijaan.

Ketterä kehitys pyrkii luomaan epäreilun kilpailuedun sillä, että kehitysprosessia hiotaan pikkuhiljaa jopa vuosia. Tällöin “projekti” on vain nimitys kehitettävälle sisällölle sen sijaan, että projektille luotaisiin uusi hallinto, henkilöstö, ohjausryhmä, raportointi, jne. Tällaisten väliaikaisten projektistruktuurien on vaikeaa kilpailla tuottavuudessa tai työviihtyvyydessä vuosia hiotulle pysyvälle kehitysprosessille ja -organisaatiolle.

Ketterän projektin ja tuotteen onnistumisen mittareita:

1. Sijoitetun pääoman tuotto (Return On Investment, ROI)

2. Kehityksen ja ylläpidon kokonaiskustannukset (Total Cost of Ownership, TCO)

3. Markkinoillemenoaika (Time to Market)

4. Liikevoitto ja markkinaosuus

5. Tuotoksen laatu

6. Aikataulu

7. Käyttäjätyytyväisyys

8. Syntynyt kehitysprosessi

9. Organisaatiossa syntyneet ihmissuhteet

“Project success is not product success.” –Jeff Patton, Agile Alliance

Toimiva tuote 1960-luvulta on edelleen hyvä onnistumisen lähtökohta, joskaan tuotteen toimivuus ei takaa sopivuutta loppukäyttäjän tarpeeseen. 1980-luvulla alettiin korostaa perinteistä projektinhallinnan näkökulmaa (aika, sisältö ja budjetti), johon 1990-luvulla lisättiin asiakkaan hyväksyntä. Mutta onko asiakkaan hyväksyntä sama asia kuin tyytyväinen loppukäyttäjä? Mielenkiintoisesti 2010-luvulla on alettu korostaa kokonaisvaltaista onnistumista sekä organisaation oppimista, ihmissuhteita ja kehitysprosessia. Onnistuneissa projekteissa korostuukin käyttäjille aidosti hyödyllinen lopputulos ja kehitysmalli, joka minimoi muutoksen hinnan, tukee toistuvia julkaisuja, jatkokehitystä ja siten tuotteen elinkaarta.

Case-esimerkki: Organisaatiomallin onnistunut kehittäminen (kiitos Marko Taipale)

Noin 300 hengen organisaatiossa kehitettiin hanketta, joka koostui kuudesta kehitysprojektista. Kullakin projektilla oli oma johtoryhmänsä sekä hankkeen yhteinen johtoryhmä. Hallinnollisiin kokouksiin ja riippuvuuksien selvittelyyn kului tällä “tuplamallilla” merkittävästi aikaa ja rahaa, eikä asiakkaalle ollut merkitystä sillä, montako projektia hankkeen taustalla oli. Ratkaisuna projektien omista ohjausryhmistä luovuttiin ja ne korvattiin kaikille kuudelle projektille yhteisellä johtoryhmällä, joka nyt vastasi yhden yhteisen projektin sekä hankkeen ohjaamisesta. Taustalla säilytettiin kuusi tuotealuetta, joiden kehitystiimit toimivat ketterällä prosessilla. Muutosten avulla työn ohjaamiseen tarvittavaa palaveriaikaa säästettiin vuositasolla 1,3 miljoonaa euroa. Lisäksi saatiin merkittävää hyötyä varsinaisen kehitystyön tuottavuuden parantumisesta.

Yhteenveto onnistumisen määritelmästä

Mieti tarvitsetko yksittäisiä “ainutlaatuisia” projekteja, vai kannattaisiko kehittää vahvaa prosessikulttuuria, jossa samankaltaisia projekteja voidaan toteutettaa “business as usual” -tyyppisesti koko tuotteen elinkaaren ajan. Keskustele asiakkaasi tai tuoteomistajasi kanssa siitä, kuinka mittaatte ketterän projektin tai tuotejulkaisun onnistumista. Kannattaa myös muistaa, että onnistuminen vaatii lähes aina oppimista ja oppiminen epäonnistumista.