Grundlagen des Projektmanagements

Abbildung 1 - ICB-Elemente in den Grundlagen des PM

 

Die im Folgenden erläuterten Begriffe – Projekt, Projektmanagement, Prozess, Aufgabe, Projektportfolio, Projektmanagement-Office und Projektarten sind Inhalte der ICB-Elemente Governance, Strukturen und Prozesse und Projektdesign.

Governance, Strukturen und Prozesse (4.3.2) „Die Kompetenz Governance, Strukturen und Prozesse definiert das Verständnis für und die Abstimmung mit den gewachsenen Strukturen, Systemen und Prozessen der Organisation, welche Unterstützung für Projekte bieten und Einfluss auf ihre Organisation, ihre Einführung und ihr Management haben.“ [GPM17a, Seite 47]

 

Projektdesign (4.5.1) „Die Kompetenz Projektdesign definiert, wie die Bedürfnisse, Wünsche und Einflüsse der Organisation(en) von Einzelnen interpretiert und gewichtet werden und auf das höchste Level des Projektdesigns übertragen werden, um die höchste Erfolgswahrscheinlichkeit sicherzustellen.“ [GPM17a, Seite 106]

Begriffsklärung

4.3.2 Governance, Strukturen und Prozesse / Bloom’sche Taxonomie 2 – Verstehen

4.5.1 Projektdesign / Bloom’sche Taxonomie 2 - Verstehen

Begriff	Erklärung
Projekt	Die DIN 69901 nennt ein Projekt  ein „Vorhaben, das im Wesentlichen durch die Einmaligkeit seiner Bedingungen gekennzeichnet ist“. [DIN16a] Gemäß der ICB 4.0 ist ein Projekt „ein einmaliges, zeitlich befristetes, interdisziplinäres, organisiertes Vorhaben, um festgelegte Arbeitsergebnisse im Rahmen vorab definierter Anforderungen und Rahmenbedingungen zu erzielen.“ [GPM17a] Die daraus abgeleiteten Merkmale eines Projekts sind Einmalig, neu Begrenzte Ressourcen Fachlich und sozial komplex Mindestens ein Ziel Definierter Anfang und definiertes Ende Projektspezifische Organisation
Projektmanagement	In der DIN 69901 wird Projektmanagement als „Gesamtheit von Führungsaufgaben, -organisation, -techniken und –mitteln für die Initialisierung, Definition, Planung, Steuerung und den Abschluss  von Projekten“ definiert. [DIN16a] Die ICB 4.0 ergänzt dazu „Projektmanagement befasst sich mit der Anwendung von Methoden, Tools, Techniken und Kompetenzen für ein Projekt, um Ziele zu erreichen.“ [GPM17a] Projektmanagement ist eine temporäre Aufgabe während der Laufzeit eines Projekts.
Prozess	Allgemein stellt ein Prozess eine Reihe von Aktivitäten dar, die aus einem definierten Input ein definiertes Ergebnis (Output) erzeugen. [MOTZ17] präzisiert diese einfache Definition. Er bezeichnet einen Prozess als „Abfolge von zusammengehörigen und/oder zusammenbetrachteten, in Beziehung und/oder Wechselwirkung stehenden Prozessschritten, die einen zeitlichen Beginn und ein Ende haben und durch die Eingaben in Ergebnisse umgewandelt werden.“ Projektmanagementprozesse finden sich in der DIN 69901, die einen Mindeststandard für Projektmanagement definiert. [DIN16a]
Aufgabe	Im Projektkontext sind Aufgaben „aus Ziele abgeleitete Aufforderungen an einzelne Personen, Personengruppen oder Organisationen, eine bestimmte Arbeit … unter gegebenen Bedingungen und Nutzung bestimmter Mittel zu erledigen und dabei die vorgegebenen Ziele zu erreichen.“ [MOTZ17]

Tabelle 2 - Begriffsklärung

Projektportfolio

4.3.2 Governance, Strukturen und Prozesse / Bloom’sche Taxonomie 1 – Wissen

Werden in einer Organisation mehrere Projekte gleichzeitig oder überlappend durchgeführt spricht man von einem Projektportfolio. Ein Projektportfolio bündelt Projekte in einem abgegrenzten Verantwortungsbereich zum Zweck der übergeordneten Planung und Steuerung. Es orientiert sich an der übergeordneten Zielsetzung (z.B. aus der Strategie) des Unternehmens, wählt unter Berücksichtigung knapper Ressourcen Projekte aus und initiiert diese zu deren Umsetzung. [DIN16d, PATZ17]

Projektportfoliomanagement  ist im Gegensatz zum Projekt- und Programmmanagement eine permanente Aufgabe. Wie das PM umfasst auch das Projektportfoliomanagement die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln hier aber für die übergreifende Planung und Steuerung von Projektportfolios einer Organisation. [DIN16d, MOTZ17]

Projektmanagement-Office

4.3.2 Governance, Strukturen und Prozesse / Bloom’sche Taxonomie 1 – Wissen

Ein Projektmanagement-Office (PMO)  ist eine projektübergreifende meist permanente Unterstützungsfunktion, die zum einen den Projekten den methodischen Rahmen und PM-Standards vorgibt, zum anderen die Einführung und Optimierung des Projektmanagementsystems des Unternehmens begleitet. Ein weiterer Aufgabenschwerpunkt ist die operative Unterstützung der Projektleiter und weiteren Projektbeteiligten.

Folgende Tabelle zeigt beispielhaft die Aufgaben, Kompetenzen und Verantwortung (AKV – siehe auch Kapitel 3.5.2) des PMO (in Anlehnung an [PFET17] und [PATZ17])

Aufgabe	Projektanträge klassifizieren und prüfen Sitzungen des Lenkungsausschusses vorbereiten Pflegen des Projektportfolios Beraten und Schulen der Projektbeteiligten in der Handhabung des PM-Handbuchs/ Vorgehensmodells Pflegen und Weiterentwickeln des PM-Handbuchs/ Vorgehensmodells Organisieren des Erfahrungsaustauschs von Projektleitern
Kompetenz (Befugnisse)	Einhalten der vorgegebenen Richtlinien für Projektmanagement (PM-Handbuchs/ Vorgehensmodells) einfordern Einfordern der Projektstatusberichte
Verantwortung	… für das Informieren des Antragstellers über den Stand seines Projektantrags … für die Transparenz über kritische Entwicklungen im Projektportfolio oder bei Ressourcenüberlastung

Tabelle 3 - AKV eines Projektmanagement-Office (Beispiel)

Projektarten

4.3.2 Governance, Strukturen und Prozesse / Bloom’sche Taxonomie 1 – Wissen

4.5.1 Projektdesign / Bloom’sche Taxonomie 1 - Wissen

Projekte werden in der Praxis in verschiedene Dimensionen eingruppiert. Häufig werden Projektarten nach dem Objekt (Projektinhalt) klassifiziert [GPM17b]

• Investitionsprojekt
• Forschungs- und Entwicklungsprojekt
• Organisationsprojekt

Projektart	Beschreibung
Investitionsprojekt	erfordern hohen Planungsgrad sowie eine plangemäße Steuerung Beispiele: Bau von Straßen, Messehallen oder die Beschaffung von Flugzeugen, Schiffen oder Großmaschinen
Forschungs- und Entwicklungsprojekt	Beziehung von Input und Output ist oft unsicher, Lösungen sind in der Regel reproduzierbar Beispiele: Entwicklung von Medikamenten, Konzepten und Produkten
Organisationsprojekt	Erfordern eine variable Planung, da sich durch das Projekt die Grundlagen des Projekts verändern. Dieser Zirkelbezug von Ursache und Wirkung macht eine fortlaufende Anpassung der Vorgehensweise notwendig Beispiele: Entwicklung bzw. Verbesserung der Leistungsfähigkeit oder Wirksamkeit einer Organisation und / oder die organisatorische Umsetzung spezifischer Vorhaben (Messen, Kongress)

Tabelle 4 - Projektarten nach dem Objekt

Es gibt zahlreiche weitere Möglichkeiten der Projektklassifizierung, beispielsweise nach der Projektorganisation (siehe Kapitel 3.5.1, Seite 66) und der Projektsteuerung (technokratisches bzw. agiles Projekt).

Projektmanagementerfolg

4.5.1 Projekt Design / Bloom’sche Taxonomie 2 – Verstehen

Der Projekterfolg ist laut DIN 69901-5 das „zusammenfassende Ergebnis der Beurteilung des Projektes hinsichtlich der Zielerreichung.“ Dahinter steht zum einen die Einhaltung der vertraglich definierten Parameter – Kosten, Termin, Leistung als ein direkt messbares Ergebnis. Zum anderen die Anerkennung und positive Beurteilung der Projektergebnisse durch Auftraggeber und Kunden, aber auch durch die Projektmitarbeiter und den Projektleiter. [DIN16a]

Die ursprünglichen Dimensionen des Projekterfolges sind zusammengefasst

• Einhalten der geplanten Kosten und Termine
• die erwartete Leistung bzw. Qualität der (technischen) Lösung
• die Zufriedenheit der Beteiligten

Ergänzend dazu finden sich in der Literatur noch weitere Faktoren, die ein Projekt erfolgreich machen. [KERZ17]

• minimale Änderung des Projektziels, d.h. Veränderung der Rahmenbedingungen wurden so gering wie möglich gehalten und unbedingt zwischen Projektleiter und Auftraggeber abgestimmt
• das Unternehmen arbeitete störungsfrei weiter, d.h. das Projekt wurde innerhalb der Richtlinien, Abläufe, Regeln und Vorgaben der Organisation abgewickelt
• die Unternehmenskultur wurde nicht verändert, d.h. auch wenn per Definition jedes Projekt einmalig ist, sollte der Projektleiter nicht von den Mitgliedern seines Projektteams erwarten, dass sie von den Unternehmensnormen abweichen.

Abhängig vom Zeitpunkt der Betrachtung lässt sich der Projekterfolg noch in Anwendungserfolg (beschreibt die Auswirkung bzw. den Erfolg auf dem Markt, also die Nutzenziele des Auftraggebers) und Abwicklungserfolg (beschreibt die Durchführung des Projektes) unterscheiden. [MOTZ17]

Der Projektmanagementerfolg ist mit dem Projekterfolg eng verknüpft, aber nicht als identisch zu betrachten. Professionelles Projektmanagement erhöht in vielen Fällen nachweisbar den Projekterfolg. Ein ausschlaggebender Faktor für den Projektmanagementerfolg ist die effektive und effiziente Verbindung von Projektanforderungen, Aktivitäten und Ergebnissen, um so die Zielsetzungen zu verwirklichen und einen erfolgreichen Projektabschluss zu erreichen. Als Projektmanagementerfolg wird auch eine positive Beurteilung durch die wichtigsten Stakeholder hinsichtlich ihrer Zufriedenheit mit der Abwicklung des Projekts gewertet. [PATZ17]

Abbildung 2 – Beispiele für Projektmanagement-Erfolgsfaktoren

Projektmanagementerfolg beginnt bereits mit der Auswahl des passenden Vorgehensmodells für die Abwicklung des Projekts.

Projektmanagementansätze und Vorgehensmodelle

4.5.1 Projekt Design / Bloom’sche Taxonomie 2 – Verstehen

Sequenzieller PM-Ansatz

Eine sequenzielle Vorgehensweise strukturiert Projekte in Phasen, die nacheinander abgearbeitet werden. Streng ausgelegt muss eine Phase erfolgreich abgeschlossen werden, bevor die nächste Phase beginnen kann. [TIMI17, GPM17b]

Typische Vertreter sind das Wasserfallmodell und das V-Model XT. Letzteres ist ein deutscher Standard für die Planung und Durchführung von Systementwicklungsprojekten. Es wird in Unternehmen, Behörden und im militärischen Bereich genutzt.

Iterativ/Inkrementeller PM-Ansatz

Der iterative PM-Ansatz zählt wie der inkrementelle PM-Ansatz zu den sog. „Wiederholenden Vorgehensmodellen“.

Die einzelnen Schritte werden von der Anforderung bis zum ersten Teilergebnis sequenziell durchlaufen, d.h. für jedes Inkrement werden die Anforderungen für das Zwischenziel formuliert, dann entwickelt, implementiert und getestet. Dies wird solange wiederholt, bis am Ende das fertige Gesamtergebnis vorliegt. [TIMI17, GPM17b] Dieses Vorgehen eignet sich bei

• Projektarbeit mit hohen Unsicherheiten
• fehlender Erfahrung für die Bearbeitung
• volatilen[1] Anforderungen

Typische Vertreter dieses Ansatzes sind das Spiralmodell und Rational Unified Process (RUP).

 

Agiler PM-Ansatz

Die iterativinkrementelle Vorgehensweise des agilen Ansatzes liefert dem Kunden möglichst schnell ein funktionsfähiges System, das in kurzen Iterationsschleifen verbessert und mit zusätzlichen Funktionen erweitert wird. [GPM17b]

Weitere Merkmale dieses PM-Ansatzes sind

• Timeboxing: Die einzelnen Iterationen werden in festen Zeitabschnitten durchlaufen, das heißt alle Beteiligten können sich auf die festgelegten Termine verlassen. Im Falle von Problemen erfolgt keine Terminverschiebung, sondern eine Anpassung des Umfangs der zu erstellenden Version (siehe dazu auch Kap. 8.1.1 Timeboxing).
• Selbstorganisierte Teams: Die Mitglieder im Team sind grundsätzlich gleichberechtigt. Das Team hat die Autonomie, sich selbst so zu organisieren, dass es die Arbeitsanforderungen bestmöglich erfüllen kann.
• Änderungsfreundliche Projektkultur: Im Gegensatz zum klassischen Wasserfallmodell werden Anforderungen und Technologien nicht im „Design Freeze“ unter Änderungskontrolle gestellt. Änderungen werden als Freund, nicht als Gegner des Projekts gesehen und sind damit Bestandteil des Produktentwicklungszyklus.

Für die Gestaltung des agilen PM Ansatzes sind verschiedene Rahmenbedingungen wie das Agile Manifest mit seinen vier Wertepaaren und 12, diese Wertepaare präzisierenden Prinzipien zu berücksichtigen. Da in der agilen Welt immer wieder auf diese Wertepaare Bezug genommen wird, werden sie hier kurz dargestellt

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Der Fokus liegt in der Agilen Welt auf der linken Seite der Aussage, der rechte Teil wird trotzdem nicht vernachlässigt.[2]

Typische Vertreter dieses Ansatzes sind z.B. Scrum, Crystal, eXtreme Programming (XP), Feature Driven Development (FDD) und Kanban.

Hybrider PM-Ansatz

Unter dem hybriden Projektmanagementansatz wird die Nutzung von Methoden, Rollen, Prozessen und Phasen unterschiedlicher Standards oder Vorgehensmodelle verstanden. Meistens wird das klassische Projektmanagement als Basis verwendet und in verschiedenen Vorgehensweisen mit agilen Elementen bestückt. [TIMI17, MOTZ17]

In einer Studie mit über 1000 Teilnehmern der Hochschule Konstanz gaben 37% der Befragten an, anhand einer „Mischform“ Projekte/ Entwicklungsprozesse zu bearbeiten. Sie nutzen durch die Kombination die Stärken der verschiedenen Vorgehensweisen. Die Studie zeigt ebenfalls, dass die im hybriden Umfeld am häufigsten eingesetzten Werkzeuge aus dem agilen Methodenkasten kommen. [KOMU17]

Ähnlich der Fabel vom Affen und Elefanten gibt es demnach immer häufiger ein „sowohl als auch“ statt ein „entweder oder“. [BOEH04]

Ein Elefant versorgt mit Stärke, Disziplin und Verlässlichkeit ein Dorf mit Nahrungsmitteln. Nachdem die Köche im Dorf zunehmend exotischere Zutaten fordern, von denen der Elefant zwar gehört hatte, die aber nicht entlang seines Weges zu finden waren, verliert der Elefant an Popularität und Ansehen (Klassische Methoden).

Zur gleichen Zeit gab es in einem in der Nähe gelegen Dorf einen Affen, der dieselbe Aufgabe wie der Elefant hatte. Im Gegensatz zu ihm suchte der agile Affe die Lebensmittel kreuz und quer im Dschungel. Er war durch seine Suche nicht immer pünktlich in seiner Auslieferung, brachte aber jeweils exotische Nahrungsmittel und Zutaten mit. Sein Problem begann mit der stetig wachsenden Bevölkerung in seinem Dorf und seiner begrenzten Transportkapazität. Die Dorfbewohner wurden ungeduldig und der Affe zweifelte an seinen Fähigkeiten, seinem Auftrag gerecht zu werden (Agile Methoden).

Glücklicherweise treffen sich eines Tages der entmutigte Elefant und der resignierende Affe. Beide stolz auf ihre jeweiligen Fähigkeiten aber auch beeindruckt von den Kompetenzen des anderen. Schnell stellten sie den Nutzen einer Zusammenarbeit fest und entschieden, ihre Kräfte zu bündeln. Der Affe kümmerte sich fortan um die exotischen Wünsche der beiden Dörfer, der Elefant übernahm die Lieferung ausreichender Mengen an Grundnahrungsmitteln (Kombination klassische und agile Methoden).

