Voorkom uitzichtloze software projecten: het einde hoeft niet in zicht te zijn.

Het zal niet de eerste keer zijn dat er opnieuw in het nieuws een bericht voorbij komt dat beschrijft hoe een software project opnieuw gigantisch uitgelopen is. Het systeem is nog niet eens af maar de kosten zijn niet meer te overzien. Een eindtijd van het project kan niet geschat worden. Zelfs in organisaties waarvan niemand het had verwacht, blijkt het succesvol afronden van een software project bijzonder lastig. Een goed begin is het halve werk geldt hier niet. De instelling: “Zolang wij blijven geloven in de meerwaarde van het systeem, komt het goed” zorgt niet voor een succesvolle implementatie. Wat dan wel? Hoe kan je er voor zorgen dat de sceptici (“Achja.. het zal ze toch wel niet lukken”) het niet winnen? Het antwoord is simpel — en je kent het al.

Elke studie of opleiding heeft het wel eens aangestipt: als iets te moeilijk is om in één keer op te lossen, hak het dan in stukken. Zoals elk complex vraagstuk moeten ook software projecten opgedeeld worden in duidelijk gedefinieerde deelvraagstukken. Op een complex vraagstuk is niet gelijk een antwoord te geven. Een groot softwarepakket is niet in één maand te implementeren binnen uw organisatie. Accepteer dat de uiteindelijke finish nog niet in zicht is. Dit is niet erg. Besef dat je de eindstreep niet in zicht hoeft te hebben om te weten dat er verandering nodig is.

Hoewel dit raar voelt is het wel de enige manier waarop je een uitzichtloos doel kunt halen. Denk zo: aan het begin van de marathon is het onmogelijk te weten waar het einde is — maar daar komen, zal, en gaat, je lukken.

Om toch verder te komen moeten binnen het project kleinere problemen worden gedefinieerd. Van deze kleinere deelproblemen is het essentieel dat elke eindstreep wel behapbaar is. Door telkens naar een deeloplossing te streven komt het project steeds verder en kom je dus steeds dichterbij de (eerst onzichtbare) finish.

Ook wij hebben last gehad van project die uitlopen. Nu gelukkig niet meer! De bovenstaande denkwijze heeft ons hierbij geholpen. We delen graag onze implementatie hiervan.

Structuur. Van groot -> klein.

Hoe verdeel je het maken van een groot software systeem dan in overzichtelijkere kleinere problemen?

1. De scope (maanden tot jaren)

Een team werkt goed wanneer elk lid eenzelfde doel voor ogen heeft. In dezelfde gedachtegang: een samenwerking werkt goed wanneer beide partijen naar hetzelfde einddoel streven. Vóórdat een samenwerking vorm krijgt is het dus erg belangrijk dat hier over gesproken wordt. Bij aanvang is het niet belangrijk om te bespreken welke werkzaamheden precies uitvoerig moeten gebeuren; het is veel belangrijker dat beide partijen straks aan hetzelfde probleem gaan werken. Eerst moet de scope (omvang) van het project duidelijk worden.

2. Fases (weken tot maanden)

Pas als de scope van het project duidelijk is (en dit kan soms langer duren dan dat je verwacht), is het tijd om hét grote abstracte probleem te compartimentaliseren. Met de scope van het project in je achterhoofd kan het al best snel duidelijk worden wat de eerste stappen zijn. Deze eerste stappen vertalen zich naar fase 1. Het hoeft op dat moment nog helemaal niet duidelijk te zijn wat er in fase 2 aan bod gaat komen — dat wordt pas tijdens de eerste fase duidelijk. De oplevering van één fase: een release versie van het systeem.

Plan van aanpak. Stappen.

Nu de structuur van het project duidelijk is, is het natuurlijk wel belangrijk om in grote lijnen te weten hoe het project vorm zal krijgen. Wat wordt er in de fases en in de sprints precies uitgewerkt? Een fase ziet er als volgt uit.

1. Vooronderzoek (enkel bij eerste fase)

Een vooronderzoek lijkt in eerste instantie op overhead maar is essentieel voor het succesvol voltooien van een groot project. Vóórdat je aan iets begint moet je er goed over nadenken. Bij kleinere projecten is het probleem vaak triviaal maar voor grote projecten is dit meestal niet duidelijk. In een vooronderzoek brengen wij in kaart wat de huidige status is van het probleem en waar er dus kansen liggen. Oplevering van het vooronderzoek: een rapport waar de kansen in beschreven staan.

2. Projectvoorstel

Aan de hand van een vooronderzoek maken wij een projectvoorstel. In dit voorstel doen wij een voorstel van het te bouwen (deel)systeem. Door duidelijk af te stemmen wat er in het projectvoorstel komt te staan voorkomen we onverwachte kosten en uitloop van het project. Belangrijk is om ambitieus te zijn maar realistisch te blijven. Oplevering van deze stap: een offerte inclusief bouwplan. (Voor de beeldvorming: één offerte beschrijft dus de exacte werkzaamheden van één fase.)

3. Ontwikkeling

De derde stap van de rode draad door het project is het de eigenlijke ontwikkeling van het systeem. In deze fase werken wij het bouwplan van de offerte uit. Dit doen we met sprints (zoals hierboven beschreven). Door duidelijk af te kaderen welke functionaliteiten in welke sprints ontwikkeld worden (en dit altijd met de klant te communiceren) blijven alle partijen op de hoogte van ontwikkelingen, nieuwe wensen en ervaringen van het systeem. De oplevering van de laatste sprint is in principe de oplevering van één fase (een release versie van het systeem).

4. Uitrol

Eén stap in het projectproces verdient het niet onderschat te worden. Helaas zien we toch dat dit vaak wel gebeurt. De uitrol van een systeem is erg belangrijk. De ontwikkeling van een systeem is één. Het tweede, de acceptatie vergroten van het systeem in een organisatie, is minstens zo belangrijk. Het zou zonde zijn als niemand het nieuwe systeem gaat gebruiken. Oplevering van de vierde stap: het geven van lessen/workshops en het schrijven van handleidingen.

5. Support (enkel bij laatste fase)

De laatste stap in in de samenwerking (die verreweg het langst duurt): de support. Als het systeem in gebruik genomen is en alles fijn werkt blijven er natuurlijk kleinigheden in het gebruik naar voren komen. Frustraties afvangen, fouten oplossen en updates aan het systeem horen bij het functioneren van een groot systeem. Continue support hoort hier natuurlijk bij.