Viime viikolla kirjoitin uutiskirjeeseemme projektoinnin tärkeydestä muutoshankkeiden läpiviennissä. Lue teksti kopioimalla alla oleva linkki selaimeesi.

https://gallery.mailchimp.com/af9969da14351a489224f4a7e/files/Promotive_Viisi_vinkkia_kipeiden_muutosten_lapivientiin_osa_1.pdf

Templates, bloody templates

Ollaanpa ihan rehellisiä. Harva meistä erityisesti rakastaa niiden kuponkien täyttämistä. Tällä viittaan dokumentaatioon, jonka projektipäällikkö tyypillisesti juoksee kasaan ja kiikuttaa ohjausryhmälle tai jollekin sidosryhmälle – ja toivoo hartaasti että se myös luetaan.

Projektit ovat huisin erilaisia siinä, millaista roolia dokumentit näyttelevät. Projekti, josta ei ole kirjoitettu riviäkään ei mielestäni ole projekti ensinkään. Pienissä, lyhytkestoisissa projekteissa, joissa ei tehdä merkittäviä ostoja riittää usein projektiehdotus, toimeksianto tai tiivistetty projektisuunnitelma. Oma mielipiteeni on, että myös loppuraportti pitää tehdä jokaisesta projektista.

Suuret asiakastoimitusprojektit perustuvat yleensä sopimukseen, jonka pohjalta tarkennetaan suunnitelma sekä erilaiset alasuunnitelmat joita kertyy usein toistakymmentä (riskikartoitus, viestintäsuunnitelma, laatusuunnitelma jne). Etenemistä pitäisi seurata sormi jatkuvasti projektin pulssilla ja ennustaa tulevaa parhaan tiedon mukaan.

Projektijohtaminen on paljon muutakin kuin raportointia, eikä asiakirjapohjien taakse pääse pakoon vastuuta. Projektipäällikön erottaa kuitenkin asiantuntijasta vastuu hahmottaa projektin tilanne kokonaisuutena ja vetää siitä tarvittavat johtopäätökset.

Vaikka standardimuotoinen dokumenttipohja kuulostaa asiana triviaalilta, on se käytännössä usein välttämätön edellytys sille että ne asiakirjat syntyvät. Olen nähnyt lukemattomia projektimalleja, joissa ennakkoehtynä tietyn virstanpylvään saavuttamiseksi on vaikkapa ”feasibility study”. Ellei mallia ole olemassa, ensimmäinen kysymys on yleensä ”no millaiselta se toteutettavuustutkimus sitten näyttää”?

Asiakirjapohjat ovat ikään kuin tarkistuslistoja, jotka pakottavat ajattelemaan ja kirjoittamaan systemaattisesti. Dokumentteja miettiessä ei pyörää aina tarvitse keksiä uudestaan. Googlaamalla löytyy nopeasti erilaisia dokumenttikirjastoja ja esimerkiksi www.projectmanagement.com jakaa templateja ainakin kampanjaluonteisesti myös ilmaiseksi.

Ketterän keisarin vanhat vaatteet

Kun Agile Manifeston kirjoittamisesta on kulunut kohta 15 vuotta, kiivailu ketterien menetelmien ja projektijohtamisen ns. vesiputousmallin välillä jatkuu. Itse olen asettunut näiden leirien väliin, pyrkien ikään kuin linkiksi eri osapuolten välillä.

En ylipäätään pidä ismeistä ja uskon, että useimmissa tapauksissa todellinen projektinjohto sisältää elementtejä molemmista filosofioista.

No miksi kaikki tämä kiivailu? Miksi jotkut esittävät, että tarkasti rajattuihin vaiheisiin ja hyväksymiskriteereihin nojaava vesiputousmalli on kuollut, kauan eläköön ketterä järjestelmäkehitys! Tai päinvastoin.

Tehokkuutta, nopeutta ja suoraviivaisuutta korostava aikamme henki antaa sanalle ”ketterä” osin ansiotontakin arvostusta. Puhumme ketteristä organisaatioista ja ketterästä strategiasta. No totta kai kehittämistyönkin pitää silloin olla ketterää. Olen osallistunut tilaisuuksiin, joissa toimitusjohtaja tai joku muu ylimmän johdon edustaja toteaa, että tästä lähtien meidän kehittämisprojektit sitten toteutetaan ketterästi. Full stop. Suuren herran poistuttua kateederin takaa projektipäälliköt, sovelluskehittäjät ja muut tekijät mulkoilevat toisiaan hämmästyneinä.

Projektien toteuttaminen tiiviissä tiimeissä, jotka kokoontuvat usein, työskentelevät nopeissa purskeissa ja mukautuvat muuttuviin vaatimuksiin ei minusta vielä edusta ketterää projektinjohtomenetelmää. Minulle se edustaa maalaisjärkeä.

Ketterän kehityksen menetelmien soveltaminen vaatii paljon muutakin. Kuinka monessa organisaatiossa on nimetyt scrum masterit ja product ownerit, aikataulutetut spirintit, sprint backlogit ja sprint retrospectivet, burndown chartit ja product backlogit. Varmasti joissakin, mutta kovin harvassa. Tämä ei kuitenkaan tarkoita sitä ettet voisi poimia esimerkiksi Scrumista soveltuvia työkaluja ja käyttää niitä omassa projektissasi.

Agile-liike syntyi vastaiskuna paperivuorien alle hautautuviin, byrokratiabunkkereihin pakotettuihin IT-projekteihin. Kun perehdyin ensimmäisiin systeemityömalleihin 1990-luvulla ymmärsin täysin tuon vastaiskun. Todellisuus vain on vieläkin hyvin toisenlainen monessa organisaatiossa. Jos nyt tehtäisiin edes minimisuoritus eli projektiehdotus, projektisuunnitelma ja projektin päätyttyä loppuraportti voitaisiin sen jälkeen olla ihan niin ketteriä kuin halutaan.

Me emme tarvitse vähempää dokumentaatiota projekteissa. Tarvitsemme enemmän ja parempaa dokumentaatiota. Ja ennen kaikkea tarvitsemme projekteja, joissa sidosryhmiä hallitaan niin että projektin tuottamaa tietoa odotetaan nälkäisinä ja ahmitaan ensilukemalta. Paperi, joka – Agile Manifeston sanoin – lykätään johonkin pölyiseen arkistoon, edustaa kopiopaperin ja erityisesti kirjoittamiseen kuluneen ajan härskiä väärinkäyttöä.

Projektijohtamisen opeista tehokkuutta ja vaikuttavuutta valtionhallintoon

http://www.haus.fi/ajankohtaista/haus-blogi/projektijohtamisen_opeista_tehokkuutta_ja_vaikuttavuutta_valtionhallintoon/

Projektitoiminnan sertifioinnit – mitä ja minkälaista hyötyä?

Kansainvälisten järjestöjen projektipäällikkösertifioinnit rantautuivat Suomeen 2000-luvun alussa. Näistä ensimmäisiä oli IPMA:n järjestelmä, jossa sertifioidaan projektiosaajia, projektipäälliköitä, projektinjohtajia ja projektitoiminnan johtajia.

Suorittaessani itse IPMA C-projektpäällikkösertifoinnin vuoden 2003 lopulla meitä oli Suomessa parisensataa. Nyt C-projektipäälliköitä on yli 1600 ja kaikkiaan voimassa oleva IPMA-sertifiointi on noin 2500 suomalaisella.

Omat sertifiointijärjestelmänsä on myös Project Management Instute PMI:llä, sekä Prince2-mallin kehittäneellä brittiläisellä OGC:llä. Tämän lisäksi projektitoimintaan kytköksissä olevien ohjelmakehitysmenetelmien (Scrum) ja IT-palveluiden johtamista raamittavan ITILin sertifioinnit ovat yleistyneet.

Entä miksi yritykset ja yksilöt näitä sertifiointeja suorittavat? IPMA ja sen jäsenjärjestö PRY ovat sivuillaan jaotelleet muodollisen projektipäällikköpätevyyden edut sertifioitavalle henkilölle, tämän työnantajalle ja yrityksen asiakkaille.

Viimeisten kymmenen vuoden aikana olen prepannut satoja projektiosaajia suorittamaan joko IPMA- tai PMI-sertifioinnin. Sertifiointi ei koskaan ole ”läpihuutojuttu”, vaan taidonnäyte, joka vaatii riittävän tiedollisen ja kokemuksellisen pohjan lisäksi perinpohjaista harjoittelua ja valmistautumista.

Minulta on kysytty lukemattomia kertoja, onko tästä sertifioinnista hyötyä oman urakehityksen kannalta. Pitkään vastasin monitulkintaisesti sen olevan kyllä mahdollista, mutta minkäänlaista takuuta siitä ei ole että esimerkiksi IPMA-sertifiointi olisi ohituskaista projektipäällikön urapolulla.

Sitten, mielestäni vuoden 2013 aikana, tapahtui muutos. Esimerkiksi Helsingin Sanomien sunnuntainumerossa alkoi olla työpaikkailmoituksia, joissa projektipäälliköltä edellytettiin esimerkiksi IPMA B- tai C-sertifiointia. Myös monet asiakkaani kertoivat sertifiointien olevan tärkeitä, jopa välttämättömiä tarjouskilpailuissa menestymistä ajatellen.

Uskallan sanoa kehitystä vetävän julkishallinnon, joka on perinteisesti ollut meritokraattinen eli korostanut muodollisten pätevyyksien merkitystä. Valtion ja kuntien vanavedessä tulevat niille palveluja tuottavat laitos-, järjestelmä- ja palvelutoimittajat.  Ja näiden perässä puolestaan kyseisiä yrityksiä palvelevat alihankkijat.

Projektipäällikölle sertifioinnista voi nykyään hyvinkin olla hyötyä urakehityksen kannalta. Projektipäällikköjään sertifioivat yritykset todennäköisesti hyötyvät tarjouskilpailuissa koulutetusta henkilöstöstään.

Tästä huolimatta kannattaa muistaa sertifiointien perimmäinen merkitys – toimia yhtenä osana järjestelmällistä henkilöstön ja projektikulttuurin kehittämistä. Kuten opintojaan aloittelevan oikeustieteen ylioppilaan tai lääketieteen kandin, myös projektipäällikön tulisi olla kiinnostunut tutkinnon tuomasta sisältöosaamisesta, ei ainoastaan sen välinearvosta.

Projektivalmennuksilta vaaditaan nyt nopeutta, tehokkuutta ja käytännönläheisyyttä

http://www.promotive.fi/ajankohtaista/kaytannonlaheinen-ja-tehokas-projektiosaamisen-kehittaminen/

Moolok vei vallan vain suurissa järjestelmäintegraatiohankkeissa

Tapio Järvenpään ja Ilkka Kankareen Veikö Moolok Vallan on lennokas ja iskevä kuvaus suurten ict-projektien kohtaamista ongelmista. Kirjoittajat luettelevat vaikuttavan kavalkadin poskelleen menneitä tietotekniikkahankkeita, osin anonyymeinä ja osin yritysten oikeita nimiä käyttäen. Kirja sisältää myös esimerkkejä onnistuneista hankkeita ja mikä tärkeintä kahdentoista askeleen listan parempiin ict-projekteihin.

Kirjan takakansi lupaa liikaa, sillä se puhuu yleisellä tasolla projektien epäonnistumisesta, mutta sisällössä käsitellään nimenomaan suuria järjestelmähankkeita. Niissä epäonnistumisen siemeniä löytyy muualtakin kuin projektinhallinnasta, mm. järjestelmien sisällöstä, suurten ict-palvelutalojen verisestä kilpailusta ja erityisesti julkisen sektorin ongelmallisesta hankintamenettelystä.

Osin fiktiomuotoista kerrontaa sisältävä kirja on suorapuheisuudessaan ja kerronnan sujuvuudessaan kuitenkin piristävää luettavaa. Lopuksi kirjoittajat luettelevat myös inspiraation lähteenään toimineita kirjoja ja sähköisiä foorumeja. Myös allekirjoittaneen kirja lienee käväissyt käsissä sillä kerronnassa on tuttuja piirteitä ja kuvitteellisen esimerkkiprojektin ainoan aasialaisjäsenen sukunimi eroaa vain yhdellä kirjaimella omassa projektiromaanissani käytetystä.