Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

ICT-projecten overheid blijven zorgenkind

Aanbevelingen Algemene Rekenkamer zijn te vrijblijvend

 

Het lukt de overheid maar niet om een aantal opgezette ict-projecten tot een goed einde te brengen. De Algemene Rekenkamer doet verwoedde pogingen de problemen boven tafel te krijgen en oplossingen te bieden om verdere escalatie van deze problemen het hoofd te bieden. Dr. Ir. Denis Verhoef vindt dit een nobel streven, maar de voorgestelde maatregelen zijn in zijn ogen te algemeen en te vrijblijvend.

Op 18 maart en 1 juli werden respectievelijk deel A en deel B gepresenteerd van ‘Lessen uit ICT-projecten bij de overheid'. Beide delen van de rapportage van de Algemene Rekenkamer zijn opgesteld in opdracht van de Tweede Kamer. Ze zijn een reactie op twee artikelen van V. Dekker, vorig jaar in het dagblad Trouw, met de alarmerende koppen ‘Automatisering slokt miljarden euro's op' en ‘Automatiseringsramp lijkt onvermijdelijk'. In deze artikelen wordt onderbouwd dat de Nederlandse overheid jaarlijks vier miljard tot vijf miljard euro uitgeeft aan geheel of gedeeltelijk mislukte ict-projecten.

De stroom mislukkingen houdt sinds de publicatie van deel B nog steeds aan. Neem de uitkering van toeslagen door de Belastingdienst waarbij mensen door automatiserings¬problemen geen, of juist te veel geld ontvangen. Of het mislukte WIA-project bij het UWV, waar afgelopen juni de stekker uit werd getrokken en dat Computable op de voet volgt. Dit laatste project is goed voor een schadepost van naar schatting 87 miljoen euro. Tijd dus voor een kritische beschouwing.

Analyse siert Rekenkamer

In de analyse van de Rekenkamer komen de volgende acht oorzaken aan bod voor mis¬lukkingen.
- De beslissers in het politieke veld geloven in ict als ware het een wondermiddel voor het oplossen van allerlei beleidsvraagstukken maar hebben vaak onvoldoende zicht op de mogelijkheden van ICT.
- Deadlines worden vaak niet vastgesteld op basis van een onderbouwde en realistische planning, maar op basis van politieke overwegingen.
- Belangrijke wijzi¬gingen in eisen of randvoorwaarden zijn lang niet altijd aanleiding voor herbezinning op de uitgangspunten van het project.
- Vaak zijn ver¬schillende, autonome, organisaties bijictT-projecten betrokken waardoor centrale regie of doorzettingsmacht ontbreekt.
- Een grote impact op de it-infrastructuur gaat over het algemeen hand in hand met een organisatie¬verandering. Dat wordt bij het realiseren van politieke doelstellingen vaak over het hoofd gezien.
- Projectdoelen zijn vaak niet scherp gedefinieerd. Daardoor vormen externe ict-leveranciers zich een incompleet en mogelijk zelfs onjuist beeld van wat de opdrachtgever verwacht.
- ICT-systemen staan vaak niet op zichzelf maar moeten worden aangesloten op andere, bestaande, systemen. Hiermee wordt vaak geen rekening gehouden.
- De ontwikkelingen op het gebied van ict gaan razend snel.

Wat de analyse van de Rekenkamer siert is dat de hand in eigen - publieke - boezem wordt gestoken: er zijn weinig onvertogen woorden over het onvermogen of de onkunde van de (vaak externe) ict-leveranciers. De analyse is samen te vatten als: het ontbreekt de overheid aan professioneel opdrachtgeverschap in dezen.

Oorzaak nummer zes (Projectdoelen zijn vaak niet scherp gedefinieerd) springt er overigens met kop en schouders boven uit: dit is mogelijk de belangrijkste oorzaak voor mislukkingen. Geregeld worden, onder het mom van ‘deuren open houden voor voortschrijdend inzicht', doelen en resultaten onvoldoende helder geformuleerd. Wanneer een opdrachtgever echter niet precies zegt wat hij wil, moet hij ook niet verbaasd opkijken als hij niet krijgt wat hij wil.

Aanbevelingen te algemeen

De intrigerende vraag is vervolgens: wat nu te doen? Hoe krijgt de opdracht¬gever grip op complexe ict-projecten? En hier zijn de aanbevelingen dan wel erg algemeen van aard.

Samengevat raadt de Rekenkamer in deel A van haar rapportage aan over voldoende kennis en expertise van ict te beschikken, om besluitvorming te faseren, om besluiten alleen met onderbouwing te nemen (nota bene!) en om herbezinning op de uitgangspunten van een project uit de taboesfeer te halen. In deel B wordt ook geadviseerd om bewuste keuzes in kostensoorten te maken, kosten te ramen op basis van ict-projecten met een helder gedefinieerd start- en eindpunt, kostenrapportages te controleren, portfolio¬beheer in te richten en, last but not least, leren te stimuleren.

