Vertrouwen is de sleutel tot succes in complexe IT-transformatie-programma’s

Inleiding

Onlangs werd bekend dat de overheid kampt met extreme overschrijdingen (ongeveer één miljard) als gevolg van vertraagde programma’s ([Olst18]). Ook in andere sectoren komen mislukte programma’s voor. Retailer Lidl is recent gestopt met een implementatie die zeven jaar geduurd heeft en vijfhonderd miljoen euro heeft gekost. Bestuurders en toezichthouders hebben vertrouwen in een goede afloop, omdat ze niet of onvoldoende geïnformeerd worden over de status en risico’s van het programma. Het vertrouwen in het succes van een IT-transformatieprogramma is op twee manieren te interpreteren en positief te beïnvloeden. Hiervoor werd al een onafhankelijke aanpak (‘Quality Assurance’) gebruikt, die nog steeds werkt en gebruikt kan worden. Het is nu tijd om Quality Assurance ‘anders’ in te zetten, door het vertrouwen in de relaties binnen een programma meer aandacht te geven en nader te onderzoeken. Dit artikel beschrijft welke factoren impact hebben op het vertrouwen in de relaties binnen een IT-transformatieprogramma, en hoe dit vertrouwen positief beïnvloed kan worden.

Transformatieprogramma’s met een verander- en IT-component zijn voor de meeste organisaties nog altijd moeilijk beheersbaar ([Koza07], [Olst18]). Tientallen miljoenen euro’s worden gereserveerd om systemen en processen te veranderen. Voorbeelden hiervan zijn implementaties van een ERP-systeem of het Elektronisch Patiëntendossier in een ziekenhuis. Dergelijke programma’s worden niet frequent uitgevoerd, gezien de (business)impact die ze hebben. Ze worden daarnaast uitdagender door trends (zoals de Cloud en outsourcing), en door de betrokkenheid van de in het programma aanwezige stakeholders. Door een sterke toename van de betrokkenheid van externe partijen in dergelijke programma’s groeien deze programma’s snel qua tijdelijke organisatie, en als gevolg daarvan zijn ze ook moeilijker beheersbaar.

Het vertrouwen tussen de betrokken partijen in een IT-transformatieprogramma is van groot belang voor de uiteindelijke kwaliteit (en het resultaat) van het programma. Vertrouwen kan snel beschadigd worden. We zien dat leveranciers steeds vaker met onderaannemers (moeten) werken, waardoor het aantal betrokken partijen in de programmaorganisatie toeneemt, en het vertrouwen tussen de betrokken partijen onder druk kan komen te staan.

In de literatuur bestaan verschillende gedateerde definities van vertrouwen ([McKn96]). Een overeenkomst in deze definities van vertrouwen is de bereidheid van een persoon of groep om afhankelijk te zijn van de daden van een andere persoon of groep ([Maye95]). IT-transformatieprogramma’s zijn omgevingen waarin een structuur bestaat van meerdere leveranciers en betrokken partijen. Deze partijen hebben naast een duidelijk gezamenlijk belang (het programma moet slagen binnen de daarvoor gestelde kaders), ook een eigen belang dat met het gezamenlijke belang kan conflicteren. Indien er een conflicterende situatie optreedt, heeft dit vaak een negatief gevolg voor het vertrouwen tussen de betrokken partijen, en zodoende ook impact op het gezamenlijk belang.

De praktijk laat zien dat onderling vertrouwen een belangrijke oorzaak, en katalysator, is voor het succes van een IT-transformatieprogramma. De vraag is dus hoe er vertrouwen in IT-transformatieprogramma’s kan worden gecreëerd, en waar mogelijk verbeterd, zodat het vooraf beoogde resultaat en de bijbehorende kwaliteit kan worden gehaald. Hoe kan vertrouwen ‘expliciet’ gemaakt worden voor bijvoorbeeld bestuurders, toezichthouders en externe (project)auditors?

