Het artikel geeft handvatten hoe organisaties grip kunnen krijgen op projecten door het goed beheren van requirements

1. FINANCE
& CONTROL
Management control
Me thodie k opste ll e n e n be he re n va n re quire me nt s
requirements excellence een
businessfeestje?
Vanuit control-optiek is het een hele toer om goed grip te krijgen op projecten. Levert het project de juiste
en gewenste resultaten? Hoe weet u of er tijdens de duur van het project niet allerlei wijzigingen nodig
zullen zijn en hoe krijgt u daar vat op? Volgens de auteurs zijn organisaties beter in control door het
toepassen van de methodiek van ‘requirements excellence’. Zij beschrijven de voorwaarden die een grote
rol spelen bij het beheren van requirements.
D o o r Hil c o ta PPe l , je r o e n o oY e Va a r e n a n ge l a a bD o e l H a f ie Z K H a n
Z owel commerciële afdelingen als de diverse stafafdelingen
leveren hun eisen en wensen (requirements) op dezelfde
eisen en behoeftes in beeld krijgen en niet alle stakeholders
betrekken? Hoe komt het dat de verschillende stakeholders
manier aan, waardoor overeenkomsten en verschillen sneller niet dezelfde taal spreken? En hoe komt het dat we gedurende
onderkend worden. Door requirements te koppelen aan de uitvoering van projecten onvoldoende grip hebben op
enerzijds de bron en anderzijds processtappen, wordt het voortschrijdende inzichten, lees veranderingen van eisen en
eigenaarschap geregeld. Door de requirements goed te admi- behoeften? Het lijkt erop dat de noodzaak om op een goede,
nistreren, wordt de impact van de mutaties direct inzichtelijk professionele wijze de eisen en behoeftes in beeld te krijgen,
en kan een significant deel van de bestaande requirements vast te leggen en te beheren vaak onderschat wordt. Het vak-
hergebruikt worden, wat winst kan opleveren. gebied van requirements engineering en management biedt
mogelijkheden, zoals we in dit artikel zullen aantonen. We
Bij de term requirements is vaak de eerste associatie dat hij hebben accenten gelegd binnen dit vakgebied en het geheel
IT-gerelateerd is. Deze associatie is onjuist, omdat hij juist noemen we requirements excellence.
alles te maken heeft met de wijze waarop de business struc-
tureel grip blijft houden op zijn eisen en wensen. Wat is een requirement?
In 2009 heeft de Standish Group een internationaal onder- Alvorens verder op de materie in te gaan, zullen we eerst be-
zoek (het Chaosrapport) uitgevoerd naar de faalfactoren van spreken wat we met ‘requirements’ bedoelen. Een requirement
IT-projecten. De drie belangrijkste faalfactoren zijn: te weinig is een uitdrukking van een eis of behoefte van een stakehol-
inbreng gebruikers, incomplete requirements en specificaties der. Die eis of behoefte dient bij te dragen aan de doelstellin-
en het niet goed bijhouden van het veranderen van require- gen van de organisatie op strategisch (waarom), tactisch (wat)
ments en specificaties. Het lukt kennelijk nog niet zo goed om of operationeel niveau (hoe), om product-, proces-, organisa-
alle eisen en behoeften (requirements en specificaties) boven tie- en systeemveranderingen mogelijk te maken. De require-
water te krijgen en als we die dan wel hebben, om ze goed in ments dienen duidelijk, consistent, ondubbelzinnig, testbaar
control te houden tijdens de uitvoering van projecten. Dit beschreven en beheerd te worden en moeten afgestemd zijn
roept een aantal vragen op. Hoe komt het dat we niet alle met alle betrokken stakeholders.
augustus 2010 | 15 w w w. f i n a n c e - c o n t r o l . n l

