Projekte scheitern. Das ist eine Tatsache. Auch agile Projekte scheitern. Sie scheitern aber anders als klassische Projekte. In meiner Vision möchte ich ein Szenario skizzieren, in dem ein bisher erfolgreiches Projekt scheitert. Dabei gehe ich besonders auf die Rolle einer Produktdokumentation ein, die mit der Methode CARDS+ erstellt und gepflegt wurde.

04 Vision Projektkrise

Ausgangssituation

Wir haben ein feines System, das seit fast zehn Jahren seinen Dienst tut. Es wird von seinen Nutzern nicht geliebt, aber es ist unverzichtbar. In diesen zehn Jahren wurden rund 15 große Releases erfolgreich eingeführt. In diesen zehn Jahren hat der Auftraggeber jedoch nur insgesamt zwei (!) technische Release “zugelassen”. Das System wurde jahrelang fachlich erweitert, die Anzahl der Funktionen des Systems hat sich in dieser Zeit mindestens verdoppelt. Die Anzahl der technischen Schnittstellen stieg sogar von anfangs fünf auf über 40. Mittlerweile wird es als Bestandssystem von den Mitarbeitern eines Wartungsprojektes gepflegt. Technische Schulden führen vermehrt zu Störungen im Betrieb. Die Entwickler können kaum noch Anforderungen umsetzen bzw. die Umsetzung wird immer teurer. Das Team ist entweder mit der Fehlerbehebung voll ausgelastet oder es muss aufgrund der technischen Schulden sehr viel Risiko einrechnen.

Nun kommt es zur Projektkrise. Der Auftraggeber verliert das Vertrauen in das System und damit auch in die Mitarbeiter des Wartungsprojektes. Aufgrund der anhaltenden Probleme wird auch das Management ausgetauscht. Der “neue” Auftraggeber will das System auf Vordermann bringen. Er lässt sich beraten und entscheidet sich für einen kompletten Neustart. Das System soll auf der grünen Wiese neu gebaut werden, mit einem neuen Team. Der Auftraggeber nimmt an, dass die Mitarbeiter aus dem Wartungsprojekt “ausgebrannt” und technologisch nicht mehr am Puls der Zeit sind. Sie würden den Neustart eher behindern. Der Auftraggeber möchte, dass das neue Team sowohl die Verwendung eines Standardproduktes als auch den Neustart auf Basis einer neuen Technologie prüft.

Projektinitialisierung

Der Auftraggeber startet ein Projekt mit dem Ziel, ein komplett neues System zu bauen. Es soll alle Probleme des Bestandssystem lösen. Die fachlichen Anforderungen an das neue System sind unverändert. Mit anderen Worten: Die Systembeschreibung und das Glossar gelten vorerst unverändert.

Zuvor muss das Team die Entscheidung treffen, wie das zukünftige System gebaut wird: Standardprodukt oder Produktinnovation mit neuer technischer Plattform.

ktip Der Auftraggeber hat das letzte Wort. Das Team muss eine Make-Buy-Reuse-Analyse machen – Reuse wurde vorerst ausgeschlossen. Die Analyse hat in großen Unternehmen immer eine “politische” Komponente. Hersteller von Standardprodukten haben oft ein Lobby. Auch bei technischen Plattformen hängt es oft entscheidend davon ab, welcher Software-Experte gefragt wird. Auch unternehmensweite IT-Strategien beschränken die Auswahl an Technologien.

Die Vision Produktinnovation zeigt den Wert der Produktdokumentation für den Fall, dass ein System komplett erneuert wird. Diese Plattform muss “zukunftssicher” sein. Mit der Vision Produktidee bin ich bereits auf die Frage “Was ist zukunftssicher” eingegangen.

In der Vision Standardprodukt betrachte ich den Wert der Produktdokumentation bei der Auswahl eines Standardproduktes für das neue System. Die Frage “Was ist zukunftssicher” muss in diesem Fall der Hersteller des Standardproduktes beantworten.

Projektvalidierung

