Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Bulk en Gedonder-kwadrant kan uitkomst bieden

Prioriteer requirements en bevindingen op basis van bedrijfsrisico’s

‘Wie het hardst roept, bepaalt de prioriteit!’ Projecten doen, is keuzes maken: wat is er te realiseren met het beschikbare budget en binnen de beschikbaar gestelde tijd? Hoeveel kosten en moeite gaan we steken in het testproces om problemen in productie te voorkomen? Mijn ervaring is dat het stellen van prioriteiten binnen projecten een serieuze uitdaging is.

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. In dit artikel wil ik je een instrument aanreiken dat deze problemen oplost: het Bulk & Gedonder kwadrant.

MSHR of ‘Migratie SAP HR' was een programma voor de ontwikkeling en implementatie van één personeelssysteem en salarisadministratie voor vijf ministeries. Dit was een omvangrijk en complex programma met veel stakeholders en veel verschillende belangen. Het was een worsteling om steeds weer de juiste prioriteiten te stellen bij issues van een vaak onderling onvergelijkbaar karakter. Het volgende voorbeeld illustreert dat.

De nieuwe salarisstrook bleek standaard niet meer dan twee persoonlijke titels weer te geven. Sommige onderdelen binnen het Rijk bleken daar gevoelig voor te zijn. Tegelijkertijd waren er problemen met de juiste berekening van salarissen. Het structureel afwegen van de issues was lastig omdat daartoe nog niet voorzien was van een concreet kader.

Ik achtte het belangrijk dat die onderdelen met het grootste afbreukrisico voor de bedrijfsvoering zondermeer de meeste aandacht moesten krijgen. Ofwel: hoe meer ‘last' je van een disfunctionerend onderdeel in je bedrijfsvoering hebt, hoe hoger de prioriteit moet zijn. Ik ben daarop op zoek gegaan naar methoden om prioriteit te stellen aan requirements en in het kielzog daarvan aan bevindingen. Twee gangbare methoden voor prioritering, MoSCoW en TMap's productrisicoanalyse, passeerden de revue. Omdat deze niet helemaal voldeden aan de behoefte, kreeg ik bij MSHR de kans om een nieuwe methode, het Bulk & Gedonder kwadrant, te implementeren.

MoSCoW

De MoSCoW methodiek (Clegg, D., R. Barker, CASE Method Fast-Track: A RAD Approach, Oracle UK Consulting, 1994) wordt veel gebruikt binnen de business analyse om aan ieder requirement een prioriteit toe te kennen. De term staat voor:

• Must have: dit requirement is noodzakelijk voor projectsucces.
• Should have: dit 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.
• Could have: niet belangrijk voor succes; mee te nemen als het weinig kost en wel veel oplevert.
• Won't have: dit draagt weinig bij aan succes of is weinig rendabel en wordt in ieder geval niet nu geïmplementeerd.

MoSCoW is op zich een prima methodiek. Het is eenvoudig en het gaat om prioriteiten bezien vanuit de bedrijfsvoering. Er kleven echter drie potentiële nadelen aan de toepassing. Ten eerste is er niet zondermeer 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. Ten tweede bestaat het gevaar voor ‘trade-offs' of compromissen: ik ga mee met jouw must-have voor dit requirement als jij meegaat met mijn must-have voor dat requirement. Tot slot komt het voor 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.

PRA volgens TMap

Een Productrisicoanalyse (PRA) heeft tot doel om tot een beeld te komen van de risicovolle kenmerken van een te testen (deel)product. Hoe hoger het risico, hoe grondiger het onderdeel getest moet worden . Het risico wordt daarbij bepaald als ‘faalkans x schade'. Vervolgens wordt de faalkans bepaald als ‘foutkans x gebruiksfrequentie'. De PRA is daarmee behoorlijk complex met veel variabelen en een tabel binnen een tabel. Binnen deze complexiteit gaat het vervolgens toch om vooral inschattingen, bijvoorbeeld: de verwachte schade is of hoog of middel of laag. Een ander probleem is dat TMap (TMap Next voor resultaatgericht testen, Uitgeverij Tutein Nolthenius, 2006) voor de PRA uitgaat van it-risico's. Zo wordt de foutkans bepaald op basis van systeemfuncties en inschattingen door ontwikkelaars of testers. Daarmee is PRA minder geschikt als instrument voor het bepalen van risico's voor de bedrijfsvoering.

Bulk & Gedonder

Er is dus behoefte aan een methodiek die vanuit de bedrijfsvoering op een eenvoudige, transparante manier kan prioriteren terwijl eventueel ‘machtsmisbruik' wordt tegengegaan. Het Bulk & Gedonder kwadrant geeft invulling aan die behoefte. 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').

Ieder requirement kent nu een prioriteit 1, 2 of 3, waarbij:

• Prio 1 betekent: dit requirement moet correct geïmplementeerd en grondig getest zijn. Indien (nog) niet correct geïmplementeerd, is de consequentie dat de volgende projectfase, of de in productie name, moet worden uitgesteld.
• Prio 2 betekent: dit 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.
• Prio 3 betekent: dit mag onder tijdsdruk of bij budgetbeperkingen sneuvelen; hier gaat men vanuit de bedrijfsvoering geen (serieuze) last van hebben.

Stel dat een stakeholder van mening is dat een requirement een hogere prioriteit moet hebben. Hij zal 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. Doorgaans ontstaat er een verdeling van ongeveer 25% met prioriteit 1, 50 procent prioriteit 2 en 25 procent prioriteit 3.

