IT-sectorheeft eigen waakhond nodig

Te laag opleidingsniveau van medewerkers? Incompetent IT-management? Opdrachtgevers die het niet begrijpen? Op zoek naar een antwoord wijzen IT’ers al snel naar mensen, de organisatie of methode. Als de problemen zo voor de hand liggen, waarom wordt er dan niets aan gedaan?
Er is iets fundamentelers mis. Het is ijdele hoop om te denken dat softwareontwikkelingsprojecten vanzelf beter worden. Na tientallen jaren van aanmodderen is het nu tijd voor dwang. Tijd voor verbeterplicht. En tijd voor toezicht op daadwerkelijk en effectief gebruik van de al zo lang bekende best practices.

Open deuren
Het zijn open deuren, de redenen voor het niet toepassen van bewezen technieken (zie kader ‘Stilstand in ICT’). In plaats van er dan iets aan te doen, zijn IT-organisaties druk met het adopteren van de een na de andere methode of technologie. Het kost al snel enige jaren om bijvoorbeeld echt agile te leren werken, maar organisaties maken geen tijd vrij om zo’n leerproces te doorlopen. Nieuw is namelijk beter, met als gevolg dat de IT-klassiekers ondergeschoven kindjes blijven. Wel RUP zeggen toe te passen, maar Barry Boehm niet kennen. Wel de nieuwste technologie onderwijzen, maar niet Swebok gebruiken als basis voor het curriculum.
Er is weinig voor nodig om een nieuwe methode of techniek tot een hype te ontwikkelen. Zorg voor een paar kopstukken met rockster-allure en laat die vooral veel boeken schrijven. Een grove telling op amazon.com van het aantal boeken over serviceoriëntatie levert gemakkelijk tientallen titels op. Het is verwonderlijk hoe snel een paar ogenschijnlijk goede ideeën vaak zonder enig tastbare vorm van validatie worden opgeblazen.
Zo zijn IT-organisaties druk genoeg – maar niet met zaken die daadwerkelijk bijdragen aan het wegnemen van de barrières voor het toepassen van zinnige ideeën. Open deuren blijven zo wagenwijd open.
De gevolgen zijn uitermate onprofessioneel, om niet te zeggen onverantwoord. Hoe kan het dat ontwikkelaars overdag software schrijven waar ze zich ’s avonds, bij het bijdragen aan weer een nieuw stoer open-sourceframework, diep voor zouden schamen? Hoe kan het dat organisaties de status van projectleiders bepalen aan de hand van de omvang van projecten en niet op basis van de mate van succes? Het is te vanzelfsprekend dat ontwikkelaars en projectleiders na opzichtig falen gewoon weer in een volgend project, op dezelfde manier, aan de slag gaan. Opvallend is dat IT’ers met dit soort zaken wegkomen. Falende projecten van een omvang die een parlementaire enquête zouden rechtvaardigen, halen misschien net de voorpagina van Automatisering Gids.
Natuurlijk zijn er uitzonderingen. Bij systemen waar mensenlevens op het spel staan, blijkt softwareontwikkeling professioneler te moeten én te kunnen. Maar waarom gebeurt dat niet structureel, dus ook bij de ontwikkeling van administratieve software of pakketimplementaties? Of, om te beginnen, als er belastinggeld op het spel staat?
Blijkbaar zien en voelen betrokkenen de pijn van mislukking nog te weinig. Falen in de IT wordt als een fact-of-life beschouwd en niemand lijkt echt geïnteresseerd in de oorzaken. Het lukt IT’ers (en alle andere betrokkenen bij IT-projecten) nog steeds goed om een speciale positie te claimen voor hun vakgebied. Het inzicht dat het beter kan is nog geen reden om iets te veranderen: blijkbaar is er geld genoeg. Bij uitloop komt het project gewoon op de agenda van het volgende jaar.
Niemand heeft ook direct belang om het echt beter te doen. Opdrachtgevers scoren in hun organisaties met grote projecten, ondanks dat de grootte van een project toch ook een bekende faalfactor is. Leveranciers verdienen meer aan langlopende projecten met veel meerwerk. Auditoren ontlenen zelfs deels hun professionele bestaan aan het feit dat er slecht lopende projecten zijn. Het algemeen belang is niet de optelsom van de afzonderlijke deelbelangen in ontwikkelingstrajecten (zie kader ‘Iteratief ontwikkelen in niemands belang’).

