Widerständen bei Softwareprojekten erfolgreich begegnen
In den seltensten Fällen wird der Erfolg von Softwareprojekten durch funktionale Mängel der Software oder fachlich inkompetente Projektmitarbeiter gefährdet. Der Widerstand kommt vielmehr von Rechthabern, Besserwissern und Schlechtrednern im Projektumfeld. Wie erkennen Projektverantwortliche den im Verborgenen schlummernden Widerstand und wie gehen sie richtig damit um?

Georg Kraus und Tobias Götz

        


 
eit Jahren schon gehen Softwareeinführungen oft einher mit Budgetüberschreitungen, zeitlichem Verzug oder gar dem kompletten Stopp des Projektes. Schuld ist in den wenigsten Fällen die fachliche Inkompetenz der Projektmitarbeiter oder externer Systemintegratoren. Auch die funktionalen Mängel der Software sind selten die Ursache für das Scheitern von Projekten.

Dies zeigt die Studie von Datamonitor (März 2002), nach der ein Drittel der Projekte nicht die geplanten Budget- und Zeitgrenzen einhält. Wiederum war nur bei 31 Prozent dieser Projekte ein Zeitverzug durch technische Probleme festzustellen, der Rest war entweder eine Mischung aus technischen und nicht-technischen Problemen oder völlig von den Problemen der Soft- und Hardware unabhängig (54 Prozent).

Bereits 1995 führte eine Untersuchung der Standish-Group zu einem ähnlich fatalen Ergebnis: nur 16 Prozent der untersuchten Projekte wurden innerhalb der geplanten Zeit- und Budgetrestriktionen erfolgreich beendet, ein Drittel wurde gar ganz eingestellt.

Es stellt sich die Frage nach den Ursachen und darauf selbstverständlich nach möglichen Gegenmaßnahmen.
Warum sind Softwareprojekte seit je her in diesem extremen Maße in ihrem Erfolg gefährdet? Um diese Frage ausreichend zu beantworten, muss in einem ersten Schritt der Charakter von Softwareprojekten betrachtet werden.

Softwareprojekte...

:: greifen in bestehende Abläufe, Strukturen und Prozesse ein und verändern diese.
:: haben meist Kosteneinsparungen und Effizienzsteigerungen zum Ziel.
:: schaffen Transparenz über Abläufe und vereinfachen Datenzugriffe und Auswertungen.
:: haben in den meisten Fällen einen direkten Einfluss auf den Ablauf des Tagesgeschäftes der User des Systems.

So werden oft jahrelang festgefahrene Macht- und Informationsstrukturen aufgebrochen. Die Mitarbeiter eines Unternehmens müssen einerseits einen Teil ihres Informationsmonopols aufgeben und zum anderen sich mit neuen Strukturen und Abläufen vertraut machen. Dies ist zum einen unbequem und zum anderen gefährdet das Ziel der Effizienzsteigerung bei der Softwareeinführung in vielen Fällen den eigenen Arbeitsplatz. Oft entsteht bei Mitarbeitern eine Abneigung gegen die Einführung und dieser Widerstand ist kontraproduktiv.

Um Aussagen über praxisrelevante Widerstände und deren Ursachen treffen zu können, wurden in einer Untersuchung1 Personen über ihre Erfahrungen befragt. Die berufliche Position der Teilnehmer reicht von IT-Projektleitern über IT-Berater bis hin zu Geschäftsführern mittelständischer IT-Unternehmen. Unter den beteiligten Unternehmen fanden sich z.B. DaimlerChrysler, KPMG, SAP, Hewlett Packard und die Dresdner Bank.

Die Unternehmen sind entweder IT-Beratungshäuser mit einem entsprechenden langjährigen IT-Beratungs-Know How oder aber große Konzerne, welche eine hausinterne IT-Abteilung besitzen.

Welche Formen des Widerstandes treten in der Praxis auf?
In einem ersten Schritt wurde untersucht, welche Arten von Widerständen an die Oberfläche treten. Hier sind die verdeckten Widerstände von offenen zu unterscheiden. Um das Verhalten der betroffenen User besser zu verstehen, stellt sich die Frage nach den Symptomen und schließlich nach den Tools und Methoden, die angewendet werden können, um diesen Widerständen zu begegnen und ihnen entgegenzuwirken.