MSHR

Terug naar het voorbeeld van MSHR. Laten we de issues van toen eens plaatsen in het licht van het kwadrant. Zou een limiet aan het aantal op te voeren titels per persoon tot last zijn van een groot deel van de populatie? Of zou een persoon die niet al zijn titels kan opvoeren hierover escaleren? Het aantal op te voeren titels kent duidelijk een prioriteit 3. Daarnaast waren er de incorrecte salarisberekeningen. Dit raakt zoveel mensen en zal zeker escaleren en kent derhalve een prioriteit 1. Voor een ander concreet voorbeeld over de toepassing van Bulk & Gedonder kwadrant, zie het kader met een casus van de Gemeente Rotterdam.

Het Kwadrant heeft MSHR geholpen in hun focus op de kern van hun HR systeemimplementatie én testtijd en -kosten te beperken. De kracht van het instrument zit ‘m in de eenvoud, de omgekeerde bewijslast en het feit dat er wordt uitgegaan van de bedrijfsvoering. Het zal dan ook niet verbazen dat het Kwadrant sinds de introductie met succes ook bij diverse andere organisaties in gebruik is genomen, zoals: P-Direkt, het Ministerie van Economische Zaken, Landbouw & Innovatie (EL&I), Fortis ASR, de Gemeente Rotterdam (zie ook het kader) en Het WaterschapsHuis, het shared service center informatievoorziening van de Waterschappen. Ik kan dan ook iedereen van harte aanbevelen om de Bulk & Gedonder prioritering binnen de eigen veranderomgeving toe te passen.

Basile Lemaire, managing partner Blue Bricks Acceptatie Management

De praktijk bij de Gemeente Rotterdam

Binnen de Gemeente Rotterdam loopt het programma R12-2 voor het uniformeren de erp-processen van de verschillende diensten en het realiseren van één systeem. Bij aanvang van het programma is gekozen om requirements op te stellen en deze te prioriteren met behulp van het Kwadrant. De van de requirements afgeleide ontwerpen en testcases zijn eveneens geprioriteerd. Voor het opstellen van de requirements zijn, per functioneel domein, werkgroepen geformeerd. In iedere werkgroep zitten (sleutel)gebruikers die de verschillende diensten binnen de gemeente Rotterdam vertegenwoordigen. Samen met de werkgroepen heb ik de behoefte geïnventariseerd, deze vertaald naar requirements en door de werkgroep laten voorzien van prioriteit.

Het bepalen van de prioriteit is een interessante exercitie. Het zorgt voor de nodige onderlinge discussie. Wat mij opvalt, is dat werkgroepleden aanvankelijk alles belangrijk vinden. Mijn indruk is dat men vooral een prioriteit 1 wil toekennen uit angst voor het mislopen van bepaalde functionaliteit. Wat ook opvalt, is dat een requirement voor het ene werkgroeplid belangrijker is dan voor een ander; er wordt vaak gekeken naar hoe belangrijk het requirement is voor de eigen dienst in plaats van voor de hele gemeente. Belangrijk is in ieder geval het doorvragen aan de hand van het Kwadrant. Hoeveel mensen hebben er nu echt last van? Waarom zou dit gaan escaleren en naar wie dan? Door middel van dergelijke vragen is er goed tot een eenduidige prioriteitstelling te komen waar iedereen achter staat.
Per systeemonderdeel heeft het prioriteren een dagdeel in beslag genomen. Door de tijd te nemen hebben we bereikt dat het programma bezig is met de zaken die écht belangrijk zijn voor de gemeente als geheel. Tevens is er begrip ontstaan tussen de verschillende diensten voor elkaars belangen en manier van werken. Dit heeft weer zijn voordelen gehad in de keuzes die gemaakt zijn ten aanzien van geüniformeerde procesontwerpen en systeemimplementaties. Gedurende het programma geven de B&G prioriteiten board en bestuurders handvatten voor sturing. In principe hoeven zij alleen geïnformeerd te worden over de status van de requirements met prioriteit 1.

Peter Mathôt, business acceptatie consultant

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Een leuk artikel dat laat zien dat problemen en oplossingen generiek zijn. Het Bulk & Gedonder systeem wordt onder de naam Piep & Knijp ook gebruikt binnen het beheer. Quadrant Piep(ers) bevat de incidenten met een lage prioriteit. Quadrant Knijp(end) de incidenten met de hoogste prioriteit.

Deze eenvoudige indeling voorkomt dat je 'als een kip zonder kop' achter alle ongemakken in de ICT aan gaat lopen.

Complimenten met dit artikel.

Ik heb het met plezier gelezen. Bij gelegenheid kan ik de werkwijze direct toepassen. Ik mocht willen dat er meer van zulke artikelen verschijnen.

Complimenten! Een goed leesbaar en helder artikel over een onderwerp waar in de praktijk van de testmanager inderdaad het "bewezen" model (PRA) zo complex is voor stakeholders dat het een heldere prioritering vaak in de weg staat. MoSCoW is een stuk intuitiever voor leken, maar mist inderdaad een objectief normkader. Ik vind dit een mooie tussenvorm: simpel toepasbaar en goed doordacht, zoals dat hoort bij een goed theoretisch kader.

Grappig verhaal... zelfs ik als die hard techneut snap het.

Allen, dank voor de reacties. Het is voor een auteur altijd prettig om feedback te krijgen. Complimenten zijn daarbij natuurlijk extra mooi. Ik hoop dat B&G jullie in jullie werkpraktijk zal helpen.

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.