Development

Software-ontwikkeling

Het gaat niet zo slecht met automatisering

15 mei 2014

De resultaten van IT-projecten worden vaak over één kam geschoren. Grote projecten scoren slechter dan kleine. Grote mislukte IT-projecten komen eerder in de publiciteit dan geslaagde projecten. Ten onrechte ontstaat het idee dat het slecht gaat met de automatisering in het bedrijfsleven en bij de overheid. Deze opvatting leidt regelmatig tot ongenuanceerde uitspraken als ‘bijna alle IT-projecten mislukken’ of ‘IT-projecten bij de overheid worden slechter uitgevoerd dan bij bijvoorbeeld de retail’. De oorzaak van de verkeerde beeldvorming is mede dat auteurs vaak volstaan met louter de gemiddelde resultaten te citeren. De Nederlandse schrijver Godfried Bomans zei ooit: ‘Een statisticus waadde vol vertrouwen door een rivier die gemiddeld één meter diep was. Hij verdronk.’

Er wordt al jaren systematisch en onafhankelijk onderzoek gedaan naar en verslag gedaan van IT-projecten. Deze onderzoeken tonen aan dat de allergrootste faalfactor voor alle projecten – ook buiten de IT – de ‘omvang’ is. De massa zorgt voor problemen. In Nederland bestaat echter 90 procent van alle IT-projecten uit kleine projecten. En van deze kleine projecten is gemeten dat maar 4 procent mislukt, bij grote projecten is dit 38 procent. Met andere woorden, zo slecht gaat het niet.

Klein en groot

Het bekendste en meest geciteerde onderzoeksbureau, als het om IT-projecten gaat, is de Standish Group International in Boston. Over de jaren 2004 tot en met 2012 onderzocht de Standish Group het resultaat van ruim 50.000 IT-projecten. Deze projecten vonden voor 60 procent plaats in de USA, voor 25 procent in Europa en 15 procent in de rest van de wereld. Over het jaar 2012 is de beste score gemeten van de gehele periode: 18 procent van de projecten mislukte. Daarvoor bestaan verschillende redenen. Er is een toename (in de database) van kleinere IT-projecten, maar er is ook een verbetering merkbaar van leiderschap aan de kant van de opdrachtgever.

Heel anders wordt het beeld wanneer we kleine en grote IT-projecten afzonderlijk weergeven. Projecten waarvan de kosten voor lonen plus inhuur lager zijn dan 250.000 euro worden door de EU geacht te behoren tot kleine IT-projecten. De Standish Group hanteert als definitie voor kleine projecten een loonsom (inclusief inhuur) minder dan 1 miljoen dollar. Voor de Nederlandse situatie betekent dit dat meer dan 90 procent van de IT-projecten onder kleine projecten kan worden gerangschikt.

Kleine IT-projecten waren in 2012 acht keer zo succesvol dan grote projecten en mislukken negen keer minder dan grote IT-projecten. Ook worden kleine IT-projecten vaker op tijd en volgens budget en/of conform de gewenste functionaliteit afgesloten. Wanneer in acht wordt genomen dat in het MKB vaak gebruik wordt gemaakt van softwarehuizen, zegt het percentage van 20 procent problematische projecten weinig over planning en budget. In de verstrekking van de opdracht aan een softwarehuis worden de planning en de begroting door concurrentiedruk vaak omlaag ‘gepraat’. Wanneer achteraf toch meer capaciteitsinzet nodig was, is de typering dat zo’n project problematisch was, weinig realistisch. Naarmate de projectomvang boven de 10 miljoen dollar aan arbeidskosten verder toeneemt, nadert de kans op een succesvol IT-project tot nul.

Succesfactoren

Minstens zo interessant als statistisch inzicht in de resultaten van IT-projecten is de vraag waarom projecten mislukken of slagen. Je zou verwachten dat dit na vijftig jaar automatiseren algemeen bekend zou zijn. Dat is echter niet het geval. Vooroordelen zoals die bestaan over resultaten van IT-projecten, bestaan ook over wie en/of wat verantwoordelijk is voor die resultaten. Er zijn auteurs die schrijven over hun ervaringen met IT-projecten. Die ervaringen zijn waardevol, maar onvergelijkbaar met onafhankelijk en meerjarenonderzoek van tienduizenden IT-projecten. In dezelfde database waarin de projectresultaten zijn vastgelegd, staat ook een veelheid aan eigenschappen over elk project, zoals projectgegevens, typeringen van het op te leveren systeem en de ontvangende organisatie. In het post-mortemonderzoek – of andere ‘project-einde reviews’ bij het (voortijdig) beëindigen van het project – worden de attributen gevuld met metingen over aanpak, skills, capaciteit, methodieken, kosten, tools, managementstijl, besluitvorming tijdens het project, cultuur en allerlei interne en externe invloeden.

