Volgens Basile Lemaire is het vaak lastig binnen projecten requirements goed te prioriteren. "Bestaande methodieken zijn omslachtig of onnodig complex. Een ander probleem is dat prioriteiten vaak worden bepaald vanuit een it-perspectief in plaats vanuit de bedrijfsvoering. Helaas komt het ook vaak voor dat degene die het hardste roept, bepaalt wat een ‘must’ is." Lemaire ontwikkelde een instrument voor het prioriteren van requirements: het Bulk & Gedonder kwadrant.

Omdat binnen business analyse de MoSCow-methodiek vaak gebruik wordt voor het prioriteren van requirements, gaat Lemaire uitgebreid in op de nadelen van deze methode. Voor wie MoSCow nog niet kent, het is een acroniem van vier categorieën waarin - in dit geval - requirements worden ingedeeld:

1. Must have: requirement is noodzakelijk voor projectsucces.

2. Should have: requirement is belangrijk maar minder tijdkritisch als de must-have, of er is een ‘workaround’ om in de werkpraktijk toch aan het requirement te kunnen voldoen.

3. Could have: requirement is niet belangrijk voor projectsucces; mee te nemen als het weinig kost en wel veel oplevert.

4. Won’t have: requirement draagt weinig bij aan projectsucces of is weinig rendabel en wordt in ieder geval niet nu geïmplementeerd.

Lemaire beoordeelt MoSCoW als een prima methode (eenvoudig, prioriteren vanuit bedrijfsvoering), maar onderkent drie mogelijke nadelen:

1. Het is lastig te bepalen te bepalen in hoeverre een requirement bijdraagt aan succes. In de praktijk bestaat daarbij het risico dat het aan grootste deel van de requirements een must-have wordt toegekend; iedereen wil zeker stellen dat zijn wens wordt meegenomen.

2. Risico van ‘trade-offs’ of compromissen: ik ga mee met jouw must-have voor dit requirement als jij meegaat met mijn must-have voor dat requirement.

3. Risico dat de stakeholder die het hardst roept of het meeste macht uitoefent, bepaalt wat de must-haves zijn. De vraag is dan in hoeverre het gaat om bedrijfsbelangen of om zijn belangen.

Deze nadelen pleiten - aldus Lemaire - voor "een methodiek die vanuit de bedrijfsvoering op een eenvoudige, transparante manier kan prioriteren terwijl eventueel ‘machtsmisbruik’ wordt tegengegaan": het Bulk & Gedonder-kwadrant.

Het Kwadrant gaat uit van afbreukrisico: wat zijn de consequenties wanneer er niet aan een requirement wordt voldaan? Per requirement wordt de prioriteit
bepaald. Het prioriteren geschiedt met stakeholders vanuit de bedrijfsvoering zoals klanten, gebruikers, proceseigenaren en functioneel beheerders. It-risico’s worden in principe als irrelevant beschouwd. Een risico is namelijk pas een risico als een bedrijfsproces in gevaar komt. Dat daar mogelijk een it-probleem
aan ten grondslag ligt, is belangrijk voor je implementatie en oplossing maar niet voor je prioritering.

De prioritering vindt plaats aan de hand van twee assen, de Bulk-as en de Gedonder-as. De Bulk-as: als aan dit requirement niet wordt voldaan, hebben daar (onacceptabel) veel eindgebruikers last van. De Gedonder-as: als aan dit requirement niet wordt voldaan, volgt escalatie (‘komt er gedonder van’).

Op basis van de twee assen kunnen vier kwadranten worden onderkend, die staan voor een prioriteit 1, prioriteit 2 of prioriteit 3:

1. Prio 1: requirement moet correct geïmplementeerd en grondig getest zijn. Indien het (nog) niet correct geïmplementeerd, is de consequentie dat de volgende projectfase, of de in productiename, moet worden uitgesteldust have: requirement is noodzakelijk voor projectsucces.

2. Prio 2: requirement moet in principe correct geïmplementeerd zijn. De opdrachtgever kan er bij tijdsdruk echter voor kiezen dat pas in een volgende projectfase of release aan het requirement moet zijn voldaan.

3. Prio 3: requirement mag onder tijdsdruk of bij budgetbeperkingen sneuvelen; hier gaat men vanuit de bedrijfsvoering geen (serieuze) last van hebben.

Prioriteren volgens het Bulk en Gedonder-kwadrant heeft twee belangrijke voordelen. Allereerst zal een stakeholder, wanneer hij graag wil dat een requirement een hogere prioriteit krijgt, moeten kunnen aantonen dat, door niet te voldoen aan dat requirement, de gebruikerspopulatie er last van kan hebben of dat de zaak gaat escaleren. Aangeven dat iets een must is op basis van machtspositie of hard roepen, gaat nu niet op.

"Een ander voordeel is dat er geen reden is om over prioriteiten te onderhandelen en compromissen te sluiten; het is nu duidelijk waar de werkelijke risico’s liggen als het gaat om het behalen van succes. De ervaring leert dat stakeholders met elkaar goed in staat zijn te bepalen wanneer er sprake is van onacceptabel veel gebruikers op de Bulk-as. Tevens zijn ze in staat een hele reële inschatting te maken wanneer er sprake is van escalatie. Door het groepsproces ontstaat een open discussie over consequenties, projectdoelstellingen en het behalen van de business case."

Lemaire geeft aan dat de verdeling van de requirements over de drie verschillende prioriteiten vaak als volgt is: 50% van de requirements heeft prioriteit 2, prioriteit 1 en 3 geldt voor elk 25% van de requirements.

Bron: Bulk en Gedonder-kwadrant kan uitkomst bieden, Basile Lemaire, in: Computable 07/10/2011