Dit artikel beschrijft de belangrijkste risico’s met een impact op het vertrouwen binnen IT-transformatieprogramma’s. Om het vertrouwen in het (eind)resultaat van een programma of project inzichtelijk te maken, volstaat een huidige, reeds bewezen en gevalideerde aanpak genaamd ‘Quality Assurance’ (hierna: QA). Om het vertrouwen tussen de betrokken partijen te vergroten, is een uitbreiding van de reeds bestaande QA-methodiek nodig. Om het bewustzijn rondom relaties in IT-transformatieprogramma’s te creëren, gaat dit artikel in op de vraag hoe risico’s met een impact op het vertrouwen tussen de verschillende partijen tijdig gesignaleerd en gemitigeerd kunnen worden, en in hoeverre de QA dient te veranderen om een bijdrage te leveren aan het vergroten van het vertrouwen in een IT-transformatieprogramma. We geven achtereenvolgens een toelichting op de structuur van een IT-transformatieprogramma, we beschrijven de risico’s met een impact op het vertrouwen, om ten slotte de aanpassingen aan de huidige QA-methodiek te beschrijven, die het vertrouwen kunnen vergroten.

De structuur van een IT-transformatieprogramma

De projectmanagementmethodiek PRINCE2 beschrijft een programma of project als een tijdelijke, flexibele organisatiestructuur die is opgezet om de implementatie van een verzameling met elkaar samenhangende projecten te coördineren, sturen en controleren, om uiteindelijk de boogde strategische doelstelling en gerelateerde eindresultaten te behalen ([Onna10]).

In een dergelijk programma worden bedrijfsprocessen verbeterd, waar de gehele organisatie direct of indirect bij wordt betrokken. Door de betrokkenheid van de eindgebruiker is het veranderkundige aspect van groot belang bij deze programma’s. Bij IT-transformatieprogramma’s onderscheiden we naast de verandercomponent ook een duidelijke IT-component, die ervoor zorgt dat IT en de business samenkomen in de programmaorganisatie.

In een IT-transformatieprogramma zijn de volgende zes fasen te onderscheiden (zie Figuur 1). In de initiatiefase wordt het doel van het programma nader uitgezocht en uitgewerkt. Tevens wordt de financiële haalbaarheid van het programma getoetst. In de ontwerp- en bouwfase wordt de oplossing achtereenvolgens ontworpen en gerealiseerd. Na het testen wordt het systeem in productie genomen in de ‘Go-Live’-fase en vindt de transitie naar de beheerorganisatie plaats.

Figuur 1. Verschillende fases van een IT-transformatieprogramma. [Klik op de afbeelding voor een grotere afbeelding]

In Figuur 2 is een vereenvoudigde weergave van de structuur van een dergelijk programma weergegeven, zoals beschreven in PRINCE2 ([Onna10]). Hierin zijn de standaardrollen van een programmastructuur opgenomen, zoals de eigenaar (project board), de gebruikersorganisatie (senior user), project- of programmamanagement en de leverancier (senior supplier).

Figuur 2. Structuur IT-transformatieprogramma (PRINCE2). [Klik op de afbeelding voor een grotere afbeelding]

In de praktijk zien we dat het leveranciersnetwerk (de ‘senior supplier’ in PRINCE2) steeds meer leveranciers bevat, en daarmee steeds groter wordt. In Figuur 3 is de vereenvoudigde structuur van een IT-transformatieprogramma weergegeven, in relatie tot het gerelateerde leveranciersnetwerk.

Figuur 3. Structuur IT-transformatieprogramma met uitgebreid leveranciersnetwerk. [Klik op de afbeelding voor een grotere afbeelding]

De leveranciers zijn op te delen in de volgende vier typen:

1. Softwareleveranciers: deze leveranciers leveren de software die als basis dient voor de implementatie van het nieuwe systeem;
2. Implementatiepartners: deze partners leveren de capaciteit, kennis en ervaring aan het IT-transformatieprogramma. In veel praktijkgevallen is de interne capaciteit en het kennisniveau onvoldoende om een dergelijk programma succesvol uit te kunnen voeren;
3. Hardwareleveranciers: deze leveranciers leveren de benodigde hardware, eventuele software en consultancy om de oplossing of het systeem te laten functioneren;
4. Interne ICT-organisatie: vaak is er een interne ICT-afdeling betrokken bij het programma, met verantwoordelijkheden als het inrichten van de beheerorganisatie, of het bestellen, testen en implementeren van de benodigde randapparatuur.

We merken dat externe leveranciers, maar ook de ICT-afdeling, gebruikmaken van onderleveranciers. De structuur die dan ontstaat, zie Figuur 3, maakt het afstemmen van planningen en verwachtingen ingewikkeld. Het resultaat is een uitgebreid, tijdelijk netwerk van zowel interne als externe partijen, die sterk van elkaar afhankelijk zijn. De bereidheid van alle betrokken partijen om afhankelijk te zijn van de prestaties van andere partijen is essentieel voor het onderlinge vertrouwen. Daar komt bij dat niet alle leveranciers elkaar kennen, waardoor de afhankelijkheid niet voor alle partijen inzichtelijk is.

