Hoe je een bruikbaar, nuttig & zinvol intranet oplevert binnen 16 maanden [case]

Hoe je een bruikbaar, nuttig & zinvol intranet oplevert binnen 16 maanden [case]

De gemiddelde duur van een intranetproject is 25 maanden, volgens NN/g*. Toch vroeg een grote zorgorganisatie mij in februari 2023 om binnen een jaar het oude, op Drupal gebaseerde, intranet te vervangen door een nieuw, SharePoint-platform. In deze longread lees je het verhaal van hoe ik, samen met een fantastisch projectteam en dito leverancier, uiteindelijk binnen 16 maanden een nieuw platform heb opgeleverd.

Sta jij aan de vooravond van de implementatie van een nieuw intranet? Dan is deze blogpost voor jou. Ik neem je mee voor een kijkje achter de schermen van een intranetproject met een strakke deadline, hoge verwachtingen, en een flinke dosis realisme. Geen gladde succesverhalen, maar een eerlijk relaas over keuzes maken, samenwerken met beperkte middelen, en vooral: bouwen aan iets wat écht werkt voor medewerkers.

De scope van het project

Het intranetproject had een harde deadline, omdat de ondersteuning voor het Drupal 7-intranet aan het eind van dat jaar zou stoppen. De SharePoint-eis was ook niet onderhandelbaar, omdat de organisatie parallel aan het nieuwe intranet Microsoft 365 implementeerde.

De scope van dit project was een intranetoplossing voor:

  1. Corporate, top-down communicatie
  2. Formele content, naslagwerk of bibliotheek
  3. Informele samenwerking en communicatie

Buiten de scope vielen:

  • Documentmanagement: afgehandeld in SharePoint.
  • Formele(re) samenwerking: gebeurde al met Teams.
  • Interne digitale dienstverlening: verschillende applicaties waren al aanwezig.

Afdelingsoverstijgend projectteam

De projectgroep bestond uit collega’s uit de hele organisatie. De een had vooral ervaring met het beheren van het oude intranet, de ander met interne communicatie, en weer een ander met HR-onderwerpen. Wat we niet in het projectteam hadden, was IT-expertise, omdat de meeste interne mensen al in beslag waren genomen door het Microsoft 365-project.

Meerdere stakeholders

We wilden een bruikbaar en zinvol intranet bouwen voor de zorgmedewerkers, dus werkte het projectteam samen met een uitgebreide groep collega’s op alle professionele niveaus en afdelingen, om vanaf het begin de juiste keuzes te maken. Door meerdere belanghebbenden te betrekken, respecteerden we de tijd van mensen en verlichtten we de last van het projectteam.

Asynchrone samenwerking

Aangezien het aantal betrokkenen, de harde deadline en de beperkte beschikbaarheid van stakeholders, hebben we ervoor gekozen om af te zien van de traditionele tweewekelijkse projectvergaderingen en in plaats daarvan zoveel mogelijk asynchroon te werken.

Resultaat was dat het projectteam slechts één keer per twee weken online bijeenkwam voor een overleg van zo’n 50 minuten. Bijna alle andere communicatie, coördinatie en samenwerking gebeurde in de verschillende Teams-kanalen en -documenten.

Sterker nog, we hebben elkaar in de loop van het project maar één keer (!) fysiek ontmoet, namelijk bij de presentaties van de leveranciers. De enige andere keer dat we elkaar fysiek ontmoetten, was net nadat we live waren gegaan.

Visie en strategie bepalen

Een van de voorbereidende documenten die ik voorafgaand aan het project ontving, was een projectplan voor het vorige, op Drupal gebaseerde intranet. Gek genoeg had ik dat plan gemaakt in mijn beperktere betrokkenheid bij de voorbereidingen voor dat ‘oude’ intranet.

Het projectplan werkte nog steeds voor de klant, dus we konden erop voortbouwen voor de visie en strategie voor de nieuwe intranetoplossing. Wel hebben we de inhoud van de strategie met zowel de projectgroep als de stuurgroep herijkt, en de uitkomsten daarvan hebben als basis voor het project gediend.

Het doel voor het intranet was:

