Versnel uw stage-gates: sjablonen voor businesscases, risicoanalyses en experimenten18 min lezen

Stel je voor: er is een vergadering bij de poort gepland van 90 minuten. Het eerste uur wordt besteed aan vragen over de businesscase moet heb op papier beantwoord.

De recensenten blijven steeds weer dezelfde vragen stellen:

• Welke omzetcijfers zijn schattingen en welke zijn gecontroleerd?
• Wat maakt dit ongeldig als het fout is?
• Wat heeft het team sinds de laatste etappe geleerd?
• Wat moeten we precies financieren, en voor hoe lang?

Geen van die vragen is nieuw. Het team werd alleen niet gevraagd om ze van tevoren te beantwoorden, dus de poort zorgt ervoor dat schrijven live.

Sjablonen versnellen het proces, maar alleen als drie documenten dezelfde ruggengraat delen. De businesscase, het risicoregister en het experimentplan moeten één set aanname-ID’s hebben.

Via die koppeling leest het systeem wat er is veranderd en wijst het middelen toe voor de volgende fase. Hieronder staan drie kant-en-klare sjablonen, waarbij in alle drie een proefproject voor kostenbesparing is verwerkt.

Waarom de poorten langzamer gaan voordat iemand een beslissing neemt

Bij de langzame poorten die we hebben gezien, gaat de tijd voor Het besluit gaat in. De beoordelaars besteden de tijd aan het reconstrueren van wat het team denkt.

EEN McKinsey-enquête uit een in 2019 gepubliceerd onderzoek bleek dat er in het algemeen sprake was van een soortgelijke vertraging bij de besluitvorming:

• 61% zei dat het grootste deel van hun tijd voor besluitvorming wordt besteed aan zonder resultaat.
• Slechts 48% waren het ermee eens dat hun organisaties snel beslissingen nemen.

Die cijfers hebben betrekking op de besluitvorming in het algemeen, op basis van 1.228 respondenten. Gates kampt met een ernstigere vorm van hetzelfde probleem.

Gupta, Smits en Weig van McKinsey beschrijf de poortversie:

“Maar al te vaak zijn stage-gate-vergaderingen niet veel meer dan evaluaties van de productrijpheid, waarbij er maar weinig aandacht is voor besluitvorming.”

Ze wijzen ook op de motivatiekloof: “Aangezien de financiering bij een traditionele ”stage gate’-procedure zelden wordt uitgesteld of stopgezet, hebben deelnemers weinig motivatie om zich voor te bereiden op besluitvormingsgerichte besprekingen.”

Dus teams brengen een status update, elk op hun eigen manier opgemaakt. De beoordelaars zetten dit vervolgens om in steeds weer dezelfde paar vragen, stap voor stap.

Dat betekent dat de poort zijn tijd besteedt aan begrijpend lezen. Het besluit inzake de middelen, het enige telefoontje dat alleen de poort kan plegen, krijgt de resterende minuten.

Een sjabloon bestaat uit de vragen van de Poort, die al vroeg zijn opgeschreven

In de officiële richtlijnen wordt hiervan uitgegaan.

Het Amerikaanse Ministerie van Energie, 2007 richtlijnen voor het stage-gate-proces projecten beoordelen “aan de hand van een reeks criteria die aan het begin van elke fase worden vastgesteld.”

In diezelfde richtlijnen staat beschreven wat er bij elke poort gebeurt:

• Een besluit om door te gaan, uit te stellen of te stoppen
• Goedkeuring van de financiering voor de volgende fase
• Een goedgekeurd plan voor die fase

Maar het belangrijkste punt is dat timing. De criteria zijn “vooraf vastgesteld”, zodat “poortwachters objectieve en tijdige beslissingen kunnen nemen”.”

De auteurs van de ‘Decision-Gate’ van McKinsey beschrijven de werkversie op dezelfde manier:

“De voorbereiding van vergaderingen is grondig en verloopt aan de hand van standaardsjablonen, en de vergaderingen zijn inhoudelijk maar kort.”

