Iedereen komt het tegen: projecten die ver over het budget heen gaan, veel te laat wor-den opgeleverd en dan ook nog zonder dat de gewenste functionaliteit wordt gerealiseerd.Waar komt dat door? In het eerste artikel in deze reeks hebben we het al gehad over de Big Hitters voor succesvolle projecten. Het lijkt vanzelfsprekend, maar toch is het de oor-zaak van veel problemen in projecten: een onduidelijk of verkeerd doel. Hierdoor ont-staat het risico dat de requirements, de eisen aan de oplossing van het probleem, niet op de juiste of sterk wijzigende uitgangspunten zijn gebaseerd. Je realiseert dan met succes de verkeerde verandering, of de realisatie komt nooit af. Heb je daarmee je doel bereikt?Dit artikel gaat over succes: het verzilveren van kansen, oplossen van problemen en be-halen van de juiste doelen. Vind de kansDe behoefte tot verandering ontstaat wanneer een pro-bleem of kans wordt ontdekt. De opdrachtgever is de persoon die de opdracht moet geven om het probleem op te lossen of de kans te verzilveren. De opdracht wordt gegeven aan een projectmanager of in het ideale geval aan een business analist voor een vooronderzoek.

Het is nu de kunst om de juiste doelstelling voor het pro-ject te formuleren. Alleen dan wordt een project een suc-ces. Maar dat is eenvoudiger gezegd dan gedaan. Welke problemen kom je zoal tegen?Allereerst wordt er in de praktijk onvoldoende tijd be-steed aan de analyse van het probleem. Wat moeten we

Requirements Engineering

32 XR Magazine januari 2012

Successen in een project…

Jan Willem Knop

…bereik je doelen met requirements!

Dit artikel is deel 3 in een reeks van vijf artikelen over succesvol requirements engineering. In het vo-

rige deel hebben we gezien hoe je complexiteit en pragmatiek op elkaar kan afstemmen om require-

ments succesvol in te zetten. Door het requirements engineering proces goed te organiseren en prag-

matisch in te steken kan je veel knelpunten, die het succes van requirements bedreigen, voorkomen. In

dit artikel besteden we aandacht aan een volgend aandachtspunt, namelijk “start met het probleem”.

Figuur 1: Problemen bij requirements engineering

Reageren op dit artikel? Klik hier.

de overige betrokkenen bij de verandering, bestaat het risico dat de oplossing van de opdrachtgever klakkeloos uitgevoerd wordt. Hierdoor krijgt de opdrachtgever niet de oplossing die hij nodig heeft, maar de oplossing die hij wil. De kans is groot dat de doelstellingen hier niet mee bereikt worden. Zo laat ook het voorbeeld zien met de auto (zie kader ‘Doel en middel’), waarbij een alter-natieve oplossing beter bijdraagt aan het succes van het project dan het initieel gestelde doel.

De goede opdrachtgever… is het halve werkEen ander veel voorkomend probleem is dat de op-drachtgever niet altijd degene is die eigenaar is van het probleem of verantwoordelijk is voor het verzilveren van de kans. Zijn belang bij het probleem is daardoor minder groot als van diegene die het probleem daadwerkelijk dagelijks ervaart. Hierdoor ontstaat de kans dat het ei-genlijke probleem niet binnen het project geadresseerd wordt. Neem het voorbeeld ‘Klachten van klanten’.

nu eigenlijk precies oplossen? Deze ‘haast’ zit in de aard van de mens. Wij zijn van nature geneigd om meteen met oplos-singen aan te komen voordat we het probleem volledig door-grond hebben.Het is dus belangrijk om niet te starten met een project voordat de kans of het probleem en de bijbehorende doelstelling en oplossingsrichting helder is. Ga daarom bij je belanghebben-denanalyse ook op zoek naar degenen die verantwoordelijk zijn, die probleemeigenaar zijn, of die het meest geraakt worden door het probleem. Deze per-sonen moeten vervolgens ook als belanghebbende bij requi-rements engineering worden betrokken.Daarnaast geeft de opdrachtge-ver bij het verstrekken van de opdracht niet altijd goed weer wat de kans of zijn probleem precies is. Daar zijn verschillende oorzaken voor. Om te beginnen is er natuurlijk het algemene probleem van communicatie. Mensen die betrokken zijn in een pro-ject begrijpen elkaar niet altijd even goed. Zeker in de software industrie, waar opdrachtgevers aan de business kant en opdrachtnemers in de IT (afdeling of leverancier) vaak verschillende werelden vertegenwoordigen is dit een probleem. Opdrachtgevers hebben bovendien vaak de neiging om in oplossingen te denken. Maar hoe komt het nu dat het voor een opdrachtgever makkelijker is om oplossingen te formuleren dan doelstellingen? Dit wordt met name veroorzaakt doordat doelen abstracter zijn dan op-lossingen. Een auto is veel tast-baarder dan het afleggen van de afstand tussen twee punten door 20 personen. Vandaar dat de opdrachtgever door de requirements engineer geholpen kan worden bij het formuleren van juiste en volledige doelstellingen.Zoals we hebben kunnen zien geven opdrachtgevers in de praktijk vaak opdracht voor het realiseren van een be-paalde oplossing, in plaats van een doelstelling. Het be-denken van de oplossing is echter de verantwoordelijk-heid van domeinexperts. Dit zijn de belanghebbenden. Omdat de opdrachtgever vaak hoger in hiërarchie is dan