Het intranet ondersteunt het dagelijkse werk door mensen, informatie en applicaties op één plek samen te brengen. Het biedt toegang tot relevante en actuele informatie, nieuws en documenten en faciliteert de verwerving en levering van kennis. Het intranet draagt bij aan werkplezier en onderlinge verbinding en zorgt voor betrokkenheid van medewerkers bij elkaar en bij de organisatie. Voor veel collega’s is het intranet het startpunt van hun (digitale) werk, en een onlosmakelijk onderdeel van ieders werkdag.

Wensen en behoeften van medewerkers ontdekken

Voorafgaand aan mijn start hadden projectteamleden geprobeerd de behoeften van medewerkers in kaart te brengen in een enquête uit 2021. Hoewel de resultaten waardevol waren, had de enquête twee tekortkomingen: (1) ze werd uitgevoerd midden in de COVID-pandemie, en (2) de uitkomsten waren niet concreet genoeg om in ons project te gebruiken.

En dus stelden we meer dan 900 van de 16.000 collega’s één vraag: “Welke 5 dingen zijn voor jou het belangrijkst, om te kunnen vinden of doen op het intranet?” Deze zogenaamde taakidentificatie-enquête legde bloot wat medewerkers in het algemeen prioriteit gaven, per organisatieonderdeel, per functie/rol (bijv. verpleegkundige, ondersteunend personeel), per gebruikscontext en per apparaattype (laptop, tablet of smartphone).

Met de inzichten uit deze enquête konden we bepalen welke soorten content en functionaliteit voor medewerkers het belangrijkst waren. De bevindingen waren ook relevant voor de volgende stappen: design, content en technologie.

De top 10 taken in de enquête waren:

  1. Protocollen, procedures, stroomschema’s
  2. Scholing, opleiding, e-learning
  3. Kennis, nieuws, informatie delen
  4. Wie is wie, smoelenboek (collega vinden, afdeling, deskundigheid)
  5. Nieuws
  6. Mededelingen
  7. Mijn personeelsdossier
  8. Rooster, dienstrooster, werkrooster, dienst ruilen
  9. Ziektebeelden, problematiek (dementie, revalidatie, enzovoort)
  10. Elektronisch patiëntendossier

Deze 10 items kregen 39,7% van de stemmen, wat bijna identiek was aan de laagst scorende 71 items in de enquête.

De ontwerpfase: navigatie en functionaliteit

Bij de ontwerpstap waren twee dingen belangrijk:

  1. Functioneel/technisch ontwerp, oftewel: wat moet er in het nieuwe intranet zitten en kunnen; en
  2. Navigatieontwerp/menustructuur, met andere woorden: hoe navigeren medewerkers naar de gewenste informatie en functies?

Ik behandel ze in omgekeerde volgorde.

2. Navigatieontwerp

Met het projectteam en een kleine groep andere collega’s hebben we een concept navigatiestructuur gemaakt. We hebben het navigatieontwerp aan een zogenaamde tree test onderworpen, waarbij een diverse groep van bijna 500 medewerkers de boomstructuur heeft getest op basis van hun eigen hoogst scorende taken uit het eerdere onderzoek. Met deze test konden we aantonen dat de navigatiestructuur van het intranet zou werken, en waar dit niet het geval was, konden we aanpassingen doen op basis van testfeedback.

Het resultaat van een van de opdrachten van de tree test zag er als volgt uit:

Grafiek met resultaat van een van de opdrachten uit de tree test: 83% succesvol

1. Functioneel ontwerp

We hebben een lijst gemaakt van 31 zogenaamde epics, waarbij elke epic een functionele eenheid beschreef, bijvoorbeeld Nieuws, Profielen of Zoeken. Door dit op een gedetailleerde manier te doen, begreep het projectteam grondig wat het intranet moest bieden, en konden potentiële leveranciers een voorstel maken op basis van dezelfde uitgebreide informatie.

Een voorbeeld van de epic is deze, voor medewerkersprofielen:

  • Medewerkers kunnen de profielen van collega’s vinden, bekijken, volgen en contact opnemen.
  • Medewerkers kunnen hun eigen profiel bewerken.
  • Beheerders kunnen profielen van (andere) medewerkers bewerken.

Contentinventarisatie en -migratie

Zonder relevante, nuttige content geen succesvol intranet. We wilden de inhoud van het oude intranet niet overboord gooien, maar ook voorkomen dat we alles meenamen en zo een deel van de problemen van het oude intranet naar het nieuwe kopieerden.

