Artikel

Requirements zijn de Big Hitter…

…voor succesvolle projecten!

We willen maximaal rendement uit onze IT-investeringen. De realiteit is dat de meeste IT-projecten mislukken. En dat is al vrij lang zo in de IT-wereld. Je kunt je daarom afvragen of IT-projecten wel succesvol kunnen zijn. In dit artikel beschrijven we hoe een goed ingericht requirements proces de Key Success Factor is voor geslaagde IT-projecten. We laten dat zien aan de hand van een “Big Hitter” voor succesvolle projecten en hoe requirements daarin een rol spelen.

Herkent U dit?

Bij een gemeentelijke instelling is de herinrichting van een straat door de betreffende ambtenaar voortvarend ter hand genomen. Er zijn meer parkeerplaatsen in de straat nodig en dus is met dat doel een nieuwe straatindeling ontworpen.

Een bestratingsbedrijf krijgt opdracht om de nieuwe straatindeling te realiseren. De werkzaamheden beginnen. Om bewoners en winkeliers tegemoet te komen in de overlast die de werkzaamheden met zich meebrengen, wordt de straat alvast opengesteld voordat de werkzaamheden zijn afgerond. De nieuwe lantaarnpalen zijn nog niet geplaatst, en de oude konden nog niet worden weggehaald, omdat de straat anders onverlicht zou zijn. Met het volgende resultaat:

Figuur 1: Meer parkeerplaatsen?

De doelstelling ‘meer parkeerplaatsen’ is natuurlijk duidelijk. De eisen aan ‘goede straat verlichting’ zijn echter vergeten. Hierdoor is onvoldoende aandacht besteed aan het eindproduct, waardoor de eisen ten aanzien van de volgorde waarin de taken werden uitgevoerd niet goed zijn geïnventariseerd. De straat is precies volgens plan aangepast en toch voldoet het eindresultaat (nog) niet. Uiteraard is het probleem op te lossen, maar daarvoor wordt dan wel een extra inspanning verricht, waarbij de juist aangelegde parkeerplaats opnieuw wordt opengebroken.

We hebben Requirements nodig om projecten te doen slagen. Projecten slagen door een goed product dat voldoet aan de (business) doelstellingen: op tijd en tegen gebudgetteerde kosten op te leveren. Dan moet requirements engineering, het proces om tot requirements te komen, echter wel op de juiste manier worden uitgevoerd.

De Big Hitters

We hebben gezien dat we voor veranderingen die we wensen te realiseren projecten nodig hebben. En die projecten moeten we op de juiste manier uitvoeren om het gewenste resultaat te bereiken, zonder extra kosten zoals het opnieuw moeten openbreken van de straat om de lantaarnpaal te kunnen verplaatsen.

Voor IT-projecten is het eveneens van groot belang dat we die op de juiste manier uitvoeren. Aart J. van Dijk heeft in zijn promotieonderzoek naar Succes and Failure Factors in ICT projects: A Dutch Perspective onderzoek gedaan naar de factoren van IT-projecten die bepalend zijn voor een succesvolle afloop.

In zijn studie beschrijft Van Dijk deze factoren, de zogenoemde Big Hitters. De studie vat succesfactoren samen die onder andere naar voren zijn gebracht door Capers Jones, John Smith en Peter Noordam. Van Dijk betoogd in zijn onderzoek dat je, wanneer je aandacht geeft aan deze Big Hitters, je grote kans maakt op een succes. Maar ook dat wanneer je één Big Hitter verwaarloost de kans dat je project niet succesvol wordt haast een zekerheid is.

De zeven Big Hitters zijn:

  1. Goed projectmanagement
  2. Realistische deadlines
  3. Goede communicatie
  4. Sterk en compleet requirements document
  5. Voldoende betrokkenheid van toekomstige gebruikers
  6. Betrokkenheid en commitment van senior management
  7. Voldoende professionaliteit (professionals)

Als je naar de lijst met Big Hitters kijkt, zie je dat requirements, het onderwerp van dit artikel expliciet genoemd is. En ze spelen ook een cruciale rol bij alle andere Big Hitters. Requirements leveren bijvoorbeeld een grote bijdrage aan goede communicatie. Als ze zodanig beschreven zijn dat ze door alle belanghebbenden eenduidig geïnterpreteerd worden, verbetert dit de onderlinge communicatie over de requirements.

Ook de CHAOS rapporten van The Standish Group bevestigen keer op keer dat requirements een belangrijke, zo niet de belangrijkste rol spelen bij het al dan niet slagen van projecten.

Bedreigingen voor succesvolle toepassing van requirements

Requirements zijn dus cruciaal voor het succes van projecten. Echter, de meeste projecten mislukken. Besteden we dan te weinig aandacht aan de Big Hitters?

Met experts hebben we een workshop gehouden over succesvolle toepassing van requirements, vanuit verschillende rollen. De workshop ging over de problemen die we bij onze klanten regelmatig tegenkomen en die succesvol requirements engineering bedreigen. We hebben de problemen samengevat in onderstaande uitspraken:

Figuur 2: De meest voorkomende problemen bij requirements engineering

