Of, waarom (veel) (grote) automatiseringsprojecten mislukken

Vierde deel en slot.

Waarom gaan zoveel automatiseringsprojecten mis, vroeg ik in de drie vorige blogs af? Ik denk dat het te maken heeft met de omvang ervan. In een viertal blogs wil ik dat aan u uitleggen. Dit is de vierde en tevens slot.

De voorgaande blogs

In de drie voorgaande blogs beschreef ik de totstandkoming, de start van een automatiseringsproject en de jaren van programmeren en testen. 

De conclusie van de eerste blog (lees het hier) was dat tijdens de plannenmakerij tot aan de kick-off alles goed verliep.

In de tweede ging (lees het hier) er al van alles fout en liep men fors uit de tijd en het budget.

De derde blog eindigde met de allesomvattende zaterdagtest en de vraag, zou het lukken? Werkt het systeem….?

Welnu, dit is het vierde deel en slot en wat blijkt? Het systeem werkt niet!

Het moet toch een kleinigheid zijn?

Het systeem werkt niet! Hoe kan dat nou? De stuurgroep komt, ook in de zaterdagse spijkerbroek, in het kantoor van de directeur bijeen. Waar gaat het fout, kunnen we dat nog repareren? vraagt de directeur. Hij is in charge. Dit mag nu niet mis lopen. Er staat veel op het spel. Wat kost het repareren? Het zal toch maar een kleinigheid zijn? Niemand weet het. Er zal eerst moeten worden onderzocht wat er precies is misgegaan. Alles wordt weer in de oorspronkelijke vorm teruggezet, de roll back, want maandag gaat de business weer gewoon van start. Men gaat naar huis, eerst maar eens van het weekend genieten. Maandag zien we weer verder.

Té quick and té dirty, téveel workarounds

Het systeem blijkt het niet te doen. Helemaal niet. Het wordt niet duidelijk waar het aan ligt, maar men vermoedt dat de programmering van de volledig uitgeklede functionaliteit, waar ook nog eens nieuwe zaken aan zijn toegevoegd, onder de tijdsdruk te quick and te dirty is geweest. Om dat op te lossen heeft men zijn toevlucht tot te veel workarounds gezocht. Men had meer tijd moeten nemen voor kwalitatief goed programmeren en behoorlijk  testen en minder in de functionaliteit moeten snijden en, erger nog,  daaraan zaken toe te voegen. Tegen bewegende doelen valt natuurlijk niet op te programmeren, dat begrijpt toch iedereen?

Groep van ‘wijze mannen’

Er komt na verloop van tijd een groep van ‘wijze mannen’ bijeen om te bezien wat er gedaan moet worden, of er nog iets van dit nieuwe systeem gered kan worden en hoe verder te gaan. Het bedrijf is door deze mislukking in een diepe crisis geraakt. Personele consequenties vallen niet binnen het mandaat van deze groep, maar daarbuiten valt te beluisteren dat er ‘koppen gaan rollen’.

En nu het antwoord op de vraag van de vier titels van dit vierluik. De oorspronkelijk vraag was:

How do you eat the elephant?

De oplossing…..:  you chop him into pieces and eat one bite at a time.

De groep van wijze mensen bedenkt een oplossing waarbij het nieuwe systeem fasegewijs zal worden herbouwd en geïmplementeerd. Daarmee nemen de risico’s af, kan rekening worden gehouden met de immer in beweging zijnde markt, hoeven geen consessies aan programmering en testen te worden gedaan, wordt het personeel niet over de kling gejaagd, enfin, het geheel is beter onder controle te houden. Het gaat echter jaren duren en zal veel meer kosten.

Er is nog een nadeel. Er komt geen big bang. De fases zullen op hun beurt fasegewijs worden geïmplementeerd. Stap voor stap dus en de stappen ook weer in stappen. Er zal dus geen sprake zijn van heldendom. De automatisering zal als het ware sluipenderwijs plaatsvinden. Alleen als men na een aantal jaren terugkijkt, zal men kunnen vaststellen dat er toch wel veel bereikt is.

Dus, how do you eat the elephant? You chop him into piecesand eat one bite at the time! Alleen dan, in kleine, controleerbare, afgemeten stappen zijn grote projecten tot een goed einde te brengen. Dat is het goede nieuws! Het nadeel? Je wordt een geen held van….

Nog even ter bevestiging een uitsmijter van Walter Elliot, voor een volgende blog, zie foto.