Tezamen met 'slecht projectmanagement' vormt 'slechte requirements' de top 2 van redenen waarom softwareprojecten vaak uitlopen of helemaal mislukken. Bij het van de grond af ontwikkelen van nieuwe software oplossingen voor organisaties is het altijd een uitdaging om eisen en wensen op zo’n manier in kaart te brengen dat het opgeleverde systeem op basis daarvan geaccepteerd of afgewezen kan worden en het resultaat goed bruikbaar is.
Het verzamelen van de business, user, functional en non-functional (quality of service) requirements is een karwei wat altijd onderschat wordt op de volgende aspecten:
• Weet de klant wel wat hij eigenlijk wil?
• Bepalen de juiste mensen de requirements?
• Is de lijst van requirements volledig?
• Kunnen requirements ondubbelzinnig worden gespecificeerd?
• Hoe maken we requirements testbaar?
De laatste twee aspecten zijn relatief eenvoudig te adresseren. Door gebruik te maken van een deugdelijk requirements gathering tool (veelal Excel op basis van een goede template) en in vervolgdocumenten zoals functioneel ontwerp, technisch ontwerp en testplan een requirements index op te nemen kan veel geautomatiseerd worden. Requirements moeten zo veel mogelijk SMART gedocumenteerd worden. Het blijft natuurlijk wel monnikenwerk, maar het is in het algemeen goed te doen. Uiteindelijk kunnen dus bij het uitvoeren van het testplan tijdens de acceptatietests de requirements afgetikt gaan worden en bepaald worden of het opgeleverde aan de eisen voldoet.
Tegenstrijdige requirements
Op de vraag 'Is de lijst van requirements volledig' is vaak moeilijker antwoord te geven. Wel helpen de juiste tools ook hier bij. Vooral voor de lijst van non-functional requirements (zoals performance en beschikbaarheidseisen) is snel te bepalen of het een volledig overzicht is omdat het vaak een standaard lijst is. De moeilijkheid zit hem hier vaak in tegenstrijdige requirements zoals performance versus security en flexibiliteit versus beheersbaarheid. Gebruik requirements versioning om ook veranderende requirements tijdens de uitvoer van het project goed te kunnen managen.
De twee moeilijkste aspecten staan bovenaan in de lijst. We kunnen heel ondubbelzinnig user requirements specificeren naar aanleiding van workshops met een aantal sleutelgebruikers, maar als deze sleutelgebruikers verkeerd zijn geselecteerd kan het resultaat verre van optimaal zijn. In dit geval zal vaak nog steeds wel redelijk met het systeem gewerkt kunnen worden en levert het zijn voordelen toch nog op. Het is vaak de deskundigheid en ervaring van de interviewer cq. functionele consultant die bepaalt hoe goed en consequent de uiteindelijke lijst van user requirements is, ongeacht eventuele slechte input.
Meetbaar maken
Het allermoeilijkste aspect is natuurlijk de eerste: 'Weet de klant wel wat hij eigenlijk wil?'. De business requirements bepalen hoe het systeem de bedrijfsdoelstellingen mede helpt te gaan behalen maar zullen ook gebruikt worden om de business case voor het nieuwe systeem meetbaar te maken. Maar wie bepaalt die business requirements eigenlijk? Degene die het systeem gaat gebruiken? Degene die de besluiten neemt? Of degene die ervoor betaalt?
In de vele requirements sessies die ik in mijn carrière heb mogen leiden of meemaken was het de uitdaging om vanuit je eigen kunde en ervaring de mensen die verantwoordelijk zijn voor het aanleveren van de business requirements op één lijn te krijgen en binnen de kaders te houden. Er zijn al genoeg systemen die ik altijd maar 'kinderen met een waterhoofd' noem (bijvoorbaat sorry als ik iemand hiermee beledig). Ik bedoel hiermee systemen die té veel kunnen, die functionaliteiten bieden die eigenlijk niet tot de kern of zelfde categorie behoren.
SAP en Sharepoint
Dé grootste uitdaging is om de klant tegen zichzelf te beschermen en om een goed samenhangend systeem op te leveren. Jarenlange product management ervaring is hier cruciaal. De taal van de klant spreken en sturend kunnen communiceren is ook erg belangrijk. Uiteindelijk is het de kunst om de klant het gevoel te geven dat ze zelf de requirements hebben bedacht, terwijl jij natuurlijk al lang wist hoe het systeem er uit moest zien. Dit is makkelijker als je systemen ontwikkelt die gebaseerd zijn op een basis uitgangspunt, zoals maatwerk op een standaard erp-systeem als SAP of een standaard platform voor document management als Sharepoint. Maar laten we eens heel eerlijk zijn, weten we bij voorbaat eigenlijk al niet wat de klant grotendeels nodig heeft en hebben we dat al niet heel vaak eerder ontwikkeld? 80% van de requirements kan waarschijnlijk één op één gekopieerd worden vanuit een ander project. Alleen die verrekte laatste 20 procent kost meestal 80 procent van de tijd, en dat is vaak het grootste probleem; hoe krijgen we die 80 procent omlaag en veranderen we voor eens en voor altijd die regel?
Dag Gijs,
Allereerst goed te lezen artikelen met veel punten die ik kan onderstrepen.
Alleen de eerste zin wil ik wat nuanceren.
“Tezamen met ‘slecht projectmanagement’ vormt ‘slechte requirements’ de top 2 van redenen waarom softwareprojecten vaak uitlopen of helemaal mislukken.”
Ik denk namelijk dat er nog 1 voor de top 2 van jou komt en in feite beschrijf je die ook in je artikel. Weet de klant wel wat hij wil?
Waar ik in de praktijk tegenaan loop is dat een klant een sneller paard zoekt terwijl hij eigenlijk baat heeft bij een auto (vrije interpretatie van Henry Ford).
Iedereen praat vanuit zijn referentie kader; dat wat hij al kent en stelt van daaruit zijn behoefte. Maar zo’n bedrijf of persoon heeft eigenlijk behoefte aan iemand die veel meer weet en helpt bij het inzicht van wat er nu eigenlijk gewenst is.
Dit is overigens ook het gevaar als je met je leverancier praat. Die zal ook in alle problemen de oplossing van zijn eigen product het beste vinden (logisch).
Dus projectmanagement is belangrijk, requirements zijn belangrijk, maar die komen pas na een strategie fase.
Hi Henri,
Daar heb je helemaal gelijk in, strategie is waar het allemaal mee moet beginnen. In die fase bepaal je de visie, doelstellingen, business case en de implementatie aanpak in grote lijnen. Op dat niveau is echter vaak iedereen wel op 1 lijn te krijgen is mijn ervaring.
De fase van vertaling van deze strategie naar daadwerkelijke implementatie is waar het vaak “mis” gaat. Men is het dan wel over de grote lijnen eens, maar bij het uitwerken van de nitty gritty details moet grote inspanning worden geleverd om daadwerkelijk iets op te kunnen gaan leveren wat aan de visie, doelstellingen en business case gaat voldoen.
Je kunt het requirementsproces standaardiseren, gebaseerd op best practices (FSM bijvoorbeeld) en je kunt standaard sets van requirements opstellen voor standaardoplossingen (allerlei tooling, CRM en ERP oplossingen), maar ik denk dat zolang er sprake is van verschillende organisaties je geen standaard kunt creëren die voor alle vergelijkbare situaties hetzelfde is.
Voor gelijke organisaties onder één paraplu, zoals gemeenten, kun je wellicht een set requirements opstellen die meer dan 90% van de benodigde functionaliteit afdekt, maar dan nog blijf je hangen op een aantal unieke specs die per organisatie verschillend zijn, afhankelijk van het lokale beleid, de politieke signatuur van de gemeenteraad, de invloed van grote bedrijven op besluitvorming etc..
Wat in elk geval niet moet is dat IT gaat vertellen wat de klant wil. Dat gaat al jaren fout. Wat IT moet doen is de klant helpen. Helpen doe je door de klant in een zo vroeg mogelijk stadium de consequenties van bepaald keuzes te laten zien. Daar help je hem veel beter mee. Je stuurt daarmee evengoed het requirementsproces, maar dan niet naar wat jij wilt leveren of wat jij denkt dat de klant nodig heeft, maar naar wat de klant echt hebben wil en daadwerkelijk nodig heeft, dus zonder de toeters en bellen die hij aanvankelijk ook nodig dacht te hebben. Dat is een iets andere benadering, maar met hetzelfde effect voor IT: een tevreden klant met op maat gesneden IT.
Leuk en herkenbaar verhaal
Maar: wie is de klant?
Kijk ik naar de gefaalde projecten in mijn omgeving zie ik namelijk nog een andere factor die meespeelt: de verkeerde key-users, service delivery managers, zogeheten experts et cetera.
Managers die denken te weten hoe er op de werkvloer gewerkt wordt, “epxerts” die zich te goed voelen om met de werknemers te gaan praten (niet zelden uit angst om door de mand te vallen omdat ze eigenlijk helemaar niet zo veel weten als dat ze altijd beweerd hebben) of de key-user die eigenlijk zelf niets doet maar alles laat doen… ik heb ze allemaal voorbij zien komen afgelopen jaren.
Helaas waren dit de mensen die het contact met de leverancier onderhielden, waardoor de werkvloer met een slecht werkbaar product opgezadeld werd.
Het belang van een goede, maar vooral representatieve, klantvertegenwoordiging wordt nogal eens onderschat!
Leuk artikel Gijs, en ook leuke reacties erop.
Ik ben wat minder blij met je opmerking dat alle klanten kenlijk het zelfde willen, om ze dan maar uitgerekend met SAP of Sharepoint op weg te sturen.
Ik werk voor een klein bedrijf dat alles op klantenspec maakt.
Onze klanten zijn dan ook vaak eigenzinnige (veelal familie) bedrijven die graag een nononsens product willen dat doet wat zij er van verwachten.
De enkeling die bij een overname overgaat op SAP of MicroSoft is daar zelfden blij mee (soms komen ze naar vijf jaar nog voor support op het reeds lang afgeschreven pakket).
Ik denk dat PaVaKa het wat dat betreft eerder bij het rechte eind heeft.
Zorg dat de wens van de klant voor hem/haar zelf inzichtelijk is en kom eerst dan met een voorstel.
Het gaat immers niet aleen om het verkopen van je product, maar als het even meezit ook om een langdurige en tevreden klant relatie.
Uitdagende titel en inderdaad herkenbaar verhaal.
Ik ben er van overtuigd dat het opstellen van vereisten een discipline is die door “de business” en “IT” samen gedaan moet worden. Vaak kan de rol van “IT” die van een “Maverick” zijn: een persoon die niet volledig op de hoogte is van de bedrijfsprocessen maar iedereen voortdurend de vraag stelt waarom we zaken überhaupt doen of waarom op een bepaalde wijze. Ik zie namelijk vaak dat projecten zich vooral richten op automatiseren van bestaande werkwijzen en dat levert niet per definitie het beste resultaat. Of zoals Bill Gates al zei:
“..iets automatiseren lost de onderliggende problemen niet op, het zorgt er alleen voor dat ze zich sneller voordoen, in grotere getalen en met grotere regelmaat”
Een ander aspect is dat de business vaak al een idee heeft van “hoe” zaken opgelost moeten worden en hoe de oplossing er uit moet zien zonder dat zij volledig op de hoogte zijn van wat technisch allemaal mogelijk is. Ook hier zal de “IT afdeling” zijn meerwaarde kunnen bewijzen door hierover mee te denken. Mijn ervaring is dat in projecten te kort wordt stilgestaan bij “wat” er gerealiseerd moet worden (waar moet een mogelijke oplossing aan voldoen en welke business doelen moeten deze ondersteunen?) en men te snel overgaat op het “hoe” en de “IT afdeling” gaat hier graag in mee waardoor de echte kansen op procesverbetering blijven liggen.