Als je werkzaam bent als Informatiemanager, Functioneel Beheerder, Change Manager of Product Owner krijg je vroeg of laat te maken met requirements. Requirements management als proces is essentieel om projecten succesvol uit te voeren, ook bij een Agile projectaanpak .
Het uitvragen van deze requirements wordt vaak als tijdrovend en lastig ervaren waardoor de uitdaging uit de weg wordt gegaan de business value (bedrijfswaarde) bij deze requirements te achterhalen en met stakeholders vast te stellen. Dit artikel geeft je wat handvatten.
Back-to-the-basics: een requirement is een enkelvoudig gedocumenteerde bepaling wat een specifiek(e) product of dienst zou moeten doen (vereiste). Voor ieder willekeurige organisatie gelden weer andere producten en diensten. Requirements worden veelal gebruikt bij systeemontwerp en software ontwikkeling. In een requirement worden benodigde attributen, capaciteiten, karakteristieken of kwaliteiten van een (informatie)systeem geïdentificeerd die bruikbaar zijn en meerwaarde (value) bieden voor een gebruiker in één of meerdere bedrijfsprocessen. Requirements zijn geen simpele opsomming van user stories uit een product backlog en geven geen houvast om de gewenste uitkomst van een project noch te voorspellen noch goed vast te leggen en te communiceren.
Projecten (ook in de Agile vorm) worden succesvoller als vooraf de requirements helder zijn, afgestemd zijn met de diverse stakeholders (belanghebbenden) en zijn voorzien van impactbepaling en prioritering. Juist dat is geen sinecure.
Het begint feitelijk met het Waarom (It starts with Why). Om welke reden wil een stakeholder zijn of haar requirement geïmplementeerd zien en kan hij/zij definiëren wat de wens exact inhoudt (It follows with What). In deze fase gaat de (beheer)organisatie zich vaak al druk maken om het HOE. Dat is nu juist iets voor later en laat die verantwoordelijkheid vooral over aan de leverende interne of externe software leverancier. Het Hoe wordt wel in het zadel geholpen als Wat en Waarom helder zijn en ook zijn uitgeschreven.
Een van de uitdagingen om uit te vinden tijdens het prioriteren van producteigenschappen is: wat is de echte waarde van de nieuwe producteigenschap voor het bedrijf. Dit noemen we de business value. Dit ligt vaak niet op de plank en niet iedere organisatie heeft een gestructureerd marketing- en verkoopproces om de mogelijke waarde van een producteigenschap vast te stellen, laat staan naar elkaar uit te leggen. De waarde van deze eigenschap is gerelateerd aan de tijd die het kost om de eigenschap te ontwikkelen en op de markt te brengen (ontwikkeltijd versus time-to-market). Het is wellicht not-done dat stakeholders moeten bepalen welke nieuwe eigenschap het meest waardevol is of waarde toevoegt, toch is het well-done deze uitdaging aan te gaan. Doorgaans is daar een Functioneel Beheerder of Informatiemanager bij betrokken, deze zetten zich richting de business meteen op de kaart en de meerwaarde is een feit. Het is niet ongebruikelijk in dit proces dat verschillende stakeholders het niet eens zijn over welke eigenschap het eerst ontwikkeld dient te worden. Onderken dit en loop er niet voor weg.
Rendement bij het prioriteren van requirements valt uitsluitend te behalen als de:
Het staat eenieder vrij een set aan methoden en technieken te gebruiken zodat er grip komt op de requirements, tevens op IT-leveranciers die nieuwe functionaliteiten ontwikkelen en eveneens op de organisatie die deze functionaliteiten gaan beheren. Wat kunt u zoal doen?...
Schrijf je in voor onze nieuwsbrief