Waarom mislukken veel projecten van software implementaties.

De opdracht

In mijn carrière als consultant en projectleider heb ik een groot aantal implementaties meegemaakt. In grotere organisaties geeft men er de voorkeur aan om een software implementatie als project aan te pakken. Dat betekent het formeren van onder andere een projectgroep en het benoemen van een intern en extern projectleider.

Het ideaal plaatje
In het voortraject waarin de business case wordt beschreven, om tot een zakelijke rechtvaardiging van het project te komen staan alle neuzen nog dezelfde kant op. Alle processen worden met aangewezen gebruikers uit de organisatie besproken en beschreven. Iedereen verleent min of meer enthousiast zijn of haar medewerking. Alles staat eigenlijk klaar om te starten en te komen tot een voorbeeldig project waarbij alles binnen geplande tijd en gepland budget wordt opgeleverd. Er zijn alleen maar winnaars. De opdrachtgever beschikt over een nieuw up to date systeem, de gebruikers mogen er mee werken ( en wie wil nou niet met een nieuw en modern systeem werken?). En tot slot de leverancier, zij hebben weer een succesvol project opgeleverd dat ook nog geld oplevert. De website kan worden aangepast, want er kan weer een mooi referentverhaal worden toegevoegd.

De werkelijkheid
Zo mooi beschreven als hierboven ontwikkelt een project zich in de praktijk eigenlijk nooit. Wat zijn hier de redenen voor? In deze blog wil ik mij alleen richten op het menselijke aspect.
Iedereen vergeet om van te voren duidelijk te maken dat we niet alleen te maken hebben met een software implementatie, maar ook met een veranderingstraject. De medewerkers van de organisatie waar de software wordt geïmplementeerd zijn gewend om te werken op een manier zoals men (meestal) al vele jaren doet. Met alle mitsen en maren die dit met zich meebrengt weet men al jaren te dealen en is het een vertrouwde omgeving. Nu wordt men min of meer gedwongen om uit de vertrouwde omgeving (comfortzone) te komen en moet men zich iets nieuws eigen maken. Voor een deel van het personeel is dit geen probleem. Deze mensen waren vaak in het voortraject ook al betrokken of zaten zelfs in de projectgroep. De medewerkers die het er juist moeilijk mee hadden dachten, het duurt nog zo lang en het zal zo’n vaart niet lopen.
Kortom, de projectgroep loopt tegen weerstand op in de organisatie. Het project loopt vertraging op. De opdrachtgever wordt ontevreden over de leverancier en extern projectleider, want zij halen hun deadlines niet. De extern projectleider is ontevreden over de intern projectleider. Deze krijgt het immers niet voor elkaar om de medewerkers mee te krijgen in het project.
En al die tijd is er niets veranderd aan de nieuw te implementeren software. Dit was immers van te voren allemaal goed in kaart gebracht en hadden we met elkaar een handtekening onder gezet. Waar gaat het in dit geval dus mis? Het menselijk aspect is onderbelicht item in een dergelijk project.

Een oplossing
Wees als leverancier of extern projectleider vooraf duidelijk tegen de opdrachtgever. Vertel wat hem te wachten staat (misschien is hij zelf één van de remmende factoren) en zeg hoe je hier op in kunt spelen.
Betrek mensen vroeg in het traject die “problemen” op latere termijn kunnen veroorzaken. Laat hen meedenken en meepraten over de keuzes die gemaakt moeten worden. Je zult zien dat mensen die eerst werden ingeschat als vertragende factor later in het project je ambassadeur kunnen zijn.