Overheids-IT kan veel beter

Overheids-IT kan veel beter
Dat grote IT-projecten binnen de overheid veelvuldig falen is niet nieuw. Wel krijgen we de oorzaken van dat falen steeds beter in kaart. Analyse van een veelheid aan projecten in binnen en buitenland leert dat er wel degelijk handvatten zijn om de slaagkans van een IT-project realistisch in te schatten. Daarnaast is een permanente zakelijke rechtvaardiging van een IT-project in de uitrolfase een prima stuurmechanisme.
Hans en Theo Mulder
In de brief van 30 januari 2015 van minister Blok van Wonen en Rijksdienst aan de Tweede Kamer over het eindrapport van de tijdelijke commissie ICT-projecten wordt terecht een vergelijking getrokken met Operatie Comptabel Bestel uit de jaren tachtig. Die stond destijds onder leiding van Frans Kordes, directeur van de Algemene Rekenkamer en grondlegger van de automatisering bij de marine. Onder leiding van Kordes kwam er een bureau voor automatiseringsonderzoek en werd de Commissie voor de Rijksuitgaven warm gemaakt voor het idee dat er absoluut iets ingrijpends moest gebeuren. Besloten werd tot de zogenoemde Operatie Comptabel Bestel. Alle departementen moesten hun administratieve organisatie actualiseren en vervolgens ook volgens die regels gaan functioneren. Voor de hele operatie was vijf jaar uitgetrokken. Dat is niet helemaal gehaald, maar toen Kordes met pensioen ging was het voor elkaar. Minister Blok merkte terecht op in zijn brief: “Het kabinet ziet bij de oplossing van de IT-problematiek een analogie met de Operatie Comptabel Bestel, die halverwege de jaren tachtig was gericht op het vergroten van de beheersbaarheid en rechtmatigheid van de overheidsuitgaven. De Operatie Comptabel Bestel was een meerjarige en ingrijpende operatie die succesvol verliep door een strakke politieke regie. Die is nu evenzeer cruciaal. Het kabinet kan niet garanderen dat zich in de toekomst niet opnieuw problemen met IT-projecten voordoen.” Deze reactie benadrukt dat er geen eenvoudige en snelle remedies zijn, en dat de aanpak een enorme operatie betreft, hetgeen past in het beeld dat IT-falen een fundamenteel probleem is. Dat IT-falen een hardnekkig fenomeen betreft kunnen wij als auteurs uit ervaring met honderden mediations, bindende adviezen, arbitrages en deskundigenberichten voor rechtbanken, bevestigen. Saillant detail is dat we sinds 1989, onder het voorzitterschap van Frans Kordes, betrokken zijn geraakt bij het oplossingen van automatiseringsgeschillen in Nederland.
Internationaal perspectief
Hoogervorst1 schrijft: “Een schrale troost is dat IT-mislukkingen niet slechts bij de Nederlandse overheid aan de orde zijn, maar bij vele organisaties (bedrijven, instituties of gouvernementele instellingen) zichtbaar zijn. Dit falen is reeds jaren gaande. In 1996 verscheen John Kotter’s boek Leading Change . Daarin viel te lezen dat wereldwijd 70 procent van alle veranderingsinitiatieven die organisaties initiëren niet succesvol zijn: hetgeen werd beoogd, werd niet gerealiseerd. Erger nog, niet zelden zijn veranderingsinitiatieven contraproductief. Helaas is in dit opzicht sinds 1996 weinig veranderd. In 2011 publiceren Keller en Price2 een internationaal onderzoek over deze malaise, en schrijven: Fifteen years later, we can choose from more than 25,000 books on organizational change, and hundreds of courses of how to lead and manage it. In spite of this abundance of advice, all available research suggests that – you guessed it – still only one in three programs succeeds ”.
Vanuit de Standish Group in Boston wordt al jaren geconstateerd dat het falen van grote IT-projecten een wereldwijd en fundamenteel probleem betreft, dat niet alleen overheden treft, maar ook andere sectoren. In figuur 1 worden de gemiddelde percentages van succesvolle, problematische en gefaalde IT-projecten aangegeven voor de verschillende sectoren.
Figuur 1. Aandeel (niet) geslaagde IT-overheidsprojecten per sector
 
