Den lättrörliga projektledaren

Förmodligen sökte han en lätt provocerande effekt, och lyckades ganska bra med det. Jag har själv jobbat som projektledare. Är jag därför dömd till pajas-status? Det känns ju inte så roligt att höra.

Om vi börjar med att sortera bort den rena förolämpningen, att projekt-ledare skulle vara pajasar, kanske vi kan räta tillräckligt på ryggen för att kunna ta en titt på bakgrunden till uttalandet: att projektledare egentligen inte åstadkommmer så mycket.

Hur mycket åstadkommer projektledare då? När jag tänker tillbaks på de gånger jag själv jobbat som utvecklare minns jag snabbt att min egen erfarenhet av projektledare inte är särskilt positiv. Jag har kanske haft alldeles för höga förväntningar, men jag inbillar mig ändå att projektledarskapet måste innebära mer än att bara titta in till teamet nån gång då och då och fråga hur det går.

Eller mer än att bara föra en minutiös och mycket lång lista över "Open Issues", utan att någonsin utforska varför inget någonsin kan lyftas av från listan, som blir större och större för var dag.

Eller mer än att (och det här är en bitter favorit i min tragiska samling) påbjuda övertid i början av projektet så att "vi slipper den senare", och sedan när projektet går på knäna utfärda mandatet "nu är det fulhack som gäller grabbar".

Dylika erfarenheter kan förstås få den mest godhjärtade att utbrista i förolämpningar. Tyvärr verkar många i mjukvarubranschen ha liknande erfarenheter, och i brist på gott ledarskap uteblir ofta resultaten i projekten.

Men vi skulle ju strunta i syrligt gnäll och förolämpningar, och bli lite mer konstruktiva. Vad är egentligen gott projektledarskap, och vad bör en projektledare åstadkomma?

Den förhärskande idealbilden av projektledaren tycks vara den av en spindel i sitt nät. En jonglerande spindel som har full kontroll på de otaliga bollar han har i luften. En koordinator som har insikt i start och slut för var och en av projektets många uppgifter, och som oförtröttligt delar ut dessa på ett kalendertidsoptimerande sätt till projektets många "resurser".
Så långt stommen i idealbilden. Lägg sedan på en projektmetod, och på projektledarens redan lätt nedsjunkna axlar läggs då ansvaret att förstå och följa denna. Vissa företag skiljer dessutom på projektmetod och utvecklingsmetod, och lämnar glatt över jobbet att pussla ihop denna märkliga tudelning till projektledaren.

Kvar blir mycket lite kapacitet till ledarskap. In kommer ofta trötthet och cynism. I slutänden blir det mesta brandsläckning. Kanske är just det en typ av aktivitet som kan se ut som spattiga pajaskonster för en person på åskådarplats.

Varför händer detta gång på gång?

Detta händer gång på gång därför att vi glömmer att utvecklingsprojekt idag, kanske särskilt mjukvaruprojekt, är så komplexa att det är omöjligt för en ensam person att överblicka och kontrollera alla detaljer. Om vi väntar på att projektledaren ska uppnå full kontroll får vi vänta för evigt, eller åtminstone tills dess projektet läggs ned.

Det finns andra sätt att definiera projektledarrollen, sätt som erkänner komplexiteten och söker andra vägar att handskas med den än att sönderdela problemet i oändligt många små beståndsdelar och sedan försöka samordna dessa till en fungerande lösning. Tanken om lättrörlighet, som på engelskan kallas för agile, visar på en sådan väg[1].

Det lättrörliga projektets filosofi tar avstamp just i att utvecklingsprojekt är ofattbart komplexa, på grund av den kombinatoriska explosion av samband som uppstår ur blandningen av problemdomän, teknik och människor.

Paradoxalt, eller uppenbart, nog är motmedlet mot komplexitet inte mer komplexitet i form av mer detaljerade projektplaner, mer detaljerade projektmetoder eller mer detaljerade ansvarsbeskrivningar. Motmedlet mot komplexitet är enkelhet.

