Unøyaktige estimater er en av de mest populære utfordringene innen prosjektledelse. Når du starter et nytt IT-prosjekt, vil du vite to ting: hvor lang tid det kommer til å ta, og hvor mye det kommer til å koste. For å kunne svare på disse spørsmålene må du estimere prosjektene du skal kjøre. Det finnes ingen magisk regel som sier at prosjekt X tar 12 uker og koster $150 000. Eller at et Y-lignende nettsted tar 10 uker å utvikle og koster $100 000.
Hva du vil lære av denne artikkelen:
- Hvordan forbereder prosjektledere seg på kostnadsestimering i prosjektledelse?
- Hvilke estimeringsteknikker er nyttige for prosjektestimering?
- Hvordan forbereder du deg på å estimere kostnader ved hjelp av formler?
Du kan ikke vurdere et prosjekts tidslinje eller kostnader uten grundig estimering, selv om prosjektets omfang er svært likt det du har gjort før. Og det blir enda verre: Estimering vil aldri gi deg et 100% nøyaktig svar på disse spørsmålene også. Så hvorfor estimerer vi? Fordi det er den eneste måten å gjøre antakelser om prosjektets tidslinje og budsjett, arbeidsmengden og ressursene som trengs for å levere det.
Når du estimerer prosjektet, kan du også planlegge ansatte med riktig erfaring og kompetanse. Det du kan gjøre, er å bruke metoder og teknikker som lar deg estimere med størst mulig nøyaktighet. Slik bruker du Agile-metodikken og Planning Poker-teknikken til å lage meningsfulle estimater for prosjektet ditt.
James Grenning utviklet i 2002 en planleggingspokerøkt som er kjent for sin strategi kalt Scrum poker. På begynnelsen av 1950-tallet var estimeringsmetoden hans, Wide band Delphi, for tidkrevende og hadde andre begrensninger. I Grennings tilfelle handlet pokerplanen opprinnelig om å løse et problem der spillerne var for entusiastiske og overfokuserte til å vinne. Mike Cohn, grunnleggeren av Agile allianser og Scrum-allianser, brukte senere denne teknikken i en artikkel med tittelen Agile Estimation and Planning.
Å starte et vellykket prosjekt avhenger i stor grad av hvor godt du forstår hva det faktisk handler om. Det inkluderer:
- Forstå kundens forventninger
- Forståelse av prosjektets mål og hovedmål
- Opprette en liste over nødvendige funksjoner
Når du har gått gjennom kundens brief og har så mye informasjon om prosjektkravene som mulig, kan du liste opp alle funksjonene og sende dem videre til teamet ditt.
For å gjøre dette må du lage en etterslepsliste som består av alle funksjonene som skal gjøres. Deretter kan du prioritere dem, vurdere kompleksiteten og anslå hvor lang tid det vil ta å fullføre dem. En skikkelig etterslepsliste bør bestå av
- Brukerhistorier - beskriver handlingene som brukerne kan utføre på hvert trinn i bruken av produktet
- Akseptkriterier - liste opp de elementene som trengs for at en historie skal kunne fullføres
- Story points - estimer arbeidsmengde, risiko og kompleksitet i relativ poengverdi
- Oppgaver for brukerhistorier - liste opp oppgavene som må gjøres for å levere en brukerhistorie
Det er avgjørende å involvere utviklingsteamet i utarbeidelsen og prioriteringen av produktetterslepet for å sikre nøyaktige og realistiske vurderinger.
Når du har en liste over funksjoner klar, kan du prioritere hver enkelt av dem. Du kan bruke MoSCoW-analysemetoden til å sortere dem slik:
- Må ha
- Burde ha
- Kunne ha
- Vil ikke ha
Når du utvikler et prosjekt, må du fokusere på det du må levere i første omgang. Å bygge en MVP gir deg muligheten til å teste hypoteser om ideen din før du fullfører hele prosjektet, vise den til interessenter eller betabrukere og samle inn tilbakemeldinger som er viktige for den videre utviklingen av resten av funksjonene.
Prioritering kan også hjelpe deg med å estimere prosjektet. Når du fokuserer på de viktigste funksjonene og de du må gjøre først, kan du gjøre mer nøyaktige antakelser om når de vil være ferdige. Når det gjelder "kunne ha"-funksjoner, kan du begynne med et grovt estimat, ettersom de ligger lenger ut i utviklingsprosessen og mye kan endre seg innen teamet ditt kommer til dem (og hvis teamet ditt kommer til dem, ettersom du etter å ha samlet inn tilbakemeldinger om MVP-en din kan snu og ikke inkludere alle de opprinnelig planlagte funksjonene).
Det er imidlertid viktig å estimere alle funksjonene, uavhengig av prioritet (bortsett fra de som "ikke skal være med", selvfølgelig), ettersom du ønsker å få en oversikt over hele prosjektet på én gang. Og når du kommer til de neste fasene av prosjektet, kan du revurdere arbeidsomfanget for å sikre at estimatene dine fortsatt er nøyaktige.
Nå som du har ferdigstilt produktetterslepet ditt, er det på tide å estimere hvert enkelt element. For å gjøre dette bruker vi story points. Dette er enheter Agile-team bruker for å evaluere arbeidet som trengs for å fullføre hvert element i etterslepet. Story points bidrar til å tildele relativ verdi til elementene i etterslepet. De er ikke relatert til tid og kan ha ulik verdi for ulike team, så de har ingen emosjonell verdi. Dermed er det stor sjanse for at teammedlemmene ikke vil øke estimatene bare for å være på den sikre siden. Planning Poker hjelper programvareteamene med å planlegge arbeidsflyten og forbedre prosjektets leveringshastighet.
Ved hjelp av story points kan et team estimere:
Planleggingsøkten er en av estimeringsteknikkene på brutto-nivå, og bruker en modifisert versjon av Fibonacci-sekvensen: 1, 2, 3, 5, 8, 13, 20, 40, 100. For å estimere elementer fra produktetterslepet får teammedlemmene de samme settene med planleggingspokerkort med tall på. Etter en kort introduksjon av etterslepsposten av produkteieren (som ikke stemmer) og diskusjonen, velger de hver for seg kortet med det antallet historiepoeng de anser som relevant for arbeidsmengden som kreves for å fullføre denne posten, og avslører dem samtidig.
Hvis tallene ikke stemmer overens, diskuterer teammedlemmene hvorfor de har valgt et visst antall historiepoeng, og stemmer deretter på nytt. Dette er en del av planleggingspokerprosessen, en konsensusbasert estimeringsmetode som brukes i Agile for å estimere innsatsen for brukerhistorier. De gjør dette til de oppnår konsensus, og går deretter videre til neste punkt i etterslepet. Og hvis antallet man blir enige om er høyt, la oss si 20, 40 eller høyere, betyr det at en historie kan kreve for mye arbeid for én sprint, og at den kanskje må deles opp i mindre oppgaver. Ideelt sett bør presentasjonen av punktet, diskusjonen og avstemningen ta rundt to minutter, noe som gjør det mulig å estimere hele backloggen på kort tid. Men siden poenget her er å estimere hele etterslepet på én gang, kan du ta deg god tid, og ikke bekymre deg hvis noen historier tar litt lenger tid å vurdere.
Teamhastigheten viser hvor raskt prosjektet utvikler seg. Det hjelper deg med å forstå to ting:
- Hvor mye arbeid teamet ditt er i stand til å utføre i løpet av en sprint
- Hva er den forventede datoen for ferdigstillelse av hele omfanget, forutsatt at det er løst
Hastigheten er forskjellig for hvert team. Du kan vurdere den etter de første iterasjonene, når teamet allerede har jobbet med noen funksjoner. Hvis du for eksempel har inkludert fire elementer i etterslepsloggen i den første iterasjonen, med totalt 20 historiepunkter, og teamet har fullført tre av dem, noe som tilsvarer 15 historiepunkter, er dette teamets nåværende hastighet. Husk at bare fullførte elementer teller. Selv om de hadde klart å starte på det fjerde elementet, men ikke har fullført det, teller det ikke.
Scrum-masteren spiller en avgjørende rolle i å legge til rette for estimeringsprosessen og sikre nøyaktige vurderinger under disse øktene.
Etter å ha forhandlet om historiepunkter og vurdert teamets hastighet, kan du fastsette prosjektets tidsplan. Dette gjør du ved å legge sammen teamets hastighet fra de tre siste iterasjonene og dele den på tre. Hvis hastigheten fra disse iterasjonene for eksempel var 20, 23 og 17, vil gjennomsnittshastigheten være omtrent 20 poeng. Hvis den totale arbeidsmengden var estimert til 100 historiepoeng, ville det med en gjennomsnittshastighet på 20 poeng ta fem iterasjoner å fullføre prosjektet. Hvis vi antar at én iterasjon tar to uker, bør du kunne levere prosjektet på 10 uker.
For å fastsette budsjettet for prosjektet ditt kan du bruke denne grunnleggende formelen: (totalt antall historiepoeng / hastighet * teamtimer per sprint) + ikke-lønnskostnader = estimert budsjett. Når du har det totale antallet story points delt på gjennomsnittshastigheten, multipliserer du antall sprinter med 40 timer per uke per teammedlem for å få lønnskostnadene. Deretter legger du til de ikke-lønnsrelaterte kostnadene, som kapitalkostnader, utstyrskostnader, vedlikeholdskostnader, opplæringskostnader osv. Vi har for eksempel et prosjekt som er estimert til 100 story points, og teamets gjennomsnittshastighet er 20. Hvis vi tildeler et team på 5 personer til prosjektet med en timepris på $50, er teamtimene per sprint verdt $20 000 og $100 000 for 5 sprinter. Med en hypotetisk ikke-lønnskostnad på $50 000 blir det estimerte budsjettet for prosjektet vårt $150 000. Med tanke på konfidensintervallene på eksemplariske nivåer på 80-120%, er det rapporterte budsjettintervallet nå $120 000 til $180 000.
Husk at ingen estimering er 100% nøyaktig. Det er best å estimere prosjektet på nytt med noen få iterasjoner, ettersom ting som ressurstilgjengelighet, teamets hastighet eller prosjektets omfang kan endre seg over tid. Når du estimerer på nytt, sørger du for at estimatet ditt er oppdatert. Ved hjelp av programvare for tidsregistrering og ressursplanlegging kan du også administrere teamets tilgjengelighet og omfordele dem ved behov. Med de rette teknikkene og verktøyene kan du gjøre estimatene mer pålitelige og planlegge ditt neste prosjekt bedre.
Nøyaktige prosjektestimater er avgjørende for vellykket prosjektledelse. Ved å forstå forventningene og målene, lage en detaljert etterslepliste, prioritere funksjoner og bruke teknikker som story points og Planning Poker, kan du forbedre nøyaktigheten i estimatene dine. Regelmessig reestimering og bruk av verktøy for tidssporing og ressursstyring øker påliteligheten til prosjektets tidslinjer og budsjetter ytterligere. Ved å følge disse fremgangsmåtene kan du overvinne utfordringene med unøyaktige estimater og sikre bedre prosjektresultater.
Bruk Planning Poker-estimeringsteknikken med letthet
Sjekk hvorfor vår programvare for ressursstyring er valgt av prosjektledere fra Hill-Knowlton eller Stormind Games
Ressurskalenderen (eller prosjektstyringskalenderen, prosjektplanleggingskalenderen, ressursplanleggingsprogramvaren) gjør det mulig å planlegge, administrere og allokere ressurser på en mer effektiv måte - spesielt hvis Microsoft Excel har hatt en ledende rolle i...
Hva er det ultimate målet for prosjektledere? Å gjennomføre prosjektene sine på en vellykket måte. Prosjektlederne selv innrømmer at dette ikke skjer så ofte: Ifølge den siste undersøkelsen Pulse of the Profession blir mindre enn 60% av prosjektene fullført, enten...
Kapasitetsstyring er en strategi som brukes av bedrifter for å utnytte produksjonseffektiviteten best mulig i forhold til etterspørselen etter en tjeneste eller et produkt. Det endelige målet med kapasitetsstyring er å Identifisere og...