Ha aldrig mer än dubbelt så många personer som snittet under hela projekttiden

Erik Sjöberg skrev ett blogginlägg häromdagen om nyttan av att lägga till fler personer mot slutet av ett projekt för att klara deadline. Alla projektledare vet att det är svårt med bedömningar om antal resurser och ännu svårare att bedömma hur mycket det lönar sig att tillsätta fler resurser mot slutet av ett projekt. Hinner de bli produktiva i tid för att tillföra något före deadline? Tar de istället värdefull kraft från de som redan är mest produktiva i teamet?

Han nämner en tumregel som säger att man aldrig under projektet ska ha mer än dubbelt så många personer som snittet under hela projekttiden. Min spontana tanke var att jag måste ha brutit mot den tumregeln i tidigare projekt. Men efter att ha räknat lite på det inser jag att vi hela tiden faktiskt höll oss inom detta nyckeltal.Och vid projektutvärderingarna var vi nog någorlunda överens om att det inte skulle ha funkat med så mycker fler personer.

Den första hälften av projektet var huvudsakligen en analysfas och antalet inblandade personer var då nio. I den andra fasen bestod projektet av åtta av de ursprungliga nio samt ytterligare mellan två och tio personer. Efter att ha räknat lite på det (vilket tyvärr blir rätt svårt med tanke på att resursfördelningen förändrats kontinuerligt) så visar det sig att snittet faktiskt var rätt högt, över 13 personer. Som mest var vi cirka 20, vilket skulle innebära att vi höll oss inom tumregeln.

Efter att ha gått igenom projektutvärderingar och projektdokumentationer kan jag också dra en del andra slutsatser:

• Var tydlig med att tidsåtgången i projektet kan variera. Försök att till exempel be linjeorganisationen om en person på "i genomsnitt 50%" snarare än konstant 50%. Pratar man om det i förväg så går det ofta att ordna, men om man inte pratar om det tidigt blir det svårt att senare öka eller minska en persons tidsåtgång.
  
• Om man har inhyrda resurser från konsultföretag kan det vara en idé att ha flera personer med samma kompetens på deltid, snarare än en person på heltid. Då kan deltidarna gå upp i tid och projektet får fler produktiva personer utan att någon ny behöver skolas in och sätta sig i allt.(Å andra sidan får vi större overhead generellt i projektet ju fler personer vi är, så det här blir en avvägning. Men 2x50% istället för 1x100% borde fungera i de flesta fall.)
• Skriv öppna avtal med externa leverantörer, där resursbehoven kan förändras med högst 1-2 månaders varsel.
• Dokumentera lagom mycket, så det inte tar tid från teamet, men ändå är ett underlag som hjälper nya team-medlemmar att komma in i jobbet.
• Ett team består av en mängd olika kompetenser. Det verkar vara svårare att tillsätta fler personer i samma kompetensområde än att tillsätta helt nya kompetensområden.

Nån som har liknande erfarenheter?

Styrning av webbprojekt: Projektstyrning, Effektstyrning, Scrum

Jag har hört några gånger att scrum eller andra agila metoder ersätter mer traditionella projektmetoder som rup, props, eller pps. Det stämmer nog till 90%, många delar i traditionell metodik går bort när man använder scrum. Men en övergripande projektstyrning utöver scrum behövs fortfarande. Jag ser tre nivåer av styrning av webbprojekt:

1. Projektstyrningen fokuserar på att definiera projektets ramar. Istället för en regelrätt projektplan handlar det mer om en "projektdefinition" eller ett "projektupplägg". Dels behöver milstolpar beslutas, som till exempel "Projektdirektiv godkänt", "Förstudie genomförd", "Teamet på plats", "Utvecklingsstopp" eller "Lansering". Dels behöver till exempel en riskanalys och intressentanalys tas fram. Inom projektstyrning lägger jag också att etablera arbetssätt gentemot projektets styrgrupp, det vill säga till exempel förankra att vi kommer att arbeta med effektstyrning och scrum.
2. Effektstyrning går ut på att styra projektet med ständigt fokus på verksamhetsnytta istället för "leverabler" eller "krav". Den nytta som projektet ska skapa kartläggs i en resonemangskedja från syftet med tjänsten som ska tas fram, till målgrupperna som ska använda tjänsten, deras användningsmål och slutligen åtgärder som behöver vidtas. Varje steg prioriteras så att kartan blir ett stöd för projektgruppen och för styrgruppen för att följa och styra projektet. (Exempel på effektkarta finns på Socialstyrelsens utvecklingsblogg).
3. Scrum (eller nån annan agil metod) är den operativa styrningen av projektet. Det handlar om att ha alla kompetenser samlade, planera för högst några veckor i taget och visualisera arbetet så mycket som möjligt. På så sätt uppstår verksamhetsnyttan inom de ramar som definierats för projektet.

Någon som har ett likande upplägg?

Projektledarens och styrgruppens ansvar för riskhantering

Risker är alla de faktorer som kan göra att man inte uppnår syftet med projektet. Uttryckt annorlunda: Risk är skillnaden mellan de förutsättningar du har i projektet och de förutsättningar du behöver för att säkert uppnå målet. I webbprojekt handlar de flesta riskerna om oklara krav, personal, leverantörer, planering och styrning.

