Al in 2006 had de Inspectie Werk en Inkomen zijn twijfels over de implementatie van het Wia-project dat uiteindelijk werd stilgelegd. Het tijdspad was vanaf het begin kritiek en er waren twijfels over de efficiëntie en onzekerheden.
De Inspectie Werk en Inkomen had al in december 2006 twijfels over de bouw van het ict-systeem van de Wia, de opvolger van uitkeringswet WAO. Het platform, dat automatiseerder Logica probeerde te bouwen, werd uiteindelijk afgelopen juni definitief stilgelegd door uitkeringsinstantie UWV.
De inspectie, belast met het toezicht op de uitvoering van arbeids- en inkomstenwetgeving, constateerde in zijn rapportage van 22 december 2006 dat de bouw ‘op het uiterste moment' van start ging. Aangezien met de politiek de opleverdeadline van 1 januari 2008 was afgesproken, was vanaf het begin geen enkele speling in de planning mogelijk. "Er was sprake van een kritiek tijdspad waar UWV al direct op zat", vertelt communicatiemanager Michiel Hoorweg van de inspectie. De deadline werd uiteindelijk niet gehaald.
"Bovendien", vertelt Hoorweg, "waren er bij ons twijfels of de geplande investeringen konden worden terugverdiend. Het plan was zeer ambitieus." Al in zijn rapport van december 2006 waarschuwde de inspectie dat het project diverse risico's en onzekerheden kende. Het zou daarbij onder meer gaan om de koppeling met de polisadministratie en aanpassingen in de organisatie, waardoor deze meer functiegericht dan wetgericht zou moeten werken.
Onder de loep
Namens het ministerie van Sociale Zaken en Werkgelegenheid beoordeelde de Inspectie Werk en Inkomen de onderzoeken die uitkeringsinstantie UWV deed naar de voortgang van de inmiddels stilgelegde implementatie van het Wia-systeem. Ook het onderzoek dat UWV momenteel uitvoert naar het stopzetten van het systeem, neemt de inspectie onder de loep zodra het is verschenen.
Hoorweg verwacht de tussenrapportage van UWV eind augustus en het eindrapport in november. "De inspectie bekijkt of het onderzoek van UWV volledig inzicht geeft in de kosten van het project en of de problemen en oorzaken voldoende zijn geanalyseerd", vertelt Hoorweg. "We doen dat op basis van de stukken die UWV oplevert en zo nodig met aanvullend onderzoek."
Voor de Inspectie Werk en Inkomen is de administratieve en technische implementatie van de Wia-regeling overigens niet het enige ict-project dat wordt gevolgd. Zo volgen de ambtenaren volgens Hoorweg onder meer het verbeteringstraject bij de Sociale Verzekeringsbank (SVB), dat een grote ict-component kent, de invoering van Walvis (Wet administratieve lastenverlichting en vereenvoudiging in sociale verzekeringswetten) en ontwikkeling van een digitaal klantdossier voor de sociale zekerheid.
Geschiedenis
Het Wia-project, waarbij automatiseerder Logica ruim 2,5 jaar bouwde aan een ict-systeem dat de opvolger van de WAO in goede banen moest leiden, werd half juni definitief stilgelegd. De kosten bedroegen inmiddels 87 miljoen euro.
Minister Donner van Sociale Zaken schreef op 17 juni in een brief aan de Tweede Kamer dat doorgaan met het project ‘steeds hogere kosten met zich zou meebrengen, zonder dat het resultaat daarmee zou worden zeker gesteld'. De 'risicobeheersende maatregelen' hadden namelijk 'onvoldoende gewerkt' en het ambitieniveau lag volgens externe onderzoekers te hoog. Hierdoor werd het project 'te complex en technisch en financieel onbeheersbaar'.
Naar aanleiding van eerdere berichten in Computable over het mislukte Wia-project, weet de uitkeringsinstantie de problemen juist aan de vele wetswijzigingen waarmee de organisatie te maken kreeg. De door Computable gesproken ict'ers die bij het project betrokken waren, legden de schuld bij de niet-onafhankelijke projectaansturing, te krappe budgetten en het ontbreken van goede specificaties.
Overigens koos UWV in 2005 uit tijdsoverwegingen voor maatwerk in plaats van een standaardoplossing. De instantie hoopt reeds gebouwde onderdelen van het systeem te hergebruiken, om zo de financiële schade te beperken.
Mislukken in de ict is niet erg. Er niet van leren en dezelfde mantras tegen dezelfde mensen blijven preken wel. Als keer op keer taken onderschat, budgetten overschreden en deadlines niet gehaald worden, moeten we dan niet eens gaan denken aan het feit dat we gewoon met z’n allen een imcompetent zootje zijn. Of – en dat is misschien beter – niet worden afgerekend op onze competentie maar op onze compliance?
Alle methoden van SDM tot RUP en Agile, maken van competente mensen en medewerkers brave radertjes in een grote ontmenselijkte ict-machinerie. De ja-knik en schouderophaal cultuur in de ict is walgelijk en wordt door de management structuren gestimuleerd.
Vroeger werkte je over omdat je eergevoel zei dat je met je team resultaat wilde behalen. Tegenwoordig werk je over omdat de zoveelste onrealistische deadline niet wordt gehaald (wat je al vooraf had doorgegeven aan de projectleiding maar die had zich via Prince2 geconformeerd aan een projectplanning en kon of wilde daar niet van afwijken, no matter what).
Ik heb software verkocht zien worden aan klanten op basis van specificaties, zonder dat de marketing mensen ook maar het minste besef hadden wat die specificaties inhielden voor de ontwikkelafdeling. Ik heb projectleiders weggestuurd zien worden als kleine kinderen omdat ze de waarheid aan het management vertelden. Ik heb zelf een projectleider de laan uit moeten (laten) sturen omdat hij niet doorhad dat hij door zijn gedram het project alleen maar in gevaar bracht (veel externen is niet te veel zeuren anders alleen coderen namelijk). En ja, ik heb ook zelf het bijltje erbij neergegooid en niet omdat ik niet in de Iict-ers geloof die op de projecten zitten, maar omdat ik geloof dat de huidige methoden ze domweg niet in staat stellen om te excelleren. Dat moeten ze doen om de complexe processen die gemodelleerd, geanalyseerd en geprogrammeerd moeten worden, te begrijpen en dan vanuit begrip in code om te zetten.
En of de bedrijven nu Logica, Getronics Pink Roccade, Atos Origin of Cap Gemini heten, het maakt niet uit.
Laten we nou allemaal eens gaan nadenken over hoe we de professional terug kunnen krijgen in de ict. Hoe we de management laag kunnen ontdoen van managers die nog niet in staat zijn “Hello World” in BASIC te programmeren, maar wel in staat zijn een klant een miljoenen project door de strot te drukken. Hoe we weer naar de klanten kunnen gaan luisteren en de tijd kunnen krijgen om te doorgronden wat de klant wil, wat die kan willen (want daar zit een groot verschil in) en dan tot de kern van de zaak doordringen om die in code om te zetten.
Ikzelf heb met Ad Oskam (toen van DCE Europe) in 1990 mijn intrede in de ict gedaan met een klein dBase IV project. We hebben samen twaalf maanden onderzocht wat de klant (mijn toenmalige werkgever Riza) wilde en uiteindelijk hebben we (de analisten) besloten welke wensen we konden honoreren en welke niet (Pareto 80/20).
Dat leverde eerst scheve gezichten op bij de mensen die hun wensen niet gehonoreerd zagen, maar uiteindelijk wel tevreden gezichten toen het systeem deed wat wij hadden beloofd dat het zou doen. Programmeren was in twee maanden gedaan (door twee man) en testen was een week werk. Het is van dBase IV naar een Sun geporteerd en draait volgens mij nu nog.
Waarom? Omdat we met een klein team de tijd kregen om te denken. Omdat we onze opdracht duidelijk afschermden tegen de buitenwereld (nadat we wel via een prototype de wensen van die buitenwereld in kaart hadden gebracht). Ik denk dat we ons weer eens moeten bezinnen op de competentie die ik toen bij mensen als Ad Oskam aantrof. Die heb ik toen ik in 1998 – na een gat van zes jaar – terug kwam in de ict namelijk niet meer aangetroffen.
Ik kwam terug in een industrie waar enthousiasme was vervangen door lethargie, waar mensen van werkgever veranderden met als voorwaarde dat ze dan niet meer naar “dat” project gestuurd zouden worden, waar projectleiders worden afgerekend op het behalen van de deadlines (waarbij de kwaliteit van de opgeleverde code geen beoordelingsfactor is), waar testcoordinatoren die vragen hebben bij de kwaliteit van de software worden ontslagen omdat ze “het proces belemmeren”, waar een userinterface getest wordt, zonder dat de onderliggende backend fatsoenlijk functioneerd, waar analyses onder de analisten vandaan gerukt worden zonder dat deze klaar en gereviewd zijn onder het mom van RUP, waar code door CMM5 bedrijven wordt gegenereerd in India en per omgaande post retour komt.
Kortom heren en dames ict-ers, laten we nou maar gewoon toegeven dat we allemaal prutsers zijn, dat we nog steeds automatiseren als kleuters en als kippen zonder kop ons telkens weer aan die ene steen stoten en dus budgetoverschreiding op budgetoverschreiding, tijdsoverschreiding op tijdsoverschreiding en miskleun op miskleun plaatsen.
Maar laten dan ook de opdrachtgevers de boter van hun hoofd halen en erkennen dat ze ons telkens opnieuw, doordat ze zelf maar een gebrekkig idee hebben van wat ze nou eigenlijk willen en dat nog gebrekkiger in Nederlandse of Engelse volzinnen gieten, voor een onmogelijke opdracht stellen en als een bedrijf zo eerlijk is dat uit te leggen pendelen naar dat ene bedrijf dat dat nou net niet doet.
Is er dan geen oplossing? Ja die is er wel en dat is een holistische benadering van het probleem waarbij erkent wordt dat in software alles met alles verbonden is en dus ook elk component van het traject van de eerste business analyse tot de laatste ‘do untill’-loop de uiteindelijke kwaliteit van de software beinvloed. Dat het een creatief en inventief proces is waar problemen kunnen opduiken op onverwachte plekken. Waar dus tijd en budget altijd een probleem kunnen zijn. Waar meer mensen niet noodzakelijkerwijs wordt vertaald in kortere doorlooptijd maar wel noodzakelijkerwijs in hogere kosten. Waar ook een optimale teamgrote kan worden gedefinieerd. Waar analisten niet alleen met analisten, ontwikkelaars met ontwikkelaars en testers met tester praten, maar waar interdisciplinair wordt gedacht. Waarom zou een ontwikkelaar niet kunnen testen en waarom zou een tester niet kunnen analyseren? Waar management van proactief/repressief naar reactief/stimulerend gaat en waar kwaliteit weer de kans krijgt geleverd te worden.
Als een deadline dwingend wordt vastgelegd bepaal dan meteen welke functionaliteit je werkelijk nodig hebt en niet na vier jaar ontwikkelen zes maanden voor invoering. Concentreer je daar op, laat de franje de franje. Zorg ervoor dat je van elke regel code weet voor welke Business Requirement die bedoeld is, zodat als een requirement wijzigt, je met een druk op de knop kunt zien wat, waar, waarom en hoezo gewijzigd moet worden. Laat als ontwikkelaar een manager weten dat de duivel in de details verborgen zit en dat een project meestal niet stukloopt op zijn grote lijn, maar op jouw detail en dat jouw “detail” dus geen bijzaak maar een hoofdzaak is.
En bedenk vooral: ict is een toegepaste kunstvorm, mooie code is prachtig om te zien, schitterend om mee te werken en de mensen die erbij betrokken zijn een werkomgeving verdienen waarin ze kunnen schitteren.