Met andere woorden: een sjabloon bestaat uit de vragen van de gate, die worden opgeschreven voordat het team aan de slag gaat. Niemand hoeft ik denk wat de recensenten zullen vragen.

Elk van de 3 onderstaande sjablonen biedt een oplossing voor een specifieke reeks vragen van recensenten van tevoren, zodat je gate de resource-aanroep eerder bereikt.

Drie sjablonen, één ketting

Sjablonen versnellen het proces alleen als ze de taken aan elkaar doorgeven. De businesscase, het risicoregister en het experimentplan moeten als één geheel worden gelezen.

Het idee van onderlinge verbanden is niet nieuw. In Ontdekkingsgestuurde planning, beschreven Rita McGrath en Ian MacMillan een vakgebied dat “in vier onderling samenhangende documenten is vastgelegd.”

Hun schema, afkomstig uit het artikel in de Harvard Business Review uit 1995, ziet er als volgt uit:

• Een omgekeerde winst-en-verliesrekening, waarin de economische basisprincipes worden weergegeven
• Pro forma operationele specificaties, waarin de benodigde werkzaamheden worden uiteengezet
• Een checklist voor belangrijke aannames, zodat aannames ook daadwerkelijk worden gecontroleerd
• Een mijlpaalplanningstabel, waarin “de aannames worden gespecificeerd die bij elke projectmijlpaal moeten worden getoetst”

Elk document wordt bijgewerkt “naarmate het project vordert en er nieuwe gegevens aan het licht komen”. In het mijlpalenoverzicht worden zelfs aannames vermeld “met de juiste cijfers uit de checklist voor aannames”.”

De nummering was er al vanaf het begin, maar onze ervaring leert dat de koppeling niet meer werkt zodra elk document in een eigen map staat met een aparte eigenaar.

Het antwoord van McGrath en MacMillan was een “bewaker van de aannames”, een aangewezen persoon die ervoor zorgt dat de controles bij elke mijlpaal worden uitgevoerd.

Zonder zo iemand, zo waarschuwen ze, is het onwaarschijnlijk dat mensen die “tot aan hun oksels in projectdruk zitten” de updates zullen coördineren. Wijs die persoon aan vóór de eerste mijlpaal.

Gedeelde ID’s houden de keten bij elkaar

Wat we nog zouden toevoegen, is het risicologboek. Neem het dezelfde de ID’s van de aannames (A1, A2, A3) erin opnemen, zodat alle drie de sjablonen één sleutel delen.

Zo verloopt het proces van poort tot poort:

1. Businesscase: nummert zijn belangrijkste aannames, te beginnen met A1.
2. Risicoregister: geeft een rangorde weer van de risico’s die het project zouden doen mislukken, waarbij elk risico is gekoppeld aan de ID van de aanname die het in gevaar brengt.
3. Onderzoeksopzet: test de best gerangschikt aannames vóór de volgende poort, waarbij de drempels voor doorgang en stop vooraf zijn ingesteld.
4. Poort: bekijkt wat er sinds de vorige keer is veranderd en wijst vervolgens middelen toe voor de volgende fase.

Met gedeelde ID’s kan een beoordelaar elk van de hoogst gerangschikte aannames nader onderzoeken aan het risico en de test. Zonder deze gegevens vraagt de poort het opnieuw.

Dat spoor is wat de poort vormt snel, omdat er in de kamer niets opnieuw in elkaar gezet hoeft te worden.

Gedeelde ID’s hebben ook invloed op wat de gate weergeeft. Beoordelaars zien welke aanname-ID’s sinds de vorige keer zijn verplaatst, samen met het bijbehorende bewijsmateriaal.

Het sjabloon voor de businesscase

De businesscase vormt het begin van de keten, dus het is de taak ervan om smal met opzet. Daarin staat wat het project moet opleveren en van welke aannames dat afhankelijk is.

Ga uit van wat het project moet opleveren

McGrath en MacMillan beginnen met de omgekeerde winst-en-verliesrekening, die “van onder naar boven loopt”.”

