Artikel

Successen in een project…

…bereik je doelen met requirements!

Dit artikel is deel 3 in een reeks van vijf artikelen over succesvol requirements engineering. In het vorige deel hebben we gezien hoe je complexiteit en pragmatiek op elkaar kan afstemmen om requirements succesvol in te zetten. Door het requirements engineering proces goed te organiseren en pragmatisch 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: Veel voorkomende problemen met requirements engineering

Figuur 2: Aandachtspunten voor succesvol requirements engineering

Iedereen komt het tegen: projecten die ver over het budget heen gaan, veel te laat worden 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 oorzaak van veel problemen in projecten: een onduidelijk of verkeerd doel. Hierdoor ontstaat 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 behalen van de juiste doelen.

Vind de kans

De behoefte tot verandering ontstaat wanneer een probleem 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 project te formuleren. Alleen dan wordt een project een succes. Maar dat is eenvoudiger gezegd dan gedaan. Welke problemen kom je zoal tegen?

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.”

Allereerst wordt er in de praktijk onvoldoende tijd besteed aan de analyse van het probleem. Wat moeten we nu eigenlijk precies oplossen? Deze ‘haast’ zit in de aard van de mens. Wij zijn van nature geneigd om meteen met oplossingen aan te komen voordat we het probleem volledig doorgrond 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 belanghebbendenanalyse ook op zoek naar degenen die verantwoordelijk zijn, die probleemeigenaar zijn, of die het meest geraakt worden door het probleem. Deze personen moeten vervolgens ook als belanghebbende bij requirements engineering worden betrokken.

Daarnaast geeft de opdrachtgever 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 project 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 oplossingen. Een auto is veel tastbaarder 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 bepaalde oplossing, in plaats van een doelstelling. Het bedenken van de oplossing is echter de verantwoordelijkheid van domeinexperts. Dit zijn de belanghebbenden.

Omdat de opdrachtgever vaak hoger in hiërarchie is dan 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 alternatieve oplossing beter bijdraagt aan het succes van het project dan het initieel gestelde doel.

De goede opdrachtgever … is het halve werk

Een ander veel voorkomend probleem is dat de opdrachtgever 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 eigenlijke probleem niet binnen het project geadresseerd wordt. Neem het volgende voorbeeld:

Klachten van klanten

Bij een verzekeraar wil de manager van de polisadministratie 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 altijd gehaald werd en dus werd door de manager een project gestart om de tiendagentermijn weer structureel te maken.

Uit de probleemanalyse bleek echter dat er minimaal twee belangrijkere aanleidingen zijn voor het verkorten van de doorlooptijd van een verzekeringsaanvraag:

  • In het huidige internettijdperk zijn klanten gewend om direct geholpen te worden. Een klant maakt geen onderscheid tussen zorgverzekering of een autoverzekering. Die laatste is binnen enkele minuten af te sluiten. Een doorlooptijd van twee dagen wordt gezien als het maximum.
  • In het call center worden te veel klachten ontvangen over het te laat leveren van de polis. Klanten worden ongeduldig en bellen dan op om te vragen waar de polis blijft. Dit soort telefoontjes is voor de verzekeraar zeer duur. De eerder gestelde limiet is dus belangrijk om de verwachtingen helder te krijgen. Vanuit bezuinigingsoogpunt heeft het call center al een taakstelling voor volgend jaar zodat flink op de FTE’s moet worden bezuinigd.

De juiste doelstelling is hier dus belangrijk. De manager van de polisadministratie draagt echter niet de verantwoordelijkheid hiervoor en wil hieraan het budget 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 telefoongesprekken. Die had er dus veel meer belang bij dat de telefoontjes echt niet meer zouden komen;
  • of de marketeer, die direct liet weten dat marktonderzoeken hebben duidelijk gemaakt dat in het huidige internettijdperk klanten voor het aanleveren van een polis een termijn van maximaal twee dagen nog acceptabel vinden.

Gevolg: een jaar later was de klanttevredenheid gedaald, 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…

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 requirements. Want uiteindelijk wil je naar een oplossing toe. En sommige symptomen vragen om een onmiddellijke, 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 belanghebbende geeft op die vraag moet worden bekeken aan de hand van een aantal criteria:

  • Geeft de belanghebbende de diepere oorzaak of alleen een andere vorm van hetzelfde probleem?
  • Wanneer je het probleem achter het probleem vindt kan dat laatste (de bron) groter zijn dan het oorspronkelijke 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 aanpakken. 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 schoenen 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 belangrijk is om de probleemeigenaren vroegtijdig te betrekken 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 doelstelling.

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 volgende case:

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 probleem 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 punten 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 worden.

Zoek de oplossing binnen de grenzen

Requirements 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 requirements geven de grenzen aan waarbinnen alternatieve oplossingen gezocht kunnen worden. Als een opdrachtgever 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 meerdere oplossingen mogelijk, zoals een autobus, twintig fietsen, vijf 4-persoons auto’s, lopen, openbaar vervoer, et cetera.

Naarmate er meer requirements van andere belanghebbenden worden geïnventariseerd, zal het aantal mogelijke oplossingen verder afnemen. Als een belanghebbende 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 houden

Oplossing 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 project te halen. Maar ook omdat je tijdens een project erachter 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 volgens PRINCE2™, wordt in de praktijk exact zo uitgevoerd als aan het begin van het project bedacht is. Als het doel van het project niet helder gedefinieerd is, zal het project 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.

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

Project manager en requirements engineer: een natuurlijke symbiose

Uit het voorgaande kun je al concluderen dat het bepalen van het juiste doel van groot belang is voor de project 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 vergelijken dan zien we veel overlap. Naar ons idee is het dan ook nodig om een co-leiderschap van deze twee rollen te organiseren in ieder project. Want waar de requirements 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 natuurlijk 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 requirements 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

 

Precies volgens Plan!

Dit artikel is gebaseerd op het boek ‘Precies volgens 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 engineering vooral ook een kwestie van keuzes maken die passen bij jouw organisatie. Die keuzes maak je met al de mensen die het moeten doen. Requirements 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.

Categorie:   
Auteur(s)
afbeelding van jwknop
Jan Willem Knop
Valori - Product Manager/Consultant

Jan Willem Knop is als Product Manager/Consultant werkzaam bij Valori. Na bij toeval terecht te zijn gekomen in de software-industrie, heeft hij zo'n beetje alle rollen in IT-projecten doorlopen. De rode draad in Jan Willem’s carrière van programmeur naar ‘mensen-mens’ is de kwaliteit van het product. Kwaliteit die voor een groot deel bepaald wordt door requirements. En kwaliteit van requirements wordt bepaald door mensen. In zijn werk bij Valori is Jan Willem er achtergekomen dat werken met requirements niet vanzelfsprekend is in de industrie. Iedere kans om uit te dragen hoe dat kan veranderen pakt Jan Willem daarom aan.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.