Verhoef: Grip op outsourcing

Bovendien zitten er vaak omvangrijke contracten tussen. Problematische situaties geven soms aanleiding tot issues waarbij men de kleine lettertjes van de contracten probeert te interpreteren. En die bieden niet altijd evenveel soelaas, met een onprettige samenwerking tot gevolg.
Dat komt vooral omdat contractmanagement nog in de kinderschoenen staat. Met alle respect voor de inkopers en juristen zijn het vaak diegenen die de contracten opstellen en de prijzen vastleggen. Een gemiste kans in outsourcingcontracten is bijvoorbeeld de opname van een setje belangrijke IT-specifieke indicatoren die de grip op het dagelijkse werk verbeteren, door monitoring, control, transparantie en meer. Een veel gemaakte fout is bijvoorbeeld de acceptatietest om af te rekenen. Ik gaf in een eerdere column aan dat een dergelijke test voor dat doel niet geschikt is, omdat je daarmee gemiddeld maar 30 procent van de fouten in software opspoort.
Wat moet je nu aan KPI’s in een outsourcingcontract opnemen zodat je minimaal grip op de situatie krijgt zonder al te veel discussie over de metrieken zelve? Dat is een verhaal dat van twee kanten moet komen. Optimaliseren naar resultaatgericht werken betekent dat de klant in staat is een opdracht te formuleren, en de leverancier in staat gesteld wordt om op te leveren.
Vage plannen die de hele tijd veranderen dragen daar niet aan bij. Het is derhalve goed om de volatiliteit van het eisenpakket binnen de perken te houden. Dat doe je door de zogenaamde ‘scope creep’ onder de 1 procent groei per maand te houden. Het eisenpakket gemeten in functiepunten aan het eind van de requirements fase mag bij oplevering niet meer dan 1 procent per maand zijn aangewassen. Sterker, outsourcing deals met een maandelijkse groei van meer dan 2 procent zijn een indicatie dat er iets mis kan zijn. Scope creep boven de 5 procent is een sterke indicator dat het project hoogstwaarschijnlijk in de problemen verkeert.
Voorts is een bepaalde minimale kwaliteit vereist. Je kunt niet tegen een minimaal uurtarief eisen dat er nul fouten in de software op zullen treden. Kwalitatief goede IT-ers hebben hoge uurtarieven, gelukkig ze zijn vaak veel productiever, dus dat geld komt wel terug.
Hoeveel fouten mogen er in opgeleverde software zitten zodat er nog steeds sprake is van een succesverhaal, en bij welk aantal wordt het minder fraai? Minder dan vijf fouten per functiepunt in het “totale volume” van de software, en je zit redelijk goed. Totaal volume wil zeggen fouten in requirements, in het ontwerp, in de code, de documentatie, en door incorrect verbeterde fouten. Ook dit is een sterke discriminant: zes of meer fouten per functiepunt is een signaal, en bij hogere aantallen is er aanleiding tot grote zorg. Vergelijk het maar met de oplevering van een eensgezinswoning waar gemiddeld nog 21 defecten aanwezig zijn. Als dat substantieel hoger is, is dat een indicatie dat het hele huis niet goed gebouwd is.
En dan de defect removal efficiency (DRE) waar ik in de vorige column al op inzoomde. Dat is het percentage fouten dat je voor oplevering van een (tussen)product hebt gevonden en verbeterd. Je kunt minimaal naar twee van die percentages kijken. Om verassingen te voorkomen bij oplevering, is het aan te raden om bij een belangrijke mijlpaal alvast een defect removal efficiency af te dwingen. De DRE voordat je gaat testen is erg nuttig om contractueel vast te leggen. Als die meer dan 65 procent is, met andere woorden voordat je gaat testen heeft de outsourcer er al 65 procent uit gehaald, dan heb je hoogstwaarschijnlijk te maken met een project dat op het juiste spoor zit. Is het 35 procent of minder, dan moeten we eerder aan een ontsporing denken. Meteen na het testen is dat dan bekend. En omdat je dit per contract hebt vastgelegd is er ook transparantie over de reeds opgeloste problemen, die de leverancier graag rapporteert omdat dat tot een hogere DRE bijdraagt.
Het voordeel van dit soort KPI’s is dat de leverancier maatregelen moet nemen om zo vroeg mogelijk in het traject fouten te vinden en te voorkomen, wat de kwaliteit alleen maar ten goede komt en ook nog eens goedkoper is. Immers, hoe sneller je een fout ontdekt hoe minder het kost om hem ongedaan te maken. Als vierde KPI is het raadzaam om een defect removal efficiency before delivery te eisen. Een DRE van meer dan 94 procent is een mooi resultaat, en minder dan 85 procent is problematisch.De combinatie van deze vier indicatoren maakt het verschil tussen falende en succesvolle projecten. Uiteraard kunnen en zullen de precieze cijfers per geval iets anders zijn: al naar gelang de grootte, complexiteit, en het type project. Dat laat onverlet dat expliciet opnemen van dit soort KPI’s in contracten een goede relatie tussen IT-dienstverleners en hun klanten bevordert.
Prof.dr. Chris Verhoef is hoogleraar informatica aan de Vrije
Universiteit in Amsterdam. Hij schrijft maandelijks een ­column in AG II.