Meer aandacht voor de veranderkant van IT-projecten loont!

Cover stories

IT projecten en nieuwe ICT systemen. De grootste uitdaging is niet de techniek is, maar wat gebruikers ermee doen. De sleutel  ligt in de lijn, niet in het project.

Wie de investeringsvoorstellen voor IT-projecten bekijkt, ziet vaak een mooi perspectief. Efficiencywinst, meer toegevoegde waarde voor klanten, meer commerciële kansen. Het waarmaken daarvan is vaak niet alleen een technische uitdaging maar vooral een verandervraagstuk. Ja dat weet u wel. Maar waarom gaat het dan toch vaak zo moeizaam? Een pleidooi voor een bredere kijk op IT-projecten.

Een waargebeurd verhaal.
Een grote onderneming wil een nieuw klantinformatie-systeem implementeren. De onderneming bestaat uit een aantal zelfstandig opererende regiobedrijven. De ratio achter deze forse investering is duidelijk: als alle regiobedrijven de actuele informatie over klanten vastleggen en met elkaar delen, dan krijgt het bedrijf als geheel meer zicht op de commerciële kansen die er zijn. En dan wordt het gemakkelijker om die te benutten, bijvoorbeeld door meer cross-sell en up-sell. 

Wanneer het systeem draait en de gebruikers getraind zijn, loopt het toch anders. Dan blijkt dat de salesmanagers niet erg hard sturen op het bijhouden van klantdata, zij hebben andere prioriteiten. Binnen de salesteams is de norm dat je met klanten en business bezig hoort te zijn, niet met ‘administratieve rompslomp’. Bovendien gaat het delen van informatie met de andere regio’s tegen ieders gevoel in: je gaat toch geen leads weggeven? Als gevolg hiervan wordt het nieuwe systeem onvoldoende gevoed met informatie en blijven de verwachte commerciële voordelen uit.

Techniek of gedrag?

Net als bij het bovenstaande voorbeeld, is de opbrengst van IT-investeringen vaak niet zozeer afhankelijk van de techniek zelf maar van de manier waarop de organisatie die inzet.

Digitaal ontwerpen en bouwen in een BIM-systeem zorgt bij bouwbedrijven voor minder faalkosten. Als je het tenminste goed inzet in een nieuwe manier van werken. Een CRM-systeem helpt om commerciële kansen beter te benutten. Als je het tenminste goed gebruikt. Een modern Field Service-systeem voor de technische buitendienst zorgt voor sneller oplossen van storingen en een snellere facturatie. Als de buitendienst tenminste z’n werkwijze wil aanpassen. En ook in het bredere IT-domein, zoals bij vraagstukken rond informatiebeveiliging, zien we dat de grootste uitdaging niet de techniek is, maar wat gebruikers ermee doen. 

In al deze gevallen is het realiseren van de geplande opbrengst dus vooral afhankelijk van het gedrag van medewerkers. Het is een verandervraagstuk. In de meeste implementatieplannen is daar ook aandacht voor.

Alleen wordt dat vraagstuk vaak vrij beperkt opgevat, als iets dat je vanuit het project kan oplossen door training, e-learnings of een adoptieprogramma. In de praktijk zien we dat dit vaak een verkeerde inschatting is.

Het gedrag van mensen, dus ook of- en hoe zij nieuwe technologie gebruiken, wordt vooral bepaald in de context van de lijnorganisatie en het team waarin zij werken. Bijvoorbeeld doordat hun managers op bepaalde doelen sturen, of doordat er onderling bepaalde normen gelden. Daar kan geen knoppentraining of e-learning iets aan doen. 

Nog een waargebeurd verhaal.

