Een nieuw IT project starten zonder haalbaarheidsonderzoek is als een huis bouwen zonder de grond te testen. Misschien gaat het goed. Maar als het misgaat, ontdek je dat pas als de fundering al gestort is en de kosten niet meer te overzien zijn.
Toch slaan veel MKB-bedrijven deze cruciale stap over. De druk om snel te digitaliseren is groot, leveranciers beloven gouden bergen, en het management wil resultaten zien. Ken je de digitale volwassenheid van je organisatie al? Die nulmeting bepaalt mede of een IT project kans van slagen heeft. Begrijpelijk. Maar de cijfers liegen niet: volgens het Standish Group CHAOS 2020-rapport slaagt slechts 31% van alle IT-projecten, is 50% "challenged" (budget, planning of scope overschreden) en faalt 19% volledig. Voor AI-projecten is dat beeld nog somberder: RAND Corporation (2024) stelt dat meer dan 80% van AI-projecten niet in productie komt — exact twee keer zo hoog als de faalratio van reguliere IT-projecten. Een gedegen haalbaarheidsonderzoek verkleint dat risico aanzienlijk.
Of het nu gaat om een AI-implementatie (lees ook ons artikel over het traject van AI assessment naar live), een nieuw ERP-systeem, een webshop-migratie of procesautomatisering: een gedegen haalbaarheidsonderzoek helpt je om de juiste go/no-go beslissing te nemen.
Wanneer Is een Haalbaarheidsonderzoek Nodig?
Niet elk IT project vereist een volledig haalbaarheidsonderzoek. Een kleine website-aanpassing of het toevoegen van een plugin kun je zonder uitgebreid vooronderzoek uitvoeren. Maar zodra een of meer van de volgende situaties van toepassing is, wordt een haalbaarheidsonderzoek essentieel:
- Investering boven EUR 25.000 - Bij grotere bedragen wil je zekerheid over het rendement
- Meerdere systemen moeten gekoppeld worden - Integratie-complexiteit is een van de grootste risicofactoren
- Het project raakt kernprocessen - Als de dagelijkse operatie afhankelijk wordt van het nieuwe systeem
- Er is onzekerheid over de technische mogelijkheden - Kan de gewenste oplossing technisch gebouwd worden?
- Organisatorische verandering is nodig - Als medewerkers anders moeten gaan werken
- De tijdsdruk is hoog - Juist dan wil je vooraf weten of de planning realistisch is
Een haalbaarheidsonderzoek kost doorgaans 5-10% van het totale projectbudget. Bij een project van EUR 100.000 investeer je dus EUR 5.000 tot EUR 10.000 in vooronderzoek. Die investering verdient zichzelf terug door het voorkomen van mislukte projecten of kostbare koerswijzigingen halverwege.
De 4 Typen Haalbaarheid
Een grondig haalbaarheidsonderzoek bekijkt het project vanuit vier perspectieven. Elk perspectief kan een dealbreaker zijn, daarom is het belangrijk om ze alle vier te onderzoeken. Het Project Management Institute hanteert vergelijkbare feasibility-dimensies in de PMBOK Guide: een feasibility study levert de basis voor de business case die vervolgens doorgroeit naar een project charter.
1. Technische Haalbaarheid
De meest voor de hand liggende vraag: kan het technisch gebouwd worden?
Wat je onderzoekt:
- Bestaan de benodigde technologieen en zijn ze volwassen genoeg?
- Kunnen bestaande systemen gekoppeld worden via APIs of middleware?
- Is de benodigde data beschikbaar en van voldoende kwaliteit?
- Past de oplossing binnen de huidige IT-infrastructuur?
- Zijn er licentie- of compliancebeperkingen?
Valkuil: Leveranciers beantwoorden de vraag "kan het?" bijna altijd met ja. De echte vraag is: kan het binnen de gestelde kaders van tijd, budget en complexiteit? Een AI Assessment kan helpen om de technische haalbaarheid objectief in kaart te brengen.
2. Financiele Haalbaarheid
Hier draait het om de business case: levert het project meer op dan het kost?
Wat je onderzoekt:
- Totale investering (licenties, implementatie, training, beheer)
- Verwachte besparingen (arbeidstijd, foutreductie, snelheid)
- Terugverdientijd en ROI over 3-5 jaar
- Doorlopende kosten na livegang
- Opportuniteitskosten: wat kost het om niets te doen?
Kosten-baten analyse template:
| Categorie | Eenmalig | Jaarlijks | Toelichting |
|---|---|---|---|
| Licentiekosten | EUR X | EUR X | Software, cloud, per-user fees |
| Implementatie | EUR X | - | Configuratie, maatwerk, integratie |
| Training | EUR X | EUR X/2 | Initieel + jaarlijkse bijscholing |
| Beheer en onderhoud | - | EUR X | Hosting, updates, support |
| Besparing arbeidstijd | - | -EUR X | FTE-uren x uurtarief |
| Foutreductie | - | -EUR X | Minder fouten = minder herstelwerk |
| Omzetstijging | - | -EUR X | Snellere doorlooptijd, betere service |
Vuistregel: Een gezonde IT-investering heeft een terugverdientijd van 12-24 maanden. Korter dan 12 maanden is uitstekend, langer dan 36 maanden is risicovol voor het MKB.
3. Organisatorische Haalbaarheid
Technisch en financieel haalbaar, maar kan en wil de organisatie het aan? Dit is in de praktijk vaak de grootste succesfactor: onderzoek van Prosci toont aan dat 88% van projecten met excellent change management de doelen haalt of overtreft, tegenover slechts 13% bij gebrekkig change management — een 7x verschil dat zelden door technologie alleen te overbruggen is. McKinsey's transformatie-onderzoek bevestigt het patroon: slechts 30% van organisatorische transformaties slaagt in het verbeteren én vasthouden van prestaties, en voor digitale transformaties ligt dat percentage nog lager.
Wat je onderzoekt:
- Heeft het team de vaardigheden om met het nieuwe systeem te werken?
- Is er draagvlak bij management en eindgebruikers?
- Past het project bij de strategische richting van het bedrijf?
- Is er voldoende capaciteit naast de dagelijkse werkzaamheden?
- Hoe groot is de verandering ten opzichte van de huidige werkwijze?
Signalen van onvoldoende organisatorische haalbaarheid:
- "We hebben er eigenlijk geen tijd voor" (capaciteitsprobleem)
- "De directie vindt het prima, maar het team ziet het niet zitten" (draagvlakprobleem)
- "We hebben vorig jaar ook al een nieuw systeem gekregen" (verandermoeheid)
- "Niemand hier heeft ervaring met dit soort technologie" (kennisprobleem)
4. Operationele Haalbaarheid
Kan de oplossing in de dagelijkse praktijk functioneren?
Wat je onderzoekt:
- Hoe wordt het systeem dagelijks gebruikt door eindgebruikers?
- Wat gebeurt er als het systeem uitvalt? Is er een fallback?
- Hoe wordt het systeem beheerd na livegang? Door wie?
- Past het systeem in de bestaande werkprocessen of moeten die aangepast worden?
- Schaalt de oplossing mee met groei van het bedrijf?
Tip: Betrek eindgebruikers vroeg in het haalbaarheidsonderzoek. Zij weten precies waar de knelpunten zitten en welke oplossingen in de praktijk wel of niet werken.
Het 6-Stappenplan
Stap 1: Probleem- en Doelstelling Definiëren
Begin niet met de oplossing, maar met het probleem. Dit klinkt logisch, maar in de praktijk begint menig IT project met "we willen systeem X implementeren" in plaats van "we willen probleem Y oplossen."
Acties:
- Beschrijf het huidige probleem in meetbare termen (uren, kosten, fouten, doorlooptijd)
- Formuleer concrete doelstellingen met SMART-criteria
- Bepaal de scope: wat valt er wel en niet binnen het project?
- Identificeer de belangrijkste stakeholders
Voorbeeld van een goede probleemstelling: "De orderverwerking kost gemiddeld 45 minuten per order, met een foutpercentage van 6%. Dit leidt tot EUR 120.000 per jaar aan onnodige arbeidskosten en EUR 35.000 aan herstelwerk. Doel: orderverwerking onder 10 minuten met minder dan 1% fouten."
Stap 2: Alternatieven in Kaart Brengen
Een veelgemaakte fout is om slechts een oplossingsrichting te onderzoeken. Breng minimaal 3 alternatieven in kaart:
- Optie A: Niets doen (nulscenario, als benchmark)
- Optie B: Bestaande systemen optimaliseren of uitbreiden
- Optie C: Nieuw systeem implementeren
- Optie D (optioneel): Hybride aanpak of gefaseerde implementatie
Voor elke optie beschrijf je op hoofdlijnen: de aanpak, de geschatte kosten, de doorlooptijd en de verwachte opbrengsten.
Stap 3: De 4 Typen Haalbaarheid Onderzoeken
Dit is de kern van het onderzoek. Loop voor elke serieuze optie (B, C en eventueel D) de vier typen haalbaarheid door:
Per optie scoor je elk type op een schaal van 1-5:
| Type | Score 1 | Score 3 | Score 5 |
|---|---|---|---|
| Technisch | Grote onzekerheden | Haalbaar met maatwerk | Bewezen technologie |
| Financieel | ROI > 36 maanden | ROI 18-24 maanden | ROI < 12 maanden |
| Organisatorisch | Grote weerstand | Gemiddeld draagvlak | Breed draagvlak |
| Operationeel | Grote proceswijzigingen | Aanpasbaar | Past naadloos |
Een totaalscore onder de 12 (van de 20) is een serieus risico. Onder de 8 is het advies om het project in deze vorm niet door te laten gaan.
Stap 4: Risico-assessment Uitvoeren
Elk IT project heeft risicos. Het verschil tussen een succesvol en een mislukt project zit in hoe goed je die risicos vooraf in kaart brengt en mitigeert.
Top 10 risicos bij IT projecten:
- Scope creep - Het project groeit tijdens de uitvoering. Mitigatie: strakke scopedefinitie en change request procedure.
- Te optimistische planning - Alles duurt langer dan gepland. Mitigatie: voeg 30-50% buffer toe aan de planning.
- Onvoldoende datakwaliteit - Garbage in, garbage out. Mitigatie: datavalidatie als eerste stap.
- Integratieproblemen - Systemen koppelen is complexer dan verwacht. Mitigatie: proof of concept voor kritieke koppelingen.
- Leveranciersafhankelijkheid - Vast aan een leverancier zonder alternatieven. Mitigatie: open standaarden en exitstrategie.
- Gebrek aan draagvlak - Het team werkt niet mee. Mitigatie: betrek gebruikers vanaf dag 1.
- Budget overschrijding - Onvoorziene kosten. Mitigatie: 15-20% contingency budget.
- Verouderde requirements - Wensen veranderen tijdens het project. Mitigatie: agile aanpak met korte sprints.
- Kennisconcentratie - Alle kennis zit bij 1 persoon. Mitigatie: documentatie en kennisdeling.
- Onrealistische verwachtingen - Management verwacht wonderen. Mitigatie: duidelijke communicatie over wat het systeem wel en niet kan.
Risicomatrix: Scoor elk risico op waarschijnlijkheid (1-5) en impact (1-5). Vermenigvuldig de scores. Risicos met een score boven 15 vereisen een concreet mitigatieplan.
Stap 5: Proof of Concept of Pilot
Bij twijfel over de technische haalbaarheid is een proof of concept (PoC) of pilot de beste investering die je kunt doen. Maar wat is het verschil? Belangrijke waarschuwing vooraf: Gartner voorspelt dat minstens 30% van generatieve AI-projecten wordt afgeblazen na de POC-fase — door slechte datakwaliteit, onvoldoende risicobeheersing, oplopende kosten of onduidelijke business value. Voor AI-pilots specifiek vond MIT NANDA's State of AI in Business 2025 dat 95% van enterprise generative AI-pilots geen meetbare ROI op de P&L leveren. Een goed opgezette PoC met vooraf gedefinieerde succes-criteria is daarom geen luxe, maar de enige manier om te voorkomen dat je project in die 95%-bucket terechtkomt.
Proof of Concept (PoC):
- Doel: Bewijzen dat de technologie werkt
- Duur: 1-2 weken
- Scope: 1 specifieke functionaliteit of koppeling
- Deelnemers: Technisch team
- Kosten: EUR 2.000 - EUR 10.000
- Wanneer: Bij onzekerheid over technische haalbaarheid
Pilot:
- Doel: Bewijzen dat de oplossing werkt in de praktijk
- Duur: 4-8 weken
- Scope: 1 afdeling of 1 proces, volledige functionaliteit
- Deelnemers: Technisch team + eindgebruikers
- Kosten: EUR 10.000 - EUR 30.000
- Wanneer: Bij onzekerheid over operationele of organisatorische haalbaarheid
Keuzecriterium: Is de twijfel technisch? Start met een PoC. Is de twijfel of het in de praktijk werkt? Ga voor een pilot. Bij beide twijfels: eerst PoC, daarna pilot.
Stap 6: Go/No-Go Beslissing
Alle informatie is verzameld. Nu moet er een beslissing vallen. Gebruik onderstaande criteria als leidraad:
Go-criteria (alle moeten "ja" zijn):
- De business case is positief (ROI < 24 maanden)
- De technische haalbaarheid is aangetoond (score 3 of hoger)
- Er is voldoende organisatorisch draagvlak
- De risicos zijn beheersbaar en gemitigeerd
- Het budget en de capaciteit zijn beschikbaar
- De timeline is realistisch (inclusief buffer)
No-go signalen (elk van deze is een showstopper):
- De ROI is negatief of langer dan 36 maanden
- Kritieke technische onzekerheden zonder PoC-resultaten
- Actieve weerstand van sleutelmedewerkers zonder plan
- Geen fallback-scenario bij falen
- Leverancier kan geen referenties tonen van vergelijkbare projecten
Soms is de uitkomst: "Nog niet." Dat is ook waardevol. Het project is misschien over 12 maanden wel haalbaar als de technologie matuurder is, het budget groter of het team er klaar voor is. Een solide IT-strategie helpt je om het juiste moment te bepalen.
Het Haalbaarheidsrapport: Template
Een goed haalbaarheidsrapport is bondig maar volledig. Gebruik deze structuur:
- Management samenvatting (1 pagina) - Conclusie en aanbeveling voorop
- Probleemstelling en doelstellingen - Meetbaar en SMART
- Onderzochte alternatieven - Minimaal 3, inclusief nulscenario
- Haalbaarheidsanalyse per alternatief - Technisch, financieel, organisatorisch, operationeel
- Kosten-baten analyse - Met sensitiviteitsanalyse (best case, worst case, verwacht)
- Risico-assessment - Top risicos met mitigatieplan
- PoC/Pilot resultaten - Indien uitgevoerd
- Go/no-go aanbeveling - Met onderbouwing en voorwaarden
- Implementatieplan op hoofdlijnen - Bij een go-aanbeveling
- Bijlagen - Detailberekeningen, interviewverslagen, technische specificaties
Tip: Schrijf de management samenvatting als laatste, maar plaats deze als eerste in het rapport. Beslissers lezen vaak alleen de eerste pagina.
Haalbaarheidsfouten die tot verkeerde go/no-go leiden
Fout 1: Te Optimistisch Plannen
De nummer 1 fout bij IT projecten. Planningen worden gemaakt op basis van het best-case scenario, terwijl de realiteit altijd dichter bij het worst-case scenario ligt.
Oplossing: Gebruik de "3-punts schatting": vraag het team om een optimistische, realistische en pessimistische schatting. De verwachte duur = (optimistisch + 4x realistisch + pessimistisch) / 6. Dit geeft een statistisch betrouwbaardere schatting.
Fout 2: Scope Creep Negeren
"Als we toch bezig zijn, kunnen we ook meteen..." is de gevaarlijkste zin in elk IT project. Kleine toevoegingen stapelen zich op tot een onherkenbaar groot project.
Oplossing: Definieer de scope glashelder vooraf. Elke wijziging gaat via een formele change request met impact-analyse op budget, planning en risicos. Geen uitzondering.
Fout 3: Alleen de Technische Haalbaarheid Onderzoeken
Het is verleidelijk om je te focussen op de technische kant, maar de meeste IT projecten falen niet door technische problemen. Ze falen door organisatorische weerstand, onrealistische verwachtingen of onvoldoende budget voor beheer na livegang.
Oplossing: Geef alle vier de typen haalbaarheid evenveel aandacht. De organisatorische en operationele haalbaarheid zijn minstens zo belangrijk als de technische.
Fout 4: De Kosten van Niets Doen Negeren
Het nulscenario lijkt gratis, maar dat is het zelden. Handmatige processen worden duurder naarmate het bedrijf groeit, medewerkers die vertrekken nemen kennis mee, en concurrenten die wel digitaliseren lopen steeds verder vooruit.
Oplossing: Bereken altijd de kosten van het nulscenario over 3-5 jaar. Dit geeft context aan de investering en maakt de business case sterker.
Wanneer Extern Advies Inschakelen?
Een haalbaarheidsonderzoek kun je intern uitvoeren, maar in sommige gevallen is externe expertise waardevol:
- Ontbrekende expertise - Als niemand intern ervaring heeft met de beoogde technologie
- Objectiviteit nodig - Als er intern sterke meningen zijn die het onderzoek kleuren
- Leveranciersevaluatie - Als je onafhankelijk advies wilt over leverancierskeuze
- Complexe integraties - Als meerdere systemen gekoppeld moeten worden
- Hoog risico - Als de investering substantieel is en de impact op de organisatie groot
Bij CleverTech begeleiden we haalbaarheidsonderzoeken voor IT en AI projecten. Van een AI Assessment dat de technische mogelijkheden in kaart brengt, tot een volledig haalbaarheidsonderzoek met business case en implementatieadvies. Onze strategisch AI advies dienst helpt je om de juiste beslissing te nemen voordat je investeert.
Van onderzoek naar gefundeerde beslissing
Een haalbaarheidsonderzoek is geen bureaucratische vertraging. Het is een investering die voorkomt dat je tienduizenden of honderdduizenden euro's uitgeeft aan een project dat nooit had moeten starten, of dat met betere voorbereiding wel had geslaagd.
De 6 stappen zijn helder: definieer het probleem, breng alternatieven in kaart, onderzoek de vier typen haalbaarheid, voer een risico-assessment uit, valideer met een PoC of pilot, en neem een onderbouwde go/no-go beslissing.
Het mooie van dit proces is dat zelfs een "no-go" waardevol is. Je hebt dan voor een fractie van de projectkosten ontdekt dat het project in de huidige vorm niet haalbaar is. Dat bespaart je maanden aan frustratie en een aanzienlijk deel van je budget.
Wil je sparren over de haalbaarheid van een IT of AI project? Gebruik de keuzehulp om te ontdekken welke aanpak het beste bij jouw situatie past.
Opgesteld met AI-tools en gecontroleerd door het redactieteam van CleverTech — tech-leads met ervaring in AI, procesautomatisering en IT-consulting.