Typischer Vertreter dieses Ansatzes sind Reliable Scrum (Scrum und Critical Chain), das Wasser-Scrum-Fall-Modell, das V-Scrum-Modell (Agile V) und Scrumban (Scrum und Kanban).

Evolutionärer PM Ansatz

Evolutionäres Projektmanagement baut auf vorhandenem auf, reagiert umgehend auf Veränderungen, bezieht Erfahrung direkt ein, nutzt Freiräume und probiert – ausgehend vom erreichten Stand – weitere Neuerungen im Sinne von „Trail and Error“. Das evolutionäre PM zeichnet sich durch eine schrittweise Zielentwicklung und Verfeinerung aus. [LITK05]

Typischer Vertreter dieses Ansatzes ist das Prototyping.

Engpassorientierter PM-Ansatz

Der engpassorientierte PM-Ansatz bzw. das Critical Chain Projektmanagement beruht auf einem von Eliyahu Goldratt begründeten  systemorientierten Management-Ansatz zur Identifizierung und Beseitigung von Engpässen. Das Ziel ist die Verkürzung der Projektlaufzeit und eine Erhöhung der Termintreue. [TECH10]

Beim Critical Chain PM wird ein Projekt als Netzwerk verschiedener Prozesse gesehen. Die Performance des Netzwerks wird durch einen Engpass-Prozess begrenzt. Zur Steigerung der Effizienz schlägt Goldratt einen Thinking Process mit fünf Schritten vor [BEA11b, ANDE12]

• 1.     Identifizieren des Engpasses
• 2.     (optimales) Auslasten des Engpasses
• 3.     Ausrichten aller Prozesse am Engpass
• 4.     Beheben des Engpasses
• 5.     Kontrolle und weiter bei Schritt 1 (In Anlehnung an ein Bonmot von Sepp Herberger: „Nach dem Engpass ist vor dem Engpass“)

Typischer Vertreter dieses Ansatzes ist die Theory of Constraints (ToC).

 

Standards im Projektmanagement

4.3.3 Compliance, Standards und Regularien / Bloom’sche Taxonomie 2 – Verstehen

Im vierten ICB-Element im Kapitel Grundlagen - Compliance, Standards und Regularien - beschäftigen wir uns mit den derzeit gültigen nationalen und internationalen Standards für Projektmanagement. Dazu gehören

• die in Deutschland bekannte Normenreihe DIN 69900, 69901 und 69909
• das internationale Gegenstück ISO 21500
• der PMBoK Guide des Project Management Institute
• PRINCE 2
• PM²
• die Grundlage für dieses Buch, die Individual Competence Baseline 4.0

 

Compliance, Standards und Regularien (4.3.3) „Die Kompetenz Compliance[3], Standards und Regularien definiert, wie der Einzelne die externen und internen Einschränkungen in einem bestimmten Bereich … interpretiert und sie aufeinander abstimmt.“ [GPM17a, Seite 53]

Normenreihe DIN 69900, 69901 und 69909

In Deutschland existieren eine ganze Reihe von Projektmanagement Normen. Eine der ältesten ist die DIN 69900 „Projektmanagement – Netzplantechnik; Beschreibungen und Begriffe“ aus dem Jahre 1987. Der Anwendungsbereich dieser Norm beschränkt sich auf die Netzplantechnik und weitere Methoden zur Ablauf- und Terminplanung und legt die zugehörige Terminologie fest. [DIN16e]

Neuer und aktueller ist die DIN 69901 „Projektmanagement – Projektmanagementsysteme“ mit ihren fünf Teilen aus dem Jahr 2009

• Grundlagen
• Prozesse, Prozessmodell
• Methoden
• Daten, Datenmodell
• Begriffe

Die DIN 69901-2 (Projektmanagement - Projektmanagementsysteme - Teil 2: Prozesse, Prozessmodell) beschreibt fünf Prozessgruppen, die fünf Projektmanagementphasen „Initialisierung, Definition, Planung, Steuerung und Abschluss“, 11 Prozessuntergruppen (z.B. Ablauf und Termine, Änderungen, Organisation, Qualität) und 59 Prozesse. Sie bietet mit ihren Prozessbeschreibungen eine gute Grundlage für das Managen von Projekten. Allerdings müssen diese Prozesse, wie bei den meisten Modellen, projektspezifisch angepasst werden. Dies erfolgt häufig unternehmensweit im Rahmen einer Projektmanagement-Standardisierung (z.B. durch Ausarbeiten und in Kraft setzen eines Projektmanagement-Handbuchs, siehe Kapitel 1.5.7) oder es wird durch den Projektleiter gemäß der individuellen Anforderung seines Projekts vorgenommen.

In der DIN 69901-5 werden Projektmanagement-Grundbegriffe definiert und die Nomenklatur zu vielen Fachbegriffen im Projektmanagement geregelt. Dieser Teil stellt sozusagen das Glossar der Norm dar. [DIN16a]

Die neueste Ergänzung in dieser Reihe ist die DIN 69909 „Multiprojektmanagement – Management von Projektportfolios, Programmen und Projekten“ mit derzeit vier Teilen (Grundlagen, Prozesse, Methoden und Rollen) aus dem Jahr 2013. [DIN16d]

ISO 21500

Die internationale Projektmanagement-Norm ISO 21500 „Leitlinien Projektmanagement“ wurde  2016 als DIN ISO 21500:2016-02 unverändert als Deutsche Norm übernommen. Sie beschreibt ebenfalls fünf Prozessgruppen (Initiierung, Planung, Umsetzung, Controlling, Abschluss). Im Vergleich zur DIN 69901 kommt sie mit zehn Prozessuntergruppen (z.B. Integration, Stakeholder, Leistungsumfang) und 38 Prozessen aus. Die ISO 21500 gibt einen allgemeingültigen Überblick über die wesentlichen Inhalte des Projektmanagements und ermöglicht so eine leichte Adaptierbarkeit auf die jeweiligen unternehmensspezifischen Rahmenbedingungen. [DIN16b]

PMBOK^® Guide

A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) des Project Management Institute (PMI) liegt seit 2017 in der sechsten Ausgabe vor und enthält die offizielle Norm des American National Standards Institute (ANSI) für Projektmanagement (ANSI/PMI 99-001-2017).

Der Guide  enthält ebenfalls eine prozessorientierte Beschreibung der Funktionen des Projektmanagements. Die fünf Prozessgruppen (Initiierung, Planung, Ausführung, Steuerung, Abschluss) beziehen sich ebenfalls auf die Phasen des Projektlebenszyklus. Sie werden um 10 Wissensgebiete (z.B. Integrationsmanagement, Stakeholdermanagement, Risikomanagement) und 49 Prozesse ergänzt. [PMI17a]

PRINCE2^®

PRINCE2^® – Projects In Controlled Environments stellt ein branchenübergreifendes Projektmanagementsystem aus jeweils sieben Grundprinzipien (z.B. Lernen aus Erfahrung, Definierte Rollen und Verantwortlichkeiten), Wissensbereiche (z.B. Business Case, Organisation, Qualität) und Prozessen dar. Die sieben Prozesse lassen sich auf drei Management-Ebenen aufteilen

• Lenken – Vorbereitung, Lenkung
• Managen – Initiierung, Steuerung, Managen eines Phasenübergangs, Abschluss
• Liefern – Managen der Produktlieferung

Herausgegeben und weiterentwickelt wird PRINCE2^® von AXELOS, einem britischen Unternehmen, das u.a. auch für das weitverbreitete IT Service Management ITIL^® (IT Infrastucture Library) verantwortlich zeichnet. [AXEL17]

PM²

Der PM² Project Management Methodology Guide ist eine vom Centre of Excellence in Project Management (CoEPM²) der Europäischen Kommission entwickelte und unterstützte Projektmanagementmethode. Im Fokus steht die Zusammenführung der unterschiedlichen Projektmanagementansätze innerhalb der EU-Verwaltung durch Festlegung einer einheitlichen Terminologie und gemeinsamer Verfahren. Das Phasenmodell besteht aus fünf Phasen – Initiierung, Planung, Durchführung und Abschluss. Die fünfte Phase – Überwachung und Kontrolle – ist übergreifende von Beginn (Initiierung) bis Ende des Projekts (Abschluss). Das Modell basiert auf bewährten Standards im Projektmanagement, ICB 4.0, PMBOK^® Guide, PRINCE2^® und PRINCE2^® Agile. [CEPM18]

ICB 4.0

Die Individual Competence Baseline Version 4.0 der International Project Management Association (IPMA) enthält keine Prozessbeschreibungen sondern stellt einen umfassenden Katalog individueller Kompetenzen dar. Die ICB 4.0 ist in drei Domänen aufgeteilt – Projekt-, Programm- und Portfoliomanagement. Die in diesen drei Standardwerken enthaltenen Kompetenzelemente werden in drei Bereiche eingeteilt:

Kontext-Kompetenz (Perspective) Methoden, Werkzeuge und Techniken, mit denen ein Einzelner mit seiner Umgebung interagieren kann Persönliche und Soziale Kompetenz (People) Attribute, die ein Einzelner benötigt, um erfolgreich Projekte zu leiten bzw. in ihnen mitzuarbeiten Technische Kompetenz (Practice) spezifische Methoden, Werkzeuge und Techniken, die in Projekten eingesetzt werden

Abbildung 3 – Eye of Competence (IPMA)

Dieses „Eye of Competence“ bildet ein (Kompetenz-)Spektrum ab, über das Personen verfügen, die in Projekten, Programmen oder Portfolios arbeiten oder diese leiten. Die ICB 4.0 macht dabei in Bezug auf Branchen oder Wirtschaftszweige keinen Unterschied. [GPM17a]

Der Schwerpunkt dieses Buches liegt in der Domäne Projektmanagement.

Projektmanagement-Handbuch

Unternehmen, Konzerne und andere Organisationen verwenden häufig interne Richtlinien in Form von Projektmanagement-Handbüchern oder PM-Leitfäden, um eine organisationsweit einheitliche Vorgehensweise im Projektmanagement sicherzustellen. Das PM-Handbuch kann Teil des Organisationshandbuchs oder ggfls. des Qualitätsmanagementhandbuchs des Unternehmens sein. Im einfachsten Fall stellt das PM-Handbuch eine Zusammenstellung von z.B. Checklisten und Formularen für das Projektmanagement dar. Meistens beinhaltet es ein unternehmensspezifisches Vorgehensmodell zur Planung, Überwachung und Steuerung der Projekte. [MOTZ17]

 

	Projektmanagement-Handbuch vs. Projekthandbuch
	Das Projektmanagement-Handbuch ist eine interne Unternehmensrichtlinie bzw. ein Projektmanagement-Leitfaden und enthält meist neben einem unternehmensspezifischen Vorgehensmodell eine Zusammenstellung von z.B. Checklisten und Formularen für das Projektmanagement [MOTZ17]	Das Projekthandbuch ist eine projektspezifische Zusammenstellung von Informationen, Regelungen, Standards und Arbeitsmitteln für die Planung und Durchführung sowie dessen Überwachung und Steuerung. Es wird üblicherweise zum Projektstart erstellt und kontinuierlich fortgeschrieben. [MOTZ17] Inhalt: Projektdefinition und Leistungsplanung, Projektorganisation, Projektinformationswesen und Kommunikation, Projektplanung, Projektüberwachung und –steuerung, Projektabschluss

 

Initialisierungsphase

Abbildung 4 - ICB-Elemente in der Initialisierungsphase

 

Die Initialisierung eines Projektes erfolgt entweder aus dem internen Umfeld eines Unternehmens (z.B. Reaktion der Geschäftsleitung auf ein festgestelltes Problem, Anforderung eines Fachbereichs) oder aus dem externen Umfeld (z.B. eine gewonnene Ausschreibung, Kundenanforderung/ -auftrag, geänderte Marktbedingungen). [GPM17b]

Auswahl von Projekten

Strategie (4.3.1) „Die Kompetenz Strategie definiert, wie Strategien verstanden und mithilfe von Projekten in handhabbare Elemente aufgeteilt werden. Diese Kompetenz definiert dafür ein leistungsstarkes Managementsystem, in dem Projekte bzgl. ihrer Ausrichtung an der Strategie und der Vision betrachtet und gesteuert werden, um sicherzustellen, dass sie möglichst stark mit der Mission und der Nachhaltigkeit der Organisation korrelieren“ [GPM17a, Seite 42]

 

Vision, Mission, Strategie

4.3.1 Strategie / Bloom’sche Taxonomie 1 – Wissen

Projekte werden üblicherweise nicht um ihrer selbst willen durchgeführt, sondern um den Geschäftszweck des Unternehmens zu unterstützen. Aus diesem Grund leiten sich die Projektziele aus der Vision, der Mission und der Strategie des Unternehmens ab.

Abbildung 5 - Zielpyramide des Unternehmens

Vision

An der Spitze der Zielhierarchie steht eine allgemeine und grundsätzlich gehaltene Vorstellung von der künftigen Rolle des Unternehmens. Diese wird i.d.R. mit anspruchsvollen Begriffen belegt und beschreibt einen idealen Zustand in der Zukunft. [BEA17]

Sie ist eine wichtige Komponente der Unternehmensführung, weil sie in einer knappen und anschaulichen Formulierung allen Mitarbeitern deutlich macht, worum es geht. Die Vision des Unternehmens kann auch einzelne Elemente auf dem Weg zu diesem Idealzustand umfassen und benennen. Aus der Unternehmensvision lassen sich die wichtigsten Unternehmensziele und Unternehmensstrategien ableiten. Die Vision markiert eine weit in die Zukunft gerichtete Orientierung, ist also richtungsweisend. [FLEI16]

Eine gute Vision drückt aus

• Warum tun wir das, was wir tun?
• Wo wollen wir in fünf bis zehn Jahren stehen?
• Was wäre uns auch in einer wirtschaftlichen Krisensituation wichtig?
• Welche Werte würden wir auch dann verfolgen, wenn das Unternehmen turbulenten Zeiten ausgesetzt ist?
• Was würden wir auch dann hochhalten, wenn es ein (scheinbarer) Nachteil im Wettbewerb ist?

Die Vision verkörpert die Unternehmensphilosophie.

Mission

Die Mission eines Unternehmens beschreibt den wesentlichen Zweck oder den Auftrag, den das Unternehmen verfolgt. Sie sagt, warum das Unternehmen oder eine Organisationseinheit existiert und was das Unternehmen für seine Stakeholder, für Kunden, Eigentümer, Mitarbeiter oder Partner sein will. [FLEI16, BEA17]

Die Mission entspricht der Unternehmenspolitik als Ausdruck des eigenen Auftrags zur Realisierung der Vision.

Strategie

Eine Strategie ist ein längerfristig ausgerichtetes, planvolles Anstreben eines konkreten (Unternehmens-)Ziels. Die Unternehmensstrategie zeigt auf, wie ein

• mittelfristiges (ca. 2 bis 4 Jahre) oder
• langfristiges (ca. 4 bis 8 Jahre)

Unternehmensziel erreicht werden soll. Strategische Ziele stellen eine Konkretisierung der Vision / Mission dar. Sie haben grundlegenden Charakter und geben die Rahmenbedingungen für das Handeln der Organisation vor. An ihnen lässt sich der Erfolg des Unternehmens messen. [SZTU18a, BEA17]

 

Beispiel - Deutsche Post DHL Group[4]   Unsere Vision                 Wir sind DAS Logistikunternehmen für die Welt. Unsere Mission              Menschen verbinden, Leben verbessern. Excellence. Simply Delivered. Unsere Strategie 2025   Spitzenleistungen in einer digitalen Welt.

 

Beurteilung der Projektidee

Üblicherweise stehen Unternehmen nur beschränkt Ressourcen zur Verfügung, d.h. Geld- und Sachmittel, Personal sowie Material müssen so eingesetzt werden, dass sie die Unternehmensziele effizient und effektiv unterstützen. Da Projekte zur Durchführung Ressourcen brauchen bzw. verbrauchen, ist es nur konsequent, wenn nur solche Projekte durchgeführt werden, die möglichst gut zur Erreichung eben dieser Unternehmensziele beitragen. [BEA11a]

Neben dem eigenen strategischen Planungsprozess als Quelle für Projektideen werden immer häufiger Projekte durch Veränderungen im Umfeld des Unternehmens (z.B. neue Technologien, Gesetzesänderungen, Markteintritt eines neuen Wettbewerbers) initiiert. [PATZ17]

Die Auswahl der richtigen Projekte im Unternehmen ist Aufgabe des strategischen Projektmanagements. Dabei ist zu prüfen, ob das Projekt grundsätzlich durchführbar ist. Diese „Vorauswahl“ soll verhindern, dass unpassende Projekte überhaupt in Angriff genommen werden.

 

 

