Een ict-project kent al snel honderden requirements. Meestal is het onmogelijk of onwenselijk om al die requirements in één keer te implementeren. Er moeten dan keuzes gemaakt worden. Welke requirements nemen we mee in de eerstvolgende release en welke requirements voegen we later toe?
Naast technische risico's en (on)mogelijkheden is hierbij de prioriteit van de requirements een uitermate belangrijk criterium. Requirements met een hoge prioriteit zijn belangrijker voor de business en leveren meer toegevoegde waarde dan requirements met een lagere prioriteit.
De prioriteit van een requirement zegt iets over de business value die men ermee denkt te halen. Meestal is het voldoende om de relatieve business values te bepalen. De requirements worden dan ten opzichte van elkaar gepositioneerd op basis van hun verwachte business value. Hiervoor bestaan verschillende prioriteringstechnieken. Sommige prioriteringstechnieken gaan verder door een absolute waarde aan de requirements toe te kennen. Veel gebruikte prioriteringstechnieken zijn: onderverdeling in de groepen hoog, middel en laag (relatief), ranking in aflopende volgorde van belangrijkheid zetten (relatief), tevredenheids- en ontevredenheidsratio's toekennen (relatief), indelen volgens MoSCoW (absoluut) en indelen volgens de categorieën van KANO (absoluut)
Het prioriteren van de requirements is minder eenvoudig dan het op het eerste gezicht lijkt. In depraktijk houden stakeholders vaak vol dat ze alle requirements even belangrijk vinden of kunnen de stakeholders het niet eens worden over de prioritering. Wat dan?
Wat doe je als…bijna alle requirements de hoogste prioriteit krijgen? Stakeholders zeggen vaak dat ze alle requirements super belangrijk vinden. Dit leidt er in sommige projecten toe dat 80 à 90 procent van de requirements de hoogste prioriteit krijgen. Het is dan niet mogelijk om de relatieve business value te gebruiken als criterium voor de requirements in de volgende release (of het volgende increment). Het prioriteren van de requirements kan dan net zo goed achterwege blijven.
Hier volgen enkele tips bij het prioriteren van de requirements:
– Laat alle requirements die de hoogste prioriteit hebben gekregen, nogmaals prioriteren. Vraag de stakeholders deze requirements in volgorde van belangrijkheid te zetten (ranking).
– Laat de stakeholders de requirements in drie of vijf groepen van gelijke grootte, verdelen. Het afdwingen van groepen met evenveel requirements kan alleen met bij relatieve prioritering. Bijvoorbeeld indelen in de groepen belangrijk, heel belangrijk en super belangrijk of in de groepen 1,2,3,4 en 5.
– Help de stakeholders door het stellen van de juiste vragen, zoals 'Wat zou de consequentie zijn als deze requirement niet in de eerste release wordt meegenomen?', 'Kan de requirement tijdelijk vervangen worden door een handmatige actie of andere workaround?' en 'Waarom is de klant/gebruiker ontevreden als het systeem niet aan deze requirement voldoet?'.
De verschillende stakeholders bij een ict-project hebben uiteenlopende belangen. Het is daarom niet verwonderlijk dat ze allemaal andere prioriteiten stellen. Gelukkig is het niet nodig om het met alle stakeholders eens te worden over de prioriteiten van de totale set aan requirements.
Laat stakeholders alleen die requirements prioriteren die ze zelf hebben ingebracht of die ze direct aangaan. Verdeel de totale set aan requirements in functionele gebieden, voor iedere gebruikersgroep één (bijvoorbeeld voorraadbeheer, verkoop, facturatie). Laat de requirements in ieder functioneel gebied alleen prioriteren door de vertegenwoordiger(s) van de betreffende gebruikersgroep. Laat to slot het relatieve belang tussen de functionele gebieden bepalen door de manager op het overkoepelende niveau.
Goed stuk. vind ik.
Mijn ervaring is dat als jemensen vraagt wat ze willen je een breed antwoord krijgt. Als je dus 100 potentiele gebruikers van een nieuw erp pakket dit vraagt krijg je dus een hele dure, ingewikklede erp implementatie.
Veel beter is het om de gebruiker al direct te vragen wat ie wil als het euro 1000,= ( ten laste van zijn budget dus) kost of euro 500,= etc.
Prioriteitstelling dus gelijk in de vraagstelling bij de aanstaande gebruiker neerleggen.
De les is dat waar beslissen, betalen en genieten in 1 hand ligt pakweg 30% efficiency voordeel optreedt.
Inderdaad mooi stukje. Het is goed om onderscheid te maken tussen (high-level) requirements en detail-invulling (specificaties). Mijn ervaring leert dat deze nogal eens door elkaar gebruikt worden. Zorg dat alleen de business value op hoog niveau wordt vertaald naar requirements. Detailinvulling volgt uit deze requirements en kan, om in agile termen te spreken, per iteratie worden vastgesteld.
Uiteindelijk zou er niets gespecificeerd mogen worden dat niet direct uit de (hoog) geprioriteerde requirements kan worden afgeleid. Dit zou immers niet efficient bijdragen aan de business value en in het ergste geval slechts geld kosten.
Typisch dat al snel 80% van de requirements tot Must Have worden verklaard. Ik vroeg dan altijd aan degene die dat zegt: “dus als deze requirement niet lukt, dan ga jij naar je baas en trek jij de stekker uit het project?”. Vaak is dan het antwoord: “nou, eh, nee, dat niet.”
Goed zo. We hebben het dan dus over een Should Have.
Een stapje terug graag:
“Het prioriteren van de requirements is minder eenvoudig dan het op het eerste gezicht lijkt. In de praktijk houden stakeholders vaak vol dat ze alle requirements even belangrijk vinden of kunnen de stakeholders het niet eens worden over de prioritering. Wat dan?”
Een gebruikersorganisatie die niet kan prioriteren is een rood stoplicht! Het duidt erop dat de stakeholders niet duidelijk genoeg en/of onenigheid hebben over wat het systeem en elke afzonderlijk onderdeel daarvan (requirements) de organisatie gaat brengen in termen van waarde. Door dan maar even een andere prioriteringstechniek te gaan toepassen sta je bij de achterdeur te koekeloeren, terwijl de voordeur wagenwijd openstaat!
Prioriteren moet je vanuit de projectdoelen doen!
Dat zijn doelen gesteld vanuit business (bv omzetverhoging), techniek (bv flexibele architectuur) en eindgebruikers (bv boek kopen). Door het product snel te simuleren kan je toetsen of een requirement bijdraagt aan de doelen. Want ik onderschrijf het statement ‘als je vraagt wat ze willen hoor je te veel’. En vaak zegt iemand iets te willen terwijl helemaal niet beseft wat dat functioneel of op scherm inhoudt.
Laat ik mijn reactie simpel houden: Lees de blog van Ron Tolido : http://www.blogit.nl/de-dood-van-requirements
En laat ik afsluiten met een quote van 1 van mijn helden, John Gall:
A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.
Veel waars in dit stukje, maar wat mij betreft toch wat te oppervlakkig. “De” Requirements kun je niet over een kam scheren en dat lijkt hier wel te gebeuren. Aan de basis hebben we meerdere typen requirements, zoals:
• Business requirements, die iets zeggen over de bedrijfsdoelstellingen waaraan nieuwe functionaliteit moet bijdragen,
• Gebruikersrequirements, die iets zeggen over de gewenste functionaliteit die gebruikers nodig hebben bij de uitvoering van hun taken en daarmee de realisatie van die doelstellingen en
• Systeemrequirements, die iets zeggen over de eisen waaraan het systeem moet voldoen om de business en/of gebruikersrequirements te realiseren, ofwel om de uiteindelijke functionaliteit te laten functioneren.
Elke categorie kent haar eigen prioritering die, van business naar systeem, beïnvloed wordt door de bovenliggende requirements. Want uiteindelijk heeft ICT maar een doel en dat is het leveren van dié functionerende functionaliteit die de klant en haar gebruikersorganisatie helpt bij het realiseren van de bedrijfsdoelstellingen.
Het spreekt voor zich dat deze doelstellingen gecommuniceerd moeten worden, gevat in duidelijk beleid. Dat helpt gebruikers de juiste keuzes te maken, helpt analisten de juiste prioritering vast te stellen en het helpt ICT te leveren wat echt nodig is.
Helemaal mee eens dat je moet vertrekken vanuit de business requirements ofwel de doelstellingen van de business. Ook het statement ‘als je vraagt wat ze willen, hoor je teveel’ onderschrijf ik. Het opstellen van de juiste requirements omvat veel meer dan het eenvoudigweg opsommen van de eisen en wensen van de stakeholders, zoals nog te vaak wordt gedacht.
Prioriteren doe je inderdaad op meerdere niveau’s en op verschillende momenten in het requirementsproces. Bedankt voor deze aanvulling.
@Nicole de Swart
…daar is toch de dmu voor.
Nooit problemen mee gehad.
Ik hanteer altijd een aantal w’s en h’s.
Wie, wat, waar, welke, waarom, hoe, hoeveel, waarom wij en (de belangrijkste) where is the money?
Dat noem ik de juiste w’s en h’s prioriteren.
Zeg maar, Jasper’s why-prioriteren-beren-leren onderzoek.
Kost nix – ’s gratis.
Daar heb ik geen moeilijke woorden voor nodig, moeilijke antwoorden wel!
Stake holders willen de onderneming runnen (lees: als het even kan graaien) – heb ik nix mee te maken – schuif ik naar de share holders.
Share holders willen rendement op hun investering (lees: maak hun niet uit, als ze maar verdienen aan hun investering) – heb ik nix mee te maken – schuif ik naar de stake holders.
Vervolgens is het contract getekend en kunnen we aan het werk.
Ik wil maar 1 ding, de order en de eindgebruiker tevreden stellen, de rest is gebakken lucht met een licht mousserende glooiende rode wijn… met een stukje zachte Franse kaas. Om de sfeer nog iets te verhogen, doe ik daar dan mijn schoenen bij uit.
Wie is u dan zult u zeggen?
Well, ik ben een simpele ‘broek op holder’.
Nicole heeft een lange vakantie.
We horen niets meer van d’r, hoe kan dat nou?
Ze zal wel met haar neus in de woordenboeken zitten.
Dat dit soort meisjes bij Computable… enz. Begrijp er niets van.
Ik zet GROTE vraagtekens bij de kwaliteit van het artikel.
Ik snap derhalve de redactie niet.
Volgens mij en andere mensen die ik het artikel hen laten lezen… Wegwezen met die Nicole.
Zo heb ik er ook nog 1: wegwezen-trigreren-nicoleren.