[...] Hagen hat sich den Methodenwürfel der GPM angeschaut, findet ihn gut, hat aber dennoch ein paar kritische Anmerkungen zur Systematik und [...]

Hallo Stefan,

im Wesentlichen teile ich deine Meinung, verstehe ich die Projektphasen vielleicht etwas anders als du und frage mich, ob vielleicht einfach hier die gewählten Wörter zu einem unterschiedlichen Verständnis führen, aber eigentlich das Gleiche gemeint ist.
Am Beispiel von der Phase Planung, deren Abschluss durch einen Meilenstein du bemängelst, versuche ich das zu erläutern.

Die Namen der Phasen (oder eher Prozesse) kenne ich so aus Prince2 — wie du vielleicht auch. Dort ist Planen ein Prozess der beginnend mit dem Initiieren des Projektes bis, ich glaube, kurz vor den Abschluss dessen parallel zu anderen Prozessen läuft. Dabei werden die Aktivitäten des Planens immer wieder angestoßen. Meilensteine sind in Prince2 laut meines Wissens nicht vorhanden. Dies wäre somit die geforderte Kontinuität.

Leider fand ich kein bisher kein schönes Bild, das dies wirklich gut zeigt, deswegen muss ich das Bild im Prince2 Eintrag auf Wikipedia vertrösten (http://de.wikipedia.org/wiki/PRINCE2). Noch ein Hinweis zu dem Bild: Die Prozesse Steuern einer Phase, Managen der Phasenübergange und Managen der Produktlieferung können beliebig oft wiederholt werden und somit zu mehreren Iterationen oder Projektphasen führen.

Natürlich stimme ich dir zu, dass wenn diese Prozesse/Phasen als rein sequentiell angesehen werden, dies nach heutigem Wissen eine veraltete Sichtweise wäre. Der dritte Kritikpunkt ist auch wieder eine Frage der Definition, allerdings fände ich den Begriff PM Wissensfelder auch sehr viel passender. Ich finde es sollte vielleicht manchmal erwähnt werden, was unter der Definition nicht verstanden wird, dann wäre es oft verständlicher.

Ich hab mir das Thema Projektphasen vor einiger Zeit durch den Kopf gehen lassen und die relevanten Definitionen verglichen. Aus meiner Sicht haben Prozesse nichts in einer Phasendefinition verloren. Die Phasen definieren sich vorrangig über ihr Ziel, dies wird in vielen Fällen durch einen Stage Gate-Prozess vorgegeben. D.h. am Phasenende erfolgt eine Abnahme. Eine “Aufweichung” aus Projektnotwendigkeiten oder aus einer agilen Sicht kann stattfinden, d.h. Phasen können überlappen. Dies birgt, je nachdem welche Phasen überlappen, das Risiko Kosten zu produzieren, die sich im Nachgang als unnötig erweisen. Aber wie immer gilt es abzuwägen. Mein Rechercheergebnis mit Meinung habe ich hier hinterlegt: http://pjmb.wordpress.com/2009/02/26/projektphase-definition

Hallo,
auch auf die Gefahr hin, dass ich mich als absoluten PM-Thorie-Laien oute … in meiner Praxis (Organisationale Change Projekte) kommt es praktisch immer dazu, dass wir zwar Veränderungsphasen durchlaufen, allerdings keine der Phasen im eigenltichen Sinne abschließen.
Z.B. heißt bei uns eine der frühen Phasen “Dringlichkeit deutlich machen” und eine weitere “Vision und Strategie entwickeln”. Wir haben festgestellt, dass es nicht nur darauf ankommt, die Dringlichkeit einmal formuliert zu haben oder die Strategie in ein Strategiepapier gegossen zu haben. Vielmehr ist es wichtig, die Erkenntnisse immer wieder zu prüfen und immer wieder auszuloten, ob die Inhalte und Vereinbarungen in der Organisation noch präsent sind.

Damit uns das gelingt haben wir ein Prozess-Thermometer oder Projekt-Thermometer entwickelt, dass uns dabei hilft, die “Betriebstemperatur” der einzelen Phasen zu erkennen und auf Entwicklungen zu reagieren.
Hier ein Beispiel, das ich schon eimal mit den Wörtern aus dem PRINCE2-Prozessbild bei Wikipedia gefüllt habe.

Die Y-Achse gibt die Temperatur der Phase an, wie sie etwa vom Projektleitungsteam oder in einer Kurzumfrage bei Mitarbeitern eingschätzt wird. Auf der X-Achse werden die relevanten Phasen abgetragen.

Macht man die Einschätzung, kann man daraus ableiten, in welcher Phase im Moment welche Aktionen notwendig sind (z.B. mehr Kommunikation, Konfliktmanagement, alles i.O usw.). Unsere Erfharung zeigt, dass diese Vorgehen vor allem dort gut funktioniert, wo Phasen auf dauerhafte Vereinbarungen aus vorehrgehenden Phasen angewiesen sind, also dort, wo auch egentlich abgeschlossene Phasen wieder neu aufbrechen.

Ich habe keine Ahnung, ob das hierher passt und jemandem weiter hilft. Mir kam es eben in den Kopf, als ich diesen Blogbeitrag gelesen habe.

Grüße
Gebhard

Hier der Link zur Grafik, die Stefan gerne auch in den Beitrag einarbeiten kann, wenn er es kann?

http://www.sinnkoppelung.de/sites/default/files/ProjektThermometer.png

Ich freue mich sehr über Eure Erkenntnisse und Sichtweises zum Thema GPM Methodenwürfel bis hin zu Phasendefinitionen. Wir haben doch alle erkannt, dass die meisten Projekte als Prozesse zu sehen sind und deshalb kaum scharfe Abgrenzungen zutreffen. Die Kunst unseres PM-Handwerks besteht doch darin Komplexitäten zu reduzieren ohne durch zu scharfe Abgrenzungen die Möglichkeiten des Denkens in Prozessen zu reduzieren. Ich bin seit 25 Jahren Projektmanager und auch wegen dieser phasenorientierten und sonstigen zu einfachen Betrachtungen sowie mangelhafter Berücksichtigung komplexer Systeme aus der GPM ausgetreten.

Hallo,

vermutlich stimmt es, dass in solchen Diskussionen wirklich niemand “recht” hat. Die Methoden im Methoden-Würfel könnten auch jeder anderen Dimension zugeordnet werden. Wenn Sie drei Leute fragen, bekommen Sie da garantiert fünf Antworten…

Allerdings möchte ich darauf verweisen, dass die Norm DIN 69901-2 kein “serielles” Prozessmodell darstellt, sondern im Gegensatz dazu explizit “iterativ” ist. Es sind beliebig viele Rücksprünge von PM-Phase zu PM-Phase beziehungsweise von Prozess zu Prozess möglich. Dies ist wie in jedem Modell nur schwer darstellbar…

Jedes Projekt hat einen Anfang und ein Ende. Dazwischen finden viele Aktivitäten bzw. Prozesse statt. In der Ausbildung von Projektmanagern ist es nach unserer Erfahrung hilfreich, den “roten Faden” durch´s Projekt aufzeigen zu können. Auch bei der Definition von PM-Systemen hat sich diese Darstellung als “Schablone” gut bewährt, sie kann beliebig an Projektart/-komplexität angepasst werden.

Nun zur Unterscheidung von den PM-Phasen, die zur Orientierung im Methodenwürfel angezogen werden, und zu den Projektphasen. Dies war übrigens ein “Kunstgriff”, damit unser PM-Prozessmodell allgemein gültig, und damit in allen Kontexten, Branchen, Projektarten etc. anwendbar ist. Hier als Zitat aus der Norm:

“Der gesamte Ablauf eines Projekts (Projektlebenszyklus), von der Initialisierung bis zum Abschluss, lässt sich in zusammenhängende Abschnitte (Phasen) unterteilen. Die Norm unterscheidet zwischen Projektphasen und Projektmanagementphasen. Projektphasen unterteilen den Projektlebenszyklus in zeitlich zusammenhängende Abschnitte und spiegeln so den Projektverlauf mit den inhaltlichen Aktivitäten aus Sicht der jeweiligen Organisation wider. Abhängig von den Anforderungen der jeweiligen Projektart, Branche oder Organisation können diese Aktivitäten verschieden unterteilt werden. Die Phaseneinteilung auf der Ebene des Projektmanagements orientiert sich hingegen
an den logisch zusammenhängenden Aktivitäten des Projektmanagements. Die Norm unterscheidet die fünf
Projektmanagementphasen „Initialisierung“, „Definition“, „Planung“, „Steuerung“ und „Abschluss“.
Die grundlegende Aufgabe bei der Gestaltung von Organisationen ist es, einen Abgleich bzw. eine Synchronisierung der Prozesse vorzunehmen und zu dokumentieren (z. B. in einem Projektmanagement-Handbuch).”

Die PM-Phasen stellen keine “zeitliche” sondern eine “logische” Anordnungsbeziehung dar! Dies findet man mit ähnlichen Darstellungen/Bezeichnungen auch im PMBoK. Bei der Abeit an der neuen ISO 21500 haben wir sehr schnell Konsens über diese Anprdnungsbeziehungen gefunden. Wer “große Unterschiede” zwischen PMI und GPM/IPMA konstatiert, sollte mal ein Meeting meiner Arbeitsgruppe im Rahmen der ISO 21500 erleben…
Auch die Briten mit ihrem PRINCE 2 lassen sich da übrigens wunderbar integrieren. Mit der ISO 21500 werden zukünftig dann auch die – oft künstlich – heraufbeschworenen “Lagerkämpfe” verstummen.

Zum Schluss noch eine Anmerkung zum Thema “Prozessgruppen” vs. “Knowledge Areas”. Auch hier rückt das PMI zukünftig ab von ihrer Bezeichnung. In der ISO 21500 benennen wir das nun “Subject Groups”. In dieser “Gruppe” werden inhaltlich zusammengehörige Prozesse zugeordnet – auch hier gilt wieder: nur zur Veranschaulichung.

Fazit: Es geht darum, Zusammenhänge darzustellen und verständlich zu machen. Recht machen kann man es eh keinem. Der Projektmanager muss lernen, virtuos mit dem verfügbaren Instrumentarium umzugehen. Dann wird er schon wissen, wann er was braucht…

Vielleicht gilt hier das Motto: “Take it easy”

MfG

Reinhard Wagner
Vorstand PM-Forschung und Facharbeit
GPM Deutsche Gesellschaft für Projektmanagement e.V.

[...] In der Diskussion rund um den GPM-Methodenwürfel und seine Begriffe hatte ich Stefan vom PM Blog einen Nachschlag versprochen: Hier kommt [...]

Prost! Ich freue mich schon auf die nächste DIN-Sitzung ,-) Die subject groups sind sicher näher am Ziel als die knowledge areas. Denn wenn man sich deren Definition ansieht, ist sie wachsweich. Das PMI hat die Definition nicht abgeschlossen, sondern bleibt die Antwort auf die Frage nach den Wissensanforderungen, die ein Wissensgebiet definieren, leider bis heute schuldig.

