De bouw van het nieuwe informatiesysteem Cajis is gestopt omdat het te groot dreigde te worden, en daardoor onbestuurbaar. Ook speelden bezuinigingen een rol bij deze beslissing. Er is ongeveer twaalf miljoen euro uitgegeven aan de ontwikkeling ervan. Delen ervan zullen worden benut bij het opstarten van nieuwe projecten. Dat stelt het ministerie van Justitie in een reactie op eerdere berichtgeving hierover in Computable.
Cajis staat voor Capaciteit en Justiabelen InformatieSysteem. Het gevangenisinformatiesysteem was bedoeld voor de Dienst Justitiële Inrichtingen (DJI) en werd ontwikkeld door het Shared Service Centrum ICT, de ICT-uitvoeringsorganisatie van de DJI in Gouda. Volgens woordvoerder Job van de Sande van Justitie is achter Cajis een punt gezet omdat het project dreigde te ontsporen. 'Cajis diende diverse doelstellingen, zoals capaciteitsmanagement, informatie over justiabelen, plaatsingen en insluitingen, waardoor de scope van het project steeds groter werd en minder bestuurbaar.'
Herbruikbaar
Verder speelde in het besluit om te stoppen met Cajis mee dat DJI moet bezuinigen op de ict-huishouding, aldus Van de Sande. Daartegenover staat dat DJI bezig is met het opzetten van een moderne informatievoorziening die oude systemen moet vervangen en waarmee 'toekomstgerichte beslissingen kunnen worden genomen', aldus Van der Sande. Hij stelt dat de kennis en de producten die Cajis toch hebben opgeleverd, de basis zullen vormen bij het opstarten van nieuwe projecten die wel passen binnen het architectuurlandschap van DJI. De dienst houdt voorlopig het huidige gevangenisinformatiesysteem TULP (Ten Uitvoer Legging Persoonsgebonden straffen) aan, met bouwjaar 1993.
De mislukte ontwikkeling van Cajis heeft circa 12 miljoen euro gekost, meldt de woordvoerder. Het sneven van het project heeft geen directe gevolgen voor medewerkers van het Shared Service Centrum ICT. Wel worden de contracten van een zevental inhuurkrachten ontbonden.
Als je vorige project teveel kostte en te weining opleverde, wat doet ons dan denken dat het de volgende keer beter gaat?
Einstein said: “Insanity is doing the same thing over and over again and expecting a different outcome”.
Het resultaat kan alleen maar veranderen als we dingen anders en beter doen. Dat anders zien we wel eens. Beter zien we niet zo vaak…
In dit geval moeten we afwachten hoe het de volgende keer weer gaat lopen. Gaat het werkelijk beter tegen lagere kosten, of wordt ons geld weer verkwanselt door incompetentie (sorry, ik kan het niet anders noemen: geld van de samenleving over de balk gooien en er mee wegkomen). Statistisch gezien is er niet veel hoop. Het management vetrouwt, zo lijkt het, alleen maar op hoop, of goede praatjes van de leveranciers, die vaak zo gemakkelijk zijn door te prikken.
Quote: “Delen ervan zullen worden benut bij het opstarten van nieuwe projecten”
Kortom opweg naar een nieuwe miljoenenverslindende versie!
Is het echt zo moeilijk om te snappen wat de bedoeling is en welke partijen gebruik gaan maken van het systeem?
Nou en of het soms moeilijk is om te snappen wat de bedoeling is! Want voor toekomstige gebruikers is bepaalde functionaliteit ‘vanzelfsprekend’, en dat blijkt dan pas gaandeweg de rit. Bovendien voegt men tijdens de rit nog allerlei wensen toe. En dan wordt het als leverancier lastig om ‘nee’ te verkopen, ook als interne leverancier..
De requirements wijzigen nu eenmaal gedurende de rit omdat wij leren, zij leren en de omstandigheden wijzigen. Zorg dus voor een proces dat hiermee weet om te gaan.
Onlangs rapporteerde een leverancier dat “de requirements gedurende het project steeds veranderden”. Ze waren echter duidelijk opgeschreven (incl screen shots) en in het geheel niet veranderd. De leverancier leverde echter steeds iets anders dan stond beschreven. Zijn perceptie van de requirements veranderde blijkbaar steeds.
Meer algemeen: We verwachten dat de klant een omschrijving van het te bouwen systeem snapt. De meeste mensen kunnen zich echter bij het lezen van zo’n tekst geen voorstelling maken van wat dit in hun werkelijkheid betekent. Vervolgens moeten ze met bloed tekenen omdat de leverancier anders niet verder gaat. Zodra ze zien hoe het systeem zich in werkelijkheid ontvouwt, kunnen ze zich langzamerhand een voorstelling maken wat het voor hen gaat doen, en dan pas komen de reacties. Geheel voorspelbaar, dus geen excuus. Dit soort dingen treden in elk project op. Als je hier niet mee om weet te gaan …
Denk aan de vijf mogelijke bedrijfsprocessen:
– Wat men verondersteld wordt om te doen
– Wat men vertelt dat men doet
– Wat men in werkelijkheid doet
– Wat het softwaresysteem de mensen wil laten doen
– Wat men eigenlijk zou moeten doen
Waar gaat het nu in werkelijkheid om?
Incrementeel bouwen (Agile, Scrum) is hierop ’t antwoord.
@Gast
Incerementeel bouwen volgens Agile of Scrum helpt in dit geval alleen als je onbeperkt budget en geen eind-datum hebt
Als men gaandeweg het ontwikkeltraject erachter komt dat men het toch anders wil, betekend dat change requests op hetgeen tot nu toe is opgeleverd
Wanneer je maar genoeg change requests krijgt, loop je vanzelf uit budgettijd; daar helpt geen Agile of Scrum aan
@Niels Malotaux
“De meeste mensen kunnen zich echter bij het lezen van zo’n tekst geen voorstelling maken van wat dit in hun werkelijkheid betekent.”
Dit kan je twee kanten op redeneren. Voor zowel de klant als de bouwer. Sterker nog in het algemeen kan je stellen dat een groot en ingewikkeld ICT systeem in algemeen buiten het voorstellingsvermogen gaat van menig menselijke geest om in het abstracte te kunnen zien. Dus die moeten het eerst kunnen zien om te kunnen beslissen of dit is wat ze bedoelen. Alleen heeft de techniek daar nog geen duidelijke oplossing voor. Goed, Agile en Scrum komt redelijk in de buurt maar daar kleven als al eerder opgemerkt ook de nodige nadelen aan.
Volgens mij is het dan ook aan de ICT zelf om de hand in eigen boezem te steken en zich beter te gaan realiseren dat de huidige manier waarop implementaties gerealiseerd worden verbeterd moeten worden. Met name op het vlak van het overzichtbaar houden zodat er beter/sneller duidelijk wordt wat klant en bouwer bedoeld. Hierbij zal de klant dan ook veel makkelijker over de streep komen en akkoord gaan met een intensiever (lees duurder) traject.
@Peter
Dus niet alleen incrementeel, maar ook iteratief en constant lerend. Dat is hoe we het Evolutioneel zouden aanpakken. Dat is Agile, maar wel met duidelijke deadlines en weten om te gaan met verandering van de requirements, die nu eenmaal gaan optreden, zonder dat de deadlines worden veronachtzaamd. Het is allemaal zo voorspelbaar en wat er aan te doen is is ook al zo lang bekend.
Zoals Cobb in 1989 al zei: “We know why projects fail. We know how to prevent their failure. So why do they still fail?”
@Peter
Evo (Evolutionary) projecten zijn intensief, maar juist goedkoper met een beter resultaat.
Dit artikel (en jaarlijks vele anderen van gelijke strekking) vragen in duidelijke taal om een veel groter respect voor het vooraf definieren van de requirements.
Hoeveel wordt er op jaarbasis alleen al door onze overheid uitgegeven aan ICT-projecten waarvan zelfs na afloop (of stopzetten van het project zoals hier) nóg niet precies duidelijk is wát er nu eigenlijk gebouwd hád moeten worden…
Het is tegenwoordig al mogelijk om software-prototypes te genereren op basis van de volledige requirements! Ik hoop dan ook dat deze dure maar Middeleeuwse praktijken gauw tot een eind komen. Zie hier Kabinet Rutte I, uw eerste besparing is een feit.