[...] – PMI und DIN/GPM im Widerspruch! Stefan Hagen hat sich heute mit einer leisen Kritik am Methodenwürfel der GPM geäußert. Die leise Kritik möchte ich mit einer klaren Stellungnahme zu den Begriffen [...]

Hi Andreas,

freue mich, dass Du als GPM-Insider das Thema in Deinem Blog aufgegriffen hast!

LG, Stefan

Hallo Stefan, ich geb Dir recht – es ist ‘lästig’, wenn man unter vermeintlich klaren Überschriften dann was findet, was nicht so in das eigene PM-Weltbild passt. Anstelle der Bezeichnung Projektphasen wäre wohl besser ‘PM Prozesse’ oder ‘PM Teilprozesse’. Allerdings würde ich gerne mal mit Dir diskutieren, wie einzelne PM (Teil-)Prozesse im Laufe des Projektes gehandhabt werden können, ich glaube, da haben wir sehr unterschiedliche Erfahrungen. Die GPM Bezeichnung Prozessgruppen ist leider wirklich irreführend, Dein Vorschlag PM Wissensfelder analog PMI Knowledge Areas ist da viel passender LG Franz

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.

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

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.

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

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 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

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

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.

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 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

@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/

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

[...] der Diskussion rund um den GPM-Methodenwürfel und seine Begriffe hatte ich Stefan vom PM Blog einen Nachschlag versprochen: Hier kommt er: Die vor langer Zeit vom PMI im Standard PMBOK® Guide-Standard definierten [...]