We ontwikkelen nu al een aantal decennia op grote schaal software. Dit lijkt een eeuwigheid voor diegene die er vanaf het begin bij betrokken zijn geweest maar als je het vergelijkt met andere vakgebieden zoals het ontwikkelen van medicijnen en het bouwen van huizen dan zijn we eigenlijk nog maar net begonnen. Softwareontwikkeling als vakgebied staat eigenlijk nog maar in de kinderschoenen en kenmerkt zich regelmatig door een grote mate van onvolwassenheid. Maar we worden beter, leren snel en zijn steeds beter in staat om onze softwaretrajecten succesvol af te ronden.

Software ontwikkeling kwam als vakgebied eind 1950 begin 1960 opzetten en er ontstonden discussies over hoe ze dit nu inhoud moesten geven. De NATO science committee heeft in 1968 en 1969 een tweetal conferenties georganiseerd die Software ontwikkeling een laatste zetje gaven op weg naar volwassenheid. Velen zien deze conferenties dan ook als het begin van de Software ontwikkeling als vakgebied.

In de decennia die daarop volgden kwamen we er in de praktijk achter dat het ontwikkelen van software toch complexer was dan eerst gedacht. Veel projecten gingen over budget, haalden hun deadline niet of schoten kwalitatief vaak tekort. Als reactie daarop kwamen veel onderzoekers en bedrijven met nieuwe technieken en methoden en prezen deze aan als de oplossing voor alle problemen. Maar zoals Fred Brooks in 1986 in zijn artikel “No Silver Bullet — Essence and Accidents of Software Engineering” reeds heeft beargumenteerd bestaat er niet een enkele oplossing voor alle problemen.

Ondanks alle nieuwe technieken en methodes worstelen we nog steeds met dezelfde problemen als in het begin van de Software ontwikkeling, projecten gaat nog steeds over budget, deadlines worden niet gehaald en ook de kwaliteit van de software laat vaak te wensen over. Veel bedrijven hebben hun IT projecten niet onder controle, dit blijkt ook uit een 2 jaarlijkse studie van de Standish Group. Hun zogenaamde “Chaos Report” wordt wereldwijd gezien als 1 van de voornaamste bronnen van informatie over de succesfactor van IT projecten in de Verenigde Staten en Europa. Het onderzoek besloeg in 2006, 30.000 projecten van grote tot kleine bedrijven in verschillende sectoren. In 2006 werden 31% van de IT projecten succesvol afgerond, 16% vroegtijdig afgebroken en 50% ging over budget, behaalden niet de vooraf gestelde requirements en/of werden opgeleverd met technische beperkingen.

Nu is er natuurlijk veel kritiek op de bevindingen in het Chaos Report een van de meeste opmerkingen is dat het percentage wat zij succesvolle projecten noemen niet klopt. Dit zou er vooral mee te maken hebben dat bijna niemand een project heeft gedraaid dat en op tijd en binnen budget en met alle requirements is opgeleverd. Ook hoeft een IT project dat binnen budget, tijd en met alle requirements niet altijd succesvol te zijn. Wanneer bijvoorbeeld de software niet aansluit bij de behoefte van de eindgebruikers kan je je afvragen hoe succesvol dat project eigenlijk is geweest. De percentages uit het Chaos Report bevestigen eigenlijk wat we al jaren onbewust of bewust weten: “Het is erg moeilijk om kwalitatief hoogwaardige software te ontwikkelen met een duidelijke meerwaarde voor de onderneming”. Belangijker nog dan de percentages zijn de oorzaken die de Standish Group aandraagt voor het uiteindelijk niet halen van deadlines, requirements en het overschrijden van budgetten.

• betrokkenheid van de eindgebruiker
• onduidelijke requirements
• veranderingen in scope
• ontbreken van management ondersteuning
• geen goede planning
• onrealistische of onduidelijke doelstellingen

Wat opvalt is dat de oorzaken die worden aangedragen niet in de technische hoek liggen maar vooral op het gebied van samenwerking en communicatie. Voor veel IT bedrijven zijn de genoemde oorzaken herkenbaar alleen ligt een goede oplossing niet voor de hand. Vaak wordt er gewezen op de kwaliteit van de medewerkers en het ontbreken van procedures. Natuurlijk zijn deze aspecten van invloed op het eindresultaat van een ontwikkeltraject maar om een echte oplossing te vinden is het belangrijk dat bedrijven op een andere manier tegen softwaretrajecten aan gaan kijken. Om duidelijk te maken hoe, is het belangrijk om bewust te worden van de manier waarop we Software ontwikkeling vaak benaderen.