Je begint met de “vereiste winst” en werkt vervolgens terug naar de omzet en kosten die daarvoor nodig zouden zijn. Elk van die cijfers wordt een aanname.

De volgorde is van belang. Als een prognose wordt opgesteld op basis van de omzet, kan deze ongemerkt stijgen totdat gewoon neemt de hindernis.

Als we uitgaan van de vereiste winst, draait de vraag om. Hoeveel klanten, tegen welke prijs en met welke marge zou het project nodig hebben, en gelooft iemand dat eigenlijk wel?

De velden van de businesscase

Dit is de set velden waarmee we zouden beginnen, plus een proefproject om kosten te besparen dat we in alle drie de sjablonen zullen doorvoeren. Elk veld geeft antwoord op een vraag die je gate zou stellen anders zeg het hardop.

Twee velden doen het grootste deel van het werk. Genummerde aannames worden in het risicologboek ingevoerd, en het vertrouwensveld laat recensenten weten welke nummers opzettelijk gissingen.

Geef elke schatting het label ‘indicatief’, ‘getest’ of ‘basislijn’ mee. Dat is onze schaal, en elk driestappenlabel is geschikt, zolang het maar in de hele portefeuille wordt gebruikt.

Ook in de richtlijnen van de overheid worden businesscases in fasen ingedeeld: die van het Britse ministerie van Financiën Green Book begeleidt een project door de fasen van een strategische conceptstudie, een concept-businesscase en een volledige businesscase.

De vijf casussen (strategisch, economisch, commercieel, financieel en management) zijn “nauw met elkaar verweven perspectieven op hetzelfde voorstel”, die zijn ontwikkeld “via een iteratief proces”.”

Dat patroon zouden we overnemen. Met deze velden hoeft je gate niet langer twee inleidende vragen te stellen: welke getallen worden getest en waarvoor precies wordt gefinancierd.

Het sjabloon voor het risicologboek

Een register dat uitsluitend met het oog op volledigheid is opgezet, faalt op voorspelbare wijze. Het bevat een lijst van alles, en er wordt niets afgewogen tegen de businesscase.

De sectoren zelf zijn al goed ingeburgerd. De Britse regering heeft Teal Book beschrijft elk risico “in termen van oorzaak, gebeurtenis en gevolgen”.”

Hiermee wordt een eigenaar toegevoegd, waarschijnlijkheids- en impactscores, een reactie en een eindbeoordeling. Vervolgens snelheid, of “hoe snel het risico de doelstellingen zou beïnvloeden mocht het zich voordoen.”

Wat de ranglijst betreft, Shrivastava’s 2012 Paper voor het PMI Global Congress is duidelijk: “risico’s met een hoge waarschijnlijkheid en een grote impact staan bovenaan het risicoregister.”

De velden van het risicologboek

We zouden een korte kern uit die lijst behouden en twee kolommen toevoegen. De kolommen ‘Gekoppelde aanname’ en ‘Test’ zijn de kolommen die aansluiten de schakel aan de ketting.

Terug naar het proefproject voor kostenbesparingen, waarvan de A3 luidt: de proeflocaties zullen hun bedrijfsgegevens delen. Hier volgt de risicobeschrijving bij die aanname:

Geen enkel standaardregister dat we hebben gevonden, legt een verband tussen een risico en de aanname die het in gevaar brengt. Dat verband is onze ontwerpkeuze, en juist daardoor werkt de keten.

Het legt ook een stille mislukking bloot. Een risico zonder bijbehorende aanname duidt op een ontbrekende schakel, of op een aanname in de businesscase nooit opgeschreven.

Software kan die leemte opsporen en risico’s signaleren waarvoor geen aanname of test is gekoppeld. Het is nog steeds aan mensen om de risico’s te rangschikken en de beslissing te nemen.

Beperk wat de poort bereikt

Zelfs een gerangschikt register duurt te lang voor de poort. Vraag recensenten dus niet om af te wegen 40 risico’s in één vergadering.

Daarom zouden we het register in tweeën splitsen voor de poort:

• Gate-pakket: de top 5 van risico’s op basis van waarschijnlijkheid en impact, waarbij bij elk risico een aanname wordt genoemd waarvan het gewenste resultaat afhangt
• Bijlage: al het overige, dat door de risicobeheerder wordt bijgewerkt

In het Teal Book worden maatregelen op dezelfde manier gewogen. Er wordt gevraagd om maatregelen die “evenredig” zijn, waarbij de kosten ervan worden afgewogen “tegen de waarschijnlijkheid en de gevolgen van het optreden van het risico”.”

En als bij een top-5-risico geen aanname wordt genoemd, dan spreken de businesscase en het risicoregister boekdelen verschillende verhalen.

Dat is de snelheidswinst die je behaalt met een begrensd, gekoppeld logboek. Recensenten vragen niet meer wat het project de das omdoet, want je top 5 geeft daar al antwoord op.

Het sjabloon voor het experimentplan

Het experimentplan zet gerangschikte risico’s om in bewijsmateriaal vóór de volgende gate. Het belangrijkste veld is het veld dat het gemakkelijkst over het hoofd wordt gezien: een pass-regel die luidt voor de testruns.

Het Kabinetsbureau’s Testen, leren, aanpassen In dat document wordt dat duidelijk vastgelegd in twee instructies:

• “Laten we van meet af aan precies vaststellen welk resultaat we willen bereiken en hoe we dat gaan meten”
• “om in de analysefase vast te houden aan deze vooraf vastgestelde uitkomsten”

Het artikel is geschreven met het oog op gerandomiseerde studies, maar de beginsel doorverwijzingen naar een willekeurige gate-test.

De GOV.UK-servicehandleiding geeft dezelfde aanwijzingen voor de alfafase: “Een cruciaal onderdeel van alpha is het in kaart brengen van je meest risicovolle aannames en deze te toetsen.”

Teams motiveren de overstap naar de bètaversie “aan de hand van de succesindicatoren die je aan het einde van de ontdekkingsfase hebt vastgesteld.” De richtlijnen voor het ontdekken er wordt zelfs gezegd dat het daar “geen nalatigheid is om te stoppen”.

Er is ook correlatieonderzoek dat dit ondersteunt. Het onderzoek van PMI uit 2024 medewerkers die de succescriteria vooraf vaststellen, behalen een netto projectsuccesscore van 41, tegenover 20 bij degenen die dat niet doen.

Dat zijn door de deelnemers zelf gerapporteerde scores uit algemene projecten, maar de tendens komt overeen met de regel: bepaal zelf wat als succes geldt eerste.

De velden van het experimentplan

Eén plan per geteste aanname zorgt ervoor dat het overzichtelijk blijft. Dit zijn de velden die we zouden gebruiken, voortbordurend op het voorbeeld van het risicologboek:

Stel in beide drempels vaststellen voordat de test begint, en de spreiding daartussen klein houden. Een grote spreiding leidt tot te veel resultaten die geen uitsluitsel geven.

Let op het tussenliggende geval in het voorbeeld: 1 site levert. Dit valt tussen twee stoelen in, dus het team moet de gate een grondigere test voorleggen.

En de tabel is laatste Het veld is het filter dat ertoe doet. Als het resultaat geen invloed heeft op de beslissing bij de poort, is het experiment onderzoek en hoort het niet thuis in dit poortpakket.

Met dit plan wordt dus de laatste openstaande vraag van de agenda geschrapt. Elk resultaat valt onder een van de vooraf vastgestelde categorieën: geslaagd, gestopt of een strengere toets.

Rangschikking op basis van risico en kosten

Welke aanname test je als eerste? De bronnen wijzen in twee richtingen:

• Richtlijnen voor de alfa-versie van GOV.UK: wijst op de meest risicovolle aannames
• Van Rita McGrath Startbericht uit 2008: “Probeer de goedkoopste mijlpalen in een vroeg stadium in te plannen en de duurdere of risicovollere mijlpalen voor later te bewaren”

De twee regels staan haaks op elkaar, dus we zouden ze combineren. Eerst rangschikken op risico, en vervolgens de goedkoopste een test die de aanname dat het de hoogste rang heeft zou bevestigen.