2. FINANCE
&CONTROL
Leuk zo’n definitie over requirements, maar wat is de toege- uw organisatie helpen om projecten succesvoller te maken.
voegde waarde ervan? Met andere woorden: hoe worden de 1. Universele taal. De eisen en behoeften van commercie,
problemen of uitdagingen herkend die veroorzaakt worden maar ook die van risk, compliance, audit en andere staf-
door gebrekkig handelen met die requirements? diensten moeten te vertalen zijn naar één gezamenlijke taal,
namelijk die van requirements. De lijnmanager moet voor-
Waarom requirements? komen dat hij eerst de verschillende talen moet ontleden en
Om erachter te komen of requirements excellence van in overeenstemming moet brengen.
toepassing is op uw organisatie hebben we een aantal situaties 2. Formuleren. Requirements moeten ondubbelzinnig gefor-
op een rij gezet die in min of meerdere mate te maken hebben muleerd worden en dat is al een kunst op zich. Een require-
met ondoelmatig handelen met requirements. ment mag namelijk slechts voor één uitleg vatbaar zijn.
Verder moeten requirements goed gereviewd worden, zodat
Komen de volgende vraagstukken u bekend voor? er niet te snel allerlei wijzigingen op doorgevoerd hoeven te
~ De business wil dat de leverancier aantoont of hij al zijn worden.
businesswensen gaat honoreren, gegeven tijd en geld. De 3. Volledigheid. De set van requirements moet zo volledig als
projectmanagers moeten duidelijker aantonen wat ze van mogelijk worden opgesteld. Betrek alle stakeholders tijdig
de businesswensen wel en niet gaan realiseren. bij het formuleren en toetsen van alle benodigde require-
~ De business wil weten wat de front- en backoffice precies ments. Sterker nog, bij het opzetten van requirements moet
moeten gaan doen met het nieuwe product om het succes- de requirements engineer erop attent gemaakt worden dat
vol te implementeren. hij alle aspecten meeneemt.
4. Relatie naar proces en naar de bron. Requirements moet je
kunnen ‘mappen’ op je processen. Een procesmanager (van
De user requirements vormen vaak frontoffice of backoffice of te outsourcen onderdeel) moet
snel kunnen zien welke requirements in zijn domein vallen.
het startpunt van veranderprocessen Wij zijn van mening dat requirements gerelateerd moeten
worden aan de bron en aan het proces en de daarvoor ver-
antwoordelijke proceseigenaar.
~ De business krijgt het verwijt van de leverancier dat hij de 5. Administreren. Goed requirements-beheer moet leiden tot
requirements weliswaar accordeert, maar dat hij vervolgens kosten- en tijdbesparingen en verhoging van de kwaliteit
allerlei wijzigingen laat doorvoeren. Het lijkt erop dat de van projectresultaten. Dergelijk beheer impliceert ook goe-
business te snel ‘ja en amen’ heeft gezegd. de traceerbaarheid van de diverse soorten requirements.
~ De business wil de commerciële businesswensen, maar ook Die traceerbaarheid geldt voor zowel veranderprocessen
de eisen van compliance risk en audit in een en hetzelfde (projecten en dergelijke) als voor bron (wet- en regelgeving,
document zien zodat de samenhang duidelijk wordt. Met commercie) en proces (operationele processen).
andere woorden: hoe kan bereikt worden dat alle betrokke- 6. Rol. Requirements moeten los van projecten beheerd wor-
nen dezelfde taal spreken? den. De business stelt een functionaris aan die alle require-
~ Hoe kan de business alle requirements overzichtelijk behe- ments in zijn domein beheert.
ren zodat hij iets kan terugvinden en hergebruiken in plaats 7. Changeprocessen en requirements. De requirements moeten
van alles steeds weer opnieuw te moeten bedenken? een expliciete plek krijgen bij projecten en change requests,
~ De business wil een deel van zijn proces outsourcen, maar zodat ze snel te traceren zijn.
welke eisen moet hij daaraan stellen en welke stuurinforma-
tie heeft hij daarbij nodig? De genoemde voorwaarden vormen de basis van onze requi-
rements excellence-methodiek.
Om dit soort vragen te kunnen beantwoorden is het noodza-
kelijk dat u in uw organisatie de volgende voorwaarden goed 1. Requirements als universele taal voor vele disciplines
op orde heeft. (commerciële maar ook stafafdelingen). Er bestaan in de
praktijk verschillende soorten requirements, zoals functionele
Voorwaarden en non-functionele requirements, maar ook security,
De volgende voorwaarden spelen een belangrijke rol bij een compliance, audit en commerciële requirements (zie ook
juist gebruik van requirements en het leveren van een bijdra- figuur 1 op de volgende blz.). Wij onderscheiden:
ge aan beheersbare business- en veranderingsprocessen. Als ~ business requirements: omschrijven het ‘waarom’ en het
u deze voorwaarden in uw controlpraktijk herkent, kunt u doel, bijvoorbeeld marktaandeel terugwinnen door kwali-
16 | augustus 2010

