von Renee Ossowski, PMP
Diese Zusammenfassung ist in großen Teilen i.d.R. nur für Leser verständlich, die an meinem Seminar teilgenommen haben oder anderweitig entsprechend vorgebildet sind.
1. Änderungen Kapitel1 „Einführung“:
· Die Interaktion und Darstellung der Beziehungen zwischen Projekten, Programmen und Portfolien wurde intensiviert und stärker vor dem Hintergrund des Projektmanagements der Organisation beschrieben.
Projekte, Programme und Portfolien müssen stärker an den Strategien des Unternehmens ausgerichtet werden. Im Umkehrschluss bedeutet diese Ausrichtung eine Stärkung des Unternehmenserfolgs (Business Value). Zwei Fragen sollen hierdurch beantwortet werden:
„Führen wir die richtigen Projekte durch?“ Strategische Fragestellung.
„Führen wir die Projekte richtig durch?“ Operative Fragestellung.
Das Rahmenwerk eines Unternehmens, das diese Intensivierung von Interaktionen zwischen den Projekten, Programmen und Portfolien und dem Unternehmen forcieren soll, wird als
„Organizationel Governance“ bezeichnet.
Diese „Organizationel Governance“ bildet einen Ordnungsrahmen, der sich an den Strategien des Unternehmens und den gesetzlichen Vorgaben orientiert.
· Beispiel: Gesetzliche Vorgaben – Risikomanagement
o Gemäß „Sarbanes Oxley Act“ (SOX) http://de.wikipedia.org/wiki/Sarbanes-Oxley_Act und „Gesetz zur Kontrolle und Transparenz im Unternehmensbereich“ (KonTrag) http://de.wikipedia.org/wiki/Gesetz_zur_Kontrolle_und_Transparenz_im_Unterneh mensbereich, sind Unternehmen verpflichtet, Maßnahmen zu ergreifen, die den Fortbestand des Unternehmens sichern. Dazu gehört auch die Risikobeurteilung der Projekte der Unternehmen. Obwohl das SOX ein Gesetz der USA ist, so sind doch auch alle weltweit USA – börsennotierten Unternehmen davon betroffen. (2351, PM3)
· Beispiel: Unternehmensstrategie
o Im Rahmen der Bosten-Matrix http://www.wirtschaftslexikon24.com/d/boston- matrix/boston-matrix.htm werden Geschäftsfelder (http://de.wikipedia.org/wiki/Gesch%C3%A4ftsfeld) nach „Marktwachstum und relativen Marktanteilen“ analysiert. Im Kontext dieser Bewertung kommen Strategien wie „Halten (Verteidigung des Marktanteils) – Ausbauen – Ernten – Rückzug“ zum Einsatz. Eine Strategie des Ausbauens heißt für den
Portfoliomanager, dass er im Rahmen der Portfolioanalyse Projekte auswählt, die in der Lage sind, den stärksten Mitwettbewerber Marktanteile zu nehmen. Für den Projektleiter dagegen bedeutet die Strategie des Ausbauens, dass er mit seinen Fachexperten zum Beispiel im Rahmen einer QfD Analyse http://de.wikipedia.org/wiki/Quality_Function_Deployment , die Stärken der
Konkurrenz bestens analysiert, um eigene Anforderungen an das Produkt daran auszurichten und die des Konkurrenten weit zu übertreffen. Geht es dagegen um eine Strategie des Haltens z.B. bezüglich des Haltens der Gewinne, wird es im Wesentlichen für die Spezialisten darum gehen, z.B. über Wertanalyse http://www.business-wissen.de/handbuch/wertanalyse/ und dem PM über Life cycle costing http://www.iff.uni- stuttgart.de/forschung/fabrikbetrieb/Seiten/lifecyclecosting.aspx, Herstellungspreise zu reduzieren.
· Des Weiteren wurden die zwischenmenschlichen Fähigkeiten des Projektmanagers intensiver beschrieben (S.18 PmBok 5th):
· Führung
· Teambildung
· Motivation
· Kommunikation
· Beeinflussung
· Entscheidungen
· Politisches und kulturelles Bewusstsein
· Verhandeln
· Vertrauensbildung
· Konfliktmanagement
· Coaching
Diese Fähigkeiten werden auf den Seiten 513 – 519 des PmBoks 5th sehr ausführlich beschrieben.
· Auf Seite 10 + 11 wird das PMO strukturierter dargestellt:
· Projekt unterstützendes PMO – Beratung, Training, Assets ehemaliger Projekte
· Projektüberwachendes PMO – sorgt für Einhaltung aller Richtlinien des Unternehmens
· Projekt strategisches PMO – intensiver Steuerungsaufwand durch PMO
· Der Hinweis auf Unternehmen, die den „Management by Projects MbP“ Ansatz umsetzen, ist nicht neu (S.14, 1.5.2.1 PmBok 5th). Diese Beschreibung wurde auch schon im PmBok 3th vorgenommen (PmBok 3th Seite 27, 2.3.1.). MbP sieht Operations und Projektmanagement nicht als zwei organisatorisch getrennte Systeme, sondern versucht beide Elemente zu einem Ganzen zu generieren und mit den Methoden des Projektmanagements zu erledigen (PmBok 3th Seite 8 letzter Absatz). So gehen auch viele Linienabteilungen in der MbP Organisation unter. Häufig verbleibt nur die Personalabteilung als ständige Instanz. Die Mitarbeiter werden dagegen von Projekt zu Projekt verschoben. Ein Kennzeichen einer MbP Organisation ist der reduzierte feste Mitarbeiterstamm. Viele Mitarbeiter werden als Externe beschäftigt um bei ausbleibenden Aufträgen schnell zu verschlanken
2. Kapitel 2 „Organisatorische Einflüsse und Projektlebenszyklus“ : Einige Änderungen und Neuigkeiten
· Die Inhalte in Kapitel 2 werden in einer anderen Reihenfolge dargestellt.
· Auch hier kommt der Begriff „Governance“ im Kontext der „Stakeholder Governance“ und „Project Governance“ vor.
Der Begriff “Governance” war vor 10 Jahren noch ein Fremdwort. Ursprünglich mal als „gutes Regieren“ verstanden, wird der Begriff heute in vielen Kontexten verwendet.
Hier soll Governance – auch als Corporate Governance bezeichnet – als organisatorische Projekt – und Unternehmensführung gedeutet werden, die den optimalen Ordnungsrahmen für die Leitung und Steuerung des Unternehmens oder auch der Stakeholder bildet.
Dieser Ordnungsrahmen ergibt sich aber auch im Kontext von Projekten und Stakeholdermanagement.
· Bezogen auf die temporären Projektorganisationen, werden jetzt zusätzlich die
Zusammensetzungen der Projektteams diskutiert. Speziell werden die „Zweckbestimmten Teams“ und die „Teilzeitteams“ beschrieben. Die „Zweckbestimmten Teams“ sind Teams, die vollkommen aus der Linie gelöst werden und nur dem Projekt zur Verfügung stehen. Häufig auch in der Ausprägung von virtuellen Teams eingesetzt, die weltweit verteilt agieren.
Die „Teilzeitteams“ bewegen sich in der Matrix zwischen Linie und Projekt.
· Ein erheblicher Neuansatz ergibt sich in der Darstellung verschiedener Projektlebenszyklen. Phase to Phase – sequentiell und überlappend – , Predictive Life Cycles, Iterative and Incremental Life Cycles und Adaptive Live Cycles.
· Phase to Phase – sequentiell und überlappend, sind ganz grundsätzliche (Basis-) Darstellungen, die auch bisher im PmBok beschrieben worden sind und auch als Grundmodell für die drei folgenden speziellen Life Cycles verwendet werden, wobei eine Phase dann auch einer Iteration oder einem Increment entsprechen kann.
Sequentielle Beziehungen erfordern immer den Abschluss der vorhergehenden Phase. Der Liefergegenstand der vorhergehenden Phase muss verifiziert (jetzt in 5th
„validiert“!!) werden und bildet den Input für die aktuell startende Phase.
Überlappende Phasen sollen vor dem Hintergrund von Fast Tracking eine Beschleunigung des Projekts erzeugen und damit einen früheren Markteintritt. Vor dem Hintergrund von Simultaneous Engineering soll aber auch eine interdisziplinäre Vorgehensweise forciert werden, die mehr Innovation und Kostenreduktion über frühzeitige Fehlererkennung forcieren soll http://de.wikipedia.org/wiki/Simultaneous_Engineering .
· Predictive Life Cycles werden in Umgebungen verwendet, in denen der Scope (Inhalt und Umfang) eines Projekts gut planbar ist. Die Anforderungen müssen im Vorfeld bekannt sein. Das Wasserfallmodell stellt hier das bekannteste Modell dar. http://de.wikipedia.org/wiki/Wasserfallmodell
· Iterative and Incremental Life Cycles kommt dem bisher von PMI dokumentierten Prinzip – Rolling Wave Planning – am nächsten. Es existiert auf der Zeitachse ein grober Scope, der aber in Form von Iterationen immer detaillierter ermittelt wird.
Iterationen werden auf Basis von „Use Cases“ gesteuert. Ein Use Case beschreibt sehr genau alle funktionalen und nicht funktionalen Elemente einer Ausführungseinheit. Z.B. folgende funktionale Anforderung an einen Roboter: „Der Roboter muss die Bodenplatte im Winkel von 45 Grad an den Motorblock anschrauben können“.
Die Iterationen werden solange durchgeführt, bis eine bestimmte Anforderung für ein
Use Case erfüllt ist. Als bekanntestes Modell kann man hier „Rational Unified
Process“ nennen. http://de.wikipedia.org/wiki/Rational_Unified_Process
„Rational
Unified Process RUP“ besteht aus 4 Phasen, in denen die Iterationen
stattfinden:
1. Inception – Konzept und Vision
2. Elaboration – Architekturprototyp
3. Construction – Entwickeln und Testen
4. Transition – Übergabe und Auslieferung
· Das V-Modell XT ist ein Mix aus Predictive Life Cycles und Iterative and
Incremental Life Cycles. Die linke Seite stellt
quasi ein Wasserfallmodel dar, auf der rechten Seite werden
die Iterationen durchgeführt. http://de.wikipedia.org/wiki/V-Modell
· Adaptive Live Cycles sind „User Stories“ orientiert. Im Gegensatz zum Use Case,
beschreibt eine User Story nur sehr elementar die Bedürfnisse aus Sicht eines
Users. Beispiel: „Ein Arzt möchte, wenn er morgens den Computer einschaltet,
alle Patienten des Tages
aufgelistet bekommen, die unter Diabetes leiden.“
Der Scope wird nur in sehr kurzen „Sprints“ (bei Scrum) geplant, Änderungen fallen daher
kostentechnisch kaum ins Gewicht. Neben Scrum ist „Extreme Programming EP“ ein
weiterer Vertreter dieser Cycles. EP ist aber noch weit agiler in seiner
Vorgehensweise als Scrum.
http://www.it-agile.de/fddtraining.html
3. Kapitel 3
„Projektmanagementprozesse“: Wenig Änderungen…
· außer einer Auslagerung der Prozessbeschreibungen in den Annex A1. Die
Auslagerungen in den Annex A1 gehen aber konform mit den bisherigen
Ausführungen im PmBok 4th.
· sowie eine genaue Definition des Begriffs„Projektinformationen“. Projektinformationen werden in Bereiche gegliedert:
· Arbeitsfortschrittsdaten
(Ausgangswerte der Prozesse der Ausführungsprozessgruppe): Daten ergeben sich
aufgrund von Überwachungsmaßnahmen wie Tests, Audits und sonstige Messungen.
Beispiel: CPI = 0,9 und SPI = 0,8
· Arbeitsfortschrittsinformationen
(Ausgangswerte der Überwachungs- und Steuerungsprozessgruppe) Ergeben sich
aufgrund der Einordnung und Interpretation der Daten: „Aufgrund des CPI und SPI
werden wir mehr für das Projekt bezahlen und später fertig werden.“
· Arbeitsfortschrittsberichte (Ausgangswert des Integrationsprozess
„Überwachen und Steuern der Projektarbeit“) Aufbereitung der Informationen in
entsprechenden Berichten mit grafischen Darstellungen und Kommentaren sowie
Assets für zukünftige Projekte.
Die Thematik wird auf Seite 467
näher beleuchtet.
4. Kapitel 4
„Integrationsmanagement“ : Im Integrationsmanagement
ergeben sich keine bedeutsamen Veränderungen. Hier und da wird auf die agilen
Methoden verwiesen.
·
Auf Seite 77 wird der PMP etwas intensiver beschrieben als bisher.
· Die Übersicht der PMP Inhalte
sowie der Projektdokumente wurde von Seite 350 auf Seite 78 verschoben.
· Die Definition für „Korrekturmaßnahmen“ hat sich geändert. Bisher
lautete die Definition auf S. 83 PmBok 4th:
o Dokumentierte Vorgaben für die Durchführung der Projektarbeit, um die erwartete künftige Leistung der Projektarbeit mit dem PMP in Einklang zu bringen
Bisher also, auch wenn für uns Deutsche nicht so richtig nachvollziehbar, eine proaktive, antizipierende Maßnahme. Das Wort „Korrektur“ passt da nicht so richtig aus unserer deutschen Sicht. Die neue Definition auf Seite 85 PmBok 5th lautet:
o An intentionel activity that realigns the performance oft the project work with
the project management plan.
„Realign“ wird übersetzt als „wieder ausrichten“. Diese Definition könnte dazu verleiten, die
„Korrektur“ als reaktive Maßnahme zu interpretieren. Auf S. 413 13.4.3.2 PmBok 5th wird allerdings wieder die alte Definition angewendet. Ich gehe davon aus, dass PMI in der Korrektur nach
wie vor eine antizipierende Maßnahme sieht.
Auf Seite 89 wird den Kosten- und Zeitprognosen ein enger Kontext zum EVM zugeschrieben.
· Auf Seite 91 werden einige neue „Analytische Techniken“ aufgezählt. Neu sind: Regressionsanalyse, Gruppierungsmethoden, Zeitserien, Fehlerbaumanalyse (Hinweise und Verlinkungen finden Sie im neuen Powerpoint Handout 5th, im digitalen Ordner)
·
Genau wie im PmBok 4th werden die „Abgelehnten Änderungsanträge“ nicht
mehr in den Prozessübersichten berücksichtigt. Im PmBok 3th Seite 79, findet
man die abgelehnten CRs als Ausgangswert bei „Integrierter Änderungssteuerung“
und bei „Überwachen und Steuern der Projektarbeit“ als Eingangswert. Die können sich in der Praxis eigentlich nicht in Luft auflösen.
5. Kapitel 5 „Projekt Inhalts- und Umfangsmanagement“: Ein neuer Prozess, allerdings schon im PmBok 3th Seite 105 enthalten, in der Version 4th entfernt und jetzt wieder vorhanden: Planung des Inhalts- und Umfangsmanagement. Ausgangswert ist der Plan für Inhalts- und Umfangsmanagement (Plan the Plan).
· Im Prozess „Anforderungen
sammeln“: Eine neue Kreativitätstechnik: Multikriterien
Entscheidungsanalyse, sowie zwei neue Werkzeuge: Kontextdiagramme und Dokumentenanalyse.
· Der Anforderungsmanagementplan wurde sinnvollerweise von den Ausgangswerten in die Eingangswerte verlagert. Dieser Plan ist auch ein „Plan the Plan“ Plan, der den Prozess „Sammeln der Anforderungen“ in seiner Durchführung beschreibt und somit kein Ausgangswert sein kann.
· Auf Seite 119 wird jetzt ein Beispiel einer „Rückverfolgbarkeitsmatrix“ aufgezeigt.
· Seite 124 werden Projektauftrag und Projektleistungsbeschreibung anhand eines Beispiels von einander abgegrenzt.
· Der Prozess „Inhalt und Umfang verifizieren“ wurde umbenannt in „Inhalt und Umfang validieren“
6. Kapitel 6
„Terminmanagement“: Ein neuer Prozess: Planen des Zeitmanagements. Ausgangswert ist der Zeitmanagementplan (Ein Plan the Plan).
·
Neue Grafiken auf Seite 157 und 158. Wobei die Darstellung der AE –
Beziehung jetzt bezogen auf das Beispiel in Prosa mehr Transparenz erbringt als
bisher, aber die Grafik auf Seite 157 meiner Ansicht immer noch verwirrt, da
sie auch abstrakt dargestellt wird. Zumindest wenn man MS-Project User ist.
Hier wird der Vorgang „A“ als Vorgänger dargestellt, obwohl er aus „realer
Zeitachsenansicht“ der Nachfolger ist. Sachlich richtig.
Aber hier hätte man eher die reale Abfolge auf der Zeitachse darstellen sollen,
um das Verständnis zu fördern. Durch das Beispiel der „Security“ (S. 156 PmBok
5th) wird der Zusammenhang jetzt aber etwas verständlicher.
PmBok 3th + 4th
hatten allerdings nur Prosa Definitionen, die vollkommen iritierten: „The
completion of the succsessor activity depends upon the initiation of the
predecessor activity.“
Sachlich richtig, aber bei dieser
Definition musste man auch wissen, dass der Vorgänger immer als
Vorgänger interpretiert wird, wenn er aufgrund der sachlichen Kausalität
steuert, egal ob zeitlich nachfolgend oder vorhergehend.
Im folgenden MS-Project Beispiel
ist dies der Fall: Vorgang 123 steuert über seinen Start das Ende von Vorgang
128. Er wird also trotzdem als Vorgänger interpretiert. Das hat übrigens nichts
mit der numerischen Reihenfolge zu tun. Der Vorgang „Schicht2“ könnte auch dem
Datensatzeiger 130
unterliegen.
Er wäre trotzdem als zeitlicher Nachfolger der „steuernde Vorgang
(Kausalzusammenhang)“ und damit der Vorgänger.
· Falsch ist die rechte Darstellung auf Seite 158. Hier handelt es sich nicht um eine SS – 15d Verknüpfung, sondern um eine SS + 15d Verknüpfung.
Bemerkung des Autors:
Auf Seite 171 wird im Rahmen der Analyse der Reserven wieder der Begriff der „ Known Unknowns“ ins Spiel gebracht. Diesen Begriff konnte man schon im PmBok 3th auf Seite 166 bezogen auf das Kostenmanagement finden. Known Unknowns stellen im Gegensatz zu den Unknown Unknowns Risiken dar, die vor dem Hintergrund der Eintrittswahrscheinlichkeit und des Auswirkungsgrads bewertbar sind. Risikoreserven für Unknown Unknowns stellen Reserven für nicht vorhersehbare Risiken dar und bedürfen eines genehmigten Change Request.
Die Risikoreserven, die bezogen auf Zeit und Kosten errechnet werden, wurden gemäß PmBok 3th Clusterförmig auf einen sogenannten „Dauer 0“ Vorgang der Baseline des Projektmanagers gebucht. Dieser „Dauer 0“ Vorgang verhinderte sogenannte „pessimistische Schätzungen“ bezogen auf einzelne Vorgänge.
Zitat PmBok 3th: „Demzufolge sind die Kostenabweichungen für Vorgänge der jeweiligen Gruppe von Terminplanvorgängen genauer, da sie auf nicht pessimistischen Kostenschätzungen beruhen“ (Vom Autor: Falls sie keine Risikoaufschläge enthalten).
Diese Erklärung ist im Kontext von EVM extrem wichtig, wird aber im PmBok 4th + 5th nicht mehr gegeben.
Im PmBok 5th wird nur noch gesagt: „Risikoreserven können für eine einzelne Aktivität, für das gesamte Projekt, oder auch Beides geschätzt werden (S. 206, 7.2.2.6).“
Die Problematik der „pessimistischen Schätzungen“ für einzelne Vorgänge wird hier nicht mehr diskutiert. Im Gegenteil, es wird darauf verwiesen, dass mit zunehmenden Informationen über das Projekt Risikoreserven (RR) reduziert werden können. Im Kontext zu EVM hieße dies (….und jetzt ist EVM Grundlagenwissen notwendig um die folgende Beschreibung zu verstehen), das die Plankosten (falls die RR in den Vorgängen enthalten ist) auf jeden Fall höher liegen, als die Soll- oder evtl. später die Ist-Kosten.
Aber schon die Reduktion der Sollkosten ergibt im EVM eine positive Prognose bezogen auf den CPI, obwohl nur nicht benötigte Risikoreserven reduziert wurden.
Im Kontext von EVM bedeutet dies des Weiteren, dass CPI und SPI nicht sonderlich aussagefreudig sind, wenn Zeit- und Kostenreserven unmittelbar auf die Vorgänge gebucht werden. Werden die Reserven nicht benötigt und steigen die aktuellen Kosten über den risikobereinigten Planwert eines Vorgangs, bleiben aber unterhalb des Planwerts inklusive Risikozuschlag, wird der CPI und SPI immer > 1.0 sein.
Gemäß der EVM Lehre sollten die Plankosten eines Vorgangs immer der potenziellen realen Wertschöpfung eines Vorgangs entsprechen. Dies wäre nicht der Fall, wenn die Risikoreserven im Vorgang enthalten wären. Meiner Ansicht nach sollten sie also in der PMB enthalten sein, in der Baseline (MS- Project) aber nicht. Erst wenn die Risikoreserven aufgrund eines Risikoeintritts fließen, erhöhen sie die aktuellen Kosten gegenüber der Baseline und verringern damit den CPI, was dann im Rahmen des Prozessvermögens der Organisation als Risikoeintritt dokumentiert werden könnte. Dies wäre eine sinnvolle Vorgehensweise.
Auch werden Risikoreserven häufig entfremdet eingesetzt. CPI und SPI würden auch in diesem Fall an Aussage Freudigkeit verlieren.
In der Grafik auf Seite 213 PmBok 5th wird sogar deutlich, dass die Risikoreserven über die Aggregierung der Vorgänge mit in die Control Accounts gebucht werden. Dies würde eine dezidierte Betrachtung von PV, EV und AC noch schwieriger machen.
Die „Dauer0“ Lösung aus dem PmBok 3th ist hier also nach wie vor vorzuschlagen, falls EVM betrieben wird.
4. Kapitel 7 „Projekt Kostenmanagement“: Ein neuer Prozess: Planen des Kostenmanagements. Ausgangswert ist der Kostenmanagementplan.
· Im Prozess „Kosten schätzen“ hat sich die Größenordnungsschätzung auf – 25% bis + 75% geändert.
Im PmBok 3th S. 161 waren das mal – 50% bis + 100%, im PmBok 4th S. 168 + – 50%. Allemal eine Prüfungsfrage wert.
· Die „Known + Unknown Unknowns“ auf Seite 206 wurden schon im Kapitel 6 Terminmanagement beleuchtet. Die Aussagen sind hier analog zu übertragen. Die neue Grafik auf Seite 213 ebenfalls.
· Die Grafik auf Seite 214 enthält keine Fehler mehr. In der Version 4th Seite 178 gingen Projekt Budget, EAC und BAC Werte am Ende alle konform. Das ist wohl für 99% aller Projekte unrealistisch. Im PmBok 3th S. 170 lief die Basisplankostenkurve vor der Kurve der Finanzierungsanforderungen. Das war auch keine korrekte Darstellung.
· Gut ist die neue Formelsammlung des EVM auf Seite 224. Allerdings wäre sie noch vollständiger, wenn für den EAC/ETC auch die Formeln EAC/ETC pessimistisch und EAC/ETC optimistisch dargestellt wären, um ein statistisches EAC Fenster zu errechnen. Prognosen mit Punktlandung sind relativ selten.
5. Kapitel 8 „Projekt Qualitätsmanagement“: Keine signifikanten Veränderungen.
· Neu ist die Grafik auf Seite 231. Hier werden die Beziehungen der Prozesse „Qualitätssicherung und Qualitätssteuerung“ zu IPECC (http://www.ipecc.com/ ), PDCA (Deming Zyklus) und den Prozessgruppen nach PMI aufgezeigt.
Die Projektion des PDCA Zyklus auf den Prozessgruppenzyklus, wurde schon in der Version 3th auf den Seiten 39 + 40 vorgenommen.
Die Grafik auf PmBok 5th S. 231 steht im Zusammenhang mit der Grafik auf Seite 235. Es wird deutlich, dass in den Planungs- und Ausführungsprozessgruppen durch Prävention oder unmittelbarer Fehlerbehebung, „Übereinstimmende Arbeit mit den Anforderungen“ erzeugt wird, was eine Reduzierung der Qualitätskosten (S.235) zur Folge hat. Auch „Überwachen und Steuern“ hat durch die Validierung einen Anteil an der Kostenreduktion.
„Nicht konforme Ergebnisse (S.235)“ dagegen, werden maßgeblich über reaktive Maßnahmen erzielt, im Rahmen von Endkontrollen, die Nacharbeit oder Ausschuss erzeugen.
· Auf Seite 236 werden jetzt die „Seven Tools of Quality Management“ von den anderen Werkzeugen abgegrenzt. Das war bisher nicht der Fall.
· Als einer der Flowcharts wird jetzt das SIPOC Modell (S.237) dargestellt. Im Rahmen der Zieldefinition bei Lean Six Sigma wird SIPOC als Werkzeug genutzt. Beispiele : http://de.wikipedia.org/wiki/SIPOC http://managementmethoden.info/TBSchlankheitWerkzeuge/TBSIPOC
· Auf Seite 245 werden einige neue Diagrammtypen dargestellt. Sie werden hier aber in Prosa und auch grafisch ausreichend erklärt.
6. Kapitel 9 „Projekt Personalmanagement“: Keine signifikanten Veränderungen.
· Anstatt „Entwickeln des Personalmanagementplans“ heißt der Prozess jetzt „Planen des Personalmanagementplans“.
7. Kapitel 10 „Projekt Kommunikationsmanagement“: Keine signifikanten Veränderungen.
· Die beiden Stakeholder bezogenen Prozesse wurden ausgegliedert in das neue Kapitel 13 „Projekt Stakeholdermanagement“. Die Prozesse „Planen der Kommunikation“ wurden umbenannt in
Planen des Kommunikation“, „Verteilen von Informationen“ in „Managen der Kommunikation“ und „Fortschritt berichten“ in „Steuern der Kommunikation“.
8. Kapitel 11 „Projekt Risikomanagement“: Keine signifikanten Veränderungen.
· Auf Seite 338 wird die Sensitivitätsanalyse besser erklärt und das darauf basierende Tornadodiagramm grafisch abgebildet.
9. Kapitel 12 „Projekt Beschaffungsmanagement“: Keine signifikanten Veränderungen.
· Folgende Prozesse wurden umbenannt: „Planen der Beschaffungen“ in „Planen des Beschaffungsmanagements“, „Verwalten der Beschaffungen“ in „Steuern der Beschaffungen“.
10. Kapitel 13 „Projekt Stakeholdermanagement“: Ein neues Kapitel, zumindest teilweise.
· Die Prozesse „Identifizieren der Stakeholder“ und „Managen der Stakeholdererwartungen“ existierten schon zuvor im Wissensgebiet „Kommunikationsmanagement“.
· Die Prozesse „Planen des Stakeholdermanagements“ und „Steuern der Stakeholderengagements“ sind neu.
· Der Prozess „Identifizieren der Stakeholder“ enthält auf Seite 396 ein neues Modell zur Einordnung der Stakeholder:
Ein Stakeholder, der beispielsweise in die Kategorie 1 (Definitive) fällt, wäre ein extrem wichtiger Stakeholder. Er verfügt über die Attribute „Rechtmäßig, Kraft (…voll) und Eindringlich.
· Der Prozess „Planen des Stakeholdermanagements“ erstellt den Ausgangswert
„Stakeholdermanagementplan“. Hier werden die anderen Prozesse des Kapitels 13 durchdacht und bezüglich ihrer Integration geplant. Die Werkzeuge und Techniken wurden auch bisher im Rahmen anderer Prozesse vorgestellt.
· Der Prozess „Steuern des Stakeholderengagement“ unterstellt eine gute Kenntnis des PM bezüglich der Beziehungen der Stakeholder untereinander. Dies ermöglicht dem PM die Effektivität und Effizienz der Kommunikation zu steuern. Die Werkzeuge und Techniken wurden auch bisher im Rahmen anderer Prozesse vorgestellt.
Eine Richtigstellung zum Schluss: Ein Fehler den ich im Seminar auf Basis PmBok 4th gemacht habe. Ich habe die „Ressource Break Down Structure RBS“, mit den jeweiligen Arbeitspaketen assoziiert. Dieses Dokument heißt aber OBS, Organizationel Breakdown Structure (Siehe S. 261 PmBok 5th). Der RBS dagegen wird als Darstellung aller Ressourcen (Material, Menschen, Equipment) im Projekt erklärt, um die Planung und Überwachung des Projekts zu erleichtern.
In der Akronym Übersicht PmBok 5th Seite 525 wird RBS nur noch als Akronym für „Risk Breakdown Structure“ verwendet. Wie aber Seite 261 zeigt, wird RBS auch weiterhin für „Ressource Break Down Structure“ verwendet.