Auswahlkriterien, für die passenden Projekte können beispielsweise sein

• Kundennutzen
• Kostensenkungspotenzial
• strategische Bedeutung
• verbesserte Reaktionsfähigkeit
• Risiko
• Dringlichkeit (Muss-Projekt - betrifft zwingende Themen, wie z.B. gesetzliche Änderungen)

Allerdings gewinnt die Beurteilung der Wirtschaftlichkeit in immer höherem Maße an Bedeutung. Aus ökonomischer Sicht können Projekte u.a. nach der

• Amortisationsdauer (Zeitdauer, die benötigt wird, um die Investition wieder zurückzugewinnen)
• Kapitalwertmethode (auch Net Present Value; Projekt ist dann wirtschaftlich, wenn die Summe aller Ein- und Auszahlungen positiv ist)
• Risikobewertung (Variantenrechnung, Sensitivitätsanalyse)

bewertet und selektiert werden. [KERZ17, PATZ17]

Bei externen Kundenaufträgen ist das Messkriterium das Ergebnis nach Kosten, also der mit dem Projekt zu erwirtschaftende Deckungsbeitrag.

Erfolgsfaktoren

4.3.1 Strategie / Bloom’sche Taxonomie 1 – Wissen

4.5.1 Projektdesign / Bloom’sche Taxonomie 2 - Verstehen

Erfolg beruht nicht nur auf Handlungen und der Verknüpfung unterschiedlicher Vorgehensweisen, sondern auch auf externen „Umständen“. Diese externen Umstände manifestieren sich in den Erfolgsfaktoren für das Projekt. Erfolgsfaktoren sind Schlüsselgrößen, die für das Erreichen der Gesamtziele eines Projektes von zentraler Bedeutung sind. Stimmt die Summe dieser Faktoren, so wird das Projekt als Ganzes erfolgreich sein, zeigen sich dagegen hier Defizite, so beeinträchtigt dies unmittelbar den Gesamterfolg. Projektmanagement-Erfolgsfaktoren sind somit Vorgehensweisen und Situationen, die den Erfolg eines Projektes steigern können. [GABL18, MOTZ17]

Erfolgsfaktoren sind gem. der jährlichen Erhebung der Standish Group International Inc. (CHAOS-Report) beispielsweise: Aufmerksamkeit des Managements, realistische Erwartungen, kompetente Teammitglieder, klare Vision und Ziele, Verfügbarkeit des Kunden, Stakeholdermanagement.

 

	Erfolgsfaktoren vs. Erfolgskriterien
	Erfolgsfaktoren sind Schlüsselgrößen bzw. Rahmenbedingungen, die für das Erreichen der Gesamtziele eines Projektes von zentraler Bedeutung sind. [GABL18]	Erfolgskriterien sind Merkmale, Eigenschaften und Bewertungsmaßstäbe, an denen der Erfolg eines Projekts gemessen und beurteilt werden kann. Die Projekterfolgskriterien müssen für jedes Projekt spezifisch identifiziert, analysiert und bewertet werden. Sie sollen klar verständlich und messbar sein. Dabei sind insbesondere Ziele und Nutzen des Auftraggebers, der verschiedenen Projektbeteiligten und der Nutzer der Projektergebnisse zu betrachten. [MOTZ17]

 

Nutzwertanalyse

4.3.1 Strategie / Bloom’sche Taxonomie 3 – Anwenden (Level C)

Neben den „harten“ Kostenkriterien können auch die oben erwähnten qualitativen Auswahlkriterien wie strategische Bedeutung, Kundennutzen und Dringlichkeit berücksichtigt werden. Die Nutzwertanalyse erlaubt die Verbindung der „harten“ und „weichen“ Kriterien und somit eine Gesamtbeurteilung des Projektes. Dabei wird ein Punktwert für alle in Frage kommenden Projekte ermittelt. [NAGE95]

Vorgehen

• 1.     Kriterien bestimmen und gewichten (Summe der Gewichte = 10 bzw. 100%)
• 2.     Punkte für die Erfüllung der Kriterien durch die einzelnen Projekte vergeben (Werte von 1 - 10)
• 3.     Gewichte (G) mit den Punkten (P) multiplizieren
• 4.     Ergebnisse pro Kriterium und Projekt addieren
• 5.     Summe pro Projekt einer Attraktivitätsskala zuordnen und entsprechende Auswahl treffen

 

		Projekt A		Projekt B		Projekt C
Muss Projekt		nein		nein		ja
Kriterien	G	P	G * P	P	G * P	P	G * P
Wirtschaftlichkeit	3	7	21	10	30
Dringlichkeit	1	9	9	4	4
Kundennutzen	2	10	20	7	14
Risiko[5]	1	9	9	4	4
Strategie	3	5	15	9	27
Summe	10		74		79	umsetzen

Tabelle 5 - Nutzwertanalyse (Beispiel)

Neben Projekt C (Muss-Projekt) wäre nach der Nutzwertanalyse Projekt B für die Umsetzung erste Wahl. Diese Methode lässt sich auch im weiteren Verlauf der Projekte, beispielsweise bei der Priorisierung von Zielen oder der Bewertung von Lösungsalternativen, einsetzen. So kann das strategische Projektmanagement dafür sorgen, dass die richtigen Projekte ausgewählt werden (Effektivität), während das operative Projektmanagement diese dann richtig umsetzt (Effizienz).

Projektdefinition

Business Case

4.3.1 Strategie / Bloom’sche Taxonomie 1 – Wissen

Der Business Case oder Wirtschaftlichkeitsnachweis ist eine dokumentierte Machbarkeitsstudie, die den Grund für das Projekt und damit den Nutzen für die Organisation einschließlich des betriebswirtschaftlichen Nutzens darstellt. In der Regel ist der Auftraggeber für die Ausarbeitung dieses Dokuments verantwortlich. In diesem Dokument werden außerdem die Ziele für die Projektinitialisierung genannt, es kann somit zum Projektabschluss auch als Messkriterium dienen. [GPM17a, PMI17a]

Zu Erstellung eines Business Cases gibt es keine einheitliche Vorgabe. Die PM Methode PRINCE2 bietet hier einen Leitfaden mit folgenden Abschnitten: [RAD18]

Zusammenfassung (Executive Summary)	kurze Übersicht über den Business Case
Gründe (Reasons)	Motivation für die Durchführung des Projekts
Optionen (Business Options)	Möglichkeiten zur Durchführung des Projekts mit quantitativer und qualitativer Bewertung
Erwarteter Nutzen (Expected Benefits)	Auflistung des Nutzens mit Begründungen und Messungen
Erwartete negative Effekte (Expected Dis-benefits)	Ergebnisse, die von Stakeholdern negativ bewertet werden und/ oder negative Nebeneffekte
Zeitrahmen (Timescale)	Start und Ende des Projekts und wann sich das Projekt rechnet
Kosten (Costs)	Kosten des Projekts und Kosten, die nach Abschluss entstehen
Investitionsrechnung (Investment Appraisal)	Informationen über Return on Investment (ROI), Kapitalwertmethode (Net Present Value); Kosten-Nutzen-Analysen
Hauptrisiken (Major Risks)	Zusammenfassung der größten Risiken für das Projekt

Tabelle 6 – Leitfaden Business Case

Projektsteckbrief

4.5.2 Anforderungen und Ziele / Bloom’sche Taxonomie 3 – Anwenden)

Ein weiteres, Dokument, das zur Beschreibung des Leistungsumfangs des Projekts zur Anwendung kommt ist der Projektsteckbrief (siehe Abbildung 6). Er stellt die wesentlichen Eckdaten des Projektes kurz und präzise dar. Dazu gehören

• Projektname und Projektnummer
• eine Beschreibung des Inhalts
• die Projektziele
• Informationen zu Dauer, Beginn und Ende
• eine Aussage zum Budget
• Angaben zum Auftraggeber und/ oder Kunde
• beteiligte Personen (Projektleiter, Projektteam)
• eine Übersicht zu den geplanten Projektphasen

Der Projektsteckbrief ersetzt nicht die ausführliche Beschreibung von Leistungsumfang und Lieferobjekten, sondern gibt einen Überblick über das Projekt und seine Besonderheiten. Üblicherweise wird versucht, dieses Dokument, auf eine Din A4-Seite zu begrenzen. Je nach Sprachgebrauch und Festlegung im Unternehmen wird der Projektsteckbrief auch als Projektdefinitionsblatt, Projektbeschreibung, Projektantrag, Projektauftrag oder Project Charter bezeichnet. [PATZ17, MOTZ17]

 

Abbildung 6 – Projektsteckbrief (Beispiel)

Definitionsphase

Abbildung 8 – ICB-Elemente in der Definitionsphase

 

In der Definitionsphase besteht der erste Schritt darin, ein Kernteam für das Projekt zusammenzustellen, das in dieser Phase zunächst folgende Fragen klärt: [BERG16]

Warum?	Warum wird das Projekt gemacht (Zieldefinition)?
Wo?	Wo wird am Projekt gearbeitet? In welcher Umgebung (Umfeldanalyse)?
Wer?	Welche Personen und Unternehmen sind an der Durchführung und Finanzierung beteiligt und wer ist betroffen (Stakeholderanalyse und Projektorganisation)?
Was?	Was muss wann gemacht werden (Phasenplan und Meilensteine)?

Tabelle 7 – Fragen während der Definitionsphase

 

 

Anforderungen und Ziele

Anforderungen und Ziele (4.5.2) „Die Kompetenz Anforderungen und Ziele definiert das „Warum“ für das Projekt – welche Ziele müssen erreicht werden, welcher Nutzen muss realisiert werden und welche Anforderungen der Stakeholder müssen erfüllt werden.“ [GPM17a, Seite 111]

Anforderungen

4.5.1 Projektdesign / Bloom’sche Taxonomie 1 - Wissen

4.5.2 Anforderungen und Ziele / Bloom’sche Taxonomie 2 – Verstehen

„Willst du mir wohl sagen, wenn ich bitten darf, welchen Weg ich hier nehmen muss?“ fragt Alice „Das hängt zum guten Teil davon ab, wohin du gehen willst“ sagte die Katze. „Es kommt mir nicht darauf an, wohin –“ sagte Alice. „Dann kommt es auch nicht darauf an, welchen Weg du nimmst“, sagte die Katze. „– Wenn ich nur irgendwo hinkomme“, fügte Alice als Erklärung hinzu [CARR69].

Dieser Ausschnitt aus dem Gespräch von Alice mit der Grinse-Katze im Buch „Alice im Wunderland“ macht das Dilemma in so manchem Projekt deutlich. Wir wissen nicht genau wohin die Reise gehen soll, doch das erledigen wir dann höchst effizient und wundern uns wenn am Ende die Kosten überschritten werden und die Leistung durch unseren Auftraggeber nicht abgenommen wird. Die Gründe für diese Irritationen sind vielschichtig [EBER14, HRUS14]

• Unklare, interpretierbare Anforderungen
• falsche Anforderungen
• implizite Anforderungen
• fehlende Anforderungen
• Änderung von Anforderungen

Ohne klare und abgenommene Anforderungen lassen sich schwerlich die Leistungsziele des Projekts und ihre Messkriterien definieren. Anforderungsmanagement oder besser Requirements Engineering legt hierfür den Grundstein.

Gem. der ISO 10006 (Qualitätsmanagementsysteme – Leitfaden für QM in Projekten) ist „die Erfüllung der Anforderungen der Kunden und anderer interessierter Parteien für den Projekterfolg notwendig.“ [DIN16c] Was sind Anforderungen? Das IEEE (Institute of Electrical and Electronical Engineers) definiert eine Anforderung in der Norm ISO/IEEE 29148 als „statement which translates or expresses a need and its associated constraints and conditions.“ [IEEE11] Den Bedarf („need“) bekommen wir für unser Projekt im Idealfall mittels eines Lastenhefts. Das Lastenheft (User Requirements Specification) ist die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines (Projekt-)Auftrags.“ [DIN16a] Das heißt jedoch nicht in jedem Fall, dass in diesem Dokument tatsächlich alle Anforderungen abgebildet sind.

Für den Projektleiter und sein Projektteam gilt es, das Lastenheft gegen die sachlichen Umfeldfaktoren auf weitere, bisher nicht dokumentierte Anforderungen abzuprüfen. Ebenfalls ist das Lastenheft auf unklare bzw. interpretierbare Anforderungen „abzuklopfen“. Eine wichtige Quelle für Anforderungen sind ebenfalls die sozialen Umfeldfaktoren also die Stakeholder des Projekts. Diese repräsentieren sozusagen die „Stimme des Kunden“ (Voice of Customer, VoC). In der VoC spiegeln sich Bedürfnisse, Wünsche, Ansprüche und Erwartungen an die im Projekt zu erbringende Dienstleistung bzw. das zu erstellende Produkt [SCHM15].

Anforderungen sind somit das Bindeglied zwischen dem Auftraggeber („will etwas haben“) und dem Auftragnehmer („kann es liefern“). Dabei wird zwischen funktionalen und nichtfunktionalen Anforderungen unterschieden.

Abbildung 11 – Funktionale und nichtfunktionale Anforderungen

Die Anforderungen sind entsprechend aufzunehmen und zu beschreiben. Hierzu können folgende Regeln herangezogen werden [HRUS14]

• Kurze, einfache Sätze
• Eine Anforderung pro Satz
• Bedürfnisse, keine Lösungen beschreiben
• Abkürzungen nur wenn unbedingt notwendig
• Keine Generalität (manche, viele, alle, man, …)
• Verbindlichkeiten klar formulieren (was muss, was kann?)
• Aktiv formulieren (Wer macht was?)
• Erfüllung überprüfbar (Messbarkeit, Akzeptanzkriterien)
• Priorität festlegen

Eins sollte hierbei immer berücksichtigt werden – niemals bei Unklarheiten eine eigene Annahme im Sinne „Das wird mein Interviewpartner schon so gemeint haben“ treffen. Oder um es mit den Worten von Eric Bogosian im Film „Under Siege 2: Dark Territory“ (1995) zu sagen „Assumptions are the mother of all fuck ups!“[6]

Die präzisierten Requirements werden meistens in einem Pflichtenheft zusammengeführt. Das Pflichtenheft stellt das „vom Auftragnehmer erarbeitete Realisierungsvorhaben auf der Basis des vom Auftraggeber vorgegebenen Lastenhefts“ dar [DIN16a]. Es ergänzt das Lastenheft um erste Lösungsideen, Angaben zu den erwarteten Kosten und erste zeitliche Schätzungen. Das Pflichtenheft, häufig wird auch Fachkonzept oder Systembeschreibung synonym dafür verwendet, stellt somit die Sicht des Auftragnehmers dar und ist die Basis für die weiteren Schritte im Projekt. [VDI01]

 

 

Ziele

4.5.2 Anforderungen und Ziele / Bloom’sche Taxonomie 3 – anwenden

Projekte verfolgen mindestens ein Ziel und liefern für das Unternehmen relevante Ergebnisse. Sie stehen somit im Spannungsfeld von zu erreichenden Unternehmenszielen, den Erfolgsfaktoren des Unternehmens und der erforderlichen bzw. geforderten Qualität, die durch sie zu erbringen ist. Die Unternehmensziele leiten sich aus der Geschäftsstrategie des Unternehmens ab. Daraus wiederum werden die operativen Ziele definiert. Wie eingangs erwähnt liefern Projekte für das Unternehmen nutzbringende Ergebnisse, Projektziele resultieren daher aus den strategischen (strategische Projekte) oder den operativen Zielen des Unternehmens.

Zieldefinition, Zielgrößen

Ziele sind eines der Merkmale eines Projektes. Projektziel und Zieldefinition werden in der DIN 69901-5:2009 und der ICB 4.0 wie folgt beschrieben:

„Projektziel – Gesamtheit von Einzelzielen, die durch das Projekt erreicht werden“ [DIN16a, Seite 160]

„Zieldefinition – quantitative und qualitative Festlegung eines Projektinhaltes und der einzuhaltenden Realisierungsbedingungen, z.B. Kosten, Dauer, in den Zielmerkmalen mit meist unterschiedlichen Zielgewichten (z.B. Muss- und Kann-Ziele)“ [DIN16a, Seite 163]

„Die Kompetenz Anforderungen und Ziele definiert das „Warum“ für das Projekt – welche Ziele müssen erreicht werden, welcher Nutzen muss realisiert werden und welche Anforderungen der Stakeholder müssen erfüllt werden.“ [GPM17a, Seite 111]

Die Projektzielgrößen Kosten (Aufwand), Leistung (Ergebnis) und Termin (Zeit) stellen die verdichtete, übersichtliche Darstellung der Gesamtheit der Projektziele dar. Sie werden häufig in Form eines Dreiecks veranschaulicht, dem sogenannten „Magischen Dreieck“ des Projektmanagements.[7]

Abbildung 12 – „Magisches Dreieck“

 

 

 

Zielfunktionen, Zielarten

Projektziele haben neben der Kontrollfunktion (Stichwort: Messkriterium) weitere wichtige Funktionen.

 

