Ok, je gaat aan de slag met de bouw van een nieuw intranet. Je hebt zorgvuldig de organisatiedoelen in kaart gebracht. Onderzocht hoe je collega’s zo goed mogelijk kunt ondersteunen in hun dagelijks werk. Bekeken welke systemen ontsloten of gekoppeld moeten worden en op welke manier. Daarnaast heb je je verdiept in de inhoud en structuur van de content. Met deze kennis ga je de bouwfase in. Er kan dus weinig meer misgaan. Toch?
De praktijk is weerbarstig
Helaas is de praktijk weerbarstig. Vaak wordt er vol goede moed gestart, maar ergens rond de tijd dat de eerste deadline begint te naderen of de eerste testronde is geweest slaat de stemming om. Op miraculeuze wijze veranderen projecten van passievolle, ambitieuze en innovatieve plannen in een hoop getouwtrek, oeverloze testrondes, uitstel op uitstel, onvruchtbaar gewellesnietes en weglekkend enthousiasme.
Dit artikel is niet de garantie dat het deze keer anders zal gaan. Wel is goed om te kijken waarom het nou zo vaak mis gaat.
Valkuil #1: teveel in één keer
Allereerst zien we dat er bijna altijd teveel in één keer moet. Of dit nou komt vanuit enthousiasme. Of het idee dat er direct een wow-effect moet zijn bij lancering (en dat hiervoor heel veel nieuwe functionaliteit nodig is). Of omdat simpelweg alles binnen een project moet worden afgerond. Eigenlijk wordt in een eerste oplevering bijna altijd teveel functionaliteit gepropt. Dit betekent meer complexiteit, meer (technische) afhankelijkheden en meer testwerk.
Valkuil #2: denken vanuit het best denkbare scenario
Ten tweede wordt er vaak gedacht vanuit het best denkbare scenario en niet vanuit het meest haalbare scenario. 80% van de energie gaat vaak in de laatste 20% van de ontwikkeling zitten. Er zou niet alleen sprake moeten zijn van een succes wanneer in de eerste versie voor elk onderdeel het best denkbare resultaat is behaald. Reid Hoffman, de oprichter van LinkedIn zegt zelfs: “If you are not embarrassed by the first version of your product, you’ve launched too late”.
Valkuil #3: nog te veel onzekerheden en onduidelijkheden tijdens de bouw
Tenslotte – ook al zijn er vast nog legio andere redenen die ik hiermee onbenoemd laat – zijn er vaak tijdens de bouwfase nog onvoorziene onzekerheden of onduidelijkheden die gedurende de ontwikkelfase nog moeten worden uitgezocht. Vaak zijn deze technisch van aard. Houd hier rekening mee in de planning en ureninschatting. Een valkuil is namelijk dat er in het geval van een technische onzekerheid verzand wordt in een discussie over de oplossingsrichting.
Think Big, act small – de bouw van een nieuw intranet
Hoe dan wel? Wij geloven in het principe: Think Big, Act Small. Oftewel: zorg voor een groot(s), helder vergezicht – een stip aan de horizon – en durf hier vervolgens in zo klein mogelijke stapjes naar toe te werken. Zodat je nieuw verworven inzichten mee kunt nemen in het proces en weloverwogen stappen zet.
De stip aan de horizon is er, want die heb je in de eerste fase van het project vastgesteld en aangescherpt. De kunst is nu nog om tot kleine stappen te komen zoals bij Agile-projectmethodieken, als SCRUM. Meer over de implementatie van een succesvol social intranet vind je in het boek ‘In 7 stappen naar een succesvol social intranet’.
Hoe bepaal je die kleine stappen?
Het is echter best lastig om tot echt kleine stappen te komen. Vaak voelen ze voor een projectgroep, die bezig is met het nieuwe social intranet als te klein. Dat is ook logisch. De projectgroep heeft zich verdiept in de materie, heeft allerlei oplossingen gezien en kent bovenal de stip aan de horizon. Dan kan een kleine eerste stap al snel voelen als futiel of zelfs als een tegenvaller. Vergeet hierbij dan niet dat voor de rest van de organisatie alles wat er wel wordt ‘geleverd’ grotendeels nieuw is. Lees hoe De Friesland Zorgverzekeraar de bouw van het nieuwe intranet hebben gefaseerd.
Projectvoorbeeld
Een voorbeeld: Stel je wilt een nieuw social intranet ontwikkelen gebaseerd op een combinatie van Office365, aanvullende social business software (zoals Embrace) en een reeks koppelingen met allerlei applicaties die gebruikt worden binnen de organisatie. Verder wil je een deel van de oude content migreren en een producten- en dienstencatalogus met allerlei slimme formulieren toevoegen.
Te kleine stap voor projectgroep is vaak een grote stap voor eindgebruikers
Het lanceren van alleen de social business software met minimale styling voelt waarschijnlijk als een te kleine stap. Want hoe zit het dan met alle managed content, de geweldige ontwerpen die zijn gemaakt, het samenwerken binnen documenten en de KPI’s op het dashboard?
Toch is voor de rest van de organisatie de stap van een traditioneel intranet naar een interactief platform waarop gebruikers berichten kunnen plaatsen, profielen kunnen raadplegen en eenvoudige blogs kunnen schrijven waarschijnlijk al een grote stap.
Vanuit dat perspectief is het juist wel prettig dat deze eerste stap klein en overzichtelijk is. Zo kun je extra aandacht besteden aan gebruikersondersteuning tijdens de eerste weken na lancering of kun je werken aan die introductievideo die gebruikers uitlegt waarom het nieuwe intranet er is, welke bijdrage van hen verwacht wordt en dat dit nog maar een eerste versie is.
Terwijl een deel van de projectgroep na lancering bezig is met nazorg en begeleiding van gebruikers, kun je ondertussen verder werken aan een eerste update die twee weken later wordt gelanceerd. In deze update kan bijvoorbeeld de allerbelangrijkste managed content worden toegevoegd aan het intranet en kan de styling nog wat verder worden aangescherpt.
Wil je weten hoe andere organisaties hun social intranet succesvol hebben ingezet? Lees het gratis ebook: ‘In 7 stappen naar een succesvol social intranet‘.
De voordelen van het opdelen van je project in kleine stappen
Kleine, behapbare stappen zoals deze hebben een aantal grote voordelen:
- Je krijg snel en vaak feedback van eindgebruikers;
- Het risico dat het volledige project stilvalt, doordat ergens een hele ingewikkelde koppeling nog niet werkt, is veel kleiner;
- Je hebt na elke stap de mogelijkheid om te beslissen om door te gaan met een volgende stap of juist een pas op de plaats te maken. Dit laatste kan soms nuttig zijn, omdat je meer tijd wilt besteden aan het begeleiden van gebruikers of om een functionaliteit uit een vorige ‘release’ uit te breiden;
- Er kan gerichter worden getest. Dit verkleint het risico op frustraties die ontstaan door het bijhouden en wegwerken van lange lijsten met fouten en onvolkomenheden;
- Na een klein succesvol project heb je als team zin in de volgende stap. Na een groot en langdradig project ben je er eigenlijk wel even klaar mee. Dat laatste is dodelijk, omdat bij een social intranet het ‘echte werk’ pas begint na de eerste lancering (zie hoofdstuk 6 en 7);
- Kleine projecten zijn leuker dan grote projecten. Met een leuk team in een korte tijd een inspanning leveren met daarna snel resultaat is nou eenmaal leuker dan maandenlang met dezelfde mensen in dezelfde overleggen te praten over dezelfde problemen.
Hoe kom je tot kleine stapjes?
In kleine stappen naar die stip op de horizon dus. Maar hoe splits je een groot project op in kleine stappen? Je zou hiervoor de geadviseerde sprintlengte uit de ontwikkelmethode SCRUM kunnen aanhouden: één stap kost het ontwikkelteam dan niet meer dan twee weken.
Op basis van dit verdelingsprincipe kom je dan op een lijst die er ongeveer zo uitziet:
Lijst met dingen die we moeten doen (1 – 2 wk/item)
- Inrichten Social Business Software en basisstyling
- Ontwikkelen verschillende sjablonen
- Realiseren koppeling met TopDesk
- Overzetten documenten van X-schijf naar intranet
- Migreren deel van de content van het oude intranet
- Koppelen met Active Directory en automatisch vullen profielen
- Maken introductievideo en zorgen voor opstart-wizard voor nieuwe gebruikers
Wat doe je als eerste?
Wat ga je dan eerst doen en wat later? Denk terug aan het principe ‘Think Big, Act Small’. Je hebt al bepaald wat belangrijk is voor de organisatie en welke functionaliteit de medewerkers het meeste helpt in hun dagelijks werk. Houd dit aan als leidraad bij het prioriteren van acties.
Een handig hulpmiddel
Hiervoor kun je het schema hieronder gebruiken:
Bepaal voor elk onderdeel wat de impact is (de mate waarin het onderdeel bijdraagt je een stap dichter bij de stip aan de horizon brengt) en het risico (de complexiteit van het onderdeel).
In twee ‘sprints’ tot een eerste lancering
Als je alle onderdelen hebt ingevuld, kun je de volgorde bepalen en aan de slag gaan. Idealiter zouden twee sprints voldoende moeten zijn om tot een eerste lancering te komen. Dus even doorpakken en over 30 dagen ben je live!
Dit artikel werd voor het eerst geplaatst op 16-06-2014.
