KWD reageert op “Lessen uit ICT-projecten bij de overheid" - Nieuws

De Algemene Rekenkamer heeft het tweede gedeelte van het rapport “Lessen uit ICT-projecten bij de overheid" gepubliceerd, naar aanleiding van de vierde en laatste vraag van de Tweede Kamer over ICT projecten bij de overheid. Het vakblad Computable vroeg Gerard Meijer van KWD Resultaatmanagement op de inhoud van dit rapport te reageren.

Inleiding

In deel B van het rapport “Lessen uit ICT-projecten bij de overheid" formuleert de Algemene Rekenkamer het antwoord op de vierde en laatste vraag van de Tweede Kamer. Deze vraag bestaat uit de volgende deelvragen:

• Hoe worden de doelmatigheid en de doeltreffendheid van de uitgaven voor ICT- projecten bijgehouden in de administraties?
• Welke indicatie kan de Algemene Rekenkamer geven van vermijdbare kosten en vermijdbare vertragingen?
• Welk beeld geeft dit van de mogelijkheden en beperkingen van een breed onderzoek naar de vermijdbare kosten en vermijdbare vertragingen voor ICT-projecten bij de rijksoverheid sinds 2000?

Naast een antwoord op elk van de deelvragen, schetst de Rekenkamer de complexiteit waarbinnen de niet altijd even helder afgebakende projecten hun gewenste en noodzakelijke resultaten moeten zien te bereiken.

Naar mijn overtuiging laat de Rekenkamer in het beantwoorden van de Tweede Kamervraag duidelijk een kans liggen. Zij beperkt zich vooral tot een algemene beschrijving van de problemen.  Achterliggende oorzaken krijgen veel minder aandacht in het rapport. Bovendien wordt in het verkrijgen van een conclusie te zwaar geleund op informatie uit administraties en het uniform zijn van de inhoud van die administraties. Vrijblijvende, algemene en onpersoonlijke oplossingen zijn hiervan het gevolg.

Mijn reactie bestaat uit 2 delen. Het eerste deel betreft een reactie op de aanbevelingen van de Rekenkamer. Het tweede deel bevat een aantal veel voorkomende oorzaken voor “mislukte” projecten. Pas als je de werkelijke oorzaken scherp op het netvlies hebt, ben je in staat echte verbeteracties te definiëren. Ook in die zin heeft de Rekenkamer mijn inziens een kans laten liggen.

Reactie op de aanbevelingen van de Rekenkamer

In deel B van het rapport komt de rekenkamer op hoofdlijnen tot de volgende constateringen en aanbevelingen:

1. Geen Rijksbreed onderzoek.
   De Rekenkamer ziet weinig toegevoegde waarde in een rijksbreed onderzoek omdat er onvoldoende betrouwbare informatie beschikbaar is. Het trekken van conclusies is inderdaad niet mogelijk als je niet beschikt over voldoende informatie. Ik ben van mening dat het ontbreken van deze informatie juist de aanleiding zou moeten zijn om wél breed empirisch onderzoek te starten naar de achterliggende oorzaken. Het doorploegen van administraties is daarbij niet genoeg.  Aanvullende informatie over omvang, kosten en kwaliteit kan ook op basis van anders verkregen gegevens worden verzameld. Bijvoorbeeld via interviews, enquêtes, expertoordelen en gesprekken met projectleiders. KWD heeft dit soort aanvullend onderzoek al vaker naar tevredenheid van onze opdrachtgevers uitgevoerd.
2. Kosten en kostensoorten [...], inclusief incalculeren van de verwachte levensduur van het systeem.
   Natuurlijk is het gestructureerd vastleggen van de uitgaven belangrijk. Je kunt er de onderlinge vergelijkbaarheid van ICT projecten mee verbeteren.  Het vaststellen van kosten en kostensoorten is op zichzelf ook snel te regelen. Dat is, volgens mij, niet het echte probleem. De vraag is veel relevanter waarom de kosten en kostensoorten niet worden vastgelegd. Het klinkt logisch om uit te gaan van de gemiddelde levensduur van vergelijkbare systemen. Maar waar wordt een generiek huur en toeslagen systeem gebruikt dat als referentie kan dienen voor het Nederlandse Toeslagen systeem?  Daarnaast is het nog maar de vraag of en hoe de verwachte levensduur van een systeem moet worden vastgesteld. Er draaien immers nog steeds Cobol programma’s uit de jaren 80 bij grote organisaties. Om nog maar te zwijgen over het aantal Fortran applicaties uit de jaren 60 en 70.
