Geef IT niet altij d de schuld

Regelmatig berichten de media over it-projecten die worden stopgezet, enorme vertraging oplopen, of waarvan de budgetten volledig uit de hand lopen of een eindresultaat hebben dat weinig gelijkenis vertoont met de oorspronkelijke opzet. Tussen de regels door proef je vaak verwijten richting de betrokken it-professionals, intern dan wel extern. De techneuten hebben het weer veel te rooskleurig voorgesteld. Toch hebben de meeste mislukkingen niet met IT zelf te maken. Het Britse ministerie van Economie publiceerde recent een aantal interessante best practices. Daaruit kun je ook worst practices destilleren. 
Als belangrijke oorzaak voor mislukkingen wordt het gebrek aan alignment genoemd. Dat is een modieuze term voor de afstemming tussen project en strategische doelstellingen van de organisatie. De tweede oorzaak is gebrekkig leiderschap: het algemeen management zou een project vooruit kunnen helpen met hun inzet, hun connecties en hun leiderschap, maar laten dit na. De derde oorzaak is gebrek van betrokkenheid van deelnemers en andere betrokkenen. Tja, dan hebben we het wel over absolute randvoorwaarden om een project van langere duur over moeilijke momenten te helpen. Ook veel andere faalfactoren hebben weinig met de technologie zelf van doen: gebrek aan samenwerking tussen project team en eindgebruikers; gebrek aan samenwerking tussen projectteam en belangrijke leveranciers. 
Wat betreft de uitvoering lijden veel projecten aan gebrek aan middelen om goed projectbeheer en/of risicobeheer in te zetten. Ik ken heel wat grote projecten waar nog steeds niet aan systematisch risicobeheer wordt gedaan. En zelfs als zou dat risicobeheer maar in een informele vorm door het projectteam zelf gebeuren, dan heeft dat heel wat voordelen. Het kan ervoor zorgen dat het project niet vastloopt op voorzienbare en vaak makkelijk te omzeilen problemen. 
Laat ik tenslotte de usual suspects noemen, zowel bij megaprojecten als bij hele kleintjes. Men heeft niet steeds de gewoonte om grote projecten op te delen in onderdelen die beperkt zijn in tijd en omvang, en die gemakkelijker zijn te controleren en recht te trekken. Bij veel projecten ten slotte wordt wel duidelijk geformuleerd welk voordeel het de onderneming moet brengen, maar ontbreekt de operationalisering hoe de beoogde voordelen worden gedefinieerd en getoetst. Om dan uiteindelijk de IT maar weer de schuld te geven als het fout gaat.