In veel organisaties worden projecten gestart op basis van een idee dat ‘wel ongeveer klopt’. De urgentie is voelbaar, de intentie is goed, de oplossingsrichting lijkt logisch. En dus gaan teams aan de slag, soms zelfs vol energie.
Toch stokt het vaak alsnog. Niet door een gebrek aan inzet of competentie, maar omdat gaandeweg blijkt dat verwachtingen uit elkaar liepen. Wat de één bedoelde met “een simpel dashboard” bleek voor de ander een volledig geautomatiseerde rapportage. Of de oplossing die werd opgeleverd lost het verkeerde probleem op.
Dat soort situaties kosten niet alleen tijd en geld, maar ook vertrouwen. En ze zijn zelden het gevolg van slechte uitvoering. Vaak lag het echte probleem al aan het begin: de behoefte was niet scherp genoeg gedefinieerd.
Heldere behoeften, betere besluiten
In de technische wereld noemen we dit werkveld requirements engineering: het proces waarin je samen onderzoekt wat er precies nodig is, waarom dat relevant is, en onder welke voorwaarden het tot een goede oplossing kan leiden.
Hoewel het een formeel vakgebied is, zijn de principes universeel toepasbaar. In essentie gaat het om: goed luisteren, de vraag achter de vraag begrijpen, afstemmen op context en risico’s, en verwachtingen expliciet maken vóórdat er iets gebouwd, gekocht of ingevoerd wordt.
Dat is niet alleen nuttig bij grote IT-projecten of systeemvervanging. Ook bij beleidsvoorstellen, procesaanpassingen of het selecteren van een nieuwe leverancier geldt: hoe duidelijker de behoefte in beeld is, hoe groter de kans op een resultaat dat werkt.
De reflex om te dóen
In de praktijk is er vaak een neiging om snel tot actie over te gaan. De druk is hoog, de middelen zijn beperkt, de vraag is acuut. Stilstaan bij de onderliggende behoefte voelt dan al snel als vertraging.
Toch blijkt in veel evaluaties dat juist die eerste afstemming ontbreekt. Teams lopen vast, trajecten worden bijgesteld, er ontstaat onduidelijkheid over verantwoordelijkheden of gewenste functionaliteit. En dan moet alsnog worden teruggegaan naar de beginvraag: wat wilden we nu ook alweer bereiken?
De paradox is dat een klein beetje vertraging aan het begin vaak zorgt voor een versnelling verderop. Niet door het opstellen van lange documenten, maar door samen bewust stil te staan bij kernvragen: voor wie doen we dit, wat is het probleem, wat is een acceptabele oplossing, en onder welke randvoorwaarden?
Ook buiten projectomgevingen waardevol
Hoewel de term uit de IV-wereld komt, is deze manier van werken breder toepasbaar. Ook in kleinere organisaties, of in domeinen waar ‘projectmatig werken’ niet vanzelfsprekend is, kan het verhelderend zijn om explicieter te zijn over wat er nodig is – en wat niet.
Een team dat samenwerkt aan een beleidswijziging kan veel baat hebben bij een gedeeld beeld van het doel, de doelgroep en de gewenste impact. Een leidinggevende die een interne verbetering wil doorvoeren, helpt zichzelf door vooraf te bespreken wat succes betekent – en hoe dat gemeten wordt.
Het hoeft niet ingewikkeld te zijn. Maar het vraagt wél aandacht voor afstemming, vooral aan het begin.
Samenvattend
Goede afstemming vooraf voorkomt misverstanden achteraf. Dat is geen nieuwe wijsheid, maar wel één die in de praktijk vaak wordt genegeerd zodra de druk toeneemt.
Requirements engineering, in de meest eenvoudige zin, helpt om die afstemming bewust te maken. Door scherp te krijgen wat er nodig is, waarom, en hoe het past binnen de context.
Niet als papieren exercitie, maar als serieus onderdeel van samenwerken aan iets dat moet werken. In IT, in beleid, en in vrijwel elke andere organisatiecontext.