Kuinka toteuttaa tehokas retrospektiivi ja soveltaa oppeja tuleviin projekteihin

Lue litterointi:

 

Kokeilemme podcastiemme litterointia ohjelmistolla. Antakaa anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole täysin oikeassa joka kerta.

Galen Low: Hei kaikille ja kiitos, että kuuntelette. Nimeni on Galen Low, ja edustan The Digital Project Manageria. Olemme digitaalisten ammattilaisten yhteisö, jonka tavoitteena on auttaa toisiamme kehittämään taitojamme, kasvattamaan itseluottamustamme ja verkostoitumaan, jotta voimme vahvistaa projektinhallinnan arvoa digitaalisessa maailmassa. Jos haluat kuulla siitä lisää, siirry osoitteeseen thedigitalprojectmanager.com.

Tänään puhumme projektien retrospektiiveistä: miten ne toteutetaan tehokkaasti ja miten varmistetaan, että retrospektiiveissä kerätyt opit todella muuttuvat tulevien projektien parannuksiksi.

Seurassani on tänään Payson Hall, Catalysis Groupin perustaja ja pääkonsultti. Hän on auttanut organisaatioita oppimaan projektien virheistä jo yli 30 vuoden ajan.

Payson, hienoa saada sinut mukaan ohjelmaan.

Payson Hall: Hei, mukava olla mukana ja tavata yleisö.

Galen Low: Kyllä, ja olen iloinen, että mainitsit tuon, koska teemme tänään jotakin hieman erilaista. Olemme suorassa lähetyksessä jäsentemme kanssa studioyleisönä, ja otamme kysymyksiä lennosta Slack-yhteisömme kautta. Michael on myös studiossa kanssani, joten hän täydentää joitakin kysymyksiä. Tuomme ne mukaan keskusteluun, ja mitä tahansa voi tapahtua. Tehdään tästä vilkas.

Hyvä on, aloitetaan. Ajattelin aloittaa herkullisella kysymyksellä, koska olemme puhuneet tästä ja olet toteuttanut projektien retrospektiivejä konsulttina jo vuosikymmenten ajan monenlaisissa projekteissa, kuten ohjelmistoprojekteissa ja laajoissa järjestelmäintegraatioprojekteissa. Haluaisin kysyä sinulta tätä: kun tulet ulkopuolisena konsulttina kaivamaan esiin projektin kaikki likaiset pikku salaisuudet, näkevätkö projektiryhmät sinut ystävänä vai vihollisena? Tuntuuko siltä, että he saavat mentorointia? Vai tuntuuko siltä, että heitä auditoidaan?

Payson Hall: Tavallisesti kyse on ystävällisestä vuorovaikutuksesta. Haluaisin tehdä eron, koska yksi osa konsultointityöstäni on projektien ruumiinavausten tekeminen. Jos projekti ajautuu pahasti raiteiltaan ja on huolestuttavaa, että ihmiset tiesivät sen menevän väärään suuntaan mutta eivät sanoneet mitään, tilanne muistuttaa paljon enemmän auditointia.

Itse asiassa työskentelen Kalifornian osavaltion tarkastajan kanssa ja olen auditoinut miljardien dollarien IT-projekteja. Niissä yleensä pyritään rakentamaan asianajajille oikeusjuttu, jonka avulla voidaan haastaa järjestelmäintegraattori. Tavallisempi ja ystävällisempi retrospektiivi on yksinkertaisesti sitä, että ihmiset sanovat: Hei, saimme tämän projektin päätökseen.

Tuodaan joku vetämään jälkikäteinen tarkastelu, eikö niin? Sitä retrospektiivi tarkoittaa. Katsotaan taaksepäin ja kysytään: mitä opimme? Mitä teimme nokkelasti, vaikka emme ehkä huomanneet sitä silloin? Mitä teimme tavalla, jonka olisimme jälkikäteen halunneet tehdä toisin? Se on oikeastaan riskienhallintaistunto, jossa katsotaan taustapeiliin. Mitä voin tehdä ensi kerralla paremmin? Mitä tein nokkelasti ja haluan varmistaa tekeväni jatkossakin enemmän?

Galen Low: Pidän tuosta erottelusta todella paljon, koska jotkut kuuntelijat eivät ehkä koe eroa samalla tavalla. Jokainen retrospektiivi voi tuntua ruumiinavaukselta tai siltä, että heistä tulee oikeudessa käytettävää todistusaineistoa. Se voi tuntua syyllisten etsimiseltä sen sijaan, että vain katsottaisiin taustapeiliin ja opittaisiin virheistä.

Payson Hall: Yksi retrospektiivin harvoista suurista säännöistä on tämä: projektipäällikkönä ei pitäisi koskaan vetää omaa retrospektiiviään. Jotkin huonosti menneet asiat ovat nimittäin asioita, joita itse teit. Hyvä fasilitaattori voi huolehtia siitä, ettei sinua naulita seinälle. Hän tekee keskustelusta kysymyksiä kuten: mitä tapahtui, milloin se tapahtui ja mitä opimme tästä? Ei sitä, että no, Galen, sinä mokasit todella pahasti.

Se ei ole rakentavaa. Ihmiset puolustautuvat ja tilanne ajautuu raiteiltaan. Riippumatta siitä, tuotko jonkun ulkopuolelta vai onko organisaation sisällä joku, jota arvostat ja johon luotat ja joka on hyvä fasilitaattori, haluat keskustelun vetäjäksi ulkopuolisen henkilön, joka ei ollut mukana projektissa eikä ole itse pelissä mukana. Näin keskustelu voidaan käydä niin, ettei lattialla ole lopuksi paljon verta.

