Tien factoren voor succesvolle projecten

test

Het is niet makkelijk om te bepalen wat de verhouding is tussen geslaagde en gefaalde IT projecten. Een van de belangrijkste criteria is natuurlijk: is het project opgeleverd volgens de initiële begroting en tijdsplanning? Daarnaast moet het eindproduct aan kwaliteitsnormen voldoen en moet het daadwerkelijk in gebruik worden genomen. Hardere normen in vorm van wetten en regels ontbreken vooralsnog in de IT sector.

Toch is het niet eenvoudig om een project te evalueren op succes omdat juist een businesscase vaak ontbreekt, waarmee dit zou moeten gebeuren. Dikwijls zijn de resultaten van een eindproducten niet zo goed en snel zichtbaar als een atoombom. (Manhanttanproject wordt als het begin van het modern project management gezien)

Er zijn vele onderzoeken uitgevoerd op het gebied van IT projecten. Het “CHAOS” rapport van de Standish Group (anno 1994) is een van de bekendste onder deze studies. Kort samengevat enkele conclusies: 31,1% van alle projecten werden geannuleerd zonder afgerond te worden en meer dan de helft van de projecten kostten 189% meer als de originele schatting.

Ernst & Young voert de zogenaamde ICT Barometer onderzoek uit. Het onderzoek wordt sinds december 2001 tweemaandelijks gehouden. Volgens het “ICT Projecten Ondezoek Juni 2007” kan minder dan de helft van Nederlandse projecten succesvol worden genoemd. Hoewel het rapport concludeert dat maar slechts 4% van de projecten echt mislukken, is dit volgens mij gewoon creatief rekenen. Ik zou eerder zeggen dat 40% echt mislukt omdat geen enkele randvoorwaarde is gehaald maar uiteindelijk zo veel geld en energie is gestoken om maar een eindresultaat te toveren zodat het niet als een mislukt project bestempelt kon worden.

Ook bij de overheid is het nog niet goed geregeld. De overheid heeft geen heldere zicht op uitgaven en heeft geen mechanismen om de projecten te coördineren zoals het hoort. Ook zijn het vaak monsters van projecten zonder kop of staart.

1. Volledige vereistenspecificatie
Essentieel element voor elk project. Het klinkt eigenlijk zo ontzettend vanzelfsprekend: allereerst glashelder formuleren wat er ontwikkeld moet worden, zodat er geen mogelijkheid kan bestaan van verkeerde interpretatie. De opdrachtgever weet wat er opgeleverd moet worden en de opdrachtaannemer begrijpt wat de verwachtingen zijn.

Hierbij is het belangrijk dat niet alleen de algemene vereisten beschreven worden, maar ook de specifieke vereisten. Als vuistregel geldt: niets is vanzelfsprekend!
2. Project team: Technische vaardigheden en motivatie
Ook al zijn de specificaties tot op het puntje volkomen uitgewerkt en is er aan alles gedacht is het kennisniveau en vaardigheid van het projectteam cruciaal. Tevens is kennis en vaardigheid tevergeefs zonder motivatie. Succesvolle projecten blijven prestaties van teamleden. Zonder volledige inzet zal elke project stranden.
3. Competent project manager
Vergelijk het met een vliegtuiglanding: naast vele andere factoren zoals het weer of de toestand van de landingsbaan, is een succesvolle landing bijna onmogelijk zonder een vakbekwame piloot. Een automatische piloot kan in normale situatie's prima helpen, maar juist als er problemen zijn moet er iemand krachtig kunnen ingrijpen.

4. Duidelijk business case en doelen
Een project kan alleen succesvol worden beschouwd als het project bijdraagt aan de bedrijfsdoelstellingen. Daarom moeten deze doelen door iedereen, vanaf het begin van het project bekend zijn. Alleen op deze wijze kan er gegarandeerd worden dat alle activiteiten getoetst kunnen worden aan de wezenlijke vraag: waarom voeren we een bepaalde taak uit?
5. Betrokkenheid van de eindgebruiker(s)
Vanaf het begin tot eind behoren eindgebruikers een integraal onderdeel te zijn van het project. In elke fase van het project kunnen eindgebruikers input leveren en kunnen afwijkingen tijdig gesignaleerd worden.
6. Realistische verwachtingen
Alle betrokken zullen nuchtere verwachting moeten hebben van het project. Het onmogelijk om een software pakket zoals bijvoorbeeld “Microsoft Word 2007” door 2 programmeurs in 2 weken te laten ontwikkelen. Tevens is het onrealistisch van een developer om te denken dat de volgende release van een software pakket wel nog 6,5 jaar kan wachten. Kortom: een realiteitsfilter doet wonderen.
7. Gestandaardiseerde software infrastructuur
Gebruik maken van een (tot op een zeker niveau) gestandaardiseerde infrastructuur voor software zorgt er voor dat er meer tijd beschikbaar is voor business logica en configuratie management zodat het uiteindelijke product beter aansluit op de eisen en wensen.
8. Planning
Een gedegen planning zorgt er voor dat kosten niet overschreden worden en dat het project opgeleverd kan worden op een vooraf bepaalde moment. Ook is er zonder een planning niet mogelijk om de voortgang te monitoren. Ook draagt een planning een essentiële bijdrage aan voor het bewaken van het projectbereik en toewijzen van beschikbare bronnen.
9. Reële fasering
Zorgvuldig bepalen van project fases kan een project maken of breken. Te veel features in een bepaalde fase plannen kan ervoor zorgen dat geen enkel functionaliteit werkt volgens de specificaties of volgens een bepaalde kwaliteitsnorm. Te veel bugs of te weinig tijd voor usability kan dan er voor zorgen dat de software totaal onbruikbaar is.

Dit kan makkelijk voorkomen worden door een eerste versie te lanceren met alleen de basisfunctionaliteiten en vervolgens de software stapsgewijs uit te bereiden met functionaliteiten. Hoe groter een software project is, hoe groter de kans dat het faalt.
10. Nauwkeurige (tijd)inschattingen
Software inschatten is een vak apart. Door ervaring en kennis kunnen onderdelen van een software project exact ingeschat worden waarvoor budget, tijd en bronnen voor gereserveerd kunnen worden. Indien dit niet deskundig gebeurt kan een project catastrofaal worden.