Waarom je SharePoint-project al vóór de start kan mislukken

🧩 In het kort

Veel SharePoint-projecten mislukken al vóór de kick-off, niet door de techniek, maar door ontbrekende keuzes. 

Zonder heldere use-cases, meetbare succescriteria, eigenaarschap, lichte maar duidelijke governance, een basis informatiearchitectuur, een realistisch migratieplan en aandacht voor adoptie, ontstaat er al snel wildgroei, slechte vindbaarheid en lage gebruikersacceptatie. 

Start daarom met een kleine pilot, leg de spelregels vooraf vast en schaal pas op als het werkt.

Je kent ’m misschien: iemand roept in een meeting “We moeten iets met SharePoint.” Iedereen knikt. Er wordt een projectgroep gevormd, een planning gemaakt, en voor je het weet staat er een kick-off op de kalender. En toch… maanden later hoor je: “SharePoint werkt niet”, “niemand gebruikt het”, “het is een rommeltje” of “we zijn terug naar de netwerkschijf”.

Het pijnlijke is: in veel organisaties gaat het niet mis tijdens de implementatie. Het gaat mis ervoor. In de keuzes (of het gebrek daaraan) die je maakt vóórdat je ook maar één site aanmaakt. In dit artikel laat ik zien waar het vaak fout gaat in de voorbereidingsfase, en wat je kunt doen om dat te voorkomen.

Inhoudsopgave

Eerst dit: wat is ‘mislukken’ bij SharePoint?

Een SharePoint-project “mislukt” zelden met een spectaculaire crash. Het sterft meestal langzaam, door duizend kleine frustraties:

  • De adoptie blijft laag: mensen blijven mailen, chatten of op een netwerkschijf werken.

  • Er ontstaat wildgroei aan Teams en sites: niemand weet waar iets hoort.

  • Zoeken “werkt niet” (maar eigenlijk is er geen structuur, metadata of eigenaarschap).

  • Rechten zijn chaos: te streng (niemand kan werken) of te los (risico’s).

  • Content veroudert: niemand voelt zich verantwoordelijk.

  • De kosten lopen uit door eindeloos bijsturen, rework en “extra wensen”.

Als je dit herkent: de oorzaak zit vaak in ontbrekende fundamenten. SharePoint is niet alleen een tool; het is een manier van werken. En dat vraagt voorbereiding.

voordeel-gebruik-sharepoint-standaard-templates-03

De 9 oorzaken dat je project al vóór de start ontspoort

1. Geen businessdoel: SharePoint als “doel op zich”

De meest voorkomende valkuil: je start vanuit de oplossing. “We gaan naar SharePoint” klinkt modern en logisch, maar het zegt niets over het probleem dat je oplost.

Symptomen

  • De projectomschrijving is: “documenten migreren naar SharePoint”.

  • Iedereen heeft een ander beeld bij “succes”.

  • Er komen gaandeweg allerlei wensen bij (“dan kunnen we ook gelijk…!”).

Wat je wél nodig hebt
Begin met maximaal drie concrete use-cases. Bijvoorbeeld:

  • “We willen versiebeheer en samen aan documenten werken zonder e-mailbijlagen.”

  • “We willen een intranet waar nieuws en kennis vindbaar is binnen 30 seconden.”

  • “We willen projectdossiers met duidelijke rechten, templates en lifecycle.”

Een scherpe use-case dwingt je om keuzes te maken: structuur, rechten, metadata, training, en inrichting.

2. Geen succescriteria: niemand kan winnen

Als je vooraf niet afspreekt wat “goed” is, dan wordt elk resultaat discussie. De één kijkt naar techniek (“het staat live”), de ander naar gedrag (“niemand gebruikt het”), en een derde naar compliance (“het is niet veilig”).

Maak succes meetbaar, bijvoorbeeld:

  • 70% van de doelgroep gebruikt Teams/SharePoint wekelijks voor documentcollaboratie.

  • Zoektijd naar standaarddocumenten is gehalveerd.

  • 90% van de documenten is geclassificeerd (minimaal op vertrouwelijkheid).

  • Elke site heeft een eigenaar en is na X maanden gereviewd.

