Projektmanagement Im Einkauf

Kerstin Hillberg
Projektmanagement
im Einkauf
Praxisleitfaden mit Checklisten
und Beispielen
2. Auflage
Projektmanagement im Einkauf
Kerstin Hillberg
Projektmanagement
im Einkauf
Praxisleitfaden mit Checklisten
und Beispielen
2., aktualisierte und erweiterte Auflage
Kerstin Hillberg
Berlin, Deutschland
ISBN 978-3-658-31309-8 ISBN 978-3-658-31310-4 (eBook)

https://doi.org/10.1007/978-3-658-31310-4
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen National

bibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2017, 2020
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die
nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung
des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen,
Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen
etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die
Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des
Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten.
Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informa
tionen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind.
Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder
implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt
im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten
und Institutionsadressen neutral.
Springer Gabler ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH
und ist ein Teil von Springer Nature.
Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany
Inhaltsverzeichnis 5
Inhaltsverzeichnis
1 Warum dieses Buch? .............................................................................................. 11
2 Projektmanagement – Was ist das eigentlich?................................................... 13
3 Entwicklung der Anforderungen im Einkauf und die Notwendigkeit

von Projektmanagement........................................................................................ 23
3.1 Die Rolle des Einkaufs im Unternehmen .................................................... 23

3.2 Aktuelle Anforderungen an die Rolle des Einkäufers ............................... 26
4 Voraussetzungen für Projektarbeit im Einkauf ................................................ 29
4.1 Wodurch werden Projekte gekennzeichnet, oder wann machen

Projekte Sinn?.................................................................................................. 31
4.2 Phasen im Projektlebenszyklus .................................................................... 32
4.3 Standardisierung in den Phasen ................................................................... 35
5 „8 Schritte“ im Projektmanagement.................................................................... 41
5.1 Projektantrag ................................................................................................... 44

5.2 Mind-Map ....................................................................................................... 49
5.3 Zielplanung ..................................................................................................... 51
5.3.1 Wie wird das Projektziel beschrieben?............................................ 55
5.3.2 SMART-Regel ..................................................................................... 56
5.3.3 Definition, Begriffserklärung und SMART-Beispiel..................... 57
5.3.4 Meilensteine........................................................................................ 58
5.3.5 Meilensteintrendanalyse ................................................................... 60
5.4 Der Projektstrukturplan (PSP) ...................................................................... 61
5.4.1 Funktionsorientierte Gliederung ..................................................... 63
5.4.2 Objektorientierte Gliederung ........................................................... 64
5.4.3 Phasenorientierte Gliederung .......................................................... 65
5.4.4 Arbeitspaket ....................................................................................... 68
5.5 Terminplanung ............................................................................................... 69
5.5.1 Analoge Abschätzung ....................................................................... 70
5.5.2 Bottom-up-Schätzung........................................................................ 71
5.5.3 Activity Sequencing oder das Festlegen von Arbeitsfolgen ......... 72
6 Inhaltsverzeichnis
5.5.4 Terminplan als Beispiel-Berechnung von zehn

Arbeitspaketen mit progressiver und retrograder
Kalkulation ......................................................................................... 73
5.5.5 Gantt-Diagramm ................................................................................ 74
5.5.6 Netzplan oder PERT .......................................................................... 76
5.5.7 Rahmenbedingungen beachten ........................................................ 77
5.6 Kostenplanung................................................................................................ 79
5.7 Projektorganisation ........................................................................................ 81
5.7.1 Wann und wie werden die Themen umgesetzt? ........................... 84
5.7.2 Das Team und die Rollen im Projekt ............................................... 85
5.7.3 RACI (Verantwortlichkeits-)-Matrix ............................................... 89
5.7.4 Stakeholderanalyse ............................................................................ 90
5.8 Risikomanagement ......................................................................................... 92
5.8.1 Quantifizierung benannter Risiken ................................................. 95
5.8.2 Möglichkeiten, auf Risiken zu reagieren ........................................ 97
5.9 Beispiel eines Musterprojektes ..................................................................... 98
5.9.1 Projektantrag ...................................................................................... 99
5.9.2 Projektbeispiel Mind-Map .............................................................. 101
5.9.3 Projektbeispiel Zielplanung............................................................ 101
5.9.4 Projektbeispiel Projektstrukturplan............................................... 103
5.9.5 Projektbeispiel Terminplan............................................................. 105
5.9.6 Musterprojekt Kostenplan .............................................................. 107
5.9.7 Musterprojekt Projektorganisation und Stakeholderanalyse ..... 107
5.9.8 Risikomanagement .......................................................................... 110
6 Globalisierung … ................................................................................................. 113
6.1 Historie und Entwicklung Globalisierung ................................................ 115

6.2 Herausforderung von Projekten im internationalen Umfeld ................. 117
6.3 Die Rolle des Einkäufers im globalen Umfeld .......................................... 120
6.4 Werkzeuge und Methoden zur Vorbereitung einer internationalen
Einkaufsstrategie .......................................................................................... 122
6.5 Analyse der Kennzahlen ............................................................................. 125
6.5.1 Pareto-Analyse ................................................................................. 126
6.5.2 Die Ausgaben-Matrix ...................................................................... 127
6.5.3 Total Cost of Ownership und die Projekte im Einkauf ............... 129
6.5.4 Die Kraljic-Matrix als Unterstützung zur Lokalisierung ............ 133
6.5.5 Beschaffungsanalyse........................................................................ 135
7 Risiken der Globalisierung und durch die Corona-Krise ............................. 137
7.1 Die andere Seite der Medaille ..................................................................... 137

7.2 Digitalisierung im eigenen Bereich ............................................................ 137
8 Die Analyse des globalen Marktes .................................................................... 139
9 Kulturelle Herausforderungen im globalen Umfeld ..................................... 143
9.1 Was betrachten wir als Kultur? .................................................................. 144

9.1.1 Die Brille, mit der wir Kultur betrachten ...................................... 146
9.1.2 Was sind Handlungskompetenzen? .............................................. 147
9.2 Methoden zur Analyse des Projektumfeldes ............................................ 149
9.2.1 Die Projektumfeldanalyse ............................................................... 149
9.2.2 Stakeholderanalyse .......................................................................... 150
9.3 Unterschiedliche Modelle kultureller Zusammenhänge......................... 152
9.3.1 Das Modell von Geert Hofstede..................................................... 153
9.4 Konkrete Einflussgrößen auf unsere Arbeitswelt durch kulturelle
Unterschiede ................................................................................................. 156
9.5 Führung und Konfliktmanagement in internationalen Projekten ......... 157
10 Agiles Projektmanagement ................................................................................. 159
10.1 Die Bausteine des agilen Projektmanagements ........................................ 161

10.1.1 Die „agilen Werte“ ........................................................................... 162
10.1.2 Agile Prinzipien ............................................................................... 164
10.1.3 Agile Techniken ............................................................................... 164
10.1.4 Agile Methoden................................................................................ 165
10.1.5 Klassische Methoden versus agile in der Theorie .......................... 166
10.2 Die Methode Scrum ..................................................................................... 167
10.2.1 Der Ablauf von Scrum..................................................................... 168
10.2.2 Die Rollen im Scrum ........................................................................ 169
10.2.3 Produkt Backlog ............................................................................... 171
10.2.4 Planning Poker oder das Abschätzen von Aufwänden .............. 173
10.2.5 Daily Scrum Meeting ....................................................................... 173
10.2.6 Sprint Backlog und Daily Scrum.................................................... 173
10.2.7 Retroperspektive als Ausgangspunkt für die Verbesserung
im Team............................................................................................. 174
10.2.8 Review mit dem Kunden ................................................................ 176
8 Inhaltsverzeichnis
11 Führung in agilen Projekten ............................................................................... 179
11.1 Die Kommunikation im agilen Projektmanagement ............................... 180

11.2 Der Product Owner und die Herausforderung an seine
kommunikativen Fähigkeiten ..................................................................... 181
12 Digitalisierung oder Einkauf 4.0 ........................................................................ 183
12.1 Was versprechen wir uns von Einkauf 4.0? .............................................. 183
12.2 Der operative Einkauf und seine Aufgaben.............................................. 185
12.3 Der strategische Einkauf und seine Aufgaben ......................................... 186
12.4 Die Rolle des Einkäufers im Umfeld 4.0 .................................................... 187
13 Führung im Projekt .............................................................................................. 189
13.1 Was ist Führung? .......................................................................................... 189

13.2 Kick-off als Instrument ................................................................................ 201
13.2.1 Checkliste möglicher Inhalte und Ziele des Kick-offs................. 201
13.2.2 Checkliste zur Vorbereitung eines Kick-offs ................................ 202
13.3 Motivation ..................................................................................................... 203
14 Was macht Teamarbeit erfolgreich? .................................................................. 209
14.1 Der Projektleiter und die menschliche Seite ............................................. 209

14.2 Teamentwicklungsphasen nach Tuckman ................................................ 212
14.3 Die Präsentation und was dazu gehört ..................................................... 216
15 Projektherausforderung im internationalen Umfeld — Why culture

counts ...................................................................................................................... 219
16 Steuerung von Projekten ..................................................................................... 225
16.1 Steuerung des Projektes Kosten- und Terminplan .................................. 228

16.2 Kostensteuerung ........................................................................................... 228
16.3 Meilensteintrend- und Kostentrendanalyse als Werkzeug zur
Früherkennung von Abweichungen .......................................................... 230
17 Kommunikation im Projekt und Austausch von Informationen ................. 235
17.1 Austausch von Informationen .................................................................... 235

17.2 Auswahl der Kommunikationsmethode ................................................... 237

17.3 Besprechung .................................................................................................. 238
17.3.1 Vorbereitung ..................................................................................... 240
17.3.2 Durchführung................................................................................... 240
17.3.3 Nachbereitung .................................................................................. 241
17.4 Das Ding mit der persönlichen Distanzzone! ........................................... 242
17.5 Das Telefon als Medium .............................................................................. 243
17.6 Fragen und Hinterfragen, aber richtig....................................................... 244
17.7 Feedback geben — Feedback nehmen, was heißt das genau? ................ 245
Literatur ........................................................................................................................ 247

Warum dieses Buch? 11
1 Warum dieses Buch?

Zwischen Wunsch und Wirklichkeit liegt die Tat!
Viel wurde bereits über Projektmanagement und Einkauf geschrieben. Warum
nun dieses Buch?
Mit diesem Buch möchte ich nicht nur meinen Seminarteilnehmern, sondern auch
den Lesern ein einfaches Werkzeug an die Hand geben, welches sie unterstützen
soll, die Herausforderungen der Projekte im Einkauf leichter zu meistern – einen
roten Faden und einen „Werkzeugkasten“ für den Alltag. Eine „Toolbox“, auf die
in der Hektik des Alltagsgeschäftes immer wieder zurückgegriffen werden kann.
Aus meiner 30-jährigen Erfahrung im Projektgeschäft, basierend auf den nationa-

len und internationalen Standards des Projektmanagements, sind hier die für
mich wichtigsten acht Schritte beschrieben, ohne die es keine Transparenz gibt
und damit auch keine Führung im Projekt möglich ist. Je nach Projektart und
Umfang können die Schritte in Ausmaß und Tiefe angepasst werden.
In einfacher Reihenfolge geplant und dokumentiert, als Basisplan verankert,

ermöglichen sie es mir, Transparenz, schnelle Kommunikation und damit auch
eine schnelle Reaktionsgeschwindigkeit in meinem Projekt zu erreichen.
Lange war der Einkauf Dienstleister im Unternehmen. Heute nimmt er eine stra-
tegische Rolle ein. Bei immer stärker werdendem Kostendruck und hoher Ge-
schwindigkeit ist das Projektmanagement nicht mehr wegzudenken.
Die Einsparungen im Einkauf liegen schon lange nicht mehr allein in einer gut
geführten Verhandlung. Schlagworte wie Total Cost of Ownership, Supply Chain
Management, Zentralisierung und Einsparungen durch technologische Anpas-
sungen setzen die Integration vieler Schnittstellen und ein sauber aufgesetztes
Prozessmanagement voraus. Die Anforderungen können nur noch bewältigt
werden, wenn ein gutes Projektmanagement implementiert ist.
So ist dieses Buch entstanden mit dem Ziel, Projektmanagern in Einkaufsprojek-

ten Hilfestellung für die tägliche Praxis zu geben. Anregungen, Checklisten und
Beispielprojekte sollen dabei helfen, den Werkzeugkasten für die tägliche Arbeit
zu erweitern.
Die Theorie ist das eine, die Herausforderung im Alltag das andere. Dieses Buch
soll darin unterstützen, die Schnittstelle zwischen beiden ein wenig anschaulicher
zu gestalten, und neue Anregungen und Sichtweisen für den Arbeitsalltag geben.
© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020
K. Hillberg, Projektmanagement im Einkauf,
https://doi.org/10.1007/978-3-658-31310-4_1
Projektmanagement – Was ist das eigentlich? 13
2 Projektmanagement – Was ist

das eigentlich?
In der Theorie ist Projektmanagement eine Methode, mit der Projekte initiiert,
geplant, gesteuert, kontrolliert und abgeschlossen werden.
Aber schauen wir uns die Theorie einmal an, unzählige Bücher und Ausführun-
gen wurden dazu geschrieben. In 30 Minuten kann man sich die Theorie im In-
ternet herunterladen. Kein Problem und schnell zu verstehen: Einen Leistungs-
umfang vereinbaren, Kosten und Termine festlegen. Das ist alles.
Doch dann kommt das Problem, die Theorie in die Praxis umzusetzen. Und ganz
plötzlich entstehen Aufgaben und Herausforderungen, an die man überhaupt
nicht gedacht hat. Viel mehr gehört zum Projektmanagement als eigentlich ange-
dacht. Fangen wir doch einmal mit ein paar einfachen Fragen an.
■ Was ist in meinem Unternehmen ein Projekt?

■ Was wollen wir im Einkauf als Projekt definieren?
■ Wer trifft im Projekt welche Entscheidungen?
■ Wie sind die entsprechenden Rollen mit Aufgaben, Verantwortung und
Entscheiderkompetenz definiert?
So klar beschrieben ist dann bereits nach diesen wenigen Fragen doch gar nicht
mehr, was ein Projekt ist. Erst einmal steht überall, ein Projekt hat einen klaren
Anfang und ein klares Ende. Und ist einmalig.
Sofort kommt mir der Gedanke: Wenn ich morgen früh einen Kaffee kochen möch-
te, hat das „Projekt“ auch einen klaren Anfang und ein klares Ende. Es gibt ein
Risiko und auch die Herausforderung, dass der Kaffee dabei noch gut werden soll.
Aber ist das dann auch gleich ein Projekt und wer entscheidet das?
Ein Projekt ist erst einmal nichts anderes als eine große Aufgabe, die in Form
einer Sonderorganisation, der Projektorganisation, strukturiert, geplant und ge-
steuert wird. Mit einem vorgegebenen Termin und Kostenrahmen sowie einer
(hoffentlich) abgestimmten Qualität.
https://doi.org/10.1007/978-3-658-31310-4_2
14 Projektmanagement – Was ist das eigentlich?
Allerdings ist hier Qualität nicht gleichzusetzen mit „schöner“, „größer“ und „bes-
ser“, sondern Termin, Kosten und „vereinbarter Leistungsumfang“ gehören zusammen
– zusammengefasst in dem sogenannten „Magischen Dreieck“ (vgl. Abbildung 4.1).
Projektmanagement ist eine Sonderorganisation, die parallel zur bestehenden

Linie existiert. Das heißt auch, dass die Rollen, die zu dieser Organisation gehö-
ren, klar beschrieben sein müssen. Wann immer ich die Rolle als Projektleiter
übernehme, sind die folgenden Fragen zu beantworten:
■ Für welchen Umfang des Projektes bin ich verantwortlich?

■ Was ist meine Aufgabe?
■ Was darf ich im Rahmen des Projektes entscheiden?
Meinen ersten Job nach dem Studium hatte ich bei einem großen Automobilher-
steller in Süddeutschland. Ich war Sachbearbeiter in der Fertigungsplanung für
die Innenmontage. Die Aufgaben wurden noch in einer reinen Linienorganisation
abgearbeitet. Entscheidungen wurden über die klassischen Hierarchiestufen
getroffen. Die Rollen und Verantwortlichkeiten waren in der Linie klar umrissen
(vgl. Abbildung 2.1).
Abbildung 2.1 Beispiel Hierarchiestufen

Wann immer ich mit der Entwicklung konkrete Abstimmungen hatte, musste ich
die ganze Hierarchiestufe hinauf. Freigaben über meine Führungskräfte waren
die Voraussetzung für die Genehmigungen. Genauso verlief es mit anderen Be-
reichen. Die Firma war ganz klar linienorientiert aufgebaut. Der Produktentste-
hungsprozess von Fahrzeugen war zu diesem Zeitpunkt ca. 2,5-mal so lang wie
heute. Sicherlich haben sich viele Dinge seither geändert. Aber ein Teil, der zur
Zeitersparnis beigetragen hat, war die immer stärker werdende Nutzung der
Sonderorganisation auf Zeit: das Projektmanagement.
Wegbereiter für das Projektmanagement waren militärische Programme und

auch die Raumfahrt. Mitte der 1980er-Jahre kam das Thema Projektmanagement
in Deutschland mehr und mehr an – hiermit dann auch die Notwendigkeit, eine
weitere Organisationsform ins Leben zu rufen. Diese basiert auf den sogenannten
cross-funktionalen Teams. Es wurde nicht mehr gefragt, welche Linienfunktion
zuerst von der Aufgabe betroffen ist, sondern:
Welche Tätigkeit ist als erstes notwendig und wen benötige ich in meinem Team,
um diese Aufgabe abarbeiten zu können?
Projektmanagement ist ein Denken in Prozessen, weg von der eigentlichen Li-
nienstruktur hinzu:
■ Welchen Input benötigen wir?

■ Welches Arbeitspaket mit welchem Mehrwert wird erledigt?
■ Was ist der notwendige Output, um weiterarbeiten zu können?
Abbildung 2.2 Zeitliche Einsparungen im Produktentstehungsprozess durch

cross-funktionale Teams (Quelle: Fortune Magazine, NPI-Sim
Storyboard The Change Works 2003, S. 10)
In Abbildung 2.2 wird dargestellt, wie sich der Produktentstehungsprozess in

Firmen durch die Einführung der cross-funktionalen Teams in einer Projektorga-
nisation verkürzt hat.
Die Fragen stellen sich nunmehr zum Fachprozess bzw. zum definierten Leis-
tungsumfang, den es abzuarbeiten gilt.
Was kommt zuerst, was folgt danach?
Ohne aber die beteiligten Menschen, macht der beste Prozess keinen Sinn. Wir
benötigen klare Rollen und Spielregeln, um diese Prozesse auch zum Leben zu
erwecken – mit den Personen im Team, die sie umsetzen.
Mit dem Aufsetzen des Projektteams wird die Frage gestellt, wen wir benötigen,
um die gestellte Aufgabe bzw. das entsprechende Arbeitspaket in die Praxis
umzusetzen? Wie muss die Organisationsstruktur für das jeweilige Projekt aus-
sehen, damit die Herausforderungen mit schneller Reaktionsgeschwindigkeit
und hoher Anpassung von Abweichungen zum gewünschten Termin und mit
dem entsprechenden Budget umgesetzt werden können?
Durch die zunehmende Vernetzung der Arbeitswelt, Globalisierung und eine

immer höhere Geschwindigkeit steigt auch der Druck auf die Unternehmen und
den Einkauf.
Permanente Veränderungsprozesse über alle Ebenen eines Unternehmens müssen

gesteuert werden. Dies gilt sowohl für Produkte als auch für Dienstleistungen.
Daraus resultieren auch immer kürzere Innovationszyklen. Der steigende Druck im
Einkauf hat bei der Abarbeitung der anstehenden Aufgaben eben nicht nur Einfluss
auf eine Funktion, sondern fordert viele Funktionen quer durch die Organisation.
Bei Einsparungen wird oft die komplette Prozesskette betrachtet (Supply Chain
Management). Damit wird der Einkäufer Schnittstellenmanager oder auch Projekt-
leiter. Ganzheitliches Arbeiten über den eigenen Bereich hinaus ist notwendig.
Um dem Anspruch und den notwendigen Aufgaben im Einkauf gerecht werden

zu können, werden interdisziplinäre Teams benötigt. Nur noch gemeinsam kann
man den anstehenden Aufgaben in der sich schnell verändernden Zeit gerecht
werden. Maßnahmen müssen gemeinsam entwickelt und umgesetzt werden –
mit dem Ziel, gesetzte Aufgaben effektiv erledigen zu können. Dies setzt die
einheitliche Implementierung von Spielregeln für diese Methodik voraus: die
Methode, die wir Projektmanagement nennen (vgl. Abbildung 2.3).
Abbildung 2.3 Beispiel eines cross-funktionalen Teams im Einkauf mit seinen

Kernfunktionen
Das Projektteam ist eine Sonderorganisation auf Zeit. Die Organisationsform hat
über den definierten Projektzeitraum hinaus Gültigkeit.
Einer der entscheidenden Erfolgsfaktoren im Projektmanagement ist die klare

Abgrenzung zur Linienfunktion sowie die damit verbundene Rollenklärung. In
einer Rolle müssen sowohl
■ die Aufgabe, die es zu erledigen gilt,

■ die Verantwortung bzw. der dazugehörige Verantwortungsbereich als auch
■ die Entscheidungskompetenz
definiert und für alle verbindlich dokumentiert werden. Je nach Projekt und
Projektumfang handelt es sich hier um folgende mögliche Rollen:
■ Auftraggeber
■ Projektleiter
■ Teilprojektleiter
■ Teammitglieder
■ Entscheidergremien
■ Linienvorgesetzte
■ Projektassistenz
■ Steuerkreis
■ Pate
■ etc.
Fragen wie „Wer entscheidet wann und was in Hinblick auf das jeweilige Pro-
jekt?“ oder „Wer entscheidet über das Projekt hinaus?“ sind vorab zu klären, um
potenziellen Konflikten frühzeitig aus dem Weg zu gehen. Je mehr Schnittstellen
betroffen sind, umso wichtiger ist ein einheitlich akzeptiertes Vorgehen.
Viele Einkaufsprojekte werden im internationalen Umfeld durchgeführt. Dies

steigert die Komplexität dieser Organisationsform nochmals und fordert den
Projektmanager in seinem Handeln. Im Einkauf sind immer mehr Hersteller oder
Lieferanten nicht mehr in Deutschland angesiedelt, sondern im Ausland lokali-
siert. Damit ändern sich auch die entsprechenden Beschaffungsprozesse. Viele
Aufträge werden durch die damit verbundene Komplexität als Projekt definiert.
Globalisierung fungiert als Komplexitätstreiber und erhöht damit verbunden
auch die Notwendigkeit von Projektmanagement im Einkauf!
Historie und Entwicklung des Projektmanagements
Schon beim Pyramidenbau muss eine Form des Projektmanagements funktioniert

haben – die alten Ägypter hatten hierbei aber sicher einen Vorteil: Die Ressourcen
waren nicht limitiert.
Die Baumeister des alten Ägypten haben Leistungen erbracht, die bis heute unüber-
troffen sind. Das um 2700 vor Christus errichtete Grabmal des Pharao Cheops, die
größte Pyramide des Landes, war für damalige Verhältnisse ungeheure 146 m hoch
und bedeckte mehr als fünf Hektar Fläche. Hier interessiert aber weniger das tech-
nische Können, sondern die Sicht auf das Projektmanagement.
Die Baumeister des Altertums bewegten Zehntausende von Arbeitern dazu, unter
Qualen tonnenschwere Steinquader aufeinander zu schichten. Sie koordinierten
den Einsatz der Arbeiter, sorgten für Baumaterial und dessen Logistik vor Ort.
Über Jahrzehnte schufteten Zehntausende von Steinmetzen, Tagelöhnern und

Versorgungspersonal auf der Baustelle – immer versorgt mit Material. Die Be-
schaffung funktionierte tadellos. Gearbeitet wurde in Gruppen – wahrscheinlich
mehrere hundert Mann pro Team, und zwar im Schichtbetrieb, so dass immer
nur eine begrenzte Zahl von Arbeitern zeitgleich im Einsatz war. Die Baumeister
sollen bereits Buch über Arbeitszeiten, Personaleinsatz und Löhne geführt und
Berichte über Beschaffung, Logistik sowie Zeitpläne erstellt haben. Starb ein Pha-
rao, bevor seine Pyramide, die ihm als Grabmal für die Ewigkeit dienen sollte,
fertig war, wurde ein Krisenmanager eingesetzt. Priester, Architekten und Baulei-
ter bildeten einen Krisenstab, da die Mumie des verstorbenen Pharao binnen
70 Tagen beerdigt sein musste.
Die römischen Legionen hingegen sorgten zur Zeit ihres „Imperium Romanum“
für den Ausbau der Straßen, errichteten Brücken, Häfen und Städte. Ein Großteil
ihrer Projekte diente militärischen Zwecken. Auch das Mittelalter war von Mili-
tärprojekten geprägt. Die Sorgen der Projektverantwortlichen unterschieden sich
zu diesem Zeitpunkt kaum von denen der heutigen Zeit. Auch hier ging es im-
mer um die Übersetzung der Anforderungen des Kunden (vereinbarter Leis-
tungsumfang, Termine, Kosten und Qualität) in ein Produkt. Zwar waren die
Kommunikationsmöglichkeiten in jener Zeit noch weitaus eingeschränkter als
heute, die Fragen aber waren die gleichen:
■ Wie integriere ich Stakeholder?

■ Wie führe ich das Team?
■ Wie führe ich den Fachprozess?
■ Wie wird die Kommunikationsstruktur aufgebaut?
■ Welche Reportingsysteme sind notwendig?
■ Wie führe ich schwierige Personen?
■ Wie werden Abweichungen vom Basisplan gemanagt?
■ Wie gehe ich mit Krisen um?
■ Welche Risiken gilt es zu betrachten?
■ Wer bezahlt bei Planabweichungen?
■ Welche Ressourcen stehen mir zur Verfügung?
Starke Geheimhaltungsvorschriften waren immer wieder in der Geschichte des
Projektmanagements dafür verantwortlich, dass sich nützliche Methoden schwer
oder nur sehr langsam verbreiteten.
Auch die Projektleiter des Mittelalters waren vor klassischen Fehlern des Pro-
jektmanagements nicht gefeit. Eine Fehleinschätzung der Anforderungen beim
Bau des Kölner Doms führte beispielsweise dazu, dass die Baustelle mehrere
Jahrhunderte bestand und erst beendet werden konnte, als ausreichend techni-
sche und finanzielle Mittel zur Verfügung standen.
Zur jüngeren Geschichte des Projektmanagements gehören große Infrastruktur-

projekte, so etwa der Eiffelturm oder die Eisenbahnlinie Nürnberg-Fürth, um nur
zwei größere Projekte aus dem 19. Jahrhundert zu nennen. In dieser Zeit stand
noch die Technik im Vordergrund. Erst viel später wurden die Denkweise und
auch die Herangehensweise an das Thema Projektmanagement erneuert.
Mitte der 1980er-Jahre änderte sich auch in Deutschland, wenn auch erst sehr
langsam, das Herangehen an große und komplexe Aufgaben. Die Methode Pro-
jektmanagement gewann an Bedeutung. Notwendig wurde dies durch die immer
höhere Geschwindigkeit und die voranschreitende Globalisierung. Mit der bishe-
rigen Linienorganisation konnte man weder der Geschwindigkeit noch dem
Kostendruck gerecht werden. Die Notwendigkeit einer neuen Organisationsform
neben der bekannten Linienfunktion wurde zu einem „MUSS“.
So wurden in den 1980er-Jahren etwa bei Automobilherstellern noch weitestge-

hend Linienabläufe gelebt. Es gab Arbeitskreise, aber noch keine offizielle Projekt-
struktur. Der Produktentstehungsprozess eines Fahrzeugs betrug zu diesem Zeit-
punkt etwa sieben Jahre. Kommunikations- und Entscheidungswege verliefen
noch hierarchisch in der Linienfunktion. E-Mail-Adressen waren nur konzernin-
tern gegeben – undenkbar für die heutige jüngere Generation (Quelle: Heinz
Schelle, Entwicklungsgeschichte und Trends im Projektmanagement, S. 5)
Was ändert sich mit dem Projektmanagement? Was verbirgt sich dahinter?
Projektmanagement ist eine Veränderung der Linienfunktion in einen Prozess!

Im Projektmanagement wird nicht gefragt, welche Funktion zuerst kommt, son-
dern welches Arbeitspaket zuerst erledigt werden muss, um das Ziel schnellst-
möglich zu erreichen. Wir wechseln von der Arbeit in der sicheren Hierarchie der
Linie hin zu einer atmenden und flexibleren Projektstruktur.
Dies setzt voraus, dass gut funktionierende sogenannte „cross-funktionale

Teams“ aufgesetzt werden. Wir reden dann generell darüber, welches erste Ar-
beitspaket zuerst notwendig wird, und erst dann über den Arbeitsbereich (oder
Fachbereich), der dieses Arbeitspaket umzusetzen hat. Es ist eine große Heraus-
forderung, dieses Vorgehen in eine bestehende Aufbauorganisation mit ihren
festen Abläufen zu implementieren.
Mit dem Projektmanagement haben wir nicht nur eine Methode implementiert,
sondern wir benötigen eine weitere Organisationsform, eine „Sonderorganisation
auf Zeit“. Diese besteht in einer Matrixorganisation parallel zur bestehenden
Linie.
Die Projektmanagementorganisation benötigt eigene Rollen, Funktionen und

Kommunikationsspielregeln. Die Menschen im Unternehmen aber bleiben die
gleichen. Viele erhalten eine doppelte Funktion und damit auch Arbeitsbelas-
tung. Im Einkauf oder aus dem Einkauf heraus gilt es, das Tagesgeschäft zu meis-
tern und zusätzlich das Projekt zu steuern. Damit sind Projektmitglieder und
Projektleiter auch täglich gefordert, ihre Zeit und ihre Aufgaben zu strukturieren
und zu managen.
Die Herausforderung in Linie und Projekt kann nur gemeistert werden, wenn wir
diese Fragen auch beantworten können:
„Welche Aufgabe hat wann Priorität?“ oder „Welches Projekt wird zuerst bedient?“
Eigenorganisation bedeutet in diesem Zusammenhang, zu unterscheiden, was

heute dringend und was wichtig ist: eine kontinuierliche Herausforderung in
einer sich schnell bewegenden Struktur.
In der Geschichte und Entwicklung arbeitete die NASA im gleichen Zeitraum

bereits mit Projektmanagement, um die Kosten einzudämmen. Zur Koordination
der vielen Partner und Lieferanten werden Planungs-, Steuerungs- und Projekt-
überwachungssysteme eingeführt.
Eine Standardisierung entwickelte sich in Amerika und Europa Ende der 1970er-,
Anfang der 1980er-Jahre mit dem Ziel der Gewährleistung eines hohen und ein-
heitlichen Qualitätsniveaus unter Berücksichtigung der jeweiligen Landesstan-
dards. Die Institute bieten auch entsprechende Zertifizierungen an.
1983 veröffentlichte das PMI (Project Management Institute), der US-

amerikanische Fachverband für Projektmanagement, mit dem „Project Manage-
ment Body of Knowledge“ (PMBOK) die erste umfangreiche Ausbildungsunter-
lage für Projektpersonal.
Die IPMA (International Project Management Association) ist ein von Europa
ausgehender Projektmanagement-Verband (bzw. Zertifizierungsstelle), der 1979
in der Schweiz etabliert wurde. Der heutige Sitz ist in den Niederlanden. In
Deutschland liegt hierfür die Verantwortung bei der GPM, die ein vierstufiges
Zertifizierungsprogramm durchführt.
Projektmanagement auch für den Einkauf zuzuschneiden, ist eine Entwicklung,

die sich durch starke Veränderungen an die Rolle des Einkaufs und an den Ein-
käufer ergeben hat. War die Rolle des Einkäufers noch vor einiger Zeit die des
Beschaffers, so hat sich diese über die letzten Jahre deutlich verändert.
Viele Schnittstellen, hohe Geschwindigkeit, schnelle Änderungen und internatio-

nales Arbeiten sind nur einige Gesichtspunkte, die deutlich machen, dass wir
neben der bisherigen Organisationsform eine weitaus flexiblere benötigen, um
die geforderten Arbeiten in der sich darstellenden Komplexität überhaupt bewäl-
tigen zu können. Auch und vor allem im Einkauf!
23
3 Entwicklung der Anforderungen

im Einkauf und die
Notwendigkeit von
Projektmanagement
3.1 Die Rolle des Einkaufs im Unternehmen

Die Geschichte des Einkaufs ist so alt wie die Geschichte des Handelns. Bereits in
der Antike wurde für Einkauf relevantes Wissen in Handelsschulen vermittelt.
Aufgrund der Intensivierung des Handels im Mittelalter wuchs auch die Bedeu-
tung der Einkaufsaktivitäten. 1832 wurde der Einkauf in einer Veröffentlichung
des englischen Ökonomen Charles Babbage (1791–1871) vermeintlich erstmals als
wichtige unternehmerische Funktion beschrieben (Quelle: Charles Babbage, On
the Economy of Machinery and Manufactures, 1832; http://www.gutenberg.
org/ebooks/4238, Zugriff am 03.09.2016).
Die erste bekannte Einkaufsabteilung wurde 1866 im Zuge der Entwicklung der
Eisenbahn in Nordamerika gegründet. Nach der Jahrhundertwende wurden in
weiteren wissenschaftlichen Veröffentlichungen beispielsweise die Funktionen
der Einkaufsabteilungen sowie die notwendigen Qualifikationen der Beschäftig-
ten diskutiert. Der Einkauf kann folglich in Theorie und Praxis auf eine sehr lange
Tradition zurückblicken.
1980er-Jahre
In vielen Unternehmen setzt sich die Erkenntnis durch, dass sich die Beschaffung
von Gütern nicht nur auf den Einkaufspreis konzentriert. Auch die Globalisie-
rung und die in vielen Unternehmen immer geringer werdende Fertigungstiefe
führen dazu, dass immer mehr die Erkenntnis reift, dass die Einsparungen in der
Prozesskette (Supply Chain) liegen und nicht nur in der Verhandlung mit dem
Lieferanten.
1990er-Jahre
In dieser Zeit gibt es nochmals einen Trend, geprägt durch den Manager José
Ignacio López, welcher als Einkaufsvorstand bei Volkswagen durch seine kom-
https://doi.org/10.1007/978-3-658-31310-4_3
24 Entwicklung der Anforderungen im Einkauf …
promisslose Verhandlungsführung eine erhebliche Kostensenkung erzielte, die

aber im Nachhinein sehr oft durch eine Verschlechterung der Qualität in Frage
gestellt wurde. Projektmanagement, Supply Chain Management und Total Cost
of Ownership rücken mehr in den Vordergrund.
Die Anforderungen an den Einkauf und damit auch an die Einkäufer entwickeln
und verändern sich. Bedingt durch die hohe Dynamik im Unternehmensumfeld
kommt die Anforderung hinzu, Strategien, Abläufe und Geschwindigkeit anzu-
passen und neue Wege zu gehen. Die Lösungsansätze zielen alle darauf ab, das
funktionsorientierte Denken aufzugeben und ganzheitlich, prozessorientiert zu
denken und zu handeln. Projektmanagement gewinnt im Einkauf an Bedeutung.
Damit verändert sich auch das Berufsbild des Einkäufers. In den Unternehmen
war der Einkäufer über Jahre lediglich der Beschaffer. Stiegen die Preise, so wur-
de dies dem Einkäufer angelastet. Eine ganzheitliche Betrachtung hinsichtlich der
Supply Chain setzt sich erst langsam durch. Das Geld kann nur noch teilweise in
einer geschickten Verhandlung gespart werden, mehr aber in einer kompletten
Prozessbetrachtung, eben der sogenannten Supply Chain. Der Kostendruck wird
der Position des Beschaffers nicht mehr gerecht. Die Rolle des Einkäufers be-
kommt komplett neue Herausforderungen. Quelle: BME-Service „Personal &
Karriere“ & BME-Initiative „Young Professionals“, BME-Leitfaden „Karriere im
Einkauf“, 2012, S. 10)
So kann es passieren, dass einzelne Produkte teurer werden, der Prozess aber
ganzheitlich für das Unternehmen Einsparungen aufweist. Spätestens hier wird
deutlich, dass sich die Rolle des Einkäufers hin zum Projektmanager verändert
und viele Schnittstellen zu integrieren sind.
Viele Einkaufsprojekte entstehen aus sogenannten Cost-Saving-Programmen,

Lieferanten in Low Cost Countries oder Veränderungen in der Struktur im eige-
nen Unternehmen.
In bestimmten Bereichen kann ein Teil der Einsparungen durch gezielte Verhand-
lungen erreicht werden, sehr oft aber nur noch durch die Betrachtung bzw. die
Optimierung der kompletten Prozesskette. Dies bedingt große Veränderungen
und auch technische Anpassungen, so etwa bei Kooperationspartnern im In- und
Ausland, Verlagerungen von Werkzeugen, um nur zwei Beispiele für komplexe
Aufgaben im Einkauf zu nennen, deren Zielerreichung dann in Form einer Pro-
jektstruktur umgesetzt werden sollte.
Die Rolle des Einkaufs im Unternehmen 25
Abbildung 3.1 Potenzielle Projekte aus dem Einkauf heraus
Die Entscheidung, ob ein Projekt aufgesetzt werden soll oder die Linienstruktu-
ren ausreichen, um das Ziel zu erreichen, unterliegt bestimmten Kriterien und
der Entscheidung im Einkauf. Die Voraussetzungen dafür, was ein Projekt be-
dingt, bleiben die gleichen wie im klassischen Projektmanagement.
Dabei dürfen wir nicht vergessen: Ein Seminarteilnehmer fragte mich einmal,
warum er im Team arbeiten soll, wenn er es allein besser kann. Antwort: Gar
nicht, sollte er eine Tätigkeit wirklich allein besser können.
Nach DIN 69901 wird ein Projekt wie folgt definiert:
„Ein Projekt ist ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen
in ihrer Gesamtheit gekennzeichnet ist, wie z. B.: Zielvorgabe, zeitliche, finanzielle, per-
sonelle oder andere Bedingungen, Abgrenzungen gegenüber anderen Vorhaben und pro-
jektspezifische Organisation.“ (siehe hierzu auch: Projektdefinition auf Wikipedia
bzw. im PM Glossar: https://de.wikipedia.org/wiki/Projekt, Zugriff am
03.09.2016; https://www.projektmagazin.de/glossar, Zugriff am 03.09.2016)
Jedoch ist das Wort bzw. die Tätigkeit „Projekt“ nicht immer eindeutig definiert.
Ein Projekt setzt immer Teamarbeit voraus und die Einbindung diverser Schnitt-
stellen. Kann ich es allein bzw. allein besser, sollte ich nicht den Aufwand der
Projektarbeit betreiben. Denn dies wird gern vergessen: Das Aufsetzen der Son-
derorganisation auf Zeit, der Projektarbeit, bringt auch Mehraufwand in Form
der Integration von Entscheidern, des Steuerns von Menschen und der Abstim-
mungsarbeit mit sich.
Am Ende ist es immer eine Entscheidung des Managements, ob an dieser Stelle

die Notwendigkeit der Projektarbeit gesehen wird, unter Zuhilfenahme der Re-
geln des Projektmanagements.
Fazit
 Die Aufgabenumsetzung in Form einer Projektstruktur ist durch die stei-

gende Komplexität im Einkauf notwendig geworden.
 Die Rolle des Einkäufers hat sich vom Beschaffer zum Projektleiter ent-
wickelt.
 Internationales Arbeiten bedingt andere Organisationsformen.
 Projektarbeit generiert auch Mehraufwand.
 Die Entscheidung, ob und wie ein Projekt aufgesetzt wird, ist eine
Managemententscheidung.
3.2 Aktuelle Anforderungen an die Rolle

des Einkäufers
Die Aufgaben eines Einkäufers lassen sich im Wesentlichen in operative und
strategische Aufgaben aufteilen.
Beispiele operativer Einkaufsthemen:
■ Bedarfsplanung
■ Bestellung
■ Einholung und Vergleich von Angeboten
■ Rechnungskontrolle
■ Liefertermintreue
Aktuelle Anforderungen an die Rolle des Einkäufers 27
■ Überprüfung von Zahlungsmodalitäten

■ Eingabe der Daten ins System
■ ...
Beispiele strategischer Einkaufsthemen:
■ Ermittlung und Bedarf der Materialien für das Unternehmen

■ Agieren auf internationalen Beschaffungsmärkten
■ Gestaltung und Zusammenarbeit mit bevorzugten Lieferanten
■ Organisation einer Zusammenarbeit mit notwendigen Nachbarfunktionen
(Entwicklung, Technik, Qualitätssicherung, Juristen ...)
■ konsequente Umsetzung der Unternehmensstrategie in eine gute Einkaufs-

strategie
■ Initiierung von Make-or-Buy-Entscheidungen

■ Outsourcing-Strategien
■ Prozessanalysen
Je nach Unternehmensgröße und Aufbauorganisation können diese Rollen und
Anforderungen personell klar getrennt werden, oft vermischen sie sich aber auch.
Während der konventionelle Einkauf in erster Linie als „Bestellbüro“ diente, gilt
es nun vermehrt, strategisch aktiv zu werden. Das erfordert im Rahmen der Ma-
terialwirtschaft besonders für den Einkäufer ein geändertes Anforderungsprofil.
Nunmehr ist nicht mehr nur die Fachkompetenz, sondern auch Sozial- und Ma-
nagementkompetenz gefragt. Der Einkäufer wandelt sich vom Spezialisten zum
Generalisten. Umsetzungsstärke, ganzheitliche Betrachtung der Situation, Team-
orientierung und Führungsqualitäten sollten den Mitarbeiter im Einkauf aus-
zeichnen.
Vor diesem Hintergrund wandelt sich der Einkäufer in einen Projektmanager mit
dem Schwerpunkt des Führens von klassischen Einkaufsprojekten. Somit ergeben
sich auch neue Herausforderungen an die Rolle hinsichtlich seiner Verantwor-
tung und Kompetenz.
Welche Vorteile verspricht man sich vom Projektmanagement im Einkauf?

Durch die strukturelle Trennung sowie das prozessorientierte Denken im Ein-
kauf ergibt sich eine Verbesserung der Einkaufsergebnisse durch:
 strategischeres Vorgehen
 Einbindung der Schnittstellen durch cross-funktionale Teams
 schnellere Umsetzung komplexer Aufgaben
 bessere Kommunikation
 schnellere Reaktionsgeschwindigkeit bei Änderungen
 höhere Savings durch das Steuern unternehmensrelevanter Projekte aus

dem Einkauf heraus
 strukturierteres Abarbeiten bei internationalen Herausforderungen
Das Ziel ist immer eine schnellere und effizientere Abarbeitung der anstehen-
den Aufgabe.
Aktuelle Anforderungen an die Rolle des Einkäufers 29
4 Voraussetzungen für
Projektarbeit im Einkauf
An dieser Stelle gilt es, sich immer wieder in das Bewusstsein zu rufen, dass eine
Projektmanagementorganisation eine Sonderorganisation auf Zeit ist. Diese be-
steht neben der Linienorganisation und muss mit entsprechenden Spielregeln
versehen werden.
Folgende Faktoren sind aus der Erfahrung heraus kritisch:
■ Abgrenzung, was ein Projekt ist und als solches auch abgearbeitet werden
muss
■ Definition der Entscheidungsfindung bzw. der Entscheider

■ Definition von Rollen, Aufgaben, Verantwortung und Kompetenz
■ Definition von Eskalationsstufen
■ Bewertung der notwendigen Aufwände und Ressourcen, die eine erfolgreiche
Umsetzung der Aufgabe erst möglich machen
Grundvoraussetzung für ein Projekt ist immer die Eingrenzung durch das soge-
nannte „Magische Dreieck“ oder „Triple Constraint“, wie es vom PMI bezeichnet
wird.
Ein Projekt hat immer einen klar definierten Anfang und ein klar definiertes Ende
mit einem darin vereinbarten Leistungsumfang zu entsprechenden Kosten!
Der Projektlebenszyklus wird in verschiedene Phasen eingeteilt. Die Laufzeit

eines Projektes kann je nach Größe zwischen einigen Wochen bis zu mehreren
Jahren betragen. Ein „Muss“ ist es, am Anfang eines Projektes aus den Anfor-
derungen des Kunden oder Auftraggebers einen klaren und für alle Projektbe-
teiligten eindeutigen Projektauftrag zu definieren, was in der Praxis leider oft
sehr vage gehalten wird und damit im Verlauf der Umsetzung zu Problemen
führt. Sobald der Rahmen abgesteckt ist, kann auch das Ziel entsprechend defi-
niert werden. Das jeweilige Ziel mit seinen entsprechenden Meilensteinen (=
Teilzielen) sollte bereits in einer frühen Phase klar definiert und schriftlich
dokumentiert werden.
https://doi.org/10.1007/978-3-658-31310-4_4
30 Voraussetzungen für Projektarbeit im Einkauf
Dies ist ein iterativer Prozess, der idealerweise unter Einbeziehung der Fach-
funktionen stattfindet und somit auch einen Teil der Teambildung gewährleis-
tet. In einer frühen Phase des Projektes lassen sich viele Faktoren wie Zeit und
Kosten nur durch analoge Kalkulation (auf Basis früherer Projekte und Ver-
gleichswerte) abschätzen. Im Verlauf der Planungsphase wird die analoge Kal-
kulation in eine detailliertere Abschätzung auf Basis der Arbeitspakete überge-
leitet.
Die Voraussetzung eines Projektes, immer einen klar definierten Anfang und ein
klar definiertes Ende zu haben, klingt in der Theorie sehr einfach. Oft sind diese
aber in der Praxis schwer zu beschreiben, da oft eine Grauzone vorhanden ist.
Daher gelten immer die pragmatischen Fragen:
■ Welches Arbeitspaket wird dem Projekt zuerst zugeordnet?

■ Ab wann bin ich als Projektleiter für die Umsetzung verantwortlich?
Dieser Übergangsbereich oder die am Anfang eines Projektes bestehende Grau-
zone wird möglichst schnell vom Tagesgeschäft abgegrenzt. Dadurch vermeidet
man unnötige Reibungskonflikte und sorgt für einen guten Übergang der Aufga-
ben und Teammitglieder von der Linienarbeit in die Projektarbeit.
Die Fragen
■ „Was gehört zum Projekt?“ und

■ „Was liegt außerhalb der Projektverantwortung (gern auch als „Out of Scope“
bezeichnet)?“
sollten im Projektauftrag beschrieben und dokumentiert sein.
Sie sind bei der Abgrenzung hilfreich. Manchmal ist es einfacher, zu beschreiben,
was nicht zum Projektauftrag gehört, um daraus abzuleiten, welche der anste-
henden Aufgaben dem Projekt zugeordnet werden.
Ein einfaches, aber klares Beispiel ist ein Hausbau. Hier wird der Inhalt des Hau-
ses beschrieben. Der Garten, ebenfalls wichtig, ist aber kein Bestandteil des Bau-
trägervertrags und damit „out of scope“.
Wodurch werden Projekte gekennzeichnet, oder wann machen Projekte Sinn? 31
Fazit
 Abgrenzung des Verantwortlichkeitsbereiches!
 Wo ist der Anfang des Projektes?
 Wann ist das Projekt beendet?
 Welche Ressourcen sind notwendig?
 Wie sind die Rollen definiert?
 Was ist Bestandteil des Projektauftrags?
 Ist der Auftrag schriftlich definiert und abgezeichnet?
 Out of Scope oder: Was gehört nicht zum Projektauftrag?
4.1 Wodurch werden Projekte

gekennzeichnet, oder wann
machen Projekte Sinn?
Ein Projekt ist immer durch eine entsprechende Komplexität gekennzeichnet.
Nur dann, wenn entsprechende Schnittstellen notwendig sind, bestimmte Risiken
absehbar, der Neuigkeitsgrad gegeben ist, macht es Sinn, den Aufwand für das
Aufsetzen der Sonderorganisation auf Zeit, der Projektorganisation, überhaupt
aufzuwenden.
Sehr oft wird vergessen, dass Projektarbeit auch den Zeit- und Ressourceneinsatz
voraussetzt. Was aber kennzeichnet Projekte im klassischen Sinn?
Projekte sind temporär
Das heißt aber auch, sie haben einen klar definierten Anfang und ein definiertes
Ende. Projekte beginnen, wenn die verantwortliche Organisation diese offiziell
autorisiert. Das Ende eines Projektes ist erreicht, sobald die Ziele und die dazu-
gehörigen Meilensteine in die Praxis umgesetzt wurden. Der Projektauftrag ist
das schriftliche dazugehörige Dokument.
Projekte sind einzigartig
Einzigartig heißt an dieser Stelle, dass das Produkt, das Konzept oder der Prozess
neu oder anders sind als die Aufgaben vorher. Auch wenn der Bauträger bei
einem Hausbau bereits mehrere Häuser fertiggestellt hat, so wird doch jedes
weitere wieder als Projekt abgewickelt. Rahmenbedingungen, Anforderungen

des Kunden, technische Details etc. können immer anders sein. Genauso verhält
es sich bei einem potenziellen Einkaufsprojekt, z. B. der Verlagerung eines Werk-
zeugs, der Implementierung eines Lieferantenbewertungssystems o. Ä.
Projekte sind komplex
Die Komplexität kann sich sowohl durch viele Schnittstellen als auch durch tech-
nische oder strukturelle Anforderungen auszeichnen. Durch die weltweite In-
tegration von Lieferanten sind Landesspezifika, kulturelle oder auch politische
Herausforderungen im Rahmen der Komplexität immer ein Thema. Ein Aufgabe
allein für sich stehend ist noch kein Projekt. Aufgaben können aber kleine Ele-
mente des Projektes sein. Eine Excel-Tabelle zur Anordnung von Lieferanten zu
erstellen, ist noch kein Projekt, im Rahmen einer Portfolioanalyse zur Bewertung
von Auditierung von Lieferanten kann es jedoch Bestandteil eines Projektes sein.
Um ein Projekt erfolgreich abschließen zu können, müssen die im Basisplan festge-

legten Anforderungen hinsichtlich Termine, Kosten und des vereinbarten Leis-
tungsumfangs in die Praxis umgesetzt sein. Das Projekt ist ein System mit vielen
Arbeitspaketen, in dem der Projektleiter gemeinsam mit dem Kernteam die mitei-
nander im Wettbewerb stehenden Anforderungen und Aufgaben im Sinne des
Gesamtziels ausgleicht.
Auch wenn eine Grauzone vorhanden ist: Die Abgrenzung, ab wann die Aufga-
ben dem Projekt zugeordnet werden und was außerhalb des Projektes liegt, ist
unerlässlich, damit eine Aufwands- und Kostenschätzung möglichst realistisch
durchgeführt werden kann. Erst dadurch wird es möglich, zu beurteilen, welchen
Gewinn oder Einsatz das Projekt in finanzieller Hinsicht bedeutet.
Etwa 95 Prozent der Tätigkeit eines Projektleiters ist mit Kommunikation ver-
bunden. Damit wird auch deutlich, dass hier die Hauptaufgabe des Projektleiters
liegt. Es ist wohl eine der großen Herausforderungen, diesen Kommunikations-
prozess stringent zu führen. Hierzu gehören nicht nur das Kernteam und die
Beteiligten, sondern es umfasst auch die Kommunikation, das Berichtswesen und
die Marketingarbeit zu Auftraggebern, Gremien und Stakeholdern.
4.2 Phasen im Projektlebenszyklus

Für Projekte werden im Unternehmen Phasen beschrieben, deren Anfang und
Ende immer durch einen Meilenstein oder ein Gate Review (Audit mit Überprü-
fung auf Erreichung der gesetzten Teilziele) gekennzeichnet sind.
Phasen im Projektlebenszyklus 33
Ein weiterer Aspekt der Phasen ist die Reduzierung der Komplexität. Durch die
Einteilung des Projektes in Phasen ist es bereits am Anfang eines Projektes mög-
lich, eine Form der zeitlichen Gliederung zu erlangen, auch wenn über das Pro-
jekt und die damit verbundenen Aufgaben noch nicht viel bekannt sind.
In vielen Unternehmen werden am Ende einer Phase sogenannte Gate Reviews

durchgeführt. Diese Gate Reviews geben dem Projektleiter die Möglichkeit der
Überprüfung einzelner, vorab definierter Arbeitsstände und damit die Sicherheit
des Projektfortschritts nach Basisplan. Diese Abfrage bekommt formalen Charak-
ter und damit auch die Möglichkeit, die Aufmerksamkeit sowie die Unterstüt-
zung des Managements zu erlangen.
Alle Projekte haben etwas gemeinsam: Sie stehen nicht einfach so im Raum, son-
dern die Quelle ist immer ein Kunde, eine komplexe Aufgabe oder auch ein kon-
kretes Problem. Die Definition, wann etwas in Form eines Projektes und mit der
Methode Projektmanagement abgewickelt werden soll, unterliegt dem Unter-
nehmen und ist oft eine Frage der Vereinbarung, die in einem Projektmanage-
ment-Handbuch festgelegt sein kann oder sollte.
Ziel eines Handbuchs ist, dass in einem Unternehmen Projekte nach gleichen
Spielregeln abgewickelt werden. Wenn der eine Schach spielt und der andere
Monopoly, dann macht zwar keiner einen Fehler, aber es ist nahezu ausgeschlos-
sen, zu einem gemeinsamen Ergebnis zu kommen. Im Handbuch werden deshalb
die gemeinsamen Spielregeln definiert und schriftlich dokumentiert.
Abbildung 4.1 Magisches Dreieck
Eine Skizze zur Entstehung eines Projektes in einer Matrixorganisation ist das
sogenannte „Magische Dreieck“ (Abbildung 4.1). Es setzt die Eckpunkte für den
vereinbarten Leistungsumfang im Hinblick auf Termine und Kosten:
■ Was ist in unserem Bereich oder Unternehmen als Projekt definiert?

■ Wie lautet der vereinbarte Leistungsumfang (= Qualität)?
■ Welche Kosten entstehen?
■ Wie lange wird es dauern (Termine)?
Wo kommen Projekte eigentlich her? Manchmal bekommt man das Gefühl, sie
erscheinen einfach so im jeweiligen Umfeld. Die „Grauzone“ ist ab und an sehr
hoch. Dies gilt es, am Anfang zu klären, um diese nicht durch den kompletten
Projektlebenszyklus mitzuziehen.
Unabhängig von der Ursache des Projektes ist es immer wichtig, den definierten
Prozess ablaufen zu lassen. Die Standardisierung sorgt für Effizienz und Akzep-
tanz des Vorgehens unternehmens- bzw. einkaufsweit.
Ein Projekt benötigt den Projektauftrag, um der Aufgabe in ihrer gesonderten

Organisationsform den notwendigen Rahmen und auch die entsprechende Ver-
bindlichkeit im Unternehmen zu geben.
Auftraggeber lieben das Risiko und geben gern unklare Aufträge. Um dem entgegenzu-
wirken, wird der Projektauftrag als Vertrag benötigt. Dies sichert sowohl den Auftragge-
ber als auch den Projektleiter ab!
Der Ursprung oder die Notwendigkeit für ein Projekt kann vielseitig sein. Es
kann ein Problem, der Bedarf nach Veränderung, ein Kunde oder die Generie-
rung von Savings sein, um an dieser Stelle nur einige Beispiele zu nennen. Der
Übermittler des Projektes ist der Auftraggeber. Er ist derjenige, dem wir auch
berichten (siehe Kapitel 5.7, bzw. Schritt 7 – Projektorganisation). Am Ende eines
jeden Projekts steht dann das jeweilig definierte Produkt.
Der erstellte Basisplan wird in der Umsetzungsphase gesteuert, Abweichungen

vom Plan frühzeitig verfolgt und entsprechend der Situation angepasst. Wir
steuern und überwachen immer die drei Komponenten des Magischen Dreiecks.
Daher reduziert sich die Frage in der Steuerung auch immer wieder auf die drei
Eckpunkte. Habe ich es einmal definiert, so wird in der Steuerung gefragt: Wel-
che Bedeutung hat die Änderung für
■ Termine,
■ Kosten,
■ Qualität (vereinbarter Leistungsumfang)?
Standardisierung in den Phasen 35
Keine dieser Stellgrößen kann verändert werden ohne einen Einfluss auf eine der
beiden weiteren Größen. Konkret heißt das, ich kann keine Termine verkürzen,
ohne entweder den Leistungsumfang anzupassen oder die Kosten zu erhöhen.
Sicherlich kann ich den Leistungsumfang reduzieren und dabei die Kosten und den
Termin halten. Doch dies wäre natürlich nicht im Sinne des Projektes und es wäre
gewiss eine spannende Herausforderung, dies dem Auftraggeber zu „verkaufen“.
4.3 Standardisierung in den Phasen

Die standardisierten Phasen und Meilensteine des Projektmanagements werden
in Prozessen beschrieben (Abbildung 4.2). Das Ziel dieses Vorgehens ist eine
Erleichterung der Abfolgen durch Standardisierung. Gleichermaßen möchten wir
im Unternehmen und im Einkauf sicherstellen, dass alle Beteiligten nach den
gleichen Spielregeln arbeiten.
Die vier Phasen, die auch in jedem Einkaufsprojekt zu beschreiben sind, lauten:
1. Definitionsphase
2. Planungsphase
3. Umsetzungsphase
4. Abschlussphase
Folgende Projektmanagement-Tätigkeiten sollten in den jeweiligen Phasen

durchgeführt werden:
1. Definitionsphase:
Mit der Definitionsphase bekommt das Projekt einen offiziellen Charakter. Das
Projektteam wird seitens der benötigten Funktionen benannt. Der Umfang aller
für das Projekt benötigten Ressourcen ist an dieser Stelle noch nicht geklärt.
Wir arbeiten auf Basis von Erfahrungswerten bzw. auf Basis von bereits abge-
schlossenen Projekten.
Je nach Stand der Aufgabe, kann diese Phase auch eine Machbarkeitsanalyse
beinhalten.
Innerhalb der Phase wird der Kick-Off durchgeführt, die offiziellen Eckdaten
ausgetauscht, und, je nach Größe des Projektes, kann auch der Projektstruktur-
plan gemeinsam erstellt werden.
Am Ende der Phase stehen der unterzeichnete Projektantrag und das Kernteam
fest. Der Projektleiter ist offiziell ins Amt berufen!
Sprechen wir über eine technische Änderung, so ist in dieser Phase auch das
Systemkonzept zu beschreiben.
 Am Ende der Definitionsphase sollte der Projektantrag unterschrieben sein.
 Die Grobplanung für das Projekt ist vorhanden.
 Das Kick-Off wurde durchgeführt.
 Das Team ist benannt.
 Der Leistungsumfang, die Termine sowie die Kosten sind abgeschätzt und
 (sollte dies noch nicht vor Beginn des Projektes geschehen sein) die Mach-
barkeit geprüft.
2. Planungsphase:
Die Planungsphase dient der weiteren Konkretisierung und Detaillierung der

Planung der Definitionsphase. Ziel der Planungsphase ist ein detaillierter Pro-
jektplan, welcher sich aus verschiedenen Detailplänen zusammensetzt (z. B. Risi-
koplanung, Aufwandsplanung, Termin- und Meilensteinplanung, Kosten- und
Ressourcenplanung). Wann immer möglich, werden die Arbeiten im Team ausge-
führt, um hier schon für einen guten Teamfindungsprozess zu sorgen.
Der Fokus in der Planungsphase liegt auf der Erstellung des Basisplans. Die Her-
ausforderung ist die realistische Abschätzung der benötigten Aufwände für Ar-
beitspakete, Funktionen und Aufgaben. Sehr oft steht diese in Korrelation zu den
Vorgaben und Wünschen der Kunden oder Auftraggeber. Es findet eine iterative
Herangehensweise statt, in der der Projektleiter die jeweiligen Schnittstellen
zusammenbringt. Während wir uns in der Definitionsphase noch auf Ver-
gleichsprojekte und Annahmen stützen („top down“), ist in der Planungsphase
so viel Wissen vorhanden, dass über die einzelnen Arbeitspakete, also eher „bot-
tom up“ geplant werden kann.
Das Projekt ist am Ende dieser Phase hierarchisch gegliedert und die Projekt-
struktur bis auf Arbeitspaketebene heruntergebrochen.
Am Ende der Planungsphase ist der Basisplan vorhanden – das Dokument, wel-
ches über die gesamte Projektlaufzeit nur über einen offiziellen Änderungsantrag
mit Genehmigung des Steuerkreises angepasst bzw. geändert werden kann.
Dieses Referenzdokument basiert auf den Daten des „Magischen Dreiecks“. Hier
sind die Eckdaten von Termin, Kosten und Qualität (vereinbartem Leistungsum-
fang) festgelegt.
Der Basisplan ist ein festes Dokument. Ist eine Änderung des Basisplans notwen-
dig, so erfolgt diese ausschließlich über den vorab festgelegten Änderungspro-
zess und betrachtet wieder die Auswirkungen der Änderung hinsichtlich Kosten,
Termin und Leistungsumfang aller beteiligter Funktionen. Die Freigabe der Än-
derung erfolgt über einen offiziellen Steuerkreis.
3. Umsetzungsphase:
Hier beginnt die Realisierung des definierten Projekts. Ist mein Projekt ein Kon-
zept (z. B. Vorschlag zur Lieferantenbewertung), so ist die Umsetzung das Papier
und an dieser Stelle noch nicht die Bewertung der Lieferanten selbst. Als Umset-
zung gilt immer die Umsetzung des Projektes, nicht zu verwechseln mit der Ferti-
gung des Produktes!
Wichtig ist es, auf die klare Abgrenzung zu achten: Was gehört zum Projekt und was nicht?
Der Schwerpunkt der Projektleiter-Tätigkeit ist in dieser Phase das Steuern des Projektes.
Es findet ein permanenter Soll-Ist-Abgleich von Basisplan zu Istplan statt!
Das Augenmerk des Projektleiters liegt auf der Steuerung des Projektes. Es findet
ein permanenter Soll-Ist-Abgleich statt. Die im Basisplan festgelegten Arbeitspa-
kete werden in ihrer Umsetzung überwacht. Kernteammeetings und Arbeitssit-
zungen sind Teil der Steuerung von Terminen/Kosten in Bezug zum vereinbarten
Arbeitspaket.
Bei anfallenden Abweichungen gilt es, die Arbeitspakete hinsichtlich des final
vereinbarten Projektziels wieder zu korrigieren. Dies setzt eine gute Kommunika-
tionsstruktur voraus, die vorab festgelegt sein sollte. Etwa 95 % der Tätigkeit
eines Projektleiters steht im Zusammenhang mit Kommunikation.
4. Abschlussphase:
Nach der Umsetzung des Projektes gibt es hinsichtlich des kaufmännischen Ab-
schlusses, des Reviews und vor der Entlastung des Teams sowie auch dem Feiern
von Erfolgen noch einige Aufgaben.
Das Projekt wird in der Abschlussphase nochmals bewertet. Haben wir das ge-
steckte Ziel erreicht? Was können wir zukünftig verbessern? Was war gut, was
weniger?
Der Projektabschlussbericht wird seitens des Projektleiters erstellt und an den

Kunden weitergegeben.
Das Projekt findet sein offizielles Ende. Das Produkt wird der Linie übergeben.
Der Projektleiter wird entlastet. Dieser Meilenstein kann auch zu einem Zeit-
punkt X nach Abschluss des Projektes stattfinden. Der Zeitpunkt sollte aber defi-
niert werden.
Fazit
 Projekte werden in Phasen eingeteilt, um die Komplexität zu reduzieren.
 Mit der Einteilung in Phasen bekommt das Projekt bereits eine erste Struktur.
 Die nächste Phase kann erst begonnen werden, wenn die vorherige die fest-
geschriebenen Meilensteine erreicht hat. Dies wird oft mit einem Review
überprüft.
 Abschluss der Definitionsphase ist der Projektantrag.
 Abschluss der Planungsphase ist der Basisplan des Projektes.
 Abschluss der Umsetzungsphase ist die Umsetzung des Basisplans entspre-

chend der Terminschiene.
 Das Ende der Abschlussphase sind die Dokumentation und die Entlastung
des Teams.
 Die Schwerpunkte der Tätigkeit des Projektleiters wechseln von Phase zu

Phase:
— Definitionsphase = Abschätzen des Umfangs, konkrete Klärung des

Auftrags, Kick-Off.
— Planungsphase = Die in der Definitionsphase abgeschätzten Umfänge

hinsichtlich Terminen, Kosten und Qualität als Top-down-Arbeits-
pakete umsetzen und daraus Termin- und Kostenplan erstellen.
— Umsetzungsphase = Steuern des Projektes und permanenter Soll-Ist-

Abgleich.
— Abschlussphase = Übergabe des Projektes an Auftraggeber, Dokumen-

tation, Entlastung des Teams und Projektleiters.
Abbildung 4.2 Überblick und Phasenplan

5 „8 Schritte“ im
Projektmanagement
Was genau benötige ich, um ein Projekt zu steuern? Wenn man sich die Theorie
ansieht, dann bekommt man sehr schnell das Gefühl: kein Problem. Das Thema
ist einfach zu verstehen. Das stimmt zwar, aber:
Ein paar Termine, die Kosten und ein Ziel gilt es zu steuern. Wie fragte mich
meine Großmutter einmal: „Und was machst Du mit dem Rest des Tages?“
Nun wird die Theorie in die Praxis umgesetzt und dann kommt der „Aha-
Effekt“. Da wird selbst eine Auftragsklärung zur echten Herausforderung. Da
werden Entscheidungen nicht getroffen. Es existieren Herausforderungen an
allen Ecken: Technik, die nicht so umgesetzt wird, Arbeitspakete, die nicht einge-
halten werden, Überschreitungen des Plans, Konflikte, Teammitglieder, die nicht
nach Plan arbeiten, Rollen, die nicht geklärt sind.
Und immer wieder die gleiche Frage: Was kann ich machen, um diese komplexe
Aufgabe transparent zu steuern und erfolgreich umzusetzen? Was aber brauche
ich wirklich an Werkzeugen, damit es funktioniert?
Aus meiner Erfahrung der letzten dreißig Jahre im Projektmanagement sind es

die einfachen Methoden, die uns helfen, den Überblick im Projekt zu behalten.
In der Hektik des Alltags mit all seinen Herausforderungen muss die anzuwen-
dende Methode einfach sein. Ich brauche einen roten Faden, dem ich folgen kann,
auch wenn es unruhig wird im Umfeld. Genau dann, wenn Zeitdruck und Ter-
minengpässe zur Tagesordnung gehören; gerade dann benötigen wir einen einfa-
chen Werkzeugkasten, der uns eine Struktur ermöglicht, auf die wir immer wie-
der zurückgreifen können.
8 Schritte, mit dem Team besprochen und in die Praxis umgesetzt, schaffen be-
reits viel Klarheit und Transparenz. Natürlich kann ich bei Bedarf auch viele
weitere Methoden anwenden. Erst einmal möchte ich hier jedoch praxisorientiert
aus meiner Erfahrung die 8 Schritte vorstellen, mit denen ich den roten Faden
durch das Projekt legen kann. Diese Schritte sind keine Erfindung meinerseits,
sondern auch Bestandteil nationaler und internationaler Zertifizierungen und
Standardisierungen. In einer bestimmten Reihenfolge abgewickelt, ergeben die 8
Schritte eine hilfreiche Struktur, die ich sowohl mit dem Team erarbeiten als auch
https://doi.org/10.1007/978-3-658-31310-4_5
42 „8 Schritte“ im Projektmanagement
(wenn Bausteine schon klar gegeben sind, z. B. Zieldefinition) auf Arbeitspaket-

ebene herunterbrechen kann.
Wichtig ist auch hier, dass die Planung sowohl seitens des Managements als auch
aus Sicht des Teams akzeptiert wird. Ein Ziel und eine Planung sind nur so gut,
wie sie von allen Beteiligten getragen werden.
Natürlich stehen diese 8 Schritte nicht nur im Raum, sondern aus ihnen lässt sich
sowohl die entsprechende Stakeholderanalyse ableiten als auch die Kommunika-
tionsstruktur (siehe Kapitel 5.7, bzw. Schritt 7 – Projektorganisation) aufbauen.
Alles was wir im Projekt zur Zielerreichung machen, wird in das Team oder in
Richtung Management kommuniziert. Dabei geht es um Input für Arbeitspakete
oder Entscheidungsfindung seitens des Managements. Die Frage ist immer, an
wen ich berichte, damit das Ziel wie geplant erreicht werden kann.
Die Methode, die mir in der Hektik des Alltags und im Tagesgeschäft weiterhel-
fen soll, muss einfach sein, damit ich diese in jeder Situation anwenden kann,
ohne lange darüber nachzudenken.
Die beschriebenen Schritte finden sich sowohl in den Prozessen der Deutschen
Norm GPM wieder als auch in der internationalen Zertifizierung, deren Regel-
werk das Project Management Body of Knowledge (PMI) ist. Das Mind-Mapping
wird in vielen Bereichen angewendet. Es ist eine allgemein gültige Methode, die
hier zur ersten Strukturierung der notwendigen Ressourcen und Schnittstellen
benutzt wird.
Die 8 Schritte haben sich über die vielen Jahre der Praxis in unterschiedlichen
Branchen und Projekten bewährt.
Projektantrag 43
Abbildung 5.1 Die Bestandteile der „8 Schritte“

5.1 Projektantrag
Der Projektantrag ist die offizielle Vereinbarung zum Projekt zwischen Auftrag-
geber und Auftragnehmer. Der Antrag setzt den Projektleiter offiziell in der Rolle
seiner Sonderorganisation, der Projektorganisation, in Kraft. Er dient als Ver-
tragsgrundlage für das weitere Vorgehen und sollte auch dafür Sorge tragen,
dass beide Parteien das gleiche Bild über die anstehende Aufgabe (das Projekt)
und deren Zielerreichung im Kopf haben.
Der Projektantrag sollte der Schriftform entsprechen und dokumentiert sein!
Die 8 Schritte werden in der Definitionsphase auf Basis der vorhandenen Infor-
mationen beschrieben und in der Planungsphase vertieft. In der Definitionsphase
ist es eine Abschätzung der Schritte, die bereits möglich sind. Die Basisdaten sind
Erfahrungs- bzw. Vergleichswerte.
In der Planungsphase sollten bereits alle Informationen vorliegen, die eine Pla-
nung über und durch die Arbeitspakete (top down) möglich machen.
Der Projektantrag kann nach unterschiedlichen Anforderungen des Unterneh-

mens ausgelegt sein. Folgende Punkte sollten immer enthalten sein:
a. Name des Projektes
b. Beschreibung: Was versprechen wir uns von der Umsetzung? Warum soll
dieses Projekt realisiert werden?
c. Rahmenbedingungen: Was sind die Leitplanken, die wir einhalten müssen.

Dies können unternehmensinterne Vorgaben, technische oder auch prozessre-
levante Vorgaben sein.
d. Team: Benennung der Funktionen – wenn möglich bereits mit Personen be-
setzt.
e. Aufgaben, Verantwortung und Entscheidungskompetenz der jeweiligen Rolle

sind entweder im Projekthandbuch des Unternehmens beschrieben oder wer-
den hier nochmals im Einzelnen als Abgrenzung zur Linienfunktion darge-
stellt.
f. Ziel des Projektes und Meilensteine: Die Meilensteine ergeben sich zum Teil
aus dem Ziel des Projektes. Meilensteine sind sogenannte Überprüfungsbau-
steine auf dem Weg zum Ziel.
Projektantrag 45
g. Über die Zielplanung (Schritt 3) werden das finale Ziel sowie die entspre-
chenden Meilensteine SMART beschrieben. Auch hier gilt die Devise: Ein Ziel
ist immer nur so gut, wie es von allen Beteiligten akzeptiert wird.
h. Budget und Wirtschaftlichkeitsbetrachtung: Was schätzen wir an Kosten und

Aufwänden für das Projekt, und was versprechen wir uns von der Umset-
zung?
i. Risikobetrachtung: Welche Chancen und Risiken sehen wir für die Umset-
zung? Welche Gelder müssen für die Vermeidung von Risiken bereitgestellt
werden? Je nach Größe des Projektes benötige ich einen zusätzlichen Risiko-
manager (verantwortlich für das Risikomanagement im Projekt).
j. In Scope/Out of Scope: Was gehört zum Projekt, was liegt außerhalb des Pro-
jektes und wird umgesetzt, ist aber nicht Bestandteil des Projektes? Die Out-
of-Scope-Betrachtung hilft in einer frühen Phase des Projektes, den Rahmen
besser abzustecken und damit potenziellen Konflikten vorzugreifen.
Abbildung 5.2 Beispiel Projektauftrag (Quelle: Hagen Management GmbH,

Projektauftrag kompakt, 2014 – kostenlose Formulare;
http://www.pm-handbuch.com/pm-vorlagen/, Zugriff am
03.09.2016)
Projekttitel: …….
A. Projektdaten
Start: Projektleiter: Name,

Fachabteilung
Ende: Projektnummer:
B. Projektorganisation
Projektleiter: Auftraggeber:
Projektteam: Name, Lenkungsausschuss: Name,

Abteilung Fachabteilung
Ja
…………. ………….
Nein
…………. ………….
…………. ………….
Sonstige Beteiligte: z.B. Externe, interne Beteiligte, die nicht direkt zum
Projektteam gehören
C. Projektbeschreibung
Ausgangssituation/
Projektbegründung:
Projektgesamtziel: Möglichst SMART beschrieben
Projektteilziele/ Meilensteine
Meilensteinziele:
…………
…………
…………
Messbare Projekt-  ………….  ………….

ergebnisse:
 ………….  ………….
 ………….  ………….
Out of Scope 1. ………….
2. ………….
3. ………….
4. ………….
Projektantrag 47
Projektrisiken:  ………….  ………….
 ………….  ………….
 ………….  ………….
D. Projektbudget & Wirtschaftlichkeit

Personalaufwand: Lohnkosten / Stundensatz mal abgeschätzter Auf-
wand je Abteilung
………….
………….
………….
Sonstige Kosten: Direkte Projektkosten €
…………. ………….
…………. ………….
Gesamtprojektkosten/
Projektbudget: ………….€
Sonstige Ressourcen: z. B. Räume, Reise, Tests ...
Projekteinnahmen/ Wirtschaftlichkeitsbetrachtung
Wirtschaftlichkeit: Was wird an Return des Projektes erwartet und wie
lange dauert es bis zum Break Even?
E. Rahmenbedingungen
Sonstige relevante Was sind Beschränkungen des Projektes?
Informationen:
F. Projektentscheidung
Einreichung
Projektauftrag:
……………………………………………..
Datum, Unterschrift Projektleiter
Projektentscheidung: Das Projekt wird bewilligt.

Das Projekt wird unter der Einhaltung folgender
Auflagen bewilligt:
 ………….
 ………….
 ………….
Das Projekt wird abgelehnt.
Begründung:
……………………………………………..
Datum, Unterschrift Auftraggeber
Der Projektantrag kann an die Anforderungen des Unternehmens angepasst werden! Es

gibt Empfehlungen inhaltlicher Art, aber keine Bedingungen!
Die in Unternehmen beschriebenen Projektaufträge können sehr unterschiedlich

ausfallen. Eine klar definierte Norm gibt es nicht. Obwohl dieses Dokument die
Basis für das weitere Vorgehen im Projekt bestimmt, existiert der „Auftrag“
manchmal nur in mündlicher Form.
Bei einem Zughersteller, für den ich tätig war, bestand der Auftrag in einem
vielseitigen Regelwerk, das durch Juristen abgesichert wurde. Genau so habe ich
demgegenüber den Auftrag mündlich erlebt: „ Für die Messe sollte ein Messe-
stand erstellt werden.“ An dieser Stelle ist die Beweisführung für den erteilten
Auftrag weitaus schwieriger und die Möglichkeit, sich nicht zu verstehen, weit-
aus größer.
Mind-Map 49
Fazit
 Der Projektauftrag ist das offizielle Projektdokument.
 Das Dokument kann in unterschiedlichen Unternehmen sehr unterschiedli-

che Ausprägungen haben und sollte daher auf den Einkauf und das jeweili-
ge Unternehmen ausgerichtet und standardisiert sein.
 Der Projektleiter wird offiziell benannt.
 Der fixierte Projektauftrag ist idealerweise am Ende der Definitionsphase

fertiggestellt und unterschrieben.
5.2 Mind-Map
Mind-Map ist ein Werkzeug, welches der Strukturierung dient. Dieses Werkzeug
findet nicht nur im Projektmanagement seinen Einsatz. Es wird in diesem Schritt
dazu benutzt, beteiligte Bereiche sowie Schnittstellen zu identifizieren und Ar-
beitspakete auf einer sehr groben Ebene abzustimmen.
Wir denken an dieser Stelle noch nicht über die Aufwände (die Zeit, die wir
brauchen, um das Arbeitspaket zu erledigen) nach, die das Arbeitspaket benötigt.
Hier geht es nur um Identifikation aller zum Projekt zugehörigen Bereiche und
deren zu leistende Arbeit für das Projekt. In dieser frühen Phase soll es dabei
unterstützen, die beteiligten Strukturen bzw. Bereiche zu identifizieren und mit
diesen abzustimmen, was getan werden muss.
Das Mind-Map und damit die Beschreibung aller Schnittstellen kann optimaler-
weise im Team erfolgen. Damit sorge ich als Projektleiter auch gleichermaßen für
eine Teambildung.
Das Ziel dieses Schrittes im Mind-Map ist die Basis für:
1. die Beteiligtenstruktur,
2. den Projektstrukturplan,
3. den Kommunikationsplan,
4. die Unterstützung des Teambildungsprozesses,
5. die Aufdeckung aller Schnittstellen, die durch das Projekt zu bedienen sind,
6. die Arbeitspakete, die auf einer sehr groben Ebene zugeordnet werden.
Fragen, die zum Mind-Map gestellt und beantwortet werden:
■ Welche Funktion (welcher Fachbereich) ist beteiligt?

■ Was muss diese Funktion zur Zielerreichung des Projektes leisten?
Das Mind-Map ist nicht zu verwechseln mit der Projektorganisation oder der
Stakeholderanalyse.
In unserer Struktur benutzen wir das Mind-Map, um eine Abgrenzung der Auf-
gaben zwischen den Bereichen abzustimmen und potenzielle Konflikte, die damit
verbunden sind, bereits in einer sehr frühen Phase anzusprechen – natürlich
auch, um einen Überblick über die Komplexität der einzubindenden Schnittstel-
len zu erlangen. In der Projektorganisation (Schritt 7, bzw. Kapitel 5.7) geht es um
die Darstellung der beteiligten Personen mit Namen und Rolle, im Mind-Map um
die Darstellung der notwendigen Fachfunktionen.
Während die Stakeholderanalyse dazu dient, zu erkennen, welche Einzelperso-

nen oder Gruppen einen Einfluss auf das Projekt haben, sind die im Mind-Map
beschriebenen Bereiche direkt für das Projekt tätig bzw. dienen als Entscheider-
gremien oder externe Dienstleister. Stakeholder beeinflussen das Projekt, sind
aber nicht zwingend am Projekt beteiligt (Beispiel: Presse, Anwohner, Umwelt-
schutz). Mit dem Mind-Map wird sichergestellt, dass Schnittstellen, die für die
Umsetzung des Projektes notwendig sind, auch eingebunden werden.
Die Verantwortlichen für Arbeitspakete finden sich sowohl im Kernteam als auch
in unterstützenden Teams (siehe Kapitel 5.7 bzw. Schritt 7 – Projektorganisation)
wieder. Hier sind auch die Entscheidergremien.
Pragmatischerweise wird den Dienstleistern oder Entscheidergremien zur besseren

Strukturierung eine andere Farbe zugeordnet. Damit ist auf einen Blick zu erken-
nen, ob eine interne oder externe Kommunikationsstruktur aufgebaut werden
muss. Das hilft mir als Projektleiter, angemessen zu reagieren und das Schnittstel-
lenmanagement und die Kommunikationswege entsprechend aufzubauen.
Fazit
 Das Mind-Map strukturiert die benötigte Fachfunktion.
 Das Mind-Map ist ein Schritt zum Basisplan.
 Es zeigt auf einen Blick alle Schnittstellen, die in den Kommunikationsfluss

eingebunden werden müssen.
 Grobe Arbeitspakete werden ohne eine Aufwandsschätzung mit den betei-

ligten Bereichen abgestimmt und selbigen auch zugeordnet.
Zielplanung 51
 Entscheidergremien werden bereits gekennzeichnet.
 Das Mind-Map visualisiert die Komplexität des anstehenden Projektes.
— Die Anzahl der Schnittstellen hängt von der Größe des Projektes ab!
— Die Arbeitspakete werden nur sehr grob eingetragen!
 Aufwände werden erst in Schritt 4 (Projektstrukturplan) abgeschätzt und in

den Basisplan eingetragen.
WER ist beteiligt = Funktionen
WAS muss getan werden = Arbeitspaket
Abbildung 5.3 Beispiel Mind-Map
5.3 Zielplanung
„Wer den Hafen nicht kennt, in den er segeln will, für den ist kein Wind ein günstiger.“
(Seneca, 1–65 n. Chr., römischer Philosoph)
Schon Seneca wusste: Ohne ein klares Ziel vor Augen sind alle Aktivitäten hinfällig.
Das Projektziel ist im Projektmanagement bereits Bestandteil des „Magischen Drei-

ecks“ und wird als Vision eines Zustandes, der in der Zukunft liegt, bezeichnet.
Wir unterscheiden zwischen dem als End- oder final beschriebenen Zustand und
den Zwischenzielen (den Meilensteinen) auf dem Weg dorthin. Um das finale
Ziel und den Abschluss des Projektes zu beschreiben, stellen wir folgende Frage:
Welcher Zustand oder welche Leistung ist zu erbringen, damit das Projekt erfolgreich
abgeschlossen ist?
Der Zustand wird auf der Zeitachse durch einen Meilenstein gekennzeichnet.
Dem Meilenstein ist immer ein fester Termin zugeordnet. Beispiel: Lieferanten-
audit ist durchgeführt: 01.06.20XX
Die Anzahl der Meilensteine dient der weiteren Strukturierung. Meilensteine

können seitens des Auftraggebers gegeben sein (z. B.: Die Verlagerung des Werk-
zeugs ist abgeschlossen: 01.07.20XX) oder intern durch den Projektleiter und das
Team selber festgelegt werden.
Wichtig ist, dass sich Auftraggeber und Auftragnehmer über den Zustand und
den Meilenstein sowohl in der Planung als auch in der Umsetzung einig sind.
Der Überprüfungsbaustein ist immer ein SMART beschriebener Meilenstein.
Die Meilensteine dienen der Steuerung. Ein weiteres Instrument hierfür ist die
Meilensteintrendanalyse.
In der Praxis ist es leider immer wieder gang und gäbe, dass Projekte ohne ein-
deutige Zielvorgabe ins Leben gerufen werden. Ist das der Fall, habe ich bereits
an dieser Stelle ein dauerhaftes Problem für mein Projekt geschaffen. Als Projekt-
leiter ist es Voraussetzung, die Ziele, so nicht eindeutig vorhanden, mit dem
Auftraggeber nochmals klar abzugrenzen.
■ Wie soll der Ist-Zustand nach Umsetzung der Projektaufgabe aussehen?

■ Was ist Projektbestandteil, was nicht?
Was aber ist ein Ziel? Allgemein gesprochen ist ein Ziel die Beschreibung eines
Zustandes, der in der Zukunft liegt, und nicht der Weg dahin.
Die Projektziele sind entsprechend des Magischen Dreiecks zu beschreiben. Wir

erinnern uns: Projekte kommen nicht plötzlich, sondern sind Bestandteil der
Unternehmensstrategie. Sie dienen der Erreichung der strategischen Ziele des
Unternehmens.
Wir fragen an dieser Stelle:
■ Welcher Zustand soll im Rahmen der Aufgabe (Projekt) erreicht werden?

■ Wann soll der Zustand erreicht sein?
■ Wie können wir diesen Zustand messen?
Zielplanung 53
In Schritt 4, dem Projektstrukturplan, werden dann die Arbeitspakete beschrie-

ben, die zur Erreichung der in Schritt 3 beschriebenen Teilziele notwendig sind.
In Schritt 5 werden sie mit der Zeitachse und den terminlichen Verbindlichkeiten
im Terminplan zusammengefügt. Diese wiederum ergeben die einzelnen Aktivi-
täten des Terminplans. Der rote Faden zieht sich vom Mind-Map bis zum Risi-
komanagement durch und wird dann im Dokument „Projektantrag“ durch die
Unterschrift zum Projektauftrag.
Je nach Projekt werden bestimmte Meilensteine vorgegeben. Für eine gute Struk-
turierung setze ich mir als Projektleiter weitere Überprüfungsbausteine, die mir
bei der Steuerung des Projektes helfen. Im Rahmen der Meilensteintrendanalyse
habe ich damit auch ein weiteres Werkzeug, mit dem ich Tendenzen und Unre-
gelmäßigkeiten des Projektes sehr schnell erkennen kann. Es setzt voraus, dass
ich in der Planung die entsprechenden Stellgrößen erfasse.
Abbildung 5.4 Meilensteine und Arbeitspakete
Definieren der einzelnen

Überprüfungsbausteine
Schritt (Meilensteine) in Schritt 3

3

Schritt Beschreiben der Arbeitspakete, die zu den

4 Meilensteinen führen, und Abschätzen der
jeweiligen Aufwände (Stunden oder
Personentage für das jeweilige Arbeitspaket)
Schritt
Im Terminplan werden die Aufwände mit
5
den Ressourcen im Kalender verknüpft.
Auch Warte- und Liegezeiten finden sich
hier wieder.
Aus den Zielen der Einkaufsorganisation leiten sich die Ziele für das Projekt ab.
Die Ziele sind organisatorisch miteinander verknüpft.
Da Projekte immer ein Bestandteil der gesamten Organisation sind, ist hier
nochmals schematisch die Struktur dargestellt. Die Ziele des Einkaufs unterstüt-
zen die gesamte Organisation. Entsprechend sind die Einkaufsprojekte hier ein-
gegliedert.
1. WAS ist das Sachziel, welches es zu erreichen gilt? Sachziel
2. WAS ist das Terminziel zum jeweilig definierten

Leistungsumfang (Sachziel)?
3. WAS ist das Kostenziel zum jeweilig definierten

Leistungsumfang (Sachziel)? Terminziel Kostenziel
Abbildung 5.5 Zielpyramide
Projektziele leisten einen Beitrag zu den Zielen des Einkaufs und kaskadieren
sich bis auf Arbeitspaketziele herunter. Auch Mitarbeiterziele sind optimaler-
weise in diese Struktur eingebunden. Der zu erreichende Zustand wird beschrie-
ben sowie Teilziele auf dem Weg dorthin.
Zielplanung 55
5.3.1 Wie wird das Projektziel beschrieben?

Ziele sind zu erarbeiten und sie nur so gut, wie sie von allen Beteiligten akzep-
tiert und getragen werden. Ist in der Praxis das finale Ziel vorgegeben und ein-
deutig beschrieben, so brechen wir es auf Teilziele SMART herunter. Ist das nicht
der Fall, so ist eine der Hauptaufgaben, aus den Anforderungen an das Projekt
das finale Ziel zu beschreiben – und dieses dann wiederum nochmals mit dem
Auftraggeber abzustimmen und im Projektauftrag zu dokumentieren. Erst wenn
das Ziel klar ist, kann ich weitere Schritte im Projektmanagement vollziehen.
■ Was muss erreicht sein, damit das Projekt erfolgreich abgeschlossen ist?
■ An welchen Ergebnissen muss sich der Projektleiter messen lassen?
■ An welchen Zielen muss sich das Projektteam messen lassen?
Was in der Theorie sehr einfach klingt, kann in der Praxis oft schwierig sein.
Bedingt durch sich gegenseitig kannibalisierende Ziele kommt es oft zu Konflik-
ten. Was für den einen Bereich ein Vorteil sein kann, kann für einen anderen
Bereich ein Nachteil sein.
Ist der günstigste Lieferant auch jener, der von der Fertigung gewollt ist? Der von
der Technik gewünschte Lieferant hingegen ist teurer als die anderen. So gibt es
zahlreiche Beispiele, in denen ein Bereich seinen Vorteil sieht, der andere Bereich
aber eher einen Nachteil im Sinne der eigenen Zielerreichung. Zu lösen ist die
Thematik nur, wenn alle bereit sind, bei der Konfliktlösung im Sinne aller Betei-
ligten mitzuwirken. Auch hier gilt wieder – Kommunikation, Kommunikation
und nochmals Kommunikation. Nur sprechenden Menschen kann man helfen,
sagte einmal ein Bekannter. Dies gilt auch für das Projekt!
Mit der Zielbeschreibung im Team gelingt es oft, Konflikte zu besprechen, solan-

ge die Realität in der Umsetzung des Projektes uns noch nicht eingeholt hat. Mit
der gemeinsamen Zieldefinition bzw. der gemeinsamen Definition der Meilen-
steine treiben wir auch das Wir-Gefühl im Team voran. So können hier schon
Maßnahmen ergriffen werden, die den weiteren Ablauf des Projektes im Team
reibungsloser gestalten.
Ziele werden gemeinschaftlich erarbeitet und verabschiedet. Dies ist kein rei-
bungsloser Prozess und setzt klare Kommunikation und Abstimmungen voraus.
Zielplanung
 Die Auftragsklärung in der frühen Phase des Projektes ist mit dem Auf-
traggeber sauber zu fixieren. Wenn es hier Differenzen gibt, ziehen diese
sich durch das gesamte Projekt. Die Ziele ergeben sich aus den Anforde-
rungen an das Projekt und sind somit nur zu beschreiben, wenn der Auf-
trag geklärt ist. Alles im Projektmanagement ist ein Prozess und baut aufei-
nander auf.
 Es ist darauf zu achten, dass die Ziele sich nicht gegenseitig kannibalisieren,
da es zwischen den Bereichen ansonsten immer wieder zu Reibungspunk-
ten kommt.
 Die Erreichbarkeit der Ziele sollte abgestimmt sein. Ziele im Projekt sind
immer eine Herausforderung. Sollte allerdings von vornherein klar sein,
dass ein Ziel nicht zu erreichen ist, gilt es auch hier, eine Lösung im Sinne
des Projektes zu finden.
 Um die Ziele zu definieren, benötigen wir den richtigen Teilnehmerkreis.

Wenn möglich, werden Ziele mit den Teilnehmern definiert, die diese auch
im weiteren Verlauf des Projektes umsetzen müssen.
 Ziele sollten von allen Projektbeteiligten „getragen“ werden.
 Die Ziele sollten realistisch sein und nicht zu optimistisch. Niemandem ist
gedient, wenn das Projektziel nicht erreicht werden kann.
Da in einem Projekt die Arbeitspakete und damit auch die dazugehörigen Abtei-
lungen voneinander abhängig sind, ist immer Teamarbeit Voraussetzung für den
Projekterfolg. Setzt ein Part seine Forderungen permanent zulasten der anderen
Bereiche durch, wird früher oder später der Projekterfolg gefährdet sein. Die
zwischenmenschlichen Beziehungen sind ein wesentlicher Faktor für die erfolg-
reiche Zielumsetzung.
5.3.2 SMART-Regel
Ziele sind wichtig, um sich auf einem Weg von einem Ist- zu einem Soll-Zustand
nicht zu verirren oder zu verlaufen. Ziele beschreiben dabei aber nicht den Weg,
sondern einen konkreten, zu erreichenden Zustand. Um diesen zu erreichenden
Zustand präzise, einheitlich und auf den Punkt für jeden verständlich zu be-
schreiben, wurde die SMART-Formel entwickelt.
Zielplanung 57
SMART steht dabei für spezifisch, messbar, attraktiv, realistisch, terminiert.

SMART ist kein genormter Begriff, sondern hat ab und an Abwandlungen bei
Themen wie „attraktiv“ – hier wird auch gern „anspruchsvoll“ genommen (im
Englischen oft achivable = erreichbar).
Im Projektmanagement gibt es jedoch nicht nur das übergeordnete Ziel, sondern

auch, wie bereits beschrieben, viele Teilziele. Auch diese kleinen Zwischenziele –
meist mit Meilensteinen verbunden – sowie Nicht-Ziele (was darf nicht erreicht
werden/Abgrenzung), Kommunikationsziele, Qualitätsziele, Termin- und Zeitzie-
le sowie Kosten- und Ressourcenziele können durch die SMART-Formel verein-
facht und präzisiert werden.
5.3.3 Definition, Begriffserklärung und

SMART-Beispiel
Die Abkürzung SMART, oder auch S.M.A.R.T. (Quelle: Partizipative Qualitäts-
entwicklung 2008, http://www.partizipative-qualitaetsentwicklung.de/subnavi/
methodenkoffer/smart-kriterien.html, Zugriff am 03.09.2016), steht für:
■ spezifisch
■ messbar
■ attraktiv
■ realistisch
■ terminiert
Spezifisch (specific oder alternativ: significant, simple)
Ein „schönes“ Auto, ein „guter“ Prozess, „hohe“ Savings sind an dieser Stelle
keine hilfreichen Beschreibungen. Wenn wir über ein schönes Auto nachdenken,
so wünscht sich manch ein kleines Mädchen vielleicht ein pinkfarbenes Fahrzeug
mit Prinzessin Lillifee. „Schön“ liegt eben im Auge des Betrachters, so wie auch
„gut“ und „hoch“. Daher möchten wir bei der Beschreibung ein klares Verständ-
nis bekommen, was sich hinter diesen Begriffen verbirgt. Eine Farbe ist dann
nicht nur schön, sondern wird bei der Zielbeschreibung in RAL und damit mess-
bar angegeben. Ein guter Prozess wird mit messbaren Kennzahlen hinterlegt,
hohe Savings ebenso. Alles wird konkret beschrieben, so dass die Ergebnisse
jederzeit nachvollziehbar und messbar sind.
Messbar (measurable oder alternativ: meaningful)

An jenen messbaren Parametern, welche Sie in Ihr Ziel einbauen, können Sie
jederzeit abgleichen, ob Sie auf dem richtigen Weg sind oder ein Ziel eventuell
bereits erreicht wurde. Bedenken Sie: Was man nicht messen kann, kann man
nicht erreichen – das gilt beim Sport wie auch im Projekt.
Attraktiv (accepted oder auch: agreed, actionable, attainable, achievable)

Unter „attraktiv“ wird die Motivation verstanden, warum etwas zu tun ist.
Nichts ist im Arbeitsalltag demotivierender (außer sinnlose und langweilige
Besprechungen), als etwas tun zu müssen, was nicht mit den persönlichen Zielen
übereinstimmt – oder bei dem man das „Wofür“ erst gar nicht erkennt. Zugege-
ben: Das Berufsleben ist kein Ponyhof und wir müssen uns täglich mit fremdbe-
stimmten Zielen abgeben, aber geben Sie als Projektleiter wenigstens das „Wa-
rum“ weiter. Ziele wollen erreicht und nicht verwaltet werden.
Realistisch (realistic oder alternativ: reasonable, relevant, resonant)

Sie wollen ein Haus bauen, in einem Monat fertig sein und 50 Prozent in Eigen-
leistung erbringen? Auch das ist unrealistisch – es sei denn das Haus ist eine
Hundehütte.
Terminiert (time-bound oder auch: time-framed, time-based, time-boxed,

trackable)
Ziele benötigen einen Zeitbezug – in unternehmerischen Zielerreichungs-
workshops/-gesprächen meistens ein Jahr –, die Angabe „in einem Jahr“ ist aller-
dings kein geltender Zeitbezug und nicht SMART-Ziel-konform. Wer sein Ziel
mit „in einem Jahr“ beschreibt, hat jeden neuen Tag wieder genau ein Jahr Zeit –
das wäre geschummelt. Setzen Sie also ein konkretes Enddatum, an welchem die
oben definierten Endparameter spätestens eingetreten oder erreicht sein sollen.
5.3.4 Meilensteine
Meilenstein ist einer der gängigsten Begriffe in der Zielplanung und im Pro-
jektmanagement. Dies ist laut Definition die Beschreibung eines Ereignisses
besonderer Bedeutung. Wichtig ist hier das Wort Ereignis. Es handelt sich um
die Beschreibung einer Situation. Der Weg dahin ist an dieser Stelle noch nicht
zwingend deutlich. In der Guideline des amerikanischen PMI und deren Project
Management Body of Knowledge wird der Meilenstein als „Completion of an
important deliverable“ beschrieben, gleichzusetzen mit der Erreichung eines
wichtigen Teilergebnisses. Hierbei kann man zwei Meilensteinarten unter-
scheiden:
Zielplanung 59
1. die sogenannten verpflichtenden Meilensteine, die sich aus der Vertragsver-

einbarung ergeben (z. B.: Lieferant hat sich verpflichtet, am Tag x eine ent-
sprechende Anzahl Erstmuster zu liefern),
2. die optionalen Meilensteine, die wir selbst als für uns im Prozess wichtigen
Überprüfungsbaustein definieren (z. B.: Abstimmung mit anderen Bereichen
abgeschlossen, Freigabe-Dokument ist erstellt).
Die Definition von Meilensteinen ist Bestandteil der Zielplanung. Meilensteine

sind sowohl in kleinen als auch in großen Projekten notwendig. Meilensteine sind
Überprüfungsbausteine auf dem Weg zum Gesamtziel. Meilensteine teilen den
gesamten Prozess in überschaubare Etappen. Sie geben uns die Möglichkeit, in
das Projekt steuernd einzugreifen. Genauso wie ich beim Bergsteigen Etappenzie-
le festlege, lege ich im Projekt Meilensteine fest und habe mir somit die Möglich-
keit geschaffen, an diesen Stellen des Projektes zu überprüfen, ob ich im Rahmen
der Anforderungen hinsichtlich Terminen, Kosten und zu erfüllendem Leis-
tungsumfang noch auf dem richtigen Weg bin. Meilensteine sind entsprechend
auch zeitlich definiert. Sie haben immer ein Datum und sind kein Zeitraum. So
wie bei einem Hausbau das Richtfest ein Überprüfungsbaustein sein kann, sind
es bei technischen Projekten klassische Meilensteine, z. B. Design Freeze, Verga-
betermine, Prototypen-Tests, Freigabe von Erstmustern etc. Bei Prozessänderun-
gen kann dies „Ist-Aufnahme abgeschlossen“, „Prozesse abgestimmt“, „Prozess
freigegeben“ sein, um nur einige Beispiel an dieser Stelle zu nennen. Im weiteren
Verlauf der Umsetzung des Projektes werden die Meilensteine auch als Steue-
rungsinstrument benutzt.
Abbildung 5.6 Elemente Meilensteine
Meilenstein

Input = Was benötigt Output – deliverable aus

das Ereignis, um dem erfüllten Ereignis.

erfüllt werden zu Prozess benötigt das
können? Ergebnis, um weiterlaufen
zu können.
Meilensteine sind Punkte, die besonders kritisch sind und die einen Wendepunkt
im Verlauf des gesamten Projektes darstellen können, da der weitere Ablauf vom
Erreichen dieses Meilensteins abhängt. Es sind daher kleine Zwischenziele, die
erreicht werden müssen, um ein Projekt erfolgreich durchzuführen oder eventu-

ell vorzeitig abzubrechen, bevor schon zu viel investiert wurde. Solch ein Wen-
depunkt kann zum Beispiel die Zusage eines wichtigen Teilhabers oder Geldge-
bers des Projekts sein, eine Lieferung oder der Erfolg eines Versuchs, der über
den weiteren Fortgang des Projekts entscheidet.
Fazit
 Meilensteine dienen der Einteilung des Projektes in kleinere Etappen.
 Meilensteine geben die Möglichkeit, das Projekt zu steuern und Abwei-

chungen oder Fehlplanungen frühzeitig entgegenzuwirken.
 An jedem Meilenstein muss überprüft werden können, ob der Basisplan mit

der aktuellen Umsetzung noch übereinstimmt.
 Meilensteine sind Entscheidungshilfen, um deutlich zu machen, ob Ände-

rungen bzw. Anpassungen notwendig sind.
 Meilensteine dienen der Berichterstattung an den Auftraggeber.
 In der sogenannten Meilensteintrendanalyse lassen sich Meilensteine und

deren Aktivitäten einfach überwachen.
5.3.5 Meilensteintrendanalyse
Das Steuerungsinstrument für die Meilensteine ist die sogenannte Meilenstein-
trendanalyse. Fast alle Meilensteine liegen auf dem sogenannten kritischen Pfad.
Das heißt, bei Nichterfüllung des Meilensteins zum entsprechenden Termin ist
von einer zeitlichen Verschiebung im Projekt auszugehen. Dies wiederum spie-
gelt sich in der Meilensteintrendanalyse wider. Eine Erläuterung der Methode
erfolgt in Kapitel 9.3.
Hier ein kurzer Auszug aus dem Projektmanagement-Handbuch (Quelle: True

Care GmbH, Projektmanagement Handbuch online; http://www.projekt-
managementhandbuch.de/projektrealisierung/meilensteintrendanalyse/, Zugriff
am 03.09.2016), um an dieser Stelle die Wichtigkeit des Strukturierens über Mei-
lensteine darzustellen.
„Die Meilensteintrendanalyse ist ein vorwärts gerichtetes Controllinginstrument.

Mit ihrer Hilfe ist es möglich, Meilensteinverschiebungen so rechtzeitig zu visua-
lisieren, dass ein Eingreifen oft noch möglich ist und auf diese Art und Weise
bevorstehende Verzögerungen im Projektablauf vermieden werden können. Im
Der Projektstrukturplan (PSP) 61
Rahmen der Meilensteintrendanalyse werden die einzelnen Meilensteintermine

jeweils zum Berichtszeitpunkt auf der Hochachse aufgetragen. Fragestellung zu
jedem Berichtszeitpunkt muss sein, wann der jeweilige Meilenstein aus aktueller
Sicht erreicht sein wird. Diese Einschätzungen werden jeweils über die verschie-
denen Berichtszeitpunkte zu einem Trend verbunden. Verantwortlich für die
Erstellung einer Meilensteintrendanalyse ist in der Regel die Projektleitung. Diese
fordert die jeweils notwendigen grundlegenden Informationen von den Beteilig-
ten ab bzw. wird proaktiv von diesen beliefert.“
5.4 Der Projektstrukturplan (PSP)

Der Projektstrukturplan ist das Herzstück der Planung. In der Zielplanung legen
wir das zu erwartende Ergebnis fest, den Zielzustand, den es zu erreichen gilt. Über
die Meilensteine beschreiben wir die auf dem Weg liegenden Teilergebnisse.
Der fertige Projektstrukturplan enthält alle Arbeitspakete, die für die Erreichung
der vorab definierten Ziele notwendig sind.
Abbildung 5.7 Zusammenhang Meilensteine und Arbeitspaket
Aus den Meilensteinen, den Arbeitspaketen und den zur Verfügung gestellten
Ressourcen können wir im Verlauf der Planung den Terminplan erstellen.
Im Projektstrukturplan sollten alle Arbeitspakete beschrieben sein, die für die

vollständige Umsetzung des Projektes und dementsprechend zur Erreichung der
Ziele notwendig sind. Für die Arbeitspakete wird abgeschätzt (Zeit und Kosten),
welcher Aufwand für die jeweilige Umsetzung notwendig ist.
Nach der reinen Lehre umfasst der PSP die vollständige Darstellung eines Projek-
tes sowie aller Teilprojekte, Teilaufgaben und Arbeitspakete. Der im Englischen
als „work breakdown structure“ bezeichnete Projektstrukturplan dient der kom-

pletten Gliederung des Projektes. Der Projektstrukturplan mit seiner Untergliede-
rung in einzelne Elemente bildet die Grundlage für eine Arbeitsteilung im Pro-
jekt. Elemente wie Teilprojekte und Arbeitspakete werden direkt Funktionen und
Teammitgliedern zugeordnet.
Bereits im Mind-Map wurden Abgrenzungen zu großen Arbeitspaketen zwischen

den Funktionen geklärt. Wer ist für welche Aufgabe verantwortlich, ist die Frage im
Mind-Map. Darauf basierend werden im Projektstrukturplan die konkreten Auf-
wände in Form von Stunden oder Tagen zugeordnet. Wie lange benötigt eine Per-
son, um die Umsetzung des Arbeitspaketes zu gewährleisten? Dies erfolgt mit den
Arbeitspaketverantwortlichen gemeinsam und dient daher auch der Klärung mögli-
cher Konflikte oder Unstimmigkeiten in einer sehr frühen Phase des Projektes.
Konkret bespricht man mit den Verantwortlichen des jeweiligen Fachbereichs die
für das Projekt notwendigen Tätigkeiten und leitet die Aufwände ab. Mit den
Führungskräften der Fachbereiche wird abgeklärt, ob für den entsprechenden
Zeitraum die notwendigen Ressourcen bereitgestellt werden können.
Der Projektstrukturplan kann je nach Projekt unterschiedliche Gliederungsfor-

men haben:
■ funktionsorientiere Gliederung,
■ objektorientierte Gliederung,
■ phasenorientierte Gliederung.
Die Form der Gliederung sollte je nach Projekt getroffen werden. In einem Reor-
ganisationsprojekt zum Beispiel ist die Funktions- oder phasenorientierte Gliede-
rung bevorzugt anzuwenden, in einem Projekt, in dem ein Produkt neu entwi-
ckelt wird, wird eher eine objektorientierte Anordnung bevorzugt. Im Anschluss
werden die einzelnen Arbeitspakete in einem sachlichen und/oder zeitlich logi-
schen Zusammenhang verknüpft – der sogenannten Anordnungsbeziehung.
Fazit
 Darstellung der vollständigen Projektstruktur
 Vorgabe einer Struktur für alle Arbeitspakete des Projektes
 vollständige Darstellung des notwendigen Leistungsumfangs
 Verantwortlichkeiten des jeweiligen Arbeitspakets festlegen

 Zuordnung des Aufwands für das jeweilige Arbeitspaket
 Bestimmung aller zum Projekt gehörenden Arbeitspakete (Kostenträger)
 Ordnen und Strukturieren der Arbeitspakete in einer geeigneten Systematik

(Kostenträgerstruktur)
 Schaffung von Transparenz gegenüber allen Projektbeteiligten
 Die Struktur kann je nach Projekt unterschiedlich sein: funktionsorientiert,

fachbereichsorientiert, technisch orientiert.
5.4.1 Funktionsorientierte Gliederung

In der funktionsorientierten Gliederung werden den einzelnen Fachfunktionen
des Unternehmens die jeweiligen Arbeitspakete in den bereits definierten Phasen
zugeordnet. Als Projektleiter wird in der Definitionsphase bereits über Ver-
gleichswerte grob abgeschätzt, wie lange Teilprojekte dauern könnten (Top-
down-Schätzung). Im weiteren Verlauf sind bereits weitere und detailliertere
Informationen über die umzusetzende Aufgabe vorhanden, so dass nun gemein-
schaftlich mit den benannten Verantwortlichen der Fachbereiche eine Abschät-
zung auf Arbeitspaketebene möglich sein sollte. Gemeinschaftlich mit dem Team
werden folgende Fragen beantwortet:
■ Welche Aufgaben entstehen in den einzelnen Phasen?

■ Wie viel Zeit wird in den einzelnen Fachbereichen benötigt, um das Arbeits-
paket wie beschrieben umzusetzen?
Bei der Abschätzung der Zeit sprechen wir nur über die reine Arbeitszeit und
noch nicht über den Zeitraum, der für die Umsetzung benötigt wird. So braucht
ein Einkäufer für die Anfrage bei Lieferanten und die entsprechenden Verhand-
lungen beispielsweise an absolutem Aufwand sechs Arbeitstage, für die Abwick-
lung des Arbeitspaketes jedoch zwei Monate (die Lieferanten, die angefragt wer-
den, müssen ausgewählt werden, Angebote werden angefragt, bis zur Rückmel-
dung vergeht ein bestimmter Zeitraum ... danach wird verhandelt, eventuell der
in Frage kommende Lieferant besucht etc.).
Im Projektstrukturplan wird die absolut notwendige Arbeitszeit betrachtet, im Ter-

minplan spiegelt sich dann die Durchlaufzeit bzw. Zeitspanne wieder. Diese basiert
auf der Planung im Projektstrukturplan, den vorhandenen Ressourcen und der soge-
nannten Liegezeit (= Warten auf die Antwort der Lieferanten, in der für dieses Projekt
gerade nicht aktiv gearbeitet wird; siehe Kapitel 5.5, bzw. Schritt 5 – Terminplanung).
Abbildung 5.8 Funktionsorientiert gegliederter Projektstrukturplan
Erstellen des Projektstrukturplans in der Praxis:
1. Aus dem Mind-Map werden die bereits ermittelten Fachbereiche in den PSP
übertragen.
2. In einem Workshop mit allen Beteiligten oder aber auch in Einzelgesprächen

werden die jeweiligen pro Phase anfallenden Arbeitspakete ermittelt.
3. Für die ermittelten Arbeitspakete werden die pro Fachbereich und Arbeitspa-
ket notwendigen Aufwände in Form von Stunden oder Tagen eingetragen.
4. Im weiteren Verlauf und zur Erstellung des Terminplans wird mit den Füh-
rungskräften der Fachbereiche abgestimmt, ob die Ressourcen auch für den
entsprechenden Zeitraum zur Verfügung gestellt werden können.
5.4.2 Objektorientierte Gliederung

Die objektorientierte Gliederung ist dann hilfreich, wenn Projekte in Teilprojekte
gegliedert werden. Die Größe des Projektes ist dann auch entsprechend. Bei der
objektorientierten Gliederung erfolgt die Strukturierung nach den einzelnen
Bestandteilen (Objekten), die für das Projekt benötigt werden. Dieses Verfahren
wird meistens dann benutzt, wenn das Projekt die Herstellung eines Produktes
zum Ziel hat, wie beispielsweise den Bau eines Hauses oder die Entwicklung
bzw. Änderung eines technischen Produktes. Dies bezieht sich auf die Auto-
mobilbranche genauso wie auf den Anlagenbau. Die Zerlegung erfolgt dann nach
der technischen Struktur des zu erstellenden Produktes. Design-to-Cost-Program-

me im Einkauf haben oft technische Änderungen zur Folge, die sich über die
objektorientierte Gliederung gut darstellen lassen.
Abbildung 5.9 Objektorientiert gegliederter Projektstrukturplan
5.4.3 Phasenorientierte Gliederung

Als dritte, häufig anzutreffende Gliederungsform ist die phasenorientierte Glie-
derung zu nennen. Hier werden die Phasen eines Projektes zur Gliederung zu-
grunde gelegt.
Abbildung 5.10 Phasenorientiert gegliederter Projektstrukturplan
Es gibt bei der Gliederung kein „Richtig“ oder „Falsch“. Der Vorteil der objekt-
orientierten Gliederung ist z. B. bei großen Projekten eine klare Untergliederung
in Teilprojekte bereits in der frühen Phase – die Delegation ganzer Komponenten
an Teilprojektleiter, die dann wiederum eine Untergliederung in ihre gröberen
Arbeitspakete unternehmen können.
Dafür liefert der funktionsorientierte Plan auf einen Blick die notwendigen Auf-
wände je Phase und Funktion.
Alle Varianten sollen im weiteren Verlauf des Projektes einer guten Steuerung
und Anpassung vom Basisplan dienen.
Das Ziel aller Varianten ist immer das gleiche: Ein Projekt soll durch die Gliede-
rung in überschaubare, besser zu handhabende Arbeitspakete untergliedert wer-
den. Am Anfang des Projektes, während wir noch wenig Wissen über die Detail-
lierung haben, schätzen wir, wie beschrieben, auf Basis von vergleichbaren Pro-
jekten. Dann erlangen wir mehr Wissen über die Aufgabe und sind in der Lage,
mit den entsprechenden Know-how-Trägern aus den Fachbereichen eine Planung
über detaillierte Arbeitspakete durchzuführen.
Auch weitere anfallende Aufwände werden im Rahmen der Kostenplanung

(siehe Kapitel 5.6, bzw. Schritt 6 – Kostenplanung) auf den Arbeitspaketen zu-
geordnet.
Der Detaillierungsgrad der Arbeitspakete hängt von folgenden Faktoren ab:
1. Große Arbeitspakete:
 Der Arbeitspaket-Verantwortliche operiert mit hohem Erfahrungswert.
 Die Firma hat sehr viel Erfahrung mit dieser speziellen Aufgabe.
 Das Projekt ist in einer sehr frühen Phase und die notwendigen Informatio-
nen sind noch nicht vorhanden.
 Es ist im Sinne der Zielerreichung nicht notwendig, auf Mikroebene zu ar-

beiten.
2. Kleine Arbeitspakete
 Es ist notwendig, sehr detailliert die Kosten und Termine überwachen und
steuern zu können.
 Der Erfahrungswert mit diesem speziellen Projekt ist sehr gering.
 Es wird Klarheit über jedes einzelne Vorgehen im Projekt erwartet.
 Es liegt ein sehr hoher Termindruck auf dem Projekt.
 Das Teammitglied ist neu und nicht so vertraut mit dem Inhalt.
Um bereits in der Planung des Projektes Klarheit über Rollen und Verantwort-
lichkeiten zu bekommen, ist es als Projektleiter hilfreich, einen Vorschlag für den
Projektstrukturplan zu entwickeln, diesen aber dann mit dem Team gemeinsam
zu validieren und anzupassen. Dies kann in einer gemeinsamen Besprechung
oder auch in einem Workshop stattfinden. Wann immer das Team etwas zusam-
men erarbeitet, wird auch der für die Umsetzung notwendige Teamspirit verbes-
sert. Alle Planungen sind nur so gut, wie sie von den entsprechend beteiligten
Teammitgliedern auch getragen werden.
Im weiteren Verlauf dient der Projektstrukturplan als Steuerungsinstrument. Er

ist Bestandteil des Basisplans. Damit ist er auch gleichzeitig Basis für ein eventu-
ell anfallendes Änderungsmanagement. Im Rahmen der Projektsteuerung wer-
den die Bestandteile des Projektstrukturplans zeitlich, inhaltlich und kostenmä-
ßig verglichen.
Der Projektstrukturplan bildet den Kern des Projektes. Er ist das Referenzdoku-
ment für jede weitere Tätigkeit sowohl in der Planung als auch in der Umsetzung
des Projektes.
Der Detaillierungsgrad steht damit auch im direkten Zusammenhang mit dem

Controlling-Bedarf. Der Projektstrukturplan ist die Basis für
■ den Kommunikationsplan,
■ den Terminplan,
■ den Kostenplan,
■ die nochmalige Klärung von Rollen in Form von Aufgabe, Verantwortung
und Entscheidungskompetenz.
Der Projektstrukturplan ist ein hilfreiches Werkzeug, um in cross-funktionalen

Teams die Commitments der Teammitglieder für ihre jeweiligen Zuständigkeiten
zu erhalten.
5.4.4 Arbeitspaket
Das Arbeitspaket (Abbildung 5.11) ist die unterste Ebene im Projektstrukturplan
und liegt in der Verantwortung des jeweiligen Projektteammitglieds.
 Der Projektstrukturplan beinhaltet alle Arbeitspakete, die zur Zielerrei-

chung notwendig sind.
 Er ist die Ausgangsbasis, auf der die weiteren Steuerungsinstrumente Ter-

min- und Kostenplan entwickelt werden.
 Abgrenzungskonflikte (Verantwortlichkeiten für die Arbeitspakete) werden

in einer frühen Phase angesprochen und geklärt.
 Der Detaillierungsgrad hängt davon ab, was genau der Projektleiter für die
Steuerung des Projektes später benötigt.
 Die Verantwortlichkeiten werden hier bereits zugeordnet. Im weiteren Ver-

lauf ist es nur noch eine Frage der Umsetzung.
 Jedes Arbeitspaket ist mit Terminen, Kosten und Leistungsumfang abge-

grenzt.
 Die Arbeitspakete sind entsprechend der fachlichen Inhalte den jeweiligen

Verantwortlichen zugeordnet.
 Die Arbeitspakete sind mit den Verantwortlichen abgestimmt.
 Die Arbeitspakete werden durch die sogenannten Anordnungsbeziehungen

verknüpft.
Terminplanung 69
Abbildung 5.11 Arbeitspaket
5.5 Terminplanung
Ein zentrales Element der Terminplanung ist, wie das Wort schon sagt, der Ter-
min. Nach DIN 69900 wird ein Termin als ein „durch Kalendertag und/oder Uhr-
zeit ausgedrückter Zeitpunkt“ definiert. Weiter sind Vorgänge, d. h. (Arbeits-
)Abläufe, ein zentrales Element.
Jedes Arbeitspaket benötigt eine gewisse Zeitdauer, welche über Aufwand- oder
Leistungswerte oder durch Expertenwissen festgelegt werden kann. Im Projekt-
strukturplan werden alle Aktivitäten und Arbeitspakete ermittelt und die Auf-
wände mit Experten gemeinsam bewertet. Im Terminplan werden diese mit den
Meilensteinen und dem Kalender zusammengeführt.
Die Verbindung von Meilensteinen, den jeweiligen Arbeitsschritten, die sich im

Projektstrukturplan mit entsprechenden Aufwänden spiegeln, stellen im Termin-
plan nun die Zeiträume dar.
Im Projektstrukturplan sehen wir nur die absoluten Aufwände. Für einen guten
Terminplan benötigen wir zusätzlich den Kalender, Liegezeiten, verfügbare Res-
sourcen, entsprechende Feiertage und sonstige Informationen, die uns hinsicht-
lich der Termine begrenzen.
Folgende Informationen werden als Input für eine Terminplanung benötigt:
■ Aufwand und Dauer eines Arbeitspaketes

■ Kalender
■ Wartezeiten
■ Liegezeiten (z. B. Warten auf Antwort des Lieferanten, Trocknen von Farbe ...)
■ vorhandene Ressourcen
■ Meilensteine
■ Urlaub
Die Schätzungen können, je nach Projektstand, unterschiedlich ausfallen. Im
Folgenden finden wir eine kurze Beschreibung der jeweiligen Möglichkeiten, zu
realistischen Abschätzungen zu kommen.
5.5.1 Analoge Abschätzung

In der frühen Phase des Projektes erfolgt die Abschätzung über die sogenannte
analoge Schätzung. Die analoge Schätzung (Analogous Estimating) hilft, ein
geplantes oder sich im Anfangsstadium stehendes Projekt partiell zu bewerten.
Als Grundlage für dieses Verfahren werden bekannte Größen aus ähnlichen und
bereits abgeschlossenen Projekten herangezogen. Diese bekannten Kenngrößen
beziehen sich z. B. auf das Volumen, den Arbeitsaufwand, den Zeitumfang und
den Etat eines Projektes. Wir analysieren an dieser Stelle auf Basis von Erfah-
Terminplanung 71
rungswerten und ziehen Vergleiche zum aktuellen Projekt. Anhand dieser quan-
titativen und inhaltlichen Erfahrungswerte lassen sich Ableitungen und Vorher-
sagen für dieselbe Art von Kenngrößen für das geplante Projekt herstellen.
Analoge Schätzungen werden zu einem Zeitpunkt vorgenommen, zu dem für ein

Projekt erst wenig inhaltliche Angaben und genaue Informationen zur Verfügung
stehen. Diese Abschätzung ist in einer frühen Phase des Projektes sinnvoll. Auf
Basis von Vergleichsdaten bekommt man eine realistische Planung. Diese wird
im weiteren Projektverlauf durch Bottom-up (über Arbeitspakete) verifiziert.
5.5.2 Bottom-up-Schätzung
Erst im weiteren Verlauf, wenn mehr Informationen zum Projekt vorhanden sind
und wir die Arbeitspakete definiert haben, kann eine Schätzung von unten, also
Bottom-up geschehen.
Darunter versteht man die detaillierte Projektplanung nach dem „Von-unten-

nach-oben-Prinzip“ oder auch Bottom-up. Hier wird die Komponente der Arbeit
in detaillierte Arbeitspakete eingeteilt. Die Tätigkeiten, Abläufe, Zeitplanungen
und Kosten vom Projektmanagement werden nicht auf der Projektebene detail-
liert durchgeplant, sondern von den jeweiligen Arbeitspakten aus.
Nach der groben Projektplanung, d. h. nach der Definition von Ober- und Unter-
projekt ohne die genaue Zeit- und Kostenplanung, werden konkret die Arbeits-
pakete genau beschrieben. Das Projektmanagement bestimmt die internen und
externen Kosten durch die Auswahl von Projekt, Mitarbeitern, Tätigkeit. Diese
Werte werden im Bottom-up-Prinzip den zugeordneten Projekten zugerechnet
und auf die nächste Projektebene hochgereicht.
Alle internen und externen Kosten eines Unterprojektes werden dann zum jewei-
ligen Oberprojekt hochgestuft, bis das Top-Projekt, quasi die Wurzel des Projekt-
baums, erreicht ist. Allerdings ist für die Bottom-up-Schätzung Voraussetzung,
dass wir bereits alle notwendigen Informationen zusammenstellen konnten, um
detailliert mit den Experten gemeinsam die Abschätzung auf Arbeitspaket-Ebene
durchzuführen.
5.5.3 Activity Sequencing oder das Festlegen von

Arbeitsfolgen
Hierbei werden im Wesentlichen zwei Fragen gestellt:
■ Welches Arbeitspaket kommt zuerst?

■ Was kann auf Basis von technischen oder zeitlichen Abhängigkeiten folgen?
Ein einfaches Beispiel: Der Lieferant muss ausgewählt sein, bevor ich den Vertrag
abschließen kann. Ich kann kein Dach auf ein Haus setzen, bevor der Rohbau
nicht fertig ist.
Die Gesamtheit aller Arbeitspakte wird auf diese Art zusammengefügt: Vorrau-
setzung, um die Aktivität starten zu können (Input); Durchführen des Prozess-
schrittes (Arbeitspaket); Output – Wie sieht das Ergebnis aus bzw. was kommt
heraus und womit kann weiter gearbeitet werden?
Abbildung 5.12 Anordnungsbeziehung bei Arbeitspaketen
Die Verknüpfung der Aktivitäten erfolgt im Terminplan. Hier werden die Vor-
gänger- und Nachfolgerbeziehungen angeordnet. Diverse Terminplanungssys-
teme sind dabei hilfreich.
Die Meilensteine extern und intern werden eingesetzt. Alle im Projektstruktur-

plan festgelegten Arbeitspakete werden mit den vorhandenen Ressourcen zu-
sammengefügt und in den Terminplan übertragen. Für eine gute Terminplanung
ist auch die Hinterlegung des Kalenders notwendig. Der hinterlegte Kalender
sorgt für einen Übergang von absoluten Tagen und Aufwänden, die geschätzt
wurden, zu den realistischen Tagen, die für die Arbeitsleistung zur Verfügung
stehen. Bei internationalen Projekten ist auf die unterschiedlichen Arbeitstage
bzw. Feiertage zu achten.
Terminplanung 73
Der Terminplan kann unterschiedlich dargestellt werden. Es ist hilfreich, ein

EDV-Tool zu benutzen, da bei Änderungen auch sofort die entsprechenden
Auswirkungen auf den gesamten Terminplan zu erkennen sind.
Die Darstellung erfolgt entweder im sogenannten Gantt-Chart oder dem Netzplan.
5.5.4 Terminplan als Beispiel-Berechnung von

zehn Arbeitspaketen mit progressiver und
retrograder Kalkulation
Die Arbeitspakete werden im PSP benannt und abgeschätzt und in der Anord-
nungsbeziehung mit Vorgängerbeziehungen verknüpft. Daraus entstehen die
sogenannte progressive Kalkulation = Vorwärtsrechnung und die sogenannte
retrograde Kalkulation = Rückwärtsrechnung.
Das System führt beide Rechnungen aus, um den kritischen Pfad zu ermitteln.
SE – FE (spätestes Ende – frühestes Ende) ergibt die Pufferzeit. Ist die Pufferzeit
gleich null, so heißt das: Jede Verschiebung würde ohne Anpassung sofort zu
einer Verschiebung des Endtermins führen.
Tabelle 5.1 zeigt beide Berechnungen. Ist die Vorwärtsrechnung abgeschlossen, so

wird der FE auch als SE gesetzt. Bei der Rückwärtsrechnung bezieht sich das Sys-
tem auf die Nachfolger und nicht auf die Vorgänger wie bei der Vorwärtsrechnung.
Tabelle 5.1 Berechnungen
No. Arbeitspaket V N D FA FE SA SE P
Entwicklung
2,3,4,
1 und Zeich- – 14 1 14 1 14 0
5,6,7,8
nung
Review
2 1 9 2,5 14 16,5 46,5 49 32,5
Zeichnung
Prototypen-
3 1,4 5 17 26 43 29,5 46,5 3,5
test
Vorbereitung
4 1 3 12 14 26 17,5 29,5 3,5
Bestellung
5 Qualitätstest 1,3 9 2,5 43 45,5 46,5 49 3,5
No. Arbeitspaket V N D FA FE SA SE P
Einbau in der
6 1 9 35 14 49 14 49 0
Fertigung
7 Gate Review 1 – 1 14 15 52 53 38
Test der Teile
8 1 9 4,5 14 18,5 44,5 49 30,5
beim Kunden
Workshop
2,6,
9 beim Kunden 10 3 49 52 49 52 0
5,8
und Übergabe
Dokumen-
10 9 – 1 52 53 52 53 0
tation
Die Tabelle zeigt:
Spalte 1: Nummerierung
Spalte 2: Arbeitspakete – aus dem PSP entnommen
Spalte 3: V = Vorgänger – definiert
Spalte 4: N = Nachfolger – definiert
Spalte 5: Dauer des Arbeitspaketes – aus PSP
Spalte 6: FA = Frühester Anfang – Termin kann gesetzt werden
Spalte 7: FE = Frühestes Ende – ermittelt das System
Spalte 8: SA = Spätester Anfang – ermittelt das System
Spalte 9: SE = Spätestes Ende – ermittelt das System
Spalte 10: P = Pufferzeit – ermittelt das System aus SE – FE
Ist der Puffer gleich null, so befindet sich das Projekt mit seinen Vorgängen auf
dem sogenannten kritischen Pfad.
Die rechnerische Ermittlung der Daten kann in zwei unterschiedlichen Varianten

graphisch dargestellt werden.
5.5.5 Gantt-Diagramm
Das erste Gantt-Diagramm wurde um 1890 von Karol Adamiecki (1866–1933)
entworfen, einem polnischen Ingenieur, der ein Stahlwerk im südlichen Polen
betrieb und sich für Managementideen und -techniken zu interessieren begann.
Etwa 15 Jahre nach Adamiecki entwickelte Henry Gantt (1861–1919), ein ameri-
kanischer Ingenieur und Managementberater, seine eigene Version des Dia-
gramms: Durch ihn wurde es in der westlichen Welt allgemein bekannt und
Terminplanung 75
populär. Dementsprechend war es Henry Gantt, nach dem Diagramme dieses

Typs benannt wurden.
Wie bei allen Terminplanungen ist der detaillierte Projektplan die Voraussetzung,
um einen realistischen Terminplan zu erstellen.
Im Gantt-Diagramm werden die Arbeitspakete und anfallenden Aktivitäten so-

wie die Meilensteine jeweils als waagerechter Balken oder als Symbol in einer
Linie dargestellt.
Der Vorteil im Verhältnis zum Netzplan ist eine kompaktere Darstellung der für
die Projektsteuerung erforderlichen Informationen. Wartezeiten, Termine in
Form von Datum, Meilensteinen etc. können auf einen Blick gesehen werden.
Eine schematische Darstellung eines Netzplans als Beispiel Gantt-Diagramm

(Balkendiagramm):
Abbildung 5.13 Terminplanung, Beispiel Gantt-Diagramm aus EDV-Tool

Abbildung 5.14 Terminplanung, Beispiel Gantt-Diagramm in MS Project
5.5.6 Netzplan oder PERT
Abbildung 5.15 Terminplan Abbildung als Netzplan

Terminplanung 77
„Kritischer Pfad“
Dieser kann erst ermittelt werden, wenn alle notwendigen Arbeitspakete zur
Zielerreichung des Projektes um den Projektstrukturplan ermittelt wurden und
im Terminplan abgebildet und mit Vorgängern versehen wurden.
Der kritische Pfad ist der möglichst kürzeste Weg durch ein Projekt. Die Puffer-
zeiten für diese Aktivität sind gleich null. Jede Verschiebung einer Aktivität, die
auf dem kritischen Pfad liegt, führt dadurch automatisch bei Nichtkorrektur zu
einer Verschiebung des Endtermins. Daher sollten diese Aktivitäten gut und vor
allem nicht zu „optimistisch“ geplant sein.
Arbeitspakete, die aus Sicht der Experten kritisch sind, sollten im Risikomanage-
ment mit betrachtet werden sowie gemäß der dortigen Einschätzung mit entspre-
chenden Alternativoptionen versehen werden, z. B.: Lieferzeit von Lieferanten
aus Übersee oder China, Container gehen verloren oder liegen beim Zoll, Un-
wetter beeinträchtigt den Transport mit Schiffen etc. All dies kann bei knapp
bemessener Lieferzeit zu einem Problem hinsichtlich der Termineinhaltung
führen.
5.5.7 Rahmenbedingungen beachten
5.5.7.1 Feiertage und Co

Hierunter fallen Urlaub, Feiertage, Schulungen und Fehlzeiten im Allgemeinen.
Auch die Weihnachtszeit ist eine Rahmenbedingung. Hier werden die Ressour-
cen knapper. Aus eigener Erfahrung verplant man sich in dieser Zeit gern. Es
sollte also vorab geklärt sein, welche Ressource wann in den Urlaub geht. Zu-
meist ist vom 15. Dezember bis 15. Januar nicht mit allen Teammitgliedern zu
rechnen. Achtung: Meist ist man bei Einsparungspotenzialen auf das Know-how
der Entwicklung und der Fertigung angewiesen. Selbiges gilt natürlich auch für
Verlagerungen von Werkzeugen etc. Es ist also wichtig, in der Projektorganisati-
on zu schauen, wen ich wann und mit welchen Ressourcen benötige. Achtung:
Bei internationalen Projekten verschieben sich die Feiertage, diese bitte mit ein-
planen.
5.5.7.2 Limitierte Ressourcen

Limitierte Ressourcen wären z. B. Prüfstände, Räume ... Zum Einsatz kommen
diese etwa, wenn Materialien getestet werden müssen, bei Änderungen oder
Anpassungen.
Wenn für die Durchführung des Projektes bestimmte Räumlichkeiten benötigt

werden, ist all dies im Zeitplan mit zu beachten und gegebenenfalls anzupassen.
Sehr schnell können auch einfache Ressourcen-Engpässe zu einer Verzögerung
im Projekt führen. Und dies gilt es, vorab schon zu beachten, damit es in der
Umsetzung des Projektes nicht zu bösen Überraschungen kommt.
5.5.7.3 Achtung Zeitpuffer

Was eigentlich so positiv klingt, kann hinsichtlich der Motivation im Team und
der unterschiedlichen Persönlichkeitsstrukturen auch nachteilig werden. Das
Gefühl, Zeit zu haben, ist dann ähnlich wie das Einkaufen von Weihnachts-
geschenken: Überraschenderweise fällt Weihnachten dieses Jahr auf den 24. De-
zember. Und dann gilt es, schnell noch Geschenke zu kaufen. So ist das auch mit
zu viel Puffer der einzelnen Arbeitspakete. Das heißt in der Praxis, die Arbeits-
pakete so früh wie möglich zu erledigen, um dann den Puffer zu nutzen, wenn
ein Terminengpass auftritt.
Fazit
 Die notwendigen Arbeitspakete sollten von den Beteiligten geschätzt wer-

den, die diese auch umsetzen werden.
 Der Gesamtterminplan ist Bestandteil des Basisplans und somit ein Doku-
ment, welches mit dem Auftraggeber abgestimmt und freigegeben wird.
 Die Verfügbarkeit der notwendigen Ressourcen ist mit den jeweiligen Ver-
antwortlichen der anderen Fachbereiche abzustimmen.
 Auch hier gilt: Der Terminplan wird Bestandteil des Basisplans und nur
über den offiziellen Änderungsantrag angepasst, sobald die Änderungen
einen Einfluss auf den kritischen Pfad haben.
 Die Steuerung des Projektes basiert auf dem Terminplan.
 Voraussetzung für einen guten Terminplan ist ein vollständiger Projekt-

strukturplan.
 Mit dem Terminplan werden während der Steuerungsphase Prognosen

bezüglich Projektdauer und Projektendtermin gemacht.
 Der Terminplan soll kritische Vorgänge identifizieren und steuerbar

machen.
Kostenplanung 79
5.6 Kostenplanung
Die Kostenplanung basiert, wie auch die Terminplanung, auf dem im Projektan-
trag vereinbarten Leistungsumfang. In der Kostenplanung schätzen wir alle Res-
sourcen und Aufwände ab, die bis zur vollständigen Umsetzung des Projektziels
notwendig sind. Das heißt, alle Arbeitspakete werden in der Planungsphase
hinsichtlich der Kosten bewertet und die Schätzung im Kostenbasisplan fixiert.
Die Kostenplanung ist verantwortlich für die Wirtschaftlichkeitsbetrachtung des
Projektes.
Wir wollen wissen, was uns die vollständige Umsetzung des Projektes kostet. Hierbei ist
zu beachten, dass das vorgegebene Budget nicht zwingend den Kosten entspricht.
Die vollständigen Projektkosten können wir erst berechnen, wenn der komplette
Projektablaufplan erstellt ist. Wir berechnen die Kosten für jede einzelne Aufgabe
und summieren diese auf Basis der Arbeitspakete über die gesamte Projektlauf-
zeit.
In einem Arbeitspaket werden alle relevanten Daten aus Ablauf-, Termin- und
Ressourcenplänen zusammengefasst. Auf dieser Basis werden die Kosten für das
Arbeitspaket erfasst und im Kostenplan (Basisplan) festgehalten. Der Basisplan
ist die Grundlage für die Projektsteuerung. Der Basisplan wird nur über einen
offiziellen Änderungsprozess angepasst.
Der Leistungsumfang des Projektes wird bereits am Anfang der Definitionsphase

über das „Magische Dreieck“ abgegrenzt. In einer ganz frühen Phase des Projek-
tes, wenn wir noch nicht sehr viel über das Projekt wissen, schätzen wir die Kos-
ten, wie auch die Termine, über frühere Projekte (analoge Abschätzung). Später
gehen wir über die Arbeitspakete (Bottom-up).
Die Kosten können im Projekt wie folgt zugeordnet werden:
direkte Kosten = Aufwände, die direkt dem Projekt zuzuordnen sind
Diese Kosten entstehen direkt durch die Umsetzung des Projektes. Von Perso-
nenetagen über Materialien bis Reisekosten kann alles direkt dem Projekt zuge-
ordnet werden.
Indirekte
= Overhead oder Gemeinkosten
Kosten
Indirekte Kosten sind anteilige Aufwendungen, die wir einem Projekt nicht di-
rekt zuordnen können, die aber in unmittelbarem Zusammenhang mit den direk-
ten Projektkosten entstehen.
variable Kosten = stückzahlabhängige Kosten, z. B. Material
Fahren wir mit einem Auto und Fahrer zum Lieferanten, so wären in diesem
Beispiel die Anzahl der sich im Auto befindenden Personen der variable Kosten-
anteil (1–4 Personentage).
fixe Kosten = unabhängig von der Stückzahl, z. B. benötigtes Werk-

Werkzeug für die Erstellung der Teile
Fixe Kosten sind in diesem Beispiel das Auto und der Fahrer.
Mögliche Kostenarten:
■ Personentage in Stunden oder Tagen

■ Reisekosten
■ Räume
■ IT
■ Beratungskosten
■ Material
■ Werkzeuge
■ Fracht
■ Zoll
Projektorganisation 81
■ Genehmigungen
■ ...
Je nach Projekt werden die jeweiligen anfallenden direkten Kosten dem Projekt
zugeordnet. Der Anteil der indirekten Kosten wird mit der Finanzabteilung des
Unternehmens abgestimmt.
Fazit
 Die Kosten bestimmen die Wirtschaftlichkeit des Projektes. Daher ist bereits
am Anfang eines Projektes der Leistungsumfang klar abzugrenzen.
 Alle benötigten Ressourcen sind zu betrachten.
 Die Umfänge der benötigten Ressourcen sind mit den Verantwortlichen

abzustimmen.
 Die Kosten werden auf Basis der geplanten Arbeitspakete im Projektverlauf

gesteuert.
 Die Kosten werden im Basisplan festgehalten.
5.7 Projektorganisation
Der Mensch ist im Projekt immer noch die treibende Kraft. Daher ist eine gute
Projektorganisation für den Erfolg des Projektes notwendig.
Die meisten produzierenden Unternehmen sind matrix-organisiert. Das heißt, es

besteht parallel zur Linienorganisation die Projektorganisation. Die Matrixorga-
nisation ist die häufigste Organisationsform für Projekte innerhalb von perma-
nenten Linienorganisationen. Bei der Matrixorganisation überlagern die temporä-
ren Projektorganisationen die Linienorganisationen so, dass zwei oder mehr
Organisationseinheiten (die Trägerorganisation und die Projekte) zugleich auf die
Ressourcen zugreifen. Die Mitglieder des Projektteams bleiben bei einer Mat-
rixorganisation unverändert in die Linienorganisation eingebunden und unter-
stehen somit sowohl ihrem Vorgesetzten als auch dem Projektmanager.
Die jeweiligen Rollen für das Projekt werden mit Experten besetzt. Das Organigramm
mit Namen und Telefonnummer der jeweiligen Personen ist ein offizielles Dokument.
Die Projektorganisation ist für uns ein einfaches, aber äußerst wichtiges Werk-
zeug. Wir erinnern uns: Projektmanagement ist eine Sonderorganisation auf Zeit.
An dieser Stelle beschreiben wir, anders als im Mind-Map, nicht mehr nur die
benötigten Funktionen, sondern wir nennen konkret Namen, die für die jeweilige
Rolle verantwortlich sind.
Im Mind-Map haben wir die für unser Projekt notwendigen Experten in Form
von Funktionen beschrieben. In der Projektorganisation versehen wir die jeweili-
gen Rollen mit Personen. Namen, Funktion und Telefonnummer werden hinter-
legt. Dies wird dokumentiert und wird allen Beteiligten zugänglich gemacht.
Die Projektorganisation hat das Ziel Klarheit über Informations-, Entscheidungs-

und Eskalationswege zu schaffen – kurz: die Grundlage für effizientes Arbeiten.
Folgende Rollen sind immer zu beschreiben:
■ Projektleiter
■ Auftraggeber
■ Lenkungsausschuss
■ Kernteam
■ unterstützendes Team
■ Beteiligte
Diese finden sich in allen Projekten wieder.
Entsprechend der Projektgröße, der Größe des Unternehmens sowie der Schnitt-
stellen werden weitere Rollen hinzugefügt.
Abhängig von Größe, Art des Projektes, Schnittstellen können Projekte unterschied-
lich organisiert sein. Jedoch kommen wir um folgende Kernaufgaben nicht umhin:
Das Zentrum bilden der Projektleiter und sein internes Kernteam. Das Kernteam
bildet die Fachfunktionen ab, deren Know-how während der gesamten Projekt-
laufzeit notwendig ist. Dazu kommt das unterstützende Team. Diese Rolle wird
Bereichen zugeordnet, die nur zu bestimmten Arbeitspaketen das Projekt unter-
stützen, z. B. Juristen. Diese werden oft nur in der Phase der Vertragsklärung
benötigt. Entsprechend werden diese Experten in Abstimmung auch nur für ihre
relevanten Arbeitspakete hinzugezogen. Während das Kernteam sich regelmäßig
trifft, wird das unterstützende Team nur bei notwendigen Arbeitspaketen zu den
Besprechungen eingeladen. Über die Verantwortlichkeitsmatrix (RACI) kann ich
als Projektleiter definieren, wer informiert werden muss bzw. Informationen
beisteuert.
Als sogenannte Beteiligte werden die Bereiche bezeichnet, die durch das Projekt
bedingt Änderungen erfahren, z. B. bei der Einführung eines neuen IT-Systems
all jene, die eine Schulung dafür benötigen. Beteiligte leisten keinen Beitrag zum
Projekt, müssen aber in Form von anfallendem Aufwand berücksichtigt werden.
Im Beispiel des IT-Systems: Schulungen, die einen Aufwand generieren.
In der Projektorganisation finden sich auch sämtliche Steuerkreise und der Auf-
traggeber wieder.
Abbildung 5.16 Beispiel Projektorganisation
Die Expertise und die Zugehörigkeit in der Organisation werden über die Funk-
tion definiert (Einkaufseiter, Projekteinkäufer, Sachbearbeiter R&D). Parallel dazu
kann man unterschiedliche Rollen im Projekt einnehmen. Die Rollen einer Person
können im Projekt wechseln. Bin ich in einem Projekt Projektleiter, so kann ich in
einem anderen Projekt Teammitglied sein (siehe Kapitel 5.7.2).
Bei der Beschreibung der Rolle werden sowohl die Aufgabe, die Verantwortung
als auch die Entscheidungskompetenz festgelegt.
■ Aufgabe = Was habe ich zu tun?

■ Verantwortung = Wofür stehe ich gerade?
■ Kompetenz = Was darf/muss ich entscheiden?
Diese drei Punkte gehören zu einer Beschreibung der Rolle. Eine komplexe Auf-
gabe ohne entsprechende Entscheidungskompetenz führt unwillkürlich zu einem
Problem. Einer der kritischen Punkte ist hier die klare Abgrenzung zur Leitungs-
funktion in der Linie: Was darf ich als Projektleiter bezogen auf das jeweilige
Projekt in Abgrenzung zur Linie entscheiden? Für alle Rollen sollten die entspre-
chenden Punkte beschrieben und dokumentiert sein.
Der Aufbau der Projektorganisation wird maßgeblich durch die Kultur des Un-
ternehmens bestimmt. Die Führungsrolle des Projektleiters und die an dieser
Stelle gegebene „Macht“ sind Bestandteil der Unternehmenskultur.
Checkliste von Fragen, die eine Erstellung der Projektorganisation erleichtern:
■ Sind alle notwendigen Rollen beschrieben?

■ Wer berichtet an wen?
■ Wer ist im Projekt wofür verantwortlich?
■ Wer entscheidet Änderungen des Basisplans?
■ Wie fließen die Informationen (Meetings, E-Mail ...)?
■ Wann und wie oft trifft sich das Kernteam?
■ Wann werden die Experten aus dem unterstützenden Team hinzugezogen?
■ Wie und wann werden die Beteiligten informiert?
■ Wie oft tagt der Lenkungsausschuss?
■ Wann und wer informiert/spricht mit dem Auftraggeber?
■ Welche externen Schnittstellen sind relevant für das Projekt?
5.7.1 Wann und wie werden die Themen umgesetzt?
1. Abgrenzung des Projektes
Aus der Definition bzw. der Abgrenzung des Projektes ergeben sich das dafür
benötigte Know-how und damit auch die für das Projekt notwendige Funktion.
2. Definition der Rollen
Wird die Verantwortlichkeitsmatrix für ein Projekt definiert, kann auf das Mind-
Map und die Stakeholderanalyse zurückgegriffen werden, um Personen oder
Personengruppen zu bestimmen, die in irgendeiner Form in das Projekt invol-
viert werden müssen.
3. Definition der Aufgaben
Die Aufgaben sind sehr grob im Mind-Map abgegrenzt. Über den Projektstruk-
turplan können weitere Arbeitspakete entnommen werden. Teilweise müssen
Aufgaben aber auch explizit definiert werden (s. Kapitel 5.4, bzw. Schritt 4 – PSP):
Welches sind die Aufgaben des Lenkungsausschusses, welches die Aufgaben der
Projektleitung, welches die Aufgaben der Qualitätskontrolle usw.?
4. Festlegung der Verantwortlichkeitsmerkmale
Hier können Sie auf die genannten Merkmale der RACI-Matrix zurückgreifen
(vgl. Abb. 5.16 sowie Kapitel 5.7.3).
5. Genaue Definition (Normierung) der Verantwortlichkeitsmerkmale
Beispielsweise ist zu definieren, was „Accountable“ konkret bedeutet: Es könnte

jemand sein, der für einen Verantwortungsbereich eine Entscheidungsgewalt hat,
die sich auf ein Budget beziehen kann, auf Personalverantwortung, auf eine Unter-
schriftsberechtigung, auf die Abnahme eines Liefer- und Leistungsumfangs usw.
6. Kommunikation der Verantwortlichkeitsmatrix
Ein guter Zeitpunkt für die Kommunikation der Verantwortlichkeitsmatrix (siehe

Kapitel 5.7.3) ist das Kick-off-Meeting.
5.7.2 Das Team und die Rollen im Projekt

Die Zusammensetzung des Projektteams kann hinsichtlich der Fachfunktionen sehr
unterschiedlich geprägt sein. Abhängig von Aufgabe und Umfang werden die
jeweiligen Experten für das Team benannt. Die Mitglieder des Teams stammen aus
der Linienfunktion. In einigen Fällen wird das Know-how extern hinzugeholt. An
dieser Stelle ist es umso wichtiger, eine klare Rollenbeschreibung zu haben.
Eine Rolle ist die Funktion jedes Einzelnen im Projektteam. So kann ich von der
Fachfunktion Einkäufer sein und zusätzlich im Projekt die Rolle des Projektleiters
übernehmen. In kleineren Projekten besteht auch die Möglichkeit, mehrere Rollen

auszufüllen. Beispiel: Im Großprojekt existiert die Rolle des Risikomanagers, in
kleineren Projekten übernimmt der Projektleiter diese Aufgabe und hat damit
auch die Rolle inne.
Die Rollenbeschreibung dient den Beteiligten zur Abgrenzung ihrer eigenen

Aufgabe. Die folgenden Rollen finden wir in fast allen Projekten wieder:
■ Auftraggeber
■ Projektleiter
■ Teilprojektleiter
■ Teammitglied
■ Projektassistent
■ Risikomanager
■ Lenkungsausschuss
Die Rolle ist die temporäre Funktion, die einer Person im Sinne einer Projektor-
ganisation zugeordnet wird. Ebenfalls gehört dazu, in welcher Position die Rolle
zu anderen Schnittstellen steht. Kurz: Wie sind die jeweiligen Machtverhältnisse?
Um eine Rolle beschreiben zu können, werden drei Aspekte betrachtet:
■ der Aufgabenbereich,
■ der zu verantwortende Bereich,
■ die Entscheidungsbefugnis.
Am Beispiel des Projektleiters kann eine Rollenbeschreibung wie folgt aussehen:
Aufgabe
■ plant und steuert das Projekt hinsichtlich Terminen, Kosten und vereinbartem
Leistungsumfang; dies wird im Projektstrukturplan bis auf Arbeitspaketebene
heruntergebrochen und im Terminplan mit Meilensteinen und Kalender zu-
sammengefügt
■ bildet und leitet das Projektteam und fördert den Teamgeist

■ führt die Kommunikation im Projekt
■ plant Ressourcen und sorgt für deren Zuweisung in Absprache mit den Leitern
■ identifiziert mit den Experten Projektrisiken und steuert Gegenmaßnahmen ein

■ präsentiert und vertritt das Projekt
Verantwortung
■ … für die Umsetzung des Prozesses von der Projektidee bis zum Projekt-
abschluss
■ … für die vereinbarten Ziele: Budget, Kosten, Termine, Qualität

■ .... für die Umsetzung der definierten Arbeitspakete
■ … für Informationsfluss gegenüber Projektteam und Auftraggeber
■ … für Terminplan und Wirtschaftlichkeit des Projektes
Entscheidungskompetenz
■ arbeitet mit den notwendigen Fachbereichen zusammen

■ besitzt projektspezifische Weisungsbefugnis (Was?, Wann?, Wie gut?)
■ kann Aufgaben und Rechte an Projektteammitglieder delegieren
■ berichtet dem Auftraggeber
Jedes Unternehmen beschreibt die Rollen nach eigenen Anforderungen, abhängig
von Organisationsform, Kultur und Zielen.
Einer der Erfolgsfaktoren im Projekt ist die gute Abgrenzung der Schnittstelle
„Rolle im Projekt“ und die Funktion in der Organisation. Damit kann sich das
Projektteam auf die Umsetzung der Arbeitspakete konzentrieren und Reibungs-
verluste durch ungeklärte Verantwortlichkeiten werden minimiert.
Eine Frage, die in den Seminaren immer wieder seitens der Teilnehmer gestellt
wird, hier einmal als Zusammenfassung der Gruppenarbeiten aus sogenannten
Teamtrainings:
Was macht das Team erfolgreich und was wird als Störgröße empfunden?
positiv:
■ feste Regeln für die Zusammenarbeit

■ klare Rollen und Verantwortungen
■ gemeinsam Ziele festlegen und umsetzen
■ Hierarchie als Nebensache

■ respektvolle Kommunikation
■ konstruktiver Umgang mit Konflikten
■ gemeinsame Werte festlegen
■ sachliche Diskussionen beibehalten
■ konkrete Aufgabenstellung
■ Feedback und nochmals Rückmeldung für erbrachte Leistung
negativ:
■ Kompetenzen untergraben
■ Regeln ignorieren
■ sich vom Team lösen, eigene Ziele setzen
■ Niemand sollte aus seiner Rolle „fallen“ – Aufgaben werden gestört
■ andauernde Positionskämpfe im Team
■ ungelöste Konflikte
■ persönliche Befindlichkeiten
■ andere Teammitglieder übergehen
Es ist für das Team hilfreich, Werte und Spielregeln der Zusammenarbeit gemeinsam zu
definieren.
Fazit
 Mit der Projektorganisation werden die verantwortlichen Menschen und

Funktionen in das Gesamtsystem „Organisation“ eingebunden.
 Die für das Projekt notwendigen Experten werden in das Kernteam bzw. in
das unterstützende Team eingebunden.
 Die einzelnen Rollen werden mit Aufgaben, Verantwortung und Kompe-

tenz definiert. RACI (Verantwortlichkeits-)-Matrix
5.7.3 RACI (Verantwortlichkeits-)-Matrix

Die Verantwortlichkeitsmatrix ist für den Projektleiter ein weiteres Werkzeug
unterstützend zur Projektorganisation. Vereinfacht werden auf der X-Achse die
großen Arbeitspakete beschrieben und auf der Y-Achse die jeweiligen Rollen.
Der Projektstrukturplan sollte mit der entsprechenden Verantwortlichkeitsmatrix

bereits im Kick-off mit dem Team gemeinsam erstellt werden.
Abbildung 5.17 Verantwortlichkeitsmatrix (Quelle: PMBOK, A Project

Management Body of Knowledge, 2008, S 220/221)
Mit einer gut aufgebauten RACI-Matrix kann man auf einen Blick erkennen, wer
im Projekt ist:
Responsible:
Verantwortlich im eigentlichen Sinn für die Erledigung und Umsetzung des
jeweiligen Arbeitspaketes. Der Verantwortliche kann das Arbeitspaket selber
umsetzen oder umsetzen lassen. Er stellt sicher, dass das Arbeitspaket terminge-
recht und in entsprechender Qualität verfügbar ist.
Accountable:
Nimmt das Arbeitspaket ab. Ist zeichnungsberechtigt. Ist Ansprechpartner für
Ziel und Qualität des Arbeitspakets. Benötigt das Ergebnis des Arbeitspakets.
Consultant:
Unterstützend oder beratend bei der Umsetzung in fachlicher Hinsicht.
5.7.4 Stakeholderanalyse
Die Stakeholderanalyse ist ein weiteres Werkzeug, das in einer frühen Phase des
Projektes bereits wertvolle Unterstützung bei der Umsetzung des Projektes gibt.
Mit der Stakeholderanalyse wird systematisch festgehalten, welche Personen

oder welche Interessengruppen über die gesamte Projektlaufzeit einen Einfluss
auf das Projekt haben können. Anders als im Mind-Map sind diese Personen
nicht zwingend Bestandteil der Projektorganisation. Stakeholder können einen
Einfluss haben, ohne direkt im Projekt mitzuwirken. Mit der Stakeholderanalyse
identifizieren wir die Interessen, die Erwartungen und den möglichen Einfluss in
Bezug auf die Umsetzung unseres Projektes.
Abbildung 5.18 Stakeholderanalyse vor Projektstart
Schritt 1:
Relevante Stakeholder identifizieren. Pragmatischerweise wird dies mit bereits
bekannten Projektbeteiligten durchgeführt. Im Gespräch oder Workshop wird die
Liste der Personen erweitert. Wichtige Informationen wie die Rolle, das Interesse
am Projekt, der mögliche Einfluss werden abgeschätzt.
Schritt 2:
Dokumentation der möglichen Anforderungen an das Projekt durch die jeweili-
gen Stakeholder.
Schritt 3:
Identifikation des möglichen Einflusspotenzials oder der Störgröße, die die jewei-
ligen Stakeholder haben können. Bei vielen Stakeholdern ist es wichtig, diese
nochmals in Gruppen zu untergliedern, um einen effizienten Prozess im Umgang
mit diesen zu entwickeln. Beispiel: Erstellen einer Matrix, bezogen auf die Macht
und die aktive Einbindung in das Projekt (Interesse) (Abbildung 5.19).
Schritt 4:
Ableiten von Aktivitäten zur Einbindung der jeweiligen Stakeholder in unter-
schiedlichen Projektphasen.
Schritt 5:
Wiederholung und Review auf Basis des aktuellen Projektstandes.
Mit dem Stakeholder-Management sollen in einer frühen Phase des Projektes

strategisch alle Personen identifiziert werden, die das Projekt beeinflussen, unter-
stützen und negative Einflussfaktoren möglichst minimieren können.
Fazit
 Die Stakeholderanalyse und auch die RACI-Matrix sind hilfreiche „Werk-

zeuge“ zur Gestaltung des Kommunikationsprozesses.
 In der RACI-Matrix befinden sich die Personen, die direkt am Projekt oder
Entscheidungsprozess beteiligt sind.
 In der Stakeholderanalyse befinden sich alle Personen oder Personengrup-

pen, die einen Einfluss auf das Projekt haben können.
Abbildung 5.19 Macht und Interesse der identifizierten Stakeholder
5.8 Risikomanagement
„Ein Schiff, das im Hafen liegt, ist sicher, aber dafür werden Schiffe nicht gebaut.“
(William Shedd, 1820–1894, US-amerikanischer Theologe)
Das Ziel des Risikomanagements ist es, die Wahrscheinlichkeit und den Einfluss
negativer Ereignisse auf das Projektziel zu minimieren. Die Ereignisse haben
immer einen Einfluss auf die Projektziele und damit auf Termin, Kosten und
vereinbarten Leistungsumfang. Ihre Ursachen können natürlich vielseitig sein.
Projekte sind per Definition neu und bringen immer unsichere Komponenten mit
sich. Als Risiken bezeichnet man jegliche negativen Abweichungen vom Basis-
plan sowie den Zielen. Eine positive Abweichung wird als Chance gesehen. Im
PMBOK wird es daher auch als „Risk and Opportunity Management“ bezeichnet.
Risikomanagement 93
Wir versuchen eine anfänglich noch subjektive Größe (die Annahme, es könnte
ein Risiko sein) mit Zahlen zu bewerten. Risikomanagement ist ein Prozess.
Die Auftretenswahrscheinlichkeit und der potenzielle Schaden werden mit einer

Kennziffer bewertet.
Die entsprechenden Maßnahmen, die der Verhinderung oder Minimierung des

Risikos dienen, werden erarbeitet.
Da alle Projekte mehr oder weniger mit dem Risiko der Terminüberschreitung,
der Überziehung der geplanten Kosten und der Verfehlung des geplanten Leis-
tungsumfangs behaftet sind, ist ein gutes Management der Risiken unerlässlich.
Je früher die wichtigsten Risikotreiber, also Faktoren, die den rechtzeitigen Pro-
jektabschluss, die Einhaltung des Projektbudgets und die Erreichung des verein-
barten Leistungsumfangs gefährden können, aufgedeckt werden, umso eher
kann Risikovorsorge getroffen werden.
Die Verantwortung für das Thema Risikomanagement liegt bei der Projektlei-
tung. Je nach Größe des Projektes wird ein sogenannter Risikomanager benannt,
der die Steuerung der Risiken übernimmt. Die Verantwortlichkeiten liegen fest,
die Frage bleibt: Was ist ein Risiko für unser Projekt?
Hierzu lohnt zunächst einmal die Unterscheidung zwischen Problem und Risiko.
Ein Risiko kann zu einem Problem werden, wenn es nicht frühzeitig erkannt und
gesteuert wird. Ein Problem ist zeitlich gesehen schon da, ein Risiko liegt in der
Zukunft.
Ein Risiko bedroht das Projekt hinsichtlich der Zielerreichung. Somit impliziert es
aber auch automatisch, dass es ohne ein klar abgegrenztes Ziel auch kein gutes
Risikomanagement gibt.
Aus einem Risiko kann sehr schnell ein Problem werden. Ein Problem ist be-
kannt, ein Risiko noch nicht. Um aber diese potenziellen Bedrohungen zu erken-
nen, gilt es, einem Prozess zu folgen. Auch hier ist das Ergebnis nur so gut wie
der Input der jeweiligen am Prozess beteiligten Experten.
Risikomanagement ist ein Prozess
Der Prozess beinhaltet die Steuerung der Risikoplanung, das Erkennen, Bewerten
sowie das Steuern der definierten Gegenmaßnahmen, damit das Risiko nicht
eintritt. Die Methode sollte möglichst effizient, aber einfach anzuwenden sein.
Der Erfolg hängt immer davon ab, wie gut der Input der Experten ist.
Abbildung 5.20 Vorgehen, Prozess Risikomanagement (Quelle: in Anlehnung

an Steuerkreis nach William Edwards Deming (1900–1991),
US-amerikanischer Physiker und Statistiker)

Risiko identifizieren

Aktivitäten umsetzen Risiko bewerten

Gegenmaßnahmen definieren
Die Einflussfaktoren auf das Risikomanagement sind vielseitig. Stakeholder,

Projektleiter sowie die Experten sehen das Projekt aus unterschiedlichen Blick-
winkeln und so natürlich auch die potenziellen Risiken, die auf ein Projekt ein-
wirken. Dies führt natürlich dazu, dass Risiken unterschiedlich eingeschätzt
werden. Auch die Abschätzung der Gegenmaßnahmen fällt sehr unterschiedlich
aus. Genau diese unterschiedlichen Sichtweisen ermöglichen es uns, eine ganz-
heitliche Sicht auf das Projekt und dessen Bedrohung auf die Zielerreichung zu
bekommen. Das Risikomanagement sollte im Team und so früh wie möglich
(Definitions- oder Planungsphase) durchgeführt werden. Im weiteren Verlauf des
Projektes werden die Risiken überwacht und gesteuert.
In einem ersten Schritt werden Risiken in ihren potenziellen Gruppen und einer
Kategorie zugeordnet. Handelt es sich eher um ein technisches Risiko, ein Um-
weltrisiko, ein logistisches Risiko etc.?
■ In Schritt 1 werden Risikogruppen in Bezug auf das Projekt identifiziert.

■ Die Informationsquellen (z. B. Experte oder auch EDV) werden benannt.
■ In Schritt 3 werden die möglichen Ursachen für die potenzielle Bedrohung
benannt.
■ In Schritt 4 wird das eigentliche Risiko beschrieben.

■ In Schritt 5 werden die Auswirkungen abgeschätzt, die dieses Risiko auf den
Termin, die Kosten und/oder den Leistungsumfang haben könnte.
Risikomanagement 95
Abbildung 5.21 Schritte in der Risikobetrachtung (Quelle: PMBOK, A Guide to

the Project Management Body of Knowledge, 2008, S. 152)
5.8.1 Quantifizierung benannter Risiken

In vorherigen Schritten wurden die Risiken und deren Ursachen benannt. Die
Risiken werden in einem weiteren Schritt bewertet, um dann entsprechend der
eingeschätzten Bedeutung der potenziellen Bedrohung Gegenmaßahmen einzu-
leiten.
Für eine einfache Bewertungsmethode stellen wir uns zwei Fragen:
1. Wie hoch wird der potenzielle Schaden eingeschätzt, den das Risiko verursa-
chen würde?
2. Wie wird die Auftretens-, bzw. Eintrittswahrscheinlichkeit für das entspre-

chende Risiko eingeschätzt?
Das Risiko wird quantifiziert, indem wir auf einer Skala zwischen 1 und 10 so-
wohl das Risiko als auch den potenziellen Schaden bewerten, den das eintretende
Risiko verursachen könnte, inkl. der sogenannten Auftretenswahrscheinlichkeit.
Die Skala zwischen 1 und 10 ist hier frei gewählt.
Abbildung 5.22 Skala Auftretens- und Eintrittswahrscheinlichkeit
Auftretenswahrscheinlichkeit
10
1 5 10 Schaden
Nr. Risiko A S A×S P Gegenmaßnahmen Wer Wann
A = Auftretenswahrscheinlichkeit
S = Schaden
A×S = Multiplikator aus Auftretenswahrscheinlichkeit und Schaden
P = Priorisierung zur Überprüfung der Zahlen, z. B.: Wann immer Auftretens-

wahrscheinlichkeit oder Schaden mit 10 benannt wurden, verschiebt sich die
Priorität, auch wenn der andere Faktor nur eine 1 sein mag.
Risikomanagement 97
Bezogen auf die ermittelten Risiken findet die Bewertung hinsichtlich Auftre-
tenswahrscheinlichkeit und Schaden statt. Danach werden potenzielle Gegen-
maßnahmen erarbeitet und die für die Abarbeitung notwendigen Verantwortli-
chen mit Termin bestimmt. Hier gilt es, einen konkreten Namen (z. B.: Peter Mül-
ler) benennen und nicht nur eine Funktion sowie ein konkretes Datum
(30.03.20XX) zur Umsetzung.
Zu einem späteren Datum wird der Erfolg der umgesetzten Maßnahme über-
prüft.
Risikomanagement ist ein Prozess und begleitet das Team während der komplet-
ten Projektlaufzeit. Es kostet Geld, kein Risikomanagement kann jedoch noch
teurer werden.
5.8.2 Möglichkeiten, auf Risiken zu reagieren
Abbildung 5.23 Risk Respond Management (Quelle: PMBOK, A Guide to the

Project Management Body of Knowledge, 2008, S. 164)
Avoid = Ein Risiko beseitigen, indem die Auftretenswahrscheinlichkeit

auf null gesenkt wird.
Mitigate = Verringern der Auftretenswahrscheinlichkeit und/oder der Aus-

wirkungen eines Risikos. Mitigation ist spezifisch für jedes Risiko
sowie für die sich darauf beziehenden Aktivitäten.
Transfer = Haftung oder Verantwortung für Risikoauswirkungen an Dritte

übertragen, wie z. B.: Versicherung, Outsourcing.
Accept = Bewusste Entscheidung, ein Risiko zu akzeptieren und dessen

Auswirkungen zu decken, wenn der monetäre Schaden des eintre-
tenden Risikos geringer geschätzt wird als die Vermeidung des
Risikos. Dies sollte aber eine Managemententscheidung sein und
offiziell dokumentiert und abgenommen.
Die Herausforderung im Risikomanagement ist einmal die Identifikation der

Risiken, aber auch das gemeinsame Entscheiden und Vereinbaren über diese. Je
nach Persönlichkeiten, Expertisen der Teammitglieder, Kulturen und Sichtweisen
wird dies sehr unterschiedlich betrachtet.
Fazit
 Risikomanagement ist ein Prozess, der bereits zu Beginn des Projektes defi-
niert wird.
 Risikomanagement findet im gesamten Projektverlauf statt.
 Gutes Risikomanagement setzt Expertenwissen voraus.
 Die Vermeidung und Eingrenzung von Risiken ist mit Kosten verbunden.
5.9 Beispiel eines Musterprojektes

Beschaffung eines Roboters für die Fertigung zum Einlegen von Elektronik-
teilen in die Prozesskette
Das Musterprojekt ist nicht vollständig, sondern dient nur der Verdeutlichung
der Abläufe untereinander. Es zeigt, wie die einzelnen Schritte aufeinander auf-
bauen. Der „rote Faden“ wird beschrieben. Die Rolle des Projektleiters liegt für
das Beispielprojekt im Einkauf.
Beispiel eines Musterprojektes 99
5.9.1 Projektantrag
Beschreibung:
Zur Fertigungsoptimierung und im Rahmen eines Kostenreduzierungsprogramms
wurde seitens der Geschäftsleitung beschlossen, für das Einlegen von Teilen in
den Fertigungsprozess einen Roboter einzusetzen anstatt wie bisher Personal. Der
Standort Stuttgart soll in diesem Bereich optimiert werden. Der Einkauf wurde
informiert. Einen entsprechenden Lieferanten gibt es noch nicht. Es gab bei der
bisherigen Verfahrensweise immer wieder auch Qualitätsprobleme. Nach Vorab-
informationen geht es auch darum, einen gleichbleibenden Prozess zu gestalten,
der über Personal doch immer wieder auch zu qualitativen Unterschieden im
Endprodukt geführt hat. Die Projektleitung soll in diesem Fall im Einkauf sein.
Das Projekt steht unter hohem Zeitdruck (s. u., Rahmenbedingungen).
Die Beschreibung soll sicherstellen, dass alle Beteiligten das Gleiche unter dem
Projekt sowie dessen Umfang verstehen. Der Projektantrag ist die Vertragsbasis
zwischen Auftraggeber und Auftragnehmer. Sie basiert auf den Eckdaten des
sogenannten „Magischen Dreiecks“ und umfasst Qualität (vereinbarter Leis-
tungsumfang), Termine und Kosten. Es gilt, ein gemeinsames Verständnis zu
schaffen. Hier ist die Basis für die weitere Planung gelegt. Eine Abweichung
vom Basisplan sollte im Verlauf des Projektes nur dann stattfinden, wenn ein
offiziell abgezeichneter Änderungsantrag vorliegt und es keine Unstimmigkei-
ten mehr zwischen Auftraggeber und Auftragnehmer über den geänderten
Umfang und die sich daraus ableitenden Änderungen von Zeit und Kosten
darstellen. Ansonsten wird dies einer der ständigen typischen Diskussions-
punkte und raubt unnötig Zeit und Energie.
Rahmenbedingungen:
Das Projekt ist ein Teilprojekt im Rahmen eines Optimierungsprogramms zur
qualitativen Verbesserung und Optimierung in der Fertigung. Daher ist der End-
termin gekoppelt an das gesamte Projekt und soll bis 20.12.20XX abgeschlossen
sein, da hier das Management ein Audit zur Überprüfung der Wirksamkeit
der beschlossenen Maßnahmen angedacht hat. Der aktuelle Termin ist der
15.01.20XX. Vom Kick-off bis zum Audit ist die Zeitspanne nicht mehr als
11 Monate.
Die Rahmenbedingungen sind als sogenannte Leitplanken zu betrachten. Es

sind Vorgaben, die gesetzt sind. In diesem Beispiel wurde das Programm in der
Fertigung beschlossen und sollte nicht weiter diskutiert werden. Der Projek-
tauftrag leitet sich daraus ab. Ebenfalls der Termin, der aus Sicht der Beteiligten
im Einkauf eine Herausforderung darstellt.
Zielbestimmung:
Der Roboter zum Einlegen in den Fertigungsprozess ist seitens des Auftraggebers
und der Fertigung abgenommen und kann in die Serie übernommen
werden. 15.12.20XY
Meilensteine:
Lastenheft seitens Entwicklung liegt vor. 15.02.20XY
Zeitraum des Projektes: 15.02.20XY – 15.01.20XX = 11 Monate Durchlaufzeit
Die klare Abgrenzung von Anfang und Ende des Projektes. Bitte nicht verges-
sen: Der Basisplan wird durch das Magische Dreieck begrenzt – Termine, Kos-
ten und den dabei vereinbarten Leistungsumfang.
Team:
Einkauf (PL), Fertigungsplanung, Entwicklung, Fertigung (je ein Verantwortli-
cher im Kernteam)
Der Projektauftrag ist die offizielle Vereinbarung zwischen Auftraggeber und

Auftragnehmer. An dieser Stelle sollte idealerweise von beiden Seiten ein kla-
res Commitment bestehen. Der Projektleiter übernimmt offiziell die Führung
des Projektes mit dem Projektauftrag.
Begrenzungen:
Der Roboter muss in den Fertigungsprozess integriert werden, Anpassungen der
bestehenden Fertigungsstraße sind nicht geplant.
In Scope:
Auswahl und Beschaffungsprozess des Roboters.
Out of Scope:
Anpassung der Software in der Fertigung
Manchmal ist es einfacher, zu fragen, was nicht zum Projektumfang gehört,

und dies als „Out of Scope“ zu definieren. Dies kann helfen, potenzielle Kon-
flikte über den zum Projekt gehörigen Arbeitsumfang frühzeitig vorwegzu-
nehmen.
5.9.2 Projektbeispiel Mind-Map
Abbildung 5.24 Mind-Map-Roboter
Das Mind-Map als Basis für den Projektstrukturplan sowie für die Projektorga-
nisation. Hier werden zwei Themen beantwortet:
Wer ist als Funktion oder Schnittstelle beteiligt?
Was muss als ganz grobes Arbeitspaket getan werden?
5.9.3 Projektbeispiel Zielplanung

Laut Lastenheft vom 15.01.20XY (Freigabe 22.02.20XY) ist am 15.12.20XY ein
Roboter zum Einlegen von Elektronikteilen in die Fertigungsstraße AB, Halle Z
am Standort Stuttgart abgenommen.
Folgende Meilensteine sind in die Zielplanung aufgenommen:
M1 Kick-off durchgeführt 20.02.20XY

M2 Lastenheft abgenommen 22.02.20XY
M3 Angebote der Lieferanten liegen vor 15.04.20XY
M4 Vorstellung und Eingrenzung der in Frage kommenden Lieferante 20.04.20XY
M5 Lieferantengespräche sind geführt 20.05.20XY
M6 Vertrag mit Lieferant geschlossen 10.06.20XY
M7 Bestellung abgeschickt 15.06.20XY
M8 Roboter abgenommen 15.11.20XY
M9 Roboter freigegeben und in Fertigung integriert 15.12.20XY
Der Endtermin ist vorgegeben, auch hier abgeleitet aus dem „Magischen Drei-
eck“ von Termin, Kosten und vereinbartem Leistungsumfang. In unserem Bei-
spiel war die Umstellung seitens der Fertigung vorgegeben und leitete sich aus
dem gewünschten Einsparungspotenzial ab. Weitere Meilensteine können vor-
gegeben oder aber auch von uns gesetzt werden. Vom letzten Meilenstein aus-
gehend, setzen wir die Meilensteine entsprechend unserer Planung rückwärts.
Schon hier lassen sich, so vorhanden, Unklarheiten in Planung und daraus re-
sultierende Abweichungen in der Umsetzung erkennen und in Abstimmung
mit dem Auftraggeber und/oder Steuerkreis anpassen.
5.9.4 Projektbeispiel Projektstrukturplan
Tabelle 5.2 Beispiel Auszug aus einem Projektstrukturplan für das

Musterprojekt
Funktion Definition Planung Umsetzung Abschluss
Projektleitung *AP1 Projekt- *AP7 Erstellen *AP17 Steuerung *AP30

28PT umfang klären und Abstimmen des Projektpro- finanzieller
3PT des Basisplans zesses 10PT Abschluss
*AP2 6PT *AP18 Projektdo- *AP31
Vorbereiten und *AP8 Freigabe kumentation 2PT Projektdoku-
Durchführen vom Lenkungs- mentation 3PT
des Kick-offs ausschuss
2PT vorbereiten 2PT
Einkauf AP3 *AP9 Marktana- *AP19 Umsetzung AP36

Summe Kick-off 0,5PT lyse 3PT des Einkaufspro- Freigabepro-
27,5PT *AP10 Kennzah- zesses 10PT zesse 1PT
len und Portfo- *AP20 Abstim-
lio-analyse 3PT mung mit Lieferan-
ten und Verträge
schließen
10PT
Entwicklung *AP3 *AP11 Be- *AP21 bedarfsge- *AP32 Freiga-

Summe Kick-off 0,5PT schreibung des rechte Teilnahme be 2PT
40,5PT Lastenheftes an Lieferantenge-
*AP4 10PT sprächen 4PT
Ist-Aufnahme
*AP12 Rahmen *AP22 Teilnahme
mit Fertigung festlegen 2PT an Projektbespre-
4PT chungen 6PT
*AP13 Teilnah-
*AP5
me an Meetings *AP23 Abstim-
Bestimmung 4PT mung mit F 4P
technisches Soll
4PT
Fertigungspla- AP3 Kick-off *AP14 Anforde- *AP24 Beschrei-

nung 0,5 PT rungen seitens ben und Umsetzen
Summe Fertigung ein- der neuen Prozes-
18,5PT bringen 2PT se 6PT
*AP25 Abstim-
mungen projekt-
bezogen 10PT
Funktion Definition Planung Umsetzung Abschluss
Fertigung *AP6 *AP15 Unter- *AP26 Anpassun- *AP33 Anpas-

Summe Fertigungsrele- stützung des gen in der Ferti- sungen an die
21,5PT vante Anforde- Einkaufs 3PT gung 6PT Serie 3PT
rungen einbrin- *AP27 Teilnahme *AP34 Freiga-
gen 0,5PT an projektbezoge- be 2PT
nen Besprechun-
gen 6PT
Qualität *AP16 Kennzah- *AP28 Überprü- *AP35 Ab-

Summe 12PT len festlegen fung der Qualität nahme und
und abstimmen 2PT Dokumentati-
4PT *AP29 Auditierung on 3PT
des Prozesses
2PT
Summe 15,0PT Summe 39PT Summe 78PT 14PT
Der Projektstrukturplan ist an dieser Stelle nicht vollständig. Beispielhaft sind je

Phase und Funktion einzelne Arbeitspakete aufgegriffen und mit abgeschätzten
Personentagen versehen worden. Die Vervollständigung des PSPs sowie das
Abschätzen der einzelnen Arbeitspakete können nur durch die Fachfunktionen
im Unternehmen geschehen.
Der Projektstrukturplan bildet die Arbeitspakete ab, die zur Erreichung der
Ziele und Meilensteine notwendig sind. In diesem Beispiel wurde ein funkti-
onsorientierter Strukturplan gewählt. Für technische oder Bauprojekte eignet
sich eher eine Baugruppengliederung. Für die einzelnen Arbeitspakete wird
gemeinsam mit der Führungskraft des Fachbereiches und/oder dem Team-
mitglied der jeweils benötigte Aufwand abgeschätzt. In dieser Darstellung ist
sehr schnell zu erkennen, wie die jeweilige Arbeitsbelastung liegt. Die Res-
sourcen und deren Verfügbarkeit sind mit den einzelnen Fachbereichen ab-
zustimmen.
Im Beispiel wurden als Einheit die sogenannten PT = Personentage genutzt. Die

Arbeitspakete sollten nicht zu klein gewählt werden. Die Aufwände sagen
nicht zwingend etwas über die benötigte Durchlaufzeit aus, sondern spiegeln
den effektiven Aufwand, der notwendig ist, um das Arbeitspaket umzusetzen.
Entsprechend der Zeitfenster ergeben sich die notwendigen Ressourcen. Der

Projektstrukturplan dient ebenfalls als Basis für die Termin- und Kostenpla-
nung. Optimalerweise ist der Plan mit allen Beteiligten abgestimmt.
5.9.5 Projektbeispiel Terminplan

Die Meilensteine werden als Fixpunkte in den Terminplan eingetragen.
Abbildung 5.25 Schematische Darstellung der Meilensteine und des Terminplans
Die im PSP geschätzten Aufwände für die Arbeitspakete werden genutzt und
in den Terminplan eingetragen. Die Arbeitspakete werden durch die gesetzten
Anordnungsbeziehungen logisch verknüpft. Der Terminplan wird idealerweise
mit einem EDV-Tool erstellt.
Die Meilensteine, von außen gegeben oder gesetzt, geben die Begrenzung und
den Rahmen des Terminplans. Die Arbeitspakete aus dem Projektstrukturplan
Abbildung 5.26 Schematische Darstellung von Meilensteinen und Arbeits-

paketen als Gantt-Diagramm
werden mit den jeweiligen Ressourcen hinzugefügt. Ebenfalls werden hierbei

die Wartezeiten, Freiräume, Liegezeiten, Feiertage etc. mit eingeplant. Unter
Betrachtung aller Aspekte wird in Abhängigkeit der Anordnungsbeziehung
der Terminplan entwickelt.
Die Arbeitspakete sollten nicht zu detailliert sein. Weder möchte man „Sklave
seines Terminplans sein“ noch die Teammitglieder zu eng führen. Wenn mög-
lich, sollte viel Eigenverantwortung für die Umsetzung im Team liegen.
Ist der Terminplan freigegeben, so gilt er als Basisplan und wird über die ge-
samte Projektlaufzeit für die Steuerung genutzt. Eine offizielle Änderung des
Basisplans kann nur über den Steuerkreis erfolgen. Hierzu ist ein offizieller
Änderungsantrag notwendig. Im Änderungsantrag werden die Auswirkungen
auf Kosten und Leistungsumfang beschrieben.
Ressourcen können in vielen Terminplanungssystemen mit eingetragen werden.

In der Steuerungsphase werden in den jeweiligen Arbeitssitzungen die geplan-

ten mit den aktuellen Arbeitsständen abgeglichen. Die Verantwortung der Um-
setzung liegt bei den verantwortlichen Teammitgliedern.
5.9.6 Musterprojekt Kostenplan

Der Kostenplan wurde an dieser Stelle bewusst weggelassen. Die benötigten
Zahlen sind analog Schritt 6 – Kostenplanung (s. Kapitel 5.6) im Unternehmen zu
ermitteln!
Im Kostenplan bilden wir über die Arbeitspakete die geschätzten Kosten ab.
Alle Aufwände, die direkt mit dem Projekt in Verbindung stehen, werden hier
aufgezeigt. Die Stunden- bzw. Tagessätze werden über die Finanzabteilung
oder das Controlling abgefragt. Aufwände sind in diesem Fall Personentage,
Werkzeuge, Materialien, Räume, Reisekosten, der Roboter selbst etc.
Ob ein Projekt Gewinn abwirft und sich rechnet, wird über Kennzahlen er-
mittelt. Eine mögliche Kennzahl ist der ROI (Return of Investment), der das
prozentuale Verhältnis von Gewinn zu investiertem Kapital angibt. Der ROI
wird berechnet, indem der Gewinn durch die Kosten geteilt wird, und dient
zumeist bei Projekten als Rendite-Evaluierungsverfahren. Soll der ROI im
Voraus berechnet werden, so müssen die anfallenden (Projekt-)Kosten und
der zu erwartende Gewinn geschätzt werden. Im Fall des Roboters würde
das investierte Kapital ins Verhältnis zur erwarteten Einsparung in der Ferti-
gung gesetzt.
5.9.7 Musterprojekt Projektorganisation und

Stakeholderanalyse
In einer vereinfachen Form der Darstellung einer Stakeholderanalyse kann ich es
mir leicht machen und zeichne die Personen oder Personengruppen, die einen
Einfluss auf mein Projekt haben können, in ein „Orbit“ ein. Dabei sind dem Zent-
rum diejenigen am nächsten, denen ich einen hohen Einfluss zuordne. In unse-
rem Beispiel ist außerhalb des Projektteams noch der Betriebsrat mit zu beachten.
Die Stakeholderanalyse kann auch wie in Schritt 7 – Projektorganisation be-

schrieben durchgeführt werden (s. Kapitel 5.7).
Abbildung 5.27 Stakeholderanalyse
Die Stakeholderanalyse wird zu Beginn des Projektes das erste Mal durchge-
führt. Es ist ein Werkzeug, um potenzielle Einflüsse durch einzelne Personen
oder Personengruppen abzuschätzen und Maßnahmen daraus abzuleiten. Wir
versuchen, im Team etwas zu visualisieren bzw. zu quantifizieren. Es ist eine
subjektive Einschätzung. Daher sollte auch die Stakeholderanalyse im Team
durchgeführt werden.
Habe ich als Projektleiter mit meinem Team die Einschätzung der Einflussgrö-
ße durchgeführt, gilt es im zweiten Schritt, zu überlegen, welche Einstellung
(positiv/negativ) die jeweilige Person zu meinem Projekt hat.
In einem dritten Schritt überlege ich dann, wie ich diese Person/Personen-
gruppe gewinnbringend in mein Projekt einbringe bzw. Störgrößen vermeide.
Auch hier können die Maßnahmen, wie dieses geschieht, entsprechend der
Situation sehr unterschiedlich sein. Die Maßnahmen können informativ sein
oder aber auch das Einbinden in das Projekt beinhalten. Es ist Aufgabe des Pro-
jektleiters und seines Teams, hier das notwendige Maß zu finden.
Beispiel Projektorganisation
Anders als die Stakeholderanalyse bilde ich in diesem Fall die direkt Beteiligten
meines Projektes ab. Also nicht Personen oder Personengruppen, die einen Ein-
fluss haben können, sondern alle, die in irgendeiner Form an meinem Projekt
direkt beteiligt sind. Optimalerweise habe ich auf einen Blick alle Ansprechpart-
ner mit Namen und Telefonnummer. Die Projektorganisation ist ein offizielles
Dokument.
Abbildung 5.28 Projektorganisation
Dem Auftraggeber wird während der gesamten Projektlaufzeit die Entwick-

lung des Projektes berichtet und etwaige Anpassungen werden mit ihm abge-
stimmt. Optimalerweise sind regelmäßige Berichtstermine fixiert.
Der Lenkungsausschuss kann unterschiedliche Zusammensetzungen haben. In

unserem Fall wären die Leiter der jeweiligen Geschäftsbereiche gut. Damit wä-
re gesichert, dass bei etwaigen Abweichungen oder Anpassungen alle relevan-
ten Entscheider an einem Tisch sitzen und schnell zu einem Ergebnis kommen
können.
Im Kernteam ist jeweils ein Vertreter der Fachbereiche mit den meisten Ar-
beitspaketen. Diese sind bei allen Kernteammeetings mit dabei und sorgen als
Schnittstelle dafür, dass in ihrer Linienfunktion alle Arbeitspakete, die im Pro-
jekt anfallen, umgesetzt werden.
Herr Schneider aus der Fertigung macht also nicht zwingend alle Arbeitspakete
selbst, sondern ist die Schnittstelle in seine Abteilung. Je nach seiner Einschät-
zung kann er Fachspezialisten zu bestimmten Fragestellungen in die Projektsit-
zungen mitbringen.
Der Steuerkreis (Lenkungsausschuss) trifft übergeordnete Entscheidungen und

ist mit den Entscheidern der Linie bzw. je nach Unternehmensgröße auch
durch die Geschäftsleitung besetzt. Der Lenkungsausschuss ist ein Entschei-
dergremium. Die Aufgabe als Projektleiter ist es, in entsprechenden Abständen
über das Projekt zu berichten bzw. bei Abweichungen des Basisplans entspre-
chende Maßnahmen zu präsentieren, die entweder eine Anpassung von Ter-
minen, Kosten oder Leistungsumfang beinhalten oder aber auch entsprechende
Korrekturmaßnahmen enthalten können.
Im unterstützenden Team sind Fachfunktionen, die nicht während der gesam-

ten Projektlaufzeit gefordert sind. Die Juristen unterstützen beispielsweise in
Zeiten der Vertragsgestaltung. Hier werden sie zu bestimmten Fragestellungen
mit hinzugezogen.
5.9.8 Risikomanagement
Im Risikomanagement beschäftigt man sich mit potenziellen Bedrohungen für
das definierte Ziel des Projektes hinsichtlich Terminen, Kosten und Leistungsum-
fang. Hierbei sind folgende Fragen relevant:
■ Welche Folgen hat das Eintreten des Risikos?

■ Wie wirkt sich das Risiko konkret aus?
■ Wie sieht die Folge der Auswirkung aus?
Tabelle 5.3 Beispiel Musterprojekt Risikomanagement
Nr. Risiko A S A×S P Gegenmaßnahmen Wer Wann
1 Lieferprobleme 3 7 35 1 Audit, enge Ab- Müller 10.06.XX

beim Lieferanten stimmung, Treffen EK
vor Ort
2 Prozessanbindung 2 8 16 2 Frühzeitige Schulte, 15.12.XX

in Fertigung Prozessanbindung F
kritisch alte Fertigungslinie
bis Aufbau beste-
hen lassen
Risikomanagement ist Teamarbeit. Die Erfahrung zeigt, dass eine Zusammen-

führung der unterschiedlichen Sichtweisen der jeweiligen Stakeholder die Qua-
lität ausmacht. Wie immer hängt der Erfolg einer Methode vom Input und da-
mit von den Beteiligten ab.
Risikomanagement beinhaltet mehrere Schritte oder Prozesse, die sich über die
gesamte Projektlebensdauer ausdehnen. Genau wie die Arbeitspakete werden
auch die Risiken über die gesamte Projektlebenszeit gesteuert.
Die potenziellen Bedrohungen (Risiken) werden im Team erörtert und entspre-

chende Gegenmaßnahmen werden definiert, damit das Risiko nicht eintritt. Es
wird ein Verantwortlicher für das jeweilige Risiko benannt, der „den Hut auf-
hat“, damit das Risiko nicht eintritt.
6 Globalisierung …
… bedeutet Vernetzung über Grenzen hinweg. Was uns aber dabei interessiert,
sind die Auswirkungen auf unsere Projekte und den Einkauf. Oder – was heißt
das für das Projektmanagement im Einkauf. In der zweiten Auflage des Buches
möchte ich diese Themen und die aktuellen Änderungen am Markt nochmals
beleuchten. Die Themen sind immer im Kontext zu sehen. Ich kann Digitalisie-
rung nicht entkoppeln von Globalisierung. Dazu kommen neue Themen, wie das
agile Arbeiten oder agiles Projektmanagement. Auch das wird Teil der Zukunft
sein. Damit werden sich auch die Führungsaufgaben und die Rollen der beteilig-
ten Personen ändern. Fangen wir hier aber erst einmal mit der Globalisierung an.
In der Theorie ist die Globalisierung die Zunahme der Intensität und der Reich-
weite grenzüberschreitender Austausch- und Interaktionsbeziehungen. Dabei
geht es um wirtschaftliche, kulturelle, technologische und politische Transaktio-
nen, Waren- und Informationsströme, um Menschenbewegungen (Tourismus,
Migration) und um Kommunikation. Globalisierung ist die Intensivierung welt-
weiter sozialer Beziehungen, durch die entfernte Orte in solcher Weise miteinan-
der verbunden werden, das Ereignisse an einem Ort durch Vorgänge geprägt
werden, die sich an einem viele Kilometer entfernten Ort abspielen, und umge-
kehrt (Anthony Giddens, 1997).
Für das Projektmanagement und den Einkauf hat es, wie vieles im Leben, Vor-
und Nachteile, da dadurch der immer härter werdende internationale Preisdruck
zum Tragen kommt. Die Globalisierung nahezu aller Bereiche der Wirtschaft
zwingt Einkäufer und Projekteleiter, sich auch außerhalb der Grenzen Deutsch-
lands und damit in anderen Rechts-, Sprach-, und Kulturbereichen nach günsti-
gen Beschaffungsquellen umzusehen. Dies gilt heutzutage nicht mehr nur für
Konzerne, sondern auch der Mittelstand muss in Zukunft weltweit beschaffen,
um seine Wettbewerbsfähigkeit zu erhalten und zu verbessern. Die Zahl der
Lieferanten aus Billiglohnländern ist in den letzten Jahren erheblich angestiegen.
Waren es am Anfang nur einzelne Teile, werden heute komplette Baugruppen,
Dienstleistungen sowie komplette Produkte verlagert und dadurch auch mehr
und mehr Lieferanten im Ausland lokalisiert. Immer mit dem Ziel, die Produk-
tivität des Einkaufs und damit auch die des Unternehmens zu steigern. Das soge-
nannte Global Sourcing wird ein strategisches Instrument. Bedingt durch die
Globalisierung und die immer schnellere Kommunikation durch das World Wide
Web wurde auch der Markt für eine internationale Beschaffungsstrategie geöff-
net. Dies bringt auch einige Herausforderungen sowie Risiken mit sich. Was über
Jahre eine Chance war, hat sich im Rahmen der Corona-Krise als massives Pro-
https://doi.org/10.1007/978-3-658-31310-4_6
blem erwiesen. Produkte konnten nicht einfach beim Lieferanten um die Ecke
abgeholt werden, sondern die globalen Lieferketten brachen für einen Zeitraum
nahezu komplett zusammen.
Neben der Globalisierung kamen auch noch Themen wie Digitalisierung und
Einkauf 4.0. hinzu. Themen, auf die ich im weiteren Verlauf noch kurz eingehen
möchte.
Aber was heißt das konkret?
Was ist Globalisierung? Bei der Globalisierung spielen die normalen Grenzen
eines Staates eine immer geringere Rolle. Waren und Informationen werden über
Grenzen hinweg verkauft und transportiert. Für den Einkauf bedeutet Globalisie-
rung die Lokalisierung von Lieferanten über die Landesgrenzen hinaus, mit dem
Ziel, Wettbewerbsvorteile anderer Standorte hinsichtlich der Produktion von
Waren zu nutzen. Als Einkäufer entwickelt sich die neue Rolle vom Spezialisten
zum Generalisten. Der Einkäufer wird Projektmanager im internationalen Um-
feld – eine Herausforderung auf vielen Ebenen. Auch wenn die Versorgung mit
Produkten aus anderen Ländern so alt ist, wie der Handel selbst, heißt das vom
Beschaffer zum Schnittstellen-, Projekt- und auch Risikomanager. Chancen und
Risiken gilt es vorab abzuwägen. Eine einfache Bestellung ist nicht mehr möglich,
da einige weitere Einflussgrößen auf die Beschaffung wirken. Die Politik des
Landes, Fracht, Zölle, Transportmöglichkeiten, Logistik, Verpackung, um nur
einige Beispiele zu nennen.
Fazit
 Durch die Globalisierung kommt es sowohl für die Einkaufsprozesse als

auch für die Projektprozesse zu neuen Herausforderungen.
 Grenzen werden überschritten, neue Kulturen und damit neue Herausfor-

derungen kommen auf uns zu.
 Zeit und Reaktionsgeschwindigkeit, und auch die Erwartung an diese,

nehmen zu.
 Projektmanagement im Einkauf bekommt eine neue Facette und die Rolle

des Einkäufers wird neu definiert.
 Der Einkäufer als Schnittstellenmanager und Projektleiter.
Wenn wir uns nochmal das Wort „global“ ansehen, dann bedeutet dies in unse-
rem Alltag, dass die Tätigkeit nicht mehr oder nicht allein in unserer eigenen
Umgebung stattfinden wird. Wir überschreiten Grenzen, Länder und auch Kul-
Historie und Entwicklung Globalisierung 115
turen. Die Welt ist enger zusammengerückt. Darüber hinaus kommen noch wei-
tere Einflüsse hinzu. Dies gilt es sowohl in Projekten als auch bei der Lokalisie-
rung neuer Lieferanten zu beachten. Wir müssen noch zielorientierter und strate-
gischer vorgehen, als dies bisher bereits der Fall war. Methoden, wie Stakeholder-
Analyse oder Risikomanagement gehören genauso zu unserem Handwerkszeug,
wie die Analysen unsers Portfolios und der Lieferanten (siehe Kapitel 7). Dieses
Vorgehen setzt einen guten Prozess voraus, damit das Risiko einer neuen Be-
schaffungsstrategie im Rahmen gehalten wird.
Hier einmal nur einige Einflüsse, die für uns Herausforderungen bedeuten kön-
nen.
Abbildung 6.1 Skizze Einflussgrößen bei der Globalisierung
6.1 Historie und Entwicklung Globalisierung

Wann und wie kam es überhaupt zur Globalisierung? Hier streiten sich ein wenig
die Geister. Während die einen sagen, die Globalisierung ist so alt wie die
Menschheit selbst, definieren andere den Beginn der Globalisierung eher in den
achtziger Jahren. Die neuen Kommunikationsmöglichkeiten bildeten bei der
Globalisierung einen wesentlichen Faktor. Während noch in den siebziger Jahren
bei einem Austausch als Student oder Schüler die Informationen über Telefon
und Briefe stattgefunden haben, so konnte man schon einige Jahre später Freunde
und Familie über Facebook, WhatsApp und oder ähnliche Medien an seiner Reise
teilhaben lassen. Die Welt schrumpfte in Geschwindigkeit zusammen. Als ich in
den achtziger Jahren meinen ersten Job bei Daimler Benz antrat, war das damals
moderne E-Mail-System in der Lage, mit Mercedes in USA intern zu kommuni-
zieren. Wir hatten einen Abteilungs-PC und die Arbeit fand noch auf der DOS-
Oberfläche statt. Heute überhaupt nicht mehr vorstellbar.
Wenn wir uns bewusst machen, dass die erste E-Mail erst am 3.8.1984 in Karls-
ruhe empfangen wurde, dann wird deutlich, wie jung eigentlich noch die schnel-
len Kommunikationswege sind. Die erste E-Mail ging an die Adresse von
Rotert@germany. Michael Rotert, geboren 1950, war in den achtziger Jahren wis-
senschaftlicher Mitarbeiter am Institut für Telematik der Universität Karlsruhe.
Er betreute das Rechenzentrum der Fakultät Informatik, wo er den ersten Mail-
server Deutschlands einrichtete – im Keller, auf einem VAX 11/750 mit dem Unix-
Betriebssystem BSD.
Danach erfuhr die Globalisierung eine rasende Beschleunigung. Die internatio-

nalen Verflechtungen auf allen Ebenen wurden vereinfacht. Lieferanten wurden
weltweit lokalisiert, Low Cost Countries für Einsparungspotentiale genutzt, die
Lieferanten weltweit gesucht. Dies hat für Einkäufer viele Chancen, birgt aber
auch viele Herausforderungen. Die Rolle verändert sich. Die Supply Chain der
Produkte hat viele Einflussgrößen auf dem Weg vom Hersteller bis zum Waren-
eingang. Der Einkäufer sieht neuen Herausforderungen entgegen und Global
Sourcing hält Einzug. Ziel ist immer wieder, eine Einsparung der Kosten zu erzie-
len. Die sogenannten LCC (Low Cost Countries) spielen insofern eine besondere
Rolle, dass wir hier auch meist über ein niedriges Lohnniveau reden und dadurch
besonders arbeitsintensive Produkte verlagert werden. Das heißt aber auch, dass
Cost Break Down und Supply Chain Management zu unserem Tagesgeschäft und
vor allem, in unseren Werkzeugkasten gehören.
Die Anforderungen an die Skills des Einkäufers gehen durch die Globalisierung
sehr schnell über die Einkaufskompetenz hinaus. Eine strategische Heran-
gehensweise ist notwendig, um sowohl das richtige Land und dann den richtigen
Lieferanten für das benötigte Produkt herauszufiltern. Da wir uns nun nicht mehr
nur in unserem Kulturkreis bewegen, ändern sich auch die Spielregeln, Sprach-
und Rechtsbereiche. Kenntnisse über die weltweiten Beschaffungsmärkte, Ein-
bindung vieler Schnittstellen, Total Cost of Ownership, innovative Logistikkon-
zepte sind nur einige Stichworte, die zur neuen Rolle des Einkäufers führen und
damit auch zur Notwendigkeit von Projektmanagement. Der Einkäufer ist auf
dem Weg in eine neue Rolle.
Herausforderung von Projekten im internationalen Umfeld 117
Fazit
 Die Globalisierung bekam in den achtziger Jahren durch neue Kommunika-

tionswege eine rasante Beschleunigung.
 E-Mails eröffneten Wege in die weite Welt und die Kommunikation wurde
einfacher. Während vorher lange Postwege und teure Telefonate die Optio-
nen waren, so konnten nun in Sekunden Informationen von einem Ende der
Welt an das andere gesendet werden.
 Es ergeben sich ganz neue Lieferantenmärkte, die gesteuert werden wollen.
6.2 Herausforderung von Projekten im

internationalen Umfeld
Natürlich stellen uns internationale Projekte vor noch mehr Herausforderungen,
als dies nationale Projekte bereits tun. Woran liegt das? Ganz einfach, es ist die
Komplexität, die sich nochmals erweitert. Die „8 Schritte“ bleiben erhalten, ver-
ändern sich aber in Ihren Herausforderungen. Die Themen erweitern sich um
viele Komponenten. Allein die Sprache, auf die sich geeinigt werden muss und
die nicht von allen gleich verstanden wird. Kulturelle Unterschiede, wie Arbeits-
kultur, Werte und Normen, Verständnis von Zusagentreue, und nicht zu verges-
sen, rechtliche und politische Aspekte. Dies sind nur einige Beispiele, die plötz-
lich ein anderes Gesicht bekommen.
Checkliste vor dem Start eines internationalen Projektes:
■ Wer leitet das Projekt?

■ Stakeholderanalyse ist durch kulturelle und politische Unterschiede ein
„Muss“ in einem solchen Projekt.
■ Projektumfeldanalyse – Was beeinflusst unser Projekt noch?

■ Nutzwertanalyse – Was ist uns wichtig?
■ Paarweiser Direktvergleich – Herausfiltern der für uns relevanten Kriterien.
■ Risikomanagement – Welche besonderen Risiken können durch ein internati-
onales Projekt in einem anderen Land auftreten?
■ Wie wird das Team zusammengesetzt sein? Wie unterschiedlich ist das Wer-
tesystem der beteiligten Personen und welchen Einfluss auf das Projektge-
schehen könnte es haben?
— Wie können wir die Phasen der Teamentwicklung in einem solchen Um-
feld ideal gestalten?
■ Wie wollen wir das Projekt starten? Wo und in welcher Form soll das Kick-
Off stattfinden.
— Haben wir die Chance für ein Treffen?

— Welche Methoden der Kommunikation kommen zum Einsatz?
■ Kommunikation
— Wie ist die Projektsprache?
— In welcher Sprache wird dokumentiert?
— Wie gestalten wir die Teammeetings? Welche Uhrzeiten sind für alle mög-
lich?
■ Wie kann die Zusammenarbeit mit ausländischen Dienstleistern, Lieferanten

oder auch Kooperationspartnern aussehen?
■ Wie ist die Vertragslage, wenn es mal nicht so gut läuft? Wo ist der Gerichts-
stand?
■ Welche Technik steht zur Verfügung – Video- oder Webkonferenz?

■ Wie soll kommuniziert werden – per E-Mail, Chat oder Telco?
Was hier erst einmal sehr einfach zu lösen klingt, kann im Alltag tatsächlich zu
Herausforderungen führen. Daher ist es umso wichtiger, diese Themen bereits
beim Aufsetzen des Projektes zu klären und vor allem Spielregeln für das Arbei-
ten im Team festzulegen. Als Projektleiter ist es umso wichtiger, sich zu überle-
gen, wie und in welcher Form das Projekt gesteuert werden kann und wie ich bei
solch komplexen Projekten zeitnah zu den für mich und das Team relevanten
Informationen komme.
Auch die Frage nach Eskalationsschritten im Worst Case sollte bereits am Anfang
geklärt sein. Erfahrungsgemäß wird es umso schwieriger, wenn das Kind erst
einmal in den Brunnen gefallen ist.
Immer daran denken, es ist nicht falsch, wenn eine Partei Schach spielt und die
andere Partei Monopoly. Leider kommt man dabei aber nicht auf einen Nenner.
Die Rolle des Einkäufers im globalen Umfeld 119
Wir müssen uns frühzeitig auf ein Spiel einigen, damit es nicht im weiteren Ver-
lauf des Projektes zu Konflikten führt, die man hätte vermeiden können.
Fazit
 Spielregeln für ein erfolgreiches Projektmanagement am Anfang des Projek-

tes festlegen.
 Dies gilt sowohl für Planung, Steuerung und Themen sowie für die Kom-
munikation, aber auch für den Fall eines Konfliktes.
Die GPM hat im Jahr 2002 auf dem Weltkongress eine Studie veröffentlicht, die in
Ihrer Kernaussage immer noch Gültigkeit hat.
Abbildung 6.2 Herausforderungen internationaler Projektarbeit (Quelle:

O. Scherer, Vortrag auf dem IPMA Weltkongress 2002)
50
45
40
35
30
25
20
15
10
5
0
1 2 3
Spalte1 Technische Aspekte Arbeitskultur

Politisch rechtliche Aspekte Infrastruktur Projektmanagment
Sprache andere
6.3 Die Rolle des Einkäufers im globalen

Umfeld
Was muss der Einkäufer als Projektmanager im globalen Umfeld im Auge haben?
Wenn wir vor einiger Zeit über „den Einkauf“ gesprochen haben, so wurde die-
ser Begriff hautsächlich mit dem operativen Einkaufsgeschäft verbunden. Im
klassischen Sinne das Bestellwesen, der Angebotsvergleich und die Preisverhand-
lung. Die Aufgaben und Ziele gehen hier über die termingerechte Versorgung
der anfordernden Bereiche mit Produkten und/oder Leistungen) in der richtigen
Menge, am vorbestimmten Ort, in der vorgesehenen Qualität hinaus (Arnold
1997, S.66).
Durch die Globalisierung wurde im Einkauf die Methode Projektmanagement als

Werkzeug notwendig. Hier begann auch eine neue Ära. Strategische Anforde-
rungen und Führungskompetenz wurden notwendig. Mit dem Einkauf 4.0 und
der Digitalisierung werden die Herausforderungen noch einmal komplexer.
Nichts ist so beständig wie der Wandel, hat bereits Heraklit gesagt.
Die strategische Ausrichtung auf den internationalen Beschaffungsmarkt wurde

eine Notwendigkeit, um wettbewerbsfähig zu bleiben. Dadurch wird auch klar,
dass wir uns mit der neuen Rolle anfreunden müssen. Sie fordert auch entspre-
chende neue Kompetenzen. Während die junge Generation schon fast mit dem
Handy geboren wurde, sind die Digitalisierung und das papierlose Büro für
meine Generation noch nicht gängig.
Im strategischen Einkauf hat durch die Globalisierung auch das Thema Projekt-
management eine wichtige Rolle eingenommen. Die Digitalisierung wird ein
Großprojekt mit eigenen Herausforderungen.
Wenn wir weltweit einkaufen wollen, ist das Ziel, Ressourcen, die lokal nicht
vorhanden oder teurer sind, global zu beschaffen. Die hiermit verbundenen Risi-
ken müssen den vermeintlichen Chancen vorab gegenübergestellt werden. Fo-
kussieren wir uns allein auf das monetäre Einsparungspotential, kann es sehr
schnell teuer werden. Daher ist es umso wichtiger, strategisch zu prüfen, für
welche Produkte oder Teile davon es von Vorteil ist, bzw. welche Teile besser
lokal bleiben. Eine gute Methodenkompetenz des Einkäufers ist notwendig, um
die Transparenz bei solchen komplexen Herausforderungen nicht zu verlieren.
Erst einmal ist es wichtig, eine eigene Standortbestimmung der Daten zu machen,
unser eigenes Ziel zu definieren und dann eine für das Projekt gute Risikoanalyse
durchzuführen. Die Risiken können sich ganz unterschiedlich zeigen. Ich habe oft
Die Rolle des Einkäufers im globalen Umfeld 121
erlebt, dass selbst die notwendige Reisezeit bei Qualitätsproblemen eine Heraus-
forderung wurde. Ebenso haben die Kultur des Landes, das Wertesystem, die
Sprache und natürlich auch der Transport der Teile ihren Einfluss auf die Pro-
dukte und die Arbeit. Ein gutes Risikomanagement, aufgeteilt nach entsprechen-
den Risikogruppen (z. B. Umwelt, Politik, Kultur, Technik, …) über den gesamten
Projektverlauf ist hilfreich.
An dieser Stelle wird deutlich, welchen Einfluss die Rolle des Einkäufers im Glo-
bal-Purchasing-Bereich in Zukunft haben wird. Der Verantwortungsbereich wird
mehr und mehr erweitert. Themenblöcke wie Nachhaltigkeit kommen hinzu. Es
ist nicht mehr nur die Beschaffungsstrategie für die unterschiedlichen Material-
gruppen, sondern die Koordination zur Umsetzung der anfallenden Aufgaben,
Risiken und Projekte im Unternehmen. Sehr oft ist eine der Herausforderungen
die Leitung und Koordinierung der Kommunikation zwischen den diversen
Schnittstellen, wie den Einkaufsteams, der Entwicklung, der Produktion, den
Endverbrauchern und natürlich auch den Lieferanten. Im Rahmen der Globalisie-
rung erarbeiten Sie mit den Schnittstellen neue Beschaffungsmöglichkeiten. Im-
mer mit dem Ziel, Einsparungen zu generieren und dabei die Balance zwischen
Chance und Risiken überschaubar zu halten.
Fazit
 Die Globalisierung verändert die Herausforderungen, die es zu bewältigen

gilt.
 Dadurch wird die Rolle des Einkäufers im Unternehmen nochmals kom-

plexer.
 Neben der Fachkompetenz ist Methoden- und Sozialkompetenz unerläss-

lich.
 Die Rolle des Beschaffers werden mehr und mehr IT-Systeme übernehmen
(siehe Kapitel Digitalisierung), während die Rolle des Projektmanagers im
Einkauf eine größere Bedeutung erlangt.
Abbildung 6.3 Anforderungen und notwendige „Skills“ des Einkäufers in der

globalen Welt.
6.4 Werkzeuge und Methoden zur

Vorbereitung einer internationalen
Einkaufsstrategie
Wir haben nun einiges über die Anforderungen an die Rolle des Einkäufers in
einer globalen Welt erfahren. Um Transparenz in den Projekten halten zu kön-
nen, werden Werkzeuge und Methoden benötigt. Schnelle Reaktionsgeschwin-
digkeit und gute Preise sind dabei gesetzt. Im Verlauf dieses Kapitels möchte ich
einige Methoden aufzeigen. Diese sollen dabei unterstützen. Es ist wichtig, eine
gute Struktur zu entwickeln, damit die Menge der auf uns zu kommenden Auf-
gaben noch handelbar bleibt.
Das Ziel der Werkzeuge ist im stressigen Alltag immer, den Überblick und die Transpa-
renz zu behalten und damit sich selbst effiziente Handlungsoptionen zu erarbeiten.
Werkzeuge und Methoden zur Vorbereitung einer internationalen Einkaufsstrategie123
Welches Wissen benötigen wir?
1. Die eigenen Kennzahlen und Daten im Unternehmen
2. Materialgruppenstruktur
3. Ziel der Globalisierungsstrategie
4. Informationen über das Marktgeschehen und die Einflussgrößen dazu
5. Chancen und Risiken, die die getroffenen Entscheidungen hinsichtlich inter-

nationaler Lieferanten mit sich bringt.
Warum gehen wir Global?
Die Antwort ist einfach: Wir suchen den Preisvorteil, der sich durch die Beschaf-
fung in anderen Ländern ergeben kann. Allein der Preis ist aber nicht ausschlag-
gebend. Die Anforderungen an die Produkte sollten vorab gut definiert sein.
Eine Nutzwertanalyse kann hier unterstützen.
Fragen wie schnelle Verfügbarkeit, Zuverlässigkeit, müssen in der Supply Chain

mit in Betracht gezogen werden, um im weiteren Verlauf keine zusätzlichen Pro-
bleme in der Lieferkette zu bekommen.
Eine gute und erfolgreiche Marktanalyse setzt Wissen über die eigene Ist-Situa-
tion voraus. Hier geht es um das Thema Materialgruppensegmentierung, Portfo-
lioanalyse, Kennzahlen-Know-how.
Wir machen uns immer wieder Gedanken, warum Projektmanagement notwen-

dig ist. Bedingt durch die Komplexität der Veränderung in solchen Strukturen, ist
ein Arbeiten in der Linie nicht ausreichend. Es ist eine gute Organisationsstruktur
notwendig, die für solche Herausforderungen besser geeignet ist. Eine davon ist
das klassische Projektmanagement. Im weiteren Verlauf wollen wir uns natürlich
auch noch ansehen, welche Rolle agile Methoden oder das agile Projektmanage-
ment spielen – hier aber erst einmal die Veränderung, die ein solches Arbeiten
erst notwendig macht.
Es gilt, zuerst einmal folgende Fragen zu beantworten:
■ Was kaufen wir ein?

■ Von wem kaufen wir ein?
■ Wie kaufen wir ein?
■ Was sind die Charakteristika der Ausgaben-Matrix?
Um diese Marktanalyse zielgerichtet durchführen zu können, ist eine Aufarbei-

tung der eigenen Daten unerlässlich. Folgendes Vorgehen ist sinnvoll, um die
globalen Projekte strategisch angehen zu können.
1. Materialgruppenmanagement: Eine Materialgruppe ist demnach eine sinnvol-

le Zusammenfassung mehrerer Materialien, die eine gewisse Homogenität
besitzen, z. B. Gussteile, Dichtringe, ...
2. Die Analyse der eigenen Produkte bzw. der eigenen Materialgruppe
‒ Pareto zur Analyse der Top-Lieferanten mit dem höchsten Umsatz
‒ Nutzen: größten Hebel kennen
 Ausgaben-Matrix – Analyse, wo und was der Lieferant im Unterneh-
men global liefert
‒ Nutzen: schnelle, qualitative und quantitative Analyse der zu beschaffen-
den Produkte oder Services
 Lieferantenauswertung
‒ Nutzen: Priorität der Lieferanten kennen für eine entsprechend gute Basis
in den Verhandlungen
3. Externe Umfeldbetrachtung zur Risikoabschätzung (Porters Five Forces)

‒ Nutzen: Kenntnis potentieller Einflussgrößen des Marktes, der Wettbe-
werber und auch der Lieferanten auf dem Markt und Ausrichtung der
entsprechenden Strategie
4. Preisanalyse – Supply-Chain-Betrachtung und Cost Break Down

‒ Nutzen: Bessere Beurteilung der preislichen Vorteile eines Landes auf Ba-
sis des Cost Break Downs, der entsprechenden Kostenelemente und der
Kostentreiber eines Produktes (z. B. Lohnkosten)
5. Festlegung der Kriterien für die Lieferantenauswahl, basierend auf einer

Nutzwertanalyse bzw. einem paarweisen Direktvergleich
‒ Nutzen: Die Entscheidungen analytisch zu gestalten. Das heißt, welche
Lieferanten erfüllen die für uns wichtigen Kriterien am besten und welche
nicht.
6. Lieferantenauswahl und Risikomanagement

‒ Nutzen: Welche Chancen und Risiken verändern sich für ein bestimmtes
Land oder einen bestimmten Lieferanten?
7. Verhandlung und der Vertragsabschluss

‒ Nutzen: Neuen Lieferanten unter Vertrag bringen unter Berücksichtigung
der bereits erwähnten Methoden.
Analyse der Kennzahlen 125
Abbildung 6.4 Pyramide zur strategischen Lieferantenauswahl im globalen

Umfeld
6.5 Analyse der Kennzahlen

Es gibt unterschiedliche Ansätze für eine Ist-Zustand-Analyse der eigenen Daten
und jeweiligen Materialgruppen sowie Preisstrukturen. Einen Anfang macht die
Pareto-Analyse. Diese ist nicht allein auf den Einkauf ausgelegt, sondern kann
viele Einsatzmöglichkeiten haben.
6.5.1 Pareto-Analyse
Die ABC-Analyse basiert auf der sogenannten 80/20-Regel oder der Pareto-Regel.
Damit lassen sich die Lieferanten oder Produkte in der „A-Klasse“ identifizieren.
Für diese können Sie spezielle Maßnahmen und Prioritäten planen. Welche das
im Einzelnen sind, hängt von den Zielen und Fragen ab, die Sie mit der ABC-
Analyse erreichen oder beantworten wollen. Dass diese Unterscheidung wichtig
ist, hat bereits Vilfredo Pareto erkannt. Seine Untersuchungen haben gezeigt, dass
in vielen Fällen mit 20 Prozent Aufwand 80 Prozent des Ertrags erwirtschaftet
werden. Diese Erkenntnis wird als 80/20-Regel oder Pareto-Regel bezeichnet. Sie
lässt sich auf viele Bereiche des Unternehmens anwenden, so auch bei der Priori-
sierung von Lieferanten. Übersetzt heißt die Regel für Einkäufer:
■ mit 20 % der Lieferanten werden 80 % des Umsatzes gemacht bzw. 20 % der

Einkaufteile machen 80 % des Einkaufwerts aus, oder:
■ mit 20 % Aufwand für Planung und Handling von Einkaufsteilen werden

demnach 80 % des im Umlaufvermögen gebundenen Kapitals gut gemanagt.
Wir wollen mit dieser Methode einen strategischen Überblick über die wichtigs-
ten Daten und Kennzahlen der aktuellen Lieferanten erhalten. Die Auswertung
dieser Daten erleichtert die Marktanalyse. Wie kann Pareto für die Auswertung
von Lieferantendaten genutzt werden?
■ Auf der Y-Achse wird der Umsatz des Lieferanten im gesamten Unternehmen
eingetragen. Hier sollten auch Daten aus anderen Materialgruppen bzw. an-
deren Standorten eingetragen werden.
■ Auf der X-Achse werden die Lieferanten zugeordnet.

■ In unserem Beispiel wurden die Lieferanten in Kategorien eingeteilt.
■ A = Lieferanten mit dem höchsten Einkaufsvolumen. Üblicherweise werden
80 % des gesamten Einkaufsvolumens mit 20 % der Lieferanten gemacht.
Unser Ziel ist es immer, den höchsten Effekt mit dem geringsten Aufwand zu
erzielen. Dies setzt eine gute strategische Ausrichtung voraus. Pareto ist ein
Werkzeug, um einen Überblick zu den relevanten Produkten und auch Lieferan-
ten zu erhalten. Wir verschaffen uns zunächst eine Übersicht über alle Lieferan-
ten unserer Materialgruppen und strukturieren diese nach entsprechendem Ein-
kaufsvolumen. Die A-Lieferanten sind diejenigen mit dem höchsten Volumen.
Auf einen Blick kann man in der graphisch dargestellten Pareto-Analyse eine
Aussage dazu machen.
Abbildung 6.5 Pareto-Ausgaben-Analyse der aktuellen Lieferantenbasis
% Ausgaben aller Lieferanten
A B C
20 % 50 % 100 %
alle Lieferanten
6.5.2 Die Ausgaben-Matrix

Das Ziel der Ausgabenmatrix ist, aus möglichst detaillierten Daten eine Aussage
über die eigenen Materialgruppen und Ausgaben je Lieferant machen zu können.
Daraus können dann entsprechende strategische Maßnahmen abgeleitet werden.
Hierfür benötigen wir folgende Daten.
■ Lieferanten, mit denen wir Umsatz machen

■ Umsatz der Lieferanten – auch Umsatz, der mit dem Lieferanten außerhalb
unseres Standortes und unserer Materialgruppe getätigt wird
■ Produkte, die der Lieferant an unser Unternehmen bzw. Töchter unseres Un-
ternehmens liefert
Fragen, die hierbei aufkommen können:
■ Wo können Bündelungseffekte erzielt werden?

■ Gibt es im Unternehmen unterschiedliche Preise eines Produktes vom glei-

chen Lieferanten?
■ Gibt es Produkte, die wir zusätzlich von diesem Lieferanten beschaffen könn-
ten, um daraus Bündelungseffekte zu erzielen?
■ Wie viel Gesamtumsatz macht der Lieferant mit uns? Wie hoch ist dabei das
Risiko?
Tabelle 6.1 Kostenstruktur der Lieferanten im Konzern
Lieferant Produkt A Produkt B Produkt C
Standort A ... €/Jahr ... €/Jahr ... €/Jahr Einkaufsvolumen/

Standort gesamt
Standort B ... €/Jahr ... €/Jahr ... €/Jahr
Standort C ... €/Jahr ... €/Jahr ... €/Jahr
Standort Z ... €/Jahr ... €/Jahr ... €/Jahr
Einkaufsvolumen
je Produkt gesamt
Sobald diese Kennzahlen vorliegen, kann eine Aussage über die aktuelle Situa-
tion der Materialgruppe getroffen werden.
Habe ich diese Kennzahlen, so lässt sich bereits eine Aussage über mögliche Bün-
delungen, oder auch in Kombination mit einer Marktanalyse, über andere Länder
bzw. andere Märkte nachdenken. Für alle diese Methoden ist ein gutes Projekt-
management notwendig. Das Arbeiten in cross-funktionalen Teams ist unerläss-
lich, um im Einkauf entsprechend strategisch agieren zu können. Aus meiner
Ausgabenmatrix kann eine Beschaffungsanalyse erarbeitet werden.
Folgende Daten werden benötigt:
■ Preis pro Bauteil, Produkt oder Komponente

■ Preise je Lieferant
■ Preise je Standort
■ Zahlungskonditionen
■ Vertragsbedingungen
■ Transportkosten
■ Volumen beschafft durch den Bereich oder Standort
■ Einkaufsvolumen je Lieferant
■ Logistik, Vereinbarung, Verpackung, Lieferzeit, ...
Fazit
 Eine gute Aufbereitung der Ist-Daten in Form einer Ausgabenmatrix ist

notwendig, um entsprechende Lieferantenmärkte neu erschließen zu kön-
nen.
 Die Zahlen und Daten meiner Materialgruppe dienen als Basis, um eventu-
elle Einsparungen durch globale Projekte realisieren zu können.
6.5.3 Total Cost of Ownership und die Projekte im

Einkauf
Der moderne Einkauf setzt an vielen Stellen gute Projektarbeit voraus. Das Ziel
ist immer kosteneffizient zu arbeiten. Etwa 75 % der Kosten eines Produktes
werden bereits in der Entwicklung festgelegt. Im Umkehrschluss macht es daher
Sinn, den Einkauf bereits sehr früh in das Projekt mit zu integrieren. Auch „Ein-
kaufsgurus“, wie Prof. Dr. Horst Wildemann, beschreiben das „Advanced Pur-
chasing” so, dass die Aufgaben des Einkaufs bereits Bestandteil des Produktent-
stehungsprozesses sind. So wird jeder Einkäufer entweder Projektleiter, Teilpro-
jektleiter oder zumindest Inhaber von einem oder mehreren Arbeitspaketen.
Was ist das Ziel einer solchen Vorgehensweise? Hier ein paar Antworten:
■ Optimierte Produktentstehungsseite / Kosten bereits während der Produkt-

entstehung aus Sicht des Einkaufs betrachten
■ Reduzierung von Projektkosten

■ Frühzeitige Einbindung des Einkaufs und der Lieferanten reduziert Liefer-
engpässe und Kosten
■ Optimierung der Entwicklungsleistung und der Entwicklungskapazität

■ Verbesserung der Prozesssicherheit

■ Erhöhung der Qualität
■ Reduzierung der Komplexität
■ Aufbau von Systemkompetenz
■ Risikominimierung
Nun aber zur Methode. Was genau bedeutet eigentlich Total Cost of Ownership?
Hier sprechen wir über die gesamten Kosten eines Produktes. Wir schauen nicht
mehr allein auf die Entstehungskosten, sondern an dieser Stelle über eine Ge-
samtkostenbetrachtung. Ist ein zu beschaffendes Produkt ausgewählt, so gilt es,
die kompletten Prozesskosten zu ermitteln. In diesem Fall ist das cross-funktio-
nale Team zusammenzubringen. Für den Einkäufer bedeutet dies, die Projekt-
manager-Rolle zu übernehmen und die entsprechenden Schnittstellen zusam-
menzubringen.
Bei einem zu entwickelnden Produkt können dies sein:
■ Entwicklung
■ Juristen
■ Controlling
■ Produktion
■ Logistik
■ Elektroniker
■ IT
■ Wareneingang
■ … und weitere wichtige Fachabteilungen
In Bezug auf die zu betrachtenden Kosten wären dies:
■ Teilepreise und Nebenkosten, abzüglich eventueller Rabatte oder Skonti

■ eventuelle Finanzierungskosten – gegebenenfalls unter Berücksichtigung des
internen Zinssatzes für eingesetztes Eigenkapital sowie der Opportunitätskos-
ten, die entstehen, wenn die Mittel nicht für andere Zwecke eingesetzt wer-
den können, die eventuell mehr Gewinn brächten
■ Logistik- und Lieferkosten, Transport

■ Zölle
■ Installations-, Montage- und Anfahrtskosten
■ Kosten für die Einweisung und Schulung von Mitarbeitern
■ Änderungen oder Anpassungen von internen Prozessen
Fazit
 Bei dieser Methode werden die pro Produkt anfallenden Kosten jedem Pro-
zessschritt zugeordnet – immer mit dem Ziel, entsprechende Einsparungen
und Stellgrößen finden zu können.
 Wir betrachten nicht mehr nur die Beschaffung des Produktes, sondern
schauen uns den gesamten Lebenszyklus und die dabei anfallenden Kosten
an.
 Durch die Aufgliederung in einzelne Schritte kann auch die Bewertung

einer eventuellen Verlagerung zu einem globalen Lieferanten oder die Er-
weiterung des Lieferantenpanels besser bewertet werden.
 Alle Methoden dienen dem Ziel einer besseren Aussagekraft hinsichtlich

strategischer Entscheidungen für die Zukunft.
Um Kosteneinsparungen zu generieren, reicht es nicht mehr aus, nur mit den

Lieferanten zu verhandeln. Wir greifen auch in Material, Prozess oder die Tech-
nologie ein. Dadurch erreichen wir eine Aufschlüsselung der einzelnen Kosten in
Kostentreiber und Kostenelemente über die gesamte Produktentstehungszeit.
Und somit auch über die gesamten Supply Chain. Für diese Supply-Chain-
Betrachtung ist das Know-how diverser Schnittstellen im Unternehmen notwen-
dig. Im erweiterten Sinn werden nicht nur die Entstehungskosten angesehen,
sondern auch die folgenden Life-Cycle-Kosten. Auch wenn das Wort TCO (Total
Cost of Ownership) in aller Munde ist, so gibt es noch keine verbindliche Vor-
schrift, wie die Berechnung erfolgen kann. Wir wollen dies auch hier nur unter
dem Aspekt der Lieferantenauswahl im globalen Umfeld tun.
Abbildung 6.6 Skizze Total Cost of Ownership – Kostenbetrachtung bei früh-

zeitiger Einbindung des Einkaufs (75 % der Produktkosten
werden in der Entwicklung festgelegt.)
Kosten
Beeinflussung der Produktkosten

in der Entstehung
Idealerweise Einbindung
des Einkaufs
Zeit
Projektplanung Konkretisierung Projektumsetzung
Fazit
 Total Cost of Ownership (TCO) im Zusammenhang mit einem Cost Break

Down gibt uns die Möglichkeit, die anfallenden Kostenelemente und Kos-
tentreiber eines Produktes in den einzelnen Phasen zu betrachten.
 Die Kombination beider Methoden hat das Ziel, eine Vergleichbarkeit von
Preisangeboten zu ermöglichen.
6.5.4 Die Kraljic-Matrix als Unterstützung zur

Lokalisierung
Peter Kraljic hat im Jahr 1983 eine weitere strategische Betrachtungsweise für die
Strukturierung des Einkaufsportfolios entwickelt. Am besten funktioniert diese
Betrachtung in Bezug zu einer Materialgruppe und ihren entsprechenden Pro-
dukten. Die Analyse unterstützt und gibt Aussagen über die Art des jeweiligen
Lieferanten. Sie bezieht sich auf der X- und der Y-Achse auf zwei Dimensionen.
a. die Gewinnauswirkung
b. das Beschaffungsrisiko
Sämtliche Einkaufsprodukte, Artikel oder Materialien eines Unternehmens lassen

sich nach jeweiligem Risiko, der Komplexität und dem Einfluss auf das Betriebs-
ergebnis in einer Matrix erfassen.
Kraljic hat aus diesen beiden Dimensionen folgende Struktur für die zu beschaf-
fenden Produkte entwickelt.
■ strategische Produkte
■ Engpassprodukte
■ Hebelprodukte
■ unkritische Produkte
Allgemeine Empfehlungen für das strategische Vorgehen leiten sich aus den
Normstrategien für die Beschaffungstypen ab, sollten jedoch immer auch die
einzelnen Marktsituationen berücksichtigen (vgl. Heß, Supply-Strategien, S. 36).
Diese Art der Struktur ermöglicht einen anderen Blick auf die Auswahl von Lie-
feranten. Engpassprodukte oder auch strategische Produkte bedeuten bei einer
globalen Beschaffung ein anderes Risiko, als die unkritischen Produkte.
Haben wir das Produkt entsprechend zugeordnet, so können wir weitere Aussa-
gen über das entsprechende Risiko eines neuen Lieferanten an einem anderen
Standort machen.
Abbildung 6.7 Kraljic-Matrix
Risiko hoch
Experten Top-Lieferant
Preislich gute
Basislieferanten Lieferanten
Preis
Die Matrix besagt, dass ein Produkt mit hohem Preis und auch hohem Risiko
(komplexe Produkte) nur bei Top-Lieferanten gesourct werden sollte. Umgekehrt
kann ein Produkt mit niedrigem Preis und auch niedrigem Risiko bei Basisliefe-
ranten beschafft werden. Selbige sind somit einfacher zu finden.
In der Matrix wird der Bezug zwischen dem Risiko eines zu beschaffenden Pro-
duktes und dem Preis hergestellt. Auf der Ebene werden die Lieferanten-
Klassifizierungen oder auch die sogenannten Cluster ermittelt.
■ Basislieferant: Hier werden einfache Teile zu weniger guten Preisen bezogen.

Mit diesen Lieferanten gilt es zu verhandeln oder diese vom Panel zu entfernen.
■ Preislich gute Lieferanten: einfache Teile zu guten Preisen

■ Experten: komplexe oder komplizierte Produkte zu entsprechend hohen Prei-
sen
■ Top-Lieferanten: komplexe oder komplizierte Produkte zu guten Preisen

Fazit
 Bevor das Projekt einer strategischen Verlagerung begonnen wird, benötige

ich Aussagen hinsichtlich des Preises, des Risikos und den dafür möglichen
Lieferanten.
 Die Kraljic-Matrix ist ein gutes Hilfsmittel, um eine solche Entscheidung

treffen zu können.
6.5.5 Beschaffungsanalyse
Ein weiteres strategisches Werkzeug im Projektmanagement des Einkäufers ist
die sogenannte Beschaffungsanalyse.
Eine effektive Beschaffung erfordert die tiefgehende Analyse der gesamten Kos-
tenstruktur Ihres Einkaufs. Nur mit einer gut strukturierten Beschaffungsanalyse
können die Potenziale sichtbar gemacht und im Sinne eines optimalen strate-
gischen Einkaufs ausgeschöpft werden – mit dem Ziel einer Kostenoptimierung
im Einkauf. Dies geht weit über den normalen Beschaffungsprozess hinaus und
macht immer wieder die neue Rolle und das Projektmanagement im Einkauf
notwendig.
Abbildung 6.8 Beschaffungsanalyse

Die andere Seite der Medaille 137
7 Risiken der Globalisierung und

durch die Corona-Krise
7.1 Die andere Seite der Medaille

Dieses Kapitel ist der aktuellen Corona-Situation geschuldet. Vor einigen Wochen
hätten wir alle wahrscheinlich nur auf die „guten Seiten“ der Globalisierung
geschaut. Nun aber treffen uns alle auch die Risiken – angefangen beispielsweise
mit Medikamenten, die nicht verfügbar sind. Die Lieferketten brechen in alle
Richtungen ab oder sind zumindest stark heruntergefahren. Ich habe Kunden,
deren Auftragslage sehr gut ist, die aber ihre für die Produktion benötigten Mate-
rialien nur schwer oder gar nicht aus dem internationalen Markt bekommen
können. Andere wiederum haben keine Aufträge mehr, da gerade im Entwick-
lungsbereich oder in der Automobilindustrie China eine große Rolle gespielt hat.
Derzeit kann sicher noch niemand sagen, wie die Welt nach Corona aussehen
wird. Aber eines ist sicher: Die seit 1985 stark intensivierte Verteilung der Infor-
mationen durch E-Mail und das World Wide Web wird einen neue bzw. andere
Bedeutung bekommen. Wir haben uns alle in vielen Teilen dieser Welt abhängig
gemacht von anderen Ländern und Kulturen. Es ist nicht mehr so schnell mög-
lich, die Wirtschaftskette aus dem eigenen Umfeld zu bestücken. Wir fliegen viele
Produkte rund um den Globus, weil es billiger ist, diese dort zu produzieren oder
ergänzen zu lassen. Wir reden über Umweltschutz und das Tierwohl und sub-
ventionieren viele dieser Wirtschaftszweige.
Durch die globale Krise sind viele, sich gegenseitig kannibalisierende Ziele wie-
der ans Tageslicht gekommen. Ob sich nach der Krise etwas ändern wird, werden
wir sehen. So lange wie wir immer weiter, immer größer und immer höher wol-
len, werden wir auch den Preis für dieses Handeln tragen müssen. Auch die
richtige Balance zwischen Wirtschaftlichkeit und Gesundheit bzw. Sicherheit zu
finden, wird eine Verantwortung sein, der wir uns weder im Einkauf noch in
unseren Projekten verschließen können.
7.2 Digitalisierung im eigenen Bereich

Hätte man mich gefragt, ob ich ein Training, wie „Führung und Kommunikation“
online durchführen würde, so hätte ich sicher gesagt, dass ich es eher nicht glau-
https://doi.org/10.1007/978-3-658-31310-4_7
138 Risiken der Globalisierung und durch die Corona-Krise
be. Jetzt habe ich bereits diverse Trainings online durchgeführt und verschiedene
Systeme dafür genutzt. Von Webex, über Vitero, Teams oder auch Yulinc war
alles dabei. Zoom wird von vielen Unternehmen mit dem Argument der Datensi-
cherheit abgelehnt. Zu meinem eigenen Erstaunen habe ich mich dabei sehr wohl
gefühlt. Alle Systeme hatten so ihre kleinen Tücken. Die Digitalisierung hat auch
ihre Herausforderungen. Dennoch konnte ich mit den Teilnehmern durch unter-
schiedliche virtuelle Räume, Kameras, Rollenspiele einen guten Kontakt aufbau-
en. Trotzdem haben wir alle den direkten Kontakt vermisst und den Austausch
auch in den Pausen. Wir lernen alle gerade dazu.
Hier einmal Dinge, die durch Home Office und digitales Arbeiten als Vorteile
bzw. Nachteile benannt wurden:
Vorteile:
■ weniger Reisezeit
■ freie Zeitgestaltung
■ der Tagesablauf ist eigenbestimmt
■ mehr Achtsamkeit für kleine Dinge
■ das direkte Umfeld besser wahrnehmen
■ mehr Zeit mit Partner und Familie
■ neue Herausforderungen annehmen
Nachteile:
■ weniger Austausch mit Kollegen

■ Herausforderung von Kind, Familie und Beruf unter einem Dach
■ IT, die nicht immer so gut funktioniert
■ Kommunikation wird schwieriger
Zusammengefasst heißt das, nicht alles, was gerade passiert, ist schlecht. Wir
lernen alle gerade die Notwendigkeit auch einmal neue Wege zu gehen.
Digitalisierung im eigenen Bereich 139
8 Die Analyse des globalen

Marktes
Auch wenn die Globalisierung gerade kriselt, hat sie ihre Existenzberechtigung.
Daher wollen wir uns auch die unterschiedlichen Seiten dieser Medaille ansehen.
Für eine globale Beschaffung müssen wir nicht nur unsere Kennzahlen kennen,
sondern auch die sich schnell ändernde Situation auf dem Weltmarkt. So spielt
hier nicht nur das Produkt, sondern auch das Umfeld eine Rolle. Politik und
Stakeholder sind nur ein Beispiel (Brexit und die Strafzölle der USA gegen Han-
delspartner) aus der aktuellen Situation.
Ich möchte mich in diesem Buch nicht mit Politik beschäftigen, wichtig ist aber
bei der Globalisierung, die jeweils aktuelle Situation und deren Auswirkungen
auf die Beschaffungsstrategie mit zu betrachten.
Hier möchte ich Methoden zeigen, die aus der Praxis heraus einfach anwendbar
sind und uns damit unterstützen, die aktuellen Informationen zur Situation am
Weltmarkt in Bezug zur jeweiligen Materialgruppe erfassen zu können. Diese
benötigen wir, um damit Prognosen über die Zukunft zu entwickeln – und
Prognosen, die wir mit Zahlen und Daten unterlegen.
Eine Methode dazu ist der gute alte Porter. Porters Five Forces sind auch heute
noch eine gutes Vorgehen, um einen strukturierten Überblick über die aktuelle
Marktsituation zu gewinnen.
Porters five Forces – Die Methode

Während die Methoden aus Kapitel 6 dazu dienen, die internen Zahlen zu erfas-
sen schauen wir uns jetzt das Umfeld an. Michael E. Porter entwickelte die Five-
Forces-Analyse (Branchenstrukturanalyse oder das Fünf-Kräfte-Modell). Als Ein-
käufer unterstützt uns diese Methode, um strategische Aussagen über unsere
Materialgruppe und die entsprechenden Kräfte auf dem globalen Markt besser
einzuschätzen.
Wie der Name bereits sagt, dient die Branchenstrukturanalyse einer detaillierten
Auseinandersetzung mit dem für das Unternehmen relevanten Produkt und dem
Wettbewerb, in dem wir uns befinden. Hierzu gehören Wettbewerber, Kunden,
potentielle Ersatzprodukte, Lieferanten und Wettbewerbsintensität
https://doi.org/10.1007/978-3-658-31310-4_8
140 Die Analyse des globalen Marktes
Porters Annahme geht davon aus, dass die Attraktivität eines Produktes und die
sich darin befindenden Akteure durch die sie umgebende Marktstruktur beein-
flusst werden. Bevor wir uns also auf den globalen Markt ausrichten, haben wir
mit Porter ein strategisches Werkzeug, mit dem wir die branchenspezifischen
Kräfte, die auf unser Produkt wirken, betrachten können.
Sinnvoll ist es, nicht nur den heutigen Zeitpunkt, sondern auch einen Zeitpunkt
in der Zukunft zu wählen, um eine Einschätzung über die strategische Ausrich-
tung von Produkt und Lieferant zu tätigen und so auf Basis der aktuellen Infor-
mationen Entscheidungen zu treffen. Dies geschieht auf Annahmen und den
Informationen, die wir aktuell zur Verfügung haben. Es ist ein strategisches In-
strument. Wie immer nutze ich gern das Wissen des gesamten Projektteams, um
eine bessere Aussage machen zu können. Somit haben wir zumindest das gesam-
te Teamwissen in unsere Betrachtung einbezogen. Alle Methoden sind immer nur
so gut, wie das Wissen, welche eingebrachte werden kann.
Porter hat folgende Kräfte bzw. Einflussgrößen des Marktes betrachtet:
■ Verhandlungsmacht des Lieferanten

Diese ist immer dann hoch, wenn wir nicht viele Entscheidungsmöglichkeiten
haben. Als Beispiel dient Single Source oder aktuell die Baubranche, da es fast
keine Baufirmen am Markt mit freien Ressourcen gibt. Daher verschiebt sich das
Machtpotential in Richtung Lieferant. Ein weiteres Beispiel kann eine lange Frei-
gabe von Verfahren sein, bevor der Lieferant zugelassen wird (z. B. Luftfahrt).
Müssen sich andere Lieferanten hohen Auflagen unterwerfen, so steigert dies die
Macht der aktuellen Lieferanten.
■ Verhandlungsmacht des Kunden (Abnehmer)

Sehen wir uns an dieser Stelle als Kunde, so ist unsere Verhandlungsmacht dann
groß, wenn es mehrere Optionen am Markt gibt und sich ein Wechsel des Liefe-
ranten als einfach gestaltet. Wenn wir ein hohes Einkaufsvolumen beim Lieferan-
ten haben, geht das Machtverhältnis auch zu unseren Gunsten. Daher ist die
Globalisierung an dieser Stelle auch ein Thema. Auch wenn sich eine Verlage-
rung ins Ausland als schwerer erweist, kann schon die Option eine Veränderung
der Machtverhältnisse bedeuten. Wichtig hierbei ist es, die eigene Position gut zu
kennen, um entsprechende Handlungsoptionen generieren zu können
■ Bedrohung durch neue Wettbewerber

Wenn neue Wettbewerber auf dem Markt erscheinen, führt das in der Regel da-
zu, dass sich der Preisdruck erhöht. Wie und in welcher Form die Produkte auf
den Markt kommen, hängt von einigen Eintrittsbarrieren ab. Ein Beispiel ist die
Pharmaindustrie, die zwanzig Jahre lang einen Patentschutz auf ihre Produkte
hat (und einem in der EU möglichen Zuschlag von fünf Jahren). Läuft dieser aus,
so ändert sich sofort die Marktsituation durch das Eintreten von Generika.
■ Bedrohung durch Ersatzprodukte

Unter Ersatzprodukten versteht man Produkte, die ähnliche Kundenbedürfnisse
erfüllen wie das Original. Da hier die Gefahr besteht, dass Kunden zum anderen
Produkt wechseln, verschiebt sich der Markt. Als Substitut können wir aber auch
das „neue Wege gehen“ verstehen. Das Thema Digitalisierung verschiebt den
Markt massiv. Ein einfaches Beispiel wären Briefumschläge – das Substitut
E-Mail reduzierte den Bedarf an Briefumschlägen um ein Vielfaches.
■ Wettbewerbsintensität in der Branche

Ein Beispiel aus der aktuellen Marktsituation ist die Baubranche. Bedingt durch
den Bauboom, ist eine der großen Hürden überhaupt eine Baufirma zu finden.
Immer wieder wird mir von Kunden gespiegelt, dass es kaum eine Möglichkeit
der Verhandlung gibt, sondern dass die Kunden überhaupt froh sind, einen An-
bieter zu finden. Vor ein paar Jahren war die Marktsituation eine völlig andere.
Fazit
 Nachdem wir unsere Kennzahlen der Materialgruppe kennen, kommt die

Analyse der Marktsituation. Eine Methode hierzu ist Porters Five Forces.
 Da eine angewandte Methode nur so gut ist, wie das Wissen, welches wir
gemeinsam in die Methode packen, ist es notwendig, die Wissensträger für
unser Produkt zusammenzubringen, um gemeinschaftlich ein gutes Ergeb-
nis zu erzeugen.
Neben den von Porter benannten Einflussgrößen sollten zusätzlich folgende Fak-
toren mit in Betracht gezogen werden:
Politik: Die Ausrichtung und auch die Stabilität des politischen Systems in dem
von uns ausgewählten Land sollten mit Bedacht betrachtet werden. Politische
Entscheidungen können sich merklich auf unsere Produkte, Projekte und damit
auch auf unser Unternehmen auswirken. Sehr oft sind die politischen Richtungen
nur bedingt vorhersehbar und vor allem nicht beeinflussbar. Sie sind daher im-
mer ein Risiko. Ändert sich politisch etwas, so ändern sich auch die anfallenden
Kosten einer zu beschaffenden Ware. Im Rahmen unserer Möglichkeiten ist dies
vorab als Risiko oder Chance einzuschätzen. Ein entsprechendes Risikomanage-
ment kann hier unterstützen.
142 Die Analyse des globalen Marktes
Juristisches Umfeld: Nicht immer ist es einfach, wenn die Rechtslage des jeweili-
gen Landes für uns Gültigkeit hat. Rechtssystem, Wertesystem und auch Ent-
scheidungsfindung kann erheblich von unserem System abweichen. Die Konse-
quenzen aus einer Abweichung sollten, wenn möglich, von uns bei Projektstart
mit betrachtet und bewertet werden.
Kultur und Religion: Bei Kultur und Religion fängt es schon mit ganz einfachen
Themen an. Wer hat welche Feiertage und welche Prioritäten und steht an diesen
Tagen dem Projekt und/oder als Lieferant nicht zur Verfügung. Natürlich hat die
Religion auch einen Einfluss auf Werte und damit Denk- und Handlungsweisen
beteiligter Stakeholder, Entscheidungsgremien und Teams.
Abbildung 8.1 Relevante Einflüsse, die die Machtverhältnisse des Projekt-

oder Produktsystems beeinflussen
9 Kulturelle Herausforderungen
im globalen Umfeld
Während wir bereits im Kapitel „Why culture counts“ auf die Herausforderun-
gen im internationalen Umfeld eingegangen sind, möchte ich dieses Kapitel the-
menbezogen noch einmal aufgreifen. Die kulturellen Herausforderungen zeigen
sich an unterschiedlichen Stellen in unseren Projekten. Going global macht es
nicht einfacher. Wobei die kulturellen Herausforderungen nicht allein durch
Going Global, sondern auch zwischen Ländern, Städten und/ oder auch Regionen
auftreten können. Jedes Unternehmen hat seine eigene Kultur. Seine Werte und
Normen, die in einer bestimmten Gesellschaft als akzeptiert und richtig gelten.
Um kulturellen Missverständnissen vorweg zu greifen, gilt es selbige zu erken-
nen und zu akzeptieren. Oft macht man sich die eigenen speziellen kulturellen
Ausprägungen gar nicht bewusst. Sie sind ja auch für uns die Normalität.
Kultur ist das Regelwerk, welches für uns als gut und richtig akzeptiert wurde. In
einer anderen Kultur gilt ein anderes Regelwerk.
Erleben wir ein anderes Verhalten, als das von uns erwartete, so ist es immer
wichtig zu überlegen, ob dies ein Verstoß gegen Regeln ist oder vielleicht nur ein
Verstoß gegen unsere Regeln. Bevor wir uns in einem neuen Kulturkreis bewe-
gen, ist es hilfreich, sich der eigenen Regeln (Kultur) sowie der neuen Kultur
bewusst zu werden. Spannend ist es immer dort, wo große Abweichungen im
Verständnis auftreten. Als Beispiel sei hier genannt, dass das Lächeln in Thailand
nicht immer ein Lächeln der Freundlichkeit ist, so wie wir es in Deutschland
verstehen. Es kann viele Bedeutungen eines Gefühls zeigen.
Woher aber rührt das Thema Kultur und was hat einen Einfluss auf die Werte
einer Gesellschaft? Die Gründe sind vielschichtig. Geprägt werden wir und unse-
re Gesellschaft unter anderem durch folgende Punkte:
■ Geschichte und Vergangenheit

■ Einstellung zu Menschen
■ Religion
■ Organisation
■ Führungs- und Hierarchie-Verständnis
■ Wertehaltung
https://doi.org/10.1007/978-3-658-31310-4_9
144 Kulturelle Herausforderungen im globalen Umfeld
■ Vorurteile
■ Rollenbilder und Erwartungen an die Rollen
■ Zeitfaktor
■ Abstandsfaktor
■ Tabus
■ Sprache
Landeskultur ist nicht zu verwechseln mit der spezifischen Unternehmenskultur.
Ein junges Start-up-Unternehmen in Asien kann durchaus westlicher geprägt
sein, als ein konservatives asiatisches Unternehmen. Auch hier bewegt sich die
Welt. Die jüngere Generation hat meist einige Zeit im Ausland verbracht. Sei es
durch ein Studium oder durch den Austausch während der Schulzeit. So ver-
mischen sich die Wertekulturen oder passen sich an.
9.1 Was betrachten wir als Kultur?

Der Begriff Kultur stammt von dem lateinischen Wort „colere“ und bedeutet so
viel wie „bebauen, bestellen, pflegen“ – die Art und Weise, wie wir unser Leben
gestalten. Geert Hofstede, einer der bekannteren Forscher im Rahmen von Kul-
tur, sagt, es ist die kollektive Programmierung des Geistes.
Oft wird Kultur mit dem Eisberg-Modell verglichen. Das, was wir oberhalb der
Wasseroberfläche wahrnehmen, ist vielfältig. In Bezug zu Kultur ist es Verhalten,
Tradition, Sprache, Religion, Essen, Kunst, Symbole, Architektur usw. Kultur gibt
Sicherheit, da sie Regeln und Rituale vorgibt, an die wir uns anlehnen können.
Ge- und erlebte Zugehörigkeit zu einer Kultur gibt Orientierung in einem kom-
plexen Gefüge und macht dadurch erst handlungsfähig. Wir bekommen durch
die Zugehörigkeit eine kulturelle Identität. Die für uns daraus resultierenden
Standards geben Sicherheit und Orientierung.
Was wir aber nicht sofort sehen können, sind die Werte und die Weltanschauung
sowie die Grundhaltung der Menschen. Diese befinden sich unterhalb der Eis-
oberfläche des Eisbergs.
Treffen sich also zwei Menschen oder zwei Menschengruppen aus unterschied-
lichen Kulturen, so treffen sich auch zwei Eisberge. Automatisch entsteht die
Frage:
Was betrachten wir als Kultur? 145
Warum machen die alles ganz anders als wir?
Es treffen unterschiedliche Kulturkreise aufeinander und damit auch eine unter-

schiedliche Wahrnehmung zu Werten, zum Denken, zum Handeln und zur Kom-
munikation.
Abbildung 9.1 Wahrnehmung des Verhaltens zweier unterschiedlicher Kul-

turkreise oder: Warum machen die alles ganz anders?
Kulturkreis A Kulturkreis B
Verhalten Verhalten
WERTE WERTE
Bei diesem Treffen neigen wir dazu, das Verhalten des Anderen auf Basis der
eigenen Werte und Einstellungen zu interpretieren. Wir nennen dies auch Kul-
turstandards. So hat jedes Land oder jede Kultur sein eigenes kulturspezifisches
Orientierungssystem. Bei der Begegnung mit der fremden Kultur werden zu-
nächst die bisherigen Erfahrungen, Werte und Beurteilungsmaßstäbe herangezo-
gen, die uns vertraut sind und die uns bisher in unserer Kultur als Orientierungs-
system gedient haben. Um Kultur zu „lernen“ gilt es, die Unterschiede zu erken-
nen. Dies ist der erste Schritt für eine zwischenmenschliche Kommunikation
verschiedener Kulturen.
Anhand des Eisbergmodells können wir Ableitungen zum Thema Kultur herstel-
len. Unsere Werte, Einstellungen, Weltanschauungen beeinflussen unser Verhal-
ten auf unbewusste Art und Weise. Wir sehen unser Umfeld auch nur durch die
Brille unserer Prägungen. Auf Basis unserer kulturellen Prägung entwickeln wir
gern sogenannte Vorurteile oder auch Stereotypen. Anbei ein paar Beispiele, die
für bestimmte Länder gern genannt werden.
9.1.1 Die Brille, mit der wir Kultur betrachten

Die Brille der eigenen Erfahrung oder Kultur. Bevor wir uns nicht auf andere
Kulturen einlassen, haben wir auch keine Chance, anders zu sehen, als durchdie-
se Brille.
Wenn wir die hier beschriebenen Stereotype verlassen wollen, dann hilft nur
kulturelle Kompetenz. Wissen, welches uns hilft unsere eigene und die Kultur
der anderen besser zu verstehen.
Abbildung 9.2 Skizze: stereotype kulturelle Einschätzungen
Deutsche
Italiener sind
tragen
touchy
Lederhosen
Amerikaner
Chinesen essen Briten sind
sind
Hunde höflich
oberflächlich
Holländer Stereotype Einschätzungen und Spanier sind

fahren Fahrrad Vorurteile anderer Kulturen laut
Stereotype sind Verallgemeinerungen, die zutreffen können, aber nicht müssen.

Sie beziehen sich eher auf „sagen und hören“ als auf eigenes Erleben. Daher sind
sie auch mit Vorsicht zu genießen. Bekannterweise essen wir Deutschen nicht nur
Knödel und laufen das ganze Jahr in Lederhosen herum. Je mehr wir andere
Kulturen kennen gelernt haben, umso mehr Verständnis oder Verstehen können
wir aufbauen. Was wir nicht kennen, macht uns Angst und Angst führt zu Ab-
lehnung.
Was betrachten wir als Kultur? 147
Für uns ist es erst einmal hilfreich, unsere eigene kulturelle Prägung zu verste-
hen. Jedes eigene Verhalten kann genauso von einer anderen Kultur interpretiert
werden, wie wir es tun. Daher gehört zum Lernen interkultureller Kompetenz in
erster Linie das Bewusstsein über die eigene Kultur und das Beobachten des
Verhaltens anderer Kulturen, ohne sofort eine Wertung stattfinden zu lassen. Um
dieses „Bewertungssystem“ zu verlassen, sollten wir erst unser eigenes Orientie-
rungssystem verstehen und dann das der fremden Kultur. Verstehen wir uns, so
ist es auch möglich, die Brücke der Kommunikation von einem Kulturkreis zum
anderen zu schlagen. Aus dem Verstehen resultieren unsere Handlungskompe-
tenzen. Was aber ist unter Handlungskompetenz zu verstehen?
9.1.2 Was sind Handlungskompetenzen?

Als Handlungskompetenz wird die Bereitschaft und Befähigung des Einzelnen
verstanden, sich in beruflichen, gesellschaftlichen und privaten Situationen sach-
gerecht durchdacht sowie individuell und sozial verantwortlich zu verhalten.“
(Kultusministerkonferenz, 23. September 2011)
Zu unseren Handlungskompetenzen zählen wir drei Bereiche:
1. Soziale Kompetenz
Teamfähigkeit, menschliche Fähigkeiten, Kommunikation, Empathie, ...
2. Persönliche Kompetenz
Einstellung zum Leben, Rolle, Aufnahmebereitschaft, Führungsverständ-
nis, …
3. Fachkompetenz
Fachkenntnisse über ein spezielles Feld, Wissen, Erfahrung im beruflichen
Fachgebiet
Für die interkulturelle Kompetenz braucht es die Fähigkeit, das Verhalten der
anderen Kultur zu beobachten, zu erkennen und selber Handlungsoptionen dar-
aus abzuleiten. Entscheidend ist es an den Stellen, wo wir einen Unterschied in
Handlungsfeldern wahrnehmen.
Für uns steht immer die Frage im Vordergrund, was der kulturelle Unterschied
für unser Projekt bedeutet und wie wir im Team damit umgehen. Oder, auf wel-
chen gemeinsamen Nenner wir uns einigen können. Auch eine Betrachtung der
Risiken zu kulturellen Unterschieden kann helfen. Was oft so lapidar klingt, kann
das Projekt massiv beeinflussen.
In unseren Projekten benötigen wir für einen erfolgreichen Abschluss ein gut
funktionierendes Team mit gleichen Zielen. Dies kann aber im interkulturellen
Umfeld nur dann klappen, wenn wir die speziellen Orientierungssysteme unse-
rer Mitspieler verstehen und entsprechende Handlungen darauf ausrichten. Na-
türlich ist das keine Einbahnstraße, sondern bedingt das gegenseitige Verstehen
der Teammitglieder. Respekt, Wertschätzung und Empathie auf allen Seiten ist
die Basis für eine erfolgreiche Umsetzung der Herausforderungen eines Projek-
tes.
Um uns auf das Projektziel konzentrieren zu können, hilft es, sich auf ein Team-
wertesystem mit eigenen Regeln zu einigen. Dies setzt die kulturellen Regeln
nicht außer Kraft. Ein „kulturelles Regelwerk“ für das Projektteam hilft aber der
Orientierung aller Beteiligten.
Kulturellen Missverständnissen und Konflikten, basierend kulturellen Unter-

schieden, gilt es frühzeitig entgegenzuwirken. Ist das gegenseitige Vertrauen
durch „Nicht-Verstehen“ erst einmal beschädigt, so kann dies sehr schnell das
ganze Projekt gefährden.
Handlungsempfehlungen für das Planen internationaler Projekte im globalen

Umfeld:
Checkliste und Handlungsempfehlungen für das Planen internationaler Pro-

jekte im globalen Umfeld:
1. Schaffung gemeinsamer Standards (gemeinsames Regelwerk)
2. Vereinbarung gemeinsamer Werte und Rituale
3. Festlegung von Erfolgsfaktoren (Wann ist das Projekt gelungen?)
4. Gemeinsames Zielverständnis schaffen
5. Einschätzen der politischen Sensibilität des Projektes
6. Gemeinsam die Spielregeln für das Projekt festlegen
7. Gutes Stakeholder Management
8. Frühzeitiges Festlegen eines Eskalationsprozesses
9. Gutes Wissen über das Projektumfeld (Projektumfeldanalyse)
10. Gute Beziehungen zu den entsprechenden Informationsquellen kann im Aus-

land wichtiger sein als im Inland
Methoden zur Analyse des Projektumfeldes 149
11. Das Risikomanagement bekommt noch einmal eine weitere Dimension. Auch
hier ist der Prozess frühzeitig festzulegen und die kulturelle Herausforderung
eventuell schon bei der Benennung von Risiken einzukalkulieren.
12. Wissen darüber, wie Entscheidungen getroffen werden.
13. Gemeinsames Verständnis über „Commitments“ erzeugen. (Was heißt es,

wenn ich eine Zusage für einen Termin gemacht habe? Wie genau ist die Zu-
sagentreue? Gern gibt es hier kulturell ein unterschiedliches Verständnis über
das Wort „Ja“.)
14. Zeitaufwand durch die Sprache bedenken. (Wie viel mehr Aufwand benötige
ich für Telcos, Meetings etc., wenn ich nicht nur Muttersprachler im Projekt
habe?)
9.2 Methoden zur Analyse des

Projektumfeldes
Natürlich werden diese Methoden auch in nationalen Projekten eingesetzt. Im
globalen Kontext sind sie für den Projekterfolg unerlässlich. In welcher Tiefe die
Methoden notwendig sind, sollte der Projektleiter selbst entscheiden. Auch die
daraus resultierenden Handlungsempfehlungen sind ein weiterer Schritt.
9.2.1 Die Projektumfeldanalyse

Anders als die Stakeholderanalyse bezieht sich die Projektumfeldanalyse nicht
nur auf die Personen oder Personengruppen, die einen Einfluss auf das Projekt
haben können, sondern auf die Erfassung aller Randbedingungen und Einfluss-
faktoren für das Projekt. Die Projektumfeldanalyse ist ein Werkzeug zu Anfang
des Projektes. In der Definitionsphase findet auch die Umfeldanalyse statt. Je
nachdem, wie die Rahmenbedingungen sind, kann dies das notwendige Projekt-
budget nochmals beeinflussen. Die Ergebnisse der Analyse sollten in die Projekt-
planung mit einfließen.
Abbildung 9.3 Skizze: Prozess der Umfeldanalyse
Identifikation der Einflussfaktoren – Ist-Zustand
Analyse/Bewertung/Priorisierung
Auswertung von Maßnahmen und Handlungsempfehlungen
Umsetzung der Maßnahmen in die Planung des Projektes
Kontinuierliche Beobachtung des Umfeldes und

der identifizierten Maßnahmen
Fazit
 Ziel ist die frühzeitige Erkennung und damit Einflussnahme bei Verände-
rung der das Projekt beeinflussenden Indikatoren.
9.2.2 Stakeholderanalyse
Wie bereits erwähnt, bezieht sich die sich die Stakeholderanalyse auf Personen
oder Personengruppen, die einen Einfluss auf das Projekt haben können. Hier
geht es auch darum, die Bedürfnisse der jeweiligen Personen zu erkennen sowie
auch ihre Position und Treiber dem Projekt gegenüber. Stakeholder können einen
positiven oder negativen Einfluss auf den Projekterfolg haben. Sie müssen nicht
zwingend am Projekt beteiligt sein (z. B. die Politik des jeweiligen Landes).
Stakeholderanalysen sind gerade bei globalen Projekten von Bedeutung. Bedingt

durch die Werte des jeweiligen Landes, können die das Projekt beeinflussenden
Personen oder Personengruppen weitaus komplexer sein, als in der uns bekann-
ten Kultur (z. B. die graue Eminenz im Unternehmen, der Dorfälteste oder gerade
in Kulturen mit sehr hoher Machtdistanz die Einflussfaktoren durch die Hierar-
chie). Daher ist es für uns extrem wichtig zu wissen, wer das Projekt - unabhän-
gig von der hierarchischen Position - noch beeinflussen kann. Dies geht weit über
die juristischen Einflüsse hinaus.
Methoden zur Analyse des Projektumfeldes 151
Wir wollen Blockierer, Blender und schwierige Personen erkennen, genauso wie
Befürworter und Unterstützer – mit dem Ziel, Störer und Hinderer mit entspre-
chenden Maßnahmen entgegenwirken zu können und die Unterstützer und Hel-
fer entsprechend zu integrieren.
Wie ist das Vorgehen?
1. Identifikation der potentiellen Einflussnehmer auf das Projekt. Gern im Team.

Eine erste Unterscheidung kann zwischen den am Projekt beteiligten und
nicht beteiligten Personen liegen.
2. Eine weitere erste Unterscheidung in interne und externe.
3. In einem nächsten Schritt werden die identifizierten Stakeholder konkreter

analysiert und entsprechend projektspezifischer Einflussgrößen (inhaltlich,
organisatorisch, sozial) bewertet und gewichtet.
4. Einordnen in der Matrix
5. Entsprechende Maßnahmen erarbeiten
Abbildung 9.4 Skizze: Ableitung von Persönlichkeitsstrukturen aus der Sta-

keholderanalyse (Wie stehen die jeweiligen Stakeholder dem
Projekt gegenüber und wie ist ihr Einfluss?)
positiv
Helfer Unterstützer
Störer Hinderer
negativ
Macht/Einfluss
Fazit
 Für komplexe Projekte ist eine Stakeholderanalyse immer von Bedeutung,

um auch hier potentiellen Störgrößen möglichst frühzeitig entgegenwirken
zu können.
 Im globalen Umfeld werden die Risiken und Herausforderungen durch

unterschiedliche Wertesysteme und Regelwerke, die als richtig oder falsch
angesehen werden, nochmals größer.
 Stakeholder Management ist ein gutes Werkzeug zur Reduzierung von

Störgrößen.
9.3 Unterschiedliche Modelle kultureller

Zusammenhänge
Ein Kulturmodell ist der Versuch, unsere kulturelle Prägung zu beschreiben. Es
ist der Ansatz zur Beschreibung von kulturell verankerten Denkmustern und
untersucht den Umgang mit gesellschaftlichen Erscheinungen und Problemen,
der im Kollektiv einer Kultur allgemein verbreitet und anerkannt ist, beispiels-
weise das Verhältnis zwischen Einzelperson und Gesellschaft.
Abbildung 9.5 Kulturebenen nach Edgar Schein (Quelle: Schein, Internatio-

nales Projektmanagement, Beck, S. 22)
Sichtbar, aber
Verhaltensweisen und Ergebnisse interpretations-
Sprache, Rituale, Kleidung, Umgangsformen etc..
bedürftig
Werte und Normen Teil sichtbar

Maxime, Ideologien, Verhaltensrichtlinien, Verbote Teils bewusst
Basisannahmen Unsichtbar, meist

über Umweltbezug, Welt, Wesen des Menschen,
unbewusst
Wesen menschlicher Handlungen und Beziehungen
Unterschiedliche Modelle kultureller Zusammenhänge 153
Kultur beeinflusst unsere Wahrnehmung, unser Denken und unser Verhalten.

Dabei stellt sich zunächst die Frage, wie dieses Phänomen „Kultur“ zu konkreti-
sieren ist. Im deutschsprachigen Raum wird der Begriff „Kultur“ dabei für unter-
schiedliche Zusammenhänge genutzt (Schmidtke 2015).
Zunächst wird er im alltäglichen und nicht-wissenschaftlichen Kontext verwen-

det, um Menschen gemeinsamer Abstammung aufgrund statisch wahrgenomme-
ner Merkmale zu charakterisieren oder er dient im Plural zur Bezeichnung von Ge-
meinschaften mit gemeinsamen Merkmalen, wie Sitten oder Sprache (Ethnien).
Es gibt einige Forscher, die sich mit diesem Thema intensiv auseinandergesetzt
haben. Die Ansätze waren unterschiedlich. Das Ziel ist aber immer, ein Cluster
für die Unterschiedlichkeit von Menschen konkret beschreiben zu können.
Die erste Ebene der Kleidung und Umgangsformen ist sehr oft die am einfachsten
zu beobachtende und damit auch die, die am wenigsten Probleme gestaltet. So-
bald wir aber tiefer gehen und Normen und Werte anfassen, wird es komplizier-
ter. Diese Ebene mit der Basis von Annahmen gemeinsam bildet das Geflecht von
Regeln, welches wir unbewusst als das Richtige annehmen.
Die bekanntesten Kulturforscher sind neben Geert Hofsteede noch Edward T. Hall
und Fons Trompenaars. Genauer möchte ich an dieser Stelle nur auf die Kultur-
dimensionen von Geert Hofsteede und den Kontext zum Projektmanagement im
Einkauf eingehen.
9.3.1 Das Modell von Geert Hofstede

An dieser Stelle möchte ich auf Hofstede eingehen und seine kulturellen Dimen-
sionen einbringen und wie diese unser Projekt beeinflussen können. Unser Ziel
ist es, kulturelle Missverständnisse zu vermeiden, indem wir als erstes einmal
verstehen, wo diese liegen können. Die kulturellen Ausprägungen unterscheiden
sich durch das jeweilige Land, in dem wir unser Projekt aufsetzen. Was aber gibt
es zu verstehen? Die soziale Kompetenz, die in dieser Kultur Gültigkeit hat. Kon-
kret können wir lernen, was Gastfreundschaft bedeutet, wie man sich während
eines Meetings verhält, wo und wann Verhandlungen geführt werden, wie man
sich begrüß und welche Spielregeln in diesem Land oder in dieser Kultur Gültig-
keit haben.
Wichtig an dieser Stelle ist erst einmal, unsere eigene Kultur gut zu verstehen.
Wie bereits dargestellt, müssen uns erst einmal selbst beobachten. Viele unserer
Handlungen geschehen nicht auf der bewussten Ebene. Wir sind damit aufge-
wachsen und sie spiegeln unsere Wahrheit wider, die in unserem Lebensraum als
richtig oder falsch gilt. Sehr oft werden wir als Deutsche mit unserer direkten Art
als unhöflich wahrgenommen. Bewusst ist uns dies erst einmal nicht. Der harte
Klang unserer deutschen Sprache tut sein Übriges.
Hofstede hat seine Erkenntnisse aus dem Ergebnis einer umfangreichen Studie
aus den siebziger Jahren bei IBM abgeleitet. An der Studie waren mehr als
100.000 Mitarbeitern weltweit beteiligt. Anhand der fünf Dimensionen von Hof-
stede können wir auch heute in der verstärkt globalen Welt noch Handlungsopti-
onen für unsere Projekte ableiten.
Für Hofstede ist Kultur: „Die kollektive Programmierung des Geistes, die die
Mitglieder eines Landes oder einer Kultur von Menschen von anderen unter-
scheidet.“(Dätsch 2018)
In seiner Studie hat Hofstede folgende Dimensionen zur Eingliederung von

Kulturen herausgefiltert, in denen er die unterschiedlichen Verhaltensmuster
und Regeln unterscheidet:
1. Die Machtdistanz
Die Machtdistanz stellt die emotionale Distanz zwischen Vorgesetztem und Mit-
arbeiter dar. Das heißt, hierarchisch hat der Chef Recht. Während in Deutschland
und/oder auch in den nordischen Ländern die Machtdistanz eher geringer ist, hat
in lateinamerikanischen, afrikanischen oder auch in asiatischen Ländern der Chef
die Rechte, bedingt durch seine Position im Unternehmen. Dies bedeutet aber
auch, dass das agile Arbeiten in solchen Ländern eine größere Herausforderung
darstellt, weil damit die Hierarchien mehr oder weniger aufgeweicht werden. Für
uns bedeutet dies auch in klassischen Projekten ein verstärktes Achten auf Stake-
holder. Die Teammitglieder benötigen in solchen Ländern eine bestimmte Füh-
rungsrolle, da wir ansonsten keine Entscheider in unseren Projekten haben und
damit auch schnell Auswirkungen auf Termine und Meilensteine.
2. Individualismus versus Kollektivismus
In individualistischen Kulturen (englischsprachigen Ländern, Skandinavien,

deutschsprachiger Raum) sind die Handlungsmotive der beteiligten Personen
geprägt durch den Einzelnen. Er bringt sich als Person in seinem Beruf ein. In
eher kollektivistisch geprägten Kulturen (lateinamerikanischen, arabischen oder
afrikanischen Ländern) ist die Zugehörigkeit zu einer Gruppe wichtiger. Dies
kann der Clan, die Familie oder auch die Firma sein. Je nach Kultur kann es hier
auch noch Unterschiede des Zugehörigkeitsgefühls geben, das heißt Familie
(arabische Länder) oder Firma (japanische Länder). In den Projekten spielt daher
die Betrachtung des Umfeldes und der Stakeholder wieder eine große Rolle. Alle
Unterschiedliche Modelle kultureller Zusammenhänge 155
diese sogenannten weichen Themen werden bei Nichtbeachtung sehr schnell

harte Fakten. Für uns stellt sich in den Projekten die Frage, wer die Entscheider
sind. Wer beeinflusst noch das Projekt, anders als in unserer eigenen Kultur? Wie
kann die Integration des notwendigen Wissens in die Projekte geschehen? Habe
ich in Afrika nicht die Rückendeckung des Dorfältesten, dann wird mein Projekt
vermutlich gar nicht erst an den Start gehen.
3. Maskulinität versus Femininität

Hofstede unterscheidet hier zwei gegensätzliche sogenannte geschlechterspezifi-
sche Eigenschaften von Kulturen. Hohe Maskulinität in einer Kultur bedeutet
einen Fokus auf stereotype maskuline Werte, wie materiellen Erfolg, Aggressivi-
tät, Ehrgeiz und Konkurrenz. In maskulinen Kulturen gibt es zudem große Un-
terschiede in den klassischen Geschlechterrollen. Bei geringerer Maskulinität – in
femininen Kulturen – sind die Geschlechterrollen dagegen fließender und weni-
ger festgelegt. Dort zeigen Frauen und Männer mehr Bescheidenheit, Fürsorg-
lichkeit und Fokus auf Beziehungen. Diese Dimension wird auch als Quantität vs.
Qualität bezeichnet, wobei Quantität für maskulines Verhalten steht und Qualität
für feminines Verhalten. Die höchste Maskulinität herrscht in Japan, Österreich,
der Schweiz, Italien und Venezuela. Deutschland kommt dicht dahinter und ist
noch in der Top 10 der maskulinsten Länder. Die geringste Maskulinität herrscht
in den nordeuropäischen Ländern Schweden, Dänemark und Norwegen, sowie
in den Niederlanden. Dort sind die Geschlechterrollen weit weniger streng fest-
gelegt und stattdessen offener und fließender.
4. Unsicherheitsvermeidung
Dies ist der Grad, wie sich Menschen einer Kultur durch neue Herausforderun-
gen verunsichern lassen, d. h. der Grad, an dem gemessen wird, wie schnell sich
eine Kultur durch neue oder ungewohnte Situationen beeinflussen lässt. In Län-
dern mit einem hohen Grad an Unsicherheitsvermeidung besteht die Tendenz,
Abweichungen zu sanktionieren bzw. alles per Gesetz zu regeln. In Ländern oder
Kulturen, in denen sich das Unsicherheitsniveau eher niedrig bewegt, ist die
Haltung, dass Veränderungen ein Bestandteil des Lebens sind und nicht für alles
eine Regel erstellt werden muss. Was sind klassische Herausforderungen, die
unseren Arbeitsalltag im globalen Umfeld massiv beeinflussen können und die
wir uns erst einmal bewusst machen müssen?
5. Lang- oder Kurzfristausrichtung

Dieser Index wurde von Hofstede erst später eingeführt. Er beschreibt den Zeit-
horizont einer Gesellschaft. Kurzfristig ausgelegte Kulturen legen Wert auf tradi-
tionelle Methoden. In langzeit-orientierten Kulturen, wie z. B. China, liegt der
Fokus auf dem Aufbau von persönlichen Beziehungen bzw. Beziehungsnetzwer-

ken, die eher langfristigen Charakter haben. Im Gegensatz dazu legt man in
kurzzeit-orientierten Kulturen Wert auf Gewinn in kürzerer Zeit.
6. Genuss und Zurückhaltung – eine neue Dimension, die im Jahr 2020 hin-
zukam
Diese Dimension ist relativ neu und bezieht sich auf die Umsetzung der eigenen
Bedürfnisse. Sie bezieht sich darauf, wie offen mit der Auslebung der eigenen
Bedürfnisse umgegangen wird. Dazu zählen auch Fragen zu genussorientierter
Freizeitgestaltung, wie offen mit Sexualität umgegangen wird, oder wie pessimis-
tisch oder optimistisch der Blick auf die Zukunft ist.
Fazit
 Jede dieser sechs Dimensionen kann dabei helfen, ein Projekt mit Beteiligten
aus unterschiedlichen Kulturen besser zu verstehen und damit auch Maß-
nahmen zu ergreifen, die eine möglichst konfliktarme Abwicklung zulassen
und die Zielerreichung verbessern.
 Umgekehrt können alle diese Komponenten zu großen Herausforderungen

in Projekten werden, wenn wir ihnen keine Beachtung schenken.
9.4 Konkrete Einflussgrößen auf unsere

Arbeitswelt durch kulturelle
Unterschiede
Die Beispiele aus Abbildung 9.6 sind nur einige aus meiner Praxis, die immer
einen Einfluss auf den Prozess und Ablauf der Projekte hatten. Ich habe während
meiner Vorlesungen einmal gefragt, wo die Studenten tatsächlich schwerwiegen-
de kulturelle Missverständnisse erlebt haben. Eine junge chinesische Studentin
erzählte daraufhin folgendes Beispiel: Ein chinesisches Unternehmen mit ameri-
kanischem Investor hatte Gelder beantragt, da es ihnen finanziell nicht gut ging.
Die Investoren flogen nach China und wurden dort aufs Beste bewirtet. Die
chinesische Kultur kümmerte sich um ihre Gäste. Woraufhin die Amerikaner die
Gelder nicht zur Verfügung stellten, mit den Worten, wenn das Unternehmen
sich noch so teures Essen leisten kann, kann es ihm noch nicht so schlecht gehen.
Ein kulturelles Missverständnis mit fatalen Folgen.
Führung und Konfliktmanagement in internationalen Projekten 157
Abbildung 9.6 Wo können wir diese kulturellen Missverständnisse sehen oder

erleben?
9.5 Führung und Konfliktmanagement in

internationalen Projekten
Interkulturelle und internationale Projekte im globalen Umfeld sind sehr konflikt-
gefährdet. Umso wichtiger ist es, die Rollen vorab klar zu definieren und im
Rahmen der Steuerungsmaßnahmen einen guten Eskalationsprozess festgelegt zu
haben, bevor das Kind in den Brunnen gefallen ist. Es ist hilfreich, den Eskalati-
onsprozess vor Beginn oder mit Start des Projektes festzulegen und auch zu
kommunizieren.
Was genau heißt Eskalation oder Eskalationsmanagement? Wenn der Konflikt

z. B. nicht mehr auf der Ebene des Projektteams geklärt werden kann, so wird er
in eine höhere Hierarchieebene oder an ein entsprechendes Gremium abgegeben,
entsprechend der vorab festgelegten Stufen.
Im globalen Umfeld ist auch zu klären, was genau eskaliert werden soll, d. h.
wann und an wen. Auch die Werte der Eskalation können kulturell unterschied-
lich sein. In arabischen Ländern ist auch das Thema Respekt ein Grund zur Eska-
lation. Prinzipiell hat in Projekten immer noch das magische Dreieck und die
daraus resultierende Planung Verbindlichkeit. In unserem Kulturkreis werden
Termine, Kosten und nicht eingehaltene Leitungen eskaliert. Wird von dieser
Verbindlichkeit hinsichtlich Kosten, Terminen und/oder vereinbartem Leistungs-
umfang abgewichen, so tritt ein Eskalationsprozess in Kraft, wenn der Projektlei-
ter dies nicht mit seinem Team lösen kann.
Ein erfolgreicher Eskalationsprozess setzt eine gute Stakeholderanalyse (siehe

Kapitel Werkzeuge) voraus. Diese soll mich als Projektleiter darin unterstützen,
die entsprechenden Machtverhältnisse frühzeitig zu kennen und entsprechend
einsetzen zu können. Kulturell bedingt können das Machtverhältnis und damit
auch die Entscheidungswege unterschiedlich gestaltet sein.
Auch das Thema Risikomanagement nimmt noch einmal eine neue Rolle ein.
Bedingt durch den kulturellen Hintergrund ist nicht jedes Teammitglied in der
Lage, Risiken auch offen zu benennen oder anzusprechen. Zusätzlich zu den
klassischen Clustern im Risikomanagement (Technik, Umwelt, Politik, Kommu-
nikation) kommt noch das Thema Kultur hinzu. Entsprechend der Prägung gilt
die direkte Benennung eines Fehlers als Gesichtsverlust oder Schwäche für das
jeweilige Projekt. Daher ist es umso wichtiger, frühzeitig auch den Prozess des
Risikomanagements mit dem Team zu besprechen und diesen auch zu leben.
Auch hier kommt Hofstede wieder ins Spiel. Als Beispiel werden Probleme in
Kulturen mit hoher Machtdistanz vom Vorgesetzten gelöst. Was in einem Projekt
auch die Wahrnehmung potentieller Bedrohungen einschränkt.
Fazit
 Führung und Risikomanagement bekommen in globalen Projekten noch

mal eine neue Bedeutung.
 Bedingt durch den kulturellen Hintergrund werden potentielle Risiken

oder Probleme nicht erkannt oder thematisiert.
 Eine frühzeitige Planung und Kommunikation des Risikomanagement- und
Eskalationsprozesses unter Einbeziehung der unterschiedlichen Wertevor-
stellungen sind für den Projekterfolg grundlegende Voraussetzungen, eben-
so wie eine gute Kenntnis über die relevanten Stakeholder.
Führung und Konfliktmanagement in internationalen Projekten 159
10 Agiles Projektmanagement
Das agile Projektmanagement ist eine weitere Methode, die in den letzten Jahren
an Bedeutung gewonnen hat. Daher möchte ich diese als Ergänzung zum bereits
beschriebenen Projektmanagement mit hinzufügen.
Agiles Projektmanagement hat seinen Ursprung in der Software-Entwicklung.

Nicht für alle Projekte macht das agile Arbeiten Sinn. Scrum ist wohl die bekann-
teste Methode agil zu arbeiten. Es ist aber nur eine der Optionen des agilen Pro-
jektmanagements. Da sie die bekannteste ist, möchte ich sie an dieser Stelle auch
genauer beschreiben.
Dabei sind auch die Ressourcenaufwände ein großes Thema. Zudem müssen die
Organisation und das Management hinter der Methode stehen. Agiles Arbeiten
ist vor allem für Projekte in überschaubarer Größe gut anwendbar. Team und
Rollen weichen stark von dem des klassischen Projektmanagements ab.
Vor dem Einsatz sollte aber immer vorab geprüft werden, ob die Methode für das
jeweilige Projekt sinnvoll ist. Oft liegt die Wahrheit in der Mitte und das klassi-
sche Projektmanagement mit einem Anteil agiler Methoden, wie z. B. Kanban
Boards, enge Anbindung an den Kunden oder auch tägliche Projektsitzungen,
unterstützen das Arbeiten in Projekten.
Wo liegt der Unterschied? Was heißt agil? Was ist klassisches Projektmanage-
ment? (vgl. Abb. 10.1)
Während sich im klassischen Projektmanagement aus dem Scope des Projektes

die Kosten und Termine ergeben, wird der Scope im agilen Projektmanagement
durch den Wert für den Kunden verändert.
Agil ein Wort, das aktuell viel verwendet wird. Wir wollen agiler werden, das
heißt aber nicht nur beweglicher und schneller, sondern agiles Projektmanage-
ment ist eine Methode mit klaren Spielregeln und Strukturen.
https://doi.org/10.1007/978-3-658-31310-4_10
Abbildung 10.1 Unterschiede agiles versus klassisches Projektmanagement
fixiert Scope Ressourcen Zeit
klassisches PM agiles PM
abgeleitet Zeit Ressourcen Scope
Agiles Projektmanagement und die Methode Scrum sind aus der IT abgeleitet.
Kent Beck hat als erfahrener Softwareentwickler im Jahr 2001 das sogenannte
agile Manifest formuliert. Jeff Sutherland und Ken Schwaber haben ihre Erfah-
rungen und ihre Best Practices aus IT Projekten zusammengetragen und in einer
Methode namens Scrum festgelegt.
Agiles Projektmanagement ist eine Antwort auf die immer höhere Geschwindig-
keit in Projekten, aber sicher keine Antwort auf alle Herausforderungen. Daher
wollen wir uns die Methoden Scrum und Kanban einmal näher ansehen. Und
natürlich ist es oft wie im wirklichen Leben, die Wahrheit liegt irgendwo in der
Mitte. Wo also machen die Methoden allein Sinn, und wo wäre das klassische
Projektmanagement mit agilen Methoden die bessere Wahl. Oder wo haben wir
schon immer ähnlich gearbeitet, es aber anders genannt ...
Die Bausteine des agilen Projektmanagements 161
Es gibt kein komplett einheitliches Verständnis, was genau zum agilen Projekt-
management gehört. Dennoch gibt es klar beschriebene Methoden, wie Scrum
oder Kanban. Agiles Projektmanagement wird gern als Oberbegriff für verschie-
dene Vorgehensmodelle bei der Software-Entwicklung verwendet. Die Bekann-
testen sind Scrum oder Kanban. Viele Unternehmen möchten agiler Arbeiten und
wenden diese Methoden an. Für mich ist ein wesentlicher Unterschied, dass die
Teams eigenverantwortlich arbeiten müssen. Dies wiederum fordert die Rolle
jedes Teammitglieds.
Die Herausforderung ist, für das jeweilige Projekt auch die richtige Methode und
die entsprechenden Teammitglieder mit den geforderten Kompetenzen zu haben
und das auch noch in eine Organisation eingebettet, die dies unterstützt.
Egal, welche Methode wir aus dem agilen Arbeiten wählen, ob Design Thinking,
Kanban oder Scrum, sie haben alle eines gemeinsam und bauen auf Folgendem
auf:
■ Exzellentes Teamwork und Gruppen-Intelligenz

■ Verringerung von Hierarchie und Top-down-Entscheidungen
■ Verringerung von Planung, Management, Regeln, Bürokratie
■ Selbstorganisation und Empowerment
■ Verbesserung der Kommunikation
Insgesamt stellt dies eine Herausforderung für die entsprechenden Teammitglie-
der dar. Eigenverantwortliches Arbeiten ist in jedem Fall die Basis.
10.1 Die Bausteine des agilen

Projektmanagements
Das agile Projektmanagement setzt sich aus unterschiedlichen Bausteinen zu-
sammen, die in der Methode Scrum sehr konkret beschrieben wurden.
Abbildung 10.2 Agile Bausteine (Quelle: Basis aus Scrum.org)
Agile Methoden
geben den agilen Techniken eine Gesamtstruktur hin zum Projektmanagement
Agile Techniken
sind konkrete Verfahren zur Umsetzung der Werte und Prinzipien
Agile Prinzipien
basieren auf den agilen Werten und geben Handlungsgrundsätze
Agile Werte
sind das Fundament
Was bedeuten diese agilen Bausteine für uns und was verbirgt sich dahinter?
10.1.1 Die „agilen Werte“

Sie stellen die Grundsätze im agilen Projektmanagement dar. Auf welche Werte
sich ein Einzelner, ein Team oder eine ganze Organisation fokussiert, hängt vom
jeweiligen Umfeld und der Einschätzung der Beteiligten ab und kann sich auch
im Laufe der Zeit ändern. Der wichtige Punkt dabei ist, dass überhaupt eine
gemeinsame und einheitliche Klarheit über das grundlegende Wertesystem ge-
schaffen wird. Geschieht dies nicht, dann existiert keine gemeinsame Basis, auf
der Entscheidungen getroffen und weitergehende Prinzipien, Strategien und
Praktiken definiert werden können.
Abbildung 10.3 zeigt einen Überblick über mögliche agile Werte, die auch im
agilen Manifest beschrieben sind. Bei der Betrachtung der agilen Werte wurde
eine Relation hergestellt zu dem, was wichtiger ist in der Zusammenarbeit von
eigen organisierten Teams. Wenn wir uns einmal auf die Definition von Werten
beziehen, dann sind Werte in einer Gesellschaft akzeptiertes Verhalten. Die für
uns in einem agil aufgestellten Projekt gültigen Werte aus dem agilen Manifest
stellen sich wie folgt dar.
Abbildung 10.3 Agile Werte (Quelle: Basis aus Scrum.org)
Agile Werte
Individuen und Prozesse und

mehr als
Interaktion Werkzeuge
Funktionierende Umfassende
Ergebnisse mehr als Dokumentation
Zusammenarbeit mit Vertrags-

Kunden mehr als verhandlungen
Reagieren auf Das Befolgen eines

Veränderungen mehr als Plans
Auf den agilen Werten bauen die „agilen Prinzipien“ auf. Sie definieren, wie wir
uns als Team verhalten wollen. Es sind die Handlungsgrundsätze, die wir für
unsere Gemeinschaft als Team für „richtig“ befinden.
10.1.2 Agile Prinzipien

Auf den agilen Werten bauen die „agilen Prinzipien“ auf. Sie definieren, wie wir
uns als Team verhalten wollen. Es sind die Handlungsgrundsätze, die wir für
unsere Gemeinschaft als Team für „richtig“ befinden:
■ Wertvolle Ergebnisse werden früh und kontinuierlich umgesetzt.

■ Anforderungsänderungen sind willkommen.
■ Das Team arbeitet (täglich) eng zusammen.
■ Motivierte Mitarbeiter werden aufgebaut und unterstützt (Vertrauen)
■ Direkte Kommunikation erfolgt von Angesicht zu Angesicht.
■ Funktionierende Ergebnisse beschreiben den Fortschritt.
■ Nachhaltige Entwicklungsgeschwindigkeit wird gefördert.
■ Die Einfachheit der Lösung steht im Vordergrund.
■ Selbstorganisierende Teams liefern die besten Ergebnisse.
■ Zusammenarbeit und Qualität werden regelmäßig reflektiert.
10.1.3 Agile Techniken

Die agilen Techniken sind konkrete Verfahren zur Umsetzung agiler Prinzipien –
immer mit dem Ziel einer höheren Flexibilität, schnelleren Reaktionsgeschwin-
digkeit sowie mehr Eigenverantwortung und einem effektiveren Arbeiten im
Team.
Abbildung 10.4 Beispiele agiler Techniken
Übersicht über
aktuelle Aufgaben
räumliche
Nähe
Definition of Done, klare
Festlegung, wann eine
Aufgabe fertig gestellt ist
Visualisierung des
Arbeitsstandes
Effiziente, tägliche
Statusmeetings
möglichst frühzeitige
Erzeugung von Time Boxing – wirklich
Kundennutzen feste Zeitvorgaben
10.1.4 Agile Methoden

Agile Methoden sollen uns unterstützen, das Projekt in einer bestimmten Weise
zu managen. Sie stützen sich dabei auf die von uns definierten Techniken, Prin-
zipien und Werte.
An dieser Stelle möchte ich auch einmal auf den Unterschied hinweisen, den wir
zwischen dem agilen und den klassischen Methoden machen. Beides hat seine
Existenzberechtigung. Allerdings ist es immer wieder wichtig, die Rahmenbedin-
gungen der Projekte im Auge zu behalten und die für uns sinnvollste Methode
zum Einsatz zu bringen.
10.1.5 Klassische Methoden versus agile in der Theorie

klassisch agil
Kunde sieht nur Endergebnis Kunde sieht Zwischenergebnis
Dies kann ich aus meiner Erfahrung nicht bestätigen. Auch im klassischen
Projektmanagement werden regelmäßig Zwischenstände mit dem Kunden
abgestimmt.
große Teams möglich relativ kleine Teams nötig
Durch die eigenorganisierten Teams ist es in kleinen Teams einfacher.

Allerdings werden auch im klassischen Projektmanagement bei großen
Projekten die Teams in der Projektorganisation auf kleinere, überschaubare
Teams heruntergebrochen (Stichwort Teilprojekte).
klare Hierarchien selbstorganisierte Teams
Im klassischen werden die Fachspezialisten eingesetzt, die für ihren jewei-

ligen Fachbereich die Entscheider sind. In agilen Organisationen geben sich
die Teams ihre Aufgaben selber.
Aufgaben von oben zuteilen Aufgaben selbstständig übernehmen
Auch an dieser Stelle ist die Projektmanagement-Welt nicht ganz schwarz/

weiß. Die Meilensteine, die es klassisch zu erledigen gilt, werden idealer-
weise mit den jeweiligen Fachbereichen abgestimmt. Die Arbeiten bzw.
Arbeitspakete, die sich daraus mit den jeweiligen Zeit- und Aufwandsab-
schätzungen ergeben, sollten das Teammitglied, der Projektleiter und
auch der Linienvorgesetzte gemeinsam abstimmen.
viel Kommunikation über viel informelle Kommunikation über

Meetings und Dokumente Stand-up-Meetings
Im klassischen Projektmanagement ist die Art der Abarbeitung eher durch

den Führungsstil des Projektleiters gegeben und weniger durch die Me-
thode, wie im agilen Projektmanagement. Allerdings bedingen viele Groß-
projekte auch eine gute Dokumentation. Dies ist oft schon gesetzlich vor-
geschrieben.
Die Methode Scrum 167
Bekannte agile Methoden, die sehr detailliert beschrieben und aus der Software
Entwicklung auf andere Projekte übertragen wurden, sind:
■ Scrum
■ Kanban
■ Extreme Programming
■ Design Thinking
■ Lean Start uUp
Eine der bekanntesten Methoden des agilen Projektmanagements ist die Methode
Scrum. Diese soll mit ihren Spielregeln im Folgenden konkreter beschrieben wer-
den, auch um ein Gefühl dafür zu vermitteln, welche neuen oder auch anderen
Anforderungen an die beteiligten Personen gestellt werden.
Wir erinnern uns, der Erfolg der Methode Projektmanagement hängt weder im
Einkauf noch in anderen Bereichen allein vom Team, sondern sehr stark von der
die Methode beeinflussenden Organisation ab und der Art, wie Entscheidungen
getroffen werden.
10.2 Die Methode Scrum

Scum wurde durch seine „Erfinder“ Ken Schwaber und Jeff Sutherland im Scrum
Guide beschrieben. Die Definition von Scrum lautet auf Basis von scrum.org wie
folgt:
„Scrum ist ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive

Aufgabenstellengen angehen können und durch das sie in die Lage versetzt wer-
den, produktiv und kreativ Produkte mit höchstmöglichem Wert auszuliefern.“
Scrum ist:
■ leichtgewichtig
■ einfach zu verstehen
■ eine Methode, die eine starke Eigenorganisation der Teams verlangt
■ für große Projekte, wie es sie im Infrastrukturbereich gibt, weniger geeignet.
10.2.1 Der Ablauf von Scrum
Abbildung 10.5 Überblick Prozessablauf im Agilen Projektmanagement der

Methode SCRUM
Idee Kunde – Stakeholder
Product Backlog
Product Owner Prio 1 Prio1
Prio 2
Prio 3
Sprint Backlog
Sprint Planning Der Product Owner
Scrum Master Das Entwicklerteam
Sprint Dauer Review

max. 30 Tage Retroperspektive
10.2.2 Die Rollen im Scrum

Wie stehen die Rollen zueinander oder das Zusammenspiel zwischen
Scrum Master
Product Owner Team
Wir sprechen im Scrum über drei Rollen, die ich im Weiteren beschreiben möch-
te. Diese basieren auf den beschriebenen Rollen der Erfinder von Scrum.
Product Owner
Die Rolle des Product Owners ist entscheidend für die Gestaltung und den Wert
des Produktes. Der Product Owner ist das Gesicht des Kunden im Scrum. Er ist
auch der Einzige, der für das Management des Backlogs zuständig ist. Auch ist er
auch gleichermaßen für den wirtschaftlichen Erfolg des Projektes zuständig. Der
Product Owner ist der Ansprechpartner, wenn es um die Anforderungen des zu
entwickelnden Produktes im Sinne des wirtschaftlichen Mehrwertes geht. Er
muss kein Fachspezialist sein. Dennoch muss er aus Kundensicht vertreten.
Der Product Owner trägt die Verantwortung für die korrekte Führung des Pro-
duct-Backlogs. Er arbeitet gemeinsam mit den Stakeholdern an Veränderungen
und schreibt diese in aus seiner Sicht geeignete User Stories um. Die Einträge
werden von ihm priorisiert und sortiert. Alle Mitglieder des Entwicklungsteams
müssen die Einträge verstehen und auch sehen können. Verändern darf sie aber
nur der Product Owner.
Während des jeweiligen Sprints arbeitet der Product Owner sehr eng mit seinem
Team zusammen. Sein Ziel ist es, dass alle für den Sprint beschriebenen User
Stories fertig sind und das Ziel des Sprints erreicht wird.
Im Scrum Guide wird sogar beschrieben, dass die Entscheidungen des Product
Owners hinsichtlich seines Projektes von der Organisation zu akzeptieren sind,
damit sein Erfolg gewährleistet ist. Würde man einem Projektleiter eine gleiche
Entscheiderkompetenz zuteilen, so wären seine Erfolgschancen sicherlich auch
um einiges höher.
Aufgaben des Product Owners:
■ Hoheit über das Backlog

■ Im Product Backlog Einträge klar und verständlich formulieren.
■ Dafür sorgen, dass alle Einträge des Backlogs für alle Teammitglieder sichtbar
und klar sind sowie aufzeigen, welche Arbeiten als nächstes anstehen.
■ Sortierung der Einträge im Backlog per Sprint und gegebenenfalls Priorisie-

rung.
Der Product Owner kann die Arbeiten selbst durchführen oder sie an das Team
übergeben. Die Verantwortung bleibt jedoch bei ihm.
Die Rolle des Scrum Master
Der Scrum Master ist, wie das Wort bereits sagt, verantwortlich für den Scrum,
d. h. für die Einhaltung der Methode. Ähnlich der Rolle eines Change Managers
muss er dafür sorgen, dass die Methode eingehalten und auch in die Organisa-
tion getragen wird. Der Scrum Master ist Support und Ansprechpartner für die
Teams. Er hilft dem Team auch, Störgrößen der Arbeitsumgebung zu eliminieren.
Er hat ein offenes Ohr für die Probleme und hilft dem Team, diese zu beseitigen.
Er unterstützt das Team genauso wie den Product Owner.
In Richtung Product Owner ist er in erster Linie Unterstützer zur Anwendung

der Methode Backlog. Er vermittelt die Techniken für eine effektive Verwaltung
des Backlogs. Außerdem unterstützt er ihn darin, die Inhalte zu priorisieren. Er
unterstützt das Team in einem reibungslosen Ablauf:
■ Er coacht das Team hinsichtlich Teamentwicklung und Methode.

■ Er entfernt Hindernisse, die das Team bei der Zielerreichung stören könnten.
■ Er unterstützt bei Scrum-Ereignissen (Durchführung von Sprints, Retropers-
pektiven, …)
Seine Rolle in Richtung Organisation liegt darin, dass er auch diese in Sachen Ein-
haltung des agilen Projektmanagements und seiner Methode unterstützt. Auch
bei der Auswahl von Projekten, die für den Einkauf mit agilen Methoden ab-
gebildet werden sollen, ist er Unterstützer.
Das Development TEAM
Das Entwicklungsteam setzt sich aus den Fachspezialisten zusammen, die in der
Lage sind, die Anforderungen des Kunden in ein fertiges Produkt umzusetzen.
Die eigentlich gängige Rolle aus dem klassischen Projektmanagement bekommt
im Rahmen des agilen PM eine größere Eigenverantwortung. Das Team bestimmt
mit, an welcher Aufgabe als nächstes gearbeitet wird, wobei dies auch der Ent-
wickler oder Einkäufer im Rahmen seines Verantwortungsbereiches machen
kann. Während es im agilen PM um die Einhaltung des Sprints geht, muss der
Einkäufer im klassischen Projektmanagement die Ziele der Meilensteine errei-
chen. Das Entwicklungsteam ist interdisziplinär und beinhaltet alle Fachfunktio-
nen, die der Abarbeitung des Backlogs dienen. Zwar haben einzelne Mitglieder
des Teams spezielle Fachfunktionen, anders als im klassischen liegt jedoch die
Verantwortung für die Abarbeitung im gesamten Team und wird nicht den ein-
zelnen Funktionen zugeordnet.
Eine wichtige Regel im agilen Projektmanagement für das Team ist:
■ Die Entwickler arbeiten ausschließlich nach den fachlichen Angaben des Pro-
duct Owners.
■ Die Entwickler dürfen nicht von außerhalb des Scrum-Teams zusätzliche

Aufgaben bekommen.
10.2.3 Produkt Backlog

Das Produkt Backlog obliegt der Verantwortung des Product Owners. Auf Basis
der User Stories wird das Produkt Backlog entwickelt. Die User Stories spiegeln
die Anforderungen des Kunden an das Produkt. Das Development Team ent-
wickelt daraus das Produkt Backlog.
Im weiteren Projektfortschritt ermittelt das Team die Sprint Backlogs (Aufgaben,

die je Sprint erledigt werden sollen oder müssen). Das Produkt Backlog ist sozu-
sagen ein strategisches Planungsinstrument. Hiermit wird die Ausrichtung für
das Projekt bzw. Produkt gegeben. Jede User Story bzw. jede im Backlog enthal-
tene Anforderung soll einen sichtbaren Mehrwert für den Kunden abbilden. Die
Anforderungen können hinsichtlich ihres Geschäftswertes bewertet und priori-
siert werden.
Ein Produkt Backlog entspricht einer geordneten Liste mit allen Anforderungen,
die bekannt sind und die das Produkt enthalten sollte. Im klassischen PM würde
man es ein detailliertes Lastenheft nennen. Zugriff auf das Produkt Backlog
haben alle, ändern allerdings darf nur der Product Owner. Anders als im Lasten-
heft, sind die Anforderungen im Backlog niemals vollständig. Im klassischen
Projektmanagement werden neue Anforderungen über den Change Request
offiziell implementiert, im agilen Projektmanagement entwickelt sich das Produkt
Backlog mit fortschreitendem Projekt immer weiter. Immer mit dem Ziel, das
Produkt so gut zu entwickeln (oder die Aufgabe), dass es den größtmöglichen
Nutzen auf, auf Basis der beschriebenen User Story, für den Kunden bietet. Man
kann auch sagen, dass im Produkt Backlog die User Stories sortiert werden, um
dann im weiteren Verlauf des Projektes mit dem agilen Planen beginnen zu kön-
nen. Mit dieser Art des Vorgehens wird auch deutlich, für welche Projekte sich
eher das klassische, das agile oder aber auch ein klassisches Projektmanagement
mit agilen Methoden eignet.
Abbildung 10.6 Kanban Board
user stories to do work in progress done
Story 1 Task A Task B Task A

……….
Task B
Story 2 Task C
……….
Task C
Story 3
……….
Als Sprint wird ein Zeitabschnitt von ein bis vier Wochen definiert, in dem sich
das Entwicklungsteam als Ziel gesetzt hat, bestimmte Aufgaben oder Arbeitspa-
kete aus dem Backlog abzuwickeln. Eigentlich könnte man im klassischen Pro-
jektmanagement die Zeit zwischen zwei Meilensteinen auch Sprint nennen. Der
Zeitraum wird nicht verlängert. Am Ende eines jeden Sprints wird reflektiert,
was gut und was schlecht gelaufen ist. Dies geschieht im Sprint Review. Dieses
findet ohne den Kunden statt, anders als die Retroperspektive, die gemeinschaft-
lich mit dem Kunden stattfinden kann. Während des Sprint Planning wird festge-
legt, welche Arbeiten aus dem Produkt Backlog in das Sprint Backlog überführt
werden. Übersetzt heißt das, es gibt einen genauen Plan, welche konkrete Punkte
in der definierten Zeit eines Sprints zu erledigen sind.
10.2.4 Planning Poker oder das Abschätzen von

Aufwänden
Im agilen Projektmanagement wird der Aufwand erst einmal nicht in Tagen ge-
schätzt. Planning Poker ist eine relative Aufwandsschätzung für User Stories in
der agilen Welt. Sie wird tatsächlich über ein Kartenspiel durchgeführt. Die
Punktewertung ist keine absolute Messgröße, sondern spiegelt den relativen
Arbeitsaufwand, den jedes Teammitglied schätzt.
Weichen die Schätzwerte stark voneinander ab, so lässt der Scrum Master die ein-
zelnen Teammitglieder ihre Beweggründe für die Einschätzung darlegen. Danach
wird eine weitere Runde geschätzt, bis die Teammitglieder annähernd Konsens
über den anstehenden Aufwand haben. Erst dann werden die Story Points der
jeweiligen User Story zugeordnet.
Haben alle User Stories Ihre Punkte erhalten, kann daraus der Aufwand für die
jeweiligen Sprints abgeleitet werden.
10.2.5 Daily Scrum Meeting

Die Verfolgung des Projektfortschritts erfolgt im Daily Scrum, einem täglichen
Team Meeting. Hier werden auch Themen genannt, die den Erfolg fördern bzw.
Hindernisse, die es aus dem Weg zu räumen gilt. Im Verlauf des Meetings sollte
jedes Mitglied des Entwicklungsteams folgende Fragen beantworten:
■ Welche Aufgaben habe ich gestern erledigt (done)?

■ Welche Aufgaben plane ich heute zu erledigen?
■ Welche Störgrößen gibt es, die mich davon abhalten könnten?
Die Fragen dienen der Transparenz im Projekt und helfen, die Prozesse und Auf-
gaben besser zu verstehen. Ebenfalls wird dadurch das Teamgefühl gestärkt.
10.2.6 Sprint Backlog und Daily Scrum

In einem Sprint Backlog befinden sich alle „Arbeitspakete“, die das Team für not-
wendig hält, um die vereinbarten Definition of Done – (Kriterien der Zielerrei-
chung) und das jeweilige Sprintziel zu erreichen. Den Sprint-Fortschritt bzw. die
anstehenden Tätigkeiten, Probleme und Hindernisse werden im Daily Scrum be-
sprochen – ein Stand Up Meeting, welches laut Definition „Daily“ stattfindet, in
der Praxis aber sehr oft weniger häufig. Die Teilnahme am Meeting ist für das
Team verpflichtend. Das Daily Scrum stellt kein Status Meeting dar, so wie wir es
im klassischen PM gewohnt sind. Das Ziel ist die Synchronisation im Team und
nicht die Rechtfertigung über geleistete oder nicht geleistete Arbeitspakete.
10.2.7 Retroperspektive als Ausgangspunkt für die

Verbesserung im Team
Das Prinzip der Retroperspektive wird im agilen Manifest beschrieben. Die Ret-
roperspektive dient einer Reflektion der Vergangenheit mit dem Ziel der Imple-
mentierung von Verbesserungen. Im Mittelpunkt steht vor allem die Zusammen-
arbeit im Team. Die Zusammenarbeit hat durch die Eigenverantwortung der
Teammitglieder eine hohe Priorität. Es gibt offiziell keine Führungsperson, inso-
fern dient dieses Meeting der Vereinbarung über weitere, das Team verbessernde
Tätigkeiten. Das Team bekommt von außen keine Vorgaben, sondern muss sich
die aus Teamsicht richtigen Arbeitsweisen zur Zielerreichung selbst auswählen.
Bereits in unseren Werten und Methoden haben wir vereinbart, dass Verbesse-
rungen immer willkommen sind. Und somit auch nicht als Kritik, sondern als
kontinuierliches Hilfsmittel angesehen werden. Im Scrum ist sie Bestandteil der
Methode und als Sprint-Retroperspektive Bestandteil eines jeden Sprint-Ab-
schnitts.
Dies ist auch ein Vorgehen bzw. eine Methode, die sich sehr gut in das klassische
Projektmanagement einbetten lässt. Sehr oft wird dieses Vorgehen als Workshop
im Projekt durchgeführt. Hier organisiert durch die Rolle und in der Verantwor-
tung des jeweiligen Projekt- oder Teilprojektleiters. Wenn man einen Zeit-
abschnitt zwischen zwei Meilensteinen betrachtet, könnte man diesen genauso
wie einen Sprint sehen. Mit zu erreichenden Zielen (Definition of Done) und
klaren Ergebnissen. Ein solches Daily ist auch im klassischen Projektmanagement
hilfreich. Oft nimmt man sich nicht die Zeit dafür. Der Pay Back an reibungslose-
rem Ablauf ist aber hoch. Ich habe dies selbst immer in sogenannten Krisen-
projekten gemacht. Da der Leidensdruck in solchen Projekten hoch genug ist, war
es keine Frage für das Team, diese Zeit zu investieren.
In der Methode Scrum ist die Sprint-Retroperspektive als Methode und Bestand-
teil wie folgt beschrieben:
Verantwortlich für das Meeting ist an dieser Stelle der Scrum Master. In seinen
Verantwortungsbereich fällt auch die Einhaltung des Zeitplans (Time Box).
Wichtig ist, dass potentielle Konflikte durch den Scrum Master gut gesteuert
werden. Im klassischen Projektmanagement geschieht dies durch die Rolle des
Projektleiters.
Das agile Projektmanagement mit Scrum ist eine Methode, die seit Jahren in aller
Munde ist. Sie weicht aber stark von der des klassischen Projektmanagements ab.
Auch wenn sie sich auf weitere Anwendungsgebiete übertragen lässt, so darf
man hierbei nicht vergessen, dass das agile Arbeiten aus der IT-Entwicklung
stammt. Die Herausforderung ist auch hier, für die richtige Aufgabe die richtige
Methode zu implementieren und die für die neue Rolle entsprechenden Team-
mitglieder zu haben. Nicht zu vergessen, dass das agile Arbeiten eine gute Res-
sourcenverfügbarkeit und ein Team benötigt, das eigenverantwortlich arbeiten
kann und will.
Vorteile von agilem Arbeiten oder Scrum:
■ kurze Kommunikationswege
■ selbstorganisierte Teams können eine hohe Effektivität erzielen
■ transparentes Arbeiten dank Daily´s und allen zugänglichen Backlogs
■ kontinuierlicher Verbesserungsprozess
Nachteile
■ hoher Ressourcenaufwand durch enge Kommunikation

■ keine konkreten Handlungsanweisungen durch die sich selber organisieren-
den Teams
■ Zeitverlust durch zu vorsichtig geplante Sprints

■ Weniger geeignet für große, lange laufende Projekte
Wenn wir uns die Vorteile von Scrum ansehen, dann stellt sich die Frage, wie
man auch für große Projekte das Beste aus beiden Welten zusammen bekommt.
Also welche Methoden des agilen Projektmanagements kann ich übertragen? Für
mich beantwortet sich dies erst einmal so:
■ Kundennähe – kurze Berichtswege durch engere Einbindung des Kunden (im

agilen durch den Product Owner umgesetzt)
■ höhere Transparenz – tägliche Meetings, visualisierte Aufgaben (z. B. Kanban

Board); kann auch im klassischen Projektmanagement genutzt werden
■ klare Spielregeln für das Team – siehe Werte im agilen Projektmanagement

■ Meilensteine (entsprechend Sprint) sauber setzen und die entsprechend not-

wendigen Arbeitspakete aus dem Projektstrukturplan im Kanban abbilden
Dies ist eine einfache Beschreibung zum Transfer von Methoden aus dem agilen
Arbeiten in das klassische Projektmanagement. Sind die Teammitglieder moti-
viert, ist die Kommunikation gut, werden im Bereich und im Projekt die gleichen
Spielregeln gespielt, so läuft auch das Projekt gut.
Wichtig ist immer, dass wir das vorhandene Know-how der Beteiligten möglichst
effizient zusammen tragen und die Organisation das Vorgehen unterstützt.
10.2.8 Review mit dem Kunden

Anders als die Retroperspektive, findet das Meeting nicht nur mit dem Team,
sondern auch mit dem Kunden statt. Das Review ist ein wichtiger Bestandteil des
Sprints. Das Team präsentiert dem Kunden bzw. dem Product Owner das Pro-
dukt. Interessierte Stakeholder sind in diesem Meeting auch willkommen.
Da die Anforderungen an das Produkt im agilen Projektmanagement als verän-

derbar gelten, geht es im Review um folgende Punkte:
■ Ist das Ziel für den Sprint erreicht bzw. hat das Produkt die geforderten
Eigenschaften? Steht das sogenannte Inkrement = vorzeigbares Produkt mit
entsprechend definierten Eigenschaften? Je nach Wichtigkeit für Team und
Kunden wird abgestimmt, ob das Produkt bzw. das jeweilige Item auch
demonstriert werden soll; gern in einer Tabelle vorab versendet, damit auch
hier das Thema Transparenz gelebt wird.
■ Feedback erhalten über die erledigten Aufgaben während des Sprints (ent-
sprechen Vorstellung des Produkts oder die Features).
■ Wenn alle Product Backlog Items für den Sprint vorgestellt wurden, werden
die wichtigsten Ergebnisse und auch Herausforderungen besprochen. Meist
werden diese vom Scrum Master oder vom Product Owner moderiert. Beides
ist möglich.
■ Durch das Feedback zum bereits bewältigten Sprint, ergeben sich oft Anfor-
derungen für den anstehenden Sprint und für mögliche Anpassungen der
Backlog Items. Daher ist meist der letzte Punkt auf der Agenda des Reviews
der Ausblick auf den nächsten Sprint sowie die hierfür anstehenden Tätig-
keiten.
Fazit
 Ein wichtiger Teil am Ende jeden Sprints ist das Review mit dem Kunden
und interessierten Stakeholdern, mit dem Ziel, Feedback für die erledigten
Aufgaben zu erhalten und daraus resultierend eventuell auch das Backlog
für den kommenden Sprint anzupassen.
Dies war ein kurzer Einblick in das agile Arbeiten in Projekten. Beide Methoden,
sowohl das klassische Projektmanagement als auch das agile Projektmanagement
haben ihre Existenzberechtigung. Es ist wichtig, Abzugrenzen vorzunehmen,
d. h. an welcher Stelle und für welche Projekte die geeignetste Methode einge-
setzt werden kann.
11 Führung in agilen Projekten

Auch wenn es offiziell keine Führung in agilen Projekten gibt, so muss diese
durch das Team bzw. durch die Rahmengbedingungen, die gegeben sind, umge-
setzt werden. Ohne Ordnung und Ziel gibt es auch kein Ergebnis. Wer den Hafen
nicht kennt, in den er segeln will, für den ist kein Wind ein günstiger. Seneca will
auch im agilen Projektmanagement gesehen werden.
Die Beschreibung von Führung lautet laut Wirtschaftslexikon wie folgt:
„Führung ist die Fähigkeit, eine Richtung vorzugeben, andere im Sinne eines gemeinsa-
men Ziels zu beeinflussen, sie zu motivieren und zum Handeln zu bringen und sie für
Ihre Leistung in die Verantwortung zu nehmen.“
Wenn wir uns das Konstrukt des agilen Projektmanagements ansehen, ist in der
Theorie beschrieben, dass es, anders als im klassischen Projektmanagement den
Projektleiter, keine einzelne Führungspersönlichkeit gibt. Dennoch kommt natür-
lich auch das agile Projektmanagement nicht ohne eine Form der Steuerung aus.
Dies kann wie nachfolgend beschrieben werden:
Ein gemeinsames Ziel wird als erstes über die User Stories durch den Kunden
vorgegeben. Das Backlog, welches durch den Product Owner organisiert und
priorisiert wird, ergibt die Arbeitspakete. Das Team nimmt sich die Arbeitspakete
für den jeweiligen Arbeitsabschnitt, den Sprint, selber. Störgrößen werden durch
den Scrum Master bearbeitet. Das sogenannte Impediment Backlog ist eine Auf-
listung der zu bearbeitenden Störgrößen, die das Leben des Teams erschweren.
Dieses Backlog wiederum unterliegt der Verantwortung des Scrum Masters.
Hierunter können auch Themen fallen, wie Infrastruktur, Lautstärke, Probleme in
der Kommunikation. Wir reden also nicht nur über die technischen Themen, son-
dern alles, was den Erfolg des Projektes gefährden könnte. Für den Scrum Master
gilt an dieser Stelle nicht „Melden oder Dokumentieren“, sondern die benannten
Themen müssen schnellstmöglich aus dem Weg geräumt werden. Wichtig ist zu
entscheiden, welche Themen in das Impediment Backlog gehören und welche
Themen kann und muss das Team selber lösen.
https://doi.org/10.1007/978-3-658-31310-4_11
180 Führung in agilen Projekten
11.1 Die Kommunikation im agilen

Projektmanagement
Wenn wir bereits im klassischen Projektmanagement feststellen, dass 95 % aller
Tätigkeiten des Projektleiters im Kontext Kommunikation stehen, so sind dies im
agilen wohl nahezu 100 %. 5 % mehr oder weniger ist hier allerdings nicht die
Frage, sondern deutlich ist, für den Erfolg eines Projektes ist gute Kommunikati-
on eine Grundvoraussetzung. Da es den klassischen Projektleiter im Scrum nicht
gibt, muss die ansonsten von ihm übernommene Kommunikation auf drei Rollen
verteilt werden. Der Product Owner, der Srum Master und das Entwicklungs-
team stellen autarke Rollen mit eigenen Führungskompetenzen dar. Die Kom-
munikation im Team organisieren die Teammitglieder selber. Diese ist auf die
Arbeitspakete fokussiert und die Abarbeitung. Die Kommunikation mit dem
Scrum Master findet in Form der Daily´s statt oder bei anfallenden Problemen.
Die Kommunikation mit den Stakeholdern entfällt und wird sozusagen durch
den Product Owner ersetzt. Seine Rolle ist unter anderem das Sprachrohr für den
Kunden und die Stakeholder. Damit sind die Schnittstellen abermals minimiert
worden. One Face to the Customer könnte man auch hier sagen.
Allerdings findet das normale Leben auch mit den agilen Methoden weiterhin
statt. Das heißt, die Herausforderung der Kommunikation nach innen und außen
ist ein Spannungsfeld, welches es in Balance zu halten gilt. Herr Schulz von Thun
mit seinem Vier-Ohren-Prinzip bleibt uns erhalten. Die Challenge des Austau-
sches im Team von Informationen auf der Sachebene und auf der anderen Seite
von emotionaler und auch Beziehungsebene, gilt es zu meistern. Das Team kann
nur gut arbeiten, wenn beide Ebenen bedient werden.
Wie sagte einmal ein guter Freund, nur sprechenden Menschen kann man helfen.
Dies gilt auch für das Projektmanagement. Daher sind folgende Schwerpunkte in
der Kommunikation zu beachten, um eine gute Transparenz im Projekt zu erhal-
ten.
■ Austausch von Sachinformationen mit dem Ziel der Abarbeitung von Arbeits-
paketen
■ Gute Kommunikation, auch wenn es mal nicht reibungslos läuft (Wie wollen
wir Konflikte lösen?)
■ Dialogfähigkeit
Der Product Owner und die Herausforderung an seine kommunikativen Fähigkeiten181
11.2 Der Product Owner und die

Herausforderung an seine
kommunikativen Fähigkeiten
Die Rolle des PO´s ist es, dass sich das Team die Aufgaben in den Sprints so setzt,
dass die Anforderungen des Kunden und der Stakeholder abgebildet werden.
Die Stakeholder sind Personen oder Personengruppen, die einen Einfluss auf das
Projekt haben können. Neben dem Kunden beeinflussen sie das Projekt durch
direkte oder indirekte Anforderungen. Der Product Owner stellt die Schnittstelle
zu diesen Personen oder Personengruppen und natürlich zum Kunden dar. Er
hält sie über den aktuellen Stand auf dem Laufenden. Die „Führung“ und Kom-
munikation in den Sprints läuft direkt im Team ab. Daily Scrums unterstützen
das Vorgehen. Wie auch immer man es betrachten möchte: der Product Owner ist
im agilen und im Scrum verantwortlich für die Umsetzung der Anforderungen
des Kunden. Und damit auch für das gewünschte Endergebnis.
Fazit
 Das Arbeiten in Scrum ist eine Methode im agilen Projektmanagement und

bisher die bekannteste.
 Der wesentliche Unterschied zum klassischen Projektmanagement liegt in

der Eigenorganisation der Teams, den noch klareren Regeln und Werten.
 Durch die täglichen Meetings und die Visualisierung haben Kommunika-

tion und Transparenz oberste Priorität.
 Scrum kommt aus der IT und ist daher nicht für alle Großprojekte geeignet.
Was versprechen wir uns von Einkauf 4.0? 183
12 Digitalisierung oder Einkauf 4.0

Die Digitalisierung macht auch vor dem Einkauf und seinen Projekten nicht halt.
Und stellt neue Herausforderungen an die Kenntnisse des Einkäufers. Durch Glo-
balisierung und den immer weiter wachsenden Kostendruck müssen die Unter-
nehmen, um wettbewerbsfähig zu bleiben, ihre Prozesse digitalisieren und im-
mer weiter über neue Technologien und Anpassungen ihrer Software nachden-
ken. Wenn wir bisher viel über Industrie 4.0 gehört und gelesen haben, so
gewinnt das Thema Einkauf 4.0 immer weiter an Bedeutung. An dieser Stelle
möchte ich keinen wissenschaftlichen Artikel über Digitalisierung schreiben,
dennoch einmal ein paar Gedanken und Verknüpfungen, was Digitalisierung in
Bezug zum Thema Projektmanagement im Einkauf bedeuten kann. In vielen
Unternehmen sind administrative Aufgaben bereits automatisiert. Daher ver-
lagert sich bereits hier die Rolle in den strategischen Einkauf oder den Projekt-
einkauf. In einigen Jahren wird er laut einer Studie des Fraunhofer Instituts nicht
mehr existent sein, da alle administrativen Einkaufsprozesse komplett automa-
tisiert werden können. Das Berufsbild des klassischen Beschaffers wird damit
Geschichte sein. Projektmanagement und Schnittstellen-Management treiben die
Werteschaffung in Form von Einsparungspotentialen.
Wir unterscheiden, je nach Unternehmen, zwischen Prozessen und Tätigkeiten im

operativen Einkauf und Prozessen und Tätigkeiten im strategischen Einkauf. Ein-
kauf 4.0 ist nicht einfach der Einsatz eines IT-Tools, sondern ein Change-Manage-
ment-Prozess, der eine klare Prozess- und Datenanalyse voraussetzt.
12.1 Was versprechen wir uns von Einkauf 4.0?

Wie immer, ist das Ziel eine Optimierung der Wertschöpfungskette. Um die Digi-
talisierung sinnvoll zu gestalten, ist das nicht mehr nur eine Unterstützung bzw.
ein Datentransfer durch IT-Systeme, sondern die Prozesse müssen ganzheitlich
gestaltet werden. Eine horizontale und vertikale Vernetzung der Prozesse sollte
erfolgen, damit nicht nur Teilprozesse digitalisiert werden, sondern die Daten
ganzheitlich zusammengefügt werden können. Der Einkauf 4.0 geht an dieser
Stelle noch einen Schritt über die bekannte digitale Vernetzung der Supply Chain
hinaus. Wie genau die Umsetzung in zehn Jahren aussehen kann, dürfen wir nur
ahnen. Ein aus meiner Sicht bedeutender Unterschied zur alleinigen Digitalisie-
rung ist die Vernetzung über Unternehmen hinweg. So soll die digitale Zukunft
nicht mehr nur auf das eigene Unternehmen und die Produktionsdaten zurück-
https://doi.org/10.1007/978-3-658-31310-4_12
greifen, sondern auch auf die der Lieferanten bzw. der Lieferantenkette. Es wird
spannend, wie die Unternehmen diesen Change bewältigen werden. Auch die
Kommunikation in Echtzeit der Systeme wird ein weiterer Baustein, so z. B.
mehrstufige Vernetzungen, in der die Kommunikation der Systeme in Echtzeit
miteinander in den Ablauf eingebunden werden sollen.
Durch diese neue Form der Analyse und Kommunikation können Handlungsbe-
darfe entlang der Wertschöpfungskette frühzeitig erkannt und entsprechende
Maßnahmen eingeleitet werden. Wir versprechen uns konkret von der Digitali-
sierung:
■ eine schnellere und flexiblere Anpassung an die Bedarfe im Unternehmen

■ Kosteneinsparung durch automatisierte Abläufe
■ Reaktionsbeschleunigung durch Echtzeit-Kommunikation
■ eine verbesserte Vernetzung von Daten über die Supply Chain hinaus – In-
formationen werden in Echtzeit zur Verfügung gestellt (unternehmensüber-
greifender Austausch von Daten und Informationen)
Um dieses Ziel zu erreichen, setzt es eine gute Analyse der Ist-Situation voraus.
Einkauf 4.0 ist ein Change-Prozess, der das gesamte Unternehmen betrifft und
für den die Voraussetzungen erst geschaffen werden müssen. Dies ist eine große
Herausforderung für alle Firmen – ein Change-Prozess, der viele bekannte Ab-
läufe über den Haufen wirft und auch die Rolle der Einkäufer komplett verän-
dert.
Hier einmal nur ein paar Stichworte, was wir benötigen, damit Digitalisierung
überhaupt stattfinden kann:
■ Bestandsaufnahme des Einkaufs: Wo steht der Einkauf aktuell in Sachen Digi-

talisierung (angelehnt an die Gesamtstrategie des Unternehmens)?
■ Verfügbarkeit aller Daten der Einkaufsprozesse

■ Wie sieht der aktuelle relevante Einkaufsprozess für das jeweilige Unterneh-
men aus?
■ Wissen, welche Daten der Supply Chain zusätzlich erhoben werden können
■ Komplexe Abstimmung mit allen Beteiligten (Schnittstellenmanagement oder
Projektmanagement gewinnen an Priorität)
Der operative Einkauf und seine Aufgaben 185
Da wir zwischen den Tätigkeiten im operativen und strategischen Einkauf unter-

scheiden, möchte ich als Reminder noch einmal die unterschiedlichen Tätigkeits-
felder beschreiben. Schnell wird klar, dass der operative Einkauf in seiner aktuel-
len Rolle wenig Raum im Einkauf 4.0 haben wird, dafür wird aber die Rolle des
strategischen Einkäufers noch viel mehr eine Erweiterung in Richtung Projekt-
manager bzw. Schnittstellenmanager erfahren.
12.2 Der operative Einkauf und seine

Aufgaben
Im klassischen Sinne ist der Job des operativen Einkaufs die benötigten Materia-
len und Ressourcen zur richtigen Zeit, in der richtigen Menge, am richtigen Ort
und zum richtigen Preis zu haben. Die Rolle des operativen Einkäufers ist es, die
administrativen und direkten Einkaufstätigkeiten wahrzunehmen. Zu seiner
Tätigkeit gehören:
■ Bestellabwicklung
■ Reklamationsbearbeitung
■ Terminkoordination
■ Rechnungsprüfung
Abbildung 12.1 Der operative Einkaufsprozess
Bedarfs- Bedarfs- Bestellung Termine Rechnung

Controlling
meldung erkennung auslösen verfolgen verfolgen
Pflege der Stammdaten und Lieferantencontrolling
In vielen Unternehmen sind einige Prozessschritte bereits komplett digitalisiert.

Falls in der Zukunft die Rolle des operativen Einkäufers tatsächlich nahezu kom-
plett an die Systeme abgegeben wird, ist aber auch klar, dass die Anforderungen
an den strategischen Einkäufer mit seinen Aufgaben wachsen. Noch immer kön-
nen Maschinen nicht die Netzwerkpflege übernehmen. Was aber wird die neue
Rolle sein?
12.3 Der strategische Einkauf und seine

Aufgaben
Abbildung 12.2 Challenge accepted – Herausforderung an die Rolle des Ein-

käufers der Zukunft?
Rolle zusätzliche Skills
Schnittstellenmanager hohes technisches

Verständnis
Projektmanager
Der Einkäufer
der Zukunft gute Vernetzung intern
Datenmanager
gute IT-Kenntnisse
Beziehungsmanager
Technologien schaffen neue Wertschöpfungsmöglichkeiten im Einkauf, sie erset-

zen aber nicht die persönliche Beziehung. Auf der einen Seite vereinfachen sie die
Kommunikation, machen sie aber oft nicht besser. Daher wird ein Fokus in der
neuen Rolle die Aufrechterhaltung und Verbesserung der für einen guten Ein-
kauf der Zukunft notwendigen persönlichen Beziehungen zu internen und exter-
nen Schnittstellen sein. Die Rolle im Einkauf wird mehr und mehr in Richtung
Management der Schnittstellen und strategische Aufgaben gehen.
Wie der Name bereits sagt, unterscheidet sich der operative vom strategischen
Einkauf darin, dass sich dieser nicht um die rein operative Bestellabwicklung,
sondern um die strategischen Ansätze zur Optimierung der Wertschöpfung
kümmert. Diese setzt sich aus Maßnahmen zusammen, die dem Unternehmen
eine nachhaltige Optimierung der Wertschöpfung bringen. Das „Go Global“
gehört ebenso in den strategischen Einkauf, wie die Optimierung der Material-
gruppen-Strategie und die Analyse des Umfelds (siehe Methoden der Analyse in
der Globalisierung, Kapitel 6).
Die Rolle des Einkäufers im Umfeld 4.0 187
Auch die von mir beschriebenen Werkzeuge gehören zu den Arbeitsmitteln des
strategischen Einkäufers, der an dieser Stelle gleichermaßen auch der Projektma-
nager ist. Je nach Größe des Unternehmens kann die Rolle des Einkäufers auch
beide Seiten beinhalten. Je nach „Hut“, den er gerade trägt, unterscheiden wir
nach operativen und strategischen Tätigkeiten.
Das oberste Ziel des strategischen Einkäufers kann mit folgenden Worten be-
schrieben werden: Er hat die Produkte des Unternehmens im Auge und stellt
sicher, dass die Position des Unternehmens schnell und flexibel der Marktsituati-
on angepasst wird.
Im Weiteren sind seine Aufgaben:
■ Die Position des eigenen Unternehmens auf dem nationalen und internationa-
len Einkaufsmarkt sichern und stärken
■ Risikomanagement betreiben
■ Bei der Umsetzung der Unternehmensziele im Einkauf mitwirken
■ Neue Märkte erkennen und für das Unternehmen verfügbar machen
■ Die Wertschöpfung verbessern
■ Die Zukunft im Auge haben
Abbildung 12.3 Prozess der Strategie-Ausrichtung
Material- Analyse
Bescha- Lieferan-
gruppen- / und Lieferan- Koninuier-
ffungs- ten-
Kennzah- Entwick- ten- liche
strategie auswahl /
lenanalyse lung des Integra- Über-
fest- Verhand-
Kenn- Lieferanten tion wachung
legen lung
zahlen Panels
12.4 Die Rolle des Einkäufers im Umfeld 4.0

Bisher ist, wie bereits erwähnt, noch nicht ganz klar, wie die Rolle in Zukunft
aussehen wird. Eine wirklich genaue Definition oder eine genaues Wissen, wie
diese aussehen soll, gibt es aber noch nicht. Dennoch gibt es eine Vorstellung,
was passieren kann, wenn die digitale Welt ihre Möglichkeiten ausschöpft.
Daher ist die neue Rolle genauso wenig im Detail beschrieben. Was wir aber
wissen, ist, dass nichts so bleiben wird, wie es bisher ist. Nichts ist so sicher, wie
der Wandel.
Den Einkäufer in Form des Bestellers wird es in Zukunft nicht mehr geben. Was
es aber geben muss, ist eine vielseitige Persönlichkeit, die sich folgenden Aufga-
ben gegenübersieht:
■ Der Einkäufer als Projektmanager.

■ Der Einkäufer wird sich stärker bereits in der Produktentstehung integrieren.
■ Der Einkäufer kümmert sich um alle Schnittstellen.
■ Der Einkäufer steht beratend zur Seite.
■ Der Einkäufer analysiert die Daten und leitet Handlungsoptionen daraus ab.
■ Der Einkäufer führt weiterhin die Verhandlungen.
■ Der Einkäufer ist Strategie-Manager.
■ Der Einkäufer ist Schnittstelle zur IT.
Fazit
 Mit dem Einkauf 4.0 geht es nicht allein um eine Digitalisierung von Ar-
beitsprozessen, sondern um eine völlig neue Arbeitswelt mit veränderten
Anforderungen an Menschen, die diese erfüllen.
 Prozesse, Inhalte, Rollen, Aufgabengebiete über die eigenen Unterneh-

mensgrenzen hinweg sind die Vision.
Mit den veränderten Aufgaben werden sich auch die Schwerpunkte verschieben.
Wir sprechen von einem Change Management im großen Umfang, welches alte
Einkäuferrollen ablöst und neue gestaltet. Es handelt sich um eine besondere
Herausforderung an eine neue Generation Einkäufer 4.0.
Was ist Führung? 189
13 Führung im Projekt
13.1 Was ist Führung?

„Ich habe gelernt,
dass Menschen vergessen, was du gesagt hast,
Menschen werden vergessen, was du getan hast,
aber Menschen werden nie vergessen,
wie du sie hast fühlen lassen.“
(Maya Angelou, geborene Marguerite Annie Johnson, 1928–2014,
US-amerikanische Autorin und Dichterin)
Worin unterscheidet sich Führung in der Linie von Führung im Projekt? Eine
Frage, die immer wieder gestellt wird. Da Projektmanagement eine Sonderorga-
nisation auf Zeit mit eigenen Rollen und Spielregeln ist, gilt es, die Führungsrolle
entsprechend zu definieren. Erst wenn die Abgrenzung zur Linienorganisation
stattgefunden hat und die Rollen definiert sind, ist die Voraussetzung für gute
Führung geschaffen.
Führung im Projekt und Führung in der Linie basieren auf zwei unterschiedli-
chen Organisationsformen. In beiden Organisationsformen werden Aufgaben
und Tätigkeiten umgesetzt.
■ In der Linie sind die Funktionen hierarchisch organisiert und basieren auf
fachlicher und disziplinarischer Führungsrolle.
■ Im Projekt wurde eine Organisationsform auf Basis der sogenannten cross-

funktionalen Teams gewählt mit dem Ziel einer schnellen Kommunikation
und Reaktionsgeschwindigkeit. Eine disziplinarische Weisungsbefugnis be-
steht oft nicht.
Die benötigten Fachfunktionen werden in einem Team zusammengefügt (siehe

Kapitel 5.2, bzw. Schritt 2 – Mind-Map). Um in der Führung erfolgreich zu sein,
bedarf es einer klaren Rollenbeschreibung. Die klare Abgrenzung der Führungs-
aufgabe des Projektleiters zur Führungsaufgabe in der Linie sollte gegeben sein.
■ Wer entscheidet wann und was im Projekt?

■ Welche Aufgabe habe ich als Projektleiter, wofür bin ich verantwortlich und
wo liegt meine Entscheidungskompetenz?
https://doi.org/10.1007/978-3-658-31310-4_13
Einer der Erfolgsfaktoren im Projekt ist erfahrungsgemäß die klare Rollenvertei-

lung im Unternehmen. Ist dies nicht geschehen, läuft man Gefahr, eine Grund-
satzdiskussion und damit ein hohes Konfliktpotenzial über den gesamten Pro-
jektverlauf zu bekommen. Diese Voraussetzung gilt es über das Management zu
schaffen und zu definieren. Als Projektleiter bin ich Führungskraft auf Zeit, ent-
sprechend der Zeitdauer des Projektes.
Er ist außerdem für die Fortschrittskontrolle zum Erlangen des Sprintziels ver-
antwortlich. Hierbei erläutert der Product-Owner im Sprint-Review, ob Product-
Backlog-Einträge die Eigenschaft Done besitzen. Auch die Entscheidung über
eine optionale frühzeitige Beendigung eines Sprints liegt im Verantwortungsbe-
reich des Product Owners.
Was macht eine Führungskraft aus, was benötigt sie?
■ die zu erledigende Aufgabe,

■ die dafür benötigten Werkzeuge,
■ die persönlichen Fähigkeiten, die als Führungskraft benötigt werden.
Als Führungskraft werden wir nicht geboren. Aber Führung kann man lernen
(Quelle: Fredmund Malik, Führen, Leisten, Leben. Wirksames Management für
eine neue Welt, 2006, S. 70/71 Aufgaben und Werkzeuge). Wenn wir an besonde-
re Führungspersönlichkeiten denken, dann ist oft der Irrglaube, dass diese allein
durch ihr charismatisches Erscheinungsbild führen. Das ist sicher ein Teil der
Führungspersönlichkeit, aber nicht alles. Ein anderer Teil beruht auf erlernbaren
Elementen, die erst in der Summe die Führungspersönlichkeit ausmachen.
Welche Elemente sind das? In erster Linie einmal die Aufgabe – der sogenannte
Fachprozess, der geführt werden muss; die Aufgabe, die es zu erledigen gilt.
Diese werden im Projektauftrag definiert. Das Magische Dreieck gibt den Rah-
men vor. Daraus leitet sich auch das Projektziel ab, welches in Teilziele (die soge-
nannten Meilensteine) heruntergebrochen wird. Die einzelnen Aktivitäten wer-
den über den Projektstrukturplan (s. Kapitel 5.4, bzw. Schritt 4) definiert und in
den Terminplan (s. Kapitel 5.5, bzw. Schritt 5) eingebunden. Als Projektleiter
wird der Fachprozess zuerst geplant und dann in der Umsetzungsphase ge-
steuert.
Wir führen als Projektleiter immer die Aufgabe, das Team und die Einzelperson –
eine große Herausforderung in der Sonderorganisation auf Zeit.
Abbildung 13.1 Führung als Projektleiter (Quelle: John Adair, Develop your
Leadership Skills, 2007, S. 23)
Anforderungen aus
der Aufgabe/dem
Fachprozess
Anforderungen der
Anforderungen aus
Einzelpersonen
der Teamsteuerung
Teamarbeit entsteht im Projekt dadurch, dass die zu erledigende Aufgabe für

einen Einzelnen zu komplex geworden ist. Daher brechen wir das komplette
Projekt in einzelne Arbeitspakete herunter, die dann wiederum steuerbar wer-
den. Wer kann schon den „Elefanten Projekt“ im Ganzen schlucken? Der Termin-
und auch der Kostenplan werden „Steuerungsinstrumente“ für den Projektleiter.
Dies wird kombiniert mit den Anforderungen aus dem Team, das ebenfalls als
Ganzes gesteuert werden möchte: das Zusammenbringen der relevanten Funkti-
onen und Persönlichkeiten, um den Elefanten, den ein Einzelner nicht stemmen
kann, gemeinschaftlich zu tragen. Das heißt aber auch, dass mir als Projektleiter
die Aufgabe zuteilwird, die Ressourcen entsprechend den Anforderungen einzu-
setzen und den Teamprozess mit vielen Schnittstellen zu steuern.
Das Team wiederum generiert sich aus Einzelpersonen, die genauso gesehen und
geführt werden möchten.
Für den Projektleiter bedeutet dies, die Aufgabe, das Team und die Einzelperso-
nen im Blick zu haben und gemeinschaftlich zum Erfolg zu führen. Erst wenn
diese Schnittstellen sauber abdeckt werden, kann ich den komplexen Herausfor-
derungen im Projekt gerecht werden.
Abbildung 13.2 Führen des Projektes

Entsprechend der Führung durch Ziele, Arbeitspakete, Meilensteine werden die

dadurch entstehenden einzelnen Aufgaben
■ klar beschrieben,
■ konkret,
■ abgegrenzt,
■ zeitlich begrenzt,
■ realistisch,
■ messbar.
1. Die Aufgabe oder das Arbeitspaket
ergeben sich im Projekt aus den Vorgaben hinsichtlich Terminen, Kosten und
Qualität. Voraussetzung ist die saubere Abstimmung mit dem Auftraggeber
über den Umfang des Projektes. WICHTIG: Habe ich den Umfang nicht ein-
deutig abgegrenzt, so kann ich dies auch nicht bei den Arbeitspaketen durch-
führen. Nur über einen klaren Auftrag kann ich die Inhalte der Arbeitspakete
bestimmen. Ist dies nicht geschehen, zieht sich das Konfliktpotenzial durch
das gesamte Projekt!
Das Magische Dreieck und die Meilensteine definieren den klaren Anfang
und das klare Ende des Projektes. Diese brechen wir auf Teilaufgaben über
Teilziele (s. Kapitel 5.3.4, bzw. Schritt 3 – Meilensteine) auf Arbeitspakete her-
unter. Die Summe der Arbeitspakete ergibt das gesamte Projekt. Die Arbeits-
pakete finden wir im Projektstrukturplan wieder und steuern diese in Bespre-
chungen und Termin- und Kostenplänen (s. Kapitel 5.5 und 5.6, bzw. Schritt 5
und 6 – Terminplanung und Kostenplanung). Erst die Kombination von
Teamführung, Individuum und Fachprozess in Summe ergeben das Ergebnis
meiner Projektführung.
2. Welche Werkzeuge benutzen wir dafür?
Um arbeiten zu können, benötigen wir Werkzeuge. Und die Anwendung der

Werkzeuge kann erlernt werden. So wie jeder Handwerksberuf können auch
die für die Führung benötigten Werkzeuge erlernt werden. Erfolg ist 95 %
Fleiß und 5 % Talent.
Beispiele, die zu den sogenannten Werkzeugen im Projekt zählen:
‒ Ziele setzen – dem Team, dem Einzelnen, mir selbst

‒ Planen – den gesamten Prozess und die Arbeitspakete
‒ Steuern – den gesamten Prozess und die Arbeitspakete
‒ Anpassen – den Prozess und die Arbeitspakete bei Abweichungen

‒ Delegieren – der Arbeitspakete an die Teammitglieder
‒ Entscheiden – am Ende des Tages und bei aller Teamarbeit entscheidet im
Sinne des Projektes der Projektleiter
‒ Besprechungen – einberufen und durchführen
‒ Feedbackgespräche führen
Abbildung 13.3 Die Führungspersönlichkeit
Was brauche ich, wie sieht die „ideale Führungskraft“ aus? Dies hat auch etwas
mit der Situation, in der ich mich befinde, zu tun. Stellen sie sich vor, zwei Piloten
würden in einem Krisenfall im Cockpit erst einmal diskutieren und alle Szenarien
durchspielen. Ich glaube, das wollen wir uns gar nicht weiter ausmalen. Hier
muss ganz klar und sofort entschieden werden. So ist das auch im Projekt. Habe
ich ein Krisenprojekt, so ist die Entscheidungskraft schneller und wichtiger, um
das Überleben im Projekt zu sichern. Befinde ich mich aber in einem Projekt,
welches klar geplant ist, so muss ich situativ immer wieder darüber nachdenken,
welches meiner Ziele nun gerade Priorität hat und wie sich dies mit den mir zur
Verfügung stehenden Menschen verwirklichen lässt.
In einem gut geplanten Projekt (z. B. Verlagerung eines Werkzeugs von A nach B)
werden die unterschiedlichen Sichtweisen in Workshops oder Arbeitssitzungen
zusammengetragen und eine Entscheidung auf Basis einer Szenarioplanung
herbeigeführt – in einem Krisenprojekt eher auf Basis einer 80/20-Variante, in der
die Zeit eine größere Rolle spielt als die Planungsgenauigkeit.
Die Komponenten Situation, Zeit und Priorität haben ebenfalls einen großen Einfluss auf
die Art der gerade notwendigen Führung!
Neben der Aufgabe und den Werkzeugen gibt es die persönlichen Fähigkeiten,
die das Führen erleichtern. Welche sind das? Nennen wir einmal einige, ohne die
Führen nur schwer möglich sein wird.
■ Selbstvertrauen – Menschen fühlen immer, ob Selbstwert gegeben ist oder

nicht. Das eigene Selbstwertgefühl zu entwickeln, hat Priorität auf dem Weg
zur Führungskraft.
■ Enthusiasmus – Eine Führungspersönlichkeit ohne Enthusiasmus ist kaum

vorstellbar: Menschen begeistern können als Teil der Führung.
■ Härte – Oft sind Führungspersönlichkeiten voller Erwartungen und daher

auch sehr fordernd: Fordern und Fördern als Basis der Führung
■ Klarheit – führt zu Vertrauen und ohne Vertrauen keine Führung. Einem

Menschen, dem wir nicht trauen, werden wir nie folgen, wenn es schwierig
wird: Klarheit als Führungsinstrument, auch in schwierigen Situationen.
■ Fairness – Wir erwarten von einer Führungskraft, dass alle gleich behandelt
werden und somit ein Gefühl der Fairness aufkommt. Im Team sind Aner-
kennung und Kritik für geleistete Arbeit gleichmäßig zu verteilen: Fairness in
der Führung.
■ Empathie – Führung benötigt Verstand, aber auch Herz. Gute Führung ohne
Empathie ist kaum vorstellbar.
■ Bescheidenheit – Das Gegenteil von Bescheidenheit ist in der Führung Arro-

ganz. Wer möchte schon für einen arroganten Projektleiter arbeiten?
All diese Fähigkeiten lassen sich entwickeln oder sind erlernbar. Aber nicht von
heute auf morgen. Viele Werte beruhen auf Erfahrung und Weiterentwicklung
unserer Persönlichkeit. Aber ist damit ist auch die Frage beantwortet, ob man
Führung lernen kann? Ja! Es ist eine Frage der Zeit.
Der österreichische Wirtschaftswissenschaftler Fredmund Malik bezieht in sei-

nem Buch „Führen, Leisten, Leben“ (Quelle: Fredmund Malik, Führen, Leisten,
Leben. Wirksames Management für eine neue Welt, 2006) bestimmte Grundsätze
mit ein, die er für Führung als wichtig erachtet. Ein gewisses Maß an Disziplin
(und Selbstdisziplin) ist erforderlich. Das Handeln nach bestimmten Grundsätzen
kann jeder lernen, man braucht jedoch die Einsicht in die Bedeutung des eigenen
Berufs und in die Risiken, die mit Fehlern verbunden sind. Auch das ist lern- und
lehrbar. Dabei ist das allgemeine Verständnis von feststehenden Grundsätzen
leichter als deren Anwendung im konkreten Einzelfall, der immer wieder variie-
ren kann. Malik definiert sechs Grundsätze wirksamer Führung:
1. Grundsatz Resultatorientierung
In Bezug auf die Projektführung heißt das, dass ein klar vereinbartes Ziel unum-
gänglich ist und damit auch dessen Verankerung im Projektantrag (Quelle: Fred-
mund Malik, Führen, Leisten, Leben. Wirksames Management für eine neue
Welt, 2006, S. 84).
2. Grundsatz Beitrag zum Ganzen
Erfolgreiche Projektleiter verstehen nicht nur, ihr eigenes Projekt im Auge zu

haben, sondern auch die Stakeholder und die Vertretung des Projektes in die
Ziele der Organisation. Kommunikation und Projektmarketing als Werkzeuge
(Quelle: Ebd. S. 98).
3. Grundsatz Konzentration auf Weniges
Wenn ich als Projektleiter versuche, alles selber zu erledigen, werde ich scheitern.
Eine der Hauptaufgaben eines Projektleiters ist es, zu wissen, welche Kennzahlen
meinen Projektprozess steuern, und über diese das Projekt zu führen. Es ist kaum
möglich, alle Projektdetails und Arbeitspakete selbst zu führen. Das setzt aber
auch voraus, dass ich das Werkzeug Delegation beherrsche (Quelle: Ebd. S. 110).
4. Grundsatz Stärken nutzen
Als Projektleiter kenne ich meine eigenen Stärken und Schwächen. Bevor ich
andere führe, muss ich erst einmal mich selber kennen und einschätzen können.
Erst dann bin ich in der Lage, auch als Führungskraft für andere einen guten Job
zu machen. Die Stärke im Team und das Erfolgsrezept im Projekt ist das zielori-
entierte Zusammenführen der einzelnen Fähigkeiten der jeweiligen Teammit-
glieder. Das Mind-Map ist der erste Schritt, um die fachlichen Kompetenzen
zusammenzubringen. Die einzelnen Stärken sind die Grundvoraussetzung für
den erfolgreichen Projektprozess (Quelle: Ebd. S. 122).
5. Grundsatz Vertrauen
Ohne Vertrauen keine Führung. Vertrauen ist die Basis des menschlichen Mitei-
nanders. Aber wodurch entsteht Vertrauen und wie äußert es sich? Wenn wir das
tun, was wir sagen, geben wir Sicherheit. Umgekehrt können wir natürlich auch
die Frage stellen, was wir tunlichst unterlassen sollten, damit wir Vertrauen nicht
zerstören (Quelle: Ebd. S. 140).
„Vertrauen braucht Jahre, um es aufzubauen und Sekunden, um es zu vernichten!“
Unzuverlässigkeit, nicht eingehaltene Absprachen, kleine und große Lügen – dies

sind nur einige Beispiele, wie Vertrauen mit wenig Aufwand gebrochen werden
kann. Was also braucht es, damit ich als Führungskraft vertrauensvoll bin?
Klarheit: Reden wir nicht nur über „nett sein“. Reden wir ebenso über Klarheit,
auch wenn die Wahrheit für mein Gegenüber nicht angenehm sein mag: die Ver-
zögerung des Projektes und dessen Auswirkung auf Arbeitspakete, um nur ein
kleines Beispiel zu nennen.
In meinen Seminaren sprechen wir immer wieder darüber, was wir als Teammit-
glieder von unserem Projektleiter erwarten. Gern möchte ich dieses hier wieder-
geben. Als „gute Führung“ im Projekt sind folgende Fähigkeiten gewünscht oder
notwendig und werden immer wieder aus Sicht des Teams genannt:
‒ Klare Zielvorgaben – ausgedrückt durch Meilensteine (S.M.A.R.T-Prin-

zip), regelmäßiger Austausch darüber.
‒ Kommunikation – klar, umfassend, rechtzeitig, an alle Beteiligten – Kom-
munikationsplan sollte vorhanden sein.
‒ Motivation – die Teammitglieder integrieren und mitnehmen (Informatio-
nen, die von Schnittstellen außerhalb des Kernteams kommen, zielgerich-
tet weitergeben).
‒ Wertschätzung – ausgedrückt in respektvollem Umgang, klarer Kommu-
nikation und Feedback.
‒ Verantwortung teilen – bei der Delegation von Arbeitspaketen die Ent-
scheidung auch bei dem jeweiligen Teammitglied des Fachbereichs lassen.
Feedback und Abstimmung im weiteren Arbeitsverlauf.
‒ Durchsetzungsfähigkeit – das Projekt hinsichtlich Auftraggeber, Len-
kungsausschuss und Lieferanten vertreten.
‒ Konfliktfähigkeit – auch mal einen Konflikt aushalten und lösen. Nicht
weglaufen oder ignorieren.
‒ Kooperation mit dem Team und nicht nur autoritär sein.
‒ Klare Arbeitspaketverteilung.
6. Grundsatz positives Denken
Challenge accepted! Die Projektherausforderungen werden angenommen.
Es geht nicht darum, die Welt schönzureden, aber eine negative Einstellung zum
Projekt ist absolut kontraproduktiv. Vorbild sein und konstruktiv mit dem Team
die Aufgaben angehen (Quelle: Ebd. S. 157).
Die genannten Fähigkeiten haben Allgemeingültigkeit und sind als Bedürfnis der
Teammitglieder zu sehen, um motiviert und engagiert die Arbeitspakete abwi-
ckeln zu können.
Checkliste Führung im Projektteam aus Sicht des Projektleiters:
■ Ist eine Stakeholderanalyse notwendig?

■ Habe ich die Teammitglieder frühzeitig zusammengebracht?
■ Nutze ich das Kick-off bereits als Teambuilding?
■ Habe ich eine Verantwortlichkeitsmatrix?
■ Sind die Rollen und Verantwortlichkeiten klar definiert?
■ Sind die Arbeitspakete klar definiert (Kapitel 5.4, bzw. Schritt 4 – Projekt-
strukturplan)?
■ Ist der Terminplan abgestimmt und freigegeben?

■ Sind die Kosten und das Budget frei und geplant?
■ Werden die Risiken gesteuert?
■ Ist die Balance zwischen einem zu starken Controlling und genügend Frei-
raum für die Teammitglieder aus meiner Sicht gegeben?
■ Sind die Besprechungen, für die ich verantwortlich bin, gut vorbereitet und
stringent geführt?
■ Habe ich eine klare Kommunikationsstruktur und kann Informationen ziel-

orientiert weitergeben?
■ Habe ich für mein Projekt gute Steuerinstrumente, die es mir ermöglichen,
schnell und zielorientiert zu reagieren (z. B. Meilensteintrendanalyse, Kosten-
trendanalyse ...)?
■ Habe ich guten und regelmäßigen Kontakt zu Auftraggeber und Steuergremi-

en und kann damit schnell Entscheidungen herbeiführen?
■ Was tue ich, damit sich das Team auch als Gemeinschaft wahrnimmt?
■ Delegiere ich im notwendigen Umfang und gebe entsprechend Feedback?
■ Besteht ein Eskalationsprozess?
Delegieren, aber richtig
Im Allgemeinen bedeutet Delegieren, eine Aufgabe oder eine Verantwortlichkeit an

eine andere Person weiterzugeben. Was so einfach klingt, birgt ein paar Herausfor-
derungen. Jedoch ist wirksame Projektarbeit ohne Delegation nicht möglich.
Wir unterscheiden zwei Arten der Delegation:
■ Delegation einer Aufgabe

■ Delegation einer Autorität bzw. von Verantwortung
Um in der Teamarbeit das notwendige Vertrauen zu entwickeln, ist beides not-
wendig. Über den Projektstrukturplan werden die einzelnen Aufgaben zur Ziel-
erreichung definiert und den einzelnen Teammitgliedern zugeordnet. Die meis-
ten Verantwortlichkeiten ergeben sich durch die definierte Funktion. Anstelle
von ungeklärten Verantwortlichkeiten gilt es, diese frühzeitig festzulegen!
Wie aber funktioniert Delegation?
1. Schritt: WAS genau möchte ich übergeben?
■ ausreichende Informationen über die Aufgabe und alles, was für ihre Erledi-
gung wichtig ist,
■ hier ist auch genügend Information über Sinn und Ziel mit zu erläutern.
■ klare Anweisungen in Bezug auf das, was erwartet wird, dabei aber ausrei-
chend Handlungsspielraum. Der oder die Person, die die Aufgabe entgegen-
nimmt, muss auch über den Handlungsspielraum informiert sein. Dies gilt
auch umgekehrt bei der Übernahme einer Projektleitung. Wenn die Rolle gut
ausgefüllt werden soll, dann muss jeweils klar sein, was die Aufgabe ist, was
meine Verantwortung ist und in welchem Bereich ich Entscheidungen treffen
darf (Kompetenz).
■ Informationen zu Sinn und Ziel der Aufgabe, denn nur wer weiß, was das
Ziel ist, kann es auch erreichen.
2. Schritt: Unterstützen bei der Umsetzung
Die Aufgabe zu übergeben und erst bei Terminende abzuholen, ist keine Dele-
gation.
■ Gemeinschaftlich werden Teilziele definiert, die zu bestimmten Terminen

besprochen werden.
■ Sollte es Schwierigkeiten geben, gilt es, das Teammitglied entsprechend zu

unterstützen.
3. Schritt : Rückmeldung über das Arbeitspaket und die Zusammenarbeit bei

Abgabe
■ Ein Lob hat noch niemandem geschadet.

■ Bei Abgabe der Aufgabe ist ein Feedback über die Themen, die gut gelaufen
sind, und auch über die Themen, die Verbesserungspotenzial haben, ein guter
Abschluss der delegierten Aufgabe.
Abbildung 13.4 Delegieren
Fazit
 Das Ziel ist klar zu definieren, dabei die Rahmenbedingungen und Be-
schreibung der zu übergebenden Aufgabe nicht vergessen!
 Während der Umsetzung der Aufgabe ist es wichtig, immer wieder den
Status zu besprechen und als Coach zur Verfügung zu stehen. Oft ändern
sich Einflussgrößen. So viel Kontakt zur umsetzenden Person wie nötig.
 Teilziele und weitere Abstimmungstermine sollten im ersten Schritt bespro-

chen und gemeinsam festgelegt werden.
 Delegieren heißt auch unterstützen und nicht nur übergeben!

Kick-off als Instrument 201
13.2 Kick-off als Instrument

Über das Kick-off wird viel gesprochen. Aber was genau machen wir mit und in
diesem Termin? Warum ist dieses Treffen so wichtig?
Als Kick-off bezeichnen wir die erste offizielle Auftaktveranstaltung eines Projek-
tes. Das Kick-off sollte Bestandteil eines jeden neu gestarteten Projektes sein.
Symbolisch zeigt es allen Projektbeteiligten den Übergang von der Linie in das
Projekt und damit den Beginn der Umsetzung der Aufgabe in der Sonderorgani-
sation.
Natürlich kann der Ablauf eines Kick-offs unterschiedlich sein. Je nach Projekt-
größe und Teilnehmerzahl reicht die Bandbreite von einer reinen Informations-
veranstaltung (großes Projekt, viele Teilnehmer) bis hin zu einem Treffen, in dem
gemeinsam die ersten Planungsergebnisse (bei bis zu ca. 20 Teilnehmern mög-
lich) erarbeitet werden.
In Teamarbeit kann im Kick-off bei kleineren Teams bereits am Basisplan gearbei-

tet werden. Das heißt, es wird gemeinsam über erste Meilensteine, Projektstruk-
turplan, mögliche Arbeitspakete oder auch die Abstimmung von Terminen ge-
sprochen. Das gemeinsame Treffen kann als Teambuilding oder aber auch zur
Erarbeitung von ersten Ergebnissen genutzt werden.
Auch in einem Einkaufsprojekt unterstreiche ich mit dem Kick-off nochmals die
Zugehörigkeit zu meiner Projektstruktur.
Als Projektleiter ist es wichtig, das Kick-off gut vorzubereiten und umzusetzen.
Es spiegelt den Charakter des kommenden Projektes wider. Im Folgenden ist eine
Checkliste zusammengestellt, die als Gedankenstütze für die Vorbereitung und
die Umsetzung dient.
Was genau möchte ich erreichen?
13.2.1 Checkliste möglicher Inhalte und Ziele des

Kick-offs
■ Warum wird das Projekt überhaupt durchgeführt?
‒ Was ist die Motivation?
‒ Was ist der erwartete Nutzen?
■ Vermittlung des Projektziels an alle Beteiligten

‒ Was soll mit und in diesem Projekt erreicht werden?
‒ Welche Teilziele und Meilensteine liegen bereits vor?
‒ Welches ist der Endtermin?
■ Rahmenbedingungen und Wichtigkeit des Projektes verdeutlichen

■ Nutzen des Projektes für das Unternehmen und den Einkauf
■ Teamzusammensetzung und Rollen
‒ Wer ist am Projekt beteiligt?
‒ Sind die Stakeholder schon definiert?
■ Erwartungen an die Zusammenarbeit

‒ Welches sind unsere Werte im Team?
‒ Wie wollen wir miteinander umgehen?
■ Kennenlernen der Teammitglieder, falls dies vorher noch nicht bekannt war
‒ Das „Who is Who“ im Projekt
■ Wie wollen wir unsere Arbeit organisieren?

‒ Wie und wann laufen die Besprechungen?
‒ Wer informiert wann und wie?
‒ Welche Medien für welche Besprechung (vis-à-vis, Video, Telefonkonferenz)
Der Projektleiter ist „Gastgeber“ des Kick-offs. Das Kick-off kann sowohl eine
reine Informationsveranstaltung als auch eine Informations- und Arbeitssitzung
in Kombination sein!
13.2.2 Checkliste zur Vorbereitung eines Kick-offs

Aufgaben als Projektleiter:
■ Habe ich alle Beteiligten identifiziert?

‒ Möchte ich auch Stakeholder einladen?
‒ Wer außer dem Kernteam ist noch beteiligt?
■ Habe ich den Zeitpunkt festgelegt?

‒ Habe ich Urlaubs- und Feiertage für das Kick-off mit betrachtet?
‒ Was ist ein idealer Zeitpunkt?
‒ Sind Ort und Raum geklärt?
Motivation 203
‒ Ist das notwendige Equipment geklärt?

‒ Ist das Catering geklärt?
■ Ablauf und Einladung

‒ Ist der Ablauf festgelegt?
‒ Wurden die Einladungen früh genug versandt?
‒ Habe ich die Zusagen für Anwesenheit mit angefragt?
‒ Habe ich kritische Themen mit einzelnen Beteiligten im Vorfeld bespro-
chen?
‒ Liegen mir alle notwendigen Unterlagen vor, um den Termin optimal
durchführen zu können?
‒ Wie und wer dokumentiert den Termin?
‒ Habe ich mir die nächsten Schritte nach dem Kick-off bereits überlegt, so
dass ich dies den Teilnehmern weitergeben kann?
■ Sind die notwendigen Rollen im Projekt mit den Verantwortlichen abge-

stimmt?
‒ Wer ist an der Umsetzung direkt beteiligt?

‒ Wen benötige ich als Unterstützer?
■ Kann ich dies so mit dem Team besprechen?

■ Wie möchte ich mit Punkten umgehen, die ich nicht im Kick-off klären kann
(Offene-Punkte-Liste)?
13.3 Motivation
Wenn wir über das Thema Führung reden, dann sind Motivation, Kommunikati-
on und Feedback dazugehörige Werkzeuge. Was aber ist Motivation?
Als Motivation bezeichnen wir den menschlichen Antrieb, aus sich heraus das
Beste leisten zu wollen. Diese Art des Antriebs kann gebremst oder auch unter-
stützt werden. Basierend auf einer für uns positiven Empfindung, generieren wir
ein Handlungsmotiv („Ich fühle mich wohl/Ich fühle mich nicht wohl!“). Wird
eine Emotion mit einer Zielorientierung verknüpft, so sprechen wir von einem
Motiv. Motivation ist dementsprechend ein Prozess, der zu einer positiven Hand-
lungsbereitschaft führt.
Einige Psychologen haben sich darüber Gedanken gemacht. Abraham Maslow

(1908–1970) sei von diesen genannt, denn, wenn auch etwas angestaubt, so ist
seine Motivationspyramide doch ein hilfreiches Werkzeug, um sich der Bedeu-

tung von Motivationsfaktoren im Projektumfeld bewusst zu werden.
Abbildung 13.5 Maslows Pyramide (Quelle: C. George Boeree. Shippensburg

University, USA. Abraham Maslow, Personality Theories,
1998, S. 4)
Die Theorie von Maslow besagt, dass eine Motivation auf der nächsthöheren
Stufe nur dann möglich ist, wenn die Stufen darunter befriedigt sind. Entspre-
chend der Theorie von Maslow, kann ich einen Menschen, der Hunger hat, nicht
durch die Option der Selbstverwirklichung motivieren!
1. Physiologische Bedürfnisse
Essen, Schlafen, Trinken. Die Grundbedürfnisse von uns Menschen können durch
die Arbeit und das Gehalt befriedigt werden und sind damit als Motivatoren
bereits erfüllt.
Motivation 205
2. Das Bedürfnis nach Sicherheit und Schutz
Kann durch einen sicheren Arbeitsplatz befriedigt werden: Der Mitarbeiter

braucht keine Angst vor Arbeitsplatzverlust zu haben und kann sich dann ganz
der Tätigkeit widmen. Dieser Motivator kann durch das Projekt kaum verbessert
werden, da dies bereits durch das Arbeitsverhältnis abgedeckt wird.
3. Das Bedürfnis nach Zugehörigkeit und Kontakt
Hier kann ich als Projektleiter etwas tun. Zugehörigkeit zum Projekt, zum Team
und das Gefühl der Gemeinsamkeit fördern die Motivation meiner Teammitglie-
der. Das Arbeiten im Team bereichert die Tätigkeit der Mitarbeiter um vielfältige
soziale Kontakte.
4. Das Bedürfnis nach Anerkennung und Wertschätzung
Kann durch direktes und aufrichtiges Lob des Projektleiters und durch einen
erweiterten Handlungs- und Entscheidungsspielraum für Teammitglieder befrie-
digt werden. Innerhalb von Projekten gibt es Auszeichnungen und Gratifikatio-
nen für herausragende Leistungen.
5. Das Bedürfnis nach Selbstverwirklichung
Im Projekt kann sich der einzelne Mitarbeiter entwickeln, indem herausfordernde

Tätigkeiten und eigenverantwortliches Handeln möglich sind, und damit konti-
nuierlich seine Fähigkeiten und Fertigkeiten erweitern. Diese Herausforderungen
im Projekt führen zu einem steigenden Qualifikationsniveau, das sich langfristig
in beruflichem Aufstieg niederschlagen kann.
Die ersten vier Bedürfnisse nennt Maslow auch „Defizitbedürfnisse“, da bei

Nichtbefriedigung ungünstige Folgen zu erwarten sind (z. B. Unzufriedenheit,
Krankheit) und ein Gefühl der Entbehrung hervorgerufen werden kann.
Wie bereits beschrieben, stehen die Bedürfnisse untereinander in einer Form der
Abhängigkeit. Erst wenn ein Bedürfnis erfüllt ist, kann das nächsthöhere als
Motivator fungieren. Je höher das Bedürfnis, desto weniger wichtig ist es für das
reine Überleben, denn es kann leichter aufgeschoben werden, es wird als weniger
drängend erlebt und kann auch ganz verschwinden. Ein Individuum, dessen
Verhalten durch höhere Bedürfnisse bestimmt ist (das setzt voraus, dass alle
grundlegenderen Bedürfnisse befriedigt sind), ist seltener krank, schläft besser
und lebt länger. Befriedigung höherer Bedürfnisse führt weg von psychopatholo-
gischen Erscheinungen (psychischen Krankheiten) und ist damit ein wichtiger
Schutzfaktor für Gesundheit. Höhere Bedürfnisse werden sozial höher bewertet.
Das Befolgen und die Befriedigung höherer Bedürfnisse haben positive soziale
Konsequenzen (Loyalität, Freundlichkeit ...).
Für mein Projekt bedeutet das: Nur wenn meine Teammitglieder auch eine ange-
nehme Arbeitsumgebung haben, kann ich die volle Leistung im Team erwarten.
Aus den Workshops und Seminaren wurden immer wieder bestimmte Punkte
genannt, die von Teammitgliedern als motivierend bezeichnet wurden. Daraus
hat sich eine kleine Checkliste entwickelt, die für mich als Projektleiter eine Ge-
dankenstütze darstellen soll.
Checkliste Motivation
 Das „Wir-Gefühl“ im Team

— Sind die Ziele kommuniziert und abgestimmt und werden von allen
Teammitgliedern getragen?
— Gibt es Teamevents, in denen auch Erfolge gefeiert werden?
— Stimmen wir uns gemeinsam ab?
— Ist deutlich, wer welche Verantwortung im Rahmen der Projektorgani-
sation hat?
 Vertrauen zeigen
— Gebe ich dem Teammitglied genügend Freiraum, aber auch Unterstüt-

zung bei der Umsetzung?
— Ist für das Team deutlich, auf welcher Basis Entscheidungen getroffen
werden?
— Gebe ich meinen Teammitgliedern nach außen Rückendeckung?
— Stehe ich hinter ihren Entscheidungen?
 Respekt und Wertschätzung auch leben
— Gebe ich genügend Feedback?

— Lobe ich auch bei guten Arbeitserfolgen?
— Kommuniziere ich auf Augenhöhe?
— Respektiere ich den fachlichen Input meiner Teammitglieder?
— Bin ich im Umgang mit Konflikten auf der Sachebene und nicht auf der
menschlichen Ebene?
— Lebe ich die Vorbildfunktion?
— Beziehe ich kulturelle Unterschiede mit ein?
Motivation 207
 Verantwortung übertragen
— Sind die Arbeitspakete sauber delegiert?

— Ist genügend Freiraum für die Umsetzung der Arbeitspakete vor-
handen?
— Überlasse ich die Entscheidungen weitestgehend dem Teammitglied
oder mische ich mich ständig in fachliche Themen ein?
— Unterstütze ich im Rahmen der Projektleiterfunktion bei der weiteren
Entwicklung und Umsetzung?
— Gebe ich Ziele im Rahmen des Gesamtprojektziels klar weiter?
 Kommunikation
— Gebe ich die notwendigen Informationen weiter?

— Informiere ich aus Schnittstellen und anderen Gremien?
— Kann ich auch in schwierigen Situationen klar kommunizieren?
— Bin ich in der Lage, Entscheidungen zu treffen, auch wenn diese gerade
nicht „modern“ sind?
— Habe ich eine sinnvolle Besprechungskultur aufgebaut (Zeit, Dauer,
Teilnehmer, Vorbereitung, Dokumentation)?
 Erreichbarkeit des Projektleiters
— Bin ich für meine Teammitglieder erreichbar?

— Bin ich transparent in der Steuerung des Projektes?
Der Projektleiter und die menschliche Seite 209
14 Was macht Teamarbeit

erfolgreich?
Meist arbeiten wir nicht allein, sondern fast alle Aufgaben lassen sich nur unter
Zusammenführung unterschiedlichen Know-hows abbilden – vor allem die gro-
ßen, sehr komplexen Aufgaben, die wir als Projekte bezeichnen.
Wenn einzelne Personen zusammenkommen, sprechen wir gern von Teams.

Aber reicht das wirklich schon aus? Was genau kennzeichnet ein Team?
In erster Linie sind die Rollen im Team klar definiert und innerhalb des Teams
gibt es bis auf den Projektleiter keine hierarchische Abstufung. Die Teammitglie-
der (Funktionen) wurden entsprechend des benötigten Expertenwissens zusam-
mengestellt.
14.1 Der Projektleiter und die

menschliche Seite
„Der beste Führer ist der, dessen Existenz gar nicht bemerkt wird, der zweitbeste der,
welcher geehrt und gepriesen wird, der nächstbeste der, den man fürchtet, und der
schlechteste der, den man hasst. Wenn die Arbeit des besten Führers getan ist, sagen die
Leute: ‚Das haben wir selbst getan.’“
(Lao-Tse, ca. 700 v. Chr., chinesischer Philosoph)
Um ein Projekt erfolgreich zu führen, ist neben einem Anspruch an das Fachver-
ständnis auch ein hohes Maß an sozialer Kompetenz notwendig. Was zeichnet
einen Leader für ein Projekt aus? Ohne bestimmte Kompetenzen oder Skills kann
Führung nicht funktionieren.
Oft werden die Anforderungen untergliedert in die notwendige:
■ Fachkompetenz = „Sachkompetenz, Fachkenntnis, Fachkunde, Sachkunde,

Fachwissen, Hardskill versteht man die Fähigkeit, berufstypische Aufgaben
und Sachverhalte den theoretischen Anforderungen gemäß selbstständig und
eigenverantwortlich zu bewältigen. Die hierzu erforderlichen Fertigkeiten
und Kenntnisse bestehen hauptsächlich aus Erfahrung, Verständnis fachspe-
zifischer Fragen und Zusammenhänge sowie der Fähigkeit, diese Probleme
https://doi.org/10.1007/978-3-658-31310-4_14
210 Was macht Teamarbeit erfolgreich?
technisch einwandfrei und zielgerecht zu lösen. Voraussetzung ist in der Re-

gel eine entsprechende Ausbildung.“
(Quelle: https://de.wikipedia.org/wiki/Fachkompetenz, Zugriff am 03.09.2016)
■ Methodenkompetenz = „die Fähigkeit und Fertigkeiten, Fachwissen zu be-

schaffen und zu verwerten und allgemein mit Problemen umzugehen. Me-
thodenkompetenz ist mit dafür verantwortlich, Fachkompetenz aufzubauen
und erfolgreich zu nutzen, ist also auch Kompetenz, die Kompetenz(en) er-
schließt: eine Schlüsselqualifikation bzw. -kompetenz. Im Einzelnen wird da-
runter verstanden, z. B.:
‒ die Fertigkeit, Informationen zu beschaffen, zu strukturieren, zu bearbei-

ten, aufzubewahren und wieder zu verwenden, darzustellen, Ergebnisse
von Verarbeitungsprozessen richtig zu interpretieren und in geeigneter
Form zu präsentieren.
‒ die Fertigkeit zur Anwendung von Problemlösungstechniken.
‒ die Fertigkeit zur Gestaltung von Problemlösungsprozessen.“
(Quelle: https://de.wikipedia.org/wiki/Methodenkompetenz, Zugriff am
03.09.2016)
■ Soziale Kompetenz = „(engl. social skills) ist die Gesamtheit individueller

Einstellungen und Fähigkeiten, die im Sinne der Kooperation nützlich sind,
eigene Handlungsziele mit den Einstellungen und Werten einer Gruppe zu
verknüpfen und so auch beim Verhalten und der Einstellungen dieser Gruppe
mitzuwirken. Soziale Kompetenz umfasst eine Vielzahl von Fertigkeiten, die
für die soziale Interaktion nützlich bzw. notwendig sind. Ein zuweilen mit ihr
gleichgesetzter Teilaspekt der sozialen Kompetenz ist dabei die sogenannte
soziale Intelligenz als ‚Fähigkeit, andere zu verstehen sowie sich ihnen ge-
genüber situationsangemessen und klug zu verhalten‘.“ (Quelle: https://de.
wikipedia.org/wiki/Soziale_Kompetenz, Zugriff am 03.09.2016)
Die Anforderungen an den Projektleiter sind vielfältig. Ohne folgende Fähigkei-

ten ist eine erfolgreiche Führung eines Teams schwierig.
Der Projektleiter und die menschliche Seite 211
Abbildung 14.1 Geforderte Fähigkeiten des Projektleiters
Es gibt eine besondere Beziehung zwischen Auftraggeber und Auftragnehmer.

Dieses Verhältnis ist eine der Schlüsselrollen für den Erfolg oder Misserfolg eines
Projektes. Es beginnt mit der Auftragsklärung und bleibt eine „Beziehung auf
Lebenszeit“, zumindest der Projektlebenszeit. Von der Kommunikation, dem
Verständnis und der Klarheit des Auftrags hängt das weitere Vorgehen ab. Daher
ist es wichtig, ein paar Fragen mit „Ja“ beantworten zu können.
■ Ist der Projektauftrag zwischen Projektleiter und Auftraggeber geklärt und

schriftlich dokumentiert (siehe Projektantrag)?
■ Ist der Auftraggeber kommunikativ in das Projektgeschehen eingebunden?

■ Trifft der Auftraggeber seine Entscheidungen entsprechend dem Projektbedarf?

■ Erhält der Projektleiter die volle Unterstützung des Auftraggebers, auch bei
Problemen und Krisen?
14.2 Teamentwicklungsphasen nach

Tuckman
Sind die Rollen geklärt und die Einzelpersonen treffen sich, um ein Team zu gestal-
ten, dann nehmen die Teamentwicklungsphasen (nach dem US-amerikanischen
Psychologen und Organisationsberater Bruce Wayne Tuckman, * 1938) Gestalt an.
Abbildung 14.2 Teamentwicklungsphasen nach Bruce W. Tuckmann

Teamentwicklungsphasen nach Tuckman 213
Tuckmann definierte 1965 vier Teamphasen (Quelle: Bruce Wayne Tuckman,

Developmental sequences in small groups, 1965) und ergänzte diese 1977 um eine
fünfte (Quelle: Bruce Wayne Tuckman, Mary Ann C. Jensen, Stages of small
group development revisited, 1977). Er differenzierte bei den ersten vier Phasen
zwischen dem zwischenmenschlichen Verhalten der Teammitglieder und der
Entwicklung des Arbeits- bzw. Projektauftrags. Aus Projektsicht ist in den jewei-
ligen Phasen das Führungsverhalten des Projektleiters entsprechend zu gestalten,
um die Mitarbeiter schnellstmöglich auch zu einem Team zu führen.
1. Forming-Phase
a. Verhalten der Teammitglieder

In der „Orientierungsphase“ geht es darum, sich zu begegnen. Die Mit-
glieder lernen sich kennen und streben nach Sicherheit. Die Teamstruktur
ist von Unsicherheit geprägt, da alles noch neu ist. Jedes Teammitglied
versucht, seine Position im Team zu finden sowie herauszufinden, wel-
ches Verhalten in der Situation akzeptiert wird.
b. Abstimmung des Projektauftrags
Die Teammitglieder versuchen den Projektauftrag, in Bezug zu ihrer Rolle
zu klären. Welche Informationen benötigen sie, um den Projektauftrag
und oder die definierten Arbeitspakete auszu-führen?
c. Führung in dieser Phase
Der Projektleiter gibt in dieser Phase durch Ziele, Informationen zum
Projekt und Projektauftrag dem Team Sicherheit. Raum für das gegen-
seitige Kennenlernen ist in dieser Phase wichtig. Austausch, gut struktu-
rierte Besprechungen mit klarer Agenda, frühzeitiger Einladung sowie
einem klaren Ziel sind in dieser Phase Methoden, um das Team aufzu-
setzen.
Wichtig in dieser Phase:
 Raum für das Kennenlernen

 Ziel und Projektauftrag vorstellen und abstimmen
 gemeinsame Entwicklung bzw. gemeinsames Abstimmen des weiteren
Vorgehens und des Basisplans
 Treffen von Vereinbarungen für die gemeinsame Teamarbeit
 Kick-off als Werkzeug für den Projektstart und den guten Teamstart
 alle Teammitglieder treffen sich, wenn möglich, persönlich
2. Storming-Phase

Es ist die Phase, in der jedes einzelne Teammitglied versucht, seinen Be-
reich abzustecken. Ziele werden klarer, Machtkämpfe entstehen.
Individuelle Ziele können mit Projektzielen kollidieren. Es kommt oft zu
Konflikten und Unstimmigkeiten im Team. Die Zeiten, in denen „nett
sein“ im Vordergrund steht, sind vorbei.
Es ist wichtig, in dieser Phase sachlich und zielorientiert zu bleiben. Es ist
wichtig, Platz für die Konfliktlösung zu geben, aber nicht den Raum, sich
darin zu „baden“. Als Projektleiter Vorbild zu sein und klare Grenzen zu
setzen, ist in dieser Phase wichtig, um schnellstmöglich in eine Perfor-
manz-Phase überzugehen.
 als Projektleiter auf Fachorientierung achten

 Vorbild sein und bleiben
 Unterstützen bei der Konfliktlösung
 darauf achten, dass der gegenseitige Respekt erhalten bleibt
 Unterschiedliche Meinungen dürfen nicht dazu führen, dass ein anderes
Teammitglied als Mensch in Frage gestellt wird (Ich bin ok – Du bist ok!).
 Die Phase Storming sollte möglichst schnell in die Phase des Normings
übergehen.
3. Norming-Phase
In dieser Phase finden sich die einzelnen Personen als Team zusammen. Der
Rahmen für die Zusammenarbeit wurde gestaltet. Das Team kennt sich und das
„Gerangel“ um Hierarchie im Team ist beendet. Zusammenarbeit steht im Vor-
dergrund. Die Eigenarten der anderen Teammitglieder werden als gegeben hin-
genommen.

Das Team beginnt, sich gegenseitig mit Stärken und Schwächen der Ein-
zelnen zu akzeptieren. Die Stimmung im Team hat etwas von Erleichte-
rung, aber auch von Ernüchterung.
Das Team wird in dieser Phase arbeitsfähig. Der Projektauftrag wird um-
gesetzt. Das Team erkennt die gemeinsame Stärke und beginnt, die Team-
ziele in den Vordergrund zu setzen.
Teamentwicklungsphasen nach Tuckman 215

Das Magische Dreieck hinsichtlich Terminen, Kosten und Qualität wieder
in den Vordergrund bringen. „Wir“ kennen uns gegenseitig, daher ist es
einfacher, die Arbeitspakete zu delegieren und entsprechend weiterzu-
reichen. Das regelmäßige Teammeeting dient der Umsetzung. Der Infor-
mationsfluss und die Umsetzung nehmen Beschleunigung auf. Feedback
geben und nehmen ist Bestandteil der Werkzeuge während der gesamten
Projektzeit.
 Verbindlichkeit im Team erzeugen

 Regeln nochmals fixieren
 das WIR stärken
 Zielorientierung und Geschwindigkeit aufnehmen
4. Performing-Phase
Ziel eines jeden Teams ist es, in die Performing-Phase (Hochleistungsphase) zu

gelangen. Jetzt ist das Team leistungsfähig und arbeitet effizient und eigenstän-
dig. Das Team akzeptiert sich gegenseitig. Gegenseitiges Vertrauen ist die Basis
für die Zusammenarbeit.

Das Team unterstützt sich gegenseitig. Vertrauen und Wertschätzung sind
die Basis für die erfolgreiche Zusammenarbeit. Entscheidungen werden
vereinbart und eingehalten. Austausch von Informationen und Meinun-
gen findet statt.
Zielorientierung und Abarbeitung der Aufgaben stehen im Vordergrund.
Die Rolle der Projektleitung tritt in den Hintergrund. Das Team ist in der
Lage, die anstehenden Probleme selbst zu lösen. Die Projektleitung kann
sich darauf konzentrieren, den Überblick zu bewahren, bzw. das große
Ganze nicht aus den Augen zu verlieren.
 Der Erfolg des Teams steht im Vordergrund und wird gefeiert.

 Das Team als solches ist eine Einheit und motiviert.
 Das Team ist weitestgehend eigenorganisiert.
5. Adjourning-Phase
Diese Phase wurde von Tuckman erst in den 1970er-Jahren hinzugefügt, gemeinsam
mit Mary Ann C. Jensen. Sind Teams sehr lange in der Performing-Phase gewesen, so
ist es schwer, das Gefühl von Gemeinsamkeit wieder aufzugeben. Es stellt sich ein
bisschen das Gefühl wie am Ende einer Beziehung ein. In dieser Phase dürfen Erfolge
nochmals gefeiert werden. Es findet ein Rückblick statt. Was war gut, was würden
wir anders machen? Das Team wird offiziell aus dem Projekt entbunden.
14.3 Die Präsentation und was dazu gehört

Das Präsentieren und Verkaufen des Projektes ist ein wichtiger Bestandteil in der
Projektarbeit. Ob Projektleiter oder Teammitglieder, ob vor dem Steuerkreis oder
vor dem Kunden: Immer wieder ist es wichtig, das Arbeitspaket, den Projektsta-
tus oder auch Änderungen und Anpassungen vorzustellen.
Ckeckliste Präsentation
Tabelle 14.1 Präsentation – Checkliste möglicher Punkte
Zielgruppe
Warum brauchen wir diese Präsentation?
Kenne ich die Erwartungen der Zuhörer?
Welche Einstellung hat die Zielgruppe oder

der Einzelne?
Sind vorab Gespräche notwendig?
Wo muss die Zielgruppe abgeholt werden?

Stichwort Einführung
Was ist die Erwartungshaltung der Zuhörer?

Weiß ich, ab wann die Präsentation als
erfolgreich angesehen wird?
Die Präsentation und was dazu gehört 217
Ablauf
Ist die Agenda verteilt?
Gibt es Rückmeldungen zur Agenda, die

berücksichtigt werden müssen?
Wer präsentiert aus dem Team was?
Wie ist der Ablauf, wenn mehrere Personen

präsentieren?
Welche Medien werden genutzt?
Wollen wir Flipcharts nutzen?
Sind Handouts notwendig?
Müssen Unterlagen vorab versandt werden?
Raum für Fragen geben.
Dank und Verabschiedung bereitstellen.
Örtlichkeit
Ist die Raumgröße entsprechend den Anfor-

derungen?
Wie soll die Bestuhlung sein?
Funktionieren die Medien: Beamer, Video ...?
Werden Getränke benötigt?
Habe ich den Raumschlüssel?
Sind die Flipcharts und Pinnwände vor-

handen?
Ist der Moderationskoffer vorhanden?

Herausforderung im internationalen Umfeld 219
15 Projektherausforderung im
internationalen Umfeld —
Why culture counts
Viele Einkaufsprojekte laufen im internationalen Umfeld ab. Was aber bedeutet
das für unsere Projekte? Warum bedeutet dies wiederum eine ganz neue Heraus-
forderung?
Internationale Projekte und multinationale Teams stellen eine besondere Heraus-

forderung für alle Beteiligten dar. Neben der alltäglichen Komplexität im Projek-
tumfeld steigert sich diese nochmals durch die unterschiedlichen Wertesysteme,
die sich in der Unterschiedlichkeit der Verhaltens-, Sprach- und Denkweisen
äußern. Dadurch erhalten die Planung, Umsetzung und Führung cross- funktio-
naler Teams nochmals spezielle Herausforderungen.
Die Worte, die wir wählen, sind nur ein kleiner Teil in unserer Art zu kommuni-
zieren. Die Art, wie wir uns ansehen, die Stimmlage, der Kontext, in dem wir
sprechen – all dies transportiert mehr Information als das gesprochene Wort, die
Verben oder die Adjektive, die am Ende den ganzen Satz ergeben.
Daher ist es auch so wichtig, sich getroffen zu haben. Wir fühlen uns wohler,
wenn wir die Körpersprache, die Mimik und die Gestik, den Humor erlebt haben.
Wie aber ist dies zu deuten? In unserer eigenen Kultur können wir dies ohne
Probleme nachvollziehen.
Kultur
Kultur = Der Begriff Kultur entstammt dem lateinischen Wort „colere“ und
bedeutet so viel wie bebauen, bestellen pflegen. Jede Kultur hat ihre Besonder-
heiten und ihre eigenen, für sie typischen Orientierungen. Diese prägen die
Angehörigen einer Kultur und formen deren Identität.
Nach dem niederländischen Kommunikationswissenschaftler Geert Hofstede (*

1928) bedeutet Kultur die „mentale Software“, die in einem Sozialisationspro-
zess kulturell „programmiert“ wird. Im Laufe dieser Sozialisation und vor al-
lem in der Kindheit, der Primärsozialisation, erwirbt das Individuum bestimm-
te Muster des Denkens, Fühlens und Handels, die als Werte und Haltungen
umschrieben werden.
https://doi.org/10.1007/978-3-658-31310-4_15
220 Projektherausforderung im internationalen Umfeld — Why culture counts
Unsere Kultur setzt sich zusammen aus:
 Werten, Normen
 Kommunikationsstil
 Einstellungen
 Auffassungen
 Gefühlen, Erwartungen, Verpflichtungen
 Bedürfnissen
Geprägt durch die Gesellschaft, in der wir aufwachsen, prägt sich die soge-
nannte Kultur, in der wir leben und die unserer Wahrheit entspricht.
Für unseren Projektalltag bedeutet dies, wir können uns nicht entziehen – nicht
der eigenen Kultur, der des Teams und auch nicht der Unternehmenskultur.
Umso wichtiger ist es auch, für das Team eine Kultur mit eigenen Werten zu
entwickeln und sich in unserem Alltag bewusst zu machen, dass die unter-
schiedlichen „Wahrheiten“, in denen wir leben, einen gemeinsamen Nenner
benötigen, um ein gut funktionierendes Team zu haben.
 Wie wollen wir miteinander umgehen?
 Was ist Wertschätzung?
 Wie wollen wir kommunizieren?
 Wie wollen wir mit Konflikten umgehen?
Checkliste Kultur
Was konkret ist anders? Worauf müssen wir im Team hinsichtlich kultureller
Unterschiede achten?
Eigentlich ist nichts anders, nur alles komplexer!
 Kommunikation (z. B.: Was bedeutet Zusagentreue?)
 Wie Entscheidungen getroffen werden (gemeinschaftlich oder im Alleingang?)
 Wahrnehmung
 die Rolle in der Gemeinschaft
 die Art, Risiken zu betrachten
 der Aspekt Pünktlichkeit und Zeit

Nationalität
Der Begriff der Nationalität bezeichnet die Zugehörigkeit zu einem Staat. Die
Nationalität sorgt dafür, dass unsere Kultur und damit unsere Werte anders
sind. Die Herausforderung ist, dieses „anders sein“ erfolgreich für unser Pro-
jekt einzusetzen.
Herausforderungen im internationalen Umfeld oder: Worauf muss ich als

Projektleiter achten?
Je nach Situation stellen sich im internationalen Kontext viele Herausforderungen

und auch damit verbundene Risiken. Was ist anders und was kann ich als Pro-
jektleiter tun, damit diese Herausforderungen nicht zur Falle werden?
Standardisierung von Kommunikation, Besprechungen, Berichten und

Dokumenten
Die erste Herausforderung ist, in welcher Sprache die Besprechungen geführt

werden. Wie wird dokumentiert? Sehr oft haben die Teammitglieder sehr unter-
schiedliche Sprachkenntnisse. Dies allein kann zu groben Missverständnissen in
der Kommunikation führen. „Aber nur sprechenden Menschen kann geholfen
werden!“ Was können oder sollten wir tun, um möglichst wenig Reibungsverlus-
te zu haben?
Kommunikation und Informationsflüsse sollten nicht dem Zufall überlassen

werden. Stattdessen sind in internationalen Projekten bereits zu Beginn des Pro-
jektes Kommunikationsstandards zu definieren, z.B. Art, Form und Häufigkeit
der Regelkommunikation, des Reportings und der Dokumentation. Vorausset-
zung hierfür sind eine Projektorganisation mit festen Ansprechpartnern und eine
Festlegung der Projektsprachen, sowohl in Besprechungen als auch im Berichts-
wesen.
Weiterhin sollte Klarheit über Zusagentreue von Terminen und Arbeitspaketen

hergestellt werden. Was etwa heißt „pünktlich“? Denn auch hier kann es durch
kulturelle Unterschiede zu sehr unterschiedlichen Auffassungen über Pünktlich-
keit und Präsenz kommen.
Feste Projektorganisation und fix definierte Ansprechpartner
Die Verbundenheit zu Vorgesetzten und dem eigenen Land kann speziell in

internationalen Projekten zu einer Krise führen. Im Rahmen eines Veränderungs-
projektes habe ich erlebt, wie durch die Nähe der Chinesen zu ihren eigenen
222 Projektherausforderung im internationalen Umfeld — Why culture counts
Vorgesetzten die Struktur nochmals geändert werden musste. Im Rahmen einer

Zentralisierung des Einkaufs in den USA und nicht mehr in den eigenen Ländern
änderte sich auch die Berichtsstruktur. Diese ging entsprechend der Projekte
nicht mehr an den direkten Vorgesetzten wie bisher, sondern projektbezogen an
den Vorgesetzen in die USA. Was in den meisten Ländern keine Probleme mach-
te, musste in China nochmals angepasst werden. Erst in der Umsetzung des Pro-
jektes fiel auf, dass die nötigen Informationen aus China verspätet oder gar nicht
kamen. Durch das Einsetzen einer Führungskraft vor Ort ließ sich die Thematik
beheben.
Hätten wir in diesem Projekt die kulturellen Hintergründe noch intensiver be-
trachtet, so wäre die Verzögerung im Projekt gar nicht erst entstanden. In diesem
Fall ist sehr schnell klar geworden, wie wichtig die Betrachtung der kulturellen
Hintergründe beim Aufbau der Projektorganisation ist.
Genauso ist darauf zu achten, dass die entsprechend definierten Ansprechpartner

auch die für das Projekt notwendige Entscheidungsgewalt bezogen auf ihre Ar-
beitspakete haben.
Vereinbarungen über den Umgang mit Konflikten und Problemen
Konflikte und Probleme sind im Projektalltag völlig normal. Wo Menschen aufeinan-

dertreffen, kommen auch unterschiedliche Sichten und Meinungen zum Tragen.
Entscheidend ist nur, wie wir damit umgehen und ob wir das auch bewusst tun.
Respekt und gegenseitiges Vertrauen sind auch im internationalen Kontext die

Basis, um mit Störungen und Problemen umzugehen. Vertrauen lässt sich durch
die räumliche Distanz schwieriger aufbauen. Auch die Sprachbarriere stellt für
alle Beteiligten eine Herausforderung dar.
Gegenseitiger Respekt, Klarheit und offene Kommunikation sind auch hier die
Basis für eine erfolgreiche Teamarbeit. Meist sind sich die Teams darüber sehr
schnell einig. Allerdings gibt es große kulturelle Unterschiede, was als respekt-
volles Verhalten angesehen wird. Schmatzen ist in unserem Kulturkreis eher
weniger respektvoll, in China aber schon, um nur ein Beispiel zu nennen.
Es ist in internationalen Projekten darauf zu achten, dass kein Land im Projekt bevorzugt
behandelt wird.
Es ist hilfreich, in einer frühen Phase festzulegen, wer im Projekt welche Rolle hat:
■ Was wird vom Teammitglied in welchem Land entschieden? Wo hat der

Projektleiter egal welchen Landes das letzte Wort?
■ Welche Länder sind im Lenkungsausschuss vertreten?

■ Wie sieht die Teamstruktur aus?
■ Wie wird kommuniziert?
Probleme, die ich in lokalen Projekten habe, potenzieren sich sehr schnell im
internationalen Umfeld. Es ist immer darauf zu achten, dass sich keine Nation
benachteiligt fühlt. Bereits hier ist darauf zu achten, dass nicht schon Demotivati-
on und Konflikte durch das Gefühl der Ungerechtigkeit entstehen (z. B. Vertei-
lung der Reiselast; konkret heißt das: Die Besprechungen sollten nicht nur in
einem Land stattfinden, sondern auch hier die Last gleichmäßig verteilt werden!).
Beispiele möglicher Einkaufsprojekte im internationalen Kontext:
■ Projekte mit internationalen Lieferanten

■ Joint Venture im Ausland
■ Projekte der eigenen Firma mit Einbindung von ausländischen Standorten
■ Lieferantenlokalisierung im Ausland
Fazit
Sensibler Umgang mit der Projektorganisation und der damit verbundenen

Rollenklärung in einer frühen Phase, um potenziellen Problemen und Konflik-
ten wenig Raum zu geben.
 Eindeutige Klärung der Sprache im Projekt; bei der Auswahl der Teammit-
glieder ist dies bereits zu berücksichtigen.
 Berücksichtigung der Zeitzonen bei der Festlegung der Besprechungstermine.
 Stakeholderanalyse durchführen! Bedingt durch die entsprechenden Kultu-

ren können die Macht und Einflussgrößen sehr unterschiedlich sein.
 Mehr Zeit für Besprechungen und Abstimmungen planen; erfahrungsge-

mäß ist dies durch die Sprachbarriere notwendig.
 Zeit ist eine wichtige Dimension in unterschiedlichen Kulturen – genauso

das Thema, was als pünktlich empfunden wird. Legen Sie frühzeitig fest,
welcher Spielraum für das gemeinsame Projekt gilt!
16 Steuerung von Projekten

Die Steuerung von Projekten ist der über die gesamte Projektlaufzeit stattfinden-
de Prozess des Abgleiches von Soll und Ist. Genau wie bei der Planung werden
Termine, Kosten und vereinbarter Leistungsumfang aus dem Plan mit dem aktu-
ellen Stand verglichen.
Auch hier gilt der sogenannte Steuerkreis. Der von William Edwards Deming
entworfene Steuerkreis zur kontinuierlichen Verbesserung der Qualität kann
auch in Projekten angepasst werden.
Abbildung 16.1 Steuerkreis
Was wir in der Definitionsphase über das „Magische Dreieck“ (Termine, Kosten,
vereinbarter Leistungsumfang) festgelegt haben, wird in der Planungsphase
detailliert und im sogenannten Basisplan festgehalten. Der Basisplan wird nur
https://doi.org/10.1007/978-3-658-31310-4_16
über den offiziellen Änderungsantrag und die damit verbundene Genehmigung

durch den Lenkungsausschuss angepasst. In der Umsetzungsphase findet der
regelmäßige Soll-Ist-Abgleich statt.
Phasen der Projektsteuerung
Der Bereich, der gesteuert werden soll, wird durch

den Termin und den vereinbarten Leistungsumfang
eingegrenzt.
In der Planungsphase werden Detailziele über die

1. Planen
Meilensteine eingesetzt. Im Projektstrukturplan
finden wir dann alle Arbeitspakete wieder, die zur
Zielerreichung dienen sollen. Diese werden in der
Umsetzungsphase permanent gesteuert und hin-
sichtlich der Erreichung von Termin, Kosten und
Leistungs-umfang überprüft!
In der Umsetzungsphase werden die geplanten

Arbeitspakete durch den jeweils verantwortlichen
Bereich umgesetzt. Im Projektteam sitzt als Schnitt-
stelle entweder der Umsetzer direkt als Teammit-
glied, oder das Kernteammitglied steuert die Um-
2. Umsetzen
setzung in seinem jeweiligen Fachbereich.
Trendaussagen bekommt der Projektleiter bereits

durch Werkzeuge wie die Meilenstein- oder auch
die Kostentrendanalyse.
Gleichzeitig wird die Einhaltung der vorgegebenen

Zeiten, Kosten und Inhalte überprüft. Der Termin-
sowie der Kostenplan dienen hier als Werkzeuge.
Das Kernteam sitzt in seinem regulären Meeting
zusammen und bespricht den Projektfortschritt
3. Überprüfen
sowie eventuelle Abweichungen. Szenarien, wie die
Abweichungen angepasst werden, sollten durch das
verantwortliche Teammitglied erbracht werden.
Hinsichtlich der Auswirkungen auf das Gesamtpro-
jekt steuert der Projektleiter gemeinschaftlich mit
dem Team gegen.
Die Anpassung der Abweichung erfolgt hinsichtlich

diverser Faktoren. Ist das Projekt eher termingetrie-
ben, so werden die Kosten oder der Leistungsumfang
angepasst. Ist das Projekt eher kosten- als terminge-
4. Anpassen trieben, so werden die Auswirkungen eher in Rich-
tung Anpassung des Termins gehen. Diese Maßnah-
men allerdings können nur über die Anpassung des
Basisplans und damit einer offiziellen Genehmigung
erfolgen. Am Ende des Tages ist es immer wieder die
gleiche Frage: Wer kommt für die Kosten auf?
Die Aufgabe des Projektleiters mit seinem Team ist

es, so lange wie möglich die Anpassungen der Ar-
beitspakete im Voraus und im vorgegebenen Rah-
men von Termin, Kosten und Qualität durchzuführen.
Fazit
 Es werden Kosten, Termine und Leistungsumfang gesteuert. Diese sind im

Basisplan verankert.
 Die Projektsteuerung hinsichtlich der Erreichung von Zielen und Teilzielen

liegt im Verantwortungsbereich des Projektleiters.
 Bereits in der Definitionsphase werden die Grundsteine für die Projektsteu-

erung gelegt. Daher ist es besonders wichtig, den vereinbarten Leistungs-
umfang mit dem Kunden sauber abzugrenzen. Ist dies nicht klar geschehen,
sind die Probleme im weiteren Projektverlauf vorgegeben.
 Über das Magische Dreieck wird der Rahmen des Projektes in der Definiti-
onsphase abgesteckt. Die Informationen über das Projekt sind hier oft noch
sehr rudimentär.
 Der in der Definitionsphase abgesteckte Rahmen wird mit Meilensteinen

versehen. Meilensteine sind Teilziele, die mir dabei helfen, auf dem Weg
der Zielerreichung überprüfen zu können, ob das Ziel noch im vorgegebe-
nen Rahmen erreicht wird.
 Meilensteine liegen immer auf dem kritischen Pfad. Mit Hilfe der Meilen-
steintrendanalyse sind die Auswirkungen als „Trend“ vorauszusehen.
 Ziel ist es immer, zu einem frühen Zeitpunkt noch Handlungsoptionen zu

haben, um das Ziel doch noch im vorgegebenen Rahmen erreichen zu kön-
nen, und nicht erst am Ende des Projektes festzustellen, dass die Ziele nicht
mehr im vorgegeben Rahmen liegen.
 Dies setzt genügend Rückmeldung über die Erreichbarkeit der Arbeitspake-

te voraus. Die Rückmeldung über die diversen Stadien der Arbeitspakete
erfolgt in den Kernteammeetings.
 Der Projektleiter holt je nach Projektstand entsprechende Unterstützer zu

den Sitzungen dazu. (siehe Kapitel 5.7 – Projektorganisation).
16.1 Steuerung des Projektes Kosten- und

Terminplan
Die auf die Zukunft geplanten Kosten des Projektes müssen sich rechnen. Insofern
werden alle für die Umsetzung des Projektes notwendigen Kosten abgeschätzt
(siehe Kapitel 5.6, bzw. Schritt 6 – Kostenplanung) und im Verlauf des Projektes
überwacht. In der frühen Phase des Projektes wurden die Kosten über Vergleichs-
werte mit den Spezialisten abgeschätzt. Im weiteren Verlauf und mit mehr Informa-
tionen über das Projekt wurden diese auf einzelne Arbeitspakete heruntergebro-
chen. Diese Arbeitspakete werden zeitlich und auch kostenmäßig gesteuert. Die
Größe der Arbeitspakete sollte daher entsprechend überschaubar sein.
16.2 Kostensteuerung
Auf Basis der Planungskosten erfolgt in der Umsetzungsphase die Steuerung der
Kosten. Wie auch bei Terminen und Leistungsumfang werden die Plankosten mit
den jeweiligen Ist-Kosten abgeglichen. Der erledigte Leistungsumfang wird in ein
Verhältnis zu den tatsächlich ausgegebenen Kosten gesetzt. Eventuell auftretende
Abweichungen sollen frühzeitig erkannt und angepasst werden.
In Abbildung 16.2 sehen wir symbolisch die über den Projektstrukturplan ermit-
telten Arbeitspakete. Diese werden über die gesamte Projektlaufzeit aufsummiert
und ergeben im Ganzen die Projektkosten. All dies passiert gemeinsam mit den
Experten in der Planungsphase.
Im Verlauf der Umsetzung des Projektes gleichen wir die geplanten mit den
tatsächlich angefallenen Kosten ab und greifen steuernd ein, wenn notwendig.
Kostensteuerung 229
Abweichungen werden nur über einen offiziell genehmigten Änderungsantrag

eingearbeitet. Diesen gilt es, vom Lenkungsausschuss genehmigen zu lassen. Erst
danach wird auch der Kostenbasisplan angepasst.
Fazit
 Die Kosten werden mit den Experten gemeinsam abgeschätzt.
 Die Basis für die Kostenschätzung sind in der frühen Phase des Projektes
die Vergleichswerte der jeweiligen Experten.
 Im Verlauf der tieferen Planung werden die Kosten durch die Arbeitspakete
konkretisiert (Bottom-up-Planung).
Arbeitspakete sollten nicht zu klein gestaltet werden, damit man nicht nur damit
beschäftigt ist, die Terminpläne oder Kostenpläne anzupassen. Die Werkzeuge
wie Termin- und oder Kostenplan sollen uns helfen, Projekte transparenter zu
gestalten und damit steuerbar zu machen und nicht das Leben des Projektleiters
komplizierter.
Abbildung 16.2 Steuerung der Kosten über Arbeitspakete

Über die im Projektstrukturplan geplanten Arbeitspakete erfolgt auch die Projekt-

steuerung. Im Verlauf des Projektes wird der Kostenbasisplan mit der zu erbringen-
den Leistung verglichen. Es wird abgeglichen, ob die Arbeitsleistung zu einem be-
stimmten Termin und zu den geplanten Kosten umzusetzen war. Konkret heißt das:
■ Zu einem Zeitpunkt X (in der Planungsphase) wurde eine Leistung geplant.

Diese wurde im Projektstrukturplan auf Arbeitspakete heruntergebrochen.
■ Diese Leistung hat Plankosten, die ebenfalls im Arbeitspaket dargestellt

werden.
■ Alle direkten und indirekten Kosten werden zugeordnet, soweit dies möglich
ist. Entsprechende Kennzahlen wie Personenkosten je Stunde können über
den Finanzbereich des Unternehmens abgefragt werden.
■ In der Umsetzungsphase wird durch den permanenten Soll-Ist-Abgleich die er-

brachte Leistung ins Verhältnis zu den geplanten Terminen und Kosten gestellt.
■ Ist zu erkennen, dass Abweichungen vorhanden sind oder anstehen, so wird

entsprechend gegengesteuert.
■ Durch die Unterteilung in Teilziele (Meilensteine) und entsprechende Ar-

beitspakete wird das große Paket Projekt transparent und steuerbar gemacht!
16.3 Meilensteintrend- und Kostentrend-

analyse als Werkzeug zur
Früherkennung von Abweichungen
Meilensteine sind Teilziele auf dem Weg zum Gesamtziel. Kann ich das Teilziel
nicht erreichen, so ist auch das entsprechende Gesamtziel des Projektes in Gefahr.
Das bedeutet eingreifen und anpassen.
Die Meilensteintrendanalyse ist ein effizientes Werkzeug, um den Projektfort-

schritt zu überwachen. Dieses Überwachungswerkzeug setzt voraus, dass die für
das Projekt relevanten Meilensteine gut geplant und im Terminplan fixiert sind.
Nur dann macht diese Methode wirklich Sinn.
Abbildung 16.3 zeigt die schematische Darstellung eines Meilensteins mit den
Arbeitspaketen A–D, die zur Erreichung des Meilensteins notwendig sind. Der
Basisplan wird in der Umsetzungsphase überprüft. Die Meilensteine können über
den gesamten Projektverlauf beobachtet und gesteuert werden. Dies ist ein sich
permanent wiederholender Prozess.
Meilensteintrend- und Kostentrendanalyse 231
Abbildung 16.3 Meilensteintrendanalyse
Meilensteintrendanalyse
Die Meilensteintrendanalyse (MTA) ist eine übersichtliche Kombination aus His-

torie und Prognose ausgewählter Meilensteine eines Projekts. In einer grafischen
Darstellung werden die detailliert geplanten Meilensteine eingetragen und in
entsprechenden Berichtszeiträumen überwacht. So sind sehr schnell mögliche
Abweichungen in den Arbeitspaketen nachzuvollziehen, ohne dass ich als Pro-
jektleiter immer alle Arbeitspakete im Blick haben muss. Erst wenn die Meilen-
steintrendanalyse Unregelmäßigkeiten aufweist, werden gemeinsam mit dem
Team die Abweichungen analysiert und auf die Zukunft ausgerichtet angepasst.
Ziel der MTA ist es, ein effizientes Steuerungswerkzeug zu haben!
Wie wird die Meilensteintrendanalyse in der Praxis angewandt? Zu Beginn des

Projektes werden die Meilensteine über den Berichtszeitraum aufgetragen. Es
gibt in der Darstellung zwei Zeitachsen. Auf der Y-Achse werden die geplanten
Meilensteine über den Projektverlauf und auf der X-Achse die entsprechenden
Berichtszeiträume in der Umsetzung des Projektes eingetragen.
Wie funktioniert die Meilensteintrendanalyse?
1. Festlegen der Meilensteine, die beobachtet werden sollen.
2. Überwachen und Anpassen der Meilensteine bei Abweichungen/Berichtszeit-

räume sind festgelegt.
3. Ursache für die Abweichungen in den Arbeitspaketen ermitteln.
4. Aktivitäten zur Anpassung der Abweichungen ergreifen und wenn das nicht
möglich ist, dann sind über einen offiziellen Änderungsantrag die Anpassun-
gen im Projekt vorzunehmen.
Abbildung 16.4 Meilensteintrendanalyse und Berichtszeitraum
Als Projektleiter nutze ich die Meilensteintrendanalyse als Werkzeug, um nicht

ständig alle Arbeitspakete zu beobachten. Die Arbeitspakete führen zu den Teil-
zielen, den Meilensteinen. Kann ich also absehen, dass sich ein Meilenstein be-
wegt, so habe ich immer noch die Möglichkeit, an dieser Stelle tiefer in den Plan
zu gehen und bei Bedarf entsprechende Aktivitäten zu ergreifen. Die MTA soll
als Hilfsmittel dienen, sehr schnell einen Überblick über den aktuellen Status des
Projektes zu bekommen, um dann entsprechende Handlungsoptionen für die
Zukunft daraus abzuleiten (Quelle: PMBOK, A Guide to the Project Management
Body of Knowledge, 2008, 4. Auflage, S. 20).
Weiterhin ist es auch ein gutes Reportinginstrument für den Lenkungsausschuss

oder den Kunden.
Wie kann ich die entsprechenden Bewegungen der jeweiligen Meilensteine

deuten?
Meilenstein 1 ist volatil. Das heißt, er bewegt sich. Ein guter Grund tiefer einzu-
steigen. Dies kann vielfältige Ursachen haben. Offensichtlich war er laut Dia-
gramm im ersten Berichtszeitraum im Plan. Im 2. Berichtszeitraum gab es eine
Abweichung, im 3. Berichtszeitraum ist der Meilenstein sogar verkürzt.
Meilenstein 2 scheint stabil. Hier aber ergibt sich die Frage, warum Meilenstein 1
keine Auswirkung auf Meilenstein 2 hat.
Meilenstein 3 ist laut Skizze verspätet und bisher noch nicht korrigiert. Im Detail
wäre zu prüfen, warum sich der Meilenstein verspätet hat und ob eine Korrek-
turmaßnahme möglich ist oder der Plan angepasst werden muss.
1. Ursache für die Abweichungen in den Arbeitspaketen ermitteln.
2. Aktivitäten zur Anpassung der Abweichungen ergreifen; wenn das nicht

möglich ist, dann über einen offiziellen Änderungsantrag die Anpassungen
im Projekt vornehmen.
Fazit
 Die Meilensteintrendanalyse dient in erster Linie dazu, den Projektfort-

schritt zu überwachen, Abweichungen zu erkennen und vorausschauend
entgegenwirken zu können.
 Das Projekt bleibt transparent und die notwendigen Ressourcen können

entsprechend eingesetzt werden.
 Wichtig ist, dass in der Planungsphase alle relevanten Teilziele (Meilenstei-

ne) definiert wurden und somit der Einsatz der MTA auch Sinn macht!
 Weiterhin eignet sich die MTA auch als Reporting-Instrument für das Ma-
nagement. Der Projektstatus und die Bewegungen im Projekt sind auf einer
oder wenigen Seiten darstellbar.
17 Kommunikation im Projekt und

Austausch von Informationen
17.1 Austausch von Informationen

Die Kunst, Botschaften und Nachrichten zu kommunizieren, ist ein großer Be-
standteil der Aufgabe eines Projektmanagers. Wir erinnern uns: Etwa 95 % aller
Tätigkeiten des Projektleiters stehen im Zusammenhang mit der Kommunikation.
Ob eine Besprechung, eine Verhandlung mit dem Lieferanten, die Umsetzung der
Arbeitspakete, das Reporting oder auch die Präsentation vor Lenkungsausschuss
und Gremien – alles steht im Zusammenhang mit der Kommunikation. Wir alle
kommunizieren auf die eine oder andere Art. Wie der Philosoph und Soziologe
Paul Watzlawick (1921–2007) sagte, kann man nicht nicht kommunizieren.
Abbildung 17.1 Sender und Empfänger (Quelle: Friedemann Schulz von Thun,
Miteinander reden 4: Fragen und Antworten, 2007, S. 36)
Wir haben unterschiedliche Möglichkeiten und Medien:
■ Face-to-Face (Besprechung, Präsentation ...)

■ Telefon oder E-Mail
– die richtige Wahl des Mediums zur Zielerreichung ist entscheidend.
Zum Austausch von Informationen benötigt man immer zwei oder mehrere Par-
teien. Ein paar Spielregeln gelten für alle Kommunikationsarten, egal ob Bespre-
chung, Video oder Telefonkonferenz.
https://doi.org/10.1007/978-3-658-31310-4_17
236 Kommunikation im Projekt und Austausch von Informationen
1. Schaffen Sie eine positive Atmosphäre – eine angespannte Atmosphäre ist

selten eine gute Basis für eine erfolgreiche Kommunikation. Dies gilt auch für
die Verhandlung. Wertschätzung und respektvoller Umgang miteinander
sind die Basis für eine gemeinsame Zielerreichung. Ein freundlich gesproche-
nes „Nein“ kann dann auch besser gehört werden.
2. Seien Sie authentisch. Was immer Sie tun, welches Werkzeug auch immer Sie
nehmen: Schauspielerei fällt Ihrem Gegenüber auf. Bleiben Sie sich treu und
nutzen Sie die erlernten Methoden in Ihrem Sinn!
3. Die Begrüßung als Türöffner – eine freundliche Begrüßung, ein paar unverfäng-
liche Worte zu Beginn sind ein Muss, ob in der Besprechung oder am Telefon.
4. Worum sich die Besprechung dreht, wurde vorab per Einladung bekanntgege-
ben. Wiederholen Sie das Unterfangen nochmals zu Beginn einer jeden Kom-
munikation. Sie wissen nie, wo Ihr Gegenüber gerade steht. Holen Sie ihn ab.
Wann immer wir kommunizieren gilt: Jeder hat seine eigene Wahrheit, eine gemein-
same müssen wir erst erarbeiten!
Um erfolgreich zu kommunizieren, gilt es, die Barrieren zu durchbrechen. Wie

aber erreiche ich meinen Gesprächspartner und stelle sicher, dass meine Botschaft
auch angenommen werden kann?
Hier einige Stichworte zum Thema respektvoller Umgang miteinander und mit
welchen Aktivitäten dieser gezeigt werden kann:
■ Aktives Zuhören: Das meint die passive Tätigkeit, zu verstehen, was den Ge-
sprächspartner bewegt. Den Gesprächspartner als Mensch und seinen Stand-
punkt zu respektieren heißt aber noch nicht, diesen auch zu akzeptieren!
Wodurch kennzeichnet sich das aktive Zuhören? Nach Carl Ransom Rogers
(1902–1987), dem Begründer der Gesprächstherapie in der medizinischen Psycho-
logie, bilden drei wesentliche Elemente die Basis des „aktiven Zuhörens“:
■ Die Grundhaltung sollte empathisch und offen sein.

■ Die Gesprächspartner sollten authentisch und kongruent auftreten.
■ Man sollte seinem Gegenüber Akzeptanz und bedingungslose positive Beach-
tung entgegenbringen.
Rogers medizinischer Ansatz ist heute noch grundlegend für die generelle Ge-
sprächsführung der alltäglichen Kommunikation des „aktiven Zuhörens“. Fol-
gende Handlungen nach Rogers unterstützen das Verstehen des Gegenübers:
Auswahl der Kommunikationsmethode 237
Verbal
■ Zustimmen: „Ja“, „Ich verstehe“, „Da gebe ich dir Recht“

■ Nachfragen: „Kannst du das bitte noch einmal genauer erklären?“
■ Die eigene Meinung vorerst zurückhalten
■ Pausen aushalten und aussprechen lassen
Nonverbal
■ Offener Blick
■ Augenkontakt halten
■ Zustimmung durch Körpersprache – Nicken, offener Blick
■ Notizen machen
Klarheit in der Kommunikation
■ Klar sein in dem, was ich selber kommunizieren möchte

■ Die Botschaft kurz und knapp kommunizieren
■ Sicherstellen, dass die Botschaft auch angenommen und verstanden werden
konnte
Fazit
 Eine positive Atmosphäre ist unerlässlich.
 Aktives Zuhören ist erlernbar und zeigt Wertschätzung und Respekt für
den oder die Gesprächspartner.
 Ein Respektieren der Position des Anderen ist noch lange kein Akzeptieren.
17.2 Auswahl der Kommunikationsmethode

Die Wahl der jeweiligen Methode hat einen großen Einfluss auf die Botschaft und
wie diese angenommen werden kann. Wir haben immer die Wahl zwischen dem
geschriebenen oder dem gesprochenen Wort. Ist der Anspruch mehr formal bzw.
möchte ich meine Nachricht dokumentiert wissen, so wird der schriftliche Ansatz
genutzt. Das gesprochene Wort kann ebenfalls in unterschiedlichen Varianten
transportiert werden – abhängig von der räumlichen Distanz der Teams oder
Partner sowie der gegeben Möglichkeiten.
Tabelle 17.1 Arten der Kommunikation
Art der Kommunikation Beispiele Nutzen
Das geschriebene Wort E-Mail, Briefe, Berichte, Das geschriebene Wort ist
‒ Wahl der Sprache Verträge, Terminpläne, nachhaltiger, kann nachge-
Kostenpläne, Agenden, lesen werden und gibt auch
‒ Wahl des Mediums
Einladungen meinem Gegenüber Zeit,
darüber nachzudenken.
Das gesprochenen Wort Besprechungen, Interviews, Der direkte Austausch hat

‒ Wahl des Mediums Präsentationen, Berichte, den Vorteil, dass auch eine
Telefonate, Ansprachen direkte Antwort möglich ist.
‒ Wahl des Personen- Die diversen Besprechun-
kreises
gen müssen aber gut vor-
‒ Festlegung des Inhalts bereitet sein, um eine hohe
‒ Mimik und Gestik können Motivation der Beteiligten
mit eingesetzt werden zu ermöglichen.
Multimedia Telefonkonferenzen, Telefonkonferenzen sind

‒ Kombination unterschied- Videokonferenzen, extrem gut vorzubereiten
licher Methoden Web-Systeme und auch der Teilnehmer-
kreis entsprechend gut zu
‒ Hilfreich bei Überbrü- strukturieren, damit die
ckung von Distanzen Telko kurz und effizient
abgewickelt werden kann.
Die Videokonferenz hat den
Vorteil, dass Gestik und
Mimik mit eingebracht
werden können.
17.3 Besprechung
Die Besprechungen sind ein wichtiger Bestandteil der Kommunikationsstruktur.
Sehr oft kommt eine Demotivation der Teilnehmer durch zu lange und unstruk-
turierte Besprechungen zustande.
Besprechung 239
Damit eine Besprechung zielgerichtet stattfinden kann, ist eine gute Vorbereitung
notwendig. Diese Vorbereitung gibt es nicht umsonst, sie kostet Zeit!
Als Projektleiter ist es hilfreich, sich eine Matrix über die jeweiligen für das Pro-
jekt notwendigen Besprechungen zu erstellen und hier bereits alles, was möglich
ist, zu standardisieren. Mögliche Besprechungen für die Projekte sind:
■ Kernteammeeting
■ Lenkungssauschussmeeting
■ Besprechungen mit Lieferanten
■ Reports vor dem Auftraggeber
Der Inhalt des Kernteammeetings ist die Projektfortschrittskontrolle. Kernteam-
mitglieder und Unterstützer, wenn notwendig, treffen sich, um den Soll-Ist-
Abgleich des Basisplans vorzunehmen. Wir steuern auch an dieser Stelle Termi-
ne, Kosten im Verhältnis zum vereinbarten Leistungsumfang.
Hier werden die aktuellen Basispläne und deren Arbeitspakete abgeglichen und
mit dem kompletten Kernteam entsprechende Szenarien bzw. die Korrekturmaß-
nahmen mit den jeweiligen Arbeitspaketverantwortlichen abgestimmt.
Bei Abweichungen stellt sich immer folgende Frage:
Welche Auswirkung hat dies auf
■ Termine,
■ Kosten,
■ Leistungsumfang
und wie können wir die Abweichungen so beeinflussen, dass die Auswirkungen
auf den Endtermin minimiert werden?
Die Standardisierung an dieser Stelle betrifft:
■ den Zeitrahmen,
■ den Ort,
■ die Teilnehmer (Das Kernteam steht fest, die unterstützenden Funktionen
werden nach Bedarf hinzugezogen!).
Lenkungssausschussmeetings sind Besprechungen, in denen der Projektleiter den

aktuellen Status bespricht und eventuelle Szenarien über Abweichungen zur Ent-
scheidung bringt. Die möglichen Optionen sind an dieser Stelle gut vorzubereiten. Im
Lenkungsausschuss sitzen die jeweiligen Entscheider der jeweiligen Fachbereiche.
17.3.1 Vorbereitung
Um effizient arbeiten zu können, ist die Vorbereitung der Besprechung unerläss-
lich. Dies stellt auch sicher, dass nur Teilnehmer eingeladen sind, die bei der
Zielerreichung der Besprechung unterstützen können.
Die Einladung sollte je nach Distanz der eingeladenen Personen möglichst früh-
zeitig stattfinden. Alternativ kann auch die Videokonferenz genutzt werden,
wenn die Distanzen zu weit entfernt liegen: „Save the date“!
Der Inhalt der Einladung sollte sein:
■ Ziel der Besprechung

■ Zeitrahmen
■ Ort
■ Erwartung an die Teilnehmer
■ Tagesordnungspunkte
Achtung! Eine gute Vorbereitung benötigt Zeit. Dafür sind die Teilnehmer moti-
vierter, da nur diejenigen anwesend sind, die auch zum Thema beitragen können.
17.3.2 Durchführung
Während der Besprechung sollte zielorientiert vorgegangen werden. Dass die
Teilnehmer pünktlich zur Besprechung erscheinen sollten, kann bereits in den
Werten des Teams verankert werden. Immer wieder wird in den Seminaren ge-
spiegelt, dass Respekt und Wertschätzung zur Motivation wichtig sind. Den
anderen Teammitgliedern nicht die Zeit rauben und sie nicht warten lassen, ist
ein Schritt in diese Richtung. Es ist wichtig, genügend Raum für den Austausch
zu geben, aber trotzdem zielorientiert vorzugehen. Je nach Situation ist es die
Aufgabe des Projektleiters, das Gefühl für sein Team zu haben. Trotzdem sollte
der Zeithorizont eingehalten werden. Die vorher benannten Tagesordnungs-
punkte werden abgearbeitet und der Status dokumentiert. Offene Fragen werden
wenn möglich geklärt. Weitere Aktionen sind fix und werden im Protokoll fest-
gehalten – wenn möglich, gleich über den Beamer für alle visualisiert. Wer Proto-
koll für dieses Meeting führt, sollte vorab fix sein.
Besprechung 241
Für Arbeitspakete ist immer ein Termin und ein Verantwortlicher festzulegen. An
dieser Stelle immer eine Person benennen und nie nur die Funktion. Herrn oder
Frau XY klar benennen und die Aufgabe sowie den Termin abstimmen (siehe
Kapitel 6.1.1 – Delegieren, aber richtig).
Während der Besprechung:
■ Vorstellung des Ziels und des Themas

■ kurze Vorstellung der Teilnehmer, falls diese sich noch nicht kennen sollten
■ Vereinbarungen für den Ablauf des Meetings abstimmen
‒ Zum Beispiel: Wie wollen wir mit Mobiltelefonen während der Sitzung
umgehen?
‒ Zeitrahmen
‒ ....
■ Agenda abarbeiten
■ wichtige Ergebnisse dokumentieren
■ nächste Schritte festlegen
■ Besprechung offiziell beenden
17.3.3 Nachbereitung
Das Protokoll sollte zeitnah zur Besprechung versandt werden. Das Protokoll
sollte kurz und knapp gehalten werden. Die Teilnehmer bestätigen, dass sie mit
dem Protokoll, dem Maßnahmenplan oder den Arbeitspaketen einverstanden
sind. Dazu versenden Sie diese Dokumente an alle Teilnehmer der Besprechung
und bitten um Rückmeldung bis zu einem bestimmten Datum. Gehen solche
Rückmeldungen nicht ein, gilt das Protokoll der Besprechung als „genehmigt“.
Diese Vereinbarung kann für das Projektteam als allgemein gültige Regel verein-
bart werden. Die einzelnen Punkte können auch während der Besprechung be-
reits fixiert werden. Die aktuellen Terminpläne und Arbeitspakete, die während
der Besprechung berücksichtigt werden, können via Beamer für alle visualisiert
werden. So haben sie als Projektleiter oder Einladender die Möglichkeit, die Er-
gebnisse bereits während des Meetings „freizugeben“. Die Ergebnisse gelten
dann als abgestimmt. Danach wird das Protokoll nur noch verteilt. Wer während
der Besprechung kein Veto einlegt, hat dem Protokoll zugestimmt. Dies sollte
aber als Spielregel vorab geklärt sein.
Nach der Besprechung nicht vergessen, eine eigene To-do-Liste anzulegen:
■ Benötigen Sie weitere Informationen? Wenn ja, mit wem müssen Sie Kontakt
aufnehmen, um diese zu erhalten?
■ Wer muss außerhalb des Teams seitens der Stakeholder informiert werden?
■ Benötigen Sie weitere Unterlagen oder Teile?
■ Was wird das Ziel der nächsten Besprechung sein?
■ So es kein reguläres Meeting ist, ist diese notwendig?
17.4 Das Ding mit der persönlichen

Distanzzone!
Eine entspannte Kommunikation kann nur in einer persönlichen Distanzzone
erfolgen. Die klassische Distanz (Distanzzonen nach dem US-amerikanischen
Anthropologen Edward T. Hall, 1914–2009, Quelle: Edward T. Hall, The hidden
dimension, 1966), in der wir uns bei Smalltalk, mit Arbeitskollegen und Bekann-
ten wohlfühlen, beträgt ca. eine Armlänge (50 cm von uns weg). Alles was dichter
an uns kommt, empfinden wir als Eindringen in die Intimzone. Hall unterschei-
det zwischen der intimen, der persönlichen, der sozialen und der öffentlichen
Distanzzone.
■ Intime Distanzzone: zwischen 15 und 45 cm. Nur Menschen, die uns emotio-
nal nahestehen, dürfen in diese Zone eindringen.
■ Persönliche Zone: zwischen 50 und 122 cm. Dies ist die Wohlfühlzone bei
Smalltalk und eben auch beim Treffen neuer Menschen, so auch der Team-
mitglieder.
■ Soziale Zone: zwischen 122 und 360 cm. Diese Distanz halten wir bei Treffen
in unserem Bereich ein; zum Beispiel Handwerker in der Wohnung.
■ Öffentlich Zone: Ab 360 cm. Wann immer wir auf der Straße eine anonyme
Menschengruppe treffen, empfinden wir diese Distanz als angemessen.
Laut Hall sind die Werte Mittelwerte. Frauen stehen sich eher näher gegenüber
als Männer. In sogenannten Kontaktkulturen wie Lateinamerika darf man sich
deutlich näher kommen. Ansonsten gilt die Regel, die unsichtbaren Grenzen
nicht zu überschreiten, um ein positives Gefühl bei allen Beteiligten zu ermög-
lichen.
Das Telefon als Medium 243
Kulturelle Unterschiede: In Ländern wie Spanien, Frankreich, Italien oder Süd-

amerika kann es sein, dass männliche Kollegen sich umarmen. In Japan ist Kör-
perkontakt nicht üblich. In China und Japan ist es üblich, bei der Begrüßung
Visitenkarten zu tauschen.
■ Die Besprechungen sind zur effizienten Abwicklung gut vorzubereiten.

■ Ziele, Zeitrahmen und Inhalte sind dem Teilnehmerkreis frühzeitig mitzu-
teilen.
■ Die Entscheidungen während der Sitzung visualisieren, damit Einwände

gleich besprochen werden können.
■ Nach der Sitzung zeitnah das Protokoll an alle Beteiligten versenden. Das
Protokoll möglichst knapp halten, da die Flut an Informationen in unserem
Umfeld sowieso schon sehr groß ist.
■ Die Spielregeln für das Projektteam und auch die Besprechungen sollten vor-
ab festgelegt sein.
17.5 Das Telefon als Medium

Die Telefonkonferenz ist erfahrungsgemäß ein hilfreiches, aber auch sensibel zu
benutzendes Medium.
Wann ist eine „Telko“ hilfreich?
■ Bei räumlichen Abständen.

■ Bei nur wenigen Teilnehmern (wir erkennen uns an der Stimme).
■ Bei Abfragen und dem Abstimmen von konkreten Arbeitspaketen.
Für eine Telefonkonferenz ist eine noch strukturiertere Vorbereitung notwendig
als in der Besprechung, um die Teilnehmer motiviert zu halten. Der Ablauf, die
Inhalte, das Ziel und die Erwartungen an die teilnehmenden Personen sind expli-
zit vorab schriftlich zu benennen.
Wenn möglich, den Zeitrahmen von 30 bis 45 Minuten nicht sprengen.
Auch hier gilt:
■ Agenda im Voraus versenden.

■ Alle notwendigen Dokumente parat haben.
■ Ziel klar definiert haben.

■ Kleiner Teilnehmerkreis abgestimmt und eingeladen.
■ Während der Telefonkonferenz findet eine kurze Vorstellung der Teilnehmer
(nicht mehr als 2–5) statt.
■ Der Grund und das Ziel der Telko werden vom Einladenden kurz wiederholt.
■ Langsam und deutlich sprechen
■ Nach dem Telefonat werden die wichtigen Punkte schriftlich festgehalten.
■ Lächeln Sie, während Sie sprechen. Auch das können die anderen Teilnehmer
„hören“!
17.6 Fragen und Hinterfragen, aber richtig

Die richtige Fragetechnik begleitet den Projektleiter von der Auftragsklärung bis
zum Abschluss des Projektes.
■ Warum?
■ Was?
■ Wie?
■ Wer?
■ Bis wann?
sind dabei mächtige Worte. Als Projektleiter ist das Hinterfragen der Ist- oder
Sollzustände ein ständiges Hilfsmittel. Arbeitspakete, Zeiträume, Abweichungen
– all das gilt es zu verstehen. „Wer fragt, der führt“, lautet ein altes Sprichwort.
Wenn ich rede, höre ich nur, was ich schon weiß, wenn ich aber Fragen habe und
zuhöre, habe ich die Chance, Neues zu erlernen. Die richtige Frage öffnet die Tür
für Wissen und Verständnis. Das permanente Hinterfragen und daraus resultie-
rende Verständnis sind die Basis für eine gute Teamarbeit.
Es gibt unterschiedliche Fragestellungen, daher ist es hilfreich, sich selber zu

fragen, welche Form am besten zu meinem Ziel passt. Manchmal hat man mit
einer Frage noch nicht sein Ziel erreicht, deshalb sollten wir uns nicht scheuen,
die Fragen so lange zu stellen, bis wir eine zufriedenstellende Antwort erhalten
haben.
Feedback geben — Feedback nehmen, was heißt das genau? 245
Tabelle 17.2 Wann macht welche Frageform Sinn?
Die richtige Frage zur richtigen Zeit
Fragestil/-typ Beispiele
Offene Fragen ‒ Könnten Sie uns bitte einige Informatio-

Diese Frageform fordert keine genaue nen zu Ihrer Firma geben?
Antwort, sondern ist hilfreich beim Erlan- ‒ Welche Erwartungen haben Sie an die
gen von Informationen und zur Eröffnung Zusammenarbeit mit unserer Firma?
einer Diskussion.
Geschlossene Fragen ‒ Können Sie uns die gewünschte Stück-

Diese Fragen sind zielorientiert und nur mit zahl liefern?
Ja oder Nein zu beantworten. Sie geben ‒ Findet der Termin am 20.02. statt?
dem Gegenüber wenig Raum!
Faktensuche ‒ Wie viel Prozent Ihres Umsatzes werden

Diese Fragen haben das Ziel, Informatio- Sie mit unserer Firma machen?
nen über eine bestimmte Situation zu ‒ Welchen Anteil R&D können Sie im Cost
erlangen. Breakdown nachweisen?
Feedback-Fragen ‒ Welche Werte möchten wir uns im Team

Diese Fragen dienen der Rückmeldung zur geben?
Zusammenarbeit. ‒ Denken Sie, dass die Zusammenarbeit
zwischen unseren Firmen sich im letzten
Jahr verbessert hat?
17.7 Feedback geben — Feedback nehmen,

was heißt das genau?
Der englische Begriff Feedback wäre direkt übersetzt „Rückmeldung“. Dies trifft
es aber nicht wirklich. Die Rückmeldung unterliegt bestimmten Spielregeln mit
dem Ziel, dem Feedback-Nehmer eine Rückmeldung über das Wirken seiner
Aussage, seines Auftretens oder aber auch seines Handelns auf den Feedback-
Geber zu geben. Beim Feedback geht es darum, Einfluss zu nehmen auf das zu-
künftige Verhalten. Im Projekt ist Feedback ein hilfreiches Instrument zur Steue-
rung des Teams. Es ist bei der Delegation von Arbeitspaketen genauso wichtig
wie bei der Führung von Einzelpersonen.
Feedback kann sowohl positiv als auch negativ (= Kritikgespräch) sein. Feedback
will beiden Parteien helfen, zusammen besser zu werden, und sollte daher kon-
struktiv genutzt werden. Dabei gibt es ein paar Spielregeln die unterstützen sol-
len, dass das Feedback nicht verletzend, sondern hilfreich für beide Seiten ist.
Abbildung 17.2 Feedback
Checkliste – Halte ich die Spielregeln ein?
Für den Feedback-Geber Ja / Nein
Ist mein Feedback auf ein Verhalten bezogen?
Bleibe ich bei einer Wahrnehmung?
Greife ich die Person an oder bleibt es bei einer Kritik an der Handlung?
Ist das Feedback sachlich?
Ist das Feedback erwünscht?
Ist das Feedback ein „Vier-Augen“-Gespräch?
Ist das Feedback wertschätzend?
Ist das Feedback zeitnah?
Ist mein Feedback wertschätzend?
Für den Feedback-Nehmer Ja / Nein
Lasse ich den Feedback-Geber ausreden?
Kann ich es unterlassen, mich zu recht-fertigen?
Ist das Feedback für mich hilfreich?
Kann ich die Beschreibung nachvollziehen?
Hilft mir das Feedback, mich weiter zu entwickeln?

Literatur 247
Literatur
Adair, John: Develop your Leadership Skills, 3. Auflage, Kogan Page 2016
Andler, Nicolai : Tools für Projektmanagement Workshops und Consulting, Publicis Publi-
shing, 3. Auflage, 2010
Angermeier, Georg: Projektmagazin, Artikel unter https://www.projektmagazin.de/autor/
dr-georg-angermeier
BME-Service „Personal & Karriere“ & BME-Initiative „Young Professionals“: BME-Leitfa-
den „Karriere im Einkauf“, BME e. V. 2012; online unter https://shop.bme.de/products/bme-
leitfaden-karriere-im-einkauf-7d56aaa0-1bea-4e47-b806-3275b244c576
Büsch, Mario : Praxishandbuch strategischer Einkauf, Springer Gabler, 3. Auflage 2013
Dätsch, Christiane (Hrsg.): Kulturelle Übersetzer: Kunst und Kulturmanagement im trans-
kulturellen Kontext, Edition Kulturwissenschaft, transcript Verlag, 2018
Füting, Ulrich Chr./Hahn, Ingo: Projectcontrolling leicht gemacht. Wie hält man Kosten und
Termine ein?, Redline Wirtschaft 2005
Glas, Andreas H. und Kleemann, Florian C. : Einkauf 4.0, Die digitale Transformation in der
Beschaffung, Springer Verlag
Haeske, Udo: Pocket Business. Team- und Konfliktmanagement: Teams erfolgreich führen –
Konflikte konstruktiv lösen, Cornelsen 2002
Hall, Edward T.: The hidden dimension, Garden City 1966.
Harris, Thomas A.: Ich bin o.k. – Du bist o.k. Wie wir uns selbst besser verstehen und unse-
re Einstellung zu anderen verändern können. Eine Einführung in die Transaktionsanalyse,
Rowohlt, 2007
Heller, Robert: Communicate Clearly, Dorling Kindersley 1998
Henke, Prof. Dr. Michael, Vorstudie Einkauf 4.o – Digitalisierung im Einkauf, Fraunhofer
Institut IML und BME e.V, 2016
Hobbs, Peter: Professionelles Projektmanagement, MVG 1999
Hoffmann, Hans-Erland, Schoper, Yvonne Gabriele & Conor, John Fitzsimons: Internationa-
les Projektmangement – interkulturelle Zusammenarbeit in der Praxis
Hoffmann, Hans-Erland/Schoper, Yvonne-Gabriele/Fitzsimons, Conor John: Internationales
Projektmanagement. Interkulturelle Zusammenarbeit in der Praxis, Beck-Wirtschafts-
berater, dtv 2004
Hofstede, Geert/Hofstede, Gert Jan: Lokales Denken, globales Handeln: Interkulturelle
Zusammenarbeit und globales Management, 2. Auflage, Beck-Wirtschaftsberater, dtv 2001
Intercultural Network, Einführung in die interkulturelle Kommunikation, http://www.inter
cultural-network.de/, 1.6.2020
Kellner, Hedwig: Konflikte verstehen, verhindern, lösen – Konfliktmanagement für Füh-
rungskräfte, Hanser 2000
Kellner, Hedwig: Projekte Konfliktfrei führen: Wie Sie ein erfolgreiches Team aufbauen,
Hanser 2000
https://doi.org/10.1007/978-3-658-31310-4
248 Literatur
Kunhardt, Jon K.G., Kommunikation, Motivation und kulturelle Prägung, Denk-, Hand-
lungs- und Verhaltensmuster einer globalisierten Welt. Kulturelle Missverständnisse, Im-
plizite Motive, Kulturdimensionen – April 2017, independend published
Kursay-Merkle, Ursula: Agiles Projektmanagement im Berufsalltag, Springer Gabler, 2018
Laufer, Harmut: Grundlagen erfolgreicher Mitarbeiterführung. Führungspersönlichkeit,
Führungsmethoden, Führungsinstrumente, GABAL 2007
Madauss, Bernd J.: Handbuch Projektmanagement, 5. Auflage, Schäffer-Poeschel 1994
Malik, Fredmund: Führen, Leisten, Leben. Wirksames Management für eine neue Welt,
Campus 2006
Maslow, Abraham H: A Theory of Human Motivation, in: Psychological Review, Vol. 50,
No. 4 July 1943, S.370–396
Mattock, John: Cross-cultural Business, Management Pocket Books 2006
Nagel, Gerhard: Wagnis Führung. 365 Tage aus dem Leben eines Change-Managers, Han-
ser 1999
Niermeyer, Rainer: Teamarbeit. Führen und Erfolge sichern, 2. Auflage, Haufe 2008
Ottmann, Roland: Der nackte Projektmanager, 3. Auflage, Ottmann & Partner 2005
Pinnow, Daniel F.: Führen: Worauf es wirklich ankommt, Gabler 2005
PMBOK: A Guide to the Project Management Body of Knowledge, Fourth Edition, PMI
Global Standard 2008
Preußig, Jörg: Agiles Projektmanagement, Scrum, Use Cases, Task Boards & Co., Haufe
Robbins, Stephen P.: The Truth about Managing People, business management, Kanada an
imprint of Person Eduation
Robbins, Stephen P.: The Truth about Managing People, FT Press 2003
Rosenau jr., Milton D./Githens, Gegory D.: Successful Project Management: A Step-by-Step
Approach with Practical Examples, Fourth Edition, Wiley 2011
Schelle, Heinz: Entwicklungsgeschichte und Trends im Projektmanagement, in: Nino Grau,
Reinhard Wagner (Hg.): Basiswissen Projektmanagement – Grundlagen der Projektarbeit,
Symposium 2013, S. 109–123
Schmidtke, Birgit: Vortrag Kulturmodelle, ProScientia Linz 12.03.2015
Schulz von Thun, Friedemann: Miteinander reden 4: Fragen und Antworten, Rowohlt 2007
Sutherland, Jeff und Schwaber, Ken: The official Scrum Guide, Scrum.org
Timinger, Holger: Modernes Projektmanagement, Mit traditionellem und agilem Projekt-
management zum Erfolg, Wiley-VCH Verlag
True Care GmbH: Projektmanagement-Handbuch online,
http://www.projektmanagementhandbuch.de/
Tuckman, Bruce Wayne/Jensen, Mary Ann C.: Stages of small group development revisited,
in: Group and Organizational Studies, 2/1977, S. 419-427
Tuckman, Bruce Wayne: Developmental sequences in small groups, in: Psychological Bulle-
tin, 63/1965, S.348–399
Vigenschow, Uwe und Grass, Andrea: Agiles Projektmanagement: Anspruchsvolle Soft-
wareprojekte erfolgreich führen, dpunkt.verlag, 2017
Literatur 249
Wirdemann, Ralf: Scrum mit User Stories, Hanser

Young, Trevor: 30 Minuten bis zum erfolgreichen Projektmanagement, Gabal 2000
Ziegler, Michael: Agiles Projektmanagement mit Scrum, Wolf Digital GmbH, 3. Auflage
2020

Projektmanagement Im Einkauf

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Projektmanagement Im Einkauf

Hochgeladen von

Copyright:

Verfügbare Formate

Kerstin Hillberg

ISBN 978-3-658-31309-8 ISBN 978-3-658-31310-4 (eBook)

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen National­

1 Warum dieses Buch? .............................................................................................. 11

2 Projektmanagement – Was ist das eigentlich?................................................... 13

3 Entwicklung der Anforderungen im Einkauf und die Notwendigkeit

3.1 Die Rolle des Einkaufs im Unternehmen .................................................... 23

4 Voraussetzungen für Projektarbeit im Einkauf ................................................ 29

4.1 Wodurch werden Projekte gekennzeichnet, oder wann machen

5.1 Projektantrag ................................................................................................... 44

5.5.4 Terminplan als Beispiel-Berechnung von zehn

6 Globalisierung … ................................................................................................. 113

6.1 Historie und Entwicklung Globalisierung ................................................ 115

7 Risiken der Globalisierung und durch die Corona-Krise ............................. 137

7.1 Die andere Seite der Medaille ..................................................................... 137

8 Die Analyse des globalen Marktes .................................................................... 139

9 Kulturelle Herausforderungen im globalen Umfeld ..................................... 143

9.1 Was betrachten wir als Kultur? .................................................................. 144

10 Agiles Projektmanagement ................................................................................. 159

10.1 Die Bausteine des agilen Projektmanagements ........................................ 161

11 Führung in agilen Projekten ............................................................................... 179

11.1 Die Kommunikation im agilen Projektmanagement ............................... 180

12 Digitalisierung oder Einkauf 4.0 ........................................................................ 183

13 Führung im Projekt .............................................................................................. 189

13.1 Was ist Führung? .......................................................................................... 189

14 Was macht Teamarbeit erfolgreich? .................................................................. 209

14.1 Der Projektleiter und die menschliche Seite ............................................. 209

15 Projektherausforderung im internationalen Umfeld — Why culture

16 Steuerung von Projekten ..................................................................................... 225

16.1 Steuerung des Projektes Kosten- und Terminplan .................................. 228

17 Kommunikation im Projekt und Austausch von Informationen ................. 235

17.1 Austausch von Informationen .................................................................... 235

17.2 Auswahl der Kommunikationsmethode ................................................... 237

Literatur ........................................................................................................................ 247

1 Warum dieses Buch?

Aus meiner 30-jährigen Erfahrung im Projektgeschäft, basierend auf den nationa-

In einfacher Reihenfolge geplant und dokumentiert, als Basisplan verankert,

So ist dieses Buch entstanden mit dem Ziel, Projektmanagern in Einkaufsprojek-

2 Projektmanagement – Was ist

■ Was ist in meinem Unternehmen ein Projekt?

Projektmanagement ist eine Sonderorganisation, die parallel zur bestehenden

■ Für welchen Umfang des Projektes bin ich verantwortlich?

Abbildung 2.1 Beispiel Hierarchiestufen

Wegbereiter für das Projektmanagement waren militärische Programme und

■ Welchen Input benötigen wir?

Abbildung 2.2 Zeitliche Einsparungen im Produktentstehungsprozess durch

In Abbildung 2.2 wird dargestellt, wie sich der Produktentstehungsprozess in

Was kommt zuerst, was folgt danach?

Durch die zunehmende Vernetzung der Arbeitswelt, Globalisierung und eine

Permanente Veränderungsprozesse über alle Ebenen eines Unternehmens müssen

Um dem Anspruch und den notwendigen Aufgaben im Einkauf gerecht werden

Abbildung 2.3 Beispiel eines cross-funktionalen Teams im Einkauf mit seinen

Einer der entscheidenden Erfolgsfaktoren im Projektmanagement ist die klare

■ die Aufgabe, die es zu erledigen gilt,

Viele Einkaufsprojekte werden im internationalen Umfeld durchgeführt. Dies

Historie und Entwicklung des Projektmanagements

Schon beim Pyramidenbau muss eine Form des Projektmanagements funktioniert

Über Jahrzehnte schufteten Zehntausende von Steinmetzen, Tagelöhnern und

■ Wie integriere ich Stakeholder?

Zur jüngeren Geschichte des Projektmanagements gehören große Infrastruktur-

So wurden in den 1980er-Jahren etwa bei Automobilherstellern noch weitestge-

Projektmanagement ist eine Veränderung der Linienfunktion in einen Prozess!

Dies setzt voraus, dass gut funktionierende sogenannte „cross-funktionale

Die Projektmanagementorganisation benötigt eigene Rollen, Funktionen und

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen National