Det finns en myt i planeringskretsar om att mer detaljer är bättre och mer exakt. När det gäller resursplanering ser detta ut som stora kalkylblad med namn på personer som tilldelats specifika projekt under månader eller veckor under minst ett år. Om vi kan planera så mycket detaljer så långt måste det vara korrekt, eller hur? Inte så snabbt. Det finns tre huvudproblem med detta tillvägagångssätt:
- Det tar lång tid att skapa och ändra dessa kalkylblad.
Om du vill se vad som händer om du slutför projekt A, B och D i stället för C, E och F kommer du förmodligen att behöva bränna nattljus för att nå dit. Och hoppas att du inte förstör några formler i kalkylbladet när du ändå håller på. Och om fler än en person har tillgång till kalkylbladet, försök att inte trampa varandra på tårna (eller raderna). Om du hanterar resurser för en stor grupp blir detta snabbt oöverskådligt och leder till det fruktade analysförlamningssyndromet. - Dessa stora kalkylblad gör det mycket svårt att se skogen för alla träd.
Visst finns det sammanfattningsflikar i kalkylbladet, men du kan inte leka med dessa sammanfattningar. Man måste gå tillbaka till den detalj som de rullas upp från för att se hur skogen kan förändras om man ändrar några av dessa träd. Låt oss säga att skogsvyn visar avdelningsvisa sammanfattningar för alla projekt. Det innebär fortfarande att du kommer att ha ganska många rader i fliken Sammanfattning för att få fram den sista raden som visar om avdelningen eller gruppen är överkapacitativ. Och om så är fallet måste man gå tillbaka till detaljbladen för att ta reda på hur man ändrar det. - Du försöker lösa fel problem!
På skogsnivån handlar det främst om att godkänna rätt projekt som passar den tillgängliga kapaciteten. Detta är inte ett problem för varje enskild användare, utan ett kapacitetsproblem i större skala. Om du till exempel har en IT-avdelning med 500 personer vill du verkligen se en uppdelning av dessa 500 personer i logiska grupperingar och sedan välja de projekt som passar dessa grupperingar.
The guest speaker for our upcoming Agile Enterprise customer webcast on November 10th, Dr. Klaus Leopold, released a book in 2018 called “Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility” that has a great take on this, in a slightly different context. He described and laid out various types of planning and execution into three “Flight Levels.” These Flight Levels can apply to resource planning as well. I’ll let you read the book to get the full understanding, but here’s how I apply them to Resource Planning.
Strategi. Samordning. Drift.
"Flight Level 3" är den strategiska nivån och motsvarar ett flygplan som flyger på 30,000 fot. Om du flyger ett flygplan på den höjden förväntar du dig inte att se människor på marken. Oftast ser du breda landskap med städer, motorvägar och gårdar. Du behöver inte se personerna på marken för att veta var du ska flyga planet, du behöver bara det bredare landskapet. I termer av resursplanering kan detta motsvara avdelningar eller stora team. Mer detaljerade än hela 500 personens IT-grupp som helhet, men säkert mindre än var och en av 500 personerna. Nyckeln här är det problem vi löser - att se till att vi inte överbelastar systemets kapacitet. Det var allt! Inte vem som ska utföra arbetet, inte vilka roller som är inblandade - låt oss bara se till att vi inte överbelastar systemet.
"Flight Level 2" är samordning på en mer måttlig höjd som 15,000 fot för att hålla sig till flygplansanalogin. På den här nivån förväntar vi oss att se mer detaljer, men fortfarande inte individerna på marken. För resursplanering kan detta vara roller som projektledare, affärsanalytiker och ingenjörer. Observera att jag inte inkluderar dessa rollbaserade typer på flygnivå 3. Här löser vi problemet med kritisk resurstillgång. Om vi har gjort en planering på flygnivå 3 och det övergripande systemet inte är överbelastat, kommer vi redan nu att finna mycket mindre konkurrens om resurserna. Det kan dock fortfarande finnas överbelastning av kritiska resurser, t.ex. projektledare eller vissa typer av ingenjörer. Jag anser att den här nivån innebär att hitta rätt typ av människor för rätt projekt.
"Flight Level 1" är operativ, en mycket låg höjd på 5,000 fot och lägre där enskilda objekt är tydligt synliga och urskiljbara. Nu tittar vi på vem som ska utföra arbetet. Detta är en uppgift för projektledare som tilldelar arbetet eller produktägare som prioriterar berättelser som enskilda personer ska ta fram.
Planering av resurskapaciteten - överbelasta inte systemet
När vi nu har beskrivit flygnivåerna kan vi dyka lite djupare ner i flygnivå 3 - planering av resurskapacitet. Kom ihåg att målet här är helt enkelt att inte överbelasta systemet med arbete och begränsa de strategiska besluten utifrån vad som ryms i kapacitetsröret.
Det första steget du måste ta är att ta reda på vad dina kapacitetsrör verkligen är. Om du gör IT-avdelningen med 500 personer till ett enda rör kan du välja ut projekt som ryms inom dess kapacitet på 20,000 timmar i veckan. Och du kanske väljer alldeles för många webbprojekt och lämnar nätverksingenjörerna i sticket.
Om du är en Agile-butik är detta mycket lättare. Du använder redan Teams. Om du är stor kan det finnas tekniska avdelningar som består av flera team och du kan välja att använda antingen teamkapaciteten eller avdelningskapaciteten. Detta kan uttryckas i story points, person-månad, dagar eller sprintar. Det fina med agila team är att de redan är balanserade. Ett typiskt team kan bestå av en scrum-master, en testare och fyra ingenjörer. Om det förhållandet inte fungerar kan teamets sammansättning justeras så att berättelserna flyter smidigt och du kan rikta initiativ eller projekt till ett team och veta hur mycket som kommer att rymmas i deras rör.
Agile teams work great for software only projects, but PMOs manage a broad range of work, which often needs infrastructure resources, subject matter experts (SMEs), and project management. Now how do we divide up that 500-person IT department? One way is to develop virtual capacity teams. Individual resources are usually specialized in most large IT departments. Thus, infrastructure projects will have PMs that only manage infrastructure, specialized business analysts, and of course network engineers and admins. Maintaining third-party software applications will also find specialized project management and engineering resources. That 500-person shop can probably be broken down into a dozen or so minimally overlapping virtual capacity teams.
I dag driver du förmodligen både vattenfalls- och agila projekt, så det är troligt att du har en hybrid av ovanstående.
Nu när vi har abstraherat en sann 30,000-fots planeringsvy för kapacitet kan vi välja arbete. I stället för att välja de bästa 20 projekten av 100 föreslagna kan vi välja de bästa 10 webbprojekten, de fem bästa infrastrukturprojekten osv. Och du kan få in ett par små webbprojekt i den återstående kapaciteten. Det är högst troligt att de bästa 20 projekten blir 30 när de anpassas till deras kapacitetsrör. Om du behöver ändra planen är det naturligtvis lika enkelt som att ändra sammansättningen av projekten i vart och ett av ett dussintal kapacitetsteam - och inte ändra de projekt som tilldelats var och en av dessa 500 personer.
I slutändan handlar det om att lösa rätt problem på rätt planeringsnivå. På det hela taget är resurskapacitetsfrågor ett problem på "flygnivå 3". Det är inte bara detaljerna som är avgörande, utan för mycket detaljer kommer att hindra den smidighet och det sunda beslutsfattande som vi alla strävar efter. Du kommer att ägna mer tid åt att uppdatera detaljerna än åt att se till att projekten löper smidigt!