Een ziekenhuis implementeert een nieuw Elektronisch Patiëntendossier (EPD). Zo’n systeem zit in het hart van het primaire proces, dus alle verschillende specialisten en zorgmedewerkers hebben ermee te maken. Het inrichten van het systeem is een langdurig en taai proces. Het ziekenhuis bestaat uit vele zelfstandige afdelingen en klinieken met hun eigen werkprocessen, terwijl digitalisering om een zekere mate van standaardisering vraagt. Binnen het EPD-project wordt met vertegenwoordigers uit de organisatie hard gewerkt aan een systeeminrichting die voor iedereen acceptabel is. Maar als het systeem live gaat is zo ongeveer iedereen binnen het ziekenhuis ontevreden en zelfs boos. Want het systeem sluit nog onvoldoende aan op de praktijk. Dat uit zich in: ‘Dit werkt gewoon niet’, en ‘Het is gewoon te ingewikkeld gemaakt, ik snap het niet’. De onrust die ontstaat, laat zien dat er naast het technische gedeelte nog iets anders had moeten gebeuren: in een vroeg stadium de organisatie meenemen. Leidinggevenden hierbij goed hun rol laten pakken en helpen om de noodzaak uit te dragen. De verwachtingen managen. Werken aan acceptatie van meer standaardisatie. En afdelingen en klinieken eerder betrekken zodat zij hun manier van werken tijdig kunnen aanpassen. Als je dat achteraf nog moet doen begin je al met 2-0 achter. 

Vier voorwaarden

De twee waargebeurde voorbeelden maken duidelijk dat trainingen en adoptieprogramma’s niet voldoende zijn wanneer verandering van gedrag en manier van werken noodzakelijk zijn Daar kan een project weinig aan doen, er moet vooral iets in de lijnorganisatie gebeuren. In het boek Change made simple, dat mijn collega Ilse van Ravenstein en ik een paar jaar terug schreven, bespreken we vier randvoorwaarden voor organisatieverandering. In de praktijk zien we dat die ook cruciaal zijn voor grote IT-projecten:

  1. In de eerste plaats is het essentieel dat managers en medewerkers in de teams zelf de overtuiging hebben dat de nieuwe technologie en de nieuwe manier van werken gaan helpen bij het bereiken van hun doelen. Daarvoor is het belangrijk dat managers en teamleiders al in een vroeg stadium de visie achter de nieuwe technologie uitdragen. En vooral: hierover met hun mensen in gesprek gaan. Waarom willen we dit? Wat gaat het opleveren? En wat vraagt het concreet van ons om die voordelen te realiseren? Dat kost tijd en energie, het is tegelijk de enige manier om te werken aan de gemeenschappelijke overtuiging dat deze verandering loont.
  2. Vervolgens is het goed dat de betrokken medewerkers zelf een actieve rol spelen bij het realiseren van de ‘praktische’ verandering. Dat is iets anders dan key-users mee laten denken over de inrichting van een systeem. Waar het om gaat is dat teams zelf meebepalen hoe de nieuwe werkwijze het beste kan worden ingepast in hun dagelijkse routines.
  3. De derde randvoorwaarde is dat het veranderproces goed aansluit bij de dagelijkse werkelijkheid van de betrokken medewerkers. Dat gaat bijvoorbeeld om timing (wanneer is een verandering het minst verstorend, wanneer is er tijd om een training te volgen). Het kan ook over prioriteiten gaan. Zo was er een bank die vooral aandacht had voor het lanceren van nieuwe applicaties, terwijl de basissystemen om klanten te kunnen helpen steeds vaker platlagen. Voor acceptatie van nieuwe applicaties door medewerkers, was het nodig om eerst het stabiliseren van de basissystemen prioriteit te geven.
  4. Tot slot is het belangrijk dat de verandering van werkwijze goed ondersteund, gefaciliteerd en verankerd wordt. Door goede communicatie, door trainingen en door ondersteuning op de werkvloer. Maar ook door de operationele sturing in lijn te brengen met de nieuwe manier van werken. Dus: hoe kun je de doelstellingen van afdelingen zodanig aanpassen dat het juiste gebruik van de nieuwe technologie wordt gestimuleerd en beloond?