3. FINANCE
& CONTROL
teitsverbetering bereikbaarheid en dienstverlening; impact op bijbehorende documentatie, impact op kwaliteits-
~ user requirements: omschrijven het ‘wat’ en wat er vervol- eisen, etc. Juist bij deze user requirements zien we dat de ver-
gens moet gebeuren. Voorbeelden zijn: toename bereik- schillende vakdisciplines bij elkaar komen en het proces com-
baarheid met x%; afnamezoekend telefoonverkeer van x%, plexer wordt. Een voorbeeld: compliance meldt dat in het
binnen 24 uur; kader van wet X de klant zich moet identificeren bij het aan-
~ system requirements: omschrijven het ‘hoe’ en welke oplos- gaan van de overeenkomst. De operationele risk manager
singen mogelijk zijn. Voorbeelden zijn: de helpdeskmede- meldt dat bij het aangaan van overeenkomsten gecontroleerd
werkers moeten elk jaar een cursus klantvriendelijke inter- moet worden of de betreffende klant zich identificeert met
actie volgen, applicatie X moet gebruikers attenderen op een geldig legitimatiebewijs, want in het verleden is dat een
doorlooptijden tussen de 12 en 24 uur, binnen het intake- paar keer misgegaan. De audit manager meldt dat hij graag
proces van werkzoekenden worden eerst alle gegevens ge- key risk controls wil hebben van de lijnmanager die verant-
noteerd en dan pas worden de diensten aangeboden. Sys- woordelijk is voor het afsluiten van overeenkomsten. De rela-
tem requirements gelden overigens niet alleen op tiemanager meldt dat hij alleen bij het aangaan van een over-
applicaties, maar kunnen ook van toepassing zijn op orga- eenkomst een klant wil lastigvallen met de vraag of hij zich
nisatie, producten en processen. wil identificeren. Dit voorbeeld toont aan dat vier disciplines
uiteindelijk hetzelfde willen: ‘bij het aangaan van een overeen-
De drie soorten requirements zijn aan elkaar gekoppeld. Pas komst dient de klant zich te identificeren met een geldig iden-
als de waarom-vraag duidelijk is, kunt u zeker zijn of het ‘wat’ titeitsbewijs’. Dit is de gemeenschappelijke user requirement.
goed en volledig is. Een user requirement geeft een gedetai-
leerde beschrijving van het eindproduct. Om deze reden dient 2. Requirements goed en volledig formuleren; een vak
een user requirement altijd gekoppeld te zijn aan een business apart. Er bestaan vele eisen waaraan een goede requirement-
requirement. Organisaties starten regelmatig projecten zonder tekst moet voldoen. Die eisen zijn ontstaan omdat zender en
dat zij de waarom-vraag helder hebben geformuleerd. Een ontvanger van de boodschap exact hetzelfde beeld moeten
businesscase wordt vaak niet opgeleverd. Het gevolg is dat er hebben. Op basis van kennis en praktijkervaringen is een
gedurende de uitvoering vaak wijzigingen in het project aantal richtlijnen gedefinieerd. Denk hierbij aan richtlijnen
gemaakt moeten worden. De opdrachtgever realiseert zich als: elimineer vaagheden, schrijf kort en bondig, hanteer
namelijk dat hij niet duidelijk genoeg is geweest in de afbake- bepaalde zinsopbouw, beperk de woordenschat en omschrijf
ning van het project. Dit leidt tot onnodige vertraging en ex- de behoefte in plaats van de oplossing.
tra kosten. Om dit te voorkomen is het belangrijk om valida-
tiesessies te organiseren met de betrokkenen. 3. De set van requirements moet zo volledig mogelijk zijn.
Een goede requirement-tekst is nog niet voldoende. De hele
Nadat het ‘waarom’ helder is, kan het ‘wat’ worden uitgewerkt. set van requirements moet bepaalde ‘hogere’ behoeftes (voor-
De bijbehorende user requirements bestrijken vele aspecten. beeld klantgerichter werken door sneller en met betere ant-
Denk hierbij aan productaspecten, primaire procesaspecten, woorden op klantvraag te reageren) goed afdekken. Hoe weet
je nu dat je volledig bent? Die zekerheid is niet te geven. Vaak
is er geen tijd om iedereen de requirements te laten reviewen.
Requirements Een oplossing is om met referentiemodellen te werken waarin
alle requirements al geordend worden naar bepaalde groepen.
Waarom
Business De ervaring leert dat het groeperen van requirements naar
requirement producten of documenten of primaire proces of beheerproces
of besturingsproces of kwaliteit een goede start is. Als blijkt
Wat dat er bijvoorbeeld nog geen requirements zijn over kwaliteit,
User dan is de kans groot dat de non-functionele requirements zijn
requirement vergeten. Als blijkt dat er geen requirements zijn over het be-
Business
sturingsproces, dan is de kans groot dat de key performance
OPS/IT indicators (kpi’s) over performance nog niet benoemd zijn.
Hoe
System
requirement
4. Requirements en de relatie naar processen en bronnen.
In figuur 2 op blz. 18 ziet u drie grijze kolommen met daarin
Figuur 1 normenkaders en bronnen, requirements en processen.
Soorten requirements en hun onderlinge relaties Uiteindelijk zullen de normenkaders en bronnen en
augustus 2010 | 17 w w w. f i n a n c e - c o n t r o l . n l