Galen Low: Se on reilua. Ja oikeastaan todella kiinnostava näkökulma, koska tiedän monien avaavan tämän jakson yrittääkseen selvittää, miten he toteuttavat oman retrospektiivinsä.

Ja ilman muuta ymmärrän, että se on monille projektiryhmille todellisuutta. Käymme läpi myös joitakin matkan varrella oppimiasi vinkkejä ja asioita. Pidän kuitenkin neuvostasi, että fasilitaattorina voi olla joku muu — ja ehkä pitäisi olla joku muu — jotta keskusteluun saadaan toinen näkökulma ja jotta se ei muutu syyllisten etsimiseksi. Eikä lattialla ole jälkikäteen paljon verta, kuten sanoit.

Payson Hall: Sellainen henkilö voi tulla mukaan erilaisten oletusten kanssa. Mieti projekteja, joissa olet ollut mukana. Projektin aikana teit oletuksia siitä, mitkä asiat aiheuttivat ongelmia. Ne voivat olla oikeita tai vääriä. Henkilö, joka tulee mukaan ilman näitä oletuksia, voi olla avoin muulle tiedolle tai muille tulkinnoille.

Galen Low: Pidän tuosta. On hienoa saada mukaan sellainen näkökulma henkilöltä, joka ei ollut mukana pitkässä, esimerkiksi 12–18 kuukautta kestäneessä projektissa ja joka ei ole niin lähellä sitä, ettei enää näe metsää puilta.

Voisimme ehkä aloittaa yleisistä asioista. Loitonnetaan hieman ja annetaan kuuntelijoille perusta. Voitko omasta näkökulmastasi selittää, mikä projektin retrospektiivi on ja miksi sellainen kannattaa toteuttaa?

Payson Hall: Hyvä kysymys. Retrospektiivin sana tarkoittaa taaksepäin katsomista. Ajatuksena on, että projektissa saavutetaan merkittävä vaihe tai projekti päättyy. Katsomme taaksepäin ja sanomme: selvä, hengähdetään hetki. Mitä opimme tästä viimeisestä jaksosta? Mitkä opit haluamme soveltaa seuraavaan jaksoon tai seuraavaan projektiin?

Mitä teimme vahingossa nokkelasti? Tai mitä teimme niin, että ajattelin: jos voisin tehdä tämän uudelleen, lähettäisin itselleni viestin aikakoneella ja kertoisin, mitä olisin halunnut tehdä toisin. Ajatuksena on yksinkertaisesti pysähtyä hetkeksi ja tarkastella projektin tapahtumia niiden asiayhteydessä.

Kuten sanoit, loitonnetaan ja muodostetaan kokonaiskuva, jotta ymmärrämme, mikä on tärkeää ja mikä ei. Jotkin asiat ovat vain mustia joutsenia. Kyseessä oli odottamaton tapahtuma, kuten COVID. En useimmissa tulevissa projekteissa suunnittele pandemioita varten, mutta jos sellainen osui omaan projektiisi, se vaikutti siihen.

Siitä voi ehkä oppia jotakin, mutta jotkin asiat ovat vain asioita, joihin ei voi varautua. Jos esimerkiksi tarvitsit tusinan kannettavia tietokoneita, tilasit 14 siltä varalta, että pari olisi käyttökelvottomia heti alussa, ja yksi niistä todella oli käyttökelvoton, se oli erittäin nokkela ratkaisu, koska aikataulusi oli tiukka.

Silloin voi todeta, että kahden muun kannettavan tietokoneen kustannusten vertaaminen vältettyyn viivästykseen voi olla todella hyvä oppi. Ylimääräinen tietokone ei välttämättä ole romua. Sen voi ehkä palauttaa. Sopimukseen voidaan kirjata oikeus palauttaa se, jos pakkausta ei ole avattu.

Se saattoi olla tuhat dollaria todella hyvin käytettyä rahaa. Se säästi kolmen viikon viivästyksen. Jos olet työskennellyt laitteistojen kanssa viimeisten kolmen vuoden aikana toimitusketjujen ollessa täysin sekaisin, tiedät tarkalleen, mistä puhun.

Galen Low: Ehdottomasti. Pidän tuosta esimerkistä, ja siinä on jotakin todella tärkeää, jota ihmiset eivät tavallisesti ajattele: retrospektiivit voivat olla hetki pohtia jotakin, mikä meni todella hyvin — jotakin nokkelaa ja hienoa.

Retrospektiivissä kysytään usein, mikä meni hyvin, ja vastaus on, että tiimi työskenteli hyvin yhdessä ja viestintä toimi. Mutta selkeä oppi voi olla esimerkiksi se, että joku varasi vaihtoehtoisen kokoushuoneen, kun ensisijainen tila peruuntui. Meillä oli varasuunnitelma, ja se oli hienoa. Se pitäisi ottaa opiksi ja sisällyttää prosessiimme seuraavaa kertaa varten. Ja kuten sanoit, sopimukseen voidaan kirjata, että ylimääräisen kannettavan tietokoneen voi palauttaa avaamattomana. Näin olemme turvassa ja voimme hyödyntää oppia tulevissa projekteissa.