We lichten er in dit artikel een probleem uit: “Zelf geen requirement(s) aandragen”. In de praktijk zijn er belanghebbenden die vinden dat ze zelf geen requirements hoeven aan te dragen. Het is immers de verantwoordelijkheid van de requirements engineer om requirements naar voren te brengen. Ze redeneren dat de requirements engineer de expert is.

Gezien het aantal verschillende soorten belanghebbenden die normaliter een rol spelen in IT-projecten is het onmogelijk dat de requirements engineer over alle domeinkennis beschikt van deze belanghebbenden. Door dit toch te verwachten van de requirements engineer is het risico dat er onvolledige en onjuiste requirements komen erg groot. Indien de belanghebbenden hun eigen belang niet vertegenwoordigen zal het eindresultaat van het project niet voldoen aan de wensen en eisen van de gebruikers. Zo getuigt ook onderstaand voorbeeld.

De ‘hippe’ spijkerbroek

Tijdens een presentatie over requirements maakte een deelnemer vanuit de zaal de opmerking dat hij een keer, toen hij een kledingwinkel bezocht, aan een verkoopster vroeg om een hippe spijkerbroek. Hij ging er van uit dat die verkoopster voldoende wist om op basis van die informatie de juiste spijkerbroek voor hem te kunnen uitzoeken. De requirements ten aanzien van de spijkerbroek werden dus aan de verkoopster overgelaten, stelde hij. Volgens hem gold dit ook voor de requirements engineer. Deze zou met een enkele opdracht de resterende requirements prima zelf kunnen bedenken. Toen ik hem vervolgens vroeg: ‘Zou je de hippe spijkerbroek die de verkoopster voor je heeft uitgezocht daarna ook ongezien afrekenen zonder dat je hem mag omruilen?’, was het antwoord een duidelijk: ‘nee’! Met andere woorden, zoals je het bepalen van de maat, kleur, prijs, het model, merk van je hippe spijkerbroek niet overlaat aan de verkoopster, zo doe je dat ook niet met de requirements ten aanzien van de requirements engineer. Bij de vraagsteller viel het kwartje; hij gaf aan dat hij in toekomstige projecten zijn belangen voortaan zelf ging vertegenwoordigen.

Aanpak voor succesvolle requirements

Aan de hand van de problemen die onze experts bij klanten tegenkomen rond het requirements proces zijn we gaan analyseren hoe we die kunnen aanpakken zodat we requirements engineering (proces, documentatie etc.) op een succesvolle manier kunnen toepassen. Op basis van alle problemen bij requirements engineering hebben we een vijftal aandachtspunten afgeleid (zie figuur 3). Besteed je voldoende tijd en aandacht aan deze punten dan zal requirements engineering succesvol zijn.

Figuur 3: Aandachtspunten voor succesvol requirements engineering

Wanneer je deze aandachtspunten gebruikt met een blik gericht specifiek op jouw project en bedrijfscultuur dan zal jouw project succesvol zijn. Laten we er een voorbeeld uit halen.

Organiseer je proces

Een van de gevonden aandachtspunten is de inrichting van het requirements proces. Hoewel er veel theorie beschikbaar is over requirements, blijft het bovenal mensenwerk. Een standaard requirements engineering proces is een goed uitgangspunt, en om dit proces effectief te doorlopen is het belangrijk dat de verschillende partijen goed samenwerken. Op het moment dat meerdere mensen samenwerken om iets te bereiken, zoals binnen een project, is een duidelijke rolverdeling nodig.

Een rolverdeling zorgt voor houvast. Iedereen binnen het project weet van tevoren wat er van hem of haar verwacht wordt. Hiermee schep je duidelijkheid en voorkom je communicatieproblemen met de bijbehorende ergernissen.

Figuur 4: Rolverdeling belangrijke rollen in RE proces

Het is bijvoorbeeld cruciaal voor het succes van requirements engineering om bij de kick-off van een project het proces, de rollen en de bijbehorende taken en verantwoordelijkheden toe te lichten aan het projectteam en de belanghebbenden. Dit geeft iedereen de tijd om goed na te denken over zijn/haar rol in het proces. Als er mensen zijn die niet de juiste rol hebben gekregen, of geen mandaat hebben om namens hun afdeling requirements aan te dragen dan kan dit maar beter vroegtijdig helder zijn. Zodat tijdig de benodigde maatregelen genomen worden, zoals het wisselen van rollen of het aanvragen van mandaat. Het toepassen van de RACI (of RASCI), zie figuur 4, voor requirements engineering tijdens de kick-off helpt bij het scheppen van deze duidelijkheid.

Al met al leidt deze rolverdeling tot het oplossen van een deel van de in figuur 2 genoemde problemen. Hoe je dat doet is zoals eerder aangegeven een kwestie van goed kijken naar jouw organisatie of project (zie kader).

Hiermee hebben we een aandachtspunt behandeld. In volgende artikelen gaan we in op de andere aandachtspunten voor succesvol requirements engineering.

Dit artikel is gebaseerd op het boek ‘Precies volgens Plan!’ geschreven door Mark Hoogveld, Jan Willem Knop en Marcel Schaar. Het boek gaat ook op de andere Big Hitters in en laat zien hoe het inrichten van een requirements proces hier invloed op heeft.

In het boek ‘Precies volgens Plan!’ 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.