Waarom AI-projecten mislukken: vier beslissingen die al genomen waren voor de eerste regel code

Valkuil 1: het project begint bij AI in plaats van bij een probleem

Veel trajecten beginnen bij een technologie die indruk maakt. Dat is een vertrekpunt zonder probleem erin. In de projecten die wij zien, komt de vraag naar AI het vaakst vanuit IT en niet vanuit de business. Dat is geen verwijt aan IT: IT hoort nu eenmaal als eerste over de technologie, dus daar begint het gesprek. Het probleem is de volgorde, niet de afdeling.

Wat er dan gebeurt, valt te voorspellen. IT bouwt iets dat technisch klopt en toont het aan de business. Die herkent haar eigen proces er niet in en vraagt aanpassingen. Er volgt een tweede versie, een demo, een discussie over uitzonderingen die niemand had opgeschreven. Elke ronde kost weken, en niemand kan zeggen wanneer het af is, want nergens staat wat “af” betekent. Ondertussen zit de verantwoordelijke met een systeem dat hij niet gevraagd heeft.

In aflevering 1 van de Juvo-podcast valt het zo: “Dus het is eigenlijk geen IT-feestje alleen meer.” IT blijft nodig om de mogelijkheden te onderzoeken en naar een proof of concept of een MVP toe te werken. De richting komt van de business, want die weet welk proces pijn doet en welke waarde eruit moet komen.

Die waarde is geen gevoel. Ze is een bedrag, een doorlooptijd of uren per week, en je kan de ROI van een AI-project berekenen voor je begint. Dan blijft één vraag over: wie beslist welke waarde eruit moet komen, en wie betaalt ervoor?

Valkuil 2: niemand ligt er wakker van

Eigenaarschap klinkt zacht, maar het is een harde vraag. In aflevering 1 valt ze zo: “Wie zijn P&L gaat er eigenlijk op vooruit als we daarin stappen zetten?” Zolang daar geen naam op staat, is er geen eigenaar maar een geïnteresseerde.

Dat verschil zie je het scherpst aan het budget. Moet het budget uit een leeg IT-potje komen, dan sleept het initiatief aan zonder dat er iemand beslist. Dat zien wij in onze projecten terugkomen. Er komt geen nee en geen ja, en dus blijft het project bestaan zonder vooruit te gaan.Elke vraag over prioriteit wordt dan een escalatie naar iemand die het dossier niet kent.

Een trekker gedraagt zich anders dan een opdrachtgever op afstand. Een opdrachtgever geeft de opdracht mee en komt over drie weken resultaten halen. Een trekker zit in de stuurgroep, hakt knopen door over de scope en maakt de tijd van zijn eigen mensen vrij. Hij legt aan de rest van de organisatie uit waarom dit er ligt. Die laatste taak is geen communicatieoefening achteraf. Ze bepaalt of het resultaat straks gebruikt wordt.

Dit heeft niets met AI te maken. Een klassiek IT-project waar niemand wakker van ligt, loopt op dezelfde manier vast. En als die eigenaar er wel is, waarom strandt het dan nog in de pilotfase?

Valkuil 3: proberen om te proberen

In aflevering 1 krijgt deze valkuil de kortste naam: “Proberen om te proberen.” In de trajecten die wij doen, blijven pilots en proofs of concept hangen doordat er te snel gestart wordt en te snel resultaat verwacht wordt. Er is enthousiasme, er is een omgeving, er is zelfs een demo. Wat er niet is, is een afspraak over wanneer dit af is.

Zonder die afspraak stopt een proof of concept nooit. Hij groeit, want er is altijd nog een geval dat er niet in zit. Vier vragen beantwoord je daarom voor je begint:

1. Wat noemen we geslaagd, in een getal dat we achteraf kunnen vaststellen?
2. Wanneer stoppen we, en wie zegt dat dan?
3. Hoeveel tijd geven we het?
4. Wie van jullie werkt mee, en hoeveel uren per week staan daarvoor vrij?

Op de derde vraag hebben wij een eigen antwoord. Wij zetten maximaal zes weken op een proof of concept, met een go/no-go op het einde. Zes weken is een bovengrens, geen streefduur, en het zegt niets over de uitkomst. Komt er geen waarde uit, dan stop je, en dan weet je iets wat je voordien niet wist. Dat is een opbrengst, geen troostprijs.

De vierde vraag is de moeilijkste, en ons antwoord kost ons soms werk. Co-creatie is hier geen mooi woord maar de voorwaarde. Maakt een klant geen tijd vrij bij zijn eigen mensen, dan kan een traject van drie weken uitlopen tot negen weken of langer. Wij hebben dat in onze trajecten zien gebeuren. Krijgen de mensen die het moeten dragen geen tijd, dan raden wij het traject af in plaats van het te starten.

We werken apart uit waarom een AI-pilot blijft hangen. En over welke use case gaat dat gesprek dan eigenlijk?

Valkuil 4: 120 use cases en geen enkele in productie

Eén organisatie kwam bij ons aan tafel met 120 gedefinieerde AI-use-cases. Geen enkele stond in productie. De lijst was met zorg gemaakt, per departement, in workshops. Precies daar zit het probleem.

Een grote AI-brainstorm vertrekt van de technologie en vraagt wat je ermee zou kunnen doen. Dat levert ideeën op die los staan van een proces dat vandaag pijn doet. En het levert er veel op, want een brainstorm meet niet wat iets oplevert: hij meet hoeveel mensen iets kunnen bedenken.

Daarna moet iemand prioriteren, en daar loopt het opnieuw vast. Niet door een gebrek aan methode, want scoringsmatrixen zijn er genoeg. Het loopt vast door een gebrek aan mandaat. Zolang niemand mag beslissen, zet elk departement zijn eigen voorstel bovenaan, en dan wint de lijst van niemand. Zo blijven 120 use cases gewoon 120 use cases.

Het alternatief is kleiner en saaier. In onze discovery-gesprekken met een beperkt aantal keypersonen uit de business komen er doorgaans één tot maximaal drie echte pijnpunten boven. Daar kies je er één uit, met iemand die mag beslissen. De mensen die je daarvoor aan tafel zet, zijn ook de mensen die het straks moeten gebruiken, en dat maakt hen je ambassadeurs tot in productie.

Valt het op dat in geen van deze vier valkuilen de technologie voorkomt?

Zo pak je een AI-project wel aan

Zeven regels die je morgen zelf kan toepassen. Weet je niet waar je vandaag staat, begin dan met een zelfscan die toont waar je staat.

1. Vertrek van een businessprobleem dat vandaag geld of tijd kost, en niet van de technologie die je net gezien hebt.

2. Wijs één eigenaar aan met budget en met een P&L die erop vooruitgaat.

3. Beperk je tot één tot drie use cases, gekozen uit de pijnpunten die de business zelf benoemt.

4. Bepaal je succescriteria en je go/no-go-momenten voor je start, en niet onderweg.

5. Zet er een termijn op: bij ons is dat maximaal zes weken voor een proof of concept.

6. Betrek de sleutelgebruikers vanaf dag één en maak hun tijd ook echt vrij.

7. Communiceer open naar de hele organisatie, en niet alleen naar de mensen die aan tafel zaten.

Veelgestelde vragen over AI-projecten die mislukken