SharePoint, Planner, Project eller Teams — hvad skal man bruge til projektstyring?

Vi har bygget projektportaler i SharePoint, siden Bluedock startede i 2012, altså de seneste 14 år, og der er ét spørgsmål, der går igen næsten uanset hvem vi sidder overfor: skal vi bruge Teams, Planner, Project eller SharePoint til vores projekter? De ligger jo alle sammen i den Microsoft 365-aftale, man betaler for i forvejen.

Vi kunne godt tænke os at nuancere det spørgsmål lidt, for i mindst ét af tilfældene er der slet ikke tale om et valg mellem to ting, sådan som mange tror. Og vores erfaring er i øvrigt, at de fleste organisationer ikke har et planlægningsproblem — de har et dokument- og overblik-problem. Det er en vigtig skelnen, fordi de to problemer bliver løst hvert sit sted, og fordi kun det ene af dem koster ekstra pr. bruger pr. måned.

Fire værktøjer, kort fortalt

Vi har samlet det i et skema, som nogenlunde svarer til den tavletegning, vi ender med at lave på det første møde.

Teams og SharePoint er det samme sted set fra to sider

Den misforståelse, vi oftest møder, er, at man skal vælge mellem Teams og SharePoint. Det skal man ikke, for det er ikke to systemer, og det er værd at få af vejen først, fordi resten af diskussionen ellers kommer til at handle om det forkerte.

Hvert team i Teams har et SharePoint-websted bag sig, og fanen Filer i en kanal er i virkeligheden en mappe i det websteds dokumentbibliotek. Microsoft skriver det selv ganske firkantet: at se på Filer-fanen i et team er det samme som at kigge i kanalens mappe i SharePoint-bibliotekets indhold. Når to kolleger sidder i det samme Word-dokument inde i Teams, foregår det altså i SharePoint, og de rettigheder og sikkerhedsindstillinger, man sætter i SharePoint, slår igennem i Teams med det samme, uden at nogen behøver at gøre noget.

Man kan vel sige, at “vi bruger Teams til vores projekter” i praksis betyder “vi bruger SharePoint, vi har bare ikke indrettet det”. Det er ikke ment som en kritik — det er bare der, hvor det interessante spørgsmål begynder.

Det interessante spørgsmål er, hvor meget struktur der ligger bag

Opretter man et team pr. projekt og lader det blive ved det, får man et websted med ét dokumentbibliotek, en mappe pr. kanal og ellers ikke så meget: ingen metadata, ingen dokumenttyper, ingen skabeloner, ingen godkendelser og ingen måde at se på tværs af projekterne. Det fungerer udmærket, når man har fem projekter kørende. I vores erfaring holder det op med at fungere et sted mellem tyve og halvtreds projekter, og det sker sjældent fra den ene dag til den anden — det er snarere noget, der langsomt bliver mere besværligt, indtil nogen siger det højt.

En projektportal skifter ikke frontend. Den ændrer det, der ligger bagved: indholdstyper og metadata i stedet for mappenavne, en skabelon der sørger for, at projektrum nummer halvtreds ser ud som nummer ét, automatik i Power Automate, og en samlet liste over alle projekter med status, ejer, fase og risiko.

Og portalen bliver ikke et sted, folk skal gå hen i stedet for Teams. SharePoint-sider, -lister og -biblioteker kan sættes ind som faneblade i en Teams-kanal, så både projektrummet og porteføljeoverblikket står inde i Teams ved siden af samtalen. Man kan i øvrigt også gå den modsatte vej og koble et team på et SharePoint-websted, der findes i forvejen.

Det samme mønster kan man se i Microsofts egen projektskabelon til Teams, “Manage a Project”. Den består af nogle kanaler plus SharePoint-lister (en projekttracker og en issue-tracker), Milestones, Approvals, SharePoint-sider, Power Automate, OneNote og en Planner-plan. Selv Microsofts eget bud på et projektteam er altså i al væsentlighed SharePoint vist inde i Teams.

En detalje, som overrasker mange

Almindelige kanaler deler ét SharePoint-websted med en mappe pr. kanal, men private og delte kanaler får hver deres eget websted — ikke en mappe, men et selvstændigt sted med egne rettigheder, som hverken teamets øvrige medlemmer eller administratorer har adgang til, medmindre de selv er medlem af kanalen.

