ich kann nur unterstreichen, dass ein “iterativ-rollierendes Prozessmodell” erst bei höherer Reife Sinn macht. Ich habe schon erlebt, wie sich ein paar Leute damit und darin verstrickt haben.

Aus meiner Sicht liegt der wesentliche Vorteil eines gemeinsamen (einfachen) Prozess-Modells bei seiner Einführung darin, dass sich ein Projektteam das Verhandeln zur Frage, wie man nun das Projekt denn angehen soll, ein Stück weit sparen kann. Außerdem wird die Anzahl von späteren Überraschungen in Form von unerfüllten Erwartungen beträchtlich reduziert.

Mit den besten Grüßen
Holger Zimmermann

Unter “Reifegrad” hätte ich in diesem Zusammenhang, Reifegrade wie die des CMM bzw. CMMI verstanden…
…und so etwas braucht sowohl Entwicklung, wie auch Zeit.

@Felix: Ich stimme Deiner Aussage ebenfalls zu, unter eben einem anderen Gesichtspunkt…

Konkret: In der Phase “Durchführung & Implementierung” kann ich mir sehr schön eine Umsetzung mit Scrum und mehreren Sprints vorstellen. Einige Arbeitspakete/Stories können auch in den Phasen davor (Abschätzungen, Setup) und danach (Übergabe, Stabilisierungen) in Scrum-Teams wandern.

@Bernd:
Meine Erfahrungen sagen mir, dass eine Organisation die Projekte durchführt grundsätzlich einen übergeordneten PM-Prozess haben sollte.

Hat sie diesen nicht, so müssen viele Dinge immer wieder neu im Projektkontext diskutiert werden. Viele (unangenehme) Entscheidungen werden auf die Projektbeteiligten abgeschoben, die ohne entsprechenden Rahmen in der gleichen Situation sehr unterschiedlich entscheiden.

Der PM-Prozess sollte jedoch nur als Rahmen dienen und kann auch bewusst übergangen werden. In diesem Fall muss jedoch klar sein, wer hierfür die Verantwortung trägt.

Beispiel: Der Vertrieb setzt die Durchführung eines (unrealistischen) Projektes durch weil es “strategisch” ist obwohl die Kennzahlen und Analysen dagegen sprechen. Typischerweise hat ohne Dokumentation der Entscheidungsfindung dann irgendwann der PM den schwarzen Peter und der Vertrieb akquiriert bereits das nächste Todesmarschprojekt.

Sehr wichtig ist jedoch, dass der Detaillierungsgrad der Vorgaben stimmt. Ohne richtiges Augenmaß wird ein nicht passender PM-Prozess nie gelebt werden.

Da es sich um Erfahrungswerte handelt, trag ich mal einen Link aus dem agilen Projektmanagement bei:

http://www.monitor.co.at/index.cfm/storyid/9002?CFID=20393105&CFTOKEN=4790536

Auf Seite 2 des Links äußert sich Herr Schneck aus dem Healthcare

Meiner Meinung nach sind es vorallem langwierige Projekte, die (wenn überhaupt) einen übergeordneten Projektmanagement-Prozess benötigen und ich kann mir vorstellen, dass sich mit der Zeit auch ein Reifegradwachstum (wenn man diesen “vorantreibt”) ergibt.

Ab wann man in solchen Projekten zB rollierend vorgeht, bleibt aber offen und hängt unter Anderem mit den gestellten Anforderungen / wechselnden Zielen zusammen.

Bei häufigen “Umplanungen”, weil sich zB die Rahmenbedingungen ändern, wird man mit klassichen Mitteln wohl eher ein Projekt beenden und ein Neues starten, statt ein bestehendes Projekt flexibel “umzulenken”….

Nein, Quellen habe ich dafür keine. Die These basiert auf praktischen Erfahrungswerten.

a) Du hast aber sicher recht, dass die Branche und die jeweilige Projektart im Wesentlichen bestimmen sollte, welcher PM Prozess und damit auch welche PM Methodologie zur Anwendung kommt.

b) Gerade im Software- und IT-Projektmanagement sind agile, iterative PM Prozesse und Vorgehensweisen state-of-the-art.

c) Meine These, dass sequentielle PM Prozessmodelle (wie das obige) einfacher anzuwenden sind als iterativ-dynamische Modelle, kommt daher, dass sequenzielle Modelle eher “checklisten-artig” abgearbeitet werden können (erst 1 dann 2 dann 3…). Das stellt in der Praxis eine Vereinfachung dar und ist deshalb einfacher (wenn auch nicht immer richtiger).

d) Wenn ein solches Prozessmodell mal wirklich angewendet und gelebt wird, ist der Schritt zu einer iterativ-dynamischen – auch agilen – PM Methodik ein kleiner.

Die Erfahrung zeigt aber, dass ein derartiges, iterativ-rollierendes Prozessmodell häufig erst in einer späteren Implementierungsphase (oder in einem höheren PM Reifegrad) Sinn macht.

Gibt es da auch Quellen zu?
Ich würde intuitiv nämlich viel eher einen Zusammenhang mit der Branche/Art des Projektes erwarten, als mit dem Reifegrad oder Implementierungsphase des Prozesses