Under promise and over delivery in softwareprojecten

Je kent het gesprek waarschijnlijk wel. Een klant vraagt om “gewoon even” een maatwerkapplicatie, er wordt in de offerte een datum genoemd die prettig klinkt, en pas later blijkt dat de koppeling met het ERP, de testfase en de acceptatie door gebruikers toch meer tijd kosten dan in de verkoopkamer zichtbaar was. Dan schuift de oplevering op, niet omdat iedereen traag werkt, maar omdat de eerste belofte te strak was gezet voor de echte complexiteit.

Precies daar zit de waarde van under promise and over delivery. Niet als verkooptruc, maar als werkwijze waarbij scope, planning en communicatie vanaf het begin rekening houden met onzekerheid, afhankelijkheden en integraties die in maatwerksoftware bijna nooit netjes lineair verlopen.

Een klant hoort in een verkoopgesprek “zes weken” en onthoudt vooral dat getal. In de praktijk blijkt later dat de applicatie niet op zichzelf staat, maar moet praten met een ERP, een CRM, een boekhoudpakket en soms nog een oude Excel-werkwijze die niemand graag hardop benoemt. Dat is het moment waarop een belofte uit de brochure botst met de technische realiteit.

De Nederlandse context maakt dat extra zichtbaar. Onderzoek onder 129 organisaties laat zien dat slechts 20% bijna alle projecten binnen tijd en budget afrondt, terwijl 50% dat bij ongeveer de helft van de projecten lukt en 30% bij minder dan de helft. Bij de overheid liepen begin 2023 tientallen grote IT-projecten samen al 1,3 miljard euro uit, waarvan de tien grootste ongeveer 700 miljoen euro en de overige 109 projecten samen ruim 600 miljoen euro. Ook liep twee op de drie grote IT-projecten vertraging op, en volgens berichtgeving wordt bij de overheid ongeveer 30% van de ICT-projecten succesvol afgerond, terwijl bij grote projecten vanaf 7,5 miljoen euro slechts 7% slaagt en een kwart volledig misloopt. Bron 1, Bron 2, Bron 3

Een belangrijk deel van die uitloop ontstaat al vóór de eerste regel code. Offertes gaan vaak uit van een nette rechte lijn, terwijl maatwerksoftware juist schuurt op integraties, afstemming en keuzes die pas tijdens het bouwen echt scherp worden. Wie daar te optimistisch plant, schuift risico's door naar de sprint, het testmoment of de acceptatie.

Dat patroon zie je ook terug in de bekende cone of uncertainty. Hoe eerder een raming wordt gemaakt, hoe groter de foutmarge meestal is. Daarom werken projectdata, functionele omvang en gefaseerde planning beter dan een lineaire belofte die geen ruimte laat voor rework, afhankelijkheden en vertragingen in de keten. De bredere kosten van technische schuld maken dat alleen maar duidelijker, omdat uitgestelde keuzes later alsnog tijd en budget vragen. Bron 4 Technische schuld: de onzichtbare kostenpost

Praktische observatie: een mooie einddatum helpt alleen als de omvang al scherp genoeg is gemeten om die datum te dragen.

Daarom werkt under promise and over delivery in deze context als een tegenmaatregel. Het zet onzekerheid expliciet op tafel, in plaats van haar weg te poetsen. Daarmee ontstaat een planning die technisch klopt en organisatorisch beter standhoudt.

De makkelijkste metafoor is die van een pakketbezorger. “Morgen tussen 9 en 17 uur” is minder spectaculair dan “vóór 10 uur”, maar het is vaak geloofwaardiger. Als het pakket om 9:15 al voor de deur staat, voelt dat als meevaller. Als de chauffeur te vroeg belooft en te laat komt, voelt zelfs een nette levering als teleurstelling.

Bij software werkt dat net zo. Het team zegt niet wat theoretisch het snelst kan, maar wat het realistisch en gecontroleerd kan halen. Daarna wordt intern zo gewerkt dat de kans groot is dat de oplevering de verwachting raakt of zelfs overtreft.

Aan de klantkant betekent het een conservatieve belofte. Dus geen optimistische datum die alleen klopt als alles vlekkeloos gaat, maar een planning met ruimte voor integratieproblemen, testbevindingen en feedback.

Aan de teamkant betekent het maximale focus zodra die afspraak is gemaakt. Het team committeert zich aan minder functionaliteit dan technisch misschien haalbaar lijkt, zodat onverwachte issues niet meteen het hele schema omgooien. Dat is iets anders dan scope creep, waarbij extra wensen ongemerkt blijven binnenkomen. Het is ook iets anders dan gold plating, waarbij developers meer bouwen dan nodig is omdat het “toch nog even mooier kan”.

Een conservatieve belofte is geen vrijbrief om langzaam te werken. Het is juist een discipline om sneller tot een beheersbaar resultaat te komen.

