Een projectteam bij een middelgrote gemeente besteedt de eerste bijeenkomst over een nieuw zaaksysteem aan de vraag of het project volgens Prince2 of volgens een lichte Scrum-variant wordt aangepakt. Er wordt gestemd, de methode staat aan het eind van de vergadering op de eerste sheet van de presentatie. De eisenlijst voor het systeem zelf bestaat op dat moment uit drie bulletpoints op een half A4'tje: geen acceptatiecriteria, geen eigenaar per eis, geen onderscheid tussen must en nice-to-have. Drie weken later, als de eerste sprint van start gaat, blijkt niemand het eens over wat 'een werkend dossieroverzicht' precies inhoudt.
Die volgorde, eerst de methode en dan pas de eisen, komt vaker voor dan je zou denken. Onderzoek wijst uit dat het de verkeerde volgorde is.
Wat het onderzoek laat zien
Dvir, Raz en Shenhar onderzochten in 2003 waar projectsucces daadwerkelijk mee samenhangt. Hun bevinding: succes correleert met de kwaliteit van de eisen-definitie, hoe scherp is vastgelegd wat het project moet opleveren, en niet met de mate waarin een formeel PM-proces is doorgevoerd. Met de methodekeuze zelf, hoe grondig ook uitgewerkt in een handboek of sjabloon, hangt dat nauwelijks samen. Met de eisen wel.
Dat is een ongemakkelijke conclusie voor wie veel tijd steekt in het kiezen en documenteren van een werkwijze. Een projectplan met een strak Prince2-stramien, rollen, faseovergangen, een PID, alles volgens het boekje, oogt professioneel. Maar als de eisenlijst eronder vaag blijft, koopt de opdrachtgever schijnzekerheid: de vorm is op orde, de inhoud niet.
De nuance die erbij hoort
Dit is geen pleidooi om governance en procesafspraken maar te laten voor wat ze zijn. Ander onderzoek, van Serrador en Turner uit 2015, vindt wel positieve verbanden tussen procesvolwassenheid en projectsucces. 'Inhoud boven proces' is dus geen universele wet, de twee onderzoekslijnen spreken elkaar op dit punt tegen. Wat blijft staan: eisen-definitie mag niet verdwijnen achter een methodologiediscussie, ook niet als die discussie zelf nuttig is.
Wat dat betekent voor de start van een project
Concreet: als een plan van aanpak in de eerste weken vooral gaat over welke methode wordt gevolgd, welk framework, welke sjablonen, welke overlegstructuur, terwijl de eisenlijst een placeholder blijft, staat de volgorde op zijn kop. De methodekeuze kan best vroeg plaatsvinden, maar niet in plaats van het vastleggen van eisen. Een eis die telt, heeft een eigenaar, is verifieerbaar (je kunt achteraf toetsen of eraan is voldaan) en staat los van de manier waarop het project wordt aangestuurd.
Voor wie een plan van aanpak beoordeelt voor de kickoff is dit een concrete vraag naast die over governance en fasering: staan de eisen er, onafhankelijk van de gekozen werkwijze? Een plan dat op procesinrichting uitstekend scoort maar waarvan de eisen niet verder komen dan een intentieverklaring, verdient op dat punt een kritische blik. Niet omdat proces niet telt, maar omdat een strak proces de afwezigheid van scherpe eisen kan maskeren, en dat is precies waar het bij het zaaksysteem misging.
Een concrete stap
Zet bij de eerstvolgende sessie over het plan van aanpak de eisenlijst boven aan de agenda, voor het gesprek over de te volgen methode. Laat elke eis een eigenaar en een acceptatiecriterium krijgen voordat het team verdergaat naar de vraag welk framework daaromheen wordt gebouwd. Dat kost een uur op een moment dat de discussie toch nog over vorm gaat, en voorkomt dat een goed gedocumenteerde methode straks bovenop een leeg fundament staat.