Grafik des Monats Umfassende Beschreibung von Einzelthemen durch Grafiken

Hier wird sporadisch, jeweils zu Monatsbeginn, eine Grafik des Monats zu „meinen Themen“ vorgestellt, die eine besondere Aufmerksamkeit verdient.

Gründe für die besondere Aufmerksamkeit können sein:

• Die Grafik ist besonders gelungen und wird daher häufig von Dritten zitiert
• Die Grafik ist sehr komplex und ohne weitere Erläuterung nicht unmittelbar verständlich
• Die Grafik wird sehr häufig in der Standardliteratur verwendet und gehört zum Grundlagen-Know-how

Wenn Sie einen Vorschlag für eine weitere, neue „Grafik des Monats“ machen möchten, so schreiben Sie mir einfach eine E-Mail (kontakt@peterjohann-consulting.de).

Vorbemerkungen

• Bei der „Grafik des Monats“ wird besonderer Wert auf die grafische Umsetzung und weniger auf die textuelle Ergänzung gelegt
• Jede „Grafik des Monats“ besteht häufig aus Varianten, die ansonsten nicht (gleichzeitig) in der Literatur zu finden sind
• Jede „Grafik des Monats“ kann auch nach Ablauf des Monats noch ergänzt und verbessert werden
• Die Weblinks und die Literatur zur „Grafik des Monats“ können jederzeit aktualisiert werden; hierdurch kann es sein, dass die Weblinks und Literatur neuer sind als die „Grafik des Monats“
• Zur Einordnung und Vertiefung können immer die Ausarbeitungen in meinen Präsentationen herangezogen werden

Die Grafiken des Monats bis heute

Folgende Grafiken wurden bislang erläutert:

• Juli 2016: Die Kompetenzstufen (und die Kenntnisse)
• Februar 2015: Die Pyramide(ngrafik im Projektalltag)
• Januar 2015: Die Vorgangsliste
• Dezember 2014: Der „Korridor der Unsicherheit“
• November 2014: Das Kanban-Board
• Oktober 2014: Die Stakeholder-Matrix (Stakeholder-Portfolio)
• September 2014: Die Risikomatrix
• August 2014: Die Balance zwischen Kosten und Nutzen
• Juli 2014: Die J-Curve der Veränderung
• Juni 2014: Das Kano-Diagramm
• Mai 2014: Die RACI-Matrix
• April 2014: Die Übersichtsgrafik der Earned Value Analysis
• März 2014: Die Teamentwicklungsphasen nach Tuckman
• Februar 2014: Das magische Dreieck des Projektmanagements
• Januar 2014: Die Projektarten-Matrix

Weitere mögliche Grafiken des Monats

Weitere Kandidaten für die Grafik des Monats:

• Zusammenhänge: Phasen, Prozesse, Werkzeuge und Methoden im Projektmanagement
• Die Kommunikationsmatrix
• Der Controlling-Regelkreis
• Das Risikoregister
• Die Stufen der Konflikt-Eskalation
• Die ITTO-Darstellung von PM-Prozessen
• Der zyklische Prozess-Ablauf
• Skalen zur Bewertung (Ampel, Plus-Minus, 1bis5)
• …

Grafik des Monats Juli 2016: Die Kompetenzstufen (und die Kenntnisse)

Kompetenzstufen und Kenntnisstände werden in allen Bereichen abgefragt, um so zugeschnittene Informationen an die entsprechenden Gruppen geben zu können. Dabei kommen verschiedene Stufungen zur Anwendung. In der Abbildung 1.1 ist „meine“ Stufung für das Projektmanagement wiedergegeben.

Abbildung 1.1: Eine Klassifikationen von Kompetenzstufen

Die Einordnung zu den Kompetenzstufen kann insbesondere erfolgen durch …

• Selbstbestimmung oder
• Ermittlung durch Dritte.

Bei beiden Ansätzen können verschiedene Verfahren zur Ermittlung des Kenntnisstands eingesetzt werden. Dies sind insbesondere:

• Beobachtung: Die Bewertung erfolgt aufgrund von (allgemeinen) Beobachtungen
• Assessment: Die Bewertung erfolgt auf Basis von vorgefertigten, schriftlichen oder mündlichen Assessments

Die Ermittlung des Kenntnisstands wird ebenfalls über Bewertungsschemata (wie „gering, mittel, hoch“, „1 … 5“ oder andere) vorgenommen. Die Zuordnung dieser Bewertungen zu den Kompetenzstufen wird hier nicht erläutertet, da dies sehr umfangreich werden würde.

1.1 Anmerkungen / Varianten

Die Skalen zur Bewertung von Kompetenzstufen sind uneinheitlich. Durchgesetzt haben sich drei- bis fünfstufige Unterteilungen. In der nachfolgenden Abbildung sind einige dieser Skalen wiedergegeben.

Abbildung 1.2: Die Klassifikation der Kompetenzstufen im Vergleich

Besonders häufig sind die Kompetenzstufen von Dreyfus zu finden, die auch hier als Grundlage verwendet wurden.

Das International Software Testing Qualifications Board (ISTQB) und das International Requirements Engineering Board (IREB) verwenden Know-how-Stufen um Lerniele zu definieren. Die Skaierung ist beim ISTQB vier- und beim IREB zweistufig.

Abbildung 1.3: Die Know-how-Stufen nach ISTQB

Abbildung 1.4: Die Know-how-Stufen nach IREB

1.2 Einsatz

Ist eine Zuordnung (von den Kenntnissen) zu den Kompetenzstufen bereits erfolgt, so kann diese weiterverwendet werden. Es gibt die Möglichkeit der …

• Festlegung, wohin man sich fachlich (und inhaltlich) entwickeln möchte oder soll.
• Klassifikation von Literatur oder Fachbeiträgen – für wen ist das Buch oder der Fachartikel gedacht (oder geeignet).

Die Festlegung , wohin man sich entwickeln möchte, kann einfach durch eine Anordnung der Kompetenzstufen in einer horizontalen Linie (Abbildung 2.1) oder einer vertikalen Skala (Abbildung 2.2) erfolgen. Der Ist-Zustand wird durch eine orange Markierung (Kreuzchen oder Pfeil) und der Soll-Zustand durch eine grüne Markierung verdeutlicht.

Abbildung 2.1: Die Kompetenzstufen in der Liniendarstellung

Abbildung 2.2: Die Kompetenzstufen in der Skalendarstellung

Die Kompetenzstufen beziehen sich in der Regel auf Einzelpersonen, jedoch können mit dem gleichen Schema auch Gruppen oder ganze Organisationen bewertet werden. Die nachfolgende Tabelle (Abbildung 2.3) dient zur Erfassung der Kompetenzstufen.

Abbildung 2.3: Die Kompetenzstufen für Organisationen

Als Besonderheit können hier noch Tiefe und Umfang erfasst werden. Diese Unterscheidung dient dazu, um individuell genauer Teilbereiche erfassen zu können. Beispielsweise sollte ein Projektplaner das Themengebiet Projektmanagement kennen (Umfang), jedoch muss er nicht alle Details des Projektmanagements (in der Tiefe) beherrschen.

In Abbildung 2.4 ist nun eine ausgefüllte Tabelle zu sehen, die Legende in der Abbildung 2.5.

Abbildung 2.4: Die Kompetenzstufen für Organisationen mit Entwicklungsvorgaben

Abbildung 2.5: Die Kompetenzstufen für Organisationen mit Entwicklungsvorgaben – Legende

Im dargestellten Beispiel wird eine Einzelperson und die dazugehörige Organisation betrachtet. In einem (Vorab-)Assessment wurden der Kenntnisstand ermittelt und Kompetenzstufen zugeordnet (orange Kreise). Hierauf aufbauend wurden die Soll-Zustände (Soll-Profile) definiert – hier durch gestrichelte grüne Kreise dargestellt. Der Übergang zwischen beiden Zuständen wird die gestrichelte rote Linie verdeutlicht. Zusätzlich wurden Zwischenpunkte eingebaut, die auf besondere Ereignisse beim Übergang hinweisen sollen – dies könnten Prüfungen, Audits oder auch Assessments sein.

1.3 Auch zu finden in

Die Klassifikationsstufen zur Darstellung des Kenntnisstands sind in der ein oder anderen Form in folgenden Präsentationen und Büchern zu finden.

1.3.1 Eigene Präsentation

	Inhalt	Typ
	Projektmanagement – Eine Einführung (PM-Basispräsentation)	(pdf)

1.3.2 Literatur

• /GPM14/ Deutsche Gesellschaft für Projektmanagement: Kompetenzbasiertes Projektmanagement (PM3), GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 6. Auflage 2014, ISBN 978-3-924841-40-9

1.3.3 Weblinks

• /#Wiki-Kompetenzstufen/ Artikel zu den „Kompetenzstufen“ in der deutschen Wikipedia
• /#Wiki-Personen/ „Kategorie: Personenbezeichnungen“ in der deutschen Wikipedia

Grafik des Monats Februar 2015: Die Pyramide(ngrafik im Projektalltag)

Die Pyramide(ngrafik) wird zur Visualisierung von sortier- oder einordbaren Elementen häufig eingesetzt. Dabei weist sie in der einfachsten Variante ein Dreiecksform auf, die von waagerechten Linien durchzogen ist, so dass mehrere Trapeze und ein Dreieck in der Spitze entstehen. Diese werden nach ab- oder aufsteigender Priorität einzeln beschriftet. In der nachfolgenden Abbildung wird über die Pyramide eine dreistufige Gewichtung von „sehr wichtig“ über „wichtig“ bis „weniger wichtig“ abgebildet.

Abbildung 1.1: Die Pyramidendarstellung (Minimalform)

Die Pyramidendarstellung ist aufgrund ihrer Einfachheit direkt zu verstehen: Häufig visualisiert sie im Wesentlichen eine Liste.

Nach der Wikipedia ist die Pyramide „eine mathematische dreidimensionale Grundform eines geometrischen Körpers“; möchte man den 3D-Aspekt mitberücksichtigen, so kann man ein Dreieck am Rand des ersten Dreiecks hinzufügen. Inhaltlich ändert sich hierdurch nichts, es ist lediglich eine optische Veränderung.

Abbildung 1.2: Die Pyramidendarstellung (optisch ergänzt)

Einige typische, universelle Pyramidenbeschriftungen sind in der nachfolgenden Abbildung wiedergegeben.

Abbildung 1.3: Typische Beschriftungen der Pyramiden

1.1 Anmerkungen / Varianten

Die Pyramidenform kann zur Visualisierung unterschiedlicher Sachverhalte verwendet werden. Eine generelle Einschränkung oder ein bevorzugtes Einsatzgebiet gibt es nicht.

In der Literatur gibt es Bücher zum „Prinzip der Pyramide“ /Minto05, Schoof13/; diese zeigen den Einsatz zur Strukturierung von Sachverhalten mit der Pyramidenform. Jedoch werden dort auch „Taxonomiebäume“ (wie „Und-oder-Diagramme“) zu den Pyramiden gezählt.

1.2 Einsatz

Die Verwendung der Pyramidenform ist nicht auf bestimmte Themengebiete beschränkt, jedoch in einigen Kontexten besonders häufig zu finden. Im Projektmanagement sind dies:

• Bei der Darstellung von Projektzielen
• Im Projektcontrolling
• Bei der Erklärung der Mitarbeiter- und Teammotivation

1.2.1 Bei den Projektzielen

Zur Ermittlung der Ziele in einem Projekt kann die Zielpyramide eingesetzt werden. Dabei wird im Allgemeinen von übergeordneten Zielkategorien über die Zielunterkategorien auf die einzelnen Ziele geschlossen (Top-Down-Ansatz). Sind die Einzelziele bereits bekannt, so können in einem Bottom-Up-Ansatz durch Clusterung die Zielkategorien und Zielunterkategorien benannt und die Einzelziele zugeordnet werden.

Abbildung 2.1: Die Zielpyramide

Als Beispiel für eine Zielpyramide ist hier ein Projekt „Neue Website“ mit den Oberzielen und Einzelzielen dargestellt.

