De bouw van het belastingsysteem Tax-i voor de waterschappen liep al verkeerd vanaf dag één van de voorlopige gunning aan Logica. Te ambitieus, te complex en niet-realistisch. De evaluatiecommissie Taxi, dat het debacle door Twynstra Gudde liet onderzoeken, spreekt van een collectief falen van ict- en regie-organisatie Het Waterschapshuis, de waterschappen en automatiseerder Logica. Volgens het adviesbureau is het project mislukt door een combinatie van politieke, organisatorische en technische klassieke faalfactoren. Schadepost: 17,2 miljoen euro.
De evaluatiecommissie verwijst in de begeleidende brief aan het bestuur van de Unie van Waterschappen naar het rapport ‘Lessen uit ict-projecten bij de overheid’ van de Algemene Rekenkamer. Uit dit rapport blijkt dat de belangrijkste oorzaak voor het mislukken van ict-projecten bij de overheid ligt in een combinatie van politieke, organisatorische en technische factoren. Daardoor worden dergelijke projecten vaak te ambitieus en te complex en mislukken ze. Uit het onderzoek van Twynstra Gudde komt naar voren dat dergelijke ‘klassieke’ faalfactoren zich ook bij het project Taxi-i hebben voorgedaan.
Stekker eruit
In 2007 besloot het Waterschapshuis, de gezamenlijke ict-organisatie van de waterschappen, met Tax-i te starten. Logica werd als hoofdaannemer aangetrokken met Ordina en Oracle als partners. Het systeem, bestaande uit een centrale inning- en heffingtoepassing en een overheidsdatabase, kwam echter niet van de grond. In maart 2012 werd de stekker er definitief uitgetrokken. In het kader van de afbouw van Tax-i werden drie besluiten genomen: een schikking met Logica zodat een gang naar de rechter kon worden voorkomen, een verrekening van de intern gemaakte kosten en het opstellen van een evaluatie. Dit laatste punt is door Twynstra Gudde uitgevoerd.
Schadepost
Aan Tax-i zouden 24 van de 26 waterschappen meedoen. Het was begroot op 25 miljoen euro. Uiteindelijk leverde het stopzetten ervan een schadepost op van 17,2 miljoen euro: de werkzaamheden van Logica (6,6 miljoen), de projectkosten van het Waterschapshuis (4,4 miljoen) en de aangeschafte Oracle-licenties (6,2 miljoen voor een periode van vijf jaar). Deze kosten komen voor rekening van Het Waterschapshuis.
De evaluatie wordt vandaag besproken tijdens een algemene ledenvergadering van De Unie van Waterschappen.
Lees ook achtergrondverhaal Evaluatie Taxi-i: Collectief falen bij debacle
@Oskar Hendriks,
Ik begrijp je sentiment, echter je probeert je nu ook te verkopen als een “ik kan alles tegen de laagste kosten”-figuur die je eerder beschrijft als zojuist door Bart Nelissen genoemd. Je kunt alles, en dat allemaal op basis van een half verhaal. Kennelijk heb je ook inzicht in de samenstelling en de ervaring van zowel Logica (in de diverse verschijningsvormen) en de Cap Gemini’s.
Om vervolgens af te sluiten met een advies die in de afgelopen jaren juist bewezen heeft niet te werken: waterval. En als klap op de vuurpijl ook nog eens het ontwikkelteam (uitvoerende partij) ook nog eens geheel afsluit van de partij die de gebruikers vertegenwoordigt (en daarmee dus de enige lijn van praktijkkennis) door er een projectmanager tussen te zetten. Hiermee verhoog je alleen maar de ceremoniele praktijken om vragen te beantwoorden.
Even een schets van wat er gaat ontstaan (een ontwikkelaar heeft een vraag omtrend een stuk op te leveren functionaliteit):
1. Eerst een vergadering plannen met de regisseur om de vragen voor te leggen
2. Dan moet de regisseur een overleg plannen met de opdrachtgever om de vragen direct te beantwoorden
3. De opdrachtgever weet het ook niet en plant een overleg met de chef van de afdeling die de vraag zou moeten weten te beantwoorden
4. De vraag wordt doorgenomen en zo goed als mogelijk beantwoord
5. Het antwoord wordt aan de opdrachtgever gegeven
6. Het antwoord wordt aan de regisseur gegeven
7. Het antwoord wordt aan de ontwikkelaar gegeven….
Ken je het spelletje “chinese whispers” (of op z’n Nederlands telefoontje)? De kans is groot dat in de eerste stap de regisseur de vraag al verkeerd doorgeeft aan de opdrachtgever (de regisseur geeft al dan niet bewust er toch zijn/haar interpretatie aan) en dat gaat zo door.
Denk je echt dat dit beter gaat werken, en goedkoper?
In complexe en technisch innovatieve projecten is het juist de waterval-project benadering en de vele overlegschijven die hebben geleid tot grote overschrijdingen van budgetten en grote onschrijdingen van de benodigde functionaliteit. De praktijk heeft bewezen dat in dit soort grote ICT projecten het juist kostenbesparend werkt als je werkt volgens een Agile methode (zoals Hans Michiels ook aangeeft).
Let wel: Agile is geen Haarlemmer olie, er zijn projectvormen die juist wel met een meer waterval benadering moeten worden gedaan; in de ICT echter zal je veel meer projecten op een Agile manier moeten benaderen.
@Cpt. Hier leg je wel wat bloot, “chinese whispers”. Nu komt een groot probleem om de hoek kijken. Ik ken Cap met name in de hoedanigheid van leverancier van maatwerk. Ik heb ervaren als er iets niet helemaal duidelijk is, ik gewoon als ontwerper of ontwikkelaar naar de werkvloer van de klant ga met een vraag en ik direct het enige en juiste antwoord kreeg (getoetst). Dat mag een Capper niet want daar zit een heel circus Cappers omheen en er is contractueel vastgelegd wat er geleverd gaat worden en dat moet dan ook nog weer worden opengebroken. Daarnaast ontbreekt vaak bij de Cap programmeur/ontwerper de specifieke klant-/bedrijfskennis en weet niet eens dat er een probleem zou kunnen zijn. Verder wil het management van de klant grip kunnen houden op het project en wil dus precies weten en kunnen sturen op alle issues die boven komen. Zeker bij grote projecten kom je niet weg met alleen een telefoontje, daarmee haal je de sturende functie van het klantmanagement volledig onderuit. 1 wijziging zou gevolgen kunnen hebben voor een afdeling 5 processen verderop. De klant zelf heeft al moeite dat totaal overzicht te hebben/houden laat staan een aannemer, ongeachte vooropleiding en/of ervaring, wat wel helpt is specifieke branche kennis en ervaring. Het is mij opgevallen dat sales medewerkers van de detacheerders met nog tig klanten, vaak pretenderen (gesteund door hun management), klantkennis te hebben, en weten wat er bij de klant ‘allemaal’ speelt. Een enkele vak idioot van Cap die 60 uur per week met de klant bezig is (ook in het informele circuit), die weet het meest, maar heeft vaak onvoldoende tijd en vind geen gehoor bij zijn/haar officiele werkgever. En daar wringt alweer een schoen, de opdrachtgever/klant mag soms tegen een belachelijke vergoeding de werknemer overnemen, reden is niet de continuiteit maar het snelle geld van de aannemer, en dan hebben we nog de arbeidsvoorwaarden van de werknemer die vaak niet strookt, neem bijvoorbeeld het eeuwige gedoe over de auto van de zaak. De auto is gereedschap wat detacheringspersoneel nodig heeft en bij een dienstbetrekking bij een eindklant niet meer, maar ziet het gereedschap als verkapt inkomen, tot de bijtelling te sprake komt:-). Al met al veel complexe, specifieke en grijze gebieden, dus.