in Anforderungsanalyse, Fallbeispiel, Praxistipps

Wie bringt man ein Projekt zum Abschluss, wenn es kein Pflichtenheft gibt?

Wie oft habe ich schon gehört, man müsse dem dauernden „Wünsch dir was“ der Anwender endlich Einhalt gebieten. Sie sollen sagen was sie wollen und nicht dauernd neue Anforderungen einwerfen, so werden wir ja nie fertig. Zweifellos kann man nicht in Produktion gehen, bevor die Anwendung eine hinreichende Stabilität erreicht hat, das gilt sowohl für die Features aus fachlicher Sicht als auch für die technische Umsetzung. Daher gibt es die „Freeze“-Phasen, zuerst Anforderungs-Freeze, dann Code-Freeze. Zum Schluss werden nur noch schwere Fehler korrigiert. Wer kann dagegen sein, es so zu machen? Natürlich niemand! Hat jemand schon erlebt, dass der ausgerufene Freeze tatsächlich eingehalten wurde? Im Prinzip schon, wenn man ein paar Ausnahmen als Bestätigung der Regel akzeptiert.

Ich habe selbst schon auf diesem Weg Projekte zum Abschluss gebracht, allerdings habe ich dabei auch eine Erfahrung gemacht, die vom Common Sense etwas abweicht. Ich meine nämlich, dass es vom Reifegrad der Anwendung abhängt, ob neue Anforderungen auftauchen oder nicht. Ab einem gewissen Zeitpunkt gehen die Change Requests wie von selbst dramatisch zurück, wenn man nämlich die Anforderungen hinreichend verstanden und umgesetzt hat. Vorher kann man alles versuchen, es ist vergeblich. Es liegt also meist nicht an der Begehrlichkeit der Anwender, wenn man nicht zu einem Ende kommt, sondern an objektiven Mängeln dessen, was man bisher im Projekt geschaffen hat.

Mein erstes größeres IT-Projekt übernahm ich als Krisenmanager, weil es einfach nicht  gelingen wollte, eine Abnahme zu erzielen. Immer tauchten neue Punkte auf, die noch fehlten oder nicht passten. Ein Pflichtenheft gab es zwar, nur hatte sich die Anwendung schon so weit von den dort niedergeschriebenen Vorgaben entfernt, dass eine Berufung darauf nach hinten los gegangen wäre: ich war nämlich Mitglied der Geschäftsleitung der Firma, die das System zu entwickeln hatte und man hätte uns mit Recht vorwerfen können, das Pflichtenheft nicht beachtet bzw. es nicht aktualisiert zu haben. Das wäre nochmals Mehraufwand gewesen, den uns natürlich niemand bezahlt hätte. Was also tun? Ich erfand das Konstrukt der „vorläufigen Abnahme“ mit folgendem Briefing an die Anwender auf Kundenseite: „Wir wissen, dass Sie das System noch nicht abnehmen werden, weil noch Punkte fehlen oder nicht passen. Aber wir schauen uns jetzt alles gemeinsam an und halten fest, was sie daran hindert, eine Abnahme durchzuführen.“ Und das funktionierte tatsächlich. Wir bekamen so ein Pflichtenheft mit einer endlichen Liste von noch zu erledigenden Anpassungen und Erweiterungen, die mussten wir abarbeiten und dann klappte es tatsächlich mit der Abnahme. Budgetär war das Projekt natürlich kein Erfolg für uns, aber dafür war ich nicht verantwortlich, ich hatte die Never-Ending-Story zu einem Abschluss gebracht, das war ein Erfolg, mehr war nicht mehr drin.

Ein anderes Mal kam ich als externer Projektleiter auf Zeit in ein Projekt, das durch beachtliche Termin- und Budgetüberschreitungen in die Krise geraten war. Der bisherige Projektleiter hatte das Handtuch geworfen. Ziel des Projektes war die Entwicklung und der Rollout einer umfangreichen Softwarelösung für einen wichtigen Unternehmensbereich. Die Entwicklung der Software lag in den Händen eines Tochterunternehmens, das wiederum den größten Teil des Auftragsvolumens an einen externen Subunternehmer vergeben hatte, der daher für den Erfolg des Projekts bestimmend war.

Aufgrund der aufgetretenen Verzögerungen und Budgetüberschreitungen waren alle Beteiligten unter Druck. Die Versuchung, diesem Druck durch Schuldzuweisungen zu entkommen, war groß, das Klima im Programm und im Projekt entsprechend belastet. Eine intensive und konflikthafte Auseinandersetzung mit Change Requests war das dominierende Thema der Projektarbeit, als ich meinen Job antrat. Die Erwartung an mich war, endlich das Entstehen von Change-Requests zu stoppen, vor allem dadurch, dass ich das „Wünsch Dir was“ der Anwender unter Kontrolle bekomme.

Was war aber das wirkliche Hindernis für einen Konsens über die noch offenen Anforderungen zwischen Anwendern und der IT? In einer Reihe von Vier-Augen-Gesprächen zeigte sich, dass die „Lieferanten“ die mangelnde Disziplin der Anwender bei der Kontrolle des Scopes und die daraus resultierenden Change-Requests als zentrales Problem klassifizierten, die „Anwender“ hingegen sahen die mangelnde Eignung des bisher gelieferten Systems für den praktischen Einsatz als KO-Kriterium.

Die Frage nach einem Pflichtenheft oder einer anderen Art von Anforderungsdefinition ergab, dass es zwar ein Pflichtenheft gab, dieses jedoch aus Sicht der Anwender gravierend unvollständig war. Aus diesem Grund war es auch nie abgenommen worden, galt also offiziell als vorläufig und sollte in der Projektarbeit konkretisiert werden.

Der Engpass waren also die gegensätzlichen Situationsbeschreibungen von „Lieferanten“ und „Kunden“. Während die Software-Entwickler davon ausgingen, dass die Anforderungen klar seien und nur noch Change Requests gegenüber dieser Anforderungsdefinition zulässig seien, versuchten die Anwender mit Hilfe  von Change Requests die nicht vorhandene Anforderungsdefinition zu ersetzen. Was für die einen Changes (also Zusatzanforderungen) waren, war für die anderen unverzichtbarer Teil des Projektscope. Man hielt die Teile in der Hand, es fehlte aber eine Gesamtsicht.

Als Maßnahme zur Krisenbewältigung wurde daher eine (neuerliche) Phase der Anforderungsanalyse eingeschoben. Diese war zwar schwer durchzusetzen, weil ja offiziell alles klar war, aber unverzichtbar für den Erfolg, wie sich später bestätigte. Die Analyse wurde in einer kleinen Gruppe im Dialog abgewickelt, die Kommunikationswege wurden verkürzt, die Ergebnisse in Textform für alle verständlich dargestellt (es war letztlich das, was man ein Fachkonzept nennt). Auf der Seite der Lieferanten wurde eine Zwischenebene eingespart. Diese war vor allem mit der Identifikation von Change Requests und deren Bepreisung beschäftigt gewesen und hatte peinlich darauf geachtet, dass kein direkter Kontakt zwischen Anwendern und Entwicklern stattfand. Das Klima der Zusammenarbeit verbesserte sich signifikant und nachhaltig, aus dem Gegeneinander wurde durch den direkten Kontakt immer mehr ein Miteinander. Am Ende konnte der GoLive in einem akzeptablen Termin- und Budgetrahmen geschafft werden.

Ohne einen Schritt des bewussten Zurückweichens hinter verhärtete Argumentationslinien wäre in beiden Fällen ein Abschluss noch lange nicht gelungen.

 

Schreibe einen Kommentar

Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.