Risico’s voor het vertrouwen in IT-transformatieprogramma’s

Op basis van ervaringen die wij de afgelopen jaren hebben opgedaan met IT-transformatieprogramma’s zijn we tot onderstaande aspecten gekomen, die een impact kunnen hebben op het vertrouwen (voor wat betreft de relaties tussen de betrokken partijen). In de volgende paragraaf gaan we vervolgens verder in op de aanbevelingen om Quality Assurance uit te breiden met deze risico’s.

Netwerkstructuur

IT-transformatieprogramma’s zijn complex door de netwerkstructuur die ontstaat als gevolg van de verschillende partijen die gelijktijdig betrokken zijn bij het programma en verantwoordelijk zijn voor een gedeelte van het resultaat (zie figuur 3). Implementatieconsultants werken steeds vaker met onderleveranciers (met name zzp’ers), waardoor de programmaorganisatie indirect te maken heeft met meerdere partijen. De betrokken partijen hebben elk een eigen manier van werken, wat in veel gevallen leidt tot verschillen in aanpak, ontwikkelmethodiek, projectmanagementmethodiek, implementatiestrategie, communicatie en het systeem voor risico- en issuemanagement. Deze verschillen kunnen leiden tot issues in de samenwerking, en uiteindelijk zelfs tot risico’s voor het vertrouwen tussen deze partijen.

We constateren dat programmamanagers of stuurgroepen zich niet altijd bewust zijn van deze netwerkstructuur, evenals van de bijbehorende verschillen in aanpak en (individuele) belangen. Een getekende overeenkomst met een leverancier kan onvoldoende inzicht geven in de mogelijke betrokkenheid van onderleveranciers.

Onderlinge belangen

Leveranciers die betrokken zijn bij een programma hebben altijd een eigen belang. Dit belang is veelal gericht op de opleverdatum van het programma. Het belang kan echter ook een oorsprong hebben in de scope van het programma (bijvoorbeeld de gebruikersorganisatie, die zo veel mogelijk functionaliteit gerealiseerd wil hebben). De aanwezigheid van deze tegenstrijdige of tegengestelde belangen is niets nieuws, maar wel een significant risico voor het vertrouwen binnen een programma.

De vier meest bekende en gebruikte stuurparameters voor programma’s zijn geld, tijd, kwaliteit en scope. De grootste uitdaging voor een IT-transformatieprogramma is om de vooraf bepaalde kwaliteit te behalen, binnen de beschikbare planning en het budget. Hoewel dit een gezamenlijk doel is van alle partijen die een rol spelen in het programma, blijkt in de praktijk dat de focus op de verschillende stuurparameters onderling kan verschillen, en in sommige gevallen zelfs conflicteren met het gezamenlijk doel.

Wij merken dat de gebruikersorganisatie in een programma zo veel mogelijk functionaliteit en een zo hoog mogelijke kwaliteit wil, terwijl een implementatieconsultant veelal gefocust is op het behalen van de opleverdatum binnen het beschikbare budget. Het vertrouwen tussen de betrokken partijen kan dalen wanneer deze belangen te ver uit elkaar komen te liggen.

Interne versus externe betrokkenheid

Zoals in de inleiding al aangegeven, constateren we de afgelopen jaren een aanzienlijke toename in de betrokkenheid van externe partijen bij programma’s. We kennen zelfs programma’s waarbij meer externe dan interne medewerkers aan het programma werken. Uit onderzoek ([Youn17]) blijkt dat een significante toename van externen in veel gevallen leidt tot achterdocht en zorgen bij de interne werknemers. Daarnaast blijkt uit dit onderzoek dat het onderlinge vertrouwen in zulke gevallen onder druk komt te staan, en daarmee ook de prestatie van het programmateam als geheel.

Bij onze klanten ervaren wij een perceptie bij interne medewerkers dat externen minder ‘gevoel’ bij de cultuur van de organisatie hebben. Een gevolg hiervan is dat de interne medewerkers de externen minder zullen vertrouwen, en zij daardoor minder vertrouwen hebben in een goede overdracht van het programma naar de lijnorganisatie. Daarnaast merken we dat interne medewerkers vaak bang zijn om hun eigen functie te verliezen aan een externe medewerker, na afronding van het programma.