De sleutel voor verandering ligt in de lijn, niet in het project

Het zal duidelijk zijn dat deze vier randvoorwaarden grotendeels in de lijnorganisatie worden bepaald en niet in het project. Het project richt zich vaak in de eerste plaats op de technische implementatie: zorgen dat het systeem draait. De kunst is om te zorgen dat ook in de lijn de juiste dingen op het juiste moment gebeuren. Maar als het project dat niet kan doen, wie zorgt er dan wel voor?

Een oplossing is om naast de projectmanager een changemanager aan te stellen. Iemand die zich kan richten op het veranderproces in de lijnorganisatie. Iemand die lijnmanagers helpt om een heldere visie op de verandering te ontwikkelen en uit te dragen. Die signaleert wanneer er meer nodig is om te zorgen dat leidinggevenden bereid en in staat zijn om hun rol in de verandering te vervullen. Iemand die zorgt voor goede communicatie en andere interventies. En die helpt bij verankering van gewenst gedrag in de aansturing van teams.

Geef verandering de aandacht die het verdient

In een paar woorden samengevat: de veranderkant van IT-projecten is vaak veel breder is dan wat er binnen projecten  wordt opgepakt. Dat verklaart waarom die projecten vaak zo moeizaam gaan, en grote investeringen soms niet het verwachtte rendement opleveren. Ik pleit ervoor meer aandacht te besteden aan dat bredere veranderproces. Zodat medewerkers mee gaan in de verandering die nodig is, de manier van werken tijdig is aangepast en de organisatie klaar is om de nieuwe technologie te verwelkomen.

Michiel van Delden is specialist op het gebied van organisatieverandering bij Involve – specialisten in change en communicatie.

 

Kom met uw praktijkervaringen op het terrein van managen en organiseren

Deel uw kennis, schrijf 3 columns of artikelen en ontvang een gratis pro-abonnement (twv €200)

Word een pro!

SCHRIJF MEE >>

Ir. Jan G.M. van der Zanden
Lid sinds 2019
Een zeer goede analyse van wat vaak fout gaat; en de oplossing.

Ik zou dat graag nog even "theoretisch" verder onderbouwen. Bij projectmanagement (bijv. Prince 2) wordt slechts een output, projectresultaat, opgeleverd. Er wordt wel een planning gemaakt van "Benefit management", dus hoe je de baten incasseert; maar dat incasseren zelf behoort niet tot de scope van projectmanagement. Weinig mensen, en zelfs weinig projectleiders, weten dit. Laat staan dat opdrachtgevers, directeuren en lijnmanagers dit weten. En zich realiseren wat dit impliceert!

Het realiseren van de baten wordt in Programmamanagement gerealiseerd. Zie bijvoorbeeld MSP, Managing Succesful Programmes https://www.axelos.com/certifications/propath/msp-programme-management.