Wir stehen jetzt vor der Herausforderung, eine neue technische Plattform oder ein geeignetes Standardprodukt für das Bestandssystem zu finden.

  1. Mit Hilfe der Systembeschreibung des Bestandssystems haben wir eine Reihe von Technologien evaluiert. Wir haben exemplarisch versucht, wichtige Cases mit der neuen Technologie zu lösen. Die Cases haben wir aufgrund der Einschätzung des Auftraggebers oder nicht-funktionaler Anforderung (z.B. Sicherheit, Leistungsfähigkeit) ausgewählt. Entwickler in zwei Teams haben die Lösungsansätze mit einem Showcase überprüft.
  2. Wie in der Vision Standardprodukt beschrieben, haben wird eine Variante der Systembeschreibung des Bestandssystems erstellt. Wir haben versucht, Cases mit Funktionen des Standardproduktes zu lösen.

Die Erkenntnisse aus der Umsetzung des Showcase haben wir verwendet, um mit der Schätzmethode Use-Case-Points und den Cases aus der Systembeschreibung eine grobe Schätzung für das gesamte System zu machen. Die Schätzung hilft uns einerseits bei der Auswahl der Technologien, andererseits ist es ein Anhaltspunkts für die “Größe” der Aufgabe. Der Auftraggeber ist von der erwarteten Größe der Aufgabe überrascht.

Im Fall des Standardproduktes erkennen wir, dass es eine verhältnismäßig große Anzahl Cases gibt, für die wir keine akzeptable Lösung finden. Der Auftraggeber ist jedoch nur in wenigen Fällen bereit, auf Funktionen zu verzichten.

In dieser Vision möchte ich davon ausgehen, dass wir feststellen, dass am Ende weder Make (neue Technologie) noch Buy (das Standardprodukt) eine geeignete Lösung ist.

Projektabbruch

Am Ende dieser Evaluierung steht der Projektabbruch. Der Auftraggeber hat eingesehen, dass es für seinen Problemraum (noch) kein geeignetes Standardprodukt gibt. Der Auftraggeber war einfach zu wenig bereit, seine Anforderungen an das Standardprodukt anzupassen. Auch der komplette Neustart des Systems mit neuen, modernen Technologien hat den Auftraggeber nicht überzeugt. Er sieht zu viele Risiken und zu hohe Kosten.

Dem Auftraggeber ist klar, dass es wie bisher nicht mehr weitergehen kann. Er ist aber nicht bereit, alles auf eine Karte zu setzen. Wie so oft kommt es zu einem Kompromiss. Die Mitarbeiter aus dem Wartungsprojekt und die für die neuen Technologien angeworbenen Mitarbeiter werden zu einer Projektorganisation zusammengefasst. Die Teams übernehmen die Wartung des Bestandssystems. Besonders der Abbau der technischen Schulden steht am Anfang im Fokus des Teams. Sie beginnen aber auch mit einem Refactoring des Bestandssystems mit dem Ziel, Teile des Systems herauszulösen und mit neuen Technologien zu realisieren. Das können Schnittstellen sein, das sind aber vor allem die Teile, für die Standardprodukte bisher keine Funktionen anbieten. Der langfristige Plan ist, nach Abschluss des Refactoring ein Bestandsystem zu haben, das aus einem reduzierten Kern (ein Monolith) und eine Reihe von Microservices besteht. Der Kern wird am Ende durch ein Standardprodukt ersetzt.

Fazit

Eine Projektkrise macht nie Spass. Jedes bißchen Sicherheit wird dankbar angenommen. Eine vollständige und gut gepflegt Systembeschreibung eines Bestandssystems ist so eine Sicherheit. Die Dokumentation stellt daher einen großen Wert dar. CARDS+ hilft diesen Wert zu langfristig erhalten, durch kontinuierliche Pflege auch während der Wartung. Die Dokumentation muss bereits vorhanden sein, wenn es zur Krise kommt. Denn eines ist klar: Eine Projektkrise ist in den meisten Fällen nicht geplant, sie kommt überraschend. In einer solchen Krise ist keine Projektorganisation in der Lage, eine Systembeschreibung ad-hoc zu erstellen. Eine fehlerhafte Systembeschreibung ist bei der Lösung der Probleme eher hinderlich als hilfreich, kann u.U. zu Fehlentscheidungen führen.