De go/no-go-beslissing: hoe je die voorbereidt en wie er besluit

Waar de go/no-go over beslist

Een go/no-go is het moment waarop de business zegt: deze versie van het CRM mag naar productie, op deze datum. Of ze zegt: nog niet. Het is geen formaliteit aan het eind van de test. Het is de reden dat de test is gedaan.

Een goede go/no-go heeft drie delen:

• Feiten. Wat er is getest, wat geslaagd is, wat nog openstaat. Uit de testresultaten, niet uit het hoofd.
• Een oordeel. De eigenaren van de processen zeggen of ze met deze versie hun werk kunnen doen, en onder welke voorwaarden.
• Een besluit. De stuurgroep weegt de feiten en de oordelen af tegen de go-livedatum, en besluit.

Bij de meeste go/no-go-overleggen die misgaan ontbreekt het eerste deel. Mensen discussiëren over hoe erg een issue is, of over de vraag of een proces wel getest is, omdat niemand de cijfers heeft. De rest van deze gids gaat erover hoe je zorgt dat de feiten er zijn voordat het overleg begint.

Eindcriteria: spreek ze af vóór de eerste testdag

Eindcriteria zeggen wanneer de test goed genoeg is om live te gaan. Spreek ze af met de stuurgroep vóór de eerste testdag. Aan het eind lopen de emoties hoog op en zijn de datums dichtbij. Dat is het verkeerde moment om te bepalen wat telt.

Criteria die voor de meeste CRM-go-lives werken:

• Er staat geen Critical issue open.
• Elke Must-testcase is geslaagd.
• Elk open High issue heeft een workaround of een datum voor de fix die de business accepteert.
• Elke testcase in scope heeft een resultaat.
• De eigenaar van elk proces heeft zijn sign-off gegeven.

Spreek af wat de woorden betekenen

Criteria werken alleen als iedereen dezelfde schaal gebruikt. Schrijf op wat elke ernst betekent, en deel dat met testers en de stuurgroep:

Doe hetzelfde voor prioriteit. Een testcase met Must dekt wat op dag één moet werken, zoals een offerte maken of een case routeren. Als een Must-testcase faalt, komt de go-live in gevaar. Zie Testcases schrijven die businesstesters begrijpen voor het bepalen van prioriteiten.

Schrijf op wat niet wordt getest

Elke UAT laat iets buiten beschouwing: een land dat later live gaat, een rapport dat nog niet klaar is, een koppeling die alleen in de systeemtest is getest. Zet het vóór de test op papier. Dan kan niemand bij de go/no-go zeggen dat hij dacht dat het erbij zat.

Wie besluit

Er doen twee groepen mensen mee, met verschillende rollen.

De eigenaren van de processen geven hun sign-off

Voor elk proces of elke groep in de test geeft één persoon uit de business de sign-off: de salesdirecteur voor lead to cash, het hoofd klantenservice voor case management, de financieel verantwoordelijke voor facturatie. Zij weten wat hun teams nodig hebben, en zij moeten met het resultaat leven. Hun sign-off zegt: mijn mensen kunnen met deze versie hun werk doen.

Benoem ze aan het begin van het project, niet in de laatste week. Een proceseigenaar die de test pas in het go/no-go-overleg ziet, tekent zonder te lezen, of vraagt om nog een week.

De stuurgroep besluit

De stuurgroep neemt het besluit voor de hele go-live. Daarin zitten meestal de sponsor uit de business, de projectmanager, een lead van IT en, bij een implementatiepartner, iemand van de partner. De stuurgroep weegt dingen af die één proceseigenaar niet kan overzien: een contract met het oude CRM dat afloopt, een trainingsplan, een migratieweekend, andere projecten op dezelfde datum.

De testlead bereidt voor, maar besluit niet

De testlead brengt de feiten en een advies. De testlead geeft geen sign-off namens de business en neemt het besluit niet. Door die rollen gescheiden te houden, blijft het besluit overeind als er na de go-live iets misgaat.

Het rapport: wat erin staat