Toinen asia, josta pidin, oli se, että retrospektiivi toteutetaan joko projektin lopussa tai merkittävän projektin sisäisen tapahtuman jälkeen. Monet tuntemani ihmiset ajattelevat, että retrospektiivi tarkoittaa projektin loppua ja silloin on liian myöhäistä. Voimme katsoa taustapeiliin, mutta mukana on surumielinen sävy: tämä olisi voinut mennä paremmin, mutta nyt on liian myöhäistä. Meidän on odotettava seuraavaa projektia. Sen sijaan projektin aikana on muitakin kohtia, joissa retrospektiivin voi toteuttaa. Haluaisin palata tähän myöhemmin.

Payson Hall: Kyllä. Se on yksi kiinnostavista asioista, joita ketteristä menetelmistä saadaan, koska niissä tehdään yleensä pieni retrospektiivi jokaisen sprintin lopussa. Olen työskennellyt projekteissa, joissa retrospektiivit toteutettiin suurempien projektien virstanpylväiden kohdalla, mutta ketterät menetelmät sanoivat tavallaan: miksi emme tekisi näitä jaksoittain?

Kun retrospektiivejä tehdään useammin, ne ovat pienempiä. Tiimi oppii ymmärtämään prosessin ja pystyy osallistumaan siihen ja saamaan sen päätökseen. Mielestäni ketterien menetelmien kehittäjät tekivät hienon innovaation kiteyttäessään ajatuksen retrospektiiveistä jokaisen sprintin lopussa.

Galen Low: Pidän tuosta ajattelutavan muutoksesta: voimme tehdä tämän säännöllisemmin, jolloin yksittäinen retrospektiivi on pienempi. Jos kuitenkin asettuisin vastarannan kiiskeksi, uskon monien organisaatioiden sanovan haluavansa oppia virheistään ja epäonnistua nopeasti. Mutta käytännössä kaikki organisaatiot eivät ole valmiita investoimaan taaksepäin katsomiseen. He sanovat, että opimme sen jo matkan varrella, emme tarvitse siitä erillistä kokousta, vaan siirrytään seuraavaan asiaan.

Mitä kunnollisen projektin retrospektiivin toteuttaminen vaatii? Ja kannattaako se? Jos organisaatio sanoisi, että ihmiset kokivat vaikeudet projektin aikana ja nyt pitäisi vain jatkaa eteenpäin, mitä vastaisit?

Payson Hall: Hyvä kysymys. Kun puhumme prosessien parantamisesta, haluamme varmistaa, etteivät oppimisen ja parannuksen kustannukset ylitä parannuksesta saatavaa arvoa. Mitä retrospektiivin toteuttaminen siis vaatii? Annan esimerkin ja käyn sen läpi. Ensimmäiseksi sanoisin, että asiayhteydellä on merkitystä.

Jos puhumme miljoonien tai miljardien dollarien projektista, se vaatii paljon enemmän työtä kuin pieni projekti. Myös dataa on paljon enemmän. Jos projekti on ongelmallinen, siihen kuluu enemmän työtä kuin suhteellisen sujuvasti edenneeseen projektiin. Jos projekti romahtaa ja asianajajat tulevat mukaan, et tee retrospektiiviä vaan ruumiinavausta, ja ne voivat olla hyvin kalliita.

Tässä yksi esimerkki. Toteutin äskettäin retrospektiivin noin 12 henkilön tiimin kanssa projektista, joka kesti noin 18 kuukautta. Se oli sisäinen projekti, jossa oli tusinan verran ihmisiä. Projekti kesti noin 18 kuukautta, täytti vaatimukset ja myöhästyi hieman hyväksyttävällä tavalla. Asianajajia ei tarvittu.

Kysymys oli: olemme päässeet loppuun, hengähdetään hetki. Mitä opimme? Mitä voimme tehdä toisin? Yksittäiset tiimin jäsenet käyttivät valmistautumiseen, kokoukseen ja jälkipuintiin todennäköisesti neljästä kuuteen tuntia. Fasilitaattorina käytin ehkä tusinan tuntia valmistautumiseen, fasilitointiin ja lopputuloksen kirjoittamiseen.

Projektipäällikkö käytti ehkä 8–12 tuntia tietojen toimittamiseen ja asioiden läpikäyntiin kanssani. Retrospektiivi vei siis yhteensä noin kaksi henkilöviikkoa työtä. Kaksi henkilöviikkoa. Jos ajattelemme tusinaa henkilöä ja projektipäällikköä, jotka työskentelivät 18 kuukautta, kyse on noin tuhannesta henkilöviikosta.

Toisin sanoen 0,2 prosenttia käytettiin taaksepäin katsomiseen ja sen ymmärtämiseen, mitä opimme, mitä voimme tehdä toisin ja mitä teimme nokkelasti. Ajattele asiaa näin: tarvitsee löytää vain tapa säästää kahden henkilöviikon verran työtä, ja investointi on jo maksanut itsensä takaisin.

Tämä voi tapahtua kahdella tavalla. Se voi olla rakenteellista: esimerkiksi suositus projektinhallintatoimistolle siitä, että jokin asia tehdään jatkossa eri tavalla, mikä säästää aikaa ja vaivaa. Se voi olla myös orgaanista. Voimme huomata, että tässä projektissa varmistimme koodikatselmoinnin toteutumisen, ja se auttoi todella paljon. Kokeilimme sitä, ja siitä oli hyötyä. Seuraavassa projektissa kaikki tiimin jäsenet kantavat oppia mukanaan ja voivat edistää sitä.

