Een goed projectbegin is het halve werk!

Ict-projecten beheersbaar houden

Je hoort het vaak over ict-projecten; ze gaan ruim over budget, leveren niet de juiste kwaliteit en halen de deadlines niet. Er zijn voorbeelden genoeg van projecten die miljoenen of zelfs miljarden over het budget zijn gegaan. Agile wordt aangedragen als de oplossing om een project beheersbaar te houden, omdat het taken in kleine stukjes opknipt en zo zorgt voor overzicht. Dit helpt enorm om het project flexibel te laten meebewegen met de wensen. Maar, hier zit ook een keerzijde aan: Agile schiet soms door en dan denkt men geen voorbereiding nodig te hebben omdat alles later wel duidelijk wordt. In dat geval wordt Agile gebruikt als excuus om weinig voor te bereiden en slecht te documenteren. Oké, maar dan kan je toch besluiten alles van tevoren goed voor te bereiden? Ja dat kan, maar het probleem is dat je van tevoren nooit weet wat je tijdens het bouwen tegenkomt.

Hoe weet je nu welke voorbereiding het beste werkt en belangrijker nog; welke voorbereiding past het beste bij jouw project? Zonder een goede voorbereiding beginnen met een ict-project is als het bouwen van een huis, maar zonder dat je weet wat onder de grond zit (techniek), geen idee wie erin gaan wonen en wat hun wensen zijn (gebruikers & processen) en geen idee hoe het huis eruit moet komen zien (interface). Het maakt nogal uit of je op kleigrond een vakantiehuis bouwt of een woonboot op de gracht moet opleveren. Bij OGD merken we dat de juiste voorbereiding veel problemen vroegtijdig kan oplossen en verspilling kan voorkomen. In deze blog zetten we drie verschillende soorten voorbereidingen op een rijtje, want een goed projectbegin is het halve werk!

Een goede voorbereiding, hoe doe je dat?

Hoe kun je nu een ict-project in de hand houden én zeker weten dat je de juiste oplossing aan het bouwen bent? Het klinkt logisch, maar dat doe je door het project van tevoren goed te omschrijven. Het is zaak om samen met de toekomstige gebruikers de wensen zo duidelijk mogelijk te krijgen. Dit kan binnen enkele dagen gedaan worden. Maar hoe zorg je nu dat je de wensen goed afstemt en duidelijk krijgt? Bij OGD gebruiken we daar drie verschillende manieren voor: Backlogsessies, Pretotypen en Design Sprints.

1.   Backlogsessies – Alle wensen op een rij binnen enkele uren

Backlogsessies richten zich met name op het ophalen van informatie van de klant. We vragen naar de wensen en schrijven deze samen uit tot een overzicht aan Users Stories en globale prioriteiten. Deze lijst heet een backlog en geeft een eerste indruk van wat er gebouwd moet worden. Vergelijk het met een lijst met wensen van iemand die een huis wilt bouwen. Het geeft inzicht, maar de nuances en schetsen ontbreken.

Backlogsessies richten zich op:

• Wat zijn de wensen van de klant?
• Wie gaat het gebruiken?

Een backlogsessie is snel en eenvoudig te realiseren en de investering is daardoor ook vrij klein. Er is weinig tijd of ruimte om diep in te gaan op de werkwijzen en processen, maar het eind van een backlogsessie staan de belangrijkste afspraken en wensen alvast op papier voor verder uitwerking.

2.   Pretotypen – In 1 tot 2 dagdelen de belangrijkste processen en een eenvoudige interface in kaart

Bij OGD spreken we tijdens een Pretotype-sessie het volgende met de klant door:

• Wat zijn de wensen van de klant?
• Wie gaat het gebruiken?
• Wat zijn hun werkwijzen?
• Welke processen moet de oplossing ondersteunen?