Ich stimme Dir voll zu.

Natürlich kann man den Phasenbegriff unterschiedlich definieren. Aber auch mir erscheint “die richtigste” Definition zu sein, dass eine Phase durch ein klares Endergebnis, idR Meilensteinergebnis, abgeschlossen wird.

Die verschiedenen Vorgehensmodelle wie Stage-Gate implizieren ja auch exakt dieses Phasenverständnis.

Hallo Andreas – ich hoffe, “Dutsen” ist OK – das gehört im Web 2.0 dazu !

“Projekte als Prozesse sehen”: Diese Aussage könnte auch zu Misserständnissen führen. Selbstverständlich ist ein Projekt immer ein Prozess/Ablauf, bei dem verschiedene Aktivitäten aufeinander folgen.

Der Prozessbegriff wird allerdings im Organisationskonzept “Prozessmanagement” (= Geschäftsprozessmanagement auf der Basis des Business Reengineering Ansatzes von Hammer/Champy) als systematische Abfolge von Aktivitäten definiert. Hier ist das Ziel, Prozesse so weit wie möglich zu standardisieren.

Ich denke, wir sollten zumindest differenzieren:

- standardisiert-strukturierte vs. inkrementell-evolutionäre Prozesse
- sequentielle vs. iterative Prozesse
- wertschöpfende vs. nicht-wertschöpfende Prozesse
- …

