Projektmanagement fur Ingenieure: Gestaltung technischer Innovationen als systemische Problemlosung in strukturierten Projekten. Mit Online-Service

Walter Jakoby Projektmanagement für Ingenieure

Aus unserem Programm

Produktionscontrolling und -management mit SAP® ERP

vonJ.Bauer Projektierung von Automatisierungsanlagen

von Th. Bindei und D. Hofmann Grundkurs SA~ ERP

von D. Frick, A. Gadatsch und U. G. Schäffer-Külz Grundkurs Geschäftsprozess-Management

von A. Gadatsch Management für Ingenieure

von G. Hachtel und U. Holzbaur Masterkurs IT-Management

von J. Hofmann, W. Schmidt, W. Renninger und O. Toufar Investitionsmanagement mit SA~

von J. Jandt und E. Falk-Kalms Handbuch Unternehmenssicherheit

von K.-R. Müller IT für Manager

von K.-R, Müller und G. Neidhöfer IT-Sicherheit mit System

von K.-R. Müller ITIL kompakt und verständlich

von A. Olbrich Prozesse optimieren mit ITIL®

von H. Schiefer und E. Schitterer Optimiertes IT-Management mit ITIL®

von F. Victor und H. Günther www.viewegteubner.de

-----'

Walter Jakoby

Projektmanagement für Ingenieure Gestaltung technischer Innovationen als systemische Problemlösung in strukturierten Projekten Mit 138 Abbildungen, 65 Tabellen, 87 Einzel-Beispielen zur praktischen Anwendung der Methoden, 55 Übungsaufgaben, 128 Verständnisfragen, 4 Fallbeispielen, direkt einsetzbaren Formularen und Checklisten sowie einem Glossar als Mini-Lexikon. STUDIUM

VIEWEG+

TEUBNER

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Das in diesem Werk enthaltene Programm-Material ist mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Der Autor übernimmt infolgedessen keine Verantwortung und wird keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programm-Materials oder Teilen davon entsteht. Microsoft® Office Project ist ein eingetragenes Warenzeichen der Microsoft Corporation. Nachdruck der Screenshots mit freundlicher Erlaubnis der Microsoft Corporation. Höchste inhaltliche und technische Qualität unserer Produkte ist unser Ziel. Bei der Produktion und Auslieferung unserer Bücher wollen wir die Umwelt schonen: Dieses Buch ist auf säurefreiem und chlorfrei gebleichtem Papier gedruckt. Die Einschweißfolie besteht aus Polyäthylen und damit aus organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen.

1. Auflage 2010 Alle Rechte vorbehalten © Vieweg+Teubner Verlag

I Springer Fachmedien Wiesbaden GmbH 2010

Lektorat: Reinhard Dapper

I Walburga Himmel

Vieweg+Teubner Verlag ist eine Marke von Springer Fachmedien. Springer Fachmedien ist Teil der Fachverlagsgruppe Springer Science+Business Media. www.viewegteubner.de

."c" cOP><, .~tl·1~•• c.:s...>, ~.t":;"~

,<'v",

"~J V~


0ov
~G,_c.c

t"

..~...:::..""

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung au ßerhaIb der engen Grenzen des Ur he berrec htsgesetzes .Ist 0 hne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Technische Redaktion: FROMM MediaDesign, Selters/Ts. Druck und buchbinderische Verarbeitung: MercedesDruck, Berlin Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Printed in Germany ISBN 978-3-8348-0918-6

Vorwort Projekte - einmalige, zielorientierte und zeitbegrenzte Vorhaben - sind fester Bestandteil der Arbeitswelt geworden. Sie sind die Reaktion auf steigende Anforderungen in Form komplexer technischer Probleme, kürzer werdender Innovationszyklen, wachsenden Kostendrucks und zunehmender Vernetzung. Um die dabei auftretenden Probleme zielgerichtet zu lösen, Teams termintreu zu führen und Produkte marktgerecht zu gestalten, müssen unstrukturierte Arbeitsflüsse in Prozessen organisiert und durch konsequente Planung und Steuerung als Projekte verwirklicht werden. Selbstverständlich hat es immer schon Projekte gegeben, die "einfach so" zum Erfolg geführt wurden. Es hat aber auch "einfach so" schon manche Projektpleite gegeben. Je höher die Anforderungen und je härter die Randbedingungen sind, desto weniger werden ungemanagte Projekte gelingen. Projektmanagement ist aber keine Kanone, die man auspackt, um jeden kleinen Projektspatzen zu fangen. Es stellt vielmehr eine Palette systematischer Methoden zur Verfügung, die zur Lösung unterschiedlicher Probleme genutzt werden können. Man muss wissen, wie man die Methoden anwendet, man muss wissen, welche man braucht und wann man sie braucht. Dieses Buch soll Absolventen technischer Studiengänge und berufserfahrenen Ingenieuren und Informatikern eine praxisnahe und kompakte Einführung in die Methoden des Projektmanagements geben. Meine Erfahrungen als Projektleiter und als Projektberater bilden nicht nur die fachliche Basis, sondern vor allem die Motivation zum Schreiben des Buchs. Technische Fragestellungen sind oft schon komplex genug; allzu gerne werden daher Fragen zu Kosten und Terminen beiseite geschoben und das Planen und Steuern der Projekte anderen überlassen. Projektmanagement ist in vielen betriebswirtschaftlichen Studiengängen zu finden; in manchen technischen Studiengängen klafft hier eine Lücke. Dies wird der heutigen beruflichen Wirklichkeit nicht gerecht. Wer sich im Dreiklang von Funktionen, Terminen und Kosten nur auf eine Komponente konzentriert, erfüllt seine Aufgabe nur so weit, wie ein Musiker der einen Akkord mit nur einem Ton zu spielen versucht. Ich hoffe, dass dieses Buch zum erfolgreichen Zusammenspiel technischer und wirtschaftlicher Denkweisen beitragen kann, damit aus kreativen Ideen in strukturierten Projekten innovative Produkte werden. Lorscheid, im August 20 I0

WalterJakoby

Inltalt

Vorwort

V

1 Projekte 1.1 In 7 Schritten zum Projekt 1.2 Definitionen............................................................................................................... 1.2.1 Projektbeispiele 1.2.2 Abgrenzung von Nicht-Projekten 1.2.3 Klassifizierung von Projekten 1.3 Systeme und Projekte 1.3.1 Systemdefinition 1.3.2 Projekte aus Systemsicht 1.4 Projekte als Problemlösungsprozesse 1.4.1 Probleme 1.4.2 Prozesse 1.5 Projektmanagement 1.5.1 Der Projektmanagement-Prozess 1.5.2 Entwicklung des Fachgebiets 1.5.3 Normen, Standards, Zertifizierung 1.5.4 Fallbeispiele 1.6 Repetitorium

1 1 4 4 5 11 13 13 15 17 17 21 23 23 27 28 29 31

2 Problemlösen 2.1 Problemanalyse 2.1.1 Problemerkennung 2.1.2 Prob1emstrukturierung 2.2 Erstellung eines Zielsystems 2.2.1 Von der Zielwolke zum Zielsystem 2.2.2 Zielvariablen und Zielkriterien 2.2.3 Randbedingungen und Gütekriterien 2.2.4 Zie1strukturierung 2.3 Lösungssynthese 2.3.1 Bedingungen der Ideenfindung 2.3.2 Methoden der Ideenfindung 2.4 Lösungsauswahl 2.4.1 Intuitive und qualitative Entscheidungen 2.4.2 Analytische Entscheidungsverfahren 2.5 Repetitorium

35 37 37 40 43 43 45 49 51 54 54 57 62 63 64 68

3 Projektgründung 3.1 Das Zieldreieck von Projekten 3.2 Projektauftrag 3.2.1 Lastenheft und Pflichtenheft 3.2.2 Inhalt und Gliederung von Lasten- und Pflichtenheft

71 71 73 73 74

VIII 3.2.3 Formale Anforderungen 3.2.4 Auftragsdokumente 3.3 Projektkalku1ation 3.3.1 Das Aufwands-Auftrags-Di1emma 3.3.2 Mögliche Lösungen 3.4 Repetitorium

Inhalt 78 78 82 82 83 84

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 Standard-Ablaufstruktur 4.2.3 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 4.5 Repetitorium

88 88 88 89 94 96 97 97 101 103 108 108 110 111 115 117

5 Strukturplanung 5.1 Produktstrukturp1anung 5.1.1 Der Produktstrukturp1an 5.1.2 Vorgehensweise zur Planerstellung 5.2 Projektstrukturplanung 5.2.1 Der Projektstrukturp1an 5.2.2 Produktorientierte Gliederung 5.2.3 Prozessorientierte Gliederung 5.2.4 Standard-Projektstrukturp1äne 5.3 Repetitorium

121 122 122 124 126 126 127 129 131 134

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 Repetitorium

136 136 145 154 155 159

7 Ablauf- und Terminplanung 7.1 Anordnungsbeziehungen 7.2 Netzpläne 7.3 Planungsmethoden 7.3.1 Critica1-Path-Method 7.3.2 Metra-Potential-Methode

162 162 165 167 167 169

Inhalt 7.3.3 PERT-Methode 7.304 Gantt-Diagramme 704 Kapazitätsplanung 7.5 Repetitorium

IX 170 174 176 182

8 Risikomanagement 8.1 Projektrisiko 8.1.1 Unsicherheiten in Projekten 8.1.2 Der Risikobegriff 8.2 Der Risikomanagement-Prozess 8.2.1 Risiko-IdentifIkation 8.2.2 Risiko-Bewertung 8.2.3 Risiko-Minderung 8.204 Eventualfallplanung 8.2.5 Risiko-Überwachung 8.3 Repetitorium

185 185 185 186 187 188 191 194 196 197 201

9 Projektsteuerung 9.1 Projektkontrolle 9.1.1 Projektdatenerfassung 9.1.2 Projektdatenauswertung 9.1.3 Fortschrittsplanung 9.104 Meilenstein-Trendanalyse 9.2 Fortschrittssteuerung 9.3 Projektabschluss 9.3.1 Maßnahmen zum Projektabschluss 9.3.2 Mögliche Probleme am Projektende 904 Repetitorium

203 203 204 209 211 216 222 224 224 225 226

10 Der Mensch im Projekt 10.1 Selbstmanagement 10.1.1 Methoden des effizienten Arbeitens 10.1.2 Umgang mit Stress 10.2 Projektleiter 10.2.1 Aufgaben eines Projektleiters 10.2.2 Anforderungen an Projektleiter 10.2.3 Führungsstile 10.3 Projektteams 10.3.1 Teambildung 10.3.2 Personalauswahl 10.3.3 Team-Entwicklungsphasen 1004 Repetitorium

229 229 229 233 235 235 239 241 242 242 244 247 249

11 Software-Werkzeuge 11.1 Software-Werkzeuge im Projektmanagement 11.1.1 Einordnung der PM-Software-Werkzeuge 11.1.2 Anforderungen an PM-Software-Werkzeuge 11.1.3 Der Markt für PM-Software

252 252 252 253 254

X

Inhalt 11.2 Projektplanung und -steuerung mit Microsoft® Office Project 11.2.1 Die Struktur von MS-Project 11.2.2 Vorgangsplanung 11.2.3 Ressourcenplanung 11.2.4 Projektüberwachung 11.2.5 PERT-Analyse 11.2.6 Dateihandhabung 11.3 Repetitorium............................................................................................................

255 255 257 260 263 264 265 266

Anhang Al Formulare A1.1 Projekt-Dokument A1.2 ProjektdefInition A1.3 Arbeitspaketbeschreibung A1.4 Besprechungsbericht A1.5 Statusbericht A1.6 To-Do-Liste A1.7 Risikoanalyse A2 Glossar A3 Verweise A3.1 Literatur A3.2 Hyperlinks A3.3 Normen A4 Verzeichnisse A4.1 Formelzeichen A4.2 Beispiele A4.3 Abbildungen A4.4 Tabellen

269 269 269 270 271 272 273 274 275 276 282 282 285 286 287 287 288 290 294

Sachwortverzeichnis

296

1 Projekte " Wer etwas tun will, findet einen Weg; alle anderen finden Ausreden. " (Sprichwort)

1.1 In 7 Schritten zum Projekt "Wir würden ja gerne Projektmanagement machen, aber dafür fehlt uns leider die Zeit." "PM braucht man nur bei großen Vorhaben mit vielen beteiligten Personen." "Bis jetzt haben wir es auch ohne Projektmanagement noch immer irgendwie hingekriegt." "Ich mache lieber Produktentwicklung als diese ganze Verwaltungsarbeit." Wenn Sie derartige Sprüche hören, ist Vorsicht angesagt: Phrasenalarm! Gerade wenn die Zeit knapp ist, ist Projektmanagement notwendig. Es ist auch bei mittleren und kleinen Vorhaben sinnvoll und nützlich. Und das Beste: Projektmanagement kann man lernen und mit überschaubarem Aufwand betreiben. Angenommen, ihre Bewerbung war erfolgreich. Sie haben die Stelle, auf die Sie so lange hingearbeitet haben, bekommen und müssen jetzt mit Ihrer Familie umziehen. Ist das ein Projekt? Das Vorhaben ist neu und nicht ganz einfach. Es werden eine Menge Probleme auftauchen. Die Zeit ist knapp, das Geld auch und es müssen mehrere Beteiligte zusammenwirken. Aber braucht man dafür Projektmanagement? Investieren Sie ein wenig Zeit in die Analyse des Problems, in die Suche nach möglichen Lösungen und in die Planung der konkreten Realisierung. Machen Sie sich einen Plan und Sie werden den Weg des Projekts wie eine Landkarte vor sich sehen. Sie werden zwar später nicht genau den Weg gehen, den Sie geplant haben, aber Sie werden wissen, wo Sie stehen und sie werden immer wieder herausfinden, wie es weiter geht. Auch das ist Projektmanagement.

Beispiell-l Umzug Mare Theisen hat die Stelle als Entwicklungsleiter bei den Steinbachwerken bekommen. Anfang Juli, d.h. in drei Monaten soll er anfangen. Er möchte mit seiner Frau Anne und den beiden Töchtern nach Neustadt umziehen. Sie setzen sich an einem ruhigen Samstagnachmittag zusammen und überlegen, was zu tun ist. 1. Was ist das Problem? Die Familie lebt derzeit in einer Mietwohnung in Altdorf. Anne arbeitet als Lehrerin. Sie kann zum Anfang des nächsten Schuljahres im September zum Gymnasium in Neustadt wechseln. Die älteste Tochter geht zurzeit in die Grundschule, die jüngere in den Kindergarten. Da die Mietwohnung sowieso zu klein war, möchte die Familie, in Neustadt ein Haus mit einem kleinen Garten mieten. Das Problem besteht also darin, innerhalb von 4 Monaten ein Haus zu suchen und den Umzug der Familie durchzuführen. 2. Was muss getan werden? Die Suche nach dem Haus in Neustadt hat höchste Priorität. Erst danach kann die Wohnung in Altdorf gekündigt werden. Auch die Suche nach einer Schule für die ältere Toch-

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6_1, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

2

1 Projekte tel" und nach einem Kindergartenplatz ist erst möglich, wenn klar ist, in welchem Stadtteil

ein Haus gefunden wird. Für die Haussuche muss die Familie eine Wunschvorstellung entwickeln: lieber ein Reihenhaus in einem Neubaugebiet, ein älteres Haus in der Nähe der Stadtmitte oder doch ein frei stehendes Haus etwas außerhalb? Wenn es dann so weit ist, muss der Umzug organisiert werden und bei den Behörden und Versorgem sind An- und Abmeldungen erforderlich.

3. Wie viel Aufwand ist erforderlich? Die meiste Zeit wird wohl die Suche nach einem geeigneten Haus in Anspruch nehmen. Familie Theisen geht hier von bis zu 3 Monaten aus. Für die Auflösung der Wohnung in Altdorf, das Verpacken aller Habseligkeiten wird etwa eine Woche veranschlagt und für das Auspacken und Einräumen in Neustadt die gleiche Zeit. 4. Wer soll es tun? Für die Suche nach einem Haus muss Familie Theisen zunächst selbst Randbedingungen festlegen. Mit der eigentlichen Haussuche soll ein Immobilienmakler beauftragt werden, der eine Vorauswahl geeigneter Objekte triffi:. Die in Frage kommenden Häuser wird Familie Theisen besichtigen, um sich dann zu entscheiden. 5. Wann soll es getan werden? Da die Zeit drängt wird ein Plan für die verschiedenen Aktivitäten gemacht. Dabei muss die richtige Reihenfolge und der erforderliche Aufwand berücksichtigt werden. Es ergibt sich die folgende Liste. as

AufWand

r:-V 'Haussuche und Kriterien Suche nach geeigneten Objekten Erste Besichtigung~ Weitersuche Zweite Besichtigungen Wohnung kündigen Mietvertrag IUmzug UmzuQsfirma auswählen + beauftragen Festle~un~ Beding~en

Saehenver~

Wohnung räumen Möbeltransport und aufstellen Alles einräumen [F ormalitäten [jschule suchen Kindergartenplatz suchen

-

Wer

Wann

~

1T~ _ _ .6.nne; Marc Makler 25 Tage 2 Tage Anne;Marc 15 TaQe Makler 2 Tage Anne;Marc 1 Tag Mare Anne, Mare ~

27.3. __ 29.3.-30.4. 4.5 + 5.5. 10.5.-27.5. 128. +295 31.5. 4.6,

2Ta9~ 4 Tage 1 Tag 1 Tag 4 Tage

~

7.6 24.6.-276 28.6. 29.6. 17,-4,7.

Anne Anne

177

1T~

1 Tag

-

Anne;Mare Umzugsfirma UmzuQsfirma Anne;Mare

8.7

Büd 1-1 Ein einfacher, erster Projektplan für den Umzug

6. Wo sind die Risiken? Eine wichtige Frage ist, ob ein geeignetes Haus gefunden wird. Deshalb planen Marc und Anne in zwei Schritten vorzugehen. In einer ersten Runde wird versucht, ein Haus zu fmden, das den eigenen Vorstellungen am nächsten kommt. Sollte dies nicht gelingen, müssen die Anforderungen so weit reduziert werden, dass die Erfolgsaussichten in einer zweiten Runde besser sind.

3

1.1 In 7 Schritten zum Projekt

Ein weiteres Risiko ist natürlich der Zeitplan. Deshalb wird zwischen dem idealen, geplanten Einzugstermin und dem spätest möglichen Termin Ende August, der durch den Schulbeginn festgelegt ist, noch ein Puffer von fast einem Monat geschaffen. Wenn sich Verzögerungen ergeben, können sie durch den Puffer ausgeglichen werden. Bis zum Dienstantritt von Mare Theisen, am 1.7. ist der Umzug sowieso nicht zu schaffen, so dass er vorübergehend in einem Hotel übernachten muss. 7. Läuft es nach Plan? Diese Frage wird sich jeden Tag bei der Durchführung stellen. Da ein Plan existiert, können auch Abweichungen schnell erkannt, deren Auswirkungen abgeschätzt und darauf reagiert werden. Die 7 Fragen sind natürlich nur ein Anfang. Aber sie zeigen, dass man schon mit wenig Aufwand eine ganze Menge Einsicht in ein Problem gewinnen, Ideen skizzieren und eine Lösung planen kann. In einem einfachen Projekt können auch die Antworten auf die Frage einfach sein. In Projekten einer nennenswerten Komplexität steht aber jede der Fragen stellvertretend für einen ganzen Fragenkomplex. Jeder Fragenkomplex wird in einer Phase des Projekts untersucht und beantwortet und liefert ein Ergebnis, auf das in der folgenden Phase aufgebaut werden kann. Tabelle 1.1 7 Fragen zum Projekt Frage

Ergebnis

Kapitel

1.

Was ist das Problem?

Problembeschreibung

2,3

2.

Was muss getan werden?

Projektstrukturplan

5

3.

Wie viel Aufwand ist erforderlich?

Zeitaufwand und Ressourcenbedarf

6

4.

Wer soll es tun?

Personalplan

4

5.

Wann soll es getan werden?

Terminplan

7

6.

Wo sind die Risiken?

Risikoidentifikation

8

7.

Läuft es nach Plan?

Projektcontrolling

9

Im ersten Kapitel dieses Buchs wird der Hintergrund für die Fragen grundlegend untersucht und beschrieben. Jedes folgende Kapitel beschreibt dann im Einzelnen, wie man im konkreten Projekt Antworten auf die Fragen findet. Kapitel 2 beschreibt 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) und der Projektsteuerung (Kap. 9). Eine gesonderte Darstellung verdient die Betrachtung des Menschen im Projekt (Kap. 10). Den Abschluss des Buches bildet eine Anleitung zum Einsatz von Werkzeugen im Projektmanagement (Kap. 11).

4

1 Projekte

1.2 Definitionen "Der Beginn der Weisheit ist die Definition der Begriffe. " (Sokrates)

1.2.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. 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 Millionen 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 Hoover-Dam 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. m 3 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. $). Das "Toshka-Projekt" ist ein Vorhaben in Ägypten, mit dem Ziel, die Toshka-Senke im Südwesten des Landes durch Bewässerung für die Landwirtschaft nutzbar zu machen. Das Projekt wurde 1996 begonnen. Es soll bis zum Jahre 2017 abgeschlossen sein und wird ca. 60 Mrd. € kosten. Hinter dem harmlos klingenden "Manhattan-Projekt" verbirgt sich der Bau der ersten Atombombe in den USA während des 2. Weltkriegs. Das Projekt startete im August 1942 und führte im Juli 1945 zur ersten Zündung einer Bombe in der Nähe von Los Alarnos. Zeitweise waren bis zu 100.000 Personen an dem Projekt beteiligt, das Kosten von ca. 2,5 Mrd. $ verursachte. 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

1.2 Definitionen

5

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! Ähnlich "erfolgreich" war das Projekt zur Entwicklung der Concorde. Es wurde 1962 mit einem geplanten Kostenrahmen von 100 Mio. englischen Pfund begonnen und sollte bis 1968 fertig gestellt werden. Der tatsächliche Projektabschluss gelang aber erst 1976 und die Kosten explodierten auf 1,46 Mrd. Pfund! Insgesamt wurden 20 Flugzeuge des Typs Concorde gebaut. Der letzte Flug fand im Jahr 2003 statt, so dass 14 Jahre Entwicklungszeit einer Einsatzzeit von 27 Jahren gegenüber stehen. Von den jährlich in den USA durchgeführten 175.000 Software-Projekten mit einem GesamtVolumen von 250 Mrd. $ untersuchte die Standish Group im Jahre 1994 8.300 Projekte. Von diesen waren 16 % erfolgreich, 53 % wurde verspätet, viele sogar deutlich verspätet fertig gestellt und 31 % wurden abgebrochen. Weitere Untersuchungen in den Jahren 1996 und 1998 brachten ähnliche Ergebnisse. 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 zunehmende 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.2.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 Projektcharakter 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.

Beispiel1-2 Sind das alles Projekte? Mit dem Apollo-Programm verfolgte die USA in den 6Oer-Jahren des 20. Jahrhunderts das Ziel, den ersten Menschen zum Mond und wieder zurück auf die Erde zu bringen. Das Ziel

6

1 Projekte wurde 1960 von Präsident Kennedy verkündet und im Juni 1969 zu einem erfolgreichen Abschluss gebracht. Das Programm kostete 25 Mrd. $ und beschäftigte 400.000 Menschen. Unter dem Namen "Projekt Gutenberg" (www.gutenberg.org) wird seit 1971 eine elektronische Bibliothek mit frei verfügbaren Werken von Schriftstellern aus aller Welt erstellt. Sie umfasst derzeit 25.000 Werke. Das "Human Genom Project" (www.genome.gov/l0001772) hatte das Ziel, das Erbgut des Menschen, welches aus 23 Chromosomenpaaren, ca. 25.000 Genen und 3 Mrd. Basenpaaren besteht, vollständig zu entschlüsseln. Das Projekt wurde 1990 gestartet und im Jahre 2003 abgeschlossen. Am Anfang arbeiteten ca. 1000 Wissenschaftler an diesem Projekt mit. Unter dem Namen "Eden Project" (www.edenproject.com) wurde von 1995 bis 2001 in Cornwall, im Südwesten Englands auf 50 ha. Fläche ein botanischer Garten errichtet. In kuppelförmigen Gewächshäusern werden verschiedene Vegetationsbedingungen nachgebildet, um alte, seltene und vom Aussterben bedrohte Pflanzenarten zu züchten und zu erhalten. Das GNU-Projekt (www.gnu.org) wurde 1983 gegründet mit dem Ziel, ein neues, kostenlos verfügbares Betriebssystem für Rechner zu entwickeln. Im geplanten Desertec-Projekt (www.desertec.org) sollen für 400 Mrd. € in der Sahara Solarkraftwerke zur Stromgewinnung gebaut werden. In 10 Jahren sollen damit 15 % des europäischen Stromverbrauchs gedeckt werden.

Wodurch wird ein Vorhaben zu einem Projekt? Alle im vorangehenden Kapitel beschriebenen Vorhaben waren zweifelsfrei Projekte. Es handelte sich fast immer um sehr umfangreiche Aufgaben, mit vielen einzelnen Arbeiten und vielen beteiligten Personen, die in organisierter Form auf ein Ziel hin gearbeitet haben. Alle Projekte waren auf ihre Art neuartig, einmalig und durch vielfältige technische Schwierigkeiten gekennzeichnet. Bei genauerem Hinschauen kann man auch begrenzte Ressourcen (Kapital, Maschinen, Werkzeuge, Platz) und begrenzte Zeit als charakteristische Merkmale erkennen. Zentrale Merkmale, die das Wesen eines Projekts ausmachen, sind also: 1. Zielklarheit 2. Einmaligkeit: Neuartigkeit des Vorhabens 3. Schwierigkeit der Aufgabe 4. Prozesscharakter: Zusammensetzung aus vielen Arbeitsschritten 5. Terminierung: Begrenzung der zur Verfügung stehenden Zeit 6. Teambildung: Beteiligung mehrer Personen 7. Ressourcenbegrenzung. Die Komprimierung dieser Kriterien führt zu folgender Definition:

Ein Projekt ist ein zeitlich begrenztes Vorhaben, zur Schaffimg eines neuartigen Produkts oder einer neuartigen Dienstleistung. 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?

1.2 Definitionen

7

Besteht ein Vorhaben aus nur einem einzigen Arbeitsschritt, wird wohl niemand auf die Idee kommen, dies als Projekt zu bezeichnen: die Erstellung eines Besprechungsberichts, die Beantwortung einer Kundenreklamation durch den technischen Service oder das Aufspielen einer neuen Software-Version sind sicher keine Projekte. Auch wenn ein Vorhaben aus mehreren Arbeitsschritten besteht, ist es noch nicht zwangsläufig ein Projekt. Sind die Arbeiten nämlich sehr einfach oder laufen immer wieder gleichartig ab, kann man nicht von einem Projekt sprechen: die Auswahl und Anschaffung eines neuen Laptops, die Durchführung einer regelmäßigen Vertriebsbesprechung, eine wöchentliche ablaufende Datensicherung oder die Erstellung einer Bilanz am Ende eines Geschäftsjahres sind öfter wiederkehrende Vorhaben und besitzen daher keinen Projektcharakter. Schwieriger wird die Einschätzung bei komplexen und umfangreichen Vorhaben, wie z. B. die kontinuierliche Verbesserung eines Produktionsprozesses, die Suche nach einem neuen physikalischen Prinzip zur Energiegewinnung, der Beweis der Fermat'schen Vermutung, das Raumfahrtprogramm der Vereinigten Staaten oder die Herstellung des Weltfriedens. Auch wenn das eine oder andere dieser Vorhaben vielleicht auf den ersten Blick als Projekt eingestuft wird, fehlen bestimmte Merkmale, die im allgemeinen Konsens als wesentlich angesehen werden. Keines dieser Vorhaben besitzt eine zeitliche Begrenzung. Nicht in jedem Fall ist ein konkretes und nachprüfbares Ziel erkennbar und auch die Begrenzung der zur Verfügung stehenden Ressourcen ist unklar. Oft sind es gerade die fehlenden Projektmerkmale, die zum Scheitern der Vorhaben führen. Im Umkehrschluss bedeutet dies, dass die Erfolgsaussichten steigen, wenn aus den Vorhaben Projekte gemacht werden, indem klare Zielsetzungen und klare Zeitvorgaben geschaffen werden. Um die Projekt-Frage ("Projekt" oder "Nicht-Projekt") auf systematische Weise zu beantworten, ist es naheliegend, die beschriebenen Merkmale als Kriterien zu verwenden. Für jedes Vorhaben sollte also überprüft werden, ob die genannten Kriterien erfüllt sind, eventuell auch zu beurteilen, in welchem Maße sie erfüllt sind, die Ergebnisse zu gewichten, um dann zu einer Entscheidung zu kommen.

Beispiel1-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 wenn sie es nicht explizit tun, welche unsystematischen, unformalen Management-Methoden 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?

1 Projekte

8

Das Ergebnis der Analyse eines Vorhabens hinsichtlich der Erfüllung der Projektkriterien sind also im einfachsten Fall sieben binäre Werte ("erfüllt" oder ,,nicht erfüllt"). Bei den Projektkriterien kann es aber auch fließende Übergänge mit stetigen Erfüllungsgraden geben. Ein Produkt ist z. B. nie vollständig, sondern immer nur in bestimmten Aspekten neuartig. Jedes Projektkriterium kann daher nur zu einem gewissen, zwischen 0 % und 100 % liegenden Grad auf die Projekt-Eigenschaft des Vorhabens hinweisen. Kennt man die Werte der Kriterien, ist die binäre Projekt-Frage allerdings noch nicht beantwortet. Da es mehrere Projektkriterien gibt, kann es durchaus sein, dass ein Merkmal das Vorhaben als Projekt ausweist, ein anderes aber nicht. Ein weiterer Unsicherheitsfaktor ist die Subjektivität: was für den einen einfach ist, kann für andere schwierig sein. Was der eine als Projekt ansieht, ist für den anderen nur eine Routine-Aufgabe. Zur Klärung dieser Frage könnte man ein Vorhaben dann als Projekt einstufen, wenn die Mehrzahl der Merkmale erfüllt ist, oder wenn der Mittelwert der Erfüllungsgrade über 50 % liegt. Allerdings ist ein solcher Ansatz nicht zwangsläufig richtig. Selbst wenn nur ein Merkmal erfüllt ist, kann eine Entscheidung für ein Projekt sinnvoll sein. Ist die Aussage der Projektmerkmale sehr eindeutig in die eine Richtung, kann man ohne Zweifel von einem Projekt sprechen und genau so im entgegen gesetzten Fall von einem Nicht-Projekt. Zwischen diesen beiden Extremen bleiben aber viele Vorhaben, bei denen die Projekt-Eigenschaft mit Einschränkungen gegeben ist. Ein Vorhaben ist also umso eindeutiger ein Projekt, je mehr Projektkriterien erfüllt sind, je stärker diese erfüllt sind und je mehr Menschen die Einschätzung der Merkmalserfüllung teilen. Vorhaben /"

Projekte 1. Zielklarheit 2. Einmaligkeit 3. Schwierigkeit 4. Prozesscharakter 5. Terminierung 6. Teambildung 7. Ressourcenbegrenzung

~

Grenzfälle

~

Nicht-Projekte 1. 2. 3. 4. 5. 6. 7.

unklare Ziele Routine einfach ein Arbeitsschritt kein Zeitlimit nur eine Person unbegrenzte Ressourcen

Bild 1-2 Abgrenzung von Projekten und Nicht-Projekten

Die Analyse der beschriebenen Projektmerkmale erfordert einen nicht zu leugnenden Aufwand. Die Gewichtung der Ergebnisse kann auf unterschiedliche Art erfolgen. Zusätzlich wird diese Situation noch dadurch erschwert, dass die Beurteilung subjektiv, d. h. vom Erfahrungsschatz der beurteilenden Person abhängig ist. Angesichts dieser Schwierigkeiten zu entscheiden, ob es sich bei einem Vorhaben um ein Projekt handelt oder nicht, könnte man geneigt sein, sich den Aufwand für eine genauere Analyse zu ersparen und die Entscheidung "nach Gefühl" zu treffen. Gerade dadurch werden aber bereits am Anfang entscheidende Fehler gemacht, die später nur mit erheblichem Mehraufwand korrigierbar sind. Entscheidet man sich fälschlicherweise dafür, ein Vorhaben als Nicht-Projekt anzusehen und entsprechende Management-Methoden nicht anzuwenden, kann es zu vielfältigen Problemen, Verzögerungen und eventuell sogar zu einem Scheitern kommen. Behandelt man dagegen jedes Vorhaben als Pro-

1.2 Defmitionen

9

jekt, betreibt man unnötigen Aufwand und nervt die Beteiligten mit Arbeiten, Besprechungen und Berichten, die als übertriebener Formalismus empfunden werden. Die Frage, ob es sich bei einem Vorhaben um ein Projekt handelt, ist also keine akademische Frage. Die richtige Antwort bildet die Basis dafür, dass tatsächliche Projekte zum Erfolg geführt und Nicht-Projekte ohne unnötigen Aufwand durchgeführt werden. Die Projekt-Frage sollte daher immer der Auslöser für eine erste gründliche Analyse eines Vorhabens sein. Am Ende einer solchen Analyse steht dann nicht nur eine Antwort auf die Frage "Projekt oder Nicht-Projekt", sondern die Antwort, die ja viele subjektive Faktoren enthält, wird objektiviert: Ihr Zustandekommen wird nachvollziehbar und dadurch wird die Gefahr einer falschen Antwort deutlich verringert. Außerdem führt die Analyse eines Vorhabens im Rahmen der ProjektFrage zu einer ersten, tieferen Einsicht. Jedes Merkmal macht eine spezielle Teilproblematik eines Projekts aus. Jedes Teilproblem wiederum erfordert spezielle Lösungsmethoden. Die Kenntnis des Projektprofils, d. h. der Erfü1lungsgrade der einzelnen Merkmale gibt unmittelbare, wichtige Hinweise auf die benötigten Lösungsmethoden. Tabelle 1.2 Problematiken von Projekten und zugehörige Maßnahmen Problematik

Maßnahmen

Zielklarheit

Explizite Zielformulierung

Einmaligkeit

Fachwissen, Erfahrungen (eigene und fremde)

Schwierigkeit

Fachwissen

Prozesscharakter

Planung

Terminierung

Parallelisierung, Planung

Teambildung

Organisation

Ressourcenbegrenzung

Serialisierung, Planung

Ein Projekt bei dem z. B. viele Personen beteiligt sind, erfordert ganz andere Organisationsstrukturen, als ein Projekt mit wenigen oder gar nur einer beteiligten Person. Auch die Frage des Informationsmanagements, also der Ablage von Informationen und des Zugriffs auf Informationen für die Beteiligten steigt überproportional mit deren Zahl an. Technisch besonders schwierige Projekte erfordern ein ausgeprägtes Maß an Fachwissen. Hier ist also der Fokus auf das Finden von Projektbeteiligten mit dem passenden Kompetenzprofil zu legen. Bei Projekten mit extremem Zeitdruck ist es erforderlich, die Arbeiten so weit wie möglich zu parallelisieren. Aufgrund der gegenseitigen Abhängigkeiten erfordert dies natürlich eine sehr genaue Planung und Koordination. Projekte mit extremer Ressourcenbegrenzung können dagegen oft nur durch Serialisierung der Arbeiten durchgeführt werden. Auch dies erfordert eine genaue Planung, kollidiert aber mit dem gerade erläuterten Wunsch zur Parallelisierung. Es ist also nicht immer vermeidbar, dass Anforderungen, die aus unterschiedlichen Projektmerkmalen resultieren, sich gegenseitig widersprechen. Solche Konstellationen sind manchmal gar nicht oder meistens nur durch geeignete Kompromisse lösbar. Aufgrund der Mehrdimensionalität eines Projekts ist es also nicht so, dass alle Projektmanagementmethoden und -maßnahmen in jedem Projekt gleich wichtig sind. Nur durch Kenntnis

1 Projekte

10

des individuellen Projektprofils ist es möglich zu beurteilen, welche der vielen im Projektmanagement verfügbaren Methoden und Werkzeuge im konkreten Fall benötigt werden und welche verzichtbar sind.

Beispiel1-4 Projektkriterien Bei den folgenden Vorhaben soll untersucht werden, ob es sich um Projekte handelt. 1. Leitung eines Unternehmens. 2. Entwicklung einer neuen Mikroprozessorschaltung. 3. Re-Design einer bestehenden Mikroprozessorschaltung wegen Umstellung auf schadstoffarme Bauteile. 4. Suche nach einem neuen Prinzip zur platz-, gewichts- und kostensparenden Speicherung elektrischer Energie. TabelJe 1.3 Projektkriterien für verschiedene Projekte Kriterien Vorhaben

Z

E

S

P

T

B

R

Ergebnis

Untemebmensleitung

+

0

+

+

-

+

+

Nein!

Entwicklung neue Mikroprozessorschaltung

+

+

+

+

+

0

+

Ja

Re-Design Mikroprozessorschaltung

+

0

0

+

+

0

+

Nein

Neuer Energiespeicher

0

+

+

+

?

+

+

Unklar

Z: Zielklarheit, E: Einmaligkeit, S: Schwierigkeit, P: Prozesscharakter, T: Terminierung, B: Teambildung, R: Ressourcenbegrenzung 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. 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.

11

1.2 Definitionen

1.2.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, erfordert andere Planungs- und Organisations-Methoden als ein Projekt mit wenigen Beteiligten und wenigen Monaten Laufzeit. Um entscheiden zu können, welche Management-Methoden 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öDe. 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 "Mannjabre" 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 5 Größenordnungen sowohl bei der Zahl der am Projekt beteiligten Personen und auch von 5 Größenordnungen bei der Projektlaufzeit aus, so erhält man folgende Projektgrößen.

.

J1a,hre

0,1 0,3 1 3

5

-

Beteiligte Personen

1 0,1 0,3 1 3 5

I I I

3

10

30

100

0,3

1 3

3

10 30 100 300

0,9 3

9 15

f-

9

10 - -

30

30 50

150

90

t I

500

I

L I

sehr klein ~ein mittel groß sehr ~roß

f-

Größe

Kosten

< 0,5 PJ

< 100 T€

0,5 .. 5 PL 100 T€ .. 1 Mio€ 5 .. 50 PJ 1 .. 10 Mio € 50. 500 PJ 10 .. 100 Mio € > 500 PJ >100Mio€

BUd 1-3 Klassifizierung von Projekten nach der ProjektgTÖße

Projekte mit wenig Beteiligten und sehr langer Laufzeit oder Projekte mit sehr vielen Beteiligten und sehr kurzer Laufzeit 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 5 PJ als ,,klein" und Projekte mit mehr als 50 PJ als "groß" und dazwischen liegende als ,,mittel" bezeichnet werden können. Außerdem kann

12

1 Projekte

nach unten ("sehr klein" <0,5 PJ) und nach oben ("sehr groß" > 500 PJ) weiter differenziert werden. Zur Bestimmung der Kosten wurde in der Tabelle davon ausgegangen, dass eine Projektgröße von 1 PJ Kosten von 200 Tsd. € (inklusive Material, Maschinen etc.) verursacht. Die reinen Personalkosten sind dabei mit der Hälfte dieser Summe, also 100 Tsd. €IPJ veranschlagt. In erster Näherung kann außerdem von 10 Tsd. € pro Personenmonat ausgegangen werden (1 PJ = 11 PM = 220 PT). Natürlich handelt es sich bei diesen Zahlen um grobe Näherungen, die im konkreten Fall deutlich abweichen können. Einen beträchtlichen Einfluss hat dabei natürlich 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 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 modeme aber auch historische Projekte wurden in der Baubranche durchgeführt. Hierzu zählen Tietbauvorhaben, 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 SoftwareAnwendung 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. Probleme 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 betrim, 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,

13

1.3 Systeme und Projekte

Staudämmen, Inseln, Kanälen, Flughäfen oder von Produktionsanlagen. Ein besonderes Merkmal von Investitionsprojekte ist das hohe Kostenbudget, das durch einen vermehrten Bedarf an Maschinen, Rohstoffen und Zulieferteilen entsteht und das in der Planung und Steuerung eines besonderen Augemerks bedarf.

1.3 Systeme und Projekte In einem geschlossenen System nimmt das Chaos mit der Zeit zu. (Zweiter Hauptsatz der Thermodynamik)

1.3.1 Systemdefinition Ein System ist ein Gebilde, das von seiner Umgebung als zusammenhängende Einheit abgegrenzt werden kann. Das System 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. Umgebung

,

--------1---------' v I I

u

syst~eY : x I I

I I I

Bild 1-4 Externe Sicht zur System-Abgrenzung

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 angeschlos-

1 Projekte

14

sen 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. 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 Server-Rechnern, 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. Umgebung

D

D

D

Bild 1-5 Interne System-Sicht

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.3 Systeme und Projekte

15

1.3.2 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. 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 fmdet 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.

A

E

A-A

Ressourcen

B-B

R-R

Projekt

Bild 1-6 Ein Projekt aus Systemsicht

Zwischen diesen Projekt-Elementen können diverse Beziehungen bestehen: 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. A-R: Für die Arbeiten werden bestimmte Ressourcen benötigt, z. B. welche Maschine wird gebraucht, welche Kosten verursacht die Arbeit. B-R: Auch die Beteiligten nehmen Ressourcen in Anspruch, wie z. B. Gehalt, Arbeitsplatz, Rechner. R-R: Auch zwischen den Ressourcen bestehen Beziehungen, wie z. B. jede Ressource nimmt Kapital in Anspruch, eine Maschine braucht Platz.

16

1 Projekte

Beispiel 1-5 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 durchzufUhrender 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, 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 ausgefiihrt 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. Die Wechselwirkungen eines Systems mit seiner Umgebung und die Wechselwirkung der Systemkomponenten untereinander bilden die Struktur des Systems. Die Struktur ist meistens ein relativ gleichbleibender, statischer Aspekt eines Systems. Zusammen mit den Zustandsgrößen fUhren die Wechselwirkungen aber auch zu einem wichtigen dynamischen Aspekt. Die Ausfiihrung von Arbeiten durch die Beteiligten unter Einsatz von Ressourcen nimmt Zeit in Anspruch. Sollen mehrere Arbeiten von einer Person oder auf einer Maschine ausgefiihrt 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.4 Projekte als Problemlösungsprozesse

17

1.4 Projekte als Problemlösungsprozesse Der Optimist sieht in jedem Problem eine Aufgabe, der Pessimist in jeder Aufgabe ein Problem. Der Realist weiß Aufgaben und Probleme zu unterscheiden.

1.4.1 Probleme "Man ist entweder Teil der Lösung oder Teil des Problems. (Michail Gorbatschow) H

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 vielfaltigen 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.

Beispiel1-6 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. Der Stromfluss durch die Reihenschaltung eines elektrischen Widerstands und eines Kondenstors nach dem Einschalten der Spannung soll als Zeitverlaufberechnet werden. 4. Es soll ein Schaltnetzteil für einen Rechner mit 100 Watt Leistung entwickelt werden. 5. Im Rahmen einer I-wöchigen Schulung soll den Teilnehmern die Kunst des Projektmanagement beigebracht werden. 6. Ein ehemaliges Bahnhofsgebäude an einer stillgelegten Bahnlinie soll zu einem Hotel umgebaut werden. 7. Es soll ein Auto für 4 Insassen konstruiert werden mit einem Verbrauch von weniger als 1 Liter auf 100 km. 8. Ein Industriegebiet soll über eine neue Straßenverbindung an die bestehende Autobahn angeschlossen werden, um die nahe gelegene Stadt vom Verkehr zu entlasten 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. Ein System durch geeignete Handlungen aus einem Anfangs- in einen Zielzustand zu bringen ist eine Aufgabe. Aufgaben können extrem 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 schwer sein. Auch der einfache Pakettransport, kann kompliziert werden, wenn jemand kein Auto hat, nicht weiß, wo Hamburg liegt oder wenn das Paket 2 Tonnen wiegt. Eine Aufgabe wird zu einem Problem, wenn es ein Hindernis gibt, dass die Lösung der Aufgabe erschwert oder gar verhindert wird. Eine Aufgabe wird zu einem Problem, wenn der Weg vom Anfangs- zum Zielzustand durch ein Hindernis erschwert wird.

18

1 Projekte

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 oder wenn nicht klar ist, welche der vielen Handlungsmöglichkeiten die beste ist. Sind die Handlungen bekannt, muss auch entschieden werden in welcher Reihenfolge diese ausgeführt werden. 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 von untergeordneter Bedeutung, so dass einige wenige dominierende Problemdimensionen übrig bleiben.

Beispiel1-7 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 fmden wird der Problernraum durch Größen wie Arbeitsfreude, Bezahlung, Branche, Region aufgespannt. Bei allen 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. In vereinfachter, aber einprägsamer Form kann man folgendes Modell eines Problemlösungsprozesses skizzieren. 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 zu bringen, indem bestimmte Handlungen u in der richtigen Reihenfolge ausgeführt werden.

1.4 Projekte als Problemlösungsprozesse

x2

19

R2

R1

R3

RO R4 x1 Bild 1-7 Zustandsraummodell des Problemlösungsprozesses

Die Randbedingungen R grenzen den Handlungsspielraum ein, da sie verbotene Bereiche definieren. Dabei gibt es Randbedingungen (Rl bis R4), die während des gesamten Problemlösungsprozesses einzuhalten sind und andere (RO), die nur nach Erreichen des Zielzustands gelten. Der innerhalb der Randbedingungen verbleibende Zielraum kann zusätzlich durch ein Gütekriterium J beschrieben werden, das durch die Lösung zu optimieren ist. 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. Problemdimensionen

A~Ufw:~s~nalkosten aterialkosten [

aschinenkosten Zeitaufwand

Nutzen f-Funktionalität Lßenutzerfreundlichkeit Bild 1-8 Problemdimensionen Aufwand und Nutzen und mögliche Unterteilungen

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 Projekte

20

Beispiel1-8 Studium Ein Studium soll unter dem Gesichtspunkt der Problemlösung betrachtet werden. Als Problemdimensionen kann man den erforderlichen Aufwand A und die erzielte QualifIkation Q betrachten. Der Aufwand ist zeitlicher und finanzieller Art. Geht man davon aus, dass der finanzielle Aufwand zur Studiendauer proportional ist, so genügt es, in erster Linie den Zeitaufwand zu betrachten. Es wird mit einem Normalaufwand von 900 Stunden pro Semester gerechnet. Bei einer Dauer von 6 Semestern kommt man damit auf ca. 5400 Stunden. Es wird nun festgelegt, dass nicht mehr als 10.000 Stunden (Randbedingung R2) und nicht weniger als 2.500 Stunden (R5) in das Studium investiert werden sollen. Zur Messung der Qualifikation wird die erzielte Gesamtnote verwendet, auch wenn dadurch bestimmte Aspekte, wie spezielles Curriculum, sonstige Studienleistungen oder studienfremde Leistungen nicht erfasst werden. Aufgrund der Notenskala kann die Gesamtnote nicht besser als 1,0 (Rl) und nicht schlechter als 4,0 sein (R4). Als weitere Randbedingung wird definiert, dass abhängig vom investierten Zeitaufwand eine bestimmte Mindestqualifikation erreicht sein muss (R3). Der Bereich im Zustandsraum, der nicht durch Randbedingungen ausgeschlossen ist, verbleibt als möglicher Zielraum. Durch die Formulierung eines Gütekriteriums J (gestrichelte Linie) kann der Zielbereich weiter unterteilt werden. Im dargestellten Beispiel nimmt die Gütefunktion Werte zwischen 1 (schlechtester Wert) und 10 (bester Wert) an. Zustandspunkte gleicher Güte sind durch Höhenlinien verbunden. Die fett dargestellte S-förmige Kurve schließlich zeigt einen typischen Verlauf: Zu Beginn wird Aufwand investiert, es stellt sich aber noch kein messbares Ergebnis ein. Im weiteren Verlauf sind dann immer mehr Fortschritte der Qualifikation feststellbar. Q

1,0 -I'--.L..--<:'-L."=-:--L--,L--"'--~..L--L..-L~'--...e.......,+

4,0

5.000

10.000 A [Std]

Bild 1-9 Zustandsraum des Problems "Studium"

Später werden die Fortschritte wieder geringer, da z. B. bei Wiederholungsklausuren nur noch geringe Verbesserungen erreicht werden, so dass mit mehr Aufwand zwar noch eine bessere Gesamtnote erzielbar ist, aber der Wert der Gütefunktion nicht mehr weiter ansteigt.

1.4 Projekte als Problemlösungsprozesse

21

1.4.2 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.

Beispiel1-9 Das Springer-Problem Wie viele Springer können auf einem Schachbrett untergebracht werden, ohne sich gegenseitig zu bedrohen, wie viele derartige Springer-Kombinationen gibt es und wie sehen sie aus? Die Frage ist nicht durch einfaches Rechnen zu lösen. Der typische Lösungsweg besteht aus Probieren und vielen Versuchen. Die scheinbare schwierige Lösung dieser Frage wird aber schlagartig offensichtlich, wenn man erkennt, dass ein Springer nur Felder der anderen Farbe seines Feldes bedroht. Setzt man Springer auf die 32 Felder gleicher Farbe, wird noch kein Springer bedroht. Es gibt auch keine weitere Platzierungsmöglichkeit mehr, da alle freien Felder bereits bedroht sind. Auf ein Schachbrett passen also genau 32 sich nicht bedrohende Springer. Eine derartige Lösung ist zwar typisch für ,,knifflige" Rätselaufgaben und 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 erfordern und dementsprechend auch Zeit in Anspruch nehmen. Ein solcher Vorgang wird als Prozess bezeichnet: 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 Befiillen 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, ü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. Jedes Projekt ist schwierig zu lösen. Thm liegt 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.

1 Projekte

22

Beispiell-lO 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? Die Bewegungsmöglichkeiten der Damen im Schachspiel sind auf den ersten Blick einfacher, als die der Springer. Damen können horizontal, vertikal und diagonal bewegt werden. Nach kurzem Nachdenken ist es offensichtlich, dass nicht mehr als 8 Damen auf ein Schachbrett passen. Die möglichen 8-Damen-Kombinationen und deren maximale Zahl sind dagegen nicht so einfach zu finden. Daher dauerte es auch 2 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 muss 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. 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: Routine /

Aufgaben:

Anfangs- in Zielzustand überführen

Innovation

'r : Probleme:

Routineprozesse:

mehrere Lösungsschritte aber unproblematisch

Schwierigkeit + Neuartigkeit

I I

r-------------------------~

I I I I I L I I I I I I I

"",'\

---------------------------------

Problemlösungsprozesse:

zeitlich + logisch gestaffelte Lösungsschritte --------------------------------

:~

Bild 1-10 Begriffliche Abgrenzung von Projekten

Projekte:

Beteiligung mehrerer Personen Begrenzeung von Ressourcen und Zeit

//

1.5 Projektmanagement

23

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. Tabelle 1.4 Kriterien für Aufgaben, Probleme, Problemlösungsprozesse und Projekte Kriterium

Aufgabe

Problem

PL-Prozess

Projekt

Zielklarheit

Ja

Ja

Ja

Ja

Einmaligkeit

Ja

Ja

Ja

Schwierigkeit

Ja

Ja

Ja

Ja

Ja

Prozesscharakter Terminierung

Ja

Teambildung

Ja

Ressourcenbegrenzung

Ja

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.5 Projektmanagement " Wichtige Grundsätze müssen biegsam sein. " (Abraham Lincoln)

1.5.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. 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 "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.

1 Projekte

24

Bild 1-11 Stetiger Arbeitsfluss

Im Gegensatz zum bloßen ,,Machen" benötigt ein Projekt eine klare Aufgabenstellung mit konkreter Zielformulierung, Randbedingungen, Gütekriterien und ein überprütbares 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.

~ Projekt ~ ~~ZS I ================:.---..~~~ Bild 1-12 Zeitlich und inhaltlich abgegrenztes Projekt

Ein Projekt muss aber nicht nur nach außen zeitlich und inhaltlich abgegrenzt werden. Auch intern besitzt es eine bestimmte Struktur. Obwohl natürlich jedes Projekt bei genauer Betrachtung sein individuelles Aussehen besitzt, kann man bei genügender Abstraktion eine gemeinsame Grundstruktur erkennen. Jedes Projekt ist ein Problemlösungsprozess mit einem Auftrag als Input und einem konkreten Ergebnis 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. 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.

1.5 Projektmanagement

25 Projekt

Ana-: Iyse

Entwurf

Realisierung

: Vali: dierung

Bild 1-13 Erste Unterteilung eines Projekts

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 fmden 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: 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: Projektmanagement ist die Planung und Steuerung der problemläsenden Prozesse von Projekten, um diese termingerecht und aufwandsminimierend zum Ziel zu führen. 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

1 Projekte

26

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 enthält die folgende Abbildung. In ihr wird nicht nur die logische Abfolge der einzelnen Aktivitäten gezeigt. Sie bringt auch die Verteilung des Aufwands über die Projekt-Laufzeit zum Ausdruck. 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. Tätigkeiten

Prj.-Durchführung Realisierung Prj.-Man.

P~.-Steuerung

Zeit

Bild 1-14 Weitergehende Projektunterteilung (Def.: Definition, Ab.: Abschluss)

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 teilweise sequentiellen, teilweise parallelisierbaren Arbeitsabläufen, die im Idealfall einmalig, im Realfall aber auch in Schleifen mehrfach durchlaufen werden können. Durch gestrichelte Linien wird in der Abbildung zum Ausdruck gebracht, 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:

Der Projektmanagement-Lebenszyldus 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.5 Projektmanagement

27

1.5.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 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 ([Reschke 1989], [Schelle 2004]) äußerten. 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 [Lomnitz 2008]. Außerdem gibt es eine Fokussierung auf die Anwendung des Projektmanagements in verschiedenen Anwendungsbereichen, wie der industriellen Forschung und Entwicklung [Platz 1986], dem Maschinen- und 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, um so 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 ein MultiprojektOrganisation geführt werden ("management by projects"). Mittlerweile gibt es eine kaum noch zu überblickende, stetig wachsende Zahl von Fach-, Handund 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 zunehmenden praktischen Anforderungen und vom Bestreben, beide 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.

28

1 Projekte

Angesichts der Stofffiille ist es natürlich für Anflinger im Bereich des Projektmanagements schwer, einen geeigneten Zugang zu der 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.5.3 Normen, Standards, ZertiflZierung 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 Vorteilliegt. Seit vielen Jahren gibt es daher Bestrebungen, durch eine Standardisierung und Normung für eine größere Transparenz zu sorgen. Verschiedene Organisationen und Interessenverbä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 (lCB) ist ein Standard der International Project Management Association (lPMA). In der aktuellen Version 3.0 aus dem Jahre 2009 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 (lPMA-Level D), über den zertifizierten Projektmanager (lPMA-Level C), den Senior Projekt Manager (IPMA-Level B) bis zum Projektdirektor (lPMA-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 2008 gültigen 4. Ausgabe des PMBOK sind 42 Prozesse definiert, die in 5 Gruppen gegliedert sind: lnitiierung, 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 (CAPI) 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 8 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

1.5 Projektmanagement

29

gehende "Practitioner Examination". Obwohl der PRINCE2-Standard 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 fiir 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. 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. Derzeit arbeitet das Technical Committe TC 236 der ISO an der internationalen Norm ISO 21500. Sie ist als eine Art internationale Dachnorm fiir die bestehenden Standards und nationalen Normen konzipiert und soll in den nächsten Jahren erscheinen. 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 Vorbereitung zur ZertiflZierung, sondern es soll dem Einsteiger in das Thema eine grundlegende und zugleich kompakte Einarbeitung ermöglichen. So weit dies vom Umfang her machbar war, wurden die Standards berücksichtigt, so dass sich viele Methoden, Prozesse und Phasen sowie Kompetenz- und Wissenselemente aus den Standards hier wieder fmden. 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.5.4 Fallbeispiele Ein praxisorientiertes Lehrbuch darf die beschriebenen grundlegenden Prinzipien und die 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 fiir 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 Mechanik, elektronischer Steuerungen und Software. Dabei gibt es sowohl Standardmaschinen, die in kleinen

30

1 Projekte

Serien mit unterschiedlichen Varianten produziert werden, als auch Sondermaschinen, die im Kundenauftrag neu entwickelt und aufgebaut werden [Jakoby 2006]. ~einbachwerke

GeschäftsführunL Vertrieb Zentrale Region 1

-

_~ion5

-~40o

I-l~L

-

60

Steinbach , Stefan I-

I - - I------

-

255

-

1---'-- -

--

Theisen, Marc

25 20 35 60 40 50 25

IElektronik-Fert~g

-

!~lrlEach, Thomas I-

Technik Konstruktion LElekl.ronikentwicklunq [SOjtwareentwicklunq Mechanik-Produktion iMontage Service Betriebswirtschaft fKaufm Abteilunq 1Personalbateiluna IBetriebsabteilung IT-Abteilung I~_~ Einkauf

-

Leiter

75

Steinbach , Karola 20 110 15 10 110 10

Wulff -

Bild 1-15 Organigramm des Beispiel-Unternehmens mit Bereichen und Abteilungen

Mit seinen 400 Beschäftigten generiert das Unternehmen einen jährlichen Umsatz von 100 Millionen Euro. 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. Beispiell-11 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, Grafikbildschirm 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.

1.6 Repetitorium

31

Beispiell-12 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. Beispiel1-13 Fallbeispiel "Dokumenten-Managementsystem (DMS)" Alle Unterlagen aus den verschiedenen Abteilungen der Steinbachwerke werden bislang in elektronischer Form auf zentralen Netzlaufwerken abgelegt und auch regelmäßig gesichert. Hierzu gehören z. B. Angebote, Produktbeschreibungen, Handbücher, Betriebsanleitungen und Fertigungsunterlagen. Der Austausch von Dokumenten zwischen verschiedenen Abteilungen erfolgt über Laufwerke mit gemeinsamem Zugriff. Immer wieder kommt es dabei zu Problemen, z. B. bei der Freigabe der Dokumente für andere Abteilungen, beim Umgang mit Dokumenten, die nicht in elektronischer Form vorliegen, bei der Dokumentenversionierung und beim Suchen nach vergessenen oder falsch abgelegten Dokumenten. Aus diesem Grund hat die Geschäftsleitung beschlossen, die Dokumentenablage, -versionierung, -verteilung und den Dokumentenzugriff im gesamten Unternehmen einheitlich zu handhaben. Aus diesem Grund soll im Rahmen eines Organisationsprojektes die Dokumentenhandhabung vereinheitlicht, ein Dokumentenmanagementsystem angeschafft und in allen Abteilungen eingeführt werden. Beispiel1-14 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 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.

1.6 Repetitorium 1.6.1 Checklisten Die für das Projektmanagement erforderlichen Aktivitäten werden in diesem am Ende jedes Kapitels in Form von Checklisten kompakt zusammengefasst. Die Checklisten sind hierarchisch gegliedert. Die folgende oberste Checkliste komprimiert die wichtigsten Aktivitäten des gesamten Projektmanagements in 7 einfachen Fragen. In sehr einfachen Projekten kann es genügen nur diese Fragen zu beantworten und die Antworten als ProjektdefInition (Siehe Formblatt im Anhang) schriftlich festzuhalten. In allen anderen Projekten wird zu jeder Frage in eine oder mehrere vertiefende Checkliste benötigt. Sie fIndet

1 Projekte

32

sich am Ende des jeweiligen Kapitels. Zusammengenommen bilden sie eine große, hierarchisch gegliederte Checkliste, die den gesamten Ablauf des Projektmanagements umfasst. Tabelle 1.5 Checkliste Projektmanagement Frage

Vertiefung in Checkliste

Kapitel

1.

Was ist das Problem?

Problemlösen + Projektgründung

2.5.1 +3.4.1

2.

Was muss getan werden?

Strukturplanung

5.3.1

3.

Wie viel Aufwand ist erforderlich?

Aufwandsschätzung

6.5.1

4.

Wer soll es tun?

Projektorganisation

4.5.1

5.

Wann soll es getan werden?

Ablauf- und Terminplanung

7.5.1

6.

Wo sind die Risiken?

Risikornanagernent

8.3.1

7.

Läuft es nach Plan?

Projektsteuerung + -abschluss

9.4.1

1.6.2 Verständnisfragen 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

Worin unterscheiden sich Projekte von Nicht-Projekten? Nach welchen Kriterien würden Sie Projekte unterteilen? Beschreiben Sie die externe und die interne Sicht eines Systems! Worin unterscheiden sich Systeme und Nicht-Systeme? Nennen Sie Beispiele für Systeme, die im Zusammenhang mit Projekten auftreten können! Aus welchen Komponenten setzt sich ein Projekt aus systemtechnischer Sicht zusammen? Was ist ein Prozess? Worin unterscheiden sich Aufgaben, Probleme, Problemlösungsprozesse und Projekte? Wie würden Sie Management definieren? Was versteht man unter Projektmanagement? Was unterscheidet gemanagte Projekte von nicht gemanagten Projekten? In welche 8 Gruppen kann man die Tätigkeiten in einem Projekt einteilen? Machen Sie eine grobe Aussage über den Aufwandsanteil der Tätigkeitsgruppen in einem Projekt! Kann es Ein-Personen-Projekte geben? Begründen Sie Ihre Ansicht! Was beschreibt der Projektmanagement-Lebenszyklus?

1.6 Repetitorium

33

1.6.3 Übungsaufgaben Aufgabe 1-1 Projekte und Nicht-Projekte Erstellen Sie eine Liste mit größeren Vorhaben, an denen Sie beteiligt waren: 3 Vorhaben, die sicher keine Projekte sind, 3 Vorhaben, bei denen sie nicht sicher sind, ob es Projekte sind, 3 Vorhaben, die sicher Projekte sind. Erweitern Sie die Liste mit 6 großen Projekten, an denen Sie nicht unbedingt beteiligt waren, von denen Sie aber gehört oder gelesen haben. Aufgabe 1-2 Aufgaben Erstellen Sie eine Liste mit Aufgaben, an denen Sie beteiligt waren oder sind: 3 Problemlösungsprozesse, die keine Projekte sind, 3 Routineprozesse, 3 Probleme, deren Lösung keine Prozesse erfordern, 3 unproblematische Aufgaben, deren Lösung keinen Prozesscharakter besitzen. Aufgabe 1-3 Ungemanagte Projekte Waren Sie schon einmal an einem größeren Projekt beteiligt, das ohne explizites Projektmanagement durchgeführt wurde? Wie ist es gelaufen? Aufgabe 1-4 Projekteigenschaften Legen Sie 7 Kriterien (A-G) fest, die sich eignen, um zu beurteilen, ob die aufgeführten Vorhaben Projektcharakter besitzt. Überprüfen Sie, ob bzw. in welchem Maße die folgenden Vorhaben nach diesen Kriterien Projekteigenschaften besitzen. Projekt Neubau einer Produktionshalle Ausrichten einer Hochzeit Aufführung eines Theaterstücks Organisation eines lO-jährigen Firmenjubiläums Betrieb eines Windparks Durchführung eines Studiums Umorganisation des Bestellwesens Aufbau einer Web-Präsenz für einen Buchhändler Anfertigen einer Produkt-CD

A

B

C

D

E

F

G

34

1 Projekte

Aufgabe 1-5 Projektklassifikation Versuchen Sie, die Fallbeispiele dieses Buches anhand der Kriterien Größe, Projektgegenstand und Projektart zu klassifizieren!

Aufgabe 1-6 Aufgaben, Probleme, Prozesse, Projekte Untersuchen Sie, bei welchen der folgenden Vorhaben es sich um Aufgaben und bei welchen es sich um Probleme handelt. Bei welchen Vorhaben ist die Durchführung ein Prozess und bei welchen handelt es sich um ein Projekt? 1. Erlernen einer Fremdsprache. 2. Eine mathematische Gleichung 4. Grades lösen. 3. Bestimmung von Höhe und Durchmesser eines zylindrischen Körpers mit vorgegebenem Volumen (z. B. 1 Liter) und minimaler Oberfläche. 4. Aufbau eines Billy-Regals. 5. Die Fahrstrecke minimaler Länge für die Auslieferung von 10 Paketen an 10 verschiedenen Orten ermitteln. 6. Die hinsichtlich Fahrstrecke, Fahrzeit und Energieverbrauch optimierte Strecke für die Auslieferung von 10 Paketen an 10 verschiedenen Orten ermitteln. 7. Ein Programm schreiben, mit dem die optimale Route für die Auslieferung von beliebig vielen Paketen an verschiedenen Orten berechnet werden kann. Schätzen Sie bei jedem Vorhaben den Schwierigkeitsgrad und den Zeitaufwand!

2 Problendösen " Probleme sind getarnte Gelegenheiten." (aus Ungarn)

Jedem Projekt liegt ein Problem zugrunde. Die Durchführung eines Projekts ist daher ein Problemlösungsprozess. Aber es gibt nicht nur ein großes, dominierendes Problem, das mit Hilfe des Projekts gelöst werden soll, sondern im Laufe eines Projekts treten auch unendlich viele kleinere Probleme auf. Für die Planung und Durchführung von Projekten ist es daher unerlässlich, Prinzipien und Methoden des Problemlösens anwenden zu können. Deshalb werden in diesem Kapitel Struktur und Ablauf eines systematischen Problemlösungsprozesses erläutert. Jeden Tag sind wir mit kleinen, manchmal auch mit großen Problemen konfrontiert und sie begegnen uns in jedem Realitätsbereich, seien es technische, soziale, psychische, finanzielle oder organisatorische Probleme. Ständig sind wir damit beschäftigt, Probleme zu lösen. Und wenn sich einmal keine Probleme von selbst auftun, haben wir Langeweile und suchen uns knifflige Denksportaufgaben. Für den Philosophen Karl Popper ist sogar alles Denken Problemlösen. Aufgrund der großen Vielfalt der Problem-Erscheinungsformen, muss man sich schon auf einen Teilbereich beschränken oder sehr stark abstrahieren, um eine akzeptable Defmition des Problembegriffs zu finden. Jedes konkrete Problem ist anders und daher ist auch jede konkrete Problemlösung anders. Das heißt aber noch lange nicht, dass es keine Erkenntnisse gäbe, die man von einer Problemlösung auf eine andere übertragen könnte. Zum einen gibt es oft Lösungsmuster, die für eine ganze Klasse von Problemen geeignet sind. Es handelt sich hierbei um Heuristiken oder um Algorithmen. Wie anders als durch Handlungsmuster, die er aus vielen ähnlichen Situationen verallgemeinert hat, wäre der Mensch z. B. in der Lage, jeden Tag im Straßenverkehr neue problematische Situationen mit geringem Denkaufwand zu meistem. Zum anderen findet man bei ausreichender Abstraktion in jeder Erarbeitung einer Problemlösung gleichartige Arbeitsabläufe. Diese kann man zum Aufbau eines allgemeingültigen Problemlösungsprozesses verwenden. Dieser Problemlösungsprozess besteht aus drei Planungs- und zwei Ausführungsphasen. Die Planung setzt sich aus der der Problemanalyse, der Lösungssynthese und der Lösungsauswahl zusammen. Daran schließen sich die Realisierung der Lösung und deren Validierung an. Jede dieser Phasen kann noch einmal in mehrere Schritte unterteilt werden. Die Analyse eines Problems beginnt mit der Problemerkennung, setzt mit dessen Strukturierung fort und endet mit der Formulierung. Beim Durchlaufen dieser Phasen wird das Verständnis des Problems von einer ungefähren, "wolkigen" Vorstellung schrittweise immer weiter konkretisiert und präzisiert. Am Ende sollte eine vollständige und präzise Formulierung des Problems stehen. In der nächsten Phase, der Lösungssynthese geht es darum, Ideen für eine mögliche Lösung des Problems zu suchen, geeignet erscheinende Ideen zu selektieren und diese dann detailliert auszuarbeiten. Am Ende dieser Phase sollte es mehrere mögliche Lösungen für das Problem geben. Diese werden dann in der dritten Phase bewertet und schließlich wird die beste bzw. erfolgversprechendste ausgewählt. Nicht immer gestaltet sich der Ablauf so schön linear, wie es die Beschreibung nahe legt. In jeder Phase kann es zu Störungen kommen, so dass man nicht weiter kommt. Dann wird es notwendig, die vorangehende Phase erneut zu durchlaufen. So kann man z. B. nach einer erfolglos verlaufenen Lösungssuche noch einmal zur Problemanalyse zurückgehen, um dort

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6_2, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

36

2 Problemlösen

unnötig einschränkende Bedingungen zu eliminieren oder vorher nicht erkannte Freiheitsgrade zu finden. Daher schließt sich an jede Phase eine Verzweigung an. Ist eine Phase erfolgreich abgeschlossen, geht es zur nächsten. Ist das nicht der Fall, findet ein Rücksprung statt.

•

Problemanalyse

Problemerkennung Problemstrukturierung

•

Zielformulierung Lösungssuche

Ideenfindung Ideenselektion

• • •

Ideenausarbeitung Lösungsauswahl Bewertung

Entscheidung Realisierung

Validierung

+

Bild 2-1 Die 5 Schritte des Problemlösungsprozesses

Nach der endgültigen Entscheidung für eine bestimmte Lösung ist der Planungsteil des Problemlösungsprozesses abgeschlossen. Die Lösung kann nun realisiert werden. An die Realisierung sollte sich schließlich noch eine Validierung anschließen. Hier ist zu überprüfen, ob das ursprüngliche Problem tatsächlich gelöst wurde. Darüber hinaus kann in der Validierung auch der Lösungsprozess rückblickend analysiert und bewertet werden: Welche Fehler wurden gemacht? Welche Erfahrungen wurden gewonnen? Wie können sie für folgende Problembearbeitungen genutzt werden? Der beschriebene Prozess weist große Gemeinsamkeiten mit dem IDEAL-Problem-Solver auf [Branford 1993]. Dieser besteht ebenfalls aus 5 Schritten. Sie werden als Identify, Define&Represent, Explore, Act und Lookback bezeichnet und können ohne Mühe den oben beschriebenen Phasen zugeordnet werden. Auch die REFA-Planungssysternatik, die zur Ausarbeitung von Problemlösungen dient, ist ähnlich strukturiert [REFA]. Diese Systematik umfasst 6 Stufen: Ausgangssituation analysieren, Ziele festlegen, Lösungskonzept erarbeiten, Lösung detaillieren, Lösung einführen und Lösung einsetzen.

2.1 Problemanalyse

37

2.1 Problemanalyse "Dem weht kein rechter Wind, der keinen Hafen hat, nach dem er segelt. " (M. de Montaigne)

2.1.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. Nicht immer sind die Probleme so offensichtlich und klar, wie bei Rätsel und Denksportaufgaben. Reale Probleme sind selten explizit formuliert. Sie ä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 besteht darin zu 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 Informationen können sich später doch als wichtig herausstellen oder sie bilden den Auslöser für die Suche nach weiteren Informationen. Das Suchen nach Informationen zu einem Sachverhalt, von dem noch wenige Kenntnisse vorliegen ist natürlich ein kreativer und teilweise unsystematischer Vorgang. Damit der Erfolg aber nicht vollkommen dem Zufall überlassen wird, ist es notwendig, eine gewisse Struktur in die Suche zu bringen. Am besten gelingt dies, durch das Stellen vieler geeigneter Fragen. Der Minimalumfang eines Fragenkatalogs zur Erfassung eines Problems besteht aus 4 Was-Fragen. Sie richten sich auf die wichtigsten Informationen zu einem Problem: auf Anfangs- und Zielzustand, auf die Operatoren und die Barriere. Sie stellen daher den idealen Einstieg in die Problernerkennung dar. Bei einfachen Problemen können sie sogar schon ausreichend sein. Tabelle 2.1 4 Was-Fragen zur Problemerkennung

Frage

Altemativfragen

Was

ist gegeben?

Wo stehe ich?

Was

ist gesucht?

Was ist mein Anfangszustand? Wo will ich hin? Was ist mein Zielzustand? Was

kann ich tun?

Welche Handlungsmöglichkeiten habe ich? Welche Operatoren gibt es?

Was

hindert mich daran?

Woraus besteht die Barriere? Was ist die "Problematik"? Was könnte schief gehen?

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

38

2 Problemlösen

sich auf den Gegenstand, die Ursache und Erscheinungsfonn des Problems richten. Neue 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. Tabelle 2.2 6 W-Fragenkatalog zur Problemerkennung Problem

Nicht-Problem

Lösung

Wer

meldet das Problem? ist betroffen vom Problem?

ist nicht betroffen vom Problem?

könnte die Lösung ebenfalls gebrauchen?

Wo

tritt das Problem auf?

tritt das Problem nicht auf?

könnte die Lösung ebenfalls eingesetzt werden?

Wann

tritt das Problem auf?

tritt das Problem nicht auf?

sollte die Lösung vorhanden sein?

Was

ist das Problem?

ist nicht das Problem?

sollte die Lösung unbedingt können?

Wie

zeigt sich das Problem?

läuft: es normalerweise?

sollte die Lösung aussehen?

Warum

ist es ein Problem?

ist es fiir andere kein Problem?

wird die Lösung gebraucht?

Es existieren etliche Vorschläge und Bezeichnungen für derartige 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 Infonnationssammlung 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. Beispiel 2-1 Sporadische Ausfälle der Steuerung eines Manipulators

Bei einem Hersteller von Manipulatoren wurden immer wieder sporadische, kurzzeitige Störungen des Steuerungsrechners gemeldet. Die Manipulatoren dienen zur automatischen Aufnahme, Bewegung und Positionierung von Objekten. Untersuchungen der Service-Abteilung beim Kunden brachten keine Erkenntnisse. Auch der Austausch einzelner Baugruppen des Rechners und deren Untersuchung ergaben keinen Aufschluss über die mögliche Fehlerursache. Die Tests wurden im Labor unter verschiedenen Bedingungen auch über längere Zeiträume durchgeführt. Dabei konnte kein Fehler beobachtet werden. Da es bei manchen Kunden aber weiterhin zu Störungen des Rechners kam, wurden die Störungsmeldungen systematisch erfasst und ausgewertet. Die folgende Aufstellung fasst die Ergebnisse in verkürzter Fonn zusammen: Wer

Das Problem trat bei manchen Kunden auf, bei anderen nicht. Es konnte keine Systematik erkannt werden.

Wo

Die Manipulatoren wurden in unterschiedlichen Umgebungen eingesetzt. Eine Abhängigkeit der aufgetretenen Fälle von den Umgebungstemperaturen, von der Staubbelastung, von der Feuchtigkeit oder elektromagnetischer Umgebung

2.1 Problemanalyse

39

war nicht feststellbar. Die Manipulatoren wurden sowohl ortsfest als auch auf Fahrzeugen eingesetzt. Beim mobilen Einsatz traten die Fehler auffällig oft auf, beim ortsfesten Einsatz dagegen selten oder gar nicht. Wann

Die Störungen traten zu beliebigen Ubrzeiten und in verschiedenen Betriebszuständen auf. Eine zeitliche oder logische Systematik war nicht erkennbar.

Was

Das Problem waren Störungen im Betrieb des Manipulators. Diese entstanden durch Fehler der Steuerung. Alle Hardware-Baugruppen wurden einzeln ausgetauscht. Fehler der Baugruppen konnten nicht festgestellt werden. Auch nach Einsatz neuer Baugruppen traten immer wieder Fehler auf, so dass der Verdacht eines Software-Fehlers begründet erschien.

Wie

Die Störungen traten sporadisch und kurzzeitig auf. Sie äußerten sich sehr unterschiedlich: in einfachen Fällen z. B. durch das kurzzeitige "Dunkel"-Werden der Anzeige oder durch kurzzeitigen Ausfall des Datenverkehrs, in schweren Fällen durch einen Rechner-Absturz und anschließendem Neu-Start.

Warum

Nach dem Absturz des Steuerungsrechners und dem Neu-Start blieben die Manipulatoren stehen. Auch wenn es noch zu keinen Sachschäden oder gar Personenschäden gekommen war, litt das Vertrauen der Bediener in die Sicherheit des Systems.

Die geschilderte Problemerkennung ergab als einzige, signifIkante Auffälligkeit das stark gehäufte Auftreten der Fehler beim mobilen Einsatz des Manipulators, während die ortsfesten Manipulatoren offensichtlich störungsfrei arbeiteten. Da die Hardware und die Software des Steuerungsrechners überall gleich waren, wurde nach einer Besonderheit des mobilen Einsatzes gesucht. Diese wurde schließlich in den auftretenden mechanischen Erschütterungen während des mobilen Betriebs gefunden. Systematische Rütteltests führten schließlich zur Ursache des Problems. Die elektronischen Bausteine zur Speicherung der Software auf der CPU-Baugruppe waren gesockelt, damit diese jederzeit leicht gewechselt werden konnten. Bei einigen Baugruppen wiesen die Sockel Haarrisse auf, wodurch die Anpresskraft für die Kontakte zwar noch ausreichend, aber deutlich verringert war. Durch stärkere Erschütterungen konnte es zu Wackelkontakten beim Lesen aus den Speicherbausteinen und damit zu SoftwareFehlern kommen. Nachdem die Sockel entfernt und die Speicherbausteine fest eingelötet wurden, traten die Fehler nicht mehr auf. 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 oder der Zeitbedarf 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. In dieser Interpretation zeigt die dargestellte Tabelle symbolhaft einige typische Fehlersituationen der Problemerkennung. Besonders gravierend sind die Fälle, in denen ein real existierendes Problem gar nicht gesehen wird. Unergiebig, manchmal sogar skurril sind die Fälle, in denen Probleme gesehen werden, wo es gar keine gibt. Neben diesen Extremfällen sind aber auch Fehler zu beachten, bei denen das Problem unklar ist bzw. über- oder unterschätzt wird.

40

2 Problemlösen

Tabelle 2.3 Typische Fehlersituationen bei der Problemerkennung Problem wird nicht ~esehen

Es gibt kein Problem

•

0 ~

Problem

Problemsicht unklar

Problemsicht

0::

Problem überschätzt

•

Problem unterschätzt

Idealfall

111

•

~

2.1.2 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 entlang eines Fragenkatalogs sinnvoll. Den Ausgangspunkt bildet die Frage nach dem Problemgegenstand, also dem System, das gemäß der Defmition 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 den Problemlöser nicht beeinflusst werden. Als nächstes werden die Größen gesucht, die sich im System verändern können. Sie legen das Verhalten des Systems fest und können durch den Problemlöser 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 UrsacheWirkungs-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 [Schulte-Zurhausen 2002]. 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 HauptUrsachen z. B. durch die 4-M-Metbode gekennzeichnet: Mensch, Maschine, Material, Metbo-

2.1 Problemanalyse

41

deo Bei der 7-M-Methode kommen ergänzend Milieu (Umgebung), Management und Money (Kosten) hinzu. Berufsaussicht Zukunftssicher Gehalt Jobchance

Hochschule Renomme Professoren Labore Studienplatzwahl

Freizeitangebot Heimatnähe Studienort

Interesse Schulleistungen Fachgebiet

Bild 2-2 Ishikawa-Diagramm der Einflussfaktoren fiir die Wahl eines Studienplatzes

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 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, B-Faktoren mittlere und C-Faktoren geringe Bedeutung. Die Definition der Bedeutung und die Grenzziehung zwischen den drei Klassen ist natürlich subjektiv, dafür aber mit geringem Aufwand machbar. Transparenter sind quantitative Klassifizierungsverfahren. Hierbei muss Bedeutung jedes Einflussfaktors durch einen Zahlenwert ausgedrückt werden.

42

2 Problem1ösen

Dies gelingt in vielen Fällen recht gut, z. B. durch statistische Methoden oder durch Befragung und Punktvergabe innerhalb einer Bewertungsgruppe, kann aber manchmal auch problematisch sein. Liegt eine numerische Bewertung der Faktoren vor, lässt sich die Klassifizierung z. B. durch eine Pareto-Analyse vornehmen. Diese basiert auf der Beobachtung, dass bei vielen Sachverhalten die Unterschiede zwischen den verschiedenen Einflussfaktoren beträchtlich sein können. Oft gibt es einige wenige Faktoren, die eine Größe ganz wesentlich beeinflussen, während es viele andere Faktoren mit nur geringem Einfluss gibt. Dies ist das nach seinem Entdecker benannte Pareto-Prinzip, das in einer leicht eingängigen Form auch als 80/20-Regel bekannt ist: 80 % der Wirkung wird durch 20 % des Aufwands erzeugt [Koch 2004]. Die Gültigkeit des Pareto-Prinzips in seiner allgemeingültigen Form kann in sehr unterschiedlichen Realitätsbereichen bestätigt werden: 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.

Beispiel1-1 Pareto-Analyse der Welt-Bevölkerungsstatistik Auf der Erde gibt es ca. 200 Staaten. Die Bevölkerungszahlen der Staaten sind sehr unterschiedlich: In China leben 1,3 Mrd. Menschen; im Vatikanstaat knapp 1000. Sortiert man die Staaten nach der Bevölkerungszahl, addiert diese auf und rechnet den Prozentwert der Summe aus, erhält man die dargestellten Ergebnisse: land Erde 1 China 2 Indien 3 USA 4 Indonesien 5 Brasilien 6 Pakistan '---'--

"

Bevölkerung Summe Prozen 6.829.360.000 1.353.311.000 1.353.311.000 19,8% 1.198.003.000 2551.314.000 37,4% 2.865.973.00gj 42,~ 3ill5.9.0001 229.965.000 1 3.095.938.000 45,3% 193.734.000 3.289.672.000 48,2% 180.808.000, 3.470.480.000 50,8%

3D Tansania 31 Sudan

43.739.000 42.272000 40.276.000 39.802000 38.074000 34.895.000

~entinien

~ Kenia

34 Polen 35 Alqerien

88 89 90 91

Schweden Somalia Benin Aserbaidschan

f--

9.249.000 9.133.000 8.935.000 8.832.000

5.388.161.000 5.430.433.000 5.470709.000 5510.511000 5.548.585.000 5.583.480.000

78,9%1 79,5% 80,1% 80,7% 81,2% 81,8%

6.542.361ooQ. 6.551.494000 6.560.429000 96,1% 6.569.261.000 96,2%

~:~~

Bild 1-3 Weltweite Bevölkenmgsstatistik nach Staaten

In den 6 größten Staaten der Erde leben über 50 % der Weltbevölkerung. Die 32 größten Staaten (16 % von 200) machen 80 % und die 90 größten (45 %) machen 96 % der Weltbevölkerung aus. Die Welt-Bevölkerungsstatistik ist also eine recht gute Bestätigung des Pareto-Prinzips.

2.2 Erstellung eines Zielsystems

43

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-Faktoren, die nächsten 16 % sind B-Faktoren und die restlichen 4 % - oft ist dies die größte Gruppe - sind CFaktoren. Das Idealziel der Problemstrukturierung, das allerdings nur selten erreicht wird, 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.2 Erstellung eines Zielsystems "Nachdem wir das Ziel aus den Augen verloren hatten, verdoppelten wir unsere Anstrengungen ". (Mark Twain)

2.2.1 Von der Zielwolke zum Zielsystem Auch wenn die verschiedenen Schritte der Problemerkennung und der Problemstrukturierung schon viele Erkenntnisse über das Problem zu Tage gefördert haben, darf der gesamte Prozess der Problemanalyse erst als abgeschlossen betrachtet werden, wenn das Problem explizit formuliert wurde. Oft werden bei komplexen Problemstellungen erst durch die schriftliche Formulierung Lücken und Widersprüche aufgedeckt, die trotz gründlicher Analyse bestehen geblieben sind. Zur Formulierung können textliche, tabellarische und graphische Mittel genutzt werden. Neben der schriftlichen Fixierung der Ergebnisse ist die Zielbeschreibung die wichtigste Aufgabe der Problemformulierung. Zielorientiertes Handeln in allen Lebensbereichen ist heute so selbstverständlich geworden, dass es eigentlich verwundert, dass die Zielorientierung noch immer als ausdrückliche Anforderung in Leitbildern, Stellenanzeigen oder Projektbeschreibungen auftaucht. Ein Grund hierfür ist wohl in der Diskrepanz zwischen Wunsch und Wirklichkeit zu suchen. Wohl jedem ist klar, dass ein Vorhaben nur dann zum Erfolg geführt werden kann, wenn die Ziele auch bekannt sind. Aber wie oft taucht mangelnde Zielorientierung als Ursache für gescheiterte Projekte, für Misserfolge oder für Unternehmenspleiten auf. Wie kann es dazu kommen?

44

2 Problemlösen

Die gravierendste Fehleinschätzung ist wohl das Fehlen eines Ziels! Die an einem Vorhaben beteiligten Personen glauben zwar das Ziel zu kennen oder wenn sie es selbst nicht kennen, dass die anderen Beteiligten, die Auftraggeber oder wenigstens die Verantwortlichen die Ziele kennen. Das heißt aber lange noch nicht, dass es tatsächlich ein Ziel gibt, dass dieses Ziel klar ist und dass es allen klar ist. Genau so fatal ist es, wenn es zu viele Ziele gibt. Bei mehreren Zielen gibt es zwangsläufig Konflikte. Die vollständige Erreichung des einen Ziels geht zu Lasten eines anderen. Hier muss eine Klärung der Prioritäten bzw. der Gewichtung erfolgen. Zielsetzung und Zielklarheit sind somit eine notwendige Voraussetzung, wenn ein Vorhaben gelingen soll. Die Zielfindung ist dann erfolgreich, wenn sie zu Beginn eines Vorhabens in mehreren systematisch aufgebauten Schritten von verschwommenen Vorstellungen zu klar formulierten Zielen führt. Dieser Prozess gelingt nur selten auf Anhieb. Er braucht Zeit, Geduld und oft mehrere Durchgänge. Zu Beginn des Zielfindungsprozesses ist die Unklarheit am größten. 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". 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.

........

I /

I

Träume

Visionen

/

,,

/

\

Werte

I I

,/

/

I

, Wünsche \

\

\

Anforderungen

\ \

I I I I

Gefühle / I I

I \ \

Mängel

........

=>

,

Erwartungen

I I I

.........

\

/

Zielsystem Teilziel

Variable

Kriterium

""

Bild 2-4 Erstellung eines Zielsystems

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 eines Siebes kombiniert werden. Am Ende der Zielformulierung sollte ein abgegrenztes Zielsystem mit konkreten Kriterien und überprüfbaren Variablen stehen.

2.2 Erstellung eines Zielsystems

45

Für die Zielfindung können zwei gegensätzliche Perspektiven hilfreich sein: die Formulierung eines Idealziels und die Zieleinbettung. 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 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 Ziele 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 fiir 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. Bei der Formulierung von Zielen sollte darauf geachtet werden, dass sie lösungsneutral erfolgt. Sie sollte also nicht schon mögliche Lösungen enthalten, da dies oft andere, bessere Lösungen blockiert.

2.2.2 Zielvariablen und Zielkriterien Nur in sehr einfachen Problemstellungen wird es möglich sein, ein einziges elementares Ziel zu formulieren. Typische Beispiele hierfiir sind Aufgaben, in denen es exakt eine Lösung gibt und genau diese gesucht wird, ohne dabei auf Bedingungen, wie z. B. Zeitbedarf zu achten. Das Acht-Damen-Problem (Wie viele Möglichkeiten gibt es, 8 Damen auf einem Schachbrett zu platzieren, so dass sie sich gegenseitig nicht schlagen können?), das Sieben-Euro-ElfProblem (Welche vier Produktpreise ergeben als Summe und als Produkt den Wert 7,11 €?) oder das Problem des Handlungsreisenden (Welches ist die optimale Route, um alle europäischen Hauptstädte zu bereisen?) sind typische Beispiele. In realen Problemstellungen mit vielfältigen praktischen Anforderungen und Einschränkungen setzt sich das Ziel aus mehreren Komponenten zusammen, die sich teilweise ergänzen, aber auch widersprechen können. So ist es z. B. bei der Entwicklung eines neuen Produkts selbstverständlich, dass es neben einer ganzen Reihe funktionaler Anforderungen auch terminliche Vorgaben sowie Beschränkungen des Personal- und des Ressourceneinsatzes gibt. Ein Ziel setzt sich also im Allgemeinen aus verschiedenen Bestandteilen - man kann sie auch Teilziele nennen - zusammen.

Beispie12-3 Entwicklung eines fahrradtauglichen Navigationsgeräts (Teil I) In einem Projekt zur Entwicklung eines neuen Navigationsgeräts fiir den Einsatz auf Fahrrädern hat der Geschäftsführer den Entwicklungsleiter und die Vertriebsbeauftragten zu einer Vorbesprechung eingeladen. Neben den wirtschaftlichen Vorstellungen der Ge-

46

2 Problemlösen schäftsleitung, mit dem neuen Gerät einen möglichst hohen Markanteil und einen hohen Deckungsbeitrag zu erzielen, gibt es funktionale Anforderungen des Vertriebs, z. B. hinsichtlich Display-Größe, Bauform, Akku-Laufzeit, Wetterfestigkeit und Ergonomie der Benutzerschnittstelle. Außerdem sollte die Entwicklungszeit möglichst kurz und das Projektbudget strikt begrenzt sein. Schließlich werden folgende Ziele formuliert: 1. Marktführerschaft bei fahrradtauglichen Navigationsgeräten. 2. Möglichst kompakt bauendes Gerät bei ausreichend großem Display. 3. Robuste Bauform. 4. Ergonomische Benutzerschnittstelle. 5. Erreichung der Marktreife bis Jahresende. 6. Strikte Limitierung des Budgets. 7. Niedrige Gerätekosten. Erleichtert, diese erste, schwierige Hürde im Projekt überwunden zu haben, beendet der Geschäftsführer die Besprechung.

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 gute Basis für notwendige Entscheidungen. Damit Ziele nicht nur gut klingen, sondern operationalisierbar sind, d. h. sich für die Auswahl konkreter Handlungen im Laufe des Projekts eignen, muss die Zielformulierung einige Anforderungen erfüllen. 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 ist 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 -lODe und +4o o e eingrenzt. Aus diesen einfachen Beispielen wird klar, dass jedes Teilziel für sich spezifisch formuliert und messbar gemacht werden muss. Am ehesten gelingt dies, wenn jedes Teilziel durch eine Zielvariable ausgedrückt wird. Das Einhalten eines bestimmten Wertebereichs oder das Erreichen eines optimalen Wertes können dann das als Kriterium zur Überprüfung der Zielerreichung verwendet werden. Beispiel2-4 Entwicklung eines fahrradtauglichen Navigationsgeräts (Teil 2) Aufgrund seiner Erfahrungen mit ähnlichen Besprechungen zu Beginn anderer Projekte ist der Entwicklungsleiter bei weitem nicht so zufrieden mit der Zielformulierung wie sein Geschäftsführer. Da die Teilziele so gut wie gar nicht operationalisierbar sind, versucht er die Teilziele zu spezifizieren und messbar zu machen, um sie dann in seinem Projekt als Vorgaben zu verwenden.

47

2.2 Erstellung eines Zielsystems

Die ursprünglichen Ziele musste der Entwicklungsleiter teilweise auftrennen, um sie messbar zu machen und geeignet auf Zielvariablen abbilden zu können. So hat er z. B. das doch recht abstrakte Ziel "Ergonomie" auf zwei Variablen abgebildet: die bei einem durchschnittlichen Benutzer erforderliche Einarbeitungszeit bei der erstmaligen Benutzung des Geräts und die bei einem eingearbeiteten Benutzer benötigte Zeit zum Aufrufen einer beliebigen Funktion. Auch die anderen Ziele hat er auf messbare Variable abgebildet und auf deren Wertebereichen geeignete Kriterien definiert. Tabelle 2.4 Zielsystem des Fahrrad-Navigationsgeräts Teilziel

(Überprüfbare) Variable

Kriterium

Marktfiihrerschaft

Marktanteil

Mind.30%

Kompakte Bauform

Gehäusevolumen

Möglichst gering

Großes Display

Display-Diagonale

Zwischen 10 cm und 12 cm

Robuste Bauform

IP-Schutzart

IP 54

Ergonomie

(Erstmalige) Einarbeitungszeit

Max. 30 Min.

Ergonomie

Funktionszugriffszeit

Max. 5 Sekunden

Schnelle Marktreife

Time-to-market

Max. 8 Monate

Niedriger Geräte-Preis

Herstellkosten

Möglichst gering

Niedrige Entw.-Kosten

Projektbudget

Max. 250 Tsd. €

Allerdings stellt sich der Entwicklungsleiter nun die Frage, ob alle diese Ziele gemeinsam erreichbar sind. Insbesondere hat er Bedenken, ob in der kurzen Entwicklungszeit alle gewünschten Funktionen realisierbar sind. Er wendet sich deshalb noch einmal an die Geschäftsleitung und den Vertrieb, um Aussagen über die Prioritäten der Teilziele zu bekommen und darüber, welche Teilziele unbedingt erreicht werden müssen und auf welche Teilziele gegebenenfalls verzichtet werden kann. Leider erhält er darauf die lapidare Auskunft, dass alle Teilziele sehr wichtig und unverzichtbar sind. Durch das Formulieren von Teilzielen, von Zielvariablen mit geeigneten Messbereichen und einzuhaltenden Bedingungen sind die beiden wichtigsten Anforderungen an eine Zielformulierung sichergestellt, nämlich Ziele spezifisch und messbar zu machen. Daneben gibt es einige weitere Anforderungen. Aus psychologischen Gründen sollten Ziele immer positiv und attraktiv 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. Bei der Entwicklung eines neuen PKW ist der Kraftstoffverbrauch sicher eine nahe liegende und gut messbare Zielvariable. Die Forderung nach einem Verbrauch unter 1 Liter 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 kmIh und Anschaffungskosten von 10.000 € wohl unrealistisch.

48

2 Problemlösen

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 fiir die Ziele. Allerdings gibt es oft auch Zwischenziele, die schon vorher erreicht werden müssen. Tabelle 2.5 Merkmale SMARTer Zielkriterien Kriterium

Merkmal

Gegenteil

Spezifisch

klar definiert, nachvollziehbar, präzise, konkret, verständlich

vage und allgemein

Messbar

Kriterien für Zielerreichung

Nicht überprüfbar, interpretierbar

Attraktiv

positiv und aktiv formuliert, motivierend, aktionsorientiert

"vermeiden"

Realistisch

erreichbar, beeinflussbar gegebenenfalls in Teilziele aufbrechen

unerreichbar

Terminiert

fester, spätester Zielerreichungszeitpunkt

open end

Die dargestellten Schritte auf dem Weg der Zielfmdung und -formulierung kann man etwas vereinfacht, aber gut einprägsam unter der Forderung zusammenfassen, dass Ziele SMART formuliert werden sollten: spezifisch, messbar, attraktiv, realistisch und terminiert. Beispiel 2-5 Smarte und unsmarte Ziele Die folgenden Formulierungen sollen auf ihre Eignung als Projektziele untersucht und SMART formuliert werden. "Ich möchte in Zukunft nicht mehr so faul sein." Das Ziel ist negativ formuliert und zugleich unspezifisch. Es gibt kein Messkriterium und keine Terminangabe. S: Ich möchte regelmäßig laufen, M: 3 mal pro Woche, mindestens 30 Minuten, A: einem Lauftreff anschließen, einmal die 10 km schaffen, R: pro Woche 20 km; nicht jede Woche 100 km, T: nächste Woche beginnen, nächstes Jahr an einem Lauf-Wettbewerb teilnehmen. Eine bessere Formulierung wäre daher: ,,Ich werde nächste Woche damit beginnen, 3 Mal pro Woche mindestens 30 Minuten zu laufen, um nächstes Jahr am JedermannSilvesterlauf teilnehmen zu können." ,,Mein Ziel ist die Vermeidung einer unnötig geringen Bearbeitungskadenz von Kundenanfragen." Gerade hinter der Verwendung umständlicher, mit Fremdwörtern dekorierter Formulierungen werden oft unklare Ziele verborgen. S: Verringerung der Zeitdauer fiir die Bearbeitung,.

2.2 Erstellung eines Zielsystems

49

M: Kundenanfragen innerhalb von einem Arbeitstag beantworten, A: Erhöhung der Bearbeitungskadenz (nicht Vermeidung von ...) , R: 95 % der Anfragen in einem Tag beantworten, T: Ziel bis Ende des 3. Quartals erreichen. "Bis Ende des 3. Quartals werde ich mindestens 95 % der eingehenden Kundenanfragen innerhalb von einem Arbeitstag beantworten." "Unnötiger COrAusstoss soll vermieden werden." Die Formulierung ist vage, nicht messbar und unattraktiv. Konkreter wäre die Aussage: "Der COrAusstoss in Deutschland soll um 40 % verringert werden." Die Forderung ist nun messbar, aber es fehlen noch die Terminierung (bis wann) und der ProzentReferenzwert. "Der COrAusstoss in Deutschland soll bis zum Jahr 2020 um 40 % gegenüber dem Wert von 1990 verringert werden." Diese Formulierung erfüllt fast alle Anforderung. Fragt sich nur, ob sie realistisch ist. Bei der Suche nach einer Antwort helfen vielleicht ein paar Zahlen weiter: 2000: 900 MTo; 2007: 860 MTo Deutschland: 1990: 1.000 MTo; 2007: 6.400 MTo 2000: 3.700 MTo; China: 1990: 2.500 MTo; 2007: 30.900 MTo 2000: 24.500 MTo; Welt: 1990: 22.500 MTo,

2.2.3 Randbedingungen und Gütekriterien Die Zielfindung sollte zu einem Zielsystem mit mehreren Teilzielen führen. 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 tatsä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 [Grünig 2004]. 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.

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 Nichtein-

50

2 Problemlösen

haltung fiihrt aber nicht zwangsläufig zu einer Zielverfehlung. Bei ihnen gilt ,je mehr, desto besser" und sie sind daher meist Bestandteil eines Gütekriteriums.

Gütekriterien sollen bei einer ProblernIäsung maximiert bzw. eingehalten werden. Sie legen die Qualität einer Läsung/est. Gütekriterien können sowohl analoger als auch binärer Art sein. Analoge Gütekriterien besitzen Werte auf einer kontinuierlichen Skala. 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 Problemstellung.

Beispiel2-6 Fallbeispiel "CAD-Software": Zielformulierung Bei den Steinbachwerken soll ein neues CAD-System für die mechanische Konstruktion angeschafft werden, da das derzeit verwendete System veraltet ist und vom Hersteller abgekündigt wurde. Zur Vorbereitung der Anschaffung werden die Anforderungen an das System diskutiert und schließlich in Form von Zielkriterien formuliert. Zwei wichtige Kriterien sind die einmaligen Anschaffungskosten und die jährlichen Wartungs- bzw. Update-Kosten. Beide Kriterien sind sehr leicht zu erfassen; sie können den Angeboten der Anbieter entnommen werden. Das dritte Zielkriterium ist der Funktionsumfang der Systeme. Von der Konstruktionsabteilung wird eine Liste aller benötigten Funktionen erstellt und dann mit dem Funktionsumfang der präsentierten Systeme verglichen. Als Zielvariable wird der Erfüllungsgrad der geforderten Funktionen in Prozent definiert. Das vierte Teilziel bildet die Bedienbarkeit bzw. die Einfachheit der System-Handhabung. Das Kriterium setzt sich aus mehreren Teilkriterien zusammensetzt, wie z. B. Einarbeitungsaufwand, Ergonomie der Benutzerschnittstelle, Anpassbarkeit an unterschiedliche Benutzerniveaus. Die Überprüfung des Kriteriums könnte z. B. mit Hilfe des DATech Prüfverfahrens für die Konformität interaktiver Systeme auf der Grundlage der ISO-Norm 9241 erfolgen. Wegen des dabei erwarteten Aufwands, wird aber entschieden, die Bedienqualität durch die Mitarbeiter in Form einer Note zu messen: Jeder Mitarbeiter gibt jedem System auf der Basis der Präsentation eine Note. Die gemittelte Note wird dann als Zielvariable verwendet. Aus den negativen Erfahrungen mit dem alten System, soll die Zukunftssicherheit des Systems als weiteres Kriterium berücksichtigt werden. Da es sich hierbei aber um eine Prognose handelt, ist keine direkte Überprüfung möglich. Nach längerer Diskussion wird der Verbreitungsgrad als Zielvariable herangezogen. Dabei wird davon ausgegangen, dass ein weit verbreitetes System nicht so einfach vom Markt verschwindet und dass der große Umsatz genügend finanzielles Potential für eine stetige Weiterentwicklung des Systems bietet. Da genaue Zahlen über den Verbreitungsgrad aber nicht vorliegen, wird er auf drei Werte (hoher, mittlerer bzw. niedriger Verbreitungsgrad) abgeschätzt. Weitere Teilziele sind die Einsetzbarkeit des Systems auf dem Betriebssystem Linux, die Möglichkeit, Dateien des alten CAD-Systems zu importieren und eine online-Schnittstelle zum Produktions-Planungs-System. Diese Kriterien sind binärer Art. Nach der Formulierung der Teilziele, der Festlegung geeigneter Zielvariablen und deren Wertebereichen ist eine Gewichtung der Kriterien und eine Bewertung der angebotenen

2.2 Erstellung eines Zielsystems

51

Systeme notwendig. Zunächst werden Muss-Kriterien festgelegt, deren Nichteinhaltung zum Ausscheiden der Alternative führt. Aufgrund des genehmigten Budgets müssen die Anschaffungskosten unter 30.000 € und die jährliche Wartung unter 3.000 € liegen. Ein System muss außerdem mindestens 80 % der geforderten Funktionen zur Verfügung stellen und es darf in der Handhabung keinesfalls schlechter als 3,0 benotet werden. Auch die Eignung für das Betriebssystem Linux wird als Muss-Kriterium definiert. Tabelle 2.6 Zielvariablen und Randbedingungen zur Anschaffung eines CAD-Systems Teilziel

Zielvariable

Randbedingg.

Gütekrit.

Kosten

Anschaffungskosten [Tsd. €]

<30 Tsd. €

mögl. niedrig

Kosten

Wartungskosten [Tsd. €]

< 3 Tsd. €

mögl. niedrig

FurrUdionsurnfang

FurrUdionsurnfang [0 % .. 100 %]

>80%

mögl. hoch

Handhabung

Handhabungsnote [1,0 .. 5,0]

Mind.3,0

mögl. gut

Verfügbarkeit

Verbreitungsgrad [niedriglmittellhoch]

mögl. hoch

Linux-Eignung

Linux-kompatibel [jainein]

-

Datei-Import

Datei-Import möglich [jainein]

Ja

-

PPS-Schnittstelle

Schnittstelle vorhanden [jainein]

-

Ja

Ja

Als Gütekriterien werden niedrige Kosten, hoher Funktionsumfang, gute Handhabung und hohe Verfügbarkeit definiert. Auch die beiden binären Bedingungen der Linux-Eignung und einer PPS-Schnittstelle sollen Bestandteil des Gütekriteriums sein. Das vorangehende Beispiel zeigt, dass es einerseits unabhängige Randbedingungen und Gütekriterien gibt, dass aber andererseits die gleiche Zielvariable sowohl als Gütekriterium als auch als Randbedingung ins Zielsystem einfließen kann. 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.

2.2.4 Zielstrukturierung Ist die Zahl der Teilziele gering, genügt es, das Gesamtziel als unstrukturierte Sammlung der Einzelzieie zu betrachten. Bei umfangreichen Vorhaben, kann diese Liste aber unübersichtlich und unhandlich werden. Dann ist es notwendig, sie zu strukturieren. Die Einzelzieie werden dabei nach bestimmten Kriterien zu Gruppen zusammen gefasst, die eine Zielgruppe bilden. Diese werden wiederum zum Globalziel des Vorhabens gebündelt. Auch aus einem anderen Grund müssen Ziele oft strukturiert werden: Es ist nicht immer möglich, ein Zielkriterium durch eine einzige Zielvariable auszudrücken. In diesem Fall ist eine Untergliederung des Ziels notwendig. Gerade nichtoperationelle Zielkriterien, wie z. B. "Be-

52

2 Problemlösen

dienkomfort" oder "Ergonomie", die sowohl für die Lösungssuche als auch für die Messung der Zielerreichung schwierig sind, sollten untergliedert und damit operationalisiert werden. Auch bei anderen, scheinbar gut messbaren Kriterien, wie z. B. ,,Kostenminimierung", kann eine Untergliederung sehr hilfreich sein. So kann sich z. B. die Zielvariable "Kosten" zusammensetzen aus Herstellkosten und Betriebskosten. Die Herstellkosten wiederum können weiter untergliedert werden in Materialkosten, Entwicklungskosten, Kosten für die Produktion, die Lagerung, den Transport usw. Vor dem Hintergrund der Zielfmdung auf der Basis von übergeordneten Begriffen wie Visionen, Wünsche etc, macht die hierarchische Gliederung des Zieles außerdem deutlich, dass auch ein Gesamtziel in ein übergeordnetes Ziel eingebettet ist. Oft hilft gerade diese Erkenntnis bei der Entscheidung im Falle von Zielkonflikten. Gibt es innerhalb des Zieles gegenläufige Zielvariablen kann nämlich untersucht werden, welche der Zielvariablen im Sinne der übergeordneten Kriterien zielführend ist. Beispiel 2-7 Deckungsbeitrag für Kunststoffgehäuse Bei einem Hersteller von Kunststoffgehäusen teilt der Chef seinem Betriebsleiter mit, dass zu wenig Geld mit den Gehäusen verdient wird. Obwohl es sich hier objektiv betrachtet bloß um eine Zustandsbeschreibung handelt, glaubt der Chef damit schon einen Auftrag und auch ein Ziel formuliert zu haben. Der Betriebsleiter, der die Grundsätze SMARTer Zielbeschreibung kennt, formuliert für sich folgenden Auftrag: "Unser Ziel ist es, den Deckungsbeitrag für das Kunststoffgehäuse innerhalb von 8 Monaten von 10 % auf 20 % zu steigern." Das Ziel ist sicherlich spezifisch, messbar, attraktiv, terminiert und hoffentlich auch realistisch. Das Ziel besteht aus einem einzigen Kriterium und einer messbaren Variablen (Deckungsbeitrag). Es handelt sich um ein Gütekriterium, da das Ziel um so besser erreicht wird, je höher der Deckungsbeitrag ausfallt. Insofern scheinen die Verhältnisse einfach und klar zu sein. Aber alleine schon das Fehlen einer Randbedingung sollte schon stutzig machen. Der Betriebsleiter bildet ein Projektteam, das den Auftrag analysiert. Verschiedene grundsätzliche Lösungswege werden diskutiert. Im Laufe der Diskussion zeigt sich, dass die Zielsetzung doch nicht so eindeutig ist, wie es auf den ersten Blick scheint. Ein Mitarbeiter aus der Produktion schlägt vor, preisgünstigeres Kunststoffgranulat als Rohstoff für das Gehäuse einzukaufen. Ein anderer Mitarbeiter gibt zu bedenken, dass der preiswertere Kunststoff, geringere Schlagfestigkeit und eine geringere Lebensdauer aufweist. Die Diskussion macht deutlich, dass die Produktqualität als zusätzliches Zielkriterium berücksichtigt werden muss. Ein Mitarbeiter aus dem Vertrieb schlägt vor, ein neues Spritzgusswerkzeug zu konstruieren, da das bisher verwendete, zu relativ vielen Fehlern und damit zu Produktausschuss führt. Da ein neues Werkzeug aber zusätzliche Kosten verursacht, müssen diese als weiteres Zielkriterium betrachtet werden. Auch der Vorschlag, die Verkaufszahlen des Gehäuses durch zusätzliches Marketing anzukurbeln, um den Stückpreis zu verringern, zeigt den Einfluss des Kostenkriteriums. Am Ende der Diskussion ist klar, dass neben dem Deckungsbeitrag auch die Produktqualität und die anfallenden Kosten Zielkriterien für das Vorhaben sein müssen.

2.2 Erstellung eines Zielsystems

53

Sowohl durch die BÜfidelung von Teilzielen als auch durch die Untergliederung von Hauptzielen erhält ein Ziel eine Struktur. Aus einem wolkigen Globalziel oder einem ungeordneten Bündel von Teilzielen wird ein hierarchisch strukturierter Zielbaum. Teilziele können voneinander unabhängig sein; sie können aber auch positiv oder negativ korreliert sein. Wird ein Teilziel durch geeignete Maßnahmen verbessert, so ergibt sich für ein anderes, positiv korreliertes Teilziel ebenfalls eine Verbesserung. Eine positive Korrelation zweier Zielvariablen kann so weit gehen, dass sie sich identisch verhalten. Ist dies der Fall, genügt es, nur eine der beiden Variablen in der Problemlösung zu berücksichtigen.

r rJ

~

-~

c

AIBI Globalziel Hauptziel1 Teilziel1.1 4 Teilziel1.2 Teilziel 1.3 5 Hauptziel 2 6 7 Teilziel 21 Teilziel22 8 Teilziel2.3 9 Hauptziel 3 10 11 -fTeilzieI3.1 12 Teilziel3.2 1 2 3

101

E Zielvariablen Kosten Entwicklungskosten Produktionskosten I Betribeskosten I IFunktionen Funktion 1 I Funktion 2 I Funktion 3 Organisation

I

F I G Gewichtung

3~

T

~Termintreue Qualität

10% 10% 10%

50% 20% 20%

I

10% 20%

I

10% 10%

Bild 2-5 Hierarchische Zielstrukturierung (Zielbaum)

Zielvariablen können aber auch negativ korreliert sein - es entsteht ein Zielkonßikt. In der Praxis ist dies sogar sehr häufig der Fall. Wird also der Wert einer Zielvariablen verbessert, verschlechtert sich der Wert einer anderen, negativ korrelierten. In diesem Fall liegt natürlich ein strukturelles Zielproblem 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. Man hat dann einen Zielkonflikt: Nur eine der beiden Zielvariablen kann berücksichtigt werden. Dieses Problem muss im Rahmen der Entscheidungsfindung behandelt werden. Von den Zielkonflikten müssen die Interessenkonßikte deutlich unterschieden werden. Erstere stellen fast immer ein sachliches Problem dar, welches logisch gelöst werden kann. Interessenkonf1ikte sind soziale Probleme, die weit schwierigere psychologische Methoden erfordern. Beispiel 2-8 Korrelationen und Konflikte bei Zielvariablen Wichtige Zielvariablen für den Bau einer Brücke sind die Tragflihigkeit, das Gewicht und der Preis. Gewicht und Preis sind zumindest teilweise positiv korreliert: Gelingt es, das Gewicht bei gleichen Werkstoffen durch eine intelligentere Konstruktion bei gleich bleibender Tragfähigkeit zu verringern, so wird sich aufgrond des geringeren Materialverbrauchs auch der Preis verringern. Tragflihigkeit und Gewicht sowie Tragflihigkeit und Preis sind dagegen negativ korreliert. Größere Tragfähigkeit der Brücke führt bei gleicher Bauweise zu höherem Gewicht und

54

2 Problemlösen höherem Preis. Hier kommt es zu einem Zielkonflikt. Soll die höhere Tragflihigkeit ohne Gewichtszunahme erreicht werden, so geht dies meist nur durch deutlich erhöhte Kosten, z. B. durch Verwendung leichter aber robuster Werkstoffe. Der Zielkonflikt kann gelöst werden, indem eine Größe, z. B. die Kosten durch eine Randbedingung begrenzt wird. Die gegenläufige Zielgröße, z. B. die Tragflihigkeit kann dann so weit erhöht werden, bis der Grenzwert der Kosten erreicht wird. Eine vollkommen andere, meistens wesentlich schwerer zu lösender Konflikt liegt vor, wenn Verkehrsplaner eine möglichst große und breite Brücke fordern, während Landschaftsschützer gerne eine kleinere Brücke hätten und am liebsten auf einen Neubau ganz verzichten würden.

2.3 Lösungssynthese "Nichts aufder Welt ist so mächtig wie eine Idee, deren Zeit gekommen ist. " (MoUere)

2.3.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. Als einigermaßen gesichert gelten verschiedene kreativitätshemmende und kreativitätsf6rdernde Faktoren. Eine unbestrittene Voraussetzung für Kreativität ist Wissen. Eine breite, vielfältige Wissensbasis ist für die Kreativität sehr fOrderlich, während spezialisiertes Wissen keine so starke kreative Wirkung entfaltet und extremes Spezialwissen sogar hinderlich sein kann. Je mehr jemand weiß und je mehr jemand aus verschiedenen Fachgebieten weiß, desto eher ist er 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 fOrdernder 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

2.3 Lösungssynthese

55

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. Unbestritten ist auch die Erkenntnis, dass Ideen nicht erzwungen werden können. 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 Blockaden, 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ÜToumgebung geschaffen werden, durch die Wahl eines Termins, der aus der üblichen Arbeitszeit herausragt oder durch das Hinzuziehen von Personen, die mit dem Problem bislang 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. Tabelle 2.7 Kreativitätshemmende und -fördernde Faktoren Hemmende Faktoren

Fördernde Faktoren

Druck: Zeitdruck, Erfolgsdruck

Breite, vielfältige Wissensbasis

Voreilige Kritik

Angenehme Atmosphäre

Funktionale Fixierung

Gruppendynamik

Einstellungseffekte

Analogiebildung

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, einfachere 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.

Beispiel 2-9 Überwindung von Denkblockaden Das Legen geometrischer Muster mit Streichhölzern sind beliebte Denksportaufgaben. Der Mensch ist dabei ein sehr guter Abstrahierer der spätestens bei der dritten gleichartigen Aufgabe damit beginnt, ein Lösungsschema zu formulieren. Das folgende Bild zeigt, wie

56

2 Problemlösen aus 4 Streichhölzern 1 Quadrat und aus 7 Streichhölzern 2 Quadrate gelegt werden können. Die Aufgabe ist es nun, aus 9 Streichhölzern mindestens 3 Quadrate zu bilden.

1111

I

1111111

- - - - - - - +- - - - - - - - - - - - -

1=1

I

i

1-=1

i

111111111

-1-

_

I

i

?

Bild 2-6 Streichholzaufgabe mit 4, 7 und 9 Streichhölzern

Durch die vorbereitende "Hilfe" mit 4 bzw. 7 Streichhölzern, können verschiedene Fixierungen entstehen. So wird oft die Annahme gemacht, dass die Seitenlänge gleich der Streichholzlänge sein muss. Oder es wird als selbstverständlich erachtet, dass die Seitenlänge aller Quadrate gleich sein muss. Schließlich wird fast immer angenommen, dass die Quadrate in einer Ebene liegen müssen und dass alle Streichhölzer verwendet werden müssen. Alle diese Annahmen sind falsch, da sie nicht gefordert wurden. Die einzige wirkliche Bedingung ist die Gleichseitigkeit jedes Quadrats für sich. Das Erkennen jeder Blockade führt zu einer eigenen Lösung. Wenn man die Seitenlänge gleich der Streichholzlänge lässt, kann man 3 Quadrate bilden, indem man die dritte Raumdimension nutzt. Lässt man unterschiedliche Seitenlängen zu, kann man mit nur 8 Streichhölzern sogar 14 Quadrate bilden. Auch ganz ausgefallene Ansätze wie das Durchbrechen von Streichhölzern oder die Nutzung der schmalen Seite eines Streichholzes können zu neuartigen Lösungen führen. Auch wenn es Erfmdern 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. Typisch für diese Phase ist die Erfolglosigkeit! Auch wenn fast immer die Hoffung besteht, das Problem schnell zu lösen, gelingt dies bei Problemen nennenswerter Komplexität praktisch nie. Mental ist diese Situation natürlich sehr schwierig: Es wird viel Zeit und viel Arbeit in das Problem investiert und man hat das Gefühl, keinen Millimeter weiter zu kommen oder 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

2.3 Lösungssynthese

57

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.3.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. ZUfÜ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 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-PlanMethode) dar. Jeder Teilnehmer notiert seine Ideen auf einzelnen 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 können die veröffentlichten Ideen diskutiert und durch Vergabe von Punkten durch die Teilnehmer bewertet werden. 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. Hier setzen sich 6 Teilnehmer zusammen. Jeder notiert 3 Ideen auf einem Blatt. Nach 5 Minuten 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 dieser Methode sind alle Beiträge zwangsläufig dokumentiert. Introvertierte Gruppemnitglieder 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,

58

2 Problemlösen

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. Beschränkungen vernachlässigen oder die Realisierbarkeit höher einschätzen, als sie es tatsächlich ist. 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 einzunehmen. Ähnlich funktioniert die Denkhüte-Methode nach De Bono. Hier gibt es sogar 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 analytisch denkenden Realisten, des optimistischen Träumers und des Kritikers aus der Disney-Methode zugeordnet 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 aufF. Zwicky zurück [Zwicky 1965]. 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

2.3 Lösungssynthese

59

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.

Beispiel2-10 Morphologische Methode zur Suche nach neuen Sensoren Bei der elektrischen Messung physikalischer Größen werden verschiedene Effekte genutzt. Bei passiven elektrischen Aufnehmem, sind dies die Wirkungen, die verschiedene Größen auf die elektrischen Basisgrößen Widerstand, Kapazität und Induktivität haben. Beispiele hierfür sind die Abhängigkeit des Widerstands von der Länge, dem Querschnitt, der Materialeigenschaft oder der Temperatur eines Bauteils. Ein Hersteller elektrischer Sensoren möchte nun sein Produktportfolio um neue Sensoren erweitern. In einer Sitzung werden die wichtigen Merkmale von Aufnehmem 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. Tabelle 2.8 Morphologischer Kasten für passive elektrische Aufnehmer Merkmal

Merkmalsausprägungen

I Kraft I Moment

Messgröße

Winkel

Hilfsgröße

Bewegung

Elektrische Größe

Widerstand

Umgeb.-medium

Luft

Druck

I Beschleunig. I Feuchte

Temperatur Kapazität

I Öl

Umgeb.-Temp.

<50 oe

Genauigkeit

Besser als 0,1 %

Wasser <90

oe

Besser als 0,5 %

Induktivität

I Granulat

< 120 oe

I Pulver

Besser als 1 %

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 oe einsetzbar sein und eine Genauigkeit von mindestens 1 % besitzen. 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 zwar außergewöhnlich, aber realisierbar sind, hohes Innovationspotential bergen.

60

2 Problemlösen

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öglichkeit 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, 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 (1997), sowie dessen Weiterentwicklung SCAMMPERR. Die dargestellte Tabelle versucht die Fragenmethodik zusammenzufassen und gegenüber zu stellen. Jede dieser Fragemethodiken kann sowohl auf das bestehende Problem ("Kann ich mein Problem transformieren, adaptieren etc., um es zu lösen?") als auch auf vorhandene Lösungen anderer Probleme angewendet werden ("Kann ich eine andere Lösung transformieren, adaptieren etc., um mein Problem zu lösen?"). Tabelle 2.9 Fragemethodiken zur Aufspannung von Lösungsräumen Methode

Kann ich mein Problem lösen, indem ich ...

Minimieren

es verkleinere?

eine vorhandene Lösung verkleinere?

Maximieren

es vergrößere?

eine vorhandene Lösung vergrößere?

Transformieren

es gedanklich in einen anderen Bereich übertrage?

eine in einem anderen Bereich vorhandene Lösung auf mein Problem übertrage?

Kombinieren

es mit anderen Problemen kombiniere?

mehrere vorhandene Lösungen kombiniere?

Modifizieren / Adaptieren

es modifiziere?

eine vorhandene Lösung modifiziere?

Umordnen/ Invertieren

seine interne Anordnung verändere oder gar invertiere?

die Anordnung einer vorhandenen Lösung verändere oder invertiere?

Substituieren

ein Teilproblem ersetze?

einen Teil einer vorhandenen Lösung ersetze?

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 nicht nur die Lagerfläche verringert, sondern 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

2.3 Lösungssynthese

61

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 ganzes Fachgebiet, das sich ausschließlich mit dieser Art der Lösung von Problemen beschäftigt, ist die Bionik [Nachtigall 2002]. 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).

BeispieI2-11 Apotheken-Lagerfläche Apotheken sind oft in den lA-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? 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 der obigen Tabelle 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 Bekanntheits- und Verbreitungsgrad. Dies gilt insbesondere bei kleinen und mittelständischen Unternehmen. Verschiedene Befragungen bei potentiellen Anwendern von Kreativitätsmethoden haben ge-

62

2 Problemlösen

zeigt, dass das Brainstorming und auch die Kartenabfrage einen sehr hohen Bekanntheitsgrad besitzen, in deutlichem Abstand gefolgt vom Brainwriting, von der 635-Methode und morphologischen Methoden ([Knieß 1992], [Herren 2008]). 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. Tabelle 2.10 Vergleich der Kreativitätsmethoden Methode

S

T

D

H

M

P

Brainstorming [Osbom 1957]

S+

6-12

2 Std.

H

M

P+

Brainwriting

S+

6-12

2 Std.

H

M

-

K.artenabfrage (Pinnwand)

S+

4-12

2 Std.

H++

M+

P

H

Methode 635 [Rohrbach]

S

6

1 Std.

Morphologische Methode [Zwicky 1965]

S+

1..

8 Std.

H+

-

P

-

Synektik [Gordon]

S++

4-8

2 Std.

H

M+

P+

TRlZ [Altschuller]

S++

1..

8 Std.

H

-

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)

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 empfoWen zu werden.

2.4 Lösungsauswahl " Unser Entscheiden reicht weiter als unsere Erkenntnis. " (Kant) 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 vielfliltige Anforderungen, Wünsche und Ziele zugrunde. Damit Entscheidungen nicht zuflillig oder willkürlich getroffen werden und dadurch fehleranflillig

2.4 Lösungsauswahl

63

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.4.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]. 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.

64

2 Problemlösen

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. Beispiel2-12 Präferenzmatrix für die Wahl eines Studienfachs Ein Abiturient möchte studieren, ist sich aber unschlüssig, welches Fach er wählen soll. Nachdem er sich gründlich über verschiedene Fächer informiert hat, ist er unschlüssiger als zuvor. Er bespricht die Situation mit seinen Eltern. Dabei kommen verschiedene Argumente zur Sprache. Der Student möchte Fach A studieren, da es seinen persönlichen Interessen am meisten entspricht und da er glaubt, dass dieses Fach nicht so schwer sei wie Fach B. Der Vater gibt aber zu Bedenken, dass gerade Fach B sehr gute Berufsaussichten biete. Die Mutter plädiert für Fach C, da der dadurch erlangte Abschluss ein hohes gesellschaftliches Ansehen besitze. Als der Student am Abend seiner Freundin die Situation schildert, ist diese von keinem der drei Fächer begeistert, da sie nicht am Wohnort angeboten werden und deshalb einen Wegzug des Studenten erfordern. Sie ist daher für Fach D, das in der Heimatstadt abgeboten wird und daher auch mit geringeren Kosten verbunden ist. K1: Interesse K2: Schwere des Studiums K3: Berufsaussichten K4: Ansehen des Fachs K5: Wohnortnähe

Bild 2-7 Präferenzmatrix für die Studienfachwahl

Da der Student sich über die Bedeutung der Argumente nicht schlüssig ist, formuliert er sie als Auswahlkriterien und ermittelt eine Gewichtung mit Hilfe einer Präferenzmatrix. Als Ergebnis des Vergleichs ergibt sich für den Studenten ein klareres Bild. Seine persönliche Neigung besitzt die höchste Priorität, gefolgt von den Berufsaussichten, der Wohnortnähe, der Schwere des Studiums und schließlich dem gesellschaftlichen Ansehen des Berufs.

2.4.2 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

2.4 Lösungsauswahl

65

Handlungsalternativen werden auch die Zielkriterien bei den analytischen Verfahren systematisch untersucht und ausgewertet. Tabelle 2.11 Nutzwertanalyse zur Bewertung von Alternativen ~ anband der Kriterien K; Kriterium

Variable

Nutzen

Gewicht

Ko

Vo

Uo

go

KI

VI

VI

...

...

Kn

Vn

Alternative AI

...

Alternative Am mit Wirkung Ern

mit Wirkung EI

go .Uo(E1)

...

go·UO(E m )

gl

gl . U1(EI)

...

gl·U1(Em )

...

...

...

.. .

Vn

gn

gn . Un(E 1)

... ...

gn . Un(E m )

Die Nutzwertanalyse geht von einer Zielfonnulierung aus, die sich aus mehreren Gütekriterien K i zusammensetzt. Der Erfüllungsgrad jedes Kriteriums wird durch eine Zielvariable Vi gemessen. Alle Zielvariablen werden mit Hilfe einer Nutzenfunktion Vi auf einen einheitlichen Nutzenmaßstab abgebildet. Der Einfluss jedes Einzelnutzens 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: n

I

(2.1)

J k = Lgi .Ui(Ek)=Max i=O

Der Nutzen eines Zielkriteriums kann in unterschiedlicher Fonn, 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. 100%

o%-+<=:-----+-.

100% O%-1-----j<::------l-....

100% 0%++--+---1-....

Bild 2-8 Verschiedene Nutzenfunktionen

Nutzenfunktionen können für binäre, digitale und auch kontinuierliche Wertebereiche definiert werden. Neben lineare Funktionen können auch nichtlineare Effekte, wie z. B. Begrenzungen oder Bereichsbildungen, wie im obigen Bild dargestellt, sinnvoll sein. BeispieI2-13 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 Sys-

2 Problemlösen

66

teme 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.

-

0 A l B -Ie ~ VitAl lVi/BI Vi/q Vi/DI lVi/EI :i IZielvariable Vi 25[ 21 16 15 121 ~!Anschaffungskosten !:!!t__ 1---05 0,7 -1l~,7 1,0 -.1 ~rtunJlskosten: lI€) 3 Funkti~sumfang fO .. 1OO%1 95% 95% 95% 85% 75% 3,6 4 Handhabung [Note 1,0 .. 5,0) 1,6 1,8 2,2 2,0

,I

mittel mittel ~ Verfügbarkeit Ihoc~milte!!niedrÜu eb°~ .,..,..6 Linux-Basis ljalnein] ne~ Ja Ja I 7lpPS-Schniltstelie fjalnein] Ija nein !nein

I. niedrig mittel . Ja ja

Ja fia

BUd 2-9 Sc:reenshot der bewerteten Varianten Abis E

Die Soll-Ziele werden von 2 der 5 Systeme nicht erfüllt. Bei Variante E liegt der Funkti.onsumfang unter den geforderten 80 %. Außerdem wurde die Handhabung bei Variante C schlechter als 3,0 benotet. Diese beiden Varianten scheiden daher aus.

I-r-

-- -

,i IZielvariable Vi Ui 1lAnschaffungskosten: ~ 10 T~ .. 30T~ 0,0 T€ .. 2,5 T€ 2lWartunqskosten: [T~J 31 Funktionsumfang [0-,-,1911"&]___ . .80% ~OO% 41Handhabung jNote 1,0 .. 5,Q] 1,0 3,0 ~~~barkeil fhochlmitlel!niedrigj niedriQ/mitlel/hoch nein/ia 6 Linux-Basis fialnein1 nein/ia , 71 PPS-Schnittstelle lialnein1

=

[D le ~A Ui(A) I ~ i"Ui Ui(C11 qi"Ui Ui(DI 1~ i*Ui Iqi 9,5[ 2,38 10 .. Pklel 25% 2,01 0,50 7,01 1,75 10 .. 0 Pklel 10% 8,~,80 3,0 0,30 ---l,Q ~ 7,5 2,25 7,5 2:25 -~ ,-0,75 ~PkteJ 30% ---:;rn;;::, 10 .. 0 Pklel 15% 4,0 0,50 5,0 0,75 7,0 1,05 0/5/10 Pklel 10% 1O!~,QQ 5,0 0:50 ~~ ~ 0 110 Pktel 6% 0,0 0,00 10,0 0,60 10,0 0,60 4% 10,01 0,40 10,01 0,40 ---OP1 0,00 110 Pklel '100% I 5,55 ~

°

= = =

, I

I

°

1

°

=

_L!Ji __

Bild 2-10 Screenshot der gewichteten Nutzenfunktionen für die 3 Varianten A, C und D

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). 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ösungsaltemative 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 Ko als Kostenkriterium, so gilt:

67

2.4 Lösungsauswahl n

Lgi 'Ui(E k ) Jk =

. 1

1=

()

Uo E k

, .

Max

(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 Umrechung des Nutzens ergibt. Es wird dann das Kriterium gewählt, bei dem die Nutzen-Kosten-Differenz maximal ist. n

Jk =

LUi(Ek )-Uo(Ek )

(2.3)

i=l

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 zufriedenstellend 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 AufgabensteIlung 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.

68

2 Problemlösen

2.5 Repetitorium 2.5.1 Checklisten Tabelle 2.12 Checkliste Problemlösen

1.

Woraus besteht das Problem?

2.

Welche Ziele sollen erreicht werden?

3.

Wie sehen die Randbedingungen aus?

4.

Welche Kriterien legen die Güte einer Lösung fest?

5.

Wie sehen die Prioritäten und Kriterien-Gewichte aus?

6.

Wurden genügend Lösungsideen produziert?

7.

Welche Methoden wurden zur Produktion von Ideen eingesetzt?

8.

Welche Lösungsideen wurden detailliert ausgearbeitet?

9.

Nach welchem Verfahren wird entschieden, welche Lösung realisiert werden soll?

2.5.2 Verständnisfragen 1. 2. 3.

Erläutern Sie die Grobstruktur eines Problemlösungsprozesses! Erläutern Sie die 6-W-Methode zur Problemerkennung! Erläutern Sie die typischen Fehlersituationen bei der Problemerkennung!

4. 5.

Was ist das Ziel der Problemanalyse? Was ist ein Ursache-Wirkungsdiagramm (Ishikawa-Diagramm)?

6. 7. 8.

Was ist ein Beziehungsdiagramm? Was versteht man unter einer Pareto-Analyse? Was versteht man unter einer ABC-Analyse?

9. 10. 11.

Was beschreibt das 80/20-Prinzip? Erläutern Sie die Bedingungen für die Formulierung von Zielen! Worin unterscheiden sich Muss- und Soll-Kriterien bei der Zielformulierung?

12. 13.

Was istInkubation? Durch welche Faktoren wird die Findung kreativer Ideen gehemmt bzw. gefördert?

14. 15. 16.

Beschreiben Sie die Ideenfmdung durch Brainstorming! Worin unterscheidet sich Brainwriting vom Brainstorming? Beschreiben Sie die 635-Methode zur Ideenfindung!

17. 18.

Beschreiben Sie die morphologische Methode zur Ideenfindung! Durch welche Methoden kann die Sichtweise eines Sachverhalts systematisch verändert werden? Welche Systematiken kennen Sie, um einen Lösungsraum aufzuspannen?

19.

2.5 Repetitorium

69

20.

Ist es sinnvoll, Entscheidungen intuitiv zu treffen?

21. 22. 23.

Was ist eine Argumentenbilanz? Erläutern Sie die Anwendung einer Präferenzmatrix! Skizzieren Sie die wichtigen Schritte einer Nutzwertanalyse!

24.

Worin unterscheiden sich Nutzwertanalyse, Kosten-Wirksamkeitsanalyse und Wirtschaftlichkeitsanalyse?

2.5.3 Übungsaufgaben Aufgabe 2-1 Problemerkennung Einfamilienhausheizung

Der Besitzer eines Einfamilienhauses beklagt sich, dass die Kosten für die mit Öl betriebene Heizung zu hoch sind. Versuchen Sie mit Hilfe der 6-W-Methode das Problem zu analysieren. Aufgabe 2-2 Ishikawa-Diagramm für die Herstellkosten von PKWs

Welche Faktoren beeinflussen die Kosten zur Produktion von PKWs? Stellen Sie den Zusammenhang als Ishikawa-Diagramm dar. Aufgabe 2-3 ABC-Analyse

Führen Sie eine ABC-Analyse der weltweiten Energiequellen durch. Sie sollten mindestens 15 verschiedene Energiequellen (z. B. Erdöl, Kernkraft, Photovoltaik) erfassen. Aufgabe 2-4 Argumentenbilanz

Ihr derzeitiges Auto ist ca. 6 Jahre alt und hat eine Laufleistung von 125.000 km. Sie überlegen, ob Sie das Auto weiter behalten oder sich ein anderes kaufen sollen. Erstellen Sie eine Argumentenbilanz. Aufgabe 2-5 Zielformulierung

Untersuchen Sie die Qualität der folgenden Zielformulierungen! "Um den Gewinn des Unternehmens zu maximieren, soll die Produktivität gesteigert und die Kundenzufriedenheit verbessert werden." "Ich möchte in Zukunft mehr Freude an meiner Arbeit haben und mein Einkommen deutlich erhöhen." "Unsere Projektbesprechungen sind immer von endlos langen Diskussionen geprägt und hinterher weiß niemand so recht, was zu tun ist." ,,zur Erhöhung der Verkaufszahlen sollen die Mitarbeiter der Entwicklungsabteilung in nächster Zeit den Vertrieb bei seiner Arbeit unterstützen." "Da in zurückliegenden Projekten die Kostenpläne um mehr als das doppelte überschritten wurden, ist beim neuen Projekt der Projektleiter für die strikte Einhaltung des Kostenbudgets verantwortlich."

70

2 Problemlösen

,,Das Gewicht des Fahrzeugs ist durch die vermehrte Verwendung von Kunststoff-Bauteilen kurzfristig zu reduzieren." Wie würden Sie diese Ziele formulieren? Aufgabe 2-6 Zielsystem Erstellen Siefür jedes der folgenden Vorhaben ein Zielsystem, bestehend aus Teilzielen, Zielvariablen und zugehörigen Wertebereichen. Kauf eines neuen Autos. Neubau eines Einfamilienhauses. Verwendung eines Lottogewinns von 100 Tsd. €. Aufgabe 2-7 Nutzwertanalyse Sie haben Ihr Studium des Wirtschaftingenieurwesens erfolgreich abgeschlossen. Nachdem Sie mehrere Bewerbungen geschrieben haben, wurden sie zu Vorstellungsgesprächen eingeladen und können nun zwischen folgenden Stellen wählen: Bei einem Elektrokonzern in München könnten Sie als Leiter einer aus 7 Technikern bestehenden Serviceabteilung :für Kraftwerksleitsysteme anfangen. Zu Ihren Aufgaben zählen die Führung der Abteilung und die Organisation der Service-Einsätze. Ihr Gehalt beträgt 60 Tsd. €. In Norddeutschland wurde Ihnen bei einem Hersteller von Windkraftanlagen eine Stelle als Trainee angeboten. Sie würden zunächst bei einem Gehalt von 40 Tsd. €, verschiedene Bereiche des Unternehmens durchlaufen und nach einem Jahr würde dann über Ihr endgültiges Einsatzgebiet entschieden. Bei einem am Bodensee ansässigen Automobilzulieferer könnten Sie bei einem Gehalt von 45 Tsd. € als Schaltungsentwickler :für Motorsteuerungen beginnen. Ihr derzeitiger Arbeitgeber, ein mittelständischer Hersteller von Schaltanlagen bietet Ihnen die Position als stellvertretender Vertriebsbeauftragter :für den Raum Osteuropa. Ihre Aufgabe wäre die Akquisition und Betreuung neuer Kunden. Das Gehalt ist erfolgsabhängig. Erstellen Sie zur Vorbereitung der Entscheidung eine Nutzwertanalyse.

3 Projektgründung " Sattle gut und reite getrost. " (J. W. Goethe)

3.1 Das Zieldreieck von Projekten 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. Injedem Projekt geht es darum, innerhalb einer begrenzten Zeit und mit begrenzten Ressourcen ein bestimmtes Ergebnis zu liefern. Auf diesem Abstraktionsniveau lassen sich 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 Basisdimension 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 natürlich aus einer Vielzahl von Teilkriterien zusammen: der Arbeitsaufwand der beteiligten Personen, die eingesetzten Maschinen, Rohstoffe, Werkzeuge Räume, zugekaufte Leistungen. Alle eingesetzten Ressourcen stellen Kosten dar bzw. können unmittelbar in Kosten umgerechnet werden. Es ist daher sinnvoll, alle diese Teilkriterien zu einem Basiskriterium "Kosten" zusammen zu fassen. 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 hier 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. Mit dieser Festlegung gelangt man in Projekten zu den drei grundlegenden Zielkriterien: Termine, Kosten und Qualität. Die drei Anforderungen stehen in einem sehr engen, gegenläufigen Zusammenhang. Steigen die Qualitätsanforderungen in einem Projekt an, so geht dies zu Lasten der Kosten und der Termine. Sollen Kosten eingespart werden, ist dies oft nur durch Reduktion der funktionellen Qualitäts-Anforderungen bzw. durch längere Laufzeit erreichbar. Eine Verkürzung der Laufzeit wiederum führt zu höheren Kosten bzw. schlechterer Qualität des Ergebnisses. 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, muss das Ganze eher als netter, prägnanter Name für einen grundlegenden Sachverhalt angesehen werden. In diesem Buch wird stattdessen der Begriff Zieldreieck verwendet.

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6_3, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

72

3 Projektgründung

Betrachtet man die drei Basiskriterien als Dimensionen in einem dreidimensionalen Zielraum, so legen die drei Anforderungsniveaus jeweils einen Punkt auf jeder Achse fest und bilden zusammen genommen ein Dreieck im Zielraum. Dabei ist zu beachten, dass die Anforderungen in Achsenrichtung ansteigen, die somit höhere Qualität, niedrigere Kosten und kürzere Termine repräsentieren. Die enge Wechselwirkung der drei Größen kann graphischen veranschaulicht werden. Steigen die Anforderungen in einer Dimension an, z. B. bei der Qualität, müssen die Anforderungen bei den anderen Kriterien sinken, z. B. durch höhere Kosten oder spätere Termine. In Anlehnung an das Prinzip kommunizierender Röhren kann man sich die Kopplung bildlich so vorstellen, dass die Fläche des Dreiecks, d. h. eine bestimmte Qualitäts-Kosten-TerminKombination, konstant bleibt. De die Verbesserung bei einem der Ziele immer nur zu Lasten der anderen erreicht werden kann, spricht man manchmal auch von einem Trilemma. , I

...

(höhere) Qualität

(kürzere) Termine

(niedrigere) Kosten

~~

/

Bild 3-1 Zieldreieck von Projekten ("Magisches" Projektdreieck)

Die folgende Abbildung zeigt einige typische Konstellationen im Zieldreieck, bei denen die ursprüngliche Zielkombination verändert wurde. Das erste Bild (a) zeigt den Fall, dass eine Steigerung der Qualitätsanforderung nur zu Lasten des Kostenziels (höhere Kosten!) und zu Lasten der Terminziele (spätere Fertigstellung!) erreichbar ist. Der nächste Fall (b) stellt eine Verschärfung der Terminanforderung dar. Sie wird durch Mehrkosten (schwächeres Kostenziel) und Minderqualität (z. B. weniger Funktionen) erreicht. Der letzte Fall (c) zeigt, wie sich ein höheres Kostenziel (Kosteneinsparung!) zu Lasten der Qualität und der Termine auswirkt. a

c

b

'A

T

'A

T

T

Bild 3-2 Darstellung geänderter Ziele eines Projektes im Zieldreieck

Das Zieldreieck ist natürlich kein mathematisch anwendbares Werkzeug. Es dient lediglich zur symbolischen Darstellung der Zusammenhänge. Diese sind aber so wichtig, dass es bei Ein-

3.2 Projektauftrag

73

griffen im Projekt immer notwendig ist, sich die Auswirkungen "vor Augen" zu führen. Hier leistet das Zieldreieck gute Dienste.

3.2 Projektauftrag Jedes Projekt hat einen Auftraggeber und einen Auftragnehmer. 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. Der Auftraggeber eines Projekts stellt bestimmte Forderungen und ist bereit, für deren Erfüllung zu zahlen. Im Gegenzug verpflichtet sich der Auftragnehmer, die Anforderungen zu erfüllen. Überspitzt formuliert möchte der Auftraggeber seine Anforderungen für möglichst wenig Geld erfiillt bekommen und der Auftragnehmer möchte für möglichst wenig Leistungen möglichst viel Geld bekommen. Die Details dieser Zusammenarbeit regelt der Projektauftrag. In ihm beschreibt der Auftraggeber, welche Leistungen er im Laufe des Projekts vom Auftragnehmer erwartet. Ein Auftrag umfasst mehrere Aspekte. Der fachliche Aspekt betrachtet den Auftragsgegenstand, der am Ende des Projekts vom Auftragnehmer zu liefern ist. Der organisatorische Aspekt beschreibt die Bedingungen für die Durchführung der Zusammenarbeit. Den dritten Aspekt bilden die rechtlichen Vereinbarungen, die mit der Auftragsvergabe verbunden sind.

3.2.1 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". Es wird daher oft auch Leistungsverzeichnis genannt. Für das Dokument, das die Anforderungen zusammenfasst, sind weitere Bezeichnungen im Gebrauch, wie z. B. Anforderungsspezifikation, Kundenspezifikation oder Requirements-Specification. Im Folgenden wird hier durchgängig der Begriff Lastenheft verwendet.

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 "LastenBuch" 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.

74

3 Projektgründung

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.

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. Stark abstrahiert beschreibt der Auftraggeber im Lastenheft seine Anforderungen an die Problemlösung, während der Auftragnehmer im Pflichtenheft beschreibt, wie die Lösung aussehen wird. 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-lPflichtenheft".

3.2.2 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. Aus Sicht der zeitlich gestaffelten Arbeitsschritte eines Projektes bildet die Funktionsspezifikation die Beschreibung des angestrebten Zielzustands. Neben den 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.

3.2 Projektauftrag

75

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 dem Leser 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 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

Beispiel3-1 Fallbeispiel "DMS": Lastenheft Die Anschaffung eines Dokumenten-Management-Systems bei den Steinbachwerken war bei den verschiedenen Beteiligten mit sehr unterschiedlichen Vorstellungen und Erwartungen verbunden. Dazu gehörten überspitzt formuliert Positionen, wie: "Wir schaffen eine DMS-Software an und dann gibt es in Zukunft keine Probleme mehr mit der Ablage und dem Austausch von Dokumenten." Oder: "Neben den Problemen, die wir jetzt schon mit der Dokumentenablage und -suche an der Backe haben, werden wir uns in Zukunft auch noch mit den Formalitäten des DMS herumplagen müssen." Um derartig gegensätzliche Positionen zusammen zu bringen, wurde zunächst ein Lastenheft erstellt, das die Anforderungen an das neue System beschreiben sollte. Während zu-

76

3 Projektgründung nächst noch die Erwartung vorherrschte, dass es im Wesentlichen um die Anschaffung eines Software-Werkzeugs ging, wurde schon in den ersten Sitzungen erkannt, dass dessen Einführung in den betroffenen Abteilungen einen beträchtlichen Zeitaufwand erfordern würde. Im weiteren Verlauf wurde klar, dass auch die bestehenden Arbeitsprozesse im Umgang mit den Dokumenten untersucht und geändert werden mussten. Erst durch diesen Erkenntnisprozess konnte die Bedeutung und der Umfang des geplanten Projekts erfasst werden. Auch im Lastenheft kam die Bedeutung der Umgestaltung der Arbeitsprozesse als wichtiger Projektbestandteil zum Tragen. Im Wesentlichen setzte sich das Lastenheft aus den Anforderungen an die neuen Arbeitsprozesse und den Anforderungen an das anzuschaffende Tool zusammen. Dies führte zu folgender Gliederung des Lastenhefts. 1. Einführende Übersicht 1.1. Derzeitige Datenhandhabung und -ablage 1.2. Übersichtliche Beschreibung des Ziel-Zustand 1.3. Grundlegende Randbedingungen und Zielkriterien 2. Anforderungen an das Dokumentenmanagement 2.1. Dokumentenkategorien 2.2. Verwendete Software-Tools 2.2. Beschreibung der Arbeitsabläufe 2.3. Normen, -Richtlinien, Vorschriften fiir die Dokumentenhandhabung 3. Das DMS-Tool 3.1. Benutzertypen und Benutzerschnittstellen 3.2. Benötigte Funktionen des Tools 3.3. Software-Schnittstellen zu anderen Werkzeugen 4. Projekt-Anforderungen 4.1. Bedingungen fiir die Projektdurchführung 4.2. Beschreibung der Testbedingungen 4.2. Vertragskonditionen (Termine, Gewährleistung, Berichte, Dokumentation) 4.3. Test, Inbetriebnahme, Abnahme, Service

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-2 LastenheftlPflichtenheft fiir den Einsatz von Automatisierungssystemen Die Überlappung von Lastenheft und Pflichtenheft kommt bei der Mustergliederung fiir den Einsatz von Automatisierungssystemen gemäß VDI-NDE-Richtlinie 3694 zum Ausdruck: 1. Einführung in das Projekt 2. Beschreibung der Ausgangssituation (Ist-Zustand) 3. Aufgabenstellung (Soll-Zustand)

3.2 Projektauftrag

77

4. Kommunikationsschnittstellen 5. Anforderungen an die Systemtechnik 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 Kapitel 1 bis 8 bilden das Lastenheft. Das Pflichtenheft ergibt sich als dessen Fortschreibung in den Kapiteln 9 und 10. Diese Mustergliederung zeigt sehr deutlich die enge Zusammengehörigkeit beider Dokumente. In der Baubranche regelt und standardisiert die Vergabe- und Vertragsordnung für Bauleistungen (VOB) die Schnittstelle zwischen Auftraggeber und Auftragnehmer. Der Auftraggeber listet in einem Leistungsverzeichnis alle gewünschten Leistungen auf. Diese Liste übernimmt daher die Aufgabe eines Lastenheftes. Der Auftragnehmer füllt die Preisspalte im Leistungsverzeichnis aus, ergänzt es durch individuelle Abweichungen und Lieferbedingungen. Das ausgefüllte und ergänzte Leistungsverzeichnis, das der potentielle Auftragnehmer als Angebot abgibt, stellt dann das Pflichtenheft dar. Beispiel3-3 Leistungsverzeichnis bei einem Bauprojekt Die folgende Aufstellung zeigt auszugsweise das Leistungsverzeichnis für die Arbeiten eines Zimmermanns für ein Wohnhaus. Tabelle 3.1 Leistungsverzeichnis bei einem Gewerk eines Bauprojekts Pos.

Anzahl

Bezeichnung

I

14m

Bauholz frei Baustelle liefern

2

800m

Bauholz verzimmern und richten

3

60 Stk:.

Sparrenköpfe hobeln und lasieren

4

100m

NuHFederschalung liefern und montieren

5

50kg

Nägel und Kleineisenzeug

3

2

Einzelpreis

Gesamtpreis

Summe

Jede Position beschreibt eine Leistungsanforderung mit der Art und Menge der Leistung. Der Anbieter kann nun aufgrund seiner Kalkulation seine Angebotspreise eintragen und das Ganze als Angebot abgeben. 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 (position 6 bis 8) ausgeschrieben werden. Sie gehen nicht in die Angebotssumme ein, werden aber herangezogen, wenn die entsprechenden Leistungen benötigt werden.

78

3 Projektgründung

3.2.3 Formale Anforderungen Das Lastenheft fasst die Anforderungen an ein Projekt zusammen. Ein mangelhaftes Lastenheft ist eine ideale Grundlagefür scheiternde Projekte. Um dies zu vermeiden, sollte ein Lastenheft 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 ein Lastenheft 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 das Lastenheft das falsche Forum. Eindeutige und widerspruchsfreie Forderungen machen die Aufgabe klar. Missverständnisse und Ärger am Projektabschluss wird 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 Nebenoder 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 fiihren. 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 Projektdurchfiihrung ist ein derartiger Grundsatz abzulehnen und durch das Qualitätsmerkmal der Realisierbarkeit zu ersetzen. Ein Lastenheft sollte also nur realistische Forderungen stellen. Unrealistische Forderungen fiihren 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 Lastenhefterstellung ü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 aufWiderspruchsfreiheit geprüft werden. Das Bestreben um Vollständigkeit fiihrt oft zu sehr langen Forderungslisten und die Sorge, bloß nichts zu vergessen, kann auch zu unnötigen Forderungen fiihren. Deshalb sollte 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.4 Auftragsdokumente So wie jedes Projekt ein Ergebnis liefern soll, das bestimmte Anforderungen erfüllt, muss auch jeder Projektauftrag ein Lasten- und Pflichtenheft enthalten. Darüber hinaus werdenfür einen Auftrag weitere Dokumente benötigt, die die Modalitäten der Projektdurchfiihrung regeln. Vergleichsweise einfach ist dies bei unternehmensinternen Projekten, bei denen also Auftraggeber und Auftragnehmer aus dem gleichen Unternehmen kommen. Beispiele hierfür könnte die Anschaffung einer neuen Maschine, die Umorganisation bestimmter Arbeitsabläufe oder die Modernisierung des Bauteilelagers in einem Unternehmen sein. Vor dem detaillierten Las-

3.2 Projektauftrag

79

ten- und Pflichtenheft wird man hier eine schriftliche Projektdefinition erstellen. Sie soll in knapper Form die wichtigsten Aspekte des Projekts zusammenfassen. Beispiel3-4 Fallbeispiel "CAD-Software": Projektdefinition Das folgende Bild zeigt die Projektdefinition für das Fallbeispiel "CAD-Software".

Projeki-Defillitioll

STEillBACHWERKE AG

Thema: Projektdefmition

Verfasser: Theisen I Datum: 29.6.2009 Verteiler: T. Steinbach, K. Steinbach, Theisen, Wulff, Baumann, Eiseie Schlagworte: Konstruktion, Software, CAD Gliedenmgsmerkmale: Internes Pro;ekt, Investitionsprojekt

Pro i ektinhalt Aus~situation:

Ziele: ProjektbeschreilnUlg:

Kritische Faktoren:

Das derzeit vet"1Nendete CAD-System wurde abgekündigt. Deshalb soll ein neues angeschafft werden. Mindest-Funktionsumfang wie das alte System Import bestehender Zeichungs-Dateien unbedingt erforderlich. Proiektlaufzeit max. 5 Monate. Die benötigten Funktionen müssen von den Nutzem des derzeitigen Systems zusammengestellt werden. Dann muss eine Marktübersicht in Frage korrunender Systeme erstellt und die 2-3 besten Systeme eingehender untersucht werden. Das favorisierte System wird in einem Probebetrieb getestet, bevor es in der Abteilung ein geführt wird. Möglichst schnelle Auswahl und Einfuhrung des Systems. Einarb eitungsaufwand und Kompatib ililät

Bud.-aet:

O. Projektbeginn 1. Vorauswahl von 2-3 Kandidaten 2. Entscheidung für 1 System 3. Ende Probebetrieb 4. Ende der Einführungsphase und Proiektende 50 Tsd €und 6 Personenmonate

Projektbeteili.-c:rte Auftrag,...aeber: Projektleiter: Proiektteam:

Ges chäftsleitung Theisen Wulff Baumann. Eiseie

Meilenste~:

BUd 3-3 Projektdefinition für das Projekt "CAD-Software"

Die Projektdefinition fasst die wichtigsten Informationen zum Projekt in knapper Form zusammen. Dabei wurde das Muster-Formular aus dem Anhang verwendet.

80

3 Projektgründung

Um sich bei der Projektdefinition tatsächlich auf die wichtigsten Aspekte zu beschränken, ist es sinnvoll, den Umfang strikt z. B. auf nur eine Seite zu begrenzen. Die Ziele und Bedingungen des Projekts müssen dabei nicht vollständig ausformuliert werden, sondern sie können in stichpunktartiger Form festgehalten werden. 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. 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. In einem allgemeinen Teil kann ein Anbieter die wesentlichen Bestandteile seines Angebots in knapper Form zusammenfassen und seine spezifischen Kompetenzen hervor heben. 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 bereits erwähnte VOB in der Baubranche oder die Verdingungsordnung für Leistungen (VOL) des Wirtschaftsministeriums für öffentliche Aufträge. Auftrag Auftrag-

I

r-- ~ Ausschreibung [ Lastenheft

geber

~

- IAngebot [ Pflichtenheft

I I

I~ I

I

I I I I I I I

Auftragnehmer

IHI

I

I I I I I

f--M Auftragserteilung t---+-"

j

Bild 3-4 Auftragsdokumente

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,

3.2 Projektauftrag

81

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 Auftraggeber 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 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-5 Angebotsgliederung Die folgende Auflistung skizziert die Struktur eines Angebots [Bindei 2009]. 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. 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.

3 Projektgründung

82

3.3 Projektkalkulation " Wer nicht rechnen kann, wird nicht reich; wer rechnen kann, wird nicht arm. " ( Sprichwort)

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 Projektka1kulation 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 Wettbewerber 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 Auftragerteilung 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. : optimistischer

;I unbekannter

pessimistischer :

: Schätzwert

: wahrer Wert

Schätzwert :

I

geringer

hohes Risiko

Aufwand

sicherer Auftrag

t

kein Risiko kein Auftrag Schätzbandbreite

großer Aufwand Bild 3-5 Das Aufwands-Auftrags-Dilemma

I

3.3 Projektkalkulation

83

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.

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 so genanntes Leistungsverzeichnis vorzulegen. Dies ermöglicht es den Anbietern, mit überschaubarem Aufwand realistische Angebote zu erstellen. Dieses Verfahren besitzt für den Auftraggeber 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, z. B. ein oder zwei Wettbewerber in einer zweiten Runde zur Abgabe eines detaillierteren Angebots aufgefordert. In diesem Fall kann die Abgabe eines detailliert ausgearbeiteten 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

3 Projektgründung

84

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 (Vor-Analyse) 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.

I Projektstudie I Vorprojekt

I

Projekt

I

14----.-

PE9 I

IA

Y-E

I

zs

--~

I..E. . . . -I--=--R__

zs

li

I

V

I

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

zs

=> Pflichtenheft => Angebot => Machbarkeit !

=> Produkt

Bild 3-6 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. Gemäß DIN 69905 wird sie als Projektstudie bezeichnet. Gerade bei Forschungs- und Entwicklungs-Projekten mit hohem Innovationsgrad ist dieser Weg sinnvoll

3.4 Repetitorium 3.4.1 Checklisten Tabelle 3.2 Projektgründung 1.

Sind die wichtigen Projektziele hinsichtlich FunktionalitätJQualität, Kosten und Tenninen bekannt?

2.

Wer ist Auftraggeber und wer Auftragnehmer des Projekts?

3.

Existiert ein Lastenheft?

4.

Wurde ein Pflichtenheft erstellt?

5.

Existiert ein schriftlicher Projektauftrag...

... ... 6.

bei internem Projekt als Projektantrag und -genehmigung? bei externem Projekt als Angebot, Auftragserteilung und -bestätigung?

Nach welcher Methode und wie genau wurde der Projektaufwand kalkuliert?

3.4 Repetitorium

85

TabeUe 3.3 Inhalt von Lasten- und Pflichtenheft

1.

Einfiihrende Übersicht Wie sind die benötigten Funktionen derzeit realisiert (evtL gar nicht)? Was sind die Stärken und Schwächen der derzeitigen Lösung? Welche Funktionen sollen realisiert werden? Welches sind die Zielkriterien? Unterscheidung zwischen Muss-/Wunsch- und Abgrenzungskriterien?

2.

Die Produktspezifikation In welcher Umgebung wird das Produkt eingesetzt? Mit welchen anderen Systemen ist eine Interaktion erforderlich? Über welche Schnittstellen erfolgt die Interaktion? Welche Funktionen muss das Produkt zur Verfügung stellen?

3.

Die Rahmenbedingungen für den Einsatz des Produktes Beschreibung der Einsatzfälle, der Einsatzszenarien und der Benutzertypen. Welche NormenlRichtlinien müssen (sollen) erfüllt werden?

4.

Die Rahmenbedingungen für die Durchfiihrung des Projektes Welche Anforderungen muss der Auftragnehmer erfüllen (Zertifizierung etc.)? Laufzeit und wichtige Meilensteine des Projektes Anforderungen an Test, Inbetriebnahme, Service

3.4.2 Verständnisfragen 1. 2.

Was beschreibt das ,,magische" Projektdreieck? Aus welchen Dokumenten besteht ein Projektauftrag?

3.

Beschreiben Sie Inhalt und Form einer Projektdefinition!

4.

Was versteht man unter einem Lastenheft?

5.

Was versteht man unter einem Pflichtenheft?

6. 7.

Welche Qualitätsanforderungen müssen Lastenhefte erfüllen?

8. 9.

Was ist ein Leistungsverzeichnis? Welche Aussagen sollte ein Angebot enthalten?

10. 11. 12. 13.

Was bedeutet der Zusatz "freibleibend" bei einem Angebot? Nach welchen weiteren Kriterien können die Anforderungen an ein Projekt gegliedert werden? Ordnen Sie die Kapitel eines exemplarischen Lastenhefts den 3 Inhaltskategorien zu! Für welchen Projektschritt bildet das Lastenheft die Eingangsgröße?

14.

Wie äußert sich das Aufwands-Auftrags-Dilemma und wie kann es gelöst werden?

In welche 3 Kategorien können die Inhalte von Lastenheften eingeteilt werden?

86

3 Projektgründung

3.4.3 Übungsaufgaben Aufgabe 3-1 Projektauftrag Sommerfest Sie gehören zu einer Arbeitsgruppe mit 8 Mitarbeitern und Mitarbeiterinnen. Von Ihrem Gruppenleiter erhalten Sie die Aufgabe, in zwei Wochen ein Sommerfest für alle Mitglieder der Arbeitsgruppe und deren Angehörige zu organisieren. 1. Wie würden Sie die Projektaufgabe formulieren? 2. Welches sind die Projektziele? 3. Welches sind die beteiligten bzw. betroffenen Personen? 4. Welche Ressourcen werden benötigt? 5. Welche Arbeiten sind zu erledigen? 6. Wie groß ist der Aufwand für die Arbeiten? 7. Bis wann müssen die Arbeiten erledigt sein? 8. Welches sind die Randbedingungen des Projekts? 9. Welches sind die Gütekriterien des Projekts? 10. Worin besteht (für Sie) die Problematik des Projekts? 11. Was ist das System/Produkt, um das es im Projekt geht? 12. Wie kann die Qualität bewertet werden? 13. Was ist Projekt-Input und -Output?

Aufgabe 3-2 Solare Energieversorgung für ein Einfamilienhaus Sie sind stolzer Besitzer eines Einfamilienhauses. Die bestehende Ölheizung Ihres Hauses möchten Sie durch eine solare Energieversorgung erweitern. Diese soll zur Warmwasserbereitung und zur Heizungsunterstützung dienen. Die Wohnfläche des Hauses betrage ca. 150 m2 • Im Haus gibt es Räume mit Fußbodenheizung und Räume mit Radiator-Heizkörpern. Die verfügbare Dachfläche beträgt ca. 80 m 2 • Erstellen Sie eine detaillierte Gliederung für ein Lastenheft (nur die Gliederung!). Das Lastenheft soll als Grundlage für eine Ausschreibung dienen. Sie sind der Auftraggeber. Alles, was Sie haben wollen, dürfen Sie festlegen. Alles, was Sie nicht festlegen, realisiert der Auftragnehmer so, wie es ihm am besten passt. Aufgabe 3-3 Lastenheft amoR Sie sind Wissenschaftlicher Mitarbeiter an einer Hochschule. Ihnen stehen mehrere autonome mobile Roboterplattformen (vom Typ amoR) zur Verfügung. Diese bestehen aus einer mechanischen Tragkonstruktion mit einer Montageplattform der Abmessung 60·50 cm2 , 2 einzeln ansteuerbaren Antriebsrädern mit einer Drehwinkelerfassung, angetrieben über Servomotoren mit je 150 W Leistung, einer zweikanaligen Motorsteuereinheit, die über eine serielle Schnittstelle angesteuert wird, einer 12VDC/ SAh Akku-Stromversorgung. Ein amoR wiegt ca. 15 kg; das zulässige Gesamtgewicht beträgt 40 kg. Von Ihrem Vorgesetzten haben Sie den Auftrag erhalten, auf der Basis von amoR einen Laborversuch zu konzipieren, der die praktische Anwendung eines (beliebigen) im Studium vermittelten Lehrinhalts ermöglicht. Hierzu soll amoR mit entsprechenden Aufbauten (z. B. Sensoren, Aktoren, Elektronikbaugruppen, Rechnern) ausgestattet und zum Funktionieren gebracht werden. Zum Aufbau stehen Ihnen max. 5000 € und für ein Jahr bis zu 3 studentische Hilfs-

3.4 Repetitorium

87

kräfte (mit je 8 Stunden pro Woche) zur Verrugung. Erstellen Sie eine vollständige Aufgabenbeschreibung als Lastenheft zum Aufbau eines amoR-Laborversuchs! Funktionsbeispiele, die mit amoR realisierbar sind, können die Verfolgen einer Spur, das Erfassen und Ausweichen vor Hindernissen oder das Aufladen und Abladen von kleineren Obj ekten sein. Aufgabe 3-4 Projektdefmition Die Steinbachwerke begehen im nächsten Jahr ihr 75-jähriges Firmenjubiläum. Dieses Ereignis will der Seniorchef mit den Beschäftigten des Unternehmens und deren Angehörigen sowie ausgewählten Kunden angemessen feiern. Zusätzlich zu Ihren normalen Aufgaben erhalten Sie vom "Alten" den ehrenvollen Auftrag, das Projekt zur Organisation des Jubiläums zu leiten. Am nächsten Tag ruft Sie Stefan Steinbach, der dynamische Juniorchef, der wenig von einer "biederen" Feier hält, in sein Büro. Er möchte das Jubiläum fiir eine positive Außendarstellung in der Tages- und Fachpresse nutzen und die aktuellen Neuentwicklungen präsentieren. Er bittet Sie, eine entsprechende Projektdefinition zu erstellen.

Wie würden Sie diese formulieren? Als Vorlage können Sie das Muster einer Projektdefinition aus dem Anhang verwenden.

4 Projektorganisation " Organisation besteht darin, weder den Dingen ihren Laufnoch den Menschen ihren Willen zu lassen. " (Helmar Nahr) 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 eines Systems von Regelungen, durch das die Arbeitsleistung der Mitarbeiter auf die Unternehmensziele ausgerichtet wird. Überträgt man diese Beschreibung auf die Organisation von Projekten, so kann man folgende Definition vornehmen: Projektorganisation ist die Schaffung von Regeln, durch die die Arbeit der Projektbeteiligten aufdie 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 Aufbauorganisation " Wer glaubt, dass Projektleiter Projekte leiten, glaubt auch, dass Zitronenfalter Zitronen falten. " (Unbekannter praxiserprobter Projektbeteiligter)

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 den meisten 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

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6_4, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

89

4.1 Aufbauorganisation

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. U: Unternehmensleitung

V: Vertrieb E: Entwicklung F: Fertigung K: Kaufmännischer Bereich Bild 4-1 Organigramm eines Unternehmens

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 folgende Werte: Tabelle 4.1 Zusammenhang zwischen der Zahl der Hierarchieebenen und der Mitarbeiter Ebenen

1

2

3

4

5

6

7

Mitarbeiter

1

7

50

350

2.000

15.000

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 sollten daher ausgeschlossen sein.

4.1.2 Formen der Autbauorganisation 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 Untemehmensstrukturen 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 zu klären, welche Weisungsbefugnisse ein Projektleiter gegenüber den einzelnen Projektmitarbeitern besitzen soll. Die Bandbreite der Befugnisse reicht hierbei von vollständiger

90

4 Projektorganisation

Weisungsbefugnis, über eingeschränkte, z. B. rein fachliche Befugnisse bis hin zur EinflussBefugnis, die manchmal auch zu einem "guten Zureden" mutiert. Die Befugnisse des ProjektIeiters 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 Leistungfü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 eine reine Proj ektorganisation.

Bild 4-2 Reine Projektorganisation

Die Projektmitarbeiter werdenfü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 Mitarbeiterfü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?

4.1 Aufbauorganisation

91

Aufgrund der beschriebenen Probleme und auch aufgrund des größeren Aufwands zur Bildung einer reinen Projektorganisation ist diese nur bei länger laufenden und großen Projekten empfehlenswert. Beispie14-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. 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 (Reine PO). Eine zweite Form der Organisation findet man, wenn die fachliche und die disziplinarische Weisungsbefugnisse voneinander getrennt werden. Die im Projekt tätigen Mitarbeiter bleiben disziplinarisch in ihren jeweiligen Bereichen, werden aber der fachlichen Weisung des ProjektIeiters unterstellt. Stellt man die disziplinarische Weisung senkrecht und die fachliche waagerecht dar, erhält man eine matrixförmiges Organigramm, weshalb man auch von einer MatrixProj ektorganisation spricht.

Bild 4-3 Matrix-Projektorganisation

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. 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.

92

4 Projektorganisation

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.

Bild 4-4 Aufuags-Projektorganisation

Eine weitere Abschwächung der Befugnisse des Projektleiters :führt zur Einfluss-Projektorganisation. 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.

Bild 4-5 Einfluss-Projektorganisation

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 Aufgabentrennung zwischen den Bereichen unstrittig ist. Um der Funktion des Projektleiters genügend Gewicht zu verleihen, wird die Position im Organigrarnm als Stabsstelle eingebaut, die direkt der Unternehmensleitung unterstellt ist. Daher wird oft auch von einer Stabs-Projektorganisation gesprochen. Es ist auch denkbar, die Vorteile der Linienorganisation und der reinen Projektorganisation zu kombinieren, indem man einen Bereichsleiter gleichzeitig zum Projektleiter macht. 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 und man spricht von einer Projektleitung in der Linie.

4.1 Aufbauorganisation

93

Bild 4-6 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. Diese Bedingung ist bereits in der einfachen graphischen Darstellung erkennbar. Die Weisungen innerhalb der eigenen Abteilung sind für den Projektleiter, der ja sowieso schon Linienleiter ist, unproblematisch. Seine Weisungen zu den Projektmitarbeitern aus anderen Abteilungen müssen aber gesondert definiert werden. Beispiel 4-2 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 eine 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 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 DiscounterProjekt wohl nicht permanent benötigt, da der größere Teil der Projektarbeit, nämlich die Anlagenerrichtung, von externen Unternehmen ausgeführt wird.

94

4 Projektorganisation

Beispiel 4-3 Fallbeispiel "DMS": Autbauorganisation Für das geplante Projekt zur Auswahl, Anschaffung und Einführung eines DokumentenManagementsystems bei den Steinbachwerken, soll eine geeignete Autbauorganisation festgelegt werden. Mit dem DMS sollen die Abteilungen Einkauf, Produktion, Montage, Entwicklung und Service arbeiten. An der Spezifikation der Anforderungen und auch an der Systemeinführung müssen alle diese Abteilungen beteiligt werden. Ein DMS ist ein rechnergestütztes Werkzeug, also ein IT-Produkt, so dass Fachkenntnisse in diesem Bereich im Projekt benötigt werden. 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 berücksichtigt werden müssen. 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.

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 (im Wesentlichen der Personalaufwand) und die Schnittstellenzahl, d. h. das Ausmaß, in dem unterschiedliche Abteilungen an einem Projekt beteiligt sind. Je größer die Projekte 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 folgende Diagramm. Bei kleinen Projekten mit wenig bereichsübergreifenden Schnittstellen wird der Leiter des Bereichs, aus dem die meisten Projektmitarbeiter kommen Projektleiter. 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.

4.1 Aufbauorganisation

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

Projektgröße und -bedeutung Reine PO

V

groß

I

/ I

Auftrags-PO V+F

Matrix-PO F

I I

/ I

I~

-_

I I -

klein

Linie-PO V+E niedrig

~

/

_!

;'

Einfluss-PO

E

hoch

Schnittstellenanzahl und -bedeutung

Bild 4-7 Abhängigkeit der Organisationsfonn von Projektgröße und Schnittstellenzahl

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 aufProjektbeteiligte 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-4 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 HardwareEntwickler und ein Software-Entwickler dauerhaft im Projekt arbeiten sollen. Aus den Abteilungen 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.

96

4 Projektorganisation

Beispiel4-5 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 Autbauorganisationsform ist hier geeignet? An dem Projekt sind mehrere 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 niedriger 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 (5 - 10 %) 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 ein externer Fachmann, der bereits Erfahrungen mit QMS besitzt, auf eine zeitlich befristete Stabsstelle berufen.

4.1.4 Projektbeteiligte Jeder im Projekt Beteiligte ü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 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 !MV-Matrix, in der jedem Beteiligten seine entsprechende Rolle bei den Arbeiten zugewiesen wird [Kraus 2004]. Die !MV-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.

Beispiel4-6 IMV-Matrix In der dargestellten !MV-Matrix 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?

97

4.2 Ablauforganisation Tabelle 4.2 Beispiel einer IMV-Matrix

Beteiligte

A

B

C

D

E

F

M

M

M

I

Arbeita

V

M

Arbeitb

I

V

Arbeit c

I

I

Arbeitd

I

V

I V

I M

I

M

I

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 und F ist wahrscheinlich Auftraggeber. Bei den Arbeiten b, c, und d werden Projektleiter und Auftraggeber infonniert. Im Team gibt es eine verantwortliche und eine zu infonnierende Person. Vennutlich laufen die Arbeiten in der Reihenfolge b, c, d ab. 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: infonned). Darüber hinaus gibt es Vorschläge für weitere Rolle, wie z. B. unterstützende Personen (S: supportive) oder Personen, die die Ergebnisse der Arbeiten verifIzieren (V: verifying). 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 und benötigten Personen für das Projekt, für die Teilprojekte und die Arbeitspakete festgelegt und dokumentiert werden.

4.2 Ablauforganisation " Ordnung ist das Durcheinander, an das man sich gewöhnt hat. "(Robert Lembke)

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.

98

4 Projektorganisation Beispiel 4-7 Arbeitspakete bei der Entwicklung eines elektrischen Messgeräts Die Anfertigung einer Gehäuseskizze. Das Erstellen des Layouts einer Platine anband 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. Der Test einer Funktion zur Berechnung des CRC-Bytes für ein Datentelegramm. Die Verdrahtung eines Schaltschranks. Die Analyse eines Lastenhefts auf technische Machbarkeit.

Ein Arbeitspaket wird immer einer verantwortlichen Person zugeordnet, es besitzt einen klaren Start- und Endtennin und es liefert zum Endtennin 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.

Ein Arbeitspaket besteht aus Arbeiten, die fUnktionell und zeitlich sehr eng zusammengehören und von einer Person ausgeführt werden. Es stellt aus Sicht des Projektmanagements die kleinste betrachtete Aktivitätseinheit dar. Der typische Umfang eines Arbeitspakets liegt zwischen I 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 « I 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 Ausfiihrungsebene in die Projektmanagementebene sichergestellt ist. Mehrere Arbeitspakete, die funktionell oder zeitlich eng miteinander gekoppelt sind, werden auf der nächsten 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-8 Fallbeispiel "Maschinenterminal": Typische Teilprojekte Im Projekt zur Entwicklung des Maschinentenninals, 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, Erstellung eines PCB-Layouts, 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. Mus-

99

4.2 Ablauforganisation

teraufbau des Gehäuses, Test der CPU-Platine, Test der IO-Platine, Funktionstest der Software-Module, Integrationstest und Systemtest könnten zum Teilprojekt "Test" zusammengefasst werden. 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 ProjektmanagementAktivitä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. Tabelle 4.3 Gliederung von Projekten unterschiedlicher Größe auf mehreren Ebenen Projektgröße

Untergliederung

50 ... 500 PJ

Groß-Projekt

5 ... 50 P]

Teilprojekte

Mittleres Projekt

0,5 5 P]

Teilprojekte

Teilprojekte

Kleines Projekt

0,5 ... 5 PM

Teilprojekte

Teilprojekte

Teilprojekte

1 ... lOPT

Arbeitspakete

Arbeitspakete

Arbeitspakete

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 Teil-Prozessen.

100

4 Projektorganisation

Jeder Teilprozess 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 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 sauberen Projektorganisation mit den praktischen Zielen kurzer Projektlaufzeiten miteinander in Einklang gebracht.

Eine Projektphase ist ein zeitlich abgegrenzter Teil eines Projekts. Sie kann ein oder mehrere Teilprojekte umfassen. Anfangs- und Endzeitpunkt einer Projektphase stellen Meilensteine dar. Jede Projektphase muss abgeschlossen sein, bevor die nächste beginnen kann. 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ütbar. 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. Kann 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, falls die verlorene Zeit nicht wieder hereingeholt werden kann auch der Endtermin des Projekts. Bei noch gravierenderen Problemen könnte auch das Abbrechen 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.

Ohne die Trennung der Projektphasen durch Meilensteine werden derartige Entscheidungen oft immer wieder aufgeschoben. Typische Auswirkungen nicht getroffener, notwendiger Entscheidungen sind das lautlose Versickern, das ewige Dahinplätschern oder das ergebnislose Beenden. Ein solches Verhalten im Projekt führt zumindest zu drastischen Terminüberschreitungen, viel zu oft aber auch zu gescheiterten Projekten. Beispiel 4-9 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 StandardAblaufstruktur 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 Ist-Zustand 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 Ent-

4.2 Ablauforganisation

101

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. Tabelle 4.4 Leistungsphasen nach HOAI Nr,

Phase

1.

Grundlagenermittlung

2

Vorplanung

3 4

Genehmigungsplanung

5

Ausfiihrungsplanung

6

Vorbereitung der Vergabe

Entwurfsplanung

7

Mitwirkung bei der Vergabe

8

Objektüberwachung

9

Dokumentation

Aufwand

3% 7% 11% 6% 25% 10% 4% 31 % 3%

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 im Durchschnitt in den 9 Leistungsphasen anfiillt.

4.2.2 Standard-Ablaufstruktur Projekte in unterschiedlichen Anwendungsgebieten führen natürlich auch zu unterschiedlichen Ablaufstrukturen und Projektphasen. Dennoch ist es mit Hilfe einer gewissen Abstraktion möglich, Projektphasen zu definieren, die in sehr vielen Projekten auftreten, wenn auch vielleicht mit unterschiedlichen Bezeichnungen. 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 Schritten, die in gleicher Weise aufeinander folgen; Problemanalyse - Lösungsentwurf - Realisierung - Validierung. 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.

102

4 Projektorganisation

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 dann 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 erreichte Realisierung tatsächlich eine Lösung des Problems darstellt, ob die vorgegebenen Randbedingungen eingehalten und das Gütekriterium tatsächlich optimiert wurde.

Bild 4-9 In Phasen gegliederte Standard-Ablaufstruktur ("Wasserfallmodell")

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, 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. 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 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.

103

4.2 Ablauforganisation

4.2.3 Varianten von Ablaufstrukturen In der idealisierten Betrachtungsweise mit zeitlich sauber getrennten Phasen und genau definierten Übergabeschnittstellen ist kein Platz für Überlappungen, wie sie in der Praxis fast unvermeidbar sind. Ein realitätsnahes Ablaufmodell erschließt sich aber bei genauer Betrachtung.

Jede Projektphase besteht nämlich nicht nur aus mehreren einzelnen Arbeitspaketen, sondern bei den Paketen gibt es auch eine gewisse Prioritätsverteilung. So gibt es z. B. in der Analysephase Arbeiten, die von grundlegender Bedeutung für das Gelingen des Projekts sind und daher möglichst früh durchgeführt werden. Andere Analyse-Arbeiten werden zwar für den Feinabgleich benötigt, können aber bei Bedarf nach hinten geschoben werden. So wird man in jeder Phase zunächst die wichtigen ("groben") Arbeiten vornehmen, bevor man zu den ("feinen") Detailfragen übergeht. In allgemeiner Form kann man weiter unterteilen zwischen Grob-Analyse, -Entwurf, -Realisierung, -Validierung sowie Fein-Analyse, -Entwurf, -Realisierung, -Validierung. Bei noch genauerer Betrachtung sind möglicherweise weitere Unterteilungen möglich. Dies soll aber hier nicht weiterverfolgt werden, da die Art der Unterteilung vom konkreten Projekt abhängt und für die allgemeinen Erläuterungen an dieser Stelle nicht benötigt werden. II

III

IV

Bild 4-10 Unterteilung der Phasen in Grob- und Fein-Phasen

Außer einer feineren Untergliederung hat die Unterscheidung von Grob- und Fein-Phasen zunächst einmal nichts gebracht. Weder wurde inhaltlich etwas verbessert, noch konnte die Projektlaufzeit verkürzt werden. Die Auftrennung der 4 Phasen schafft aber neue Organisationsmöglichkeiten. Statt zunächst die Analyse vollständig abzuschließen, bevor mit dem Entwurf begonnen wird, kann man nach der Grob-Analyse mit dem Grob-Entwurf beginnen, um dann GrobRealisierung und Grob-Validierung anzuschließen. Nach Abschluss der Grob-Phasen folgen dann die jeweiligen Fein-Phasen.

Bild 4-11 Grob- und Fein-Phasen (A-E-R-V)

104

4 Projektorganisation

Wie die graphische Darstellung zeigt, bleibt die Gesamtdurchlaufzeit gleich. Trotzdem hat die Organisationsform der schrittweisen Verfeinerung einen großen Vorteil: Fehler, die in einer frühen Phase gemacht werden und daher weit reichende Konsequenzen haben, fallen früher auf. Sie können deshalb mit weniger Aufwand behoben werden oder aber bei ganz gravierenden Problemen kann das Projekt in einer frühen Phase abgebrochen werden, bevor immense Kosten aufgelaufen sind. In der Literatur ist diese Form der Ablauforganisation auch als Spiralmodell bekannt [Boehm 1988]. Dieser Name 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. Das Spiralmodell nutzt eine wichtige Beobachtung 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.

Bild 4-12 Spiralfönniger Ablauf mit mehreren iterativen Durchläufen

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. Deren Reduzierung ist das Ziel eines weiteren Ablaufmodells, des 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.

105

4.2 Ablauforganisation

kj

I

F~

I

IE1

I BQ

I

W'-LBJl.l1-----J~

~

A~

b.

Bild 4-13 Ablaufmit Simultaneous Engineering

Nach der Grob-Analyse wird z. B. nicht nur der Grob-Entwurf gestartet, sondern auch schon gleich die Fein-Analyse. Das gleiche passiert mit den anderen Projektphasen. Dies 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 Infonnationsaustausch zwischen den einzelnen Arbeitspaketen erforderlich. Ein simultanes Ausführen der Arbeiten erhöht natürlich das Risiko. Sollten z. B. in der GrobValidierung gravierende Fehler der davor liegenden Grob-Arbeiten festgestellt werden, wären die bis dahin erbrachten Fein-Arbeiten umsonst gewesen. Der Lohn für das erhöhte Risiko ist aber eine Reduzierung der Durchlaufzeit. Beispiel4-10 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. Man erhält somit 8 (kleine) Phasen. Die DurchlaufZeit beträgt hier 63 Arbeitstage. ®

1

g

Name GA

·Oauer

Start

Ende

2 tage 05.01.09 ... 106-:01.09 ...

Vor•••

T

2

FA

3

GE

3 tage 13.01.09 ... 15.01.09 ... '2

4

FE

12tage 16.01.09 ... 02.02.09 ... 3

5

GR

10 tage 03.02.09 ... 16.02.09 ... 4

6

FR

lHage 17.02.09 ... 06.03.09 ... :5

7

GoI

6tage 09.03.09 ... 16.03.09 ... 6

8

FV

12 tage 17.03.09 ... 01.04.09 ... 7

,n

Hage 07.01.09 ... 12.01.09 ... I

GA

2tage 05.01.09 ... 06.01.09 ...

10

FA

11

GE

4 tage 07.01.09 ... 12.01.0? 3tage 07.01.09 ... 09.01.09 ... 9

12

FE

12tage 13.01.09 ... 28.01.09 ... 10;11

13

GR

10 tage 13.01.09 ... 26.01.09 ... 10;11

14

FR

14 tage 29.01.09 ... 17.02.09 ... p;13

9

15 16

r

-

_GoI _ _6~ ~.01.09 "'105.02,~ ..::..- ~

FV

12tage 18.Q2.09 ... 05.03.09 ... 14;15

lJan 09 105

12

119

126

~

IFeb 09 102 109

I

16

123

IMrz 09 102 109

Ac 116

I ~

~ =. .":",,,., ~

I

I

... I

BUd 4-14 Screenshot eines Projektplans mit sequentieller und parallelisierter Ausfiihnmg

123

13

106

4 Projektorganisation An diesem einfachen Beispiel wird der laufzeitverkürzende Effekt von simultanem Engineering deutlich. Er wird durch zwei Maßnahmen erreicht. Erstens werden wie beim Spiralmodell 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.

Die folgende Tabelle fasst die wesentlichen Merkmale der drei Ablaufmodelle zusammen: Tabelle 4.5 Vergleich der Grundmodelle der Ablauforganisation Kriterium

Wasserfallmodell

Spiralmodell

Simultaneous Engineering

Ablauf

sequentiell

iterativ

parallel

Phasentrennung

ausgeprägt

schwächer

fehlt

Durchlaufzeit

lang

lang

kurz

Feststellung von Fehlern

Spät

früher

Spät

Aufwand f. Planung und Kommunikation

gering

mittel

hoch

Die beschriebenen Modelle des Projektablaufs stellen Grundformen dar, die nicht immer in Reinform auftreten. Je nach Anforderungen können die verschiedenen Strukturmerk:male 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.

Beispiel4-11 Fallbeispiel ,,Maschinenterrninal": 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. 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. Zur Verkürzung der Entwicklungszeit sollten am Markt verfügbare eingebettete SingleBoard CPU-Module im PC/I04-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

4.2 Ablauforganisation

107

Durchzugleser und die externen Steckanschlüsse untergebracht werden. Der benötigte Platz für die Elektronik: wurde mit 18·25·5 cm3 (L·B·lI) abgeschätzt. Die Stromversorgung sollte mit einem externen Steckemetzteil erfolgen. Durch die Entscheidung für eine standardisierte Haroware- und Betriebssystem-Plattfonn konnte die Software-Entwicklung sofort beginnen und auf einem Standard-pe durchgeführt und getestet werden.

Vorgangsname

Arbeä

EI Maschinenterminal M4

294 Tage

Grob-Analyse

5 Tage

Grob-Entwurf --g=--M-echanik

5 Tage[

Fein-Analyse Komponentenauswahl Aufbau

12 Tage

g Elektronik

116 Tage

--t---

Fein-Analyse

-

10 Tage

Scha~ungsentwurf

Prototypen-Aufbau+Test Redesign

15 Tage "f--

-

25 Tage I 8 Tage

-

Layout

10 Tage

Aufbau

10 Tage

Test

20 Tage

Dokumentation

18 Tage

g Software

---95 Tage I

Fein-Analyse

>--

10 Tage

Detail.Entwurf

15~el

Programmierung

40 Tage

Test

30 Tage

SVV-Dokumentation Benutzerhandbuch

g Validierung Funktionstest Systemlest

o Tage o Tage 45 Tage 20 Tage 25 Tage

I

i~

Bild 4-15 Projektplan Maschinentenninal 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.

108

4 Projektorganisation

4.3 Organisation der Informationsflüsse Information verhält sich zu Wissen wie eine handvoll Sand zu den Pyramiden von Gizeh. Im Laufe eines Projekts fallen sehr viele Informationen an, die von ganz unterschiedlicher Bedeutung sein können.

Beispiel4-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 auf9: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." 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 I 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. 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, SMS-Nachrichten, EMails, Besprechungsnotizen, Berichten, Zeitungs- und Zeitschriftenartikeln zu ertrinken droht. Aus praktischer Sicht muss jede Information neben ihrem Gehalt auch auf ihre Relevanz überprüft werden.

4.3 Organisation der Informationsflüsse

109

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 Stomierung 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. Beispiel4-13 Informationskategorien Die folgende Einteilung bildet 5 Informationskategorien, die sich nach ihrer Wichtigkeit bzw. Auswirkung auf das Projekt unterscheiden. Tabelle 4.6 Bildung von Informationskategorien Kat.

Art der Information

Zu informieren:

Reaktion

11

Informationen, die den Erfolg des gesamten Projekts geflihrden können

Auftraggeber + Projektleiter

Krisensitzung mit Auftraggeber

12

Informationen, die eine Verzögerung oder Mehraufwand nach sich ziehen

Auftraggeber + Projektleiter

Projekt-interne Krisensitzung

13

Informationen, die das gesamte Projektteam betreffen

ProjektIeiter + gesamtes Team

Auf regelmäßiger Projektsitzung behandeln

14

Informationen, die mehrer Projektbeteiligten betreffen

Projektleiter + alle Betroffenen

Besprechung der Betroffenen

15

Informationen, die nur einen Projektbeteiligte betreffen

Betroffener

Bearbeitung durch Betroffenen

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 (11-15) zu berücksichtigen. 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

110

4 Projektorganisation

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. Der dritte grundlegende Baustein des Informationsmanagements ist die Dokumentation, d. h. die dauerhafte Ablage der Informationen fiir einen späteren Zugriff. Ein 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. 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 oft vergebliches Unterfangen. Durch die Einführung von Rechnern konnten Informationen auch in elektronischer Form erstellt, verteilt und gespeichert werden. Dadurch nahm der Informationsfluss sowohl 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 fiir 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 vielfl:ihige 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.

4.3 Organisation der Informationsflüsse

111

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 konununizieren 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 konunt 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 bestinunen.

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 Abfolge eines Projekts kann man folgende Dokumentenarten unterscheiden: • • • • •

Auftragsdokumente Organisationsdokumente Planungsdokumente Steuerungsdokumente Abschlussdokumente

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, die 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 Sanunlung 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 inuner wirksam.

112

4 Projektorganisation

Organisationsdokumente

Planungsdokumente

Organigramm Liste der Projektbeteiligten Ressourcenhste IMV-Matrix PM-Handbuch

Auftragsdokumente Anfrage Lastenheft Pflichtenhaft Angebot Auftrag Projektantrag Änderungsantrag Projektdefinition (F) Kalkulationsunterlagen

t

---.,

Steuerungsdokumente

ArbeitspaketBeschreibungen Produktstrukturplan Projektstrukturplan Terminplan Meilensteinliste Kapazitätsplan Personaleinsatzplan Risikoanalyse

Besprechungsberichte (F) Statusberichte (F) To-Do-Listen (F)

1 t

f

Analyse + Entwurf

I

Realisierung + Validierung

Abschlussdokum.

f-

Abschlußbericht Übergabeprotokoll Nachkalkulation

I

allgemeine Projektdokumente Projekt-Daten-Sammlung "dunkle Information"

Bild 4-16 Dokumentenarten in einem Projekt (F: Fonnular im Anhang)

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: • • • • • • •

TitelfThema 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 Gliederungsmerkmale, die zur hierarchischen Einordnung des Dokuments dienen

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 Projektidentiftkation 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

4.3 Organisation der Informationsflüsse

113

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 vielfliltige 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. 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 werden 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.

114

4 Projektorganisation

Beispiel4-14 Fallbeispiel ..CAD-Software", Besprechungsbericht Der folgende Screenshot zeigt einen Besprechungsbericht, der mit Hilfe des Formulars aus dem Anhang erstellt wurde.

Besprechullgsbel'icht

Steinbachwerke AG

Projekt: Einfühmng eines neuen CAD-Systerns Pro'ektleiter: Theisen Pro'ektidentdikatlon: SBW 4711 Thema: Ausweitung der Produktunterlagen Teilnehmer: Theisen, Wulff, Baumann, Eisele Termin: I Ort B371 I Uhrzeit 15:00 Verfasser: Eisele Verteiler: T Steinbach, K Steinbach + alle Teilnehmer

I Datum 6.102009

I Datum

7.10.2009

NI'. Inhalt

AJBJI

1

I

2

3

4

5

Von den angeschriebenen Anbietern einer CAD-Software haben bis jetzt 7 aus sage fähige Unterlagen gesandt. Zwei Anbieter liegen mit den Anschaffungskosten deutlich über 30 Tsd. €, so dass sie nicht weiter verfolgt werden. Von 4 Herstellern wurden bis jetzt gar keine bzw. nur sehr oberflächliche Unterlagen zur Verfügung gestellt. Aufgrund der schleppenden Reaktlon muss befürchtet werden, dass dies später beim Support nicht besser aussieht. Daher werden diese Hersteller nicht weiter berücksichtigt. Von der Konstruktion wird eine Liste mit allen benötigten Funktionen erstellt, dIe zur Auswertung der Unterlagen verwendet werden soll Die vorliegenden Unterlagen werden ausgewertet. Es wird ein Vergleich in Form einer Tabelle erstellt, in der die Anschaffungskosten, die Wartungskosten und die verfügbaren Funktionen gegenüber gestellt werden. Nächste Besprechung am 23.10.2010, 900 Uhr, Raum B371

B

A EiseIe 13. 10. A Baumann 2210

I

Bild 4-17 Screenshot eines Besprechungsberichts

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, einen Beschluss oder einen Auftrag handelt. Bei allen Aufträgen muss die verantwortliche Person und ein Erledigungstennin angegeben werden, 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. 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 ent-

4.4 Das Projektmanagement-Handbuch

115

hä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. 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.

4.4 Das Projektmanagement-Handbuch "Ein Buch ist wie ein Spiegel: Wenn ein Affe hinein schaut, kann kein Apostel herausblicken. " (G. C. Lichtenberg) Gemäß der Defmition 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, und wenn später, dann zu umso heftigeren 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 Erscheinungsformen, 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 Projekthandbuchs 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." In ihm werden also alle allgemeingültigen organisatorischen Regelungen zur Durchführung von Projekt festgehalten. Diese Regeln werden nicht nur für ein einziges Projekt aufgestellt, sondern gelten für alle Projekte in einem Unternehmen. Außerdem

116

4 Projektorganisation

enthält das PM-Handbuch vereinheitlichte Vorlagen für zu verwendende Dokumente. Ein umfangreiches Beispiel findet man in [Hilpert 2001, S. 181].

PM-Handbuch Projektorganisation

eAblauforganisation eAufbauorganisation

) )

( Informationsorganisation

)

Bild 4-18 PM-Handbuch als Output der Projektorganisation

Der Aufwand für die Erstellung eines PM-Handbuchs wird durch die erreichbaren Vorteile mehr als wett gemacht. 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 Aufbau- und einer 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.

Beispiel4-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 ZertiflZierung nach ISO 9000 überprüft. 1. Einleitung 1.1 Aufgaben und Anwendungsbereich des Handbuchs 1.2 Begriffsklärungen 1.3 Versionen des PM-Handbuchs 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 und Gremien 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.5 Repetitorium

117

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 Tenmnplä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 in einem 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 Regern 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 PMHandbuchs enthält alle Checklisten und einheitliche Vorlagen für alle Projektdokumente.

4.5 Repetitorium 4.5.1 Checklisten Tabelle 4.7 Checkliste Projektorganisation 1.

Welche Aufbauorganisation hat das Projekt?

2.

Gibt es eine Liste der Projektbeteiligten?

3.

Sind die Rollen (Aufgabe, Verantwortung) der Beteiligten festgelegt?

4.

Welche Ablauforganisation hat das Projekt?

Wie hoch sind die Schnittstellenzahl und die Größe des Projekts?

Stehen Aufwand, Kosten, Qualität im Vordergrund (Sequentialisierung)? Oder ist das Projekt sehr zeitkritisch (parallelisierung)? 5.

Gibt es ein PM-Handbuch?

4 Projektorganisation

118

Tabelle 4.8 Checkliste Infonnations-, Kommunikations- und Dokwnentenmanagement I.

Infonnation Welche Infonnation ist relevant? Für wen ist die Infonnation relevant? Was ist als Reaktion auf die Infonnation zu tun?

2.

Kommunikation Wie erreicht die Infonnation den Empfänger? Ist eine Rückmeldung erforderlich? Wie erfolgt die Rückmeldung?

3.

Dokwnentation In welcher Fonn werden Informationen dokwnentiert? Gibt es Vorlagen für die Projektdokwnente? Wo und wie erfolgt die Ablage? Wie erfolgt der Zugriff und wer besetzt welche Zugriffsrechte?

4.5.2 Verständnisfragen 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

Welche Formen der Aufbauorganisation gibt es für Projekte? Beschreiben Sie deren wichtigste Merkmale! Worin unterscheiden sie sich? Stellen Sie die verschiedenen Projektorganisationsformen in Abhängigkeit der Schnittstellenanzahl und Projektgröße in einem Diagramm dar! Was versteht man unter einem Arbeitspaket, einem Teilprojekt, einem Meilenstein und einer Projektphase? Was ist eine IMV-Matrix? Welche Ablaufmodelle gibt es? Was beschreibt das "Wasserfallmodell" und das "Spiralmodell"? Was versteht man unter Simultaneous Engineering? Erstellen Sie eine Vorlage für einen Projekt-Besprechungsbericht! Welche Informationen sollten in jedem Projektdokument enthalten sein? Was ist ein Dokument und welche Arten von Dokumenten entstehen In den verschiedenen Projektphasen? Worin unterscheiden sich Bericht, To-Do-Liste und Logbuch? Was ist ein Projektmanagement-Handbuch?

4.5 Repetitorium

119

4.5.3 Übungsaufgaben Aufgabe 4-1 Gliederung eines Projekts Der Ablauf für ein Projekt mit einem Arbeitsumfang von 20 Personenjahren soll entworfen werden. Wie würden Sie es hierarchisch gliedern?

Aufgabe 4-2 IMV-Matrix In einem Projekt soll ein Programm für die Firma Fabag entwickelt werden. Dazu sind verschiedene Arbeiten zu erledigen. Zunächst muss Anne das Pflichtenheft erstellen. Die Benutzerschnittstelle wird von Bernie programmiert und getestet. Chris erstellt das Hauptprogramm. Wenn diese beiden fertig sind, führt Doris den Gesamttest durch. Alle erstellen die Dokumentation. Projektleiter ist Ernie. Legen Sie für die beschriebenen Arbeiten und die Beteiligten (A bis F) die IMV-Matrix an. Denken Sie auch daran, das Gesamtprojekt als Arbeit mit aufzunehmen. Erläutern Sie Ihre Festlegungen.

Aufgabe 4-3 IMV-Matrix Die folgende Tabelle zeigt eine IMV-Matrix mit 6 Projektbeteiligten und 5 Arbeiten. Beteiligte Arbeit

A

B

C

I

a

D

E

F

M

V

b

I

I

c

M

I

M

V

M

d

V

I

I

I

M

I

V

I

M

e

I

V

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?

Aufgabe 4-4 Aufbauorganisation Das folgende Organigramm zeigt die Aufbauorganisation eines Unternehmens Stellen Sie eine Matrix-Projektorganisation graphisch dar!

120

4 Projektorganisation

Aufgabe 4-5 Aufbauorganisation

Um welche Projekt-Aufbauorganisationsform handelt es sich bei dem dargestellten Diagramm? Für welche Fälle ist diese Organisationsform vorteilhaft?

Aufgabe 4-6 Organisation des Entwicklungsprojekts für ein Navigationsgerät Der Hersteller von Fahrradzubehör hat die Vorstudie für das Entwicklungsprojekt des neuen Navigationsgeräts für Fahrräder abgeschlossen. Der Aufwand wird mit ca. 3 Personenjahren bei einer Laufzeit von 12 Monaten veranschlagt. Aus der Entwicklungsabteilung sollen ein Hardware-Entwickler und ein Software-Entwickler dauerhaft im Projekt arbeiten. Aus den Abteilungen Vertrieb, Produktion und mechanische Konstruktion wird je I Mitarbeiter zeitweise im Projekt benötigt.

Welche Aufbauorganisation soll für das Projekt gewählt werden? In wie viele Ebenen sollte das Projekt gegliedert werden?

5 Strukturplanung "Je planmäßiger die Menschen vorgehen, desto wirksamer vermag sie der Zufall zu treffen. " (Friedrich Dürrenmatt) Einen für den Erfolg oder Misserfolg eines Projekts ganz entscheidenden Schritt im Rahmen des Projektmanagements bildet die Projektplanung. Hier werden alle notwendigen Aktivitäten des Projekts, die zur Ausführung der Arbeiten benötigten Personen und Ressourcen, die erforderlichen Aufwände und die verursachten Kosten geschätzt, der Ablauf geplant und die wichtigen Termine festgelegt. Der Input der Projektplanung ist der konkrete Projektauftrag also das Lastenheft und das Pflichtenheft. Außerdem liegen der Projektplanung die Festlegungen zugrunde, die im Rahmen der Projektorganisation getroffen wurden. Sie regeln die personellen Strukturen, die Ablaufstrukturen und die Handhabung der Informationen.

Bild 5-1 Arbeitsschritte der Projektplanung

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6_5, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

122

5 Strukturplanung

Im Idealfall liegt am Ende der Projektplanung eine vollständige Liste mit allen Arbeitspaketen und deren Terminen, sowie der anfallenden Kosten und Aussagen über die Planungsrisiken vor. Damit der Weg von der mit vielen Unbekannten behafteten Ausgangssituation bis zur detaillierten und vollständigen Planung kein Zufallstreffer bleibt, ist eine aus mehreren Arbeitsschritten bestehende, systematische Vorgehensweise notwendig. Die einzelnen, aufeinander folgenden Planungsschritte führen dabei schrittweise zu einer zunehmenden Konkretisierung der Pläne. Die Planungsschritte beginnen mit der Analyse des Produkts und aller benötigten Teile. Es wird so weit in seine Bestandteile zerlegt, bis alle zur Entwicklung und Herstellung notwendigen Arbeitspakete erkennbar sind. Die Summe aller notwendigen Arbeiten bildet den Projektstrukturplan (Kapitel 5: Strukturplanung). Von ihm ausgehend werden dann die benötigten Zeit- und Kostenaufwendungen geschätzt (Kapitel 6: Projektschätzung). Anhand der fachlichen Beziehungen zwischen den Arbeiten und der Organisationsregeln für die Arbeitsabläufe, lassen sich detaillierte Ablaufpläne erstellen. Unter Berücksichtigung der verfügbaren Personen und Ressourcen können dann Zieltermine für die Arbeiten definiert werden (Kapitel 7: Ablauf- und Terminplanung). Den Abschluss der Planung bildet eine Analyse der Planungsrisiken (Kapitel 8: Risikomanagement).

5.1 Produktstrukturplanung 5.1.1 Der Produktstrukturplan Im Zentrum aller Aktivitäten sollte immer das angestrebte Projektziel stehen. 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. Deshalb sollten am Anfang der Planung der Projektgegenstand, also das abzuliefernde Produkt stehen. Das Produkt - egal ob es sich dabei um eine mechanische Konstruktion, ein elektrisches Gerät, ein Softwaresystem oder ein Gebäude handelt - besteht im Allgemeinen aus einer Vielzahl von Komponenten. Die Komponenten stehen untereinander in Wechselwirkungen und können hierarchisch gegliedert werden. Das gesamte System kann daher als baumartig gegliederter Produktstrukturplan dargestellt werden. Bei kleinen Systemen oder bei nur grober Auflösung lässt sich dieser Strukturplan in graphischer Form darstellen. Bei größeren Systemen und detaillierter Betrachtung wird die graphische Darstellung umfangreich und verliert an Übersichtlichkeit. Hier ist die Listenform besser geeignet. Die konkrete Struktur eines Produkts ist natürlich individuell sehr unterschiedlich. Bei einer mechanischen Konstruktion bietet 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

5.1 Produktstrukturplanung

123

diese Liste in der Planungsphase gestaltet sein muss. Da die Produktplanung die Vorarbeit für die Projektplanung bildet, bestimmt diese den Detaillierungsgrad. Ist bei einem Produktteil klar erkennbar, welche Arbeiten für dessen HersteUung 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. 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. Wohnhaus I 1.~grund I -

--

._ 1.1.1 Hausanschlüsse 1.1.1.IKanalanschluss 1.1.2. Wasseranschluss - ~ Fundamente 1.3. Bodenplatle

-

...

2. Rohbau

-

2.1. Mauerwerk 2.1.1.:- Keller 2.1.2. Erdqeschoß 2.1.3. Obergeschoß 22. ~ken

f-

...

--

I

Bild 5-2 Produktstrukturplan Wohnhaus (Auszug)

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 Detaillierungsebene 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. 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.

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

5 Strukturplanung

124

5.1.2 Vorgehensweise zur PlanersteIlung 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 immer weiter gedanklich zerlegt, bis man auf der Ebene elementarer Teile 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 dieser 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. 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 Zusammengehörigkeit 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.

Beispiel5-2 Fallbeispiel "Maschinenterminal": Produktstrukturplan Das Maschinenterminal aus dem Fallbeispiel soll eine einfache Benutzerschnittstelle mit Textdisplay und Folientastatur besitzen. Die Personenidentiftkation 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

5.1 Produktstrukturplanung

125

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.

__________....,> Top-Down

1. Gehäuse 2. Elektronik 3. Software

4. Zubehör

Maschinenterminal

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

<

2.2. Benutzerschnittstelle 2.2.1. Textdisplay 2.2.2. Folientastatur

Bottom-Up

_

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

Bild 5-3 Top-Down- und Bottom-Up-Ansatz zur Strukturierung

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. Maschinenterminal M4 1 Gehäuse Basisteil ---1.2. Deckel !1.3. Durchzug~ser 1.4. Wandhalterung 2. ~ktronik

1:1

-

.L!. QlJJ~~augru~~

- ! - - 2-.:.LLEC1 04-S ingle-Board- Co n)J:lu~r 2.2. Benutzerschnittstelle 2.2.1. LC-Textdis~~1. 2.2.2. Folientastatur '-2.2.3. Tastaturschaltung__ 2.3. Leseqeräteinterface serielle Schnittstelle - - 2.3.1. ---2.4. Ein-/Ausqänqe 1-41. 4 digitale Eingänge 0-30 VDC

3

-'-

's oft ware

"3:1:[Betriebssystern 3.1.1. DOS 3.2. Gerätetreiber 132.1. Tastaturauswertung in Puffer 3.2.2. Lese~erätetreiber vom Hersteller 3.2.3. Ansteuerunq Ein-/Ausgänge 32.4. JCP/IP-Stack

-

~Ter,,!inal ~f1'!.Il1

!.

I2.61N8iZtell__

- ~l ~,~entkartenleser

Tl2."6T 230 VAC

---

---

3.3.1. Zeit9.esteuerte Kommunikation 33.2. ~~esteuer1eTasta~rauswertung_ Zubehör 4.1. ~rcode-Durchzugleser 4.2. Barcode-Lesestift

- ,::-::/-.-,-4.0~_ 2 Re lais '!U s9än@..

2.5.i Rechnerschniltstelle I'2.5.1. ,Ethernet 100 Base.T (RJ45)

---

--

4.4. Chipkartenleser

Bild 5-4 Produktstrukturplan des Mascbinenterminals

_.

5 Strukturplanung

126

Das Ergebnis könnte, wie 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. 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 "Kein Plan überlebt die erste Feindberührung. " (Helmuth Grafvon Moltke)

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 Durchfiihrung 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 (eng!.: 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 befmden 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 Gesamt-Zusammenhang gesehen). 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. Der Projektstrukturplan selbst bildet die Basis für weitere Planungsschritte: die Erstellung des Terminplans, die Schätzung der Kosten und den Einsatz der Mitarbeiter und der Ressourcen. Produktstrukturplan Ablauforganisation

Erstellung Projektstrukturplan

Bild 5-5 Einordnung des Projektstrukturplans im Projektablauf

Projekt-

t---+j struktur-

plan

5.2 Projektstrukturplanung

127

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 einem Grob-Projektstrukturplan zu begnügen. Das Ergebnis der Grobstrukturierung ist ein grober 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, hoffentlich nicht zu 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 Projektdurchfiihrung 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 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 Projektdurchfiihrung erfolgen. Dieser Weg wird in kleinere Teilstücke 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 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

5 Strukturplanung

128

werden daher sinnvollerweise auch zusammenhängend im Projektstrukturplan dargestellt und geplant. Beispiel 5-3 Fallbeispiel ,,Maschinentenninal": Projektstrukturplan Für das Maschinentenninal, 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. !

I

BAnforderungsanalyse

Aufbau Laborprototyp

Schnittstellenanforderungen

Funktionstests + Schaltungsmodifikation

Denutzerschnittstelle

-

Rechner-Hardware-Anforderungen

- I--

Software/Betriebssystem

I

I----

J

L

-

Musteraufbau

Stromversorgung

BSoftware

E1Lösungsentwurf

DOS-Beschaffung

Grob-Lösungskonzepte Bewertung und Lösungsauswahl

-

- I----

Auswahl Lesegeräte -

~

Entwurf Benutzerschnittstelle

I----

Hardwarekonzept Anwendungselektronik

I

I

Marktübersicht Durchzugleser

Auswahl und Bestellung Durchzugleser

----

Auswahl und Bestellung Lesestift

BValidierung

Auswahl und Muster-Bestellung

E1Elektronik

1

Marktübersicht Lesestifte

---

Funktionstest Elektronik-Prototyp

-

Marktübersicht embedded-CPUs

- I----

Auswahl und Bestellung CPU-Baugruppe

rI

Programmerstellung zeitgesteuerter Date~ Programmerstellung Menüführung

Softwarekonzept

Marktübersicht Standardgehäuse

I

--

BZubehör

BGehäuse

.-1

Auswahl und Test eines TCP/IP-Stack

Entwurf Stromversorgung

BRealisierung

J

Test der Lesegrätetreiber

--

Programmierung Treiber EA-Ansteuerung

-

Hardwarekonzept CPU

I

Platinen bestellen Platinen bestücken

Gehäuseanforderungen

I

PCB-Layout

Klärung mit Hersteller Folientastatur ---

Auswahl und Bestellung Textdisplays

.

Schaltungsentwurf Anwendungsschaltung,

EMV-Tests Systemtest HW+SW

-

Komplettaufbau 5 Mustergeräte

- I----

I----

'--

Test 1"1ustergeräte im Netz Schulung Servicemitarbeiter Schulung Vertriebsmitarbeiter Probeeinsatz -

-

-

Bild 5-6 Projektstrukturplan Maschinentennina1

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 I Personenjahr.

5.2 Projektstrukturplanung

129

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 Arbeitspak.eten 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 er:fiillen. Hier sind die Funktionen einzelner Abteilungen, wie z. B. Vertrieb, Einkauf, Montage und Service eher 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-4 Fallbeispiel "Solaranlage": Projektstrukturplan Die bestehende Heizanlage im Büoogebäude der Steinbachwerke soll durch eine solarthermische Anlage unterstützt werden. Diese besteht aus Flachkollektoren, die auf der Maschinenhalle untergebracht werden, sowie einem neuen bivalenten Wännespeicher. Der vorhandene Öl-Brenner mit seiner Steuerung ist erst 7 Jahre alt und soll erhalten bleiben. r=:J

8

Vorprojekt

2

Bestandsaufnahme vor Ort

3

Grobe Bedarfsermittlung

4

Grobkonzepl

26

5

Grobe Marktanalyse

27

6

Angebot erstellen

7

8

Analyse und Entwurf

25

~

18

Aufbau Ausbau und Entsorgung ader Komponenten

I

Maurerarbeden für Ledungsführung

29

Gerüst aulstellen

3D

Montage der mech. Dachhanerungen

8

Detaillierte Bederfsenelyse

9

Detailkonzepl ausarbeden

31

Montage der Solarkollektoren

lD

Analgenpläne zeichnen

32

Einbeu Warmespeicher

11 12 13

Terminierten Ablaufplan entwerfen

8

Beschaffung

8

33

Anschluß eller thermischen Komponenten

34

Montage der elekIr . Ledungen

35

Einbeu Solarstelion

14

Solarkollektoren (ink!. Heder + Verbdinung)

36

Einbau Steuerung

15

Solermodul (ink!. Rohre)

37

Anschluß und Prüfung eller elektr. Komponenlen

16

Steuerung (ink!. Fühler + Ledungen)

38

Gerüst abbauen

17

Wasserspeicher

39

18

8

Genaue Marktanalyse

--

Einbau der Rohr-Ledungen

8

Dokumentation

40

Betriebsanledung

19

Solerkollektoren (ink!. Heder + Verbdiflung)

41

BedienungsBnledung

20

Solarmodul (Ink!. Rohre)

42

21

Steuerung (ink!. Fühler. Le.ungen)

43

Wasserspeicher

22

Einholung von Angeboten

Vllartungsvorschrift

8

Anlagentest

44

Befüllung und Dichligkeäsprütung

23

Erstellung Preisspiegel

45

Iobetrlebnahme

24

Bestellung

46

Einweisung des Betreibers

Bild 5-7 Projektstrukturplan der Solaranlage

-

130

5 Strukturplanung 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 das Ingenieurbüro Sunnyboy vergeben, das nach eigenen Angaben langjährige Erfahrungen mit Solaranlagen besitzt und dessen Geschäftsführer den Juniorchef der Steinbachwerke aus dem Golfclub kennt. Zusammen mit dem Angebot wird der auf der nächsten Seite 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. Sowohl die angebotene Anlage als auch der Preis fmdet 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.

Neben den beiden Grundformen des produkt- und des prozessorientierten Strukturplans findet man in der Praxis auch viele Mischformen, die 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 der Abbildung 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.

5.2 Projektstrukturplanung

131

I Proiekt

--I Teiloroiekt 1

Arbeitsoaket 1.1. Arbeitsoaket 1.2. Arbeitsoaket 1.3.

--I Teiloroiekt 2

I Arbeitsoaket 2.1. I Arbeitsoaket 2.2.

--I Teiloroiekt 3

I Arbeitsoaket 3.1. I Arbeitsoaket 3.2.

----------------------.-

I

-----------------------------.----.

I

Bild 5-8 Zuordnung der Arbeitspakete zu den Projektbeteiligten

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 zuflillig 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 Gemeinsamkeiten auftreten. Es ist daher erstrebenswert, die Gemeinsamkeiten in einem Standard-Projektstrukturplan zusammen zu fassen. 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 Vergessen einzelner Arbeitspakete. Außerdem lassen sich Erfahrungen mit vergangenen Projekten besser nutzen, um z. B. Kennzahlen für die Aufwandsschätzung zu bestimmen.

132

5 Strukturplanung Beispiel S-S 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 fiir manche Arbeiten im Entwicklungsprozess auffii.llig oft zu finden. Die von vielen Seiten erhobenen Vorwürfe wurden immer wieder mit Hinweis auf die Neuartigkeit der Projekte und die NichtVorhersagbarkeit 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. Die Obermenge der gemeinsamen Arbeiten wurde dann zu einem groben StandardProjektstrukturplan zusammengefasst. 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. B 1. Vorprojekt

I

I

1 .1 . Einarbeitung

4.1. Experimentelle

Testscha~ungen

1.2. Analyse Lastenheft

4.2. Schailungsentwurf

1.3. Erstellung Grob-Pflichtenheft

4.3. Leiterplatten-Design

1.4. Angebot

4.4. Hardware-Dokumentation

B 2. Konzeption

4.5. Fertigung Prototyp

2.1 . Detaillierte Anforderungsanalyse

4.6. Schailungs-Redesign

2.2. Erstellung Detailliertes Pflichlenhett

4.7. Fertigung Nullserie

2.3. Entwurf Gehäusekonzept

B 3. Mechanische Konstruktion

B 5. Software-Entwicklung 5.1 . Anforderungsanalyse

3.1. Konstruktion Gehäuse

5.2. Software-Entwurf

3.2. Aufbau Gehäusemuster

5.3. Programmierung Rapid Prototype

3.3. Gehäuseredesign

5.4. Software-Codierung

3.4. Herstellung Nullserie

5.5. Software-Tests

------

r

B 4. Hardware-Entwicklung

5.6. Software-Dokumentation

El 6. Tests 6.1 . Test Funktionseinheiten 6.2. Systemtest 6.3. Test Nullserie

Bild 5-9 Standard-Projektstrukturplan fiir die Entwicklung elektronischer Steuerungen

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, einige Arbeiten zu vergessen wird da-

5.2 Projektstrukturplanung

133

durch 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.

Beispiel5-6 Prozessleittechnik-Projekte Ein Prozessleitsystem zur Automatisierung verfahrenstechnischer Anlagen besteht aus einer Vielzahl vernetzter Sensoren, Aktoren, Regler und Steuerungsrechnern. Da jede 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 PLTProjekts 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 [Gutermuth 2007] als Standard-Projektstruktur dokumentiert. Tabelle 5.1 Phasen und Aktivitäten von PLT-Projekten Nr.

Phase

1.

Grundlagenermittlung

1%

2.

Vorplanung

6%

3.

Basisplanung z.B.

4.

6.

10% 45% 5%

Geräte festlegen Stellenfunktionspläne erzeugen

10%

Montageunterlagen erstellen

9% 24%

Software konfigurieren

10%

Funktionen prüfen

6%

Inbetriebsetzung z.B.

7.

19%

Errichtung z.B.

Aufwand

PLT-Funktionen festlegen

Ausführungsplanung z.B.

5.

Aktivität

4% 1%

Personal ausbilden

Projektabschluss

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 Projektund Qualitätsmanagement wurde dabei mit ca. 7 - 10 % beziffert und ist in den einzelnen Aktivitäten enthalten.

5 Strukturplanung

134

5.3 Repetitorium 5.3.1 Checklisten Tabelle S.2 Checkliste Strukturplanung 1.

Wurde der Produkt-Strukturplan erstellt?

2.

Wurde ein Projekt-Strukturplan erstellt?

3.

Gibt es einen Standard-Strukturplan?

I Wurde der Plan Top-Down oder Bottom-Up erstellt? I Ist er produktorientiert oder prozessorientiert aufgebaut?

5.3.2 Verständnisfragen 1.

2.

Was ist ein Produktstrukturplan? Was ist ein Projektstrukturplan?

3.

Worin unterscheiden sich der Top-Down-Ansatz und der Bottom-Up-Ansatz zur Erstellung strukturierter Listen?

4.

Worin unterscheiden sich die produktorientierte und die prozessorientierte Vorgehensweise zur Gliederung eines Projektstrukturplans?

5.

Wozu dient ein Standard-Projektstrukturplan?

5.3.3 Übungsaufgaben Aufgabe 5-1 Produktstrukturplan Fahrrad Erstellen Sie einen detaillierten Produktstrukturplan für ein Fahrrad! Wovon hängt es ab, ob der gewählte Detaillierungsgrad ausreicht? Aufgabe 5-2 Standard-Projektstrukturplan Erstellen Sie einen Standard-Projektstrukturplan für ein Ingenieur-Studium aus Sicht eines Studierenden! Welche Aktivitäten sind erforderlich? Wie können diese gegliedert werden? Wie würde hier eine produktorientierte bzw. eine prozessorientierte Vorgehensweise aussehen? Aufgabe 5-3 Produktstrukturplan Computer Gegeben ist die folgende grobe Gliederung der Produktstruktur eines Computers. 1. Mechanik 2. Elektrik

5.3 Repetitorium

135

3. Elektronik 4. Software 5. Geräte zur Eingabe, Ausgabe und Datenspeichenmg Führen Sie die Produktstrukturienmg auf der 2. Gtiedenmgsebene fort. Die Begriffe der 1. Gtiederungsebene sind bewusst relativ abstrakt gewählt. Konkretisieren Sie deren Bedeutung, um die Komponenten zuordnen zu können! (Beispiel: Gehört der interne Kabelbaum zur Mechanik oder zur Elektrik?) Aufgabe 5-4 Fallbeispiel "Solaranlage": Projektstrukturplan Gegeben ist der folgende Produktstrukturplan des Fallbeispiels Solaranlage. Versuchen Sie, aus Sicht des beauftragten Ingenieurbüros alle erforderlichen Arbeitspakete zu bestimmen, und gliedern Sie diese in einem produktorientierten Projektstrukturplan! ~

-~

-

c AI B I Solarthermie-Anlage ~Wärr~slem . 3 111 Flachkollektoren 4 1.2 mechanische Halterungen 5 11.3 Entlüfter ---6 114 ~valenter Wärmespeicher 1~1.5 Rohrleitung en Solars! ation-Kollektoren ~ _ 1.6 Rohrleitung~n Sjleicher-Solarsta.!lon 9 1.7 Solarllüssigkeit 10 2. ISolarstation 11 121 E-umpe 2.2 Manometer -13 2.3 Absperrhähne _ 124 B.9ckschlagklappen

+ -Z-

-

-E. ~

15 2.5 ~h.':l~!13lefäß 16 _I~ Füllhahn 17 2.7 ~nlleerhahn 18 2.8 Duchflußmesser 19 3. 1Steuerunq 20 131 Solarreqler

r

11- & _33

-

l

Temjleraturfühler Kollektor. Temperalurfühler Speicher ~ 23 3.4 elektrische Versorgung .1! 4. Handbücher 25 4.1 Bedienungsanleitung 4.2 Betriebsanleitunq 26 27 4.3 Wartungsvorschrift

Bild 5-10 Produktstrukturplan Solaranlage

---

6 Projektschätzung "Arbeit dehnt sich aus, bis sie die Zeit, die ihr zur Verfügung steht, vollständig ausfüllt. " (Cyril N. Parkinson)

6.1 Methodische Grundlagen des Schätzens "Besser ungefähr richtig als exaktfalsch. " (F.J. Strauß) 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 Schätzung 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. _ _----'Wl.ll..l.i:is... sJ;iJenl..1.-_> (siChere

AUSSage~

1--1 I

I

__

---lR~a::Llt.c.enl..1.-_ _>

I

unsichere Aussagen

I

keine Aussagen

Bild 6-1 Gewinnung von Aussagen aus verfügbaren Informationen

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 Verrugung 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 verrugbare Informationen zugänglich zu machen. Aber gerade dieser Aufwand macht aus einem unkalkulierbaren Vorhaben ein planbares und kontrollierbares Projekt.

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6_6, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

6.1 Methodische Grundlagen des Schätzens

137

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, belastbare Aussagen zu gewinnen. 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. Die Informationen sind oft nicht leicht zugänglich und oft auch nicht direkt, aber kein Projekt ist wirklich vollständig neu. 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. Auch wenn dies manchmal als nicht möglich oder zumindest als schwierig erscheint, ist es trotzdem nötig. 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 oft 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. 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

138

6 Projektschätzung

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, selten benötigte Zahl parat. Sie kann aber ohne Hilfsmittel auf verschiedenen Wegen geschätzt werden. Bei Frage nach Landfläche der Erde werden bei Teilnehmern in Projektmanagementkursen 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 die um den Faktor 1000 daneben liegenden Dimension "Tausend km2" und bei den anderen die passende Dimension "Millionen km2") kombiniert. Wird dagegen mehr Zeit zur Verfügung gestellt, 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. Bei 80 Mio. Einwohnern und einer (geschätzten) Fläche von 400 Tsd. km2 ist die Bevölkerungsdichte Deutschlands 200 Ew.1km2. 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

2

U2 40 = ).·1f·d2 = )..1f. ( -UJ2 ; =)..--;:dO %·-3-Mio. km 2 = 160 Mio. km 2

Ist der Erdumfang nicht bekannt, kann er eventuell aus anderen Informationen (z. B. dem Roman "In 80 Tagen um die Welt" (80 Tage, 10 Stunden/Tag, 50 kmIh)) abgeleitet werden. Das Beispiel der Landfläche zeigt einige 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 auszuwerten. 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 wer-

6.1 Methodische Grundlagen des Schätzens

139

den; 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 liefen 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 Skala 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. 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. Liegen Erfahrungen vor, ist diese vergleichende Anordnung mit Aussagen wie: "deutlich mehr Aufwand als PI ", "etwas weniger Aufwand als P6", "vergleichbar mit P4" oft leichter, als ein auf Zahlen basierendes Schätzen.

A7 A6 A5 A4 A3

A2. A1

P1

P2

P3

P4

P5

P6

P7

Bild 6-2 Qualitative Schätzung des Projektaufwands durch Vergleich

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. Dagegen sollte die Frage des ausführenden Unternehmens keinen so starken Einfluss haben. Ähnlich sieht es z. B. bei der Erstellung von Software-Systemen aus. Die zu erwartende Programmlän-

6 Projektschätzung

140

ge wird im Wesentlichen den erforderlichen Aufwand bestimmen. Für eine schnelle, aber grobe Schätzung wird der Einfluss eines einzigen, dominierenden Parameters betrachtet. A = Co . E o

(6.1)

Der Wert Co ist dabei eine Kennzahl, die den Einfluss der Größe Eo auf den Aufwand beschreibt. Beispiele für derartige Kennzahlen findet man in allen praktischen Anwendungen, wie z. B. im Maschinenbau (10 € pro kg bei Stahlkonstruktionen), im Hausbau (400 € pro m 3 umbauter Raum) oder bei der Software-Erstellung (3 Personenmonate pro 1000 Programmzeilen). Beispiel 6-2 Gebäudekostenschätzung Die folgende Tabelle zeigt die Kosten und Nutzflächen einiger unterschiedlicher Gebäude. Gebäude

Nutzfläche

Kosten

Kosten/m2

Taipeh 101, Hochhaus

412 Tsd. m

2

1600 Mio. €

3.900€

Burj Dubai, Hochhaus

517 Tsd. m

2

1400 Mio. €

2.700€

Dom Aquaree, Hotel, Berlin

67 Tsd. m2

340 Mio. €

5.100 €

Messeturm Frankfurt

61 Tsd. m

2

250 Mio. €

4.000€

Kanzleramt, Berlin

19 Tsd. m

2

250 Mio. €

13.100 €

Klinikum Offenbach

29 Tsd. m

2

140 Mio. €

4.800€

Neubau FH Hamburg

10 Tsd. m 2

50 Mio.€

5.000€

150 m

300 Tsd. €

2.000€

Einfamilienhaus

2

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 m 2 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 2.000 €/m2 , Hotels 4.000 €/m 2 , Prestigebauten mit öffentlichen Geldern 12.000 €/m2 , lässt sich die Kostenschätzung weiter präzisieren und treffsicherer gestalten. Natürlich kann eine einparametrische Schätzung nur sehr grob sein. Sie muss dann durch weitere Parameter verfeinert werden. Dies kann z. B. geschehen, 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. (6.2)

6.1 Methodische Grundlagen des Schätzens

141

Die Stärke des Einflusses der einzelnen Parameter 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. 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 gilt für die Konstruktion von Gehäusen und die Software-Erstellung. Zweitens zeigt 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 EI 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. Tabelle 6.1 Kalkulationsschema für Entwicklungskosten Projektmanagement

Analyse Entwurf

Realisierung

Gehäuse

EI·O,lO

EI·O,25

EI

Elektronik

E2·0,10

E2·0,25

E2

Programm

E3·0,15

E3·0,20

E3

A= ""'C··EL..J I I=16·E ' , , 1 +25·E 2 +25·E 3

Test

Dokumentation

Summe

EI·O,25

EI·I,6

E2·0,75

E2·0,40

E2·2,5

E3·0,85

E3·0,30

E3·2,5

(6.3)

Bei einem Projekt mit El=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.

142

6 Projektschätzung

Ein anderer wichtiger Spezialfall ist die Zerlegung der SucbgröOe. Setzt sich diese aus einer Summe einzelner Anteile zusammen, so ist es sinnvoll, zunächst die Einzetkomponenten 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 besser, als die Güte der Einzelschätzungen.

(6.4) 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 Einzetkosten 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 eine Vielzahl von Arbeiten auszuführen ist. I Vorgangsname

Arbe~

1

I±I Vor projekt

2 Tage

7

I±I Analyse und Entwurf

3 Tage

12 25

I±J Beschaffung B Aufbau

4 Tage 14,5 Tage

26

Ausbou und Entsorgung a~er Komponenten

27

Maure",rbMen für LetungSführung

28

Einbau der Rohr-Le'ungen

29

Einbau Wärmespeicher

30

Anschluß oller thermischen Komponenten

-

2 Tage 1 Tag

-

31

Montage der elektr.

32

Einbau Solarstation

----n-

1 Tag 0,5 Tage

-

0,5 Tage 1 Tag

Le~ungen

-

Einbau Steuerung

0,5 Tage 0,5 Tage

34

Anschluß und PrÜfung aller eleldr. Komponenten

1 Tag

35

Gerüst aufstl'len

1 Tag

36

Montage der mech.

~ 38

Dachho~erungen

Montage der Solarkollektoren

Gerüst abbauen

0,5 Tage 4 Tage 1 Tag

39

I±I Dokumentation

1 Tag

43

I±I Anlagentest

1 Tag

I

Bild 6-3 Screenshot des Projektstrukturplans "Solaranlage"

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.

6.1 Methodische Grundlagen des Schätzens

143

Der dargestellte Screenshot zeigt einen Ausschnitt des Projektstrukturplans, bei dem die Arbeiten des Teilprojekts "Aufbau der Solaranlage" einzeln geschätzt wurden. Aufgrund seines spezifischen Erfahrungshorizonts kann der Mensch Größen, für die er eine sensorische Ausstattung besitzt, also Entfernungen, Gewichte, Zeiten relativ gut schätzen. Andere Größen zu schätzen, wie z. B. Flächen, Volumina, Geschwindigkeit oder Beschleunigung, fällt dem Menschen schwer. Außerdem ist die Schätzung dann recht gut, wenn die Werte in einem mittleren Bereich liegen. Sehr große oder sehr kleine Werte kann sich der Mensch nur schlecht vorstellen und daher auch nur ungenau schätzen. Hier sollte mit Hilfe von Kennwerten eine Skalierung auf einen mittleren Bereich erfolgen, der dem Vorstellungsvermögen des Menschen entgegen kommt. Hat man z. B. einmal die Kenngrößen Bevölkerungsdichte bestimmt, so kann man sie innner benutzen, um aus besser bekannten Bevölkerungszahlen und eventueller Korrektur für dichter oder weniger dicht besiedelte Gebiete, Flächen zu schätzen. 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 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 Schätzung korrigieren. Danach schätzt jeder Experte noch einmal und der dann gemittelte Wert bildet das Ergebnis. Die Beschreibung der verschiedenen Ansätze und Methoden zeigt, dass es beim Schätzen eine ganze Reihe von Werkzeugen gibt, 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. Daher genügt als Ergebnis einer Schätzung auch nicht ein einzelner Wert, sondern beim Schätzen wird der unbekannte tatsächliche Wert ersetzt durch Aussagen über die Auftretenswahrscheinlichkeit der möglichen Werte.

6 Projektschätzung

144 Tabelle 6.2 Gegenüberstellung verschiedener Schätzmethoden Schätzmethode

Beschreibung

Intuitiv

Minimaler Aufwand, sehr große Unsicherheit

Vergleichend

Einfach, Unsicher

KennzaWen

Steigender Aufwand, steigende Sicherheit

Zerlegen

Bei gleicher Einzel-Unsicherheit steigt die Gesamt-Sicherheit

Skalieren

Auf vorstellbare Größen und Dimensionen umrechnen

Kombinieren

Unterschiedliche Wege nutzen

Gruppe

Die Gruppe schätzt besser als der Einzelne

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 einen ersten, groben Schätzwert liefern, mit aufwändigeren Schätzverfahren, um die Sicherheit der Schätzung zu steigern.

..

SchätzGenauigkeit

Top-Down

Bottom-Up

-5 .. + 10%

-10 .. +25%

-25 .. + 75%

1%

3%

5%

Relativer Schätzaufwand

Bild 6-4 Zusammenhang Schätzaufwand/Schätzgenauigkeit

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 Zahlen für diesen Zusammenhang hängen zwar vom konkreten Projekt ab, aber die dargestellte GrafIk versucht zumindest einen groben Anhaltspunkt zu geben. 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

6.2 Mathematische Grundlagen des Schätzens

145

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. 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 bestimmt werden.

6.2 Mathematische Grundlagen des Schätzens 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 Werte, die mehr oder weniger unwahrscheinlich sind. Um derartige vage Aussagen nun 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) = 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) = P(X = x) = F'(x). Sie beschreibt, mit welcher Wahrscheinlichkeit der Wert x angenommen wird.

_

F(x)

Schätzen . Wissen . Raten

Min

Max

x

Bild 6-5 Verteilungsfunktion F(x) und Dichtefunktion p(x) einer Variablen x

In dieser Darstellungsform besteht das Gewinnen von Informationen über die Größe X aus der Bestimmung der Verteilungsfunktion F(x) bzw. der Dichtefunktion p(x). Die Auswertung der Informationen zur Erzeugung einer Aussage ist dann die Festlegung eines einzigen geeigneten Schätzwerts und der Erzeugung einer Aussage über die Güte dieses Schätzwertes. Anschaulich

146

6 Projektschätzung

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 Grenzfalle des Schätzens, nämlich das "Wissen" und das "Raten" haben daher ganz charakteristische 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. Er wird wie folgt berechnet: E = E{x} = f x· p(x)dx

(6.5)

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: M 00 f p(x)dx = f p(x)dx = 0,5 -00

(6.6)

M

Ein dritter Kennwert, der als Schätzwert dienen kann, ist der Wert W mit der höchsten Wahrscheinlichkeit.

p(x)lx=w =Max.

(6.7)

Alle drei Kennwerte einer Dichtefunktion 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 größere 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: V=E{(x-E)2}= f(x-E)2. p (x)dx

S

=.JV

(6.8) (6.9)

Beispiel 6-5 Würfeln Beim Würfeln gibt es 6 mögliche Ergebnisse. Diese sind gleich wahrscheinlich (p=1/6). Die Verteilungsfunktion hat einen treppenf6rmigen Verlauf, der in 6 Stufen von Obis 1 ansteigt.

6.2 Mathematische Grundlagen des Schätzens

6/6 5/6 4/6 3/6 2/6 1/6

147

F(x)

p(x)

x

23456

Bild 6-6 Dichtefunktion bei einem Würfel

Der Erwartungswert und die Standardabweichung kann hier relativ einfach berechnet werden. E = .!..(l + 2 + 3 + 4 + 5 + 6) = 3,5 6 .--.,-------------....,.

S=

.!..~.(1-3,5)2 +(2-3,5)2 +(3-3,5)2}= 1,71

6 Ein Spieler soll nun die Punktesumme zweier Würfel vorhersagen. Im Gegensatz zu praktischen Schätzaufgaben sind hier die Bedingungen exakt bekannt. Der Wertebereich der zu schätzenden Größe muss zwischen 2 und 12 Punkten liegen. Allerdings haben die Werte unterschiedliche Wahrscheinlichkeit. Bei einem Würfel hat jeder Punktewert die Wahrscheinlichkeit 1/6. Eine Kombination von zwei Punktewerten hat somit die Wahrscheinlichkeit von 1/36. Manche Wertekombinationen liefern aber die gleiche Punktesumme, so dass die Wahrscheinlichkeit zunächst von 1/36 bis auf 6/36 steigt und dann wieder linear sinkt. Man erhält somit die dargestellte Wahrscheinlichkeitsdichtefunktion

36/36 30/36 24/36 18/36 12/36 6/36

F(x)

p(x)

2

12

x

Bild 6-7 Dichtefunktion der Punktesumme zweier Würfel

Die höchste Wahrscheinlichkeit als Summe hat der Wert 7. Er wird sich durchschnittlich in einem von 6 Würfen ergeben. Im Gegensatz zum Zufallsexperiment mit einem Würfel, bei dem die Dichtefunktion eine Gleichverteilung besitzt, ergibt sich bei 2 Würfeln schon eine geringe Häufung in der Mitte. Dieser Effekt setzt sich bei mehr Würfeln verstärkt fort. Die Breite der Dichtefunktion nimmt daher mit der Zahl der Würfel immer weiter ab. (Bei n=l ist SIE=1,71/3,5=O,488. Bei n=2 wird SIE=2,4117=O,345.)

6 Projektschätzung

148

Beispiel6-6 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. 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 folgende Diagramm zeigt das zusammengefasste Ergebnis aller Schätzungen als Dichtefunktion. 0,08

r.....

0,07 0,06

1 /

0,05 0,04

\

t

0,03 0,02

f

0,01

f

.t

0 1

4

7

\

\

~

"'........

10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58

Bild 6-8 Dichtefunktion der Projektdauer (in Tagen)

Als kleinster Wert wurden 20 Arbeitstage, als größter Wert 50 Arbeitstage genannt. Die Auswertung ergab die dargestellt Dichtefunktion. Aus der Dichtefunktion konnten folgende Kennwerte bestimmt werden: Wahrscheinlichster Wert W=28,0 Tage Median M=30,8 Tage Erwartungswert E=32,0 Tage Standardabweichung S=5,9 Tage 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. 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 Werte werden als gleich wahrscheinlich angenommen, so dass die Dichtefunktion einen rechteckf'örmigen Verlauf besitzt.

E= a+b 2

(6.10)

b-a b-a ~ 8=-=-·,,3

(6.11)

.J126

Die vielfache Verwendung der Gleichverteilung beruht weniger auf deren tatsächlichem Vorkommen, als darauf, dass mangels besseren Wissens gleich wahrscheinliche Werte angenom-

6.2 Mathematische Grundlagen des Schätzens

149

men 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, der maximale und der wahrscheinlichste Wert c.

E=a+b+c 3 8

(6.12)

= b-a 1+ (b _c)2 + 6

b-a

(c

_a)2 = b-a . b-a 6

(v'1,5... ~)

(6.13)

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)=-.!.-(x-aY-1.(b-xY-1

(6.14)

B

Dabei ist B ein konstanter, normierender Faktor, der mit Hilfe der Beta-Funktion aus den Parametern a, b, rund s berechnet werden kann. p(x)

a

c

b

x

Bild 6-9 Gleichverteilung (1), Dreieck-Verteilung (II) und Beta-Verteilung (III)

Eine in Theorie und Praxis gleichermaßen große Bedeutung besitzt die so genannte Normalverteilung. Bei ihr besitzen die Werte in der Mitte eine noch größere und die Werte am Rande eine noch geringere Wahrscheinlichkeit. Die Nonnalverteilung besitzt einen charakteristischen, als Gauß'sche Glockenkurve bezeichneten Verlauf

p(x)=

1 ~

,,2,.·8

e

[-MX~ErJ

(6.15)

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ät-

6 Projektschätzung

150

zungen zusammen, so ist die Gesamtschätzung, unabhängig von den Einzelschätzungen normalverteilt. Somit kann Erwartungswert und Standardabweichung der Gesamtschätzung relativ einfach abgeschätzt werden.

p(T 0,4

1

I

---T---

- - -1- - -

0,3

I I

I I

- - _1- __

I ---1 ---

0,2

- - _1- __

___ l ___

I I I I I I I

1 I I

0,1 0,0

I I I

-3Ts

I I

-.1 ___ I

-Ts Te

+Ts

L ___ I I I

+3Ts

T

Bild 6-10 Nonnalverteilung (Erwartungswert Te, Standardabweichung Ts)

Die Normalverteilung ist symmetrisch bezüglich des Erwartungswertes, so dass Erwartungswert, Median und wahrscheinlichster Wert gleich sind. Außerdem ist der gesamte Verlauf der Normalverteilung durch die beiden Kennwerte Erwartungswert und Standardabweichung bestimmt. Kennt man diese beiden Werte, so können alle Aussagen bezüglich der Verteilungsund Dichtefunktion gemacht werden. Insbesondere ist es möglich zu sagen, in welchem Maße die Schätzwerte um den Erwartungswert streuen. p(x=E+z*S)

o

z

Bild 6-11 Bestimmung der Wahrscheinlichkeit P(x,z) bei der Nonnalverteilung

Um zu berechnen, wie hoch die Wahrscheinlichkeit ist, dass der Wert der Zufallsvariablen X kleiner ist als x (P(X::;; x) = F(x)), braucht man bei der Normalverteilung nur deren Erwartungswert und die Standardabweichung zu kennen. Damit kann man z. B. sehr einfach bestimmen, mit welcher Wahrscheinlichkeit die ProjektIaufzeit kleiner ist, als ein bestimmter Wert T. Bei x = E + z· S ist die Wahrscheinlichkeit p(x,z) eine Funktion von z, gemäß folgender Tabelle [Kreyszig 1973, S. 393].

6.2 Mathematische Grundlagen des Schätzens

151

TabeUe 6.3 Konkrete Werte für P(x, z) bei der Normalverteilung z

p(x<E-z'S)

p(E-z'S<x<E+z'S)

p(x<E+z'S)

0,000

50,0%

0,0%

50,0%

0,266

40,0%

20,0%

60,0%

0,524

30,0%

40,0%

70,0%

0,842

20,0%

60,0%

80,0%

1,000

15,87%

68,27 %

84,13 %

1,282

10,0%

80,0%

90%

1,645

5%

90,0%

95,0%

2,000

2,28%

95,45 %

97,72 %

2,326

2%

96%

98,0%

3,090

0,1 %

99,8%

99,9%

3,719

0,01 %

99,98 %

99,99 %

Bei einer Nonnalverteilung liegen nur gut 2 % der Werte unter E-2S, etwa 16 % unter E-S, 50 % unter E, über 84 % unter E+S und 98 % unter E+2S. Diese Werte können nun bei der Schätzung der Projektdauer sehr anschaulich genutzt werden. Die Zufallsvariable x entspricht hier der Projektdauer T. Die Wahrscheinlichkeit ein Projekt in der erwarteten Zeitdauer (z=O, x=E) fertig zu stellen, beträgt also genau 50 %! Eine Tenninzusage auf der Basis des erwarteten Zieltennins zu machen, ist also genau so verlässlich, wie beim Roulette auf "Rouge" zu setzen. Nimmt man dagegen nicht die Summe der Erwartungswerte, sondern die Summe der wahrscheinlichsten Werte aller Einzelvorgänge, so sinkt die Wahrscheinlichkeit, das Projekt innerhalb der versprochenen Zeit fertig zu stellen, noch weiter ab. Schließlich liegt aufgrund der Schiefe der Einzelverteilungen, der wahrscheinlichste Wert unterhalb der Erwartungswerte. Um mit größerer Wahrscheinlichkeit einen zugesagten Termin zu halten, muss der Zusagetermin nach hinten verschoben werden. Geht man auf den Erwartungswert plus einfacher Standardabweichung, steigt die Summe der Wahrscheinlichkeit schon auf 84 % und bei Addierung der doppelten Standardabweichung gar auf 98 %!

Beispiel 6-7 Aussagen über Aufwand und Laufzeit Der Projektleiter hat gemeinsam mit den Projektbeteiligten einen Projektstrukturplan erstellt, den Aufwand für jedes Arbeitspaket bestimmt und zu einem GesamtErwartungswert (E=240 PT) und einer Gesamt-Standardabweichung (S=32 PT) für das Projekt addiert. Der Auftraggeber erwartet nun eine Aussage über den voraussichtlichen Projektaufwand. Im Projektteam gibt es unterschiedliche Auffassungen, welcher Wert genannt werden soll. Das Team schlägt vor, den Erwartungswert von 240 PT als Planwert zu nehmen. Dies wird aber vom Projektleiter abgelehnt, da die Chance, diesen Wert auch einzuhalten bei nur 50 % liegt. Man einigt sich auf den Planwert von 272 PT, bei dem sich die Chance auf 84 % verbessert. (272=240+1,0'32). Dem Auftraggeber ist dieser Wert allerdings viel zu hoch. Er verlangt eine deutliche Verringerung. Darauf erwidert der Projektleiter " ... dass wir auf keinen Fall mit weniger als 200 Personentagen auskommen werden."

152

6 Projektschätzung Obwohl diese Aussage recht zutreffend ist (Wegen 200 = 240 - 1,25'32, ist die Aussage zu fast 90 % richtig), wird sie beim Auftraggeber vollkommen falsche Vorstellungen wecken, da sich der genannte Zeitwert (200 PT) im Gedächtnis als Planwert festsetzt, aber nicht die beschriebene Bedingung ("nicht schneller als").

So elegant das Konzept der Beschreibung einer Schätzgröße mit Hilfe einer Wahrscheinlichkeitsdichtefunktion mathematisch auch ist, so schwierig ist seine praktische Umsetzung. Die Schätzung eines Wertes ist oft schon schwierig. Alle Werte eines Wertebereichs mit einer zugehörigen Wahrscheinlichkeitszahl zu bestimmen, ist in praktischen Fällen schier unmöglich. Ein brauchbarer Kompromiss zwischen theoretischem Idealfall und dem praktisch Machbaren ist es, neben einem Schätzwert auch eine Aussage über seine Genauigkeit zu machen. Anschauliche, in der Praxis anwendbare Verfahren hierfür sind die Zweipunkt- und Dreipunktschätzung. Statt eines einzigen Schätzwertes basieren sie auf zwei bzw. drei Werten, so dass neben dem Schätzwert auch eine Aussage über seine Qualität gewonnen wird. Die Zweipunktschätzung grenzt den Wertebereich durch einen kleinsten Wert (a) und einen größten Wert (b) ein. In der Mitte des Bereichs wird dann der Schätzwert E angenommen. Unter der Annahme, dass die zwischen den beiden Werten liegende Verteilung die Form einer Beta-Funktion hat, kann die Standardabweichung näherungsweise bestimmt werden:

E

a+b 2

(6.16)

b-a s=-6

(6.17)

=

Auch die Dreipunktschätzung grenzt den Wertebereich ein, nutzt aber zusätzlich einen wahrscheinlichsten Wert (c), der nicht zwangsläufig in der Mitte zwischen Minimum und Maximum liegen muss. Die Approximation des Schätzwertes und dessen Standardabweichung ergibt sich hier als: E= a+4·c+b 6

(6.18)

b-a s=-6

(6.19)

Beispiel 6-8 Schätzung einer Projektdauer (2) Ersetzt man die aufwändige Schätzung der Projektdauer durch eine Bestimmung des kleinsten (a=20 Tage), der größten (b=50 Tage) und des wahrscheinlichsten Wertes (c=28 Tage), so erhält man bei einer Zweipunktschätzung einen Mittelwert von E=35,0 Tagen und bei der Dreipunktschätzung einen Mittelwert E=30,3 Tage. Die Standardabweichung ist in beiden Fällen gleich (S=5,0 Tage). Verglichen mit den exakten Werten zeigt sich, dass die Dreipunktschätzung bessere Resultate liefert. Hätte man eine Gleichverteilung angenommen, so wäre E=35,0 Tage und S=8,7 Tage. Bei einer Dreieckverteilung wäre E=32,7 Tage und S=6,3 Tage. Man erkennt, die abnehmende Standardabweichung, wenn man von der Gleichverteilung zur Dreiecksverteilung und von dieser zur Zwei- bzw. Dreipunktschätzung übergeht. Dies

6.2 Mathematische Grundlagen des Schätzens

153

spiegelt die Annahme geringerer Wahrscheinlicbkeiten am Rande und höherer Wahrscheinlicbkeiten in der Mitte des Wertebereichs wieder. Gegenüber der bloßen Schätzung eines einzigen Wertes bringt die Zweipunkt- und die Dreipunktschätzung neben einer verbesserten Einsicht in das Schätzproblem auch eine Aussage über die Zuverlässigkeit der Schätzung bzw. ihrer Streuung. Eine weitere, zum Teil deutliche Verbesserung wird erreicht, wenn die zu schätzende Größe in einzelne Summanden zerlegt werden kann, die unabhängig voneinander geschätzt werden. Aus der Definition von Erwartungswert und Varianz folgt dann:

E= Jx.p(x)dx= LJXj .p(xj)dxj =LEj i

(6.20)

j

(6.21)

Der Erwartungswert der Swnme ist gleich der Summe der Erwartungswerte. Die Standardabweichung der Swnme ist die Wurzel der Summe der einzelnen Standardabweichungen. Durch die Wurzelfunktion führt dies bei der Summe zu einer durchschnittlich geringeren Standardabweichung als bei den Einzelgrößen!

Beispiel 6-9 Aufwandsschätzung in einem Projekt Bei einem Projekt, das aus 7 Arbeitspaketen (APl-AP7) besteht, soll der Gesamtaufwand geschätzt werden. Außerdem soll eine Aussage über die Streubreite der Schätzung gemacht werden. Jedes Arbeitspaket wird in drei Punkten mit optimistischem (a), pessimistischen (b) und realistischem Wert (c) geschätzt. Mit der Dreipunktformel können dann:für jedes Arbeitspaket ein Erwartungswert (E) und eine Standardabweichung (S) bestimmt werden. a

Bnd~12

c b E S SIE 1QR 27,3% 20 80 36,7 10 201-30 20,0 3,3 16,7% 2,5 12,0% 15 20 30 20,8 10 25 11,7 3,3 1 28,6% 5 15 20 4,2 18,5% 40t-22,5 90 51,7 20 50 112 22,6% 5 9,5 2,5 26,3% 8 20 17,0 9,8% 901 1581 3151 172,81 901 1581 315 172,81-> 37,5 21,7%

V

301

100,0 11 ,1

62-

<=1

11 ,1 17,4 136,1 6,3 288,2 1406,3

Projektaufwandsschätzung als Schätzwertsummen

Vergleicht man den daraus ermittelten Erwartungswert E=I72,8 Tage und die Standardabweichung S=17,0 Tage mit den Werten, die sich aus einer direkten Schätzung des Gesamtaufwandes (a=90 Tage, b=315 Tage und c=158 Tage) ergeben würden (E=172,8 Tage, S=37,5 Tage), so erkennt man eine deutlich verringerte Standardabweichung bei unverändertem Erwartungswert.

154

6 Projektschätzung a AP1 AP2 AP3 AP4 AP5 AP6 AP7

Sumo Sumo

c

b

E

I

8 16r321 5 10 20 11 22-1--441 25 50 00 [ 4 8 161 781 156 3121 781 156 3121

1

S I

v

SIE

7,5 23% T 56,3 5,0 f- 23% 25,0 16,0 17,3 I 4,0 23% I 10,8 23% 6,3 2.5 5,5 23% 23,8 I 30,3 12,5 156,3 23% 54,2 8,7 4,0 2.01 23% 169,01 17,1 10,1%/-9 294,0 169,01=> 39;0 23,1%1 1521,0

1~ ~T-~L 32,S 10 20 40 1 21,7

,

,

; ,

Blld 6-13 Projektaufwandsschätzung als Schätzwertsummen

Durch die getrennte Abschätzung der einzelnen Komponenten ergibt sich ein Schätzwert mit deutlich geringerer Streuung. Dieser Effekt kann noch deutlicher im zweiten Zahlenbeispiel beobachtet werden, bei dem die Einzelschätzungen die gleiche relative Standardabweichung von 23 % besitzen. Das Ergebnis der Schätzsumme besitzt nur noch eine relative Standardabweichung von 10 %1

6.3 Schätzung der Projektdauer " Schnell entflieht die Zeit, (Lateinisches Sprichwort) 11

Eine besondere Bedeutung besitzt die Schätzung der Projektdauer. Kennt man den Arbeitsaufwand A für ein Arbeitspaket, so kann bei bekanntem Personaleinsatz P und der Leistung L die benötigte Zeitdauer T für das Arbeitspaket berechnet werden.

T=~ L·P

(6.22)

Ein Arbeitspaket mit 20 PT (personentagen) beispielsweise kann bei Einsatz einer Person und einer Leistung von 100 % in 20 Arbeitstagen bewältigt werden. Eine Verdopplung der Personenzahl halbiert die Zeitdauer auf 10 Tage; eine Halbierung der Leistung, d. h. die Person arbeitet nur zur Hälfte an dem Paket, verdoppelt die Zeitdauer. Leider hat dieser theoretisch so einfache und einleuchtende Zusammenhang seine praktischen Tücken. Dies wird offensichtlich, wenn man Grenzfälle betrachtet. Würde man auf das Arbeitspalret von 20 PT von 20 Personen mit 100 % Leistung bearbeiten lassen, wäre es theoretisch in einem Tag fertig. Sicherlich gibt es Arbeiten, wo eine beliebige Parallelisierung möglich ist, aber nicht in Projekten mit hohem Neuartigkeits- und Schwierigkeitsgrad. Theoretisch sollte es möglich sein, die Zeitdauer beliebig zu kürzen, durch entsprechenden hohen Personaleinsatz. Praktisch geht dies nicht, da bei mehr Personen zusätzlicher Kommunikationsaufwand entsteht. Das folgende Bild verdeutlicht den Zusammenhang. Der Aufwand A setzt sich zusammen aus dem Arbeitsaufwand AO und bei mehr als einer beteiligten Person dem Kommunikationsaufwand Al. Dieser steigt mit der Zahl N der Personen mindestens linear, realistisch gesehen sogar exponentiell an. Dividiert man den Gesamtaufwand durch die Zahl der Personen (T=AJN) ergibt sich der dargestellte Verlauf der Zeitdauer.

6.4 Schätzung des Aufwands bei Software-Systemen Zeit

~ ~

155

A: Gesamtaufwand (AO+A1)

A~~ ~

~

T: Gesamtdauer (T=A1N) -

T

~

~

~

~

~

~

N

AO: Arbeitsaufwand A1: Kommunikationsaufwand

Zahl der Mitarbeiter

Bild 6-14 Abhängigkeit der Projektdauer von der Zahl der Personen

Zudem gibt es Arbeiten die grundsätzlich nicht beliebig parallelisiert werden können. Für viele Arbeiten gibt es eine natürliche Obergrenze der Parallelisierung. Ganz anschaulich zeigt dies folgendes simple Beispiel: Wenn ein Mann zum Ausheben einer Grube einer Länge, Breite und Höhe von je I Meter, 10 Stunden braucht, müssten 20 Arbeiter mit der Grube in einer halben Stunde fertig sein. Fragt sich nur, wie die 20 Arbeiter auf der Grundfläche von 1m2 in der halben Stunde ,,kooperieren". Ein vergleichbarer Effekt, wenn auch aus einer anderen Ursache resultierend, tritt auf, wenn eine Person nur zum Teil ihrer Zeit an einer Arbeit dran bleiben kann (N
6.4 Schätzung des Aufwands bei Software-Systemen "Die dümmsten Programmierer haben die dicksten Programme. " (Unbekannt) Der Aufbau detailliert ausgearbeiteter Schätzmodelle in einem bestimmten Fachgebiet, stellt eine wichtige Kompetenz eines projektausführenden Unternehmens dar. Sie ermöglichen es, anband eines Lastenhefts relativ schnell und genau den erforderlichen Aufwand und die Kosten zu schätzen. Werden die Schätzungen dann verwendet, um ein Angebot zu erstellen, so ist es

156

6 Projektschätzung

offensichtlich, dass ein Schätzmodell, das verlässliche Ergebnisse in überschaubarer Zeit liefert, einen Wettbewerbsvorteil darstellt. Aus diesem Grund gibt es nur wenige veröffentlichte Schätzmodelle. Eine Ausnahme bildet hier die Schätzung von Software-Projekten. Eines der bekanntesten ist das CoCoMo (Constructive Cost Model) von Boehm [Boehm 1981]. Der Grundgedanke des Schätzverfahrens von Boehm besteht darin, dass der Aufwand für die Software-Entwicklung im Wesentlichen von der Programmlänge abhängt. Boehm geht dann weiter von der Annahme aus, dass die Programmlänge für neue Vorhaben aufgrund von Vergleichswerten besser vorhersagbar ist, als der Arbeitsaufwand. Im ersten Ansatz, dem so genannten Basic Model, wird dann der Aufwand A proportional zur Programmlänge L angenommen. (6.23) Die Programmlänge wird gemessen in Programmzeilen (KLOC: Kilo Lines of Code). Hierbei werden nur Quellcode-Zeilen erfasst; Kommentar-Zeilen und Dokumentations-Zeilen zählen nicht mit. Ebenso werden die Teile des Programms, die nur für Hilfs- oder Testzwecke eingebaut wurden, nicht mitgezählt. Boehm prägt hierfür den Begriff der Delivered Lines ofInstruction (DU). Der Aufwand A wird gemessen in Personenmonaten. 1 Personenmonat entspricht dabei 152 Personenstunden; 12 Personenmonate ergeben 1 Personenjahr. Durch Auswertung einer stattlichen Zahl von 63 Software-Projekten, mit Größen zwischen 2 KLOC bis 966 KLOC; bzw. 6 PM bis 11.400 PM wurden für die Konstante Cl folgende Wertebereiche ermittelt: Cl

=

1 .. 40 [PM/KLOC]

Die Bandbreite des Faktors Cl ist enorm und ebenso groß ist daher die Bandbreite der Produktivität: l/Cl = 1,000 .. 0,025 [KLOC/PM] = 6,5 .. 0,16 [LOC/Std] Als Mittelwerte ermittelte Böhm einen Wert von Cl

=

3 [MM/KLOC]

l/Cl= 0,333 [KLOC/MM] = 2,2 [LOC/Std] Natürlich besitzt ein Ergebnis mit einer so großen Varianz keine große SignifIkanz. Es kann lediglich als sehr grober Schätzwert für die Produktivität angesehen werden. Die Werte zeigen aber auf jeden Fall, dass weit weniger Programmzeilen pro Zeit erreichbar sind, als man dies eventuell beim reinen Programmieren vermuten würde. Dies liegt daran, dass im Zeitaufwand, alle Phasen der Programmerstellung, also Aufgabenanalyse, Programmentwurf, Test und Dokumentation berücksichtigt sind. Für eine Verbesserung der Schätzung wird das Modell verfeinert und es werden neben der Programmlänge weitere Einflussfaktoren identifIziert und quantifIziert. Hierzu zählt die Beobachtung, dass bei großen Projekten der Aufwand stärker als proportional mit der Programmlänge ansteigt. Dies berücksichtigt das Coco-Modell durch einen Faktor C2, mit dem die Programmlänge potenziert wird. Der Faktor C2liegt dabei zwischen 1,05 und 1,20.

A = Cl . LC2

(6.24)

Als weiterer Einflussfaktor wurde die Projektart erkannt. Es werden drei Projektarten unterschieden: organic, semi-detached und embedded. Die folgende Tabelle stellt die Eigenschaften

6.4 Schätzung des Aufwands bei Software-Systemen

157

dar, die die Projektart kennzeichnen. Außerdem werden die zugehörigen Werte von Cl und C2 für die drei Projektarten dargestellt. Tabelle 6.4 CoCoMo-Schätzmodelle und Parameter Eigenschaften

Organic

SemiDetached

Embedded

Organisation versteht Zielsetzung der Software

Gründlich

Einigermaßen

In Grundzügen

Erfahrung in der Entwicklung ähnlicher Softwaresystemen

Viel

Mittel

Etwas

Notwendigkeit der strikten Einhaltung externer Schnittstellen

Etwas

Mittel

Sehr stark

Parallele Entwicklung mit Hardware oder Geschäftsprozessen

Wenig

Etwas

Stark

Notwendigkeit neuer Technologien

Gering

Etwas

Merklich

Softwareumfang

<50KDLI

<300KDLI

Jede Größe

Cl (Basic)/C 1' (Intermediate)

2,4/3,2

3,0/3,0

3,6/2,8

C2

1,05

1,12

1,20

C3

2,5

2,5

2,5

C4

0,38

0,35

0,32

Parameter

Als weiteres Ergebnis aus den Untersuchungen konnte nicht nur ein Algorithmus zur Berechnung des Aufwands A, sondern auch eine Bestimmung der optimalen Projektdauer D und der optimale Größe N des Projektteams bestimmt werden:

D=C3 ·A C4 N=A/D

(6.25)

Die zur Bestimmung der Projektdauer verwendeten Parameter C3 und C4, sind ebenfalls in der obigen Tabelle dargestellt.

Beispiel6-10 Projektierungs-Software In einem Projekt sollte ein Programm erstellt werden, bei dem ein modular aufgebautes Automatisierungssystem in graphischer Form projektiert werden kann. Im Wesentlichen bestand das Programm aus einem interaktiven graphischen Editor, einer Datenbank für die graphischen Symbole und für die Attribute der Systemmodule und einem Auswerteteil. Durch Vergleich mit anderen Programmen konnte die gesamte Programmlänge auf 33.000 Zeilen geschätzt werden. Die Projektart wurde als "organic" eingestuft, da entsprechende Kenntnisse vorlagen. Damit ergaben sich folgende Werte für Aufwand, Dauer und Zahl der Mitarbeiter:

158

6 Projektschätzung A=C1 ·LC2 =2,4·33,0'105 MM=94,3MM D = 2,5 . A 0,38 = 14 Mon

N = 6,8 Mitarbeiter

Beispiel6-11 Berechnungs-Programm für Transportbahnen Ein vorhandenes Programm zur Dimensionierung von seilgebundenen Transportbahnen sollte in einem Projekt neu geschrieben werden. Die Geometrie der Transportstrecke, also Längen, Neigungen, Kurven usw. wurden im Programm eingegeben. Daraus wurden dann die im Seil auftretenden Kräfte berechnet. Das Programm wurde vor mehr als 30 Jahren in Basic geschrieben und besaß eine spartanische Benutzeroberfläche, bei der alle Eingaben, Ausgaben und die Funktionsauswahl in textlicher Form erfolgen. Aus diesem Grund sollte das Programm komplett neu erstellt werden. Leider gab es keine Dokumentation des Basic-Programms, sondern nur einen Ausdruck des spärlich kommentierten Quellcodes. Dieser umfasste 56 Seiten, was bei etwa 50 Zeilen pro Seite einen Umfang von 2800 Programmzeilen ergab. Die Dateigröße betrug 91.386 Zeichen. Somit ergab sich ein Wert von durchschnittlich 33 Zeichen/Zeile. Ausgehend von diesen Werten wurde der Aufwand zur Neu-Erstellung des Programms, die voraussichtliche Dauer des Projekts und die sinnvolle Anzahl von Mitarbeitern abgeschätzt: 1,12 PM=76PM A=C1 ·LC2 =24.28 " , D

= 2,5· AO,35 = 5,5Mon

N = 1,7 Mitarbeiter

Im Laufe des Projekts wurde das Programm manuell in die Programmiersprache C++ portiert und mit einer Windows-Oberfläche ausgestattet. Der daraus resultierende Quellcode umfasste 2839 Zeilen! Die Quelltextdatei umfasste 113.864 Byte. Aus personellen Gründen wurde das Projekt nur von einem Mitarbeiter erstellt. Das Programm konnte inklusive Test und Dokumentation in etwa 7 Monaten erstellt werden. Dadurch ergab sich zwar eine längere Laufzeit, dafür mit 7,0 PM etwas weniger Aufwand als geschätzt. Die Berücksichtigung der Projektart und des überproportionalen Anstiegs des Aufwands mit der Programmlänge können die Varianz der Schätzung verringern. Sie ermöglichen mit geringem Aufwand eine schnelle, grobe Aufwandsschätzung. Dennoch gibt es in einzelnen Projekten noch große Abweichungen zwischen geschätztem und tatsächlich benötigtem Aufwand. Daher wurden weitere Verbesserungen des Modells durch insgesamt 15 Korrekturfaktoren vorgenommen. Diese gehen in Form multiplikativer Faktoren Ei in die Berechnung ein. A = Cl . L

C

2

15

Tl Ei

(6.26)

i=l

Im Normalfallliegen die Faktoren bei 1 und werden in Abhängigkeit verschiedener Merkmale nach oben oder unten variiert. Details hierzu würden an dieser Stelle zu viel Raum einnehmen. Daher wird auf die entsprechende Literatur verwiesen [Boehm 1981].

6.5 Repetitorium

159

6.5 Repetitorium 6.5.1 Checklisten Tabelle 6.5 Checkliste Aufwandsschätzung 1.

Liegt ein Projektstrukturplan vor, der auch auf der Ebene der Arbeitspakete detailliert ausgearbeitet ist?

2.

Gibt es aus eigenen oder fremden praktischen Erfahrungen Kennzahlen zur Abschätzung von Arbeitspaketen?

3.

Gibt es für jedes Arbeitspaket Experten, die Aufwand und Kosten schätzen können?

4.

Gibt es für die großen bzw. kritischen Arbeitspakete mehrere Experten für jedes Arbeitspaket?

5.

Wie sehen der optimistische, der realistische und der pessimistische Schätzwert für jedes Arbeitspaket aus?

6.5.2 Verständnisfragen 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

Worin unterscheiden sich Wissen, Schätzen und Raten? Erläutern Sie das Konzept einer Zufallsvariablen, ihrer Verteilungsfunktion und ihrer Wahrscheinlichkeitsdichtefunktion! Welche Bedeutung haben Erwartungswert, Median, wahrscheinlichster Wert, Standardabweichung und Varianz einer Zufallsvariablen? Was versteht man unter qualitativer, intuitiver und quantitativer Schätzung? Erläutern Sie die Vorgehensweise bei der Zweipunktschätzung und der Dreipunktschätzung! Was versteht man unter der De1phi-Methode im Zusammenhang mit der Schätzung? Welche Möglichkeiten gibt es, um die Güte einer Schätzung zu verbessern? Wie kann bei der Schätzung eines Wertes eine Aussage über die Schätzgüte bestimmt werden? Welcher Zusammenhang besteht zwischen der Schätzgenauigkeit und dem Schätzaufwand? Stellen Sie den Zusammenhang zwischen Zeitdauer und Zahl der Mitarbeiter für ein Arbeitspaket fester Größe graphisch dar und erläutern Sie ihn! Erläutern Sie die Bedeutung des Prinzips der motivationsfreien Schätzung und der schätzungsfreien Motivation! Erläutern Sie das Constructive Cost Model CoCoMo!

6 Projektschätzung

160

6.5.3 Übungsaufgaben Aufgabe 6-1 Gebäudekostenschätzung

In der Kaffeepause stellen einige Ihrer Kollegen wilde Spekulationen über die Kosten des geplanten neuen Bürogebäudes für Ihre Firma an. Sie wissen lediglich, dass das kubische Gebäude eine Länge von 35 m und eine Breite von 20 m besitzt und 3 Etagen erhalten soll. Können Sie eine grobe Schätzung der Gebäudekosten erstellen? Was müssten Sie wissen, wenn Sie die Schätzung präzisieren sollten? Aufgabe 6-2 Aussage über Aufwand und Laufzeit im Projekt

Sie leiten ein Projekt. Der Projektstrukturplan wurde erstellt und der Aufwand für alle Arbeitspakete geschätzt. Der Gesamtaufwand beträgt 320 Personentage; als Standardabweichung wurden 45 Personentage ermittelt. Der Auftraggeber hätte gerne eine verbindliche Aussage über den voraussichtlichen Gesamtaufwand für das Projekt. Was sagen Sie ihm? Können Sie auch eine Aussage über die voraussichtliche Projektlaufzeit machen? Aufgabe 6-3 Dreipunktschätzung

Für die folgenden Vorgänge wurde eine Dreipunktschätzung der Vorgangsdauer erstellt. Vorgang 1

Vorgänger

Projektdeftnition

a

c

b

2

2

4

2

Marktrecherche

1

7

10

16

3

Nutzerbefragung

1

12

15

18

4

Auswertung

2,3

9

12

16

5

Produktfestlegung

3,4

2

3

3

6

Zwischenpräsentation

5

1

1

1

7

Deftnition der Eigenschaften

5

8

10

13

8

Designstudien

5

10

15

22

9

Designauswahl

7,8

2

3

4

10

Detailfestlegung

9

8

9

11

11

Dokumentation

10AA

10

12

15

12

Präsentation vorbereiten

10,11

3

4

6

13

Abschlusspräsentation

12

1

1

1

E

S

Summe

Berechnen Sie für jeden Vorgang Erwartungswert und Standardabweichung! Berechnen Sie den erwarteten Gesamtaufwand und die zugehörige Standardabweichung! Welchen Aufwand würden Sie nennen, wenn Sie diesen mit 68 % bzw. 95 % Wahrscheinlichkeit einhalten wollen?

6.5 Repetitorium

161

Aufgabe 6-4 Fallbeispiel "Solaranlage": AufWandsschätzung Sie erhalten von Ihrem Projektleiter den folgenden Projektplan zur Realisierung der Solaranlage. Er gibt Ihnen den Auftrag, den ArbeitsaufWand für jedes Arbeitspaket als Dreipunktschätzung zu bestimmen. Dabei wird für jedes Arbeitspaket ein optimistischer, ein realistischer und ein pessimistischer AufWand geschätzt. Solarthermische Anlage ~I-:---:---'c-I-----.,------,1

I

]Arbeitspaket

IVorll~ekt

-'-'--- --'--=-'-'-

1.1. Bestandsaufnahme vor Ort 1.2. Grobe Bedarfsermiltlung 1.3. Grobkonzept 1.4. Grobe Marktanalyse 1.5._ Angebot erstellen 2. IAnalyse und Entwurf 2.1. Detaillierle Bedarfsanal se 2.2. Detailkonzepl ausarbeiten ._·~.3-,- Anal~plane zeichnen ~2.4. lli!.~inie!!.en..!-~Iaufplan entwerfen 3.lBeschaffung (RealisierunfL!l -~ Gena~M~ktanalyse -

-

3.2.

-

-

3.3. 3.4.

-

4. lAufbau - - -(Realisierung - - -2) 4.1. Ausbau und Entsor9'i:J'1.9 alter Komponenten 4.2. Maurerarbeiten für Leitungsführung ~inbau der Rohr-Leitunqen 14 .3. 4.4. Gerüst aufstellen 4.5. Montage der mech Dachhalterungen -

~ . Montage der Solarkollektore'!.-

4.7. Einbau Wärmespeicher 4.8. Anschluß aller thermischen Komponenten _ _

5.

Monta.ge der elektr. Leitungen Einbau Solarstation -Einbau Steuerunq Anschluß und Prüfung aller elektr Komponenten Gerüst abbauen Dokumentation IRealisierung 31

-

~ *:triebS~le!!~!~fL

-~

4.10. 4.11. 4.12. 4.13.

Solarkollektoren (inkl. Halter + Verbdinunl 5.2. Bedienungsanleitung Solarmodul (inkl. Rohre) 5.3. Wartungsvorschrift SteuerungJinkl. Fühler + Leitun~_ _ 6. IAnia entest (Vahdlerung) Wasserspeicher 6.1. Befüllun und Dichtigkeits rüfun Einholunq von Angeboten 6.2. Inbetriebnahme Solarkollektoren (inkl. Halter + Verbdjnun, -16.3. Einweisun des Betreibers Solarmodul finkl. Rohre) SteuerungJinkl. Fühler + Leitungen)_ _ lEillt-rb_ei_ten Wasserspeicher Erstellung Preisse.ieg_e_1_ Bestellung

--

_

Bild 6-15 Projektplan für das Fallbeispiel"Solaranlage"

Welche Angaben fehlen Ihnen, um eine sinnvolle Schätzung vornehmen zu können? Machen Sie selbst sinnvolle Annahmen für die fehlenden Angaben und führen dann die Schätzungdurch. Bestimmen Sie nun Erwartungswert und Standardabweichung für jedes Arbeitspaket, für jedes Teilprojekt und für das Gesamtprojekt!

7 Ablauf- und Terminplanung "Keine Zeit!" heißt: "Andere Priorität. " Nachdem im Projektstrukturplan die Liste aller Arbeiten erfasst, in hierarchischer Ordnung gegliedert wurde und in der Aufwandsschätzung Aussagen über den Aufwand und mögliche Laufzeiten gewonnen wurden, muss als nächstes die Ausführung der Arbeiten geplant werden. Hierbei muss festgelegt werden, wann und von wem eine Arbeit ausgeführt werden soll. Dabei ist eine ganze Reihe von Anforderungen und Einschränkungen zu berücksichtigen. Aufgrund des Termindrucks in Projekten wäre es sinnvoll, alle Arbeiten so früh wie möglich auszuführen. Dies ist aber für die meisten Arbeiten entweder gar nicht möglich oder aber aus Kostengründen nicht sinnvoll. Viele Arbeiten im Projekt besitzen gegenseitige Abhängigkeiten. Typischerweise können bestimmte Arbeiten erst begonnen werden, wenn zuvor andere Arbeiten abgeschlossen wurden. Die Bestückung einer Platine beispielsweise setzt voraus, dass sie zuvor hergestellt wurde. Vor der Herstellung steht das Layout, das wiederum erst nach dem Entwurf des Schaltplans erfolgen kann. Aber auch wenn Arbeiten sehr früh begonnen werden können, ist dies nicht unbedingt sinnvoll. Die Bestellung eines teueren Transportbehälters für ein neu zu entwickelndes Produkt ist zwar bereits zu Projektbeginn möglich, sobald dessen Abmessungen und Gewicht bekannt sind, verursacht aber eine unnötig frühe Kapitalbindung und kostet Lagerplatz. Viele Arbeiten sollen daher erst dann ausgeführt werden, wenn sie tatsächlich gebraucht werden (,just in time"). Fasst man diese gegenläufigen Anforderungen zusammen, so erhält man folgendes Grundprinzip für die Ablau:fplanung: Arbeiten sollten so früh wie nötig, aber so spät wie möglich eingeplant werden. Die wesentliche Aufgabe der Ablaufplanung ist es also, die Abhängigkeiten zwischen den Arbeitspaketen des Projektstrukturplans zu erkennen, um dann die idealen Zeitpunkte für die Durchführung der Arbeiten zu finden.

7.1 Anordnungsbeziehungen "Eine Beziehung, die kriselt, heißt Wackelkontakt. " (K. Klages) Die Ablaufplanung beginnt damit, die logischen Anordnungsbeziehungen zwischen Arbeitspaketen zu erfassen. Sie beschreiben, wie Anfang bzw. Ende der einen Arbeit mit Anfang bzw. Ende einer anderen Arbeit gekoppelt sind. Hier gibt es vier Möglichkeiten. Die wichtigste Anordnungsbeziehung löst bei Beendigung einer Arbeit den Start einer anderen aus. Die eine Arbeit (der Vorgänger) muss zuerst komplett abgeschlossen sein, bevor die andere (der Nachfolger) begonnen werden kann. Diese Ende-Anfangs-Beziehung tritt mit Abstand am häufigsten aufund wird daher auch als Normalfolge bezeichnet. Eine Sprungfolge tritt auf, wenn Arbeiten überlappend ausgeführt werden müssen. Die eine Arbeit kann erst beendet werden, wenn die andere begonnen wurde. Bei der Anfangsfolge ist der Beginn zweier Arbeiten aneinander gekoppelt, bei der Endefolge besteht eine Kopplung bei deren Abschluss. Anfangs- und Endefolge findet man häufig bei Arbeiten, die parallel laufen aber nur in einer festen Reihenfolge begonnen bzw. beendet werden können.

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6_7, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

7.1 Anordnungsbeziehungen

163

Sprungfolge (AB: Anfang-Ende)

Anfangsfolge (AA: Anfang-Anfang)

~

U

U

Normalfolge (EA: Ende-Anfang)

~

Endefolge (EE: Ende-Ende)

~~ u

~

u

Bild 7-1 Anordnungsbeziehungen bei Arbeitspaketen

Zusätzlich zu den logischen Reihenfolge-Bedingungen kann es auch zeitliche Bedingungen geben: Die Nachfolge-Arbeit kann z. B. erst begonnen werden, nachdem der Vorgänger abgeschlossen ist und eine zusätzliche Zeit vergangen ist. Dies wird dann in Form von Zeitparametern berücksichtigt. Will man z. B. das Warten auf eine externe Zulieferung, das ja keinen projektinternen Arbeitsaufwand bedeutet, nicht als eigenen aufwandslosen, aber zeitbehafteten Arbeitsgang berücksichtigen, kann man die Zulieferung als Zeitparameter zwischen der Bestellung und der Verarbeitung einbauen. Anordnungsbeziehungen können auch zwischen mehr als 2 Elementen bestehen. Beschränkt man sich hier auf die Sprungfolge, so gibt es zwei Beziehungen: eine Verzweigung und eine Zusammenführung. Bei der Verzweigung löst das Ende der einen Arbeit den Anfang mehrerer Folge-Arbeiten aus. Bei der Zusammenführung müssen mehrere Arbeiten beendet sein, bevor eine Folge-Arbeit beginnen kann.

Beispiel7-1 Anordnungsbeziehungen Auf einer Großbaustelle soll die Bodenplatte für eine neue Halle betoniert werden. Dabei werden 6 Arbeitspakete und deren Beziehungen betrachtet. Tabelle 7.1 Anordnungsbeziehungen Nummer

Arbeitspaket

Aufwand

1

Annierung

1 Tag

2

Schalung

1 Tag

Anordnungsbeziehungen

3

Beton liefern

8 Std.

lEA;2EA

4

Betonieren Frühschicht

5 Std.

3AA;5AB

5

Betonieren Spätschicht

5 Std.

3EE

6

Steine liefern

1 Tag

5EA+2 Tage

Zunächst müssen der Einbau der Stahlarmierung und die parallel laufende Verschalung komplett fertig gestellt sein, bevor mit dem Betonieren begonnen werden kann (Normal-

7 Ablauf- und Terminplanung

164

folge, EA). Sobald mit der Anlieferung des Betons begonnen wird, muss er auch verarbeitet werden (Anfangsfolge, AA). Da das Betonieren länger dauert, wird in einer Früh- und einer Spätschicht gearbeitet. Zur Vermeidung von Verzögerungen arbeiten die beiden Schichten überlappend: Erst wenn die Spätschicht begonnen hat, darf die Frühschicht ihre Arbeit beenden (Sprungfolge AE). Die Spätschicht wiederum kann ihre Arbeit erst beenden, wenn die Betonlieferung fertig ist (Endefolge, EE). Verzögerungen bei der Betonanlieferung führen sofort auch zu Verzögerungen der Betonverarbeitung.

Bild 7-2 Anordnungsbeziehungen in graphischer Darstellung

Die Anlieferung der Steine, die auf der Bodenplatte abgestellt werden, kann erst erfolgen, wenn die Bodenplatte genügend ausgehärtet ist. Daher wird diese Normalfolge mit einer zusätzlichen Zeitbedingung (+ 2 Tage) versehen. Die Anordnungsbeziehungen haben für die Planung und auch später bei der Projektsteuerung große Bedeutung. Verschiebt oder verlängert sich ein Arbeitspaket, so führt dies direkt auch zu einer Verschiebung der damit gekoppelten Arbeitsgänge. Da diese wiederum Beziehungen zu anderen Arbeiten aufweisen können, kann sich eine Veränderung bei einer Arbeit auf viele andere auswirken. Besonders gravierend ist dies bei Arbeiten in frühen Projektphasen und mit vielfältigen Wechselwirkungen auf andere Arbeiten. Um die negativen Auswirkungen von Änderungen auf das Projekt zu verringern, versucht man, Arbeiten möglichst zu entkoppeln und Puffer einzubauen.

Beispiel7-2 Temperaturmessbox Zur Messung der Temperatur bei einer Pizza-Produktionslinie soll eine Messbox aufgebaut werden, die den berührungslos gemessenen Temperaturwert erfasst, aufzeichnet und über eine serielle Schnittstelle an die Maschinensteuerung überträgt. Aus der Projektplanung und der Aufwandsschätzung haben sich die dargestellten Arbeitspakete und die zugehörigen Zeitdauern ergeben. Beim Ablauf der Arbeiten müssen verschiedene Abhängigkeiten berücksichtigt werden. Nach der Aufgabenanalyse können die Auswahl des Gehäuses, der Entwurf der Schaltung und die Programmierung parallel beginnen. Der Aufbau der elektrischen Schaltung erfolgt nach dem Entwurf des Schaltplans. Der Programmtest setzt eine abgeschlossene Programmierung voraus. Sind Hardware und Software erstellt und für sich getestet, folgt der Systemtest. Bei der Montage der Komponenten im Gehäuse und der Inbetriebnahme laufen schließlich alle Arbeiten wieder zusammen.

7.2 Netzpläne

165 Vorgangsname

Anfang

Dauer

Ende

I

Vorgänger

1

Aufgabenanalyse

2 Tage 24.11.08 25.11.08

2

Gehäuse: Auswahl und Bestellung

8 Tage 26.11.08 05.12.08 1

3

Enlwurf Schanplan

5 Tage 26.11.08 02.12.08 1

4

Programmierung

9 Tage 26.11.08 08.12.08 11

5

Schanungsaufbau

6 Tage 03.12.08 10.12.08 3

6

Programmtest

4 Tage 09.12.08 12.12.08'4

7

Systemtestl-Wl/+SI/V

3 Tage 15.12.08 17.12.08 5;6

8

Monlage+Jnbetriebnahme

-

-

f---

2 Tage 18.12.08 19.12.08 7;2

Bild 7-3 Arbeitspakete für den Aufbau einer Temperaturmessbox

Die Darstellung eines Ablaufplans in tabellarischer Form ist zwar für einzelne Vorgänge recht übersichtlich. Die zwischen den Vorgängen bestehenden Abhängigkeiten und die Struktur des Gesamtablaufs sind aber in dieser Darstellungsform nicht gut zu erkennen. Hier bietet die graphische Darstellung in Form von Netzplänen deutliche Vorteile.

7.2 Netzpläne Ein Projektstrukturplan enthält eine Menge von Arbeitspaketen, zwischen denen Ablaufbeziehungen bestehen können. Die Ablaufbeziehungen legen fest, in welcher Reihenfolge die Vorgänge aufeinander folgen und welche Vorgänge parallel ablaufen können. Sie bilden die Basis zum Entwurf eines Ablaufplans. Die logische Anordnung der Arbeitspakete im Ablaufplan ist im Allgemeinen relativ komplex. Für eine bessere Übersicht bietet es sich an. Ablaufpläne graphisch, in Form von Netzplänen darzustellen [Schwarze 2006]. Aus Sicht der Netzplantechnik besteht ein Projektablauf aus drei Grundelementen. Ein Vorgang ist ein zeiterforderndes Geschehen im Projektablauf, welches einen definierten Anfang und ein definiertes Ende besitzt. Jedes Arbeitspaket aus dem Projektstrukturplan erscheint somit als Vorgang im Ablaufplan. Die wichtigste Kenngröße eines Vorgangs für die Ablaufplanung ist dessen Zeitdauer. Ein Ereignis ist ein Zustandsübergang im Projektablauf. Ein Ereignis tritt zu einem bestimmten Zeitpunkt auf, besitzt aber selbst keine Zeitdauer. Typische Ereignisse im Projektablauf sind Beginn und Abschluss eines Vorgangs. Das dritte Element sind Beziehungen, die zwischen Vorgängen und Ereignissen bestehen. Die Beziehungen können zeitlicher oder logischer Art sein; sie können fachliche, personelle oder materielle Ursachen haben. Die Kopplung zwischen dem Liefern der Steine und dem Einbringen des Betons in dem Beispiel der Bodenplatte hat eine fachliche Ursache und ist zeitlicher Art: Das Aushärten nimmt zwei Tage in Anspruch, bevor der Beton belastet werden kann. Zwischen dem Verschalen und dem Armieren besteht zunächst keine Beziehung: Beide Arbeiten können unabhängig voneinander erfolgen. Sollen beide Arbeiten aber von ein und derselben Person ausgefiihrt werden, entsteht eine personelle Beziehung, die einen sequentiellen Ablauf erfordert. Netze im Sinne der Graphentheorie stellen nur zwei Objekte zur Verfügung: Knoten und Kanten. Knoten repräsentieren Objekte, Kanten die Beziehungen, die zwischen den Objekten bestehen. In graphischer Form werden Knoten als Punkte, Kreise oder Rechtecke dargestellt.

166

7 Ablauf- und Terminplanung

Besitzen die Beziehungen zwischen den Objekten eine Wirkungsrichtung, so werden die Kanten als Pfeile dargestellt. In erster Linie ist ein Netz ein rein mathematisches Gebilde, das anschaulich graphisch dargestellt werden kann und erst durch die Zuordnung zu realen Sachverhalten eine praktische Bedeutung gewinnt. Die Zuordnung kann auf sehr unterschiedliche Weise erfolgen. Leider :führt dies dazu, dass in der Projektablaufplanung unterschiedliche, aber vom Aussehen leicht zu verwechselnde Typen von Netzplänen im Einsatz sind. Die Ursache missverständlicher Darstellungen liegt darin, dass Projektablaufpläne 3 verschiedene Grundelemente benötigen (Vorgänge, Ereignisse, Beziehungen), Netzpläne im Allgemeinen aber nur zwei Darstellungselemente zur Verfügung stellen (Knoten, Kanten). Ordnet man den Knoten Vorgänge zu und stellt die Beziehungen zwischen den Vorgängen als Pfeile dar, entsteht ein so genanntes Vorgangs-Knoten-Netz (VKN). Die Vorgänge bilden in dieser Darstellungsform die Netzknoten. Sie werden als rechteckige Kasten dargestellt und können verschiedene Informationen aufnehmen, wie z. B. Bezeichnung und Nummer des Vorgangs oder die geschätzte Dauer. Die Vorgänge sind über Pfeile miteinander verbunden. Jede Verzweigung hinter einem Vorgang und jede Zusammenführung vor einem Vorgang stellen ein Ereignis dar.

E1

E7

Bild 7-4 Ablaufplan als Vorgangs-Knoten-Netz für das Beispiel Temperatunnessbox

Man erhält eine gleichwertige, aber anders zu lesende Darstellung, wenn man die Ereignisse als Knoten dargestellt und die Vorgänge, die zwischen den Ereignissen ablaufen als Pfeile. Die Verwendung dieser so genannten Ereignis-Knoten-Netze (EKN) in der Ablaufplanung richtet einen stärkeren Fokus auf die Ereignisse und damit auf die Meilensteine im Projekt. Die Knoten, die hier Ereignisse repräsentieren, werden manchmal als Rechteck manchmal aber auch als Kreis dargestellt. Hinsichtlich der Zuordnung vergleichbar sind die Vorgangs-PfeilNetze (VPN). In der Literatur und auch in der praktischen Anwendung finden sich verschiedene Darstellungsformen, sowohl für Ereignis-Knoten als auch für Vorgangs-Knoten. Da die Ablaufnetze in erster Linie zur Terminbestimmung verwendet werden, sind die Darstellungen meist an die speziellen Methoden zur Terminplanung angepasst.

7.3 Planungsmethoden

167 V2:8

V4:9

V6:4

'------I~ E71-----J

Bild 7-5 Ereignis-Knoten-Netz (EKN)

Die Ablaufplanung hat zum Ziel, die Struktur des Gesamtablaufs festzulegen. Dazu werden die Beziehungen zwischen einzelnen Vorgängen berücksichtigt, die aus technischen oder organisatorischen Randbedingungen resultieren. Das Ergebnis der Ablaufplanung ist eine Ablaufstruktur, die als tabellarisch oder graphisch dargestellt werden kann.

7.3 Planungsmethoden "Ist es auch Wahnsinn, so hat es doch Methode. " (Shakespeare) Zur weiteren Konkretisierung der Planung kann als Nächstes die Terminierung der Arbeiten erfolgen. Hier geht es nicht nur darum, Anfangs- und Endtermin aller Vorgänge zu bestimmen, sondern auch eventuell vorhandene terminliche Spielräume zu erkennen. Die Schaffung zeitlicher Puffer ist notwendig, um später bei der Projektdurchführung unvermeidlich auftretende kleinere Abweichung vom Plan auffangen zu können, ohne die Projekt-Meilensteine zu gefährden. Im Wesentlichen geht es also in der Terminplanung darum, für jedes Arbeitspaket den frühest und spätest möglichen Anfangs- und Endtermin zu bestimmen. Hierzu gibt es mehrere Verfahren. Grundsätzlich kann man zwischen deterministischen und stochastischen Verfahren unterscheiden. Deterministische Verfahren, wie CPM und MPM nehmen die Schätzwerte für Aufwand und Zeitdauer als zutreffend an und berechnen daraus alle Termine. Stochastische Verfahren, wie z. B. PERT, berücksichtigen zusätzlich die Varianz der Schätzung und machen Aussagen über die Wahrscheinlichkeit, mit der die Termine auch eingehalten werden. Die drei genannten und hier auch in ihren Grundzügen vorgestellten Verfahren wurden etwa zur gleichen Zeit, Ende der 1950er Jahre, entwickelt. Die Bestimmung der Termine basiert auf den ermittelten Vorgangsdauern und den Vorgangsbeziehungen. Um früheste und späteste Termine für jeden Vorgang zu ermitteln, werden die Knoten der Netzpläne um entsprechende Zeitfelder erweitert.

7.3.1 Critical-Path-Method Bei dieser Methode wird in den rechteckigen Knoten eines VKN nicht nur die Bezeichnung des Vorgangs eingetragen, sondern auch die aus der Ablauf- und Terminplanung resultierenden Daten. Aus der Zeitschätzung für die einzelnen Arbeitspakete kann die Dauer D eines Vorgangs bestimmt werden. Sie ergibt sich aus dem Arbeitsaufwand dividiert durch den Personal-

7 Ablauf- und Terminplanung

168

einsatz. Zusammen mit den Ab1aufbeziehungen sowie den festgelegten Meilensteinbeziehungen können die charakterisierenden Termine für jeden Vorgang bestimmt werden. Dies sind frühester und spätester Anfangs- und Endzeitpunkt. Außerdem resultieren aus der Berechnung zwei Pufferzeiten: der freie Puffer und der Gesamtpuffer. Diese Werte können im Vorgangssymbol eingetragen werden: Die Terminplanungsmethode Critical-Path-Method (CPM) wurde 1956 vom Chemie-Unternehmen Dupont zusammen mit der Fa. Remington Rand entwickelt. Jedes Ereignis aus dem Ab1aufp1an wird bei CPM als abgerundeter Netzknoten dargestellt. CPM basiert also auf den Vorgangs-Pfeil-Netzwerken (VPN) bzw. den Ereignis-KnotenNetzen (EKN) und besteht aus zwei wesentlichen Schritten: der Vorwärtsrechnung und einer Rückwärtsrechnung.

i:D

~ F

j

S·

J Pi J

j: Ereignisnummer F: Frühester Ereignistennin S: Spätester Ereignistermin P: Puffer D: Dauer (des davor liegenden Vorgangs)

Bild 7-6 Ereignis-Knoten-Symbol der Critical-Path-Method (CPM)

Die Vorwärtsrechnung dient zur Bestimmung der frühest möglichen Ereignistermine. Zunächst erhält das Projektstartereignis den Termin 0 zugewiesen. Dann wird bei den Folgeereignissen mit Hilfe der Vorgangsdauer der jeweils frühest mögliche Anfangstermin berechnet. Führen mehr als ein Vorgang zu einem Ereignis Ej , so tritt das Ereignis erst dann ein, wenn alle Vorgänge abgeschlossen sind. Als frühester Ereignistermin muss als der späteste Fertigstellungstermin der vorangehenden Vorgänge genommen werden: F j = ~ax{Fj + D j } (i: alle vorangehenden Ereignisse)

(7.1)

I

Der früheste Ereignistermin Fj ergibt sich aus dem Maximum der frühesten Vorgängerereignistermine plus der Vorgangsdauer. Hat man das ganze Netz bis ans Ende gerechnet, so ist der früheste Endtermin des Projekts bekannt. Er wird dann in der Rückwärtsrechnung als Basis zur Bestimmung der spätesten Ereignistermine verwendet. Hier ergeben sich die Ereignistermine durch Subtraktion der Vorgangsdauer von den Terminen der Nachfolgeereignisse. Hat ein Ereignis mehrere Folgeereignisse, muss der minimale Termin als spätester Ereignistermin verwendet werden.

S j = Min{S k k

Dd (k: alle nachfolgenden Ereignisse)

(7.2)

Der späteste Ereignistermin ergibt sich aus dem Minimum der spätesten Nachfolgerereignistermine minus der Vorgangsdauer. Im letzten Schritt kann dann die Pufferzeit für jeden Vorgang bestimmt werden. Sie ergibt sich als der Abstand zwischen frühestem und spätestem Ereignistermin.

Pj = Sj -Fj

(7.3)

7.3 Planungsmethoden

169

Die Pufferzeit beschreibt, um welche Zeit ein Ereignis nach vorne oder hinten verschoben kann, ohne die gesamte Projektlaufzeit zu verändern. Pufferzeiten ergeben sich immer nur dann, wenn parallel ablaufende Vorgänge unterschiedlich lange dauern.

Bild 7-7 Beispiel eines Netzes bei der Critical Path Method

Alle Ereignisse mit Pufferzeit 0 und die dazwischen liegenden Vorgänge bilden den kritischen Pfad, der dem Verfahren seinen Namen gegeben hat. Die Durchlaufzeit des kritischen Pfades bestimmt die Projekt-Durchlaufzeit. Eine Verkürzung der Projektlaufzeit kann also nur auf dem kritischen Pfad erreicht werden.

7.3.2 Metra-Potential-Methode Die Metra-Potential-Methode (MPM) wurde 1958 vom französischen Unternehmen Metra entwickelt und erstmals beim Bauprojekt für ein Kreuzfahrtschiff angewendet. Jeder Vorgang aus dem Ablaufplan wird bei MPM als rechteckiger Netzknoten dargestellt. FA

FE

n: Vorgang D

I GP I FP

SA

SE

D: Dauer GP: Gesamter Puffer FP: Freier Puffer FA: frühester Anfangstermin FE: frühester Endtermin SA: spätester Anfangstermin SE: spätester Endtermin

Bild 7-8 Vorgangs-Knotensymbol der Metra-Potential-Methode

MPM verwendet also ein Vorgangs-Knoten-Netz. Die Vorgehensweise ist mit CPM vergleichbar. Allerdings werden nicht Ereigniszeitpunkte berechnet, sondern Anfangs- und Endtermine für die Vorgänge. Auch bei MPM werden zunächst in der Vorwärtsrechnung die frühesten Zeitpunkte FA j =~ax{FEi}

(7.4)

I

(7.5)

7 Ablauf- und Terminplanung

170

und dann in der Rückwärtsrechnung die spätesten Zeitpunkte bestimmt

SE j = Min{SA k }

(7.6)

SA j = SE j -D j

(7.7)

k

Der Vergleich der spätesten und der frühesten Anfangszeiten für jeden Vorgang liefert dessen Gesamtpuffer. Ist dieser größer Null, kann der Vorgang geschoben werden.

GPj =SE j -FEj =SAj -SEj

(7.8)

Min{FAk}-FE j

(7.9)

FPj

=

k

Bild 7-9 Beispiel eines Netzes bei der Metra-Potential-Methode

Die deterministischen Planmethoden, wie CPM und MPM beruhen auf der Annahme, dass die Vorgangsdauern exakt bekannt sind. Da es sich hierbei aber immer um Schätzwerte handelt, ist dies per se ein Widerspruch. Schätzwerte können nie ganz exakt sein. Werden sie trotzdem als verlässliche Werte verwendet, führt dies dazu, dass sich schon bei geringen Schätzfehlern im kritischen Pfad der Zieltermin verschiebt. Daher wird in der Regel eher vorsichtig, d. h. zu pessimistisch, geschätzt. Wird dies bei allen Vorgängen gemacht, entstehen unrealistisch große Projektlaufzeiten und späte Zieltermine. Um dies zu vermeiden, kann man in der Ablaufplanung statt eines einzigen Schätzwertes die Dreipunktschätzung mit optimistischen, realistischen und pessimistischen Schätzwerten verwenden. Die in den Schätzwerten zum Ausdruck kommenden Unsicherheiten lassen sich dann als Planungspuffer verwenden.

7.3.3 PERT-Methode Die Dreipunktschätzung wird konkret angewandt bei der PERT-Methode (program evaluation and review technique, [Miller 1965]). Sie arbeitet ähnlich wie CPM, verwendet aber die aus der Dreipunktschätzung berechneten Mittelwerte statt eines direkten Schätzwertes. Die Methode wurde erstmals 1958 beim amerikanischen Polaris-Projekt zur Entwicklung von Mittelstreckenraketen angewendet.

171

7.3 Planungsmethoden

Die Berechnungen bei PERT basieren auf der Annahme, dass der Zeitaufwand für die einzelnen Arbeitspakete Beta-verteilt ist. Der Grund für die Annahme sind praktische Beobachtungen. Zum einen ist der Aufwand nach unten und nach oben in der Regel begrenzt. Außerdem sind die Zeitwerte oft im unteren Bereich wahrscheinlicher, während sie nach oben immer mehr abflachen. Die Dichtefunktion ist also begrenzt und schief. Derartige Verläufe lassen sich durch eine Beta-Funktion beschreiben.

peT)

To: optimistisch Tw: wahrscheinlich Te: erwartet Tp: pessimistisch To

Tw

Te

Tp

T

I----I..~ z·Ts

Bild 7-10 Beta-Verteilung

Die besondere Bedeutung der Beta-Verteilung wird vor allem durch die einfache Handhabung erklärt. Wenn der kleinste, optimistische (To), der größte, pessimistische (Tp) und der wahrscheinlichste Schätzwert (Tw) bekannt sind, können Erwartungswert Te und Standardabweichung Ts der Verteilung wie bei der Dreipunktschätzung berechnet werden.

Te= To+4·Tp+Tw 6

(7.10)

Ts = Tp-To

(7.11)

6

Wird nun für jedes Arbeitspaket eines Projekts die Dauer durch Dreipunktschätzung ermittelt, so kann auch die Laufzeit des Gesamtprojekts ermittelt werden. Hierzu werden die Einzelschätzungen der Arbeitspakete auf dem kritischen Pfad addiert. Die Addition der Schätzwerte führt zu einer Überlagerung der Verteilungsfunktionen. Hierbei nähert sich die SummenVerteilungsfunktion immer mehr einer Normalverteilung an. Somit kann die Verteilungsfunktion der Projektlaufzeit mit einer gewissen Berechtigung als normalverteilt angesehen werden. Die vielfältig dokumentierten günstigen Eigenschaften der Normalverteilung kann man somit zumindest näherungsweise für die Projektschätzung nutzen. Beispiel7-3 PERT-Projektanalyse Ein vor der Beauftragung stehendes Projekt wurde vom Projektleiter mit einem Personalaufwand von 275 Tagen abgeschätzt. Eine Aussage über die Güte dieser Schätzung konnte der Projektleiter nicht machen. Auch eine Aussage über die voraussichtliche Laufzeit war ohne genauere Analyse nicht machbar. Daraufhin wurde die Projektskizze den potentiellen Beteiligten aus dem Unternehmen präsentiert. Am Ende der Präsentation gab jeder Teilnehmer eine Zeitschätzung ab, ohne die Schätzung des Projektleiters zu kennen. Die optimistischste Schätzung lag bei 200 Tagen, die pessimistischste bei 350 Tagen und der wahrscheinlichste Wert bei 250 Tagen.

7 Ablauf- und Terminplanung

172

Unter Verwendung der Formel der Dreipunktschätzung konnte damit der Erwartungswert Te=258 Tage und die Standardabweichung Ts=25 Tage bestimmt werden. Daraus wiederum ergab sich die Verteilungsfunktion F(A) für den Aufwand A: Tabelle 7.2 Verteilungsfunktion F(A) des Aufwands A z

0,00

A=Te+z·Ts

258

F(A)

50%

0,25

0,52

0,84

1,28

1,64

2,00

265

271

279

60%

70%

80%

290

299

308

90%

95%

98%

Wie die Tabelle zeigt, hatte der Projektleiter intuitiv seine Aufwandsschätzung so gelegt, dass er den prognostizierten Wert mit einer Wahrscheinlichkeit von etwa 75 % einhalten konnte. Um nun zu einer Aussage über die Durchlaufzeit und zu noch genaueren Aussagen über den Aufwand zu kommen, wurde das Projekt in insgesamt 10 Arbeitspakete aufgeteilt. Dann wurde der Zeitbedarf für jedes Arbeitspaket durch drei Punkte geschätzt. Mit Hilfe des Ablaufplans konnte dann aus diesen Werten der kritische Pfad, dessen Durchlaufzeit und der Gesamtaufwand für das Projekt ermittelt werden. Tabelle 7.3 Geschätzte und berechnete Zeitwerte Vorgang

Dauer

Al

30

A2

20

A3

20

BI

60

B2

30

Cl

35

To

Tw

Tp

Te

Ts

20

25

40

26,7

3,3

Al

15

18

25

18,7

1,7

Al

10

15

20

15,0

1,7

Al

40

50

90

55,0

8,3

A2

25

30

40

30,8

2,5

A3

25

30

45

31,7

3,3

Vorgänger

C2

15

BI; B2; Cl

10

12

15

12,2

0,8

D1

20

A2

10

15

20

15,0

1,7

D2

25

D1

20

25

30

25,0

1,7

D3

20

C2;D2

20

25

35

25,8

2,5

Laufzeit

90,0

112,0

180,0

119,7

9,4

Gesamtaufwand

195

245

360

255,9

10,7

Man erhielt nun einen kaum veränderten, erwarteten Aufwand von knapp 256 Tagen. Die Standardabweichung und damit auch die Unsicherheit der Vorhersage hatten sich aber von 25,0 Tagen auf 10,7 Tage deutlich verringert. Der kritische Pfad bestand aus den Vorgängen Al, BI, C2 und D3. Seine Laufzeit besaß einen wahrscheinlichsten Wert von 112 Tagen, einen Erwartungswert von 119,7 Tagen und eine Standardabweichung von 9,4 Tagen. Mit einer Wahrscheinlichkeit von 98 % konnte also das Projekt innerhalb von maximal 139 Tagen realisiert werden. Der Arbeitsaufwand hierfür betrug maximal 277 Personentage. So gesehen, hatte der Projektleiter seine zu Beginn gemachte Aussage mit nicht nur ausreichend, sondern üppig abgesichert.

7.3 Planungsmethoden

173

Die PERT-Analyse ermöglicht es also nicht nur, Aussagen über den Gesamtaufwand und die Durchlaufzeit für ein Projekt zu machen, sondern durch Verwendung der Dreipunktschätzung gelingt es zudem, Aussagen über die Wahrscheinlichkeiten zu machen, mit denen bestimmte Zusagen beim Aufwand und bei der Laufzeit eingehalten werden können. Beispiel 7-4 Kritischer Pfad beim Temperaturmessbox -Projekt Der kritische Pfad beim Temperaturmessbox- Projekt besteht aus 5 Vorgängen (VI, V4, V6, V7 und V8). Die optimistische, realistische und pessimistische Schätzung der Zeitbedarfe hat die Werte in der Tabelle ergeben. Mit Hilfe der Näherungsformeln der Dreipunktschätzung können Erwartungswert und Standardabweichung für jeden Vorgang ermittelt werden. Die Summe der Einzelwerte ergibt entsprechend eine optimistische, eine realistische/wahrscheinlichste, eine pessimistische und eine erwartete Projektlau1Zeit. Vorgang

TO

TR

TP Mittelwert Stdabw.

V1

2

V4 \Il3

6

2 9 4 3 2 20

4 15 6 6 31 34

V7 'vB Summe

3 2 2

15

2,3 9,5 4,2 3,3 2,2 21 ,5

0,3 1,5 0,5 0,7 0,2 1,8

Bild 7-11 Schätzwerte für den kritischen pfad des Temperaturmessbox-Projekts

Im besten Fall könnte das Projekt in 15 Tagen abgeschlossen werden. Dazu müssten aber alle Arbeitspakete optimal laufen. Die Wahrscheinlichkeit hierfür ist sehr gering. Genauso unwahrscheinlich ist es aber, dass alle Arbeitspakete die maximale Dauer beanspruchen und das Projekt dadurch 34 Tage braucht. Wahrscheinlicher ist es, dass die Projektlaufzeit im mittleren Bereich liegt. Zur Berechnung der Wahrscheinlichkeit benötigt man zunächst den Erwartungswert und die Standardabweichung:

(7.12)

(7.13) Mit Te=21,5 Tage und Ts=I,8 Tage folgen dann die angegebenen Wahrscheinlichkeiten :fiir die verschiedenen Durchlaufzeiten des kritischen Pfads. Tabelle 7.4 Verteilungsfunktion F(T) der Projekt-Laufzeit T T

17,9 Tage

19,7 Tage

21,5 Tage

23,3 Tage

25,1 Tage

F(T)

2%

18%

50%

84%

98%

174

7 Ablauf- und Terminplanung Die Wahrscheinlichkeit, den erwarteten Wert einzuhalten, beträgt 50 %. Sie steigt auf 84 % bzw. 98 %, wenn die einfache bzw. doppelte Standardabweichung berücksichtigt wird. Genauso drastisch sinken die Erfolgsaussichten, wenn Laufzeiten unterhalb des erwarteten Werts genannt werden!

7.3.4 Gantt-Diagramme Das Erstellen eines Netzplans und die Berechnung der Termine ist selbst bei kleinen Projekten mit z. B. 100 Arbeitspaketen recht aufwändig. In manueller Form ist dies kaum durchführbar. Zudem sind spätere Änderungen ebenfalls sehr arbeitsintensiv. Deshalb wurde bereits bei den Ende der 1950er Jahre entwickelten Planungsverfahren auf Rechner zurückgegriffen. So wurde z. B. CPM auf einem UNNAC-Rechner implementiert. Mit der enormen Verbreitung von Rechnern und dem Entstehen rechnerbasierter Projektplanungswerlezeuge stehen geeignete Hilfsmittel auch schon :für kleine Projekte zur Verfügung. Moderne Planungswerlezeuge können viele Arbeits- und Rechenschritte automatisch ausführen. Gerade bei Änderungen von Plänen macht sich dies vorteilhaft bemerkbar. Gleichzeitig hat der zunehmende Rechneremsatz bei der Planung Unterschiede der einzelnen Planungsmethoden unwichtig werden lassen. Die Anordnungsbeziehungen der Vorgänge und deren Termine bilden eine in Tabellenfonn gespeicherte Datenbasis. Eine graphische Darstellung dieser Daten egal in welcher Form - stellt nur noch eine bestimmte Sichtweise auf die verknüpften Daten dar. Ist einmal die Terminplanung gemacht und gespeichert, kann jederzeit zwischen den verschiedenen Sichtweisen umgeschaltet werden. Vorgangsname Aufgebenenlllyse Gehäuse: Auswehl und Bestellung Entwurf SChllnpllln Programmierung Scha.ungsaulbau Programmtest Systemtest HW+SW Montage+lnbelriebnahme

Bild 7-12 Gantt-Diagramm des Temperaturmessbox-Projekts

Bei den Tools erfreut sich eine Darstellungsart besonderer Beliebtheit, die schon 1910 vom amerikanischen Ingenieur H. Gantt entwickelt wurde. Bei diesem nach seinem Erfinder benannten Diagramm werden Vorgänge durch Balken dargestellt, deren Länge der Zeitdauer entspricht. Die proportionale Umsetzung der Zeitdauer eines Vorgangs in eine Balkenlänge sorgt :für eine anschauliche und aufAnhieb verständliche Darstellung des Projektablaufs. Das Gantt-Diagramm war allerdings nicht als Hilfsmittelfür die Erstellung eines Plans, sondern nur zur anschaulichen Darstellung des Planungsergebnisses geeignet. Die logischen und zeitlichen Anordnungsbeziehungen zwischen den Vorgängen waren nicht erkennbar. Deshalb wurden die Diagramme unter der Bezeichnung Plannet (planning Network) weiterentwickelt. Die Anordnungsbeziehungen zwischen den Vorgängen werden durch Pfeile zwischen den

7.3 Planungsmethoden

175

Balken symbolisiert. Mit der zunehmenden Verbreitung der Netzplandarstellung mit Hilfe rechnergestützter Werkzeuge konnten sich die auf den Gantt-Diagrammen und der PlannetTechnik. basierenden Methoden als Planungswerkzeuge auf breiter Front durchsetzen. Heute bietet praktisch jedes Planungswerkzeug eine Darstellung eines Terminplans als GanttDiagramm an. Dadurch kann bei Änderung von Tenninen, auch die graphische Darstellung auf Knopfdruck aktualisiert werden. Beispiel7-5 Fallbeispiel ,,Maschinentenninal M4": Gantt-Diagramm Das folgende Bild zeigt aus dem Projektstrukturplan des Maschinenterminals, einen Teil der Arbeiten zur Elektronikentwicklung. Die Dauer der Arbeiten wurde geschätzt und in der Tabelle eingetragen. Außerdem wurden die Anordnungsbeziehungen berücksichtigt. Name

23

Marktübersicht embedded-CPUs

24

Auswahl und 8estellung CPU-8augruppe

I I

25 26

27

31 tage

l

5 tage

29

I

30

o tage J24EA+ 15 tage

Klärung mit Hersteller Folientastatur

2 tage 29

Aufbau Laborprototyp PC8-Layout

32

1 tag 26

Eingang Textdisplay --- ---Schaltungsentwurf Anwendungsschaltung

~ Funktionstests + Schaltungsmodifikation

31

-

-

2 tage 23EA+6 tage ----

r-

Eingang CPU-Baugruppe

~uswahl und 8estellung Textdisplays

26

Vorgänger

Dauer

BElektronik

22

o tage 27EA+ 15 tage ---'10 tagel

1--

4 tage 29 8

tag~~

4 tage 31

33

Platinen bestellen

1 tag 32

34

Platinen bestücken

1 tag 33

35

Musteraufbau

-

3 tage l25j28j34

Bild 7-13 Die Arbeiten für die Elektronik-Entwicklung als Tabelle ...

Name

Nov08

$

GElektronlk Marktübersicht embedded-CPUs Auswahl und Bestellung CPU-Baugruppe Eingang CPU-Baugruppe Klärung mit Hersteller Folientastatur

Auswahl und Bestellung Textdisplays Eingang Textdisplay -- ---Schaltungsentwurf Anwendungssch31tun Aufbau Laborprototyp Funktionstests

+ Schaltungsmodifikation

PCB-Layout Platinen bestellen

Platinen bestücken Musteraufbau

Bild 7-14 ... und als Gantt-Diagramm

Dez 08

•

7 Ablauf- und Terminplanung

176

Die Lieferung einer bestellten CPU-Baugruppe bzw. eines Textdisplays verursacht zwar keinen Aufwand, kostet aber Laufzeit. Diese Zeiten werden als zusätzliche Zeitbedingungen (+15 Tage) berücksichtigt. Das gleiche gilt für die angeforderten Informationen für die Auswahl einer CPU-Baugruppe (+6 Tage). Das Eintreffen der Lieferungen wurde dabei als Vorgänge mit der Dauer 0 modelliert. Diese Vorgänge werden dann beim Musteraufbau als Vorgänger berücksichtigt, da ein Mustergerät erst aufgebaut werden kann, wenn alle Komponenten vorhanden sind. Schon bei einer geringen Zahl von Vorgängen ist es schwer, den Überblick über den Ablauf zu behalten. Die graphische Darstellung besitzt hier enorme Vorteile. Hier werden die Abhängigkeiten der Arbeiten sowie die Zeitbedingungen offensichtlich. Selbst bei umfangreichen Ablaufplänen sind die wesentlichen Strukturen, wie z. B. sequentielle und parallele Abläufe sofort erkennbar.

7.4 Kapazitätsplanung Zusätzliches Personal am Projektende verschlimmert die Probleme, die zu wenig Personal am Anfang verursacht hat. In den vorangegangenen Planungsschritten wurden bei der Aufwandsschätzung und der Ablaufplanung unbegrenzt verfügbare Kapazitäten angenommen. Bei der Planung der Arbeitspakete und der Termine wurden lediglich die Anordnungsbeziehungen zwischen den einzelnen Arbeiten berücksichtigt. Diese legen fest, ob die Vorgänge gekoppelt geplant werden müssen oder ob sie unabhängig voneinander angeordnet werden können. Bei der Terminierung der Vorgänge wurde angenommen, dass ein Arbeitspaket von einer Person bearbeitet wird und dass diese im gewünschten Zeitraum verfügbar ist. Unter dieser Voraussetzung ist die Dauer für die Bearbeitung eines Vorgangs identisch mit dem Zeitaufwand für das Arbeitspaket. Diese Annahme erleichtert die Terminierung, ist aber nicht sehr realitätsnah. In praktischen Projekten müssen vielfältige Einschränkungen berücksichtigt werden. Die Zahl der im Projekt arbeitenden Personen ist begrenzt, nicht alle Personen stehen über die gesamte Projektlaufzeit zur Verfügung und sie stehen auch nicht immer zu 100 % ihrer Arbeitszeit zur Verfügung. Das gleiche gilt für die materiellen Ressourcen, wie Maschinen, Arbeitsplätze, Rohstoffe. Auch hier gibt es Einschränkungen der Verfügbarkeit. Nicht zuletzt müssen auch die Kosten im Auge behalten werden, da das Gesamtbudget meistens nicht beliebig eingesetzt werden kann, sondern nur zeitlich gestaffelt freigegeben wird. Aufgrund derartiger Einschränkungen kann die Ablauf- und Terminplanung zunächst nur als erster, grober Schritt in einem iterativen Planungsprozess angesehen werden. In den nachfolgenden Schritten müssen die praktischen Einschränkungen berücksichtigt werden und in eine Feinplanung einfließen. Die terminierten Ablaufpläne enthalten alle Vorgänge eines Projekts, d. h. in ihnen wurden die Arbeitspakete mit Anfangs- und Endterminen versehen. Die Vorgänge des kritischen Pfads legen die Projektlaufzeit fest, während es bei den anderen Vorgängen zeitliche Puffer gibt, in denen die Vorgänge nach vorne oder hinten verschoben werden können, ohne die Projektlaufzeit zu vergrößern. Außerdem bilden die Anfangs- und Endzeitpunkte der Projektphasen Meilensteine, an denen der Projektfortschritt später überprüft werden kann. Zur Durchführung des Projekts müssen die Arbeiten, die in einem Vorgang zu erledigen sind, Personen zugeordnet werden. Das gleiche gilt für Maschinen, Werkzeuge oder Rohstoffe, die im Vorgang benötigt werden. Legt man für jeden Vorgang eine Person fest, die den Vorgang

177

7.4 Kapazitätsplanung

bearbeitet, so ergeben sich wegen der bestehenden Terminierung unmittelbar auch die Zeiträume, zu denen Personen im Projekt arbeiten müssen. Da bei der Terminierung der Vorgänge keine Rücksicht auf personelle Randbcdingung genommen wurde, ergibt sich eine mehr oder weniger zufällige zeitliche Verteilung der personellen Kapazitäten. Das typische Aussehen dieses Belastungsdiagramms macht deutlich, wamm hier oft von einem ,,Kapazitätsgebirge" gesprochen wird. Beispiel 7-6 Prozesssteuerung

Bei den Steinbachwerken soll eine mikroprozessorbasierte Prozesssteuerung aufgebaut werden. Das folgende Bild zeigt den Projektstrukturplan. Unter Berücksichtigung des geschätzten Zeitaufwands und der Anordnungsbezi.ehungen ergibt sich der dargestellte Ablauf. Die Laufzeit beträgt 9 Wochen, bei einem Gesamt-Arbeitsaufwand von 24 Persenenwochen. VC
El

"~

, ,• • , • " " ;

"n " "

,Y"'1l'<"

121Tog~

Proze••steuerung

"-

Gmbkonz
_kt""""",e

10 To'7'

Sichefhel"",rtlinie

~;-

Ge!l/iu,e""-,,,wohl

5Toge :l

ScMlLO;l,m""",f

10T_ 2

PrCVommert"",-"j

5Toge :l

Aufbou ~,••,,"ef,cMlco;

5Toge 6

Te,;!

5Toge 8

~,;jefocMlLO;l

ScMlLO;l'''YO
10Toge S

PrcvOlTllflef,;!eLo;l

10 To'7' 7

PrcvMllfte,;!

10T_ll

Auf_Prototyp

10T_13

DokLrne
10Toge 10;12

•

e, e, e, e, e,

•

" "

.,

"

l' -,

e, e, e, e, e, e, e,

5Toge 10;12

Sy,;tontesl

Re", KWL! KWn KW2. KW:l5 KW26 KWH KW28 KW29 KW3lJ KW3t K\

"

~,

"

DDd 7-15 Terminierter Ablaufplan mit personeller überlast

"

"

Für das Projekt stehen nur die beiden Mitarbeiter PI und P2 zur Verfiigung. Mitarbeiter PI ist Hardware-Entwickler, Mitarbeiter P2 Software-Entwickler. Die Arbeitspakete werden den Mitarbeitern entsprechend ihrer fachlichen Qualifikation, wie oben dargestellt, zuge-

ordnet. K(t)

500%--400%--300% -

_~_~_~ __ ~_~_~_~_~__ ~_~_l

,

,

, , , , , , , ' :--:--~-+-~--:--:--~-~

,

=""2z,,'--:--~ -+- ~ - -:- -:- - ~ - ~' I

I __

,

200% 100%

23

'25'

'27'

,

'29'

,

, ,

, , , , , , ' _.., __ f-_I-_l. , , , ,'

--,--,--,--r--'-

'31 '

KW

DDd 7-16 Belastungsdiagramm ("Kapazitätsgebirge")

178

7 Ablauf- und Terminplanung Unschwer ist zu erkennen, dass bei den Mitarbeitern zeitweise Überlasten auftreten. Dies ist bei den gegebenen Rahmendaten unvermeidlich. Bei einem Arbeitsaufwand von 24 Personenwochen und 2 eingesetzten Personen ergibt sich eine Mindestlaufzeit von 12 Wochen. Wollte man das Projekt tatsächlich in 9 Wochen realisieren, wäre zusätzliches Personal nötig. Den theoretischen Wert von 2,7 Personen (24 PW /9 W) könnte man erreichen, indem eine zusätzliche Person zeitweise im Projekt mitarbeitet.

Stehen in einem Projekt N Personen zur Verfügung und ist ein Gesamtaufwand A, z. B. gemessen in Personentagen zu leisten, so ergibt sich theoretisch eine minimale Laufzeit T=AIN für das Projekt. Dies würde aber bedeuten, dass das Personal in vollem Umfang exakt für die Projektzeit zur Verfügung steht, und dass es für alle Beteiligten vom Projektstart bis zum Projektende etwas Sinnvolles zu tun gibt (im Bild rechts dargestellt). Beide Annahmen sind praxisfern. K(t)

K(t)

Bild 7-17 Reale und ideale Belastungs-/Auslastungsdiagramme

In der Regel wird am Anfang eines Projekts noch nicht das gesamte Personal benötigt. Bei der Analyse einer Aufgabe und beim Entwurf möglicher Lösungen kommt man oft mit einigen wenigen Personen aus. Im weiteren Fortgang des Projekts, während der Realisierungs- und Testphase steigt dann der Personalbedarf an. Wenn die heiße Phase eines Projekts überstanden ist, folgen oft noch einige Arbeiten, wie z. B. Fehlerbehebung, Dokumentationsnachträge und Restarbeiten, die nicht mehr so personalintensiv sind. Das Belastungsdiagramm in realen Projekten (im Bild links) besitzt daher oft einen buckelf6rmigen Verlauf, der mit etwas Phantasie an einen Waltisch erinnert. Unter Kapazitätsplanung versteht man nun die Berücksichtigung aller personellen Randbedingungen im Projektablauf. Eine gravierende personelle Randbedingung kann die begrenzte Zahl von Personen sein, die in einem Projekt zur Verfügung stehen. Im Kapazitätsgebirge macht sich dies durch eine feste obere Grenze bemerkbar. Mindestens genau so gravierend sind begrenzte Kapazitäten bei bestimmten fachlichen Qualifikationen. Wenn z. B. in einem Projekt 7 Personen zur Verfügung stehen, aber nur 2 mit Programmierkenntnissen, nutzen die anderen 5 Personen nichts, selbst wenn sie vorübergehend nichts zu tun haben sollten. Weitere typische Einschränkungen äußern sich so, dass manche Personen nur in bestimmten Zeiträumen zur Verfügung stehen oder nur einen bestimmten Prozentsatz ihrer Arbeitszeit für das Projekt einsetzen dürfen. Gründe hierfür können die weiterhin bestehenden Aufgaben in der Linienfunktion sein, die gleichzeitige Mitarbeit in mehreren Projekten oder sie können auch privater Natur sein.

179

7.4 Kapazitätsplanung

Zur Kapazitätsplanung stehen verschiedene Maßnahmen zur Verfügung. Unproblematisch ist die Verschiebung eines Vorgangs, wenn dieser genügend Puffer besitzt. In vielen Fällen reicbt dies nicht aus. Dann müssen Termine auf dem kritischen Pfad verändert werden, was natürlich Auswirkungen - meist unangenehme - auf die Meilensteine hat Beispiel 7-7 Kapazitätsplanung

Der folgende Proje1dstrukturplan zeigt die Arbeitspakete eines Software-EntwicklungsProjekts mit den zugehörigen Arbeitsaufwänden. Die Arbeitspakete wurden den drei Personen A, Bunde zugeordnet Die Abarbeitung der Analyse und der Konzepterstellung erfolgt sequentiell, da B und C in einem anderen Projekt eingebunden sind. Mit dem Beginn der Codierung arbeiten alle 3 parallel. Vorgangsname

1111) hge F~~i;;;i;i;iiiii;i;;i;ii~;i;;;iii:;;ii~iii:iiiiiiiii~ii;i;iiiiiii~iii;i;iiii;;~i;;i;iiiiii;i;i;;;i~iiiii;i;i;i;~,

EI SW-Pl"ojek1

:r:~,:~:~,,~::~~:rts

1~~:::1

EI Codierung

25 Tage

Programmierung Benutzerschnitistell,l

Detenbankan~jndUnl

Programmierung Det:enverarbeitung

EI Komponententest

_

15 Tage

I

28 T8ge

~I 8 Tegel

Test Detenbankanbindung

12 Tage

Test Dfflenvertlrbertung

~I

-

EI Systemte~

20 Tage

_

I

~I

_ _ systemtest _

EI

__

25 Tage

Test COM-Sehn"ste"e

-

A

20 Tage

Test Benutzerschnrtlstelle

_

~'iiiiiiiiiiiiiiii~iiiiiiii~:"'_.L

I

12 Tage I

Programmierung (aM-Schnittstelle

Programmierung

~I

10 TEIge I 25 Tage

Erstellung Grobkonzept Erstellung Feinkonzept

- 2:°

DOk~:~=~n

TTaa;:

8enutzerhandbuch

C

I

~I

-

Programmdokumentation

20 Tage

Übergtlbe, Schulung, Abnohme

-

lii C

5 TOgel

BOd 7-18 Projek:tplan des Software-ProJekts ohne Kapazitätsausgleich

Bei der Zuordnung der Arbeitspakete wurde nicht auf die Kapazitätsbegrenzungen geachtet. Von KW 24 bis zum Fertigstellungstermin in KW 36 kommt es zu deutlichem überschreiten der verfügbaren Kapazität bei B und C. K(t) 500% - 400% 300% 200%

100%

I -i I

I

I

I

I

I

I

I

I

-+ - -+ - +- -

I

I

I

I

t- -t- -,- -i- -i I

I

I

I

I

I

I

I

I

I

I

I-- -I-I I

-+ - + - +- -

I

~iiiii:~~

,-,I

T

,

r

r

, -,

I

I

I

I

I

I

I

"""'"

mw I

I

'15'

I

I

'17'

I

I

'19'

I

I

'21'

I

I

-l::::::J-

0

I

I

I

I

I

I

+

I

I

I

I

'31'

'33'

BOd 7-19 Belastungsdiagramm mit erkennbaren überlastungen

+

t- -,

,

I

I

I

-i I

--i

I

,

, --,

-,

-,-

'39'

,

I

'29'

I

t-

I

'27'

I

~~ii::i-:~

,

'23' '25' ~

I

--J - --l _..I- _..I- - I-- _I--- -,- -,- -J - --l _..II I I I I I I I I I I

'35'

:~ I

'37'

!'S.

I

I I

I

I

i i KW

7 Ablauf- und Tenninplanung

180

Da A nur bis KW 27 im Projekt eingeplant ist, liegt es natürlich nahe, einige der Arbeiten von B oder C auf A zu verlagern. Doch dies alleine kann das Problem nicht lösen. Von KW 24 bis KW 36 sind insgesamt 42 Personenwochen zu leisten, es stehen aber nur 39 Personenwochen (3 Personen a. 13 Wochen) zur Verfügung. Da der Beginn der Codierung in KW 24 nicht vorgezogen werden kann und kein zusätzliches Personal verfügbar ist, scheint eine Tenninüberschreitung unvermeidlich. Als die Notwendigkejt einer Terminüberschrejtung dem Auftraggeber angedeutet wird, beroft dieser sich aber auf den eingegangenen Verpflichtungen Er beharrt deshalb auf der Einhaltung des Termins. Vorgangsneme

=t'

Dauer

=C:C7:C~,--------I"7:-:::----EI SW-Projelct

132 Tage

Analyse des Lastenhetts Erstellung Pflichtenhetl

Erstellung Grobkonzept

_

j

~ _ ...

•

.. !'.'

10 Tage

Erstellung Feinkonzepl.

EI Codierung

5 Tage 10 Tage

01 APril ; 01 Mal \ 01 Juni /01 Juli ' 01 August ; 01 September 01 Old i r i KVV12 KW14'kW16 kW18 KVV20'KW22 kW24'kW26 KW28 l KW30 KW32 kW34 kW36 KVV38 KVV4

25 Tage

_

A

35 Tage

Programmierung BenutzerSChnitistelr-- 25 Tage Programmierung (DM-Schnittstelle

I

Programmierung Datenbankanbindun! Programmierung

12 Tage

15 Tf1ge 20 Tage

Datenverarbe~ung

EJ Komponent.ent.est

35 Tage

Test Benutzerschnittstelle

12 Tage

Test COM-Schnittstelle

8 Tage

Test Datenbankanbindung

12 Tage

Test Datenverarbeitung

20 Tage

EI Systemtesf

20 Tage

Systemtest

20 Tage

Systemtest

20 Tage

ElDok~

I

_ _35Tage

Benutzerhandbuch

15 Tage

Programmdokumentation

20 Tage

Übergabe, Schulung, Abnahme

5 Tage

l'-iiiiiiiiiiiiiii_

A

Bild 7-20 Modifizierter Projektplan des Software-Projekts mit Kapazitätsausglcich Der Projektleiter setzt sich noch einmal mit dem Team zusammen und nach einer detaillierten. Analyse des Projektplans finden sie eine mögliche Kompromisslösung, bei der der Abgabe1eJmin eingehalten werden. kann. Folgende Maßnahmen werden ergriffen: 1. Programmierung und Test der Datenbankschnittstelle wird von B aufA verlagert. 2. A macht auch das Benutzerhandbuch und die Programmdokumentation. 3. Mit dem Auftraggeber wird vereinbart, dass die Programmdokumentation zum Übergabezei1punkt in KW 36 noch nicht vorliegen muss, sondern in KW 40 nachgereicht wird 4. Der Systemtest durch B und C beginnt bereits, während A noch am Test der Datenbankschnittstelle atbeitet. Dann werden die Arbeiten so geschoben, dass keine Kapazitätsüberschreitungen mehr auftreten. Das obige Bild zeigt den geänderten Projektplan Im Kapazitätsdiagramm erkennt man, dass mit diesen Festlegungen keine Engpässe mehr auftreten.

7.4 Kapazitätsplanung

181

K(t) 500% -"

400%-

I 1

-I

I

I

-I

I

I

I

I

I -

I -

J-

1-

I

I

I

I

'1ltt

j

1_".

I

1'-'-

I

,

,

1_

1_

I

I

,

l-

-

-

-

l-

I

-

-

I

--, -

-

~I

-

1

-

-r

, --l--.-----~---

I I I I I I I I I I I I' , 300% - - -;I - -Il - -,I - 'I - -II - .-I - "-I - ,..I - ,-I - ~~~~~~~~~~~~~l~ 200% ----,---,-'1-,-,-,-,-,-,I

I

I

I

I

I

I

I

I

'2~ '25'

'29'

'31'

'33'

'39'

KW

Bild 7-21 Belastungsdiagramm mit eingehaltenen Kapazitätsgrenzen

Wenn die Verlängerung der Projektlaufzeit nicht zulässig ist, hilft nur die vorübergehende Aufstockung der personellen Kapazität bei den kritischen Arbeiten, wobei natürlich die entsprechende fachliche Qualifikation zu berücksichtigen ist. Allerdings hat die personelle Aufstockung Nebenwirkungen zur Folge. Zusätzliche Personen im Projekt kosten nicht nur mehr reine Arbeitszeit, sondern sie benötigen zusätzliche Einarbeitungszeit und sie verursachen Mehraufwand für Kommunikation und Koordinierung. Aus diesem Grund sollte vor einer Entscheidung für personelle Aufstockung Klarheit geschaffen werden über den dadurch mehr als proportional steigenden Aufwand. Auch ein kurzes Gedenken an die Erfahrungen von Brooks kann hier angebracht sein: ,,Adding manpower to a late project makes it even later." Die Umsetzung der personellen Bedingungen im terminierten Ablaufplan ist in der Regel nicht einfach, da ja auch die Anordnungsbeziehungen der Arbeitspakete, die Terminvorgaben für die Projektphasen, die Kostenbedingungen und die Ressourcenverfügbarkeit berücksichtigt werden müssen. Ein grundsätzlicher Konflikt bei der Kapazitätsplanung besteht zwischen möglichst kurzer Projektlaufzeit und möglichst geringem Aufwand. Um hier einen akzeptablen Kompromiss zu fmden, sind oft mehrere iterative Planungsdurchläufe erforderlich. Dabei sollte immer vom Groben zum Feinen vorgegangen werden, d. h. zunächst sollten grundlegende Terminfestlegungen getroffen werden, die aber noch gewisse Puffer offen lassen, die dann in den anschließenden Iterationen für die Feinjustierung genutzt werden können. Der Feinabgleich bei der Kapazitätsplanung ist auch später bei der Projektdurchführung immer wieder nötig, weil z. B. Arbeiten länger dauern als ursprünglich geplant oder weil eingeplantes Personal unvorhergesehen nicht zur Verfügung steht. Um in solchen Situationen nicht sofort die gesamte Planung erneut durchführen zu müssen oder gar den schönen Plan zu den Akten zu legen und nur noch im Freiflug - oder sollte man eher von einem Blindflug sprechen? - das Ziel zu suchen, sollte die Terminplanung unbedingt einige Pufferzeiten offen halten.

7 Ablauf- und Terminplanung

182

7.5 Repetitorium 7.5.1 Checklisten Tabelle 7.5 Checkliste Ablauf- und Tenninplanung

1.

Wurden alle Anordnungsbeziehungen zwischen den Vorgängen erfasst?

2.

Wurden dabei auch zeitliche Bedingungen berücksichtigt?

3.

Nach welcher Methode wird der Ablauf geplant?

4.

Soll detenninistisch oder stochastisch geplant werden?

5.

Wurde die Grob-Planung durch die Berücksichtigung der verfügbaren Personalkapazität verfeinert?

6.

Wurden dabei auch Begrenzungen der Ressourcen (Maschinen, Werkzeuge, Kapital berücksichtigt?

7.5.2 Verständnisfragen 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

Was versteht man bei einem Projektablaufunter einem Vorgang und einem Ereignis? Was ist eine Anordnungsbeziehung bei Arbeitspaketen und welche Anordnungsbeziehungen gibt es? Woraus besteht ein Netzplan? Was ist ein Vorgangs-Knoten-Netzwerk? Was ist ein Ereignis-Knoten-Netzwerk? Welche Termine und Zeitwerte werden bei der Terminplanung ermittelt? Was ist ein Kritischer Pfad? Erläutern Sie die Critical Path Method (CPM)! Erläutern Sie die Metra Potenzial Methode (MPM)! Erläutern Sie die PERT-Methode! Was ist ein Gantt-Diagramm? Was versteht man unter einem Kapazitätsgebirge?

7.5.3 Übungsaufgaben Aufgabe 7-1 Anordnungsbeziehungen Bei den folgenden 6 Vorgängen gibt es verschiedene Abhängigkeiten.

Vorgang C und E müssen seit 3 Tagen beendet sein, bevor B beginnen kann. Wenn B beginnt muss auch F beginnen. Erst wenn B endet, darf auch A enden. Während B läuft muss F oder A laufen. D darf erst beginnen, wenn nach Abschluss von A I Tag vergangen ist.

7.5 Repetitorium

183

Vorgang

Anordnungsbeziehung

A B C D E

F

Stellen Sie die Anordnungsbeziehungen zwischen den Vorgängen in der Tabelle dar. Aufgabe 7-2 Tenninplanung Ennitteln Sie für alle Vorgänge des folgenden Netzplans die frühesten und spätesten Anfangsund Endtermine sowie die jeweiligen Pufferzeiten.

Bild 7-22 Vorgangs-Knoten-Netz

Aufgabe 7-3 Erstellung einer Produktdokumentation Erstellen Sie aus der Vorgangsliste einen Netzplan und bestimmen Sie den kritischen Pfad. Vorgang

Vorgänger

opt. Dauer

real. Dauer

pess. Dauer

A

Literatur-Recherche

3

4

5

B

Internet-Recherche

3

5

7

C

Stoffsammlung

A,B

4

6

9

D

Quellengliederung

B

2

2

3

E

Thementabelle

C,D

3

4

6

Erw. wert

Std. abw.

7 Ablauf- und Terminplanung

184

Berechnen Sie für jeden Vorgang den Erwartungswert und die Standardabweichung der Vorgangsdauer Aufgabe 7-4 VKN erstellen Stellen Sie den Ablauf für die Erstellung der Produktdokumentation als Vorgangs-KnotenNetzwerk (VKN) dar. Aufgabe 7-5 Netzplan erstellen Erstellen Sie aus der Vorgangsliste einen Netzplan und bestimmen Sie den kritischen Pfad. Vorgang

Vorgänger

opt. Dauer

real. Dauer

pess. Dauer

A

12

15

19

B

26

30

37

C

A,B

16

20

26

D

A,B

4

5

7

E

A,B

21

25

30

F

C

20

25

32

G

C,D,E

17

20

26

H

C

8

10

13

I

E

11

15

20

Erw. wert

Std. abw.

Berechnen Sie für jeden Vorgang den Erwartungswert und die Standardabweichung der Vorgangsdauer. Nach Vorlage des Projektplans stellt der Auftraggeber die Forderung, den Fertigstellungstermin um 2 Wochen vorzuziehen. Gibt es eine sinnvolle Lösung? Aufgabe 7-6 EKN erstellen Stellen Sie den vorangehenden Ablauf als Ereignis-Knoten-Netzwerk (EKN) dar.

8 Risikomanagement

8.1 Projektrisiko " Der Honig ist nicht weit vom Stachel." (dt. Sprichwort)

8.1.1 Unsicherheiten in Projekten Das Gelingen eines Projekts setzt eine ganze Reihe positiv verlaufender Aktivitäten voraus. Kommt es bei einer dieser Aktivitäten zu Problemen, kann dies zu Verzögerungen, Qualitätseinbußen oder Mehrkosten führen. Jeder Erfolgsfaktor stellt daher zugleich einen Risikofaktor dar: Arbeiten können sich als schwieriger und langwieriger herausstellen, als ursprünglich gedacht, bestellte Teile können verspätet eintreffen, Lastenheft oder Pflichtenheft kann sich als fehlerhaft oder unvollständig heraus stellen, Arbeiten können im Plan vergessen worden sein, technische Konzepte können sich als Fehlschläge herausstellen, Projektbeteiligte können vorübergehend oder ganz ausfallen. Die Konsequenzen, die ein Risikofall in einem Projekt haben kann, sind vielfältig: überschrittene Termine, geplatzte Kostenbudgets oder nicht eingehaltene Produktqualität. Im schlimmsten Fall kann ein Risikofaktor ein Projekt auch vollständig zum Scheitern bringen. Schon diese kurze Skizzierung der Problematik macht klar, dass Risiken in einem Projekt nicht vollständig auszuschalten sind, und dass ein Ignorieren der Risiken in einer systematischen Projektplanung und -steuerung nicht akzeptabel ist. Die Handhabung von Risiken wird in vielen Projekten vernachlässigt. Dies liegt wohl weniger daran, dass die Bedeutung von Risiken unterschätzt wird, sondern eher an der Erkenntnis, dass es keine uneingeschränkte Sicherheit geben kann. Leider werden aus dieser Einsicht oft die falschen Schlussfolgerungen gezogen. Wenn Unsicherheit nicht vollständig beseitigt werden kann, neigen manche dazu, keinerlei Risiken einzugehen, was in letzter Konsequenz noch nicht einmal durch Nichtstun erreicht werden kann, während andere sich blindlings in jedes Risiko stürzen. Der angemessene Umgang mit unsicheren Situationen ist Risikomanagement. Projektmanagement plant, was passieren soll. Risikomanagement analysiert, was schief gehen kann, was getan werden kann, um dies zu verhindern, und was getan werden muss, wenn etwas schief gegangen ist. Die extreme Gegenposition zum Ignorieren der Risiken ist ein rein mathematisches Risikomanagement, bei dem alle Unsicherheiten auf Zahlen abgebildet und dann mit scheinbarer Präzision kalkuliert werden. Aber jede noch so ausgeklügelte mathematische Methode kann nur dann gute Ergebnisse liefern, wenn die Eingangsdaten etwas taugen. In der Praxis liegt die Wahrheit zwischen den beiden Extremen. Deshalb werden die Methoden in diesem Kapitel unterschieden zwischen qualitativen Methoden, die einen guten Überblick über das RisikoSzenario vermitteln und quantitativen Methoden, die versuchen, Risiken und Maßnahmen im Detail so weit wie möglich belegbar und nachvollziehbar zu handhaben.

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6_8, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

186

8 Risikomanagement

8.1.2 Der Risikobegriff Durch Aktivitäten werden im Projekt bestimmte gewollte und geplante Wirkungen erzielt. Jede Aktivität :führt das Projekt in einen neuen Zustand auf dem Weg vom Anfangs- in den ZielZustand. Durch viele nicht vorhersagbare Ereignisse wird der geplante Verlauf beeinflusst. Die Wirkungen können positiver Art - Chancen - oder negativer Art - Risiken - sein. Jedes Risiko entsteht aus dem Zusammenwirken eines potentiellen, negativen Ereignisses und dem Schaden, den es im Projekt verursacht. Jedes nicht vorhersagbare Ereignis kann eintreten, muss aber nicht. Es besitzt also eine Eintrittswahrscheinlichkeit zwischen 0 % (es tritt sicher nicht ein) und 100 % (es tritt sicher ein). Der Schaden, den ein negatives Ereignis im Projekt bewirkt, kann sehr unterschiedlicher Art sein; er beeinträchtigt immer das Erreichen von Projektzielen. Der Schaden kann sich in höherem Aufwand, verspätetem Projektabschluss, verschlechterter Produktqualität oder in einem Scheitern des Projekts äußern. Die DIN IEC 62198 definiert Projektrisiko als die Kombination aus der Eintrittswahrscheinlichkeit eines bestimmten Ereignisses und seinen Folgen für die Projektziele. Beispiel 8-1 Personalrisiko

Viele Projekte sind personalintensiv. Daher stellen die beteiligten Personen auch einen Risikofaktor dar. Ein möglicher Schadensfall wäre die Kündigung eines Mitarbeiters während des Projekts. Auf den ersten Blick ist natürlich nicht vorhersagbar, ob ein Mitarbeiter kündigen wird. Andererseits wäre es blauäugig, bei einem Projekt, das z. B. 1 Jahr läuft und im Durchschnitt 10 Mitarbeiter beschäftigt, davon auszugehen, dass keiner kündigen wird. Beträgt z. B. die mittlere Verweildauer der Mitarbeiter im Unternehmen bzw. in der Abteilung 5 Jahre, so liegt die Wahrscheinlichkeit dafür, dass ein Mitarbeiter während der Projektlaufzeit kündigt, bei 20 %. Bei 10 beteiligten Mitarbeitern liegt dann die Wahrscheinlichkeit, dass kein Mitarbeiter während der Projektlaufzeit kündigt bei nur 10 % (=0,8 10)! Der Schaden, den das Risikoereignis bewirkt, hängt vom Mitarbeiter und seiner Aufgabe im Projekt ab. Je höher die Qualifikation und je weniger Mitarbeiter vergleichbarer QualifIkation im Unternehmen zur Verfügung stehen, desto größer ist der Schaden. Alle Tätigkeiten, die im Umgang mit Risiken notwendig sind, werden zum Risikomanagement zusammengefasst. Hierzu zählen vor allem die Erkennung, die Bewertung und die Verringerung von Risiken. Risikomanagement findet heute in sehr vielen Bereichen statt: beim Umgang mit technischen Maschinen, mit Produkten oder mit gefährlichen Stoffen, bei unternehmerischen Entscheidungen, bei Finanzgeschäften und auch bei Projekten. Natürlich wird man bemüht sein, die Risiken in einem Projekt so weit wie möglich zu verringern. Eine vollständige Beseitigung aller Risiken ist in der Realität wohl nicht möglich. Es gibt sogar die Ansicht, dass ein Projekt ohne Risiko kein lohnendes Projekt ist, da es ohne Risiko auch keine Chance geben kann. Aus praktischer Sicht, können die Risiken eines Projekts also nicht vollständig beseitigt, sondern bestenfalls verringert werden. Aber auch dies gibt es nicht kostenlos: Risikoverringernde Maßnahmen werden immer Kosten verursachen, so dass Risikomanagement auf einen Vergleich der Kosten für die vorgesehenen Maßnahmen mit der dadurch bewirkten Risikoverringerung hinausläuft. Es ist daher nahe liegend, den mit einem Risiko verbundenen Schaden zu bestimmen und in Relation zu den Kosten zu setzen, die die risikoverringernden Maßnahmen verursachen. Sei

8.2 Der Risikomanagement-Prozess

187

nun M ein Maßnahmen-Szenario für eine bestimmte Risikokonstellation und es gebe N mögliche Ergebnisse, mit den Eintrittswahrscheinlichkeiten Pi und den Schadensausmaßen Si' Das Risiko R(M) für das Maßnahmen-Szenario M ergibt sich dann als Schadens-Erwartungswert. N

R(M)= E{S(M)} = LPi ,Si

(8.1)

i=l

In dieser Formulierung ist es am sinnvollsten, sich für das Maßnahmen-Szenario zu entscheiden, welches das Risiko minimiert. Jedes Szenario umfasst sowohl risikoverringernde als auch schadensbegrenzende Maßnahmen. Erstere werden vor Eintritt des Schadens ergriffen. Sie sind so ausgelegt, dass sie die Wahrscheinlichkeit Pi des Schadensereignisses verringern. Schadensbegrenzende Maßnahmen greifen nach dem Schadensfall. Sie haben zum Ziel, den entstehenden Schaden Si zu begrenzen, bzw. zu verringern. Zu den Maßnahmen-Szenarien zählt auch der Fall, dass keine besondere Maßnahme ergriffen wird. Dieser Fall bildet den Vergleichsmaßstab.

8.2 Der Risikomanagement-Prozess "Wer nicht wagt, der nicht gewinnt. " (dt. Sprichwort) Risikomanagement besteht aus 5 aufeinander folgenden Aktivitäten. Sie bilden den Risikomanagement-Prozess. Jeder Prozessschritt liefert Informationen, die im darauf folgenden Schritt genutzt werden.

Projektziele Auftrag

RisikoIdentifikation

Projektpläne

Risiko-Ereignisse Schadenswirkung Eintritts-Wahrsch.

Ressourcen

Schadensausmaß

Beteiligte Organisation

Risiko-mindernde Maßnahmen

Randbed.

EventualfallMaßnahmen Risikoüberwachung

Bild 8-1 Der Risikomanagement-Prozess

Risiko-Indikatoren

188

8 Risikomanagement

Das Gesamtergebnis ist eine Datenbank, die alle Informationen über Art und Ausmaß der Risiken sowie die Maßnahmen zur Risiko-Reduzierung enthält. Die einzelnen Schritte des Risikomanagement-Prozesses und die bei deren Durchläufen gewonnenen Informationen der Risiko-Datenbank werden nun im Einzelnen erläutert.

8.2.1 Risiko-Identifikation Der erste Schritt des Risikomanagements ist das Erkennen der Risikoquellen. Diese können offensichtlich sein: der Ausfall von Projektmitarbeitern, unterschätzte technische Probleme, unterschätzter Aufwand oder vergessene Anforderungen. Oft gibt es aber auch unerkannte oder unscheinbare Risikoquellen, deren Aufdeckung eine genauere Analyse erfordert. Jedes Projektrisiko steht in engem Zusammenhang mit den Projektzielen. Im Laufe eines Projekts ergeben sich sehr viele unvorhergesehene Ereignisse. Risikofaktoren sind nur diejenigen Ereignisse, die die Erreichung der Projektziele gefährden. Die Suche nach potentiellen Risikoquellen muss sich daher immer an den Projektzielen orientieren: Welche Ereignisse sind denkbar, die das Erreichen eines Projektziels verschlechtern oder gar verhindern? Eine Systematik, die die typischen Risikoquellen in Projekten erfasst, vermeidet das planlose Suchen nach Risiken in jedem Einzelfall. Sehr sinnvoll ist es, sich hier an die Defmition eines Projekts als System zu erinnern, das nach außen mit seiner Umgebung interagiert und im Inneren aus verschiedenen Komponenten besteht, die miteinander in Wechselwirkung stehen. Alle Komponenten des Systems "Projekt" sowie die Beziehung des Systems nach außen und in seinem Inneren stellen potentielle Risikofaktoren dar. Beginnen wir mit der äußeren Schnittstelle eines Projekts. Von seiner Umgebung, d. h. vom Auftraggeber erhält das Projektteam einen Auftrag, dessen wichtigster Bestandteil das Lastenheft ist. Es beschreibt die Anforderungen des Auftraggebers an die erwarteten Lieferungen und Leistungen. Hierzu gehören Zielkriterien und Randbedingungen. Es besteht die Gefahr, dass die Anforderungen im Lastenheft widersprüchlich oder gar nicht realisierbar sind. Außerdem kommt es immer wieder vor, dass der Auftraggeber Anforderungen vergessen oder als selbstverständlich voraus gesetzt und daher nicht erwähnt hat. Die aus dem Lastenheft resultierenden Auftragsrisiken müssen so weit wie möglich während der Aufgabenanalyse aufgedeckt und beseitigt werden. Das Pflichtenheft sollte daher nicht nur festlegen, wie die Anforderungen des Lastenhefts erfüllt werden, sondern es sollte die Anforderungslücken und Widersprüche des Lastenhefts beseitigen. Insbesondere sollte zur Vermeidung von Missverständnissen das Anforderungsprofil abgegrenzt werden. Hierzu ist es erforderlich, auch die Anforderungen ausdrücklich zu benennen, die im Projekt nicht erfüllt werden. Stimmt der Auftraggeber dem Pflichtenheft zu, ist an diesem Punkt Klarheit hergestellt und spätere Diskussionen werden vermieden. Natürlich bleiben selbst bei gründlicher Analyse auch im Pflichtenheft noch Risiken. Wenn ein Projekt Anforderungen enthält, bei denen es unsicher ist, ob sie technisch realisierbar sind oder bei denen unklar ist, wie viel Zeit die Realisierung in Anspruch nehmen wird, sollte dies auch benannt und bei der Auftragserteilung berücksichtigt werden. Entweder wird der Auftraggeber das Risiko akzeptieren und mittragen oder er wird die Anforderung abschwächen. Neben dem Auftrag als wichtigste Schnittstelle eines Projekts zu seiner Umgebung gibt es noch eine Vielzahl von Verbindungen, die stillschweigend oder unbewusst für den Projekterfolg vorausgesetzt werden. Man kann sie als passive Erfolgsfaktoren bezeichnen, die aber zu aktiven Misserfolgsfaktoren werden können.

8.2 Der Risikomanagement-Prozess TabeUe 8.1 Checkliste Projekt-Risikofaktoren

Auftrags-Risiken Sind die Anforderungen des Lastenhefts klar, vollständig und widerspruchsfrei? Können sich die ZielvorgabenIPrioritäten ändern? Ist der Projektplan kommuniziert und akzeptiert? Randbedingungs-Risiken Unternehmen Hat das Projekt im Unternehmen die notwendige Priorität? Sind im Unternehmen das benötigte Personal und die Ressourcen verfügbar? Auftraggeber Ist die Bonität des Auftraggebers sicher? Lieferanten Liefertreue: Kann der Lieferant wie zugesagt liefern? Termintreue: Werden Termine eingehalten? Qualitätstreue: Sind die Lieferungen von ausreichender Qualität? Recht & Gesetz Sind die rechtlichen Bedingungen bekannt? (Normen, Richtlinien, Genehmigungen etc.) Ist die Patentsituation geklärt? Personelle Risiken Projektmitarbeiter Verfügbarkeit während Bedarfszeit? Ausreichende Qualifikation? Gibt es soziale Spannungen? (Streitigkeiten, Egoismen etc.) Technische Risiken Eingesetzte RohstoffefTechnologien Sind die Technologien evtl. am Ende ihrer Lebensphase? Verfügbarkeit der Rohstoffe Eingesetzte Werkzeuge Verfügbarkeit der benötigten Werkzeuge Schnittstellenkompatibilität der Werkzeuge Organisatorische Risiken Planungsrisiken Wie gut/realistisch sind die Aufwands- und Terminschätzungen? Ist der Projektstrukturplan vollständig? Steuerungsrisiken Erfolgt eine Projektkontrolle? Gibt es eine Risikokontrolle?

189

190

8 Risikomanagement

Hierzu gehören die vielen externen Voraussetzungen und Bedingungen, die für die Durchführung eines Projektes notwendig sind. Zu diesen riskanten Randbedingungen zählt insbesondere die Situation des Unternehmens, in dem das Projekt durchgeführt wird. Ändern sich z. B. die im Projekt genutzte Unternehmens-Infrastruktur, die Projekt-Prioritäten oder die wirtschaftliche Situation des Unternehmens, kann sich dies massiv auf das Projekt auswirken. Das Gleiche kann bei entsprechenden Änderungen beim Auftraggeber passieren oder durch Änderungen der gesetzlichen Randbedingungen. Im Allgemeinen kann der potentielle Schaden durch Änderungen bei den externen Randbedingungen sehr groß sein. Sie sollten daher auf jeden Fall vor Projektbeginn kritisch geprüft werden. Allerdings ist die Palette der Maßnahmen, um gegen externe Änderungen vorzubeugen oder darauf zu reagieren, recht bescheiden. Diese Misere wird nur dadurch abgemildert, dass die Wahrscheinlichkeit für derartige Änderungen eher gering einzustufen ist. Wesentlich wahrscheinlicher, dafür aber mit mehr Handlungsoptionen versehen, sind die durch interne Projektfaktoren verursachten Risiken. Ein Projekt lebt davon, dass eine Vielzahl von Arbeiten von den Projektbeteiligten ausgeführt wird, die sich dazu verschiedener Ressourcen bedienen. Jeder Beteiligte, jede Arbeit und jede Ressource birgt Risiken für das Projekt. Eine große Gruppe von Risikofaktoren stellen die arbeitstechnischen Risiken dar. Jedes Arbeitspaket, das im Projekt ausgeführt werden muss, birgt mehr oder weniger große Risiken. Es liegt daher nahe, systematisch alle Arbeitspakete des Projektstrukturplans auf mögliche Risiken zu prüfen. Besonders vielfältig sind personelle Risiken. Die Suche nach potentiellen negativen Auswirkungen führt hier zu einer ganzen Reihe von Fragen: Stehen genügend Mitarbeiter für das Projekt zur Verfügung? Stehen Sie zur richtigen Zeit zur Verfügung? Haben die Mitarbeiter die richtige fachliche Qualifikation? Ist der Projektleiter für die Führung eines Teams geeignet? Gibt es soziale Spannungen innerhalb des Teams? Die personellen Risiken im Projekt können nicht pauschal behandelt werden. Jeder Projektbeteiligte ist ein Individuum und verursacht auch individuelle Risiken. Kennt ein Projektleiter seine Mitarbeiter schon länger, z. B. aus der Arbeit in der Linie oder aus vorangegangenen Projekten, fällt ihm eine Risikoabschätzung leichter. Ist dies nicht der Fall, sollten Informationen von Kollegen oder Vorgesetzten hinzu gezogen werden.

Beispiel 8-2 Risiken bei der Entwicklung einer Elektronikbaugruppe Die folgende Liste zeigt beispielhaft einige Risiken, die in einem Arbeitspaket zur Entwicklung einer Elektronikbaugruppe enthalten sein können: Sind alle Anforderungen an die Baugruppe bekannt? Sind die Schnittstellen (elektrisch, mechanisch) definiert? Lässt sich die Aufgabe mit den vorhandenen Kenntnissen lösen? Ist die Zeitschätzung zur Entwicklung der Baugruppe realistisch? Sind Bauelemente mit den geforderten Spezifikationen verfügbar? Können die Lieferanten die Lieferzeit einhalten? Sind alle Richtlinien beachtet? (EMV, schadstoffarme Bauteile, Sicherheit) Die Unterschiede zwischen individuellen Projekten sind natürlich sehr groß. Daher kann es auch keine Liste mit Risikofaktoren geben, die für alle Projekte gültig ist. Werden in einem Unternehmen immer wieder ähnliche Projekte durchgeführt, können aber die Erfahrungen zum

8.2 Der Risikomanagement-Prozess

191

Aufbau einer Liste mit Risikofaktoren genutzt werden. Diese Liste kann dann stetig fortgeführt und ergänzt werden. Dazu können die abgeschlossenen Projekte hinsichtlich aufgetretener Probleme ausgewertet werden: Der Schadensfall eines abgeschlossenen Projekts ist das Risiko des nächsten Projekts.

8.2.2 Risiko-Bewertung Risiko ist definiert als das Produkt der Eintrittswahrscheinlichkeit des Schadensereignisses und des Schadensausmaßes. Im Idealfall müsste die Risikobewertung daher aus einer Bestimmung aller Eintrittswahrscheinlichkeiten und aller Schadensausmaße für die möglichen Ergebnisse der Maßnahmenszenarien bestehen. Bei weitem nicht immer wird es gelingen, für alle diese Größen exakte numerische Werte zu bestimmen. Für eine qualitative Risikohandhabung genügt es, die Werte näherungsweise zu bestimmen. Ein graphisches Näherungsverfahren ist die Risk-Map: In einem Diagramm, in dem horizontal die Eintrittswahrscheinlichkeit und vertikal das Schadensausmaß eingetragen wird, kann jedes Risiko als Punkt dargestellt werden. Die Lage eines Punktes im Diagramm ermöglicht eine grundlegende Aussage über das damit verbundene Risiko. Je weiter ein Punkt nach rechts bzw. nach oben verschoben ist, desto größer ist das Risiko. Punkte gleichen Risikos bilden eine Hyperbel S Scheitern des Projekts erhebliche Mehrkosten

I I I -

-

-

-

-

-

_ _

__ I I I I I I

B

I I I I I I -

-

-

I

:_L.._-_-_-_-_-_....lf--_-_-_-_-_-_-_-_-'-j-_-_-_-_-_---'__

moderate Mehrkosten

geringe Mehrkosten

I

A ~ ______ '~ - -_-_-_-_-_-_-_-_....,J-_-_-_-_-_-_..:._

-

-

-

E pO

-

-

-1- -

I I I I I I

C

-

-

-

-

-

t- - - - - - - - - ---1 - -

I I

I I

I I I I I

I I I I I

p1

I I I I I I -

-

-

-

-

I

D p2

j

I I I

p3

p

pO: sehr unwahrscheinlich (z.B. < 0,1%) p1: unwahrscheinlich (z.B. 0,1% .. 1%) p2: wenig wahrscheinlich (z.B. 1% .. 10%) p3: ziemlich wahrscheinlich (z.B. > 10%)

Bild 8-2 Risk-Map: Eintrittswahrscheinlichkeit p, Schadensausmaß S

Fasst man nun noch bestimmte Werte zu Wertebereichen zusammen, entstehen Klassen vergleichbarer Risiken. Für eine grobe Betrachtung ist es irrelevant, ob sich die Risiken zweier Maßnahmen um 10 % unterscheiden, wenn die Ungenauigkeit zur Bestimmung der 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

192

8 Risikomanagement

die existierenden Risken in der Risk-Map ein, erhält man das so genannte Risiko-Portfolio des Projekts. Kann auch der ungefähre Wert eines Risikoparameters nicht angegeben werden, helfen Risikographen. 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 (FeWer-Möglichkeits- und Einfluss-Analyse). Bei diesem Verfahren wird jedes Arbeitspaket des Projektstrukturplans auf mögliche FeWerquellen untersucht. Danach wird versucht, den negativen Einfluss, den die Fehlerquelle auf die Arbeit haben könnte, zu analysieren. Tabelle 8.2 Bestimmung von Risikoklassen Schadensausmaß

Eintrittswahrscheinlichkeit

Risikoklasse

Scheitern des Projekts (Katastrophe: bis zu 100 % der Gesamtkosten) wenig oder ziemlich wahrscheinlich unwahrscheinlich

A B

C

sehr unwahrscheinlich Erhebliche Kosten (Notfall: z. B. 10 - 30 % der Gesamtkosten) Sonst sehr unwahrscheinlich

B

C

Moderate Mehrkosten (Störung z. B. 3 - 10 % der Gesamtkosten) sonst unwahrscheinlich

C D

sehr unwahrscheinlich

E

Geringe Mehrkosten (z. B. weniger als 3 % der Gesamtkosten) sonst unwahrscheinlich

D

E

Wie bei der Risk-Map und dem Risikographen wird die Auftretenswahrscheinlichkeit PA sowie 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. Alle 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 so genannten Risikoprioritätszahl RPZ zusammengefasst. Diese Zahl 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 Wert 10). Als unkritisch werden Risiken mit einem Wert unter 40 gesehen. Risiken mit Werten über

193

8.2 Der Risikomanagement-Prozess

100 sind dagegen kritisch und müssen durch geeignete vorbeugende Maßnahmen verringert werden. Beispiel 8-3 Projekt-FMEA für das Fallbeispiel Mascbinenterminal Um im Projekt "Mascbinenterminal" 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. Tabelle 8.3 Bestimmung der Risikoprioritätszahl Wahrschein1ichkeit

A

E

Budget- oder

B

Terminüberschreitung unwahrscheinlich

<0,1 %

1

10

<5%

1

sehr gering

< 1,0%

2,3

8,9

< 10%

2,3

gering

<10%

4,5

6, 7

<20%

4,5

mittel

<25%

6,7

4,5

<50%

6,7

hoch

>25%

8,9

2,3

>50%

8,9

sehr hoch

>50%

10

1

Scheitern des Projekts

10

A: Auftrittswahrscheinlicbkeit, E: EntdeckungswahrscheinJichkeit, B: Bedeutung

Basierend auf diesen Werten konnten dann die Risikofaktoren untersucht und bewertet werden. Einen Auszug zeigt die folgende Tabelle. Tabelle 8.4 Ergebnis der FMEA (Auszug)

Indikatoren und Bedeutung der Risikofaktoren Risikofaktor: Wichtiger Projektmitarbeiter kündigt ._._._._._._._._._._._._._._._._._._._._._._._._._._.-._._._._._._._._

.

A, E, B

RPZ

A=6

172

Indikator: Verändertes Verhalten E=7 ...............................................................................................................................................................................................1------------. Bedeutung: Terminüberschreitung um ca. 10 -15 %

B=4

A=3 24 Risikofaktor: CPU wird abgekündigt ...............................................................................................................................................................................................1-----------_. E=4 . .Indikator: . . . . . . . . . . . . .Rechtzeitige . . . . . . . . . . . . . . . . .Mitteilung . . . . . . . . . . . . . .des . . . . Herstellers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1------------_.

Bedeutung: Umsteigen aufErsatztyp, Mehrkosten ca. 10 % Risikofaktor: Benutzerschnittstelle wird nicht akzeptiert

._._._._._._._._._._._._._._._._._._._._._._._._._._.-._._._._._._._._

B=2

.

A=7

Indikator: Reklamationen bei Präsentation bzw. Probebetrieb

E=2

Bedeutung: Re-Design, Zeitverlust 10 %, Mehrkosten 10 %

B=5

70

...............................................................................................................................................................................................1-----------_. Aufgrund der Risikoprioritätszahl wird die Kündigung des Mitarbeiters als kritischer Faktor eingestuft, fiir den vorbeugende Maßnahmen notwendig sind. Die Abkündigung der CPU ist unkritisch, da von vomeherein ein Ersatztyp vorgesehen ist. Bei der BenutzerschnittsteIle wird das Risiko verringert, indem zu Projektbeginn ein Prototyp erstellt und dem Auftraggeber zur Begutachtung vorgestellt wird.

194

8 Risikomanagement

8.2.3 Risiko-Minderung 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 Risikomanagement-Prozesses 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 versuchen, die Eintrittswahrscheinlichkeit des schädigenden Ereignisses oder das Schadensausmaß zu verringern. Es ist wenig hilfreich, wenn man glaubt, jedes Schadensereignis mit Sicherheit 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". 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 Risken - 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 alarp-Strategie (as low as reasonably practicable): die Projekt-Risiko-Reduzierung 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. Tabelle 8.5 Risk reduction stair Klasse

Ziel

Bedeutung für das Risiko

A

Avoid

Risiko verhindern: Schaden oder Eintritt auf Null senken!

B

Mitigate

Risiko lindern: Wahrscheinlichkeit verringern, Schaden minimieren.

C

Limit

Risiko begrenzen: eine obere Grenze für den Schaden sicherstellen.

D

Transfer

Risiko übertragen: z. B. aus einem finanziellen einen zeitlichen Schaden machen.

E

Accept

Risiko akzeptieren ( ... and look on the bright side of life)

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

8.2 Der Risikomanagement-Prozess

195

Sicherheit erreicht. Allerdings muss das "Nachdenken" auch seinen schriftlichen Niederschlag fmden. 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. Die 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 zufrieden stellend 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 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 dies unbedingt der Fall wäre. 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, d. h. riskante 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!

196

8 Risikomanagem.ent Beispiel 8-4 Hardware-Entwicklungsprojekt Bei den Steinbachwerken sollte eine programmierbare Rechnerbaugruppe neu entwickelt werden. Bei einem solchen Vorhaben ist die Abkündigung von Bauteilen immer ein Risikofaktor. Das wichtigste Bauteil im vorliegenden Fall war der verwendete Mikroprozessor, da sein Wechsel sowohl bei der Hardware als auch bei der Software großen Aufwand nach sich zieht. Im vorliegenden Fall wurde geschätzt, dass die neu entwickelte Schaltung 5 Jahre lieferbar sein sollte. Geht man davon aus, dass ein Prozessor etwa 10 bis 20 Jahre lieferbar ist, war die Wahrscheinlichkeit einer Abkündigung während der Lieferzeit recht hoch. Sie wurde mit 25 % veranschlagt. Der Schaden, der in diesem Fall für eine Neu- oder Umentwicklung notwendig wäre, wurde auf 50 Tsd. € beziffert. Somit ergab sich ein Risiko in der Höhe von 12,5 Tsd. €. Zur Reduzierung des Risikos wurden mehrere Maßnahmen erwogen. Die Verwendung eines Prozessors, zu dem es einen kompatiblen Ersatztyp gab, änderte die Kündigungswahrscheinlichkeit zwar nicht, aber der Schaden war deutlich geringer. Allerdings hatte dieser Prozessor eine schlechtere Leistung, so dass mit 1,0 Tsd. € Mehrkosten gerechnet werden musste. Bei Verwendung eines Prozessors, der in großer Stückzahl hergestellt wurde, sank die Wahrscheinlichkeit der Abkündigung deutlich. Noch geringer wurde sie bei Einsatz eines Prozessors mit einem Zweitlieferanten (Second Source). Weitere Optionen waren Zusicherung einer Liefergarantie, die sich der Lieferant allerdings mit 5 Tsd. € honorieren ließ oder der Abschluss einer Versicherung, was eine Prämie von 6,5 Tsd. € kostete.

i

Ereignis IMaßnahme Kf!sd. €) IR [Tsd. €JJC [Tsd. €L R.. C [Tsd. €L Prozessorabkündigung 25%-1-50\ 12,5 0,0 12,5 25%1 2,0 1,0 3,0 I--_--t-='Pr~ozc=e~or mit komJlatiblem Ersatztyp Serien-Prozessor 10%L~0 5,0 1,gJ 6,0 IProzessor mit Second-Source --+---,5~'X4o _ 50 2,5 2,5 5,0 ~rgarantie des Herstellers 3% 50 1,5 5,0 6,5 25% 0 0,0 6,5 6,5 Versicherung abschließen

------er

BUd 8-3 Screenshot der Maßnabmenbewertung

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 lieferten eine Verbesserung gegenüber dem ursprünglichen Fall. Am besten schnitt der Prozessor ab, zu dem es einen kompatiblen Ersatztyp gab.

8.2.4 Eventualfallplanung 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 Vorsoge für den Fall treffen, dass während der Projektdurchfiihrung ein zielschädigendes Ereignis eintritt. Damit nicht erst in einer solchen angespannten Situation überlegt werden muss, was getan werden kann,

8.2 Der Risikomanagement-Prozess

197

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 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 Aus1astung 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 erlaubt 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 Projektdurchfiihrung ein frühzeitiges Erkennen und Eingreifen ermöglichen.

8.2.5 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 angenommen werden.

198

8 Risikomanagement

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 Dur, 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 eines Mitarbeiters erfahren und so manche drohenden persönlichen Probleme vermeiden oder sich frühzeitig aufkommende 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 S-S 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. RisikofaldOl' Beschreibung: Wirkung: Eintrillswahrsch. p Schadens ausmaß S

Hardware-Entv"ickler kündigt oder fallt aus. Anderer Entwickler muss die Aufgabe übernehmen; ca. 30%; ziemlich wahrscheinlich! 5 Wochen Verzug

Risikoreduzierende Ivlaßnahmen Beschreibung: Entwicklungsaufgabe auf2 Entwickler aufteilen. Wirkung: Fallt einer aus, entsteht kein Verzug. Mehraufwand Einarbeitung erforderlich. red. Eintrittswahrsch. p unuerändert ca. 30% red. Schadensausmaß S Kein Verzug, Mehraufwand ca. 4 Tsd. € Eventualfallplanung Eintrillsindikatoren: EuentualfallMaßnahmen: Verantwortlich für die Risikoüberachung:

'. · _.. ,. ... _...... - . : :0: · ... :,. ................ - ---,.---.---,.--- .. I

,

•

•

I

I

~

I

I

•

I

~

I

I

I

•

,

•

I

I

I

I

I

•

•

•

'

p

luSd '

I

I

I

· ... ,.. ··T·· .... ··T· · ···,.··· .. ··· .. ···T·

-

I

•

•

•

,

I

I

I

I

•

I

•

I I

• •

• •

• •

---~---:---:o-:· I

•

•

•

~

Veränderungen im Verhalten des Mitarbeiters: z.B. verschlossen, nachlässiger, Fehlzeiten. Persönliches Gespräch, bessere Bezahlung? Projektleiter

Bild 8~ Analyse des Personalrisikos in einem Entwiclclungsprojekt

8.2 Der Risikomanagement-Prozess

199

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. Das folgende Bild zeigt einen Ausschnitt aus dem Formular zur Analyse des Personalrisikos. 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. Daher werden aufwändige Verfahren nur selten eingesetzt. In den Projekten, in denen überhaupt ein nennenswertes Risikomanagement betrieben wird, sind Checklisten zur RisikoIdentifikation 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 durchgefiihrt 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 Rl), die Kompatibilität des Systems (R2) und der erforderliche Einarbeitungsaufwand (R3) erkannt. Schaden sehr hoch

' Y

R2: Kqmpatibilität : I I

---------,-I

I I I I I

hoch

---------,--

mittel

I I I I

I

-----r--------,-------I

I

I I

I I

R~: Einarbeitung

I

-----: - :

-----

0"

-----~-------I

I

,-------

0

R1: Auswahl

--------

I

gering

I I I I I

<3%

3 .. 10%

10 .. 30%

Bild 8-5 Risiko-Portfolio für das Fallbeispiel "CAD"

>30%

Wahrscheinlichkeit

200

8 Risikomanagement 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 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 System-Hersteller 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 diese 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.

8.3 Repetitorium

201

8.3 Repetitorium 8.3.1 Checklisten Tabelle 8.6 Checkliste Risikomanagement 1.

Wurde eine Liste mit möglichen Risikofaktoren erstellt?

2.

Wurde für jeden Risikofaktor die Eintrittswahrscheinlichkeit und das Schadensausmaß ermittelt ...

... ... 3.

durch eine (grobe) Klassifizierung? durch eine genaue Bewertung?

Wurden vorbeugende Maßnahmen zur Risikoverringerung ergriffen?

4.

Sind in der Planung PufferlRisikoprämien für die verbliebenen Risiken berücksichtigt?

5.

Wurden Maßnahmen für den Schadensfall festgelegt (Eventualfallplanung, Notfallplanung)?

6.

Wurden Indikatoren zur frühzeitigen Erkennung des Auftretens von Risikoereignissen defmiert?

7.

Ist die personelle Zuständigkeit für die regelmäßige Überwachung der Indikatoren geregelt?

8.3.2 Verständnisfragen 1. 2.

3. 4. 5. 6. 7. 8.

Was ist ein Projektrisiko? Was ist eine ,,risk-map"? Was ist eine Risikoklasse? Was ist ein Risiko-Portfolio? Geben Sie Schadens-Beispiele in einem Projekt aus Sicht des Auftraggebers, des Projektleiters und eines Projektmitarbeiters an. Aus welchen Aktivitäten besteht der Risikomanagement-Prozess? Was ist eine Eventualfallplanung? Was ist eine ,,risk reduction stair"?

8.3.3 Übungsaufgaben Aufgabe 8-1 Risiken beim Autokauf Sie möchten sich einen gebrauchten Wagen kaufen, der etwa 4 Jahre alt ist. Sie möchten das Auto etwa 6 Jahre fahren und in dieser Zeit für Anschaffung und Reparatur höchstens 8000 € ausgeben. Führen Sie eine Risikobetrachtung durch. Welches sind die 3 größten Risikofaktoren? Schätzen Sie deren Eintrittswahrscheinlichkeit und das mögliche Schadensausmaß.

202

8 Risikomanagement

Suchen Sie nun für jeden Risikofaktor mindestens eine vorbeugende und eine korrigierende Maßnahme. Aufgabe 8-2 Risiken in einem Studium

Formulieren Sie für ein Studium die 3 nach Ihrer Meinung wichtigsten Zielkriterien. Führen Sie die Zielkriterien zu einer Kostenfunktion zusammen, indem Sie für jedes Zielkriterium den möglichen Wertebereich festlegen und den Kriterienwerten Kosten zuordnen. Die Gesamtkostenfunktion ergibt sich dann als Summe der 3 Einzelkosten. Führen Sie nun eine Risikobetrachtung durch. Identifizieren Sie die 7 größten Risikofaktoren. Schätzen Sie deren Eintrittswahrscheinlichkeit und das mögliche Schadensausmaß. Legen Sie drei Risikoklassen fest und ordnen Sie die Risikofaktoren diesen Klassen zu. Suchen Sie nun vorbeugende und welche korrigierende Maßnahmen für die Risikofaktoren. Aufgabe 8-3 Risikoportfolio Fallbeispiel "DMS" Erstellen Sie ein Risiko-Portfolio für das Fallbeispiel "DMS". Legen Sie zunächst geeignete Werte(-bereiche) für die Eintrittswahrscheinlichkeit und das Schadensausmaß fest.

Bilden Sie dann Risikoklassen. Listen Sie nun mindestens 5 Risikofaktoren auf, bewerten Sie diese und tragen Sie diese in der folgenden Risk-Map ein. Schaden

I I I I

____ I

I I I I

L

J I I I I

I I I

I

I

I I I I

I I I ______ I

I I I L

I I I L

J

I I I I I

I I I I I

I I I I I

I I I I I

------I-----r----r----1

Wahrscheinlichkeit

Bild 8-6 Risiko-Portfolio

Durch welche Maßnahmen können Sie die Risiken verringern? Wie verändert sich dadurch die Lage der Risiken?

9 Projektsteuerung " Wer ruhig leben will, darf nicht alles sagen, was er weiß, und nicht alles glauben, was er hört. " (fernöstliche Weisheit) 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 darauf reagiert werden. Dies ist die Aufgabe der Projektsteuerung.

terminierter ~ ProjektAblaufplan steuerung

i--

~ steuemde Eingriffe

+-----1

Projektfortschritt

r-------

Projektdurchführung

I+--

--------

Projektergebnis

Bild 9-1 Arbeitsschritte der Projektplanung

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 steuernde Eingriffe im Ablauf zu korrigieren. Gelingt dies nicht, kann es auch notwendig sein, den ursprünglichen Plan zu revidieren, um ihn der Wirklichkeit anzupassen.

9.1 Projektkontrolle " Vertraue aufAllah. Aber binde dein Kamel an. " (aus Ägypten) 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?

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6_9, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

204

9 Projektsteuerung

9.1.1 Projektdatenerfassung Die naheliegendsten 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 zuflillig 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 sollten 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 Zustandangaben, 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. Der 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 und auch termingerecht abgegeben 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 Tendenz, sich nicht unnötig festzulegen und auch keine Fehler zu dokumentieren. Daher fallen Berichte oft etwas 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 wesentlich besser auf Zwischentöne achten und bei Unklarheiten nachfragen. Jeder Projektleiter sollte sich daher nicht nur auf formale Abläufe verlassen, sondern regelmäßig auch einzeln mit den Mitarbeitern reden. Beispiel 9-1 Projektstatusberichte

Das folgende Bild zeigt zum Stichtag 23.6. die Momentaufnahme eines Projekts, das am 10.6. begonnen wurde und am 3.7. abgeschlossen sein soll.

9.1 Projektkontrolle

205

Dem Projektleiter liegen folgende Rückmeldungen zu den Arbeitspaketen vor: API 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 der Mitarbeiter ist optimistisch, die geforderten Funktionen in der geplanten Zeit fertig zu stellen. Die Kosten für AP2 liegen im Rahmen des Budgets Vorgangsname

AP1 AP2

-

Dauer

29. Jun '09 08. Jun '09 115. Jun '09 122. Jun '09 I S MIDIMIDIFISIS MIDIMIDIFISISIMIDIMIDIFISIS MIDIMIDIFI

,

6 Tege 8 Tege

AP3

5 Tege

AP4

12 Tage l

AP5

5 Tage

,

Bild 9-2 Gantt-Diagramm eines Beispiel-Projekts

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 Vetzögerungen bei AP I erst am Montag, dem 22.6. begonnen, so dass der Mitarbeiter noch nichts Konkretes sagen kann. Auf die Nachfrage, ob er die in AP I verlorenen beiden Tage bis zum vorgesehen Abschlusstennin wett machen kann, möchte er sich erst dann äußern, wenn er die Arbeit von API 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. 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 Tennin ein Produkt vorgelegt wird, das alle im Lastenheft geforderten Funktionen erfüllt und der vorgegebene Kostenrabmen 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. Projekte sind in Teilprojekten und Projektphasen gegliedert. Jedes Teilprojekt liefert ein überpTÜtbares Ergebnis. Außerdem werden Beginn und Ende 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 kniffiigen technischen Problems im Kreise zu drehen,

206

9 Projektsteuerung

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 terminlieh 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 informellen 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 der Projektleitung. Zu Projektbeginn sollte deshalb erstens sicher gestellt 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. Hier kann man auf den terminierten Ablaufplan zurückgreifen. Er enthält alle auszuführenden Arbeiten sowie deren geplante Anfangsund 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

9.1 Projektkontrolle

207

werden, der für die Fortschrittserfassung pauschal durch einen Fortschrittswert von 50 % ausgedrückt wird. Die Rückmeldung begonnener und abgeschlossener Arbeitspakete ist ein einfacher Weg zur Bestimmung des aktuellen Status des Gesamtprojekts. 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 Hoffuung, 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 schon vorliegen, so 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: Wird 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 Fortschrittswerten 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.

208

9 Projektsteuerung

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 aufund 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 der neu geschätzte, voraussichtliche Restaufwand für ein Arbeitspaket gemeldet 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. Tabelle 9.1 Ermittlung des Fertigstellungsgrads (FGR, in 0 - 100 %) Methode

Merkmale

Schätzen FGR=x% Subjektiv, kaum überprütbar. Nur verwenden, wenn sonst nichts geht. Zeitproportionalität FGR = Istzeit/Planzeit Liegt oft daneben. Besser Restwertschätzung. Restwertschätzung FGR = (Planzeit-Restzeit)/Planzeit Aktualisierung in kurzen Abständen (z. B. I Woche) Statusschritte FGR = 0 % I 100 %; FGR = 0 % I 50 % I 100 % Anwenden auf Arbeitspaketebene. Leicht zu handhaben. Mengenproportionalität FGR = Istmenge/Planmenge Sehr gut, wenn geeignetes Mengenmaß verfügbar.

209

9.1 Projektkontrolle

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 Ablau:fplä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.

9.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 sie von niemandem ausgewertet und in entsprechende steuernde Eingriffe umgesetzt werden? Für ein Projekt gibt es eine Vielzahl von Anforderungen, die erfiillt und Randbedingungen, die eingehalten werden. 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. /~ F

Bild 9-3 Zieldreieck zur Messung des Projektfortschritts

210

9 Projektsteuerung

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. 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 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. In anderen Projekten könnten die Termine gehalten worden sein, aber zu Lasten erhöhter Kosten und verringerter Funktionalität. F

F /\ /

I

/

\

\ \

~ I

/

\

\

\

/

/

K

\

\

~T

Bild 9-4 Soll-Istwert-Abweichungen bei Projekten

Für jede Art der Planabweichung gibt es unterschiedliche Reaktionsmöglichkeiten. 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. Tabelle 9.2 Reaktionsmöglichkeiten aufPlanabweichungen

Funktions-

Realität ändern

Plan ändern

Kapazität erhöhen

Termine verschieben

Produktivität erhöhen

Funktionen vereinfachen

Priorität KostenPriorität Termin-

Termine verschieben Kapazität (Personaleinsatz) erhöhen

Funktionen vereinfachen

Priorität

Die folgende Liste enthält einige konkrete Vorschläge für verschiedene mögliche Maßnahmen. [Schelle 2007]

9.1 Projektkontrolle

211

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 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 entsprechender 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 Arbeit befindliche Arbeitspakete Schätzungen des Restaufwands erstellt. Darüber hinaus ist selbstverständlich eine Wachsamkeit für auftauchende Probleme auf informeller Ebene permanent notwendig.

9.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. Am Anfang gibt es eine ganze Reihe von Vorarbeiten und Einarbeitungen. Der Projektfortschritt ist daher nur gering oder manchmal gar nicht feststellbar. Nach Überwindung der anfänglichen Schwierigkeiten werden in den mittleren Projektphasen oft gute Fortschritte erzielt. Gegen Ende ver-

212

9 Projektsteuerung

langsamt sich der Fortschritt wieder, weil z. B. in den Tests immer wieder Fehler auftreten oder weil scheinbar nebensächliche Detailaufgaben überraschend viel Zeit kosten. P Pz P3

t

- - - - - - - - - - - - - - - - - - - - - - - - - - - ;;ro- /

------------------------~/

1

- - - - - /

-

-

-

-

-

-

-

-/71- -

-

-

-

/

1 1

/

Pz ------------------~

1 1

I I ,/./ 1 1/

/ (I ./ /

I I 1 1 1....

1/

/ /

/ /1 1 1

P1

/ //

-

-

-

-

-/7' /

/

,/ .-> / /

:-/:!..-/-':

/1/

/

~

I I I I I I I 1 1 1

PA .....""..y~:!:....!.--'-~I___'_--'-.!......!--'........"'---'---'-~Je.'_--'--'---'--'--'-~--'--'-!......!.__'_e""'__'-___., .. tA

Bild 9-5 Planung des Projektfortschritts

Obwohl der S-förrnige 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 Fortschritte :führt zu typischen Denkfehlern in den verschiedenen Projektphasen. In einer frühen Phase (Zeitpunkt tl) :führt die lineare Projektion des Fortschritts PI 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 10 zu optimistisch gesehen. Mit dem Abflachen der Kurve setzt dann die Ernüchterung ein und der Termin muss immer weiter 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 (im Bild PI, P2, P3 und pz) definiert werden. Nimmt man die Pakete als Fortschrittsniveaus an, können die zugehörigen Termine (im Bild: t\, t 2, 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.

9.1 Proj ektkontrolle

a

t1

P P z P 3 P

2

t2

213

t3

tz a: vermuteter linearer Verlauf b. tatsächlicher Verlauf

-

c: richtige gewählte Paketgrößen

c Bild 9-6 Richtige Dimensionierung der Leistungspaketgrößen

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 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 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 Fertigstellung "ewig" hinzieht. Die Tests werden dann oft 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.

214

9 Projektsteuerung Beispiel9-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. Vorgangsname

Dauer

EI SW.Projekt

P(Ii

5 Tage

0

10 Tage I

0

Erstellung Grobkonzepl

10 Tager-oj 25 Tage

EI Codierung

25 Tage

-

Programmierung Benutzerschnittstelle

25 Tage

12Tage~

Programmierung D81enbankanbindung

15Tagel

1900

Programmierung Datenverarbe~ung

20 Tage I

2300

Test COM·Schnittstelie Test Datenbankanbindung

--

Test

-

Datenverarbe~ung

._-----Systerrdest

EI Dokumentation

- r-

500

8 Tage

300 200

-

-

20 Tage

500

r------20 Ta~e 1_800 I 20 Tage

Benutzerhandbuch

15 Tage

0

Programmdokumemation

20 Tage

0

Übergabe, Schulung, Abnahme

5 Tage I

13. Q11, 2010 Aug Jul

I

I

~

4

4200

12 Tage 12 Tage

Jun

i ~ ~

~

28 Tage

Test Benutzerschnittstelle

I

.~

0

Programmierung COM·Schnittstelie

EI Komponententest

--

I

Erstellung Pflichlenhett Erstellung Feinkonzepl

-

12. Q11, 2010 Mai Apr

115 Tage

Analyse des Lastenhefts

---

LOC

0

;

~

--

'=:l

iii~

i;;;;;;;;;

il

Bild 9-7 Projeldplan SW-Projekt

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 Anfordenmgsanalyse: Vorliegen des Lastenhefts (nach 15 Tage) 2. Abschluss der Grobkonzepterstellung: Vorliegen eines Grobkonzepts (nach 25 Tagen) 3. Abschluss der Feinkonzepterstellung: Vorliegen eines Feinkonzepts (nach 50 Tagen) 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.

9.1 Proj ektkontrolle

215

Die im Laufe eines Projekts anfallenden Kosten haben ebenfalls einen nichtlinearen Verlauf. Allerdings gibt es am Projektanfang einen markanten Unterschied. Die Kosten werden durch verschiedene Faktoren verursacht, von denen oft die Personalkosten einen Großteil ausmachen aber auch die Kosten für Werkzeuge, Zu1ieferer, Materialien und Gebühren zu berücksichtigen sind. K

- - - - - - - - - - .--------Y

2

3

Bild 9-8 Planung der Kostenbudgets

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 Ana1yse- 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. 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[, K z, K 3, K z) zu definieren und diese mit Fortschreiten des Projekts in etwa gleich großen Zeitabständen frei zu geben.

Beispiel 9-3 Fallbeispiel "DMS": Planung der Kostenbudgets Das DMS-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 €/PT angesetzt. Neben den Personalkosten, die die Kapitalkosten für den Arbeitsplatz und dessen Ausstattung bereits beinhalten, müssen noch die Anschaffungskosten für die DMS-Software berücksichtigt werden.

216

9 Projektsteuerung Kosten€

Anteil

Kostenfaktor

5.000

100%

Direktes Entgelt (Bruttogehalt)

1.100

22%

Direkte Nebenkosten (z. B. Urlaub)

1.100

22%

Indirekte Nebenkosten (Arbeitgeberanteil zur Sozialversicherung)

1.000

20%

Nebenkosten für nicht produktive Arbeiten

800

16%

Zusatzkosten (Arbeitsplatz, Rechner: Miete, Abschreibung, Zinsen)

9.000

180%

Hier wird davon ausgegangen, dass 40.000 € für die Grund-Software anfallen und 10.000 € 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 1.000 € veranschlagt. Projektphase

Eigenes Personal

Zukauf

Fremdpersonal

Budget

PT

€

€

PT

€

€

Anforderungsspezifikation

60

27.000

27.000

Produktauswahl

40

18.000

18.000

Pilotbetrieb

80

36.000

40.000

20

20.000

96.000

Produkteinführung

120

54.000

10.000

10

10.000

74.000

Summe

300

135.000

50.000

30

30.000

215.000

Die dargestellten Kostenbudgets müssen zu Beginn der jeweiligen Projektphasen durch die Geschäftsleitung freigegeben werden.

9.1.4 Meilenstein-Trendanalyse Der Fortschritt in einern 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

217

9.1 Projektkontrolle

Meilenstein. Der Projektfortschritt wird dann durch die Zeitpunkte beschrieben, zu denen die Meilensteine erreicht werden. Beispiel 9-4 Meilenstein-Trendanalyse Das folgende Gantt-Diagramm zeigt ein kleines Projekt mit 4 Vorgängen Abis D.

.1\

5 Tage

B

10 Tage 1

C

12 Tage

D

15 Tage 2;3

-f--

-

Bild 9-9 Gantt-Diagramm eines kleinen Projekts

Als Meilensteine werden der Abschluss von Vorgang A (tl), der Beginn von D (t2) und der Zieltennin (tz) definiert. Zu Beginn wurde die Dauer der Vorgänge geschätzt. Daraus ergeben sich die dargestellten Plantermine für die Meilensteine. 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. Tabelle 9.3 Aktualisienmg der Meilensteine durch Restaufwands8chätzung t=

tz

h(B) h(C) tl tA

0 30 15 12 5 0

5 32 17 13

7

10 34 19 15 8

15 36 21 17

20 37 22 21

25 37 24 22

30 37

35 38

40 39

8/7

13/3

17/0

Ist-Aufwand I Geschätzter Restaufwand A

B

C D

015 0110 0/12 0/15

512 0/10 5/8 0/15

8/0 2/9 10/5 15/0

7/6 1512 15/0

12/2 20/1 15/0

14/0 21/0 3/12

Neben der ständigen Verschiebung der Meilensteine zeigt sich, dass auch der Ist-Aufwand (60 Tage) im Projekt den Plan-Aufwand (42 Tage) deutlich übersteigt. 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 Meilensteintennine über der Laufzeit des Projekts auf, erhält man einen Meilenstein-Trendverlauf.

9 Projektsteuerung

218

Planzeit

Projektzeit t

Bild 9-10 Meilenstein-Trendanalyse

Zu Beginn des Projekts werden die geplanten Meilensteintermine (im Bild t 1 bis t3) sowie der Anfangs- und 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.

Beispiel 9-5 Schulausbildung Das folgende Trenddiagramm zeigt den Verlauf einer Schul- und Hochschulausbildung. Die Meilensteine sind definiert als Einschulung, Mittlere Reife, Abitur, Bachelorabschluss und Masterabschluss. Man kann im Verlauf die Wirkung verschiedener Ereignisse erkennen. Zunächst verläuft bis zur Einschulung alles glatt. Während der Grundschulzeit tritt ein erstes Problem auf, so dass ein Schuljahr wiederholt werden muss. Gehen wir nicht näher darauf ein, sondern erklären es damit, dass der Schüler nicht mit der Grundschullehrerin klar gekommen ist. Natürlich verschieben sich dadurch auch alle anderen Termine, da die Dauer der Arbeitspakete bekannt ist (a). Da auch an einer anderen Schule und mit anderem Lehrpersonal immer noch Probleme auftreten (b), werden die Eltern schließlich von der Sorge geplagt, es könnten sich weitere Verschiebungen ergeben. Sie stellen daher ein späteres Studium ernsthaft in Frage. Dar-

9.1 Proj ektkontrolle

219

autbin verspricht der Schüler sich in der Oberstufe besonders anzustrengen und an eine Schule zu wechseln, in der ein verkürztes Abitur möglich ist. Dadurch können die Planungen wieder nach unten korrigiert werden (c). Planzeit

Master

24 J

Bachelor

22 J

Abi

19 J

a

b

c

d

e

Projektzeit t

mittlere Reife 16 J

Einschulung

6J

Geburt

0J

Bild 9-11 Meilenstein-Trendanalyse einer Schul- und Hochschulausbildung

Die Versprechungen des Schülers erweisen sich aber als haltlos, so dass der Plan eines Schulwechsels wieder verworfen wird. Angesichts weiter mäßiger Leistungen erhöhen anschließend alle Beteiligten den geschätzten Zeitbedarf für das Studium von 3 auf 4 Jahre. Aufgrund eines Auslands-Praktikums werden aus den 8 sogar 9 Semester (d). Zermürbt verweigern die Eltern schließlich die Finanzierung eines Master-Studiums: Der Sohn macht trotzdem weiter und finanziert das Master-Studium durch Jobs. Das kostet ihn zwar zusätzliche Zeit (e), aber es härtet ihn so weit ab, dass er schließlich doch das Ziel erreicht, wenn auch deutlich später, als die Eltern sich erhofft hatten. 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. 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.

220

9 Projektsteuerung

I

r--........-......,.

-I - -I - -II

I

I

Bild 9-12 Charakteristische Meilenstein-Trend-Muster

Einen interessanten Verlauf zeigt das rechte Trenddiagramm. 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 hereingeholt. 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.

Bild 9-13 Meilenstein-Trend-Muster bei zu optimistischer und zu vorsichtiger Schätzung

Steigen die Trendlinien gleichmäßig an, so deutet dies auf eine zu optimistische Schätzung zu Projektbeginn hin. 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. Sie sind ein Zeichen für zu vorsichtige Schätzungen zu Projektbeginn. Für das laufende Projekt muss dies nicht unbedingt korri-

9.1 Proj ektkontrolle

221

giert 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. 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.

Bild 9-14 Problematische Meilenstein-Trend-Muster (I)

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 Sprunge oder Knicke in den Trendlinien auf, nicht selten kurz vor dem Erreichen der IstZeitlinie, so muss dringend auf eine regelmäßig aktualisierte Schätzung hingewirkt werden.

Bild 9-15 Problematische Meilenstein-Trend-Muster (II)

222

9 Projektsteuerung

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. 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. 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 Dehnung der Termine.

9.2 Fortschrittssteuerung "Eine schmerzliche Wahrheit ist besser als eine Lüge. " (Thomas Mann) "Eine sanfte Lüge ist besser als die harte Wahrheit. " (aus Ägypten)

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 auch geringe Abweichungen verkraften. Außerdem sollten 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 sollten, 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 (Verlauf!) festgestellt. In diesem Fall muss die Frage gestellt werden, ob der Plan falsch ist oder die Realität. Wird zum Zeitpunkt 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 11) zu erkennen.

9.2 Fortschrittssteuerung

223

P 100%

Bild 9-16 Reaktion auf einen Rückstand im Projektfortschritt

Sind die Verspätungen dagegen auf EinzelefIekte und nicht auf systematische Planungsfehler zurück zu führen, muss aufjeden Fall versucht werden, ein weiteres Anwachsen des Planungsrückstands zu verhindern. Die Korrektur des Ablaufs führt zu einer Verschiebung der Plankurve (Verlauf 111). 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 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 gepufIert werden und sollten durch den PlanungspufIer aufIangbar sein. Es macht wenig Sinn kleine Abweichungen zu kommunizieren, da dies von anderen oft 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 SicherheitspufIer 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 Lieferterrnins, das

224

9 Projektsteuerung

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.

9.3 Projektabschluss "Injedem Ende liegt ein neuer Anfang." (Miguel de Unamuno y Yugo)

9.3.1 Maßnahmen zum 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. Aus formaler Sicht bildet der Projektabschluss das juristische 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. Im Abnahmebericht werden die durchgeführten, erfolgreichen Tests festgehalten, aber auch die Forderungen, Ziele oder Randbedingungen, die nicht erfüllt wurden. Entweder muss der Auftragnehmer an diesen Stellen nachbessern oder aber der Auftraggeber kann seine Zahlungen kürzen. Das Übergabeprotokoll listet alle Sachen und Dokumente auf, die der Auftraggeber erhalten hat und beschreibt die Modalitäten der Übergabe. 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, 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. 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? Wann und warum wurden Termine überschritten? Warum wurden Kostenbudgets nicht eingehalten? Auch die Erfahrungssicherung ist ein wichtiger Baustein eines ordentlichen 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

9.3 Projektabschluss

225

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. Den letzten Baustein zum Abschluss eines Projekts bildet die Projektauflösung: Die am Anfang gebildeten Gremien lösen sich im Rahmen einer abschließenden Sitzung auf, die Kostenstellen und das Projektbüro werden geschlossen und das Amt des Projektleiters endet. Durch die Auflösung des Projektteams wechseln die Mitarbeiter wieder in ihre ursprüngliche Aufgabe. Nicht immer gelingt dies reibungslos, so dass hier schon vor dem Projektende vorbereitende und beim Wechseln unterstützende Gespräche notwendig sind. Die für das Projekt reservierten Ressourcen, wie z. B. Räume, Rechner, Maschinen oder Werkzeuge werden zurück gegeben bzw. verkauft. Auch der soziale Aspekt der Projektarbeit kann mit einer Abschlussfeier der Beteiligten angemessen berücksichtigt werden.

9.3.2 Mögliche Probleme am Projektende 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. Die Varianten problematischer Verläufe in der Spätphase von Projekten sind vielfältig: Projekte können versickern, lautlos sterben, abgebrochen werden oder irgendwie kein Ende fmden. 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. 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. 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.

226

9 Projektsteuerung

9.4 Repetitorium 9.4.1 Checklisten Tabelle 9.4 Checkliste Projektsteuerung

1.

Woraus besteht der Projektfortschritt? Wie wird er gemessen? Wann wird er gemessen?

2.

Existiert ein ordentliches Berichtswesen? Wer kontrolliert die Berichte?

3.

Führt der Projektleiter regelmäßig informelle Abfragen durch?

4.

Werden Aufwände und Kosten systematisch erfasst?

5.

Erfolgt eine regelmäßige Restaufwandsschätzung laufender Arbeitspakete?

6.

Wie sieht die Planung der Kostenbudgets aus?

7.

Erfolgt eine Meilenstein-Trendanalyse?

Tabelle 9.5 Checkliste Projektabschluss

1.

Wie erfolgt die Abnahme des Projekts?

2.

Wie werden die gewonnenen Erfahrungen dokumentiert und ausgewertet?

3.

Wie erfolgt die Auflösung der Projektgremien, des Projektteams und der Ressourcen?

9.4.2 Verständnisfragen 1. 2. 3. 4. 5. 6. 7. 8.

Wie kann der Fortschritt in einem Projekt erfasst werden? Welche Angaben sollte ein Projekt-Statusbericht enthalten? Was ist eine Restaufwandsschätzung? Stellen Sie einen typischen Verlauf des Projektfortschritts über der Zeit dar! Was ist ein Meilenstein-Trend-Diagramm? Wie kann im Rahmen der Projektsteuerung aufPlanabweichungen reagiert werden? Welche Arbeiten sind zum korrekten Abschluss eines Projekts erforderlich? Welche Probleme können in der Spätphase eines Projekts auftreten?

9.4 Repetitorium

227

9.4.3 Übungsaufgaben Aufgabe 9-1 Das folgende Bild zeigt den Status eines Software-Projekts am Montag, dem 10.5.2010. Die Analyse- und Entwurfsarbeiten sind vollständig abgeschlossen. Derzeit laufen die Programmier- und Testarbeiten. Vorgangsname

EI Systemtest Systemtest Systemtest

EI Dokumentation Benutzerhandbuch

Blld 9-17 Status des Software-Projekts

In der Projektbesprechung, die alle 2 Wochen stattfindet, meldet Mitarbeiter C gute Fortschritte. Er ist mit der Programmierung der Benutzerschnittstelle eine Woche :früher als geplant fertig und kann bereits heute mit den Test beginnen. Allerdings möchte in der nächsten Woche 3 Tage Urlaub machen. um zu Hause die Küche zu renovieren. Mitarbeiter B liegt etwa 1 Woche hinter dem Zeitplan Er hat 80 % der benötigten Verarbeitungsfunktionen fertig. Er geht aber davon aus, dass er die restlichen Funktionen bis Donnerstag programmiert hat und dann mit den Tests beginnen kann. Den Mehraufwand bei der Programmierung begründet der Mitarbeiter mit vorgezogenen Testdurchläufen. Da diese gute Ergebnisse gezeigt haben. ist er sicher. dass er die vorgesehene Testdauer von 20 Tagen nicht vollständig benötigen wird und so die momentane Verspätung wieder aufholen kann. Mitarbeiter A liegt etwa 2 Wochen hinter dem Zeitplan. Die Programmierung der COMSchnittstelle ist nach seinen Aussagen trotz technischer Probleme zu 90 % fertig. Mit den Tests hat er noch nicht begonnen. Er begründet die Verzögerung damit, dass er vor der Programmierung noch Änderungen am Feinkonzept vorgenommen habe, um so Programmierarbeit einsparen zu können. Dies habe sich aber nicht veIWirklichen lassen. da auch Änderungen bei der Datenverarbeitung notwendig gewesen wären, zu denen Programmierer B aber nicht bereit war. Auf die Frage des Projektleiters, wie der Rückstand wieder aufgeholt werden kann, weicht A zunächst aus. Als der Projektleiter energischer nachfragt, schlägt A schließlich vor, dass er

228

9 Projektsteuerung

die Erstellung des Benutzerhandbuchs, die für die zweite Juni-Hälfte vorgesehen ist, an C abgibt und die gewonnene Zeit für die Fertigstellung seiner Programmteile und die Tests nutzt. Kann das Projekt noch termingerecht am 4.9.2010 abgeschlossen werden?

Was sollte der Projektleiter nach Ihrer Einschätzung tun? Welche Maßnahmen sind möglich? Welche realistisch? Welche Fehler wurden gemacht? Wie lassen sich diese in Zukunft vermeiden? Aufgabe 9-2 Meilenstein-Trenddiagramm analysieren Das dargestellte Meilenstein-Trenddiagramm zeigt einen kritischen Verlauf. Wie weit ist das Projekt fortgeschritten? Welche Fehler wurden bisher bei der Fortschrittsplanung gemacht? Was ist zu tun, um diese im weiteren Projektverlauf zu vermeiden?

Aufgabe 9-3 Meilenstein-Trenddiagramm zeichnen Die folgende Tabelle zeigt nach der Hälfte der geplanten Projektdauer (t=50) die Entwicklung der 4 Meilensteintermine. t=

0

10

20

30

40

50

tz

100

100

100

100

100

100

t3

75

75

75

78

83

85

t2

50

t1

25

tA

0

50 25

50 32

57 40

62 46

66 52

I I I I I

_:__:__:- ~ - J- ~ - ~ - ~ I

I

I

I

I

t

"I - 1 - T - T -

_1 _ _ 1_ _ 1_

-J _

-:- -:--: -j-+I

I

I

I

_1 __ 1__I_..J_ I I I -1- -1- - l -

I

I

I

-1- - l -

I

-1- -

I

I

Stellen Sie den Verlauf der Meilensteine als Trenddiagramm dar. Wie beurteilen Sie den Verlauf?

I

- 1- -1- -I -

I

_

I

I I

10 Der Mensclt im Projekt

10.1 Selbstmanagement " Manche Manager sind das Produkt starker Phantasie und schwacher Nerven. " (E. Ewel) 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 Routine-Aufgaben 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.

10.1.1 Methoden des effIZienten Arbeitens Bei der Planung eines Projekts werden alle Aufgaben so weit untergliedert, bis sie auf der Ebene der Arbeitspakete einzelnen Personen zugeordnet werden können. Aus dem Projektplan ergibt sich somit für jeden Beteiligten eine Liste auszuführender Arbeiten mit zugehörigen Start- und Zielterminen. Aus Projektsicht ist ein Arbeitspaket die kleinste zu planende und zu überwachende Einheit. Sie umfasst in der Regel Pakete mit einem Umfang von 1 bis 20 Tagen Arbeit. Aus Sicht eines Projekt-Mitarbeiters ist eine weitere Detaillierung der Arbeit nötig. Sie wird manchmal als Mikroplanung bezeichnet. Jeder Arbeitswoche und jeder Arbeitstag erfordert eine vorausschauende Planung, damit alle Anforderungen "unter einen Hut" gebracht werden. Die Arbeiten, die den Einzelnen 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. Als Voraussetzung für eine Planung müssen Ziele festgelegt werden. Für die Arbeitspakete des Projekts ergeben sich die funktionalen Ziele aus der Arbeitspaket-Beschreibung und die Terminziele aus dem Projektplan. Ist das Arbeitspaket umfangreicher, kann es sinnvoll sein, Teilziele zu bilden. Aber auch für die anderen Arbeiten müssen Ziele gebildet werden. 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."

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6_10, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

230

10 Der Mensch im Projekt

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 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 werden nicht eingehalten. 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, ungegliederter Form alle auszuführenden Aufgaben. Für jede Aufgabe sollte dann der Aufwand geschätzt und ein frühest möglicher und ein spätest mö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 ABCAnalyse 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 Eisenhower-Prinzip 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

10.1 Selbstmanagement

231

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 Uhr 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 Minuten 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Üfoarbeit 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. 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. Tabelle 10.1 Methodik: des effizienten Arbeitens

1. Ziele formulieren

I Sinn-Ebene, strategische Ebene, taktische Ebene; Motive, Werte, Wünsche.

2. Aktivitäten analysieren

I Analyse der Aktivitäten; in Listen sammeln (=> To-Do-Liste).

3. Aufwand schätzen

I Zeitbedarf und Kapitalbedarf schätzen; mit den verfügbaren Budgets vergleichen.

4. Entscheiden

I Was ist wichtig? Was ist dringlich? (=> ABC-Analyse)

5. Planen

I Reihenfolge der Arbeiten; feste Termine berücksichtigen; Pufferzeiten frei halten.

6. Ausführen

I Wo treten Abweichungen auf? Sind Planänderungen nötig?

7. Auswerten

I Was wurde erledigt? Was ist liegen geblieben? Was sind Ursachen für Abweichungen?

10 Der Mensch im Projekt

232

Es gibt eine ganze Reihe von Methoden, die diese Arbeitsschritte unter einem meistens gut klingenden und mehr oder weniger zutreffenden Namen zusammenfassen.

BeispiellO-l 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: Länge schätzen: Pufferzeiten schaffen: Entscheidung über Priorität: Nachkontrolle:

eine To-Do-Liste erstellen. den Aufwand für alle Aufgaben schätzen. nur einen Teil (z. B. 60 %) der Zeit verplanen. Wichtigkeit der Arbeiten bestimmen. 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.

BeispiellO-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 Minuten 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, z.B. [tiddlywiki.com], die die Umsetzung mit Hilfe eines Rechners ermöglichen. So wichtig für den einzelnen Autor auch die Vorteile der eigenen und die Nachteile der fremden Arbeitsmethoden sein mögen - zur Organisation der täglichen Arbeiten ist es 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

10.1 Selbstmanagement

233

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 auftreten. 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. Abfall 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 Ausmisten 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. Viele praktische Erfahrungen haben gezeigt, dass deshalb nur etwa 60 % der verfügbaren Zeit verplant werden sollten. Der verbleibende Puffer wird für unvorhergesehene Arbeiten und für die Aufarbeitung unterschätzter Arbeiten benötigt.

10.1.2 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ück greifen kann. Es gibt ein ganzes Spektrum an Stress auslösenden Faktoren. Im Allgemeinen werden vier Kategorien unterschieden: • • • •

Physische Stressoren, wie z. B. Lärm oder Hitze entstehen durch die Arbeitsbedingungen. 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) uns 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 entspre-

234

10 Der Mensch im Projekt

chende 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 Merkmale von Projekten und lassen sich daher 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 Arbeitsmethodiken 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 mildem. Kontraproduktiv sind so genannte eskapadische Strategien, wie z. B. übermäßiges Trinken, Einsatz von Medikamenten oder Drogen. Auch

10.2 Projektleiter

235

wenn sie vielleicht kurzfristig zu wirken scheinen, sind sie als Maßnahmen 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. Tabelle 10.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

10.2 Projektleiter " Den guten Steuermann erkennt man erst im Sturm. " (Seneca)

10.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 aber 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 Gesamt-Verantwortung für das Projekt gerecht zu werden. Als originäre, nicht delegierbaren Aufgaben eines Projektleiters sind folgende zu nennen:

236 • • • •

10 Der Mensch im Projekt

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 natürlich 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 gewünschten 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 am wenigsten vermisst werden. Oft muss ein Projektleiter in einer solchen Situation schon zum ersten Mal seine Durchsetzungsfähigkeit unter Beweis stellen. 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 auch 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 Aufgabe, 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 wenn nötig, 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

10.2 Projektleiter

237

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. 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 die Delegation 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 die Delegierung 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 Bedingungen zu vermeiden. Werden Aufgaben an die Projektmitarbeiter delegiert, müssen sie auch die entsprechenden Entscheidungsbefugnisse erhalten. Nur wenn die 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 Gesamt-Verantwortung beim Projektleiter liegt, kommt er nicht umhin, kleinere Entscheidungen den Mitarbeitern zu überlassen und nur deren Richtigkeit im abgelieferten Teil-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. Dieser wird in einem folgenden Kapitel behandelt. 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 KontrollAufgabe 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 Projekten ist ein Projektleiter auch

10 Der Mensch im Projekt

238

Controller; in großen Projekten sollte die Kontroll-Aufgabe durch einen eigenen ProjektController übernommen werden. Als letztes wichtiges Aufgabengebiet eines Projektleiters soll das "Feedback geben" genannt werden. Leider wird diese Aufgabe allzu oft vernacWä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. 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 gebrauchf') annehmen, sondern das Problem sollte aus Sicht des Projektleiters oder des Projektteams geschildert werden ("Wir haben jetzt zwei Wochen 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. Tabelle 10.3 Checkliste Kritikgespräch 1.

Gespräch gut vorbereiten und Zeit nehmen.

2.

Keine allgemeinen Vorwürfe machen ("Sie"), sondern konkrete Probleme ansprechen ("Wir").

3.

Lösungen gemeinsam suchen und als Ziele vereinbaren.

4.

Zum Abschluss positive Aspekte und gemeinsame Ziele betonen.

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.

10.2 Projektleiter

239

10.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. Natürlich ist den meisten Beteiligten bewusst, dass eine solche Aufzählung Idealforderungen formuliert, die nie alle und nie vollständig erfiillt sind. Leider führt eine endlose Aufzählung optimaler Fähigkeiten aber dazu, dass nicht ausreichend zwischen unbedingt notwendigen und optionalen 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 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. Proj ektleiter benötigen 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, Verantwortungsbewusstsein 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 zum Teil auch unlösbare Konflikte aushalten können. 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. Der 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 Kapitel 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.

10 Der Mensch im Projekt

240

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, dass der Projektleiter die Methoden in seiner täglichen Arbeit einsetzt und nutzt. Ihm kommt hier eine Vorbildfunktion zu. Nur wenn er sich selbst so verhält, wie er es von seinen Mitarbeitern erwartet, werden diese ihm folgen. Tabelle 10.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 Konfliktfiihigkeit (Konflikte ertragen und beseitigen können) Fachkompetenz (Umgang mit dem Fachgebiet) Fähigkeit zum vemetzten 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

10.2 Projektleiter

241

10.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 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 fiir 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 des Mitarbeiters fördert und diesen fiir 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]. 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.

10 Der Mensch im Projekt

242

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ühnmgskontrolle 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, kann die Projektleitung zusammenhängende Aufgaben "Delegieren" (Delegating). Die Projektleitung tritt bei diesem Reifegrad in den Hintergrund und überlässt dem Mitarbeiter den Freiraum für Entscheidungen und Aufgabenausfühnmg. Die Kontrolle erfolgt hier in größeren Zeitabständen und eher informell als formell. Tabelle 10.5 Situative Reifegrad-Theorie Reifegrad

Führungsstil

Beschreibung

1

Anweisen

Anweisungen geben, Ausführung eng kontrollieren

2

Argumentieren

Begründete Anweisungen, Ausführung in Abständen kontrollieren

3

Partizipieren

Beteiligung an Entscheidungen, Ergebnisse kontrollieren

4

Delegieren

Aufgabe übertragen, Entscheidungsfreiheit, informelle Kontrolle

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 sacWiche Hintergrund und die Dringlichkeit einer Entscheidung in die AuswaW mit einfließen. Den "richtige" 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.

10.3 Projektteams " Einer al/eine macht keinen Tanz. " (Sprichwort)

10.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-,,K.ultur". Diese Situation birgt Chancen und Risiken.

10.3 Projektteams

243

Die Zeit, die den Mitgliedern eines Projektteam 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 gefordert 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. 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 mittelbis 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 Kompetenzund 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 eige-

244

10 Der Mensch im Projekt

nen Ambitionen zurück zu stellen, alles fiir 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. Stattdessen 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 fiir 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 fiir 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 fiir die Galerie; wer genügend Luft hat, kann ja am Ende noch sprinten.

10.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 fiir die Personalauswahl. Der Projektstrukturplan, die darin aufgelisteten Arbeitspakete und die zu deren Bearbeitung erforderlichen Qualifikationen bilden daher die Basis fiir 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 fiir 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.

10.3 Projektteams

245

Vielmehr soll erkannt werden, welche Stärken und Schwächen jemand 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üof-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. Tabelle 10.6 Persönlichkeitseigenschaften Eigenschaft

Eigenschaftsspektrum

E

M

F

X

X

Interaktionsfonn

extrovertiert

introvertiert

X

emotionale Stabilität

stabil

labil

X

Offenheit

konservativ

offen

Wahrnehmung

intuitiv

sensitiv

X

X X

Entscheidungsfmdung

fühlend/emotional

denkend/rational

X

Entscheidungskonstanz

flexibel/percepteive

urteilend/judging

X

Verträglichkeit

egoistisch

altruistisch

X

Gewissenhaftigkeit

oberflächlich/effizient

gewissenhaft

X

E: als Eigenschaft im Persönlichkeitszirkel von Eysenck enhalten. M: Bestandteil des Typenindikators von Myers und Briggs. F: Einer der Faktoren des Fünf-Faktoren-Modells (Big Five).

Eine schon sehr früh erkannte und in vielen Modellen zu findende Eigenschaft ist die Interaktionsform. Sie beschreibt, in welchem Maße ein Mensch Anregungen aus seiner Umgebung aufnimmt und weitergibt. Extrovertierte Menschen agieren 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. In Stresssitua-

246

10 Der Mensch im Projekt

tionen 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 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 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. 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 Balm des Projekts zu halten und den Altruismus nur so weit zu fordern, wie er die Leistungsfähigkeit nicht beschränkt.

10.3 Projektteams

247

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 von Faulen, der noch nie ein Dummer war, zum Ausdruck.

10.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. Tabelle 10.7 Entwicklungsphasen von Arbeitsgruppen (nach Tuckman) Phase

Engl. Bez.

Charakteristische Merkmale

Orientierungsphase

Fonning

Unsicherheit, Kennenlemen, Formieren

Konfliktphase

Storming

Konflikte, Konkurrenzdenken, Machtproben

Nonnierungsphase

Nonning

Zusammenrücken, gemeinsame Ziele, Etablierung von Regeln

Leistungsphase

Performing

Kooperation, Offenheit, Verständnis,

Die Gruppenbildung beginnt mit einer Orientierungsphase. Die Mitglieder der Gruppe müssen sich zunächst kennen lernen. Jeder versucht, seine eigene Rolle in der Gruppe zu emden. Gleichzeitig werden die anderen hinsichtlich ihrer charakterlichen Eigenschaften 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 während der gesamten Zeit mitgeschleppt und sorgen immer wieder für Reibungsverluste. Nachdem einige "Ecken und Kanten" abgeschliffen und einige "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.

248

10 Der Mensch im Projekt

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 Konfliktund 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.

10.4 Repetitorium

249

10.4 Repetitorium 10.4.1 Checklisten Tabelle 10.8 Checkliste Arbeitsmethodik 1.

Welches sind meine Ziele für heute / für diese Woche?

2.

Welche Arbeiten möchte ich oder muss ich erledigen?

3.

Wie viel Aufwand erfordern sie?

4.

Welche Arbeiten sind am wichtigsten und am dringlichsten?

5.

Welche festen Termine habe ich und wie teile ich die verbleibende Zeit auf wichtige und dringliche Arbeiten auf?

6.

Welche gravierenden Änderungen ergeben sich während der Ausführung?

7.

Am Ende: Was wurde erledigt? Was wurde nicht erledigt? Warum?

10.4.2 Verständnisfragen 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

Aus welchen Schritten besteht eine effiziente Arbeitsmethodik im Rahmen des Selbstmanagements? Wozu braucht man eine persönliche To-Do-Liste? Was beschreibt die Eisenhower-Methode? Welche Kategorien von Stress-Ursachen und Stress-Wirkungen gibt es? Durch welche Maßnahmen kann Stress bewältigt werden? Welche Voraussetzungen und Kompetenzen werden von einem Projektleiter erwartet? Welches sind die wesentlichen Aufgaben eines Projektleiters? Nennen Sie wichtige Merkmale eines guten Kritikgesprächs! Nennen Sie einige wichtige Eigenschaften, die zur Beschreibung des Persönlichkeitsprofils von Menschen geeignet sind! Worin unterscheiden sich die verschiedenen Führungsstile? Welche 4 Phasen durchläuft der Reifegrad einer Führungsbeziehung? Welche 4 Entwicklungsphasen durchlaufen Arbeitsgruppen?

250

10 Der Mensch im Projekt

10.4.3 Aufgaben Aufgabe 10-1 Zeitbilanz Erstellen Sie eine Zeitbilanz für einen normalen Arbeitstag, indem Sie alle Tätigkeiten, die mehr als 5 Minuten in Anspruch nehmen, mit Uhrzeit und Dauer notieren. Für die Auswertung können Sie ähnliche Arbeiten, z. B. alle Telefonate, zusammenfassen. Ermitteln Sie, welcher Anteil der Zeit für geplante Arbeiten und welcher Anteil für Unvorhergesehenes verwendet wurden. Überlegen Sie, welche Arbeiten Zeitdiebe sind und wie Sie diese in Zukunft fernhalten können. Aufgabe 10-2 Zeitfresser/Zeitdiebe Überprüfen Sie, in welchem Maße die folgenden Aussagen auf Sie zutreffen: ,,Anrufe, E-Mails und Besucher sorgen immer wieder für Unterbrechungen meiner Arbeit." "Ich sitze zu oft und zu lange in Besprechungen mit fruchtlosen Diskussionen." "Es dauert oft ziemlich lange, bis ich bestimmte Informationen auf meinem Schreibtisch oder in meinem Rechner gefunden habe." ,,Die anspruchsvollen Aufgaben schiebe ich wie einen Berg vor mir her, weil ich mich ständig um lauter Kleinkram kümmern muss." " ,Nein' zu sagen fällt mir schwer, wenn jemand etwas von mir will." Was können Sie gegen die Zeitdiebe tun? Aufgabe 10-3 Stress-Tagebuch Legen Sie sich ein Stress-Tagebuch an, das Sie über einen Zeitraum von einigen Wochen führen. Notieren Sie die Art und den Zeitpunkt des Stressors. Beschreiben Sie die Art und die Stärke Ihrer Stress-Reaktion. Zur Auswertung des Stress-Tagebuchs überlegen Sie, welche Stress-Ursachen vermeidbar sind und wie Sie diese in Zukunft ausschalten oder wenigstens reduzieren können. Aufgabe 10-4 Formulierung von Kritik Überprüfen Sie, ob und gegebenenfalls warum die folgenden Aussagen die Regeln eines konstruktiven Kritikgesprächs verletzen: "Wegen Ihnen haben wir schon wieder 3 Wochen verloren." "Ich werde es nicht länger hinnehmen, dass Sie ständig vereinbarte Termine überziehen." ,,Der Statusbericht, den Sie mir vorige Woche geschickt haben, ist vollkommen oberflächlich. Was soll ich damit anfangen?" "Sie sind zu lasch gegen unsere Lieferanten. Wenn Sie denen nicht die Leine anziehen, tanzen die uns auf der Nase herum." "Wenn es in Ihrem Kopf so aussieht, wie auf Ihrem Schreibtisch, wundert es mich nicht, dass Sie ständig alles Mögliche vergessen." Wie würden Sie die angesprochenen Probleme als Projektleiter formulieren?

10.4 Repetitorium

251

Aufgabe 10-5 Persönlichkeitseigenschaften Versuchen Sie, sich selbstfür jede der folgenden Persönlichkeitseigenschaften zwischen den beiden Extremwerten einzuordnen. Eigenschaft

Extremwert

I

2

3

4

5

Extremwert

Interaktionsfonn

extrovertiert

introvertiert

emotionale Stabilität

stabil

labil

Offenheit

konservativ

offen

Wahrnehmung

intuitiv

sensitiv

Entscheidungsfindung

fühlend/emotional

denkend/rational

Entscheidungskonstanz

flexibellperceptive

urteilend/judging

Verträglichkeit

egoistisch

altruistisch

Gewissenhaftigkeit

oberflächlich/effizient

gewissenhaft

Bitten Sie nun jemanden aus Ihrem Familien-, Freundes- oder Kollegenkreis um eine Einschätzung Ihrer Eigenschaften. Wo gibt es zwischen den Einschätzungen Übereinstimmungen und wo gibt es größere Unterschiede? Aufgabe 10-6 Persönlichkeitseigenschaften Versuchen Sie, die Hauptperson Ihres Lieblings-Buchs oder -Films anband ihrer Persönlichkeitseigenschaften einzuordnen.

Versuchen Sie, in dem Buch oder Film Personen zu finden, bei denen jeweils eine Persönlichkeitseigenschaft besonders ausgeprägt ist. Aufgabe 10-7 Projektleiter-Anforderungskriterien Legen Siefür die Anforderungen an einen Projektleiter Gewichtungen fest, so dass die Gesamtgewichtung 100 % ergibt.

Wie könnte eine entsprechende Gewichtung der Anforderungskriterien :für ein Mitglied des Projektieams aussehen?

11 Software-Werkzeuge Jedes Werkzeug ist schlecht, wenn man nicht weiß, wozu es gut ist.

11.1 Software-Werkzeuge im Projektmanagement 11.1.1 Einordnung der PM-Software-Werkzeuge Die Tätigkeitsarten 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 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. ERP-SW PPS SCM CRM - - - - - -I BDE

IBüro-SW kleine Projekte

PM-SW

PM.SW: DMS

Büro-SW

Büro-SW

mittlere Projekte

große Projekte

Bild 11-1 Einordnung von Projektmanagement-Software-Werkzeugen

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: DokumentenManagement-System), die Lieferantenbeziehungen (SCM: Supply Chain Management) oder die Kundenbeziehungen (CRM: Customer Relationship Management) durchgängig rechnerge-

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6_11, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

11.1 Software-Werkzeuge im Projektmanagement

253

stützt gehandhabt werden können. In diesem Fall kann ein Projektmanagement-Werkzeug auch Bestandteil eines integrierten Unternehmens-Software-Systems sein. Derartige Systeme sind sowohl in der Anschaffung, als auch im Umgang aufwändig, so dass sie nur bei großen Projekten sinnvoll sind. 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 Dokumentenerstellung, Tabellenkalkulation, Kommunikation oder Präsentation gehandhabt werden. Bei einfachen, kleinen Projekten kann unter Umständen schon der Einsatz der Standard-BüroSoftware als Hilfsmittel fiir das Projektmanagement genügen, wenn z. B. mit Hilfe von Textverarbeitungsprograrnmen Berichte erstellt und mit einer Tabellenkalkulation Projektpläne erstellt und gepflegt werden [Schels 2005], [Kowalski 2007]. Weitere Gesichtpunkte 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 - weiter zu verwenden. Bei aller Wichtigkeit und Leistungsfahigkeit 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 ProjektmanagementWerkzeug kann ein fehlendes Projektmanagement ersetzen: Zuerst kommt die Methodik, dann das Werkzeug!

11.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 Verlaufe eines Projekts. Zum Projektende sind dann nur noch die Abschlussdokumente zu erstellen. Erledigt man die Standard-Aufgaben, wie sie bei jeder Bürotätigkeit anfallen mit BüroSoftware und die unternehmenstypischen Aufgaben mit ERP-Software, so bleibt ein Bündel von Funktionen, die fiir das Projektmanagement charakteristisch sind. Sie sollten durch spezielle PM-Software unterstützt werden. Ein Mindest-Funktionsvorrat fiir 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 Aus-

254

11 Software-Werkzeuge

gabe 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.

11.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. Der Markt für PM-Software ist regelrecht explodiert. So führt z. B. [pm-software.info] rund 200 Produkte in seiner Marktübersicht, von denen ca. 80 dem engeren Bereich der PMSoftware zugeordnet werden können. Das Spektrum der Lizenzkosten reicht von 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. 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 [GanntProject.biz], Open Workbench [openworkbanch.org], Open Proj [serena.com] und dot Project [dotproject.net]. 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-Source-Konzept 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.

11.2 Projektplanung und -steuerung mit Microsoft® Office Project

255

Mittlerweile gibt es einige Groupware-Systeme, die die besonderen Anforderungen der Gruppenarbeit in Projekten unterstützen. Als wichtige Beispiele sollen hier open-Xchange [openxchange.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.

11.2 Projektplanung und -steuerung mit Microsoft® Office Project1 Wie bei der Büro-Software stellt das PM-Tool MS-Project hinsichtlich Funktionalität und Bedienung einen Standard dar. Der Einsatz eines Werkzeugs im Projektmanagement wird daher nun am Beispiel von MS-Project eingehender beschrieben.

11.2.1 Die Struktur von MS-Project MS-Project ist ein Programm aus dem Office-Paket von Microsoft. Es unterstützt viele Aufgaben, die im Rahmen der Projektplanung und -steuerung ausgeführt werden. Aufgrund der Funktionsvielfalt ist die Benutzerschnittstelle recht umfangreich und daher nicht auf Anhieb zu überblicken. Dass es eine Vielzahl von Funktionen und Einstellwerten gibt, heißt das aber nicht, dass diese alle gleich oft benötigt werden. Viele Parameter können auf Standardwerte voreingestellt werden, die das Gros der Anwendungen abdecken. Ebenso wird eine ganze Reihe von Funktionen in normalen Projekten nur selten oder gar nicht benötigt. Aus diesem Grund werden hier nur die grundlegenden Funktionsmechanismen sowie die häufig benötigten Funktionen und Einstellungen von Project erläutert. Ein Projekt in MS-Project besteht aus vielen einzelnen Vorgängen, also Arbeitspaketen, die von Personen bearbeitet werden, die dabei Maschinen und Materialien in Anspruch nehmen und Kosten verursachen. Auch Meilensteine werden in Project als Vorgänge gehandhabt. Sie verursachen keine Arbeit und besitzen daher die Dauer O. Einzelne Vorgänge können zu Sammelvorgängen zusammengefasst werden. Dadurch lassen sich Projekte über beliebig viele Ebenen hierarchisch gliedern. Die Bearbeitung von Vorgängen im Rahmen eines Projekts erfolgt durch Menschen. Diese beanspruchen hierzu verschiedene Sachmittel, wie z. B. Maschinen, Rechner, Räume, Materialien und Geldmittel. In Project werden alle Sachmittel und die handelnden Personen als Ressourcen bezeichnet. Vorgänge und Ressourcen sind Datenstrukturen mit vielen Attributen. Man kann sie sich als zwei große Tabellen vorstellen: die Vorgangstabelle und die Ressourcentabelle. Jeder Vorgang bzw. jede Ressource entspricht einer Zeile, jedes Attribut einer Spalte. Zwischen den Attributen der Vorgänge und den Attributen der Ressourcen können Abhängigkeiten bestehen. Außerdem werden Ressourcen und Vorgänge einander zugeordnet, so dass auch zwischen den beiden Tabellen Abhängigkeiten entstehen.

1 Microsoft®

Office Project wird im Folgenden als MS-Project bezeichnet.

256

11 Softwarc-Wedczeugc

Die Aufgabe von Project ist es nun, die Eingabe aller benötigten Daten zu unterstützen, die bestehenden Abhängigkeiten zu iiberprdfen, die Bereclmungen durchzuführen und die Ergebnisse in der gewünschten Form. auszugehen und zu speichern. Ansichten Gantt

Netzplan RessOlJroe Vorgang

MS Projed

Kalender

t

t

Vorgänge

*.mpp

I

*.mpt

I

·.xIs

I

Ressourcen

LLrTI LLrTI BDd 11-2 Schnittstellen von MS-Project

Die Planung und Steuerung von Projekten ist ein umfangreicher Prozess, der aus zahlreichen, aufeinander aufbauenden Arbeitsschritten besteht. Aus ökonomischen Gründen sollte die Planung des Projekts vom Groben zum Feinen erfolgen: Zu Beginn der Planung sollten die wichtigen grundlegenden Festlegungen mit geringer Genauigkeit getroffen und im weiteren Fortgang, dann schrittweise verfeinert werden. Diese Vorgehensweise sollte sich auch im Umgang mit MS-Project widerspiegeln. Nach dem Start erscheint MS-Project mit einem neuen, leeren Projekt, das für die ersten Schritte verwendet werden kann. Die Standardansicht eines Projekts ist das Ba1kemdiagramm (Gantt) mit einem textlichen Tabellenbereich (links) und einem graphischen Balkenbereich (rechts). Die benötigten Funktionen werden entweder über das Menüsyst:em, über leans. über Shortcuts oder per kontextsensitivem Mausclick aufgerufen.

. .-.

~ MIcrosoft ProJect

:(ji!1

,,-oI:ei

:Q.l311i1

.~

myProjectl mpp ~~

jli ,?(". GJ~

o IV()f~SMlfle

eo"",

"'''

I Dtloer I

E&os

~

Arbel

;

.

~oje+1

"

~~

ZI/Sorrroemfbel

••-,

IVOf\l'lO;ler IRe"oc

-

=

"

,_. ,

1']LQ][i<]

•,

04. Jon 10 11.,,",,'10 18.Jon'1O 25.-""" hlDMDf S ShlOIolDf $ SMDhlDf S $"'D~

-

-

0 ~.

v

>

'"

BOd 11-3 MS-Project, Start: StandardanHicht eines neuen Projekts

;~

11.2 Projektplanung und -steuerung mit Microsoft® Office Project

257

Im. dargestellten Screenshot sind nur die wichtigsten Icons eingeblendet (von links): Tabelle 11.1 Wichtige lcons von MS-Project Funktionen

lcons

Dateibandhabung (Neu, Öffnen, Speichern, Drucken) Aktionen rückgängig machen bzw. wiederholen

wfJ·

Informationen zum Vorgang, Ressourcenzuordnung

-~

Ansicht vergrößern bzw. verkleinern, Hilfefunktion

+

Vorgang höher bzw. niedriger stufen (R.ecbtspfeil, Linkspfeil)

-.?

Teilvorgänge einblenden bzw. ausblenden (Plus. Minus)

-

.J

(@

=

Wichtige Einstellungen :für ein Projekt betreffen die Arbeitstage und -zeiten. Sie werden in Form eines Kalenders definiert. Der Projektkalender gilt:für das gesamte Projekt (Extras -> Optionen -> Kalender) während individuelle Einstellungen in den Ressourcenkalend.ern getätigt werden können. Nach dem Anlegen eines neuen Projekts sollten die wichtigsten Einstellungen vorgenommen werden. Sie stehen unter Projekt -> Proj ektinfo zur Verfügung. Sollen die Termine im Projekt von einem festen Starttermin aus in Vorwärtsrichtung berechnet werden, so wird diese ~ion ausgewählt (Berechnung vom: Projektanfangstermin) und der g~chte Anfangstermin festgelegt. Stattdessen ist auch eine Rüclewärtsberechnung vom Endtermin her möglich. Außerdem kann an dieser Stelle auch der g~chte Kalender gewählt werden.

11.2.2 Vorgangsplanung Die Projektplanung beginnt mit der Eingabe der Vorgänge. Zu jedem Vorgang gibt es eine Vielzahl von Attributen. Hierzu gehören z. B. ein Name, Anfangs- und Endtermin, Dauer, und Priorität. Die Attribute werden entweder direkt in der Tabelle oder in einem eigenen Formular eingegeben (Projekt -> Informationen zum vorgang). Alle Attribute können in der Tabelle als Spalten ein- bzw. ausgeblendet werden. Die Vorgänge eines Projekts sollten als Projektstrukturplan hierarchisch gegliedert werden. Dazu werden einzelne Vorgänge zu Sammelvorgängen zusammengefasst. Der Sammelvorgang wird vor den einzelnen Vorgängen eingefügt und höher gestuft. Auch Sammelvorgänge können weiter zusammengefasst werden, so dass sich eine beliebige hierarchische Struktur aufbauen lässt. Sie kann jederzeit durch Höher- oder Niedrigerstufen der Vorgänge verändert werden. Die verschiedenen Gliederungsebenen der hierarchischen Struktur können ein- oder ausgeblendet werden (Projekt -> Gliederung -> Einblenden -> Gliederungsebene), so dass das Projekt in unterschiedlich detaillierten Sichtweisen betrachten lässt. Als Nächstes werden Zeitaussagen benötigt. Zur deren Eingabe eignet sich ebenfalls die Vorgangstabelle im linken Teil des Fensters, während die Wirkung im Balkendiagramm auf der rechten Seite anschaulich nachvollziehbar ist.

258

11 Softwarc-Wedczeugc

Die Terminplanung ist ein zentraler Teil des Projektm 8D ogements. Sie kann grundsätzlich in Vorwärtsrichtung, d. h. vom. Projektanfang ausgehend, oder rückwärts vom Projektende her erfolgen. Zusätzlich können einzelne Vorgänge auf einen festen Termin gesetzt werden.

tm MIcrosoft ProJect ''''I "-",,ei lie",beii:en ~_9_~ liIiI @

,

~

myProject1 mpp

.,

!\nSiCOt

eo""

~rll>;le<1

. CH'

:::;:::

I~

Prc;e
1 T... ?

1 log? I

Best.,,,houf_

--. :::;:: --'--

,

!4

e

8 Bosisplanung

~ ,

tyojekt

"

"'''

o Ivorg.......,"""'"

E[tros

1 TO(l?

_f,«mttl.o;l

1 T... ?

Gmbkonz
1 T... ?

_ktontlly,e

1 T... ?

Aro;/etd «stolffi

1 T... ?

<"i -

....... ....

~""

• +

04.,,",,'10 $SIolDhlOf

Z\lSornrrJe<>Ybeii:

,

Eenstor

18.Jon10

11. Jon '10

r::J[gJ15<J

•,

, 25.Jon'10

S$MPMOf SShlDMDf SSMOMOf $

01.fob A S Iol D '"

v ~

-'

> <

>/

~.

BDd 11-4 MS-Project, Schritt 1: Eingabe von Vorgingcn

Bei der Vorwärtsplanung wird vom Projekt-Anfangstermin gerechnet. Der im Rahmen der Aufwandsschätzung bestimmte Zeitaufwand wird für jedes Arbeitspaket in der Spalte ,,Arbeit" eingegeben. Alternativ können auch die vorgesehenen Zeitdauem in der Spalte ,,Dauer" eingegeben werden. Diese Eingaben sind nur für die Arbeitspakete nötig, da bei Meilensteinen die Dauer und die Arbeit auf Null gesetzt und bei Sammelvorgiingen automatisch berechnet werden. tm MlCro
.l!:!i ,,-_

~.,l_I8Q

l!eilfb<>tffi

@

~I'QJ~

myProJoctl mpp

~

~Il!.

Vll>'p1

lf).(".

""rn.>;.

t..

'&tros

~~'io

,,~

,,~

,,~

,,~

~D)e+1

1:1S

_~f'<

~~

"" ""

Zl/S....-rJeIWteI:

~

'~~~

-.

< Borel:

_'I

~

tffiSt"

+ -

r

I<~

, K,

>~

BDd 11-5 MS-Project, Schritt 2: Eingabe der Zeiten

Die beiden nächsten Schritte setzen die Ablauf- und Terminplammg lUD. Zunächst werden die Anordnungsbeziehungen der Vorgänge festgelegt. Für jeden Vorgang kann es einen oder mehrere Vorgänger geben. Die BeschreHnmg der Beziehung erfolgt mit Hilfe der automatisch ver-

11.2 Projeklplanung und -steuerung mit Microsoft@ Office Project

259

gebenen, ganz links dargestellten Vorgangsnummem. Diese werden in der Spalte "Vorgänger" eingegeben. Mehrere Vorgänger können durch Semikola getrennt werden (Beispiel: 2; 5). Als Standard wird die Normalfolge (Hode-Anfang, HA) ohne gesooderte Kennzeichnung angenommen. Falls eine andere Folgeart verwendet werden soll, wird diese über ein Kürzel festgelegt: AA für die Anfangsfolge, EE für die Eodefolge und AE für die Sprungfolge (z. B. l3EE; 19AE, 25AA, 2EA). Auch zusätzliche Zcitbedingungen sind darstellbar. (Beispiel: 7EA+3T) Neben den schon kurz angesprochenen Informationen können Vorgänge noch eine Vielzahl weiterer Attribute besitzen.

Tabelle 11.2 Eine Auswahl wichtiger Vorgangs-Attribute Vorgangs-Attribute N, Fortlaufende Nummer Textliche Bezeichnung des Vorgangs

Name Arbeit

Der Arbeitsaufwand für den Vorgang

D...,

Die Dauer des Vorgangs

AIlfang

Oe< (geplante) Anfimgstemrin

Ende

Der (geplante) Endtennin

Priorität

Sie liegt zwischen 0 und 1000 und wird für den späteren Kapazititsausgleich benötigt

Bei der Eingabe der Vorgangsdauer werden aufgrund der Voreinstellungen automatisch Anfangs- und Endtermine berechnet Dies ist der erste Schritt der Tcrminplanung. Das genaue Terminieren der Vorgänge kann manuell oder automatisch passieren. (Extras -> Optionen -> Berechnen: Automatisch). Für das automatische Platzieren ist es wichtig. mit den gewünschten Einstellungen zu arbeiten:

Projekt -> Informationen zum Vorgang -> Spezial -> Vorgangsart. Iß M,cro.oft PrOject :~ "-"'''' ~D[511l1

~i>tde<1

~LQ]rgJ

myProjectl mpp ~

~~

@cfJlr!. ,?t"".

R:nrJOt

&

E1tr",

-tl:'~

ETojekt

G]S

Ber'>hl:

~~

Zll'~

~

"~

..

~

Eonstor

+ -

? ArioI

.S.FKll

v

,

<

BUd 11-6 MS-Project, Schritt 3: Ablaufplanung mit Hilfe der Anordmmgsbeziehungen

.=

'J

260

11 Software-Werkzeuge

Die Darstellung des Projektplans als Balkendiagramm kann auf vielfältige Weise an die verschiedenen Anforderungen angepasst werden (R.echts-Click im Balkendiagramm). Neben dem Aussehen der Balken und der Darstellung der Anordnungsbeziehungen kann die Beschriftung der Zeitachse oder das Layout des Diagrammblatts modifiziert werden. Nach der Ablaufplanung steht ein erster, grober Projektplan zur Verfügung. Dieser berücksichtigt noch keinen Ressourceneinsatz, gibt aber einen Überblick über die Reihenfolge der Arbeiten und liefert auch eine Aussage über mögliche Zieltermine. Unter Ansicht -> Netzplandiagramm kann der zugehörige Netzplan betrachtet werden. In ihm ist auch der kritische pfad gekennzeichnet Er kann auch im Balkendiagramm eingezeichnet werden: (Ansicht -> Weitere Ansichten -> Balkendiagramm: Einzelheiten -> Auswahl). te Microsoft Project :~ Q.atei

: IJ 6

~earbeiten

i/Jl

e. <

GJ[Q]LRJ

- myProJectl.mpp 6f"isicht

~nFjjgen

Lt:I 1\ ..,. l".

format

&J

W

E!tras

1~ gj ill

11

j,--,I~ :::

E.rojekt

:.'.. /

Beri~ht

q E<

@

I::... ,-,.

Z!!sammenarbeit

E.enster

~:.;." .. - '''bl,ode''

f--------H . -

r·,: '-. Frage ruer elligeben

I

,10

I"''''

~

.

-

7"

., ~,

--

F

K

U

". r5I X

{,

.

11

Bereit

,

1

Bild 11-7 MS-Project, Ansicht Netzplan

11.2.3 Ressourcenplanung Die Eingabe des Projektstrukturplans mit den einzelnen Vorgängen, deren Abhängigkeiten und den geschätzten Aufwänden bzw. Dauern fiibrt bereits zu einem ersten Tenninplan. Dieser ist aber nur vorläufig, da er den Ressourceneinsatz und mögliche Kollisionen noch nicht berücksichtigt. Zur Verfeinerung dieses Plans müssen im Projekt die Arbeiten zu Personen zugeordnet werden bzw. in Project die Vorgänge zu Ressourcen. Project unterstützt drei Ressourcenarten: Arbeit, Material und Kosten. Bei personalintensiven Projekten genügt es, zunächst nur die Ressourcenart ,,Arbeit" zu benutzen. Mit dieser wird im wesentlich der Personaleinsatz im Projekt geplant. Die Zuordnung der Ressourcen in MS-Project erfolgt am besten im Projektstrukturplan. Ist eine Ressource noch nicht definiert, kann dies, quasi nebenbei bei der Zuordnung erfolgen. Hierzu muss die entsprechende Option eingeschaltet sein (Optionen -> Allgemein > Neue Ressourcen und Vorgänge automatisch hinzufügen). Sinnvoller ist es aber, die Ressourcen explizit einzugeben. Dies erfolgt am übersichtlichsten in tabellarischer Form (Ansicht -> Ressource: Tabelle).

11.2 Projektplanung und -steuerung mit Microsoft® Office Project

I@ 6

261

Arial

~

Ressourcenname Art Materialbeschrittung Kürzel pete. Arben PE

Gruppe Max.Einh.

st.nd.rdsatz

Fälhg am

Basiskalender

100%

40,00 €JSld. Anteilig

standard

Paul

Arben

PA

100%

40,00 €JSld. Anteilig

standard

Mary

Arben

MA

100%

60,OOWd. Anteilig

standard

Bereit

Bild 11-8 MS-Project. Schritt 4: Eingabe der Ressourcen

Zunächst sollten die Projektbeteiligten mit Namen und Namens-Kürzel eingetragen werden. Weitere eventuell benötigte Daten sind Ressourcen-Art und Standard-Stundensatz. Steht eine Person nur teilweise im Projekt zur Verfügung, kann dies als max. Einheit in Form eines Prozentwerts ausgedrückt werden. TabeUe 11.3 Eine Auswahl wichtiger Ressourcen-Attribute Ressourcen-Attribute Ressourccnnam.e

Ausführliche Bezeichnung bzw. Name

Art

Ressourcenart: Arbeit, Material oder Kosten

Kürzel

K:ur.z:bezeichnung

max. Einheit

Prozentsatz, zu dem diese Ressource zur Verfügung steht

Stundensatz

Kosten einer Ressource pro Stunde

Nach der Definition der Ressourcen liegen in Project zwei Tabellen vor: die Vorgangstabelle und die Ressourcentabelle. Sie können nun verbunden werden. Dazu werden die Ressourcen den Vorgängen zugeordnet. Da jedes Arbeitspaket von einer Person erbracht werden soll, muss auch jeder Vorgang einer Ressource zugeordnet werden. Nach dieser Zuordnung gibt es zusätzliche Einschränkungen im Projektplan, da eine Ressource zu jedem Zeitpunkt nur zu ihrer max. Einheit (z. B. zu max. 100 %) berücksichtigt werden kann. Ist eine Ressource überlastet, so muss der Vorgang entweder einer anderen Ressource zugeordnet oder verschoben werden. Das Ergebnis der Ressourcenzuordnung ist ein Ablauf- und Terminplan, bei dem nicht nur alle Vorgänge einen Anfangs- und einen Endtermin haben, sondern auch der Einsatz der Ressourcen terminlich genau festliegt. Allerdings gibt es diese Genauigkeit nicht ohne erhöhten Aufwand.

262

11 Software-Werkzeuge

~ MIcrosoft ProJect myProjectl mpp

.

~LQ]~

,

.8

> <

•

F

K

Y

Ale~Of~

• '/_

-'

BOd 11-9 MS-Project, Schritt S: Zuordnung der Ressourcen

Bei den Ressourcen wird zwischen den Ressourcenart:en Arbeit, Material und Kosten unterschieden. Eine Azbeits-Ressource leistet die für einen Vorgang benötigte Arbeit A. Über den Stundenwert S (z. B. 8 Std. pro Tag) und die Einheit E (z. B. 100 %) können die Kosten und die Dauer D für den Vorgang bestimmt werden. Zwischen den Größen besteht folgender Zu-

sammenhang:

A=D·E·S

(11.1)

Für die Planung können immer nur drei dieser Größen fest vorgegeben werden. Die vierte Größe ergibt sich dann zwangsläufig.

Beilpielll-1 Zusammenhang zwischen Arbeit, Dauer und Einheit

Steht tür eine Arbeitsmenge von A. - 120 Personenstunden eine Person, die 6 Stunden pro Tag arbeitet, zu 100 % zur Verfügung, so ergibt sich eine Dauer vonD- 20 Tagen:

D=~= E·S

120Std. lOO%·6Std.rrag

20Toge

Um die gleiche Arbeitsmenge innerhalb von D = 8 Tagen fertig zu stellen, wird bei unverändertem Stundenwert S = 6 Std.lrag eine Einheit von E = 250 % benötigt:

E=~= D· S

120Std. 8 Tage· 6 Std.lrag

2,5=250%

Mathematisch kann man ein Projekt als ein Gleichungssystem. mit vielen untereinander verknüpften Variablen ansehen. Die Änderung einer Variablen kann Auswirkungen auf viele andere haben. Je nach Zielsetzung gibt es mehrere mögliche S1rategicn, um zu einer Lösung des Gleichungssystems, d. h. zu konkreten Werlen für die Variablen zu kommen. Will man z. B. einen vorgegebenen Zieltermin einhalten, ist es nötig, die Termine als feste Größen einzugeben und den Ressourceneinsatz variabel zu gestalten. Ist dagegen der Ressourceneinsatz fest, können sich die Termine verschieben. In der Praxis wird eine Mischung aus diesen Strategien sinnvoll sein, so dass die beteiligten Größen zum Teil als fest und zum Teil als variabel zu handhaben sind.

11.2 Projektplanung und -steuerung mit Microsoft® Office Project

263

MS-Project unterstützt diese Strategien durch verschiedene Berechnungsmodi. Im Modus "feste Einheit" ist der Arbeitseinsatz, d. h. die Zahl der verfügbaren Stunden pro Tag fest und die Dauer oder die Zahl der Arbeitstage variiert. Im Modus "feste Arbeit" variiert die Einheit oder die Dauer und bei "feste Dauer" können sich die Einheit oder die Arbeit verändern. Die folgende Tabelle zeigt die möglichen Vorgabe-Konstellationen und die daraus berechnete Größe. Tabelle 11.4 Berechnungsmodi

Vorgabe Arbeit A

A=D·E·S

Vorgabe Dauer D

Vorgabe Einheit E

feste Arbeit

=>D

=>E

=>D

feste Dauer

=>E

=>A

=>A

feste Einheit

=>D

=>A

=>D

Die Bedeutung der Berechnungsmodi ist nicht ganz trivial und gleichzeitig von zentraler Bedeutung für die Planung. Sie soll daher an einem Beispiel erläutert werden.

Beispiel1l-2 Ressourcenberechnung In einem Projekt gibt es 3 verschiedene Mitarbeiter Ca, b, c). Ihre Leistungseinheiten betragen 100 %, 50 % und 200 %. Im Modus "feste Einheit" gibt es für D = lOT die zugehörigen Arbeitswerte und für A = 10 T die zugehörigen Dauerwerte. Wird in diesem Modus der Wert der Einheit verdoppelt, sinkt die Dauer entsprechend um den Faktor 2. feste Einheit

feste Arbeit

(100 %, 50 %, 200 %)

A=lOT

E=E·2

D=lOT

A=lOT

E

D=lOT

a

D=5T

A=lOT

D=lOT

D=lOT

b

D=lOT

A=5T

D=20T

c

D=2,5T A=2OT

D=5T

feste Dauer D=lOT A=A·2

E

O=D·2

A=lOT

E=100% D=20T

A=lOT

A=20T

E=100%

D=20T

E=100% D=40T

A=20T

A=40T

E=100%

D=5T

E=100% D=lOT

A=5T

A=10T

E=100%

Im Modus "feste Arbeit" und "feste Dauer" führt die Verdopplung der Arbeit auch zur Verdopplung der Dauer und vice versa. Bei Vorgabe von D = lOT und A = lOT muss die Leistung bei 100 % liegen. a liegt also im Soll, während b seine Leistung verdoppeln und c seine Leistung halbieren muss. Für die Stundenzahl wurde immer S = 8 Std.lT angenommen.

11.2.4 Projektüberwachung Zu Beginn eines Projekts wird eine Planung erstellt. Diese wird sich im Laufe eines Projekts ändern. Die Gründe hierfür sind vielfältig und zum Teil nicht zu vermeiden. Um die Abweichungen vom Plan nachvollziehen zu können, ist es notwendig, den Plan während der Projektdurchführung zu aktualisieren. Um dabei nicht den Überblick zu verlieren und die Planänderungen auch später noch nachvollziehen zu können, lässt sich der ursprüngliche Plan als Basis-

264

11 Software-Werkzeuge

plan sichern (Extras -> Überwachung -> Basisplan speichern). Dadurch werden die momentanen Werte als Planwerte übernommen. Dabei wird keine eigene Datei erzeugt, sondern die Planwerte des Basisplans werden in zusätzlichen Feldern der Vorgangstabelle gesichert. Vorgangsname

Dauer

Arbe~

I Geplante

-----------'-----+---EI SW-Projekt

129 Tage

Analyse des Lastenhelts

-

6 Tage

Erst.:!~~gPffi~~~;:;~ft--rJ_~a~d Erstellung Grobkonzepl

I

12 Tage

- -"21 Tage

-----:E=-rst-Cellun9 FeinkonzePt

Dauer

---

Geplante Arbe~

2.008 Std. j 132 Tage

2.032 Std.

st~ ..s Tage

4?_~d.

48

64~~_Ta....:.ge-l-_80 Std·l

96 Std.

10 Tege

80' Std.1

168 Std-,-25Tage

200 Std.'

Abweichung Abweichung Dauer Arbe~

-3 Tage

I

-24 Std.

~g: _ _ 8 ~~: -2

T~ -16 Std.

2 Tage

16 Std.

=4 Tag~2 Std.

BUd 11-10 Vergleich von Plan- und Istwerten mit Hilfe eines Basisplans

Unter anderem werden die Werte für Anfang, Ende, Dauer und Arbeit jedes Vorgangs in die Felder geplanter Anfang, geplantes Ende, geplante Dauer und geplante Arbeit geschrieben. Während der Projektdurchführung können dann die Abweichungen zwischen den Plan- und Istwerten verfolgt werden (z. B. Abweichung Arbeit). Spätere Planversionen können als so genannte Zwischenpläne (Basisplan 1, 2, 3 usw.) aufgezeichnet werden.

11.2.5 PERT-Analyse Ein wirkungsvolles Hilfsmittel fiir den Umgang mit Schätzunsicherheit ist die Dreipunktschätzung im Rahmen der PERT-Analyse. Hier wird fiir jeden Vorgang nicht nur ein Schätzwert fiir Dauer bzw. Arbeit erstellt, sondern ein optimistischer, ein realistischer und ein pessimistischer Schätzwert. Aus diesen kann dann mit Hilfe der PERT-Analyse ein optimistischer, ein realistischer und ein pessimistischer Ablaufplan berechnet werden. In Project wird die PERT-Analyse aktiviert durch: Ansicht -> Symbolleiste -> PERT-Analyse. Dort stehen insgesamt 6 Funktionen zur Verfügung. Zunächst können in einer Tabelle die drei Schätzwerte fiir jeden Vorgang eingegeben werden. In der nachfolgenden Berechnung werden die drei Ablaufpläne bestimmt, die man getrennt betrachten kann. Außerdem wird aus den drei Werten ein Erwartungswert berechnet, der für die weitere Planung im Gantt-Diagramm verwendet wird. Beispiel11-3 Temperaturmessbox Am Beispiel der Temperaturmessbox soll eine PERT-Analyse erfolgen. Die bereits festgelegten Schätzwerte für die Dauer werden als realistische Werte übernommen. Dann werden fiir jeden Vorgang die pessimistische und die optimistische Dauer geschätzt. Hierbei kann es durchaus sein, dass zwei oder gar alle drei Werte identisch sind. Nach der Eingabe erfolgt die PERT-Berechnung. Sie liefert als neue Dauer für jeden Vorgang den wahrscheinlichsten Wert, der als gewichteter Mittelwert der drei Schätzwerte bestimmt wird. Die Gewichtungsfaktoren sind auf 1, 4, 1 voreingestellt, können aber durch den Benutzer geändert werden.

11.2 Projektplanung und -steuerung mit Microsoft® Office Project Vorgangsname

IEI Datenlogger I-

Dauer

Optimistische Dauer

265

Realistische Dauer

IPessimistische Dauer

22 Tage

15 Tage

20 Tage

Aufgabenanalyse

2,33 Tage

2 Tage

2 Tage

4 Tage

Gehäuse: Auswahl und Bes

8,17 Tage

5 Tage

B Tage

12 Tage

Entwurf Scha~plan

5,33 Tager

4 Tage

5 Tage

8 Tage

Programmierung

37 Tage

-

9,5 Tage

6 Tage

9 Tage

15 Tage

6,17 Tage

4 Tage

6 Tage

9 Tage

4,5 Tage

3 Tage

4 Tage

8 Tage

Systemlest Kl/V+SVV

3,33 Tage

2 Tage

3 Tagel

6 Tage

Montage+/nbetriebnahme

2,33 Tage

2 Tage

2 Tagel

4 Tage

Scha~ungsaufbau

Programmlest

Bild 11-11 PERT-Analyse für die Temperatunnessbox

Wegen der unsymmetrischen, nach rechts verschobenen Lage der Schätzwerte, liegt der Erwartungswert über dem realistischen (=wahrscheinlichsten) Wert.

11.2.6 Dateihandhabung Ein vollständiges konkretes Projekt wird in MS-Project als Projektdatei (*.mpp) abgelegt. Ir *.mpp MS Project II *.mpt I I Global.mpt I II *.xs

th

Konkrete Projekte

n

Projekttemplates für mehrere gleichartige Projekte

I

Einmalige globale Einstellungen für MS Project

th

Dateien zum Import bzw. Export

Bild 11-12 Dateien von MS-Project

Zu jedem Projekt gehört eine Vielzahl von Parametern. Deren Werte sind beim Start von MSProject auf sinnvolle Weise voreingestellt, so dass fiir einen ersten, einfachen Einstieg keine Einstellarbeiten nötig sind. Meistens werden aber in jedem Projekt einige spezifische Einstellungen benötigt. Diese werden beim Speichern des Projekts mit abgelegt, so dass sie erhalten bleiben. Sollen verschiedene Projekte mit gleichen Einstellungen erstellt werden, so kann ein Projekt-Template erstellt werden (Speichern unter -> Projektvorlage (* .mpt»). Diese Vorlage kann dann immer beim Anlegen eines neuen Projekts verwendet werden. Die allgemeinen VoreinsteIlungen von MS-Project werden in einer Vorlage mit dem festen Namen Global. mpt abgespeichert. Da einer Projektdatei im Wesentlichen zwei Tabellen zugrunde liegen, nämlich die Vorgangstabelle und die Ressourcentabelle, ist auch ein Export zu bzw. ein Import von MS-Excel unproblematisch. Der hnport von Daten, also z. B. von Vorgängen oder Ressourcen aus einer Excel-Datei, kann entweder zum Anlegen eines neuen Projekts oder zum Hinzufügen zu einem bestehenden Projekt genutzt werden. Der hnport (Datei -> Öffnen -> * .xla-Datei)

11 Software-Werkzeuge

266

wird von einem Import-Assistenten unterstützt. Jedem Feld der Excel-Tabelle muss ein Feld der Vorgänge oder der Ressourcen zugeordnet werden. Besonders einfach, aber nicht unbedingt notwendig ist dies, wenn beide den gleichen Namen besitzen. Alle Feldzuordnungen können als Importschema gespeichert werden, das bei späteren Importvorgängen nutzbar ist. Der Export (Datei -> Speichern unter -> *. xIs) ist noch unproblematischer. Die Feldnamen aus MS-Project können automatisch als Feldnamen der Excel-Tabelle übernommen werden.

11.3 Repetitorium 11.3.1 Checklisten Tabelle 11.5 Checkliste Anforderungen an PM-Tools

1.

Basisanforderungen des Einzelprojekt-Management Erstellung von Plänen für Projektstruktur, Ablauf und Tennine Personal- und Ressourcenverwaltung Definition von Kalendern Unterstützung des Kapazitätsausgleichs Kostenmanagement Auswertung und Dokumentation des Projektfortschritts unterschiedliche Darstellungsfonnen, der Tabellen, Listen und Pläne

2.

Weitergehende Anforderungen Unterstützung der Aufwandsschätzung Unterstützung der Risikoanalyse Wissens-, Konfigurations-, Qualitäts- oder Dokumentenmanagements

3.

Multiprojekt-Management bzw. Management von Projekt-Portfolios

4.

Kollaboratives Arbeiten

5.

Web-Interface

11.3.2 Verständnisfragen 2.

Mit welchen anderen Software-Systemen sollte eine PM-Software zusammenarbeiten? Was versteht man bei einer PM-Software unter einem Vorgang?

3. 4. 5.

Was ist bei einer PM-Software eine Ressource und welche Ressourcenarten gibt es? Was ist ein Sammelvorgang? Wie kann in einer PM-Software ein Meilenstein eingegeben werden?

6.

Was ist ein Netzplandiagramm?

1.

267

11.3 Repetitorium

11.3.3 Übungsaufgaben In den folgenden Übungsaufgaben soll :für das Fallbeispiel "CAD-Software" das Projekt geplant werden. Leiter des Projekts ist Herr Theisen. Am Projekt arbeiten Frau Hansen und die Herren Baumann, Wulffund Eiseie mit. Das Projekt besteht aus 4 Phasen: Vorauswahl, Präsentation, Probebetrieb und Einführung. Anfang und Ende dieser Phasen bilden die 5 Meilensteine. In der Vorauswahl sollen Systeme, die in Frage kommen, gesucht und bewertet werden. Dazu wird der Funktionskatalog festgelegt, eine Marktrecherche durchgeführt und ausgewertet. Als Ergebnis der Vorauswahl stehen die 2 oder 3 Systeme fest, die am besten geeignet sind. Die Hersteller der Systeme werden dann zu einer Präsentation eingeladen. Innerhalb einer Woche sollen die Systeme gemeinsam von allen Projektbeteiligten bewertet werden. Nach der Entscheidungfür ein System wird dieses auf einem Rechner installiert und darauf ein Probebetrieb durchgeführt. Anschließend wird das Systemfür alle Mitarbeiter eingeführt. Die folgende Tabelle fasst die wichtigsten Informationenfür das Projekt zusammen: Tabelle 11.6 Arbeiten des Fallbeispiels "CAD-Software" Arbeiten

Aufwand

Dauer

%

Mitarbeiter

25T

40%

Baumann

Projektbeginn

1

Marlctrecherche

2

Festlegung Funktionskatalog

4PT

Eiseie

3

Erstellung Marktübersicht

5PT

Baumann

Ende Vorauswahl 4

Präsentation

5T

Theisen, Hansen, Baumann, Eiseie

Entscheidung 5

Installation Testsystem

lOT

50%

Wulff

6

Durchführung Probebetrieb

20T

50%

Hansen

7

Auswertung Probebetrieb

3 PT

Hansen

5PT

Eiseie

Ende Probebetrieb 8

Schulung Mitarbeiter

9

Systemeinführung

25T

30%

Eiseie

Projektende

Aufgabe 11-1 Eingabe Projektstrukturplan Legen Sie in einem PM-Software-Werkzeug einen Projektstrukturplan an, der alle Arbeiten als Vorgänge enthält. Berücksichtigen Sie dabei, dass nicht jede Arbeit mit einem Arbeitspaket identisch sein muss. Teilen Sie deshalb die Präsentation auf 4 Arbeitspakete - einesfür jeden Beteiligten.

268

11 Software-Werkzeuge

Fassen Sie die Arbeiten, wie beschrieben, zu Projektphasen zusammen, indem Sie die Vorgänge zu Sammelvorgängen bündeln. Legen Sie die Meilensteine als Vorgänge mit der Dauer Null an.

Aufgabe 11-2 Eingabe von Anordnungsbeziehungen Legen Sie Anordnungsbeziehungen fest. Zunächst sollten die 4 Projektphasen als Sequenz festgelegt werden. Innerhalb jeder Projektphase werden dann die Beziehungen zwischen den Arbeitspaketen bestimmt. Die Marktrecherche und die Festlegung des Funktionskatalogs können parallel erfolgen. Die Erstellung der Marktübersicht folgt auf die beiden. Überlegen Sie (auch anband der personellen Zuordnung), welche Vorgänge parallel bzw. sequentiell erfolgen.

Aufgabe 11-3 Eingabe der Ressourcentabelle Legen Sie nun eine Ressourcentabelle an, in der alle Projektbeteiligten eingetragen werden. Berücksichtigen Sie dabei, dass Herr Wulff wegen seiner anderen Verpflichtungen grundsätzlich nur zu 50 % seiner Arbeitszeit zur Verfügung steht

Aufgabe 11-4 Eingabe von Aufwand und Dauer Aus der obigen Tabelle können Sie die Schätzwerte des Aufwands bzw. der Dauer für die verschiedenen Arbeiten entnehmen. Übertragen Sie diese in den Projektstrukturplan Dabei muss beachtet werden, dass an bestimmten Arbeiten nur teilweise gearbeitet werden kann. Hier müssen die entsprechenden Prozentwerte eingegeben werden. Nach diesen Eingaben liegt nun ein erster Entwurf des Projektplans vor. Wie groß ist der Gesamtaufwand? Welche Laufzeit hat das Projekt nach dieser Planung? Ist dieser Wert realistisch?

Aufgabe 11-5 Planverfeinerung Der Plan berücksichtigt noch keine Wartezeiten. So müssen z. B. nach der Vorauswahl die potenziellen Lieferanten zur Präsentation eingeladen werden. Sie werden sicherlich nicht sofort kommen können, so dass hier nach der Entscheidung eine Wartezeit nötig wird. Sie können diese entweder als eigenes Arbeitspaket einbauen oder in der Anordnungsbeziehung zwischen Vorauswahl-Phase und der Präsentations-Phase. Das Gleiche gilt für den Probebetrieb. Nach der Entscheidung für ein System muss eine Lieferzeit eingeplant werden. Bauen Sie auch diese in den Projektplan mit ein. Welche Laufzeit hat das Projekt nun? Ist die Vorgabe der Geschäftsleitung von 5 Monaten für die Projektdauer erreichbar? Was können Sie tun?

Anhang

Al Formulare Bei den hier vorgestellten Formularen liegt das Haupt-Augenmerk auf den anzugebenden Informationen, auf den entsprechenden Ausfüll-Hinweisen und auf dem beispielhaft gezeigten Prinzip eines vorgegebenen, einheitlichen und durchgängigen Aufbaus der Formulare. Es geht dagegen nicht um eine Festlegung der Formulargestaltung. Diese ist zum Teil Geschmackssache und zum Teil auch eine Frage der im Unternehmen existierenden Gestaltungsund Darstellungsrichtlinien zur Corporate ldentity. Aus diesem Grund sind die Formulare hier bewusst puristisch gestaltet, sowohl hinsichtlich der Verwendung graphischer Elemente als auch hinsichtlich der Textauszeicbnung.

AI.I Projekt-Dokument



IProjekt:

Proiektleiter:

Thema: Verfasser: VertelIer: Schlagworte: Gli ederungsrnerkmale:



I Prj.-Nr: I Datum:

I

Bild A-l Gemeinsame Vorlage für alle Projekt-Dokumente

Die Vorlage enthält die Informationen, die in jedem Projekt-Dokument enthalten sein sollen. Die Kopfzeile umfasst die Art des Dokuments (z. B. Besprechungsbericht, Personalliste, Meilensteintabelle) und das Firmenlogo. Darunter stehen die Angaben zum Projekt: Projektbezeichnung, Name des Projektleiters und die Projektidentifikation (Nummer, Kürzel oder ähnliches). Darauf folgen Angaben, die in jedem Dokument enthalten sein sollten (bzw. enthalten sein können). Hierzu gehören das Thema, Name des Verfassers, Datum der Erstellung hzw. Freigabe des Dokuments. Im Verteiler stehen die Namen aller Personen, die das Dokument

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

270

Anhang

erhalten sollen. Die Schlagworte und Gliederungsmerkmale dienen zur Einordnung und zum Wiederfinden des Dokuments in einer Dokumentenablage.

A1.2 ProjektdefmitioD

Projekt-Definition

I Projekt:

Projektleiter

Thema: Projektdefinition Verfasser: Verteiler: Schlagworte: Gliederungsmerkmale:



I Prj.-Nr.: I Datum:

Projektinhalt Ausgangssituation: Ziele: ProjektBeschreibung: Kritische Faktoren:

Budget: Projektbeteiligte Auftraggeber: Proj ektleiter: Projektteam: Bild A-2 Formular für eine Projektdefinition

Die Projektdeftnition fasst auf einer Seite die wichtigen Infonnationen zu einem Projekt zusammen. Sie beginnt mit der Beschreibung der Ausgangssituation. Dann werden die wichtigsten Ziele beschrieben, wobei zur Abgrenzung auch Nicht-Ziele ausdrücklich erwähnt werden können. Die Projektbeschreibung zählt die wichtigen Aufgaben auf, die im Projekt zu realisieren sind. Die für den Erfolg wichtigen Faktoren und die Risiken sollten ausdrücklich hervorgehoben werden. Alle Aufzählungen sollten stichpunkartig erfolgen und sich auf die (3 bis 7) wichtigsten Punkte beschränken. Als nächstes sollten die zeitlichen und fmanziellen Ressour-

271

Al Formulare

cenbeschränkungen in Fonn der Meilensteine und des Budgets spezifiziert sowie die Projektbeteiligten benannt werden. Eine Projektdefinition kann in leicht modifizierter Fonn auch als Projektantrag oder als Projektgenehmigung verwendet werden.

AI.3 Arbeitspaketbeschreibung Jedes Arbeitspaket muss in kurzer Form beschrieben werden. Die AP-Nummer und die Bezeichnung dienen zur eindeutigen Identifikation im Rahmen des Projekts. Jedes Paket muss einer verantwortlichen Person zugeordnet werden.

Arb eitspaketbeschrei bung

I Projekt:



I Prj.-Nr.

Pro jektleiter:

I Arbeitspaket:

I AP-Nr.:

AP -Verantwortlicher:

Auszuführende Arbeiten: Benötigte Vo raussetzungen: Angestrebte Ergebnisse:

Ablauf I Termine Früheste Termine Späteste Tennine Betroffene AP

Dauer: Anfang: Anfang: Vorgänger:

Ende: Ende: Nachfolger

BUd A·3 Vorlage für eine Arbeitspak:etbeschreibung

Danach werden die auszuführenden Arbeiten, die dazu benötigten Voraussetzungen und die angestrebten Ergebnisse beschrieben. Zur Einordnung des Pakets im Projekt dienen die Angaben zur geplanten Dauer und den Terminen sowie die Vorgänger- und NachfolgerArbeitspakete, zu denen Abhängigkeiten bestehen.

272

Anhang

A1.4 Besprechungsbericht Bei einem Besprechungsbericht werden zusätzlich zu den Standard-Infonnationen eines Projekt-Dokuments der Anlass der Besprechung als Thema, die Teilnehmer und der Tennin angegeben. Der Inhalt der Besprechung sollte in einzelne Besprechungspunkte gegliedert werden. Für jeden Besprechungspunkt wird festgelegt, ob es sich um einen Auftrag (A), einen Beschluss (B) oder eine Infonnation (I) handelt.



BeSI)rechungsbericht

I Projekt:

I Prj.-Nr:

Proiektleiter

Thema: Teilnehmer: Termin: I Ort: Verfasser: Verteiler Schlagworte: Gli ederungsmerkmale:

Nr. Inhalt

I Uhrzeit:

I Datum: I Datum:

AfBil

A: Auftrag. B: Beschluss, I: Information

Bild A-4 Vorlage für einenBesprechungsbericht

Bei einem Auftrag sollten zusätzlich eine verantwortliche Person und ein Erledigungstermin festgelegt werden. Die Aufuäge der Besprechungen müssen auf Erledigung kontrolliert werden. Damit nicht immer wieder die Berichte aller vorangegangenen Besprechungen durchgesehen werden müssen, ist es hilfreich, alle Aufuäge aus dem Besprechungsbericht in eine regelmäßig kontrollierte Ta-Da-Liste zu übertragen.

Al Fonnulare

273

Al.5 Statusbericht

Statusbericht



IProjekt:

I Prj.-Nr.:

Thema: Status: I Qualität: Termin:

I

Verfasser Verteiler: Schlagworte: Gliederungsmerkmale:

Kosten: Datum:

IErledigt. A,borite. IAuf.." ••••• P"bl.m. IM'gIi,h. Maß.u1,~" IG.pl••te A,b.it•• Bild A-5 Vorlage für einen Statusberiebt

Das Thema eines Statusberichts ist entweder der Berichtszeitraum bei periodisch zu erstellenden Berichten oder der Anlass für einen nichtperiodischen Bericht, also z. B. der Abschluss eines Arbeitspakets oder das Erreichen eines Meilensteins. In kurz gefasster Form sollte eine Aussage über den Status gemacht werden., getrennt für die drei Dimensionen des magischen Dreiecks. Hier kann entweder eine kurze, standardisierte textliche Statusaussage gemacht werden oder eine graphische Darstellung, z. B. in Fonn einer Ampel. Etwas ausführlicher sollte über die erledigten Arbeiten, d. h. die erreichten Ziele, über aufgetretene Probleme und mögliche Maßnahmen zu deren Lösung und über die als nächstes geplanten Arbeiten berichtet werden. Hier ist möglicherweise auch eine getrennte Betrachtung der drei Zieldimensionen Qualität, Termine und Kosten sinnvoll. Selbstverständlich kann ein Statusbericht noch weitere Gliederungspunlete enthalten. So werden z. B. im Statusbericht von [Hahn 2002] Kosten- und Terminaspekte ausführlich behandelt.

Anhang

274

A1.6 To-Do-Liste Eine To-Do-Liste enthält eine Sammlung von Arbeiten bzw. Aktivitäten unterhalb der Ebene der Arbeitspakete. Diese Aktivitäten sind also zu klein, um sie im Projektplan zu berücksichtigen, dürfen aber andererseits nicht vergessen werden. Deshalb werden sie in einer To-Do-Liste tabellarisch gesammelt. Die wichtigsten Angaben betreffen die beauftragte Person (Wer), die Art der zu erledigenden Aktivität (Was), den spätesten Zieltermin (Bis wann), den Arbeitsaufwand, den aktuellen Status (z. B. offen, in Arbeit, erledigt) und die Priorität (z. B. AIB/C). Darüber hinaus können weitere Infonnationen in der Tabelle aufgenommen werden, wie z. B. das Erfassungsdatum oder ein verbleibender Restaufwand bei laufenden Aktivitäten.

Ta-Do-Liste

I Projekt:

Projektleiter:

Thema: Verfasser: Verteiler: Schlagworte Gliederungsmerkmale: Wer

Was



I Prj.-Nr: I Datum:

Bis Wann

Aufwand

Status

Prio.

Bild A-6 Vorlage für eine To-Do-Liste

Statt einer einzigen To-Do-Liste ist es gerade bei größeren Projekten sinnvoll, z. B. für jeden Beteiligten oder für jedes Teilprojekt getrennte To-Do-Listen zu führen. Aufgrund des tabellarischen Aufbaus und der Notwendigkeit, die To-Do-Liste ständig zu pflegen, damit sie aktuell bleibt, ist es sinnvoll, die To-Do-Liste mit einem Programm zur Tabellenkalkulation zu führen und wenn möglich online zugänglich zu machen. Ein einfacher Mechanismus hierfür könnte die Ablage auf einem zentralen Rechnerlaufwerk sein, auf das die Projektbeteiligten Zugriff haben.

Al Formulare

275

AI.7 Risikoanalyse Für jeden Risikofaktor wird eine eigene Analyse angefertigt und mit Hilfe eines Formulars dokumentiert. Die Dokumentation umfasst eine Beschreibung des Risikofaktors, der risikoreduzierenden Maßnahmen und der Maßnahmen, die beim Eintritt des riskanten Ereignisses ergriffen werden. Nach Projektende wird jeder Risikofaktor ausgewertet, um Erfahrungen für kommende Projekte zu sichern. Die bildliche Darstellung von Eintrittswahrscheinlichkeit und Schadensausmaß vor und nach Ergreifen der risikoreduzierenden Maßnahmen erlaubt die Klassifikation des Risikofaktors auf einen Blick.



Risikaanalyse

I Projekt:

Projektleiter:

I_V_er_fa_s_s_er_:

I Prj-Nr. I_D_a_tu_m_:

_

Risikofaktor Beschreibung:

8

--- --- --- ----- - -- - -- ----- --- - -- ---

Wirkung: Eintrittswahrsch. p Schadens ausmaß S

--- --- --- ---

l±=-

U

Risikoredunerende Maßnahmen Besc hreibung: Wirkung: red. Eintrittswahrsch p red. Schadensausmaß S

Eventualfallplanung Eintrittsindikatoren: EventualfallMaßnahmen: Verantwortlich für die Risiko überwac hung:

Auswertung Schadensfall eingetreten? Schadenswirkung:

Bild A-7 Formular zur Analyse eines Risikofaktors

S

--- --- --- ----- - -- - -- ----- --- - -- ---

--- --- --- --~

p

276

Anhang

A2 Glossar Die ABC-Analyse dient dazu, die Wirkungsstärke der Einflussfaktoren auf eine bestimmte Größe zu klassifizieren. Ein Ablauf besteht aus mehreren aufeinander folgenden Arbeitsschritten. Ein Ablaufplan ist ein spezieller Netzplan, der den Ablauf eines Projekts als Netz von Vorgängen und Ereignissen beschreibt. Ein terminierter Ablaufplan ordnet die Ereignisse im Ablauf eines Projekts festen Terminen zu. Im Rahmen der Ablaufplanung wird die Reihenfolge der Arbeitspakete eines Projekts festgelegt. Mit der Abnahme bestätigt ein Auftragnehmer die vollständige Erbringung einer Lieferung oder Leistung, die in einem Auftrag definiert wurde. Diese Bestätigung sollte in schriftlicher Form als Abnahmeprotokoll dokumentiert werden. Ein Abschlussbericht fasst den Verlauf, die Ergebnisse und die gemachten Erfahrungen eines Projekts an dessen Ende zusammen. Das Änderungsmanagement besteht aus der Erfassung, Steuerung und Dokumentation notwendiger Änderungen in einem Prozess. In einem Angebot werden Kosten, Termine und Bedingungen der Lieferungen und Leistungen für einen Auftrag verbindlich oder unverbindlich (freibleibend) festgehalten. Eine Anordnungsbeziehung beschreibt die logische Abhängigkeit zwischen zwei Vorgängen. Man unterscheidet die Anfangsfolge (Anfang-Anfang), die Normalfolge (Ende-Anfang), die Sprungfolge (Anfang-Ende) und die Endefolge (Ende-Ende). Ein Arbeitspaket besteht aus Arbeiten, die funktionell und zeitlich sehr eng zusammengehören und von einer Person ausgeführt werden. Es stellt aus Sicht des Projektmanagements die kleinste betrachtete Aktivitätseinheit dar. Eine Argumentenbilanz ist eine Methode der Entscheidungsfmdung, bei der positive und negative Argumente für einen Sachverhalt einander gegenüber gestellt werden. Ein System aus einem Anfangs- in einen gewünschten Zielzustand zu bringen ist eine Aufgabe. Eine Aufgabe wird zu einem Problem, wenn der Weg vom Anfangs- zum Zielzustand durch ein Hindernis erschwert wird. Ein Auftrag stellt eine vertragliche Vereinbarung über eine zu erbringende Lieferung oder Leistung zwischen einem Auftraggeber und einem Auftragnehmer dar. Das Aufwands-Auftrags-Dilemma beschreibt den Zwiespalt, dass ohne Auftrag nur wenig Aufwand in eine Projektschätzung investiert werden kann, dass aber ohne genaue Schätzung eine Angebotsabgabe sehr fehlerbehaftet sein kann. Bei der Aufwandsschätzung wird der Aufwand für die Arbeitspakete geschätzt. Sie dient zur Ermittlung der voraussichtlichen Kosten und zur Planung des Zeitablaufs. Ein Balkendiagramm ist eine graphische Darstellung, bei der die Ausdehnung realer Objekte durch die Länge der Balken symbolisiert wird. Gantt-Diagramme sind Balkendiagramme zur Darstellung von Prozessen, bei denen die Dauer eines Vorgangs der Länge des zugehörigen Balkens entspricht.

Al Glossar

277

Ein Bericht ist ein Dokument, das anlässlich eines bestimmten Ereignisses verfasst wird, z. B. wegen einer Besprechung oder beim Erreichen eines Meilensteins. Ein Beziehungsdiagramm stellt die Wechselwirkungen, die zwischen den Größen eines Sachverhalts bestehen, als graphisches Netz dar. Bei der Bottom-Up-Vorgehensweise wird eine Aufgabe dadurch gelöst, dass man zunächst spezielle Teil-Lösungen schafft und diese schrittweise zur Gesamt-Lösung zusammensetzt. Beim Brainstorming werden in einer Gruppen-Sitzung möglichst viele Ideen zur Lösung eines Problems produziert. Jeder darf Ideen formulieren; sie dürfen von den anderen aufgegriffen, weiter entwickelt oder kombiniert, aber nicht bewertet oder kritisiert werden. Ein (Finanz-) Budget stellt eine bestimmte Menge einer zur Verfügung gestellten (fmanziellen) Ressource dar. Der zeitliche Verlauf der Inanspruchnahme wird als zeitabhängiger (Kosten-) Plan dargestellt. Die Delphi-Methode bezeichnet ein Verfahren zur Erstellung von Schätzwerten für einen Sachverhalt durch mehrere Experten in drei Schritten: zuerst verdeckt schätzen, dann Ergebnisse veröffentlichen und schließlich Schätzwert endgültig festlegen. Ein Dokument ist eine Informationseinheit, die mehrere Informationen zu einer physischen Einheit, z. B. in Papierform oder elektronischer Form zusammenfasst. Einsatzmittel (Ressourcen) sind Sachmittel (nach DIN69902 auch Personen), die zur Durchführung der Arbeitspakete eines Projekts benötigt werden. Ein Element ist ein nicht weiter zerlegbares Objekt. Ein Entscheidungsbaum gibt die Struktur eines aus mehreren, aufeinander aufbauenden Stufen bestehenden Entscheidungsprozesses wieder. Eine Entscheidungsmatrix ist Bestandteil einer Nutzwertanalyse, bei der die Kriterien und die Alternativen eine Matrix aufspannen, in der die jeweiligen Bewertungen eingetragen werden. Entwicklung ist ein Arbeitsprozess, bei dem vorhandene Kenntnisse genutzt werden, um ein neues Produkt zur Lösung eines Problems zu erstellen. Eine EventualfaUplanung beinhaltet Maßnahmen, die zu ergreifen sind, wenn ein Risikofall in einem Projekt eintritt. Die Fehlermöglichkeits- und -Einßussanalyse (FMEA) dient zur Risikoanalyse, indem mögliche Fehlerquellen aufgedeckt und deren Auswirkung untersucht werden. Ein Formular ist Muster, das den Aufbau und die Gestaltung eines Dokuments vorgibt. Eine Funktion ist eine erwünschte Reaktion eines technischen Systems auf eine äußere Anregung. Als Funktionalität bezeichnet man die Menge aller Funktionen eines Systems. Forschung ist ein Arbeitsprozess, bei dem auf wissenschaftlichem Weg, neue Erkenntnisse zur Lösung von Problemen gesucht werden. Gütekriterien sollen bei einer Problemlösung maximiert bzw. eingehalten werden. Sie legen die Qualität einer Lösung fest. Eine Groupware ist ein System rechnerbasierter Software-Werkzeuge für die Kommunikation, Kooperation und Koordination in der Gruppenarbeit. Eine IMV-Matrix stellt Interesse, Mitwirkung, und Verantwortlichkeit der Projektbeteiligten für die Arbeitspakete eines Projekts dar.

278

Anhang

Als Inkubation bezeichnet man eine Phase der Ideenfindung, in der unbewusst an einer Idee "gebrütet" wird. Die International Competence BaseIine (ICB) ist ein Standard der International Project Management Association (IPMA) und definiert 46 Kompetenzfelder des Projektmanagements. In Deutschland wird dieser Standard durch die Deutsche Gesellschaft für Projektmanagement (GPM) getragen. Ein weiterer, international weit verbreiteter Standard ist der Project Management Body of Knowledge (PMBOK) des amerikanischen Project Management Institute, der aus 42 Prozessen besteht. Die Kapazitätsplanung legt den zeitlichen Einsatz der Projektbeteiligten und der Ressourcen während der Projektlaufzeit fest. Das Kick-Off-Meeting ist die Auftaktveranstaltung zum Start eines Projekts. Kommunikation ist der Austausch von Informationen. Die Komplexität eines Sachverhalts entsteht durch die Vielfalt der Beziehungen, die zwischen seinen Bestandteilen existieren. Konstruktion ist ein Arbeitsprozess, bei dem aus verrugbaren Elementen ein neues Gebilde fiir eine bestimmte Aufgabe entworfen wird. Als Kritischer Pfad bezeichnet man die Vorgangssequenz, die die Durchlaufzeit eines Projekts bestimmt. Ein Lastenheft beschreibt aus Sicht des Auftraggebers die Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Projekts. Vor allem in der Baubranche wird es auch als Leistungsverzeichnis bezeichnet. Der Lenkungsausschuss (Steering Board) ist das oberste Entscheidungsgremium der Projektorganisation. Management ist die Planung und Steuerung von Prozessen. Anfangs und Endzeitpunkt einer Projektphase stellen Meilensteine dar. Die Meilenstein-Trendanalyse untersucht während der Durchfiihrung eines Projekts die Änderung der Plantermine fiir die Meilensteine und ermöglicht, drohende Terminprobleme im Projektverlauf zu erkennen. Die Mikroplanung dient dazu, den Ablauf der einzelnen Arbeiten die ein Arbeitspaket bilden, z. B. im Verlauf eines Tages zu planen. Ein Modul ist ein Objekt, das aus Elementen und anderen Modulen besteht. Die morphologische Methode dient zur systematischen Suche nach möglichen Lösungen fiir ein Problem. Die Merkmale des Problems bilden einen Lösungsraum, der im Allgemeinen als morphologischer Kasten, bzw. bei nur zwei Merkmalen als morphologische Matrix bezeichnet wird. Das Augenmerk des Multiprojekt-Managements liegt auf mehreren, parallel laufenden Projekten, die gemeinsames Personal beanspruchen bzw. gemeinsame Ressourcen nutzen. Es wird oft auch als Management von Projekt-Portfolios bezeichnet. Ein Netzplan ist die graphische Darstellung eines Netzes, das aus Knoten (z. B. Kreise, Rechtecke) besteht, die über Kanten (z. B. Linien, Pfeile) miteinander verbunden sind. Bei Vorgangs-Knoten-Netzplan (VKN) werden Vorgänge als Knoten und Ereignisse als Pfeile dargestellt. Bei Ereignis-Knoten-Netzplan (EKN) entsprechen die Knoten den Ereignissen und die Pfeile den Vorgängen.

Al Glossar

279

Als Netzplantechnik bezeichnet man die auf Netzplänen basierenden Methoden zur Planung eines Ablaufs. Eine Nullserie bezeichnet die ersten, unter den Bedingungen einer Serienproduktion hergestellten, noch nicht für den Kundeneinsatz bestimmten Aufbauten eines neuen Produkttyps. Die Nutzwertanalyse ist ein Verfahren zur Bewertung von Entscheidungsaltemativen mit Hilfe gewichteter Nutzenfunktionen für die Entscheidungskriterien. Das Pareto-Prinzip (oft auch 80/20-Regel) beschreibt einen Effekt, nach dem in einem Sachverhalt einige, wenige (z. B. 20 % von allen) Einflussgrößen die größte Wirkung (z. B. 80 %) erzielen, während die vielen anderen Größen nur eine geringe Wirkung besitzen. Das Pflichtenheft beschreibt aus Sicht des Auftragnehmers Art und Umfang der Lieferungen und Leistungen, zu denen er sich verpflichtet. Ein PhasenmodeU beschreibt den Ablauf eines Projekts als eine Abfolge zeitlich getrennter Abschnitte. Als Planen bezeichnet man die gedankliche Vorbereitung zukünftiger, zielgerichteter Aktivitäten. Der Produktstrukturplan (ProdSP) ist eine hierarchisch gegliederte Liste aller Teile eines Produkts. Ein Projekt ist ein zeitlich begrenztes Vorhaben, zur Schaffung eines neuartigen Produkts oder einer neuartigen Dienstleistung. Eine Projektablauforganisation ist eine Sammlung von Regeln, die den grundlegenden Ablauf eines Projekts festlegen. Eine Projektaufbauorganisation ist eine Sammlung von Regeln, die das Zusammenwirken der Projektbeteiligten, insbesondere die Befugnisse des Projektleiters, festlegen. Ein Projektauftrag umfasst das Lastenheft, das Pflichtenheft sowie die kaufmännischen Dokumente Anfrage, Angebot und Kaufvertrag. Projektbeteiligte (Stakeholder) sind alle Personen, die eine Rolle in einem Projekt ausüben, z. B. Auftraggeber, Projektleiter, Projektcontroller, Mitarbeiter im Projektteam, Zulieferer. In einem Projektbüro werden administrative und organisatorische Aufgaben des Projektmanagements zentral zusammengefasst. Es dient zur unmittelbaren Unterstützung der Projektleitung. Eine Projektdefinition fasst die wichtigsten Aspekte zum Inhalt und zur Durchführung eines Projekts in knapper, stichpunktartiger Form schriftlich zusammen. Das "magische" Projektdreieck symbolisiert die Ziele hinsichtlich Funktion (Qualität), Kosten und Terminen in einem Projekt. Projektierung ist ein Arbeitsprozess, bei dem die Lösung einer technischen Aufgabe durch Zusammenstellung verfügbarer Module erstellt wird. Ein Projektlebenszyklus ist ein vollständiger Durchlauf durch die Phasen Analyse, Entwurf, Realisierung und Validierung eines Projekts. Ein Projektleiter ist die verantwortliche Person zur Durchführung eines Projekts und zur Führung des Projektteams. Projektmanagement ist die Planung und Steuerung der problemlösenden Prozesse von Projekten, um diese termingerecht und aufwandsminimierend zum Ziel zu führen.

280

Anhang

Ein Projektmanagement-Handbuch beinhaltet allgemeingültige Regelungen fiir die Durchführung von Projekten in einem Unternehmen. Der Projektmanagement-Lebenszyklus beschreibt das organisatorische Zusammenwirken und den zeitlichen Ablauf aller Aktivitäten in einem Projekt als eine zusammenhängende Einheit. Projektorganisation ist die Schaffung von Regeln, durch die die Arbeit der Projektbeteiligten auf die Projektziele ausgerichtet wird. Eine Projektphase ist ein zeitlich abgegrenzter Teil eines Projekts. Sie kann ein oder mehrere Teilprojekte umfassen. Anfang und Ende einer Projektphase bilden Meilensteine. Projektplanung umfasst alle Arbeiten, die dazu dienen, den gewünschten Verlauf eines Projekts festzulegen. Gemäß DIN IEC 62198 definiert man Projektrisiko als die Kombination aus der Eintrittswahrscheinlichkeit eines bestimmten Ereignisses und seinen Folgen fiir die Projektziele. Projektsteuerung umfasst alle Maßnahmen, um alle Vorgänge im Projekt auf dem geplanten Verlauf zu halten. Der Projektstrukturplan (ProjSP) fasst alle in einem Projekt notwendigen Arbeiten in einer hierarchisch gegliederten Liste zusammen. Eine Projektstudie (Machbarkeitsstudie, Feasibility Study) dient bei riskanten Projekten dazu, vorab die Realisierbarkeit zu überprüfen, sowie den Aufwand und den Zeitbedarf abzuschätzen. Ein Projektteam besteht aus mehreren Personen, die die Aufgaben in einem Projekt bearbeiten und dabei vom Projektleiter geführt werden. Ein Prototyp ist ein Produktaufbau, der noch nicht unter den Bedingungen der Serienproduktion erfolgt. Prototyping ist die Erstellung eines Prototyps. Beim Rapid Prototyping wird dies bewusst mit möglichst wenig Aufwand betrieben, um frühzeitig bestimmte Aspekte eines neuen Produkts untersuchen zu können. Ein Prozess ist ein zeitlicher Ablauf, der aus mehreren Vorgängen mit wechselseitigen Abhängigkeiten besteht. Als Pufferzeit bezeichnet man die Differenz zwischen frühest möglichem und spätest möglichem Anfangszeitpunkt eines Vorgangs. Qualität ist das Maß der Erreichung eines Ziels durch eine konkrete Problemlösung. Randbedingungen sind Bedingungen, die bei der Lösung eines Problems eingehalten werden müssen. Nicht eingehaltene Randbedingungen stellen ein Scheitern der Problemlösung dar. Als Ressource kann man alle materiellen und monetären Mittel bezeichnen, die fiir die Durchführung eines Vorhabens zur Verfiigung stehen. Eine Risikoklasse fasst eine Gruppe vergleichbar schwerer Risiken zusammen. Eine Risikoklasse bildet in der risk-map einen zusammenhängenden Bereich. Risikomanagement ist die Planung und Steuerung aller Maßnahmen, die zum Erkennen und Vermeiden potenzieller Risiken sowie zur schadensmindernden Reaktion auf eingetretene Risiken dienen.

Al Glossar

281

In einer zweidimensionalen "risk-map" werden Risiken entsprechend ihrer Eintrittswahrscheinlichkeiten und des Schadensausmaßes eingetragen. Eine risk-map mit den wichtigsten Projektrisiken ist eine Darstellung des Risiko-Portfolios. Ein "risk-reduction-stair" stellt abgestufte risikoreduzierende Maßnahmenfür Risiken unterschiedlicher Schwere dar. Bei der Rückwärtsrechnung werden beim Projektende beginnend die spätest möglichen Terminefür Ereignisse und Vorgänge im Projektplan berechnet. Stakeholder sind nach ISO 10006 alle Personen, die ein Interesse am Projekt haben oder vom Projekt in irgendeiner Weise betroffen sind. Als Steuern bezeichnet man die zielgerichtete Beeinflussung von Aktivitäten. Ein System ist eine aus mehreren, untereinander verbundenen Teilen bestehende Einheit, die mit ihrer Umgebung über feste Schnittstellen in Wechselwirkung steht. Die Teile können Elemente oder Module sein. Ein Teilprojekt stellt eine aus mehreren zusammen gehörenden Arbeitspaketen bestehende Einheit eines Projekts dar. Bei der Top-Down-Vorgehensweise wird eine Aufgabe dadurch gelöst, dass man bei einem allgemeinen, abstrakten Ansatz beginnt und diesen weiter konkretisiert. Ein Termin ist der Zeitpunkt, an dem ein bestimmtes Ereignis eintritt. Trendanalyse dient der Gewinnung von Aussagen durch Auswertung des zeitlichen Verlaufs einer Größe. Das Ursache-Wirkungs-Diagramm (Ishikawa-Diagramm) ist eine standardisierte graphische Darstellung aller Faktoren, die auf eine Größe einwirken. Ein Vorgang ist die kleinste zeitliche Ablaufeinheit in einem Projekt und entspricht im Allgemeinen der Ausführung eines Arbeitspakets durch eine Person. Mehrere Vorgänge können zu einem Sammelvorgang zusammengefasst werden. Bei der Vorwärtsrechnung werden beim Projektanfang beginnend die frühest möglichen Terminefür Ereignisse und Vorgänge im Projektplan berechnet. Das Ziel ist der Zustand, in den ein System durch bestimmte Maßnahmen gebracht werden soll. Der Zustand eines Systems setzt sich aus den Werten aller Speichergrößen zusammen. Bei der Ideenproduktion nach der 635-Methode notieren 6 Teilnehmer je 3 Ideen auf einem Blatt. Nach jeweils 5 Minuten wandert das Blatt zum Nachbarn zur Weiterentwicklung der vorgefundenen Ideen, bis alle Teilnehmer alle Blätter bearbeitet haben. Als 95-%-Syndrom wird eine Situation bezeichnet, bei der Arbeiten nach scheinbar plangemäßem Fortschritt kurz vor Erreichen des Abgabetermins zunehmend Probleme bereiten und die Fertigstellung immer wieder hinausgeschoben wird.

282

Anhang

A3 Verweise AJ.I Literatur [Allen 2001] Allen, D.: Getting Things Done. The Art of Stress-Free Productivity. Verlag Viking Adult, 2001. [Balzert 1998] Ba1zert, H.: Lehrbuch der Software-Technik (Band 2). Spektrum Verlag, Heidelberg, Berlin, 1998. [Bernecker 2001] Bernecker, G. : Planung und Bau verfahrenstechnischer Anlagen: Projektmanagement und Fachplanungsfunktionen. Springer Verlag, Berlin, 4. Aufl., 2001. [Boehm 1981] Boehm, B.: Software Engineering Economics. Prentice Hall, 1981. [Boehm 1988] Boehm, B.: A spiral model of software development and enhancement. IEEE Computer, Jahrgang 21, Nr. 5, S. 61-72, 1988. [Braehmer 2009] Braehmer, D.: Projektmanagement für kleine und mittlere Unternehmen. Hanser Verlag München, 2. Aufl. 2009. [Bransford 1993] Bransford, J.D., Stein, B.S.: The ideal problem solver. Freeman, New York, 2.Aufl. 1993. [Bullinger 1995] Bullinger, H.-I.; Warschat, J.: Concurrent Simultaneous Engineering Systems. Springer-Verlag, Berlin, 1995. [Burghardt 1988] Burghardt, M.: Projektmanagement, Erlangen, 1988. [Daenzer 1982] Daenzer, W.F.: Systems Engineering. Verlag industrielle Organisation, 3. Aufl. 1982. [Dixius 1999] Dixius, D.: Simultane Projektorganisation. Springer-Verlag, 1999. [Dörner 1987] Dörner, D.: Problemlösen als Informationsverarbeitung. Kohlhammer, 3. Aufl. 1987. [Dülfer 1982] Dülfer, E.: Projektmanagement International. Schaeffer-Poeschel, Stuttgart, 1982. [Ehrlenspiel 2006] Ehrlenspie1, K.: Integrierte Produktentwicklung. Hanser-Ver1ag, 3. Aufl. 2006. [Eisenführ 1999] Eisenführ, F., Weber, M.: Rationales Entscheiden, Springer-Verlag, Berlin, 3. Aufl. 1999. [Franke 1998] Franke, A; Fürnohr, M.: Risikomanagement von Projekten.

Tüv Media, 1998.

[Gareis 1991] Gareis, R: Projektmanagement im Maschinen- und Anlagenbau. Wien, 1991. [Gigerenzer 2007] Gigerenzer, G.: Bauchentscheidungen - Die Intelligenz des Unbewussten und die Macht der Intuition. Berte1smann Verlag, München, 2007. [Gilb 1988] Gilb, T.: Principles ofSoftware Engineering Management. Addison wes1ey, 1988. [GPM 2004] GPM (Hrsg.): Projektmanagement Fachmann. RKW-Verlag, 8. Aufl. 2004. [Groh 1982] Groh, H.; Gutsch, RW.: Netzplantechnik, Düsseldorf, 1982. [Grünig 2004] Grünig, R, Kühn, R.: Entscheidungsverfahren für komplexe Probleme. Springer-Verlag, Berlin, 2004.

A3 Verweise

283

[Greiner 2009] Greiner, P., Mayer, P. E., Stark, K.: Baubetriebslehre - Projektmanagement. Vieweg+Teubner, Wiesbaden, 4. Aufl., 2009. Gutermuth 2007] Gutermuth, G., Hausmanns, C.: Kostenstruktur und Untergliederung von Automatisierungsprojekten. Automatisierungstechnische Praxis, atp, Heft 11, S. 84-92,2007. [Hab 2006] Hab, G., Wagner, R.: Projektmanagement in der Automobilindustrie. GablerVerlag, 2. Aufl. 2006. [Hahn 2002] Hahn, R.: Projektmanagement für Ingenieure. Wiley-VCH Verlag, Weinheim, 2002. [Herren 2008] Herren, J.: Zwischen Euphorie und Skepsis: Kreativitätstechniken im Praxiseinsatz. HR Today, Heft 3, 2008, S. 53. [Hilpert 2001] Hilpert, N., Rademacher, G., Sauter, B.: Projekt-Management und ProjektControlling im Anlagen- und Systemgeschäft. VDMA-Verlag, 2001. [Jakob 2007] Jakob, B.: Projektmanagement für den Mittelstand. Vdm Verlag Dr. Müller, 2007. [Jakoby 2006] Jakoby, W.: Supermann, was nun? Kliomedia, Trier, 2006. [Kerzner 1979] Kerzner, H.: Project Management, a Systems Approach to Planning, Scheduling and Controlling. New York, 1979. [Kowalski 2007] Kowalski, S.: Projekte planen und steuern mit Excel. Haufe-Verlag, 2007. [Knieß 1992] Knieß, M.: Nischenpolitik für Produktionsunternehmen der Bundesrepublik Deutschland. Münster 1992. [Kraus 2004] Kraus, G., Westermann, R.: Projektmanagement mit System. Gabler Verlag, Wiesbaden, 4. Aufl. 2004. [Kreyszig 1973] Kreyszig, E.: Statistische Methoden und ihre Anwendungen. Vandenhoeck & Ruprecht, 4. Aufl. 1973. [Lomnitz 2008] Lomnitz, G.: Multiprojekt-Management. Mi-Fachverlag, München, 2008. [Madauss 1983] Madauss, B.: Handbuch Projektmanagement. Schäffer-Poeschel-Verlag, 1983. [Martin 1976] Martin, C.C.: Project Management. How to make it work. Amacom Books, 1976. [Martino 1964] Martino, R: Project management and Control. New York, 1964. [Miller 1965] Miller, RW.: Zeit-Planung und Kosten-Kontrolle durch PERT. RV. Decker's Verlag, 1965. [Nachtigall 2002] Nachtigall, W.: Bionik. Springer-Verlag, 2. Aufl. 2002. [NAMUR 2003] NA 35: "Abwicklung von PLT-Projekten". Arbeitsblatt NA 35 der NAMUR, 2003. [Neubauer 2002] Neubauer, M.: Krisenmanagement in Projekten. Springer-Verlag, Berlin, 2. Aufl. 2002. [Osborn 1957] Osborn, A. F.: Applied Imagination - Principles and Procedures of Creative Problem-Solving. New York, 1957. [Patzak 1998] Patzak, G., Rattay, G.: Projekt-Management. Linde-Verlag Wien, 3. Aufl., 1998. [Peipe 2005] Peipe, S.; Kämer, M: Projektberichte, Statusreports, Präsentationen. HaufeVerlag, 2005.

284

Anhang

[Platz 1986] Platz, J.; Schmelzer, H.J.: Projektmanagement in der industriellen Forschung und Entwicklung. Springer-Verlag, 1986. [Pritsker 1966] Pritsker, A., Harp, W.: GERT - Graphical Evaluation and review Technique. The Journal ofIndustrial Engineering, 1966, S. 267-274. [REFA] http://www.lean-manu.de/Methoden_HTML/REFA-Planungssystematik.htm. [Ribbens 2000] Ribbens, J.: Simultaneous Engineering for new product development. John Wiley & Sons, 2000. [Rinza 1985] Rinza, P.: Projektmanagement. Überwachung und Steuerung von technischen und nichttechnischen Vorhaben. Springer, Berlin. 2. Aufl. 1985. [Rösch 1994] Rösch, W., Volkmann, W.: Bau-Projektmanagement. Verlag Rudolf Müller, Köln,1994. [Rump 2010] Rump, J., Schabei, F.: Wie Projektarbeit Unternehmen verändert. Harvard Business Manager. Heft 2, 2010, S. 16-19. [Saynisch 1979] Saynisch, M., Schelle, A., Schub, A.: Projektmanagement. Konzepte, Verfahren, Anwendungen. Oldenbourg-Verlag, 1979. [Saynisch 1984] Saynisch, M.: Konfigurationsmanagement. TÜV Media, Köln 1984. [Schelle 2004] Schelle, H.; Reschke, H.; Schnopp, R.; Schub, A.: Projekte erfolgreich managen. TÜV-Verlag, Köln, 2004. [Schelle 2007] Schelle, H.: Projekte zum Erfolg führen. dtv, München, 5. Aufl. 2007. [Schels 2005] Schels, 1.: Projektmanagement mit Excel. Addison Wesley, München, 2005. [Schlicksupp 1989] Schlicksupp, H.: Innovation, Kreativität und Ideenfindung. 3. Aufl. Würzburg, 1989. [Schneider 2008] Schneider, K.J.: Bautabellen für Ingenieure. Werner Verlag, 18. Aufl. 2008. [Schulte-Zurhausen 2002] Schulte-Zurhausen, M.: Organisation. Verlag Vahlen, München, 2. Aufl. 2002. [Schröder 1970] Schröder, H.: Projektmanagement - Eine Führungskonzeption für außergewöhnliche Vorhaben. Wiesbaden, 1970. [Schwarze 2006] Schwarze, J.: Projektmanagement mit Netzplantechnik. NWB Verlag, 9. Aufl., 2006. [Spath 2007] Spath, D.; Schimpf, S.; Kugler, A.: Webbasierte Open-Source-Kollaborationsplattformen. Studie der Fraunhofer-Gesellschaft, Institut für Arbeitswirtschaft und Organisation, Stuttgart, 2007. [Staehle 1999] Management. Eine verhaltenswissenschaftliche Perspektive. 8. Aufl., München 1999. [Zogg 1974] Zogg, A.: Systemorientiertes Projektmanagement. Zürich, 1974. [Zwicky 1966] Zwicky, F.: Entdecken, Erfinden, Forschen im morphologischen Weltbild. München/Zürich, 1966.

A3 Verweise

285

AJ.2 Hyperlinks www.ipma.ch: International Project Management Association www.gpm-ipma.de: Deutsche Gesellschaft für Projektmanagement (GPM), Mitglied der IPMA www.pmaktuell.org: Monatliches Fachmagazin der GPM www.spm.ch: Schweizerische Fachorganisation für Projektmanagement www.p-m-a.at: österreichische Projektmanagement-Vereinigung www.pmi.org: Projektmanagement-Institut www.projektmagazin.de: Internet-Fachmagazin für das Projektmanagement www.innovations-report.de: Forum für Innovationen in Wissenschaft, Industrie und Wirtschaft www.projektmanagementhandbuch.de: online-Handbuch pmsoftware.info: Informationen zu PM-Software-Werkzeugen www.project-management-software.org: Informationen zu PM-Software-Werkzeugen www.pmworldtoday.net: Internationales online-PM-Fachmagazin www.vdma.org: Verband Deutscher Maschinen- und Anlagenbau e.V. www.zvei.de: Zentralverband Elektrotechnik- und Elektronikindustrie e.V. www.bitkom.org: Bundesverband Informationswirtschaft, Telekommunikation und neue Mediene.V. www.bauindustrie.de: Hauptverband der Deutschen Bauindustrie e.V. www.vdi.de: Verein Deutscher Ingenieure e.V. www.vde.de: Verband der Elektrotechnik Elektronik Informationstechnik e.V. www.gi-ev.de: Gesellschaft für Informatik e.V. Ganttproject.biz: PM-Tool Gantt Project, basierend auf Java www.openworkbench.org: PM-Tool Open Workbench, basierend aufJava www.serena.com/products/openproj: PM-Tool Open Proj, basierend auf Java www.dotproject.net: PM-Tool dot Project, web-basiert www.tiddlywiki.com: Rechnerbasiertes Werkzeug zur Organisation von Ideen, Notizen und Arbeiten www.open-xchange.com: Groupware für die Projekt-Kollaboration www.phprojekt.de: Groupware für die Projekt-Kollaboration www.egroupware.org: Groupware für die Projekt-Kollaboration www.dotproject.net: Groupware für die Projekt-Kollaboration www.projectcartoon.com: Cartoons zum Thema "How projects really work"

286

Anhang

A3.3 Normen DIN 69900-69905: Normenreihe zur Projektwirtschaft (1987) DIN 69900: Netzplantechnik, Begriffe (1987) DIN 69901: Projektmanagement, Begriffe (1987) DIN 69902: Einsatzmittel, Begriffe (1987) DIN 69903: Kosten und Leistung, Finanzmittel, Begriffe (1987) DIN 69904: Projektmanagementsysteme, Elemente und Strukturen (2000) DIN 69905: Projektabwicklung Begriffe (1997) DIN 19246: Messen, Steuern, Regeln - Abwicklung von Projekten - Begriffe BS 6079: A guide to project management. (British Standard, 2002) ISO 10006: Qualitätsmanagementsysteme - Leitfaden für Qualitätsmanagement in Projekten (2003) ISO 21500: Guide to project management. In Arbeit befindliche internationale Projektmanagement-Norm

A4 Verzeichnisse

287

A4 Verzeichnisse A4.1 Formelzeichen A a b c C Di E F(x) FAi FEi Fi FP GP I(t) L M P PT PM PJ pet) p(x) R S SAi SEi Si T To Tp Tw Te Ts V w X x

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) Zeitlicher Puffer Personentag Personenmonat (1 PM = 20 PT) Personenjahr (1 PJ = 11 PM = 220 PT) Plan-Verlauf Wahrscheinlichkeitsdichtefunktion einer Zufallsvariablen Risiko Standardabweichung einer Verteilungsfunktion Spätester Anfangstermin für den Vorgang i Spätester Endtermin für den Vorgang i Spätester Termin für ein Ereignis i, bzw. Schadensausmaß Zeitdauer Zeitdauer, optimistisch geschätzt Zeitdauer, pessimistisch geschätzt Zeitdauer, wahrscheinlichster Wert Zeitdauer, Erwartungswert Zeitdauer, Standardabweichung Varianz einer Verteilungsfunktion wahrscheinlichster Wert einer Verteilungsfunktion Zufallsvariable Wert einer Variablen

288

Anhang

A4.2 Beispiele Beispiel 1-1 Beispiel 1-2 Beispiel 1-3 Beispiel 1-4 Beispiel 1-5 Beispiel 1-6 Beispiel 1-7 Beispiel 1-8 Beispiel 1-9 Beispiel 1-10 Beispiel 1-11 Beispiel 1-12 Beispiel 1-13 Beispiel 1-14 Beispiel 2-1 Beispiel 2-2 Beispiel 2-3 Beispiel 2-4 Beispiel 2-5 Beispiel 2-6 Beispiel 2-7 Beispiel 2-8 Beispiel 2-9 Beispiel 2-10 Beispiel 2-11 Beispiel 2-12 Beispiel 2-13 Beispiel 3-1 Beispiel 3-2 Beispiel 3-3 Beispiel 3-4 Beispiel 3-5 Beispiel 4-1 Beispiel 4-2 Beispiel 4-3 Beispiel 4-4 Beispiel 4-5 Beispiel 4-6 Beispiel 4-7 Beispiel 4-8 Beispiel 4-9 Beispiel 4-10 Beispiel 4-11

Umzug Sind das alles Projekte? Studium Projektkriterien Grillfete Aufgaben, Probleme, Projekte Problemdimensionen Studium Das Springer-Problem Das Damen-Problem Fallbeispiel "Maschinenterminal M4" Fallbeispiel "Solaranlage" Fallbeispiel "Dokumenten-Managementsystem (DMS)" Fallbeispiel "CAD-Software" Sporadische Ausfälle der Steuerung eines Manipulators Pareto-Analyse der Welt-Bevölkerungsstatistik Entwicklung eines fahrradtauglichen Navigationsgeräts (Teil 1) Entwicklung eines fahrradtauglichen Navigationsgeräts (Teil 2) Smarte und unsmarte Ziele Fallbeispiel "CAD-Software": Zielformulierung Deckungsbeitrag für Kunststoffgehäuse Korrelationen und Konflikte bei Zielvariablen Überwindung von Denkblockaden Morphologische Methode zur Suche nach neuen Sensoren Apotheken-Lagerfläche Präferenzmatrix für die Wahl eines Studienfachs Fallbeispiel "CAD-Software": Nutzwertanalyse Fallbeispiel "DMS": Lastenheft LastenheftlPflichtenheft für den Einsatz von Automatisierungssystemen Leistungsverzeichnis bei einem Bauprojekt Fallbeispiel "CAD-Software": Projektdefmition Angebotsgliederung Neue Produktionslinie für einen Pizza-Hersteller Fallbeispiel "Solaranlage": Aufbauorganisation Fallbeispiel "DMS": Aufbauorganisation Brandmeldezentrale Qualitäts-Managementsystem (QMS) IMV-Matrix Arbeitspakete bei der Entwicklung eines elektrischen Messgeräts Fallbeispiel "Maschinenterminal": Typische Teilprojekte Leistungsphasen nach HOAI Projektplan mit sequentieller und paralleler Bearbeitung Fallbeispiel "Maschinenterminal": Simultaneous Engineering

1 5 7 10 16 17 18 20 21 22 30 31 31 31 38 42 .45 .46 48 50 52 53 55 59 61 64 65 75 76 77 79 81 91 93 94 95 96 96 98 98 100 105 106

A4 Verzeichnisse

289

Beispiel 4-12 Beispiel 4-13 Beispiel 4-14 Beispiel 4-15 Beispiel 5-1 Beispiel 5-2 Beispiel 5-3 Beispiel 5-4 Beispiel 5-5 Beispiel 5-6 Beispiel 6-1 Beispiel 6-2 Beispiel 6-3 Beispiel 6-4 Beispiel 6-5 Beispiel 6-6 Beispiel 6-7 Beispiel 6-8 Beispiel 6-9 Beispiel 6-10 Beispiel 6-11 Beispiel 7-1 Beispiel 7-2 Beispiel 7-3 Beispiel 7-4 Beispiel 7-5 Beispiel 7-6 Beispiel 7-7 Beispiel 8-1 Beispiel 8-2 Beispiel 8-3 Beispiel 8-4 Beispiel 8-5 Beispiel 8-6 Beispiel 9-1 Beispiel 9-2 Beispiel 9-3 Beispiel 9-4 Beispiel 9-5 Beispiel 10-1 Beispiel 10-2 Beispiel 11-1 Beispiel 11-2 Beispiel 11-3

108 109 114 116 123 124 128 129 132 133 138 140 141 142 146 148 151 152 153 157 158 163 164 171 173 175 177 179 186 190 193 196 198 199 204 214 215 217 218 232 232 262 263 264

Projektinfonnationen Infonnationskategorien Fallbeispiel "CAD-Software", Besprechungsbericht Zusammensetzung eines PM-Handbuchs Produktstrukturplan Wohnhaus Fallbeispiel "Maschinenterminal": Produktstrukturp1an Fallbeispiel "Maschinenterminal": Projektstrukturp1an Fallbeispiel "Solaranlage": Projektstrukturp1an Standard-Projektstrukturp1an Prozess1eittechnik-Projekte Landfläche der Erde Gebäudekostenschätzung Kalkulationsschema für Entwicklungskosten Fallbeispiel "Solaranlage": Schätzung des Arbeitsaufwands Würfeln Schätzung einer Projektdauer (1) Aussagen über Aufwand und Laufzeit... Schätzung einer Projektdauer (2) Aufwandsschätzung in einem Projekt Projektierungs-Software Berechnungs-Programm für Transportbahnen Anordnungsbeziehungen Temperaturmessbox PERT-Projektana1yse Kritischer Pfad beim Temperaturmessbox -Projekt Fallbeispiel "Maschinentennina1 M4": Gantt-Diagramm Prozesssteuerung Kapazitätsplanung Personalrisiko Risiken bei der Entwicklung einer Elektronikbaugruppe Projekt-FMEA für das Fallbeispiel Maschinentenninal... Hardware-Entwicklungsprojekt Personalrisiko in einem Entwicklungsprojekt Fallbeispiel "CAD-Software": Risikoportfolio Projektstatusberichte Leistungspakete für die Fortschrittsp1anung Fallbeispiel "DMS": Planung der Kostenbudgets Mei1enstein-Trendana1yse Schulausbildung ALPEN Getting Things done (GTD) Zusammenhang zwischen Arbeit, Dauer und Einheit Ressourcenberechnung Temperaturmessbox

290

Anhang

A4.3 Abbildungen Bild 1-1 Bild 1-2 Bild 1-3 Bild 1-4 Bild 1-5 Bild 1-6 Bild 1-7 Bild 1-8 Bild 1-9 Bild 1-10 Bild 1-11 Bild 1-12 Bild 1-13 Bild 1-14 Bild 1-15 Bild 2-1 Bild 2-2 Bild 2-3 Bild 2-4 Bild 2-5 Bild 2-6 Bild 2-7 Bild 2-8 Bild 2-9 Bild 2-10 Bild 3-1 Bild 3-2 Bild 3-3 Bild 3-4 Bild 3-5 Bild 3-6 Bild 4-1 Bild 4-2 Bild 4-3 Bild 4-4 Bild 4-5 Bild 4-6 Bild 4-7

Ein einfacher, erster Projektplan für den Umzug Abgrenzung von Projekten und Nicht-Projekten Klassifizierung von Projekten nach der Projektgröße Externe Sicht zur System-Abgrenzung Interne System-Sicht Ein Projekt aus Systemsicht Zustandsraummodell des Problemlösungsprozesses Problemdimensionen Aufwand und Nutzen und mögliche Unterteilungen Zustandsraum des Problems "Studium" Begriffliche Abgrenzung von Projekten Stetiger Arbeitsfluss Zeitlich und inhaltlich abgegrenztes Projekt Erste Unterteilung eines Projekts Weitergehende Projektunterteilung (Def.: Definition, Ab.: Abschluss) Organigramm des Beispiel-Unternehmens mit Bereichen und Abteilungen Die 5 Schritte des Problemlösungsprozesses Ishikawa-Diagramm der Einflussfaktoren für die Wahl eines Studienplatzes Weltweite Bevölkerungsstatistik nach Staaten Erstellung eines Zielsystems Hierarchische Zielstrukturierung (Zielbaum) Streichholzaufgabe mit 4, 7 und 9 Streichhölzern Präferenzmatrix für die Studienfachwahl Verschiedene Nutzenfunktionen Screenshot der bewerteten Varianten Abis E Screenshot der gewichteten Nutzenfunktionen für die 3 Varianten A, C und D Zieldreieck von Projekten ("Magisches" Projektdreieck) Darstellung geänderter Ziele eines Projektes im Zieldreieck Projektdefinition für das Projekt "CAD-Software" Auftragsdokumente Das Aufwands-Auftrags-Dilemma Vorprojekt und Projektstudie Organigramm eines Unternehmens Reine Projektorganisation Matrix-Projektorganisation Auftrags-Projektorganisation Einfluss-Projektorganisation Projektleitung in der Linie Abhängigkeit der Organisationsform von Projektgröße und Schnittstellenzahl

2 8 11 13 14 15 19 19 20 22 24 24 25 26 30 36 ,41 42 44 53 56 64 65 66 66 72 72 79 80 82 84 89 90 91 92 92 93 95

A4 Verzeichnisse

291

Bild 4-8 Bild 4-9 Bild 4-10 Bild 4-11 Bild 4-12 Bild 4-13 Bild 4-14

99 102 103 103 104 105

Bild 4-15 Bild 4-16 Bild 4-17 Bild 4-18 Bild 5-1 Bild 5-2 Bild 5-3 Bild 5-4 Bild 5-5 Bild 5-6 Bild 5-7 Bild 5-8 Bild 5-9 Bild 5-10 Bild 6-1 Bild 6-2 Bild 6-3 Bild 6-4 Bild 6-5 Bild 6-6 Bild 6-7 Bild 6-8 Bild 6-9 Bild 6-10 Bild 6-11 Bild 6-12 Bild 6-13 Bild 6-14 Bild 6-15 Bild 7-1 Bild 7-2 Bild 7-3 Bild 7-4 Bild 7-5

Arbeitspakete, Teilprojekte und Projektphasen In Phasen gegliederte Standard-Ablaufstruktur ("Wasserfallmodell") Unterteilung der Phasen in Grob- und Fein-Phasen Grob- und Fein-Phasen (A-E-R-V) Spiralförmiger Ablauf mit mehreren iterativen Durchläufen Ablauf mit Simultaneous Engineering Screenshot eines Projektplans mit sequentieller und parallelisierter Ausführung Projektplan Maschinenterminal M4 Dokumentenarten in einem Projekt (F: Formular im Anhang) Screenshot eines Besprechungsberichts PM-Handbuch als Output der Projektorganisation Arbeitsschritte der Projektplanung Produktstrukturplan Wohnhaus (Auszug) 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 Produktstrukturplan Solaranlage Gewinnung von Aussagen aus verfUgbaren Informationen Qualitative Schätzung des Projektaufwands durch Vergleich Screenshot des Projektstrukturplans "Solaranlage" Zusammenhang Schätzaufwand/Schätzgenauigkeit Verteilungsfunktion F(x) und Dichtefunktion p(x) einer Variablen x Dichtefunktion bei einem Würfel Dichtefunktion der Punktesumme zweier Würfel Dichtefunktion der Projektdauer (in Tagen) Gleichverteilung (I), Dreieck-Verteilung (11) und Beta-Verteilung (III) Normalverteilung (Erwartungswert Te, Standardabweichung Ts) Bestimmung der Wahrscheinlichkeit P(x,z) bei der Normalverteilung Projektaufwandsschätzung als Schätzwertsummen Projektaufwandsschätzung als Schätzwertsummen Abhängigkeit der Projektdauer von der Zahl der Personen Projektplan für das Fallbeispiel "Solaranlage" Anordnungsbeziehungen bei Arbeitspaketen Anordnungsbeziehungen in graphischer Darstellung Arbeitspakete für den Aufbau einer Temperaturmessbox Ablaufplan als Vorgangs-Knoten-Netz für das Beispiel Temperaturmessbox Ereignis-Knoten-Netz (EKN)

105 107 112 114 116 121 123 125 125 126 128 129 131 132 135 136 139 142 144 145 147 147 148 149 150 150 153 154 155 161 163 164 165 166 167

292

Bild 7-6 Bild 7-7 Bild 7-8 Bild 7-9 Bild 7-10 Bild 7-11 Bild 7-12 Bild 7-13 Bild 7-14 Bild 7-15 Bild 7-16 Bild 7-17 Bild 7-18 Bild 7-19 Bild 7-20 Bild 7-21 Bild 7-22 Bild 8-1 Bild 8-2 Bild 8-3 Bild 8-4 Bild 8-5 Bild 8-6 Bild 9-1 Bild 9-2 Bild 9-3 Bild 9-4 Bild 9-5 Bild 9-6 Bild 9-7 Bild 9-8 Bild 9-9 Bild 9-10 Bild 9-11 Bild 9-12 Bild 9-13 Bild 9-14 Bild 9-15 Bild 9-16 Bild 9-17

Anhang 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") Reale und ideale 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 Vorgangs-Knoten-Netz Der Risikomanagement-Prozess Risk-Map: Eintrittswahrscheinlichkeit p, Schadensausmaß S Screenshot der Maßnahmenbewertung Analyse des Personalrisikos in einem Entwicklungsprojekt Risiko-Portfolio für das Fallbeispiel "CAD" Risiko-Portfolio Arbeitsschritte der Projektplanung Gantt-Diagramm eines Beispiel-Projekts Zieldreieck zur Messung des Projektfortschritts Soll-Istwert-Abweichungen bei Projekten Planung des Projektfortschritts Richtige Dimensionierung der Leistungspaketgrößen Projektplan SW-Projekt Planung der Kostenbudgets Gantt-Diagramm eines kleinen Projekts Meilenstein-Trendanalyse Meilenstein-Trendanalyse einer Schul- und Hochschulausbildung Charakteristische Meilenstein-Trend-Muster Meilenstein-Trend-Muster bei zu optimistischer und zu vorsichtiger Schätzung Problematische Meilenstein-Trend-Muster (I) Problematische Meilenstein-Trend-Muster (11) Reaktion auf einen Rückstand im Projektfortschritt Status des Software-Projekts

168 169 169 170 171 173 174 175 175 177 177 178 179 179 180 181 183 187 191 196 198 199 202 203 205 209 210 212 213 214 215 217 218 219 220 220 221 221 223 227

A4 Verzeichnisse

293

Bild 11-1 Einordnung von Projektmanagement-Software-Werkzeugen Bild 11-2 Schnittstellen von MS-Project Bild 11-3 MS-Project, Start: Standardansicht eines neuen Projekts Bild 11-4 MS-Project, Schritt 1: Eingabe von Vorgängen Bild 11-5 MS-Project, Schritt 2: Eingabe der Zeiten Bild 11-6 MS-Project, Schritt 3: Ablaufplanung mit Hilfe der Anordnungsbeziehungen Bild 11-7 MS-Project, Ansicht Netzplan Bild 11-8 MS-Project, Schritt 4: Eingabe der Ressourcen Bild 11-9 MS-Project, Schritt 5: Zuordnung der Ressourcen Bild 11-10 Vergleich von Plan- und Istwerten mit Hilfe eines Basisplans Bild 11-11 PERT-Analyse für die Temperaturmessbox Bild 11-12 Dateien von MS-Project Bild A-1 Gemeinsame Vorlage für alle Projekt-Dokumente Bild A-2 Formular für eine Projektdefinition Bild A-3 Vorlage für eine Arbeitspaketbeschreibung Bild A-4 Vorlage für einen Besprechungsbericht Bild A-5 Vorlage für einen Statusbericht Bild A-6 Vorlage für eine To-Do-Liste Bild A-7 Formular zur Analyse eines Risikofaktors

252 256 256 258 258 259 260 261 262 264 265 265 269 270 271 272 273 274 275

294

Anhang

A4.4 Tabellen Tabelle 1.1 Tabelle 1.2 Tabelle 1.3 Tabelle 1.4 Tabelle 1.5 Tabelle 2.1 Tabelle 2.2 Tabelle 2.3 Tabelle 2.4 Tabelle 2.5 Tabelle 2.6 Tabelle 2.7 Tabelle 2.8 Tabelle 2.9 Tabelle 2.10 Tabelle 2.11 Tabelle 2.12 Tabelle 3.1 Tabelle 3.2 Tabelle 3.3 Tabelle 4.1 Tabelle 4.2 Tabelle 4.3 Tabelle 4.4 Tabelle 4.5 Tabelle 4.6 Tabelle 4.7 Tabelle 4.8 Tabelle 5.1 Tabelle 5.2 Tabelle 6.1 Tabelle 6.2 Tabelle 6.3 Tabelle 6.4 Tabelle 6.5 Tabelle 7.1 Tabelle 7.2 Tabelle 7.3 Tabelle 7.4

7 Fragen zum Projekt Problematiken von Projekten und zugehörige Maßnahmen Projektkriterien für verschiedene Projekte Kriterien für Aufgaben, Probleme, Problemlösungsprozesse und Projekte Checkliste Projektmanagement. 4 Was-Fragen zur Problemerkennung 6 W-Fragenkatalog zur Problemerkennung Typische Fehlersituationen bei der Problemerkennung Zielsystem des Fahrrad-Navigationsgeräts Merkmale SMARTer Zielkriterien Zielvariablen und Randbedingungen zur Anschaffung eines CAD-Systems Kreativitätshemmende und -fördernde Faktoren Morphologischer Kasten für passive elektrische Aufnehmer Fragemethodiken zur Aufspannung von Lösungsräumen Vergleich der Kreativitätsmethoden Nutzwertanalyse zur Bewertung von Alternativen Ak anhand der Kriterien Ki Checkliste Problemlösen Leistungsverzeichnis bei einem Gewerk eines Bauprojekt Projektgründung Inhalt von Lasten- und Pflichtenheft 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 Checkliste Projektorganisation Checkliste Informations-, Kommunikations- und Dokumentenmanagement Phasen und Aktivitäten von PLT-Projekten Checkliste Strukturplanung Kalkulationsschema für Entwicklungskosten Gegenüberstellung verschiedener Schätzmethoden Konkrete Werte für P(x, z) bei der Normalverteilung CoCoMo-Schätzmodelle und Parameter Checkliste Aufwandsschätzung Anordnungsbeziehungen Verteilungsfunktion F(A) des Aufwands A Geschätzte und berechnete Zeitwerte Verteilungsfunktion F(T) der Projekt-Laufzeit T

3 9 10 23 32 37 38 .40 47 48 51 55 59 60 62 65 68 77 84 85 89 97 99 101 106 109 117 118 133 134 141 144 151 157 159 163 172 172 173

A4 Verzeichnisse

295

Tabelle 7.5 Tabelle 8.1 Tabelle 8.2 Tabelle 8.3 Tabelle 8.4 Tabelle 8.5 Tabelle 8.6 Tabelle 9.1 Tabelle 9.2 Tabelle 9.3 Tabelle 9.4 Tabelle 9.5 Tabelle 10.1 Tabelle 10.2 Tabelle 10.3 Tabelle 10.4 Tabelle 10.5 Tabelle 10.6 Tabelle 10.7 Tabelle 10.8 Tabelle 11.1 Tabelle 11.2 Tabelle 11.3 Tabelle 11.4 Tabelle 11.5 Tabelle 11.6

182 189 192 193 193 194 201 208 210 217 226 226 231 235 238 240 242 245 247 249 257 259 261 263 266 267

Checkliste Ablauf- und Terminplanung Checkliste Projekt-Risikofaktoren Bestimmung von Risikoklassen Bestimmung der Risikoprioritätszahl Ergebnis der FMEA (Auszug) Risk reduction stair Checkliste Risikomanagement Ermittlung des Fertigstellungsgrads (FGR, in 0 100 %) Reaktionsmöglichkeiten auf Planabweichungen Aktualisierung der Meilensteine durch Restaufwandsschätzung Checkliste Projektsteuerung Checkliste Projektabschluss Methodik des effizienten Arbeitens Stress-Ursachen, -Reaktionen und -Bewältigung Checkliste Kritikgespräch Anforderungen an Projektleiter Situative Reifegrad-Theorie Persönlichkeitseigenschaften Entwicklungsphasen von Arbeitsgruppen (nach Tuckman) Checkliste Arbeitsmethodik Wichtige Icons von MS-Project Eine Auswahl wichtiger Vorgangs-Attribute Eine Auswahl wichtiger Ressourcen-Attribute Berechnungsmodi Checkliste Anforderungen an PM-Tools Arbeiten des Fallbeispiels "CAD-Software"

Sachwortverzeicltnis A

ABC-Analyse 41 Ablauforganisation 97 Abnahme 224 Abnahmebericht 224 Abschlussanalyse 224 80/20-Rege1 42 alarp 194 ALPEN-Methode 232 Änderungsmitteilung 110 Anfangsfolge 162 Angebot 80 Anordnungsbeziehung 162 Arbeitsfluss 23 Arbeitspaket 98 Argumentenbilanz 63 Aufgabe 17 Ausschreibung 80 B

Basic Model 156 Basisplan 264 Bauch-Entscheidungen 63 Bericht 113,204 Betaverteilung 149 Beziehung 165 Beziehungsdiagramm 41 Bindefrist 81 Bottom-up-Ansatz 124 Brainstorming 57 Brainwriting 57 C CAPI 28 Checkliste 113 CoCoMo 156 Concurrent Engineering 104 Critical-Path-Method (CPM) 168 CSCW 255 D

Delegieren 236 De1phi-Methode 143 Denkhüte-Methode 58

Disney-Methode 57 Dokument 110 Dokumentation 110 Dokumentenmanagementsystem 111 Dreiecksverteilung 149 Dreipunktschätzung 152 E

Einstellungseffekt 55 Eisenhower-Prinzip 230 Endefolge 162 Entwicklungsprojekt 12 Ereignis 165 Ereignis-Knoten-Netz (EKN) 166 Erfahrungssicherung 224 Erwartungswert 146

F Feasabi1ity Study 84 Feedback 238 FMEA 192 Forschungsprojekt 12 Fortschrittsplanung 211 Fortschrittssteuerung 222 Führungsstile 241 Fünf-Faktoren-Modell 245 95-%-Syndrom 208, 14 Funktionale Fixierung 55 G

Gleichverteilung 148 GPM 28 Groupware 255 GTD 232 Gütekriterien 50 I

ICB 28 Imagine-Methode 58 IMV-Matrix 96 Information 108 informelle Abfragen 204 Inkubation 56 Integrierte Produktentwicklung 104

Walter Jakoby, Projektmanagement für Ingenieure, DOI 10.1007/978-3-8348-9759-6, © Vieweg+Teubner Verlag I Springer Fachmedien Wiesbaden GmbH 2010

Sachwortverzeichnis Intuitive Entscheidungsverfamen 63 IPMA 28 Ishikawa-Diagramm 41 K Kalender 257 Kanten 165 Kapazitätsgebirge 177 Kapazitätsplanung 176 Kartenabfrage 57 Knoten 165 Kommunikation 109 Kontrollieren 237 Kostenbudget 215 Kosten-Wirksamkeitsanalyse 66 Krise 223 Krisenmanagement 223 Kritikgespräch 238 kritischer Pfad 169 L Leistungskurve 231 Leistungsverzeichnis 73 Liste offener Punkte (LOP) 115 Logbuch 113 M Machbarkeitsstudie 84, 195 Management 25 Median 146 Meilenstein 100 Meilenstein-Trendanalyse 216 Meilenstein-Trendverlauf 218 Meta-Plan-Methode 57 Metra-Potential-Methode (MPM) 169 Mikroplanung 229 morphologischer Kasten 59 Motivation 237 N Netz 165 Netzplan 165,260 Normalfolge 162 Normalverteilung 149 Notiz 113 Nutzwertanalyse (NWA) 65

o

operationalisierbare Ziele 46

297 Operations Research 67 OPM3 29 Organ 88 Organisation 88 Organisationsprojekt 12 p Pareto-Prinzip 42 Personalaufwand 11 Personalauswahl 244 Personaltabelle 114 Personenjam 11 Personenmonat 11 Personentag 11 Persönlichkeitseigenschaften 245 - emotionale Stabilität 245 - Entscheidungsfindung 246 - Entscheidungsmobilität 246 - Gewissenhaftigkeit 247 - Interaktionsform 245 - Offenheit 246 - Verträglichkeit 246 - Wahrnehmungsart 246 Persönlichkeitszirkel 245 PERT-Methode 170 Plannet 174 PMBOK 28 PMI 28 PMI-Methode 58 PMP 28 Präferenzmatrix 63 PRINCE2 28 Problem 18 Problemdimension 18 Problemlösungsprozess 21 Produktorientierte Gliederung 127 Produktstrukturplan 122 Projekt 6 Projektabschluss 224 Projektart 12 Projektauflösung 225 Projektberichtswesen 204 Projektdatenauswertung 209 Projektdatenerfassung 204 Projektdeftnition 79 Projektgegenstand 12 Projektgröße 11 Projektierungsprojekt 12 Projektkriterien 10

298 Projektleiter - Anforderungsprofile 239 - Aufgaben 235 Projektmanagement 25 Projektmanagement-Handbuch 115 Projektmanagement-Lebenszyk1us 26 Projektorganisation - Auftrags-PO 91 - Einfluss-PO 92 - Linienorganisation 88 - Matrix-PO 91 - Projektleitung in der Linie 93 - reine PO 90 Projektorganisation (PO) 88 Projektphase 100 Projektp1anung 121 Projektsteuerung 203 Projektstrukturplan 126 Projektstudie 84 Projektteam 242 Projektvertrag 81 Prozessorientierte Gliederung 129 R

RACI-Matrix 97 Randbedingungen 49 Raten 136 Reifegrad-Theorie 241 Ressource 255 Ressourcentabelle 113 Restaufwand 208 Restaufwandsschätzung 208 Risikograph 191 Risiko-Portfolio 191 risk reduction stair 194 Risk-Map 191 Rückwärtsrechnung 168

S Samme1vorgang 257 Schätzen 137 - in der Gruppe 143 - intuitive Schätzung 139 - quantitative Schätzung 139 - Schätzgrößen skalieren 143 - vergleichende Schätzung 139 - Zerlegung der Suchgröße 142 6-3-5-Methode 57, 14

Sachwortverzeichnis 6-VV-Methode 38 Selbstmanagement 229 Simu1taneous Engineering 104 SMART 48 Spiralmodell 104 Sprungfolge 162 Standardabweichung 146 Standard-Projektstrukturp1an 131 Statusbericht 204 Stress 233 Stressbewältigung 234 Stressoren 233 System 13 T

Teilprojekt 98 Temperamentenlehre 245 To-Do-Liste 114 Top-down-Ansatz 124 TRIZ 61 Typenindikator 245 U Ursache-VVirkungs-Diagramm 40

V Varianz 146 Versionierung 110 Verteilungsfunktion 145 V-Modell XT 29 Vorgang 165,255 Vorgangs-Knoten-Netz (VKN) 166 Vorgangs-Pfeil-Netz (VPN) 166 Vorprojekt 84 Vorwärtsrechnung 168

w

VVahrscheinlichkeitsdichtefunktion 145 VVasserfa1lmodell 102 VVirtschaftlichkeitsanalyse 67 VVissen 137 work breakdown structure (VVBS) 126 Z

Zufallsvariable 145 Zweipunktschätzung 152