PmBok Guide 6 Kap.4 : Eines der zentralen Kapitel des PmBok Guide 6 Kap.4 ist das Integrations-management enthält 7 Integrationsprozesse, die quasi Metaprozesse bedeuten. Sie sind die zentralen Prozesse der Prozessgruppen und integrieren die anderen 43 Prozesse. Bespiele finden Sie in der PMIstandard+*.
| * Auf Verlinkungen der PMIstandards+ Plattform, haben Sie nur als eingeloggtes Mitglied Zugriff! |
Kapitel 4 Integrationsmanagement
In der Prozessübersicht fällt sofort auf, dass der Prozess „4.4, Projektwissen managen“, neu ist. Wer genau hinschaut, sollte sich jetzt fragen, warum dieser Prozess nun die Nummer 4.4 erhielt und nicht 4.5 oder 4.3.
Wer meine Analyse des Kapitel 1 gelesen hat, könnte die Antwort wissen. Im Kapitel 1 habe ich einen kleinen Schlenker in die Informationstheorie durchgeführt. Zeichen – Daten – Informationen – Wissen, so lautet die hierarchische Reihenfolge von unten nach oben. PMI – so vermute ich – hat dieses Konzept auf Seite 27 im PmBok Guide 6th übernommen und auf das Projektmanagement angepasst.
Sie finden dort auch einen Hinweis auf den Prozess 4.3. Der Prozess „4.3 Lenken und Managen der Projektarbeit“ erfasst alle Daten des Projekts, aus allen Wissensgebieten. Das lässt sich auf der Seite 91 verifizieren. Wobei die Beschriftung der „Arbeitsleistungsdaten“, nicht optimal gelungen ist. Man könnte meinen, die Arbeitsleistungsdaten wandern von 4.6 (Unternehmen/Organisation), in Richtung (4.3 Lenken und Mangen der Projektausführung). Dem ist nicht so. Die Arbeitsleistungsdaten fließen von 4.3 nach 5.5 bis 13.4. Dies sind die Steuerungsprozesse der Wissensgebiete, in denen die Daten in Informationen transformiert werden.
Sehr viel besser wird die Flussrichtung der Arbeitsleistungsdaten, im PmBok Guide 5th, Seite 80 angezeigt.
Verwirrend könnte für den Neuling auch sein, dass „Projektwissen managen“ in Abb. 4-7, 6th, nur aus Arbeitsleistungsdaten des Prozess 4.4 generiert wird. Dies wiederspricht der Informationstheorie. Zwischen Daten und Wissen ist immer die Stufe der Informationsgewinnung notwendig. Der PmBok Guide stellt allerdings nicht in jedem Flussdiagram alle Kausalitäten dar, da dies zu einer gewissen Unübersichtlichkeit führen kann. Um daher ein ganzheitliches Bild zu erhalten, muss der Leser andere Flussdiagramme im PmBok Guide wie bspw. die Abb. 4.9 (S.99) mit einbeziehen. Hier wird deutlich, dass der Projektmanagementplan, Projektdokumente, EEFs und OPAs weitere Trigger bilden. Trotzdem wäre es sinnvoll gewesen, auch einen expliziten Kontext zu den Steuerungsprozessen herzustellen, wie bspw. im PmBok Guide 5th, Seite 80, da diese die Informationen liefern, die notwendig sind, aus Daten Informationen zu aggregieren. Implizit wird dies durch den Projektmanagementplan und die Projektdokumente geleistet,.
Arbeitsleistungsdaten und Arbeitsleistungsinformationen
Was mir allerdings gar nicht gefällt, ist die Definition der Arbeitsleistungsdaten und Arbeitsleistungsinformationen in 4.5.1.3. : „Arbeitsleitungsdaten werden erst zu Arbeitsleistungsinformationen, wenn sie mit anderen Projektvariablen verglichen worden sind.“ Diese Definition verwirrt. Arbeitsleistungsdaten müssen interpretiert werden, sie können nicht verglichen werden. Beispiel:
Daten: CPI = 0,85 SPI = 0,90
Falls Sie keine Ahnung vom EVM haben, werden Ihnen diese Indizes nichts sagen. Es sind einfach nur Daten. Erst wenn Sie wissen, was CPI und SPI bedeuten, dann können Sie diese Daten interpretieren, nämlich: „Wir werden das Budget überschreiten und den Endtermin nicht einhalten können, wenn sich diese Zahlen stabilisieren.“ Allerdings gibt es noch viele andere Daten in einem Projekt, die integrativ interpretiert werden müssen. Zum Beispiel auch nicht monetäre Daten, wie bspw. Konfliktpotenzial. Wenn der Konfliktpegel in einem Team ständig steigt (Daten oder Datum), dann lassen sich daraus Schlussfolgerungen interpretieren, die durchaus in eine Terminprognose mit einfließen können.
Ein Vergleich macht nur Sinn, zwischen Plan-Daten und Ist-Daten, die interpretiert worden sind. In dem Fall werden Arbeitsleistungsinformationen in den Steuerungsprozessen verglichen. Nicht umsonst werden die erfassten Daten aus der Ausführungsprozessgruppe in die entsprechenden Steuerungsprozesse geleitet. CPI und SPI würden bspw. nie nach dem Prozess „Beschaffungen steuern“ geleitet sondern nach „Kosten steuern“.
Im gleichen Abschnitt 4.5.1.3, 2. Absatz wird gesagt: „Arbeitsleistungsdaten werden im Rahmen der Steuerungsprozesse gesammelt…“ Diese Aussage PmBok Guide 6 Kap.4 steht eklatant im Wiederspruch zu der Definition im PmBok 5th, Seite 58, 3.8 Absatz 1: „Projektdaten werden als Ergebnis verschiedener Ausführungsprozesse gesammelt… Die gesammelten Daten werden während verschiedener Steuerungsprozesse analysiert und aggregiert….“
Die unterstrichene Aussage steht auch im Widerspruch zur Abb. 1-7, 6th, wo die Arbeitsleistungsdaten als Ausgangswert der Ausführungsprozesse den Steuerungsprozessen zugeführt werden. Auch in dem Absatz 4.3.3.2, 6th, werden die Arbeitsleistungsdaten in „Lenken und managen der Projektarbeit“ gesammelt und als Ausgangswert den Steuerungsprozessen „zugeführt“.
Ich sehe die Definitionen des PmBok 5th hier eindeutig im Einklang mit der Informationstheorie des Fachbereichs Informatik. Im PmBok 6th, wird dies nicht mehr deutlich. Vor dem Hintergrund sehr präziser Fragestellungen in der PMP Prüfung, können diese Inkonsistenzen zu Problemen führen.
Kommen wir auf die oben gestellte Frage zurück: Warum erhält der Prozess „Projektwissen managen“, die Nummer 4.4.? Nun, der Prozess 4.3 liefert Daten aus allen Ecken des Projekts. Von daher ist es sinnvoll, den Prozess „Projektwissen managen“ auch numerisch gleich dahinter zu schalten.
Der Projektmanagementplan
Den Projektmanagement Plan (PMP) finden Sie im PmBok Guide 6 Kap.4 auf Seite 89. Daneben finden Sie auch die denkbaren Dokumente. Folgende Änderungen wurden im PMP vorgenommen:
1. Der Personalmanagementplan wurde in Ressourcenmanagementplan umbenannt.
2. Der Prozessverbesserungsplan (PVB) wurde ersatzlos gestrichen. Nach wie vor kommt es aber immer wieder zu Passagen im PmBok Guide 6th, in denen Prozessverbesserungen oder die Prozessanalyse Gegenstand der Beschreibungen sind. Es wäre auch sehr kritisch zu sehen, gäbe es keine Prozessanalyse mehr. Schließlich dient das Prinzip der kontinuierlichen Prozessverbesserung auch den Prozessen des Projektmanagements. Im PmBok Guide 5th auf Seite 551 wird der Prozessverbesserungsplan folgendermaßen definiert: „Er detailliert die Schritte zur Prozessanalyse, um wertschöpfende Tätigkeiten zu identifizieren“. Auf Seite 241, 5th, werden die Aufgaben des PVB noch detaillierter beschrieben.
Auf Seite 293 6th, wird die Prozessanalyse weiterhin als Teil der Datenanalyse benannt. Ob die Schritte der Prozessanalyse jetzt in einem anderen Dokument erfasst werden, ist mir bis hierher noch nicht bekannt. Sollte ich darauf stoßen, werde ich diesen Teil hier ergänzen. Bisher diente der PVB auch als Ausgangswert des Prozesses „Qualitätsmanagement planen“. Auch dieser Ausgangswert wurde ersatzlos gestrichen.
3. Drei neue Pläne kamen hinzu:
a. Fortschrittsmessungsbasisplan
b. Beschreibung des Projektlebenszyklus
c. Entwicklungsansatz
Wobei der Fortschrittsmessungsbasisplan (Performance Measurement Baseline (PMB – gut zu merken: Papa – Mama – Berta)) im PmBok Guide 5th, bspw. Seite 302, als zu aktualisierendes Dokument des PMP genannt wurde. Aber eben nicht in der Tabelle Seite 78, 5th. Auch wurde er in 10.2.3.2, 5th, als integratives Dokument für Inhalt und Umfang, Terminplan und die Kostenparameter benannt. Dies gilt auch für die Version 6. Hier wird die PMB sogar in den Steuerungsprozessen der Wissensgebiete Terminmanagement, Inhalt- und Umfangsmanagement und Kostenmanagement als Eingangs- und Ausgangswert dargestellt. Von daher wäre es sinnvoll, diesen Bezug schon in der Tabelle auf Seite 89, 6th, deutlich zu machen.
In 5th wurden bspw. in der PMP Tabelle Seite 78 die 3 untergeordneten Dokumente des Inhalts- und Umfangsplan dargestellt. Analog dazu könnten das Dokument für Inhalt und Umfang, der Terminplan und die Kostenparameter in der Tabelle von 6th als integrative Dokumente des Fortschrittsmessungsbasisplans (PMB) auch schon in der Tabelle auf Seite 89 dargestellt werden. Leider nicht und zusätzlich werden auch die drei untergeordneten Dokumente nicht mehr in der Tabelle Seite 89 dargestellt.
Der Projektlebenszyklus war im PmBok Guide 5. Version ein wichtiger Bestandteil des Kapitel 2: „Organisationsbedingte Einflüsse und Projektlebenszyklus“. In diesem PmBok Guide wurde der Projektlebenszyklus schon im 1. Kapitel sehr anschaulich besprochen. Aus agiler Perspektive könnte man den Zyklus auch als „Summe aller Sprints“ bezeichnen. Auch die Phasen eines klassischen Projektlebenszyklus können weniger als vier Wochen dauern.
Ein Dokument „Entwicklungsansatz“ kannte die PmBok Version 5 nicht. In der 6er Version werden bspw. die Entwicklungsansätze „Rollierende Planung“ und „ adaptive oder iterative Ansätze“ unterschieden (Seite 133). Aber auch Ansätze für Produktgenerierung oder Dienstleistungen werden als Entwicklungsansatz bezeichnet (Seite 88).
Beschreibung des Projektlebenszyklus und der Entwicklungsansatz bilden jetzt zudem Eingangswerte im Prozess 5.1, Inhalts- und Umfangsmanagement planen.
Weitere Änderungen im Kapitel Integrationsmanagement
Positiv zu bemerken ist, dass Eingangs- und Ausgangswerte wieder häufig mit ihren untergeordneten Dokumenten aufgelistet werden. Was mir fehlt, ist die 12 Punkte Aufzählung aus der Version 5, auf Seite 80 und 81. Diese Punkte haben mir im Training immer sehr geholfen, den Teilnehmern den Unterschied zwischen „Projektausführung Lenken und Managen“ sowie „Projektarbeit überwachen und steuern“ deutlich zu machen.
Fortsetzung für Kapitel 4 folgt
