Is een Programma van Eisen nog wel van deze tijd? Hier moet je op letten bij de aanschaf van software

Heb je ooit in een restaurant een gerecht besteld om vervolgens naar de keuken te lopen en de kok tot in detail te vertellen hoe hij het moest bereiden? Absurd idee, toch? Opvallend genoeg is dit nu precies hoe een Programma van Eisen (PvE) vaak wordt gebruikt bij de aanschaf van software. Met als risico dat je niet krijgt wat je nodig hebt, omdat je zelf nu eenmaal geen specialist bent. 

De kok van het restaurant weet precies hoe hij een perfecte lasagna moet bereiden: daar heeft hij namelijk voor geleerd en uitgebreide ervaring mee. Hij weet hoe je pastadeeg maakt en hoe je een lasagne bereidt die verrast. Dus waarom zou je hem dat als leek moeten vertellen? Je wilt toch juist profiteren van zíjn expertise? Dat is de reden dat je uit eten gaat en niet zelf thuis gaat staan hannesen met eieren, bloem en een pastamachine om pastadeeg te maken. 

Toch is dit de manier waarop veel verenigingen en goede doelen nieuwe software aanschaffen. In plaats van in een vroeg stadium experts te betrekken en hen te vragen mee te denken in de beste oplossing voor de uitdaging die je wilt oplossen, bedenken zelf een hele waslijst aan wensen en eisen. Niet zelden wordt daar een externe adviseur voor ingeschakeld. 

Profiteren van expertise

Een PvE heeft vele voordelen, maar kan averechts werken wanneer je het niet op de juiste manier inzet in het project. Een van de voordelen is dat je als vereniging of goed doel voorafgaand aan de aanschaf van nieuwe software goed nadenkt over wat je belangrijk vindt en welke waarde je met het nieuwe pakket wilt creëren. 

Je krijgt misschien wel waar je om hebt gevraagd, maar niet wat je nodig hebt.

Maar vanaf dat punt wordt het al snel complex. Want je weet misschien wel wat je wilt bereiken en ook dat je daar data voor wilt inzetten, maar hoe dat dan in de praktijk zijn beslag moet krijgen is een tweede. Bij het traditionele Programma van Eisen vul je deze uitdaging vervolgens zelf al in met concrete vereisten waaraan de software moet voldoen. Oftewel: je vertelt de kok precies hoe lang je wilt dat hij de lasagna in de oven zet en op welke temperatuur, terwijl je niet weet hoe het gerecht is samengesteld en hoe je daarmee het beste resultaat bereikt. En dat is nou juist het punt: je betaalt de kok voor zijn kennis en expertise maar stelt daar zoveel voorwaarden aan dat hij die kennis en expertise niet tot zijn recht kan laten komen. Het resultaat is dat je misschien krijgt waar je om hebt gevraagd, maar niet wat je nodig hebt.

Dat gezegd hebbende is het helemaal niet zo dat jouw softwareleverancier wel altijd precies weet wat je nodig hebt. Hij weet wel meer van technologie en hoe dit interacteert met processen en mensen, maar alleen jij weet waar je vereniging of goede doel bij gebaat is. Je zult dus samen tot een optimale oplossing komen. 

Gierend uit de bocht

Het is niet verwonderlijk dat veel verenigingen en goede doelen naar een PvE grijpen wanneer ze een nieuw softwarepakket moeten aanschaffen. Zo’n traject is niet iets dat je regelmatig onderneemt en er is een flinke investering mee gemoeid. Dat maakt dat je graag zoveel mogelijk zekerheid wilt inbouwen, helemaal in een wereld waarin de berichten over dure en ellenlange IT-trajecten je om de oren vliegen. Je wilt zeker weten dat jouw organisatie niet in zo’n debacle terechtkomt. Het is daarom heel logisch om op een PvE te vertrouwen, want dan heb je gevoelsmatig immers grip op wat je krijgt.

Maar heb je wel eens bedacht waaróm die IT-projecten soms zo gierend uit de bocht vliegen qua tijd en budget? Een van de redenen ís vaak het PvE. Die had je niet verwacht, hè? Ik zal je uitleggen waar de risico’s zitten en waarom juist zo’n ogenschijnlijk helder overzicht van eisen ervoor kan zorgen dat er onduidelijkheid ontstaat. 

Interpretatieverschillen bij een Programma van Eisen

Veel Programma’s van Eisen die worden opgesteld bij de aanschaf van een softwarepakket zijn niet concreet genoeg. Dat lijkt onlogisch, maar is het niet. Van oorsprong worden PvE’s gebruikt bij het ontwerp van fysieke objecten, zoals consumentenproducten, gebouwen en machines. Het vormt een alomvattende lijst van specificaties die iedere keer exact hetzelfde object moeten opleveren, ongeacht in welke fabriek of door welke aannemer het gemaakt wordt. 

