Behandel het ICT-project als een startup

Foto: raneko / osaMu CC 2.0

Over de aanpak van grote ICT-projecten bij de overheid is veel geschreven en gerapporteerd. Desalniettemin hebben wij de indruk dat er nog te weinig verandert om dit soort projecten in het gareel te krijgen. We hebben daarom nog eens goed gekeken naar de oorzaken van de problematiek en ons gerealiseerd dat een groot ICT-project niet zozeer een technische klus maar in feite een hele onderneming is. Vandaar dat we een ondernemersbril hebben opgezet en een parallel hebben getrokken met opstartende ondernemingen, waarbij we ons afvroegen wat grote ICT-projecten daarvan zouden kunnen leren.
Er zijn twee factoren waarvan we denken dat ze echt het verschil kunnen maken tussen slagen en niet slagen van projecten: de voorbereidingsfase en het team. Dat zijn overigens factoren die zich niet in de praktijk laten brengen door er een instructie over te schrijven of door ze in een checklist op te nemen ten behoeve van een projectreview of toets. Daar is de gewenste andere aanpak veel te fundamenteel voor.

Voorbereidingsfase moet écht anders

In de wereld van de startende ondernemers wordt de term ‘glas eten’ gebezigd. Het was de mede-bedenker en -oprichter van Paypal, tevens CEO van SpaceX en Tesla, Elon Musk, die stelde dat het opbouwen van een onderneming is alsof je glas zit te eten en de afgrond in kijkt. Het is gewoon echt keihard werken. Je krijgt teleurstellingen, je hebt te weinig geld en er gebeurt van alles. Maar dan moet je blijven doorzetten, gericht op de werkelijk toegevoegde waarde van het product of de dienst en op de afnemer, de echte eindgebruiker. Als je daarbij steeds groot blijft denken en dat weet te combineren met klein beginnen neemt de kans op succes zienderogen toe.
De projectvoorbereiding bij ICT-projecten zou wat ons betreft meer een dergelijk karakter moeten krijgen. En dat is een heel ander karakter dan we doorgaans in de praktijk van projecten tegenkomen. Er moet ruimte komen voor creativiteit en experimenten. Dit in het besef dat er meer wegen zijn die naar Rome leiden. ‘Jumping to conclusions’ – we zien het maar al te vaak – moet worden vermeden. De projectomvang moet zo klein mogelijk worden gehouden, minder is meer. Stokpaardjes, lang gekoesterde wensen die niets met het probleem van doen hebben, franje en overige ballast mogen daarbij geen plek hebben.
Te weinig zien we dat twee of meer oplossingen worden onderkend en uitgeprobeerd en dat er soms gewoon opnieuw wordt gestart. Waarom zou je niet een aantal teams de opdracht kunnen geven om elk met een oplossing te komen? Geef ze een klein budget om te experimenteren en/of met een proof-of-concept te komen en kies vervolgens de oplossing die het beste past.

Verwachtingen managen

Vroegtijdig falen is toegestaan. Je leert er veel van en je sluit wegen uit die op het eerste oog aantrekkelijke kanten lijken te hebben, maar bij nader inzien tot mislukken gedoemd zijn. Als zodanig is vroegtijdig falen geen afgang, maar een leermoment.
Daarnaast is het belangrijk dat de kwetsbaarheden en risico’s van het project bloot op tafel komen in plaats van onder het tapijt worden geveegd. Hoewel een dergelijke transparantie niet altijd even makkelijk is te realiseren, is het een must om te voorkomen dat later lijken uit kasten kunnen vallen. Stakeholders moeten er daarom intensief bij worden betrokken en hun verwachtingen moet je in een vroegtijdig stadium managen. Het is meestal zo dat een aantal partijen baat heeft bij het project, maar dat er ook partijen zijn die weliswaar nodig zijn om het project te laten slagen, maar die er zelf weinig mee opschieten of zelfs iets moeten inleveren. Daar moet men eerlijk en transparant over zijn en met betrokkenen passende afspraken over maken. De realiteit gebiedt te zeggen dat niet altijd alle stakeholders volledig kunnen worden bediend. Verder moeten risico’s door stakeholders gezamenlijk worden gedragen en niet slechts bij een partij worden geparkeerd. Gelet op het bovenstaande vergt dat wel nogal wat onderhandelingskunst.

Eindgebruikers

