Laat je nooit uitdagen voor een onmogelijk project

Ik ben maar één keer in mijn IT-carrière ontslagen. Niet door de beveiliging met een kartonnen doos het pand uit gemarcheerd, maar wel ‘Jasper hoeft maandag niet meer te komen’ teruggekoppeld aan de inhuurpartij. Dit alles gebeurde op een project in Inverness, of all places, en al na vier dagen. Ik woonde toen in Edinburgh.

In mijn verdediging: het was 23 jaar geleden, dus ik beschouw het als ruim verjaard. Ik was nog groen, en het was een onmogelijk project. Wat ging er mis en wat heb ik ervan geleerd?

Vergelijk Groningen-Eindhoven (250 km)

Voor het Britse equivalent van de waterschappen moesten alle lokale autoriteiten in Noord-Schotland actuele gegevens aanleveren van hun installaties: pompen, gemalen, etc. Dat was een jaarlijkse exercitie. Voorheen werden al die Excelbestanden verzameld en met de hand ingevoerd. Dat kon efficiënter, dacht men. We huren iemand in om een slimme macro te schrijven en een Oracle programmeur om die output door te sluizen naar de database.

Zoiets had alleen gewerkt als de circa vijftig aanleverende partijen zich netjes aan een voorgeschreven keurslijf zouden houden in de vorm van een Excel sjabloon dat de invoer in goede banen leidde. Maar zo waren ze het niet gewend. Dus kreeg je vijftig subtiel andere versies. Alleen met een slim script dat alle afwijkingen in de mal perste en de onacceptabele afwijkingen eruit pikte had je dat kunnen automatiseren. Een duur (want ingewikkeld) stuk software dat je bovendien uitgebreid moest testen. En eenmaal in gebruik had je ook een proces nodig voor het onvermijdelijk heen-en-weer sturen van handmatige revisies. En volgend jaar had je weer nieuwe sheets ingevuld door andere mensen met nieuwe opvattingen van hun data.

Een software-oplossing onder deze omstandigheden was misschien technisch wel te doen, maar economisch onverantwoord. Iemand had moeten zeggen: “Doen we niet. Verwerk het dit jaar dus nog maar een keer met de hand, en verzin voor volgend jaar een betere procedure. En wees streng naar je leveranciers. Als ze het niet volgens onze standaard invullen krijgen ze het meteen retour”.

Mijn eerste fout was dat ik dit niet al de eerste dag gezegd had. Maar ja, ik had een reis van vijf uur achter de rug en een week gereserveerd in het B&B. Bovendien was ik ingehuurd om code te schrijven en niet om een oplossing te helpen bedenken. Die was er in hun ogen al.

Mijn kapitale tweede fout was dat ik niet meeging in hun technische oplossing. Men dacht dat het met een Excel macro ging werken. Misschien, maar daar had ik weinig ervaring mee. Wel met de Perl Excel library. Maar daar liep ik met mijn laptopje al snel tegen de hardware beperkingen van die tijd aan met de joekels van bestanden. Ik volhardde vier dagen stug op de ingeslagen weg en werd misschien iets te vocaal in mijn gemopper over alle aanleverende partijen. Intussen communiceerde ik nauwelijks over het gebrek aan voortgang.

De moraal van dit verhaal? Een klant die de technische oplossing al helemaal in zijn hoofd heeft is een alarmbel van jewelste. Daar moet je nooit kritiekloos mee akkoord gaan. Vraag je bij elke nieuwe klus ook af of jij wel de juiste persoon op de juiste plek bent. Natuurlijk wil je uitgedaagd worden, maar zelfoverschatting ligt op de loer, zeker aan het begin van je carrière. Ervaring leert je je eigen beperkingen kennen. 

En belangrijkst van alles: liever even geen klus dan een die ik hier beschreef.