Portfoliomanagement

Organisaties veranderen snel en voeren dus veel programma’s en projecten door. Wanneer een organisatie geen of onvoldoende portfoliomanagement heeft, ontbreekt het in veel gevallen aan een integraal overzicht van de lopende programma’s en afhankelijkheden tussen deze programma’s. De organisatie kan dan in de situatie terechtkomen dat belangrijke (IT-)resources voor meerdere programma’s of projecten worden ingezet, zonder dat de programmamanager of stuurgroep hiervan op de hoogte is. Het risico hiervan is dat een resource niet kan leveren naar verwachting, wat vervolgens een impact kan hebben op het onderlinge vertrouwen.

Portfoliomanagement brengt structuur in het projectenportfolio en de governance van de programmaorganisatie. Een portfolio heeft, in tegenstelling tot een programma, een permanent karakter. Portfoliomanagement is noodzakelijk om de strategische doelstellingen van de organisatie te realiseren, door te investeren in veranderingen (IT-transformatieprogramma’s).

Adoptie van de business

Kenmerkend voor een IT-transformatieprogramma is de betrokkenheid van de gebruikersorganisatie, en de impact op de primaire processen in de gebruikersorganisatie bij het opleveren van het programma. In een dergelijk programma is tijdige en blijvende aandacht voor verandermanagement van belang, anders zal de adoptie van de business achterblijven, en het programma wellicht niet het gewenste resultaat of effect opleveren.

We merken dat key users (in de business) veelal te laat of niet voldoende betrokken worden bij een IT-transformatieprogramma. Als gevolg hiervan leren zij de betrokken partijen, die onderdeel uitmaken van het IT-transformatieprogramma, pas gedurende de testfase (of vlak voor ‘Go-Live’) kennen. Doordat programma’s tegenwoordig een netwerkstructuur kennen, met (verhoudingsgewijs) veel externen, bestaat het risico dat het vertrouwen van de key users daalt door deze late betrokkenheid.

Projecthygiëne

De complexiteit van IT-transformatieprogramma’s vindt vaak een oorsprong in de business case of begroting en de omvang/grootte van de programmaorganisatie. Een grote kostenpost zijn de uren die gemaakt worden door de interne medewerkers en externen.

Wij zien in de praktijk dat organisaties vaak nog (onder)leveranciers in de programmaorganisatie hebben, zonder een getekende overeenkomst of duidelijke afspraken. Programma’s zonder gevalideerde business case of begroting komen gelukkig zelden nog voor. Wanneer onvoldoende afspraken met leveranciers over tijdsbesteding, planning, of kwaliteit worden gemaakt, is dit een risico voor het vertrouwen in het programma.

Vroeg of laat zal het programma namelijk (laten) bepalen waar het staat in relatie tot de stuurparameters (geld, tijd, scope en kwaliteit). Op dat moment worden de gemaakte uren van de interne medewerkers en externen in kaart gebracht, in relatie tot de voortgang en financiën. Wanneer dan het inzicht ontbreekt of dit onvoldoende ‘hard’ of feitelijk is, kan dit een negatief effect op het vertrouwen hebben. Leveranciers kunnen achterblijven in het leveren van het gewenste resultaat, terwijl de uren al grotendeels ‘op’ zijn. Afwijkingen kunnen dan moeilijk verklaard worden, en er kan wantrouwen in het succes van de leverancier ontstaan. Een programmacontroller zou hierbij kunnen ondersteunen als controlerende partij. Het Project Management Office (PMO) zou dit kunnen continueren gedurende het gehele programma.

Het vertrouwen ‘meten’ en vergroten

Zoals eerder benoemd is het vertrouwen in een IT-transformatieprogramma tweeledig. Het vertrouwen kan namelijk enerzijds betrekking hebben op het vertrouwen in het algehele en ‘tastbare’ resultaat van het programma, anderzijds op het vertrouwen tussen de partijen in de governance van het programma. Een transformatieprogramma heeft volgens ons twee kanten: een harde (blauwe) kant, en een zachtere (of menselijke) kant.

Om het ‘tastbare’ resultaat van een IT-transformatieprogramma te onderzoeken, wordt QA gebruikt ([Keun16]). Met behulp van QA kan een programma doorgelicht worden, en zo wordt inzicht gegeven in de kwaliteit en risico’s van een IT-transformatieprogramma. Hiervoor worden de ‘harde’ componenten, zoals de programmastructuur en -governance, begroting, beheerprocessen, ingerichte controlemaatregelen, testresultaten en procedures onderzocht.