Tabelle 8 – Zielfunktionen

Ein nicht ganz ernst zu nehmender Vorschlag des Autors: Nimmt man die Anfangsbuchstaben der Zielfunktionen ergibt sich das Akronym „KOKS Verbindet“ …

Ziele werden in Klassen zusammengefasst. Drei Klassen lassen sich bereits im „Magischen Dreieck“ erkennen – Termin-, Leistungs- und Kostenziele. Eine andere Möglichkeit sieht die Unterscheidung nach Ergebnis- und Vorgehenszielen (auch Prozesszielen) vor.

Unter den Ergebniszielen werden Projektziele zusammengefasst, die sich auf den Projektgegenstand (z.B. Finanzziele, Leistungsziele, Soziale Ziele, Ökologische Ziele) beziehen. Vorgehensziele hingegen beschreiben den Weg zur Erreichung des Projektergebnisses, d.h. alle Forderungen und Randbedingungen, die im Laufe des Projektes zu erfüllen sind (z.B. Terminziele, Budgetziele).

Eine Sonderstellung nehmen die Nutzenziele oder Nutzungsziele ein. Sie stellen die spätere Nutzung des Projektergebnisses dar, obwohl sie bei Abschluss des Projektes noch nicht vorliegen und der Projektleiter daher nicht unmittelbar für deren Erreichung verantwortlich ist. Allerdings dürfen sie während des Projekts nicht aus den Augen verloren werden weil sie Ansatzpunkte für Chancen im Projekt sein können. [MOTZ17]

Trotz umfassender Zielformulierung kommt es vor, dass der Auftraggeber während der Projektumsetzung eine Leistung einfordert, die vom Projektteam nicht als Teil des Projektes gesehen wird. Um diesem Umstand vorzubeugen ist eine klare Abgrenzung durch die Formulierung von Nicht-Zielen  hilfreich (out-of-scope). Nicht-Ziele drücken aus auf welche Aspekte im Rahmen des Projektes verzichtet wird. Die Formulierung der Nicht-Ziele ist zudem eine wichtige Komponente in der Auftragsklärung zwischen Projektleitung und Auftraggeber [PATZ17].

Nach Festlegung der Ergebnis-, Vorgehens- und Nicht-Ziele müssen diese noch kategorisiert werden. Die Einteilung erfolgt üblicherweise in Muss- (Nicht erreichen bedeutet Scheitern des Projektes), Soll- (Nicht erreichen verhindert die Gesamtzufriedenheit der Stakeholder mit dem Projekt) und Kann-Ziele (eher sekundär, nur bei angemessenem Aufwand anzustreben) Kategorien. Nicht-Ziele werden nicht kategorisiert. Innerhalb der Kategorien kann, abhängig von den jeweiligen Zielbeziehungen, noch zusätzlich eine Priorisierung vorgenommen werden.

 

 

Klasse	Beschreibung	Messkriterium	Kategorie
Hauptziel	Durchführen einer erlebnisorientierten integrativen Kinderfreizeit für 100 Kinder am letzten Juliwochenende 2021 mit einem Budget von Euro 7.500.-
Leistung	Übernachtung und Verpflegung ist sichergestellt (L1)	Alle TN haben einen Schlafplatz und bekommen drei Mahlzeiten/Tag	M
	Ln	…	….
Termin	Die Durchführung der Veranstaltung findet vom 27.-29. Juli 2021 statt (T1)	Veranstaltung findet vom 27. bis 29. Juli 2021 statt	M
	Tn	…	…
Kosten	Das Budget in Höhe von 7.500 Euro ist eingehalten (K1)	Gesamtkosten ≤ 7.500 Euro	M
	Kn	…	…
Sozial	Kinder mit Handicap nehmen an der Freizeit teil (S1)	5% bis 10 % der TN mit Handicap	S
	Sn	…	…
Nicht-Ziel	Erwirtschaftung eines Überschusses (N1)
	Nn
Kategorie: M = Muss-Ziel, K = Kann-Ziel, S = Soll-Ziel

Tabelle 9 - Zieltabelle (Beispiel)

Die grafische Darstellung der Zielhierarchie (Hauptziel, Oberziel, Unterziel), erfolgt entsprechend der gewählten Zielart in Form eines Zielbaumes.

Abbildung 13 – Zielhierarchie mit Ergebnis- und Vorgehenszielen

 

 

Abbildung 14 – Zielhierarchie mit Leistungs-, Termin- und Kostenzielen

Zielformulierung, Zielbeziehungen

Bei der Zielformulierung sollten folgende Regeln beachtet werden.

• 1.      vollständig, d.h. alle wesentlichen Projektziele inkl. der Nicht-Ziele sind formuliert
• 2.      quantifiziert, d.h. mit Kriterien, an denen die Zielerreichung überprüfbar/ messbar gemacht werden kann.
• 3.      eindeutig, d.h. klare Formulierung, die keine Alternative zulässt. Worte wie z.B. „möglichst“, „könnte“, „sollte“, „schneller/ weniger als“ sind zu vermeiden
• 4.      positiv, d.h. der Weg zu etwas hin wird beschrieben. Worte wie z.B. „ohne“, „nicht“, „keine“ sind zu vermeiden. Bei Nicht-Zielen reicht daher die Nennung der auszuschließenden Leistung, also „Schulung der Anwender“ statt „Schulung der Anwender ist nicht Bestandteil …“
• 5.      lösungsneutral, d.h. das Ziel ist aus der Nutzung des Projektergebnisses definiert, nicht aus technischer Sicht. Also kein Vorgeben bzw. Ausschließen von möglichen Lösungen.
• 6.      in Zielsprache, d.h. prägnant und in der vollendeten Gegenwart (z.B. … ist erreicht, … ist bezugsfertig, … ist betriebsbereit, … im Einsatz, … ist eingehalten, … ist eröffnet).

Zur Überprüfung der Zielspezifikation eignet sich das Akronym SMART

Tabelle 10 – SMART

 

 

Werden mehrere Ziele für ein Projekt identifiziert, so sind die Beziehungen der Ziele untereinander zu analysieren. Dabei wird zwischen verschiedenen Zielverträglichkeiten bzw. Zielbeziehungen unterschieden. Die Skala geht dabei von Zielidentität über Zielneutralität hin zu Zielantinomie.

Abbildung 15 – Zielbeziehungen

Die Beziehung der Ziele wird in der folgenden Tabelle im Detail beschrieben.

 

Tabelle 11 – Definition der Zielbeziehungen

Anhand einer Zielbeziehungsmatrix können die erarbeiteten Ziele auf ihre gegenseitige Wirkung hin überprüft werden (Paarweiser Vergleich).

 

            Abbildung 16 – Zielbeziehungsmatrix

Anmerkung: Am Häufigsten findet man Konkurrenz-Beziehungen zwischen den einzelnen Zielgegenständen Termin, Kosten und Leistung. Beispielsweise zwischen Termintreue vs. Budget- bzw. Kostentreue, Termintreue vs. Leistungserbringung und/ oder Budget- bzw. Kostentreue vs. Leistungserbringung.

 

 

Umfeld und Stakeholder

Stakeholder (4.5.12) „Die Kompetenz Stakeholder umfasst die Identifikation, die Analyse, das Einbeziehen und Managen der Einstellungen und Erwartungen aller relevanten Stakeholder.“ … „Die Beteiligung der Stakeholder ist ein fortlaufender Prozess, der sich über den gesamten Lebenszyklus des Projekts hinzieht.“ [GPM17a, Seite 155]

Umfeldanalyse

4.5.12 Stakeholder / Bloom’sche Taxonomie 3 – Anwenden

4.2.1 Strategie / Bloom’sche Taxonomie 1 – Wissen

Bevor mit der Planung des Projektes begonnen wird, ist es notwendig, einen prüfenden Blick auf das Projektumfeld zu werfen. Als Projektumfeld wird die Umgebung bezeichnet, in der ein Projekt entsteht und durchgeführt wird, die das Projekt beeinflusst und von dessen Auswirkungen betroffen ist. Projektbeeinflussungen können aus sozialen und sachlichen Umfeldfaktoren resultieren. [BEA11b]

Hinsichtlich der Ausdehnung des Projektumfelds lassen sich

• das unmittelbare (direkte) Projektumfeld, z. B. Auftraggeber, Rahmenbedingungen,
• das mittelbare (indirekte) Projektumfeld, z. B. Firmenleitung, Arbeitsmarkt

unterscheiden. Häufig werden auch die Begriffe „intern“ für unternehmensinterne und „extern“ für unternehmensexterne Einflussfaktoren verwendet. [BEA11b]

Bei den sachlichen Umfeldfaktoren bietet das Akronym PESTEL  ein gutes Hilfsmittel, das der Projektleiter u.a. dazu verwenden kann, die Zusammenhänge zwischen seinem Projekt und dessen Umfeld darzustellen. Das Akronym PESTEL steht dabei für

Akronym	Beschreibung	Beispiele
Political (Politisch)	Aktuelle und potenzielle Einflüsse aus dem politischen Umfeld	Landes- & Bundespolitik, Europapolitik, Medien
Economic (Wirtschaftlich)	Lokale, nationale und weltweite wirtschaftliche Einflussfaktoren	Arbeitsmarkt, Wettbewerber, Kapitalmarkt, Zölle
Social (Gesellschaftlich)	Das sozio-kulturelle Umfeld und Auswirkungen des gesellschaftlichen Wandels	Firmenkultur, Projektkultur, Arbeitsbedingungen, Organisationsform, Migration
Technological (Technisch)	Einfluss/ Auswirkung von Technologie	Technische Infrastruktur, Technologiewandel
Environmental (Ökologisch)	Lokale, nationale und globale Umwelteinflüsse	Wetter, Umweltvorgaben, limitierte natürliche Ressourcen, Abfallbeseitigung
Legal (Gesetzlich)	Auswirkung lokaler, nationaler und internationaler Gesetze und Regularien	Gesetze, Normen, Verordnungen

Tabelle 12 – PESTEL

Innerhalb der sozialen Umfeldfaktoren werden Personen und/ oder Institutionen identifiziert, die das Projekt positiv oder negativ beeinflussen können (siehe Kapitel 3.3.2 Stakeholdermanagement). Eine entsprechende grafische Aufbereitung der gesammelten Umfeldfaktoren kann wie folgt aussehen:

Abbildung 17 – Umfeldanalyse mit Einflussfaktoren (Beispiele)

Die frühzeitige Analyse des Projektumfeldes als systematische Betrachtung der positiven (unterstützenden) und negativen (störenden) Einflüssen auf das Projekt hilft, Chancen zu finden, Risiken zu erkennen und eine adäquate Kommunikationsstrategie festzulegen. Die Umfeldanalyse ist somit ein wichtiger Ausgangspunkt für weiterführende Analysen und daraus abzuleitende Maßnahmen im Laufe des Projekts.

Chancen beinhalten alle Bedingungen, die während der Projektlaufzeit dazu führen, dass die Projektziele besser erreicht werden können. Unter Risiken werden hingegen alle Bedingungen und Situationen zusammengefasst, die das Projekt möglicherweise negativ beeinflussen. Hierbei wird nicht zwischen direkten/ indirekten bzw. internen/ externen Umfeldfaktoren unterschieden.

 

 

 

Sachliche Umfeldfaktoren	Einfluss auf Projekt			Beschreibung	Interaktion mit anderen sachlichen Umfeldfaktoren
	Risiko	Chance	Neutral
Firmenkultur		X		offene Kultur lässt sich ins Projekt übertragen	Wettbewerb Arbeitsmarkt
Arbeitsbedingungen			X
Infrastruktur			X
Gesetze, Normen	X			mögl. Gesetzesänderungen während der Projektlaufzeit	Landespolitik Kapitalmarkt
limitierte natürliche Ressourcen	X			Seltene Erden
Arbeitsmarkt	X			Fachkräftemangel	Landespolitik
Kapitalmarkt			X
Wettbewerb			X		Kapitalmarkt
Landespolitik			X

Tabelle 13 – Chance-Risiko-Bewertung der sachlichen Umfeldfaktoren (Beispiel)

Die möglicherweise risikobehafteten Interaktionen sind mit ihren Ursachen und den daraus für das Projekt entstehenden Folgen kurz zu beschreiben. Zusätzlich können evtl. vorhandene Chancen festgestellt und auf ihre Nutzbarkeit im Projekt hin analysiert werden.

Die detaillierte Analyse sowie das Festlegen und Umsetzen entsprechender Maßnahmen erfolgt für die sozialen Umfeldfaktoren im Stakeholder- (siehe Kapitel 3.3.2) bzw. für die sachlichen Umfeldfaktoren im Risikomanagement (siehe Kapitel 4.6).

 

Stakeholdermanagement

4.5.12 Stakeholder / Bloom’sche Taxonomie 3 – Anwenden

4.3.4 Macht und Interesse / Bloom’sche Taxonomie 3 – Anwenden (Level C)

Stakeholder sind gemäß der ICB 4.0 „alle Einzelnen, Gruppen oder Organisationen, die an dem Projekt beteiligt sind, dieses beeinflussen, davon beeinflusst werden oder an der Durchführung bzw. dem Ergebnis desselben interessiert sind.“ [GPM17a, Seite 155] Das Interesse muss nicht zwingend positiv sein, Stakeholder können auch schädlichen Einfluss auf das Erreichen der Projektziele ausüben.

Unterscheiden lassen sich Stakeholder in primäre und sekundäre Stakeholder. Primäre Stakeholder wirken direkt, Sekundäre hingegen wirken indirekt über ihre Beziehungen und ihren Einfluss. Innerhalb dieser Einteilung kann gemäß dem Promotorenmodell von Witte wiederum in Projektbefürworter (Promotoren) und Projektgegner (Opponenten) unterschieden werden [WITT73].

Witte definiert Promotoren als Rollen, die Prozesse aktiv fördern und beeinflussen. Sein Modell kennt Machtpromotoren  und Fachpromotoren. Später folgte eine Erweiterung um Beziehungs- bzw. Sozialpromotoren und Opponenten.[8]

 

Machtpromotor	Unterstützt bzw. beeinflusst auf Grund seiner Stellung in der Unternehmenshierarchie Durch diese hierarchisch legitimierte Macht ist er in der Lage Opponenten zu beeinflussen Hauptaufgabe für das Projekt: Überzeugungs- und Begeisterungsarbeit im Sinne des Projekts
Fachpromotor	Unterstützt bzw. beeinflusst durch sein spezifisches Fach- und Methodenwissen Finden sich häufig in Linienpositionen mit Affinität zu technischen Neuheiten Hauptaufgabe für das Projekt: Voranbringen der Projektarbeit durch Weitergabe von Wissen und Lösungsansätze für von Opponenten aufgebrachten Problemen zu entwickeln
Beziehungs- bzw. Sozialpromotor	Verfügt über ein starkes Netzwerk von persönlichen Kontakten quer durch alle Hierarchie-Ebenen hindurch Anerkannt und respektiert Hauptaufgabe für das Projekt: Neue Netzwerke aufzubauen und dadurch das Projekt indirekt unterstützen
Opponent	Personen, die ein Projekt verzögern oder verhindern wollen.

Tabelle 16 – Promotoren und Opponenten

Promotoren und Opponenten erhalten ihre Autorität auf unterschiedlichen Machtgrundlagen oder Können. [WUND11] In der Soziologie finden sich die verschiedensten Definitionen zum Machtbegriff. Max Weber (1922) beispielsweise beschreibt Macht als „… jede Chance, innerhalb einer sozialen Beziehung den eigenen Willen auch gegen Widerstreben durchzusetzen.“ Heinrich Popitz (1986) definiert Macht „… als das Vermögen sich als Mensch gegen andere Kräfte durchzusetzen.“

Beide Definitionen betonen das Durchsetzen gegen andere. Dieses „sich durchsetzen“ kann zum einen auf Basis der Stellung des Einzelnen innerhalb einer Hierarchie, also durch organisatorische Weisungsbefugnis, oder ausgehandelt zwischen einzelnen Akteuren von statten gehen. In Anlehnung an die Typologie von French/ Raven (1968) lassen sich dafür fünf bzw. sechs Machtgrundlagen unterscheiden [OLFE15] 