Dit zijn aanbevelingen waar niemand nee tegen zegt. Wie wil er niet leren?

Aanvullende aanbevelingen

De Rekenkamer richt zich sterk op de kosten, nauwelijks op de baten en risico's. Daarnaast gaat ze nauwelijks in op inhoudelijke strategiebepaling. In mijn ervaring zijn juist ook op deze terreinen aanbevelingen nodig om grote ict-projecten te laten slagen. Deze richten zich op de vragen: hoe kan een opdrachtgever sturen op baten en risico's, in plaats van (alleen) op kosten en hoe dient een opdrachtgever een passende strategie te kiezen voor aanbesteding en uitvoering van zijn project?, met de nadruk op ‘passende'.) Hier volgen aanbevelingen bij deze beide vragen.

Sturen op baten en risico's

Sturen op kosten is nodig, maar -in zekere zin- makkelijk. Elke maand weer is er een factuur die laat zien welke kosten er gemoeid zijn gegaan met de uitgevoerde werkzaamheden. ‘Ook deze maand hebben we twee miljoen uitgegeven.' Ja, maar wat kwam er voor terug?

Sturen op baten is vele malen lastiger. Wat is er bereikt als de ontwerpfase vier maanden oud is, als tien procent van het systeem gerealiseerd is? De prachtige quote ‘Mag ik één liter software?' zegt het precies. Het ontbreekt aan heldere, toegankelijke maat¬staven. De enige maatstaf die geregeld gehanteerd wordt - de Rekenkamer verwijst hiernaar overigens wél - zijn de zogenaamde functiepunten; deze maatstaf zegt iets over de omvang van een ict-systeem en is louter kwantita¬tief van aard.

Wie gaandeweg een project al wil sturen op (de totstandkoming van) baten is geholpen bij een fasering van de te bereiken resultaten. In de huidige ict-praktijk bepalen vaak alleen logische afhankelijkheden de fasering: eerst het systeemontwerp, dan de bouw en test en ten slotte de implementatie. Laat ook risico's de fasering bepalen. Worden hoge eisen gesteld aan de beveiliging van het systeem (de betrouwbaarheid, de performance, ...), dan is er altijd wel een deelsysteem aan te wijzen waar deze eisen zich in het bij¬zonder manifesteren. Ontwerp en bouw dat deel dan eerst!

Met een goed gunningsmodel kan een opdrachtgever de markt sturen. Wanneer leveranciers tachtig procent van de score voor hun offerte kunnen verdienen met de afgegeven prijs, leidt dit onherroepelijk tot andere offertes dan wanneer ze dit kunnen verdienen met de kwaliteit van hun dienstverlening. Risico's zijn hier een goede, en vaak vergeten, aanvullende inspiratiebron. De offertes van leveranciers worden meer op prijs en kwaliteit gewaar¬deerd dan op risico's. Laat de markt meedenken over hoe die kritieke deadline gehaald kan worden, over hoe draagvlak bereikt kan worden! Maak van je kritieke risico's je sterkte! Bijgaand kader is een illustratief voorbeeld.

Kies passende strategie

Grote ict-projecten zijn spannend en uniek: ieder project vraagt een maatwerk¬benadering. Het ontwerp daarvan is een vak apart. Hier komt de opdrachtgever voor een aantal specifieke keuzen te staan, bijvoorbeeld:
- Welke leveranciersstrategie hanteren we? Een single-vendor- of een multi-vendor-strategie?
- Welke ontwerpaanpak kiezen we? Een met veel gebruikersparticipatie, of een waar analisten en ontwerpers het voor¬touw nemen?
- Hoe faseren we de bouw van het nieuwe informatiesysteem? Komt het systeem in een aantal versies tot stand? Worden opvolgende deel¬systemen opgeleverd? Of hanteren we een zo genaamde big bang-aanpak: het systeem wordt in een keer opgeleverd?

Bij ict-projecten zijn dit lastige keuzen, omdat ‘het beste' antwoord niet bestaat. Neem nu het voorbeeld van de ontwerpaanpak. Bij sommige pro¬jecten is draagvlak bij de eindgebruikers van groot belang, of inbreng van specifieke materiedeskundigheid. Bij zulke projecten is gebruikersparticipatie van harte aan te raden. Andere projecten hebben te kampen met een grote tijdsdruk. Bij zulke projecten is het aan te raden niet te veel praters aan tafel te hebben. Dat kost alleen maar kostbare tijd. Hier weinig gebruikers¬participatie graag.

Gelukkig zijn - in Europees verband - veel van dit soort strategische keuzen in ict-projecten op een rij gezet, en voorzien van vuistregels om van geval tot geval tot een passend antwoord te komen. Deze vuistregels zijn vaak geënt op het risicoprofiel van ict-projecten. Iedere opdrachtgever ziet graag dat de meest kritieke risico's van zijn project bepalend zijn voor de te nemen strategische keuzen! Dit soort vuistregels wordt echter te weinig toegepast.

