Skabelon til projektstatusrapport: ugentligt format, eksempel — og hvordan rapporten samler sig selv ud fra opsummeringerne (2026)

En projektstatusrapport er en kort side i fast format, der fortæller dem, der står uden for det daglige arbejde, hvor projektet står: om det er på sporet eller ej, hvad der har ændret sig siden sidste rapport, hvad der kan gå galt, og hvad læseren bliver bedt om at tage stilling til. Den skrives i en fast rytme, for de fleste projekter ugentligt, og den er den samme side hver gang, så læseren kan sammenligne denne uge med sidste uge i stedet for at læse alt forfra.

Denne guide tager først håndværket: formatet, en skabelon du kan kopiere, et udfyldt eksempel og en kortere ugentlig version til en teamleder, der rapporterer opad. Derefter kommer mekanikken: hvornår en rapport er nok, og hvornår et statusmøde stadig er umagen værd, hvor rapporten skrives i de værktøjer, dit team allerede bruger, og hvad der sker mellem møderne og siden. For rapportens sværeste del er ikke selve skrivningen. Det er den halve time forinden, hvor lederen går en uges opkald og chats igennem for at finde ud af, hvad der egentlig blev aftalt.

Hvad en projektstatusrapport er — og hvad den ikke er

Fire dokumenter kredser om et projekt, og rapporten er den, der oftest forveksles med de andre:

Opsummeringen gælder ét møde; rapporten gælder ugen på tværs af dem alle. En stand-up bringer blokeringer frem for dem, der kan fjerne dem; rapporten fortæller en, der står længere væk, om de blokeringer truer datoen. Beslutningsloggen gemmer hvorfor; rapporten siger blot, at en beslutning er truffet eller stadig mangler. Hvis rapporten er svær at skrive, ligger årsagen næsten altid længere oppe i kæden: ugens møder efterlod ingen optegnelse af deres resultater, så lederen rekonstruerer dem fra hukommelsen fredag eftermiddag.

Det ugentlige format: seks blokke, én side

En rapport, der læses hver uge, skal kunne være på én skærm og have den samme form hver gang. Seks blokke i denne rækkefølge:

1. Overskrift. Projekt, rapporteringsperiode, forfatter og datoen for den næste rapport. Læsere kigger først efter perioden — en rapport uden periode er en side med påstande uden et "siden hvornår".
2. Samlet status på én linje. Grøn, gul eller rød — eller på sporet, i risiko, af sporet — plus én sætning, der siger hvorfor. Farven er et resumé af blokkene nedenunder, ikke en fornemmelse; hvis risikoblokken siger, at en leverandør er forsinket to uger, kan linjen ikke sige grøn.
3. Fremdrift siden sidste rapport. Tre til seks linjer om, hvad der er afsluttet, hver som et resultat frem for en aktivitet. "Checkout-flow til gennemsyn hos kunden" er et faktum; "arbejdet på checkout" er det ikke.
4. Næste periode. Hvad teamet forpligter sig til at nå før næste rapport, hver med en ansvarlig. Denne blok er det, næste uges fremdriftsblok skal måles mod.
5. Risici, problemer og beslutninger der skal træffes. En risiko er noget, der kan ske; et problem er noget, der er sket. Hver linje: hvad, effekten på dato eller budget, den ansvarlige, og hvad læseren bliver bedt om at gøre — herunder "ingenting, til orientering". Beslutninger, der skal træffes, får deres egen linje med den dato, projektet har brug for svaret senest.
6. Åbne handlingspunkter. Hvert handlingspunkt, der stadig er åbent fra et hvilket som helst møde i perioden, med ansvarlig og forfaldsdato og en markering af dem, der er overskredet. Det er den blok, de fleste rapporter dropper, og den, læseren bruger til at vurdere, om farven i blok 2 er ærlig.

Tre ting skal udelades: dialog (hvem der sagde hvad), aktivitetslogs (timer, afholdte opkald) og alt, læseren ikke kan handle på. Rapporten er til en, der bruger fire minutter på den. Hver linje skal kunne bestå spørgsmålet "hvad ville læseren gøre anderledes, hvis vedkommende vidste det her?"

