Wie man beim Go-Live nochmals ins Straucheln kommen kann

Das Projekt ist gut gelaufen, die erstellte Software erfüllt die Anforderungen der Anwender und jetzt geht es „nur“ noch darum, diese aus der Entwicklungs- und Testumgebung in die Produktivumgebung zu transferieren, die Daten aus dem Altsystem zu übernehmen und dann freizuschalten. Da kann doch nichts mehr schief gehen, möchte man glauben. Oja, es kann! Beim Go-Live eines Projektes kann noch viel schief gehen, auch wenn vorher noch so gut gearbeitet wurde.

Hier eine Liste der Top 5 Hoppalas aus einer Vielzahl von Projekten. Die Beispiele stammen aus meiner Praxis. Manchmal ging es wirklich schief, oft gelang es gerade noch rechtzeitig, das Problem in den Griff zu bekommen.

a. Die Berechtigungen wurden nicht richtig und vollständig vergeben

Das scheint trivial, ich nenne es aber trotzdem als erstes, weil das geradezu regelmäßig passiert. Ich habe es daher fix auf meiner Checkliste und stoße mehrfach nach. Trotzdem passiert es immer wieder, wenn auch in unterschiedlichem Ausmaß. Dass bei einigen Personen irgend eine Rolle nicht zugewiesen wurde, scheint mir geradezu unvermeidbar. Wenn das großflächig passiert, ist es ein echtes Problem. Man muss daher mit entsprechendem Aufwand früh genug gegensteuern.

Besonders störend ist es, wenn das Problem bei der Schulung auftritt. Teilnehmer sind angereist, Trainer sind bereit, aber man kann nicht richtig beginnen. Außerdem bekommen die künftigen Anwender gleich ein negatives Bild vom neuen System, auch wenn das Problem garnichts mit dem eigentlichen System zu tun hat.

b. Die Schulung wurde nicht frühzeitig und umfassend organisiert

Wer, wann, von wem, mit welchem Zeitaufwand und an welchem Ort geschult werden muss, ist eine nicht zu unterschätzende Planungsaufgabe. Bei großen Anwenderzahlen und regionaler Streuung ist das eine beträchtliche logistische Herausforderung. Die Gefahr, dass man den Schulungsaufwand nach unten schraubt, weil man Aufwand sparen will, ist erheblich und rächte sich gnadenlos.

Wenn man die Logistik als gelöst voraussetzt, bleibt die Frage, wie die Schulung inhaltlich gestaltet wird. Wer kennt das neue System am besten? Natürlich jene, die es entwickelt haben! Diese Personen sind aber meist bis knapp vor der Produktivsetzung mit Entwicklungsaufgaben, Fehlerkorrekturen und Deployments ausgelastet und stehen daher nicht früh genug für eine professionelle Schulungsvorbereitung zur Verfügung. Außerdem sind diese Personen selten in der Lage, an der alltäglichen Praxis der Anwender anzuknüpfen und sie von dort aus zur Nutzung des neuen Systems hinzuführen. Die brennendsten Fragen der Anwender betreffen nur selten die Funktionalität der Software, sondern es geht um organisatorische und fachliche Fragen, zu denen nur Trainer Auskunft geben können, die aus dem Bereich der Anwender kommen.

Hier lohnt sich ein gut organisiertes und personell großzügig ausgestattetes Test-Management. Anwender, die frühzeitig in Tests aktiv waren, sind ideale Trainer. Man muss natürlich schon bei der Planung der Tests und vor allem bei der Zusammenstellung der Testteams an die Schulung denken. Was hier versäumt wurde, kann man knapp vor den Go-Live nicht mehr kompensieren.

Wenn man agil entwickelt, bekommt man die geeigneten Tester quasi als Nebenprodukt. Aber auch hier muss mit ausreichender Kapazität und gegebenenfalls regionaler Streuung gearbeitet werden, einen Erfolgsautomatismus gibt es auch in agilen Projekten nicht.

Bei sehr großen Anwenderzahlen, ich hatte einmal eine Zielgruppe von ca. 8.000 Personen im gesamten Bundesgebiet verteilt, ist E-Learning als vorgeschaltete Basisschulung ein sehr guter Ansatz. Hier gilt ebenfalls eine ausreichende Vorlaufzeit als unbedingte Voraussetzung. Dadurch kann man allerdings den Aufwand der Präsenzschulungen reduzieren und bei der Erarbeitung des E-Learnings auch Personen einbeziehen, die als Trainer nicht zur Verfügung stehen (sei es aus Zeitgründen, sei es wegen mangelnder Trainerskills).

Die Defizite einer mangelhaften Schulungsplanung lassen sich leider nicht kurzfristig ausgleichen und können den Erfolg eines bis zu diesem Zeitpunkt hervorragend laufenden Projekts zunichte machen. Allerdings kann so ein Mangel frühzeitig erkannt und korrigiert werden, wenn man das verabsäumt, handelt es sich um „einen Selbstmord mit Anlauf“.

