Jotkut firmat toimivat ilman pomoja, myös ilman projektipäälliköitä. Scrumissa projektipäällikköä roolina ei edes tunneta. Entisaikojen käsitys projektipäälliköstä joutaakin historiaan. Väitän, että projektipäällikkö voi kuitenkin tuottaa asiakkaalle huomattavasti arvoa kahdella eri tavalla: johtamalla ensiksi projektien liiketaloudellista hyötyä, ja toiseksi sekä ihmisiä että tiimejä.
Projektipäällikkö – firman turhin tyyppi?
Projektit ja päälliköt. Ihanan vanhanaikaisia käsitteitä. Päälliköitä ei tarvita mihinkään. Moderneimmissa yrityksissä ei ole pomoja, vaan johtajuus tapahtuu horisontaalisesti tiimeissä ja niiden yli, kuten Frederic Laloux esittää loistavassa kirjassaan Reinventing Organizations.
Ja entä sitten projektit? Ketterä kehitys on etenkin IT-puolella tehnyt käytännössä projektista jos ei täysin tarpeettoman, niin ainakin varsin hyhmäisen käsitteen. Melkein minkä tahansa IT-järjestelmän elinkaaren aikana tehdään enemmän työtä järjestelmän toiminnallisuuden kehittämiseksi projektin jälkeen kuin sen aikana.
Hierarkiat litistyvät ja projektit ketteröityvät. Tarvittaessa kuka tahansa voi nähdä projektin reaaliaikaisen tilanteen ruudulta. Perinteinen projektipäällikön tehtäväkenttä aikataulujen, budjettien, raporttien, ynnä muiden papereiden pyörittelyssä tulee päivä päivältä tarpeettomammaksi.
Myönnän auliisti, että olen itsekin pohtinut, olenko vain turha pomo häiritsemässä rehellistä työntekoa. Sen pohjalta olen pyrkinyt löytämään roolini projektipäällikkönä uudestaan.
Asiakasarvo projektipäällikön työn keskiöön
Nojaan tukevasti leaniin, joten pohdintani ytimessä on arvon tuottaminen asiakkaalle. Näin ollen kysymys kuuluu: mitä sellaista projektipäällikkö voi projektissa tehdä, että hän tuottaa asiakkaalle todellista arvoa? Vai onko mitään sellaista?
Tietenkin projektipäällikkö auttaa asiakastaan luovimaan toimittajaorganisaation karikoissa, mutta se on hukkaa. En ole vielä tavannut asiakasta, joka haluaisi maksaa erikseen siitä, että paikkaillaan kömpelöitä prosesseja.
Olen tunnistanut kaksi asiaa, joihin keskittymällä projektipäällikkö voi luoda aitoa asiakasarvoa: arvon sekä ihmisten ja tiimien johtaminen. Näiden arvo kirkastuu erityisesti pitkällä aikavälillä.
Katse horisonttiin
Vuosia sitten tein ensimmäisiä projektejani avustavana projektipäällikkönä. Loppua kohden tuli totuttuun tapaan kiire. Viimeisinä viikkoina huhkittiin jopa yötä päivää, ja käyttöönotto saatiin kuin saatiinkin tehtyä, vaikkakin vähän myöhässä. Ihan valmista ei kuitenkaan tullut: olin mukana vielä kolme vuotta myöhemmin, kun viimeinen projektin sisältöön kuulunut tehtävä valmistui. Matkan varrella toki tehtiin paljon muutakin kuin projektin häntiä.
Äkkiseltään voisi kuvitella, että projekti oli epäonnistunut. Ja se olisikin ollut, jos sitä oltaisiin katsottu erillisenä projektina: aikataulu ja budjetti ylitettiin, eikä kaikkea edes saatu valmiiksi. Silti asiakas oli erittäin tyytyväinen.
Pohdin asiaa pitkään, kunnes tajusin, että ongelma ei ollut suorituksessa. Se oli koko projektin käsitteessä. Meidän ei pidä johtaa projekteja, vaan tuotteita, kuten Mik Kersten asian muotoilee kirjassaan Project to Product. Tuotteella tässä tarkoitetaan rankasti yksinkertaistaen sitä, mitä rakennetaan tuottamaan arvoa.
Katseen pitää olla nimenomaan tuotteen arvon mittareissa, ei perinteisissä projektin mittareissa.
Tuo projekti siis epäonnistui, koska sen puitteissa päätettiin tehdä vähän eri asioita, ja sen seurauksena budjetti ja aikataulu venyivät. Ketterästi, tai tuotenäkökulmasta, katsoen tämä ei olisi ollut epäonnistuminen. Projektin aikana yksinkertaisesti opittiin uutta, joten prioriteetit muuttuivat.
Mutta miten tämä liittyy projektipäällikköön?
Projektipäällikkö arvon johtajana
Ensimmäinen uuden projektipäällikön arvokkaista tehtävistä on johtaa asiakasarvoa. Vanhan projektipäällikön piti olla tarkka projektin mittareiden, kuten budjetin ja aikataulun, suhteen.
Uusi projektipäällikkö ei käytä projektin määriteltyä budjettia tai aikataulua alibinaan, vaan pyrkii rohkeasti johtamaan asiakkaan saamaa arvoa. Projektipäällikkö etsii kyltymättömästi arvoa, ja auttaa muotoilemaan sitä asiakkaalle.
Kerstenin ajattelua mukaillen: ei ajatella kiinteää projektia kulueränä, josta selvitä mahdollisimman vähin kustannuksin. Sen sijaan ajatellaan projektia osana tuotetta, joka tuottaa firmalle arvoa vuosiksi eteenpäin. Kersten tunnistaa tämän eron suurimpana selittäjänä sille, miksi IT-yritykset saavat IT-investoinneistaan arvoa siinä, missä moni perinteinen epäonnistuu.
Arvon etsiminen on tärkeää etenkin, kun alustava käyttöönottoprojekti on saatu maaliin. Projektipäällikön työ ei Solitalla päätykään käyttöönottoon, vaan jatkuu tyypillisesti vuosia sen jälkeenkin. Tänä aikana me emme pelkästään pyri pitämään tuotetta hengissä, vaan me kehitämme sitä jatkuvasti tuottamaan asiakkaalle yhä enemmän todellista bisnesarvoa. Projektipäällikkö toimii asiakkaan liiketoiminnan edustajana toimittajan puolella. Siksi tässä roolissa projektipäälliköltä vaaditaan ennen kaikkea liiketaloudellista ymmärrystä.
Palataan edellä mainittuun projektiin. Olisinko onnistunut projektipäällikkönä paremmin, jos olisin pitänyt tiukemmin kiinni projektin määrittelystä? Olisimme ehkä päässeet maaliin aikataulussa ja budjetissa. Asiakas olisi kuitenkin saanut siitä vähemmän arvoa. Minä en tiedä, miten sitä voisi pitää onnistumisena.
Paperinpyörittelijä
Itseohjautuvuus on päivän kovimpia sanoja. Olin kerran projektissa, jossa se oli erittäin korkealla tasolla. Minun roolini projektipäällikkönä oli käytännössä istua kokouksissa ja todeta, että kaikki on hyvin. Asiakas oli tietysti oikein tyytyväinen, koska kaikki sujui hienosti.
Jälkeenpäin ajatellen asiakas olisi saattanut olla vielä tyytyväisempi, jos en olisi käyttänyt aikaani ja heidän rahaansa istuskelemalla noissa palavereissa tyhjän panttina. Enpä olisi halunnut olla Office Spacen Bobien haastattelussa kertomassa roolistani tuossa projektissa.
Jatketaan siitä aasinsiltaa pitkin projektipäällikön toiseen arvokkaaseen tehtävään.
Päälliköstä palvelevaksi johtajaksi
Perinteisesti projektipäällikön vastuu ihmisiin liittyen on ollut resursointia ja töiden ohjausta. Projektipäällikkö on yksinkertaisesti pitänyt huolta siitä, että projektissa on ollut oikea määrä ihmisiä, jotta pysytään aikataulussa ja budjetissa. Sitten projektipäällikkö on jakanut tehtävät. Muusta viis, oma esihenkilö selvitelköön projektin traumat ja massiivisen flexikertymän.
Joe Iaroccin määritelmän mukaan palveleva johtaja kehittää ihmisiä, rakentaa luottamusta tiimissä ja saavuttaa tuloksia. Lyhyellä aikavälillä viimeksi mainittu onnistuu monin tavoin, mutta pitkällä aikavälillä kaksi edellistä ovat avainasemassa myös kolmannen saavuttamiseksi. Kuten arvon johtaminen, tämä tulee erityisen tärkeäksi, kun katsotaan yli lyhyen projektihorisontin kohti tuotteen koko elinkaaren arvoa.
Projektipäällikköä ei tarvitakaan määräämään tehtäviä. Hän osoittaa suuntaa, viitoittaa tiimille tietä kohti asiakasarvoa. Projektipäälliköltä vapautuu tästä myös valtavasti aikaa ihmisten ja tiimin hyvinvoinnin ja osaamisen kehittämiseen. Asiakasarvo on selkeä: hyvinvoinnin ja osaamisen kehittäminen liittyvät tutkitustikin huomattavasti korkeampaan tuottavuuteen ja koko yrityksen kasvuun.
Ei sittenkään turha?
Uskon, että projektit voivat onnistua myös tyystin ilman projektipäällikköä, esimerkiksi Scrumin pohjalta. Olen myös jossain määrin Laloux’n kuvailemien teal-organisaatioiden fani, ja uskon niiden käytäntöjen tuomiseen myös perinteisempiin organisaatioihin. On todella aika päästää irti perinteisestä käsityksestä projektipäälliköstä.
Projektipäällikkönä en näekään itseäni tiimin yläpuolella, vaan sen jäsenenä. Siinä, missä koodari on koodaamisen asiantuntija, minun tehtäväni projektipäällikkönä on olla asiakasarvon, ihmisten ja tiimityön johtamisen asiantuntija.
Siinä missä projektia on syytä katsoa arvoa luovana tuotteena, myös projektipäällikköä on syytä katsoa uusin silmin. Projektipäällikkö ei ole pakollinen kuluerä, vaan parhaimmillaan mahdollistaa todellista asiakasarvoa.
Lopuksi: Mutta entä Scrum?
Kiva kun kysyit. Tekstissä mainitut kaksi tehtävää ovat sellaisia, joita Scrumissa ei tunneta. Scrumissa ei ole ihmisten johtajaa. Scrum Masterin tehtäviin kuuluu valvoa ja valmentaa Scrumin toteutumista, ei johtaa ihmisiä yleisesti.
Tuoteomistaja vastaa periaatteessa arvon johtamisesta. Tuoteomistaja on erinomaisessa asemassa arvon johtamisessa, kun kehitetään omalla porukalla. Sen sijaan Solitan kaltaista palveluntarjoajaa käytettäessä tuoteomistaja vain harvoin pystyy aivan samaan. Olen nähnyt tällaisesta onnistumisesta yhden esimerkin. Siinä tapauksessa tuoteomistajalla oli taustaa kyseisen järjestelmän konsultoinnin puolelta.
Mikäli asia kiinnostaa tarkemmin, suosittelen lämpimästi lukemaan Mik Kerstenin visionäärisen kirjan Project to Product. Olennainen pointti sieltä: Scrumin kaltainen viitekehys koskee vain toimituksen osuutta, ei koko arvovirtaa.
