Was ich als Projektleiter heute anders machen würde

Fallstricke eines Change-Projekts – und wie Sie sie vermeiden

Teil 1: Die erforderliche Veränderung erkennen und akzeptieren
Die Zeit ist reif für Veränderung: Sie werden mit einem Change-Projekt betraut. Doch wie packt man es an? Wo lauern Fallen und wie umgeht man sie? Was braucht es, damit der Change gelingt? Roger Fischlin berichtet von Tücken und Lessons Learned aus einem für ihn lehrreichen IT-Change-Projekt. In Teil 1 bekommen Sie Einblick, wie Mitarbeiter eine einschneidende Veränderung erfahren und wie sie diese akzeptieren lernen.
Für eilige Leser (Management Summary)
Als Abonnent erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management-Summary.
Mehr Infos zum Abo oder Login.

Projekte bedeuten Veränderung. Um Menschen beim Wandel zu unterstützen, haben Projekte zunehmend Arbeitspakete "Change Management". Verdeckt durch Slogans wie "Betroffene zu Mitwirkenden machen" sind die Inhalte allerdings meist vage, am Ende bleiben Dokumente wie Stakeholder-Analyse und Schulungsunterlagen. Der Mensch ist aber keine Maschine, er kann sein Verhalten zum Stichtag nicht einfach ändern. Change Management ist weniger ein Arbeitspaket mit Liefergegenständen als vielmehr eine Kompetenz.

Ausgehend von meiner eigenen Erfahrung aus einem IT-Change Projekt stelle ich Ihnen Modelle vor, wie Menschen Veränderungen erfahren, wie sie motiviert werden, wie sie lernen und worauf es beim Führen durch Veränderungen ankommt.

Eine Veränderung bahnt sich an

Ich arbeitete vor 15 Jahren als Gruppenleiter im zentralen IT-Betrieb eines großen deutschen Unternehmens. Computerbegeisterte hatten die IT in der Dekade zuvor mit viel technischer Expertise, Enthusiasmus und Pioniergeist aufgebaut. Die Arbeit an der Anwender-Hotline war verpönt und wenn möglich kümmerte man sich lieber um technische Probleme. Die Kollegen von der IT waren als Fachleute geschätzt und wurden oft nach ihrem Rat gefragt. Sie sahen sich als IT-Experten, nicht als Dienstleister. Der IT-Leiter war die treibende Kraft beim Aufbau und so verfolgte er die Strategie der technologischen Führerschaft der zentralen IT.

Die Systeme liefen seit Jahren stabil, zusätzliche Angebote kamen hinzu. Große Neuerungen waren allerdings rar. Die Kollegen kümmerten sich vielmehr um Detailverbesserungen und die Automatisierung der Administration. Man war mit dem Status quo zufrieden und stolz auf das Erreichte.

Doch die Ruhe war trügerisch. Die Welt sollte alsbald aus den Fugen geraten. Auslöser waren technische Probleme beim E-Mail-Empfang, die wir nicht in den Griff bekamen. Die IT-Architektur war den gestiegenen Anforderungen nicht mehr gewachsen; die in die Jahre gekommenen Lösungen skalierten nicht mehr im erforderlichen Maß. Es waren grundlegende Änderungen in der IT-Landschaft und in der Aufstellung der IT erforderlich. Die Aufwände für den Betrieb der Systeme waren beharrlich gestiegen. Nun fehlten Kräfte für die Modernisierung.

Die Kritik an der IT innerhalb der Organisation verschärfte sich. Der Fokus der Vorwürfe verlagerte sich von den technischen Problemen hin zur generellen Aufstellung und dem Selbstverständnis der IT. Die Kritiker verlangten, dass wir stärker auf Standardprodukte und Managed-

Anzeige
Jetzt kostenlos weiterlesen!
Abonnenten des Projekt Magazins wissen mehr!
Starten Sie jetzt unser 4-wöchiges Kennenlern-Angebot: Die Anmeldung dauert nur ein paar Minuten – Sie können also gleich weiterlesen.
  • KostenlosDas Kennenlern-Angebot kostet Sie nichts.
  • Kein RisikoSie können jederzeit kündigen, ohne dass Ihnen Kosten entstehen.
  • Einen Monat lang alles lesen4 Wochen Online-Zugriff auf alle Inhalte des Projekt Magazins.
Tech Link