Skabelon til projektstatusrapport

Kopiér den ind i et dokument, en kanalbesked eller et canvas. Firkantede parenteser er pladsholdere.

[Projekt] — statusrapport for [periode, fx 20.–24. oktober]
Forfatter: [navn] · Sendt: [dato] · Næste rapport: [dato]
Samlet: [på sporet / i risiko / af sporet] — [én sætning, der siger hvorfor]

Gjort siden sidste rapport
– [Resultat, som et faktum] — [ansvarlig]
– [Resultat] — [ansvarlig]
– [Resultat] — [ansvarlig]

Næste periode (inden [dato for næste rapport])
– [Leverance] — [ansvarlig]
– [Leverance] — [ansvarlig]

Risici og problemer
– [Risiko eller problem] — effekt: [dato / budget / omfang] — ansvarlig: [navn] — ønske: [beslutning senest dato / til orientering]

Beslutninger der skal træffes
– [Spørgsmål, med de muligheder der er på bordet] — skal bruges senest [dato] — fra [navn]

Åbne handlingspunkter
– [Opgave] — [ansvarlig] — forfald [dato] — [åben / overskredet siden dato]
– [Opgave] — [ansvarlig] — forfald [dato] — [åben]

Rækkefølgen er bevidst. En sponsor, der kun læser de første tre linjer, får farven og begrundelsen; en, der læser til ende, får de handlingspunkter, der forklarer farven. Hold overskrifterne identiske fra uge til uge — formatets værdi er sammenligningen.

Eksempel: en udfyldt ugentlig statusrapport

Et lille softwareprojekt, et team med to sprog og en kunde, der læser rapporten hver mandag:

Ordreportal v2 — statusrapport for 20.–24. oktober
Forfatter: Mateusz · Sendt: 24. oktober · Næste rapport: 31. oktober
Samlet: i risiko — betalingsudbyderens sandbox kom fire dage for sent; lanceringsdatoen holder kun, hvis integrationstesten består senest 29. oktober.

Gjort siden sidste rapport
– Checkout-flow til gennemsyn hos kunden; to kommentarer åbne — Ana
– Produktimport fra ERP kører hver nat i staging — Priya
– Spanske og rumænske UI-tekster færdige; fransk på 80 % — Luca

Næste periode (inden 31. oktober)
– Betalingsintegrationstest på udbyderens sandbox — Priya
– Kundens godkendelse af checkout — Ana
– Franske tekster færdige, alle tre sprog gennemgået — Luca

Risici og problemer
– Forsinket betalings-sandbox (problem) — effekt: lancering 7. november holder kun, hvis testen består senest 29. oktober; ellers 14. november — ansvarlig: Priya — ønske: til orientering, beslutning nedenfor
– Kundens svartid på gennemsyn (risiko) — effekt: hver runde tager 3 dage; en tredje runde flytter godkendelsen forbi testvinduet — ansvarlig: Ana — ønske: kunden samler kommentarer i én runde

Beslutninger der skal træffes
– Hvis testen fejler 29. oktober: lancering 14. november med betalinger, eller 7. november med betaling kun mod faktura og kortbetaling tilføjet senere — skal bruges senest 30. oktober — fra kunden

Åbne handlingspunkter
– Send udbyderen IP-tilladelseslisten — Priya — forfald 21. oktober — overskredet siden 21. oktober
– Bekræft go-live-vindue med hostingpartneren — Mateusz — forfald 28. oktober — åben
– Svar på de to checkout-kommentarer — Ana — forfald 27. oktober — åben

Læg mærke til, hvad eksemplet ikke siger: hvor mange møder der blev holdt, hvem der talte, hvor mange timer der gik. Læseren får på én linje at vide, at datoen er i risiko, og i én blok, hvad vedkommende bliver bedt om at tage stilling til.

Ugentlig rapportskabelon til en teamleder

En teamleders ugentlige rapport til sin egen leder er en kortere fætter til projektrapporten. Læseren er én person, ofte med under to minutter, og spørgsmålene er tre: holder teamet sine forpligtelser, hvad står i vejen, og hvad har du brug for fra mig. Fire blokke kan være i en chatbesked:

