Requirements creep

“We gaan het dit keer heel anders doen”, zo stelde de project manager tijdens de kick-off van het nieuwe project. “We gaan ons dit keer exact aan de requirements houden. We doen niets meer, en niets minder dan is overeengekomen met de klant. En alles wat we tegenkomen aan meer- en minderwerk, dat zetten we gewoon op een aparte lijst. We gaan het systeem eerst conform de requirements opleveren, en daarna gaan we pas aan de slag met het meerwerk – als de klant daar tenminste voor wil betalen.” En hij sloot zijn betoog haast dreigend af met de woorden “Dit keer gaan we onze planning halen. Ik accepteer geen verrassingen meer.”

De kwestie

Hoe begrijpelijk is de opstelling van deze projectmanager. Het werk is voor een vaste prijs aangenomen. Er ligt na maanden onderhandelen eindelijk een lijvig contract; de wederzijdse verplichtingen zijn uitgebreid juridisch getoetst; er is een harde deadline voor de oplevering overeengekomen; er is dus geen enkele ruimte voor voortschrijdend inzicht. Het is goed voorstelbaar, zeker als een organisatie een historie heeft van uit de hand gelopen projecten, dat het bevriezen van requirements wordt gezien als een middel om projecten beter te laten lopen. In een post-project review wordt het fenomeen requirements creep immers niet zelden als de voornaamste schuldige van falende projecten aangewezen.

Toch is het niet bepaald zeker dat een systeem dat geheel conform de vooraf geformuleerde requirements wordt gebouwd, in de praktijk ook als een succesvol systeem wordt ervaren. Met andere woorden, een project dat we als een succes beschouwen, levert niet altijd een succesvol resultaat op.

Wat is hier aan de hand?

Er zijn boeken volgeschreven over de vraag hoe je aan goede requirements kunt komen en wat er in dat proces allemaal mis kan gaan. Eén van de aspecten is ongetwijfeld dat het ontwerpen van een oplossing en het ontlokken van eisen en wensen vaak hand in hand gaan. Ga maar na: zelfs de meest ervaren architect overziet het ontwerp pas als hij in detail heeft nagedacht over alle relevante aspecten in hun onderlinge samenhang. Dat doe je niet op basis van een schets, of een vaag idee, daarvoor moet je je echt in de oplossing verdiepen. Dus als je al een systeem volledig conform requirements zou willen bouwen, dan moet het ontwerp al helemaal af zijn, nog voordat je met de bouw begint. En dat is zo vorige-eeuws…

Een andere netelige kwestie draait om de “SMART-ness” van requirements. Het komt nog steeds voor dat requirements worden opgeleverd die onvoldoende toetsbaar zijn. Onvoldoende objectiveerbare eisen als “het systeem moet gebruikersvriendelijk zijn”, of “de onderhoudbaarheid moet voldoen aan de normen van professionaliteit” zijn geheide kiemen van conflict. Met name op het gebied van beveiliging kom je dergelijke vangnetartikelen nog verrassend vaak tegen.

Sommige opdrachtgevers hebben een onbedwingbare neiging om te overvragen. Bij het opstellen van een programma van eisen is de verleiding groot om het intern eens te worden over de optelsom van wensen en verlangens van alle betrokkenen, zowel in functionele als in technische zin, in de veronderstelling dat dit tijdens de onderhandelingen nog wel wordt aangescherpt. Echter, het spel van het tegen elkaar uitspelen van leveranciers brengt nogal eens met zich mee dat het eisenpakket een eigen leven gaat leiden. De prijs van de resulterende complexiteit weegt dan vaak niet op tegen de toegevoegde waarde van allerlei op de keper beschouwd niet-essentiele requirements.

Het opstellen van onhaalbare requirements is een andere bekende valkuil. Het is natuurlijk verleidelijk om – geheel in de geest van Machiavelli – te richten op een hoger doel in de hoop een lager gelegen doel te bereiken. Het wordt pas vervelend als dat hoger gelegen doel contractueel als verplichting wordt vastgelegd en het bereiken van het lager gelegen doel officieel als een mislukking wordt gezien. Oplossingen worden daardoor nodeloos duur en projecten worden nodeloos riskant. Het is dan ook zaak om als vragende partij zorgvuldig onderscheid te maken tussen wensen en eisen, en als aanbiedende partij, om wensen daadwerkelijk serieus te nemen.

