Project-IT:n mallilla projekti päätetään jämptisti

Osa 3: Projektin päättämisen edellytykset ja laadunvarmistus

Project-IT:n Mukautuvan projektinhallinnan esittelyssä olemme jo asettaneet liiketoiminnalliset tavoitteet ja kehittäneet ratkaisua ketterillä sprinteillä jatkuvasti uutta oppien. Tässä artikkelissa kerron laaduntarkistuspisteistä sekä projektin ytimekkäästä päättämisestä.

Ketterien menetelmien alkuvuosista on joillekin jäänyt pelko, että projektit eivät pääty milloinkaan. Mallimme avulla jokainen projekti päätetään hallitusti. Projektin avainhenkilönä ja liiketoiminnan äänitorvena on tuoteomistaja. Hänellä on kokonaisnäkemys siitä, onko projektin keskeiset liiketoimintatavoitteet saavutettu. Hänen tukenaan projektipäällikkö seuraa projektille myönnettyä budjettia ja aikataulua. Yhdessä he pystyvät ohjaamaan projektin maaliin aiempaa tehokkaammin liiketoiminnan ja projektin reunaehtojen mukaan, toki ohjausryhmän siunaamana.

Toinen ketterän kehittämisen perinteinen synti on ollut se, että ketterä kehitystiimi keskittyy vain tekniseen toteuttamiseen. Tällöin unohdetaan, että tuotteella on käyttäjiä ja yrityksellä organisaatioita, joiden pitäisi hyötyä uudesta palvelusta. Ikävä kyllä käyttäjät unohtuvat yhä edelleen liian usein projektin teknisten ongelmien muodostaman vuoren varjoon.

Mukautuva projektinhallinta varmistaa, että myös kehitystiimin ulkopuoliset vastuut hoidetaan. Kehitystiimien käyttämiin ketteriin menetelmiin, kuten Scrumiin, verrattuna Mukautuvassa projektinhallinnassa on erityisesti panostettu laaduntarkistuspisteisiin. Mallin mukaisesti projektipäällikkö valvoo, että projektissa huomioidaan kaikki sidosryhmät. Ennen kuin mitään viedään tuotantoon, on kaiken oltava valmiina: viestintä, markkinointi, koulutus ja mahdolliset organisatoriset muutokset sekä riittävä tuki uuden palvelun käyttöön.

Budjetissa ja aikataulussa

Perinteisissä projekteissa ryhdytään päätösvaiheessa lähes aina vääntämään toimittajan kanssa kättä siitä, että reilu vuosi sitten lähes mielivaltaisesti keksityt nippelit ja nappelit puuttuvat. Näistä kokonaisuuden kannalta epäoleellisista asioista väännetäänkin sitten toden teolla, vaikka käyttäjät eivät kyseisillä toiminnallisuuksilla mitään tekisikään. Väännön ansioista niin aikataulu kuin kustannuksetkin paukkuvat yli sovitun, käytetylle rahalle ei varmasti saada katetta ja kaikille jää paha maku suuhun.

Perinteisesti pitkän projektin lopussa tehdään tuon väännön jälkeen iso käyttöönotto, ja projektia ryhdytään sulkemaan. Siinä vaiheessa käyttäjiltä tai muulta organisaatiolta alkaa sataa palautetta, kun kaikkien tarpeita tai kaikkia osapuolia ei ole huomioitu lanseerauksessa. Projektin rahat on jo poltettu, ja henkilöt kiinnitetty seuraaviin projekteihin, mutta varsinainen liiketoiminnan muutos onkin oikeasti vasta alkamassa!

Mukautuvan projektinhallinnan projekteissa tätä ongelmaa ei synny, koska palautetta on kerätty matkan varrella koko ajan ja siihen on myös reagoitu. Myöskään toimittajien kanssa ei tarvitse vääntää kättä, koska tuoteomistaja varmistaa, että tehdään vain oleellisia asioita.

Mukautuvan projektin budjetti pysyy perinteistä projektia paremmin raameissaan, koska tärkeimmät asiat on tehty ensin, ja viety jo tuotantoonkin. Realismia toki on, että budjetti käytetään kokonaan, mutta kun budjetti alkaa tulla vastaan, voidaan todeta, että vaikka kaikkea alussa ideoitua ei ehkä ole toteutettu, niin kaikki oikeasti merkitykselliset muutokset on saatu käyttöön ja liiketoiminnan tavoitteet on saavutettu. Perinteisissä projekteissa nysvättäisiin tässä vaiheessa vielä toisarvoisia muutoksia kauan sitten paukkuneella budjetilla.

Muista seurata liiketoimintatavoitteiden täyttymistä!

Mukautuvan projektinhallinnan avulla tehdystä projektista ei laadita perinteistä 50-sivuista opusta, vaan kevyt loppuraportti, jota oikeasti hyödynnetään jatkokehittämiseen. Raportissa käydään läpi avainluvut, liiketoiminnan tahtotila, miten hyvin se toteutui ja erityisesti se, miten tavoitetilan toteutuminen varmistetaan.

Liiketoimintatavoitteet tähtäävät usein jopa vuosia projektin päättymisen jälkeiseen aikaan, joten projektin hyötyjä ei vielä projektin päätösvaiheessa kovin tarkasti tiedetä. Toki mukautuvan projektinhallinnan avulla saadaan odotettavissa olevista hyödyistäkin parempi käsitys kuin perinteisessä projektimallissa. Hyötyjä lähdetään kerryttämään jo projektin aikana heti kun se vain on mahdollista. Projektin päätösvaiheessa varmistetaan, että linjaorganisaatio ei tarvitse enää projektin tukea ja sovitaan, kuka varmistaa liiketoimintatavoitteiden täyttymisen projektin jälkeen.

Kokemusteni mukaan Mukautuvan projektinhallinnan avulla projektit saadaan paljon useammin valmiiksi aikataulussa ja suunnitelluilla kustannuksilla kuin perinteisillä menetelmillä, ja samalla tehdään huomattavasti vähemmän tarpeetonta työtä.

Haluatko sinä tehostaa IT-projektejasi? Ota yhteyttä ja jutellaan lisää.

Simo Lankinen
simo.lankinen@project-it.fi
johtava konsultti
Project-IT Oy

Lue Mukautuvasta projektinhallinnasta kertovan artikkelisarjan kaksi edellistä osaa:

Osa 1: Mukautuva projektinhallinta: liiketoiminnan tavoite, kustannusarvio, aikataulutus 

https://projectitoy.wpengine.com/2018/01/18/project-itn-malli-varmistaa-liiketoimintahyotyjen-saavuttamisen/

Osa 2: Mukautuva projektinhallinta: toteutusvaiheen kehityssprintit ja jatkuva oppiminen

https://projectitoy.wpengine.com/2018/02/15/project-itn-mallilla-projekti-etenee-hallitun-ketterasti/

Jaa artikkeli: