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/