Dr. Reinhard Schmitt & Kollegen

Projekte aus einem Guss

von Reinhard Schmitt

Change Management, das tatsächlich Veränderung in Organisationen bewirken möchte, muss deutlich über Projekt-Marketing mittels Newsletter, Intranetseiten, Flyer, Foliensätzen & Co. hinausgehen. Andernfalls bleibt es - auch wenn es von Vielen mit dem Label Change Management überklebt wird - bei Projektmitteilungsmanagement über kommunikative Einbahnstraßen. Das Projekt führt dann Monologe. Es streut breitflächig Daten in der Annahme, dass relevante Personen diese als wesentliche Information wahrnehmen, im Sinne der Projektziele verstehen, damit einverstanden sind und aus einer grundsätzlich lernenden Haltung heraus als Wissen dauerhaft abspeichern. Da wird den Adressaten Einiges abverlangt.

Nach meinem Verständnis lebt echtes Change Management vom Dialog und folgt dabei einem kontinuierlichen Zyklus bestehend aus

  • Sammeln von Informationen - sowohl über die Inhalte der Veränderung als auch über den Kreis der Betroffenen,
  • Bilden von Hypothesen, was die mitzuteilende Veränderung bei den Betroffenen auslösen könnte und warum,
  • Planen und Durchführen situativ geeigneter Kommunikationsmaßnahmen,
  • erneutem Sammeln von Informationen über die Wirkung der durchgeführten Maßnahmen,
  • wiederum Bilden von Hypothesen ... usw.

Am Anfang eines Veränderungsprozesses ist weder planbar, wie viele Zyklen erforderlich sein werden, um die beabsichtigten Veränderungsziele zu erreichen, noch klar, welche Maßnahmen mit welchen Inhalten von wem innerhalb eines bestimmten Zyklus durchgeführt werden. Ferner ist nicht auszuschließen, dass neue Erkenntnisse, die Auftraggeber und Projektleitung aus dem Dialog mit den Betroffenen gewinnen, die Veränderungsziele verändern. Es handelt sich um einen Lernprozess für alle Beteiligten.

Damit ergibt sich unter projektorganisatorischen Gesichtspunkten häufig ein Problem. Folgt beispielsweise ein IT-Projekt dem klassischen Wasserfallmodell, kollidiert der beschriebene kontinuierliche Veränderungszyklus mit der linear angeordneten Abfolge von Projektaktivitäten (z.B. Anforderungsanalyse, Konzeptphase, Realisierungsphase, Testphase und Rollout-Phase). Dialog mit den von der Veränderung Betroffenen findet - wenn's gut läuft - am Anfang und notwendigerweise am Ende statt - was häufig schlecht läuft.

Zum einen können sich alle Beteiligten den vollen Umfang der inhaltlichen Veränderung zu Beginn des Projekts allenfalls abstrakt vorstellen. Zum anderen verändern im Zuge der Konzeptions- und Realisierungsarbeiten gewonnene Erkenntnisse den ursprünglich vereinbarten Umfang und damit die (abstrakt) erwartete Veränderung. Nicht selten entwickeln Projektteams dabei eine von den zukünftigen Anwendern entkoppelte Eigendynamik. Die Stunde der Wahrheit schlägt am Anfang der Rollout-Phase, meistens in den Schulungen. Erst jetzt wird den Betroffenen vollumfänglich klar, was an Veränderung auf sie zukommt. Akzeptanzprobleme und Konflikte treten dann geballt auf - zu einem denkbar ungünstigen Zeitpunkt, denn nach der Schulung sollte es idealerweise zeitnah an die operative Arbeit mit dem Produktivsystem gehen.