Een aanname op het niveau van de kill die goedkoop te testen is, krijgt voorrang. Een dure aanname wacht tot goedkopere tests het aantal mogelijkheden hebben beperkt, voor zover dat mogelijk is.

McGraths opmerking over aannames geldt voor dit alles: “Het belangrijkste is dat je ze opschrijft!”

Dezelfde vragen, diepgaandere antwoorden bij elke poort

Elk nieuw document per gate zorgt ervoor dat de discussie opnieuw begint, omdat de beoordelaars de draad kwijtraken. Een dynamische verzameling van de dezelfde Met 3 sjablonen kunnen ze de delta aflezen.

Hieronder zie je hoe dezelfde velden zich uitbreiden in de vroege, midden- en late fasen:

Zorg voor een evenredige diepgang: het Groene Boek vraagt om “voldoende details om een weloverwogen besluitvorming te ondersteunen”, en niet meer dan dat. De inspanning die in een voorstel wordt gestoken, moet “in verhouding staan tot de omvang, de kosten, de complexiteit en het risico ervan”.”

NASA laat dezelfde werkproducten beoordelingen ondergaan naarmate de volwassenheid ervan toeneemt, en NPR 7123.1D voegt er labels aan toe, zoals ‘Voorlopig’ en ‘Uitgangssituatie’.

Een product waarvoor een basislijn is vastgesteld, kan nog steeds in de ontwikkelingsfase zitten, aangezien het vaststellen van een basislijn “niet noodzakelijkerwijs betekent dat het op dat moment in de levenscyclus volledig volwassen is.”

Behoud dus de kernvelden opgelost over de poorten heen en passen de diepgang aan. De beoordelaars vergelijken vervolgens gelijksoortige zaken met elkaar.

Wanneer sjablonen het proces juist vertragen

Sjablonen hebben een zwakke plek, en de bedenker van Stage-Gate heeft de klachten vastgelegd. Ze uitmonden in bureaucratie wanneer de velden geen basis meer vormen voor een beslissing.

Papierwerk dat tot geen besluit leidt

In een artikel uit 2014, “Wat nu?: Na Stage-Gate”, Robert Cooper somt de kritiekpunten van critici op, namelijk dat het proces ’vol zit met papierwerk, checklists en te veel werk dat geen toegevoegde waarde oplevert.“

Hij beschrijft ook hoe de 'leanere' poorten er bij twee bedrijven uitzagen:

• Bij de Ethicon Surgery-groep van J&J werden businesscases die voorheen “documenten van 30 tot 90 pagina’s waren waarvan de voorbereiding weken in beslag nam” teruggebracht tot 4 pagina's.
• Dankzij het SIMPL-proces van P&G zijn de opleveringspakketten teruggebracht “tot slechts zes pagina’s”.”

Cooper baseert zich hierbij op bronnen uit 2005 en 2007, dus beschouw ze als illustraties. In geen van beide wordt gemeten hoeveel sneller de poorten werkten.

De definitie die hij aanhaalt, is kort: bureaucratie is “werk dat geen meerwaarde oplevert”. Volgens die maatstaf is een sector waarin nooit een besluit wordt gewijzigd, bureaucratie.

Vraag voor elk vakgebied of een beoordelaar zou besluiten anders zonder dat.

Een checklist op papier is niet hetzelfde als het daadwerkelijk gebruiken ervan

De chirurgie biedt hier een nuttige analogie, zij het met een kanttekening. De checklist voor chirurgische veiligheid van de WHO werd ingevoerd in 8 ziekenhuizen in 8 steden, waarbij een vergelijking tussen de situatie vóór en na de invoering werd gemaakt.

Haynes en collega’s rapporteerde deze resultaten in 2009:

• Het aantal sterfgevallen daalde van 1,5% naar 0,8%.
• Het aantal complicaties daalde van 11,01 TP5T naar 7,01 TP5T.