Een laatste afrader is het gebruik van requirements om de oplossing te specificeren. Een combinatie van te veel en te strikte requirements heeft in het ergste geval een lege oplossingsruimte tot gevolg. Het is dan onmogelijk gemaakt om een succesvolle oplossing te bedenken. Maar ook als er nog wel een beperkte oplossingsruimte overblijft, dan blijft het risico bestaan dat in wezen superieure oplossingen onmogelijk gemaakt worden door een onvoldoende doordacht eisenpakket. Dus ook hier geldt: in de beperking toont zich de meester.

De rol van de architect

Een architect werkt nauw samen met zijn klant om zijn eisen en wensen duidelijk te krijgen. Hij doet dit om ‘in de huid van de klant’ te kunnen kruipen, om een ontwerp te kunnen maken dat voldoet aan de vaak dieperliggende behoeftes. Die zijn misschien niet SMART, maar dat maakt ze voor de klant nog niet minder relevant. Daarbij zal een architect op basis van zijn professionaliteit een klant ook stimuleren om na te denken over eisen en wensen die hij in eerste instantie misschien nog niet op zijn netvlies had. Tegelijkertijd zal een goede architect een klant niet lastig vallen met alle requirements die weliswaar relevant zijn voor de realisatie van het systeem, maar vanuit het perspectief van de klant volstrekt onbelangrijk. Het vinden van een goede balans tussen uitdagen en filteren getuigt van goed vakmanschap.

Een architect behoort een klant vriendelijk en vasthoudend uit te dagen om te verwoorden wat de achterliggende reden van een requirement is. Hij zal onderlinge strijdigheden blootleggen en op een constructieve manier proberen prioriteiten te achterhalen. Hij zal ook willen praten over de consequenties van een requirement, bijvoorbeeld in termen van kosten of risico’s. En hij zal actief op zoek gaan naar alle stakeholders die zeggenschap hebben over bepaalde aspecten van het systeem. Is er in de requirements wel voldoende met hun belangen rekening gehouden? Zijn zij voldoende gecommitteerd aan het gewenste resultaat? Hoe kan de oplossing zodanig worden ontworpen, dat het ook vanuit hun perspectief acceptabel is? Zijn alle criteria voor succes wel voldoende gewaarborgd?

Timing speelt ook een belangrijke rol. Aan het begin van een traject gaat het erom de requirements te adresseren die de besluitvorming kunnen beïnvloeden. In de loop van het traject wordt er meer gedetailleerd, en worden andersoortige eisen en wensen relevant. Het vroegtijdig lastigvallen van stakeholders met requirements die nog niet relevant zijn kan een professionele relatie ernstig ondermijnen. Dit is ook één van de achterliggende redenen waarom het vaak zo moeizaam is om alle relevante requirements te specificeren nog voordat er één spa de grond is ingegaan.

Een architect mag nooit een slaaf van de opgestelde requirements worden. Een architect komt pas goed tot zijn recht als hij de requirements meester kan zijn. Dat is immers de kern van “werken onder architectuur”. Als onvoldoende doordachte requirements tot wet worden verheven, als eisen en wensen niet als middel voor wederzijdse afstemming worden gezien, en als die wetten ook nog eens moeten worden toegepast zonder ruimte om na te denken over de bedoeling ervan, dan zullen nog talrijke ontwikkelprojecten tot mislukken gedoemd zijn.

Er zijn in het verleden al tal van dit soort kapotgespecificeerde projecten na veel geruzie uiteindelijk geëindigd in een rechtszaal. Als een rechter zich moet buigen over de bedoeling van de opgestelde requirements en de mate waarin het geleverde product daarin voorziet, dan heeft de betrokken architect in elk geval jammerlijk gefaald.

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 6de in een reeks die op dit weblog gepubliceerd zal worden.