De zes belangrijkste aspecten met een impact op het vertrouwen in een programma, zoals eerder benoemd in dit artikel, vinden een oorsprong in de meer ‘zachte’ of softe kant van een programma. Deze risico’s worden bij een traditionele QA-aanpak nog onvoldoende onderzocht.

In tabel 1 hebben we de eerder beschreven risico’s gekoppeld aan de belangrijkste aanbevelingen voor het uitbreiden of aanpassen van de QA-methodiek, zoals we deze kennen en toepassen.

Tabel 1. Aanbevelingen voor uitbreiding QA per risico voor het onderlinge vertrouwen tussen partijen. [Klik op de afbeelding voor een grotere afbeelding]

Het is van belang om deze risico’s tijdig te signaleren, zodat het vertrouwen in een programma niet beschadigd wordt. We adviseren organisaties waarin een IT-transformatieprogramma wordt uitgevoerd om QA toe te passen, en de risico’s en bijbehorende aanbevelingen, zoals weergegeven in tabel 1, daarbij aanvullend in scope te nemen.

Tot slot hangt de relevantie van de eerder beschreven risico’s af van de fase waarin het programma zich bevindt. In figuur 4 zijn de zes risico’s geplot op de structuur van een IT-transformatieprogramma. Zoals zichtbaar is in de figuur zijn portfoliomanagement en projecthygiëne twee aspecten waar gedurende het gehele programma aandacht voor dient te zijn. De netwerkstructuur ontstaat vooral in de initiatiefase, en dient vooral op dat moment aandacht te krijgen. De onderlinge belangen van de partijen komen naar voren bij het daadwerkelijk ontwerpen en realiseren van de oplossing. Doordat het betrokken externe netwerk steeds verder toeneemt vanaf de bouwfase, gezien de toenemende vraag naar resources, speelt dat aspect voornamelijk een rol in de bouw-, test- en Go-Live-fases. Zoals beschreven wordt de gebruikersorganisatie vaak pas vanaf de testfase betrokken bij het programma. Dit dient idealiter al vanaf de ontwerpfase te gebeuren, om zo de verwachtingen van zowel de business als het programmamanagement beter op elkaar af te stemmen.

Figuur 4. Risicoverloop gedurende het IT-transformatieproject (de getallen geven de risico’s uit Tabel 1 weer). [Klik op de afbeelding voor een grotere afbeelding]

Conclusie

Quality Assurance vergroot het vertrouwen in het realiseren van het beoogde eindresultaat van een IT-transformatieprogramma, doordat het risico’s in een vroeg stadium in kaart kan brengen. We constateren dat dergelijke programma’s complexer zijn geworden door de netwerkstructuur die ontstaat in deze programma’s. Hierdoor ontstaan risico’s voor het vertrouwen tussen de betrokken partijen. Deze risico’s worden in de traditionele aanpak van QA onvoldoende onderzocht, en daarmee ook onvoldoende gemitigeerd.

De praktijk laat zien dat er anno 2018 nog steeds flinke missers gemaakt worden bij het uitvoeren van IT-transformatieprogramma’s. Volgens ons is dit deels te wijten aan het vertrouwen in het IT-transformatieprogramma. Hierdoor gaat kennis, maar helaas ook veel geld verloren. Geld dat in bepaalde sectoren, bijvoorbeeld in de gezondheidszorg, vele malen beter besteed had kunnen worden aan het primaire proces of innovatie. We roepen bestuurders en toezichthouders dan ook op om actief aan de slag te gaan met het ‘in control’ krijgen en houden van programma’s en projecten, vooral waar het gaat om het vertrouwen in het programma.

In dit artikel hebben we de belangrijkste risico’s die een impact kunnen hebben op het vertrouwen tussen de betrokken partijen uiteengezet, en deden we aanbevelingen om deze risico’s te mitigeren. Door bewustzijn te creëren en deze risico’s in de scope van een QA-onderzoek te nemen, kan QA een belangrijke bijdrage leveren om, naast het vergroten van het vertrouwen in het eindresultaat van het IT-transformatieprogramma, ook het vertrouwen tussen de betrokken partijen onderling inzichtelijk te maken en vergroten.