I mitt förra inlägg resonerade jag lite kring rollen projektledare (PL). Jag kom fram till att en PL traditionelllt har (minst) tre mycket stora ansvarsområden: Behov och krav, teknisk lösning samt teambyggande. Det känns osannolikt att en individ kan gå i land med allt detta samtidigt. I denna text börjar vi dekonstruera PL-rollen genom att titta närmare på detaljerna.

En traditionell projektledare har alltid två problem: 1. Hur få bästa kvalitet på tidplanen? 2. Hur få alla att sluta upp kring tidplanen? Somliga PL sitter på sin kammare och gör ganttscheman med detaljerade aktiviteter. Många gånger är de inte experter på området. Kanske har de en gång haft den expertisen, men utvecklingen har gått dem förbi. Inom mitt område, systemutveckling, tar det bara ett par år att tappa stinget. Det är leder till planer med stora kvalitets- och trovärdighetsproblem.

De flesta projektledare har dock lärt sig att man ska då ska ta hjälp av övriga projektmedlemmar för att försöka göra en trovärdig plan. Det här ger ett bättre resultat, men fortfarande har projektledaren ägarskap över planen. Ingen i teamet bryr sig nämnvärt om en aktivitet på ”den kritiska linjen” blir en dag försenad. Folk glömmer bort planen och rapporterar inte ändringar. Varför skulle de? Det är inte deras plan.

Ett tredje problem, vilket är specifikt för områden där en hög grad av innovativt arbete och kreativitet ingår, till exempel produkt- och systemutveckling, är att exakt vilka aktiviteter som ska ingå för att utföra en uppgift inte är kända förrän man utför dem.

Det kanske låter konstigt men man kan jämföra med att måla en tavla eller, varför inte, skriva en dikt. Ett försök att detaljplanera diktskrivande kan bli något sånt här:

1. Införskaffa lämpligt material: Papper och skön penna
2. Skriv dikt
3. Plocka ihop material

Lite väl hög nivå på steg 2 kanske? Vi gör ett nytt försök:

1. Införskaffa lämpligt material: Papper och skön penna
2. Välj ett tema
3. Välj en titel
4. Skriv rad 1
5. Baserat på sista ordet, hitta rimord
6. Skriv rad 2, med bra rim
7. (osv till rad 10)
8. Plocka ihop material

Känns inte klockrent. Jag är, som du märker, inte en professionell poet, men om du skulle fråga en skulle du få samma svar: Diktskrivning emotstår alla försök att bli detaljplanerat. Vårt val står alltså mellan att göra planen på för hög nivå för att vara användbar eller på för detaljerad nivå för att vara korrekt. Oanvändbart eller fel, vilket väljer du?

Mina slutsatser av ovanstående resonemang blir att:

• detaljplanering måste göras av de som ska utföra arbetet, dvs de verkliga experterna
• detaljplanering ske vid en så sen tidpunkt som möjligt, för att ge gruppen bästa möjliga beslutsunderlag
• vi får ödmjukt bereda oss på att ständigt ändra om detaljplanen eftersom det är mycket svårt att förutse exakt hur en kreativ uppgift ska lösas.

Läs resten av det här inlägget »

Produkt- och systemutveckling utförs ofta i projektform. Det är rimligt att tro att ett projekt måste ledas av någon och att denna någon måste vara en projektledare. Men det behöver inte vara så. Med agila metoders intåg känns rollen, så som den traditionellt är komponerad, missanpassad till dagens behov. Varför?

Låt oss försöka bryta ned rollen projektledare (PL) och se på vad en sådant traditionellt förväntas göra. Din lista kan se lite annorlunda ut, men i stort tror jag att följande lista bör kännas igen:

