0 
0 Het bouwen en implementeren van IT-systemen heeft een dubieuze reputatie. “Het duurt twee keer langer en kost twee keer meer dan gedacht” is een veelgehoorde uitspraak. En niet zonder reden! De media berichten regelmatig van uit de hand gelopen projecten. Gelukkig zijn er ook veel voorbeelden van geslaagde projecten en goed uitgepakte business cases. Vanzelfsprekend is de kwaliteit van de betrokken IT-ers van belang. Maar ook u als opdrachtgever heeft het succes van een project voor een groot gedeelte in eigen hand.
Een eenvoudige tip om veel te besparen
Een bekend, gevierd en bekritiseerd schrijver zei “Er komt een moment dat je een werk niet meer beter maakt, maar alleen aan het veranderen bent. Train jezelf om dat moment te herkennen”. Dit is recentelijk nog aangehaald op MT.nl. Hetzelfde kan gezegd worden over de bouw van IT-systemen. Welk doel heeft u met een systeem? Betere informatievoorziening, snellere afhandeling, lagere kosten? Het periodiek beoordelen van Agile projecten op het basiscriterium is van evident belang om maximaal resultaat tegen minimale kosten te boeken.
Als ik een berg zand wil verplaatsen, is een shovel een geweldig middel om snel meters te maken. De laatste scheppen doe ik met een schop, de laatste “korrels” met een bezem. Sterker nog, ik accepteer dat ik de laatste korrels alleen verdeel. Het maakt geen significant verschil of ik deze korrels ook verplaats krijg naar de nieuwe bestemming.
En toch is dat wat we met IT-systemen vaak doen. We beginnen de bouw van een systeem om iets significants te veranderen of verbeteren. We itereren door tot we een werkend geheel hebben, we itereren door tot we dat hebben geoptimaliseerd en dan modderen we door totdat echt alles met het nieuwe systeem kan. Of aangetoond hebben dat dat niet lukt… Waarom? Waarom accepteren we niet dat het nieuwe systeem zijn grenzen kent, dat er uitzonderingen blijven en dat we voor die uitzonderingen een prima work-around kunnen bedenken? Als we voor iedere work-around de business case vergelijken met dat wat nodig is om het het systeem aan te passen, zouden we ze nooit automatiseren. Maar verstopt in de scope, gebeurt dat vaak wel. En dat leidt niet alleen tot hogere realisatiekosten en een veel langere realisatietijd, maar ook tot exponentieel hogere exploitatie- en beheerkosten. Omdat er meer te onderhouden is én de te beheren software veel complexer is geworden.
Acceptatie
Acceptatie wordt meestal gebruikt als term voor het moment waarop wordt gecontroleerd dat een systeem aan alle specificaties voldoet. Als we Acceptatie wat meer gebruiken als term om aan te geven dat we systeem- en complexiteitsgrenzen erkennen, winnen we veel tijd, geld en energie. Train uzelf en uw collega’s om het moment te herkennen dat het beoogd resultaat niet meer beter wordt. Als u dan energie stopt in een methode om de laatste uitzondering ook als zodanig te behandelen, zult u zien dat de IT-productiviteit exponentieel toeneemt. IT moet toegevoegde waarde leveren en daar moet dan ook de focus van de besturing op liggen.
Ik vind het een uitdaging om met minder energie het punt te bereiken waarop ik kan vaststellen dat doormodderen eigenlijk niets meer oplevert. En dus blij te zijn met de warde die is gecreëerd.
