Anforderungsmanagement in IT Projekten
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 ;-)
risikomanagerin
16. Juli 2008 um 19:17
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.
Peter Addor
17. Juli 2008 um 11:45
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!
SH
17. Juli 2008 um 11:53
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 „neue Erkenntnis über Möglichkeiten bringen, auf die Welt einzuwirken. Wenn solche neuen Erkenntnisse gewonnen sind,“ kann sich der Projektmanager wieder „dem Planen widmen oder er findet auf diese Weise einen direkten Übergang von Start- zum Zielpunkt“.
http://www.anchor.ch/cms/front_content.php?idart=74&ref=14nicht
Peter Addor
17. Juli 2008 um 13:08
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.
Peter Addor
17. Juli 2008 um 13:13
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
Stefan Hagen
17. Juli 2008 um 13:18