Vervolgens stimuleerde Ontario adoptie en verplichtte het ziekenhuizen om hierover openbaar verslag uit te brengen. Urbach en collega’s onderzocht 101 ziekenhuizen en constateerde geen significante daling van het aantal sterfgevallen of complicaties.

Het onderzoek uit 2009 had geen gelijktijdige controlegroep, en een operatie is geen ‘gate meeting’. Maar als je beide onderzoeken samen bekijkt, vormen ze een nuttige waarschuwing.

Onze lezing: een ingevuld sjabloon alleen Het voldoen aan een regel verandert niets aan het gesprek, en dat is waar de beslissing wordt genomen.

Het ‘leeg-doek’-bezwaar

Cooper beschrijft ook een radicalere optie, die bij Corning is getest, waarbij wordt afgestapt van op sjablonen gebaseerde deliverables. In zijn verslag schrijft hij:

• Elk team “begint met een leeg doek” en brengt zijn eigen visie in kaart.
• “Er worden geen activiteiten uitgevoerd louter omdat ze ‘op een lijst’ in een of andere handleiding staan, of omdat er deliverables worden opgesteld omdat er een sjabloon is dat moet worden ingevuld.”
• Het addertje onder het gras, waarover hij heel openhartig is: “projectteams moeten zeer ervaren zijn om dit te laten slagen.”

Ons antwoord is dat het sjabloon is dat overzicht, in een herhaalbare vorm. Het bevat de kritische aannames van Cooper en het bewijsmateriaal dat nodig is om deze te toetsen, voor teams die niet allemaal uit experts bestaan.

Zoals Cooper meldt, heeft P&G in dit verband een oproep gedaan met betrekking tot het proces. Dietmar Bressau, de bedrijfsleider voor het beheer van de innovatiediamant, wilde één gemeenschappelijk proces dat was afgestemd op het risico van elk initiatief.

Zijn waarschuwing: “Als je de deur opent voor twee of drie processen, volgen er al snel vier, vijf en zes. Uiteindelijk kan er van alles gebeuren.”

Zorg er dus voor dat je één samenhangende set sjablonen hebt en de omvang ervan afstemmen op het risico. Na een paar projecten, verwijderen elk gebied waar nooit een beslissing is gewijzigd, voor de gehele portefeuille.

Zet de drie aan elkaar vast voordat je ze gaat oppoetsen

Een gate verloopt sneller wanneer de vragen al vóór de vergadering worden beantwoord, in een vorm die elke beoordelaar herkent. Dankzij gekoppelde ID’s blijft die vorm consistent tussen verschillende gates.

Begin met 4 bewegingen, in deze volgorde:

1. Nummer de aannames in je huidige businesscase, beginnend bij A1.
2. Rangschik de risico’s die het project zouden doen mislukken, waarbij elk risico is voorzien van een aanname-ID.
3. Stel, voordat er tests worden uitgevoerd, drempelwaarden voor het doorlaten en stoppen vast voor de meest risicovolle aannames.
4. Vraag de volgende poort om te controleren wat er is verplaatst, en voer vervolgens de wijzigingen door of stop.

Dus poets er geen enkele enkel Eerst het sjabloon. Zelfs een prachtige businesscase met een groot aantal aannames zorgt er nog steeds voor dat de aanvraag wordt teruggestuurd voor verdere toelichting.

Met behulp van tools kunnen gekoppelde ID’s gemakkelijker van poort naar poort worden gevolgd. Er moet echter nog steeds iemand zijn die de aannames up-to-date houdt, en de poort moet nog steeds een beslissing nemen of het proces stoppen.

En beoordeel de poort aan de hand van de kwaliteit van wat het besluit. Een kortere vergadering die financiert het verkeerde project is geen vooruitgang.

Download ons gratis ebook Projectportfolio: Van kansen naar waarde om te leren hoe je stage-gate-beslissingen kunt nemen als onderdeel van een gestuurde innovatieportefeuille.

Vraag een demo aan om te zien hoe Accept Mission u gekoppelde businesscases, scorekaarten en gate-beslissingen in één overzicht biedt voor uw gehele innovatieportfolio.