So begleiten Sie IT-Projekte mit einem runden Veränderungsmanagement. Im Blog-Artikel „Change Management wird unterschätzt“ habe ich die Notwendigkeit von Organisationsanalyse und Change Management in IT-Projekten hervorgehoben. Hier finden Sie meine 10 wichtigsten Bausteine für ein erfolgreiches Veränderungsmanagement in IT-Projekten.
Anpassungsdruck wahrnehmen
Erarbeiten Sie zunächst die externen Erwartungen und Veränderungen im Markt, die eine Veränderung Ihrer Prozesse erforderlich machen: zum Beispiel Neue Kundenerwartungen, Wettbewerb, neue Vertriebswege, neue gesetzliche Forderungen. Manchmal auch werden Veränderungen notwendig, weil im Unternehmen durch Vorgaben, Konsolidierungsrichtlinien oder Software-Migrationen sich die Bedingungen für Teams ändern. Aus der Sicht der betroffenen Führungskräfte und ihrer Leute sind auch das „externe“ Bedingungen. Wichtig ist: Veränderung braucht einen Anpassungsdruck an veränderte Umweltbedingungen. Diesen Anpassungsdruck müssen wir wahrnehmbar machen – sonst bewegt sich nichts.
Change-Projekte koordinieren
Finden Sie heraus, welche anderen Veränderungsprojekte auf die beteiligten Teams einwirken. Stellen Sie den Gesamtzusammenhang dieser Veränderungen dar und versuchen Sie gemeinsam mit den Teams, alle diese Projekte im Kontext zu verstehen. Diese Maßnahme hilft, dass Ihr Projekt nicht im Wahrnehmungspuffer der Organisation untergeht: Bei zu viel Veränderung schalten die Menschen „auf Durchzug“ oder lassen sich wie willige Lämmer zu allem treiben – nehmen aber in Wirklichkeit nichts an. (Zur Pufferkompetenz siehe mein Artikel „Weckducken als Überlebensstrategie“)
gewachsene Abläufe bewusst machen
Machen Sie die gewachsenen Abläufe in den Teams sichtbar. Die meisten Prozesse im Alltag sind den Beteiligten überhaupt nicht bewusst – sie laufen „einfach so“. Solche gewachsenen Prozesse sind schwer änderbar. Sobald wir die Abläufe bewusst machen, können wir auch über Veränderung sprechen. Prozessmodelle sind ein gutes Mittel, die subtilen Abläufe zu bewussten Prozessen zu machen.
Szenarien entwickeln
Stellen Sie dann die Optionen für zukünftige Abläufe und die bisherigen Prozesse in Szenarien gegenüber und binden Sie die Beteiligten ein. Am besten Sie verwenden dazu die BPMN als eine standardisierte Modellierungssprache, damit die Szenarien wirklich vergleichbar sind.
technisches BPMN-Modell erstellen
Wenn Sie ein organisatorisches Szenario entwickelt haben, modellieren Sie daraus die Anforderungen an die IT-Entwicklung in einem technischen BPMN-Modell. Dabei modellieren Sie die Aufgaben der Bearbeiter und die der Applikationen in getrennten Pools. Für die Entwickler einer Applikation ist dann „ihr“ Pool gleichzeitig das Lastenheft für ihre Entwicklung. So gelingt Ihnen eine sehr enge Verzahnung zwischen Organisationsanalyse und Lastenheft.
Testfälle aus dem Modell entwickeln
Das Prozessmodell liefert jetzt auch die Voraussetzung für die Konstruktion von Testfällen für die Applikation. Anhand des Modells können Sie sicherstellen, dass alle möglichen Pfade des Prozesses durch einen Testfall abgedeckt sind. Die Testszenarien für die Applikationsentwicklung ergeben sich aus der Prozessanalyse, nicht aus der Entwicklung.
Benutzerschulung aus dem Modell erstellen
Auch für die Benutzerschulung bietet das Prozessmodell den optimalen Rahmen: Der Pool für die Benutzeraktivitäten enthält alle Interaktionen zur Applikation in der sinnvollen Abfolgelogik. Hier können Sie jede Aktivität und ihre Maskendialoge prozessorientiert beschreiben.
Go Live planen
Erstellen Sie ein Migrationskonzept für den Go Live. Selbst die besten Testszenarien können nicht verhindern, dass zum Go Live noch Überraschungen in der Tüte sind.
- Halten Sie Fallback-Lösungen und Workarounds bereit, wenn in den ersten Tagen die Applikation nicht so läuft wie sie soll (sie wird es NICHT!). Wie können Anwender im Fall eines Falles noch auf alte Prozesse zurückgreifen? Wie können Bearbeitungsfälle notfalls geschoben werden, bis ein Bug repariert ist?
- Konzipieren Sie eine Pilotphase. Lassen Sie einen Teil der Benutzer mit einem Teil der Fälle live gehen und organisieren Sie die Abgrenzung. Wichtig ist hier die Vorbereitung des organisatorischen Ablaufs: Wie kann ich Bearbeitungsfälle separieren, damit in der Pilotphase die Reibung minimiert wird? Schaffen Sie ein klares Phasenmodell für die Ausweitung auf einen flächendeckenden Roll-Out.
- Sorgen Sie dafür, dass während der Pilotphase Entwicklerressourcen zur Verfügung stehen, um notfalls kurzfristig Korrekturen vornehmen zu können. Planen Sie ein zweites Release noch während der Pilotphase.
Veränderungsmanagement budgetieren
Die hier beschriebenen Aufgaben für die Anforderungsanalyse, die Testszenarien und das Veränderungsmanagement erfordern personelle Ressourcen in Ihrem Projekt. Diese Tätigkeiten binden vor allem Kräfte in den späteren Benutzerteams. Stellen Sie zu Projektbeginn sicher, dass diese Ressourcen tatsächlich zur Verfügung stehen. (Oft werden interne Personalressourcen nicht budgetiert („Eh-da-Kosten“) und dann beliebig hin- und hergeschoben).