Escalatie van problemen in IT projecten

In mijn praktijk als IT deskundige wordt ik meestal ingeschakeld wanneer er al een conflict tussen partijen hoog is opgelopen. NB Dat is op zich jammer, want ik heb ideeën om conflicten te voorkomen, maar dat is voer voor een andere blog. Het dispuut tussen partijen is zo hoog opgelopen dat er een onafhankelijke derde bij wordt gehaald om het conflict te beslechten. In de meest “harde” vorm is dat een rechter, maar ook andere vormen van conflictbeslechting (mediation, arbitrage) komen voor.

Is vertrouwen tussen leverancier en afnemer terecht?

IT-projecten starten met vertrouwen, vertrouwen tussen leverancier en afnemer, tussen IT-specialist en gebruiker. Vol goede moed en ideeën wordt het IT-project gestart. Alle betrokkenen denken goed op de hoogte te zijn van wat gemaakt en geleverd moet worden, de partijen zijn positief gestemd en kijken uit naar een succesvolle oplevering en ingebruikname.

Maar toch, maar toch…

Optimistisch vooruitkijken is een goede eigenschap, maar enige vorm van realisme is, juist op dat moment, vereist.

Uit ervaring weet ik één ding zeker: het project gaat anders verlopen dan iedereen bij de start denkt, meningen tussen leverancier en afnemer, tussen IT-specialist en gebruiker, gaan in de loop van het project uit elkaar lopen. En hoe langer het project duurt, des te groter het verschil wordt. Dan ontstaan (hoogoplopende) discussies over hetgeen was afgesproken en wat de interpretatie van specificaties is. En dan ga ik nog even aan voorbij aan iets als “het is logisch dat…“, “maar dat spreekt toch voor zich dat…” of “je had kunnen weten dat…“.

Kortom: discussies die de voortgang van het project frustreren.

Een goede escalatie kan een ernstiger conflict voorkomen

Besef aan het begin van een project dat deze discussie gaat ontstaan en spreek een werkwijze af hoe met deze interpretatieverschillen wordt omgegaan: een escalatieprocedure.

Natuurlijk is een gang naar de rechter uiteindelijk ook een escalatieprocedure, maar wel een kostbare. Er zijn eenvoudiger mechanismen in het project zelf af te spreken die de gang naar de rechter voorkomen.

Is een escalatie negatief?

Escaleren heeft in algemene zin een negatieve betekenis, denk bijvoorbeeld aan: het geweld escaleerde, de ruzie escaleerde, maar in de betekenis een escalatieprocedure bij een IT-project komt het juist als een beheersbare wijze van verergeren over: het trapsgewijs verergeren. Of in de betekenis van een escalatieprocedure bij IT-projecten: het beslechten van een discussiepunt naar een hoger echelon doorzetten.

Soorten escalatieprocedures

Er zijn twee typen escalatieprocedures: functioneel en hiërarchisch.

Functionele escalatie: overgedragen aan een team met meer expertise op het betreffende gebied, bijvoorbeeld een gebruikersvertegenwoordiging, of een systeembeheergroep.

Hiërarchische escalatie: een discussiepunt wordt overgedragen aan hoger management in de projectstructuur, bijvoorbeeld de stuurgroep.

Het voordeel van een functionele escalatie is dat met meer inhoud en functionele deskundigheid naar het discussiepunt wordt gekeken, terwijl de hiërarchische escalatie al snel leidt tot het bekijken van de contractuele afspraken en financiën. Niet onbelangrijk, maar niet altijd het belangrijkste.

De beginfase van het project, als alles nog koek en ei is, is het moment om de escalatieprocedure af te spreken. Als u probeert deze afspraken te maken als er al een dispuut is, is dat gegarandeerd tot mislukken gedoemd. Dan escaleert het dispuut vanzelf, maar op een onbeheersbare wijze tot een conflict, in plaats van dat het conflict wordt voorkomen of efficiënt opgelost.

En nu?

Behoefte aan een praktische aanpak voor de opzet van een escalatieprocedure? Of een gesprek daarover? Neem contact op.

Beter vroegtijdig recht gezet, dan achteraf voor het gerecht gezet.