- Een roadmap die niet aan een bedrijfsuitkomst is gekoppeld, is een wensenlijst, geen sturingsinstrument
- Werk met horizons van drie tijdsbestekken in plaats van één jaarplanning: nu, volgend en later
- Prioriteer met een vast raamwerk in plaats van met de luidste stem in de vergadering
- Elk item heeft een eigenaar en een geschat kostenplaatje nodig, of het blijft een intentie zonder uitvoering
- Een roadmap die niet minstens elk kwartaal wordt herzien, is binnen een jaar achterhaald
1. Begin bij bedrijfsuitkomsten, niet bij technologie
De meest voorkomende fout bij het bouwen van een IT-roadmap is beginnen met een lijst technologieën die het bedrijf zou moeten aanschaffen. Dat levert een lijst op die intern logisch aanvoelt voor IT, maar die niemand anders in het bedrijf kan verdedigen wanneer het budget ter discussie staat. Een roadmap die standhoudt, begint andersom: welke bedrijfsuitkomsten moeten het komende jaar worden bereikt, en welke IT-capaciteiten zijn daarvoor nodig.
Als het bedrijf van plan is naar twee nieuwe locaties uit te breiden, is de IT-vraag niet "hebben we nieuwe laptops nodig", maar "welke infrastructuur, welk identiteitsbeheer en welke ondersteuningscapaciteit maken die uitbreiding mogelijk zonder dat de beveiliging verwatert." Als het doel is de omzet per medewerker te verhogen, is de vraag welke systemen handmatig werk vertragen en welke automatisering dat oplost. Elk item op de roadmap moet in één zin terug te voeren zijn op een uitkomst die een directielid herkent.
2. Werk met drie horizons in plaats van één jaarplanning
Een enkel jaarplan behandelt een project dat morgen moet starten hetzelfde als een project dat over negen maanden pas relevant wordt, wat het moeilijk maakt om prioriteiten te onderscheiden. Een indeling in drie horizons lost dat op: horizon een omvat wat nu wordt uitgevoerd of binnen dit kwartaal start, horizon twee wat is gepland maar nog niet begonnen, meestal binnen twee tot drie kwartalen, en horizon drie wat op de radar staat maar nog onvoldoende is uitgewerkt om te plannen.
Horizon één moet zeer gedetailleerd zijn: eigenaar, budget, mijlpalen. Horizon twee heeft globale scope en een indicatief budget nodig. Horizon drie is bewust vaag, een lijst van signalen die worden gevolgd totdat ze rijp genoeg zijn om naar horizon twee te verschuiven. Dit voorkomt dat de roadmap wordt overladen met gedetailleerde plannen voor dingen die pas over anderhalf jaar spelen en tegen die tijd toch zijn veranderd.
3. Prioriteer met een raamwerk, niet met de luidste stem
Zonder een expliciet prioriteringsraamwerk wint doorgaans het project met de meest overtuigende voorstander in de vergadering, wat zelden hetzelfde is als het project met de hoogste bedrijfswaarde. Een eenvoudig raamwerk dat goed werkt voor het mkb, scoort elk kandidaat-item op drie assen: impact op de bedrijfsuitkomst, urgentie inclusief beveiligings- en compliancerisico bij uitstel, en uitvoeringskosten inclusief tijd van het team.
Items met hoge impact en hoge urgentie gaan naar horizon één. Items met hoge impact maar lage urgentie gaan naar horizon twee. Items met lage impact, ongeacht hoe enthousiast iemand erover is, gaan onderaan de lijst of eraf. Dit raamwerk hoeft niet ingewikkeld te zijn om effectief te zijn; het voorkomt vooral dat beslissingen worden genomen op basis van wie het hardst roept.
4. Elk item krijgt een eigenaar en een kostenplaatje
Een roadmap-item zonder toegewezen eigenaar is een intentie, geen plan. Zodra een item de horizon-één-status bereikt, moet er één naam aan gekoppeld zijn die verantwoordelijk is voor de voortgang, ongeacht of die persoon het werk zelf uitvoert. Zonder dat verdampt verantwoordelijkheid zodra de eerste onverwachte prioriteit zich aandient.
Een roadmap zonder kostenplaatje is geen plan, het is een verlanglijst die wacht tot iemand de rekening presenteert.
Hetzelfde geldt voor kosten. Een grove schatting, zelfs een bandbreedte, is voldoende voor horizon twee en drie, maar horizon één heeft een specifiek bedrag nodig dat is afgestemd met wie het budget beheert. Roadmaps die worden goedgekeurd zonder kostenschatting, lopen vrijwel altijd vast op het moment dat de factuur binnenkomt en niemand die had zien aankomen.
5. Breng afhankelijkheden tussen items in kaart
IT-initiatieven staan zelden op zichzelf. Een migratie naar een nieuw identiteitsplatform kan een voorwaarde zijn voor drie andere projecten die op de roadmap staan. Een netwerkupgrade kan nodig zijn voordat een nieuwe locatie operationeel kan worden. Wanneer deze afhankelijkheden niet expliciet in kaart zijn gebracht, wordt een project vaak gepland zonder te beseffen dat het afhankelijk is van iets dat pas twee kwartalen later klaar is.
Een eenvoudig afhankelijkheidsoverzicht, zelfs een korte notitie per item met "vereist X voordat dit kan starten", voorkomt de meest voorkomende oorzaak van vastgelopen roadmaps: een team dat begint aan iets waarvan de fundering nog niet is gelegd.
6. Stel een vast herzieningsritme in
Een roadmap die eenmaal per jaar wordt opgesteld en daarna in een la verdwijnt tot de volgende jaarplanning, is binnen zes maanden achterhaald. Bedrijfsprioriteiten verschuiven, budgetten veranderen, en nieuwe risico's dienen zich aan die niet op de oorspronkelijke lijst stonden. Een kwartaalherziening, kort maar verplicht, houdt de roadmap in lijn met de werkelijkheid: welke items zijn afgerond, welke zijn vertraagd en waarom, wat is nieuw binnengekomen op horizon drie, en welke items verschuiven tussen horizons.
7. Communiceer de roadmap buiten IT
Een roadmap die alleen binnen IT wordt gedeeld, mist het grootste deel van zijn waarde. De directie moet de roadmap kunnen zien in bedrijfstaal, niet in technische termen, om budgetbeslissingen te kunnen onderbouwen. Andere afdelingen moeten weten wat eraan komt zodat zij kunnen plannen rond geplande veranderingen in plaats van erdoor te worden verrast. Een beknopte, niet-technische samenvatting van de roadmap, gedeeld op kwartaalbasis met de directie, is vaak het verschil tussen een IT-budget dat wordt goedgekeurd en een dat wordt bevraagd.
De roadmap levend houden
Een roadmap is geen document, het is een proces. De bedrijven die er het meeste uit halen, behandelen de kwartaalherziening als een vast onderdeel van hoe IT wordt bestuurd, niet als een aparte exercitie die ergens bovenop komt. Dat vraagt om een eigenaar, iemand die verantwoordelijk is voor het actueel houden van de roadmap, het bijeenroepen van de herziening en het bewaken dat items daadwerkelijk vooruitgang boeken in plaats van kwartaal na kwartaal te blijven staan.
- Koppel elk roadmap-item expliciet aan een bedrijfsuitkomst die een directielid herkent.
- Verdeel items over drie horizons in plaats van één jaarplanning, met afnemende detailniveau naarmate de horizon verder weg ligt.
- Gebruik een vast raamwerk van impact, urgentie en kosten om prioriteiten te bepalen.
- Wijs een eigenaar en een kostenschatting toe aan elk item zodra het horizon één bereikt.
- Herzie de roadmap elk kwartaal en communiceer een niet-technische versie naar de directie.
Bedrijven zonder een aangewezen IT-leider die deze discipline bewaakt, zien vaak dat de roadmap terugvalt naar een jaarlijkse exercitie die niemand herziet. Het fractionele IT-managementaanbod van Cyvra neemt roadmapbeheer op als terugkerende verantwoordelijkheid, zodat de planning in lijn blijft met wat het bedrijf daadwerkelijk nodig heeft.
Gartner publiceert onderzoek naar IT-roadmapmethodieken op gartner.com. Harvard Business Review behandelt strategische planning en prioritering op hbr.org.