• Expertenmacht (expert power) – Sachkenntnis bezüglich bestimmter Aufgaben und/ oder Probleme. Machtgrundlage für Fachpromotoren, Opponenten
• Informationsmacht (information power) – Zugang zu und Kontrolle von Information, situationsbezogenes spezifisches Wissen. Machtgrundlage für Fachpromotoren, Opponenten
• Referenzmacht (referend power) – Vorbild-/Identifikationsfunktion. Machtgrundlage für Beziehungs- bzw. Sozialpromotoren, Opponenten
• Legitimationsmacht (legitimate power) – festgelegte und akzeptierte Befugnisse, hierarchische Ordnung innerhalb des Unternehmens. Machtgrundlage für Machtpromotoren, Opponenten
• Belohnung- (reward power) und Bestrafungsmacht (coercive power) – Sanktionsgewalt in positivem (Belohnung) und negativem (Bestrafung) Sinne. Machtgrundlage für Machtpromotoren

 

	Abgrenzung Macht und Autorität
	Macht ist ein politisch-soziologischer Grundbegriff, der für Abhängigkeits-  oder Überlegenheitsverhältnisse verwendet wird. Der Machthaber hat die Möglichkeit, ohne Zustimmung, gegen den Willen oder trotz Widerstandes des Beherrschten die eigenen Ziele mit Anwendung von Machtmitteln (z.B. Belohnung, Bestrafung) durchzusetzen. Macht kann auf verschiedenen Machtgrundlagen basieren (s.o.), ihre Ausübung ist mit Aufwand verbunden (z.B. laufende Kontrolle). [WUND11]  instabile Führung	Autorität ist die Möglichkeit einer Person, Gruppe oder Institution, Einfluss auf andere auszuüben und ggf. den eigenen Willen gegenüber diesen durchzusetzen. Dadurch entsteht ein Verhältnis der Über- und Unterordnung. Arten von Autorität Personale Autorität: Der Anspruch auf Autorität wird mit personengebundenen Merkmalen (z.B. Körperkraft, Leistung, Alter, Wissen, Erfahrung) begründet. Funktionale Autorität (professionelle Autorität): Beruht auf überlegener und nachweisbarer Sachkunde oder Wissen. Positionale Autorität: Leitet sich aus der Position, dem Amt oder dem Rang ab und besteht unabhängig von der Person des Positionsinhabers. [GABL18]  stabile Führung

 

 

Prozess

Abbildung 19 – Prozess Stakeholdermanagement

 

Identifizieren der Stakeholder

Ein erster Schritt zur Identifizierung der Stakeholder wurde bereits mit der Umfeldanalyse (soziale Umfeldfaktoren) gemacht. Jetzt gilt es, diese noch einmal zu verifizieren und mit Hilfe der einen oder anderen Kreativitätstechnik die Stakeholderliste zu ergänzen bzw. zu aktualisieren. Ein Sortieren nach Promotoren, Opponenten und Unentschlossenen kann hierbei unterstützend wirken.

Ebenfalls hilfreich kann die Überlegung sein, wer an das Projekt Anforderungen haben und/oder Input liefern wird (upstream) und wer mit den Ergebnissen des Projekts nach dessen Abschluss umgehen soll (downstream).

Analysieren und bewerten der Stakeholder

Die Analyse und Bewertung hat für alle Stakeholder des Projektes zu erfolgen.. Im Minimum beinhaltet die Analyse Fragen zu Erwartungen/ Befürchtungen, Einfluss und dem zu erwartenden Konfliktpotenzial. Selbstverständlich lässt sich die Analyse auch auf andere Bereiche ausdehnen – „Einstellung zum Projekt“ und „Grad der Betroffenheit“ sind davon zwei Beispiele.

Leitfragen zum Erfassen von Erwartungen/ Befürchtungen und Bewerten von Einfluss und Konfliktpotenzial können wie folgt lauten:

Erwartungen/ Befürchtungen

Welche Motive hat der Stakeholder, das Projekt zu unterstützen/ nicht zu unterstützen? Was sind seine Erwartungen an das Projekt/ Projektergebnis? Welche Befürchtungen hat er in Bezug auf den Projektverlauf, das Projektergebnis? Welche persönlichen Ziele hat der Stakeholder in Bezug auf das Projekt?

Einfluss (Macht)

Ist der Stakeholder ein Machtpromotor (Stellung in der Hierarchie)? Kann er das Projekt unterstützen/ voranbringen/ zum Scheitern bringen? Kann er die Meinung anderer beeinflussen?

Konfliktpotenzial

Ist der Stakeholder ein Opponent (Gegner des Projekts)? Weichen die persönlichen Ziele des Stakeholders von den Projektzielen ab? Wie stark weichen sie ab? Ist der Stakeholder vom Projektergebnis aus seiner Sicht stark betroffen? Eher positiv oder eher negativ?

 

Für die Bewertung von Einfluss und Konfliktpotenzial empfiehlt es sich, keine Zahlen zu verwenden, sie ist eine subjektive Einschätzung des Projektleiters bzw. des Projektteams und deren Erfahrungen. Für diese Einschätzung hat sich die Einteilung in hoch und niedrig bewährt. Die Darstellung der Stakeholderanalyse erfolgt mittels einer Tabelle.

 

Tabelle 17 – Stakeholdertabelle (Beispiel)

Nach erfolgter Bewertung der Stakeholder können diese in ein Portfolio mit vier Quadranten visualisiert werden. Der Vorteil dieser Darstellung liegt darin, dass sofort sichtbar wird, auf welchen Stakeholdern der Fokus des Projektleiters liegen sollte (i.d.R. rechts oben, hoher Einfluss und hohes Konfliktpotenzial).

 

Abbildung 20 – Stakeholderportfolio

 

Maßnahmenplanung

Die zu planenden Maßnahmen der Stakeholdersteuerung bedienen sich der Instrumente des Projektmarketing und der Projektkommunikation. Während sich die Projektkommunikation eher an die projektinternen Stakeholder richtet, beschäftigt sich das Projektmarketing überwiegend mit den projektexternen Stakeholdern und zielt darauf ab, den Bekanntheitsgrad des Projektes zu erhöhen sowie dessen Image zu verbessern [PATZ17].

Je nachdem wie die Einschätzung der Anspruchsgruppen ausgefallen ist, sollte eine geeignete Kommunikationsstrategie gewählt werden, um die einzelnen Stakeholder abzuholen, zu informieren und bei ihnen eine positive Einstellung zum Projekt zu fördern. Dabei ist es sinnvoll, zu wichtigen Stakeholdern eine individuelle Kommunikation zu pflegen, andere Stakeholder können mit weniger Aufwand informiert werden.

Die Planung der Maßnahmen wird pro Quadrant des Stakeholderportfolios vorgenommen. Dabei ist zu beachten, dass die Stakeholder in Quadrant I (hoher Einfluss/ hohes Konfliktpotenzial) die meiste Aufmerksamkeit und somit auch die meiste Zeit des Projektleiters in Anspruch nehmen, da diese für den gewünschten Erfolg 1:1 (Projektleiter direkt mit dem Stakeholder) individuell betreut werden müssen. Der Aufwand für die Betreuung der Stakeholder in den Quadranten II (niedriger Einfluss/ hohes Konfliktpotenzial) und IV (hoher Einfluss/ niedriges Konfliktpotenzial) ist wesentlich geringer, da sie entweder dem Projekt sowieso positiv gegenüber eingestellt sind oder nur wenig Einfluss haben und somit keine größere Gefahr für das Projekt bedeuten. Hier ist eine 1:n Betreuung (z.B. via Meeting) ausreichend. Die im Quadrant III gelisteten Stakeholder werden üblicherweise über unpersönliche Medien bedient (m:n), z.B. über Newsletter oder Infoveranstaltungen.

Entsprechend ist für den jeweiligen Quadranten eine der folgenden Strategien zu wählen [RÖSS08].

 

partizipativ – Stakeholder als Partner
Die partizipative Strategie zielt darauf ab, die Stakeholder in unterschiedlicher Intensität partnerschaftlich am Projekt zu beteiligen. Die Beteiligung reicht von der Information, Kommunikation und Diskussion der Ziele, Aufgaben und des Projektstandes über die aktive Beteiligung bis hin zur Übertragung von Verantwortung durch die Einbindung in den Entscheidungsbildungsprozess. Ganz nach dem Motto „Betroffene zu Beteiligten machen.“

diskursiv – (lateinisch discursivus‎ „fortschreitend erörternd“) die sachliche Auseinandersetzung mit den Stakeholdern (kann auch Konfliktmanagement bedeuten)

repressiv bzw. restriktiv – bewusst reduzierte Informationsabgabe
Im Gegensatz zu den beiden anderen Strategien besteht hier die Vorgehensweise darin, über andere Akteure, z.B. Machtpromotoren, die Stakeholder zu beeinflussen und zu steuern, Dies kann u.a. durch direkte Weisungen und Vorgaben der Geschäftsleitung oder durch selektive Verbreitung von Informationen geschehen.

Die aus den jeweiligen Strategien abgeleiteten Maßnahmen finden sich dann in einem Kommunikationsplan wieder. Dieser Plan lässt sich angelehnt an die Kommunikationsformel von Harold D. Lasswell,  aufbauen.

 

 

Auf Basis der Stakeholderanalyse lässt sich damit festlegen Wer, Was, Wann, Wie und durch Wen mit Informationen „versorgt“ wird um eine reibungs- und lückenlose Kommunikation zu und mit den Stakeholdern sicherzustellen. Die Stakeholder können hier auch passend zu den gewählten Strategien pro Quadrant gruppiert werden.

Der Projektleiter sollte sich bei all der Planung nicht selbst vergessen: Wer Informationen liefern soll, muss erstmal welche bekommen …

 

Nr	Wer	Was	Wann	Wie	durch Wen
1	N.N., Auftraggeber	Generelle Infor­mationen über das Projekt Demonstration fertiger Teilprodukte	Zu allen Meilensteinen Evtl. Sprint Review	Meeting, persönliches Gespräch, Statusbericht	Projektleiter und Fachkoordinatoren
2	Nutzer	Informationen zu fertiggestellten Funktionen, Demonstration fertiger Teilprodukte	Quartalsweise Evtl. Sprint Review	Newsletter, Intranetseite Demo	Projektleiter, Teilprojektleiter, Fachspezialist
3	N.N., Arbeitspartner				Projektassistenz
4	N.N., Firmenleitung	Informationen zum Projektfortschritt		Meeting, persönliches Gespräch	Projektleiter
5	N.N., Lieferant			Mail, Telefon	Projektassistenz
6	N.N., Geldgeber	Informationen zum Projektfortschritt		Meeting, persönliches Gespräch	Projektleiter
7	N.N., Projektleiter	Status der Arbeitspakete Mögliche Probleme, Hindernisse	Wöchentlicher Jourfix Evtl. Daily Scrum	Meeting, persönliches Gespräch	Projektteam, Arbeitspaketverantwortliche
n	…

Tabelle 18 – Kommunikationstabelle (Beispiel)

All diese Maßnahmen dienen dazu, die Stakeholder in den Projektverlauf einzubeziehen, sogar einzubinden um wichtige Informationen und Anregungen zu erhalten. Die ICB 4.0 verwendet hierzu den Begriff Verpflichtungsstrategie [GPM17a], andere sprechen vom Stakeholder Engagement [APM17b] oder von Stakeholder Stewardship [GRIF15]. Hinter jeder Bezeichnung steht aktives Tun, kein passives Abwarten, um die Stakeholder frühzeitig, regelmäßig, ehrlich und proaktiv über das Projekt auf dem Laufenden zu halten.

 

Controlling des Prozesses

Sowohl die Wirksamkeit der ergriffenen Maßnahmen als auch die Situation der Stakeholder müssen regelmäßig überwacht und analysiert werden. Nur dann lässt sich feststellen, ob sich die Erwartungen/ Befürchtungen und/ oder die Machtsituation der Stakeholder verändert hat und neue Stakeholder die Projektbühne betreten haben. Dies und die übliche Dynamik des Projektumfeldes machen es notwendig, den gesamten Prozess regelmäßig, wenigstens am Ende einer jeden Phase, zu durchlaufen. Die Veränderung der Stakeholder lässt sich ebenfalls in einem Portfolio darstellen [GPM17b].

Abbildung 21 – Stakeholderportfolio (Maßnahmen)

 

Die ursprüngliche Quadrantenstrategie dürfte sich allerdings kaum durchhalten lassen. Es ist schwer vorstellbar, dass sich die Firmenleitung (Stakeholder 4) nach den durchgeführten persönlichen Maßnahmen jetzt mit Maßnahmen aus der diskursiven „Strategiekiste“ zufrieden sein wird. Das reduzierte Konfliktpotenzial wird schnell wieder zur vollen Größe anwachsen. D.h. letztendlich trotz aller Pläne – der gesunde Menschenverstand sollte immer mit einbezogen werden.

 

 

Projektphasen

4.5.1 Projektdesign / Bloom’sche Taxonomie 1 – Wissen

4.5.4 Ablauf und Termine / Bloom’sche Taxonomie 3 – Anwenden

Entsprechend des gewählten Projektdesigns oder der Vorgaben des Unternehmens auf Basis eines Vorgehensmodells, wird das Projekt in einzelne Abschnitte, die Projektphasen, unterteilt. Das Thema Projektphasen ist Bestandteil des ICB-Elements Ablauf und Termine, das in Kapitel 4.2 näher beschrieben wird.

Projektphasen sind der erste Planungsschritt zur Aufteilung des Gesamtvorhabens, sie gliedern ein Projekt in zeitliche Abschnitte, die inhaltlich voneinander abgegrenzt sind. Diese Phasen haben eine klare Zielsetzung, nutzen Ressourcen zur Erstellung wichtiger Lieferobjekte und beinhalten auch Entscheidungen als Grundlage für die folgende Projektphase. Die Abfolge der Phasen eines Projekts zusammen wird auch als Projektlebenszyklus bezeichnet. [DIN16a]

Im Unterschied zu den Projektphasen welche die inhaltlichen Aktivitäten des Projektes widerspiegeln, orientiert sich die Phaseneinteilung für das Projektmanagement an den logisch zusammenhängenden Aktivitäten des Projektmanagements – Initialisierung, Definition, Planung, Steuerung, Abschluss – den Projektmanagementphasen. [DIN16a]

Mit der Erstellung des Phasenplans liegt eine erste Grobplanung und damit eine Machbarkeitsprüfung für die vom Auftraggeber genannten Projektziele vor. An dieser Stelle kann eine Go/ Nogo-Entscheidung für das Projekt getroffen werden.

Elemente des Phasenplans

Der Phasenplan enthält Hauptaktivitäten, die in den einzelnen Phasen zusammengefasst werden. Die Projektphasen beginnen üblicherweise mit einem Meilenstein und werden mit einem solchen Entscheidungspunkt bzw. Ereignis besonderer Bedeutung [DIN16a] abgeschlossen. Diese Ereignisse können sein

• Prüfungen bzw. Abnahmen
• „Etappenziel“
• Entscheidungen z.B. über den Beginn der nächsten Phase

Meilensteine haben eine Dauer von Null und werden im Phasenplan üblicherweise mit einer Raute dargestellt. Zum besseren Verständnis und Lesbarkeit werden die Meilensteine inkl. einer Beschreibung des dazugehörenden Ereignisses in einer Tabelle aufgelistet.

Um die Zielwünsche (Termine und Kosten) des Auftraggebers auf Machbarkeit prüfen zu können, werden voraussichtlichen Dauern und die erwarteten Kosten der Hauptaktivitäten grob abgeschätzt und zu Projektsummen aggregiert. Dies geschieht sinnvollerweise durch Erfahrungswerte abgeschlossener ähnlicher Projekte oder durch Expertenschätzung.

Bei allen Schätzungen hat der Projektleiter in der darauffolgenden Kommunikation den Auftraggeber deutlich auf deren vorläufigen Charakter hinzuweisen, um unerwünschte und sachlich falsche finale gedankliche Festlegungen zu vermeiden.

Projektmanagement taucht im Phasenplan nicht als eigene Phase auf, da es sich bei den PM-Aktivitäten um phasenbegleitende Querschnittsfunktionen handelt, die sich über alle Projektphasen erstrecken. Budgetär wird es in dieser Planungsstufe mit 10 bis 15% der geschätzten Kosten berücksichtigt (falls keine sachlogischen Gründe eine höhere oder niedrigere Annahme rechtfertigen).

Ein Beispiel für einen Phasenplan (Wasserfall Modell) folgt auf den nächsten Seiten.

 

1.   Liste der Projektphasen mit Ziel und Hauptaktivitäten

Tabelle 19 – Projektphasen und Hauptaktivitäten (Beispiel)

2.   Liste der Meilensteine mit Ergebnis

Tabelle 20 – Meilensteintabelle (Beispiel)

3.   Phasenplan

Abbildung 22 – Phasenplan (Beispiel)

 

In der Phasenplanung können auch agile Elemente Anwendung finden:

Die Übergänge der Phasen, also zu einem Meilenstein, lassen sich auch mit einer Retrospektive  gestalten. Eine Retrospektive (siehe auch Kapitel 8.1.3.5) setzt sich mit der Kooperation im Team auseinander, identifiziert konkrete Verbesserungen für die Zusammenarbeit und den Arbeitsprozess. Diese Verbesserungen werden gleich in der nächsten Phase umgesetzt. [PREU18, DRÄT19]

 

Planungsphase

Abbildung 27 – ICB-Elemente in der Planungsphase

 