In software betekent dat vaak: een sprint niet volproppen, een integratie eerst klein bewijzen, en pas daarna uitbreiden. Het principe is dus niet “minder doen”, maar “slimmer beloven en strakker leveren”. Under promise and over delivery is geen trucje, maar een planningstechniek.

Klanten reageren niet alleen op feitelijke oplevering, maar vooral op het verschil tussen verwachting en uitkomst. Dat is precies de logica achter het expectancy-disconfirmation model. Een resultaat dat precies voldoet aan een hoge belofte voelt zelden bijzonder, terwijl een resultaat dat een bescheiden belofte overtreft snel vertrouwen opbouwt.

Dat is in software meteen zichtbaar. Een demo die twee dagen eerder live gaat dan gepland, wordt vaak ervaren als sterk signaal van beheersing. Een demo die “net op tijd” komt, kan technisch prima zijn, maar levert minder emotionele winst op. En een gemiste deadline kleurt vaak het hele gesprek erna, ook als de software inhoudelijk goed is.

Diezelfde psychologische werking speelt intern. Developers die een haalbare sprintcommitment aangaan, werken rustiger en maken betere technische keuzes. Er is minder druk om half afgemaakte oplossingen door te drukken, en minder neiging om technische schuld te verhullen achter tempo.

Dat sluit aan bij Nederlandse ICT-governance, waar het Adviescollege ICT-toetsing benadrukt dat software voortvarender wordt ontwikkeld wanneer vanaf het begin met stevig mandaat wordt gestuurd en de omgeving goed is ingericht. Dan nemen de voorspelbaarheid van planning en kwaliteit toe, en groeit de kans op meer autonomie en werkplezier bij ontwikkelteams. Bron 5

Een conservatieve belofte werkt dus op twee niveaus tegelijk. De klant krijgt een realistischer verwachting, en het team krijgt een werkbare bandbreedte. Dat is zelden spectaculair in een pitch, maar wel sterk in uitvoering.

Voorspelbaarheid in maatwerksoftware vraagt om vier onderdelen die samen werken. Scope, mijlpalen, iteraties en communicatie moeten op elkaar aansluiten, anders wordt de planning alsnog een wenslijst.

Een traject wordt betrouwbaarder zodra de functionele grenzen vooraf helder zijn. Alles hoeft niet meteen vast te liggen, maar de kern wel: wat zit erin, wat zit er niet in, en welke aannames dragen de offerte?

Zonder die scherpte groeit elk klein extraatje uit tot verborgen werk. Met een vaste scope kun je bewuster beloven, omdat je weet welke discussie later niet meer stilletjes in de planning schuift.

Een einddatum zonder tussenstappen blijft kwetsbaar. Mijlpalen maken voortgang zichtbaar, bijvoorbeeld met een werkende authenticatiemodule, een gemigreerde dataset of een eerste integratie die echt data uitwisselt. De klant ziet dan niet alleen wanneer iets klaar moet zijn, maar ook hoe ver het traject al is.

Bij grotere overheidsprojecten wordt planning ook beter hanteerbaar wanneer voortgang, kosten en kwaliteit tussentijds zichtbaar zijn. Dat helpt om verwachtingen te toetsen voordat een traject onnodig uitloopt. Bron 4

Iteraties van twee weken dwingen tot kleine, leverbare stukken. Daardoor blijft een grote tegenvaller aan het eind kleiner, omdat risico's eerder boven water komen. Als een koppeling of performance-probleem misgaat, gebeurt dat in een beheersbare sprint, niet in de laatste week voor livegang.

Dat is ook waar onderbeloven praktisch werkt. Je belooft alleen wat je in een sprint echt kunt dragen, en je houdt ruimte over om technische keuzes netjes af te maken.

Communicatie is geen bijlage, maar een vast onderdeel van het traject. Een weekly demo met echte software, een transparante voortgangsweergave en een vast aanspreekpunt maken het verschil tussen gissen en weten waar je staat.

• Scherpe scope, voorkomt dat wensen stilletjes uitwaaieren.
• Mijlpalen, maken vooruitgang meetbaar voor beide kanten.
• Korte iteraties, houden risico's klein en herstelbaar.
• Continue communicatie, voorkomt verrassingen aan het eind.

Die vier samen vormen het technische en organisatorische raamwerk van een traject waarin conservatief beloven logisch wordt. Niet omdat de lat lager ligt, maar omdat de route ernaartoe zichtbaar en bespreekbaar is.

Een B2B-portaal startte met een belofte van 14 weken in plaats van de gebruikelijke acht. Dat voelde in het begin voorzichtig, maar die marge gaf ruimte om de kern goed neer te zetten en keuzes later te toetsen in plaats van ze vroeg vast te spijkeren.

In de eerste sprints leverde het team losse, werkende onderdelen op. Eerst login, daarna facturatie-overzicht, daarna een eerste rapportagemodule. Elke demo liet echte voortgang zien, geen schema op slides.

Die aanpak past bij een MVP, zoals uitgelegd in MVP: waarom klein beginnen de slimste strategie is. Je brengt alleen de functies in die direct waarde tonen, zodat je snel ziet wat werkt en wat nog bijgestuurd moet worden.