En ole koskaan nähnyt retrospektiiviä, jossa emme olisi lopuksi koonneet havaintoja, suosituksia ja ehdotuksia. Mielestäni se on vähintään niiden kahden henkilöviikon arvoinen, jotka investoimme.

Galen Low: Selvä. Puhumme suuremmista projekteista, mutta onko pienille projekteille olemassa alarajaa? Jos projekti kesti vain neljä viikkoa, kahden henkilöviikon investointi voi vaikuttaa liian suurelta. Jätättekö retrospektiivin tekemättä? Yhdistättekö viisi pientä projektia ja toteutatte yhteisen retrospektiivin?

Payson Hall: Ei. Se oli oikeastaan urani alussa tekemäni virhe.

Retrospektiiviin ei pidä ottaa ketään, joka ei ollut mukana projektissa. Oletetaan, ettei tiimi ole keskenään sodassa. Kun käydään avointa keskustelua siitä, mikä toimi ja mikä ei, ihmiset voivat sanoa: minä mokasin tämän tai olisin voinut tehdä sen toisin.

Ihmiset ovat paljon mukavampia tekemään niin tiimin kanssa, jonka kanssa he ovat työskennelleet läheisesti, eivät tuntemattomien kanssa. En siis yhdistäisi retrospektiivejä. Kun on tehty useita pieniä retrospektiivejä, projektipäälliköt voidaan toki koota yhteen ja etsiä yhteisiä teemoja, jos projektinhallintatoimisto haluaa tehdä niin.

Retrospektiiviin en kuitenkaan halua turisteja. Haluan, että mukana on vain tiimi. Voimmeko tehdä tämän pienessä mittakaavassa? Ehdottomasti. Virallisen prosessin käyn läpi hetken kuluttua. 18 kuukauden projektissa ihmiset tuntevat usein pyörivänsä hamsterinpyörässä päivästä toiseen. Merkittäviä tapahtumia on, mutta asiayhteys katoaa helposti.

Kolmen tai neljän viikon projektissa kokoontuminen tunniksi voisi riittää useimpiin asioihin. Haluaisin valmistautua hieman ja varmistaa, että ymmärrän projektin sekä sen, mitä projektipäällikkö haluaa saavuttaa. Mutta kyllä, tällaisen retrospektiivin voisi toteuttaa melko epämuodollisesti tunnissa tai kahdessa.

Galen Low: Mainitsit tämän aiemmin. Ketterässä viitekehyksessä retrospektiivi voidaan tehdä jokaisen sprintin jälkeen. Projektin lopussa voidaan ehkä vielä koota kaikki opit yhteen ja tehdä niiden perusteella suosituksia. Pidän ajatuksesta, ettei kahden henkilöviikon työmäärän tarvitse tapahtua kokonaan projektin lopussa.

Payson Hall: Jos tiimissä on kahdeksan henkilöä, kaikkien kokoaminen samaan huoneeseen tunniksi tarkoittaa kahdeksaa henkilötyötuntia. Kun mukaan lasketaan valmistautuminen ja projektipäällikön työ, koko prosessi voidaan ehkä toteuttaa 12 tunnissa. Siihen sisältyy yhden sivun luettelo siitä, mitä opimme.

Galen Low: Mukana ovat myös vaihtoehtoiskustannukset. Jos käytämme tunnin ja löydämme opin, joka säästää joka kerta puoli miljoonaa dollaria, investointi on maksanut itsensä moninkertaisesti. Myös retrospektiivin tekemättä jättämisen kustannuksia kannattaa ajatella.

Mainitsit aiemmin sisäiset tiimit. Monet kuuntelijat työskentelevät toimistoissa, joissa asiakkaat eivät halua maksaa retrospektiivistä, koska heidän mielestään organisaation pitäisi itse kehittyä. Toisaalta johtokaan ei halua investoida siihen, koska aika ei ole laskutettavaa. Miten projektin johtajat voivat puolustaa tällaista oppimista ja vakuuttaa omistajat ja johtoryhmät retrospektiivin arvosta?

Payson Hall: Yritän olla kohtelias, mutta jos toimitusjohtaja tulee paikalle ja sanoo, ettei seuraavaa projektia tarvitse tehdä tätä paremmin eikä mitään ole opittavaa, päivittäisin ansioluetteloni. Se huolestuttaisi minua suuresti.

Ennen Catalysis Groupin perustamista työskentelin neljä vuotta IBM:n konsultointipalveluissa monimiljoonaisissa projekteissa. Olet oikeassa: yleensä asiakas ei maksa tästä, vaan organisaatio maksaa. Organisaatio maksaa, koska se haluaa tietää, miten asiakastyytyväisyyttä ja tehokkuutta voidaan parantaa ja missä tehtiin virheitä prosessien kehittämiseksi.

Konsultointiyrityksessä kannattaa pysähtyä miettimään, mitä veloitat tunnilta. Kuinka monta tuntia täytyy säästää, jotta siitä syntyy arvoa? Jos hallinnollinen työ kuuden henkilön kanssa kestää tunnin ja löydämme tavan säästää seuraavassa projektissa neljä päivää, retrospektiivi on maksanut itsensä moninkertaisesti.

En tiedä kyseisen tilanteen asiayhteyttä. Organisaatio saattoi menettää rahaa ja toimitusjohtaja tarvitsi tuloja. Yleisesti ottaen kokemukseni mukaan tätä ei ole vaikea perustella. Yksi tapa on aloittaa pienestä. Jos kyseessä on lyhyt projekti, kokoontukaa lounaalla tai varatkaa tunti.

