De nut en noodzaak van business values

Succesvol projecten doen

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 met waarom

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.

Business valuation

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.

Hoe vindt overeenstemming in prioriteiten plaats?

Rendement bij het prioriteren van requirements valt uitsluitend te behalen als de:

• Prioriteiten volledig begrepen worden;
• Prioriteiten gedefinieerd zijn voor de gehele organisatie en niet per afdeling of individu die het hardste schreeuwt, urgentie mag niet de boventoon voeren;
• Alle stakeholders zeer bewust en betrokken worden bij het prioriteren zonder de gehele verantwoordelijkheid weg te managen naar de Product Owner;
• Business values zijn opgedeeld naar componenten als: wet-en regelgeving, imago, juridisch, financieel-economisch etc.

Welke methoden en technieken zijn bruikbaar in uw situatie?

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?...

• Achterhaal wie je stakeholders zijn en wat hun precieze rol is in het bedrijfsproces, inventariseer wat hen blij maakt en waar zij tegenaan lopen, bespreek hun doelen;
• Ken je stakeholders: investeer tijd in hen, maak eens een praatje bij de koffieautomaat, ga een dagje floorwalken om te proeven hoe de business denkt en kruip een tijdje in de huid van je stakeholder;
• Als je met requirements werkt, splits deze voor het overzicht uit naar functionele en niet-functionele requirements. Functionele requirements beschrijven specifiek gedrag of functies die het (informatie)systeem dient te vervullen (capaciteiten). Niet-functionele requirements (in vakjargon de zgn. non-functionals) specificeren criteria om het functioneren van het (informatie)systeem te beoordelen, maar beschrijven niet het specifieke gedrag zelf. Denk aan veiligheid, betrouwbaarheid en (systeem) performance;
• Stuur data-driven op business values waardoor IT- en IV projecten succesvoller worden en betere beslissingen kunnen worden genomen op basis van  prioriteiten van meerdere stakeholders. Door voortgang op doelen te  meten kunnen prioriteiten telkens worden bijgestuurd op basis van echte data (Plan-Do-Check-Act);
• Relateer product keuzes aan echte business value waarmee je in staat bent goed stakeholder management te doen en telkens de meeste waarde op te leveren op basis van meetbare doelen;
• Speel het business-value spel: je nodigt alle stakeholders uit voor een meeting van max 2-4 uur (Product Management Board). Stakeholders wordt gevraagd te stemmen op de Business Value van iedere product vereiste zoals gepresenteerd door de Product Owner uit de Product Backlog. Als spelregel geldt wel dat de business value relatief bepaald wordt en uitvalt naar:
• Operationele efficiency: ieder requirement bespaart geldt voor de organisatie dan wel versterkt het imago;
• Up-sell: iedere vereiste brengt geldt op;
• Behouden: iedere vereiste die voorkomt dat klant overstapt naar de concurrent;
• Nieuwe zaken:  iedere vereiste die potentieel nieuwe business aanboort.