Na 12 weken draaide het volledige MVP in een staging-omgeving. In de laatste fase was er ook nog ruimte voor een extra rolbeheerlaag die later in het traject was bedacht. De klant kreeg dus niet alleen binnen de belofte geleverd, maar ook een versie die de oorspronkelijke scope functioneel versterkte.

Bij een legacy-migratie van een Windows-applicatie naar een webstack lag de angst vooral bij stilstand. De klant rekende op lange downtime, dus de offerte zette per module een strak kader neer, met een gecontroleerde cut-over en een roll-backpad.

Door feature flags, een canary-release en een serieus rollback-plan bleef de feitelijke omschakeling per module korter dan dertig minuten. Dat maakte de migratie niet risicovrij, wel beheersbaar.

De eerste case draait om snelheid zonder kwaliteit te verliezen. De tweede om verandering zonder de operatie te verstoren. In beide gevallen werkte de conservatieve belofte niet als rem, maar als buffer waardoor extra waarde mogelijk werd.

Dat sluit aan op de Nederlandse realiteit van uitgelopen ICT-projecten. In overheidsdocumentatie over het ICT-landschap is de verhouding tussen continuïteit en vernieuwing verschoven van 90%-10% naar 80%-20%, met als beoogde verhouding 70%-30%. Tegelijk is ongeveer 20% van de verouderde AIX-systemen uitgefaseerd en is al een derde van de doelstelling om 40% van applicaties met technische waarde lager dan 50% af te bouwen gerealiseerd. Bron 6

Bij MG Software zit dit principe niet alleen in de planning, maar in de manier waarop offerte, sprint en communicatie op elkaar aansluiten. Dat begint met een midden-scenario in plaats van een optimistische gok. De klant krijgt bandbreedtes te zien, inclusief de risico's die bij integraties of migraties horen, zodat verwachtingen niet op lucht worden gebouwd.

Tijdens de sprint wordt bewust niet alles volgepland. Er blijft ruimte over voor onverwachte integraties, reviewrondes of kleine correcties die anders pas te laat zichtbaar zouden worden. In een goede sprintcadans is die reserve geen verspilling, maar een noodzakelijke buffer voor echte softwareontwikkeling.

Vast ritme werkt beter dan grote beloften. Een demo aan het einde van elke sprint maakt voortgang zichtbaar en voorkomt dat gesprek en werkelijkheid uit elkaar groeien.

Daar hoort ook een vaste technische structuur bij. Een geschikt hulpmiddel is een planning met duidelijke scope, vaste tussenresultaten en terugkerende reviewmomenten, zoals uitgewerkt in het sprint-planning-template van MG Software. Dat soort ritme helpt om voortgang niet alleen te voelen, maar ook te bewijzen.

In klantgesprekken werkt een vast aanspreekpunt het best. Diegene benoemt risico's vroeg, vraagt door op nieuwe wensen en maakt successen concreet. Daardoor wordt een conservatieve belofte geen defensieve houding, maar een manier om betrouwbaarheid zichtbaar te maken in elke fase van het traject.

De eerste misvatting is dat under promise and over delivery vertraging betekent. In de praktijk gaat het om scherper ramen, strakker afbakenen en eerder opleveren wat echt waarde toevoegt. Wie te groot belooft, kiest niet voor ambitie maar voor extra risico.

De tweede misvatting is dat conservatief plannen zwak oogt. Het laat juist zien dat scope, integraties en testwerk serieus zijn meegenomen. In Nederlandse ICT-projecten, waar deadlines vaak onder druk staan, geeft dat meer vertrouwen dan een belofte die later nog moet worden teruggedraaid. Wie klein begint, kan ook leren van de eerste versie, zoals in de aanpak van een MVP klein starten slimmer maakt.

De derde misvatting is dat agile vanzelf tot meer oplevert. Agile werkt alleen als de richting scherp blijft en het ritme bewaakt wordt. Zonder duidelijke scope en vaste communicatie worden sprints juist losse stukken werk waarin verrassingen zich opstapelen.

• Maak één sprintinschatting realistischer, door de eerste versie bewust conservatiever te zetten.
• Reserveer ruimte voor onbekende taken, niet als losse post, maar als expliciete buffer.
• Plan elke week een demo, met werkende software en concrete feedback.
• Communiceer direct wanneer marge ontstaat, zodat de klant ziet wat eerder of extra is opgeleverd.

Dat hoeft niet groot te zijn. Eén project, één sprint, één ander gesprek kan al genoeg zijn om te zien hoeveel rust het oplevert. Bij MG Software werkt dat alleen als techniek en organisatie samen bewegen. Daarom worden sprints gekoppeld aan vaste mijlpalen, heldere klantmomenten en een realistische belofte aan het begin. Wie dat patroon vasthoudt, merkt snel dat conservatief beloven niet minder ambitieus is, maar beter uitvoerbaar in de praktijk.