Besluitvorming in AI-projecten met een onzekere scope

Een contract met een vaste scope werkt als vooraf duidelijk is wat wordt opgeleverd. Denk aan een brochuresite, een app met een afgeronde specificatie of illustraties in afgesproken formaten. De levering en prijs kunnen dan vooraf precies worden vastgelegd.

Bij AI-projecten verandert de specificatie vaak wanneer het model met echte data wordt getest. Een geplande integratie kan een onderzoeksvraag blijken of juist veel eenvoudiger worden door nieuwe software. Dat is niet automatisch een planningsfout. Het hoort bij werken met technologie en kennis die tijdens het project veranderen.

Daaruit wordt vaak geconcludeerd dat je geen vast contract moet tekenen. Die conclusie is te eenvoudig en slaat de voor de hand liggende tegenwerping over.

Een pilot is ook een contract

Er zit een looptijd in, een prijs, een omschrijving van wat als geleverd telt en aan beide kanten een naam. Het een pilot noemen haalt daar niets van weg. Het verandert welke bepalingen vastliggen en welke bewust open blijven.

De relevante vraag is beperkter en bruikbaarder: welke voorwaarden moeten vastliggen voordat het werk begint en welke juist niet?

Veelvoorkomende oorzaken van problemen in AI-projecten

Onderzoek biedt een bruikbaarder vertrekpunt dan aannames over waarom zulke projecten mislukken.

RAND sprak 65 datawetenschappers en technische specialisten met minstens vijf jaar ervaring in het bouwen van modellen binnen bedrijven en de wetenschap.¹ De meest genoemde oorzaak was niet technisch. Betrokkenen begrepen of formuleerden het probleem verschillend. Daardoor werden modellen geoptimaliseerd voor de verkeerde maatstaf of pasten ze niet in het beoogde werkproces. Een vaste scope die vanuit dezelfde onduidelijkheid wordt geschreven, lost dat probleem niet op.

De projectmanagementliteratuur wijst dezelfde kant op, met een belangrijke kanttekening bij hoe ze meestal wordt geciteerd. PMI meldt dat van de mislukte projecten 47 procent de doelen niet haalde door gebrekkig eisenbeheer.² Dat is een aandeel van de mislukkingen, niet van alle projecten, en het wordt voortdurend in de verkeerde richting geciteerd. De Pulse van 2021 zet scope-uitbreiding wereldwijd op ongeveer een derde van de projecten.³ Vaak dus. Niet altijd.

Coopers model met beslismomenten tussen ontwikkelfasen maakte investeringsbesluiten expliciet. In later werk pleitte hij voor flexibiliteit en waarschuwde hij voor starre bureaucratie.⁴ Het spiraalmodel van Boehm plaatst op vergelijkbare wijze een herhaalde risicoanalyse vóór de volgende investering.⁵ Deze methoden nemen onzekerheid niet weg, maar zorgen dat zij op vaste momenten wordt beoordeeld.

Veel conflicten ontstaan doordat een contract iets vastlegt wat beide partijen bij ondertekening nog niet volledig konden overzien. Zonder gepland beslismoment wordt die onduidelijkheid later moeilijk te herstellen.

Wat een beslismoment moet vaststellen

Forenta for Business maakt dit concreet met een vast besluit aan het einde van iedere fase.

Een fase eindigt met een van drie uitkomsten: doorgaan, aanpassen of blokkeren. Aanpassen en blokkeren zijn geen systeemfouten. Ze zorgen dat 'doorgaan' een inhoudelijk besluit blijft. Een beslismoment dat alleen toestemming kan geven, is geen echte controle.

De volgende fase begint pas wanneer verplichte punten zijn afgehandeld. Het oordeel en de reden voor de blokkade blijven in het logboek staan. Zo vraagt een openstaand punt om een concrete handeling voordat het project verder kan.

Een bevoegd persoon kan van het advies afwijken. Dat is belangrijk, want een proces waar niemand langs kan, wordt al snel omzeild. De afwijking vraagt een geschreven reden, wordt op naam vastgelegd en laat het oorspronkelijke oordeel staan. Je kunt doorgaan, maar niet doen alsof er geen bezwaar was.

Als het werkende systeem niet is beoordeeld, vermeldt de review dat de zekerheid beperkt is. Een oordeel over gebouwde software dat alleen op een beschrijving rust, blijft een aanname. Dat onderscheid moet zichtbaar zijn in het besluit.

Eén overzicht van bevindingen en besluiten

Wat een contract niet kan, is bijblijven. Het beschrijft een afspraak op één moment, en elk gesprek daarna leeft in mail, telefoontjes en geheugen. Precies daar bouwen twee partijen stilletjes verschillende versies van wat er is gebeurd.

Als bevindingen, besluiten en openstaande punten op één plek staan, hoeven betrokkenen later niet uit e-mails en herinneringen te reconstrueren wat is afgesproken. Dat verkleint de ruimte voor verschillende lezingen van hetzelfde projectverloop.

Wat dit niet oplost

Afgebakende opdrachten vragen tijd voor de inrichting. Beide partijen moeten vooraf vastleggen wanneer een fase voldoende resultaat heeft opgeleverd. Ook voorkomt deze aanpak geen slechte samenwerking, maar zij kan problemen wel eerder zichtbaar maken en de financiële verplichting beperken.

Als de scope vooraf wel goed bekend is, kan een contract met een vaste prijs nog steeds passend zijn. Een pilot voegt dan mogelijk onnodige stappen toe.

De onderzoeken van RAND en PMI gaan over projectfalen in brede zin. De RAND-studie bestaat uit interviews met 65 vakmensen en is geen gecontroleerd experiment. De resultaten zijn bruikbare praktijkervaringen, geen exacte meting van oorzaak en gevolg.

Forenta for Business is beschikbaar als gecontroleerde pilot voor organisaties, met prijs op aanvraag. De omgeving is niet volledig zelf te activeren.

Leg alleen vast wat vooraf te bepalen is

De tegenstelling is niet contract of geen contract. Een afgebakende opdracht legt de voorwaarden vast die vooraf te bepalen zijn en dwingt aan het eind een echte beslissing af in plaats van een automatische verlenging.

Dat werkt alleen als een beslismoment het project ook werkelijk kan tegenhouden.