33januari 2012 XR Magazine

Figuur 2: Aandachtspunten voor succesvol requirements engineering

Albert Einstein: “If I had one hour to save the world I would spend fifty-five

minutes defining the problem and only five minutes finding the solution.”

Organiseerje proces

Leg require-ments vast

Start methet probleem

Weespragmatisch

Betrek debusiness

Succesvolrequirementsengineering

Kritisch doorvragen zorgt ervoor dat je het probleem achter het symptoom of de oplossing leert kennen. En daarmee ook de eigenaar van het echte probleem. Je loopt echter ook een gevaar wanneer je alsmaar door blijft vragen naar de bron van het probleem en naar re-quirements. Want uiteindelijk wil je naar een oplossing toe. En sommige symptomen vragen om een onmiddel-lijke, misschien niet-optimale oplossing. Je moet daarom in de zoektocht naar het achterliggende probleem ook weten wanneer je moet stoppen met het stellen van de ‘waarom’-vraag. Ieder antwoord dat een belanghebben-de geeft op die vraag moet worden bekeken aan de hand van een aantal criteria:• Geeft de belanghebbende de diepere oorzaak of al-

leen een andere vorm van hetzelfde probleem?• Wanneer je het probleem achter het probleem vindt

kan dat laatste (de bron) groter zijn dan het oorspron-kelijke probleem. Vraag je voortdurend af: “Weegt het oplossen van het bronprobleem echt op tegen het bestrijden van het symptoom?”

Op enig moment moet je dus kunnen vaststellen dat het stellen van de ‘waarom’-vraag niets meer oplevert. Dan ben je aangeland bij het probleem dat je kunt gaan aan-pakken. Daarmee weet je ook wie de opdrachtgever zou moeten zijn. Wanneer dat een andere is dan nu in een stuurgroep zit, dan moet je dus om verandering vragen.Een requirements engineer moet dus stevig in zijn schoe-nen staan. Want het zal niet altijd voor iedereen duidelijk zijn dat de investering die je vroegtijdig in een project wilt doen om doelstellingen helder te formuleren zichzelf gaat terugverdienen.

Van problemen naar requirements (en oplossingen)Samenvattend kunnen we dus opmerken dat het belang-rijk is om de probleemeigenaren vroegtijdig te betrek-ken bij requirements engineering en tot de kern van het eigenlijke probleem te komen, voordat de volgende stap op de weg genomen wordt: het formuleren van de doel-stelling.

34 XR Magazine januari 2012

Bij een verzekeraar wil de manager van de polisad-ministratie de doorlooptijd van het afsluiten van een (zorg)verzekeringspolis verlagen. Reden daarvoor is een richtlijn dat een polis uiterlijk tien dagen na de ontvangst van de aanvraag bij de klant moet liggen. Vooronderzoek had uitgewezen dat die norm niet al-tijd gehaald werd en dus werd door de manager een project gestart om de tiendagentermijn weer structu-reel te maken.

Uit de probleemanalyse bleek echter dat er minimaal twee belangrijkere aanleidingen zijn voor het ver-korten van de doorlooptijd van een verzekeringsaan-vraag:• In het huidige internettijdperk zijn klanten ge-

wend om direct geholpen te worden. Een klant maakt geen onderscheid tussen zorgverzekering of een autoverzekering. Die laatste is binnen en-kele minuten af te sluiten. Een doorlooptijd van twee dagen wordt gezien als het maximum.