Abbildung 2.2: Ein Beispiel für die Zielpyramide

Anmerkung:
Diese Form der Zielpyramide eignet sich sehr gut für den Einsatz in Zielworkshops, in dem die Zielpyramide auf Metaplanwänden verwendet wird.

1.2.2 Im Projektcontrolling

Im Projektcontrolling wird die Pyramidendarstellung zur Unterscheidung der einzelnen Controlling-Ebenen (strategisch, taktisch, operativ) eingesetzt.

Abbildung 2.3: Differenzierung im Projektcontrolling (nach /Fiedler13/)

Der „Informationsbedarf des Projektcontrollings“ kann ebenfalls über eine Pyramide visualisiert werden. Hierbei wird von den Absolut- oder Rohdaten über verdichtete Informationen (KPIs) auf den Projektstatus geschlossen.

Abbildung 2.4: Die Informationspyramide des Projektcontrollings

1.2.3 Bei der Mitarbeiter- und Teammotivation

Gerade bei den „weichen Themen“ ist die Pyramidendarstellung häufig zu finden. Ein sehr bekanntes Beispiel ist die Maslowsche Bedürfnispyramide, die hier in einer Variante abgebildet ist.

Abbildung 2.5: Die Maslowsche Bedürfnispyramide

Bei der Maslowschen Bedürfnispyramide werden die unterschiedlich gewichteten Bedürfnisse von Menschen dargestellt. Erst wenn die Bedürfnisse einer darunterliegenden Hierarchiestufe erfüllt sind, können die darüberliegenden einen Anreiz bilden und zum Hauptmotivator werden. Einzelne Personen können nur dann Höchstleistungen (über „Selbstverwirklichung“) vollbringen, wenn alle anderen Bedürfnisse erfüllt sind.

Weniger häufig zu finden ist die „Kasseler Teampyramide“, die den strukturellen Aufbau eines Teams zeigt.

Abbildung 2.6: Die Kasseler Teampyramide (nach /Wastian11/)

Anmerkung:
Die Kasseler Teampyramide hat eine gewisse Ähnlichkeit mit den Teamentwicklungsphasen nach Tuckman (siehe hierzu: Grafik Monats März 2014: Die Teamentwicklungsphasen nach Tuckman).

1.3 Auch zu finden in

Die Pyramidengrafik (im Projektalltag) ist (auch) in folgenden Präsentationen und Büchern zu finden.

1.3.1 Eigene Präsentationen

	Inhalt	Typ
	Projektmanagement – Eine Einführung (PM-Basispräsentation)	(pdf)
	Projektmanagement: Controlling – Eine Übersicht	(pdf)
	Projektmanagement: Ziele im Projekt, Zielentwicklung und SMARTe Zielformulierung – Eine Übersicht	(pdf)
	Projektmanagement: Führung und Team – Eine Übersicht	(pdf)

1.3.2 Literatur

• /Fiedler13/ Rudolf Fiedler: Controlling von Projekten: Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle, Vieweg + Teubner, Wiesbaden 6. Auflage 2013, ISBN 978-3-8348-1769-3
• /GPM12/ Deutsche Gesellschaft für Projektmanagement: Kompetenzbasiertes Projektmanagement (PM3), GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 5. Auflage 2012, ISBN 978-3-924841-40-9
• /Minto05/ Barbara Minto: Das Prinzip der Pyramide. Ideen klar, verständlich und erfolgreich kommunizieren, Addison Wesley, München 2005, ISBN 978-3-8273-7189-8
• /Schoof13/ Axel Schoof, Karin Binder: Auf den Punkt: Präsentationen pyramidal strukturieren: Erfolgreicher kommunizieren mit klaren Botschaften und ergebnisorientierter Struktur, Springer Fachmedien Wiesbaden 2013, ISBN 978-3-658-03228-9
• /Wastian11/ Monika Wastian, Isabell Braumandl, Lutz von Rosenstiel: Angewandte Psychologie für das Projektmanagement. Ein Praxisbuch für die erfolgreiche Projektleitung, Springer, Berlin 2. Auflage 2011, ISBN 978-3-642-19919-6

1.3.3 Weblinks

• /#Wiki-Pyramide/ Artikel zur „Pyramide (Geometrie)“ in der deutschen Wikipedia
• /#Wiki-Prinzip-der-Pyramide/ Artikel zum „Prinzip der Pyramide“ (Pyramidales Prinzip) in der deutschen Wikipedia
• /#Wiki-umgekehrte-Pyramide/ Artikel zum „Prinzip der umgekehrten Pyramide“ in der deutschen Wikipedia

Grafik des Monats Januar 2015: Die Vorgangsliste

Die Vorgangsliste – ein zentrales Element der Netzplantechnik – dient zur einfachen und schnellen Erfassung von einzelnen Vorgängen (auch Tätigkeiten oder Aktivitäten). Sie kann direkt erstellt werden ohne dass irgendwelche Voraussetzungen erfüllt werden müssten.

Beispielhaft wird hier die Vorgangsliste anhand des „Lebenszyklus eines Weihnachtsbaums“ (in einer Familie, zu Weihnachten) verdeutlicht.

Folgende 7 Schritte sind auszuführen:

1. Zunächst muss ermittelt werden, welcher Typ Weihnachtsbaum (Fichte, Kiefer, Tanne, etc.) besorgt werden soll. Hierzu kann beispielsweise der Familienrat einberufen werden
2. Dann kann der Weihnachtsbaum (Kürzel: WB) besorgt werden
3. Anschließend erfolgt das Aufstellen mit einem Weihnachtsbaumständer
4. Das Schmücken kann danach vorgenommen werden
5. Damit ist der Weihnachtsbaum „fertig“ – jedoch darf er weiterhin („fortlaufend“) geschmückt werden
6. Irgendwann muss darf der Weihnachtsbaum abgeschmückt werden
7. Zum Schluss (nach etwa 3 Wochen) sollte der Weihnachtsbaum entsorgt werden

Die einzelnen Schritte werden als einzelne Zeilen in die Vorgangsliste eingetragen, die dann so aussehen könnte:

Abbildung 1.1: Die Vorgangsliste „Weihnachtsbaum“

Die(se) Vorgangsliste enthält folgende Spalten:

• PSP-Code: Hierüber wird eine eindeutige Nummer für einen Vorgang (innerhalb eines Projekts / Projektstrukturplans) vergeben
• Vorgangsname: Bezeichnung des Vorgangs
• Dauer: Wie lange dauert dieser Vorgang?
• Vorgänger: Welcher Vorgang ist diesem Vorgang vorlagert?
• Nachfolger: Welcher Vorgang folgt nach diesem Vorgang?

Die Vorgangsliste kann als Ablauf- oder Netzplan visualisiert werden, indem die Vorgänge als Rechtecke dargestellt und über Pfeile miteinander verbunden werden. Ein gerichteter Pfeil bedeutet „folgt nach“.

Abbildung 1.2: Der Ablaufplan „Weihnachtsbaum“

Die Vorgangsliste wird in Projekten zur Aufbereitung von Projektstrukturplänen (PSPs) genutzt. Häufig wird der Projektstrukturplan zur besseren Visualisierung an Metaplanwänden erstellt und auf Teil- oder Unterprojekte runtergebrochen. In unserem Beispiel wurde das Teilprojekt „3.2 Weihnachtsbaum“ näher betrachtet und in 7 Arbeitspakete unterteilt. Die Arbeitspakete wurden dann in die Vorgangsliste (hier als einzelne Vorgänge) eingetragen.

Abbildung 1.3: Der Projektstrukturplan (PSP) zum Projekt „Weihnachten 2014“

1.1 Anmerkungen / Varianten

In unserem Beispiel wurden in der Vorgangsliste sowohl die Nachfolger- wie auch die Vorgängerbeziehung angegeben. Es reicht aber bereits eine der beiden Spalten aus – üblicherweise wird in der Minimalfassung nur die Nachfolgerbeziehung notiert.

Abbildung 1.4: Die Vorgangsliste „Weihnachtsbaum“ – Minimalfassung

Da sowohl der Vorgangsname wie auch die Dauer der einzelnen Vorgänge für die (zeitliche wie logische) Reihenfolge der Vorgänge keine Rolle spielen, könnte eine Vorgangsliste zur Erstellung des Ablaufplans wie folgt aussehen:

Abbildung 1.5: Die Vorgangsliste „Weihnachtsbaum“ – ohne Reihenfolge

In der Projektpraxis werden aus dem Projektstrukturplan Arbeitspakete abgeleitet, deren Dauer („welchen Zeitraum benötigt man?“) und Aufwand („wieviel Zeit muss man investieren?“) zur Umsetzung geschätzt werden. Diese Angaben können in einer erweiterten Vorgangsliste untergebracht werden.

Abbildung 1.6: Die Vorgangsliste „Weihnachtsbaum“ – Maximalfassung

Aus dieser Vorgangsliste können dann, unter Zuhilfenahme zusätzlicher Angaben, weitere Pläne, wie der Termin-, der Kapazitäts- oder der Kostenplan erstellt werden.

1.2 Einsatz

Die Vorgangsliste ist ein zentrales Element zur Strukturierung von Projekten. Auch wenn sie heute in Projekten meistens nicht mehr explizit, sondern implizit über Projektmanagement-Software-Systeme zum Einsatz gelangt, sollte man sie als Projektmanager einsetzen können. In der Literatur wird sie der Netzplantechnik zugerechnet.

1.3 Auch zu finden in

Beschreibungen zur Vorgangsliste, zum Ablauf- und Netzplan sowie zur Netzplantechnik sind in folgenden Präsentationen und Büchern zu finden.

1.3.1 Eigene Präsentation

	Inhalt	Typ
	Projektmanagement: Netzplantechnik – Eine Übersicht	(pdf)

1.3.2 Literatur

• /Schwarze14a/ Jochen Schwarze: Projektmanagement mit Netzplantechnik, NWB, Herne 11. Auflage 2014, ISBN 978-3-482-65241-7
• /Schwarze14b/ Jochen Schwarze: Aufgaben zur Netzplantechnik, NWB, Herne 6. Auflage 2014, ISBN 978-3-482-56226-6

1.3.3 Weblinks

• /#Wiki-Weihnachtsbaum/ Artikel zum Weihnachtsbaum in der deutschen Wikipedia

Grafik des Monats Dezember 2014: Der „Korridor der Unsicherheit“

Werden Schätzungen des Aufwands und der Dauer (für ein Projekt) durchgeführt, so sind diese immer mit einer Unsicherheit behaftet. Genaue Schätzungen sind aufwendig (und damit teuer) und werden daher meistens erst durchgeführt, wenn das Projekt weiter konkretisiert wird. Es ergibt sich somit ein „Korridor der Unsicherheit“ (englisch: Cone of Uncertainty), der die Schätzgenauigkeit im Verlaufe eines Projekts wiedergibt (Abbildung 1.1).

Abbildung 1.1: Der „Korridor der Unsicherheit“ (nach /Kerzner08/)

Im Laufe eines Projekts wird zu unterschiedlichen Zeitpunkten mit unterschiedlicher Genauigkeit geschätzt. Typischerweise sollten mindestens zu folgenden drei Zeitpunkten Schätzungen vorgenommen werden:

1. Vor Beginn des Projekts wird mit der Machbarkeitsstudie abgeschätzt, welcher Größenordnung („Rough Order Magnitude – ROM“) das Gesamtprojekt zuzuordnen ist
2. Bei der Ausarbeitung des Projekts wird meistens eine Kosten/Nutzen-Analyse vorgenommen, über die das Projektbudget festgelegt wird
3. Erst mit Projektstart und der Erstellung der konkreten Pläne (wie dem Projektstrukturplan – PSP) kommt es zur definitiven Schätzung auf Basis der Arbeitspakete

Die nachfolgende Tabelle gibt die Größenordnung der Abweichungen in den einzelnen Schätzphasen wieder.

Abbildung 1.2: Abschätzungen der Größenordnung (nach /Kerzner08/)

