Die Situation ist angespannt. Das individuell entwickelte IT-System wird mehr schlecht als recht gewartet. Die verbliebenen Projektmitarbeiter sind kaum mehr motiviert und wollen das Projekt verlassen. Das Budget für die Wartung ist beschränkt. Die Kosten für die Wartung steigen seit Jahren kontinuierlich an. Die Gründe sind fehlende Innovationen, immer mehr technische Schulden in der Software, Wissensverlust durch Fluktuation in der Organisation und wachsende Lizenz- oder Betriebskosten.

Die Entscheidung, das Bestandssystem individuell zu realisieren, war gut begründet. Zu diesem Zeitpunkt gab es noch kein passendes Standardprodukt bzw. die verfügbaren Standardprodukte waren nicht nutzbar in dem Markt, in dem sich das Unternehmen bewegt, weil rechtliche Vorgaben nicht erfüllt werden konnten. Als weiterer Treiber für die Individuallösung kam der Wunsch nach Alleinstellungsmerkmalen dazu.

Die Situation hat sich geändert. Die Standardprodukte wurden weiterentwickelt. Sie haben mittlerweile alle Fähigkeiten, die für die Nutzung im Unternehmen gebraucht werden. Es gibt keine Alleinstellungsmerkmale mehr im Bestandssystem. Im Gegenteil. Das Bestandssystem kann schon längst nicht mehr mit den Standardprodukten am Markt mithalten.

Der Auftraggeber betrachtet das Bestandssystem mittlerweile als Risiko. Er möchte es durch ein Standardprodukt ersetzen.

Der Auftraggeber startet das Migrationsprojekt. Zuvor hat er in einem Auswahlprozess zwei Standardprodukte benannt, die für den Einsatz im Unternehmen als Ersatz für das Bestandssystem geprüft werden sollen. Das Wartungsteam wird verstärkt, damit sie neben der Wartung des Bestandssystems die zusätzlichen Aufgaben im Migrationsprojekt übernehmen kann.

Das Bestandssystem wurde mit der Methode cards+ im Wiki dokumentiert. Das Team startet daher mit der Aufgabe, die Produktdokumentation auf Vollständigkeit zu überprüfen. Weil die bestehende Software komplett durch ein Standardprodukt ersetzt werden soll, konzentriert sich das Team auf die Systembeschreibung und stellt sicher, dass jede Fähigkeit des existierenden IT-Systems mit einem Case korrekt erfasst ist. Sie finden vor allem dort Lücken, wo im Bestandssystem Sonderfälle und Besonderheiten abgebildet wurden. Gemeinsam mit den erfahrenen Nutzern schließen sie die Lücken.

Das neue IT-System muss alle Fähigkeiten des Bestandssystems besitzen. Die nächste Aufgabe des Teams ist es, für jeden Case des Bestandssystems eine korrekte Lösung in einem Standardprodukt zu finden.

• Das Standardprodukt hat für den Case eine passende Lösung. Die neue Lösung kann direkt festgehalten werden.
• Das Standardprodukt bekommt durch eine individuelle Anpassung (engl. customizing) eine passende Lösung für den Case. Die notwendigen Anpassungen werden als Anforderung dokumentiert.

Die beiden Fälle zeigen, dass das Standardprodukt in der Lage ist, das Bestandssystem zu ersetzen. Wenn das Standardprodukt für einen Case jedoch keine akzeptable Lösung hat, dann wird der Auftraggeber aktiv und trifft eine der folgenden Entscheidungen:

• Der Case wird komplett gestrichen und damit der Umfang des neuen IT-Systems reduziert. Dabei ist eine Betrachtung von Kosten und Nutzen sehr hilfreich. Die Begründung wird als Lösung dokumentiert.
• Der Case wird individuell entwickelt. In manchen Fällen übernimmt der Hersteller diese Lösung sogar in ein zukünftiges Release des Standardproduktes.
• Der Case wird durch einen neuen Case ersetzt, für den es eine Lösung mit dem Standardprodukt gibt. Der ursprüngliche Case wird ohne Lösung belassen.

Wichtig ist, dass kein Case aus der ursprünglichen Systembeschreibung gelöscht wird.