Bij een Pretotype-sessie gaan we dieper in op het proces en schetsen samen met de klant de oplossing. De klant is hierbij vaak de opdrachtgever en soms ook de eindgebruiker. Vergelijk het met een ruwe schets van het huis en een omschrijving van het dagelijkse leven van bewoners. Op deze manier krijg je al een beter beeld, maar dit is wel alleen vanuit het perspectief van één bewoner. Wat er uit Pretotyping komt is afhankelijk van de complexiteit van het project en de tijd die er is voor Pretotypen. In het algemeen levert het dit op:

1. Een backlog met daarin de belangrijkste wensen ingedeeld in korte en lange termijn;
2. schema’s van de belangrijkste processen waarop de software gericht moet zijn;
3. eenvoudige visuele schetsen (om intern te communiceren/testen.

Aan het eind van een Pretotype-sessie heb je beter inzich in de complexiteit, stakeholders en risico's van het project. De investering is nog beperkt bij Pretotypen en het geeft meer inzicht dan een Backlogsessie. Dit is dus interessant voor grotere projecten. Hoewel het al redelijk goed inzicht geeft in de vraag, heb je nog geen concrete feedback van gebruikers waarmee je aannames kunt toetsen. Daarvoor zijn Design Sprints een ideale methode. Deze sessies halen diepgaande feedback op bij een grotere groep stakeholders, zodat je al een goed beeld hebt of het project van de grond gaat komen.

3.   Design Sprint – Intensief in een week analyseren, prototypen, bouwen én testen

Een design sprint bevat veel elementen uit de pretotyping-sessie, maar dan uitgebreider én gavalideerd met gebruikers. We bouwen samen met de klant in een week een overtuigend visueel prototype dat we voorleggen aan echte gebruikers in een realistische test. Dit geeft concrete feedback en maakt potentiële pijnpunten vroegtijdig inzichtelijk. Je kan dit vergelijken met het bouwen van een digitale versie van een huis waar een gebruiker doorheen kan lopen. Een week design sprint is intensief, maar zeer waardevol. Zo’n sprint ziet er ongeveer zo uit:

• Maandag – Omschrijven van kernprobleem, wensen en kernproces.
• Dinsdag – Uitschetsen belangrijkste functionaliteit van de applicatie.
• Woensdag - Omschrijven storyboard.
• Donderdag – Bouwen van een prototype (in bv Powerpoint/Keynote).
• Vrijdag – Voorleggen prototype aan mogelijke klanten en feedback vragen.

Aan het eind van een Design Sprint heb je vaak een goede basis voor het gehele project die bovendien is getest gebruikers. Hiermee voorkom je dat je het verkeerde bouwt en dit scheelt vaak veel moeilijkheden later in het ontwikkelproces en bij de implementatie.

Maar is dat wel Agile?

Een veelgehoorde opmerking is dat deze voorbereidingen wel heel 'waterval' zijn en niet agile. Bij een watervalproject probeer je alles van tevoren duidelijk te hebben, dit kost veel tijd voor iets dat geen 100% zekerheid geeft. Bij Agile daarentegen leer je tijdens het project steeds meer en komen antwoorden gaandeweg. Agile betekent alleen niet dat je niet goed moet nadenken over het project voordat je begint. Je moet dus niet te Agile worden en geen voorbereidingen treffen, want dat frustreert veel projecten vanwege het gebrek aan basis. De uitdaging is om de juiste balans te vinden tussen zekerheid vooraf en een agile aanpak, dus je moet de voorbereiding doen die past bij het project.

Net als dat een small, medium en large shirt niet iedereen past, geldt dit ook voor de voorbereiding van een project. Is het een klein project zonder complexe interface? Dan is vaak een Backlogsessie of korte Pretotype-sessie voldoende. Is het een project nog klein maar kan groot worden met veel risico’s? Dan is een Pretotype-sessie een minimum maar is een Design Sprint een betere optie. Bij complexe trajecten van vele weken raden we sowieso een Design Sprint aan.

Een goed projectbegin vraagt aan het begin een investering maar betaalt zich ruim terug. Dus neem de tijd om je project scherp te krijgen en kies de projectstart die bij jou past.