Verdeckte Widerstände:

Verdeckte Widerstände äußern sich nicht durch eine eindeutig ablehnende Haltung, sondern durch subtilere Verhaltensweisen der Betroffenen.

Eine der am häufigsten auftretenden Verhaltensweisen ist hier das Zeigen von Unflexibilität gegenüber der neuen Bedienungsfunktionalität der Software, dem Leben neuer Geschäftsprozesse oder der gewollten Verlangsamung der persönlichen Auffassungsgabe. Eine verdeckte Art des Widerstandes, die sowohl verbal wie nonverbal stattfinden kann, ist die Berufung auf die eigene Unfähigkeit. Das kann sich äußern in Aussagen wie z.B. »Dafür bin ich nicht ausgebildet«, »Im alten System war das einfacher«, »Das überfordert mich«. An dieser Stelle besteht die Schwierigkeit in der Trennung zwischen der wahren Überforderung und der vorgeschobenen Unflexibilität.

Das wohl für die Veränderung gefährlichste und am schwierigsten zu identifizierende Symptom tritt auf, wenn ein Mitarbeiter seinen Vorgesetzten gegenüber große Motivation für das Projekt zeigt, unter Kollegen oder Untergebenen seinem verborgenen Unmut freien Lauf lässt und so zu einem »Widerständler im Verborgenen« wird. Dies führt zu Intrigen. Dagegen tritt das Schüren von Widerstand im eigenen Einflussbereich bei den großen Projekten nicht so stark in den Vordergrund wie bei den kleineren und mittelgroßen Projekten.
Dies lässt sich unter anderem dadurch begründen, dass es sich in einem großen Projektumfeld schwieriger gestaltet, Gleichgesinnte zu identifizieren.

Diskussionen und Meetings bezüglich der Einführung der Software können erheblich belastet werden, wenn bei einer oder mehreren Personen eine »Rechthaber-Mentalität« auftritt. Dies kann sich auch in den berühmten Killerphrasen »Das bringt sowieso nichts«, »Das hat alles keinen Sinn« etc. niederschlagen. Dieses Phänomen bezeichnen wir hier als »Besserwisserei«. Auch diese Form des Widerstandes ist recht bedeutsam.
Hingegen finden sich sehr proaktive verdeckte Widerstandsformen wie absichtliche Missverständnisse, bewusste Untergrabung der Effizienz der Software durch z.B. fehlerhafte Bedienung in der Praxis weniger.

Offene Widerstände:

Die zweite Kategorie des Widerstandes beschreibt die Verhaltensweisen, die sich ganz offensichtlich gegen das Projekt der Softwareeinführung richten.

»Schlechtreden« bei Mitarbeitern und Vorgesetzten. Ähnlich dem verdeckten Widerstand des verborgenen Schürens von Widerstand ist diese Form auch als offener Widerstand denkbar, wenn das System in der Öffentlichkeit, also auch bei den Vorgesetzten und nicht hinter vorgehaltener Hand, »schlechtgeredet« wird. Im Unterschied zur mündlichen Beschwerde ist dieses Vorgehen nicht auf einen Verantwortlichen konzentriert, sondern sehr breit in seiner Streuung und vielzählig in Bezug auf die Anzahl der Adressaten. Dieser Aspekt ist in Projekten die ausgeprägteste Form des Widerstandes.

In nur kurzem Abstand folgen die mündlichen Beschwerden.
Einer der offensichtlichen offenen Widerstände ist das Äußern von mündlicher Kritik am System. Hier nicht im Sinne konstruktiver Kritik, mit der Absicht, das System verbessern zu wollen, sondern destruktiv. Dieses Verhalten verlangt keine große Planung oder Vorbereitung, wie z.B. das Aufsetzen von kritischen destruktiven Schreiben, kann aber fast zu jeder Zeit und Gelegenheit – je nach Sprachgewandtheit – angewendet werden. Auch die nachdrückliche Suche und Berichte von Fehlern im System kann den Erfolg der Softwareeinführung verhindern. Ob die Fehler nun tatsächlich softwareseitig verursacht sind oder nur durch einen Bedienungsfehler zustande kommen, soll an dieser Stelle nicht weiter untersucht werden.