Team [navn] — uge fra [dato]
Status: [på sporet / i risiko] — [én linje]
Leveret: [to eller tre resultater, hver med et navn]
I vejen: [en eller to blokeringer, hver med, hvem der kan fjerne dem]
Behov fra dig: [én beslutning eller ressource, med en dato] — eller "ingenting denne uge"

To regler gør den læsbar over måneder. For det første er "Behov fra dig" aldrig tom ved et tilfælde: skriv "ingenting denne uge", så lederen ved, at tavsheden er bevidst. For det andet lister "Leveret" folks navne — en ugentlig rapport er også stedet, hvor en leder gør teamets arbejde synligt for en, der ikke ser det dagligt. Hvis teamet allerede har en daglig stand-up med navngivne blokeringer, er "I vejen" en kopi af dem, der stadig står tilbage fredag.

Den ugentlige rapport erstatter det ugentlige statusmøde for det meste af det, mødet bar — informationen. Hvad den ikke kan erstatte, kommer her.

Hvornår et statusmøde stadig er nødvendigt

Et statusmøde er rapportens live-form: hver person fortæller lederen eller sponsoren, hvor tingene står, i et rum, på alles regning. Når der findes en skriftlig rapport, er mødet kun berettiget, når siden ikke kan klare opgaven. Fire tilfælde:

• En beslutning med en afvejning. Rapporten kan opstille mulighederne; den kan ikke forhandle dem. Når "Beslutninger der skal træffes" har en post, hvis svar afhænger af, hvad to interessenter er villige til at give afkald på, slår tredive minutter med begge i rummet to ugers svar-til-alle.
• En dato flytter sig. En forsinkelse bliver sjældent accepteret fra en side. Samtalen om, hvad der flytter med — omfang, budget, et andet projekts start — er et møde, med rapporten som forberedende læsning.
• En risiko har overskredet sin tærskel. I den uge, en risiko bliver til et problem, skal de, der ejer konsekvensen, høre det fra lederen og stille spørgsmål, ikke læse det om mandagen.
• En ny interessent. Den, der ikke har læst de seks foregående rapporter, har brug for én session for at få projektets form; derefter er siden nok.

Et statusmøde er ikke til at læse rapporten højt. Hvis hvert punkt på dagsordenen er "status fra X", så aflys det og send siden; guiden om mødekadence gennemgår, hvilke tilbagevendende møder fortjener deres plads. Når mødet holdes, så kør det ud fra rapporten — risiko- og beslutningsblokkene er dagsordenen, og et effektivt møde slutter med, at disse punkter er markeret som besluttet, åbne eller udskudt. Med interessenter, der taler forskellige sprog, har rummet tre muligheder for selve mødet: en menneskelig tolk — guiden til Zoom-tolk viser, hvordan det sættes op — platformens egne undertekster eller et rum, der oversætter for hver deltager; rapporten, skrevet én gang, er et separat spørgsmål.

Hvor rapporten skrives i de værktøjer, du allerede bruger

Hver større platform efterlader noget efter et møde, som en statusrapport kan bygges af, og hver stopper et forskelligt sted. Kun dokumenteret adfærd, fra leverandørernes egne sider, med den måned hver side blev tjekket:

To ting er ens overalt. Det, et møde efterlader, er ét dokument pr. møde, på det ene sprog, rummet brugte; og om sidste uges næste skridt blev gjort, er ikke noget, dokumentet ved — lederen går hen og tjekker, før vedkommende skriver "gjort". Platformenes live-undertekster — det, Teams og Google Meet viser på skærmen under et opkald — ændrer ikke dokumentet bagefter. Notetakere er samme kategori et skridt videre: dem, der sammenlignes i Otter.ai-alternativer, skriver et resumé pr. møde, og en rapport, der spænder over en måneds møder, er stadig en separat side.

Sådan samler rapporten sig selv ud fra opsummeringerne