• Planera projektet: Göra tidsplaner
• Mäta och styra framdriften: Regelbundet kontrollera att planerna håller och vidta åtgärder om så inte är fallet
• Rapportera: Regelbundet informera chefer och kunder om status
• Hantera krav: Ha benkoll på kraven och, framför allt, ändringarna samt förmedla dessa till övriga
• Validera lösningen: Tillse att vi kontrollerar att kraven är uppfyllda
• Ansvara för kvaliteten i lösningen: Tillse att inga onödiga fel smyger sig in, oftast via en kvalitetprocess
• Hantera kundrelationen: Sköta projektrelaterad kommunikation med kunden och försöka göra kunden nöjd
• Etablera en process för arbetet: Tillse att projektgruppen följer organisatoriska eller egenuppsatta standarder för hur arbetet ska utföras
• Marknadsföra: Berätta om projektet, internt och externt

En del goda projektledare, men verkligen inte alla, försöker även hinna med följande uppgifter:

• Sätta ihop grupper av människor av rätt kompetens och matchande personligheter
• Bygga väl fungerande lag, arbeta med teamkänsla, peppa
• Visionera: Visualisera målet och kommunicera visionen
• Maximera kommunikation och samarbete, ”olja maskineriet”
• Eliminera hinder för teamet, till exempel intern byråkrati
• Skydda teamet från oönskad extern påverkan
• Hjälpa teamet att utvecklas och bli bättre

Puh! Av ovanstående lista förstår vi att rollen som PL är en tuff och krävande roll. Jag har själv arbetat som PL i 4 år och jag har aldrig vara så utarbetat som under den perioden. Ansvaret är tyngande.

Som man kan misstänka är många PL väldigt pressade och hinner helt enkelt inte med allt som de ”borde”. Det som vanligen får stryka på foten är givetvis inte kundrelationen, planeringen eller kravarbetet, utan de ”mjukare” aspekterna av att leda lag; de aspekterna som återfinns i den lista nr 2 ovan. En annan orsak till detta är att det är ovanligt att hitta både en teambyggande och en kvalitetsfokuserande personlighet inom en och samma person. Många projektledare idag är, eller tvingas vara, ”kontrollfreaks”. När det här sker blir projektledaren mest en kontrollant och en politiker. Tyvärr är lista nr 2 väldigt viktig, både för att behålla medarbetare och för att uppnå hög produktivitet och god kvalitet.

Ett problem som jag upplevde som projektledare var att jag fick ett oerhört stort ansvar men inte mycket till befogenhet. Jag skulle göra tidplaner, men jag visste inte exakt vilka aktiviteter som behövdes. Jag skulle mäta och styra men kunde bara mäta mot mina egna planer. Jag skulle se till att kraven blev uppfyllda men jag visste inte exakt vad de innebar eftersom jag inte hade skrivit dem. Jag skulle se till att vi arbetade klokt och rätt, men jag visste inte alltid vad det var eftersom jag inte var expert på alla områden. Jag försökte få medarbetarna engagerade i planerandet, men de ville ju inte göra mitt jobb. Och så vidare.

Jag tror att många PL kan känna igen sig i denna beskrivning. Jag var säkert en ganska dålig PL på den tiden (det var mitt första jobb), men jag vet inte hur mycket bättre jag hade kunnat hantera det idag. Så här i backspegeln känns det mer som att det var sammansättningen av ansvar till en och samma person som var fel.

Sammanfattningsvis: En projektledare, som den uppfattas idag, förväntas vara expert på tre större områden: behov och kravarbete, den tekniska lösningen ned på aktivitetsnivå och teambyggande/ledarskap. Vilket för oss till pudelns kärna: Är det rimligt att ha alla dessa ansvar i en person? Är det ens fysiskt möjligt att klara av detta inom en och samma individ? Om inte, hur kan vi fördela arbetet på ett annat sätt?

I mitt nästa inlägg tänkte jag försöka beskriva ett alternativt sätt att fördela ansvaret och ge lite råd till dig som är projektledare idag, speciellt inom produkt- och systemutveckling.