In dit inzicht
Voor wie is dit inzicht?
Voor managementteams die een belangrijk initiatief willen uitvoeren en vooraf willen weten waar de dagelijkse werking de strategie kan vertragen.
Drie bedrijven kunnen hetzelfde probleem hebben: een goedgekeurd initiatief geraakt niet op kruissnelheid. De oorzaken kunnen totaal verschillen. Bij het ene CRM-project heeft niemand tijd om processen opnieuw te ontwerpen. Bij een AI-pilot ontbreekt vertrouwen in de output. Bij een duurzaam leveranciersprogramma wil iedereen wel meewerken, maar leveranciersdata komt niet in een bruikbaar proces terecht.
Dat verschil is belangrijk. “Meer change management” is geen bruikbare interventie wanneer je niet weet waar uitvoering precies energie verliest. De ene situatie vraagt beslisrecht, de andere capaciteit en een derde een andere workflow.
Execution readiness gaat over de vraag of de organisatie voldoende voorwaarden heeft om een gekozen initiatief werkelijk uit te voeren.
De scan hieronder gebruikt zes gebieden en vraagt per gebied om bewijs. Daardoor krijg je minder snel een geruststellende score die vooral op gevoel gebaseerd is.
Drie projecten die op een andere reden vastlopen
CRM: techniek op schema, proces achter
Een CRM-project kan technisch perfect verlopen. Licenties zijn gekocht, velden zijn aangemaakt en de migratiedatum staat vast. Toch blijkt twee weken voor livegang dat marketing en sales een andere definitie van een gekwalificeerde lead gebruiken. De technische implementatie is klaar voor een proces dat inhoudelijk nog niet beslist is.
De readiness-zwakte zit hier vooral in richting en eigenaarschap. Er ontbreekt geen motivatie voor het project. Er ontbreekt een besluit over de commerciële werkwijze die het systeem moet ondersteunen.
AI: enthousiaste pilot, weinig routinematig gebruik
Een marketingteam experimenteert met een AI-assistent voor research en drafts. De eerste demo's zijn sterk en verschillende medewerkers gebruiken de tool. Na zes weken blijkt dat iedereen een eigen werkwijze heeft. Niemand weet welke bronnen leidend zijn en de review verschilt per medewerker.
De readiness-zwakte zit hier in werkbaarheid en feedback. Het team heeft toegang en interesse, maar de workflow is nog te impliciet om betrouwbaar op te schalen.
Leveranciersdata: strategisch gewenst, operationeel verweesd
Een bedrijf wil duurzaamheidsdata systematisch bij leveranciers verzamelen. Procurement stuurt een spreadsheet rond, leveranciers antwoorden in verschillende formaten en marketing vraagt later opnieuw naar dezelfde gegevens voor een claim. Het project heeft richting, alleen de dataketen en het eigenaarschap ontbreken.
Deze drie cases laten zien waarom een readinessscan vóór de uitvoering nuttig is. De zwakke zone bepaalt welke interventie zinvol wordt.
De maverik Execution Readiness Scan kijkt naar zes voorwaarden
| Gebied | Praktische vraag | Welk bewijs wil je zien? |
|---|---|---|
| Richting | Kan het team uitleggen welk probleem dit initiatief oplost en wat succes betekent? | Eén duidelijke uitkomst en herkenbare besliscriteria. |
| Keuzes | Welke bestaande prioriteit krijgt minder capaciteit omdat dit initiatief voorrang krijgt? | Agenda, budget of resourceplan waarin de keuze zichtbaar is. |
| Eigenaarschap | Wie mag beslissen wanneer uitvoering vastloopt? | Een eigenaar met tijd en beslisrecht. |
| Capaciteit | Welke mensen moeten werk verplaatsen om dit mogelijk te maken? | Concrete uren of rollen in plaats van “het team”. |
| Werkbaarheid | Past het nieuwe gedrag in processen, systemen en informatie? | Een geteste workflow met uitzonderingen. |
| Feedback | Hoe merken we tijdig dat uitvoering afwijkt? | Een klein aantal signalen en een reviewmoment. |
Je kunt draagvlak door deze zes gebieden heen lezen in plaats van er één losse score van te maken. Mensen kunnen bijvoorbeeld heel gemotiveerd zijn en toch terugvallen omdat de nieuwe werkwijze twee extra administratieve stappen vraagt. In dat geval is werkbaarheid belangrijker dan nog een communicatiecampagne.
Vraag per onderdeel om concreet bewijs
De scan wordt zwak wanneer managers elk onderdeel op gevoel een zeven op tien geven. Vraag daarom steeds: waar zien we dit in de werking?
- Richting. Laat drie betrokkenen afzonderlijk beschrijven wat het initiatief na zes maanden moet hebben veranderd.
- Keuzes. Kijk welke agenda, projecten of budgetten werkelijk minder prioriteit kregen.
- Eigenaarschap. Leg één realistisch conflict voor en vraag wie de beslissing neemt.
- Capaciteit. Zet noodzakelijke uren naast de werkelijk beschikbare ruimte.
- Werkbaarheid. Laat iemand het nieuwe proces end-to-end uitvoeren met een echte case.
- Feedback. Vraag welk signaal binnen twee weken toont dat adoptie of uitvoering achterblijft.
Deze aanpak maakt readiness bespreekbaar zonder te doen alsof de scan een wetenschappelijke score oplevert. Je zoekt naar de zone waar aanvullend werk de kans op uitvoering het meest verhoogt.
Case. CRM-implementatie vóór go-live
Neem het eerdere CRM-project. Het management wil over acht weken live. De softwareconfiguratie is ver gevorderd en het project wordt intern als “groen” gerapporteerd.
| Gebied | Bewijs | Readiness | Actie |
|---|---|---|---|
| Richting | Doel is betere handoff en pipelinezicht. | Goed | Ongewijzigd |
| Keuzes | Salestraining en datacleanup staan wel in agenda. | Redelijk | Bescherm de geplande tijd |
| Eigenaarschap | Projectmanager beheert techniek, commerciële definities hebben geen eigenaar. | Zwak | Wijs inhoudelijk eigenaar aan |
| Capaciteit | Key users hebben amper vrijgemaakte tijd. | Zwak | 2 uur/week per key user reserveren |
| Werkbaarheid | Happy flow getest, uitzonderingen nauwelijks. | Zwak | Test 10 echte dossiers |
| Feedback | Gebruik wordt pas na livegang gemeten. | Redelijk | Adoptiesignalen vooraf kiezen |
De juiste interventie is hier geen nieuwe softwarefeature. De organisatie moet drie weken besteden aan definities, echte dossiers en beschermde key-usercapaciteit. Dat kan de livegang minder spectaculair maken en de kans vergroten dat het systeem na twee maanden werkelijk gebruikt wordt.
Het artikel over RevOps, MarkOps en SalesOps behandelt die eigenaarschapsvraag verder.
Twee kortere cases met een andere bottleneck
AI-adoptie
Een marketingteam gebruikt AI voor wekelijkse performanceanalyse. Richting en capaciteit zijn prima. De workflow blijft echter onduidelijk: verschillende medewerkers gebruiken andere databronnen en de output wordt op wisselende diepte gecontroleerd. De intervention is hier procesontwerp: één inputset, duidelijke reviewregels en een escalatiepad voor opvallende conclusies. Het artikel Een AI-tool is nog geen AI-adoptie gaat verder op die logica.
Duurzaamheidsdata van leveranciers
Procurement wil data verzamelen en management steunt het doel. De zwakte zit in werkbaarheid. Leveranciers krijgen brede vragen, definities zijn niet eenduidig en niemand beheert versie of bron. Een readinessinterventie begint hier bij een kleiner datamodel en een duidelijke eigenaar, niet bij extra communicatie naar leveranciers.
Koppel iedere zwakke zone aan een andere interventie
| Zwakke zone | Typische interventie |
|---|---|
| Richting | Herformuleer doel en succescriteria en test of betrokkenen hetzelfde begrijpen. |
| Keuzes | Schrap of vertraag concurrerende initiatieven en reserveer capaciteit. |
| Eigenaarschap | Leg beslisrechten en escalatie expliciet vast. |
| Capaciteit | Maak tijd vrij, verklein de scope of verschuif timing. |
| Werkbaarheid | Test de workflow op echte cases en verwijder onnodige frictie. |
| Feedback | Kies vroege signalen en een vast reviewritme. |
Dit voorkomt de reflex om ieder executieprobleem met dezelfde oplossing te behandelen. Meer training helpt weinig wanneer de eigenaar geen beslisrecht heeft. Meer managementcommunicatie helpt weinig wanneer medewerkers structureel geen tijd hebben.
Doe de scan op drie momenten
Een readinessscan is vooral nuttig wanneer de vragen veranderen naarmate een initiatief vordert.
- Voor de start toets je vooral richting, keuzes, eigenaarschap en capaciteit.
- Na de eerste pilot verschuift de aandacht naar werkbaarheid, uitzonderingen en bewijs uit echte gebruikers.
- Vóór opschaling kijk je of processen, support en feedback ook bij groter volume standhouden.
Hou daarbij de oorspronkelijke scan bij. Het verschil tussen twee momenten vertelt vaak meer dan de absolute beoordeling. Een initiatief kan bijvoorbeeld technisch vooruitgaan en tegelijk minder uitvoerbaar worden omdat nieuwe afhankelijkheden zichtbaar zijn geworden.
Wanneer meerdere initiatieven tegelijk laag scoren op capaciteit, ligt de oplossing mogelijk een niveau hoger. Dan moet het management terug naar het portfolio en opnieuw kiezen. Het artikel Welke strategische initiatieven verdienen je volgende 90 dagen? sluit daar rechtstreeks op aan.
Herken vroege signalen dat readiness verslechtert
Execution readiness is geen statische eigenschap. Een initiatief kan sterk starten en tijdens uitvoering zwakker worden. Nieuwe afhankelijkheden worden zichtbaar, sleutelpersonen vallen uit of een onverwachte workload drukt andere prioriteiten weg.
Gebruik daarom een klein aantal waarschuwingssignalen. Ze hoeven niet in een dashboard; een maandelijkse review kan voldoende zijn.
- Beslissingen blijven langer openstaan omdat niemand zich bevoegd voelt.
- Key users missen workshops of leveren input structureel te laat.
- Dezelfde uitzondering wordt meerdere keren handmatig opgelost.
- Projectwerk gebeurt vooral buiten normale uren.
- De scope groeit terwijl de beschikbare capaciteit gelijk blijft.
- Management vraagt opnieuw om oude outputs of processen die het initiatief moest vervangen.
Zo'n signaal vraagt eerst diagnose. Een terugkerende uitzondering kan bijvoorbeeld betekenen dat de workflow onvolledig is. Gemiste workshops kunnen capaciteit tonen of onvoldoende ervaren prioriteit.
Maak readiness bespreekbaar zonder schuldvraag
De scan werkt het best wanneer lage readiness geen beoordeling van mensen wordt. “Capaciteit is zwak” betekent dat de organisatie te veel vraagt van de beschikbare tijd, niet dat medewerkers onvoldoende gemotiveerd zijn. “Eigenaarschap is zwak” betekent dat beslisrechten onduidelijk zijn, niet dat iemand zijn verantwoordelijkheid ontloopt.
Dat taalgebruik maakt het makkelijker om structurele problemen aan te pakken. De scan wordt dan een ontwerpgesprek over werk en minder een evaluatie van personen.
Geef de sponsor een concrete rol
Strategische initiatieven hebben vaak een sponsor die formeel steun geeft en daarna weinig in het dagelijkse proces voorkomt. Maak ook die rol praktisch. De sponsor lost niet elk operationeel probleem zelf op. Zijn rol wordt vooral belangrijk wanneer scope, capaciteit of prioriteiten botsen en een snelle beslissing nodig is.
Een bruikbare sponsorcheck bevat drie vragen:
- Welke beslissingen mag het projectteam zelf nemen?
- Welke conflicten worden binnen hoeveel tijd naar de sponsor geëscaleerd?
- Welke bestaande prioriteit mag de sponsor verlagen wanneer capaciteit tekortschiet?
Daarmee krijgt sponsorship een echte functie in execution readiness. Het voorkomt dat een projectteam weken wacht op beslissingen die alleen op managementniveau genomen kunnen worden.
Maak readiness zichtbaar in de projectstart
Neem de scan op in de eerste projectbespreking en laat ieder readinessgebied eindigen met één concrete afspraak. Bij richting kan dat een herformulering van succes zijn. Bij capaciteit kan het een beschermde blok in de agenda worden. Bij eigenaarschap kan het een expliciet beslisrecht zijn.
Zo vermijd je dat readiness een aparte workshop wordt waarvan de resultaten nergens landen. De waarde zit in de vertaling naar projectontwerp. Een initiatief met lage readiness kan nog steeds starten, zolang duidelijk is welke risico's bewust worden gedragen en welke eerst worden aangepakt.
Gebruik daarnaast een eenvoudig stopmoment. Wanneer twee kernvoorwaarden na een afgesproken periode niet verbeteren, moet het management opnieuw beslissen over scope of timing. Dat voorkomt dat een initiatief maandenlang “in uitvoering” blijft terwijl de organisatie feitelijk niet klaar is om het te dragen.
Starten, verkleinen of uitstellen wanneer meerdere voorwaarden zwak zijn?
Een lage readinessscore betekent niet automatisch dat een initiatief moet wachten. De beslissing hangt af van welke voorwaarden zwak zijn en hoeveel schade een mislukte start kan veroorzaken.
| Situatie | Logische keuze | Waarom |
|---|---|---|
| Richting onduidelijk + eigenaar ontbreekt | Uitstellen | Het team kan nog niet betrouwbaar beslissen wat het project moet opleveren of wie conflicten oplost. |
| Capaciteit beperkt + scope groot | Scope verkleinen | Een smaller initiatief kan dezelfde kernhypothese testen zonder de organisatie te overvragen. |
| Werkbaarheid onzeker + risico beheersbaar | Pilot starten | Echte cases leveren sneller bewijs over uitzonderingen en frictie. |
| Feedback zwak + rest sterk | Starten met extra meetlaag | De uitvoering kan beginnen terwijl vroegsignalering tegelijk wordt ingericht. |
Stel dat een CRM-project zowel lage capaciteit als zwakke werkbaarheid heeft. Je kunt de volledige organisatiebrede uitrol uitstellen en toch met één salesregio of één pipeline starten. Daarmee leer je hoe het proces zich in echte dossiers gedraagt terwijl de belasting beperkt blijft.
Maak de beslissing expliciet in het projectcharter: welke readinessproblemen accepteren we tijdelijk, welke moeten vóór start opgelost zijn en welk signaal dwingt tot herziening? Dat voorkomt dat “we starten en zien wel” later als impliciet beleid wordt behandeld.
Execution readiness werkt vaker als een keten dan als een gemiddelde
Zes readinessvoorwaarden van gemiddeld zeven op tien kunnen geruststellend ogen. Alleen kan één kritieke zwakte de uitvoering nog steeds blokkeren. Een team kan de verandering perfect begrijpen en voldoende gemotiveerd zijn terwijl niemand een prijsconflict finaal mag beslissen. Of alle beslisrechten zijn helder terwijl dezelfde twee experts al op vier andere projecten zitten.
Daarom behandel ik execution readiness liever als een keten. Je zoekt niet naar een mooi gemiddelde, maar naar de voorwaarde die als eerste de uitvoering begrenst.
Zoek bottleneckrollen voordat je het projectplan groter maakt
Wanneer werk vertraagt, is de reflex vaak extra opvolging. Soms is de oorzaak veel eenvoudiger. Eén product owner moet tegelijk processen ontwerpen, data valideren en uitzonderingen beslissen. Meer meetings maken die persoon niet minder schaars.
Maak voor iedere kritieke rol zichtbaar
- welke deliverables exclusief van die rol afhangen;
- hoeveel tijd per week werkelijk beschikbaar is;
- welke andere initiatieven dezelfde capaciteit claimen;
- welke beslissingen kunnen worden gedelegeerd;
- welk werk kan verdwijnen of later komen.
Zo wordt capaciteit een ontwerpvariabele in plaats van een probleem dat pas tijdens uitvoering ontdekt wordt.
Meet decision latency wanneer werk vooral op antwoorden wacht
Een project kan technisch snel bewegen en toch veel kalenderdagen verliezen tussen twee beslissingen. Wanneer pricing, legal of datadefinities telkens twee weken wachten op dezelfde sponsor, is decision latency een volwaardige execution metric.
Noteer daarom bij blokkades niet alleen wat beslist moet worden, maar ook wanneer de vraag ontstond, wie bevoegd is en wanneer een antwoord kwam. Dat maakt duidelijk of vertraging uit uitvoering of governance komt.
Test het toekomstige proces met dossiers die vandaag al lastig zijn
Een nieuwe workflow wordt graag getest met een nette standaardcase. Voeg bewust ook dossiers toe met ontbrekende informatie, meerdere teams of een bestaande workaround. Wanneer de nieuwe flow precies op dezelfde plek vastloopt, heb je oude frictie vooral in een nieuw systeem gegoten.
Laat verschillende mensen dezelfde moeilijke case uitvoeren. Verschillende uitkomsten tonen waar beslislogica nog impliciet is en waar extra procesdocumentatie weinig zal helpen zolang ownership onduidelijk blijft.
Gebruik readiness gates om commitment stapsgewijs te verhogen
| Moment | Minimaal bewijs |
|---|---|
| Voor pilot | Probleem, owner, kritieke capaciteit en eerste beslisrechten helder |
| Voor bredere uitrol | Waarde en werkbaarheid bewezen op normale én moeilijke cases |
| Voor go-live | Support, ownership, dependencies en uitzonderingen getest |
| Voor opschaling | Waarde, adoptie en beheerlast voldoende stabiel |
Een gate is geen bureaucratische checklist. Ze koppelt extra commitment aan extra bewijs.
Readiness eindigt niet bij go-live
Na go-live verschuift het probleem. De projectgroep trekt zich terug en de normale organisatie moet ownership, onboarding en support overnemen. Dat is precies waar adoptie van de nieuwe werkwijze belangrijker wordt.
Execution readiness helpt de verandering uitvoerbaar maken. Adoptie toont daarna of die verandering zonder uitzonderlijke projectenergie onderdeel van het dagelijkse werk wordt.
Bronbasis
De scan is een originele maverik-synthese, geïnformeerd door strategy-execution- en change-denken. De zes gebieden zijn geformuleerd als praktische diagnosevragen en reproduceren geen beschermd cursusframework.