InterMIND er et rum til daglig kommunikation, hvor et projekt lever i en kanal, så rapportens råmateriale har et oplagt hjem. Hvert møde i kanalen ender med en opsummering — et resumé, beslutningerne, handlingspunkterne med ansvarlige og datoer — skrevet ud fra selve mødet og leveret på e-mail, som en besked i kanalen og som et link i kalenderbegivenheden. Hvert indlogget medlem læser den på sit eget sprog: optegnelsen oversættes pr. læser, den skrives ikke én gang på det sprog, rummet tilfældigvis brugte, og det samme gælder kanalens chat omkring den, som hvert medlem skriver på sit eget sprog. Ethvert medlem kan redigere opsummeringen, hver redigering bevarer forfatter og versionshistorik, og kanalen gemmer opsummeringen af hver tidligere session — så "gjort siden sidste rapport" er en rulning gennem ugens opsummeringer frem for en rekonstruktion.

Handlingspunkterne bærer deres status med sig. Et punkt vises som skal gøres, gjort eller ikke gjort med en begrundelse, og i en organisation med teamstatussider slået til vurderes tidligere sessioners åbne punkter, når den næste opsummering skrives: et punkt, som nogen har meldt færdigt, markeres som gjort, et punkt, der er drøftet men ikke færdigt, markeres som ikke gjort med begrundelsen i mødets egne ord, og et punkt, ingen tog op, forbliver åbent. Det er skabelonens blok med "åbne handlingspunkter", ført af møderne i stedet for af lederen.

Teamstatussiderne er der, hvor resten af rapporten kommer fra. Én side over de seneste 7, 28 eller 90 dage viser organisationens opgaver, problemer, hvad der er vigtigt og hastende, og de penge, der står på spil, og hver række bærer det ordrette citat fra den opsummering, den bygger på; en opgave bliver stående, indtil nogen lukker den, og efter fire uger uden bevægelse markeres den som gået i stå. Lederen skriver trendlinjen og farven — vurderingen — oven på en side, som møderne allerede har udfyldt. Den samme side kan læses gennem en tilsluttet assistent: en leder, der arbejder i Claude, ChatGPT, Copilot eller Gemini, beder om ugens åbne opgaver og problemer og får rækkerne med deres citater. Teamstatussider er en preview-funktion på betalte abonnementer: organisationens administrator slår dem til under Indstillinger → Avanceret efter at have accepteret alfavilkårene (siden Preview-funktioner beskriver hver enkelt).

Hvor rapporten skal lande i et system of record, tilføjer værten en kopi af opsummeringen til en vilkårlig adresse — et CRM- eller projektværktøjs indgående postkasse — og hver opsummering af mødet eller kanalen sendes også dertil efter en engangsbekræftelse af adressen; mekanikken står i en kopi af hver mødeopsummering i dit CRM, på e-mail, og den samme opsummering ankommer som en webhook eller en Zapier-trigger til teams, der selv sender den ind i et projektværktøj.

En kundeinteressent, der skal se opsummeringerne, inviteres til kanalen på e-mail og deltager med en gratis konto og læser på sit eget sprog; eksterne deltagere i en kanal koster værten ingenting. En gæst til ét møde deltager via link, uden konto og uden omkostning — fra en telefon, i browseren — og hører mødet live på sit eget sprog. Der er ingen optegnelse til en gæst bagefter — kontoen er gratis, og det er den, der gør optegnelsen tilgængelig. Værten stiller rummet til rådighed og betaler på et betalt abonnement kun for de medlemmer, der har været aktive de seneste 28 dage; medlemmer, der bliver stille, beholder deres adgang uden omkostning.

• Åbn en komplet opsummering — en ægte optegnelse gengivet af den samme kode, der skriver din.
• Prøv live-demoen — uden tilmelding; tal, og hør rummet oversat til hver enkelt lytter.

Rapporten som håndværk overlever ethvert værktøj: nogen skal stadig sige, om projektet er på sporet, og hvorfor. Det, der ikke behøver at overleve, er fredagens halve time — at gå en uges opkald igennem, på ét sprog, for at finde ud af, hvad der blev aftalt, og om nogen gjorde det.

FAQ

Hvad er en projektstatusrapport?