Een cruciaal onderdeel hierin is dat dit soort PvE’s aan strenge normen moeten voldoen waardoor voor iedereen duidelijk is wat een bepaalde eis inhoudt. Het lijkt misschien heel duidelijk en meetbaar wanneer je opschrijft dat de woonkamer van een nieuw huis ‘ruim genoeg moet zijn voor een gezin van zes mensen’. Maar deze formulering staat garant voor een verschil in interpretatie. 

Opvallend genoeg bevatten veel PvE’s in softwaretrajecten soortgelijke formuleringen. Denk maar eens aan de eis dat een systeem ‘gebruiksvriendelijk’ moet zijn. Daar zullen verschillende leveranciers verschillend over denken. En op het moment dat je er achter komt dat jouw gekozen leverancier jouw eisen heel anders interpreteert dan jijzelf, ben je niet zelden al zo ver in het ontwikkeltraject dat het of heel duur of wellicht zelfs onmogelijk is om nog makkelijk wijzigingen door te voeren. Ziedaar:  tijdrovende en kostbare aanpassingen die niet nodig waren geweest. 

Jij en je leverancier hebben hetzelfde belang: met de beschikbare middelen de beste en meest duurzame oplossing bouwen om je uitdagingen en problemen op te lossen.

Niet alleen is het lastig om als zelf de inschatting te maken van hoe een optimale oplossing eruit moet zien, het is bovendien een gemiste kans om niet vroegtijdig de expertise van een of meerdere leveranciers in te roepen. Leveranciers zijn erop gebrand om de efficiëntste en eenvoudigste oplossing voor een bepaald tarief te bouwen. Een vereniging of goede doel wil de beste oplossing in ruil voor een acceptabele investering. Jij en je leverancier hebben hetzelfde belang: met de beschikbare middelen de beste en meest duurzame oplossing bouwen om je uitdagingen en problemen op te lossen.

Dat kan alleen als klant en leveranciers als één team samenwerken. En om dat te bereiken is het noodzakelijk om in een vroeg stadium bij elkaar aan tafel te komen. Zo kan de vereniging of het goede doel uiteen zetten tegen welke zaken men aanloopt en welke mogelijkheden ze graag zou krijgen. En de leverancier kan meedenken hoe dat het beste bereikt kan worden. Wanneer je een PvE als uitgangspunt neemt, loop je het risico dat de leverancier bouwt wat er wordt beschreven, maar dan wel volgens zijn interpretatie. Zo krijg je niet alleen niet de beste oplossing voor jouw uitdaging, maar ook niet wat je verwacht had en betaal je wellicht te veel.

Denk in problemen (ja echt!)

Om nog even terug te komen op de analogie van het restaurant: stel dat je graag een diner op hoog culinair niveau wilt, maar niet zo’n groot budget hebt, dan kun je ook dát aangeven bij de ober. En misschien had je gedacht dat daar in ieder geval vlees bij hoort, maar dat hoeft helemaal niet zo te zijn. De kok, de expert, kan bepalen wat het beste aan jouw wensen voldoet. Misschien vraagt hij je wel of je vandaag vegetarisch wilt eten, want dat is zijn specialiteit en minstens zo smakelijk als vlees. Hij zal je dan nog vragen of je voorkeur hebt qua groenten, vleesvervangers, kruiden en specerijen om zo in de keuken het best mogelijke gerecht voor jouw budget te bereiden. Wanneer je alles van tevoren zelf al invult en hebt bepaald, mis je de expertise (en in het geval van het restaurant, het genot!) van de specialist. En dus ook de mogelijkheid om aangenaam verrast te worden en iets beters te krijgen dan je zelf had bedacht. 

Denk dus vooral in problemen en niet in oplossingen. Alleen door goed te doorgronden welk probleem of welke vraag je probeert op te lossen, kun je in samenspraak met een leverancier tot een oplossing komen die het beste past.

Inzicht in markt en mogelijkheden 

Heb je dan eigenlijk helemaal niets aan zo’n Plan van Eisen? Jazeker wel! Maar alleen als je het anders invult. In plaats van een Programma van Eisen op te stellen waarin je op de stoel van de specialist bent gaan zitten, kun je beter een inventarisatie maken van de wensen binnen je vereniging of goede doel. Welke dingen wil je graag kunnen doen om zo meerwaarde te creëren voor je leden? Beschrijf de uitdaging waar je tegenaan loopt zonder dat je direct oplossingen aandraagt. 

