Felaktiga uppskattningar är en av de mest populära utmaningarna inom projektledning. När du startar ett nytt IT-projekt vill du veta två saker: hur lång tid det kommer att ta och hur mycket det kommer att kosta. För att kunna svara på dessa frågor måste du uppskatta de projekt du ska driva. Det finns ingen magisk regel som säger att projekt X tar 12 veckor och kostar $150.000. Eller att en Y-liknande webbplats tar 10 veckor att utveckla och kostar $100.000.
Vad du kommer att lära dig av den här artikeln:
- Hur förbereder sig projektledare för kostnadsberäkning i projektledning?
- Vilka uppskattningstekniker är användbara för projektuppskattning?
- Hur mycket planering krävs för att förbereda sig för att beräkna kostnader med hjälp av formler?
Du kan inte bedöma ett projekts tidslinje eller kostnad utan en noggrann uppskattning, även om projektets omfattning är mycket lik det du har gjort tidigare. Men det blir ännu värre: en uppskattning kommer aldrig att ge dig ett 100% korrekt svar på dessa frågor också. Så varför gör vi uppskattningar? För att det är det enda sättet att göra antaganden om projektets tidslinje och budget, arbetsbelastningen och de resurser som behövs för att leverera det.
Genom att uppskatta projektet kan du också schemalägga medarbetare med rätt erfarenhet och kompetens. Det du kan göra åt det är att använda metoder och tekniker som gör att du kan estimera med största möjliga noggrannhet. Så här använder du Agile-metoden och Planning Poker-tekniken för att skapa meningsfulla uppskattningar av ditt projekt.
James Grenning utvecklade 2002 den planeringspokersession som är känd för sin strategi, kallad Scrum poker. Under början av 1950-talet var hans uppskattningsmetod, Wide band Delphi, för tidskrävande och hade andra begränsningar. I Grennings fall handlade pokerplanen ursprungligen om att ta itu med ett problem där spelarna var för entusiastiska och överdrivet fokuserade för att vinna. Mike Cohn, grundare av Agile alliances och Scrum alliances, använde senare den här tekniken i en artikel med titeln Agile Estimation and Planning.
Att starta ett framgångsrikt projekt beror till stor del på hur väl du förstår vad det faktiskt handlar om. Det inkluderar:
- Förstå kundens förväntningar
- Förståelse för projektets mål och dess huvudsyfte
- Skapa en lista över nödvändiga funktioner
När du har gått igenom kundens brief och fått så mycket information om projektkraven som möjligt kan du lista alla funktioner och skicka dem till ditt team.
För att göra det skapar du en produktbacklog som består av alla funktioner som ska göras. Du kan sedan prioritera dem, utvärdera deras komplexitet och uppskatta hur lång tid det tar att slutföra dem. En korrekt produktbacklog bör bestå av:
- Användarberättelser - beskriver de åtgärder som användarna kan vidta vid varje steg i användningen av produkten
- Acceptanskriterier - lista de punkter som krävs för att en berättelse ska kunna slutföras
- Story points - uppskatta mängden arbete, risker och komplexitet i relativt poängvärde
- Uppgifter för användarberättelser - lista de uppgifter som behöver utföras för att leverera en användarberättelse
Det är viktigt att involvera utvecklingsteamet i arbetet med att skapa och prioritera produktbackloggen för att säkerställa korrekta och realistiska bedömningar.
När du har en lista med funktioner klar ska du prioritera var och en av dem. Du kan använda MoSCoW-analysmetoden för att sortera dem enligt följande:
- Måste ha
- Bör ha
- Kunde ha
- Kommer inte att ha
När du utvecklar ett projekt ska du fokusera på det du måste leverera i första hand. Genom att bygga en MVP får du möjlighet att testa hypoteser om din idé innan du slutför hela projektet, visa den för intressenter eller betaanvändare och samla in feedback som är viktig för vidareutvecklingen av resten av funktionerna.
Att prioritera kan också hjälpa dig att uppskatta projektet. När du fokuserar på huvudfunktionerna och de som du måste göra först kan du göra mer exakta antaganden om när de beräknas vara klara. För "kan ha"-funktioner kan du börja med en ungefärlig uppskattning, eftersom de befinner sig längre fram i utvecklingsprocessen och mycket kan förändras innan ditt team hinner ta itu med dem (och om ditt team hinner ta itu med dem, eftersom du efter att ha samlat in feedback om din MVP kan ändra dig och inte inkludera alla de ursprungligen planerade funktionerna).
Det är dock viktigt att uppskatta alla funktioner, oavsett prioritet (utom de som inte ska vara med, förstås), eftersom du vill få en överblick över hela projektet på en gång. Och när du kommer till nästa steg i projektet kan du omvärdera omfattningen av arbetet för att se till att dina uppskattningar förblir korrekta.
Nu när du har din produktbacklog klar är det dags att uppskatta var och en av dess punkter. För att göra det använder vi story points. De är enheter som Agile-team använder för att utvärdera det arbete som krävs för att slutföra varje objekt från backloggen. Story points hjälper till att tilldela relativt värde till artiklarna i produktbackloggen. De är inte relaterade till tid och kan ha olika värden för olika team, så de har inte det känslomässiga värdet. Därför är det troligt att teammedlemmarna inte kommer att fylla i uppskattningarna bara för att vara på den säkra sidan. Planning Poker hjälper programvaruteam att planera arbetsflöden och förbättra projektets leveranshastighet.
Med hjälp av story points kan ett team göra en uppskattning:
Planning Session är en av beräkningsteknikerna på bruttonivå och använder en modifierad version av Fibonacci-sekvensen: 1, 2, 3, 5, 8, 13, 20, 40, 100. För att uppskatta artiklar från produktbackloggen får teammedlemmarna samma uppsättningar planeringspokerkort med siffror på. Efter en kort introduktion av produktbackloggen av produktägaren (som inte röstar) och diskussionen, väljer de privat kortet med det antal story points som de anser vara relevanta för den mängd arbete som krävs för att slutföra denna post och avslöjar dem samtidigt.
Om siffrorna skiljer sig åt diskuterar teammedlemmarna varför de har valt ett visst antal story points och röstar sedan igen. Det här är en del av planeringspokerprocessen, en konsensusbaserad uppskattningsmetod som används i Agile för att uppskatta arbetsinsatsen för användarberättelser. De gör så tills de når konsensus och går sedan vidare till nästa objekt från produktbackloggen. Och om det antal som man enas om är högt, låt oss säga 20, 40 eller högre, betyder det att en story kan kräva för mycket arbete för en sprint och kan behöva brytas ned i mindre uppgifter. Helst ska presentationen av objektet, diskussionen och omröstningen ta cirka två minuter, vilket gör det möjligt att uppskatta hela backloggen på kort tid. Men eftersom poängen här är att uppskatta hela backloggen på en gång, ta god tid på dig och oroa dig inte om vissa stories tar lite längre tid att bedöma.
Team velocity visar hur snabbt projektet utvecklas. Det hjälper till att förstå två saker:
- Hur mycket arbete ditt team klarar av att utföra under en sprint
- Vad är det beräknade datumet för att slutföra hela omfattningen, förutsatt att det är fast
Hastigheten är olika för olika team. Du kan bedöma den efter de första iterationerna när ditt team redan har arbetat med vissa funktioner. Om du till exempel har inkluderat fyra produktbacklog-objekt i den första iterationen med totalt 20 story points och teamet har slutfört tre av dem, vilket motsvarar 15 story points, är detta teamets aktuella hastighet. Kom ihåg att endast slutförda objekt räknas. Även om de hade lyckats påbörja det fjärde objektet men inte har avslutat det, räknas det inte.
Scrum Mastern spelar en avgörande roll för att underlätta estimeringsprocessen och säkerställa korrekta bedömningar under dessa sessioner.
När du har förhandlat om story points och bedömt teamets hastighet kan du fastställa projektets tidsplan. För att göra det lägger du till teamets hastighet från de tre senaste iterationerna och delar den med tre. Om t.ex. hastigheten från dessa iterationer var 20, 23 och 17, skulle den genomsnittliga hastigheten motsvara cirka 20 poäng. Om den totala arbetsmängden hade uppskattats till 100 story points skulle det, med en genomsnittlig hastighet på 20 poäng, ta 5 iterationer att slutföra projektet. Om man antar att en iteration tar två veckor, bör du leverera projektet på 10 veckor.
För att bestämma budgeten för ditt projekt kan du använda den här grundläggande formeln: (totalt antal story points / hastighet * teamtimmar per sprint) + icke-lönekostnader = uppskattad budget. När du har det totala antalet story points dividerat med den genomsnittliga hastigheten multiplicerar du antalet sprintar med 40 timmar per vecka per teammedlem för att få fram arbetskostnaden. Lägg sedan till icke-arbetskostnader som kapitalkostnader, utrustningskostnader, underhållskostnader, utbildningskostnader etc. Vi har till exempel ett projekt som uppskattas till 100 story points och vårt teams genomsnittliga hastighet är 20. Om vi tilldelar projektet ett team på 5 personer med en timtaxa på $50 är teamets timmar per sprint värda $20 000 och $100 000 för 5 sprintar. Med en hypotetisk icke-lönekostnad på $50 000 skulle den beräknade budgeten för vårt projekt vara $150 000. Med tanke på konfidensintervallen för exemplariska nivåer på 80-120% är det rapporterade intervallet för vår budget nu $120 000 till $180 000.
Kom ihåg att ingen uppskattning är 100% exakt. Det är bäst att göra en ny uppskattning av ditt projekt med några iterationer mellanrum, eftersom saker som resurstillgänglighet, teamets hastighet eller projektets omfattning kan förändras över tid. Genom att göra en ny uppskattning ser du till att din uppskattning är uppdaterad. Med hjälp av programvara för tidsspårning och resursschemaläggning kan du också hantera teamets tillgänglighet och omfördela dem vid behov. Med rätt tekniker och verktyg kan du göra dina uppskattningar mer tillförlitliga och planera ditt nästa projekt bättre.
Korrekta projektestimat är avgörande för en framgångsrik projektledning. Genom att förstå förväntningar och mål, skapa en detaljerad produktbacklog, prioritera funktioner och använda tekniker som story points och Planning Poker kan du förbättra precisionen i dina estimat. Regelbundna omestimeringar och användning av verktyg för tidsspårning och resurshantering ökar tillförlitligheten i projektets tidslinjer och budgetar ytterligare. Genom att följa dessa metoder kan du övervinna utmaningarna med felaktiga uppskattningar och säkerställa bättre projektresultat.
Använd enkelt uppskattningstekniken Planning Poker
Ta reda på varför vår programvara för resurshantering väljs av projektledare från Hill-Knowlton eller Stormind Games
Resurskalender (eller projekthanteringskalender, eller projektplaneringskalender, resursplaneringsprogramvara) gör att du kan planera och hantera och fördela resurser mer effektivt och effektivt - särskilt om Microsoft Excel hade en ledande roll i din...
Vad är det ultimata målet för projektledare? Att leverera sina projekt på ett framgångsrikt sätt. PM:arna själva medger att detta inte händer särskilt ofta: enligt den senaste undersökningen Pulse of the Profession avslutas mindre än 60% av projekten antingen...
Kapacitetsstyrning är en strategi som används av företag för att på bästa sätt utnyttja produktionseffektiviteten i förhållande till efterfrågan på en tjänst eller en produkt. Det slutliga målet med kapacitetsstyrning är att: Identifiera och...