‘Succesvolle projecten’ zijn naar tevredenheid afgerond volgens planning en budget. ‘Problematische projecten’ zijn te laat, hebben meer gekost dan gebudgetteerd en/of hebben systemen opgeleverd met onvoldoende functionaliteit of kwaliteit. ‘Mislukte projecten’ zijn voortijdig gestopt  en/of de systemen zijn niet in gebruik genomen. Van belang is te nuanceren dat de toegevoegde waarde van IT voor de organisatie voorop moet staan en dus niet projectsuccessen of -mislukkingen in termen van overeengekomen functionaliteit binnen de geschatte kosten en tijd. Immers een succesvol project conform deze criteria, voegt niet per se waarde toe aan een organisatie. Het omgekeerde kan trouwens ook het geval zijn. Een tweede nuancering bij de analyse van deze percentages is dat dit een gemiddelde betreft van alle grote en kleine IT-projecten. Uit dit overzicht zou kunnen worden afgeleid dat overheden het gemiddeld minder goed doen dan andere sectoren, maar daarbij moet dan wel in beschouwing worden genomen dat de overheid door het recht op sociale inclusiviteit – bijna per definitie – in verhouding tot andere sectoren grote IT-projecten moet uitvoeren om alle rechthebbenden met IT te ondersteunen. Een voorbeeld hiervan is dat alle Nederlanders en inwoners recht hebben op een bepaalde dienstverlening, bijvoorbeeld het verkrijgen van een paspoort, zodat per definitie sprake is van een groot IT-project. Ten onrechte bestaat dus het idee dat het altijd slecht afloopt met de automatisering in het bedrijfsleven en bij de overheid. Deze opvatting leidt regelmatig tot ongenuanceerde uitspraken als: “Bijna alle IT-projecten mislukken”. De oorzaak van de verkeerde beeldvorming is mede dat auteurs vaak volstaan met louter de gemiddelde resultaten te citeren. De Nederlandse schrijver Godfried Bomans zei in dit verband ooit: “Een statisticus waadde vol vertrouwen door een rivier die gemiddeld één meter diep was. Hij verdronk.”
 
Database
De recente resultaten uit de Standish-database3 tonen de verschillen tussen grote en kleine IT-projecten bij overheden (figuur 2) . Bij analyse van de mislukte projecten ziet de Standish Group dat samenwerking tussen mensen de voornaamste oorzaak is dat projecten slagen dan wel falen en te weinig waarde realiseren voor de overheid en haar burgers.
Figuur 2. Verschillen tussen welslagen grote en kleine IT-overheidsprojecten
 
Dat “mensen, mensen, en mensen” de voornaamste oorzaak zijn dat projecten slagen dan wel falen vraagt om een nuancering gedaan door Deming (voormalig Amerikaans statisticus, red.) die stelt dat 96 procent van de ‘fouten’ veroorzaakt wordt door de wijze waarop de organisatie is ingericht. Internationaal onderzoek laat zien dat slechts de helft van de IT-projecten enige waarde toevoegen aan de organisatie (figuur 3) .
Figuur 3. Toegevoegde waarde van grote IT-overheidsprojecten
 
