Requirementsmanagement

Algemeen

Requirementsmanagement stelt de wensen en behoeften van stakeholders vast om deze vervolgens te reviewen tot een basisset van requirements voor de ontwikkeling van oplossingen en batenmanagement. Haar doelstellingen zijn om:

• ervoor te zorgen dat alle stakeholders de kans krijgen hun wensen en behoeften kenbaar te maken;

• requirements van meerdere stakeholders met elkaar in overeenstemming te brengen om tot één levensvatbare reeks doelstellingen te komen;

• consensus tussen de stakeholders over een basisset van requirements te bereiken.

Een duidelijke en goedgekeurde omschrijving van requirements en de acceptatiecriteria daarvan, is essentieel voor het welslagen van elk project, programma of portfolio. De eisen kunnen worden uitgedrukt in fysieke prestaties, zakelijke voordelen, ambities, functies of technische behoeften.

 

 

In de planningsfase zullen de technieken en wijze van aanpak worden gedefinieerd om met stakeholders samen te werken bij het vastleggen en goedkeuren van requirements. De initiatiefase zal ervoor zorgen dat de nodige resources worden vrijgemaakt om requirementsmanagement te starten.

De plannings- en initiatiefasen worden gewoonlijk uitgevoerd als onderdeel van één overkoepelend scopemanagement procedure, maar kunnen worden gescheiden wanneer de requirements bijzonder complex of uitgebreid zijn.

De eerste specifieke stap in de procedure is het vastleggen van alle soorten requirements. De meesten zullen worden gegenereerd door interne en externe stakeholders (zoals klanten en gebruikers), maar er kan ook een achtergrond zijn van wettelijke of reglementaire requirements die ook moeten worden opgenomen.

De requirements moeten worden geanalyseerd om ervoor te zorgen dat ze praktisch en haalbaar zijn en eerder om vast te stellen ‘wat’er nodig is dan ‘hoe’ ze zullen worden bereikt. Een goed gespecificeerde requirement heeft de volgende kenmerken:

• uniek: er wordt slechts aan één kernrequirement voldaan;
• actueel: het is actueel en relevant voor de behoefte van het bedrijf;
• consistent: het is niet in strijd met andere requirements;
• begrijpelijk: het is duidelijk en ondubbelzinnig;
• verifieerbaar: door middel van inspectie, demonstratie of testen kan worden geverifieerd of de producten  aan de requirements voldoen;
• traceerbaar: het requirement kan getraceerd worden vanuit de oorspronkelijke behoefte, via het leveringsproces, tot aan het geleverde product;
• geprioriteerd: het belang ten opzichte van andere requirements wordt begrepen.

De resterende stappen zullen worden uitgevoerd in overeenstemming met de context van de werkzaamheden. Zo zou de aanpak voor softwareontwikkeling met een parallelle levenscyclus en een agile-benadering anders zijn dan die met een seriële levenscyclus; het beheer van de requirements voor bedrijfstransformatie zal anders zijn dan bij de bouw.

Het vastleggen van requirements kan op allerlei manieren worden gedaan, variërend van persoonlijke interviews, enquêtes en workshops tot focusgroepen, modellering en simulatie.

Sommige ontwikkelingsmethodologieën, waaronder agile, zijn ontworpen om continu requirements vast te leggen en te verfijnen, ervan uitgaande dat de stakeholders in het begin misschien niet zeker zijn van hun behoeften.

De analyse van de requirements houdt in dat wordt gezocht naar eventuele hiaten, overlappingen of conflicten in de vraag van de verschillende stakeholders. Het vergt op hoog niveau een initiële ontwikkeling van oplossingen, planning en batenmanagement om de implicaties van de vereisten te beoordelen. Het resultaat is een grondige kennis van de requirements en de manier waarop deze bijdragen aan de algemene doelstelling.

De consultatiestap is vooral gericht op het geven van feedback aan stakeholders en het opbouwen van consensus. De resultaten van de analyse worden gecommuniceerd via individueel overleg of groepsworkshops. Dit leidt tot een discussie over de functionaliteit en alternatieve ideeën.

Consultatie zou wel eens kunnen leiden tot het vastleggen en analyseren van nog meer requirements. Het uiteindelijke resultaat is een basisset van alternatieve keuzes voor functionele requirements. Deze kunnen vervolgens gebruikt worden om alternatieve oplossingen te onderzoeken tijdens de ontwikkeling van oplossingen.

Een gevestigde techniek die zich richt op requirementsmanagement, ontwikkeling van oplossingen en sommige aspecten van batenmanagement heet value management. Value is een subjectieve term en betekent voor verschillende mensen verschillende dingen, maar in de P3-omgeving is het een middel om de prijs-kwaliteitverhouding te maximaliseren en wordt het weergegeven door de verhouding:

Het doel van value management is niet het maximaliseren van de tevredenheid van de requirements, noch het minimaliseren van het gebruik van resources, maar het vaststellen van het evenwicht dat de verhouding tussen de twee maximaliseert.

 

Projecten, programma's en portfolio’s

Initieel worden de projectrequirements vastgesteld tijdens het identificatieproces en hoeven alleen gedetailleerd genoeg te zijn om de mogelijke oplossing te identificeren en de opdracht te voltooien. Requirementsmanagement wordt tijdens het definitieproces, samen met de ontwikkeling van oplossingen, in detail uitgevoerd om een volledige investeringsraming en business case te voltooien.

