• Home
• Nieuws

Think big, act small: hoe je de bouw van een nieuw platform kunt faseren

Geplaatst door CorporatieMedia op Monday 7 July 2014

Ok, je gaat aan de slag met de bouw van een nieuwe webapplicatie, website, klantportaal of intranet. Je hebt zorgvuldig de organisatiedoelen in kaart gebracht. Onderzocht hoe je klanten en collega's zo goed mogelijk van dienst kunt zijn. Bekeken welke systemen ontsloten of gekoppeld moeten worden en hoe. Er kan dus weinig meer misgaan. Toch?

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 eìeì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 zien we dat er vaak alleen gedacht wordt vanuit het best denkbare scenario en niet vanuit het meest haalbare. Er zou niet alleen sprake moeten zijn van een succes, wanneer in de eerste versie voor elk onderdeel het best denkbare resultaat is behaald. Juist omdat 80% van de energie vaak in de laatste 20% van de ontwikkeling gaat zitten. Reid Hoffman, de oprichter van LinkedIn zegt het nog wat sterker: “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 te veel (vaak technische) onzekerheden of onduidelijkheden die dan, terwijl er al wordt ontwikkeld, nog moeten worden uitgezocht. Nog even los van het feit dat elke planning en ureninschatting hierdoor per definitie onbetrouwbaar is, is het grootste risico dat ook al wordt er een oplossing gevonden er binnen het project discussie ontstaat over deze oplossingsrichting.

Think Big, act small
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 - maar durf hier vervolgens in zo klein mogelijke stapjes naar toe te werken.

De stip aan de horizon is er, want die heb je in het begin van het traject al vastgesteld en aangescherpt. De kunst is nu nog om tot kleine stappen te komen. Nu doen deze kleine stappen je waarschijnlijk al denken aan Agile projectmethodieken, zoals Scrum. Op zich klopt dit ook en Scrum zou hiervoor ook deels wel kunnen werken, maar de gekozen methodiek is niet de kern van dit verhaal.

Hoe bepaal je die kleine stappen?
De kern van dit verhaal is weìl dat het best lastig is om tot echt kleine stappen te komen. Vaak voelen kleine stappen voor een projectgroep 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.

Projectvoorbeeld: een nieuw (social) intranet
Een voorbeeld: “Stel, je wilt een nieuw social intranet ontwikkelen op basis van een combinatie van SharePoint, aanvullende social business software en een reeks aan koppelingen met allerlei applicaties die gebruikt worden binnen de organisatie. Verder wil je de oude content migreren en een producten- en dienstencatalogus met allerlei slimme formulieren toevoegen.”

Dan voelt het lanceren van alleen de social business software met minimale styling 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 ‘giant leap’.

Vanuit dat perspectief is het juist wel prettig dat deze eerste stap klein en overzichtelijk is. Zo kun je extra aandacht besteden aan gebruikersondersteuning in de eerste weken na lancering of kun je werken aan die geweldige 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 het projectteam na lancering bezig is met nazorg en begeleiding van gebruikers, kun je ondertussen alweer 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 ‘gepimpt’.

De voordelen van het opdelen van je project in kleine stappen
Kleine, behapbare stappen hebben een aantal enorme voordelen:

1. Je krijg snel en vaak feedback van eindgebruikers;
2. Het risico dat het volledige project stilvalt, doordat ergens een hele ingewikkelde koppeling nog niet werkt is veel kleiner;
3. 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 investeren in het begeleiden van gebruikers of in het vervolmaken van functionaliteit uit een vorige ‘release’;
4. Er hoeft veel minder getest te worden. Dit verkleint het risico op frustraties die ontstaan door het bijhouden en wegwerken van lange lijsten met fouten en onvolkomenheden;
5. 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;
6. 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 nou op in kleine stappen? Dat blijft natuurlijk een beetje arbitrair, maar je zou de geadviseerde sprintlengte uit Scrum kunnen aanhouden. Eén stap mag het ontwikkelteam dan niet meer tijd kosten dan twee weken (of minder, zeker niet meer!).

Wat doe je als eerste?
Maar wat ga je dan eerst doen en wat later? Hiervoor moet je even terug naar ‘Think Big’. Je hebt namelijk al bepaald wat belangrijk is voor de organisatie en welke functionaliteit de medewerkers het meeste helpt in hun dagelijks werk. Wanneer je gaat prioriteren zou dit dus je leidraad moeten zijn.

Een handig hulpmiddel
Je kunt hiervoor dit schema 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!

Auteur: Martijn Weesjes van Umbrella