Låt oss börja med själva basen för den lättrörliga projektledaren.

Basen är denna: du är snarare en coach än en koordinator.

Ditt jobb är inte att se till att dina projektmedlemmar påbörjar och avslutar aktiviteter i rätt tid. Den biten klarar de själva, eftersom vi jobbar med relativt små team i tidsbegränsade iterationer. Ditt jobb är att hjälpa teamet vara så produktivt det bara kan, med alla medel som står dig till buds.

Men om ingen har överblicken över start och slut för aktiviteter, hur kan vi då visualisera projektets storlek? För att besvara den frågan är det kanske lättast att titta på en idag väldigt vanlig metod för att visualisera projekt: Gantt-scheman.

Många har stött på, eller själva genomfört, mindre lyckade försök att visualisera samband mellan projektaktiviteter i Gantt-scheman, med syfte att få en överblick över projektet som helhet. I början ser allt bra ut, men redan efter några veckor fnissar projektdeltagarna och andra åt den allt mer eftersläpande planen. Redan idag är det alltså bara de i tiden närmast liggande aktiviteterna som vi lyckas förutsäga med någon större säkerhet.

Den lättrörliga projektledaren accepterar detta, och använder åter enkelhet som motmedel. Om vi gång på gång misslyckas med att förutsäga exakt vilka aktiviteter som ska ske när i framtiden, varför slita vårt hår över detta?

När vi jobbar lättrörligt jobbar vi iterativt. Det ger oss möjligheten att bara planera en iterations aktiviteter i taget. Resten av projektplanen kan vi uttrycka på en högre nivå, till exempel genom att uppskatta storleken på de funktioner och kvaliteter vi vill bygga in i vår mjukvara, utan att bryta ned dem i aktiviteter, och bedöma hur många funktioner och kvaliteter vi tror oss kunna genomföra i varje iteration. Det ger oss en rimlig uppskattning av antalet iterationer i projektet, och eftersom iterationslängden är känd (till exempel fyra veckor), kan vi också projicera planen mot kalendern.

Dessvärre är det så, att till och med planeringen av en enda iterations aktiviteter innebär en komplexitet som svårligen kan greppas av en ensam person.

När en människa inte ensam kan lösa ett problem, till exempel koordineringen av en myriad sammanlänkade uppgifter, vad gör vi då?

I det lättrörliga projektet lyfter vi ansvaret för uppgiftsplanering från den ensamme projektledaren till hela utvecklingsteamet. Vi samlar hela teamet och samarbetar för att utforska en möjlig väg till framtiden. På något vis tar det oss tillbaks till själva ursprunget till begreppet projekt, projicerandet av en mental bild av en möjlig framtid. Hur ska en ensam person kunna skapa en sådan bild för andra?

Grundregeln för den lättrörliga projektledaren blir alltså: planera aldrig ensam.
Att planera tillsammans utnyttjar inte bara gruppens gemensamma förmåga för att hantera komplexiteten i uppdraget, det skapar också ett betydligt större engagemang i gruppen. För många kan det i början vara en stor omställning att plötsligt förväntas delta i planeringsarbetet, vi är ju så vana att få uppgifter tilldelade till oss, men min erfarenhet är de flesta snart börjar uppskatta möjligheten att vara med och påverka sin arbetsdag, och märker att man har otroligt mycket att tillföra processen.

Den lättrörliga projektledaren är alltså mer coach, eller handledare, än koordinator. Det innebär också att den rent administrativa bördan som kommer av att behöva upprätthålla detaljerade planer i en föränderlig värld minskas. Vad gör vi med denna tid?
När vi frigör tid öppnar vi dörren för stödjande ledarskap.

Ett lättrörligt team koordinerar själva sina uppgifter under iterationen, medan den lättrörliga projektledaren ser som sin uppgift att hjälpa teamet nå iterationens mål. Det kan handla om att flytta möbler så att teamet kan sitta tillsammans, att ta initiativet till personliga samtal om hur arbetet kan utvecklas, eller om att skydda teamet från störningar utifrån.
Låt oss för enkelhetens skull sammanfatta detta ansvar så här: den lättrörliga projektledarens roll är att flytta möbler, så att teamet kan utveckla mjukvara.