Aloita pienestä, jotta investointi ei ole suuri.

Galen Low: Aloita pienestä ja kerää näyttöä. Voit sanoa, että tämä tuotti arvoa viime kerralla. Joissakin tilanteissa on ehkä parempi pyytää anteeksi kuin lupa ja hankkia sen jälkeen todisteet siitä, että retrospektiivi tuotti hyötyä.

Payson Hall: Retrospektiivin tuloksena syntyy usein asiakirja tai esitys, jossa ovat tärkeimmät havainnot. Sen voi muokata johtoryhmälle sopivaksi. Jos se on laadittu hyvin, se auttaa johtoa ymmärtämään, että joskus myös johto aiheuttaa ongelmia.

Resurssien siirtäminen vähäisellä varoitusajalla tai väärän dollarin säästäminen voivat olla tällaisia asioita. Jos emme halua maksaa hotelliyötä ja lennätämme henkilön yön yli toiselle rannikolle, hän on saapuessaan aivokuollut. Retrospektiivissä nämä opit voidaan tuoda esiin rakentavasti ja auttaa johtoa suuntaamaan toimintaansa tuottavampaan suuntaan.

Galen Low: Pidän tästä strategisen viestinnän näkökulmasta. Johtoryhmä ei välttämättä saa samaa versiota kuin tiimi, vaan sille voidaan antaa johtamisen kannalta olennainen versio ilman kaikkea yksityiskohtaista likaista pyykkiä.

Payson Hall: Ehdottomasti. En pidä likaisen pyykin vertauksesta kovin paljon. Yksi älykkäimmistä asioista, joita minulle on sanottu, on se, että useimmat ihmiset yrittävät tehdä oikean asian parhaalla mahdollisella tavalla käytettävissä olevien tietojen perusteella.

On helppoa tulla jälkikäteen sanomaan, että tätä ei tehty ja tuokin jätettiin tekemättä. Se ei ole asian ydin. Oletetaan, että ihmiset toimivat parhaansa mukaan käytettävissä olleen tiedon perusteella. Sitten kysytään, mitä tietoa heillä oli, miten voimme saada sen heille aikaisemmin ja miten voimme lähestyä asiaa rakentavasti.

Jos ihmiset luulevat, että etsit jotakuta ristiinnaulittavaksi, et pääse mihinkään eikä prosessista ole hyötyä.

Galen Low: Selvä. Haluaisin siirtyä prosessiin. Oletetaan, että kaikki ovat mukana ja aiomme toteuttaa projektin retrospektiivin. Miltä sinun prosessisi näyttää? Voisitko käydä sen läpi ikään kuin olisin kyseisen projektin projektipäällikkö?

Payson Hall: Oletetaan, että päätämme vuoden kestäneen projektin. Se on suuri projekti, jossa on 10–12 henkilöä. Ensimmäiseksi haluan tavata sinut.

Olet projektipäällikkö, joten haluan rakentaa kanssasi luottamuksellisen suhteen. Jos kutsuit minut mukaan, tämä on helppoa. Jos johtajat tai projektitoimisto määräsi minut mukaan, minun täytyy kannustaa sinua luottamaan minuun. Selitän prosessin, jotta tiedät, mitä odottaa.

Lupaan, etten yllätä sinua. Näet kaikki löytämäni havainnot ennen muita. Saat mahdollisuuden perustella näkemyksesi, muuttaa mieleni, antaa lisää tietoa tai esittää toisen tulkinnan.

Se vähentää projektipäällikön stressiä. En halua, että pelkäät minua tai piilottelet asioita. Se on yksi suurimmista ongelmista. Jos keskustelisit poliisin kanssa ja alkaisit käyttäytyä epäilyttävästi, tämän korvat terävöityisivät ja niskakarvat nousisivat pystyyn. Keskustelu on paljon parempi lähtökohta.

Kun luottamus on rakennettu, selitän prosessin. Ensimmäiseksi haluan ymmärtää, mitä lähditte tekemään. Onko olemassa määrittelyasiakirjoja, raportteja tai muistioita? Mikä projektin määritelmä oli?

Hyvät projektinhallintakäytännöt edellyttävät jonkinlaista projektin perustamisasiakirjaa tai määritelmää, jossa kerrotaan, mitä yritämme saavuttaa. Ihmiset tekevät tämän eri tasoisesti, mutta minun täytyy ymmärtää, mitä luulitte yrittävänne tehdä.

Sen jälkeen haluan ymmärtää, miten asia muuttui. Etsin yleensä dokumentaatiota. Kysyn, oliko määritelmä kirjattu jonnekin. Se voi olla vaatimusmäärittely, projektin perustamisasiakirja tai jokin muu vastaava. Kysyn, miten se muuttui matkan varrella ja oliko muutospyyntöjä.

Yritän selvittää, mistä aloitettiin ja miten projekti kehittyi ajan myötä. Kaikki projektit kehittyvät. Pitkän projektin aikana työkaluja vaihdetaan ja ohjelmistoversioita päivitetään.

Asiantuntijana voin auttaa tulkitsemaan tapahtumia. Jos esimerkiksi vuoden mittainen projekti törmäsi kolmen kuukauden kohdalla PeopleSoft-päivitykseen ja sen korjaaminen kesti kuukauden, voin todeta raportissa, ettei viivästys ollut projektipäällikön syytä. Tulevaisuudessa pitäisi joko välttää ohjelmiston päivittämistä projektin aikana tai varata päivitykseen aikaa aikataulussa.