Indem der Endanwender immer wieder neu nach Schwachstellen im System forscht und beim Auftreten von Fehlern auf diese bei jeder Gelegenheit ausdrücklich hinweist, wird das System immer mit einer Aura der Fehlerhaftigkeit behaftet sein.

Dasselbe gilt auch für die schriftliche Kritik, wobei hier angemerkt werden kann, dass eine schriftlich aufgesetzte Beschwerde immer mehr Einsatz und Überwindung kostet als eine mündliche Beschwerde und daher nicht so häufig anzutreffen ist.

Auch das aktive Fernbleiben von Schulungen oder Meetings spielt in der Praxis eine eher untergeordnete Rolle.

Falsche oder mangelhafte Auskünfte über eigene Prozesse ⁄ Anforderungen, das bewusste Verhindern der Weitergabe wichtiger Informationen und offene Aggressionen sind in Projekten dagegen wenig anzutreffen.

Ursachen von Widerständen
Als eine Hauptursache von Widerständen sind verschiedene Formen der Angst auszumachen. Sei es die Schwächung der eigenen Macht, das Offenlegen von persönlichen Schwächen oder die Angst vor materiellem Verlust – alle diese Ängste können Ursache für die oben genannten Widerstandsformen sein.

Eine Eigenschaft von Standardsoftware ist, dass Daten schnell für Zugriffsberechtigte zur Verfügung stehen, womöglich gleich grafisch aufbereitet. Das ist für die Zugreifenden auf der einen Seite erfreulich, kann aber auf der anderen Seite bei denen, die früher über diese Daten verfügt haben, zu einem Machtverlust führen.

Das Wissen ist nun nicht mehr bei ihnen gelagert, sondern lediglich durch Sicherheitsbeschränkungen im System vor unberechtigtem Zugriff geschützt. Diese Angst vor der Transparenz und dem Machtverlust ist – je nach Art des einzuführenden Systems – meist sehr stark vorhanden.

Ein Hauptthema im Bereich der Ängste ist an zweiter Stelle die Angst vor der Überforderung der individuellen Fähigkeiten. Insbesondere bei älteren Endanwendern ist diese Angst verstärkt ausgeprägt.

Im Gegensatz zur Angst vor der überforderung geht es bei der Angst vor dem persönlichen Misserfolg gegenüber anderen nicht primär um die Angst vor der Komplexität des Systems, sondern um die Angst, die eigene Unfähigkeit anderen gegenüber zeigen und einräumen zu müssen. Diese kann z.B. an einem Einzelarbeitsplatz weniger ausgeprägt sein als in Großraumbüros.

Die nun folgenden Ängste spielen eine eher untergeordnete Rolle in Softwareprojekten:

:: Angst vor Mehrarbeit: Die Befürchtung, nach der Einführung des Systems mehr Arbeit zu haben als vorher mit dem alten System oder der alten Arbeitsweise.

:: Angst vor der Offenlegung abteilungsweiter Schwächen: Genauso wie die Ängste im zwischenmenschlichen Bereich ist auch die Angst vor dem öffentlichen Bekanntwerden abteilungsweiter Schwächen denkbar.

:: Die Angst vor Kontaktverlust (durch vermehrte Bildschirmarbeit nimmt der persönliche Kontakt zu den Kollegen ab) hat in der Praxis keine Bedeutung.

Die Angst vor der Transparenz des Systems und der damit möglicherweise verbundene Machtverlust ist eines der Hauptthemen, das in allen Fällen dominiert. Diese Angst erscheint typisch für die Einführung von Standardsoftware. Da in den allermeisten Fällen ein oder mehrere Softwaresysteme bereits in Verwendung sind, der offensichtliche Unterschied zu einem integrierten System wie dem einer Standardsoftware liegt aber in einer Trennung der Wissensbereiche. Eine Standardsoftware hingegen hebt diese Grenzen, die meist auch Abteilungsgrenzen sind, auf.