In der Planungsphase werden die wesentlichen Bedingungen für das Projekt festgelegt. Durch die Planung sollen realistische Werte für Leistung, Kosten und Termine ermittelt werden. Damit können Fehler reduziert, mangelnde Abstimmung verhindert und so Fehlentwicklungen in einem frühen Projektstadium vermieden werden. Die Projektplanung umfasst u.a. die Planung der Projektstruktur, des Projektaufwandes, des Ressourceneinsatzes und der Kosten. Abhängig von den konkreten Anforderungen im Projekt werden zum Abschluss der Planungsphase noch die Vertragsinhalte mit den Lieferanten abgestimmt. [GPM17b]

Grundsätzlich sollten bei der Planung folgende Fragen geklärt werden um eine Konzept- bzw. Planungsfreigabe als Ergebnis dieser PM-Phase zu erhalten. [BERG16]

Was?	Was muss im Detail gemacht werden (Projektstrukturplan)?
Wie?	Wie soll vorgegangen werden (Ablaufplan)? Welche Mittel und Ressourcen werden eingesetzt (Einsatzmittelplan)?
Wann?	Wann wird mit dem Projekt begonnen? Wann soll/ muss es fertig sein (Terminplan)?
Wie viel?	Wie viel wird das Projekt kosten und wie erfolgt die Finanzierung (Kosten- und Finanzplanung)?
Welche?	Welche Risiken bzw. Chancen bestehen (Risikoplan)?
Wie gut?	Welche Qualitätsziele müssen erreicht werden und wie wird deren Erreichung sichergestellt (Qualitätsplan)?

Tabelle 25 – Fragen während der Planungsphase

Die Planungsphase enthält verschiedene ICB-Elemente aus dem Bereich Practice. Allerdings in veränderter Reihenfolge. Aus Sicht des Autors macht es mehr Sinn, sich zuerst um den Ressourcenbedarf zu kümmern und dann darauf aufbauend die Kostenplanung durchzuführen. Die Themen Chancen und Risiken sowie Qualität sind projektbegleitende Prozesse und können auch in einer früheren Projektmanagementphase gestartet bzw. durchgeführt werden.

 

Chancen und Risiken

Chancen und Risiken (4.5.11) „Die Kompetenz Chancen und Risiken umfasst die Identifikation, die Analyse, die daraus resultierende Planung und Umsetzung sowie die Steuerung der Chancen und Risiken eines Projekts. … Beim Management von Chancen und Risiken handelt es sich um einen fortlaufenden Prozess, der sich über den gesamten Lebenszyklus des Projekts erstreckt.“ [GPM17a, Seite 150]

Grundlagen Chancen und Risiken

4.5.11 Chancen und Risiken / Bloom’sche Taxonomie 3 – Anwenden

Neben der Notwendigkeit Risikomanagement auf Grund gesetzlicher (z.B. KontraG), normenseitiger (z.B. ISO 9001) und unternehmensspezifischer Anforderungen (z.B. Corporate Governance) durchzuführen gehört es auch zu den Projektmanagementaufgaben innerhalb des Projektlebenszyklus. Risikomanagement hilft, Projektrisiken zu vermeiden, zu verringern oder zu begrenzen. Ebenfalls fällt in dieses Aufgabenspektrum das Fördern von Projektchancen, also von positiven Entwicklungsmöglichkeiten.

Risikomanagement …

• verbessert den Handlungsspielraum des Projektleiters.
• identifiziert und steuert Risiken im Projekt.
• stellt ein Frühwarnsystem dar, durch das Risiken minimiert und beherrscht werden können.
• erkennt Chancen für das Projekt und zeigt Wege zu deren Nutzung auf.
• verbessert die Kommunikation und den Umgang mit Risiken und Chancen.

Das Wort „Risiko“ leitet sich aus dem frühitalienischen ris(i)co ab – eine Klippe, die es zu umschiffen gilt. Die DIN 69901-5:2009 bezeichnet ein Risiko als

„Mögliche negative Abweichung im Projektverlauf (relevante Gefahren) gegenüber der Projektplanung durch Eintreten von ungeplanten oder Nicht-Eintreten von geplanten Ereignissen oder Umständen (Risikofaktoren).“ [DIN16a, Seite 159]

Kürzer fasst sich die Norm DIN ISO 31000:2018 Risikomanagement – Leitlinien. Sie bezeichnet ein Risiko als

„Auswirkung von Unsicherheit auf Ziele“ [DIN18, Seite 7]

Prozess

4.5.11 Chancen und Risiken / Bloom’sche Taxonomie 3 – Anwenden

Das Risikomanagement folgt dem Prozess Identifizieren – Analysieren – Planen – Controlling. Dieser Prozess wird spätestens bei jedem Meilenstein erneut durchlaufen, um den Status der bekannten Risiken festzustellen und neue zu identifizieren.

Abbildung 59 – Risikoprozess

Risiken identifizieren

Hier wird die enge Verzahnung mit der Umfeldanalyse sichtbar. In den Kategorien sachlich und direkt/indirekt bzw. intern/extern bereits identifizierte Bestandteile können direkt in die Risiko-Tabelle übernommen werden. Die während der Umfeldanalyse identifizierten Stakeholder (Kategorien sozial und direkt/indirekt bzw. intern/extern) werden via Stakeholderanalyse, wo notwendig, ebenfalls in die Risiko-Tabelle übernommen. Zur Identifikation weiterer Risiken empfehlen sich verschiedene Kreativitätstechniken (z.B. Brainwriting, Mind Mapping, Kopfstandmethode, FMEA), Checklisten sowie das systematische Durchforsten der bisher erstellten Projektpläne (PSP, Ressourcenplan, Ablauf- und Terminplan, Kostenplan) auf potenzielle Risiken. Hilfreich ist auch die Kategorisierung nach Risikoarten wie beispielsweise

• Kaufmännische Risiken
• Ressourcen Risiken
• Technische Risiken
• Terminrisiken
• Politische Risiken

In dieser Phase sind alle identifizierten Risiken ernst zu nehmen – keine „Das schaffen wir schon“-Mentalität – jedes identifizierte Risiko ist wichtig genug, um betrachtet zu werden.

Die identifizierten Risiken werden in einer Tabelle gesammelt und strukturiert. Alle Risiken sind präzise zu benennen und zu beschreiben.

 

#	Risiko	Ursache (n)	Klassifizierung
1	Streik der Drehbuchautoren	nicht erfüllte Lohnforderungen	Terminrisiko
2	Bereits genehmigte Außenaufnahmen werden verboten	Einstellung zum Filmprojekt hat sich bei den zuständigen Behörden geändert	Politisches Risiko
3	Spezialisten stehen nicht zum vereinbarten Zeitpunkt zur Verfügung	Unklare Vorgaben bei Vertragsabschluss mit der Agentur	Ressourcen Risiko
n	…	…	…

Tabelle 38 – Risikotabelle

Zur besseren Visualisierung können die Risiken in einem Portfolio dargestellt werden. Hierzu werden sie bezüglich Schadenshöhe (SH, auch Tragweite) und Eintrittswahrscheinlichkeit (ETW) qualifiziert und entsprechend im Portfolio eingeordnet. Eine Qualifizierung der Risiken kann beispielsweise nach „sehr hoch, hoch, niedrig, sehr niedrig“ erfolgen. Es empfiehlt sich, die Ausprägung „mittel“ nicht zu verwenden, um den Beteiligten eine eindeutige Stellungnahme abzuringen.

 

#	Risiko	Ursache (n)	Auswirkung	ETW	SH
1	Streik der Drehbuchautoren	nicht erfüllte Lohnforderungen	Drehbuch wird nicht rechtzeitig fertig, Start der Dreharbeiten verzögert sich	n	h
2	Bereits genehmigte Außenaufnahmen werden verboten	Einstellung zum Filmprojekt hat sich bei den zuständigen Behörden geändert	Neue Drehorte müssen ausgewählt werden, Genehmigungen müssen neu eingeholt werden, Dreharbeiten verzögern sich	h	sh
3	Spezialisten stehen nicht zum vereinbarten Zeitpunkt zur Verfügung	Unklare Vorgaben bei Vertragsabschluss mit der Agentur	Verzögerungen bei den Dreharbeiten oder qualitative Einschränkungen, da nur „2. Wahl“ zur Verfügung gestellt wird	n	sh
n	…	…	…	…	…
sn = sehr niedrig, n = niedrig, h = hoch, sh = sehr hoch

Tabelle 39 – Qualifizierte Risikotabelle mit ETW und SH

 

Abbildung 60 – Qualifiziertes Risikoportfolio (Beispiel)

 

 

 

Risiken analysieren

Nach der Identifikation der Risiken folgen in dieser Phase deren Analyse und Bewertung und damit ihrer Quantifizierung. Es sind Überlegungen anzustellen bezüglich der Auswirkung, Schadenshöhe (auch Tragweite) und der Eintrittswahrscheinlichkeit. Hierzu kann die bereits genutzte Risikotabelle um die notwendigen Felder ergänzt werden. Der Risikowert (RW) ist das Produkt aus Eintrittswahrscheinlichkeit (ETW) und Schadenshöhe (SH) des Risikos.

 

ETW (%) * SH (€) = RW (€)

 

Die Höhe der Eintrittswahrscheinlichkeit ist, unerheblich ob individuell oder in einer Gruppe festgelegt, immer ein subjektiver Wert, welcher die Risikopräferenz (risikofreudig, risikoneutral oder risikoavers) des Entscheiders/ der Entscheider widerspiegelt.

 

#	Risiko	Ursache (n)	Auswirkung	ETW in %	SH in €	RW in €
1	Streik der Drehbuchautoren	nicht erfüllte Lohnforderungen	Drehbuch wird nicht rechtzeitig fertig, Start der Dreharbeiten verzögert sich	5%	200.000	10.000
2	Bereits genehmigte Außenaufnahmen werden verboten	Einstellung zum Filmprojekt hat sich bei den zuständigen Behörden geändert	Neue Drehorte müssen ausgewählt werden, Genehmigungen müssen neu eingeholt werden, Dreharbeiten verzögern sich	20%	450.000	90.000
3	Spezialisten stehen nicht zum vereinbarten Zeitpunkt zur Verfügung	Unklare Vorgaben bei Vertragsabschluss mit der Agentur	Verzögerungen bei den Dreharbeiten oder qualitative Einschränkungen, da nur „2. Wahl“ zur Verfügung gestellt wird	5%	500.000	25.000
n	…	…	…	…	…	…
				S Risikowerte		125.000

Tabelle 40 – Quantifizierte Risikotabelle mit ETW und SH

Die grafische Darstellung erfolgt mit Hilfe einer Grafik, ähnlich der eines Risikoportfolios.

Abbildung 61 – Quantifizierte Risikodarstellung (Beispiel)

Wird ein Risiko mit einer Eintrittswahrscheinlichkeit > 50% bewertet, ist es als Tatsache zu betrachten und die notwendigen Arbeiten zur Vermeidung, Verminderung und/oder Verlagerung sind als Arbeitspaket in den Projektstrukturplan aufzunehmen.[9]

Der Risikowert (Expected Monetary Value) entspricht dem gewichteten Mittelwert bzw. den erwarteten Kosten bei Eintreten des Risikos. Die Summe der Risikowerte sollte als Risikorückstellung in die Kostenplanung einfließen. Diese Risikoreserve wird in der Regel ausreichen, um für die tatsächlich eingetretenen Risiken aufzukommen.

 

Maßnahmen planen und umsetzen

Nachdem die Risiken identifiziert, ihre Ursachen hinlänglich beschrieben und der jeweilige Risikowert ermittelt wurde, gilt es in diesem Schritt die geeigneten Risikostrategie und die entsprechenden Maßnahmen festzulegen.

Als Risikostrategie wird der Umgang und die Gestaltung der Risikobewältigung in Projekten bezeichnet. Grundsätzlich stehen verschiedene Handlungsalternativen zur Verfügung. [DIN18]

Abbildung 62 – Risikostrategien

Hierbei unterscheidet man zwischen präventiven (ursachenbezogenen), korrektiven (auswirkungsbezogenen) und selbsttragenden Handlungsalternativen.

Präventive Maßnahmen wirken, bevor das Risiko eintritt, beeinflussen also die Eintrittswahrscheinlichkeit. Korrektive Maßnahmen verringern nach Eintritt des Risikos die Tragweite bzw. die Schadenshöhe.

Generell gilt, Maßnahmen kosten Zeit und/ oder Geld, nehmen also Ressourcen in Anspruch, die nur begrenzt zur Verfügung stehen. Sie sind also entsprechend der gewählten Risikostrategie zu planen.

 

	Strategie	Vorgehen
Präventive Maßnahmen	vermeiden	Das Risiko wird gar nicht erst eingegangen (z.B. neue, noch unerprobte Technologie wird nicht eingesetzt).
	Vermindern	beinhaltet alle Aktivitäten zur direkten Beeinflussung des Risikos, sei es über die Senkung der ETW. Risiken können über technische, organisatorische oder personelle Maßnahmen reduziert werden
Korrektive Maßnahmen	begrenzen	Folgen des Schadensfalles werden minimiert. Die Maßnahmen greifen erst, wenn das Risiko eingetreten ist (z.B. Redundanz vorsehen)
	verlagern	Das Risiko wird auf Dritte übertragen, beispielsweise auf Versicherungen, Lieferanten, Kunden, Staat (z.B. Hermes-Bürgschaft zur Absicherung von Exporten). Diese Übertragung erfolgt i.d.R. mit Verträgen und findet nicht unentgeltlich statt. (z.B. Risikoprämie bei Versicherungen).
Selbsttragende Maßnahmen	akzeptieren	Das Risiko wird vom Management akzeptiert, es werden keine Maßnahmen festgelegt. Meist sind dies Risiken mit geringer Schadenshöhe und niedriger Eintrittswahrscheinlichkeit.

Tabelle 41 – Maßnahmen und Risikostrategie

Je nach gewählter Maßnahme verringert sich die Eintrittswahrscheinlichkeit (präventiv) oder die Schadenshöhe (korrektiv). Es sind auch beide Fälle möglich, wenn für ein Risiko sowohl präventive als auch korrektive Maßnahmen zur Anwendung kommen können.

 

ETW_neu (%) * SH (€) = RW_neu (€) bzw. ETW (%) * SH_neu (€) = RW_neu (€)

 

Ein Anhaltspunkt dafür, welche der geplanten Maßnahmen umgesetzt werden sollen, ist, dass die Summe aus RW_neu und den Kosten der Maßnahme kleiner sein sollte als der alte Risikowert.

 

RW_neu (€) + Kosten der Maßnahme (€) < RW_alt (€)

 

Geht es allerdings um sogenannte nicht tolerierbare Risiken, so sind in jedem Fall Maßnahmen zu ergreifen, auch wenn dies im Extremfall bedeutet, das Projekt nicht durchzuführen. Als nicht tolerierbare Risiken werden solche bezeichnet

 

• bei denen Leib und Leben von Menschen bedroht sind
• die erhebliche Schäden an der Umwelt verursachen können
• die die wirtschaftliche Existenz des Unternehmens gefährden können

 

Maßnahmen controlling

Nachdem die Maßnahmen geplant und angestoßen wurden, sind sie in der Folge zu überwachen und gegebenenfalls zu steuern. Das Risikocontrolling ist häufig ein Teil des Projektcontrollings. Es ist für den Projektleiter ein unverzichtbares Instrument während des gesamten Projektverlaufs. Die mit den Maßnahmen festgelegten Kontrollzeitpunkte (z.B. Meilenstein, eintretendes Ereignis, 14-tägiger Jour-Fixe) sorgen für eine erneute Analyse und Bewertung des Risikos bzw. der Risiken. Ergebnisse dieser Überprüfung können sich in allen Projektplänen (z.B. Ressourcenplanung, Kostenplanung, Ablauf-und Terminplanung) niederschlagen und führen möglicherweise zu deren Anpassung.

Die aktuelle Risikosituation ist auch Bestandteil des regelmäßigen Projektstatusberichts.

 

 

 

Abschlussphase

Abbildung 72 – ICB-Elemente in der Abschlussphase

Der Projektabschluss ist Bestandteil des ICB-Elements Planung und Steuerung, das bereits im Kapitel 5 Steuerungsphase beschrieben wurde. Weiterhin findet sich in diesem Kapitel ein Kompetenzelement aus Compliance, Standards und Regularien (siehe Kap. 1.6 Standards im Projektmanagement), welches thematisch den Projektabschluss ergänzt.

Projektabschluss

4.5.1 Projektdesign / Bloom’sche Taxonomie 1 - Wissen

4.5.10 Planung und Steuerung / Bloom’sche Taxonomie 2 – Verstehen

Projekte sind zeitlich begrenzte Vorhaben. Daher ist es wichtig, ein Projekt für alle Stakeholder sichtbar zu beenden. Die Abschlussphase sollte bestimmten Formalien folgen und zum Ziel haben [KERZ17]

• das Projekt gemäß den vertraglichen Vereinbarungen zu beenden
• die Projektleistung zu analysieren (Nachkalkulation, Wirtschaftlichkeitsanalyse)
• die Erfahrungen während des Projektes zu sammeln und zu analysieren (Lessons Learned)
• die Ressourcen rückzuführen (Menschen, Maschinen, Material)
• die Projektorganisation aufzulösen
• einen Abschlussbericht zu erstellen