c. Die organisatorischen Anforderungen der Umstellung wurden nicht kommuniziert

In Entwicklungsprojekten (ob es sich um Individualsoftware handelt oder um Customizing einer Standard-Software muss hier nicht unterschieden werden), konzentriert man sich auf den Zielzustand der Applikation. Wenn man es gut macht, ist damit auch ein Zielzustand der Geschäftsprozesse verbunden, jedenfalls bei den Vertretern der Anwender im Projektteam. Angesichts der vielen Herausforderungen der Entwicklungsphase gerät aber leicht in Vergessenheit, dass die künftigen Anwender diese Überlegungen nicht kennen. Auch deren Führungskräfte sind meist wenig informiert, deren Zeitbudget ist knapp und die Bereitschaft, sich mit einem Software-Projekt auseinanderzusetzen, solange die Produktivsetzung nicht direkt vor der Tür steht, ist gering.

Die Notwendigkeit der Umstellung bisher gewohnter Abläufe trifft die Anwender daher oft unvorbereitet. Auch die Schulung wird oft zu stark als Schulung zur Nutzung der neuen Anwendung gestaltet, die Umstellungserfordernisse von Ist zum Soll bleiben der Improvisationskraft der Anwender überlassen. Das überfordert diese naturgemäß und das bisher so wunderbar laufende Projekt kommt trotz gut organisierter Schulung ins Straucheln.

d. Sekundärthemen wurden vernachlässigt

Der Klassiker: die von der neuen Anwendung erzeugten Dokumente wurden nicht an die Anforderungen bzw. Möglichkeiten des neuen Systems angepasst. Mit dieser Aufgabe könnte man schon sehr früh beginnen, aber da man das ja erst ganz am Ende braucht, fallen die dafür notwendigen Ressourcen regelmäßig der Priorisierung zugunsten akuter Herausforderungen zum Opfer. So lange, bis es definitiv zu spät ist.

Zu diesen typischen Sekundärthemen gehören im anwendernahen Bereich auch Formulare, Hilfetexte, Organisationsrichtlinien, Informationen für Kunden und Geschäftspartner über Änderungen der ihnen vertrauten Abläufe und Systeme.

Im technischen Bereich zählen dazu die Konfiguration von Schnittstellen, die Übertragung von Konfigurationen aus dem Entwicklungssystem in das Testsystem und dann ins Produktivsystem und realistische Lasttests mit geeigneten Skalierungs- und Tuningmaßnahmen.

e. Die Testabdeckung war mangelhaft

Das Generieren von Testfällen, mit denen die ganze Bandbreite an Anwendungsfällen abgedeckt wird, ist eine mühsame und nicht sehr motivierende Aufgabe. Werden professionelle Testmanager eingesetzt, fehlt diesen das praktische Wissen aus der Alltagspraxis, sie sind auf Auskünfte von Anwendern angewiesen; diesen erscheint wiederum vieles so selbstverständlich, dass sie es nicht erwähnen.

Der Produktivbetrieb ist daher – nach meiner Erfahrung so gut wie immer – der erste wirklich vollständige Test. Nicht immer: ich hatte auch schon ein Großprojekt, wo wir es geschafft haben, mit ganz wenigen Fehlermeldungen durch die ersten Monate der Produktion zu kommen. Das gelang nicht zuletzt, weil wir eine Business Rules Engine einsetzten, mit der wir die Korrektheit aller Berechnungen und Geschäftsregeln parallel zur Entwicklung der Anwendung umfassend testen konnten. Solange aber diese Logik untrennbarer Bestandteil der Entwicklungsarbeiten ist, ist eine so gute Testabdeckung schon aus logistischen Gründen schwer möglich, denn ein hinreichend stabiles System steht für Anwendertests nicht früh genug zur Verfügung.

Auch hier hat ein agiles Vorgehen Vorteile, allerdings wird auch hier zu oft nicht systematisch getestet. Am häufigsten werden die „Negativ-Testfälle“ vernachlässigt, man testet, ob das System korrekte Dateneingaben und Anwenderaktionen richtig verarbeitet, man testet aber zu wenige Fälle fehlerhafter Eingaben, fehlerhaft migrierter Daten etc. Diese Lücken schlagen dann nach der Produktivsetzung unweigerlich zu.

Zusammenfassend und abschließend: So wie ein Flug erst mit einer guten Landung positiv verlaufen ist, entscheidet sich der Erfolg eines IT-Projektes erst nach der Produktivsetzung. Der Grundsatz von Stephen Covey, „Schon am Anfang das Ende im Sinn haben“, kann daher für IT-Projekte nicht genug betont werden.

Es gibt zu diesem Thema natürlich noch einige wertvolle Ressourcen im Netz. Hier eine kleine Auswahl:

Are You Ready for Go-Live? Eight Essential Questions

Project Cutover-A vital step in Project Go Live