Deze constatering sluit aan bij de eerdere opmerking van Hoogervorst, die stelt dat “het mislukken van strategische IT-initiatieven niet het onvermijdelijke gevolg van inherente IT-complexiteit is, maar het vermijdbare gevolg van de tot mislukkingen leidende wijze waarop strategische initiatieven worden ‘bestuurd’.” Immers als het IT-systeem de gedefinieerde functionaliteit levert, maar de verwachte toegevoegde waarde (hogere klanttevredenheid, lager ziekteverzuim, minder administratieve lasten, et cetera) blijkt niet gerealiseerd te worden, moet dan het IT-systeem iets verweten worden? Natuurlijk niet. Het IT-project is succesvol. Het strategisch initiatief of het organisatorisch ontwerp niet. Dat is uiteraard iets anders dan het succes of falen van IT-projecten.
Internationale oplossingen
De commissie-Elias heeft uitgebreid en goed onderzoek gedaan en zich in haar aanbevelingen (de BIT-regels) veelvuldig laten inspireren door ervaringen en oplossingen uit het buitenland, waaronder het Verenigd Koninkrijk en de VS. Expliciet wordt in het rapport van Elias verwezen naar de Raines Rules . Dit zijn acht eenvoudige criteria waar IT-investeringen aan moeten voldoen om goedkeuring te krijgen van de president van de VS. Deze regels zijn opgesteld door Franklin D. Raines, die directeur was van het Office of Management and Budget tijdens het kabinet van Bill Clinton.
De Raines Rules adviseren te kijken naar alternatieven bij andere (overheids)organisaties die het proces kunnen vereenvoudigen en efficiënt kunnen ondersteunen, met speciale aandacht voor gebruik van bestaande oplossingen. De toevoegde waarde van de IT-investering moet volgens de Raines Rules meer opleveren dan een alternatieve inzet van publieke middelen. Het rendement moet rekening houden met de complexiteit van het project, de managementcapaciteiten van de opdrachtgever, de kans op kosten- en tijdoverschrijding, en het risico van onder-of non-performance. De IT-oplossing moet passen in de ontwikkelde architecturen, volledig getest worden alvorens in productie te gaan, en een aankoopstrategie volgen die betaling aan behaalde resultaten koppelt. Het IT-project moet opgedeeld worden in zo klein mogelijke deeloplossingen die elk aantoonbaar een eigen rendement hebben onafhankelijk van de nog te realiseren gedeeltes. Vooraf moet worden bepaald wat dit succes betekent, dat meten, en verantwoorden met een vroege betrokkenheid van gebruikers.
Voorwaarden
Om dergelijke zinvolle aanbevelingen te kunnen opvolgen is het van belang om de kansen op kosten- en tijdoverschrijding en het risico van onder- of non-performance goed in te schatten. Het gebruikmaken van eerdere IT-projectervaringen, zoals beschikbaar in de IT-projectendatabase van Standish, en het uitvoeren van pilots met betrokken stakeholders zijn daarvoor noodzakelijke voorwaarden. Immers het al dan niet realiseren van toegevoegde waarde is lastig vooraf te voorspellen via rendementsberekeningen. Werkelijk productieve en/of innovatieve toepassingen laten zich niet eenvoudig in een ROI vatten. Henry Mintzberg heeft in zijn boek The Rise and Fall of Strategic Planning laten zien dat structuren als ‘office of management and budget’ de oorza ken van strategisch falen niet oplost. Dit is ook wel begrijpelijk, want falen is niet een ‘budgetprobleem’. Als dat zo was konden de accountants IT-falen voorkomen. Zij bieden inzicht om het IT-project tijdig bij te sturen of te beëindigen om onnodige kosten als gevolg van doormodderen te vermijden.
Het vooraf definiëren en tijdens het project opvolgen en bijstellen van, wat de commissieElias in goed Nederlands noemt, de zakelijke rechtvaardiging (ook wel businesscase genoemd) is dus een noodzakelijke voorwaarde. Echter, bij een businesscase denken we vaak aan het document dat nodig is voor een projectaanvraag met gedegen argumentatie van kosten, doorlooptijd en deliverables. Dat klinkt heel gedegen, maar toch ontbreekt vaak een essentieel onderdeel. Iets dat in de praktijk heel moeilijk vooraf te bepalen is: de toegevoegde waarde die een en ander gaat leveren. Want uit recent onderzoek van dr. Kim Maes aan de Universiteit Antwerpen blijkt dat businesscases in de praktijk niet of nauwelijks worden bijgewerkt gedurende het project. Evenmin worden ze tijdens het project of achteraf geëvalueerd om toekomstige projecten meerwaarde te laten creëren. Kortom, businesscases worden niet of nauwelijks op strategisch niveau gebruikt. En dat is een gemiste kans omdat juist door strategisch gebruik waardecreatie tot stand komt.
 