• In het call center worden te veel klachten ontvan-gen over het te laat leveren van de polis. Klanten worden ongeduldig en bellen dan op om te vra-gen waar de polis blijft. Dit soort telefoontjes is voor de verzekeraar zeer duur. De eerder gestel-de limiet is dus belangrijk om de verwachtingen helder te krijgen. Vanuit bezuinigingsoogpunt heeft het call center al een taakstelling voor vol-gend jaar zodat flink op de FTE’s moet worden bezuinigd.

Klachten van klanten

De juiste doelstelling is hier dus belangrijk. De ma-nager van de polisadministratie draagt echter niet de verantwoordelijkheid hiervoor en wil hieraan het bud-get niet besteden.

Dat probleem had kunnen worden opgelost door een andere opdrachtgever aan te stellen:• de manager van het call center, die al bij voorbaat

gekort was op het aantal FTE’s in verband met de beoogde verlaging van het aantal telefoonge-sprekken. Die had er dus veel meer belang bij dat de telefoontjes echt niet meer zouden komen;

• of de marketeer, die direct liet weten dat markt-onderzoeken hebben duidelijk gemaakt dat in het huidige internettijdperk klanten voor het aanleve-ren van een polis een termijn van maximaal twee dagen nog acceptabel vinden.

Gevolg: een jaar later was de klanttevredenheid ge-daald, omdat de wachttijden bij het call center langer waren geworden. De doorlooptijd was nu wel binnen de (oude) richtlijn maar doordat die niet voldeed aan de verwachting van de klant, kwamen er nog steeds veel telefoontjes. Die moesten echter door minder mensen worden afgehandeld…

Reageren op dit artikel? Klik hier.

Het gebrek aan doelstellingen is vaak te wijten aan de opdrachtgever die vaak niet goed weet te verwoorden wat de opdracht voor het project nu eigenlijk is. In de praktijk worden regelmatig doelen en oplossingen met elkaar verward. Tijdens onze requirements engineering trainingen geven we vaak de case ‘Doel en middel’.

Zoek de oplossing binnen de grenzenRequirements opstellen is uiteraard geen doel op zich, ook al heb je het doel van het product goed voor ogen. Uiteindelijk willen we toch maar een ding: een oplossing voor het probleem. Daarbij helpen goede requirements met de juiste doelstelling uiteraard wel. Want require-ments geven de grenzen aan waarbinnen alternatieve oplossingen gezocht kunnen worden. Als een opdracht-gever de opdracht geeft om een oplossing te bouwen waarmee de afstand tussen twee punten kan worden overbrugd, en de belanghebbenden geven aan dat er 20 personen moeten kunnen worden vervoerd,dan zijn binnen de grenzen van deze twee requirements meer-dere oplossingen mogelijk, zoals een autobus, twintig fietsen, vijf 4-persoons auto’s, lopen, openbaar vervoer et cetera.Naarmate er meer requirements van andere belang-hebbenden worden geïnventariseerd, zal het aantal mo-gelijke oplossingen verder afnemen. Als een belang-hebbende bijvoorbeeld het requirement toevoegt: ‘het vervoermiddel dient met een snelheid van ten minste 120 km per uur personen te kunnen vervoeren’, dan valt de fiets als oplossing af. Wel is het altijd verstandig na te gaan wat het achterliggende doel van dit requirement is en hoe noodzakelijk die is. Is het niet echt nodig, dan kunnen ook andere oplossingen, dus ook de fiets, weer in beeld komen.Op deze manier is het starten bij het doel zoals we eerder betoogden de leidraad geworden bij het vinden van de juiste oplossing. Door problemen goed te analyseren, de juiste en volledige doelstellingen te formuleren, kom je dus tot de juiste oplossing voor je eigenlijke probleem.

Wat zijn de gevolgen van ‘start met het doel’: bijsturen i.p.v. koers houdenOplossing en probleem uit elkaar houden is dus voor de requirements engineer een belangrijke activiteit. Door het doel helder en expliciet te beschrijven krijgen we de informatie die we nodig hebben voor het sturen van een project. Doelen hebben we nodig om het doel van je pro-ject te halen. Maar ook omdat je tijdens een project er-achter zult komen dat de wereld om het project heen aan het veranderen is. Ieder project krijgt daarmee te maken. Ga voor jezelf maar eens na: geen enkel projectplan of business case, de startdocumenten van een project vol-gens PRINCE2™, wordt in de praktijk exact zo uitgevoerd als aan het begin van het project bedacht is. Als het doel

35 januari 2012 XR Magazine

Figuur 3: De project manager stuurt bij, maar houdt, ook bij zwaar weer, zijn doel voor ogen

