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:
- Juni 2018: Die Zwiebel(grafik) im Projektalltag
- 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
- Der zyklische Prozess-Ablauf
- Skalen zur Bewertung (Ampel, Plus-Minus, 1bis5)
- …
Grafik des Monats Juni 2018: Die Zwiebelgrafik (im Projektalltag)
Zwiebelgrafiken (andere Bezeichnungen: Zwiebeldiagramme, gestapelte Venn-Diagramme) werden eingesetzt, um Abstände zu visualisieren. Der Name Zwiebelgrafik (engl. Onion Diagram) resultiert aus der zwiebelartigen Anordnung der einzelnen Elemente, die dann wie Zwiebelschichten wirken.
Die Abstände können beispielsweise resultieren aus:
- Zeitlicher Entfernung
- Räumlicher Entfernung
- Sozialer oder kultureller Entfernung
- …
Generell werden zur Erstellung einer Zwiebelgrafik drei bis sechs Kreise unterschiedlicher Größe übereinander geschoben. Alle Kreise liegen auf einer Bezugslinie (unten), sodass sich in etwa eine Zwiebelform ergibt. Die Kreise werden häufig mit unterschiedlichen Helligkeitsstufen einer Farbe eingefärbt, wobei der innere Bereich die dunkelste, der äußere Bereich die hellste Farbtönung erhält.
Abbildung 1.1: Die Zwiebeldarstellung (Minimalform)
Abbildung 1.2: Die Zwiebeldarstellung mit fünf Stufen
1.1 Anmerkungen / Varianten
Üblicherweise werden die Kreise der Zwiebelgrafik mit einer Farbe in verschiedenen Helligkeitsstufen eingefärbt. Es können aber auch unterschiedliche Farben verwendet werden (Abbildung 1.3). Hierbei sollte allerdings beachtet werden, das auch über Farben / Farbübergänge Zusammenhänge hergestellt werden.
Abbildung 1.3: Die Zwiebeldarstellung mit Farbvarianten
Um die Zwiebelform hervorzuheben, können die Kreise gestaucht oder gestreckt werden (Abbildung 1.4). Die gestreckte Variante ist besonders gut einsetzbar, wenn die Beschriftungstexte in den Kreisen mehr Platz benötigen.
Abbildung 1.4: Die Zwiebeldarstellung mit Formvarianten
1.2 Einsatz
Die Verwendung der Zwiebelgrafik ist nicht auf bestimmte Themengebiete beschränkt.
Häufig wird sie zur Beschreibung des Stakeholderumfelds eingesetzt (Abbildung 2.1), wobei dann auch die um 90 Grad (nach rechts) gekippte Variante benutzt wird. Um zu verdeutlichen, welche Stakeholder innerhalb und außerhalb der eigenen Organisation tätig sind, wird ein Farbübergang (orange nach blau) verwendet.
Abbildung 2.1: Die Zwiebelgrafik zur Darstellung des Stakeholderumfelds
Um die Planungshorizonte zu verdeutlichen, verwendet Mike Cohn /#Cohn-13/ eine “Planning Onion” (Planungszwiebel). Zur Hervorhebung (hier: Teamfokus) setzt er zusätzlich beschriftete Blockpfeile ein.
Abbildung 2.2: Die Planning Onion nach Mike Cohn /#Cohn-13/
Zur Verdeutlichung der Wahrnehmung des Verhaltens (von Personen) wurde von Hofstede /Hofstede17/ das Modell der Kulturzwiebel entwickelt. Nur die drei äußeren Schichten (auch Praktiken genannt) können wahrgenommen werden, der Kern (“die Werte”) erschließt sich nur indirekt über die drei äußeren Schichten.
Abbildung 2.3: Die Kulturzwiebel nach Hofstede /Hofstede17/
Um unterschiedliche Schwierigkeiten einer agilen Transformation zu beschreiben, hat Simon Powers eine “Agile Onion” (Agilitätszwiebel) entwickelt. Diese wird am linken und am rechten Rand mit zusätzlichen Informationen versehen (Abbildung 2.4).
Abbildung 2.4: Die Agile Onion nach Simon Powers /#Powers-16/
Die Projektzwiebel nach Hemmrich /Hemmrich17/ (siehe Abbildung 2.5) wird zur visuellen Verdeutlichung dafür herangezogen, dass es sich nicht lohnt, zu Beginn eines Projekts “Einsparungen” vorzunehmen, denn das Resultat ungenügender Definition und Planung ist am Ende ein Zusatzaufwand.
Abbildung 2.5: Die Projektzwiebel nach Hemmrich /Hemmrich16/
1.3 Auch zu finden in
Die Zwiebelgrafik ist in der oder anderen Form in folgenden Präsentationen und Büchern zu finden.
1.3.1 Eigene Präsentation
| Inhalt | Typ |
|---|---|
| Projektmanagement: Stakeholdermanagement – Eine Übersicht |  |
1.3.2 Literatur
- /Hemmrich16/ Angela Hemmrich, Horst Harrant: Projektmanagement. In 7 Schritten zum Erfolg, Hanser Wirtschaft, München 4. Auflage 2016, ISBN 978–3‑446–44620‑5
- /Hofstede17/ Geert Hofstede, Gert Jan Hofstede, Michael Minkov: Lokales Denken, globales Handeln: Interkulturelle Zusammenarbeit und globales Management, dtv, München 6. Auflage 2017, ISBN 978–3‑423–50952‑7
1.3.3 Weblinks
- /#Cohn-13/ Präsentationsfolien von Mike Cohn zu “Agile Planning and Project Management” aus dem Jahr 2013
- /#Powers-16/ Blogpost von von Simon Powers zu “What ist Agile” aus dem Jahr 2016
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 Klassifikation 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 Lernziele 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 grün gestrichelte Kreise dargestellt. Der Übergang zwischen beiden Zuständen wird die rot gestrichelte 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) | |
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/ 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 einordenbaren Elementen häufig eingesetzt. Dabei weist sie in der einfachsten Variante eine Dreiecksform auf, die von waagerechten Linien durchzogen ist, sodass 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
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/ Pyramide (Geometrie) in der deutschen Wikipedia
- /#Wiki-Prinzip-der-Pyramide/ Prinzip der Pyramide (Pyramidales Prinzip) in der deutschen Wikipedia
- /#Wiki-umgekehrte-Pyramide/ 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:
- Zunächst muss ermittelt werden, welcher Typ Weihnachtsbaum (Fichte, Kiefer, Tanne, etc.) besorgt werden soll. Hierzu kann beispielsweise der Familienrat einberufen werden
- Dann kann der Weihnachtsbaum (Kürzel: WB) besorgt werden
- Anschließend erfolgt das Aufstellen mit einem Weihnachtsbaumständer
- Das Schmücken kann danach vorgenommen werden
- Damit ist der Weihnachtsbaum “fertig” – jedoch darf er weiterhin (“fortlaufend”) geschmückt werden
- Irgendwann muss der Weihnachtsbaum abgeschmückt werden
- 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 vorgelagert?
- 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 (“wie viel 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 | |
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/ 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:
- Vor Beginn des Projekts wird mit der Machbarkeitsstudie abgeschätzt, welcher Größenordnung (“Rough Order Magnitude – ROM”) das Gesamtprojekt zuzuordnen ist
- Bei der Ausarbeitung des Projekts wird meistens eine Kosten-Nutzen-Analyse vorgenommen, über die das Projektbudget festgelegt wird
- 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 | |
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/ Cone of Uncertainty in der deutschen Wikipedia
- /#Wiki-Schätzung/ 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 beispielsweise meine Ausarbeitung → 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 1x2 Meter) zur Visualisierung
- selbstklebende Notizzettel (“Sticky Notes”, am besten mehrere Farben, Größe: mindestens 4x4 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 |
|---|---|
| Agilität: Kanban – Eine Kurzübersicht | |
| Agilität: Kanban – Eine Übersicht | |
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 2x2-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 |
|---|---|
| Projektmanagement: Stakeholdermanagement – Eine Übersicht | |
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-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: 3x3, 4x4, 5x5 oder 6x6). 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 (rot gestrichelte Linie). Also werden Maßnahmen benannt, deren Wirkung (blau gestrichelte 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 einem 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 |
|---|---|
| Projektmanagement: Risikomanagement – Eine Kurzübersicht | |
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-Risikomatrix/ Risikomatrix in der deutschen Wikipedia
Grafik des Monats August 2014: Die Balance zwischen Kosten und Nutzen
Um zu verdeutlichen, dass ein passendes 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 (blau 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, sodass 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) | |
| Projektmanagement: Risikomanagement – Eine Kurzübersicht | |
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-Andler-Formel/ 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 blau gestrichelte 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 Projektmanagement: Change Management – 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ögens 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 |
|---|---|
| Projektmanagement: Change Management – Eine Übersicht | |
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-J-Curve/ 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 (“unterbewusstes 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 (“unbewusstes 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 (und Business Analysis) – Eine Einführung (RE-Basispräsentation) | |
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-Kano/ 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) | |
| Projektmanagement: Kommunikation – Eine Übersicht | |
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-RACI/ 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:
- 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)
- 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)
- 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 | |
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:
- 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
- Storming – Auseinandersetzungs- oder Machtkampfphase: Die Unklarheiten bei der Umsetzung führen zu Konflikten zwischen den Teammitgliedern; diese Konflikte werden mehr oder weniger offen ausgetragen
- 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
- 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 vornherein) 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
Besonderes 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 Entwicklungsprozesses 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) | |
| Projektmanagement: Führung (und Team) – Eine Übersicht | |
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-Tuckman/ 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 (“controllt”) 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 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 Das magische Dreieck mit Ampeln
Ampeldarstellungen können zur vereinfachten Zusammenfassung des Projektstatus verwendet werden. Es wird hierzu beim magischen Dreieck für jede der drei Zielgrößen eine Ampel hinzugefügt (siehe Abbildung 2.3). 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 einzelnen Ampeln 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: Magisches Dreieck mit Ampeln
Ist eine 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 (“Das Erreichen der Projektzielgröße ist gefährdet”).
Abbildung 2.4: Legende zum magischen Dreieck mit Ampeln
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) | |
| Projektmanagement: Controlling – Eine Übersicht | |
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 2x2-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.
| Inhalt | Typ |
|---|---|
 |  |
Abb. 1.2: Variante 1 der Projektarten-Matrix | Abb. 1.3: Variante 2 der Projektarten-Matrix |
 |  |
Abb. 1.4: Variante 3 der Projektarten-Matrix | Abb. 1.5: Variante 4 der Projektarten-Matrix |
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 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) | |
| Projektmanagement: Führung (und Team) – Eine Übersicht | |
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–2021