Andere Darstellungen des Korridors der Unsicherheit, wie hier in Abbildung 1.3 wiedergegeben, benennen die möglichen quantitativen Abweichungen konkret: In diesen Fall wird davon ausgegangen, dass die ersten Schätzungen in einem Projekt bis zu 250 % abweichen können. Diese Schätzunsicherheit nimmt im Laufe des Projekts immer weiter ab, mit Projektabschluss ist sie ganz verschwunden.

Abbildung 1.3: Prozentuale Abweichungen im Projektverlauf (nach /Jenny14/)

Betrachtet man die Ziele oder Anforderungen als Grundlage für die Schätzungen, so ergibt sich folgendes Bild (für die Zielklarheit):

Abbildung 1.4: Erhöhung der Zielklarheit im Projektverlauf (nach /Schelle08/)

Die blaue Linie gibt die gewünschte Reduzierung der Schätz-Unsicherheit wieder, die grüne Linie den tatsächlichen Verlauf, der insbesondere durch „bewusstes Nachschätzen“ entsteht.

1.1 Anmerkungen / Varianten

Über den „Korridor der Unsicherheit“ (dieser Begriff ist nicht fest etabliert und wird daher nicht einheitlich in der Literatur verwendet) können auch andere Betrachtungen vorgenommen werden. Dabei könnten folgende Werte (meistens tabellarisch) gegenübergestellt werden – dies sind beispielsweise:

• Kleine vs. große Projekte
• Kosten der erhöhten Genauigkeit in den einzelnen Projektphasen
• Unterschiedliche Schätzmethoden
• Erwartete und tolerierte Schätzungenauigkeit bei den einzelnen Stakeholdern
• Branchen, insbesondere Softwareentwicklung und Baubranche; während in der Softwareentwicklung Abweichungen um den Faktor 2 durchaus üblich sind, werden Abweichungen von über 20 % in der Baubranche selten toleriert

1.2 Einsatz

Die möglichen Schätzabweichungen sollten den Schätzern (und damit den Projektverantwortlichen) immer bewusst sein. Verbesserte Schätzungen mit erhöhter Genauigkeit sind nur dann sinnvoll, wenn der Aufwand für die Schätzung geringer ist als der Nutzen, der durch die verbesserten Schätzwerte entsteht.

Merkspruch: Verwechseln Sie nicht Schätzen mit Planen oder Berechnen.

1.3 Auch zu finden in

Beschreibungen zu den Abweichungen bei Schätzungen finden sich in einigen Präsentationen und Büchern: Hier sind nur diejenigen aufgeführt, die hier auch zitiert wurden.

1.3.1 Eigene Präsentation

	Inhalt	Typ
	Projektmanagement: Schätzen von Aufwänden – Eine Übersicht	(pdf)

1.3.2 Literatur

• /Jenny14/ Bruno Jenny: Projektmanagement. Das Wissen für den Profi, Vdf Hochschulverlag, Zürich 3. Auflage 2014, ISBN 978-3-7281-3565-0
• /Kerzner08/ Harold Kerzner: Projektmanagement – Ein systemorientierter Ansatz zur Planung und Steuerung, mitp-Verlag, Bonn 2. Auflage 2008, ISBN 978-3-8266-1666-2
• /Schelle08/ Heinz Schelle, Roland Ottmann, Astrid Pfeiffer: Projektmanager, GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 3. Auflage 2008, ISBN 978-3-9248-4126-3

1.3.3 Weblinks

• /#Wiki-Cone-of-Uncertainty/ Artikel zum Cone of Uncertainty in der deutschen Wikipedia
• /#Wiki-Schätzung/ Artikel zur Aufwandsschätzung in der Softwaretechnik in der deutschen Wikipedia

Grafik des Monats November 2014: Das Kanban-Board

Das Kanban-Board ist das zentrale visuelle Element von Kanban (zur Erklärung, was Kanban ist, siehe z.B. Kanban – Eine Kurzübersicht ). Über das Kanban-Board wird ein Prozess abgebildet, in dem die Prozessschritte über Spalten beschrieben werden. In Abbildung 1.1 ist ein Kanban-Board dargestellt, welches die vier Prozessschritte Angelegt, Bewertung, Bearbeitung und Beendet erfasst.

Die Aufgaben, die bearbeitet werden sollen, werden über Aufgabenzettel (auch Tickets genannt) erfasst. Durch Umhängen der Aufgabenzettel (entsprechend ihres Umsetzungsstatus) wird der Workflow nachgestellt/beschrieben.

Abbildung 1.1: Das Kanban-Board

In den jeweiligen Spalten wird notiert (hier als rote Zahlen), wie viele Aufgaben gleichzeitig in dem jeweiligen Prozessschritt bearbeitet werden dürfen, wobei ein rotes Sternchen (*) „beliebig viele“ bedeutet. Hierdurch wird die Menge an gleichzeitig bearbeitbaren Aufgaben (WIP = Work in Progress) pro Prozessschritt begrenzt.

Zur initialen Erstellung eines Kanban-Boards benötigt man:

• ein großes Board (mindestens 1×2 Meter) zur Visualisierung
• selbstklebende Notizzettel („Sticky Notes“, am besten mehrere Farben, Größe: mindestens 4×4 cm)
• Board Marker (Stifte, abwischbar, verschiedene Farben)
• evtl. schwarzes Klebeband (1-2 cm breit)

1.1 Anmerkungen / Varianten

Das Kanban-Board ist beliebig einsetzbar, um Prozesse abzubilden. Hier werden zwei spezielle Varianten beschrieben: Das Personal-Kanban-Board und das Portfolio-Kanban-Board.

Für den Einsatz bei Einzelpersonen oder bei kleinen Teams wurde Personal Kanban entwickelt /Benson13/. Dabei ist die Struktur des Kanban-Boards sehr einfach, aber fest vorgegeben (Abbildung 1.2).

Abbildung 1.2: Das Personal-Kanban-Board (nach /Benson13/)

Zur schnellen Visualisierung von Projekt-Portfolios kann ein entsprechendes Kanban-Board verwendet werden, welches einen schnellen Überblick der noch nicht begonnenen, der startfähigen und der laufenden Projekte gibt. In Abbildung 1.3 ist beispielhaft ein Portfolio-Kanban-Board dargestellt.

Abbildung 1.3: Das Portfolio-Kanban-Board

Typische Fragestellungen, die beim Portfolio-Kanban behandelt werden:

• In welchem Status befinden sich die einzelnen Projekte?
• Ist die Anzahl der Projekte angemessen? Werden weder zu viele noch zu wenige gleichzeitig bearbeitet?
• Gibt es U-Boot-Projekte?

1.2 Einsatz

Das Kanban-Board ist das zentrale Element beim Einsatz von Kanban. Dabei sollten bevorzugt physikalische Boards, d.h. in der Regel große Wandtafeln, eingesetzt werden, da diese einen sehr guten Überblick liefern und damit insbesondere die Kommunikation anregen und fördern.

Da Kanban keinen Prozess vorgibt, sondern bestehende Prozesse übernimmt, ist die Einstiegshürde für den Einsatz von Kanban und eines Kanban-Boards niedrig.

Durch das Ziehen von horizontalen Linien auf dem Board entstehen Bahnen, denen sogenannte Serviceklassen zugeordnet werden. In Abbildung 1.4 sind die vier Serviceklassen Expedite, Feature, Change Requests und Bugs eingebaut.

Abbildung 1.4: Das Kanban-Board mit Serviceklassen

Hierbei ist zu beachten:

• Die Zahlen zu den Bahnen begrenzen die Anzahl der gleichzeitig bearbeitbaren Aufgaben in den jeweiligen Serviceklassen
• Die „Expedite-Lane“ enthält diejenigen Tickets, die unabhängig von den anderen Tickets oder dem sonstigen Status unmittelbar in die Bearbeitung gelangen müssen

1.3 Auch zu finden in

Beschreibungen zu Kanban und zum Kanban-Board finden sich in folgenden Präsentationen und Büchern.

1.3.1 Eigene Präsentationen

	Inhalt	Typ
	Kanban – Eine Kurzübersicht	(pdf)
	Kanban – Eine Übersicht	(pdf)

1.3.2 Literatur

• /Anderson11/ David J. Anderson: Kanban: Evolutionäres Change Management für IT-Organisationen, dpunkt, Heidelberg 2011, ISBN 978-3-89864-730-4
• /Benson13/ Jim Benson, Tonianne DeMaria Barry: Personal Kanban: Visualisierung und Planung von Aufgaben, Projekten und Terminen mit dem Kanban-Board, dpunkt, Heidelberg 2013, ISBN 978-3-89864-822-6

1.3.3 Weblinks

• /#Wiki-Kanban-SW-d/ Kanban (Softwareentwicklung) in der deutschen Wikipedia

Grafik des Monats Oktober 2014: Die Stakeholder-Matrix (Stakeholder-Portfolio)

Als Stakeholder (von „to have stake in = Interesse haben an“) werden die von einem Projekt oder Vorhaben betroffenen Personen oder Gruppen bezeichnet. Das Stakeholdermanagement beschäftigt sich – als eigenständige Disziplin – mit der Identifikation, Analyse und Behandlung der Stakeholder und wird sowohl beim Projektmanagement wie auch beim Requirements Engineering verwendet. Auch im Change Management finden sich Stakeholder-Betrachtungen.

Die Stakeholder-Matrix ist ein Begriff im Stakeholdermanagement, der (leider) nicht eindeutig definiert ist, aber dennoch häufig und für unterschiedliche Themen verwendet wird. Hier wird daher auch nur eine mögliche Variante der Stakeholder-Matrix vorgestellt.

Das zentrale Element bei der Erfassung (die die Identifikation und Analyse umfasst) der Stakeholder ist die Stakeholderliste (auch Stakeholderregister, seltener Stakeholderverzeichnis), eine Tabelle, in der folgende Inhalte eingetragen werden:

• Wer ist der Stakeholder?
• Was ist seine Erwartung an das Projekt?
• Wie ist seine Einstellung zum Projekt?
• Wie ist sein (potenzieller) Einfluss auf das Projekt?

Abbildung 1.1: Die Stakeholderliste – Formular

Eine ausgefüllte Stakeholderliste könnte dann folgende Eintragungen haben:

Abbildung 1.2: Die Stakeholderliste – Beispiel

Die Erstellung der Stakeholderliste wird mit dem gleichzeitigen Erstellen einer grafischen Repräsentation als Kraftfeldanalyse bezeichnet. Hierzu wird pro Stakeholderlisteneintrag eine Ellipse in ein xy-Diagramm eingezeichnet. Dies kann folgendermaßen aussehen:

Abbildung 1.3: Die Kraftfeldanalyse

Setzt man die (grafische Darstellung der) Kraftfeldanalyse in eine 2×2-Matrix mit vier Quadranten um (vergleiche Grafik des Monats Januar 2014: Die Projektarten-Matrix), so erhält man folgende Darstellung, die als Stakeholder-Matrix (oder auch Stakeholder-Portfolio, seltener Stakeholder-Einfluss-Matrix) bezeichnet wird:

Abbildung 1.4: Die Stakeholder-Matrix (Stakeholder-Portfolio)

Diese Form der Stakeholder-Matrix wird auch als Einfluss/Einstellung-Diagramm oder in leicht abgewandelter Form als Macht/Interessen-Diagramm (engl. Power/Interest Grid) bezeichnet.

1.1 Anmerkungen / Varianten

Aufgrund der Einstellung zum Projekt und dem Einfluss auf das Projekt sollten die Stakeholder unterschiedlich „behandelt“ werden. Hierzu können folgende Empfehlungen (aus dem PMBOK Guide /PBG12-d/) herangezogen werden:

Abbildung 1.5: Die Stakeholder-Matrix (Variante mit Behandlungsempfehlungen nach PMI /PBG12-d/)

Entsprechend ihrer Einstellung zum Projekt und dem Einfluss auf das Projekt können die Stakeholder typisiert werden. Eine Variante wäre hierzu:

Abbildung 1.6: Die Stakeholder-Matrix (Variante mit Typenbezeichnungen)