Slutligen, och kanske viktigast av allt: den lättrörliga projektledaren använder inte begreppet "resurser" när han pratar om sina medarbetare. Ordet resurs antyder något utbytbart, med lätt beräknad nytta och kostnad. Människor passar illa in på den beskrivningen. Den som någon gång drabbats av ett personalbyte under pågående projekt vet vilka enorma följder det kan få. Därför är den lättrörliga projektledaren mån om att värna både individen och teamet, medveten om att människor må vara en tillgång, men inte av riktigt samma sort som en burk i serverrummet.

Om man uppfattar de definitioner jag just beskrivit som något nytt eller inte handlar förmodligen mest om var man själv kommer ifrån. För vissa är det självklart att en projektledare ska vara mer som en coach än som en koordinator, för andra är det en fullständig nyhet. För vissa känns idéerna bara som sunt förnuft, vilket de förstås är. Ändå är det få som lever efter dem.

Oavsett vad vi tycker om just dessa idéer är kanske det avgörande att vi som kallar oss projektledare börjar med att leda oss själva, helt enkelt genom att meditera en stund över vilka teorier och värderingar vi styrs av.

Vi om några behöver en stabil bas att stå på, inte minst för att ha något att förkasta när vi lär oss något nytt. Annars är risken stor att vi uppfattas just som pajasar, än jonglerandes här, än där, utan synbar effekt på vare sig sista raden eller människors trivsel på jobbet.
Just effekten på sista raden, företagets resultaträkning, kan mycket väl få bli vår slutstation på denna resa. För den som inte prövat kan ett lättrörligt arbetssätt kännas som en kontrollförlust, och leda till förståeliga men inte helt genomtänkta frågor som av typen: "hur ska vi kunna ha kontroll om vi inte har en detaljerad aktivitetsplan"? Detta är emellertid en fråga av typen "har du slutat slå din fru än?" Frågan hävdar en bild av verkligheten som inte stämmer. I det senare fallet att någon faktiskt slår sin fru, i det andra att vi faktiskt har kontroll idag.

Jag brukar därför vända på steken och kasta tillbaks frågan som: "hur bra kontroll har ni idag"? Faktum är att många företag trots stora investeringar i projektmetodik och långa planeringsfaser har mycket dålig kontroll över sina projekt, vilket leder till frågan varför man ska betala så mycket för detaljkontroll om det ändå inte påverkar sista raden.
Begreppet lättrörlighet, eller agile, kommer väl med tiden att ersättas av något annat som bättre tillfredsställer vårt mänskliga behov av mode och fräschör, men förhoppningsvis behåller vi den befriande grundinsikt som de senaste årens uppvaknande i branschen har inneburit: att enkelhet och mänsklighet kan hjälpa oss hantera den komplexitet vi mjukvaruskapare befinner oss mitt uppe i.

—

[1] Begreppet "agile", som vi översätter med "lättrörlighet", har kommit att förknippas starkt med mjukvaruutveckling, men är bara toppen av ett isberg av teorier om organisation och styrning av verksamheter. Inom industrin har till exempel teorin om "lean" redan starkt fotfäste. Båda fenomenen går kanske att betrakta som yttringar av en större vändning från ett analytiskt till ett mer systemiskt perspektiv på de utmaningar vi brottas med. Se till exempel Koskela, Howell, "The underlying theory of project management is obsolete", för en diskussion rörande den teoretiska basen för projektledning.

Lär dig mer om lättrörliga projekt

• Den 10 februari klockan 14.00 presenterar Citerus och Tain ett aktuellt förbättringsprojekt, tillsammans med en av Scrums skapare, amerikanen Ken Schwaber. http://www.citerus.se/scrumipraktiken
• The underlying theory of project management is obsolete, Koskela, Howell www.leanconstruction.org/pdf/ObsoleteTheory.pdf