Blogi

Aikataulutus ketterässä projektissa: milloin tämä on valmis?

Projektilla on alku ja loppu, ihan jo sanan määritelmän mukaan. Ketterissä menetelmissä taas vastaavaa rajoitetta ei useimmiten ole. Kehittämisen oletetaan olevan jatkuvaa, ja ajoittain ulos tulee käyttökelpoinen lopputuotos. Projektissa taas lähtökohtaisesti halutaan ”kerralla valmista”.

Tyypillisesti ketteryys siis paketoidaan jonkinlaisen projektikehikon sisään. Tällöin on tärkeää määritellä, mitä projektilta halutaan ja milloin projekti on valmis. Laajuuden hallinnan ei kuitenkaan tarvitse olla sitä, että ensin määritellään tarkasti haluttu lopputulos, jota sitten muutoshallintamenettelyllä muokataan. Projektin läpimenoaikaa voi lyhentää ja projektin tuottamaa arvoa voi sekä parantaa että aikaistaa käyttämällä ketteriä menetelmiä.

Tämä kuitenkin edellyttää tiettyjä valmiuksia, joiden huomiotta jättäminen saattaa aiheuttaa pettymyksiä. Seurauksena ei esimerkiksi saada haluttua asiaa kokonaisuudessaan, ei osata ennustaa lopullisia kustannuksia tai projekti menee pitkäksi. Tällöin syytetään helposti menetelmää, vaikka epäonnistuminen johtuu usein täysin muista asioista, kuten priorisointikyvyttömyydestä tai päätöksenteon tahmeudesta. Voidaan jopa todeta, että ”ketterät menetelmät eivät sovellu tämänkaltaiseen projektiin”.

Ketterät menetelmät tarjoavat kuitenkin paljon hyviä periaatteita projektinhallintaan, vaikka mikään yksittäinen viitekehys ei olisikaan käytössä. Tässä blogisarjassa esitellään kolme avainkäsitettä, joiden kautta aikataulutukseen voi saada tarvittavaa näkökulmaa.

  1. Value – tuotosten arvo liiketoiminnalle on elintärkeää ymmärtää

Tyypillisesti ketterissä menetelmissä tehdään eniten arvoa tuottavia asioita, mikä käytännössä edellyttää arvonmuodostuksen analysoimista ja priorisointia. Tämä on hyvä pitää mielessä, kun mietitään, milloin projekti päätetään. Lähtökohtaisesti tekemistä jatketaan vain siihen pisteeseen asti, kun kyseiseen kohteeseen sijoitettu panos ei enää tuota parempaa arvoa verrattuna vaihtoehtoiseen kohteeseen. Malleja arvon ja priorisoinnin käytännön tason toteutukseen on useita. Kokonaiskuvan saavuttamiseksi kannattaa tutustua useampaan.

  1. Minimum Viable Product – pilko, opi ja hyödynnä

Suunnittelu on ehdottoman tärkeää. Ei kuitenkaan ole hedelmällisin lähestymistapa jäädä paikalleen suunnittelemaan, miten maailma saadaan valmiiksi tämän yhden hyvin määritellyn mammuttiprojektin kautta. Monessa tapauksessa on tehokkaampaa tehdä monta peräkkäistä hyvin rajattua pientä projektia, saada projektista nopeasti hyötyä ja tarkastella tilannetta uudelleen. Ensimmäisen valmiin tuotoksen jälkeen ymmärrys on kasvanut ja riski siitä, että tehdään vääriä asioita, on pienentynyt.

Startup-maailmassa tällaiset minimaalisen panoksen ja maksimaalisen arvon miniprojektit ovat elinehto, mutta MVP-ajatus soveltuu hyvin myös yleisemmin käytettäväksi. Tätä näkee silti yllättävän vähän yritysten IT-projekteissa. Saatetaan jopa puhua MVP-toteutuksesta, mutta silti projektiin halutaan mukaan jotakuinkin kaikki mitä keksitään. Mietittäessä pienintä mahdollista projektia on hyvä lähestyä asiaa sekä teknisestä että liiketoiminnallisesta näkökulmasta. Tärkeää on myös, että ymmärrystä jaetaan projektin osapuolten kesken.

  1. Definition of Done – on tärkeää määritellä konkreettisesti, mitä valmis tarkoittaa

Kolmantena osa-alueena ketterän projektin aikataulutuksessa on syytä tarkastella valmiin määritelmää. Milloin isossa kuvassa ollaan valmiita ja millä edellytyksillä projekti voidaan lopettaa? Milloin yksittäiset tehtävät ovat valmiita, esimerkiksi mitä mitattavia laatukriteerejä asetetaan? Viimeksi mainitun suhteen ketterät menetelmät ovat itse asiassa tyypillisesti hyvinkin tiukkoja, laatukontrollit ovat sisäänrakennettuna moneen prosessiin, ja löperöitä tehtäväkuvauksia ei hyväksytä.

 

Asiantuntijakirjoittajana Project-IT:n johtava konsultti Miikka Lötjönen.

Jaa artikkeli:

Lataa IT-ostamisen ABC -opas!

Asiantuntijoiden kanssa yhteistyössä kirjoitettu IT-ostamisen ABC pitää sisällään paljon käytännönläheisiä ohjeita IT-ostamiseen.

  • Kenttä on validointitarkoituksiin ja tulee jättää koskemattomaksi.