De Algemene Rekenkamer laat in het rapport ‘Lessen uit ict-projecten van de overheid, deel B' duidelijk kansen liggen. Zij beperkt zich vooral tot een algemene beschrijving van de problemen die aan de oppervlakte zichtbaar zijn. Achterliggende oorzaken worden nauwelijks onderzocht. Bovendien leunt de Rekenkamer bij het verkrijgen van een conclusie te zwaar op informatie uit administraties en het uniform zijn van de inhoud van deze administraties. Vrijblijvende, algemene en onpersoonlijke oplossingen zijn hiervan het gevolg.
Mijn reactie bestaat uit twee 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 van dit mislukken scherp op het netvlies hebt, ben je in staat echte verbeteracties te definiëren. Ook in die zin heeft de Rekenkamer mijnws 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. Administraties doorploegen is daarbij niet genoeg. Aanvullende informatie over omvang, kosten en kwaliteit kun je ook op basis van anders verkregen gegevens verzamelen. Bijvoorbeeld via interviews, enquêtes, expertoordelen en gesprekken met projectleiders.
2. Kosten en kostensoorten […], inclusief incalculeren van de verwachte levensduur van het systeem
Natuurlijk is het belangrijk de uitgaven gestructureerd vast te leggen. Zo kun je ict-projecten onderling beter vergelijken. Kosten en kostensoorten zijn op zichzelf snel vast te leggen. Dat is gewoon niet het echte probleem. De vraag waarom de kosten en kostensoorten niet zijn vastgelegd, is veel relevanter. Het klinkt logisch om uit te gaan van de gemiddelde levensduur van vergelijkbare systemen. Maar waar wordt een generiek huur- en toeslagensysteem gebruikt dat als referentie kan dienen voor het Nederlandse toeslagensysteem? Daarnaast is het nog maar de vraag of en hoe je de verwachte levensduur van een systeem moet vastleggen. Er draaien immers nog steeds Cobol programma's uit de jaren tachtig bij grote organisaties. Om nog maar te zwijgen over het aantal Fortran applicaties uit de jaren zestig en zeventig.
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. Om te bepalen of een project succesvol is, dien je de totale business case in ogenschouw te nemen. En dus niet alleen een raming. Ramingen zijn beheersingsinstrumenten 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 projectadministraties, 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 zorgen ervoor dat het uitschuiven in tijd en geld al bij de start 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 businesswensen.
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 concreet resultaat te boeken. Ik ben het er 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 vanuit 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. Ministeriële 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.
Verbeteracties gebaseerd op werkelijke oorzaken
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 aandachtsgebied kort beschrijven waar vanuit onze ervaring achterliggende oorzaken liggen en waar de verbeteracties op moeten worden gericht.
Actie 1: Verbeter de uitvoering van projectmanagement
De basics van projectmanagement ontbreken gewoon. Een goede administratie is voor elk project een randvoorwaarde. Hetzelfde geldt voor risicomanagement en de doorvertaling hiervan 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 de wensen van hogerhand kan dan "einde carrière" betekenen;
- P&O/HR weet niet hoe ze aan goede projectmanagers moeten komen of hoe ze die skills zelf kunnen vaststellen en ontwikkelen.
Actie 2: Vergroot leiderschapskwaliteiten en (project) bestuurlijke vaardigheden
Het ontbreekt aan leiderschap. Met leiderschap doel ik op:
- nee durven zeggen;
- een duidelijke visie hebben op de toekomst van de organisatie;
- duidelijke doelstellingen, opdrachten en business cases als uitgangspunten;
- verantwoordelijkheid nemen in plaats van "commitment delegeren".
Voorbeeldgedrag is essentieel!
Het ontbreekt bestuurders aan kennis en ervaring om projecten te sturen. En daarmee ontbreekt het dan ook aan "project assurance", ofwel het zekerstellen dat:
- projectdocumenten van voldoende kwaliteit zijn;
- de juiste belanghebbenden betrokken zijn;
- business case en planning en uitvoering van een 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 aan deze randvoorwaarden niet is voldaan, zijn de resultaten bijvoorbeeld:
- inhoudelijke discussies in stuurgroepen in plaats van antwoord op de vragen:
– wie doet wat?
– wanneer is het gereed?
– en vooral: welke risico's lopen we en durven we die ook te lopen? - lange tijd een gezamenlijk gevoel van voortgang, maar tegen het eind blijken de zaken niet op orde. In de eindfase blijkt bijvoorbeeld dat bepaalde elementen 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 projectmanagementaanpak: men gaat niet naar de volgende fase tenzij aan alle condities is voldaan. Als dit gedrag verandert in de laatste fase van een project en men besluit wel naar de volgende fase over te gaan (productie), terwijl niet aan alle condities is voldaan, is het gevolg veelal dat het project in deze laatste fase ontploft.
- onduidelijke verantwoordelijkheden. Belangrijk zijn vooral gezamenlijke doelen en GESCHEIDEN verantwoordelijkheden!
Dat heeft gevolgen voor de managementstijl. De volgende "managementstijlen" komen veelvuldig voor:
- het management houdt zich meer bezig met brandjes blussen dan met structureel oplossen van problemen;
- managers gedragen zich lethargisch. Signalen over uitloop krijgen zij duidelijk en tijdig aangereikt, maar ze doen 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 het management lijkt een "sense of urgency" voor ICT-projecten niet aanwezig. Achteraf is altijd een reden te vinden waarom iets niet lukte. Daarmee is de kous wat dit soort managers betreft dan kennelijk af.
Actie 3: Geef richting aan en schep vooral duidelijke kaders voor ICT innovatie
Architecten (vaak ontwerpers die door titeldevaluatie als architect worden opgesteld) krijgen de ruimte om allerlei innovatieve en technisch leuke zaken te bedenken. Zonder dat ze als vervuiler ooit moeten betalen voor de keuzes die zij maken. Sterker nog: als een bepaald concept niet werkt, is er alweer een nieuwe "oplossing" bedacht. Soms wacht men zelfs het moment niet af waarop het bestaande concept zich gaat bewijzen.
Daarnaast is er vaak sprake van een toevloed van (onrealistische) eisen tijdens de projectuitvoering. Stop deze toevloed. Houd scope en besluitvorming onder controle.
Ga evenmin 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. Door 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.
Krijg je meer grip op projecten, dan kun je situaties voorkomen waarvan sommige organisaties beweren dat ze er goed mee om kunnen gaan: het onder druk oplossen van problemen en het in de lucht krijgen van de systemen ondanks alle "tegenslagen".
Gerard Meijer
