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.