Living Elaine - Episode 77

I fredags hade jag ett tungt men ändå lyckat möte enligt devisen att ärlighet varar längst. Svidande, men ytterst konstruktiv kritik, har framförts mot såväl sälj- och leveransorganisation. Bakgrunden är en ytterst välplacerad lessons learned-övning i syfte att rensa luften och lägga korten på bordet kring vad som fungerar och inte fungerar i vårt projekt. Som vanligt var det jag som gick först i ledet och levererade den nakna sanningen med risk för att bli hängd för att jag tagit på mig rollen som budbärare. Samtidigt var det värt det eftersom jag inte överlever ett halvår till i en miljö där missnöjet är ett faktum. Jag agerar.

Givetvis kan jag inte delge resultatet, men jag kan dela med mig kring upplägget eftersom det visat sig vara framgångsrikt vid flertal tillfällen. Alltihop baserar sig på 3 frågeställningar:

1. Vad fungerar väl i vårt projekt?
2. Vad fungerar ok, men har förbättringspotential?
3. Vad fungerar inte alls?

Denna gången valde jag att genomföra en workshop där vi i 3 grupper om 4-5 personer diskuterade igenom frågeställningarna för att sedan presentera för de andra grupperna och ha en gemensam diskussion. Vid andra tillfällen har jag valt att samla informationen skriftligt. Allra viktigast är att involverade personer känner sig trygga med att deras inte på något sätt kan härledas till dem på ett sätt som kommer att användas emot dem. Av den anledningen kan det vara olämpligt för chefer eller andra väldigt inflytelserika personer att delta eftersom det riskerar att begränsa utfallet.

I gruppdiskussionerna är det viktigt att försöka få in så många aspekter som möjligt. Styr diskussionen så att den även berör mjuka värden och inte bara kring teknik. Annars är risken stor att resultatet blir en lång lista på tekniska problem som måste lösas och inte ett enda organisatoriskt eller relationsrelaterat problem eftersom det generellt sett är mindre obekvämt att hantera/diskutera.

Frågan är då hur ofta man ska genomföra sin lessons learned-övning i ett projekt och det finns såklart inte ett svar på det. Det givna tillfället är vid projektavslut, men det är nog så viktigt att genomföra lessons learned under projektets gång eftersom det då finns utrymme för konkreta förbättringsåtgärder i pågående projekt. Det är lämpligt att planera i en lessons learned regelbundet t ex i samband med viktiga projektmilstolpar, leveranser, sprintavslut you name it.

I mitt specifika fall använde jag lessons learned som ett verktyg för att konkretisera de synpunkter och det missnöje som florerade i korridorerna och på kafferasten. Helt enkelt ett sätt att låta folk få lätta på trycket under en begränsad och kontrollerad tid. Trycket höll helt enkelt på att bli för högt och hade jag inte genomfört den här övningen hade förmodligen locket flugit av vilken sekund som helst. Därför såg jag till att provocera och utmana gruppen ända tills de vågade kliva utanför sina bekvämlighetszoner och vara riktigt ärliga. Resultatet blev en hel del obekväma sanningar som trots allt gör sig bättre på nedskrivna på en whiteboard än inuti frusterade projektmedlemmar.

Vidare summerade jag resultatet från de olika grupperna och presenterade alltså för berörda personer i fredags. Där utsågs även en person som kommer att ansvara för att vidta de åtgärder som krävs för att bemöta kritiken och även stå för kommunikationen tillbaka till projektteamet. Förväntningarna på reaktion och agerande är självfallet stort och det är av yttersta vikt att de som deltagit i övningen ser konkreta resultat. Annars kan jag garantera att de kommer vara betydligt mer svårflirtade nästa gång du kommer dragande med din lessons learned-övning.

"I'm hanging up on you"

Living Elaine - Episode 54

Progressrapportering klingar falskt i många öron. Det är den där jobbiga rapporten som oftast ska skrivas på sena fredags eftermiddagen eller - ännu värre - tidigt på måndagmorgon. Den där rapporten som du helst vill hoppa över varje vecka eftersom det för det mesta verkar som att ingen läser den ändå. Eller som du sliter ditt hår över eftersom dina projektmedlemmar har glömt bort att dra sitt strå till stacken även denna veckan.

Men, misströsta icke - genom att regelbundet skriva en progressrapport ger du dig själv utrymme för reflektion. Att fundera över vad du har åstadkommit den senaste veckan blir ofta en motivationshöjare eftersom du med stor sannolikhet identifierar aktiviteter som du hunnit med av bara farten. Och om slutsatsen blir den motsatta har du åtminstone identifierat att du inte gjort det du skulle göra vilket alltid är ett steg i rätt riktning.

Dessutom är det fantastiskt skönt att ha en progressrapport att hänvisa till vareviga gång du får frågan angående hur det går för dig i ditt projekt - generellt eller kring ett specifikt problem. För att inte tala om hur användbart det är att kunna gå tillbaka i tiden och hitta veckovis information kring vad som gjorts i projektet, vilka problem som funnits och vilka risker man sett.