Man sieht: Prozess ≠ Prozess.

Wo ich mit Dir völlig d’accord bin: Die großen PM Verbände (nicht nur die GPM, gilt für PMI im selben Maße) scheinen neueren Managementansätzen (wobei, so neu sind sie eigentlich gar nicht) wie der Managementkybernetik, den systemtheoretischen Ansätzen etc. gegenüber nur wenig aufgeschlossen zu sein. Das wirkt vielfach sehr technokratisch, mechanistisch und zu stark methodisch orientiert. Aber vielleicht ist meine Wahrnehmung ja auch verzerrt. Ich lasse mich zumindest gerne eines Besseren belehren.

Ich freue mich in jedem Fall über diese – erneut – sehr angeregte und anregende Diskussion!

LG, Stefan

Hallo Hr. Wagner,

vielen Dank für diesen umfangreichen Input. Ich möchte nicht in der Breite darauf eingehen, da ich Ihnen zu einem großen Teil auch zustimme bzw. Ihre Position nachvollziehen kann.

Ich möchte kurz etwas ausholen, bevor ich auf den Punkt komme. Meines Erachtens kann die Differenzierung zwischen “PM Prozess” und “Projektprozess” weiter helfen. Diese Begriffe werden in der DIN 69904 wie folgt definiert:

