Projektledarbloggen

Är du ny på jobbet som projektledare? Kanske är du ny i så väl rollen som ny i ditt projekt? Ibland så är vi till och med nya som projektledare på företaget vi är! Alldeles oavsett hur mycket ny du är så är det här inlägget för dig!

I det här inlägget tar vi upp fem saker som du behöver förhålla dig till redan första veckan som ny projektledare.

1. Bli inte för operativ, du får många chanser till det

Vi kan komma in som projektledare i en rad olika sammanhang och projektfaser där det är mer eller mindre naturligt att hitta en bra startpunkt. Du bör ganska snart försöka hitta en ingång till faktiska arbetsuppgifter där du får en naturlig introduktion till projektet och ledarskapet genom konkreta arbetsuppgifter.

Men välj rätt startpunkt!

Hur blir ett företag, avdelning, projekt eller individ bättre på att leda projekt? Det finns massor av idéer kring det. I det här inlägget tänkt jag nämna några och kommentra de kort utifrån min erfarenhet, sedan tänkte jag föreslå ett sätt som inte används så ofta, inte som jag sett åtminstone, som handlar om projektgenomgång och projektgranskning.

Kurser och utbildningar: En bra metod att flytta positionerna kunskapsmässigt något. Ger energi och nya insikter men vänder sig främst till individer och sprider egentligen inte organisationens kunskaper, om inte kursen är utformad och genomförs av företaget själv.

Certifiering: Min personliga erfarenhet av PMP-certfieringen är att den är personlig medan IPMA genomgången mer öppnar för ett ökad spridning av kunskap i organisationen. Lärdomar formuleras – vilket är ett första steg för att de sedan ska kunna spridas – och det går att ha bisittare med vid genomgången som får höra och lära mer.

Lessons learned: I någon form så sammanfattar man lärdomar gjorda ur ett projektledarperspektiv och kommunicera dessa i organisationen. För den som medverkat i ett projekt, fas eller verksamhet och som kanske dessutom deltagit i arbetet med att sammanställa de lärdomar man gjort kan förstärka sin reflektion och inlärning avsevärt med den här metoden. Hur kunskapen når andra är mer oklart och väldigt personberoende. Det finns studier som visar på att dokument som lagras med lärdomar ”ruttnar fort”.

Arbeta tillsammans – mindre erfaren med erfaren: Mycket bra metod då det finns möjlighet att lära av varandra naturligt i arbetet. Denna metod kan dock lätt komma att handla om att man hjälps åt med ”volymarbetet” i projektet. Det är inte säkert att sammarbetet sker kring samtliga delar i hantverket ”projektledning” och spridningen av kunskap blir begränsad.

Intervjuer: Det här är en metod jag sett i praktiken inom bilindustrin. Inför en viss händelse eller fas i projektet så får ledaren på sig att intervjua utpekade nyckelpersoner i företaget. Det kan vara specialister, kvalitetspersonal eller projektledare med tidigare erfarenheter inom området. Det här är ett alternativ till Lessons learned på papper där dialogen och kontakterna gynnas till förmån för det skrivna ordet.

Audits, genomlysning eller projektgenomgångar: Jag har haft förmånen att bli tufft granskad av en mycket elak kvalitetsingenjör från en fransk biltillverkare. Förmånen säger jag med viss blandning av ironi och sanning. Att bli granskad är inte roligt, men det kan vara mycket lärorikt. Det kan dessutom göras betydligt mycket trevligare än vad man kanske först anar och fortfarande vara lika lärorikt. På ett ställe då jag var chef så samlade jag ledningsgruppen och så satte vi oss med respektive projekt och gick igenom en rad av projektets artefakter. Vi tittade på tidplan, risker, aktionslista, milstolpar och styrdokument. Vi pratade om dokumenten med projektledaren och hans teamledare. Projektkontorschefen lärde sig mer om sina projektledare och cheferna lärde sig mer om vad deras personal var tvungna att bli bättre på och stötta projektledaren inom.

Då vi gjorde det här med en rad projekt i rask takt såg vi också var de olika projekten hade best practices värda att sprida, var ökad överhörning mellan projekten skulle gynna oss som företag och samtliga inblandade fick möjlighet att diskutera frågeställningar i vardagen. Hur skriver man bra aktionslistor och vem följer upp aktionerna? Hur detaljerad ska planering vara och hur används den planering som görs? Hur styr projektledaren sin tid? Vem äger olika projektledningsdokument och projektets rutiner?

Det här synsättet kan naturligtvis tas längre men då börjar det allt mer påminna om projektkvalitetsarbete och då sticker omfattningen lätt iväg.

Har jag glömt någon bra metod för att sprida projektledarkunskap inom en organisation?

Granskning!

Ett ord jag har en viss hatkärlek till.

