Keer op keer verschijnen er berichten over mislukte IT-projecten, met als meest recente voorbeeld natuurlijk de Belastingdienst. Uit een vorig jaar verschenen onderzoek van Ernst & Young blijkt dat maar liefst zestig procent van de IT-projecten die de afgelopen twee jaar zijn gestart, gedeeltelijk of volledig zijn gestrand. Zijn we nu echt zo’n stelletje prutsers?
De cijfers van Ernst & Young liegen er niet om. Tien procent van de projecten faalde volledig, terwijl de helft gedeeltelijk misliep. Samen is dat zestig procent en dat zijn, op zijn zachtst gezegd, schrikbarende cijfers. Projecten mislukten faliekant of deels om verschillende redenen. Meer dan een kwart (27 procent) voldeed niet aan de verwachtingen en overschreed de tijdsplanning. Bij 16 procent rezen de kosten de pan uit.
Ongrijpbaar fenonomeen
Op tijd een IT-project opleveren, het budget niet overschrijden en daarbij ook nog eens voldoen aan de vereiste kwaliteit, het blijkt vier decennia na de introductie van IT nog steeds een onhaalbare kaart. De praktijk wijst uit dat veel projecten uitlopen, vele malen meer kosten en niet het gewenste resultaat opleveren. Een ongrijpbaar fenomeen en de vraag die automatisch rijst is: waarom?
Er zijn voldoende goede projectmanagementaanpakken ontwikkeld, zoals Prince II, er zijn verschillende kwaliteitsmechanismen als CMM en ISO geïntroduceerd en kostenbewaking wordt ook steeds beter ondersteund. En ook het aantal gecertificeerde projectmanagers neemt hals over kop toe omdat de markt hierom vraagt.
Waarom zijn we dan nog steeds niet in staat om projecten fatsoenlijk op te leveren? In de bouwwereld, waar zoveel aan gerefereerd wordt, is men hier toch ook toe in staat? Daar lukt het in elk geval aanzienlijk beter. Wat kunnen zij wat de IT niet kan?
Knelpunten
Als we inventariseren wat er nu precies niet goed gaat binnen IT-projecten, komen we tot een indrukwekkend lijstje. De belangrijkste knelpunten:
– te grote projecten
– trage besluitvorming
– overwaardering van de theoretische architectuur, waardoor de praktische haalbaarheid uit het oog wordt verloren
– overkill aan programmamanagement en projectcontrole
– een veel te zwaar ingericht kwaliteitsbewakingsproces
– onduidelijke afbakening
– wijzigende requirements
– gebrekkige communicatie
Bovenstaand rijtje kan moeiteloos worden aangevuld met nog twintig faalfactoren. Het lijkt ons echter interessanter te kijken naar de oplossingen. Hoe kunnen we falen ombuigen in succes? Een aantal suggesties.
Snelle besluitvorming
Alle projecten worden met de beste bedoelingen opgestart en ingericht. Naar ons idee is daar weinig mis mee, maar het is cruciaal goed te kijken naar de omvang van een project. Is dit overzichtelijk of is het een log, vaag apparaat?
Is dit laatste het geval dan is een eerste stap het opdelen van de projecten in kleine behapbare ‘brokken’. Elke ‘brok’ bestaat uit een klein, zelfstandig multidisciplinair team met een eigen projectverantwoordelijkheid. De samenstelling van deze teams kan verschillen, maar essentieel is dat de overhead beperkt blijft tot één meewerkende voorman.
Te nemen beslissingen moeten op eenvoudige wijze aan een soort centrale review board kunnen worden voorgelegd, die op zijn beurt snel op basis van bondige informatie uitsluitsel geeft. Vergeet de uitgebreide beslisnotities, een goed voorbereide mondelinge toelichting moet volstaan.
Algemene richtlijn is dat een goede projectstructuur en zoveel mogelijk reductie van overhead centraal moeten staan. Want daar zit nu net het venijn: te veel activiteiten zijn slechts indirect verbonden met het projectresultaat. Oeverloze discussies en talloze reviews zijn vaak het gevolg van een te zwaar kwaliteitsapparaat en daar zijn nu juist te veel resources en te hoge kosten mee gemoeid.
Onrealistische idealen
Een overzichtelijke projectstructuur, snelle besluitvorming, beperking van overhead, het zijn al enkele goede stappen op weg naar een succesvol IT-project, maar we zijn er nog niet. We moeten, jammer maar helaas, ook nog af van onze onrealistische idealen.
Natuurlijk, het zou mooi zijn als we in één keer een kwalitatief goed resultaat kunnen neerzetten. Het is precies dát waar projectmanagers naar streven. Onvolledigheid en foutieve functionaliteit zijn uit den boze. Liever lang nadenken en dan in een klap een perfect resultaat neerzetten. Een prachtig maar onhaalbaar streven, in de praktijk werkt het meestal niet.
Slimmer is het om de idealen overboord te zetten en binnen afzienbare tijd een tastbaar resultaat te laten zien. Dat mag dan nog weliswaar aan alle kanten rammelen, het geeft wel een beeld van het uiteindelijke resultaat waar de eindgebruikers op kunnen rekenen.
Prik in ieder geval een deadline en zet het eerste resultaat neer. Het maakt niet uit of je een dag later moet constateren dat er nog twintig fouten in zitten: het gaat om de zichtbaarheid. Wellicht zijn de initiële kosten hiervoor wat hoger – je voert immers meerdere malen een projectresultaat door dat meer fouten bevat dan wanneer er langer over nagedacht wordt – maar er staat in elk geval iets. De kans dat het uiteindelijke resultaat aansluit bij de verwachting en ook daadwerkelijk werkt, is aanzienlijk hoger: het is immers al meerdere malen serieus getest.
Planning is een ander serieus probleem bij een groot project dat als big bang wordt gebouwd.
IT heeft nu eenmaal te maken met onzekerheid vanwege de onzichtbaarheid. Bij de bouw van een huis kan een gebruiker zich beter iets voorstellen dan bij de bouw van een IT-project. Het is vaak te weinig concreet. Om die reden is het ook altijd wenselijk om al bij het opstellen van de requirements een prototype te maken. Dit heeft ook voordelen bij verdere uitbesteding van bijvoorbeeld de realisatie. De User Interface is dan in elk geval redelijk helder.
Verkeerde beeldvorming
Het is niet helemaal fair om alle schuld op de project- of programmamanagers af te schuiven. Ook een opdrachtgever zelf is vaak debet aan uitloop en vertraging van een project. Bijvoorbeeld omdat de gewenste functionaliteit nog lang niet is uitgekristalliseerd. Of omdat men in de loop van tijd weer tot andere inzichten en ideeën is gekomen.
Op de een of ander manier denkt men kennelijk dat het aanpassen van een overeengekomen concept in de IT veel eenvoudiger is dan in de in dit artikel veel geroemde woningbouw, terwijl iedereen weet dat een wijziging in de basis grote (financiële) consequenties kan hebben. Het is dan ook zaak om deze beeldvorming gedoseerd bij te stellen. Dit is goed haalbaar door middel van kleine incrementele opleveringen en het gebruik van prototypes.
Communicatie
Tenslotte is er nog het punt van samenwerking. Niet alleen die binnen het project, maar ook de samenwerking tussen de business en het project. Onvoldoende commitment vanuit de business leidt veelal tot grote misverstanden of onnodige correcties laat in het traject. Prioriteit van de business ligt echter veelal bij andere aspecten, waardoor dit soort misvattingen welhaast onvermijdelijk lijken.
De oplossing ligt voor de hand. Zorg voor een open en heldere communicatie. Niet alleen binnen het project maar ook met de business. Overspoel een organisatie niet met projectinhoudelijke zaken, maar claim hun aandacht – gedoseerd – op de juiste momenten.
Ook is het bijzonder zinvol om de business te betrekken bij teambuildingsactiviteiten waardoor ze zich met het project verbonden voelen.
Conclusie
Resumerend kunnen we stellen dat IT-projectmanagers meer "lef" moeten tonen. Als ze bereid zijn om in eerste instantie een (mogelijk) mindere kwaliteit van de opgeleverde producten te accepteren, levert ze dat in ruil snellere zichtbaarheid op.
Daarnaast moeten ze bereid zijn verantwoordelijkheden te delegeren. Het toewerken naar een resultaat op korte termijn werkt vaak beter en motiverender voor de ontwikkelteams dan een langdurig project.
De voordelen van een dergelijke aanpak zijn duidelijk. Het aantal onzekerheden wordt een stuk minder, de voortgang kan veel beter worden benoemd en de overhead wordt tot een minimum gereduceerd.
Er is nog één voetangel: de organisatie moet open staan voor de alternatieve aanpak. Alleen als de neuzen dezelfde kant opstaan, is er een goede kans van slagen. Maar gaat die vlieger niet altijd op?
Kees Buren, CoolProfs