3. Ramingen
   De voorgestelde maatregel beperkt zich tot het vaststellen van de start- en einddatum van ICT projecten, en van de verwachte levensduur van ICT systemen. Daarmee is de aanbeveling van de rekenkamer voor ramingen wel erg summier. Ramingen zijn nuttig en noodzakelijk, maar kunnen nooit een doel op zichzelf zijn. Het wel of niet geslaagd zijn van een project bepaal je door de totale business case in ogenschouw te nemen. Niet door het wel of niet halen van een raming. Het doen van ramingen moet gezien worden als een beheersingsinstrument voor projecten, niets meer en niets minder. Het schatten van een project is geen wetenschap, hoewel er voldoende methodieken voorhanden zijn die je goed kunnen helpen. Overigens constateer ik in de praktijk dat de mogelijkheden niet of nauwelijks worden benut. Ook nu weer is de werkelijke vraag: Waarom niet? Het lijkt wel alsof heel ICT Nederland er allergisch voor is.
4. Kosten
   De rekenkamer stelt interne en externe rapportages voor op basis van project administratie, inclusief controles op die administraties. Ja, dank je de koekoek! Hier geldt garbage in, garbage out. Het ontbreken van een heldere en stabiele scope en standvastige opdrachtgevers maken dat bij de start het uitschuiven in tijd en geld al een gegeven is. Meer controle staat niet gelijk aan een hogere mate van beheersing. Dit is een misvatting
   die steeds hardnekkiger wordt, blijkbaar ook bij de Rekenkamer.
5. Besturing
   Verbetering van de besturing is volgens de Rekenkamer situationeel en vooral geënt op het invullen van de CIO functie. Daarnaast stelt de Rekenkamer dat voor besluitvorming een basishoeveelheid aan kennis over organisatie, informatie en onderliggende techniek noodzakelijk is.  Zo lust ik er nog wel een paar. Wat hier wordt opgemerkt is altijd waar. De vraag is veel meer hoe je de benodigde kennis kunt opbouwen, waarborgen en inzetten.  De Rekenkamer stelt ten aanzien van besturing ook dat de business leidend en verantwoordelijk moet zijn voor budget en prioriteit. Dat klinkt vanzelfsprekend, maar de business kan die rol en verantwoordelijkheid alleen maar nemen als ze de impact van haar eisen en wensen kan overzien. Juist dat is vaak niet het geval. Hierin zit overigens ook een uitdaging voor de meer technisch georiënteerden onder ons: het in begrijpelijke termen uitleggen wat de gevolgen zijn van de groeiende of veranderde business wensen.
6. Rijksbrede coördinatie
   De Rekenkamer adviseert geen Rijksbrede coördinatie. Daar waar processen departementale grenzen overschrijden is “overall” coördinatie juist wel noodzakelijk! Gebeurt dat niet dan gaat veel tijd verloren aan polderen zonder dat er tot een concreet resultaat gekomen wordt. Ik ben heter wel mee eens dat beslissingen over bijvoorbeeld prioriteiten niet overgelaten kunnen worden aan de ICT afdelingen, laat staan aan één enkel ministerie. Dat betekent echter wel dat er vanuit een overzicht en samenhangende visie sturing gegeven moet kunnen worden aan ICT voor de overheid. Het benoemen van één functionaris helpt daarbij, maar is op zichzelf geen oplossing.
7. Ministeriele verantwoordelijkheid
   Over de reacties van de ministeries op dit rapport kan ik kort zijn: een toonbeeld van gebrek aan leiderschap. Het zijn vooral toonbeelden van procedureel correcte antwoorden.

Veel voorkomende oorzaken voor uitloop en budgetoverschrijding van ICT projecten.

Omdat de Rekenkamer de werkelijke oorzaken niet of nauwelijks weet te benoemen, bereiken de geformuleerde verbeteracties nooit de kern van het probleem. De oorzaken van de problematiek liggen mijns inziens namelijk veel dieper. Ik zal per aandachtgebied kort aangeven waar vanuit onze ervaring achterliggende oorzaken liggen, en waar dus de verbeteracties op gericht zouden moeten worden.

Projectmanagement

De basics van projectmanagement ontbreken gewoon. Een goede administratie is randvoorwaardelijk voor elk project. Hetzelfde geldt voor risicomanagement en dat doorvertalen naar realistische budgetten. In die zin is de PRI-systematiek (PRI: Projectramingen Infrastructuur) niets nieuws. Dat is gewoon adequaat projectmanagement. Waarom doen projectmanagers dat dan niet?

Bijvoorbeeld omdat:

• Projectmanagers soms geen projectmanagers zijn (parkeerplaatsen voor uitgerangeerde lijnmanagers);
• Leidinggevenden gewoonweg niets doen met de opgeleverde rapportages,
• Projectmanagers soms worden beoordeeld door hun opdrachtgever en/of hun stakeholders.
• Nee zeggen tegen wensen van hogerhand kan dan “einde carrière” betekenen;
• P&O/HR weet gewoonweg niet hoe ze aan goeie projectmanagers moeten komen of hoe ze die skills zelf kunnen vaststellen en ontwikkelen.

Leidinggevenden/bestuurders

Het ontbreekt aan leiderschap. Met leiderschap doel ik op:

• NEE durven zeggen;
• Een duidelijk visie hebben waar de organisatie naar gaat;
• Duidelijke doelstellingen, opdrachten en business cases als uitgangspunten;
• Verantwoordelijkheid nemen ipv “commitment delegeren”.

