Von Nichts kommt nichts

Zwar kann durchaus etwas aus dem Nichts entstehen (Energie des Vakuums), aber sicher keine vollständigen Anforderungskataloge.

Ich mache mir zuweilen einen Sport daraus, Gesprächspartner, die behaupten, dass sie mit Projekten zu tun haben, nach ihren Erfahrungen zu befragen. Insbesondere bin ich interessiert zu wissen, wie sie mit Problemen umgehen. Kaum einer will wissen, wovon ich spreche. Wenn ich erkläre, dass es doch zu Termin- und Budgetüberziehungen kommen könne, tun sie so, als hätten sie davon zwar schon gehört, aber nie selbst erlebt. Da geht es mir wie mit Autofahrern, die z.B. bei der Rückfahrt nach längeren Feiertagen im Stau stecken bleiben. Ich kenne keinen. Jeder, den ich frage, stritt bislang ab, jemals in einem längeren Stau gesteckt zu haben. Schliesslich sei das nur eine Frage der Organisation, wann man wo lang fährt. Und keiner der Autofahrer, die ich kenne, ist derart unbeholfen, z.B. nach Ostern am falschen Tag zurück zu fahren und erst noch über eine Strecke, die für Staus bekannt ist. Genauso wenig kennen ich privat Projektleiter, die in ihren Projekten Schwierigkeiten haben. Nur bei meinen Kunden gibt es schwierige Projekte. Gemäss Standish Chaos Report 2004 sind immer noch weniger als 30% aller Projekte erfolgreich1. Ich kann einfach nicht glauben, dass alle meine privaten Bekannten in diesen 30 erfolgreichen Prozente tätig sind. Aber sie sind sich alle einig, dass es bestimmt an der ungenauen Zieldefinition liege, oder – was auf dasselbe heraus kommt – an der Unvollständigkeit der Anforderungsbeschreibung.

Sie erinnern sich an meinen Beitrag Migrations- und Integrationsprojekte sind anders nach dem der Standish Chaos Report zum Schluss kommt, dass die Hauptursache von Schwierigkeiten in Projekten mangelhafte Zieldefinitionen und unvollständige Anforderungskataloge sind. Aber der Report bezieht sich auf Entwicklungsprojekte. In Migrations- und Integrationsprojekten können Ziele nie definitiv festgeschrieben werden, denn erst beim Bau eines Systems tauchen die richtigen Fragen auf, deren Antworten Teil der Zieldefinition sind. Anforderungs- und Spezifikationsänderungen durch den Kunden liegt selten an seinem Charakter. Natürlich gibt es immer wieder Leute, die aus persönlicher Unzufriedenheit oder Unentschlossenheit nie wissen, was sie wollen und ihre Wünsche laufend ändern. Hat eine solche Person beim Kundenunternehmen die „richtige“ Stelle inne, dann kann sie jedes Projekt vergiften. Letztendlich handelt es sich um ein Führungsproblem. Bevor jedoch der Projektleiter des Lieferanten eine Eskalation machen kann, muss er ein gut dokumentiertes „Sündenregister“ des Kunden-Projektleiters vorlegen können. Bis er das hat, wird das Projekt bereits sehr schief liegen. Es ist anzunehmen, dass er bis zu diesem Zeitpunkt ebenfalls Fehler gemacht hat, die ihm dann in einem unschönen Kreuzfeuer vorgeworfen werden, vielleicht sogar vom eigenen Management.

Im allgemeinen deutet Changing Requirements and Specifications auf die Tatsache hin, dass im Laufe des Projekts das Wissen über den Projektgegenstand zugenommen hat, was eine Redefinition der Ziele notwendig macht. Ein flexibler und erfahrener Projektleiter antizipiert das und sucht das Gespräch mit dem Auftraggeber. Gemeinsam müssen sie einen Weg suchen, der den veränderten Rahmenbedingungen gerecht wird, ohne dass das Projekt allzu sehr darunter leidet. Wirft der Lieferant dem Auftraggeber in einem verbockten Projekt jedoch vor, er hätte laufend die Ziele oder Spezifikationen geändert, disqualifiziert er sich selbst, indem er zugibt, die Notwendigkeit einer Reformulierung nicht erkannt zu haben.

Ein vollständiger Anforderungskatalog oder eine vollständige Zieldefinition würde bedeuten, dass der Auftraggeber im Voraus seine Bedürfnisse bis in das letzte Detail aufzählen kann. Man weiss aber schon lange, dass dies nicht möglich ist. Beispielsweise haben Fischhoff et al. Versuchspersonen verschiedene Versionen eines Diagramms gezeigt, das beschreibt, wie ein Auto funktioniert1. Die verschiedenen Versionen unterschieden sich in der Vollständigkeit. Die Versuchspersonen wurden gefragt, ob ein Auto, das gemäss diesem Diagramm aufgebaut ist, anspringen würde. Die Versuchspersonen bemerkten fehlende Teile kaum. Selbst das Weglassen so wichtiger und allgemein bekannter Teile wie Zündung und Benzinversorgung wurden kaum bemerkt. Die Versuchpersonen waren daher nicht in der Lage, lückenhafte Diagramme zu komplettieren. Wenn es also für ein im Betrieb stehendes und weitverbreitetes System wie das Auto nicht möglich ist, auch nur die primitivsten Anforderungen zu notieren, so ist es für ein noch zu entwickelndes und zu bauendes System erst recht unmöglich.

1B. Fischhoff et al. Fault trees: Sensitivity of estimated failure probabilitiesto problem representation. Journal of Experimental Psychology: Human Perception and Performance, 1978, 4, 330-334

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

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