Het is al lang bekend dat IT-projecten te lang duren, teveel kosten en dan meestal matige kwaliteit leveren. Je buurjongen van 16 kan vast in een week een mooi dashboard maken, dus waarom twee dure professionals daar maandenlang voor betalen?

In mijn ervaring zijn er twee factoren die het meest verantwoordelijk zijn voor dergelijke dramatische verschil in productiviteit.

- “Gisteren werkte het nog”
Robuustheid van een oplossing bepaalt hoe vaak hij omvalt. Voor elke regel code (of het equivalent) die de normale werking ondersteunt, zijn vier regels nodig om uitzonderingssituaties af te handelen. Als je alleen de normale werking ondersteunt, valt je oplossing om bij de eerste windvlaag.

- “Kun je dit even aanpassen?”
Een snel in elkaar gezette oplossing kan prima werken, totdat er iets moet veranderen. Is het zo opgezet dat iemand anders dan de uitvinder er wijs uit kan worden? Is de werking beschreven en getest? Is de oplossing volgens gangbare standaarden ontwikkeld? In de praktijk is een snel ontwikkelde oplossing van de buurjongen vaak nauwelijks meer aan te passen.

Dit is ook het grote risico als iemand een “prototype” maakt. De neiging is al snel om het prototype te houden – hij werkt immers. De verborgen kosten en risico’s, daar kom je later achter.

Dat wil natuurlijk niet zeggen dat er altijd per se een Bentley moet worden gebouwd, als je met een snorfiets prima uit de voeten kunt.