Nu under hösten läste jag en kurs i kravhantering på universitetet. I universitetsvärlden gillade man granskning. Som projektledare gillar jag också granskningar. Vi sätter ner foten och säger att nu är det här jobbet klart. Vi kvalitetssäkrar det vi gjort och går vidare. Kod, dokument, krav eller länkning spelar ingen roll. Teoretiskt så är allt så bra!

Men jag vet också att granskning är svårt. Jag har arbetat som ledare i en organisation som släppte ut en mjukvara med ett mycket allvarligt fel på marknaden. Efteranalys visade att alla granskningar var gjorda och att vi processmässigt gjort ett gediget jobb. Problemet var att ingen som granskade dokumentationen eller koden hade tillräckligt god kunskap för att kunna hitta felet, eller ens se att de saknade förmågan till det. Det handlade inte om att granskarna var okunniga, tvärtom hade man valt mycket relevanta granskare utifrån den grupp som kunde vara aktuella. Istället handlade det vårt tillkortakommande till stor del om synen på den kunskapsuppbyggnad som följer med implementationen av mycket komplex funktionalitet i mjukvara. Vi litade för mycket på en person under lång tid och trodde andra skulle kunna kvalitetssäkra det arbetet personen gjort under åratal i efterhand.

Granskning kan också bli väldigt tråkigt vilket gör att kvalitén i aktiviteten sjunker. Artefakter där granskning är en viktig del i kvalitetssäkringen bör utformas så att granskning underlättas.

Granskning och scrum

Kan flera människor i ett tvärfunktionellt team granska en stor mängd artefakter, kanske i delar som bara är några timmar långa åt gången, och finns det några fördelar i att bedriva granskning så?

Jag skulle säga ja på båda på båda frågorna.

Men några saker måste vara på plats och är de det så bidrar det dessutom till att höja kvalitén i den granskning som ska göras.

• Det måste vara tydligt vad som ska granskas för respektive artefakt och hur kommentarerna ska hanteras.
• Artefakterna måste vara granskningsbara och strukturerade så att granskning av delar, eller vissa aspekter, är möjligt.
• Det måste finnas en granskningsledare och någon form av verktygsstöd som säkrar helheten.

Att sprida granskningen vid en scrum-tavla kan dessutom tvinga fram vissa effekter som i sig höjer kunskapsnivån på teamet och bidrar till att höja kvalitén i det som görs indirekt. En tydlighet i vilken granskning som ska göras och vad den ska mynna ut i kombination med en gemensam insats att planera upp granskningen, exempelvis vid en scrum-tavla bidrar till det.

I praktiken kunde det se ut ungefär så här i Excelarken vi använde.

I praktiken hade vi 1000-tals ting att granska och vi granskade varje artefakt utifrån ett ganska stort antal aspekter. Det här var i sig inget nytt, åtminstone var inte kravet att granska det. Det som var nytt var att vi gjorde det med hela projektets bemanning – ungefär 50 personer – och att alla kunde, alternativt var tvungna, att hjälpa till. Att det gick berodde bland annat på att vi delat upp och förtydligat vad som skulle granskas med avseende på vad väldigt detaljerat. Och vi gjorde det på ett enkelt tydligt vis genom att använda ett schema enligt bilden ovan.

De artefakter som var svårgranskade, främst en grupp dokument, arbetades till viss del om för att passa vårt schema istället för tvärtom.

Förmodligen fanns det inledningsvis en person som granskat koden bäst. Eller som kunde kravverktyget bäst och därför borde granska länkningen som gjorts. För att inte tala om hur det såg ut avseende varningarna i byggresultaten. Det ville ingen kunna något om. Men att visualisera och dela upp tog oss framåt. Det var inte så svårt för systemkillen att granska alla filer med varningar när allt kom omkring. Det blev en eller två punkter som behövdes tas upp i större grupp. UI-gruppen gjorde ett mycket bra jobb i granskningen av testfall och länkningen av dem.

Ibland kunde vi gjort saker i en ordning som varit klokare, men eftersom vi alla hjälptes åt och blev allt klokare så gick eventuella omtag snabbt.

Vi höll på i månader. Först gnölade något över att vissa dokument inte granskades i sin helhet. Att allt snuttifierades. Någon ansåg att ingen hade överblick på om systemet faktiskt fungerade som tänkt och enligt ställda krav – något vi genom allt arbete som gjorts tidigare samt systemtester, robusthetstester och vad alla tester nu kunde tänkas heta var rätt säkra på när vi startade slutgranskningarna- och någon ansåg att deras kompetens kunde användas bättre.

Men det tog inte många veckor innan alla var positiva. Ingen satt med svartepetter. Kunskapsspridningen i granskningen gjorde att kvalitén snarare höjdes än sänktes. Kanske viktigaste för arbetsmoralen var att det vi hittade, som behövdes undersökas, snabbt gick att hantera. Ingen nyckelperson satt fast i granskning två veckor. Sällan hade någon en arbetsuppgift längre än ett par timmar.