Estinator Basic er en simpel applikation, der kan hjælpe med at træffe beslutninger i et projekt ved at lave simuleringer baseret på projekttrekanten.
Det foregår ved at man i kalibreringsmode indtaster de værdier, man har fra sine oprindelige planer og estimater. Herefter kan man gå i simuleringsmode og eksperimentere med hvordan ændringer til én parameter kan opnås ved at ændre på andre parametre.
Estinator Basic har følgende funktioner:
- Installationsprogram til Windows
- Indtastning af planer baseret på estimater
- Registrering af fra og tildato for projektet
- Registrering af scope fra 0 % til 100 %
- Registrering af ressourceforbrug
- Registrering af forventet kvalitet målt på ressourcer
- Anslået forbrug målt i arbejdsdage
- Simulering af ændringer til oprindelig plan
- Automatisk parameteromregning ved ændringer
- Mulighed for at nulstille simulering
- Hjælp til at finde optimal balance i projekttrekanten
- Indbygget minivejledning
Når programmet er startet op, vil man gå direkte i kalibreringsmode, og systemet har forudfyldt parametrene med default værdier:
Der er fire forskellige parametre, man kan skrue på, og de er her forklaret i detaljer:
Tid
Her taler vi om den tid, det tager for hele projektet at blive færdigt (eller den del af det, man kører igennem dette simuleringsværktøj). Systemet arbejder med en start- og slutdato, som man kan ændre på enten ved at vælge datofelterne eller ved at trække i skyderen.
Scope
Scope betyder her omfang, dvs. hvor stor en del af projektet man arbejder på. Normalt starter man med Scope på 100% og kan så evt. reducere det ved simulering. Ændres ved at trække i skyderen.
Ressourcer
Ressourcer angiver dem, der deltager i at levere produktet. Her mener vi kun den tid, der enten bruges på at fremstille eller levere produktet samt den tid, der anvendes på at kvalitetssikre det.
En nem måde at forstå det på, er at det dækker det hold (team), som står for at fremstille produktet. Hvis et projekt består af en projektleder og et team på en scrum master, en product owner/forretningsanalytiker samt fire udviklere og to testere, skal man kigge på hvem der primært står for fremdriften og hvem der primært har med kvalitetssikring at gøre. Her vil man måske vælge at sige at teamet består af syv personer, idet projektleder og scrum master ikke tæller med i dette regnskab.
Kvalitet
I dette simuleringsværktøj har vi valgt at koble kvalitet sammen med de ressourcer, der er med til at sikre kvaliteten som en procentdel af det samlede team. I eksemplet ovenfor er det to ud af syv, dvs. 28,57%.
Når man har udfyldt de fire parametre ud fra de kendte tal i planen (dvs. ud fra de nuværende estimater) er man klar til at simulere.
Simulering
For at simulere flytter man blot omskifteren foroven i skærmbilledet fra Calibrate til Simulate.
Herefter er det muligt at simulere ændringer til de fire parametre to ad gangen.
Hvis man f.eks. ønsker at ændre på tiden, så bliver man nødt til at vælge om det man vil opnå det ved også at ændre på scope, ressourcer eller kvaliteten.
Man kan blive ved med at simulere ved at rykke skyderne op og ned, og på den måde finde en balance, hvor man er tilfreds med det frembragte kompromis. Herefter går man så tilbage til sine sædvanlige planlægningsværktøjer for at finde ud af om det kan lade sig gøre.
Tryk på Reset for at vende tilbage til udgangspunktet. Tryk for ? for at få oplysninger om applikationen.
Hvis man ønsker at arbejde ud fra andre estimater, kan man bare gå helt tilbage til kalibrering ved at flytte omskifteren tilbage til Calibrate.
Eksempler
Herunder bliver eksempler gennemgået i detaljer:
Eksempel – case 1:
En kunde og en leverandør har arbejdet sammen i et stykke tid om at bygge et nyt produkt – et ERP-system f.eks. Leverandøren har på basis af det foreløbige udviklingsarbejde samt det detaljerede afklaringsarbejde med kravene (backlog grooming) udarbejdet nogle estimater for hovedopgaverne (f.eks. baseret på story points) og på basis af det lavet en tidsplan for hvornår man tidligst kan levere resten af produktet.
Leverandøren angiver at det tager ca. syv måneder at blive færdig med resten af produktet.
Det er baseret på at hele produktet er færdigt og testet, dvs. 100% scope. Der resterer herefter kun accepttest (overdragelsesprøve) samt den egentlige implementering i organisationen (undervisning, udrulning, ibrugtagning).
Leverandøren har et team på i alt 11 personer på opgaven fuldtids. Heraf arbejder 3 kun med test (to tekniske testere og en testmanager, som også selv tester). De øvrige arbejder alle med fremdrift i projektet (primært udviklere).
Ovenstående plan er udgangspunktet for alle følgende scenarier
Scenarie 1: Hvordan kommer vi hurtigere i mål?
Kunden vil gerne være færdig på fem måneder i stedet for syv. Hvordan kan det lade sig gøre?
Vi starter med at lægge den grundlæggende plan ind i systemet:
- Tid = 7 måneder
- Scope = 100%
- Ressourcer = 11 fuldtidspersoner
- Kvalitet sætter vi til lidt over de 3/11, f.eks. til 30%. Det betyder altså med andre ord at ressourcerne i gennemsnit bruger 70% tid på fremdrift og 30% på kvalitetsarbejde.
Så ser billedet ca. sådan ud:
Dette skærmbillede repræsenterer nu projekttrekanten, som den ser ud ved start af projektet. Dvs. hvordan er sammenhængen mellem de forskellige parametre.
Nu flytter vi så kontakten foroven om fra Calibration til Simulation:
Nu skriver systemet at vi kan låse op for to skydere ad gangen for at simulere. Samtidig kan vi se at hver af dem har fået en låsefunktion.
Vi skal nu finde ud af hvordan vi får reduceret syv måneder til fem måneder. Man kan starte med at veksle dette til en ren reduktion af scope ved at låse op for de to første skydere og sætte tiden ned til fem måneder:
Vi kan altså teoretisk opnå en besparelse i tid på to måneder ved at reducere opgaven til ca. 70%. Men hvad nu hvis kunden ikke ønsker så stor en reduktion af produktet?
Nu kan vi simulere videre ved at låse tiden og låse op for den næste skyder: Resources. Lad os se hvad der sker, hvis vi sætter scope op fra 70% til 80% og køber dette ved at tilføre flere ressourcer i stedet.
Vi kan nu se at vi blot ved at tilføre hvad der svarer til 1,5 fuldtidsressourcer teoretisk kan komme op på ca. 80% scope – også selv om vi stadig har en tidsperiode på fem måneder.
Som det sidste kan vi se om vi kan opnå yderligere, f.eks. få scope lidt længere op, ved også at inddrage den sidste parameter: Kvalitet.
Vi kan nu se at vi faktisk godt kunne blive hurtigere færdig, hvis vi inddrager alle parametrene.
Men dette er jo en meget toretisk betragtning, så hvordan får man verificeret dette i virkeligheden? Der bliver man nødt til at gå tilbage til projektets sædvanlige værktøjer og finde ud af følgende:
- Holder den nye tidslinje, eller er der andre ting som kan påvirke den, f.eks. ferieperioder eller eksterne afhængigheder?
- Er det muligt og realistisk at reducere scope i produktet som angivet?
- Kan man tilføre de nødvendige ressourcer på en måde, så de kan gøre nogen forskel? Vær her opmærksom på om der er behov for oplæring. I så fald er 1,5 ressource måske ikke nok.
- Kan man omfordele ressourcerne, så vi nu fokuserer lidt mindre på kvalitet end før? Vi har nu et team, der svarer til 12,5 fuldtidsressourcer, men disse skal nu bruge 79% af tiden på fremdrift og kun 21% på kvalitetssikring.
Alt dette ligger udenfor rammerne af værktøjet og kræver at man gennemgår sin plan kritisk. Estinator kan ikke løse alle de planlægningsmæssige udfordringer – kun give et vink om den rigtige retning.
Vi kan endvidere se at økonomien har ændret sig, så produktet bliver billigere. Det hænger jo sammen med at produktet nu er mindre i omfang og angiveligt kan have en mindre kvalitet. Vi har opnået en reduktion fra ca. 1399 arbejdsdage til 1119 arbejdsdage = en besparelse på ca. 20%.
Du kan også se flere demonstrationer af systemet på vores YouTube-kanal
Hent flere vejledninger ved at følge linket herunder.