Sowohl die Behandlungsempfehlungen wie auch die Typenbezeichnungen sind nicht unbedingt „schmeichelhaft“. Daher sollte die Einordnung der Stakeholder sehr bedachtsam durchgeführt werden.

Fast man die Varianten der Stakeholder-Matrix zusammen, so ergibt sich folgende Gesamt-Darstellung:

Abbildung 1.7: Die Stakeholder-Matrix (mit Quadranten und Tabelle)

Statt Einstellung und Einfluss werden in der Literatur (zusätzlich) andere Werte gegenübergestellt – dies sind beispielsweise:

• Macht und Einfluss
• Auswirkung und Einfluss
• Konfliktpotenzial und Einfluss
• Einfluss und Erwartungen
• …

1.2 Einsatz

Die Stakeholder-Matrix kann in Projekten zur schnellen Visualisierung der Stakeholder verwendet werden und kann dann für weitere Schritte wie die Stakeholderbehandlung oder Projektkommunikation herangezogen werden.

Anmerkungen:

• Die Kraftfeldanalyse sollte in jedem Projekt erstellt werden
• Soll Stakeholdermanagement durchgeführt werden, so empfiehlt es sich, die Bezeichnungen der Stakeholder-Matrix zu definieren, damit sie einheitlich verwendet werden können
• Bei größeren Projekten kann vor oder mit Projektstart eine Stakeholderklausur durchgeführt werden: Dort wird in mehreren Schritten eine Strategie zur Behandlung der Stakeholder erarbeitet

1.3 Auch zu finden in

Die Stakeholder-Matrix ist in folgenden Präsentationen und Büchern zu finden.

1.3.1 Eigene Präsentation

	Inhalt	Typ
	Stakeholdermanagement – Eine Übersicht	(pdf)

1.3.2 Literatur

• /PBG12/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Fifth Edition 2012, ISBN 978-1-935589-67-9
• /PBG12-d/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide). Fünfte Ausgabe, Project Management Institute, Philadelphia, Pennsylvania 2012, ISBN 978-1-62825-003-9

1.3.3 Weblinks

• /#OLEV-Stakeholder/ Stakeholder im Online-Verwaltungslexikon
• /#Wiki-d-Stakeholder/ Stakeholder in der deutschen Wikipedia

Grafik des Monats September 2014: Die Risikomatrix

Im Risikomanagement ist das Erkennen und die Behandlung von möglichen Risiken die zentrale Aufgabe. Dazu werden (in der praktischen Umsetzung) einzelne Risiken in dem Risikoregister (oder auch Risikoliste, seltener Risikokatalog oder Risikoprotokoll genannt) erfasst und pro Einzelrisiko die Wahrscheinlichkeit des Eintretens und die Auswirkung auf das Vorhaben (oder Projekt) beschrieben.

Um die Gesamtrisikosituation schnell erfassen zu können, werden die (wesentlichen) Risiken dann in die Risikomatrix, die mehrere Zeilen und Spalten umfasst, eingetragen. Diese kann im nicht-ausgefüllten Zustand folgendes Aussehen haben:

Abbildung 1.1: Die Risikomatrix

Die Risikomatrix ist ein zentrales Element im Projektmanagement und wird daher in nahezu jedem Projekt verwendet. Aber:

• Das Risikomanagement ist eine umfangreiche Disziplin. In Projekten wird häufig ein Risikomanagement-Prozess durchlaufen, der sich unter Anderem mit der Erstellung und Befüllung der Risikomatrix beschäftigt
• Obwohl die Risikomatrix einfach zu erklären ist, sollte ihr Einsatz in Unternehmen und Organisationen durch erfahrene Kräfte durchgeführt werden, denn die zugrundeliegenden Planungen und Skalen müssen vorab passend bestimmt werden

1.1 Anmerkungen / Varianten

Die Risikomatrix ist in verschiedenen Größen zu finden (typische Anordnungen: 3×3, 4×4, 5×5 oder 6×6). Zudem werden – gerade in der Literatur – häufig statt der Farbdarstellung Blau- oder Grautöne verwendet. Hier sind einige Varianten wiedergegeben – zur Großdarstellung bitte auf die jeweilige Abbildung klicken.

Abb. 1.2: Risikomatrix: Variante mit blauen Farben	Abb. 1.3: Risikomatrix: Variante in Grautönen
Abb. 1.4: Risikomatrix: Variante mit numerischer Skalierung	Abb. 1.5: Risikomatrix: Variante mit Maßnahmenempfehlung (nach /Rohr06/)

Die Bezeichnungen Auswirkung und Tragweite werden (hier, aber auch in der Literatur) gleichermaßen verwendet.

Um die (numerischen) Wahrscheinlichkeiten und Auswirkungen auf die Risikomatrix übertragen, kann eine Skala verwendet werden.

Abbildung 1.6: Die Risikoskala

Ergänzt man die Skala um Chancen, die neben den klassischen Risiken ebenfalls erfasst werden könnten, so ergibt sich eine erweiterte Skala, die so aussehen könnte /PBG12/:

Abbildung 1.7: Die Risikoskala (große Variante nach /PBG12/)

Das hier eingezeichnete rote Dreieck umspannt den sogenannten „Arrow of Attention“ – den Bereich, in dem sich Risiken (und Chancen) befinden, die besondere Aufmerksamkeit benötigen, da ihre Auswirkungen erheblich sein können.

1.2 Einsatz

Die Risikomatrix kann in Projekten zur schnellen Visualisierung von Risiken verwendet werden. Hierzu werden zunächst die Risiken aus dem Risikoregister auf die Risikomatrix übertragen.

Hier ein Beispiel: In diesem Projekt geht es darum, eine Sommerparty (in einer Gartenanlage) zu organisieren und auch durchzuführen. Folgende vier Risiken wurden vom Planungsteam im Risikoregister erfasst:

Abbildung 2.1: Das Risikoregister: Beispiel Sommerparty

Anmerkung:
Auf die exakte Unterscheidung zwischen Ursache – Ereignis – Auswirkung (in Form einer Risikosequenz beschrieben) wurde hier aus Vereinfachungsgründen verzichtet und stattdessen der Begriff „Risikobezeichnung“ verwendet.

Durch Eintragen der Einzelrisiken (Kreise mit Zahlen, die die Nummern aus dem Risikoregister repräsentieren) wird die Risikomatrix gefüllt.

Abbildung 2.2: Die Risikomatrix: Beispiel Sommerparty

Im Laufe des Projekts werden die einzelnen Risiken weiter beobachtet. Bei besonders kritischen Risiken werden dabei (möglichst frühzeitig) Maßnahmen benannt, durchgeführt und auf ihre Wirkung hin überprüft.

In unserem Beispiel liegen die beiden Risiken 2 und 3 außerhalb der Akzeptanzlinie (rote gestrichelte Linie). Also werden Maßnahmen benannt, deren Wirkung (blaue gestrichelten Pfeile) die Eintrittswahrscheinlichkeit und die Auswirkung auf das Projekt reduzieren. Wenn die Maßnahmen wie geplant wirken, so befinden sich die Risiken anschließend innerhalb der Akzeptanzlinie (gestrichelte Kreise 2 und 3).

Abbildung 2.3: Die Risikomatrix: Beispiel mit Maßnahmen

Weitere Anmerkungen:

• Bei größeren Projekten wird vor oder mit Projektstart eine Risikoklausur durchgeführt: Dort wird die Risikomatrix dann auf einer Metaplanwand bearbeitet, was bei der Diskussion über die Risikosituation hilfreich ist
• Die Risikomatrix kann direkt aus dem Risikoregister (mit einen Tabellenkalkulationstool) erstellt werden
• Bei Großprojekten kommen anstatt von Risikoregistern eigenständige Risikomanagementtools zum Einsatz, die insbesondere den zeitlichen Verlauf der Risiken überwachen und steuern
• In der Praxis treten häufig Schwierigkeiten bei der quantitativen Zuordnung der Risiken auf
• Die Risikomatrix kann auch direkt in die Statusberichte (eines Projekts) eingebaut werden

1.3 Auch zu finden in

Die Risikomatrix findet sich in der ein oder anderen Variante in vielen Präsentationen und Büchern, hier sind nur wenige Beispiele aufgeführt.

1.3.1 Eigene Präsentationen

	Inhalt	Typ
	Risikomanagement in Projekten – Eine Kurzübersicht	(pdf)

1.3.2 Literatur

• /PBG12/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Fifth Edition 2012, ISBN 978-1-935589-67-9
• /Rohr06/ Uwe Rohrschneider: Risikomanagement in Projekten: Die häufigsten Fallen und Gefahren – die besten Sofortmaßnahmen, Haufe, München 2006, ISBN 978-3-448-06819-1

1.3.3 Weblinks

• /#Wiki-d-Risikomatrix/ Die Risikomatrix in der deutschen Wikipedia

Grafik des Monats August 2014: Die Balance zwischen Kosten und Nutzen

Um zu verdeutlichen, dass ein passend Maß für die Durchführung einer Maßnahme oder Umsetzung eines ganzen Themengebiets (wie Qualitäts- oder Risikomanagement in Projekten) gefunden werden muss, kann eine Kosten-Nutzen-Balance-Darstellung verwendet werden (Abbildung 1.1).

Abbildung 1.1: Die Balance zwischen Kosten und Nutzen im Qualitätsmanagement

Ursprünglich stammt diese Beschreibung aus dem Qualitätsmanagement. Es werden die Kosten für Qualitätsmängel den Kosten für Qualitätsmaßnahmen gegenübergestellt. Durch Summation beider Kostenanteile ergibt sich eine Gesamtqualitätskostenkurve (in Abbildung 1.1 blau dargestellt), deren Tiefstpunkt den optimalen Qualitätsgrad wiedergibt (blaue gestrichelte Linie).

Die Übertragung dieser Darstellung auf das Risikomanagement ist einfach: Aus Qualitätsgrad wird Sicherheitsgrad, aus Gesamtqualitätskosten Gesamtrisikokosten, aus dem optimalen Qualitätsgrad der optimale Sicherheitsgrad (Abbildung 1.2).

Abbildung 1.2: Die Balance zwischen Kosten und Nutzen im Risikomanagement

1.1 Anmerkungen / Varianten

Die Übertragung auf andere Gebiete kann einfach vorgenommen werden. Hier ist beispielhaft das Maß an Dokumentation (= schriftliche Beschreibung von Sachverhalten) in einer Organisation oder in einem Projekt dargestellt.

Abbildung 1.3: Die Balance zwischen Kosten und Nutzen bei der Dokumentation

Für die Softwareentwicklung liefert die Gegenüberstellung (aus Abbildung 1.3) die Motivation für den Einsatz agiler Methoden (Abbildung 1.4). In /Bergsmann14/ heißt es dazu: „Jede Dokumentation unterstützt bis zu einem gewissen Grad die Flexibilität und die Effizienz und bremst sie ab einem gewissen (übertriebenen) Grad.“

Abbildung 1.4: Die Balance zwischen Kosten und Nutzen bei der (agilen) Dokumentation

1.2 Einsatz

Die Grafik an sich besagt zunächst nur, dass es ein zu viel und auch ein zu wenig und dazwischen eine optimale Menge an Tätigkeiten in einem Gebiet gibt. Wie das Optimum zu finden ist oder wie man sich ihm nähert, bleibt zunächst außen vor. Hierzu müssten die einzelnen Maßnahmen näher betrachtet werden.

Für das Qualitätsmanagement typische Maßnahmen sind hier kurz gelistet.

1.2.1 Qualitätssichernde Maßnahmen

• Testen
• Verfassen von Qualitätsberichten
• (regelmäßige) Reviews
• (regelmäßige) Audits
• …

1.2.2 Schadensreduzierende Maßnahmen

• Nachbearbeitung bei Abnahme (des Produkts)
• Fehlerbehebung vor Ort
• …

Um bewerten zu können, welche Maßnahmen ergriffen werden sollen, werden diese im Allgemeinen einer Gesamt-Kosten und -Nutzen-Betrachtung unterzogen, so dass sich ein Bündel von Maßnahmen ergibt, die praktisch verwendet/umgesetzt werden.