Bij kleine projecten met relatief eenvoudige doelstellingen kan dit allemaal door de projectmanager worden gedaan. Naarmate de requirements complexer worden, kan het nodig zijn specialisten in te schakelen. Zelfs bij kleine projecten is "het niet volledig begrijpen van de requirements van stakeholders" een van de meest voorkomende oorzaken van het mislukken van projecten. Dit is een exercitie die niet even terloops gedaan kan worden.

Voor projecten die deel uitmaken van een programma of die door een aannemer aan de klant worden geleverd, worden requirements afgeleid uit de programmarequirements of opdrachtbrief van de opdrachtgever. Zij hebben betrekking op een product en kunnen, afhankelijk van hoe goed de requirements zijn beschreven, leiden tot een vermindering van de benodigde inspanning.

Wanneer het de bedoeling is agile technieken te gebruiken, moet de procedure voor het managen van de requirements efficiënt en dynamisch zijn. Het moet zorgvuldige prioriteringsmechanismen gebruiken, zoals MoSCoW, om ervoor te zorgen dat in elk werkpakket alleen waardevolle en gerechtvaardigde requirements worden opgenomen.

Een eerste kwestie die moet worden opgelost, is of de requirements worden uitgedrukt als producten, resultaten of baten. Dit zal bepalen of het project de realisatie van baten omvat als onderdeel van een verlengde projectlevenscyclus. Als de vereisten meerdere baten omvatten die meer dan één gebied van bedrijfsverandering en meerdere producten betreffen, kunnen de werkzaamheden het best als een programma en niet als een project worden uitgevoerd.

De programmarequirements zullen doorgaans worden uitgedrukt als een combinatie van producten en baten. Deze kunnen vrij complexe relaties hebben die beschreven kunnen worden in een batenkaart.

De relatie tussen requirementsmanagement en de daaruit voortvloeiende functies van ontwikkelen van oplossingen en batenmanagement is niet helemaal volgordelijk. Om tot een basisset van requirements te komen is het noodzakelijk dat de stakeholders een kwantificering van de baten maken en een evaluatie van de oplossingen op hoog niveau doen. Dit gebeurt vooral in het identificatieproces en het definitieproces van de levenscyclus. Het team van programma-management is verantwoordelijk voor het managen van de requirements, voor zover dit van toepassing is op de baten van het programma, en het team moet beslissen hoeveel verantwoordelijkheid voor het managen van requirements voor producten, zal worden gedelegeerd aan de projectteams.

Een nuttige scheidslijn tussen het programma en projecten is dat het programma de functionele requirements formuleert van een verlangd product. Het is dan aan de projectteams om de technische requirements te managen die de vereiste functionaliteit zullen leveren.

 

 

Bij gebruik van value management moet het programmamanagementteam de waarde over de projecten heen afwegen. Zo kan bijvoorbeeld herprioritering en herverdeling van resources leiden tot een grotere totale waarde van het programma, ook al lijkt dit de waarde van een bepaald project te verminderen.

Een standaard portfolio bestaat uit projecten en programma's met onafhankelijke requirements. De requirements van de portfolio hebben betrekking op een efficiënt gebruik van de resources voor de organisatie en een verbetering van de discipline van het P3-management. Zodra deze requirements in het initiatieproces van de portfolio zijn vastgesteld, zullen zij vrij constant blijven.

De initiële requirements van een gestructureerde portfolio worden uitgedrukt in termen van de strategische doelstellingen van de organisatie. Dit zal een mengeling zijn van op zichzelf staande en onderling samenhangende requirements. De requirementsmanagementprocedure in een gestructureerde portfolio beoordeelt de strategische doelstellingen en verduidelijkt deze met de raad van bestuur.

De beoordeling van de requirements zal van start gaan tijdens het initiatieproces van de portfolio. Er moeten onderling samenhangende doelstellingen worden vastgesteld, die kunnen worden gebundeld in een programma met onafhankelijke doelstellingen die door projecten geleverd worden. Deze ontwerpactiviteit zal voortdurend worden herbeoordeeld als onderdeel van de prioriterings- en afwegingsactiviteiten in het portfoliomanagementproces.

De meeste activiteiten op het gebied van requirementsmanagement zullen worden gedelegeerd aan de project- en programmamanagementteams, maar het portfoliomanagementteam moet twee sleutelfuncties vervullen.

Teneerste plaats moeten zij de schakel vormen tussen de projecten en programma's enerzijds en de raad van bestuur, die eigenaar is van de strategie, anderzijds. Namens de raad van bestuur draagt het portfoliomanagementteam zorg voor een juiste vertaling van hun requirements in projecten en programma's. Namens de project- en programmamanagementteams moeten zij ervoor zorgen dat de strategische requirements adequaat zijn gedefinieerd, zodat de projecten en programma's over voldoende informatie beschikken om de juiste producten en baten te leveren.

Ten tweede moeten zij projecten en programma's coördineren om ervoor te zorgen dat de vele lokale processen voor het managen van de requirements op elkaar zijn afgestemd. Dit deel van het coördinatieproces van de portfolio kan inhouden dat de centrale verantwoordelijkheid wordt genomen voor de omgang met de belangrijkste stakeholders. Het zal zeker inhouden dat gedetailleerde project- en programmarequirements worden doorgelicht om hiaten, overlappingen en conflicten te monitoren.

 

Met dank aan het BPUG-team voor de vertaling naar het Nederlands