Det är dock några saker du bör tänka på för att göra din progressrapportering snäppet bättre:

1. Kom ihåg att syftet med en progressrapport är att påvisa att du närmar dig projektmålet som planerat. Det innebär att en grundförutsättning för att kunna rapportera progress är att det finns en plan. Jag har sett många och långa progressrapporter som visar på frenetisk aktivitet, men som i avsaknad av plan framstår som tämligen ointressant eftersom det inte säger ett dugg om huruvida vi kommer nå vårt projektmål på utsatt tid.

2. Tänk på vem som ska läsa din progressrapport. Det är viktigt att anpassa innehållet efter läsaren och ibland är det en god idé att göra olika varianter av rapporten eftersom din styrgrupp har intressen som dina projektmedlemmar inte har och vice versa. I en del fall kanske det dessutom krävs både en extern och en intern rapport om det är så att det är en kund involverad i projektet. Försök hitta en skalbar modell där du kan utgå ifrån en generisk rapport ur vilken du sedan kan välja detaljnivån och innehållet beroende på målgrupp.

3. Undvik för långa rapporteringsperioder. En vecka brukar vara lagom eller på sin höjd två veckor. Om perioderna blir för långa är det svårt att dra sig till minnes vad som har hänt, mycket av informationen kan kännas inaktuell och du förlorar i kontroll eftersom den positiva effekten av reflektion minskar.

4. Välj ett lämpligt format. Var kreativ och fundera på vilket format som passar för ditt projekt. Det viktiga är att informationen är lättöverskådlig och enkel att förstå för att öka sannolikheten att mottagaren läser och förstår innehållet.

5. Gör en noggrann intressentkarta som underlag för din sändlista. Det är viktigt att informationen når ut till rätt personer. Skicka hellre en för mycket än en för lite!

"We are all the winners - we are all the best"

Living Elaine - Episode 53

Uppsnappat i en korridor på stort, svenskt, välkänt företag:

"Vi har slutat köra projekt på min avdelning. Det finns inte längre krav på det från företaget X:s ledning. Vi körde mycket projekt förut, men det blev så jobbigt med all dokumentation så vi slutade. Nu kör vi bara med aktiviteter istället"

Det är tyvärr alltför vanligt att det uppfattas som krångligt och stelbent att följa en projektmodell. Eller att det innebär att man måste skriva en massa dokumentation som ändå ingen kommer att läsa. Båda åsikterna grundar sig på bristande kunskap kring vad syftet med en projektmodell är och erfarenhet kring hur man använder sig av en sådan.

En projektmodell ska ses som en verktygslåda - en komplett verktygslåda som tillhandahåller de verktyg du behöver för att genomföra all världens former av projekt. I verktygslådan kommer du garanterat att hitta verktyg i verktygslådan som inte är nödvändiga för just ditt projekt - oavsett om du använder en out-of-the-box-modell eller om ditt företag har gjort anpassningar för just er verksamhet. Det är därför viktigt att lägga tid på att förstå de verktyg som finns och i vilka sammanhang de är användbara. Det är tyvärr ett alltför vanligt missförstånd att rubb och stubb skall användas och följas slaviskt för att vara garanterad ett framgångsrikt projekt, men är snarare en spikrak väg rakt in i fördärvet.

(Det påminner lite om alla de taxichaufförer som nuförtiden förlitar sig helt och hållet på sin GPS istället för att lägga lite tid på att lära sig gatorna i staden där de arbetar. I väldigt många fall fungerar det fint, men alltför ofta visar GPSen helt fel väg eller till och med ingen väg alls. Jag råkade hamna i en dispyt med en taxichaufför på väg mot en kursgård utanför Stockholm just av denna anledning. Trots att jag upprepade gånger frågade om han visste vägen så visade sig att det gjorde han inte alls, men han litade på att GPSen skulle vägleda honom rätt vilket inte direkt var en vinnande strategi. Han körde vilset runt mig i Uppland under 45 minuter innan jag vansinnig bytte taxi i Bålsta och skickade tillbaka honom till Arlanda utan att betala ett rött öre.)

Tyvärr beror detta missförstånd alltför ofta på okunskap och bristande erfarenhet inom projektledning. Resultatet blir över-dokumenterade, stelbenta och krångliga projekt som i sin tur leder till att man slutar bedriva projekt eftersom det är för besvärligt.

Våra företagsledningar borde investera oändligt mycket mer pengar i grundläggande projektmetodik eftersom det garanterat skulle ge ökad kontroll över verksamheten, effektivare projekt och säkrare investeringar. Men projektledare tycks vara en roll som inte kräver formell teoretisk utbildning. Det tycks räcka med att du kan ha många bollar i luften och har ett gott humör. Och sen undrar man varför så många projekt misslyckas?

"I'm gonna scream from the top of my lungs"