Aloitan keräämällä mahdollisimman paljon taustamateriaalia, jotta en kuormita projektipäällikköä. Tarvitsen määritelmän, muutospyynnöt, riskienhallinnan tiedot ja tilanneraportit. Yksi parhaista tavoista oppia projektinhallintaa on lukea vuoden verran tilanneraportteja.

Niistä näkee, miten jokin pieni tapahtuma toisessa kuukaudessa kasvaa seuraavassa kuussa suuremmaksi ja muuttuu neljännessä kuussa täysimittaiseksi ongelmaksi. Ihmiset eivät välttämättä piilotelleet asiaa, vaan eivät ymmärtäneet sen merkitystä.

Käyn materiaalit läpi ja teen muistiinpanoja poikkeamista. Missä aikataulu muuttui? Selittikö tilanneraportti, riskiloki tai muutosloki muutoksen? Rakennan Excelissä tai Wordissa karkean aikajanan, jotta saan projektin tapahtumat järjestykseen.

Kun projektipäällikkö on ymmärtänyt, että olen paikalla auttamassa, pyydän tiimiä käyttämään 60–90 minuuttia valmistautumiseen. Pyydän heitä miettimään kolmea asiaa: mitkä olivat kiinnostavia tapahtumia, mitkä asiat menivät onnekkaasti tai nokkelasti ja mitkä olivat hidastaneet meitä tai aiheuttaneet ongelmia.

Jokaisella on erilainen näkemys tapahtuneesta. Siksi teen seinälle karkean aikajanan merkittävistä etapeista ja tapahtumista. Annan osallistujille muistilappuja ja kysyn, mitä tapahtumia he muistavat.

Tapahtumat auttavat ihmisiä sijoittamaan asiat ajallisesti. Sen jälkeen keskustelemme hyvistä asioista ja hidasteista. Rakennamme näkyvän aikajanan, joka näyttää, miten projekti kehittyi.

Usein tämä tuo esiin uusia havaintoja. Esimerkiksi uusi sidosryhmä saatettiin vaihtaa projektin puolivälissä, mutta hänelle ei järjestetty perehdytystä. Sen seurauksena tiimi sai kuukausien ajan uusia kysymyksiä ja keskeytyksiä. Aikajanan avulla syy-seuraussuhde voidaan havaita.

Seuraavaksi teemme riskienhallintaa jälkikäteen. Tarkastelemme merkittäviä tapahtumia ja kysymme kolme kysymystä: mitä olisimme voineet tehdä havaitaksemme mahdollisuuden, riskin tai ongelman aiemmin? Mitä olisimme voineet tehdä hyvän asian todennäköisyyden kasvattamiseksi tai huonon asian todennäköisyyden pienentämiseksi? Mitä olisimme voineet tehdä huonon seurauksen lieventämiseksi tai hyvän asian hyödyn lisäämiseksi?

Näin syntyy lopullisen raportin luonnos: mitä tiimi lähti tekemään, mitä se saavutti, kuinka paljon se maksoi, kuinka kauan se kesti, mitä tehtiin hyvin, mitä tapahtui epäonnistuneesti ja mitä tulevaisuudessa voidaan tehdä ongelmien vähentämiseksi.

Retrospektiiviraportista ei pidä tehdä puhelinluetteloa, jota kukaan ei lue. Sen pitäisi olla yksi tai kaksi sivua tai tiivis esitys, jossa kerrotaan muutama tärkeä asia, joita voimme hyödyntää prosessin parantamisessa.

Galen Low: Puhutaan syvyydestä. Keskustelemme virstanpylväistä ja projektin aikana tapahtuneista asioista. Kaikki hahmottavat aikajanan. Jotkut voivat tuoda esiin 10, 15 tai 20 asiaa. Käydäänkö niitä perusteellisesti läpi heti, vai tunnistetaanko ne ensin ja palataanko niihin myöhemmin kolmen kysymyksen avulla?

Payson Hall: Se on harkintakysymys. Haluan antaa ihmisille riittävästi aikaa oivallukseen, mutta en halua lähteä sivupolulle, joka venyttää kokousta kohtuuttomasti tai katkaisee keskustelun.

Kuinka paljon juurisyyanalyysiä tehdään? Jos keskustelu tuottaa hyötyä kolme tai viisi minuuttia, jatketaan. Kun keskustelu ei enää ole tuottavaa, sanomme, että tutkimme asiaa tarkemmin kokouksen ulkopuolella niiden henkilöiden kanssa, jotka liittyvät siihen läheisimmin.

Galen Low: Siksi tarvitaan fasilitointitaitoa. Vaikka et itse fasilitoisi, on hyödyllistä ymmärtää, ettei kaikkia maailman ongelmia ratkaista yhdessä istunnossa. Osa viedään eteenpäin muualla, mutta suurista asioista pitää pystyä keskustelemaan ja löytämään parannuksia tai hyödyntämään projektin aikana syntyneitä hyviä ideoita.

Payson Hall: Ehdottomasti. Hyvä ulkopuolinen fasilitaattori kysyy, etenemmekö rakentavasti ja miten tämä liittyy suurempaan kokonaisuuteen. Olen itse entinen insinööri, joten hyvä ongelma houkuttelee syvälle yksityiskohtiin, mutta se ei aina auta. Tarvitaan joku, joka pitää kokonaisuuden mielessä.

