Ich habe in diesem Blog ja schon öfter über das Modell des PM Prozesses geschrieben – beispielsweise hier, hier oder auch hier.
Noch einmal zur Auffrischung: Ein PM Prozess ist der übergeordnete Managementprozess für Projekte. Er beinhaltet alle wesentlichen Aufgaben, Funktionen und Methoden, die mit der Projektleitungs-Rolle in Verbindung stehen. Der PM Prozess stellt – wenn man’s genau nimmt – Overhead im Projekt dar, eine Investition in den Projekterfolg. Denn die PM Tätigkeit an sich ist eigentlich nicht (oder kaum) direkt wertschöpfend, sondern lediglich indirekt. Anders ausgedrückt: Durch einen stabilen, flexiblen und systematischen PM Prozess soll die Wahrscheinlichkeit auf Projekterfolg signifikant erhöht werden (Effizienz und Effektivität).
Meine These: Wenn Unternehmen einen einheitlichen PM Prozess implementieren und diesen auch zum Leben erwecken, so kann dies ein zentraler Aufhänger für ein effektiveres Projektmanagement im Unternehmen sein. Denn an einen PM Prozess können Sie alle essentiellen Schritte und Methoden anhängen, die für die erfolgreiche Abwicklung eines Projekts in der Regel notwendig sind. Ein Mindeststandard für Projekte sozusagen.
Klar ist aber auch, dass dieser PM Prozess in begründeten Fällen entsprechend angepasst, reduziert oder auch erweitert werden muss. Denn: Ein PM Prozess muss an die spezifischen Besonderheiten eines Projekts angepasst werden – man kann auch Skalierbarkeit dazu sagen.
Wie könnte nun ein solches, standardisiertes PM Prozessmodell aussehen? Hier ein Beispiel:
Ein solcher, unternehmensspezifischer PM Prozess gehört geschult, trainiert, diskutiert, von oben eingefordert und permanent weiter entwickelt. Und vor allem: Das Management muss den Prozess klar vorgeben, vorleben und auch einfordern.
Noch ein Hinweis für die „PM Professionals“ unter Ihnen: Schon klar, dass moderne Projektmanagement-Ansätze und Standards häufig von einem iterativen PM Prozessmodell ausgehen (wie jenes von PMI
Du schreibst:
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
@Jens: Danke für die interessante Frage.
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.
Ich finde diese Diskussion sehr Interessant.
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“….
@Stefan:
Ich bin der Meinung, dass auch schon bei kleineren Projekten ein zyklisches Vorgehen Sinn macht. Dieses sollte jedoch evtl. nicht explizit in dem PM-Prozess visualisiert werden, da dann viele neue Detailfragen geklärt werden müssen.
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.
@Felix: Ich bin voll und ganz Deiner Meinung – in allen Punkten.
Man lernt immer dazu, vorallem, wenn es um Projekte geht 🙂
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…
Guten Tag zusammen,
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