Change-Begleitung ist in solchen Projektszenarien lediglich präventiv am Anfang und kurativ am Ende möglich. Am Anfang des Projekts erschweren gefühlte Wirksamkeitsferne und Abstraktionsgrad ein zielgerichtetes Change Management. Veränderungen, die inhaltlich nicht bekannt sind, lassen sich weder vermitteln noch managen - und auch beim Faktor Mensch steckt der Teufel im Detail. Am Ende des Projekts ist der Drops inhaltlich gelutscht. Change-Management im Verlauf der Rollout-Phase wird zwangsläufig auf das Vermarkten der Bonbon-Packung und dem Verschreiben von Beruhigungspillen reduziert. Während der Konzept- und Realisierungsphase gilt das Prinzip Störet unsere Kreise nicht!. Da kommt das eingangs beschriebene unidirektionale Projektmitteilungsmanagement gerade recht - und beruhigt unter dem aufgeklebten Etikett Change Management zudem noch das Gewissen.

Zugegeben, das beschriebene Szenario ist überspitzt formuliert. Wie aber müsste ein Projekt beschaffen sein, das mit dem beschriebenen kontinuierlichen Veränderungszyklus kompatibel ist?

Das Idealszenario sähe für mich wie folgt aus:

  1. Der Projektablauf sollte ebenfalls zyklisch organisiert sein.
  2. Innerhalb dieser Zyklen werden Veränderungen auf sachlicher/fachlicher Ebene den Betroffenen so konkret und plastisch wie möglich mitgeteilt ohne dabei das Big Picture aus den Augen zu verlieren.
  3. Am Ende jedes Zyklus wird von den Betroffenen proaktiv Feedback eingeholt.
  4. Im Sinne des erwähnten Lernprozesses für alle Beteiligten sollte es möglich sein, geplante oder schon umgesetzte Inhalte infolge gewonnener Erkenntnisse aus dem Feedback anzupassen und gegebenenfalls zu revidieren.
  5. Die Disziplinen Projektmanagement, Fachberatung und Organisational Change Management arbeiten eng zusammen und stimmen ihre Aktivitäten inhaltlich und zeitlich aufeinander ab.

Projektmanagementansätze, die diesem Szenario sehr nahe kommen, sind unter dem Begriff Agile Methoden zusammengefasst. Sie werden primär in der Softwareentwicklung eingesetzt, sind meines Erachtens jedoch auf andere kreative Prozesse, an deren Ende ein abgestimmtes Ergebnis stehen soll, übertragbar. Bekannte Vertreter der Agilen Methoden sind Adaptive Software Development (ASD) oder Scrum. Sie erfüllen die ersten vier der o.g. fünf Punkte und proklamieren für sich nicht nur eine konsequente Kundenorientierung, sondern auch Offenheit für Änderungen, auf die das Team schnell reagieren muss, kann und darf.

Im Vordergrund stehen bei dieser Art des zyklischen Arbeitens inhaltliche Aspekte. Dies birgt ein Problem in sich: Je nachdem ob unter Kunde der Auftraggeber oder der Anwender verstanden wird, besteht die Gefahr, entweder an der Akzeptanz der Anwender vorbei zu implementieren oder die Ziele des Auftraggebers aus den Augen zu verlieren und letztendlich alte Arbeits- bzw. Kommunikationsgewohnheiten in neue (digitale) Schläuche zu füllen. Deshalb ist im Sinne des o.g. Punktes 5 eine moderierende, Interessen ausgleichende Change-Begleitung auch für solche Vorgehensmodelle angebracht.

Mein Ziel ist es, die drei Disziplinen Projektmanagement, Fachberatung und Organisational Change Management so miteinander zu integrieren, dass Projekte aus einem Guss entstehen. Sollten Sie ähnliche Ziele verfolgen, würde ich mich über einen Austausch mit Ihnen sehr freuen. [ Kontakt ]

Seminare zum Thema:

Einführung in das systemische Organisationsverständnis [ Info ]
Organisational Change Management [ Info ]

Themenblätter:

Organisational Change Management (OCM) [ pdf ]
OCM in IT-Projekten [ pdf ]