Ontwerp is het belangrijkst

Het ontwerp van een gunningsmodel en van een strategie zijn bepalende succes¬factoren voor grote ict-projecten. Het gaat om het ontwerp ervan: het is per project anders. Dit is een vak op zich. De ontwerpvragen vergen niet alleen ict-expertise maar ook bestuurlijk inzicht.

Dr.ir. Denis Verhoef,
voorzitter Information Services Procurement Group (ISPG)
managementadviseur Kirkman Company

Maak van je kritieke risico's je sterkte

Illustratief en elegant is het voorbeeld - overigens afkomstig uit de publieke sector binnen een der Europese lidstaten - waarbij een risico-analyse uitwees dat de deadline van het project, zeg 15 januari 2002, gezien moest worden als het meest kritieke risico. Zou de leverancier het systeem één dag te laat opleveren, dan zou de opdrachtgever één jaar aan data niet kunnen verwerken. Ofwel: een dag uitstel was een jaar uitstel.

Het gunningsmodel werd in dit voorbeeld zo ingericht dat leveranciers veertig procent van de score voor hun offerte konden verdienen met hun afgegeven deadline (in totaal waren er honderd punten te verdienen). En dit leek een simpel model te zijn: voor iedere maand die leveranciers bereid waren het systeem eerder op te leveren dan de kritieke deadline, kregen ze tien punten, met dus een maximum van vier maanden. Dit gunningsmodel leek, in eerste aanleg, de kat op het spek te binden. Opportunistische leveranciers leken eenvoudigweg een deadline van 15 september 2001 te kunnen afgeven en daarmee al veertig punten binnen te hebben.

Maar hier had de opdrachtgever een fraaie spanningsboog ingebouwd. Welke deadline een leverancier ook afgaf (tussen 15 september en 15 januari), indien de leverancier het systeem één dag later zou opleveren dan de door hemzelf afgegeven deadline, dan stond hem een penalty van vijf miljoen euro te wachten. Een fors bedrag, overigens wel proportioneel in relatie tot de totale opdrachtsom.

Hier deed de marktwerking vervolgens zijn werk. De uitgebrachte offertes koersten, gemiddeld genomen, op oplevering in de tweede helft van november. Geen enkele leveran¬cier bood de verleidelijke 15 september aan. En alle leveranciers hadden veel energie gestoken in kritieke-pad-analyses, in het vrijhouden van de beste mensen, in opleidingen, in vangnetten, kortom: alle leveranciers hadden zich beijverd om het meest kritieke risico van de opdrachtgever te helpen beteugelen. Ze kregen de opdracht graag gegund, maar niet ten koste van vijf miljoen Euro. Dat is professioneel opdrachtgeverschap!

Het ontwerp van een gunningsmodel bij een grote Europese aanbesteding bleek een succes¬factor van formaat.

Over de auteur

Dr.ir. Denis Verhoef is voorzitter van de Information Services Procurement Group (ISPG) en managementadviseur bij Kirkman Company. In de afgelopen jaren was hij betrokken bij verschillende ict-uitbestedingen in de publieke sector. Hij beoogt met dit artikel bij te dragen aan een spannende zoektocht die de Rekenkamer heeft ingezet: hoe kan de overheid grote, lastige, dure ICT-projecten laten slagen? Reacties zijn welkom.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/2758941). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


 

Reacties

Beste Denis,

Een mooi moment om de bevindingen in dit artikel 'ICT-projecten bij de overheid blijven zorgenkind' te linken aan de bevindingen in het artikel 'Projectmanagement schiet te kort' op ManagementSite:
http://www.managementsite.nl/673/ICT-internet-Projectmanagement-schiet-vaak-te-kort.aspx

Tekortkomingen en oplossingsalternatieven beschreven in het artikel op ManagementSite zijn een mooie aanvulling op de alinea 'Kies een passende strategie' in het artikel hierboven.

Een belangrijke conclusie die wordt getrokken in het artikel op ManagementSite is dat projectleiders (vaak de grote kartrekkers)de verkeerde opleiding en training krijgen die te eenzijdig is gericht op techniek en instrumenten (planning, tijdlijnen en deliverables).

Vriendelijke groeten,
Leon Dohmen

Beste Denis,

Ik lees in het rapport onder de "Bijlage 1 Overzicht van
conclusies, aanbevelingen en reactie minister " ook over fouten in de besluitvorming die ik niet in jouw stuk terug kon vinden.

Bijvoorbeeld:
Projecten gaan vaak te snel van start zonder goede
onderbouwing. Er wordt niet de tijd genomen om te
onderzoeken of het project realistisch is.

Vaak worden belangrijke beslissingen in een project
genomen op basis van onvoldoende of onvolledige
onderbouwing.

De link naar het orginele rapport is:
http://www.rekenkamer.nl/9282000/d/p425_rapport1.pdf





Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×