Het go/no-go-rapport is voor mensen die niet bij de test waren. Houd het kort: één pagina, met de details erachter voor wie ze wil zien.

• Een advies. Go, go met voorwaarden, of no-go, met de redenen in een of twee regels.
• Scope. Welke processen en user stories in de test zaten, en wat niet is getest.
• Wat er is getest. De omgeving, de release en de build. Een resultaat hoort bij één versie van het systeem.
• De cijfers. Testcases geslaagd, mislukt, geblokkeerd en niet afgerond.
• Per groep of proces. Dezelfde cijfers, met de sign-off van elke groep.
• Per prioriteit. Hoeveel Must-, Should- en Could-testcases geslaagd zijn, en welke Must-testcases niet.
• Issues per ernst. Hoeveel er openstaan, klaar zijn voor hertest en gesloten zijn, met de open Critical en High issues bij naam.
• De sign-offs. Wie tekende, wanneer, met welk besluit en welke voorwaarden.
• Bekende risico's. De workarounds die de business in de eerste weken gebruikt, en wie daarbij ondersteunt.

Stuur het rapport een dag voor het overleg. Wie het thuis leest, stelt betere vragen.

In UAT StudioHet Go/no-go report op het dashboard bevat de indicatie (GO, GO with conditions of NO-GO, met de redenen), de cijfers, de voortgang per dag, de resultaten per groep, per epic en per prioriteit, de issues per ernst, de open Critical en High issues bij naam, en elke sign-off van de ronde. De indicatie volgt vaste regels en is een advies: de stuurgroep besluit. Deel het als pdf of download het als slides voor de presentatie aan de stuurgroep.

Wat je doet met open issues

Aan het eind van een UAT staan er altijd issues open. De vraag is niet of er zijn, maar of er voor elk issue een besluit is. Loop ze vóór het overleg door, met de business en het ontwikkelteam, zoals in de dagelijkse triage.

Herclassificeer met zorg

In de laatste dagen is er druk om een Critical issue naar High te verplaatsen. Soms is dat terecht: er komt een workaround, of het proces blijkt zelden voor te komen. Doe het openlijk, in de triage, met de proceseigenaar, en schrijf op waarom. Doe het nooit stilletjes om de cijfers mooier te maken. Zo mislukt een go-live in de eerste week.

Wensen zijn geen defecten

Testers vinden dingen die ze graag anders zouden zien. Als het systeem werkt zoals ontworpen, is het een change request: dat gaat naar de backlog, niet in deze release, en het telt niet mee tegen de go-live.

In UAT StudioDe triage geeft elk issue een ernst, een prioriteit, een toegewezen persoon en een besluit: Fix, Reject of Change request. Met de module AI test design schrijft Summarize with AI op het tabblad Issues een kort overzicht van de open issues voor het go/no-go-overleg: gegroepeerd per thema, met wat de go-live blokkeert. Zonder de module geeft Summarize with your own AI een prompt om in de AI van je eigen bedrijf te plakken.

Een go onder voorwaarden

Veel CRM-go-lives krijgen een go met voorwaarden. Het systeem is goed genoeg, mits er vóór of direct na de go-live iets gebeurt. Dat is een eerlijk besluit, zolang de voorwaarden echt zijn.

Een goede voorwaarde is:

• Concreet. De kortingsgoedkeuring voor orders boven 50.000 is opgelost en opnieuw getest, niet de goedkeuringen werken.
• Belegd. Eén persoon is ervoor verantwoordelijk, bij naam.
• Gedateerd. Vóór de go-live, of een datum in de eerste weken erna.
• Gecontroleerd. Iemand bevestigt dat het is gedaan, en de stuurgroep hoort ervan.

Let op het aantal voorwaarden. Twee of drie is normaal. Vijftien betekent dat de test niet af is. Een go onder voorwaarden is geen manier om een no-go te ontlopen.

Go-live in delen

Soms is één proces niet klaar en de rest wel. Je kunt dan live gaan zonder dat proces, of met één land of team later. Besluit dat expliciet, schrijf de nieuwe datum op voor het deel dat wacht, en plan er een eigen UAT-ronde en sign-off voor.

