zoeken binnen de website

Behandel het ICT-project als een startup

Wat grote ICT-projecten bij de overheid kunnen leren van startende ondernemingen

door: Frans Lambi & Jan Ploeg | 8 september 2016

Meer aandacht voor de voorbereidingsfase en de bemensing zijn belangrijke factoren die kunnen helpen het lek rondom grote ICT-projecten bij de overheid te dichten. Maak ruimte voor vroegtijdig falen en zorg voor een bezielde opdrachtgever én een gekwalificeerd team.

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.


Jan Ploeg (l) en Frans Lambi

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.

reacties: 7

tags:

  • Rein Jonkman #

    8 september 2016, 12:15

    Buitengewoon herkenbaar, en haaks op de cultuur die we doorgaans tegenkomen binnen de overheid. Essentieel is denk ik de notie dat de opdrachtgever doorgaans onvoldoende weet wat hij kan vragen, terwijl projectleiders juist streven naar een strak afgebakende scope. Voor fantasie en creativiteit is dan nauwelijks ruimte meer binnen het project, laat staan voor het ombuigen van de opdracht.

    Hoe gaat dit ´vliegen´?
    De hier voorgestelde aanpak ziet er veelbelovend uit en moet een eerlijke kans krijgen om zichzelf te kunnen bewijzen.
    Dus: welke opdrachtgever durft het aan om een belangrijk project op deze manier aan te pakken, inclusief het kiezen voor de juiste mensen en de benodigde eigen betrokkenheid? Al was het maar in de opstartfase.
    Immers, zien is geloven.

  • Koen de Groot #

    8 september 2016, 13:32

    Bij onze organisatie herken ik de genoemde problematiek ook. Ons portfoliomanagement is sterk verbeterd. Als onderdeel daarvan ben ik nu een eerste project gestart volgens de lean Startup Methodiek.

    Het leuke hiervan is dat we vooraf niet gaan bepalen hoe het eindprodukt eruit moet zien. Na de eerste brainstormsessie lagen er gelijk 5 geweldige ideeën voor oplossingen. Alle 5 hadden we vooraf niet kunnen bedenken.

    We gaan nu een traject in van ideeën aanscherpen en valideren. Ik ben erg benieuwd of er andere organisaties zijn met ervaringen op dit gebied die we uit kunnen wisselen.

  • Seger de Laaf #

    8 september 2016, 16:53

    Eens, maar jullie vergeten één belangrijk aspect: cultuur. Binnen de overheid zijn er duizenden ambtenaren die zich graag met een project bemoeien. Daardoor is de dynamiek van een startup bij voorbaat kansloos. Tenzij je de inrichting verandert, maar dan kom je aan werkgelegenheid: Too big to fight.

  • Titus Mars #

    9 september 2016, 09:47

    Mooie insteek, Jan en Frans! We beginnen nogal eens met ‘realiseren’ en vergeten dat de fase van ‘leren en innoveren’ daarvoor niet alleen een noodzakelijk fundament is, maar ook een compleet andere dynamiek kent. Jullie perspectief maakt dat heel helder.

  • Hein Hendriks #

    9 september 2016, 10:11

    Zonder meer wederom een waardevol artikel. Elke inspiratie die leidt tot meer creativiteit om projecten binnen de overheid te laten slagen dienen we te omarmen en verder te exploreren.

    De overheid moet en kan geen onderneming zijn, maar ook een overheid verandert. Ook mensen binnen de overheid veranderen. Alleen al het feit dat jonge instromers zich anders zullen laten gelden.

    Op vele fronten is er sprake van transitie.

  • Hilbrand Bouwkamp #

    13 september 2016, 22:38

    In feite zijn veel van genoemde aspecten al een keer toegepast bij een een project binnen de overheid. Zie het artikel over AERIUS hier op iBestuur: ontwikkelen zonder zekerheden.

  • Chantal Savelsbergh Obvion #

    18 september 2016, 14:49

    Heel herkenbaar, dat voorbereiding in nieuwe projecten niet ‘alsof je al weet wat eruit moet komen ‘ gemanaged kunnen worden! De agile aanpak, lerend ontwikkelen samen met de klant tot een minimal viable product lijkt een geschiktere aanpak. Teamwork is crucuaal hierin! Veel organisaties doen nu ervaringen op met deze weg…veel te leren!

Reactieformulier

De met een * gemarkeerde velden zijn verplicht. U ziet eerst een voorbeeld en daarna kunt u uw bijdrage definitief plaatsen. Uw e-mailadres wordt niet op de site getoond. Reacties zonder achternaam worden verwijderd. Anoniem reageren alleen in uitzonderlijke gevallen in overleg met de redactie. U kunt bij de vormgeving van uw reactie gebruik maken van textile en er is beperkt gebruik van html mogelijk.