Waarom externe IT-partners vaak falen (en hoe je dat voorkomt)
Laat me beginnen met een situatie die ik een tijdje geleden meemaakte. Een KMO uit Mechelen had al hun derde IT-leverancier op rij moeten ontslaan. "Walter," zei de CEO gefrustreerd, "hoe kan het dat we steeds weer bij hetzelfde probleem uitkomen? Ze beloven gouden bergen, leveren steenhopen."
In mijn 20 jaar ervaring in IT-projecten, eerst in de software testing wereld en later als program manager bij Make IT So, heb ik dit verhaal helaas te vaak gehoord. Samen met mijn zakenpartner Jan Festjens begeleiden we bedrijven door deze uitdagingen, en gaandeweg besef ik dat het probleem niet altijd bij de leverancier ligt - het begint vaak al bij de selectie.
Het patroon dat ik steeds terugzie
Normaal gezien zou je verwachten dat bedrijven leren van hun fouten. Maar wat ik zie in de praktijk is een zich herhalend patroon:
- De noodkreet: "We hebben dringend een nieuwe oplossing nodig"
- De snelle keuze: De leverancier die het snelst kan starten, wint
- De teleurstelling: Na 6 maanden zitten verwachtingen mijlenver uit elkaar
- De breuk: Het project wordt stopgezet of de leverancier gewisseld
- De herhaling: Het hele proces begint opnieuw
Als man in the middle van de verschillende partijen zie ik dit drama zich steeds weer afspelen. En eerlijk gezegd, beide kanten dragen hun deel van de verantwoordelijkheid.
Waarom IT-partnerships zo vaak mislukken
Onduidelijke verwachtingen vanaf dag één
"We willen een systeem dat alles kan." Deze zin hoor ik regelmatig tijdens intake gesprekken. Het probleem? "Alles" betekent voor iedereen iets anders. De leverancier denkt aan een standaardoplossing, de klant droomt van een Ferrari op maat, en liefst van al nog met gouden klinken.
Communicatie die niet klopt
IT-mensen spreken vaak een andere taal dan business mensen. Waar de leverancier het heeft over "API-integraties" en "middleware", denkt de klant aan "gewoon laten samenwerken". Deze vertaalslag gaat regelmatig mis.
Budget versus realiteit
Ik zie het te vaak: leveranciers die bewust te laag inschrijven om de opdracht binnen te halen. En klanten die denken dat complexe systemen voor een prikkie gebouwd kunnen worden. Die illusie wordt nooit waarheid.
Gebrek aan eigenaarschap
Beide partijen schuiven verantwoordelijkheden heen en weer. De leverancier zegt: "De klant levert de input te laat." De klant zegt: "Ze hadden dit moeten voorzien." Ondertussen loopt het project vast.
De rol die wij spelen bij Make IT So
Jan en ik hebben Make IT So opgericht vanuit de overtuiging dat er een andere manier moet zijn. Wij fungeren niet als leverancier, maar als gatekeeper - iemand die de belangen van de klant verdedigt tegenover alle betrokken partijen.
"Make IT So is onze verzekering dat we de juiste strategische keuzes maken," zei een CEO ooit tegen mij.
Dat vat onze rol mooi samen. We staan aan de kant van onze klanten, niet aan die van de leveranciers.
Onze ervaring leert dat de meeste problemen ontstaan doordat er geen neutrale partij is die:
- Ervoor zorgt dat iedereen elkaar begrijpt
- Verwachtingen helpt aligneren
- Complexe technische zaken vertaalt naar business impact en complexe business processen vertaalt naar een realistische digitale werkwijze
- Toezicht houdt op planning en budget
- Ingrijpt wanneer het fout dreigt te lopen
Concrete signalen dat je leverancier gaat falen
Na al die jaren herken ik de waarschuwingssignalen:
Week 1-4: De honeymoon fase
- Alles lijkt perfect te lopen
- Leverancier is super enthousiast
- Eerste demos zien er veelbelovend uit
Week 5-12: De eerste scheurtjes
- "Kleine aanpassingen" die plots weken kosten
- Communicatie wordt minder frequent
- Deadlines worden "licht bijgestuurd"
Week 13+: De crisis
- Budget overschrijdingen stapelen zich op
- Oorspronkelijke planning is volledig losgelaten
- Leverancier begint te wijzen naar externe factoren
Herken je dit patroon? Dan is het tijd om in te grijpen, niet om te wachten tot het helemaal vastloopt.
Hoe voorkom je deze valkuilen?
Begin met een degelijke intake
Ik geloof sterk dat 1+1 gelijk is aan 3, maar dan moeten alle partijen wel samen aan eenzelfde zeil trekken. Dat begint met kristalheldere afspraken over wat er verwacht wordt. Neem dus de tijd om high-level alles te analyseren en door te spreken.
Zorg voor een neutrale gatekeeper
Iemand die niet financieel gebaat is bij het groter maken van het project, maar wel de expertise heeft om kwaliteit te bewaken. Wij vervullen deze rol regelmatig voor onze klanten.
Gefaseerde betalingen met mijlpalen
Betaal nooit alles vooraf. Koppel betalingen aan concrete opgeleverde functionaliteit, niet aan bestede tijd.
Wekelijkse statusmeetings met concrete deliverables
Geen vage updates over "we zijn goed bezig", maar concrete demo's van wat er die week opgeleverd is.
Plan B vanaf dag één
Wat gebeurt er als de leverancier wegvalt? Hoe neem je het project over? Deze vragen lijken negatief, maar ze dwingen tot duidelijkheid over eigenaarschap van code, gegevens en documentatie.
De menselijke kant van IT-partnerships
Ondertussen is meer en meer duidelijk dat technologie op zich niet het probleem is. Het gaat over mensen die met mensen moeten samenwerken. En daar gaat het vaak mis.
Bij Make IT So proberen we die menselijke brug te zijn. We spreken beide talen: die van de business en die van IT. We begrijpen de druk op leveranciers om projecten binnen te halen, en we begrijpen de frustratie van bedrijfsleiders die geconfronteerd worden met budgetoverschrijdingen en vertragingen.
Alles komt in orde met tijd en boterhammen - als iedereen bereid is om eerlijk te communiceren en verantwoordelijkheid te nemen.
Op zoek naar de juiste partner?
Ik ben ervan overtuigd dat er veel goede IT-leveranciers zijn. Het gaat erom de juiste match te vinden en het partnership goed op te zetten. Dat vraagt tijd, aandacht en soms een neutrale partij die de vertaalslag maakt.
Bij twijfel over een lopend project of hulp nodig bij het selecteren van een nieuwe partner? Laten we van gedachten wisselen. Het is beter goed voorbereid van start te gaan dan achteraf de scherven op te moeten rapen.
De goede partners zijn er wel, je moet ze alleen herkennen.