Galen Low: Pidän näkökulmasta, jossa kyse on tuleville projektiryhmille tai tulevalle itsellesi jaettavan raportin luonnoksesta. Kukaan ei välttämättä halua palata pitkään kalanruotokaavioon etsimään juurisyytä.

Sanoit myös, että kyse on riskienhallinnasta jälkikäteen. Riskienhallinta nähdään usein tulevaisuuteen suuntautuvana toimintana: miten autamme hyviä asioita tapahtumaan ja estämme huonoja asioita. Retrospektiivin ja riskienhallinnan yhteys ei ole kaikille ilmeinen, mutta viesti on kuin pulloon laitettu kirje tulevaisuuden ihmisille siitä, miten vältetään tapahtunut huono asia tai hyödynnetään hyvä asia.

Payson Hall: Ehdottomasti. Keskeistä on, että keskustelun pitää koskea sitä, mikä toimi ja mikä ei, ei sitä, kuka toimi ja kuka ei.

Fasilitaattorin tehtävä on estää syyllisten etsiminen. Olin kerran mukana tilanteessa, jossa tiimi oli päättänyt yhden projektin ja aloittamassa seuraavaa. He olivat toteuttamassa retrospektiiviä, ja tein jotakin typerää: kutsuin itseni mukaan.

Yksi tiimin jäsen sanoi, ettei aio osallistua, koska kaikki syyttäisivät häntä siitä, mikä meni pieleen. Menin mukaan tarkkailijana, ja fasilitaattori oli surkea. Hän halusi tietää, kuka oli vastuussa mistäkin, vaikka se ei ole retrospektiivin kysymys.

Tiimi kieltäytyi heittämästä henkilöä bussin alle ja sanoi, ettei sillä ole merkitystä, kuka teki asian. Merkitystä on sillä, mitä tapahtui. Myöhemmin selvisi, että henkilö oli alkoholisti ja hänellä oli vakava ongelma, mutta se ei kuulunut retrospektiiviin. Kyse oli henkilökohtaisesta asiasta, joka piti käsitellä muualla.

Et voi luottaa siihen, että väsyneet ja turhautuneet ihmiset pystyvät aina osoittamaan näin paljon kurinalaisuutta ja empatiaa. Siksi fasilitaattorin pitää tietää, mitä hän tekee. Keskustelun tulee koskea prosessin parantamista, ei syyllisen löytämistä.

Galen Low: Miten fasilitaattori toimii, jos ihmiset aloittavat syyllisten etsimisen ja keskustelu muuttuu noitavainoksi?

Payson Hall: Ensimmäisellä kerralla annan keltaisen kortin. Sanon, ettei kyse ole siitä, kuka teki mitä. Oletamme, että kaikki tekivät parhaansa käytettävissä olleen tiedon perusteella. Haluamme puhua siitä, mitä tapahtui ja mitä seurauksia sillä oli.

Toisella kerralla voin antaa uuden varoituksen tai pyytää taukoa ja puhua henkilön kanssa erikseen. Tämä ei koske sitä, kuka rikkoi jotakin. Tästä voidaan puhua projektipäällikön kanssa myöhemmin, mutta tässä kokouksessa keskitymme siihen, mitä opimme, mikä toimi ja mikä ei.

Galen Low: Entä jos johtoryhmä tulkitsee raportin rivien välistä ja päättää, että kyse oli jonkun tietyn henkilön syystä?

Payson Hall: Henkilökohtaiset asiat eivät kuulu raporttiin. Projektipäällikön pitää käsitellä ne. Raportissa voidaan sen sijaan todeta, että resurssit muuttuivat projektin aikana ja aiheuttivat seurauksia. Tulevaisuudessa tarvitaan parempia sopimuksia ja ennakkoilmoituksia, jotta projektipäällikkö saa aikaa reagoida ja hankkia korvaavat resurssit.

Jos aikataulussa oletetaan, ettei kukaan sairastu ja kaikkien on työskenneltävä 40 tuntia viikossa, suunnitelma on liian hauras. Ihmiset sairastuvat, heidän lapsensa kaatuvat polkupyörällä ja heidän vanhempansa tarvitsevat apua. Ylikuormitetut resurssit tekevät projektiaikataulusta haavoittuvan.

Galen Low: Pidän tuosta erottelusta. Projektin ongelmista voidaan oppia, mutta henkilökohtaiset henkilöstöasiat eivät kuulu raporttiin.

Payson Hall: Raportin pitää olla myös diplomaattinen. Konsultille maksetaan siitä, että hän kertoo, jos vauva on ruma, mutta uutinen pitää välittää tavalla, joka ei pahenna tilannetta. Oppitunnit kannattaa kuvata myönteisesti: näin toimimme, ja jatkossa suosittelemme tätä. Ei niin, että kaikki meni täysin pieleen.

Galen Low: Miten varmistetaan, että suositukset johtavat muutokseen eivätkä vain pölyty hyllyllä?

Payson Hall: Ensimmäinen ongelma on liian pitkä raportti. Jos teen 30-sivuisen raportin, kukaan ei lue sitä. Raportin pitää olla lyhyt ja havainnot pitää priorisoida. Jos projektipäällikkö löytää kuusi asiaa, joita voisi parantaa, valitaan niistä kaksi tai kolme ja hiotaan viesti johtoryhmälle.