Afgedwongen ethiek
Deze barrières liggen op een heel ander vlak dan de veelgenoemde barrières als gebrek aan opleiding of incompetent management. Zolang alle betrokken IT-partijen eerder beter dan slechter worden van mislukte projecten, kan de oplossing niet van de IT-branche zelf verwacht worden. De discussie over verbetering moet dan ook plaatsvinden in het publieke domein, niet binnen de branche.
Verbeteren gebeurt niet vanzelf. De urgentie van het probleem wordt niet afdoende gevoeld door degenen bij wie de macht ligt om er iets aan te doen. Er wordt niet geleerd van mislukkingen of problemen, en dat leidt tot steeds weer gemaakte fouten. Van zelfregulatie is de afgelopen jaren niets gebleken.
Om echt te verbeteren is dwang nodig. Beter toezicht op IT-projecten is onontbeerlijk. De IT-sector heeft een eigen waakhond nodig, een eigen toezichthouder of zelfs autoriteit, die de bevoegdheid heeft om volwassen gedrag af te dwingen. Deze toezichthouder moet zich bezig houden met het zichtbaar maken van de problemen. Dan komt er maar eens een parlementaire enquête over de besteding van belastinggeld in IT-projecten. Een andere taak is het verzamelen van relevante informatie over methodes en het (laten) onderzoeken in hoeverre ze echt werken. Van veel methodes bestaat een meer of minder gefundeerd vermoeden dat ze werken, maar het is hard nodig dat er een echte onderbouwing komt van wat werkt en waar wel of niet en waarom wel of niet. Inzicht in wat werkt is veruit te verkiezen boven het blind volgen van hypes.
Misschien moet er wel wet- en regelgeving komen waarmee de autoriteit toezicht kan (laten) houden op daadwerkelijke toepassing van de bewezen methodes. IT-organisaties – leveranciers en opdrachtgevers – moeten immers op hun aandeel en een falend IT-project worden aangesproken.
Dit betekent niet dat individuele IT’ers hun eigen verantwoordelijkheid kunnen blijven afschuiven. Beroepsorganisaties zoals IEEE en ACM hebben al een ‘code of ethics’ die beschrijft hoe een professional zich moet gedragen. De toezichthouder moet dan ook maar meteen IT-professionals zo’n code laten ondertekenen. Jammer dat Hippocrates geen IT-vrienden had – een eed als de zijne kan de IT-branche goed gebruiken.


Kader: Stilstand in ICT

Op 1 juni jl. stonden deelnemers van het seminar ‘25 jaar stilstand in de ICT’ stil bij de vraag waarom bewezen methodes en technieken niet of maar zeer beperkt worden toegepast. Ze dachten na over barrières op de gebieden van engineering, management en competenties. Ook een IT-grootheid als Barry Boehm, de bedenker van het spiral model voor softwareontwikkeling, houdt zich met vergelijkbare vragen bezig, getuige zijn keynotepresentatie op de laatste International Conference on Software Engineering.
De drie categorieën van oorzaken voor het niet toepassen van methodes die op het seminar naar voren kwamen, zijn:
• Het individu. Hier spelen zaken als angst voor verandering, onduidelijkheid over ‘what’s in it for me’, gebrek aan discipline, de keuze van politiek boven ratio, het geen grenzen kunnen en durven stellen.
• De organisatie. Barrières zijn incompetent management, incompetente medewerkers, een tegenwerkende cultuur, het ontbreken van aandacht voor leren, het afschuiven van verantwoordelijkheden, het ontbreken van aandacht voor een juiste teamsamenstelling, het ontbreken van geld of tijd voor verbetering.
• De methodes zelf. Methodes zijn te moeilijk of worden ‘in name only’ toegepast. Vaak is niet duidelijk wat de baten zijn en bovendien volgen methodes elkaar te snel op.