Eindgebruikers moeten in een zo vroeg mogelijk stadium hun zegje kunnen doen. Daarom is het van belang eindgebruikers als zodanig te identificeren en ze vervolgens actief bij het project te betrekken, bijvoorbeeld door ze in te zetten bij experimenten! Te vaak zien we echter dat de echte eindgebruikers niet betrokken zijn. De ‘gebruikersrol’ wordt dan min of meer ingevuld door een beleidsambtenaar of een informatiemanager. Dat is verre van optimaal.
Bij dit alles moet er een gevoel van urgentie zijn; zaken moeten doortastend worden aangepakt, vooruitgang moet zichtbaar zijn. Het mag namelijk niet ontaarden in een speeltuin om wat te freewheelen. Het stellen van een deadline kan hierbij helpen.

Wat ons betreft vindt er een veel grotere scheiding plaats tussen deze voorbereidingsfase en de realisatie- of uitvoeringsfase. Dit geldt ook voor governance en toetsing. De startup-achtige voorbereidingsfase gaat niet lukken als je die in het keurslijf van de een of andere projectmanagementmethodiek probeert te persen. Diverse verplichte startdocumenten en rigide procedures gecombineerd met werkgroepen, stuurgroepen en een opdrachtgever, die ver van het team af zit, passen daar niet bij.

Opdrachtgever en team doorslaggevend

En daarmee komen we bij onze tweede prioriteit: het team. Om een ICT-project tot een succes te maken is een gepassioneerde opdrachtgever nodig, die samen met een sterk en bevlogen team opereert. Voorwaarden zijn dat er een echte ‘klik’ bestaat tussen opdrachtgever en het team en dat de opdrachtgever van begin tot einde betrokken blijft. Op die wijze kan het project solide op de rails worden gezet en vervolgens tot een goed einde gebracht. De kans is dan ook het grootst dat de noodzakelijke middelen effectief worden aangewend en dat de beoogde resultaten daadwerkelijk worden geboekt.
Maar hoe gaat het in de praktijk? Hoe vaak gebeurt het niet dat de opdrachtgever van een project niet eens weet wie de architect van een voor hem belangrijk nieuw systeem is en wie daadwerkelijk de kritische programmatuur daarvoor realiseert? De opdrachtgever kent de projectmanager, maar veel verder reikt zijn persoonlijke betrokkenheid bij de echte werkzaamheden vaak niet. Meestal slaagt hij er wel in het project te financieren omdat hij een of meer potjes kan aanboren. Vaak kan daarna al snel worden gestart als er maar een plan van aanpak (PID) ligt, een projectmanager is aangewezen en een rechtvaardiging van het project in de vorm van een businesscase voorhanden is. In ondernemersland werkt het zo niet. Financiers zijn niet meteen geneigd geld te steken in een onderneming op basis van alleen een mooi businessplan, een gelikte presentatie en de wetenschap dat een gedreven ondernemer de kar trekt. Geloof en vertrouwen in de betreffende ondernemer en het team dat de klus moet gaan klaren zijn ontzettend belangrijk vooraleer de beurs wordt getrokken. Natuurlijk moet het businessmodel aantrekkelijk en realistisch zijn, maar vaak weegt de teamkwalificatie nog net iets zwaarder.
Governance-constructies (project- en programmamanagementstructuren) van ICT-projecten bij de overheid creëren doorgaans een te grote afstand tussen opdrachtgever en team. Dikke pakken projectdocumentatie, beoordeeld door rijen van reviewers en toetsers, kunnen niet datgene vervangen wat nodig is voor een succesvol ICT-project:
een bezield opdrachtgever én een gekwalificeerd team dat hij vertrouwt en waarvoor hij zijn de hand in het vuur durft te steken.
De bemensing van ICT-projecten, inclusief het aanwijzen of vinden van een goede opdrachtgever, moet in ieder geval bij de overheid veel meer aandacht krijgen.

Frans Lambi is directeur bij Covision Management Consulting BV
Jan Ploeg is Verbinder | Informatiemanager | Architect bij I-Interim Rijk, de Rijksbrede pool van I-professionals

In een whitepaper hebben beide auteurs een verdergaande analyse van de aanhoudende problematiek uit dit artikel gemaakt en op een breder terrein de vergelijking gemaakt met startende ondernemers.
Het betreffende document kunt u HIER downloaden.