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

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

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.

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.