Projektmanagement für Ingenieure: Ein praxisnahes Lehrbuch für den systematischen Projekterfolg [5 ed.] 3658327901, 9783658327903

Table of contents :
Vorwort
Abkürzungsverzeichnis
Inhaltsverzeichnis
Verzeichnis der Beispiele
Abbildungsverzeichnis
Tabellenverzeichnis
1 Projekte
1.1 Definitionen
1.2 Systeme und Prozesse
1.3 Projektmanagement
1.4 Weiterführende Literatur
2 Projekte als Problemlösungsprozesse
2.1 Modelle des Problemlösens
2.2 Methoden und Werkzeuge zur Problemanalyse
2.3 Methoden und Werkzeuge zur Erstellung eines Zielsystems
2.4 Lösungssynthese
2.5 Lösungsauswahl
2.6 Weiterführende Literatur
3 Projektgründung
3.1 Die Projektinitiierung
3.2 Der Projektauftrag
3.3 Projektkalkulation
3.4 Weiterführende Literatur
4 Projektorganisation
4.1 Aufbauorganisation
4.2 Ablauforganisation
4.3 Organisation der Informationsflüsse
4.4 Das Projektmanagement-Handbuch
5 Strukturplanung
5.1 Produktstrukturplanung
5.2 Projektstrukturplanung
5.3 Vorgänge festlegen
6 Projektschätzung
6.1 Methodische Grundlagen des Schätzens
6.2 Mathematische Grundlagen des Schätzens
6.3 Schätzung der Projektdauer
6.4 Schätzung des Aufwands bei Software-Systemen
6.5 Weiterführende Literatur
7 Ablauf- und Terminplanung
7.1 Ablaufmodelle
7.2 Planungsmethoden
7.3 Kapazitätsplanung
7.4 Weiterführende Literatur
8 Risikomanagement
8.1 Projektrisiko
8.2 Der Risikomanagement-Prozess
9 Kostenmanagement
9.1 Kosten
9.2 Kostenplanung in Projekten
9.3 Kostencontrolling mittels Earned Value Analyse
9.4 Weiterführende Literatur
10 Qualitätsmanagement
10.1 Qualität
10.2 Qualitätsmanagementsysteme
10.3 Qualitätsorientierte Managementkonzepte (QoM)
10.4 Qualitätsmanagement in Projekten
10.5 Weiterführende Literatur
11 Projektsteuerung
11.1 Projektüberwachung
11.2 Projektlenkung
11.3 Projektabschluss
11.4 Weiterführende Literatur
12 Der Mensch im Projekt
12.1 Selbstmanagement
12.2 Projektleiter
12.3 Projektteams
13 Software-Werkzeuge
13.1 Software-Werkzeuge im Projektmanagement
13.2 Office-Werkzeuge im Projektmanagement
13.3 MS-Project: Schnelleinstieg
13.4 Weiterführende Literatur
14 Agiles Projektmanagement
14.1 Agilität
14.2 Aufbauorganisation mit Scrum-Rollen
14.3 Ablauf- und Informationsorganisation in Sprints
14.4 Klassisch, agil oder hybrid?
A1 Formulare
A2 Landkarte der PM-Prozesse und -Dokumente
A2 Glossar
Literatur
Stichwortverzeichnis

Citation preview

Walter Jakoby

Projektmanagement für Ingenieure Ein praxisnahes Lehrbuch für den systematischen Projekterfolg 5. Auflage

Projektmanagement für Ingenieure

Walter Jakoby

Projektmanagement für Ingenieure Ein praxisnahes Lehrbuch für den systematischen Projekterfolg 5., überarbeitete und aktualisierte Auflage

Walter Jakoby Hochschule Trier Trier, Deutschland

ISBN 978-3-658-32790-3 https://doi.org/10.1007/978-3-658-32791-0

ISBN 978-3-658-32791-0 (eBook)

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Vieweg © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2010, 2013, 2015, 2019, 2021 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 Informationen 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 Vieweg 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

Vorwort

Die Arbeitswelt vollzieht heute in vielen Bereichen einen rasanten Wandel, der geprägt ist durch die Digitalisierung der Arbeitsmittel und durch die Vernetzung der Arbeitsabläufe über fachliche und räumliche Grenzen hinweg. Die Arbeitsprozesse stehen dabei nach wie vor unter Qualitäts-, Termin- und Kostendruck, so dass die Arbeit in Projektform immer wichtiger wird und in vielen Bereichen bereits zur dominierenden Arbeitsform geworden ist. Parallel dazu entwickelt sich auch das Projektmanagement (PM) weiter. Die klassischen PM-Methoden haben einen hohen Reifegrad erreicht, der in Normen und Standards zum Ausdruck kommt. Gleichzeitig kommen neue, schlanke und agile Methoden zum Einsatz. Es hat sich dabei erwiesen, dass PM nicht so sehr ein „monumentales“, abgeschlossenes System ist, sondern ein Werkzeugkasten von vielen verschiedenen, aber zusammenwirkenden Methoden, aus denen je nach Projektprofil die am besten passenden ausgewählt werden. Die vorliegende 5. Auflage dieses Lehrbuchs trägt diesen Entwicklungen Rechnung, indem die bestehenden Kapitel verschlankt und durch ein neues Kapitel zum Thema agiles PM ergänzt wurden. Jedes Kapitel beschreibt die Aufgaben, die im Lebenszyklus eines Projekts entstehen und stellt die Methoden und Werkzeuge vor, die für deren Lösungen geeignet sind. Ergänzend zum Buch werden verschiedene Materialien zur Verfügung gestellt. Eine kompakte Zusammenfassung, Verständnisfragen und Übungsaufgaben sowie ein vollständiges Projektbeispiel bietet das „Intensivtraining Projektmanagement“, das nun in 3. Auflage vorliegt. Auf meinem Blog (www.ie-j.de/PM.htm) stehen Bilder, Tabellen, Formulare und Checklisten zum Download bereit. Dozenten können auf Anfrage ([email protected]) außerdem einen vollständigen, frei editierbaren Foliensatz erhalten. Trier im Oktober 2020

Walter Jakoby

V

Abkürzungsverzeichnis

A a b c C Di E F(x) FAi FEi Fi FP GP I(t) L M

Aufwand kleinster bzw. optimistischer Schätzwert größter bzw. pessimistischer Schätzwert wahrscheinlichster bzw. realistischer Schätzwert Konstante Dauer des Vorgang i Erwartungswert einer Verteilungsfunktion Verteilungsfunktion einer Zufallsvariablen Frühester Anfangstermin für den Vorgang i Frühester Endtermin für den Vorgang i Frühester Termin für ein Ereignis i Freier Puffer Gesamtpuffer Ist-Verlauf Länge (z. B. eines Programms) Median einer Verteilungsfunktion, bzw. Maßnahmen-Szenario (zur Risikovermeidung) P Zeitlicher Puffer PT Personentag PM Personenmonat (1 PM = 20 PT) PJ Personenjahr (1 PJ = 11 PM = 220 PT) P(t) Plan-Verlauf p(x) Wahrscheinlichkeitsdichtefunktion einer Zufallsvariablen R Risiko S Standardabweichung einer Verteilungsfunktion SAi Spätester Anfangstermin für den Vorgang i SEi Spätester Endtermin für den Vorgang i Spätester Termin für ein Ereignis i, bzw. Schadensausmaß Si T Zeitdauer To Zeitdauer, optimistisch geschätzt Tp Zeitdauer, pessimistisch geschätzt VII

VIII

Tw Te Ts V W X x

Abkürzungsverzeichnis

Zeitdauer, wahrscheinlichster Wert Zeitdauer, Erwartungswert Zeitdauer, Standardabweichung Varianz einer Verteilungsfunktion wahrscheinlichster Wert einer Verteilungsfunktion Zufallsvariable Wert einer Variablen

Inhaltsverzeichnis

1

Projekte . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Definitionen . . . . . . . . . . . . . . . . . . . 1.1.1 Projektbeispiele . . . . . . . . . . . . 1.1.2 Abgrenzung von Nicht-Projekten . 1.1.3 Klassifizierung von Projekten . . . 1.2 Systeme und Prozesse . . . . . . . . . . . . 1.2.1 Systemdefinition . . . . . . . . . . . 1.2.2 Projekte aus Systemsicht . . . . . . 1.2.3 Probleme . . . . . . . . . . . . . . . . 1.2.4 Prozesse . . . . . . . . . . . . . . . . 1.3 Projektmanagement . . . . . . . . . . . . . . 1.3.1 Der Projektmanagement-Prozess . 1.3.2 Entwicklung des Fachgebiets . . . . 1.3.3 Normen, Standards, Zertifizierung 1.3.4 Vorgehensmodelle . . . . . . . . . . 1.3.5 Fallbeispiele . . . . . . . . . . . . . . 1.3.6 Gliederung des Buchs . . . . . . . . 1.4 Weiterführende Literatur . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

1 2 2 3 7 11 11 13 15 18 20 20 24 25 27 29 31 32

2

Projekte als Problemlösungsprozesse . . . . . . . . . . . . . . . . 2.1 Modelle des Problemlösens . . . . . . . . . . . . . . . . . . . . 2.1.1 Vorgehensmodelle des Problemlösens . . . . . . . . . 2.1.2 Der allgemeine Problemlösungsprozess . . . . . . . . 2.1.3 Vorgehensmodelle der Projektdurchführung . . . . . . 2.1.4 Vorgehensmodelle für gemanagte Projekte . . . . . . 2.2 Methoden und Werkzeuge zur Problemanalyse . . . . . . . . 2.2.1 Problemerkennung . . . . . . . . . . . . . . . . . . . . . 2.2.2 Problemstrukturierung . . . . . . . . . . . . . . . . . . . 2.3 Methoden und Werkzeuge zur Erstellung eines Zielsystems 2.3.1 Von der Zielwolke zum Zielsystem . . . . . . . . . . . 2.3.2 Zielvorstellungen erfassen . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

33 34 34 37 40 42 43 43 45 47 47 49 IX

X

Inhaltsverzeichnis

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

51 53 57 57 59 65 65 67 70

3

Projektgründung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Die Projektinitiierung . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Zustandekommen von Projekten . . . . . . . . . . . . . 3.1.2 Ein Projekt definieren . . . . . . . . . . . . . . . . . . . 3.1.3 Stakeholder und Projektumfeld analysieren . . . . . . 3.1.4 Anforderungen erfassen . . . . . . . . . . . . . . . . . . 3.2 Der Projektauftrag . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Bedeutung und Inhalt des Projektauftrags . . . . . . . 3.2.2 Auftragsdokumente . . . . . . . . . . . . . . . . . . . . . 3.2.3 Formale Anforderungen . . . . . . . . . . . . . . . . . . 3.2.4 Lastenheft und Pflichtenheft . . . . . . . . . . . . . . . 3.2.5 Inhalt und Gliederung von Lasten- und Pflichtenheft 3.3 Projektkalkulation . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Das Aufwands-Auftrags-Dilemma . . . . . . . . . . . 3.3.2 Mögliche Lösungen . . . . . . . . . . . . . . . . . . . . 3.4 Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

71 72 72 73 76 78 81 81 83 86 87 88 90 90 92 93

4

Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Aufbauorganisation . . . . . . . . . . . . . . . . . . . . . 4.1.1 Linienorganisation von Unternehmen . . . . . . 4.1.2 Formen der Aufbauorganisation . . . . . . . . . 4.1.3 Auswahlkriterien für die Organisationsform . . 4.1.4 Projektbeteiligte . . . . . . . . . . . . . . . . . . . 4.2 Ablauforganisation . . . . . . . . . . . . . . . . . . . . . 4.2.1 Teilprozesse eines Projekts . . . . . . . . . . . . 4.2.2 Phasen und Meilensteine . . . . . . . . . . . . . 4.2.3 Standard-Ablaufstrukturen . . . . . . . . . . . . 4.2.4 Varianten von Ablaufstrukturen . . . . . . . . . 4.3 Organisation der Informationsflüsse . . . . . . . . . . . 4.3.1 Information, Kommunikation, Dokumentation 4.3.2 Informationsmanagement . . . . . . . . . . . . . 4.3.3 Informationsmanagement im Projekt . . . . . . 4.4 Das Projektmanagement-Handbuch . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

95 96 97 98 103 105 107 107 109 111 116 121 121 123 124 128

2.4

2.5

2.6

2.3.3 Ziele formulieren . . . . . . . . . . . . . . . 2.3.4 Zielsystem erstellen . . . . . . . . . . . . . Lösungssynthese . . . . . . . . . . . . . . . . . . . . 2.4.1 Bedingungen der Ideenfindung . . . . . . . 2.4.2 Methoden der Ideenfindung . . . . . . . . . Lösungsauswahl . . . . . . . . . . . . . . . . . . . . 2.5.1 Intuitive und qualitative Entscheidungen . 2.5.2 Analytische Entscheidungsverfahren . . . Weiterführende Literatur . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

Inhaltsverzeichnis

XI

5

Strukturplanung . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Produktstrukturplanung . . . . . . . . . . . . . . . . . . 5.1.1 Der Produktstrukturplan . . . . . . . . . . . . . 5.1.2 Zusammensetzung des Produktstrukturplans 5.1.3 Vorgehensweise zur Planerstellung . . . . . . 5.2 Projektstrukturplanung . . . . . . . . . . . . . . . . . . 5.2.1 Der Projektstrukturplan . . . . . . . . . . . . . 5.2.2 Produktorientierte Gliederung . . . . . . . . . 5.2.3 Prozessorientierte Gliederung . . . . . . . . . 5.2.4 Standard-Projektstrukturpläne . . . . . . . . . 5.3 Vorgänge festlegen . . . . . . . . . . . . . . . . . . . . 5.3.1 Arbeitspakete beschreiben . . . . . . . . . . . 5.3.2 Vorgänge definieren . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

131 132 132 135 137 140 140 141 142 145 148 148 150

6

Projektschätzung . . . . . . . . . . . . . . . . . . . . . . 6.1 Methodische Grundlagen des Schätzens . . . . . 6.1.1 Ziel des Schätzens . . . . . . . . . . . . . . 6.1.2 Schätzmethoden . . . . . . . . . . . . . . . . 6.1.3 Bedingungen des Schätzens . . . . . . . . 6.2 Mathematische Grundlagen des Schätzens . . . . 6.2.1 Wahrscheinlichkeitsrechnung . . . . . . . . 6.2.2 Verteilungsfunktionen . . . . . . . . . . . . 6.2.3 Zwei- und Dreipunktschätzung . . . . . . 6.3 Schätzung der Projektdauer . . . . . . . . . . . . . 6.4 Schätzung des Aufwands bei Software-Systemen 6.5 Weiterführende Literatur . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

153 154 154 157 162 164 164 166 169 172 173 176

7

Ablauf- und Terminplanung . . . . . 7.1 Ablaufmodelle . . . . . . . . . . . 7.1.1 Anordnungsbeziehungen 7.1.2 Netzpläne . . . . . . . . . . 7.2 Planungsmethoden . . . . . . . . 7.2.1 Critical-Path-Method . . . 7.2.2 Metra-Potential-Methode 7.2.3 PERT-Methode . . . . . . 7.2.4 Gantt-Diagramme . . . . . 7.3 Kapazitätsplanung . . . . . . . . . 7.4 Weiterführende Literatur . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

177 178 178 181 185 186 187 189 192 195 201

8

Risikomanagement . . . . . . . . . . . . . 8.1 Projektrisiko . . . . . . . . . . . . . . 8.1.1 Unsicherheiten in Projekten 8.1.2 Der Risikobegriff . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

203 204 204 205

. . . . . . . . . . .

XII

Inhaltsverzeichnis

8.2

Der Risikomanagement-Prozess 8.2.1 Risiko-Identifikation . . . 8.2.2 Risiko-Bewertung . . . . . 8.2.3 Risiko-Behandlung . . . . 8.2.4 Risiko-Überwachung . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

206 206 210 213 217

9

Kostenmanagement . . . . . . . . . . . . . . . . . . . . . . 9.1 Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1 Grundbegriffe der Kostenrechnung . . . . . 9.1.2 Arbeitskosten . . . . . . . . . . . . . . . . . . 9.2 Kostenplanung in Projekten . . . . . . . . . . . . . . 9.2.1 Projektkalkulation . . . . . . . . . . . . . . . 9.2.2 Kostenverteilung . . . . . . . . . . . . . . . . 9.3 Kostencontrolling mittels Earned Value Analyse . 9.3.1 Aufgabe und Ziele des Kostencontrollings . 9.3.2 Ermittlung der Istwerte . . . . . . . . . . . . 9.3.3 Analyse von Plan-, Ist- und Sollzahlen . . . 9.4 Weiterführende Literatur . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

221 222 222 223 226 227 228 230 230 231 233 236

10

Qualitätsmanagement . . . . . . . . . . . . . . . . . . . . 10.1 Qualität . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.1 Definition des Qualitätsbegriffs . . . . . . . 10.1.2 Sichtweisen der Qualität . . . . . . . . . . . . 10.1.3 Entwicklung des Fachgebiets . . . . . . . . . 10.1.4 Bedarf an Projekt-QM . . . . . . . . . . . . . 10.2 Qualitätsmanagementsysteme . . . . . . . . . . . . . 10.2.1 Die Normenfamilie ISO 9000 ff . . . . . . . 10.2.2 Grundsätze der ISO 9000 . . . . . . . . . . . 10.2.3 Das QM-Prozessmodell . . . . . . . . . . . . 10.3 Qualitätsorientierte Managementkonzepte (QoM) 10.3.1 Total Quality Management . . . . . . . . . . 10.3.2 Lean Management . . . . . . . . . . . . . . . 10.3.3 Kontinuierliche Verbesserung . . . . . . . . 10.3.4 Reifegradmodelle . . . . . . . . . . . . . . . . 10.4 Qualitätsmanagement in Projekten . . . . . . . . . . 10.4.1 QM-Prozesse in Projekten . . . . . . . . . . 10.4.2 Qualitätsplanung . . . . . . . . . . . . . . . . 10.4.3 Qualitätslenkung . . . . . . . . . . . . . . . . 10.4.4 Qualitätssicherung . . . . . . . . . . . . . . . 10.5 Weiterführende Literatur . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

237 238 238 240 242 244 245 245 246 247 250 250 253 254 256 258 258 260 262 266 268

Inhaltsverzeichnis

XIII

11

Projektsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Projektüberwachung . . . . . . . . . . . . . . . . . . . . . 11.1.1 Projektdatenerfassung . . . . . . . . . . . . . . . . 11.1.2 Projektdatenauswertung . . . . . . . . . . . . . . . 11.1.3 Fortschrittsplanung . . . . . . . . . . . . . . . . . . 11.1.4 Meilenstein-Trendanalyse . . . . . . . . . . . . . . 11.2 Projektlenkung . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.1 Fortschrittssteuerung . . . . . . . . . . . . . . . . . 11.2.2 Änderungsmanagement . . . . . . . . . . . . . . . 11.3 Projektabschluss . . . . . . . . . . . . . . . . . . . . . . . . 11.3.1 Wozu ein Projektabschluss? . . . . . . . . . . . . 11.3.2 Abnahme des Projektergebnisses . . . . . . . . . 11.3.3 Der richtige Zeitpunkt für den Projektabschluss 11.3.4 Erkenntnissicherung . . . . . . . . . . . . . . . . . 11.3.5 Projektauflösung . . . . . . . . . . . . . . . . . . . 11.4 Weiterführende Literatur . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

269 270 271 276 279 285 290 290 292 294 294 296 299 301 302 304

12

Der Mensch im Projekt . . . . . . . . . . . . . . 12.1 Selbstmanagement . . . . . . . . . . . . . . . 12.1.1 Aufgaben des Selbstmanagements . 12.1.2 Methoden des effizienten Arbeitens 12.1.3 Umgang mit Stress . . . . . . . . . . 12.2 Projektleiter . . . . . . . . . . . . . . . . . . . 12.2.1 Aufgaben eines Projektleiters . . . 12.2.2 Anforderungen an Projektleiter . . 12.2.3 Führungsstile . . . . . . . . . . . . . 12.3 Projektteams . . . . . . . . . . . . . . . . . . 12.3.1 Teambildung . . . . . . . . . . . . . . 12.3.2 Personalauswahl . . . . . . . . . . . 12.3.3 Team-Entwicklungsphasen . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

305 306 306 307 311 314 314 318 320 322 322 324 327

13

Software-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.1 Software-Werkzeuge im Projektmanagement . . . . . . . . . . . . . . . 13.1.1 Einordnung der PM-Software-Werkzeuge . . . . . . . . . . . . . 13.1.2 Anforderungen an PM-Software-Werkzeuge . . . . . . . . . . . 13.1.3 Der Markt für PM-Software . . . . . . . . . . . . . . . . . . . . . 13.2 Office-Werkzeuge im Projektmanagement . . . . . . . . . . . . . . . . . 13.2.1 Einsatzbereiche von Office-Werkzeugen . . . . . . . . . . . . . . 13.2.2 Tabellenkalkulation am Beispiel von MS-Excel . . . . . . . . . 13.2.3 Handhabung wichtiger Projektlisten und -pläne mit MS-Excel

. . . . . . . . .

. . . . . . . . .

329 330 330 331 332 333 333 336 338

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

XIV

Inhaltsverzeichnis

13.3 MS-Project: Schnelleinstieg . . . . . . . . . . . . 13.3.1 Die Struktur von MS-Project . . . . . . . 13.3.2 Die Benutzeroberfläche von MS-Project 13.3.3 Vorgangsplanung . . . . . . . . . . . . . . 13.3.4 Ressourcenplanung . . . . . . . . . . . . . 13.3.5 Dateihandhabung . . . . . . . . . . . . . . 13.4 Weiterführende Literatur . . . . . . . . . . . . . . 14

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

343 343 344 347 350 352 353

Agiles Projektmanagement . . . . . . . . . . . . . . . . . . . . . . 14.1 Agilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.1.1 Klassische und agile PM-Modelle . . . . . . . . . . . 14.1.2 Agile Werte und Prinzipien . . . . . . . . . . . . . . . 14.1.3 Lean-Prinzipien . . . . . . . . . . . . . . . . . . . . . . 14.1.4 Scrum-Übersicht . . . . . . . . . . . . . . . . . . . . . 14.2 Aufbauorganisation mit Scrum-Rollen . . . . . . . . . . . . 14.2.1 Product Owner . . . . . . . . . . . . . . . . . . . . . . 14.2.2 Scrum Master . . . . . . . . . . . . . . . . . . . . . . . 14.2.3 Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2.4 Externe Rollen . . . . . . . . . . . . . . . . . . . . . . . 14.3 Ablauf- und Informationsorganisation in Sprints . . . . . . 14.3.1 Anforderungserfassung mit dem Product Backlog . 14.3.2 Grobplanung mit Releases . . . . . . . . . . . . . . . 14.3.3 Ablauf eines Sprints . . . . . . . . . . . . . . . . . . . 14.3.4 Sprint-Vorbereitung und -Planung . . . . . . . . . . . 14.3.5 Sprint-Ausführung . . . . . . . . . . . . . . . . . . . . 14.3.6 Sprint-Review und -Retrospektive . . . . . . . . . . . 14.4 Klassisch, agil oder hybrid? . . . . . . . . . . . . . . . . . . . 14.4.1 Vergleich klassisch und agil organisierter Projekte . 14.4.2 Nutzen agiler Vorgehensweisen . . . . . . . . . . . . 14.4.3 Hybride Vorgehensweisen . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

355 356 356 358 360 361 363 363 364 366 368 368 368 371 373 374 375 377 379 379 381 383

A1 Formulare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 A2 Landkarte der PM-Prozesse und -Dokumente . . . . . . . . . . . . . . . . . . . . 387 A2 Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397 Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401

Verzeichnis der Beispiele

Beispiel 1.1 „Mega“-Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 1.2 „Out-of-time- und Out-of-budget“-Projekte . . . . . . . . . . . . . . . . . Beispiel 1.3 Studium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 1.4 Projektkriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 1.5 Projekt-Kennzahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 1.6 Grillfete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 1.7 Aufgaben, Probleme, Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 1.8 Problemdimensionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 1.9 Das Damen-Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 1.10 Fallbeispiel „Maschinenterminal M4“ . . . . . . . . . . . . . . . . . . . . Beispiel 1.11 Fallbeispiel „Solaranlage“ . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 1.12 Fallbeispiel „CAD-Software“ . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 2.1 Morphologische Methode zur Suche nach neuen Sensoren . . . . . . . . Beispiel 2.2 Apotheken-Lagerfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 2.3 Fallbeispiel „CAD-Software“: Nutzwertanalyse . . . . . . . . . . . . . . . Beispiel 3.1 Fallbeispiel „CAD-Software“: Projektdefinition . . . . . . . . . . . . . . . Beispiel 3.2 Erwartungen und Befürchtungen von Stakeholdern . . . . . . . . . . . . . Beispiel 3.3 Taxifahrt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 3.4 Angebotsgliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 3.5 Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen Beispiel 4.1 Neue Produktionslinie für einen Pizza-Hersteller . . . . . . . . . . . . . . Beispiel 4.1 Fallbeispiel „Solaranlage“: Aufbauorganisation . . . . . . . . . . . . . . . Beispiel 4.2 Aufbauorganisation für ein CRM-Projekt . . . . . . . . . . . . . . . . . . . Beispiel 4.3 Brandmeldezentrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 4.4 Qualitäts-Managementsystem (QMS) . . . . . . . . . . . . . . . . . . . . . Beispiel 4.5 IMV-Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 4.6 Arbeitspakete bei der Entwicklung eines elektrischen Geräts . . . . . . . Beispiel 4.7 Fallbeispiel „Maschinenterminal“: Typische Teilprojekte . . . . . . . . . Beispiel 4.8 Leistungsphasen nach HOAI . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 4.9 Projektplan mit sequentieller und paralleler Bearbeitung . . . . . . . . . Beispiel 4.10 Fallbeispiel „Maschinenterminal“: Simultaneous Engineering . . . . .

2 2 5 6 9 14 15 17 19 30 30 30 61 63 67 74 77 81 85 89 99 101 102 104 105 106 107 108 110 114 114 XV

XVI

Verzeichnis der Beispiele

Beispiel 4.11 DeLorean DMC-12 . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 4.12 Projektinformationen . . . . . . . . . . . . . . . . . . . . . . . Beispiel 4.13 Informationskategorien . . . . . . . . . . . . . . . . . . . . . . Beispiel 4.14 Fallbeispiel „CAD-Software“, Besprechungsbericht . . . . Beispiel 4.15 Zusammensetzung eines PM-Handbuchs . . . . . . . . . . . Beispiel 5.1 Produktstrukturplan Wohnhaus . . . . . . . . . . . . . . . . . . Beispiel 5.2 Standard-Produktstrukturplan mit Gliederungsschlüssel . . . Beispiel 5.3 Fallbeispiel „Maschinenterminal“: Produktstrukturplan . . . Beispiel 5.4 Fallbeispiel „Maschinenterminal“: Projektstrukturplan . . . . Beispiel 5.5 Fallbeispiel „Solaranlage“: Projektstrukturplan . . . . . . . . Beispiel 5.6 Standard-Projektstrukturplan . . . . . . . . . . . . . . . . . . . Beispiel 5.7 Prozessleittechnik-Projekte . . . . . . . . . . . . . . . . . . . . . Beispiel 5.8 Arbeitspaketbeschreibung Beschaffung Solarmodule . . . . . Beispiel 6.1 Landfläche der Erde . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 6.2 Gebäudekostenschätzung . . . . . . . . . . . . . . . . . . . . . . Beispiel 6.3 Kalkulationsschema für Entwicklungskosten . . . . . . . . . . Beispiel 6.4 Fallbeispiel „Solaranlage“: Schätzung des Arbeitsaufwands Beispiel 6.5 Schätzung einer Projektdauer (1) . . . . . . . . . . . . . . . . . Beispiel 6.6 Aussagen über Aufwand und Laufzeit . . . . . . . . . . . . . . Beispiel 6.7 Schätzung einer Projektdauer (2) . . . . . . . . . . . . . . . . . Beispiel 6.8 Aufwandsschätzung in einem Projekt . . . . . . . . . . . . . . Beispiel 6.9 Projektierungs-Software . . . . . . . . . . . . . . . . . . . . . . Beispiel 6.10 Berechnungs-Programm für Transportbahnen . . . . . . . . Beispiel 7.1 Anordnungsbeziehungen . . . . . . . . . . . . . . . . . . . . . . Beispiel 7.2 Temperaturmessbox . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 7.3 Scheinvorgänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 7.4 PERT-Projektanalyse . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 7.5 Kritischer Pfad beim Temperaturmessbox-Projekt . . . . . . Beispiel 7.6 Fallbeispiel „Maschinenterminal M4“: Gantt-Diagramm . . Beispiel 7.7 Prozesssteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 7.8 Kapazitätsplanung . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 8.1 Personalrisiko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 8.2 Risiken bei der Entwicklung einer Elektronikbaugruppe . . . Beispiel 8.3 Projekt-FMEA für das Fallbeispiel Maschinenterminal . . . Beispiel 8.4 Hardware-Entwicklungsprojekt . . . . . . . . . . . . . . . . . . Beispiel 8.5 Personalrisiko in einem Entwicklungsprojekt . . . . . . . . . Beispiel 8.6 Fallbeispiel „CAD-Software“: Risikoportfolio . . . . . . . . . Beispiel 9.1 Stundensatz für Arbeitskosten ermitteln . . . . . . . . . . . . . Beispiel 9.2 Kostenplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 9.3 Ermittlung des Fertigstellungswertes . . . . . . . . . . . . . . . Beispiel 9.4 EVA-Kennzahlen bestimmen (1) . . . . . . . . . . . . . . . . . Beispiel 9.5 EVA-Kennzahlen bestimmen (2) . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

118 121 122 127 129 134 136 138 142 143 146 147 149 156 158 159 161 165 169 170 171 174 175 179 181 184 190 191 193 196 198 205 210 212 215 218 219 224 229 231 234 235

Verzeichnis der Beispiele

Beispiel 10.1 Qualitätsbewertung Fallbeispiel „CAD-System“ . . . . . . Beispiel 10.2 Fallbeispiel „Maschinenterminal“ – Qualitätssichtweisen Beispiel 10.3 Anforderungen für die Entwicklungsplanung . . . . . . . . Beispiel 10.4 Qualitätsplanung für ein Software-Projekt . . . . . . . . . . Beispiel 11.1 Projektstatusberichte . . . . . . . . . . . . . . . . . . . . . . . Beispiel 11.2 Leistungspakete für die Fortschrittsplanung . . . . . . . . . Beispiel 11.3 Fallbeispiel „CAD“: Planung der Kostenbudgets . . . . . . Beispiel 11.4 Meilenstein-Trendanalyse . . . . . . . . . . . . . . . . . . . . Beispiel 11.5 Abnahmeprotokoll . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 11.6 Abschlussphase eines Software-Projekts . . . . . . . . . . . Beispiel 11.7 Fragebogen zur Feststellung der Mitarbeiterzufriedenheit Beispiel 12.1 ALPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel 12.2 Getting Things done (GTD) . . . . . . . . . . . . . . . . . . Beispiel 13.1 Formatierung von Textinhalten in Tabellen . . . . . . . . . Beispiel 13.2 Einfache MS-Excel-Berechnungen . . . . . . . . . . . . . . Beispiel 13.3 Terminplanung mit MS-Excel . . . . . . . . . . . . . . . . . Beispiel 14.1 Aufwandsschätzung und Workload . . . . . . . . . . . . . .

XVII

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

239 241 249 265 272 282 284 285 297 300 302 310 310 335 337 339 372

Abbildungsverzeichnis

Abb. 1.1 Abb. 1.2 Abb. 1.3 Abb. 1.4 Abb. 1.5 Abb. 1.6 Abb. 1.7 Abb. 1.8 Abb. 1.9 Abb. 1.10 Abb. 1.11 Abb. 1.12 Abb. 2.1 Abb. 2.2 Abb. 2.3 Abb. 2.4 Abb. 2.5 Abb. 2.6 Abb. 2.7 Abb. 2.8 Abb. 2.9 Abb. 2.10 Abb. 3.1 Abb. 3.2 Abb. 3.3 Abb. 3.4 Abb. 3.5

Projektmerkmale und typische Problematiken . . . . . . . . . . . . . . . . Klassifizierung von Projekten nach der Projektgröße . . . . . . . . . . . . Externe und interne Sicht der Systemstruktur . . . . . . . . . . . . . . . . Ein Projekt aus Systemsicht . . . . . . . . . . . . . . . . . . . . . . . . . . . Zustandsraummodell des Problemlösungsprozesses . . . . . . . . . . . . Problemdimensionen Aufwand und Nutzen . . . . . . . . . . . . . . . . . Begriffliche Abgrenzung von Projekten, Prozessen, Problemen und Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stetiger Arbeitsfluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zeitlich und inhaltlich abgegrenztes Projekt . . . . . . . . . . . . . . . . . Grundstruktur einer (ungemanagten) Projektdurchführung . . . . . . . . Grobstruktur eines gemanagten Projekts . . . . . . . . . . . . . . . . . . . Zuordnung der Buchkapitel zu den Prozessgruppen der ISO 21500 . . . Systemisches Modell des Problemlösens . . . . . . . . . . . . . . . . . . . Elementare Vorgehensmodelle des Problemlösens . . . . . . . . . . . . . Die Problemlösungsprozesse des spoc-Modells . . . . . . . . . . . . . . . Wasserfallmodell und Simultaneous Engineering als Extremfälle möglicher Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . Iterative Vorgehensmodelle: Spiralmodell (links) und Scrum (rechts) . . Vorgehensmodell für gemanagte Projekte . . . . . . . . . . . . . . . . . . . Ablauf der Zielbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verschiedene Nutzenfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . Screenshot der bewerteten Varianten A bis E . . . . . . . . . . . . . . . . . Screenshot der gewichteten Nutzenfunktionen für die 3 Varianten A, C und D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prozesse der Projektgründung . . . . . . . . . . . . . . . . . . . . . . . . . . Aktivitäten zur Initiierung eines Projekts . . . . . . . . . . . . . . . . . . . Projektdefinition für das Projekt „CAD-Software“ . . . . . . . . . . . . . Anforderungen und Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zieldreieck von Projekten („Magisches“ Projektdreieck) . . . . . . . . .

5 9 11 13 17 18 20 21 21 22 23 31 35 35 38 40 41 42 48 67 68 68 72 73 75 79 81

XIX

XX

Abb. 3.6 Abb. 3.7 Abb. 3.8 Abb. 3.9 Abb. 3.10 Abb. 4.1 Abb. 4.2 Abb. 4.3 Abb. 4.4 Abb. 4.5 Abb. 4.6 Abb. 4.7 Abb. 4.8 Abb. 4.9 Abb. 4.10 Abb. 4.11 Abb. 4.12 Abb. 4.13 Abb. 4.14 Abb. 4.15 Abb. 4.16 Abb. 4.17 Abb. 4.18 Abb. 5.1 Abb. 5.2 Abb. 5.3 Abb. 5.4 Abb. 5.5 Abb. 5.6 Abb. 5.7 Abb. 5.8 Abb. 5.9 Abb. 5.10 Abb. 5.11 Abb. 5.12 Abb. 5.13 Abb. 6.1 Abb. 6.2

Abbildungsverzeichnis

Projektauftrag als Vereinbarung zwischen Auftraggeber und Auftragnehmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bestandteile und Verantwortlichkeitsbereiche des Projektauftrags . . Auftragsdokumente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zusammenhang Schätzaufwand – Schätzgüte . . . . . . . . . . . . . . Vorprojekt und Projektstudie . . . . . . . . . . . . . . . . . . . . . . . . . Prozesse der Projektorganisation . . . . . . . . . . . . . . . . . . . . . . Organigramm eines Unternehmens . . . . . . . . . . . . . . . . . . . . . Reine Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . Matrix-Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . Auftrags-Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . . Einfluss-Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . . . Projektleitung in der Linie . . . . . . . . . . . . . . . . . . . . . . . . . . Abhängigkeit der Organisationsform von Projektgröße und Schnittstellenzahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arbeitspakete, Teilprojekte und Projektphasen . . . . . . . . . . . . . . In Phasen gegliederte Standard-Ablaufstruktur („Wasserfallmodell“) Ablauf mit Simultaneous Engineering . . . . . . . . . . . . . . . . . . . Screenshot eines Projektplans mit sequentieller und parallelisierter Ausführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Projektplan Maschinenterminal M4 . . . . . . . . . . . . . . . . . . . . Modelle für Projekt-Ablaufstrukturen . . . . . . . . . . . . . . . . . . . Projektplan DeLorean DMC12 . . . . . . . . . . . . . . . . . . . . . . . Iterativer Ablauf mit einem Prototyp als Zwischenergebnis . . . . . . Dokumentenarten in einem Projekt . . . . . . . . . . . . . . . . . . . . . Screenshot eines Besprechungsberichts . . . . . . . . . . . . . . . . . . Prozesse der Strukturplanung . . . . . . . . . . . . . . . . . . . . . . . . Graphisch dargestellter Produktstrukturplan . . . . . . . . . . . . . . . Produktstrukturplan in Listenform . . . . . . . . . . . . . . . . . . . . . Produktstrukturplan Wohnhaus (Auszug) . . . . . . . . . . . . . . . . . Standard-Produktstrukturplan . . . . . . . . . . . . . . . . . . . . . . . . Top-down- und Bottom-up-Ansatz zur Strukturierung . . . . . . . . . Produktstrukturplan des Maschinenterminals . . . . . . . . . . . . . . Einordnung des Projektstrukturplans im Projektablauf . . . . . . . . . Projektstrukturplan Maschinenterminal . . . . . . . . . . . . . . . . . . Projektstrukturplan der Solaranlage . . . . . . . . . . . . . . . . . . . . Zuordnung der Arbeitspakete zu den Projektbeteiligten . . . . . . . . Standard-Projektstrukturplan für die Entwicklung elektronischer Steuerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AP-Beschreibung Beschaffung Solarmodule . . . . . . . . . . . . . . . Gewinnung von Aussagen aus verfügbaren Informationen . . . . . . Qualitative Schätzung des Projektaufwands durch Vergleich . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

82 82 84 91 93 96 97 99 100 101 101 102

. . . .

. . . .

104 110 113 114

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

115 116 118 119 120 125 128 132 133 133 134 137 139 139 141 143 144 146

. . . .

. . . .

147 150 155 158

Abbildungsverzeichnis

Abb. 6.3 Abb. 6.4 Abb. 6.5 Abb. 6.6 Abb. 6.7 Abb. 6.8 Abb. 6.9 Abb. 6.10 Abb. 6.11 Abb. 7.1 Abb. 7.2 Abb. 7.3 Abb. 7.4 Abb. 7.5 Abb. 7.6 Abb. 7.7 Abb. 7.8 Abb. 7.9 Abb. 7.10 Abb. 7.11 Abb. 7.12 Abb. 7.13 Abb. 7.14 Abb. 7.15 Abb. 7.16 Abb. 7.17 Abb. 7.18 Abb. 7.19 Abb. 7.20 Abb. 7.21 Abb. 7.22 Abb. 7.23 Abb. 7.24 Abb. 7.25 Abb. 8.1 Abb. 8.2 Abb. 8.3 Abb. 8.4 Abb. 8.5 Abb. 9.1 Abb. 9.2

Screenshot des Projektstrukturplans „Solaranlage“ . . . . . . . . . . . . . Zusammenhang Schätzaufwand/Schätzgenauigkeit . . . . . . . . . . . . . Verteilungsfunktion F .x/ und Dichtefunktion p.x/ einer Variablen x . Dichtefunktion der Projektdauer (in Tagen) . . . . . . . . . . . . . . . . . Gleichverteilung (I), Dreieck-Verteilung (II) und Beta-Verteilung (III) . Normalverteilung (Erwartungswert Te, Standardabweichung Ts) . . . . Bestimmung der Wahrscheinlichkeit P .x; z/ bei der Normalverteilung . Projektaufwandsschätzung als Schätzwertsummen . . . . . . . . . . . . . Abhängigkeit der Projektdauer T von der Zahl N der Personen . . . . . Prozesse der Ablauf- und Terminplanung . . . . . . . . . . . . . . . . . . . Anordnungsbeziehungen bei Arbeitspaketen . . . . . . . . . . . . . . . . . Anordnungsbeziehungen in graphischer Darstellung . . . . . . . . . . . . Arbeitspakete für den Aufbau einer Temperaturmessbox . . . . . . . . . Ereignisse und Vorgänge in Netzgraphen . . . . . . . . . . . . . . . . . . . Ablaufplan als Vorgangs-Knoten-Netz für das Beispiel Temperaturmessbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ereignis-Knoten-Netz (EKN)/Vorgangs-Pfeil-Netz (VPN) . . . . . . . . Anordnungsbeziehungen mit Scheinvorgängen . . . . . . . . . . . . . . . Vorgangs-Pfeil-Netz (VPN) mit Scheinvorgängen . . . . . . . . . . . . . . Ereignis-Knoten-Symbol der Critical-Path-Method (CPM) . . . . . . . . Beispiel eines Netzes bei der Critical Path Method . . . . . . . . . . . . . Vorgangs-Knotensymbol der Metra-Potential-Methode . . . . . . . . . . Beispiel eines Netzes bei der Metra-Potential-Methode . . . . . . . . . . Beta-Verteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schätzwerte für den kritischen Pfad des Temperaturmessbox-Projekts . Gantt-Diagramm des Temperaturmessbox-Projekts . . . . . . . . . . . . . Die Arbeiten für die Elektronik-Entwicklung als Tabelle . . . . . . . . . . . . . und als Gantt-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminierter Ablaufplan mit personeller Überlast . . . . . . . . . . . . . . Belastungsdiagramm („Kapazitätsgebirge“) . . . . . . . . . . . . . . . . . Ideale (a) und reale (b) Belastungs-/Auslastungsdiagramme . . . . . . . . Projektplan des Software-Projekts ohne Kapazitätsausgleich . . . . . . . Belastungsdiagramm mit erkennbaren Überlastungen . . . . . . . . . . . Modifizierter Projektplan des Software-Projekts mit Kapazitätsausgleich Belastungsdiagramm mit eingehaltenen Kapazitätsgrenzen . . . . . . . . Prozesse des Risikomanagements . . . . . . . . . . . . . . . . . . . . . . . . Risk-Map: Eintrittswahrscheinlichkeit p, Schadensausmaß S . . . . . . . Screenshot der Maßnahmenbewertung . . . . . . . . . . . . . . . . . . . . . Analyse des Personalrisikos in einem Entwicklungsprojekt . . . . . . . . Risiko-Portfolio für das Fallbeispiel „CAD“ . . . . . . . . . . . . . . . . . Prozesse des Kostenmanagements . . . . . . . . . . . . . . . . . . . . . . . Bestimmung des Sach-/Gemeinkosten-Zuschlags . . . . . . . . . . . . . .

XXI

161 163 164 166 166 167 168 171 172 178 178 180 181 182 183 183 184 184 186 187 188 188 189 192 192 194 194 196 197 197 198 199 200 200 207 211 216 219 220 222 225

XXII

Abb. 9.3 Abb. 9.4 Abb. 9.5

Abb. 9.6 Abb. 9.7 Abb. 10.1 Abb. 10.2 Abb. 10.3 Abb. 10.4 Abb. 10.5 Abb. 10.6 Abb. 10.7 Abb. 10.8 Abb. 11.1 Abb. 11.2 Abb. 11.3 Abb. 11.4 Abb. 11.5 Abb. 11.6 Abb. 11.7 Abb. 11.8 Abb. 11.9 Abb. 11.10 Abb. 11.11 Abb. 11.12 Abb. 11.13 Abb. 11.14 Abb. 11.15 Abb. 11.16 Abb. 11.17 Abb. 11.18 Abb. 11.19 Abb. 11.20 Abb. 11.21 Abb. 11.22 Abb. 11.23 Abb. 12.1 Abb. 12.2

Abbildungsverzeichnis

Bestimmung der produktiven Arbeitsstunden pro Jahr . . . . . . . . . . . Berechnung des Arbeitskosten-Stundensatzes . . . . . . . . . . . . . . . . Kostenverteilung über die Laufzeit und die Teilprojekte (Zahlenangaben in Tsd. C) (PK: Personal-, MK: Material-, ZK: Zukaufkosten, SK: Summe der Kosten) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Earned Value Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vorhersage des weiteren Projektverlaufs . . . . . . . . . . . . . . . . . . . Qualitätsüberprüfung für das Fallbeispiel „CAD-System“ . . . . . . . . . Entwicklungsschritte des Qualitätsmanagement . . . . . . . . . . . . . . . Das QM-Prozessmodell (In Klammern Kapitelnummern der ISO 9001) Grundgedanken des Total Quality Management . . . . . . . . . . . . . . . Problemlösung im Rahmen der kontinuierlichen Verbesserung . . . . . . Prozesse des Qualitätsmanagements . . . . . . . . . . . . . . . . . . . . . . Fragestellungen des House of Quality . . . . . . . . . . . . . . . . . . . . . Kriterien der GPM zur Bewertung der „Project Excellence“ . . . . . . . Prozesse der Projektsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . Gantt-Diagramm eines Beispiel-Projekts . . . . . . . . . . . . . . . . . . . Zieldreieck zur Messung des Projektfortschritts . . . . . . . . . . . . . . . Soll-Istwert-Abweichungen bei Projekten . . . . . . . . . . . . . . . . . . Planung des Projektfortschritts . . . . . . . . . . . . . . . . . . . . . . . . . Richtige Dimensionierung der Leistungspaketgrößen. a vermuteter linearer Verlauf, b tatsächlicher Verlauf, c richtig gewählte Paketgrößen Projektplan SW-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planung der Kostenbudgets . . . . . . . . . . . . . . . . . . . . . . . . . . . Gantt-Diagramm eines kleinen Projekts . . . . . . . . . . . . . . . . . . . . Charakteristische Meilenstein-Trend-Muster . . . . . . . . . . . . . . . . . Meilenstein-Trend-Muster bei (a) zu optimistischer und (b) zu vorsichtiger Schätzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a–d Problematische Meilenstein-Trend-Muster . . . . . . . . . . . . . . . Reaktion auf einen Rückstand im Projektfortschritt . . . . . . . . . . . . . Prozessschritte des Änderungsmanagements . . . . . . . . . . . . . . . . . Beispiel eines genehmigten Änderungsantrags . . . . . . . . . . . . . . . . Aktivitäten des Projektabschlusses . . . . . . . . . . . . . . . . . . . . . . . Projektabnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verlauf der Projektabnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . Kopf-Daten des Abnahmeprotokolls . . . . . . . . . . . . . . . . . . . . . . Abgenommene Leistungen und festgestellte Mängel . . . . . . . . . . . . Abnahmeerklärung des Abnahmeprotokolls . . . . . . . . . . . . . . . . . Beispiel-Ablauf am Projektende . . . . . . . . . . . . . . . . . . . . . . . . Ein Fragebogen zur Mitarbeiter-Befragung . . . . . . . . . . . . . . . . . . Struktur, Arbeitsfluss und Zeitablauf auf der Ebene der Arbeitspakete . Aufteilung und Planung der Arbeitspakete . . . . . . . . . . . . . . . . . .

225 226

229 231 235 240 243 247 251 256 259 261 268 270 272 277 278 280 281 282 283 285 287 288 289 291 292 293 295 297 297 298 298 298 300 303 306 306

Abbildungsverzeichnis

Abb. 13.1 Abb. 13.2 Abb. 13.3 Abb. 13.4 Abb. 13.5 Abb. 13.6 Abb. 13.7 Abb. 13.8 Abb. 13.9 Abb. 13.10 Abb. 13.11 Abb. 13.12 Abb. 13.13 Abb. 13.14 Abb. 13.15 Abb. 13.16 Abb. 14.1 Abb. 14.2 Abb. 14.3 Abb. 14.4 Abb. 14.5 Abb. A.1 Abb. A.2

Einordnung von Projektmanagement-Software-Werkzeugen . . Nutzung der Rechenfunktionen für Zelleninhalte . . . . . . . . . Tabelle mit Produkt-Strukturplan und Terminen . . . . . . . . . . Arbeitspakete mit Balkendiagramm . . . . . . . . . . . . . . . . . Bedingte Formatierung von Zelleninhalten . . . . . . . . . . . . . Balkendarstellung mit Plan- und Istwerten . . . . . . . . . . . . . Schnittstellen von MS-Project . . . . . . . . . . . . . . . . . . . . . MS-Project, Start: Standardansicht eines neuen, leeren Projekts Projektinformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . Schritt 1: Eingabe von Vorgängen . . . . . . . . . . . . . . . . . . Schritt 2: Eingabe der Zeiten . . . . . . . . . . . . . . . . . . . . . Schritt 3: Ablaufplanung mit Hilfe der Anordnungsbeziehungen MS-Project, Ansicht Netzplan . . . . . . . . . . . . . . . . . . . . . MS-Project, Schritt 4: Eingabe der Ressourcen . . . . . . . . . . MS-Project, Schritt 5: Zuordnung der Ressourcen . . . . . . . . Dateien von MS-Project . . . . . . . . . . . . . . . . . . . . . . . . Iterativer Ablauf eines Scrum-Projekts in zeitlicher (links) und symbolischer Darstellung (rechts) . . . . . . . . . . . . . . . . . . . Anforderungsspezifizierung im Product Backlog . . . . . . . . . Ablauf eines Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . Prozess-Modell eines Sprints . . . . . . . . . . . . . . . . . . . . . Sequentiell hybrides (a) und parallel hybrides PM-Modell (b) . . Ausschnitt eines Formularbeispiels „Projekt-Dokument“ . . . . Formular Statusbericht . . . . . . . . . . . . . . . . . . . . . . . . .

XXIII

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

331 337 339 341 341 342 344 345 347 348 348 349 350 351 352 352

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

362 369 373 373 384 386 386

Tabellenverzeichnis

Tab. 1.1 Tab. 1.2 Tab. 2.1 Tab. 2.2 Tab. 2.3 Tab. 2.4 Tab. 2.5 Tab. 2.6 Tab. 2.7 Tab. 2.8 Tab. 2.9 Tab. 3.1 Tab. 4.1 Tab. 4.2 Tab. 4.3 Tab. 4.4 Tab. 4.5 Tab. 4.6 Tab. 5.1 Tab. 6.1 Tab. 6.2 Tab. 6.3 Tab. 6.4 Tab. 7.1 Tab. 7.2 Tab. 7.3 Tab. 7.4 Tab. 8.1

Projektkriterien für verschiedene Vorhaben . . . . . . . . . . . . . . . . . . Kennzahlen für verschiedene Projektkategorien . . . . . . . . . . . . . . . 4 Was-Fragen zur Problemerkennung . . . . . . . . . . . . . . . . . . . . . 6-W-Fragen zur Problemerkennung . . . . . . . . . . . . . . . . . . . . . . Anforderungen für STARKE Ziele . . . . . . . . . . . . . . . . . . . . . . . Zielvariablen und Randbedingungen zur Anschaffung eines CADSystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zielbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kreativitätshemmende und -fördernde Faktoren . . . . . . . . . . . . . . . Morphologischer Kasten für passive elektrische Aufnehmer . . . . . . . Vergleich der Kreativitätsmethoden . . . . . . . . . . . . . . . . . . . . . . Nutzwertanalyse zur Bewertung von Alternativen Ak anhand der Kriterien Ki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arbeitsschritte der Stakeholder- und Umfeldanalyse . . . . . . . . . . . . Zusammenhang zwischen der Zahl der Hierarchieebenen und der Mitarbeiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispiel einer IMV-Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gliederung von Projekten unterschiedlicher Größe auf mehreren Ebenen Leistungsphasen nach HOAI . . . . . . . . . . . . . . . . . . . . . . . . . . . Vergleich der Grundmodelle der Ablauforganisation . . . . . . . . . . . . Bildung von Informationskategorien . . . . . . . . . . . . . . . . . . . . . . Phasen und Aktivitäten von PLT-Projekten . . . . . . . . . . . . . . . . . . Kalkulationsschema für Entwicklungskosten . . . . . . . . . . . . . . . . . Gegenüberstellung verschiedener Schätzmethoden . . . . . . . . . . . . . Konkrete Werte für P .x; z/ bei der Normalverteilung . . . . . . . . . . . CoCoMo-Schätzmodelle und Parameter . . . . . . . . . . . . . . . . . . . . Anordnungsbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verteilungsfunktion F .A/ des Aufwands A . . . . . . . . . . . . . . . . . . Geschätzte und berechnete Zeitwerte . . . . . . . . . . . . . . . . . . . . . Verteilungsfunktion F .T / der Projekt-Laufzeit T . . . . . . . . . . . . . . Checkliste Projekt-Risikofaktoren . . . . . . . . . . . . . . . . . . . . . . .

7 10 43 44 53 54 55 58 62 64 67 76 98 106 109 111 120 123 148 160 163 168 175 180 190 191 192 209 XXV

XXVI

Tab. 8.2 Tab. 8.3 Tab. 8.4 Tab. 8.5 Tab. 9.1 Tab. 9.2 Tab. 9.3 Tab. 9.4 Tab. 9.5 Tab. 10.1 Tab. 11.1 Tab. 11.2 Tab. 11.3 Tab. 12.1 Tab. 12.2 Tab. 12.3 Tab. 12.4 Tab. 12.5 Tab. 12.6 Tab. 12.7 Tab. 13.1 Tab. 13.2 Tab. 13.3 Tab. 13.4 Tab. 13.5 Tab. 13.6 Tab. 14.1 Tab. 14.2 Tab. 14.3 Tab. 14.4 Tab. 14.5 Tab. 14.6 Tab. 14.7 Tab. 14.8 Tab. 14.9 Tab. 14.10 Tab. 14.11 Tab. 14.12 Tab. 14.13 Tab. 14.14 Tab. 14.15 Tab. A.1

Tabellenverzeichnis

Bestimmung von Risikoklassen . . . . . . . . . . . . . . . . . . . . . Bestimmung der Risikoprioritätszahl . . . . . . . . . . . . . . . . . Ergebnis der FMEA (Auszug) . . . . . . . . . . . . . . . . . . . . . . Risk reduction stair . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kalkulationsgrößen für den Stundensatz . . . . . . . . . . . . . . . Aufgaben der Kostenplanung . . . . . . . . . . . . . . . . . . . . . . Fertigstellungsdaten der Arbeitspakete (FG: Fertigstellungsgrad) Earned Value der Arbeitspakete (FG: Fertigstellungsgrad) . . . . Kennzahlen der Earned Value Analyse . . . . . . . . . . . . . . . . Wichtige QMS-Normen . . . . . . . . . . . . . . . . . . . . . . . . . Ermittlung des Fertigstellungsgrads (FGR, in 0–100 %) . . . . . . Reaktionsmöglichkeiten auf Planabweichungen . . . . . . . . . . . Aktualisierung der Meilensteine durch Restaufwandsschätzung . Methodik des effizienten Arbeitens . . . . . . . . . . . . . . . . . . . Stress-Ursachen, -Reaktionen und -Bewältigung . . . . . . . . . . Richtige und falsche Bestandteile von Kritikgesprächen . . . . . . Anforderungen an Projektleiter . . . . . . . . . . . . . . . . . . . . . Situative Reifegrad-Theorie . . . . . . . . . . . . . . . . . . . . . . . Persönlichkeitseigenschaften . . . . . . . . . . . . . . . . . . . . . . Entwicklungsphasen von Arbeitsgruppen (nach Tuckman) . . . . Codierung für verschiedene Informationskategorien . . . . . . . . Zelleninhalte mit Verknüpfungen . . . . . . . . . . . . . . . . . . . . Registerkarten des Hauptmenüs von MS-Project 2013 . . . . . . . Grundlegende Funktionen und Icons von MS-Project . . . . . . . Zugriffswege auf Funktionen . . . . . . . . . . . . . . . . . . . . . . Eine Auswahl wichtiger Ressourcen-Attribute . . . . . . . . . . . . Die 4 Werte des agilen Manifests . . . . . . . . . . . . . . . . . . . . Die 12 Prinzipien des agilen Manifests . . . . . . . . . . . . . . . . Product Owner: Aufgaben und Befugnisse . . . . . . . . . . . . . . Scrum Master: Aufgaben und Voraussetzungen . . . . . . . . . . . Team: Aufgaben, Befugnisse, Merkmale . . . . . . . . . . . . . . . User Stories eines Product Backlogs für eine Web-App . . . . . . Sprint-Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sprint-Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Retrospektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formen klassischer und agiler Aufbauorganisation . . . . . . . . . Formen klassischer und agiler Ablauforganisation . . . . . . . . . Formen klassischer und agiler Informationsorganisation . . . . . . Merkmale klassischer und agiler PM-Modelle . . . . . . . . . . . . Übersicht der zur Verfügung gestellten Formulare . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

212 212 213 214 224 226 232 233 234 245 274 278 286 308 312 317 319 321 325 327 335 339 345 346 346 351 358 359 364 366 367 370 374 375 376 377 378 380 381 381 383 385

1

Projekte

Dieses erste Kapitel führt Sie auf einen „Rundflug“ über die Projekt-„Landschaft“. Auch wenn es manchmal anders aussieht: nicht jedes Vorhaben ist ein Projekt! Zunächst werden anhand von Beispielen die charakteristischen Merkmale erläutert, die Projekte kennzeichnen und von Nicht-Projekten unterscheiden. Danach lernen Sie die systemische Sicht auf Projekte kennen, die Ihnen hilft, sowohl den Projektgegenstand als auch das Gesamt-Projekt als ein System zu sehen. Sie werden dadurch in die Lage versetzt, Projektaufgaben aus System-Perspektive zu analysieren und das Projekt systematisch zu planen und zu steuern. Anschließend wird gezeigt, dass jedes Projekt ein spezieller Problemlösungsprozess ist. Methoden zur Lösung von Problemen bilden daher elementare Werkzeuge in Projekten. Das Kapitel endet mit der Definition des Begriffs Projektmanagement und Sie werden mit dem Projektmanagement-Lebenszyklus sowie dessen Unterteilung in verschiedene Prozesse und Phasen vertraut gemacht.

Nach der Bearbeitung des Kapitels sind Sie in der Lage,  anhand nachvollziehbarer Merkmale zu entscheiden, ob ein Vorhaben ein Projekt ist,  ein Projekt nach verschiedenen Aspekten zu klassifizieren,  ein Projekt aus systemtechnischer Sicht zu analysieren, indem Sie seine externen Schnittstellen sowie die internen Bestandteile und deren Wechselwirkungen benennen,  zu entscheiden, ob ein Vorhaben eine Aufgabe oder ein Problem ist und ob zu seiner Lösung ein Prozess, ein Problemlösungsprozess oder ein Projekt erforderlich ist,

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 W. Jakoby, Projektmanagement für Ingenieure, https://doi.org/10.1007/978-3-658-32791-0_1

1

2

1

Projekte

 die Aufgaben, Abläufe und Aktivitäten zu benennen, aus denen sich das Projektmanagement zusammensetzt.

1.1 Definitionen 1.1.1 Projektbeispiele Projekte sind heute in vielen Bereichen zu finden: In den technischen Abteilungen der Industrie werden Entwicklungsprojekte durchgeführt, um neue Produkte auf den Markt zu bringen, während die Kaufleute mit dem Projekt zur Einführung einer neuen Buchhaltungssoftware kämpfen. Unterdessen plant das Management bereits ein neues Übernahme-Projekt. Autoren künden ihr neues Buchprojekt an, Schauspieler schwärmen vom gerade abgeschlossenen Filmprojekt, Architekten setzen ihre Ideen im Entwurfsprojekt um und Studierende befinden sich gerade in einer schwierigen Phase ihrer Projektarbeit. Für viele Familien ist der Bau eines Eigenheimes eines der größten im Leben zu bewältigenden Projekte, während andere die ganze Familie als zeitlich begrenztes Projekt ansehen. Beispiel 1.1 „Mega“-Projekte

Viele Beispiele bekannter und erfolgreicher Projekte findet man in der Baubranche. Das Empire State Building in New York wurde von 1930 bis 1931 in nur 410 Arbeitstagen errichtet. Es kostete 25 Mio. $ und damit nur die Hälfte des geplanten Budgets! Der Arbeitsaufwand betrug 7 Mio. Stunden oder etwa 4000 Personenjahre. Mit einer Gesamthöhe von 449 m war es bis 1972 das höchste Gebäude der Welt. Als eines der ersten Projekte, bei dem dokumentierte, systematische Methoden zur Planung und Steuerung des Projektablaufs eingesetzt wurden, gilt der Bau des HooverDam von 1931 bis 1935. Die dabei errichtete, 221 m hohe und an der Krone 379 m lange Mauer staut den Colorado-River zwischen Arizona und Nevada in der Nähe von Las Vegas. Auch bei diesem Bauwerk blieben die Kosten von 32 Mio. $ unter dem Planwert. Eindrucksvolle Bauprojekte der heutigen Zeit sind der Gotthard-Basistunnel in der Schweiz, der die Alpen auf einer Länge von 57 km untertunnelt (Kosten 5 Mrd. $), der Meeresflughafen Chek Lap Kok bei Hongkong, bei dem mit Hilfe von 340 Mio. m3 Gesteinsmassen eine künstliche Insel mit einer Fläche von 938 ha geschaffen wird (Kosten für die Insel und alle darauf gebauten Einrichtungen 20 Mrd. $) oder die Inselgruppe „The World“ in Dubai mit einer Fläche von 5400 ha (Kosten 7,6 Mrd. $). J

1.1

Definitionen

3

Beispiel 1.2 „Out-of-time- und Out-of-budget“-Projekte

Manche Projekte erlangen gewollt oder ungewollt großes öffentliches Interesse. Nicht immer ist dabei der Erfolg der Grund dafür. Das Ziel des Projekts „Toll Collect“ war der Aufbau und Betrieb eines Systems zur Erhebung einer LKW-Maut auf deutschen Autobahnen. Der Auftrag wurde im Juli 2002 erteilt. Statt der vorgesehenen Inbetriebnahme im August 2003 konnte der vollständige Betrieb erst im Januar 2006 aufgenommen werden. Aus den versprochenen 14 Monaten Laufzeit wurden also 42 Monate! Verspätet oder unvollständig fertig gestellte oder auch komplett gescheiterte Projekte sind leider keine Einzelfälle. Als im Jahre 1959 mit dem Bau des Opernhauses in Sydney begonnen wurde, war die Fertigstellung für das Jahr 1965 geplant und es wurde mit Kosten von 7 Mio. australischen Dollar kalkuliert. Tatsächlich dauerte der Bau bis 1973 und es entstanden Kosten in der Höhe von 102 Mio. australischen Dollar! In einer Langzeitstudie untersucht die Standish Group seit 1994 regelmäßig das Ergebnis von Software-Projekten. Von den mittlerweile 40.000 untersuchten Projekten waren etwa 25 bis 35 % erfolgreich, etwa 40 bis 50 % wurden verspätet, viele sogar deutlich verspätet fertig gestellt und etwa 20 % wurden ganz abgebrochen. J Gemeinsam ist den aufgezählten Beispielen und auch den in der Literatur exemplarisch betrachteten Projekten, dass es sich um sehr große, teilweise sogar gigantische Vorhaben mit mehreren Hundert oder gar mehreren Tausend Personenjahren an Arbeit handelt. Sicher sind derartige Projekte sehr eindrucksvoll, um die Bedeutung und die Notwendigkeit systematischer Projektarbeitsmethoden zu verdeutlichen. Allerdings hat der Fokus auf Groß-Projekte auch Nachteile. Die Messlatte für Projektarbeit wird dadurch sehr hoch angesetzt. Es entsteht der Eindruck, systematische Projektarbeit und explizites Projektmanagement sei nur für große Projekte sinnvoll, für mittlere und kleine Projekte aber zu aufwändig. Tatsächlich sind heute viele Vorhaben, die nur wenige Personenmonate in Anspruch nehmen, zweifelsfrei Projekte und erfordern von Anfang an eine klare methodische Vorgehensweise, wenn sie zum Erfolg geführt werden sollen. Die Gründe hierfür sind die zunehmende Komplexität und Vernetzung unserer Lebens- und Arbeitswelt, das mittlerweile hohe Abstraktionsniveau vieler Arbeitsprozesse und der immer weiter steigende Zeit- und Kostendruck. Die zunehmende Verwendung des Projektbegriffs ist in den meisten Fällen eine Folge der hohen funktionellen, finanziellen und zeitlichen Anforderungen. Sie können auch in kleinen Projekten nur durch ein systematisches Projektmanagement erfüllt werden.

1.1.2 Abgrenzung von Nicht-Projekten Wie die kurze Aufzählung zeigt, findet man heute Projekte in allen Lebensbereichen. Aber auch schon zu früheren Zeiten wurden Vorhaben verwirklicht, die ohne Zweifel Projekt-

4

1

Projekte

charakter hatten, ohne dies ausdrücklich im Namen zum Ausdruck zu bringen. Der Bau der Pyramiden war sicherlich das Ergebnis einer enormen planerischen und organisatorischen Leistung, ebenso die Konstruktion der Arche Noah, während der Turmbau zu Babel zeigt, dass noch lange nicht jedes Groß-Projekt zu einem erfolgreichen Abschluss gebracht wird. Spätestens im 20. Jahrhundert hat der Projektbegriff eine so rasant zunehmende Verbreitung gefunden, dass man sich manchmal fragt, ob jedes dieser Vorhaben, zu Recht ein „Projekt“ im Namen trägt oder ob wir es hier nur mit einem weiteren, inflationär gebrauchten Modebegriff zu tun haben. Wodurch wird ein Vorhaben zu einem Projekt? Alle im vorangehenden Kapitel beschriebenen Vorhaben waren zweifelsfrei Projekte. Sieht man von verschiedenen spezifischen Details ab, sind bei den Vorhaben einige grundlegende Gemeinsamkeiten zu erkennen. In allen Projekten gibt es einen Sachverhalt, der durch verschiedene Aktivitäten in einen erwünschten Zielzustand gebracht werden soll. Die Existenz eines Ziels ist also ein wesentlicher Antrieb zur Durchführung eines Projekts und die Klarheit des Ziels ist die unverzichtbare Voraussetzung für dessen Gelingen. Ohne klares Ziel wird jedes Projekt scheitern. Die Ausführung der Maßnahmen, die der Zielerreichung dienen, stoßen bei allen Projekten auf Schwierigkeiten. Diese können sehr unterschiedlich sein. In der Regel entstehen sie durch die Neuartigkeit und Einmaligkeit der Aufgaben. Kein Projekt ist vollständig neuartig und einmalig, aber wichtige neuartige Teilaufgaben eines Vorhabens, machen ein Projekt schwierig. Schwierigkeiten lassen Aufgaben zu Problemen werden und daher liegt jedem Projekt ein (großes) Problem (und natürlich viele, viele kleinere Probleme) zugrunde. Ein weiteres durchgängig zu beobachtendes Merkmal der beschriebenen Projekte besteht darin, dass ihre Umsetzung aus einer Vielzahl auszuführender Arbeiten besteht. Zwischen diesen Arbeiten bestehen Abhängigkeiten: das Ergebnis der einen Arbeit wird in der nächsten benötigt, manche Arbeiten können gleichzeitig, andere müssen nacheinander bearbeitet werden. Ein Bündel derartig vernetzter Arbeiten bezeichnet man als Prozess und der Prozesscharakter ist daher das dritte wichtige Projektmerkmal. Aus der Vielzahl und der Vielfalt der auszuführenden Arbeiten resultiert der Bedarf an mehreren Personen, die im Projekt mitwirken. In erster Linie wird dies durch die Vielfalt der fachlichen Disziplinen verursacht, die im Projekt benötigt werden, aber auch Zeitgründe sprechen oft gegen die Durchführung eines Projekts durch eine einzelne Person. Neben den aktiven im Projekt mitwirkenden Personen sind aber auch passive, von der Durchführung der vom Ergebnis betroffene Personen im Projekt zu berücksichtigen. Die Ausführung von Arbeiten kostet Zeit. Der personelle und sächliche Aufwand kostet Geld. Beide Arten von Gütern sind in jedem praktischen Projekt begrenzt. Das Ziel muss nicht nur in endlicher Zeit, sondern meist in einem straffen Terminkorsett erreicht werden. Auch der zulässige Ressourcenaufwand muss sich an Budgetvorgaben halten. Die Begrenzung, sowohl der Ausführungszeit als auch der aufwendbaren Ressourcen, insbe-

1.1

Definitionen

Z

Merkmale Zielexistenz

S

Schwierigkeit, Neuargkeit

P

Prozesscharakter

O

Organisaon, Teambildung

R T

Ressourcenbegrenzung Terminierung

5

Aufgabe Problem Prozess Projekt

=> typische Problemaken unklare, veränderliche Anforderungen unklare, schwierige Realisierbarkeit viele und stark vernetzte Akvitäten unklare Verantwortungen/Befugnisse knappe Ressourcen, insb. Kapital knappe Termine

Abb. 1.1 Projektmerkmale und typische Problematiken

sondere des benötigten Kapitals, stellt daher das letzte wesentliche Projektmerkmal dar. Zentrale Merkmale, die das Wesen eines Projekts ausmachen, zeigt Abb. 1.1. Diese Merkmale können in folgender Definition zusammengefasst werden: I

Ein Projekt ist ein multipersonales Vorhaben zur Erreichung eines neuartigen Ziels in vorgegebener Zeit und mit begrenzten Ressourcen.

Die vorangehende Auflistung zeigt eine abgestufte charakteristische Einteilung verschiedener Vorhaben. Gibt es zu einem Vorhaben ein klares Ziel, handelt es sich um eine Aufgabe. Ist die Aufgabe schwierig, wird sie zu einem Problem. Erfordert die Lösung viele vernetzte Tätigkeiten, besitzt sie Prozesscharakter. Sind dann auch noch mehrere Personen beteiligt oder betroffenen und sind Zeit und Ressourcen begrenzt, handelt es sich um ein Projekt. Wie sieht es aber mit kleineren Vorhaben aus? Wann ist ein kleines, ein weniger schwieriges, ein nur teilweise neuartiges Vorhaben kein Projekt mehr? Ist ein zeitlich unbegrenztes Vorhaben noch ein Projekt? Gibt es auch Ein-Personen-Projekte? Müssen immer alle diese Kriterien erfüllt sein, damit man von einem Projekt sprechen kann? Welche müssen erfüllt sein und welche müssen es nicht? Beispiel 1.3 Studium

Ist ein Studium ein Projekt? Die Antworten hierauf fallen oft widersprüchlich aus. Nicht jeder Mensch studiert. Die meisten, die studieren, tun dies nur einmal. Bei einem Studium gibt es ein Ziel mit nachprüfbarer Zielerreichung und es gibt eine zeitliche Limitierung. Es studiert zwar nur eine Person, aber sie benötigt noch eine ganze Reihe anderer Personen, wie z. B. Professoren, die Wissen vermitteln und überprüfen, Eltern, die das Studium finanzieren, Kommilitonen, mit denen man sich gemeinsam vorbereitet. Die Ressourcen in einem Studium sind begrenzt. Dies gilt nicht nur für die Finanzierung des Studiums, sondern auch Hörsäle, Laborplätze und Arbeitsräume sind knapp. Ihre Nutzung erfordert daher eine detaillierte Planung und Organisation. Angesichts dieses doch recht eindeutigen Ergebnisses – alle Projektmerkmale sind erfüllt – wird man nicht umhin können, ein Studium als Projekt anzusehen. Aber wie viele Studierende führen tatsächlich ein explizites Projektmanagement durch? Und

6

1

Projekte

wenn sie es nicht explizit tun, welche unsystematischen, nichtformalen ManagementMethoden kommen zum Einsatz? Wenn ein Studium so eindeutig ein Projekt ist, wäre es da nicht an der Zeit, zu Studienbeginn etwas über Projektmanagement zu lernen? J Kein Projektmerkmal ist eine binäre Variable, die eindeutig erfüllt ist oder eindeutig nicht erfüllt ist. Jedes Merkmal kann mehr oder weniger erfüllt sein: ein Projektziel kann mehr oder weniger klar sein, jede Projektaufgabe kann mehr oder weniger klar sein und die Zahl der Personen kann sehr unterschiedlich sein. Zudem können die Merkmale als Projektindikatoren bei einem Vorhaben unterschiedlich ausgeprägt sein. Manche Vorhaben sind sehr schwierig, weisen aber nur eine schwache Ressourcenbegrenzung auf. Andere stehen unter sehr hohem Zeitdruck, dafür beinhalten sie aber wenige neuartige Aufgaben. Die Festlegung, ob ein Vorhaben ein Projekt ist oder nicht, ist daher sowohl relativ: die Projektcharakteristik kann mehr oder weniger stark ausgeprägt sein, und sie ist subjektiv: was eine Person schon als Projekt einstuft ist für eine andere ein „Nicht-Projekt“. Trotzdem ist die Untersuchung der Projektmerkmale bei einem Vorhaben wichtig. Sind die einzelnen Indikatoren recht stark ausgeprägt und zeigen sie auch noch in die gleiche Richtung, können manche Vorhaben eindeutig als Projekt, andere genau so eindeutig als Nicht-Projekt eingestuft werden. Bei diesen Fällen hat die Analyse für Klarheit gesorgt. Bei den Zweifelsfällen kommt es letztlich gar nicht so sehr auf die Entscheidung (Projekt oder Nicht-Projekt) an, sondern die Kenntnis des Profils ist wichtig. Jedes Projektmerkmal, das in einem Vorhaben sehr ausgeprägt ist und daher Probleme bereitet, erfordert bestimmte planende Methoden. Unklare Ziele erfordern erhöhten Aufwand bei der Aufgabenklärung und dem Anforderungsmanagement. Auf fachlich schwierige Aufgabe muss durch passende Fachkompetenzen reagiert werden. Ist der Prozesscharakter sehr ausgeprägt, ist eine genaue Ablaufplanung nötig, egal ob das Vorhaben als Projekt eingestuft wird oder nicht. Sind die Zeitvorgaben sehr eng, muss so viel wie möglichst parallel bearbeitet werden und bei vielen beteiligten oder betroffenen Personen sind deren Ausrichtung auf die gemeinsamen Ziele und die Organisation des Informationsaustauschs hoch zu priorisierende Aufgaben. Die Analyse eines Vorhabens hinsichtlich der Projektmerkmale dient also hauptsächlich als Entscheidungsbasis für die benötigten Managementmethoden und -werkzeuge. Nicht in jedem Projekt muss immer die dickste Managementkanone in Stellung gebracht werden und bei manchen Nichtprojekten ist der Einsatz von Managementmethoden sehr hilfreich. Beispiel 1.4 Projektkriterien

Bei den folgenden Vorhaben soll untersucht werden, ob es sich um Projekte handelt (Tab. 1.1). 1. Leitung eines Unternehmens. 2. Entwicklung einer neuen Mikroprozessorschaltung.

1.1

Definitionen

7

Tab. 1.1 Projektkriterien für verschiedene Vorhaben Vorhaben Unternehmensleitung Entwicklung neue Mikroprozessorschaltung Re-Design Mikroprozessorschaltung Neuer Energiespeicher Jährliche Inventur

Kriterien Z S + o + + +  o + + 

Ergebnis P + + + + o

O + o o + +

R  + +  +

T  + +  +

Nein Ja Nein Unklar Nein

Z: Zielklarheit, S: Schwierigkeit, P: Prozesscharakter, O: (viele) Beteiligte, R: Ressourcenbegrenzung, T: Terminierung

3. Re-Design einer bestehenden Mikroprozessorschaltung wegen Umstellung auf schadstoffarme Bauteile. 4. Suche nach einem neuen Prinzip zur effizienten Speicherung elektrischer Energie. 5. Inventur eines Unternehmens zum Abschluss des Geschäftsjahrs. Obwohl die Leitung eines Unternehmens viele Projektkriterien erfüllt, ist es dennoch kein Projekt, da eine zeitliche Begrenzung für diese Aufgabe nicht vorgesehen ist. Eine Zeitbegrenzung kann daher als notwendige Bedingung für ein Projekt eingestuft werden. Die Neuentwicklung einer elektrischen Schaltung erfüllt praktisch alle Projekteigenschaften. Beim Re-Design dagegen fehlen als wesentliche Projekteigenschaften die Neuartigkeit und die Schwierigkeit. Die Entwicklung eines neuen Energiespeichers ist in der Einschätzung problematisch. Ohne weitere Informationen ist eine Entscheidung hier nicht möglich. Die Frage der Zielklarheit müsste sicherlich präzisiert werden durch konkrete Maßzahlen für Platz- und Gewichtsbedarf sowie die Kosten. Außerdem müsste unbedingt eine Zeitaussage gemacht werden. Eine Inventur wird in der Regel jährlich durchgeführt. Es handelt sich also um einen Routine-Prozess. J Die wenigen Beispiele zeigen, dass es einige harte und weiche Projektkriterien gibt. Notwendige Kriterien sind die Einmaligkeit und Zielklarheit der Aufgabe, die Zeitbegrenzung für deren Umsetzung und die Zusammensetzung der Lösung aus mehreren Arbeitsschritten. Schwächer und in unterschiedlichem Maß erfüllbar sind die Fragen der Schwierigkeit, die Zahl der beteiligten Personen und der Ressourcenbegrenzung.

1.1.3 Klassifizierung von Projekten Da es sehr unterschiedliche Arten von Projekten gibt, ist es selbstverständlich, dass es keine Projektmanagement-Methoden gibt, die immer und für alle Projekte geeignet sind. Ein Projekt, an dem mehrere 1000 Personen über mehrere Jahre hinweg beteiligt sind, er-

8

1

Projekte

fordert andere Planungs- und Organisations-Methoden als ein Projekt mit wenigen Beteiligten und wenigen Monaten Laufzeit. Um entscheiden zu können, welche ManagementMethoden bei einem Projekt passen und welche nicht, ist es hilfreich, Projekte zu klassifizieren und dann die passenden Methoden den verschiedenen Projektklassen zuzuordnen. Projekte können nach verschiedenen Kriterien klassifiziert werden. Ein nahe liegendes wichtiges Kriterium ist die Projektgröße. Als Messwert für die Projektgröße bieten sich beispielsweise die Zahl der Beteiligten, die Laufzeit oder die Kosten an. Im Allgemeinen wird der Personenaufwand, gemessen in Personenjahren (vor der Erfindung der Gleichberechtigung als „Mannjahre“ bezeichnet), als geeignete Maßzahl verwendet. In den Aufwand als Maßzahl fließt sowohl die Zahl der Beteiligten als auch die Laufzeit ein. Außerdem werden bei personalintensiven Projekten die Projektkosten zu einem großen Teil durch den Personalaufwand bestimmt, so dass die wichtigen Parameter, die die Projektgröße bestimmen, erfasst sind. Die Messung des Personalaufwands ist bislang nicht standardisiert. Von einem Jahr bleiben ohne die Wochenenden und die Feiertage nach Abzug des Urlaubs (25–30 Tage) und von Fehlzeiten durch Krankheit etwa 210–220 Arbeitstage. In der Literatur werden diese Tage unterschiedlich auf das Jahr und die Monate aufgeteilt. So geht z. B. [Balzert 1998] von 10 Monaten pro Jahr und 20,8 Tagen pro Monat aus. In diesem Buch werden als Kompromiss zwischen uneinheitlicher Realität und einfacher Handhabung die Einheiten Personentag (1 PT), Personenmonat (1 PM = 20 PT) und Personenjahr (1 PJ = 11 PM = 220 PT) zur Messung des Personalaufwands verwendet. Selbstverständlich gibt es unterschiedliche Ansichten darüber, wann ein Projekt „groß“ oder „klein“ zu nennen ist. Dies ist auch nicht verwunderlich, da es sich tatsächlich um eine kontinuierliche Skala handelt. Geht man aber von einer Einteilung in 6 Größenordnungen sowohl bei der Zahl der am Projekt beteiligten Personen und auch von 6 Größenordnungen bei der Projektlaufzeit aus, so kann man die in Abb. 1.2 dargestellten Projektgrößen unterscheiden. Projekte mit wenig Beteiligten und sehr langer Laufzeit (im Diagramm der Bereich links, oben) oder Projekte mit sehr vielen Beteiligten und sehr kurzer Laufzeit (rechts, unten) sind eher selten, so dass sich die meisten Projekte in der Nähe der Diagonalen befinden. Legt man nun noch gut einprägsame Grenzen fest, so gelangt man zu einer groben Einteilung, bei der Projekte bis zu 4 PJ als „klein“ und Projekte mit mehr als 40 PJ als „groß“ und dazwischen liegende als „mittel“ bezeichnet werden können. Außerdem kann nach unten („sehr klein“ < 0,4 PJ) und nach oben („sehr groß“ > 400 PJ, MegaProjekt > 4000 PJ) weiter differenziert werden. Auf der Diagonalen besteht zwischen dem Aufwand A (in PM), der Anzahl N der beteiligten Personen (P) und der Laufzeit D (in Monaten) folgender Zusammenhang: 1=3

DM D 3  APM

NP D

1 2=3  APM 3

1=2

D M D 5  NP

Er kann für eine erste, grobe Abschätzung der mittleren Personenzahl und der Laufzeit genutzt werden, wenn eine Abschätzung des Personalaufwands vorliegt.

1.1

Definitionen

9

Abb. 1.2 Klassifizierung von Projekten nach der Projektgröße

Zur Bestimmung der Kosten kann man davon ausgehen, dass eine Projektgröße von 1 PJ Kosten von 250 Tsd. C (inklusive Material, Maschinen etc.) verursacht. Dies entspricht gemittelt über viele Branchen in etwa dem Median, des jährlichen Umsatzes pro Mitarbeiter. Die reinen Personalkosten können dabei mit einem Viertel bis zur Hälfte dieser Summe, also 60–125 Tsd. C/PJ veranschlagt werden. In erster Näherung kann außerdem von 10 Tsd. C pro Personenmonat ausgegangen werden. Selbstverständlich handelt es sich bei diesen Zahlen um grobe Näherungen, die im konkreten Fall deutlich abweichen können. Einen beträchtlichen Einfluss hat dabei zwangsläufig der Einsatz an Maschinen und Material. Dieser hängt vor allem von der Art des Projekts ab. Trotzdem ermöglicht die Personalkostenkennzahl eine erste schnelle Einordnung der Größe eines Projekts und der damit verbundenen Kosten. Für eine genauere Abschätzung der Kosten muss die Projektart zur Korrektur der Kostenkennzahl berücksichtigt werden. Beispiel 1.5 Projekt-Kennzahlen

Aus eigenen Projekten des Autors und aus Literaturangaben für Projekte aus verschiedenen Branchen, wurden wichtige Kennzahlen ermittelt (Tab. 1.2). Die Angaben zum Gotthard-Basistunnel zur Elbphilharmonie und zu einem typischen (deutschen) Kinofilm stammen aus verschiedenen Veröffentlichungen. Die Angaben für die Entwicklung eines (vollständig) neuen PKW-Modells variieren sehr stark. Sie beinhalten auch den Entwurf der dazu gehörenden Produktionslinie. Bei dem Baumaschinenhersteller handelt es sich um ein mittelständisches Unternehmen mit ca. 800 Mitarbeitern, das ein komplett neues Werk mit Produktionshalle und Bürogebäude aufgebaut hat. Die Spiele-Software Quake-Engine 3 umfasst ca. 400.000

10

1

Projekte

Tab. 1.2 Kennzahlen für verschiedene Projektkategorien Projekt

D [J]

1. Gotthard-Basistunnel 17 2. Entwicklung neues Automodell 4 3. Bau der Elbphilharmonie 10 4. Neues Werk für Baumaschinenhersteller 1,9 5. Neue Spiele-Software (Quake Engine) 3,3 6. Dt. Kinofilm 2,5 7. Aufbau einer Gebäudehebeanlage 1,75 8. Projekt-Arbeit im Studium 0,25

A [PJ]

Mio. C

25.000 4000 2000 565 200 25 3,5 0,25

10.000 2000 800 130 41 5 0,9 0,004

Mio. C/PJ 0,400 0,500 0,400 0,230 0,200 0,200 0,250 0,015

N [P] 1500 1000 180 300 60 10 2 1

Programmzeilen. Die Gebäudehebeanlage besteht aus bis zu 80 elektrohydraulischen automatisch gesteuerten Hebern. Sie dient dazu, schief stehende Gebäude zu heben. J Ein zweites wichtiges Kriterium zur Klassifizierung von Projekten ist der Projektgegenstand. Hier kann unterschieden werden, zwischen Projekten, die ein Produkt oder eine Dienstleistung, zum Gegenstand haben. Viele moderne aber auch historische Projekte wurden in der Baubranche durchgeführt. Hierzu zählen Tiefbauvorhaben, wie Straßen, Tunnel, Kanäle oder Hochbauvorhaben. Als weitere Branchen, in denen sehr viel Projektarbeit stattfindet sind die Konstruktion und der Bau von Maschinen zu nennen, die Entwicklung neuer chemischer oder biochemischer Produkte, wie z. B. Medikamente oder Werkstoffe, die Entwicklung elektrischer und elektronischer Geräte und die Entwicklung von Software. Auch wenn es sicherlich weitere mögliche Klassifikationskriterien gibt, soll als drittes und letztes an dieser Stelle die Projektart genannt werden. Hiermit ist die Art der Tätigkeiten im Projekt gemeint. In einem Forschungsprojekt werden neue wissenschaftliche Erkenntnisse gesucht. Oft ist es unsicher, ob dabei Ergebnisse erzielt werden und bei weitem nicht immer steht die Nutzanwendung dieser Erkenntnisse am Ziel der Bemühungen. Forschungsprojekte sind daher durch ein großes Maß an Neuartigkeit, durch abstraktere Ziele und eine hohe Unsicherheit der Planung gekennzeichnet. Etwas weniger unsicher sollten Entwicklungsprojekte sein. Hierbei wird ein neues Gerät, eine Maschine, ein Programm entwickelt bzw. konstruiert. Auch hier hat man einen hohen Grad an Neuartigkeit. Die Zielsetzung sollte aber konkreter sein und die Machbarkeit sicherer sein als bei Forschungsprojekten. Erfahrungen zeigen, dass aber auch Entwicklungsprojekte große Unsicherheit bergen können, die sich oft bei den Terminen und Kosten äußert. Noch konkreter sind Projektierungsprojekte: Hier soll eine neue Anlage, eine neue Software-Anwendung aus vorhandenen Modulen entworfen und aufgebaut werden. Bei derartigen Vorhaben findet man eine geringe bis mittlere Neuartigkeit; dem Projekt liegt oft ein Kundenauftrag zu Grunde, dessen Umfang und Ziel meistens eindeutig ist. Proble-

1.2

Systeme und Prozesse

11

me bestehen vorwiegend darin, gegenläufige Anforderungen, hinsichtlich Funktionalität, Terminen und Kosten miteinander zu vereinbaren. Eine weitere oft anzutreffende Projektart sind Organisationsprojekte. Bei diesen sollen z. B. betriebliche Abläufe oder Organisationen geändert oder neu aufgebaut werden. Da Organisation das Zusammenwirken von Menschen betrifft, sind nicht nur Menschen an der Durchführung eines solchen Projekts beteiligt, sondern ihr Zusammenwirken im Rahmen der Organisation stellt auch den Projektgegenstand dar. Die besondere Herausforderung von Organisationsprojekten bilden daher psychische Vorgänge bei den Projektbeteiligten. Die Projektart mit der längsten Historie und einem hohen Reifegrad des Projektmanagements sind Investitionsprojekte. Hierzu gehört der Bau großer und einmaliger Gebäude, Straßen, Staudämmen, Inseln, Kanälen, Flughäfen oder von Produktionsanlagen. Ein besonderes Merkmal von Investitionsprojekten ist das hohe Kostenbudget, das durch einen vermehrten Bedarf an Maschinen, Rohstoffen und Zulieferteilen entsteht und das in der Planung und Steuerung eines besonderen Augenmerks bedarf.

1.2 Systeme und Prozesse 1.2.1 Systemdefinition Ein System ist ein Gebilde, das von seiner Umgebung als zusammenhängende Einheit abgegrenzt werden kann (Abb. 1.3). Es wird von der Umgebung über Eingangsgrößen beeinflusst. Dabei gibt es Eingangsgrößen u, über die eine gezielte Beeinflussung erfolgt und unerwünschte Störgrößen v. Das System reagiert auf diese Anregungen und wirkt seinerseits auf die Umgebung zurück mit gewünschten Reaktionen y und unerwünschten Nebenwirkungen n. In einem System können Materie, Energie und Informationen gespeichert werden. Durch die eingangsseitige Zuführung oder ausgangsseitige Abgabe ändert sich der Zustand des Systems. Er ist zu jedem Zeitpunkt eindeutig bestimmt durch die Werte der Speichergrößen x.

Abb. 1.3 Externe und interne Sicht der Systemstruktur

12

1

Projekte

Betrachtet man beispielsweise ein Auto (ohne den Fahrer) als System, so reagiert es auf Eingangsgrößen, wie z. B. Gas geben, Schalten und Lenken durch den Fahrer mit einer Geschwindigkeits- und Positionsveränderung. Störgrößen wären hier z. B. veränderliche Steigungen, Seitenwind oder ein auf der Fahrspur auftauchendes Hindernis. Mögliche Zustandsgrößen des Systems „Auto“ sind seine Position und seine Geschwindigkeit. Auch ein Haus ist ein System. Die Umgebung wirkt hier über Sonneneinstrahlung, Wind oder Regen auf das Haus ein. Die Ausgangsgrößen des Hauses auf die Umgebung sind seine Wärmeabgabe, der Lärm, den die Bewohner verursachen oder der Druck über das Fundament auf den Untergrund. Das Internet ist ein sehr komplexes und mittlerweile über den ganzen Globus verteiltes System. Es besteht aus einer Vielzahl von Übertragungssystemen, Rechnern und auf diesen Rechnern ablaufenden Programmen. Die Umgebung bilden andere Rechner, die ans Internet angeschlossen werden. Eingangsgrößen des Systems sind Daten die an einem Rechner eingespeist und an einem anderen Rechner als Ausgangsgrößen herauskommen. Neben dieser externen Sicht auf ein System gibt es gleichberechtigt auch die interne Sicht: Im Inneren besteht ein System aus Komponenten, die untereinander in Wechselwirkung stehen (Abb. 1.3). Beim Auto sind dies z. B. die Karosserie, der Motor, das Getriebe und das Fahrwerk. Bei einem Haus kann man Fundament, Mauerwerk, Decken, Dach, Heizung, Sanitär- und Elektroanlagen als wichtige Bestandteile identifizieren. Das Internet wiederum besteht aus einer unübersehbaren Vielzahl von Client- und ServerRechnern, den darauf laufenden Programmen sowie Datenspeicher, Datenübertragungseinrichtungen und Leitungen. Zwischen der Umgebung und dem System bestehen genauso Wechselwirkungen wie zwischen den inneren Komponenten des Systems. Auf den ersten Blick scheint daher die Abgrenzung zwischen System und Umgebung oder zwischen inneren und äußeren Wechselwirkungen zumindest nicht eindeutig, manchmal sogar willkürlich zu sein. Der Ausweg aus dieser scheinbaren Beliebigkeit stellt die Qualität der Wechselwirkungen dar. Es gibt Komponenten, zwischen denen nur lose Wechselwirkungen bestehen, während andere sehr eng gekoppelt sind. Motor, Getriebe und Räder eines Autos sind sehr eng gekoppelt, so dass man sie als eine Einheit – als ein System – betrachten kann. Andere Teile, wie z. B. Klimaanlage, Autoradio oder Reserverad weisen untereinander und auch mit dem Antriebssystem praktisch keine Kopplung auf. Es gibt also immer Komponenten mit loser und solche mit enger Kopplung. Die Berechtigung, ein Gebilde als System anzusehen, ist umso mehr gegeben, als die Wechselwirkungen zwischen den Teilen des Gebildes deutlich größer sind als die Wechselwirkungen mit der Umgebung. Muss man also entscheiden, welche Komponenten zum System gehören und welche nicht, dann sollte das Augenmerk auf die Stärke der Wechselwirkungen gerichtet werden. Bei starken Wechselwirkungen zu einer Komponente sollte diese eher dem System zugeschlagen werden, bei schwachen Wechselwirkungen eher zur Umgebung.

1.2

Systeme und Prozesse

1.2.2

13

Projekte aus Systemsicht

Was hat nun ein Projekt mit einem System zu tun? Sehr viel! Der Projektgegenstand, also das Produkt, das Ergebnis eines Projektes ist, weist alle Systemmerkmale auf: Das Produkt besitzt eine klare Abgrenzung von der Umgebung, in der es später eingesetzt bzw. betrieben werden soll. Außerdem besteht es fast immer aus mehreren, in Wechselwirkung zueinander stehenden Teilkomponenten (Abb. 1.4). Aber auch ein Projekt als Ganzes ist ein System. Aus externer Sicht erhält es von seiner Umgebung einen Auftrag als Input und es liefert ein Ergebnis – den Projektgegenstand – als Output. Darüber hinaus findet man in einem Projekt eine ganze Reihe von Teil-Systemen. Ein soziologisches Teil-System stellen die Beteiligten dar, zwischen denen während der Projektdauer eine Vielzahl von Wechselwirkungen stattfinden. Die eingesetzten Ressourcen, wie z. B. CAD-Systeme, Dokumenten-Management-Systeme, oder die Maschinen stellen Systeme dar. Eine weitere Systemkomponente bilden die auszuführenden Arbeiten. Sie weisen untereinander viele logische und zeitliche Abhängigkeiten auf und nehmen darüber hinaus Arbeitszeit der Projektbeteiligten in Anspruch und benötigten Materialien, Energie, Räume und Kapital. In jedem Projekt besteht zwischen diesen Projekt-Elementen eine Vielzahl von Wechselwirkungen: A-A: Beziehungen zwischen einzelnen Arbeiten, wie z. B. ein größeres Arbeitspaket besteht aus mehreren Teilarbeiten oder: eine Arbeit muss abgeschlossen werden, damit eine andere beginnen kann. A-B: Beziehungen zwischen Arbeiten und Beteiligten: Die Projektbeteiligten können verschiedene Rollen bei der Ausführung von Arbeiten annehmen, wie z. B. ein Beteiligter führt eine Arbeit aus, ein anderer muss über die Fertigstellung informiert werden, ein Beteiligter muss eine Arbeit freigeben. B-B: Beziehungen zwischen Projektbeteiligten, z. B. der Projektleiter legt die Rolle eines Projektmitarbeiters fest, manche Projektbeteiligten kommen gut miteinander klar, bei anderen kommt es immer wieder zu Reibereien.

A u ftra g

A-B

Arbeiten

A-R

A-A

R-B

Ressourcen

R-R

Abb. 1.4 Ein Projekt aus Systemsicht

Beteiligte

B-B

Projekt

E r g e b n is

14

1

Projekte

A-R: Für die Arbeiten werden bestimmte Ressourcen benötigt, z. B. eine Arbeit erfordert bestimmte Maschinen, jede Arbeit verursacht Kosten. B-R: Die am Projekt beteiligten Personen nehmen Ressourcen in Anspruch: sie erwarten ein Gehalt, sie brauchen einen Schreibtisch, einen Rechner und andere Hilfsmittel. R-R: Auch zwischen den Ressourcen bestehen Beziehungen, wie z. B. jede Ressource nimmt Kapital in Anspruch, eine Maschine braucht Platz. Die Vielzahl der Projekt-Bestandteile und die noch größere Vielfalt der Wechselwirkungen macht die Komplexität eines Projekts aus und lässt die Planung und Steuerung von Projekten zu einer wirklichen Herausforderung werden. Beispiel 1.6 Grillfete

Es ist Freitag, 14:30 Uhr und in Ihrer Arbeitsgruppe ist um 17:00 Uhr Feierabend. Um 20:00 Uhr wird im Fernsehen ein Fußballspiel übertragen. Ihr Chef will mit seinen 5 Mitarbeitern und deren Familien eine Grillfete veranstalten. Er bittet Sie, die Fete zu organisieren. Sie stellen sich einige Fragen: Was ist der Projekt-Auftrag? Was ist das Ergebnis? Wann ist Anfangszeitpunkt und Endzeitpunkt des Projekts? Welche Projekt-Beteiligten gibt es? Was gehört außerdem zum Projekt? Welche Beziehungen bestehen zwischen den Projekt-Bestandteilen? Wie könnte eine Planung aussehen? Ist die Grillfete überhaupt ein Projekt? Sicher ist die Grillfete kein großes Projekt. Mit etwas mehr Planungsvorlauf, wäre es wohl nur ein Routine-Vorhaben, aber durch die extrem kurze Vorbereitungszeit, wird es zu einem Projekt, da es doch eine ganze Reihe von Beteiligten, benötigter Ressourcen und durchzuführender Aktivitäten gibt. Beteiligte am Projekt sind der Chef, die 5 Mitarbeiter (inklusive Ihnen selbst) und alle Familienangehörigen. Weitere Beteiligte können Lebensmittel- und Getränke-Lieferanten sein oder Vermieter einer geeigneten Lokalität. Benötigte Ressourcen sind ein Raum mit Grillmöglichkeit, ein Fernseher, Fleisch, Getränke, Holzkohle und nicht zuletzt auch das Geld zur Deckung der Kosten. Selbst bei einem kleinen Vorhaben wie der Grillfete gibt es eine Reihe von Aktivitäten, wie z. B. Raum suchen, Fleisch besorgen, Getränke besorgen, Grill besorgen, nach der Fete wieder aufräumen, Leergut zurückbringen und Kostenabrechnung erstellen. Das Projekt beginnt sofort mit der Auftragserteilung. Es endet nicht mit dem Ausklang der Fete, sondern wenn alles weggeräumt und abgerechnet ist. Wegen des großen Zeitdrucks müssen die vorbereitenden Arbeiten so weit wie möglich parallel ausgeführt werden. Daher ist es sinnvoll eine Liste aller Arbeiten zu machen und diese auf alle Mitarbeiter aufzuteilen, und eventuell sogar deren Familien mit einzuspannen. Die nachbereitenden Arbeiten dagegen sind dagegen zeitlich unkritisch. J Die Wechselwirkungen eines Systems mit seiner Umgebung und die Wechselwirkung der Systemkomponenten untereinander bilden die Struktur des Systems. Die Struktur ist

1.2

Systeme und Prozesse

15

meistens ein relativ gleichbleibender, statischer Aspekt eines Systems. Zusammen mit den Zustandsgrößen führen die Wechselwirkungen aber auch zu einem wichtigen dynamischen Aspekt. Die Ausführung von Arbeiten durch die Beteiligten unter Einsatz von Ressourcen nimmt Zeit in Anspruch. Sollen mehrere Arbeiten von einer Person oder auf einer Maschine ausgeführt werden, so kann dies nur sequentiell erfolgen. Bestimmte Arbeiten setzen andere Arbeiten voraus und können daher, auch bei unbegrenzten Ressourcen nur nacheinander erledigt werden. Der dynamische Systemaspekt ist daher ein ganz wichtiger Bestandteil der Projektplanung und -steuerung. Hier werden Fragen untersucht wie z. B.: Wann muss das Projekt abgeschlossen sein? Wann kann eine Arbeit frühestens verrichtet werden? Wann muss eine Arbeit spätestens beendet sein, damit das Projekt im Plan bleibt? Wann wird eine Ressource benötigt? Wer steht in einem bestimmten Zeitraum zur Verfügung, um eine Arbeit zu verrichten? Welche anderen Arbeiten müssen abgeschlossen sein, damit diese Arbeit begonnen werden kann? Die Antworten auf diese und andere Fragen werden im Rahmen der Termin- und Ablaufplanung eines Projekts gesucht. Sie stellt einen zentralen Bestandteil des Projektmanagements dar.

1.2.3 Probleme Jeden Tag sind wir mit Aufgaben und Problemen konfrontiert. Egal ob wir sie bewusst als solche wahrnehmen oder unbewusst verarbeiten; sie begegnen uns ständig und in sehr vielfältigen Formen. Auch wenn Aufgaben und Probleme oft Anlass für Ironie sind („Ich hätte mal gern ein Problem.“) oder geleugnet werden („Es gibt keine Probleme; nur Herausforderungen.“); um Aufgaben und Probleme zu erkennen und sinnvoll zu lösen, ist es wichtig, sie beim richtigen Namen zu nennen. Beispiel 1.7 Aufgaben, Probleme, Projekte

Welche dieser Vorhaben sind Projekte? Welche stellen ein Problem dar? Und welche sind nur eine Aufgabe? 1. Ein Paket soll mit einem Auto von München nach Hamburg gebracht werden. 2. Es soll ein Programm geschrieben werden, das die größte 9-stellige Primzahl berechnet. 3. Es soll ein Schaltnetzteil für einen Rechner mit 100 W Leistung entwickelt werden. 4. Im Rahmen einer 1-wöchigen Schulung soll den Teilnehmern die Kunst des Projektmanagement beigebracht werden. 5. Ein ehemaliges Bahnhofsgebäude an einer stillgelegten Bahnlinie soll zu einem Hotel umgebaut werden. 6. Es soll ein Auto für 4 Insassen konstruiert werden mit einem Verbrauch von weniger als 1 l auf 100 km.

16

1

Projekte

7. Ein Industriegebiet soll über eine neue Straßenverbindung an die bestehende Autobahn angeschlossen werden, um die nahe gelegene Stadt vom Verkehr zu entlasten J So unterschiedlich die Aufgabenbeispiele auch sind, bei genügender Abstraktion findet man den gemeinsamen Kern: eine Aufgabe ist dadurch definiert, dass ein System, aus einem Anfangszustand durch geeignete Handlungen in einen Zielzustand gebracht werden soll. I

Ein System durch geeignete Handlungen aus einem Anfangs- in einen Zielzustand zu bringen ist eine Aufgabe.

Aufgaben können sehr unterschiedliche Schwierigkeitsgrade beinhalten. Ein Paket vom A nach B zu bringen, ist bei weitem nicht so schwierig, wie der Aufbau eines Schaltnetzteils, ganz zu schweigen vom Bau eines Hauses oder des Gotthard-Basistunnels. Zudem kann eine Aufgabe für verschiedene Menschen unterschiedlich schwierig sein. Auch der einfache Pakettransport, kann kompliziert werden, wenn jemand kein Auto hat, nicht weiß, wo Hamburg liegt oder wenn das Paket 2 t wiegt. Eine Aufgabe wird zu einem Problem, wenn es ein Hindernis gibt, dass die Lösung der Aufgabe erschwert oder gar verhindert wird. I

Eine Aufgabe wird zu einem Problem, wenn der Weg vom Anfangs- zum Zielzustand durch ein Hindernis erschwert wird.

Hindernisse auf dem Weg vom Anfangs- zum Zielzustand sind genau so vielgestaltig, wie die Aufgaben selbst. Schwierigkeiten können sich ergeben, weil man nicht weiß, was gemacht werden muss, wie es getan werden kann, wenn nicht klar ist, welche der vielen Handlungsmöglichkeiten die beste ist oder in welcher Reihenfolge die Handlungen auszuführen sind. Schwierigkeiten entstehen auch, wenn der Handlungsspielraum durch viele Bedingungen eingeschränkt ist, wie z. B. knappe Zeit, knappe Ressourcen oder fehlendes Fachwissen. Weitere Barrieren tun sich auf, wenn der Zielzustand oder der Anfangszustand unklar ist. Gibt es mehrere geeignete Lösungen, kann es notwendig sein, die beste Lösung zu finden, d. h. die Lösung, die ein Gütekriterium optimiert. Ist kein Gütekriterium bekannt, kann die Suche nach einem Gütekriterium zum Bestandteil der Lösungssuche werden. Von zentraler Bedeutung für das Zustandsraummodell ist die Frage der Problemdimensionen. Alle Größen, die bei der Beschreibung des Anfangszustandes und des Zielzustandes auftauchen oder in den Randbedingungen oder Gütekriterien verwendet werden, sind potentielle Problemdimensionen. Im Allgemeinen wird ein Problem viele Dimensionen aufweisen, so dass eine einfache, zweidimensionale Darstellung nicht möglich ist. Andererseits können mehrere Problemdimensionen oft zusammengefasst werden oder sind

1.2

Systeme und Prozesse

17

von untergeordneter Bedeutung, so dass einige wenige dominierende Problemdimensionen übrig bleiben. Beispiel 1.8 Problemdimensionen

Bei einem Transportproblem können die benötigte Zeit, die verursachten Kosten oder die verbrauchte Energie mögliche Problemdimensionen sein. Beim Bau eines Hauses sind die gewünschte Wohnfläche, die Kosten und die Bauzeit wichtige Kriterien und eignen sich daher als Problemdimensionen. Bei einem Studium sind die erreichte Qualifikation und der erforderliche Aufwand bestimmende Problemdimensionen. Bei dem Problem, eine Arbeitsstelle zu finden wird der Problemraum durch Größen wie Arbeitsfreude, Bezahlung, Branche, Region aufgespannt. Bei Entwicklungsproblemen, wie z. B. der Entwicklung eines neuen Gerätes, einer Software, eines Autos oder eines Medikaments sind die zu implementierenden Funktionen, die Benutzerfreundlichkeit, der Entwicklungsaufwand und der Zeitbedarf wichtige Kriterien. J In vereinfachter, aber einprägsamer Form kann man folgendes Modell eines Problemlösungsprozesses skizzieren (Abb. 1.5). Die Problemdimensionen spannen einen Zustandsraum auf, der im Beispiel zweidimensional ist, also eine Zustandsebene bildet. Das Problem besteht darin, das System aus seinem Anfangszustand (links, unten) in seinen Zielzustand (rechts, oben) zu bringen, indem bestimmte Handlungen u in der richtigen Reihenfolge ausgeführt werden. Der Handlungsspielraum wird in der Regel durch Randbedingungen R eingegrenzt, die verbotene Bereiche definieren. Dabei kann es Randbedingungen (im Bild R1 bis R4) geben, die während des gesamten Problemlösungsprozesses einzuhalten sind und andere (R0), die nur nach Erreichen des Zielzustands gelten. Meist gibt es nicht nur eine einzige

Abb. 1.5 Zustandsraummodell des Problemlösungsprozesses

18

1

Abb. 1.6 Problemdimensionen Aufwand und Nutzen

Projekte

Problemdimensionen Aufwand Personalkosten Materialkosten Maschinenkosten Zeitaufwand Nutzen Funktionalität Benutzerfreundlichkeit

mögliche Lösung, sondern mehrere. Mit Hilfe eines Kriteriums J wird dann die Güte der Lösungen beschrieben, um die beste auswählen zu können. Die geschilderten Beispiele zeigen, dass es einige Kriterien gibt, die immer wieder als Problemdimensionen auftauchen. Hierzu zählen sicher die Kosten für eine Problemlösung, die für die Lösung benötigte Zeit, der erreichte Nutzen und die zur Verfügung gestellten Funktionen (siehe Abb. 1.6). In noch stärkerer Abstraktion könnte man den Aufwand für eine Lösung und den mit der Lösung erzielten Nutzen als die beiden dominierenden Problemdimensionen ansehen. Beide Dimensionen setzen sich i. a. aus mehreren unterschiedlichen Bestandteilen zusammen. Außerdem weisen beide Problemdimensionen eine starke Korrelation auf.

1.2.4

Prozesse

Das vorangehende Kapitel hat gezeigt, wie aus einer Aufgabe durch eine besondere Schwierigkeit ein Problem wird. Zur Lösung eines Problems muss dieses Hindernis beseitigt oder umgangen werden. Dies kann manchmal durch einen „Trick“ oder einen „Kniff“ erfolgen. Trickreiche Lösungen für „knifflige“ Rätselaufgaben sind schön für den, der den „Kniff“ findet, aber bei realen Problemen sind trickförmige Lösungen nur selten anzutreffen. Zur Lösung realer Probleme können Kniffe hilfreich sein, aber sie erfordern viel mehr Systematik als Trickreichtum. Reale Probleme und die dabei anzutreffenden Hindernisse sind meistens so vielgestaltig, dass die Problemlösung viele Arbeitsschritte erfordert und dementsprechend auch Zeit in Anspruch nimmt. Ein solcher Vorgang wird als Prozess bezeichnet: I

Ein Prozess ist ein zeitlicher Ablauf, der aus mehreren Vorgängen mit wechselseitigen Abhängigkeiten besteht.

Prozesse sind in vielen Bereichen zu finden. Ein verfahrenstechnischer Prozess besteht aus einer ganzen Reihe von Schritten, wie dem Befüllen eines Behälters, dem Aufheizen, dem Reagieren, dem Kühlen und dem Abfüllen. Ein Auto wird in einem Produktionsprozesse hergestellt, der mit dem Einlegen des Blechs in eine Werkzeugmaschine beginnt,

1.2

Systeme und Prozesse

19

über das Zusammenschweißen einzelner Blechteile, die „Hochzeit“ von Karosserie und Fahrwerk, den Einbau des Motors bis zum erstmaligen Starten des Motors und der Überführung zum Verladeort reicht. Auch ein juristischer Prozess ist ein aus vielen Schritten bestehender, oft langwieriger Vorgang mit ungewissem Ausgang, wie man hoffentlich nicht aus eigenem Erleben sondern höchstens aus der Kafka-Lektüre weiß. Auch die Lösung komplexer Probleme besteht aus vielen aufeinander aufbauenden Aktivitäten. Sie bilden in diesem Fall den Problemlösungsprozess. Ein Projekt besteht aus mehreren Arbeitsschritten, zwischen denen Abhängigkeiten bestehen und die nacheinander oder gleichzeitig bearbeitet werden können. Ein Projekt ist daher immer ein Prozess. Da viele Anforderungen die Lösung erschweren, liegt einem Projekt also ein Problem zugrunde. Ein Projekt ist daher ein Problemlösungsprozess: eine zeitlich und logisch gestaffelte Folge von Arbeitsschritten zur Lösung eines Problems. Aber nicht jeder Problemlösungsprozess ist auch ein Projekt. Beispiel 1.9 Das Damen-Problem

Wie viele Damen können auf einem Schachbrett untergebracht werden, ohne sich gegenseitig zu bedrohen, wie viele derartige Damen-Kombinationen gibt es und wie sehen diese aus? Damen können horizontal, vertikal und diagonal bewegt werden. Es ist offensichtlich, dass nicht mehr als 8 Damen auf ein Schachbrett passen. Die möglichen 8-DamenKombinationen und deren maximale Zahl sind dagegen nicht so einfach zu finden. Daher dauerte es auch zwei Jahre (von 1848 bis 1850), bis die Lösung des Problems gefunden wurde: Es gibt 92 gültige Kombinationen. Zu dieser Zeit waren sicherlich einige Projekt-Kriterien für das Problem erfüllt: Das Problem war neuartig, es war schwierig und erforderte eine ganze Reihe von Arbeitsschritten. Andererseits konnte es aber auch von einer Person gelöst werden. Es gab auch keinen definierten Zeitrahmen für die Lösung. Es gibt vergleichbare Probleme, bei denen ganze Generationen erfolglos nach einer Lösung suchten. Mit der Verfügbarkeit von Rechnern kann eine Lösung des Acht-Damen-Problems heute nicht mehr als Projekt eingestuft werden. Programmierkenntnisse vorausgesetzt kann das Problem in kurzer Zeit von einer Person gelöst werden. J Die ursprünglich schwierige Lösung des Damenproblems ist spätestens seit der Verfügbarkeit von Rechnern zu einem zwar interessanten, aber nicht allzu schwierigen programmiertechnischen Routineprozess geworden. Zu einem Projekt wird ein Problemlösungsprozess erst durch die Komplexität des zugrunde liegenden Problems und der für die Lösung erforderlichen Schritte. Die Komplexität kann sich auf verschiedene Art äußern, z. B. durch eine starke Vernetzung, oder durch fachliche Vielfalt. Komplexe Lösungen erfordern daher immer das Zusammenwirken mehrerer Personen. Weitere charakteristische Merkmale sind die Begrenzung der Ressourcen und der zur Verfügung stehenden Zeit. Die Abgrenzung der verschiedenen Aufgabentypen kann man in Form eines Mengendiagramms vornehmen (Abb. 1.7).

20

1

Projekte

Abb. 1.7 Begriffliche Abgrenzung von Projekten, Prozessen, Problemen und Aufgaben

Eine Aufgabe stellt so gesehen die geringste Anforderung, nämlich Zielklarheit. Durch besondere Schwierigkeiten und durch ihre Neuartigkeit wird eine Aufgabe zu einem Problem. Besteht der Lösungsweg aus mehreren zeitlich und logisch gestaffelten Schritten, so handelt es sich um einen Prozess: entweder um einen Routineprozess zur Lösung von einfachen Aufgaben oder um einen Problemlösungsprozess. Ein Projekt wird daraus durch die besondere Komplexität des Problems und der Lösung sowie durch die Begrenzung der verfügbaren Zeit und knapper Ressourcen. Die Entscheidung, ob es sich bei einem Vorhaben um eine Aufgabe, ein Problem oder ein Projekt handelt, ist keinesfalls von nur abstraktem Interesse. Die Überprüfung der Kriterien bringt vielmehr eine erste weiter gehende Einsicht in das Profil des Vorhabens und seine charakteristischen Eigenschaften. Außerdem liefert sie ganz konkrete Hinweise darauf, was an Methoden und Maßnahmen erforderlich ist, um das Vorhaben erfolgreich zu realisieren.

1.3 Projektmanagement 1.3.1 Der Projektmanagement-Prozess Ein Projekt besteht aus einer Vielzahl zusammenwirkender Arbeiten. Diese darf man sich aber nicht als einen gleichmäßig verlaufenden Fluss von Arbeiten vorstellen, bei dem an einer Stelle ein Auftrag in den Fluss geworfen wird, der an anderer Stelle ein Ergebnis ans Ufer spült (Abb. 1.8). Ein Arbeitsfluss hat kein Anfang und keine Ende. Viele Dinge sind zufällig und treiben ungeplant vor sich hin. Es ist nicht klar, wann der Fluss einen Output liefert, welchen Output er liefert und ob er überhaupt etwas liefert. Derartige Prozesse laufen unbewusst oft unter dem Motto: „Wir machen einfach mal und schauen dann was raus kommt.“ Auch wenn dies so drastisch formuliert vollkommen inakzeptabel klingt, gibt es in der Praxis oft

1.3

Projektmanagement A

A

21 A

Arbeitsfluss, Arbeitsabläufe

t E

E

E

Abb. 1.8 Stetiger Arbeitsfluss

„Projekte“, die genau so durchgeführt werden. Es wird viel gemacht und mit ein wenig Glück wird auch irgendwann irgendetwas an Land gespült. Mit einem systematischen, zielorientierten Vorgehen hat dies aber nicht viel zu tun. Im Gegensatz zum bloßen „Machen“ benötigt ein Projekt eine klare Aufgabenstellung mit konkreter Zielformulierung, Randbedingungen, Gütekriterien und ein überprüfbares Ergebnis sowie definierte Anfangs- und Endzeitpunkte. Außerdem müssen die Akteure mit Zuständigkeiten und Verantwortlichkeiten festgelegt werden. Dadurch wird aus einem ungeordneten Fluss von Arbeiten ein Projekt (Abb. 1.9). Ein Projekt darf aber nicht nur nach außen zeitlich und inhaltlich abgegrenzt werden. Auch intern benötigt es eine bestimmte Struktur. Obwohl selbstverständlich jedes Projekt bei genauer Betrachtung sein individuelles Aussehen besitzt, kann man bei genügender Abstraktion eine gemeinsame Grundstruktur erkennen. Jedes Projekt beinhaltet einen Problemlösungsprozess mit einem Problem als Input und einer Lösung als Output. Die für die Problemlösung erforderlichen Arbeiten beginnen mit einer Analyse der Aufgabe. Hier werden die Problemdimensionen erfasst, Anfangs- und Zielzustand beschrieben, die Hindernisse für eine einfache Problemlösung untersucht, die Randbedingungen und eventuell ein Gütekriterium formuliert. Im nächsten Schritt, dem Entwurf, werden mögliche Lösungen gesucht, auf ihre Tauglichkeit und ihre Vor- und Nachteile überprüft und dann die beste Lösung ausgewählt. Diese wird dann in der nächsten Phase, der Realisierung, praktisch umgesetzt. Die Projektdurchführung wird dann abgeschlossen durch eine Überprüfung der erreichten Resultate im Rahmen der Validierung. Sollte das gesteckte Ziel nicht vollständig erreicht worden sein, können weitere Durchläufe nötig sein. Im schlimmsten Fall muss bei der Validierung auch ein Scheitern des Projekts festgestellt werden (Abb. 1.10).

A

Projekt

E t

Abb. 1.9 Zeitlich und inhaltlich abgegrenztes Projekt

22

1

Projekte

Projektdurchführung A

Analyse

Entwurf

Real.

Valid.

E

Abb. 1.10 Grundstruktur einer (ungemanagten) Projektdurchführung

Damit ein Projekt möglichst nicht scheitert und damit auch der Zeitrahmen eingehalten wird, ist es nötig, die vielen einzelnen Arbeiten des Projekts zu planen, zu steuern und zu koordinieren. Hierzu dient das Projektmanagement. In seiner populären Bedeutung werden unter Management vorwiegend Tätigkeiten verstanden, die zur Führung eines Unternehmens benötigt werden. Hieraus leitet sich auch die Berufsbezeichnung des Managers ab. Die Wurzeln des Begriffs sind zu finden im englischen to manage und im italienischen maneggiare „an der Hand führen“, das sich wiederum vom lateinischen manus „Hand“ ableitet. Der englische Begriff „to manage“ hat ca. 12 bis 15 unterschiedliche, sich teilweise ergänzende oder überschneidende Bedeutungen. Zudem wurde der Begriff „Management“ fast schon inflationär auf viele Bereiche übertragen. Den verschiedenen existierenden theoretischen Definitionen und – viel wichtiger – den verschiedenen als „Management“ bezeichneten praktischen Tätigkeiten ist gemeinsam, dass es um die Planung und Steuerung von Prozessen geht. Management dient dazu, einen Prozess zum Ziel zu führen. Diesem Buch wird deshalb folgende minimalistische Definition von Management zugrunde gelegt: I

Management ist die Planung und Steuerung von Prozessen.

Diese Definition passt auf praktisch alle Management-Bereiche. Ein Unternehmensmanager hat das Ziel, das Unternehmen zum wirtschaftlichen Erfolg zu führen, um die Anforderungen der Anteilseigner nach Kapitalerhalt und Rendite und die Anforderungen der Arbeitnehmer nach einem sicheren und gut bezahlten Arbeitsplatz zu befriedigen. Wie bereits gesehen ist ein Projekt ein Problemlösungsprozess. Da dieser Prozess im Allgemeinen aus vielen Aktivitäten besteht, von mehreren Beteiligten getragen wird und den Einsatz von Ressourcen verlangt, ist auch für diesen Prozess ein Management erforderlich. Auch wenn es nicht immer ausdrücklich betont wird, soll dies unter Einhaltung der geplanten Termine und mit möglichst geringem Aufwand an Personal, Material und Kosten erfolgen. Als Spezialfall des allgemeinen Managements erhält man also folgende Definition: I

Projektmanagement ist die Planung und Steuerung der problemlösenden Prozesse von Projekten, um diese termingerecht und aufwandsminimierend zum Ziel zu führen.

1.3

Projektmanagement

23

Die Lösung eines Problems im Rahmen eines Projektes erfordert viele Arbeitsschritte und beansprucht viele Ressourcen. Deren Einsatz muss vor der Durchführung geplant und während der Durchführung gesteuert werden. Projektmanagement umfasst daher die Gesamtheit der Planungs- und Steuerungsmaßnahmen zur Durchführung eines Projekts. Aufgrund der Komplexität und der Limitierung in einem Projekt ist Planung notwendig. Dabei muss Inhalt, Abfolge und Terminierung der Arbeiten festgelegt werden. Der Einsatz der beteiligten Personen und der Ressourcen muss geplant werden sowie die zeitliche Verteilung der Kosten. Eine vollständige und perfekte Planung ist bei komplexen Prozessen nicht möglich. Deshalb muss die Durchführung der Arbeiten überwacht und bei Abweichungen vom Plan korrigierend eingegriffen werden. Dies ist die Aufgabe der Steuerung. Weitere Bestandteile des Projektmanagement sind die Projektdefinition zu Beginn und der Projektabschluss. Die Aktivitäten des Projektmanagement müssen, zumindest bei größeren Projekten ebenfalls geplant und gesteuert werden. Allerdings sollte der Anteil der Projektmanagement-Aktivitäten immer nur einen kleinen Teil der gesamten Projektaktivitäten ausmachen. Innerhalb eines Projekts können also die Realisierungs- und die Management-Aktivitäten unterschieden werden. Die Aussagen über einen notwendigen und ausreichenden Wert des Managementanteils variieren je nach Projekttyp und Projektgröße. Man kann aber davon ausgehen, dass ein sinnvoller Wert zwischen 5 und 15 % liegt. Die Zusammenfassung der Aktivitäten der Projektdurchführung und des Projektmanagements zeigt Abb. 1.11. Ein Projekt besteht aus einem Problemlösungsprozess, der in das Projektmanagement eingebettet ist. In der Darstellung kommen die logische und die grobe zeitliche Abfolge der einzelnen Aktivitäten zum Ausdruck. Im Detail kann es in jedem Projekt Abweichungen geben. So kommt es oft zu zeitlichen Überlappungen einzelner Aktivitäten und zu Schleifen. Der Arbeitsaufwand ist in den verschiedenen Projektphasen sehr unterschiedlich. Zu Beginn eines Projekts ist der Aufwand relativ gering. Er steigt dann mit zunehmender Projektdauer an und erreicht in der heißen Phase der Realisierung und Validierung den Höchstwert. Gegen Ende des Projekts lässt der Aufwand bei erfolgreichem Verlauf rasch nach. Zwischen den einzelnen Aktivitäten bestehen natürlich viel mehr Abhängigkeiten, als in einer einfachen, schematisierten Form darstellbar sind. Der Ablauf ist ein Prozess mit

Projektmanagement A

Definition

Planung

Analyse Projekt

Steuerung

Entwurf

Projektdurchführung

Abb. 1.11 Grobstruktur eines gemanagten Projekts

Real.

Abschluss

Valid.

E

24

1

Projekte

teilweise sequentiellen, teilweise parallelisierbaren Arbeitsabläufen, die im Idealfall einmalig, im Realfall aber auch in Schleifen mehrfach durchlaufen werden können. Es muss daher berücksichtigt werden, dass die verschiedenen Aktivitäten der Projektdurchführung nicht immer abrupt beginnen bzw. enden, sondern oft fließend in einander übergehen. Den starken zeitlichen Aspekt des Projektablaufs bringt der in der Literatur gebräuchliche Begriff des Projektmanagement-Lebenszyklus (PM-Lebenszyklus) zum Ausdruck: I

Der Projektmanagement-Lebenszyklus beschreibt das organisatorische Zusammenwirken und den zeitlichen Ablauf aller Aktivitäten in einem Projekt als eine zusammenhängende Einheit.

Im einfachsten Fall besteht ein Projekt aus genau einem solchen Zyklus. Dann ist PMLebenszyklus, gleich Projekt-Lebenszyklus. Umfangreichere Projekte setzen sich aber aus mehreren PM-Lebenszyklen zusammen. Jeder Zyklus bildet eine in sich geschlossene Projektphase. Aufgrund ihrer Struktur kann eine Projektphase auch als Teilprojekt gesehen werden. Teilprojekte wiederum können sequentiell nacheinander, aber auch parallel ablaufen.

1.3.2 Entwicklung des Fachgebiets Wahrscheinlich gibt es Projekte, seit es den Homo sapiens gibt. Spätestens aber mit dem Aufkommen von Ackerbau und Viehzucht musste der Mensch im Rhythmus der Jahreszeiten seine Aktivitäten vorausschauend planen und seine knappen Ressourcen einteilen. Möglicherweise wurde dabei auch schon Projektmanagement betrieben. Ohne Zweifel hatten derart gigantische Vorhaben wie der Bau der Pyramiden oder die Eroberung ferner Länder Projektcharakter und wären ohne geeignete Planung und Steuerung nicht erfolgreich gewesen. Der Anfang von Projektmanagement als systematische, wissenschaftliche Disziplin kann kaum exakt datiert werden. Frühe Verfahren zur Planung von Arbeitsabläufen wurden von Taylor und Gantt Ende des 19. Jahrhunderts entwickelt. Ein rasch ansteigendes Interesse fand das Projektmanagement in den 40er Jahren des 20. Jahrhunderts. Zunächst wurden für Teilgebiete Methoden auf wissenschaftlicher Basis erarbeitet. Insbesondere sind hier Planungsmethoden zu nennen, die auf Netzplänen basieren, wie z. B. PERT [Miller 1965], GERT [Pritsker 1966]. Es folgten erste Fachbücher zum Thema Projektmanagement: [Martino 1964; Schröder 1970; Zogg 1974; Martin 1976; Saynisch 1979]. Das aufblühende wissenschaftliche Interesse, die Ausgestaltung von Teilgebieten und die Entwicklung praxistauglicher Methoden führten zu stetig zunehmenden Erkenntnissen auf dem Gebiet, die sich auch im zunehmenden Umfang der veröffentlichten Monographien einzelner [Madauss 1983; Kerzner 1979; Burghardt 1988] oder mehrerer Autoren [Schelle 2004] äußerten.

1.3

Projektmanagement

25

Im Lauf der Zeit wurde das Fachgebiet immer weiter erschlossen und es entwickelten sich eigenständige Teilgebiete. Beispiele hierfür sind die Themen Konfigurationsmanagement [Saynisch 1984], Risikomanagement [Franke 1998], Management internationaler Projekte [Dülfer 1982] oder das Multiprojekt-Management. Außerdem gibt es eine Fokussierung auf die Anwendung des Projektmanagements in verschiedenen Anwendungsbereichen, wie der industriellen Forschung und Entwicklung [Platz 1986], dem Maschinenund Anlagenbau [Gareis 1991], dem Bauwesen [Rösch 1994; Greiner 2009] und der Verfahrenstechnik [Bernecker 2001]. Während lange Zeit ein Projekt als eine Ausnahmesituation in einem ansonsten starr organisierten Unternehmen mit festgelegten Arbeitsprozessen angesehen wurde, wird Projektarbeit immer mehr zum Normalfall. Projektarbeit ist sogar dabei, den Charakter der Unternehmensführung zu verändern [Rump 2010]. Je dynamischer sich das Geschäftsfeld eines Unternehmens entwickelt, umso mehr macht es Sinn, Methoden des Projektmanagements auch für die Führung des Unternehmens zu übernehmen. Im Extremfall können alle Aktivitäten eines Unternehmens als Projekte angesehen und damit das Unternehmen wie eine Multiprojekt-Organisation geführt werden („management by projects“). Mittlerweile gibt es eine kaum noch zu überblickende, stetig wachsende Zahl von Fach-, Hand- und Lehrbüchern zum Thema Projektmanagement. Dies spiegelt offensichtlich den Zustand eines sowohl in der Tiefe, als auch in der Breite rasch wachsenden Fachgebiets. Dieses Wachstum wird getrieben von den zunehmenden wissenschaftlichen Erkenntnissen, den steigenden praktischen Anforderungen und vom Bestreben, beide Entwicklungen auf einen gemeinsamen Nenner zu bringen. Aus diesem Grund wird es auch in den nächsten Jahren in dem sicherlich reifen, aber noch lange nicht ausgereiften Fachgebiet neue Prinzipien, neue Methoden und neue Werkzeuge geben. Angesichts der Stofffülle ist es für Anfänger im Bereich des Projektmanagements schwer, einen geeigneten Zugang zur Thematik zu finden. Das Problem wird zusätzlich dadurch erschwert, dass Projektmanagement in sehr unterschiedlichen Berufsbildern benötigt wird. Vor diesem Hintergrund wurde das vorliegende Buch als Lehrbuch konzipiert, das sich an Studierende und Berufstätige richtet, die im technischen Bereich tätig sind und einen einfachen, aber systematischen Einstieg in das Projektmanagement finden wollen.

1.3.3 Normen, Standards, Zertifizierung Die dynamische Entwicklung des Fachgebietes in den letzten Jahrzehnten hat zu einer Fülle von neuen Begriffen, Methoden und Abläufen im Projektmanagement geführt. Einerseits ermöglicht dies, die verschiedenen Aufgaben des Projektmanagements zu erfüllen, andererseits wird der Überblick und der Einstieg in das Thema durch die große Vielfalt aber erschwert. Nicht immer ist offensichtlich, wo eine neue Methode sich von anderen, existierenden Verfahren unterscheidet und wo der spezifische Vorteil liegt. Seit vielen Jahren gibt es daher Bestrebungen, durch eine Standardisierung und Normung für eine größere Transparenz zu sorgen. Verschiedene Organisationen und Interes-

26

1

Projekte

senverbände arbeiten an dieser Aufgabe. Allerdings gibt es bislang keinen einheitlichen Standard. Auf der Basis der verschiedenen Standards werden außerdem Schulungen und Prüfungen zur Zertifizierung der Projektmanagement-Qualifikationen angeboten. Die International Competence Baseline (ICB) ist ein Standard der International Project Management Association (IPMA). In der aktuellen Version 3.0 definiert sie drei Kompetenzbereiche: (PM-technischer, PM-Verhaltens- und PM-Kontext-Kompetenzbereich) mit insgesamt 46 Kompetenzelementen. Landesspezifisch wird die ICB als National Competence Baseline (NCB) umgesetzt. In Deutschland wird diese durch die Deutsche Gesellschaft für Projektmanagement (GPM) getragen, die bereits den PM-Kanon entwickelt hat. Das Hauptaugenmerk der ICB liegt auf der Zertifizierung. Sie besteht aus 4 Stufen, beginnend beim Projektmanagement-Fachmann (IPMA-Level D), über den zertifizierten Projektmanager (Level C), den Senior Projekt Manager (Level B) bis zum Projektdirektor (Level A). Ein international weit verbreiteter Standard ist der Project Management Body of Knowledge (PMBOK) des amerikanischen Project Management Institute (PMI). PMBOK ist vor allem eine Sammlung von Methoden, die sich im praktischen Einsatz bewährt haben. In der seit 2013 gültigen 5. Ausgabe des PMBOK sind 47 Prozesse definiert, die in 5 Gruppen gegliedert sind: Initiierung, Planung, Ausführung, Steuerung und Abschluss. Die Zuordnung dieser Gruppen zu den im vorliegenden Buch verwendeten Projektphasen ist offensichtlich. Das gesamte im Projektmanagement benötigte Wissen wird in 9 Gebiete unterteilt: Integrations-, Umfangs-, Termin-, Kosten-, Qualitäts-, Personal-, Kommunikations-, Risiko- und Beschaffungsmanagement. Die Zertifizierung gemäß PMBOK unterscheidet einen Certified Associate in Project Management (CAPM) und den Project Management Professional (PMP), der eine umfangreiche Berufserfahrung voraus setzt. Als dritter Standard soll PRINCE2 (Projects in Controlled Enviroments 2) erwähnt werden. Er beschreibt 7 Tätigkeitsprozesse: Vorbereiten eines Projekts, Initiieren eines Projekts, Steuern einer Phase, Managen der Phasenübergänge, Managen der Produktlieferung, Abschluss eines Projekts, sowie die übergreifenden Prozesse Planen und Lenken eines Projekts. Für die Zertifizierung gibt es zwei Niveaus: die grundlegende „Foundation Examination“ und die weiter gehende „Practitioner Examination“. Obwohl der PRINCE2Standard sehr praxisnah ausgelegt und weltweit stark verbreitet ist, hat er in Deutschland und Europa noch nicht die gebührende Beachtung gefunden. Neben den drei grundlegenden Projektmanagement-Standards gibt es zahlreiche weitere, zum Teil branchen- oder anwendungsspezifische Standards, wie z. B. das V-Modell XT, einem deutschen Standard für IT-Projekte im öffentlichen Dienst. Ebenfalls vom PMI stammt das Organizational Project management maturity Model (OPM3). Es beschreibt den Reifegrad einer Organisation, also z. B. eines Unternehmens, im Umgang mit den Prozessen des Projektmanagements. In 5 Stufen verläuft die Reifung von einem rudimentären, über einen dokumentierten, institutionalisierten, ordnungsgemäßen bis zu einem ausgereiften PM-Prozess.

1.3

Projektmanagement

27

Seit längerem existieren nationale Normen, von denen die DIN 69901 von besonderer Bedeutung ist, aber auch die britische BS 6079 nicht unerwähnt bleiben soll. Im Jahre 2012 veröffentlichte die ISO die internationale Norm ISO 21500. Sie ist als eine internationale Dachnorm für die bestehenden Standards und nationalen Normen konzipiert und enthält ein vollständiges Prozessmodell für das Projektmanagement. Das Management von mehreren parallel laufenden Projekten behandelt die Multiprojektmanagement-Norm DIN 69909. Parallele Projekte, die gemeinsame Ressourcen nutzen, werden dort als Projektportfolios bezeichnet. Besitzen die Projekte auch inhaltliche Gemeinsamkeiten, bilden sie ein Programm. Die VDI-Gesellschaft Systementwicklung und Projektgestaltung (VDI-GSP) hat das Berufsbild von Ingenieuren, die in Projekten arbeiten (Blatt 1) und die Anforderung an deren Qualifikation (Blatt 2) als Richtlinie VDI 6600 formuliert. Die benötigten Kompetenzen wurden in 5 Qualifikationsfelder unterteilt: in Management- und Führungskompetenzen, in soziale, fachlich-methodische und persönliche Kompetenzen. Die Bezeichnung „Projektingenieur VDI“ ist geschützt und kann erst nach Abschluss eines technischen Studiengangs und der Teilnahme an einem entsprechenden Lehrgang des VDI erworben werden. Der Lehrgang besteht aus 6 Modulen, die in mehreren Etappen absolviert werden. Viele der in diesem Buch erläuterten Methoden und Prinzipien sind auch in den Normen und Standards enthalten. Aufgrund der Konzipierung als einführendes Lehrbuch, zielt das vorliegende Buch aber nicht auf eine unmittelbare Vorbereitung zur Zertifizierung, sondern es soll Einsteigern in das Thema eine grundlegende und zugleich kompakte Einarbeitung ermöglichen. Soweit dies vom Umfang her machbar war, wurden die Standards berücksichtigt, so dass sich viele Methoden, Prozesse und Phasen sowie Kompetenzund Wissenselemente aus den Standards hier wieder finden. Für eine dauerhafte Arbeit im Projektmanagement, insbesondere bei großen Projekten, ist natürlich eine vertiefende Qualifizierung notwendig und deren Nachweis durch entsprechende Zertifikate sinnvoll.

1.3.4 Vorgehensmodelle Projekte sind durch sechs wesentliche Merkmale bestimmt: Existenz eines Ziels, Schwierigkeit der Aufgabenstellung, Prozesscharakter der auszuführenden Arbeiten, Bedarf an Organisation, Ressourcenbegrenzung und Terminierung. An jedem dieser Merkmale können sich Probleme ergeben: unklare oder veränderliche Ziele, hoher fachlicher Schwierigkeitsgrad, viele stark vernetzte Teilprozesse, viele beteiligte und betroffene Personen, strikt begrenzte Kostenbudgets und enge Termine, um nur einige, oft auftretende Problematiken zu benennen. Die Lösung jeder Problematik, die in einem konkreten Projekt auftritt, erfordert spezifische Maßnahmen. Auch wenn natürlich jedes Projekt individuell unterschiedlich ist, lassen sich zumindest bei ähnlicher Problematik, die passenden Lösungsmethoden auch auf andere Projekte übertragen. Steht z. B. der Termindruck bei einer bestimmten Kategorie von Projekten im Vordergrund, ist die starke Parallelisierung der Arbeiten eine

28

1

Projekte

hilfreiche Lösung. Auch für andere Problematiken können übergreifende Lösungswege gefunden werden. Dies ist die Grundidee des Projektmanagements, als eigenständiger Fachdisziplin. Im Laufe der Zeit wurde ein ganzes Bündel von Methoden und Werkzeugen für unterschiedliche Konstellationen zusammengetragen und dann zu einem durchgängigen System verallgemeinert. Das Ergebnis sind Vorgehensmodelle mit vielen zusammenwirkenden Methoden und Prozessen, die einen hohe Allgemeingültigkeit und breite Anwendbarkeit für sich in Anspruch nehmen. Das Grundprinzip der Standards besteht darin, jede Problematik hinsichtlich der sechs Projektmerkmale zu reduzieren und beherrschbar zu machen, indem      

Ziele möglichst präzise und vollständig definiert, fachliche Schwierigkeiten durch Bereitstellung geeigneter Kompetenzen eliminiert, alle benötigten Prozesse und Arbeiten bis ins Detail festgelegt, alle beteiligten Personen sehr strikt kontrolliert und geführt, die anfallenden Kosten budgetiert und kontrolliert, die Einhaltung der Termine in sehr engen Zeittakt gesichert wird.

Zum einen führt diese Ansatz aber zu sehr umfangreichen „monumentalen“ PM-Standards, deren Erlernen und Anwenden viel Aufwand erfordert und deren Anwendung bei kleinen oder mittleren Projekten oft in Frage gestellt wird. Zum anderen hat sich gezeigt, dass auch eine noch so buchstabengetreue Anwendung der Standards bei vielen Projekten nicht den erhofften Erfolg gebracht hat. Statt nun die Standards noch weiter auszudehnen und damit die Probleme noch zu vergrößern, haben an mehreren Stellen Gegenbewegungen eingesetzt. Sie wollen die „starren“ und „monumentalen“ Standards durch „schlanke“ und „flexible“ Vorgehensmodelle ersetzen. Diese Zielsetzungen kommen auch in den Namensgebungen der Modelle zum Ausdruck: es wird von agilem PM, von effektivem PM oder von Lean-PM gesprochen. Die „alten“ Standards werden dagegen als „traditionell“, „klassisch“ oder „konventionell“ bezeichnet. In den neuen Ansätzen stecken viele sinnvolle Ideen und sie bieten auch viele praktisch nützliche Methoden und Werkzeuge, die eine Reihe bisher ungelöster Problematiken lösen können. Agile Vorgehensmodelle z. B. stellen Methoden bereit, die mit unklaren und veränderlichen Zielen umgehen können. Sie erreichen dies, indem sie selbstorganisierende Projektteams aufbauen, die mit starker Kundeneinbindung arbeiten und im Zieldreieck der Qualität den Vorrang vor Kosten und Terminen einräumen. Projekte, deren Charakteristik zu diesen Vorgaben passen, können mit agilen Methoden nachgewiesenermaßen positive Ergebnisse erzielen. Dort wo die „neuen“ Vorgehensmodelle versprechen, die alten vollständig abzulösen, ersetzen sie ein altes Problem durch ein neues: es kann nicht das allgemeingültige Vorgehensmodell für alle Projekte geben – egal ob es „alt“ oder „neu“ ist. Das Versprechen, dass mit einem neuen Modell oder einem neuen Denken alle bisherigen Probleme in Projekten oder in Unternehmen gelöst sind, mag ein zugkräftiges Verkaufsargument für Bücher,

1.3

Projektmanagement

29

Schulungen oder Zertifikate sein – einzuhalten ist es nicht. Als Ergebnis dieser Erkenntnis tauchen vermehrt Veröffentlichungen auf, in denen „traditionelles“ und „modernes“ PM zum „hybriden“ PM zusammengeführt werden. Es gibt kein „altes“ und ein „neues“ PM, sondern passende und unpassende Methoden. Es gibt etablierte Methoden, die sich in vielen – aber bei weitem nicht allen – Projekten bewährt haben. Es gibt neue Methoden, die bisher ungelöste Probleme lösen können und es verbleiben darüber hinaus noch viele ungelöste Probleme in Projekten, zu denen es möglicherweise in den nächsten Jahren weitere hilfreiche Methoden geben wird. Projektmanagement ist eine Disziplin, die es in der praktischen Anwendung sicherlich schon sehr lange und in ihrer wissenschaftlichen Ausprägung seit etlichen Jahrzehnten gibt. Im Laufe der Zeit hat sich eine gewisse Grundstruktur heraus gebildet mit einer Reihe von Arbeitsprozessen, die Probleme lösen, die praktisch in jedem Projekt auftauchen: die Definition und Gründung des Projekts, die mehr oder weniger präzise Planung des Ablaufs, die Ausrichtung der Personen auf gemeinsame Ziele sowie das Management der Kosten, der Qualität und der Risiken. Je nach Projektcharakteristik und -größe müssen diese PM-Prozesse in unterschiedlicher Weise durch konkreten Methoden mit Leben gefüllt werden. Daher ist es wichtig, ein möglichst umfangreiches Repertoire an Methoden – einen Werkzeugkasten – zu besitzen, in den man beim Auftreten konkreter Probleme zielsicher greifen kann. Deshalb werden in diesem Buch sowohl „traditionelle“ als auch „moderne“ Methoden vorgestellt und vermittelt.

1.3.5 Fallbeispiele Ein praxisorientiertes Lehrbuch darf die beschriebenen grundlegenden Prinzipien und Methoden des Projektmanagement nicht nur theoretisch erläutern, sondern es muss deren Anwendung an möglichst konkreten und möglichst unterschiedlichen Beispielen veranschaulichen. Allerdings sind reale Projekte zu umfangreich, um diese in allen Details dazustellen. Außerdem erfordert das Nachvollziehen der Problematik von Projektmanagement nicht nur das Verständnis einer konkreten fachlichen Aufgabenstellung, sondern es setzt auch Einsicht in organisatorische Strukturen des Unternehmens voraus, in dem ein Projekt durchgeführt wird. Um diese gegensätzlichen Anforderungen widerspruchsfrei zu erfüllen, wird in diesem Buch die Anwendung der Prinzipien und Methoden zunächst an vereinfachten Beispielen erläutert und anschließend an konkreten, durchgängig verwendeten Fallbeispielen vertieft. Diese Fallbeispiele basieren auf praktischen Erfahrungen des Autors als Projektleiter, Geschäftsführer und Unternehmensberater. Sie wurden aber so weit abstrahiert, dass der Umfang für ein Lehrbuch geeignet ist und die fachliche Wissensbasis der zugrunde liegenden realen Projekte und Unternehmen geschützt bleibt. Alle Fallbeispiele wurden deshalb bei einem fiktiven Unternehmen angesiedelt, den Steinbachwerken, einem mittelständischen Hersteller von Produktionsmaschinen. Die Steinbachwerke entwickeln, bauen und liefern komplette Maschinen bestehend aus

30

1

Projekte

Mechanik, elektronischer Steuerungen und Software. Dabei gibt es sowohl Standardmaschinen, die in kleinen Serien mit unterschiedlichen Varianten produziert werden, als auch Sondermaschinen, die im Kundenauftrag neu entwickelt und aufgebaut werden. Mit seinen 400 Beschäftigten generiert das Unternehmen einen jährlichen Umsatz von 100 Mio. C. Unterhalb der Geschäftsleitung gliedern sich die Steinbachwerke in die Bereiche Vertrieb, Technik, und Betriebswirtschaft. Der Vertriebsbereich ist in mehrere Vertriebsregionen unterteilt. Der Bereich Technik gliedert sich in die Abteilungen Konstruktion, Elektronikentwicklung, Softwareentwicklung, Mechanik-Produktion, Elektronik-Fertigung, Montage und Service. Zum Bereich Betriebswirtschaft gehören die kaufmännische Abteilung, die Personalabteilung, die Betriebsabteilung, der Einkauf sowie Lager und Logistik. Im Unternehmen gibt es verschiedene Vorhaben, die als Projekte durchgeführt werden sollen und im weiteren Verlauf des Buches als Fallbeispiele herangezogen werden. Beispiel 1.10 Fallbeispiel „Maschinenterminal M4“

Die Maschinen der Steinbachwerke werden mit eigenen Steuerungsterminals ausgerüstet. Diese dienen zum automatischen Betrieb der Maschinen, besitzen eine interaktive Benutzerschnittstelle und können an ein Firmennetzwerk angeschlossen werden. Das Terminal ist modular aufgebaut und besteht aus einem eigenen Gehäuse, verschiedenen Elektronikbaugruppen, wie z. B. CPU-Baugruppe, Ein-/Ausgangs-Baugruppen, Netzwerkkarte, Bildschirm und Tastatur. Außerdem ist die Steuerung frei programmierbar. Das bestehende Terminal vom Typ M3 wird seit mehr als 10 Jahren eingesetzt. Gestiegene Leistungsanforderungen sowie zunehmende Bauteilabkündigungen machen es erforderlich, einen Nachfolger mit der Typenbezeichnung M4 zu entwickeln. J Beispiel 1.11 Fallbeispiel „Solaranlage“

Die bestehende Ölheizung des Bürogebäudes und der Produktionshalle verursacht aufgrund des steigenden Ölpreises jährlich steigende Kosten. Da der Ölbrenner aber erst vor 5 Jahren erneuert wurde, soll er nicht ausgetauscht, sondern durch Solarkollektoren unterstützt werden. Zur Anbringung der Kollektoren ist das Dach der Maschinenhalle geeignet, dessen nach Südosten ausgerichtete Hälfte eine nutzbare Fläche von 450 m2 besitzt. Im Rahmen eines Projektes soll die Halle mit einer solarthermischen Energieversorgung ausgerüstet werden. J Beispiel 1.12 Fallbeispiel „CAD-Software“

Bei den Steinbachwerken werden die Konstruktionszeichnungen für alle mechanischen Teile seit etlichen Jahren mit Hilfe eines CAD-Systems erstellt. Das System ist allerdings veraltet und wurde vom Hersteller abgekündigt. Aufgrund massiver Kompatibilitätsprobleme sieht sich der Hersteller nicht in der Lage ein Upgrade des alten auf sein neues System anzubieten. Daraufhin beschließen

1.3

Projektmanagement

31

Projekte

1

Problemlösungsprozesse

2

Integr. A

St, Rs, Cm

Scope

Time

3

4

5

ProjektGründg.

ProjektOrga.

ProjektStrukt.

6

Risk 7

Schätzg. Ablauf-/ TerminPlanung

Cost 8

RisikoMan.

Quality 9

KostenMan.

10

Qual.Man.

Projektplanungs- und -organisaonsdokumente E

Projektsteuerung

11

Projektsteuerungsdokumente Der Mensch im Projekt

12

Soware-Werkzeuge

13

Abb. 1.12 Zuordnung der Buchkapitel zu den Prozessgruppen der ISO 21500

die Steinbachwerke, sich ohne Festlegung auf den bisherigen Hersteller nach geeigneten Systemen umzuschauen und ein neues System auszuwählen und in der Konstruktion einzuführen. J

1.3.6 Gliederung des Buchs Die Gliederung des vorliegenden Buchs richtet sich in erster Linie nach dem typischen Ablauf in einem Projekt, folgt zugleich der internationalen PM-Norm ISO 21500, die den Rahmen für viele Normen gibt. Die Norm teilt alle Aktivitäten innerhalb eines Projekts in 39 Prozesse ein. Diese sind in insgesamt 10 Themengebieten gegliedert und 5 Prozessgruppen zugeordnet. Die ISO 21500 beschreibt, was im Rahmen des Projektmanagements zu tun ist. Sie beschreibt nicht, wie es zu tun ist. Das vorliegende Buch soll sowohl das Verständnis für das „Was?“ als auch für das „Wie?“ vermitteln. Als einführendes Lehrbuch ist es auf die gut nachvollziehbare Vermittlung der notwendigen Grundlagen, Methoden und Werkzeuge und deren praktischer Anwendung ausgerichtet. Normative und didaktische Anforderungen müssen kein Widerspruch sein. In Abb. 1.12 ist die Zuordnung der Buchkapitel zu den Themengebieten Integration, Stakeholder (St), Ressources (Rs), Communication (Cm), Scope, Time, Risk, Cost und Quality der ISO 21500 zu erkennen. In der oberen Hälfte des Diagramms sind die Prozesse der Projekt-Initiierung und -Planung mit dem Auftrag (A) als Eingabe dargestellt. Die Arbeitsergebnisse dieser Prozesse sind die Dokumente der Projektplanung und -organisation. Diese bilden den Input für die Prozesse der Projektdurchführung. Die dort entstehenden Dokumente der Projektsteuerung bilden einen rückgekoppelten Wirkungskreis, an dessen Ende das Projektergebnis (E) steht.

32

1

Projekte

Im ersten Kapitel des vorliegenden Buchs wird der Hintergrund für PM-Aktivitäten grundlegend untersucht und beschrieben. Kap. 2 erläutert die Grundstruktur der Problemlösungsprozesse, die in jedem Projekt zu finden sind. Dann folgen die verschiedenen Arbeitsabläufe des Projektmanagements, angefangen von der Projektgründung (Kap. 3) und der Projektorganisation (Kap. 4) über die Strukturplanung (Kap. 5), die Aufwandsschätzung (Kap. 6) sowie die Ablauf- und Terminplanung (Kap. 7) bis hin zum Risikomanagement (Kap. 8), dem Kostenmanagement (Kap. 9), dem Qualitätsmanagement (Kap. 10) und der Projektsteuerung (Kap. 11). Projekte werden von Menschen gemacht und Menschen müssen im Projekt zusammenarbeiten. Die Bedeutung des Menschen im Projekt verdient daher eine gesonderte Beachtung (Kap. 12). Die Planung von Projekten mit Hilfe von Software-Werkzeugen wird beschrieben und am Beispiel von MS-Project erläutert (Kap. 13). Den Abschluss des Buchs bildet eine Beschreibung agiler PM-Methoden (Kap. 14). Eine detaillierte Zuordnung der Teilkapitel des Buchs zu den einzelnen Prozessen der ISO 21500 und den Kompetenzelementen der IPMA ICB3 und der GPM NCB3 zeigt Abb. A.1 im Anhang. Dort sind auch die wichtigsten Dokumente getrennt nach Planung und Organisation sowie Überwachung und Steuerung von Projekten dargestellt.

1.4 Weiterführende Literatur Es gibt sehr viele Bücher, die das Thema PM in allgemeiner Form darstellen, auf bestimmte Teilgebiete eingehen oder aus Sicht der Anwendung von PM in bestimmten Bereichen behandeln. Die folgenden, allgemeingültig angelegten und regelmäßig aktualisierten Werke sind zur Vertiefung in das Thema sehr gut geeignet. Kerzner, H.: Project Management, a Systems Approach to Planning, Scheduling and Controlling. Wiley-Verlag, 12. Aufl. 2017. Stellt das Thema PM aus dem System-Ansatz heraus sehr umfassend und angelehnt an den Standard des PMBOK dar. Madauss, B.: Projektmanagement. Springer-Verlag, 8. Aufl. 2020. Behandelt alle Teilgebiete des PM nicht nur aus theoretischer, sondern auch in praxisnaher Sichtweise. Patzak, G.; Rattay, G.: Projektmanagement. Linde-Verlag, 7. Aufl. 2017. Beim Management einzelner Projekte beginnend wird darüber hinaus gehend das Multiprojektmanagement behandelt sowie projektorientiert arbeitende Unternehmen. Wysocki, R.K. Effective Project Management. Wiley-Verlag, 7. Aufl. 2017. Stellt das „traditionelle PM“ im Vergleich zum „agilen“ und „extremen“ PM dar.

2

Projekte als Problemlösungsprozesse

In diesem Kapitel lernen Sie den spoc-Problemlösungsprozess kennen, der aus Problemanalyse (study), Lösungsentwurf (plan), Realisierung (operate) und Validierung (check) besteht. Zunächst werden Methoden vorgestellt, die das vollständige Erkennen und Strukturieren von Problemen ermöglichen. Anschließend lernen Sie, wie man von abstrakten, „wolkigen“ Zielvorstellungen in mehreren aufeinander aufbauenden Schritten zu einem konkreten, strukturierten Zielsystem gelangt. Sie werden sehen, wie man Ziele geeignet formuliert und wie man zwischen Gütekriterien und Randbedingungen unterscheidet. Danach werden Sie mit dem systematischen Suchen nach Ideen für eine Problemlösung vertraut gemacht. Nach der Beschreibung kreativitätsfördernder und -hemmender Faktoren erlernen Sie die wichtigsten Methoden für eine gezielte Ideenproduktion. Aus mehreren möglichen Lösungen muss schließlich die am besten passende ausgewählt werden. Hierfür braucht man Entscheidungsverfahren. Sie werden die Besonderheiten intuitiver, qualitativer und analytischer Ansätze zur Entscheidungsfindung kennen lernen. Die weit verbreitete Nutzwertanalyse wird detailliert erläutert, so dass Sie diese im praktischen Einsatz beherrschen.

Nach der Bearbeitung des Kapitels sind Sie in der Lage,  die Grobstruktur und die 4 Phasen des allgemeinen Problemlösungsprozesses zu beschreiben,  ein Problem zu analysieren, indem Sie seine Bestandteile erkennen, diese strukturieren und das Ziel der Problemlösung formulieren,  ausgehend von einer abstrakten Zielwolke ein konkretes Zielsystem, bestehend aus Zielkriterien, Zielvariablen, Randbedingungen und Gütekriterien zu erstellen,

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 W. Jakoby, Projektmanagement für Ingenieure, https://doi.org/10.1007/978-3-658-32791-0_2

33

34

2 Projekte als Problemlösungsprozesse

 die wichtigsten Methoden zu benennen, die man zum Entwurf von Lösungen eines Problems benötigt,  die wichtigsten Verfahren der Ideenfindung, -bewertung und -auswahl in praktischen Aufgaben selbständig anzuwenden,  die Suche nach Ideen zur Lösung eines Problems als kreativen und systematischen Prozess der Ideenproduktion zu gestalten,  mit Hilfe verschiedener Verfahren zur Prioritäts- und Nutzwertbestimmung aus mehreren Lösungsmöglichkeiten die beste auszuwählen.

2.1

Modelle des Problemlösens

2.1.1 Vorgehensmodelle des Problemlösens Den Ausgangspunkt eines Problems bildet ein Sachverhalt, der sich zu jedem Zeitpunkt in einem bestimmten Zustand befindet. Die Aufgabe von Problemlösern ist es, diesen Sachverhalt aus dem vorgefundenen Anfangs- in einen angestrebten Zielzustand zu überführen. Das Ziel kann von außen vorgegeben oder aber auch selbstdefiniert sein. Es kann ein neu definiertes, innovatives Ziel sein oder die Wiedererlangung eines „Normalzustandes“ nach dem Wirken einer Störung (Abb. 2.1). Die Lösung eines Problems besteht aus einer Sequenz von Handlungen die auf den Sachverhalt angewendet werden, um diesen gezielt zu beeinflussen. In der Regel sind diese Handlungen abhängig von Beobachtungen, die die Problemlöser laufend vornehmen, um Informationen über den jeweiligen Zustand des Sachverhalts zu gewinnen. Zur Festlegung geeigneter Handlungen greifen Problemlöser auf verfügbares Wissen zurück, das gleichzeitig durch die ausgewerteten neuen Beobachtungen stetig erweitert wird. Geschlossene Probleme stellen idealisierte Situationen dar, bei denen es neben dem passiven problematischen Sachverhalt nur die Problemlöser als einzige aktive Instanz gibt. Prüfungsaufgaben, Denksportaufgaben oder Rätsel sind typische Beispiele dieser Kategorie. Probleme der realen Welt dagegen sind fast immer offene Probleme: Neben den Problemlösern gibt es ein neutrales Umfeld, das in zufälliger, nicht vorhersagbare Weise auf den Sachverhalt einwirkt. Noch gravierender sind die Wirkungen von Gegenspielern. Sie haben nicht nur eigene, divergierende Ziele, sondern sie wirken so auf den Sachverhalt ein, dass die Ziele der Problemlöser konterkariert werden. Der Aktivitätsablauf beim Lösen von Aufgaben und Problemen ist sicherlich genau so vielfältig wie die zu lösenden Aufgabenstellungen. Betrachtet man den Schwierigkeitsgrad eines Problems als wesentliches Unterscheidungsmerkmal, so gibt es zwei grundlegende Vorgehensweisen. Bei geringem Schwierigkeitsgrad kann auf umfangreiches Vorwissen zum Sachverhalt zurückgegriffen werden. Aus der verfügbaren Menge bekannter

2.1 Modelle des Problemlösens

35 (neutrales) Umfeld

Problemlöser

Ziel

Handlungen Beobachtungen

Wissen

Gegenspieler

(problemat.) Sachverhalt

Zustand

Abb. 2.1 Systemisches Modell des Problemlösens

Lösungen, werden geeignete Maßnahmen ausgewählt. Deren Reihenfolge wird geplant, so dass der Lösungsweg dann gedanklich vorweggenommen werden kann. Anschließend erfolgt die Umsetzung der geplanten Maßnahmen. In seiner Reinform kann man dieses Vorgehen als „plan&do (p&d)“ bezeichnen: Zuerst wird ein vollständiger Lösungsplan entworfen, dann wird er verwirklicht (Abb. 2.2, links). Als formalisiertes Modell ist dieses Vorgehen als PDCA-Schema bekannt: beim Auftreten eines Problems wird eine Lösung geplant (plan), dann wird sie umgesetzt (do), auf ihre Wirksamkeit überprüft (check) und schließlich dauerhaft eingesetzt (act). Am entgegengesetzten Ende des Vorgehensspektrums findet sich das Modell „try&error (t&e)“ (Abb. 2.2, rechts). Bei schwierigen Problemen ist das Wissen über den Sachverhalt zunächst sehr lückenhaft. In diesem Fall müssen mehr oder weniger zufällig experimentelle Lösungsversuche unternommen werden. Die Erwartung richtet sich in diesem Fall weniger auf einen Zufallstreffer, als auf einen Erkenntnisgewinn. Je mehr Erkenntnisse über den problematischen Sachverhalt gewonnen werden, desto stärker kann sich das zufällige, „blinde“ Probieren zu einem zielgerichteten Versuchen entwickeln. Auch für diese Verhaltensweise gibt es ein formalisiertes Schema, das so genannte TOTE-Modell. Zunächst wird ein Problem in Gestalt einer Abweichung zwischen einem erwünschten Zielzustand und einem unerwünschten Istzustand festgestellt (Test), Durch eine Handlung wird versucht, die Diskrepanz zu beseitigen (Operate). Anschließend werden Soll- und Istzustand wieder miteinander verglichen (Test). Konnte das Problem beseitigt werden, wird die Aktivität beendet (Exit). Ist das nicht der Fall, werden weitere Lösungsversuche unternommen. Da „p&d“ auf der einen und „t&e“ auf der anderen Seite die beiden Extrema eines Spektrums an Vorgehensweisen zur Lösung unterschiedlich schwieriger Probleme

p&d s p o c

t&e s study p plan o operate c check

plan do t

s p o c t

Abb. 2.2 Elementare Vorgehensmodelle des Problemlösens

try

try er

try er

er t

36

2 Projekte als Problemlösungsprozesse

darstellen, muss jede dazwischenliegende Vorgehensweise Elemente beider Extremfälle beinhalten (Abb. 2.2, mitte). Sowohl bei „p&d“ als auch bei „t&e“ ist die Handlungskomponente anzutreffen, bei der Maßnahmen ausgeführt werden: „do“ bzw. „try“. Diese Komponente soll im Weiteren als „operate“ bezeichnet werden. Bei vollständigem Vorwissen über den Sachverhalt, kann eine Lösung vollständig vorausgeplant werden. Ist das Vorwissen lückenhaft, kann die Lösung zwar nicht vollständig, aber zumindest teilweise geplant werden. Eine Planungskomponente wird auf jeden Fall enthalten sein. Das Überprüfen der erreichten Lösung wird bei unvollständigem Wissen und damit unvollständigem Plan ebenfalls notwendig sein. Diese Komponente soll statt der etwas pessimistisch stimmenden Bezeichnung „error“ durch den neutralen Begriff „check“ beschrieben werden. Eine vierte Komponente kommt zwar weder in „p&d“ noch in „t&e“ explizit vor, kann aber dennoch als selbstverständlicher Bestandteil angenommen werden, nämlich die Analyse des vorgefundenen Sachverhalts (study). Eine Analyse ist sowohl bei einfachen Aufgaben vor Beginn der Planung als auch bei schwierigen Problemen vor dem Ausprobieren von Maßnahmen notwendig. Wie die weiteren Untersuchungen bestätigen werden, ist diese Analyse-Phase in sehr vielen detaillierter ausgearbeiteten Vorgehensmodellen enthalten. Man erhält somit das spoc-Modell mit 4 Phasen des Problemlösens:  „study“: Nach dem Auftreten und Erkennen eines Problems werden zunächst Informationen zum problematischen Sachverhalt gesammelt. Sie werden analysiert und als Modell des Sachverhalts und des angestrebten Zielzustands strukturiert.  „plan“: Die nächste Phase besteht aus den verschiedenen Schritten der Lösungssuche: Es werden Lösungsideen gesammelt und zu möglichen Lösungswegen zusammengesetzt. Aus den möglichen Lösungen wird schließlich eine als beste oder erfolgversprechendste ausgewählt.  „operate“: Nach der Entscheidung für eine grundsätzliche Lösung wird diese detailliert ausgearbeitet und verwirklicht.  „check“: Das erreichte Ergebnis wird überprüft. Es wird entschieden, ob das Problem vollständig gelöst wurde oder ob ein weiterer Durchlauf der 4 spoc-Phasen erforderlich ist. Außerdem werden gewonnene Erkenntnisse gesichert. Hinsichtlich des Ablaufs weist das planvolle Lösen unproblematischer Aufgaben einen rein sequentiellen Charakter auf, während bei schwierigen Problemen das iterative Vorgehen sehr stark ausgeprägt ist. Beide Ablaufmuster werden also bei den dazwischenliegenden Schwierigkeitsgraden benötigt. Der Gesamtablauf besteht daher aus dem sequentiellen Durchlaufen der 4 Komponenten study-plan-operate-check. Für die zu erwartenden Wiederholungen sind zunächst Rücksprünge zur unmittelbar vorangehenden Phase möglich. Erweist sich dagegen die erreichte Lösung in der „check“-Phase als gar nicht oder nicht vollständig zielführend, müssen alle Schritte in einer vollständigen Iteration erneut durchlaufen werden.

2.1 Modelle des Problemlösens

2.1.2

37

Der allgemeine Problemlösungsprozess

Das spoc-Modell beschreibt ein Vorgehen zur Lösung von Problemen, das aufgrund seiner starken Abstraktion für beliebige Problemlösungen geeignet ist. Das Modell beinhaltet „plan-and-do“ sowie „try-and-error“ als Extremfälle eines ganzen Spektrums von Vorgehensweisen. Bei einfacheren Aufgaben ist der Ablauf vorwiegend sequenziell. Mit zunehmendem Schwierigkeitsgrad des Problems nimmt der Ablauf dagegen einen immer stärker iterativ geprägten Charakter an. Neben dem Schwierigkeitsgrad spielt auch die Komplexität des problematischen Sachverhalts eine wichtige Rolle bei der Gestaltung der Lösungsschritte. Mehrere Faktoren tragen zur Komplexität eines Problems bei: die Zahl der Bestandteile, die zu dem Sachverhalt gehören, die Stärke der Vernetzung, die Zahl der erforderlichen Lösungsschritte sowie die Klarheit oder Unklarheit der Zielsetzung. Auch bei komplexen Problemen ist das spocModell zur Gliederung der Vorgehensweise geeignet, aber es kann hier weiter untergliedert werden. Aus einer vergleichenden Untersuchung existierender Vorgehensmodelle, wie z. B. dem DMAIC-Zyklus aus dem Qualitätsmanagement, dem Grochla-Vorgehensmodell für Verwaltungsprozesse, dem REFA-Modell zur Gestaltung von Arbeitsabläufen, dem IDEALS-Konzept oder dem System-Engineering kann ein Prozessmodell entworfen werden, das sich aus insgesamt 8 Teilprozessen zusammensetzt (Abb. 2.3). Jeder Prozess besitzt Eingaben, die in mehreren Schritten verarbeitet werden, woraus ein bestimmtes Ergebnis erzeugt wird. Den Input für die gesamte Problemlösung bilden verschwommene Sichtweisen der aktuellen Situation („Problemnebel“) und unklare Vorstellungen über die zu erreichenden Ziele („Zielwolke“). Zunächst wird das Problem benannt und abgegrenzt. Diese explizite Problemdefinition bildet den Rahmen für die folgenden problemlösenden Schritte. Zu Beginn ist ein Problem oft nur sehr unklar und diffus bekannt. Es gibt z. B. Symptome, die einen unerwünschten Zustand kennzeichnen. Aufgrund der unklaren, verschwommenen Sichtweise soll hier von einem Problemnebel gesprochen werden: Man befindet sich in einem unklaren Zustand, hat keinen richtigen „Durchblick“ und erkennt nur hin und wieder Details, die aber danach wieder verschwinden. Bevor an eine Lösung gegangen werden kann, muss dieser Nebel gelichtet werden. Das Problem muss abgegrenzt werden: Woraus besteht das Problem? Was gehört zum Problem und was nicht? Das Ergebnis dieses Prozesses ist eine dokumentierte Problembeschreibung. Der notwendige Umfang einer Problembeschreibung richtet sich selbstverständlich nach dem Problemumfang, Bei einfachen Problemen können wenige Sätze zur Beschreibung ausreichen. Umfangreiche Probleme können Dutzende von Seiten umfassen. Generell sollte man sich vor der Annahme hüten, dass alles „eh klar“ wäre. Dies gilt schon nicht, wenn nur eine einzige Person betroffen ist und bei mehrere Personen sind anfängliche Unklarheiten unvermeidbar und machen eine gemeinsame Problembeschreibung unumgänglich. Das Ergebnis ist ein Modell des problematischen Sachverhalts, aus dem der aktuelle Zustand aber auch mögliche Eingriffe erkennbar werden.

38

2 Projekte als Problemlösungsprozesse

Abb. 2.3 Die Problemlösungsprozesse des spoc-Modells

Dies gilt auch für das Ziel. Bei weitem nicht immer ist klar, was erreicht werden soll und es schon gar nicht allen Beteiligten in gleicher Weise klar. Am Anfang liegen diffuse Vorstellungen, Anforderungen und Erwartungen vor. Da diese Vorstellungen ähnlich verschwommen sind, wie der Problemnebel, sich aber zunächst außerhalb der Reichweite der Beteiligten befindet, soll hier von einer Zielwolke gesprochen werden. Aus ihr muss im Prozess „Ziel bilden“ ein Zielsystem gemacht werden. Darunter ist eine konkret abgegrenzte Sammlung von Teilzielen zu verstehen, die bei umfangreichen Zielsetzungen hierarchisch gegliedert werden. Außerdem müssen die angestrebten Ziele konkret formuliert werden, die Zielerreichung muss überprüfbar sein und die Priorität der angestrebten Teilziele muss festgelegt sein. Nach der Analyse liegen eine Problemdefinition, ein Modell des problematischen Sachverhalts und eine systematische Zielformulierung vor. Auch wenn die Teilprozesse im Ablauf nacheinander dargestellt sind und in der Regel auch in dieser Reihenfolge ausgeführt werden, können die Aufgaben auch parallel bearbeitet werden. Auch eine iterative Vorgehensweise kann sinnvoll sein, bei der zunächst die groben, wichtigen Problembestandteile und Zielvorstellungen erfasst werden. Anschließend werden beide dann verfeinert. Nach der Analyse- folgt die Planungsphase. Sie startet mit dem Teilprozess „Lösungsideen suchen“. Wie der Name schon andeutet, ist dies ein offener, kreativer Prozess.

2.1 Modelle des Problemlösens

39

Oft muss hier mit dem Problem und den Zielen experimentiert werden, um Lösungsmöglichkeiten zu finden. Bei umfangreichen Problemen ist die Lösung ein hierarchisch gegliedertes Gebilde. Daher kann es sinnvoll sein, zunächst einmal Lösungen für Teilprobleme zu suchen, um aus diesen dann eine mögliche Gesamtlösung zusammenzusetzen. Manche Teilprobleme können dabei hart zu knackende Nüsse sein, während bei anderen auf Erfahrungen mit ähnlichen Problemen zurückgegriffen werden kann. Liegen Teillösungen vor, sollte man auch versuchen, diese zu verändern, um weitere Lösungsvarianten zu finden. Liegen genügend Ideen vor, kann man an den Entwurf von Lösungen gehen. Die Betonung liegt hier auf der Mehrzahl: es sollten mehrere Lösungsalternativen konstruiert werden. Keinesfalls darf man sich mit einer Lösung begnügen. Die erstbeste Lösung ist zwar die erste, aber nicht die beste! Erst wenn mehrere Lösungen vorliegen, gibt es berechtigte Hoffnung, dass die beste dabei ist. Außerdem verringert sich das Risiko böser Überraschungen bei der Realisierung der Lösung und mehrfacher Durchläufe durch den Lösungsprozess, die erheblichen Mehraufwand verursachen. Im Teilprozess „Entscheidungen treffen“ werden die Lösungsalternativen anhand des Zielsystems bewertet. Dies darf man sich aber nicht einfach nur als mathematischen Algorithmus vorstellen, der aus Bewertungen und Gewichtungen die optimale Lösung liefert. Nicht immer spiegelt das zu Beginn erstellte Zielsystem die tatsächliche Intention der Beteiligten exakt wieder. Während der Zielsuche werden oft zusätzliche Erkenntnisse gewonnen. Sie liefern Anhaltspunkte für eine Überarbeitung des Zielsystems. Erst dadurch wird sichergestellt, dass das Zielsystem die tatsächlichen Erwartungen wiedergibt. Außerdem sollte man die aus der Berechnung sich ergebende optimale Lösung mit seinen Erwartungen vergleichen. Stimmt das mathematische Ergebnis mit den intuitiven Erwartungen überein? Wo gibt es Unterschiede? Wodurch kommen diese zustande? Liegt der Fehler bei der Intuition oder bei der Systematik? Das Ergebnis der Entscheidung ist eine ausgewählte Lösung. Da sie sich in der Regel aus einer Vielzahl von Teillösungen zusammensetzt, die in mehreren Schritten realisiert werden, wird hier von einem Lösungsweg gesprochen. Die Realisierung einer komplexen Lösung ist ein arbeits-, zeit- und kapitalaufwändiges Vorhaben. In jedem Schritt können hier Fehler auftreten, die Korrekturen und Nacharbeiten erforderlich machen. Aus diesem Grund wurden die Lösungsvarianten, die der Entscheidung zugrunde gelegt wurden, nur grob ausgearbeitet. Aus Gründen der Aufwandsminimierung wird dann nur die ausgewählte Lösung, detailliert ausgearbeitet. Hierzu dient der Teilprozess „Lösung ausarbeiten“, der bereits zur „Operate“-Phase zählt. Das Ergebnis ist ein detailliert geplanter Lösungsweg. Im nächsten Teilprozess „Lösung realisieren“ wird der Plan dann in die Tat umgesetzt. Liegt eine Realisierung vor, muss überprüft werden, ob sie die Anforderungen erfüllt. Hierzu wird die erreichte Lösung mit dem Zielsystem verglichen („Lösung überprüfen“). Bei einem komplexen Problem, mit einer umfangreichen Lösung ist es praktisch nicht zu vermeiden, dass an einzelnen Stellen Diskrepanzen auftreten. Hier wird dann Nacharbeit nötig. Oft liefern die Realisierung der Lösung und der anschließende Vergleich mit dem

40

2 Projekte als Problemlösungsprozesse

Ziel aber auch zusätzliche Erkenntnisse, die für eine Optimierung genutzt werden können. Hierzu dient der letzte Teilprozess „Lösung optimieren“. Er ermöglicht, das Potential, das in einer Lösung steckt und die während des Lösungsprozesses gewonnenen Erkenntnisse bestmöglich zu nutzen. Zur Ausführung der Arbeiten in den beschriebenen Teilprozessen der Problemlösung gibt es eine ganze Reihe von erprobten Vorgehensweisen, Methoden und Werkzeugen. Sie sollen in den nächsten Kapiteln im Detail vorgestellt werden. Die Vorgehensweisen für die „Operate“ und die „Check“-Phase sind sehr problemspezifisch. Die Aufgaben der „Study“- und der „Plan“-Phase können dagegen allgemeiner dargestellt und vom einzelnen Anwendungsfall stärker abstrahiert werden. Deshalb konzentriert sich die Darstellung hier auf die Teilprozesse „Problem verstehen“, „Ziele setzen“, „Lösungen suchen“ und „Entscheidungen treffen“.

2.1.3 Vorgehensmodelle der Projektdurchführung Ein Projekt ist ein großer Problemlösungsprozess, in dem viele kleiner Problemlösungsprozesse enthalten sein können. In einem Projekt – egal ob gemanagt oder ungemanagt – geht es darum, ein Produkt zu erzeugen, das vorgegebene Anforderungen erfüllt. Die 4 Phasen der Problemlösung in einem Projekt werden bezeichnet als    

study: Analyse der Aufgabenstellung plan: Entwurf eines zielführenden Projektergebnisses (Produkt) operate: Realisierung des geplanten Produkts check: Validierung des erreichten Ergebnisses

Das nahe liegende Vorgehensmodell für die Durchführung eines Projekts ist es, die 4 Phasen der Problemlösung mit ihren vielfältigen Aktivitäten nacheinander zu durchlaufen. Da die Ergebnisse der Arbeiten aus einer Phase den Input für die Arbeiten der nächsten Phase darstellen, wird dieses Modell als Wasserfallmodell bezeichnet (Abb. 2.4, links). Das Wasserfallmodell hat den Vorteil der Übersichtlichkeit. Es liegt eine strikte Phasentrennung vor. Mit den Arbeiten einer Phase wird erst dann begonnen, wenn alle benötigten

s An. p Ent. o c

s An. p Ent. Real. o c

Real. Val.

t

Val.

t

Abb. 2.4 Wasserfallmodell und Simultaneous Engineering als Extremfälle möglicher Vorgehensmodelle

2.1 Modelle des Problemlösens

41

Ergebnisse der vorangehenden Phase vollständig vorliegen. Wesentlicher Nachteil ist natürlich die lange Laufzeit. Eine Verkürzung der Laufzeit lässt sich erreichen, wenn die Phasentrennung aufgehoben wird und Arbeiten verschiedener Phasen zumindest teilweise parallel ausgeführt werden. Bei Engineering-Projekten wird dies als Simultaneous Engineering bezeichnet. Dieses Vorgehensmodell wurde in den 1980er Jahren propagiert und mit vielen Erwartungen bedacht. Bei weitem nicht alle Hoffnungen haben sich erfüllt. Viele Projekte scheiterten und es trat Ernüchterung ein. Am deren Ende war erkennbar, dass Simultaneous Engineering Vorteile besitzt, dass aber viele offene Fragen der konkreten Durchführung zu klären sind. Seitdem wurden in verschiedenen Teilbereichen Verbesserungen für die parallelisierte Projektdurchführung erreicht. Bei der Vielzahl von Arbeiten, die in Projekten zu leisten sind, gibt es große Unterschiede hinsichtlich der Wichtigkeit und Auswirkung. Bei manchen Arbeiten handelt es sich um bloße Fleißarbeiten. Die Ergebnisse anderer Arbeiten haben weit reichende Konsequenzen: sie können viel oder wenig Folgearbeiten nach sich ziehen und manche Arbeiten ermöglichen erst Aussagen über die grundsätzliche Machbarkeit. Um nun möglichst frühzeitig Klarheit im Projekt zu gewinnen, ist es sinnvoll die wichtigen Arbeiten so früh wie möglich auszuführen und die Fleißarbeiten nach hinten zu verschieben. Dies ist das Grundkonzept des Spiralmodells (Abb. 2.5, links). Der Problemlösungsprozess wird mehrmals vollständig durchlaufen. Im ersten, schnellen Durchlauf werden die wichtigsten Fragen des Projekts geklärt. Mit der dadurch gewonnen Klarheit werden dann in der zweiten Iteration die nächsten wichtigen Arbeit ausgeführt. Da keine Parallelisierung erfolgt, wird der Gesamtdurchlauf durch das Projekt nicht kürzer als beim Wasserfallmodell, aber es wird viel früher Klarheit gewonnen und im worst-case, bei fehlender Machbarkeit, kann ein Projekt auch frühzeitig beendet werden. Ein weiteres iteratives Vorgehensmodell ist in agilen Projekten zu finden. Hier wird die Laufzeit des Projekts in mehrere gleich große Intervalle unterteilt. Diese so genannten Sprints dauern etwa 4 Wochen und liefern immer ein Teilergebnis. Jeder Sprint kann einen vollständigen Problemlösungsprozess darstellen, so dass also immer alle 4 Phasen durchlaufen werden. Es kann aber auch sein, dass z. B. die Analyse als Ganzes vorab ausgeführt wird und dann in jedem Sprint nur noch Entwurf, Realisierung und Validierung erfolgen. Die agilen Modelle treffen keine Festlegung hinsichtlich der Parallelisierung. Die Arbeiten der verschiedenen Phasen können innerhalb des Sprints wasserfallartig nacheinander

An. En. Re. Va.

An. En. Re. Va. 1. It.

2. It.

3. Iteraon

t

1. Sprint

2. Sprint

Abb. 2.5 Iterative Vorgehensmodelle: Spiralmodell (links) und Scrum (rechts)

3. Sprint

t

42

2 Projekte als Problemlösungsprozesse

ausgeführt werden. Es spricht aber auch einiges dafür, hier eine Überlappung zuzulassen. Die Menge an Arbeiten innerhalb eines Sprints ist deutlich geringer als im Gesamtprojekt, so dass berechtigter Anlass zur Hoffnung besteht, dass simultanes Arbeiten innerhalb des Sprints zum Erfolg führt.

2.1.4

Vorgehensmodelle für gemanagte Projekte

Ein ungemanagtes Projekt dient in erster Linie dazu, am Ende das gewünschte Projektergebnis vorzulegen. Eine explizite Planung und Steuerung der Aktivitäten erfolgt nicht. In kleinen Projekten und bei eingespielten Teams kann dies durchaus zum gewünschten Ziel führen. Sind diese Bedingungen nicht erfüllt oder werden an die Kostenlimitierung und an die Termintreue höhere Anforderungen gestellt, muss ein Projekt gemanagt werden. Genauso wie die Projektdurchführung stellt auch das Projektmanagement einen Problemlösungsprozess dar. Er kann ebenfalls in vier Phasen unterteilt werden:    

study: (Initiierung und) Definition des Projekts plan: Planung des Projektablaufs operate: Steuerung der Projektdurchführung check: Abschluss des Projekts

Projektdurchführung und Projektmanagement stellen also zwei parallele, gekoppelte Problemlösungsprozesse dar. Hinsichtlich der Kopplung gibt es je nach Projekt unterschiedliche Varianten, aber in erster grober Näherung kann man die Projektdefinition und die Planung als Vorstufe der Projektdurchführung sehen, zu der wiederum die Projektsteuerung parallel liegt. Nach Vorliegen des angestrebten Ergebnisses erfolgt dann der Projektabschluss (Abb. 2.6). In vielen Fällen liegen zu Beginn eines Projekts nicht genügend Informationen vor, um eine Planung der Arbeiten bereits vornehmen zu können. In diesem Fall ist es sinnvoll, zunächst eine grobe Analyse und auch einen groben Entwurf des angestrebten Ergebnisses durchzuführen, so dass weiter gehende Einsichten in die notwendigen Arbeiten und den Aufwand gewonnen werden kann. Dies kann z. B. in Gestalt eines Vorprojekts oder einer Machbarkeitsanalyse erfolgen. Damit kommt man zu dem dargestellten Vorgehensmodell für gemanagte Projekte.

Abb. 2.6 Vorgehensmodell für gemanagte Projekte

PM Df. Pl. An. En. Re. Va.

Steuerung An. Ent.

Ab.

Real. Val.

t

2.2 Methoden und Werkzeuge zur Problemanalyse

43

Die Projektdurchführung ist hier als Wasserfallmodell dargestellt. Es steht hier lediglich stellvertretend für die verschiedenen, zuvor vorgestellten Vorgehensmodelle.

2.2 Methoden und Werkzeuge zur Problemanalyse 2.2.1

Problemerkennung

Die Problemanalyse ist ein Vorgang, bei dem der Problemraum schrittweise aufgespannt wird. Sie beginnt mit der Wahrnehmung der Existenz des Problems. Dann werden dessen Bestandteile bestimmt und deren Wechselwirkungen untersucht. Nur selten sind die Probleme offensichtlich und klar. Reale Probleme äußern sich in der Regel nur in Form bestimmter Symptome. Die eigentlichen Problemursachen müssen erst mühsam lokalisiert werden, bevor eine Lösung des Problems angegangen werden kann. Die erste wichtige Leistung ist das Erkennen, dass es überhaupt ein Problem gibt. Erst danach kann der Gegenstand des Problems, sein Umfang, seine Bestandteile, deren Wechselwirkungen und eventuelle Bedingungen erkannt werden. Zu Beginn, wenn noch wenig über das Problem bekannt ist, geht es darum, möglichst viele Informationen zu sammeln. In dieser Phase kann jede Information wichtig und hilfreich sein. Daher sollten nicht voreilig Informationen als unwichtig abgetan oder verworfen werden. Scheinbar unwichtige Details können sich später doch als wichtig herausstellen oder sie bilden den Auslöser für die Suche nach weiteren Erkenntnissen. Das Suchen nach Informationen zu einem Sachverhalt, von dem noch wenige Kenntnisse vorliegen, ist ein kreativer Vorgang. Damit der Erfolg aber nicht vollkommen dem Zufall überlassen wird, ist es notwendig, die Suche zu strukturieren. Hier helfen verschiedene Frageschemata. Sehr grundlegend sind die 4-Was-Fragen (Tab. 2.1). Sie richten ihren Fokus auf die aktuelle Situation, auf den angestrebten Zustand, auf Handlungsund Vorgehensoptionen und auf die Schwierigkeiten. Die 4-Was-Fragen stellen daher den idealen Einstieg in die Problemerkennung dar. Bei einfachen Problemen können sie sogar schon ausreichend sein. Da viele Beobachtungen nur die Symptome eines Problems wiedergeben, müssen die Ursachen erforscht werden. Hierzu dienen die 5-Warum-Fragen. Ein beobachtetes Phänomen wird dabei hinterfragt („Warum ist das so?“). Auch die in der Antwort gefundene

Tab. 2.1 4 Was-Fragen zur Problemerkennung Was Was Was

Frage ist gegeben? ist gesucht? ist zu tun?

Was

ist schwierig?

Alternativfragen Wo stehe ich? Was ist mein Anfangszustand? Wo will ich hin? Was ist mein Zielzustand? Welche Handlungsmöglichkeiten habe ich? Welche Operatoren gibt es? Woraus besteht die „Problematik“? Was könnte schief gehen?

44

2 Projekte als Problemlösungsprozesse

Ursache wird in der gleichen Art weiter hinterfragt, bis die eigentliche Problemursache gefunden wurde. Die Anzahl der geforderten Wiederholungen ist dabei nicht unbedingt wörtlich zu nehmen. Sie soll nur signalisieren, dass sehr ausdauernd nachgefragt werden muss, bis man zum Kern des Problems gelangt ist. Bei komplexen Problemen werden viele weitere Informationen gebraucht. Sie können durch umfangreichere Kataloge mit detaillierteren Fragen erschlossen werden. Dies können Fragen nach Ort, Zeit und Personen sein, die mit dem Problem zu tun haben. Weitere Fragen sollten sich auf den Gegenstand, die Ursache und Erscheinungsform des Problems richten. Man gelangt so zu den 6-W-Fragen: Was? Wie? Warum? Wer? Wo? Wann? Weitere Dimensionen können sich eröffnen, wenn man dann das Interesse nicht alleine auf das Problem richtet, sondern auch auf sein Gegenteil (das „Nicht-Problem“) und auf die mögliche Lösung. Damit ergibt sich bereits eine ganze Reihe von Fragen, wie z. B. in Tab. 2.2 dargestellt. Es existieren etliche weitere Vorschläge für geeignete Fragenkataloge. Wichtiger als die spezielle Zusammensetzung des Katalogs scheint aber zu sein, dass es überhaupt einen Fragenkatalog gibt, den man als „Navigator“ für die Informationssammlung verwendet und abarbeitet. Selbst wenn nicht alle diese Fragen zu nützlichen Antworten führen, ergibt sich fast immer ein buntes Antwortmosaik, das die wichtigen Bestandteile des Problems erkennbar macht. Außerdem können die Antworten weitere Fragen provozieren, die dann zusätzliche Mosaiksteine liefern. Kleine Fehler, die zu Beginn der Analyse gemacht werden, können zu gravierenden Fehlern bei der Lösung führen. Manches Problem wird dadurch nur unvollständig oder gar nicht gelöst. Bei anderen Lösungen ist der Aufwand größer als nötig. Die Aufgabe der Problemerkennung kann man auch so formulieren, dass es darum geht, das tatsächliche Problem und das Bild, das sich jemand davon macht, in möglichst gute Deckung miteinander zu bringen.

Tab. 2.2 6-W-Fragen zur Problemerkennung Problem Was? Wie? Warum? Wer? Wo? Wann?

x x x x x x

NichtProblem x x x x x x

Lösung

Beispiele

x x x x x x

Was ist nicht das Problem? Wie äußert sich das Problem? Warum ist es für andere kein Problem? Wer ist betroffen/nicht betroffen vom Problem? Wo und wann tritt das Problem auf? Wann wird die Lösung spätestens gebraucht?

2.2 Methoden und Werkzeuge zur Problemanalyse

2.2.2

45

Problemstrukturierung

Die bei der Problemerkennung gesammelten Informationen werden im nächsten Schritt ausgewertet: Die gefundenen Mosaiksteine werden untersucht und zu einem Bild zusammengesetzt. Das Ziel dieser Strukturierung ist es, das Zusammenwirken der Problembestandteile und damit das Verhalten des Problemgegenstands zu verstehen. Auch hierbei ist eine strukturierte Vorgehensweise sinnvoll. Den Ausgangspunkt bildet die Frage nach dem Problemgegenstand, also dem System, das gemäß der Definition des Problembegriffs aus dem Anfangs- in den Zielzustand geführt werden soll. Die Frage, was zum System gehört und was nicht, ist keineswegs akademischer Natur. Nur das was zum System gehört, kann Bestandteil der Lösung werden. Alles andere gehört zur „Umgebung“ kann also durch die Problemlöser nicht beeinflusst werden. Als nächstes werden die Größen gesucht, die im System veränderlich sind. Sie legen das Verhalten des Systems fest und nur sie können gezielt beeinflusst werden, um ein gewünschtes Verhalten zu erzeugen. Systemgrößen können sehr unterschiedlicher Art sein, z. B. die Zahl der Mitarbeiter in einer Abteilung, die Verfügbarkeit einer Maschine, die Kosten für ein Projekt, der Termin für eine Lieferung oder die Verkaufszahlen für ein Produkt. Wichtig ist es, den Bereich zu kennen, in dem der Wert einer Größe liegen kann. Eine Größe kann nur wenige diskrete Werte annehmen oder aber stetig veränderlich sein. In diesem Fall kann der Wertebereich nach oben und unten begrenzt sein. Da die verschiedenen Bestandteile eines Systems in Wechselwirkung stehen, gibt es auch Beziehungen zwischen den Systemgrößen. Diese müssen im nächsten Schritt gesucht und analysiert werden. Von besonderer Bedeutung für das Systemverständnis sind kausale Beziehungen. Ist eine Größe die Ursache und eine andere die Wirkung, so kann dieses Wissen zur gezielten Systembeeinflussung genutzt werden. Ein Hilfsmittel zur Darstellung kausaler Beziehungen zwischen Systemgrößen ist das Ursache-Wirkungs-Diagramm. Für eine Systemgröße werden alle Faktoren gesucht, die auf die Größe einwirken. Sie werden dann gruppiert, so dass zwischen Haupt- und Neben-Ursachen unterschieden werden kann. Von Ishikawa wurde eine standardisierte graphische Form des Diagramms entwickelt, das aufgrund seiner speziellen Darstellungsweise zuweilen auch als „Fischgrätdiagramm“ bezeichnet wird. Um nicht bei jeder Suche nach den Einflussfaktoren für eine Größe bei Null anzufangen, gibt es Vorschläge für allgemeingültige Haupt-Ursachen, die dann zur Suche nach konkreten Faktoren innerhalb jeder Gruppe verwendet werden. In einprägsamer Form werden die Haupt-Ursachen z. B. durch die 4-M-Methode gekennzeichnet: Mensch, Maschine, Material, Methode. Bei der 7-M-Methode kommen ergänzend Milieu (Umgebung), Management und Money (Kosten) hinzu. Ein Ursache-Wirkungs-Diagramm ist geeignet, die Wirkungskette für eine Systemgröße möglichst vollständig zu erfassen. Bei jedem Problem gibt es aber viele Größen die beeinflusst werden. Außerdem kann eine beeinflusste, abhängige Größe selbst wieder auf andere einwirken. Somit entsteht in der Regel nicht nur eine baumartige Struktur, sondern

46

2 Projekte als Problemlösungsprozesse

ein verzweigtes Wirkungsnetz mit parallelen und seriellen Kopplungen sowie mit Rückkopplungen. Das Netz der Wechselwirkungen kann als Beziehungsdiagramm dargestellt werden. Während beim Ursache-Wirkungs-Diagramm tatsächlich auf Vollständigkeit Wert gelegt wird, muss man sich beim Beziehungsdiagramm wegen der Vielzahl der Wechselwirkungen oft auf die wichtigen, dominierenden Wirkungen beschränken, um das Netz übersichtlich und handhabbar zu halten. Wenn dies gelingt, ist das Beziehungsdiagramm ein gutes Hilfsmittel, um das gesamte Beziehungsgeflecht einer Problemstellung zu erfassen und eventuell auch grundlegende Muster, wie z. B. Wirkungsketten oder rückgekoppelte Wirkungskreise zu erkennen. Andererseits kann das Diagramm bei realen Problemen recht umfangreich werden, so dass sein Nutzen sehr stark davon abhängt, ob es gelingt, zwischen dominanten und subdominanten Beziehungen zu unterscheiden. Das Beziehungsdiagramm stellt nur die Existenz und die Richtung einer Kausalbeziehung dar. Deren Intensität muss in einer getrennten Diagnose ermittelt werden. Eine wichtige Methode dabei ist die so genannte ABC-Analyse. Die Stärke des Einflusses verschiedener Faktoren auf eine Größe wird hierbei in drei Klassen eingeteilt, um sich später auf die wichtigen Faktoren konzentrieren zu können. Die Zuordnung eines Faktors zu einer Klasse kann qualitativ oder quantitativ erfolgen. Bei der qualitativen Klassifizierung werden die Faktoren nach ihrer Bedeutung zugeordnet: A-Faktoren besitzen große, BFaktoren mittlere und C-Faktoren geringe Bedeutung. Die Festlegung der Bedeutung und die Grenzziehung zwischen den drei Klassen ist natürlich subjektiv, dafür aber mit geringem Aufwand machbar. Transparenter sind quantitative Klassifizierungen. Hierbei muss die Bedeutung jedes Einflussfaktors durch einen Zahlenwert ausgedrückt werden. Dies gelingt in vielen Fällen recht gut, z. B. durch statistische Methoden oder durch Befragung und Punktvergabe innerhalb einer Bewertungsgruppe, kann aber oft auch problematisch sein. Liegt eine numerische Bewertung der Faktoren vor, lässt sich die Klassifizierung z. B. durch eine Pareto-Analyse vornehmen. Sie untersucht die Einflussstärke verschiedener Größen auf einen bestimmten Sachverhalt. Dabei ist zu beobachten, dass die Verteilung der Einflussstärke verschiedener Größen oft sehr stark von der Gleichverteilung abweicht. Auch wenn dies nicht immer und in konkreten Zahlen fast nie exakt gilt, wird dieses nach seinem Entdecker benannte Pareto-Prinzip oft mit der so genannten 80/20-Regel gleich gesetzt: Das wichtigste Fünftel der Einflussgrößen verursacht 80 % der Wirkung, die restlichen vier Fünftel tragen nur 20 % zur Wirkung bei. Diese verblüffende Beobachtung ist in sehr unterschiedlichen Realitätsbereichen zu finden: 80 % des Umsatzes eines Unternehmens werden mit den wichtigsten 20 % der Produkte und mit 20 % der Kunden gemacht; 80 % eines Textes bestehen aus den 20 % häufigsten Wörtern; 20 % der Familien eines Landes besitzen 80 % des Kapitals. Das Pareto-Prinzip kann man zur Analyse der Bedeutung von Einflussfaktoren auf eine Größe nutzen. Dazu werden die numerisch bewerteten Einflussfaktoren in einer Tabelle der Größe nach sortiert. Dann werden die Bedeutungswerte aufsummiert. Die wichtigsten Einflussfaktoren, die in der Summe 80 % der Wirkungen verursachen, sind die A-Fakto-

2.3 Methoden und Werkzeuge zur Erstellung eines Zielsystems

47

ren, die nächsten 16 % sind B-Faktoren und die restlichen 4 % – oft ist dies die größte Gruppe – sind C-Faktoren. Das Idealziel der Problemstrukturierung, ist ein vollständiges Strukturmodell des Problemgegenstands, mit allen Systemgrößen und deren exakten Wechselwirkungen. Aber auch wenn dieses Ziel nur selten erreicht werden kann, liefert die Problemanalyse viele Erkenntnisse über die Struktur des Problemgegenstands. Aus diesen Strukturkenntnissen können dann wichtige Aussagen über das Systemverhalten gewonnen werden. Dazu werden die Systemgrößen unterschieden nach Zustandsgrößen, Stellgrößen und Messgrößen. Stellgrößen sind alle Größen, die von außen, d. h. vom Problemlöser direkt geändert werden können. Außerhalb des Systemkontexts entsprechen die Stellgrößen den Handlungsalternativen, die zur Problemlösung zur Verfügung stehen. Die Stellgrößen wirken auf die Zustandsgrößen des Systems. In ihnen sind alle Informationen über das weitere Verhalten des Systems gespeichert. Alle Energie-, Materie- und Informationsspeicher stellen Zustandsgrößen des Systems dar. Die Messgrößen, schließlich sind die Größen, deren Wert dem Problemlöser zugänglich sind. Nicht immer sind die Zustandsgrößen direkt beobachtbar, sondern sie können nur indirekt über die Messgrößen ermittelt werden. Im Idealfall ist jede Zustandsgröße direkt einstellbar und zu jedem Zeitpunkt bekannt.

2.3

Methoden und Werkzeuge zur Erstellung eines Zielsystems

2.3.1 Von der Zielwolke zum Zielsystem Zielorientiertes Handeln ist in sehr vielen Bereichen ein ausgeprägtes Qualitätsmerkmal: in Stellenausschreibungen wird es als Einstellungskriterium hervorgehoben, in Arbeitszeugnissen dient es zur Kennzeichnung einer hervorragenden Arbeitsweise, die Zielvereinbarung („Management-by-objectives“) wird seit langem als Instrument der transaktionalen Mitarbeiterführung eingesetzt, zur Organisation von Teams werden alle Beteiligten auf die gemeinsamen Ziele ausgerichtet und bei der Führung von Unternehmen wird die Zielbildung als zentrale Aufgabe des Managements eingestuft. Wird von „dem“ Ziel gesprochen, so suggeriert dies die Existenz eines einzigen, einfachen Ziels, was in der Realität kaum gegeben ist. Umfassende Ziele sind in der Regel abstrakt und setzen sich aus einer Fülle von Teil- und Einzelzielen mit zunehmenden Konkretisierungsgrad zusammen. Zwischen den Teilzielen bestehen Wechselwirkungen. Sie können sich gegenseitig ergänzen, sie können miteinander konkurrieren oder aber auch voneinander entkoppelt sein. Die Kenntnis der bestehenden Kopplungen ist für die richtige Umsetzung des Gesamtziels notwendig. Komplexe Vorhaben, die sich aus vielen Maßnahmen zusammensetzen und über längere Zeiträume erstrecken, bergen die Gefahr, dass das Ziel zwischendurch aus den Augen verloren wird. Die Verwirklichung von Zielen erfordert wiederum eine ganze Reihe von Maßnahmen und Aktivitäten. Es ist daher bei weitem nicht selbstverständlich, dass allen Beteiligten in jeder Phase der Aktivitäten, die Ziele bewusst sind. Dies gilt in ganz beson-

48

2 Projekte als Problemlösungsprozesse

derem Maße, wenn Ziele zentraler Bestandteil einer vertraglichen Vereinbarung zwischen Auftraggeber und Auftragnehmer sind. Angesichts dieses nur kurz skizzierten Szenarios, bestehend aus  der Wichtigkeit von Zielen für die Aktivitäten,  deren komplexer Strukturierung und  des Prozesscharakters der Zielverwirklichung, ist die Formulierung, Dokumentierung und Kommunikation von Zielen von essentieller Bedeutung. Dass diese Bedeutung sich nicht immer in entsprechendem Handeln manifestiert, belegt die Erfahrung, dass die häufigste Ursache für das Scheitern von Projekten bei den Anforderungen und Zielen zu finden sind: Projekte scheitern, vor allem wegen unvollständiger, unklarer und veränderlicher Anforderungen und Ziele! Die Situation zu Beginn eines Problemlösungsprozesses, wie er in Projekten stattfindet, ist dadurch gekennzeichnet, dass in den Köpfen der Beteiligten Vorstellungen über den angestrebten Zustand existieren. Aber statt klarer Ziele gibt es Wünsche, Träume, Visionen, Wertvorstellungen, Gefühle. Ziele können aber auch aus negativen Faktoren, wie z. B. unbefriedigenden Situationen, Mangelerscheinungen oder Fehlverhalten entstehen. Tendenziell sind die Ursprünge von Zielen („wir wollen ein erfolgreiches Produkt“, „ein gesundes Unternehmen“, „eine funktionierende Partnerschaft“) eher abstrakt, undeutlich abgegrenzt und nicht näher begründbar. Derartige Formulierungen bilden gewissermaßen eine „Zielwolke“ (Abb. 2.7). Ein abstraktes Ziel lässt aber keine konkrete Handlungsvorschrift zu. Oft können sogar mit dem gleichen Ziel gegensätzliche Handlungen begründet werden. Als Anfang für eine Zielfindung ist diese Situation normal und akzeptabel. Sie vereinfacht das Formulieren, da man sich um konkrete Aussagen über das Erreichen bzw. Nicht-Erreichen der Ziele drücken kann. Um aber konkrete Handlungen ableiten zu können, müssen auch die Ziele konkret formuliert werden. Der Übergang von einer wolkigen Vorstellung über das, was bei einer Problemlösung erreicht oder verhindert werden soll, zu konkreten, überprüfbaren Zielen besteht aus mehreren Schritten. Hierbei werden vage Vorstellungen nach und nach verdichtet, so dass manchmal das Bild eines Zieltrichters verwendet wird. Da aber gleichzeitig auch unpassende Zielvorstellungen herausgefiltert werden, müsste das Bild des Trichters mit dem

Visionen

Werte Träume Vorstellungen Erwartungen Anforderungen Gefühle Wünsche Absichten Mängel

Abb. 2.7 Ablauf der Zielbildung

Ziele setzen 1. Zielvorstellungen erfassen 2. Ziele formulieren 3. Zielsystem erstellen

1. Zielkatalog 2. Zielbaum 3. Zielsystem

2.3 Methoden und Werkzeuge zur Erstellung eines Zielsystems

49

eines Siebes kombiniert werden. Am Ende der Zielformulierung sollte ein abgegrenztes Zielsystem mit konkreten Kriterien und überprüfbaren Variablen stehen. Zunächst müssen die „in der Wolke“ schwebenden Zielvorstellungen erfasst werden. Das Ergebnis ist eine mehr oder weniger lange Liste von Teilzielen. Dieser Zielkatalog ist in der Regel stichpunkartig aufgebaut, er ist ungeordnet und möglicherweise auch nicht sehr übersichtlich. Deshalb ist eine explizite Zielformulierung erforderlich. Die Teilziele müssen dabei geordnet und in eine dokumentierte Form gebracht werden. Die Teilziele stehen in vielfältigen Beziehungen zueinander und sie sind unterschiedlich konkret. Die Formulierung der Teilziele und des Gesamtziels führt daher auf eine hierarchische Anordnung – den so genannten Zielbaum. Im letzten Schritt wird das Zielsystem erstellt. Es baut auf dem Zielbaum auf und ergänzt ihn um überprüfbare Zielvariablen und um Aussagen über die unterschiedliche Bedeutung der Teilziele.

2.3.2 Zielvorstellungen erfassen Um die bestehenden Zielvorstellungen möglichst vollständig und zutreffend zu erfassen, ist es zunächst einmal notwendig heraus zu finden, wer Zielvorstellungen beitragen kann und darf. Zu diesen so genannten Stakeholdern gehören in einem Projekt in erster Linie die Auftraggeber. Sie stellen Anforderungen an das vorzulegende Projektergebnis und nennen oft auch Bedingungen für die Projektdurchführung, wie z. B. Meilensteine oder vorzulegende Informationen. Findet ein Projekt in einem Unternehmen statt, können weitere Ziele von internen Beteiligten kommen. Die Abteilungs- und Unternehmensleitung hat Vorstellungen über die wirtschaftlichen und organisatorischen Bedingungen. Sie wird Vorgaben für die einzusetzenden Ressourcen, für das benötigte Personal und auch für die einzuhaltenden Termine machen. Auch die Projektbeteiligten, die an der Lösung des Problems aktiv mitwirken, haben Vorstellungen über die zu erreichenden Ziele. Zum einen sind dies eigenständige Zielvorstellungen, die vor allem die Gestaltung der eigenen Arbeitsbedingungen und auch die Art des Zusammenarbeitens betreffen. Eine originäre Aufgabe der Beteiligten ist es sogar aus den Anforderungen der Auftraggeber, die z. B. in einem Lastenheft erfasst wurden, konkrete Ziele für die angestrebte Lösung abzuleiten. Diese werden in der Regel in einem Pflichtenheft festgehalten. Neben der unmittelbar Beteiligten ist auch das Umfeld eines problematischen Sachverhalts bei der Zielbildung zu berücksichtigen. Dies können räumlich oder funktionell benachbarte Personenkreise sein. Oft sind auch Anforderungen und Bedingungen der gesamten Gesellschaft zu beachten, die z. B. in Form von Gesetzen, Normen oder Vorschriften dokumentiert sind. Für eine möglichst vollständige Erfassung der Zielvorstellungen ist es hilfreich, auch hinsichtlich der Zielarten unterschiedliche Perspektiven einzunehmen. Für das Ergebnis einer Problemlösung gibt es Sachziele („Welche Objekte oder Gegenstände gehören zur Lösung?“), es gibt Funktionsziele („Welche Funktionen oder Leistungen gehören zur

50

2 Projekte als Problemlösungsprozesse

Lösung?“) und Kostenziele („Was darf die Lösung kosten?“). Zusammengefasst bilden diese Zielarten Qualitätsmerkmale für das angestrebte Ergebnis. Auch für den Ablauf der Problemlösung können Ziele bestehen. Hier sind einzuhaltende Termine, zu erreichende Zwischenergebnisse sowie Einschränkungen bei den verfügbaren Ressourcen, dem Personal und den Kosten für die Lösungsprozess zu nennen. Ein Vorhaben kann nur in seltenen, idealisierten Fällen losgelöst von der Umgebung betrachtet werden. Wesentlich häufiger hat die Umgebung starke Einwirkungen auf das Vorhaben. Man kann auch sagen: Das Vorhaben ist in seine Umgebung eingebettet. Ein Projekt zur Entwicklung eines neuen Produkts beispielsweise ist immer Bestandteil übergeordneter Ziele, wie z. B. Ablösung eines veralteten Produkts, Erweiterung des Produktportfolios, Erhöhung des Marktanteils oder Erschließung eines neuen Marktes. Diese Ziele selbst sind wiederum eingebettet in unternehmensstrategische Ziele, wie Erhöhung des Gewinns oder Sicherung der Arbeitsplätze. Auch wenn eine weitgehende Entkopplung von übergeordneten Zielen angestrebt wird und oft auch erreicht werden kann, bleiben Einflüsse bestehen. Gerade zur Auflösung von Zielkonflikten innerhalb des Problemlösungsprozesses kann die Lösung von der Detailbetrachtung und die Berücksichtigung der Zieleinbettung in übergeordnete Zwecke sehr hilfreich sein. Ein entgegengesetzter Ansatz ist die Formulierung eines Idealziels. Es wird unter Weglassen praktischer Beschränkungen, wie z. B. begrenzter Ressourcen formuliert: „Was würden wir machen, wenn wir ganz von vorne anfangen könnten, . . . wenn wir das ganze Team auf dieses Problem ansetzen könnten, . . . wenn wir ein zehnmal so großes Budget hätten?“ Auch wenn ein Idealziel sich nicht als konkretes Ziel für eine Problemlösung eignet, kann es zur Orientierung sehr gute Hilfe bei der Herleitung eines Realzieles leisten. Außerdem kann die Kenntnis eines Idealzieles Denkblockaden beim späteren Lösungsentwurf überwinden helfen, indem z. B. vermeintliche Beschränkungen hinterfragt werden. In der Regel führt die Betrachtung unterschiedlicher Perspektiven zu einer langen Liste von Zielen. Oft kann man sich vom Umfang dieses Zielkatalogs und der Fülle der Ziele erschlagen fühlen. Irgendwie hat man das Gefühl, dass die angestrebte Lösung alles können soll. Daher sollte man die Fragestellung auch einmal auf den Kopf stellen: Was ist nicht das Ziel? Durch die Beantwortung dieser invertierten Fragestellung gelingt die Abgrenzung der „Zielwolke“. Dies trägt sehr viel zur Konkretisierung der Vorstellung über das angestrebte Ergebnis bei. Allerdings ist die Abgrenzung nicht ganz einfach. Manche Vorstellung kann erst im Laufe der Problemlösung konkretisiert werden. Deshalb sollte hier „Kernprägnanz vor Randschärfe“ gehen. Zentrale Ziele sollen also so präzise wie möglich formuliert werden, einzelne Rand-Ziele dürfen dagegen auch unscharf bleiben. Eine letzte Anmerkung soll einem manchmal zu beobachtenden Irrtum gelten: Ziele sind keine Prognosen. Das bei einer Problemlösung als wahrscheinlich angesehene Ergebnis eignet sich nicht als Zielvorgabe. Je nach persönlicher Einstellung sind Prognosen entweder zu optimistisch oder zu pessimistisch. Beide Positionen sind wenig hilfreich. Sie beschreiben nicht, das was angestrebt wird, sondern stellen lediglich Vermutungen über den Verlauf der Arbeiten an.

2.3 Methoden und Werkzeuge zur Erstellung eines Zielsystems

51

2.3.3 Ziele formulieren Das Lösen von Problemen im Kontext von Projekten besteht aus einer ganzen Reihe von Aktivitäten und erfordert das Zusammenwirken mehrerer Beteiligter. Das Formulieren der Ziele dient daher mehreren Zwecken. Die Handlungssteuernde Funktion von Zielen ist in der psychologischen Forschung empirisch belegt. Ziele dienen der Motivation der Beteiligten. Ziele als gedanklich vorweggenommene Ergebnisse veranlassen Handlungen und regen die Aktivität an. Während der Ausführung der verschiedenen Handlungen sind immer wieder Entscheidungen zu treffen und die Handlungen aller Beteiligten einer Gruppe müssen auf das gemeinsame Ziel ausgerichtet werden. Ziele dienen daher die Aufgabe der Orientierung. Nicht zu Letzt dienen Ziele auch zur Kontrolle der erreichten Ergebnisse: sind alle Anforderungen erfüllt? wo gibt es Abweichungen? Damit sich Ziele zur Motivation, zur Orientierung und zur Kontrolle eignen, müssen sie in geeigneter Weise formuliert, dokumentiert und kommuniziert werden. In der Literatur findet man eine beinahe unübersehbare Fülle von Anforderungen, die bei der Zielformulierung zu beachten sind. Die beiden wichtigsten Anforderungen an eine gute Zielformulierung sind, sie spezifisch und messbar zu machen. Dies ist der Fall, wenn die Formulierung einen konkreten, überprüfbaren Sachverhalt beinhaltet. Hierbei gibt es natürlich beliebig viele Abstufungen zwischen „abstrakt“ und „konkret“. Eine robuste Bauform beispielsweise ist zunächst noch recht abstrakt. Konkreter wäre es, Wasserdichtigkeit, Unempfindlichkeit gegen Stöße, gegen elektromagnetische Felder und gegen erhöhte Temperaturen zu fordern. Noch besser wäre es, die Werte genau zu spezifizieren, indem man die erforderliche Dichtigkeit gegen Feuchtigkeit und Staub durch eine genormte Schutzart, also z. B. IP54 festlegt und den Umgebungs-Temperaturbereich für den normalen Betrieb zwischen 10 und +40 °C eingrenzt. Aus psychologischen Gründen sollten Ziele immer positiv und anregend formuliert werden. Bei der Festlegung von Zielen wird oft nach der Devise vorgegangen, „das Unmögliche zu fordern, um das Mögliche zu erreichen“. So kühn eine solche Forderung auch klingen mag, so wenig hilfreich ist sie in der Praxis. Das Unmögliche zu fordern, führt schnell zu einer Überforderung und der übertriebene Ansporn schlägt in Fatalismus um. Außerdem kann die Jagd nach einem unerreichbaren Ziel viel Zeit und Kosten verursachen, die nicht mehr in vernünftigem Verhältnis zur erreichbaren Wirkung stehen. Jedes Zielkriterium sollte daher realistisch sein, durchaus auch ehrgeizig, aber keinesfalls utopisch. Moderat anspruchsvolle Ziele haben sich am besten für die Motivation und die Erfolgsaussichten einer Problemlösung erwiesen. Bei der Entwicklung eines neuen PKW ist der Kraftstoffverbrauch sicher eine nahe liegende und gut messbare Zielvariable. Die Forderung nach einem Verbrauch unter 1 l pro 100 km ist sicherlich attraktiv, für sich alleine sogar erreichbar. In Kombination mit anderen Forderungen, wie z. B. 4 Sitzplätze, 250 kg Zuladung, Höchstgeschwindigkeit 200 km/h und Anschaffungskosten von 10.000 C wohl unrealistisch.

52

2 Projekte als Problemlösungsprozesse

Ein letztes wesentliches Merkmal guter Zielformulierung ist die Terminierung. Es genügt nicht, ein Ziel irgendwann zu erreichen, sondern gerade bei der Durchführung von Projekten ist die Zusage und Einhaltung von Zeitplänen ein ganz entscheidendes Qualitätskriterium. Jedes Zielkriterium muss daher mit einem Zeitbezug ausgestattet sein. Im Zweifelsfall ist der Endtermin eines Projekts gleichzeitig der angestrebte Termin für die Ziele. Allerdings gibt es oft auch Zwischenziele, die schon vorher erreicht werden müssen. Die bisher genannten fünf Anforderungen wurden sehr einprägsam im SMART-Schema zusammengefasst: Ziele sollen spezifisch, messbar, anregend, realistisch und terminiert formuliert werden. Neben vielen positiven Wirkungen, die das SMART-Schema auf die Formulierung von Zielen hat, gibt es auch einige Kritikpunkte. Gerade bei komplexen hierarchisch gegliederten Zielsetzungen weist das SMART-Schema einige Nachteile auf. Die strikte Forderung, alle Teilziele SMART zu formulieren wird nicht zu Unrecht als Formalismus angesehen, der oft nur wenig nutzt. Die Einbettung von Zielen in übergeordnete Zwecke kommt genau so wenig zum Ausdruck, wie die hierarchische Strukturierung. Auch die Notwendigkeit der Kommunikation der Ziele an alle Beteiligten fehlt im SMART-Schema. Deshalb soll es hier durch zwei wichtige Anforderungen erweitert werden. Gerade bei komplexen, Zielen, wie sie in Projekten der Regelfall sind, ist eine hierarchische Strukturierung notwendig. Das globale Projektziel setzt sich über mehrere Ebenen hinweg aus mehreren Zielklassen, Teilzielen und Einzelzielen zusammen. Das Ergebnis ist der Zielbaum. Übergeordnete Ziele sind durch einen gewissen Grad an Abstraktion gekennzeichnet. Der Zielbaum wird von Ebene zu Ebene konkreter. Abstrakte Ziele auf höheren Ebenen werden erst durch deren Aufbrechen in konkretere Teilziele messbar und überprüfbar. Jedes Oberziel stellt den Zweck für seine Unterziele dar. Jedes Unterziel ist in ein Oberziel eingebettet und dient als Mittel für dessen Erreichung. In der gleichen Weise ist das Globalziel in einen übergeordneten Zweck eingeordnet. Die Kenntnis der Struktur verbessert das Verständnis für die daraus sich ergebenden Teilziele und kann bei der Behebung von Zielkonflikten helfen. Des Weiteren ist die hierarchische Zielstruktur als Grundlage für die spätere Untergliederung des Projekts geeignet. Komplexe Probleme erfordern das Zusammenwirken mehrerer Personen und Fachdisziplinen. Ziele müssen daher kommunizierbar sein. Um die Orientierung aller Beteiligten an den Zielen sicherzustellen, müssen die Ziele allen mitgeteilt werden. Diese müssen sie verstehen, sie können sie möglicherweise hinterfragen, um sich dann mit diesen Zielen zu identifizieren. Unter dem Aspekt der Zielstrukturierung haben dabei die Anforderungen des SMARTSchemas eine modifizierte Bedeutung. Spezifisch und messbar sind recht stark gekoppelt und werden daher zusammengefasst. Die Frage der Terminierung muss im Zielbaum praxisgerecht gestaltet werden. Ein Globalziel sollte auf jeden Fall immer terminiert sein. Dieser Termin gilt für den gesamten Problemlösungsprozess. Alle Unterziele müssen auch innerhalb dieses Terminziels erreicht werden. Falls keine weiteren Angaben gemacht werden, gilt das globale Terminziel auch für die Teilziele. Es sind aber zusätzliche Ein-

2.3 Methoden und Werkzeuge zur Erstellung eines Zielsystems

53

Tab. 2.3 Anforderungen für STARKE Ziele Kriterium Spezifisch Terminiert Anregend Realistisch Kommunizierbar Eingebettet

Merkmal Messbar, überprüfbar, konkret. Abstrakte Ziele durch Unterziele konkretisiert Termin-Hierarchie mit langfristigen Ober- und kurzfristigeren Unterzielen. Handlungsanregend, aber lösungsneutral. Handlungsspielraum offen halten. Anspruchsvoll, aber erreichbar. Weder utopisch, noch zu einfach Klar, verständlich, dokumentiert und kommuniziert Jedes (Teil-)Ziel bildet ein Mittel für einem übergeordneten Zweck

schränkungen in Gestalt von kürzeren Fristen möglich. Dadurch müssen für Teilbereiche des Zielbaums Zwischentermine gebildet werden. Auch bei der Frage anregender Ziele verschiebt sich die Bedeutung. Sie wird ergänzt durch die Forderung der Lösungsneutralität. Ziele sollen nicht unnötig den Handlungsspielraum der Problemlöser einschränken. Oft besitzen diese ausgeprägtere Fachkompetenzen als die Anforderungssteller. Eine zu enge Zielformulierung kann daher möglicherweise gute, kreative Lösungen verhindern. Die Weiterentwicklung des SMART-Schemas und dessen Übertragung auf hierarchisch gegliederte Zielbäume führt zum Anforderungsprofil für STARKE Ziele: sie sollen spezifisch (und messbar), terminiert, anregend, realistisch, kommunizierbar und eingebettet formuliert werden (Tab. 2.3).

2.3.4 Zielsystem erstellen Die Gesamtheit der Ziele für ein komplexes Vorhaben kann als baumartige Struktur angesehen werden, wobei für die Formulierung sowohl der Teilziele als auch für das Gesamtziel Anforderungen zu erfüllen sind, damit das Ziel seine Aufgabe der Motivation, der Orientierung und der Kontrolle genügt. Der Sinn der Zielformulierung ist es, allen an der Lösung Beteiligten klar zu machen, wohin der Weg des Projekts führen soll. Dies impliziert auch, dass am Ende des Weges, d. h. vor dem Abschluss des Projekts überprüft werden sollte, ob das Ziel erreicht oder in welchem Maße es erreicht wurde. Aber bei weitem nicht jede Zielformulierung eignet sich hierfür. Im Gegenteil. Viele Zielformulierungen klingen zwar eindeutig und klar, lassen aber trotzdem so viel Interpretationsspielraum, dass Meinungsverschiedenheiten über die Zielerreichung fast schon vorprogrammiert sind. Sind Zielformulierungen aber am Ende interpretierbar, so sind sie es auch während des Projektes. Sie bilden daher keine geeignete Basis für notwendige Entscheidungen. Damit Ziele nicht nur gut klingen, sondern sich für die Auswahl konkreter Handlungen im Laufe des Projekts und zur Bewertung der Zielerreichung eignen, müssen sie vor allem spezifisch sein. Die Bedeutung dieser Forderung für die Kontrolle ist offensichtlich, aber auch für die Orientierung und Motivation sind spezifische Ziele sehr hilfreich. In diesem Zusammenhang wird oft auch von

54

2 Projekte als Problemlösungsprozesse

operationalisierbaren Zielen gesprochen, da sich konkreten Zielen am besten Handlungen (Operatoren) ableiten lassen. Im Idealfall wird für jede Zieldimension eine Zielvariable festgelegt, die einen bestimmten Wertebereich annehmen kann. In manchen Fällen ergeben sich die Zielvariablen unmittelbar aus der Zieldimension. Soll ein zu entwickelndes Gerät z. B. möglichst leicht sein, ist das Gewicht die offensichtliche Zielvariable. Kostenanforderungen können durch Anschaffungs-, Herstellungs- oder Wartungskosten abgebildet werden. In anderen Fällen sind die Zielvariablen nicht offensichtlich. Die hohe Robustheit eines Gehäuses, die gute Handhabbarkeit eines Gerätes oder die Ergonomie einer Software-Schnittstelle sind nicht direkt messbar. Hier müssen Zielvariablen erst bestimmt werden. Eine Zielvariable ist durch den Wertebereich bestimmt, den sie annehmen kann. Bei physikalischen Variablen, wie z. B. dem Gewicht oder den Abmessungen von Objekten oder bei technischen Daten von Geräten ist dies sehr einfach. Auch bei den wirtschaftlichen Variablen, insbesondere bei den Kosten sind die Wertebereiche offensichtlich. Bei vielen anderen Größen sind Noten-, Punkte- oder Prozentskalen hilfreich. Auch die Klassenbildung (z. B. niedrig, mittel, hoch) oder binäre Wertebereiche (z. B. ja/nein oder vorhanden/nicht vorhanden) kann als Zielmaß verwendet werden. Auch wenn das Benennen von Zielvariablen nicht immer leicht ist, sollte ein Teilziel nicht deswegen hohe Bedeutung erhalten, weil es gut messbar ist und ein anderes unter den Tisch fallen, weil seine Überprüfung schwierig ist (Tab. 2.4). Typische Zielbäume bestehen aus vielen Teil- und Einzelzielen. Neben den Hierarchiebeziehungen zwischen Ober- und Unterzielen, können viele weitere Zielbeziehungen bestehen (Tab. 2.5). Teilziele können unabhängig voneinander sein, sich gegenseitig ergänzen oder miteinander konkurrieren. Im Hinblick auf die Effizienz sind sich ergänzende Ziele ideal. Mehrere Teilziele können in diesem Fall durch die gleiche Maßnahme erreicht werden. Dies gilt vor allem, wenn das gleiche Teilziel bei verschiedenen Oberzielen auftaucht. Hinsichtlich der Handhabung sind auch voneinander unabhängige Teilziele unproblematisch. Eine Maßnahme die zur Erreichung des einen Teilziels beiträgt hat keine (negativen) Auswirkungen auf andere Ziele.

Tab. 2.4 Zielvariablen und Randbedingungen zur Anschaffung eines CAD-Systems Teilziel Kosten Kosten Funktionsumfang Handhabung Verfügbarkeit Linux-Eignung Datei-Import PPS-Schnittstelle

Zielvariable Anschaffungskosten Wartungskosten Funktionsumfang Handhabungsnote Verbreitungsgrad Linux-kompatibel Datei-Import möglich Schnittstelle vorhanden

Wertebereich Tsd. C Tsd. C 0 %..100 % 1,0..5,0 niedrig/mittel/hoch ja/nein ja/nein ja/nein

Randbed. < 30 Tsd. C < 3 Tsd. C > 80 % Mind. 3,0 – – Ja –

Gütekrit. mögl. niedrig mögl. niedrig mögl. hoch mögl. gut mögl. hoch Ja – Ja

2.3 Methoden und Werkzeuge zur Erstellung eines Zielsystems

55

Tab. 2.5 Zielbeziehungen Beziehung Teil-/Einzelziele können . . . . . . identisch sein . . . sich ergänzen . . . unabhängig sein . . . miteinander konkurrieren . . . sich ausschließen

Merkmale gleiches Unterziel bei verschiedenen Oberzielen eine Maßnahme dient mehreren Zielen für jedes Ziel sind eigene Maßnahmen wirksam Maßnahmen verbessern an einer und verschlechtern an anderer Stelle die Ziele sind unvereinbar, eines muss entfernt werden

Dies ist bei konkurrierenden Zielen nicht der Fall. Hier zieht die Verbesserung bei einem Ziel, eine Verschlechterung bei einem anderen nach sich. In der Praxis treten derartige Zielkonflikte sehr oft auf. Wird also der Wert einer Zielvariablen verbessert, verschlechtert sich der Wert einer anderen, negativ korrelierten. Jede zusätzliche funktionelle Anforderung verschlechtert die Kostensituation. Auch Terminforderungen stehen meist in Konflikt mit Kosten- und Qualitätsforderungen, so dass hier oft vom Zieldreieck gesprochen wird, bei dem eine Verbesserung an einer Stelle zur Verschlechterung bei den anderen führt. In diesem Fall liegt natürlich ein strukturelles Problem vor: Die beiden gegenläufigen Zielvariablen können nicht gleichzeitig optimiert werden. Es kann höchstens ein Kompromiss zwischen beiden gesucht werden. Gegenläufige Zielvariablen können bei der Entscheidungsfindung durch Kompromisse bei der Gewichtung berücksichtigt werden. Allerdings kann die Gegenläufigkeit im Extremfall so weit gehen, dass sich zwei Zielvariablen gegenseitig ausschließen. Nur eine der beiden Zielvariablen kann berücksichtigt werden. Dieses Problem muss im Rahmen der Entscheidungsfindung behandelt werden. Von den Zielkonflikten müssen die Interessenkonflikte deutlich unterschieden werden. Erstere stellen fast immer ein sachliches Problem dar, welches logisch gelöst werden kann. Interessenkonflikte sind soziale Probleme, die weit schwierigere psychologische Methoden erfordern. Konkurrierende Teilziele erfordern immer ein Abwägen: Kann auf ein Teilziel verzichtet werden oder muss ein Kompromiss gefunden werden durch Festlegung einer Priorität bzw. einer Gewichtung? Es gibt verschiedene Möglichkeiten, um die Bedeutung eines Teilziels im Kontext eines Globalziels und damit auch in Relation zu anderen Teilzielen auszudrücken. Bei der Frage nach Prioritäten wird oft so getan, als wären alle Teilziele gleich wichtig und unverzichtbar: „Alle Ziele haben höchste Priorität“. Fast immer ist eine solche Aussage ein Zeichen dafür, dass man praktische Einschränkungen nicht akzeptieren will und sich nicht entscheiden kann. Entscheidungen sind aber immer nötig! Werden sie nicht aktiv getroffen, so überlässt man sie anderen oder dem Zufall. In der Regel haben die Teilziele immer eine unterschiedliche Bedeutung für die spätere Auswahlentscheidung zwischen mehreren Lösungsalternativen. Manche Ziele müssen tat-

56

2 Projekte als Problemlösungsprozesse

sächlich unbedingt erfüllt sein, damit eine Lösungsalternative überhaupt in Frage kommt. Sie werden oft als Muss-Ziele, als Randbedingungen oder Satisfizierungsziele bezeichnet und sind für die Erreichung des Globalziels notwendig. Selbst wenn es andere, konkurrierende Teilziele gibt, kann auf die Einhaltung der Muss-Ziele nicht verzichtet werden. Randbedingungen sind praktisch immer binärer Art: sie sind erfüllt oder nicht erfüllt. I

Randbedingungen sind Bedingungen, die bei der Lösung eines Problems eingehalten werden müssen. Nicht eingehaltene Randbedingungen stellen ein Scheitern der Problemlösung dar.

Bei der Konstruktion eines neuen Autos beispielsweise können eine maximale Breite und eine maximale Höhe unbedingt einzuhaltende Randbedingungen sein, die durch rechtliche Vorschriften oder genormte Abmessungen von Verkehrswegen, Durchfahrten, Garagen oder Autozügen fest vorgegeben sind. Soll-Ziele sind dagegen weicher. Ihre Einhaltung verbessert die Güte der Zielerreichung, weshalb sie auch als Gütekriterien oder als Optimierungsziele bezeichnet werden. Ihre Nichteinhaltung führt aber nicht zwangsläufig zu einem vollständigen Verfehlen des Ziels. Bei ihnen gilt „je mehr, desto besser“ und sie sind daher meist Bestandteil eines Gütekriteriums. I

Gütekriterien sollen bei einer Problemlösung maximiert bzw. eingehalten werden. Sie legen die Qualität einer Lösung fest.

Gütekriterien können sowohl analoger als auch binärer Art sein. Analoge Gütekriterien besitzen Werte auf einer kontinuierlichen Skala, wie z. B. Noten, Punkte, Prozentwerte oder Kosten. Binäre Kriterien sind entweder erfüllt oder nicht erfüllt. Beim Auto könnten z. B. das Vorhandensein einer Klimaanlage, eines Seiten-Airbags oder eines Schiebedachs binäre Gütekriterien sein. Analoge Kriterien wären z. B. ein möglichst großer Kofferraum, gutes Design, geringer Verbrauch, angenehme Haptik der Bedienelemente oder möglichst niedriges Gewicht. Während binäre Kriterien meist einfach festzustellen sind, ist die Messung analoger Zielvariablen manchmal mit etwas Mühe verbunden, liefert dafür aber zusätzliche Einsicht in die angestrebte Lösung. Randbedingungen sind von größerer Wirkung. Sie grenzen den zulässigen Wertebereich der Variablen ein. Sie sollten daher entsprechend vorsichtig festgelegt werden. Zu viele und zu harte Randbedingungen können den Lösungsraum so stark einschränken, dass keine Lösung mehr übrig bleibt. Daher ist es sinnvoll zu prüfen, ob aus einer Randbedingung nicht ein Gütekriterium mit hoher Gewichtung gemacht werden kann. In dem durch die Randbedingungen frei gelassenen Bereich des Lösungsraums wird dann mit Hilfe des Gütekriteriums nach der besten zugelassenen Lösung gesucht. Hierzu ist eine Gewichtung der Teilziele erforderlich, die ins Gütekriterium einfließen. Eng verwandt mit den Soll- und Muss-Zielen ist das MuSCoW-Modell zur Zielpriorisierung. Neben den Muss-Zielen („Must have“) und den Soll-Zielen („Should have“) gibt

2.4 Lösungssynthese

57

es noch Kann-Ziele („Could have“) und Nicht-Ziele („Won’t have“). Nicht-Ziele können zur Abgrenzung der Zielsetzung hilfreich sein. Außerdem beugen sie Missverständnissen vor, da sie explizit benennen, was (diesmal) nicht erreicht werden soll.

2.4 Lösungssynthese 2.4.1

Bedingungen der Ideenfindung

Eine der schwierigsten Teilaufgaben beim Problemlösen ist das Finden von Ideen. Ein Problem unterscheidet sich von einer Aufgabe vor allem durch seine Neuartigkeit. Neue Probleme erfordern auch neue Lösungen, so dass bei jeder Problemlösung neue Wege gegangen und neue Ideen gefunden werden müssen. Dieser Vorgang verlangt viel Kreativität und kann daher nicht schematisch wie ein Algorithmus ablaufen. Kreative Prozesse sind sehr stark von den psychischen Voraussetzungen des Menschen geprägt. Auch wenn kreative Prozesse in den letzten Jahrzehnten Gegenstand intensiven Forschungsinteresses waren, sind sie bislang nur in Teilen nachvollziehbar. Trotzdem hat die Forschung nützliche Erkenntnisse geliefert, die die Grundlagen für viele Methoden zum gezielten Produzieren von neuen Ideen bilden. Eine unbestrittene Voraussetzung für Kreativität ist Wissen. Eine breite, vielfältige Wissensbasis ist für die Kreativität sehr förderlich, während spezialisiertes Wissen keine so starke kreative Wirkung entfaltet und extremes Spezialwissen sogar hinderlich sein kann. Je mehr man weiß und je mehr man aus verschiedenen Fachgebieten weiß, desto eher ist man in der Lage, Wissensbausteine miteinander zu kombinieren und daraus neue Ideen zu erzeugen. Angesichts des heute erreichten, enormen Wissensumfangs ist es für Einzelpersonen kaum noch möglich, die erforderliche Wissensbreite für umfangreiche Probleme bereit zu stellen. Daher ist es sinnvoll in Gruppen von Fachleuten aus unterschiedlichen Bereichen nach neuen Ideen zu suchen. Ein weiterer fördernder Effekt der Gruppenarbeit zur Ideenproduzierung sind die Anregungen, die jeder Einzelne in einer Gruppe erfährt. Durch die Weitergabe von Ideen oder auch nur Ideenbruchstücken wird bei anderen die Phantasie angeregt und neue Ideen frei gesetzt. Mit der Zahl der Beteiligten steigt dieser Effekt natürlich an. Allerdings treten mit steigender Gruppengröße auch negative Faktoren auf, so dass es aus praktischer Sicht eine Grenze der Gruppengröße gibt, die bei ca. 10–20 Teilnehmern liegt. Gruppenmitglieder, die durch ihre Dominanz andere blockieren können, müssen durch geeignete Kommunikationsregeln und eine geschickte Moderation gebremst werden. Insbesondere dürfen Ideen – egal wie unrealistisch sie erscheinen oder wie verrückt sie klingen mögen – auf keinen Fall zu früh kritisiert werden. Das Verbot voreiliger Kritik ist daher eine wesentliche Bedingung der Gruppenarbeit (Tab. 2.6). Ideen können nicht erzwungen werden. Fleißarbeit kann unter Zeit- und Erfolgsdruck stattfinden – ob sie dabei gut gemacht wird, ist eine andere Frage. Kreativarbeit dagegen ist unter Druck gar nicht möglich. Der Versuch, neue Ideen zu erzwingen, führt oft zu Blo-

58

2 Projekte als Problemlösungsprozesse

Tab. 2.6 Kreativitätshemmende und -fördernde Faktoren Hemmende Faktoren Druck: Zeitdruck, Erfolgsdruck Voreilige Kritik Funktionale Fixierung Einstellungseffekte

Fördernde Faktoren Breite, vielfältige Wissensbasis Angenehme Atmosphäre Gruppendynamik Analogiebildung

ckaden, so dass entweder gar nichts herauskommt oder nur Kreativschrott produziert wird. Eine wichtige Voraussetzung für kreative Arbeit ist also eine lockere, anregende Atmosphäre. Diese kann z. B. durch die Wahl einer anderen, als der gewohnten Büroumgebung geschaffen werden, durch die Wahl eines Termins, der aus der üblichen Arbeitszeit herausragt oder durch das Hinzuziehen von Personen, die mit dem Problem bisher gar nichts zu tun hatten. Die typischen Merkmale einer Unternehmensorganisation, wie Arbeitsteilung, Spezialisierung, Hierarchiebildung und feste Ablaufstrukturen, die für den Erfolg eines Unternehmens notwendig sind, hemmen im Allgemeinen die Kreativität. Auch einige psychische Bedingungen, unter denen Einzelne im Unternehmen ihre Arbeit verrichten, wie Rivalität, Risikovermeidung, Routinebildung, Perfektionsstreben und Kritikfurcht, stehen kreativer Arbeit entgegen. Es ist daher klar, dass die Bedingungen für kreative Arbeit deutlich von der „normalen“ Arbeit unterschieden werden müssen. Sowohl beim Einzelnen als auch in der Gruppe kann es Blockaden geben, die kreative Lösungen verhindern. Bei der funktionalen Fixierung werden die beim Problemgegenstand vorhandenen und für die Lösung verfügbaren Objekte nur aus dem Blickwinkel ihrer „normalen“ Funktion betrachtet. Während viele Zweckentfremdungen nur als Notlösungen taugen, wie z. B. der Damenstrumpf als Ersatz für einen defekten Keilriemen, können sich manchmal gelungene Innovationen ergeben, wenn man ein Objekt für eine ungewohnte Funktion verwendet. Eine andere Art der Blockade ist der so genannte Einstellungseffekt. Hierbei verhindert der an sich sinnvolle Vorgang, dass eine in mehreren Problemen erfolgreiche Lösungsstrategie auch auf ein neues, ähnlich aussehendes Problem angewendet wird, manchmal den Blick auf andere Lösungsstrategien. Das schon oft gehörte „Das haben wir immer schon so gemacht“ zur Rechtfertigung gewohnter Handlungsmuster in Kombination mit dem „Das haben wir noch nie so gemacht“ als Kritik für eine neue Idee ist die beste Waffe, um jegliche Kreativität abzutöten. Auch wenn es Erfindern schwer fällt zu erklären, wie sie auf ihre geniale Idee gekommen sind, stellt man im Ablauf fast immer eine bestimmte Grundstruktur fest. Diese beginnt mit einer intensiven Auseinandersetzung mit dem Problem. Dies kann auf sehr unterschiedliche Art erfolgen, z. B. durch das gezielte Hinterfragen, wie bei der 6-W-Methode, durch das Herumexperimentieren mit dem Sachverhalt, das durchaus auch planlos sein kann oder durch das spielerische Ausprobieren möglicher Lösungen.

2.4 Lösungssynthese

59

Typisch für diese Phase ist die Erfolglosigkeit! Auch wenn fast immer die Hoffnung besteht, das Problem schnell zu lösen, gelingt dies bei Problemen nennenswerter Komplexität praktisch nie. Mental ist diese Situation schwierig: Es wird viel Zeit und viel Arbeit in das Problem investiert und man hat das Gefühl, keinen Millimeter weiter zu kommen. Scheinbare Fortschritte werden durch anschließende Rückschläge wieder zunichte gemacht. Trotzdem ist diese Phase eine notwendige Voraussetzung für die spätere Lösung. Daher ist es wichtig, sich nicht entmutigen zu lassen und sich in Momenten der Verzweiflung die Notwendigkeit der gründlichen Auseinandersetzung mit dem Problem bewusst zu machen. Nicht umsonst hat ein wirklich erfolgreicher Erfinder wie Edison gesagt, dass Genie zu 99 % Transpiration und zu 1 % Inspiration ist. Damit die Auseinandersetzung mit dem Problem zum Erfolg führt, genügt aber Ausdauer alleine nicht. Erfolgreiche Ideenproduzierung durchläuft fast immer eine Phase, in der das Problem wieder beiseite gelegt wird. Egal ob dies aus äußerer Notwendigkeit, aus Frustration oder aus Einsicht passiert – die Ablenkung vom Problem ist sehr hilfreich, um wieder etwas Abstand zu gewinnen und dann zur Lösung zu kommen. Anscheinend brütet der Geist unbewusst weiter am Problem, weshalb diese Phase auch als Inkubation bezeichnet wird. Typisch für dieses Ausbrüten ist, dass der Vorgang eine ungewisse Zeit dauert und dass die ausgebrütete Idee meist zu einem unerwarteten Zeitpunkt schlüpft, sei es morgens unter der Dusche, im Auto vor der roten Ampel oder abends beim Waldlauf.

2.4.2

Methoden der Ideenfindung

Die skizzierten psychischen Voraussetzungen des Menschen sowie die Erkenntnisse über hemmende und fördernde Faktoren haben in vielfältiger Form in Kreativitätsmethoden Eingang gefunden. Allen Methoden ist gemeinsam, dass es zunächst darum geht, möglichst viele Ideen zu produzieren. Wohl die bekannteste Methode zur Ideenproduktion ist das von Alex Osborn entwickelte Brainstorming („using the brain to storm a problem“, [Osborn 1957]). Sie hat das Ziel, in einer Gruppe von Experten in kurzer Zeit möglichst viele Ideen zu produzieren. Die Fokussierung auf möglichst viele Ideen, deckt sich mit der Feststellung von Linus Pauling: „The best way to get a good idea, is to get a lot of ideas“. Beim Brainstorming setzen sich mehrere Experten und ein Moderator in entspannter Atmosphäre zusammen. Jeder Beteiligte kennt das Problem und darf Lösungsideen in kurzer, stichwortartiger Form äußern. Die Ideen werden protokolliert. Sie dürfen von den anderen aufgegriffen, weiter entwickelt oder kombiniert, aber nicht bewertet oder kritisiert werden. Durch die Formulierung der Ideen und deren sofortiger Weitergabe, wird eine intensive Anregung der Phantasie bei den Beteiligten erreicht. Es besteht aber die Gefahr, dass Wortführer in der Gruppe die Suche zu früh in eine bestimmte Richtung lenken. Zurückhaltendere Gruppenmitglieder können in ihren Äußerungen dadurch blockiert werden. Dieses Problem sollte durch eine gute Moderation unterbunden werden. Beim Brainwriting wird dieses Problem dadurch entschärft, dass zunächst jeder Teilnehmer seine Ideen

60

2 Projekte als Problemlösungsprozesse

schriftlich festhält. Sie werden anschließend veröffentlicht und dann wie beim Brainstorming weiter entwickelt. Eine ähnliche Mischung aus schriftlicher und mündlicher Ideenproduktion, mit einer Neigung die Bedeutung technischer Hilfsmittel zu überbewerten, stellt die Kartenabfrage (Meta-Plan-Methode) dar. Jeder Teilnehmer notiert seine Ideen auf Karten. Die anonymen Karten werden eingesammelt und an einer Tafel veröffentlicht. Dabei können mehrfach genannte Ideen oder ähnliche Ideen zu Gruppen zusammengefasst werden. Anschließend werden die veröffentlichten Ideen diskutiert und durch Vergabe von Punkten durch die Teilnehmer bewertet. Das Ergebnis ist eine gruppierte und bewertete Sammlung von Ideen. Noch stärker formalisiert und vollständig auf die schriftliche Form reduziert verläuft die Ideenproduktion bei der 635-Methode. 6 Teilnehmer setzen sich zusammen, jeder notiert 3 Ideen auf seinem Blatt. Nach 5 min wird das Blatt zum Nachbarn weiter gegeben. Diese entwickeln nun die vorgefundenen, fremden Ideen weiter, indem sie diese z. B. konkretisieren, verallgemeinern oder mit eigenen Ideen kombinieren. Diese Schritte werden wiederholt, bis jeder Teilnehmer jedes Blatt bearbeitet hat. Am Ende gibt es also 18 Ideen, die von allen Beteiligten aufgegriffen und weiter gedacht wurden. Durch die schriftliche Form sind alle Beiträge zwangsläufig dokumentiert. Introvertierte Gruppenmitglieder kommen genau so zur Geltung wie dominante, dafür gehen aber gruppendynamische Effekte und Spontaneität verloren. Die beschriebenen Methoden enthalten zwar Festlegungen für den Ablauf und die formale Handhabung, aber keinerlei inhaltliche Vorgaben. Dadurch kann ein Problem ganzheitlich angegangen werden. Dies gelingt auch, wenn die Gruppe in möglichst viele Richtungen denkt, birgt aber die Gefahr der frühzeitigen Fixierung auf eine einzige Suchrichtung. Dies wird vermieden, durch das bewusste Durchlaufen verschiedener Rollen. Dadurch können neue Perspektiven auf ein Problem eröffnet werden. Bei der Disney-Methode gibt es drei Rollen (Realist, Träumer, Kritiker), die durch drei Stühle symbolisiert werden. Der Realist versucht beim Entwurf von Lösungsideen Vor- und Nachteile sowie Chancen und Risiken möglichst genau abzuwägen. Als Träumer ist es dagegen erlaubt, Lösungen optimistisch zu sehen. Dabei kann man z. B. praktische Einschränkungen abschwächen oder vernachlässigen. Die Gegenposition nimmt der Kritiker ein. In seiner pessimistischen Sicht fokussiert er sich auf Nachteile und Risiken der Lösungen. Wohl gemerkt: Mit der Disney-Methode ist nicht gemeint, dass einer in der Gruppe den Träumer und ein anderer den Kritiker gibt – in jeder größeren Gruppe gibt es sie in gesteigerter Form des Phantasten und des Nörglers sowieso schon – sondern jeder in der Gruppe soll die drei Rollen durchlaufen, um die entsprechenden Perspektiven aktiv einzunehmen. Ähnlich funktioniert die Denkhüte-Methode nach De Bono. Hier gibt es 6 Rollen, die durch die Farben von Hüten symbolisiert werden. Die entsprechenden Problemperspektiven werden als analytisch (weiß), emotional (rot), kritisch (schwarz), optimistisch (gelb), kreativ (grün) und ordnend (blau) charakterisiert. Ohne weiteres kann dabei die Rolle des

2.4 Lösungssynthese

61

analytisch denkenden Realisten, des optimistischen Träumers und des Kritikers aus der Disney-Methode wiedererkannt werden. Einen anderen Ansatz zur Eröffnung neuer Perspektiven wählt die PMI-Methode. Diese sucht bei jedem wichtigen Sachverhalt die positiven (Plus), die negativen (Minus) und die interessanten (Interesse) Aspekte. Dadurch wird eine einseitige Fokussierung auf die Vorteile bzw. die Nachteile eines Sachverhalts vermieden. Gerade wenn man zu einer Sache bereits einen bestimmten, z. B. positiven Standpunkt hat, sollte man auch die Gegenseite, also im Beispiel die Nachteile berücksichtigen. Außerdem werden auch zunächst nicht nutzbare, aber interessante Aspekte gesucht, die wiederum Assoziationen auslösen können. Noch einen Schritt weiter geht die Imagine-Methode („Stell dir vor . . . “). Sie fordert bewusst das Weglassen real existierender Beschränkungen, um vielleicht nicht realisierbare Lösungsideen zu produzieren. Diese können dann entweder die Vorstellungskraft für andere, doch realisierbare Ideen anregen oder aber sie geben den Anlass, die Notwendigkeit der Beschränkungen zu überprüfen. Alle bisher beschriebenen Methoden sind entweder vollständig oder doch in großen Teilen intuitiv, d. h. sie enthalten keine inhaltlichen Vorgaben. Dadurch sind diese Methoden sehr allgemeingültig und können für jede Art von Lösungssuche verwendet werden. Daneben gibt es analytische Ideenproduktionsverfahren, die das Durchsuchen des Lösungsraums nicht alleine der Intuition überlassen, sondern ihn möglichst vollständig aufspannen und systematisch durchsuchen. Durch die getrennte Betrachtung der verschiedenen Dimensionen des Lösungsraums wird die ganzheitliche Sicht zwar etwas in den Hintergrund gerückt, dafür eröffnen sich neue Ideen zu Teilaspekten, die den Anstoß für innovative Gesamtlösungen bilden können. Die morphologische Methode geht auf F. Zwicky zurück [Zwicky 1966]. Morphologie ist die Lehre von den Gestalten einer Sache oder eines Sachverhalts. Ein Sachverhalt wird dabei systematisch in seine wichtigen Merkmale zerlegt. Sie bilden die Dimensionen des Lösungsraums. Jedes Merkmal kann verschiedene Ausprägungen bzw. Werte annehmen. Eine beliebige Kombination, die aus je einem Wert für jedes Merkmal besteht, stellt dann eine mögliche Lösung dar. Durch dieses systematische Aufspannen des Lösungsraums, werden alle denkbaren Lösungen erfasst. Betrachtet man nur zwei Merkmale, ist der Lösungsraum zweidimensional – es entsteht eine sogenannte morphologische Matrix. Bei drei Merkmalen wird die Matrix dreidimensional. Zwicky hat sie als „Kasten“ bezeichnet und die daraus resultierende Bezeichnung morphologischer Kasten hat sich aufgrund seiner Anschaulichkeit durchgesetzt und wird heute für beliebige Dimensionen verwendet. Beispiel 2.1 Morphologische Methode zur Suche nach neuen Sensoren

Bei der elektrischen Messung physikalischer Größen werden verschiedene Effekte genutzt. Bei passiven elektrischen Aufnehmern, sind dies die Wirkungen, die verschiedene Größen auf die elektrischen Basisgrößen Widerstand, Kapazität und Induktivität

62

2 Projekte als Problemlösungsprozesse

Tab. 2.7 Morphologischer Kasten für passive elektrische Aufnehmer Merkmal

Merkmalsausprägungen

Messgröße

Winkel

Hilfsgröße

Bewegung

Kraft

Moment

Druck

Beschleunig.

Feuchte

Elektrische Größe

Widerstand

Umgeb.-medium

Luft

Umgeb.-Temp.

< 50 °C

< 90 °C

< 120 °C

Genauigkeit

Besser als 0,1 %

Besser als 0,5 %

Besser als 1 %

Temperatur Kapazität Öl

Wasser

Induktivität Granulat

Pulver

haben. Beispiele hierfür sind die Abhängigkeit des Widerstands von der Länge, dem Querschnitt, der Materialeigenschaft oder der Temperatur eines Bauteils (Tab. 2.7). Ein Hersteller elektrischer Sensoren möchte nun sein Produktportfolio um neue Sensoren erweitern. In einer Sitzung werden die wichtigen Merkmale von Aufnehmern und deren Ausprägungen gesammelt und als morphologischer Kasten dargestellt. Jede Kombination mit je einem Wert für jedes Merkmal stellt einen möglichen Sensor dar. Dadurch gibt es in diesem Beispiel insgesamt 6  2  3  5  3  3 = 1620 mögliche Kombinationen. Eine dieser Kombinationen ist exemplarisch hervorgehoben. Es handelt sich um einen Sensor, der zur Druckmessung geeignet ist. Der Druck muss durch eine mechanische Konstruktion in eine Wegänderung umgesetzt werden, die dann kapazitiv erfasst wird. Der Sensor soll in Öl bei Temperaturen bis 90 °C einsetzbar sein und eine Genauigkeit von mindestens 1 % besitzen. J Die morphologische Methode eröffnet systematisch den gesamten Lösungsraum. Damit aber die Vielzahl der Kombinationen nicht zum Problem wird, sind mehrere Voraussetzungen zu beachten. Zum einen ist eine Konzentration auf die wirklich wichtigen Merkmale nötig. Zum anderen muss auch der Zahl der möglichen Ausprägungen für jedes Merkmal begrenzt bleiben. Recht gut gelingt dies, wenn man ähnliche Werte zu einer Gruppe zusammenfasst und erst nach einer Vorauswahl in die Details geht. Wenn man außerdem berücksichtigt, dass oft bestimmte Kombinationen unmöglich sind, verringert sich die Zahl der Fälle noch weiter. Allerdings sollte man nicht voreilig vermeintlich unmögliche Kombinationen verwerfen, da gerade die Kombinationen, die außergewöhnlich, aber realisierbar sind, hohes Innovationspotential bergen. Auch wenn die Berücksichtigung dieser Bedingungen noch immer eine hohe Zahl an Kombinationen übrig lässt, kann die morphologische Methode hilfreich sein. Es müssen ja nicht immer alle Möglichkeiten durchgespielt werden. Oft ist es schon anregend, wenn intuitiv oder gar zufällig verschiedene Kombinationen ausprobiert werden. Ein anderer Ansatz, den Lösungsraum systematisch aufzuspannen sind strukturierte Fragenkataloge. Bei der großen Vielfalt an Problemen, ist es aber nicht verwunderlich, dass derartige Kataloge entweder recht abstrakt sind oder aber auf spezielle Problemkategorien zugeschnitten sind. Einer der ersten Fragenkataloge stammt von Alex Osborn,

2.4 Lösungssynthese

63

dem Erfinder des Brainstorming. Der Katalog umfasst insgesamt 62 Fragen, die in 8 größere Themengebiete geordnet werden können. Sehr ähnlich aufgebaut ist SCAMPER von Bob Eberle: „Substitute“, „Combine“, „Adapt“, „Modify“, „Put to other purpose“, „Eliminate“, „Reverse“. Ähnliche Fragen findet man auch in anderen Katalogen. Beim Minimieren wird überlegt, wie eine bestehende Lösung durch Weglassen oder Verkleinern bestimmter Merkmale verbessert bzw. neu genutzt werden kann. Ein gelungenes, seit über 50 Jahren am Markt erfolgreiches Beispiel hierfür ist der BIC-Kugelschreiber, bei dem wirklich alles Überflüssige weggelassen wurde, bis nur noch drei unverzichtbare Teile übrig blieben: die Mine, der Griff und eine Kappe, die gleichzeitig als Befestigungsclip nutzbar ist. Bei vielen Lebensmitteldiscountern wurde das Problem der Lagerkosten gelöst, indem das Lager komplett eliminiert wurde, indem die Produkte direkt im Verkaufsraum gelagert werden. Das Gegenstück hierzu bildet das Maximieren. Hier wird versucht durch Hinzufügen bzw. Vergrößern einer Eigenschaft ein Problem zu lösen. Wird mit einem Produkt z. B. kein Geld verdient, kann man versuchen die Stückzahl zu erhöhen, um durch die Massenproduktion den Stückpreis zu verringern. Beim Transformieren geht es darum, Lösungsprinzipien aus einem Sachbereich in einen anderen zu übertragen. Ein Fachgebiet, das sich ausschließlich mit dieser Art der Lösung von Problemen beschäftigt, ist die Bionik. Sie durchsucht den unermesslichen Fundus biologischer Funktionsprinzipien, um sie auf technische Probleme zu übertragen. Beim Kombinieren werden mehrere Lösungsideen oder mehrere Funktionen, die bisher getrennt waren, zusammengefasst. Gerade in der technischen Domäne sind viele naturwissenschaftliche Prinzipien schon recht gründlich erforscht und genutzt. Hier stellen Kombinationen mehrerer Prinzipien die treibende Kraft für Produktinnovationen dar. Ein Beispiel hierfür ist der Mähdrescher (Combine Harvester). Beispiel 2.2 Apotheken-Lagerfläche

Apotheken sind oft in den 1A-Lagen der Innenstädte angesiedelt. Hier sind die Mieten sehr hoch. Daher soll das Problem zu hoher Kosten für den Lagerraum der Arzneimittel durch Fragetechniken untersucht werden. Einige Ideen zeigt die folgende Aufstellung: Kann ich das Problem lösen, indem ich . . .     

. . . die Zahl unterschiedlicher Medikamente verringere? . . . die Zahl der vorrätigen Packungen pro Medikament verringere? . . . den Lagerraum besser ausnutze? . . . den Lagerraum aus dem Erdgeschoss entferne (Speicher, Keller)? . . . den Lagerraum aus der Apotheke entferne, in der Apotheke nur noch Rezepte annehme und die Arzneimittel ausliefere?  . . . ein automatisches Lager verwende statt manuell zu bedienende Schränke?  . . . für nicht rezeptpflichtige Produkte auch den Verkauf automatisiere und damit mehr Umsatz ohne Mehrkosten erziele? J

64

2 Projekte als Problemlösungsprozesse

Eine ganze Sammlung systematischer Methoden zum Finden von Lösungen technischer Probleme stellt TRIZ von G.S. Altschuller dar. Unter anderem hat er aus der Auswertung unzähliger Patente insgesamt 40 innovative Prinzipien extrahiert, die vielen Erfindungen zugrunde liegen. So basiert z. B. die Funktionsweise des Autolichts heute auf mindestens 3 der 40 Prinzipien. Das Prinzip der Zerlegung verteilt die Aufgabe „Beleuchtung“ auf zwei Lampen, so dass bei Ausfall einer Lampe noch eine Notbeleuchtung bleibt. Das Prinzip der Asymmetrie unterscheidet die Leuchtcharakteristik der beiden Scheinwerfer und das Prinzip der Dynamisierung liegt der Umschaltbarkeit zwischen Fern- und Abblendlicht zugrunde. Die Forschung zum Thema Kreativität hat eine ganze Reihe von Methoden hervorgebracht. Dabei gibt es einige wichtige Unterscheidungskriterien, die auch Tab. 2.8 zu Grunde liegen. Hier sind vor allem der Schwierigkeitsgrad der Methoden zu nennen, die Eignung für Einzel- oder Gruppenarbeit und die Frage einer erforderlichen Moderation. Auch die Unterscheidung zwischen rein intuitiven Methoden, Methoden mit erzwungener Perspektivenvariation und systematischen Methoden ist sicherlich von Bedeutung. Dagegen fallen manche Details, die bei der Methodenveröffentlichung hervorgehoben werden, weniger ins Gewicht. In auffälligem Missverhältnis zur Zahl publizierter Methoden steht deren Bekanntheitsund Verbreitungsgrad. Dies gilt insbesondere bei kleinen und mittelständischen Unternehmen. Verschiedene Befragungen bei potentiellen Anwendern von Kreativitätsmethoden haben gezeigt, dass das Brainstorming und auch die Kartenabfrage einen sehr hohen Bekanntheitsgrad besitzen, in deutlichem Abstand gefolgt vom Brainwriting, von der 635Methode und morphologischen Methoden. Viele andere Methoden sind dagegen weniger bekannt. Noch krasser sind die Verhältnisse beim Anwendungsgrad. Hier dominieren eindeutig die verschiedenen Varianten des Brainstormings. Andere Methoden werden oft in vereinfachter Form oder nur selten angewandt.

Tab. 2.8 Vergleich der Kreativitätsmethoden Methode Brainstorming Brainwriting Kartenabfrage (Pinnwand) Methode 635 Morphologische Methode Synektik TRIZ

S S+ S+ S+ S S+ S++ S++

T 6–12 6–12 4–12 6 1.. 4–8 1..

D 2h 2h 2h 1h 8h 2h 8h

H H H H++ H H+ H H

M M M M+ – – M+ –

P P+ – P – P P+ P

S: Schwierigkeitsgrad: S (niedrig), S+ (moderat), S++ (hoch). T: Teilnehmerzahl. D: Dauer (typische Werte). H: Hilfsmittelaufwand: H: (niedrig), H+ (moderat), H++: (hoch). M: Moderation: – (nicht erforderlich), M: (erforderlich aber einfach), M+: (erforderlich und schwierig). P: Protokollierung: – (nicht erforderlich), P (erforderlich aber einfach), P+ (erforderlich und schwierig).

2.5 Lösungsauswahl

65

Vor diesem Hintergrund scheint die Empfehlung angebracht, dass es wichtiger ist, überhaupt eine Kreativitätstechnik bei der Ideenfindung einzusetzen, als einzelne Technik gegeneinander abzuwägen. Eine gute Nutzen-/Aufwands-Relation weist die 635-Methode auf. Sie ist zudem recht einfach in der Handhabung. Für die Einzelarbeit bieten die Fragenkataloge einen guten Ausgleich für die fehlende Anregung in der Gruppe. Zum vollständigen Erfassen und systematischen Durchsuchen des Lösungsraums sind morphologische Methoden ein geeignetes und oft inspirierendes Werkzeug. Aufgrund des sowieso schon hohen Bekanntheitsgrads braucht Brainstorming nicht gesondert empfohlen zu werden.

2.5 Lösungsauswahl Eine richtig und vollständig durchgeführte Ideenfindung und Lösungsausarbeitung liefert mindestens zwei mögliche Lösungen für ein Problem. Da aus Aufwandsgründen in der Regel nur eine Lösung realisiert werden kann, muss eine Entscheidung für eine der verfügbaren Alternativen getroffen werden. Jeder Entscheidung liegen vielfältige Anforderungen, Wünsche und Ziele zugrunde. Damit Entscheidungen nicht zufällig oder willkürlich getroffen werden und dadurch fehleranfällig und bereuungsintensiv werden, ist es notwendig den Entscheidungsprozess systematisch und nachvollziehbar zu gestalten. Dies soll sicherstellen, dass ein zu einem späteren Zeitpunkt oder von anderen Personen getroffene Entscheidung möglichst zum gleichen, richtigen Ergebnis führen würde.

2.5.1

Intuitive und qualitative Entscheidungen

Im Sinne von Problemlösungsprozessen ist ein Ziel ein Punkt oder ein Bereich im mehrdimensionalen Zustandsraum, der durch geeignete Maßnahmen erreicht werden soll. Um entscheiden zu können, welche Maßnahmen zielführend sind, müssen deren Wirkungen bekannt sein. Jede Maßnahme wird sich auf die verschiedenen Zielkriterien unterschiedlich auswirken. Nur in Ausnahmefällen wird es eine Maßnahme geben, die bei allen Kriterien das beste Ergebnis liefert. Im Allgemeinen wird eine Abwägung der verschiedenen Ergebnisse erforderlich sein, um eine Entscheidung für eine der Handlungsalternativen herbei zu führen. Es gibt eine ganze Reihe unterschiedlicher Entscheidungsverfahren, die von einfachen, pragmatischen Ansätzen bis hin zu aufwändigen mathematischen Optimierungsverfahren reichen. Im ersten Ansatz kann man intuitive, qualitative und analytische Verfahren unterscheiden. Sowohl in der beruflichen als auch in der alltäglichen Praxis sind intuitive Verfahren wohl am häufigsten zu finden. Bei ihnen wird die Entscheidung mit wenig Aufwand („aus dem Bauch heraus“) getroffen [Gigerenzer 2007].

66

2 Projekte als Problemlösungsprozesse

Auch wenn derartige Bauch-Entscheidungen vielleicht auf den ersten Blick als zufällig und unprofessionell erscheinen mögen, fließen bewusst oder unbewusst viele Erfahrungen mit vergleichbaren Situationen in den Entscheidungsprozess mit ein. Intuitive Entscheidungen besitzen eine große Berechtigung. Wegen des hohen Aufwands wäre es gar nicht möglich, jede Routineentscheidung einer umfangreichen Analyse zu entwerfen. Außerdem führen intuitive Entscheidungen in vielen Situationen zu ganz akzeptablen Ergebnissen. Allerdings haben sie auch ihre Grenzen. Je gravierender eine Entscheidung ist, je komplexer die zugrunde liegenden Sachverhalte sind und je mehr Personen sich an einer Entscheidung beteiligen, desto notwendiger ist es, die Entscheidung gründlich vorzubereiten und methodisch durchzuführen. Qualitative Entscheidungsverfahren besitzen im Gegensatz zu den intuitiven eine nachvollziehbare Systematik, verzichten aber weitgehend auf mathematische Werkzeuge. Die Systematik beginnt in allen Fällen mit der expliziten Auflistung aller Handlungsalternativen. Bei einer Entscheidung mit Hilfe einer Argumentenbilanz werden alle Handlungsalternativen untersucht und die jeweiligen Vor- und Nachteile einander gegenüber gestellt. Die Alternative, bei der diese Bilanz am positivsten ausfällt, wird dann ausgewählt. Natürlich ist eine derartige Entscheidung subjektiv: Es ist nicht sicher, ob alle Argumente berücksichtigt wurden oder ob alle Argumente gleich wichtig sind. Trotzdem regt die Auflistung von positiven und negativen Argumenten die Auseinandersetzung mit der Problemsituation an und ermöglicht ohne mathematischen Aufwand eine begründbare und nachvollziehbare Entscheidung. Eine Schwäche der Argumentenbilanz ist die fehlende Durchgängigkeit und Vergleichbarkeit der Argumente. Oft führt eine zu einem anderen Zeitpunkt oder von anderen Beteiligten erstellte Argumentenbilanz zu ganz anderen Ergebnissen. Eine Verbesserung kann erreicht werden, wenn statt Argumenten Vergleichskriterien formuliert werden, die für alle Alternativen durchgängig anzuwenden sind. Ein Problem bleibt aber die Relevanz der Kriterien: welche Kriterien sind wichtig, welche weniger wichtig? Das Aufstellen von Gewichtungsfaktoren oder einer Rangordnung bei den Kriterien, fällt dem Menschen umso schwerer, je mehr Kriterien vorhanden sind. Dieses Problem lässt sich mit Hilfe einer Präferenzmatrix lösen. Bei ihr werden je zwei Kriterien paarweise miteinander verglichen. Bei jedem Vergleich werden Punkte zwischen den beiden Kriterien vergeben. Nachdem alle Kriterien paarweise miteinander verglichen wurden, hat jedes Kriterium eine bestimmte Zahl von Punkten erreicht, die entweder zu Gewichtungsfaktoren gemacht oder aber zur Bildung einer Rangordnung genutzt werden können.

2.5 Lösungsauswahl

67

Tab. 2.9 Nutzwertanalyse zur Bewertung von Alternativen Ak anhand der Kriterien K i Kriterium Variable Nutzen K0 K1 ... Kn

2.5.2

V0 V1 ... Vn

U0 U1 ... Un

Gewicht Alternative A1 mit Wirkung E1 g0 g0  U0 .E1 / g1 g1  U1 .E1 / ... ... gn gn  Un .E1 /

...

Alternative Am mit Wirkung Em g0  U0 .Em / g1  U1 .Em / ... gn  Un .Em /

... ... ... ...

Analytische Entscheidungsverfahren

Analytische Entscheidungsverfahren weisen eine durchgängige Systematik in der Gewinnung und Auswertung der Informationen für einen Entscheidungsprozess auf. Sie liefern nachvollziehbare und reproduzierbare Ergebnisse, sind aber auch entsprechend aufwändig. Neben den Handlungsalternativen werden auch die Zielkriterien bei den analytischen Verfahren systematisch untersucht und ausgewertet. Die Nutzwertanalyse geht von einer Zielformulierung aus, die sich aus mehreren Gütekriterien K i zusammensetzt (Tab. 2.9). Der Erfüllungsgrad jedes Kriteriums wird durch eine Zielvariable V i gemessen. Alle Zielvariablen werden mit Hilfe einer Nutzenfunktion U i auf einen einheitlichen Maßstab abgebildet. Der Einfluss der Einzelnutzen auf den Gesamtnutzen wird durch Gewichtungsfaktoren gi ausgedrückt. Die gewichtete Summe aller Einzelnutzen ergibt für jede Alternative einen Gesamtnutzen J. Auszuwählen ist dann die Alternative mit dem größten Nutzen: Jk D

n X i D0

Š

gi  Ui .Ek / D Max :

(2.1)

k

Der Nutzen eines Zielkriteriums kann in unterschiedlicher Form, z. B. durch Punkte, durch Noten oder durch eine Rangfolge gemessen werden. Jede Zielvariable benötigt eine eigene Nutzenfunktion, die den Wertebereich der Zielvariablen auf den Wertebereich des Nutzens abbildet. Für die Vergleichbarkeit ist es dabei notwendig, dass der Maßstab jeder Nutzenfunktion gleich ist. Nutzenfunktionen können für binäre, digitale und auch kontinuierliche Wertebereiche definiert werden. Neben linearen Funktionen (Abb. 2.8a) können auch nichtlineare Effekte, wie z. B. Begrenzungen (Abb. 2.8b) oder Bereichsbildungen sinnvoll sein.

a

b

c

100%

100%

100%

0%

0%

0%

Abb. 2.8 Verschiedene Nutzenfunktionen

68

2 Projekte als Problemlösungsprozesse

Abb. 2.9 Screenshot der bewerteten Varianten A bis E

Beispiel 2.3 Fallbeispiel „CAD-Software“: Nutzwertanalyse

Das Projekt zur Anschaffung eines neuen CAD-Systems bei den Steinbachwerken wird nun konkret. Nach einer Marktrecherche und einer Vorauswahl stehen 5 verschiedene Systeme zur Auswahl. Die System-Anbieter werden zu einer Präsentation eingeladen, an der der Konstruktionsleiter und seine Mitarbeiter teilnehmen, die später mit dem System arbeiten sollen (Abb. 2.9). Die Soll-Ziele werden von 2 der 5 Systeme nicht erfüllt. Bei Variante E liegt der Funktionsumfang unter den geforderten 80 %. Außerdem wurde die Handhabung bei Variante B schlechter als 3,0 benotet. Diese beiden Varianten scheiden daher aus (Abb. 2.10). Aus den verbleibenden Systemen muss nun das Beste ausgewählt werden. Dazu werden die Kriterien gewichtet und auf einen einheitlichen Nutzen-Maßstab abgebildet. Hierfür wird eine Punkteskala von 0 bis 10 gewählt. Die Abbildung der Werte der Zielvariablen auf den Nutzen erfolgt linear. Dabei werden die Werte auf die zulässigen Bereiche begrenzt. Die Summe der gewichteten Nutzenwerte liefert nun die beste Alternative. Wie man erkennt, besitzt Variante C den höchsten Gesamt-Nutzen (6,15), gefolgt von den etwa gleichauf liegenden Varianten A (5,55) und D (5,48). J

Abb. 2.10 Screenshot der gewichteten Nutzenfunktionen für die 3 Varianten A, C und D

2.5 Lösungsauswahl

69

Ein wichtiges, oft sogar herausragendes Kriterium bei technischen Projekten sind natürlich die Kosten. Die Kosten verhalten sich immer gegenläufig zu den übrigen Anforderungen. Qualitativ bessere und schnellere Ergebnisse sind nur zu höheren Kosten zu haben. Daher ist es nahe liegend, den Nutzen der verschiedenen Zielkriterien für eine Lösungsalternative den entsprechenden Kosten gegenüber zu stellen. Dies geschieht bei der Kosten-Wirksamkeitsanalyse. Ausgewählt wird hierbei die Alternative, bei der die Wirksamkeit, d. h. der Quotient aus Gesamtnutzen zu Kosten am größten ist. Wählt man U 0 als Kostenkriterium, so gilt: n P

Jk D

i D1

gi  Ui .Ek / Š

U0 .Ek /

D Max : k

(2.2)

Bei der so genannten Wirtschaftlichkeitsanalyse geht man noch einen Schritt weiter. Der Nutzen U i wird hier nicht in Form von Punkten oder Noten bestimmt, sondern monetär, z. B. als Gewinn oder in Form eingesparter Kosten. Alle Kriterien werden also monetär ausgedrückt. Auf eine Gewichtung kann verzichtet werden, da sich diese implizit aus der Umrechnung des Nutzens ergibt. Es wird dann das Kriterium gewählt, bei dem die Nutzen-Kosten-Differenz maximal ist. Jk D

n X

Ui .Ek /  U0 .Ek /

(2.3)

i D1

Die hier vorgestellten Verfahren der Entscheidungsfindung stellen nur einen Grundvorrat eines vielfältigen Spektrums dar. Unter dem Oberbegriff des Operations Research gibt es eine ganze Reihe von Verfahren, die viele praktische Besonderheiten berücksichtigen, z. B. unsichere Wirkungen, mehrstufige Entscheidungen oder dynamische Prozesse [Eisenführ 1999; Grünig 2004]. Sie sollen aber hier aus Platzgründen und um nicht zu weit vom Thema abzuschweifen, nicht näher behandelt werden. Trotz der großen Palette theoretisch gut fundierter Verfahren der Entscheidungstheorie und der mathematischen Exaktheit der Berechnung sollte man sich auch bei analytischen Verfahren über die unvermeidliche Subjektivität der Ergebnisse in der praktischen Anwendung bewusst sein. Viele Festlegungen von Parametern und Faktoren in den Algorithmen sind unsicher, was sich auch im Ergebnis niederschlägt. Angesichts des beträchtlichen Aufwandes bei den analytischen Entscheidungsmethoden und der Schwierigkeit, zutreffende Werte für Gewichtungsfaktoren, Wahrscheinlichkeiten etc. zu finden, führt dies oft zu der voreiligen Schlussfolgerung, dass die Ergebnisse, die aus einer methodischen Entscheidungsfindung zu erhalten sind, nicht besser sind, als z. B. intuitiv getroffene Entscheidungen. Aber wie schon gesagt, eine solche Schlussfolgerung ist voreilig. Die analytische Entscheidungsfindung mit Hilfe der Optimierung stellt einen wichtigen Bestandteil der Entscheidungsvorbereitung und Entscheidungsfindung bei komplexen Fragestellungen dar. Einfache Fragestellungen können sicher durch Intuition zufrieden-

70

2 Projekte als Problemlösungsprozesse

stellend und mit geringem Aufwand beantwortet werden. Bei mittlerem Schwierigkeitsgrad sollten qualitative Methoden zusätzlich angewendet werden, um die Ergebnisse bei moderatem Aufwand sicherer zu machen. Bei komplexen Fragestellungen und bei wichtigen Entscheidungen sollten auch quantitative Methoden angewendet werden. Sie zeigen, welche Informationen gesucht werden müssen, und wie diese zu verknüpfen sind. Selbst wenn diese Informationen nur unsicher sind, führt die Beschäftigung mit der Aufgabenstellung zu mehr Einsicht und damit auch zu einer besseren Entscheidung, selbst wenn diese dann doch qualitativ oder gar intuitiv getroffen wird. Stimmen dann intuitiv, qualitativ und analytisch gefundene Lösungsalternative überein, hat man zusätzliche Sicherheit. Stimmen die Lösungen dagegen nicht überein, sind alle Herleitungen nochmals zu überprüfen und die Ursache der Diskrepanz zu suchen.

2.6 Weiterführende Literatur

Betsch, T.; Funke, J.; Plessner, H.: Denken – Urteilen, Entscheiden, Problemlösen. Springer-Verlag, 2011. Didaktisch gut aufgebaute Einführung in die psychologischen Grundlagen des Problemlösens. Haberfellner, R. et al.: Systems Engineering. Orell Füssli, 14. Aufl. 2018. Eine umfassende Darstellung der theoretischen Grundlagen und der Anwendung des Systemansatzes in technischen Projekten. Schlicksupp, H.: Ideenfindung. Vogel-Verlag, 1998. Beschreibung der bekanntesten Methoden zur Findung von Ideen mit anschaulichen Beispielen.

3

Projektgründung

Wie das Fundament für ein Gebäude, so soll die Projektgründung für ein Projekt eine tragfähige Basis bilden. In diesem Kapitel werden die wichtigen Arbeiten zur Projektgründung beschrieben (Abb. 3.1). Bei der Initiierung eines Projekts wird dessen Rahmen festgelegt. Hierzu gehört die Erfassung der Anforderungen, die Klärung der Projektziele und die Erstellung einer Projektdefinition. Im Falle externer Auftraggeber ist ein vollständiger, fachlich, kaufmännisch und juristisch belastbarer Auftrag zu entwickeln. Das Lastenheft als Anforderungsdokument und das Pflichtenheft, das zur Beschreibung von Inhalt und Umfang des Projekts dient, werden vorgestellt. Anschließend wird auf die Kalkulation eingegangen. Insbesondere wird das Aufwands-Auftrags-Dilemma bei der Erstellung von Angeboten erläutert und es werden mögliche Lösungen des Problems beschrieben.

Nach der Bearbeitung des Kapitels sind Sie in der Lage,  die wichtigsten Rahmendaten eines Projekts in Form einer Projektdefinition zusammenzufassen,  das Zieldreieck von Projekten zu beschreiben und Beispiele für seine Zusammensetzung zu beschreiben,  die Bedeutung und Zusammensetzung eines Projektauftrags als verbindliche Vereinbarung zwischen Auftraggeber und Auftragnehmer zu erläutern,  die Aufgaben und mögliche Gliederungen von Lastenheften und Pflichtenheften zu benennen,  das Aufwands-Auftrags-Dilemma bei der Aufwandsabschätzung und Kalkulation von Projekten zu erkennen und zu lösen.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 W. Jakoby, Projektmanagement für Ingenieure, https://doi.org/10.1007/978-3-658-32791-0_3

71

72

3

Anforderungen Ausschreibung Lastenhe

Projektgründung

Projekt iniieren

Projekt-Definion

Aurag entwickeln

Pflichtenhe

Angebot kalkulieren

Angebot

Abb. 3.1 Prozesse der Projektgründung

3.1 Die Projektinitiierung 3.1.1 Zustandekommen von Projekten Die Entstehungsgeschichten von Projekten sind sicherlich so vielfältig wie die Projekte selbst:  jemand hat die Idee für ein neues Produkt oder ein neues Verfahren,  eine Fabrik, eine Brücke oder ein Flughafen soll neu gebaut werden,  in einem Produktionsprozess tritt ein gravierender Mangel auf, der behoben werden soll,  ein potentieller Kunde hat eine Herstellung oder Lieferung eines Produkts ausgeschrieben oder gar schon den Auftrag erteilt. Ideen für Projekte können sich zufällig ergeben, aber das Zustandekommen eines Projekts ist kein Selbstläufer. Es muss aktiv betrieben und gestaltet werden. Die dazu notwendigen Schritte werden unter dem Begriff der Projektinitiierung zusammengefasst (Abb. 3.2). Hierzu gehört das Definieren von Projektzielen, -inhalt und -umfang. Projekten liegen immer Ideen, Forderungen und Ziele zugrunde. Nur wenn sie klar sind, besteht berechtigte Hoffnung auf ein erfolgreich verlaufendes Projekt. Die Klärung der Ziele führt zu der Frage der Stakeholder: wer könnte an einem Projekt (aktiv) beteiligt sein und wer könnte vom Projekt (passiv) betroffen sein. Im heutigen Qualitäts- und Projekt-Verständnis können alle Stakeholder Anforderungen stellen. Die Identifikation aller Stakeholder ist daher die Voraussetzung für die vollständige Erfassung aller Anforderungen und der darauf aufbauenden Formulierung der Ziele. Die beiden wichtigsten Rollen im Kreis der Stakeholder sind Auftraggeber (AG) und Auftragnehmer (AN). Beide treffen in Gestalt des Auftrags eine Vereinbarung, in der sie sich zu bestimmten Leistungen und Gegenleistungen verpflichten. Bei internen Projekten gehören Auftraggeber und Auftragnehmer zum gleichen Unternehmen. Auslöser für

3.1 Die Projektinitiierung

73

Abb. 3.2 Aktivitäten zur Initiierung eines Projekts

Projekte können in diesem Fall z. B. die Entwicklung eines neuen Produkts, die Umorganisation bestehender Arbeitsabläufe oder größere Anschaffungen sein. Der Start eines solchen Projekts bedarf einer Genehmigung. Dazu ist es notwendig, den geplanten Projektinhalt zu beschreiben, den erforderlichen Aufwand und die zu erwartende Laufzeit zu benennen. Selbstverständlich ist dies zu Beginn nicht exakt möglich. Aber ohne eine grobe Schätzung oder die Nennung eines Rahmens für die Kosten und die Termine, ist eine Genehmigung kaum möglich. Bei externen Projekten tritt ein anderes Unternehmen oder eine externe Person als Auftraggeber auf. Daher gibt es zusätzliche Schnittstellen und der Auftrag für das Projekt zieht oft weit reichende kaufmännische und juristische Konsequenzen nach sich. Daher sind entsprechende vertragliche Vereinbarungen notwendig. Auch bei externen Projekten ist in der Regel eine interne Beantragung und Genehmigung erforderlich. So kann z. B. der Vertrieb einen Auftrag akquirieren, der ein Projekt notwendig macht. Die wesentlichen Merkmale des Projekts werden dann festgehalten und bei der Vertriebs- oder Geschäftsleitung wird ein entsprechender Antrag gestellt. Diese wird Aufwand und Nutzen für das Projekt abwägen und mit anderen anstehenden Projekten vergleichen. Erst nach der Genehmigung kann der Auftrag bestätigt und das Projekt begonnen werden.

3.1.2 Ein Projekt definieren Je stärker der Projektcharakter bei einem Vorhaben gegeben ist, desto größer ist zu Beginn die Ungewissheit. Sie betrifft z. B. die angestrebten Liefergegenstände, die Ziele, die notwendigen Arbeiten, die Termine, die benötigten Ressourcen und die anfallenden Kosten. Schon zur groben Klärung dieser Fragen ist Aufwand notwendig. Andererseits kann kein Projekt begonnen werden, ohne dass ein grober Rahmen festgelegt wurde. Deshalb ist eine Definition eines Projekts notwendig. Sie fasst die wichtigsten Festlegungen zusammen und wird daher manchmal auch als Projekt-„Steckbrief“ bezeichnet. In der Projektdefinition sollen die wichtigen Fragen zum Projekt beantwortet werden. Was ist die Ausgangssituation? Welche Ziele werden verfolgt? Welche großen Arbeitspakete sind vorhersehbar? Welches sind kritische Faktoren? Können Meilensteine benannt und ein Budgetrahmen festgelegt werden? Die Definition eines Projekts setzt also eine erste,

74

3

Projektgründung

grobe Analyse der Aufgabenstellung und zum Teil auch eine grobe Planung der erforderlichen Aktivitäten und des Ablaufs voraus. Beispiel 3.1 Fallbeispiel „CAD-Software“: Projektdefinition

Abb. 3.3 zeigt die Projektdefinition für das Fallbeispiel „CAD-Software“. Dabei wurde das Muster-Formular aus dem Anhang verwendet. Neben den Kopfdaten, die in jedem Projekt enthalten sein sollten, sind die wichtigen Informationen zum Projekt in knapper Form zusammengefasst. Die Adressaten dieses Dokuments erhalten einen schnellen Überblick über Zweck, Ziel und Inhalt eines Projekts sowie über seine zeitlichen, finanziellen und organisatorischen Rahmenbedingungen. J Die Darstellung der Ausgangssituation gibt den Zustand vor Beginn des Projekts wieder. Sie sollte den Zweck des Projekts und dessen Notwendigkeit erkennen lassen. Die Ziele beschreiben das angestrebte Projektergebnis. Da der Katalog der Zielkriterien bei einem typischen Projekt oft recht umfangreich ist, muss man sich auf die wichtigsten Ziele konzentrieren. Termin- und Kostenziele brauchen hier nicht angegeben zu werden, da sie bei den Meilensteinen bzw. beim Budget explizit genannt werden. Die Projektbeschreibung schildert den Arbeitsinhalt und den Ablauf des Projekts mit den wichtigen Teilprojekten und Phasen. Der Arbeitsinhalt und -umfang sollte aus dieser Schilderung erkennbar sein. Meilensteine bilden wichtige Wegmarken im Projektverlauf. Sie sollten auch zeitlich zugeordnet werden. Bei der Formulierung ist daher auf die Benennung von Ereignissen („Ende Probebetrieb“) und nicht von Tätigkeiten („Entwicklung der Schaltung“) zu achten. Zur Definition eines Projekts empfiehlt sich die Verwendung einer einheitlichen Vorlage. Dies erleichtert den Verfassern die Erstellung der Definition und den Lesern die schnelle Orientierung. Um eine möglichst knappe Form zu erreichen müssen die Beschreibungen nicht immer vollständig ausformuliert werden, sondern sie können in stichpunktartiger Form festgehalten werden. Bei internen Projekten von mittlerer oder geringer Größe kann eine Projektdefinition ohne weiteres zur Beantragung des Projekts und zur Genehmigung verwendet werden. Dazu wird sie von der genehmigenden Instanz, also z. B. der Unternehmens-, Bereichsoder Abteilungsleitung und durch den Projektleiter zur Bestätigung unterzeichnet. Selbstverständlich ist es zu Projektbeginn schwierig, die notwendigen Angaben für die Projektdefinition zu erstellen. Aber gerade das macht sie notwendig. Sie regt das Nachdenken an und eine grobe, ungefähre Aussage ist viel besser als gar keine. Eine genauere Analyse und detaillierte Aussagen folgen dann in späteren Phasen und Dokumenten der Projektplanung. Die Projekt-Definition – oft wird auch von einem Projekt-Steckbrief gesprochen – sollte eine möglichst kompakte Beschreibung der wesentlichen Aspekte eines Projekts beinhalten. Sehr hilfreich ist es, den Umfang von vorneherein zu beschränken, damit die Darstellung übersichtlich bleibt und sich gleichzeitig auf die wichtigsten Merkmale fokussiert. Der typische Umfang eines solchen Steckbriefs beträgt eine Seite („One Pager“).

3.1 Die Projektinitiierung

75

Abb. 3.3 Projektdefinition für das Projekt „CAD-Software“

Neben der textlichen Beschreibung eines Projekts kommen teilweise auch graphische Übersichtspläne zum Einsatz. Als Projekt-Canvas („Leinwand“) bezeichnet man großformatigere, vorstrukturierte Pläne, bei denen die wichtigen Informationen in entsprechenden Feldern eingetragen und durch graphische Symbole unterstützt werden. Die einheitliche Aufteilung auf einem Canvas erleichtert das schnelle Erfassen und Wiederfinden der Informationen. Oft wird ein Projekt-Canvas als Poster in einem gemeinsamen Projektarbeitsraum platziert.

76

3

Projektgründung

Noch freier ist die Gestaltung einer Projekt-Landkarte. Auf der Landkarte werden bestimmte Projektaspekte und die bestehenden Beziehungen angeordnet und vorwiegend in graphischer Form mit wenig Text dargestellt. So kann z. B. der grobe Ablauf als „RoadMap“ dargestellt, werden, was eine räumliche Zuordnung des jeweils erreichten Fortschritts ermöglicht. Diese Art der Darstellung nutzt den Vorteil, dass man sich als Mensch graphische Darstellungen und Anordnungen wesentlich besser merken kann, als abstrakte textliche Begriffe. Gleichzeitig muss bewusst bleiben, dass es sich hier immer nur um eine Visualisierung geht, bei der graphische Symbole als Gedankenstützte für die tatsächlichen komplexen Sachverhalte dienen.

3.1.3 Stakeholder und Projektumfeld analysieren Projekte werden von Menschen für Menschen gemacht. Über die Inhalte, Termine, Kosten, Anforderungen und Ziele hinausgehend, sollten daher immer die handelnden Personen im Auge behalten werden. In erster Linie werden natürlich die Akteure betrachtet, die die Arbeiten eines Projekts ausführen, also die Projektleitung und das Projektteam. Darüber hinaus gibt es aber eine Vielzahl anderer Beteiligter, die zum Erfolg eines Projekts beitragen können oder die von einem Projekt betroffen sind. Als Sammelbegriff für alle diese Personen hat sich die Bezeichnung Stakeholder etabliert. Teilweise wird auch der Begriff der interessierten Parteien verwendet. Gerade zu Beginn eines Projekts ist es notwendig, die Stakeholder eines Projekts und deren Interessen zu erfassen und in der Planung zu berücksichtigen. Noch vor der Festlegung der Aufgaben und Rollen des Projektteams muss das Umfeld des Projekts analysiert werden. Da es nicht immer auf Anhieb leicht fällt, alle Stakeholder zu erkennen, ist eine formale Gliederung des Umfelds hilfreich (Tab. 3.1). Von grundsätzlicher Bedeutung ist die Unterscheidung zwischen unternehmensinternen und externen Personen. Neben dem Projektteam und der Projektleitung, sind im Unternehmen die Geschäftsleitung, die verschiedenen Abteilungen und auch ein interner Auftraggeber zu berücksichtigen. Laufen im Unternehmen mehrere Projekte, wird es zu deren Koordination einen Lenkungsausschuss und zur Unterstützung des Projektmanagements ein PM-Office geben. Wichtige externe Stakeholder sind die Kunden, Zulieferer und Kooperationspartner. Weitere Stakeholder können je nach Projekt Behörden, Nachbarn, Mitbewerber und die allgemeine Öffentlichkeit sein.

Tab. 3.1 Arbeitsschritte der Stakeholder- und Umfeldanalyse 1 2 3 4

Arbeitsschritte Stakeholder identifizieren (intern/extern), (Betroffene/Beteiligte) Projekteinfluss analysieren und bewerten (Promoter/Opponenten, Einflussstäke) Maßnahmen festlegen (z. B. informieren, einbinden) Sächliches Umfeld erfassen (z. B. Gesetze, Richtlinien, Vorschriften, Infrastruktur)

3.1 Die Projektinitiierung

77

Als erstes Ergebnis der Umfeldanalyse liegt eine Liste von Stakeholdern vor. Die einzelnen Personen und Personengruppen sind in der Regel von sehr unterschiedlicher Bedeutung für das Projekt. Die Art des Einflusses und dessen Stärke muss daher im nächsten Schritt heraus gefunden werden. Bei den Personen, die vom Projekt betroffen sein können, ist deren Einstellung zum Projekt wichtig. Positiv eingestellt sind Personen, die sich vom Projekt Verbesserungen oder Vorteile erwarten. Sie können als Promotoren eingesetzt werden. Natürlich wird es auch Personen geben, die dem Projekt ablehnend gegenüber stehen. Gründe hierfür können tatsächliche oder vermutete Benachteiligungen oder Beeinträchtigungen sein. Typische Beispiele für derartige Opponenten können Nachbarn bei Bauvorhaben oder betroffene Abteilungen bei Organisationsprojekten sein. Projektgegner können zu deutlichen Verzögerungen, zu Blockaden oder gar zum Projektabbruch beitragen. Für den Erfolg eines Projekts und für die Akzeptanz seiner Ergebnisse müssen selbstverständlich die Opponenten erkannt und deren Anliegen berücksichtigt werden. Neben reinen Opponenten und Promotoren gibt es oft auch neutral oder ambivalent eingestellte Personen, die sowohl Vorteile als auch Nachteile des Projekts erkennen. Neben der Frage einer positiven, negativen oder neutralen Einstellung zum Projekt ist bei den Stakeholdern natürlich deren Einflussstärke, deren Bedeutung für das Projekt und deren Macht zu berücksichtigen. Diese Größen können nur selten in Form von Zahlenwerten ausgedrückt werden. Dies ist aber auch nicht nötig, da es in den meisten Fällen genügt, eine Einteilung der Einflussstärke in mehrere Gruppen vorzunehmen. Beispiele können eine ABC-Analyse mit drei unterschiedlich wichtigen Gruppen sein oder eine Einteilung in fünf Gruppen mit abnehmender Bedeutung. Nach der Sammlung der Stakeholder und der Analyse von deren Bedeutung sollten für die wichtigen Stakeholder Maßnahmen festgelegt werden. Positiv eingestellte Betroffene können eventuell als Promotoren gewonnen werden. Neutrale oder Skeptiker können eventuell frühzeitig über den Ablauf eines Projekts und die erwarteten Ergebnisse informiert werden. Gemäß dem Leitsatz, dass alle sozialen Probleme durch mangelnde Kommunikation erklärt werden können, lassen sich viele Komplikationen am Rande eines Projekts durch frühzeitige Information verringern. Beispiel 3.2 Erwartungen und Befürchtungen von Stakeholdern

Teammitglieder können sich von der Mitwirkung im Projekt zusätzliche Qualifikationen, eine bessere Bezahlung und Aufstiegsmöglichkeiten erwarten. Als Risiken können sie die hohe Arbeitsbelastung betreffen oder befürchtete Nachteile bei der späteren ReIntegration in die Linienabteilung. Ein Projekt mit einer neuartigen Aufgabe kann einerseits als sehr interessante Herausforderung gesehen werden. Andererseits kann der einem Projekt immanente Schwierigkeitsgrad auch zu Unsicherheit und zur Angst vor dem Scheitern führen. Die Linienabteilung, die Mitarbeiter ins Projektteam entsendet, hat natürlich Bedenken, dass die eigenen Aufgaben darunter leiden oder von den verbleibenden Beteiligten

78

3

Projektgründung

zusätzlich übernommen werden müssen. Sofern das Projektergebnis nicht direkt der Abteilung zu Gute kommt, überwiegen bei der Sicht auf das Projekt die Nachteile. Die Erwartungen eines Auftraggebers richten sich in erster Linie auf das angestrebte Ergebnis, das im Lastenheft beschrieben wurde. Nicht eingehaltene Termine, geringerer Leistungsumfang, geringere Qualität und höhere Kosten zählen dagegen zu den typischen Risiken aus Sicht der Auftraggeber. Bei den nicht direkt eingebundenen externen Stakeholdern wie z. B. Nachbarn, Wettbewerbern oder der allgemeinen Öffentlichkeit werden in der Regel Bedenken und Befürchtungen überwiegen. Bei einem Bauprojekt können z. B. Nachbarn Nachteile während der Bauphase oder aber auch dauerhafte Beeinträchtigungen durch den Baukörper, wie z. B. versperrte Sicht, Schattenwurf oder Lärm gesehen werden. J Zum Umfeld eines Projekts gehören neben den Personen auch sächliche Faktoren. Laufen in einem Unternehmen mehrere Projekte gleichzeitig, so sind die dadurch entstehenden Randbedingungen, wie z. B. Ressourcenbegrenzungen zu berücksichtigen. Im Zweifelsfall müssen hier Prioritäten gesetzt werden, die mit den Interessen der einzelnen Projekte kollidieren. Dies ist in der Regel die Aufgabe eines projektübergreifenden Multiprojektmanagements. Aber auch die Vermeidung von Konflikten mit den Aufgaben der Linienabteilungen stellen wichtige Umgebungsanforderungen dar. Auch die Umgebung außerhalb eines Unternehmens kann einen starken Einfluss auf das Projekt besitzen. In erster Linie sind hier natürlich Gesetze, Vorschriften und Richtlinien zu nennen, die berücksichtigt werden müssen. Aber auch neue technische Entwicklungen, Änderungen des Marktumfelds und allgemeine soziale Entwicklungen, können sich in einem Projekt auswirken. Die Umfeld- und Stakeholderanalyse sollte sehr früh, am besten bereits in der Vorbereitung eines Projekts erfolgen. Dies bedeutet aber nicht, dass sie dann für den weiteren Ablauf erledigt wäre. Die Gruppe der betroffenen Personen kann sich im Laufe eines Projekts erweitern. Auch die Einstellung der Personen und deren Einfluss auf das Projekt kann sich ändern. Größere Änderungen müssen erfasst und in geeignete Reaktionen umgesetzt werden. Das Stakeholder-Management ist daher als dauerhafter Bestandteil des Projektmanagements zu sehen.

3.1.4 Anforderungen erfassen Mit den Stakeholdern und dem Projektumfeld sind auch die Quellen von Anforderungen in einem Projekt bekannt. I

Eine Anforderung ist eine Aussage über eine Eigenschaft oder Funktion, die ein Produkt oder Prozess erfüllen muss oder soll.

Im besten Fall legen die Stakeholder ihre Anforderungen explizit vor (Abb. 3.4). Der klassische Weg hierfür ist ein Lastenheft. Im Idealfall ist es vollständig, die Anforderun-

3.1 Die Projektinitiierung

79

Abb. 3.4 Anforderungen und Ziele

gen sind widerspruchsfrei und ändern sich während der Projektlaufzeit nicht. Wie gesagt: dies ist ein Idealfall. In realen Projekten muss man damit umgehen, dass Anforderungen vergessen werden, dass sie teilweise unklar formuliert werden und dass sie sich widersprechen. Sehr oft können die Kunden die Anforderungen gar nicht explizit formulieren. Agile Methoden halten hierfür den Weg der Use-Cases und der User-Stories bereit: Die Anwender beschreiben, was sie mit dem angestrebten Produkt machen möchten und wie sie es am liebsten machen wollen. Neben den expliziten Anforderungen der Anwender – sei es traditionell als Lastenheft oder agil als Use-Cases – müssen auch implizite Anforderungen berücksichtigt werden. Ein zu erstellendes Produkt bewegt sich immer in einem fachlichen Umfeld, in dem ein gewisser „Stand der Technik“ erwartet wird. Dieser wird in den meisten Fällen gar nicht ausdrücklich benannt, sondern stillschweigend vorausgesetzt. Dass ein Auto eine Heizung oder eine Wegfahrsperre hat, war vor vielen Jahren vermutlich eine explizite Anforderung. Heute ist dies in einem neuen Auto selbstverständlich. Sind derartige Anforderungen sicherheitsrelevant oder dienen in anderer Weise zum Schutz der Menschen oder der Umwelt, werden sie durch den Gesetzgeber zwingend vorgeschrieben. Ein neues Auto muss Rückhaltesysteme wie Sicherheitsgurt und Airbag besitzen und es muss auch Grenzwerte beim Schadstoffausstoß einhalten. Explizite Anforderungen – so umfangreich sie auch sein mögen – bilden heute nur den sichtbaren teil eines Eisbergs. Viel umfangreicher ist oft der implizite Bereich in Gestalt vorausgesetzter oder verpflichtender Anforderungen. Anforderungen an ein Produkt als Projektergebnis und an das Projekt als Ganzes stellen die Basis für die Qualitäts- und damit auch für die Erfolgsbeurteilung dar. Die Hauptursache für das Scheitern von Projekten sowie für massiven Mehraufwand und gravierende Terminüberschreitungen sind unvollständige, unklare und veränderliche Anforderungen. Die gründliche Analyse der Anforderungen zu Beginn eines Projekts kostet zwar einigen Aufwand und auch einige Überwindung, da noch kein offensichtlicher Fortschritt erzielt wird. Der hier investierte Aufwand wird aber um ein Vielfaches eingespart durch Vermeidung von unnötigen oder wiederholten Arbeiten. Sie bildet außerdem die Basis für die Sicherstellung der Qualität des Projekts.

80

I

3

Projektgründung

Der Erfüllungsgrad der Anforderungen ist das Maß für die Qualität eines Projekts.

Aus der Analyse der externen Anforderungen werden die internen Ziele des Projekts abgeleitet. Die Ziele bilden den Sollwert für das Management eines Projekts. Die Zielkriterien, die einem Projekt zugrunde liegen, sind so vielfältig wie die Projekte selbst. Daher kann es auch kein einheitliches Zielsystem für unterschiedliche Projekte geben. In jedem Projekt geht es darum, innerhalb einer begrenzten Zeit und mit begrenzten Ressourcen ein definiertes Ergebnis zu liefern. Auf diesem Abstraktionsniveau lassen sich einige Gemeinsamkeiten in den Zielsystemen unterschiedlicher Projekte finden. Vollkommen offensichtlich sind die zeitlichen Anforderungen an ein Projekt. Das Gesamtergebnis und wichtige Zwischenergebnisse müssen zu bestimmten Terminen vorgelegt werden. Egal ob diese Termine nun fest vorgegeben sind und daher nicht verhandelbare Randbedingungen des Auftraggebers darstellen oder ob die Termine nur in gewissen Grenzen liegen sollen und damit zu Gütekriterien werden, immer wird es zeitliche Zielkriterien in einem Projekt geben. Die Termine stellen daher eine Dimension des Zielraums dar. Eine weitere Basisdimension sind die Kosten. Die Ressourcen in einem Projekt, insbesondere die finanziellen Ressourcen sind begrenzt und sollen möglichst sparsam eingesetzt werden. Das Kostenkriterium setzt sich aus einer Vielzahl von Teilkriterien zusammen: der Arbeitsaufwand der beteiligten Personen, die eingesetzten Maschinen, Rohstoffe, Werkzeuge Räume, zugekaufte Leistungen. Alle eingesetzten Ressourcen verursachen Kosten bzw. können unmittelbar in Kosten umgerechnet werden. Es ist daher sinnvoll, alle diese Teilkriterien zu einem Basiskriterium „Kosten“ zusammenzufassen. Viele Anforderungen und Teilziele betreffen das Produkt oder die Dienstleistung, die Gegenstand eines Projektes sind. Hier werden vielfältig Anforderungen an die Funktionsweise, an die Gestaltung und an die Handhabung gestellt. Diese sind sehr projektspezifisch und können kaum verallgemeinert werden. Man kann diese Anforderungen aber zu einem Basiskriterium zusammenfassen. Als Namensgebung hat sich der Begriff „Qualität“ durchgesetzt, der hier recht weit gefasst werden muss. Vereinfacht könnte man sagen, dass das globale Zielkriterium „Qualität“ alle Teilziele umfasst, die nicht zeitlicher Natur oder monetärer Art sind. Soll eines der drei grundlegenden Zielkriterien verbessert werden, geht dies immer nur zu Lasten eines anderen oder gar der beiden anderen. Steigen die Qualitätsanforderungen (Gestrichelter Verlauf) wird hierfür mehr Zeit bzw. mehr Geld gebraucht. Kürzere Termine (strichpunktiert) gehen zu Lasten der Qualität und der Kosten. Kosteneinsparungen lassen sich zum Teil durch längere Laufzeit und durch geringere Qualität erkaufen. Die grundlegende Bedeutung dieses Zusammenhangs gilt praktisch in allen Projekten. Sie wird in der Literatur oft als „magisches“ Projektdreieck bezeichnet. Da an keiner Stelle die „Magie“ dieses Dreiecks näher erläutert wird, kann das Ganze eher als netter, prägnanter Name für einen grundlegenden Sachverhalt angesehen werden. In diesem Buch wird stattdessen der Begriff Zieldreieck verwendet (Abb. 3.5).

3.2 Der Projektauftrag

81

Abb. 3.5 Zieldreieck von Projekten („Magisches“ Projektdreieck)

3.2 Der Projektauftrag 3.2.1 Bedeutung und Inhalt des Projektauftrags Ein Projekt als zeitlich begrenztes Vorhaben mit einem am Ende erwarteten Ergebnis braucht einen klaren Auftrag. Dieser wird bei der Projektgründung vom Auftraggeber an den Auftragnehmer erteilt. Bei kleinen Projekten kann dies ein und dieselbe Person sein, die aber dann zwei verschiedene Rollen übernimmt. In der Regel sind Auftraggeber und Auftragnehmer unterschiedliche Personen oder auch unterschiedliche Unternehmen. Der Projektauftrag muss dann nicht nur fachlich, sondern auch rechtlich auf eine solide Basis gestellt werden, um Klarheit über die Ziele und die Modalitäten der Zusammenarbeit herzustellen. Beispiel 3.3 Taxifahrt

Am Flughafen springt ein Mann ins Taxi: „Los, schnell zum Messegelände.“ Sorgfältig faltet der Fahrer seine Zeitung zusammen, startet den Motor, setzt die Uhr auf Null und fährt los, dabei den Mann im Rückspiegel musternd und unverständlich etwas in seinen Dreitagebart murmelnd. Bei der Ankunft am Messegelände beschwert sich der Fahrgast. Er kommt zu spät zu seinem Termin, die Fahrt ist ihm zu teuer und er wurde am West- statt am Südeingang abgesetzt. Was ist passiert? Der Gast hat dem Fahrer einen Auftrag erteilt, der unpräzise, unvollständig und zudem unhöflich formuliert war. Dass bei einem derartigen Auftrag ein fehlerhaftes Ergebnis (falscher Zielort), ein verpasster Termin und zu hohe Kosten heraus kommen, ist zu erwarten. Dabei ist es fast schon egal, ob der Fahrer nicht besser konnte oder nicht besser wollte. J Im Projektauftrag dokumentiert ein Auftraggeber seine Anforderungen an das Projekt und das Projektergebnis. Der Auftragnehmer beschreibt, welche Leistungen er erbringen wird (Abb. 3.6). Mit der Unterzeichnung des Auftrags verpflichten sich beide zu bestimmten Leistungen und Gegenleistungen und zu bestimmten Bedingungen, unter denen das Projekt durchgeführt wird. Am Ende des Projekts wird das erreichte Ergebnis anhand des Auftrags überprüft: Wurden alle zugesagten Leistungen erbracht? Wurden die Bedingungen eingehalten?

82

3

Auftraggeber

Projektauftrag Was? Wie? Wann?

Projektgründung

Auftragnehmer: Projektdurchführung

Projektergebnis

Abb. 3.6 Projektauftrag als Vereinbarung zwischen Auftraggeber und Auftragnehmer

Ein Projektauftrag ist also eine vertragliche Vereinbarung zwischen Auftraggeber und Auftragnehmer. Die juristische Strenge des Vertrages kann dabei sehr unterschiedlich sein. Sie reicht vom juristisch schwachen Charakter einer Zielvereinbarung bei kleinen unternehmensinternen Projekten bis hin zu umfangreichen Vertragswerken mit verbindlichen Lieferungs-, Zahlungs-, Gewährleistungs- und Haftungsbedingungen bei externen Auftraggebern. Die Festlegungen des Projektauftrags wirken sich auf das gesamte Projekt aus. Fehler die am Anfang gemacht werden, haben weitreichende Folgen. Ein Projektauftrag sollte daher so präzise, wie möglich sein. Hierzu gehört, dass er alle Anforderungen vollständig umfasst, dass er keine unnötigen Anforderungen enthält und dass seine Formulierungen unmissverständlich sind. Angesichts seiner Bedeutung für ein Projekt sollte es selbstverständlich sein, dass ein Projektauftrag immer in schriftlicher Form dokumentiert und von den Beteiligten unterzeichnet wird. Die Informationen, die ein Projektauftrag enthalten muss, stammen zum Teil vom Auftraggeber und zum Teil vom Auftragnehmer. Sie können in drei Kategorien unterteilt werden (Abb. 3.7). Der fachliche Teil beschreibt den Projektgegenstand, der als Ergebnis erwartet wird. Der organisatorische Teil definiert die wichtigen Bedingungen für die Projektdurchführung. Der juristische Teil schließlich umfasst die rechtsrelevanten Vereinbarungen zwischen den beteiligten Vertragspartnern.

Projektauftrag Auftraggeber Auftragnehmer Ausgangssituation Anforderungen / Ziele fachlicher Teil

Aufgabenstellung krit. Faktoren Meilensteine Budget

Projektteam

Vertrags-Bed.

Vertrags-Bed.

Unterschrift

Unterschrift

organisatorischer Teil

juristischer Teil

Abb. 3.7 Bestandteile und Verantwortlichkeitsbereiche des Projektauftrags

3.2 Der Projektauftrag

83

Im fachlichen Teil beschreibt der Auftraggeber zunächst die Ausgangsituation, die den Anlass und die Basis für das Projekt bildet. Dann werden die Ziele beschrieben, die durch das Projekt erreicht werden sollen und die zu erfüllenden Anforderungen. Eine allgemein gehaltene Aufgabenbeschreibung soll den Projektinhalt möglichst allgemeinverständlich und knapp zum Ausdruck bringen. Besondere Hervorhebung verdienen die Faktoren, die für den Erfolg oder Misserfolg des Projekts entscheidend sind. Hierhin gehört auch die Darstellung der wichtigsten Risikofaktoren. Der organisatorische Teil des Auftrags umfasst die Vereinbarungen zur Projektdurchführung. Hierzu gehören die Meilensteintermine, insbesondere den Start- und Endtermin für das Projekt. Die Preisvereinbarungen zu den Projektkosten müssen mindestens eine Festlegung des Gesamtbudgets enthalten. Bei länger laufenden Projekten müssen auch Teilbudgets spezifiziert werden, die nach Erreichen wichtiger Meilensteine freigegeben oder als Teilzahlung geleistet werden. Bei internen Projekten kann es sinnvoll sein, bei den Kosten zwischen Sachkosten und dem Personalaufwand zu differenzieren. Falls der Auftraggeber bestimmte Einsatzmittel, also z. B. Maschinen, Einrichtungen, Räumlichkeiten beistellt, muss dies auch im Auftrag festgehalten werden. Soweit der Auftragnehmer hierzu schon in der Lage ist und soweit es den Auftraggeber interessiert, kann auch die personelle Besetzung des Projektteams im Auftrag genannt werden. Auch wenn noch nicht alle Namen feststehen, muss auf jeden Fall ein Projektleiter als verantwortlicher Ansprechpartner benannt werden. Bei externen Projekten sind juristische Vereinbarungen ein wichtiger Bestandteil des Auftrags. Hierzu gehören die allgemeinen Geschäftsbedingungen der beteiligten Geschäftspartner sowie die Gewährleistungs- und Haftungsvereinbarungen. Vor allem bei Großprojekten hat sich die Handhabung von Rechtsansprüchen im Verlaufe und am Ende eines Projekts als wichtiges Teilgebiet etabliert [Gregorc 2009]. Dieses so genannte Claim Management sollte daher bereits bei der Formulierung der juristischen Vereinbarungen des Auftrags angewendet werden.

3.2.2 Auftragsdokumente Die Form und der Umfang von Auftragsdokumenten sind so vielfältig wie die Projekte selbst. Sie reichen von einer einfachen Projektdefinition im Umfang von einer Seite bei einem kleinen, internen Projekt, bis zu mehrere Hundert Seiten umfassenden Aufgabenbeschreibungen und ganze Ordner füllenden Vertragspapieren. Je nach Initiierung und Ablauf, kann die Projektdefinition auch als Projektantrag einer Unternehmensabteilung oder als Projektgenehmigung durch die Geschäftsleitung verwendet werden. Bei externen Projekten – sie werden oft auch als Auftragsprojekte bezeichnet – sind Auftraggeber und Auftragnehmer verschiedene juristische Personen. Hier sind neben den fachlichen und organisatorischen Aspekten zusätzlich rechtliche Bedingungen zu beachten, zu klären und vertraglich festzuhalten.

84

3

Projektgründung

Abb. 3.8 Auftragsdokumente

Die Auftragsphase beginnt hier mit einer Anfrage oder der Ausschreibung eines Projekts, z. B. durch ein Lastenheft. Ein potentieller Auftragnehmer antwortet hierauf mit einem Angebot. Es enthält allgemeine, technische, kaufmännische und juristische Aussagen (Abb. 3.8). Im allgemeinen Teil kann ein Anbieter die wesentlichen Bestandteile seines Angebots in knapper Form zusammenfassen und seine spezifischen Kompetenzen hervorheben. Dadurch bietet sich die Chance, bei den entscheidenden Personen auf der Seite der Auftraggeber Vertrauen in die Leistungsfähigkeit des Auftragnehmers zu schaffen und die Vorteile gegenüber den Mitbewerbern zu verdeutlichen. Im technischen Teil werden die Lieferungen und Leistungen detailliert beschrieben. Der kaufmännische Teil macht Aussagen über den Preis, Zahlungsbedingungen, Lieferfristen und Termine. Strittig sind oft Haftungs- und Gewährleistungsfragen. Sie sollten daher im Angebot vertraglich geregelt werden. Die Vertragsbedingungen können individuell zwischen Auftraggeber und Auftragnehmer verhandelt werden. In manchen Branchen gibt es aber auch allgemein akzeptierte Vertragsbedingungen, wie z. B. die Allgemeinen Bedingungen für Lieferungen und Leistungen der Elektroindustrie des Zentralverbandes der Elektrotechnik und Elektroindustrie (ZVEI), die Vergabe- und Vertragsordnung für Bauleistungen (VOB) in der Baubranche oder die Verdingungsordnung für Leistungen (VOL) des Wirtschaftsministeriums für öffentliche Aufträge. Die Erstellung eines Angebots, mit der Angabe von Kosten, Lieferzeiten und Lieferumfang erfordert eine Reihe von Kenntnissen, die erst durch ausgiebige Beschäftigung mit der Anfrage gewonnen werden können. Die Erstellung eines Angebots stellt somit bereits einen schnellen, groben Durchlauf durch die Projektphasen der Aufgabenanalyse, des Lösungsentwurfs und der Projektplanung dar. Bei einem verbindlichen Angebot sind die Angaben des Angebots rechtlich verpflichtend. Wird der Auftrag dann erteilt, so ist der Auftragnehmer zur Annahme und Ausführung verpflichtet; im anderen Fall drohen Regressansprüche. Daher sollte jedes verbindliche Angebot mit einer Bindefrist zeitlich begrenzt werden. Möchte der Anbieter zunächst noch keine Verpflichtung eingehen, muss das Angebot als „freibleibend“ gekennzeichnet

3.2 Der Projektauftrag

85

werden. Damit ist das Angebot zunächst unverbindlich. Ein rechtlich wirksamer Vertrag kommt erst dann zustande, wenn der Anbieter den Auftrag nach Erteilung ausdrücklich bestätigt. Beispiel 3.4 Angebotsgliederung

Die folgende Auflistung skizziert die Struktur eines Angebots. Der allgemeine Teil gibt einen kurzen, aber prägnanten Überblick. Der technische Teil und die allgemeinen Bedingungen können als Anhang detailliert ausgeführt werden.  Allgemeiner Teil, – Die Aufgabe besteht aus . . . – Besondere Probleme hierbei sind . . . – Unsere Lösung für diese Aufgabe umfasst folgende Komponenten . . . – Der besondere Nutzen unser Lösung für Sie besteht aus . . . – Für eine Zusammenarbeit sind folgende Vorteile von Bedeutung . . .  Technischer Teil, – Detaillierte Beschreibung des Liefer- und Leistungsumfangs, – Technische Daten, Soll-Werte, – Kennwerte.  Allgemeine Vertragsbedingungen (kaufmännisch und juristisch), – Preis, Preisbasis, Zahlungsbedingungen, Eigentumsvorbehalt; Lieferfrist und Termine; Versandbedingungen und Liefervorbehalte; Abnahmeprozedur; Haftung; Gewährleistungsfrist; Angebotsbindefrist; Gerichtsstand und anwendbares Recht. J Bei großen Projekten kann über das Angebot, die Auftragserteilung und -bestätigung hinaus ein spezieller Projektvertrag abgeschlossen werden. Dieser fasst neben den Projektzielen, den Lieferungen und Leistungen alle Vereinbarungen zusammen, die z. B. Zahlungsmodalitäten, Termine, Haftungsfragen, Anforderungen an die Berichtserstellung, Geheimhaltungsvorschriften, Abnahmebedingungen, Lizenzen, Patente und Nutzungsrechte betreffen können. Die beschriebene Struktur eines Auftrags stellt natürlich eine verallgemeinerte und teilweise auch idealisierte Sicht der Schnittstelle zwischen Auftraggeber und Auftragnehmer dar. In der Praxis finden sich viele Variationen und Abweichungen. Im Extremfall werden manche Aufträge auf der Basis mündlicher Absprachen oder in minimaler schriftlicher Form erteilt. Auch wenn dies im Einzelfall auch einmal gut ausgehen kann, bildet ein derartiger Beginn oft schon die Basis für ein gescheitertes oder sich in endlosem Streit erschöpfenden Projekt.

86

3

Projektgründung

3.2.3 Formale Anforderungen Die Auftragsdokumente fassen die Anforderungen an ein Projekt zusammen. Ein mangelhafter Auftrag ist ein idealer Nährboden für scheiternde Projekte. Um dies zu vermeiden, sollte ein Auftrag einige Qualitätskriterien erfüllen. Auch wenn diese Kriterien offensichtlich erscheinen mögen, zeigen viele negative Beispiele, dass deren Einhaltung bei weitem nicht selbstverständlich ist. Als erste Anforderung an einen Auftrag soll dessen Verständlichkeit hervorgehoben werden. Gerade weil es oft um fachlich anspruchsvolle Aufgaben geht, sollte eine möglichst klare und einfache Sprache verwendet werden. Für weitschweifig verschnörkelte, mit Fremdwörtern gespickte, mit Phrasen verstopfte und die fachliche Kompetenz und Eloquenz des Verfassers unterstreichende Formulierungen ist der Auftrag das falsche Forum. Eindeutige und widerspruchsfreie Forderungen machen die Aufgabe klar. Missverständnisse und Ärger am Projektabschluss werden dadurch vermieden. Auftraggeber und Auftragnehmer sind oft in unterschiedlichen Fachsprachen beheimatet. Deshalb sollten alle wichtigen Termini definiert werden. Als Nächstes ist bei der Erstellung des Forderungskatalogs auf Vollständigkeit zu achten. Problematisch sind meist nicht die Kern-Anforderungen eines Projekts. Diese stehen unter besonderem Augenmerk und werden daher nur selten vergessen. Problematischer sind Neben- oder Rand-Anforderungen. Sie werden entweder vergessen oder vom Auftraggeber als selbstverständlich vorausgesetzt. Beides wird im Laufe des Projekts oder sogar erst bei dessen Abschluss zu Ärger führen. Eine Leistung, die nicht ausdrücklich gefordert wurde, kann nicht hinterher reklamiert werden. Viele Auftraggeber formulieren ihre Anforderungen nach dem Grundsatz, das Unmögliche zu fordern, um das Machbare zu erhalten. Aus Sicht einer wirksamen und wirtschaftlichen Projektdurchführung ist ein derartiger Grundsatz unsinnig und durch das Qualitätsmerkmal der Realisierbarkeit zu ersetzen. Ein Auftrag sollte also nur realistische Forderungen stellen. Unrealistische Forderungen führen zu erhöhtem Aufwand, zu stark überhöhten Budgets und bleiben trotzdem unrealisierbar. Auch bei der Kombination von Forderungen, von denen jede für sich realisierbar ist, kann es Probleme geben. Oft können sich Forderungen gegenseitig widersprechen. Dies passiert besonders dann, wenn sich die Formulierung über einen längeren Zeitraum hinzieht, oder wenn der Forderungskatalog von verschiedenen Beteiligten additiv zusammengestellt wird. Der Forderungskatalog sollte deshalb immer in seiner Gesamtheit betrachtet und auf Widerspruchsfreiheit geprüft werden. Das Bestreben um Vollständigkeit führt oft zu sehr langen Forderungslisten und die Sorge, bloß nichts zu vergessen, kann auch zu unnötigen Forderungen führen. Deshalb sollte schließlich auch auf die Relevanz der Forderungen geachtet werden. Über das eigentliche Ziel hinausgehende Forderungen tragen vielleicht zu einer sichereren Zielerreichung bei, aber sie erhöhen auch die Kosten. Jede Forderung kostet Geld und jede unnötige Forderung verschwendet Geld.

3.2 Der Projektauftrag

87

3.2.4 Lastenheft und Pflichtenheft Alle Forderungen des Auftraggebers müssen vor Projektbeginn erfasst und schriftlich festgehalten werden. Hierzu dient ein Lastenheft. Nach DIN 69905 beschreibt es aus Sicht des Auftraggebers „die Gesamtheit der Forderungen an die Lieferungen und Leistungen“. Für das Dokument, das die Anforderungen zusammenfasst, sind weitere Bezeichnungen im Gebrauch, wie z. B. Anforderungsspezifikation, Kundenspezifikation oder RequirementsSpecification. Im Folgenden wird hier durchgängig der Begriff Lastenheft verwendet. I

Ein Lastenheft beschreibt aus Sicht des Auftraggebers die Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Projekts.

Je nach Projektgegenstand können Lastenhefte sich hinsichtlich Umfang, Aufbau und Inhalt sehr stark unterscheiden. Für kleinere Projekte können die Forderungen des Auftraggebers auf wenigen Seiten (Lasten-„Heft“) festgehalten werden. Größere Projekte dagegen können Lastenhefte mit mehreren Hundert Seiten erfordern. Hier müsste man eher von einem „Lasten-Buch“ sprechen. Bei manchen Aufträgen kann sogar die Erstellung des Lastenhefts bereits ein eigenes Projekt sein. Je präziser die Forderungen des Auftraggebers im Lastenheft fixiert sind, desto klarer wird auch deren Überprüfung am Projektende sein. Auch wenn diese Erkenntnis trivial klingt und tatsächlich seit langem bekannt ist, werden viele Projekte noch immer ohne Lastenheft oder mit unvollständigem Lastenheft begonnen. Wohlwollend betrachtet liegt dies nur zum kleineren Teil an Nachlässigkeiten. Oft werden fehlende Lastenhefte damit begründet, dass sowieso alles klar sei. Zu oft haben sich derartige Vermutungen als Illusionen erwiesen, so dass sie für ein Nichterstellen eines Lastenheftes nicht akzeptabel sind: Wenn tatsächlich alles klar sein sollte, ist ein Lastenheft schnell geschrieben und die Klarheit auch für alle Beteiligten sichergestellt. Gravierender, aber genau so wenig stichhaltig ist der Einwand, dass bei Projektbeginn viele Informationen noch nicht bekannt sind. Ist dies tatsächlich der Fall, müssen die Informationen zuerst beschafft, bewertet und darauf aufbauend entsprechende Entscheidungen getroffen werden, bevor das Projekt begonnen wird. Passiert dies nicht, sind massive Mängel oder gar ein Scheitern des Projekts die drohende Folge. Ein Lastenheft ist also für alle Projekte, egal ob schwierig oder einfach zwingend erforderlich! Die Antwort des Auftragnehmers auf das Lastenheft ist das Pflichtenheft. Hierin fasst er alle Lieferungen und Leistungen zusammen, zu denen er sich mit der Annahme des Auftrags verpflichtet. Das Pflichtenheft bildet also eine Art Rückmeldung des Auftragnehmers an den Auftraggeber, in der er beschreibt, wie er den Auftrag zu erfüllen gedenkt. Gleichzeitig bildet das Pflichtenheft für den Auftragnehmer den Ausgangspunkt für die Planung des Produkts und der erforderlichen Arbeiten im Projekt.

88

I

3

Projektgründung

Das Pflichtenheft beschreibt aus Sicht des Auftragnehmers Art und Umfang der Lieferungen und Leistungen, zu denen er sich verpflichtet.

Lastenheft und Pflichtenheft bilden die Basis für eine Vereinbarung zwischen einem Auftraggeber und einem Auftragnehmer. Das Lastenheft und das Pflichtenheft haben unterschiedliche Aufgaben und sind daher auch zumindest inhaltlich getrennt zu betrachten. Nicht immer ist eine Trennung von Lastenheft und Pflichtenheft zwingend erforderlich. Beide können auch zu einem Dokument zusammengefasst und auch von Auftraggeber und Auftragnehmer gemeinsam verfasst werden. Hieraus resultiert die oft anzutreffende Vermischung beider Profile und die kombinierte Bezeichnung „Lasten-/Pflichtenheft“.

3.2.5 Inhalt und Gliederung von Lasten- und Pflichtenheft Ein Lastenheft ist sehr stark ergebnisorientiert, d. h. es richtet den Blick in erster Linie auf das Produkt als erwünschtes Ergebnis eines Projekts. Je nach Anwendungsbereich gibt es unterschiedliche Anforderungsspektren und auch unterschiedliche Gliederungsvorschläge für Lastenhefte. Auf jeden Fall bildet die Spezifikation der Produktfunktionen den Kern der Anforderungen. Manchmal wird diese Spezifikation auch als „Last“ bezeichnet. Sie beschreibt, was das gewünschte Produkt können muss und was es eventuell zusätzlich können sollte. Sehr hilfreich ist auch die Abgrenzung, d. h. die Beschreibung von Funktionen, die das Produkt nicht zu leisten braucht. Neben den geforderten Funktionen gibt es eine ganze Reihe von Bedingungen, die eingehalten werden müssen. Hierbei kann unterschieden werden zwischen produkt- und projektspezifischen Bedingungen. Produktspezifische Anforderungen resultieren zum Beispiel aus den Einsatzbedingungen (Temperatur, Feuchtigkeit, Erschütterungen, EMV, einzuhaltende Normen und Richtlinien). Weitere Produktbedingungen sind Anforderungen an Produktkosten und Stückzahlen. Projektspezifische Randbedingungen sind zum Beispiel Termine, Anforderungen an der Auftragnehmer (z. B. Zertifizierung) und Vertragsbedingungen. Bei komplexeren Produkten kann das Lastenheft relativ umfangreich werden. Um Lesern des Lastenheftes den Einstieg in die Problematik zu erleichtern und einen schnellen Überblick zu ermöglichen, sollte eine einführende Übersicht den Anfang des Lastenheftes bilden. Die Übersicht sollte mit einer Beschreibung des derzeitigen Ist-Zustandes beginnen, dann den angestrebten Ziel-Zustand in leicht verständlicher, nicht zu detaillierter Form darstellen und die wichtigen Randbedingungen aufzählen. Um alle Beteiligten an einem Projekt, insbesondere Auftraggeber und Auftragnehmer von unterschiedlichen Ausgangslagen zu einer gemeinsamen Verständnisbasis zu führen, ist eine allgemeinverständliche Beschreibung des Auftragsgegenstands notwendig. Dies kann die Beschreibung des Problems sein, das den Auftrag veranlasst. Bei einer Produktentwicklung ist der beabsichtigte Einsatzzweck zu beschreiben. Außerdem sollte der bei Auftragserteilung bestehende Anfangszustand und der bei Projektabschluss angestrebte

3.2 Der Projektauftrag

89

Zielzustand dokumentiert werden. Nützlich ist ein Glossar, das die wichtigen Fachbegriffe definiert. Die folgende Struktur stellt nicht unbedingt eine Standardgliederung für Lastenhefte und Pflichtenhefte dar, sondern sie zählt mögliche Bestandteile in geordneter Form auf. 1. Einführende Übersicht, 1.1. Ausgangspunkt, Ist-Zustand, 1.2. Projektzweck, Ziel-Zustand, 1.3. Randbedingungen und Zielkriterien, 2. Die Produktspezifikation, 2.1. Die Produktumgebung, 2.2. Produktschnittstellen, 2.3. Produktfunktionen, 3. Die Rahmenbedingungen Produktion und Produkteinsatz, 3.1. Anwendungsszenarien und Einsatzbedingungen, 3.2. Produktionsbedingungen, 3.3. Normen, Richtlinien, Vorschriften für das Produkt und dessen Einsatz, 4. Die Rahmenbedingungen für die Durchführung des Projektes, 4.1. Anforderungen an den Auftragnehmer (wie z. B. Zertifizierung), 4.2. Vertragskonditionen (Termine, Gewährleistung, Berichte, Dokumentation), 4.3. Test, Inbetriebnahme, Abnahme, Service, 5. Anhänge: Glossar, Verweise. Der gesamte Prozess der Projektbearbeitung ist eine Reihe von Schritten zunehmender Konkretisierung und Detaillierung. Die Problemanalyse und das daraus folgende Lastenheft sowie der grobe Lösungsentwurf, der zum Pflichtenheft führt, sind die ersten beiden derartigen Schritte. Das Lastenheft beschreibt die Anforderungen an das Projektergebnis, lässt aber dessen Realisierungsdetails offen. Konkreter wird dann das Pflichtenheft. Von den vielen möglichen Lösungen beschreibt es eine in konkreter Form. Oft kann das Pflichtenheft daher als Fortschreibung des Lastenhefts angesehen werden. Beispiel 3.5 Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen

Die Überlappung von Lastenheft und Pflichtenheft kommt bei der Mustergliederung für den Einsatz von Automatisierungssystemen gemäß VDI-/VDE-Richtlinie 3694 zum Ausdruck: 1. 2. 3. 4. 5.

Einführung in das Projekt, Beschreibung der Ausgangssituation (Ist-Zustand), Aufgabenstellung (Soll-Zustand), Kommunikationsschnittstellen, Anforderungen an die Systemtechnik,

90

3

Projektgründung

6. Anforderungen an die Systementwicklung, die Inbetriebnahme und den Einsatz, 7. Anforderungen an die Qualität, 8. Anforderungen an die Projektabwicklung, 9. Systemtechnische Lösung, 10.Systemtechnik (Ausprägung). Die Kap. 1–8 bilden das Lastenheft. Das Pflichtenheft ergibt sich als dessen Fortschreibung in den Kap. 9 und 10. Diese Mustergliederung zeigt sehr deutlich die enge Zusammengehörigkeit beider Dokumente. J In der Baubranche regelt und standardisiert die Vergabe- und Vertragsordnung für Bauleistungen (VOB) die Schnittstelle zwischen Auftraggeber und Auftragnehmer. Ein Auftraggeber listet in einem Leistungsverzeichnis alle gewünschten Leistungen auf. Es handelt sich hierbei um ein spezielles, standardisiertes Lastenheft. Jede Position beschreibt eine Leistungsanforderung mit der Art und Menge der Leistung. Der Anbieter kann nun aufgrund seiner Kalkulation seine Preise für die angefragten Leistungen und eventuell eigene, abweichende Leistungen eintragen. Zusammen mit den individuellen Lieferbedingungen stellt das ausgefüllte Leistungsverzeichnis dann das Angebot dar. Für den Ausschreibenden hat die standardisierte Form der Ausschreibung den Vorteil, die abgegebenen Angebote sehr einfach und transparent miteinander vergleichen zu können. Um bei zusätzlich erforderlichen Leistungen unangenehme Überraschungen zu vermeiden, können optionale Leistungen ausgeschrieben werden. Sie gehen nicht in die Angebotssumme ein, werden aber herangezogen, wenn die entsprechenden Leistungen benötigt werden.

3.3 Projektkalkulation 3.3.1 Das Aufwands-Auftrags-Dilemma Ein Angebot und ein Pflichtenheft als Antwort auf eine Projektanfrage müssen neben technischen Aussagen auch kaufmännische Aussagen, wie Projektkosten und Lieferzeit umfassen. Die Erstellung eines Angebots setzt also bereits eine Aufgabenanalyse, einen zumindest groben Lösungsentwurf, eine belastbare Projektplanung und eine solide Projektkalkulation voraus. Dies alles zu erstellen kostet Zeit und Aufwand. Angesichts des Risikos, den Auftrag trotzdem nicht zu bekommen, stellt sich die Frage, wie viel Aufwand vor der Auftragserteilung notwendig und gerechtfertigt ist. Das Problem ist bei unternehmensinternen Projektanfragen nicht so gravierend. Richtet z. B. die Geschäftsleitung an die Entwicklungsabteilung die Anfrage zur Entwicklung eines neuen Geräts, so muss diese natürlich eine Aussage über Machbarkeit, Kosten und Termine machen. Die Situation ist aber nicht so kritisch, da es in der Regel keinen Wett-

3.3 Projektkalkulation

91

bewerber um den Auftrag gibt. Die Geschäftsleitung entscheidet „nur“, ob sie das Projekt zu den angebotenen Bedingungen und dem versprochenen Ergebnis erteilt oder nicht. Bei externen Projektanfragen gibt es aber in der Regel mehrere, manchmal sogar eine ganze Reihe von Wettbewerbern. Hier entfaltet sich das Dilemma in voller Blüte. Steckt man vor der Auftragserteilung nur wenig Aufwand in Problemanalyse, Lösungsentwurf, Planung und Kalkulation, so kommt man zu unsicheren Aussagen über Machbarkeit, Termine und Aufwand. Im Angebot müssen aber präzise Aussagen gemacht werden. Legt man sich ans untere, optimistische Ende der Schätzbandbreite, ist zwar die Auftragswahrscheinlichkeit hoch, aber das Schätzrisiko ebenso. Kurz gesagt wird man in diesem Fall mit großer Wahrscheinlichkeit Geld drauflegen. Legt man sich dagegen ans obere, sichere Ende der Schätzbandbreite, ist zwar das Risiko gering, aber auch die Auftragswahrscheinlichkeit. Hier wird man mit großer Sicherheit kein Geld verdienen. Man kann versuchen, diese „Wahl zwischen Pest und Cholera“ zu umgehen, indem man sich irgendwo in die Mitte legt. Gelingt es dabei, das Projektrisiko stärker sinken zu lassen, als die Auftragswahrscheinlichkeit, kann die Methode „geringer Aufwand vor Auftragserteilung“ erfolgreich sein. Auf alle Fälle setzt sie ausreichend Erfahrung mit vergleichbaren Projekten voraus, um die Schätzbandbreite nicht allzu groß und das Gefühl für den richtigen Mittelweg verlässlich werden zu lassen. Ist dies nicht der Fall, kann die Entscheidung für die Mitte auch zu „Pest“ und „Cholera“ gleichzeitig führen. Die Unsicherheit bei den Aussagen über Machbarkeit, Termine und Kosten kann verringert werden durch höheren Aufwand vor Auftragserteilung. Aber auch dann gibt es ein Problem. Wenn andere Wettbewerber dies auch machen, werden sie zu ähnlichen Resultaten kommen. Je mehr Wettbewerber dies tun, umso dichter werden die Angebote beieinander liegen und die Auftragsvergabe hängt von kleinen Unterschieden ab, ist also mehr oder weniger zufällig (Abb. 3.9).

Aufwand pessimissch

unbekannter wahrer Wert

opmissch

Zeit

Abb. 3.9 Zusammenhang Schätzaufwand – Schätzgüte

92

3

Projektgründung

3.3.2 Mögliche Lösungen Für das beschriebene Dilemma gibt es keine einfache, pauschale Lösung. Die geeignete Vorgehensweise hängt von verschiedenen Fragen ab: Welche eignen Erfahrungen mit vergleichbaren Projekten liegen vor? Welche und wie viele Wettbewerber gibt es? Wie detailliert ist das Lastenheft des Auftraggebers? Die Analyse einer angefragten Aufgabe und die Abschätzung des erforderlichen Aufwands gelingen umso besser und mit umso weniger Aufwand, je mehr Erfahrungen mit vergleichbaren Projekten vorhanden sind. Daher ist es wichtig, die Erfahrungen, die bei abgeschlossenen Projekten gewonnen wurden und auch Erfahrungen mit Anfragen, die nicht zum Auftrag führten, systematisch zu sammeln und auszuwerten. Die daraus gewonnenen Erkenntnisse ermöglichen es, die kritischen Punkte einer Aufgabe schnell zu erfassen und z. B. mit Hilfe von Kennwerten schnelle Aufwandsabschätzungen zu erstellen. Außerdem ist es nahe liegend, sich besonders auf solche Anfragen zu konzentrieren, die den bereits durchgeführten Projekten ähneln. Werden viele Wettbewerber durch eine Anfrage angesprochen, ist es sinnvoll, den Aufwand für das Angebot strikt zu begrenzen. Bei guter eigener Auftragslage kann man es sich leisten, etwas sicherer zu schätzen. Dagegen kann man Zeiten schlechter eigener Auftragslage durch niedrigere Angebote überbrücken, indem man die Auftragswahrscheinlichkeit zu Lasten der Gewinnspanne erhöht, um die Auslastung des Unternehmens zu sichern. In Branchen mit vielen Wettbewerbern ist es außerdem oft üblich, Ausschreibungen in detaillierter und standardisierter Form, als Leistungsverzeichnis vorzulegen. Dies ermöglicht es den Anbietern, mit überschaubarem Aufwand realistische Angebote zu erstellen. Für die Auftraggeber besitzt dieses Verfahren den Vorteil, dass die Angebote transparent und damit gut vergleichbar sind. Eine andere Vorgehensweise, die mit dem Auftraggeber abgesprochen werden muss, besteht darin, dass in einer ersten Runde mehrere Wettbewerber mit wenig Aufwand eine grobe Kalkulation durchführen und dann im Angebot einen Richtpreis abgeben. Dann werden wenige Wettbewerber in einer zweiten Runde zur Abgabe eines detaillierteren Angebots aufgefordert. In diesem Fall kann die Erstellung eines detaillierten Pflichtenhefts als Bestandteil des Angebots vom Auftraggeber bezahlt werden. Bei sehr neuartigen und komplexen Vorhaben kann sogar die Erstellung eines Lastenhefts ein eigenes, kleineres Projekt sein. Hier wird die Lastenhefterstellung ausgeschrieben und als eigener Auftrag vergeben. Dessen Ergebnis bildet dann die Grundlage für die Ausschreibung des eigentlichen Vorhabens. An dieser Ausschreibung kann sich der Lastenheft-Ersteller genau so wie die Mitbewerber beteiligen. Ist die Analyse einer Aufgabenstellung, der Entwurf einer möglichen Lösung und die zugehörige Kalkulation aufwändig, so kann dem eigentlichen Projekt ein kleineres Projekt vorgeschaltet werden. Es besteht aus einer Analyse der wichtigsten Anforderungen (VorAnalyse) und einer Skizzierung des Lösungsentwurfs (Vor-Entwurf). Darauf aufbauend lässt sich dann eine Kalkulation durchführen, aus der die größten Unsicherheiten beseitigt sind.

3.4 Weiterführende Literatur

93

Projektstudie Vorprojekt V-A

V-A: Vor-Analyse V-E: Vor-Entwurf

Projekt A

V-E

E R V

=> Pflichtenheft => Angebot => Machbarkeit !

A: Analyse E: Entwurf R: Realisierung V: Validierung

=> Produkt

Abb. 3.10 Vorprojekt und Projektstudie

Steht nicht nur das Kostenbudget und der Zeitrahmen in Frage, sondern die grundsätzliche Machbarkeit, so kann dem eigentlichen Projekt auch eine Machbarkeitsstudie (Feasability Study) voran gehen (Abb. 3.10). In der DIN 69905 wird sie als Projektstudie bezeichnet. Gerade bei Forschungs- und Entwicklungs-Projekten mit hohem Innovationsgrad ist dieser Weg sinnvoll.

3.4 Weiterführende Literatur

Rupp, C. Systematisches Requirements-Engineering und -Management. Hanser-Verlag, 6. Aufl. 2014 Behandelt das systematische Erfassen, Analysieren und Dokumentieren von Anforderungen. Das Buch fokussiert vor allem auf IT-Projekte, kann aber auch an vielen Stellen auf allgemeine Projekte übertragen werden. Krügler, E. Projektverträge im Anlagenbau und für vergleichbare Investitionsprojekte. Springer-Verlag, 2013. Beschreibung der gesetzlichen Grundlagen für Verträge zwischen Auftraggeber und -nehmer in Investitionsprojekten. Enthält praktische Vorschläge für die Gestaltung der Vertragstexte

4

Projektorganisation

Dieses Kapitel zeigt Ihnen, wie der Aufbau und der Ablauf von Projekten mit Hilfe von einigen Grundregeln organisiert werden kann (Abb. 4.1). Zunächst werden die verschiedenen Aufbauorganisationsformen vorgestellt, sie lernen deren Vor- und Nachteile kennen und sie können so anhand weniger Kriterien beurteilen, welche Form in einem konkreten Projekt am besten geeignet ist. Der zeitliche Ablauf von Projekten wird in Teilprojekte, Arbeitspakete, Projektphasen und Meilensteine gegliedert. Sie lernen den sequentiellen Ablauf mit strikter Phasenabgrenzung als Standard-Ablaufmodell und das Wasserfallmodell als seine bekannteste Realisierungsform kennen. Sie werden sehen, wie ein Ablauf mit Hilfe des Spiralmodells iterativ organisiert werden kann und wie sich die Projektlaufzeit durch Parallelisierung verkürzen lässt. Zur Regelung der Informationsflüsse in einem Projekt werden zunächst die Zusammenhänge zwischen Information, Kommunikation und Dokumentation aufgefrischt. Dabei sollen Sie die Bedeutung wichtiger Informations-, Kommunikations- und Dokumentenarten kennen lernen. Danach soll die Aufgabe eines allgemeinen Informationsmanagements in Unternehmen bewusst gemacht werden, um dann auf die Besonderheiten der Informationshandhabung in Projekten einzugehen. Abschließend werden die verschiedenen Dokumentenarten vorgestellt, die im Projekt vorkommen und die Aufgabe eines Projektmanagement-Handbuchs wird erläutert.

Nach der Bearbeitung des Kapitels sind Sie in der Lage,  die verschiedenen Aufbauorganisationsformen von Projekten innerhalb eines Unternehmens zu beschreiben und im konkreten Fall, die passende Aufbauorganisation festzulegen,  die Rollen zu benennen, die in Projekten von Personen zu übernehmen sind,

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 W. Jakoby, Projektmanagement für Ingenieure, https://doi.org/10.1007/978-3-658-32791-0_4

95

96

4

Projektorganisation

Projektdefinion Projektaurag

Auauorganisaon definieren

PM-Handbuch

Ablauforganisaon festlegen

Projekt-Ablauforga.

Kommunikaon planen

Komm.-plan

Projekt-Auauorga. Stakeholder-Register Rollenbeschreibung

Abb. 4.1 Prozesse der Projektorganisation

 den Ablauf eines Projekts mit Hilfe von Arbeitspaketen, Teilprojekten, Projektphasen und Meilensteinen zu untergliedern,  die wesentlichen Merkmale des Wasserfallmodells, des Spiralmodells und des Simultaneous Engineerings sowie deren Vor- und Nachteile zu erläutern,  zu erklären, wie der Informations- und Kommunikationsfluss in Projekten organisiert werden kann,  die wichtigsten Dokumentenarten in Projekten zu benennen und die Regeln zu deren formaler Gestaltung festzulegen,  die Bedeutung und den Inhalt eines Projektmanagement-Handbuchs zu erläutern.

4.1

Aufbauorganisation

Als Organ bezeichnet man einen Teil eines Körpers, der eine bestimmte Aufgabe übernimmt und im Zusammenwirken mit anderen Organen die Funktionsweise des Körpers sicherstellt. Es kann sich dabei um verschiedenartige Körper handeln, wie z. B. um biologische, soziologische oder juristische Körper. In der Technik spricht man hier eher von einem System, das aus verschiedenen Komponenten besteht. Für den Begriff der Organisation gibt es zwei unterschiedliche Bedeutungen. Zum einen meint man damit ein Gebilde, das aus mehreren zusammenwirkenden Organen besteht. In dieser Bedeutung ist eine Organisation ein Körper oder ein System. Zum anderen ist Organisation ein Vorgang, bei dem Regeln für das Zusammenwirken von Organen erstellt werden. In der Betriebswirtschaftslehre beispielsweise versteht man unter Unternehmensorganisation die Schaffung von Regelungen, durch das die Arbeitsleistung der Mitarbeiter auf die Unternehmensziele ausgerichtet wird. Überträgt man diese Beschreibung auf die Organisation von Projekten, so kommt man zu folgender Definition:

4.1 Aufbauorganisation

I

97

Projektorganisation ist die Schaffung von Regeln, durch die die Arbeit der Projektbeteiligten auf die Projektziele ausgerichtet wird.

Wie bereits gesehen, kann man ein Projekt als System betrachten. Es besitzt eine statische Struktur und ein dynamisches Verhalten. Beide Aspekte müssen organisiert werden, so dass sowohl die statische Aufbauorganisation als auch die dynamische Ablauforganisation betrachtet werden muss.

4.1.1 Linienorganisation von Unternehmen Bei weitem nicht alle Arbeiten in einem Unternehmen besitzen Projektcharakter. Viele Arbeiten finden regelmäßig und in gleicher Weise wiederkehrend statt. Eine effiziente Produktion verlangt sogar, die Arbeitsabläufe so weit zu standardisieren, dass sie in immer gleicher Weise ablaufen und immer Produkte gleichbleibender Qualität liefern. Ausnahmen und einmalige Probleme sind so weit wie möglich zu vermeiden. Da somit gleichartig wiederholte Arbeiten und Routine in vielen Unternehmen überwiegen, ist die Unternehmensorganisation auch für diese Art von Arbeit optimiert. Sehr typisch ist eine baumartig aufgebaute Unternehmensstruktur. Es gibt mehrere Hierarchieebenen und jeder Mitarbeiter hat einen einzigen unmittelbaren Vorgesetzten. Sachbearbeiter sind in Gruppen organisiert; mehrere Gruppen bilden eine Abteilung, mehrere Abteilungen einen Bereich und mehrere Bereiche zusammen genommen bilden ein Unternehmen. Da von jedem Mitarbeiter über die Hierarchie-Ebenen eine direkte Linie bis zur Unternehmensleitung führt, wird zwar meist von einer Linienstruktur gesprochen, obwohl es sich im Sinne der Graphentheorie eigentlich um eine Baumstruktur handelt. In graphischer Form wird die Organisationsstruktur eines Unternehmens als Organigramm dargestellt (Abb. 4.2). Die Zahl der Hierarchieebenen hängt natürlich von der Unternehmensgröße ab. Geht man davon aus, dass im Durchschnitt etwa 3 bis 20 Mitarbeiter einen Leiter brauchen und wählt einen Wert von 7 Mitarbeitern pro Leiter als Faustregel, kommt man auf die Werte in Tab. 4.1. U: Unternehmensleitung

U

V

E

F

V: Vertrieb E: Entwicklung

K

F: Fertigung K: Kaufmännischer Bereich . . .

. . .

. . .

Abb. 4.2 Organigramm eines Unternehmens

. . .

98

4

Projektorganisation

Tab. 4.1 Zusammenhang zwischen der Zahl der Hierarchieebenen und der Mitarbeiter Ebenen Mitarbeiter

1 1

2 7

3 50

4 350

5 2000

6 15.000

7 100.000

Der entscheidende Vorteil, der zur großen Verbreitung der Linienorganisation geführt hat, ist deren Klarheit. Jegliche Weisungsbefugnis, sowohl die fachliche als auch die disziplinarische, liegt in den Händen einer Person. Missverständnisse oder Weisungskonflikte werden dadurch deutlich verringert.

4.1.2

Formen der Aufbauorganisation

Von den üblichen Arbeiten in einem Unternehmen unterscheiden sich Projekte vor allem durch ihre Einmaligkeit, die zeitliche Begrenzung, die Komplexität, insbesondere der Beteiligung mehreren Personen, Bereiche und Abteilungen. Ein Projekt stellt an die Organisation, vor allem hinsichtlich der fachlichen und disziplinarischen Weisungen eigene Anforderungen, die zum Teil zu den festen Unternehmensstrukturen im Widerspruch stehen. Damit diese Diskrepanz nicht während des Projekts zu Kollisionen führen, ist es notwendig, Unternehmensanforderungen und Projektanforderungen zu Projektbeginn festzulegen. Für jedes Projekt muss entschieden werden, wie die für das Projekt erforderliche Struktur mit der bestehenden Unternehmensstruktur in Übereinklang gebracht werden kann. Soll die Projektarbeit in der gleichen Organisation, wie die Routinearbeit stattfinden, so muss ein Kompromiss zwischen beiden Anforderungen gefunden werden. Zunächst ist zu klären, wer das Projekt leiten soll und wer im Projekt mitarbeiten wird. Hierbei ist auch festzulegen, welche Weisungsbefugnisse ein Projektleiter gegenüber den einzelnen Projektmitarbeitern besitzen soll. Die Bandbreite der Befugnisse reicht von vollständiger Weisungsbefugnis, über eingeschränkte, z. B. rein fachliche Befugnisse bis hin zur Einfluss-Befugnis, die manchmal auch zu einem „guten Zureden“ mutiert. Die Befugnisse des Projektleiters gegenüber den Projektmitarbeitern können individuell sehr unterschiedlich sein, so dass jedes Projekt eine andere Aufbauorganisation besitzt. Es gibt aber einige bewährte Grundstrukturen, die in unterschiedlichen Variationen immer wieder anzutreffen sind. In der Regel werden Projektleiter und Projektmitarbeiter aus dem Unternehmen kommen. Da sie aber mit ihren „normalen“ Aufgaben im Rahmen der Linienorganisation ausgelastet sind, müssen sie ganz oder teilweise hiervon freigestellt werden. Bei einer teilweisen Freistellung haben sie vorübergehend zwei Vorgesetzte: den Projektleiter und den Abteilungsleiter. Hierbei ergeben sich vielfältige praktische Fragen: Wer legt die Prioritäten fest? Wer trifft die fachlichen Entscheidungen? Wer genehmigt den Urlaub? Wer beurteilt die Leistung für die Gehaltsverhandlungen? Einfacher ist es sicherlich, die benötigten Mitarbeiter vollständig aus der Linienstruktur heraus zu nehmen und von ihren normalen Aufgaben zu entbinden. Man erhält dadurch

4.1 Aufbauorganisation

99

Abb. 4.3 Reine Projektorganisation

U

V

E

. . .

F

. . .

K

. . .

P

. . .

. . .

eine reine Projektorganisation, wie sie Abb. 4.3 zeigt. Die Projektmitarbeiter werden für die Projektdauer von den anderen Abteilungen abgeordnet und dem Projektleiter unterstellt. Er besitzt ihnen gegenüber vollständige Weisungsbefugnis. Dadurch ergeben sich keine personellen Konflikte mit anderen Bereichen. Das Projektteam agiert wie eine eigenständige Abteilung. Personelle Probleme, die dadurch entstehen, dass ein Mitarbeiter seinem Linienvorgesetzten und dem Projektleiter unterstellt ist, gibt es bei der reinen Projektorganisation nicht. Trotzdem können auch in dieser Organisationsform Probleme auftreten. Zum einen werden nicht alle Mitarbeiter für die gesamte Projektlaufzeit tatsächlich im Projekt benötigt. Kann der Bedarf auf einen zusammenhängenden Zeitraum konzentriert werden, ist es möglich, den Mitarbeiter auch nur für einzelne Projektphasen ins Projekt zu nehmen. Schwieriger ist es, wenn Mitarbeiter nur zu einem bestimmten Teil, z. B. zu 50 % ihrer Arbeitszeit im Projekt benötigt werden. Hier wird die reine Projektorganisation fragwürdig. Andere personelle Probleme können sich bei der Integration der Mitarbeiter ins Projekt durch die Unterstellung unter der Projektleiter als „Chef auf Zeit“ und bei der Reintegration in die ursprüngliche Abteilung ergeben. Akzeptiert z. B. der Linienvorgesetzte die Leistungsbeurteilung, die der Projektleiter vorgenommen hat, bei der Gehaltsverhandlung? Wie ist das Verhältnis zu den Kollegen, die die Aufgabe des vorübergehend im Projekt Tätigen übernommen und sich damit vielleicht profiliert haben? Aufgrund der beschriebenen Probleme und des größeren Aufwands zur Bildung einer reinen Projektorganisation ist diese nur bei länger laufenden und großen Projekten empfehlenswert. Beispiel 4.1 Neue Produktionslinie für einen Pizza-Hersteller

Ein Lebensmittelhersteller, auf dessen zwei Produktionslinien ausschließlich TiefkühlPizzen hergestellt werden, möchte eine neue, dritte Produktionslinie zur Herstellung von Nudelgerichten aufbauen. Planung, Errichtung und Inbetriebnahme soll im Rahmen eines Projekts erfolgen. Zum Projekt gehören eine Vielzahl von Arbeiten: Festlegung der zu produzierenden Gerichte, Entwurf des zugehörigen automatisierten Produktionsverfahrens, Konstruktion der benötigten Maschinen, Ermittlung des Platzbedarfs und eines geeigneten Standorts für die Produktionslinie sowie deren Aufbau und Inbetriebnahme.

100

4

Projektorganisation

Der zu erwartende Umfang des Projekts, die Zahl der beteiligten Personen im Unternehmen und auch außerhalb des Unternehmens sowie das mit der Erweiterung verbundene Risiko machen es ratsam ein eigenständiges Projektteam, mit eigenem Projektleiter und fest zugeordneten Mitarbeitern zu bilden. J Eine zweite Form der Organisation findet man, wenn fachliche und disziplinarische Weisungsbefugnisse voneinander getrennt werden. Die im Projekt tätigen Mitarbeiter bleiben disziplinarisch in ihren jeweiligen Bereichen, werden aber der fachlichen Weisung des Projektleiters unterstellt. Stellt man die disziplinarische Weisung senkrecht und die fachliche waagerecht dar, erhält man eine matrixförmiges Organigramm, weshalb man auch von einer Matrix-Projektorganisation spricht (Abb. 4.4). Vorteilhaft macht sich hier die weitgehende Beibehaltung bestehender personeller Strukturen bemerkbar, und es wird trotzdem ein funktionierendes Projektteam geschaffen. Auch die Aufnahme neuer Projektmitarbeiter, die vorübergehende Mitarbeit im Projekt oder die Rückintegration in die Linienarbeit ist relativ einfach möglich. Leider kann es bei zwei Vorgesetzten immer zu Spannungen und Weisungskonflikten kommen. Für deren Lösung bedarf es entweder des guten Willens der Beteiligten oder einer übergeordneten Entscheidungsinstanz. Die Auftrags-Projektorganisation stellt eine Mischform der beiden ersten Varianten dar (Abb. 4.5). Der Projektleiter hat in seinem Team sowohl feste Mitarbeiter, gegenüber denen er vollständig weisungsbefugt ist, als auch Mitarbeiter anderer Bereiche, denen er nur fachliche Weisungen erteilen darf. Diese Organisationsform lässt sich vor allem dann sinnvoll einsetzen, wenn das Projekt einige Mitarbeiter erfordert, die dauerhaft im Projekt arbeiten und andere, die nur temporär benötigt werden. Eine weitere Abschwächung der Befugnisse des Projektleiters führt zur Einfluss-Projektorganisation (Abb. 4.6). Der Projektleiter besitzt hierbei keine formalen Weisungsbefugnisse, sondern kann die Mitarbeiter nur durch seine eigene oder von der Unternehmensleitung verliehene Autorität führen. Er kann also nur im Dialog mit den Linienleitern das Projekt führen. Die Funktionsfähigkeit dieser Organisationsform ist sehr stark von der Person des Projektkoordinators abhängig, von dessen Autorisierung durch die Geschäftsleitung und der Akzeptanz durch die Linienleiter. Die Einfluss-Projektorganisation lässt sich vor allem bei kleineren Projekten anwenden und bei Projekten, bei denen die Auf-

Abb. 4.4 Matrix-Projektorganisation

U

V

E

. . .

F

. . .

K

. . .

P

. . .

4.1 Aufbauorganisation

101

Abb. 4.5 Auftrags-Projektorganisation

U

V

E

F

. . .

K

. . .

. . .

P

. . .

Abb. 4.6 Einfluss-Projektorganisation

U

V

E

. . .

P

F

. . .

K

. . .

. . .

gabentrennung zwischen den Bereichen unstrittig ist. Um der Funktion des Projektleiters genügend Gewicht zu verleihen, wird die Position im Organigramm als Stabsstelle eingebaut, die direkt der Unternehmensleitung unterstellt ist. Daher wird oft auch von einer Stabs-Projektorganisation gesprochen. Beispiel 4.1 Fallbeispiel „Solaranlage“: Aufbauorganisation

Das Ingenieurbüro Sunnyboy, das seit mehreren Jahren solarthermische Anlagen für private Wohnhäuser plant und mit Hilfe von Subunternehmen errichtet, erhält eine Anfrage der Steinbachwerke zur Erweiterung der Heizung des Bürogebäudes durch eine Anlage zur solarthermischen Energiegewinnung. Die Kubatur und der Wärmebedarf des Bürogebäudes liegen beide um einen Faktor 4 über dem normaler Wohnhäuser. Die an das Bürogebäude angrenzende Maschinenhalle besitzt ein ausreichend großes Dach zur Anbringung der Solarkollektoren. Welche Organisationsform sollte bei Sunnyboy für das Projekt gewählt werden? Bei dem Ingenieurbüro ist eigentlich jeder Auftrag ein Projekt. Es sollte daher eine eigene Projektierungsabteilung besitzen, die alle Anfragen bearbeitet. Auch wenn sonst nur Wohnhäuser ausgestattet werden, ist die Anbringung einer Solaranlage auf einer Maschinenhalle hinsichtlich der Anlagen- und Projektkomplexität nicht so unterschiedlich. Die Anfrage sollte daher als „normales“ Projekt in der Projektierungsabteilung durchgeführt werden. Das Ingenieurbüro erhält nun die Anfrage eines Lebensmitteldiscounters zur Ausstattung aller 40 Filialen mit Solaranlagen. Verglichen mit den übrigen „normalen“ Projekten ist diese Anfrage deutlich umfangreicher. Das Risiko ist ebenfalls deutlich

102

4

Abb. 4.7 Projektleitung in der Linie

Projektorganisation

U

V

E

. . .

F

. . .

K

. . .

. . .

größer und könnte die Substanz des Ingenieurbüros gefährden. Aus diesem Grund sollte sich die Bedeutung des Projekts auch in der passenden Organisationsform widerspiegeln. Hier erscheint eine Matrix-Projektorganisation sinnvoll zu sein. Eine Person wird als eigenständiger Projektleiter eingesetzt, der auf Mitarbeiter anderer Abteilungen fachlich zurückgreifen kann. Diese bleiben aber in ihren angestammten Abteilungen, um die dort laufenden Arbeiten nicht komplett lahm zu legen. Außerdem werden sie im Discounter-Projekt wohl nicht permanent benötigt, da der größere Teil der Projektarbeit, nämlich die Anlagenerrichtung, von externen Unternehmen ausgeführt wird. J Es ist auch denkbar, die Vorteile der Linienorganisation und der reinen Projektorganisation zu kombinieren, indem ein Bereichsleiter gleichzeitig auch Projektleiter wird, wie in Abb. 4.7 dargestellt. In diesem Fall sind alle Entscheidungen, die für ein Projekt benötigt werden, an einer Stelle gebündelt, und es kann keine Weisungskonflikte geben. Man spricht von einer Projektleitung in der Linie. Allerdings ist eine Linien-Projektleitung nur bei kleinen Projekten anwendbar. Außerdem sollte der Personalbedarf zu einem großen Teil aus einer einzigen Abteilung gedeckt werden. Die Weisungen innerhalb der eigenen Abteilung sind für den Projektleiter, der ja sowieso schon Linienleiter ist, unproblematisch. Seine Weisungsbefugnisse gegenüber den Projektmitarbeitern aus anderen Abteilungen müssen aber gesondert definiert werden. Beispiel 4.2 Aufbauorganisation für ein CRM-Projekt

Bei den Steinbachwerken werden die Kundendaten bislang auf mobilen und stationären Rechnern der beteiligten Personen individuell verwaltet. Es gibt keinen zentralen Datenbestand, so dass es immer wieder unvollständige und fehlerhafte Daten gibt. Deshalb soll eine Software für die zentrale Verwaltung der Kundendaten (CRM: Customer Relationship Management) angeschafft werden. Mit der CRM-Software sollen die Abteilungen Vertrieb, Montage, Auslieferung, Bestell- und Rechnungswesen sowie der Service arbeiten. An der Spezifikation der Anforderungen und auch an der Systemeinführung müssen alle diese Abteilungen beteiligt werden. Eine CRM-Software ist ein rechnergestütztes Werkzeug, also ein ITProdukt, so dass Fachkenntnisse in diesem Bereich im Projekt benötigt werden.

4.1 Aufbauorganisation

103

Die Idee, einen externen Spezialisten als Projektleiter einzusetzen und eine Einfluss-Projektorganisation aufzubauen, wird von den Beteiligten verworfen, da zu viele Informationen über interne Abläufe im Projekt zu berücksichtigen sind. Da die Steinbachwerke in der Person des IT-Spezialisten, Herrn Wulff über ausreichendes IT-Know-how verfügen, wird er zum Projektleiter ernannt. Der Aufwand und die Bedeutung des Projekts werden nicht so hoch eingestuft, so dass die Organisationsform „Projektleitung in der Linie“ gewählt wird. Herr Wulff übernimmt also die Aufgabe der Projektleitung zusätzlich zu seinen normalen Aufgaben, erhält aber für Routineaufgaben, wie Installation neuer Software und Administrierung neuer Rechner im Firmennetzwerk, Unterstützung von einem externen IT-Büro. Aus jeder betroffenen Abteilung wird ein Mitarbeiter in Teilzeitform im Umfang von einem Arbeitstag pro Woche in das Projektteam entsandt. J

4.1.3 Auswahlkriterien für die Organisationsform Die Frage der Projektorganisation läuft im Kern darauf hinaus, festzulegen von wem die Projektmitarbeiter ihre Weisungen erhalten. Das Bündel an Weisungsbefugnissen kann unterschiedlich aufgeteilt werden. In den beiden Extremfällen erhält ein Mitarbeiter seine Weisungen vollständig von einer Person, entweder dem Linienleiter (reine Linienstruktur) oder dem Projektleiter (reine Projektstruktur). Zwischen diesen beiden Extremfällen existieren Mischlösungen, bei denen zwischen disziplinarischen und fachlichen Weisungen unterschieden wird (Matrix-Projektorganisationen), oder bei denen an die Stelle von Weisungsbefugnissen Koordinationsbefugnisse treten (Einfluss-Projektorganisation). Die beiden wichtigsten Parameter zur Auswahl der richtigen Organisationsform sind die Projektgröße und die Schnittstellenzahl. Je größer die Projekte in Relation zur Unternehmensgröße sind und je vielfältiger die Schnittstellen, desto größer sollte der Umfang der Weisungsbefugnisse des Projektleiters (in Relation zu den Linienleitern) sein. Eine qualitative Einordnung zeigt das Diagramm in Abb. 4.8. Die Projektgröße wird dabei durch mehrere Einflussfaktoren bestimmt. Hier ist zunächst einmal die Zahl der beteiligten Personen zu nennen. Aber auch der Arbeitsaufwand ist eine wichtige Größe, die sich umso stärker von der Personenzahl unterscheidet, je mehr Mitwirkende nur in Teilzeit im Projekt beschäftigt sind. Ein weiterer, in die Abschätzung der Projektgröße einfließender Faktor ist die Höhe des Projektbudgets. Bei allen diesen Punkten ist selbstverständlich die Relation der Projektgröße zur Größe des Unternehmens zu berücksichtigen. Ein Projekt mit einem Aufwand von 10 PJ wird für ein Unternehmen mit 20 Beschäftigten ein großes Projekt sein, während ein Aufwand von 50 PJ für ein Unternehmen mit mehreren tausend Beschäftigten wohl als klein eingestuft wird. Auch die Schnittstellenzahl eines Projekts wird von mehreren Faktoren bestimmt. Im Wesentlichen hängt sie davon ab, wie viele unterschiedliche Abteilungen des Unternehmens an einem Projekt beteiligt sind und in welchem Ausmaß sie vom Projekt betroffen sind. Kommen die Projektmitarbeiter nur aus zwei oder drei unterschiedlichen Abteilun-

104

4

Weisungsbefugnisse: V: vollständig F: fachlich E: Einfluss

Projektgröße und -bedeutung Reine PO V

groß Auftrags-PO V+F

klein

Linie-PO V+E niedrig

Projektorganisation

Matrix-PO F

Einfluss-PO E hoch

Schnittstellenanzahl und -bedeutung

Abb. 4.8 Abhängigkeit der Organisationsform von Projektgröße und Schnittstellenzahl

gen, ist die Schnittstellenzahl gering. Sind mehr als die Hälfte der Abteilungen personell im Projekt eingebunden, wird man von hoher Schnittstellenzahl sprechen. Bei kleinen Projekten mit wenig bereichsübergreifenden Schnittstellen wird der Leiter des Bereichs, aus dem die meisten Projektmitarbeiter kommen, zum Projektleiter ernannt. Er erhält auf die Mitarbeiter anderer Bereiche lediglich Einflussbefugnis. Der Projektleiter übt seine Aufgabe neben seiner hauptamtlichen Bereichsleitungsaufgabe aus. Bei kleinen Projekten mit vielen bereichsübergreifenden Schnittstellen wird ein hauptamtlicher Projektleiter bestellt, der aber nur Einflussbefugnisse erhält. Der Projektleiter kann sich vollständig auf die Projektaufgabe konzentrieren. Da er nur vorübergehend auf der gleichen Ebene tätig ist wie die Bereichsleiter in Linienfunktion, wird er von diesen nicht so stark als Konkurrent gesehen und eher unterstützt. Bei mittleren Projekten mit wenig bereichsübergreifenden Schnittstellen gibt es einen hauptamtlichen Projektleiter mit festen Mitarbeitern, auf die er vollständige Weisungsbefugnis erhält, sowie einer fachlichen Weisungsbefugnis auf Projektbeteiligte aus anderen Bereichen. Bei mittleren Projekten mit vielen bereichsübergreifenden Schnittstellen gibt es einen hauptamtlichen Projektleiter der ausschließlich auf Projektbeteiligte aus anderen Bereichen zugreifen kann und für diese nur fachliche Weisungsbefugnisse hat. Für große Projekte schließlich wird ein eigener Projektbereich gebildet. Alle Projektbeteiligte sind dem Projektleiter für die Dauer des Projekts vollständig unterstellt. Beispiel 4.3 Brandmeldezentrale

Bei einem mittelständischen Hersteller von Systemen für die Gebäudeautomatisierung soll eine neue Brandmeldezentrale entwickelt werden. Der Aufwand hierfür wird mit ca. 5 Personenjahren und einer Laufzeit von 2 Jahren veranschlagt. Die Entwicklungsabteilung besteht aus 20 Mitarbeitern, von denen ein Hardwareund ein Software-Entwickler dauerhaft im Projekt arbeiten sollen. Aus den Abteilun-

4.1 Aufbauorganisation

105

gen Vertrieb, Produktion und mechanische Konstruktion wird je 1 Mitarbeiter zeitweise im Projekt benötigt. Welche Aufbauorganisation soll für das Projekt gewählt werden? Aufgrund der Laufzeit und des Umfangs kann das Projekt in Relation zur Unternehmensgröße als Projekt mittlerer Größe eingestuft werden. Die Zahl der Schnittstellen bzw. der Projektbeteiligten ist überschaubar, so dass eine Auftrags-Projektorganisation geeignet erscheint. Die beiden Entwickler werden für die gesamte Projektlaufzeit aus ihrer Abteilung freigestellt, die Mitarbeiter aus den anderen Abteilungen stehen bei Bedarf zur Verfügung. Als Projektleiter könnte einer der beiden Entwickler eingesetzt werden. Eventuell käme auch eine Linien-Projektorganisation in Frage, bei der der Entwicklungsleiter die Rolle des Projektleiters übernimmt. J Beispiel 4.4 Qualitäts-Managementsystem (QMS)

Im gleichen Unternehmen soll nun ein Qualitäts-Managementsystem eingeführt werden, das von allen Abteilungen durchgängig zu nutzen ist. Die Festlegung der Anforderungen, die Auswahl eines geeigneten Systems und dessen Einführung im Unternehmen soll als Projekt durchgeführt werden. Welche Aufbauorganisationsform ist hier geeignet? An dem Projekt sind fast alle Abteilungen des Unternehmens beteiligt. In jeder Abteilung gibt es mehrere Mitarbeiter, die Erfahrungen mit den Arbeitsprozessen und der Anwendung von Verfahren zur Sicherung der Qualität der Arbeitsergebnisse gemacht haben. Diese Erfahrungen sollen in die Auswahl eines QMS eingebracht werden. Der individuelle Aufwand für das Projekt ist wohl eher niedrig anzusetzen, aber aufgrund der Vielzahl der Beteiligten ist mit einer vergleichsweise langen Laufzeit zu rechnen. Es bietet sich eine Einfluss-Projektorganisation an. Die benötigten Mitarbeiter werden nur einen geringen Teil ihrer Arbeitszeit für das Projekt aufwenden, so dass eine Matrix-PO wenig Sinn macht. Gegen eine Linien-PO spricht die Tatsache, dass alle beteiligten Abteilungen gleiches Gewicht im Projekt besitzen. Als Projektleiter wird eine externe Person, die bereits Erfahrungen mit QMS besitzt, auf eine zeitlich befristete Stabsstelle berufen. J

4.1.4 Projektbeteiligte Jede im Projekt beteiligte Person übernimmt eine bestimmte Rolle. Derartige Rollen können z. B. Projektleitung, Projektmitarbeit, Auftraggeber, Auftragnehmer oder Beobachter sein. Betrachtet man die im Projekt zu erledigenden Aufgaben, kann man drei grundlegenden Rollen der Beteiligten unterscheiden. Für jede Aufgabe muss es genau eine verantwortliche Person (V) geben. Aufgaben ohne verantwortliche Person werden selten bedarfsgerecht erledigt. Bei mehreren Verantwortlichen sind Konflikte vorprogrammiert. Des Weiteren gibt es bei jeder Aufgabe

106

4

Projektorganisation

Tab. 4.2 Beispiel einer IMV-Matrix Beteiligte Arbeit a Arbeit b Arbeit c Arbeit d

A V I I I

B M V

C M I V

D M I V

E M M M

F I I I I

mitarbeitende Personen (M), die die Aufgabe durchführen. Zu dieser Personengruppe können eine oder mehrere Personen gehören. Schließlich gibt es für jede Aufgabe auch zu informierende Personen (I), die im besten Falle bei der erfolgreichen Erledigung oder in anderen Fällen bei auftretenden Problemen unterrichtet werden müssen. Ordnet man alle Arbeiten zeilenförmig und alle Beteiligten spaltenförmig an, so entsteht eine Matrix, die so genannte IMV-Matrix, in der jedem Beteiligten seine entsprechende Rolle bei den Arbeiten zugewiesen wird [Kraus 2004]. Die IMV-Matrix schafft Übersicht über die Rollen aller Beteiligten. Ihr Aussehen ermöglicht es auch einige Schlussfolgerungen zu ziehen, ohne dass alle Details der Aufgabenzuordnung bekannt sind. Beispiel 4.5 IMV-Matrix

In der dargestellten IMV-Matrix (Tab. 4.2) gibt es 6 Beteiligte (A–F) und 4 Arbeiten (a–d). Welche Aussagen können über die Rollen der einzelnen Beteiligten gemacht werden? Bei welcher Arbeit handelt es sich um das Gesamtprojekt? Wer ist Projektleiter, wer Auftraggeber und wer Mitarbeiter im Projekt? Welche Vermutung über die Reihenfolge der Arbeiten lässt sich anstellen? Da bei Arbeit a alle Personen beteiligt sind, könnte es sich hier um das Gesamtprojekt handeln. A wäre dann der Projektleiter, B, C, D und E bilden das Projektteam, da sie an den übrigen Arbeiten mitwirken und F ist wahrscheinlich Auftraggeber. Bei den Arbeiten b, c, und d werden Projektleiter und Auftraggeber informiert. Im Team gibt es eine verantwortliche und eine zu informierende Person. Vermutlich laufen die Arbeiten in der Reihenfolge b, c, d ab. J Ein ähnliches Hilfsmittel ist die RACI-Matrix. Sie verwendet 4 Rollen der Projektbeteiligten. Für jede Arbeit muss eine Person verantwortlich sein (R: responsible). Es gibt eine Auftrag gebende Person (A: accountable), die auch das Ergebnis abnimmt und die Kosten trägt. Darüber hinaus gibt es Personen, die beratend hinzu gezogen werden und auch an den Entscheidungen mitwirken (C: consulted), sowie Personen, die den Fortgang über Entscheidungen und Ergebnisse zu informieren sind (I: informed). Darüber hinaus gibt es Vorschläge für weitere Rollen, wie z. B. unterstützende Personen (S: supportive) oder Personen, die die Ergebnisse der Arbeiten verifizieren (V: verifying).

4.2 Ablauforganisation

107

Egal ob nun die IMV-Matrix, die RACI-Matrix oder ein selbst definiertes Repertoire von Rollen verwendet wird – entscheidend ist, dass die wichtigen Rollen der beteiligten Personen für das Projekt, für die Teilprojekte und die Arbeitspakete festgelegt und dokumentiert werden.

4.2 Ablauforganisation 4.2.1

Teilprozesse eines Projekts

In einem Projekt gibt es im Allgemeinen mehrere Beteiligte, die viele Arbeiten zu verrichten haben. Der Prozesscharakter von Projekten, d. h. die logischen und zeitlichen Abhängigkeiten zwischen den verschiedenen Arbeiten, stellen eine beträchtliche planerische und steuernde Herausforderung dar. Um diese zu bewältigen, ist es notwendig, neben den Fragen der Weisungsbefugnisse auch die Abläufe zu organisieren. Die Ablauforganisation eines Projektes, legt allgemeingültige Regeln fest, nach denen alle Aktivitäten mit ihren gegenseitigen Abhängigkeiten in einen geordneten Ablauf zu bringen sind. Hierzu ist es notwendig, ein Projekt als Ganzes so weit in einzelne Teile zu zerlegen, bis man bei überschaubaren und gut planbaren Arbeitseinheiten angelangt. Die kleinste derartige Einheit wird als Arbeitspaket bezeichnet. Ein Arbeitspaket fasst Arbeiten zusammen, die einen engen funktionellen und zeitlichen Zusammenhang bilden. Beispiel 4.6 Arbeitspakete bei der Entwicklung eines elektrischen Geräts

    

Die Anfertigung einer Gehäuseskizze. Das Erstellen des Layouts einer Platine anhand des Schaltplans. Das Programmieren einer datenverarbeitenden Funktion. Die Erstellung eines Benutzerhandbuchs. Das Erstellen des Layouts einer Platine zur Ankopplung von analogen Spannungseingängen an eine CPU.  Die Verdrahtung eines Schaltschranks.  Die Analyse eines Lastenhefts auf technische Machbarkeit. J Ein Arbeitspaket wird immer einer verantwortlichen Person zugeordnet, es besitzt einen klaren Start- und Endtermin und es liefert ein messbares bzw. feststellbares Ergebnis. Aus Sicht des Projektmanagements muss ein Arbeitspaket nicht weiter unterteilt werden, sondern es bildet eine zusammenhängende Einheit, die von der Projektleitung gestartet, nach Fertigstellung von der verantwortlichen Person zurückgemeldet wird und zwischendurch im Normalfall keine Management-Aktivität erfordert. I

Ein Arbeitspaket besteht aus Arbeiten, die funktionell und zeitlich sehr eng zusammengehören und von einer Person ausgeführt werden können. Es stellt

108

4

Projektorganisation

aus Sicht des Projektmanagements die kleinste betrachtete Aktivitätseinheit dar. Der typische Umfang eines Arbeitspakets liegt zwischen 1 und 10 Personentagen (PT). Auch wenn es im Einzelfall einmal noch kleinere oder größere Arbeitspakete geben kann, ist es sinnvoll sich in der genannten Bandbreite zu bewegen. Sehr kleine Arbeitspakete (< 1 PT) sollten zusammengefasst werden, um den Planungs- und Verwaltungsaufwand nicht unnötig in die Höhe zu treiben. Größere Pakete (> 10 PT) sollten aufgeteilt werden, damit eine regelmäßige Rückkopplung von der Ausführungsebene in die Projektmanagementebene sichergestellt ist. Jedes Projekt besteht aus einer Vielzahl von Arbeitspaketen. Viele können beliebig nacheinander oder nebeneinander ausgeführt werden. Andere müssen aufgrund von wechselseitigen Abhängigkeiten in einer bestimmten Reihenfolge abgearbeitet werden. Um die Komplexität eines Projekts mit seinen vielen Arbeitspaketen im Ablauf beherrschen zu können, ist es notwendig, die Arbeitspakete zu gruppieren. Mehrere Arbeitspakete, die funktionell oder zeitlich eng miteinander gekoppelt sind, werden deshalb auf der nächst höheren Gliederungsebene zu einer Einheit zusammengefasst. Für derartige Einheiten sind unterschiedliche Bezeichnungen im Gebrauch. In diesem Buch werden zusammengefasste Einheiten als Teilprojekt bezeichnet. Ein Teilprojekt besteht also aus mehreren Arbeitspaketen, die funktionell zusammengehören und meist auch zusammenhängend in einem bestimmten Zeitrahmen ausgeführt werden. Beispiel 4.7 Fallbeispiel „Maschinenterminal“: Typische Teilprojekte

Im Projekt zur Entwicklung des Maschinenterminals, das aus einem Gehäuse, mehreren elektrischen Baugruppen und einem Programm besteht, können verschiedene Teilprojekte gebildet werden. Aus produktorientierter Sicht kann man Arbeitspakete, die zu einem bestimmten Produktteil gehören, zu einem Teilprojekt zusammenfassen. Das Teilprojekt „Gehäuse“ könnte dann aus den Arbeitspaketen Grobentwurf, Detailkonstruktion, Musteraufbau, Redesign und Nullserienherstellung bestehen. Das Teilprojekt „CPU-Platine“ würde aus den Arbeitspaketen Schaltplanerstellung, Probeaufbau, Test, PCB-Layout, Fertigung der Platinen, Bestückung, Test der Baugruppe und Dokumentation bestehen. Genau so gut könnte man die Bildung von Teilprojekten auch ablauforientiert vornehmen. Hier würde z. B. aus allen Entwurfsarbeiten, wie Gehäuseentwurf, Schaltungsentwurf und Programmentwurf das Teilprojekt „Entwurf“ gebildet. Alle Testarbeiten, wie z. B. Musteraufbau des Gehäuses, Test der CPU-Platine, Test der IOPlatine, Funktionstest der Software-Module, Integrationstest und Systemtest könnten zum Teilprojekt „Test“ zusammengefasst werden. J Auch ein Teilprojekt muss einen klaren Start- und Endtermin besitzen und es muss ein nachprüfbares Ergebnis liefern. Im Gegensatz zu einem Arbeitspaket erfordert ein Teilprojekt nicht nur beim Start und am Ende, sondern auch während seiner Durchführung

4.2 Ablauforganisation

109

Tab. 4.3 Gliederung von Projekten unterschiedlicher Größe auf mehreren Ebenen Projektgröße 50 . . . 500 PJ 5 . . . 50 PJ 0,5 . . . 5 PJ 0,5 . . . 5 PM 1 . . . 10 PT

Untergliederung Groß-Projekt Teilprojekte Teilprojekte Teilprojekte Arbeitspakete

Mittleres Projekt Teilprojekte Teilprojekte Arbeitspakete

Kleines Projekt Teilprojekte Arbeitspakete

Projektmanagement-Aktivitäten. Da in der Regel mehrere Personen beteiligt sind, muss das Teilprojekt vorher geplant, während der Durchführung überwacht und bei Planabweichungen gesteuert werden. Ein Teilprojekt, das aus einzelnen Arbeitspaketen zusammengesetzt ist, besitzt in der Regel einen Arbeitsumfang von etwa 0,5 bis 5 Personenmonaten (PM). Es enthält also durchschnittlich etwa 10 Arbeitspakete. Je nach Projektgröße können die aus Arbeitspaketen gebildeten Teilprojekte auf der nächsten Gliederungsebene zu einem größeren Teilprojekt zusammengefasst werden. Bei noch größeren Projekten können auch diese wiederum zusammengefasst werden, bevor man auf der Ebene eines (Gesamt-)Projekts landet (Tab. 4.3).

4.2.2

Phasen und Meilensteine

Neben der statischen Strukturierung eines Projekts in Teilprojekte und Arbeitspakete ist auch der Ablauf in Form von Prozessen von großem Interesse. Verschiedene Teilprojekte oder Arbeitspakete müssen nicht immer getrennt und nacheinander ausgeführt werden. Zur Verkürzung der Durchlaufzeit ist es oft sinnvoll, Arbeitspakete oder Teilprojekte auch parallel zu bearbeiten. Ein typischer Projektablauf besteht daher sowohl aus sequentiell gekoppelten als auch aus parallelen Prozessen. Jeder Prozess besitzt im Plan mindestens einen Start- und einen Endtermin, oft auch noch Zwischentermine, die bei der Projektsteuerung überwacht werden können. Trotzdem ist es notwendig, im Projekt übergeordnete Termine zu definieren, an denen wichtige Projektphasen abgeschlossen werden. Derartige Termine werden allgemein als Meilensteine bezeichnet. Sie grenzen einzelne Phasen eines Projekts voneinander ab. Zwischen zwei Meilensteinen liegt also jeweils eine Projektphase. Projektphasen können mit Teilprojekten identisch sein. In diesem Fall laufen die Teilprojekte ebenfalls sequentiell ab. Um die Laufzeit eines Projekts möglichst kurz zu halten, ist es aber oft sinnvoll, Teilprojekte auch parallel ablaufen zu lassen. In diesem Fall bilden mehrere nacheinander oder nebeneinander ablaufende Teilprojekte eine Projektphase. Durch die Kombination rein sequentieller Projektphasen und paralleler oder sequentieller Teilprojekte werden die beiden Ziele der klaren Projektorganisation mit den praktischen Zielen kurzer Projektlaufzeiten miteinander in Einklang gebracht.

110

4

Projektorganisation

Arbeitspakete (im Teilprojekt) Projektphasen

I

II

III

IV

Teilprojekte

Meilensteine

Abb. 4.9 Arbeitspakete, Teilprojekte und Projektphasen

I

Eine Projektphase ist ein zeitlich abgegrenzter Teil eines Projekts. Sie kann ein oder mehrere Teilprojekte umfassen. Anfangs- und Endzeitpunkt einer Projektphase stellen Meilensteine dar. Ein Meilenstein ist erreicht, wenn alle Ergebnisse der vorangehenden Projektphase vorliegen.

Jede Projektphase muss abgeschlossen sein, bevor die nächste beginnen kann (Abb. 4.9). Durch diese saubere Schnittstelle zwischen zwei Projektphasen gewinnt man Ordnung und Planungssicherheit. Das Ergebnis eines Projekts kann dadurch nicht erst am Ende – positiv oder negativ – festgestellt werden, sondern bereits in frühen Phasen sind Zwischenergebnisse überprüfbar. Das Erreichen eines Meilensteins erlaubt einen Vergleich der bis dahin geleisteten Arbeit mit dem Plan. Auf eventuell aufgetretene Abweichungen zwischen Plan und Realität kann und muss hier mit grundlegenden Entscheidungen reagiert werden. 4mmKann eine Projektphase nicht wie geplant abgeschlossen werden, macht es keinen Sinn, mit der nächsten Projektphase zu beginnen. Eine mögliche Reaktion ist z. B. die Verlängerung der Projektphase mit einem neuen Zieltermin. Dadurch verschieben sich nachfolgende Phasen und auch der Endtermin des Projekts, falls die verlorene Zeit nicht wieder hereingeholt werden kann. Bei noch gravierenderen Problemen kann auch der Abbruch des Projekts eine notwendige Reaktion auf das Überschreiten eines Meilensteins sein. So unangenehm derartige Entscheidungen auch sind, je länger sie aufgeschoben werden, desto unangenehmer werden die Konsequenzen. 4mmOhne die Trennung der Projektphasen durch Meilensteine werden notwendige Überprüfungen und Entscheidungen oft immer wieder aufgeschoben. Typische Auswirkungen sind das lautlose Versickern, das ewige Dahinplätschern oder das ergebnislose Beenden von Arbeitspaketen und Teilprojekten. Ein solches Verhalten im Projekt führt zumindest zu drastischen Terminüberschreitungen, viel zu oft aber auch zu gescheiterten Projekten. Beispiel 4.8 Leistungsphasen nach HOAI

Die Baubranche besitzt umfangreiche und lange zurück reichende Erfahrungen mit der Strukturierung und Planung von Projekten, so dass es hier seit langem eine Standard-

4.2 Ablauforganisation

111

Tab. 4.4 Leistungsphasen nach HOAI Nr. 1. 2 3 4 5 6 7 8 9

Phase Grundlagenermittlung Vorplanung Entwurfsplanung Genehmigungsplanung Ausführungsplanung Vorbereitung der Vergabe Mitwirkung bei der Vergabe Objektüberwachung Dokumentation

Aufwand (in %) 3 7 11 6 25 10 4 31 3

Ablaufstruktur gibt. Sie wird durch die Honorarordnung für Architekten und Ingenieure (HOAI) in 9 aufeinander folgende Leistungsphasen unterteilt [Schneider 2008]. In der Grundlagenermittlung werden die Vorstellungen der Bauherren und der IstZustand erfasst. Daran schließen sich drei Entwurfsphasen an. In der Vorplanung erfolgen die Analyse der Aufgabe, die Erarbeitung eines Konzepts und eine Kostenschätzung. Die Entwurfsplanung umfasst eine detaillierte Planung des Projektgegenstands und eine darauf basierende Kostenrechnung. In der Genehmigungsplanung werden alle Fragen, die für den Bauantrag relevant sind, geklärt und die entsprechenden Unterlagen erstellt. In den beiden nächsten Leistungsphasen geht es um die Vergabe des Auftrags. Zunächst bereiten Architekten oder Ingenieure die Vergabe vor und wirken in der nächsten Phase an der Vergabe und der Erstellung eines Kostenvoranschlags mit (Tab. 4.4). Die eigentliche Bauausführung beginnt in Phase 8. Hier übernehmen Architekten oder Ingenieure die Bauleitung. Der Gesamtablauf wird durch die Dokumentationsphase abgeschlossen. Zusätzlich zur Phaseneinteilung macht die HOAI auch Aussagen über den Anteil des Arbeitsaufwands, der in den 9 Leistungsphasen erfahrungsgemäß anfällt. J

4.2.3 Standard-Ablaufstrukturen Die vielen Arbeitspakete eines Projektes können zum Teil beliebig nebeneinander oder nacheinander ausgeführt werden. Zwischen manchen Arbeiten bestehen aber Abhängigkeiten, so dass sie parallel bzw. sequentiell ausgeführt werden müssen. Ob eine Arbeit so früh wie nötig, so spät wie möglich oder mit einem zeitlichen Puffer eingeplant wird, hängt teilweise von den Projektzielen ab. Daher könnte man erwarten, dass jedes Projekt eine individuelle, einzigartige Ablaufstruktur aufweist. Bei sehr detaillierter Betrachtung ist dies auch der Fall.

112

4

Projektorganisation

Andererseits findet man in Projekten oft gleichartige Arbeitspakete, Teilprojekte und Projektphasen. Es ist daher sinnvoll, Ablaufstrukturen, die sich in vielen Projekten bewährt haben, als Standard zu definieren. Ausgangspunkt hierfür ist die Betrachtung eines Projekts als ein Problemlösungsprozess. Die systematische Lösung von Problemen, auch wenn diese sehr unterschiedlich sein können, erfolgt in abstrahierter Sicht immer wieder in mehreren Prozessen, die in gleicher Weise aufeinander folgen. Sowohl in der Theorie als auch in der praktischen Anwendung gibt es mehrere Modelle, die sich in der Anzahl und in der Bezeichnung der Prozesse unterscheiden. Hier wird ein Modell mit den vier aufeinander folgenden Prozessen Problemanalyse – Lösungsentwurf – Realisierung – Validierung verwendet. Die Problemlösung beginnt mit einer Problemanalyse. Deren Input bildet die Problembeschreibung. In der Analyse wird das Problem detailliert untersucht, die Problemdimensionen werden ermittelt, Ist-Zustand und Ziel-Zustand werden bestimmt sowie die Randbedingungen und zu optimierenden Kriterien formuliert. Während die von außen kommende Problembeschreibung teilweise unspezifisch, lückenhaft oder in sich widersprüchlich sein kann, sollte die aus der Analyse herauskommende Aufgabenbeschreibung möglichst konkret, vollständig und widerspruchsfrei sein. Die Aufgabenbeschreibung wird dann im nächsten Schritt, dem Entwurf, verwendet. Sinnvoll ist es hier, sich nicht von vorneherein auf eine einzige Lösung zu konzentrieren, sondern mehrere mögliche Lösungen zu suchen, diese bis zu einem gewissen Grad auszuarbeiten, Vor- und Nachteile gegenüber zu stellen und sich dann für eine Lösung zu entscheiden. Die ausgewählte, den meisten Erfolg versprechende Lösung wird dann detailliert als Plan ausgearbeitet. Die Lösungspläne bilden die Grundlage für die nun folgende Realisierungsphase. Hier wird der Plan in eine reale Lösung umgesetzt. Im letzten Schritt, der Validierung, wird die Qualität der Lösung überprüft. Hier wird untersucht, ob die erreichte Realisierung tatsächlich eine Lösung des Problems darstellt, ob die vorgegebenen Randbedingungen eingehalten und das Gütekriterium tatsächlich optimiert wurde. Jeder der vier Lösungsschritte stellt ein eigenes Teilprojekt dar. Im Idealfall muss jedes Teilprojekt abgeschlossen sein, bevor das nächste beginnen kann. Somit bildet jedes Teilprojekt eine eigene Projektphase. Der Output des einen Teilprojekts bildet den Input für das nächste. Stellt man die Teilprojekte sowie deren Input und Output kaskadenförmig, nacheinander dar (Abb. 4.10), so erinnert dies an einen Wasserfall. Daher hat sich für diese Art des Ablaufs die Bezeichnung „Wasserfallmodell“ etabliert, wobei in der Literatur mit einer unterschiedlichen Zahl von Teilprojekten und Projektphasen gearbeitet wird. Innerhalb eines Teilprojekts und damit auch innerhalb einer Phase laufen auch beim Wasserfallmodell Arbeiten parallel ab. Durch die saubere Trennung der einzelnen Teile und Phasen eines Projekts besitzt das Wasserfallmodell einen sehr einfachen und klaren Aufbau, der sich daher auch gut für die Projektkontrolle eignet. Allerdings kann das Modell in der Realität nur selten in Reinform umgesetzt werden. Die Analyse eines Problems kann z. B. nicht immer vollständig abgeschlossen werden, bevor mit dem Lösungsentwurf begonnen wird. Oft treten beim Versuch, eine Lösung zu erarbeiten neue, bisher unberücksichtigte Probleme auf, so dass

4.2 Ablauforganisation

Problem

113

Analyse Aufgabe Entwurf Plan Realisierung Lösung Validierung I

II

III

IV

val. Lösung Zeit

Abb. 4.10 In Phasen gegliederte Standard-Ablaufstruktur („Wasserfallmodell“)

eine erneute Analyse notwendig wird. Auch ein Lösungsentwurf kann meistens nicht vollständig „trocken, auf Papier“ erfolgen, sondern Realisierungsmöglichkeiten müssen oft ausprobiert werden, um eine größere Sicherheit für die Realisierbarkeit zu erlangen. Aus diesen Gründen gibt es in der Praxis viele Abwandlungen der rein sequentiellen Ablaufstruktur des Wasserfallmodells. Der Preis für die Einfachheit und Klarheit des Wasserfallmodells ist die hohe Durchlaufzeit. Ein neues Teilprojekt und damit auch eine neue Projektphase wird erst begonnen, wenn die vorangehende beendet ist. Die Reduzierung der Durchlaufzeit kann erreicht werden, wenn die Prozesse nicht nacheinander sondern gleichzeitig, nebeneinander laufen. Dies ist der Kerngedanke des so genannten Simultaneous Engineering [Ribbens 2000; Dixius 1999], das oft auch als Concurrent Engineering [Bullinger 1995] oder als Integrierte Produktentwicklung [Ehrenspiel 2006] bezeichnet wird. In der Herleitung dieses Modells wird die sequentielle Arbeitsweise des Wasserfallmodells, bei dem die Ergebnisse einer Projektphase ohne Rückkopplung an die nächste fließen („over the wall“-Engineering) als Ursache vieler Probleme im Projekt erkannt. Beim simultanen Vorgehen werden die Arbeiten so weit wie möglich parallelisiert. Eine vollständige Parallelisierung ist kaum möglich, daher gibt es einen gewissen zeitlichen Versatz, der allerdings möglichst klein gehalten werden soll (Abb. 4.11). Liegen die ersten Ergebnisse aus der Analyse vor, wird bereits mit dem Entwurf begonnen. Genau so beginnen Realisierung und Validierung schon, sobald erste greifbare Resultate der davor liegenden Prozesse verfügbar sind. Diese Vorgehensweise erfordert natürlich eine ganz andere Denkweise, weshalb die Einführung einer simultanen Arbeitsweise auch gravierende organisatorische Änderungen voraussetzt. Da es keine abgrenzbaren Projektphasen mehr gibt, ist ein deutlicher höherer Informationsaustausch zwischen den einzelnen Arbeitspaketen erforderlich.

114

4

Problem

Projektorganisation

Analyse Aufgabe Entwurf Plan Realisierung Lösung Validierung

val. Lösung Zeit

Abb. 4.11 Ablauf mit Simultaneous Engineering

Ein simultanes Ausführen der Arbeiten erhöht natürlich das Risiko. Frühe Fehler, die nicht sofort bemerkt werden, sind schon in viele Arbeiten eingeflossen. Im schlimmsten Fall sind diese Arbeiten vergebens. Im weniger schlimmen Fall erfordert die Beseitigung der Fehler einen zusätzlichen Aufwand. Der Lohn für das erhöhte Risiko ist aber eine Reduzierung der Durchlaufzeit. Beispiel 4.9 Projektplan mit sequentieller und paralleler Bearbeitung

Gegeben sei ein kleines Projekt mit den Phasen Analyse, Entwurf, Realisierung und Validierung. Jede dieser 4 Phasen wird noch einmal in Grob- und Fein-Phase unterteilt. In den Grob-Phasen (GA, GE, GR, GV) werden die für den Projekterfolg kritischen Fragen behandelt. Die fein-Phasen (FA, FE, FR, FV) haben die unkritischen Fleiß-Arbeiten zum Gegenstand. Man erhält somit 8 (kleine) Phasen. Die Durchlaufzeit beträgt hier 63 Arbeitstage (Abb. 4.12). Der laufzeitverkürzende Effekt von simultanem Engineering wird durch zwei Maßnahmen erreicht. Erstens werden die kritischen Arbeiten jeder Phase zuerst ausgeführt und danach die weniger kritischen. Außerdem wird mit den weniger kritischen Arbeiten bereits begonnen, bevor die kritischen Arbeiten der Folgephasen abgeschlossen sind. Die Durchlaufzeit kann dadurch auf 44 Tage reduziert werden. J Beispiel 4.10 Fallbeispiel „Maschinenterminal“: Simultaneous Engineering

Die Entwicklung des neuen Maschinenterminals sollte aufgrund auslaufender Verträge mit den bisherigen Zulieferern bis zur Serienreife in maximal 8 Monaten entwickelt werden. Es war klar, dass dies nur durch massive Parallelisierung der Arbeiten zu erreichen war.

4.2 Ablauforganisation

115

Abb. 4.12 Screenshot eines Projektplans mit sequentieller und parallelisierter Ausführung

Um eine weit gehende Parallelisierung der Arbeiten zu erreichen, wurden zunächst eine Grob-Analyse der Anforderungen und ein Grob-Entwurf des Terminals durchgeführt. Hierbei wurden die wichtigsten Entwurfsentscheidungen, so getroffen, dass sie einerseits möglichst konkrete Vorgaben für die nachfolgenden Arbeiten ermöglichen, andererseits aber gewisse Spielräume für die noch nicht berücksichtigte Detail-Anforderungen lassen. Als Hardwarebasis wurde die x86-Prozessorreihe mit einem freien DOS-Betriebssystem gewählt, da dieses für alle benötigten Schnittstellen entsprechende Treiber zur Verfügung stellt. Ein Multitasking- oder Echtzeit-Betriebssystem war wegen der nicht benötigten Grafik-Schnittstelle und der nicht benötigten Echtzeitanforderungen nicht erforderlich (Abb. 4.13). Zur Verkürzung der Entwicklungszeit sollten am Markt verfügbare eingebettete Single-Board CPU-Module im PC/104-Format verwendet werden. Alle anwendungsspezifischen Teile (Anschlüsse für Lesegeräte, Relaisausgänge, Anschluss für Tastatur und Display) sollten auf einem zu entwickelnden Basis-Board realisiert werden. Als Gehäuse sollte ein am Markt verfügbares Kunststoffgehäuse verwendet werden. In diesem sollte neben der Elektronik die zu entwerfende Folientastatur, das Display, ein Durchzugleser und die externen Steckanschlüsse untergebracht werden. Der benötigte Platz für die Elektronik wurde mit 18  25  5 cm3 abgeschätzt. Die Stromversorgung sollte mit einem externen Steckernetzteil erfolgen. Wegen der Verwendung einer standardisierter Hardware- und Betriebssystem-Plattform konnte die SoftwareEntwicklung sofort beginnen und auf einem Standard-PC durchgeführt und getestet werden.

116

4

Projektorganisation

Abb. 4.13 Projektplan Maschinenterminal M4

Durch die Festlegung der wesentlichen Entwurfsentscheidungen während des GrobEntwurfs konnte anschließend parallel mit den mechanischen Arbeiten (Gehäuse, Einbaugeräte, Tastatur, Stecker, Auswahl von Zubehör wie Magnetkarten-Durchzugleser, Barcode-Durchzugleser, Barcode-Lesestift) mit den elektrischen Arbeiten (Schaltungsentwurf, Layout, Test) und den Software-Arbeiten (Festlegung der Protokolle, Festlegung der Datensicherung, Benutzerdialog, Programmierung, Test) begonnen werden. J

4.2.4

Varianten von Ablaufstrukturen

Der rein sequentielle Projektablauf, wie er im Wasserfallmodell verwirklicht ist und der extrem parallele Ablauf des Simultaneous Engineering stellen die beiden Grundformen für die Ablauforganisation dar. Die parallele Vorgehensweise führt zu einer minimalen Projektlaufzeit, allerdings auf Kosten höheren Aufwands. Die sequentielle Arbeitsweise ist einfacher anzuwenden, hat aber längere Laufzeiten zur Folge.

4.2 Ablauforganisation

117

In der Praxis existieren zahlreiche weitere Ablaufmodelle. Die sequentielle Bearbeitung geht davon aus, dass der jeweilige Prozess Analyse, Entwurf, Realisierung und Validierung vollständig abgearbeitet sein muss, bevor der nächste beginnen kann. Dieser Ansatz basiert auf dem Gedanken, dass die Arbeitsergebnisse eine untrennbare Einheit darstellen. Dies muss aber nicht immer so sein. Viele Produkte und Dienstleistungen, die in einem Projekt realisiert werden, lassen sich unterteilen. Typische Muster für derartige Unterteilungen sind das Komponentenmodell, das Schichtenmodell und das Prototypenmodell. Beim Komponentenmodell wird das Projektergebnis – das Produkt – in mehrere gleichwertige Module zerlegt. Diese können unabhängig voneinander realisiert und am Ende zum Gesamtergebnis zusammengesetzt werden. Das Komponentenmodell findet man heute in sehr vielen Bereichen, wie z. B. bei der Herstellung von Autos, bei denen viele Fahrzeuge aus einem Modulbaukasten aufgebaut werden. Beim Schichtenmodell besteht das Projektergebnis aus mehreren, aufeinander aufbauenden Schichten. Jede Schicht greift auf Funktionen der darunter liegenden Schicht zurück und stellt selbst Funktionen für die darüber liegende Schicht zurück. Diese Art der Produktstrukturierung wird z. B. bei der Softwareerstellung, beim Aufbau von Kommunikationssystemen und bei Rechnersystemen vielfach angewendet. Unter einem Prototyp versteht man eine einfache Objekt-Realisierung, die nur einen bestimmten, in der Regel besonders wichtigen Aspekt eines Objekts realisiert und viele andere Details weglässt. Das Prototypenmodell unterteilt das Projektergebnis daher in mehrere Konkretisierungsstufen, die bei einem groben, abstrakten Prototyp beginnen und diesen schrittweise verfeinern und konkretisieren. Die Gliederung des Projektergebnisses in mehrere Teile, eröffnet die Möglichkeit, das Projekt iterativ zu durchlaufen und in jeder Iteration ein Teilergebnis zu realisieren. Jedes der genannten Produktmodelle eignet sich für iterative Projektdurchläufe. Eine Iteration erzeugt dann entsprechend eine Komponente, eine Schicht oder einen Prototyp. Je nach Abhängigkeit der Einzelergebnisse sind mehr oder weniger starke Überlappungen der einzelnen Iterationen möglich. Durch die Aufteilung der 4 Prozesse ergeben sich zusätzliche Freiheitsgrade bei der Organisation des Projektablaufs in iterativer Form (Abb. 4.14). Im einfachsten Fall laufen sowohl die Iterationen als auch die Teilprozesse rein sequentiell ab (iss). Die Projektdurchlaufzeit wird zwar dadurch nicht verringert, aber es liegen viel früher bereits überprüfbare Teilergebnisse vor. Der Projektfortschritt ist dadurch besser zu kontrollieren. Außerdem werden Fehler früher festgestellt und verursachen dadurch geringere Kosten. Ein typisches Beispiel für diese Ablaufform ist das so genannte Spiralmodell, das später ausführlich behandelt wird. Wenn innerhalb einer Iteration die Teilprozesse parallelisiert werden, die Iterationen aber weiterhin sequentiell ablaufen, erhält man eine Ablaufstruktur wie sie z. B. beim agilen Projektmanagement der Scrum-Methodik verwendet wird (ips). Man erreicht eine deutliche Verkürzung der Laufzeit und kann die Komplexität trotzdem überschaubar halten, da es weiterhin abgegrenzte Projektphasen gibt. Dies ist bei der nächsten Struk-

118

4 einmaliger Durchlauf

iterative Durchläufe z.B. Spiralmodell

z.B. Wasserfallmodell

An

Projektorganisation

En Re

sequentiell

Va

iss z.B. Scrum

Projektablauf

ips

isp z.B. Simultaneous Engineering

An En Re

parallel

ipp

Va

Projektergebnis Einheit

Komponenten

Schichten Prototypen

Abb. 4.14 Modelle für Projekt-Ablaufstrukturen

tur nicht mehr der Fall. Hier wird zwar innerhalb jeder Iteration sequentiell gearbeitet, aber die Iterationen überlappen sich (isp). Die kürzeste Durchlaufzeit wird bei doppelter Parallelisierung erreicht: sowohl die Teilprozesse innerhalb einer Iteration, als auch die Iterationen selbst laufen überlappend ab (ipp). Das Prototypenmodell erfordert in der Regel eine sequentielle Abarbeitung der Iterationen. In den einzelnen Iterationen entstehen Projektergebnisse mit zunehmendem Konkretisierungsgrad. In der ersten Iteration werden die Prozesse Analyse, Entwurf, Realisierung und Validierung relativ schnell und grob durchlaufen. Das Ergebnis ist ein Prototyp, der nur die wichtigsten Merkmale des angestrebten Ergebnisses zeigt. Beispiele hierfür findet man in allen Bereichen: als einfache, verkleinerte Modelle („Holzmodelle“) in der Architektur oder im Maschinebau, als Platinen mit „fliegender Verdrahtung“ in der Elektronik oder als Software, die nur die Benutzerinteraktion ohne weitergehende Verarbeitungsfunktionen realisiert. In darauf folgenden Iterationen können weitere, konkretere Prototypen aufgebaut werden, bis man schließlich im letzten Schritt beim vollständigen Projektergebnis angelangt. Die Zahl der Iterationen kann dabei je nach Projekt variieren. In der Regel werden 2 oder 3 Iterationen genügen. Beispiel 4.11 DeLorean DMC-12

Anfang der 70er Jahre hatte John DeLorean die Idee, ein Fahrzeug zu entwickeln, das den höchsten zu dieser Zeit bekannten Sicherheitsstandards genügen und dabei aber ein sportliches Aussehen haben sollte. Trotz vieler Probleme konnte das Auto als Ergebnis

4.2 Ablauforganisation

119

1. Iteration 2. Iteration

3. Iteration

Konzept

1. DMC-Prot. 2. DMC-Prot. Lotus-Prot. Pre-Prod.-Car

Red Rocket

4. Iteration

5. Iteration

6. Iteration Serienprod.

Holzmodell

1/74

1/75

10/75

12/77

7/78

12/79

10/80

Abb. 4.15 Projektplan DeLorean DMC12

eines fast 7 Jahre dauernden Entwicklungsprojekts in Serie produziert werden. Das Projekt wurde in mehreren Iterationen entwickelt (Abb. 4.15). In einem ersten Durchlauf wurden die Ideen gesammelt und ein Grundkonzept entworfen. Wichtige Fragen zum Antriebskonzept wurden anhand des „Red Rocket“ genannten Versuchsfahrzeugs geklärt, das aus verfügbarer Teilen aufgebaut wurde (u. a. ein Fiat X1/9, ein Motor von Ford und ein Getriebe von Borg Warner). Parallel dazu wurde ein Holzmodell im Maßstab 1:1 als Design-Studie hergestellt. In der nächsten Projektiteration entstand ein erster DMC-12-Prototyp mit einem Motor von Citroen, der sich aber als zu schwach heraus stellte. Im zweiten Prototyp wurde das Konzept des Mittelmotors zugunsten eines Heckantriebs aufgegeben. Für die Weiterentwicklung zur Serienreife wurde eine Verbindung mit Lotus eingegangen. Dabei wurden viele der ursprünglichen Ideen über Bord geworfen und auch der Chefentwickler von DeLorean warf wegen gravierender Dissonanzen mit Lotus das Handtuch. In der letzten Iteration wurde schließlich ein Pre-Production-Car entwickelt, womit das Projekt nach 6 Iterationen erfolgreich abgeschlossen wurde. Anzumerken bleibt noch, dass insgesamt 8583 Fahrzeuge in Serie hergestellt wurden. Aufgrund von Qualitätsmängeln in der Serienproduktion und daraus resultierender finanzieller Probleme musste die Firma nach nur 2 Jahren ihre Geschäftstätigkeit beenden. (Eine interessante, detaillierte Beschreibung mit Photos ist zu finden auf [DeLorean.de].) J Der Vorteil des Prototypenmodells besteht darin, dass die kritischen Fragen bezüglich des Projektgegenstands als erstes überprüft werden, bevor Aufwand in die Detailarbeit gesteckt wird. Sind in der Aufgabenstellung oder im gewählten groben Lösungsgedanken grundlegende Fehler enthalten, so fallen diese schon sehr früh auf. Die Fehler können dann mit überschaubarem Aufwand behoben werden. Falls erforderlich kann das Projekt auch in einer frühen Phase abgebrochen werden, wodurch der Schaden immerhin begrenzt bleibt. In der Literatur ist diese Form der Ablauforganisation auch als Spiralmodell bekannt [Boehm 1988]. Der Ursprung dieses Namens wird anschaulich klar, wenn man den Ablauf nicht linear über einer Zeitachse aufträgt, sondern in einem Ursprung beginnend spiralförmig nach außen. Dabei stellt jede Umdrehung einen vollständigen Teilablauf dar.

120

4

Projektorganisation

Abb. 4.16 Iterativer Ablauf mit einem Prototyp als Zwischenergebnis

Das Spiralmodell (Abb. 4.16) nutzt eine auf dem Pareto-Prinzip basierende Erkenntnis aus vielen praktischen Projekten: In jedem Teilprojekt und jeder Projektphase gibt es wichtige Arbeiten mit weit reichenden Konsequenzen und weniger kritische FleißArbeiten. Die Entwurfsentscheidungen in den frühen Projektphasen führen zu einer weitgehenden Festlegung des Aufwands für die folgenden Arbeiten. Außerdem haben Fehler, die in solchen Arbeiten gemacht und erst in späten Projektphasen bemerkt werden, viele verlorene Arbeiten und somit erhöhten Aufwand zur Folge. Führt man einen vollständigen Zyklus zuerst für die kritischen Arbeiten durch und erst anschließend die Fleiß-Arbeiten, kann man das Fehlerrisiko reduzieren. Da beim Spiralmodell nur die Reihenfolge der Arbeiten geändert wird, diese aber nach wie vor sequentiell ausgeführt werden, ändert sich die Projektlaufzeit nicht. Tab. 4.5 fasst die wesentlichen Merkmale der bekannten Ablaufmodelle zusammen. Die beschriebenen Modelle des Projektablaufs stellen Grundformen dar, die nicht immer in Reinform auftreten. Je nach Anforderungen können die verschiedenen Strukturmerkmale miteinander kombiniert werden. So ist es z. B. möglich, die Analyse eines Problems und die Suche nach möglichen Lösungen sequentiell auszuführen, danach zwei oder drei mögliche Lösungen parallel durch konkurrierende Arbeitsgruppen ausarbeiten zu lassen und dann die ausgewählte Lösung so weit wie möglich parallel zu realisieren.

Tab. 4.5 Vergleich der Grundmodelle der Ablauforganisation Kriterium Ablauf Phasentrennung Durchlaufzeit Feststellung von Fehlern Aufwand f. Planung . . . . . . und Kommunikation

Wasserfallmodell sequentiell ausgeprägt lang spät gering

Spiralmodell iterativ schwächer lang früher mittel

Scrum iterativ schwächer kürzer früher niedrig hoch

Simult. Eng. parallel fehlt kurz spät hoch

4.3 Organisation der Informationsflüsse

4.3

121

Organisation der Informationsflüsse

Im Laufe eines Projekts fallen sehr viele Informationen an, die von ganz unterschiedlicher Bedeutung sein können. Beispiel 4.12 Projektinformationen

„Wir haben den Auftrag für das Projekt erhalten.“ „Die Software ist so gut wie fertig.“ „Das Arbeitspaket muss bis zum 30.9. abgeschlossen werden.“ „Der Test des Prototyps ist erfolgreich abgeschlossen worden.“ „Wiesemann hat am Samstag ein Tor geschossen.“ „Die Projektbesprechung ist auf 9:30 Uhr vorverlegt worden.“ „Die Lieferung der CPU-Baugruppe wird sich um 4 Wochen verzögern.“ „Theisen hat sich beim Fußballspielen einen Kreuzbandriss zugezogen.“ „Wenn beim Test alles glatt geht, können wir den Terminplan noch einhalten.“ J Bei weitem nicht immer ist die Wichtigkeit oder Unwichtigkeit einer Information so offensichtlich wie in diesen einfachen Beispielen. Für ein Gelingen des Projekts ist es eine wichtige Voraussetzung, alle relevanten Informationen zu erfassen, zu speichern und den Projektbeteiligten zugänglich zu machen. Dies ist die Aufgabe des Informationsmanagements. Damit beim Entstehen von Information nicht immer individuell entschieden werden muss, was mit dieser Information gemacht wird, sollten die Regeln der Erfassung, Kommunikation und Speicherung von Informationen vor Projektbeginn festgelegt werden.

4.3.1 Information, Kommunikation, Dokumentation Von einer Information bzw. einem Informationsgewinn spricht man, wenn jemand Kenntnisse über den Wert eines Sachverhalts erlangt. Der Informationsgewinn ist umso größer, je seltener und unwahrscheinlicher ein Sachverhalt ist. Informationen können in sehr unterschiedlicher Form dargestellt und als Daten gespeichert werden. Dieser theoretische Informationsbegriff verwendet nur den Kenntnisstand des Informationsempfängers. Die Relevanz einer Information wird nicht berücksichtigt. Daher hat die Information „unsere Fußballmannschaft hat gewonnen“ und die Information „wir haben den Projektauftrag bekommen“ den gleichen Informationsgehalt, nämlich genau 1 Bit. Grundsätzlich könnte man natürlich argumentieren, dass in einem Projekt jede Information relevant sein kann und deshalb erfasst, kommuniziert und gespeichert werden muss. Die in den letzten Jahrzehnten rasant gestiegenen Möglichkeiten der Informationserfassung, der Kommunikation und der Datenspeicherung scheinen dies auch technisch möglich zu machen.

122

4

Projektorganisation

Dass es aber auch beim Umgang mit Informationen notwendig geworden ist, auf Effizienz zu achten, wird jeder bestätigen, der täglich in einer Flut von Anrufen, SMSNachrichten, E-Mails, Besprechungsnotizen, Berichten, Zeitungs- und Zeitschriftenartikeln zu ertrinken droht. Aus praktischer Sicht muss jede Information neben ihrem Gehalt auch auf ihre Relevanz überprüft werden. Als nächstes stellt sich die Frage, wie mit einer relevanten Information im Rahmen eines Projektes umzugehen ist. Neu entstehende Informationen, wie z. B. die Stornierung einer Lieferung per E-Mail, die telefonische Krankmeldung eines Mitarbeiters oder einer Entscheidung im Rahmen einer Projektbesprechung müssen an die richtigen Adressaten kommuniziert und eventuell gespeichert werden. Da der Umgang mit Informationen in einem Projekt einerseits nicht für jede Information einzeln festgelegt werden kann, andererseits auch nicht jedem Beteiligten frei gestellt werden kann, müssen im Rahmen der Projektorganisation Informationskategorien gebildet und allgemeingültige Regeln für jede Kategorie festgelegt werden. Informationsgewinn findet nur statt, wenn jemand von der Information Kenntnis erlangt. Daher bildet die Weitergabe der Informationen an die richtigen Empfänger – die Kommunikation – einen bedeutenden Bestandteil des Informationsmanagements. Die technischen Kommunikationsmöglichkeiten sind heute vielfältig, angefangen von Besprechungen, über Telefonate, Videokonferenzen, E-Mails, bis hin zu internetbasierten Diensten und Datenbanken. Wichtiger als die Frage des Kommunikationskanals ist der Ablauf für den Umgang mit Informationen. Bei einer eher unwichtigen Information kann es ausreichen, die Information selbst oder einen Hinweis auf ihre Ablage in einer Datenbank zu versenden, ohne weitere Aktivitäten zu veranlassen. Bei wichtigen Informationen genügt dies nicht. Hier sollte der Empfang durch eine Rückmeldung quittiert werden, um erstens sicher zu sein, dass die Information angekommen ist und um zweitens die Weitergabe dokumentiert zu haben. Neben derartigen Basisregeln, können die Kommunikationsabläufe im Rahmen der Projektorganisation noch viel detaillierter geregelt werden. Hierzu gehören z. B. Festlegung der zu informierenden Personen, Festlegungen über einzuhaltende Zeitfenster bei der Kommunikation. Beispiel 4.13 Informationskategorien

Die folgende Einteilung bildet 5 Informationskategorien, die sich nach ihrer Wichtigkeit bzw. Auswirkung auf das Projekt unterscheiden (Tab. 4.6). Für jede Kategorie muss festgelegt werden, wer zu informieren ist, wenn ein solches Informationsereignis eintritt und was zu tun ist. Mögliche Reaktionen reichen vom Weiterleiten der Information an die Betroffenen, über die Einberufung einer Projektsitzung bis zu einem Krisengespräch mit dem Auftraggeber. Denkbar ist auch, in der IMV-Matrix bei der Informationspflicht die Kategorie der Information (I1–I5) zu berücksichtigen. J Der dritte grundlegende Baustein des Informationsmanagements ist die Dokumentation, d. h. die dauerhafte Ablage der Informationen für einen späteren Zugriff. Ein

4.3 Organisation der Informationsflüsse

123

Tab. 4.6 Bildung von Informationskategorien Kat. I1 I2 I3 I4 I5

Art der Information Informationen, die den Erfolg des gesamten Projekts gefährden können Informationen, die eine Verzögerung oder Mehraufwand nach sich ziehen Informationen, die das gesamte Projektteam betreffen Informationen, die mehrere Projektbeteiligten betreffen Informationen, die nur einen Projektbeteiligte betreffen

Zu informieren: Auftraggeber + Projektleiter Auftraggeber + Projektleiter Projektleiter + gesamtes Team Projektleiter + alle Betroffenen Betroffener

Reaktion Krisensitzung mit Auftraggeber Projekt-interne Krisensitzung Auf regelmäßiger Projektsitzung behandeln Besprechung der Betroffenen Bearbeitung durch Betroffenen

Dokument ist eine formale und dauerhafte Zusammenfassung von Informationen. Dokumente können in Papierform (p-Dokument) oder in elektronischer Form (e-Dokument) vorgelegt werden. Inhaltlich können Texte, Grafiken, Listen und Tabellen unterschieden werden. Wird ein Dokument freigegeben bzw. veröffentlicht, darf es danach nicht mehr geändert werden. Damit notwendige Änderungen nachvollziehbar bleiben, müssen sie entweder über eine Versionierung oder über Änderungsmitteilungen gehandhabt werden. Bei der Versionierung erhält jedes geänderte Dokument eine neue Versionsnummer. In einer neuen Version des Dokuments können Informationsbausteine beibehalten, entfernt oder hinzugefügt werden. Versionsnummer können hierarchisch gegliedert werden (Beispiel: Lastenheft Version 1.3). Änderungsmitteilungen sind nur bei kleinen und wenigen Änderungen zu empfehlen, da sonst zu viele einzelne Änderungsmitteilungen anfallen und die Übersicht verloren geht. Größere und viele Änderungen sind übersichtlicher in Form versionierter Dokumente zu handhaben. Die neueste Dokumentenversion zeigt den aktuellen Stand im Zusammenhang, zurückliegende Versionen werden nur bei Betrachtung der Entstehungsgeschichte gebraucht.

4.3.2 Informationsmanagement Das Informationsmanagement hat sich in den letzten Jahrzehnten durch die Einführung der elektronischen Datenverarbeitung rasant gewandelt. Dieser Wandel ist bei weitem noch nicht abgeschlossen, sondern befindet sich möglicherweise noch in einer frühen Phase. Während vieler Jahrzehnte wurden Informationen ausschließlich in Papierform dokumentiert. Die Ablage erfolgt in Mappen, Ordnern, Regalen, Schränken etc. Die Suche nach Informationen war ein aufwändiges und nicht selten vergebliches Unterfangen. Durch die Einführung von Rechnern konnten Informationen auch in elektronischer Form erstellt, verteilt und gespeichert werden. Dadurch nahm der Informationsfluss so-

124

4

Projektorganisation

wohl in der Menge als auch in der Fließgeschwindigkeit deutlich zu, weshalb oft der Eindruck einer Informationsflut entsteht. Die systematische Ablage und das zielgerichtete Wiederfinden der Informationen konnten mit der Verbreitungsgeschwindigkeit nicht mithalten. Die Ablage der Daten erfolgte zunächst als elektronische Dokumente auf verschiedenen, persönlichen Rechnern. Das Wiederfinden der Dokumente hing sehr stark vom Einzelnen ab. Einen ersten Fortschritt brachte die Verbindung von Rechnern in Netzen. Die Ablage der Dokumente auf zentralen Netz-Laufwerken, ermöglichte jedem berechtigten Beteiligten Zugang zu den Dokumenten und sorgte für eine (oft bescheidene) Vereinheitlichung der Ablagesystematik. Die Zugriffsproblematik wurde durch Einführung von zentralen Dokumenten-Servern verbessert. Nicht nur in einem Projekt, sondern auch bei den vielen Routineaufgaben, die ohne Projekte in Unternehmen ausgeführt werden, fallen vielfältige Dokumente an. Aus diesem Grund hat sich das Dokumentenmanagement als eigenständige Aufgabe etabliert. Besitzt ein Unternehmen ein Dokumentenmanagementsystem (DMS), so können die im Projekt anfallenden Dokumente in diesem System gehandhabt werden. Dabei sind u. a. folgende Fragen zu beantworten:     

Wie und wo erfolgt die Ablage der Dokumente? Wer darf auf welche abgelegten Dokumente (lesend) zugreifen? Wie wird der Zugriff geschützt? Wie wird die Suche (nach abgelegten Dokumenten) unterstützt? Wie erfolgt die Sicherung (abgelegter Dokumente)?

Ein erster, einfacher Ansatz zur Beantwortung der Fragen könnte sein, alle Informationen als wichtig einzustufen, sie an alle Beteiligten zu kommunizieren und auch zu dokumentieren. Zwar würde man dadurch sicherstellen, dass keine Information verloren geht, aber zum einen wäre, aufgrund der Vielzahl anfallender Informationen der Aufwand enorm. Außerdem tritt bei den Beteiligten eine solche Informationsüberflutung ein, dass „vor lauter Bäumen der Wald nicht mehr gesehen wird“ oder einfacher gesagt, dass bei der Flut von Informationen die wichtigen übersehen werden. Man kommt also nicht umhin, zunächst die Wichtigkeit einer Information zu bewerten, dann die Projektbeteiligten zu identifizieren, die diese Information benötigen und schließlich, Art der Dokumentation und Ort der Dokumentenablage zu bestimmen.

4.3.3 Informationsmanagement im Projekt Jede Aktivität in einem Projekt besitzt Input und Output. Neben materiellem Input und Output sind Dokumente die wichtigsten Ein- und Ausgänge einer Aktivität. Daher muss für jede Projektaktivität festgelegt sein, welche Informationen und Dokumente als Eingang und als Ausgang zu einer Aktivität gehören. Entsprechend der zeitlichen

4.3 Organisation der Informationsflüsse

125

Abb. 4.17 Dokumentenarten in einem Projekt

Abfolge eines Projekts kann man folgende Dokumentenarten unterscheiden: Auftrags-, Organisations-, Planungs-, Steuerungs- und Abschlussdokumente (Abb. 4.17). Die Auflistung erhebt keinen Anspruch auf Vollständigkeit. Bei der Vielfalt der Projekte und Dokumente ist dies gar nicht möglich. Vielmehr soll die Auflistung als ein Grundvorrat benötigter Dokumente angesehen werden, der eine Überprüfung im konkreten Projekt ermöglicht und zur Erzeugung weiterer, benötigter Dokumente anregen soll. Daneben gibt es in jedem Projekt eine mehr oder weniger geordnete Sammlung von Daten, die während des Projekts anfallen. Hierzu zählen z. B. Notizen, E-Mails, Memoranden etc. Diese Daten können wichtige Informationen tragen, ohne dass sie adäquat dokumentiert sind. In Anlehnung an die dunkle Materie im Weltall, könnte man hier von dunkler Information sprechen: sie ist nicht sichtbar, aber aufgrund ihrer Schwerkraft immer wirksam. Alle Dokumente, die in einem Unternehmen und damit auch in einem Projekt erstellt werden, sollten gewisse Mindestanforderungen an einen einheitlichen formalen Aufbau und an den Inhalt erfüllen. Außerdem sollte jede Seite eines Dokuments in der Kopf- oder Fußzeile einheitliche Rahmendaten enthalten, wie Seitennummer, Dokumententitel und Datum. Folgende Informationen sollten zu den Dokumentenstammdaten gehören:      

Titel/Thema des Dokuments, Anlass/Zweck/Art des Dokuments, Angaben zum Verfasser, Verteiler (Lese-Verpflichtete, Lese-Berechtigte), Erstellungs-/Freigabe-Datum, Stichworte, die für das Suchen, Filtern und Sortieren verwendet werden können.

126

4

Projektorganisation

Alle Projektdokumente sollten darüber hinaus auch eine kurze Angabe der wichtigsten Projektstammdaten enthalten. Hierzu gehören: Projektbezeichnung, Projektidentifikation (Kürzel, Nummer), Projektleiter. Auf alle weiter gehenden Informationen zum Projekt kann dann über die Projektidentifikation zugegriffen werden. Zur Unterstützung eines einheitlichen Aufbaus und eines vollständigen Umfangs der Dokumente, sollte es eine entsprechende Vorlage geben. Außerdem sollte für jede spezielle Dokumentenart ein eigenes Formular erstellt und zum Bestandteil des Projekthandbuchs gemacht werden. Verschiedene Muster-Formulare sowie Hinweise zum Ausfüllen derartiger Formulare sind im Anhang zu finden. Im Rahmen eines Projekts fallen nicht nur eine ganze Menge von Informationen an, sondern auch sehr vielfältige Dokumententypen. Ohne Anspruch auf Vollständigkeit sollen hier exemplarisch einige wichtige Dokumententypen skizziert werden. Ein Logbuch stellt die einfachste Form der Dokumentation von stetig anfallenden Informationen dar. Ein Logbuch wird von einer Person geführt, die darin alle Gedanken, Ideen, Gespräche und auch deren Ausarbeitung enthält. Die Informationen werden in der zeitlichen Reihenfolge ihres Auftretens in ein gebundenes, fortlaufend nummeriertes Buch eingetragen. Wegen fehlender formaler Anforderungen sind Logbücher sehr einfach zu führen. Dies hat aber auch Nachteile. Hierzu zählen die fehlende Gliederung und eine aufwändige Suche nach bestimmten Stichworten. Trotz dieser Nachteile sind Logbücher aber immerhin besser als gar keine Dokumentation. Die Informationen sind festgehalten, nachträgliche Eintragungen sind nicht mehr möglich bzw. zumindest nicht erlaubt und Informationen können nicht entfernt werden (Seitenzahlen!). Sie eignen sich daher vorwiegend als individuelle Informationssammlungen der einzelnen Projektbeteiligten. Für die Projektdurchführung ist die To-Do-Liste eine sehr wichtige Dokumentenart. In ihr werden für eine Person, für eine Gruppe von Personen oder für alle Projektbeteiligten die auszuführenden Aufgaben in Form einer Liste oder Tabelle zusammengefasst. Jeder Eintrag enthält eine auszuführende Aufgabe, eine verantwortliche Person und einen Zieltermin. Weitere Angaben können den Erledigungsstatus (z. B. offen, in Arbeit, erledigt), den geplanten Beginn, den Aufwand oder die Priorität beschreiben. Eine vergleichbare Aufgabe und einen ähnlichen Aufbau hat eine „Liste offener Punkte“ (LOP). In ihr werden verschiedene kleinere Aufgaben gesammelt, die nicht als Arbeitspakete im Projektplan auftauchen. Auch hier gehören zu jeder Aufgabe eine verantwortliche Person, ein Termin und ein Status. Eine Notiz wird verfasst, wenn ein informationell relevantes Ereignis auftritt und die entstandenen Informationen nachvollziehbar weiter gegeben und dauerhaft gespeichert werden sollen. Hierbei kann es sich z. B. um eine Telefonnotiz, eine Aktennotiz oder eine Gesprächsnotiz handeln. Ein Bericht wird aus unterschiedlichen Anlässen verfasst. Ein Bericht wird immer anlässlich eines bestimmten Ereignisses verfasst. Er sollte nach der Erstellung bzw. Freigabe später nicht geändert werden können. Von einer Notiz unterscheidet sich ein Bericht nicht nur im Umfang, sondern es werden vor allem höhere formale Anforderungen gestellt. Jede Besprechung sollte z. B. in Form eines Berichts dokumentiert werden. Statusberichte wer-

4.3 Organisation der Informationsflüsse

127

den zu festgelegten Terminen verfasst, z. B. als Meilensteinreport nach Abschluss einer bestimmten Projektphase. Von besonderer Bedeutung ist natürlich der Projektabschlussbericht. Ein Besprechungsbericht sollte die wichtigen Inhalte einer Besprechung dokumentieren. Dies kann entweder als kurzes Ergebnisprotokoll oder ausführlicher als Wiedergabe der Diskussion und unterschiedlicher Standpunkte erfolgen. Typische Informationsarten sind Aufträge (wer, was, bis wann), Beschlüsse und Informationen. In einem Projekt sollte es keine Besprechung ohne einen Bericht geben. Statusberichte werden zu festgelegten Zeitpunkten (z. B. periodisch oder an Meilensteinen) verfasst. Sie fassen die Aktivitäten und Ergebnisse des abgelaufenen Zeitraums zusammen und machen Aussagen über den Projektstatus hinsichtlich Produkt, Aufwand, Kosten und Terminen. Checklisten sind standardisierte Listen für bestimmte Aktivitäten. Die Aktivitäten, die für eine bestimmte Aufgabe normalerweise benötigt werden, sind in der Checkliste gesammelt. Wird eine entsprechende Aufgabe bearbeitet, werden die einzelnen Punkte der Checkliste abgehakt. Checklisten stellen sicher, dass nichts vergessen wird. Die Standardisierung erleichtert die Übersicht bei verschiedenen Projekten und Beteiligten. Ein Nachteil entsteht, wenn eine Checkliste zu allgemeingültig angelegt wird. Sie wird dadurch umfangreich und enthält viele Punkte, die im Einzelfall nicht nötig sind. Eine Ressourcentabelle enthält alle für das Projekt benötigten und zur Verfügung stehenden Ressourcen mit ihren Ausstattungs- und Verfügbarkeitsmerkmalen. In einer Personaltabelle werden alle Personen aufgelistet, die am Projekt beteiligt sind (alle Stakeholder). Für die Personen kann es viele Attribute geben. Personaltabellen enthalten nur Informationen über einzelne Personen; Beziehungen zwischen verschiedenen Personen werden hier nicht beschrieben. Das Ergebnis der Analyse- und Entwurfsphase eines Projekts sind vielfältige Planungsdokumente. Hierzu gehören der Produktstrukturplan, der Projektstrukturplan, Testpläne, Ressourceneinsatzpläne, Personaleinsatzpläne, Kostenpläne. Die Pläne können in der Form von Tabellen bzw. Listen verfasst sein. Übersichtlicher sind graphische Darstellungen in Form von Netzplänen und Ablaufplänen. Beispiel 4.14 Fallbeispiel „CAD-Software“, Besprechungsbericht

Der Screenshot in Abb. 4.18 zeigt einen Besprechungsbericht, der mit Hilfe des Formulars aus dem Anhang erstellt wurde. Neben den grundlegenden Angaben, die in jedem Projektdokument enthalten sein sollten, sind im Bericht die wichtigen Ergebnisse der Besprechung festgehalten. Bei jedem Ergebnis wird kenntlich gemacht, ob es sich um eine Information (I), einen Beschluss (B) oder einen Auftrag (A) handelt. Bei allen Aufträgen muss die verantwortliche Person und ein Erledigungstermin angegeben werden. J

128

4

Projektorganisation

Abb. 4.18 Screenshot eines Besprechungsberichts

4.4 Das Projektmanagement-Handbuch Gemäß der Definition zu Beginn des Kapitels versteht man unter Projektorganisation die Schaffung von Regeln, durch die die Arbeit der Beteiligten auf die Projektziele ausgerichtet wird. Im Wesentlichen gehören hierzu die Regeln für die personellen Weisungsbefugnisse, die Regeln für den Ablauf der Arbeitsprozesse und die Regeln für die Informationsflüsse. Zur Vermeidung unnötiger Reibungsverluste während der Durchführung eines Projekts ist es wichtig, diese Regeln zu Projektbeginn zu definieren und dauerhaft einzuhalten. Projekte, bei denen es diese Regeln nicht gibt, führen früher oder später zu Problemen. Diese können sich sehr vielfältig äußern, wie z. B. in personellem Weisungswirrwarr zwischen Projekt- und Linien-Vorgesetzten, im Festfahren des Projekts in permanent sich wiederholenden Schleifen von Fehlern, Notlösungen und neuen Fehlern oder im vergeblichen Suchen nach nicht auffindbaren Dokumenten. Trotz sehr unterschiedlicher Erscheinungs-

4.4 Das Projektmanagement-Handbuch

129

formen, haben derartige Probleme fast immer eine systematische Ursache: mangelnde Projektorganisation. Immer wieder werden bestimmte Erklärungen für fehlende oder lückenhafte organisatorische Festlegungen in Projekten herangezogen, wie z. B. „Zeitdruck“, „zu viel Aufwand“ oder „unnötiger Formalismus“. Angesichts der vielen Nachteile sind diese Ausreden aber nicht akzeptabel. Außerdem lassen sich die Erklärungen mit Hilfe eines Projekthandbuchs entkräften. Werden in einem Unternehmen, das in einer bestimmten Branche und in einem bestimmten Marktsegment tätig ist, öfter Projekte durchgeführt, so ist es wahrscheinlich, dass die Projekte, auch wenn sie sich fachlich voneinander unterscheiden können, viele organisatorische Gemeinsamkeiten aufweisen. Es ist daher sinnvoll, die Regeln der Projektorganisation für eine ganze Reihe von Projekten, eventuell sogar für alle Projekte des Unternehmens einheitlich festzulegen. Sie können dann in Form eines Handbuchs dokumentiert werden. Laut DIN 69905 ist das Projektmanagement-Handbuch (PM-Handbuch) eine „Zusammenstellung von Regelungen, die innerhalb einer Organisation generell für die Planung und Durchführung von Projekten gelten.“ Diese allgemeingültigen organisatorischen Regeln werden nicht nur für ein einziges Projekt aufgestellt, sondern gelten für alle Projekte in einem Unternehmen. Außerdem enthält das PM-Handbuch vereinheitlichte Vorlagen für zu verwendende Dokumente. Ein umfangreiches Beispiel findet man in [Hilpert 2001, S. 181]. Der Aufwand für die Erstellung eines PM-Handbuchs wird durch die erreichbaren Vorteile mehr als wettgemacht. Ist das Handbuch erst einmal erstellt, kann bei jedem Projekt darauf zurückgegriffen werden. Die Organisation für ein neues Projekt reduziert sich dadurch auf einige wenige Entscheidungen, wie z. B. die Auswahl der passenden Aufbauund Ablauforganisation aus den im Handbuch aufgelisteten Standard-Organisationsformen. Die Verwendung eines PM-Handbuchs verringert auch die Gefahr, dass Projekte ohne entsprechende organisatorische Regelungen begonnen werden. Beispiel 4.15 Zusammensetzung eines PM-Handbuchs

Die folgende Auflistung stellt den Aufbau und die Gliederung eines exemplarischen Projektmanagement-Handbuchs dar. Das Handbuch wurde bei den Steinbachwerken im Laufe zahlreicher Projekte erstellt und wird stetig weiter gepflegt. Es ist ein Bestandteil des Qualitätsmanagements. Seine Anwendung wird bei den regelmäßig stattfindenden Audits zur Bestätigung der Zertifizierung nach ISO 9000 überprüft. 1. Einleitung, 1.1 Aufgaben und Anwendungsbereich des Handbuchs, 1.2 Begriffsklärungen, 1.3 Versionen des PM-Handbuchs,

130

4

Projektorganisation

2. Projektgründung, 2.1 Anforderungen an das Lastenheft, 2.2 Aufgaben und Aufbau des Pflichtenhefts, 2.3 Grundlagen für die Projektkalkulation, 3. Aufbauorganisation, 3.1 Aufgaben, Verantwortungen und Befugnisse der Projektbeteiligten, 3.2 Vorgesehene Formen der Aufbauorganisation, 3.3 Festlegungen für die Teamarbeit, 3.4 Regeln für die Kommunikation im Projekt, 3.5 Regeln für die Dokumentierung und Dokumentenablage, 4. Projektplanung, 4.1 Anforderungen an den Produktstrukturplan, 4.2 Anforderungen an den Projektstrukturplan, 4.3 Muster eines Standard-Projektstrukturplans, 4.4 Anleitung und Regeln für die Aufwandsschätzung, 4.5 Festlegung der Methoden für die Ablauf- und Terminpläne, 4.6 Vorgehensweise für die Risikoanalyse, 5. Projektsteuerung, 5.1 Aufgabe der Projektkontrolle, 5.2 Einzusetzende Methoden der Fortschrittsanalyse, 5.3 Korrekturmaßnahmen, 6. Projektabschluss, 6.1 Arbeitsschritte des Projektabschlusses, 6.2 Festlegung der Projektauswertung, Anhang: Checklisten, Formulare. Die Einleitung legt die grundlegenden Randbedingungen für die Anwendung des Handbuchs fest. Danach werden die notwendigen Arbeiten und die Anforderungen an die Dokumente beschrieben, die zu Beginn eines Projekts benötigt werden. Da das Handbuch für alle Arten von Projekten im Unternehmen gültig ist, werden die möglichen Formen der Aufbauorganisation beschrieben, aus der im konkreten Projekt eine Organisationsform ausgewählt wird. Das nächste Kapitel legt die Anforderungen an die Pläne, sowie die Regeln für die Arbeitsschritte der Planerstellung fest. Danach werden der Aufgabenbereich und die Methodik für die Überwachung und Steuerung des Projektablaufs festgelegt. Das letzte Kapitel behandelt die Regeln für den Projektabschluss. Der Anhang des PM-Handbuchs enthält alle Checklisten und einheitliche Vorlagen für alle Projektdokumente. J

5

Strukturplanung

Einen für den Erfolg oder Misserfolg eines Projekts ganz entscheidenden Schritt im Rahmen des Projektmanagements bildet die Projektplanung. Im vorliegenden Kap. 5, Strukturplanung, geht es um die Strukturierung des Produkts und des Projekts. Sie werden zunächst mit der strukturierten Sichtweise des Produkts vertraut gemacht. Der Produktstrukturplan enthält alle Bestandteile, die am Ende eines Projekts vorliegen bzw. ausgeliefert werden müssen. Sie werden den Projektstrukturplan, der alle Arbeiten eines Projekts in hierarchisch gegliederter Form umfasst, als zentrales Planungsdokument eines Projekts kennenlernen. Aus allen darin enthaltenen Arbeitspaketen werden Vorgänge gebildet, die dann von den beteiligten Personen unter Nutzung bestimmter Ressourcen auszuführen sind (Abb. 5.1).

Nach der Bearbeitung des Kapitels sind Sie in der Lage,  die Bedeutung des Produktstrukturplans als Sammlung aller Arbeitsergebnisse für die Projektplanung zu erläutern,  einen Produktstrukturplan nach der Top-down- oder der Bottom-up-Vorgehensweise zu erstellen,  in einem Projekt das angestrebte Projektergebnis – egal ob es sich um einen Gegenstand oder eine Leistung handelt – als hierarchisch strukturierten Plan zu modellieren,  die zentrale Bedeutung des Projektstrukturplans als Sammlung aller auszuführenden Arbeiten für die nachfolgenden Planungsschritte zu begründen,  die jeweiligen Vorteile einer produktorientierten und einer prozessorientierten Gliederung des Projektstrukturplans zu formulieren,  aus einem konkreten Produktstrukturplan einen Projektstrukturplan zu erstellen,

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 W. Jakoby, Projektmanagement für Ingenieure, https://doi.org/10.1007/978-3-658-32791-0_5

131

132

5 Strukturplanung

Lastenhe Pflichtenhe

Produkt-Strukturplan erstellen

Produkt-Strukturplan

Projekt-Strukturplan erstellen

Projekt-Strukturplan

Vorgänge festlegen

Vorgangsliste AP-Beschreibungen

Abb. 5.1 Prozesse der Strukturplanung

 mit Hilfe von Standard-Projektstrukturplänen Erfahrungen aus vorangegangenen Projekten zu sammeln und zur Planung neuer Projekte zu nutzen.

5.1 5.1.1

Produktstrukturplanung Der Produktstrukturplan

Den Ausgangspunkt für die Strukturierung eines Projekts sollte immer das angestrebte Projektziel sein. Wenn die Planung darauf ausgerichtet wird, welches Ergebnis am Projektende erwartet wird, ist die Wahrscheinlichkeit, einerseits alle erforderlichen Aktivitäten berücksichtigt zu haben und andererseits keine unnötigen Aktivitäten entfaltet zu haben, am größten. Das Produkt – egal ob es sich dabei um eine mechanische Konstruktion, ein elektrisches Gerät, ein Softwaresystem, ein Gebäude, eine Dokumentation, eine Verfahrensvorschrift oder eine Dienstleistung handelt – besteht im Allgemeinen aus einer Vielzahl von Komponenten. Die Komponenten stehen untereinander in Wechselwirkungen und können hierarchisch gegliedert werden. Das Projektergebnis kann daher als baumartig gegliederter Produktstrukturplan angesehen werden. Bei kleinem Umfang oder bei nur grober Auflösung lässt sich dieser Strukturplan in graphischer Form darstellen (Abb. 5.2). In der graphischen Form kann man sehr gut die aus der horizontalen Strukturierung folgenden, verschiedenen Produktteile erkennen. Die vertikale Strukturierung führt zu verschiedenen Strukturebenen. Sie beginnen auf der obersten Ebene beim Gesamtprodukt und werden nach unten immer detaillierter bis hin zu elementaren Produkt-Komponenten. Bei größeren Systemen mit Dutzenden Produktteilen und Hunderten von elementaren Komponenten wird die detaillierte Beschreibung in graphischer Form umfangreich und verliert an Übersichtlichkeit. Hier ist die Listenform besser geeignet (Abb. 5.3).

5.1 Produktstrukturplanung

133

Abb. 5.2 Graphisch dargestellter Produktstrukturplan Abb. 5.3 Produktstrukturplan in Listenform

Auch wenn die Bezeichnungen horizontal/vertikal in dieser Darstellungsform etwas gewöhnungsbedürftig erscheint – Grafik und Liste bringen den gleichen Sachverhalt zum Ausdruck, den Produktstrukturplan als Baumstruktur. I

Der Produktstrukturplan (ProdSP) ist eine hierarchisch gegliederte Liste aller Teile eines Produkts.

Die konkrete Struktur eines Produkts ist natürlich individuell sehr unterschiedlich. Bei einer mechanischen Konstruktion bieten sich eine getrennte Betrachtung der einzelnen Teilkomponenten und deren zunehmende Detaillierung an. Bei einer größeren elektrischen Schaltung können die verschiedenen Funktionen betrachtet werden. Wird die Gesamtschaltung auf verschiedene Baugruppen aufgeteilt, so sind diese ein geeignetes Gliederungskriterium. Bei einem Softwaresystem bietet sich die Gliederung in einzelne Programme, in Module und Funktionen an. Bei einem Gebäude sind die verschiedenen Gewerke geeignet, um eine Gliederung des Produkts vorzunehmen. Das Ergebnis der Produktplanung sollte eine vollständige Liste der Produktteile sein. Dabei stellen sich natürlich die Fragen, wann eine Liste tatsächlich vollständig ist und wie detailliert diese Liste in der Planungsphase gestaltet sein muss. Da die Produktplanung die Vorlage für die Projektplanung bildet, bestimmt diese den Detaillierungsgrad. Ist bei

134

5 Strukturplanung

einem Produktteil klar erkennbar, welche Arbeiten für dessen Herstellung oder Beschaffung notwendig sind, hat man einen genügenden Detaillierungsgrad erreicht. Ist dies noch nicht der Fall, so ist eine weitere Zerlegung nötig. Beispiel 5.1 Produktstrukturplan Wohnhaus

Bei einem Bauprojekt kann das Produkt „Wohnhaus“ zerlegt werden in seine komplexen Teile Baugrund, Rohbau und Ausbau (Abb. 5.4). Deren Zusammensetzung ist noch viel zu komplex, um daraus schon die notwendigen Arbeiten im Einzelnen planen zu können. Deshalb ist eine weitere Zerlegung notwendig. Beim Ausbau könnten dies z. B. die Teile der Wasserversorgung, der Entsorgung, die elektrischen Anlagen, die Heizung, die Fenster etc. sein. Auch diese Bestandteile sind immer noch zu komplex. In einer weiteren Detaillierung kann man die elektrischen Anlagen aufteilen in elektrische Hauptleitung (vom Hausanschluss zum Zähler), zentrale Energieverteilung mit Zähler und Sicherungen, die Verteilungsleitungen, die Verbraucher und die Schaltkomponenten. Auf dieser De-

Abb. 5.4 Produktstrukturplan Wohnhaus (Auszug)

5.1 Produktstrukturplanung

135

taillierungsebene lassen sich nun einzelne Arbeitspakete identifizieren, die zur Herstellung oder Beschaffung notwendig sind. In der gleichen Art müssen alle Gewerke so weit detailliert werden, dass die damit verbundenen Arbeiten erkennbar und abschätzbar sind. J Das Ergebnis der Produktplanung ist der Produktstrukturplan, der alle Teile des Produkts enthält. Er besitzt eine Baumstruktur, die entweder in Textform beschrieben oder graphisch dargestellt werden kann. Der Produktstrukturplan konzentriert sich auf die hierarchische Beziehung der Teile. Andere Aspekte wie deren räumliche Anordnung, deren Verbindung untereinander oder die Wirkungsbeziehungen werden zunächst, d. h. für die im nächsten Arbeitsschritt folgende Projektstrukturplanung nicht unbedingt gebraucht. Da aus dem Produktstrukturplan alle weiteren Pläne, insbesondere der Projektstrukturplan abgeleitet werden, kommt seiner Qualität eine besondere Bedeutung zu. Hier sind vor allem folgende Merkmale zu nennen:  Vollständigkeit,  Übersichtlichkeit,  Transparenz. Mit Abstand das wichtigste Qualitätsmerkmal ist die Vollständigkeit. Wird ein Teil vergessen, so tauchen auch die dafür notwendigen Arbeiten im Projektplan nicht auf, was sofort ungeplanten Mehraufwand und Terminprobleme zur Folge hat. Wird dagegen ein Produktteil am Ende eines Projekts anders realisiert, als ursprünglich geplant, ändern sich zwar die anfallenden Arbeiten. Trotzdem ist der Schaden in diesem Fall um eine ganze Größenordnung geringer, als wenn gar keine Arbeiten eingeplant worden wären. Eine gründliche und übersichtliche Produktstrukturplanung deckt außerdem Unklarheiten, Lücken, Fehler und Widersprüche in der Aufgabendefinition auf. Außerdem vermittelt die Auseinandersetzung mit dem angestrebten Produkt Einblicke in die unterschiedliche Wichtigkeit und Schwierigkeit der einzelnen Produkteile. Die wichtigen Risikofaktoren sind dadurch bekannt.

5.1.2

Zusammensetzung des Produktstrukturplans

Bei einem Produkt wird natürlich in erster Linie an die Teile gedacht, die am Ende an die Auftraggeber geliefert werden sollen. Sie werden in der Regel im Lastenheft gefordert und im Pflichtenheft explizit genannt. Die Gefahr hier etwas zu vergessen, ist eher gering. Aber zum Produkt gehört noch mehr, als die Liefergegenstände. Hier sind vor allem die Dokumentationen zu nennen, die am Projektende abzuliefern sind, wie z. B. Benutzerhandbuch, Bedienungsanleitung und Betriebsanleitung. Aber auch die Dienste, wie z. B. Inbetriebnahme, Schulung und Service zählen zum „Produkt“. Sie erfordern Zeitaufwand,

136

5 Strukturplanung

sie sind vorzubereiten und verursachen Kosten und sind deshalb unbedingt im Projektplan zu berücksichtigen. Vielfach vergessen werden Hilfsprodukte und Zwischenprodukte. Hiermit sind alle die Produkte und Produktteile gemeint, die nicht an die Auftraggeber ausgeliefert werden, aber im Laufe des Projekts benötigt werden. Typische Zwischenprodukte sind Simulationsmodelle, Prototypen und Testversionen eines Produkts. Es handelt sich sozusagen um Produkte in einer früheren Entwicklungsstufe, die später bei der Auslieferung nicht mehr in Erscheinung tritt. Hilfsprodukte dagegen werden geschaffen, um die eigentlichen Produkte z. B. zu testen, zu vermessen, zu verarbeiten oder zu transportieren. Manche Hilfsprodukte müssen in eigenen Teilprojekt entwickelt und aufgebaut werden. Andere können in fertiger Form zugekauft werden. Aber auch diese verursachen Kosten und Aufwand in Form einer Marktrecherche, der Bestellung und der Inbetriebnahme. Sie müssen daher im Projekt berücksichtigt werden. Oft kommen in den Produkten viele Bestandteile mit ähnlichen Bezeichnungen vor, wie z. B. Gehäuse, Elektronikbaugruppe, Software-Treiber. Die Gefahr von Verwechselungen ist hier besonders groß. Deshalb sollte in der Erstellung des Produktstrukturplans bereits auf eindeutige Bezeichnungen geachtet werden. Am besten gelingt dies durch einen numerischen Schlüssel – eine Teile-Ident-Nummer. Da die Teile zu einer baumartigen Struktur gehören, sollte der Schlüssel außerdem die Position des Teils in der Baumstruktur kennzeichnen. Ein derartiger Gliederungsschlüssel besitzt für jede Gliederungsebene eine eigene Position. In der Praxis findet man unterschiedliche Konstellationen:  Gegliederte Nummerierungen, z. B. 2.1.5.3,  Mehrstellige Dezimalzahlen, z. B. 0001, 2437, 1002,  Gemischte alphanumerische Schlüssel, z. B. IIIA17, IVC9. Am übersichtlichsten ist sicherlich die gegliederte Nummerierung. Die Ebenen werden durch Punkte getrennt, so dass jede Ebene leicht zu finden ist und keine Einschränkungen hinsichtlich des Zahlenbereichs bestehen. Mehrstellige Dezimalzahlen verwenden für jede Ebene eine Ziffer. Daher sind auf jeder Ebene maximal 10 Positionen möglich. Gemischte Systeme, die neben den arabischen Zahlen auch Buchstaben und z. B. römische Zahlen zulassen sind dagegen eher unübersichtlich. Werden in unterschiedlichen Projekten ähnliche Produkte entwickelt, was in vielen Unternehmen typisch ist, so ist eine Standardisierung des Produktstrukturplans sehr sinnvoll. Zurückliegende Projekte und die darin entwickelten Projekte werden ausgewertet und nach Gemeinsamkeiten untersucht. Daraus wird dann als Obermenge eine StandardStruktur der Produkte erstellt. Dadurch können Erfahrungen aus abgeschlossenen Projekten genutzt werden. Neue Produktstrukturpläne lassen sich dadurch schneller und mit weniger Fehlern erstellen. In der Regel deckt ein Standard-Produktstrukturplan nur die oberen Ebenen der Baumstruktur ab, da in den unteren Ebenen individuelle Details überwiegen und produktspezifisch gestaltet sind.

5.1 Produktstrukturplanung

137

Abb. 5.5 Standard-Produktstrukturplan

Beispiel 5.2 Standard-Produktstrukturplan mit Gliederungsschlüssel

Abb. 5.5 zeigt für einen Hersteller elektrischer Geräte einen Ausschnitt eines StandardProduktstrukturplans mit einem Gliederungsschlüssel. Er umfasst die beiden obersten Ebenen der Struktur. Auch wenn nicht jede Ebene der Struktur bei einem konkreten Produkt ausgestaltet sein muss, erleichtert sie die Bestimmung der Produktstruktur, da nicht so leicht Teile vergessen werden. J

5.1.3 Vorgehensweise zur Planerstellung Für die Herleitung eines Produktstrukturplans stehen zwei grundsätzliche Wege zur Verfügung: Top-down oder Bottom-up. Beim Top-down-Ansatz beginnt man beim Gesamtprodukt, das dann in seine Haupt-Teile zerlegt wird. Diese werden dann möglicherweise über mehrere Hierarchieebenen gedanklich immer weiter zerlegt, bis man auf der Ebene elementarer Bestandteile angelangt ist. Die Teile sind elementar, wenn sie fertig beschafft werden können oder wenn alle Arbeiten, die zu ihrer Herstellung erforderlich sind, vollständig bekannt sind. Der Vorteil der Top-down-Vorgehensweise ist eine quasi „von selbst“ entstehende Gliederung. Diese Gliederung ist aber gleichzeitig eine Schwäche des Ansatzes. Ist die Gliederung nämlich nicht schon vorab erkennbar, ist die schrittweise Zerlegung schwierig.

138

5 Strukturplanung

Hier kann der Bottom-up-Ansatz helfen. Ist die hierarchische Struktur nicht auf Anhieb erkennbar, beginnt man mit einem unstrukturierten Sammeln und Aufzählen von Produktteilen. Eine geeignete Hilfe hierbei ist die Betrachtung des angestrebten Produkts als System. Als solches steht es mit seiner Umgebung über Schnittstellen in Verbindung. Diese Schnittstellen erfordern verschiedene Systemteile. Darüber hinaus muss das Produkt bestimmte Funktionen realisieren. Auch diese erfordern Systemteile. Durch dieses Vorgehen entsteht eine unstrukturierte, oft bunt gemischte Liste von Produktteilen. Ist man nach eingehender Recherche der Meinung, die Liste sei nun vollständig, beginnt man, sie zu gruppieren, zu ordnen und hierarchisch zu gliedern. Hierfür kann es unterschiedliche Gliederungskriterien geben, wie z. B. die funktionale oder die räumliche Zusammengehörigkeit. Fast immer stellt man beim Gliedern fest, dass noch Teile vergessen wurden, so dass die Liste nach und nach komplettiert wird. Allerdings fällt es beim Bottom-up-Ansatz schwer zu entscheiden, wann die Liste tatsächlich vollständig ist. Daher läuft man Gefahr, entweder Teile zu vergessen, weil die Suche zu früh beendet wurde, oder viel Zeit mit einer ergebnislosen Suche zu vergeuden. Aus praktischer Sicht ist es daher sinnvoll, sich nicht nur auf einen der beiden Wege zu stützen, sondern den Problemraum von beiden Seiten aufzuspannen und dadurch mit vertretbarem Zeitbudget ein gutes Ergebnis zu erzielen: man erstellt Top-down eine hierarchische Strukturierung des Produkts und Bottom-up eine Liste von Teilen, die noch fehlen und führt dann beide Listen zusammen. Beispiel 5.3 Fallbeispiel „Maschinenterminal“: Produktstrukturplan

Das Maschinenterminal aus dem Fallbeispiel soll eine einfache Benutzerschnittstelle mit Textdisplay und Folientastatur besitzen. Die Personenidentifikation erfolgt entweder manuell durch Eingabe der Personalnummer oder automatisiert mit Hilfe von Barcodeleser bzw. Magnetkartenleser. Zur Auswertung und Ansteuerung von Maschinensignalen sollen schaltende Eingänge und Ausgänge zur Verfügung stehen. Die Auswertung und Speicherung aller Meldungen erfolgt auf einem zentralen Server, an den die Terminals über ein Rechnernetz angeschlossen werden. Server und Rechnernetz stehen bereits zur Verfügung und sind daher nicht Bestandteil des Projekts. Zur Erstellung des Strukturplans mit dem Top-down-Ansatz kann man zunächst das Gerät gedanklich in seine wesentlichen Bestandteile zerlegen, wie z. B. Mechanik, Elektronik, Software und Dokumentation. Die Zerlegung stellt die erste Gliederungsebene des Produktstrukturplans dar. Im nächsten Schritt kann dann jeder Bestandteil gedanklich weiter zerlegt werden. Bei der Mechanik könnte man sich ein zweischaliges Gehäuse, bestehend aus Ober- und Unterteil vorstellen, einen Stecker für den Stromanschluss, einen Netzwerkstecker und eine Wandhalterung. In der gleichen Art könnte man Elektronik, Software und Dokumentation auf der zweiten Gliederungsebene zerlegen. Falls notwendig könnte man auch noch eine dritte Gliederungsebene einführen, um zu elementaren Komponenten zu kommen (Abb. 5.6).

5.1 Produktstrukturplanung

139

Top-down

Bottom-up Maschinenterminal

1. Gehäuse 2. Elektronik 3. Software 4. Zubehör

2. Elektronik 2.1. CPU-Baugruppe 2.2. Benutzerschnittstelle 2.3. Lesegeräteinterface ...

2.2. Benutzerschnittstelle 2.2.1. Textdisplay 2.2.2. Folientastatur ...

1. Netzteil 2. CPU 3. Folientastatur 4. Lesestift 5. LAN-Stecker ... 36. Textdisplay 37. Wandhalter

Abb. 5.6 Top-down- und Bottom-up-Ansatz zur Strukturierung

Abb. 5.7 Produktstrukturplan des Maschinenterminals

Entscheidet man sich dagegen für einen Bottom-up-Ansatz, wird man die Gerätebestandteile spontan in einer Art Brainstorming zusammenstellen, ohne zunächst auf eine Gliederung zu achten. Das Ergebnis könnte, wie in Abb. 5.6 rechts dargestellt, eine Aufzählung von einzelnen Teilen sein. Als Nächstes müssen diese Teile nach einem bestimmten Gesichtspunkt gruppiert und zu Oberbegriffen zusammengefasst werden (Abb. 5.7). J

140

5 Strukturplanung

Da der Produktstrukturplan in einer frühen Planungsphase erstellt wird, sind viele Realisierungsdetails noch nicht bekannt. Dies muss auch nicht sein. Der Plan sollte zwar alle wesentlichen Teile des Produkts und deren hierarchische Gliederung beinhalten. Viele später benötigte Aussagen muss der Produktstrukturplan aber noch nicht enthalten! Hierzu zählt z. B. die räumliche Anordnung der Teile oder Festlegungen über die Wechselwirkungen oder Verbindungen zwischen den Teilen. Das Hauptaugenmerk sollte in dieser Projektphase stattdessen auf die Vollständigkeit der Teile-Aufzählung gelegt werden.

5.2 Projektstrukturplanung 5.2.1

Der Projektstrukturplan

Ein Projekt umfasst im Allgemeinen eine große, oft nicht überschaubare Menge von Arbeiten. Viele Arbeiten sind zu Beginn eines Projektes nur unvollständig oder gar nicht bekannt. Die erfolgreiche Planung und Durchführung eines Projektes setzt aber voraus, dass alle auszuführenden Arbeiten eingeplant sind und dass Abhängigkeiten, die zwischen den Arbeiten bestehen, berücksichtigt werden. Es ist daher notwendig, die unstrukturierte Gesamtmenge aller Arbeiten in einem hierarchisch gegliederten Plan einzelner Arbeitspakete zusammen zu fassen. Dieser so genannte Projektstrukturplan (engl.: work breakdown structure) stellt alle Arbeiten, die im Laufe eines Projektes anfallen, in einer Baumstruktur dar. Auf der obersten (der 0.) Ebene der Baumstruktur steht das Gesamtprojekt. Auf der untersten Ebene befinden sich viele einzelne Arbeitspakete. Notwendiges Merkmal eines Projektstrukturplanes sind seine Vollständigkeit (es werden alle Aufgaben erfasst) und die Gesamt-Betrachtungsweise (keine Aufgabe wird für sich alleine, sondern im GesamtZusammenhang gesehen). I

Der Projektstrukturplan (ProjSP) fasst alle in einem Projekt notwendigen Arbeiten in einer hierarchisch strukturierten Liste zusammen.

Das Produkt als angestrebtes Ergebnis eines Projekts bestimmt weitgehend, was in einem Projekt zu tun ist. Zumindest bei technischen Projekten ist daher der Produktstrukturplan der wichtigste Input für die Erstellung des Projektstrukturplans (Abb. 5.8). Der Projektstrukturplan selbst bildet die Basis für weitere Planungsschritte: die Festlegung der Vorgänge, die Erstellung des Terminplans, die Schätzung der Kosten und den Einsatz der Mitarbeiter und der Ressourcen. Die Erstellung eines Projektstrukturplans erfordert wegen der angestrebten Vollständigkeit einen gewissen Arbeitsaufwand. Dieser ist aber gerechtfertigt, durch die solide Basis, die er für die weiteren Planungen bildet. Wird ein Projektstrukturplan im Rahmen der Erstellung eines Angebots erarbeitet, kann es sinnvoll sein, sich zunächst mit

5.2 Projektstrukturplanung Produktstrukturplan Ablauforganisation

141

Erstellung Projektstrukturplan

Projektstrukturplan

Abb. 5.8 Einordnung des Projektstrukturplans im Projektablauf

einem Grob-Projektstrukturplan zu begnügen. Das Ergebnis der Grobstrukturierung ist ein Projektstrukturplan, bei dem das Gesamtprojekt so weit untergliedert ist, dass die Teilaufgaben hinsichtlich Funktionalität, Zeitaufwand und Kosten abschätzbar sind. Bei welchem Detaillierungsniveau eine hinreichend genaue Abschätzbarkeit erreicht ist, kann nicht allgemein beantwortet werden. Dies hängt im Wesentlichen von zwei Faktoren ab: von eventuell vorliegenden Erfahrungen mit ähnlichen Aufgaben und vom Zweck der Abschätzung. Ein genaues Angebot oder eine detaillierte Personalplanung erfordert eine wesentlich höhere Genauigkeit der Schätzung als wenn nur eine Größenordnung der erwarteten Kosten angegeben oder ein möglicher Zieltermin genannt werden soll. Der grobe Projektstrukturplan bildet die Basis zur Schätzung des Aufwandes und damit zur Erstellung eines Angebotes. Da oft nur ein geringer Teil der Angebote auch zu einem Auftrag führt, ist es aus Aufwandsgründen sinnvoll, nur eine grobe Strukturierung zu erstellen. Erst wenn der Auftrag für die Projektdurchführung erteilt wurde, ist eine Feinplanung sinnvoll. Diese hat das Ziel, die Aufgaben so weit zu konkretisieren und zu untergliedern, dass man zu Einzelaufgaben gelangt, die vom Aufwand her gut überschaubar sind und genau einer Person, einer Maschine oder einem Arbeitsplatz zugeordnet werden können. Der Fein-Projektstrukturplan bildet damit die Grundlage für die spätere Ablaufplanung. Für die Gliederung der Projektstruktur gibt es zwei grundsätzliche Varianten. Die Strukturierung kann ausgehend vom Projektziel erfolgen. Die Gliederung des angestrebten Gesamtprodukts in verschiedene Produktteile kann man daher auch zur Gliederung der Arbeiten des Projekts verwenden. Man spricht hierbei auch von einer objekt- bzw. produktorientierten Strukturierung. Die Strukturierung kann aber auch unter dem Aspekt der Projektdurchführung erfolgen. Dieser Weg wird in kleinere Etappen zerlegt. Hierbei stehen die Arbeitsabläufe im Unternehmen bzw. die Funktionen der einzelnen Abteilungen im Vordergrund und man spricht von einer funktions- bzw. prozessorientierten Strukturierung.

5.2.2

Produktorientierte Gliederung

Die produktorientierte Gliederung eines Projektstrukturplans leitet die Arbeitspakete für ein Projekt aus den Produktteilen ab und lehnt sich an die Gliederung des Produktes an. Jeder Teil eines Produkts erfordert bestimmte Arbeiten, so dass diese auch zu einer Teilaufgabe im Projektstrukturplan zusammengefasst werden können. Trotzdem sind die

142

5 Strukturplanung

beiden Gliederungen nicht identisch. Zum einen gliedert der Produktstrukturplan physische Komponenten des Produkts und der Projektstrukturplan die Arbeiten des Projekts. Des Weiteren umfasst der Projektstrukturplan Arbeiten, die einem Produktteil nur sehr schwer oder gar nicht zuzuordnen sind. Beispiele hierfür sind die Arbeiten des Projektmanagements, die Analyse des Lastenhefts, der Systemtest oder die Übergabe des Gesamtprodukts. Sind die im Projekt zu lösenden Probleme überwiegend technischer Art, so ist die produktorientierte Gliederung sinnvoll. Dies ist z. B. der Fall, wenn ein neues technisches Produkt entwickelt werden soll. Hier kann es unproblematische Produktteile geben, die einfach beschafft oder hergestellt werden können, und andere Teile, bei denen größere Probleme auftreten können. Zu deren Lösung müssen oft unterschiedliche Abteilungen eines Unternehmens oder Fachleute unterschiedlicher Disziplinen eng zusammenarbeiten. Die entsprechenden Arbeiten werden daher sinnvollerweise auch zusammenhängend im Projektstrukturplan dargestellt und geplant. Beispiel 5.4 Fallbeispiel „Maschinenterminal“: Projektstrukturplan

Für das Maschinenterminal, dessen Produktstrukturplan zuvor entworfen wurde, kann nun der Projektstrukturplan hergeleitet werden. Zunächst erfolgt eine grobe Einteilung der Projektphasen. Dann werden passend zum Produkt die größeren Komponenten (Gehäuse, Elektronik, Software, Zubehör) betrachtet. Diese werden anschließend weiter detailliert (Abb. 5.9). Das Ergebnis ist eine gegliederte Liste aller Arbeitsgänge. Auch wenn diese Liste noch keinen Anspruch auf Vollständigkeit erheben kann, erhält man bereits ca. 50 Arbeitsgänge. Nimmt man für diese einen mittleren Personalaufwand von 5 Personentagen an, umfasst das Projekt damit eine Größenordnung von 250 Personentagen, also etwas mehr als 1 Personenjahr. J

5.2.3

Prozessorientierte Gliederung

Bei der prozessorientierten Gliederung legen die Arbeitsabläufe und die an einem Projekt mitwirkenden Abteilungen eines Betriebs die Zuordnung von Arbeitspaketen zu Teilaufgaben oder zu Teilprojekten des Projektstrukturplans fest. Bei der prozessorientierten Gliederung wird der zeitliche Ablauf eines Projekts als Kriterium für die Zuordnung zu Arbeitspaketen herangezogen. Arbeitspakete, die aufeinander folgen müssen, bilden dann eine Teilaufgabe. Die prozessorientierte Gliederung der Arbeiten ist vor allem dann sinnvoll, wenn die Probleme im Projekt vorwiegend organisatorischer Art sind. Dies ist z. B. bei Organisationsprojekten der Fall oder bei der Projektierung von Anlagen, die aus verfügbaren Komponenten zusammengestellt werden, um eine Aufgabe zu erfüllen. Hier sind die Funktionen einzelner Abteilungen, wie z. B. Vertrieb, Einkauf, Montage und Service eher

5.2 Projektstrukturplanung

143

Abb. 5.9 Projektstrukturplan Maschinenterminal

unabhängig voneinander. Im Projektstrukturplan werden daher die Arbeitspakete der einzelnen Abteilungen als zusammenhängende Einheiten dargestellt. Die prozessorientierte Gliederung eines Projekts lehnt sich stärker an die bestehende Linienstruktur eines Unternehmens an und erleichtert die Zuordnung der Arbeitspakete zu Abteilungen und Personen. Allerdings gehen dabei auch projektspezifische Vorteile, wie das abteilungsübergreifende Denken und Zusammenarbeiten zum Teil wieder verloren. Beispiel 5.5 Fallbeispiel „Solaranlage“: Projektstrukturplan

Die bestehende Heizanlage im Bürogebäude der Steinbachwerke soll durch eine solarthermische Anlage unterstützt werden. Diese besteht aus Flachkollektoren, die auf der Maschinenhalle installiert werden, sowie einem neuen bivalenten Wärmespeicher.

144

5 Strukturplanung

Abb. 5.10 Projektstrukturplan der Solaranlage

Der vorhandene Öl-Brenner mit seiner Steuerung ist erst 7 Jahre alt und soll erhalten bleiben. Der alte Wasserspeicher soll durch einen bivalenten Speicher ersetzt werden, bei dem sowohl der Öl-Brenner als auch die Solaranlage als Wärmequelle dienen. Im Heizraum im Keller des Hauses ist genügend Platz, um den Wärmespeicher und die Solarstation unterzubringen. Die Flachkollektoren sollen auf der angrenzenden Maschinenhalle montiert werden. Der Auftrag zur Planung, Montage und Inbetriebnahme der Solaranlage wird an ein externes Ingenieurbüro vergeben. Zusammen mit dem Angebot wird der in Abb. 5.10 dargestellte vorläufige Projektstrukturplan vorgelegt. Der Projektstrukturplan ist entsprechend des Arbeitsablaufs in die 4 Phasen Aufgabenanalyse, Beschaffung, Aufbau und Inbetriebnahme unterteilt. Diese Unterteilung hat den Vorteil, dass mit dem Aufbau erst begonnen wird, wenn alle Teile da sind. Dadurch ergeben sich keine unnötigen Verzögerungen während der Aufbauphase und die Nerven des Auftraggebers und das Budget des Auftragnehmers werden geschont. Jede Phase kann in verschiedene Arbeitspakete unterteilt werden. Diese sind so zugeschnitten, dass der jeweilige Aufwand gut abschätzbar ist und dass sie so weit wie möglich unabhängig voneinander ausgeführt werden können.

5.2 Projektstrukturplanung

145

Sowohl die angebotene Anlage als auch der Preis findet nach entsprechenden Verhandlungen die Zustimmung beim Auftraggeber. Da aber während der Montage- und Inbetriebnahmephase mit Störungen zu rechnen ist, erwartet der Verhandlungsführer der Steinbachwerke vor der Vergabe des Auftrags einen verlässlichen Ablauf- und Terminplan. Dieser soll vom Auftragnehmer innerhalb einer Woche vorgelegt werden. J Neben den beiden Grundformen des produkt- und des prozessorientierten Strukturplans findet man in der Praxis auch viele Mischformen. Sie versuchen, die Vorteile der beiden Gliederungsarten miteinander zu kombinieren. Bei der Entscheidung für ein bestimmtes Gliederungsschema der Projektstruktur sollte immer die Aufgabe des Projektstrukturplans im Auge behalten werden: Er bildet die Basis für die nachfolgenden Planungsschritte, insbesondere die Aufwandsschätzung und die Zuordnung von Personen zu den Arbeitspaketen. Jede Gliederung, die diese Planungsschritte erleichtert und verbessert, ist eine gute Gliederung. Das Gliederungsschema sollte also immer so gewählt werden, dass die Zuordnung der Arbeiten zu den Personen möglichst einfach und klar wird. Dies ist z. B. der Fall, wenn nicht nur ein einzelnes Arbeitspaket zu einer Person zugeordnet werden kann, sondern wenn mehrere zusammengehörende Pakete, die ein Teilprojekt bilden, auch von einer zusammengehörenden Gruppe von Personen, also einer Unternehmensabteilung komplett bearbeitet werden können. In Abb. 5.11 wird das Teilprojekt 1 komplett durch die Entwicklungsabteilung (E) bearbeitet. Innerhalb des Projekts wird damit eine Untereinheit gebildet, die sich selbst organisieren kann. Für die Projektleitung (P) ist es egal, welche Person aus der Entwicklungsabteilung das einzelne Arbeitspaket bearbeitet. Wichtig ist nur, dass die Arbeiten gemacht werden, dass sie richtig gemacht werden und dass sie zeitgerecht fertig gestellt werden. Die Verantwortung hierfür liegt bei der Leitung der Entwicklungsabteilung. Die übrigen Arbeiten werden Personen aus unterschiedlichen Abteilungen zugeordnet, was für die Projektleitung natürlich mehr Koordinierungsaufwand bedeutet.

5.2.4

Standard-Projektstrukturpläne

Die Erstellung eines vollständigen Projektstrukturplans ist eine wichtige Voraussetzung dafür, dass die Aufwandsschätzung alle Arbeiten erfasst und die Terminplanung verlässliche Aussagen liefert. Aufgrund der Einmaligkeit von Projekten kommt es andererseits immer wieder vor, dass Arbeitspakete vergessen oder „unterschätzt“ werden. Bei wirklich einmaligen Projekten lässt sich dieses Problem nur durch hohe Sorgfalt verringern. Um sich nicht auf mehr oder weniger zufällig gut geratene Projektpläne zu verlassen, ist es notwendig, den Entwurf des Projektstrukturplans möglichst zu systematisieren. Ein Unternehmen, das dauerhaft auf einem bestimmten Gebiet arbeitet, wird im allgemeinen nicht jedes Mal vollkommen unterschiedliche Projekte realisieren, sondern es werden von Projekt zu Projekt, trotz der Unterschiede im Detail immer wieder

146

5 Strukturplanung U

V

E . . .

F . . .

K . . .

P . . .

Projekt Teilprojekt 1 Arbeitspaket 1.1. Arbeitspaket 1.2. Arbeitspaket 1.3. Teilprojekt 2 Arbeitspaket 2.1. Arbeitspaket 2.2. Teilprojekt 3 Arbeitspaket 3.1. Arbeitspaket 3.2.

Abb. 5.11 Zuordnung der Arbeitspakete zu den Projektbeteiligten

Gemeinsamkeiten auftreten. Es ist daher erstrebenswert, die Gemeinsamkeiten in einem Standard-Projektstrukturplan zusammenzufassen. Die Struktur dieses Standard-Projektstrukturplans kann als eine Obermenge aller Arbeitspakete angesehen werden, die typischerweise in den Projekten dieses Unternehmens anfallen. Die Standardisierung führt die Erstellung eines konkreten Projektstrukturplans auf die Auswahl einer Teilmenge des Standard-Projektstrukturplans bzw. das Streichen unbenötigter Arbeiten und die Konkretisierung der verbleibenden Arbeitspakete zurück. Dies erleichtert die Erstellung eines Plans und reduziert das Risiko, einzelne Arbeitspakete zu vergessen. Außerdem lassen sich Erfahrungen mit vergangenen Projekten besser nutzen, um z. B. Kennzahlen für die Aufwandsschätzung zu bestimmen. Beispiel 5.6 Standard-Projektstrukturplan

Bei einem Hersteller kundenspezifischer elektrischer Steuerungen kam es in den Entwicklungsprojekten immer wieder zu Beanstandungen und teilweise deutlichen Zeitüberschreitungen. Unter den verschiedenen Ursachen hierfür war das komplette „Vergessen“ bestimmter Arbeitspakete oder das „Unterschätzen“ des Aufwandes für manche Arbeiten im Entwicklungsprozess auffällig oft zu finden. Die von vielen Seiten erhobenen Vorwürfe wurden immer wieder mit Hinweis auf die Neuartigkeit der Projekte und die Nicht-Vorhersagbarkeit der Probleme gekontert. Zur Lösung des Problems wurde eine ganze Reihe vergangener Entwicklungsprojekte analysiert. Trotz der zweifellos zutreffenden Ansicht, dass jedes Projekt anders aussieht, konnten in den verschiedenen Projekten durch eine abstraktere Betrachtungsweise viele Gemeinsamkeiten erkannt werden.

5.2 Projektstrukturplanung

147

Abb. 5.12 Standard-Projektstrukturplan für die Entwicklung elektronischer Steuerungen

Die Obermenge der gemeinsamen Arbeiten wurde dann zu einem groben StandardProjektstrukturplan zusammengefasst (Abb. 5.12). Dieser enthält alle Arbeiten, die in den Entwicklungsprojekten anfallen können, aber nicht immer anfallen müssen. Auf der obersten Ebene besteht jedes Projekt aus den Teilprojekten Vor-Projekt, Konzeption, mechanische Konstruktion, Hardware-Entwicklung, Software-Entwicklung und Tests. Jedes Teilprojekt ist außerdem, wie dargestellt, weiter in Arbeitspakete unterteilt. Bei der Akquisition und Planung eines neuen Projekts wird nun zunächst immer der Standard-Projektplan zugrunde gelegt. Arbeiten, die in einem konkreten Projekt nicht notwendig sind, werden gestrichen. Die verbleibenden Grob-Arbeitspakete können dann für das konkrete Projekt verfeinert werden. Die Gefahr, Arbeiten zu vergessen wird dadurch deutlich verringert. Außerdem können die Erfahrungswerte über geschätzte und tatsächlich benötigte Zeitaufwendungen besser miteinander verglichen und für neue Schätzungen herangezogen werden. J Beispiel 5.7 Prozessleittechnik-Projekte

Ein Prozessleitsystem zur Automatisierung verfahrenstechnischer Anlagen besteht aus einer Vielzahl vernetzter Sensoren, Aktoren, Regler und Steuerungsrechnern. Da jede

148

5 Strukturplanung

Tab. 5.1 Phasen und Aktivitäten von PLT-Projekten Nr. 1. 2. 3. 4.

5.

6. 7.

Phase Aktivität Grundlagenermittlung Vorplanung Basisplanung z. B. PLT-Funktionen festlegen Ausführungsplanung z. B. Geräte festlegen Stellenfunktionspläne erzeugen Montageunterlagen erstellen Errichtung z. B. Software konfigurieren Funktionen prüfen Inbetriebsetzung z. B. Personal ausbilden Projektabschluss

Aufwand (in %) 1 6 19 10 45 5 10 9 24 10 6 4 1 1

verfahrenstechnische Anlage anders aufgebaut ist und unterschiedliche Produktionsabläufe verwirklicht, ist auch die Planung, Errichtung und Inbetriebnahme eines Prozessleitsystems ein komplexes und zugleich einmaliges Vorhaben. Im Rahmen eines solchen PLT-Projekts erfolgen eine Projektierung der benötigten Hardware-Komponenten und die Programmierung der eingesetzten Rechner. Die NAMUR ist ein internationaler Verband der Anwender von Automatisierungstechnik der Prozessindustrie. Sie hat zahlreiche PLT-Projekte untersucht. Die dabei festgestellten Gemeinsamkeiten wurde im Arbeitsblatt NA 35 als Standard-Projektstruktur dokumentiert (Tab. 5.1). Ein typisches PLT-Projekt besteht aus 26 Einzelaktivitäten, von denen in der Tabelle nur einige exemplarisch aufgeführt sind. Die Aktivitäten werden 7 Projektphasen zugeordnet. Besonders hilfreich ist die Aufwandsermittlung für die Einzelaktivitäten, die in Form von Prozentwerten des Gesamtaufwands ausgedrückt wurden. Der Aufwand für das Projekt- und Qualitätsmanagement wurde dabei mit ca. 7–10 % beziffert und ist in den einzelnen Aktivitäten enthalten. J

5.3

Vorgänge festlegen

5.3.1 Arbeitspakete beschreiben Im Projektstrukturplan wird ein Projekt in Teilprojekte und Arbeitspakete untergliedert. Bei mittleren und großen Projekten kann es dabei mehrere Teilprojekt-Ebenen geben. Auf

5.3 Vorgänge festlegen

149

der untersten Ebene stehen immer die Arbeitspakete. Aus Sicht des Projektmanagement sind sie die kleinste betrachtete Arbeitseinheit. Unterhalb dieser Ebene ist es die Aufgabe der einzelnen Personen, die anstehenden Arbeiten und Aktivitäten selbständig noch detaillierter zu planen. Hierzu wird das Arbeits„Paket“ aufgeschnürt und in die einzelnen Arbeiten zerlegt. Diese Arbeiten werden dann individuell auf den zur Verfügung stehenden Bearbeitungszeitraum verteilt. Damit dies gelingt, müssen die auszuführenden Arbeiten eines Pakets vollständig und verständlich beschrieben werden. Hierzu wird für jedes Arbeitspaket eine eigene Beschreibung erstellt. Jedes Arbeitspaket kann als Prozess angesehen werden. Es ist daher naheliegend, dass die AP-Beschreibung in kurzer Form die auszuführenden Arbeiten benennt, die benötigten Voraussetzungen bzw. den Input sowie die angestrebten Arbeitsergebnisse. Neben den Kopfdaten, wie Projektbezeichnung und -nummer sowie Projektleiter muss für ein Arbeitspaket auch die benötigte fachliche Qualifikation und eine verantwortliche Person benannt werden. Dieses Feld kann zunächst auch offen bleiben, da die personelle Zuordnung meistens erst im Laufe der späteren Planungsschritte erfolgt. Dies gilt auch für den Arbeitsaufwand bzw. die Ausführungsdauer. Aus Gründen der Übersichtlichkeit, sollte die AP-Beschreibung in einem Projekt standardisiert und als Formular im PM-Handbuch enthalten sein. Der Umfang der AP-Beschreibung sollte nicht größer als eine Seite sein. Die Beschreibung muss nicht für Laien verständlich sein, sondern sie sollte auf das Qualifikationsniveau der späteren Bearbeiter gerichtet sein. Sie kann daher auch in Form von Stichpunkten erfolgen. Beispiel 5.8 Arbeitspaketbeschreibung Beschaffung Solarmodule

Für das Fallbeispiel „Solaranlage“ wurde der Projektstrukturplan erstellt und die Arbeitspakete wurden beschrieben. Abb. 5.13 zeigt die Beschreibung für die Beschaffung der Solarmodule, die im Rahmen der Strukturplanung und noch vor der Ablauf- und Terminplanung erstellt wurde. Die Beschreibung des Arbeitspakets ist für diese Phase des Projekts weitgehend vollständig. Die auszuführenden Arbeiten und auch das angestrebte Ergebnis sind präzise beschrieben. Die Aufgabe fällt in den Bereich der Einkaufsabteilung und wurde auch schon personell zugeordnet. Die inhaltlichen Voraussetzungen sind benannt und sogar schon den dafür nötigen Arbeitspaketen zugeordnet. Der Arbeitsaufwand und die Dauer werden erst im nächsten Schritt ermittelt. Das Gleiche gilt für die Vorgangstermine. Es wurde vergessen, die Projektleitung explizit zu benennen. Des Weiteren fehlt die Projektnummer. Der Projektname alleine kann zu Fehlern führen, da erfahrungsgemäß nicht immer die gleiche Bezeichnung verwendet wird und es bei inhaltlich ähnlichen Projekten daher zu Verwechselungen kommen kann. Als weiteres Manko kann man die unübersichtliche Nummerierung der Arbeitspakete nennen. Das Projekt wird wohl kaum eine vierstellige Zahl von Arbeitspaketen umfassen, so dass bei der Wahl dieser Nummer andere Informationen mitcodiert wurden. Für einen baumartig gegliederten

150

5 Strukturplanung

Abb. 5.13 AP-Beschreibung Beschaffung Solarmodule

Projektstrukturplan wäre eine untergliederte Codierung der Nummer sinnvoller als die hier verwendete dezimale Nummerierung. J

5.3.2

Vorgänge definieren

Die Ausführung eines Arbeitspakets stellt einen (kleinen) Prozess dar, bei dem aus dem Input in mehreren Arbeitsschritten das gewünschte Ergebnis erzeugt wird. Im Projektmanagement wird hierfür der etwas bürokratisch klingende Begriff des Vorgangs verwendet. Unter einem Vorgang versteht man also die Ausführung aller Arbeitsschritte eines Arbeitspaketes. Die Arbeiten erfordern einen bestimmten Aufwand, der im Rahmen der Projektplanung abgeschätzt werden muss. Jeder Vorgang nimmt eine gewisse Zeit in Anspruch, die durch den Aufwand und die Zahl der für die Arbeit eingesetzten Personen bestimmt wird. Bei der Ablaufplanung wird für jeden Vorgang bestimmt, welche anderen Vorgänge vorher erledigt sein müssen und für welche Vorgänge er vorausgesetzt wird. Die daran anschließende Terminplanung legt dann für jeden Vorgang einen frühestmöglichen und einen spätestmöglichen Anfangs- und Endtermin fest. Da Arbeitspakete und damit auch Vorgänge die unterste Ebene darstellen, die im Projektmanagement aktiv geplant und gesteuert wird, stellt sich die Frage nach dem geeigneten Umfang eines Arbeitspakets und damit nach der Dauer eines Vorgangs. Der ideale Arbeitsumfang und damit auch die ideale Dauer hängen von mehreren Faktoren

5.3 Vorgänge festlegen

151

ab. Aus fachlicher Sicht sollten in einem Arbeitspaket nur eng zusammenhängende Arbeiten gebündelt werden. Dies hat dann auch eine gewisse Nähe der benötigten fachlichen Qualifikationen zur Folge und damit auch eine Fokussierung auf wenige Personen. In erster Näherung wird man versuchen ein Arbeitspaket genau einer Person zuzuordnen. Wenn doch mehrere Personen im Arbeitspaket benötigt werden, muss auf jeden Fall eine Person die Verantwortung für das Paket tragen. Neben dem fachlichen Aspekt sind auch Management-Aufwand und -Wirksamkeit zu berücksichtigen. Damit der Planungs- und Steuerungsaufwand nicht zu groß wird, sollte der Umfang eines Arbeitspakets nicht zu klein sein. Als Untergrenze kann hier ein Personentag bzw. die Dauer von einem Tag genannt werden. Andererseits sollte der Umfang auch nicht zu groß werden. Hier besteht die Gefahr, dass während der Bearbeitung größere Abweichungen vom Plan auftreten, die das Projektmanagement nicht bemerkt. Bei unerfahrenen Zuständigen für das Arbeitspaket sollte daher die Vorgangsdauer kürzer gewählt werden. Als Obergrenze kann man einen Wert von etwa 20 Tagen ansehen. Zusammenfassend kann man die Bandbreite für die Vorgangsdauer auf 1 bis 20 Tage beziffern und die typische Dauer mit 5 Tagen ansetzen: die zuständige Person erhält den Auftrag für die Bearbeitung und meldet diese selbsttätig nach einer Woche als erledigt zurück. Selbst wenn Verzögerungen auftreten, so ist der Managementaufwand für ein solches Paket im erträglichen Rahmen.

Projektschätzung

Projekte sind per Definition neuartig und einmalig. Der erforderliche Aufwand für die Arbeitsleistungen, die Kosten für die benötigten Ressourcen und die Projektlaufzeit sind daher im Allgemeinen unklar. Da diese Informationen für die Planung eines Projekts aber unbedingt benötigt werden, müssen entsprechende Werte geschätzt werden. Die Qualität der Projektplanung steht und fällt mit der zutreffenden Schätzung des zu erwartenden Aufwands und der Laufzeiten. Zunächst werden methodische und einige mathematische Grundlagen des Schätzens behandelt. Sie ermöglichen es nicht nur, aus vorhandenen unsicheren Informationen belastbare Schätzwerte zu gewinnen, sondern sie erlauben auch Aussagen über deren Güte. Ein besonderes Augenmerk wird der Schätzung der zu erwartenden Projektdauer gewidmet. Abschließend wird exemplarisch die Schätzung des Aufwands bei SoftwareSystemen behandelt, bei der zahlreiche Untersuchungen durchgeführt wurden und viele praktische Erfahrungswerte dokumentiert sind.

Nach der Bearbeitung des Kapitels sind Sie in der Lage,  bei einer konkreten Schätzaufgabe die Vorteile einer intuitiven, einer vergleichenden und einer quantitative Schätzungen zu beurteilen,  die Qualität einer Schätzung zu verbessern, indem Sie die zu schätzende Größe zerlegen, indem Sie eine Schätzung in einer Personengruppe durchführen und indem Sie mehrere Schätzverfahren geeignet kombinieren,  die wichtigen Grundbegriffe der Wahrscheinlichkeitsrechnung zur mathematischen Handhabung von Ungewissheit zu benennen,  die Bedeutung von Wahrscheinlichkeit, Wahrscheinlichkeitsdichte- und -Verteilungsfunktionen zu erklären,

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 153 W. Jakoby, Projektmanagement für Ingenieure, https://doi.org/10.1007/978-3-658-32791-0_6

6

154

6

Projektschätzung

 in einer praktischen Schätzaufgabe mit Hilfe der Zweipunkt- und der Dreipunktschätzung nicht nur eine Aussage über einen Schätzwert, sondern auch über dessen Güte ermitteln,  die besondere Problematik bei der Schätzung der Projektdauer zu erläutern und aus vorliegenden Aufwandsschätzwerten eine belastbare Aussage über die Projektdauer zu gewinnen,  mit Hilfe des Cocomo-Schätzmodell anhand der Programmlänge den Aufwand zur Erstellung eines Software-Systems abzuschätzen,  die Besonderheiten individueller Projekte mit Hilfe von Korrektur-Parametern auszudrücken,  bei bekanntem Aufwand die optimale Teamgröße und die optimale Projektdauer zu bestimmen.

6.1

Methodische Grundlagen des Schätzens

6.1.1 Ziel des Schätzens Der Projektstrukturplan ist eine Liste mit allen im Projekt auszuführenden Arbeiten. Um daraus Aussagen über den Ablauf des Projekts, über die benötigten Ressourcen, über die verursachten Kosten, über den Zeitpunkt der Ausführung der Arbeiten, über die Dauer des Projekts und über den erreichbaren Fertigstellungstermin ableiten zu können, werden viele Informationen benötigt: der Zeitaufwand für die einzelnen Arbeitspakete, erforderliche Mengen an Material, Maschinen, Energien und sonstige Kosten. Absolut sichere Projektplanungen sind nur möglich, wenn die gesuchten Größen exakt bekannt sind. Da Neuartigkeit und Einmaligkeit aber wesentliche Projektmerkmale sind, stellt eine detailsichere Planung von Projekten eigentlich einen Widerspruch in sich dar. Aber auch die gegenteilige Schlussfolgerung, dass wegen der bestehenden Unsicherheit gar keine Aussage möglich sei, ist falsch. Projekte, bei denen keine Informationen vorliegen und keine Aussagen über den voraussichtlichen Bedarf gemacht werden können, sind eher selten. Lägen tatsächlich keinerlei Information vor, könnte man keine sinnvolle Aussagen über die gesuchten Größen machen und wäre auf ein Raten angewiesen. Die Genauigkeit bzw. Verlässlichkeit der Aussagen läge dann bei 0 % und wäre für eine Projektplanung unbrauchbar. Zwar entsteht in vielen Situationen der Eindruck, dass keine Informationen zur Verfügung stehen, aber fast immer ist diese Schlussfolgerung voreilig. Die Informationen sind nicht immer leicht zugänglich, vielleicht auch verdeckt oder nur über Umwege erreichbar. Es erfordert dann natürlich einen gewissen Aufwand, nicht offensichtlich ver-

6.1 Methodische Grundlagen des Schätzens 100%

Wissen

Informationen

155 sichere Aussagen fast sicher

Schätzen

0%

unsichere Aussagen

sehr unsicher Raten

keine Aussagen

Abb. 6.1 Gewinnung von Aussagen aus verfügbaren Informationen

fügbare Informationen zugänglich zu machen. Aber gerade dieser Aufwand macht aus einem unkalkulierbaren Vorhaben ein planbares und kontrollierbares Projekt. Das andere Extrem bilden Situationen, bei denen alle Informationen vollständig zugänglich sind. Das Wissen um die Situation ist hier genau und die Verlässlichkeit beträgt 100 %. Auch diese Situation ist seltener, als man glaubt. Zwischen diesen beiden Extremfällen liegen die Situationen, die Schätzen erforderlich machen. Die Aufgabe des Schätzens ist es also, aus mehr oder weniger unsicheren Informationen über einen Sachverhalt, nutzbare Aussagen zu gewinnen (Abb. 6.1). Die Aufgabe lässt sich in zwei Teile zerlegen, nämlich erstens, die verfügbaren Informationen zu finden und zweitens, aus den Informationen die richtigen Schlussfolgerungen zu ziehen. Auch wenn es nicht immer so aussieht: Es gibt kein Projekt, bei dem überhaupt keine Informationen verfügbar sind. Es liegen oft Erfahrungen aus ähnlichen Projekten vor, aus fachlich verwandten Aufgabenstellungen oder zumindest aus vergleichbaren Teilaufgaben. Diese Erfahrungen – seien es Erfahrungen der Projektbeteiligten oder Erfahrungen anderer – müssen zu Tage gefördert und genutzt werden. Partielle Ungewissheit, also weder vollständiges Unwissen noch vollständiges Wissen, ist ein Wesensmerkmal des Schätzens. Neben dem eigentlichen Schätzwert sollte daher auch immer versucht werden, eine Aussage über die Genauigkeit der Schätzung zu machen. Es ist nicht leicht, einen unbekannten Wert zu schätzen, aber noch schwerer ist es, eine Aussage über dessen Verlässlichkeit zu machen. Das Schätzen hat aber nicht nur einen mathematischen, sondern auch einen psychologischen Aspekt. Das Unbehagen, das Menschen empfinden, wenn sie zu einer Schätzung aufgefordert werden, liegt in der Ungewissheit begründet. Menschen wollen eigentlich präzise Aussagen machen oder gar keine. Sicher gibt es unendlich viele Ausreden, mit denen die Unmöglichkeit, einen Wert schätzen zu können, begründet wird. Bei der Planung zukünftiger Aktivitäten ist man aber auf Schätzungen angewiesen. Deshalb sollte die Scheu vor dem Schätzen genommen werden. Am ehesten gelingt dies, wenn einige grundlegende Kenntnisse über den Schätzvorgang, über die dabei oft gemachten Fehler und über deren Vermeidung vorhanden sind.

156

6

Projektschätzung

Eine weitere, erhebliche Hürde für die Bereitschaft, unsichere Größen zu schätzen, stellen „Bestrafungen“ für Fehlschätzungen dar. Aus Angst, einen geschätzten Zieltermin nicht einhalten zu können, wird oft ein erheblicher Sicherheitspuffer stillschweigend eingerechnet, um ihn garantiert einhalten zu können. Falls die geplante Arbeit dann vor dem zugesagten Termin fertig zu werden droht, wird sie so lange verschleppt, bis der Termin da ist, um nicht wegen einer zu großzügigen Schätzung in die Kritik zu geraten. Aus diesem Grund ist es notwendig Schätzungen systematisch und „stressfrei“ durchzuführen. Um Aussagen über den unbekannten Wert einer Größe gewinnen zu können, müssen zunächst Informationen über diese Größe gesucht und gesammelt werden. Die Informationen können sehr unterschiedlicher Art sein und unterschiedliche Aussagekraft besitzen. Eine wichtige erste Hilfe stellen Ober- und Untergrenzen für den möglichen Wertebereich einer unbekannten Größe dar. Am Anfang einer Schätzung muss es dabei gar nicht um eine sehr enge Eingrenzung gehen. Eine Abschätzung der Größenordnung mit Hilfe von Faktoren oder Zehnerpotenzen ist besser als gar keine Aussage. Eine weitere wichtige Informationsquelle können Hilfsgrößen sein, die auf die unbekannte Größe wirken, von ihr beeinflusst werden oder aber irgendwie mit ihr korreliert sind. Wenn Informationen über diese Hilfsgrößen zugänglich sind, lassen sich daraus auch Aussagen über die Suchgröße bestimmen. Können aus mehreren Hilfsgrößen Informationen gewonnen werden, verbessert das natürlich die Qualität der Schätzung. Beispiel 6.1 Landfläche der Erde

Gesucht ist die Landfläche der Erde. Bei weitem nicht jeder hat eine derartige Zahl parat. Sie kann aber ohne Hilfsmittel auf verschiedenen Wegen geschätzt werden. Bei Frage nach Landfläche der Erde werden bei spontaner Schätzung immer wieder Werte zwischen 100 Tsd. km2 und 1000 Mio. km2 genannt. Die große Spannweite dieser Werte (Faktor 104 ) zeigt die erhebliche Unsicherheit der Schätzung. Auffällig ist dabei die Häufung der Nennungen bei mehreren 100 Tsd. km2 und bei mehreren 100 Mio. km2 . Offensichtlich wird die Vorstellung „sehr groß“ in den Zahlenwert „mehrere 100“ umgesetzt und dann mit einer entsprechenden Dimension (bei den einen „Tausend km2 “ und bei anderen „Millionen km2 “) kombiniert. Steht dagegen mehr Zeit zur Verfügung, werden die genannten Schätzwerte in der Regel besser. Dabei werden verschiedene Überlegungen angestellt, um aus verfügbaren Kenntnissen die gesuchte Aussage abzuleiten. Flächen sind für den Menschen generell schlechter abschätzbar, als Entfernungen. Man kann daher versuchen, die Schätzung einer Fläche auf die Schätzung von Längen zurück zu führen. So könnte man z. B. die unbekannte Fläche von Deutschland aus der geschätzten Nord-Süd-Ausdehnung (1000 km) und der Ost-West-Ausdehnung (400 km) bestimmen (400.000 km2 ). Die jenseits der menschlichen Erfahrungs- und Vorstellungswelt liegende Fläche der Erde könnte man dann auf besser abschätzbare Größen, wie z. B. die Bevölkerungsdichte zurückführen.

6.1 Methodische Grundlagen des Schätzens

157

Bei 80 Mio. Einwohnern und einer (geschätzten) Fläche von 400 Tsd. km2 ist die Bevölkerungsdichte Deutschlands 200 Ew./km2 . Geht man davon aus, dass die weltweite Bevölkerungsdichte um einen Faktor 4 bis 10 geringer ist, als in Deutschland, kommt man bei 6 Mrd. Menschen bei der Landfläche auf Unter- und Obergrenzen von 120 bis 300 Mio. km2 . Die Bevölkerungsdichte könnte durch weitergehende Informationen von anderen Ländern präzisiert und eventuell auch in anderen Schätzaufgaben genutzt werden. Vor allem Teilnehmer aus dem technischen Bereich gehen einen anderen Weg. Sie nutzen Kenntnisse der Geometrie und des ungefähren Erdumfang (40 Tsd. km), um dann mit Hilfe einer Abschätzung des Landanteils eine Landflächenschätzung zu erstellen:  L D     d2 D    

U 

2 D 

U2 402  30 %  Mio. km2 D 160 Mio. km2 :  3

Ist der Erdumfang nicht bekannt, kann er eventuell aus anderen Informationen (z. B. dem Roman „In 80 Tagen um die Welt“ (80 Tage, 10 h/Tag, 50 km/h)) abgeleitet werden. J

6.1.2 Schätzmethoden Das Beispiel der Landfläche zeigt Grundprobleme des Schätzens unbekannter Größen, es zeigt aber auch einige Lösungsansätze. Es gibt eine ganze Reihe unterschiedlicher Methoden, um vorhandene, aber nicht direkt verfügbare („dunkle“) Informationen zugänglich zu machen und für eine Schätzung zu nutzen. Bei der intuitiven Schätzung äußern einzelne oder mehrere Personen ihre „gefühlte“ Einschätzung des untersuchten Sachverhalts. Die intuitiven Schätzwerte können begründet werden; sie müssen aber nicht. Je mehr Erfahrungen die beteiligten Personen zu dem Sachverhalt haben, desto besser und wirksamer kann eine intuitive Schätzung sein. Bei erfahrenen Schätzern ist es manchmal sogar so, dass die spontane Schätzung „aus dem Bauch heraus“ besser ist als eine, die sich erst nach langem Nachdenken ergibt. Allerdings ist dies nicht der Regelfall, sondern intuitive Schätzungen besitzen große Streuungen und Unsicherheiten. Die Schätzung wird zusätzlich dadurch erschwert, dass Fachleute oft ihr Fachgebiet zwar gut kennen, aber auf anderen Gebieten, insbesondere bei finanziellen oder zeitlichen Schätzungen große Fehler machen. Nicht-Fachleute liefern in vielen Fällen sogar Schätzwerte, die um mehrere Zehnerpotenzen auseinander liegen können. Im Beispiel der Landfläche reicht die Skala der in verschiedenen Kursen erhobenen Schätzwerte von 100 Tsd. km2 bis 1000 Mio. km2 ! Das ist zwar noch besser als gar keine Aussage, aber man sollte intuitive Schätzungen nur zur Eingrenzung der Werteskala nutzen. Bei der Projektschätzung kann eine intuitive Schätzung mit minimalem Aufwand eine grobe Vorstellung des zu erwartenden Aufwands in einer sehr frühen Planungsphase liefern.

158 Abb. 6.2 Qualitative Schätzung des Projektaufwands durch Vergleich

6

Projektschätzung

A7 A6 A5 A4 A3 A2 A1 P1

P2 P3 P4 P5 P6 P7

Bei einer vergleichenden Schätzung können Erfahrungen aus anderen Projekten herangezogen werden. Die Projekte werden aufsteigend nach dem Gesamtaufwand sortiert und in einer Skala dargestellt. In dieser Skala kann man dann versuchen, das neue zu schätzende Projekt einzuordnen (Abb. 6.2). Liegen Erfahrungen vor, ist diese vergleichende Anordnung mit Aussagen wie: „deutlich mehr Aufwand als P1“, „etwas weniger Aufwand als P6“, „vergleichbar mit P4“ oft leichter, als ein auf Zahlen basierendes Schätzen. Die vergleichende qualitative Schätzung kann nicht nur für ganze Projekte, sondern auch für einzelne Arbeitspakete durch Vergleich mit anderen, fachlich ähnlichen Arbeitspaketen angewandt werden. Die Einzelschätzungen können dann zu einer Gesamt-Projektschätzung zusammengefasst werden. Insofern kann die qualitative Schätzung eine hinreichende Basis für die Projektschätzung liefern. Voraussetzung sind aber auch hier Erfahrungen mit vergleichbaren Projekten. Daher sollten in jedem Projekt eine Nachbetrachtung und Auswertung der geschätzten und der tatsächlich benötigten Aufwendungen durchgeführt werden. Bei der quantitativen Schätzung wird der Einfluss verschiedener Parameter auf die zu schätzende Größe herangezogen. Beim Bau eines Gebäudes z. B. wirken sich dessen Größe sehr stark und das Ausstattungsniveau relativ stark auf die zu erwartenden Kosten aus. Ähnlich sieht es z. B. bei der Erstellung von Software-Systemen aus. Die zu erwartende Programmlänge wird im Wesentlichen den erforderlichen Aufwand bestimmen. Für eine schnelle, aber grobe Schätzung wird der Einfluss eines einzigen, dominierenden Parameters betrachtet. (6.1) A D C0  E0 Der Wert C0 ist dabei eine Kennzahl, die den Einfluss der Größe E0 auf den Aufwand beschreibt. Beispiele derartiger Kennzahlen findet man in allen praktischen Anwendungen, z. B. im Maschinenbau (10 C pro kg bei Stahlkonstruktionen), bei Immobilien (400 C pro m3 umbauter Raum) oder bei der Software-Erstellung (3 Personenmonate pro 1000 Programmzeilen).

6.1 Methodische Grundlagen des Schätzens

159

Beispiel 6.2 Gebäudekostenschätzung

Die folgende Tabelle zeigt die Kosten und Nutzflächen einiger unterschiedlicher Gebäude. Gebäude Taipeh 101, Hochhaus (1999–2004) Burj Dubai, Hochhaus (2004–2010) Dom Aquaree, Hotel, Berlin (2003) Messeturm Frankfurt (1988–1990) Kanzleramt, Berlin (1997–2001) Klinikum Frankfurt-Höchst (2016–2021) Einfamilienhaus

Nutzfläche 412 Tsd. m2 517 Tsd. m2 67 Tsd. m2 61 Tsd. m2 19 Tsd. m2 34,5 Tsd. m2 150 m2

Kosten 1600 Mio. C 1400 Mio. C 340 Mio. C 250 Mio. C 250 Mio. C 263 Mio. C 450 Tsd. C

Kosten/m2 3900 C 2700 C 5100 C 4000 C 13.100 C 7600 C 3000 C

Auch wenn die Kosten pro m2 Wohn- bzw. Nutzfläche um einen Faktor 6,5 auseinander liegen, ist dieser Unterschied lange nicht so groß, wie man es bei den sehr unterschiedlichen Gebäudearten und -größen erwarten würde. Die Kennzahl „Kosten pro m2 Nutzfläche“ kann also sicherlich als wichtiger Faktor zur Kostenschätzung von Gebäuden genutzt werden. Führt man noch weitergehende Unterscheidungen ein, wie z. B. Wohnhäuser 2000 C/m2 , Hotels 4000 C/m2 , Prestigebauten mit öffentlichen Geldern 12.000 C/m2 , lässt sich die Kostenschätzung weiter präzisieren und treffsicherer gestalten. J Natürlich kann eine einparametrische Schätzung nur sehr grob sein. Sie muss dann durch weitere Parameter verfeinert werden, z. B. indem verschiedene multiplikative Faktoren den Wert nach oben oder unter korrigieren. Im Allgemeinen liefert die Schätzung mit Hilfe einer einzigen Kennzahl und möglichen Korrekturfaktoren ein schnelles, aber grobes Ergebnis. Für eine genauere Schätzung ist es notwendig weitere Einflussparameter zu suchen und deren Einfluss zu berücksichtigen. Am einfachsten ist es, wenn der Aufwand als Linearkombination mehrerer Einflussparameter berechnet werden kann. X Ci  Ei (6.2) AD i

Die Stärke des Einflusses der einzelnen Parameter Ei wird dann durch die Koeffizienten Ci bestimmt. Sie bilden ein System von Kennzahlen, die aus eigenen oder fremden Erfahrungen resultieren können. Beispiel 6.3 Kalkulationsschema für Entwicklungskosten

Bei einem Hersteller programmierbarer elektrischer Messgeräte ergaben sich bei der Schätzung neuer Entwicklungsprojekte immer wieder sehr große Schätzfehler. Um die Ursachen hierfür zu finden und den Schätzvorgang zu systematisieren wurden eine ganze Reihe abgeschlossener Entwicklungsprojekte analysiert.

160

6

Projektschätzung

Tab. 6.1 Kalkulationsschema für Entwicklungskosten Projektmanagement Analyse Entwurf Gehäuse E1  0,10 E1  0,25 Elektronik E2  0,10 E2  0,25 Programm E3  0,15 E3  0,20

Realisierung Test

Dokumentation Summe

E1 E2 E3

E1  0,25 E2  0,40 E3  0,30

E2  0,75 E3  0,85

E1  1,6 E2  2,5 E3  2,5

Die durchgeführten Projekte bestanden fast immer aus einem mechanischen Teil (Gehäuse mit allen Ein- und Anbauten), Elektronik und Software. Die Projekte setzten sich im Wesentlichen aus den Projektphasen Aufgabenanalyse, Systementwurf, Realisierung und Test zusammen. Außerdem waren die durchgängigen Arbeiten des Projektmanagements sowie der Dokumentation beim Aufwand zu berücksichtigen. Beim Vergleich des vorhergesagten und des tatsächlich benötigten Aufwands zeigten sich zwei wichtige Effekte. Erstens war die Diskrepanz bei den Arbeiten der Realisierungsphase recht gering. War eine Schaltung bekannt, konnte der Aufwand für das Layouten, Herstellen und Bestücken der Platine recht gut vorhergesagt werden. Das Gleiche galt für die Konstruktion von Gehäusen und die Software-Erstellung. Zweitens zeigte sich, dass zwischen den zentralen Realisierungsarbeiten des Projekts und den anderen Arbeiten eine auffällige Korrelation bestand. Aus diesen beiden Beobachtungen wurde dann das folgende Schätzmodell erarbeitet. Zu Beginn eines Projekts wird der Realisierungsaufwand E1 für die Gehäusekonstruktion, der Aufwand E2 für die Realisierung der Elektronik und der Aufwand E3 für die Programmierung geschätzt. Mit Hilfe der Kennwerte, die aus der Auswertung abgeschlossener Projekte stammen, kann dann der Aufwand für die übrigen Arbeiten des Projekts und für das Gesamtprojekt hochgerechnet werden (Tab. 6.1). AD

X

Ci  Ei D 1;6  E1 C2;5  E2 C 2;5  E3

(6.3)

i

Bei einem Projekt mit E1 = 30 PT, E2 = 60 PT und E3 = 70 PT beispielsweise ergibt sich ein Gesamtaufwand von A = 403 PT, also etwa 20 Personenmonaten. Der Aufwand für die Arbeiten eines konkreten Projekts, die von den Mitarbeitern gut geschätzt werden können, wird also mit Erfahrungswerten für die schwerer zu schätzenden oder oft vergessenen Arbeiten kombiniert und zu einer verlässlichen Basis für das Gesamtprojekt zusammengefasst. J Ein anderer wichtiger Spezialfall ist die Zerlegung der Suchgröße. Setzt sich diese aus einer Summe einzelner Anteile zusammen, so ist es sinnvoll, zunächst die Einzelkomponenten Ai zu schätzen und dann die Schätzwerte zu summieren. Durch die Überlagerung positiver und negativer Abweichungen ist die Schätzgüte für die Gesamtgröße in der Regel

6.1 Methodische Grundlagen des Schätzens

161

besser, als die Güte der Einzelschätzungen. AD

X

Ai

(6.4)

i

Im Rahmen von Projekten bietet es sich an, den Produktstrukturplan, der ja die Zusammensetzung eines Produkts aus einzelnen Komponenten darstellt, zur Schätzung der Produktkosten heran zu ziehen. Zunächst werden die Kosten für jede Komponente einzeln geschätzt. Die Summe der Einzelkosten ergibt dann die Gesamtproduktkosten. Sofern kein systematischer Schätzfehler vorliegt, der alle Einzelschätzungen in der gleichen Weise verfälscht, ist die Gesamtschätzung genauer als die Einzelschätzungen. In gleicher Weise kann der aus vielen einzelnen Arbeitspaketen bestehende Projektstrukturplan zur Schätzung des Projektaufwands genutzt werden. Hier wird der Zeitaufwand für jedes Arbeitspaket geschätzt und dann zum Gesamtaufwand summiert. Beispiel 6.4 Fallbeispiel „Solaranlage“: Schätzung des Arbeitsaufwands

Für das Fallbeispiel „Solaranlage“ soll der Personalaufwand geschätzt werden. Dies ist zunächst recht schwierig, da viele Arbeiten auszuführen sind. Die Aufgabe wird einfacher, wenn man die einzelnen Arbeitspakete detailliert auflistet. Einzelne, kleinere Arbeitspakete sind einfacher zu schätzen, da hier eher Erfahrungswerte vorliegen, als bei komplexen, zusammengesetzten Arbeiten. Zudem verringert sich durch das Auflisten der Arbeiten, die Gefahr, bestimmte Arbeiten komplett zu vergessen. Der in Abb. 6.3 dargestellte Screenshot zeigt einen Ausschnitt des Projektstrukturplans, bei dem die Arbeiten des Teilprojekts „Aufbau der Solaranlage“ einzeln geschätzt wurden. J Als weitere Maßnahme zur Verbesserung der Schätzqualität kann man verschiedene Schätzwege miteinander kombinieren. Dadurch fällt ein Fehler, den man bei einem Ansatz gemacht hat, bei einem anderen Ansatz auf und kann entweder eliminiert oder korrigiert werden. Außerdem wird durch die Kombination verschiedener Schätzansätze der mögliche Wertebereich weiter eingeschränkt und die Aussage über den wahrscheinlichen Wertebereich gefestigt. Im Beispiel der Landfläche der Erde wurde die Schätzung über

Abb. 6.3 Screenshot des Projektstrukturplans „Solaranlage“

162

6

Projektschätzung

die Kugelgeometrie mit der Schätzung über die Bevölkerungsdichte kombiniert, um die Zuverlässigkeit der Aussage zu erhöhen. Für die Qualität einer Schätzung, hat die Frage wer schätzt, erheblichen Einfluss. Sinnvoll ist es natürlich, wenn für eine Schätzung Experten, also Personen mit Erfahrungen in dem abzuschätzenden Gebiet herangezogen werden können. Eine Verbesserung gegenüber der Schätzung einer einzelnen Person ist dann zu erzielen, wenn mehrere unabhängig voneinander schätzen und dann die Ergebnisse gemittelt werden. Werden in einer Gruppe von jedem Gruppenmitglied unabhängig von den anderen je ein Suchwert geschätzt und die Werte anschließend gemittelt, so ist der Gruppenschätzwert im Allgemeinen besser als die Einzelschätzwerte: Die Gruppe schätzt besser als der Einzelne. Dies gilt allerdings nur dann, wenn das Qualifikationsniveau der Gruppenmitglieder im Fachgebiet etwa gleich gut (oder gleich schlecht) ist. Ein einzelner Experte schätzt dagegen besser als eine Gruppe von Laien. Noch bessere Ergebnisse können nach der so genannten Delphi-Methode erzielt werden. Bei diesem, von der Rand-Corporation in den 1960er Jahren erprobten Verfahren erstellen mehrere Experten zunächst unabhängig voneinander Schätzwerte. Diese werden dann den anderen Schätzern präsentiert und begründet. Eine Diskussion der persönlichen Schätzwerte muss nicht stattfinden. Es geht also nicht darum, in der Gruppe andere zu überreden, sondern nur eigene Gedankengänge offen zu legen. Erläutert jedes Gruppenmitglied die Überlegungen, die zu seinem Schätzwert geführt haben, erkennen andere eventuell falsche eigene Einschätzungen und können die eigene Schätzung korrigieren. Danach schätzt jedes Gruppenmitglied noch einmal und der dann gemittelte Wert bildet das Ergebnis. Ähnlich gestaltet sich der Ablauf einer Schätzklausur. Auch hier erstellen Experten zunächst selbständig eine Schätzung und diskutieren diese dann miteinander, um dann zu einem gemeinschaftlich getragenen Ergebnis zu kommen. In Tab. 6.2 sind die Merkmale der verschiedenen Schätzmethoden gegenübergestellt.

6.1.3 Bedingungen des Schätzens Die vorangehende Beschreibung umfasst Methoden, die ein systematisches Finden und Nutzen von Informationen ermöglichen. Sie zeigt aber auch, dass eine Schätzung nie eindeutig sein kann. Es gibt immer mehrere, meist sogar viele mögliche Werte. Der Aufwand kann dabei zwischen den einzelnen Methoden sehr unterschiedlich sein. Schnelle, unsichere Schätzungen können nur durch Mehraufwand verbessert werden. Je besser, d. h. je zuverlässiger ein Schätzergebnis sein soll, desto höher ist der erforderliche Aufwand. Daher kombiniert man in der Praxis einfache Schätzverfahren, die eine erste, grobe Aussage liefern, mit aufwändigeren Verfahren, um die Sicherheit der Schätzung zu steigern. Damit stellt sich natürlich die Frage, welcher Aufwand in einem Projekt für die Schätzung getrieben werden sollte. Die Antwort hierauf kann nur die angestrebte Schätzgenauigkeit geben. Je höher die gewünschte Genauigkeit, desto höher der Aufwand. Genaue

6.1 Methodische Grundlagen des Schätzens

163

Tab. 6.2 Gegenüberstellung verschiedener Schätzmethoden Schätzmethode Intuitiv Vergleichend Kennzahlen Zerlegen Kombinieren Gruppe

Beschreibung Minimaler Aufwand, sehr große Unsicherheit Einfach, Unsicher Steigender Aufwand, steigende Sicherheit Bei gleicher Einzel-Unsicherheit steigt die Gesamt-Sicherheit Unterschiedliche Wege nutzen Die Gruppe schätzt besser als der Einzelne

Zahlen für diesen Zusammenhang hängen zwar vom konkreten Projekt ab, aber die in Abb. 6.4 dargestellte Grafik soll zumindest einen groben Anhaltspunkt geben. Wird nur geringer Schätzaufwand betrieben (z. B. 1 % des voraussichtlichen Gesamtaufwands) ist die Unsicherheit groß (z. B. 25 bis +75 %). Dementsprechend unsicher ist dann der Verlauf des Projekts und der am Ende aufgelaufene Aufwand. Die Erhöhung des Schätzaufwands (auf z. B. 5 %) erhöht dann die Verlässlichkeit des Verlaufs. Die Aufwandsschätzung ist eine der schwierigeren Aufgaben in einem Projekt. Dies rührt zum einen aus den Projektcharakteristiken Einmaligkeit und Komplexität. Zum anderen gibt es aber auch menschlich bedingte Fehler. Die Schätzung des voraussichtlichen Arbeitsaufwands führt die beteiligten Personen in einen Zwiespalt. Einerseits besteht eine generelle Tendenz, den Aufwand zu niedrig zu schätzen. Dies gilt vor allem bei neuen Themen oder bei Mitarbeitern, die selten schätzen. Eine weitere Ursache ist die zu frühe Berücksichtigung knapper Ressourcen oder enger Terminpläne. Bei der Durchführung liegt durch eine optimistische, d. h. zu knappe Aufwandsschätzung die Messlatte für die zu erbringende Leistung sehr hoch. Daher wird oft auch versucht, den Aufwand sehr hoch anzusetzen, um die versprochene Leistung auch sicher erbringen zu können.

Abb. 6.4 Zusammenhang Schätzaufwand/Schätzgenauigkeit

164

6

Projektschätzung

Ist man an realistischen Schätzungen interessiert, sollten beide Effekte minimiert werden. Dies lässt sich unter dem Schlagwort motivationsfreie Schätzung und schätzungsfreie Motivation zusammenfassen. Bei der Schätzung sollte das alleinige Ziel sein, ohne Furcht vor Repressalien möglichst verlässliche Werte zu bestimmen. Die Motivation für die gute Durchführung der Arbeit sollte dagegen nicht aus den Schätzwerten abgeleitet werden.

6.2 Mathematische Grundlagen des Schätzens 6.2.1 Wahrscheinlichkeitsrechnung Die vorangehende Beschreibung der methodischen Grundlagen des Schätzens verzichtet fast vollständig auf die Nutzung mathematischer Werkzeuge. Sie hat gezeigt, dass es keinen eindeutig „richtigen“ Schätzwert geben kann, sondern viele mögliche Schätzwerte, die mehr oder weniger wahrscheinlich sind und oft auch sehr viele andere Werte, die mehr oder weniger unwahrscheinlich sind. Um derartige vage Aussagen zu präzisieren und belastbar zu machen, kommt man nicht um einige mathematische Methoden der Statistik und der Wahrscheinlichkeitsrechnung herum. Mathematisch kann eine unbekannte Größe, deren Wert geschätzt werden soll, als Zufallsvariable X dargestellt werden. Die Verteilungsfunktion F .x/ D P .X  x/ beschreibt, mit welcher Wahrscheinlichkeit P die Variable X einen Wert kleiner gleich x annimmt. Die Wahrscheinlichkeit beginnt bei 0 (0 %), sie steigt stetig an, bis sie einen Wert von 1 (100 %) erreicht. Die Ableitung der Verteilungsfunktion ist die Dichtefunktion p.x/ D P .X D x/ D F 0 .x/. Sie beschreibt, mit welcher Wahrscheinlichkeit der Wert x angenommen wird (Abb. 6.5). In dieser Darstellung besteht das Gewinnen von Informationen über die Größe X aus der Bestimmung der Verteilungsfunktion F(x) bzw. der Dichtefunktion p(x). Daraus können dann Aussagen über einen geeigneten Schätzwert und über die Güte dieses Schätzwertes gewonnen werden. Anschaulich gesprochen liegt der geeignete Schätzwert irgendwo „in der Mitte“ der Dichtefunktion und die Breite der Dichtefunktion ist ein Maß für die Unsicherheit: Je schmaler die Dichtefunktion, desto besser ist die Schätzung. Die beiden Grenzfälle des Schätzens, nämlich das „Wissen“ und das „Raten“ haben daher ganz cha-

F(x) Schätzen

1

Wissen p(x) Min

Max

Raten x

Abb. 6.5 Verteilungsfunktion F(x) und Dichtefunktion p(x) einer Variablen x

6.2 Mathematische Grundlagen des Schätzens

165

rakteristische Dichtefunktionen. Beim „Wissen“ hat die Dichtefunktion an einer einzigen Stelle den Wert 1 und beim „Raten“ geht die Dichtefunktion überall gegen 0. Die Verteilungsfunktion bzw. die Wahrscheinlichkeitsdichtefunktion einer zu schätzenden Größe enthält alle verfügbaren Informationen. Sie erlaubt eine Aussage über die möglichen Werte und über die Auftretenswahrscheinlichkeit. Trotzdem versteht man in praktischer Hinsicht unter einem „Schätzwert“ nicht eine Dichtefunktion, sondern einen einzigen Wert. Dieser kann mit Hilfe verschiedener Kennwerte aus der Dichtefunktion gewonnen werden. Recht anschaulich ist der Schwerpunkt der Fläche zwischen der Dichtefunktion und der x-Achse. Dies ist der so genannte Erwartungswert E: Z E D Efxg D

x  p.x/dx 

X

xi  p.xi /:

(6.5)

i

Ein anderer Kennwert ist der Median M. Er wird so bestimmt, dass die Fläche links vom Median, gleich der Fläche rechts vom Median ist: ZM

Z1 p.x/dx D

1

p.x/dx D 0;5:

(6.6)

M

Ein dritter Kennwert, der als Schätzwert dienen kann, ist der Wert W mit der höchsten Wahrscheinlichkeit: (6.7) p.x/jxDW D Max: Alle drei Kennwerte kommen als Schätzwerte in Frage. Bei symmetrischen Dichtefunktionen sind sie gleich, so dass sich eine Entscheidung für einen der drei Werte erübrigt. Bei unsymmetrischen Dichtefunktionen, kann es aber Unterschiede zwischen den drei Werten geben, so dass eine Entscheidung für einen der Kennwerte als Schätzwert notwendig ist. Neben einer Aussage eines geeigneten Schätzwertes, erlaubt die Dichtefunktion auch eine Aussage über dessen Sicherheit. Je breiter der Wertebereich und je höher die Dichtefunktion an den Rändern, desto unsicherer ist auch der Schätzwert. Als geeignete Kennwerte kommt die Varianz V bzw. die Standardabweichung S in Frage: Z V D Ef.x  E/ g D 2

.x  E/2  p.x/dx 

X

.xi  E/2  p.xi /;

(6.8)

i

SD

p

V:

(6.9)

Beispiel 6.5 Schätzung einer Projektdauer (1)

Die voraussichtliche Dauer eines Projekts ist eine der interessantesten Größen im Projektmanagement und deren Schätzung gleichzeitig eine der schwierigsten Aufgaben.

166

6

Projektschätzung

Abb. 6.6 Dichtefunktion der Projektdauer (in Tagen)

Zwischen verschiedenen Projektbeteiligten gehen die Meinungen oft sehr weit auseinander. Im vorliegenden Beispiel wurden 8 Projektbeteiligte zunächst unabhängig voneinander befragt. Jeder Projektteilnehmer, konnte mehrere geschätzte Laufzeiten (in Tagen) angeben und mit insgesamt 20 Punkten gewichten. Anschließend konnten sich die Teilnehmer untereinander besprechen und ihre Schätzungen abändern. Das Diagramm in Abb. 6.6 zeigt das zusammengefasste Ergebnis aller Schätzungen als Dichtefunktion. Als kleinster Wert wurden 20, als größter Wert 50 Arbeitstage genannt. Aus der Dichtefunktion konnten folgende Kennwerte bestimmt werden: Wahrscheinlichster Wert Median Erwartungswert Standardabweichung

6.2.2

W = 28,0 Tage, M = 30,8 Tage, E = 32,0 Tage, S = 5,9 Tage. J

Verteilungsfunktionen

Für die praktische Schätzung gibt es einige spezielle Dichtefunktionen, die entweder aufgrund ihrer Einfachheit oder ihres häufigen Vorkommens große Bedeutung besitzen. Sie sind in Abb. 6.7 dargestellt. Bei der Gleichverteilung geht man davon aus, dass der Wertebereich durch einen minimalen Wert (a) und einen maximalen Wert (b) eingegrenzt ist. Die dazwischen liegenden

Abb. 6.7 Gleichverteilung (I), Dreieck-Verteilung (II) und Beta-Verteilung (III)

6.2 Mathematische Grundlagen des Schätzens

167

Werte werden als gleich wahrscheinlich angenommen, so dass die Dichtefunktion einen rechteckförmigen Verlauf besitzt. Die vielfache Verwendung der Gleichverteilung beruht weniger auf deren tatsächlichem Vorkommen, als darauf, dass mangels besseren Wissens gleich wahrscheinliche Werte angenommen werden. In vielen praktischen Fällen, sind die Werte am Rande des Wertebereichs weniger wahrscheinlich und die Werte in der Mitte wahrscheinlicher. In einfacher Form gibt die Dreiecksverteilung diesen Sachverhalt wieder. Hier werden drei Werte benötigt: der minimale (a), der maximale (b) und der wahrscheinlichste Wert c. Werden Größen geschätzt, die einseitig begrenzt sind, ergeben sich meist schiefe Verteilungen. Dies ist insbesondere bei Aufwands- oder Kostenschätzungen in Projekten der Fall. Der Aufwand bzw. die Kosten für ein Projekt, für eine Teilprojekt oder ein Arbeitspaket können keine negativen Werte annehmen, kleine und mittlere positive Werte sind dagegen recht wahrscheinlich, während große positive Werte mit geringer und sehr große Werte mit verschwindender Wahrscheinlichkeit auftreten. Man kann derartige Verteilungen z. B. durch eine schiefe Dreieckverteilung approximieren. Eine präzisere Modellierung erlauben Betaverteilungen: p.x/ D

1 .x  a/r1  .b  x/s1 : B

(6.10)

Dabei ist B ein konstanter, normierender Faktor, der mit Hilfe der Beta-Funktion aus den Parametern a, b, r und s berechnet werden kann. Eine in Theorie und Praxis gleichermaßen große Bedeutung besitzt die so genannte Normalverteilung (Abb. 6.8). Bei ihr besitzen die Werte in der Mitte eine noch größere und die Werte am Rande eine noch geringere Wahrscheinlichkeit. Die Normalverteilung besitzt einen charakteristischen, als Gauß’sche Glockenkurve bezeichneten Verlauf. Die große Bedeutung der Normalverteilung rührt aus dem zentralen Grenzwertsatz: Die Summe von n unabhängigen, beliebig verteilten Zufallsvariablen besitzt eine Verteilungsfunktion, die sich mit steigender Zahl n immer mehr der Normalverteilung annähert. Dies hat eine ganz erhebliche praktische Bedeutung. Setzt man z. B. eine Projektschätzung aus vielen Teilschätzungen zusammen, so ist die Gesamtschätzung, unabhängig von den

Abb. 6.8 Normalverteilung (Erwartungswert Te, Standardabweichung Ts)

p(T) 0,4 0,3 0,2 0,1 0,0 -3Ts

-Ts

Te

+Ts

+3Ts

T

168

6

Abb. 6.9 Bestimmung der Wahrscheinlichkeit P(x,z) bei der Normalverteilung

Projektschätzung

P(x=E+z*S)

P(x 10%)

Abb. 8.2 Risk-Map: Eintrittswahrscheinlichkeit p, Schadensausmaß S

Risikoparameter sowieso schon 30 oder gar 50 % beträgt. Die mit dieser groben Schätzung klassifizierten Risiken können als gleichwertig angesehen werden. Trägt man für ein konkretes Projekt die bestehenden Risiken in der Risk-Map ein, erhält man das so genannte Risiko-Portfolio. Kann auch der ungefähre Wert eines Risikoparameters nicht angegeben werden, helfen Risikographen (Tab. 8.2). Hier wird für jeden Risikoparameter eine Klassenbildung der Werte vorgenommen. Das Schadensausmaß kann in Relation zur Projektgröße z. B. in 4 Klassen eingeteilt werden. Die Kombination der beiden Parameter führt dann zu einer Risikoklasse. Verglichen mit der Risk-Map ist ein Risikograph nichts anderes, als eine Einteilung der beiden Achsen und eine anschließende Klassenbildung im Diagramm. Eine weitere Möglichkeit zur Risiko-Klassifizierung ist die Projekt-FMEA (FehlerMöglichkeits- und Einfluss-Analyse). Bei diesem Verfahren wird jedes Arbeitspaket des Projektstrukturplans auf mögliche Fehlerquellen untersucht. Danach wird versucht, den negativen Einfluss, den die Fehlerquelle auf die Arbeit haben könnte, zu analysieren. Wie bei der Risk-Map und dem Risikographen wird bei einer FMEA die Auftrittswahrscheinlichkeit pA und das Schadensausmaß S geschätzt. Zusätzlich wird die Entdeckungswahrscheinlichkeit pE bestimmt. Sie macht eine Aussage darüber, wie wahrscheinlich es ist, dass das Eintreten des Fehlerfalls erkannt wird. Die drei Größen werden auf einer Skala von 1 bis 10 bewertet. Dabei läuft die Skala bei der Auftretenswahrscheinlichkeit und beim Schadensmaß von „gering“ bis „hoch“ und bei der Entdeckungswahrscheinlichkeit von „hoch“ bis „gering“. Die drei Parameter werden dann multiplikativ zur Risikoprioritätszahl RPZ zusammengefasst. Sie ist ein Maß für das Risiko. Die Risikoprioritätszahl kann theoretisch zwischen 1 (alle drei Faktoren sind 1) und 1000 liegen (alle drei Faktoren haben den

212

8

Risikomanagement

Tab. 8.2 Bestimmung von Risikoklassen Schadensausmaß Eintrittswahrscheinlichkeit Scheitern des Projekts (Katastrophe: bis zu 100 % der Gesamtkosten) wenig oder ziemlich wahrscheinlich unwahrscheinlich sehr unwahrscheinlich Erhebliche Kosten (Notfall: z. B. 10–30 % der Gesamtkosten) sonst sehr unwahrscheinlich Moderate Mehrkosten (Störung z. B. 3–10 % der Gesamtkosten) sonst unwahrscheinlich sehr unwahrscheinlich Geringe Mehrkosten (z. B. weniger als 3 % der Gesamtkosten) sonst unwahrscheinlich

Risikoklasse A B C B C C D E D E

Tab. 8.3 Bestimmung der Risikoprioritätszahl Wahrscheinlichkeit

A

E

Budget- oder Terminüberschreitung

B

unwahrsch.

1

10

25 %

8, 9

2, 3

> 50 %

8, 9

sehr hoch

>50 %

10

1

Scheitern des Projekts

10

A: Auftrittswahrscheinlichkeit, E: Entdeckungswahrscheinlichkeit, B: Bedeutung

Wert 10). Als unkritisch werden Risiken mit einem Wert unter 40 gesehen. Risiken mit Werten über 100 sind dagegen kritisch und müssen durch geeignete vorbeugende Maßnahmen verringert werden. Beispiel 8.3 Projekt-FMEA für das Fallbeispiel Maschinenterminal

Um im Projekt „Maschinenterminal“ eine FMEA für die verschiedenen Risikofaktoren durchführen zu können, wurden die Auftritts- und Entdeckungswahrscheinlichkeiten sowohl qualitativ als auch quantitativ in verschiedene Stufen eingeteilt. Die Bedeutung eines Risikos wurde anhand der Budget- oder Terminüberschreitung klassifiziert (Tab. 8.3). Basierend auf diesen Werten konnten dann die Risikofaktoren untersucht und bewertet werden. Einen Auszug zeigt Tab. 8.4. Aufgrund der Risikoprioritätszahl wird die Kündigung des Mitarbeiters als kritischer Faktor eingestuft, für den vorbeugende

8.2 Der Risikomanagement-Prozess

213

Tab. 8.4 Ergebnis der FMEA (Auszug) Indikatoren und Bedeutung der Risikofaktoren Risikofaktor: Wichtiger Projektmitarbeiter kündigt Indikator: Verändertes Verhalten Bedeutung: Terminüberschreitung um ca. 10–15 % Risikofaktor: CPU wird abgekündigt Indikator: Rechtzeitige Mitteilung des Herstellers Bedeutung: Umsteigen auf Ersatztyp, Mehrkosten ca. 10 % Risikofaktor: Benutzerschnittstelle wird nicht akzeptiert Indikator: Reklamationen bei Präsentation bzw. Probebetrieb Bedeutung: Re-Design, Zeitverlust 10 %, Mehrkosten 10 %

A, E, B A=6 E=7 B=4 A=3 E=4 B=2 A=7 E=2 B=5

RPZ 168

24

70

Maßnahmen notwendig sind. Die Abkündigung der CPU ist unkritisch, da von vorneherein ein Ersatztyp vorgesehen ist. Bei der Benutzerschnittstelle wird das Risiko verringert, indem zu Projektbeginn ein Prototyp erstellt und dem Auftraggeber zur Begutachtung vorgestellt wird. J

8.2.3 Risiko-Behandlung Die Risiko-Identifikation liefert eine Liste mit risikobehafteten Ereignissen und deren schädlichen Wirkungen auf die Erreichung der Projektziele. Die Risiko-Bewertung macht Aussagen über die Eintrittswahrscheinlichkeit der Ereignisse und das Schadensausmaß. Diese Aussagen können als Risikoklassen grober, qualitativer Art oder als Wahrscheinlichkeitswerte und Schadenshöhe genau quantifiziert sein. Auf jeden Fall liegt nach den ersten beiden Schritten des Risikomanagementprozesses eine nach der Schwere der Risiken priorisierte Liste der Risikofaktoren vor. Liegt das Gesamtrisiko im Projekt über einem akzeptablen Wert, muss es verringert werden. Dazu müssen die gravierenden Risiken einzeln attackiert werden. Man kann dazu, die Eintrittswahrscheinlichkeit des schädlichen Ereignisses oder das Schadensausmaß verringern. Es ist wenig hilfreich, zu glauben, jedes Schadensereignis auf jeden Fall verhindern zu können. Es ist schon viel gewonnen, wenn es gelingt, die Risikoparameter um eine Klasse zu senken. Ein Notfall kann so zu einer Störung werden und eine Katastrophe „nur noch“ zu einem Notfall. Zugleich ist es notwendig, sich nicht nur mit dem theoretisch Wünschenswerten, sondern auch mit dem praktisch Machbaren auseinander zu setzen. Dies kann man sich wie eine Treppe vorstellen, die „risk reduction stair“ (Tab. 8.5). Die einzelnen Stufen dieser Treppe können den Risikoklassen zugeordnet werden: Je höher das Risiko, desto höher muss auch das Ziel sein. Risikoereignisse der höchsten Kategorie – Projektkatastrophen – müssen verhindert werden (avoid). Dieses Ziel bildet die oberste Stufe der Treppe. Geringer eingestufte Ri-

214

8

Risikomanagement

Tab. 8.5 Risk reduction stair Klasse A B C D

Ziel Avoid Mitigate Limit Transfer

E

Accept

Bedeutung für das Risiko Risiko verhindern: Schaden oder Eintritt auf Null senken! Risiko lindern: Wahrscheinlichkeit verringern, Schaden minimieren. Risiko begrenzen: eine obere Grenze für den Schaden sicherstellen. Risiko übertragen: z. B. aus einem finanziellen einen zeitlichen Schaden machen. Risiko akzeptieren (. . . and look on the bright side of life).

siken – Notfälle, Störungen – versucht man zu lindern (mitigate), zu begrenzen (limit) oder zu übertragen (transfer). Risiken der niedrigsten Kategorie werden akzeptiert (accept), um den Aufwand minimal zu halten. In die gleiche Richtung weist auch die alarpStrategie (as low as reasonably practicable): die Projekt-Risikoreduzierung sollte nur so weit getrieben werden, wie es aus praktischen Gesichtspunkten vertretbar ist. Das Prinzip unterstreicht noch einmal die enge Beziehung zwischen Risikoverringerung und dem dazu erforderlichen Aufwand. Jeder Risikofaktor erfordert natürlich seine eigenen individuellen Maßnahmen. Dennoch gibt es einige grundlegende Gemeinsamkeiten bei den Faktoren und bei den Maßnahmenkatalogen. Eine wichtige Fehlerquelle ist das Vergessen von Anforderungen im Lastenheft. Dieses Risiko kann durch eine gründliche Analyse der Aufgabenstellung und durch sorgfältige Zusammenstellung des Pflichtenhefts gemindert werden. Schon dadurch, dass zwei Beteiligte, nämlich Auftraggeber und Auftragnehmer, getrennt über die Problemstellung nachdenken, wird höhere Sicherheit erreicht. Allerdings muss das „Nachdenken“ auch seinen schriftlichen Niederschlag finden. Nur weil etwas nicht im Pflichtenheft steht, heißt das noch lange nicht, dass es auch nicht erbracht werden muss. Die Diskussion darüber setzt dann ein, wenn man sie gar nicht gebrauchen kann, nämlich gegen Ende des Projekts. Im Zweifelsfall ist es besser, eine eventuell nahe liegende, aber nicht benötigte Anforderung im Pflichtenheft explizit auszuschließen, als sie unausgesprochen im Raum stehen zu lassen. Alle Schätzungen, die zur Planung von Aufwänden, Kosten und Terminen gemacht werden, sind potentielle Risikofaktoren. Schätzungen sind per se unsicher. Maßnahmen, die zur Verringerung der Unsicherheit und damit auch zur Verringerung des Risikos beitragen, wurden bei der Vorstellung der Schätzmethoden bereits erläutert. Schätzungen können verbessert werden durch das Schätzen in der Gruppe, durch das Mitberücksichtigen der Unsicherheit im Rahmen einer Dreipunktschätzung und durch das Zerlegen der Schätzgrößen in einzelne Faktoren. Nicht alle technischen Fragestellungen in einem Projekt können schon bei der Planung zufriedenstellend beantwortet werden. Aufgrund der Neuartigkeit der Probleme in einem Projekt müssen auch neue Wege beschritten werden, um eine Lösung zu finden. Genau aus diesem Grund ist es wichtig, nicht nur eine einzige Lösung zu suchen, sondern aus

8.2 Der Risikomanagement-Prozess

215

möglichst vielen Lösungsideen zwei oder drei Varianten konkreter auszuarbeiten, bevor man sich für die Realisierung der offensichtlich besten Lösung entscheidet. Falls sich dies als unbrauchbar oder nicht machbar erweisen sollte, kann man auf eine ausgearbeitete Alternative zurückgreifen. Auch wenn dies zwar etwas Mehraufwand kostet, ist es allemal besser, als plötzlich ohne „Plan B“ dazustehen und in der ohnehin schwierigen Situation wieder von vorne beginnen zu müssen. Bei besonders kniffligen, aber chancenreichen technischen Problemen empfiehlt es sich, eine separate Machbarkeitsstudie durchzuführen. In ihr wird gezielt überprüft, ob eine ausgesuchte Lösungsidee tauglich ist, um ein Problem zu lösen. Legt man eine derartige Untersuchung vor das eigentliche Projekt, kann man Klarheit über die Lösung gewinnen und das Projekt mit geringerem Risiko durchziehen. Eine andere typische Fehlerkonstellation während der Projektdurchführung ist der Ausfall einer Person oder einer Projektressource. Ist der Ausfall zeitlich begrenzt, kann ein derartiges Ereignis durch eine Reserve ausgeglichen werden. Die Maschinenkapazität oder die Personaldecke für das Projekt beispielsweise wird etwas großzügiger geschnitten, als unbedingt nötig. Eine Alternative ist die Bildung einer personellen „Feuerwehr“ oder von Ressourcen im „Standby“. Auch ein zeitlicher Puffer ist hilfreich: Fällt eine Person oder eine Maschine vorübergehend aus oder kommt eine Lieferung später als gedacht, so kann man das verkraften, wenn die dadurch betroffenen Arbeitspakete nicht auf dem kritischen Pfad liegen. Schwieriger ist ein dauerhafter Ausfall. Natürlich verursacht jede Pufferung zusätzliche Kosten. Sie müssen mit der erzielbaren Risikoreduzierung verglichen werden. Nur wirklich wichtige Ereignisse sollten daher durch Reserven gepuffert werden. Bei allen risikoreduzierenden Maßnahmen muss man sich über eines im Klaren sein: Soll ein Projekt chancenreich sein, ist es auch riskant; will man das Risiko reduzieren, geht das nicht ohne Kosten; die Kosten müssen durch die Chancen des Projekts gedeckt sein. Oder kürzer: Risikomanagement kostet Geld; kein Risikomanagement kostet mehr Geld! Beispiel 8.4 Hardware-Entwicklungsprojekt

Bei den Steinbachwerken soll eine programmierbare Rechnerbaugruppe neu entwickelt werden. Bei einem solchen Vorhaben ist die Abkündigung von Bauteilen immer ein Risikofaktor. Das wichtigste Bauteil der Rechnerbaugruppe ist der verwendete Mikroprozessor, da sein Wechsel sowohl bei der Hardware als auch bei der Software großen Aufwand nach sich zieht. Im vorliegenden Fall wird davon ausgegangen, dass die neu entwickelte Schaltung 5 Jahre lieferbar sein soll. Normale Prozessoren sind etwa 10 bis 20 Jahre lieferbar, so dass die Wahrscheinlichkeit einer Abkündigung während der Lieferzeit recht hoch ist. Sie wird mit 25 % veranschlagt. Der Schaden, der in diesem Fall für eine Neu- oder Umentwicklung notwendig wäre, wird auf 50 Tsd. C beziffert. Somit ergibt sich ein Risiko in der Höhe von 12,5 Tsd. C.

216

8

Risikomanagement

Abb. 8.3 Screenshot der Maßnahmenbewertung

Zur Reduzierung des Risikos werden mehrere Maßnahmen erwogen. Die Verwendung eines Prozessors, mit einem kompatiblen Ersatztyp, ändert die Kündigungswahrscheinlichkeit zwar nicht, aber der Schaden wäre deutlich geringer. Allerdings hätte dieser Prozessor eine schlechtere Leistung, so dass mit 1,0 Tsd. C Mehrkosten gerechnet werden muss (Abb. 8.3). Bei Verwendung eines Prozessors, der in großer Stückzahl hergestellt wird, sinkt die Wahrscheinlichkeit der Abkündigung deutlich. Noch geringer wird sie bei Einsatz eines Prozessors mit einem Zweitlieferanten (Second Source). Weitere Optionen sind die Zusicherung einer Liefergarantie, die sich der Lieferant allerdings mit 5 Tsd. C honorieren lässt oder der Abschluss einer Versicherung, was eine Prämie von 6,5 Tsd. C kostet. Der dargestellte Screenshot zeigt das Ergebnis der Berechnungen. Die oberste Zeile zeigt den Schadensfall ohne risikoverringernde Maßnahme. Darunter sind die jeweiligen Maßnahmen mit den veränderten Risiken (R) und Kosten (C) dargestellt. Die letzte Spalte gibt deren Summe an. Alle Maßnahmen liefern eine Verbesserung gegenüber dem ursprünglichen Fall. Am besten schneidet der Prozessor ab, zu dem es einen kompatiblen Ersatztyp gibt. J Auch nach gründlicher Analyse der Risiken und nach Ergreifen risikoreduzierender Maßnahmen, wird es nicht gelingen, alle Risiken auszuschalten. Zum einen werden immer wieder Risikofaktoren unterschätzt. Zum anderen ist nicht jede theoretisch denkbare Maßnahme auch wirtschaftlich sinnvoll. Deshalb muss das Risikomanagement auch Vorsorge für den Fall treffen, dass während der Projektdurchführung ein zielschädigendes Ereignis eintritt. Damit nicht erst in einer solchen angespannten Situation überlegt werden muss, was getan werden kann, sollte die Planung bereits Maßnahmen für einen absehbaren „Eventualfall“ oder einen unvorhergesehenen „Notfall“ enthalten. Ein schädliches Ereignis tritt im Projekt immer zum unpassendsten Zeitpunkt auf. Der Stress für die Beteiligten ist in dieser Situation groß und bildet keine gute Basis, um eine Lösung zu suchen, die „rettet, was zu retten ist“. Kann man aber auf einen Maßnahmenkatalog für den Eventualfall zurückgreifen, verliert die Situation einiges an Schrecken. Zudem schärft die frühzeitige Auseinandersetzung mit derartigen Maßnahmen schon in

8.2 Der Risikomanagement-Prozess

217

der Planungsphase die Einschätzung für die möglichen Risiken und verhindert, manchmal unbewusst, das Eintreten des Fehlers. Eine nicht sehr erfreuliche, aber notwendige Reaktion auf vergessene Anforderungen sind Gespräche mit dem Auftraggeber. Kann er auf die Anforderungen verzichten, ändert sich der Projektplan nicht. Der Verzicht muss aber immer schriftlich festgehalten werden. Sind die Anforderungen unverzichtbar, müssen sie in einen modifizieren Projektplan aufgenommen werden. Es wird möglicherweise zu höherer Auslastung oder Terminverschiebungen kommen; höhere Kosten werden auf jeden Fall entstehen. Hat der Auftragnehmer seine Hausaufgaben richtig gemacht, gehen die Kosten zu Lasten des Auftraggebers. Bei unterschätztem Aufwand oder unterschätzten technischen Problemen ist dies nicht der Fall. Hier trägt der Auftragnehmer das Risiko und im Eventualfall auch die Kosten. Außerdem muss er, sobald gravierende Abweichungen auftreten, den Plan korrigieren und den Cannossagang zum Auftraggeber antreten. Nicht jedes schädliche Ereignis ist offensichtlich und wird sofort erkannt. Verzögert sich z. B. die Lieferung einer Komponente, so ist nicht unmittelbar zu erkennen, ob diese Komponente für das Projekt wichtig ist oder ob die Verzögerung auf dem kritischen Pfad des Projekts liegt. Die Mitteilung des Lieferanten landet vielleicht beim Einkauf, der gar nichts mit dem Projekt zu tun hat, sondern nur die Bestellung abwickelt. Bleibt die Information nun dort liegen, läuft das Projekt möglicherweise in ein Problem, während eine sofortige Informationsweitergabe rechtzeitige Reaktionen ermöglicht hätte. Viele Ereignisse senden wie ein Erdbeben vor den katastrophalen Schockwellen leichte Vorboten voraus. Wenn man diese erkennt, sind sogar schon präventive Reaktionen möglich. Wenn ein Mitarbeiter ein Projekt oder ein Unternehmen verlassen will, kündigt sich dies manchmal schon vorher an. Klagen über mangelnde Kommunikation im Team, verschlechterte Arbeitsleistungen, zunehmende Verschlossenheit oder übellaunige „pampige“ Reaktionen sind oft Anzeichen von Unzufriedenheit und können einer Kündigung vorangehen. Ständige Vertröstungen bei der Frage nach Arbeitsergebnissen, Nachlässigkeit bei der Erstellung von Berichten und ständiges Auftauchen unvorhergesehener „Restarbeiten“ können auf vertuschte technische Probleme hinweisen. Um derartige Probleme nicht nur zufällig zu erkennen, sondern systematisch überwachen zu können, müssen für die wichtigen Risikofaktoren in der Eventualfallplanung geeignete Indikatoren festgelegt werden. Diese sollen später bei der Projektdurchführung ein frühzeitiges Erkennen und Eingreifen ermöglichen.

8.2.4 Risiko-Überwachung Aufgrund der Komplexität, der Neuartigkeit sowie des Termin- und Kostendrucks von Projekten sind die „normalen“ Arbeiten schon anspruchsvoll. Dass jemand von selbst auf mögliche schädliche Ereignisse achtet, kann daher nicht als selbstverständlich angenom-

218

8

Risikomanagement

men werden. Deshalb müssen die Eintrittsindikatoren aktiv überwacht werden: „Wer die Risiken nicht aktiv bekämpft, den bekämpfen die Risiken.“ [Gilb 1988]. Die Überwachung der wichtigsten Projektrisiken sollte in der Obhut eines Projektleiters liegen. Hierzu gehören vor allem die personellen Risiken. Zum Führen des Projektteams gehört nicht nur, die Beteiligten zur Arbeit „anzutreiben“ und Ergebnisse abzufragen. Ein guter Projektleiter wird auch die menschliche Seite der Personalführung ernst nehmen. Dazu gehören immer wieder eingestreute informelle Gespräche mit den Mitarbeitern des Projekts. Bei gutem Gespür für die Zwischentöne einer Unterhaltung kann man einiges über den inneren Zustand der Mitarbeiter erfahren und so manche drohenden persönlichen Probleme vermeiden oder sich frühzeitig auf kommende Probleme vorbereiten. Technische und organisatorische Risiken können im Rahmen der Projektsteuerung am Vergleich der Planwerte mit den tatsächlichen Istwerten des Projektfortschritts überwacht werden. Treten Abweichungen vom Plan auf, ist nicht nur die Ursache zu klären, sondern auch ihr Risikopotential ist zu bestimmen. Die verschiedenen technischen Fragestellungen sind in der Projektplanung sowieso schon bestimmten Personen zugeordnet. Diese sind daher auch am besten zur Überwachung der entsprechenden Risikoindikatoren geeignet. Beispiel 8.5 Personalrisiko in einem Entwicklungsprojekt

In einem Projekt zur Entwicklung eines elektrischen Messgeräts sind mehrere Arbeitspakete zur Hardware-Entwicklung im Umfang von insgesamt 160 PT vorgesehen, die von einem Entwickler vollständig übernommen werden. Bei der Laufzeit des Projekts von 12 Monaten führt dies in der Projektplanung zu keinem Engpass (Abb. 8.4). Allerdings ist diese Entscheidung riskant. Der Mitarbeiter könnte z. B. wegen Kündigung ausfallen. In diesem Fall müsste ein anderer Entwickler die Aufgaben übernehmen und hierzu eingearbeitet werden. Die Einarbeitungszeit wird mit ca. 8 Wochen veranschlagt. Diese Verzögerung wäre so gravierend, dass sich auch das Projektende um mindestens 4 Wochen verschieben würde. Deshalb werden die Hardware-Arbeitspakete auf 2 Entwickler aufgeteilt. Dadurch sind diese Arbeiten auch im Falle des Ausfalls von einem der beiden nicht mehr kritisch. Abb. 8.4 zeigt einen Ausschnitt aus dem Formular zur Analyse des Personalrisikos. J Zu etlichen Arbeitsschritten des hier beschriebenen Risikomanagement-Prozesses findet man in der Literatur zahlreiche noch detaillierter ausgearbeitete Methoden. Hierzu gehören z. B. mathematische Algorithmen der Entscheidungstheorie mit denen optimale Entscheidungen bei unvollständiger Information oder Entscheidung unter Unsicherheit bestimmt werden können. Andere Verfahren versuchen die im Projekt ablaufenden riskanten Prozesse im Rechner zu simulieren, um daraus Erkenntnisse über den Umgang mit Risiken abzuleiten. Der hierbei notwendige, theoretische Aufwand steht aber oft in keinem gesunden Verhältnis zum praktischen Nutzen.

8.2 Der Risikomanagement-Prozess

219

Abb. 8.4 Analyse des Personalrisikos in einem Entwicklungsprojekt

Daher werden aufwändige Verfahren nur selten eingesetzt. In den Projekten, in denen überhaupt ein Risikomanagement betrieben wird, sind Checklisten zur Risiko-Identifikation das wichtigste Werkzeug. Dies passt recht gut zu der Einschätzung, dass die Schaffung eines Risiko-Bewusstseins wichtiger ist als mathematische Risiko-Quantifizierung! Beispiel 8.6 Fallbeispiel „CAD-Software“: Risikoportfolio

Für das Fallbeispiel „CAD-Software“ soll eine Risikoanalyse durchgeführt werden. Ausgehend von den beschriebenen Projektzielen sollen mögliche Risikofaktoren identifiziert werden. Bereits in der Projektdefinition wurden als kritische Faktoren die schnelle Auswahl und Einführung des Systems (Risiko R1), die Kompatibilität des Systems (R2) und der erforderliche Einarbeitungsaufwand (R3) erkannt (Abb. 8.5). Zur Auswahl eines Systems sind mehrere Arbeiten notwendig, die in Personentagen gemessen zwar nicht sehr aufwändig sind, die sich aber lange hinziehen, da Unterlagen angefordert, verglichen und bewertet sowie anschließend Hersteller zu einer Präsentation eingeladen werden müssen. Bei einer Projektlaufzeit von 5 Monaten ist die Wahrscheinlichkeit einer Zeitüberschreitung sehr groß. Zwar ist der dadurch entstehende materielle Schaden nicht so groß. Dennoch wird beschlossen, das Risiko zu

220

8 Schaden

Risikomanagement

R2: Kompatibilität

sehr hoch R3: Einarbeitung hoch

mittel

R1: Auswahl

gering 30%

Wahrscheinlichkeit

Abb. 8.5 Risiko-Portfolio für das Fallbeispiel „CAD“

verringern. Der Projektbeginn wird um 2 Monate verschoben, da dann eine Fachmesse stattfindet, auf der alle namhaften Hersteller vertreten sind. Auf der Messe kann bereits eine Vorauswahl stattfinden, so dass die anschließende Eingrenzung auf ca. 3 Hersteller, die zu einer Präsentation eingeladen werden, deutlich schneller abläuft. Die Frage der Kompatibilität des neuen Systems mit den bisher verwendeten Dateiformaten ist ebenfalls kritisch. Aufgrund der optimistischen Aussagen der SystemHersteller wird die Wahrscheinlichkeit für unvollständige Kompatibilität nicht so hoch angesetzt. Sollten die Probleme aber dennoch auftreten, wären umfangreiche Anpassarbeiten nötig, so dass auch mit einem erheblichen Mehraufwand gerechnet werden muss, der mehr als 20 % des Gesamtbudgets ausmachen kann. Zur Risikoreduzierung sollen aus alten Projekten exemplarische Dateien zusammengestellt werden. Diese werden den Herstellern übergeben, damit sie die Kompatibilität überprüfen und rechtlich bindende Aussagen hierüber machen können. Der mögliche Schaden lässt sich dadurch komplett auf die Lieferanten übertragen. Als weiterer Risikofaktor wird die erforderliche Einarbeitung angesehen. Sollte die Einarbeitung schwieriger sein als gedacht, würde dies für alle Mitarbeiter Mehraufwand bedeuten. Der wirtschaftliche Schaden hierfür ist beträchtlich. Dies wurde bereits im Projekt berücksichtigt durch den Einbau einer Prototyp-Phase. Ein Mitarbeiter der Steinbachwerke wird in dieser Phase vom Lieferanten geschult und durchläuft dann seinen gewohnten Arbeitsablauf auf dem neuen System. Erst nach Abschluss dieser Phase wird das System bei allen Mitarbeitern eingeführt. Dies sollte dann wesentlich einfacher sein, da bereits ein hausinterner Mitarbeiter sich mit dem System auskennt und Fragen schneller beantworten kann. Das verbleibende Risiko wird als tragbar eingeschätzt. Durch die ergriffenen Maßnahmen verschieben sich die Risiken in Richtung niedrigeren Schadens bzw. geringerer Auftrittswahrscheinlichkeit, wie in der Grafik dargestellt. J

Kostenmanagement

In diesem Kapitel werden zunächst die Grundbegriffe der betrieblichen Kostenrechnung erläutert. Sie werden dann genutzt, um die in einem Projekt entstehenden Arbeitskosten der mitwirkenden Personen zu schätzen und zu kalkulieren. Anschließend erhalten Sie einen Einblick in die Aufgaben und Methoden der Kostenplanung, die den zeitlichen Verlauf der Kosten und die Budgets ermittelt (Abb. 9.1). Diese Werte bilden zusammen mit den laufend erfassten Fortschrittsdaten die Basis sowohl für die Angebotserstellung als auch für die Kostenkontrolle während der Projektdurchführung. Die bekannteste Methode zur Analyse und Kontrolle der Kosten, die Earned Value Analyse wird zum Schluss des Kapitels detailliert vorgestellt und erläutert.

Nach der Bearbeitung des Kapitels sind Sie in der Lage,  die wichtigen Begriffe der Kostenrechnung, wie Kosten, Kostenstellen, Kostenarten, Kostenträger und Gemeinkosten zu erläutern,  aus bekannten direkten Personalkosten, wie z. B. Monatsgehältern, die Stundensätze zur Kalkulation der Kosten des Personalaufwands zu berechnen,  aus dem Terminplan eines Projekts mit Aufwandsschätzwerten die zeitliche Verteilung der Kosten, den Verlauf der Plankosten über die Projektdauer und die zu den Meilensteinterminen freizugebenden Budgets zu bestimmen,  mit Hilfe der Earned Value Analyse aus gegebenen Planwerten eines Projekts und aktuell erfassten Istwerten die nötigen Kennzahlen zur Analyse des finanziellen Projektstatus und zur Vorhersage des finanziellen Projektergebnisses zu berechnen.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 221 W. Jakoby, Projektmanagement für Ingenieure, https://doi.org/10.1007/978-3-658-32791-0_9

9

222

9

Kostenmanagement

ProjektStrukturplan

Kostenschätzung

Kostenschätzwerte

Ablauf- und Terminplan

KostenPlanung

Plankostenverlauf Budgets

Fortschrisdaten

Kosten überwachung

Istkosten korr. Maßnahmen Änderungsanträge

Abb. 9.1 Prozesse des Kostenmanagements

9.1

Kosten

9.1.1 Grundbegriffe der Kostenrechnung In einem Projekt entstehen auf vielfältige Weise Kosten: Personen arbeiten im Projekt und erhalten hierfür ein Gehalt. Für Ihre Arbeit brauchen sie einen Arbeitsplatz, Werkzeuge und Maschinen. Sie nutzen die Infrastruktur des Unternehmens und greifen auf Dienste anderer Abteilungen zurück. Auch von außen werden Güter und Dienstleistungen für das Projekt zugekauft. Der gesamte in Geld bewertete Verbrauch von Gütern und Dienstleistungen zur Erstellung einer Leistung wird als Kosten bezeichnet. Die Kosten müssen durch den Auftraggeber getragen werden. Dies wird im Auftrag geregelt. Neben vielen anderen Vereinbarungen enthält der Auftrag deshalb auch eine Festlegung der vom Auftraggeber aufzubringenden Finanzmittel. Der Erfolg eines Projekts bemisst sich daher auch an der Erreichung der Kostenziele. Die Betrachtung von Kosten ist keine Besonderheit von Projekten, sondern zählt zu den grundlegenden betriebswirtschaftlichen Aufgabengebieten. Eine zentrale Rolle spielt dabei die Kostenrechnung. Im Normalfall kann in einem Projekt auf die bestehende Kostenrechnung des Unternehmens zurückgegriffen werden. Einige grundlegende Begriffe und Methoden der betrieblichen Kostenrechnung werden daher auch für das Projektmanagement benötigt. Die Kostenrechnung dient dem Ziel, das Unternehmen als Ganzes aber auch einzelne Bereiche wirtschaftlich zu betreiben. Sie erfasst dazu:  welche Kosten entstanden sind (Kostenart),  wo die Kosten entstanden sind (Kostenstelle) und  wofür die Kosten entstanden sind (Kostenträger). Die wichtigsten Kostenarten sind Personalkosten, Materialkosten, Abschreibungen, kalkulatorische Kosten und Kosten für Zulieferungen. Typische Kostenträger sind entweder das gesamte Unternehmen, einzelne Abteilungen, Aufträge oder Projekte. Mögliche

9.1 Kosten

223

Kostenstellen können Bereiche, Arbeitsgruppen, Aufträge, Projekte oder Teilprojekte sein. Im einfachsten Fall kein ein ganzes Projekt als Kostenstelle und, falls es zu Beginn ein entsprechendes Budget erhalten hat, auch als Kostenträger auftreten. Im Sinne der Transparenz ist dies aber nicht sinnvoll, da später nur ein Gesamtergebnis ermittelt werden kann. Fehler bei den kalkulierten und tatsächlich entstandenen Kosten können so aber nicht erkannt werden. Besser ist es, innerhalb des Projekts verschiedene Kostenstellen und Kostenträger zu definieren. Dies können z. B. Teilprojekte, Projektphasen oder größere Arbeitspakete sein. Wichtig ist es, entstehende Kosten lückenlos zu erfassen und den Verursachern anzurechnen, um gültige Aussagen über den wirtschaftlichen Betrieb zu gewinnen. Dies ist nur selten so einfach, wie es klingt. Einzelkosten können einem Kostenträger direkt zugeordnet werden. Beispiele für diese direkten Kosten sind Löhne und Gehälter, Rechnungsbeträge für zugekauftes Material oder aus dem Lager entnommene Teile. Daneben gibt es Gemeinkosten, die einem Kostenträger nicht direkt zurechenbar sind. Hierzu zählen z. B. die Inanspruchnahme anderer Abteilungen, die Nutzung der betrieblichen Infrastruktur, Schulungen, Miete, Zinsen. Hier ist eine indirekte Aufteilung z. B. über Kennzahlen oder Verteilerschlüssel erforderlich. Oft ist es aber gar nicht möglich, derartige Gemeinkosten verursachergerecht aufzuteilen. Zudem steht in den meisten Fällen der Aufwand für die Erfassung und Verteilung in keiner sinnvollen Relation zu dem erzielten Nutzen. Deshalb werden indirekte Kosten in der Regel als prozentuale Zuschläge zu den direkten Kosten berücksichtigt.

9.1.2 Arbeitskosten Viele Projekte sind personalintensiv, so dass hier die Arbeitskosten dominieren. Auf deren Schätzung, Planung und Kalkulation ist besonders zu achten. Da er multiplikativ in die Kalkulation eingeht, ist der Stundensatz eine wichtige und kritische Größe. Ein Fehler im Stundensatz pflanzt sich proportional auf das Gesamtprojekt fort. Um Fehler zu vermeiden, versucht man zum einen den Stundensatz möglichst genau zu bestimmen. Zum anderen darf der Aufwand vor Projektbeginn nicht unnötig hoch getrieben werden. Die Personalkosten werden daher in der Regel nicht individuell bestimmt, sondern es werden Personengruppen mit einheitlichem Stundensatz gebildet. Außerdem werden alle indirekten Personalkosten in Form eines pauschalen Gemeinkostenzuschlags berücksichtigt (Tab. 9.1). Die Ausgangsbasis für die Kalkulation eines Stundensatzes ist die nominelle jährliche Arbeitszeit T A . Sie ergibt sich in der Regel aus den Arbeitsverträgen, in denen wöchentliche Arbeitszeiten und der Urlaubsanspruch geregelt sind. Nach Abzug von Fehlzeiten und Zeiten für unproduktive Arbeiten verbleibt die produktive Zeit. Statt über eine individuellen Zeiterfassung kann die produktive Zeit über einen Korrekturfaktor CP ermittelt werden, der kleiner als 1 ist.

224

9

Kostenmanagement

Tab. 9.1 Kalkulationsgrößen für den Stundensatz Zeichen TA CP KB CV CS KS

Bedeutung Nominelle jährliche Arbeitszeit (Personenstunden) Korrekturfaktor für die produktive Arbeitszeit Jährliches Bruttogehalt Korrekturfaktor für den AG-Anteil zur Sozialversicherung Korrekturfaktor für die Arbeitsplatz-Sachkosten Kalkulierte Kosten pro Arbeitsstunde

Beispiel T A = 1760 Pers.-Std. CP = 0,85 K B = 45.000 C CV = 1,20 CS = 1,30 K S = 46,92 C/Pers.-Std.

Die zweite Basisgröße ist das an die Beschäftigten ausgezahlte Bruttogehalt K B , das auf Monatsbasis oder Jahresbasis angegeben wird. Auch hier sind zusätzliche Komponenten zu berücksichtigen. Zum einen sind dies Arbeitgeberanteile zur Sozialversicherung. Diese werden prozentual berechnet und können als Faktor CV ausgedrückt werden. Weitere Aufschläge entstehen durch die Sachkosten, die mit dem Arbeitsplatz verbunden sind. Dies sind z. B. Kosten für einen Büroraum, für ein Fahrzeug, für Dienstreisen etc. Auch diese werden als prozentualer Aufschlag (Faktor CS ) berücksichtigt. Aus den beiden Basiswerten und den Korrekturfaktoren kann dann der Stundensatz bestimmt werden, der zur Kalkulation der Kosten für den Arbeitsaufwand im Projekt verwendet wird: CS  CV  KB : (9.1) KS D C P  TA Die Betrachtung der Arbeitszeiten und Kosten auf Jahresbasis stellt dabei sicher, dass saisonale und einmalige Effekte wie z. B. Urlaub oder Weihnachtsgeld berücksichtigt sind. Damit die Korrekturfaktoren möglichst gut die tatsächlichen Verhältnisse wiedergeben, ist es in einem Unternehmen notwendig, die tatsächlichen Werte zurückliegender Jahre zu erfassen und statistisch auszuwerten. Beispiel 9.1 Stundensatz für Arbeitskosten ermitteln

Ein Unternehmen, das überwiegend Ingenieurdienstleistungen anbietet, benötigt für seine Angebotskalkulation einen Stundensatz der Arbeitskosten. Neben den unmittelbaren Personalkosten müssen auch die mit dem Arbeitsplatz verbundenen Sachkosten, also z. B. die Raumkosten oder Reisekosten, im Stundensatz berücksichtigt werden. Zur Vereinfachung der Kalkulation sollen die Sachkosten somit als fester, proportionaler Zuschlag gehandhabt werden. Dazu werden die gesamten Personalkosten und alle anfallenden Sachkosten im Unternehmen für ein Jahr aufsummiert (siehe Abb. 9.2). Die Arbeitskosten enthalten also 77 % reine Personalkosten und 23 % Sachkosten. Der Quotient der Arbeitskosten und der Personalkosten beträgt 1,3. Ausgehend von den Personalkosten können die Sachkosten somit als pauschaler Zuschlag von 30 % auf die Personalkosten angesetzt werden. Als nächstes werden die Arbeitszeiten bestimmt. Ausgehend von einem Jahr werden zunächst Wochenenden und Feiertage abgezogen. Außerdem werden die vertraglich

9.1 Kosten

225

Abb. 9.2 Bestimmung des Sach-/Gemeinkosten-Zuschlags

Abb. 9.3 Bestimmung der produktiven Arbeitsstunden pro Jahr

vereinbarten Urlaubstage sowie die durchschnittlich anfallenden Krankheitstage berücksichtigt. Man erhält somit 216 Arbeitstage (Abb. 9.3). Da nicht während der gesamten Zeit produktiv gearbeitet werden kann, sind weitere Abschläge nötig. Insbesondere werden Zeiten für die Weiterbildung berücksichtigt. Verwaltungsarbeiten werden als pauschaler Abschlag von ca. 7 % geschätzt. Damit bleiben 192 produktive Arbeitstage und bei 8 h pro Tag 1536 produktive Arbeitsstunden pro Jahr. Mit diesen Werten können nun die Stundensätze für die Arbeitskosten (als C/Std.) bestimmt werden. Individuelle Unterschiede sollen zwar nicht betrachtet werden. Um die teilweise deutlichen Gehaltsunterschiede im Unternehmen dennoch zu berücksichtigen, werden drei Gehaltsgruppen gebildet: Ingenieure, Techniker und Sonstige. Aus dem monatlichen Bruttogehalt folgt ein Jahresbruttogehalt, das auch Urlaubsund Weihnachtsgeld enthält. Bezogen auf die Jahresarbeitsstunden erhält man einen Brutto-Stundensatz. Neben dem Bruttogehalt fallen aber weitere Kosten an. Es sind dies die Arbeitgeber-Beiträge zur Sozialversicherung und zur Berufsgenossenschaft. Als Ergebnis erhält man den Stundensatz für die produktive Zeit.

226

9

Kostenmanagement

Abb. 9.4 Berechnung des Arbeitskosten-Stundensatzes

Zur Bestimmung des tatsächlichen Arbeitskosten-Stundensatzes müssen schließlich noch der Sachkosten in Höhe von 30 % aufgeschlagen werden. Der daraus folgende Stundensatz liegt um mehr als 90 % über dem auf Monatsbasis berechneten Bruttogehalt. Die so berechneten Stundensätze können nun zur Kalkulation der Arbeitskosten in einem Projekt verwendet werden (Abb. 9.4). J

9.2 Kostenplanung in Projekten Die Kostenplanung in einem Projekt erfüllt mehrere Aufgaben (Tab. 9.2). Zunächst wird sie zur Kalkulation der Gesamtkosten im Rahmen der Angebotserstellung benötigt. Die zweite Aufgabe ist die Bestimmung der zeitlichen Verteilung des Finanzbedarfs während des Projekts. Hiermit wird geklärt, wann wie viel Geld bereit stehen muss. Zusätzlich erhält man einen Verlauf der geplanten Kosten als Basis für die spätere Kontrolle. Als dritte Aufgabe der Kostenplanung ist die Ermittlung der Kosten für die einzelnen Teilprojekte und Arbeitspakete zu nennen. Diese Planung wird für die Kontrolle und Steuerung von Soll- und Istverlauf benötigt. Erst diese detaillierte Betrachtung bringt die benötigte Transparenz und ermöglicht es, die Ursachen von Zielabweichungen zu lokalisieren und darauf zu reagieren.

Tab. 9.2 Aufgaben der Kostenplanung Aufgaben der Kostenplanung: Angebotskalkulation Ermittlung des zeitlichen Plankostenverlaufs Ermittlung der Kostenverteilung auf die Teilprojekte und Arbeitspakete

Wird benötigt für . . . Angebotserstellung und Vergabeverhandlung Budgetbildung und Kontrolle des Istverlaufs Kontrolle von Soll- und Istverlauf

9.2 Kostenplanung in Projekten

227

9.2.1 Projektkalkulation Eine erste summarische Kalkulation der Projektkosten ist vor Projektbeginn erforderlich und dient der Angebotserstellung auf der Basis des geschätzten Aufwands und der Kosten für die benötigten sächlichen Ressourcen. Für die Kalkulation werden die im Verlaufe des Projekts zu erwartenden Kosten geschätzt. Dieser Wert fließt dann in das Angebot ein und bildet auch die Grundlage für die Vergabeverhandlung und für einen eventuellen Auftrag. Für eine Kostenschätzung gibt es eine ganze Reihe von Methoden. Grundsätzlich gilt: Je präziser sie sein soll, desto aufwändiger ist eine Schätzung. In manchen Bereichen können die Kosten eines ganzen Projekts näherungsweise mit Hilfe von Kennwerten abhängig von einem dominierenden Parameter geschätzt werden. In der Baubranche ist dies z. B. die so genannte Kubatur, dem in Kubikmetern gemessenen umbauten Raum, im Stahlbau das Gewicht einer mechanischen Konstruktion oder in der Software-Entwicklung die Zahl der Programmzeilen. Eine derartige Schätzung ist schnell und mit minimalem Aufwand machbar. Sie setzt aber entsprechende Erfahrungswerte voraus. Zudem liefert sie nur eine grobe Aussage und kann deshalb nur dazu dienen, einen ersten Richtwert zur Orientierung zu erhalten. Genauere und verlässlichere Schätzungen erfordern mehr Aufwand. Bei ihnen werden die Projektkosten nicht en bloc ermittelt, sondern die Gesamtkosten werden in einzelne Pakete untergliedert und getrennt geschätzt. Dabei kann z. B. nach Kostenarten zwischen den Arbeitskosten, den Materialkosten und den Zukaufkosten unterschieden werden. Auch eine Differenzierung nach verschiedenen Kostenverursachern, den Kostenstellen, ist notwendig. Die Kostengliederung sollte der Projektgliederung des Projekt-Strukturplans entsprechen. Die Teilprojekte und eventuell auch größere Arbeitspakete werden dabei als Kostenstellen betrachtet. Kleinere Arbeitspakete sollten hinsichtlich der Kosten nicht einzeln betrachtet werden, da dies den Aufwand für das Schätzen sowie für die spätere Erfassung und Kontrolle stark erhöht, während der Nutzen nur gering ist. Bei der Wahl des richtigen Detaillierungsgrades gilt das Prinzip: so detailliert wie nötig; so grob wie möglich. Bei der Festlegung der richtigen Detaillierung ist eine ABCAnalyse und das Pareto-Prinzip hilfreich. Die möglichen Kostenverursacher im Projekt werden nach dem erwarteten Umfang in drei Klassen A, B und C unterteilt. Nach dem Pareto-Prinzip werden dann die Faktoren, die den Löwenanteil, z. B. 80 % der Kosten verursachen, detailliert untersucht und geschätzt. In den meisten Fällen ist die dadurch erreichte Detaillierung ausreichend. Für eine genauere Betrachtung können auch noch die B-Faktoren analysiert werden. C-Faktoren können oft durch prozentuale Zuschläge berücksichtigt werden. Auch die zugekauften Güter oder Dienstleistungen sollten nicht als Block gehandhabt werden, sondern passend zur Projektgliederung unterteilt werden. Leistet z. B. ein Subunternehmen in einem Projekt mehrere Arbeitspakete oder Teilprojekte, so sollten die Kosten auch entsprechend aufgeteilt werden.

228

9

Kostenmanagement

Für die Transparenz der Kostensituation, sollte auch die Kostenstellengliederung der Istkosten mit der Plankostengliederung übereinstimmen. Nur dadurch kann sichergestellt werden, dass sich die anfallenden Kosten nachvollziehbar kontrollieren und zielgerichtet steuern lassen. Zur detaillierten Schätzung der Arbeitskosten kann auf die Aufwandsschätzwerte zurück gegriffen werden, die bereits für die Terminplanung erstellt wurden. Der Aufwand multipliziert mit den Stundensätzen ergibt die Arbeitskosten. Außerdem müssen für jedes Arbeitspaket die Kosten der benötigten Materialien sowie der zuzukaufenden Güter und Dienstleistungen geschätzt werden. Sehr sinnvoll ist es, an dieser Stelle die verantwortlichen Personen für die Teilprojekte und Arbeitspakete einzubinden. Sie können möglicherweise die präzisesten Aussagen machen. Außerdem werden sie durch die frühzeitige Einbindung die Projektziele eher akzeptieren und ihre Arbeit auf die Zielerreichung ausrichten. Für eine objektive Bewertung eines Projekts aus Kostensicht, ist es nötig, nicht nur die genannten, offensichtlichen Personal- und Sachkosten der Arbeitspakete zu berücksichtigen. Auch indirekte Kosten müssen in die Planung einfließen, z. B. in Form des Gemeinkostenzuschlags im Stundensatz. Außerdem muss der gesamte Projektlebenszyklus im Sinne eines „life cycle costing“ betrachtet werden. Hier sind z. B. Kosten für die Arbeiten vor Projektbeginn und für die möglichen Restarbeiten nach der Abnahme zu nennen. Allzu oft werden Projekte von den Verantwortlichen „schön gerechnet“, indem Projektkosten als allgemeine Kosten deklariert oder auf andere Kostenstellen gebucht werden. Kurzfristig mag dies verlockend sein, aber die Kosten fallen dennoch an und müssen durch das Unternehmen getragen werden. Was hilft es, wenn ein Unternehmen lauter „erfolgreiche“ Projekte produziert, ihm am Ende aber trotzdem das Geld ausgeht?

9.2.2

Kostenverteilung

Das Ergebnis der Kostenschätzung ist eine summarische Gesamtaussage über die Projektkosten, die im Angebot und in den Verhandlungen für die Auftragsvergabe verwendet wird. Die Schätzung auf der Ebene der Arbeitspakete oder Teilprojekte liefert aber auch wichtige auf zeitliche Perioden oder auf Kostenstellen bezogene Detailaussagen, die für die Planung der Projektdurchführung benötigt werden. Liegen für jedes Arbeitspaket Kostenschätzungen vor, so lässt sich zusammen mit dem Ablauf- und Terminplan ermitteln, in welchen Zeitperioden bestimmte Kosten anfallen. Diese Betrachtung kann z. B. monatlich oder quartalsweise erfolgen. Die auf die Kostenstellen, z. B. auf die Arbeitspakete bezogene Kostenplanung („Wo entstehen die Kosten?“) ist eine wichtige Sichtweise für die Steuerung und Kontrolle der Kosten. Außerdem sorgt sie für eine Kostentransparenz. Durch die Verwendung von Kostenstellen fallen Kostenabweichungen nicht mehr pauschal auf das gesamte Projekt

9.2 Kostenplanung in Projekten

229

Abb. 9.5 Kostenverteilung über die Laufzeit und die Teilprojekte (Zahlenangaben in Tsd. C) (PK: Personal-, MK: Material-, ZK: Zukaufkosten, SK: Summe der Kosten)

zurück. Vielmehr können die Ursachen lokalisiert und entweder noch im laufenden Projekt korrigiert oder aber im nächsten Projekt vermieden werden. Beispiel 9.2 Kostenplanung

Für ein Projekt soll eine Kostenplanung erstellt werden. Das Projekt beginnt Anfang April und läuft bis Mitte März des darauf folgenden Jahrs. Die Gliederung des Projekts hat einen Strukturplan mit 7 Teilprojekten (TP1 bis TP7) und 4 Projektphasen (I bis IV) ergeben. Für jedes Teilprojekt werden die Personalkosten (PK), die Materialkosten (MK) und die Zukaufkosten (ZK) geschätzt und aufsummiert (SK) (Abb. 9.5). Es sollen nun die Gesamtkosten, der Verlauf der Kosten über die Projektlaufzeit und die Projektphasen freizugebenden Budgets ermittelt werden. Für jedes Teilprojekt erhält man die jeweiligen Kosten aus der Schätzung. Wegen der eindeutigen Zuordnung der Teilprojekte zu den 4 Projektphasen können damit auch die in einer Phase erwarteten Kosten ohne weiteres ermittelt werden. Diese können als Budgets verwendet werden, die zu Beginn der Phase freigegeben werden. Die Gesamtkosten ergeben sich aus der Summation der Einzelkosten aller Teilprojekte (255 Tsd. C). Die zeitbezogene Kostenplanung soll auf Monatsbasis erfolgen. Wie zu erkennen ist, passen die Projektphasen nicht genau in das Monatsraster. In manchen Monaten fallen daher Kosten aus verschiedenen Projektphasen an. Die monatlich geplanten Kosten sowie die kumulierten Plankosten sind unterhalb des Diagramms dargestellt. J

230

9.3

9

Kostenmanagement

Kostencontrolling mittels Earned Value Analyse

9.3.1 Aufgabe und Ziele des Kostencontrollings Die Aufgabe des Kostenmanagements ist es, den Verlauf der Kosten so zu planen und zu steuern, dass die zu Beginn eines Projekts formulierten Kostenziele erreicht bzw. eingehalten werden. Aus der Kostenplanung haben sich zeitbezogene und kostenstellenbezogene Planzahlen ergeben. Diese bilden die Basis für das Kostencontrolling. Während der Projektdurchführung werden die tatsächlichen anfallenden Kosten als Istkosten erfasst. Sie können mit den Planzahlen verglichen werden. Weicht ein Projekt aus inhaltlichen Gründen vom Planverlauf ab, weil sich z. B. eine Lieferung verzögert oder weil ein Arbeitspaket vorgezogen wird, ändert sich auch der Kostenverlauf. Die ursprünglichen Planzahlen sind dann nur noch eingeschränkt hilfreich. Deshalb werden neben den Plan- und Istkosten auch die Sollkosten benötigt. Diese müssen aus dem tatsächlichen Projektfortschritt bestimmt werden. Die Aufgabe des Kostencontrollings ist es also, regelmäßig Istkosten zu erfassen, Sollkosten zu berechnen, Plan-, Ist- und Sollkosten miteinander zu vergleichen sowie bei Abweichungen korrigierend einzugreifen. Die bekannteste Methode des Kostencontrollings, die Earned Value Analyse wird nun ausführlich erläutert. Die Earned Value Analyse (EVA) dient dazu, den Fortschritt eines Projekts aus Sicht von Aufwand und Nutzen zu analysieren. Dabei wird zu Beginn des Projekts der Verlauf des Aufwands geplant. Er ergibt sich aus dem Projektablaufplan in Kombination mit der Aufwandsschätzung für die einzelnen Arbeitspakete. Im Verlauf des Projekts werden in regelmäßigen Zeitabständen von ca. 2–4 Wochen der geplante Aufwand, der tatsächliche Aufwand und der geschaffene Wert der Leistungen miteinander verglichen. Die Analyse basiert auf dem Gedanken, dass bei einem normal verlaufenden Projekt der geschaffene Nutzen mit dem erforderlichen Aufwand übereinstimmen sollte. Aufwand und Nutzen werden dabei monetär bewertet: der Aufwand wird in Form von Kosten ausgedrückt, der Nutzen als finanzieller Wert der Leistungen. Aus dem regelmäßigen Vergleich von Kosten und Werten sowie von geplanten und tatsächlichen Kosten können dann Aussagen über den momentanen Zustand des Projekts, Vorhersagen über den möglichen weiteren Verlauf und auch Schlussfolgerungen für notwendige steuernde Eingriffe gemacht werden. Die Earned Value Analyse wurde in den 60er Jahre in den USA entwickelt und ist dort seit langem etabliert. In Deutschland ist die Methode auch unter den Bezeichnungen Ertragswert-, Leistungswert- oder Arbeitswertanalyse bekannt, aber bei weitem nicht so verbreitet. Ausgangspunkt der Methodik sind die Arbeitspakete des Projektstrukturplans. Deren zeitliche Zuordnung im Rahmen des Ablauf- und Terminplans ergeben eine Verteilung des Arbeitsaufwands während des Projekts. Die Multiplikation mit dem Stundensatz und Kumulation über die Zeit liefert den Verlauf der Plankosten (PV: Planned Value) während der gesamten Projektdauer. Die geplanten Gesamtkosten, die bis zum Projektende auflau-

9.3 Kostencontrolling mittels Earned Value Analyse

231

BAC

AC PV

CV SV

EV

t1

TAC

t

Abb. 9.6 Earned Value Analyse

fen, werden als „Budgeted Cost at Completion“ (BAC) bezeichnet; die benötigte Zeit als „Time at Completion“ (TAC). Während der Projektdauer werden in bestimmten Zeitabständen die bis dahin tatsächlich entstandenen Kosten (AC: Actual Cost) und der Fertigstellungswert (EV: Earned Value) ermittelt (Abb. 9.6). Der richtige Zeitabstand für die Berechnungen hängt von der Projektgröße bzw. -dauer ab. Um einerseits unnötigen Verwaltungsaufwand zu vermeiden und wirklich aussagefähige Daten zu erhalten und andererseits Fehlentwicklungen nicht zu spät zu erkennen, ist eine erste Analyse nach 10–20 % der Projektzeit sinnvoll. Die weiteren Analysen können dann z. B. alle 2–4 Wochen erfolgen.

9.3.2 Ermittlung der Istwerte Der aktuelle Aufwand kann bei einer funktionierenden Zeiterfassung und bei einer Buchung der Arbeitszeiten auf die einzelnen Arbeitspakete jederzeit relativ einfach bestimmt werden. Mit Hilfe der Stundensätze ergeben sich daraus unmittelbar die aktuellen Kosten. Deutlich schwieriger ist die Bestimmung des Fertigstellungswertes, des Earned Value. Hier muss auf die bereits beschriebenen Methoden der Fortschrittserfassung auf der Ebene der Arbeitspakete zurückgegriffen werden. Der Wert der abgeschlossenen Arbeitspakete fließt in vollem Umfang in den Fertigstellungswert, vorausgesetzt die Arbeiten sind wirklich erfolgreich abgeschlossen. Problematisch sind aktuell laufende Arbeitspakete. Deren Fertigstellungsgrad ist in der Praxis nicht immer so leicht feststellbar. Einfache Abhilfen sind die Berücksichtigung der Leistung der laufenden Pakete mit einem pauschalen Prozentsatz. Besser, aber auch aufwändiger ist die Schätzung des Fertigstellungswertes, z. B. durch Schätzung des Restaufwandes.

232

9

Kostenmanagement

Tab. 9.3 Fertigstellungsdaten der Arbeitspakete (FG: Fertigstellungsgrad) AP1 AP2 AP3 AP4 Summe

Plan 15 12 20 15 62

Ist 5 10 12 8 35

FG (in %) 33 83 60 53 56

0/100 0,0 0,0 0,0 0,0 0,0

0/50/100 7,5 6,0 10,0 7,5 31,0

0/20/50/80/100 3,0 9,6 10,0 7,5 30,1

Beispiel 9.3 Ermittlung des Fertigstellungswertes

Die Tab. 9.3 zeigt die Momentaufnahme eines Projekts, bei dem 4 Pakete in Arbeit sind. Bezieht man die erfassten Istwerte des Arbeitsaufwands auf die Planwerte, ergibt sich der Fertigstellungsgrad FG. Zumindest vordergründig könnte man den Ist-Aufwand als Fertigstellungswert annehmen. Im vorliegenden Fall wären dies 35 Tage bzw. 56 %. Eine derartige Annahme ist aber recht optimistisch, um nicht zu sagen blauäugig. Der bislang betriebene Aufwand muss sich nicht zwangsläufig im Wert der Leistungen wiederspiegeln. Pauschale Ansätze, wie in den nächsten Spalten der Tabelle dargestellt, sind zwar einfach, aber nicht unbedingt präzise. Bei der extrem vorsichtigen Methode 0/100 werden angefangene Arbeitspakete mit 0 % bewertet und vollständig fertig gestellte mit 100 %. Realistischer ist die Methode 0/50/100: angefangene Pakete werden pauschal mit 50 % bewertet, nicht begonnene mit 0 % und fertige mit 100 %. Durch die Mittelung über mehrere Pakete, von denen einige gerade erst angefangen, manche fast fertig und andere irgendwo in der Mitte sind, gleichen sich Einzelfehler aus. Noch detaillierter ist die Methode aus der letzten Spalte der Tabelle. Hier wird die Fertigstellung laufender Pakete auf feste Werte von 20, 50 oder 80 % geschätzt. Präziser, aber auch aufwändiger sind Restaufwandsschätzungen. Hier wird nicht nur der Ist-Aufwand erfasst, sondern zusätzlich wird der Rest-Aufwand geschätzt. Statt den Istwert auf den Planwert zu beziehen, wird der Fertigstellungsgrad nun aus dem Quotienten von Istwert und Ist- plus Restwert gebildet. Im Normalfall, wie bei AP1 der Fall, entspricht der Rest-Aufwand der Differenz von Plan- und Ist-Aufwand. Das Paket liegt im Plan. Nicht untypisch ist es, dass der Restaufwand größer ist, als ursprünglich gedacht. Der Fertigstellungsgrad ist dann geringer als dies der Ist-Aufwand nahe legt. Im dargestellten Beispiel führt die Restaufwandsschätzung für die Summe aller Arbeitspakete zu einem Fertigstellungswert von 30 Tagen bzw. 49 % (vgl. Tab. 9.4). J Auch wenn dieses Zahlenbeispiel nur einen Einzelfall wiedergibt, legt es Schlussfolgerungen nahe, die sich in vielen praktischen Situationen als gültig erwiesen haben. Eine pauschale Berücksichtigung des Fertigstellungsgrades mit der Methode 0/50/100 liefert bei minimalem Aufwand brauchbare Ergebnisse. Dies gilt vor allem, je mehr Arbeitspakete in Bearbeitung sind und je kleiner die Pakete dimensioniert sind. Die Restaufwands-

9.3 Kostencontrolling mittels Earned Value Analyse

233

Tab. 9.4 Earned Value der Arbeitspakete (FG: Fertigstellungsgrad) AP1 AP2 AP3 AP4 Summe

Plan 15 12 20 15 57

Ist 5 10 12 8 35

Rest 10 4 15 8 37

Ist + Rest 15 14 27 16 72

FG (in %) 33 71 44 50 49

Earned Value 5,0 8,6 8,9 7,5 30,0

schätzung ist zwar aufwändiger, liefert aber präzisere Ergebnisse und führt zudem zu einer bewussten Auseinandersetzung der beteiligten Personen mit dem Arbeitsfortschritt. Gerade dies fördert in vielen Fällen eine zielstrebige Arbeitsweise.

9.3.3 Analyse von Plan-, Ist- und Sollzahlen Ausgehend von den Periodenwerten (Planned Value PV, Actual Cost AC, Earned Value EV) können nun vergleichende Analysen angestellt werden. Eine erste Betrachtung vergleicht den bisher erreichten Fortschritt (EV) mit dem geplanten Fortschritt (PV). Die Differenz EV  PV wird als Schedule Variance (SV) und der Quotient EV/PV als Schedule Performance Index (SPI) bezeichnet. SV D EV  PV

(9.2)

EV (9.3) PV Bei plangemäßem Fortschritt ist SV = 0 und SPI = 1. Liegt das Projekt hinter der Planung zurück, ist SV negativ und SPI < 1; liegt es über Plan wird SV positiv und SPI > 1. Diese beiden Kennzahlen machen also unabhängig vom betriebenen Aufwand eine Aussage über die Abweichung des Istverlaufs vom Planverlauf. Sie können zur Fortschrittssteuerung genutzt werden. Schedule Variance bzw. Schedule Performance Index enthalten keine Aussage über die Effizienz der Arbeit bzw. der bislang entstandenen Kosten. Hierzu müssen die aktuellen Kosten (AC) und der bislang geschaffene Wert der Leistung (EV) verglichen werden. Auch hier gibt es eine absolute und eine relative Kennzahl, nämlich die Cost Variance (CV) und den Cost Performance Index (CPI). SPI D

CV D EV  AC

(9.4)

EV (9.5) AC Wenn die bislang entstandenen Kosten mit den geschaffenen Leistungen übereinstimmen ist CV = 0 und CPI = 1. Bei CV > 0 und CPI > 1 läuft das Projekt effektiv: der geschafCPI D

234

9

Kostenmanagement

Tab. 9.5 Kennzahlen der Earned Value Analyse Bezeichnung Planwerte Budget at Completion (Ges.-Budget) Time at Completion (Ges.-Laufzeit) Istwerte Earned Value (fertig gestellter Wert) Planned Value (geplanter Wert) Actual Cost (aktuelle Kosten) Cost Variance/Perform. Index Schedule Variance/Perform. Index Ziel-Prognose Estimate at Completion Variance at Completion Estimate to Complete Plan at Completion Delay at Completion

Akt. Zustand

Kostenwerte

Zeitwerte

BAC TAC EV EV PV AC AC CV = EV  AC CPI = EV / AC SV = EV  PV

EV PV

SPI = EV / PV

EAC = BAC / CPI VAC = EAC  BAC ETC = EAC  AC PAC = TAC / SPI DAC = PAC  TAC

fene Wert übersteigt die Kosten. Je negativer CV dagegen ist, bzw. je weiter CPI unter 1 liegt, desto kritischer ist das Projekt: die Kosten übersteigen den Wert. Beispiel 9.4 EVA-Kennzahlen bestimmen (1)

Für ein Projekt wurde ein Budget von BAC = 420 Tsd. C veranschlagt und eine Laufzeit von TAC = 275 Tage. Die monatlich durchgeführte Erfassung ergibt nach 5 Monaten aktuelle Kosten von AC = 140 Tsd. C und einen Fertigstellungswert von EV = 130 Tsd. C. Der Planwert für diesen Zeitpunkt beträgt PV = 115 Tsd. C. Die Analyse ergibt folgende Kennzahlen: CV = EV  AC = 10 Tsd. C CPI = EV / AC = 0,928

SV = EV  PV = +15 Tsd. C SPI = EV / PV = 1,130

Der Projektfortschritt liegt also derzeit über Plan (+15 Tsd. C). Gleichzeitig ist aber der erreichte Istwert geringer als die verausgabten Kosten (10 Tsd. C). Möglicherweise wird das Projekt also schneller fertig als geplant, dabei aber höhere Kosten verursachen. J Die wichtigsten Kennzahlen der Earned Value Analyse sind in der Tab. 9.5 zusammengefasst. Aus der momentanen Fortschritts- bzw. Kostensituation des Projekts können auch Aussagen über den weiteren Verlauf und über das voraussichtliche Projektende abgeleitet werden. Hierzu sind aber verschiedene Annahmen nötig. Geht man davon aus, dass das Projekt wie bisher weiterläuft, müssen die bisher erreichten Werte AC und EV mit dem Planverlauf fortgeschrieben werden.

9.3 Kostencontrolling mittels Earned Value Analyse

235

EAC VAC

ETC

BAC

AC PV EV

SV / SPI

CV / CPI DAC

TAC

PAC

t

Abb. 9.7 Vorhersage des weiteren Projektverlaufs

Der in Abb. 9.7 dargestellte exemplarische Verlauf der Kostenkennzahlen des Projekts zeigt zum Zeitpunkt der Analyse zwei Probleme auf. Der Projektfortschritt ist geringer als geplant (EV < PV, SV < 0, SPI < 1). Außerdem liegen die tatsächlichen Kosten, deutlich über dem bislang geschaffenen Wert (EV  AC, CV  0, CPI  1). Daher ist es auch nicht erstaunlich, dass die Prognose sowohl einen Zeitverzug für das Projektende als auch deutliche Mehrkosten ergibt. Die proportionale Fortschreibung des bisherigen Verlaufs des Fertigstellungswerts ergibt einen neuen, voraussichtlichen Fertigstellungszeitpunkt (Plan at Completion PAC). Aus dem Verlauf der aktuellen Kosten kann zudem auf die voraussichtliche Projektkosten (Estimate at Completion EAC) hochgerechnet werden. Die Fortschreibung der bisherigen Verläufe ermöglicht die Bestimmung weiterer Kennzahlen, wie der voraussichtliche Zeitverzug für das Projektende (Delay at Completion DAC = PAC  TAC), die voraussichtlichen Mehrkosten (Variance at Completion VAC = EAC  BAC) und die geschätzten Restkosten (Estimate to Complete ETC = EAC  AC). Die so bestimmten Kennzahlen zur Vorhersage des Gesamtaufwands und der Gesamtzeit gehen davon aus, dass das Projekt so weiter läuft wie bisher. Verzögerungen und Mehrkosten, wie in Abb. 9.7 dargestellt, können wohl kaum ohne weiteres hingenommen werden. Stellt man zu einem Analysezeitpunkt fest, dass das Projekt unter Plan liegt, wird man versuchen, den Rückstand wieder aufzuholen und die Mehrkosten zu verringern. Hierzu gibt es verschiedene Eingriffsmöglichkeiten zur Steuerung des weiteren Projektfortschritts. Diese werden später im Rahmen der Projektsteuerung behandelt.

236

9

Kostenmanagement

Beispiel 9.5 EVA-Kennzahlen bestimmen (2)

Die Daten des Projekts aus dem vorangegangenen Beispiel 9.4 werden nun zur Bestimmung der Prognosekennzahlen für das Gesamtprojekt verwendet: EAC = BAC / CPI = 452 Tsd. C VAC = EAC  BAC = 32 Tsd. C ETC = EAC  AC = 312 Tsd. C.

PAC = TAC / SPI = 243 Tage DAC = PAC  TAC = 32 Tage

Gemäß dieser Hochrechnung auf das Gesamtprojekt wird es voraussichtlich 32 Tage früher abgeschlossen werden können, dabei aber 32 Tsd. C Mehrkosten verursachen. J

9.4 Weiterführende Literatur

Fleming, W.F.; Koppelman, J.M.: Earned Value Project Management. PMI, 4. Aufl. 2010. Ausführliche Erläuterung der Earned Value Analyse und deren Anwendung in der Projektsteuerung.

Qualitätsmanagement

10

Qualität bildet eine der drei Dimensionen des Projekt-Zieldreiecks. Dies verdeutlicht ihre große Bedeutung im Rahmen von Projekten. Im vorliegenden Kapitel erhalten Sie zunächst eine einleitende Übersicht des mittlerweile sehr umfangreichen Fachgebiets, um sich orientieren und Methoden einordnen zu können. Maßnahmen zur Sicherstellung der geforderten Qualität sollten heute fester und durchgängiger Bestandteil aller Arbeitsprozesse eines Unternehmens sein. Deshalb wurden die Anforderungen an die Gestaltung von Qualitätsmanagementsystemen (QMS) in einer ganzen Reihe von Normen festgelegt. Sie stellen mittlerweile eine Vorlage für viele andere Managementsysteme dar, so auch für den Aufbau von QMS in Projekten. Die Grundprinzipien und das QM-Modell dieser Normenreihe, werden in einem eigenen Abschnitt vorgestellt. Die Ausdehnung des Qualitätsbegriffs vom Produkt auf das ganze Unternehmen, die Etablierung der Qualitätsverbesserung als ständige Aufgabe und die Verschlankung der umfangreichen Prozesse auf die wertsteigernden Teilprozesse ist das Ziel einiger Methoden, wie Total Quality Management, Lean Management oder der kontinuierlichen Verbesserung. Sie gehen deutlich über das reine QM hinaus und werden als qualitätsorientierte Managementkonzepte beschrieben. Viele allgemeine QM-Methoden und auch die grundlegenden Managementkonzepte werden zunehmend für das qualitätsorientierte Management von Projekten genutzt. Sie kommen in den Projektprozessen Qualitätsplanung, -lenkung und -sicherung zum Einsatz und werden an Beispielen beschrieben.

Nach der Bearbeitung des Kapitels sind Sie in der Lage,  die Bedeutung der Begriffe Qualität, Qualitätsmanagement und Qualitätsmanagement-System zu erläutern,

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 237 W. Jakoby, Projektmanagement für Ingenieure, https://doi.org/10.1007/978-3-658-32791-0_10

238

10

Qualitätsmanagement

 die objektive produktorientierte, die subjektive kundenorientierte und die relative kostenorientierte Sichtweise von Qualität zu erläutern und die Unterschiede zu erklären,  die Bedeutung der ISO 9000-Normenfamilie für das Qualitätsmanagement und die darin verwendeten Grundsätze zu erklären,  das QM-Prozessmodell mit seinen wichtigen Hauptprozessen und deren Beziehungen zu skizzieren,  das im Namen zum Ausdruck kommende, dreiteilige Konzept von TQM in eigenen Worten zu erläutern,  zu erklären, wie die derzeitige Weiterentwicklung des QM zu einem qualitätsorientierten Management von Unternehmen mit Hilfe von TQM, Lean Management, KVP und von Reifegradmodellen für ein qualitätsorientiertes PM genutzt werden kann,  die Aufgaben der Qualitätsplanung und deren Umsetzung beim Quality Function Deployment in eigenen Worten zu beschreiben,  die Aufgaben und Methoden der Qualitätslenkung als Bestandteil eines Wirkungskreises zu erläutern,  zu beschreiben, wie die Qualitätssicherung als Mittel zur stetigen Verbesserung der QM-Methoden in Projekten genutzt werden kann.

10.1 Qualität 10.1.1 Definition des Qualitätsbegriffs In der Umgangssprache, aber auch in der Fachsprache wird der Begriff Qualität in sehr unterschiedlichen Zusammenhängen und auch mit unterschiedlicher Bedeutung verwendet. So ist z. B. oft von hoher Qualität eines Produkts die Rede oder gar von höchsten Qualitätsanforderungen. Auch die Werbung bedient sich gerne der Qualität zur Charakterisierung eines Produkts. Andererseits weisen Produktrückrufe immer wieder auf Qualitätsmängel hin. Der Begriff des Qualitätsmaßstabs deutet auf eine kontinuierliche Skala zur Messung von Qualität hin, während ein Qualitätsniveau eher für eine gestufte Skala spricht. Es existieren zahlreiche Definitionen des Begriffs. Qualität wird z. B. bezeichnet als „das, was der Kunde will“, als „die Eignung zum Gebrauch“ (Juran), als „der Grad der Übereinstimmung mit Anforderungen“ (Crosby), oder als „der Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt“ (ISO). Trotz aller Vereinfachungen und Zuspitzungen, die in solch knappen Definitionen enthalten sind, weisen die Begriffsbestimmungen einige wesentliche Gemeinsamkeiten auf.

10.1 Qualität

239

Qualitätsaussagen beziehen sich immer auf Anforderungen, die ein Produkt erfüllen muss. Im Weiteren wird nun folgender Qualitätsbegriff zugrunde gelegt: I

Die Qualität eines Produkts wird bestimmt durch den Grad, in dem es die gestellten Anforderungen erfüllt. Oder noch kürzer:

I

Qualität ist Anforderungserfüllung.

Auch wenn man bei Produkten vorwiegend an materielle Objekte denkt, müssen auch Dienstleistungen, wie sie z. B. von Verwaltungen, im Gesundheitswesen oder der Unterhaltungsbranche erbracht werden, sowie immaterielle Objekte, wie z. B. Software, Filme oder Musik als Produkte angesehen und in die Qualitätsbetrachtung mit einbezogen werden. Wenn im Folgenden von Produkten gesprochen wird, so gilt dies immer in diesem umfassenden Sinne. Produkte können also sein: materielle Objekte, Dienstleistungen oder immaterielle Objekte. Diese Betrachtung gilt auch für Projekte. Jedes angestrebte Ergebnis in einem Projekt ist ein Produkt und es wird eine bestimmte Qualität besitzen, in dem Maße, wie es die gestellten Anforderungen erfüllt. Jedes Produkt besitzt viele Merkmale, wie z. B. Größe, Gewicht, Farbe, Preis. An einige dieser Merkmale stellen Kunden Anforderungen, an andere nicht. Alle Merkmale, für die Anforderungen zu erfüllen sind, werden als Qualitätsmerkmale bezeichnet. Erfüllt ein Produkt diese Anforderungen, so wird von einer ausreichenden Qualität des Produkts gesprochen. Sind wichtige Anforderungen nicht erfüllt, ist die Qualität nicht gegeben. Es handelt sich hierbei also um Muss-Anforderungen. In der Praxis gibt es oft auch weitere Anforderungen, deren unvollständige Erfüllung zwar zu schlechterer, aber immerhin noch akzeptabler Qualität führen. Sie könnte man als Soll-Anforderungen bezeichnen. Die Qualität ist umso besser, je höher der Grad der Erfüllung der Soll-Anforderungen ist. Die Qualität bezieht sich also immer auf ein Produkt als Ganzes. Sie wird ermittelt anhand aller einzelnen Merkmale, für die Anforderungen zu erfüllen sind. Die so ermittelte Qualität ist in der Regel eine stetige, stufenlose Größe. Sie kann aber mit Hilfe bestimmter Anforderungsniveaus auf gestufte Aussagen (Qualitätsniveaus), im einfachsten Fall sogar auf eine einzige binäre Aussage reduziert werden. Beispiel 10.1 Qualitätsbewertung Fallbeispiel „CAD-System“

Im Fallbeispiel „CAD-System“ wurde eine Lösung realisiert, deren Qualität nun bewertet werden soll. Als Zielvariablen wurde der Funktionsumfang (gemessen von 0 bis 100 %), die Handhabungsnote (Note 5,0 bis 1,0), die Möglichkeit des Alt-DateiImports (nein/ja) und die Eignung für das Betriebssystem Linux (nein/ja) festgelegt. Die Wertebereiche werden zunächst normiert (von 0 bis 1). Dann werden drei Randbedingungen formuliert: der Funktionsumfang muss mindestens 80 % umfassen, die

240

10

Qualitätsmanagement

Abb. 10.1 Qualitätsüberprüfung für das Fallbeispiel „CAD-System“

Handhabung muss mit mindestens 3,0 benotet und der Datei-Import muss möglich sein (Siehe Abb. 10.1). Des Weiteren werden drei Gütekriterien und die zugehörigen Gewichtungen festgelegt: die Werte für den Funktionsumfang (50 %) und die Handhabung (40 %) sollen möglichst hoch sein und das CAD-System sollte (muss aber nicht!) für Linux geeignet sein (10 %). Mit den erreichten Istwerten kann die Qualität beurteilt werden. Alle Randbedingungen sind erfüllt. Bei den Gütekriterien wird ein Gesamtergebnis von 0,725 erzielt. Dieses Ergebnis kann entweder als relative Aussage über den Grad der Qualität übernommen werden oder es könnte auch für das Gesamtergebnis eine Randbedingung für das Erreichen der Qualitätsbedingung festgelegt werden. Länge diese z. B. bei 70 %, wäre die Qualität bei der erreichten Lösung gegeben. J

10.1.2 Sichtweisen der Qualität Um die Qualität von Produkten zu überprüfen und zu sichern, ist es notwendig zum einen die Anforderungen der Kunden an das Produkt zu kennen und zum anderen die Beschaffenheit des hergestellten Produkts anhand seiner Qualitätsmerkmale zu ermitteln. Werden die Anforderungen erfüllt, ist die Qualität gegeben. In dieser Betrachtungsweise ist Qualität objektiv: Kennt man alle Merkmale eines Produkts, kennt man seine Beschaffenheit. Kennt man die Werte aller Qualitätsmerkmale, also aller Merkmale für die es Anforderungen gibt, kennt man die Qualität des Produkts. Aber die Verhältnisse sind nicht immer so klar, wie in diesem Idealfall. Bei Massenprodukten hat der Hersteller keinen direkten Kontakt mit den Kunden und es gibt auch kein vollständig homogenes Anforderungsprofil aller Kunden. Hier ist der Hersteller selbst verpflichtet, ein Anforderungsprofil so festzulegen, dass er die Anforderungen der abstrakten „Kundschaft“ erfüllt. Auch bei einem Projekt können derartige Probleme auftreten, da die Auftraggeber des Projekts und die Nutzer des beauftragten Ergebnisses oft nicht identisch sind. Sofern die Herstellung des Produkts nicht durch einen individuellen Kaufvertrag mit dem Kunden geregelt ist, wird es zwischen der objektiv gemessenen Qualität und der subjektiv empfundenen Kundenzufriedenheit Abweichungen geben. Sobald mehrere Personen oder Gruppen Anforderungen festlegen, werden diese nicht vollständig deckungs-

10.1 Qualität

241

gleich sein. Dies gilt natürlich in besonderem Maße für Massenprodukte. Die Bandbreite der Zufriedenheit der Anforderungssteller ist hier oft beträchtlich, was die Festlegung des Anforderungsprofils durch den Hersteller erheblich erschwert. An dieser Stelle hilft die dritte Sichtweise. Qualität ist relativ zu sehen, nämlich in Relation zu den Kosten. Qualität ist nicht nur eine binäre Eigenschaft (erfüllt oder nicht erfüllt), sondern sie kann auch mehr oder weniger erfüllt sein. Da sich Qualität aus mehreren Merkmalen zusammensetzt, können sogar einige Merkmale eine sehr gute Erfüllung und andere eine schlechte Erfüllung der Anforderungen aufweisen. Hier setzt dann das Zusammenspiel mit den Kosten ein: Qualität und Kosten weisen eine starke wechselseitige Kopplung auf. Eine höhere Produktqualität verursacht höhere Kosten. Kunden, die höhere Qualität fordern, sollten daher auch bereit sein, einen höheren Preis zu zahlen. Aus Sicht der Kunden ist daher zu fragen, welche Qualität für einen bestimmten Preis erwartet wird. In der Regel wird es ein Mindestniveau geben, das unabhängig vom Preis immer erfüllt sein muss. Über diesem Niveau werden Kunden das Verhältnis von Preis und Qualität bewerten. Aus Sicht des Herstellers ist zu fragen, zu welchen Kosten eine bestimmte Qualität erreicht werden kann. Des Weiteren muss ein Hersteller die Kosten für die Sicherstellung einer bestimmten Qualität mit den Kosten der Nichterfüllung der Qualitätsanforderungen vergleichen. In den Zeiten der zunehmenden Vernetzung sind aber auch die Anforderungen und die Kosten für das Umfeld des Unternehmens bis hin zur gesamten Gesellschaft zu berücksichtigen. Beispiel 10.2 Fallbeispiel „Maschinenterminal“ – Qualitätssichtweisen

Für das Maschinenterminal gibt es verschiedene Gruppen, die Anforderungen stellen können, wie z. B.    

die Geschäftsleitung als Auftraggeber für das interne Entwicklungsprojekt, die potentiellen Kunden, die das Terminal einsetzen, die Entwicklungsabteilung als Auftragnehmer, die Vertriebsabteilung, die durch das neue Gerät mehr Umsatz generieren soll.

Objektive Anforderungen sind z. B. das Vorhandensein bestimmter Schnittstellen am Gerät zur Erfassung und Ausgabe von Daten, das IP-Schutzniveau gegen das Eindringen von Staub oder Feuchtigkeit oder das Einhalten einer maximalen Obergrenze für den Gerätepreis. Als subjektiv muss die Forderung einer „ergonomischen“ Benutzerschnittstelle eingestuft werden. Ungeübte Benutzer werden hier eine vollkommen andere Vorstellung von Ergonomie haben, als regelmäßige Benutzer des Terminals. Bei einem einfachen Kompromiss sitzt man hier sehr schnell zwischen allen Stühlen: Für Ungeübte ist die Schnittstelle zu kompliziert, für die anderen zu umständlich. Auch die Sicht der Entwicklungsabteilung, des Vertriebs und der Geschäftsleitung unterscheiden sich ganz deutlich. Die Entwicklungsabteilung würde das Gerät unter

242

10

Qualitätsmanagement

Verwendung ganz neuer Bauteile vollkommen neu entwickeln. Die Geschäftsleitung bevorzugt eine kostengünstige Entwicklung, die möglichst viele Komponenten aus dem alten Gerät wiederverwendet. Der Vertrieb hätte gerne ein neues, deutlich leistungsfähigeres, aber gleichzeitig konkurrenzlos preiswertes Gerät. J

10.1.3 Entwicklung des Fachgebiets Auch wenn das Qualitätsmanagement bereits eine recht lange Tradition aufweist, ist die Entwicklung des Fachgebiets bei weitem noch nicht abgeschlossen, sondern es befindet sich in einer andauernden Entwicklung. Die Notwendigkeit einer expliziten Qualitätssicherung kann mit der Anfang des 20. Jahrhunderts einsetzenden und rasch zunehmenden Arbeitsteilung erklärt werden. Solange ein Produkt vollständig von einer Person hergestellt wurde, war diese nicht nur für die Ausführung der Arbeiten, sondern auch für die Qualität des Ergebnisses verantwortlich. Die Sicherstellung einer ausreichenden Qualität erfolgte hier implizit und basierte auf der Expertise einer einzigen Person. Die zunehmende Spezialisierung bei den Arbeitsgängen machte eine Verteilung auf mehrere Personen notwendig. Wo früher ein Tischler ein Möbelstück mit dem Auftraggeber besprochen, die Rohstoffe ausgewählt, das Möbelstück komplett selbst gefertigt, persönlich ausgeliefert und dabei die Rückmeldung des Kunden unmittelbar erfahren hat, wurde der Ablauf in einer arbeitsteiligen Produktion auf viele Personen im Vertrieb, in der Herstellung einzelner Elemente, auf deren Montage und auf die Auslieferung aufgeteilt. Bei der stark arbeitsteiligen Produktion geht aber die unmittelbare Verantwortlichkeit für das Ergebnis verloren, so dass Qualitätssicherung als eigenständige Aufgabe und die Qualitätsabteilung als neue organisatorische Einheit im Unternehmen geschaffen werden musste. Sie dient dazu, am Ende des Produktionsprozesses die Beschaffenheit der hergestellten Produkte zu überprüfen und die Einhaltung der Anforderungskriterien sicherzustellen, indem fehlerhafte Produkte aussortiert oder nachgebessert werden. Die mit dem Ziel der Kostenreduktion eingeführte Massenproduktion machte dann die oft aufwändige, manuelle Qualitätssicherung zu einem Engpass. Es war kaum noch möglich, lückenlos alle Produkte zu kontrollieren. Man beschränkte sich deshalb auf Stichproben. Mit Hilfe statistischer Methode wurde dann aus den Prüfergebnissen der Stichprobe auf die gesamte Produktion hochgerechnet. Fehler im Produktionsprozess wurden durch diese statistische Prozesskontrolle erkannt und eliminiert. Durch die statistischen Verfahren rückte der Produktionsprozess in das Zentrum der Qualitätsbetrachtung. Nicht mehr das Erkennen fehlerhafter Produkte am Ende der Produktion war das wesentliche Ziel, sondern die Verbesserung des Produktionsprozesses, um dadurch die Zahl fehlerhafter Produkte zu verringern oder diese gar auf null zu senken. Die Verlagerung der Betrachtungsweise wurde durch den Begriff der Qualitätsverbesserung anstelle der bloßen Qualitätssicherung zum Ausdruck gebracht. Die wachsende Komplexität der Produkte und Produktionsprozesse, die stetig steigenden Anforderungsniveaus und die zunehmende Vernetzung aller beteiligten Prozesse

10.1 Qualität

243

führte dabei zu einer weiteren, deutlichen Ausweitung der Betrachtungsweise. Viele der neu entwickelten Methoden und Werkzeuge brachten aber nicht die erhoffte Wirkung, so dass sich schließlich die Erkenntnis durchsetzte, dass für den nutzenbringenden Einsatz qualitätsverbessernder Methoden auch eine vorbereitende Planung und eine den Einsatz begleitende Lenkung notwendig sind. Dies führte zur Etablierung des Qualitätsmanagements (QM). Die Notwendigkeit einer systematischen Handhabung aller qualitätserzeugenden und qualitätssichernden Maßnahmen führte im Laufe der 1980er Jahre zur Festlegung von Anforderungen an Qualitätsmanagementsystemen (QMS) durch die internationale Normenreihe ISO 9000. Im Unternehmen wurde nicht mehr nur der reine Produktionsprozess berücksichtigt, sondern alle Prozesse, also auch Konstruktion und Entwicklung, Beschaffung, Unternehmensführung sowie die Handhabung der Kundenbeziehungen. Diese wesentliche weiter gefasste Sichtweise von Qualität kommt im Begriff des Total Quality Management (TQM) zum Ausdruck. Den Zusammenhang und die zeitliche Aufeinanderfolge der verschiedenen Ansätze des Qualitätsmanagement zeigt Abb. 10.2. Diese Abbildung macht auch deutlich, dass die verschiedenen Maßnahmen sich nicht gegenseitig ablösen, sondern aufeinander aufbauen. Es handelt sich also nicht um „Moden“, sondern um eine stufenartige Weiterentwicklung der qualitätssteigernden Prozesse. Das Thema Qualität und Qualitätsmanagement hat Eingang in sehr viele Normen gefunden. Von zentraler Bedeutung für das Thema QMS ist die Normenfamilie ISO 9000 ff. Eine ganze Reihe verschiedener Leitfäden für verschiedene Teilgebiete des Qualitätsmanagement sind in den Normen ISO 10001 ff zu finden. Da diese Normen für eine möglichst umfassende Gültigkeit sehr allgemein gehalten sind, gibt es für viele branchenspezifische Normen, die die Anforderungen an QM und an QMS für die jeweilige Branche konkretisieren. Beispiele hierfür sind die Automobilindustrie (VDA 6), die Medizintechnik (ISO 13485) oder die Telekommunikationstechnik (EN 9100 ff). Die Arbeiten auf dem Gebiet der Qualität werden durch zahlreiche Vereine und Institutionen gefördert und unterstützt. In Deutschland ist dies die Deutsche Gesellschaft für Qualität (DGQ), in Europa die European Organisation for Quality (EOQ) und die European Foundation for Quality Management (EFQM) sowie in Amerika die American Society for Quality (ASQ). Diese Institutionen bieten heute vielfältige Qualifizierungsmaßnahmen an und sind an der Erstellung und Weiterentwicklung von Normen beteiligt.

TQM QMS Qualitätsmanagement Qualitätssteuerung Qualitätsprüfung 1900

1920

1940

1960

1980

Abb. 10.2 Entwicklungsschritte des Qualitätsmanagement

2000

2020

t

244

10

Qualitätsmanagement

10.1.4 Bedarf an Projekt-QM Die Erfüllung der Anforderungen ist doch im Allgemeinen sowieso das Ziel eines Projekts und insbesondere auch das Ziel des Projektmanagements. Wozu braucht man dann überhaupt ein dezidiertes Qualitätsmanagement in Projekten? Hierfür kann man im Wesentlichen drei Gründe nennen: Fokussierung auf die Anforderungserfüllung, Systematisierung der Methoden und Maßnahmen sowie Einbettung der Anforderungserfüllung ins Unternehmens-QM. Im Projekt werden viele Zwecke und Ziele verfolgt: am Ende eines Projekts muss ein Ergebnis abgeliefert werden, das Projekt sollte sein Budget einhalten und es sollte im Zeitrahmen bleiben, um nur die wichtigsten zu nennen. Allzu leicht geraten einzelne Anforderungen dabei aus dem Blickfeld. Ein dezidiertes QM im Projekt hält den Fokus auf die Gesamtheit der Anforderungen im Blick und sorgt zudem für den Abgleich zwischen widersprüchlichen Anforderungen. Die Erfüllung der Anforderungen benötigt an zahlreichen Stellen und in unterschiedlichen Phasen eines Projekts geeignete Prozesse, Methoden und Werkzeuge. Ein systematisches QM sorgt dafür, dass alle qualitätsorientierten Maßnahmen im Projekt zueinander passen und ein durchgängiges System bilden. Fehler und Reibungsverluste werden dadurch minimiert. Die qualitätsorientierte Planung und Steuerung aller Herstellprozesse stellt seit langem eine wesentliche Aufgabe in einem Unternehmen dar. Der Aufbau eines zertifizierten QMSystems und dessen stetige Weiterentwicklung ist mittlerweile unverzichtbar. Die Durchführung von Projekten fällt damit auch in den Gültigkeitsbereich eines QMS und es muss ebenfalls etabliert und auditiert werden. Das Projekt-QM ist daher ein Bestandteil des gesamten Unternehmens-QM. Es muss darin eingebettet sein und damit harmonisieren. Die Entwicklung des Qualitätsmanagements wurde wesentlich durch die Massenproduktion und den Einsatz statistischer Methoden forciert. Projekte sind aber ganz wesentlich durch ihren neuartigen und einmaligen Charakter geprägt. Daher ist oft zu hören, dass ein systemisches Qualitätsmanagement in Projekten nicht möglich wäre. Erstens war dies aber nie zutreffend und zweitens zeigen die derzeitigen Entwicklungen in Richtung des qualitätsorientierten Managements, dass auch ganze Unternehmen, bei denen immer wieder neuartige und einmalige Probleme auftreten, qualitätsorientiert geführt werden und dies gilt damit natürlich auch für Projekte. Deshalb werden nun Erkenntnisse, Methoden und Werkzeuge aus dem QM vorgestellt, die bei der Planung und Steuerung von Projekten benötigt werden.

10.2 Qualitätsmanagementsysteme

245

10.2 Qualitätsmanagementsysteme 10.2.1 Die Normenfamilie ISO 9000 ff Im Laufe der Entwicklung des Qualitätsmanagements hat sich das Methodenspektrum, das zunächst nur auf Qualitätsprüfung ausgelegt war, stetig ausgedehnt. Nach dem Produkt ist der Entstehungsprozess und dann das ganze Unternehmen ins Interesse der Aktivitäten gerückt. Zunehmend wird auch die Unternehmensführung in das QM eingezogen. Da neben der Produktprüfung dadurch auch viele planende und lenkende Aktivitäten erforderlich wurden, hat sich der Begriff des Qualitätsmanagements etabliert. Zudem setzt sich die Erkenntnis durch, dass Qualitätsmanagement nicht mit Hilfe einzelner, unabhängiger Methoden betrieben werden kann, sondern nur durch eine Einheit zusammenwirkender Maßnahmen. Dies kommt im Begriff des Qualitätsmanagementsystems zum Ausdruck: einem System für das Management der Qualität. Mit der Normenreihe ISO 9000 ff erschien 1986 der erste Weltstandard zum Thema Qualität. Die dynamische Entwicklung des Gebiets spiegelt sich in mehreren seitdem erfolgten umfangreichen Überarbeitungen dieser Normenreihe wieder, aber vor allem in der Zahl der insgesamt heute zum Thema Qualität und Qualitätsmanagement existierenden Normen. Die namensgebende ISO 9000 legt die Begriffe für QMS fest und beschreibt deren Grundlagen. Sie bildet damit die Basis für mehrere andere Normen, von denen die wichtigste die ISO 9001 ist. Sie definiert die Anforderungen, die an ein Qualitätsmanagementsystem gestellt werden. Die dort formulierten Anforderungen sind verpflichtend, d. h. sobald sich ein Unternehmen für sein QMS auf die ISO 9001 beruft, müssen die Anforderungen nachweisbar erfüllt sein. Nicht bindend, aber trotzdem sehr hilfreich ist die ISO 9004, die Anleitungen für das Leiten und Lenken für den nachhaltigen Erfolg einer Organisation gibt. Die ISO 9001 ist sehr umfassend angelegt und gilt für alle fachlichen Bereiche und für alle Branchen. Darauf aufbauend gibt es viele Normen, die QMS-Anforderungen für spezielle Teilbereiche festlegen. Für das QM in Projekten dient die ISO 10006. Sie stellt einen Leitfaden für den Aufbau eines projektspezifischen QMS dar, sie beschreibt den Verantwortungsbereich des Managements, die qualitätsorientierte Planung und Steuerung des Ressourceneinsatzes, der Prozesse und der stetigen Verbesserung in Projekten (Tab. 10.1).

Tab. 10.1 Wichtige QMS-Normen Norm, Nr., Jahr ISO 9000:2015 ISO 9001:2015 ISO 9004:2009 ISO 10006:2017

Inhalt QMS – Grundlagen und Begriffe QMS – Anforderungen Leiten und Lenken für den nachhaltigen Erfolg einer Organisation – Ein Managementansatz QM – Leitfaden für QM in Projekten

246

10.2.2

10

Qualitätsmanagement

Grundsätze der ISO 9000

Das erfolgreiche Leiten und Lenken von Organisation – egal ob Betriebe, Unternehmen oder Projekte – im Hinblick auf die Qualität der erzeugten Produkte wird in der ISO 9000 auf acht Grundsätzen aufgebaut. In diesen Grundsätzen kommt die große Bedeutung der Menschen zum Ausdruck. Die Hälfte der Grundsätze betrifft die Akteure. 1. Einbeziehung von Personen: Produkte werden von Personen für Personen gemacht. Ein QMS muss daher die Bedeutung der beteiligten und betroffenen Personen berücksichtigen und diese in die Festlegungen mit einbeziehen. 2. Kundenorientierung: Ohne Kunden fehlt die Geschäftsgrundlage. Daher ist es unbedingt notwendig, die Anforderungen der Kunden zu erfassen, sie zu verstehen und zu erfüllen. 3. Führung: Die Führungspersonen in einer Organisation setzen die Ziele, legen Rahmenbedingungen fest. Sie schaffen damit die Voraussetzungen für die Produktion und sind für die Qualität verantwortlich. Aber nicht nur das Vorgeben, sondern auch das Einhalten und das Leben der eigenen Vorgaben macht die Führung glaubhaft und sorgt für die nötige Identifikation. 4. Lieferantenbeziehung zum gegenseitigen Nutzen: Auch die Lieferanten sind Teil der Wertschöpfungskette. Ihr Beitrag und auch ihre Anforderungen müssen daher beim Aufbau eines QMS berücksichtigt werden. Nur wenn Lieferant und Unternehmen den Nutzen erkennen, wird das Zusammenwirken funktionieren. Die beiden nächsten Grundsätze definieren die Sichtweise auf das Unternehmen als Hersteller der Produkte. QM wird mittlerweile nicht mehr als eine lose Sammlung mehrerer Methoden, Maßnahmen und Werkzeuge gesehen, sondern ein QMS bildet eine Einheit verschiedener zusammenwirkender Prozesse. 5. Prozessorientierter Ansatz: Tätigkeiten können nicht isoliert, sondern sie müssen aus dem Blickwinkel der ablaufenden Prozesse betrachtet werden. Tätigkeiten dienen dazu, einen Input in einen Output zu wandeln, sie müssen von Personen ausgeführt werden und diese benötigen hierfür Ressourcen. 6. Systemorientierter Managementansatz: Die in einer Produktion ablaufenden Prozesse stehen untereinander in Wechselwirkung: der Output des einen ist der Input des anderen Prozesses, manche Prozesse müssen nacheinander ablaufen, andere können parallel liegen. Diese systemische Vernetzung muss bei allen Planungen und Steuerungseingriffen durch das Management berücksichtigt werden. Die beiden letzten Grundsätze verweisen auf die Bedeutung systematischer Problemlösungsprozesse und machen deutlich, dass die Problemlösung im Rahmen von QM kein einmaliges Ereignis, sondern ein nie endendes Bestreben sein muss.

10.2 Qualitätsmanagementsysteme

247

7. Sachbezogene Entscheidungsfindung: Dieser Grundsatz weist darauf hin, dass vor den Entscheidungen die Erfassung der sachlichen Informationen, also z. B. die Messung der tatsächlichen Ergebnisse und deren Auswertung zur Problemanalyse liegen muss, bevor über Lösungsmaßnahmen entschieden werden kann. 8. Ständige Verbesserung: Dieser Grundsatz beugt einer Illusion vor, dass der Aufbau eines QMS ein einmaliger Akt wäre. Eine Organisation ist eine dynamische Einheit in sich stetig wandelnden Umgebung. Daher ist eine ständige Verbesserung bzw. Anpassung einer Organisation kein Zeichen einer fehlerhaften Konzipierung des QMS, sondern eine unvermeidliche Bedingung.

10.2.3 Das QM-Prozessmodell Aus den Grundsätzen der ISO 9000 geht hervor, dass die Aktivitäten innerhalb des QMS prozessorientiert betrachtet werden. Die zahlreichen Prozesse, die in einer Organisation für ein QMS benötigt werden, sind natürlich von Branche zu Branche, von Unternehmen zu Unternehmen und möglicherweise von Produkt zu Produkt unterschiedlich. Um alle unterschiedlichen Fälle abzudecken, verwendet die Normenfamilie ein relativ allgemeines Prozessmodell einer Organisation. In diesem Modell sind sieben Hautprozesse definiert. Sie bilden drei Ebenen rückgekoppelter Wirkungskreise (siehe Abb. 10.3). Der innere Wirkungskreis besteht aus vier Prozessen. Er erhält Anforderungen der Kunden als Eingabe. Der Prozess „Betrieb“ setzt diese Anforderungen um und erzeugt das Produkt. Sowohl die objektive Beschaffenheit des Produkts als auch die subjektive

Abb. 10.3 Das QM-Prozessmodell (In Klammern Kapitelnummern der ISO 9001)

248

10

Qualitätsmanagement

Zufriedenheit der Kundschaft wird im Hauptprozess „Bewertung der Leistung“ erfasst und ausgewertet. Die Ergebnisse dieses Prozesses bilden die Grundlage für die Planungs-, Leitungs- und Koordinierungsaufgaben im Hauptprozess „Führung“. Aus den Festlegungen der Unternehmensleitung werden dann Entscheidungen für die „Planung“ der betrieblichen Abläufe abgeleitet. Dies beinhaltet das Bereitstellen der benötigten sächlichen Ressourcen, kompetenten Personals und der Infrastruktur sowie die Schaffung des geeigneten Arbeitsumfelds. In den Prozessen werden zahlreiche unterstützende Aktivitäten benötigt. Sie sind im Prozess „Unterstützung“ zusammengefasst. Die vier Hauptprozesse bilden einen geschlossenen Wirkungskreislauf. Dieser wird nicht nur einmal, sondern immer wieder durchlaufen. Damit die dabei auftretenden Probleme und gewonnene Erkenntnisse zur stetigen Weiterentwicklung der Abläufe und Ergebnisse führen, wird mit Hilfe des Prozesses „Verbesserung“ ein zweiter rückgekoppelter Wirkungskreis aufgebaut. Die Weiterentwicklung der gesamten Organisation ist das Ziel des äußeren Wirkungskreises. Die dazu gehörenden Aktivitäten sind im Prozess „Kontext der Organisation“ zusammengefasst. Die Schaffung geschlossener Wirkungskreisläufe, die das Ergebnis von Arbeiten immer wieder überprüfen, daraus Entscheidungen ableiten und daraufhin Maßnahmen zur Verbesserung festlegen und planen, ist ein wesentliches Merkmal in allgemeinen Problemlösungsprozessen und im QM im Besonderen. Diese Vorgehensweise basiert auf dem PDCA-Zyklus von Deming. Arbeiten werden geplant (Plan) und ausgeführt (Do). Die Ergebnisse werden überprüft (Check). Auf die dabei festgestellten Abweichungen von den angestrebten Zielen wird mit einer Modifikation der Planungen reagiert (Act). Derartige Zyklen sind nicht nur auf der gerade beschriebenen obersten Ebene des QMModells zu finden, sondern es gibt sie auf jeder Ebene und bei jedem Prozess. So setzt sich z. B. die Produktrealisierung aus den Teilprozessen Entwicklung, Beschaffung und Produktion zusammen. Jeder dieser Teilprozesse wird in einem eigenen PDCA-Zyklus geplant, ausgeführt, überprüft und verbessert. Dies setzt sich auch auf den darunter liegenden Ebenen bis zu den konkreten Arbeitsprozessen, wie z. B. „Kurbelwelle drehen“, „Programm testen“, „Ware kommissionieren“ fort. Auch hier werden die Arbeitsergebnisse überprüft und der Arbeitsvorgang wird erforderlichenfalls korrigiert. Jeder Prozess setzt also nicht nur den Input der Anforderungen in ein Arbeitsergebnis als Output um, sondern er wird als Bestandteil des QMS überprüft und analysiert. Auf Abweichungen wird mit der Modifikation der Planung und damit auch einer geänderten Ausführung reagiert. Erst dieser wiederholt durchlaufene Wirkungskreislauf führt zu einer stetigen Verbesserung. Durch die weitgehende Abstraktion wird in der Norm ein Prozessmodell geschaffen, das überall anwendbar ist, wo es um die Qualität von Produkten geht. Die ISO 9001 geht aber noch einen Schritt weiter und legt innerhalb der Hauptprozesse mehrere Teilprozesse fest, die ebenfalls sehr allgemeingültig sind, so dass die Anforderungen an die Prozesse normiert und für eine verbindliche Überprüfung verwendet werden können. Erst unterhalb dieser Ebene werden individuelle, d. h. branchen-, unternehmens- oder gar produktspezifische Festlegungen nötig.

10.2 Qualitätsmanagementsysteme

249

Die verschiedenen allgemeingültigen Teilprozesse eines QMS sind in der ISO 9001 benannt. Der wesentliche Inhalt der Norm ist die verbindliche Festlegung der Anforderungen an diese Prozesse. Die Norm legt zunächst in allgemeine QMS-Anforderungen fest. In den Abschnitten 4 bis 10 werden dann die Anforderungen an die einzelnen Prozesse innerhalb der 7 Hauptprozesse beschrieben. An dieser Stelle soll nicht im Einzelnen auf alle in der Norm definierten Unterprozesse eingegangen werden. Der Aufbau der Norm und die dort gewählte Vorgehensweise kann aber anhand des folgenden einfachen Beispiels verdeutlicht werden. Beispiel 10.3 Anforderungen für die Entwicklungsplanung

Der Prozess „Entwicklung von Produkten“ als Teil des in Abschnitt 8 der ISO 9001 behandelten Hauptprozesses „Betrieb“ wird in Abschnitt 8.3 der Norm in mehrere Teilprozesse untergliedert: 8.3.1 8.3.2 8.3.3 8.3.4 8.3.5 8.3.6

Grundlegendes Planung Eingaben Lenkung Ergebnisse Änderung

Für jeden dieser Teilprozesse werden Anforderungen festgelegt. Für den Teilprozess Entwicklungsplanung (8.3.2) beispielsweise wird dann konkret gefordert, dass die Organisation    

den Entwicklungsprozess in Phasen untergliedert, für die Entwicklungstätigkeiten Art, Dauer und Umfang festlegt, Verantwortungen und Befugnisse der Beteiligten beschreibt, die Bewertung, Verifizierung und Validierung der Ergebnisse festlegt.

Derartige Festlegungen sorgen für eine sinnvolle Gestaltung des Entwicklungsplanungs-Prozesses. Sie stellen überprüfbare Kriterien für eine spätere Auditierung des QMS dar. J Auch alle anderen Teilprozesse der Norm sind wie im vorangehenden Beispiel in Einzelprozesse zerlegt, für die dann konkrete Anforderungen benannt werden. Die Norm beinhaltet daher ein sehr detailliertes Anforderungsprofil für die Prozesse und Teilprozesse.

250

10

Qualitätsmanagement

10.3 Qualitätsorientierte Managementkonzepte (QoM) Der Fokus des QM hat sich im Laufe der Entwicklung des Fachgebiets stetig vergrößert. Er lag zunächst beim Endprodukt und wurde dann auf die betrieblichen Produktionsprozesse ausgedehnt. Als nächstes wurden dann auch die Prozesse der Entwicklung, der Zulieferung und der sonstigen Unterstützung ins QM einbezogen. Seit einigen Jahren werden auch für die Führungsprozesse QM-spezifische Anforderungen gestellt. Noch weiter gehen Konzepte, die das gesamte Unternehmen qualitätsorientiert zu führen. Aufgrund ihrer Wirkungen auf das Projektmanagement sollen hier das Total Quality Management, das Lean Management oder Reifegradbewertungen vorgestellt werden.

10.3.1 Total Quality Management Nach der Etablierung einzelner Methoden und Werkzeuge zur Sicherstellung der Qualität setzten seit den 1950er Jahren an verschiedenen Stellen Bestrebungen ein, die das Zusammenführen der Einzelteile zu einem durchgängigen System zum Management von Qualität zum Ziel haben. Die Etablierung der Normenreihe ISO 9000 ff. in den 1980er Jahren und ihre fast lückenlose Akzeptanz hat den Aufbau eines QMS und den Nachweis der Anforderungserfüllung zur Pflicht für moderne Unternehmen gemacht. Über die Systematisierung des QM hinausgehend sind mehrere Ansätze erkennbar, die den Begriff der Qualität und den Ansatz zu deren Management umfassender sehen. Sie werden unter dem Begriff des „Total Quality Management“ (TQM) eingeordnet. Die Entwicklung dieses umfassenden QM-Ansatzes wird seit vielen Jahren durch Preise angeregt und gefördert. Hierzu zählen seit 1951 der Deming Prize, seit 1987 der Malcom Baldrige National Quality Award in den USA und seit 1992 der EFQM Excellence Award in Europa. Die in einem Unternehmen zu ergreifenden Maßnahmen, um einen derartigen Preis zu erringen, sind freiwillig, verbessern die Position eines Unternehmens aber nachhaltig. In diesem Sinne können die TQM-Maßnahmen als „Kür“ im Vergleich zur „Pflicht“ eines QMS gesehen werden. TQM ist kein System neuer Methoden und Werkzeugen, sondern in erster Linie die Beschreibung einer umfassenden Zielsetzung. Das Neue ist die massive Ausdehnung der Betrachtungsweise von QM, die in der Bezeichnung „Total“ zum Ausdruck kommt. Die umfassende („totale“) Sichtweise wird an mehreren Stellen angewendet. Dies beginnt beim Begriff der Qualität. Während „nicht-totales“ QM unter Qualität die Beschaffenheit eines Produktes verstand, die oft mit anderen unternehmerischen Kostenund Terminzielen in Konkurrenz stand, wird nun bei TQM der Qualitätsbegriff umfassend verstanden. Die Qualität des Produktes ist eine Folge der Qualität der Arbeit, der Qualität der Prozesse und der Qualität des Unternehmens. Alle diese Qualitätsmerkmale werden deshalb in die Betrachtung mit aufgenommen (Abb. 10.4). Mit dieser Aufweitung der Qualitäts-Perspektive wird auch die ausschließliche Fokussierung auf die Anforderungen der Kunden an das Produkt beseitigt. In der umfassen-

10.3 Qualitätsorientierte Managementkonzepte (QoM) Abb. 10.4 Grundgedanken des Total Quality Management

Einbeziehung ... der Kunden ... der Mitarbeiter ... der Lieferanten

251

Q

T M

Qualität ... der Produkte ... der Prozesse ... der Arbeit ... des Unternehmens

Teamfähigkeit Lernfähigkeit Verantwortlichkeit

den Sichtweise von TQM werden Mitarbeiter, Lieferanten und die Führung nicht mehr nur als Erbringer von Leistungen betrachtet, sondern auch sie stellen neben den Kunden Anforderungen. Des Weiteren sollen auch die Ansprüche des Umfeldes und der Gesellschaft berücksichtigt werden. Das alleinige Ziel ist daher nicht mehr nur Zufriedenheit der Kundschaft, sondern auch die Zufriedenheit des internen Personals, der Lieferanten, der Unternehmenseigner und der Gesellschaft als Ganzes. Die umfassende Berücksichtigung der Anforderungen und des Qualitätsbegriffs macht auch ein weiter gefasstes Verständnis von Management zur Planung und Steuerung erforderlich. Die in QMS bereits definierten rückgekoppelten Wirkungskreise für die verschiedenen Prozesse müssen daher bei TQM auch auf übergeordnete Prozesse ausgedehnt werden. Durch die sehr weit gefasste Betrachtungsweise ist TQM trotz des „Q“ in Namen kein reines „Qualitätsmanagement“ im engeren Sinne mehr, sondern eigentlich ein umfassender Ansatz zum Management eines Unternehmens. Daher ist der Begriff auch nicht mehr in der aktuellen Fassung der ISO 9000 enthalten. Auf diesen Aspekt weist auch die parallel zu TQM verlaufende Zielsetzung der „Business Excellence“ hin. Hierunter versteht man die Gestaltung der Geschäftstätigkeit eines Unternehmens mit dem Ziel exzellente Ergebnisse zu erreichen. Die umfassende Sichtweise der Qualitätsverbesserung ist durch die Arbeiten von Deming konzeptionell und seit Feigenbaums Konzept des „Total Quality Control“ auch begrifflich auf der Agenda. Ein weiterer Vorläufer ist das Konzept des Company Wide Quality Control (CWQC) von Ishikawa. Trotz der nun schon mehrere Jahrzehnte andauernden Arbeiten auf diesem Gebiet kann das Konzept nicht als abgeschlossen bezeichnet werden. Dies ist zum einen wegen des umfassenden Ansatzes wohl nur schwer zu erreichen und zum anderen wegen des methodischen Anspruchs der ständigen Verbesserung auch gar nicht gewollt. Allerdings erschwert dieser Befund des „Work in Progress“ eine Einarbeitung in das Thema. In der Literatur sind sowohl inhaltlich als auch in der Anzahl divergierende „Grundgedanken“, „Prinzipien“, „Säulen“, „Pfeiler“ und „Bausteine“ des TQM zu finden. In umfassender Sichtweise lassen sich die Grundgedanken von TQM im Hinblick auf dessen Anwendung in Projekten unter 5 Prinzipien zusammenfassen:

252

10

Qualitätsmanagement

Qualität ist . . . . . . 1. das oberste Ziel, . . . 2. die Erfüllung der Anforderungen aller Betroffenen. Die Erreichung von Qualität erfordert . . . . . . 3. von allen Beteiligten ihre Verantwortung zu tragen. . . . 4. eine prozessorientierte Sichtweise, . . . 5. stetige Verbesserungen. Die ersten beiden Prinzipien legen die Bedeutung von Qualität in einem neuen, umfassenderen Sinne fest. Die drei weiteren Prinzipien beschreiben, wie die derart definierte Qualität erreicht werden kann. 1. Qualität ist das oberste Ziel. Der Erreichung, Sicherstellung und Verbesserung von Qualität wird bei TQM eine übergeordnete Bedeutung zugemessen. Alle anderen Ziele sind der Qualität untergeordnet. In seiner so genannten Reaktionskette hat Deming gezeigt, dass andere Faktoren, wie höhere Produktivität, geringere Kosten, höherer Marktanteil und Unternehmensgewinn Folgen der höheren Qualität sind. Nur wenn die Qualität stimmt, werden die Produkte vom Kunden angenommen und nur dann kann sich ein Unternehmen langfristig behaupten. Weitere Faktoren, wie z. B. Produktgestaltung, technische Features, bessere Produktionsbedingungen sind die Voraussetzung für Qualität. Sie erhalten ihre Berechtigung und Bedeutung daher ebenfalls nur aus der Qualität. 2. Qualität ist die Erfüllung der Anforderung aller Betroffenen. Mit der deutlichen Aufwertung der Qualitätsziele wird in TQM auch die Bedeutung der Begriffe „Qualität“ und „Kunde“ ausgeweitet. Neben den Käufern eines Produkts kommen nun auch die Anforderungen anderer Beteiligten zur Geltung, wie z. B. die Belegschaft, das Führungspersonals, die Lieferanten sowie das gesellschaftliche Umfeld des Unternehmens. Qualität bezieht sich dadurch mehr nur auf die Produktmerkmale, sondern auch auf die Merkmale des gesamten Entstehungsprozesses. Ein erstklassiges Produkt, das unter widrigen Arbeitsbedingungen für die Belegschaft und unter inakzeptablen Belastungen für die Umwelt zustande käme, hätte daher in diesem umfassenden Sinne keine zufrieden stellende Qualität. TQM öffnet damit den Weg von der Produktqualität zur Unternehmensqualität. 3. Qualität ist nur erreichbar, wenn alle Beteiligten ihre Verantwortung tragen. Das Recht, Anforderungen zu stellen, geht einher mit der Verpflichtung aller Beteiligten auch ihren Anteil an deren Erfüllung beizutragen. Alle an Unternehmensprozessen beteiligten Personen, die Unternehmensleitung voran, sind in TQM für die Qualität der Prozesse zuständig. Die Verantwortung für die Qualität beginnt bei der Geschäftsleitung.

10.3 Qualitätsorientierte Managementkonzepte (QoM)

253

Diese gibt nicht mehr nur die Ziele des Unternehmens vor und überprüft dann die Zielerreichung oder sanktioniert das Nichterreichen. Ziele zu definieren ist ein offener Vorgang, an dem auch alle davon betroffenen Personen beteiligt werden müssen. 4. Die Erreichung von Qualität erfordert eine prozessorientierte Sichtweise, Bei der prozessorientierten Sichtweise auf eine Produktion werden alle Arbeitsabläufe als zusammenwirkende Prozesse verstanden. Jeder Prozess erhält Eingaben (Input) von vorangehenden Prozessen und liefert Ergebnisse (Output) an nachfolgende Prozesse. In jedem Prozess sind Personen beteiligt und es werden Ressourcen genutzt. Das Kunden-Lieferanten-Verhältnis, das bislang nur zwischen den internen Lieferanten und den externen Kunden gesehen wurde, wird nun auf alle Prozesse übertragen: Jeder Beteiligte eines Prozesses ist Kunde der vorangehenden Prozessbeteiligten und Lieferant für die Beteiligten der nachfolgenden Prozesse. 5. Zur Erreichung von Qualität sind stetige Verbesserungen notwendig. Die klassische Sicht auf Maßnahmen des Managements, besteht aus dem Erkennen von Problemen, dem Setzen von Zielen, dem Erarbeiten und Einführen von Maßnahmen sowie dem Verifizieren der Wirksamkeit dieser Maßnahmen. Für einzelne Aufgaben und Problemlösungen gilt diese Vorgehensweise auch nach wie vor. In TQM wird dieser Ablauf aber als ein Zyklus betrachtet, der immer wieder durchlaufen werden muss. Die Erreichung und Sicherstellung der zufriedenstellenden Qualität ist kein einmaliger Vorgang mehr, der irgendwann beendet ist. QM ist ein nie aufhörender Vorgang, mit dem NullFehler-Zustand als Idealziel. Auch wenn dieses Ziel möglicherweise nie erreichbar sein wird, ist die kontinuierliche Verbesserung ein Wesensmerkmal von TQM. Im japanischen wird dies durch den Begriff Kaizen („Veränderung zum Besseren“) ausgedrückt, während im deutschsprachigen Raum von einem Kontinuierlichen Verbesserungsprozess (KVP) die Rede ist. Die hier formulierten Grundprinzipien fassen den Ansatz von TQM in komprimierter Form zusammen. Jedes Grundprinzip enthält eine ganze Reihe weiterer Merkmale. Die Grundprinzipien stellen aber keine Handlungsanleitung dar, sondern sie beschreiben allgemeine Ziele und Rahmenbedingungen für TQM. Im Gegensatz zu QMS gibt es kein einheitliches oder gar normiertes Modell, sondern es gibt viele unterschiedliche Wege, die versuchen, die beschriebenen Ziele zu erreichen.

10.3.2 Lean Management Wie TQM basiert auch das Lean Management auf vielen bekannten und einigen neuen Werkzeugen und Methoden des Qualitätsmanagements. Sie werden mit Hilfe einer übergeordneten „Philosophie“ und mit Hilfe mehrerer Grundprinzipien zu einem durchgängigen Konzept zusammengesetzt. Es basiert im Wesentlichen auf 5 Prinzipien: Kun-

254

10

Qualitätsmanagement

dennutzen, Wertschöpfungsprozesse, Prozessfluss, Pull-Prinzip und kontinuierliche Verbesserung. Kundennutzen: Ein Produkt wird hergestellt, um den Kunden einen Nutzwert zu liefern. Ihm muss daher bei allen Arbeiten und bei allen Entscheidungen im herstellenden Unternehmen die höchste Priorität eingeräumt werden. Die höchste Priorität des Kundennutzens – besser: der Qualität – ist ein Merkmal, dass auch in vielen anderen Systemen zum Management betrieblicher Prozesse zu finden ist. Wertschöpfungsprozesse: Damit der angestrebte Nutzwert eines Produkts am Ende der Herstellung erreicht wird, müssen alle beteiligten Prozesse ihren Anteil zum Wert liefern. Hierzu zählen nicht nur die Herstellprozesse, sondern auch die Prozesse zur Entwicklung und Gestaltung des Produkts, die unterstützemden Prozesse im Unternehmen und auch die gesamte Prozesskette der Zulieferung. Prozessfluss: Jeder beteiligte Prozess sollte einen kontinuierlichen Output liefern, damit auch die nachfolgenden Prozesse stetig arbeiten können und ihren Anteil an der Wertschöpfung liefern. Unnötiges Puffern von Prozessergebnissen, unproduktive Liegezeiten oder Transportwege sind daher zu vermeiden. Pull-Prinzip: In der klassischen Produktionsplanung wurden Arbeitsaufträge für die einzelnen Maschinen von einer übergeordneten Instanz geplant und in die Produktion gegeben. Auftretende Abweichungen von der Planung führen zu Überproduktion an bestimmten Stellen oder zu Wartezeiten an anderen Stellen. Beim Pull-Prinzip werden Aufträge nicht in die Produktion „gedrückt“, sondern durch die Prozesskette „gezogen“. Jeder Prozess reagiert auf die Anforderung seines Nachfolgeprozesses und erteilt selbst Aufträge an den vorgeordneten Prozess. Dadurch werden Teile immer nur dann und in genau der Menge produziert, wie sie gebraucht werden. Die bekannteste Methode, die das PullPrinzip verwirklicht ist Kanban. Bei dieser Methode zur Steuerung von Produktions- oder Lieferprozessen führt die Entnahme einer bestimmten Menge an Teilen durch einen Prozess unmittelbar zu einem Produktionsauftrag für den vorgelagerten Prozess. Dadurch ist nur die jeweils benötigte Menge der Teile vorrätig und es fällt keine überschüssige Lagerung an.

10.3.3 Kontinuierliche Verbesserung Kein Prozess wird auf Dauer so gut sein, dass er nicht verbessert werden kann. Zum einen werden immer wieder Erfahrungen gemacht, die zu einer Verbesserung führen können. Zum anderen ändern sich die Randbedingungen, unter denen ein Prozess arbeitet. Daher ist die Verbesserung eines Prozesses keine Aufgabe, die nur dann zu lösen ist, wenn ein Problem auftritt, sondern es handelt sich hier um eine Daueraufgabe. Daher müssen Verbesserungsmöglichkeiten aktiv gesucht und dann systematisch umgesetzt werden. Zur Verwirklichung dieser 5 Prinzipien werden im Lean Management zahlreiche Methoden und Techniken eingesetzt. Viele dieser Techniken dienen primär der Effizienzstei-

10.3 Qualitätsorientierte Managementkonzepte (QoM)

255

gerung der Produktion, wie z. B. Just-in-Time, Kanban, One-Piece-Flow oder Wertstromdesign. Fortschritte bei Produkten als auch bei Prozessen werden auf zwei Arten erzielt: durch Innovation und Progression. Erfindungen, neue Werkstoffe, neue Basistechnologien und Neuentwicklungen sorgen für sprungartige Entwicklungsschübe. In relativ kurzer Zeit kommt es zu starken Innovationen, die z. B. viele neue Funktionen, neue Produkte sowie ressourcen- oder eine kostensparende Produktion ermöglichen. Innovative Fortschritte erzielen hohe Aufmerksamkeit. Sie werden durch entsprechende Schlagworte verstärkt. Oft enthalten die neuen „Schläuche“ („Diruption“, „neue Paradigmen“, „neue Mindsets“) aber auch nur bekannten, alten Wein. Viel weniger Aufmerksamkeit erzeugen kontinuierliche Verbesserungen, deren methodische Umsetzung als „kontinuierlicher Verbesserungsprozess“ (KVP), „Continuous Improvement“ (CIP) oder „Kaizen“ bekannt sind. Trotz einiger Unterschiede im Detail weisen die genannte Methoden viele Gemeinsamkeiten auf: sie fokussieren auf die starke Einbindung der Personen, die im Prozess mitwirken und sie fördern das aktive Erkennen und Formulieren von Verbesserungsmöglichkeiten. Die beteiligten Personen kennen einen Prozess am besten. Sie erkennen Fehler und auch Verbesserungsmöglichkeiten. Schon lange gibt es deshalb an vielen Stellen ein betriebliches Vorschlagswesen. Es ist allerdings hinsichtlich der Entstehung von Vorschlägen und deren Umsetzung oft ein zufälliger Prozess. KVP, CIP und Kaizen setzen an diesem Problem an und machen aus der Generierung und aus der Realisierung von Verbesserungsvorschlägen einen aktiven und systematischen Prozess. Jede Iteration für die kontinuierliche Verbesserung stellt einen Problemlösungszyklus dar. Er kann, wie bereits beschrieben, in die Phasen study, plan, operate und check mit den entsprechenden Teilschritten untergliedert werden. Um aus dem allgemeinen Problemlösungsprozess einen kontinuierlichen Verbesserungsprozess zu machen, wird er durch spezielle Schritte erweitert (siehe Abb. 10.5). Zunächst wird ein so genannter Qualitätszirkel etabliert. Es handelt sich hierbei um eine feste Gruppe von Personen, die entweder selbst Verbesserungsvorschläge einbringen können oder eingegangene Vorschläge bearbeitet. Die Gruppe besteht aus etwa 5 bis 12 Personen. Sie treffen sich regelmäßig und bearbeiten freiwillig und selbständig auftretende Probleme und eingegangene Lösungsvorschläge. In der study-Phase untersuchen sie den Istzustand und formulieren den Zielzustand. Sie analysieren Wechselwirkungen im bestehenden Sachverhalt und suchen Ursachen für die aufgetretenen Probleme. In der plan-Phase entwickeln und bewerten sie Lösungsideen, bestimmen die zu deren Umsetzung erforderlichen Maßnahmen, den erforderlichen Aufwand und den erzielbaren Nutzen. Das Ergebnis der Analyse und Planung präsentiert der Qualitätszirkel einem Entscheidungsgremium. Dieses bewertet die Vorschläge verschiedener Qualitätszirkel und wählt die wichtigsten aus. Wird ein Verbesserungsvorhaben ausgewählt, werden mit dem Qualitätszirkel die erforderlichen Maßnahmen und Ressourcen vereinbart. Dann kann das Vorhaben zur Prozessverbesserung umgesetzt werden. In der Regel erfolgt dies zunächst

256

10

Qualitätsmanagement

Abb. 10.5 Problemlösung im Rahmen der kontinuierlichen Verbesserung

nur an einem Arbeitsplatz. Ist die Verbesserung erfolgreich, kann sie als Standard festgelegt und an alle anderen Arbeitsplätzen verwirklicht werden. Die beschriebene Vorgehensweise wird als PDCA-Zyklus bezeichnet, oft auch, nach seinem Erfinder, als Deming-Zyklus. Die Analyse eines Problems und die Planung einer Lösung ist hier in einer einzigen Phase („Plan“) zusammengefasst. Auf die testweise Realisierung („Do“) folgt die Erfolgsprüfung („Check“) und gegebenenfalls der Dauereinsatz („Act“). Dass dieser Problemlösungsprozess in einer stetigen Verbesserung eingesetzt wird, bringt der Begriff „Zyklus“ zum Ausdruck. Die stetige Verbesserung besteht aus vielen aufeinander folgenden PDCA-Zyklen. In vielen grafischen Darstellungen wird deshalb PDCA oft als Rad dargestellt, das sich entlang der langsam aufwärts strebenden Entwicklungslinie dreht.

10.3.4 Reifegradmodelle Güter und Dienstleistungen sind heute meist komplexe Produkte. Dementsprechend komplex sind auch die Arbeitsabläufe zu deren Herstellung. Der ökonomische Erfolg vieler Herstellungsprozesse basiert auf einer weitreichenden Zerlegung der Arbeitsabläufe in möglichst kleine Arbeitseinheiten. Die Effizienz einer derartigen arbeitsteiligen Produktion entsteht durch die hohe Wiederholungsgenauigkeit und -geschwindigkeit für die einzelnen Arbeiten. Der Erfolg der arbeitsteiligen Produktion legt es natürlich nahe, deren Vorteile auch auf die Produktion von Dienstleistungen oder immaterieller Produkte zu übertragen. In dieser funktionsorientierten Sicht wird eine Gesamtaufgabe in viele unabhängige Teilaufgaben – die Funktionen – zerlegt. Jede beteiligte Person, Gruppe oder Abteilung erfüllt ihre Aufgabe möglichst gut und macht sich dabei keine Gedanken darüber, welche Qualität

10.3 Qualitätsorientierte Managementkonzepte (QoM)

257

die zugelieferten Teile haben. Sie macht sich auch keine Gedanken darüber, was mit den Ergebnissen ihrer Arbeit weiter passiert. Praktische Erfahrungen mit dieser Arbeitsweise haben gezeigt, dass sie zwar oft zu lokal optimierten Abläufen führt, aber allzu oft Mängel bei den Gesamtergebnissen verursachen. Auf diese Misere wurde in zahlreichen Gebieten reagiert, indem man die einzelnen Abläufe als eine zusammenwirkende Einheit – als Prozess – betrachtet. Diese prozessorientierte Sicht liegt z. B. der Normenreihe ISO 9000, dem Total Quality Management und den verschiedenen Geschäftsprozessmodellen zugrunde. ISO 9001 fordert die Etablierung bestimmter Prozesse für die betrieblichen Abläufe. Im Rahmen der Auditierung wird dann überprüft, ob diese Prozesse im Unternehmen so ausgeführt werden, wie deren Beschreibung es fordert. Das Ergebnis ist eine Bescheinigung über die Übereinstimmung der tatsächlichen Abläufe mit den geplanten Abläufen. Einen ähnlichen Ansatz verfolgen so genannte Reifegradmodelle. Sie dienen dazu, das Kompetenzniveau einer Organisation hinsichtlich der Ausführung ihrer Prozesse zu ermitteln. In erster Linie wird im Reifegradmodell festgelegt, welcher Prozess bewertet werden soll, nach welchen Kriterien und mit welchen Parametern oder Indikatoren er bewertet werden kann. Der zu bewertende Prozess kann entweder im Reifegradmodell explizit beschrieben werden – in diesem Fall ist ein Prozessmodell Bestandteil des Reifegradmodells – oder der Bezug wird implizit mit Hilfe eines externen Modells hergestellt. Die Bestimmung des Reifegrads eines Unternehmens bezieht sich also immer auf die dort ausgeführten Prozesse. Die Bestimmung des Reifegrads beginnt daher bei den Prozessen. Für jeden Prozess wird gemessen, wie gut er im Unternehmen ausgeführt wird. Die so ermittelten Prozess-Fähigkeitsgrade werden dann zu einer Aussage über den Reifegrad des Unternehmens für die Gesamtheit der Prozesse zusammengefasst. Das Capability Maturity Model Integration (CMMI) ist ein Modell, das zur Bestimmung und Verbesserung des Reifegrads von Unternehmen dient. Arbeitsschritte, die sich im praktischen Einsatz bewährt haben – so genannte Praktiken – werden im CMMI gesammelt und Arbeitsprozessen zugeordnet. Die Anwendung der Praktiken in den Arbeitsabläufen soll dafür sorgen, dass die mit den Prozessen verbundenen Ziele erreicht werden. Vordergründig dient das Modell dazu, die Kompetenz eines Unternehmens in der Umsetzung der Arbeitsprozesse – seinen Reifegrad – zu messen. Liegen aber erst einmal Aussagen über den Reifegrad vor, ist dessen Verbesserung ein naheliegender nächster Schritt. Die Basis des CMMI bilden die Prozessgebiete (Process Area, PA), die alle Anforderungen zu einem Thema zusammenfassen. Prozessgebiete sind z. B. das Anforderungsmanagement (REQM), die Projektplanung (PP) oder die Projektverfolgung und -steuerung (PMC). Insgesamt sind in CMMI 22 Prozessgebiete definiert. Für jedes Prozessgebiet wird der Zweck beschrieben, es gibt erläuternde Hinweise und die bestehenden Beziehungen mit anderen Prozessgebieten werden benannt Zu jedem Prozessgebiet können mehrere spezifische Ziele (Specific Goals, SG) gehören, die durch die Aktivitäten des Prozessgebiets

258

10

Qualitätsmanagement

erreicht werden sollen. Für jedes Ziel wiederum gibt es mehrere spezifische Praktiken, durch deren Anwendung die Ziele erreicht werden sollen. Unter spezifischen Praktiken (Specific Practice, SP) sind keine abstrakten Aktivitäten zu verstehen, die aus theoretischen Überlegungen hergeleitet wurden, sondern es handelt sich um konkrete Handlungsmuster, die sich in der Praxis, in jahrelanger Anwendung als sinnvoll und brauchbar erwiesen haben. Sie beschreiben, was getan werden muss. Für das spezifische Ziel „Schätzungen etablieren“ beispielsweise wird die Praktik „Schätzung für Aufwand und Kosten festlegen“ näher erläutert, es werden Ergebnisse der Praktik aufgezählt (z. B. „Schätzgrundlagen“, „Aufwandsschätzungen“, „Kostenschätzungen“) und es werden Subpraktiken beschrieben, aus denen sich die Praktik zusammensetzt. Eine Praktik legt fest, was getan werden muss. Sie legt nicht fest, wie es getan wird. CMMI sagt also beispielsweise, dass der Bedarf der unterstützenden Infrastruktur in einem Projekt in die Schätzung einbezogen werden muss. Sie legt nicht fest, wie dieser Bedarf ermittelt bzw. kalkuliert wird. Anhand der Liste der Prozessgebiete kann ein Unternehmen überprüfen, ob die zugehörigen Praktiken angewendet und ob die Ziele erreicht werden. Zusätzlich kann mit Hilfe des CMMI auch überprüft werden, in welchem Maße die Ziele erreicht werden.

10.4 Qualitätsmanagement in Projekten 10.4.1 QM-Prozesse in Projekten Im Qualitätsmanagement wurde der Fokus beim Endprodukt beginnend über die Produktion, die Konstruktion und die Entwicklung auf alle im Unternehmen ablaufenden Prozesse ausgedehnt. Derartige Prozesse sind auch im Projektmanagement zu finden. Projekte sind daher heute ganz selbstverständlich auch ein QM-Anwendungsgebiet und die qualitätsorientierten Aktivitäten bilden neben vielen anderen wichtige Aufgaben innerhalb des Projektmanagements. In Projekten werden im Wesentlichen drei QM-Prozesse unterschieden (Abb. 10.6). In der Qualitätsplanung wird festgelegt, welche Maßnahmen und Methoden in einem konkreten Projekt zur Erreichung der Qualität zu ergreifen sind. Das Ergebnis ist ein Qualitätsmanagementplan, der die Vorgehensweisen und Abläufe als Bestandteil des QMS beschreibt. Ein weiteres wichtiges Ergebnis ist der Qualitätsplan, der aus den Projektzielen die konkrete Feststellung der Qualität des Produkts ableitet. Während der Durchführung des Projekts sorgt die Qualitätslenkung für das Umsetzen der Planung. Dazu werden die Fortschritte gemessen und die realisierten Liefergegenstände erfasst. Aus dem Vergleich mit den Plandaten werden notwendige Eingriffe abgeleitet und notwendige Änderungen beantragt. Die Wirksamkeit der Planungs- und Lenkungsmaßnahmen, die im QM-Plan festgelegt sind, wird durch die Qualitätssicherung überprüft. Sie dient zur kontinuierlichen Verbesserung des QM innerhalb von Projekten. Werden Fehler festgestellt oder neue Erkenntnisse

10.4 Qualitätsmanagement in Projekten

259

Abb. 10.6 Prozesse des Qualitätsmanagements

gewonnen, werden diese zur Weiterentwicklung und Verbesserung der Vorgaben und der eingesetzten Methoden genutzt. Die Qualitätssicherung ist vor allem nach Abschluss eines Projekts gefordert, um die generelle Fähigkeit eines Unternehmens für die qualitätsgerichtete Durchführung von Projekten zu verbessern. Projekte, die in Unternehmen durchgeführt werden, sind zunächst einmal in das Qualitätsmanagement-System des Unternehmens eingebettet. Auf viele allgemeingültige Regelungen des Qualitätshandbuchs und auf Institutionen der Qualitätssicherung kann daher in Projekten zurückgegriffen werden. Trotzdem stellt das QM in Projekten besondere Anforderungen. Die wichtigste Besonderheit von Projekten besteht darin, dass die geforderte Qualität nach einem einmaligen Durchlauf am Ende des Projekts erreicht sein muss und nicht wie in Routine-Prozessen durch eine schrittweise Verbesserung machbar ist. Die ISO 10006 ist eine Richtlinie für das Qualitätsmanagement in Projekten. Sie gehört zur Normenfamilie ISO 9000 und ihre Gliederung entspricht der ISO 9001. Es handelt sich bei der ISO 10006 nicht um eine Norm zur Festlegung des Projektmanagement an sich, sondern sie fokussiert auf den Qualitätsaspekt im Projektmanagement. In der Richtlinie werden Hilfestellungen für die Herstellung und Sicherung der Projektqualität in den verschiedenen PM-Teilprozessen gegeben, so dass es auch viele Gemeinsamkeiten mit bestehenden PM-Normen, insbesondere der ISO 21500 gibt. Den Kern der Richtlinie bilden die Maßnahmen die für die verschiedenen Prozesse im Rahmen der der Projektsteuerung erläutert sind. Die ISO 10006 ist daher als eine prozessorientierte Gliederung des Projektmanagements zu sehen, die mit anderen Gliederungsstandards, wie dem International Competence Baseline (ICB) der IPMA, dem Project Management Body of Knowledge (PMBOK) der PMI oder PRINCE2 viele grundlegende Gemeinsamkeiten, aber in Details auch einige Unterschiede aufweist. Die Richtlinie ist für alle Arten, Größen und Komplexitäten von Projekten ausgelegt. Sie stellt daher ein allgemeingültiges Rahmenwerk dar. Die konkrete Ausgestaltung der Prozesse, Aussagen über anzuwendende Methoden sowie der Aufbau der Dokumente muss unternehmensspezifisch und teilweise sogar projektspezifisch erfolgen. Die existierenden Standards bilden dabei sowohl eine Basis, auf der aufgebaut werden kann, als auch einen Rahmen, innerhalb dessen man sich bewegen sollte.

260

10

Qualitätsmanagement

10.4.2 Qualitätsplanung Die Durchführung eines Projekts kann angesehen werden als eine schrittweise Konkretisierung abstrakter Anforderungen. In der Projektgründung werden Anforderungen an das Projektergebnis analysiert und als Ziele formuliert. In der nächsten Phase wird daraus ein Produkt entworfen, was oft mehrere Iterationen erfordert. Aus den möglichen Lösungen und Lösungsvarianten wird dann die beste ausgewählt, detailliert geplant und realisiert. Auch hierfür können mehrere Iterationen notwendig sein. In der letzten Phase wird überprüft, ob die realisierte Lösung valide ist. Das Qualitätsmanagement begleitet diesen Weg, um sicherzustellen, dass die Anforderungen erfüllt werden. Damit die Anforderungserfüllung nicht erst am Ende überprüfbar ist, müssen in allen Zwischenschritten auch die bis dahin erreichten Teilergebnisse überprüft und eventuell korrigiert werden. Hierfür werden geeignete Methoden und Werkzeuge benötigt. Sie werden durch die Qualitätsplanung ausgewählt und an geeigneten Stellen des Arbeitsablaufs eingebaut. Die Überprüfung der Qualität der Zwischenergebnisse erfolgt oft an so genannten Quality Gates. Sie bilden „Tore“, die erst durchschritten werden können, wenn die Zwischenergebnisse die Anforderungen erfüllen. Ist dies nicht der Fall, sind Nacharbeiten nötig, bevor zur nächsten Ablaufphase fortgeschritten werden kann. Als Quality Gates bieten sich natürlich die Meilensteine des Projektablaufs an, aber es können durchaus auch zwischen den größeren Meilensteinen Quality Gates zwischengeschaltet werden. Eine der wichtigsten Methoden, die an mehreren Stellen entlang des Weges von den Anforderungen bis zum Projektergebnis eingesetzt werden kann, ist das Quality Function Deployment (QFD). Diese Methode dient dazu, Anforderungen an ein Produkt und mögliche Lösungsmerkmale zueinander in Beziehung zu setzen, um daraus Schlussfolgerungen zur Gestaltung der Produktmerkmale abzuleiten. QFD setzt das Konzept der strikten Kundenorientierung und der Einbindung aller Beteiligten in die Qualitätsprozesse in sehr systematischer Weise um. Die Methode wurde in den 1960er Jahren durch Akao in Japan entwickelt und eingesetzt, in den 1980er Jahren in den USA und seit den 1990er Jahren auch in Europa übernommen. Auch wenn die QFD-Methodik sehr umfangreich ist, basiert sie im Kern auf einer einfachen Gedankenkette. Den Ausgangspunkt der Untersuchungen bilden die Anforderung des Kunden („Was wird gefordert?“). Die Anforderungen werden vollständig erfasst und als hierarchisch gegliederte Liste dargestellt. Da in der Regel nicht alle Anforderungen gleich wichtig sind, wird für jede Anforderung eine Priorität festgelegt. Sie wird als Prioritätszahl ausgedrückt, z. B. von 1 bis 5 in aufsteigender Priorität. Jede Anforderung, die ein Kunde stellt, muss vom Lieferanten durch eine Lösungsfunktion bzw. durch ein Produktmerkmal erfüllt werden („Wie soll die Anforderung erfüllt werden?“). Alle vom Lieferanten geplanten Lösungsmaßnahmen werden deshalb ebenfalls in einer gegliederten Liste zusammengefasst. Nicht immer gibt es für eine Anforderung genau eine Lösungsmaßnahme. Oft wirken mehrere Maßnahmen für die Lösung einer Aufgabe zusammen. So kann z. B. die Minimierung einer Baugruppe sowohl Platz als

10.4 Qualitätsmanagement in Projekten

261

auch Gewicht sparen. Eine Gewichtsersparnis andererseits kann auch durch Verwendung eines leichteren Materials erreicht werden. Deshalb werden im dritten Schritt Anforderungen und Maßnahmen in Form einer Matrix gegenübergestellt. Die Anforderungen mit ihren Prioritäten werden in den Zeilen und die Maßnahmen in den Spalten einer Matrix angeordnet. In jeder Matrixzelle, die eine Maßnahme mit einer Anforderung verknüpft, kann nun angegeben werden, wie stark die Maßnahme zur Erfüllung der Anforderung beiträgt. Für diese Einflussstärke kann z. B. eine Skala von 0 (kein Einfluss) bis 3 (starker Einfluss) verwendet werden. Summiert man in einer Spalte der Matrix die Produkte von Anforderungspriorität und der jeweiligen Einflussgröße auf, so drückt das Ergebnis die Bedeutung jeder Maßnahme für die Gesamtlösung aller Anforderungen aus. Zur besseren Vergleichbarkeit kann die Einflussstärke auch relativ, als Prozentwert ausgedrückt werden. Aufbauend auf der Matrixdarstellung von Qualitätsanforderungen und Lösungsfunktionen nutzt QFD weitere Informationen, die an die Matrix angegliedert werden. Daraus entsteht eine Gesamtdarstellung, die als House of Quality (HoQ) bezeichnet wird (siehe Abb. 10.7). Die geplanten Lösungsmerkmale können sich gegenseitig positiv oder negativ beeinflussen. So wird z. B. die Verwendung eines besonders leichten Werkstoffs für eine mechanische Konstruktion deren Gewicht verringern, sich aber möglicherweise negativ auf deren Stabilität oder Preis auswirken. Um derartige gegenseitigen Korrelationen sichtbar zu machen, wird die Beeinflussungsmatrix der Lösungsmaßnamen oben („als Dach“) dargestellt. Unterhalb der zentralen Matrix können neben der bereits erläuterten absoluten bzw. relativen Bedeutung eines Lösungsmerkmals weitere Angaben gemacht werden. Sie werden oft unter der Fragestellung „Wieviel?“ zusammengefasst. Hierzu zählen mögliche Zielgrößen für ein Merkmal, wie z. B. „Gewicht kleiner 15 kg“, „Einarbeitungszeit klei-

5. Korrelaon der Merkmale

Wie 3. Lösungsmerkmale

Was 1. Kundenanforderungen 2. Anforderungsprioritäten

Warum 4. Korrelaon der Merkmale mit den Anforderungen

Wieviel 7. Bedeutung der Merkmale 8. Schwierigkeitsgrad 9. Webewerbsanalyse 10. Merkmalsausprägung

Abb. 10.7 Fragestellungen des House of Quality

6. Webewerbsanalyse

262

10

Qualitätsmanagement

ner 20 h“ oder „Speicherplatz größer 20 Mbyte“. Eine weitere interessante Angabe kann der Schwierigkeitsgrad für die Realisierung eines Lösungsmerkmals, z. B. in Form einer Punkteskala sein. Schließlich kann auch noch der Vergleich der eigenen Lösung mit Lösungen der Wettbewerber sehr informativ sein. Eine ähnliche Fragestellung kann auch für die Kundenanforderungen angestellt werden, indem auch hier das eigene Produkt mit dem Wettbewerb verglichen wird. Dies läuft dann unter der Fragestellung „Warum?“. Das Ziel der Untersuchung des House of Quality ist es also, die wichtigen Lösungsmaßnahmen zu erkennen und von den weniger wichtigen oder gar unwichtigen Maßnahmen zu unterscheiden. „Wichtig“ sind dabei die Maßnahmen, die zur Erfüllung der Kundenanforderungen den höchsten Beitrag leisten und die zu einer maximalen Abhebung vom Wettbewerb führen. QFD ist ein sehr detaillierter Prozess, der aus einer ganzen Reihe von Arbeitsschritten und Darstellungen besteht, die sehr viele Informationen beinhalten. Dies stellt für die Anwendung eine hohe Hürde dar. Die bereits vom QFD-Erfinder Akao formulierte Devise „Copy the spirit, not the form“ sollte aber jeden ermutigen, sich nicht von Formalitäten und Details abschrecken zu lassen, sondern den QFD-Gedanken auf die individuellen Fragestellungen eines Problems zu übertragen.

10.4.3 Qualitätslenkung Während der Projektdurchführung ist es die Aufgabe der Qualitätslenkung zu überprüfen, ob das Projekt auf dem richtigen Weg ist, um die Anforderungen zu erfüllen. Dazu muss der jeweils erreichte Qualitätsstatus erfasst und mit dem Plan verglichen werden. Die Erfassung der Istwerte und der Vergleich mit den Sollwerten bilden den Input für die Qualitätsregelkreise der Lenkung. Aus der Soll-/Istwert-Differenz leiten sie erforderliche Projekteingriffe oder auch Änderungsanträge ab. Alle Methoden zur Sicherstellung und zur Verbesserung der Qualität benötigen Informationen über die tatsächlichen Werte der Qualitätsmerkmale der Produkte. Bei der Umsetzung der Anforderungen an ein Projektergebnis in entsprechende Ziele, wird u. a. darauf geachtet, die Zielerreichung messbar zu machen. Deshalb werden Zielvariablen definiert, anhand derer die Erfüllung der Anforderungen messbar bzw. überprüfbar ist. Es kann sich hierbei um Variablen mit einem stetigen oder diskreten Wertebereich handeln oder auch um binäre Werte mit einer ja/nein-Aussage. Manche Zielvariablen können erst am Ende eines Projekts gemessen werden. Sie erlauben nur eine nachträgliche Kontrolle oder sie machen eine aufwändige Nacharbeit erforderlich. Besser ist es, wenn Zielvariablen bereits während des Projekts erfasst werden können, da so ein früherer korrigierender Eingriff möglich ist. Zur Darstellung und Dokumentation erfasster Qualitätsmerkmale eignen sich graphische Darstellungsmittel am besten. Sie sind für den Menschen sehr übersichtlich, da sie einen guten Überblick geben und eine schnelle Auswertung ermöglichen. Im Qualitäts-

10.4 Qualitätsmanagement in Projekten

263

management haben sich im Laufe der Jahre spezielle Darstellungsmittel etabliert, die als Qualitätswerkzeuge bekannt sind. Eine Fehlersammelliste stellt aufgetretene Fehler in Form einer Strichliste dar. Für den Aufbau einer solchen Liste müssen zunächst die möglichen Fehler benannt werden. Wenn nicht alle Fehler vorab bekannt sind, ist es sinnvoll, eine Kategorie „Sonstige Fehler“ vorzusehen. Die bei der Prüfung beobachteten Fehler werden dann als Strichliste gezählt. Dies ist bei einer manuellen Prüfung besonders einfach handhabbar. Eventuell kann die Erfassung in verschiedene Zeitintervalle eingeteilt werden, z. B. Fehler pro Tag, pro Schicht oder pro Stunde. Eine Fehlersammlung erlaubt eine Aussage über die Häufigkeit der aufgetretenen Fehler. Derartige Aussagen lassen sich in einem Histogramm übersichtlich darstellen. Darunter versteht man eine Balken-Darstellung der Häufigkeit bestimmter Merkmale. Eine Achse listet die möglichen Werte eines Qualitätsmerkmals auf. Auf der anderen Achse werden die Häufigkeitszahlen aufgetragen. Eine spezielle Form von Histogrammen sind Pareto-Diagramme. Bei ihnen werden die Merkmalswerte nach der Häufigkeit geordnet. Das Ergebnis ist daher ein Balkendiagramm mit stetig absteigender (oder auch aufsteigender) Balkenlänge. Diese Art der Darstellung ist eine wichtige Vorarbeit für die Pareto-Analyse. Sie hat das Ziel, die wichtigsten Einflussfaktoren für einen bestimmten Effekt zu finden. In sehr vielen Bereichen wurde herausgefunden, dass die Einflussfaktoren nicht gleich verteilt auftreten, sondern sehr oft starke Ungleichverteilungen aufweisen. Die so genannte 80/20-Regel sagt z. B. aus, dass in vielen Bereichen 20 % der Einflussfaktoren für 80 % der Wirkung verantwortlich sind. Übertragen auf die Qualitätsprüfung bedeutet dies, dass 20 % der Fehlerarten für 80 % aller fehlerhaften Produkte verantwortlich sind. Einen ähnlichen Ansatz verfolgt die ABC-Analyse, bei der alle Merkmale entsprechend ihrer Wichtigkeit in die Kategorie A (die wichtigsten), B und C eingeteilt werden. Die Erfassung der Qualitätsmerkmale ist der wichtige erste Schritt in der Sicherstellung einer ausreichenden Qualität. Im zweiten Schritt müssen aus den gewonnenen Daten der Produkte Rückschlüsse auf die zugrundeliegenden Prozesse gezogen werden. Insbesondere müssen im Prozess die Ursachen für beobachtete Produktfehler gefunden werden, um die Prozesse zu verbessern und Fehler nachhaltig zu vermeiden. Auch für diese Analyse erfasster Daten stehen verschiedene Methoden und Werkzeuge zur Verfügung. Die gemeinsame Sichtweise für viele Methoden ist die Betrachtung der Produktion als System. Dieses System besitzt als Eingaben die Anforderungen der Kunden, der Mitarbeiter, der Unternehmenseigner und des Umfelds. Die Ausgabe des Systems sind die Produkte. Innerhalb des Systems gibt es viele Produktionsfaktoren, wie z. B. die handelnden Personen, die Maschinen, Rohstoffe und Kapital. Zwischen diesen Faktoren bestehen wechselseitige Abhängigkeiten. Die wichtigsten Wechselwirkungen sind Kausalketten: ein Faktor verursacht eine Änderung bei einem anderen und diese Veränderung hat wieder weitere Reaktionen zur Folge. Durch die Rückwärtsverfolgung solcher Kausalketten kann man von den im Produkt beobachteten Fehlern zu den im Prozess liegenden Ursachen gelangen. Mehrere

264

10

Qualitätsmanagement

Methoden unterstützen diese Sichtweise und dienen dazu, Kausalitäten zu finden und zu verstehen. Eine solche Methode ist die Korrelationsanalyse. Sie versucht anhand von beobachteten Werten zweier Größen x und y, die zwischen diesen bestehende Wechselwirkung aufzudecken. Je größer die beobachtete Korrelation, desto stärker ist die zugrunde liegende Wechselwirkung. Die gemessene Korrelation wird dabei zur besseren Vergleichbarkeit mit Hilfe des Korrelationskoeffizienten r auf den Bereich zwischen 1 und +1 normiert. Ist der Korrelationskoeffizient gleich Null, besteht keine Abhängigkeit. Bei einer positiven Korrelation wirken beide Größen in die gleiche Richtung, d. h. steigt die eine, steigt auch die andere. Eine negative Korrelation drückt eine Gegenläufigkeit aus: steigt die eine Größe, so sinkt die andere. Steigt die Korrelation auf 1, sind beide Größen fest miteinander gekoppelt. Dies gilt auch bei einem Korrelationskoeffizienten von 1, bei dem die beiden Größen aber umgekehrt proportional verlaufen. Eine Korrelation besitzt eine starke Aussagekraft, aber es muss berücksichtigt werden, dass sie sich auf Beobachtungen beschränkt und für sich alleine keine zwangsläufigen Schlussfolgerungen über die zugrunde liegende Wechselwirkung zulässt. Erst eine weiter gehende Analyse kann hier Aufschluss und Hilfe für die Interpretation der Korrelationswerte geben. Sind z. B. zwei Größen sehr stark korreliert, ist nicht klar, welche der beiden die Ursache und welche die Wirkung ist. In Wirklichkeit ist noch nicht einmal klar ob es hier überhaupt einen Kausalzusammenhang gibt. Es könnte auch sein, dass beide Größen durch eine andere, dritte Größe verursacht werden und nur deshalb gekoppelt erscheinen. Aus diesem Grund liefert die Korrelationsanalyse wichtige Informationen über mögliche Abhängigkeiten, aber es sind nur Indizien, keine Beweise. Zur Aufdeckung von Kausalketten dient die 5-Warum-Fragetechnik. Sie versucht von einer beobachteten Wirkung, z. B. einem Fehler, durch wiederholtes Nachfragen zu den Ursachen zu gelangen. Die offensichtlichen, naheliegenden Ursachen eines Problems sind oft nur die Wirkung anderer, davor liegender Einflüsse. Durch das mehrfach wiederholte Nachfragen kann man die eigentlichen Ursachen führen. Die Zahl 5 ist dabei nicht unbedingt wörtlich zunehmen. Sie soll andeuten, dass man die Ursachenforschung bei verketteten Sachverhalten nicht vorschnell abbrechen darf, sondern mehrmals nachfragen sollte. Bei vielen beobachteten Fehlern gibt es nicht nur eine, sondern mehrere Ursachen. Die Qualität eines Produkts wird daher durch viele Faktoren positiv oder negativ beeinflusst. Ein von Ishikawa entwickeltes Hilfsmittel, um solche Einflussfaktoren zu finden und sie dann übersichtlich dazustellen, ist das Ursache-Wirkungs-Diagramm. Einflussgrößen werden im Diagramm als Pfeile dargestellt. Einzelne Größen werden zu Gruppen mit gemeinsamen Pfeilen zusammengefasst. Diese wiederum führen auf einen Hauptpfeil, der in der beeinflussten Größe mündet. In einer Serienproduktion können Qualitätsdaten kontinuierlich erhoben werden. Handelt es sich um Massenproduktion muss dies stichprobenartig erfolgen. In einem Projekt wird genau ein Produkt – das angestrebte Projektergebnis – hergestellt. Daher müssen auch für die Erfassung der Qualitätsdaten andere Bedingungen gelten. Eine permanente

10.4 Qualitätsmanagement in Projekten

265

Erfassung macht kaum Sinn, da weder ständig signifikante Änderungen auftreten, noch der erforderliche Aufwand gerechtfertigt wäre. Daher stellt sich die Frage, wann Qualitätsdaten in einem Projekt erfasst werden sollten. Die Erfassung der Qualitätsdaten ist integraler Bestandteil der Meilensteine: ein Meilenstein ist erst dann erreicht, wenn die eingeplanten (Zwischen-)Ergebnisse vorliegen, die die Anforderungen erfüllen. Darüber hinaus können auch zwischen den Meilensteinen weitere Quality Gates eingeplant werden. Sie sollten so verteilt sein, dass erkennbare Fortschritte vorliegen. Dies ist natürlich vom Projektinhalt und der Projektphase abhängig. Während des Entwurfs sind qualitative Fortschritte nur schwer messbar. Man verlässt sich hier zum Teil auf Mitarbeiterschätzungen, z. B. anhand der Restaufwandsschätzung. Etwas einfacher ist dies während der Realisierungsphase. In einem Programmierprojekt beispielsweise ist eine tägliche Inspektion des Programmcodes und ein regelmäßiger Test neuer Releases möglich. Von besonderer Bedeutung ist selbstverständlich die Qualitätserfassung am Projektende. Bei der Verifikation des Ergebnisses wird überprüft, ob alle Lieferungen und Leistungen des Pflichtenhefts in der zugesagten Quantität und Qualität vorliegen. Darauf baut dann die Validierung auf, die prüft, ob damit auch die Anforderungen der Auftraggeber erfüllt sind. Den letzten Schritt bildet dann die Abnahme des Projektergebnisses durch die Auftraggeber. Beispiel 10.4 Qualitätsplanung für ein Software-Projekt

In einem Entwicklungsprojekt soll eine neue Software für die Verwaltung der Lieferanten eines Fahrzeugherstellers erstellt werden. Die Planung der Qualität wird aus mehreren Maßnahmen zusammengesetzt. Mit dem Auftraggeber wird vereinbart, dass die Anforderungen in Form von „User Stories“ beschrieben werden. Dabei werden alle Anwendungsfälle, wie z. B. das Eingeben neuer Lieferanten, das Sortieren oder Filtern von Lieferanten nach verschiedenen Kriterien aus Anwendersicht beschrieben. Dadurch wird sichergestellt, dass die Anforderungen aus der Sicht und in der Sprache der Anwender formuliert sind. Dann wird vereinbart, dass für jeden Anwendungsfall ein Rapid Prototyp erstellt wird, der nur die Bildschirmmaske für die entsprechende Funktion mit allen Eingabeund Ausgabeelementen enthält. Diese Masken sollen vom Benutzer abgenommen und genehmigt werden. Dann wird die Software entworfen. Das entsprechende Entwurfsdokument wird von einem unabhängigen Entwickler gemeinsam mit dem Entwerfer in einem „Structured Walk Through“ besprochen. Erst danach erfolgt die Implementierung der einzelnen Software-Funktionen. Für jede Funktion werden bereits in der Entwurfsphase Testfälle festgelegt, die nach der Codierung durchzuspielen sind. Nach der der Implementierung der Funktionen werden daraus Module zusammengebaut und getestet. Sie werden anschließend schrittweise zum Gesamtsystem zusammengebaut. Für das vollständige System sind ebenfalls Be-

266

10

Qualitätsmanagement

dingungen für den Integrationstest festgelegt. Nach Abschluss aller internen Tests wird das Software-System für den Kunden übergeben. Dieser führt die Abnahme in dem Umfang durch, wie er bei der Auftragserteilung vereinbart wurde. J Eine weitere wichtige Aufgabe der Qualitätslenkung ist das Änderungsmanagement. Nur selten bleiben die Anforderungen, die Auftraggeber im Lastenheft dokumentiert haben über die gesamte Projektlaufzeit unverändert. Oft wird im Laufe eines Projekts festgestellt, dass Anforderungen vergessen wurden oder sich geändert haben. Die Änderung von Anforderungen zieht zusätzlich zu erbringende Leistungen nach sich. Sie sollten in der Regel daher nicht stillschweigend übernommen werden. Die Summe vieler kleiner Änderungen kann erheblichen Mehraufwand, zusätzliche Kosten und Verzögerungen zur Folge haben. Daher ist die Erfassung von Änderungen bei den Anforderungen, deren Analyse und die notwendige Korrektur der Planungen ein wichtiger Bestandteil des Qualitätsmanagements.

10.4.4 Qualitätssicherung Die Qualitätsplanung und -lenkung bildet einen rückgekoppelten Wirkungskreis, der das Projekt durch etliche Maßnahmen aus Sicht der Anforderungserfüllung auf Kurs hält. Immer wieder liefern die Anwendung der Methoden aus dem Baukasten des Projekt-QMS und vor allem das Auftreten von Problemen Erkenntnisse, die zu einer Verbesserung des Projekt-QMS beitragen können. Die Nutzung solcher Erkenntnisse, die Sicherstellung der Funktionsweise des Projekt-QMS und dessen stetige Verbesserung ist der Zweck der Qualitätssicherung. Ideen für die Verbesserung des Projekt-QMS können selbstverständlich schon während der Projektdurchführung entstehen. Wesentlich wahrscheinlicher ist es aber, dass nach Abschluss eines Projekts und nach Abnahme des erreichten Ergebnisses durch den Kunden offensichtlich wird, wo Anforderungen erfüllt bzw. nicht erfüllt wurden und wie solche Qualitätsmängel früher erkannt oder womöglich sogar verhindert werden können. Die Weiterentwicklung des Projekt-QMS sollte deshalb einen wichtigen Input aus der Projekt-Retrospektive erhalten. Wichtige Methoden zur Weiterentwicklung der qualitätsorientierten Prozesse können aus dem Unternehmens-QMS übernommen werden. Zur Verbesserung der Qualität der Arbeit kann ein projektinternes Vorschlagswesen oder ein im Unternehmen eventuell bereits etablierter Kontinuierlicher Verbesserungsprozess genutzt werden. Hierzu gehört auch der Einsatz von Qualitätszirkeln, die beim Auftreten grundsätzlicher Probleme gebildet werden. Die Wirksamkeit und der Nutzen eines Projekt-QMS stellen Werte auf einer kontinuierlichen Skala dar. Um diese Werte in einem Projekt bzw. in einem Unternehmen zu verbessern, muss er zunächst einmal gemessen werden. Hierzu dienen Reifegradmodelle, von denen es mittlerweile eine ganze Reihe gibt. Trotz etlicher Unterschiede im

10.4 Qualitätsmanagement in Projekten

267

Detail haben die verschiedenen Modelle viele Gemeinsamkeiten. Die notwendigen Arbeiten sowie deren Input und Output werden durch Prozessmodelle beschrieben. Für die Prozesse werden dann Fähigkeitsstufen festgelegt, mit denen gemessen wird, wie gut der jeweilige Prozess beherrscht wird. Die Gesamtsicht aller Prozessfähigkeiten wird dann zu einem Reifeniveau der Organisation, d. h. des Unternehmens oder der Prozessorganisation zusammengefasst. Die Kenntnis des Reifeniveaus und vor allem der Einblick in die Zusammensetzung der Reifebewertung ermöglicht es, Schwachstellen in einzelnen Prozess zu erkennen und diese dann zu verbessern. Als Beispiele für Reifgradmodelle können genannt werden:  CMMI, das im vorigen Abschnitt bereits erläutert wurde,  OPM3 (Organizational Project Management Maturity Model) des PMI,  P3M3 (Portfolio, Programme, and Project Management Maturity Model). Als weiterer Anreiz zur Qualitätssicherung werden so genannte Exzellenz-Modelle eingesetzt, wie sie im Rahmen des Total Quality Management zum Einsatz kommen. Beispiele hierfür sind verschiedene Qualitäts-Preise, wie z. B. der Ludwig-Erhard-Preis oder der Deming-Award, der „Excellence Award“ der EFQM sowie dessen Entsprechung in Projekten, der „Project-Excellence“-Modell der deutschen Gesellschaft für Projektmanagement. Das Excellence-Modell der EFQM, dient dazu, Unternehmen zu identifizieren und auszuzeichnen, die ein hervorragendes Qualitätsmanagement etabliert haben. Das Modell wurde durch die GPM für die Anwendung auf Projekte angepasst. Ziel dieses GPM-Exzellenz-Modells ist es zu beschreiben, welche Kriterien beim Management von Projekten und beim erreichten Ergebnis erfüllt sein müssen, damit Projekte als „exzellent“ bezeichnet werden können. Die Bewertung wird dann verwendet, um Projektteams in unterschiedlichen Kategorien mit dem „Project-Excellence-Award“ auszuzeichnen. Gleichzeitig kann dieses Modell auch genutzt werden, um die PM-Befähigung eines Teams zu beurteilen, Schwachstellen zu erkennen und so die Befähigung stetig zu verbessern. Um als exzellent bezeichnet werden zu können, muss ein Projekt nicht nur ein hervorragendes Ergebnis liefern, sondern es muss auch hinsichtlich des Managements ausgezeichnet sein. Diese beiden Bewertungsbereiche werden in 9 Hauptkriterien und diese wiederum in weitere Teilkriterien untergliedert (siehe Abb. 10.8). Bei der Suche nach Preisträgern, werden durch eine unabhängige Kommission im Rahmen eines Assessments die Kriterien überprüft und mit Punkten bewertet. Da die Kriterien und auch die Punktezuordnung offengelegt sind, können sie natürlich auch zur Selbstbewertung verwendet werden.

268

10

Qualitätsmanagement

Abb. 10.8 Kriterien der GPM zur Bewertung der „Project Excellence“

10.5 Weiterführende Literatur

Jakoby, W.: Qualitätsmanagement für Ingenieure. Springer Vieweg, 2019. Eine praxisnahe Einführung in das Thema QM. Preißner, A.: Projekterfolg durch Qualitätsmanagement. Hanser-Verlag, 2006. Eines der wenigen Bücher, die speziell das QM in Projekten behandeln. Bartsch-Beuerlein, S.: Qualitätsmanagement in IT-Projekten. Hanser-Verlag, 2000. Behandelt ebenfalls das QM in Projekten, mit dem Fokus auf IT-Projekte. Schmitt, R., Pfeifer, T.: Qualitätsmanagement. Hanser-Verlag, 5. Aufl 2015. Sehr umfassendes Werk, für eine allgemeine QM-Vertiefung.

Projektsteuerung

Während der Durchführung eines Projektes ist ein regelmäßiger Vergleich des Verlaufs mit den Projektplänen erforderlich. Dies ist die Aufgabe der Projektsteuerung (Abb. 11.1). In diesem Kapitel lernen Sie, welche Daten für die Erkennung des Projektfortschritts benötigt werden und wie sie erfasst werden können. Sie erfahren, wie die Ausführung eines Projekts so gesteuert werden kann, dass die Pläne möglichst eingehalten werden und wie auf Abweichungen von den geplanten Verläufen während der Projektdurchführung durch korrigierende Maßnahmen und durch die Anpassung der Planungen im Änderungsmanagement reagiert werden kann. Da ein Projekt erst dann erfolgreich ist, wenn es korrekt zu Ende gebracht wurde, werden Sie auch mit den Aktivitäten vertraut gemacht, die zum Abschluss eines Projektes notwendig sind.

Nach der Bearbeitung des Kapitels sind Sie in der Lage,  mit Hilfe eines formalen Berichtswesens und mit Hilfe informeller Abfragen den Fortschritt in einem Projekt zu erfassen,  aus einem Repertoire möglicher Reaktion auf Planabweichungen die im konkreten Fall passende auszuwählen,  nichtlineare Fortschritte bei den Leistungen durch geeignete Paketbildungen in lineare Zeitetappen umzusetzen,  eine Meilenstein-Trendanalyse durchzuführen,  den Projektfortschritt gezielt zu steuern,  die Aufgaben zu erläutern, die für einen richtigen Projektabschluss erforderlich sind.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 269 W. Jakoby, Projektmanagement für Ingenieure, https://doi.org/10.1007/978-3-658-32791-0_11

11

270

11

Projektsteuerung

Projektpläne

Projektabschluss

validierte Liefergegenstände

Änderungsman.

Fortschrissteuerung

korrigierende Maßnahmen Änderungsanträge

Projektüberwachung

Projektsteuerung

Fortschrisdaten

Arbeitsleistungsinformaon

Projektdurchführung

Abb. 11.1 Prozesse der Projektsteuerung

11.1 Projektüberwachung Projekte enthalten eine Vielzahl von Faktoren, die bei positivem Verlauf für den Erfolg ausschlaggebend sind, aber bei ungünstigem Verlauf auch zum Misserfolg führen können. Selbst bei gewissenhaftester Vorbereitung und Planung wird es bei der Durchführung eines Projekts zu Abweichungen vom geplanten Ablauf kommen. Hierfür sind viele nicht vorhersagbare externe Einflüsse, aber auch Fehler bei der Planung oder bei der Realisierung verantwortlich. Damit die Planabweichungen nicht zwangsläufig zu einer Verschlechterung des Ergebnisses oder gar einem Scheitern des Projekts führen, müssen sie rechtzeitig erfasst und es muss darauf reagiert werden. Dies ist die Aufgabe der Projektsteuerung. Das Ergebnis der Projektplanung ist ein terminierter Ablaufplan. Er bildet den Sollwert in einem Regelkreis, der von der Projektdurchführung und der Projektsteuerung gebildet wird. Der tatsächliche Projektfortschritt muss während der Durchführung regelmäßig erfasst und auf eventuelle Abweichungen gegenüber dem Plan überprüft werden. Treten Abweichungen auf, wird man in erster Linie versuchen, diese durch geeignete lenkende Eingriffe im Ablauf zu korrigieren. Gelingt dies nicht, kann es auch notwendig sein, den ursprünglichen Plan zu revidieren, um ihn der Wirklichkeit anzupassen. Die Forderung, den Projektfortschritt regelmäßig zu messen und auf Abweichungen vom Plan zu prüfen, um dann darauf reagieren zu können, klingt plausibel und verständlich. In der Praxis ist diese Aufgabe aber alles andere als einfach. Sie wirft eine ganze Reihe von Fragen auf, von denen die folgenden von besonderer Bedeutung sind:  Woraus besteht eigentlich der Projektfortschritt?  Wie kann er gemessen werden?  Wann muss er gemessen werden?

11.1

Projektüberwachung

271

11.1.1 Projektdatenerfassung Die naheliegenden Informationsquellen zur Bestimmung des Fortschritts, der in einem Projekt zu einem bestimmten Zeitpunkt erreicht ist, sind die entsprechenden Bearbeiter. Um die bei ihnen vorhandenen Informationen nicht nur sporadisch und zufällig zu erhalten, sollte ein Projektberichtswesen etabliert werden, bei dem die Fortschritte in Form von Statusberichten oder Änderungsberichten erfasst werden. Mit Hilfe von Berichten, auch wenn sie nur subjektiv sind, gelingt es, Informationen über den Fortschritt bei den Arbeiten zu erfassen [Peipe 2005]. Darüber hinaus sollte man mit Berichten aber versuchen, persönliche Einschätzungen zu objektivieren. Dazu sollte der Aufbau von Berichten den Verfassern nicht vollkommen frei gestellt werden. Der Aufbau sollte standardisiert werden, damit die darin gemachten Angaben vergleichbar werden und damit bestimmte wichtige Angaben immer enthalten sind. Hierzu gehören der Arbeitsaufwand laut Plan, der tatsächliche Arbeitsaufwand und der geschätzte Restaufwand. Für den Aufbau eines Berichts sollte es eine Vorlage geben, so dass wichtige Informationen immer enthalten sind und an den gleichen Stellen gefunden werden. Sehr gut bewährt haben sich kurze symbolische Zustandsangaben, z. B. in Form einer Ampel. Selbstverständlich muss ein Bericht ausreichend Platz für individuelle Darstellungen lassen, da die große fachliche Vielfalt der auszuführenden Arbeiten, der dabei auftretenden Probleme und kreativer Lösungen einen entsprechenden Spielraum benötigt. Den Aufbau und die Gestaltung eines Statusberichts zeigt exemplarisch das Statusbericht-Formular im Anhang. Um eine stetige Kontrolle des Fortschritts zu gewährleisten, müssen die Berichte zu festen, vorher festgelegten Zeitpunkten verfasst werden. Außerdem müssen die Berichte aussagekräftig und belastbar sein. Sie sollten die im abgelaufenen Berichtszeitraum geleisteten Arbeiten, die dabei erzielten Fortschritte und die aufgetretenen Probleme beschreiben. Außerdem sollten sie die geplanten Aktivitäten für den kommenden Berichtszeitraum enthalten. Damit der tatsächliche Fortschritt erkennbar wird, müssen konkrete Aussagen gemacht werden. Probleme, die bei der Abarbeitung auftreten, dürfen nicht verschleiert werden. Ein recht eindeutiges Anzeichen dafür, dass Berichte diese Anforderungen nicht erfüllen liegt vor, wenn aufeinander folgende Berichte immer wieder gleichartige Arbeiten, Aussagen oder Problembeschreibungen enthalten. Einprägsam kann man die Anforderungen an Berichte mit den drei „R“ zusammenfassen: Regelmäßigkeit, Rechtzeitigkeit und Richtigkeit. Neben der formellen Erfassung der Fortschritte durch Berichte sollte die Bedeutung informeller Abfragen nicht unterschätzt werden. Bei schriftlichen Berichten besteht eine Neigung, sich nicht unnötig festzulegen und auch keine Fehler zu dokumentieren. Daher fallen Berichte oft abstrakt und nichtssagend aus. Sie sind dann für eine Erkennung tatsächlicher Fortschritte und von konkreten Problemen kaum verwendbar. Ein persönliches Gespräch ist besser geeignet, den wirklichen Zustand des Arbeitspakets zu erkennen. Hier kann man auf Zwischentöne achten und bei Unklarheiten nachfragen. Jeder Projektleiter

272

11

Projektsteuerung

Abb. 11.2 Gantt-Diagramm eines Beispiel-Projekts

sollte sich daher nicht nur auf formale Abläufe verlassen, sondern regelmäßig auch einzeln mit den Mitarbeitern reden. Beispiel 11.1 Projektstatusberichte

Abb. 11.2 zeigt zum Stichtag Dienstag, 23.6. die Momentaufnahme eines Projekts, das am 10.6. begonnen wurde und am 3.7. abgeschlossen sein soll. Dem Projektleiter liegen folgende Rückmeldungen zu den Arbeitspaketen vor. AP1 ist abgeschlossen. Alle geplanten Funktionen wurden realisiert. Allerdings konnte das Paket nicht wie ursprünglich vorgesehen am Mittwoch, dem 17.6., sondern erst am Freitag, dem 19.6. abgeschlossen werden. Außerdem sind Mehrkosten von 20 % entstanden. AP2 ist in Bearbeitung. 75 % der vorgesehenen Zeit sind abgelaufen und die Mitarbeiterin ist optimistisch, die geforderten Funktionen in der geplanten Zeit fertig zu stellen. Die Kosten für AP2 liegen im Rahmen des Budgets. AP3 sollte eigentlich fertig sein. Laut Mitarbeiter gibt es allerdings noch kleinere „Restprobleme“. Er ist fest davon überzeugt, diese im Lauf der Woche lösen zu können. AP4 wurde aufgrund der Verzögerungen bei AP1 erst am Montag, dem 22.6. begonnen, so dass der Mitarbeiter noch nichts Konkretes sagen kann. Auf die Nachfrage, ob er die in AP1 verlorenen beiden Tage bis zum vorgesehen Abschlusstermin wettmachen kann, möchte er sich erst dann äußern, wenn er die Arbeit von AP1 genauer überprüft hat. AP5 kann derzeit noch nicht begonnen werden, solange AP3 nicht vollständig abgeschlossen ist. Der Auftraggeber möchte nun vom Projektleiter wissen, ob das Projekt erfolgreich abgeschlossen werden kann. J Ein Projekt dient dazu, eine im Lastenheft beschriebene Aufgabe zu lösen. Dabei müssen Beschränkungen bei den verursachten Kosten und vorgegebene Termine eingehalten werden. Ein Projekt ist dann erfolgreich, wenn zum vorgesehenen Termin ein Produkt vorgelegt wird, das alle im Lastenheft geforderten Funktionen erfüllt und der vorgegebene Kostenrahmen eingehalten wurde. Eine auf dieser Zieldefinition aufbauende Überprüfung der Kriterien Funktionalität, Kosten und Termine des magischen Projektdreiecks ist aber erst am Projektende möglich. Sie eignet sich daher für die Projektabnahme und die abschließende Bewertung; für eine Kontrolle und Steuerung des Projekts kommt sie zu spät.

11.1

Projektüberwachung

273

Projekte sind in Teilprojekten und Projektphasen gegliedert. Jedes Teilprojekt liefert ein überprüfbares Ergebnis. Außerdem werden Beginn und Ende der Projektphasen durch Meilensteine markiert, so dass eine Überprüfung der Resultate und der Termine auf der Ebene der Teilprojekte möglich ist. Allerdings kommt auch diese Überprüfung zu selten und zu spät, um Probleme rechtzeitig erkennen und korrigierend eingreifen zu können. Hierfür ist eine regelmäßige, in kürzeren Zeitabständen stattfindende Fortschrittskontrolle notwendig. An vielen Stellen wird deshalb eine ständige Fortschrittserfassung in Projekten gefordert. Allerdings wird es kaum möglich sein, den Fortschritt tatsächlich kontinuierlich zu messen. Bei jeder Arbeit kann es notwendige Phasen geben, in denen kein Fortschritt erkennbar ist. Wie oft scheint man sich bei der Lösung eines kniffligen technischen Problems im Kreise zu drehen, bis irgendwann die zündende Idee kommt. Fast immer bereitet das scheinbar erfolglose Probieren, Tüfteln und Grübeln den Nährboden für die unbewusst heran reifende Idee. Damit die Kreativität in einem Projekt nicht durch übertriebenes Ergebnisdenken abgewürgt wird, müssen auch Phasen erlaubt sein, in denen der Fortschritt nicht sofort erkennbar ist. Eine permanente Messung des Projektfortschritts erzeugt bei den Beteiligten den Eindruck eines übertriebenen Formalismus oder sogar ein Gefühl der Gängelung und lückenlosen Überwachung. Nur selten wird in einer solchen Atmosphäre kreativ gearbeitet. Nicht zuletzt spricht auch der erforderliche Aufwand gegen eine kontinuierliche Messung des Fortschritts. Der Aufwand für die Fortschrittserfassung muss in vernünftiger Relation zum erzielbaren Nutzen stehen. Ein sinnvoller Kompromiss ist es, den Fortschritt auf der Ebene der Arbeitspakete zu überprüfen. Sie liefern ein vorher festgelegtes und nachprüfbares Ergebnis und sie sind außerdem terminlich fixiert. Kleine Arbeitspakete, im Umfang von wenigen Tagen können dabei als Einheit erfasst werden. Bei größeren Arbeitspaketen sollte der Fortschritt auch zwischendurch kontrolliert werden. Aus diesem Gesichtspunkt scheint der Wochenrhythmus für viele Projekte ein geeignetes Zeitraster für die formalisierte, regelmäßige Fortschrittsmessung zu sein, wobei natürlich in kritischen Phasen zu kürzeren Zeiten gewechselt werden sollte. Außerdem sollte das Erfassungsraster durch informelle Abfragen weiter verfeinern werden. Woraus besteht nun der Fortschritt? Da die Kriterien des magischen Zieldreiecks, also Funktionalität, Kosten und Termine zur Beurteilung des Projekterfolgs herangezogen werden, ist es nahe liegend, auch den Projektfortschritt anhand dieser Kriterien zu messen. Die Erfassung direkt messbarer Parameter, wie z. B. der Kosten ist im Wesentlichen ein technisches oder organisatorisches Problem. Besitzt ein Unternehmen bereits die entsprechenden organisatorischen Strukturen und die technischen Hilfsmittel, so kann für ein Projekt darauf zurückgegriffen werden. Auch bei den geleisteten Arbeitsstunden – meist der wichtigste Kostenfaktor im Projekt – sollte es mit einer funktionierenden projektbezogenen Personendatenerfassung jederzeit möglich sein, den geplanten Arbeitsaufwand und den tatsächlich gebuchten Zeitaufwand gegenüber zu stellen. Oft sind es nicht die fehlenden technischen Möglichkeiten, die zu Nachlässigkeiten in diesem Punkt der Kontrolle führen, sondern Zeitmangel bei

274

11

Projektsteuerung

Tab. 11.1 Ermittlung des Fertigstellungsgrads (FGR, in 0–100 %) Methode Merkmale A B Meilenstein-Methode PP M FGR durch erreichte Meilensteine bestimmt. Grob. Wichtige Ergebnisse liegen vor. Statusschritte AP M FGR = 0 % | 50 % | 100 % Anwenden auf Arbeitspaketebene. Leicht zu handhaben. Zeitproportionalität AP Z FGR = Istzeit / Planzeit AP-Ebene. Liegt oft daneben, bei Mehraufwand oder Problemen. Restzeitschätzung AP Z FGR = (Planzeit  Restzeit) / Planzeit Aktualisierung in kurzen Abständen (z. B. 1 Woche) Mengenschätzung AP M FGR = x % Subjektiv, kaum überprüfbar. Nur verwenden, wenn sonst nichts geht. Mengenmessung AP M FGR = Istmenge / Planmenge Sehr gut, wenn geeignetes Mengenmaß verfügbar. A: Anwendungsebene (PP: Projektphase, AP: Arbeitspaket) B: Basisgröße (M: Menge, Z: Zeit)

der Projektleitung. Zu Projektbeginn sollte deshalb erstens sichergestellt werden, dass die technischen und organisatorischen Voraussetzungen für die Erfassung der verausgabten Finanzmittel und der aufgewendeten Personalzeiten geschaffen sind und zweitens, dass die regelmäßige Kontrolle der Plan- und der Istwerte zu einem festen Bestandteil des Projektmanagements wird. Schwieriger als die Kostenerfassung ist die Kontrolle der Terminsituation und der Fortschritte bei der Realisierung der benötigten Funktionen (Tab. 11.1). Hier kann man auf den terminierten Ablaufplan zurückgreifen. Er enthält alle auszuführenden Arbeiten sowie deren geplante Anfangs- und Fertigstellungstermine. Es ist daher nahe liegend, zur Überprüfung der Funktionen die Ausführung der im Ablaufplan vorgesehen Arbeitspakete zu kontrollieren. Bei jedem Arbeitspaket löst eine Person eine überschaubare Aufgabe in einem eng begrenzten Zeitraum und liefert ein überprüfbares Ergebnis. Bei der Fortschrittskontrolle im Wochenrhythmus können kleine Arbeitspakete mit einem Umfang von wenigen Arbeitstagen als Ganzes erfasst werden. Sie werden also entweder als „noch nicht begonnen“ (Fortschritt 0 %) oder als „komplett fertig gestellt“ (Fortschritt 100 %) gemeldet. Bei mittleren Arbeitspaketen mit einem Umfang von 5 bis 10 Arbeitstagen kann als zusätzlicher Status „in Arbeit“ eingeführt werden, der für die Fortschrittserfassung pauschal durch einen Fortschrittswert von 50 % ausgedrückt wird.

11.1

Projektüberwachung

275

Die Rückmeldung begonnener und abgeschlossener Arbeitspakete ist ein einfacher Weg zur Bestimmung des aktuellen Status des Projekts. Trotz einer geringen Auflösung mit nur 2 oder 3 Statuswerten beim einzelnen Paket ergibt deren Zusammenfassung und Mittelung eine schnelle Orientierung. Für eine detaillierte und belastbare Aussage über den Projektstatus reicht die bloße Rückmeldung der Arbeitspakete aber nicht aus. Hierfür gibt es mehrere Gründe. Wird ein Arbeitspaket als „abgeschlossen“ gemeldet, so heißt dies nicht zwangsläufig, dass damit auch alle Anforderungen erfüllt sind. Wenn eine eingeplante Arbeit im vorgesehen Zeitrahmen erbracht wurde, kann es trotzdem sein, dass der Fortschritt nicht wie erhofft ist. Gründe hierfür können Qualitätsmängel in der erbrachten Arbeit sein, die erst später erkannt werden, höhere Kosten als geplant oder die Notwendigkeit zusätzlicher, im Plan nicht berücksichtigter Arbeiten. Nicht jeder Bearbeiter eines Arbeitspaketes erkennt derartige Mängel und wenn er sie entdeckt, wird er sie nicht unbedingt mit der erforderlichen Deutlichkeit zurückmelden. Zu groß ist manchmal die Hoffnung, dass die Arbeit vielleicht doch gut genug ist oder dass die Qualitätsmängel nicht auffallen werden oder dass die irgendwann entdeckten Mängel nicht mit ihm in Verbindung gebracht werden. Daher ist es zumindest bei kritischen Arbeitspaketen unbedingt notwendig, neben der Fertigmeldung durch den Bearbeiter, von einer anderen Person, die Qualität des Ergebnisses zu überprüfen. Dies ist nicht ganz leicht. Auch wenn von den geplanten 100.000 Zeilen eines Programms 50.000 erstellt wurden, heißt das noch lange nicht, dass tatsächlich die Hälfte der Arbeit geleistet ist und schon gar nicht, dass am Ende des Projekts die schon programmierten Teile richtig funktionieren und mit dem Rest fehlerfrei zusammenwirken. Das gleiche gilt für viele andere technische Bereiche in ähnlicher Weise. Wenn Teile eines Systems vorliegen, bleiben es zunächst einmal Einzelteile. Ihre Qualität und ihr Funktionieren im Gesamtzusammenhang kann oft erst am Projektende festgestellt werden. Leider stehen damit auch die vorher behandelten Fortschrittsfaktoren Projektkosten und Arbeitsaufwand auf der Kippe. Werden gegen Projektende mangelnde Funktion oder mangelnde Qualität festgestellt, ist Mehrarbeit nötig und es werden Mehrkosten verursacht. Die Fortschrittskontrolle steht und fällt daher mit einer korrekten Messung der Qualität der geleisteten Arbeit. Die beste Voraussetzung hierfür ist eine geeignete Produktstrukturierung. Ist der Produktstrukturplan fein genug modularisiert, so können zunächst Einzelteile für sich alleine getestet werden. Sie werden dann zu Teilkomponenten zusammengebaut, die ebenfalls getestet werden. Wird dann gegen Ende das Gesamtsystem aus seinen Teilkomponenten zusammengebaut, so sind natürlich noch nicht alle Unsicherheiten beseitigt. Im Systemtest können noch immer unliebsame Überraschungen auftreten, aber deren Wahrscheinlichkeit kann durch die gestufte Vorgehensweise deutlich reduziert werden. Auf diese Weise kann der modulare Aufbau des Produktstrukturplans die Voraussetzungen schaffen, dass der Fortschritt der Produktfunktionalität und -qualität in frühen Projektphasen möglich wird. Für größere Arbeitspakete bzw. wenn bei kleinen und mittleren Paketen eine genauere Betrachtung notwendig sein sollte, kann eine weiter gehende Auflösung bei den Fort-

276

11

Projektsteuerung

schrittswerten erfolgen. Oft wird hierfür die Relation der bisher geleisteten Arbeitszeit zu der gesamten geplanten Arbeit verwendet. Sind beispielsweise bei einem Arbeitspaket mit 15 Personentagen bislang 5 Tage gebucht, so kann man von einem Fertigstellungsgrad von 33 % ausgehen. Man sollte sich aber von detaillierten Prozentwerten keine falsche Genauigkeit vortäuschen lassen. Wenn bei einem Arbeitspaket 33 % der geplanten Arbeitsstunden erbracht sind, heißt dies noch lange nicht, dass auch 33 % der erwarteten Leistung vorliegen. Oft erweist sich eine Arbeit schwieriger als ursprünglich gedacht, so dass der ursprünglich geplante Aufwand nicht reicht, um die geforderte Leistung zu erbringen. Ein bekanntes Beispiel hierfür ist das aus der Software-Entwicklung bekannte 95-%-Syndrom: bei der Programmierarbeit werden immer wieder plangemäße Fortschritte gemeldet; erst kurz vor Erreichen des Abgabetermins („fast fertig“) treten zunehmend Probleme auf und die Fertigstellung wird immer wieder verschoben. Die Rückmeldung plangemäßer Fortschritte bei den geleisteten Arbeitsstunden darf daher nicht mit tatsächlichen Leitungsfortschritten verwechselt werden. Eine Verbesserung der Fortschrittserfassung wird erreicht, wenn mit jeder Rückmeldung neben den bisher erbrachten Arbeitsstunden auch voraussichtliche Restaufwand für ein Arbeitspaket geschätzt wird. Allerdings setzt dies eine gewisse Objektivität der Beteiligten voraus. Ohne gezielte Nachfrage wird der Bedarf an Mehrarbeit so lange verschwiegen, bis er offensichtlich wird. Daher sollte im Rahmen der Projektorganisation festgelegt werden, dass die Projektmitarbeiter regelmäßig, z. B. jede Woche, und selbsttätig, d. h. ohne Aufforderung durch die Projektleitung den aktuellen Restaufwand für die Arbeitspakete angeben, die gerade in Arbeit sind. Falls Mehraufwand bei einem Arbeitspaket notwendig werden sollte, wird dies nicht erst kurz vor Fertigstellung bemerkt. Durch die regelmäßige Restaufwandsschätzung werden die bei den Projektbeteiligten vorhandenen Informationen über den Projektverlauf erfasst und notwendige Änderungen frühzeitig erkannt. Aus den Meldungen über begonnene und abgeschlossene Arbeitspakete, der Bewertung der Qualität der Ergebnisse, sowie den korrigierten Schätzungen über den erforderlichen Restaufwand, können die terminierten Ablaufpläne aktualisiert werden. Wenn dies nicht mit Hilfe rechnergestützter Werkzeuge automatisiert geschehen kann, ist dies ein nicht zu vernachlässigender Aufwand. Außerdem erwecken ständig korrigierte Terminpläne nicht gerade den Eindruck eines professionellen Projektmanagements. Daher genügt es in der Regel, kleinere Terminkorrekturen über einige Wochen zu sammeln und dann in einen aktualisierten Terminplan einfließen zu lassen.

11.1.2 Projektdatenauswertung Regelmäßig erstellte Berichte sind eine notwendige, aber noch nicht hinreichende Voraussetzung für die Kontrolle eines laufenden Projekts. Was nutzen die vielen verfassten, in einer Datenbank abgelegten und nachlesbaren Berichte, Memoranden und Notizen, wenn

11.1

Projektüberwachung

277

sie von niemandem ausgewertet und in entsprechende steuernde Eingriffe umgesetzt werden? Für ein Projekt gibt es eine Vielzahl von Anforderungen, die erfüllt und Randbedingungen, die eingehalten werden müssen. Außerdem gibt es während des Projekts Arbeitspakete, die bereits abgeschlossen wurden, andere Arbeitspakete, die gerade bearbeitet werden, und Arbeiten, die noch nicht begonnen wurden. Konkrete Aussagen über den Fortschritt, der zu einem bestimmten Zeitpunkt erreicht ist, setzen sich daher aus vielen Teilaussagen zusammen. Für jedes bereits abgeschlossene und für jedes gerade laufende Arbeitspaket sind Aussagen über die Kriterien Funktionalität, Kosten und Termine zu machen. In der Regel gibt es hier unterschiedliche Informationen: einige Arbeitspakete laufen besser, andere laufen schlechter als geplant; bei manchen gibt es Probleme bei der Realisierung benötigter Funktionen, andere liegen hinter dem Termin oder verursachen Mehrkosten. Um ein schlüssiges Bild über den Fortschritt des Projekts zu gewinnen ist es notwendig, die vielen unterschiedlichen Einzel-Informationen zu wenigen belastbaren Gesamt-Aussagen zu komprimieren. Hierbei kann das Zieldreieck helfen. Alle fachlichen Aussagen über bereits realisierte Funktionen und über aufgetretene technische Probleme werden zu einer Funktionalitätsaussage zusammengefasst. Die Kostenaussage bündelt alle aufgelaufenen Arbeitsstunden, Kosten für Rohstoffe, Maschinen etc. Die Terminaussage schließlich fasst die Aussagen über erreichte oder überschrittene Meilensteine und Termine zusammen. Stellt man den Fortschritt für jedes Zielkriterium auf einer eigenen Achse dar, so wird der Zustand zu jedem Zeitpunkt durch drei Punkte beschrieben. Die Verbindung der Punkte ergibt ein Dreieck, dessen Form den jeweiligen Projektzustand symbolisch beschreibt (Abb. 11.3). Jedes der drei Kriterien kann für sich alleine über Plan, unter Plan oder im Plan liegen. Im Normalfall sollten die Istwerte der drei Kriterien mit den Planwerten übereinstimmen: Die bis zu einem bestimmten Zeitpunkt geforderten Funktionen wurden zum vorgesehenen Termin fertig gestellt und verursachten dabei nicht mehr als die genehmigten Kosten. In der graphischen Darstellung ergibt sich in diesem Fall ein gleichseitiges Dreieck. Abweichungen von diesem Normalfall kann es bei jedem der drei Kriterien geben, so dass es zu unterschiedlichen Problemmustern im Projekt kommt. So kann es z. B. Projekte geben, bei denen die geforderte Funktionalität mit dem vorgesehenen Kostenrahmen, aber deutlicher Terminüberschreitung realisiert wurden (Abb. 11.4a). In anderen Projekten

Abb. 11.3 Zieldreieck zur Messung des Projektfortschritts

Funktionalität

Kosten

Termine

278

11

a

K

Projektsteuerung

b

F

F

T

K

T

Abb. 11.4 Soll-Istwert-Abweichungen bei Projekten Tab. 11.2 Reaktionsmöglichkeiten auf Planabweichungen Funktions-Priorität Kosten-Priorität

Realität ändern Kapazität erhöhen Produktivität erhöhen

Termin-Priorität

Kapazität (Personaleinsatz) erhöhen

Plan ändern Termine verschieben Funktionen vereinfachen Termine verschieben Funktionen vereinfachen

könnten die Termine gehalten worden sein, aber zu Lasten erhöhter Kosten und verringerter Funktionalität (Abb. 11.4b). Für jede Art der Planabweichung gibt es unterschiedliche Reaktionsmöglichkeiten (Tab. 11.2). Die Auswahl der passenden Reaktion hängt von der Prioritätensetzung ab. Hat der Fertigstellungstermin z. B. höchste Priorität, kann auf die Planabweichung entweder durch erhöhten Personaleinsatz und dadurch steigenden Kosten reagiert werden oder durch Verringerung der erbrachten Funktionen. Hat dagegen die Funktionalität die höchste Priorität, kann die Planabweichung ebenfalls durch mehr Personal oder durch Terminverschiebung bekämpft werden. Die folgende Liste aus [Schelle 2007] enthält einige konkrete Vorschläge für verschiedene mögliche Maßnahmen.  Kapazität erhöhen, – Überstunden anordnen, – Einsatz zusätzlicher Mitarbeiter, – Zukauf von Leistungen,  Produktivität erhöhen, – Zusätzliche Schulung von Mitarbeitern, – Austausch von Mitarbeiter gegen besser qualifizierte, – Verbesserung von Information und Kommunikation, – Verbesserung der Motivation, – Befreiung von unproduktiven Arbeiten,  Funktionen vereinfachen, – Nicht zwingend benötigte Funktionen streichen, – Einfachere technische Alternativen suchen,

11.1

Projektüberwachung

279

– Einschränkung der Qualitätsanforderungen, – Ablehnung von Änderungswünschen. Zusammengefasst ergibt sich folgende Vorgehensweise für die Fortschrittserfassung: Alle Kosten im Projekt werden mit Hilfe rechnergestützter Werkzeuge als Betriebsdaten automatisch erfasst und zur Verfügung gestellt. Die Funktionen werden durch regelmäßige formelle Statusberichte der Bearbeiter rückgemeldet. Außerdem werden für die in Arbeit befindlichen Arbeitspakete Schätzungen des Restaufwands erstellt. Darüber hinaus ist selbstverständlich eine Wachsamkeit für auftauchende Probleme auf informeller Ebene permanent notwendig.

11.1.3 Fortschrittsplanung Wie bereits erläutert, darf der Projekterfolg nicht erst am Ende überprüft werden, sondern er muss während der Projektlaufzeit regelmäßig kontrolliert werden. Als Vergleich wird deshalb ein Planfortschritt benötigt. Je detaillierter ein Projekt geplant ist, desto besser kann der tatsächliche Fortschritt damit verglichen werden und desto früher können Abweichungen vom Plan erkannt werden. Im Idealfall kann der geplante Projektfortschritt als stetiger Verlauf P(t) angesehen werden. Der tatsächliche erfasste Fortschritt wird dann als Ist-Verlauf I(t) erfasst und mit dem Plan-Verlauf verglichen. Ein Projekt besteht im Allgemeinen aus vielen einzelnen Arbeitspaketen, die zum Teil parallel ausgeführt werden. Bei der Messung des Fortschritts werden aus jedem gerade laufenden Paket Informationen gewonnen. Bei der Vielzahl der Einzelinformationen ist es nicht immer leicht, den Überblick zu behalten und wichtige von unwichtigen Informationen zu trennen. Deshalb sollte schon in der Fortschrittsplanung eine Informationsverdichtung vorgesehen werden. Ein probates Mittel hierfür ist es, Leistungsfortschritte auf die Zeitachse abzubilden. Sind also alle Leistungen eines Pakets erbracht, so kann der reale Fertigstellungstermin mit dem Plantermin verglichen werden. Projekte sind komplexe Prozesse, in denen viele einzelne Vorgänge zusammenwirken. Aus systemtheoretischer Sicht handelt es sich hierbei um Verzögerungssysteme. Deren Zusammenwirken führt zu einem typischen S-förmigen Verlauf des Projektfortschritts (Abb. 11.5). Am Anfang gibt es eine ganze Reihe von Vorarbeiten und Einarbeitungen. Daher ist der Projektfortschritt in dieser Phase nur gering oder manchmal gar nicht feststellbar. Nach Überwindung der anfänglichen Schwierigkeiten werden in den mittleren Projektphasen oft gute Fortschritte erzielt. Gegen Ende verlangsamt sich der Fortschritt wieder, weil z. B. in den Tests immer wieder Fehler auftreten oder weil scheinbar nebensächliche Detailaufgaben überraschend viel Zeit kosten. Obwohl der S-förmige Verlauf, der aus dem Zusammenwirken mehrerer verzögerungsbehafteter Komponenten entsteht, eine aus der Systemtheorie bekannte und kaum zu vermeidende Tatsache ist, denkt der Mensch noch immer vorwiegend in linearen Verläufen. Das Aufeinanderprallen des realen nichtlinearen Verlaufs und der gedachten linearen Fort-

280

11

Projektsteuerung

P t P Z P

t

O

P

3

P

2

P

1

PA t

A

t

1

t

2

t

3

t

Z

t

Abb. 11.5 Planung des Projektfortschritts

schritte führt zu typischen Denkfehlern in den verschiedenen Projektphasen. In einer frühen Phase (Zeitpunkt t1 ) führt die lineare Projektion des Fortschritts P1 zu einer pessimistischen Einschätzung des erreichbaren Termins tP mit deutlichem Rückstand gegenüber dem geplanten Fertigstellungszeitpunkt tZ . Oft führt dies zu hektischem Aktionismus und einer Vernachlässigung der Analyse und Planung. In der Mitte des Projekts (t2 ), wenn gute Fortschritte erzielt werden, hat die lineare Projektion überhöhten Optimismus und unhaltbare Versprechungen zur Folge. In dieser Phase („wir sind fast fertig“) wird der Restaufwand sehr oft unterschätzt und der erreichbare Endtermin tO zu optimistisch gesehen. Mit dem Abflachen der Kurve setzt dann die Ernüchterung ein und der Termin muss immer wieder nach hinten geschoben werden. Um diese typischen Denkfehler zu vermeiden, sollte der S-förmige Verlauf von Anfang an berücksichtigt werden, indem überprüfbare Leistungspakete (in Abb. 11.6: P1, P2, P3 und Pz) definiert werden. Nimmt man die Pakete als Fortschrittsniveaus an, können die zugehörigen Termine (in Abb. 11.6: t1 , t2 , t3 ) als Meilensteine festgelegt werden. Dadurch lässt sich die Fortschrittskontrolle der Leistungen auf eine einfacher zu überprüfende Terminkontrolle zurückführen. Aber auch hier muss die unrealistische lineare Denkweise des Menschen berücksichtigt werden. Diese führt bei gleich großen Leistungspaketen zu äquidistanten Zielterminen. In Wirklichkeit führen gleich große Leistungspakete durch die Nichtlinearität zu einer ungünstigen Terminballung. Dies lässt sich durch entsprechende Wahl der Paketgrößen vermeiden. Die Überprüfungstermine sind am aussagekräftigsten, wenn sie gleichmäßig über das Projekt verteilt sind. Um dies zu erreichen, müssen die frühen Leistungspakete eher klein

11.1

Projektüberwachung

281

a

b

P

P

P

P

Z

Z

P

P

3

3

P

P

2

2

P

P

1

c

1

t

1

t

2

t

3

t

Z

t

t

1

t

2

t

3

t

Z

t

P P

Z

P

3

P

2

P

1

t

1

t

2

t

3

t

Z

t

Abb. 11.6 Richtige Dimensionierung der Leistungspaketgrößen. a vermuteter linearer Verlauf, b tatsächlicher Verlauf, c richtig gewählte Paketgrößen

gewählt werden, die Pakete in der Mitte des Projekts sollten größer und zum Schluss wieder kleiner sein. Bei der Erstellung von Software-Systemen z. B. ist die Länge des Programms ein gutes Maß zur Schätzung des Arbeitsaufwands. Daher ist es nahe liegend, auch den Programmierfortschritt mit Hilfe der Zahl der der codierten Programmzeilen zu messen. Dies führt aber zu einer linearen Verzerrung: Bevor programmiert werden kann, muss die Aufgabenstellung analysiert und eine Lösung erarbeitet werden. All dies kostet Zeit, ohne dass eine einzige Programmzeile codiert wurde. Das dadurch entstehende ungute Gefühl wird dadurch bekämpft, dass möglichst schnell mit dem Programmieren begonnen wird. Statt gründlich zu analysieren, zu planen und zu entwerfen, wird gleich loscodiert. Dadurch scheint man zwar schnellere Fortschritte zu erzielen, aber frühe Fehler rächen sich; je später desto heftiger. Wenn dann ein Großteil des Programms „steht“, scheint die Fertigstellung unmittelbar bevor zu stehen. Aber gegen Projektende kostet die Fehlersuche Zeit, ohne die Programmlänge zu erhöhen. Die Optimierung eines Programms kann sogar zu kürzer werdenden Programmen führen. Deshalb entsteht in dieser Phase oft der Eindruck, dass sich die Fer-

282

11

Projektsteuerung

Abb. 11.7 Projektplan SW-Projekt

tigstellung „ewig“ hinzieht. Die Tests werden dann gerne vernachlässigt und viele Fehler mit allen unangenehmen Begleiterscheinungen tauchen erst beim Anwender auf. Während die Programmlänge also als Kriterium für den Gesamtaufwand eine nicht zu leugnende Berechtigung besitzt, taugt sie nicht für die Fortschrittsmessung. Besser ist es, Leistungspakete zu definieren, deren Fertigstellung dann überprüft wird. Beispiel 11.2 Leistungspakete für die Fortschrittsplanung

Gegeben ist der folgende Projektstrukturplan für ein Software-Projekt. Die Arbeiten der Anforderungsanalyse und des Systementwurfs erfolgen sequentiell. Die Programmerstellung und der Komponententest werden, um Projektlaufzeit einzusparen, so weit wie möglich parallel durchgeführt (Abb. 11.7). Es sollen nun geeignete Leistungspakete definiert werden, die eine möglichst aussagefähige Messung des Projektfortschritts ermöglichen. Zunächst einmal bieten sich die Phasenübergänge als Meilensteine an: 1. Abschluss der Anforderungsanalyse: Vorliegen des Pflichtenhefts (nach 15 Tage), 2. Abschluss der Grobkonzepterstellung: Vorliegen eines Grobkonzepts (nach 25 Tagen), 3. Abschluss der Feinkonzepterstellung: Vorliegen eines Feinkonzepts (nach 50 Tagen).

11.1

Projektüberwachung

283

K KZ K3 K2

K1

tA

t1

t2

t3

tZ

t

Abb. 11.8 Planung der Kostenbudgets

Wegen der parallelen Durchführung der Codierung und des Tests, liegt der nächste Meilenstein erst am Beginn des Systemtests: 4. Abschluss von Codierung und Komponententest (nach 90 Tagen), 5. Abschluss des Systemtests (nach 110 Tagen). Der Zeitraum zwischen dem 3. und dem 4. Meilenstein umfasst zwar nur 40 Tage Laufzeit, aufgrund der Parallelität aber 124 Tage Arbeitsaufwand, so dass sich hier ein beträchtliches Risiko einer Terminüberschreitung ergibt. Um dieses zu verringern, soll in dieser Phase im Wochenabstand der Programmumfang (LOC: Lines of code) gemessen und mit dem Planfortschritt verglichen werden. Während der Codierung wird mit einem durchschnittlichen Fortschritt von 2500 Zeilen pro Woche und während des Tests von 400 Zeilen pro Woche geplant. J Die im Laufe eines Projekts anfallenden Kosten haben ebenfalls einen nichtlinearen Verlauf. Allerdings gibt es am Projektanfang einen markanten Anstieg durch die initialen Kosten (Abb. 11.8). Die Kosten werden durch mehrere Faktoren verursacht, von denen oft die Personalkosten einen Großteil ausmachen aber auch die Kosten für Werkzeuge, Zulieferer, Materialien und Gebühren zu berücksichtigen sind. Aus betriebswirtschaftlicher Sicht versucht man, die Kosten möglichst spät anfallen zu lassen, um eine unnötig frühe Kapitalbindung zu vermeiden. Allerdings ist dies nur sehr begrenzt möglich. Gerade am Projektanfang fallen Initialkosten, z. B. für Werkzeuge, Schulung oder Einarbeitung an. Anschließend steigen die Kosten langsamer an, wegen des vergleichsweise geringen Personaleinsatzes in der Analyse- und Planungsphase. In der Realisierungsphase steigen die Kosten wieder schneller, da hier meist ein höherer Personaleinsatz nötig ist und verstärkt Kosten für Zulieferer und den Prototypenbau anfallen. Gegen Projektende flacht dann der Kostenanstieg wieder ab, da Test, Fehlersuche und Fehlerbeseitigung zwar Laufzeit kosten, aber nicht so viel Personalzeit verursachen.

284

11

Projektsteuerung

Durch die beschriebenen Effekte ist auch die Kostenkurve stark nichtlinear. Um die typischen linearen Fehleinschätzungen zu vermeiden, ist es sinnvoll für die verschiedenen Projektphasen unterschiedlich große Kostenbudgets (K 1 , K 2 , K 3 , K Z ) zu definieren und diese mit Fortschreiten des Projekts in etwa gleich großen Zeitabständen frei zu geben. Beispiel 11.3 Fallbeispiel „CAD“: Planung der Kostenbudgets

Das CAD-Projekt wurde in 4 Phasen eingeteilt und der jeweilige Personalaufwand geschätzt. Die Personalkosten pro Monat werden bei den Steinbachwerken folgendermaßen kalkuliert. Die Kosten pro Personentag werden mit 450 C/PT angesetzt. Kosten C 5000 1100 1100 1000 800 9000

Anteil (in %) 100 22 22 20 16 180

Kostenfaktor Direktes Entgelt (Bruttogehalt) Direkte Nebenkosten (z. B. Urlaub) Indirekte Nebenkosten (Arbeitgeberanteil zur Sozialversicherung) Nebenkosten für nicht produktive Arbeiten Zusatzkosten (Arbeitsplatz, Rechner: Miete, Abschreibung, Zinsen) Gesamtkosten pro Personenmonat (= 20 Personentage)

Neben den Personalkosten, die die Kapitalkosten für den Arbeitsplatz und dessen Ausstattung bereits beinhalten, sind noch die Anschaffungskosten für die CAD-Software zu berücksichtigen. Hier wird davon ausgegangen, dass 25.000 C für die Grund-Software anfallen und 8000 C für die zusätzlichen Lizenzen. Außerdem wird damit gerechnet, dass während des Pilotbetriebs ein Mitarbeiter des Software-Herstellers für die Schulung und für kundenspezifische Anpassungen benötigt wird. Dessen Zeitaufwand wird zusätzlich berücksichtigt und mit einem Tagessatz von 1000 C veranschlagt. Damit ergeben sich folgende Kostenbudgets. Projektphase Anforderungsspezifikation Produktauswahl Pilotbetrieb Produkteinführung Summe

Eigenes Personal PT C 60 27.000 40 18.000 80 36.000 120 54.000 300 135.000

Zukauf C

Fremdpersonal PT C

25.000 8000 33.000

20 10 30

20.000 10.000 30.000

Budget C 27.000 18.000 81.000 72.000 198.000

Die dargestellten Kostenbudgets müssen zu Beginn der jeweiligen Projektphasen durch die Geschäftsleitung freigegeben werden. J

11.1

Projektüberwachung

285

Abb. 11.9 Gantt-Diagramm eines kleinen Projekts

11.1.4 Meilenstein-Trendanalyse Der Fortschritt in einem Projekt besteht in der Regel aus vielen einzelnen Leistungen. Hierzu gehören z. B. die zu verrichtenden Arbeiten, die zu realisierenden Teile des Produkts, sowie die zu erstellenden Planungs- und Ergebnisdokumente. Zur Messung des Projektfortschritts müsste der Fertigstellungsgrad aller einzelnen Leistungen ermittelt und dann gewichtet aufsummiert werden. Diese theoretisch ideale Messung ist praktisch kaum realisierbar. Zum einen ist es sehr schwierig und aufwändig, den Fertigstellungsgrad der einzelnen Leistungen in kurzen Zeitabständen immer wieder zu ermitteln. Zudem wäre es problematisch, die verschiedenen Leistungen gegeneinander zu gewichten. Wie sollten z. B. gute Fortschritte bei der Dokumentation gegen einen Rückstand beim Softwaretest bewertet werden? Wegen dieser Probleme ist es gängige Praxis, das Verfahren durch zwei Maßnahmen zu vereinfachen. Statt einer problematischen stufenlosen Messung der Leistungsfortschritte in Form eines Fertigstellungsgrads wird nur die vollständige Erbringung einer Leistung berücksichtigt: Entweder ist die Leistung vollständig erbracht oder sie ist es nicht. Die schwierige unterschiedliche Gewichtung der Leistungen wird durch eine Zuordnung der Leistungspakete zu Projektphasen und Meilensteinen ersetzt. Ein Meilenstein gilt erst als erreicht, wenn alle zugehörigen Leistungen erbracht sind. Eine verspätete Leistungserbringung führt so zu einem verschobenen Meilenstein. Der Projektfortschritt wird dann durch die Zeitpunkte beschrieben, zu denen die Meilensteine erreicht werden. Beispiel 11.4 Meilenstein-Trendanalyse

Das Gantt-Diagramm in Abb. 11.9 zeigt ein kleines Projekt mit den 4 Vorgängen A bis D. Als Meilensteine werden der Abschluss von Vorgang A (t1 ), der Beginn von D (t2 ) und der Zieltermin (tZ ) definiert. Zu Beginn wurde die Dauer der Vorgänge geschätzt. Daraus ergeben sich die dargestellten Plantermine für die Meilensteine (Spalte t = 0 in Tab. 11.3). Nach jeweils 5 Tagen wird der Restaufwand für die Vorgänge neu abgeschätzt und daraus die korrigierten Termine für die Meilensteine bestimmt.

286

11

Projektsteuerung

Tab. 11.3 Aktualisierung der Meilensteine durch Restaufwandsschätzung t= tZ t2 (B) t2 (C) t1 tA Vorgang A B C D

0 5 10 15 20 30 32 34 36 37 15 17 19 21 22 12 13 15 17 21 5 7 8 0 Ist-Aufwand/Geschätzter Restaufwand 0/5 5/2 8/0 0/10 0/10 2/9 7/6 12/2 0/12 5/8 10/5 15/2 20/1 0/15 0/15 0/15 0/15 0/15

25 37 22 21

14/0 21/0 3/12

30 37

35 38

40 39

8/7

13/3

17/0

Neben der ständigen Verschiebung der Meilensteine zeigt sich, dass auch der IstAufwand (8 + 14 + 21 + 17 = 60 Tage) im Projekt den Plan-Aufwand (5 + 10 + 12 + 15 = 42 Tage) deutlich übersteigt. J Die regelmäßige Gegenüberstellung geplanter und tatsächlicher Meilensteintermine erlaubt einen recht guten Einblick in den Projektverlauf. Allerdings ist die tabellarische Darstellung nicht sehr übersichtlich. Eine Verbesserung bringt hier die graphische Darstellung. Trägt man die geplanten und die tatsächlich erreichten Meilensteintermine über der Laufzeit t des Projekts auf, erhält man einen Meilenstein-Trendverlauf. Zu Beginn des Projekts werden die geplanten Meilensteintermine sowie der Anfangsund der Zieltermin auf einer vertikalen Achse aufgetragen. Die horizontale Achse bildet dann die Zeitachse der tatsächlichen Projektlaufzeit. Werden in regelmäßigen Zeitabständen die Planungen der Termine überprüft und korrigiert, so erhält man ein Trenddiagramm der Meilensteine. Die diagonal verlaufende Linie stellt den jeweiligen Ist-Zeitpunkt dar. Ändert sich die Planung für einen Meilensteintermin nicht, so ist dessen Trend eine horizontale Linie, die mit dem Erreichen des Meilensteins die Ist-Zeitlinie erreicht. Im Allgemeinen kommt es aufgrund von unvorhergesehenen Ereignissen immer wieder zu Korrekturen der Planwerte. Die zugehörigen Trendlinien weichen dann bei Terminverschlechterung nach oben bzw. bei Terminverbesserung nach unten von der Horizontalen ab. Das Meilenstein-Trenddiagramm ist ein gutes Hilfsmittel, um die Projektfortschritte in komprimierter und übersichtlicher Form darzustellen. Auch wenn die Diagramme aufgrund der starken Informationskomprimierung keine Detailrückschlüsse über die Ursachen der Verläufe oder auf zu ergreifende Maßnahmen ermöglichen, so erlauben sie eine gute Übersicht über die Gesamtsituation. Bei wiederholter Anwendung der Trendanalyse beobachtet man charakteristische Verlaufsmuster, die wichtige Schlussfolgerungen ermöglichen.

11.1 a

Projektüberwachung

287 b

Abb. 11.10 a, b Charakteristische Meilenstein-Trend-Muster

Schwanken die Trendlinien der Meilensteine im Laufe eines Projekts geringfügig nach oben oder unten, so ist das normal. Ein solcher Verlauf zeigt, dass zu Beginn realistisch geschätzt wurde und die Termine immer wieder kritisch überprüft werden (Abb. 11.10a). Einen interessanten Verlauf zeigt das Trenddiagramm von Abb. 11.10b. Hier wurde kurz nach dem Start eine gleichmäßige Verschiebung der Meilensteintermine notwendig. Ein möglicher Grund hierfür wäre, dass sich eine Arbeit der ersten Projektphase, z. B. der Aufgabenanalyse schwieriger herausstellte als gedacht. Die eingetretene Verzögerung wird aber im weiteren Verlauf des Projekts wieder aufgeholt. Da beim ersten und beim zweiten Meilenstein tatsächlich verlorene Zeit wieder wettgemacht wurde, ist die Prognose glaubhaft, noch vor Projektende die Meilensteine wieder auf dem geplanten Niveau zu haben. Steigen die Trendlinien gleichmäßig an, so deutet dies auf eine zu optimistische Schätzung zu Projektbeginn hin (Abb. 11.11a). Hier muss befürchtet werden, dass sich die Verschiebung der Meilensteine im weiteren Verlauf des Projekts fortsetzt, so dass mit erheblichem Verzug gerechnet werden muss. Hier könnte eine komplett neue, realistische Schätzung angebracht sein. Das Gegenstück bilden gleichmäßig fallende Trendlinien (Abb. 11.11b). Sie sind ein Zeichen für zu vorsichtige Schätzungen zu Projektbeginn. Für das laufende Projekt muss dies nicht unbedingt korrigiert werden, aber beim nächsten Projekt sollte der latente Pessimismus erkannt und vermieden werden. Akute Problemfälle zeigen die nächsten Verläufe. Starke Schwankungen der Trendlinie in beide Richtungen lassen auf große Unsicherheit bei der Schätzung oder bei der Durchführung des Projekts schließen (Abb. 11.12a). Hier sollte über die Gründe für die Unsicherheit mit den Beteiligten gesprochen werden, um sie entweder zu beseitigen oder um zu entscheiden, ob mit der Unsicherheit im Projekt gelebt werden kann.

288

11

Projektsteuerung

Abb. 11.11 Meilenstein-Trend-Muster bei (a) zu optimistischer und (b) zu vorsichtiger Schätzung

Glatte Trendlinien ohne Schwankungen sind oft kein Anzeichen einer guten Schätzung zu Beginn, sondern fehlender Überprüfung während der Laufzeit. Treten dann auch noch plötzlich Sprünge oder Knicke in den Trendlinien auf, nicht selten kurz vor dem Erreichen der Ist-Zeitlinie, so muss dringend auf eine regelmäßig aktualisierte Schätzung hingewirkt werden (Abb. 11.12b). Einzelne oder mehrere extrem ansteigende Trendlinien sind Alarmsignale. Hier muss überprüft werden, ob sich im Projekt ein massives Problem eingenistet hat, das den Erfolg möglicherweise komplett in Frage stellt. Es ist unbedingt nötig, das Problem zu identifizieren, um dann zu entscheiden ob es beseitigt werden kann oder ob es besser ist, die Reißleine zu ziehen und das Projekt abzubrechen (Abb. 11.12c). Problematisch sind auch Trendlinien, die sich annähern. Meist ist eine der beiden Schätzungen fehlerhaft. Der Fehler muss dann gefunden und korrigiert werden. Manchmal werden auch die Versprechungen für die noch folgenden Arbeiten heraufgesetzt, um Versäumnisse bei den laufenden Arbeiten wieder herein zu holen, was aber in den seltensten Fällen gelingt. Fast immer sind waghalsige Versprechungen nur der letzte Versuch offensichtliche Fehler zu kaschieren. Einen weiteren problematischen Verlauf zeigt auch das letzte Trenddiagramm (Abb. 11.12d). Hier wurde kurz nach dem Start eine gleichmäßige Verschiebung der Meilensteintermine notwendig. Dabei wurde davon ausgegangen, dass sich die folgenden Arbeiten dadurch nicht verlängern, sondern nur um einen konstanten Wert verschieben. Allerdings stellte sich diese Annahme später als falsch heraus, so dass es in allen Projektphasen zu Mehrarbeit kam. Dies führte dann zu einer zunehmenden Verschiebung der Termine. Bei richtiger und regelmäßiger Anwendung ist die Meilenstein-Trend-Analyse (MTA) ein sehr hilfreiches Mittel, um die Informationen über den Projektverlauf komprimiert und anschaulich darzustellen. Das Meilenstein-Diagramm wird erstmalig nach Abschluss

11.1

Projektüberwachung

289

Abb. 11.12 a–d Problematische Meilenstein-Trend-Muster

der Projektplanung mit den darin ermittelten Meilensteinen erstellt. Während der Projektdurchführung wird es dann regelmäßig fortgeschrieben. Am besten erfolgt dies im Rahmen einer Besprechung, in der die Meilenstein-Verantwortlichen ihre aktualisierten Planwerte erläutern. Nach einer Diskussion, werden die Planwerte dann ins Diagramm übernommen. Durch diese interaktive Fortschreibung ist eine unmittelbare Rückkopplung auf Planänderungen gewährleistet. Die Meilenstein-Trend-Analyse kann so für die Terminaspekte in Projekten ein ähnlich wirksames Werkzeug sein, wie die Earned-ValueAnalyse für die Kostenaspekte.

290

11

Projektsteuerung

11.2 Projektlenkung 11.2.1 Fortschrittssteuerung Bei der Feststellung von Abweichungen zwischen den Planwerten und den Istwerten, muss überlegt werden, wie darauf zu reagieren ist. Bei geringfügigen Abweichungen wird keine Reaktion notwendig sein. Jede Schätzung enthält Ungenauigkeiten und jeder Plan sollte daher einen zeitlichen Puffer enthalten, der geringe Abweichungen auffangen kann. Außerdem werden bei grundsätzlich zutreffender Schätzung sowohl positive als auch negative Abweichungen auftreten und diese sich gegenseitig kompensieren. Unproblematisch ist auch der leider seltenere Fall, dass die Istwerte besser sind als der Plan. Ist der Zeitvorteil nicht allzu groß, kann man ihn als zusätzlichen Puffer für spätere Probleme nutzen. Ist der Zeitvorteil größer, sollte er für eine Revidierung des Plans genutzt werden. Der Sinn der Revidierung liegt darin, dass Plan und Wirklichkeit nicht allzu weit auseinander liegen, auch wenn die Differenz ausnahmsweise einmal zugunsten der Wirklichkeit ausfällt. Die Neufassung des Plans verhindert das Gefühl, dass man ja „über Plan“ liegt, „jede Menge Luft hat“ und sich den einen oder anderen Fehlschlag erlauben kann. Schon oft haben sich derartige vermeintliche oder tatsächliche Vorteile durch Nachlässigkeit ins Gegenteil verkehrt. Zur Sicherheit kann der revidierte Plan zunächst nur innerhalb des Projektteams kommuniziert werden und erst später, wenn sich der Vorteil als dauerhaft erweist, auch nach außen. Häufiger wird bei der Messung des Fortschritts ein Rückstand gegenüber dem Plan festgestellt (siehe Verlauf I in Abb. 11.13). In diesem Fall muss die Frage gestellt werden, ob der Plan falsch ist oder die Realität. Wird zum Zeitpunkt t1 der Überprüfung festgestellt, dass der bis dahin geltende Plan aufgrund der realen Bedingungen nicht eingehalten werden konnte, so ist zu befürchten, dass dies auch für den Rest des Plans und die noch kommenden Arbeiten gilt. Auch wenn diese Erkenntnis schmerzlich sein kann, so ist es in diesem Fall besser, frühzeitig den Plan an die Realität anzupassen. In der dargestellten Abbildung ist diese Maßnahme als gedehnter Projektablauf (Verlauf II) zu erkennen. Sind die Verspätungen dagegen auf Einzeleffekte und nicht auf systematische Planungsfehler zurück zu führen, muss auf jeden Fall versucht werden, ein weiteres Anwachsen des Planungsrückstands zu verhindern. Die Korrektur des Ablaufs führt zu einer Verschiebung der Plankurve (Verlauf III). Noch besser ist es natürlich, wenn es gelingt, die verlorene Zeit wieder zu gewinnen (Verlauf IV). Geeignete Maßnahmen hierfür sind bessere Arbeitsleistung, Mehrarbeit durch Überstunden oder Mehrarbeit durch zusätzliches Personal. Dabei muss aber berücksichtigt werden, dass die beiden letztgenannten Maßnahmen zu höheren Kosten führen. Die geeignete Reaktion auf einen verzögerten Projektfortschritt hängt natürlich auch vom Ausmaß des Rückstands ab. Kleine Abweichungen, in der Größenordnung von wenigen Prozent, brauchen nicht weiter kommuniziert zu werden. Sie können durch die Projektleitung gepuffert werden und sollten durch den Planungspuffer auffangbar sein. Es macht wenig Sinn kleine Abweichungen zu kommunizieren, da dies von anderen oft

11.2

Projektlenkung

291

P 100% I

IV

III

II

P1Soll P

1Ist

t

A

t

1

t

Z

t

Abb. 11.13 Reaktion auf einen Rückstand im Projektfortschritt

als Pedanterie angesehen wird. Außerdem führt ständiges Nörgeln zu einer Abstumpfung. Auf die wirklich wichtigen Probleme wird dann nicht mehr angemessen reagiert. Mittlere Abweichungen, in der Größenordnung von etwa 10 %, sollte die Projektleitung an das Projektteam kommunizieren und in Zusammenarbeit mit diesem lösen. Es ist sinnvoll, das Projektteam als selbst organisierendes System zu sehen, das in der Lage ist, Probleme mittleren Ausmaßes intern zu lösen. Größere Abweichungen, die deutlich über 10 % hinausgehen, stellen eine ernsthafte Krise im Projekt dar. Sie können kaum durch Sicherheitspuffer und meist auch nicht innerhalb des Teams aufgefangen werden, sondern erfordern ein geeignetes Krisenmanagement [Neubauer 2002]. Charakteristische Anzeichen einer Krise sind:  immer wieder verschobene Termine bei Meilensteinen und Arbeitspaketen,  ständige Änderungen und neue Wünsche der Auftraggeber,  spürbar zunehmende Mitarbeiterfluktuation. Bei einer Krise im Projekt ist es notwendig, die Probleme nach außen zu kommunizieren. In der Regel muss gemeinsam mit dem Auftraggeber eine Lösung gesucht werden. Mögliche Maßnahmen zur Behebung einer Krise sind die Verschiebung des geplanten Liefertermins, das Aufholen des Rückstands auf Kosten eines höheren Aufwands oder die Reduzierung des Lieferumfangs. Eine derartige Intervention sollte in einem Projekt am besten gar nicht, wenn aber doch, dann höchstens einmal notwendig sein. Aus diesem Grund sollte vor diesem Schritt eine sorgfältige Analyse der Ursachen, der Auswirkungen und der möglichen Maßnahmen erfolgen. Hier ist es auch besser, die ganze Wahrheit auf den Tisch zu legen, als scheibchenweise mit der Wahrheit heraus zu rücken.

292

11.2.2

11

Projektsteuerung

Änderungsmanagement

Egal wie sorgfältig ein Projekt geplant wurde, Planabweichungen während der Ausführung sind nicht zu vermeiden. Die Ursachen hierfür sind vielfältig. Zum einen treten immer wieder Fehler auf, die zu Abweichungen von den Planungen führen: eine Arbeit dauert länger als gedacht, eine Funktion lässt sich in der vorgesehenen Form nicht realisieren, eine Lieferung verzögert sich, ein Teil ist defekt. Zum anderen führen neue Erkenntnisse während der Ausführung zu geänderten Vorgaben und Anforderungen. Auf derartige Ereignisse kann, wie gerade erläutert, durch steuernde Maßnahmen reagiert werden. Kleinere, lokal begrenzte Abweichungen können so behoben werden. Gravierendere Probleme erfordern aber die Anpassung der Planung an die Realität. In einem Projekt sind aber die Arbeiten untereinander sehr stark vernetzt. Weitere Einschränkungen ergeben sich durch die zugeordneten Personen, Ressourcen und Termine. Jede Änderung der Planung kann sich daher weitreichend auswirken. Bevor eine zur Behebung eines Problems notwendige Maßnahme umgesetzt wird, müssen deren Auswirkungen an anderer Stelle untersucht und berücksichtigt werden. Änderungen können daher nicht ad hoc umgesetzt werden, sondern sie müssen einen festgelegten Prozesses durchlaufen (Abb. 11.14). Dieser Änderungsprozess beginnt mit dem Erkennen eines Problems, das nicht durch eine lokal begrenzte steuernde Maßnahme behoben werden kann. Sobald eine Änderung der Planung notwendig erscheint, muss ein Änderungsantrag gestellt werden. Dies kann in allen Prozessgruppen der Fall sein: bei der Überwachung der Termine, des Inhalts, der Risiken oder der Qualität. In einem Änderungsantrag, wie das Beispiel in Abb. 11.15 zeigt, muss ein Antragsteller zunächst die Ursache für den Antrag erläutern. Dies kann z. B. ein Problem, ein Fehler oder eine neue Erkenntnis sein. Dann muss die Maßnahme beschrieben werden, die zur Umsetzung der Änderung notwendig ist. Auch die Auswirkung im Hinblick auf die Projektziele sollte kurz erläutert werden. Selbstverständlich ist es sinnvoll für Änderungsanträge ein einheitliches Formular zu schaffen. Neben den Feldern für die bereits

Abb. 11.14 Prozessschritte des Änderungsmanagements

(geänderte) Projektpläne

Änderungsmanagement 1. Änderungsbedarf erfassen 2. Änderungsantrag bearb. 3. Maßnahmen planen 4. Maßnahmen überwachen 5. Claim Management

Änderungsanträge

genehmigte Änderungen Änderungs-Register

11.2

Projektlenkung

293

Abb. 11.15 Beispiel eines genehmigten Änderungsantrags

angesprochenen Inhalte sollte auf dem Formular auch die Genehmigung oder Ablehnung mit einer entsprechenden Begründung vermerkt werden. Die anfallenden Änderungsanträge müssen durch ein eigenes Gremium analysiert, bewertet, verhandelt und entschieden werden. Die entsprechenden Rollen wurden im Rahmen der Projektorganisation Personen zugeordnet. In kleineren Projekten kann die Projektleitung diese Aufgabe übernehmen. Im allgemeinen ist die Etablierung eines Change Board sinnvoll, das regelmäßig oder bei Bedarf zusammenkommt. Zu berücksichtigende Aspekte sind die Schwere des Problems, der Aufwand für die Änderung und die Auswirkung auf das Projekt. Unter Abwägung dieser Aspekte wird der Antrag schließlich abgelehnt oder genehmigt. Im Falle der Genehmigung des Antrags müssen die notwendigen Maßnahmen und deren Auswirkungen detailliert geplant werden: Welche Arbeiten sind notwendig? Wer führt diese aus? Wer ist betroffen? Wie groß ist der Aufwand? Sind die Maßnahmen zeitlich und personell eingrenzbar, braucht die Projektplanung möglicherweise nicht überarbeitet zu werden. Statt dessen wird die Umsetzung der Maß-

294

11

Projektsteuerung

nahme separat kontrolliert. Umfangreichere Maßnahmen machen aber eine Revision der Planungen notwendig. Die notwendigen Maßnahmen müssen nun in den Ablauf- und Terminplan aufgenommen und die Vernetzung mit anderen Arbeiten berücksichtigt werden. Relativ schnell kann eine scheinbar kleine Änderung so zu beträchtlichen Planrevisionen führen. Die Lenkung und Überwachung dieser Arbeiten wird dann mit der „normalen“ Projektüberwachung zusammengeführt. Auch wenn dieser Weg gegenüber einer Sonderbehandlung aus formaler Sicht attraktiv erscheint, muss doch der Aufwand für die Planrevision und die betroffenen Personen berücksichtigt werden. Daher ist es durchaus legitim, kleine Änderungs-„Spatzen“ nicht immer gleich mit der dicken Revisions-„Kanone“ abzuschießen. Aus Gründen der besseren Übersicht sollten alle Änderungen, auch die abgelehnten, in einem Änderungsregister tabellarisch zusammengefasst werden. Es enthält die wichtigsten Informationen zu jedem Änderungsantrag und verweist auf das zugehörige Formular. Die durch den Auftragnehmer zu erbringenden Lieferungen und Leistungen sowie die vom Auftraggeber zu leistenden Zahlungen sind im Auftrag festgelegt. Änderungen im Projekt führen in der Regel zu Mehraufwand, wodurch die Rentabilität des Projekts gefährdet wird. Der zusätzliche Aufwand, der durch zusätzliche oder geänderte Anforderungen des Auftraggebers verursacht wird, ist durch das Angebot nicht abgedeckt. In der Regel entstehen Ansprüche des Auftragnehmers an den Auftraggeber. Die Handhabung dieser Ansprüche ist der Zweck des Claim Management. Ein weiterer Fokus des Claim Management sind Ansprüche an die Lieferanten. Auch hier gibt es vertragliche Vereinbarungen. Werden diese nicht eingehalten oder geändert, können auch hier Ansprüche entstehen.

11.3 Projektabschluss 11.3.1 Wozu ein Projektabschluss? Die zeitliche Begrenzung ist eines der charakteristischen Merkmale, das ein Projekt von einem kontinuierlichen Arbeitsfluss unterscheidet. Jedes Projekt sollte ein überprüfbares Ergebnis liefern und dann abgeschlossen werden. Zu einem sauberen Ende eines erfolgreichen Projekts gehören mehrere Aktivitäten. Während die meisten Projekte zumindest einen eindeutigen Anfang, z. B. in Form eines Auftrags und eines Kick-off-Meetings haben, gibt es viele Projekte, die kein eindeutiges Ende besitzen. Es stellt sich daher die Frage, wann ein Projekt zu Ende ist. Ein weit verbreiteter Irrtum soll hier gleich geklärt werden: Projekte enden nicht mit der Abnahme durch den Auftraggeber, egal wie erfolgreich sie auch verläuft. Die Abnahme eines Ergebnisses, das alle Projektziele erfüllt, verleitet die Beteiligten zu der irrigen Annahme, dass damit auch alle Arbeiten erledigt seien. Der Auftraggeber hat das gewünschte Ergebnis in Händen. Die Projektmitarbeiter freuen sich über den Erfolg und den eigenen Anteil daran. Sie sind eigentlich nicht daran interessiert, sich jetzt auch noch mit

11.3

Projektabschluss

295 Projektpläne

Prj.-ergebnis Übergabeprotokoll Abnahmebericht

Projektabschluss 1. Übergabe & Abnahme 2. Erkenntnissicherung 3. Auflösen des Projekts

Lessons Learned Abschlussbericht

Projektdaten

Abb. 11.16 Aktivitäten des Projektabschlusses

niederen Aufräumarbeiten zu beschäftigen. Viel lieber kehren sie lorbeerbekränzt in die Linienabteilung zurück oder widmen sich dem nächsten, hoffentlich genau so erfolgreichen Projekt. Dies gilt umso mehr für den Projektleiter. Ein Projekt erfolgreich geleitet zu haben, qualifiziert für die nächste, eventuell sogar höhere Aufgabe. Die Gefahr ist also groß, dass ein Projekt gar nicht oder zumindest nicht sauber abgeschlossen wird. Noch viel größer, wenn auch menschlich nachvollziehbar ist die Wahrscheinlichkeit, dass erfolgsarme oder gescheiterte Projekte nicht ordentlich abgeschlossen werden. Aber auch hier gilt: ein Projekt endet nicht mit der Nicht-Abnahme des Ergebnisses. Zum Abschluss eines Projekts gehört eine Reihe von Arbeiten (siehe Abb. 11.16). Diese können in drei Prozesse gruppiert werden: Abnahme des Ergebnisses für eine korrekte finanzielle und juristische Handhabung, Rückschau auf das Projekt zur Sicherung der gewonnenen Erkenntnisse und die Auflösung der Organe und der Umfeldbeziehungen. Damit die Bedeutung des Projektabschlusses als unverzichtbarer Bestandteil des Projekts von Anfang an bewusst wird, sollten die einzelnen Aktivitäten bereits im Projektplan berücksichtigt und personell zugeordnet werden. Es gibt nur eine richtige Form eines Projektabschlusses, aber es gibt viele Formen problematischer Verläufe. Projekte können versickern, lautlos sterben, abgebrochen werden oder irgendwie kein Ende finden. Meistens sind es fachliche Gründe, die für derartige pathologische Verläufe angeführt werden. Oft sind diese Gründe aber nur vorgeschobene Erklärungen für typische menschliche Verhaltensweisen. Mitarbeiter des Projektteams und auch der Projektleiter selbst sind zu Beginn aus anderen Aufgabenbereichen ins Projekt gewechselt. Bei längerer Projektlaufzeit kann der Wechsel zurück zur ursprünglichen Aufgabe ein Schritt ins Ungewisse sein. Man hat sich an die Aufgabe im Projekt gewöhnt und von der alten Aufgabe entfremdet, so dass man die Rückversetzung möglichst lange hinauszögert. Nur selten wird jemand von sich aus über dieses Problem sprechen, da es als Ausdruck von Schwäche angesehen werden könnte. Stattdessen tauchen immer weitere „Restarbeiten“ auf, die noch im Rahmen des Projekts erbracht werden sollen. Ein guter Projektleiter sollte dies erkennen, um eine unnötige Verlängerung des Projekts zu vermeiden, aber auch, um mit dem Mitarbeiter zu reden und den Wechsel zu erleichtern.

296

11

Projektsteuerung

Das Gegenstück zum „Kleben am Projekt“ bildet das „Verdrücken aus dem Projekt“. Manche Mitarbeiter setzen sich schon vor dem eigentlichen Ende mit unterschiedlichsten Begründungen aus dem Projekt ab. Die Ursache hierfür kann fehlendes Vertrauen in den Projekterfolg sein. Bestehen Zweifel am erfolgreichen Abschluss, machen sich manche nach der Devise „den Letzten beißen die Hunde“ aus dem Staub, um nicht für ein mögliches Scheitern verantwortlich gemacht zu werden. Läuft ein Projektschiff auf Grund, retten sich viele Beteiligte in die Boote. Auch wenn ein solches Verhalten viel über die charakterliche Struktur der Beteiligten aussagt, ist das Verhalten trotzdem alarmierend. Sind die Zweifel berechtigt, wird es für den Projektleiter schwer, die Auflösungserscheinungen zu stoppen und das Projekt noch zu einem positiven Ende zu führen. Sind die Zweifel unberechtigt, muss dies den Beteiligten bewusst gemacht werden. Hier kann eine offene Aussprache mit dem Projektteam angebracht und hilfreich sein.

11.3.2 Abnahme des Projektergebnisses Aus formaler Sicht bildet der Projektabschluss das Pendant zum Projektauftrag. Bei externen Projekten ist der Projektauftrag ein Vertrag zwischen Auftraggeber und Auftragnehmer. Der Auftragnehmer verpflichtet sich, am Projektende bestimmte Leistungen oder Produkte zu liefern. Als Gegenleistung muss der Auftraggeber seine Zahlungen leisten. Die Erfüllung der Anforderungen muss im Rahmen einer Abnahme überprüft werden. Bei der Übergabe des Projektergebnisses übergibt der Auftragnehmer alle vereinbarten Lieferungen und Leistungen. Der Auftraggeber überprüft, ob diese vollständig sind, ob sie die vereinbarte Qualität besitzen und ob alle Ziele erreicht sind. Mit der Abnahme des Projektergebnisses erklärt ein Kunde, dass die vereinbarten Bedingungen erfüllt sind. In diesem Fall werden auch die Zahlungen fällig. Außerdem starten die Gewährleistungsfrist und die Verjährungsfrist für Mängelansprüche. Die fachliche, juristische und kaufmännische Bedeutung dieses Vorgangs macht es erforderlich, dass die Übergabe und Abnahme des Projektergebnisses schriftlich protokolliert und unterzeichnet wird. Das Übergabeprotokoll listet alle Sachen und Dokumente auf, die der Auftraggeber erhalten hat und beschreibt die Modalitäten der Übergabe. Im Abnahmebericht werden die durchgeführten Tests beschrieben, die erreichten Ziele festgehalten und die Abnahme bestätigt (Abb. 11.17). Sind wesentliche Bedingungen des Auftrags nicht erfüllt, braucht der Auftraggeber das Ergebnis nicht abzunehmen. In diesem Fall werden Nachbesserungen nötig, die der Auftragnehmer zu erbringen hat (siehe Abb. 11.18). Die Nachbesserungen können sich unter Umständen erheblich in die Länge ziehen oder sogar mehrfach durchlaufen werden. Mit der Nicht-Abnahme verzögert sich oft auch die Zahlung. Ein an sich erfolgreiches Projekt kann so, in seiner Spätphase noch zu einem wirtschaftlichen Reinfall werden. Neben der Frage der Nachbesserung kann zwischen den Vertragsparteien auch Uneinigkeit über die Frage entstehen, ob eine Bedingung wesentlich ist oder nicht. Um Kontro-

11.3

Projektabschluss

297

Auftrag

Auftraggeber

Auftragnehmer

Abnahme Projektergebnis

"Kunde"

"Lieferant"

Übergabeprotokoll Abnahmebericht

Abb. 11.17 Projektabnahme Abnahme

Zahlungen werden fällig Gewährleistungsfrist beginnt Mängelverjährungsfrist beginnt

Projektergebnis Nicht-Abnahme Nachbesserung

Abb. 11.18 Verlauf der Projektabnahme

versen oder gar die Einschaltung des Rechtsweges zu vermeiden, sollten die Bedingungen der Abnahme bereits zu Beginn des Projekts, im Auftrag als Abnahmevereinbarung festgelegt werden. Sie legt den Umfang, die Kriterien und die Bedingungen der Abnahme fest und sollte Bestandteil des Pflichtenhefts sein. Hier können z. B. auch Projekt-Teilergebnisse definiert werden, die als „in sich abgeschlossene Teile“ abgenommen werden können und für die Abschlagzahlungen fällig werden. Die finanzielle Situation im Projekt lässt sich dadurch erheblich entspannen. Interne Projekte erfordern zwar keine so formale Handhabung, aber trotzdem sind auch hier eine Abnahme und die Erstellung eines Berichts notwendig. Eine ordentliche Abnahme stellt zwischen dem Auftraggeber, in diesem Fall z. B. der Unternehmensleitung und der Projektleitung Konsens über die Beurteilung des Projekterfolgs her. Für die weitere Verwendung des Projektergebnisses, aber auch über die Bewertung der Arbeit des Projektleiters und der Projektmitarbeiter bildet die Abnahme eine nachvollziehbare Grundlage. Beispiel 11.5 Abnahmeprotokoll

Zur Vereinheitlichung des Abnahmevorgangs und zur Vermeidung von Fehlern wurde eine Vorlage für ein Abnahmeprotokoll erstellt. Es soll für alle Projekte verwendet werden und ist deshalb Bestandteil des Projektmanagement-Handbuchs. Die Abb. 11.19– 11.21 zeigen die wesentlichen Teile des Abnahmeprotokolls. Der Kopf des Protokolls umfasst die Stammdaten des Projekts und eine knappe Beschreibung der Modalitäten der Abnahme. Für die Details der Abnahme, wie z. B. Testbedingungen, Testfälle kann auf das Pflichtenheft verwiesen werden.

298

Abb. 11.19 Kopf-Daten des Abnahmeprotokolls

Abb. 11.20 Abgenommene Leistungen und festgestellte Mängel

Abb. 11.21 Abnahmeerklärung des Abnahmeprotokolls

11

Projektsteuerung

11.3

Projektabschluss

299

Danach folgt die Aufzählung der abgenommenen Leistungen. Zu jeder Leistung können Bemerkungen gemacht werden, z. B. Verweise auf die Leistungsbeschreibung im Pflichtenheft oder auch festgestellte Mängel. Für jede Leistung ist einer von drei Leistungstypen anzugeben: Typ 1: Die Leistung ist vollständig erbracht und funktionsfähig. Typ 2: Die Leistung ist in wesentlichen Teilen nutzbar, weist jedoch noch Mängel auf, die behoben werden müssen. Typ 3: Die Leistung kann nicht genutzt werden; die Mängel können mit wirtschaftlich vertretbarem Aufwand nicht behoben werden. Liegen Mängel vor, muss entschieden werden, ob trotzdem eine sofortige Abnahme erfolgen kann, oder ob diese nach Behebung der Mängel erfolgen soll. Mängel vom Typ 3 führen zu einer Nicht-Abnahme. Hier ist in der Regel eine Verhandlung notwendig, bei der geklärt wird, ob eine Teil-Abnahme möglich ist oder ob gar keine Abnahme erfolgen kann. Die juristische Bedeutung der Abnahme kommt durch die Unterzeichnung der Abnahmeerklärung durch die Beteiligten zum Ausdruck. J

11.3.3 Der richtige Zeitpunkt für den Projektabschluss Nicht immer sind die Ziele eines Projektes mit der Abnahme des Ergebnisses durch den Auftraggeber schon vollständig erfüllt. Offensichtlich ist dies, wenn bei der Abnahme Mängel festgestellt werden. Diese müssen behoben werden. Aber auch dann können noch Anforderungen offen sein. Viele Projekte werden als gescheitert betrachtet, wenn das Projektergebnis durch den Auftraggeber zwar abgenommen, durch den Anwender aber nicht angenommen wird. Gründe hierfür können fehlende Einarbeitung, das Auftreten von Mängeln während der ersten Einsatzzeit oder unzureichende Akzeptanz bei den Anwendern sein. Aus diesem Grund sollte auch nach der Abnahme des Projektergebnisses und nach einer eventuell notwendigen Mängelbeseitigung eine Unterstützung der Anwender von der Projektseite erfolgen. Sehr sinnvoll ist es, diese Unterstützung bereits im Auftrag zu vereinbaren. Neben einer Gewährleistungsvereinbarung können hier auch Service- und Wartungsleistungen oder die Einrichtung einer Hotline vereinbart werden. Oft erstrecken sich diese Unterstützungsleistungen über einen längeren Zeitraum, erfordern aber, verglichen mit der Projektdurchführung, wenig Aufwand. Daher stellt sich die Frage, ob derartige Leistungen noch zum Projekt zählen sollten. Einerseits sind die Projektziele erst dann erreicht, wenn auch die vereinbarten Unterstützungsarbeiten abgeschlossen sind. Andererseits besteht die Gefahr, dass sich der Projektabschluss lange hinzieht, obwohl kaum noch Aktivitäten stattfinden.

300

11

Projektsteuerung

Abb. 11.22 Beispiel-Ablauf am Projektende

Ein Projektabschluss kurz nach vollendeter Abnahme ist dann sinnvoll, wenn die anschließenden Arbeiten von einer Linienabteilung des Unternehmens übernommen werden können. Ist dies nicht möglich, kann das Projekt eventuell provisorisch abgeschlossen werden. Hierbei werden die wesentlichen Abschlussmaßnahmen durchgeführt: Es wird ein vorläufiger Abschlussbericht erstellt, die wesentlichen Umfeldbeziehungen des Projekts werden aufgelöst und das Projektteam wird weitgehend aufgelöst. Die restlichen Arbeiten werden dann mit deutlich reduziertem Personal, eventuell sogar in Teilzeit erledigt. Man könnte in Analogie zu den Vor-Projekten von einem Nach-Projekt sprechen. Der endgültige Abschluss erfolgt dann nach Ablauf der vereinbarten Gewährleistung und erfordert nur noch wenig Aufwand. Beispiel 11.6 Abschlussphase eines Software-Projekts

Der Screenshot in Abb. 11.22 zeigt als Ausschnitt aus dem Projektplan die Abschlussphase eines Software-Projekts. Nach der Schulung der Anwender wird das Projektergebnis abgenommen. Bereits bei der Projektplanung wurde eine Mängelbeseitigung berücksichtigt. Der Aufwand hierfür kann natürlich zu Projektbeginn nicht bekannt sein. Daher wurde ein Richtwert aus Erfahrungen mit vorangegangenen Projekten bestimmt. Nach Beseitigung der Mängel erklärt der Auftraggeber in Form einer „Provisional Acceptance“ die Erfüllung der wesentlichen Anforderungen, wodurch eine Abschlagszahlung in Höhe von 95 % der Auftragssumme fällig wird. Daran anschließend kann der Auftragnehmer intern sein Projekt abschließen: die Projektdokumentation wird vervollständigt, die Ressourcen werden zurückgegeben, das Projekt wird analysiert, das Team aufgelöst und das Projekt endet. Die Gewährleistung und der Service, die nur noch einen geringen Personalaufwand erfordern, werden von der Entwicklungsabteilung übernommen. Nach Ablauf der vereinbarten Servicezeit werden die restlichen 5 % der Auftragssumme mit der „Final

11.3

Projektabschluss

301

Acceptance“ fällig, falls bis dahin alle eventuell noch aufgetretenen Mängel beseitigt wurden. J

11.3.4 Erkenntnissicherung Ein zu Ende gehendes Projekt ist eine wahre Fundgrube für wichtige Erkenntnisse. Die Fehler, die gemacht wurden, die Lehren, die daraus gezogen wurden („Lessons learned“), aber natürlich auch die Erfahrungen mit Methoden, die sich bewährt haben („Best Practices“) sind noch so frisch, dass sie genau jetzt festgehalten werden sollten und nicht irgendwann später, wenn die Erinnerungen schon wieder verblasst sind. Zudem liegen am Projektende die Ergebnisse vor, die eine abschließende Bewertung erlauben. Für die Analyse eines zu Ende gehenden Projekts gibt es eine Reihe von Bezeichnungen, wie z. B. Projekt-Retrospektive, Project Review oder Post-Mortem-Analyse. Auch wenn es im Detail Unterschiede zwischen den mit diesen Begriffen verbundenen Methoden geben mag, im Kern beschreiben Sie die gleiche Aufgabe: die Analyse der im Projekt gemachten Erfahrungen und die Sicherung der gewonnenen Erkenntnisse, um sie in späteren Projekten nutzen zu können. Die Erkenntnissicherung ist ein unverzichtbarer Baustein eines vollständigen, sauberen Projektabschlusses: Nach dem Projekt ist vor dem Projekt und das nächste Projekt ist das schwerste. Deshalb sollten die Erfahrungen nicht nur gesammelt und besprochen werden, sondern sie sollen so bewertet und gesichert werden, dass sie in folgenden Projekten nutzbar sind. Hierzu werden z. B. Funktions-, Kosten- und Zieltermine auf ihre Einhaltung überprüft sowie die Gründe und das Ausmaß aufgetretener Abweichungen untersucht. Wichtige zu untersuchende Fragen sind:  Wo sind Abweichungen aufgetreten?  Was waren die Ursachen hierfür?  Durch welche Maßnahmen hätten die Probleme vermieden werden können? Die Erfahrungen können dann in Form von Kennzahlen in einer Projektdatenbank abgelegt werden. Gewonnene systematische Erkenntnisse können zu Änderungen oder Fortschreibung des Projektmanagement-Handbuchs genutzt werden. Eine Abnahme richtet ihr Augenmerk ausschließlich auf den Projektauftrag und das Ergebnis; sie bringt das Verhältnis zwischen Auftraggeber und Auftragnehmer zu einem formalen, rechtlich belastbaren Ende. Aber auch der Verlauf eines Projekts ist eine eingehende Analyse wert. Hier werden die ursprünglich geplanten und die tatsächlich aufgetreten Abläufe verglichen. Außerdem werden die vom Projektteam gemachten Erfahrungen gesammelt und bewertet:  Welche fachlichen Probleme sind aufgetreten?  Wo hat es Informationsdefizite oder Kommunikationsprobleme gegeben?  Welche sozialen Effekte haben sich bemerkbar gemacht?

302

11

Projektsteuerung

 Wann und warum wurden Termine überschritten?  Warum wurden Kostenbudgets nicht eingehalten? Die Abnahme des Projektergebnisses erfolgt in der Regel durch eine oder mehrere vom Auftraggeber hierfür bestimmte Personen. Diese sind nicht zwangsläufig mit den Kunden bzw. Anwendern des Produkts identisch. Daher sollte zusätzlich zur Abnahme auch eine Erhebung der Kundenzufriedenheit erfolgen. Unzufriedene Anwender können ein Projekt selbst nach dem erfolgreichen Abschluss zu einem Misserfolg werden lassen. Zufriedene Anwender dagegen sind der beste Werbeträger. Die Erhebung der Kundenzufriedenheit kann im einfachsten Fall durch persönliche Gespräche erfolgen. Etwas aufwändiger, dafür aber aussagekräftiger sind formelle, schriftliche Befragungen. In einer standardisierten Form machen sie es möglich, unterschiedliche Projekte zu vergleichen. In der gleichen Weise sollte auch die Zufriedenheit der Projektmitarbeiter abgefragt und festgehalten werden. Beispiel 11.7 Fragebogen zur Feststellung der Mitarbeiterzufriedenheit

Als Baustein eines Projekt-Benchmarking möchte ein Unternehmen bei jedem abgeschlossenen Projekt die Zufriedenheit der Mitarbeiter erfassen, um die Funktionsweise der Projektprozesse zu überprüfen und diese zu optimieren. Damit die Ergebnisse der Erhebungen in verschiedenen Projekten miteinander vergleichbar sind, wurde ein standardisierter Fragebogen entworfen, der nur einige wenige Fragen beinhaltet (Abb. 11.23). Die ersten 5 Fragen haben die Zufriedenheit der Projektmitarbeiter mit den Prozessen des Projekts zum Gegenstand. Die Antworten werden in Form einer Benotung auf einer 5-stufigen Skala abgegeben. In 3 weiteren Fragen haben die Mitarbeiter die Möglichkeit, besonders positiv bzw. besonders negative aufgefallene Gegebenheiten zu nennen und Verbesserungsvorschläge zu machen. Die Ergebnisse der standardisierten Befragung werden durch den Projektleiter in einem persönliches Gespräch mit jedem Projektmitarbeiter besprochen und dabei hinterfragt, vertieft und konkretisiert. J

11.3.5 Projektauflösung Den letzten Baustein zum Abschluss eines Projekts bildet die Projektauflösung: die nicht mehr benötigten Ressourcen werden zurückgeführt und die Projektgremien werden aufgelöst. Zunächst sollte eine Abschlussbesprechung durchgeführt werden, an der Vertreter des Auftraggebers, die Projektmitarbeiter und der Projektleiter teilnehmen. In diesem informellen Gespräch sollen die Teilnehmer, die im Laufe des Projekts im Umgang miteinander und im Umgang mit der Projektorganisation gemachten Erfahrungen austauschen: Wie haben die Prozesse des Projekts funktioniert? Wo gab es Unzufriedenheit? Wie hat die

11.3

Projektabschluss

303

Abb. 11.23 Ein Fragebogen zur Mitarbeiter-Befragung

Kommunikation funktioniert? Wie wurde mit Problemen umgegangen? Was wurde gelernt? Die am Anfang gebildeten Projektgremien können entweder im Rahmen der allgemeinen Abschlussbesprechung formal aufgelöst werden oder sie können hierzu noch einmal abschließend zusammenkommen, um dabei auch gremienspezifische Erfahrungen zu diskutieren und zu dokumentieren. Die für das Projekt reservierten Ressourcen, wie z. B. Räume, Rechner, Maschinen oder Werkzeuge werden am Ende zurückgegeben bzw. verkauft. Zum Abschluss des Claim Management werden offene Ansprüche aufgrund von Minder- oder Mehrleistungen kontrolliert, es wird geprüft, ob alle Rechnungen bezahlt wurden, alle Außenstände beglichen und alle Verträge ausgelaufen sind. Die Konten und Kostenstellen des Projekts werden geschlossen. Nach Beendigung des Projekts kehren die Mitarbeiter wieder zu ihren ursprünglichen Aufgaben, z. B. in der Linienabteilung zurück. Nicht immer gelingt dies reibungslos, so dass hier schon vor dem Projektende vorbereitende und beim Wechseln unterstützende Gespräche zwischen dem Projektleiter und den einzelnen Mitarbeitern notwendig sind. Nicht zuletzt sollte auch der soziale Aspekt der Projektarbeit mit einer Abschlussfeier der Beteiligten angemessen berücksichtigt werden.

304

11

Projektsteuerung

11.4 Weiterführende Literatur

Fiedler, R.: Controlling von Projekten. Springer-Vieweg, 8. Aufl. 2020 Zeigt an zahlreichen Beispielen die Anwendung der Methoden zur Projektsteuerung in den verschiedenen Phasen eines Projekts. Fleming, W.F.; Koppelman, J.M.: Earned Value Project Management. PMI, 4. Aufl. 2010. Stellt die Steuerung von Projekten mit Hilfe der Kennzahlen aus der Earned Value Analyse dar. Kerth, N.L.: Post Mortem. MITP-Verlag, 2003 Erläutert eingehend die retrospektive Analyse von Projekten und eröffnet damit eine oft vernachlässigte Sichtweise auf Projekte.

Der Mensch im Projekt

12

In diesem Kapitel erfahren Sie, wie Sie Ihre beruflichen und privaten Aktivitäten organisieren und wie Sie dabei Überlastungen vermeiden bzw. erkennen und beheben können. Dann lernen Sie die wichtigsten Aufgaben kennen, die zur Leitung eines Projekts und zur Führung eines Projektteams gehören. Sie erfahren, welche Probleme bei der Formierung eines Projektteams zu erwarten sind, wie man sie lösen kann und wie man ein neu gebildetes Team über verschiedene Reifungsstufen in die Leistungsphase führt.

Nach der Bearbeitung des Kapitels sind Sie in der Lage,  Ihre Aktivitäten im Projekt aber auch alle anderen beruflichen und privaten Aktivitäten wie ein „Projekt im Kleinen“ zu planen und zu steuern,  die sieben elementaren Schritte zu beschreiben, die zur effizienten Organisation Ihrer Arbeit notwendig sind,  die wichtigen Merkmale zu erläutern, die das Entstehen von Stress im Umgang mit Ihren Aufgaben signalisieren, die Ursachen hierfür zu finden und Maßnahmen zur Stress-Bewältigung zu ergreifen,  die vielfältigen Kompetenzen und Aufgaben zu benennen, die für die Leitung eines Projekts gebraucht werden,  die wichtigen Merkmale verschiedener Führungsstile zu erläutern und diese in einem Spektrum zwischen autoritären und demokratischen Stilen einzuordnen,  mit Hilfe der situativen Reifegrad-Theorie für jedes Qualifikations-Niveau von Mitarbeitern, den passenden Führungsstil auszuwählen,  die typischen Probleme, die bei der Bildung eines Teams auftreten können zu erläutern und mit diesen Problemen umzugehen,  die wichtigen Merkmale eines Persönlichkeitsprofils zu erfassen, um so die passenden Personen für die einzelnen Aufgaben im Projekt auswählen zu können,

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 305 W. Jakoby, Projektmanagement für Ingenieure, https://doi.org/10.1007/978-3-658-32791-0_12

306

12

Der Mensch im Projekt

 die verschiedenen Phasen zu erkennen, die ein neu formiertes Projektteam im Ablauf eines Projekts durchlebt.

12.1 Selbstmanagement 12.1.1 Aufgaben des Selbstmanagements Im Rahmen der Strukturplanung wird ein Projekt je nach Größe über mehrere Ebenen in Teilprojekte (TP) und diese schließlich in Arbeitspakete (AP) unterteilt. Ein Arbeitspaket besitzt eine typische Größe von 1 bis 20 Personentagen und es bildet die unterste Ebene, die vom Projektmanagement geplant und gesteuert wird. In der Ablauf- und Terminplanung werden Start- und Endtermine für die Arbeitspakete festgelegt und bei der Kapazitätsplanung werden benötigte Ressourcen und verantwortliche Person zugeordnet (Abb. 12.1). Unterhalb des Projektmanagements sind die Bearbeiter der Arbeitspakete für die Planung und Steuerung der Bearbeitung verantwortlich. Dazu wird das Arbeitspaket „aufgeschnürt“ und in seine einzelnen Arbeitsgänge oder Arbeitsschritte zerlegt. Für die Ausführung der Arbeitsschritte sind in der Regel logische und zeitliche Abhängigkeiten zu berücksichtigen. Zudem sind neben den Arbeitsschritten des Projekts auch andere berufliche und private Aufgaben zu berücksichtigen (Abb. 12.2). Die aus der AP-Planung resultierende Liste an Aufgaben und Arbeiten, die in einem bestimmten Zeitraum, z. B. einem Tag oder einer Woche erledigt werden müssen, ist meistens nicht so komplex, dass hierfür eine detaillierte Planung notwendig wäre. Sie ist aber auch nicht so trivial, dass man ohne jegliche Planung und Kontrolle auskommt. Zu oft konzentriert man sich bei diesem „Fahren auf Sicht“ auf die falschen Arbeiten, setzt falsche Prioritäten und verliert Termine aus den Augen.

Abb. 12.1 Struktur, Arbeitsfluss und Zeitablauf auf der Ebene der Arbeitspakete

Abb. 12.2 Aufteilung und Planung der Arbeitspakete

12.1 Selbstmanagement

307

Als guter Kompromiss zwischen geringem Aufwand und brauchbaren Ergebnissen eignen sich auf dieser Ebene persönliche Todo-Listen. In sie werden alle zu erledigenden Aufgaben eingetragen. Neben der Benennung der Aufgabe sollte die Liste auch Informationen zu deren Wichtigkeit, zum geschätzten Arbeitsaufwand und zu geplanten Terminen erfassen. Alle Beteiligten in einem Projekt führen eine ganze Reihe von Arbeiten aus. Hierzu gehören nicht nur die Aufgaben im Projekt, sondern auch andere berufliche RoutineAufgaben sowie private Aktivitäten. So wie die Arbeitsprozesse eines Projekts ein Management erfordern, müssen auch die persönlichen Aktivitäten jedes Einzelnen geplant und gesteuert werden. Auch wenn dies oft nur intuitiv und nicht mit formalen Methoden erfolgt, kann man hier von einem Selbstmanagement sprechen, der Planung und Steuerung persönlicher Tätigkeitsprozesse. Jeder Einzelne muss für seine Aktivitäten Ziele setzen, Prioritäten definieren, mögliche Maßnahmen suchen, Entscheidungen treffen und Arbeiten planen. Selbstmanagement ist daher zu einem Teil „Projektmanagement im Kleinen“. Selbstmanagement ist aber auch mehr. Berufs- und Privatleben stehen oft in Konflikt miteinander. Um beiden Lebensbereichen gerecht zu werden, müssen berufliche und private Aktivitäten in einer Work-Life-Balance nebeneinander und miteinander in Einklang gebracht werden. Selbstmanagement hat daher sowohl eine methodische als auch eine emotionale Seite.

12.1.2

Methoden des effizienten Arbeitens

Jede Arbeitswoche und jeder Arbeitstag erfordert eine vorausschauende Planung, damit alle Anforderungen „unter einen Hut“ gebracht werden. Die Arbeiten, die den Beteiligten im Projektplan zugeordnet werden, bilden also einen Rahmen innerhalb dessen jeder für sich eine genauere Planung vornehmen sollte. Dabei müssen auch die Aktivitäten außerhalb des Projekts, egal ob sie beruflicher oder privater Natur sind, berücksichtigt werden. Zur Feinplanung der Arbeiten bietet sich das allgemeine spoc-Schema der Problemlösung an (Tab. 12.1). Als Voraussetzung für eine Planung sind Ziele festzulegen. Für die Arbeitspakete des Projekts ergeben sich die funktionalen Ziele aus der Arbeitspaket-Beschreibung und die Terminziele aus dem Projektplan. Ist ein Arbeitspaket umfangreicher, kann es sinnvoll sein, Teilziele zu bilden. Aber auch für die anderen Arbeiten werden Ziele benötigt. Leider gibt es allzu oft Zielkonflikte: „Ich muss heute unbedingt länger arbeiten, damit die Bestellung für das Gehäuse noch rausgeht, die Personalabteilung braucht dringend den Stundenzettel von letzter Woche, um 17:00 Uhr muss ich meinen Sohn aus dem Fußballtraining abholen und eigentlich wollte ich heute Abend noch eine Runde joggen.“ Gerade in den schwierigen Phasen eines Projekts – und wann ist ein Projekt eigentlich nicht in einer schwierigen Phase? – häufen sich solche Kollisionen, sie führen zu Stress, die Fehlerquote steigt an, was zu mehr Arbeit, zu höherem Zeitdruck und noch mehr Stress

308

12

Der Mensch im Projekt

Tab. 12.1 Methodik des effizienten Arbeitens study

plan

operate

check

1. Analyse der Ausgangssituation Was ist gegeben/vorhanden/passiert? 2. Formulierung der Ziele Was will ich erreichen? Sinn-Ebene, strategische Ebene, taktische Ebene; Motive, Werte, Wünsche. 3. Erfassung der notwendigen Aktivitäten Was ist zu tun? (=> Todo-Liste), Zeitbedarf schätzen; 4. Entscheidung über den Ablauf Was ist wichtig? Was ist dringlich? (=> ABC-Analyse), Reihenfolge der Arbeiten; feste Termine berücksichtigen; Pufferzeiten frei halten 5. Ausführung der Aktivitäten Wo treten Probleme auf? Wie kann ich diese beheben? Sind Planänderungen nötig? 6. Bewertung die Ergebnisse Was wurde erledigt? Was ist liegen geblieben? Was sind Ursachen für Abweichungen? Was habe ich gelernt?

führt. Damit solche Situationen, die leider oft die Regel darstellen, zur Ausnahme werden, ist eine methodische, persönliche Planung notwendig. Im Gegensatz zu einem Projekt, bei dem viele Aktivitäten parallel auf verschiedene Akteure aufgeteilt werden können, ist bei der persönlichen Planung nur eine sequentielle Abarbeitung aller anstehenden Aufgaben möglich. Die Planung der Arbeiten läuft daher auf die Festlegung der Zieltermine und eine möglichst effiziente Aufteilung der davor liegenden Zeit hinaus. Egal ob mit oder ohne Planung: Allzu oft übersteigt der Bedarf die verfügbare Zeit und die avisierten Termine können nicht eingehalten werden. Daraufhin wird beim nächsten Mal versucht, noch genauer zu planen und die Arbeitsleistung zu steigern, was aber in der Regel wieder nicht gelingt. In der Praxis gibt es zu viele Zeitdiebe und Störfaktoren, die jede noch so genaue Planung obsolet machen. Wohl jeder kennt das Gefühl, dass man zu wenig Zeit hat, um alles zu tun, was getan werden muss. Ganz zu schweigen, von der fehlenden Zeit für das, was man gerne tun würde. Zeit ist eine knappe Ressource. Der Eindruck, dass dies ein vorübergehender, durch eine Sondersituation verursachter Zustand ist, täuscht in den meisten Fällen. Zeitknappheit ist oft ein dauerhafter Zustand. In Projekten ist es sogar ein charakteristisches Merkmal! Es stellt sich daher die Frage, wie die verfügbare Zeit am besten und am sinnvollsten genutzt werden kann. Die Ablauf- und Terminplanung versucht dies auf der Ebene des Projektstrukturplans zu beantworten. Auf der Ebene der Arbeitspakete, d. h. bei der Planung des täglichen Arbeitsablaufs, muss jeder diese Frage für sich beantworten. Der erste Schritt zur Einteilung der Zeit ist es, alle anstehenden Tätigkeiten aufzulisten. Eine geeignet Form hierfür ist eine persönliche To-Do-Liste. Sie enthält in loser, ungeglie-

12.1 Selbstmanagement

309

derter Form alle auszuführenden Aufgaben. Für jede Aufgabe sollte dann der Aufwand geschätzt und ein frühestmöglicher und ein spätestmöglicher Termin bestimmt werden. Die Aufgaben der To-Do-Liste sollten dann nach den beiden Kriterien der Wichtigkeit und der Dringlichkeit geordnet werden. Bei der Einschätzung der Wichtigkeit hilft es, eine ABC-Analyse durchzuführen. Dadurch werden wichtige von weniger wichtigen und diese wiederum von unwichtigen Aufgaben getrennt. Das zweite Kriterium ist die Dringlichkeit. Es gibt dringliche Tätigkeiten und andere die entweder nicht sofort gemacht werden müssen oder nicht sofort gemacht werden können, weil zuvor andere erledigt sein müssen. Sind alle Aufgaben nach den Kriterien Wichtigkeit und Dringlichkeit klassifiziert, kann man das auf den ehemaligen amerikanischen Präsidenten zurückgehende EisenhowerPrinzip anwenden. Dringliche und wichtige Tätigkeiten rät Eisenhower sofort selbst zu erledigen. Wichtige aber nicht dringliche Tätigkeiten soll man für die Erledigung terminieren. Weniger wichtige aber dringliche Tätigkeiten sollen delegiert werden. Aufgaben, die weder wichtig noch dringlich sind, sollten gestrichen werden. Wegen permanent knapper Zeit und permanent hinzukommender neuer Aufgaben, kommt man sowieso nicht zu den unwichtigen Aufgaben. Wenn man sie also gleich eliminiert, belasten sie auch nicht mehr die eigene Tätigkeitsbilanz. Nach dem Eliminieren bzw. Delegieren der weniger wichtigen Aufgaben, bleiben die wichtigen, selbst zu erledigenden Tätigkeiten übrig. Da die eigene Zeit nur einmal verplant werden kann, müssen die oft noch parallel liegenden Aufgaben der To-Do-Liste serialisiert werden, damit eine sequentielle zeitbezogene Tätigkeitsliste entsteht. Je nach Zeithorizont kann diese als Tages-, Wochen- oder Jahresplan ausgeführt sein. Bei der Erstellung dieser Zeitpläne darf keinesfalls die gesamte verfügbare Zeit verplant werden. Es soll eine Reserve offen gehalten werden wegen möglicher Unterschätzung des erforderlichen Aufwandes für die geplanten Tätigkeiten und für hinzukommende unvorhergesehene Tätigkeiten. Bei der Tagesplanung sollte außerdem die persönliche Leistungskurve berücksichtigt werden, die im Laufe eines Tages schwankt. Zwischen etwa 7:00 und 13:00 Uhr durchläuft diese Kurve ihr Tageshoch. Wichtige und kreative Arbeiten sollten daher in diese Zeit gelegt werden. Zwischen 13:00 und 18:00 Uhr durchläuft die Leistungsfähigkeit einen flacheren Bereich, in den man daher eher Routinetätigkeiten legen sollte. Auch während guter Leistungsphasen sind kurze Erholungspausen vorteilhaft. Eine Pause von etwa 10 min nach etwa einer Stunde Arbeit hat sich als wirksamer Kompromiss zwischen Leistungsoptimierung und Erholungswirkung herausgestellt. Besonders ergiebig ist eine kurze Pause, wenn sie einen körperlichen und geistigen Kontrast zur Arbeit bildet. Bei Büroarbeit ist also Bewegung und frische Luft eine gute Abwechslung, während für körperlich Arbeitende eine kurze Ruhepause Entspannung bringt. Das Zeitmanagement muss, damit es seine positiven Effekte zum Tragen bringt, konsequent und regelmäßig praktiziert werden. Hierzu gehört auch der Einsatz von technischen Hilfsmitteln. Geeignete Werkzeuge sind schriftliche Pläne oder Rechnerprogramme, die die Umsetzung unterstützen und visualisieren.

310

12

Der Mensch im Projekt

Zum guten Zeitmanagement gehört auch die Auswertung abgeschlossener Aufgaben: Ist das Arbeitsergebnis so wie geplant? Wurde es in der vorgesehenen Zeit erreicht? Was ist schief gegangen? Was kann man beim nächsten Mal besser machen? Nur wer aus Fehlern lernt, schafft es, sie in Zukunft zu vermeiden. Deshalb sollte immer geprüft werden, wo und warum man sich verschätzt hat und wie man dies in Zukunft vermeiden kann. Es gibt eine ganze Reihe von Methoden, die die Arbeitsschritte aus Tab. 12.1 unter einem meistens gut klingenden und mehr oder weniger zutreffenden Namen zusammenfassen. Beispiel 12.1 ALPEN

Diese Methode dient zur Planung der Aktivitäten eines Tages. Sie ist relativ einfach und besteht aus 5 Schritten, deren Anfangsbuchstaben den Namen der Methode ergeben. Aufgaben auflisten: eine To-Do-Liste erstellen. Länge schätzen: den Aufwand für alle Aufgaben schätzen. Pufferzeiten schaffen: nur einen Teil (z. B. 60 %) der Zeit verplanen. Entscheidung über Priorität: Wichtigkeit der Arbeiten bestimmen. Nachkontrolle: Vergleich der Plan- und Istwerte der Aufgaben. Diese Schritte sollen einmal pro Tag durchgeführt und schriftlich festgehalten werden. Bei einer gewissen Übung erfordern sie nur wenige Minuten. J Beispiel 12.2 Getting Things done (GTD)

„Getting Things done“ ist eine Verwaltungssystematik für das Zeitmanagement, die von D. Allen entwickelt und professionell vermarktet wird [Allen 2001]. Mit Hilfe eines vorgegebenen Arbeitsablaufs und verschiedener Listen wird sichergestellt, dass nichts vergessen wird und der Kopf für wichtige Dinge frei bleibt. Arbeiten, Ideen, Notizen werden zuerst in einer Eingangsliste gesammelt. Diese wird regelmäßig durchgearbeitet. Alle darin befindlichen Einträge werden entweder als „machbar“ oder als „nicht machbar“ klassifiziert. Machbare Einträge die in einem Schritt erledigt werden können und weniger als 2 min beanspruchen, werden sofort erledigt. Länger dauernde Aktivitäten werden auf Termin gelegt oder delegiert. Sind mehrere Schritte zur Erledigung nötig, werden die Schritte geplant und terminiert. Nicht machbare Einträge wandern entweder in den Müll oder sie kommen in eine Ablage-Liste, weil sie später eventuell doch machbar sein könnten. Zur Umsetzung der GTD-Methode existieren verschiedene Hilfsmittel in Papierform. Außerdem sind auch Programme verfügbar, die die Umsetzung mit Hilfe eines Rechners ermöglichen. J So wichtig für den jeweiligen Autor auch die Vorteile der eigenen und die Nachteile der fremden Arbeitsmethoden sein mögen – zur Organisation der täglichen Arbeiten ist es

12.1 Selbstmanagement

311

für den Anwender viel wichtiger, überhaupt eine Methode zu haben und diese konsequent und regelmäßig einzusetzen. Es gibt einige typische Fehler, die bei der Zeitplanung immer wieder auftreten. Hierzu gehört, fast fertige Arbeiten nicht abzuschließen. Sie bleiben offene „Baustellen“. Die Rest-Arbeiten summieren sich auf und vermitteln dadurch den Eindruck, permanent einen Berg von Arbeit vor sich her zu schieben. Eine Arbeit abzuschließen, auch wenn sie vielleicht noch nicht perfekt ist, gibt einem dagegen das gute Gefühl von Ordnung, Kontrolle und Zufriedenheit. Ein gravierendes Problem entsteht, wenn die Zeit zu 100 % verplant wird. Dies kann nicht gut gehen. Es gibt immer unvorhergesehene Ereignisse, die eine solche Planung über den Haufen werfen. Um sich ein realistisches Bild der Wirkung derartiger Zeitdiebe zu machen, kann es sinnvoll sein, über einen Zeitraum von mehreren Tagen eine Zeitbilanz zu erstellen. Alle Aktivitäten in diesem Zeitraum werden protokolliert. Neben den geplanten Arbeiten treten in einer solchen Bilanz auch Routine-Arbeiten und unvorhergesehene Arbeiten auf. Manche Aktivitäten erfordern viel mehr Zeit als gedacht. Andere dauern zwar nie lange, treten aber immer wieder auf, so dass sich ein erheblicher Aufwand aufsummiert. Oft stellt man schon nach kurzer Zeit erstaunt fest, wie viele Störfaktoren im Laufe eines Tages zusammenkommen. Hat man dies erst einmal erkannt, ist es nur noch ein kleiner Schritt, Zeitdiebe zu eliminieren. So ist es z. B. sinnvoll, seine E-Mails nicht sofort beim Eintreffen, sondern nur zu wenigen, festgelegten Tageszeiten zu sichten. Dabei sollten die E-Mails nicht nur gelesen, sondern sofort bearbeitet werden. Müll sollte gleich gelöscht, einfache Anfragen beantwortet, aufwändige Antworten auf Termin gelegt und bearbeitete E-Mails entweder gelöscht oder in einer klar gegliederten Datenstruktur abgelegt werden. Aber auch bei radikalem Aussortieren störender und unwichtiger Aktivitäten wird es nicht gelingen, Arbeiten punktgenau zu planen und durchzuziehen. Aus diesem Grund sollte jede Planung einen ausreichenden Puffer enthalten. Praktische Erfahrungen haben gezeigt, dass nur etwa 60 % der verfügbaren Zeit verplant werden sollten. Der verbleibende Puffer (ca. 40 %!) wird für unvorhergesehene Arbeiten und für die Aufarbeitung unterschätzter Arbeiten benötigt.

12.1.3 Umgang mit Stress Das Gefühl von Stress entsteht, wenn ein Mensch einer Anforderung ausgesetzt ist, die über das Normalmaß hinausgeht und er nicht auf die üblichen Handlungsmuster zurückgreifen kann. Es gibt ein ganzes Spektrum an Stress auslösenden Faktoren (Tab. 12.2). Im Allgemeinen werden vier Kategorien unterschieden:  physische Stressoren, wie z. B. Lärm oder Hitze entstehen durch die Arbeitsbedingungen,

312

12

Der Mensch im Projekt

Tab. 12.2 Stress-Ursachen, -Reaktionen und -Bewältigung Stress-Ursachen (Stressoren) Physische Stressoren: Lärm, Hitze, Platzmangel Kognitive Stressoren: fachliche Probleme, Zeitdruck Soziale Stressoren: Konkurrenzdruck, Angriffe Emotionale Stressoren: echte Gefühle unterdrücken, unechte Gefühle heucheln Stress-Reaktionen (Wirkungen) Somatische Reaktionen: Adrenalin, Puls, Blutdruck, Krankheit Psychische Reaktionen: Ärger, Frustration, Depression Stress-Bewältigung (Maßnahmen) Unterstützung durch Handlungsspielraum, Entscheidungsfreiheit Körperlicher Ausgleich (Bewegung, Aktivität, Entspannung) Sozialer Ausgleich (Familie, Freunde, Freizeit) Stress-Resistenz durch Perspektivwechsel (Herausforderung statt Belastung) Stress-Tagebuch und Aktionsplan

 kognitive Stressoren entstehen durch Arbeitsaufgaben und äußern sich z. B. durch fachliche Anforderungen oder Zeitdruck,  soziale Stressoren entstehen aus der Zusammenarbeit mit anderen Menschen,  emotionale Stressoren werden durch Gefühlsarbeit verursacht, wenn unechte Gefühle gezeigt und echte Gefühle unterdrückt werden müssen. Die Reaktion von Menschen auf die Einwirkung von Stressoren ist subjektiv, d. h. von Mensch zu Mensch unterschiedlich und situativ, d. h. vom momentanen Zustand abhängig. Es gibt also kein starres Reaktionsmuster, aber ohne Zweifel besteht ein unmittelbarer Zusammenhang zwischen Stressoren und Reaktionen. Typische Reaktionen sind somatischer Art (vermehrte Adrenalinausschüttung, erhöhter Puls, Anstieg des Blutdrucks) und psychischer Art (Ärger, Frustration). Kurzzeitiger Stress ist nicht zwangsläufig negativ, sondern er kann sich als normale Reaktion auf die Anspannung leistungsfördernd auswirken. Nur wenn Stress nicht bewältigt wird, wenn mehrere Stressoren zusammenkommen und wenn er länger andauert, wird Stress zum Problem. Er kann dann zu Ermüdung, Konzentrationsmängeln, vermehrten Fehlhandlungen, Erkrankungen, Resignation, Depression und sozialem Fehlverhalten führen. Zur Vermeidung derartiger Stressfolgen, sind vorbeugenden Maßnahmen nötig. Diese können auf die Vermeidung von Stress gerichtet sein oder auf dessen Bewältigung. Physische Stressoren, die durch die Arbeitsbedingungen verursacht werden, lassen sich extern durch entsprechende Gestaltung der Arbeitsbedingungen vermeiden. Alle anderen Stressursachen, lassen sich nicht so leicht bekämpfen und erfordern auch interne Maßnahmen der Betroffenen. Bestimmte Stressoren, wie z. B. fachlich anspruchsvolle Aufgaben, neuartige Problemsituationen, enge Zusammenarbeit mit anderen und Zeitdruck sind charakteristische

12.1 Selbstmanagement

313

Merkmale von Projekten und lassen sich nicht grundsätzlich vermeiden. Projektbeteiligte sind daher in besonderem Maße zur Stressbewältigung und Stressresistenz gefordert. Die Bewältigung kognitiver Stressoren erfordert Fachkenntnisse, die Verwendung effizienter Arbeitsmethoden und systematischer Problemlösetechniken, wie sie bereits in den vorangegangenen Kapiteln beschrieben wurden. Soziale Stressoren können am Besten mit sozialer Kompetenz und emotionale Stressoren mit emotionaler Kompetenz begegnet werden. Wer eine gewisse Vorstellung von der Wirkung von Kommunikationsabläufen und von emotionalen Prozessen hat, wird nicht jede unbedachte Bemerkung oder jede schlechte Laune von anderen in den „falschen Hals“ bekommen und wird sich selbst mit unangebrachten Kommentaren oder gar Angriffen zurückhalten. Da Projektarbeit quasi per Definition stresserzeugend ist und gravierende Lücken nur selten während des Projektverlaufs geschlossen werden können, ist bei der Auswahl des Projektpersonals neben der nahe liegenden fachlichen Qualifikation auch auf emotionale und soziale Kompetenzen zu achten. Aus Projektsicht kann die interne Stressbewältigung des Einzelnen unterstützt werden. Hilfreiche Maßnahmen sind die Schaffung größerer Handlungsfreiräume, z. B. bei der Einteilung der Arbeitszeit, das Einräumen von mehr Entscheidungsfreiheiten und die soziale Unterstützung im Kollegenkreis. Die Hauptlast der Stressbewältigung trägt aber jeder Einzelne. Eine grundsätzliche hilfreiche Maßnahme zur Stressbewältigung ist es, an die eigene Arbeit den richtigen Maßstab anzulegen und die richtige Perspektive einzunehmen. Wer seine Arbeit zu wichtig nimmt und ihr die absolut dominierende Stellung im Leben gibt, wird auf Probleme bei der Arbeit eher gestresst reagieren, als jemand, der durch sein Privatleben, durch Familie, Freunde und Freizeitaktivitäten einen geeigneten Maßstab entwickelt, um die Schwere der Probleme angemessen einordnen und stressarm darauf reagieren zu können. Auch die richtige Sicht auf ein Problem kann den Stress reduzieren. Betrachtet man ein Problem nicht als Belastung, sondern als Herausforderung, kann der mit dem Problem verbundene Stress sogar stimulierend sein. Natürlich gelingt dies nicht bei beliebig schweren Problemen. Zu einer sinnvollen Reaktion gehört daher auch, die eigenen Grenzen zu kennen und zu akzeptieren. Stressoren, die den Einzelnen überfordern, müssen dann identifiziert und im Team bewältigt werden. Die biologische Ausstattung des Menschen und das Repertoire seiner Reaktionen in Stresssituationen sind eher auf die Bedingungen des Lebens in der Steinzeit als auf die Anforderungen des Informationszeitalters ausgelegt. Wenn der Körper in einer Stresssituation wahlweise mit Angriff oder Flucht reagieren möchte, so ist der Mensch heute gerade zum Gegenteil gezwungen: Er muss beherrscht reagieren, seine Gefühle unterdrücken sowie Sprache, Mimik und Gestik kontrollieren. Eine dauerhafte Unterdrückung körperlicher Impulse führt früher oder später zu Stress. Zu einer dauerhaft wirksamen Stressbewältigung gehört daher auch ein Ausgleich der unterdrückten Impulse durch Bewegung, körperliche Anstrengung und Sport. Auch gezielte Entspannungstechniken können die Probleme mildern. Kontraproduktiv sind so genannte eskapadische Strategien, wie z. B. übermäßiges Trinken, Einsatz von Medikamenten oder Drogen. Auch wenn sie vielleicht kurzfristig zu wirken scheinen, sind sie als Maßnahmen

314

12

Der Mensch im Projekt

zur Bewältigung von Stress nicht geeignet, da sie auf Dauer die Probleme sogar verschärfen. Oft haben Projektbeteiligte ein allgemeines, unbestimmtes Gefühl von Stress, ohne die Ursachen genau lokalisieren zu können. In diesem Fall ist ein Stress-Tagebuch als konkrete Maßnahme hilfreich. In ihm wird mindestens einmal täglich aufgezeichnet, wer oder was Stress ausgelöst hat. Schon nach wenigen Tagen gewinnt man so eine Einsicht in die Art und die Häufigkeit der auftretenden Stressoren. Sind diese erst einmal benannt, können sie durch einen Aktionsplan bekämpft werden. Dabei sollte man aber realistisch bleiben. Eine sprungartige Veränderung des eigenen Verhaltens („gute Vorsätze“) lässt schnell wieder nach und führt zur Ernüchterung. Realistischer ist eine schrittweise Verbesserung im Umgang mit den Stressoren.

12.2 Projektleiter 12.2.1

Aufgaben eines Projektleiters

Alle Aufgaben, die in einem Projekt anfallen, sind zunächst die Aufgaben des Projektleiters! In einem Projekt einer nennenswerten Größe, kann ein Projektleiter selbstverständlich nicht alle Aufgaben selbst erledigen. Er muss deshalb die Mehrzahl der Aufgaben auf andere Personen übertragen. Aber auch für übertragene Aufgaben bleibt die Verantwortung letztlich beim Projektleiter, so dass er deren Erledigung kontrollieren muss, um der Gesamtverantwortung für das Projekt gerecht zu werden. Als originäre, nicht delegierbaren Aufgaben eines Projektleiters sind folgende zu nennen:    

Bildung des Projektteams, Delegierung von Aufgaben, Kontrollierung der Bearbeitung, Feedback geben.

Wegen der Notwendigkeit, Aufgaben zu delegieren, die Verantwortung aber nicht delegieren zu können, ist die Bildung des Projektteams die erste wichtige Aufgabe eines Projektleiters. Bei der Personalauswahl ist in erster Linie darauf zu achten, dass die im Projekt benötigten fachlichen und methodischen Kompetenzen durch die Mitarbeiter abgedeckt werden. Leider kann sich ein Projektleiter nicht immer die Mitglieder des Projektteams aussuchen und oft werden die am besten geeigneten Personen von ihren Linien-Vorgesetzten nicht für ein Projekt abgestellt. Allzu oft versuchen Linien-Manager gerade die Mitarbeiter in ein Projekt zu schicken, die in der Linie nicht allzu sehr vermisst werden. Oft muss ein Projektleiter in einer solchen Situation schon zum ersten Mal seine Durchsetzungsfähigkeit unter Beweis stellen.

12.2 Projektleiter

315

Dies gilt auch für andere Projekt-Randbedingungen, wie das Budget, die Zielvorgaben und die Termine. Auch hier muss der Projektleiter vorausschauend sein und schon am Anfang energisch agieren, wenn die Vorgaben nicht passen. Sobald er nämlich seine Aufgabe als Projektleiter unter den gegebenen Randbedingungen angenommen hat, trägt er die Verantwortung. Auftraggeber neigen dazu, Probleme mit unfähigen Mitarbeitern, unrealistischen Zielen, niedrigen Budgets oder knappen Terminen zu ignorieren. Ist ein Projekt gescheitert, ist dies immer der Fehler des Projektleiters. Waren die Bedingungen für den Projekterfolg ungeeignet, hätte der Projektleiter dies erkennen und etwas ändern müssen. Insofern ist es ratsam, lieber am Anfang die erste Machtprobe auszufechten, als mit schlechten Karten das Spiel zu beginnen. Die Bildung eines Projektteams besteht aber nicht nur in der Auswahl von Mitarbeitern. Ein zusammengewürfelter Haufen von Fachleuten ist noch lange kein Team. Deshalb darf bei der Auswahl nicht nur der fachliche Aspekt eine Rolle spielen, sondern auch persönliche und soziale Kompetenzen der Mitarbeiter sind zu beachten. Im Zweifelsfall können fachlich gute und teamfähige Mitarbeiter zielführender sein, als exzellente, aber menschlich schwierige Fachleute. Gerade in der Projektarbeit mit knappen Zeitbudgets und dem Zwang zur engen Zusammenarbeit können persönliche Reibereien kritisch werden. Zu Beginn eines Projekts kann der Projektleiter die Teambildung fördern, indem er gemeinsame Veranstaltungen zur Besprechung der Aufgaben, zur Diskussion möglicher Lösungen und Definition der Ziele durchführt. Im laufenden Projekt muss er den Zusammenhang im Team sicher stellen, indem er Spannungen zwischen den Mitarbeitern erfasst. Bleiben diese in einem normalen Bereich, ist kein Eingreifen nötig. Gewisse Spannungen sind förderlich und können einen gesunden Wettbewerb anfachen. Übersteigen die persönlichen Animositäten zwischen Teammitgliedern aber den normalen Bereich, muss ein Projektleiter eingreifen. Hilfreich sind zunächst Einzelgespräche mit den Betroffenen, um sich ein Bild der Situation zu machen und anschließend ein Gruppengespräch, bei dem die Probleme auf den Tisch kommen und, falls nicht zu vermeiden, auch einmal in einem „Gewitter“ bereinigt werden. Wie schon betont, gehört die Delegierung von Aufgaben zu den wichtigsten Aufgaben eines Projektleiters. Ob das Delegieren gelingt, hängt von zwei Fragen ab: Welche Aufgaben sollen delegiert werden (bzw. welche dürfen keinesfalls delegiert werden)? An wen sollen sie delegiert werden? Aufgaben, die wichtig und dringlich sind, werden vom Projektleiter persönlich und sofort erledigt. Wichtige Aufgaben, für die kein Zeitdruck besteht, verbleiben beim Projektleiter und werden auf Termin geplant. Dringliche, aber weniger wichtige Aufgaben werden delegiert; sie werden sofort vom Projektteam bearbeitet. Bei den Aufgaben, die weder wichtig noch dringlich sind, sollte ernsthaft und kritisch geprüft werden, ob sie notwendig sind oder eliminiert werden können. Die Grenze zwischen wichtigen und weniger wichtigen Aufgaben muss natürlich von der Auslastung des Projektleiters abhängen. Ist er sehr stark ausgelastet, müssen auch relativ wichtige Aufgaben auf Mitarbeiter übertragen werden.

316

12

Der Mensch im Projekt

Keinesfalls sollte ein Projektleiter aber Aufgaben nur deshalb übernehmen, weil sie besonders dringlich sind. Hier ist die Gefahr zu groß, dass Mitarbeiter Aufgaben, die sie eigentlich erledigen sollten, liegen lassen, bis der Zeitdruck so groß ist, dass der Projektleiter als Notnagel einspringt. Eine ähnliche Falle ist die Rück-Delegation von Aufgabe. Hierbei wird eine Aufgabe zunächst an einen Mitarbeiter delegiert. Dieser kommt anschließend immer wieder mit Problemen und Nachfragen zum Projektleiter, bis dieser die Aufgabe schließlich selbst übernimmt. Damit das Delegieren von Aufgaben gelingt, muss die vorhandene Kompetenz der Mitarbeiter genutzt werden. Ist das Projektteam richtig zusammen gestellt, sind auch die benötigten Kompetenzen vorhanden. Im anderen Fall, muss das Team entweder umbesetzt oder die fehlende Kompetenz muss von außen zugekauft werden. Ist die Kompetenz im Team vorhanden, kann das Delegieren höchstens noch an der fehlenden Motivation der Mitarbeiter scheitern. An vielen Stellen wird davon gesprochen, dass die Motivation der Mitarbeiter ebenfalls eine Aufgabe eines Projektleiters ist. Aus praktischer Sicht ist eine solche These fragwürdig. Erfahrungen in vielen Projekten haben gezeigt, dass eine dauerhafte Motivation nur vom Mitarbeiter selbst kommen kann. Externe Motivatoren wie „gutes Zureden“ oder finanzielle Anreize, wirken dagegen nur kurzfristig. Das Beste, was ein Projektleiter für die Motivation seines Teams tun kann, ist dessen Eigenverantwortung zu stärken und demotivierende äußere Bedingungen zu vermeiden. Werden Aufgaben an die Projektmitarbeiter delegiert, müssen sie auch die entsprechenden Entscheidungsbefugnisse erhalten. Nur wenn Verantwortung und Befugnisse zusammenpassen, werden sich Mitarbeiter mit einer Aufgabe identifizieren und sie engagiert ausführen. Zur Vermeidung von Demotivation müssen die benötigten Ressourcen, wie z. B. Räume, Werkzeuge, Rechner und Arbeitsmittel verfügbar sein. Nicht zuletzt, ist es auch eine Aufgabe des Projektleiters, die erforderlichen Arbeiten vor der Delegierung realistisch geplant zu haben. Im Laufe eines Projekts ergeben sich vielfältige Entscheidungssituationen. Dabei besitzt die Wichtigkeit der Entscheidungen eine große Bandbreite. Auch wenn die GesamtVerantwortung beim Projektleiter liegt, kommt er nicht umhin, kleinere Entscheidungen den Mitarbeitern zu überlassen und nur deren Richtigkeit im abgelieferten Ergebnis zu überprüfen. Trotzdem bleiben aber viele wichtige und sehr wichtige Entscheidungen, die nur vom Projektleiter getroffen werden können. Ob, in welchem Maß und in welcher Form er dabei die Mitglieder des Projektteams beteiligt, ist eine Frage des Führungsstils, der später behandelt wird. Zu den manchmal unangenehm empfundenen, aber gerade dadurch besonders notwendigen Aufgaben eines Projektleiters gehört das Kontrollieren der erledigten Arbeiten: Wurden die Arbeiten mit der erwarteten Qualität und in der geplanten Zeit erledigt? Auch die Kontroll-Aufgabe ist eine unmittelbare Folge des Delegierens. Durch das Delegieren wird der Projektleiter fachlich und zeitlich entlastet. Jede von einem Mitarbeiter erbrachte Leistung bildet einen Baustein des Projektergebnisses und andere Arbeiten bauen darauf auf. Damit am Ende der Projekterfolg steht, muss jedes Arbeitspaket zeitnah kontrolliert werden, um bei Abweichungen frühzeitig korrigierend reagieren zu können. In kleinen

12.2 Projektleiter

317

Tab. 12.3 Richtige und falsche Bestandteile von Kritikgesprächen Gesprächsrahmen Gesprächsatmosphäre Einleitung

Problemanalyse

Lösungssuche Lösungsvereinbarung

Abschluss

Richtig Gespräch gut vorbereiten, Zeit nehmen, 4-Augen-Prinzip Sachlich, konkret Gemeinsame Ziele ansprechen, nach dem Befinden fragen, Gesprächsanlass darstellen Problem aus eigener Sicht sachlich darstellen („Ich“, „Wir“), Gegendarstellung zulassen und aktiv anhören Gemeinsame Basis suchen, Mitarbeiter um Lösung bitten Mitarbeiter dokumentiert die Lösung, Hilfe anbieten, Kontrolle vereinbaren positive Aspekte, gemeinsame Ziele, Nutzen der Lösung betonen

Falsch Spontan, im Beisein von Dritten Emotional, wertend, abstrakt, pauschal „Mit der Tür ins Haus fallen“

Vorwürfe machen, persönliche Kritik („Sie“), Vergangenheitsbewältigung, Vermutungen/Gerüchte äußern Lösung vorgeben/verordnen Nur mündliche Vereinbarung, Ergebnis bleibt offen Problem und Kritik wiederholen

Projekten ist ein Projektleiter auch Controller; in großen Projekten sollte die KontrollAufgabe durch einen eigenen Projekt-Controller übernommen werden. Als letztes wichtiges Aufgabengebiet eines Projektleiters soll das „Feedback geben“ genannt werden. Leider wird diese Aufgabe allzu oft vernachlässigt. Bislang gibt es keine schlüssigen Erklärungen für dieses Manko, so dass man auf Vermutungen angewiesen ist. Die Bewertung der Leistung eines Mitarbeiters kann positiv oder negativ ausfallen. Beides gehört zu einem Feedback. Das Ausbleiben eines negativen Feedbacks kann man noch leicht erklären. Einem Mitarbeiter zu sagen, dass man mit seiner Leistung unzufrieden ist, ist nicht erfreulich. Daher wird ein solches Gespräch so lange wie möglich aufgeschoben. Ist das Gespräch aber nicht mehr zu umgehen, wird es meist unangenehm. Gerade bei einer negativen Leistungsbeurteilung ist die Wahl der richtigen Worte und der richtigen Form entscheidend (Tab. 12.3). Zunächst einmal sollte Kritik im richtigen Rahmen geäußert werden. Ein Projektleiter sollte sich für ein solches Gespräch genügend Zeit nehmen und mit dem Betroffenen unter vier Augen reden. Eine mitten im Stress und in Anwesenheit von Kollegen an den Kopf geworfene Kritik kann mehr Porzellan zerschlagen, als ein Elefant im Laden. Auf jedes Feedback sollte man sich vorbereiten und genügend Zeit verwenden. Im Gespräch sollten auch nicht nur negative, sondern auch positive Aspekte der Arbeit, die bei sachlichem Nachdenken sicher gefunden werden, erwähnt werden. Außerdem sollte die Kritik nicht die Form eines Vorwurfs und einer Verallgemeinerung („Du hast für dein Arbeitspaket mal wieder viel zu lange gebraucht.“) annehmen, sondern das Problem sollte aus Sicht des Projektleiters oder des Projektteams geschildert werden („Wir haben jetzt zwei Wochen

318

12

Der Mensch im Projekt

gegenüber dem Plan verloren.“). Anschließend sollten dann im Gespräch Maßnahmen zur Lösung des Problems gesucht und explizit als Ziele vereinbart werden. Am Ende eines Kritikgesprächs sollte schließlich die Betonung der gemeinsamen Interessen und Ziele stehen. Wer nun erwartet, dass das Feedback auf eine gute Leistung, das ja für alle Beteiligten wesentlich angenehmer sein sollte, unproblematisch ist, sieht sich getäuscht. Ein positives Feedback für die Mitarbeiter ist in manchen Unternehmen ebenso selten zu finden wie selbstkritische Spitzenmanager. Die Gründe hierfür könnte die Angst sein, dass durch zu viel Lob die Leistungsbereitschaft der Mitarbeiter nachlässt oder die Befürchtung, dass die Erwartungen für eine Gegenleistung, z. B. bei der nächsten Gehaltsverhandlung, zu stark wachsen. Leider geben Führungspersonen, die ein angemessenes Feedback verweigern, ein wichtiges Führungsinstrument aus der Hand. Bei negativen Leistungen kann das sachlich formulierte Feedback ein wichtiger Ansporn für die Weiterentwicklung eines Mitarbeiters sein. Ein positives Feedback ist eine gute Gelegenheit, die Motivation und das Selbstbewusstsein eines Mitarbeiters zu stärken und ihn dabei in einer verantwortungsbewussten Rolle im Projektteam zu fördern.

12.2.2

Anforderungen an Projektleiter

Schaut man sich in den Projektleiter-Stellenbeschreibungen die Anforderungsprofile an, kann man sich oft des Eindrucks nicht erwehren, dass es nichts gibt, was ein Projektleiter nicht können soll (Tab. 12.4). Natürlich ist den meisten Beteiligten bewusst, dass eine solche Aufzählung Idealforderungen formuliert, die nie alle und nie vollständig erfüllt sind. Leider führt eine endlose Aufzählung optimaler Fähigkeiten aber dazu, dass nicht ausreichend zwischen unbedingt notwendigen und wünschenswerten Eigenschaften unterschieden wird. Wenn sowieso niemand alle Anforderungen erfüllt, sind alle irgendwie gleich und es ist scheinbar egal, wer Projektleiter wird. Aber in Wirklichkeit sind nie alle Anforderungen gleich wichtig. Tatsächlich widersprechen sich sogar manche Anforderungen, so dass von vorneherein Prioritätsfestlegungen, Einschränkungen und Kompromisse notwendig sind. Alle Arbeitsgruppenleiter übernehmen Verantwortung, um ein Team von Mitarbeitern zum Erfolg zu führen. Bei einem Projektleiter muss dies zusätzlich unter Projektbedingungen erfolgen, d. h. die Aufgabe, die Lösung und auch das Team sind neuartig und einmalig. Bestimmte Erfahrungen und Routine, die einem Arbeitsgruppenleiter in der Linie zur Verfügung stehen, fehlen bei der Projektleitung. Außerdem gibt es harte Einschränkungen hinsichtlich Projektlaufzeit, Kosten und Ergebnis. Projektleiter benötigen daher in besonderem Maße einige psychische Voraussetzungen, die ihnen den notwendigen Antrieb für die Bewältigung der Aufgaben geben. Hier sind vor allem Ehrgeiz, Konzentrationsfähigkeit, Ausdauer, Flexibilität, Verantwortungsbewusst-

12.2 Projektleiter

319

Tab. 12.4 Anforderungen an Projektleiter Psychische Voraussetzungen (Umgang mit sich selbst) Ehrgeiz (innerer Antrieb) Konzentrationsfähigkeit (in eine Aufgabe vertiefen) Ausdauer (Durchhaltevermögen) Flexibilität (auf ungewohnte Situationen reagieren können) Selbstbewusstsein (Wissen, was man kann und auch wissen, was man nicht kann) Verantwortungsbewusstsein Belastbarkeit (Stressresistenz) Frustrationstoleranz Soziale Kompetenz (Umgang mit anderen) Führungsfähigkeit Durchsetzungsfähigkeit (nach innen und nach außen) Kommunikationsfähigkeit Konfliktfähigkeit (Konflikte ertragen und beseitigen können) Fachkompetenz (Umgang mit dem Fachgebiet) Fähigkeit zum vernetzten Denken (systemisch) Generalist statt Spezialist Ökonomische Denkweise Problemlösekompetenz (Umgang mit sachlichen Problemen) Ziel-, Handlungs- und Ergebnisorientierung Analytisches Denkvermögen Urteilsfähigkeit Entscheidungsfähigkeit Methodenkompetenz (Umgang mit Arbeitsprozessen) Organisation, Planung und Steuerung von Projekten Denken in Arbeitsprozessen

sein und ein gesundes Selbstvertrauen zu nennen. Außerdem werden Eigenschaften wie Belastbarkeit, Flexibilität und Frustrationstoleranz benötigt, die eine emotionale Resistenz gegen die negativen Einflüsse bilden, die von außen auf den Projektleiter einprasseln. Wohl die wichtigste Anforderung an einen Projektleiter ist die soziale Kompetenz für den Umgang mit den Mitgliedern des Teams und mit anderen Projektbeteiligten. Eine introvertierte Persönlichkeit ist daher für die Leitung eines Projekts vollkommen ungeeignet. Wenn an dieser Stelle von der Teamfähigkeit gesprochen wird, klingt dies oft missverständlich. Ein Projektleiter kann nicht der gute Kumpel, „mister nice guy“ oder „everbody’s darling“ sein. Ein Projektleiter muss sein Team führen. Er muss in der Lage sein, sich sowohl nach innen, bei den Mitgliedern seines Teams, als auch nach außen, z. B. gegenüber Auftraggeber oder Lieferanten durchzusetzen. Die unvermeidlich auftretenden Konflikte muss ein Projektleiter lösen und andererseits unlösbare Konflikte aushalten können.

320

12

Der Mensch im Projekt

Mehr oder weniger selbstverständlich ist der Bedarf an Fachkompetenz. In vielen Fällen wird deren Bedeutung aber überschätzt. Die einzelnen Teammitglieder sollen dem Projektleiter in ihrem jeweiligen Fachgebiet durchaus überlegen sein. Im Vergleich zur Führungskompetenz verliert die Fachkompetenz an Bedeutung, je umfangreicher ein Projekt ist. Ein Projektleiter sollte nicht so sehr Spezialist, sondern vielmehr Generalist sein, der vernetzt denken und Verknüpfungen zwischen unterschiedlichen Fachgebieten herstellen kann. Die ökonomische Kompetenz ist aufgrund des starken Kostendrucks in einem Projekt selbstverständlich. Ein weiterer wichtiger Baustein im Anforderungsprofil des Projektleiters ist seine Problemlösekompetenz. Wie in Kap. 2 dieses Buches ausführlich dargestellt, gehört dazu eine ausgeprägte Orientierung an den Zielen des Projekts, an konkreten Handlungen und Ergebnissen. Für theoretische Exkurse, für technische Spielereien und für Diskussionen um ihrer selbst Willen fehlt in einem Projekt die Zeit und das Geld. Weitere Voraussetzungen zum systematischen und zielgerichteten Lösen von Problemen ist ein analytisches Denkvermögen, sowie die Urteils- und Entscheidungsfähigkeit. Für den Leiter eines Projekts fast schon selbstverständlich sind Erfahrungen mit den grundlegenden Planungs- und Steuerungsmethoden für Arbeitsprozesse, die den Kern des Projektmanagements bilden. Es genügt aber nicht, diese Methoden zu kennen und die Mitarbeiter zum Einsatz der Methoden anzuleiten. Noch wichtiger ist, die Methoden in der eigenen täglichen Arbeit einzusetzen und zu nutzen.

12.2.3 Führungsstile Das möglicherweise wichtigste Kriterium zur Einteilung der Führungsstile ist das Maß an Beteiligung der Mitarbeiter an den Entscheidungen. Die verschiedenen Stile können hinsichtlich dieses Kriteriums auf einer Skala eingeordnet werden, die von einem autoritären bis zu einem demokratischen Stil reicht. Die Antwort auf die Frage der richtigen Beteiligung der Mitarbeiter an den Entscheidungsprozessen, hängt zum einen von der Entscheidungssituation und zum anderen von den Mitarbeitern ab. Generell sind die Führungsstile an den beiden Enden der Skala – sowohl der autoritäre als auch der demokratische – selten optimal. In den meisten Fällen sind die verschiedenen Formen kooperativer Führungsstile zu bevorzugen. Ein autoritärer Führungsstil vereinfacht und beschleunigt zwar die Entscheidungsfindung – richtiger wird die Entscheidung dadurch aber nicht. Die im Projektteam vorhandene Kompetenz wird nicht ausreichend genutzt. Außerdem führen autoritäre Entscheidungen fast immer zu Demotivation und mangelnder Identifikation mit dem Projekt. Bei manchen wird sogar der Ehrgeiz angestachelt, zu beweisen, dass die Entscheidung des Projektleiters falsch war. Aber auch das Gegenteil einsamer Entscheidungen des Projektleiters, nämlich permanente Beteiligung aller Mitarbeiter und das Treffen von Mehrheitsentscheidungen birgt viele Risiken. Ein demokratischer Entscheidungsprozess kann aufwändig und zeitraubend werden. Gerade in Projekten, in denen es ja immer auf Effizienz und Wirksamkeit

12.2 Projektleiter

321

ankommt, muss also auf den Nutzen eines demokratischen Entscheidungsprozesses geachtet werden. Zudem ist der Sachverstand nicht immer gleichmäßig im Team verteilt. Eine immer wieder kehrende gründliche Diskussion aller Aspekte durch alle Beteiligten wird zudem von den Teammitgliedern oft als lähmend empfunden. In der Praxis geht es also für einen Projektleiter nicht darum, sich pauschal auf diesen oder jenen Führungsstil festzulegen, sondern er braucht ein gewisses Repertoire verschiedener Führungsstile, und er muss abschätzen können, welche Art und welches Ausmaß an Kooperation in der jeweiligen Situation passt. In einer schwierigen Situation mit der Notwendigkeit einer schnellen Entscheidung muss die Mitarbeiterbeteiligung geringer ausfallen. Wenn es brennt, kann nicht diskutiert werden, welcher Feuerlöscher am preiswertesten ist. Steht dagegen ausreichend Zeit zur Verfügung und ist die Identifikation der Mitarbeiter mit der Entscheidung wichtig, sollte eher auf Kooperation bei der Entscheidungsfindung gesetzt werden. Das zweite wichtige Kriterium zur Auswahl des richtigen Führungsstils ist die Qualifikation der Mitarbeiter. Ist diese eher gering, ist ein autoritärer Führungsstil aus pragmatischen Gründen sinnvoll. Er sollte aber nicht auf Dauer angewendet, sondern als erster Schritt eines Prozesses gesehen werden, der die Weiterentwicklung der Mitarbeiter fördert und diese für eine stärkere Beteiligung an den Entscheidungsprozessen qualifiziert. Nach Hersey und Blanchard durchläuft eine Führungsbeziehung vier verschiedene Phasen mit ansteigendem Reifegrad [Staehle 1999] (Tab. 12.5). Beim niedrigsten Reifegrad „Anweisen“ (Telling) besitzt der Mitarbeiter ein niedriges Kompetenzniveau und auch die Leistungsbereitschaft ist nicht sehr ausgeprägt. Er erhält deshalb genaue Anweisungen, die nicht weiter begründet und deren Ausführungen in kurzen Zeitabständen (z. B. täglich) kontrolliert werden. Im nächsten Reifegrad „Argumentieren“ (Selling) werden die von der Projektleitung getroffenen Entscheidungen begründet. Der Mitarbeiter hat auch die Möglichkeit für Nachfragen. Die Ausführungskontrolle ist auch hier notwendig, erfolgt aber in etwas größeren Zeitabständen. Beim Reifegrad „Partizipieren“ (Participating) wird der Mitarbeiter an den Entscheidungen aktiv beteiligt. Die Probleme werden gemeinsam besprochen. Der Mitarbeiter macht Lösungsvorschläge und er wirkt an der Entscheidung kooperativ mit. Sind die Erfahrung, Kompetenz und Leistungsbereitschaft des Mitarbeiters auf hohem Niveau angelangt, kann die Projektleitung zusammenhängende Aufgaben delegieren (De-

Tab. 12.5 Situative Reifegrad-Theorie Reifegrad 1 2

Führungsstil Anweisen Argumentieren

3 4

Partizipieren Delegieren

Beschreibung Anweisungen geben, Ausführung eng kontrollieren Begründete Anweisungen, Ausführung in Abständen kontrollieren Beteiligung an Entscheidungen, Ergebnisse kontrollieren Aufgabe übertragen, Entscheidungsfreiheit, informelle Kontrolle

322

12

Der Mensch im Projekt

legating). Die Projektleitung tritt bei diesem Reifegrad in den Hintergrund und überlässt dem Mitarbeiter den Freiraum für Entscheidungen und Aufgabenausführung. Die Kontrolle erfolgt hier in größeren Zeitabständen und eher informell als formell. Die Reifegrad-Theorie berücksichtigt zwar ein sehr wichtiges, aber nur ein einziges Kriterium für die situative Auswahl des passenden Führungsstils. Neben dem persönlichen Reifegrad müssen auch immer der sachliche Hintergrund und die Dringlichkeit einer Entscheidung in die Auswahl mit einfließen. Den „richtigen“ Stil für die Leitung eines Projekts, könnte man zusammenfassend als ein von der sachlichen Entscheidungssituation und von den persönlichen Entscheidungskompetenzen situativ abhängigen kooperativen Führungsstil definieren.

12.3 Projektteams 12.3.1 Teambildung Jede Gruppe von Menschen bildet eine Ansammlung unterschiedlicher, zum Teil sogar widersprüchlicher Interessen und Ziele. Dadurch treten unvermeidlich Spannungen oder Reibungen auf. Diese können nicht vollständig unterdrückt werden – sie sollen es auch gar nicht, zu einem gewissen Grad wirken Spannungen sogar produktiv. Es muss aber darauf geachtet werden, dass soziale Reibungsverluste nicht die Projektarbeit beeinträchtigen oder das Projekt gefährden. In einem Projektteam treten die gleichen soziologischen Effekte auf, wie in jeder anderen Gruppe von Menschen, die zusammen arbeiten. Es gibt aber Besonderheiten, die ein Projektteam von einer Arbeitsgruppe aus der Linienstruktur eines Unternehmens unterscheiden. Die Zusammensetzung eines Projektteams ist normalerweise vollkommen neuartig, einmalig und zeitlich befristet. Es gibt daher keine gewachsene Team-„Kultur“. Diese Situation birgt Chancen und Risiken. Die Zeit, die den Mitgliedern eines Projektteams zur Verfügung steht, um sich zu einem Team zu formieren, ist knapp. Deshalb kann das Zusammenwachsen nicht dem Zufall bzw. der Zeit überlassen werden, sondern es muss gezielt und aktiv betrieben werden. Das Kickoff-Meeting, bei dem die Projektaufgabe präsentiert und die Ziele und Bedingungen für die Projektdurchführung erläutert werden, sollte deshalb auch dazu genutzt werden, dass sich die Mitglieder des Projektteams gegenseitig kennen lernen. Die positive Wirkung einer solchen Veranstaltung lässt sich steigern, wenn neben dem fachlichen auch der soziale Aspekt gezielt gefördert wird, z. B. in Form eines Workshops außerhalb der gewohnten Umgebung, durch ein gemeinsames Essen oder durch eine gemeinsame Freizeitaktivität. Im Idealfall werden genau die Mitarbeiter ins Projektteam berufen und von den Linienabteilungen abgestellt, die die benötigten Kompetenzen besitzen. Alle sind motiviert, identifizieren sich mit den Projektzielen und tun ihr Möglichstes, um das Ziel zu erreichen.

12.3 Projektteams

323

Wie gesagt: ein Idealfall. In der Realität muss mit mehr oder weniger großen Abweichungen und Konflikten gelebt und umgegangen werden. Innerhalb eines Unternehmens ist in erster Linie der Konflikt zwischen den verschiedenen Abteilungen der Unternehmensorganisation – der „Linie“ – und dem Projekt zu beachten. Die Linie verdient kurzfristig das Geld. Die Projektarbeit dagegen zeigt ihre Wirkung eher mittel- bis langfristig, z. B. durch ein neu entwickeltes Produkt, durch neue Methoden und Werkzeuge oder durch eine Neuorganisation betrieblicher Abläufe. Zudem müssen die Ergebnisse eines Projekts oft später in der Linie umgesetzt werden. Es kommt daher zu normalen menschlichen Regungen, wie Konkurrenzdenken, Argwohn, Neid oder gar Ablehnung. Die spezielle „Kultur“ eines Projektteams kann zu Spannungen mit dem Rest eines Unternehmens führen. Linienabteilungen besitzen meist feste Arbeitsabläufe und lassen wenig Platz für Freiheit und Kreativität. Projektarbeit fordert vom Einzelnen größere Flexibilität und höheren Einsatzwillen, gibt ihm dafür aber auch größere Freiheiten und mehr Entfaltungsmöglichkeiten. Dies wird von den Linien-Mitarbeitern oft argwöhnisch betrachtet. Werden aus einer Abteilung Personen für ein Projekt abgestellt, fehlen sie für die normalen „Routine“-Aufgaben. Besonders schmerzlich ist es, wenn gerade die besten Mitarbeiter abgestellt werden sollen. Linien-Vorgesetzte versuchen, sich diese Schmerzen zu ersparen und stellen lieber Mitarbeiter ins Projekt ab, die in der Linie keine so große Lücke reißen. Zur Beseitigung des Widerstands der Linienabteilungen gegen ein Projekt, kann ein Befehl von oben nur das letzte Mittel sein. Besser als Befehlen ist Überzeugen. Dies gelingt am glaubhaftesten, wenn der Nutzeffekt eines Projektes möglichst konkret benannt wird. Nutzt ein Projekt dem Unternehmen als Ganzes, nutzt es auch den Linien-Abteilungen. Natürlich müssen dafür kurzfristige eigene Interessen zugunsten langfristiger gemeinsamer Interessen zurückgestellt werden. Oft hilft auch ein Hinweis darauf, dass auch andere Abteilungen ihren Kompetenz- und Ressourcenbeitrag zum Projekt leisten. Aber nicht nur zwischen der Linie und dem Projekt, sondern auch innerhalb eines Projektteams kann es Spannungen geben. Nicht immer sind sie offensichtlich. Es gibt verschiedene persönliche Konstellationen, die zu Problemen führen können, wenn sie nicht erkannt und in einer frühen Phase geklärt werden. Eine typische Konflikt-Konstellation ist der Neid auf den Projektleiter. Wenn kompetente Mitarbeiter ins Team berufen wurden, gibt es darunter sicher auch den einen oder die andere, die sich für die Aufgabe der Projektleitung Hoffnung gemacht hatten. Der Leithammel wird dann schnell zum Neidhammel. Eine solche Situation erfordert einige Überwindung, die eigenen Ambitionen zurück zu stellen, alles für den Erfolg des Projekts zu tun und nicht zu beweisen, dass die Wahl des Projektleiters falsch war. Auch ein „Maulwurf“ kann dem Projekt Schaden zufügen. Derartige Personen lehnen die Projektaufgabe innerlich ab. Sie sehen sich im Dienst ihrer Linienabteilung. Sie versuchen, den Erfolg des Projekts zu verschleppen, zu blockieren oder gar zu sabotieren. Natürlich wird das nicht offen geschehen. Offener Widerstand hätte fatale Folgen. Statt-

324

12

Der Mensch im Projekt

dessen werden auf subtile Art immer wieder „Krümel im Käse“ gefunden oder „Sand ins Getriebe gestreut“, um den Projektfortschritt zu hemmen. Ein weiteres personales Problem stellen Mitarbeiter dar, die unfreiwillig ins Projekt entsandt wurden und Angst vor allen Abweichungen von der gewohnten Routine haben. Oft sind dies durchaus kompetente Mitarbeiter, die in der Linie gute Routine-Arbeit leisten und ihre Aufgaben gewissenhaft erfüllen. In der für sie neuen Umgebung eines Projekts fühlen sie sich aber unsicher und aus Angst, etwas verkehrt zu machen, machen sie lieber nichts. Ist die Angst vor dem Neuen nur schwach ausgeprägt, kann man sie durch Zureden und kleine Erfolgserlebnisse beseitigen. Gelingt dies nicht, ist es besser, einen übervorsichtigen Mitarbeiter im Projekt gegen einen aktiveren auszutauschen. Aber auch beim Gegenteil eines ängstlichen Mitarbeiters ist Vorsicht angesagt. In vielen praktischen Projekten wurde schon die Erfahrung gemacht, dass Mitarbeiter, die mit viel Elan ins Projekt gestartet sind, im Laufe der ständig auftretenden kleinen Probleme die erforderliche Ausdauer vermissen lassen. Besonderes Augenmerk erfordern euphorische Mitarbeiter. Allzu oft sackt die anfängliche Begeisterung für die neue Aufgabe, beim Auftauchen der ersten handfesten Probleme in sich zusammen. Ein Projekt ist ein Mittelstreckenlauf: Trotz hoher Durchschnittsgeschwindigkeit ist vor allem Ausdauer gefragt: Ein Sprint beim Start taugt nur für die Galerie; wer genügend Luft hat, kann ja am Ende noch sprinten.

12.3.2 Personalauswahl Der Erfolg eines Projekts hängt selbstverständlich sehr stark von den handelnden Personen ab. Daher ist auf die Auswahl der richtigen Mitglieder des Projektteams großer Wert zu legen. In erster Linie bilden die im Projekt benötigten fachlichen Kompetenzen ein wichtiges Kriterium für die Personalauswahl. Der Projektstrukturplan, die darin aufgelisteten Arbeitspakete und die zu deren Bearbeitung erforderlichen Qualifikationen bilden daher die Basis für die Suche nach den richtigen Akteuren. Aber die fachliche Qualifikation alleine reicht nicht aus. Ein Team muss mehr sein, als die Summe von Spezialisten. Dies gilt vor allem für Projektteams. Das enge Zusammenwirken unterschiedlicher Fachgebiete, das knappe Zeitbudget und der hohe Erfolgsdruck führen zu vielfältigen Aufgabenarten. Neben der Erfüllung fachlicher Aufgaben sind hier fachübergreifende, generalisierende Denkweisen, der Bedarf an Kommunikation im Projekt und nach außen, zeitliche und geistige Flexibilität sowie Stress-Resistenz zu nennen. Angesichts dieses Anforderungsspektrums ist es hilfreich, sich ein wenig mit der psychischen Ausstattung von Menschen zu beschäftigen. Zur Erfassung und Beschreibung eines Persönlichkeitsprofils gibt es eine Vielzahl von Kriterien. Einerseits ist jeder Mensch anders. Andererseits kann man bestimmte Verhaltensweisen und Persönlichkeitsmerkmale wiedererkennen. Bei der Verwendung solcher Erkenntnisse im Projektmanagement geht es nicht um eine moralische Wertung persönlicher Eigenschaften. Vielmehr soll erkannt werden, welche Stärken und Schwächen je-

12.3 Projektteams

325

mand besitzt, für welche Art von Aufgaben jemand gut geeignet ist und welche Menschen persönlich kompatibel sind. Ein frühes Beispiel einer Typisierung ist die hippokratische Temperamentenlehre, die vier Personentypen unterscheidet: sanguinisch, phlegmatisch, melancholisch, cholerisch. Sie gilt als überholt, da sie für die Erfassung der Vielfalt menschlicher Eigenschaften viel zu grob ist. Auch der Versuch, durch eine größere Anzahl von Typen, der existierenden Vielfalt gerecht zu werden, muss als gescheitert angesehen werden. Einen anderen Weg weist der Ansatz, Persönlichkeit nicht durch Typen zu kategorisieren, sondern durch eine Palette von Persönlichkeitseigenschaften zu beschreiben, die sozusagen die Dimensionen des persönlichen Profils darstellen. Einer der ersten derartigen Ansätze ist der Persönlichkeitszirkel von Eysenck, der auf den beiden Eigenschaften Interaktionsform und emotionaler Stabilität basiert. Neuere und weiter differenzierte Modelle sind der Typenindikator von Myers und Briggs, der mit vier Eigenschaften arbeitet und das Fünf-Faktoren-Modell (the big five). Diese Modelle liegen heute vielen Persönlichkeitstests zugrunde. Es soll hier nicht im Detail auf diese Modelle eingegangen werden, sondern nur so weit, wie die Kenntnis der Persönlichkeitseigenschaften die passende Zuordnung von Aufgaben zu Personen im Rahmen des Projektmanagements zu verbessern hilft (Tab. 12.6). Eine schon sehr früh erkannte und in vielen Modellen zu findende Eigenschaft ist die Interaktionsform. Sie beschreibt, wie und in welchem Maße ein Mensch Anregungen aus seiner Umgebung aufnimmt und weitergibt. Extrovertierte Menschen interagieren sehr stark mit ihrer Umgebung. Sie sind daher für Teamarbeit prädestiniert. Introvertierte Menschen sind zurückhaltend, teilweise sogar verschlossen. Sie sind aber in der Lage, konzentriert und ausdauernd an einem Problem zu arbeiten. Für die Projektarbeit von großer Bedeutung ist die emotionale Stabilität, bzw. deren Gegenteil, der Neurotizismus. Emotional stabile Menschen sind ruhig und ausgeglichen. Gefühlsschwankungen weisen bei ihnen geringere Ausschläge nach oben und unten auf.

Tab. 12.6 Persönlichkeitseigenschaften Eigenschaft Interaktionsform emotionale Stabilität Offenheit Wahrnehmung Entscheidungsfindung Entscheidungskonstanz Verträglichkeit Gewissenhaftigkeit

Eigenschaftsspektrum extrovertiert stabil konservativ intuitiv fühlend/emotional flexibel/percepteive egoistisch oberflächlich/effizient

introvertiert labil offen sensitiv denkend/rational urteilend/judging altruistisch gewissenhaft

EY X X

MB X

FF X X X

X X X X X

EY: als Eigenschaft im Persönlichkeitszirkel von Eysenck enthalten. MB: Bestandteil des Typenindikators von Myers und Briggs. FF: Einer der Faktoren des Fünf-Faktoren-Modells (Big Five)

326

12

Der Mensch im Projekt

In Stresssituationen sind sie eher in der Lage, Ruhe und Übersicht zu bewahren. Menschen mit hohen Neurotizismuswerten sind emotional instabil. Im Extremfall schwanken sie zwischen Euphorie und Depression. Allerdings weisen sie ein höheres Maß an Empathie auf, was die Fähigkeit verbessert, für Andere Verständnis aufzubringen. Als dritte wichtige Persönlichkeitseigenschaft wird heute die Offenheit angesehen. Hiermit meint man die Fähigkeit, neugierig, interessiert und experimentierfreudig zu sein. Offene Menschen können viele neue Impulse und unkonventionelle Ideen zur Lösung von Problemen beitragen. Gerade in frühen Projektphasen kann dies von großem Nutzen sein. Weniger offene Menschen zeigen eher konventionelles Verhalten und konservative Einstellungen. Sie bevorzugen alles Bekannte und Bewährte. Individuelle Unterschiede lassen sich auch bei der Wahrnehmungsart feststellen. Die Mehrzahl der Menschen nimmt die Umgebung vorwiegend sensorisch wahr. Die Sinneseindrücke, die in unmittelbarer Interaktion mit der Umgebung entstehen, besitzen hier die größte Bedeutung. Durch Intuition geprägte Menschen dagegen misstrauen den Sinneseindrücken und verlassen sich eher auf eigene Vorstellungen, auf den „sechsten Sinn“. Sensorische Menschen sehen das konkrete, einzelne Detail, während intuitive Menschen Stärken beim abstrakten Denkvermögen besitzen und eine ganzheitliche Sicht bevorzugen. Große Unterschiede sind bei der Entscheidungsfindung der Menschen feststellbar. Rationale Entscheider versuchen einen Entscheidungsprozess so weit wie möglich zu objektivieren. Sie machen sich Listen und Tabellen und versuchen die Entscheidung logisch und rational nachvollziehbar zu machen. Emotionale Entscheider gehen subjektiv an eine Sache heran, berücksichtigen auch soziale Aspekte und hören auf ihr Bauchgefühl. Gerade in Projekten, in denen viele und oft auch weit reichende Entscheidungen zu treffen sind, ist es gut, nicht nur eine Sorte von Entscheidern zu haben, sondern sowohl die emotionale als auch die rationale Sicht zu berücksichtigen. Bei widersprüchlichen Ergebnissen ist weiteres Nachdenken erforderlich; bei übereinstimmenden Ergebnissen kann man von einer höheren Sicherheit ausgehen. An die Findung einer Entscheidung schließt sich die Frage der Entscheidungsmobilität an. Sie beschreibt, in welchem Maße jemand an einer einmal getroffenen Entscheidung festhält. Flexible Menschen kommen schneller zu Entscheidungen und sind auch eher bereit, eine Entscheidung zu revidieren. Urteilende Menschen brauchen länger, bis eine Entscheidung getroffen wurde, halten aber dafür daran fest. Beide Positionen besitzen Vor- und Nachteile, so dass auch hier im Rahmen eines Projekts der richtige Mix beider Varianten, die richtige Balance zwischen Standhaftigkeit und Flexibilität sicherstellen kann. Die Verträglichkeit ist eine Eigenschaft, die das Verhalten einer Person gegenüber anderen beschreibt. Altruistische Menschen sind gute Teamworker. Sie zeigen Verständnis, Hilfsbereitschaft und Mitgefühl für andere, neigen aber auch zu Vertrauensseligkeit und Nachgiebigkeit. Egoistische Menschen dagegen sind vorwiegend auf ihre eigenen Interessen bedacht. Anderen Interessen wird nur so weit nachgegeben, wie sie einen eigenen Vorteil verheißen.

12.3 Projektteams

327

Altruistische Menschen sind für das Projektteam nicht so eindeutig die bessere Wahl, wie dies auf den ersten Blick scheinen mag. Der Erfolg eines Projekts besteht nicht darin, dass alle nett zu einander sind, sondern dass innerhalb der vorgegeben Zeit das geforderte Ergebnis geliefert wird. Dies setzt nicht nur Kooperation, sondern oft auch die Fähigkeit zu Skepsis, Konflikt und Ehrgeiz voraus. Aus Sicht des Projekterfolgs ist es daher notwendig, den Ehrgeiz des Einzelnen in der Bahn des Projekts zu halten und den Altruismus nur so weit zu fördern, wie er die Leistungsfähigkeit nicht beschränkt. Das Verhalten des Einzelnen in Bezug auf seine Aufgabe beschreibt die Gewissenhaftigkeit. Gewissenhafte Menschen gehen von selbst sehr motiviert an ihre Aufgabe heran und sind erst zufrieden, wenn diese vollständig gelöst ist. Gewissenhafte Menschen liefern auch ohne Druck gute Arbeit; sie sind daher im Projekt von großem Nutzen. Sie neigen aber auch zu Perfektionismus, der ein Projektbudget und den Zeitplan aus dem Ruder laufen lassen kann. Oberflächliche Menschen machen nur so viel, wie gefordert. Sogar diese Eigenschaft kann von Vorteil sein, wenn sie mit Effizienz gepaart ist: Im Sinne des Pareto-Prinzips wird das Nötige mit minimalem Aufwand getan. Der Volksmund bringt diese Einstellung ironisch mit der Bemerkung vom Faulen, der noch nie ein Dummer war, zum Ausdruck.

12.3.3 Team-Entwicklungsphasen Ein Projektteam sollte sich aus kompetenten Fachleuten zusammensetzen, die ihren Ehrgeiz in den Dienst des Projekts stellen, offen und kooperativ miteinander umgehen, um gemeinsam das Projekt zum Erfolg zu führen. Im Idealfall sollten sich die Mitglieder gegenseitig anregen und motivieren, damit die Teamleistung über die Summe von Einzelleistungen hinaus geht. Aus der psychologischen Forschung ist bekannt, dass eine Gruppe nicht unmittelbar nach ihrer Einrichtung sofort in diesem Zustand ist, sondern verschiedene Phasen durchlaufen muss, bis sie zu einem wirklichen Team herangereift ist (siehe Tab. 12.7). Die Gruppenbildung beginnt mit einer Orientierungsphase. Die Mitglieder der Gruppe müssen sich zunächst kennenlernen. Jeder versucht, seine eigene Rolle in der Gruppe zu finden. Gleichzeitig werden die anderen hinsichtlich ihrer charakterlichen Eigenschaf-

Tab. 12.7 Entwicklungsphasen von Arbeitsgruppen (nach Tuckman) Phase Orientierungsphase Konfliktphase Normierungsphase

Engl. Bez. Forming Storming Norming

Leistungsphase

Performing

Charakteristische Merkmale Unsicherheit, Kennenlernen, Formieren Konflikte, Konkurrenzdenken, Machtproben Zusammenrücken, gemeinsame Ziele, Etablierung von Regeln Kooperation, Offenheit, Verständnis

328

12

Der Mensch im Projekt

ten und ihres Sozialverhaltens beobachtet. In dieser Phase können erste Aversionen und Affinitäten zwischen Gruppenmitgliedern entstehen. Nachdem die Gruppenmitglieder sich ein Bild der anderen gemacht haben, entstehen die ersten Rollenkonflikte. Auch wenn diese auf den ersten Blick fachlicher Art zu sein scheinen, sind meistens Emotionen, wie Ehrgeiz, Konkurrenzdenken oder Neid die Auslöser. Auch wenn diese Konfliktphase vielleicht unnötig oder gar ärgerlich erscheint, so haben die Forschungsergebnisse gezeigt, dass sie unvermeidlich und in den meisten Fällen sogar von Nutzen ist. Unausgefochtene Konflikte, werden dauerhaft Zeit mitgeschleppt und sorgen immer wieder für Reibungsverluste. Nachdem einige „Ecken und Kanten“ abgeschliffen und „Hörner abgestoßen“ wurden, kann sich eine Gruppe zusammenraufen. In dieser Normierungsphase besinnt man sich auf die gemeinsamen Ziele. Es etablieren sich – egal ob explizit oder implizit – Werte und Regeln; die eigene Rolle und die Rollen der anderen werden akzeptiert. Die Gruppe kann sich nun aus der Arbeitsfähigkeit in die Leistungsphase weiter entwickeln. Hier leistet nicht nur jedes Gruppenmitglied seine Arbeit, sondern die Arbeit der anderen wird geschätzt. Es wird erkannt, dass der Nutzen einer guten Arbeit der Kollegen für das Projekt größer ist, als der aus Sicht des Konkurrenzdenkens befürchtete eigene Nachteil. Erst in dieser Phase hat sich eine Gruppenidentität gebildet und aus einer Arbeitsgruppe ist ein Projektteam geworden. Die Mitglieder agieren nun nicht mehr als eine Ansammlung von Einzelkämpfern, sondern als eine Einheit, die das Projekt zum Erfolg führen will, der dann auch dem Einzelnen zugute kommt. Die Aufgabe des Projektleiters beim Durchlaufen dieser Phasen, darf es nicht sein, die frühen, als störend empfundenen gruppendynamischen Prozesse zu unterdrücken. Diese Prozesse sind für die Entwicklung zu einem Team notwendig und daher müssen die beschriebenen Phasen durchlaufen werden. Allerdings gibt es keine belastbaren Erfahrungswerte, wie lange die einzelnen Phasen dauern. Es gibt auch keinen Automatismus, der den Ablauf vorhersagbar macht. In jeder Phase können mehr oder weniger große Verzögerungen und Probleme auftreten, die sogar bis zu einem Stillstand der Gruppe führen können. Die Aufgabe eines Projektleiters muss es sein, die Gruppe moderierend und antreibend durch die einzelnen Phasen zu führen. Es ist darauf zu achten, dass beim Austragen der Konflikte keine bleibenden Schäden angerichtet werden, dass die frühen Phasen möglichst effizient durchlaufen werden und die Leistungsphase möglichst schnell erreicht wird. In Gruppen mit unbegrenzter Dauer kommt es hin und wieder zu Rückfällen in die Konflikt- und Normierungsphasen. Für die Weiterentwicklung einer länger bestehenden Gruppe kann dies sinnvoll und notwendig sein. In einem Projektteam bleibt dafür keine Zeit. Deshalb sollte ein Projektleiter derartige Rückfälle unterbinden oder auf einzelne, punktuelle Problemlösungen begrenzen. Projektleiter gehören natürlich selbst zur Gruppe und daher ist diese Rolle auch Bestandteil der Gruppendynamik. Daher müssen Projektleiter neben den praktischen Problemen, die als Führer einer Gruppe und als Moderator beim Austragen von Konflikten zu lösen sind, gleichzeitig auch die eigene Führungsrolle verteidigen, festigen und ausbauen.

Software-Werkzeuge

13

In diesem Kapitel lernen Sie, welche Funktionen PM-Software-Tools bieten und welche Anforderungen an sie gestellt werden. Außerdem wird die Marktsituation der Tools erläutert. Am Beispiel von MS-Excel werden Sie erfahren, wie Office-Werkzeuge für bestimmte Teilaufgaben des Projektmanagement genutzt werden können. Dann werden Sie auf dem kürzesten Weg zum bekanntesten PM-Werkzeug MS-Project geführt, das hinsichtlich Funktionalität und Bedienung einen Standard für PM-Software-Tools darstellt.

Nach der Bearbeitung des Kapitels sind Sie in der Lage,  das für Ihr Projekt am besten passende PM-Software-Werkzeug zu finden,  die wichtigsten Anforderungen zu erläutern, die heute an eine PM-Software gestellt werden,  die wichtigsten Einsatzbereiche von Software-Werkzeugen zur Textverarbeitung und zur Tabellenkalkulation im Rahmen des Projektmanagements zu benennen,  mit Hilfe von MS-Excel – einen hierarchisch gegliederten Projekt-Strukturplan zu erstellen, – eine einfache Ablauf- und Terminplanung in Form eines automatisch formatierten Balkendiagramms darzustellen, – eine Personaltabelle anzulegen und mit den Arbeitspaketen zu verknüpfen, – die Ist-Werte der Bearbeitungstermine in der Tabelle zu verwalten und in die Balkendiagramme zu übernehmen,  mit Hilfe von MS-Project – einen Projekt-Strukturplan mit hierarchisch gegliederten Vorgängen einzugeben, – die Bearbeitungszeiten und weitere wichtige Merkmale der Vorgänge festzulegen,

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021 329 W. Jakoby, Projektmanagement für Ingenieure, https://doi.org/10.1007/978-3-658-32791-0_13

330

13

Software-Werkzeuge

– die Vorgänge über Anordnungsbeziehungen miteinander zu verknüpfen, – die verfügbaren Ressourcen einzugeben und deren Eigenschaften festzulegen, – die Ressourcen zu den Vorgängen zuzuordnen.

13.1 Software-Werkzeuge im Projektmanagement 13.1.1 Einordnung der PM-Software-Werkzeuge Die Tätigkeiten im Projektmanagement sind sehr vielfältig: Erstellung von Berichten, Plänen, Listen und Tabellen; Durchführung und Dokumentation von Besprechungen, Weitergabe und Ablage von Informationen. Neben diesen allgemeinen Aufgaben, wie sie bei fast jeder Bürotätigkeit anfallen, gibt es eine ganze Reihe von Aufgaben, die für das Projektmanagement charakteristisch sind: Entwurf der Projektstruktur, Schätzung von Aufwänden, Planung von Arbeitsabläufen, Zuordnung von Ressourcen, Terminierung, Überwachung und Steuerung der Arbeiten. Die Vielzahl und die Komplexität der skizzierten Aufgaben macht es notwendig, diese durch geeignete Methoden und Werkzeuge zu unterstützen. Aufgrund der enormen Fortschritte bei der Rechnertechnik stehen mittlerweile viele rechnergestützte Werkzeuge hierfür zur Verfügung. Zu Beginn eines Projektes stellt sich daher nicht die Frage, ob es geeignete Werkzeuge gibt oder gar die Frage, ob man überhaupt Werkzeuge einsetzen sollte, sondern, welche Werkzeuge für das konkrete Projekt die richtigen sind. Für die Auswahlentscheidung gibt es mehrere Kriterien. Am wichtigsten ist wohl die Projektgröße: Je größer ein Projekt, desto höher sind die Anforderungen. Sie können nur durch leistungsfähige Werkzeuge bewältigt werden. Findet das Projekt im Rahmen einer Unternehmensorganisation statt, wird zudem eine enge Verzahnung mit der Unternehmens-Software benötigt, mit der z. B. die Ressourcen des Unternehmens (ERP: Enterprise Ressource Planning) und die Produktion geplant und gesteuert (PPS: Produktions-Planung und -steuerung) bzw. die Dokumente (DMS: Dokumenten-Management-System), die Lieferantenbeziehungen (SCM: Supply Chain Management) oder die Kundenbeziehungen (CRM: Customer Relationship Management) durchgängig rechnergestützt gehandhabt werden können. In diesem Fall kann ein Projektmanagement-Werkzeug auch Bestandteil eines integrierten Unternehmens-SoftwareSystems sein. Derartige Systeme sind sowohl in der Anschaffung, als auch im Umgang aufwändig, so dass sie nur bei großen Projekten sinnvoll sind (siehe Abb. 13.1). Bei mittleren Projektgrößen kann das Projektmanagement-Werkzeug eine eigenständige Software sein, die die projekttypischen Aufgaben unterstützt und über geeignete Schnittstellen Daten mit anderen Applikationen austauscht. Ein solches Werkzeug wird ergänzt durch Standard-Büro-Software, mit der die bürotypischen Aufgaben, wie Do-

13.1 Software-Werkzeuge im Projektmanagement

331 ERP-SW PPS

Büro-SW kleine Projekte

PM-SW Büro-SW mittlere Projekte

SCM CRM BDE DMS PM-SW

Büro-SW große Projekte

Abb. 13.1 Einordnung von Projektmanagement-Software-Werkzeugen

kumentenerstellung, Tabellenkalkulation, Kommunikation oder Präsentation gehandhabt werden. Bei einfachen, kleinen Projekten kann unter Umständen schon der Einsatz der Standard-Büro-Software als Hilfsmittel für das Projektmanagement genügen, wenn z. B. mit Hilfe von Textverarbeitungsprogrammen Berichte erstellt und mit einer Tabellenkalkulation Projektpläne erstellt und gepflegt werden. Weitere Gesichtspunkte zur Werkzeugauswahl sind die Erfahrungen der beteiligten Personen. Liegen schon Erfahrungen im Umgang mit Werkzeugen vor und unterscheidet sich ein neues Projekt nicht grundlegend von vorangehenden Projekten, ist es sinnvoll, die bewährten Werkzeuge – auch wenn sie das eine oder andere Manko haben sollten – weiter zu verwenden. Bei aller Wichtigkeit und Leistungsfähigkeit der Werkzeuge sollte aber nie vergessen werden, dass jedes Projektmanagement nur so gut sein kann, wie die agierenden Personen. Kein Werkzeug macht den Projektplan „von selbst“ und kein noch so gutes Projektmanagement-Werkzeug kann ein fehlendes Projektmanagement ersetzen: Zuerst kommt die Methodik, dann das Werkzeug!

13.1.2 Anforderungen an PM-Software-Werkzeuge Der Einsatz von PM-Software-Werkzeugen dient zur Erleichterung der Arbeit des Projektmanagements und zur Verbesserung der Qualität der Ergebnisse. Ein konkretes Ziel hierbei ist die Transparenz der Planung. Da es eine Vielzahl von Arbeiten mit zahlreichen Abhängigkeiten in einem Projekt gibt, ist eine Planung unerlässlich. Indem man die Planung rechnergestützt ausführt, zwingt man sich zu einer stärkeren Systematik. Die Gefahr, Planungsdetails zu vergessen, wird dadurch verringert und Widersprüche in den Plänen werden eher entdeckt. Der Einsatz von Software-Werkzeugen während des gesamten Projektablaufs löst ein Problem, das sonst am Ende eines Projekts wie eine dunkle Wolkenfront heraufzieht: die Dokumentation der Ergebnisse. Werden alle dem Projektauftrag zugrunde liegenden Informationen, die Planungsergebnisse, die Berichte und Tabellen direkt am Rechner erstellt, entsteht die Projektdokumentation im Verlauf eines Projekts. Zum Projektende sind dann nur noch die Abschlussdokumente zu erstellen.

332

13

Software-Werkzeuge

Erledigt man die Standard-Aufgaben, wie sie bei jeder Bürotätigkeit anfallen, mit Büro-Software und die unternehmenstypischen Aufgaben mit ERP-Software, so bleibt ein Bündel von Funktionen, die für das Projektmanagement charakteristisch sind. Sie sollten durch spezielle PM-Software unterstützt werden. Ein Mindest-Funktionsvorrat für eine PM-Software umfasst die Erstellung von terminierten Projektplänen, das Anlegen von Personen- und Ressourcentabellen, die Verwaltung von Kalendern, die Zuordnung von Personen und Ressourcen zu den Arbeiten des Projekts, die Unterstützung bzw. automatische Durchführung eines Kapazitätsausgleichs, das Kostenmanagement, die Steuerung des Projektablaufs und die Überwachung des Projektfortschritts sowie die Ausgabe verschiedener Darstellungsformen der Pläne, Listen und Tabellen. Über den Mindestumfang hinausgehende Funktionen können die Unterstützung der Aufwandsschätzung, der Risikoanalyse, des Wissens-, Konfigurations-, Qualitäts- oder Dokumentenmanagements sein. Eine spezielle Anforderung, die in Unternehmen benötigt wird, in denen mehrere Projekte gleichzeitig, überlappend durchgeführt werden, ist die Eignung eines PM-Werkzeugs für das Multiprojekt-Management bzw. für das Management von Projektportfolios. Werden Personen oder Ressourcen in mehreren Projekten verplant, kann dies zu gravierenden Kollisionen führen, wenn dies nicht berücksichtigt wird. Soll ein PM-Werkzeug nicht nur von einer Person, sondern von vielen gleichzeitig genutzt werden, muss die Software kollaboratives Arbeiten unterstützen. Dies wird in der Regel durch eine Client-Server-Architektur verwirklicht. Die Projektdaten werden vom Server verwaltet, der den gleichzeitigen lesenden oder schreibenden Zugriff von verschiedenen Clients ermöglicht. Die meisten kollaborativen Werkzeuge sind webbasiert, d. h. als Client kommt ein normaler Web-Browser zum Einsatz.

13.1.3 Der Markt für PM-Software Das Angebot an PM-Software war lange Zeit spärlich im Vergleich zu Büro- oder Unternehmens-Software. Dies galt sowohl für die Zahl der Anbieter als auch für die Funktionalität der angebotenen Programme. In den letzten Jahren hat sich diese Situation drastisch gewandelt. Mittlerweile gibt es sehr viele Hersteller von Software-Tools für das Projektmanagement. Auch wenn Tools außer Acht lässt, die nur Teil- oder Randaktivitäten unterstützen, gibt es einige Dutzend Software-Produkte die dem engeren Bereich der PMSoftware zugeordnet werden können. Das Spektrum der Lizenzkosten reicht von kostenlosen Open-Source-Programmen über eine Vielzahl von Programmen im Bereich von mehreren Hundert Euro bis hin zu umfassenden, mehrere Tausend Euro teuren Systemen. Neben dem Anschaffungspreis ist aber auch der Aufwand für die Einarbeitung in die Handhabung einer Software ein kritischer Punkt. Vor allem die komplexe Bedienung der vorhandenen Programme hält viele potentielle Anwender vom durchgängigen Einsatz der Werkzeuge im Projektmanagement ab.

13.2 Office-Werkzeuge im Projektmanagement

333

Neben den vielen kommerziellen PM-Tools, auf die hier nicht näher eingegangen werden kann, gibt es einige gute kostenlose Werkzeuge, wie z. B. GanttProject, Open Workbench, Open Proj und dot Project. Sie bieten die im Projektmanagement am häufigsten benötigten Funktionen, wie Projektstrukturplanung, Ablauf- und Terminplanung, Ressourcenverwaltung und graphische Plandarstellungen. Da sie nach dem Open-SourceKonzept entwickelt werden, spiegeln sie auch den speziellen Funktionsbedarf der Nutzer wider. Sie bieten in der Regel nicht den vollen Funktionsumfang, so dass sie für große Projekte nicht unbedingt erste Wahl sind. Da sie aber moderate Anforderungen bei minimalem Budget erfüllen, sind sie für kleine und mittlere Projekte sehr interessant. Die Arbeit in Teams hat aufgrund der zunehmenden Komplexität der Aufgaben und der fachlichen Vielfalt in den letzten Jahren stark an Bedeutung gewonnen. Eine besondere Herausforderung stellen Teams dar, die über räumliche und zeitliche Grenzen hinweg zusammen arbeiten. Hier sind besondere Hilfsmittel für die Kommunikation, für die Kooperation und die Koordination erforderlich. Die meisten Werkzeuge zur Unterstützung der Gruppenarbeit sind rechnerbasiert. Sie werden als Groupware und ihr Einsatzgebiet als „computer-supported cooperative work“ (CSCW) bezeichnet. Mittlerweile gibt es einige Groupware-Systeme, die die besonderen Anforderungen der Gruppenarbeit in Projekten unterstützen. Als wichtige Beispiele sollen hier openXchange [open-xchange.com], PHProjekt [phprojekt.de], eGroupware [egroupware.org] und dotProject [dotproject.net] genannt werden. Alle Systeme besitzen einen Server, auf dessen Dienste über einen Web-Browser als Client zugegriffen wird. Sie stehen in Form einer GNU-GPL-Lizenz frei zur Verfügung. Wichtige Funktionen zur Kommunikation, zum Dokumentenmanagement und zum Projektmanagement werden durch die Systeme unterstützt.

13.2 Office-Werkzeuge im Projektmanagement 13.2.1 Einsatzbereiche von Office-Werkzeugen In einem Projekt fallen eine ganze Menge von Daten an wie z. B. Projektziele, ProjektStrukturplan, auszuführende Arbeiten, beteiligte Personen, anfallende Kosten und Termine. Diese Daten und viele weitere Informationen wie z. B. die Ergebnisse von Besprechungen, die Inhalte von Berichten, Pläne und Istwerte müssen dokumentiert werden. Für die Planung und Steuerung der Projekte sind außerdem viele Daten miteinander zu verknüpfen. Angesichts der Menge der anfallenden Daten, des Umfangs der Dokumente und der Anforderungen an deren Qualität ist es praktisch unumgänglich, für die Erstellung der Dokumente geeignete Software-Werkzeuge einzusetzen. So genannte Büro-Anwendungen, insbesondere Anwendungen zur Textverarbeitung, zur Erstellung von Grafiken und zur Tabellenkalkulation gehören daher zur Grundausstattung im Projektmanagement. Dies gilt unabhängig davon, ob spezielle Projektmanagement-Tools eingesetzt werden oder

334

13

Software-Werkzeuge

nicht. Berichte, Tabellen und einfache Pläne werden immer mit Büro-Anwendungen erstellt, weil praktisch alle damit umgehen können und weil entsprechende Lizenzen für jeden Arbeitsplatzrechner erschwinglich sind. Diese beiden Bedingungen sind dagegen für dezidierte Projektmanagement-Tools meistens nicht erfüllt. An mehreren Stellen haben daher Büroanwendungen ihren festen Platz im Projektmanagement: 1. Für die Erstellung von „normalen“ Dokumenten, 2. Als Zuliefer-Werkzeuge für PM-Tools, 3. Als Alternative zu dezidierten PM-Tools bei kleinen und mittleren Projekten. Auf den ersten Aufgabenbereich, die Erstellung von „normalen“ Dokumenten wie z. B. Text-Dokumenten, Tabellen, Diagrammen oder einfachen Schaubildern braucht hier nicht näher eingegangen zu werden. Diese Tätigkeiten werden als bekannt vorausgesetzt, da sie in vielen anderen Bereichen ebenfalls benötigt werden und somit keine Besonderheit des Projektmanagements darstellen. Einen besonderen Hinweis verdient aber die Gestaltung der Dokumente. Praktische Erfahrungen geben Anlass zur Befürchtung, dass die gestiegenen Gestaltungsmöglichkeiten moderner Büro-Anwendungen die Gebrauchstauglichkeit der Dokumente oft verschlechtern! Im Laufe eines Projekts werden viele unterschiedliche Dokumente benötigt: Lastenund Pflichtenheft, Projekt-Strukturplan, Personaltabellen, Berichte, Notizen, Kostenaufstellungen, Verträge. Bei der Erstellung dieser Dokumente wird oft ungebremst von den vielfältigen Gestaltungsmöglichkeiten moderner Büro-Anwendungen Gebrauch gemacht. So verlockend es auch ist, in einem Dokument seine individuelle Handschrift oder „Duftnote“ zu dokumentieren, so hinderlich ist dies für die Arbeit im Projekt. Wenn man in jedem Dokument an anderer Stelle nach dem Projektnamen, dem Verfasser oder dem Zweck des Dokuments suchen muss, geht viel Zeit verloren. Aus Projektsicht ist es daher sinnvoll einige Regeln für die Erstellung, den Aufbau und die Gestaltung von Projektdokumenten aufzustellen. Diese Regeln sollten nach den Grundsätzen der Konsistenz und Transparenz ausgerichtet sein. Konsistente Dokumente haben einen einheitlichen, durchgängigen Aufbau. Hierbei wird z. B. festgelegt, welche Informationen in jedem Dokument enthalten sein müssen und wo diese im Dokument zu finden sind. Konsistenz bezieht sich auch auf die Gestaltung: Egal ob man sich hierbei für ein schlichtes, ein klassisches, ein modernes oder ein ausgefallenes Design entscheidet, wichtig ist, dass es im Projekt überhaupt eine Festlegung für ein bestimmtes Design gibt und dass sie auch im Projekt eingehalten wird. Mit Transparenz ist gemeint, dass die Verwendung von bestimmten Stilmitteln wie z. B. Schriftart, -farbe, -größe und -auszeichnung, eine definierte und nachvollziehbare Bedeutung hat. Wenn in einem Dokument mehrere Schriften in jeder denkbaren Stilart und dann noch in unterschiedlichen Farben und Größen eingesetzt werden, sorgt dass zwar manchmal für „Kunstwerke“ expressionistischer Ausdruckskraft aber keinesfalls für Klarheit.

13.2 Office-Werkzeuge im Projektmanagement

335

Tab. 13.1 Codierung für verschiedene Informationskategorien Informationskategorie Überschriften Normaler Text Einstell-Parameter Hilfetexte

Schriftart Times Times Arial Times

Größe 9–11 11 12 9

Schriftfarbe Schwarz Schwarz Weiß Dunkelgrau

Hintergrund Mittelblau Weiß Dunkelblau Hellgrau

Jedem Stilmittel sollte daher eine feste Bedeutung zugeordnet werden. Hierzu ist es nötig, zunächst einmal festzulegen, welche Informationskategorien es in den Dokumenten geben soll. Für jede Kategorie werden dann entsprechende Stilmerkmale festgelegt. Beispiel 13.1 Formatierung von Textinhalten in Tabellen

Um den Texten in den Projekt-Dokumenten eine einheitliche optische Codierung zu geben, werden folgende Regeln für die Schriftauszeichnung bestimmter Informationskategorien im Projektmanagement-Handbuch festgelegt (Tab. 13.1). Wie gut zu erkennen ist, sollten Informationen durchaus redundant codiert werden, da dies eine schnelle und sichere Zuordnung erleichtert. J Der zweite Aufgabenbereich von Büroanwendungen im Projektmanagement ist das Zuliefern von Informationen für dezidierte PM-Tools. Da praktisch alle Mitarbeiter Lizenzen für Büro-Tools auf ihren Arbeitsplatzrechnern haben und zumindest über grundlegende Kenntnisse in deren Nutzung verfügen, ist es naheliegend, Daten, die an verschiedenen Stellen verteilt anfallen, auch direkt vor Ort, d. h. bei den beteiligten Personen zu erfassen und dann an ein zentrales PM-Tool zu übermitteln. Mittlerweile besitzen viele Tools geeignete Schnittstellen und Funktionen die eine derartige Übermittlung vereinfachen. Tabellen eignen sich aufgrund ihrer sehr strikten zweidimensionalen Gliederung in Spalten und Zeilen besonders gut für den Datenaustausch. Hier ist ein Transfer der Daten sowohl über den Clipboard-Zwischenspeicher als auch über den Datei-Import/-Export ohne Probleme möglich. Besonders interessant ist der dritte Einsatzbereich für Büro-Tools im Projektmanagement. Für kleine Projekte und für Unternehmen, bei denen nicht regelmäßig Projekte durchgeführt werden, ist der Einsatz der Büro-Tools eine interessante Alternative zu relativ teuren, schulungsintensiven PM-Tools. Oft werden in derartigen Situationen außer zur normalen Dokumentenerstellung keine Tools für das Projektmanagement eingesetzt. Der Einsatz der Büro-Tools für grundlegende Aufgaben der Planung und Steuerung von Projekten kann hier bei geringem Aufwand zu beträchtlichem Nutzen führen. Vor allem die Tabellenkalkulation spielt hierbei eine wichtige Rolle.

336

13

Software-Werkzeuge

13.2.2 Tabellenkalkulation am Beispiel von MS-Excel1 Ein leistungsfähiges System zur Tabellenkalkulation, wie z. B. MS-Excel, besteht aus mindestens zwei, aufeinander aufbauenden, unterschiedlich komplexen und leistungsfähigen Niveaus: dem Standard-Niveau und dem Makro-Niveau mit einer stark automatisierten Verarbeitung. Auf dem Standard-Niveau der Tabellenkalkulation werden Daten in Form von Zahlen, Zeichenketten, Zeitwerten oder Datumsangaben in Zellen eingegeben. Die Zellen sind zweidimensional zu Tabellen zusammengefasst. Jede Tabelle stellt ein Arbeitsblatt dar. Mehrere Arbeitsblätter bilden eine Arbeitsmappe, die als zusammenhängende Datei gehandhabt wird. Jede Dateneinheit einer Arbeitsmappe kann eindeutig adressiert werden. Für die Namensgebung gibt es dabei eine festgelegte Konvention. Eine Zelle innerhalb einer Arbeitsblatt-Tabelle wird durch einen oder mehrere Buchstaben für die Spalte und eine Zahl für die Zeile adressiert: Beispiel A1, B395, AC17. Sollen Zellen anderer Arbeitsblätter adressiert werden, wird der Name des Arbeitsblatts vor die Zell-Adresse vorangestellt und durch ein Ausrufezeichen abgetrennt: Tabelle 1!B5, Kosten!C3. es gilt also folgende Produktionsregel: Zell-Adr::= Buchstabe+Zahl2 .

Auch über eine Arbeitsmappe hinaus, d. h. über Dateigrenzen hinweg können Zellen adressiert werden. Hier wird der Name der Datei in eckigen Klammern voran gesetzt: [Personen.xls]Stammdaten!D2. Für den erweiterten Namen einer Zelle gilt also die Produktionsregel: Erw-Zell-Adr::= (’[’Datei’]’)? (Arbeitsblatt’!’)? Zell-Adr.

Für viele Verarbeitungsaufgaben müssen zusammenhängende Zellbereiche adressiert werden. Zur eindeutigen Kennzeichnung wird die linke obere und die rechte untere Zelle des Bereichs verwendet und durch einen Doppelpunkt getrennt, z. B. A1:B5. Genauso wie bei einer Zell-Adresse können auch beim Bereich der Blattname und der Dateiname vorangestellt werden: Kosten!C2:C17, [Personen.xls]Stammdaten!B1:C10. Hier gilt also folgende Produktionsregel: Bereich::= (’[’Datei’]’)? (Arbeitsblatt’!’)? Zell-Adr’:’Zell-Adr.

In jeder Zelle können konstante Werte oder Verknüpfungen eingetragen werden. Zur Verknüpfung der Daten stellt MS-Excel mehrere Hundert Funktionen zur Verfügung. 1 2

Microsoft® Office Excel wird im Folgenden als MS-Excel bezeichnet. Verwendete Modifizierer: ? (optional), + (wiederholbar).

13.2 Office-Werkzeuge im Projektmanagement

337

Abb. 13.2 Nutzung der Rechenfunktionen für Zelleninhalte

Hierzu zählen z. B. mathematische, finanzmathematische, statistische und logische Funktionen, sowie Datenbank-, Verweis- und Text-Funktionen. Mit Hilfe der Funktionen und einiger elementarer Operatoren kann der Inhalt einer Zelle als Verknüpfung anderer Zelleninhalte berechnet werden. Beispiel 13.2 Einfache MS-Excel-Berechnungen

In einem Tabellenblatt werden in Spalte A alle Arbeitspakete eines Projekts eingetragen. Für jedes Arbeitspaket wird dann ein optimistischer (Spalte B), ein realistischer (Spalte C) und ein pessimistischer Wert (Spalte D) des Arbeitsaufwands geschätzt und eingetragen (Abb. 13.2). Der Erwartungswert wird dann in Spalte E aus der gewichteten Summe der drei Schätzwerte bestimmt. In Zelle E2 lautet die benötigte Formel hierfür: =(B2+4*C2+ D2)/6. Schließlich wird die Summe aller Erwartungswerte in Zelle E7 als erwarteter Gesamtaufwand des Projekts ermittelt: =SUMME(E2:E6). J Um die Verknüpfung von Daten weiter zu erleichtern und auch komplexe Verarbeitungsalgorithmen zu ermöglichen, die über einfache Zelleneingaben hinausgehen, können in MS-Excel eigene Verarbeitungsfunktionen programmiert und eingebettet werden. Eine derartige Funktion wird als Makro bezeichnet. Als Programmiersprache kommt VBA (Visual Basic for Applications) zum Einsatz. Ein Makro wird immer als Reaktion auf ein bestimmtes Ereignis programmiert. Typische derartige Ereignisse sind die Eingabe einer bestimmten Befehlssequenz, das Öffnen einer Arbeitsmappe, die Eingabe oder Änderung eines Wertes in einer Zelle oder die Betätigung eines Bedienelements. Innerhalb der Programmierumgebung stehen alle Bestandteile der MS-Excel-Anwendung zur Verfügung, also alle Zellen, alle Arbeitsblätter und Arbeitsmappen. Damit gibt es praktische keine Verarbeitungskonstellation, die sich nicht in MS-Excel programmieren lassen würde. Die benötigten Kenntnisse und der Aufwand für diese Verarbeitungen sind aber nicht zu vernachlässigen. Die Makro-Programmierung wird an dieser Stelle nicht weiter vertieft. Makro-Programmierung ist ein recht umfangreiches Kompetenzgebiet für das im Rahmen dieses Buchs – es geht um Projektmanagement – sowohl der Platz als auch die Notwendig-

338

13

Software-Werkzeuge

keit fehlt. Bevor man größere Makro-Bibliotheken für spezielle Verarbeitungsaufgaben im Projektmanagement erstellt, sollte sehr ernsthaft der Einsatz eines eigenständigen PMTools erwogen werden, das diese Funktionen in professioneller und ausgetesteter Form enthält.

13.2.3 Handhabung wichtiger Projektlisten und -pläne mit MS-Excel Viele Daten in Projekten können in Form von Texten, Listen oder Tabellen dargestellt werden. Solange diese Daten nicht exzessiv miteinander verknüpft werden müssen, lassen sie sich als normale Textdokumente oder Tabellendokumente handhaben. Bei manchen Daten bestehen aber stärkere Wechselwirkungen. Für die Planung und Steuerung der Projekte müssen daher Verknüpfungen zwischen den Daten hergestellt und berücksichtigt werden. Hier sind vor allem die im Projekt-Strukturplan enthaltenen auszuführenden Arbeiten und die für die Ausführung der Arbeiten benötigten Personen von zentraler Bedeutung. Daraus abzuleitende Daten sind Termin- und Kostenaussagen. Im Folgenden wird erläutert, wie sich die genannten Daten in einer Tabellenkalkulation wie MS-Excel auf mehreren Arbeitsblättern darstellen lassen und wie die benötigten Verknüpfungen einfach und effizient ausgeführt werden können. Das Ergebnis ist eine aus mehreren untereinander verknüpften Arbeitsblättern bestehende Arbeitsmappe, die eine einfache und wirksame Planung und Steuerung von kleinen oder mittleren Projekten ermöglicht3 . Der Ausgangspunkt für die Projektplanung ist der Projekt-Strukturplan. Für ein Projekt besteht er aus mehreren Teilprojekten, die sich wiederum aus Arbeitspaketen zusammensetzen. Der Projekt-Strukturplan wird auf einem Arbeitsblatt eingegeben. Es besteht zunächst aus je einer Spalte für die Arbeitspakete, für die Teilprojekte und für das Projekt. Durch diese dreistufige Gliederung, ist es möglich, mehrere kleine Projekte mit zwei Strukturebenen in einer gemeinsamen Tabelle zusammenzufassen. Genauso gut kann auch ein mittleres Projekt mit drei Gliederungsebenen in der Tabelle dargestellt werden. Für die Ablauf- und Terminplanung muss der Strukturplan um weitere Felder für die geplante oder geschätzte Dauer, für den Starttermin und den Endtermin für jedes Arbeitspaket erweitert werden. Mit Hilfe elementarer Operatoren können dann die Dauer eines Arbeitspakets (D in Tagen), sein Anfang (A als Datum) und sein Ende (E als Datum) verknüpft werden. Zwei der drei Größen müssen vorgegeben werden, während sich die dritte dann aus der Beziehung E = A + D berechnet lässt.

3

Sie wird als eProM.xlsx zum Download zur Verfügung gestellt und kann frei verwendet werden.

13.2 Office-Werkzeuge im Projektmanagement

339

Abb. 13.3 Tabelle mit Produkt-Strukturplan und Terminen Tab. 13.2 Zelleninhalte mit Verknüpfungen

1 2 3 4 5

E Dauer 5 10 10 7

F Anfang =HEUTE() =ARBEITSTAG(G2;1) =ARBEITSTAG(G3;1) =ARBEITSTAG(G4;1)

G Ende =ARBEITSTAG(F2;E2) =ARBEITSTAG(F3;E3) =ARBEITSTAG(F4;E4) =ARBEITSTAG(F5;E5)

Verwendet man für die Berechnung die normale Addition und Subtraktion, werden auch die Wochenenden verplant. In der Regel möchte man nur die Werktage berücksichtigen. Hierbei helfen die beiden Funktionen ARBEITSTAG(A,N) NETTOARBEITSTAGE(A,E)

Die erste Funktion berechnet den Werktag, der N Tage hinter dem Termin A liegt. Die zweite berechnet die Zahl der Werktage zwischen den beiden Terminen A und E. Bei beiden Funktionen kann als zusätzlicher dritter Parameter eine Liste mit Feiertagen übergeben werden. Ist die Dauer und Reihenfolge der Arbeitspakete bekannt, können alleine aus einem zentralen Starttermin die Anfangs- und Endtermine aller Arbeitspakete bestimmt werden. Beispiel 13.3 Terminplanung mit MS-Excel

Für ein Projekt A mit den 4 Arbeitspaketen AP1 bis AP4, deren Dauer geschätzt wurde, ergeben sich die in Abb. 13.3 dargestellten Anfangs- und Endtermine, wenn alle Arbeiten aufeinanderfolgend ausgeführt werden. In den Spalten E, F und G müssen dazu die in Tab. 13.2 aufgelisteten Berechnungsfunktionen eingegeben werden. Hierbei wird das aktuelle Datum als Anfangstermin für AP1 und damit als Projektanfangstermin gesetzt. Die übrigen Arbeitspakete folgen sequentiell aufeinander. Dazu werden ihre Anfangstermine auf den Arbeitstag gesetzt, der auf den Endtermin des jeweils vorangehenden Pakets folgt. J

340

13

Software-Werkzeuge

Das Ergebnis einer derartigen Eingabe ist eine vollständige Liste aller Arbeitspakete mit den zugehörigen Terminen. Für eine bessere Übersicht bei längeren Listen können Filter- und Sortierfunktionen sorgen: Daten -> Sortieren und Filtern.

Das Sortieren erfolgt anhand der Werte in einer oder mehreren Spalten Es werden immer alle Zeilen ausgegeben. Ein Filter dagegen ermöglicht, nur bestimmte Zeilen darzustellen, bei denen eine wählbare Bedingung erfüllt ist. Damit lassen sich z. B. nur die Arbeitspakete eines bestimmten Teilprojekts darstellen. Ein weiteres Hilfsmittel für die Handhabung größerer Datenmengen innerhalb des Projekts ist das Gruppieren. Hierbei können mehrere Spalten oder mehrere Zeilen zu einer Gruppe zusammengefasst werden: Daten -> Gliederung -> Gruppierung.

Die ganze Gruppe kann dann gemeinsam ein- oder ausgeblendet werden. Eine Gruppierung kann auch mehr als zwei Ebenen umfassen. Vor allem bei hierarchisch gegliederten Datenbeständen, wie dem Projekt-Strukturplan kann die Datenstruktur mit Hilfe der Gruppierung anschaulich dargestellt und gut handhabbar gestaltet werden. Die Berechnung der Termine in Abhängigkeit der Zeitdauern und der Anordnungsbeziehungen zwischen den Arbeitspaketen stellt eine gewisse Arbeitserleichterung gegenüber einer manuellen Berechnung dar. Dies macht sich vor allem bei Änderungen vorteilhaft bemerkbar. Wird z. B. der Starttermin verschoben oder ändert sich die Dauer einzelner Arbeitspakete, ergeben sich in der automatisch berechneten Tabelle unmittelbar alle neuen Termine. Allerdings lässt die Ausgabe als Datumswerte noch Wünsche offen, insbesondere den Wunsch nach einer graphischen Darstellung als Balkendiagramm. Hierfür gibt es in MS-Excel verschiedene Wege, wie z. B. die Ausgabe mit Hilfe der verschiedenen Sorten von Diagrammen. Eine hinsichtlich des Erstellungsaufwands und der Nähe zu den gewohnten Gantt-Diagrammen gute Lösung ist die Verwendung der bedingten Formatierung. Das Ziel der Darstellung ist es, die zeitliche Lage der Arbeitspakete und deren Dauer mit Hilfe von Balken über einer Zeitachse auszugeben. Die Balken sollen sich dabei unmittelbar, d. h. ohne manuelle Eingaben aus den zuvor berechneten Terminen ergeben. Zunächst wird eine größere Anzahl von Spalten als Ausgabebereich für die Balken vorgesehen und mit einer geringen Spaltenbreite formatiert. Die oberste Zeile wird dann als Zeitachse formatiert. In der ersten Spalte (Zelle N1 in Abb. 13.4) wird der Starttermin eingetragen. Die weiteren Spalten werden von hier aus berechnet: =ARBEITSTAG(N1;M$1). Dabei wird ein einstellbarer Parameter (Zelle M1) für die Schrittweite (in Tagen) gewählt, wodurch die Zeitachse skalierbar wird. Damit kann ohne Probleme zwischen verschiedenen zeitlichen Auflösungen (z. B. 1 Tag, 5 Tage, 20 Tage) umgeschaltet werden.

13.2 Office-Werkzeuge im Projektmanagement

341

Abb. 13.4 Arbeitspakete mit Balkendiagramm

Abb. 13.5 Bedingte Formatierung von Zelleninhalten

Durch diese Einstellung in der obersten Zeile gehört zu jeder Spalte des Balkenbereichs ein bestimmter Termin. In den darunter befindlichen Zellen kann dann für jedes Arbeitspaket überprüft werden, wie der Spaltentermin in Relation zum Anfangsund Endtermin jedes Arbeitspakets liegt. Liegt der Spaltentermin innerhalb der Paketlaufzeit, wird in der zugehörigen Zelle ein bestimmtes Zeichen (im vorliegenden Beispiel ein farblich hinterlegtes Leerzeichen) eingetragen. Ansonsten bleibt die Zelle leer: =WENN(UND(N$1>=$F2;N$1