4. FINANCE
&CONTROL
5. Administreren van requirements
Requirements in breder verband
Normenkader & Requirements Processen
bronnen De horizontale en verticale ketens in figuur 3 geven aan dat
er veel onderlinge verbanden zijn. Deze verbanden moeten
Extern Waarom Hoofdproces geadministreerd worden ten behoeve van de traceerbaarheid
wetten Business
& intern van de eisen en behoeftes.
beleid requirement
Naast verbanden met anderen objecten, kent een object ook
veel eigen kenmerken. Denk hierbij aan een uniek nummer,
Wat Wat Wat tekst, status ontwerp, status voortbrengingsproces, risico­
Regel User Processtap
score, etc.
requirement
De requirements moeten beheerd worden per domein, zoals
Business
de afdeling Vergunning bij een overheidsinstantie, de afdeling
OPS/IT Sparen bij een bank, de afdeling Zorgverzekeringen bij een
Hoe
System verzekeraar, etc.
requirement
Requirements en kosten- en tijdsbesparing
Bijna iedere organisatie heeft haar veranderprojecten. De scope
Figuur 2 van te veranderen objecten is vooraf niet altijd duidelijk. Bij­
Requirements in een breder verband tussen normenkaders en voorbeeld bij nieuwe externe regelgeving wordt vaak een wet
bronnen enerzijds en de processen anderzijds als scope van het veranderproject genomen. Ergens in de uit­
voeringsfase ontdekt iemand binnen de organisatie wat nieuw
requirements hun weerslag vinden in de processen. Onder en wat bestaand is. Bestaande oplossingen worden hergebruikt
normenkaders en bronnen verstaan we zaken zoals wet­ en en daarvoor zijn uiteraard geen investeringen nodig. De kunst
regelgeving, maar ook intern beleid. Een wet bestaat uit een is om in een zo vroeg mogelijk stadium te onderkennen wat
set van artikelen, lidnummers en sublidnummers en op het nieuw is en waarvoor mogelijk al bestaande oplossingen voor­
kleinste niveau spreken we van regels. Ook bij beleid zien we handen zijn. Het instrument om hier snel achter te komen zijn
op het kleinste niveau alinea’s tekst die we regels noemen. requirements. Aan de hand van een compliance­voorbeeld in
Die regels zijn opgesteld in juridische of beleidstaal en moeten figuur 4 laten we zien dat bij introductie van een nieuwe wet
omgezet worden naar requirements. Die requirements relate­ snel duidelijk is welke requirements al aanwezig zijn en welke
ren we vervolgens aan bepaalde processtappen binnen een nieuw zijn en dus in de projectscope vallen. Hierdoor wordt
proces. Andersom: een proceseigenaar wil weten welke requi­ aanzienlijk bespaard op kosten en tijd.
rements en dus regels van toepassing zijn op zijn proces. Dit
betekent dat er een behoefte is om ‘van links naar rechts’ maar
ook ‘van rechts naar links’ te kunnen zoeken. Waarom
BR Business
Requirement
Figuur 3 bestaat uit een horizontale en verticale keten. Op het
kruispunt van de ketens staan de user requirements. Boven en
onder de user requirements staan de business­ en system requi­ Wat
Wat Wat
UR User Processtap
rements. De relaties hiernaar moeten onderhouden worden. De Regel
Requirement
user requirements vormen vaak het startpunt van veranderpro­
Horizontale keten: relatie tussen vakgebieden in businessdomein
cessen als projecten en change requests. De requirements staan
niet op zichzelf, maar zijn deel van een groter geheel. Links en Hoe
rechts van de user requirements staan respectievelijk de bron­ SR System
nen (bijv. wetgeving en beleid) en de processen. requirement
Vertikale keten:
De relaties van user requirements naar bronnen en processen relatie tussen
business en
moeten goed beheerd worden, anders bent u niet in staat om
ICT bij changes
in detail aan te geven welke wet welke impact heeft op welk zoals projecten
proces. Uiteraard geldt dit ook andersom: waar in het proces
wordt voldaan aan welke wet? Het heeft dus ook een direct Figuur 3
voordeel in de rapportages. User requirements en ketenmanagement
18 | augustus 2010