van het project niet helder gedefinieerd is, zal het pro- ject zich wel aanpassen aan de veranderingen eromheen, maar dan rijst de vraag of het project bereikt wat het zou moeten bereiken. Door een doel te hebben en dit continu voor ogen te houden wordt de projectmanager in staat gesteld om het project op koers te houden richting het doel.

Doel en middel Een opdrachtgever geeft de opdracht om een auto te bouwen. Het budget dat de deelnemers krijgen is € 20.000. De deelnemers staan voor de keuze om vragen te stellen over de eisen die aan de auto gesteld worden, of op zoek te gaan naar het pro-bleem achter het probleem tot aan het doel dat de opdrachtgever wil bereiken. Het team dat de juiste vragen stelt komt er achter dat er bepaalde belanghebbenden eisen hebben die conflicteren met de voorgestelde oplossing. Bijvoorbeeld dat de auto 20 personen tegelijkertijd moet kunnen vervoeren. Het team ontdekt dat er misschien wel betere oplossingen zijn om het doel te bereiken: het overbruggen van de afstand tussen twee pun-ten door 20 personen. Een autobus realiseren lukt niet binnen het gestelde budget, het lijkt daarmee een onuitvoerbare opdracht. De oplossing om met de trein te gaan, zat niet in de originele opdracht, maar kan wel snel en goedkoop gerealiseerd wor-den.

Project manager en requirements engineer: een natuurlijke symbioseUit het voorgaande kun je al concluderen dat het bepa-len van het juiste doel van groot belang is voor de pro-ject manager. En de requirements engineer is daarbij de meest aangewezen persoon om het doel te achterhalen. Wanneer we de skills, vaardigheden en middelen van een requirements engineer en een project manager ver-gelijken dan zien we veel overlap. Naar ons idee is het dan ook nodig om een co-leiderschap van deze twee rol-len te organiseren in ieder project. Want waar de requi-rements engineer zich in eerste instantie vooral richt op inhoud en kwaliteit, richt de project manager zich primair op tijd en geld (al is de wereld in werkelijkheid natuur-lijk niet zo zwart-wit). Maar die zaken zijn natuurlijk wel onlosmakelijk met elkaar verbonden. We noemen dat het duivelsvierkant: trek aan een hoek en de andere hebben de neiging om mee te bewegen. Door het co-leiderschap leiden project manager en re-quirements engineer ieder project naar het doel waar we een project voor optuigen: het leveren van de maximale waarde voor de business, voor de tijd, geld en resources die je erin investeert. En daarbij is dan zelfs vloeken in de kerk geoorloofd: niet altijd is tijd of geld leidend in het bereiken van de juiste koers. Neem bijvoorbeeld de film “Titanic”. Veel te laat opgeleverd, veel te duur maar het succes was uiteindelijk wel zo groot dat het een van de best bezochte films aller tijden is geworden en de film 11 Oscars won. Een project manager die stuurt op tijd en geld moet door een requirements engineer op koers worden gehouden als het gaat om de doelen en de kwaliteit. Andersom geldt dat natuurlijk net zo. Door die samenwerking kan het duivelsvierkant echt in de hand worden gehouden.

Figuur 4: Duivelsvierkant PM en RE

Jan Willem Knop is als Product Manager / Consultant werkzaam bij Valori.www.valori.nl

36 XR Magazine januari 2012

Precies volgens plan!Dit artikel is gebaseerd op het boek ‘Precies vol-gens Plan!’ geschreven door Mark Hoogveld, Jan Willem Knop en Marcel Schaar. Eerder verscheen in dit blad het artikel: “Requirements zijn de Big Hitter…” waarin het boek wordt geïntroduceerd. In het boek ‘Precies volgens Plan!’ (ISBN-13: 9789012583060) geven we meer concrete tips en adviezen waardoor requirements engineering succesvol uitgevoerd en geïmplementeerd kan worden in een organisatie. In iedere organisatie! En uiteindelijk is ‘succesvol’ requirements engi-neering vooral ook een kwestie van keuzes maken die passen bij jouw orga-nisatie. Die keuzes maak je met al de mensen die het moeten doen. Requi-rements engineering is tenslotte mensenwerk.Ben je door het lezen van dit artikel benieuwd naar de andere tips in het boek, neem dan contact op met Valori of ga naar www.valori.nl.

Reageren op dit artikel? Klik hier.

Het duivelsvierkant

KwaliteitInhoud

Doorlooptijd Middelen