Et projektteam med tre private kanaler har altså projektdokumenter fordelt på fire forskellige websteder. Det er ofte den helt konkrete grund til, at “det ligger i Teams” holder op med at være et brugbart svar på, hvor et dokument er, og det er også her, man kan komme til at tro, at en oprydning eller en opbevaringspolitik rammer bredere, end den i virkeligheden gør.

Planner er til opgaver, ikke til dokumenter

Planner er godt til det, det er lavet til, og det skal man bestemt ikke lade være med at bruge. Med en helt almindelig Microsoft 365-licens får alle brugere det, Microsoft kalder basic plans, med fire visninger — Grid, Board, Schedule og Charts — plus My Tasks og My Day. Skal en projektgruppe holde styr på, hvem der gør hvad inden hvornår, er det rigeligt, og det koster ikke noget ekstra.

Det, Planner ikke gør, er lige så vigtigt at have med. Planner håndterer ikke dokumenter med versionsstyring, ikke metadata, ikke godkendelsesflows, ikke opbevaringspolitikker, og ikke overblik på tværs af fyrre projekter. En opgave kan godt have en fil hængende ved sig, men en projektportefølje er ikke det samme som en opgaveliste med vedhæftninger.

Er Microsoft Project og Planner det samme?

Efterhånden næsten. Project for the web blev pensioneret den 1. august 2025, funktionerne er flyttet ind i Planner, og samtidig skiftede licenserne navn:

• Project Plan 1 hedder nu Planner Plan 1
• Project Plan 3, som tidligere hed Project Online Professional, hedder nu Planner and Project Plan 3
• Project Plan 5 hedder nu Planner and Project Plan 5

Så svaret i dag er, at Planner er appen, og at Project er navnet på de dyrere planer i den. Man skal med andre ord ikke vælge mellem Planner og Project, men tage stilling til, om man vil betale for premium-funktionerne i Planner.

Hvornår er det så premium-funktionerne, man mangler?

Microsoft deler funktionerne op i to niveauer, og det skel er faktisk præcist nok til at bruge som beslutningsgrundlag:

• Planner Plan 1 og opefter giver Timeline-visningen (Gantt), afhængigheder mellem opgaver, People-visning og mål.
• Plan 3 og 5 lægger sprints, teamworkload, brugerdefinerede felter, opgavehistorik og rapportering oveni.

Har man projekter, hvor en forsinkelse på én opgave reelt skal skubbe femten andre, og hvor nogen skal kunne se ressourcebelastningen på tværs af teamet, så er det de funktioner, man har brug for. Det er ægte projektledelse, og det findes ikke i SharePoint, uden at nogen bygger det.

Der er dog tre ting, man bør være opmærksom på, inden man konverterer sine planer til premium:

• Premium-planer ligger i Dataverse og ikke i Microsoft 365-gruppen. Det er altså en anden datamodel og en anden platform end resten af samarbejdet.
• Vejen tilbage er ikke gratis. Nedgraderer man en premium-plan til basic igen, ruller planen tilbage til det tidspunkt, hvor den blev opgraderet. Alt arbejde imellem skal kopieres manuelt, og planen bliver ikke længere delt med gruppen bagefter.
• Integrationen bliver løsere. En basic-plan, der er sat ind på en SharePoint-side, bliver efter konverteringen til et link, som brugerne skal følge ud af siden for at åbne planen.

Og så er der prisen. Premium-funktionerne kræver mindst én Planner Plan 1-licens pr. bruger pr. måned. Vi skriver ikke kronebeløb her, for de ændrer sig løbende, men regnestykket er nemt nok at lave selv: antal projektdeltagere gange prisen pr. bruger gange det antal måneder, man regner med at bruge løsningen. Microsofts egne priser på planerne står her.

SharePoint er fundamentet under det hele

SharePoint er ikke et alternativ til Teams, men det lag, Teams viser, og det er samtidig det eneste af de fire, der tager sig af det, de fleste projekter i virkeligheden drukner i:

• Dokumenter med struktur. Versionsstyring, metadata, dokumenttyper og skabeloner, så et projektdokument ligger ét sted og hedder det samme på tværs af alle projekter.
• Rettigheder og compliance. Hvem der må se hvad, hvad der skal gemmes hvor længe, og hvad der sker med et projektrum, når projektet lukker.
• Godkendelser og automatik. Power Automate opretter projektrummet, sætter strukturen op, sender til godkendelse og rykker, når en frist nærmer sig.
• Overblik på tværs. Én liste over alle projekter med status, ejer, fase, budget og risiko, samlet fra projektrummene i stedet for skrevet manuelt i et regneark.

Og så er der det økonomiske argument, som man ikke skal underkende: SharePoint er med i den Microsoft 365-aftale, man har i forvejen. En projektportal i SharePoint koster det, det koster at bygge den, og ikke et beløb pr. bruger pr. måned, der løber videre i al fremtid.

Hvilket program er så godt til projektstyring?

Som vi ser det, afhænger svaret helt af, hvad der gør ondt lige nu:

• “Vi ved ikke, hvem der gør hvad.” Så vil vi starte med Planner. Det er med i aftalen i forvejen, og det tager en eftermiddag.
• “Vi kan ikke finde dokumenterne, og hvert projekt gør det på sin egen måde.” Det er en SharePoint-opgave, og den bliver løst bag den Teams-frontend, man allerede bruger. Det er i øvrigt langt den hyppigste henvendelse, vi får.
• “Ledelsen kan ikke se status på tværs af projekterne.” Også SharePoint, i form af et porteføljeoverblik bygget på data fra projektrummene.
• “Vores tidsplaner har reelle afhængigheder, og vi skal kunne se ressourcebelastning.” Så er det Planner premium eller Project, og så skal man betale pr. bruger. Det er pengene værd, hvis man har det problem — men de fleste har det ikke.

I praksis bruger man dem sammen

Det er som regel ikke enten-eller, og det er heller ikke et farvel til noget. En projektportal, sådan som vi typisk bygger den, ser ud på den måde, at SharePoint holder projektrummene, dokumenterne, metadataene og porteføljeoverblikket, mens Power Automate opretter nye projekter fra en skabelon, så det ottende projekt ligner det første. Planner holder opgaverne inde i det enkelte projekt, og Teams er der, hvor projektgruppen ser det hele og taler sammen om det, fordi portalen sættes ind som faneblade og ikke som et nyt sted at gå hen. Og har ét af projekterne brug for en rigtig Gantt-plan, køber man premium-licenser til de tre-fire personer, der skal lægge planen, frem for til alle 120.

Vi bygger selv portalen på SharePoints standardkomponenter — lister, biblioteker, indholdstyper, sidetemplates og Power Automate — og tilpasser dem så til den projektmodel, organisationen arbejder efter. Der er ingen platform ovenpå Microsoft 365, ingen brugerlicens og ingen binding. To eksempler kan ses hos Implement Consulting Group, der styrer pipeline og projekter i samme løsning, og hos Ejlskov, hvor sagsdokumentation og projektstyring hænger sammen.

Konklusion

Konklusionen er måske ikke så skarp, som man kunne ønske sig. Men med de 14 års erfaring, vi har, og med den platform Microsoft leverer lige nu, er vi ikke i tvivl om, at de fleste organisationer får mest ud af at lægge struktur på SharePoint-siden og lade Teams være det sted, hvor løsningen bliver vist. Det er der, problemet som regel er, og det er samtidig den del, der ikke koster noget pr. bruger.

Men det er lige så klart, at har man et enkelt behov, kører få projekter ad gangen og mangler reelt bare at kunne se, hvem der gør hvad, så er den bedste løsning selvfølgelig at holde sig til Planner og lade være med at bygge noget. Og har man omvendt tidsplaner med ægte afhængigheder, skal man ikke forsøge at lave dem i SharePoint — så er premium-licenserne pengene værd.

Vil man vende det med nogen, er en workshop på et par timer som regel nok til at afgøre, om man har et planlægningsproblem eller et overblik-problem, og bagefter får man en fast pris frem for et overslag.

Videre herfra

• Projektstyring i SharePoint — hvad en projektportal indeholder, og hvad den koster.
• Hvad er formålet med en projektportal? — hvorfor den slags løsninger bliver brugt, og hvornår de ikke gør.