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: ...
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.)
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 :-)