Zakelijke rechtvaardiging
De toepassing van businesscasemanagement, waarbij management staat voor het continu sturen op de zakelijke rechtvaardiging en de elektronische ondersteuning van het besluitvormings-proces, draagt bij aan waardecreatie.4
Businesscasemanagement omvat de volgende drie aspecten:
• De projectcyclus (initiatie – ontwikkeling – implementatie – realisatie) is verder uitgebreid met een baten-realisatiefase na oplevering.
• Focus op waardecreatie naast kosten, door-looptijd en kwaliteitsbeheersing. In het definiëren van projecten worden vaak de ‘triple constraints’ gehanteerd. Alleen levert een project dat binnen de begrote kosten en tijd wordt uitgevoerd niet per definitie een toegevoegde waarde voor de organisa tie. Een hogere koppeling aan de organisatiedoelstellingen is voorwaarde voor echte waardecreatie.
• Belangrijke stakeholders betrekken in een gedeelde besluitvorming en ondersteuning daarvan met een database-gestuurde ‘group support’-systeem, zodat verschillen in de besluitvorming zichtbaar en gedeeld worden. Deze zichtbare en transparante wijze van ‘consensus building’ op basis van een ‘collectief gedeeld geheugen’ over projectresultaten ondersteunt de besluitvorming in de projectcyclus.
In businesscasemanagement worden alle investeringsprojecten op een gedisciplineerde en uniforme wijze aangepakt. Alles start met een high-level businesscase, waarbij de initiator van het idee op één A4 de algemene visie en doelstellingen van het project beschrijft. Deze businesscase wordt dan verder uitgewerkt tot een gedetailleerde beschrijving van de gekozen oplossing, en de hiermee gepaard gaande kosten, baten en risico’s. Een gefaseerde aanpak voor de ontwikkeling van een businesscase is belangrijk om de nodige volwassenheid van het initiële idee te toetsen, de vereiste analyses uit te voeren, en om belangrijke stakeholders voldoende te betrekken. De businesscase wordt tijdens de implementatie regelmatig bijgewerkt, zodat het nog synchroon loopt met de projectuitvoering en de contextuele omstandigheden die een impact kunnen hebben op het project. Ook na oplevering van het project wordt de businesscase gebruikt om het proces van batenrealisatie verder te ondersteunen. Ook worden op portfolioniveau waardevolle lessen getrokken uit gefinaliseerde projecten, die actief in nieuwe projecten worden gebruikt. Deze vernieuwde en procesmatige businesscase-aanpak vereist een eenduidiger focus op batenrealisatie.
Specifieke eigenaars van individuele (of een groep van) baten zijn verantwoordelijk voor hun realisatie. De projectcyclus (initiatie – ontwikkeling – implementatie – realisatie) is immers uitgebreid met een batenrealisatiefase in de exploitatie, dus loopt door na de oplevering van het project. De elektronische ondersteuning door een database-gestuurde ‘group support’-systeem helpt de stakeholders in hun besluitvorming in estafette-vorm. De kennis wordt via het ‘group support’-systeem gedeeld en waar de deelnemers aan de ‘group support’-sessies mogelijkheden zien tot samenhang of overlap tussen projecten, kan dit leiden tot het samenvoegen van projectvoorstellen, wat zowel kostenbesparing als waardecreatie bevordert. De doorlopende ondersteuning van een ‘group support’-systeem maakt businesscasemanagement inzichtelijk en transparant voor de stakeholders die participeren in de besluitvorming. Bovendien kunnen op een effectieve en efficiënte wijze veel meer (kandidaat-)projecten worden gedeeld dan op de traditionele ‘papieren’ manier.
Van belang is op te merken dat de genoemde begrippen als ‘zakelijke rechtvaardiging’, ‘aantonen’, ‘meerwaarde’ en ‘haalbaarheid’ kennis veronderstellen die er niet van zelfsprekend of slechts in zeer beperkte mate is. Om deze kennis te verkrijgen dienen studies, pilots en leerexperimenten te worden uitgevoerd, waarmee op emergente wijze wordt ontdekt of het strategisch initiatief zinvol blijkt te zijn. Dat is wat een governance-competentie (met alles wat daarbij hoort) beoogt te doen. Dit organisatieontwerpperspectief is de achtergrond van de notie van ‘doorlopende zakelijke rechtvaardiging’. Het is dus niet louter een financieel-economisch perspectief dat wordt gehanteerd in de term ‘businesscasemanagement’. Deze gedachte van een organisatieontwerpperspectief, tot slot, sluit aan op de ingezonden brief van prof. Jan Dietz aan de commissie-Elias: “De onderwerpen die over het voetlicht zijn gekomen in de verhoren die de commissie heeft gehad met ICT-deskundigen en met vertegenwoordigers van de overheid, kunnen in twee groepen worden verdeeld: inhoudelijk en projectmatig. Met ‘inhoudelijk’ bedoel ik alles wat te maken heeft met het begrijpen van ICT en van de potenties en beperkingen van die technologie om, zoals het in uw opdracht staat verwoord, ‘de informatieprocessen en –stromen bij ICT(-projecten) van de overheid optimaal in te richten’. Ten aanzien van deze inhoudelijkheid geldt een nieuw paradigma. Alleen vanuit een adequaat en diepgaand begrip van de constructie en de werking van een organisatie kan men effectieve informatiesystemen voor de mensen ontwerpen.”
 