Sign-off per groep

Vraag om een sign-off per proces of groep, niet om één handtekening voor alles. Een salesdirecteur kan case management niet beoordelen, en hoeft dat ook niet. Elke eigenaar kiest een van drie antwoorden:

• Accepted: mijn mensen kunnen met deze versie hun werk doen.
• Accepted with conditions: mits de voorwaarden zijn uitgevoerd. Schrijf elke voorwaarde op, met wie het doet en wanneer.
• Rejected: niet goed genoeg om live te gaan. Vraag wat het antwoord zou veranderen.

Verzamel de sign-offs vóór het overleg, zodat de stuurgroep besluit op basis van het volledige beeld. Een sign-off hoort bij één versie: volgt er een nieuwe build of een nieuwe testronde, geef dan opnieuw sign-off.

In UAT StudioDe kaart Sign-off op het dashboard heeft een regel voor het hele project en een voor elke groep, met Accepted, Accepted with conditions of Rejected. De datum, de tijd en het aantal open Critical issues worden vastgelegd. Standaard kan niemand accepteren zolang er een Critical issue openstaat; met No sign-off while Must test cases have not passed aangevinkt, wacht accepteren ook tot elke Must-testcase geslaagd is. Afwijzen kan altijd. Een sign-off hoort bij de huidige ronde.

Het go/no-go-overleg leiden

Plan het overleg wanneer je de testdagen plant, met de datum in de agenda van de stuurgroep. Trek er een uur voor uit. Een gebruikelijke volgorde:

1. De testlead laat het rapport zien: scope, cijfers, open issues, sign-offs. Tien minuten, met de cijfers op het scherm.
2. Elke proceseigenaar zegt in een of twee zinnen waarom hij of zij zo heeft getekend, en wat de voorwaarden zijn.
3. Vragen over de open Critical en High issues: is er een fix, een workaround, een datum?
4. Vragen buiten de test: training, datamigratie, ondersteuning in de eerste weken, het plan om terug te draaien.
5. Het besluit: go, go met voorwaarden, of no-go. Lees het hardop voor, met de voorwaarden, eigenaren en datums.

Is het besluit no-go, sluit dan af met een plan: wat er moet veranderen, een nieuwe testronde, en een datum voor de volgende go/no-go. Een no-go met een plan is een normaal projectbesluit. Een no-go zonder plan voelt als mislukking.

Het besluitenlog

Leg het besluit dezelfde dag vast. Maanden later, na een incident of tijdens een audit, vraagt iemand wie besloot live te gaan met dat open issue. Het antwoord moet binnen een minuut te vinden zijn.

Een besluitenlog bevat voor elke go/no-go:

• De datum, en wie er bij het overleg waren.
• Het besluit: go, go met voorwaarden, of no-go.
• Elke voorwaarde, met de eigenaar, de datum en, later, wanneer die is uitgevoerd.
• De open issues die de business heeft geaccepteerd, met de reden.
• Het rapport waarop het besluit is gebaseerd, zoals het op dat moment was.

Bewaar het bij de projectdocumenten, en volg de voorwaarden in de eerste weken na de go-live op, tot elke voorwaarde is uitgevoerd.

In UAT StudioSave snapshot op het go/no-go-rapport bewaart het rapport zoals het was toen het besluit werd genomen; het verandert niet meer, en met Show open je het later weer. Elke sign-off blijft in de geschiedenis, ook de sign-offs die zijn vervangen of ingetrokken. Voor een auditor downloaden admins het Evidence pack: het rapport, de testcases, resultaten en issues, de geschiedenis van elk issue, elke sign-off en het auditlog, met een checksum van elk bestand.

Gratis te gebruiken

De eindcriteria, de sign-off en het rapport staan ook in de UAT-checklist voor een CRM-go-live, als gratis Excel-bestand. Voor de hele test, zie de gidsen voor een Salesforce UAT en een Dynamics 365 UAT.