Von Tom Gob habe ich wieder mal einen interessanten Link zugeschickt bekommen: „Projekte scheitern am Anforderungsmanagement„. Es geht um die Bedeutung eines professionellen Anforderungsmanagements in IT-Projekten. Viele der Erkenntnisse können jedoch auch auf andere Projektarten umgemünzt werden, denn unklare Ziele und Anforderungen sind in fast jedem sehr vielen Projekten ein Problem.
Die Ergebnisse sind wenig überraschend. Fast alle Befragten halten das Anforderungsmanagement (Requirements Engineering) für sehr wichtig, trotzdem gehen nur die wenigsten wirklich systematisch vor. Viel zu schnell wird umgesetzt und programmiert – unendliche Änderungsschleifen sind die häufige Folge. Die Kosten explodieren, die Zeitziele werden immer wieder nach hinten verschoben.
Noch einige ergänzende Links zu dem Thema:
Vortrag Anforderungsmanagement
Ich hab’s ja immer schon gewusst 😉
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.
Hallo Hr. Addor, vielen Dank für diesen tollen Kommentar.
Ich finde, die praktischen Herausforderungen, die Sie beschreiben, sind ein weiterer Grund, warum agile PM Ansätze und Methodologien (wie SCRUM etc.) in der Praxis immer wichtiger werden – nicht nur in der Softwareentwicklung.
Grüße in die Schweiz!
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
Kann man Kommentare nicht editieren? Natürlich muss es heissen: „…und weder Sie, Herr SH, noch das PMI wollen wahrscheinlich diese Methode fördern“.
Bitte verstehen Sie mich richtig: Methoden erachte ich als sehr nützlich und Trial and Error ist wirklich nur mit Vorsicht einzusetzen. Der moderne PM muss eben wissensbasiert an die Probleme heran gehen und Systemisches Denken, TRial and Error und Methodik im genau richtigen Mix anwenden.
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 Herr Addor und Herr Hagen,
dieser Thread ist jetzt zwar schon fast zwei Jahre alt, aber immer noch aktuell. Ich möchte ihn gerne nochum einen Punkt ergänzen, der mir sehr wichtig ist. Vor dem Management der Anforderungen müssen diese erst einmal entwickelt werden. Entwickeln heisst, sie aus einem oder mehreren Köpfen herauszubekommen und so zu formulieren, dass alle das gleiche verstehen.
Bei einem Haus oder einem mechanischen Bauteil ist das noch verhältnismäßig einfach. Man kann sowas ja anschauen und jeder sieht dann dasselbe. Aber wer hat schon mal eine Applikation gesehen? Oder einen Geschäftsprozess? Die Abhängigkeitenund Zusammenhänge sind extrem komplex und und jenachdem auf welcher Ebene man dies betrachtet sieht man komplett unterschiedliche Strukturen.
In der Phase der Anforderungsentwicklung ein einheitliches Bild für alle Beteiligten zu schaffen halte ich für eine der großen Herausforderungen für ein erfolgreiches Projekt. Viele Methoden griefen hier zu kurz und lassen den Projektleiter alleine. Er macht dann das, was in solchen Fällen immer am betsen ist: die Theorien sein lassen und sich auf den gesunden Menschenverstand verlassen.
Viele Grüße, Andreas Bungert
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