5. FINANCE
& CONTROL
De verantwoordelijkheid daarvoor ligt bij de business. De
leverancier gaat aan de slag om het ‘wat’ om te zetten in het
Wid Wwft ‘hoe’. In de communicatie tussen business en leverancier is het
belangrijk dat de relatie tussen het ‘wat’ en ‘hoe’ geborgd
Art. 2.1 Art. 3.2
Wetten en regels wordt. De requirements-identificatie moet ook gebruikt
Klantidentificatie Klantidentificatie
Klantonderzoek worden bij de veranderprocessen. In een projectplan moet
bijvoorbeeld de lijst van user requirements in de scope
Requirement Hergebruik Requirement terugkomen. Bij een change request moet de impactanalyse
Requirements 1. ........ 1. ........
een set van unieke requirements zichtbaar maken, die
2. ........ 2. ........
3. ........ onderzocht worden op de impact voor de operations. Dit
4. Nieuw
........ betekent dat requirements een duidelijke plek moeten krijgen
in allerlei document-templates van projecten en beheer. Ook
dient de beheerder van de requirements opgenomen te
Figuur 4 worden in de distributielijsten van de project- en
Kostenbesparing bereiken door het vroegtijdig ontdekken van beheerdocumenten, teneinde de traceerbaarheid te kunnen
mogelijkheden voor hergebruik borgen. Het is de taak van de requirements manager om te
controleren of de leverancier meer of minder levert dan
In de projectmandaatfase wordt mogelijk hergebruik van be- afgesproken. Als de business een koperen kraan wil en de
staande oplossingen vastgesteld. In de projectinitiatiefase leverancier levert een gouden kraan, dan moet dit opgemerkt
worden alleen de nieuwe user requirements meegenomen om worden.
uitgewerkt te worden tot system requirements en aangepaste Ook bij system requirements met impact op processen en or-
processen. Door het hanteren van requirements ontstaat er ganisatie moet worden bijgehouden wat de status is bij de uit-
een expliciete verwachting van het resultaat van een project. voering. Als er een system requirement is die aangeeft dat de
helpdeskmedewerkers elk jaar training x krijgen, dan dient de
6. Requirements inbedden in organisatie. Om requirements statusuitvoering bijgehouden te worden.
excellence (ontwikkelen en beheren) een goede plek te geven
bij de business is een aparte functionaris nodig: de
requirements manager. Deze functionaris heeft als Door het toepassen van requirements
takenpakket:
~ het op niveau krijgen en houden van de kwaliteit van te excellence kan de business een
ontwikkelen requirements;
~ het beheren van de relatie van requirements naar enerzijds antwoord krijgen op vraagstukken
hun bron (voorbeeld wettelijke regels of productinnovatie)
en anderzijds naar de processen;
~ het borgen van de traceerbaarheid van requirements in het Tot slot
voortbrengingsproces (projecten, change requests e.d.), De titel van dit artikel bevat de vraag of een goede opzet en
zodat duidelijk wordt welke goedgekeurde requirements beheer vanrequirements een ‘businessfeestje’ is. Uit onze uit-
welke status hebben; eenzetting moge duidelijk zijn geworden dat de business er
~ het mogelijk maken dat de betrokken lijnmanagers op een zeer veel baat bij heeft om de requirements goed in eigen
eenduidige manier omgaan met wensen en eisen van alle hand te houden. Door het toepassen van requirements excel-
stakeholders (van commerciële afdelingen, maar ook van lence kan de business een antwoord krijgen op de vraagstuk-
stafadelingen zoals risk, compliance, audit e.d.); ken die we beschreven aan het begin van dit artikel. Daar is
~ ervoor zorgen dat conflicterende requirements worden winst te behalen. Daarnaast kan de projectcontroller inzoo-
onderkend en dat er een consistente set van requirements men op die aspecten van requirements (de beschreven voor-
komt. waarden) die het verschil maken tussen een goede en minder
goede aanpak van requirements. Met die kennis heeft de
7. Requirements in veranderprocessen (bij projecten en projectcontroller een handvat om lopende projecten tijdig
beheer). De verticale balk in figuur 3 geeft de verander- bij te sturen.
processen zoals projecten en change requests weer. In het
midden staan de user requirements. Onderdeel van de user Drs. Hilco Tappel, drs. Jeroen Ooyevaar en Angela Abdoelha-
requirements zijn de acceptatiecriteria en testscenario’s. fiezkhan werken als process consultants bij ConQuaestor B.V.
augustus 2010 | 19 w w w. f i n a n c e - c o n t r o l . n l