1.3 Auch zu finden in

Der Vergleich zwischen Kosten und Nutzen von Maßnahmen wird in folgenden Präsentationen und Büchern beschrieben.

1.3.1 Eigene Präsentationen

	Inhalt	Typ
	Projektmanagement – Eine Einführung (PM-Basispräsentation)	(pdf)
	Risikomanagement in Projekten – Eine Kurzübersicht	(pdf)

1.3.2 Literatur

Ein Vergleich zwischen Kosten und Nutzen von Maßnahmen ist in der Literatur häufig zu finden. Daher könnten hier viele Bücher zitiert werden.

• /Bergsmann14/ Johannes Bergsmann: Requirements Engineering für die agile Softwareentwicklung: Methoden, Techniken und Strategien zur erfolgreichen Umsetzung, dpunkt, Heidelberg 2014, ISBN 978-3-86490-149-2
• /GPM12/ Deutsche Gesellschaft für Projektmanagement: Kompetenzbasiertes Projektmanagement (PM3), GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 5. Auflage 2012, ISBN 978-3-924841-40-9

1.3.3 Weblinks

Der Vergleich zwischen Kosten und Nutzen wird auch im Internet häufig grafisch dargestellt. Hier sind nur einige Beispiele aufgeführt.

• /#SelfLinux-Sicherheit/ Grundlagen Sicherheit (SelfLinux)
• /#Wiki-d-Andler-Formel/ Die Andler-Formel in der deutschen Wikipedia

Grafik des Monats Juli 2014: Die J-Curve der Veränderung

Die J-Curve (oder auch J-Kurve) der Veränderung beschreibt die Leistungsfähigkeit einer Person oder einer Gruppe nach einem Veränderungsimpuls. Sie ist ein Modell für das Change Management.

Durch eine Veränderung („einen Change“) soll die Leistung einer Person, einer Gruppe oder einer Organisation(seinheit) erhöht werden. Hierzu werden Maßnahmen durchgeführt, die einen Veränderungsimpuls hervorrufen. Dieser führt in den seltensten Fällen zu einer unmittelbaren Steigerung der Leistung, sondern es ist zunächst ein Leistungsabfall zu beobachten. Dieses Verhalten kann durch eine Kurve beschrieben werden, die eine J-Form aufweist – die J-Curve (rote Linie). In der Grafik gibt die gestrichelte blaue Linie die gewünschte Leistung vor, die durch die Veränderung erreicht werden soll.

Abbildung 1.1: Die J-Curve der Veränderung

Bei Veränderungen wirken Kräfte, die den gewünschten Veränderungseffekt hemmen oder fördern können. Diese werden in der J-Curve-Darstellung hinzugefügt, um zu verdeutlichen, dass der unmittelbare Leistungsabfall und die nachfolgende Leistungserhöhung nicht nur durch den Veränderungsimpuls hervorgerufen werden, sondern insbesondere durch das Umfeld, welches die Kräfte beinhaltet, zurückzuführen ist.

Abbildung 1.2: Die J-Curve der Veränderung mit wirkenden Kräften

Zur Ermittlung der hemmenden und fördernden Kräfte kann die Kraftfeldanalyse verwendet werden – diese wird in der Präsentation Change Management in Projekten – Eine Übersicht – beschrieben.

1.1 Anmerkungen

Auslöser eines Veränderungsimpulses können sein: Vorahnung, Schock, Angst, Zorn, gezielte Einflussnahme. Dies sind gleichzeitig auch hemmende oder fördernde Kräfte.

Werden Veränderungen nicht durch eine einzige Maßnahme (oder einen Impuls) herbeigeführt, so gibt es eine Reihe von Veränderungsimpulsen, die nacheinander wirken. Ein einzelner Impuls reicht (noch) nicht aus, um das gewünschte Leistungsniveau zu erreichen.

Abbildung 1.3: Die J-Curve der Veränderung: Kaskadierende Variante (steigend)

Nicht immer folgt aus einem Veränderungsimpuls ein Ansteigen des Leistungsvermögens. Es kann auch zu einem Leistungsabfall kommen, bei dem jeder Veränderungsimpuls zu einem weiteren Absinken des Leistungsvermögen führt.

Abbildung 1.4: Die J-Curve der Veränderung: Kaskadierende Variante (sinkend)

1.2 Einsatz

Die J-Curve verdeutlicht, dass zwischen dem Beginn und dem Etablieren der Veränderung eine Zeitspanne liegt, in der das Leistungsniveau nicht auf dem höchsten Stand ist. Die Fragen in der Praxis sind nun:

• Wie lange dauert es, bis das geforderte oder gewünschte Leistungsniveau erreicht wird?
• Wie lange dauert es nach einem Veränderungsimpuls, bis das ursprünglichen Leistungsniveau wieder erreicht ist?
• Wie misst man die Leistungsfähigkeit?
• Wie fördert oder unterstützt man den Prozess der Leistungserhöhung?

Die J-Curve gibt zu diesen Fragen keine Antworten, sondern dient lediglich zur Visualisierung. Jedoch kann durch Hinzufügen von Werten (mit Leistungsfähigkeiten vor und nach dem Veränderungsimpuls) die J-Curve als Diskussionsgrundlage dienen.

Abbildung 2.1: Die J-Curve der Veränderung mit Werten

In diesem Beispiel könnten die Fragen lauten:

• Ist das Absinken der Leistung (hier auf 50 %) tolerierbar?
• Wie groß darf der unmittelbare Gesamtleistungsverlust (orange Fläche) sein?
• Ist den Beteiligten klar, dass der Gesamtleistungsverlust erst zum Zeitpunkt L wieder aufgeholt wird, da erst dann die zugewonnene Leistung (grüne Fläche) die gleiche Größenordnung erreicht?

1.3 Auch zu finden in

Die J-Curve der Veränderung wird in folgenden Präsentationen und Büchern beschrieben.

1.3.1 Eigene Präsentation

	Inhalt	Typ
	Change Management in Projekten – Eine Übersicht	(pdf)

1.3.2 Literatur

In der Literatur wird die J-Curve nur in wenigen Büchern zum Change Management erläutert.

• /Jellison06/ Jerald M. Jellison: Managing the Dynamics of Change: The Fastest Path to Creating an Engaged and Productive Workplace, McGraw-Hill Professional, New York 2006, ISBN 978-0-07-147044-5
• /Leopold13/ Klaus Leopold, Siegfried Kaltenecker: Kanban in der IT: Eine Kultur der kontinuierlichen Verbesserung schaffen, Hanser, München 2. Auflage 2013, ISBN 978-3-446-43826-2

1.3.3 Weblinks

In der deutschen Wikipedia wird der Ursprung der J-Kurve aus der Wirtschaftstheorie (Auswirkungen der Abwertung einer Währung) beschrieben – dort wird sie auch als „Hockeystick-Effekt“ bezeichnet.

• /#Wiki-d-J-Curve/ Die J-Curve in der deutschen Wikipedia

Grafik des Monats Juni 2014: Das Kano-Diagramm

Das Kano-Modell (nach Noriaki Kano, 1978) dient der Analyse von Kundenwünschen und basiert auf Kundenbefragungen und statistischen Auswertungen. In diesem Modell werden die Kundenanforderungen in drei Arten von Anforderungen (auch Faktoren oder Merkmale genannt) unterteilt:

• Basisanforderungen (expected or basic requirements) sind selbstverständlich vorausgesetzte Systemmerkmale („unbewusstes Wissen“)
• Leistungsanforderungen (normal or performance requirements) sind explizit geforderten Systemmerkmale („bewusstes Wissen“)
• Begeisterungsanforderungen (delightful or excitement requirements) sind Systemmerkmale, die der Stakeholder nicht kennt, diese erst während der Benutzung entdeckt und dann Begeisterung bei ihm hervorrufen („unterbewusstes Wissen“)

Grafisch umgesetzt ergibt sich das Kano-Diagramm.

Abbildung 1.1: Das Kano-Diagramm: Darstellung

Im Kano-Diagramm wird der Erfüllungsgrad der (Kunden-)Anforderungen der Kundenzufriedenheit gegenübergestellt. Selbst wenn die Basisanforderungen (rote Linie) immer vollständig erfüllt sind, führt dies nicht zur Erhöhung der Kundenzufriedenheit. Anders die Leistungsanforderungen (blaue Linie): Werden diese im Produkt umgesetzt, so können sie zur Erhöhung der Kundenzufriedenheit beitragen. Allerdings führt die unvollständige Umsetzung dieser Anforderungen zur Unzufriedenheit beim Kunden. Die Begeisterungsanforderungen (grüne Linie) hingegen tragen unmittelbar zur Kundenzufriedenheit bei, selbst wenn sie nur unzureichend umgesetzt wurden.

Die Begeisterungsanforderungen werden im Laufe der Zeit zu Leistungsanforderungen und schließlich zu Basisanforderungen.

Die Anforderungen im Kano-Modell können folgendermaßen charakterisiert werden:

Abbildung 1.2: Die Anforderungen im Kano-Modell

Beispiele für die drei Anforderungsarten im Kano-Modell:

Abbildung 1.3: Beispiele für Anforderungen im Kano-Modell

1.1 Anmerkungen

Die Ermittlung der Anforderungen im Kano-Modell erfolgt durch den Kano-Fragebogen. Hierzu werden je zwei Fragen (1. funktional – Eigenschaft gegeben; 2. dysfunktional – Eigenschaft nicht gegeben) mit fünf Antwortmöglichkeiten („das würde mich sehr freuen“, „das setze ich voraus“, „das ist mir egal“, „das könnte ich in Kauf nehmen“, „das würde mich stören“) vorgegeben.

1.2 Einsatz

Das Kano-Modell wird bei der Ermittlung von Anforderungen im Requirements Engineering (RE) eingesetzt. Jedoch wird aufgrund des Aufwands meistens keine komplette Kano-Analyse (mit Fragebogen) durchgeführt. Dennoch werden alle drei Anforderungsarten implizit über die unterschiedlichen Ermittlungstechniken erfasst.

Abbildung 2.1: Ermittlungstechniken im RE und das Kano-Modell (nach /Pohl11/)

In der Praxis sollte darauf geachtet werden, dass alle Basisanforderungen und Leistungsanforderungen weitestgehend vollständig im Produkt umgesetzt werden. Aber auch Begeisterungsanforderungen sollten vorhanden sein, um so den Kunden von der eigenen Innovationsfähigkeit zu überzeugen.

1.3 Auch zu finden in

Das Kano-Diagramm wird in folgenden Präsentationen und Büchern beschrieben.

1.3.1 Eigene Präsentation

	Inhalt	Typ
	Requirements Engineering – Eine Einführung (RE-Basispräsentation)	(pdf)

1.3.2 Literatur

In der Literatur ist das Kano-Diagramm in der ein oder anderen Form häufiger zu finden, so z.B. in den hier aufgeführten Büchern.

• /Pohl11/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering – Foundation Level – IREB compliant, dpunkt, Heidelberg 3. Auflage 2011, ISBN 978-3-89864-771-7
• /Rupp09/ Chris Rupp: Requirements-Engineering und -Management: Professionelle, iterative Anforderungsanalyse für die Praxis, Hanser, München 5. Auflage 2009, ISBN 978-3-446-41841-7

1.3.3 Weblinks

• /#Wiki-d-Kano/ Das Kano-Modell in der deutschen Wikipedia

Grafik des Monats Mai 2014: Die RACI-Matrix

Um Verantwortungen für einzelne (Teil-)Aufgaben Personen oder Rollen zuzuordnen, kann die Verantwortlichkeitsmatrix (engl. RAM – Responsibility Assignment Matrix) verwendet werden. Nach PMI /PBG12/ kann man hierzu die RACI-Matrix verwenden, die in den Zeilen die Aufgaben und in den Spalten die (möglichen) Rollen oder Personen benennt.

Abbildung 1.1: Die RACI-Matrix: Darstellung

Es stehen folgende Möglichkeiten der Zuordnung zur Verfügung:

• R = Responsible (verantwortlich): Verantwortlich dafür, dass die Aufgabe umgesetzt wird
• A = Accountable (zuständig): Verantwortlich im kaufmännischen und juristischen Sinn (Auftraggeber)
• C = Consulted (PMI: Consult) (beraten): Derjenige, der zur Umsetzung der Aufgabe herangezogen werden kann (bidirektionale Kommunikation)
• I = Informed (PMI: Inform) (informieren): Wird über das Ergebnis/den Fortschritt informiert (unidirektionale Kommunikation)

Was ist der Unterschied zwischen dem „R“ und dem „A“ in der RACI-Matrix? Beim „R“ ist derjenige gemeint, der die Aufgabe zur Umsetzung bringt (z.B. der Projektmanager), mit „A“ die Rolle angesprochen, die letztlich zustimmen muss (z.B. der Lenkungsausschuss). Pro Zeile sollte daher immer genau ein „R“ und im Idealfall auch nur ein „A“ zu finden sein, während „C“ und „I“ beliebig häufig auftreten dürfen. Es ist möglich, dass eine Rolle gleichzeitig responsible und accountable ist (auch wenn dies insbesondere bei wichtigen Aufgaben vermieden werden sollte).

Abbildung 1.2: Die RACI-Matrix: Erklärung

Die RACI-Matrix dient zwar der Zuordnung von Aufgaben, ist aber auch ein Kommunikationsinstrument, anhand dessen man die Aufgaben-Inhalte besprechen kann.

1.1 Anmerkungen

Die RACI-Matrix ist in vielen Varianten zu finden, wobei der Begriff RACI inzwischen mehrheitlich auch in der deutschen Literatur verwendet wird. Bei den Varianten sind oftmals die Zuordnung / Bedeutungen der einzelnen Buchstaben nicht immer eindeutig.

• RASIC (oder RASCI): Wie RACI-Matrix, jedoch mit einem S für Supportive (unterstützend)
• VMI-Matrix: Verantwortlich – Mitarbeit – Information; entspricht dem R, dem C und dem I der RACI-Matrix
• CAIRO (oder RACIO): O für Omitted (ausgelassen)
• RACI-VS (oder VARISC): V für Verify (prüfend)
• ZVMI, CIDA, DACI, RAPID …: Viele weitere Varianten (die hier nicht erläutert werden)

Eine Abwandlung der RACI-Matrix ist die RAEW-Matrix, bei der die Expertise (E – entspricht dem Know-how) und Work (W – definiert, wer es machen muss) ausgewiesen werden.

1.2 Einsatz

Die RACI-Matrix ist in ihren Einsatzmöglichkeiten nicht beschränkt. So ist sie beispielsweise zu finden

• bei Prozessen (allgemein)
• im Service-Bereich
• im familiären / häuslichen Bereich
• in Projekten

In Projekten kommt die RACI-Matrix insbesondere in den Vorphasen von Projekten zum Einsatz, da zu diesem Zeitpunkt noch kein Projektplan vorliegt. Ist ein Projektplan bereits erstellt/vorhanden, so benötigt man die RACI-Matrix nicht mehr, da die Zuordnung Aufgabe <-> Rolle bereits durch den Projektstrukturplan festgelegt ist.

Häufig ergibt sich aus der RACI-Matrix, dass bei einer einzelnen Person (oder Rolle) ein Großteil der Rs stehen. Dies deutet dann an, dass hier eine potenzielle Engstelle vorhanden ist.

Typischerweise kommt bei der RACI-Matrix ein Tabellenkalkulationsprogramm zum Einsatz. Dies hat zudem dem Vorteil, dass nach Rollen oder Gruppen gefiltert werden kann.

Durch Hinzufügen weiterer Spalten können auch (erforderliche) Zusatzelemente erfasst werden, so z.B. Dokumente.

1.2.1 Die Sitzung zur Erstellung der RACI-Matrix

Es ist vorteilhaft, wenn die RACI-Matrix zusammen mit allen Beteiligten in einer gemeinsamen Sitzung erstellt wird. Hierzu werden zunächst die Aufgaben gelistet (in den Zeilen) und dann die Rollen (in den Spalten). Anschließend wird die Matrix zeilenweise durchgegangen und einzelnen (anwesenden) Personen werden die Aufgaben zugeordnet. Es ist ratsam, die Diskussionszeit pro Zeile/Punkt zu begrenzen, um so die Gesamtdauer nicht ausufern zu lassen.

1.2.2 Einschränkungen

Ab einer bestimmten Anzahl wird die RACI-Matrix übersichtlich. Daher eignet sie sich in erster Linie für eine beschränkte Anzahl von Rollen und Aufgaben.

1.3 Auch zu finden in

Die RACI-Matrix wird in folgenden Präsentationen und Büchern beschrieben.

1.3.1 Eigene Präsentationen

	Inhalt	Typ
	Projektmanagement – Eine Einführung (PM-Basispräsentation)	(pdf)
	Projektmanagement: Kommunikation – Eine Übersicht	(pdf)

1.3.2 Literatur

In der Literatur ist die RACI-Matrix in der ein oder anderen Form häufiger zu finden, so z.B. in den hier aufgeführten Büchern.

• /Andler15/ Nicolai Andler: Tools für Projektmanagement, Workshops und Consulting: Kompendium der wichtigsten Techniken und Methoden, Publicis Corporate Publishing, Erlangen 6. Auflage 2015, ISBN 978-3-89578-453-8
• /PBG12/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Fifth Edition 2012, ISBN 978-1-935589-67-9

1.3.3 Weblinks

• /#Wiki-d-RACI/ Die RACI-Matrix in der deutschen Wikipedia

Grafik des Monats April 2014: Die Übersichtsgrafik der Earned Value Analysis

Die Earned Value Analysis (EVA) ist eine Methode zum Messen der Leistung in einem Projekt (zu einem Stichtag). Sie basiert auf einer integrierten Betrachtung von Leistung, Zeit und Aufwand (Kosten) – den Parametern des magischen Dreiecks (siehe Grafik des Monats Februar 2014). Die EVA ermittelt zu einem bestimmten Zeitpunkt (dem Stichtag) aus den Plan- und Ist-Kosten spezifische Leistungswerte (CV, SV, CPI, SPI und andere), die wiederum für Prognosen für die erwarteten Gesamtkosten (BAC) wie auch für den Fertigstellungszeitpunkt herangezogen werden können.

Die Earned Value Analysis ist relativ aufwendig durchzuführen und wird zumeist nur bei größeren Projekten eingesetzt. An dieser Stelle wird nicht die komplette EVA erläutert (dazu gibt es eine ausführliche Ausarbeitung, siehe Projektmanagement: Earned Value Analysis – Eine Übersicht ), sondern nur die zentrale Übersichtsgrafik, die häufig in der Literatur zu finden ist und alle wesentliche Größen der EVA auf einmal darstellt.

Abbildung 1.1: Die Earned Value Analysis: Schematische grafische Darstellung

Die drei Basisgrößen der Earned Value Analysis werden auf Basis des Kostenverlaufs und des Projektplans (mit den Arbeitspaketen und Fertigstellungsgraden) zu einem Stichtag ermittelt:

1. Der Planned Value (PV) – der Planwert zum gegenwärtigen Zeitpunkt; andere Bezeichnungen: BCWS (Budgeted Cost of Work Scheduled), BV (Burned Value), Plankosten, Geplanter Wert. Dieser Wert ergibt sich unmittelbar aus dem Kostenverlaufsplan (= Soll-Kostenverlauf)
2. Die Actual Cost (AC) – die zum Stichtag angefallenen Kosten; andere Bezeichnungen: ACWP (Actual Cost of Work Performed), BV (Burned Value), Ist-Kosten, Fertigstellungskosten. Dieser Wert ergibt sich unmittelbar aus dem Zahlungsplan (= Ist-Kostenverlauf)
3. Der Earned Value (EV) – der Wert der aufgrund des Fertigstellungsgrads geleisteten Arbeit; andere Bezeichnungen: BCWP (Budgeted Cost of Work Performed), Fertigstellungswert. Dieser Wert ergibt sich, wenn man den Fertigstellungsgrad in Relation zu den Ist-Kosten setzt

Die Basisgrößen werden ergänzt durch folgende Größen:

• Budget at Completion (BAC) – der Gesamtplanwert (oder Gesamtbudget); andere Bezeichnungen: Ursprünglich geplante Gesamtkosten des Projekts zum Projektende.
  Das Budget at Completion ist der Planned Value am Projektende und liegt somit bereits bei Projektstart fest
• Estimate at Completion (EAC) – Erwartete Gesamtkosten zum aktuellen Zeitpunkt;
  Formel: Siehe Präsentation zur EVA
• Estimate to Complete (ETC) – Erwartete Restkosten zum aktuellen Zeitpunkt;
  Formel: EAC – AC
• Variance at Completion (VAC) – Kostenabweichung am Projektende;
  Formel: BAC – EAC

Als abgeleitete Größen kommen dann hinzu:

• Cost Variance (CV) – Kostenabweichung;
  Formel: EV – AC
• Schedule Variance (SV) – Terminplanabweichung;
  Formel: EV – PV
• Cost Performance Index (CPI) – Kostenentwicklungsindex;
  Formel: EV / AC
• Schedule Performance Index (SPI) – Terminentwicklungsindex;
  Formel: EV / PV

Diese Größen lassen sich grafisch in einer Darstellung unterbringen.

Abbildung 1.2: Die Earned Value Analysis: Komplette grafische Darstellung

Mit Hilfe der Formeln der EVA und der grafischen Darstellung ist es möglich, die (voraussichtlichen) Gesamtkosten und den (voraussichtlichen) Fertigstellungszeitpunkt des Projekts abzuschätzen.

In diesem Fall liegen die aktuellen Kosten (AC, rote Kurve) über den geplanten Kosten (PV, blaue Kurve). Dies für sich wäre nicht schlimm (denn es könnte mehr Leistung erbracht worden sein), jedoch ist auch der erzielte Wert der Arbeit (EV, grüne Kurve) geringer als der geplante Wert (ebenfalls PV). So bedeutet es aber, dass den Kosten AC ein geringerer Wert EV gegenübersteht, woraus abgeleitet werden kann, das mehr Zeit benötigt wird, um die geplante Leistung zu erreichen – dies ist die „Terminabweichung aus Kostensicht“. Gleichzeitig zeigt das Fortschreiben der Kostenprognose (gestrichelter Bereich der roten Kurve), dass die Gesamtkosten (BAC) ebenfalls überschritten werden. Insgesamt scheint sich das Projekt in Schieflage zu befinden.

1.1 Anmerkungen

Die hier gewählten Bezeichnungen sind inzwischen bevorzugt so im Einsatz und folgen weitestgehend dem PMI /PBG12/. Zwar gibt es auch deutsche Begriffe (die auch über die DIN normiert sind), jedoch sind diese in der Praxis seltener zu finden.

Die Earned Value Analysis suggeriert aufgrund der mathematischen Formeln eine hohe Genauigkeit. Jedoch müssen für die Berechnung Annahmen getroffen werden, die das Ergebnis maßgeblich beeinflussen. Daher sollten diese Annahmen immer mitangegeben und in die Interpretation einbezogen werden.

1.2 Einsatz

Die Earned Value Analysis wird bevorzugt bei größeren Projekten eingesetzt, da der Aufwand zur Ermittlung der Größen nicht unerheblich ist. Zudem muss das Erfassen, Beschreiben und Melden des Projektfortschritts etabliert und projektübergreifend einheitlich sein.

Die Tabelle beschreibt alle (wesentlichen) Größen der Earned Value Analysis.

Abbildung 2.1: Die Earned Value Analysis: Tabelle mit allen Größen

1.3 Auch zu finden in

Die Earned Value Analysis wird in folgenden Präsentationen und Büchern beschrieben.

1.3.1 Eigene Präsentation

	Inhalt	Typ
	Projektmanagement: Earned Value Analysis – Eine Übersicht	(pdf)

1.3.2 Literatur

In der Literatur wird die Earned Value Analysis in einigen Büchern zum Projektcontrolling oder in Spezialwerken dargestellt.