Die Angst vor Kontaktverlust durch vermehrte Bildschirmarbeit hingegen ist heutzutage nicht mehr akut, eben aus demselben Grund eines bereits vorhandenen Systems.
Die Angst vor der Mehrarbeit steht vor allen Dingen bei großen Projekten an. Ein Berater nannte dafür den Grund, dass sich bei kleinen Projekten der Sinn und Zweck des Systems aufgrund der geringeren Anwenderzahlen besser vermitteln lassen und dadurch die Hoffnung auf Unterstützung in der Ausführung des Tagesgeschäftes größer ist.
Dieser Aussage gegenüber steht allerdings die hohe Bewertung der Angst der Überforderung bei kleinen Projekten.

Sind die Ängste begründet?
80 Prozent aller Befragten beurteilten die Ängste vor Überforderung und Misserfolg als begründet und berechtigt. Ursache hierfür sind die komplexen integrierten Softwarelösungen.

Für ein tiefgreifendes Verständnis im Umgang mit dem System ist ein ganzheitliches, prozess- und abteilungsübergreifendes Wissen nötig. Dies ist in den wenigsten Fällen vorhanden und wird auch bei Schulungen und Trainings nicht vermittelt.
Die Ängste vor dem Positions- oder Arbeitsplatzverlust seien im Rahmen von Restrukturierungen durchaus berechtigt, Ursache hierfür sei die »Shareholder Value« Einstellung der Unternehmen.

Fehler des Managements
Für den Softwareerfolg ist auch die richtige Unterstützung des Managements unabdingbar. Auch hier können Fehler gemacht werden, die dann bei den Betroffenen Ängste hervorrufen können.

Um schnell Erfolge vorweisen zu können, wird Wert auf einen Zeitplan gelegt, der sich später oft als zu knapp herausstellt. Es müsste eigentlich von vornherein klar sein, dass in der vorgegebenen Zeit die Ziele nicht oder nur unzureichend erreicht werden können. Dies ist der – gepaart mit dem Problem unzureichender Ressourcen innerhalb des Projektteams – am häufigsten auftretende »Fehler«, den das Management bzw. die Entscheiderebene begeht.

Aber auch die eigene Kompetenz zur Planung, der Aufstellung eines detaillierten Projektplanes und definierter Meilensteine ist oft mangelhaft.

Diesem Themenbereich folgt dicht darauf der nächste: Es wird nicht erkannt, dass die Endanwender das wichtigste Glied in der Kette des Implementationsprozesses sind und diese in den Prozess aktiv eingebunden werden müssen. Der Endanwender bekommt die Software als fertiges Produkt zur Bedienung vorgesetzt. Damit fühlt sich der Anwender überfahren und in seiner eigenen Kompetenz gekränkt.

Einher damit geht auch die unzureichende oder fehlende professionelle Vermarktung des Systems. Das Marketing während der Einführung in Bezug auf den Endanwender kommt zu kurz. Dem Management fehlt das Verständnis, dass die Software den Betroffenen schmackhaft gemacht werden muss.

Erstaunlicherweise treten Probleme wie die zu starke Orientierung an Beratern und die Einführung eines Systems, das der Unternehmenskultur entgegensteht, gegenüber den oben genannten eher in den Hintergrund.

Usernähe der Unternehmen
Nach der Durchführung der Interviews lagen neben den quantitativen Rankingdaten qualitative Daten in Form von strukturierten Mitschriften vor. Außerdem wurden nach jedem Interview die persönlichen Eindrücke über die befragte Person und das Unternehmen (die Interviews fanden in den Räumlichkeiten der Unternehmen statt) schriftlich festgehalten.

Die themenbezogenen Äußerungen und Ergänzungen sind in den entsprechenden Kapiteln aufgenommen worden. Hier soll es nun darum gehen, einen Gesamteindruck zu ermitteln und zu bewerten. Dieser soll durch einzelne Zitate aus den Interviews beispielhaft erläutert werden.

1. Einbeziehung Enduser nicht sinnvoll, gefährdet Projekterfolg:
Der Enduser wird während der Implementation nicht beachtet. Er wird eher als Störfaktor gesehen.

2. Neutral:
Das Unternehmen steht dem Endanwender während der Implementation weder positiv noch negativ gegenüber, seine Beteiligung wird für den Projekterfolg nicht als bedeutend eingestuft.

