Organisaties richten zich bij de vaststelling van de requirements van een nieuw te ontwikkelen product meestal op de gedetailleerde requirements; de functional en non-functional requirements die in het vorige deel (Requirements: bezint eer ge begint…) van deze artikelreeks al aan de orde kwamen. In andere woorden: wat moet het product kunnen? En wat voor eisen stellen we aan die werking?
Aan requirements van een hoger niveau – business requirements – wordt vaak minder aandacht besteed. Of ze worden genegeerd. Dat, terwijl business requirements nodig zijn om een aantal cruciale vragen te kunnen beantwoorden: ‘Waarom doen we dit?' ‘Wat wil de business hier nu eigenlijk mee bereiken?' ‘Hoe borgen we dat het product aan alle eisen van de business voldoet?'
Vaak blijven organisaties het antwoord op die vragen schuldig, maar wordt de ontwikkeling toch voortgezet. De opdrachtgever heeft zijn zinnen gezet op die mooie nieuwe oplossing, heeft misschien wel beloften gedaan aan derden of is bang voor de reputatieschade die het gevolg kan zijn van het afblazen van het project. Het gevolg: een duur project, een oplossing die duur in het gebruik is, überhaupt niet wordt gebruikt, of een project dat uiteindelijk dusdanig uit de klauwen loopt dat het alsnog niet kan worden voltooid.
De toepassing van business requirements is daarmee bittere noodzaak. Groot voordeel: het is echt geen rocket science.
Procesbewaking
Een nieuw product biedt als het goed is een oplossing voor een probleem. Binnen organisaties komen problemen altijd op hetzelfde neer: de kosten zijn te hoog, de productie te laag, de omzet blijft achter, we hebben te veel werknemers, et cetera. Business requirements zijn ervoor om alles wat je bouwt tegen dat licht te houden. Wat wil je als bedrijf bereiken? Per wanneer? En hoeveel resources zijn ermee gemoeid? En als dat duidelijk is: draagt de nieuwe oplossing genoeg bij? Of zijn de kosten die ermee zijn gemoeid te hoog, afgezet tegen de benefits? De uitkomst is niet per se positief: als de baten niet opwegen tegen de kosten gaat het feest niet door.
Business requirements blijven ook van belang als het project al onderweg is. De omstandigheden zullen ook tijdens het proces blijven veranderen. De markt beweegt, wet- en regelgeving verandert, het bedrijf groeit of krimpt, de strategie wordt bijgesteld. Business requirements worden dientengevolge continu bijgesteld, maar kunnen ook volledig omslaan. De eisen die aan het product worden gesteld moeten meeveranderen. Als gevolg van die continue heroverweging kan blijken dat het niet zinvol is om met de ontwikkeling door te gaan. Het voordeel is dat je dat dan in een vroeg stadium kunt signaleren. Het alternatief is bovendien onwenselijk: als je je tijdens de ontwikkeling niet stoort aan wat er in de buitenwereld gebeurt kan het gebeuren dat de uiteindelijke oplossing bij voltooiing volledig obsoleet blijkt te zijn. Daar gaan je geld en je reputatie…
Kortom: met business requirements kun je het bestaansrecht van het project doorlopend blijven toetsen. Zie het als een vorm van procesbewaking.
Stakeholders
Projectleiders krijgen in grote projecten regelmatig te maken met conflicterende belangen vanuit de business. De ene stakeholder wil iets anders dan de andere en men lijkt het maar moeilijk eens te kunnen worden over het einddoel. Het is in zo'n situatie heel lastig om prioriteiten te leggen, de scope van het project af te bakenen en de voortgang te bewaken. Het gevolg: Het project wordt onbeheersbaar, qua kosten en looptijd. En het uiteindelijke product voldoet niet en/of is te duur in onderhoud.
Als je stakeholders op een goede manier kunt stimuleren hun verantwoordelijkheid te nemen en de gevolgen van hun beslissingen te onderkennen, creëer je de juiste randvoorwaarden voor een oplossing waarmee iedereen vooruit kan. De stakeholders moeten te kennen geven aan welke eisen de oplossing wat hun betreft moet voldoen – en dat moeten ze door het hele proces heen volhouden – maar ze moeten ook verder kunnen kijken dan hun neus lang is en the big picture voor ogen houden.
De vertaling van business requirements naar een werkbare oplossing zal onherroepelijk betekenen dat niet iedereen krijgt wat hij wilde. Sommige requirements zullen organisatiebreed gedeeld worden, maar andere zullen conflicteren. Stakeholders moeten daarom in staat zijn het belang van hun eigen onderdeel voor de business goed in te schatten, vooral ook in verhouding tot de organisatie als geheel. Dat betekent dat het eigen belang niet overschat moet worden, maar zeker ook niet onderschat.
Goede communicatie met stakeholders, maar ook tussen stakeholders onderling is een voorwaarde voor een complex aan requirements waarmee iedereen kan leven en dat een oplossing oplevert die echt bijdraagt aan de business. Als iedereen zijn wensen kenbaar kan maken, maar ook met de ander kan praten over mogelijke conflicterende belangen en gedeelde wensen, kan een hoop wrevel, bitterheid en frustratie worden voorkomen. Openheid en eerlijkheid zijn essentieel; aan de organisatie het een en ander te faciliteren met ronde tafels, workshops en dergelijke.
Het resultaat is een oplossing die voor alle stakeholders acceptabel is, waarbij ook meteen gezegd is dat niet iedere stakeholder helemaal gekregen heeft wat hij van origine wenste. Bij een flink deel van de stakeholders zal een lichte teleurstelling aanwezig zijn: "Ik heb helaas niet alles gekregen wat ik wilde, maar afijn, de belangrijkste zaken zitten er nu al wel in."
Prioriteit
Met goede requirements en welwillende stakeholders alleen ben je er niet. Ontwikkelprojecten moeten ook op managementniveau prioriteit hebben en houden. Als veranderende omstandigheden uitwijzen dat de requirements moeten worden bijgesteld, zal het management daarin ook een rol moeten spelen. Elke verandering heeft meestal ook een financiële dimensie. Met andere woorden: er moet vaak geld bij. Het management moet in principe bereid zijn die investering te doen. Voordeel daarbij is wel dat die financiële injectie – middels business requirements – valt te verantwoorden en niet, zoals in veel gevallen, in een zwart gat wordt gekieperd.
Het management moet ook bereid zijn te investeren in tijd: de tijd van stakeholders. Stakeholders hebben als gezegd een belangrijke rol in het proces, maar moeten ook de gelegenheid krijgen die rol in te vullen – ook al gaat dat ten koste van het bedrijfsresultaat op korte termijn.
Door aandacht te besteden aan de vaststelling van business requirements kunnen veel hoofdpijnpunten voorkomen worden. Het is de enige manier om persoonlijke agenda's onder controle te krijgen en de randvoorwaarden te scheppen voor een oplossing die echt bijdraagt aan de resultaten van de organisatie.
Jan Hendrik Stam, trainer/consultant Capgemini Academy
Requirements traceability matrix
Om te borgen dat het eindproduct maximaal bijdraagt aan de business, moeten de requirements van alle stakeholders binnen de organisatie vastgelegd worden in een requirements traceability matrix De in de organisatie opgetekende requirements worden in de matrix door elk betrokken bedrijfsonderdeel beoordeeld. Zo kom je erachter dat een bepaalde requirement voor bedrijfsonderdeel A cruciaal is, terwijl bedrijfsonderdeel B er weinig aan heeft of er juist door wordt belemmerd. Je kunt in de matrix aangeven hoe requirements zich tot elkaar verhouden.
Naast de aansluiting tussen business requirements en user requirements moeten ook andere afhankelijkheden tussen requirements zichtbaar gemaakt worden. Sluiten requirements elkaar niet toevallig uit? Is de ene requirement soms afhankelijk van een andere? Op deze manier creëer je een hierarchie van requirements; essentiele behoud je, voor conflicterende zoek je een middenweg en requirements die niet meer blijken te zijn dan nice to have laat je achterwege.
Tijdens het ontwikkelproject is het onvermijdelijk dat er wijzigingen optreden in de requirements. Voortschrijdend inzicht zal ertoe leiden dat requirements achterhaald of overbodig zijn geworden, of moeten worden bijgesteld. Met de gedocumenteerde afhankelijkheden matrix kan de impact van dergelijke wijzigingen voor alle afzonderlijke requirements en voor de totaaloplossing worden voorspeld – in het kader van change management een belangrijk pluspunt.
Hmm …. waarom heb ik bij een requirements traceability matrix een heel ander idee dan wat hier beschreven staat?
Wat hier beschreven wordt (in het kader, 1e alinea) is in mijn ogen een beslissingsmatrix. Met de beschreven methode kun je dan kijken welke requirement voor welke stakeholder belangrijk is, en op basis daarvan een besluit nemen welke requirements je wel en niet gaat implementeren en eventueel in welke volgorde (de prioriteiten).
Bij een requirements traceability matrix denk ik meer aan een tabel waarin ik kan zien met bijvoorbeeld welke functionaliteit(en) welk requirement is geïmplementeerd, met welk work package, taak of wat dan ook een requirement is geïmplementeerd of zelfs met welke testcase welke requirement wordt afgetest of geverifieerd.
Voor de rest is dit hele verhaal gewoon een stuk gezond boerenverstand gebruiken bij zowel programma- als projectmanagement. Zoals de auteur al zegt, het is geen rocket science, maar een kwestie van gewoon doen.
Ik ben het met PaVaKe eens.
Maar, ook al kom je met gezond verstand een heel eind, is het haast verbijsterend hoeveel organisaties hier toch heel veel moeite mee hebben.
Ik kom zo vaak tegen dat men zegt veel aandacht te geven aan requirements, dat het zo belangrijk is en dat men ermee omgaat als hier staat beschreven. Echter, in werkelijkheid wordt het te simpel of te gemakkelijk benaderd (gezond verstand maakt niet gelijk eenvoudig!).
Het gevolg dat ik dan vaak zie is dat: De requirements toch niet zo helder blijken te zijn: Niet de juiste stakeholders betrokken zijn; Er onvolledige traces zijn; De begrippen van business en user requirements verward worden (Ik heb overigens het liever over Needs en Features, dat dekt de lading m.i. beter en in de praktijk zie ik dat mensen dat ook beter volgen), etc.
Kortom, de conclusie uit het artikel onderschrijf ik wel, maar er valt hier dus nog een hoop te halen voor bedrijven!