Im einfachsten Fall lässt sich die Einführung einer neuen Software per Knopfdruck bewerkstelligen, ganz buchstäblich. Die IT Administration de-installiert die alte Software oder aber setzt die Zugangsrechte der bisherigen Nutzerrechte zurück. Die neue Software wird installiert, die Geschäftsprozesse und Aufgaben lassen sich nur noch mit der neuen Software erledigen. Das ist Change Management mit der Brechstange – aber es gibt kein Risiko des Scheiterns, da Mitarbeiter nicht in alte Routinen zurückfallen können, denn die dazugehörige Software ist nicht mehr im Zugriff.
Selbstverständlich lässt sich ein solch brachiales Vorgehen in Unternehmen (mit Ausnahme kleinerer Softwareanwendungen) nicht beobachten. Es passt nicht zur heute verbreiteten Unternehmenskultur, die auf kooperativen Führungsstil setzt, gesprächsbasierte Entscheidungsfindungen und insgeheim vielleicht auf so etwas wie Schwarmintelligenz. Nicht zu vergessen: Die Reibungsverluste wären zu hoch. Ein systematisches Change Management setzt bereits sehr früh ein und durchläuft – kurz zusammengefasst – folgende Phasen:
- (a) Gemeinsame Zielfindung und Formulierung einer Zielvision,
- (b) Einbindung von Repräsentanten aller betroffenen Prozesse für die Anforderungssammlung (Lastenheft) bzw. eine Softwareauswahl,
- (c) Einbindung dieser Repräsentanten in den Feinspezifikationsrunden mit dem externen Softwarehaus und schließlich
- (d) Vorbereitung und Durchführung zielgruppenspezifischer Schulungen,
- (e) Support und Sammlung von Feedback aus der praktischen Anwendungen für mögliche Erweiterungsentwicklungen.
Der Vollständigkeit halber sei darauf hingewiesen, dass Projekt Manager solcher Softwareprojekte (denen die Verantwortung für das Change Management häufig zufällt) auch die Koordination mit dem Datenschutzbeauftragten bzw. Compliance Officer zufällt; die Bestimmungen des DSGVO zum Datenschutz sind weitreichend und sollten von Anbeginn an berücksichtigt werden. Ebenso mögliche Mitspracherechte des Betriebsrats, sofern ein solcher im Unternehmen besteht; sofern Software etwa mitarbeitsspezifische Auswertungen zu Leistung oder Arbeitsqualität zulässt, ist im Regelfall mit schwierigen Diskussionen im Betriebsrat zu rechnen.
Die Kernherausforderung ist häufig die Kommunikation, genauer: die Herstellung einer gemeinsamen Sprachebene zwischen Managern mit fachlicher Verantwortung und IT Entwicklern. Ein häufig zu beobachtendes Kernproblem bei der Verständigung besteht darin, dass zu wenig Geduld für die Vermittlung von fachlichen Details bei den Anforderungen aufgebracht wird, auch Lastenhefte mit einer didaktisch unglücklichen Struktur zur Vermittlung von Geschäftsprozessen an fachliche Laien. Eine gern wiederholte Forderung bzw. Erwartung seitens der Linienmanager (also: Manager mit fachlicher Verantwortung im Unternehmen) ist etwa diejenige, dass man mit Softwarehäusern / IT Entwicklern mit einschlägiger Erfahrung auf dem fachlichen Gebiet zusammenarbeiten solle. Das ist zwar grundsätzlich eine nachvollziehbare Forderung, übersieht aber einen entscheidenden Punkt: In dem Moment, wo IT Entwickler im Projekt auftreten, handelt es sich (a) entweder um eine Auftragsentwicklung oder (b) das Customizing einer Standardsoftware.
In beiden Fällen gibt es also unternehmensspezifische Prozesse, die offenbar nicht durch Standardsoftware abgebildet werden bzw. nicht den Standardeinstellungen entsprechen. Gerade in diesen Fällen besteht ein hoher Bedarf, unternehmensspezifische Workflows detailliert zu erläutern und insbesondere auf Ausnahmefälle hinzuweisen. IT Entwickler landen häufig im Dilemma des „Ich-weiß-nicht-was-ich-nicht-weiß“, während Linienmanager bei Erläuterungen zu viel Wissen bei ihrem Gesprächspartner voraussetzen bzw. einige Details ungesagt bleiben. Die detaillierte Anforderungsspezifikation und Sicherstellung eines gemeinsamen Verständnisses über die Anforderung kann zwar ermüdend sein; in der Softwareentwicklung gilt jedoch, dass ein Fehler umso größere Kosten verursacht, je früher im Prozess er begangen wird. Das heißt umgekehrt: mit einer sehr sorgfältig ausgearbeiteten (und dann auch teuren) Anforderungsspezifikation spart man am Ende Geld. Und Zeit – auch wenn zwei Wochen zusätzliche Zeit für eine Feinspezifikation zunächst wie eine Projektverzögerung aussehen im Vergleich zu einem Start mit einem So-La-La-Lastenheft.
Was Projektmanager zudem beachten und in den Griff bekommen müssen, ist das Risiko eines gegenseitigen Misstrauens. Dies beschreibt der erfahrene Change Management Berater Winfried Berner mit folgenden Worten: „Die IT-Leute, die das Projekt ja hinterher realisieren müssen, machen sich größte Sorgen, dass ihnen die Linie so viel an „überflüssigen Sonderlocken“ in die Spezifikationen schreibt, dass das Projekt hinterher vor Komplexität und Kosten kaum noch handhabbar ist, und erst recht nicht in dem Zeit- und Budgetrahmen, den der Vorstand zuzugestehen bereit scheint. Umgekehrt befürchten die Linienmanager, dass die IT’ler ihre Anforderungen nicht wirklich verstehen (wollen), sondern hauptsächlich daran interessiert sind, ihnen eine möglichst simple, standardisierte Lösung unterzujubeln.
Die Leute aus dem Business wiederum tun sich schwer, ihre operativen Anforderungen in Specs zu übersetzen, und erst recht sind sie aus naheliegenden Gründen unsicher, ob ihre Anforderungen mit dem, was da niedergelegt wurde, wirklich vollständig beschrieben sind. Zudem fühlen sie sich überfordert, so weit im Voraus alle wesentlichen Aspekte einzubringen, und haben Angst, sich mit ihrer Unterschrift für alle Zeiten festzulegen und später keine Möglichkeit mehr zu haben, neue Erkenntnisse, und seien sie auch noch so wichtig, in das System einzubringen. Dass die Befürchtungen beider Seiten in aller Regel wenigstens teilweise berechtigt sind, macht den Dialog nicht leichter.“ (vgl. den Artikel „IT-Systeme: Vier Schwerpunkte für das begleitende Change Management“).
Es wäre fahrlässig zu behaupten, für diese Herausforderung gäbe es ein einfaches Patentrezept. Tatsächlich benötigt der Projektmanager ein besonderes kommunikatives Talent und ein sehr tiefes Verständnis für die betroffenen Geschäftsprozesse. Und mindestens in Grundzügen die Möglichkeiten und Grenzen der eingesetzten Informationstechnologie – mindestens aber ein technisches Grundverständnis, um im Projektverlauf von den IT Entwicklern entscheidungsrelevante Informationen aufnehmen und berücksichtigen zu können.
Wenn agile Projektmanagementmethoden zum Einsatz kommen (vgl. dazu einschlägige Beiträge in dieser Artikelsammlung), dann ist die Angst seitens der Linienmanager gemindert, anfangs übersehene Anforderungen im Projektverlauf noch einbringen zu können. Das agile Projektmanagement darf aber keinesfalls zu einer schlampigen Anforderungsspezifikation führen, im Geiste von: „Wenn wir etwas vergessen haben, dann können wir das später ja noch ergänzen.“ Der Anspruch einer vollständigen Anforderungsspezifikation (wenn auch bei grober Beschreibung) muss unbedingt aufrecht erhalten werden, hier muss der Projektmanager Disziplin einfordern.
Wenn die Software dann am Ende des Entwicklungs-/QA-Prozesses wirklich gut gelungen ist und sogar eine intuitive Nutzung erlaubt, dann kann man den Roll-Out Prozess auch sehr kurz halten: Wie eingangs erwähnt einfach die alte Software abschalten …
„The world is moving at 105.441 km/h. Keep up!“
CNN, amerikanischer Nachrichtensender (aus: „next practice: Erfolgsreiches Management von Instabilität“ von Peter Kruse.)