We konden de hoeveelheid content op het oude intranet aanzienlijk verminderen op basis van twee richtlijnen:

  1. We zouden geen pagina’s migreren met een publicatiedatum vóór 1 januari 2022, tenzij daar een hele goede reden voor is (bijvoorbeeld omdat iets nog actueel is). Op basis van een steekproef schatten we dat we 33% van de contentpagina’s niet hoefden te migreren.
  2. We zouden geen pagina’s migreren die tussen januari en mei 2023 maximaal 10 keer zijn geraadpleegd, nogmaals, tenzij er een zeer goede reden was om dit te doen (bijvoorbeeld omdat iets wettelijk verplicht is). Uit dezelfde steekproef bleek dat dit zou betekenen dat we ongeveer 40% van de pagina’s niet hoefden te migreren.

Met deze richtlijnen instrueerden we communicatieprofessionals in de verschillende organisatieonderdelen en afdelingen: bepaal voor je eigen content of deze verwijderd kan worden, of gemigreerd kan worden naar het nieuwe platform. Hierdoor konden we ongeveer een derde van de pagina’s op het oude intranet verwijderen, en maar liefst twee derde van de documenten.

Toen we eenmaal wisten met welke intranetoplossing we aan de slag gingen (daarover zo meer), konden we de pagina’s en documenten op het oude intranet zodanig manipuleren – met name relevante labels toevoegen – om een gestructureerde export te maken, die vervolgens kon worden geïmporteerd door de gekozen leverancier.

De laatste stap – en dit is waar de communicatiecollega’s in mei 2024 enorm veel werk hebben verzet – was het corrigeren van alle links naar de oude intranetpagina’s en documenten in de gemigreerde content.

Technologiekeuze

Zoals ik al schreef, was het uitgangspunt van het project om een SharePoint-, Microsoft 365-gebaseerd intranet te maken. Parallel aan de stappen die ik hierboven beschreef, lag dan ook de vraag op tafel: hoe gaan we het nieuwe intranet technisch realiseren?

We zijn begonnen met het presenteren van onze epics (functionele eisen en wensen) aan de leverancier die betrokken was bij het Microsoft 365-project. Die vertelde ons dat onze eisen niet konden worden gerealiseerd in de standaard Microsoft 365-suite. Dat betekende dat we zouden moeten kijken naar aanvullende tools.

Extra tools vereist

Dat deze leverancier – een gerenommeerde partij op het gebied van Microsoft 365 – direct zijn toevlucht moest nemen tot alternatieve tools, kwam enigszins als een verrassing. Microsoft 365 mag dan een grote gereedschapskist zijn, het biedt niet zomaar een oplossing voor al je functionele eisen en wensen.

Tenminste, niet als we dat ‘intranet’ niet wilden opsplitsen in verschillende delen – denk aan SharePoint, Viva Engage, Teams, enzovoort – en we aan de zorgmedewerkers zouden moeten uitleggen dat hun vertrouwde intranet nu een set van losse tools was geworden. Dit laatste argument spoorde het projectteam aan om na te denken over alternatieven voor SharePoint en Microsoft 365.

De leverancier van de digitale werkomgeving had ons een kostenraming gegeven op basis van de epics. En mijn ervaring met soortgelijke processen bij andere organisaties gaf me de indruk dat we beter af zouden zijn, eerder klaar zouden zijn én geld zouden besparen met een alternatieve oplossing.

Verschillende aanbieders bevraagd

Daarom vroeg de projectgroep in de vroege zomer van 2023 aan verschillende intranetleveranciers om, wederom op basis van onze epics, te antwoorden of zij aan deze eisen konden voldoen, en zo ja, op welke manier, en tegen welke kosten per jaar. Hoewel dit geen goede marktverkenning of productvergelijking was, konden we het op basis van de resultaten beperken tot een van de twee scenario’s:

  1. SharePoint plus een extra tool, te leveren door de eerder genoemde leverancier, of
  2. Een standaard, onafhankelijke oplossing van een van de Nederlandse marktpartijen.

De voorkeur van het projectteam

Gezien de functionele (on)mogelijkheden van deze verschillende oplossingen en leveranciers en de kostenramingen heeft de projectgroep unaniem gekozen voor het tweede scenario. De groep heeft dit advies voorgelegd aan de stuurgroep.

De stuurgroep was echter verdeeld: drie mensen waren voorstander van ons advies en één persoon koos voor het eerste scenario. Hun argumenten waren overigens volkomen begrijpelijk en terugkijkend had ik als projectleider de verschillende belanghebbenden eerder bij ons dilemma moeten betrekken.

Onze volgende stap was om met de kwestie naar de Raad van Bestuur te gaan. Daar waren twee van de drie leden voorstander van het tweede scenario, en dat gold ook voor de twee leden van de digitaliseringscommissie van de Raad van Commissarissen (ja, zo kom je nog eens ergens…). De RvB heeft het projectteam en de stuurgroep daarom gevraagd om een tweede verkenningsronde uit te voeren tussen vergelijkbare (zorg)organisaties.

Vergelijkbare organisatie koos onafhankelijke SaaS

Uit deze tweede verkenningsronde bleek dat de enige zorgorganisatie die vergelijkbaar was met mijn opdrachtgever ook voor het tweede scenario had gekozen. Ze merkten echter wel op dat ze, net als mijn klant, verwachtten dat de Microsoft 365-suite uiteindelijk veel, zo niet alle, functies van een intranet op een gebruiksvriendelijke en beheersbare manier zou leveren.

Uiteindelijk uitfaseren ten gunste van Microsoft 365

De uitkomst was voor alle betrokkenen acceptabel: we zouden kiezen voor het tweede scenario, maar zouden ook expliciet zoeken naar manieren om met de nieuw uitgerolde Microsoft 365-suite in de loop van drie tot vijf jaar meer en meer intranetfunctionaliteit te ondervangen.

Dit impliceerde dat het nieuwe intranet op termijn volledig zou worden uitgefaseerd en vervangen door Microsoft 365-applicaties. Eerlijk gezegd blijf ik twijfelen of dit inderdaad gaat lukken, maar de tijd zal het leren.

Drupal 7-ondersteuning uitgebreid

De technologische impasse leidde ertoe dat ons project ongeveer drie maanden vertraging opliep. Gelukkig besloot de Drupal-ontwikkelaarsgemeenschap om de ondersteuning voor Drupal 7 met ongeveer een jaar te verlengen, wat ons de nodige ademruimte gaf om de vertraging op te vangen.

Onze Drupal-leverancier stelde echter één voorwaarde: ze wilden zich voor maar drie maanden ondersteuning committeren, en op basis van best effort. Met andere woorden: er was meer tijd maar slechts beperkt, en ook met risico’s voor het huidige (nu oude) intranet.

Inkoop van intranettechnologie

Voor de volgende fase in ons project kwam een inkoopspecialist aan boord en haar kennis en ervaring van het aanbestedingsproces was een geweldige hulp voor het projectteam. Samen werkten we een RFP (Request for Proposal) uit op basis van de visie en strategie, de wensen en behoeften van medewerkers, onze lijst met epics, en het navigatieontwerp.

Dit betekende dat we het oorspronkelijke tijdschema voor het aanbestedingsproces konden versnellen – eind mei 2024 een leverancier gekozen – om de leverancier eind december 2023 te hebben gekozen. Wat het proces ook versnelde, was het feit dat de Raad van Bestuur de stuurgroep enige financiële ruimte had gegeven om tijdens de formele afronding van de contracten te beginnen met de implementatie en configuratie.

Voor de inkoop hebben we gekozen voor een meervoudige onderhandse aanbesteding met drie leveranciers. Laten we ze A, B en C noemen. De uitkomst van dit proces was als volgt:

  • B bood de hoogste kwaliteit op basis van onze epics (6% beter dan C en veel beter dan A).
  • B had de laagste prijs (bijna 25% lager dan C, maar vergelijkbaar met A).
  • Qua weging van kwaliteit (70) en prijs (30) was B de winnaar (van C met 11% verschil, en ook een betere score dan A).

Het projectteam, de inkoopadviseur en een klein aantal andere collega’s waren het erover eens dat leverancier B als winnaar uit de bus kwam. De stuurgroep heeft het vervolgens bevestigd en dit advies hebben we vervolgens voorgelegd aan het bestuur, dat het op 3 januari 2024 heeft goedgekeurd.

Hoewel dit allemaal natuurlijk al voorbij de oorspronkelijke deadline was, hadden we de drie extra maanden technische ondersteuning voor Drupal om aan de volgende stap te werken: de implementatie van het nieuwe intranet.

Intranet-implementatie

Voor de implementatiefase besloot de projectgroep te vertrouwen op de kennis, ervaring en planning van de gekozen leverancier. Mijn rol als projectmanager veranderde op dit punt van de drijvende kracht van het project naar die van de klantcontactpersoon voor de leverancier.

Het belang van een technische projectleider

Het projectteam was erg blij met de professionaliteit en kennis van de technische projectleider van de leverancier. Natuurlijk ging het wel eens mis in het proces en de uitvoering, maar dankzij inhoudelijk meedenken en meewerken van de projectleider – en het feit dat hij soms gewoon ‘nee’ zei als iets niet kon 😄 – vonden we bijna altijd een prettige en bruikbare oplossing.

Vertragingen voornamelijk door content

We ondervonden wel vertragingen omdat uit de contentmigratie bleek dat er extra werk nodig was. Vooral rond de links en documenten in de gemigreerde content (zoals je hierboven al las). Ze verwezen allemaal naar het oude intranet, en dat konden we alleen handmatig oplossen. Bovendien moesten we dit werk in handen geven van de verschillende communicatieprofessionals van de merken in de gezondheidszorg, vanwege hun diepgaande expertise in hun inhoud.

Op een gegeven moment hebben we er bewust voor gekozen om het project uit te stellen om de druk op deze communicatieprofessionals te verlichten. Dit gaf de contentmigratie en -optimalisatie wat ademruimte, en bood iets meer ruimte voor de technische opzet en implementatie. Uiteindelijk, na een traject van ongeveer 15 maanden, is het intranet op 3 juni 2024 live gegaan.

Na live

Dus dat was dat… nou ja, in ieder geval voor mij. Het zeer ervaren en uiterst professionele team waarmee ik werkte, zou alle verdere problemen, verbeteringen, adoptie en dagelijkse intranet- en communitymanagementtaken afhandelen.

Het oude intranet zou in de zomer van 2024 online blijven om eventuele gemiste ‘oude’ links op het nieuwe platform te kunnen opvangen. Het ging op 1 september offline na meer dan acht jaar dienst.

Deliverables

Dit is wat het projectteam en ik in de loop van die vijftien maanden hebben opgeleverd:

  • Een visie- en strategiedocument voor het nieuwe intranet.
  • Een taakidentificatie van de behoeften en wensen van medewerkers.
  • Een door user-generated en gevalideerd navigatieontwerp.
  • Een lijst met epics/functionele eisen en wensen.
  • Het inkoopproces, de selectie van product/leverancier en contract.
  • Een nieuw intranet op basis van het geselecteerde product.
  • Contentmigratie en -optimalisatie.
  • Een adoptie- en communicatiecampagne rondom go-live.
  • Governance en managementstructuur.

Hoe zit het met toekomstige ontwikkelingen?

Na de go-live is er nog ruimte om te groeien. We hadden (nog) niet alle beschikbare modules van het geselecteerde product gekocht. En het nieuwe intranet was nog slechts beperkt gekoppeld aan de digitale werkplek van de organisatie.

Verder zijn er naast het intranet aanvullende communicatiemiddelen en samenwerktools in gebruik die het intranet in de toekomst mogelijk kan overnemen, bijvoorbeeld:

  • Het delen van nieuws via nieuws en/of groepen op intranet in plaats van via e-mailnieuwsbrieven.
  • Segmentatie/personalisatie van inhoud en functies op basis van eigenschappen en gedrag van medewerkers op het platform.
  • Zogenaamde pre-boarding van nieuwe medewerkers nadat ze formeel zijn aangenomen, maar vóór hun eerste werkdag.
  • Integratie met applicaties zoals werkplekbeheer, personeelsdossier en meer op basis van microservices.

Het doel van het project

Uiteindelijk ging het bij het project om veel meer dan alleen het vervangen van een oud intranetplatform. Het ging om iets bruikbaars, nuttigs en zinvols voor de medewerkers die het elke dag (moeten) gebruiken.

Het nieuwe intranet weerspiegelt een gedeelde visie, gevormd door echte, concrete behoeften, doordachte keuzes en een gezamenlijke inspanning van de projectgroep en het leveranciersteam. Onze gezamenlijke reis legde de basis voor een platform dat in de loop van de tijd kan evolueren en groeien naarmate de organisatie verder ontwikkelt.

Want een echt effectief intranet is geen bestemming, het is een doorlopend commitment om mensen te ondersteunen in hun dagelijkse werk.

* Bron inleiding: NNGroup

Blog