I vårt senaste webbseminarium, Getting the Most Value of Your Project Resources, fick vi chansen att verkligen gå på djupet med frågor och svar på&A och få en bra insikt från vår publik om resursplanering och resurshantering.
Vad är fördelen med att hantera projekt i ett verktyg jämfört med ett kalkylblad?
Om du är en ensamstående person eller ett litet team kan du naturligtvis ofta klara dig med ett kalkylblad ett tag. Men jag har arbetat med produkter som i huvudsak ersatte kalkylblad i många, många år. Därför har jag en god känsla för bristerna med kalkylblad och även deras fördelar. Visst är kalkylblad väldigt enkla att använda, det råder ingen tvekan om det. Men det finns några grundläggande brister som du inte kan undvika med kalkylblad.
- Det största problemet med att hantera projekt i ett kalkylblad är att de inte är effektiva i en situation med flera användare. Du kan använda ett Google-kalkylblad för att dela med dig, men då förlorar du en del av funktionaliteten och användarvänligheten.
- Kalkylblad blir snabbt inaktuella. Särskilt om du har flera användare som interagerar med samma kalkylblad blir de osynkroniserade med varandra.
- De är inte särskilt bra på att representera komplexa data och relationer. I en produkt finns det till exempel flera kunder som är intresserade av olika funktioner, och vi måste spåra var och en av dem i ett många-till-många-förhållande. Möjligheten att göra frågor om vilka kunder som vill ha vilka funktioner är faktiskt ganska svår med kalkylbladet. Allt som har ett hierarkiskt förhållande eller ett en-till-många-förhållande eller till och med ett många-till-många-förhållande i dina data är verkligen svårt att hantera i ett kalkylblad.
- Det är svårt att skapa beräkningar i kalkylblad för flerdimensionella relationer som strategi, som har mer än en dimension, och program som naturligtvis har flera projekt.
Vilka är några av de KPI:er som du rekommenderar organisationer att följa när det gäller resursanvändning?
Det viktigaste att följa upp är det individuella resursutnyttjandet. För att kunna spåra detta måste du spåra:
- Resursens kapacitet - om de är tillgängliga 100% av tiden eller 80% av tiden eller halvtid eller vad det nu kan vara, med hänsyn tagen till saker som semester och helgdagar.
- Allokering - kunna spåra kapaciteten mot hur den faktiskt fördelas mot projekt eller annat arbete. Helst vill du att den ska ligga runt 85%. Om dina resurser till 100% är bokade på projekt betyder det att saker och ting sannolikt kommer att falla bort från deras bord. Om de bara är bokade till 50% på projekt och du förväntar dig att de ska vara 85%, är det naturligtvis ett tecken på att du skulle kunna få mer gjort med dina resurser.
- Planering av resursanvändning - i förhållande till roller. Att kunna sammanställa resursanvändning och resursefterfrågan per roll kommer att hjälpa dig med dina anställningsplaner, som hjälper dig med planer för kompetensutveckling och liknande.
Hur komplex eller stor måste din portfölj eller organisation vara innan du börjar se värdet av en centraliserad lösning eller ett centraliserat programvaruverktyg?
Det finns ingen exakt siffra, men redan vid fem eller sex projekt som konkurrerar om resurserna blir det svårt att hantera i ett kalkylblad eller ett uppgiftsverktyg, och du kommer att börja se ett stort värde i ett system som är utformat för att hantera detta. Och naturligtvis har organisationer vanligtvis dussintals projekt - stora organisationer har tusentals. När du kommer upp i det intervallet måste du definitivt börja förvalta portföljen.
En av de saker som du nämnde är att det är viktigt att hantera inflödena i din planeringsprocess. Har du några tips på hur du kan se till att du har korrekta uppgifter när du börjar planera?
Det finns två aspekter av uppgifterna som är viktiga. Den ena är den nytta som idén kommer att ha om den genomförs. Den andra är kostnaden för att genomföra idén. Det gäller även om idén är en förbättring, ett nytt projekt eller ett nytt program. Det första som krävs är att man gör en noggrann bedömning för att bekräfta dessa siffror och förväntningar i förhållande till objektets storlek. Du kommer att lägga ner mycket mer arbete på att validera både fördelarna och kostnaderna för ett program jämfört med en förbättring.
En viktig sak att tänka på när det gäller den strategiska anpassningen är att inte bara förlita sig på ett enkelt finansiellt mått som ROI. Det är ganska lätt att överskatta eller till och med underskatta avkastningen på förhand. Jag tror att det är mycket bättre att använda ett scorekort, där man listar upp organisationens affärsmål och poängsätter input i förhållande till dem. Särskilt om det handlar om stora projekt är det ett effektivt sätt att göra det. Genom att mäta det jag kallar "strategisk anpassning" kan du få en mer exakt bild av värdet för ditt företag.
In terms of the cost side, what we have in Innotas, for example, is you can have a project idea and you can do a role-based staffing on it where you’re not actually allocating people to the project, but you are indicating what the general level of effort for each individual role – developer, project manager, business analyst and so on. That gives you a cost value that’s more concrete than “Oh, this will cost $1 million.”
Hur påverkar resursplanering agila team, särskilt eftersom vi har utformats för att omfamna förändring som en agil organisation?
Det är sant att strukturellt agila team har större förmåga att hantera förändringar, på grund av hur agil projektledning fungerar. Men det betyder inte att vi inte behöver planera. Det finns fortfarande ett behov av att organisationen säger: "Vi behöver den här uppsättningen funktioner i vår verksamhet, och de måste skapas via projekt." Fördelarna med Agile är att du uttryckligen säger att vi ska titta på denna kapacitet och vi ska bryta ner den i en uppsättning delar och vi ska prioritera dessa delar och leverera de viktigaste först. Och du kommer att göra det i små bitar av tid också. Ni kommer att minska de små tidsramarna för leverans till två veckor eller en månad.
Sprintar är egentligen små projekt, och du gör inte en förändring inom sprinten.
Om du börjar en sprint med avsikt att göra en uppsättning berättelser eller leverera en funktion är det vad du gör under sprinten. Och du reagerar inte på några externa förändringar i prioriteringarna under sprinten. I slutet av sprinten tittar du sedan på vad som återstår att göra eller vad som finns i backloggen, finns det något nytt, behöver vi omprioritera? Sedan fokuserar du återigen på det viktigaste. Så det sätt som Agile fungerar på är att du i princip gör en lista över de viktigaste sakerna. Sedan ägnar du en liten stund åt det viktigaste på listan. Kanske gör du flera av dem. I slutet av sprinten omprioriterar du sedan igen. När det gäller förändringshantering är det bara en liten version av den stora bilden: gör strategisk planering, genomför sedan, och upprepa... Du driver fortfarande den med strategisk planering, men du kanske gör den planeringen lite oftare och med tanken att du kan vara mer lyhörd.
Bortsett från skalbarhetsproblem i kalkylblad, vilka analyser eller analysverktyg finns tillgängliga i ett centraliserat verktyg som Innotas?
Kort sagt, det varierar mycket. Innotas har ett antal olika analyskomponenter som är tillgängliga, t.ex. prediktiv portföljanalys, som i huvudsak tar alla dina projekt och använder ett mått för att avgöra deras anpassning till strategin, och tar alla dina resurser som lagras i Innotas och tittar på deras tillgänglighet och kompetens och kombinerar dessa delar av informationen för att komma fram till en rekommenderad projektplan som prioriterar de viktigaste projekten för att få den bästa avkastningen.
Dessutom kan du göra saker som en "vad händer om"-analys där du kan ställa frågor som "tänk om jag tar bort den här personen från sitt projekt och sätter den på ett annat projekt, hur skulle det påverka leveransen av de två projekten?". I huvudsak ska de kunna visa mig var jag befinner mig och ge mig insyn i vad som händer. Hjälp mig sedan att fatta beslut - vad kommer att hända om jag ändrar detta, vilka projekt ska jag arbeta med? Detta är de två grundläggande typerna av analyser som du måste kunna göra.
Hur håller du moralen på en bra eller mycket hög nivå i början, men framför allt efter att ett projekt har avslutats? Vad tycker du om att hålla motivationen uppe?
Det är en bra fråga, och på sätt och vis har den att göra med planering. En av de saker som verkligen stör många utvecklare när det gäller deras moral är att inte ha något att göra. Som produktchef för har jag ett liknande förhållande. Vi arbetar i små agila sprintar som är som små projekt, och när en funktion har levererats i slutet av en sprint eller i en utgåva blir de uttråkade och nervösa om jag inte har något nytt att arbeta med.
Projekten är vanligtvis tekniska och de flesta är intresserade av att lära sig nya saker och experimentera med ny teknik. I slutet av projektet finns det ofta en möjlighet att ge dem lite tid för att lära sig en ny färdighet eller kanske byta roll med någon annan för att lära sig en ny roll eller gå på kurs. Detta kommer att fungera beroende på organisationen. Alternativet är naturligtvis att helt enkelt tilldela nästa projekt. Det borde vara riktigt spännande: "Det är i linje med organisationens strategi, jag tror att du är den perfekta personen för att göra det."
För att återknyta till några av de tidigare punkterna: om människor har en direkt påverkan är det mycket motiverande.
Kan Innotas centralisera bemanningen som en modell eller finns det ett verktyg för att ha en centraliserad bemanningsmodell och metodik för att hjälpa till att förstå vilket arbete som kommer, vilket arbete som delegeras ut etc.?
Det grundläggande affärsproblemet är att projekt naturligtvis behöver resurser, men vanligtvis arbetar resurserna inte för projektledarna - de arbetar för någon annan organisation. Särskilt i takt med att organisationerna blir större blir detta allt oftare fallet. Den andra sidan av detta är att resursförvaltarna har dessa resurser, men de vet inte nödvändigtvis var de ska användas eftersom de inte har fingret på pulsen i projektvärlden.
Du vill inte att de ska behöva gå in i projekthanteringsverktyget för att leta efter projekt med resursbehov. Centraliserad bemanning löser detta affärsproblem. Om du inte har centraliserad personal och du har en sådan situation måste projektledarna göra många e-postutbyten eller telefonsamtal till resursförvaltarna för att förhandla och liknande saker. Centraliserad bemanning gör det möjligt att halvautomatisera processen där projektledaren behöver en utvecklare, skickar begäran till en resursförvaltare som har utvecklare och resursförvaltaren kan sedan tilldela dig en utvecklare eller avvisa begäran för att de inte kan göra det, och måste skicka den till en annan resursförvaltare.
Detta gör att du slipper en massa telefonsamtal och e-postmeddelanden. Och det ger dig ytterligare en fördel att du får ett bättre styre. Dessa telefonsamtal och e-postmeddelanden går inte att spåra eller hantera, så genom att göra all kommunikation i verktyget kan du få en inblick i hur processen går. Vad händer till exempel om det finns en resursförvaltare som inte är lyhörd? Finns det projektledare som ständigt ber om samma person, en person som de egentligen inte behöver? Detta är några av anledningarna till att du skulle använda centraliserad bemanning - det är effektivare, det löser det verkliga problemet som är brytningen mellan projektledare och resursförvaltare, och det ger dig styrning.
-
Nils Davis är för närvarande Director of Product Manager på Innotas och ansvarar för att kartlägga och genomföra ändringar av resurshanteringsfunktioner. Nils har över 20 års erfarenhet av projekt- och produktledning på företag som Egress, Naehas, Accept och NetIQ där han haft olika ledarroller. Nils är en ivrig bloggare om genomförande av strategier, planering och innovation.
