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

Author: Walter Jakoby

111 downloads 1568 Views 32MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

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>, ~.t":;"~

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


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


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


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


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


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


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.


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


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


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


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


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?


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


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

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

:-/:!..-/-':

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


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-


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-


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


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?


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


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


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


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.


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.


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


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


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


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


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

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

;.

t..

'&tros

~~'io

,,~

,,~

,,~

,,~

~D)e+1

1:1S

_~f'
hl:

~~

Zll'~

~

"~

..

~

Eonstor

+ -

? ArioI

.S.FKll

v

,

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)


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


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

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

Algorithmen fur Ingenieure - realisiert mit Visual Basic

Innovationen fur den Journalismus

Projektmanagement mit Excel

Projektmanagement mit Excel

Projektmanagement mit Excel

Konzeptentwicklung und Gestaltung technischer Produkte, 2. Auflage

Regelungstechnik fur Ingenieure

Elektrotechnik fur Ingenieure 2

Chemie: Grundwissen fur Ingenieure

Physik fur Ingenieure

Projektmanagement mit Excel GERMAN

Elektrotechnik fur Ingenieure

30 Minuten fur besseres Projektmanagement

30 Minuten fur die erfolgreiche Problemlosung

Elektrotechnik fur Ingenieure - Klausurenrechnen: Aufgaben mit ausfuhrlichen Losungen, 4. Auflage

Mathematik fur Ingenieure und Naturwissenschaftler

Thermodynamik: Ein Lehrbuch fur Ingenieure

Mathematik fur Ingenieure und Naturwissenschaftler

Ubungsaufgaben zur Mathematik fur Ingenieure Mit durchgerechneten und erklarten Losungen

Management fur Ingenieure: Technisches Management fur Ingenieure in Produktion und Logistik

Projektmanagement fur technische Projekte: Ein prozessorientierter Leitfaden fur die Praxis

Endlich im grunen Bereich! Projektmanagement fur jedermann

Softwarequalitat in PHP-Projekten

Risikomanagement in Projekten

BWL fur Ingenieure und Ingenieurinnen. Was man unbedingt als Ingenieur in der Betriebswirtschaft wissen sollte

Informatik fur Ingenieure und Naturwissenschaftler 2

Physik Aufgabensammlung. Fur Ingenieure und Naturwissenschaftler

C++ fur Ingenieure: Effizient Programmieren erlernen

Physik. Eine Einfuhrung fur Ingenieure 4. Auflage

Risikomanagement in Projekten

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

Algorithmen fur Ingenieure - realisiert mit Visual Basic

Innovationen fur den Journalismus

Projektmanagement mit Excel

Projektmanagement mit Excel

Projektmanagement mit Excel

Konzeptentwicklung und Gestaltung technischer Produkte, 2. Auflage

Regelungstechnik fur Ingenieure

Elektrotechnik fur Ingenieure 2

Chemie: Grundwissen fur Ingenieure

Physik fur Ingenieure

Projektmanagement mit Excel GERMAN

Elektrotechnik fur Ingenieure

30 Minuten fur besseres Projektmanagement

30 Minuten fur die erfolgreiche Problemlosung

Elektrotechnik fur Ingenieure - Klausurenrechnen: Aufgaben mit ausfuhrlichen Losungen, 4. Auflage

Mathematik fur Ingenieure und Naturwissenschaftler

Thermodynamik: Ein Lehrbuch fur Ingenieure

Mathematik fur Ingenieure und Naturwissenschaftler

Ubungsaufgaben zur Mathematik fur Ingenieure Mit durchgerechneten und erklarten Losungen

Management fur Ingenieure: Technisches Management fur Ingenieure in Produktion und Logistik

Projektmanagement fur technische Projekte: Ein prozessorientierter Leitfaden fur die Praxis

Endlich im grunen Bereich! Projektmanagement fur jedermann

Softwarequalitat in PHP-Projekten

Risikomanagement in Projekten

BWL fur Ingenieure und Ingenieurinnen. Was man unbedingt als Ingenieur in der Betriebswirtschaft wissen sollte

Informatik fur Ingenieure und Naturwissenschaftler 2

Physik Aufgabensammlung. Fur Ingenieure und Naturwissenschaftler

C++ fur Ingenieure: Effizient Programmieren erlernen

Physik. Eine Einfuhrung fur Ingenieure 4. Auflage

Risikomanagement in Projekten

Recommend Documents