Requirements als projectsuccesfactor

Miscommunicatie

Regelmatig wordt bij het opstarten van een project welgeteld één workshop georganiseerd voor het verzamelen en formuleren van de requirements. In het meest gunstige geval zijn voldoende afgevaardigden van de belanghebbenden partijen aanwezig die bijvoorbeeld met geeltjes in trefwoorden hun eisen en wensen plakken op grote vellen brown-paper. Het resultaat van deze sessie is vervolgens de inhoudelijke basis voor een geheel project. Dergelijke requirements vormen een wankele basis voor een goed resultaat en tevreden opdrachtgevers en gebruikers.

Voor het formuleren van requirements is kennis en ervaring ‘uit de lijn’ noodzakelijk. Veelal zijn dit specialisten die volledig vertrouwd zijn met het betreffende materiegebied, maar weinig tot geen ervaring hebben met projectmatig werken en het formuleren van professionele requirements. In dat geval is het zinvol om het requirementsproces te laten ondersteunen door professionals op dit gebied.

Goede requirements zijn belangrijk omdat deze het communicatiemiddel vormen tussen de opdrachtgever (de ‘business’) en de opdrachtnemer (het project) en tevens een belangrijk instrument vormen om de scope en de voortgang te beheersen.

Wat kenmerkt goede Requirements?

Goede requirements maken duidelijk wat een klant wil van een product of dienst. Dit illustreer ik met een eenvoudig voorbeeld uit de dagelijkse praktijk: het aanschaffen van een andere auto.

De auto moet voldoen aan de volgende requirements:

• Ruimte bieden aan twee volwassenen en twee kinderen;
• Voldoende bagageruimte hebben;
• Een caravan kunnen trekken;
• Economisch zijn in het gebruik;
• Comfortabel rijden;
• Sportieve prestaties bieden;
• Een aantrekkelijk uiterlijk hebben.

Helaas heeft een goede autoverkoper onvoldoende houvast aan deze eisen en wensen om een goed advies uit te kunnen brengen aan de klant. De verkoper dient aanvullende vragen te stellen om de eisen en wensen van de klant op het vereiste detailniveau voor een advies te leren kennen. Requirements moeten dus voldoende gedetailleerd zijn, maar mogen weer niet zo gedetailleerd zijn dat zij daarmee al het ‘hoe’ in plaats van het ‘wat’ beschrijven. Bij onze auto kan het requirement ‘sportieve prestaties’ bijvoorbeeld als volgt gespecificeerd worden:

• Voorbeeld 1: accelereren van 0 – 100 km/h in minder dan 10 seconden en een topsnelheid van minimaal 220 km/h;
• Voorbeeld 2: de auto moet voorzien zijn van een 6-cilinder motor van minimaal 200 PK.

In het tweede voorbeeld gaat de klant op de stoel zitten van de ontwerper en ontneemt zodoende de ontwerper de vrijheid om op een adequate manier invulling te geven aan de eisen en wensen. Bovendien is het nog maar de vraag of realisatie van dit requirement tot de beste keuze zal leiden. Helaas kom ik in de dagelijkse praktijk regelmatig zowel te globale als te gedetailleerde requirements tegen. Deze fouten vormen een potentiële bron voor problemen verderop in het project.

Soms blijft het formuleren van requirements beperkt tot een meer of minder uitgebreide lijst met ‘losse’ requirements waarin weinig structuur te ontdekken is. Gelukkig probeert men in de meeste gevallen nog wel om enige structuur aan te brengen door requirements te groeperen tot thema’s of een andere passende indeling. Maar ook in die gevallen ontbreekt vaak een degelijke structuur.

Hoe krijg ik als projectmanager grip op de Requirements?

Mijn persoonlijke voorkeur gaat uit naar het gebruik van een Goal Breakdown Structure (GBS). Deze techniek is vergelijkbaar met een Product Breakdown Structure, met dien verstande dat nu niet de te realiseren producten, maar de te bereiken doelen in een hiërarchische structuur weergegeven worden.

Een gebruikelijke opbouw van een GBS is als volgt:

• Projectdoel of Mission Statement: het hoofddoel van het project;
• Business doelen: zaken als verbetering van winst, marktaandeel of klanttevredenheid;
• Project Requirements: globaal geformuleerde eisen en wensen;
• Product Specificaties; gedetailleerde project requirements.

Hieronder ter illustratie een deels uitgewerkt voorbeeld voor de aanschaf van de nieuwe privéauto:

Voordeel is dat een logisch en samenhangend geheel ontstaat waarbij de bovenliggende lagen volledig bestaan uit de optelsom van de onderliggende lagen. Ieder requirement moet een duidelijke bijdrage leveren aan het bereiken van het bovenliggende doel. Wanneer dat niet het geval is, dan dient het requirement te vervallen of opnieuw gedefinieerd te worden.

Mijn tips:

• Neem voldoende tijd en ruime aandacht voor het opstellen van requirements;
• Schakel professionals in, om de materiedeskundigen te helpen bij het formuleren en structureren;
• Breng structuur en samenhang aan in de requirements, bijvoorbeeld door het gebruik van een GBS of een andere techniek;
• Bedenk dat requirements niet alleen statisch maar ook dynamisch kunnen zijn! Het is daarom zinvol om regelmatig expliciet aandacht te besteden aan de actualiteit ervan. Bijvoorbeeld bij faseovergangen.