PRM: Product Risk Management - Deel 3: Mitigatie

Mijn vorige blog ging over PRM (Product Risico Management) en het kwantificeren van het
product risico.

Daarbij ben ik tot de conclusie gekomen dat PRM een zinvolle bijdrage kan leveren aan de
business en dat het product risico voldoende goed te kwantificeren valt om bruikbaar te zijn
als rechtvaardiging om aan PRM te gaan doen.

In deze blog start ik de discussie over de invulling van Product Risico Management.

Definitie: Product Risico = de schade, die het product de business kan aandoen.

Product Risico Mitigatie

Er is een specifieke discipline, die heel goed ingezet kan worden als 'Product Risico
verzekering': de discipline Testen. Daarbij zou de teststrategie en de testaanpak gebaseerd
moeten worden op een goede Product Risico Analyse. Daarbij moet je voornamelijk uitgaan
van de product risico analyse vanuit het business perspectief.

De business gebaseerde product risico analyse kan binnen het project goed aangevuld worden
met een technische product risico analyse, gebaseerd op de technologische risico's. De
inmiddels al wat oudere testmethode RRBT: ('Risk and Requirements Based Testing',
"Successful Test Management: An Integral Approach", Iris Pinkster) en ook sinds kort ook
Tmap-Next met RBT ('Risk Based Testing') bieden handvaten voor de analyse van
technologische risico's.

Met name Tmap mist een echte en specifiek op de Business gerichte Product Risk Analyse
aanpak.
Binnen RRBT is er in zekere mate aandacht voor een business gerichte product risico
benadering. Dit slechts vanuit het perspectief van een testproject, en niet vanuit het
permanente perspectief, dat voor een specifieke in de business belegde verantwoordelijkheid
noodzakelijk is.

Interessant is dat er recent een TestNet werkgroep is opgericht met juist dit onderwerp:
Product Risk Based Testen

 Business gebaseerde Product Risico Analyse valt buiten het project, dit is een
belangrijk onderdeel van Product Risico Management
 Op de applicatie gebaseerde Product Risico Analyse valt binnen het project; dit is dus
geen onderdeel van Product Risico Management

Loont het?
Interessant is te weten: wanneer loont het om een gestructureerd en professioneel testtraject
op te zetten?
Stel: een beetje professioneel testtraject kost zo'n 200.000,- €.
Rekenen wij met een gemiddelde van 50.000,- € aan directe schade per showstopper, dan
betekend dit dat je bij vier showstoppers break-even speelt.

Testers weten heel goed dat bij een beetje testtraject doorgaans tussen de 10 en 20 serieuze
showstoppers aan het licht komen.

Het geeft beslist een leuke discussie als je als testmanager het break-even punt in je
voortgangsrapportage vermeld... En waarschijnlijk leidt die discussie tot commerciële
mogelijkheden.

Hoeveel winst kan er gemaakt worden? Ook dat valt simpel te berekenen. Laten wij uitgaan
van 10 showstoppers en de kosten van het testtraject zijn 200.000,- €. De kosten voor het
fixen stellen wij even op 1.500 €
Als wij vanuit dit perspectief alleen naar de directe schade kijken, dan komen wij op directe
schade = 10 * 7500 € * 8 h = 600.000 €.
Met testen bespaar je dan 10 x (60.000 € - 1.500 €) - 200.000 € = 385.000 € (winst).

PRM = Product Risico Mitigatie Organiseren

Waar zou je Testen als product risico Mitigatie dan organisatorisch moeten 'ophangen'?

Zoals ik in mijn eerdere blog heb gesteld: Product Risico Management is een onderdeel van
Business Risk. Strikt gezien is het product risico dus geen zorg van het project - tenzij het dat
expliciet wordt gemaakt. Product Risico Mitigatie niet wordt opgenomen in de scope van het
project. Testen als product risico Mitigatie moet dan ook niet binnen een project worden
gepositioneerd.

De oplossing ligt voor de hand: hang Testen organisatorisch onafhankelijk op buiten het
project en direct onder de verantwoordelijkheid van het Project Board. Concreet: plaats de
TestManager organisatorisch naast de Projectmanager en laat de TestManager direct aan de
Project Board rapporteren. De missie van de TestManager om de Product Risico's te
mitigeren staat dan naast de missie van de Projectmanager, diens missie het is om het product
binnen afgesproken kwaliteit, budget, tijd en scope op te leveren.

Hangt men Testen toch op binnen project, dan moet de volgende redenering worden gevolgd:
Product Risk Based Testen valt in principe buiten de scope van het project; Testen binnen het
project kan onvoldoende worden gebaseerd op een strategie van Product Risico Mitigatie
want dit valt immers buiten de scope van het project.

Een gezonde mengvorm zou ook kunnen zijn: Het mitigeren van het Product Risico expliciet
meegeven als opdracht aan het project in de Project Brief en daarmee beleggen binnen de
verantwoordelijkheid van het project.

Value Based Pricing

Een interessante vraag is: valt er een testtraject te verkopen op basis van de waarde, die testen
heeft?
De vraagstelling is relevant omdat wij nu de waarde van testen kunnen berekenen en
kwantificeren in harde euro's.
Stel dat wij 'slechts' een enkel procent van die waarde vragen - wat zou dat kunnen
opleveren?

Voorkomen directe schade: 10 Issues x 8 h x 7,500 €  =          600.000 €

Voorkomen indirecte schade: 10 Issues x 3,000,000 € =      30.000.000 €
Voorkomen reputatie schade: buiten beschouwing
                                                                             totaal          30.600.000 €
                                                                             ----------------------------------
                                                                                 1%  is          306.000 €
                                                     Minus kosten testtraject          200.000 €
                                                                            ----------------------------------
                                                                                 Winst          106.000 €

Conclusie
De kosten van 'testen' zijn vanuit het perspectief van product risico management en vanuit het
perspectief van waarde veel beter te verantwoorden dan vanuit het perspectief van een extra
kostenpost, die doorgaans als sluitstuk van de begroting per definitie onder vuur komt te
liggen.

 Product Risico Management loont

 Product Risico Management biedt de mogelijkheid om met de business op gelijk
niveau te spreken over testen
 Product Risico Management lukt alleen goed als je het organisatorisch buiten het
project ophangt, maar mengvormen zijn denkbaar.
 Product Risico Management biedt een basis voor creatieve pricing methodes

In deze drie opeenvolgende blogs heb ik laten zien dat het strategisch managen van product
risico's vanuit business perspectief een zinvolle investering is en heel goed met bestaande
kennis en kunde te realiseren is.

Ik hoop hiermee een discussie op gang te brengen over een specifiek aspect van risico 
management: dat van het specifiek managen van product risico's en de waarde, die deze
activiteit voor de business voor de business heeft.