Wer in einem Unternehmen ein Veränderungsprojekt umsetzen möchte - sei es die Einführung einer neuen Software oder die Umstrukturierung von Prozessen -, muss damit rechnen, dass nicht alle Betroffenen "Hurra" schreien und mit anpacken. Zwar gibt es meist viele Personen, die das Vorhaben unterstützen - manche Mitarbeiter, Abteilungsleiter oder Manager stehen der Veränderung aber misstrauisch oder sogar ablehnend gegenüber. Es ist wichtig, diesen so genannten "Skeptikern" hohe Aufmerksamkeit zu schenken, denn sie können das Veränderungsprojekt behindern oder sogar gefährden, insbesondere wenn sie viel Einfluss im Unternehmen haben.

Als Change Managerin habe ich viele Skeptiker getroffen und gelernt, wie man am besten mit ihnen umgeht, um das Risiko für das Projekt gering zu halten. Im Folgenden stelle ich verschiedene Typen von Skeptikern vor und beschreibe Maßnahmen, um sie doch noch für das Projekt zu gewinnen oder - falls das nicht möglich ist - ihren negativen Einfluss auf das Projekt zu minimieren.

Skeptiker - Risiko für das Projekt

Skeptiker bremsen Entscheidungen und verzögern Entwicklungen. Sie kosten Zeit, Geld und Nerven. Deshalb muss man sie ernst nehmen. In jedem Organisationsentwicklungsprojekt gibt es Promotoren, Mitläufer und Skeptiker. Meiner persönlichen Erfahrung nach richtet sich ihre Anzahl nach der Gauß'schen Normalverteilung: Ca. 80% der Mitarbeiter laufen mit, ca. 10% laufen vorweg und unterstützen das Projekt von sich aus, und ca. 10% sind Skeptiker. Die genaue Anzahl der Skeptiker spielt aber in der Praxis keine Rolle. Denn es kostet mehr Aufwand, den einen Skeptiker, den es auf jedem Projekt mindestens gibt, ins Boot zu holen, als die mittleren 80% am Laufen zu halten.

Der hohe Arbeitsaufwand darf Sie nicht davon abhalten, sich angemessen um die Skeptiker zu kümmern. Unterschätzen Sie den menschlichen Faktor in Veränderungsprojekten nicht! Ängste, Bedenken und Unsicherheiten können dazu führen, dass Mitarbeiter sich gegen das Projekt stellen. Bei größeren Veränderungen müssen Sie die Vorbehalte der betroffenen Mitarbeiter deshalb thematisieren.

Ein Beispiel aus dem wahren Leben

Ein Konzern führte in seiner wichtigsten Landesgesellschaft SAP ein. Drei Monate vor der Umstellung lief alles gut - nur der E-Commerce-Status leuchtete rot. Das System musste dringend mit dem Kunden getestet werden. Doch der lokale Projektverantwortliche für E-Com lehnte ab: Das Projekt unterliege der Geheimhaltung, außerdem habe der zuständige Kundenbetreuer panisch abgewinkt, als er ihm mitgeteilt habe, das Projektteam wünsche sich ein Meeting mit dem Kunden. Woche für Woche verging und dem Projektteam lief die Zeit davon.

Als ich in das Projekt einstieg, hatte ich schon einiges über die Verzögerungsversuche der lokalen Kollegen gehört. Der Frust im Projektteam war deutlich spürbar, besonders bei den E-Com-Leuten. Über den Vertriebsleiter lernte ich den Kundenbetreuer kennen und fragte ihn geradeheraus, wieso es nicht möglich sei, mit dem Kunden ein Meeting abzuhalten. Der Mann fiel aus allen Wolken. Keiner hatte ihm gesagt, dass die neue Software-Verbindung mit dem Kundensystem getestet werden musste, um sein Geschäft zu sichern. Der lokale Projektverantwortliche hatte also nie mit ihm gesprochen. In der folgenden Woche fuhren drei Mitarbeiter des E-Com-Teams mit ihm zum Kunden und die Tests wurden aufgesetzt. Die Sorge des lokalen Projektverantwortlichen darüber, dass die Geheimhaltung aufgeflogen war, wischte der Geschäftsführer vom Tisch - schließlich wüsste sowieso schon der ganze Markt, dass das System geändert werde.

Warum hatte der lokale Projektverantwortliche das Projekt behindert? Wie sich herausstellte, hegte er starke Vorbehalte gegen die Einführung von SAP, die neuen Prozesse und die Eingliederung seiner IT-Abteilung in die Abhängigkeit der deutschen Zentrale. Er hatte viel zu verlieren, u.a. seine Unabhängigkeit als lokaler IT-"Fürst" und seinen Expertenstatus auf der vorherigen Anlage. Seine Vorbehalte kommunizierte er aber nicht offen. Deshalb sah niemand in ihm einen Projektgegner oder hielt es für notwendig, seine Aussagen zu überprüfen. Der lokale Projektverantwortliche konnte mit seiner Verzögerungstaktik fortfahren. Dabei betrieb er eine Art Vogel-Strauß-Politik: Wenn wir dem Kunden nichts sagen, dann findet auch kein Systemwechsel statt. Und vielleicht kann die neue Software nicht alles, was die alte konnte - und alles bleibt beim Alten.

Skeptiker erkennen

Oft sind Skeptiker Menschen, die schon länger in der Firma oder in ihrer Position arbeiten. Sie kennen die Abläufe und die inoffiziellen Wege der Organisation und haben vielleicht bereits einige Umstrukturierungen oder Neueinführungen mitgemacht. Wenn es gelingt, solche Mitarbeiter und Führungskräfte für das Projekt zu gewinnen, hat man wertvolle Verbündete. Allerdings bedeutet es für den Projektleiter oder Change Manager meist harte und zähe Arbeit, den Einwänden der Skeptiker zu begegnen. Essentielle Voraussetzung: Man muss erst einmal erkennen, dass ein Mitarbeiter ein Skeptiker ist. Das erfordert in erster Linie Zeit. Das Vorgehen lässt sich in zwei Phasen unterteilen:

1. Die Anfangsanalyse

Zu Beginn eines Veränderungsprojekts findet in der Regel eine Anfangsanalyse statt. Hierbei prüft man, welche Auswirkungen die geplanten Veränderungen haben und gewinnt eine Übersicht darüber, welche Abteilungen, Bereiche oder Einzelpersonen von den Veränderungen profitieren bzw. für wen überwiegend Nachteile entstehen, beispielsweise ein höherer Arbeitsaufwand durch zusätzliche Datenpflege oder der Verlust des Expertenstatus oder der Entscheidungsmacht.