PM-Prozess:
“Prozess zur Planung, Überwachung und Steuerung von Projektprozessen.” (DIN 69 904)
Projektprozess:
“Prozess, der unmittelbar die Erzielung von Projektergebnissen bewirkt.” (DIN 69 904)

Diese Begriffe eignen sich meines Erachtens besser als PM Phasen und Projektphasen. Inhaltlich meinen wir aber wahrscheinlich dasselbe.

Der PM Prozess beschreibt den iterativen Managementprozess (indirekt wertschöpfend). Der Projektprozess hingegen ist der Projektlebenszyklus, der in der Regel in Form von Phasen strukturiert wird (wertschöpfend). So könnte die Management-Ebene klar von der Ebene der Wertschöpfung in Projekten getrennt werden. Das würde meines Erachtens Sinn machen. (Ich habe hier schon mal darüber geschrieben: http://pm-blog.com/2008/04/12/pm_methodik/ .)

Fazit: Wahrscheinlich werden wir auch weiterhin einen kritischen Diskurs führen, da – wie bereits mehrfach erwähnt – keiner wirklich objektiv recht hat. Allerdings wird wieder einmal die Wichtigkeit einer klaren Begriffsdefinition und -abgrenzung klar. Denn sonst passiert das, was in der Praxis an der Tagesordnung steht: Wir verwenden dieselben Begriffe, meinen aber etwas ganz anderes. Oder aber wir verwenden unterschiedliche Begriffe und meinen dasselbe.

In diesem Zusammenhang gefällt mir folgende Logik: Sprachklarheit –> Denkklarheit –> Handlungsklarheit. Diese Logik wird in der Broschüre “DIN Normen im Projektmanagement” (Bechler/Lage) hervorragend beschrieben: http://pm-blog.com/2008/04/15/din-normen-im-projektmanagement/

In diesem Sinne: Take it easy & happy projects

Stefan

“There is never a second chance for a first impression.”

visuelle inkompetenz ist auch eine form von inkompetenz.

diese grafik hat die anmutung aus dem 19.jahrhundert zu stammen – hätte es damals schon PCs gegeben.
entsetzlich!
dabei vergeht mir die lust auch nur eine zeile ins detail zu lesen.

sunshine!
Jan A. Poczynek

Das war in dem Fall Jans LAUTE Kritik am GPM Methodenwürfel

Leider keine sehr konstruktive Form einer Kritik. Wäre ich Urheber der Grafik, hätte ich wahrscheinlich jetzt nicht verstanden, wie ich auf Jan’s Wunsch zur besseren Darstellung eingehen könnte.

Zwar bin ich nicht in irgendeiner Form mit dem Urheber oder der Seite allgemein verbunden, allerdings fände ich es interessant, wie das verbessert werden könnte. 3 Dimensionen in einer 2D Darstellung abzubilden ist meines Wissens sehr schwer. Aber wer eine so harsche Kritik ausübt, hat sicher einige Verbesserungsvorschläge oder gar eine Lösung parat.

Ich persönlich finde die Grafik auch nicht sehr schön, aber sie erklärt ausreichend, dass es sich hier um 3 Dimensionen handelt und welche Werte in jeder gesehen werden. Leider wirkt sie zu sehr gequetscht und die Schrift ist schlecht lesbar wegen der Größe und der Qualität/Komprimierung der Grafik.

Wenn ich das richtig verstanden habe, dann geht PRINCE2 von Standardprozessen aus. Gemeint sind hier nicht die Prozesse des Projekts, sondern die Projekt Management Prozesse. Diese beinhalten immer die gleichen Aktivitäten und Ergebnisse (PRINCE2: Produkte).

Damit ist gemeint, dass es im Projekt einmal die wertschöpfenden Prozesse gibt, die das Ergebnis des Projekts sind. Allerdings herrschen auch Projekt Management Prozesse, die eigene Ergebnisse haben und sicherstellen sollen, dass das Projekt (bestmöglichst) kontrolliert verläuft.

Hallo Herr Dr. Hagen,

die von Ihnen zitierten Normen DIN 69904, 69905 sind veraltet, aktuell sind momentan nur noch die DIN 69900 “Netzplantechnik” und 69901″Projektmanagement – Projektmanagementsysteme” in den Teilen 1 bis 5…. Zu beziehen über den Beuth-Verlag in Berlin (beuth.de), es gibt diverse Veröffentlichungen von mir und den Mit-Normern zu diesem Thema. Übrigens ist es natürlich nicht hilfreich, wenn z.B. Herr Heilwagen seine eigenen Definitionen für die Diskussion heranzieht, die ja schon genug kompliziert bezüglich “Sprachklarheit” ist. Deshalb setze ich auch so viel Hoffnung (und Zeit) auf die neue ISO 21500, weil damit auch die Begriffswelten angeglichen werden.

So, nun lasse ich es aber gut sein, und arbeite wieder weiter… das nächste Highlight der GPM steht nämlich vor der Tür, das PM-Forum in Berlin “Die Kunst des Projektmanagements – Inspiriert durch den Wandel”, am 14./15.10.2009 in Berlin!

Gruß

Reinhard Wagner

Herr Wagner stellt letztlich die Frage, warum ich in der Diskussion meine eigenen Definitionen heranziehe. Der Grund ist relativ einfach: um genau solche Diskussionen führen zu können. Denn meines Wissens ist pm-wörterbuch.de derzeit das einzige vergleichende Wörterbuch für den deutschsprachigen Raum neben einigen Quellen, die Kurzartikel im Rahmen von Glossaren anbieten. Mein Ziel ist die derzeit relevanten Definitionen einander gegenüberzustellen und einen sinnvollen Mittelweg zu finden. Meine Erfahrung in diversen Projekten war, dass man sich häufig missversteht, weil eben so viele unterschiedliche Definitionen existieren. Sobald die ISO 21500 erscheint, werde ich das Wörterbuch überarbeiten, so wie auch für jede neue Version einer anderen Norm, immer mit dem Ziel den Ausgleich und praktisch anwendbare Definitionen anzubieten einschließlich Diskussion aller anderen Definitionsvarianten.

In diesem Kontext arbeite ich übergreifend über die gängigen Standards und Fachverbände und bin gespannt auf die Diskussionen, die sich daraus ergeben.

Hallo Stefan,
ich verstehe den Prozessbegriff im Projektmanagement hier als mehrdimensional und sich immer wieder iterativ auf die Entwicklungen in Projekten auswirkend z.B. in einem Reorganisationsprojekt.

Hier stimme ich allen zu, die behaupten dass diese Projekte systemorientiert, strukturiert und von mir aus auch nach DIN und Modellen gesetuert werden können. Aber nur bis zu einem bestimmten Punkt. Und mit einem Modell (Würfel) oder andern Leitlinien zur Erleuterung lassen sich die mehrdimensionalen Einflüsse in Projekten (Ziele, Strukturen, Erfahrungen, Ängste, …) doch nicht prizipiell abbilden, eben nur Modellhaft.

Deshalb stimme ich Nikolas zu indem er sagt: es herrschen eben auch Management Prozesse, die wir kontrollieren müssen.

Wenn Reinhard den Methoden Würfel als einen roten Faden bezeichnet und am Ende der Projektmanager wie ein Virtuose (Handwerker, Hellseher, Heilpraktiker, Hirte, Hoffnungsträger, …) handeln muss ist ja alles wieder in Ordnung.

Deshalb sind die modellhafte Darstellungen natürlich gut für die Ausbildung auf bestimmten Ebenen des Projektmanagements. Meine Anmerkung zum Methodenwürfel sollte lediglich deutlich machen, dass wir als Manager in komplexen Projekten und somit verantortlich für zahlreiche Entwicklungsprozesse auf allen Beziehungsebenen auch ohne DIN oder andere Standardisierungen erfolgreich sein können. – Der Mensch macht den Untzerschied!

Hallo Andreas,

also ich finde Deine Initiative pm-wörterbuch.de klasse. Denn endlich wird mal deutlich, dass im Projektmanagement (und auch anderswo) viele verschiedene Definitionen für ein und dieselben Begriffe herum geistern.

Ich würde mir wünschen, dass wir möglichst bald mal zu einem einigermaßen einheitlichen Begriffsverständnis in der PM Community kommen. Denn dann könnten wir uns endlich wieder den wirklich wichtigen inhaltlichen Fragen widmen, anstatt nur sinnlos über Begriffe und deren Bedeutung zu diskutieren.

In diesem Sinne: Weiter so! Ich schätze Dein PM-Wörterbuch sehr.

Stefan

Danke für das ermunternde Feedback Stefan.

@alle: gerne mit kritischen Kommentaren ins Wörterbuch grätschen, mit der Diskussion steigt die Qualität.

@Stefan: Wünsche welche Begriffe ich als nächstes aufarbeiten soll?

Eigentlich muss ich zwecks Gleichbehandlung der verschiedenen Standards jetzt mal die Projektmanagementphasen als Begriff in Angriff nehmen ,-)

