.svg)
Er zijn weinig vragen zo lastig als: wat zou dit IT-project moeten kosten?
Niet omdat we te weinig ervaring hebben. Ook niet omdat we iets bouwen wat nog nooit eerder is gedaan. De echte uitdaging zit in iets anders: onduidelijke requirements en de fundamentele spanning tussen een dienst verkopen alsof het een product is.
Na gewerkt te hebben aan alle kanten van de tafel—agencies, opdrachtgevers en tech bedrijven—durf ik te stellen dat de meeste projecten hetzelfde patroon volgen, nog voordat er één regel code is geschreven of één instelling is aangepast.
De service-product paradox
Kort gezegd: je koopt geen kant-en-klaar product. Je koopt tijd.
Tijd waarin standaardcomponenten worden geïntegreerd, geconfigureerd en aangepast aan jouw situatie. Dat is per definitie een dienst, ook als we het een “oplossing” noemen.
En zodra requirements veranderen—door nieuwe inzichten, technische beperkingen, platformupdates of verschuivende prioriteiten—verandert ook de benodigde tijd.
Daar ontstaat de paradox.
Management wil vooraf een vaste prijs en planning. Om dat te kunnen geven, heeft de product owner een volledig uitgewerkte scope nodig. Dat vraagt van stakeholders dat ze niet alleen hun wensen benoemen, maar ook alle consequenties daarvan doordenken. Als dat niet gebeurt, ontstaan aannames. Er worden standaardoplossingen gekozen. En zodra het wordt opgeleverd, blijkt de werkelijkheid weerbarstiger: verwachtingen sluiten niet aan en bijsturen is nodig.
In vrijwel elk project zien we dan hetzelfde gebeuren:
- Complexiteit wordt onderschat
- Inspanning en kosten worden door alle partijen geminimaliseerd
- Niemand heeft aan het begin een volledig beeld van de eindsituatie
Daar komt nog iets bij: softwareontwikkeling is nog steeds een vak, geen commodity.
Goede oplossingen vragen ervaring, oordeelsvermogen en verfijning. Nieuwe tools versnellen delen van het werk, maar nemen onzekerheid niet weg.
Dus kiezen we voor MVP’s
De gebruikelijke reactie is: we bouwen een minimal viable product en leunen zo veel mogelijk op standaardfunctionaliteit. Dat heeft absoluut waarde. Maar we hebben ook gezien hoe projecten met grote potentie zo worden teruggebracht tot oplossingen die wel werken, maar nauwelijks impact maken.
Voor standaardonderdelen—winkelwagens, productoverzichten, CRM-flows—werkt dit vaak prima. Maar zodra waarde zit in onderscheid, integratie of operationele efficiëntie, wordt het risicovol.
Als customer service geen actueel orderoverzicht heeft, of productinformatie niet laat zien waarom een product uniek is, dan verdient geen enkele livegang zichzelf terug.
De 80/20-benadering
Als we kunnen schatten, waarom lopen projecten dan toch uit in tijd en budget?
Omdat we alles op dezelfde manier benaderen. Wat in de praktijk werkt, is een splitsing.
De 80%: standaardiseren en begroten
De routinematige onderdelen—checkoutflows, gangbare integraties, basisautomatisering—zijn goed te voorspellen. Deze kunnen en moeten leunen op bewezen oplossingen. Hier is snelheid belangrijk en zijn vaste inschattingen realistisch.
De 20%: samenwerken en itereren
De overige 20% is waar echte waarde ontstaat. Dit zijn de bedrijfsspecifieke onderdelen: hoe processen écht lopen, waar frictie zit, waar onderscheid wordt gemaakt.
Deze kennis is vaak impliciet en contextafhankelijk. Ze laat zich niet volledig vangen in een RFP of twee intakegesprekken. Ze vraagt om gezamenlijk begrip.
Dat betekent: stakeholders actief betrekken, processen eerlijk blootleggen en ruimte maken voor verkenning—via workshops, prototypes en iteraties. Juist bij de onderdelen met de meeste impact voorkomt deze aanpak dure misverstanden later.
En nee, dat hoeft geen maanden te duren. Goed gefaciliteerde sessies, service blueprints en snelle prototypes kunnen in dagen worden opgezet, mits de juiste mensen samen aan tafel zitten en focussen op de echte problemen.
Wat dit betekent in de praktijk
Projecten blijven beheersbaar als een paar principes serieus worden genomen.
Voorbereiding is cruciaal. Verzamel echte requirements, zorg voor toegang tot relevante documentatie en reserveer tijd bij stakeholders. Dit bepaalt de kwaliteit van alles wat volgt.
Tijd is een factor. Haast levert zelden kwaliteit op. Een volledige e-commerce transformatie—van idee tot livegang—duurt al snel een jaar. Niet omdat er constant wordt gebouwd, maar omdat goede samenwerking continuïteit vraagt.
En bovenal: wees pragmatisch. Als er iets misloopt—en dat gebeurt altijd—gaat het niet om vasthouden aan het oorspronkelijke plan, maar om het beste resultaat binnen de beschikbare tijd en het budget. Flexibiliteit wint het van rigiditeit.
De kern
IT-projecten mislukken niet omdat mensen onkundig zijn. Ze mislukken wanneer we doen alsof we een product kopen, terwijl we eigenlijk een samenwerking aangaan.
Succesvolle projecten zijn partnerschappen, met gedeelde verantwoordelijkheid voor impact, keuzes en budget. Onzekerheid verdwijnt niet, maar je kunt er eerlijk en bewust mee omgaan: standaardiseer waar het kan, werk samen waar het telt en blijf wendbaar.
Als we projecten zo benaderen, verandert de vraag van
“wat zou dit moeten kosten?” naar
“hoe leveren we samen echte waarde?”
En dát maakt het verschil.
