Das Ende des Pflichtenheftes

Als konkretes Beispiel soll hier die Einführung eines Publishing-Systems im Unternehmen dienen. Der übliche Weg führt über ein Lastenheft des Kunden, anhand dessen für das konkrete System ein ausführliches Pflichtenheft erarbeitet wird. Dies ist normalerweise bei einer mittleren Installation (ca. 20 Arbeitsplätze) ein Aufwand von einigen Wochen und bei einer großen Installation (über 100 Arbeitsplätze) dauert die Feinspezifikation auch schon mal ein Jahr. In der Zeit der rasanten Veränderungen der Medienbranche ist das nicht mehr zeitgemäß. Aber wie lässt sich trotzdem noch ein “ordentliches” Projektmanagement durchführen?

Der Schlüssel dafür liegt einerseits in der Reduktion und andererseits in einer „teilagilen“ Vorgehensweise.

Reduktion bedeutet, das neue System muss nicht sofort alles leisten, was das bisherige konnte, sondern wird auf seine relevanten Eigenschaften heruntergebrochen. Die einfache Frage dahinter lautet: “Was bringt uns bei unseren internen Prozessen die größte Verbesserung bzw. den größten inhaltlichen oder finanziellen Effekt?”. Darauf konzentriert sich die Projektgruppe im ersten Schritt, Sonderlocken und barocke Auswüchse der bereits vorhandenen Software werden erst einmal nicht betrachtet.

Über agile Prozesse ist bereits einiges geschrieben worden – siehe Literaturangaben unten. Dahinter steckt das Prinzip einer teambezogenen Projektaufteilung in Schritte, die aufeinander aufbauen. Das Ganze stammt aus dem Programmierbereich und wird insbesondere bei der Erstellung von Apps genutzt, weil sich damit schneller bessere Ergebnisse erzielen lassen. Was gerne übersehen wird, ist, dass die agilen Methoden wie z.B. “Scrum” [2] für kleine Gruppen und überschaubare Projekte konzipiert wurden und auch nur hier funktionieren sie, da sie viel Abstimmungsaufwand benötigen. Aber trotzdem können wir auch bei größeren Systemeinführungen diese in den Bereichen gewinnbringend einsetzen, bei denen die Spezifikationen während der Realisierung angepasst werden müssen, z.B. bei Schnittstellen.

Funktionsliste plus Schnittstellenbeschreibung statt Pflichtenheft

Ich plädiere für die folgende Vorgehensweise bei der Einführung neuer IT-Systeme:

Phase I

• Im ersten Schritt Reduktion des neuen Systems auf die für den Betrieb relevanten Funktionen
• Erstellung einer Beschreibung der Umsetzung der relevanten Funktionen in einer Funktionsliste (maximal 10 Seiten)
• Auflistung aller für Phase I relevanten Schnittstellen mit einer genauen Beschreibung der technischen Umsetzung (maximal zwei Seiten pro Schnittstelle). Alle Schnittstellen sind aus Neutralitätsgründen im XML-Format oder als API (z.B. REST) auszuführen.
• Für den ersten Teil der Systemeinführung wird ein klassisches Projektmanagement mit einer kleinen Gruppe von Verantwortlichen (Key-User) durchgeführt.
• Das System wird nur mit den relevanten Funktionen und Schnittstellen arbeitsbereit implementiert.
• Das System wird im ersten Schritt nur von den Key-Usern verifiziert und dann von einer kleinen Anwendergruppe genutzt (Reduktion auf bestimmte Funktionsbereiche).
• Danach erfolgt die allgemeine Einführung der ersten Systemversion, die die wesentlichen Funktionen abdeckt. Eventuell muss noch mit dem bisherigen System parallel gearbeitet werden.

Phase II

• Bewertung der nachrangigen Funktionen nach ihrer Relevanz
• Erstellung einer hierarchisierten Funktionsliste nachrangiger Funktionen
• Spezifikation der nachrangigen Schnittstellen mit ihren substanziellen Funktionen
• Umsetzung der nachrangigen Funktionen und Schnittstellen unter Zuhilfenahme von agilen Prozessen in kleinen Teams. Die Teams können je nach Funktion/Schnittstelle unterschiedlich aufgestellt sein. Mehrere Prozesse können mit mehreren Teams parallel laufen. Die Spezifikation kann so während der Realisierungsphase an eventuelle neue Anforderungen angepasst werden.
• Iterativ: Prüfung und Livegang der neuen Funktionen und Schnittstellen

Selbstverständlich muss vor Phase II als „Metaaufgabe” eine Schulung der agilen Methoden erfolgen. Dieser Zusatzaufwand ist aber vernachlässigbar gegenüber dem erheblichen Mehraufwand eines „großen” Projektes alter Coleur. Mit dem oben beschriebenen zweiphasigen Ablauf werden zwei Fliegen mit einer Klappe geschlagen: Der Projektablauf wird an die verfügbaren Ressourcen angepasst, ohne dass der Erfolg der Mission in Gefahr ist und der Gesamtumfang wird – da, wo es möglich ist – in mehrere Einzelschritte heruntergebrochen, die gut über agile Methoden abbildbar sind. Ein Vorteil dabei ist, dass der größte Kostenblock (Phase I) am Anfang feststeht und so die Risiken kalkulierbar sind. Für Phase II wird zuerst nur eine grobe, nach oben gerundete, Kostenplanung vorgenommen, so dass das Gesamtbudget bezifferbar ist. Ein Puffer von 20% des Budgets sollte für dynamische Erweiterungen eingeplant werden. Sollten sich die Anforderungen im Laufe des Projektes ändern, werden mit dem beschriebenen Projektablauf die Zusatzkosten in Grenzen gehalten, da sie ja nur die Phase II betreffen.

Insgesamt erzielen Sie mit dieser Methode bei begrenzten Ressourcen schneller und kostengünstiger die gewünschten Ergebnisse bei der Einführung eines neuen Systems, allerdings mit dem – meist verschmerzbaren – Nachteil, dass das neue System am Anfang nicht vollständig implementiert ist.

Der Autor Dipl.-Ing. Michael Stühr (Geschäftsführer der MarkStein Software GmbH, Darmstadt, und ehemaliger Verleger) lehrt agile Methoden zur Konzeption crossmedialer Publikationen an der Hochschule Darmstadt.

Zweitveröffentlichung des Beitrags (Quelle) mit freundlicher Genehmigung von Markstein.