In de statistische verwerking van deze gegevens is een top-tien samengesteld van factoren die in 2012 bepalend was voor het falen dan wel slagen van een IT-project. In het kader over faalfactoren staan deze factoren in volgorde van belang en onderverdeeld naar kleine en grote projecten. Er zijn overeenkomsten en afwijkingen, die voor insiders goed invoelbaar zijn, maar die nog niet eerder op zo’n grote schaal statistisch konden worden onderbouwd. Kortom, de omvang van een IT-project is de belangrijkste oorzaak van het mislukken. Bij ‘omvang’ gaat het niet om materiaalkosten, maar over het aantal mensen dat betrokken is bij een project. De mislukking ligt in het onvermogen van mensen om goed samen te werken in het belang van het doel van het project (faalfactoren 1, 2, 3 en 8). Daarmee onderscheiden IT-projecten zich niet van samenwerkingsprojecten van andere aard, zoals grote bouw-, research- of bewustwordingsprojecten.

Succesvol, problematisch of mislukt

De definitie van mislukte, geslaagde en problematische projecten (triple constraints) is afkomstig van PMI, het prestigieuze Project Management Institute. ‘Succesvolle projecten’ zijn naar tevredenheid afgerond volgens planning en budget. ‘Problematische ­projecten’ zijn te laat, hebben meer gekost dan gebudgetteerd en/of hebben systemen opgeleverd met onvoldoende functionaliteit of ­kwaliteit. ‘Mislukte projecten’ zijn voortijdig gestopt en/of de systemen zijn niet in gebruik genomen.

 

Faalfactoren IT-projecten

De eerste drie faalfactoren zijn van organisatorische aard en zijn bij elkaar al goed voor de helft van alle oorzaken van het falen van IT-projecten. De eerste en belangrijkste faalfactor is ‘Management’ en is voor kleine en grote projecten vrijwel gelijk. Faalfactor 2 heeft betrekking op de kennis en vaardigheid van gebruikers die in project- en werkgroepen actief zijn. Scope-beheersing (faalfactor 3) is in grote projecten beter geregeld dan in kleine en daar is alle reden toe, omdat de uitloop van grote projecten ook grotere consequenties heeft dan bij kleine projecten. Kennis en ervaring met IT-projecten (faalfactor 4) zijn ontegenzeggelijk minder ontwikkeld in kleine organisaties dan in grote, die de mogelijkheid hebben om fulltime specialisten aan te trekken. Hetzelfde geldt voor kennis en ervaring op het gebied van projectmanagement (faalfactor 5). Actueel is de discussie over de voor- en nadelen van methoden: ‘waterval’ enerzijds en ‘agile’ anderzijds (faalfactor 6). Onderzoek uit 2012 leert dat er bij kleine IT-projecten geen grote verschillen bestaan – wat betreft projectresultaten – als gevolg van de keuze voor de ene of andere methode. Ook bij grote projecten staat de gehanteerde methode als oorzaak van het mislukken op de zesde plaats. De faalfactoren 7 en 8 spelen een grotere rol in grote dan in kleine projecten. Dat heeft alles te maken met het feit dat grote projecten zich afspelen in grote organisaties. De faalfactoren 9 en 10 hebben een geringe impact op IT-projecten.

 

‘Triple constraints’ versus ‘Value based’

Voor IT-projecten is de definitie van ‘triple constraints’ wel wat rigide blijkens de twee hieronder opgenomen voorbeelden. Ook PMI besteedt inmiddels meer aandacht aan Value Based Project Management, waarbij meer wordt gekeken naar het effect voor de organisatie en minder naar de effectiviteit van het project zelf. Uit voorbeeld 1 blijkt dat een problematisch project voor een bedrijf een positieve opbrengst kan hebben en uit voorbeeld 2 dat een goed project verliesgevend voor een organisatie kan zijn.

Voorbeeld 1
Een IT-project is begroot op 100.000 euro. De waarde voor de organisatie bedraagt 400.000 (bijvoorbeeld arbeidsbesparing). Opbrengst voor de organisatie 300.000. Het project loopt uit met een budgetoverschrijding van 50 procent, dus 150.000. Volgens de triple constraints-definitie dus een problematisch project. De opbrengst voor de organisatie is echter 250.000 euro.

Voorbeeld 2
IT-projectkosten zijn begroot op 250.000 euro. Het project is op tijd gereed en de kosten waren 200.000. Volgens de triple constraints-definitie dus een goed project. De opbrengst voor de organisatie is negatief. Na een jaar is het systeem buiten gebruik gesteld wegens gebrek aan baten. Totale kosten van die operatie waren 125.000. Verlies voor de organisatie is echter 375.000 euro.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!