Der Code hat über die Jahre gelitten, die technischen Schulden sind zu hoch: es ist keine Bewegung mehr möglich. Jetzt ein Relaunch!

Es lauern Stolperfallen auf dem Weg.

Die folgend aufgeführten Pattern beziehen sich auf den Umgang mit fachlichen Anforderungen und die für den Relaunch gewählte Projektmethodik.Technische Implikationen sind nicht explizit aufgeführt, sondern ergeben sich implizit.

Ein Relaunch ist kein Ziel, sondern eine Maßnahme

Vielen Projektteams und Auftraggeber glauben, dass der Relaunch das eigentliche Ziel sei. Das ist es aber nicht. Durch den Relaunch soll ein technisches oder fachliches Defizit behoben werden. Dieses Defizit ist zu benennen. Und fürs Projekt ist dies in ein Ziel umzuformulieren. Gleichzeitig ist festzulegen, welches Ziel allgemein mit der Plattform verfolgt wird. Diese formulierten Ziele sind gegeneinander abzuwägen und zu priorisieren.

Erfolgt dies nicht, fehlt fürs gesamte Projekt die Möglichkeit zur Priorisierung von Vorgehensmodellen und Features. Das Relaunch-Team wird sich voraussichtlich verzetteln und wird nicht oder nur verspätet liefern.

Alle haben sich an die alte Plattform gewöhnt. Die Software tut. Das Aufschreiben der User Stories ergibt sich durch Abklicken der Software. Wählt das Relaunch-Team dieses Vorgehen, machen sich zwei mögliche Gefahrenfelder auf:

1. Jedes Feature, also auch die selten oder gar nicht genutzten Features, wird in den Relaunch übernommen. Da kein fachliches Ziel für den Relaunch formuliert wurde, können Features nicht priorisiert und ggf. eliminiert werden.
   Die Anforderungsübernahme wird so unübersichtlich, da alle Features die gleiche Prio in sich tragen.
   Maßnahme: Für fachliche Klarstellung sorgen: was ist das Ziel der Plattform? Features sichten & priorisieren, ggf. aus Relaunch herausnehmen.
2. Features tragen - womöglich über mehrere Komponenten hinweg - versteckte Businesslogik in sich. Die Anforderungsaufnahme erscheint auf den ersten Blick sehr einfach. Beim ersten internen Beta-Test kommt der große Aufschrei: Feature XY ist für die Firma überlebenswichtig. So geht es nicht. Der notwendige Umbau ist grundlegend.
   Maßnahme: Die Businesslogik gemeinsam mit den Stakeholdern dechiffrieren. Und das Ergebnis in die Anforderungen einarbeiten. (D.h. für jedes Feature wird der User Story die Begründung vorangestellt, warum das Feature benötigt wird. Auf diesem Weg kann das Relaunch-Team die versteckte Businesslogik erkennen.)

Ausgelöst wurde das Bestreben zum Relaunch durch eine Featureanforderung, die auf Grund technischer Schulden oder einer veralteten Software-Plattform nicht mehr gelöst wurden konnte. "Wenn das der Auslöser ist, gehört das mit in den Relaunch. Und ABC und DEF auch."

Neue Anforderungen setzen implizit eine hohe Priorisierung - insbesondere der Auftraggeber hält diese Feature für sehr wichtig. Der Wunsch, dieses Feature "früh" zu sehen, sorgt für weiteren Priorisierungsdruck.

Maßnahme: Neues, gewünschtes Feature wird im Sinne der Zielsetzung der Plattform geprüft und priorisiert. Entsprechend der Einordnung wird es in den Anforderungskatalog aufgenommen und bearbeitet - oder eben nicht.

Das Team hat festgestellt, dass vieles vorher nicht gut lief. Und deswegen wird alles neu aufgesetzt: Kern-Teammitglieder und Projektvorgehen ändern sich. Und sorgt für den Second System Effect (Wikipedia)? Überplant, zu voluminös, nicht wartbar. Diese technische Wahrheit gilt auch fürs Projekt und Projektvorgehen.

In der ersten kritischen Projektsituation knallt es gewaltig - und das gesamte Team fällt in alte Muster zurück. Nichts ist gewonnen. Und ein unmotiviertes Team weiß nicht, welches Projektvorgehen das Richtige ist.

Maßnahme: Die Veränderung von Team und Projektvorgehen erfolgt Schritt für Schritt. Das Team entscheidet sich bewusst für veränderte Methodenbausteine.

Die alte Plattform ist über Jahre gewachsen. Der Feature-Katalog ist groß. Die versteckten Anforderungen in der Überzahl. Der Wunsch, jetzt alles auf einmal zu lösen, macht den Relaunch zu einem sehr großen Projekt. Große Projekte sind schwerer zu steuern als kleine. Das Risiko fürs Scheitern wächst.

Maßnahme: Fachliche Komponenten entdecken, System entkoppeln. Schrittweise Relaunch durchführen. Kleinere Happen sind erfolgversprechender!

1. Mit einer klaren Zielsetzung der Plattform, welche sowohl die fachlichen als auch die technischen Ziele beschreibt, startet das Team in den Relaunch.
2. Aus der Zielsetzung für die Plattform leiten sich die Priorisierungen der Features ab.
3. Das Team klärt das Projektvorgehen transparent im Rahmen der regelmäßigen Retrospektive ab. Änderungen im Projektvorgehen werden  Schritt-für-Schritt und mit Ruhe vorgenommen. Mögliche Auswirkungen werden beobachtet und reflektiert.
4. Der Relaunch selbst wird ebenfalls Schritt für Schritt - also komponentenweise - vollzogen.

Folgt man diesem Modell, hat der technische Relaunch eine gute Chance auf Erfolg!

• Nächster Artikel: Aufgaben des Projektmanagements
• Vorheriger Artikel: Projektplanung mit Change Requests