Ja rara de koekoek dat je proces zo werkt

Zolang je op een bepaald abstractieniveau blijft hangen, voelt bijna elk proces vrij snel ‘kloppend’. Maar dat zegt dan vaak iets over het gebrek aan (de benodigde) diepgang. En juist dat gebrek aan diepgang betaal je later terug in extra werk, vaak vermomd als voortschrijdend inzicht, misverstanden of dure correcties. Het is voor ons ondankbaar werk om de brenger van slecht nieuws te zijn. In projecten gebeurt het namelijk regelmatig dat we pas ná de requirementanalyse-fase de specificaties onder ogen krijgen en moeten concluderen: Ja, rara de koekoek dat je proces zo werkt.

Wat bedoelen we daarmee? Simpel: de analyse is zo abstract gebleven dat de vertaalslag naar een werkbare oplossing (nagenoeg) onmogelijk wordt. Een projectteam dat dacht klaar te zijn, wordt ineens geconfronteerd met het feit dat de analyse niet diep genoeg is gegaan en essentiële details ontbreken. We zien regelmatig ‘procesbeschrijvingen’ voorbij komen die min of meer alsvolgt zijn opgebouwd:

  • Verkooporder aanmaken
  • Picken
  • Leveren
  • Betaling ontvangen

Klinkt logisch, toch? Maar juist dát zou een alarmbel moeten zijn. Want als iets zó vanzelfsprekend overkomt, is de kans groot dat het benodigde detailniveau nog helemaal niet is bereikt. Waar zijn de uitzonderingen, randvoorwaarden, systeeminteracties, rollen, foutafhandeling? Wat je niet expliciet benoemt, wordt meestal niet meegenomen in de oplossingsrichting of scope. Niet omdat het vergeten is, maar omdat het simpelweg nooit op tafel heeft gelegen.

Als je gedurende de analyse niet meermaals ‘Hoe werkt dit?‘ hoort van je externe sparringspartner, heb je de benodigde diepgang nog niet bereikt!

Waarom is dit een probleem?
Wanneer requirements te oppervlakkig blijven, creëert dat later in het project serieuze problemen:

  • Een schijngevoel van voltooiing – Het team denkt dat de requirementanalyse is afgerond, terwijl in werkelijkheid de échte vragen nog niet eens gesteld zijn.

  • Te vage uitgangspunten voor ontwerp en implementatie – Een te algemeen proces leidt tot een oplossing die wellicht dat algemene proces ondersteunt, maar dat je er later achterkomt dat jouw proces toch nét wat complexer is – en dat die complexiteit niet in de bouw van de oplossing is meegenomen.

  • Vertraagde pijn – Wat eerder had moeten worden uitgezocht, moet nu alsnog in latere fasen worden opgelost, vaak onder tijdsdruk en met hogere kosten.

Dit probleem ligt zeker niet alleen bij de klant. Een leverancier heeft hier zeker óók een verantwoordelijkheid. Als een architect een huis ontwerpt, stelt hij niet alleen de evidente vragen of de bewoner ook een dak en een voordeur wil. Het is juist een samenspel tussen degene met de inhoudelijke kennis (de klant) en degene die het moet vertalen naar een oplossing (de leverancier). Dat vraagt van de klant dat die (vermoedelijk) verder nadenkt over zijn proces dan die misschien gewend is. En van de leverancier dat die niet blijft hangen in open deuren, maar zijn kennis gebruikt om gericht door te vragen – juist op de punten waarvan hij weet dat ze later het verschil maken.

Hoe pak je dit wél goed aan?
Een requirementanalyse is geen formaliteit en zeker geen lijstje open deuren. Het moet de basis vormen voor een oplossing die écht werkt in de praktijk. Dat betekent: verder kijken dan alleen wat iemand op hoofdlijnen zegt nodig te hebben.

Het vraagt om denkwerk, doorvragen en detailuitwerking. Ja, dat kost tijd. Maar die tijd verdien je later dubbel en dwars terug doordat je voorkomt dat je halverwege je implementatie moet herstellen, bijschaven of erger nog (deels) opnieuw beginnen.

  • Stem je aanpak af op de mate van proceskennis en -inzicht – Ga niet meteen eisen formuleren als je nog niet weet hoe het proceslandschap eruitziet of hoe processen écht werken. Start dan eerst met process discovery, validatie of modellering. Anders bouw je op aannames en fragmenten, en dat leidt zelden tot een goede oplossing.
  • Durf te benoemen wanneer de benodigde diepgang ontbreekt – Als iets nog te vaag is, spreek dat dan uit. Niet wachten tot de bouwfase om erachter te komen dat essentiële details missen. Vroeg signaleren voorkomt gedoe later.
  • Vermijd vage containerbegrippen in requirements – Termen als “order verwerken” of “gegevens valideren” klinken logisch, maar zeggen zonder context helemaal niets. Wat bedoel je precies? Wie doet het? Wanneer? Met welke regels of uitzonderingen? Functionele eisen moeten concreet, controleerbaar en toetsbaar zijn.
  • Leveranciers, pak je rol in kwaliteitsbewaking – Je bent niet alleen uitvoerder, je bent ook adviseur. Als je ziet dat iets nog te abstract is om mee te werken, kaart het dan aan. Laat zien waar je als leverancier waarde toevoegt: door jouw kennis en ervaring te gebruiken om scherpte te brengen.
  • Werk samen richting het juiste detailniveau – De klant hoeft niet alles zelf scherp te krijgen, en de leverancier hoeft niet alles zelf te verzinnen. Het draait om samenwerking waarin je elkaar helpt om de juiste vragen te stellen en écht tot de kern te komen.
Samenvatting
Een requirementanalyse moet meer zijn dan een opsomming van vanzelfsprekendheden—het moet de basis leggen voor een uitvoerbare en werkbare oplossing. Te abstracte requirements leiden tot interpretatieproblemen, misverstanden en vertragingen verderop in het project.
Dit vraagt om grondig denkwerk en detailuitwerking. Ja, dat kost tijd, maar het alternatief is later in het project vastlopen op vage en incomplete specificaties. Zowel klanten als leveranciers hebben hierin een verantwoordelijkheid: een analyse is pas af als deze de benodigde diepgang heeft bereikt.