Leider zeigt die Erfahrung, dass der Projektabschluss eher stiefmütterlich behandelt wird. Projekte „fransen aus“, sie sind für einen Teil der Mitarbeiter beendet, für andere nicht. Kostenstellen werden nicht geschlossen, so dass die Buchung von Stunden und Ausgaben auf das Projekt weiter gehen kann. [PATZ17]

Dieses „Verhalten“ kann häufig bei erfolglosen Projekten beobachtet werden. Keiner, weder Projektleiter noch Management, möchte in diesem Fall der Wahrheit ins Gesicht sehen, dass das Projekt gescheitert ist. Man lässt es lieber „auslaufen“. Das Versäumnis, ein Projekt systematisch abzuschließen, widerfährt aber durchaus auch Projekten, die als erfolgreich bezeichnet werden können. Gründe dafür können sein

• dass die Projektmitarbeiter mit allerlei zusätzlichen Aufgaben das Projektende hinausschieben, da sie nicht wissen, wie bzw. wo es nach Projektende für sie weiter geht
• dass an einem systematischen Projektabschluss kein Interesse besteht, da der Nutzen nicht gesehen und das Vorgehen nur als reiner Formalismus wahrgenommen wird
• dass zu Beginn des Projektes keine klare Zieldefinition erfolgt ist und somit die Voraussetzungen für den Projektabschluss fehlen
• dass seitens des Managements mit Lieferung des Projektergebnisses das Interesse am Projekt schwindet, es nicht mehr die ursprüngliche Priorität genießt und damit die Abschlusssitzung immer weiter nach hinten geschoben wird, bis sich das Projekt quasi von alleine auflöst, weil alle Mitarbeiter bereits in neuen Projekten beschäftigt sind [BEA11b]

Prozess

  Abbildung 73 – Prozess Projektabschluss

 

Produktabnahme

Die Phase der Produktabnahme  teilt sich in die Tätigkeiten der Produktabnahme, der Abnahmeprüfung, der Klärung der Betreuung nach dem Projektende und der eigentlichen Produktübernahme. Unter Produkt wird in diesem Zusammenhang das im Projektauftrag formulierte Projektergebnis verstanden. Die Dokumentation erfolgt im Produktabnahmebericht. [GPM17b]

Dieser Bericht stellt das juristische Ende des Projektes dar. Die sich daraus ergebenden Konsequenzen finden sich in Kapitel 4.5.4 Abnahme (Definition)

 

Abschlussanalyse

Während der Abschlussanalyse  werden eine Nachkalkulation und eine Wirtschaftlichkeitsanalyse durchgeführt. Mittels einer Abweichungsanalyse werden die evtl. festgestellten Abweichungen bzgl. Kosten, Termine, Leistung und Qualität auf ihre Ursachen hin analysiert.

Mit der Nachkalkulation wird der betriebswirtschaftliche Erfolg des Projektes ermittelt, indem alle relevanten kaufmännischen Daten zusammengestellt und mit den Vorgaben aus der Planung abgeglichen werden. Diese Informationen sind zum einen Bestandteil des Projektabschlussberichtes, zum anderen Input für die Phase Erfahrungssicherung. [DIN16a, PATZ17]

Die Wirtschaftlichkeitsanalyse in dieser Phase ist ein Soll/ Ist-Vergleich mit der Wirtschaftlichkeitsrechnung zu Beginn des Projektes. Hierbei werden alle Aufwendungen für geplante und ungeplante Leistungen erhoben und die Abweichungen zum ursprünglichen Plan dargestellt. Der Fokus kann auf der Rendite, dem erreichten Rationalisierungseffekt oder der Produktivitätssteigerung liegen. Allerdings gelingt der Vergleich nur, wenn zu Beginn des Projektes die Sollwerte festgelegt und dann die entsprechenden Ist-Daten fortwährend erhoben werden. [GPM17b]

Unterstützung für die Nachkalkulation und Analyse der Wirtschaftlichkeit leisten dabei folgende Fragen [KERT03]

• Was hat das Projekt tatsächlich gekostet?
• Wie viele Mitarbeiter waren tatsächlich beschäftigt?
• Wie lange hat es tatsächlich gedauert?
• Wann haben die Mitarbeiter tatsächlich angefangen und wann haben sie aufgehört oder das Projekt verlassen?
• Wie viel Arbeit hat das Team tatsächlich geleistet?
• Welchen Qualitätsgrad hat das Projekt tatsächlich erreicht?
• Wie verhalten sich Kosten und Termineinschätzung im Verhältnis zu den tatsächlichen Ergebnissen?

Alle aufgedeckten Abweichungen werden in der Abweichungsanalyse  auf ihre Ursachen untersucht. Bewährt hat sich die Aufteilung der Ursachen in technische, organisatorische und personelle (TOP), sowie in vermeidbare, kaum vermeidbare und unvermeidbare Ursachen. [BEA11b]

 

	Ursachen
	Technisch	Organisatorisch	Personell
Vermeidbare Ursachen	Infrastruktur nicht rechtzeitig verfügbar	Kompetenzstreitigkeiten	Mangelnde Qualifikation
Kaum vermeidbare Ursachen	Fehlende Testfälle	Konkurrenz durch andere Projekte	Fluktuation
Unvermeidbare Ursachen	Brand in einem Gebäudeteil	Wechsel in der Firmenleitung	Unfall

Tabelle 49 – Ursachen für Abweichungen (Beispiel)

Alle Ergebnisse werden im Analysebericht zusammengefasst.

 

Erfahrungssicherung

In der Phase Erfahrungssicherung  sollten Erfahrungen systematisch gesammelt, dokumentiert, aufbereitet und für kommende Projekte nutzbar gemacht werden. Dazu gehören auch die während der Analyse erhobenen Kennzahlen und die im Laufe des Projektes erstellten Dokumente, die es in geeigneter Form zu archivieren gilt. Diese gesammelten Erfahrungen, auch Lessons Learned bzw. Retrospektiven, sind die Grundlage für die Vermeidung von Fehlern in zukünftigen Projekten. Die Ergebnisse werden im Erfahrungsbericht dargestellt.

Folgende Fragen können für die Erhebung der Projekterfahrungen hilfreich sein [PATZ17]

• Was hat jeder Teilnehmer für sich aus dem Projekt gelernt?
• Welche Ergebnisse sind für die Gesamtorganisation wichtig?
• Welche positiven Erfahrungen können bei anderen Projekten angewendet werden?
• Was soll bei zukünftigen Projekten anders gemacht werden?

Damit die Erfahrungssicherung erfolgreich und effektiv sein kann, muss eine sichere Basis im Sinne von Vertrauen existieren. Nur in einer solchen Atmosphäre werden die Projektbeteiligten über ihre Arbeit diskutieren können und über möglicherweise bessere Vorgehensweisen diese zu erledigen. Diese Vertrauenskultur sollte der Projektleiter schon während des Projektes schaffen und leben. Voraussetzung dafür wäre eine konstruktive Fehler- und Lernkultur im Unternehmen, bei der Fehler zum Lernen gehören und nicht zum Karriereende bzw. zu Sanktionen führen.

Prozess des Lessons Learnd

Abbildung 74 - Prozess Lessons Learned

Das Lernen aus der Projekterfahrung kommt, wie bereits erwähnt, ausschließlich zukünftigen Projekten zugute. Es ist daher aus Sicht des Unternehmens eine wichtige Ressource für die Weiterentwicklung des unternehmensweiten Projektmanagements und Input für organisationales Lernen. [BEA11b]

Projektauflösung

Letzter Schritt der Abschlussphase und damit im gesamten Projektablauf ist die Projektauflösung. Aktivitäten der Projektauflösung sind [GPM17b]

• Abschlussbericht erstellen und dem Auftraggeber sowie den Mitgliedern der eingerichteten Projektgremien (z.B. Lenkungsausschuss, Fach- und Arbeitskreise) zur Verfügung stellen
• Abschlusssitzung(en) mit den eingerichteten Projektgremien und Vorstellung der Projektergebnisse inkl. Abschlussanalyse
• Projektpersonal zu neuen Aufgaben transferieren
• Projektressourcen auflösen bzw. verwerten
• ggfls. das Projekt aus dem Projektportfolio herausnehmen lassen

Der Projektabschlussbericht integriert den Produktabnahmebericht, den Analysebericht und den Erfahrungsbericht sowie die Ergebnisse der letzten Phase des Projektabschlusses.

Nachhaltiges Projektmanagement

4.3.3 Compliance, Standards und Regularien / Bloom’sche Taxonomie 1 – Wissen

Nachhaltiges Projektmanagement im Sinne von Wissensmanagement  ist ein Teil des ICB-Elements Compliance, Standards und Regularien (siehe dazu Kapitel 1.6 Normen im Projektmanagement).

Neues Wissen lässt sich in Projekten aus Lessons Learned Workshops und Retrospektiven gewinnen (siehe Kapitel 7.6.4 Teamlernen). Allerdings wird hierbei häufig fälschlicherweise angenommen, dass das Einholen der gemachten Erfahrung am Projektende bereits Wissensmanagement darstellt. Diesen so erhobenen Informationen fehlt der Kontext. Sie sind einfach teilbar, werden aber nicht immer richtig verstanden bzw. fehlinterpretiert. Erst im Gespräch und durch Interaktion zwischen Projektteammitgliedern und anderen Stakeholdern werden diese zu nutzbarem Wissen mit dem in künftigen Projekten Fehler vermieden werden können. [PMI17a]

Wissensmanagement ist somit der Ansatz einer Organisation, (negative) Erfahrungen so zu formulieren und darzustellen, dass daraus neues (Handlungs-)wissen entsteht, um deren Weiterentwicklung zu fördern und damit zukünftige Risiken zu mindern. [CARB18]

Phasenübergreifende Kompetenzen

Abbildung 75 – ICB-Elemente in den phasenübergreifenden Kompetenzen

Die Phasenübergreifenden Kompetenzen gehören mehrheitlich in den Kompetenzbereich People. Dieser beschreibt die persönlichen und sozialen Kompetenzen, die im Projekt benötigt werden, um den Projekterfolg realisieren zu können. Die persönlichen Kompetenzen beginnen mit den Fähigkeiten zur Selbstreflexion und enden mit der Ergebnisorientierung. Ergänzt wird dieses Kapitel um das Kompetenzelement Change und Transformation, da im Veränderungsmanagement nach Meinung des Autors sehr viel phasenübergreifende Kompetenzen zum Tragen kommen. 

Teamarbeit

Teamarbeit (4.4.6) „Bei der Kompetenz Teamarbeit geht es darum, Menschen zusammenzubringen, um ein gemeinsames Ziel zu erreichen. … Projektteams sind meist interdisziplinär. … Bei der Teamarbeit geht es darum, ein produktives Team aufzubauen, in dem es geformt, unterstützt und geführt wird. Kommunikation und die Beziehungen im Team zählen zu den wichtigsten Aspekten der Teamarbeit.“ [GPM17a, Seite 85]

Teambegriff

4.4.6 Teamarbeit / Bloom’sche Taxonomie 2 – Verstehen

Ein Team ist eine Arbeitsgruppe von Individuen, die zusammen ein bestimmtes Produkt herstellen oder einen bestimmten Service anbieten und die sich für die Qualität dieser Leistung gegenseitig Rechenschaft ablegen. Mitglieder eines Teams haben geteilte Ziele, für deren Erreichung sie gemeinsam verantwortlich sind. Sie sind wechselseitig von der Leistung der anderen Teammitglieder abhängig und beeinflussen ihre Ergebnisse durch Interaktion. [DICK13]

Daraus lässt sich schlussfolgern, dass erfolgreiches Projektmanagement nicht nur von der Methodenkenntnis und den Führungsvoraussetzungen des Projektleiters abhängig ist, sondern in hohem Maße davon, wie die Projektmitarbeiter als Team agieren, wie sie sich als Projektteam verstehen und zur Erreichung des Projektziels Verantwortung für eine oder mehrere Aufgaben übernehmen. [DIN16b]

Ein Projektteam lässt sich somit charakterisieren als

• eine bestimmte Anzahl an Personen
• die als Gruppe
• über die Projektlaufzeit
• miteinander die gemeinsamen Projektziele verfolgen
• miteinander kommunizieren und interagieren
• gruppenspezifische Rollen, Normen und Werte bilden
• und darüber ein „Wir-Gefühl“ entwickeln

Mit dem „Wir-Gefühl“ entwickelt sich ein ausgeprägter Gemeinschaftsgeist und ein starkes Zusammengehörigkeitsgefühl (Gruppenkohäsion). [BERG16]

Teamregeln

Dass diese Form der Zusammenarbeit nicht immer reibungslos abläuft dürfte klar sein, schließlich arbeiten Menschen miteinander. Mit ein paar Teamregeln, hier beispielhaft aufgeführt, lässt sich diese Zusammenarbeit verbessern:

• ü  Klare, gemeinsame Zielsetzung
• ü  Eindeutige Rollen- und Aufgabenverteilung
• ü  Wertschätzender, konstruktiver Umgang mit Konflikten
• ü  Offene Kommunikation und Feedback
• ü  Informationen stehen allen im Team zur Verfügung ( Transparenz)
• ü  Verantwortung für seine Aufgabe übernehmen ( Verlässlichkeit)
• ü  Loyalität gegenüber den Team und dem Projekt
• ü  Toleranz, Respekt, Ehrlichkeit
• ü  Erfolge gemeinsam feiern

 

Teamrollen nach Belbin

Raymond Meredith Belbin untersuchte bereits in den 1970er Jahren unter Einsatz von Unternehmensplanspielen die Leistung von unterschiedlich zusammengesetzten Teams. Nach Auswertung einer Vielzahl solcher Experimente ergaben sich für Belbin neun Rollen. Sein Rollenbegriff umfasst die Art des Sozialverhaltens und den Beitrag zur Aufgabenbewältigung, wobei jedes Teammitglied mehrere Rollen wahrnehmen kann. [BELB10, BANK17]

Bei diesen Rollen lassen sich drei Hauptorientierungen unterscheiden

• 3 handlungsorientierte Rollen:
  Macher (Shaper), Umsetzer (Implementer), Perfektionist (Completer Finisher)
• 3 kommunikationsorientierte Rollen:
  Koordinator (Co-ordinator), Teamarbeiter (Teamworker), Wegbereiter (Ressource Investigator)
• 3 wissensorientierte Rollen:
  Neuerer (Plant), Beobachter (Monitor Evaluator), Spezialist (Specialist)

Jede Teamrolle beinhaltet positive Eigenschaften (Teamrollenbeitrag) und „erlaubte“ Schwächen und trägt auf ihre Weise zu einer produktiven Gruppenarbeit bei. [BELB18]

Tabelle 63 – Teamrollen nach Belbin

Anmerkung:

Die Teamrollen nach Belbin eignen sich in der Praxis hervorragend als Übersicht und zur Orientierung für die Planung von Arbeitspaketen und Aufgaben. Dabei sollte beachtet werden: wissenschaftliche Untersuchungen belegen, dass nur selten eine einzelne Person alle Aufgaben einer Rolle übernimmt. Vielmehr handelt es sich um Aufgabenspektren, die im Team auf mehrere Personen verteilt werden. Unterschiedliche Talente, Fähigkeiten und Eigenschaften sollten projektbezogen möglichst optimal kombiniert werden. [BORN15, BECK16]

Teamentwicklung

4.4.6 Teamarbeit / Bloom’sche Taxonomie 2 – Verstehen

Formal wird das Projektteam durch die Benennung der Mitglieder gebildet. Um jedoch die bei Jedem vorhandene Leistung freizusetzen, müssen sich die interpersonellen Beziehungen der Teammitglieder entwickeln. Nach Bruce Tuckman durchlaufen Teams dabei vier typische Entwicklungsphasen bis zur optimalen Zusammenarbeit und somit zur bestmöglichen Leistung – forming, storming, norming, performing. In der fünften Phase – adjourning – findet die Auflösung des Teams statt. [DICK13]

Eine Beschreibung der einzelnen Teamphasen enthält die folgende Tabelle.

 

 

 

Tabelle 64 – Teamphasen und Rolle des Projektleiters

Die beschriebenen Findungs- und Klärungsprozesse lassen sich durch gezielte fördernde Maßnahmen beschleunigen, damit ein Team schnell in die produktive Performing-Phase kommt.

In der Praxis sind die Phasen der Teamuhr nicht immer klar voneinander zu trennen. Es werden allerdings alle Phasen von einem Team durchlaufen, sie können sich jedoch überlappen oder von unterschiedlicher Dauer sein. Ein Ausfall einzelner Phasen führt später zu Leistungseinbußen. Der Projektleiter sollte diese Phasen aktiv in seiner Rolle gestalten und die Teamfindung, speziell während der Forming-Phase, nicht dem Zufall überlassen. [BERG16]

Spezielle Teameffekte

