Keine Rede von Change – es geht ausschließlich um Anforderungsmanagement!.

Zwar ist es natürlich legitim, Begriffe so zu definieren wie man es für zweckmäßig hält. Wenn man dabei aber einen eingeführten Begriff anders belegt als üblich, sollte man aktiv alles tun, um Missverständnisse zu verhindern – zum Beispiel durch einen aussagekräftigen Untertitel –, statt darauf zu warten, dass es die Leute schon irgendwann von selbst merken werden. Anscheinend war es in diesem Fall aber gar nicht so, dass die Autoren das Anliegen hatten, den Begriff Change Management (anders) zu verwenden; vielemehr sprechen sie in dem Buch durchgehend, konsistent und ausschließlich von Anforderungsmanagement bzw. von Änderungsmanagement. Das Wort Change Management kommt im ganzen Buch nur an zwei Stellen vor: im Titel und – in der Ankündigung des Springer-Verlags! Es scheint, als wäre erst kurz vor Veröffentlichung entschieden worden, dem Buch zwecks besserer Verkäuflichkeit einen attraktiveren Titel zu verpassen – und es so auch dem einen oder anderen Käufer unterzujubeln, der genau das sucht, was der jetztige Titel verspricht, nämlich Antworten auf die Frage: Wie gestaltet man den Informations-, Kommunikations- und Qualifizierungsprozess bei größeren IT-Projekten? Wie schafft man Akzeptanz für das neue System und setzt es gegen Widerstände durch?

Anforderungsmanagement ist durchaus ein kritisches Thema in der Softwareentwicklung: Erstens weil zwischen Auftraggeber und Projektverantwortlichen Klarheit über die Spezifikationen bestehen muss, zweitens weil man bei Softwareprojekten nicht mit dem "Big Picture" auskommt, sondern unzählige Einzelheiten und Details unter Kontrolle behalten muss, drittens weil die präzise Beschreibung der Anforderungen ein Lernprozess ist, der zu Beginn des Projektes in aller Regel nicht abgeschlossen ist. Sich mit dem Management dieser Anforderungen auseinanderzusetzen, ist deshalb nicht nur eine Sache für IT-Fachleute, sondern auch für diejenigen, die mit solchen Projekten entweder als künftige Nutzer oder als Mitglieder eines Lenkungsausschusses zu tun haben. Die Letztgenannten können sich beim vorliegenden Buch allerdings auf die ersten beiden Kapitel konzentrieren; die letzten drei sind für ihren Bedarf eher zu technisch. (Darin geht es um das "Anforderungsmanagement im Rational Unified Process", um "Anforderungsmanagement werkzeuggestützt durchführen" und um "Künftige Entwicklungen", insbesondere "Die Rolle des Internet" und "Anforderungs- und Änderungsmanagement als Kernaufgabe des Projektmanagement".)

Im einführenden ersten Kapitel (66 Seiten) gibt Gerhard Versteegen zunächst einen historischen Rückblick. Darin erläutert er "Das gute alte Pflichtenheft" und seine Schwächen, die insbesondere dessen mangelnde Eindeutigkeit und schwierige Wartung. Dann geht er auf die Vorzüge und Nachteile von Prototypen ein und kommt schließlich zur "Visuellen Modellierung" als Methode der Wahl. Im Abschnitt "Was ist Anforderungsmanagement?" erklärt er, welche Arten von Anforderungen es gibt (gerechtfertigt, überzogen, unberechtigt, optional ...) und welche Anforderungen an Anforderungen zu stellen sind. Weiter geht es um den richtigen "Umgang mit Anforderungen" und schließlich um den "Anforderungsmanager". Das klingt alles furchtbar formal und erbsenzählerisch, aber wer je mit solch einer Art von Projekten zu tun hatte, weiß, dass akribische Sorgfalt in der Methodik die einzige Chance ist, die Komplexität solcher Projekte unter Kontrolle zu behalten. Weiter geht es um die Bewertung von Anforderungen, um "Fehlermeldungen – eine besondere Art von Anforderungen" und um Anforderungstypen.

Das zweite Kapitel heißt "Wenn sich Anforderungen ändern", umfasst 35 Seiten und geht zunächst auf die Gründe für Änderungen ein. Sie können im "technologischen Fortschritt" liegen, in "Änderungen beim Auftraggeber" und in "Geschäftsprozessaspekten". Dann beschreibt er unheilsschwanger den "Dominoeffekt", den solche Änderungen auslösen können – und verwendet zur Illustration das groteske Beispiel, dass ein Bauherr kurz vor Übergabe des Hauses noch eine Tiefgarage unter seinem Haus wünscht: "Was glauben Sie, wie der Bauträger reagieren wird?" (S. 83) Schließlich geht er auf "Erste Anzeichen" drohender Anforderungsänderungen ein, zu denen er – interessant! – "externe Beratungsfirmen" ebenso rechnet wie "neue Projektmitarbeiter beim Auftraggeber" und einen Technologiewechsel beim Auftraggeber.

Welche Wut bei Versteegen Änderungswünsche auslösen, die nach seiner Meinung "aus Profilierungssucht" resultieren, zeigt sich darin, dass er zu deren Abwehr eine rhetorische Strategie empfiehlt, die Betreffenden gezielt ins Messer laufen zu lassen. Er schlägt vor, zunächst die Frage zu stellen: "Haben Sie das schon mal im Gesamtkonzept berücksichtigt?" oder: "Haben Sie sich schon mal überlegt, welche Auswirkungen Ihre Anforderung an die Architektur der Software hat?" Diese Frage, so schreibt er, "hat bisher jeden Profilierungssüchtigen in zwei verschiedene Argumentationsebenen getrieben: Bescheidenes Eingestehen der mangelnden Weitsicht (...) [oder] Aggressivhaltung: Der Mitarbeiter merkt zwar, dass er sich auf relativ dünnem Eis bewegt, doch er tritt die Flucht nach vorne an: Er bezweifelt alles und macht sich damit insbesondere gegenüber seinem eigentlichen Arbeitgeber unglaubwürdig. Für den Anforderungsmanager bedeutet das, den Mut oder die Selbstüberwindung aufzubringen, diesen Mitarbeiter vor seinem Vorgesetzten zu blamieren – keine einfache Aufgabe, aber wirkungsvoll! Letztlich hängt sein eigener Erfolg davon ab, inwieweit er den anderen 'ruhig' stellt." (S. 89f.) In der Fußnote fügt er hinzu: "In der Tierwelt würde man diese Vorgehensweise als die Macht des Stärkeren bezeichnen." (S. 90)

Angesichts dieser Empfehlung fällt mir ein Buchtitel des geschätzten Tom DeMarco ein: "Warum ist Softwareentwicklung so teuer?" Einer der Gründe liegt wohl darin, dass alle technischen Fähigkeiten von begrenztem Wert sind, wenn man so mit Menschen umgeht. Denn natürlich kann man darauf wetten, dass der so abgestrafte Mitarbeiter alles in seinen Möglichkeiten Stehende tun wird, um diesen grandiosen Anforderungsmanager scheitern zu sehen. Ein bisschen "Change Management bei Software-Projekten" würde hier vielleicht doch gut tun, denn auch Softwareentwicklung ist am Ende ein sozialer Prozess – und eine wichtige Aufgabe der Projektverantwortlichen wäre deshalb, diesen Prozess möglichst reibungsfrei und konstruktiv zu gestalten, statt aktiv zur Erzeugung von Reibungsverlusten beizutragen.