Jetzt gilt es noch die Entscheidung für das gewählte Standardprodukt zu überprüfen. Dabei spielen Kosten und Termine eine Rolle. Aber auch der Glaube an die Lösung. Eine Systembeschreibung, in der es für alle Cases eine akzeptable Lösung im Standardprodukt gibt, schafft dieses Vertrauen.

Häufig gibt es mehr als Möglichkeit, das Standardprodukt zu verwenden oder zu konfigurieren, um ein bestimmtes Ziel zu erreichen. Die Lösungen unterscheiden sich in den Kosten (z.B. Einsatz einer zusätzlich zu lizensierenden Erweiterung) oder in der Komplexität (z.B. Selbstinstallation und Betrieb im eigenen Rechenzentrum). Alle betrachteten Optionen zusammen mit der abgestimmten und begründeten Entscheidung werden mit dem Baustein Decision dokumentiert.

Manche Entscheidungen erfordern bereits einen Entwurf eines Konzeptes, dass mit dem Hersteller des Standardproduktes erarbeitet wird. Der Entwurf wird mit dem Baustein Spec festgehalten.

Zur Überprüfung der Kosten lässt sich eine grobe Schätzung mit der Methode Use-Case-Points schnell durchführen. Die Cases sind sehr gut geeignet für die Schätzmethode. Und die drei Fälle bei der Lösungsfindung lassen sich direkt als Indikator für die Komplexität verwenden. Die weiteren Faktoren werden durch die Angaben des Herstellers des Standardproduktes ermittelt. Das Ergebnis der Schätzung sind gewichtete Personentage. Klingt nicht sehr agil, ist aber beim Projektstart in vielen Situationen hilfreich.

Die neue Systembeschreibung ist gleichzeitig eine sehr gute Grundlage für die Umsetzung. Cases sind hilfreich für den schnellen Aufbau eines Backlog. Der Vorteil durch die Verwendung einer gut gepflegten Produktdokumentation ist offensichtlich: Viele fachliche Fragen können sofort beantwortet werden. Der Produktverantwortliche kümmert sich von Anfang an um die Erstellung und Priorisierung der Storys, die immer einen Bezug zu einem Case haben. Die bereits vorhandene Strukturierung der Fähigkeiten der Software mit den Bausteinen Epic und Topic ist an dieser Stelle sehr hilfreich.

Mit dem Einsatz eines Standardproduktes sind bereits alle wesentlichen Entscheidungen und Konzepte bezüglich Software-Architektur und Betrieb bereits getroffen und dokumentiert. Das Team konzentriert sich sofort auf die Umsetzung der Fähigkeiten, es braucht keinen Sprint Null. Es ist auch ein Vorteil, dass zur Klärung fachlicher Fragen das Bestandssystem herangezogen werden kann.

Trotzdem wird das Projekt die Vorteile der agilen Methoden für Anforderungsanalyse und Entwicklung nutzen. Auch die frühzeitige Umsetzung betrieblicher Aspekte des IT-Systems durch DevOps ist möglich - natürlich unter den Rahmenbedingungen des Standardproduktes.

Das neue IT-System wird sich auf jeden Fall vom Bestandssystem unterscheiden. Jede andere Annahme wäre töricht und würde den Erfolg des Projektes gefährden.

Die Methode cards+ hilft bei der Wahl des richtigen Standardproduktes. Die Systembeschreibung des Bestandssystems ist die Grundlage für die Wahl des Standardproduktes. Das Glossar ist in der Regel weiterhin gültig und hilfreich. Der Produktverantwortliche und das Team haben sehr schnell ein gut gepflegtes Backlog. cards+ hilft bei der Projektdurchführung, die neue Produktdokumentation laufend in guter Qualität zu aktualisieren. Der Fortschritt in der Umsetzung des neuen Systems spiegelt sich auch im Umfang der Systembeschreibung wider. Der Produktverantwortliche wird im weiteren Verlauf des Projektes entscheiden, ob ein Case wie im Bestandssystem umgesetzt wird oder - gut begründet - doch anders. Die Systemstruktur und der Architekturentwurf des Bestandssystems kann für das neue System nicht verwendet werden. Den Verlust kann der Produktverantwortliche jedoch leicht verschmerzen, wenn das Standardprodukt seine eigene Produktdokumentation mitbringt.