3. Verstärkte Einbeziehung wünschenswert, aber Kosten ⁄ Nutzen nicht verständlich zu machen, keine Tools vorhanden:
Das Individuum (die befragte Person) sieht die Relevanz der Einbindung des Endanwenders, aber es besitzt nicht die Macht oder Fähigkeit, dies seinem Unternehmen zu vermitteln. Auch fehlt es an konkreten Tools und Methoden.

4. Im Unternehmen hat man sich Gedanken gemacht, aber konkrete Maßnahmen fehlen:
Hier existiert nun auch im Unternehmen (z.B. aufgrund von Projekten der Vergangenheit) eine Sensibilisierung gegenüber dem Endanwender, z.B. fanden auch schon Workshops zu diesem Thema statt, aber entweder es fehlt intern an den nötigen Ressourcen oder, wenn das Unternehmen eine externe Beratung ist, dem Kunden ist die Einbindung des Anwenders nicht zu verkaufen.

5. Einbeziehung notwendig und wird praktiziert, d.h. Tools vorhanden: In diesem Fall liegen Methoden-Tools vor, die auch entsprechend genutzt werden.

Zitate und Anmerkungen
Um die Ergebnisse der obigen Darstellung zu unterstreichen und die Auswertung einsichtig zu machen, sollen an dieser Stelle Einstellungen und Denkweisen der Interviewpartner anhand von im Verlaufe des Interviews gefallenen Bemerkungen verdeutlicht werden.

Auf die Einbindung der User angesprochen, reagierte ein IT Projektleiter einer großen IT Beratung mit den Worten:
»Basisdemokratie bringt nichts«.

Ein anderer Projektleiter erklärte Change Management Methoden für »in der Praxis nicht relevant«.

In Bezug auf den Endanwender auf der unteren Hierarchiestufe wurden über folgende Aussagen die Einstellungen deutlich:
»Der Enduser ist grundsätzlich primitiv«, »Der Anwender ist der mit den Knubbelfingern und der Bierflasche in der Hosentasche.«

Andere wiederum sahen die interne Vermarktung der Software als »nicht so wichtig« an. »Bei uns schafft man Akzeptanz über Lösungen. Deswegen stellt sich diese erst im Laufe der Zeit ein«.

Ein Projektleiter in einem großen Konzern beschrieb seine Situation wie folgt: »Im Projektteam hatten wir eine super Stimmung, aber diese auf den Anwender zu übertragen ist uns nicht gelungen.«

Fazit
Widerstand ist ein alltägliches Phänomen, das bei jeder Art von Veränderung auftritt, egal, ob diese offensichtlich richtig und notwendig sei oder nicht.
Auch in Bezug auf Softwareeinführung ist immer mit Widerstand zu rechnen.

Gerade weil das Auftreten von Widerstand in gewissem Rahmen als normal anzusehen ist, ist das Ausbleiben desselben eher ein Grund zur Besorgnis. Es ist dann damit zu rechnen, dass ein Großteil der von der Softwareeinführung Betroffenen von vornherein nicht an eine Verwirklichung des Projektes glaubt.

Da eine Softwareeinführung fast grundsätzlich mit Zeitdruck verbunden ist, besteht die Gefahr, die Form des Widerstandes nicht zu erkennen, unbewusst nicht zu beachten oder bewusst zu überspielen, um einer Korrektur des Zeitplanes oder der Maßnahmen vorzubeugen. Wenn Widerstand auftritt, muss dieser erkannt und sensibel darauf reagiert werden, da sonst Blockaden vom Enduser im besten Fall zu Terminverschiebungen, im schlechtesten zum Abbruch der Implementation führen können.

Die Kunst des Managements von Softwareeinführungen besteht darin, den mit Sicherheit auftretenden Widerstand zu erkennen und adäquate Methoden zu wählen, um den Widerstand in konstruktives Handeln umzusetzen. Hier scheint es bei vielen Projekten jedoch noch großen Handlungsbedarf zu geben.  

 

1 Untersuchung von Kraus & Partner, 2001
 

URL: http://www.perspektive-blau.de/artikel/0411b/0411b.htm