Als je de ontwikkeling van een systeem wilt uitbesteden aan een interne of externe leverancier zul je duidelijk moeten maken aan welke eisen en wensen de software moet voldoen. Bij veel organisaties wordt hiervoor een programma van eisen (PvE) opgesteld. Daarmee geef je als opdrachtgever aan, aan welke eisen en randvoorwaarden de te ontwikkelen software moet voldoen.
Een PvE bevat gewoonlijk een opsomming van vele tientallen of zelfs honderden requirements. Die ook nog eens SMART gespecificeerd moeten zijn. Dat is veel werk, zeker als je je eisen en wensen tot in detail wilt specificeren. Bovendien is het lastig om geen eisen over het hoofd te zien.
De meeste systemen hebben diverse groepen stakeholders met allerlei verschillende belangen. Het is een hele klus om die stakeholders op één lijn te krijgen en requirements op te stellen waar iedereen achter kan staan.
Voor de leverancier is een programma van eisen lastig te doorgronden. Hij heeft doorgaans onvoldoende kennis van het businessdomein om de eisen in context te plaatsen. De ervaring leert verder dat de requirements zelden consistent, ondubbelzinnig en specifiek genoeg zijn.
Schommelkarikatuur
Het is niet verwonderlijk dat de bekende karikatuur met de schommel nog steeds herkenbaar is. De grootste problemen waar veel automatiseringsprojecten mee kampen brengt de schommelkarikatuur treffend in beeld.
De afgelopen decennia zijn er veel best practices en methoden en technieken ontwikkeld om de situatie te verbeteren. We zien echter dat dit slechts een marginaal effect heeft gehad. Dat komt in mijn ogen omdat we de echte problemen niet aanpakken.
Aan een PvE liggen de volgende fundamentele problemen ten grondslag:
1. De gebruikers weten vooraf niet exact wat ze nodig hebben
Het is vrijwel onmogelijk om op voorhand alle eisen en wensen op tafel te krijgen. Je kunt de ins en outs van de nieuwe / gewenste situatie namelijk niet overzien. Hoe weet je dan, tot in detail, aan welke eisen een systeem dat die nieuwe situatie gaat ondersteunen, moet voldoen?
Mensen hebben daar een concreet beeld van de nieuwe situatie voor nodig. Het is een bekend verschijnsel dat zodra het nieuwe systeem is ingevoerd de gebruikers veel beter kunnen aangeven wat ze precies hadden willen hebben. De uitdrukking “I know it when I see it” komt daar vandaan.
2. Het is moeilijk om een PvE goed te doorgronden
Voor de betrokkenen aan zowel de opdrachtgevers- als leverancierszijde is een programma van eisen lastig te begrijpen. Dit komt omdat het vaak een omvangrijk document is met veel details. Hierdoor ziet men door de bomen het bos niet meer en krijgen ze geen concreet beeld van de gewenste werking van het systeem.
3. Interpretatieverschillen komen pas bij oplevering aan het licht
Een kenmerk van communicatie is dat er altijd ruis op de lijn zit tussen zender en ontvanger. Ook voor schriftelijke communicatie geldt dat misverstanden en interpretatieverschillen onvermijdelijk zijn. Toch gaan we ervan uit dat de leverancier een systeem oplevert dat voldoet aan de gespecificeerde requirements.
De onvermijdelijke verschillen tussen de behoeften van de opdrachtgevende organisatie en de interpretatie van de leverancier komen pas bij oplevering aan het licht.
Schommelkarikatuur verslaan
Zolang we de geschetste problemen niet adresseren blijft de schommelkarikatuur actueel. Met wederom nieuwe best practices acht ik de kans op echte verbeteringen klein. Daarvoor moeten we een oplossing vinden voor de fundamentele problemen.
Er is dus een wezenlijk andere aanpak nodig. Een aanpak die het huidige patroon doorbreekt. Het recept voor een aanpak waarmee je de schommelkarikatuur verslaat lees je in het artikel Doeltreffend programma van eisen en wensen.
Nicole de Swart
