Tiimiakatemia on Jyväskylän Ammattikorkeakoulun yrittäjyyden huippuyksikkö

Veikö Moolok vallan?

Kirjoitettu 21.08.16
Esseen kirjoittaja: Janita Mikkola
Kirjapisteet: 3
Kirja: Veikö Moolok vallan?
Kirjan kirjoittaja: Tapio Järvenpää, Ilkka Kankare
Kategoriat: 9. YPK:n ulkopuoliset, 9.04. Johtaminen

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Etsin pitkään jotakin mielenkiintoista projektinhallinnan kirjaa, ja kun otin Veikö Moolok vallan? -kirjan käteeni, luulin vihdoin löytäneeni sen. Mutta ei. Kai se täytyy vain hyväksyä että projektinhallinnan kirjat ovat aina hieman työläitä.

Erilaista tässä kirjassa useisiin muihin projektinhallinnan kirjoihin on se, että se ei ole täynnä kaavioita, taulukoita ja kuvioita erilaisista työkaluista, jotka on tarkoitettu projektien etenemisen helpottamiseksi. Tämä kirja esittelee sekä pieniä että maailman suurimpia projektien epäonnistumisia, sekä selittää ja analysoi mistä budjettien ja aikarajojen ylittymiset johtuivat. (s. 64-127) Antaa se käytännön ohjeistuksiakin projektien onnistumiseen kirjan loppupäässä.

Esimerkkejä maailman mielettömyydestä –lukua lukiessani meinasi välillä kyllä usko ihmiskuntaan loppua. Etenkin suurissa IT-projekteissa, missä yleensä uudistetaan vanhaa järjestelmää, vallitseva standardi on epäonnistuminen. Media uutisoi kärkkäästi etenkin jos kyseessä on julkishallinnon projekti, sillä senhän kustantavat veronmaksajat. Tuntuu, että suurissa projekteissa hälytyskellot eivät ala soimaan vielä silloin, kun deadline on kohdalla ja projekti alle puolenvälin. Ei; vasta sitten aletaan huolestua, kun projekti on myöhästynyt kahdella vuodella ja budjetti ylittynyt kolmasosalla. Kun aikarajaa on siirretty jo muutaman kerran ja budjetti huutaa hallelujaa satojen miljoonien eurojen ylityksen jälkeen, silloin on asiakkaalla jo paniikki päällä ja mitä todennäköisimmin projekti on jo keskeytyksen partaalla. Kukaan ei ole tyytyväinen.

Miksi paniikki ei iske jo heti ensimmäisen deadlinen kohdalla? Eikö siinä vaiheessa ole jo käsitystä, tuleeko projekti venymään vaiko ei? Kirjassa puhutaan, kuinka suurissa projekteissa suhteellisuudentaju pettää usein. (s. 47) Vaikka lähes kaikkien projektien alussa pohditaan, olisiko mahdollista testata nopeasti ratkaisun toimivuutta sekä ”nopeaa epäonnistumista” kaiken varalta, se usein menee hukkaan. Tavoitteeksi laitetaan käyttöönotto vuoden päästä, mikä ei tosiaan ole nopeaa epäonnistumista. Miksi nopea epäonnistuminen on projekteissa sitten tärkeää? Tehdäänpä mitä tahansa ensi kertaa, ensimmäiset ratkaisuluomukset harvoin täyttävät kaikkia tarpeita tai laatuvaatimuksia. Se, että on hyvä valmius heittää aikaisempi versio roskiin, tehostaa uuden alusta aloittamista entistä kokeneempana.

Projektimallit ovat usein vanhanaikaisia ja liian suuren kuvan suunnitelmia. Vesiputousmalliset (yksi ensimmäisiä ohjelmistotuotantomalleja, 1970-luvulta lähtien) projektit kuluttavat aina kaiken ajan ja rahan. (s. 50) Mallin ytimessä ovat pitkäaikaiset syklit, jotka muodostavat yhdessä yhden ison syklin. Kaikkien vaiheiden laajuutta kukaan ei oikein pysty määrittelemään. Tekeminen kuvataan liian suurpiirteisellä ja karkealla tasolla, ja sille varataan (varmuuden vuoksikin) reilusti aikaa.

Tässä mallissa on monta asiaa pielessä. Syntyy illuusio siitä, että aikaa riittää yllin kyllin, jolloin tehtävät kasaantuvat helposti deadlinen liepeille tai vähän yli. Pitkäkestoisuuden vuoksi projektiryhmäläisten innostus ja motivaatio tehtäviä kohtaan laantuu. Se on valitettava tosiasia, että kun aika kuluu ja tekemistä tapahtuu vain vähän kerrallaan, tekijät eivät tunne saavansa mitään käsillä kosketeltavaa vastinetta ponnisteluilleen. Vähemmästäkin loppuu kiinnostus.

Mitä kalliimmaksi ja hektisemmäksi maailmantalous muuttuu, sitä enemmän tarvitaan nopean muutoksen projektinhallintamalleja. Lyhyet seurantajaksot ja pieniksi paloitellut tehtävät (esim. SCRUM-mallissa) mahdollistavat paremmin sen, että virheet voidaan korjata nopeammin, ja jatkuva edistyksen seuraaminen kannustavat tekijöitä.

