Zo scope je een Salesforce-project zodat het op tijd oplevert

Een Salesforce-project levert op tijd op wanneer de scope de beslissingen prijst die het project nodig heeft, niet de features die het gaat bouwen. De meeste fixed-scope projecten lopen uit omdat discovery een featurelijst opleverde, en een featurelijst zwijgt over wie wat moet beslissen, en wanneer. De oplossing is een uitkomst, een beslissingsregister en een opgeschreven lijst met non-goals.

Waarom lopen fixed-scope Salesforce-projecten uit?

Niet omdat de bouw is onderschat. Bouwramingen zitten meestal dicht in de buurt. De kalender breekt ergens anders.

De cijfers zijn onvriendelijk. In zijn CRM-faalonderzoek van 2025 vond Johnny Grow dat 55% van de CRM-implementaties de geplande doelstellingen niet haalde, dat ongeveer 30% de geplande planning haalde, en dat maar 25% doelstellingen, planning en budget samen haalde. Zeven op de tien overschreden de planning met 30% of meer. Die overschrijdingen zijn zelden engineeringoverschrijdingen.

Dit is het echte mechanisme. Een scoperegel zegt "bouw een goedkeuringsproces voor kortingen boven 15%". De bouw kost drie dagen. De onbeantwoorde vraag eronder is wie goedkeurt, vanaf welke drempel, in welke valuta, wat er gebeurt als die persoon met verlof is, en of Finance of Sales de uitzondering bezit. Die vraag vraagt vier mensen in een kamer die moeilijk in een kamer te krijgen zijn. Het gaat niet sneller met meer developers. Het project wacht, en dat wachten landt op de opleverdatum.

Wat betekent het om beslissingen te prijzen in plaats van features?

Een feature is werk. Een beslissing is een afhankelijkheid van een mens. Scoping die alleen het werk telt, levert een raming op die klopt over de bouw en niet klopt over de kalender.

Je scope is als features geprijsd als:

• Elke regel begint met bouwen, configureren of migreren.
• Geen enkele regel noemt een persoon die iets moet beslissen.
• Integratieregels zeggen niet welk systeem per object de bron van waarheid is.
• Datamigratie is een regel.
• Er is geen non-goals-sectie.

Elk daarvan is een plek waar een ongenomen beslissing zich verstopt achter een geraamde taak.

Hoe scope je een Salesforce-project zodat het op tijd oplevert?

1. Schrijf een uitkomstzin, met een getal en een datum. Niet "de serviceefficientie verbeteren" maar "de wekelijkse handmatige casetriage terugbrengen van X naar Y voor het einde van Q2". Wil niemand zich aan een getal binden, dan heb je nog geen project, alleen interesse.
2. Bouw een beslissingsregister voor je een takenlijst maakt. Elke openstaande vraag die een bouw blokkeert, met een genoemde eigenaar en een datum waarop hij beantwoord moet zijn. Dat document voorspelt je go-live, niet de planning.
3. Scheid bekend van onbekend. Werk dat je eerder deed krijgt een raming. Werk dat je niet eerder deed krijgt een timebox en een expliciete exitvoorwaarde. Middel die twee nooit tot een getal.
4. Schrijf de non-goals op en laat ze hardop lezen. Zie hieronder.
5. Snijd naar een eerste release die een echte gebruikersgroep in productie gebruikt. Een team, een proces, live. Een pilot waar niemand van afhankelijk is leert je niets over de beslissingen die je verkeerd had.
6. Zet de cadans vast, niet de scope. Sprints van twee weken met werkende software aan het eind van elke sprint is wat je toelaat scope te ruilen zonder het contract te heronderhandelen. Zo werken wij bij Tekunda, en daarom overleeft een vaste datum een veranderde eis.

Wat hoort er in een non-goals-lijst?

Een non-goal is iets waarvan een redelijk mens aanneemt dat het erbij zit, opgeschreven als uitgesloten. Het is het goedkoopste artefact in het project en het meest overgeslagen.

• Dingen die stakeholders vroegen en die niet in deze release zitten, met naam, niet samengevat.
• Stille aannames: historische data voorbij een genoemde grens, offline mobiel, een tweede taal, de belastingregels van een tweede land.
• Processen die voorlopig buiten Salesforce blijven.
• Integraties die in deze release eenrichting zijn terwijl iedereen tweerichting voor zich ziet.

De regel die het laat werken: een non-goal telt alleen als de persoon die erom vroeg hem op schrift heeft gezien en niet heeft geprotesteerd. Een non-goals-lijst die niemand las, is enkel bewijsmateriaal voor de evaluatie.

Hoe ga je om met het verzoek dat in week zes binnenkomt?

Het komt binnen, en het botweg weigeren is meestal het verkeerde antwoord, want verzoeken uit week zes zijn vaak beter geinformeerd dan die uit week een. Stel twee vragen:

• Verandert het het uitkomstgetal? Zo ja, dan is het een herscoping en hoort de sponsor erbij.
• Maakt het een al genomen en bebouwde beslissing ongeldig? Zo ja, prijs het herwerk apart en zichtbaar.

Is het geen van beide, ruil het dan. Iets van vergelijkbare omvang verlaat de release en gaat naar de non-goals-lijst, op schrift, dezelfde dag. Toevoegen zonder aftrekken is hoe een datum stilletjes sterft.

Wat staat er in een scopedocument dat het contact overleeft?

• Een uitkomstzin met een metriek en een datum.
• Een beslissingsregister: vraag, eigenaar, deadline, status.
• Aannames, elk falsifieerbaar.
• Non-goals, benoemd en bevestigd.
• Datascope: welke objecten, hoe ver terug, wie de schoning bezit.
• Bron van waarheid per object, en de richting van elke integratie.
• Definition of done voor de eerste release, in gebruikerstermen.
• Wat er na go-live gebeurt, inclusief wie de backlog houdt.

Acht punten. Het past op twee pagina's en zegt meer over je opleverdatum dan een requirementsmatrix van driehonderd regels.

FAQ

Hoe lang moet Salesforce-discovery duren?

Lang genoeg om de beslissingen te sluiten die de eerste release blokkeren, en niet langer. Beoordeel het op de staat van het beslissingsregister, niet op een vast aantal weken.

Is fixed-scope altijd het verkeerde model voor Salesforce?

Nee, maar het werkt alleen als de beslissingen al genomen zijn. Fixed scope op een onbesloten proces zet de verkeerde variabele vast en de datum betaalt de rekening.

Wat is het verschil tussen een non-goal en buiten scope?

Buiten scope is contractueel. Een non-goal is gecommuniceerd. De waarde zit erin dat de stakeholder het heeft gelezen, niet dat het later verdedigbaar is.

Wie moet het beslissingsregister bezitten?

Iemand aan klantzijde met de bevoegdheid om te escaleren. Bezit je leverancier het, dan wordt elke te late beslissing een klacht over de leverancier in plaats van een interne deadline.

Kan fasering een te grote scope repareren?

Alleen als elke fase live gaat voor echte gebruikers. Fases die allemaal aan het eind landen zijn een project met extra documenten.