Ein starkes „Wir-Gefühl“ hat nicht nur positive Effekte. Problematisch wird es, wenn diese hohe Kohäsion eine Eigendynamik entwickelt. Dabei lassen sich vier Phänomene beobachten – Groupthink, Groupshift bzw. Risk shifting, Social Loafing und das Abilene-Pardox. [DÖRN11, BERG16]

 

	Voraussetzung	Symptome
Group-think	starkes Zusammengehörigkeitsgefühl, Isolation des Teams durch ein Überlegenheitsgefühl gegenüber Außenstehenden (z.B. gebündeltes Expertenwissen), Stress und Zeitdruck (z.B. in einer kritischen Situation), charismatischer, richtungsweisender Leiter	Stereotypisierung (Schwarz-Weiß-Denken) Selbstzensur (dem Teamkonsens wird nicht widersprochen) Filtern von Informationen durch sog. „Meinungswächter“ im Team Alternativen werden, speziell wenn sie von außen an das Team herangetragen werden, nicht oder nur oberflächlich geprüft
Groupshift bzw. Risk shifting	siehe Groupthink	Verantwortung wird auf die Teammitglieder verteilt (nicht der, der die Entscheidung trifft ist für die Folgen verantwortlich sondern das Team als Ganzes) Risiken werden in Kauf genommen und individuelle Sanktionen bei Fehlentscheidungen nicht befürchtet
Social Loafing	je größer die Gruppe, desto weniger wird die individuelle Leistung wahrgenommen Aufgabe nicht anspruchsvoll	Annahme, dass die eigene Leistung mehr zum Gruppenoutput beiträgt als die Leistung der anderen sinkende Motivation und damit sinkender persönlicher Einsatz im Team
Abilene-Paradox[10]	Versagen der Teamkommunikation Jedes Teammitglied glaubt irrtümlicherweise, seine eigene Einstellung würde denen der anderen Personen widersprechen	Verwandt mit Groupthink Gruppenmitglieder stellen sich oft nur ungerne gegen die Meinung der Gruppe Es werden deshalb keine Einwände vorgebracht

Tabelle 65 – Teameffekte – Groupthink, Groupshift, Social Loafing, Abilene Paradox

Beispiele bzw. Ergebnisse für diese Phänomene sind

• Explosion des Space Shuttles Challenger 1986
   arbeiten unter Druck, ignorieren wichtiger Informationen und Hinweise (Dichtungsringe an den Feststoffraketen werden bei < 12°C porös, am Starttag zeigte das Thermometer 3°C) [BERG16]
• Reaktorkatastrophe von Tschernobyl 1986
   arbeiten unter Druck, hochprofessionelles, offiziell ausgezeichnetes Team, ignorieren von Warnhinweisen und Sicherheitsbestimmungen  [DÖRN11]
• Brand der Ölplattform Deepwater Horizon 2010
   arbeiten unter (Kosten-) Druck, ignorieren geltender Standards, ignorieren von Expertenmeinungen außerhalb des Unternehmens[11]

•  

Teamlernen

4.4.6 Teamarbeit / Bloom’sche Taxonomie 2 – Verstehen

Die Arbeit in Teams bildet fraglos die Grundlage für die Umsetzung eines Projekts. Durch die Vernetzung unterschiedlichen Wissens und unterschiedlicher Qualifikationen sollen Teams leichter, schneller und kreativer Lösungen erarbeiten als der Einzelne. Oder wie es bereits Aristoteles ausdrückte „Das Ganze ist mehr als die Summe seiner Teile“. Durch die Möglichkeit, im Team von- und miteinander zu lernen, können Fehler schneller erkannt und Synergien einfacher realisiert werden. [OELS09]

Eine gängige Möglichkeit des Teamlernens und des Wissensmanagements ist ein Lessons Learned  Workshop. Er sieht vor, positive wie negative Erfahrungen zu sammeln, diese zu einem bestimmten Zeitpunkt aufzuarbeiten und mit den daraus gewonnenen Erkenntnissen Verbesserungen für die weitere (Zusammen-)Arbeit umzusetzen. [BANN14]

 

 

 

Konflikte und Krisen

Konflikte und Krisen (4.4.7) „Zur Kompetenz Konflikte und Krisen gehört das Abmildern oder Lösen von Konflikten und Krisen durch hohe Aufmerksamkeit für das Umfeld und die Fähigkeit, Abhilfe für Meinungsverschiedenheiten zu erkennen und anzubieten. Konflikte und Krisen können Ereignisse und Situationen einschließen, charakterliche Konflikte, Stresslevels und andere potenzielle Gefahren.“ [GPM17a, Seite 89]

Definition

4.4.7 Konflikte und Krisen / Bloom’sche Taxonomie 1- Kennen

Konflikt

Ein Konflikt besteht, wenn sich mindestens eine Person durch das Handeln einer anderen Person oder Institution in ihren Bedürfnissen verletzt fühlt oder die Verletzung ihrer Bedürfnisse befürchtet. [GPM17b, SCHI14]

Krise

Das Wort Krise stammt aus dem Griechischen und bedeutet wörtlich übersetzt „schwierige Lage“. Krisen können ganz unterschiedliche Dimensionen haben. Sie können eine einzelne Person betreffen oder eine Gruppe, wie zum Beispiel ein Projektteam. Eine Krise im klassischen Sinn bezeichnet eine über einen gewissen (längeren) Zeitraum anhaltende massive Störung des gesellschaftlichen, politischen oder wirtschaftlichen Systems. [BPB11]

Bezogen auf ein Projekt stellen Krisen eine besondere Form des Konflikts dar und sind nichts anderes als eine extreme Projektsituation bei der sich Beteiligte und/ oder Betroffene in einem Gefühl der Ausweglosigkeit befinden, weil Krisen

• eine gravierende Abweichung vom Plan bewirken und
• als existenzbedrohend für das Projekt sowie die Projektorganisation angesehen werden.

Krisen haben immer zwei Aspekte:

• einen sachlichen Aspekt (der Projekterfolg ist objektiv gefährdet oder bereits realistisch nicht mehr zu erreichen) und
• einen menschlich-persönlichen Aspekt (Druck, Stress, Angst, Unsicherheit, empfundene Ausweglosigkeit bei den handelnden Personen) [MOTZ17]

Allerdings stecken in Krisen auch Chancen auf Verbesserungen.

 

 

 

Konfliktursachen

4.4.7 Konflikte und Krisen / Bloom’sche Taxonomie 2- Verstehen

Konflikte in Projekten sind „gelebter Alltag“, sie sind Teil menschlicher Zusammenarbeit. Meist entstehen sie dadurch, dass unterschiedliche Erwartungen aufeinander treffen. In den meisten Fällen befürchten die Konfliktbeteiligten, Nachteile in Kauf nehmen zu müssen. Diese befürchteten Nachteile können in verschiedenen Bereichen ursächlich für Konflikte sein. In der folgenden Abbildung sind die möglichen Ursachen und ihre Wechselwirkungen aufgezeigt. [GUGE10]

 

Abbildung 91 – Konfliktursachen

 

Als Projektleiter ist es nicht einfach, Konflikte zu erkennen, da sie meist nicht offen ausgetragen werden. Mit einer Ausnahme – wir sind ein Teil des Konfliktes. Wir stellen üblicherweise die Auswirkungen  (sinkende Arbeitsleistung, Informationen werden nicht weitergegeben) bzw. die Symptome (Rückzug auf formale Kommunikation, Überziehen von Pausenzeiten, Cliquenbildung) fest. Wenn die emotionale Ebene (Beziehungsebene) stimmt, lassen sich die meisten Konflikte auf der Sachebene (Ziele, Wege, Ressourcen) lösen. Schwierig wird es, wenn persönliche Rollen- oder Beziehungskonflikte die anderen Konfliktursachen überdecken bzw. negativ beeinflussen und dadurch möglicherweise zu einer Gefahr für den Projekterfolg werden. [GPM17b]

 

 

Konflikte müssen nicht zwingend einen destruktiven Charakter haben, sie können auch durchaus positiv wirken. Sie sind Indikator für notwendige Veränderungen, können Chancen aufdecken, bereinigen unangenehme Situationen und ermöglichen gemeinsame Lösungen.

 

Konflikteskalation

4.4.7 Konflikte und Krisen / Bloom’sche Taxonomie 3- Anwenden (Level C)

Erfolgt bei destruktiven Konflikten keine Lösung, verursachen sie sinkende Produktivität, hohe Kosten und möglicherweise krankheitsbedingte Ausfälle von Mitarbeitern. Konflikte durchlaufen eine Art Evolution. Je weiter diese fortschreitet, desto unmöglicher wird ihre Lösung. In Anlehnung an das 9-Stufen-Modell des Konfliktforschers Friedrich Glasl, lässt sich diese Konflikteskalation anschaulich beschreiben. [GLAS17]

Abbildung 92 – Konflikteskalation nach Glasl

Wie der Abbildung zu entnehmen ist, lässt sich das Modell in drei Ebenen gliedern. In der ersten Ebene können beide Konfliktparteien noch gewinnen (Win-Win-Situation), in der zweiten gewinnt nur noch eine Partei (Win-Lose-Situation) und in der dritten verlieren letztendlich beide (Lose-Lose-Situation). Die einzelnen Stufen stellen sich folgendermaßen dar: [GLAS17, KREY05]

Win-Win

1.     Spannung/ Verhärtung

Konflikte beginnen mit Meinungsverschiedenheiten und sich verhärtenden Standpunkten. Bei beiden Parteien besteht die Auffassung, dass die Situation durch Gespräche entspannt werden kann.

2.     Debatten

Beide Parteien überlegen sich Strategien, um den jeweils Anderen mit Argumenten zu überzeugen. Es findet allerdings eine Polarisation auf der emotionalen Ebene statt. Streit ist möglich. Dennoch besteht bei beiden Parteien die Auffassung, das Problem mittels Kommunikation lösen zu können.

3.     Aktionen

Die Konfliktparteien erhöhen den Druck aufeinander, um ihre Meinung bzw. ihre Anforderung durchzusetzen. Gespräche werden abgebrochen, die Überzeugung, dass Reden nicht mehr ausreicht, gewinnt allmählich die Oberhand. Die bis zu diesem Zeitpunkt eventuell noch vorhandene Empathie mit der Gegenseite löst sich auf. Die Gefahr von Fehlinterpretationen wächst. Der Konflikt verschärft sich, eine dritte, neutrale Person zur Konfliktlösung kann hier bereits sinnvoll sein.

 

Win-Lose

4.     Koalition

Aufbau von Feindbildern, die im Wesentlichen aus Klischees bestehen. Es werden Sympathisanten gesucht und als mögliche Koalitionspartner hofiert. Die Sachebene wird aus den Augen verloren, Ziel ist es jetzt, den Konflikt zu gewinnen.

5.     Gesichtsverlust

Auf dieser Stufe kommt es zu direkten und in den meisten Fällen öffentlich ausgeführten Angriffen auf die andere Konfliktpartei. Der Vertrauensverlust auf beiden Seiten ist vollständig. Es kommt zum Gesichtsverlust im Sinne des Verlustes der moralischen Glaubwürdigkeit.

6.     Drohstrategie

Die Eskalation wird durch beiderseitige Drohungen und das Setzen von Ultimaten weiter beschleunigt. Die Macht der Beteiligten manifestiert sich in der Höhe der angedrohten Sanktionen und dem darin enthaltenen Schädigungspotenzial für den jeweiligen Gegner. Die Mittel (Drohung und Ultimatum) stellen den Versuch dar, die Eskalation zu kontrollieren.

Lose-Lose

7.     Begrenzte Vernichtung

Der Gegner wird nicht mehr als Mensch wahrgenommen. So lange der Gegner getroffen wird, werden bei begrenzten Vernichtungsschlägen auch eigene Verluste als Gewinn angesehen.

8.     Zersplitterung

Jedes Mittel, das der Zerstörung und Auflösung des Gegners dient, erscheint den Konfliktparteien als legitim.

9.     Totale (Selbst-)Vernichtung

Die Chance eines „Last Exit“ wurde vertan, es gibt keinen Weg zurück. Es geht nur noch darum, bei der Vernichtung des Gegners den eigenen Schaden so gering wie möglich zu halten.

 

Bei einem eskalierten Konflikt haben die Konfliktparteien keinerlei Möglichkeit mehr, die negativen Vorzeichen ihrer Werturteile und Emotionen zu kontrollieren und zu beeinflussen. Daraus folgt, dass zur Prävention von Konflikten und bei der Deeskalation von Konflikten die Beziehungsebene positiv zu gestalten ist. Insbesondere durch kooperatives Verhalten werden wechselseitig positive Werturteile und Emotionen gefördert.

Handlungsstrategien im Konfliktfall

4.4.7 Konflikte und Krisen / Bloom’sche Taxonomie 3- Anwenden (Level C)

Für Konfliktsituationen kann das TKI, das Thomas-Kilmann Conflict Mode Instrument herangezogen werden. In solchen Situationen wird das Verhalten einer Person anhand zweier grundlegender Dimensionen beschrieben – Durchsetzungsfähigkeit (meine Interessen) und Zusammenarbeit (die Interessen der Anderen). Diesen grundsätzlichen Verhaltensweisen können fünf Konfliktbewältigungsmodalitäten zugeordnet werden: [KILM75, GPM17b]

 

• 1)    Vermeiden bzw. verdrängen einer Auseinandersetzung,
• 2)    Nachgeben gegenüber dem Gegner,
• 3)    Durchsetzen der eigenen Ziele,
• 4)    Erarbeiten einer gemeinsamen Lösung (win-win),
• 5)    Entwickeln eines Kompromisses.

Abbildung 93 – Übersicht Konfliktstile (TKI)

Die folgende Tabelle zeigt eine Übersicht der Konfliktstile, der dahinterstehenden persönlichen Haltung und einiger Vor- bzw. Nachteile. [KREY05]

 

Konfliktstil	Haltung	Vor- bzw. Nachteil
vermeiden/ fliehen	„Nichts wie weg“	Q verschärfter Folgekonflikt
nachgeben/ unterwerfen	Aufgabe der eigenen Bedürfnisse	R unbedeutender Konfliktgegenstand R zur Schadensbegrenzung Q führt zu Folgekonflikten
durchsetzen/ konkurrieren	„Sieg oder Niederlage“	R zum Durchbrechen von Stillstand R für schnelle Entscheidungen Q Eskalationsgefahr
Kompromiss/ feilschen	„Jedem begegnete man zweimal“	R vorläufige Lösung für Nachverhandlung R gut für Zwischenlösungen unter Zeitdruck Q „Faule“ Kompromisse Q Kein positiver Start für langfristig tragfähige Beziehungen
gemeinsame Lösung/ integrieren	„Sich auseinander setzen, um sich zusammenzusetzen“	R Engagement und Mitverantwortung bei den Beteiligten R langfristige nachhaltige Lösung Q Lösungsfindung dauert lange

Tabelle 66 – Konfliktverhaltensweisen

 

Die Wahl des Konfliktstiles ist auch davon abhängig, mit wem der Konflikt besteht – mit dem Vorgesetzten, mit unterstellten Mitarbeitern oder mit hierarchisch gleichgestellten Kollegen.

Kooperative Konfliktlösung als Handlungsstrategie

4.4.7 Konflikte und Krisen / Bloom’sche Taxonomie 2- Verstehen (Level C)

Eine kooperative Konfliktlösung ist eine Mediation, bei dem eine neutrale dritte Person, der Mediator, die Parteien bei der Beilegung eines Konfliktes unterstützt. Der Mediator ist zwar unparteiisch, aber nicht unbeteiligt. Er strukturiert das Gespräch zwischen den Konfliktpartnern, hilft durch gezielte Fragen, die zugrunde liegenden Interessen zu erkennen, klärt Missverständnisse auf und unterstützt die Konfliktpartner dabei, gemeinsam Lösungen zu finden. [KREY05]

Abbildung 94 – Phasen kooperativer Konfliktlösung

Vorgehensweise:

Mediation eröffnen
Information über Konflikt, Motivation der Beteiligten zu einer Lösung, Erläuterung der Vorgehensweise und Regeln der Moderation

Informationen sammeln
unterschiedliche Sichtweisen werden gesammelt, Positionen werden dargestellt

Bedürfnisse klären
Befürchtungen werden geäußert, Bedürfnisse aufgedeckt, der Konflikt wird in sachliche und soziale Komponenten zerlegt, eine gemeinsame Beschreibung des Ist-Zustands wird von den Beteiligten erarbeitet

Lösungen vereinbaren
alternative Zielzustände werden erarbeitet, Handlungsspielräume dargestellt, ein für alle akzeptabler Zielzustand (Soll-Zustand) wird beschrieben

Erfolg sichern
Konsequenzen für die Beteiligten werden aufgezeigt, verbindliche Verhaltensregeln werden aufgestellt, wer macht was bis wann wird festgelegt, Ergebnis wird rechtssicher formuliert (vollständig, verständlich, zielgerichtet)

---