En kort side i fast format, sendt i en fast rytme — som regel ugentligt — der fortæller folk uden for det daglige arbejde, hvor et projekt står: en samlet status på én linje med begrundelsen, hvad der er afsluttet siden sidste rapport, hvad der er planlagt før den næste, risici og problemer med deres effekt på dato eller budget, de beslutninger, læseren bliver bedt om at træffe, og de handlingspunkter, der stadig er åbne, med ansvarlige og forfaldsdatoer. Det er den samme side hver gang, så læseren sammenligner uger frem for at læse forfra.

Hvad skal en ugentlig statusrapport indeholde?

Seks blokke: en overskrift med rapporteringsperioden; én linje samlet status med begrundelsen; fremdrift siden sidste rapport som resultater, ikke aktiviteter; forpligtelserne for næste periode med ansvarlige; risici, problemer og beslutninger der skal træffes, hver med sin effekt og et ønske; og hvert åbent handlingspunkt med ansvarlig og forfaldsdato, hvor overskredne er markeret. Udelad dialog, timer og alt, læseren ikke kan handle på.

Hvordan skriver man en projektstatusrapport?

Start fra den forrige rapport: dens blok "næste periode" er denne uges tjekliste, og dens åbne handlingspunkter er enten gjort eller stadig åbne. Gå derefter ugens mødeopsummeringer igennem for, hvad der blev besluttet, og hvad der kom til. Skriv statuslinjen sidst, efter risikoblokken, så farven passer til fakta. Send den samme dag hver uge, til den samme liste, og hold overskrifterne identiske fra rapport til rapport.

Hvad er forskellen på en statusrapport og et statusmøde?

En statusrapport skrives og læses asynkront; et statusmøde er den samme information leveret live, på bekostning af alles tid i rummet. Når der findes en rapport, er et møde berettiget, når siden ikke kan klare opgaven: en beslutning med en afvejning mellem interessenter, en dato der flytter sig, en risiko der netop er blevet til et problem, eller en ny interessent, der én gang har brug for projektets form. Et møde, hvis dagsorden er "status fra hver person", er en rapport læst højt.

Er en ugentlig rapportskabelon til en teamleder anderledes end en projektstatusrapport?

Kortere og stilet til én person. En teamleders ugentlige rapport til sin leder besvarer tre spørgsmål i fire blokke — status på én linje, hvad teamet har leveret med navne, hvad der står i vejen, og hvem der kan fjerne det, og hvad der er brug for fra lederen til hvornår — og kan være i en chatbesked. En projektstatusrapport er længere, spænder over en periode og et sæt interessenter og bærer risici, beslutninger og åbne handlingspunkter på tværs af alle projektets møder.

Hvor ofte bør en projektstatusrapport sendes?

Ugentligt for de fleste projekter: ofte nok til, at en forsinkelse opdages inden for en uge, sjældent nok til, at hver rapport har noget nyt. Hver anden uge passer til lange, stabile projekter med få beslutninger; daglig rapportering hører til en lanceringsuge eller en hændelse og er et andet, kortere dokument. Uanset rytmen bør dagen og modtagerlisten ikke ændre sig — en rapport, der kommer på en ny dag hver uge, bliver ikke læst som en serie.

Skal kunden modtage statusrapporten?

Ja, hvis kunden betaler for projektet, og en beslutning i rapporten er deres at træffe — blokken "beslutninger der skal træffes" er skrevet til dem. Skriv om muligt én rapport til alle frem for en kundeversion og en intern; en rapport med to versioner glider fra hinanden, og den interne bliver den rigtige. Det, der holdes ude af en delt rapport, er teamets interne detaljer — individuel præstation, estimater under forhandling — som hører hjemme i lederens egne noter.

Kilder: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Recap in Microsoft Teams; Zoom — Using Meeting Summary with AI Companion; Google Meet — "Take notes for me" in Google Meet; Google Workspace Updates — "Take notes for me" suggests next steps; Slack — Meeting agenda template (canvas). Microsofts noter, Google Meet-noter og Slack-sider tjekket oktober 2026; Googles meddelelse om næste skridt tjekket september 2026; Microsofts opsummerings- og Zooms mødereferatsider tjekket august 2026. Leverandører ændrer abonnementer, funktioner og sproglister over tid; tjek deres sider for den aktuelle status.