Projekti. Helppo homma? Päätetään vain minkälainen rakennus, tietojärjestelmä tai tuote halutaan saada aikaiseksi ja nimetään kannuksensa ansainnut työntekijä projektipäälliköksi vastaamaan tuloksesta? Väärin, väärin ja väärin.
Jo ensireaktion kohdalla alkoi homma luisua käsistä. Kun työkokonaisuuden toteutus- ja johtamistavaksi valitaan projekti, tulee päätöksenteon mahdollistamiseksi ensin määritellä ne hyötytavoitteet, miksi mitään kannattaa alkaa edes suunnittelemaan. Hyötytavoitteista sitten johdetaan ne tuotokset (rakennus, tietojärjestelmä tai tuote), joiden avulla kyseiset hyödyt on projektin valmistumisen jälkeen mahdollista realisoida.
Toinen kuoppa tuli itselle ja projektin onnistumiselle kaivettua projektipäällikön valinnassa. Paras asiantuntija ei välttämättä ole paras eikä edes hyvä projektipäällikkö. Projektipäällikön työ nykymaailmassa on vähintäänkin yhtä paljon ihmisten kuin asioidenkin johtamista, sillä ne ihmiset (se kuuluisa projektiryhmä), jotka tekevät tuotosten sisällöllisen ja teknisen suunnittelun sekä toteutuksen, ovat lähes aina kiinni myös organisaation jatkuvien toimintojen ja palveluiden pyörittämisessä sekä mahdollisesti kaivattuja myös muissa projekteissa. Toisinaan vaikuttaakin siltä, että projekti-sanaa käytetään silloin, kun koko organisaation henkilötyökapasiteetti on jo varattu jatkuvan toiminnan pyörittämiseen ja samoilla henkilöresursseilla halutaan silti saada uuttakin kehitettyä. Tähän yhtälöön, kun vielä nimetään projektipäälliköksi loistava asiantuntija, jonka panosta tarvitaan sisältöön enemmän kuin johtamiseen ja jolta mahdollisesti puuttuu kaikki osaaminen ja kokemus projektipäällikön työstä, on epäonnistuminen lähes taattu.
Kolmas kömmähdys liittyykin vahvasti kahteen edelliseen. Projektipäällikkö voi tässä roolissa olla vastuussa vain projektin toteutuksen tavoitteiden saavuttamisesta eli tuotosten laajuudesta & laadusta, aikataulusta ja budjetista. Projektin avulla saavutettavista tuloksista vastuu on aina projektin omistajalla. Tämänkin roolin työllistävyys riippuu pitkälti projektin kompleksisuudesta. Suoraviivaisemmissa projekteissa projektin omistajan työ on melko helppoa projektin aikana. Hänen osaltaan haasteet ovat edessä vasta sitten, kun hän oman linjavastuunsa perusteella valvoo sitä, että projektin tuotoksia käytetään ja hyödynnetään jatkuvassa toiminnassa hyötyjen realisoimiseksi. Kääntäen voi sanoa, että usein kehitysprojekteissa projektin omistaja valvoo projektin jälkeen sitä, että organisaatio toimii uudella tavalla ja käyttää projektin tuotoksia, eikä lipsu vanhoihin työtapoihin tai käyttämään vanhoja systeemejä. Tähän liittyen kannattaa katsoa video projektipäällikön ja projektin omistajan työnjaosta projekteissa.
Edellä pohditut asiat ovat aivan projektinjohtamisen ydintä, mutta niiden toteutuminen on monissa organisaatioissa heikkoa, koska nämä ovat lähestulkoon filosofisia asioita. Näiden ymmärtäminen ja noudattaminen ei vielä anna ensimmäistäkään käytännön neuvoa tai työmenetelmää yksittäisen projektin läpivientiin. Kannattaako siis lainkaan kuunnella konsulttia, jonka neuvoilla ei vielä saada mitään konkreettista aikaan?
Viime vuosien kehitystrendeissä onkin nähtävissä, että kiinnostavammaksi koetaan niiden konsulttien puheet, jotka antavat konkreettisia neuvoja varsinaisen projektityön tekemiseen. Tämä näkyy esimerkiksi siinä, että useissa organisaatioissa halutaan oppia, miten projektin toteutustyötä tekevää ryhmää eli ihmisiä ohjataan käytännön tasolla jopa päivittäisessä työssä. On ihan totta, että yksikään projektijohtamisen malli kuten ABC Projektimalli™ tai Prince2® saati projektinjohtamisen standardit ISO SFS 21500 tai Ansi PMBOK®, eivät anna konkreettisia ohjeita siihen, miten yksittäinen projekti tulisi toteuttaa ja miten työtä tulisi konkreettisen tekemisen tasolla ohjata. Mistä tämä valtava puute sitten johtuu? Ongelma johtuu siitä, että projektijohtamisen mallit ja standardit on luotu soveltumaan kaikkiin mahdollisiin erilaisiin projektityyppeihin, kun taas erilaisissa projektityypeissä tulee työn toteutuksen tasolla soveltaa erilaisia konkreettisia ohjaamismalleja.
Jos siis itse kokisin tarpeelliseksi kuunnella konsulttia, jonkin ongelman ratkaisemiseksi, kumpaa konsulttia kuuntelisin? Filosofista vai konkreettista? Todellisuudessa nimittäin asiakas joutuu tämän valinnan usein tietämättään tekemään, koska konsulttien aika on yleensä kallista ja siksi rajallista. Jokainen konsultti joutuu siis valitsemaan, mistä asioista keskustella asiakkaan kanssa ja mitkä jättää keskustelun ulkopuolelle. Lisäksi kaiken rehellisyyden nimissä on todettava, että tähän rajauspäätökseen vaikuttaa myös se, haluaako konsultti kertoa sen, mitä asiakas haluaa kuulla vai sen, mitä asiakkaan tarvitsisi kuulla. Aloittaakko haasteiden korjaaminen lattiatasolta ja konkretiasta vai johdosta ja filosofiasta? Valinta on aina asiakkaan, mutta kaikille on toivottavasti selkeää, kummasta suunnasta yrityksen tavoitteisiin pyrkimisen tulisi ohjautua. Kaikkien panosta toki tarvitaan, mutta suunnan tulisi olla yhteinen. Ihannetilanteessa meillä olisikin mahdollisuus saada apua jokaiselle tasolle ja tukea filosofiasta konkretiaan asti.
Tämän pohdinnan päätteeksi heitänkin haasteen kollegoilleni ja kaikille muillekin projektikonsulteille: ei tarjota asiakkaalle konsultaatiota vain jostain tietystä työmenetelmästä varmistamatta sitä, että kokonaisuus ja projektijohtamisen filosofia ovat asiakkaalla jo hallussa eikä myöskään tarjota konkreettisesta tekemisestä irralliseksi jäävää konsultaatiota. Huolehditaan siitä, että asiakas vähintäänkin ymmärtää saamansa konsultaation osuuden organisaation johtamisen kokonaiskuvassa. Silloin olemme mielestäni ansainneet konsultin arvon ja tuoneet työllämme merkittävää lisäarvoa asiakkaillemme. Tällaista konsulttia ainakin itse haluaisin asiakkaana kuunnella!
Annika Oinonen
Kirjoittaja toimii Suomen Projekti-Instituutissa Projektijohtamisen konsulttina.