Et af de spørgsmål, vi oftest får, når nogen overvejer en projektportal, er, om man ikke bare kan bruge Microsofts egen skabelon. Den ligger der jo i forvejen, den koster ikke noget ekstra, og den hedder ligefrem “Projektstyring”. Det er et helt rimeligt spørgsmål, og det korte svar er, at det kan man godt — men det er værd at vide, hvad man får, og hvad man ikke får, inden man beslutter, om det er nok.
Vi plejer faktisk at anbefale, at man starter med standardskabelonen. Til gengæld har vi også set en del organisationer bruge et år på selv at opdage, hvor den holder op, og det er den erfaring, vi gerne vil dele her.
Hvad skabelonen faktisk indeholder
Microsoft dokumenterer selv indholdet, og listen er kortere, end de fleste regner med. Skabelonen hedder Projektstyring (Project management), den ligger under teamsites, og den giver følgende:
| Element | Hvad det er |
|---|---|
| Hjemmeside | En færdig landingsside med billeder, tekst og web parts, som projektgruppen kan tage udgangspunkt i |
| Kalender | Viser teamets Outlook-kalender |
| Projekttracker | En liste i Microsoft Lists til at følge fremdrift |
| Issue tracker | En liste til det, der spænder ben undervejs |
| Dokumentbibliotek | Ét bibliotek til projektets filer |
| Statusrapport | En færdig nyhedsskabelon til at udgive statusopdateringer |
| Papirkurv | Adgang til nyligt slettet indhold |
Selve forsiden er sat op med en række standard-web parts, som man kan redigere eller fjerne: Hero til at fremhæve status, en nedtællingstimer frem mod en dato, dokumentbiblioteket, sitets aktivitet, begivenheder, nyheder, hurtige links og et People-element med de vigtigste kontaktpersoner.
Det er, hvad der er. Der er ikke noget skjult lag under, og der bliver ikke installeret noget. Skabelonen lægger et sæt sider, lister og web parts på et almindeligt teamsite, og derfra er det ens eget.
To ting, man bør vide, inden man trykker på knappen
Man skal være ejer af sitet for at kunne lægge en skabelon på, og det gøres under Indstillinger med Anvend en sideskabelon. Så langt, så godt. Men der er to detaljer, som overrasker folk, og som er værd at have med, inden man prøver det af på noget, der allerede er i brug:
- Indholdet bliver ikke flettet sammen. Lægger man skabelonen på et site, der allerede har indhold, får man en ny forside, og det eksisterende indhold bliver gemt som en dubletside under Sitets indhold. Det forsvinder ikke, men det står heller ikke længere, hvor folk plejer at finde det.
- Der er ingen fortryd-knap. Microsoft har ingen automatisk måde at rulle en anvendt skabelon tilbage på. Alt, hvad skabelonen laver, kan fjernes manuelt — sider kan slettes, temaer kan sættes tilbage — men det er håndarbejde.
Dertil kommer en mindre ting, som ofte forvirrer: er sitet koblet på et hub-site, arver det hubbens tema kort efter, man har genudgivet. Skabelonens eget udseende holder altså ikke, hvis man har en hub-struktur.
SharePoint projektstyring skabelonen er god nok til
Som vi ser det, er der tre situationer, hvor man ikke skal bygge noget som helst oveni:
- Ét projekt ad gangen, med en klar ende. Et byggeri, en implementering, en flytning. Projektgruppen skal bruge et sted at lægge filer, følge opgaver og give status. Skabelonen kan det hele.
- En lille organisation. Har man fem-ti projekter kørende, og kender alle hinanden, er der ingen gevinst ved metadata og automatik — der er kun vedligehold.
- Man vil finde ud af, hvad man har brug for. Det er faktisk den bedste grund. Brug skabelonen på tre projekter, og se, hvad folk selv begynder at lave om. Det er en langt bedre kravspecifikation end et møde.
Hvad skabelonen ikke gør
Den har ingen metadata og ingen indholdstyper
Projekttrackeren og issue-trackeren er almindelige lister, som man tilpasser ved at rette tekstfelterne. Der er ingen indholdstyper, ingen styret ordliste, ingen obligatoriske felter og ingen sammenhæng mellem det, man skriver i ét projekt, og det, der står i et andet. I praksis betyder det, at søgning på tværs ikke virker, som folk forventer, fordi der ikke er noget ensartet at søge i.
Den sørger ikke for, at projekt nummer halvtreds ligner projekt nummer ét
Skabelonen bliver lagt på ét site ad gangen, af den, der ejer sitet. Der er ingen automatisk oprettelse, ingen navngivningsregler og intet, der holder folk til den oprindelige struktur. Efter det tiende projekt har hver projektleder rettet i sit eget, og efter det tyvende ligner to sites sjældent hinanden. Det er ikke en fejl i skabelonen — den er ikke lavet til at holde styr på en portefølje.
Der er intet overblik på tværs af projekterne
Alt i skabelonen er scoped til ét site. Der er ingen samlet liste over alle projekter, ingen status på porteføljeniveau og ingen måde for ledelsen at se, hvordan det går, uden at åbne projekterne ét ad gangen. Det er efter vores erfaring det punkt, hvor organisationer oftest beslutter at gå videre.
Der er ingen godkendelser, livscyklus eller oprydning
Skabelonen indeholder ingen flows. Der er intet, der sender et dokument til godkendelse, rykker for en frist, arkiverer projektrummet, når projektet lukker, eller sørger for, at gamle projekter ikke bliver liggende for evigt. Det kan alt sammen bygges med Power Automate — det er bare ikke noget, man får.
Der er ingen tidsplan med afhængigheder
Projekttrackeren er en liste, ikke en plan. Skal en forsinkelse på én opgave kunne skubbe de opgaver, der afhænger af den, og skal man kunne se en ressourcebelastning på tværs af teamet, er det Planner premium eller Project, man skal se på — og det koster pr. bruger pr. måned. Vi har skrevet om forskellen på Planner, Project, Teams og SharePoint et andet sted.
Pas på: skabelonen i Teams er ikke den samme
Der findes også en projektskabelon i Teams, der hedder “Manage a Project”, og de to bliver tit forvekslet. Teams-skabelonen giver et team med kanalerne General, Announcements, Resources og Planning plus apps som Approvals, Milestones, OneNote, Power Automate, Planner og et par SharePoint-lister.
Begge dele er såkaldte Microsoft 365-forbundne skabeloner, hvilket betyder, at SharePoint-delen bliver lagt på sitet og sat op som faneblade i teamets General-kanal. Så de overlapper — men de er ikke ens, og man skal vælge, hvilken vej man går ind, før man begynder. Opretter man begge dele oveni hinanden, ender man med to forsider og to steder at lede.
Hvornår er det tid til at gå videre end skabelonen?
Som vi ser det, er der fire signaler, og de kommer næsten altid i den rækkefølge:
- Nogen spørger, hvor skabelonen til projektbeskrivelsen ligger — og svaret afhænger af, hvem der spørger.
- To projektledere har lavet hver deres struktur, og ingen af dem er forkert.
- Ledelsen beder om en oversigt, og nogen laver den i et regneark.
- Et projekt er lukket for et år siden, og ingen ved, om sitet må slettes.
De tre første handler om struktur, det sidste om livscyklus. Ingen af dem løses ved at rette i skabelonen — de løses ved at lægge indholdstyper, metadata, automatisk oprettelse og et porteføljeoverblik ind bagved. Det er præcis det, en projektportal er.
Konklusion
Konklusionen er måske ikke så skarp, som man kunne ønske sig. Standardskabelonen er et reelt godt sted at starte, den er med i den Microsoft 365-aftale, man har i forvejen, og for en organisation med få projekter ad gangen er den helt igennem tilstrækkelig. Vi siger det gerne højt, også selvom vi lever af det modsatte.
Men skabelonen er lavet til ét projekt, ikke til en portefølje, og den er lavet til at blive tilpasset af den enkelte, ikke til at holde tyve projektledere på samme spor. Er det problemet, man har, hjælper det ikke at rette i skabelonen — så skal der struktur bagved, og den struktur bygger man én gang.
Vil man vende det med nogen, er en workshop på et par timer som regel nok til at afgøre, hvad der er den rigtige vej, 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.
- SharePoint, Planner, Project eller Teams — hvad man skal bruge til hvad.
- Microsofts egen dokumentation af skabelonen — og oversigten over alle SharePoint-skabeloner.