• /Fiedler13/ Rudolf Fiedler: Controlling von Projekten: Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle, Vieweg + Teubner, Wiesbaden 6. Auflage 2013, ISBN 978-3-8348-1769-3
• /Flemming10/ Quentin W. Flemming, Joel M. Koppelman: Earned Value Project Management, Project Management Institute, Philadelphia, Pennsylvania, 4th Edition 2010, ISBN 978-1- 935589-08-2
• /PBG12/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Fifth Edition 2012, ISBN 978-1-935589-67-9
• /PBG12-d/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide). Fünfte Ausgabe, Project Management Institute, Philadelphia, Pennsylvania 2012, ISBN 978-1-62825-003-9
• /PMI-EVM11/ Project Management Institute: Practice Standard for Earned Value Management, Project Management Institute, Philadelphia, Pennsylvania 2nd Edition 2011, ISBN 978-1-935589-35-8
• /Wanner13/ Roland Wanner: Earned Value Management. So machen Sie Ihr Projektcontrolling noch effektiver, CreateSpace Independent Publishing Platform, Leipzig 3. Auflage 2013, ISBN 978-1-4840-5096-5

Grafik des Monats März 2014: Die Teamentwicklungsphasen nach Tuckman

Ein (sehr beliebtes) Modell zur Beschreibung der Teamentwicklung stammt von Bruce W. Tuckman aus dem Jahr 1965. Eine mögliche grafische Repräsentation dieses Modells stellt die Leistungsfähigkeit eines Teams einzelnen Entwicklungsphasen (die über die Projektlaufzeit auftreten) gegenüber.

Abbildung 1.1: Die Teamentwicklungsphasen nach Tuckman

Bei der Entwicklung eines Teams werden nach Tuckman folgende vier Phasen durchlaufen:

1. Forming – Orientierungsphase: Das Team findet sich zusammen, kennt sich aber noch nicht; sehr formaler und höflicher Umgang miteinander. Jeder macht das, was er kann
2. Storming – Auseinandersetzungs- oder Machtkampfphase: Die Unklarheiten bei der Umsetzung führen zu Konflikten zwischen den Teammitgliedern; diese Konflikte werden mehr oder weniger offen ausgetragen
3. Norming – Stabilisierungs- oder Organisationsphase: Es bilden und etablieren sich Spielregeln im Umgang miteinander. Ein „Wir-Gefühl“ entsteht und das Team unterstützt sich bei Problemen
4. Performing – Arbeits- oder Produktionsphase: Das Team arbeitet ohne Reibungsverluste miteinander und die (Projekt-)Arbeit steht im Vordergrund

Anmerkungen zu dieser grafischen Darstellung:

• Die Begriffe „Hügel der Euphorie“ und „Tal der Tränen“ stammen nicht aus dem Ursprungs-Modell nach Tuckman
• Die „minimal tolerierbare Leistung“ kann nicht objektiv (und von vorneherein) festgelegt werden. Aussagen wie „das Team streitet sich nur noch“ oder „das Team ist nur noch mit sich selbst beschäftigt“ deuten aber darauf hin, dass diese Leistungsschwelle unterschritten wurde

Anhand dieses Modells können einige wesentliche Aussagen getroffen werden:

• Ein Team entwickelt sich im Laufe der Zeit
• Das niedrigste Leistungsniveau ist nicht zu Beginn der Teamentwicklung, sondern erst nach einiger Zeit feststellbar
• Je nach Entwicklungsphase sind unterschiedliche Verhaltensweisen im Team zu erkennen
• Der Teamentwicklungsprozess sollte aktiv gesteuert oder beeinflusst werden
• Je nach Entwicklungsphase sollte der Teamleiter die Teamentwicklung unterschiedlich unterstützen oder fördern
• Das „Tal der Tränen“ sollte möglichst klein gehalten werden. Dies gelingt nur durch aktive Maßnahmen

1.1 Anmerkungen / Varianten

Die Entwicklungsphasen nach Tuckman sind gerade bei Projektteams besonders häufig wieder zu erkennen, da in der Regel Projektteams zu Projektbeginn nach fachlichen Kriterien zusammengestellt werden und somit die „soziale Komponente“ häufig im Hintergrund steht.

Die Phasen sind in der Regel nicht scharf voneinander getrennt. Zudem kann „ein Rückfall“ in eine vorherige Phase jederzeit erfolgen.

1.1.1 Ergänzung um eine fünfte Phase

Das Ursprungsmodell von Tuckman beschreibt nur 4 Phasen. In der Literatur findet sich gelegentlich als Ergänzung eine fünfte Phase, deren Bezeichnung und Beschreibung jedoch nicht einheitlich ist. Tuckman selbst hat 1977 als fünfte Phase „Adjourning“ (Auflösung) eingeführt. Folgende Beschreibungen sind zu finden:

• Adjourning – Ablösungsphase: Das Team wird mit Projektende aufgelöst
• Super-Performing – Höchstleistungsphase: Das Team arbeitet ohne Steuerung von außen zusammen und bringt herausragende Leistungen
• Reforming – Erneuerungsphase: Das Team stellt sich selbst neuen Herausforderungen, um so nicht in eine kontraproduktive Routine zu verfallen

1.1.2 Die Teamuhr

Eine Darstellungsvariante ist die Teamuhr (oder Teamentwicklungsuhr). In ihr werden die vier Phasen in einen Kreis eingezeichnet. Dies soll insbesondere verdeutlichen, dass sich die einzelnen Phasen wiederholen (können).

Abbildung 1.2: Die Teamuhr nach Tuckman

1.2 Einsatz

Je nachdem in welcher Entwicklungsphase sich das Team befindet, muss der Projekt- oder Teammanager mit unterschiedlichen Maßnahmen den Teamentwicklungsprozess fördern. Hierzu muss jedoch erkannt werden, in welcher Phase sich das Team befindet. Obwohl es für diesen Zweck (umfangreiche) Kriterienkataloge gibt, ist das Erkennen und Einordnen nicht ganz einfach.

Tipp: Verwenden Sie die englischen Begriffe Forming-Storming-Norming-Performing, da die deutschen Entsprechungen in der Literatur nicht immer einheitlich verwendet werden.

Üblicherweise wird zu der grafischen Darstellung der Teamentwicklungsphasen eine Tabelle hinzugefügt, in der das typische Teamverhalten und (mögliche) Maßnahmen zur Teamentwicklung benannt werden.

Abbildung 2.1: Die Teamentwicklungsphasen mit Charakterisierung und Maßnahmen

1.2.1 Besonders kritisch: Die Stormingphase

Besonderer Augenmerk sollte auf die Stormingphase gelegt werden, denn diese ist für Gesamtentwicklung entscheidend und es gilt einige Besonderheiten zu beachten.

• Während man zu Beginn des Entwicklungsprozess das (Pseudo-)Team sich selbst überlassen kann, so ist es hier unbedingt notwendig, als Projekt- oder Teammanager aktiv steuernd einzugreifen. Geschieht dies nicht, so kann das Team auseinanderfallen noch bevor es sich richtig zusammengefunden hat. Als Projekt- oder Teammanager kann man nicht erwarten, dass sich ein Team selbst organisiert
• In der Stormingphase werden die Spielregeln für die weiteren Phasen festgelegt. Problematisch ist hierbei, dass es einerseits ohne team-externe Hilfestellung nicht geht, andererseits zu viele Vorgaben dazu führen, dass das Team dauerhaft von außen geführt werden muss und der Projekt- oder Teammanager zum Dauerbetreuer wird
• Es kann sein, dass sich in dieser Phase herausstellt, dass nicht jeder ins Team passt. Hier muss der Projekt- oder Teammanager in der Lage sein, entsprechende Konsequenzen zu ziehen
• Schon darüber, wer die Spielregeln im Team festlegt, werden (interne) Führungsstrukturen aufgebaut
• Es sollten auch Sanktionsmaßnahmen festgelegt werden, die dann greifen, wenn ein Teammitglied gegen die Spielregeln verstößt

1.2.2 Einschränkungen

Das Phasenmodell ist in erster Linie für kleinere Teams gedacht. Ab einer gewissen Größe greift es nicht mehr.

1.3 Auch zu finden in

Die Teamentwicklungsphasen nach Tuckman werden in der ein oder anderen Form auch in folgenden Präsentationen und Büchern beschrieben.

1.3.1 Eigene Präsentationen

	Inhalt	Typ
	Projektmanagement – Eine Einführung (PM-Basispräsentation)	(pdf)
	Projektmanagement: Führung und Team – Eine Übersicht	(pdf)

1.3.2 Literatur

Vielfach sind in der Literatur sehr umfangreiche Charakterisierungen und Maßnahmenlisten zu finden.

• /GPM12/ Deutsche Gesellschaft für Projektmanagement: Kompetenzbasiertes Projektmanagement (PM3), GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 5. Auflage 2012, ISBN 978-3-924841-40-9
• /Litke05/ Hans-Dieter Litke: Projektmanagement für die Praxis, Hanser, München 2005, ISBN 978-3-446-22907-5
• /PBG12/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Fifth Edition 2012, ISBN 978-1-935589-67-9

1.3.3 Weblinks

• /#Wiki-d-Tuckman/ Das Phasenmodell nach Tuckman in der deutschen Wikipedia

Grafik des Monats Februar 2014: Das magische Dreieck des Projektmanagements

Zur Visualisierung der (permanent zu überprüfenden) Hauptaspekte in einem Projekt wird häufig das „magische Dreieck“ des Projektmanagements verwendet.

Abbildung 1.1: Das magische Dreieck des Projektmanagements

Die drei Hauptaspekte sind …

• Leistung oder Ergebnis (oder auch Umfang, manchmal stattdessen Qualität; die Bezeichnung Leistung ist besonders häufig im Projektcontrolling zu finden),
• Zeit (Dauer, Termin) und
• Aufwand (Kosten).

In der Darstellung wird meistens die Leistung an die Spitze des Dreiecks gesetzt, Zeit und Aufwand dann an die unteren Enden. Die drei Aspekte werden permanent überprüft und abgeglichen; ein Projekt ist nur erfolgreich, wenn alle drei Aspekte ausreichend erfüllt werden. Ein Projekt sollte „in Time, in Budget and in Quality“ („im Zeit-, Aufwands- und Leistungsrahmen“) sein.

Anhand des magischen Dreiecks kann verdeutlicht werden, dass die drei Aspekte voneinander abhängen. Möchte man beispielsweise die Leistung erhöhen, also den Umfang vergrößern, so muss man entweder den Aufwand vergrößern oder die Zeit verlängern. Abstrakt bedeutet dies, dass die Fläche des magischen Dreiecks gleich bleiben muss, wenn man die Aspekte verändert. Dies ist in der nachfolgenden Grafik dargestellt.

Abbildung 1.2: Das magische Dreieck des Projektmanagements: Flächengleichheit

In der Literatur ist gelegentlich auch eine Variante zu finden, bei der nicht die Ecken, sondern die Seiten des Dreiecks beschriftet werden. Die Bedeutung ist jedoch dieselbe.

Abbildung 1.3: Das magische Dreieck des Projektmanagements: Darstellungsvariante

1.1 Anmerkungen / Varianten

Das magische Dreieck ist in erster Linie im deutschen Sprachraum bekannt und entsprechend in der englischsprachigen Literatur kaum zu finden. Die Übersetzung lautet dann häufig „Triple Constraint“, „Iron Triangle“ oder „Magic Triangle“, in der englischen Wikipedia ist der Begriff „Project management triangle“ zu finden. Die drei Aspekte werden dann als „Scope, Time and Budget“ übersetzt; das magische Dreieck visualisiert dann den Spruch „We are on Scope, on Time and on Budget“.

1.1.1 Ziele im Projekt und das magische Dreieck

Ein Projekt kann anhand der Ziele überwacht und gesteuert („controlled“) werden. Gleiches gilt für das magische Dreieck: Auch dieses wird zum Controlling herangezogen. Der Zusammenhang zwischen den Zielen, unterschieden in die beiden Zielkategorien „Sachziele“ und „Abwicklungsziele“, ist in der folgenden Grafik dargestellt. Als weiterer Aspekt ist die „Qualität“ in die Mitte des Dreiecks geschrieben worden.