Voorbeeldgedrag is essentieel!

Het ontbreekt aan kennis en ervaring van bestuurders om projecten te sturen. En daarmee ontbreekt het dan ook aan “Project Assurance”, het zekerstellen dat:

• projectdocumenten van voldoende kwaliteit zijn,
• de juiste belanghebbenden betrokken zijn,
• business case en planning en uitvoering van project op elkaar afgestemd zijn,
• risico’s afdoende in kaart zijn gebracht en de juiste maatregelen zijn genomen,
• met de juiste standaards wordt gewerkt.

Kortom, zekerstellen dat het project onder controle is! Als deze randvoorwaarden niet voldoende zijn ingevuld is het gevolg bijvoorbeeld:

• Inhoudelijke discussies in stuurgroepen in plaats van wie doet wat, wanneer is het gereed en vooral welke risico’s lopen we en durven we die ook te lopen.
• Lange tijd gezamenlijk gevoel van voortgang. Totdat in de eindfase blijkt dat zaken niet op elkaar aansluiten en dat zaken zijn vergeten. Elke faseovergang wordt vanzelfsprekend genomen, totdat iemand het lef heeft STOP te zeggen. Dit in tegenstelling tot elke goede projectmanagement aanpak: Men gaat niet naar de volgende fase tenzij aan alle condities is voldaan. Dit gedrag verandert in de laatste fase van een project. Dan besluit men wel pas naar de volgende fase over te gaan (productie), terwijl niet aan alle condities is voldaan. Gevolg is dat projecten ontploffen in de laatste fase.
• Onduidelijke verantwoordelijkheden. Belangrijk zijn vooral  gezamenlijke doelen en GESCHEIDEN verantwoordelijkheden!!

Dat heeft gevolgen voor de managementstijl. Het leidt tot de volgende veelvoorkomende “managementstijlen”:

• Management houdt zich meer bezig met brandjes blussen dan met structureel oplossen van problemen.
• Managers gedragen zich soms lethargisch. Signalen over uitloop worden duidelijk en tijdig aangereikt maar men doet er niets mee. Bij oplevering wordt zelfs de druk opgevoerd en de projectmanager kan zijn opdracht niet teruggeven want zijn carrière in het bedrijf hangt ervan af.
• Bij management lijkt een “sense of urgency”  voor ICT projecten niet te worden gevoeld. Er wordt altijd achteraf wel een reden gevonden waarom iets niet lukte. Daarmee is de kous wat hen betreft dan kennelijk af.

Inhoudelijke oorzaken

Architecten (vaak ontwerpers die door titeldevaluatie architect worden opgesteld) krijgen de ruimte allerlei innovatieve en technische leuke zaken te bedenken. Zonder dat ze als vervuiler ooit moeten betalen voor de keuzes die zij gemaakt hebben. Sterker nog: als een bepaald concept niet werkt is er al weer een nieuwe “oplossing” bedacht. Soms wacht men zelfs de niet het moment af waarop het bestaande concept zich gaat bewijzen.
Daarnaast is er vaak sprake van een toevloed van (onrealistische) eisen tijdens projectuitvoering. Stop deze. Houd scope en besluitvorming onder controle.
Ga ook niet proberen alles te automatiseren. Sommige systemen zijn zeer complex geworden door een handjevol uitzonderingen in de automatische verwerking mee te nemen.

Overige conclusies

• Een betrouwbaar en voorspelbaar projectresultaat realiseren op basis van een onvoorspelbare vraag is onmogelijk. Dit onderzoek van de Rekenkamer is vooral gericht op de projectmanagers. Ten onrechte. Er is evenveel rendement te behalen met onderzoek naar fouten aan de vraagzijde, gericht dus op de opdrachtgevers van projecten.
• Overheidsorganisaties zijn doorlopend bezig met verbeteringen. Dat is een goede zaak. Kleine verbeterstapjes zijn echter vaak net niet succesvol. Hierdoor voelt men zich na verloop van tijd gedwongen tot het nemen van grotere stappen, zoals het om de paar jaar doorvoeren van grootschalige reorganisaties. Hoe kunnen ingrepen van die omvang ooit succesvol zijn als de kleinere stapjes al een struikelblok zijn?
• Succesvolle projecten kenmerken zich door sterk leiderschap, de wil van alle partijen om verbinding te leggen tussen ICT en business en duidelijke grondslagen (meten = weten) voor besluitvorming. Besluitvorming vindt daarbij expliciet plaats. Dat betekent dat besluiten in gezamenlijkheid worden genomen, met aanvaarding van volledige verantwoordelijkheid door elke deelnemende partij, inclusief acceptatie van de genomen risico’s.
• Met het beter in de grip krijgen van projecten voorkom je situaties waarvan sommige organisaties beweren dat ze er goed mee om kunnen gaan: het onder druk oplossen van problemen en de systemen ondanks alle “tegenslagen” toch in de lucht krijgen.

Nieuwegein Juli 2008
Gerard Meijer KWD Resultaatmanagement