@Andreas: Der Begriff “Projektmanagementphasen” ist für mich ein Wiederspruch in sich.

PM Prozesse ist nachvollziehbar, ebenso Projektphasen, aber eben nicht PM Phasen.

Relevante Begriffe für das Wörterbuch? Ich denke mal nach. Oder sonst kannst Du Dir ja beim Projektmagazin noch die eine oder andere Anregung holen: http://projektmagazin.de/glossar/

[...] vs. PMI – eine Zusammenfassung Initiiert durch die (Leise) Kritik am GPM Methodenwürfel von Dr. Stefan Hagen fand letzte Woche eine intensive Diskussion über Begriffe statt, in die sich [...]

Moin Stefan,

ist Deine Kritik nicht ein weiterer Hinweis darauf, dass wir uns vermehrt mit der eigentlichen Struktur unserer Projekte auseinander setzen sollten? Mir schwirrt regelmäßig der Kopf, wenn ich Definitionen mit Kollegen zu Tode bete, aber nicht auf den Kern der Sache komme: was ist eigentlich die Realität in Projekten?

Auch wenn schon überall gehypt: Wollen wir nicht mal ein alternatives Modell entwerfen, welches sich an agilen Methoden lehnt und versuchen, der Projekt-Realität gerecht zu werden?

Liebe Grüße aus einem klassischen Wasserfall-Projekt,

Thomas