Je hoeft niet alles te meten, maar kies 3–5 KPI’s die passen bij je use-cases.

3. Scope te breed of te vaag: “alles moet erin”

“Alles naar SharePoint” is geen scope, het is een recept voor stress. SharePoint raakt processen, content, rechten, samenwerken, cultuur en governance. Als je dat allemaal tegelijk doet, kun je nergens écht goed in worden.

Tip: knip het in fases:

  1. Pilot met 1–2 teams en 1 use-case.

  2. Opschalen met templates en governance.

  3. Migratie in waves (per afdeling, per contenttype).

  4. Optimaliseren (zoekervaring, automatisering, opschonen).

Als je klein start, kun je groot eindigen zonder chaos.

4. Geen eigenaarschap: iedereen stakeholder, niemand owner

SharePoint-projecten verdrinken in meningen wanneer niemand eindverantwoordelijk is. IT beheert de techniek, maar wie bepaalt de structuur? Wie beslist over naamgeving? Wie zegt “nee” tegen extra scope?

Zonder product owner krijg je:

  • eindeloze discussies en wisselende besluiten;

  • incomplete governance (“doen we later”);

  • eindgebruikers die afhaken omdat het te lang duurt.

Wat werkt
Wijs één duidelijke product owner / business owner aan (niet per se IT), met mandaat. Combineer dat met heldere rollen:

  • IT / M365 beheer: technische kaders, security, lifecycle.

  • Information owners: inhoud, vindbaarheid, kwaliteit.

  • Site owners: dagelijkse verantwoordelijkheid per site/team.

  • Champions: mensen uit de business die helpen bij adoptie.

5. Governance uitstellen: “dat regelen we later wel”

Dit is misschien de dodelijkste. Governance voelt als gedoe, dus we starten liever “gewoon”. Alleen: als je eenmaal tientallen sites en Teams hebt, is het veel moeilijker (en duurder) om structuur terug te brengen.

Governance hoeft niet zwaar te zijn. Maak vóór de start een minimale set afspraken (een “MVP governance”):

  • Welke typen sites bestaan er (team, project, afdeling, extern)?

  • Naamgeving (simpel, consistent, vindbaar).

  • Wie mag aanmaken, en hoe worden owners vastgelegd?

  • Rechtenmodel (owners/members/visitors + uitzonderingen).

  • Lifecycle: wanneer reviewen, archiveren, verwijderen?

  • Basis voor sensitiviteit/retentie (in ieder geval: wat is vertrouwelijk?)

Met zo’n basis voorkom je sprawl zonder bureaucratie.

6. Geen informatiearchitectuur: huis bouwen zonder plattegrond

Als je de informatiearchitectuur overslaat, krijg je de klassieker: “Zoeken werkt niet.” In werkelijkheid werkt zoeken prima—maar zonder consistente contenttypes, metadata, navigatie en eigenaarschap is het alsof je bibliotheekboeken zonder labels in dozen stopt.

Wat je minimaal nodig hebt

  • Een contentinventaris: wat voor soorten documenten heb je?

  • Basisprincipes: waar sla je wat op? (team vs project vs intranet)

  • Een paar simpele metadata-velden (niet 20!):

    • documenttype (template/rapport/contract/procedure)

    • onderwerp of proces

    • vertrouwelijkheid (indien relevant)

De kunst is: net genoeg structuur om vindbaarheid te verbeteren, zonder dat mensen het als administratie ervaren.

7. Migratie onderschatten: rotzooi verplaatsen = rotzooi in de cloud

Migratie wordt vaak gezien als “kopiëren”. Maar het is ook een moment van waarheid: je ontdekt duplicaten, verouderde files, onbekende eigenaren en gevoelige data op verkeerde plekken.

Een gezond migratiepad

  1. Inventaris: welke bronnen zijn er (fileshares, lokale schijven, oude SharePoint)?

  2. Classificatie: wat is waardevol, wat mag weg, wat is gevoelig?

  3. Opschonen: verwijderen/archiveren/dupliceercontrole.

  4. Migreren in waves.

  5. Valideren: is content vindbaar, kloppen rechten, werken links?

