Das Change Management wird in IT Projekten unterschätzt. Projektmanager konzentrieren sich auf Entwicklung und Implementation. Die Übernahme einer neuen Lösung in die Organisation sehen sie eher als Schulungsaufgabe. In einem aktuellen Beratungsprojekt erlebe ich, wie sehr ein Go Live rumpelt, wenn keiner das Veränderungsmanagement auf dem Zettel hat.
Schon die Begrifflichkeit zeigt uns, wie sehr die Veränderung aus der Entwickler-Perspektive gedacht ist: Ein „Roll-Out“ bedeutet ja, dass eine fertige Lösung auf die Benutzer ausgerollt wird – vielleicht fühlen die sich auch überrollt. Dabei geht es doch darum, dass die Organisation (der Kunde!) die erarbeitete Lösung übernimmt. Beim „Übernehmen“ ist der Kunde Subjekt der Aktion, beim „Ausrollen“ bloßes Objekt.
Organisationsanalyse vor dem Projektauftrag
Jedes IT-Projekt verändert die Organisation – sonst würde es sich nicht lohnen. Isolierte technische Projekte sind die Ausnahme. Das Projekt hat die Verantwortung dafür, dass diese Veränderung für die Organisation Sinn macht und dass sie von der Organisation getragen wird. Vorausschauende Projektmanager übernehmen keine Projekte, die der Organisation gegen den Strich gehen.
In der Anforderungsanalyse muss klar werden, wo den Leuten in der Organisation wirklich der Schuh drückt. Organisationen sind nur dann in der Lage, Prozesse zu verändern, wenn sie einen Anpassungsdruck wahrnehmen. Wer mit einer Lösung ums Eck kommt, ohne dass die Leute Not spüren, wird schnell zum Verkäufer: Er muss sein Projekt schmackhaft machen.
Wer stellt schon sein eigenes Projekt in Frage?
Hier lauert eine Falle für Projektmanager (gerade in der IT): Sie bekommen den Auftrag für ein Projekt und müssen erst dann die Anforderungen erheben. Die Sinnhaftigkeit des eigenen Projekts in Frage zu stellen, ist dann kaum noch möglich. Die Analyse der Organisation und die Anforderung an die Veränderungen muss also deutlich vor dem Projektauftrag stehen – und sie wird am besten nicht vom Projektmanager betrieben.
Wir kennen das: Wer ein Projekt will, entwirft eine Projektskizze und geht damit den Weg durch die Instanzen. Er will „sein“ Projekt genehmigt bekommen und dann loszulegen. Ein „Nein“ zum Projekt wäre eine Niederlage. Also wird in Projektskizzen der Aufwand gerne schöngerechnet, damit Projekt ihr „Go“ bekommen. Kosten für Anforderungsanalyse und Veränderungsmanagement gehen dabei schon mal verloren.
Aufgaben des Veränderungsmanagement
So vermeiden Sie Überraschungen beim Go Live: Legen Sie zuerst in einer Organisationsanalyse die Engpässe offen, für die die Organisation eine Lösung braucht. Entwickeln Sie zusammen mit den Verantwortlichen die notwendigen Veränderungen in den Prozessen und leiten Sie daraus die Anforderungen an die technische Lösung ab. Erst dann schreiben Sie Ihre Projektskizze und beauftragen den Projektmanager.
Während des Projekts brauchen Sie einen Veränderungsmanager zwischen IT-Projekt und Organisation. Der sorgt dafür, dass die entwickelte Lösung tatsächlich die gewollte Veränderung in der Organisation unterstützt. Und er organisiert den Veränderungsprozess zum Go Life. So soll er sicherstellen, dass die erwarteten Nutzengewinne auch wirklich eingefahren werden. Das Projekt endet erst, wenn die neuen Prozesse in der Organisation stabil laufen.
Lesen Sie hier meine 10 Bausteine für Change Management in IT-Projekten.