In MSP wordt expliciet de Business Change Manager opgevoerd, die er voor verantwoordelijk is om de baten van het programma te realiseren. Een cruciale taak, die buiten de scope van projectmanagement valt. Doe je dat niet, dan mislukt je project vrijwel zeker; c.q. levert niet de geplande baten uit de businesscase op. In masterclasses Portfoliomanagement, Programmamanagement en Projectmanagement (https://www.ncoi.nl/opleiding/masterclass-programmamanagement.html ) wijs ik hier altijd zeer nadrukkelijk op.

Ik hoop dat vooral overheden hier ook nog eens heel goed naar kijken; want juist dat gaat daar heel vaak vreselijk mis.

Een waarschuwing over "meedenken van teams" tijdens de ontwikkeling is wel op zijn plaats.

Gebruikers hebben heel vaak onvoldoende abstractieniveau om de nieuwe/verbeterde processen en bijbehorende ICT functionaliteiten te visualiseren en dus als specificaties aan IT-ers door te geven. Daarom is dit heel vaak een extreem zwak punt in ontwikkeltrajecten; maar zelfs ook in implementatie trajecten van standaard software, waarvan de parameters netjes moeten worden ingesteld op basis van die specificaties. Ook daarvoor is een 100% scherp beeld noodzakelijk van hoe de nieuwe werkwijze er uit moet gaan zien. Is die kennis er niet, dan leidt zowel ontwikkeling als implementatie van nieuwe SW tot een grote teleurstelling.
Het is dus van cruciaal belang dat er zowel
1. een verantwoordelijk gehouden business change manager aanwezig is,
2. als een proceseigenaar/senior user/product owner die echt voldoende abstractievermogen heeft, de strategie en tactiek van de organisatie begrijpt en dit kan vertalen naar nieuwe processen, taken van medewerkers en de daarvoor optimale ondersteunende functionaliteit van software (schermen, invoer, uitvoer, etc.)
Leon Dohmen
Pro-lid
Hoi Michiel,

Het kan ook zo maar zijn dat het nieuwe systeem krakkemikkig is of dat het nieuwe systeem slechter is dan dat de mensen al gebruiken. Dat laatste speelt vaak bij fusies of overnames waar omwille van standaardisatie het overgenomen bedrijf gedwongen wordt het systeem te gaan gebruiken van het aankopende bedrijf. Er zal dan weinig enthousiasme zijn bij het overgenomen bedrijf. Een change manager zal dit niet kunnen compenseren. Ik vind een change manager in het algemeen geen goed idee. Veranderkunde dient een integraal onderdeel te zijn van de competenties van een projectleider.

Het idee dat het lijnmanagement een prominente rol moet spelen bij het invoeren van een nieuw IT-systeem ondersteun ik. Dit is zelfs een cruciale voorwaarde voor acceptatie van het systeem. Een afdelingsmanager heeft ooit eens tegen me gezegd, bij het invoeren van een nieuw ERP-systeem, dat hij in het begin van het project niet goed begreep waarom hij zich hiermee moest bezig houden. Pas gedurende het project werd dit voor hem duidelijk. Hij vond het geen leuk werk maar voelde zich in de loop van het project er (steeds meer) verantwoordelijk voor dat zijn afdeling het systeem op de juiste manier ging gebruiken. In totaal waren (+/-) acht afdelingsmanagers betrokken bij het project waarbij elke manager voor een module of deel van het ERP-systeem verantwoordelijk was.

PS: Leuk om weer eens te lezen over IT-projecten :-)
Michiel van Delden
Auteur
Dank Jan van der Zanden, eens met je onderbouwing. Ik denk dat zelf bij programmamanagement geldt dat lijnmanagers zich in elk geval verantwoordelijk moeten voelen voor het realiseren van de voordelen van nieuwe technologie. Simpelweg omdat zij leiding geven aan de veranderingen in de werkwijze van hun mensen. Dat mensen het lastig vinden om die vooraf echt in detail te doordenken herken ik ook. Ik denk wel dat het mogelijk is als je dat meer in die teams zelf doet en het goed begeleidt. Nu worden er vaak key users ingezet in een programma, en die hebben idd vaak niet het overzicht.
Michiel van Delden
Auteur
Dank Leo Dohmen, en herkenbaar dat er altijd gedoe is rond ERP systemen bij de integratie na overnames. Ik ben het ook wel met je eens dat projectmanagers zelf change management zouden moeten kunnen doen, maar in de praktijk botst het toch heel vaak met hun rol. Change management is voor een belangrijk deel: procesbegeleiding en ondersteuning van lijnmanagers. Een projectmanager moet in de eerste plaats de 'harde implementatie' opleveren, dus die is druk met sturen op tijd, geld, kwaliteit, deliverables. Mijn ervaring is dat alles wat er in de staande organisatie moet gebeuren er dan vaak bij inschiet, of zelfs buiten scope worden verklaard. Of: dat een projectmanager niet de positie heeft om zich daar ook mee te bemoeien.

Meer over Verandermanagement