Belangrijk: wijs per bron een content owner aan. Zonder owner geen migratie—anders migreer je “wees-content” waar niemand ooit nog naar omkijkt.

8. Adoptie vergeten: de menskant komt “aan het einde”

Een training op het einde is te laat. Mensen hebben dan al hun oordeel gevormd (“gedoe”) of hebben eigen workarounds gebouwd.

Adoptie begint voor de eerste livegang:

  • Leg uit waarom (use-case) en wat verandert er in het werk.

  • Maak het concreet met “day-in-the-life” voorbeelden.

  • Werk met een champions netwerk: collega’s die het in de praktijk laten zien.

  • Maak korte werkinstructies: “hoe deel ik een document”, “hoe maak ik een projectdossier”, “hoe vind ik de laatste versie”.

En misschien wel het belangrijkst: ontwerp de omgeving zó dat het “juiste gedrag” de makkelijkste route is.

9. Verkeerde projectaanpak: waterval voor iets dat iteratie vraagt

SharePoint is niet alleen software opleveren; het is gedrag, afspraken en verbetering. Als je alles vooraf dichttimmert, mis je feedback. Als je alleen maar “snel live” wilt, bouw je een fundament van zand.

Een betere aanpak

  • Start met een pilotteam en echte content.

  • Meet frictie: waar loopt men op vast?

  • Pas templates/governance/IA aan.

  • Rol uit met herhaalbare patronen.

De win: minder discussies, meer bewijs, sneller draagvlak.

De pre-flight checklist

Wil je vóór de start snel zien of je goed zit? Check dit:

Top 3 use-cases zijn gekozen en uitgewerkt (probleem → oplossing → doelgroep).

Succescriteria/KPI’s zijn afgesproken.

Scope is gefaseerd (pilot → opschalen → migratie waves).

Product owner + besluitvorming is ingericht.

Governance MVP ligt vast (site-types, naamgeving, owners, rechten, lifecycle).

Basis informatiearchitectuur is bepaald (structuur + minimale metadata).

Migratie-aanpak + content owners per bron zijn vastgesteld.

Adoptieplan bestaat (communicatie, champions, training “in de flow”).

Pilotteam(s) en evaluatiemomenten zijn gepland.

Als je op meerdere punten “nee” moet aanvinken, is dat geen ramp—maar het is wél een signaal dat je project al risico loopt nog voor het begint.

quooker-succesverhaal-01

Praktijkvoorbeeld: Hoe Quooker wereldwijd verbonden raakte met één SharePoint-omgeving

Een herkenbaar patroon bij groei: landen/teams ontwikkelen eigen manieren van opslaan en samenwerken. In de Quooker-casus werd gekozen voor één centrale SharePoint-omgeving als digitale werkplek, met nadruk op vindbaarheid, samenwerking en adoptie, zodat medewerkers wereldwijd sneller bij de juiste informatie konden en versie-verwarring afnam.

De les hier is niet “iedereen moet hetzelfde werken”, maar: maak het makkelijk om het goede te doen (standaarden, duidelijke plekken, begeleiding).

Start met helderheid, niet met tooling

De ironie van SharePoint is dat het vaak mislukt door dingen die niets met SharePoint zelf te maken hebben. Niet omdat Microsoft het “niet kan”, maar omdat je zonder doelen, eigenaarschap, governance en adoptie een ecosysteem lanceert dat vanzelf ontspoort.

Wil je dat SharePoint wél landt? Maak de voorbereiding serieus. Kies use-cases, maak succes meetbaar, zet governance neer, ontwerp vindbaarheid, plan adoptie en migreer bewust. Dan wordt de kick-off geen startschot voor chaos, maar het begin van een omgeving die écht werkt.

SharePoint succesvol inrichten

Wil jij weten hoe je SharePoint succesvol inricht?

Download dan gratis ons eBook met meer informatie

Hulp nodig bij het inrichten van uw SharePoint omgeving?

Ivie-Hopstaken

Ivie denkt graag
met u mee.