Ei pidä hukuttaa ihmisiä toimenpiteisiin. Muut havainnot voidaan ottaa esiin myöhemmin, mutta tiimi muistaa ne silti. Virallisesti johtoryhmälle voidaan viedä kaksi tai kolme tärkeintä havaintoa. Epävirallisesti retrospektiivin osallistujat kuljettavat opit seuraaviin projekteihin.

Ajatus siitä, että kaikki retrospektiivit tallennetaan suureen organisaation tietokantaan, ei yleensä toimi. Se on liian laajaa ja liian riippuvaista asiayhteydestä. Parasta on viedä johtoryhmälle kaksi tai kolme tärkeää suositusta.

Galen Low: Pidän tästä erottelusta. On strategisia suosituksia, jotka viedään johtoryhmälle, ja epävirallista oppimista, jota tapahtuu joka tapauksessa. Kaikki osallistujat vievät retrospektiivistä jotakin seuraavaan projektiin.

Payson Hall: Kun palaamme riskienhallintaan, retrospektiivi valmistaa ihmiset tunnistamaan riskit tulevissa projekteissa. He eivät puhu hypoteettisista asioista, vaan kokemuksista. Se parantaa seuraavan projektin riskienhallintaa ja levittää opit orgaanisesti organisaatiossa.

Galen Low: Siirrytään yleisön kysymyksiin. Voiko retrospektiivin sijaan tai lisäksi tehdä ennakkotarkastelun eli esikuoleman? Miten riskienhallinta liittyy iteratiivisiin retrospektiiveihin?

Payson Hall: Ne limittyvät. Ketterässä retrospektiivissä kysytään usein, mitkä ovat esteet ja mitä olisi pitänyt tehdä toisin. Näistä syntyy seuraavan sprintin riskien lieventämiseen liittyviä tehtäviä. Retrospektiivi ja riskienhallinta tapahtuvat siis samassa yhteydessä.

Galen Low: Entä jos projektiryhmän resurssit siirretään toiseen projektiin? Miten se kirjataan niin, että sillä voidaan vaikuttaa laajemmin kuin yhden projektin tasolla?

Payson Hall: Muotoilen tämän havaintona: projekti kohtasi resurssihaasteita, koska tiimin jäseniä ohjattiin korkeamman prioriteetin projekteihin. Se on neutraali ilmaisu, joka antaa johdolle mahdollisuuden hyötyä epäilystä.

Suositus voisi olla, että projektille lisätään henkilöstöä jouston lisäämiseksi tai että projektipäällikölle annetaan mahdollisimman paljon ennakkovaroitusta resurssien siirtämisestä. Näin hänellä on aikaa reagoida ja etsiä korvaavat resurssit.

Galen Low: Mitkä ovat retrospektiivin tärkeimmät aiheet, kun aikaa on rajallisesti?

Payson Hall: Se riippuu asiayhteydestä. Kokemukseni mukaan yksi tärkeimmistä asioista on se, oliko projektilla selkeä määritelmä, jonka sidosryhmät, sponsori ja asiakas jakoivat ja hyväksyivät.

Kun määritelmä kehittyy, onko käytössä tehokas muutoksenhallintaprosessi? Jos joku haluaa lisätä joulukuuseen koristeita, niiden pitää maksaa enemmän ja kestää kauemmin. Hallitsematon laajentuminen on yksi alkuperäisistä ongelmista, jotka aiheuttavat monia myöhempiä haasteita.

Galen Low: Pidän tästä. Kaikki liittyy toisiinsa. On tärkeää ymmärtää, mikä on sidosryhmien yhteinen perusta ja mikä näkökulma tuo keskusteluun eniten arvoa.

Payson, aikamme alkaa olla lopussa. Kiitos paljon, että olit mukana. On ollut kunnia saada sinut ohjelmaan. Mistä ihmiset voivat lukea lisää Catalysis Groupin toiminnasta?

Payson Hall: Jos menet osoitteeseen catalysisgroup.com, löydät tietoa koulutuksista ja konsultoinnista. Resurssiosiossa on myös artikkeleita, jotka voi ladata. Niissä käsitellään riskienhallintaa ja riskienhallintaistunnon toteuttamista, ja niistä on hyötyä myös retrospektiivin valmistelussa.

Galen Low: Hienoa. Se kertoo myös siitä, että Payson on erittäin viihdyttävä kirjoittaja. Olen nauranut ääneen jokaiselle lukemalleni artikkelille, mutta vienyt samalla niiden tarinat mukaani. Jos joku ajatteli retrospektiivien ja riskienhallinnan olevan kuivaa, kannattaa tutustua Paysonin materiaaleihin. Lisään linkin ohjelman tietoihin.

Toivon, että kuuntelijat saivat tästä paljon irti. Muutamia kysymyksiä emme ehtineet käsitellä, mutta nostamme ne esiin yhteisössä ja keskustelemme niistä siellä.

Payson Hall: Jos haluat lähettää minulle sähköpostia ja kysyä kysymyksiä, vastaan mielelläni myös lähetyksen jälkeen mieleen tuleviin kysymyksiin.

Galen Low: Siinä kaikki tältä kertaa. Jos haluat liittyä keskusteluun yli tuhannen samanhenkisen projektinhallinnan ammattilaisen kanssa, liity yhteisöömme! Siirry osoitteeseen thedigitalprojectmanager.com/membership saadaksesi lisätietoja. Jos pidit tämänpäiväisestä jaksosta, tilaa podcast ja pysy yhteydessä osoitteessa thedigitalprojectmanager.com.

Kuullaan taas ensi kerralla. Kiitos kuuntelusta.