Dat is waar je in een vroegtijdig stadium een leverancier (of meerdere) over vraagt mee te denken. Zo behoud je de ruimte om op onverwachte en onbekende oplossingen voor jouw (deel)uitdagingen te komen. Een voordeel van het voeren van dit soort gesprekken met leveranciers is dat je beter zicht krijgt op waar je wensen en eisen daadwerkelijk liggen, wat de huidige mogelijkheden in de markt zijn en vooral ook aan welk kostenplaatje je moet denken. Dat kostenplaatje zal, wanneer je een leverancier vroegtijdig betrekt in het project, veel meer overeenkomen met het uiteindelijke bedrag dan wanneer je een leverancier louter vinkjes laat zetten op een PvE met alle interpretatieverschillen van dien. 

Ieder zijn eigen vakgebied

Eigenlijk biedt het enorm veel rust om je te realiseren dat je niet zélf hoeft te bedenken hoe jullie nieuwe software eruit moet komen te zien. Dat is namelijk voor veel verenigingen en goede doelen een ver-van-hun-bed-show. Zij willen vooral waarde leveren aan leden en donateurs. Een goed softwarepakket is daarin essentieel, maar het selecteren daarvan is geen alledaagse bezigheid voor verenigingsprofessionals en fondsenwervers.

Hoe fijn is het dat er specialisten zijn die niets anders doen dan software ontwikkelen voor verenigingen en goede doelen? En die meedenken welke mogelijkheden voor jou het beste passen, niet op basis van een eisenlijst, maar op basis van wat je graag zou willen en kúnnen doen voor je leden of donateurs. De technische vertaalslag ligt niet meer bij de organisatie die een bepaald vraagstuk wil oplossen, maar daar waar die hoort: bij de leverancier. 

Agile is flexibel

Vrijwel alle leveranciers werken tegenwoordig ‘agile’ (flexibel). Vroeger werd er inderdaad een PvE neergelegd bij een softwarebouwer die vervolgens maanden later een volledig systeem opleverde waaraan het nog lastig sleutelen was. Tegenwoordig is het ontwikkelproces een stuk flexibeler en wordt een softwarepakket in nauwe samenspraak met de klant ontwikkeld in kleine stukjes. Zodat je steeds kunt zien of het nog op het juiste pad zit en werkt zoals je dat graag zou willen en verwacht. 

Bijsturen is in agile softwareontwikkeling veel eenvoudiger en als klant ben je nauwer betrokken. Doordat de leverancier jouw vereniging beter leert kennen in een nauwe samenwerking, weet hij beter met welke problemen en uitdagingen je te maken hebt en in welke context het systeem binnen jouw vereniging moet gaan functioneren. Een PvE lijkt je houvast te bieden in het software ontwikkelingstraject, maar door agile te werken, krijg je ook houvast, alleen op een andere manier. Vaak is het even wennen aan die nieuwe, flexibele manier van werken waarbij je snel inzichtelijk krijgt welke kant het opgaat met je softwarepakket, maar op deze manier krijg je wel precies wat je nodig hebt. 

Programma van Eisen: niet meer van deze tijd?

Moet je je programma van eisen dan maar in de prullenbak gooien en je overleveren aan de leverancier? Nee, zeker niet. Maar het is wel zaak om met een andere insteek een programma van eisen op te stellen.

Voor verenigingen en goede doelen die een nieuw softwaresysteem willen aanschaffen, is veel nuttiger om goed na te denken over tegen welke problemen ze aanlopen en welke uitdagingen ze graag opgelost willen zien. Dat gaat niet alleen over technologie, maar ook over je processen en mensen. Ook is de manier waarop je waarde levert (bijvoorbeeld met bepaalde diensten of door je missie te realiseren) cruciaal om tot het beste systeem te komen dat dit ondersteunt. En dus is het, om maximaal waarde te krijgen uit je investering, verstandig om in een vroeg stadium met leveranciers om tafel te gaan zitten. Zij kunnen als experts op het vlak van technologie en processen meedenken over de optimale oplossing. 

Dat daaruit uiteindelijk een lijst met functionele eisen vloeit, is niet meer dan logisch. Maar die eisen zijn dan wel opgesteld in nauwe samenspraak met de leverancier die het systeem gaat bouwen en jullie organisatie en missie inmiddels vrij goed kent. Op die manier kun je er veel zekerder van zijn dat een nieuw systeem krijgt dat aansluit op jullie wensen en behoeften, zonder dat je daar onverwacht meer tijd of geld aan kwijt bent. 

👉 Wil je meer van dit soort artikelen lezen? Schrijf je dan in voor onze nieuwsbrief.

👉 Wil je het eens vrijblijvend hebben over jouw PvE, of heb je andere vragen? Stuur ons een mail.