Der findes en optimistisk regnefejl, som næsten alle projekter begår mindst én gang: at gange en medarbejder med en 37-timers uge og tro, at man dermed har 37 timers projektarbejde til rådighed. Det har man ikke. En arbejdsuge er fuld af ting, der skal ske, men som ikke er projektet: møder, mails, oplæring, en kollega der lige stikker hovedet ind, en driftsopgave der ikke kan vente. Regner du med den fulde uge, bygger du hele din tidsplan på et tal, der aldrig kommer til at holde. Derfor er effektiv arbejdstid et af de mest undervurderede begreber i projektstyring, og det er værd at forstå ordentligt, før du lover nogen en deadline.
Ren arbejdstid er ikke kalendertid
Når vi estimerer en opgave, tænker vi som regel i ren arbejdstid: den koncentrerede tid, det tager at løse selve opgaven, hvis man ellers får lov at sidde uforstyrret. En udvikler siger måske, at en funktion tager tolv timer. Det er sikkert rigtigt. Problemet opstår, når de tolv timer skal omsættes til kalendertid, altså hvornår opgaven reelt er færdig. For de tolv rene timer skal presses ind mellem alt det andet, og en dag på kontoret rummer sjældent en hel dag effektivt projektarbejde. Derfor kan et estimat, der er helt korrekt i ren arbejdstid, alligevel skride voldsomt, når det møder virkeligheden i kalenderen.
Broen mellem de to er belastningsgraden (også kaldet effektivitetsgraden): den andel af den betalte uge, der faktisk bliver til planlagt projektarbejde. Lad os regne et konkret eksempel igennem for et softwarehold.
Vi begynder med de 37 timer. Så trækker vi fra. Ferie, sygdom og fridage koster over et år gennemsnitligt et par timer om ugen, lad os sige tre. Møder og administration æder let fem timer. Mails, chat og de små afbrydelser, hvor man skal finde tilbage til det, man var i gang med, tager fire. Og løbende drift og ad hoc-opgaver, der ikke hører til projektet, tager yderligere fire. Tilbage står 21 effektive projekttimer ud af 37, altså en belastningsgrad på cirka 57 %. Det er ikke, fordi holdet er dovent, tværtimod. Det er bare sådan, en almindelig uge ser ud, når man ser ærligt på den.
Konsekvensen er til at tage og føle på. Har du en opgave på 21 rene timer og planlægger den som 21 divideret med 37, altså godt en halv uge, tager du fejl. Med en belastningsgrad på 57 % skal de 21 timer bruges 21 divideret med 21 effektive timer om ugen, altså en hel kalenderuge. Det er den slags fordobling, der får ellers fornuftige planer til at vælte.
Belastningsgraden afhænger af rollen
En vigtig nuance er, at belastningsgraden ikke er den samme for alle. Den afhænger stærkt af, hvilken rolle man har, og hvor meget af arbejdet der er afbrydelsestungt.
En projektleder bruger en stor del af ugen på netop at koordinere, holde møder og rydde vejen for andre, og har derfor ofte en lav belastningsgrad på det egentlige projektarbejde. En tester eller en udvikler med afgrænsede, planlagte opgaver og relativ ro kan komme betydeligt højere op. En supporter, der samtidig passer vagter og ad hoc-henvendelser, kan knap nok planlægges ind, fordi driften hele tiden bryder ind. Pointen er ikke at ramme et bestemt tal, men at bruge rollens egen sats i stedet for en flad antagelse om, at alle leverer 37 produktive timer. Netop derfor er det klogt at koble effektiv arbejdstid sammen med usikkerheden i selve estimaterne, som vi behandler under trepunktsestimering, og at lade de realistiske timetal flyde videre ind i projektbudgettet.
Ressourcestyring: allokering og overallokering
Når estimaterne er realistiske, skal arbejdet fordeles på de mennesker, der skal udføre det. Det kaldes allokering: at reservere en andel af en persons tid til bestemte opgaver i bestemte perioder. En allokering på 100 % betyder, at personen er booket en fuld effektiv uge. Så langt så godt. Faren opstår, når summen af en persons allokeringer overstiger 100 %, altså når den samme kollega på papiret er sat til at lave mere, end en uge kan rumme. Det kaldes overallokering, og det er en tavs planlægningsfejl, fordi regnearket gladelig accepterer 150 %, selv om et menneske ikke gør.
Overallokering opstår sjældent med vilje. Den sniger sig ind, fordi flere opgaver, måske fra flere projekter, tilfældigvis lander i samme uge. Resultatet er, at noget af arbejdet ganske enkelt ikke bliver lavet til tiden, og forsinkelsen forplanter sig gennem hele planen. Værktøjet til at rette op på det er ressourceudjævning.
Ressourceudjævning går ud på at glatte toppene ud, så ingen er booket over 100 %. Man kigger på de uger, hvor personen er overbelastet, og flytter noget af arbejdet til uger, hvor der er ledig kapacitet. Bemærk, at den samlede mængde arbejde er den samme før og efter; man har ikke fjernet noget, kun fordelt det, så det kan lade sig gøre i praksis. Prisen er ofte, at nogle opgaver rykker senere, og at projektet dermed kan blive en anelse længere. Til gengæld bliver planen til at stole på. Netop den afvejning mellem varighed og realisme er tæt forbundet med, hvordan man lægger sin tidsplan i et Gantt-diagram, hvor udjævningen bliver synlig som forskudte bjælker.
En sidste ting er værd at huske: ressourcestyring er ikke noget, man gør én gang. Belastningsgraden ændrer sig hen over året med ferie og sygdom, opgaver bliver forsinkede og skubber presset videre, og nye ønsker dukker op undervejs. Derfor hører effektiv arbejdstid og allokering tæt sammen med den løbende projektopfølgning og afvigelseshåndtering, hvor du opdager, når virkeligheden er ved at løbe fra planen, og når endnu en udjævning er nødvendig.
Flere folk giver ikke proportionalt mere output
Der er en beslægtet fælde, som er værd at kende, når man begynder at regne på bemanding. Den handler ikke om den enkeltes uge, men om, hvad der sker, når man sætter flere mennesker på det samme arbejde. Softwareingeniøren Fred Brooks beskrev den allerede i 1970’erne, og pointen holder stadig: mandmåneder og varighed er ikke ombyttelige størrelser. Man kan ikke uden videre veksle “fem personer i to måneder” til “ti personer i én måned”, selv om regnestykket ti gange én giver de samme ti mandmåneder. Tallet passer på papiret, men virkeligheden retter sig ikke efter det.
Brooks brugte et billede, der bider sig fast: ni kvinder kan ikke lave et barn på én måned. Nogle opgaver er grundlæggende sekventielle. De skal ske i en bestemt rækkefølge, hvor det ene trin bygger oven på det forrige, og de lader sig ikke dele op, uanset hvor mange hænder man sætter på. Sætter man flere folk på en opgave, der ikke kan deles, får man ikke fart på, man får bare flere, der venter på hinanden. Det er den samme logik, vi møder, når vi taler om aktiviteter og afhængigheder og om den kritiske vej, hvor visse ting simpelthen må komme før andre.
Endnu mere kontraintuitivt er det, som er blevet kendt som Brooks’ lov: at sætte flere folk på et projekt, der allerede er forsinket, gør det ofte endnu senere. Grunden er ligetil, når man tænker over den. Nye folk skal læres op, før de kan bidrage, og oplæringen udføres af netop de mennesker, der i forvejen har allermest travlt. Den tid, de bruger på at forklare, er tid, de ikke bruger på at flytte projektet fremad. Oven i det kommer koordineringen, og den vokser hurtigere, end man skulle tro.
Kommunikationskanalerne mellem holdets medlemmer vokser nemlig med n·(n−1)/2. To personer har én kanal at holde afstemt. Tre har tre, fire har seks, fem har ti, og seks har femten. Fordobler man holdet, får man altså langt mere end dobbelt så meget at afstemme, og hver ekstra afstemning koster tid og risikerer misforståelser. Det er derfor, et dobbelt så stort hold sjældent leverer dobbelt så meget. En del af den ekstra kapacitet forsvinder i oplæring og koordinering, før den bliver til færdigt arbejde. Set med ressourcestyringens briller er det den samme lære som resten af artiklen: output stiger ikke proportionalt med det, man hælder ind. Ligesom en 37-timers uge ikke er 37 produktive timer, er ti personer ikke ti gange en person. Vil man have mere ud af et forsinket projekt, er svaret oftere at skære i omfanget eller flytte deadline end at kaste flere hænder efter det.
Kort sagt
En 37-timers uge er ikke 37 produktive projekttimer. Fravær, møder, mails, afbrydelser og drift æder timer, så belastningsgraden ofte lander omkring det halve, og den afhænger tilmed af rollen. Estimater i ren arbejdstid skrider, når de omsættes til kalendertid uden at tage højde for det. God ressourcestyring består i at allokere efter realistiske, effektive timer, at opdage overallokering, hvor nogen er booket over 100 %, og at bruge ressourceudjævning til at glatte toppene ud, så planen faktisk kan holde. Og husk, at mere bemanding ikke giver proportionalt mere output: mandmåneder og varighed er ikke ombyttelige, og flere folk på et forsinket projekt kan gøre det endnu senere. Planlæg efter de effektive timer, ikke efter dem, der står på lønsedlen.