Den beste utvikleren sa opp i mars. Begrunnelsen var ikke lønn eller en bedre jobb — det var at hun hadde vært overbooket i et halvt år, og ingen hadde sett det.
På papiret så alt greit ut. Hvert prosjekt hadde sin plan, hver plan så fornuftig ut for seg selv. Problemet var at de samme to-tre personene gikk igjen i alle prosjektene, og ingen hadde lagt sammen belastningen på tvers. Resultatet var at noen jobbet langt over kapasitet mens andre hadde luft i kalenderen.
Overbelastningen var ikke uflaks. Den var en planleggingsfeil.
Og det er det den nesten alltid er.
Når noen i teamet er konstant overbelastet, skyldes det sjelden at det er for mye å gjøre i absolutt forstand. Det skyldes som regel noen få, gjentatte feil i hvordan ressursene planlegges — feil som er enkle å rette når du først ser dem. Du trenger ikke et dyrt bemanningssystem for det; du trenger riktig oppsett i Excel.
I denne guiden går jeg gjennom feilene som gir overbelastning, viser hvordan du går fra overbooking til kontroll, og hvordan du setter det opp i Excel slik at overbookingen syns før den skjer.
Etter noen egne forsøk endte jeg med denne ferdige ressursplanleggingsmalen — heatmap for beleggingsgrad og kapasitet per person og uke var allerede satt opp.
Det er lett å tenke at overbelastning er et tegn på at det er for mye å gjøre. Noen ganger stemmer det. Men oftere er det et fordelingsproblem: arbeidet finnes, kapasiteten finnes — den er bare ujevnt fordelt, og ingen ser det fordi belastningen aldri legges sammen per person.
En vaktliste eller et prosjektskjema viser ikke dette. De viser hvem som jobber og hva som skal gjøres, men ikke om summen går opp for den enkelte. Det er først når du regner beleggingsgrad — planlagte timer mot tilgjengelig kapasitet, per person og uke — at overbookingen blir synlig.
Og når den blir synlig, viser det seg nesten alltid at årsaken er en av de samme håndfull feilene.
Disse går igjen, og hver av dem gjør at planen ser bedre ut enn virkeligheten:
Alle får 40 timer, også den som jobber 80 prosent eller har ferie. Da ser uken ledig ut mens personen i praksis er fullbooket — og overbookingen forsvinner ut av synet før den i det hele tatt er regnet.
Hvert prosjekt ser fornuftig ut alene. Krasjet oppstår når samme person bookes inn i flere prosjekter samtidig — og det syns bare i en personvisning, ikke i prosjektplanene hver for seg.
Oppgaver settes til å ta mindre tid enn de gjør. Summen ser grei ut på planen, men i virkeligheten renner timene over — og personen som har oppgaven, betaler for optimismen.
Planen fyller hver person til 100 prosent uten margin. Når noe uventet dukker opp — og det gjør det alltid — finnes det ingen luft, og belastningen tipper over.
En plan laget ved oppstart og aldri rørt igjen stemmer ikke etter to uker. Overbookingen bygger seg opp i det stille fordi ingen ser de nye oppgavene mot den eksisterende belastningen.
Legg merke til at ingen av dem handler om at folk er late eller trege. De handler alle om hvordan planen er satt opp — og derfor kan de alle rettes i oppsettet.
Når feilene er rettet, handler resten om å fordele om. Det enkleste er å se det: samme team, samme uke, før og etter at oppgavene er flyttet fra de overbookede til dem med ledig kapasitet.
Til venstre er Anna 40 prosent over kapasitet mens Carina har halve uken ledig. Til høyre er den samme oppgavemengden fordelt slik at ingen ligger over 100 prosent — Carina tok det Anna ikke rakk. Arbeidet er det samme; det er fordelingen som endret seg.
Dette er hele forskjellen mellom å oppdage overbelastning og å forhindre den. Ser du «før»-bildet på mandag morgen, gjør du flyttingen før uken starter. Ser du det ikke, oppdager du det først når Anna er utbrent — slik det skjedde med utvikleren som sa opp.
Nøkkelen er at beleggingsgraden regnes ut fra riktig kapasitet — den som tar hensyn til stillingsprosent og fravær. Da treffer du feil 01 og 02 samtidig: kapasiteten blir ærlig, og belastningen summeres per person.
Beleggingsgrad per person og uke. Verdier over 100 % farges rødt med betinget formatering.
| Medarbeider | Kapasitet | Planlagt | Belegg |
|---|---|---|---|
| Anna | 40 t | 56 t | 140 % |
| Bjørn | 40 t | 38 t | 95 % |
| Carina | 32 t | 16 t | 50 % |
Kapasiteten kommer fra en innstillingsfane der du legger inn stillingsprosent og planlagt fravær. Carina står på 32 timer, ikke 40, fordi hun jobber 80 prosent — og da blir hennes 50 prosent et ærlig tall, ikke et som skjuler ledig tid.
Tilgjengelig kapasitet regnes fra stillingsprosent og planlagt fravær — ikke en hel uke rett av.
| Medarbeider | Still.% | Fravær | Kapasitet |
|---|---|---|---|
| Anna | 100 % | 0 t | 40 t |
| Carina | 80 % | 0 t | 32 t |
| David | 100 % | 8 t | 32 t |
For feil 03 og 04 — urealistiske estimater og manglende buffer — er trikset å planlegge mot litt under full kapasitet, for eksempel 85–90 prosent. Da finnes det luft når et estimat sprekker, uten at planen umiddelbart tipper over i rødt.
Excel løser dette godt for et mindre team. Men det er ærlig å si hvor grensen går, for den finnes.
Tegnene på at du vokser ut av Excel er konkrete: flere personer trenger å oppdatere planen samtidig og endringene krasjer, filer versjoneres i flere kopier, og det blir nesten umulig å få sanntidsoversikt over kapasitet og belastning. Når én person må holde hele arket i hodet for at det skal stemme, er det blitt sårbart.
Da — men først da — lønner et dedikert verktøy seg. Inntil dit løser en godt oppsatt Excel-mal nettopp de fem feilene over, til en brøkdel av kostnaden og uten et abonnement som løper videre hver måned.
Overbelastning er et fordelingsproblem, ikke et mengdeproblem — og det rettes i oppsettet.
Sju sammenkoblede ark med heatmap for beleggingsgrad, kapasitetsanalyse per person og uke og seks automatiske diagrammer — for opptil 15 medarbeidere og 10 prosjekter. Ingen makroer.