Miksi edelleenkin tänä päivänä luotetaan vanhoihin malleihin, vaikka ne tuottavat lähes vääjäämättä epäonnistumiseen, vaikka hankkeen tarkoitus olisikin tehokkuutta edistävä tuotos? ”Näin tämä aina ennenkin tehty” –asenne on yllättävän yleinen ajatustapa maailmassa, ja koska muutos luo aina vastarintaa, uusien mallien omaksuminen ei ole helppoa. Sitä paitsi projektin ohessa olevaa oppimiseen käytettävää aikaa tuhlataan liian paljon muuhun puuhasteluun. (s. 46) Projektien vaiheissa on aina tekijöille jotakin uutta, mutta silti suunnitelmat laaditaan oletuksella, että nämä ensikertalaiset osaisivat toteuttaa tehtävänsä ensi kerralla oikein. Tarvitaan toistoja, useita takaisinkytkentöjä sekä palautetta käyttäjiltä useiden testausten jälkeen.

  1. Pitkät syklit
  2. Hidas epäonnistuminen
  3. Oppimisajan tuhlaaminen puuhasteluun

Nämä kolme asiaa lopulta tekevät projektista kuin aallonmurtajan yli vyöryvän tsunamin, joka pitkittyy, tuo valtavat kustannukset ja on yleensä epäkäytännöllinen käyttäjilleen, koska järjestelmää ei ole annettu testattavaksi kohderyhmälle.

Näitä kolmea sudenkuoppaa pitää siis projektien johtamisessa varoa. Veikö Moolok vallan? esittelee kirjan lopussa yksityiskohtaisesti R2O –mallin, joka painottaa oppimista hankkeiden ohella.

Moolok Oppiminen

(Klikkaa isommaksi)

Kirja esittelee projektinhallinnan kolme kehää. (s. 176) 0. kehän projektinhallinta on sekavaa puuhailua; liikaa suunnittelua, hataraa tekemistä ja ei yhtään varautumista katastrofiin.

Uusimpiin ja ketterimpiin projektinhallintamenetelmiin on sisäänrakennettu melko hyvin jatkuvan seurannan ja kehittämisen rutiinit. Kun tämä 1. kehän Plan-Do-Check-Act –kaava toteutuu, projektitiimillä on jo ihan hyvät mahdollisuudet parhaiden tulosten saavuttamiseksi jatkuvien korjaustoimenpiteiden ansioista. Kirjailijoiden masentava havainto projektien arjesta kuitenkin osoittaa, että edes tämä ensimmäisen kehän oppiminen toteutuu valitettavan harvoin.

Mainitsemaani R2O –malliin siirrytään 2. kehän oppimiskehällä, joka käsittää kolme kokonaisuutta: Rethink, Rework ja Orient. Kirja esittelee ne yksityiskohtaisemmin kuin minä, mutta perusidea näissä osa-alueissa tulevat tässä:

RETHINK – Arvioi kriittisesti projektin taustaoletukset, lähestymistavat ja menetelmät. Esimerkkikysymyksiä:

Tukeeko ohjausryhmä projektia ja muutosta riittävästi? Tuottaako projekti arvoa nopeasti ja jos ei, miten sitä voi aikaistaa? Voiko suuria työkokonaisuuksia pilkkoa pienemmiksi?

REWORK – Päivitä projektimenetelmät, tiimit, organisointi, toimintamallit ja käytännöt. Esimerkkikysymyksiä:

Miten varmistat, että projekti jatkuvasti optimoi suuntaansa? Miten käännät yksisuuntaisen viestinnän aidoksi vuorovaikutukseksi? Mitä pitää muuttaa, jotta projektityö on tiimille antoisaa, innostavaa ja motivoivaa?

ORIENT – Ota organisaatio mukaan projektiin ja muutoksen tekemiseen. Esimerkkikysymyksiä:

Miten organisaation eri osat parhaiten tukisivat projektia sen elinkaaren varrella? Miten osallistat sidosryhmiä? Mitä osaamista organisaatiossasi pitää kehittää jotta projekti onnistuu? Miten varmistat, etteivät organisaatiosi avainhenkilöt aseta esteitä projektin etenemiselle?

Tämän kirjan neuvot ja vinkit on suunnattu erityisesti, jos olet päätynyt monimutkaisen ja ison megahankkeen ohjausryhmään, projektitiimiin, asiantuntijaksi tai muuksi avainhenkilöksi. Tyyliin, jos pelissä on satojatuhansia tai miljoonia euroja. Mutta yhtä hyvin näitä voi soveltaa myös pienempiin projekteihin, etenkin jos mukana on jonkin verran porukkaa, esim. parikymmentäkin ihmistä. Joka tapauksessa ne samat sudenkuopat vartovat saalistaan matkan varrella.

Sen olen Tiimiakatemiankin projekteissa huomannut, että mitä pidempi sykli ja hitaammat muutokset, sitä nopeammin alan stressaamaan ja kiinnostus haihtuu pois. Nyt vielä kirkkaammin tajuan mm. SCRUM-menetelmän käytön ja tehtävien pilkkomisen pienempiin osiin. Olen pari kertaa nyt SCRUMia yrittänyt käyttää, mutta en ole sitoutunut siihen niin kuin olisi pitänyt. En vain ymmärtänyt sen tarkoitusta; mielenkiinto pysyy yllä kun näkee jatkuvan kehityksen ja hommien etenemisen.

Ehkä se kolmas kerta siis toden sanoo.

Tagit: , , , , , ,

Keskustele artikkelista

Kirjoita kommentti

Kirjoita allaoleva koodi viereiseen kenttään roskapostin suodattamiseksi, kiitos!