Stop een AI-project wanneer het afgesproken getal niet gehaald is op de afgesproken datum. Niet als de demo er slechter uitziet, niet als het budget op is en ook niet als iemand van de directie eindelijk zijn geduld verliest. De projecten die ik heb zien mislukken, misten zelden een waarschuwing. Ze misten een vooraf afgesproken regel voor wat er gebeurt als die waarschuwing komt. Leg die regel vast vóór de eerste sprint.
Waarom blijven AI-projecten doorlopen terwijl ze hadden moeten stoppen?
Omdat beginnen aan een AI-project een beslissing is en stoppen een bekentenis. Iedereen aan tafel heeft bij de start iets toegezegd: de opdrachtgever heeft een verhaal verkocht aan de directie, het team heeft ander werk laten liggen, een leverancier heeft een resultaat voorspeld. In week acht heeft ieder van hen een persoonlijke reden om de cijfers welwillend te lezen. Niemand liegt. De meetwaarde beweegt een beetje, de dataproblemen zijn “bijna opgelost”, de volgende release gaat “het beeld veranderen”. Elke zin is aannemelijk, en samen vormen ze een project dat al een maand ongezond is.
Ik heb aan beide kanten van die tafel gezeten. Als leverancier ken ik de aantrekkingskracht: het werk is interessant, de klant is aardig en stoppen voelt als falen. Juist daarom vertrouw ik er niet meer op dat ik, of wie dan ook, de stopbeslissing op het moment zelf goed neemt. Een beslissing die valt terwijl het team moe is, de opdrachtgever zich kwetsbaar voelt en er een factuur openstaat, is een onderhandeling en geen oordeel.
De oplossing is saai. Bepaal de voorwaarden om te stoppen op een moment dat iedereen optimistisch is en er nog niets is uitgegeven. Ik noem ze stopcriteria, en in mijn eigen voorstellen staan ze op de eerste pagina in plaats van in een bijlage. In ‘Hoe ik weet dat een project gaat mislukken voordat het begint’ schreef ik over de waarschuwingssignalen die ik in een eerste gesprek hoor. Met stopcriteria bepaal je wat je doet met de signalen die pas later opduiken, zodra er echte data en echte gebruikers aan te pas komen.
Wat kan de Fyra ons leren over op tijd stoppen?
Wie in Nederland of Vlaanderen is opgegroeid, kent wel een project dat doorliep voorbij het punt waarop het nog zin had, en voor mij is dat de Fyra. Het moest de snelle verbinding worden tussen Amsterdam en Brussel, gereden door NS International (een joint venture van NS en KLM) samen met de Belgische spoorwegen NMBS/SNCB, met V250-treinen van AnsaldoBreda: negentien besteld en negen geleverd. De dienst naar Antwerpen en Brussel startte op 9 december 2012. Op 17 januari 2013 werd de dienst opgeschort na technische problemen, en op 31 mei 2013 zegde de Belgische kant het contract voor drie treinen op en trok zich terug uit de dienst. NS meldde op 3 juni 2013 dat de V250 geen optie meer was. Die data komen uit het Fyra-artikel op Wikipedia, dat verwijst naar berichtgeving uit die tijd.
Wat mij interesseert, is niet de trein maar de volgorde. Zoals International Railway Journal het eindrapport van de Nederlandse parlementaire commissie samenvatte, wist NS dat de dienstregeling voor de V250 onrealistisch was en had het twijfels over de kwaliteit, maar zegde het contract niet op. De dienst startte met weinig ervaring met de treinen en zonder noodplannen. De waarschuwingen waren er dus. Wat die samenvatting niet beschrijft, is een vooraf afgesproken punt waarop de waarschuwingen in een besluit moesten overgaan.
Ik wil eerlijk zijn over hoe ver deze vergelijking reikt. Een trein is geen taalmodel, een spoorbedrijf heeft toezichthouders en een dienstregeling die het publiek ziet, en ik beweer niet te weten wat er in die vergaderkamers is gezegd. Het is bovendien een Nederlands-Belgisch verhaal met twee vervoerders en twee parlementen, dus ik zou er niets algemeens uit afleiden over de gewoonten van het ene of het andere land. Maar het mechanisme herken ik uit veel kleinere projecten: een bekende zorg, een lanceringsdatum die iedereen al had aangekondigd en een contract waardoor stoppen duurder voelt dan doorgaan. Dat laatste is mijn eigen patroon en komt niet uit de bronnen over de Fyra. In een AI-project van mkb-formaat zijn de bedragen kleiner en is de structuur precies hetzelfde.
Welke stopcriteria spreek ik af voordat een AI-project begint?
Ik hanteer er vijf. Geen van de vijf is bijzonder slim. De waarde zit hem in het feit dat ze zijn vastgelegd en gedateerd voordat iemand een reden heeft om erover te steggelen.
Een getal op echt werk, op een vaste datum gemeten
Niet “de klantenservice verbeteren”, maar “het conceptantwoord gaat in een afgesproken aantal van de tien gevallen ongewijzigd de deur uit, gemeten op de echte tickets van vorig kwartaal”. De nulmeting komt uit echt werk, de datum van het meetmoment staat in de agenda en het getal is er een waar de klant echt voor zou willen betalen. Weet je niet hoe je dat getal kiest, dan loopt het artikel ‘Wat je meet in een AI-pilot’ de opties door.
Een datacheck in week drie
De meeste mislukkingen die ik heb gezien, hingen af van de vraag of de echte data binnenkwamen, niet door het model: echte documenten, echte exports, toegang tot het echte systeem. Het eerste criterium gaat dus helemaal niet over AI. Uiterlijk in een afgesproken week komen de echte data van de afgesproken soort binnen, anders stoppen we en zoeken we uit waarom. Een project dat in week vijf nog op voorbeelddata draait, heeft je al iets verteld.
Een eigenaar die komt opdagen
Een benoemde persoon aan de kant van de klant die kan zeggen “zo doen wij het hier” en die elke week een half uur vrijmaakt. Wisselt de eigenaar twee keer, of komt hij nooit opdagen, dan heeft het project er geen. Ik zie dat als stopsignaal, want een pilot zonder eigenaar komt vrijwel nooit uit de pilotfase. Het artikel ‘Wie heeft een AI-implementatie in handen’ beschrijft wat die rol inhoudt.
Een plafond voor de kosten per taak
Elke taak die het systeem afhandelt, kost iets om te draaien, en het is makkelijk om een resultaat aan te tonen door de kosten te laten oplopen. Ik spreek vooraf een plafond per taak af, afgeleid van wat de handmatige taak de klant nu kost. Een pilot die alleen werkt tegen een prijs die niemand wil betalen, is dan een bevinding en geen verrassing aan het eind.
Een fout die niemand zou opmerken
Ik maak een lijst van de fouten die het proces zich niet kan veroorloven en vraag of we ze zouden merken. Is de waarschijnlijkste ernstige fout er een die niemand een maand lang zou vinden, dan heeft het project eerst een controle nodig voordat er nog een functie bij komt. Kan die controle er niet komen, dan stopt het. AI-agents pas meer ruimte geven nadat ze die hebben verdiend, is een goede regel voor één agent, en dezelfde logica geldt voor hele projecten.
Eén toets pas ik op alle vijf toe: kan een buitenstaander ze scoren? Als een collega die het project nooit heeft gezien de pagina kan lezen en met de cijfers ernaast kan zeggen welke criteria zijn gehaald, zijn de criteria concreet genoeg. Is er uitleg voor nodig, dan zijn het nog meningen, en meningen buigen als eerste mee wanneer een project slecht loopt.
Hoe zie je het verschil tussen een trage start en een project dat nergens heen gaat?
Bij elk meetmoment stel ik twee vragen: wat is er bewogen sinds de vorige keer, en weten we waarom? Een trage start heeft een meetwaarde die de goede kant op beweegt en een verklaring die hetzelfde blijft. Een kansloos project heeft een vlakke meetwaarde en een verklaring die steeds verandert. In week vier waren de data vuil. In week zes begrepen de gebruikers het niet. In week acht moet het model groter. Elke reden is aannemelijk, en samen zeggen ze dat niemand het weet.
Er zijn nog twee signalen. Het eerste is dat de scope groeit om het resultaat te redden. Als het antwoord op een vlak getal een nieuwe functie, een nieuwe databron of een extra afdeling is, wordt het project gevoed in plaats van gerepareerd. Het tweede is dat meetmomenten van naam veranderen: een “go of no-go” wordt een “review”, dan een “workshop”, dan iets waar niemand notulen van maakt.
Bij twee meetmomenten op rij met een vlakke meetwaarde en geen stabiele verklaring stel ik voor te stoppen of in te perken, niet om te verlengen. Inperken is een volwaardige derde optie. Beperk je tot het ene documenttype, de ene productlijn of de ene klantgroep waar het systeem wel werkt, en pas de criteria opnieuw toe op die kleinere scope. Of je een pilot, een proof of concept of een MVP draait, bepaalt wat je kunt inperken, en het artikel ‘Pilot, PoC of MVP’ legt het verschil uit.
Hoe ziet een stopgesprek er in de praktijk uit?
Korter dan mensen verwachten. Ik zet de criteria op één slide, de gemeten waarden ernaast, en vraag de eigenaar hardop te zeggen welke zijn gehaald. Geen verhaal, geen “maar als je bedenkt dat”. Zijn er twee of meer gemist, dan kiezen we uit drie uitkomsten: stoppen, inperken, of doorgaan met een andere hypothese en een nieuwe datum. Doorgaan mag, maar alleen met iets wezenlijk anders, en maar één keer.
Ik vraag ook aan de mensen die het systeem gebruiken, en niet alleen aan de opdrachtgever, om in eigen woorden te vertellen of ze het zouden missen. Een pilot die zijn getal haalt terwijl de mensen die het werk doen er stilletjes omheen werken, heeft een criterium gehaald maar niet het doel. Die twee beelden lopen vaker uit elkaar dan de dashboards doen vermoeden, en het stopgesprek is de plek waar ik dat verschil zichtbaar wil hebben.
Wie beslist over het stoppen: de klant of de consultant?
De klant, en dat leg ik vast. Een consultant die per dag wordt betaald, heeft een financiële reden om door te gaan. Een consultant die tegen een vaste prijs werkt, heeft een reden om de overwinning uit te roepen op een smallere definitie dan de klant in gedachten had. Ik bekritiseer geen van beide modellen, en ik beschrijf de prikkels van allebei in ‘Vaste prijs of uurtarief bij AI-projecten’. In beide gevallen ligt het recht om te stoppen bij degene die eigenaar is van het bedrijfsprobleem.
Wat ik zelf toezeg, is dat ik het zonder omweg zeg wanneer een criterium niet is gehaald, ook op de dagen dat ik liever een ruimhartigere lezing zou hebben. Ik wil bovendien dat vroeg stoppen voor de klant goedkoop is: de sprints die al zijn gedraaid worden betaald, er is verder niets verschuldigd en er komt geen boete. Een klant die een boete vreest, zal nooit het stopsein geven, en dan is het hele mechanisme een wassen neus.
Wat gebeurt er nadat je een AI-project hebt gestopt?
Stoppen is goedkoper dan het lijkt, omdat het meeste van wat is gebouwd niet het model is. Het processchema, de opgeschoonde data, de testset met echte voorbeelden en de lijst met uitzonderingen blijven allemaal bestaan, en ze zijn meestal het duurste deel van de volgende poging. Ik vraag om een notitie van één pagina: wat we hebben geprobeerd, wat het getal was, waarom we stopten en wat we zouden hergebruiken.
Soms is de juiste uitkomst gewoon niets doen, voorlopig. Vaak is het een kleiner project later, en het tweede AI-project gaat meestal goed, omdat het eerste de lessen al heeft betaald.
Onder dit alles ligt het probleem van reeds gemaakte kosten (sunk costs). Het geld dat al is uitgegeven is geen reden om door te gaan, en ook geen reden om te stoppen. De enige vraag bij een meetmoment is of de volgende sprint tegen de prijs van vandaag de moeite waard is, gegeven wat de data nu zeggen. Sta je op het punt een project te starten en wil je de stopcriteria samen met de scope opstellen? Stuur me de scope en we werken ze samen uit. Het is het soort werk dat ik doe als AI-consultant voor het mkb.
Een consultant zegt waar AI loont; Crux Digits bouwt het ook. Vaste prijs per stap, één vaste expert, vanuit Utrecht.
AI-consultancy in Nederland →