Risker kan finnas antingen inom projektet eller i projektets omvärld. Som projektledare ansvarar man för att identifiera alla risker för projektet, både de som ligger inom projektet och de som ligger utanför projektet.

Ansvaret för att hantera riskerna inom projektet ligger på projektledaren

En typisk riskhändelse kan vara: Vi väljer fel teknisk plattform vilket gör att vi inte kan bygga det vi vill. Ansvaret ligger i detta fall på projektledaren och en tänkbar åtgärd är att minimera sannolikheten för att risken inträffar. Risker inom projektet kan hanteras på fyra sätt:

1. Minimera eller undanröj sannolikheten att risken inträffar. I det här fallet kan man till exempel genom att låta en extern konsult göra en förstudie om valet av teknisk plattform.
2. Minimera eller undanröj konsekvensen av att den inträffar. Till exempel genom att säkerställa att de lösningar vi bygger på plattformen är väl dokumenterade och följer standarder, så blir konsekvense lite mindre om vi längre fram skulle behöva byta plattform.
3. Överför konsekvensen på någon annan. Utforma avtal med leverantörer på ett sådant sätt att alla eventuella förseningar eller kostnader som uppstår på grund av fel plattformsval måste täckas av konsultföretaget.
4. Bevaka. Om risken är låg eller kostnaderna är för höga för att göra något åt den, så får man låta den vara men bevaka den.

Ansvaret för att hantera riskerna utanför projektet ligger på styrgruppen och beställaren
Projektledaren har sällan personalansvar och inte alltid fullt budgetansvar, vilket gör att de åtgärder projektledaren kan vidta är begränsade. Många risker ligger därför utanför projektet. Säg att vi identifierar en risk att projektets grafiska formgivare säger upp sig. Har du som projektledare inte personalansvar så måste risken lyftas till styrgruppen. Projektledaren kan jobba med att ge positiv feedback och skapa bra arbetsmiljö för formgivaren så han/hon stannar kvar, men styrgruppen behöver agera på eventuella problem med lönesättning, villkor, vidareutbildning eller alternativ bemanning. För risker utanför projektet:

1. Se till att styrgruppen blir medveten om sitt ansvar för att hantera risken.
2. Se till att öka det egna mandatet som projektledare så att projektet så långt som möjligt kan överta risken från styrgruppen. Till exempel genom att få utökat budgetansvar eller ansvar för delar av personalfrågorna.
3. Se punkt 1-4 ovan. 

Dags att revidera den traditionella projekt-triangeln

Projekttriangeln är en av grundbultarna i klassisk projektmetodik. Tid ("jag vill att det ska gå snabbt"), pengar ("jag vill ha det billigt") och resultat ("jag vill att det ska bli bra") blir var sin sida i en triangel för att visa på beroendena mellan de tre enheterna. Poängen är förstås att förändras budget så påverkas de båda andra, och så vidare.

Jag tycker att modellen har brister när den tillämpas i moderna projekt, till exempel webbprojekt. Kraven och verkligheten förändras och "resultat" blir ett för trubbigt mått. Jag föreslår därför istället en projektromb.

Tid och pengar är samma enheter som i den traditionella projekttriangeln, men resultat har delats in i kvalitet och omfång. Om kvalitet handlar om hur bra en funktion fungerar ("jag vill att det ska bli bra") så handlar omfång om hur många funktioner som finns ("jag vill ha mycket av 'det'"). Att göra en distinktion mellan kvalitet och omfång är väldigt viktigt i webbprojekt eftersom vi ofta ställs inför valet att förbättra en funktionalitet mer och mer eller att låta det vara och fokusera på att bygga nästa funktionalitet.

Jag har använt en projektromb i två projekt. Det kan se ut till exempel så här:

• Kvalitet framför omfång – vi levererar färdigställda och kvalitetssäkrade resultat stegvis, mängden resultat kan skäras ner.
• Kalendertid framför budget – måste vi välja så utökar vi budgeten, inte kalendertiden.

Ok, jag gör väl ett gantt-schema då

En del före detta kollegor har hört mig säga att gantt-scheman sällan är nödvändiga i praktiken. Gantt-scheman togs fram för enormt stora byggnadsprojekt (typ Hoover-dammen) i en tid då IT och internet inte ens var påtänkta. Henry Gantt var kollega med Frederick Taylor, löpande bandet-principens fader -- och det är väldigt långt ifrån hur man bedriver ett webbprojekt.

Men jag får erkänna att jag ägnat de senaste dagarna åt ett klassiskt gantt-schema. Dels för att kartlägga beroenden i projektet (valet av utvecklingsplattform måste till exempel göras före utvecklingsstart). Dels för att det är ett pedagogiskt och bra sätt att få acceptans för milstolpar och tidsplan.

Det sätter också det agila arbetssättet i ett sammanhang. Man ser hela projekttiden på en tidslinje och man ser en mängd olika aktiviteter med vissa beroenden. Men den största aktiviteten i gantt-schemat motsvarar över 90% av resurserna som läggs ner i projektet. Den kommer inte att brytas ner i mindre delar.

Portaler byggde man på 90-talet, eller?

I ett pågående projekt är mitt uppdrag att "bygga en portal". För att utmana de förutfattade meningarna och lyfta blicken lite längre fram körde jag tidigt med följande kommentar kring begreppet "portal".