Icon

Wartungsarbeiten

Aufgrund von Wartungsarbeiten wird openPM vom 24.8 - 25.8.2017 nicht zur Verfügung stehen. Wir bitten um Ihr Verständnis.

Projektmanagementprozessgruppen nach dem PMBOK

Das PMBOK 5th Edition definiert -in Anlehnung an Service Life Cycle- den Projektlebenszyklus mit folgenden Aktivitätengruppen, die sich auf das Projektteam sowie weitere Stakeholder beziehen: 

  • Projekt starten (starting the project) - Ausgangswert Project Charter
  • Leistungserbringung organisieren und vorbereiten (Organizing and preparing) - Ausgangswert Projektmanagementplan
  • Leistungserbringung durchführen (Carrying out the work) - Ausgangswert Akzeptierte Liefergegenstände
  • Projekt abschließen (Closing the Project) - Ausgangswert Archivierte Projektdokumente und abgeschlossene Vertragsverhältnisse

Die entlang des Projektlebenszyklusses erforderlichen Managementaktivitäten werden in 47 Projektmanagementprozessen sowie  5 Projektmanagementprozessgruppen logisch zusammengebündelt: Projektmanagementlebenszyklus. Die fünf Gruppen sind:    

Twittern

10 Kommentare

  1. Ich bin ja sehr dafür, Prozessgruppen und Wissensgebiete zu trennen. Es gibt ja je nach Standard (PMBOK, ICB, ...) verschiedene Prozessmodelle aber im Grund immer die gleichen Wissensgebiete.

    ... ich versuch das jetzt mal.

     

    1. OK, das hat geklappt. Dabei ist mir aufgefallen, dass "Prozessgruppen" und vor allem "Wissensgebiete" sehr gut auf die gleiche Ebene wie "Methoden & Werkzeuge" passen würde, also direkt unter "Wissen und Erfahrung". Wie seht Ihr das?

    2. Hallo Tobias,

      ganz so einfach sehe ich das mit den Wissensgebieten nicht. Die sind schon noch sehr PMBOK-lastig, obwohl wir schon im Vorgriff auf die nächste Auflagge des PMBOK das Stakeholdermanagement vorweggenommen haben und auch jemand das Wissensmanagement als eigenständiges Knwoledearea hinzugefügt hat. Ich bin mit der PMBOK-Logik an dieser Stelle auch nicht immer glücklich. Habe meine eigene Ablage auch nach PMBOK organisiert und beispielsweise Beiträge, die unter dem Titel "Controlling" fallen passen da irgendwie nie richtig rein, weil sie in der PMBOK-Logik immer gleich mehere Wissensgebiete (z.B. Kosten & Termine) betreffen, aber gleichzeitig auch die Prozesgruppe Übrewachung & Steuerung oder ist das dann alles Integrationsmaangement?

      Nachdem wir uns auch um Verbandsneutralität bemühen, würde ich den PMBOKauch aus diesem Grund nicht noch prominenter platzieren wollen.

      Gruß

      Bernhard

  2. Danke für die Trennung von Wissensgebieten und Prozessgruppen. Ist meiner Meinung nach besser so. Unterhalb von Sichten hängen diese Seiten aber auch nicht schlecht, denn schließlich sind sie ja Sichten auf das Thema PM, oder? Wenn wir sie nach oben heben, dann zeichnen wir diese beiden gegenüber den anderen Sichten aus. Welchen Grund hätten wir dafür?

    1. Gute Frage.Bei der Prozessgruppen kann ich das gut nachvollziehen - manchmal geht es nach Prozessen, manchmal nach Rollen und deren Aufgaben, ...

      Aber wieso stehen dann Methoden und Werkzeuge denn direkt unter "Erfahrung und Wissen" und Wissensgebiete nicht? Aus meiner Sicht gehören Methoden und Werkzeuge unterhalb der Wissensgebiete.Welche Methoden gibt es, die nicht einem Wissensgebiet zuordbar sind? Bestimmt nicht so viele. Aber wenn ich Methoden und Werkzeuge suche, dann doch zu einem bestimmten Wissensgebiet, oder?

      Ich könnt mir das so vorstellen i.e.

      Risikomanagement

      Definition Risiko & Chance
      Risikosystematik
      Methoden
      Werkzeuge
      ...

      "Methoden und Werkzeuge" könnte dann eine Sammlung von Direkt-Verweisen auf die Seiten unterhalb des Wissensgebiet werden. Ich glaub das könnte ganz hübsch werden...

      1. Ist ein Argument: Methoden & Werkzeuge auf oberster Ebene ist tatsächlich ein wenig gewöhnungsbedürftig: sehe ich auch eher als querschnittlichen Aspekt. Ich könnte mich damit anfreunden, die Wissensgebiete und Projektmanagementprozessgruppen nach dem PMBOK auf oberste Ebene zu heben und darunter dann Werkzeuge und Methoden zu beschreiben und diese dann auf einer Seite Methoden & Werkzeuge (unterhalb von Sichten) gesammelt zu verlinken. Klingt gut. Was meinen andere dazu?

      2. Hallo Tobias,

        dann müssten aber Methoden & Werkzeuge als Unterrubrik in jedes Wissensgebiet und das geht mir ehrlich gesagt zu weit. So wie die Sichten-Seite aktuell aufgebaut ist, müssten wir die Methoden & Werkzeuge unter den Listen aufhängen, dann wäre das quasi ein Quereinsteig über alle Wissensgebiete zu einer Auflistung von Methodem & Werkzeugen. (Die einzelnen Methoden können ja durchaus in den Wissensgebieten liegen oder - sofern nicht eindeutig zuordenbar unter der Methodenübersicht.

        Gruß

        Bernhard

  3. Mir persönlich gefällt die IPMA-Einteilung in

    1. Initiierung
    2. Definition
    3. Planung
    4. Ausführung/Umsetzung
    5. Abschluss

    besser.

    Bei den Sichten ist mir zu viel drin, ohne dass aus der Überschrift klar erkennbar ist, was und warum dazugehört (speziell in der unteren Hälfte). Ich kann aber (noch) nicht sagen, wie ich es besser fände. Insbesondere die Prozessgruppen und die prozessorientierte Sicht führen ein Parallelleben.

    Den Begriff Prozessgruppen finde ich auch etwas unglücklich. Im Prozessmanagement wird darunter eher eine parallele bzw. unabhängige Orientierung verstanden (Führungsprozesse, Leistungsprozesse, Unterstützungsprozesse), während im Projektmanagement doch hauptsächlich sequentielle Orientierung gemeint ist (also mit einer Reihenfolge wie in meiner Liste oben).

    1. Redundanzen in den Sichten sind durchaus gewollt, um verschiedene Zugänge zum gleichen Content zu schaffen.

      Der Begriff Prozessgruppen wird zumindest im PMBOK so verwendet.

      Ich bin mir nicht sicher, wie wir die Sicht Prozessgruppen und Wissensgebiete weiterentwickeln wollen. Wie nah wir am PMBOk bleiben wollen oder uns bewuss davon entfernen. (Der PMBOK hat ja in der prozessorientierten Sicht auch seinen Platz, wie du zu Recht anmerkst.). Ich habe ide Untertielung in den Sichten aber aufgenommen, weil der granualrere Level (z.B. Risikomanagement, QM) einfach noch gefehlt hat und ich mir keine neue Logik aus den Fingern saugen wollte. Bin für alle Vorschläge offen.

  4. Meine Meinung: In Anlehnung Serviceorientierter Architektur sind Prozesse die Aneinanderreihung von verschiednen (ich sag jetz mal) Aktivitäten. Und wie bei konfigurierbaren Prozessen in der Software sind die atomaren (nicht weiter zerlegbaren) "Aktivitäten" die eigentlichen Methoden & Werkzeuge im PM.

    Was ich damit sagen will: Wir sollten uns nicht an Prozessen orientieren sondern einfach an Methoden und Werkzeugen und die Prozessdarstellung den jeweiligen Organisationen und Trägerschaften dieser "Prozessmodelle" überlassen, Prozesse sind "Modeströmungen" und daher Veränderungen unterworfen. Daher sollten wir eine davon unabhängige Darstellung wählen und "Prozesse", ob nach PMBOK, ICB, PRICE2, V-Modell XT oder sonstige, davon getrennt notieren.

Dieser Inhalt von openPM steht unter einer Creative Commons Lizenz (CC BY 3.0) und kann frei verwendet werden unter Namensnennung durch Link auf http://openpm.info. Unpassende Inhalte, insbesondere Verstöße gegen Urheberrechte, bitte via info@openpm.info melden. Weitere Informationen unter Nutzungsbedingungen