Reden nummer 1 waarom IT projecten falen: slechte specificaties

Photo at blog from Hans van Nes - 17/03/2011 - 16:20

Ik ben opgevoed in een IT tijd en wereld waar de focus lag op het specificeren van de bedrijfsbehoefte voordat we gingen ontwikkelen. We noemde ons zelf Information Engineers: we vertaalden de bedrijfsbehoeften in gestructureerde specificaties die zelfs automatische code generatie toelieten. Wellicht in het begin een beetje omstandig maar uiteindelijk precies dat opleverend wat nodig was. Studies hebben aangetoond dat de grootste reden voor het mislukken van ICT projecten verkeerde of incomplete specificaties zijn. Waar ging het mis? Mijn top 3 van oorzaken.

Oorzaak 1: het verdwijnen van de CASE-tools

waar zijn geïntegreerde CASE-tools? In de hoogtijdagen aan het einde van de laatste eeuw, lieten de v4e generatie van deze tools een opmerkelijke kwaliteit en productiviteit zien. Mits toegepast in de juiste combinatie van de tool, mens en methode. Maar hier bij raken we tevens het zwakke punt: rigoureuze procedures, goed getrainde mensen en daardoor een tamelijk hoge investeringen vooraf. Ik herinner mij een CIO van een bank: "Mijn enige ontwikkelingsstraat die echt werkte." Dezelfde CIO waarmee ik jaarlijks in de clinch lag over waarom onze tools en mensen zo "correct" geprijsd waren.

Zijn de case tools verdwenen? Nee, een paar bestaan nog steeds; er zijn er door de Agile trend zelfs bijgekomen. Maar ik denk dat de echte evolutie is gestopt. De specificaties die wij maakten om automatische applicatie generatie mogelijk te maken waren nogal technisch georiënteerd. Doorontwikkeling heeft ervoor gezorgd dat de tools zaken als web functionaliteit en SOA kunnen ondersteunen maar geven mijns inziens geen steun bij het op intelligente wijze verzamelen van bedrijfsbehoeften. Natuurlijk zijn er ontelbare oplossingen voor mind mapping, use case definitie en prototyping. Niets lijkt echter op een 6e generatie CASE-tools te duiden.

Oorzaak 2: ERP

Door de massieve opkomst en succes van een ERP is de gewoonte van gedetailleerde specificatie snel verdwenen. Ja, requirements planning en Gap-analysis kwamen hiervoor in de plaats maar stelden zich tevreden met een veel globaler analyse. Vaak net genoeg om aan de behoefte van de business case te voldoen, zelden diep genoeg om vooraf vast te stellen dat de ERP oplossing werkt volgens "een zekere" specificatie.

De belangrijkste reden waarom vele ERP implementatie's uit de hand lopen qua kosten en tijd is nu juist het ontbreken van gedetailleerde business specificaties. Om de juiste beslissingen te nemen over installatie, inrichting en tuning zijn gedetailleerde specificaties pure noodzaak. Om nog maar niet te spreken over conversie van de legacy. Master data management was niet geheel per ongeluk een sterke functie van de toenmalige geïntegreerde CASE-tools.

Oorzaak 3: IT-Management

Goede ontwikkelaars gebruiken en accepteren specificatie procedures en tools, matige ontwikkelaars vonden altijd een reden om dit niet te doen. IT management had hier moeten ingrijpen maar deed dit vaak niet vanwege uiteenlopende redenen:

  • De goede ontwikkelaars trokken verder en wat resteerde waren de mindere goden
  • De IT consultancy firma's waren nooit erg geïnteresseerd in investeringen in geavanceerde aanpakken
  • IT Managers hadden meestal zelf geen ervaring in het gebruik van geïntegreerde oplossingen
  • Geïntegreerde tools waarom duur in onderhoud en een gemakkelijke prooi voor directe kostenbesparingen
  • De aanbieders van de tools werden overgenomen door de grote IT conglomeraten, met als gevolg veel minder innovatie en minder ondersteuning aan de IT manager
  • De verschuivende focus van maken naar kopen naar outsourcen
  • Wel budgettaire ruimte om fouten te herstellen, geen geld om het in één keer goed te doen

Cynisch? Ooit zelf opdracht gegeven een huis te bouwen? Zou je dat ooit (een tweede keer) doen zonder zeer gedetailleerde specificaties?

Ooit een engineering project zien starten voordat gedetailleerde en afgetekende blauwdrukken waren gemaakt? Waarom is dan de IT niet in staat om deze bewezen aanpak rigoureus de adopteren?

Ik hoor graag jouw verklaring.

hans.van.nes@results2match.com


terug naar boven    meer blogs