De verborgen kosten van het managen van een softwareleverancier

De factuur van je softwareproject toont €500.000. Wat hij niet toont, is de 14% van het werkjaar van je CTO die is opgegaan aan het managen ervan.

Elk enterprise softwareproject heeft een gepubliceerde kostprijs en een werkelijke kostprijs. De gepubliceerde kostprijs is wat de leverancier factureert. De werkelijke kostprijs omvat de interne tijd die je organisatie besteedt aan dat project: requirements coördineren, opleveringen beoordelen, verduidelijkingen achterna zitten, statusgesprekken voeren, escalaties managen en scope heronderhandelen.

Bij de meeste organisaties wordt deze overhead nooit gemeten. Hij wordt opgeslokt door de tijd van senior medewerkers en afgeschreven als de kosten van zakendoen. Maar hij is substantieel, stapelt zich op over meerdere leveranciers, en is vaak groter dan de efficiëntiewinst die de software zou moeten opleveren.

De vier categorieën overhead

Interne managementoverhead bij softwareprojecten valt doorgaans in vier categorieën uiteen.

Requirements-coördinatie. Businessbehoeften vertalen naar specificaties die een extern team kan bouwen. Documenten schrijven, workshops leiden, beoordelen en herzien. Bij een middelgroot project kost dit doorgaans 2 tot 4 weken van de tijd van een senior business analist of product manager.

Beoordeling van opleveringen. Evalueren wat de leverancier heeft gebouwd. Demo's draaien, feedback schrijven, demo's herhalen. Dit wordt vaak onderschat omdat het licht aanvoelt, maar het komt elke sprint terug.

Escalatiemanagement. Geschillen, misafstemmingen en scopevragen afhandelen. Bij een gemiddeld project van 6 maanden kun je rekenen op 3 tot 5 significante escalaties. Elke escalatie betrekt meerdere senior mensen en een oplossingsproces dat dagen of weken kan duren.

Administratieve overhead. Inkooporders, facturen, change requests, contractwijzigingen. Juridische toetsing van elke wijziging. Goedkeuringscycli van finance. Elk item is klein op zich; samen tellen ze op.

Bij elkaar opgeteld vertegenwoordigen deze doorgaans 15 tot 25% van de factuur van de leverancier, betaald in interne seniortijd.

De cijfers doorgerekend

Een softwareproject van €500.000 met 20% overhead kost in totaal €600.000. Maar omdat de overhead in mensentijd zit, niet op een factuur, blijft die €100.000 onzichtbaar.

Op individueel niveau besteedt een CTO die 14% van zijn jaar besteedt aan het managen van één leverancier ongeveer 35 dagen aan statusgesprekken, spec-reviews en escalaties, tijd die niet beschikbaar is voor architectuurbeslissingen, teamontwikkeling of strategisch werk.

Voor organisaties die tegelijkertijd drie of vier significante softwareprojecten draaien, vermenigvuldigt de overheadberekening zich. Drie projecten met elk 20% overhead betekent dat 60% van de tijd van senior management wordt opgeslokt door leveranciersmanagement, nog voordat er strategisch werk begint.

De verborgen kosten van leveranciersmanagement zijn geen afrondingsfout. Voor organisaties met meerdere gelijktijdige projecten kunnen ze de kosten van een fulltime senior aanwerving overstijgen.

Waarom het probleem opschaalt met de omvang

Overhead van leveranciersmanagement is niet lineair. Een tweede leverancier voegt niet zomaar 20% overhead toe. Het is meer, omdat afhankelijkheden tussen leveranciers nieuwe coördinatieproblemen creëren.

Wanneer Project A afhankelijk is van een API van Project B, en Project A loopt achter, dan gaat het statusgesprek over Project A ineens ook over de status van Project B. Escalaties van de ene leverancier beginnen de planning van de andere te beïnvloeden. Een projectmanager die twee relaties managede, managet nu de relatie tussen die relaties.

Dit is de reden waarom grote enterprises vaak merken dat hun softwareontwikkelingsportfolio beweegt op de snelheid van het traagste project, ongeacht hoeveel er wordt uitgegeven aan de snelste projecten.

Het alternatief: ingebedde verantwoordelijkheid

Het probleem van managementoverhead kent één structurele oplossing: minder, langduriger relaties met partners die zelf een groter deel van de leveringscyclus in handen houden.

Een ingebedde leveringspartner (een partner die functioneert als verlengstuk van het interne team in plaats van als externe contractant) verlaagt overhead op een specifieke manier: in plaats van dat requirements naar buiten gaan en opleveringen terugkomen, zit de partner binnen de cyclus. Requirements worden in real time verfijnd. Opleveringen worden continu beoordeeld. Escalaties worden onmiddellijk opgelost, omdat de partner aanwezig is, niet op afstand.

Het dagtarief van een ingebedde partner kan hoger liggen. De kosten als percentage van de totale projectuitgaven zijn doorgaans lager, omdat de overhead wordt opgenomen in de leveringsrelatie in plaats van erbovenop te komen.

Drie vragen voordat je tekent

Als je de werkelijke kosten van een relatie met een softwareleverancier wilt inschatten voordat je je committeert, stel dan drie vragen.

Wie aan onze kant besteedt tijd aan het managen van deze relatie, en hoeveel uur per week? Als het antwoord \"gewoon een wekelijkse check-in\" is, heb je te maken met een zeer ervaren partner, of onderschat je de betrokkenheid.

Wat gebeurt er als requirements veranderen? Bij een traditionele leverancier piekt de overhead op wijzigingsmomenten: nieuwe change request, nieuwe onderhandeling, nieuwe contractwijziging. Een ingebedde partner vangt verandering op binnen de leveringscyclus.

Hoe ziet het escalatiepad eruit? Als een escalatie van projectmanager naar accountmanager naar engagement director gaat, kijk je naar overhead. Gaat het rechtstreeks naar de persoon die het probleem kan oplossen, dan niet.

De verborgen kosten van het managen van een softwareleverancier zijn geen wetmatigheid. Ze zijn een gevolg van de structurele afstand tussen jouw business en het team dat ervoor levert. Dicht die kloof, en de overhead verdwijnt.