Requirements op papier

In een eerdere opdracht als testmanager leek er in eerste instantie reden tot optimisme. Er lag een dik Excel-document met uitgewerkte requirements. Hoewel de bouw al was gestart voordat deze rol werd ingevuld, gaf een stevige set requirements aan de basis vertrouwen.

Dat vertrouwen bleek van korte duur. Bij nadere bestudering bleek een groot deel van de requirements niet SMART gedefinieerd. Onduidelijke formuleringen, vage doelstellingen en gebrek aan concrete acceptatiecriteria maakten het onmogelijk om eenduidig te toetsen wat er precies gebouwd moest worden.

De oplossing? Alle betrokkenen die dagelijks met het nieuwe systeem zouden gaan werken bij elkaar brengen en gezamenlijk de volledige lijst doornemen. Elk requirement werd besproken: wat wordt hier precies bedoeld, wat is de achterliggende rationale, en hoe kan dit wél SMART worden geformuleerd?

Een intensief en tijdrovend traject. Met een groep van acht behandelaars kost het al snel drie volledige middagen om enkele honderden requirements zorgvuldig door te nemen.

De verkeerde mensen aan tafel

Tijdens dat traject kwam een volgende pijnlijke ontdekking aan het licht: de requirements waren niet opgesteld door – of zelfs maar samen met – de toekomstige gebruikers.

Een deel was geknipt en geplakt uit een vergelijkbaar project. Andere onderdelen waren aangevuld door managers die wisten dat uit het huidige systeem geen managementinformatie kon worden gehaald. Formuleringen als ‘er moet sturingsinformatie worden opgeleverd’ deden vermoeden dat men had gehoord dat meetbaarheid belangrijk is, maar zonder concreet te maken wat er dan precies gemeten of aangetoond moest worden.

Met veel extra inspanningen, moeizame meetings (lees: tijd en geld) en een lange restpuntenlijst als erfenis werd de eindstreep uiteindelijk gehaald. In een latere opdracht was het gelukkig anders ingericht: daar werden de requirements wél opgesteld door toekomstige gebruikers en waren alle relevante rollen vanaf dag één betrokken.

Het verschil in kwaliteit en draagvlak was direct merkbaar.

Meer voorbeelden van kostbare missers

Dit is slechts één voorbeeld. Er zijn talloze projecten die mislukken of slechts met veel bloed, zweet en tranen – en vooral tijd en geld – de eindstreep halen. En zelfs dan blijft het resultaat vaak pover. De oorzaak ligt opvallend vaak in het voortraject, waar prematuur beslissingen worden genomen door de verkeerde mensen.

Zo werd in een project besloten om te starten met testautomatisering, terwijl de keuze voor het testautomatiseringstool al door de afdeling inkoop was gemaakt. Het bleek technisch gezien de verkeerde keuze.

In een ander geval moest eerst een verouderde regressietestset worden bijgewerkt voordat automatisering überhaupt zinvol was. De businesscase voor de aanschaf van het tool kwam daarmee direct onder druk te staan.

En er was een situatie waarin wel was begonnen met het automatiseren van de testset, maar zonder modulaire opzet. De onderhoudbaarheid werd daardoor vanaf de start een groeiend probleem.

Er is veel meegemaakt.

Weeffouten herstel je niet halverwege

Juist daarom blijft de boodschap dezelfde: betrek in het voortraject de juiste personen met de juiste expertise. Alleen zo kunnen verkeerde keuzes worden voorkomen – keuzes die een project tot het einde blijven achtervolgen en waar alle stakeholders de gevolgen van ondervinden.

Cruciale weeffouten in het voortraject laten zich zelden nog afdoende repareren wanneer de trein eenmaal rijdt. In sommige gevallen is het zelfs verstandiger om te stoppen en opnieuw de definitiefase in te gaan.

‘Beter ten halve gekeerd dan ten hele gedwaald.’