Kommentare zu: Anforderungsmanagement in IT Projekten http://pm-blog.com/2008/07/08/anforderungsmanagement-in-it-projekten/ Projekte - Management - Innovation Thu, 09 Feb 2012 09:23:59 +0000 hourly 1 http://wordpress.org/?v=3.2.1 Von: S. Hagen http://pm-blog.com/2008/07/08/anforderungsmanagement-in-it-projekten/comment-page-1/#comment-6961 S. Hagen Mon, 14 Jun 2010 20:27:43 +0000 http://pm-blog.com/?p=881#comment-6961 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 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

]]> Von: Andreas Bungert http://pm-blog.com/2008/07/08/anforderungsmanagement-in-it-projekten/comment-page-1/#comment-6955 Andreas Bungert Mon, 14 Jun 2010 16:06:29 +0000 http://pm-blog.com/?p=881#comment-6955 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 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

]]> Von: Stefan Hagen http://pm-blog.com/2008/07/08/anforderungsmanagement-in-it-projekten/comment-page-1/#comment-569 Stefan Hagen Thu, 17 Jul 2008 11:18:03 +0000 http://pm-blog.com/?p=881#comment-569 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 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

]]> Von: Peter Addor http://pm-blog.com/2008/07/08/anforderungsmanagement-in-it-projekten/comment-page-1/#comment-570 Peter Addor Thu, 17 Jul 2008 11:13:30 +0000 http://pm-blog.com/?p=881#comment-570 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. 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.

]]> Von: Peter Addor http://pm-blog.com/2008/07/08/anforderungsmanagement-in-it-projekten/comment-page-1/#comment-574 Peter Addor Thu, 17 Jul 2008 11:08:20 +0000 http://pm-blog.com/?p=881#comment-574 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 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

]]> Von: SH http://pm-blog.com/2008/07/08/anforderungsmanagement-in-it-projekten/comment-page-1/#comment-573 SH Thu, 17 Jul 2008 09:53:50 +0000 http://pm-blog.com/?p=881#comment-573 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! 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!

]]> Von: Peter Addor http://pm-blog.com/2008/07/08/anforderungsmanagement-in-it-projekten/comment-page-1/#comment-572 Peter Addor Thu, 17 Jul 2008 09:45:44 +0000 http://pm-blog.com/?p=881#comment-572 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. 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.

]]> Von: risikomanagerin http://pm-blog.com/2008/07/08/anforderungsmanagement-in-it-projekten/comment-page-1/#comment-571 risikomanagerin Wed, 16 Jul 2008 17:17:44 +0000 http://pm-blog.com/?p=881#comment-571 Ich hab's ja immer schon gewusst ;-) Ich hab’s ja immer schon gewusst ;-)

]]>