Abbildung 1.4: Das magische Dreieck und die Ziele im Projekt

Anstatt der Hauptaspekte Leistung, Zeit, Aufwand können die Ziele auch direkt an die Ecken des Dreiecks eingetragen werden, um so den Zusammenhang zwischen dem magischen Dreieck und den Zielen des Projekts zu betonen. Es ergibt sich eine Variante, die nachfolgend dargestellt ist.

Abbildung 1.5: Das magische Dreieck und die Ziele im Projekt: Darstellungsvariante

1.1.2 Das Teufelsquadrat nach Sneed

Durch Aufteilen des Aspekts Leistung in „Quantität“ und „Qualität“ entsteht das „Teufelsquadrat“, welches insbesondere in der Software-Entwicklung beliebt ist.

Abbildung 1.6: Das Teufelsquadrat nach Sneed

Der Begriff „Teufelsquadrat“ entstammt aus der Erkenntnis, dass man durch Veränderung eines der Aspekte die anderen Aspekte ebenfalls mit verändert werden muss – die aufgespannte Fläche muss erhalten bleiben. Soll beispielsweise (wie hier in der Grafik angedeutet) die Qualität erhöht (Pfeil 1 in der Grafik) und die Entwicklungsdauer (Pfeil 2) verringert werden, so müssen die Kosten erhöht und die Quantität verringert werden. Das innere blaue Quadrat wird in ein flächengleiches rotes Viereck umgewandelt.

1.1.3 Das Siebeneck im Projektmanagement

Eine erweiterte Variante des magischen Dreiecks ist das Siebeneck im Projektmanagement, welches entsteht, wenn man die Aspekte Qualität (Quality), Kundenzufriedenheit (Customer Satisfaction), Risiko (Risk) und Ressourcen (Resources) hinzufügt.

Abbildung 1.7: Das Siebeneck im PM

Diese Darstellung ist in der Praxis eher selten anzutreffen.

1.2 Einsatz

Die Darstellung des magischen Dreiecks wird häufig im Projektcontrolling und bei der Beschreibung von Projektrisiken verwendet.

1.2.1 Das magische Dreieck und die Risiken

Zu jedem Aspekt im magischen Dreieck können typische Risiken auftreten. Bei Rohrschneider /Rohr06/ werden dazu benannt:

Abbildung 2.1: Das magische Dreieck und typische Risiken

1.2.2 Das magische Dreieck und die Priorisierung

In Projekten können häufig nicht alle drei Aspekte des magischen Dreiecks gleichzeitig erreicht werden. Kerzner /Kerzner08/ empfiehlt zur Vermeidung von Konflikten, im Vorfeld eines Projekts den einzelnen Aspekten des magischen Dreiecks Prioritäten zuzuordnen (siehe Grafik).

Abbildung 2.2: Das magische Dreieck und die Priorisierung

1.2.3 Die Verwendung im Ampelreport

Der „Ampelreport“ dient zur vereinfachten Zusammenfassung des Projektstatus. Es wird hierzu beim magischen Dreieck für jede der drei Zielgrößen eine Ampel hinzugefügt (siehe Grafik). Es gilt dabei zu beachten:

• Die Grenzwerte für „grün“, „gelb“ und „rot“ müssen vorab festgelegt werden (siehe Legende)
• Durch Pfeile (rauf, runter, gleichbleibend) an den Ampeln werden die Veränderungen gegenüber dem letzten Stand festgehalten

Die Kommentierung der Ampel ist Pflicht; hier gibt es zwei mögliche, unterschiedliche Vorgaben:

• Jede Veränderung gegenüber dem letzten Stand muss erläutert werden
• Alle gelben und roten Ampeln müssen kommentiert werden

Abbildung 2.3: Der Ampelreport (Beispiel)

Ist die Ampel „grün“, so ist alles im Planbereich („Projektablauf nicht gefährdet“), bei „gelb“ gibt es relevante Planabweichungen („Projektablauf / Teilziele gefährdet“) und bei „rot“ ist eine massive Abweichung vom Plan festzustellen („Projektziel gefährdet“).

Abbildung 2.4: Legende zum Ampelreport

1.2.4 Das magische Dreieck im klassischen und agilen PM

Zur Verdeutlichung der Unterschiede zwischen klassischem und agilem Projektmanagement wird die übliche Darstellung (für das klassische PM) einer um 180 Grad gedrehten Variante (für das agile PM) gegenübergestellt.

Abbildung 2.5: Das magische Dreieck im klassischen und agilen PM

Dabei wird das klassische Projektmanagement folgendermaßen charakterisiert:

• Alle Anforderungen (die die Leistung beschreiben) sind vollständig definiert und festgeschrieben
• Der Zeitraum ist geplant
• Der Aufwand (= Ressourcen wie Kosten und Mitarbeiter) können erhöht werden, um die Fertigstellung zu beschleunigen

Demgegenüber steht das agile Projektmanagement, für das festgehalten wird:

• Anforderungen sind grob beschrieben und priorisiert
• Im festgelegten Zeitraum müssen die wichtigsten Anforderungen umgesetzt werden
• Der Aufwand (= Ressourcen wie Kosten und Mitarbeiter) ist festgelegt und wird gesteuert, um innerhalb des Aufwandrahmens zu bleiben

1.3 Auch zu finden in

Das magische Dreieck ist in der ein oder anderen Form auch in folgenden Präsentationen und Büchern enthalten.

1.3.1 Eigene Präsentationen

	Inhalt	Typ
	Projektmanagement – Eine Einführung (PM-Basispräsentation)	(pdf)
	Projektmanagement: Controlling – Eine Übersicht	(pdf)

1.3.2 Literatur

• /Fiedler13/ Rudolf Fiedler: Controlling von Projekten: Mit konkreten Beispielen aus der Unternehmenspraxis – Alle Aspekte der Projektplanung, Projektsteuerung und Projektkontrolle, Vieweg + Teubner, Wiesbaden 6. Auflage 2013, ISBN 978-3-8348-1769-3
• /GPM12/ Deutsche Gesellschaft für Projektmanagement: Kompetenzbasiertes Projektmanagement (PM3), GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 5. Auflage 2012, ISBN 978-3-924841-40-9
• /Kerzner08/ Harold Kerzner: Projektmanagement – Ein systemorientierter Ansatz zur Planung und Steuerung, mitp-Verlag, Bonn, 2. Auflage 2008, ISBN 978-3-8266-1666-2
• /Rohr06/ Uwe Rohrschneider: Risikomanagement in Projekten: Die häufigsten Fallen und Gefahren – die besten Sofortmaßnahmen, Haufe Verlag, München 2006, ISBN 978-3-448-06819-1

Grafik des Monats Januar 2014: Die Projektarten-Matrix

Die Projektarten-Matrix dient zur Einordnung von Projekten nach ihrer Komplexität und ihrem Innovationsgrad. Hierzu wird eine 2×2-Matrix verwendet, auf deren X-Achse der Innovationsgrad und auf der Y-Achse die Komplexität erfasst wird.

Abbildung 1.1: Die Projektarten-Matrix

In den vier Quadranten sind zu finden:

• Routineprojekte: Projekte, die keine große Herausforderung für Organisationen darstellen sollten, da sie weder einen hohen Innovationsgrad noch eine hohe Organisations-Vernetzung (Komplexität) aufweisen. Typisches Beispiel: Organisation von Betriebsfeiern.
• Komplexe Standardprojekte: Projekte, deren Endprodukt zwar bekannt ist, die aber aufgrund einer hohen Anzahl von Beteiligten und Realisierungs-Details eine hohe Komplexität aufweisen. Typisches Beispiel: Bauprojekte.
• Potenzialprojekte: Projekte, die zwar technische Neuerungen erfordern, aber deren Aufgabenstellung keine sonderlich hohe Komplexität aufweisen. Typisches Beispiel: Entwicklung/Ableitung einer Low-Cost-Variante eines technischen Produkts.
• Pionierprojekte: Projekte, die die eine Herausforderung für Organisationen darstellen, da sowohl das Endprodukt wie auch die Art und Weise, wie man zum Produkt gelangt, Neuland darstellen. Typisches Beispiel: Komplette Neuentwicklung eines technischen Bauteils, welches auch eine neue Produktionsumgebung mit einem neuen Produktionsverfahren benötigt.

Die Grenzen zwischen den Projektarten sind fließend, eine eindeutige Zuordnung eines Projekts zu einer dieser Projektarten ist nicht immer möglich. Daher sollte diese Darstellung nur zur groben Einordnung herangezogen werden.

1.1 Anmerkungen / Varianten

Die Projektarten-Matrix findet sich häufig, wenn auch modifiziert, in der Literatur, ohne dass ein Erfinder oder Urheber benannt werden könnte; hier sind einige Varianten wiedergegeben – zur Großdarstellung bitte auf die jeweilige Abbildung klicken.

Abb. 1.2: Variante 1 der Projektarten-Matrix	Abb. 1.3: Variante 2 der Projektarten-Matrix (nach /SchuWi02/)
Abb. 1.4: Variante 3 der Projektarten-Matrix (nach /Reichert11/)	Abb. 1.5: Variante 4 der Projektarten-Matrix (nach /Drees10/)

Der Begriff „Projektarten-Matrix“ ist für diese Darstellung nicht standardisiert; vielfach wird anstatt von Projektarten auch von Projektklassen oder Projektkategorien gesprochen.

1.2 Einsatz

Die Projektarten-Matrix dient in erster Linie zur Verdeutlichung, dass Projekte je nach Randbedingungen unterschiedlich behandelt werden müssen. Pionierprojekte erfordern immer besondere Aufmerksamkeit (auch durch das Management) und sollten besonders intensiv geplant, überwacht und gesteuert werden. Bei Routineprojekten hingegen kommt es eher darauf an, das passende Maß für den Einsatz von Projektmanagement zu finden.

Wenn man in einer Runde von Projektmitarbeitern oder Projektmanagern die Frage stellt, wo sie sich mit ihrem Projekt einstufen würden, wird überwiegend auf das Pionierprojekt gewiesen – offenbar ist das Prestige dieser Projektart sehr hoch. Gleichzeitig würden die gleichen Projektmitarbeiter und Projektmanager darauf verweisen, dass sie auf große Teile des Projektmanagement-Instrumentariums verzichten können, da dies für das eigene Projekt ein zu viel an Aufwand darstellen würde. Diesen Widerspruch gilt es aufzulösen.

Ein Ableiten von notwendigen Verhaltensweisen („Wir haben ein großes Standardprojekt, also müssen wir die komplexen Verhaltensweisen berücksichtigen.“) aus der Einordnung heraus ist jedoch meistens nicht zielführend, da die Einordnung von „außen nach innen“ erfolgt: Wenn ein Projekt komplexe Verhaltensweisen erfordert, so ist es als möglicherweise als „großes Standardprojekt“ zu bezeichnen.

1.3 Auch zu finden in

Die Projektarten-Matrix ist in der ein oder anderen Form auch in folgenden Präsentationen und Büchern enthalten.

1.3.1 Eigene Präsentation

	Inhalt	Typ
	Projektmanagement – Eine Einführung (PM-Basispräsentation)	(pdf)

1.3.2 Literatur

• /Drees10/ Joachim Drees, Conny Lang, Marita Schöps: Praxisleitfaden Projektmanagement: Tipps, Tools und Tricks aus der Praxis für die Praxis, Hanser, München 2010, ISBN 978-3-446-42183-7
• /Reichert11/ Thorsten Reichert: Projektmanagement. Die häufigsten Fallen, die wichtigsten Erfolgsfaktoren, Haufe, München 2011, ISBN 978-3-648-01114-0
• /SchuWi02/ Heinz Schulz-Wimmer: Projekte managen, Haufe, München 2002, ISBN 978-3-448-04786-8

Letzte Aktualisierung: 28.12.2016 © Peterjohann Consulting, 2005-2018