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 26

Så var det det här med projektledare och projektledning. I IT- och telekombranschen har det minst sagt gått inflation i begreppet projektledare och alla som är för kassa på tekniken blir plötsligt projektledare. Det snackas hejvilt om Scrum och Agile i den yngre generationen, medan de äldre fortfarande mässar ITIL och RUP. Emellanåt hörs någon ropa PPS och en annan röst nämner PROPS. Dessvärre förstår inte de allra, allra flesta att de mixar äpplen med bananer i en enda salig röra. Och som projektledarkonsult måste jag därför varsamt akta mig för detta missstånd kring min profession för att inte riskera att hamna på uppdrag som målats upp som tungt projektledaruppdrag men efter lite grävande visar sig vara något helt annat.

Lärdom nummer 1: Ett projekt är en tydligt definierad uppgift som utförs under en begränsad tid med givna resurser och budget. Personen som ansvarar för att projektet utförs och levereras enligt givna direktiv är projektledare.

Alltså.

Alla de uppdrag som innebär en sjuhelsikes massa koordinerande och jagande för att saker och ting ska hända innebär nödvändigtvis inte att det för den sakens skull kan kallas projektledning. Visserligen innebär projektledning ofta just precis en sjuhelsikes massa koordinerande och jagande. MEN, det ska då vara inom givna ramar och inte brandsläckning allt eftersom problemen uppstår lite till höger och vänster på vägen. Att projektleda innebär att ha en plan för att uppnå ett mål och vidare undanröja de hinder som dyker upp på vägen samt kontrollera att planen efterföljs alternativt omplanera.

Lärdom nummer 2: För att effektivt driva projekt brukar man använda sig av en projektmodell. Det är viktigt att skilja på projektmodell och utvecklingsmodell - vs äpplena och bananerna som jag nämnde tidigare. En projektmodell är stöd för att driva projekt och är generellt oberoende av vilken typ av projekt du driver (med vissa undantag såklart som bekräftar regeln. Utvecklingsmodellen beskriver däremot arbetssättet - dvs hur du ska konstruera och designa slutresultatet på ett effektivt sätt.

Alltså.

Scrum och dess släktingar är alltså utvecklingsmetoder och inte projektmodeller vilket däremot PPS och PROPS är. ITIL å andra sidan faller utanför båda definitionerna eftersom det snarare är ett ramverk för hur IT-verksamhet generellt ska hanteras. Inom IT-verksamheten kan man givetvis identifiera behov av ett eller flera projekt som då lämpligen bedrivs enligt en passande projektmodell och där resultatet uppnås genom en utvald utvecklingsmodell. Ni hajar?

Resultatet blir att en hel drös med mycket erfarna projektledare plötsligt inte har drivit ett enda projekt genom åren. Det innebär inte att deras arbetsinsatser är mindre värda för det. Tvärtom. Det finns ett stort behov av projektkoordinatörer (som jag fördrar att kalla denna typ av roll). Utan duktiga och drivna projektkoordinatörer skulle många projekt stanna av helt och det finns inte en projektledare i världen som driver projekt i större organisationer som skulle klara sig utan dem. Men det är en viss skillnad i arbetsuppgifter och en väsentlig skillnad i ansvar. Eftersom jag alltid förespråkar rätt person på rätt plats tycker jag också att det är oerhört viktigt att vi förstår skillnaderna mellan dessa roller.

På samma sätt är det viktigt att våra företagsledningar inser att det finns behov av såväl projek- som utvecklingsmetoder eftersom de fyller olika syften. Först när de insett detta kan vi få snurr på verksamheten och bedriva effektiva projekt som levererar bättre resultat till lägre kostnader. Säg det företag som inte vill nå dit.

"It's the final countdown"