Es geht hier in erster Linie um Entwicklungsprojekte, wenn von Programmieren die Rede ist. Die meisten IT-Projekte sind aber Integrationen und Migrationen (hoffentlich auch). Diese gehorchen etwas anderer Regeln, als Entwicklungsprojekte. Es gibt drei Bestände, die einander beeinflussen – Work in Progress, relevantes Wissen und Issuelist. Während der Arbeit am Projektgegensatand nimmt das Wissen zu, was dazu führt, dass die Anforderungen und Ziele konkretisiert werden werden. Dies geschieht mit Hilfe einer Issuelist, die wiederum zu neuer Arbeit führt.
Fischhoff et al zeigten bereits 1978, dass es unmöglich ist, Anforderungen und Ziele so zu formulieren, dass von Anfang an klar ist, was erreicht werden soll. Man zeigte Testpersonen schematische Zeichnungen vom Innern von Autos und fragte nach dem Grad der Vollständigkeit. Kriterium war, ob ein Auto, das so gebaut war, wie auf der Zeichnung dargestellt, starten könnte. Die Testpersonen hatten die Aufgabe, die Zeichnungen zu vervollständigen, falls das Auto so nicht starten könnte. Niemand war in der Lage, die Aufgabe zu 100% zu lösen. Viele merkten es nicht einmal, wenn sogar Hauptbestandteile fehlten, wie Einspritzung oder Treibstoff.
Das zeigt, wie schwierig es ist, aus dem Nichts heraus eine Spezifikation zu schreiben. Sei es das Verfassen eines Pflichtenheftes oder das Erstellen einer Installationsanleitung, immer werden wahrscheinlich wichtige Details vergessen.

Aufgepasst mit Methodologien! PM Ansätze und Methodismus können die Wahrnehmung (z.B. von drohenden Risiken) einengen und so die Achtsamkeit einschränken. Auf alle Fälle bringen sie Vereinfachungen mit sich und verhindern (zeitraubendes) Nachdenken über das Mögliche. Mehr Denken, weniger Methoden!

Dietrich Dörner sieht “Versuch und Irrtum” als letzten Ausweg. Natürlich ist “Versuch und Irrtum” für den verantwortungsvollen Projektmanager ein rotes Tuch, und weder Sie, Herr SH, noch das PMI wollen wahrscheinlich diese Methode fördern. Da aber Spezifikationen nie vollständig sein können, kommt kein Projekt gänzlich ohne “Versuch und Irrtum” aus. Es hat auch Vorteile. Dörner schreibt: Probehandeln kann

Lieber Peter Addor,

den Fehler habe ich korrigiert. Änderungen sind nur durch den Administrator (sprich mich) möglich.

Was die anderen Punkte angeht, stimme ich Ihnen natürlich zu. Eine Methodik kann natürlich niemals das Nach- und Durchdenken ersetzen.

Wie Sie schreiben: Auf den Mix kommt es an!

Grüße, Stefan Hagen

Hallo Hr. Bungert,

ich stimme Ihnen voll und ganz zu. Einheitliche Bilder und dadurch ein gemeinsames Verständnis zu schaffen ist eine hohe Kunst, die aber auch im Anforderungsmanagement von großer Wichtigkeit ist.

In meiner Praxis haben sich in diesem Zusammenhang Methoden wie User Stories, Mindmapping oder der Consideo Modeler bewährt.

Beste Grüße, S. Hagen