Digitalisaation neljä aaltoa ja mihin ne huuhtoivat projektitiimit

Se on nyt kaikkien huulilla. Iso D. Älkää yrittäkö, teidänkin yrityksessä vähintäänkin joku miettii mitä pitäisi tehdä kun maailma tuntuu olleen täynnä digitalisaatiopuhetta ainakin viimeiset 2-3 vuotta.

Alkuvuoden aikana olen lukenut muutaman white paperin, artikkelin ja kymmenittäin blogeista kummunneita keskusteluita digitalisaation eri muodoista ja miten ne pitäisi ottaa huomioon liiketoiminnassa, johtamisessa ja henkilöstökokemuksen luomisessa. Jossain vaiheessa minusta alkoi tuntua että tämäkin kokonaisuus voidaan pilkkoa osiin. Päätin lähestyä aihetta digitalisaation eri vaiheiden tai aikakausien kautta. Tämä on tietysti vain yksi tapa siivuttaa tätä ilmiötä mutta se tuntui minusta luontevimmalta. Teitä on varoitettu.

Tavallisiin valkokaulustyöyhteisöihin, projekti- ja muuhun tiimityöhön digitaaliset työkalut tulivat 1990-luvun lopulla ja 2000-luvun alussa. Niiden pääasiallinen tavoite oli ylittää ajan ja paikan asettamat esteet erityisesti hajautettuja, virtuaalitiimejä ajatellen. Perustettiin projektikohtaisia työtiloja ja keskustelualueita Sharepointiin tai muille alustoille. Markkinoille alkoi syntyä tänään melko kömpelön näköisiä työpöytäsovelluksia, joilla pystyi esimerkiksi luomaan, siirtelemään ja poistamaan erilaisia tehtäviä ja tuotoksia kuin fläppitaululla tai valkotaululla ikään. Usein näihin työkaluihin liitettiin pikaviestinominaisuuksia, jotka olivat käytännöllisempiä kuin suljetut sähköpostilistat ja näihin liittyvä liikenne. Virtuaalitiimien johtamisen ja niissä työskentelyn haasteet oli huomattu (ks esim (https://hbr.org/2014/12/getting-virtual-teams-right) mutta oli myös viitteitä siitä että oikein organisoituneina ne saattaisivat olla huomattavasti tehokkaampia kuin perinteiset tiimit joissa jäsenet istuivat fyysisesti samassa työtilassa.

Pikku hiljaa työvälineet kehittyivät. Käyttöliittymän objekteihin tuli uusia ominaisuuksia. Niitä saattoi lajitella ja järjestää yhä useammilla tavoilla. Taskeja voitiin osoittaa useammille ihmisille. Niitä voitiin linkittää toisiinsa eri attribuuttien mukaan – projekti, yritys, henkilö, asiakas. niin kuin relaatiotietokannassa ikään. Tämä ei enää onnistu fläppitaululla ja post-it lapuilla, eli työkalut toivat mukanaan mahdollisuuksia joita ennen niiden käyttöönottoa ei voitu soveltaa.

Sitten oli pitkään hiljaista. Ja 2010-luvulle tultaessa keskustelu räjähti uudestaan käsiin. Digitalisaatio tarkoittaa nyt monille aivan eri asioita kuin 15 vuotta sitten. Siinäkin on ainakin kaksi näkökulmaa, joita yritän nyt vajavaisen ymmärrykseni avulla avata.

Ensinnäkin prosessien ja muiden tehtävien automatisointi. Jenkkikirjailija Dan Pink puhuu kirjassaan algoritmisesta työstä ja hermeneuttisesta työstä. Olen itse ajatellut että edellinen on ikään kuin suorittavaa ja korkeintaan optimoivaa työtä. Jälkimmäisen olen ristinyt ymmärrystyöksi. Nimenomaan algoritminen työ uhkaa kadota tai vähintäänkin muuttaa työtehtäviä järisyttävästi. Luin McKinseyn raportin, jonka pääviesti oli että vähemmistö työpaikoista tulee katoamaan modernin robotisaation myötä, mutta se kyllä muuttaa enemmistöä työtehtävistä. Se poistaa osan niiden sisällöstä, joten tilalle tarttis keksiä uutta tai uhkana on että tehtävistä selviytyy huomattavasti nykyistä pienempi työntekijäjoukko. Sitä intialaista testaajaa ei enää tarvita konffaamaan toiminnanohjausjärjestelmää kun se voidaan tehdä automaattisesti. Assistentteja ei tarvita buukkaamaan tapaamisia, jos sen hoitaa itse Sirillä. Tänään luin talouslehdistä, että suuri pankki aikoo automatisoida useita tähän asti ihmisten hoitavia prosessinpätkiä, kuten lainanhakijan luottotietojen tarkistamisen. Projekteissakin – jos työkalut ovat saatavissa ja niitä käytetään oikein – suorittavan työn määrä vähenee.

Ja sitten on se varsinainen iso D eli big data. Ja painotuksen pitäisi tässä olla B:llä, sillä datan määrän kasvua on melko vaikea käsittää. Joidenkin mukaan on-line käytettävissä olevan tiedon määrä kaksinkertaistuu joka vuosi. Noo, olen lukenut paljon kuumottavampiakin lukuja. Esimerkiksi vuonna 2015 julkaistussa Forbesin artikkelissa kerrottiin, että kahden edellisen vuoden aikana dataa eli merkkimuotoista raakainformaatiota on syntynyt enemmän kuin ihmiskunnan siihenastisessa historiassa. Sylttytehtaita on ainakin kaksi: hakukoneet ja sosiaalinen media. Google-hakuja teemme 40.000 sekunnissa ja jokainen niistä luo uutta informaatiota. Jokainen Facebook-tykkäyksesi tai kommenttisi luo uutta informaatiota.

Algoritmit toki toimivat myös keinoälyn taustalla. Niistä vaan näyttää tulevan (ja ehkä on jo tullut) niin mutkikkaita ettei kukaan pysty niitä hallitsemaan. Jos ajatellaan projekteja, tekoäly siis kykenee tuottamaan esimerkiksi päätöksenteon tueksi tietoa jota emme itse osaa tuottaa.

Mikä on siis ymmärrystyön tulevaisuus? Koneoppimisella on vielä pitkä kehityksen polku edessään. Tekoäly ei käsittääkseni vielä pysty selittämään, miksi Audi on niin cool että siitä kannattaa maksaa puolitoistakertainen määrä verrattuna Skodaan, joka on kuitenkin rakennettu samalle alustalle. Se ei pysty selittämään, miksi amisviikset ovat punavuorelaisella hipsterillä hauskat mutta rautavaaralaisella peräkammarin pojalla nolot. Se ei tiedä miksi kallis mittatilauspuku on Björn Wahlroosin päällä pöyhkeä mutta Arman Alizadilla (siis silloin kun hän vielä käytti julkisuudessa hienoja pukuja) magee. Siis, mitä luovempaa ajattelua ja ymmärrystä työ on, sitä paremmin se näyttäisi olevan turvassa.

Lopulta, monet yritykset ovat heränneet tai alistuneet siihen tosiseikkaan että ihmiset joka tapauksessa elävät somessa ja muutenkin virtuaalisessa maailmassa. Esimerkiksi tietoa onnistuneista tai käynnissä olevista projekteista löytyy paljon Youtubesta. Mitään liikesalaisuuksia siellä ei julkaista, mutta muutoin se on otettu entistä enemmän myös sisäisen viestinnän kanavaksi.

Urheutta unelmasta

Rakas lukija,

Pahoittelut viimeaikojen hiljaiselosta, olen nimittäin valmistellut kirjoitussarjaa, joka käsittelee ihmisten ja tiimin johtamista projekteissa.

Vuonna 2012 julkaisin kirjan nimeltä Avain - Muutosprojektista menestys. Väitän vieläkin, että se on ensimmäinen Suomessa kirjoitettu täysin fiktiomuotoinen bisneskirja. Esikuvina toimivat sellaiset maailmalla menestystä niittäneet opukset kuin The Goal, The Deadline, One Minute Manager ja Who Moved my Cheese? - kaikki business fable -genreä eli tarinoiksi kirjoitettuja.

Olen taustaltani käyttäytymistieteilijä ja aina ollut kiinnostunut siitä, mitä tapahtuu kun useampi kuin kaksi ihmistä kohtaa toisensa. Koulutustaustastani, omista kokemuksistani ja erilaisilta valmennusryhmiltä kuullustani ammensin sisällön kirjaan, jonka oleisista opeista julkaistaan nyt seitsemän kirjoituksen sarja. Muuten, ellet jostain kumman syystä vielä omista kirjaani, voit nyt hankkia sen Kansanvalistusseuran nettikaupasta erikoishintaan 15 € + postituskulut (ovh. 35 €). (http://kvskauppa.fi/tuote/aaro_ollikainen/avain_muutosprojektista_menestys/9789519140636)

Uutiskirjeet löytyvät myös LinkedIN-julkaisuistani. Ensimmäinen uutiskirje käsittelee innostavan unelman, tylsemmin vision tai tavoitetilan kirkastamista projektillesi. (https://gallery.mailchimp.com/af9969da14351a489224f4a7e/files/Promotive_kayttoopas_projektipaallikolle_osa_1.pdf)

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.