KADER: Standish Database
De Standish Group in de VS is een researchbureau gespecialiseerd in onderzoek naar resultaten van IT-projecten. Sinds 1994 publiceert zij om de twee jaar een marktstudie – een zogenoemde CHAOS Report – over de stand van zaken op IT-gebied. De database bevat inmiddels tachtigduizend afgesloten of afgebroken projecten. Uit de database worden de vijftigduizend meest actuele projecten gebruikt voor analyses en rapportages. De codering van de projecten in de database vindt plaats op basis van schriftelijke enquêtes onder opdrachtgevers en -nemers van IT-projecten, zoals CIO’s, aangevuld met persoonlijke interviews door Standishmedewerkers. Van de projecten wordt een groot aantal kenmerken vastgelegd die een beeld geven van het project, het te ontwikkelen en te implementeren systeem, en van de onderneming. Ook wordt geregistreerd wat naar het oordeel van de respondent de belangrijkste oorzaken waren van het slagen of falen van het project. De projecten vonden voor 60 procent plaats in de VS en werden uitgevoerd in grote organisaties (50 procent), middelgrote ondernemingen (30 procent) en kleine ondernemingen (20 procent).
 

KADER: De BIT-regels

1. Stel een zakelijke rechtvaardiging op waar alle belangrijke onderdelen om een besluit gedegen te kunnen nemen in voorkomen. 


2. Toon de meerwaarde van het project aan voor de eindgebruiker en de samenleving. 


3. Zorg voor draagvlak bij alle betrokken partijen, inclusief de eindgebruikers, en toets op organisatorische, bestuurlijke en technische haalbaarheid.

4. Reorganiseer en standaardiseer eerst de werkprocessen die met IT worden ondersteund en ga pas daarna automatiseren.

5. Breng de technische, organisatorische en bestuurlijke risico’s en risicomaatregelen in kaart en elimineer «doormodderen» op voorhand.

6. Zorg ervoor dat de verantwoordelijkheid voor het budget én de opdracht bij één persoon liggen.

7. Faseer de ontwikkeling van het IT-project zo efficiënt mogelijk en probeer daarbij per fase direct bruikbare producten op te leveren.

8. Sluit aan op de standaarden bij de rijksoverheid en toon de technische haalbaarheid aan.

9. Toon aan hoe er van het begin tot het einde van een project voor gezorgd wordt dat kritiek en tegengeluiden mogelijk zijn en ter harte genomen worden. Openheid en transparantie zijn hierbij het uitgangspunt.

10. Neem een heldere aanbestedingsstrategie op in de zakelijke rechtvaardiging.

Prof. dr. Hans Mulder (hans.mulder@viagroep.nl) is professor aan de Universiteit Antwerpen en als gastdocent verbonden aan de Politieacademie. Daarnaast is hij oprichter van de Venture Informatisering Adviesgroep en vervult hij diverse rollen op het terrein van mediation en geschillenbeslechting. Hij is tevens European Research Director van de Standish Group en één van de experts die door de commissie-Elias is gehoord.
Prof. Theo Mulder (theo.mulder@inventive.nl) stond aan de wieg van het niet bekostigd ICT-onderwijs in Nederland. Hij is de oprichter van de firma Multihouse, en bekleedde daarnaast een groot aantal rollen in de Nederlandse IT-wereld.
 

[1] ingezonden brief  van prof.dr. Hoogervorst van 19 mei 2014 aan de Tweede Kamer en het artikel “Strategische mislukkingen rond IT” in HMR 156, 2014.

[2] Keller, S., Price, C., Beyond Performance, Wiley 2011, p. xix.

[3] Rethinking the Public Spending on IT projects, www.standishgroup.com/sample_research_files/Haze4.pdf  Standish Group, Jim Johnson, Hans Mulder & Ilias Kontakos

[4] www.ictmagazine.nl/strategie/strategisch-gebruik-van-business-cases-bij-achmea/ , Maes, Van Capelleveen & Mulder, 2015

 

 

 

 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag