Waarom steken wij zoveel tijd in contractonderhandelingen, plannen van aanpak en functionele ontwerpen als het gaat om ict-projecten?
Onlangs antwoordde één van onze klanten letterlijk: “Wij willen gewoon in een zo vroeg mogelijk stadium zoveel mogelijk zekerheden over een project binnenslepen.” Die behoefte aan zekerheid in de ict-branche is gebaseerd op ervaringen uit het verleden, gekoppeld aan een Pavlov-reactie gericht op maximale zekerheid. Een ict-project loopt snel uit de hand qua budget, oplevertijd of functionaliteit. Die ervaring zorgt voor risicomijdend gedrag: vaste prijzen, vaste data, risico-opslagen, garanties, contractueel vastleggen van zoveel mogelijk verplichtingen en details. Het zogenaamde ‘fixed-date en fixed-price project’ is populair, maar in feite een simpele verplaatsing van het projectrisico. Of de klant hiermee daadwerkelijk zekerheid verkrijgt is nog maar zeer de vraag.
Internationale cijfers
Is het zo erg gesteld met ict-projecten? Het antwoord is ja. Wereldwijd blijkt 71 procent van de ict-projecten niet binnen budget, afgesproken tijd of met de afgesproken functionaliteit te worden opgeleverd. Volgens de Amerikaanse Standish Group wordt 18 procent van de ict-projecten zelfs voortijdig afgebroken. Bovendien heeft elke ict’er zijn eigen nachtmerrie: geldverslindende software die nooit gebruikt wordt, oeverloze discussies met gebruikersgroepen, projecten die stranden tijdens de implementatie et cetera. Deze collectief gedeelde ervaringen genereren een Pavlov-reactie gericht op zekerheid. Voor de opdrachtgever betekent dit dat hij de oplossing fixeert en wil laten realiseren tegen zo min mogelijk uren met zoveel mogelijk garanties en toezeggingen. Voor de leverancier betekent zekerheid daarentegen zo veel mogelijk uren en waar nodig een risico-opslag. Het denken in uren houdt klant en leverancier in een ijzeren greep. In veel gevallen lopen projecten – ondanks alle bedongen zekerheden – toch uit, voelt de klant zich ‘gedwongen’ deeloplossingen te accepteren of stelt de klant zelf extra resources ter beschikking om toch nog de opleverdatum te halen. Ondanks alle goede bedoelingen is het daardoor niet verwonderlijk dat de branche nog steeds een onvolwassen imago heeft.
Bijdrage
Volledige zekerheid bij een ict-project is in mijn optiek niet mogelijk. Een omgeving, een organisatie en ook een project zijn allesbehalve statisch en altijd aan veranderingen onderhevig. Het is dan ook een illusie om allerlei zekerheden in een vroeg stadium te verkrijgen en te geven. Op een enkele uitzondering na blijft één ding wel constant: de waarde van een project. Daarbij gaan wij – en vele van mijn branchegenoten – er impliciet vanuit dat ict-investeringen worden gedaan om de resultaten van een organisatie te verbeteren. Het doel van het project kan dus geformuleerd worden in termen van bijdrage aan het resultaat van de organisatie. Deze waarde wordt weliswaar steeds vaker door klant en leverancier vastgesteld, maar nog lang niet altijd. Daardoor is er ook geen ijkmechanisme om de kosten tegen de baten af te zetten en wordt het project puur op kosten gemanaged. Het omgaan met veranderingen is hier een moeizame exercitie.
Waarde
Stel dat de waardebepaling van een ict-project verplicht zou zijn, dan ben ik ervan overtuigd dat minder projecten starten. Van de projecten die wel starten zou een veel lager percentage dan de huidige 71 procent mislukken. De waarde van het project dient continu de focus te zijn, voor zowel opdrachtgever als leverancier. Deze waarde kan geconcretiseerd worden in de vorm van bijvoorbeeld omzetvergroting, kostenbesparing of toegenomen klanttevredenheid. Als ict-leveranciers zouden wij in staat moeten zijn om de maximale waarde voor de business uit de ict-oplossing te halen. Niet de meest slimme oplossing, de technisch meest perfecte oplossing of de meest innovatieve technologie. Nee, die oplossing met een zo groot mogelijke bijdrage aan het resultaat van de onderneming of organisatie. Pas als de waarde van de oplossing kristalhelder is, kunnen afspraken gemaakt worden over de functionaliteit, de tijd en de kosten van het project. In een projectomgeving zullen altijd veranderingen zijn. De vraag is hoe je met deze veranderingen omgaat. Naar mijn mening dient elke verandering getoetst te worden aan de waarde: levert deze extra functionaliteit, extra rendement? Zo ja, veroorzaakt de extra functionaliteit uitloop qua tijd? En wat kost het de klantorganisatie als een project twee weken uitloopt, is dat de extra functionaliteit waard? De consequentie van bijvoorbeeld een andere schermindeling kan een uitloop zijn van drie weken. Stel dat de software maandelijks een half miljoen euro oplevert, dan is het zeer de vraag of de extra inspanningen bijdragen aan het rendement.
Denk niet in technologie, maar in waarde
Ik ben er heilig van overtuigd dat het denken in termen van waarde en het vertalen van projectdoelen naar waarde voor de organisatie, de toekomst is van de ict-sector. De branchevereniging ICT~Office voorspelt dat de markt voor ict-dienstverlening voor het eerst in jaren weer bescheiden gaat groeien (met 1 procent). Het is te hopen dat ict’ers niet terugvallen in hun Pavlov-reactie gericht op schijnzekerheid van uren, maar dat klant en leverancier samen kritisch kijken naar de waarde van de ict-investering en deze afzetten tegen de kosten. Dit maakt de ict namelijk een gewone, volwassen branche. Ik ben heel benieuwd naar de mening van mijn collega’s hierover en nodig hen dan ook graag uit te reageren.
Mich�l Stijlen, Directeur Caesar Groep
