Beruflich Dokumente
Kultur Dokumente
Kompakte Einführung in Das Projekt
Kompakte Einführung in Das Projekt
Nicole Schelter
Kompakte Einführung in
das Projektmanagement
Mit vielen praxisnahen Beispielen
und modernen didaktischen Instrumenten
Kompakte Einführung in das
Projektmanagement
Theo Peters · Nicole Schelter
Die Online-Version des Buches enthält digitales Zusatzmaterial, das durch ein Play-Symbol
gekennzeichnet ist. Die Dateien können von Lesern des gedruckten Buches mittels der kostenlosen
Springer Nature „More Media“ App angesehen werden. Die App ist in den relevanten App-Stores
erhältlich und ermöglicht es, das entsprechend gekennzeichnete Zusatzmaterial mit einem mobilen
Endgerät zu öffnen.
ISBN 978-3-658-31193-3 ISBN 978-3-658-31194-0 (eBook)
https://doi.org/10.1007/978-3-658-31194-0
© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer Fachmedien Wiesbaden
GmbH, ein Teil von Springer Nature 2021
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht
ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung der Verlage.
Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die
Einspeicherung und Verarbeitung in elektronischen Systemen.
Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem
Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung
unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen
Zeicheninhabers sind zu beachten.
Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in
diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch
die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des
Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und
Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral.
V
Danksagung
Wir sind vielen Personen zu Dank verpflichtet, die uns inhaltlich und redaktionell mit
wertvollen Tipps und Anregungen begleitet haben. So hat Herr Claßen gerade in der
Entstehungsphase wichtige Impulse gesetzt. In besonderer Weise möchten wir uns bei
Frau Melina Schmitz bedanken, die uns im Endspurt mit großem Engagement bei der
Formatierung der Texte und Abbildungen sehr unterstützt hat.
Für Nicole Schelter wäre ohne Stephan Mielke das Buch nicht denkbar gewesen,
daher gebührt ihrem Ehemann besonderer Dank. Er war ihr stets ein treuer Sparrings-
partner und wertvoller Unterstützer.
VII
Inhaltsverzeichnis
1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Projektcharakterisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Klassifizierung von Projekten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Projektmanagement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.1 Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.2 Gegenstand des Projektmanagements. . . . . . . . . . . . . . . . . . . . . . . 8
1.3.3 Project Excellence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Aufteilung in Projektphasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.1 Projektmanagementphasen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.2 Projektlebenszyklus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5 Häufige Problemstellungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2 Klassische Grundlagen: Es geht los…. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 Projektstart. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1 Projektbeauftragung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.2 Projektziele. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.3 Projektumfeldanalyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.1.4 Stakeholderanalyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.1.5 Nutzwertanalyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.2 Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.3 Projektplanung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.3.1 Definitionsphase und Planungsphase. . . . . . . . . . . . . . . . . . . . . . . . 67
2.3.2 Aufgabenplanung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.3.3 Ablauf- und Terminplanung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.3.4 Ressourcenplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.3.5 Kostenplanung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.3.6 Risikoplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
IX
X Inhaltsverzeichnis
Stichwortverzeichnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Abkürzungsverzeichnis
AG Auftraggeber
AKV Aufgaben, Kompetenz, Verantwortung
AP Arbeitspaket
FAZ Frühester Anfangszeitpunkt
FEZ Frühester Endzeitpunkt
FP Freier Puffer
GL Geschäftsleitung
GP Gesamte Pufferzeit
HOAI Honorarordnung für Architekten und Ingenieure
MVP Minimal Viable Product
PSP Projektstrukturplan
QM Qualitätsmanagement
RFC Request for Comments
SAZ Spätester Anfangszeitpunkt
SEZ Spätester Endzeitpunkt
VKN Vorgangsknotennetzplan
XIII
Beispielverzeichnis
XV
XVI Beispielverzeichnis
Lernziele
Sie werden wissen, welche Eigenschaften ein Projekt vom Tagesgeschäft unter-
scheidet.
Sie können Projektmanagement definieren.
Sie kennen die fünf Projektmanagementphasen des IDPSA-Modells.
Sie können Projektmanagementphasen und Projektphasen unterscheiden.
Sie kennen die Gründe für die Nutzung von Projektmanagement.
1.1 Projektcharakterisierung
In der heutigen Zeit wird der Begriff des „Projektes“ sehr häufig verwendet. Daher stellt
sich zunächst die Frage, was ein Projekt auszeichnet, und was die einzelnen Definitions-
merkmale beinhalten. Viele Institutionen haben sich bereits mit dem Projektbegriff
beschäftigt, unter anderem das Project Management Institute und das Deutsche Institut
für Normung. Das Deutsche Institut für Normung (kurz DIN) definiert ein Projekt wie
folgt:
Projekt Nach der Definition der DIN 69901 [3] handelt es sich um ein Projekt,
wenn…
Termindruck
Viele Projekte sind mit strengen Terminvorgaben (siehe Abschn. 2.3.3) ausgestattet. Bei
Nichteinhaltung drohen oftmals hohe Konventionalstrafen.
Ungewissheit
Auch die Neuartigkeit des Projektproduktes ist in allen Definitionen Gegenstand. Die
neuartigen Aufgabenstellungen führen oft zu technisch und wirtschaftlich unberechen-
baren Einflüssen und im Vorfeld zu Unsicherheit.
Begrenzte Ressourcen
Die zur Verfügung stehenden Ressourcen, wie Zeit, Geld, Personal, Material, etc. sind
i. d. R. beschränkt.
Interdisziplinarität
Zur Durchführung der einzelnen Aufgabe innerhalb eines Projektes sind regelmäßig
unterschiedliche Fachgebiete involviert. Häufig wird daher die Projektgruppe
interdisziplinär gebildet.
Lange Zeithorizonte
Projekte weisen in vielen Fällen eine lange Projektdauer auf. Bis zur Finalisierung
können durchaus Jahre vergehen. Ein Beispiel ist die Elbphilharmonie mit einer Bauzeit
von insgesamt 10 Jahren [12].
1.1 Projektcharakterisierung 3
Unterschiedliche Interessenlagen
Verschiedene Stakeholder beeinflussen das Projekt. Diese sind im Rahmen des Projekt-
managements zu berücksichtigen (siehe Abschn. 2.1.3).
Komplexität
Vielschichtige Aufgaben, zu deren Bewältigung es ein gewisses Knowhow bedarf, sind
ebenfalls häufig Bestandteil eines Projektes.
Insgesamt sollen die zuvor genannten und für ein Projekt typischen Charakteristika in
dem folgenden Beispiel verdeutlicht werden.
Stadionausbau
Die Kapazität eines Stadions soll von derzeit 50.000 auf 75.000 Zuschauer erweitert
werden.
Lehrvideos
Eine Vertiefung und Erläuterung zum Projektbegriff finden Sie in den Videos Abb. 1.1
und 1.2 des Videokurses.
4 1 Einführung
Abb. 1.1 Einführung
Definitionen (https://doi.
org/10.1007/000-0qm)
Die Klassifizierung von Projekten hilft bei einer schnellen Entscheidung über das
technische Vorgehen und über den Umfang der zu nutzenden Projektmanagementaktivi-
täten. So wird ein „größeres“ und „bedeutenderes“ Projekt mit deutlich intensiveren
Controllingaktivitäten als ein „kleineres“ und „unbedeutendes“ Projekt begleitet. All-
gemein können Projekte nach den folgenden Kriterien klassifiziert werden:
• Projektdauer,
• Projektgröße und
• Projektart.
Projektdauer
Üblicherweise verlaufen Projekte zwischen wenigen Wochen und mehreren Jahren.
Projekte, die mit mehr als fünf Jahren geplant werden, sind in der betriebswirtschaft-
lichen Praxis nur selten vorzufinden. Bei Projekten kürzer als zwei Monaten ist oft eine
Person verantwortlich, die gleichzeitig die Hauptaufgaben erledigt und punktuell von
Kollegen oder anderen Abteilungen unterstützt wird.
Projektgröße
Die Größe eines Projektes kann entweder anhand:
• der Kosten bemessen werden, die für die Entwicklung des Projektes selbst entstehen
oder der Anzahl an Manntagen (als mengenmäßige Aufwandsgröße in Projekten) oder
• der Anzahl der in dem Projekt eingebundenen Personen.
1.2 Klassifizierung von Projekten 5
In der Praxis existieren kleine Projekte, in denen nur wenige Mitarbeiter eingebunden
sind, aber auch Großprojekte, in denen mehrere 100 Mitarbeiter involviert sind. Häufig
ist eine Klassifizierung der Projektgröße anhand der Anzahl der involvierten Mitarbeiter
schwierig, wie das Beispiel verdeutlicht. Das liegt bei Großprojekten insbesondere
daran, dass sowohl interne als auch externe Personen eingebunden sind und die Anzahl
der aktuellen Projektmitarbeiter von der Projektphase (siehe Abschn. 1.4) abhängig ist.
Ein Beispiel für ein länger andauerndes Projekt ist der Bau der BMW Welt in
München. Das Bauprojekt wurde im August 2003 gestartet und nach ca. vier Jahren
im Sommer 2007 abgeschlossen.
Neben den rund 100 direkten Projektmitarbeitern waren Spezialisten aus viel-
fältigen BMW Fachstellen dabei. Dazu kamen externe Dienstleister. Je nach Projekt-
phase schwankte die Anzahl der Beteiligten zudem stark. In der Planungsphase waren
zum Beispiel zweitweise allein über 1000 Planer einbezogen.
Unter dem QR-Code (Abb. 1.3) finden Sie ein Video mit weiteren Informationen zum
Bau der BMW Welt in München. ◄
Projektart
Es wird zudem zwischen inhaltlich unterschiedlichen Projektenarten unterschieden. In
der Praxis sind am häufigsten anzutreffen:
• Forschungsprojekte,
• Entwicklungsprojekte,
• Rationalisierungsprojekte,
• Projektierungsprojekte,
• Vertriebsprojekte,
• Betreuungsprojekte und
• Dienstleistungsprojekte.
weiteren hier vorgestellten Methoden neue Vorhaben Schritt für Schritt bearbeitbar,
unabhängig von den unterschiedlichen Projektthemen, von denen einige beispielhaft auf-
geführt sind:
Flughafen Berlin-Brandenburg
Die zwei QR-Codes (Abb. 1.4 und 1.5) behandeln das Thema Flughafen Berlin-
Brandenburg. Im Video hinter dem oberen QR-Code geht es um einen Rundgang
über den unfertigen Flughafen. Das andere Video geht auf Pleiten, Pech und Pannen
ein, welche durch den Bau des Flughafens entstanden sind. Der Flughafen Berlin-
Brandenburg ist ein Paradebeispiel für ein Großprojekt, bei dem bezüglich des
Projektmanagements einige falsche Entscheidungen getroffen wurden. ◄
1.2 Klassifizierung von Projekten 7
Abb. 1.6 Vertriebsprojekt
Systematische Klassifizierung
Die beschriebene Klassifizierung zwischen Projektdauer, Projektgröße und Projektart
kann mithilfe der Abb. 1.6 vorgenommen werden. Für ein Rationalisierungsprojekt ist
die Klassifizierung nachfolgend dargestellt.
Die Klassifizierung von Projekten ist hilfreich für die Ausarbeitung der Projekt-
phasen. Zum Beispiel kann ein Unternehmen durch die Zuordnung zur Projekt-
art „Rationalisierung“ die hierfür anzuwendenden Projektphasen (siehe Abschn. 1.4)
ableiten: Grobkonzept → Hauptstudie → Realisierung → Einführung → Abschluss. In
vielen Unternehmen ist dieser Projektlebenszyklus fest definiert und z. B. differenziert
nach Produktneuentwicklung oder Produktweiterentwicklung. In der Softwareent-
wicklung wurde aus diesem Grund frühzeitig das V-Modell entwickelt [1]. Die Projekt-
dauer kann zur Entscheidung darüber genutzt werden, welche Hilfsmittel eingesetzt
werden, bei einem mittelfristigen Projekt lohnt sich bspw. die Steuerung des Projektes
mit MS Project oder vergleichbarer Software. Dies wird auch durch die geringe Mit-
arbeiterzahl gestützt, die eine Einzelplatzversion ausreichend macht.
8 1 Einführung
1.3 Projektmanagement
1.3.1 Definition
Ein Blick in die Geschichte zeigt, das Managen von Projekten keineswegs eine neuartige
Disziplin darstellt. Bereits im 18. Jahrhundert äußerte sich Friedrich der Große in seinem
politischen Testament von 1752 zu den von ihm so bezeichneten „Projektemachern“ wie
folgt: „Es gibt eine Art von Lesern, Müßiggängern und Nichtstuern, die man Projekt-
macher nennt: vor deren schlechten Ratschlägen möge sich ein Herrscher sorglich in
Acht nehmen…“. Aber auch Daniel Defoe, englische Schriftsteller und Autor des welt-
bekannten Romans „Robinson Crusoes Leben und seltsame Abenteuer“, definierte
diesen Begriff schon früh: „Ein ehrenhafter Projektmacher ist jedoch der, welcher seine
Ideen nach den klaren und deutlichen Grundsätzen des gesunden Menschenverstanden,
der Ehrlichkeit und Klugheit in angemessener Weise ins Werk setzt…“ [6]. Es ist nahe-
liegend, dass die Definition von Defoe zu bevorzugen und als Leitlinie für seriöse
Projektleiter anzusehen ist.
Diese Aufgaben können auf alle Projektarten angewandt werden, es spielt dabei keine
Rolle, ob eine Software oder ein neues Auto entwickelt wird. Die Abfolge von Projekt-
tätigkeiten, die Vorgehensweise und das dazugehörige „Wording“ bleiben gleich. Diese
Aufgaben sind ebenfalls im agilen Projektmanagement wiederzufinden, wenn auch im
Detail unterschiedlich ausgestaltet. So versteht man im agilen Projektmanagement unter
„Führung der Projektgruppe“ nicht eine direktive Führung einer höheren Hierarchiestufe,
sondern eine „dienende Führung“ oder sogar ein selbstorganisiertes Team.
Die zurzeit angewandte Version des Project Excellence Modells konzentriert sich auf
die beiden Teilbereiche Ergebnisse und Realisierung. Die Realisierung auf der einen
Seite wird unter dem Begriff der Befähigung zusammengefasst. Auf der anderen Seite
kann methodisch alles wunderbar umgesetzt werden, wenn am Ende das Ergebnis nicht
passt, ist das Projekt nichtsdestotrotz ein Fehlschlag. Aus diesem Grund werden in
dem Modell nicht nur die Befähigerkriterien für die Gesamtbeurteilung herangezogen,
sondern als Ergänzung die Ergebniskriterien.
Beide Kriterienkategorien beeinflussen sich gegenseitig, so verdeutlicht der Kreis-
lauf im Project Excellence Modell, dass die Qualität der Ergebnisse ein Überdenken des
Projektmanagements nach sich ziehen sollte und diese umgekehrt die Ergebniskriterien
beeinflussen (Abb. 1.7).
Im Sinne einer konstruktiven Kritik kann die Beurteilung und Umsetzung bzgl. der
Befähigerkriterien für zukünftige Projekte zu einem qualitativ hochwertigeren Projekt-
management führen. So entsteht ein permanenter Verbesserungsprozess für das Projekt-
management im Unternehmen. Zu vergleichen ist dieser Prozess mit dem in Japan unter
dem Begriff „Kaizen“ bekanntem Prinzip der kontinuierlichen und kleinschrittigen Ver-
besserung.
Projektmanagement humorvoll
Der QR-Code (Abb. 1.8) zeigt ein Video, in dem Projektmanagement anschaulich und
lustig erklärt wird.
Abb. 1.8 Projektmanagement
humorvoll
Je umfangreicher ein Projekt ausfällt, desto sinnvoller ist es, dieses für eine bessere
Übersicht in seine einzelnen Phasen zu unterteilen. Dies gilt sowohl für die reinen
Projektmanagementaktivitäten als auch für die projektspezifischen Tätigkeiten.
1.4.1 Projektmanagementphasen
Ein in der Praxis weit verbreitetes Modell für die Gliederung von Projektmanagement-
phasen ist das IDPSA-Modell. Nach diesem Modell lassen sich die Prozesse innerhalb
eines Projektes in fünf unterschiedliche Phasen unterteilen. Die Bezeichnung „IDPSA“
ist ein Akronym der fünf wesentlichen Projektphasen. Diese werden im Folgenden am
Beispiel der Plattform AirlineCheckins.com konkretisiert:
Initialisierung
In der ersten Phase erfolgt die Konkretisierung einer Idee, für die noch kein Projekt
definiert wurde. Ziel ist ein genaueres und gemeinsames Verständnis des Projektzieles
und seiner Ergebnisse. Die Projektleitung und das Team müssen die Vorstellungen des
Auftraggebers so detailliert verstanden haben, dass darauf aufbauend eine konkrete
Planung erfolgen kann.
AirlineCheckins.com (1)
Die Lufthansa möchte die Kunden anderer Airlines gewinnen und zu diesem Zweck
ein für alle Airlines einheitliches Check-In-Portal anbieten. ◄
12 1 Einführung
Definition
Basierend auf den festgelegten Zielen werden Vorgehensweisen bzgl. Risiken, Verträgen,
Informationspolitik und ähnliches definiert und eine erste, sehr grobe Projektstruktur-
planung durchgeführt.
AirlineCheckins.com (2)
Planung
Das Projekt wird genauer geplant, d. h. es wird festgelegt und abgeschätzt, was zu tun
ist, welche Ressourcen eingesetzt werden müssen, wie hoch die Kosten sind, wie lange
das Projekt dauert und welche Termine einzuhalten sind.
Planungsphase DIN 69901 definiert die Planungsphase wie folgt: Gesamtheit der
Tätigkeiten und Prozesse zur formalen Planung eines Projektes. Hierzu zählen u. a. Vor-
gänge und Arbeitspakete planen, Kosten- und Finanzmittelplan erstellen, Risiken ana-
lysieren, Ressourcenplan erstellen usw. [3].
AirlineCheckins.com (3)
Projektstart soll Juni 2020 sein und im November 2021 sollen die ersten zahlenden
B2B-Partner angebunden sein. ◄
Steuerung
Im Rahmen der Projektsteuerung werden die Pläne abgearbeitet, es werden aufgelaufene
Arbeitsstunden, Kosten etc. festgestellt und mit den Plänen abgeglichen. Im Falle
inakzeptabler Abweichungen werden Steuerungsmaßnahmen geplant und eingeleitet.
In Abb. 1.9 sehen Sie den Projektmanagement Regelkreis. Es ist wichtig, diesen Kreis-
lauf anzuwenden, denn so kann das Projekt gesteuert und im Zweifelsfall entsprechende
Maßnahmen ergriffen werden. Der Regelkreis arbeitet mit Ist- und Sollabweichungen,
sodass erkennbar ist, wenn Abweichungen im Vergleich zu den Planzahlen vorliegen und
interveniert werden muss. Die Projektkontrolle erfolgt in kontinuierlichen Zeitintervallen
und führt langfristig zum erfolgreichen Projektabschluss.
1.4 Aufteilung in Projektphasen 13
Steuerungsphase Laut DIN 69901 wird die Steuerungsphase wie folgt definiert:
Gesamtheit der Tätigkeiten und Prozesse zur formalen Steuerung eines Projekts. Hierzu
zählen u. a. das Steuern von Terminen, Ressourcen, Kosten und Finanzmitteln, Risiken,
Qualität usw. [3].
Das Beispiel AirlineCheckins.com stellt dar, wie sich die nicht erreichte Zielgröße
„Anzahl der angebundenen Portale“ auf die weitere Planung des Projektes auswirken.
AirlineCheckins.com (4)
Viele anzubindende Airlines sind nur zu bestimmten Bedingungen bereit, sich dem
Portal anzuschließen, dies würde die Zielmarke der 90 %-Abdeckung gefährden. Aus
diesem Grund wird mit der Rechtsabteilung eine mit den Airlines zu schließende Ver-
einbarung erarbeitet und zusätzlich Zeit für die Verhandlungen eingeplant. ◄
Abschluss
Es erfolgt eine abschließende Betrachtung des Soll- und Ist-Verlaufes des Projektes,
Fehler werden analysiert und wiederverwertbare Ergebnisse gesichert.
14 1 Einführung
Abschlussphase DIN 69901 definiert die Abschlussphase wie folgt: Gesamtheit der
Tätigkeiten und Prozesse zur formalen Beendigung eines Projektes. Hierzu zählen u. a.
Erstellung des Projektabschlussberichts, Nachkalkulation, Erfahrungssicherung, Ver-
tragsbeendigung usw. [3].
AirlineCheckins.com (5)
Die fünf Phasen des „IDPSA-Modells“ finden sich im Projektlebenszyklus wieder und
beschreiben grundsätzlich die Tätigkeiten, die im Rahmen des Projektmanagements zu
erledigen sind. Mehr oder weniger detailliert, werden die IDPSA-Phasen daher in jedem
Projekt vorkommen und genutzt. Die Phasen können je nach Projekt unterschiedlich lang
sein (Abb. 1.10).
Pflichtenheft
Das Pflichtenheft beschreibt in konkreter Form, wie der Auftragnehmer die Anforderungen
des Auftraggebers zu lösen gedenkt – das sog. wie und womit. Der Auftraggeber
beschreibt vorher im Lastenheft möglichst präzise die Gesamtheit der Forderungen – was
er entwickelt oder produziert haben möchte. Erst wenn der Auftraggeber das Pflichtenheft
Lehrvideos
Eine Vertiefung und Erläuterung zu den Aspekten des Projektmanagements finden Sie in
den Videos Abb. 1.11, 1.12, 1.13 und 1.14 des Videokurses.
Abb. 1.11 Überblick
Projektmanagementphasen
(https://doi.org/10.1007/000-
0qk)
Abb. 1.12 Entwicklung
Projektmanagementphasen
(https://doi.org/10.1007/000-
0qh)
Abb. 1.13 Inhaltliche
Aspekte des
Projektmanagements (https://
doi.org/10.1007/000-0qn)
1.4.2 Projektlebenszyklus
Abb. 1.16 Projektphasen
nach dem V-Modell
Lösung entwickelt, teilweise auch mehrere, aus denen der beste Entwurf ausgewählt
wird. Je nach Komplexität des Projektes existieren einzeln testbare Module, die im
Anschluss als Ganzes getestet und ggf. angepasst werden müssen, bevor es zum Rollout
kommt und die Software den Nutzern zur Verfügung gestellt wird.
In der Praxis existiert eine Vielzahl an unterschiedlichen Ursachen dafür, dass ein
Projekt nicht erfolgreich verläuft. Dabei sind die häufigsten Ursachen eine schlechte
Kommunikation sowie unklare Anforderungen und Ziele. In Abb. 1.17 sehen Sie die
Gründe, die zumeist zum Scheitern eines Projektes geführt haben. Ebenfalls existieren
Wechselwirkungen zwischen den Ursachen.
18 1 Einführung
Abb. 1.17 Unklare Anforderungen und Ziele als Ursache für das Verfehlen der Projektziele [6]
Wie sich ein solcher Mangel an effizienter Kommunikation und Gruppendruck in der
Praxis auf ein Projekt auswirken kann, zeigt das Beispiel der Challenger-Katastrophe.
Challenger Katastrophe
Die Challenger Katastrophe am 28. Januar 1986 ist laut dem Nobelpreisträger
Richard Feynman an schlechter Kommunikation gescheitert, insbesondere durch den
Gruppendruck und die autoritäre Entscheidungsfindung. Technisch war das Versagen
eines Dichtungsringes verantwortlich, jedoch wurde genau dieses Risiko im Vorfeld
angesprochen. Seitens des Managements der NASA wurde mit Verweis auf früheres
problemloses Funktionieren und dem am nächsten Tag geplanten und veröffentlichten
Start Druck ausgeübt, der zur geplanten Durchführung des Starts und zu den bekannten
Konsequenzen geführt hat. Feynman war in der Untersuchungskommission des
Unglücks und konnte seine Erkenntnisse nur gegen Widerstände veröffentlichen [5]. ◄
1.5 Häufige Problemstellungen 19
Eine weitere Ursache für das Scheitern von Projekten kann eine unzureichende Planung
sein. Das verdeutlicht auch das nachfolgende Beispiel zum erstmaligen Versuch zum
Erbau des Panamakanals, dass zusätzlich die Bedeutung des Risikomanagements unter-
streicht.
Panamakanal
Lehrvideos
Eine Vertiefung mit Gründen für das Scheitern von Projekten finden Sie im Video
Abb. 1.19 des Videokurses.
Kontrollfragen
1. Welche acht Eigenschaften sind bei Projekten oft feststellbar?
2. Definieren Sie Projektmanagement.
3. Nennen und erläutern Sie die fünf Projektmanagementphasen anhand des IDPSA-
Modells.
4. Was ist der Unterschied zwischen Projektmanagementphasen und Projektphasen?
5. Wofür wird Projektmanagement gebraucht?
Literatur
2.1 Projektstart
Lernziele
Sie wissen, was SMART bedeutet.
Sie kennen die fünf Funktionen von Projektzielen.
Sie können die Rolle von Stakeholdern in Projekten beurteilen.
Sie kennen die vier Phasen einer Projektumfeldanalyse.
Sie können die Erkenntnisse der Projektumfeldanalyse nutzen.
Sie sind in der Lage, eine Nutzwertanalyse anwenden zu können.
2.1.1 Projektbeauftragung
Der Projektauftrag des Vorhabens stellt die Grundlage eines Projektes dar. Er ist als
eine Art initiale „Beschreibung des Projekts“ anzusehen und zielt darauf ab, die nach-
folgenden Aspekte zu erfüllen [14]:
• Definition dessen, was zum Projekt gehört (Ausgrenzung dessen, was nicht Inhalt des
Projekts ist),
• dass das Projektteam zweifelsfrei versteht, was das Projekt leisten soll,
• worauf besonders Wert gelegt wird und
• was nicht Gegenstand des Projektes ist (Abb. 2.1).
Im Verlauf der Jahre haben sich einige Hinweise ergeben, die bei der Vorgehensweise
nur mittelbar berücksichtigt wurden, jedoch bei einer aussagekräftigen Beauftragung
dennoch Einklang finden sollten:
• Es sollten nicht nur die Ziele definiert werden, die auch erreicht werden sollen,
sondern auch die „Nicht-Ziele“, um diese bewusst auszugrenzen.
Abb. 2.1 Projektbeauftragung
2.1 Projektstart 25
Das nachfolgende Beispiel soll einen Überblick darüber geben, wie der Projektauftrag
eines Projektes aussehen kann. Dabei ist zu beachten, dass es trotz der Ansätze, eine
standardisierte Beauftragung zu gestalten, keine allgemeingültige Projektbeauftragung
gibt. Das hängt vor allem mit der Vielzahl an Projektarten zusammen, die jedem Projekt
seine Individualität verschafft (Tab. 2.1).
Lehrvideos
Eine Vertiefung und Erläuterung zum Projektstart finden Sie in den Videos Abb. 2.2, 2.3
und 2.4 des Videokurses.
Tab. 2.1 Beispiel Projektbeauftragung
Beispiel Durchführung eines Hilfsprojektes im Ausland durch das Hammer Forum
e. V.
Projektnummer 1
Projektbezeichnung Aufbau eines Gesundheitszentrums im Kongo
Auftraggeber Hammer Forum e. V.
Projektleiter Max Mustermann
Mitglieder des Karl Müller
Projektteams Julia Schneider
Projektanstoß kein aktuelles Auslandsprojekt
Projektziele Beendigung des Projektes spätestens am 05.03.20 mit einem Finanzmittel-
einsatz von max. 1,5 Mio. €
Mit den vorhandenen Ressourcen sollen nach der Beendigung des Projekts
pro Tag mind. 50 Bedürftige behandelt werden
Termine
18. März 2019 1. Meilenstein Konzeption beendet
21. März 2019 2. Meilenstein Bauplanung beendet
2. Februar 2020 13. Meilenstein Bau beendet
27. Februar 2020 14. Meilenstein Übergabe des Kontrollkatalogs an den Verein
Gesamtaufwand 12 Projektmonate
Budget 1.500.000 €
26 2 Klassische Grundlagen: Es geht los…
Abb. 2.2 Einführung in
den Projektstart (https://doi.
org/10.1007/000-0s2)
2.1.2 Projektziele
Jedes Projekt ist vor Beginn mit genauen Zielformulierungen zu versehen. Ziele dienen
dem Projektleiter als Handlungsgrundlage und sind wesentlicher Ausgangspunkt für
weitere Planungen in Bezug auf das Projekt.
Die Ziele sollen der sog. „SMART-Regel“ entsprechen. Dieses Akronym steht für ins-
gesamt fünf Anforderungen an die Zielformulierung. Diese sind (Abb. 2.5):
Die SMART-Ziele sollten bei einem erfolgreichen Projekt immer eingehalten werden.
Sie dienen als unterstützende Maßnahmen, damit in einem Projekt kontinuierlich gute
und unterstützende Ziele formuliert werden.
Festivalplanung
Ziel: Die Veranstalter eines Festivals haben das Ziel gemeinsam gesetzt, die Ver-
anstaltung vom 4. bis zum 6. August mit 40.000 Besuchern in Köln auszutragen.
Wurde die SMART-Regel beachtet?
2.1 Projektstart 27
• spezifisch: Das Festival ist in der Zielsetzung konkret genannt und beschrieben.
Das Event und die Örtlichkeit sind fixiert.
• messbar: Die Zielerreichung lässt sich anhand der erwünschten Besucherzahlen
messen.
• akzeptiert: Das Ziel wurde transparent formuliert.
• realistisch: Aufgrund der Tatsache, dass das Festival bereits oft ausgerichtet
wurde, ist das Vorhaben als umsetzbar anzusehen.
• terminiert: Das Ziel sieht vor, dass das Festival im Zeitraum vom 4. bis zum 6.
August stattfinden soll.
• Ergebnis: Das o. g. von den Veranstaltern formulierte Ziel erfüllt die
Anforderungen der SMART-Regel. ◄
Das Ziel des Projektes ist schriftlich im Projektauftrag zu fixieren. Dies liegt im Ver-
antwortungsbereich des Projektleiters. Mithilfe der Zielformulierung ist es nach Abschluss
des Projektes möglich, den Grad der Zielerreichung zu messen. Ferner ist ein anspruchs-
volles Niveau des Ziels zu wählen, da dies motivierend wirkt und damit eine effiziente
Bearbeitung erreicht wird. Gleichzeitig muss das Ziel für das Projektteam in der vor-
gegebenen Zeit realisierbar sein. Als weiteres Kriterium an das Projektziel ist die Über-
prüfbarkeit am Ende des Projektes zu nennen. Auf diese Weise wird sichergestellt, dass
28 2 Klassische Grundlagen: Es geht los…
für die Beurteilung des Projekterfolges keine weiteren Faktoren außer der Leistung des
Projektes herangezogen werden. Wird bspw. ein Projekt zur Produktentwicklung mit dem
Ziel durchgeführt, den Umsatz zu steigern, so ist nicht nur das neu entwickelte Produkt
für die Umsatzsteigerung ausschlaggebend, sondern ebenfalls das gewählte Preisniveau,
begleitende Marketingmaßnahmen etc., die ggf. in weiteren Projekten behandelt wurden
(siehe auch Zielsysteme), oder im Rahmen des Tagesgeschäftes bearbeitet werden.
Wissen, welches man über das Projekt angesammelt hat. Man sollte alle Anforderungen
nach Möglichkeit immer im Anfangszeitraum eines Projektes genau ermitteln und
dokumentieren, um die Kosten des Projektes zuverlässig zu ermitteln und das Änderungs-
management konfliktfrei durchführen zu können. Dies ist ein großer Unterschied zum
agilen Projektmanagement, in dem explizit eine Weiterentwicklung der Anforderungen
durch die Bevorzugung des Reagierens auf Veränderung vorgesehen ist (siehe Abschn. 3.2).
Erwartungen des
Erwartung des Auftraggebers
Bauprojektleiters
an den Bauprojektleiter
an den Auftraggeber
Maßnahmen
• Gutes Arbeitsklima herstellen und pflegen
• Ständige Kommunikation miteinander
• Intensive Einbindung in das Geschehen pflegen, um Identifikation mit dem
Projekt zu erreichen
• Gegenseitiges Verständnis und Einfühlungsvermögen fördern
Zielsystem
Die Ziele im Zielsystem sollten präzise und SMART formuliert werden. Es gibt die ver-
schiedensten Arten von Zielen, die alle dazu beitragen, dass das Projektziel erreicht wird.
Bei großen Projekten sollte man die Ziele hierarchisch strukturieren, damit man diese
schrittweise und systematisch abarbeiten kann. In Abb. 2.8 ist ein Beispiel für ein Ziel-
system dargestellt.
Es wird differenziert nach:
• hierarchischen Einordnungen:
– Oberziele (leiten sich aus der Unternehmensstrategie oder übergeordneten
Projekten ab) und
– Unterziele (dem Oberziel untergeordnet).
• inhaltlichen Einordnungen:
– Kostenziele (bezogen auf die monetäre Einhaltung des Budgets),
– Terminziele (bezogen auf die zeitliche Einhaltung der Meilensteintermine) und
– Qualitätsziele (bezogen auf die qualitativen Ziele während des Projektverlaufs).
Zielkonflikte
Die oben genannten Ziele lassen sich im sog. „magischen Dreieck“ zusammenfassen,
dass sich aus den nachfolgenden drei Komponenten zusammensetzt:
2.1 Projektstart 31
Zentralisierung der
Bereitstellung eines
CMS zur dezentralen
Z
> Unter- eigenständigen
ziele Internetauftritte in
Pflege der Inhalte
durch die einzelnen
i
einem Webportal
Filialen
e
l
>
Kosten-
Vorgegebenes Budget von maximal
220.000 EUR
e
ziel
>
Termin - Umsetzung bis spätestens 26.05.2020
ziel
• Leistung
• Zeit und
• Kosten.
Projekt „Herzroute“
Bei dem Projekt „Herzroute“ handelt es sich um eine geplante Spezialstrecke für
E-Bike Touren vom Genfer- zum Bodensee. Ein besonderes Augenmerk liegt für
die Verantwortlichen darauf, die ca. 120 km lange Strecke qualitativ hochwertig zu
errichten.1 ◄
Flexible Electronics
1https://herzroute.ch/de/entdecken/die-herzroute/geschichte.html [04.08.2019].
2.1 Projektstart 33
Die „Magie“ dieser Darstellungsform besteht darin, dass sich die Teilziele gegenseitig
beeinflussen und sich damit mindestens eine der anderen Größen verändert, sobald eine
Veränderung an einem der drei Parameter vorgenommen wird. Meist besteht ein Ziel-
konflikt, der eine Priorisierung der Ziele erforderlich macht.
T-Shirt-Produktion
Ein Produzent von T-Shirts hat im Rahmen eines Projektes eine neue Produktions-
stätte im osteuropäischen Ausland errichtet, um dort T-Shirts fertigen zu lassen. Ziel
war es zunächst die gesamten Produktionskosten gering zu halten. Dies führte dazu,
dass nur qualitativ minderwertige Maschinen für die T-Shirt-Produktion angeschafft
werden konnten, die hohe Ausfallraten mit sich brachten. Im weiteren Verlauf wurde
daher beschlossen, die Qualität zu verbessern. Hierdurch stiegen die Kosten an und
das für das Projekt bewilligte Budget musste erhöht werden. Außerdem verlängerte
sich die ursprünglich veranschlagte Projektdauer. ◄
Lehrvideos
Eine Vertiefung und Erläuterung zu Projektzielen finden Sie in den Videos
Abb. 2.10, 2.11, 2.12 und 2.13 des Videokurses.
Abb. 2.10 Einführung
Projektziele (https://doi.
org/10.1007/000-0qv)
Abb. 2.13 Eigenschaften
guter Ziele (https://doi.
org/10.1007/000-0qy)
2.1.3 Projektumfeldanalyse
Der Erfolg eines Projektes hängt nicht ausschließlich von der Umsetzung des Projektes
selbst ab. Jedes Projekt ist von einem Umfeld umgeben und zugleich mit dessen Ein-
flüssen konfrontiert. Diese Einflüsse können den Projekterfolg mittelbar oder unmittel-
bar beeinflussen. Aus diesem Grund ist es von hoher Bedeutung, im Vorfeld das Umfeld
genau zu analysieren. Dies geschieht im Rahmen der sog. „Projektumfeldanalyse“.
Tab. 2.2 Projektumfelddimensionen
Intern Extern
Sachlich-inhaltlich Betriebsvereinbarung Gesetze
PM-Handbuch Normen und Standards
Richtlinien Request for Comments (RFC)
Umsatzentwicklung Marktentwicklung
Organisatorisch-sozial Betriebsrat Auftraggeber (AG)
Beauftragte (z. B. QM, Sicherheit) Mitarbeiter der AG-
Vorstand, Abteilungsleiter Organisation
Mitarbeiter (außerhalb des Projektes) Lieferanten
Kunden
Vorgehensschritte:
Kundenrating
Bei der Finanzierung eines Projektvorhabens muss häufig auf Fremdkapital zurück-
gegriffen werden. Der Zinssatz der Hausbank für die Fremdkapitalaufnahme kann
ggf. durch das individuelle Rating des Kreditnehmers und damit die Schätzung der
Kreditausfallwahrscheinlichkeit gesenkt werden. Dies kann einen positiven Effekt auf
das Projektergebnis darstellen. Das Kundenrating der Banken stellt eine abgewandelte
Form der klassischen Umfeldanalyse dar. Es handelt sich dabei um einen sachlich-
inhaltlichen Einfluss auf das Projekt. ◄
Eine weitere Abgrenzung der etwaigen Einflussmöglichkeiten der Stakeholder auf das
Projekt erfolgt anhand der Differenzierung von:
Es gilt zu beachten, dass die Einflussgrößen sich sowohl negativ als auch positiv auf
den Projekterfolg auswirken können. Dies gilt ebenso für Risiken und Stakeholder
(siehe Abschn. 2.1.4). Die Projektumfeldanalyse ist jedoch nicht mit einer Risiko-
analyse gleichzusetzen, da Risiken nicht notwendigerweise eintreten müssen, die Ein-
flussfaktoren aber in jedem Fall vorhanden sind. In Abgrenzung zur Stakeholderanalyse
werden in der Projektumfeldanalyse die Stakeholder lediglich identifiziert und in der
Stakeholderanalyse weiter analysiert, um ggf. Maßnahmen abzuleiten.
Nachfolgend sollen ein paar hilfreiche Tipps zur Verfügung gestellt werden, die sich
bei der Erstellung einer Projektumfeldanalyse in der Praxis bewährt haben:
• Setzen Sie die Projektumfeldanalyse (als Denkmodell) auch außerhalb von Projekten,
z. B. in persönlichen Arbeitssituationen ein. Sie ist ein gutes Hilfsmittel zur Vor-
bereitung von wichtigen Besprechungen und Verhandlungen. Wer schon vor einer
Verhandlung gut über die Erwartungen und Befürchtungen seines Gegenübers
Bescheid weiß, kann sich präventiv Argumente und passende Antworten zurechtlegen.
• Fügen Sie die aus der Projektumfeldanalyse resultierenden wesentlichen Maßnahmen
als zu erledigende Arbeitspakete in den Projektstrukturplan ein.
• Die Umfeldanalyse trägt zur Bewusstmachung des Projekts bei. Durch die Definition
des Umfeldes wird das „System Projekt“ klarer definiert [14].
Die Umfeldanalyse verläuft in insgesamt vier Phasen, die in Abb. 2.14 dargestellt sind.
Zunächst sind alle Einflussgrößen zu identifizieren, die auf jegliche Art und Weise auf
das Projekt wirken können. Anschließend sind die Einflussgrößen in Hinblick auf
ihre möglichen Folgen auf das Projekt zu bewerten. Im dritten Schritt sind konkrete
Strategien und Maßnahmen abzuleiten und zu planen. Abschließend muss regelmäßig im
Projektverlauf darauf geachtet werden, ob sich im Vergleich zur letzten Umfeldanalyse
Änderungen ergeben haben.
2.1.4 Stakeholderanalyse
Während die Projektumfeldanalyse sich mit der Identifikation der Stakeholder befasst,
werden sie in der Stakeholderanalyse in Hinblick auf ihre Bedeutung untersucht und
Maßnahmen zur Förderung oder Reduzierung des Einflusses gesucht und implementiert.
Das ist notwendig, da es für ein rundum erfolgreiches Projekt neben einem fachlich
hochwertigen Ergebnis einer gewissen allgemeinen Akzeptanz im Projektumfeld bedarf.
Bleibt diese aus, so gerät auch ein fachlich gelungenes Projekt in der Praxis häufig
Beobachtung
Identifizierung und Steuerung
Analyse der
aller Ableitung von von
Einflussgrößen
Einflussgrößen Maßnahmen Einflussgrößen
und Stakeholder
und Stakeholder und
Stakeholdern
schnell in Vergessenheit. Die Stakeholder bilden daher wichtige Größen, die auf den
Erfolg eines Projektes bedeutenden Einfluss nehmen können. Daher werden sie hier aus-
führlicher betrachtet.
Stakeholder Bei Stakeholdern handelt es sich um alle internen und externen Personen
oder Personengruppen, die an der Projektdurchführung oder den Projektergebnissen
beteiligt oder interessiert oder die davon betroffen sind.
verzichtet werden, wie es bei dem Betriebssystem Windows 7 der Fall war [12]. Auf
das gesamte System wirkt der Staat von außen ein, da möglicherweise Nutzungsein-
schränkungen betroffen sein können, wie im Zuge der 5G-Technologie für Huawei dis-
kutiert [4], oder Datenschutzbestimmungen eingehalten werden müssen. Indirekten
Einfluss üben die Kunden durch ihre Vorstellungen über den Service in einer Filiale aus,
40 2 Klassische Grundlagen: Es geht los…
diese Vorstellungen können durch Angebote von Mitbewerbern ausgelöst worden sein, die
damit ebenfalls Gegenstand einer Umfeldanalyse werden können. Für einen erfolgreichen
Projektabschluss sind alle diese Faktoren zu berücksichtigen.
Es ist wichtig, die Stakeholder vorher zu ermitteln, um sie in das Projekt einzu-
beziehen. Bei der Ermittlung der Stakeholdergruppen ist es daher von großer Bedeutung,
diese möglichst vollständig zu erfassen. Eine systematische Vorgehensweise kann dazu
eine wichtige Hilfestellung sein. Mögliche Herangehensweisen zur Identifizierung aller
Stakeholder sind:
• Brainstorming,
• Befragung des Projektteams sowie weitere in das Projekt involvierte Mitarbeiter,
• Expertenbefragung und
• Prüfung von Checklisten aus früheren Projekten.
Bei der Befragung von Experten sollte sowohl auf mit allgemeinen Projektmanagement
spezialisierte Personen zurückgegriffen werden als auch auf mit dem Inhalt des Projektes
erfahrene Personen.
Durch die Festlegung der Strategie auf Ebene der Quadranten wird eine gewisse
Flexibilität für den Fall gewahrt, dass sich im weiteren Verlauf Änderungen ergeben.
Dadurch können Stakeholder in der Matrixdarstellung nachträglich ergänzt und die
jeweils für diesen Quadranten angegebene Strategie zielgerichtet durch konkrete
Maßnahmen ausgestaltet werden.
Bei Stakeholdern, die keine besonders ausgeprägte negative oder positive Einstellung
zu dem Projekt haben und keinen bis mäßigen Einfluss nehmen können, genügt eine
kurze Recherche, um die Bewertung des Stakeholders und dessen Einordnung in die
Quadranten zu bestätigen und regelmäßig zu überprüfen.
Zusätzlich kann bei Stakeholdern, die eine negative Einstellung zu dem Projekt
pflegen und keinen bis mäßigen Einfluss nehmen können, der Informationsfluss aufrecht-
erhalten werden, um die Einstellung nach Möglichkeit ins Positive zu wandeln. Ähnlich
verhält es sich bei Stakeholdern mit einer positiven Einstellung zum Projekt und einem
ebenfalls beschränkten Einflusshorizont. Hier ist auf den Erhalt der positiven Einstellung
2.1 Projektstart 43
Zufrieden- Aufmerksam
stellen managen
Einfluss
Im Auge
Informieren
behalten
Interesse
Abb. 2.17 Stakeholderbewertung
zu achten. Eine weitere Strategie ist die Stärkung der Einflussmöglichkeiten positiv
eingestellter Stakeholder, die auf diese Weise das Projekt stärker unterstützen können
(Abb. 2.18).
Bei Stakeholdern mit stärkeren Einflussmöglichkeiten bedarf es einer intensiveren
Berücksichtigung und eine entsprechend sorgfältigere Planung der Maßnahmen. Pflegen
diese Stakeholder ein intensives Interesse an dem Projekt, empfiehlt es sich im Rahmen
der Diskussionsstrategie einen Dialog zu führen und Möglichkeiten der Einbindung
zu prüfen. Eine weitere Möglichkeit besteht darin, den Projektumfang entsprechend
der Anforderungen der Stakeholder zu verändern, und die skeptischen Stakeholder auf
diese Weise von den Vorteilen des Projektes zu überzeugen. So ist die multimediale
Ausstellung lediglich wegen der Stakeholder eingerichtet worden und gehört nicht zum
Kern-Projektumfang.
Stuttgart 21 (1)
Im Rahmen des Projektes Stuttgart 21 wurde im Hauptbahnhof am 16. Juni 1998 das
Informationszentrum Turmforum zu Stuttgart 21 und der Neubaustrecke Wendlingen–
Ulm eröffnet. Die multimediale Ausstellung führt im Bahnhofsturm über vier Etagen
und wirbt für das Gesamtprojekt und die damit verbundenen städtebaulichen Ent-
wicklungsmöglichkeiten [1]. ◄
44 2 Klassische Grundlagen: Es geht los…
Stuttgart 21 (2)
Nach langjährigen Planungen von Stuttgart 21, die bereits 1970 starteten, wurde
die Machbarkeitsstudie des Projektes bereits im Januar 1995 vorgestellt. Es gingen
13.700 Einwendungen gegen das Projekt ein, die teilweise berücksichtigt wurden und
im Raumordnungsverfahren im September 1997 final einflossen.
Die seit der offiziellen Entscheidung für die Umsetzung des Projekts teil-
nehmenden Demonstranten lösten keinerlei Änderungen in den Planungen aus,
auch sonst sind keinerlei Maßnahmen bekannt, die darauf eingingen. Es ist davon
2.1 Projektstart 45
Am Beispiel von Stuttgart 21 wird deutlich, dass die gewählten Maßnahmen keine
Garantie für den Erfolg sind und dass die Einschätzung der Stakeholder sich im Ver-
laufe des Projektes stark verändern kann. Dies ist in Abb. 2.19 dargestellt, das gleich-
zeitig deutlich macht, wie mit der unterschiedlichen Positionierung in der Matrix die
Maßnahmen geändert werden müssen.
Lehrvideos
Eine Vertiefung und Erläuterung zum Stakeholdermanagement finden Sie in den Videos
Abb. 2.20, 2.21 und 2.22 des Videokurses.
Abb. 2.19 Entwicklung
der Stakeholder im Projekt
Stuttgart 21
Zufrieden- Aufmerksam
stellen managen
Einfluss
Im Auge
Informieren
behalten
Interesse
46 2 Klassische Grundlagen: Es geht los…
Abb. 2.20 Einführung in
das Stakeholdermanagement
(https://doi.org/10.1007/000-
0qz)
Abb. 2.21 Identifizierung
und Analyse der
Stakeholder (https://doi.
org/10.1007/000-0r0)
2.1.5 Nutzwertanalyse
Zielbe-
stimmung
Polaritäts-
und Vorauswahl Ziele Entscheidungs
profil
Auswahl treffen gewichten findung
erstellen
der Mess-
kriterien
Vorauswahl treffen
Eine Vorauswahl ist kein zwingender Bestandteil einer Nutzwertanalyse, kann jedoch
dazu führen, dass im weiteren Verlauf die Anzahl der Alternativen verringert und damit
48 2 Klassische Grundlagen: Es geht los…
der Umfang der Analyse geschmälert wird. Grundsätzlich ist eine Vorauswahl vor allem
dann sinnvoll, je mehr Alternativen zur Auswahl stehen.
Sie kann insgesamt auf drei Arten erfolgen:
Ziele gewichten
Bei der Gewichtung der Ziele gilt es herauszufinden, welche Bedeutung sie für den Gesamt-
nutzen haben. Diese ist jeweils von den individuellen Präferenzen des Entscheidungsträgers
abhängig. Um sie zu quantifizieren bieten sich verschiedene Zielgewichtungsverfahren an.
Ein sehr gängiges Verfahren ist der sog. „Paarvergleich“. Dabei werden die Ziele dem Ent-
scheidungsträger jeweils paarweise gegenübergestellt und verglichen, welche der beiden
für ihn die höhere Bedeutung hat. Daraus werden anschließend die Zielgewichte ermittelt,
indem jeweils die relativen Anteile der Anzahl an höheren Bedeutungen im Paarvergleich in
Bezug auf die Gesamtanzahl der Paarvergleiche ermittelt werden (Abb. 2.24).
a Gute Allgemeinbildung
b Angemessene Sozialkompetenz a
b a
c Eifrige Lernbereitschaft d
d Verbleib im Unternehmen
Beispiel a b c d
Absolute
3 1 1 1
Summe
Relative
3/6 = 0,5 1/6 = 0,166 1/6 = 0,166 1/6 = 0,166
Summe
Polaritätsprofil erstellen
Ein Polaritätsprofil dient dazu, die unterschiedlichen Zielerreichungsgrade der Hand-
lungsalternativen grafisch darzustellen. Auch für eine Vorauswahl definierte Restriktionen
und Anspruchsniveaus können in dieser Darstellungsform (siehe Abb. 2.25) abgebildet
werden. Ebenfalls kann die Vorauswahl anhand dieser Darstellung erfolgen.
Insbesondere für eine Vergleichbarkeit der Abbildungen ist die Darstellung der
Skalen einheitlich zu gestalten. Andernfalls sieht man sich schnell mit dem Vorwurf
konfrontiert, die Aussage der Grafik verfälschen zu wollen.
Entscheidungsfindung
Zum Abschluss der Analyse wird der Gesamtnutzen jeder Alternative errechnet und sich
auf dieser Basis für die Alternative entschieden, die den höchsten Wert annimmt. Dazu
werden jeweils die Zielerreichungsgrade mit der zuvor für das jeweilige Ziel ermittelten
Gewichtung multipliziert und jeweils sämtliche Produkte der Zielerreichungsgrade einer
Handlungsalternative summiert (siehe Tab. 2.4).
Tab. 2.4 Nutzwertanalyse
Ziel Gewichtung Aus- Nutzwert Aus- Nutzwert Aus- Nutzwert
prägung Müller prägung Schmitz prägung Meier
Müller Schmitz Meier
Gute All- 0,5 6 3 8 4 10 5
gemein-
bildung
Hohe 0,166 8 1,33 9 1,49 5 0,83
Sozial-
kompetenz
Gute Lern- 0,166 7 1,16 4 0,66 8 1,33
bereitschaft
Verbleib 0,166 10 1,66 10 1,66 10 1,66
im Unter-
nehmen
nach
Beendigung
Summe 7,15 7,81 8,82
Kontrollfragen
1. Erläutern Sie die SMART-Regel.
2. Nennen Sie die fünf Funktionen von Projektzielen.
3. Welche Rolle spielen Stakeholder in Projekten?
4. Nennen Sie die vier Phasen einer Projektumfeldanalyse.
5. Wofür werden die Erkenntnisse der Projektumfeldanalyse genutzt?
6. Worin unterscheiden sich die Skalenniveaus bei der Zielbestimmung einer Nutzwert-
analyse?
2.2 Projektorganisation 51
2.2 Projektorganisation
Lernziele
Sie wissen, welche Funktionen ein Projektkoordinator in einer Stabsprojekt-
organisation übernimmt.
Sie kennen die verschiedenen Projektorganisationsformen.
Sie können anhand der Vorteile der verschiedenen Projektorganisationen eine
Empfehlung für Ihr Projekt abgeben.
Sie kennen die bedeutendsten Rollen in einem Projekt.
Sie wissen, was man unter dem AKV-Prinzip versteht.
Projektexterne Aufbauorganisation
Die Organisationsform beschreibt die organisatorische Eingliederung des Projektes in
die Organisationsstruktur des ausführenden Unternehmens. Grundsätzlich wird dabei
zwischen drei unterschiedlichen Organisationsformen unterschieden:
• Stabsprojektorganisation,
• Reine Projektorganisation und
• Matrix-Projektorganisation.
a) Stabsprojektorganisation
In Abb. 2.26 werden die Beziehungen zwischen den einzelnen Akteuren der Stab-
organisation sowie die Befugnisse des Projektleiters dargestellt. Geht man von einer ver-
einfacht dargestellten Aufbauorganisation eines Unternehmens aus, sind die einzelnen
Fachabteilungen der Geschäftsführung untergeordnet. Die Projektleitung kann als Stabs-
organisation direkt der Geschäftsleitung unterstellt sein, oder ist selbst Mitarbeiter einer
Fachabteilung. Gerade Letzteres ist eine herausfordernde Konstellation für die Projekt-
leitung, da damit geringere Einflussmöglichkeiten und oft Konflikte mit den Interessen
der eigenen Abteilung verbunden sind. Liegen Aufgaben für das Projekt an, so werden
diese an die entsprechenden Führungskräfte der Fachabteilung herangetragen, dargestellt
mit gestrichelten Linien. Im Anschluss tragen sie für die Umsetzung in ihrem Bereich
Sorge. Die Umsetzung hängt folglich von den weiteren Tätigkeiten ab, die in einem
Bereich anliegen und über die Prioritäten entscheidet der jeweiligen Führungskräfte. Ent-
sprechend gering sind die Befugnisse der Projektleitung in der Stabsprojektorganisation.
Der Projektleiter (häufig nur als Projektkoordinator bezeichnet):
GL
GL: Geschäftsleitung
P-Koord.: Projektkoordination
FA: Fachabteilung
keine alleinige
Abb. 2.26 Stabsprojektorganisation
2.2 Projektorganisation 53
b) Reine Projektorganisation
Das wesentliche Merkmal einer reinen Projektorganisation (manchmal auch autonome
Projektorganisation genannt) ist die hohe Befugnis des Projektleiters. Die Mitarbeiter
aus den verschiedenen Fachabteilungen sind dem Projekt für einen bestimmten Zeitraum
fest zugeordnet und gehen keinen anderweitigen Tätigkeiten nach. Der Projektleiter hat
gegenüber den Teammitgliedern sowohl disziplinarische als auch fachliche Weisungs-
befugnis (Abb. 2.27). Die Vorteile dieser Organisationsform sind:
c) Matrix-Projektorganisation
Die Organisation eines Projektes in Form einer Matrixstruktur ist in der Praxis auf-
grund der Vielfältigkeit der Projekte und einem entsprechend vielfältigen Personalbedarf
eine geläufige Methode. Bei dieser Art der Projektorganisation wird hinsichtlich der
Zuständigkeiten unterschieden zwischen:
Abb. 2.28 Matrix-Projektorganisation
Projektinterne Aufbauorganisation
Die projektinterne Aufbauorganisation beschreibt die hierarchische Eingliederung
der Projektteilnehmer in das gesamte Projektteam. Weiterhin werden die Rahmen-
bedingungen, Aufgaben, Kompetenzen und Verantwortlichkeiten festgelegt. Die interne
Aufbauorganisation wird beeinflusst von
Abb. 2.29 zeigt das Verhältnis der Akteure zueinander. Im Zentrum steht die Projekt-
leitung, die zum einen die Arbeiten für das Projekt im Projektteam koordiniert, auf der
anderen Seite dem Auftraggeber/Lenkungsausschuss berichtet und Entscheidungen
herbeiführt. Je nach Größe des Projektes und je nach Entscheidungsbedarf sind weitere
beteiligte Stellen in Entscheidungen einzubinden und in Form eines Lenkungsaus-
schusses zu organisieren. Entsprechend sind die bedeutendsten Rollen in einem Projekt:
Lenkungsausschuss
Dieser in der Praxis alternativ als Steuerungsgremium bezeichnete Ausschuss wird für die
Dauer des Projektes gebildet. Es ist das höchste beschlussfassende Gremium im Projekt.
Oft existieren in der Praxis beide Gremien, der Lenkungsausschuss und das
Steuerungsgremium. In diesem Fall werden diese dahingehend unterschieden, dass
es sich um einen Lenkungsausschuss handelt, wenn dieser für ein einzelnes Projekt
zuständig ist. Wesentliche Aufgabe des Lenkungsausschusses ist es, gemeinsam mit dem
Auftraggeber den ordnungsgemäßen Ablauf des Projektes zu überwachen. Hingegen
steuert das übergeordnete, ständige und strategische Steuerungsgremium die gesamte
Projektlandschaft in einer Unternehmung. Oft liegt dann das übergeordnete Portfolio-
management ebenfalls in der Hand des Steuerungsgremiums. Die zentrale Aufgabe des
Steuerungsgremiums ist die Auswahl der für das jeweilige Unternehmen passenden
Projekte und Programme.
Die folgende Tabelle stellt die Aufgaben und die Befugnisse von Lenkungsausschuss und
Steuerungsgremium tabellarisch gegenüber (Tab. 2.5).
Auftraggeber
Der Auftraggeber ist die Person bzw. Organisation, welche das Projekt beauftragt hat.
i. d. R. wird durch ihn auch das für dieses Projekt vorgesehene Budget bereitgestellt und
das Ergebnis in Empfang genommen. Der Auftraggeber ist meist der Vorsitzende des
Lenkungsausschusses. In Abstimmung mit dem Lenkungsausschuss sind die Aufgaben
des Auftraggebers:
• Freigabe finanzieller Mittel und sonstiger Ressourcen, ggf. nach Absprache mit dem
Lenkungsausschuss,
• Durchführung von Projektmarketing,
• Einnehmen der Position des kritischen Hinterfragens und
• wird aktiv, wenn Entscheidungen außerhalb des Kompetenzrahmens der Projekt-
leitung getroffen werden müssen.
Projektleitung
Der Leiter des Projektes ist im Wesentlichen für die Planung und Steuerung des Projekt-
teams zuständig. Daneben zählt insbesondere zu seinen Aufgaben:
Die Projektleitung ist für Erfolg und Misserfolg des Projektes verantwortlich und ver-
tritt das Projekt nach außen. Dementsprechend kommt der Rolle des Projektleiters die
2.2 Projektorganisation 59
wichtigste Bedeutung bei einem Projekt zu und die Besetzung hat entscheidenden Ein-
fluss auf den Erfolg des Projekts. Der Projektleiter ist für die Erreichung der vereinbarten
Projektziele verantwortlich und koordiniert die Projektaufgaben und das Projektteam
im Rahmen der ihm zugeteilten Entscheidungs- und Weisungsbefugnisse. Tab. 2.6 fasst
empfohlene Aufgaben und die entsprechend notwendigen Befugnisse der Projektleitung
zusammen.
In folgendem Beispiel wird eine typische Stellenanzeige für eine Projektleitung
dargestellt, die auf der einen Seite die Aufgaben und auf der anderen Seite die dazu
gehörigen Charakteristika des Profils aufzeigt.
Aufgabengebiet
Profil
Angebot
Wir bieten Ihnen einen anspruchsvollen und vielseitigen Arbeitsbereich, in welchem
Sie selbstständig und in einem motivierten und dynamischen Team arbeiten. Sind Sie
kunden- sowie lösungsorientiert und Ihnen liegen unregelmäßige Arbeitszeiten im
Blut?
Projektmanagementkompetenz
Fachkompetenz
Projektgröße
Abb. 2.30 Verhältnis von Fach- und Führungskompetenzen eines Projektleiters zur Projektgröße
2.2 Projektorganisation 61
Projektteam
Die Zusammensetzung der Mitglieder des Projektes obliegt dem Projektleiter. Um einen
erfolgreichen Projektverlauf sicherzustellen, ist es wichtig, eine bedachte Auswahl der
Projektteammitglieder durchzuführen. Grundlage für die Auswahl sind die technischen
Anforderungen des Projektes. Es ist sicherzustellen, dass durch die Mitglieder sämtliche
Kompetenzfelder abgedeckt sind, die das Projekt benötigt. Jedoch ist ebenfalls darauf zu
achten, dass die Teamgröße ca. zehn Personen nicht überschreitet, ggf. sind Teilprojekte
zu bilden.
Der Projektleiter steht ebenfalls vor der Herausforderung, sich bei der Auswahl der
potenziellen Teammitglieder Gedanken über die möglichen Vor- und Nachteile von
externen bzw. internen Ressourcen machen. Ein weiterer Aspekt ist das effiziente Mit-
einander im Team. So hat der Projektleiter bei der Zusammensetzung des Teams darauf
zu achten, dass die vier Kompetenzfelder:
• Fachkompetenz,
• Sozialkompetenz,
• Entscheidungskompetenz und
• Anwendungskompetenz
durch die Mitglieder des Projektteams abgedeckt werden. Idealerweise liegt bereits der
Projektstrukturplan vor, sodass die benötigten fachlichen Kompetenzen abgeleitet und
entsprechende Teammitglieder identifiziert werden können. Zusätzlich ist es erforderlich,
sich bereits im Vorfeld einen möglichst umfangreichen Überblick über die potenziellen
Mitglieder zu verschaffen und diese jeweils einem der Kompetenzfelder zuzuordnen. In
Tab. 2.7 sind die Anforderungen an die einzelnen Personen sowie die Charakterisierung
für jedes Kompetenzfeld dargestellt.
AKV-Prinzip
Bei der Delegation von Aufgaben an die Mitglieder in dem Projektteam durch den
Projektleiter ist darauf zu achten, dass die Aufgaben, Kompetenzen und Verantwortungen
der einzelnen Projektmitglieder aufeinander abgestimmt sind. Das AKV-Prinzip ist
dabei eine gute Hilfe [10]. AKV steht für:
62 2 Klassische Grundlagen: Es geht los…
• A – Aufgaben
• K – Kompetenzen
• V – Verantwortungen
Aufgaben
Unter einer Aufgabe versteht man jede Tätigkeit, die in einem mittelbaren oder unmittel-
baren zu dem Projekt steht. Üblicherweise finden sich diese im Projektstrukturplan
wieder.
Kompetenzen
Mit Kompetenzen sind hier die Weisungsbefugnisse gemeint, mit denen sowohl die
einzelnen Projektteammitarbeiter als auch der Projektleiter ausgestattet sind. Diese
müssen auf den Aufgabenumfang und die jeweilige Verantwortung abgestimmt sein.
Verantwortung
Die Übernahme von Verantwortung bedeutet, Rechenschaft über das eigene Tun ablegen
zu müssen und hinsichtlich des Erfolges und Misserfolges zur Rechenschaft gezogen
werden zu können.
So erfordert die Übergabe von zusätzlichen Aufgaben an den Mitarbeiter auch
ein zusätzliches Maß an Kompetenz für den Projektmitarbeiter, ansonsten werden
ineffiziente organisatorische Rückversicherungen beim Projektleiter notwendig und
die Motivation beim Mitarbeiter sinkt. Gleichermaßen kann sich die Übernahme von
Verantwortung immer nur auf die durchgeführten Aufgaben und die zugestandenen
Kompetenzen beziehen. Während in der Praxis häufig beobachtet wird, dass
2.2 Projektorganisation 63
Zu beachten gilt, dass es sich bei der Wahl zwischen externen und internen Kompetenz-
trägern nicht um eine Entscheidung auf Ebene des gesamten Projektteams handelt. Viel-
mehr sind es die zuvor genannten Abwägungen für jede Position innerhalb des Teams
durchzuführen. Oftmals obliegt eine derartige Entscheidung auch nicht dem Projekt-
leiter allein. Bei internen Mitarbeitern ist i. d. R. eine Abstimmung mit dem Linienvor-
gesetzten notwendig, bei externen Mitarbeitern ist der Einkauf einzubeziehen, ggf. die
Rechtsabteilung und weitere. Idealerweise erfolgt eine solche Entscheidung daher im
Lenkungsausschuss.
2.2 Projektorganisation 65
Ziel der ersten drei Phasen ist es, sie schnell zu durchlaufen und schnell in die effiziente
und motivierte Performing-Phase zu kommen. Dreh und Angelpunkt ist die Durchführung
des Kickoffs, in dem die Grundlagen für die produktive Zusammenarbeit gelegt werden.
Wesentliches Element des Kickoffs ist die Erläuterung der Projekthintergründe:
Die Performing-Phase ist die Phase, zu der alles hinstrebt. Leistung und Motivation sind
auf dem Höhepunkt und die Arbeit geht allen leicht von der Hand. Das Team funktioniert
und die Zusammenarbeit ist produktiv. Alle fühlen sich für den Projekterfolg verantwort-
lich, sehen ihren Anteil daran und pflegen eine ungezwungene Zusammenarbeit. Dies ist
im Grunde die „bequemste“ Phase für den Projektleiter, hier läuft alles wie von selbst.
Um die Teammitglieder nicht aus dem Tritt zu bringen, sollte der Projektleiter sehen,
was das Team braucht und Rahmenbedingungen schaffen, in denen es ungehindert
arbeiten kann. Nichtsdestotrotz besteht immer die Gefahr eines „Rückfalls“ in eine der
anderen Phasen, der Projektleiter muss also auch in dieser Zeit die Augen offenhalten.
Vorbereitend auf die wieder abflauende Produktivität und Motivation in der
Adjourning-Phase muss der Projektleiter die Arbeitsergebnisse genau definieren und
für die präzise Ausführung sorgen. Im Gegensatz zur vorherigen Phase ist hier mehr
Kontrolle des Projektleiters notwendig, um für einen geordneten und vollständigen
Projektabschluss zu sorgen. Gleichzeitig soll der Projektleiter die Sorge der Projektmit-
arbeiter über ihre Zukunft auffangen und sich aktiv um die Rückführung in die Linie
kümmern. Dazu gehören auch Rückmeldungen über die Leistung des Mitarbeiters in der
Projektarbeit. Dies entlastet und wirkt motivierend.
Kontrollfragen
1. Welche Funktionen übernimmt ein Projektkoordinator in einer Stabsprojekt-
organisation?
2. Welche Projektorganisationsformen der externen Aufbauorganisation gibt es?
3. Nennen Sie je einen Vorteil der verschiedenen Projektorganisationen?
4. Welche sind die bedeutendsten Rollen in einem Projekt?
5. Was versteht man unter dem AKV-Prinzip?
2.3 Projektplanung 67
2.3 Projektplanung
Lernziele
Sie wissen, wofür ein Projektstrukturplan benötigt wird.
Sie können einen Projektstrukturplan nach verschiedenen Aspekten aufbauen.
Sie kennen die Rolle der Arbeitspakete in einem Projektstrukturplan.
Sie kennen die Vorteile der Meilensteine im Rahmen der Terminplanung.
Sie können die gesamte Pufferzeit in Ihren Planungen sinnvoll einsetzen.
Sie kennen die grundlegenden Aufgaben einer Ressourcenplanung.
Sie können unterschiedliche Kostenarten in Ihren Projekten berücksichtigen.
Sie kennen die möglichen Risiken, die bei einer Risikoplanung zu berücksichtige
sind.
Definitionsphase
Die Definitionsphase dient der methodischen Konkretisierung der Initialisierungs-
phase (Abschn. 1.4.1). Während sich in der Initialisierungsphase im Wesentlichen auf
die Kunden konzentriert wurde, um ein tieferes Verständnis darüber zu erlangen, welche
Probleme gelöst und welche Ziele erreicht werden sollen, werden nun die notwendigen
Arbeiten in den Blick genommen.
Im Rahmen der Definitionsphase werden die genauen Vorgehensweisen festgelegt.
Dabei ist es wichtig zu prüfen, ob im Umfeld des geplanten Projektes und in Abhängig-
keit vom Inhalt des Projektes Anpassungen vorgenommen werden müssen. Diese können
durch das Unternehmen selbst, in dem das Projekt umgesetzt wird, vorgegeben sein,
oder durch eigene Erfahrung begründet werden. Beispiele sind ein Kommunikations-
managementplan, Risikomanagementplan etc. Diese Dokumente können einzeln vor-
liegen, oder in einem Gesamtdokument zusammengefasst werden.
Planungsphase
Ziel der Planungsphase ist die inhaltliche Detaillierung der Initiierungsphase und ist im
Ergebnis ein detaillierter Projektplan, der verschiedene Detailpläne enthält (z. B. Auf-
gabenplanung, Risikoplanung, Aufwandsplanung, Termin- und Meilensteinplanung,
Kosten- und Ressourcenplanung).
Im Rahmen der Diskussion über die Aufgaben der Projektleitung wurde bereits deut-
lich, dass ein Projektleiter nicht zwingend über das für das Projekt notwendige fachliche
Wissen verfügt. Dieses Wissen muss durch das Projektteam bereitgestellt werden. Eine
erste grobe Aufgabenplanung hilft bei der Identifizierung der benötigten Fähigkeiten.
Im sog. Kick-Off-Meeting wird diese Planung weiter detailliert. Auf der Agenda
stehen im Wesentlichen die Inhalte des Projektauftrags, der nochmals gemeinsam
68 2 Klassische Grundlagen: Es geht los…
abgestimmt und weiter konkretisiert wird. Die detaillierte Planungsarbeit wird dann
wiederum in kleineren Teams erfolgen und durch den Projektmanager koordiniert.
Lehrvideos
Welche Themengebiete abgedeckt werden, zeigt das Video Abb. 2.32.
2.3.2 Aufgabenplanung
Ziel der Aufgabenplanung ist die vollständige Identifikation der Arbeiten, die in einem
Projekt zu bearbeiten sind. Wesentliche Hilfsmittel sind der Projektstrukturplan zur
strukturierten Analyse und die Arbeitspakete zur genauen Definition der Arbeiten.
Grundsätzlich wird angestrebt, ein neuartiges Vorhaben so weit zu zergliedern, dass in
den Arbeitspaketen am Ende des Detaillierungsprozesses nur bekannte Arbeiten definiert
sind.
Projektstrukturplan
Bei der Organisation des Projektinhaltes geht es primär um die Festlegung der einzelnen
Arbeitspakete und die Schnittstellen zwischen diesen. Das verwendete Hilfsmittel ist der
Projektstrukturplan (PSP). Ein Projektstrukturplan ist die Gliederung der Gesamtaufgabe
in plan- und kontrollierbare Teilaufgaben (Arbeitspakete). Als Faustregel für die Zahl
von Arbeitspaketen (AP) im Projekt haben sich folgende Größen bewährt (Tab. 2.9):
Eine weitere Faustregel besagt, dass die Größe eines Arbeitspaketes zwischen 40
und 80 Personenstunden liegen soll. Teilweise wird dies explizit in unternehmensweiten
Projektmanagementleitfäden gefordert.
Abb. 2.32 Magisches
Dreieck und Inhalte des
Projektmanagements (https://
doi.org/10.1007/000-0r2)
2.3 Projektplanung 69
Wie derAbb. 2.33 zu entnehmen ist, steigt der Umfang und der Detailierungsgrad des
PSP mit jeder Ebene an. Weiterhin ist die Abgrenzung zwischen den Teilaufgaben und
der untersten Ebene, den Arbeitspakten zu erkennen. Jede der drei großen Teilaufgaben
des Projektes lässt sich in kleinere Teilaufgaben zerlegen, welche sich wiederum in die
kleinsten Einheiten, die Arbeitspakete, zerlegen lassen. Die Arbeitspakete sind immer die
Elemente im Projektstrukturplan, die nicht weiter untergliedert wurden.
In der praktischen Anwendung fällt es oft schwer, die Elemente eines Projektstruktur-
plans zu identifizieren. Das beginnt mit der Frage, welche Elemente auf der obersten
Ebene angesiedelt sind, bis hin zur Überlegung, welcher Teilaufgabe ein Element zuzu-
ordnen ist, oder ob das Element selbst schon eine Teilaufgabe ist. Orientierung kann
dazu eine Zergliederung des Projektstrukturplanes nach den Gesichtspunkten
• Objektorientierung,
• Funktionsorientierung,
• Phasenorientierung oder
• als Mischform
geben.
Die nachfolgenden Beispiele geben einen Überblick darüber, wie sich die Dar-
stellungsformen unterscheiden. Häufig ist es abhängig vom Projekt, welche dieser
Formen sinnvoll ist.
In Abb. 2.34 liegt ein objektorientierter Projektstrukturplan vor, alle Elemente des
Projektstrukturplanes sind ein Objekt, welches fertiggestellt werden soll und jedes
Objekt ist in weitere Objekte unterteilt.
Diese Darstellungsweise empfiehlt sich, wenn im Rahmen des Projektes ein Produkt
hergestellt werden soll, das aus mehreren identifizierbaren Komponenten besteht, bei-
spielsweise ein Auto, das in Motor, Karosserie, etc. aufgeteilt werden kann, oder wie hier
ein Gebäude, welches in weitere Teilbereiche untergliedert werden kann.
Stuttgart 21
Tiefbau Erdgeschoss
Obergeschoss
Parkdeck
Stuttgart 21
Konstruktions-
Berechnung
planung
Statik Lastannahme
Projektstrukturplan
Vorplanung Ausschreibung
Entwurfsplanung Vergabe
Genehmigungs- Bauausführung
planung
Ausführungs-
planung
69901-2 in der ersten Ebene, die weitere Zerlegung erfolgt gemäß der Honorarordnung
für Architekten und Ingenieure (HOAI). Auch hier sind existierende Standards genutzt
worden, um eine erste Orientierung bei der Zerlegung des Projektstrukturplanes zu
haben.
Die phasenorientierte Detaillierung ist gut geeignet, um das im Lauf des Projektes
wachsende Wissen in die Planung einfließen zu lassen. So können die ersten Phasen sehr
detailliert geplant werden, während die späteren Phasen erst im Projektablauf weiter-
entwickelt werden. Man spricht in diesem Fall von rollierender Planung, d. h. eine
schrittweise Verfeinerung der Phasen.
Arbeitspakete
Die unterste Gliederungsebene des PSP bilden die Arbeitspakete (AP). Sie geben an,
welche Aktivitäten auszuführen und welche Ergebnisse zu erzielen sind. Ein Arbeits-
paket
Arbeitspaket Definition nach DIN 69901: Ein Arbeitspaket ist Teil des Projektes,
das im Projektstrukturplan nicht weiter aufgegliedert ist und auf einer beliebigen
Gliederungsebene liegen kann.
Ein Arbeitspaket
• Top-Down-Verfahren,
• Bottom-Up-Verfahren und
• Gegenstromverfahren.
Top-Down-Verfahren
Beim Top-Down-Verfahren stellt das Gesamtprojekt die erste Ebene dar. Diese wird
in Teilprojekte aufgegliedert und jedes einzelne Teilprojekt weiter heruntergebrochen.
Dieser Prozess wird so lange fortgeführt, bis auf der untersten Ebene plan- und
kontrollierbare Arbeitspakete vorliegen.
Bottom-Up-Verfahren
Beim Bottom-Up-Verfahren werden zunächst mittels eines Brainstormings sämtliche
mit dem Projekt verbundene Teilaufgaben auf beliebigen Aggregationsebenen auf-
gelistet. Diese Teilaufgaben werden anschließend gruppiert und mögliche hierarchische
Beziehungen identifiziert. Die auf diese Weise entstandene Baumstruktur kann
anschließend um ggf. beim Brainstorming nicht berücksichtigte Aufgaben ergänzt
werden, etwaige Redundanzen werden aufgelöst.
74 2 Klassische Grundlagen: Es geht los…
Gegenstromverfahren
In der Praxis verläuft die Bildung des PSP meist in Form eines Gegenstromverfahrens.
Dabei handelt es sich um eine Kombination der beiden zuvor genannten Vorgehens-
weisen. Ist das Projektthema bei den Projektbeteiligten bereits bekannt, wird oftmals
Bottom-Up gestartet und die Aufgaben, die bearbeitet werden müssen, werden auf-
gelistet und strukturiert. Ein Abgleich mit dem Projektauftrag fördert Top-Down ggf.
weitere Bestandteile des Projektes zu Tage. Ist das Thema für die Beteiligten neu, wird
oft Top-Down gestartet, um schrittweise das Verständnis des Projektes zu vertiefen.
Sobald eine Ebene mit bekannteren Inhalten angelangt wurde, werden oft weitere Auf-
gaben identifiziert, die sich in die bisherige Projektstruktur ggf. nicht eingliedern lassen
und entsprechend Bottom-Up eingefügt werden. Die abschließende Prüfung auf Umsetz-
barkeit und Vollständigkeit kann sowohl Bottom-Up als auch Top-Down zu weiteren
Aufgaben führen.
Die nachfolgende Gegenüberstellung soll einen Überblick über die jeweiligen Vor-
und Nachteile geben, die mit den jeweiligen Verfahren verbunden sind. Das Gegenstrom-
verfahren ist hier bewusst außen vor, da es die Vorteile der beiden anderen Verfahren
vereint. Nur in den seltensten Fällen ist daher ausschließlich das Top-Down- bzw. das
Bottom-Up-Verfahren zu empfehlen (Tab. 2.10).
Aus der Erkenntnis, dass keines der beiden Verfahren (Top-Down/Bottom-Up)
optimal ist, wurde das Gegenstrom-Verfahren entwickelt, um die Vorteile der beiden
genannten Verfahren zu nutzen.
Ein typisches Projektziel, das in diesem „Gegenstromverfahren“ geplant wird, ist die
Einführung neuer Produkte:
1. Das Oberziel „Produkt bis zum 31.12. einzuführen“, wird von der Geschäftsleitung
der Projektleitung vorgegeben.
2. Von der Projektleitung wird ein erster, grober Top-Down-Entwurf des Projekt-
strukturplanes erstellt und auf Basis der identifizierten notwendigen Kompetenzen
den Abteilungen Forschung und Entwicklung, Produktion, Marketing/Vertrieb,
Lehrvideos
Eine Vertiefung und Erläuterung zum Projektstrukturplan finden Sie in den Videos
Abb. 2.37, 2.38, 2.39 und 2.40 des Videokurses.
Die Terminplanung fußt auf der Ablaufplanung und ist ein zentrales Element innerhalb
der Planungsphase. Durch die Einbeziehung der zeitlichen Komponente in den Planungs-
prozess soll insbesondere:
Hochhausbau in China
Was eine optimale Terminplanung alles möglich macht beweist der Bau eines
Hochhauses in China. Der Bau des Gebäudes mit 57 Stockwerken wurde nach nur
19 Tagen abgeschlossen. Unter dem QR-Code Abb. 2.41 finden Sie ein Video mit
weiteren Informationen zum diesem rekordverdächtigen Bau. ◄
Abb. 2.41 Hochhausbau in
China
2.3 Projektplanung 77
Ereignisse mit einer hohen Wichtigkeit sind etwa vorhanden, wenn es sich zu diesem
Zeitpunkt um:
• Zwischenergebnisse,
• Überprüfungen,
• wichtige Bestellungen
• wichtige Entscheidungen oder
• Phasenübergänge
handelt.
Die Meilensteine erfüllen innerhalb eines Projekts unterschiedliche Aufgaben:
Im Rahmen der Terminplanung eignen sich die Meilensteine besonders, um den groben
Ablauf des Projektes zu strukturieren, was die Übersichtlichkeit im Zuge der Netzplan-
entwicklung wesentlich erhöht. Zu diesem Zweck werden sie in eine sinnvolle, ggf. vor-
läufige Reihenfolge gebracht.
Daneben eignen sie sich im weiteren Verlauf des Projekts, um den Fortschritt zu
messen. Da sie im Rahmen der Terminplanung an strategisch wichtigen Punkten platziert
werden, kann durch deren Erreichungsgrad auch darauf geschlossen werden, ob der
zuvor erstellte Zeitplan eingehalten werden kann oder ggf. Anpassungen erforderlich
sind.
Lehrvideos
Eine Vertiefung und Erläuterung zu Meilensteinen finden Sie in den Abb. 2.42, 2.43, 2.44
und 2.45 des Videokurses.
78 2 Klassische Grundlagen: Es geht los…
Abb. 2.42 Einführung
Meilensteinplanung (https://
doi.org/10.1007/000-0r7)
Abb. 2.43 Meilensteine
und Gates (https://doi.
org/10.1007/000-0r8)
Abb. 2.44 Phasenunabh
ängige Meilensteine (https://
doi.org/10.1007/000-0r9)
Abb. 2.45 Phasenplanung
in MS Project (https://doi.
org/10.1007/000-0ra)
Schritt 2: Ablaufplanung
Die Ablaufplanung wird mithilfe der Netzplantechnik realisiert.
Ablaufplan Der Ablaufplan ist laut DIN 69901 eine Übersicht über den geplanten
sachlichen, unter Umständen auch zeitlichen Ablauf des Projektgeschehens, orientiert
am Projektziel, den Realisierungsbedingungen und den geplanten Ergebnissen.
2.3 Projektplanung 79
a) Netzplantechnik
Netzplan Nach DIN 69900 Teil 1 ist der Netzplan die grafische oder tabellarische
Darstellung von Abläufen und deren Abhängigkeiten.
In der Vergangenheit existierten drei unterschiedliche Arten von Netzplänen, von denen
sich der Vorgangsknotennetzplan (VKN) letztlich durchgesetzt hat.
Beim VKN stellen die Knoten die Vorgänge des Projektes dar. Es werden Vor-
gangsbezeichnung, Vorgangsnummer und Vorgangsdauer in die Knoten eingetragen.
Die Verbindungspfeile repräsentieren die Anordnungsbeziehungen, die sachlogischen
(technologischen) Abhängigkeiten zwischen dem End- und Anfangsereignis des
bedingten Vorgangs (Vorgänger) und dem Anfangs- oder Endereignis des bedingten Vor-
gangs (Nachfolger) beschreiben. In Anbetracht der mannigfaltigen Vorteile sowie der
am Markt verfügbaren EDV-Software werden im Projektmanagement heute praktisch
ausschließlich Vorgangsknotennetze verwendet.
Für die Erstellung eines Netzplans sind die einzelnen Arbeitspakete zunächst in Vor-
gänge aufzulösen und die sogenannten Anordnungsbeziehungen herzustellen.
• Muss der Vorgang abgeschlossen sein, wenn der Meilenstein erreicht wird?
• Kann der Vorgang erst nach Erreichung des Meilensteines bearbeitet werden?
80 2 Klassische Grundlagen: Es geht los…
Beide Fragen können durchaus gleichzeitig für einen Vorgang beantwortet werden, damit
ist bekannt, zwischen welchen Meilensteinen ein Vorgang bearbeitet werden muss oder
es wird festgestellt, dass ein Vorgang mehrfach oder in Teilschritten umgesetzt werden
muss. Letzteres macht eine weitere Aufteilung des Vorganges notwendig. So entsteht
bereits eine grobe Ablaufplanung der Vorgänge, die für eine weitere Präzisierung unter-
einander in eine sinnvolle Reihenfolge gebracht werden müssen.
Ende-Anfang-Beziehung
Der Anfangstermin des Nachfolgers ist abhängig vom Endtermin des Vorgängers.
Typisches Beispiel aus dem Umzugsleben: Erst wird die alte Tapete abgerissen, dann
tapeziert.
Seltene, aber durchaus vorkommende Beziehungen sind die Ende-Ende- oder Anfang-
Anfang Beziehungen. Diese bedeuten allerdings nicht, dass zwei Vorgänge gleichzeitig
zu Ende sein oder anfangen müssen:
Anfang-Anfang-Beziehung
Der Anfangstermin des Nachfolgers ist hier abhängig vom Anfangstermin des Vor-
gängers. Ein Beispiel aus dem Fernsehen: Die beiden Vorgänge „Formel 1-Rennen
durchführen“ und „Live-Übertragung senden“ sind insofern voneinander abhängig, dass
der Start der Live-Übertragung vom Start des Rennens abhängt. An diesem Beispiel wird
ebenfalls deutlich, dass es nicht zwangsläufig um Gleichzeitigkeit geht, denn oftmals
wird bereits vor dem Start des Rennens die Liveberichterstattung begonnen. Allerdings
verschiebt sich die Liveberichterstattung mit dem Zeitpunkt des Rennens, das angesichts
von Zeitzonenunterschieden auch am frühen Morgen oder späten Abend stattfinden kann.
Ende-Ende-Beziehung
Der Endtermin des Nachfolgers ist abhängig vom Endtermin des Vorgängers. Auch hier
gibt es ein typisches Beispiel aus dem täglichen Leben: Gänsebraten zuzubereiten dauert
erheblich länger, als das Kochen der Kartoffeln, üblicherweise richtet sich die Fertig-
stellung (das Ende) der Kartoffeln also nach dem Ende des Gänsebratens.
Anfang-Ende-Beziehung
Der Endtermin des Nachfolgers ist abhängig vom Anfangstermin des Vorgängers. Diese
Situation liegt beispielsweise bei Wachablösungen vor: der erste Wachmann darf seinen
2.3 Projektplanung 81
Dienst beenden, wenn sein Nachfolger seinen Dienst angetreten/angefangen hat. Eine
Beziehung, die so gut wie nie vorkommt, aber der Vollständigkeit halber erwähnt werden
sollte.
Jede dieser grundlegenden Beziehungen kann durch Zeitabstände variiert werden, die
positiv oder negativ sein können. Ein positiver Zeitabstand drückt eine Wartezeit aus,
die mindestens eingehalten werden muss. Beispielsweise kann der Boden erst einige
Wochen nach dem Ausbringen des Estrichs gefliest werden.
Ein negativer Zeitabstand bedeutet, dass eine Tätigkeit schon anfangen kann, obwohl
die Voraussetzungen vom Vorgänger noch nicht erfüllt sind. Dies ist beispielsweise
der Fall bei der Livesendung des Formel1-Rennens. Diese startet vor dem eigentlichen
Rennstart, der aber bestimmend für die Livesendung ist (Abb. 2.46).
Die Netzplantechnik vereint die nachfolgenden Vorteile:
ufferzeiten. Es hat sich folgende Notation für die Bezeichnung der Elemente eines Vor-
P
ganges eingebürgert. Die Ermittlung der einzelnen Elemente wird im weiteren Verlauf
genauer beschrieben (Abb. 2.47).
Mithilfe der Dauer der einzelnen Vorgänge und damit auch der AP kann der Netzplan
terminiert werden. Hinsichtlich der Notation wird in der Praxis eine in weiten Teilen
standardisierte Vorgehensweise verfolgt.
Zur Ermittlung des kritischen Weges, wird zunächst:
Abb. 2.47 Vorgangsbezeichnungen
2.3 Projektplanung 83
durchgeführt.
Bei der Vorwärtsterminierung werden die frühesten Zeitpunkte (Frühester
Anfangszeitpunk, FAZ und Frühester Endzeitpunkt, FEZ) eines Vorgangs mithilfe der
Dauer D ermittelt.
1. Der Startknoten erhält den Frühesten Anfangszeitpunkt „0“, dies wird in das linke,
obere Feld eingetragen.
2. Zum Frühesten Anfangszeitpunkt wird die Dauer addiert. So erhält man den
Frühesten Endzeitpunkt, dies wird in das rechte, obere Feld eingetragen:
Legende:
Abb. 2.48 Vorwärtsterminierung
84 2 Klassische Grundlagen: Es geht los…
1. Der Endknoten erhält als Spätesten Endzeitpunkt den Frühesten Endzeitpunkt, d. h.
die Zahl aus dem rechten, oberen Feld wird in das rechte, untere Feld übertragen.
2. Vom Spätesten Endzeitpunkt wird die Dauer subtrahiert, so erhält man den Spätesten
Anfangszeitpunkt, dies wird in das linke, untere Feld eingetragen:
Legende:
Abb. 2.49 Rückwärtsterminierung
2.3 Projektplanung 85
ermittelt werden.
Die gesamte Pufferzeit ist der Zeitraum, der für die Verzögerung der Vorgänge bzw.
des Arbeitspaketes bestenfalls zur Verfügung steht, ohne das Projektende oder einen
anderen festen Termin zu gefährden. Wird die gesamte Pufferzeit beim Arbeitsgang voll
ausgenutzt, so bleibt für die nachgeordneten Arbeitsgänge auf dem Weg zum Endpunkt
kein Spielraum mehr, da diese jeweils maximal nach hinten verschoben werden. Jede
weitere Verzögerung würde das Projektende verzögern. Die gesamte Pufferzeit GP wird
als Zeitspanne zwischen dem Frühesten und Spätesten Anfangszeitpunkt, bzw. Endzeit-
punkt eines Vorgangs berechnet:
GP = SEZ − FEZ, bzw. GP = SAZ − FAZ. (2.5)
Abb. 2.50 zeigt die Berechnung im Netzplan. Ebenfalls ist nachvollziehbar, dass sich
eine Verschiebung des Vorgangs 122 um einen Tag (also innerhalb der Pufferzeit) auf
einen entsprechend um einen Tag Späteren Frühesten Endzeitpunkt in Vorgang 123 aus-
wirkt. Der Früheste Anfangszeitpunkt wäre dann nicht mehr 14, sondern 15 und damit ist
mit dem Verbrauch der Gesamten Pufferzeit in Vorgang 122 auch die gesamte Pufferzeit
im Nachfolgevorgang verbraucht.
Ein AP kann jeweils um die freie Pufferzeit(FP) verschoben werden, ohne dass der
frühestmögliche Anfangstermin eines nachgeordneten Vorgangs beeinflusst wird. Bei der
Berechnung der freien Pufferzeit wird zunächst nach dem am frühesten startenden Nach-
folger gesucht. Von dessen Frühestem Anfangszeitpunkt wird der Früheste Endzeitpunkt
des aktuellen Vorgangs abgezogen, um die freie Pufferzeit des aktuellen Vorgangs zu
erhalten. Die freie Pufferzeit berechnet sich wie folgt:
FP = min. (FAZ(n)) − (FEZ(v)). (2.6)
Kritischer Pfad
Es empfiehlt sich darüber hinaus den sogenannten „kritischen Pfad“ zu identifizieren und in
dem Terminplan kenntlich zu machen. Auf diesem Pfad liegen sämtliche Vorgänge innerhalb des
Projektes, bei denen kein Gesamtpuffer existiert. Aus diesem Grund wirkt sich jede Verzögerung
bei Aktivitäten auf diesem Pfad unmittelbar auf den Endtermin des Projektes aus. In der Praxis
wird der kritische Pfad im Terminplan häufig durch eine farbliche Kennzeichnung in Rot hervor-
gehoben.
Gantt-Diagramm
Das Gantt-Diagramm ist eine weitere Darstellungsform des Terminplans. In der
ursprünglichen Version sind die Abhängigkeiten zwischen den Vorgängen nicht dar-
gestellt, in der aktuellen, modernen Planungssoftware sind diese ergänzt worden.
Ein großer Vorteil des Gantt-Diagramms ist die Visualisierung der Terminierung
und die zeitliche Abfolge der einzelnen Vorgänge. So kann der Anordnung entnommen
werden, ob die einzelnen Vorgänge
Zeit Monate
Vorgang
1 2 3 4 5 6 7 …
1. Projektvorbereitung
2. Konzeption
3. Spezifikation
4. Realisierung
5. Dokumentation
6. Inbetriebnahme
7. Wartung
Abb. 2.52 Gantt-Diagramm
Einfluss der Projektgröße Bei der Festlegung der Art, der Darstellung und
der Vorgänge ist die Projektgröße und dessen Komplexität einzubeziehen und
Aufwand/Nutzen einander abzuwägen.
Lehrvideos
Eine Vertiefung und Erläuterung zur Ablauf- und Terminplanung finden Sie in den
Videos Abb. 2.54, 2.55, 2.56, 2.57, 2.58 und 2.59 des Videokurses.
Abb. 2.54 Einführung
Ablauf- und Terminplanung
Abb. 2.55 Die
Anordnungsbeziehungen
(https://doi.org/10.1007/000-
0rc)
Abb. 2.56 Entwicklung
des Netzplanes aus dem
Projektstrukturplan (https://doi.
org/10.1007/000-0rd)
Abb. 2.57 Manuelle
Berechnung des kritischen
Pfades (https://doi.
org/10.1007/000-0re)
2.3 Projektplanung 89
Abb. 2.58 Planungsschritte
in MS Project
2.3.4 Ressourcenplanung
Bei der Planung der Einsatzmittel bzw. Ressourcen werden die während des Projekts
benötigten Ressourcen bestimmt und deren Verfügbarkeit sichergestellt.
Ressourcen DIN 69901 definiert Ressourcen als abgrenzbare Gattung bzw. Einheit
von Personal, Finanzmitteln, Sachmitteln, Informationen, Naturgegebenheiten, Hilfs-
und Unterstützungsmöglichkeiten, die zur Durchführung oder Förderung von Vorgängen,
Arbeitspaketen oder Projekten herangezogen werden können [5].
Ressource ist ein vielfältiger Begriff. Oft bezieht er sich auf die notwendigen
Materialien, jedoch sind ebenfalls benötigte Mitarbeiter gemeint. Mit fortschreitendem
Gebrauch der englischen Sprache verschwindet immer mehr der etwas despektierliche
Beiklang bei der Nutzung des Begriffes „Ressourcen“ für Menschen. Insgesamt ist eine
Einschätzung der nachfolgend aufgelisteten Ressourcen in der Planung sinnvoll:
• Menschen,
• Maschinen,
• Sachmittel und
• Finanzmittel.
Der Ressourcenbedarf ist über das gesamte Projekt niemals konstant, sondern ver-
ändert sich abhängig von der jeweiligen Projektphase. So werden zu Beginn
zumeist planerische Kompetenzen benötigt, während im späteren Verlauf verstärkt
90 2 Klassische Grundlagen: Es geht los…
Abweichungsanalyse
Im Anschluss an die Kapazitätsaufnahme werden diese der Ressourcenplanung gegen-
übergestellt, um etwaige Unter- oder Überkapazitäten zu identifizieren. Diese können
aus den APs abgeleitet werden oder aus dem Terminplan.
2.3 Projektplanung 91
Tab. 2.12 Ressourcenplanung
PSP Vorgang Dauer Arbeit Ressource/Menge
A.2 Phase 2 – Prozess-modellierung
A.2.10 Dokumenten-analyse durchführen 30 10 TE 2
40 BA 2
12 PC 1
A.2.12 Interviews mit den Stakeholdern führen 10
A.2.1 Prozessentwurf fertigen 45 10 PJ 2
A.2.2 Rücksprache mit den Prozess-beteiligten 30 10 TE 1
20 BA 1
5 PC 1
A.2.3 Modellierung eines ausführbaren Prozesses 15 10 TE 1
10 PC 1
…
Abkürzungen:
TE: Techniker
BA: Business Analyst
PC: Projektcontroller
Abb. 2.60 zeigt ein Ressourcenhistogramm mit dem Zeitablauf auf der X-Achse
und der Zahl der benötigten Mitarbeiter auf der Y-Achse. Dem Histogramm mit den
benötigten Ressourcen steht die Verfügbarkeit der Ressourcen gegenüber, hier als dicke
Linie eingezeichnet. Die grafische Umsetzung dient insbesondere dazu, einen schnellen
Überblick über etwaige Über- bzw. Unterkapazitäten zu erhalten, um so die zuvor
genannten Gegenmaßnahmen entsprechend gezielt einzusetzen und durch Optimierung
der Ressourcen einen positiven Einfluss auf die Terminierung und Kosten und damit auf
den Erfolg des Projektes zu nehmen.
Mögliche Maßnahmen, um etwaige Unter- oder Überkapazitäten zu bereinigen, sind:
Durch eine optimale Planung der Kapazitäten kann sich an den vorgegeben Termin-
plan gehalten werden. Wenn die richtigen Ressourcen zur richtigen Zeit am richtigen
Ort bereitgestellt werden, kann das Projekt reibungslos umgesetzt werden wie dieses
Beispiel (siehe Abb. 2.61) zeigt: In China wurde so der Bau einer neuen Bahnstrecke
in nur neun Stunden Bauzeit ermöglicht. ◄
92 2 Klassische Grundlagen: Es geht los…
Abb. 2.61 Bahnstreckenbau
in China
2.3.5 Kostenplanung
Die Kostenplanung zeigt die durch die Durchführung von dem Projekt entstehenden
Kosten. Die Planung der Kosten besteht aus zwei wesentlichen Bestandteilen:
1. Kostenschätzung
2. Kostenverlaufsplan
Kostenschätzung
Die Kostenschätzung kann in zwei Teilschritten durchgeführt werden:
Für eine verlässliche Ermittlung der entstehenden Kosten empfiehlt es sich zunächst,
die Arbeitspakete zu analysieren und daraus die zu berücksichtigenden Kostenarten zu
ermitteln. Die eingeplanten Ressourcen geben bereits erste Hinweise darauf, welche
Kostenart zu berücksichtigen ist. So sind für Mitarbeiter in aller Regel Personal-
kosten anzusetzen, im Detail wird es aber notwendig zu überprüfen, ob neben den Ver-
rechnungssätzen zusätzliche Kosten für Fortbildung oder Prämienzahlungen entstehen.
Weitere Beispiele sind in Tab. 2.13 zu finden.
Zu jeder Kostenart sind Kostensätze je Ressource und Einheit für die weitere
Berechnung der Kosten zu ermitteln, ebenso können Einmalkosten anfallen.Tab. 2.14
erhebt dabei keinen Anspruch auf Vollständigkeit insbesondere können die Kostenarten
bei anderen Projektarten andere sein.
Für die Verrechnungssätze muss zwingend geklärt werden, ob bereits Gemeinkosten
eingerechnet wurden, um später eine doppelte Berücksichtigung zu vermeiden. Bei
unternehmensinternen Verrechnungssätzen ist das oft der Fall.
jeweilige Kostenart bereits Gemeinkosten enthält oder Kosten ausschließlich direkt dem
Projekt zugeordnet werden können.
Sparkassenversicherung
Im darauffolgenden Schritt sind die Gemeinkosten zu ermitteln, die mittels eines Ver-
teilungsschlüssels den einzelnen Arbeitspaketen zugeordnet werden, sofern in den
angesetzten Verrechnungssätzen nicht bereits Gemeinkosten berücksichtigt wurden
(Tab. 2.15 und 2.16). Eine Struktur für die Schätzung der gesamten Projektkosten ist in
Abb. 2.62 dargestellt.
Im Ergebnis sind dann nicht nur die summierten, absoluten Kosten des Projekts
bekannt, sondern darüber hinaus die Kosten für jedes einzelne AP. Zusammen mit ihren
terminlichen Planungen können damit Kostenverlaufspläne erstellt werden.
Kostenverlaufsplan
Nachdem die Kosten näher bestimmt sind, werden diese in Form einer Grafik dargestellt.
Bei der Darstellung von Kostenverläufen werden regelmäßig zwei unterschiedliche Dar-
stellungsformen für den Kostenverlaufsplan angewandt:
1. Startphase
2. Analysephase
3. Synthesephase
4. Implementierungsphase
5. Einführung in Operativbetrieb
6. Kontrollphase
Mit der phasenweisen Darstellung der Kosten lässt sich übersichtlich darstellen, in
welchen Phasen die höchsten Kosten verursacht werden, dies ist in Abb. 2.63 dar-
gestellt. Aus der phasenweisen Darstellung kann die kumulierte Darstellung in Abb. 2.64
abgeleitet werden. Daraus gehen im Anschluss die gesamten Kosten zu jedem beliebigen
Zeitpunkt hervor.
Die durch das Projekt verursachten Kosten werden i. d. R. nicht in einer Summe,
sondern in Teilzahlungen beglichen. Häufig sind diese nach erfolgreichem Abschluss
zuvor gesetzter Meilensteine fällig. In Abb. 2.65 ist dargestellt, wie die kumulierte
Kostenkurve dazu genutzt werden kann, mögliche Unter- und Überdeckungen zu identi-
fizieren. Zu diesem Zweck wird die kumulierte Kostenkurve den Zahlungszeitpunkten/
Meilensteinen gegenübergestellt und der voraussichtliche Kapitalbedarf zu bestimmten
Zeitpunkten bestimmt.
Lehrvideos
Eine Vertiefung und Erläuterung zur Projektschätzung von Ressourcen und Kosten finden
Sie in den Videos Abb. 2.66, 2.67, 2.68, 2.69, 2.70, 2.71 und 2.72 des Videokurses.
2.3 Projektplanung 97
2500000
2000000
1500000
Kosten
1000000
500000
0
Zeit
Kosten Kumulierte Kosten
= Haftrücklass
Projektkostenverlauf
Zahlungsverlauf
Überdeckung = Finanzüberschuss
Unterdeckung = Finanzbedarf
Abb. 2.66 Einführung
Schätzungen
Abb. 2.69 Schätzverfahren
(https://doi.org/10.1007/000-
0rm)
Abb. 2.70 Schätzungen
großer und kleiner Stücke
Abb. 2.71 Parametrische
Schätzung (https://doi.
org/10.1007/000-0rp)
2.3.6 Risikoplanung
Die Planung eines Projektes basiert in der Regel auf Annahmen, von denen die ein
oder andere nichtzutreffend sein kann. Dazu kommen unerwartete Ereignisse, die die
Unsicherheit in einem Projekt weiter erhöhen. Um nicht zur Untätigkeit verdammt zu
sein, betrachtet ein vorausschauendes Projektmanagement im Vorfeld und während der
Projektdurchführung die damit verbundenen Risiken, um sich auf diese bestmöglich vor-
zubereiten. Das ist die Aufgabe des Risikomanagements.
100 2 Klassische Grundlagen: Es geht los…
Elbphilharmonie
Mit Blick auf mögliche Risikoursachen können die eigentlichen Risiken identifiziert
werden. Zu beachten ist, dass zwischen Ursache und Wirkung unterschieden werden
2.3 Projektplanung 101
muss. Z. B. sind steigende Lieferantenkosten eine Ursache für die Wirkung Budgetüber-
schreitung. Hinzu kommt, dass ein so spezifiziertes Projektrisiko weitaus genauer ist als
Budgetüberschreitung. Dies ermöglicht eine weitaus zielgerichtetere – und damit bessere
– Vorbereitung auf das Risiko.
Projektrisiko DIN 69901 definiert das Projektrisiko wie folgt: Ein Projektrisiko
beschreibt mögliche negative Abweichung im Projektverlauf (relevante Gefahren) gegen-
über der Projektplanung durch Eintreten von ungeplanten oder Nicht-Eintreten von
geplanten Ereignissen oder Umständen (Risikofaktoren). Mögliche Risikoarten sind
kaufmännische, technische, politische, terminliche, Ressourcen- und Umweltrisiken,
ferner die Ungenauigkeiten bei Schätzungen von Dauer und Aufwand. Ein Projektrisiko
wird quantifiziert als Produkt aus Schadenshöhe (Tragweite) und Eintrittswahrschein-
lichkeit des jeweiligen Risikofalls.
Bei der Überlegung, welche Risiken in einem Projekt auftreten können, hilft es daher,
sich die Frage zu stellen „Was kann plötzlich passieren?“, sodass die Projektziele
(Termine, Kosten, Kundenzufriedenheit, Funktionsumfang, etc.) gefährdet sein können.
Dies kann beispielsweise mit Blick auf die Arbeitspakete oder in den Vertrag geschehen,
Tab. 2.17 zeigt dazu einige Beispiele.
Weitere Risiken können sich aus Dokumenten ableiten lassen, z. B. Abschluss-
berichten von Projekten. Die Erfahrungen aus anderen Projekten können eine große
Hilfe bei der Identifizierung sein. Im Idealfall wurden die Risiken in Checklisten
zusammengestellt, ansonsten hilft ein Blick in die Projektdokumentation oder ein
Gespräch mit Projektleitungen ähnlicher Projekte.
Tab. 2.17 Beispiel Risikoidentifizierung
Risiko ID Quelle Risiko-beschreibung Risikokategorie mögliche Risiko-
ursachen
R1 PSP 1.2.4: Fest- Unzureichende Personal Kosteneinsparungs-
legung von Kenntnisse der Mit- maßnahmen
strategischen Zielen arbeiter
und Kundenseg-
menten
R2 PSP 2.1.2: Vertriebs- Programmierer Personal Abzug durch andere
koordination, Auf- werden vom Projekt Projekte
tragsabwicklung, abgezogen
R3 PSP 3.4.1: Rechnungen werden Finanzen Konkurs Kunde
Rechnungen nicht bezahlt
R4 Vertrag §4, Abs. 5: Lieferung verzögert Lieferant Geänderte
Vertragsklausel zur sich um mehr als Prioritäten,
Lieferung drei Wochen Ressourceneng-
pässe etc.
102 2 Klassische Grundlagen: Es geht los…
Risikoanalyse
Um die potenziellen Auswirkungen der Risiken zu prognostizieren, sind diese im
weiteren Verlauf genauer zu analysieren. Die Risikoanalyse unterscheidet eine
qualitative und quantitative Analyse der Risiken. Die qualitative Risikoanalyse ist im
Vergleich deutlich weniger aufwendig, andererseits aber auch weniger genau. In vielen
Projekten wird lediglich eine qualitative Risikoanalyse durchgeführt, ggf. wird eine
quantitative Risikoanalyse für einzelne, potenziell schwerwiegende Risiken ergänzt.
Beide Vorgehensweisen haben die Betrachtung von Eintrittswahrscheinlichkeit und
Schadenshöhe gemeinsam.
Im Falle der qualitativen Risikoanalyse erfolgt eine Einschätzung auf Basis grober
Abstufungen, z. B. sehr gering, gering, mittel, hoch, sehr hoch. In Tab. 2.18 ist die
qualitative Bewertung der Risiken dargestellt.
Die in der Tabelle identifizierten und analysierten Risiken sind in Abb. 2.73 graphisch
eingeordnet und ermöglichen so eine schnelle Einschätzung der Einzelrisiken, also auch
eine Einschätzung der gesamten Risikosituation.
In der Praxis wird oft so verfahren, dass zumindest ein Teil der Risiken nicht in die
quantitative Analyse einbezogen wird. Das Gesamtprojektrisiko wird in diesem Fall
grob auf Basis der Risikomatrix aus Abb. 2.73 eingeschätzt. Unter der Annahme, dass
die nicht entdeckten Risiken ähnlich verteilt sind, wie die entdeckten, wird das Gesamt-
projektrisiko höher eingeschätzt, wenn es viele identifizierte Risiken im oberen rechten
Bereich gibt. Entsprechend wird der Risikozuschlag höher ausfallen.
Statt einer qualitativen Bewertung kann die gleiche Bewertung quantitativ erfolgen.
Dies erfordert jedoch ungleich mehr Aufwand, wenn die Zahlen die Genauigkeit haben
sollen, die sie vermitteln. Für die Ermittlung von Prozentzahlen sind beispielsweise lang-
wierige statistische Erhebungen durchzuführen. Versicherungen, die jahrelang Daten zu
ihren Versicherungen gesammelt haben, können so recht genaue Wahrscheinlichkeiten
angeben.
Abb. 2.73 Qualitative
Risikobewertung
Beispiel
Zur Ermittlung des Schadens, den ein 18-Jähriger bei einem Autounfall verursacht,
sind aufwendige Schätzungen notwendig. Zunächst muss ermittelt werden, welcher
Schaden eintreten kann (Totalschaden des Autos, ca. zwei Verletzte mit Schmerzens-
geld etc.) im Anschluss ist ein Schätzwert zu ermitteln. Für das Beispiel kann über-
legt werden, ob eher ein Porsche oder Smart gefahren wurde, für die Verletzungen
und den Schadenersatz wird geschätzt, welche Verletzungen vermutlich vorliegen, ob
noch Gerichts- und Anwaltskosten einkalkuliert werden müssen und wie hoch diese
voraussichtlich werden. ◄
Erkennbar ist eine solche quantitative Risikoanalyse mit sehr viel mehr Aufwand ver-
bunden, als eine qualitative Einschätzung, die sowohl Eintrittswahrscheinlichkeit als
auch Schadenshöhe in Kategorien gering,mittel,hoch angeben würde. In Tab. 2.19 erfolgt
eine quantitative Bewertung der Risiken.
Auf Basis der quantitativen Risikoanalyse der Einzelprojektrisiken, kann nun die
Tragweite als Erwartungswert eines jeden Einzelprojektrisikos als Produkt aus Eintritts-
wahrscheinlichkeit und Schadenshöhe berechnet werden die Berechnung ist in Gl. 2.7
dargestellt.
Tragweite = Eintrittswahrscheinlichkeit × Schadenshöhe. (2.7)
104 2 Klassische Grundlagen: Es geht los…
Mit den so ermittelten Tragweiten der Einzelrisiken ist die Basis für die Bestimmung des
Gesamtprojektrisikos gelegt.
werden. Die Beispiele haben sich auf den häufigeren Fall der negativen Ereignisse
konzentriert, die Formeln sind identisch verwendbar.
Teilweise sind die Maßnahmen für die positiven und negativen Risiken unterschiedlich
es gibt aber auch Maßnahmen, die für beide Risikoarten nutzbar sind. Eine Übersicht der
Maßnahmen und ihrer Anwendbarkeit ist in Tab. 2.21 dargestellt.
Während die gemeinsamen Strategien in gleicher Form für negative und positive
Risiken angewendet werden können, zielen die Strategien für negative Risiken auf eine
Verringerung des Risikos, die Strategien für positive Risiken in das Gegenteil, eine
Erhöhung des Risikos. Da der zugrundeliegende Weg aber ähnlich ist, werden diese im
Folgenden gemeinsam beschrieben.
Akzeptanz
Im Projekt werden nicht alle Risiken behandelt werden können, daher werden die
kleinen Risiken in der Regel akzeptiert. D. h. man ist sich der Risiken bewusst, ent-
scheidet sich aber ebenso bewusst, nichts dagegen zu unternehmen.
Risikozuschlag
Es gibt akzeptierte Risiken und nicht entdeckte Risiken. Beides ist Grundlage für die
Bestimmung eines Risikozuschlages. Man nimmt dabei an, dass dort, wo viele Risiken
gefunden wurden auch viele unentdeckte Risiken lauern. Sind beispielsweise bereits
Tab. 2.21 Übersicht Risikomaßnahmen
Gemeinsame Strategien Strategien für negative Risiken Strategien für positive Risiken
Akzeptanz Risikominderung Risikoverbesserung
Risikozuschlag Risikovermeidung Risikonutzung
Alternativenplanung Risikotransfer Risikoteilung
106 2 Klassische Grundlagen: Es geht los…
viele kritische Risiken gefunden worden, in Abb. 2.73 im dunklen Bereich oben rechts,
kann im Extremfall durchaus ein Zuschlag von 100 % für das Risikomanagement vor-
gesehen werden. Entsprechend gering fällt er aus, wenn wenig bis gar keine Risiken dort
zu finden sind, sondern der Schwerpunkt der Risiken im unteren linken Bereich liegt. In
dem Fall wird oft ein pauschaler Zuschlag von 5 % gewählt. Üblicherweise liegen die
Zuschläge für das Risikomanagement bei ca. 5–10 %.
Alternativenplanung
Die Alternativenplanung kann sowohl präventiv als auch reaktiv angelegt sein. Die
Grundidee ist, sich eine Maßnahme für den Fall des Eintritts des Risikos zu überlegen,
der dann einfach abgearbeitet werden kann. Dies verhindert hektische, unüberlegte
und damit oft fehlerhafte Reaktionen. Zusätzlich können sogenannte Trigger verein-
bart werden, die anzeigen, dass das betrachtete Risiko eintreten wird. Das Eintreten der
Trigger stößt die Ausführung des Alternativplanes an.
Risikominderung/Risikoverbesserung
Im Rahmen der Risikominderung werden Maßnahmen definiert, die präventiv die Ein-
trittswahrscheinlichkeit und/oder die Schadenshöhe verringern können. Für die Risiko-
verbesserung wird im Gegenteil angestrebt, Eintrittswahrscheinlichkeit und/oder
Schadenshöhe zu erhöhen.
Risikovermeidung/Risikonutzung
Die Risikovermeidung wird – in der Regel durch Planänderungen – das Eintreten eins
Risikos vollständig verhindern. Das ist nicht für alle Risiken möglich und oft auch nicht
sinnvoll, da durch den geänderten Plan zusätzliche Risiken auftreten können oder identi-
fizierte Risiken verschlimmert werden können. Ähnliches gilt für die Risikonutzung, die
die Eintrittswahrscheinlichkeit auf 100 % erhöhen soll.
Tab. 2.22 Risikobeispiele
Risiko Konsequenzen Maßnahmen
Schlechtwetter: Stillstrand der Baustelle, Bei Schnee: Überdachung
Schnee Terminverzögerung, Pönale …
… …
Personal: Schlechter Baufortschritt Motivations-, Führungs-
Krankenstände Schlechte Qualität schulung für Polier
Fluktuation … Prioritäten zwischen Objekten
… setzen
…
Sublieferanten: Zeitliche Verzögerung Entsprechende Vertrags-
Konkurs Qualitative Mängel gestaltung
… … …
Behörden: Stillstand der Baustelle Rechtzeitige Kontaktaufnahme
Unerwartete Forderungen der Verschmutzung im Wasser- Einhaltung aller Vorschriften
Wasserrechtsbehörde und des schutzgebiet und Bedingungen bei
Arbeitsinspektorats … Zulieferern
… …
Lehrvideos
Eine Vertiefung und Erläuterung zum Risikomanagement finden Sie in den Videos
Abb. 2.74, 2.75, 2.76, 2.77 und 2.78 des Videokurses.
Abb. 2.75 Definition
von Risiken (https://doi.
org/10.1007/000-0rs)
108 2 Klassische Grundlagen: Es geht los…
Kontrollfragen
1. Welche möglichen Aufgaben übernimmt ein Projektstrukturplan?
2. Welche Rolle spielen Arbeitspakete in einem Projektstrukturplan?
3. Warum sind Meilensteine bei der Terminplanung von Vorteil?
4. Was versteht man unter der gesamten Pufferzeit?
5. Welche Vorgehensweise ist bei einer Kapazitäten Planung üblich?
6. Welche Kostenarten fallen in Projekten an?
7. Welche möglichen Risiken sind bei einer Risikoplanung zu berücksichtigen?
2.4 Projektsteuerung 109
2.4 Projektsteuerung
Lernziele
Sie wissen, was Projektüberwachung bedeutet.
Sie können sinnvolle Kennzahlen zur Projektkontrolle festlegen.
Sie kennen Maßnahmen zur Projektsteuerung.
Sie können eine Fertigstellungswertanalyse durchführen.
2.4.1 Zielsetzung
Der Begriff der Projektsteuerung mit Abgrenzung zu den Begriffen der Projektüber-
wachung und des Projektkontrolle ist in der Literatur nicht eindeutig definiert. Zunächst
einmal wird mit der Steuerung die Projektmanagementphase (Abschn. 1.4.1) bezeichnet.
Hier wird sich detaillierter an der Abb. 1.5 orientiert und daraus eine eigene Definition
für die Projektsteuerung in Anlehnung an die DIN 69901 abgeleitet.
Oberstes Ziel bei der Steuerung von Projekten ist die Erreichung der definierten
Projektziele, d. h. im Kostenrahmen, mit eingehaltenen Terminen den zugesicherten
Funktionsumfang des Projektes fertig zu stellen.
Abb. 2.79 Organisation
von Projekten/Prinzip der
Projektsteuerung [2]
Projektsteuerung kann entsprechend in folgende Schritte aufgeteilt werden und fußt auf
der Festlegung der Basispläne als Sollwertgeber.
Ist die Planung des Projektes abgeschlossen und sind der Lenkungsausschuss oder
weitere entscheidungsrelevante Stakeholder damit einverstanden, werden die gefertigten
Pläne als Basispläne des Projektes festgeschrieben. Diese fassen
Schon zum Projektbeginn sollten die Zeiten für die Ermittlung des Projektstatus festgelegt
werden. In den meisten Fällen wird eine wöchentliche Datenerfassung durchgeführt. Oft
werden die geleisteten Arbeitsstunden pro Arbeitspaket am Ende der Arbeitswoche von
den Projektmitarbeitern in dafür erstellte Arbeitszeiterfassungssysteme eingetragen und
im Rahmen von Teamsitzungen zum Status und zu den anliegenden Aufgaben der Woche
durchgeführt. Je nach Dauer und Größe der Arbeitspakete werden die Statusmeetings
im Team auch in größeren Abständen durchgeführt. Da die Kommunikation und Team-
bildung in virtuellen Teams deutlich schwieriger ist, wird zu einer mindestens wöchent-
lichen virtuellen Sitzung geraten. Die zwischenmenschlichen Aspekte der Teamarbeit
werden in Abb. 2.87 behandelt. Zur umfangreichen Kommunikation sind verschiedene
Arten von Teambesprechungen denkbar, wie in Tab. 2.23 dargestellt wird.
Die Ergebnisse der Sitzungen sind immer zu protokollieren, um im Nachgang eine
Referenz zu den besprochenen Punkten zu haben.
Die in dem aktuellen Projekt zu erhebenden Daten sind je nach Bedarf und Frage-
stellung unterschiedlich. Oft werden keine Arbeitsstunden erfasst, z. B. wenn ein Team
dem Projekt Vollzeit und über die gesamte Projektlaufzeit hinweg zur Verfügung steht,
oder wenn seitens des Betriebsrates Bedenken bestehen, die Arbeitsstunden personen-
bezogen zu erfassen. Wenn es sich um ein internes Projekt mit internen Ressourcen
handelt, werden andererseits oft die durch die geleistete Arbeit entstehenden Kosten nicht
erhoben. Um eine realistische Einschätzung des Projektstatus vornehmen zu können, kann
eine sinnvolle Auswahl der folgenden Kennzahlen im Projektverlauf erhoben werden:
• Arbeitsstunden,
• Kosten,
• %-fertig,
• Anzahl fertiger Arbeitspakete,
112 2 Klassische Grundlagen: Es geht los…
• Risikosituation: Sind Risiken eingetreten, gibt es neue Risiken oder müssen Identi-
fizierte neu bewertet werden?
• Änderungen: Welche Änderungswünsche sind aufgetaucht?
• Probleme: Welche Probleme mussten oder müssen gelöst werden?
• Teamstimmung: Ist das Team noch motiviert, hat etwas gefehlt, kann unterstützt
werden?
• Stimmung der Stakeholder: Sind die Stakeholder noch zufrieden mit dem Projekt,
welche positiven und negativen Rückmeldungen gibt es?
All diese Informationen sind die Grundlage für die Bewertung des Projektstatus.
Auf Basis der Pläne und der aktuellen Daten kann durch Vergleich festgestellt werden,
wie weit das Projekt fortgeschritten ist, z. B. durch prozentuale Ermittlung der ver-
brauchten Ressourcen:
2.4 Projektsteuerung 113
aktueller Wer
Fortschritt = ∗ 100 (2.9)
gesamter Basisplanwert
Wenn beispielsweise 1000 h für ein Projekt eingeplant wurden und bereits 100 h
abgearbeitet wurden, ist der Fortschritt bezüglich der Arbeit 10 %.
Dieser Aspekt allein genügt für eine Einschätzung des Projektstatus nicht, dafür muss
ein Vergleich von Plandaten mit den aktuellen Daten vorgenommen werden. Bezogen auf
das oben genannte Beispiel ist die Situation, dass zum Stichtag 10 % der Arbeit erledigt
wurde und dies mit dem Fortschrittsgrad, der zu diesem Zeitpunkt erreicht werden sollte,
verglichen wird:
• bei einem geplanten Fortschritt von 20 % sind wir deutlich in Verzug,
• bei einem geplanten Fortschritt von 5 % sind wir vor dem Zeitplan
• perfekt ist eine Übereinstimmung, d. h. es wurde zum aktuellen Stichtag ein Fort-
schritt von 10 % geplant. Weder wurde zu optimistisch geplant, noch wurden die
Arbeiten verzögert.
Diese Überlegung kann auf die weiteren zu erfassenden Kennzahlen angewandt werden,
siehe Abschn. 2.4.2. Und sie muss andererseits für weitere Kennzahlen umgesetzt
werden, da eine einzige Kennzahl unter Umständen kein korrektes Bild des Projektstatus
zeichnet. Dies wird in Abb. 2.81 verdeutlicht.
Betrachten wir den Planverlauf der Kostenkurve in Abb. 2.81, so sieht es nach einem
effizienten Projekt aus, da die aktuellen Kosten die geplanten Kosten unterschreiten.
Zieht man die Arbeitsstunden hinzu, so ergibt sich ein anderes Bild: die geringen Kosten
sind durch eine deutliche Verzögerung der Arbeiten erzielt worden. Damit ist der gute
Projektstatus nicht mehr gegeben.
Für jede Abweichung muss deren Ursache ermittelt werden. Diese Ermittlung ist Voraus-
setzung für die Auswahl geeigneter Steuerungsmaßnahmen. Bei der Analyse werden
häufig Ursache und Wirkung verwechselt. So sind z. B. Kosten- und Terminüber-
schneidungen immer die Folge tiefer liegender Ursachen, wie z. B. von Planungsfehlern,
Ausführungsfehlern oder Änderungen der Rahmenbedingungen. Diese Ursachen können
– wie in Abb. 2.82 dargestellt- weiter untergliedert werden und ermöglichen damit ziel-
gerichtete Maßnahmen.
In der Praxis ergeben sich häufiger Soll-Ist-Abweichungen, weil z. B. vom Auf-
traggeber oder vom Linienmanagement Termine so festgelegt werden, dass sie einer
„ernsthaften“ Planung nicht standhalten. Für die Projektplanung und die spätere
Abweichungsanalyse ist es daher einerseits notwendig, alle relevanten Annahmen und
Rahmenbedingungen festzuhalten, andererseits für realistische Planungen einzustehen.
114 2 Klassische Grundlagen: Es geht los…
Abweichungen
Ursache
Änderung der
Ausführungs-
Planungsfehler Rahmen-
fehler
bedingungen
Mitarbeiter- Leistungs-
Bei Tätigkeiten
führung änderung
Verspätete Kündigungen,
Disposition Krankheiten
Veränderte
Prioritäten
Abb. 2.82 Abweichungsursachen
2.4 Projektsteuerung 115
Kostenabweichung
Die Kostenabweichung entsteht durch eine Abweichung, die dadurch begründet ist, dass
die tatsächlich angefallenen Kosten nicht den geplanten Kosten entsprechen. Ursachen
können beispielsweise die während des Projektverlaufs im Preis gestiegenen Rohstoff-
preise sein, die zwingend für das Projekt benötigt werden und nicht anderweitig in der
Risikoplanung (siehe Abschn. 2.3.5), abgesichert sind.
Produktivitätsabweichung
Die Abweichung bei der Produktivität, die oftmals durch den Fertigstellungsgrad der
Arbeitspakete zu einem bestimmten Zeitpunkt gemessen werden, können sich durch
Krankheiten oder Ersatz des Experten durch Anfänger ergeben haben.
Leistungsabweichung
Ähnlich wie bei der Produktivitätsabweichung kann auch die Leistungsabweichung
durch Krankheiten oder Ersatz des Experten durch Anfänger verursacht sein. Gemessen
wird die Leistungsabweichung z. B. durch die Anzahl der erreichten und geplanten
Meilensteine.
Es ist sehr unwahrscheinlich, dass während des Projektverlaufes exakt die geplanten
Kenngrößen eingehalten werden, eine gewisse Schwankung ist normal und akzeptabel.
Die Akzeptanz dieser Schwankungsbreiten hängt zum einen von möglichen Vorgaben ab
und zum anderen von deren Bedeutung für die betroffenen Projektziele. Generell kann
festgehalten werden, dass Schwankungsbreiten von 5–10 % durchaus vertretbar sind, da
selbst eine genaue Schätzung eine Abweichung in diesem Rahmen mitbringt. Ist jedoch
der Termin fixiert, beispielsweise der Start einer Messe, auf der das neue Produkt vor-
gestellt werden muss, so ist eine Abweichung von einem Tag nicht mehr akzeptabel,
selbst wenn diese Abweichung formal weniger als 5 % umfasst.
116 2 Klassische Grundlagen: Es geht los…
In der Praxis findet man fast immer eine plakative Einschätzung des Projektstatus
in den drei Farben grün, gelb oder rot vor. Oft ist diese Statusampel nicht nur für das
Gesamtprojekt angegeben, sondern für die Eckpunkte des magischen Dreiecks oder
weiterer Zielgrößen. Generell ist im Vorfeld eine Abstimmung darüber, was genau die
Farben bedeuten, anzuraten. Als Daumenregel und Diskussionsgrundlage kann die
Tab. 2.24 verwendet werden.
Es ist wichtig, dass für die Gesamtbewertung des Projektstatus nicht nur die
erhobenen Kennzahlen, sondern auch die weicheren Faktoren, wie Risiken, Änderungen
etc. berücksichtigt werden.
Trendanalyse
Der Blick in die Vergangenheit des Projektes, der mit der Erfassung der aktuellen Daten
und deren Bewertung stattgefunden hat, ist für eine vorausschauende Steuerung des
Projektes allein jedoch nicht sinnvoll.
Für die Terminsituation im Projekt wird gerne die Meilensteintrendanalyse genutzt.
In der Abb. 2.83 sind auf der vertikalen Achse die prognostizierten Meilensteintermine
der Meilensteine des Projektes von unten nach oben dargestellt, auf der horizontalen
Achse die Zeitpunkte, zu denen die Meilensteine analysiert und gegebenenfalls neu
prognostiziert werden. Die Meilensteintermine werden möglichst im Projektteam zum
jeweiligen Berichtszeitpunkt unter Berücksichtigung der aktuellen Situation eingeschätzt
und in das Chart eingetragen.
• Die Meilensteintermine werden am 1.1. (erste Spalte) auf den 1.3., den 1.8. und den
1.10 geschätzt,
• das Treffen am 1.3 (dritte Spalte) ergibt die prognostizierten Meilensteintermine 1.5.,
1.7. und 1.10
• das Treffen am 1.5 (fünfte Spalte) ergibt die prognostizierten Meilensteintermine 1.5.
(der nun auch erreicht wurde), 1.6. und 1.10
• etc.
Abb. 2.83 Meilensteintrendanalyse
Steigt die gedachte Verbindungslinie nach oben, liegt eine Terminverzögerung vor, dar-
gestellt in der unteren Verlaufslinie. Die mittlere Verlaufslinie zeigt eine beschleunigte
Abarbeitung des Meilensteines und die oberste Linie eine planmäßige Bearbeitung.
Durch die Visualisierung des Terminverlaufs der Meilensteine werden allen
Stakeholdern die Terminverzögerungen vor Augen geführt und es wird deutlich ob
Steuerungsmaßnahmen notwendig sind.
Neben dem Verlauf der einzelnen Terminverläufe kann auch das Gesamtbild inter-
pretiert werden. So lässt eine stete Verschiebung aller Meilensteine nach oben auf wenig
bis keine Projektsteuerung schließen. Wird ein Terminverlauf lange nach Verzögerung
früherer Meilensteine nach oben korrigiert, ist eine wenig vorausschauende Projekt-
steuerung zu vermuten.
Auf Basis der Statusdaten und damit ggf. identifizierter Abweichungen, können im
Anschluss entsprechende Maßnahmen geplant werden. In Tab. 2.25 sind mögliche
Gegenmaßnahmen bei Terminverzug aufgezeigt.
118 2 Klassische Grundlagen: Es geht los…
Abhängig von den Befugnissen der Projektleitung können die Maßnahmen unmittel-
bar eingeleitet werden oder zunächst von einem Änderungsgremium genehmigt werden.
Für den letzten Fall ist es sinnvoll, mehrere Vorschläge zu entwickeln, die Vorteile und
Nachteile darzustellen und eine begründete Handlungsempfehlung abzugeben. Auf diese
Weise kann eine sachgerechte Entscheidung gut vorbereitet werden und die Projekt-
leitung erscheint angesichts zu lösender Probleme im Projekt nicht hilflos.
Sind die geplanten Maßnahmen genehmigt, sind die Pläne entsprechend anzupassen.
2.4.6 Fertigstellungswertanalyse
Grundlage für die Fertigstellungswertanalyseoder Earned Value Analyse ist die Kosten-
ermittlung der Arbeitspakete, denkbar sind auch andere, vergleichbare Größen. Die Ana-
lyse befasst sich mit den in genannten Schritten und strebt eine objektive, quantitative
Bewertung des Projektes an, die den Status des Projektes in wenigen Kennzahlen
zusammenfasst. Das Vorgehen soll anhand der genannten Schritte näher erläutert
werden. Das in Tab. 2.26 dargestellte Projekt wird als Beispiel herangezogen. Aufgeführt
ist die Gesamtplanung für das Projekt, sowie der geplante Fertigstellungsgrad zum 31.
März, dem Statusdatum. Alle Vorgänge, die erst nach dem Statusdatum starten, haben
zum aktuellen Zeitpunkt entsprechend einen Fertigstellungsgrad von 0 %.
2.4 Projektsteuerung 119
Tab. 2.26 Beispiel Fertigstellungswertanalyse
Vorgang Geplanter Fertig- € Tsd. geplante € Tsd. geplante Geplanter Fertig-
stellungstermin Kosten Kosten, kumuliert stellungsgrad
Konsortium 31. Jan 4 4 100 %
bilden
Vorbereitungen 28. Feb 6 10 100 %
Werbung 31. Marz 10 20 100 %
Umsetzung 1. 30. Jun 30 50 0 %
Entwurf
Umsetzung Ver- 31. Aug 26 76 0 %
feinerung
Initialförderung 31. Okt 20 96 0 %
aufsetzen
Abschlussver- 30. Nov 2 98 0 %
anstaltung
Abschluss- 31. Dez 2 100 0 %
kommunikation
100
80
60
40
20
ableiten, ob das Projekt hinter dem Plan ist oder nicht. Im ersten Fall ist die Abweichung
kleiner null, im zweiten größer als null. Interessant ist in diesem Zusammenhang die
Kostenabweichung. Während in der herkömmlichen Kostensteuerung lediglich die
Ist-Kosten mit den geplanten Kosten verglichen werden, gibt es im Rahmen der Fertig-
stellungswertanalyse die Möglichkeit, den Ist-Kosten die dafür erwirtschaftete Leistung in
Form des Fertigstellungswertes gegenüberzustellen. Dies lässt weitaus gehaltvollere Aus-
sagen zu.
Für das Beispiel bedeutet dies konkret zum 31. März:
Kostenabweichung = 18 Tsd. C − 25 Tsd. C = −7 Tsd. C (2.10)
Akzeptabel sind Werte um 0,95, wobei bei sehr neuartigen Projekten auch ein Wert
von 0,9 als grün bewertet werden kann.
Die Kennwerte, ihre Berechnung und die Schlussfolgerungen für die Projekt-
bewertung sind in der Tab. 2.28 zusammengefasst.
Aus den ermittelten Statusdaten kann im nächsten Schritt eine Prognose für das
Projekt abgeleitet werden. Während im Rahmen der Zeitplanung die besten Prognosen
aufgrund des kritischen Pfades entwickelt werden können, steht im Rahmen der Fertig-
stellungswertanalyse der Kostenentwicklungsindex zur Verfügung. Die Berechnung
fußt auf der Annahme und Erfahrung aus vielen Projekten, dass nach ca. 20–25 % der
Projektlaufzeit keine gravierenden Schwankungen des Kostenentwicklungsindex zu
beobachten sein werden. Auf dieser Basis können die erwartete Gesamtkosten bei Fertig-
stellung recht einfach berechnet werden:
Erwartete Gesamtkosten bei Fertigstellung = Geplante Gesamtkosten/Kostenent-
wicklungsindex.
In der Abb. 2.86 sind alle ermittelten Kennwerte zusammengestellt. Man kann gut
erkennen, dass die Kosten zwar unter den geplanten Kosten bleiben, andererseits der
Fertigstellungswert ebenfalls unter dem geplanten Wert liegt, sogar unter den Ist-kosten.
Damit wird der Rückstand des Projektes bezüglich Terminplan als auch Kosten deutlich.
Die Fortführung des Projektes wird dann auch folgerichtig zu erhöhten erwarteten
Gesamtkosten bei Fertigstellung führen.
Für das Beispiel bedeutet dies konkret bis zum Ende des Projektes:
Erwartete Gesamtkosten bei Fertigstellung: 100 Tsd. C ÷ 0,72 ≈ 129 Tsd. C (2.14)
Analyse der Abweichungen
Die genannten Kennzahlen können für die Ermittlung einer Prognose herangezogen
werden, die umso genauer wird, je genauer die Ursachen für die Abweichungen
bekannt sind. Im vorherigen Kapitel wurde ohne Ursachenanalyse, lediglich aufgrund
statistischer Erfahrungen, eine gleichbleibende Kostensituation angenommen, die im
Kostenentwicklungsindex festgehalten wurde.
2.4 Projektsteuerung 123
In einem Projekt können jedoch zu Beginn z. B. größere Risiken eintreten, die einen
sehr viel schlechteren Kostenentwicklungsindex bedingen. Auf diesem eine Schätzung
für den Restverlauf des Projektes abzuleiten, wäre grob fahrlässig, wenn für den Rest-
verlauf eine Abwicklung gemäß Plan angenommen werden kann. In diesem Fall würden
die erwarteten Gesamtkosten bei Fertigstellung die aktuellen Kosten berücksichtigen,
für den übrigen Verlauf aber die geplanten restlichen Kosten für die fertigzustellenden
Arbeitspakete ansetzen:
Erwartete Gesamtkosten bei Fertigstellung =
Ist-Kosten + (Geplante Gesamtkosten-Fertigstellungswert).
Für das Beispiel bedeutet dies konkret bis zum Ende des Projektes:
Erwartete Gesamtkosten bei Fertigstellung = 25 Tsd. C+ 100 Tsd. C − 18 Tsd. C = 107 Tsd. C
(2.15)
Neben den vorgestellten Prozessen und Vorgehen ist die persönliche Seite der Team-
mitglieder im Auge zu behalten. Hier soll dazu ein etwas humorvoller, aber durch-
aus treffsicherer Blick auf verschiedene Typen im Projektgeschehen geworfen werden.
Abb. 2.87 zeigt Analogien ins Tierreich und die körpersprachlichen Ausdrucksformen.
124 2 Klassische Grundlagen: Es geht los…
Alle Beteiligten zeigen Verhaltensweisen, die in einer Besprechung störend als auch
positiv wirken können. Es ist generell wichtig, einer Übertreibung der Verhaltensweisen
entgegenzuwirken, um deren konstruktiven Beitrag nutzen zu können. Ebenfalls ist zu
beachten, dass durch diese Verhaltensweisen grundlegende Bedürfnisse zum Ausdruck
gebracht werden, deren strikte Ignoranz die Teammitglieder nicht zur konstruktiven Mit-
arbeit zu motiviert.
Streitsüchtiger
Dieser Typus wird als jemand beschrieben, der Konflikten nicht aus dem Weg geht. Dies
ermöglicht eine breite Betrachtung des Diskussionsgegenstandes und ist sehr geeignet,
um Gruppendruck und unausgereifte Entscheidungen zu vermeiden. Die vom Streit-
süchtigen vorgebrachten Punkte können gut an die Gruppe zur Diskussion weitergegeben
werden, es ist aber auf eine maßvolle Streitkultur zu achten.
Positiver
Der Positive zeigt ein großes Interesse an dem harmonischen Miteinander im Team und
hat entsprechend oft das Gemeinsame im Blick. Wenn Konflikte zu eskalieren drohen,
sind diese Typen sehr gut geeignet, um die Wogen durch den Blick auf die gemeinsamen
Ziele und Überzeugungen zu glätten. Dazu sollten sie aktiv in die Diskussion mit ein-
bezogen werden.
2.4 Projektsteuerung 125
Redseliger
Der Redselige gehört ebenso wie Alleswisser und Streitsüchtiger zu denjenigen, die
keinerlei Scheu haben, in der Gruppe zu sprechen und ihre Gedanken im Gespräch
weiter zu entwickeln. Damit ist ein Einbezug aller in den Entwicklungsprozess möglich,
was gerade in Anfangssituationen das Eis bricht. Seitens der Moderation muss darauf
geachtet werden, dass die anderen Teammitglieder sich dadurch nicht mental aus der
Diskussion herausziehen.
Schüchterner
Schüchterne werden im Team oft übersehen oder ihre Meinungen werden nicht wahr-
genommen, da sie zurückhaltend agieren und oft leise sind. Sie hören gut zu und denken
mit, die Ideen und Gedanken werden im Gegensatz zum Redseligen nicht gemeinsam,
sondern allein weitergedacht. Eine direkte Ansprache fördert dieses wertvolle Gedanken-
gut zu Tage.
Ablehnender
Die kritischen Denker in der Runde sind die Ablehnenden. Sie bewahren, ähnlich wie
der Streitsüchtige, vor Fehlschlüssen und Fehlern und verdienen dafür Anerkennung.
Zuviel kritisches Denken wird durch Ausbleiben von Anerkennung hervorgerufen oder
die Anerkennung wird nicht wahrgenommen.
Uninteressierter
Der Uninteressierte kann zur eigenen Reflektion anregen. Ebenfalls ist es möglich, dass
mit der zur Schau gestellten Uninteressiertheit andere Ziele verfolgt werden, die im
Rahmen der Stakeholderanalyse (siehe Abschn. 2.1.4) untersucht werden sollten.
Erhabener
Der Erhabene, der tatsächlich Einfluss hat, kann für eine schnelle und zuverlässige Ent-
scheidungsfindung und -umsetzung von großem Wert sein. Das sollte nicht zur Ein-
räumung von Sonderrechten verleiten oder zur Zurückweisung von entgegengesetzten
Beiträgen. Hier muss in diplomatischer Weise ggf. eine direkte Ansprache des Streit-
süchtigen in eine diplomatischere Form, z. B. ein „Ja-Aber“, gebracht werden. Dann
können die Vorteile dieses Verhaltens dauerhaft genutzt werden. Es empfiehlt sich
126 2 Klassische Grundlagen: Es geht los…
ebenfalls, die Zusagen in den weiteren Treffen zu überprüfen und Lösungen für auf-
tauchende Schwierigkeiten zu suchen.
Ausfrager
Der Ausfrager ist ein wissbegieriger Projektteilnehmer. In Anerkennung dessen ist ein
Ausfrager, der sich Notizen macht, für alle wertvoll, denn die Notizen können von allen
genutzt werden. Gestellte Fragen können die Selbstreflektion anregen und ggf. Lücken
aufdecken. Wie immer ist es wichtig, Übertreibungen zu verhindern.
2.4.8 Eskalationsmanagement
In Projekten bleiben Konflikte oft systembedingt nicht aus, da das Projekt eine weitere
zusätzliche Organisationseinheit im Unternehmen bedeutet und oft Ressourcen anderer
Bereiche beansprucht. Einige der Konflikte oder Herausforderungen können intern gelöst
werden, für die, bei denen Entscheidungen außerhalb der Befugnisse des Projektes zu
treffen sind, ist das Eskalationsmanagement vorgesehen. Dies kann beispielsweise der
Fall sein, wenn Entscheidungen das Budget überschreiten würden, oder der Projekt-
umfang geändert werden müsste.
Eine frühzeitige Definition und Einrichtung des Eskalationsmanagements beginnt
mit den sogenannten Eskalationsstufen, wie z. B. in Abb. 2.88 dargestellt. Um diese
jedoch effizient managen zu können, ist es von hoher Bedeutung, jede Eskalation zu
dokumentieren:
• Initiator,
• Beschreibung des Dissens,
• betroffene Bereiche und mögliche Auswirkungen,
• Darstellung aus Sicht der Gegenposition,
• Lösungsalternativen (Ziel, Inhalt, Ergebnis, Bewertungskriterien) und
• Entscheidungsbedarf formulieren.
Kontrollfragen
1. Was bedeutet Projektüberwachung?
2. Welche Kennzahlen zur Projektkontrolle gibt es?
3. Welche Maßnahmenkategorien zur Projektsteuerung gibt es?
4. Welche Kennzahlen können mit der Fertigstellungswertanalyse ermittelt werden?
5. Wofür ist eine Fertigstellungswertanalyse nützlich?
2.5 Projektreporting
Lernziele
Sie können die Bedeutung des Projektreportings erläutern.
Sie haben eine Systematik zur Organisation der Projektdokumente.
Sie kennen die unterschiedlichen Dokumentarten.
Sie können einen Statusbericht aufstellen.
Werden Dokumente falsch abgelegt, kann es sehr teuer werden oder im Extremfall zu
gerichtlichen Auseinandersetzungen führen. Dies zeigt das Beispiel des verschwundenen
Aufnahmeantrages von Andreas Kalbitz [18].
Andreas Kalbitz
• Prozessbeschreibungen,
• Projektpläne und
• Projektberichte.
Allen Dokumenten ist die Anforderung gemeinsam, dass der Inhalt vollständig ist sowie
gelesen und verstanden wird. Für die Ersteller wie Nutzer ist es eine große Hilfe, wenn
die Informationen auf das Wesentliche beschränkt bleiben. Dabei helfen vordefinierte
Vorlagen, wie sie auch hier im Buch zu finden sind. So wird nichts Wesentliches ver-
gessen und wenn die Vorlagen aus einem unternehmensweiten Standard stammen, ist
das Erfassen in der schon gewohnten Struktur sehr erleichtert. Trotz aller Standards ist
auf die Zielgruppe zu achten und diese bei der Erstellung der Dokumente zu berück-
sichtigen. Die Verständlichkeit wird durch grafische Darstellungen von z. B. Abläufen
unterstützt. Im Projektmanagementprozess Definition wird (vorbehaltlich späterer
Änderungen) festgelegt,
jeweils in Abhängigkeit von den ausgewählten und zu nutzenden Prozessen. Für den
späteren Rückgriff auf diese Informationen werden die getroffenen Entscheidungen
bzgl. der verwendeten Prozesse, erstellten Pläne und erzeugten Berichte im Projekt-
managementhandbuch festgehalten. Dadurch soll es dem Projektteam ermöglicht
werden, ohne eine häufig zeitaufwendige Gestaltung und Formatierung eine solche Ana-
lyse für das eigene Projekt durchzuführen. In Abb. 2.89 ist dieser Prozess dargestellt.
Im Unternehmen selbst existieren vordefinierte und teilweise vorgeschriebene Prozesse,
z. B. für die Produktentwicklung. Viele Unternehmen definieren ebenfalls das Projekt-
management, welches die Grundlage für das Projektmanagement des individuellen
Projektes bildet. Der Projektleiter legt im Projektmanagementprozess Definition mit
seinem Team die für das Projekt wichtigen Prozesse fest, definiert diese und hält
die Ergebnisse im Projektmanagementhandbuch fest. Aufbauend auf den definierten
Prozessen, werden Pläne aufgestellt. Beispielsweise resultiert aus dem Prozess „Auf-
gabenplanung“ der Projektplan. Im Laufe des Projektes wird z. B. eine regelmäßige
Statusberichterstattung erwartet, die zu vielen weiteren Berichten führt.
2.5.2 Prozessbeschreibungen
Prozesse
Berichte
Änderungsstelle
Antragssteller: (Konfigurationsstelle):
Änderungsantrag schreiben Registratur und
formale Überprüfung Ja
Betroffene Stellen:
Bewertung und Genehmigung
Stellungnahme und
Überprüfung Antrag
ändern?
Änderungskonferenz
Nein
Nein
Änderung Ablehnung
durchführen? des
Antrages
Änderungsstelle:
(Konfigurations-verwaltung):
Änderungsauftrag schreiben
Einführung und Durchführung
Betroffene Stellen:
Durchführung der
Änderungen in betroffenen
Dokumenten
Dokumenten-/
Zeichnungsverwaltung,
Freigabestelle:
Verteilen von geänderten
Dokumenten
Die Aktualität lässt sich in projektindividuellen Prozessen sehr viel einfacher sicher-
stellen, wenn die Prozessbeschreibung zentralisiert, für alle leicht einsehbar ist und nach
2.5 Projektreporting 131
der ersten Erstellung entsprechend gepflegt wird. Die Prozessbeschreibungen ändern sich
im Projektverlauf sehr selten.
2.5.3 Projektpläne
Alle Projektpläne werden zum Zeitpunkt der Erstellung als realistisch angesehen. Die
einzelnen Pläne können auf denselben Daten basieren, aber für die entsprechende
Zielgruppe unterschiedlich aufbereitet sein. Beispielsweise wird der Projektplan, der
die Zusammenfassung aus Projektstrukturplanung, Dauer-, Aufwands- und Kosten-
schätzungen und der Terminplanung darstellt, oft als Grundlage für Meilensteinpläne
genutzt. Der gesamte Projektplan (bestehend aus den verschiedenen Einzelplänen) ist für
die Projektleitung von großer Bedeutung, einzelne Bereiche daraus sind für die jeweils
zuständigen Projektteams wichtig und an einem Meilensteinplan ist oft der Auftraggeber
interessiert. Welche Stakeholder, welche Pläne und ggf. Berichte erhalten, kann ebenfalls
in einem Plan festgehalten werden, dem Kommunikationsplan, für den ein Beispiel in
Tab. 2.29 dargestellt ist.
Tab. 2.29 Kommunikationsplan
Berichtsart Berichtszyklus PM PC TP TP PO Übriges Team
T&I W&C
Projektplan Vor LA-Sitzung X
Personalplan und Ein- Laufend X
satzplanung
Projektstatusbericht Monatlich X
Soll-Ist-Vergleich Monatlich X
(Kosten/Aufwand)
Fortschrittskontrolle Monatlich X
der Terminplanung
Besprechungs- Nach jedem Meeting X
protokoll
Fehlermeldungen Bei Bedarf X
Testberichte Nach erfolgtem Test X
Übergabeprotokoll Vor Freigabe/ X
Abnahme
Tätigkeitsberichte Wöchentlich X
Legende:
PM: Projektmanager
PC: Projektcontroller
TP T&I: Teilprojekt Test und Integration
TP W&C: Teilprojekt Webprogramming und Customizing
PO: Projektoffice
132 2 Klassische Grundlagen: Es geht los…
2.5.4 Projektberichte
Die Berichte werden in der Regel zu bestimmten Anlässen verfaßt und dokumentieren
diese. Einige Berichte werden unabhängig von bestimmten Anlässen auf periodischer
Basis erstellt, dazu gehören beispielsweise Statusberichte. Der Versuchung, die
Statusberichte nur zu erstellen, wenn es ein Problem gibt, oder aus anderen Gründen
Unterstützung benötigt wird, gilt es zu widerstehen. Die alleinige Erstellung von
Statusberichten zu sich negativ auswirkenden Ereignissen, vergibt der Projektleitung
die Chance, die Erfolge hervorzuheben. In der Wahrnehmung wird das Projekt als ein
schlecht durchgeführtes Projekt mit vielen Problemen in Erinnerung bleiben. Daher
sollte dieser Bericht unbedingt regelmäßig verfasst werden. Es gibt verschiedene
Anlässe, zu denen ein Projektbericht verfasst werden kann:
Lehrvideos
Eine Vertiefung und Erläuterung zum Projektreporting finden Sie in den Videos
Abb. 2.91, 2.92, 2.93 und 2.94 des Videokurses.
2.5 Projektreporting 133
Abb. 2.91 Einführung
Berichtswesen (https://doi.
org/10.1007/000-0rx)
Abb. 2.93 Dokumentarten im
Projektmanagement (https://
doi.org/10.1007/000-0rz)
Kontrollfragen
1. Erläutern Sie die Bedeutung des Projektreportings.
2. Welche Ordnerstruktur würden Sie für Ihr nächstes Projekt vorschlagen?
3. Welche unterschiedlichen Dokumentarten gibt es?
134 2 Klassische Grundlagen: Es geht los…
2.6 Projektabschluss
Lernziele
Sie wissen, wann die Aufgaben für den Projektabschluss beginnen.
Sie kennen die Ziele des Projektabschlusses.
Der Projektabschluss muss, wie die anderen Prozesse auch, sorgfältig geplant und vor-
bereitet werden und beginnt am ersten Tag des Projektes.
Es ist ein Trugschluss anzunehmen, dass mit der Abnahme durch den Kunden das
Projekt zu Ende ist und sofort am nächsten Tag neue Projekte in Angriff genommen
werden können. Auch nach einer Abnahme muss sich der Projektleiter verschiedenen
Aufgaben stellen. Ein sorgfältig geplanter Projektabschluss verfolgt mehrere Ziele:
1. Das Wissen und die Erfahrung, die im Projekt (auch durch Fehler) gesammelt
wurden, sollen nicht verloren gehen. In diesem Sinne trifft dann ein etwas
abgewandeltes Sprichwort zu: „Intelligente Organisationen machen jeden Fehler
genau einmal“. Dazu ist allerdings mehr notwendig, als vorhandene Formblätter oder
Checklisten, und Erfahrungsberichte einzufordern. Es ist wichtig, gemachte Fehler als
Chance zur Weiterentwicklung zu sehen, und eine solche Haltung auch bei den Mit-
arbeitern zu fördern.
2. Weiterer Vorteil ist die Weiterentwicklung des Projektmanagements im Unter-
nehmen. Aus diesem Grund gibt es viele Unternehmen, die regelmäßige Treffen
der Projektleiter organisieren, um Erfahrungen auszutauschen und Methoden weiter
zu entwickeln. Oft werden auch Datenbanken aufgebaut, in denen die individuellen
Projekterfahrungen gesammelt werden.
3. Die Projektmitarbeiter haben u. U. eine lange Zeit miteinander verbracht, sind
zusammengewachsen und haben es gelernt mit diesem Projektleiter, seinen Methoden
und seiner Art Projekte zu leiten, zurechtzukommen. Bei weiteren Projekten greift
man wahrscheinlich gerne auf diese Mitarbeiter zurück, und möchte sie nicht
demotivieren. Es ist daher wichtig, den Mitarbeitern Feedback zu geben, ihre Rück-
führung in das Tagesgeschäft reibungslos zu gestalten und das Projekt vielleicht bei
einer kleinen Abschlussveranstaltung auch mental abzuschließen.
Das Projektergebnis muss in seinem weiteren Leben ebenfalls bestehen können, und
muss ordnungsgemäß übergeben werden. Insofern sind schon Teilabnahmen ein
wichtiger Schritt auf dem Weg zum erfolgreichen Abschluss des Projektes.
Damit auch die endgültige Projektabnahme durch den Auftraggeber funktioniert, ist
eine letzte Projektsitzung mit den Entscheidern sinnvoll, die im Vorfeld klärt, ob alle
Punkte berücksichtigt wurden und das Projekt abgeschlossen werden kann.
Literatur 135
Abb. 2.95 Einführung
Projektabschluss (https://doi.
org/10.1007/000-0s1)
Abb. 2.96 Projektabschluss
beginnt mit Tag 1 des Projektes
(https://doi.org/10.1007/000-
0qr)
Lehrvideos
Eine Vertiefung und Erläuterung zum Projektabschluss finden Sie in den Videos
Abb. 2.95, 2.96 und 2.97 des Videokurses.
Kontrollfragen
1. Wann beginnt der Projektabschluss?
2. Was sind die Ziele des Projektabschlusses?
Literatur
3. Brettschneider, F., & Schuster, W. (2013). Stuttgart 21. Wiesbaden: Springer Fachmedien
Wiesbaden. https://doi.org/10.1007/978-3-658-01380-6.
4. Bundesregierung. (2019). Pressekonferenz von Bundeskanzlerin Merkel und Bundes-
minister Scholz am 18. November 2019. https://www.bundesregierung.de/breg-de/suche/
pressekonferenz-von-bundeskanzlerin-merkel-und-bundesminister-scholz-am-18-november-
2019-1693682.
5. Deutsches Institut für Normung. (2009). Projektmanagement-Netzplantechnik; Beschreibung
und Begriffe=Project management-Project network techniques; Descriptions and
concepts=Management de projet-Techniques logiques du reseau; Descriptions et concepts/
Normenausschuss Qualitätsmanagement, Statistik und Zertifizierungsgrundlagen (NQSZ) im
DIN. Deutsche Norm: DIN 69900. Berlin: Beuth.
6. Ebbinghaus, H. (1885). Uber das Gedachtnis: Untersuchungen zur experimentellien
Psychologie. Leipzig: Duncker & Humblot.
7. Gassmann, O. (Hrsg.). (2005). Praxiswissen Projektmanagement: Bausteine, Instrumente,
Checklisten. München: Hanser.
8. Geissner, H. (1978). Rhetorik (4., durchgesehene Aufl.). München: Bayerische Schulbuch.
9. Gessler, M. (Hrsg.). (2016). Kompetenzbasiertes Projektmanagement (PM 3): Handbuch für
die Projektarbeit, Qualifizierung und Zertifizierung auf Basis der IPMA Competence Baseline
Version 3.0 (8. überarbeitete Aufl.). Nürnberg: GPM Deutsche Gesellschaft für Projekt-
management e. V.
10. Keßler, H., & Winkelhofer, G. A. (2004). Projektmanagement: Leitfaden zur Steuerung und
Führung von Projekten; mit 42 Tabellen (4., überarb. Aufl.). Berlin [u. a.]: Springer.
11. Kühl, E. (2015). Elektronik: Apple und das Pentagon forschen an Wearables. Die Zeit. https://
www.zeit.de/digital/internet/2015-08/apple-wearables-pentagon-militaer.
12. Microsoft. (2019). Der Support für Windows 7 endet am 14. Januar 2020. https://support.
microsoft.com/de-de/help/4057281/windows-7-support-ended-on-january-14-2020.
13. NDR. (2017). Elbphilharmonie: Die wichtigsten Etappen. https://www.ndr.de/kultur/
elbphilharmonie/Elbphilharmonie-Die-wichtigsten-Etappen,elbphilchronologie100.html.
14. Patzak, G., & Rattay, G. (2018). Projektmanagement: Projekte, Projektportfolios, Programme
und projektorientierte Unternehmen (7., aktualisierte Aufl.). Wien: Linde international.
15. Project Management Institute. (2017). A guide to the project management body of knowledge
(pmbok® guide). Chicago: Project Management Institute.
16. Rauer, K. (2012). Projektmanagement auf der Überholspur: Grundlagenwissen zur IPMA
Zertifizierung. Norderstedt: Books on Demand GmbH.
17. Stabenow, D. (2013). Führen in Projekten (1. Aufl.). Training kompakt. Berlin: Cornelsen.
18. Steffen, T. (2020). Rechtsradikalismus: Andreas Kalbitz klagt vor AfD-Bundesschiedsgericht
gegen Rauswurf. Die Zeit. https://www.zeit.de/gesellschaft/zeitgeschehen/2020-05/
rechtsradikalismus-andreas-kalbitz-afd-parteiausschluss.
19. SV Informatik GmbH. (2019). Das Unternehmen SV Informatik|SV Informatik GmbH.
https://www.sv-informatik.de/content/unternehmen/.
20. Tuckman, B. W., & Jensen, M. A. C. (1977). Stages of small-group development revisited.
Group & Organization Studies,2(4), 419–427.
Agiles Projektmanagement
3
Lernziele
Sie kennen die Grundgedanken des agilen Arbeitens und können ihre Ein-
stellungen prüfen und ggf. anpassen.
Sie werden entscheiden können, ob agiles oder klassisches Projektmanagement
einzusetzen ist.
Sie können das klassische Projektmanagement mit agilen Methoden ergänzen.
Sie wissen, mit welchen Mitteln die Umsetzung unterstützt wird.
Sie kennen die typischen Rollen in einem Scrum-Team.
Sie wissen um die Kompetenzen eines agilen Teams.
Sie wissen, welche Meetings durchgeführt werden.
Sie können Backlogs aufstellen und wissen, welche es gibt.
Sie können die Items der Backlogs priorisieren.
Sie wissen, was Pokern im agilen Umfeld bedeutet.
3.1 Einführung
In den vergangenen Jahren hat sich das agile Projektmanagement immer mehr in das
Bewusstsein der Projektmanager gedrängt und erfährt große Beachtung. So werden
ganze Unternehmensbereiche auf das agile Management umgestellt, was vom Bitkom,
dem Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e. V.
explizit empfohlen wird [1].
Nichtsdestotrotz bleibt die Bedeutung des klassischen Projektmanagements erhalten,
da ein Umstieg auf agiles Projektmanagement nicht für alle Projekte sinnvoll ist.
© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer 137
Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021
T. Peters und N. Schelter, Kompakte Einführung in das Projektmanagement,
https://doi.org/10.1007/978-3-658-31194-0_3
138 3 Agiles Projektmanagement
AXA Schweiz
In der AXA Schweiz hat es sich beispielsweise gezeigt, dass trotz fortschreitender
Agilisierung der Projekte, das klassische Vorgehen bei Projekten mit stabilen und
klaren Anforderungen effizienter ist [2]. ◄
Grundlage ist das agile Manifest, das sich zwar explizit auf Softwareentwicklung
bezieht, aber inzwischen Eingang in viele weitere Anwendungsbereiche gefunden hat.
Das agile Manifest sagt nicht, dass die auf der rechten Seite erwähnten Dinge unnötig
sind, sondern lediglich, dass die Prioritäten auf den Dingen der linken Seite liegen:
• So gibt es mit dem in Scrum dargelegten Ablauf (siehe Abschn. 3.6) einen fest
definierten Prozessablauf.
• Die Dokumentation ist deshalb wichtig, weil der Mensch vergisst und das rasend
schnell, wie ein Blick auf die Vergessenskurve von Ebbinghaus zeigt [6].
3.3 Magisches Dreieck 139
• Auch Verträge sind nicht obsolet, das kann jeder bestätigen, der mit nicht ein-
gehaltenen Zusagen und daraus folgend mit nicht durchsetzbaren Ansprüchen
konfrontiert war.
• Nicht zuletzt zeigt die praktische Erfahrung vieler, die mit agilen Methoden arbeiten,
dass der Planungsaufwand mit agilen Methoden deutlich höher ist als die Arbeit im
klassischen Projektmanagement.
Aus dem agilen Manifest leitet sich folglich eine veränderte Grundhaltung zur Projekt-
arbeit ab, die aus der Erfahrung vieler gescheiterter Projekte ihre Berechtigung hat. So
zählt zu den oft zitierten Kardinalfehlern des Projektmanagements das Anforderungs-
management und die damit verbundene notwendige Einbindung der Benutzer [7].
Ebenfalls stellt man in vielen klassischen Projekten fest, dass das Bestreben eher
dahin geht, nachträgliche Änderungen am Projektumfang und an der Zeitplanung etc.
zu vermeiden oder gar zu blockieren. Dies führt in der heutigen, schnelllebigen Zeit zu
Ergebnissen, die im schlimmsten Fall nicht genutzt werden, oder die nicht die Qualität
haben, die sie haben könnten.
1. werden geänderte und neue Anforderungen mit den Prioritäten bereits existierender
Anforderungen verglichen,
2. werden diese im priorisierten Product Backlog (siehe Abschn. 3.6.1) an die Position
mit entsprechender Priorität einsortiert,
3. werden diese neuen oder geänderten Anforderungen entsprechend ihrer Priorität
früher oder später umgesetzt und
4. entfällt die Umsetzung der Anforderung, wenn sie gemäß ihrer Priorität nur außerhalb
des gesetzten Zeitrahmens umgesetzt werden könnte.
Ist die Priorität eines Backlog-Items entsprechend hoch, wird die Umsetzung sehr
schnell erfolgen, je niedriger die Priorität ist, desto später wird das Item umgesetzt.
Wenn die vorgesehene Zeit abgelaufen ist, sind oft noch Items im Backlog enthalten, die
nicht umgesetzt worden sind. Diese haben aber dann offenbar kein gutes Kosten-Nutzen-
Verhältnis.
140 3 Agiles Projektmanagement
Unter der Annahme, dass die Kosten auf Basis der beteiligten Mitarbeiter entstehen
und diese dem Projekt während der gesamten Laufzeit Vollzeit zur Verfügung stehen,
ergibt sich aus der festen Dauer des Projektes ein fester Kostenumfang.
3.4 Timeboxing/Zeitbegrenzung
Die Zeitbegrenzung ist nicht nur in den Regeln für Meetings immer wieder eine
Empfehlung, sondern wird auch im Zeitmanagement genutzt.
3.5 Umsetzung
Die Ideen des agilen Manifestes könnten durch eine veränderte Grundhaltung auch in
„klassischen“ Projekten umgesetzt werden. Jedoch zeigt die Erfahrung, dass der bloße
Wille etwas besser zu machen, meistens nicht ausreicht und durch entsprechend ver-
änderter Methoden unterstützt werden muss. Diese sind in Bezug auf die Statements des
agilen Mainfestes:
Eine Untersuchung von Bitkom hat gezeigt, dass Scrum als der „König unter den agilen
Methoden“ [8] gilt. Aus diesem Grunde soll hier Scrum als Rahmen für die Darstellung
der agilen Methoden genutzt werden. Grundlage dafür ist folgerichtig der Scrum Guide
[9].
142 3 Agiles Projektmanagement
In der Abb. 3.2 ist der Ablauf schematisch dargestellt, die einzelnen Elemente werden im
Folgenden genauer erläutert.
1. Basis für die Bearbeitung ist der Product-Backlog mit allen bekannten Anforderungen
an das Ergebnis des Projektes.
2. Die höchsten priorisierten Anforderungen werden im Rahmen der Sprint-Planung
besprochen und vom Product Owner so detailliert beschrieben, dass das Ent-
wicklungsteam diese im nächsten Sprint umsetzen kann.
3. Während der Laufzeit des Sprints findet täglich ein Daily statt.
4. Am Ende der Laufzeit des Sprints liegt im besten Fall ein an den Kunden ausliefer-
bares Ergebnis vor.
5. Dieses wird im Sprint Review seitens Product Owner und Kunden überprüft und ggf.
abgenommen.
6. In der darauffolgenden Sprint Retrospektive reflektiert das Entwicklungsteam seine
Arbeitsweise und arbeitet mögliche Verbesserungen in den nächsten Ablauf ein.
Im ersten Schritt entsteht der Product Backlog als Sammlung aller Anforderungen, die an
das zu erstellende Produkt gestellt werden. Diese Anforderungen werden Backlog Items
genannt, können sehr genau formuliert sein oder zunächst eine grobe Idee sein.
Diese Backlog Items werden nach Wichtigkeit bewertet und priorisiert. Im ersten
Backlog wird zusätzlich festgehalten, welche Anforderungen mindestens erfüllt sein
müssen, um ein minimal funktionierendes Produkt, das Minimalprodukt (MVP: Minimal
Viable Product) zu erstellen. Diese stehen an erster Stelle und werden entsprechend als
Erstes bearbeitet. Der Product Backlog ist niemals statisch, sondern wird stetig ergänzt,
um weitere oder geänderte Anforderungen aufzunehmen.
Am Beispiel des SBB Personenverkehrs wird deutlich, dass mit Einführung des
agilen Projektmanagements umfangreiche Dokumentationen entfielen und stattdessen
erfolgreich mit Backlogs und Akzeptanzkriterien gearbeitet wurde [2]. ◄
Inhalte
Die im Product Backlog aufgenommenen Informationen, die Backlog Items, können ver-
schieden strukturiert und detailliert sein, je nachdem, wie viele Informationen schon vor-
liegen und wie intensiv die Items diskutiert wurden. Wichtige Informationen sind:
• Beschreibung,
• geschätzter Aufwand,
• geschätzter Nutzen,
• Priorität und
• Risiken.
Prioritätenbildung
Aus der festen Dauer der Projekte folgt die Notwendigkeit, die Items des Product
Backlog zu priorisieren. Auf diese Weise ist es möglich, die wichtigsten Dinge zuerst
umzusetzen und die unwichtigeren unter Umständen später oder auch gar nicht umzu-
setzen. Damit ist sichergestellt, dass das Projekt mit dem besten Kosten-Nutzen-Verhält-
nis umgesetzt wird. Hier sollen zwei kombinierbare Methoden als kleiner Einblick näher
beschrieben werden.
144 3 Agiles Projektmanagement
Paarweiser Vergleich In den meisten Fällen können nicht alle Anforderungen der
„Must“-Kategorie in einem einzigen Sprint umgesetzt werden. Abstufungen innerhalb
einer Kategorie können beispielsweise mit einem paarweisen Vergleich ermittelt werden:
Es ist zu beachten, dass auch diese Reihenfolge sich jederzeit durch zusätzliche
Informationen, weitere Anforderungen oder geänderte Anforderungen ändern kann.
Sollen zur Priorisierung der Backlog Items Nutzen oder Aufwand herangezogen
werden, stehen verschiedene Schätzmethoden zur Verfügung.
Product Owner
Die Verantwortung für Aufbau und Pflege des Product Backlog hat allein der Product
Owner. Er oder sie ist Repräsentantin des Kunden, der späteren Nutzer und anderer,
die von dem Endergebnis des Projektes betroffen sind. Er sorgt dafür, dass alle
Anforderungen gesammelt und priorisiert werden, damit sichergestellt ist, dass die wirk-
lich wichtigen Anforderungen mit der höchsten Wahrscheinlichkeit umgesetzt werden.
Zu diesem Zweck werden die Anforderungen des Product Backlogs immer weiter spezi-
fiziert und verfeinert. Der Product Owner ist Ansprechpartner für das Entwicklungsteam
und diskutiert mit diesem jedes Backlog Item, welches im kommenden Sprint umgesetzt
werden soll. Das Entwicklungsteam muss vollständig verstanden haben, was umgesetzt
werden soll. Daher steht der Product Owner dem Entwicklungsteam auch während des
Sprints für Nachfragen inhaltlicher Natur zur Verfügung.
Der nächste Schritt ist die Sprint Planung. In diesem Meeting wird festgelegt, wie viele
Anforderungen des Product Backlog im kommenden Sprint umgesetzt werden können.
Zur genauen Beurteilung werden die wichtigsten Items des Product Backlogs soweit ver-
feinert, dass das Entwicklungsteam den Aufgabenumfang und den vermutlichen Arbeits-
umfang abschätzen kann. Die im kommenden Sprint zu erledigenden Product Backlog
Items werden in den Sprint Backlog übertragen und mit Akzeptanzkriterien versehen.
Diese Schritte vereinfachen eine zielgerichtete Arbeit an dem Sprint Backlog Item und
ermöglichen einen Sprint Review mit klaren Kriterien.
Zalando
Das Rezept von Zalando ist Radical Agility. Es gilt u. a. der Grundsatz „What you
cannot measure does not exist.“ Und den aktuellen Erfolg von Zalando stellt vermut-
lich niemand in Frage. Der Wunsch, die Fortschritte stets messen zu können und diese
Herausforderungen auch für komplexe Situationen erfolgreich anzunehmen, beginnt
mit messbaren Akzeptanzkriterien [10]. ◄
Es versteht sich von selbst, dass das gesamte Team an der Sprint Planung teilnimmt.
Der Product Owner ist für inhaltliche Fragen verantwortlich, der Scrum Master
für methodische Fragen zuständig und das Entwicklungsteam klärt die Fragen zur
praktischen Umsetzung.
Obwohl man annehmen kann, dass Agilität sicher nicht in einem Unternehmen,
dass sich mit Atomkraftwerken befasst, anwendbar ist, hat EnBW Energie Baden-
Württemberg AG genau das umgesetzt. Schlüssel zum Erfolg sind die umfassende
146 3 Agiles Projektmanagement
Interdisziplinarität der Teams und klare Rollen für Product Owner und einem Coach,
der dem Scrum Master gleichkommt [10]. ◄
Dieses Sprint Planungs-Meeting ist ebenfalls zeitlich streng begrenzt. Abhängig von der
Länge des Sprints (maximal vier Wochen) kann es bis maximal acht Stunden dauern.
• Verpflegung sicherstellen
• Getränke bereitstellen
• Gäste einladen
Im Ergebnis sind die Story Points des einen Projektes nicht mit den Story Points anderer
Projekte vergleichbar. Alternativ kann der paarweise Vergleich der zu schätzenden
Items eine Größenangabe ähnlich den T-Shirt Größen XS, X, M, L, XL ergeben. Diese
Schätzung ist deutlich gröber als Zahlenwerte, ist aber für eine erste Abschätzung und
Priorisierung im Product Backlog oft schon ausreichend.
3.6 Der Ablauf am Beispiel von Scrum 147
1. Das gesamte Team sitzt zusammen und überlegt sich unabhängig voneinander, wie
viel Aufwand in dem diskutierten Backlog-Item steckt.
2. Jedes einzelne Teammitglied legt die eigene Schätzung in Form einer Karte (Planning
Poker-Karten oder auch normale Pokerkarten) verdeckt auf den Tisch.
3. Sobald alle Teammitglieder ihre Schätzung durch Legen der Karte abgegeben haben,
werden die Karten umgedreht.
4. Es wird festgestellt, wer den höchsten und den niedrigsten Wert geschätzt hat, diese
beiden Personen tauschen sich öffentlich über die Gründe ihrer Schätzung aus. In
aller Regel liegen die Unterschiede in unterschiedlichen Annahmen, Risiken oder
Aufgaben begründet.
5. Nach der Diskussion wird erneut mit Punkt 1. gestartet und dieser Ablauf solange
wiederholt, bis die Schätzungen sich angeglichen haben oder das Team sich auf eine
gemeinsame Schätzung einigen kann.
Ab der zweiten Runde sind Ankereffekte nicht mehr auszuschließen, die Diskussion
liefert aber ein vollständigeres Bild der zu leistenden Arbeit und ist in jedem Fall ein
Gewinn für die Qualität der Schätzung.
Entwicklungsteam
Im agilen Umfeld wird viel Verantwortung in die Hände des Teams gelegt. Dies führt
einerseits zu einer größeren Motivation, aber auch zu neuen Herausforderungen, mit
148 3 Agiles Projektmanagement
Selbstorganisierte Teams
Zur Schlüsselidee der agilen Methoden gehören die sich selbst organisierenden Teams.
Das bedeutet:
Damit findet im Team einerseits mehr motiviertes Arbeiten durch die größere Eigen-
ständigkeit und Verantwortung statt, andererseits können damit verbundene ungewohnte
Probleme auftreten. Die fehlende Hierarchie im klassischen Sinne gibt es nicht mehr und
3.6 Der Ablauf am Beispiel von Scrum 149
damit auch niemanden, der beispielsweise Teamkonflikte lösen könnte, wenn das Team
selbst dazu nicht mehr in der Lage ist.
In Scrum gibt es als Moderator und methodische Unterstützung den Scrum-Master.
In anderen agilen Modellen wird nicht auf eine Führung verzichtet. Diese ist dann
jedoch oft mit anderen Aufgaben und einem anderen Führungsbild konfrontiert. Es setzt
sich -auch im klassischen Umfeld- mehr und mehr das Servant Leadership durch, die
Dienende Führung, die die Teamleitung als Unterstützung für das Team ansieht.
Dass diese positive Sichtweise nicht zwangsläufig von allen getragen wird, zeigt das
Beispiel Zappos.
Zappos
Das große Vorbild von Amazon, der Online-Schuhhändler Zappos versucht seit 2013
die Selbstverwaltung (Holokratie) einzuführen. Es gibt keine Hierarchien mehr, die
Mitarbeiter haben Rollen und arbeiten dynamisch in unterschiedlichen Teams. Diese
Änderung rief viel Widerstand bei den Mitarbeitern hervor und führte letztlich zur
Kündigung von 210 Mitarbeitern, insgesamt 14 % der Belegschaft. Dies macht sehr
deutlich, dass Änderungen immer mit Widerstand kämpfen müssen, selbst wenn der
Grundgedanke gut ist [11]. ◄
Die Mehrheit der Unternehmen, die selbstorganisierte Teams eingeführt haben, sind
allerdings mit den Ergebnissen sehr zufrieden, so die Business Analysten bei SBB
Personenverkehr.
Am Beispiel des SBB Personenverkehrs wurde deutlich, dass die Tätigkeit der
Business Analysten durch die Mitarbeit in agilen Projekten vielfältiger wurde, es zu
Aufgabenüberschneidungen kam und diese breit gefächerte Einsatzmöglichkeit den
Zusammenhalt im Team verstärkte [2]. ◄
Für den Erfolg einer erfolgreichen Einführung sind gemäß Detlev Lohmann, der dies für
sein Unternehmen mit 270 Mitarbeitern eingeführt hat, drei Punkte entscheidend.
Allsafe Group
Die Allsafe Group ist Experte für Ladegutsicherungen. 1999 erwarb Detlev Lohmann
25,2 % von Allsafe und ist geschäftsführender Gesellschafter. In der Zeit von 1999
bis 2016 ist das Unternehmen stetig gewachsen, was auch auf eine steigende Selbst-
organisation zurückgeführt wird.
Es wurden drei Erfolgsfaktoren von Detlev Lohmann identifiziert:
1. Schulung der Mitarbeiter zur Selbstorganisation und Zeit das Gelernte anzuwenden
150 3 Agiles Projektmanagement
Aus dem Product Backlog werden die höchsten priorisierten Anforderungen ausgewählt,
die im Zeitrahmen eines Sprints voraussichtlich umsetzbar sind. Diese Entscheidung
erfolgt im Sprint Planungsmeeting und wird durch das Entwicklungsteam getroffen.
Diese ausgewählten Anforderungen bilden den Sprint Backlog. Grundsätzlich gelten für
den Sprint Backlog die Hinweise des Product Backlog. Jedoch ist der Sprint Backlog
nach einer sehr zielgerichteten Diskussion, die die Umsetzung im nächsten Sprint vor
Augen hat, bereits sehr viel detaillierter ausgearbeitet, als es der Product Backlog ist.
Detaillierung
Mit zunehmendem Wissen über die Anforderungen (bei allen Beteiligten) wird ein
Backlog-Item in der Regel immer weiter detailliert, es erhält mehr Informationen
oder wird in kleinere Teile zerlegt. Dies kann z. B. durch eine weitere Information im
Backlog-Item dokumentiert werden, z. B. durch „Gehört zu [Übergeordnetes Item]“,
oder ein kaufen wird zu online kaufen, sodass die Zusammenhänge nicht verloren gehen.
Die Aufteilung in Teil-Items kann durch Präzisierung von Begriffen erfolgen, die für
sich allein noch sehr viel Interpretationsspielraum lassen.
INVEST
Das Akronym INVEST unterstützt die Zergliederung großer Backlog Items nach vor-
definierten Kriterien. Es wurde von Bill Wake [13] definiert und stellt verschiedene
Qualitätskriterien sicher.
• I
= Independent (unabhängig, in sich geschlossen)
• N = Negotiable (verhandelbar)
• V = Valuable (wertvoll, für den Benutzer Wert schaffend)
• E = Estimable (schätzbar, Aufwand soll jederzeit einschätzbar sein)
• S
= Small (klein, so klein wie möglich geschnitten)
• T = Testable (testbar, sie muss so viel Information enthalten, dass sie testbar ist)
Weitere Zerlegungsmöglichkeiten
Eine in der Praxis oft genutzte Aufteilung großer User Stories zieht nach Lawrence ver-
schiedene weitere Kriterien heran [14]. So kann eine Aufteilung beispielsweise erfolgen
nach:
Eine Aufteilung nach den einzelnen Workflow Schritten würde für die User Story Als
Online-Einkäufer/-in möchte ich das ausgewählte Produkt mit anderen Produkten
vergleichen, um das qualitativ beste Produkt kaufen zu können eine Aufteilung in die
Workflow Schritte Auswahl des Produktes, Festlegen der Auswahlkriterien bedeuten.
Mit dieser Aufteilung könnte einer Verfeinerung folgendermaßen aussehen:
3.6.4 Sprint
Mit dem fertigen Sprint Backlog kann der erste Sprint und später die weiteren Sprints
gestartet werden. Ein Sprint ist die für einen Entwicklungsschritt zur Verfügung stehende
Zeit und kann zwischen einer Woche und vier Wochen dauern. In dieser Zeit werden die
Anforderungen des Sprint Backlog umgesetzt, die am Ende des Sprints möglichst in ein
Inkrement münden. Für die Wahl der Dauer eines Sprints sind unterschiedliche Kriterien
maßgebend.
Für kürzere Sprints sprechen.
Kreative und gute Lösungen lassen sich eher finden, wenn kein Abgabetermin Lösungs-
druck erzeugt, in diesem Fall sind längere Sprintdauern sinnvoll. In jedem Fall bleibt die
gewählte Sprintdauer konstant, da auch ein regelmäßiger und gewohnter Ablauf Stress
reduziert.
Der Daily Scrum, kurz als Daily bezeichnet, wird nach dem Start des Sprints jeden
Tag durchgeführt. Es soll helfen, alle Beteiligten auf einen gemeinsamen Stand zu
bringen und die Arbeit des neuen Tages zielgerichtet anzugehen. Die Themen in dem
15-minütigen Meeting sind:
Die Moderation wird vom Scrum Master übernommen, der Product Owner darf
anwesend sein, um Fragen inhaltlicher Natur zu klären. Keinesfalls werden seitens
Product Owner oder Scrum Master Anweisungen an das Team gegeben, dies wider-
spricht der Selbstorganisation und kann ein Team demotivieren.
Die strenge Zeitbegrenzung wird durch die Verschiebung auftauchender Probleme
in die Zeit nach dem Daily eingehalten, die dann nur mit den Betroffenen/Beteiligten
diskutiert und gelöst werden. Eine weitere Unterstützung ist die Form des Meetings. In
vielen Fällen wird das Meeting als sogenanntes Stand-Up abgehalten, z. B. im Stehen
an Stehtischen. Die Versuchung, in gemütlicher Runde sitzend bei einer Tasse Kaffee
3.6 Der Ablauf am Beispiel von Scrum 153
mit Keksen zu verbringen, kommt so gar nicht erst auf. Und damit auch nicht die Ver-
suchung, das Meeting länger als notwendig auszudehnen.
Saxonia Systems AG
Das tägliche Treffen hat sich z. B. bei der Saxonia Systems AG bewährt, die allen
Unkenrufen zum Trotz, das agile Management mit verteilten Teams eingeführt hat.
Das Daily mit den elektronischen und spezialisierten Werkzeugen war ein zentraler
Erfolgsfaktor für die erfolgreiche Zusammenarbeit [15]. ◄
Steuerung
Mit dem Daily Scrum startet die Sprintsteuerung, d. h. es soll für alle jederzeit sicht-
bar sein, welchen Bearbeitungsstand das Projekt hat. Im Scrum Guide existiert kein
Abschnitt, der sich mit der Steuerung agiler Projekte befasst. Nichtsdestotrotz existieren
Methoden, die den aktuellen Stand des Projektes jederzeit klar visualisieren. Die
Visualisierung unterstützt den unbedingten Willen nach Transparenz, die das Mitdenken
und die Selbstverantwortung der Teammitglieder fördert.
Die EnBW Energie Baden-Württemberg AG sieht als Schlüssel zum Erfolg des agilen
Managements das Visual Management. Unter anderem wird der Projektfortschritt
visualisiert und trägt nach Aussage des Unternehmens damit entscheidend zur trans-
parenten Kommunikation bei [10]. ◄
Die bekanntesten Mittel sind das sogenannte Taskboard oder Aufgabenboard, dass sich
vom bekannteren Kanban-Board zwar nicht optisch, aber inhaltlich unterscheidet, sowie
das Burndown-Chart.
Eine naheliegende und sehr beliebte Möglichkeit ist die Erweiterung des Sprint
Backlogs zu einem Aufgabenboard. Der Sprint Backlog wird um weitere Spalten
ergänzt, mindestens um die Spalten „in Arbeit“ und „fertig“. Die Elemente des Sprint
Backlogs wandern mit jedem Arbeitsschritt eine Spalte weiter. So ist für alle unmittelbar
ersichtlich, welche Arbeiten anstehen und abgearbeitet werden können. Ebenso werden
die aktuellen Arbeiten für alle sichtbar angezeigt. Nachfragen, was aktuell bearbeitet
wird, wo Unterstützung benötigt wird, und ähnliches sind damit nicht notwendig und
fördern die Eigeninitiative und Selbstverantwortung der Teammitglieder. Ein Beispiel ist
in Abb. 3.3 dargestellt.
Eine elektronische Version des Aufgabenboards hat die erfolgreiche Transformation
der Saxonia Systems AG ermöglicht, wie in dem Video in Abb. 3.4 dargestellt wird.
Das Burndown-Chart plant den idealtypischen Verlauf der Arbeit eines Sprints oder
des Projektes und zeigt auf, wieviel Restarbeit noch zu erledigen ist. Neben dem täglich
oder pro Sprint aktualisierten Überblick über den Bearbeitungsstand ist dies besonders
hilfreich für die Sprint Retrospektive (siehe Abschn. 3.6.8). Durch Unterschreiten
154 3 Agiles Projektmanagement
Abb. 3.4 Elektronisches
Aufgabenboard bei Saxonia
Systems AG
der Ideallinie wird deutlich, dass die anliegende Arbeit schneller abgearbeitet werden
konnte, umgekehrt zeigt ein deutliches Überschreiten Probleme bei der Bearbeitung
auf. In der Sprint Retrospektive können diese Abweichungen analysiert werden, um
zukünftige Abschätzungen genauer vorzunehmen oder ähnliche Bearbeitungsprobleme
von vornherein auszuschließen (Abb. 3.5).
Scrum-Master
Im Rahmen der Dailies müssen die Scrum Master die größten Herausforderungen in der
Regel bei neuen Teams bewältigen. Einerseits wird oft der Sinn täglicher Treffen nicht
gesehen, sodass es die Tendenz zu weniger Treffen gibt. Andererseits besteht der Drang
die Probleme sofort lösen zu wollen und damit die Treffen in die Länge zu ziehen. Oft
mit einem Großteil nicht betroffener Zuschauer, die aus diesem Grund nicht selten die
Treffen reduzieren möchten.
3.6 Der Ablauf am Beispiel von Scrum 155
Die Arbeit eines Scrum Masters muss folglich von Fingerspitzengefühl begleitet sein
und es sind gute Moderationsfähigkeiten gefragt, um die Einhaltung der Regeln sicher zu
stellen. Das Entwicklungsteam bleibt jedoch selbstverantwortlich und trifft die wesent-
lichen Entscheidungen im Rahmen ihrer inhaltlichen Tätigkeit selbst.
Neben der Moderation gehört das Ausräumen von Schwierigkeiten zu den wesent-
lichen Aufgaben des Scrum Masters. Alles, was das Entwicklungsteam in seiner
Produktivität behindert, wird vom Scrum Master behandelt und -soweit möglich- aus
dem Weg geräumt. Das können z. B. Verhandlungen über geeignete Räumlichkeiten für
das Entwicklungsteam sein.
Bosch
Bei dem Unternehmen Bosch ist weniger Kontrolle als ein wesentliches Element auf
dem Weg zu mehr Wertschöpfung gesehen worden. So ist der klassische Cheftyp
u. a. ersetzt worden durch sogenannte Agile-Master, die als Trainer ihres Teams mit
schnellem, permanentem Feedback sowie intensiver Kommunikation das Team führen
[16]. ◄
156 3 Agiles Projektmanagement
Eine weitere Aufgabe der Scrum Master ist die Unterstützung des Product Owner bei
der Organisation des Product Backlog. Dazu gehört die Detaillierung der Product
Backlog Items, um die Komplexität der einzelnen User Stories zu reduzieren, genauso
wie Umsetzung der Erkenntnisse aus dem Sprint Review (siehe Abschn. 3.6.7). Die
Diskussion um den Arbeitsumfang, der in einem Sprint zu schaffen ist, ist nur einer
der typischen Konflikte zwischen Entwicklungsteam und Product Owner bei denen der
Scrum Master moderierend eingreifen muss. Gute Kenntnisse im Konfliktmanagement
und in der Konfliktmoderation sind wesentliche Fähigkeiten, die der Scrum Master
haben sollte.
Servant Leadership
Servant Leadership ist ein Führungsstil, der ausschließlich die Unterstützung des Teams
zum Ziel hat. So muss der Servant Leader genau im Auge haben, welchen Bedarf das
Team hat und welche Hilfestellungen geleistet werden müssen, um das Team dabei zu
unterstützen, die gesetzten Ziele zu erreichen.
Die Führungskraft ist in diesem Fall eher als Moderator zu sehen, entsprechende
Fähigkeiten sollte diese mitbringen und sich selbst entsprechend zurücknehmen können.
Teamdynamiken zu sehen und zu verstehen gehört ebenfalls wie ein unaufgeregtes und
effizientes Konfliktmanagement zu den Kernkompetenzen.
Konfliktmanagement
Von der Teamleitung im agilen Management wird eher die Moderation eines Konfliktes
als eine hierarchische Entscheidung erwartet.
Allparteilichkeit ist für die Moderation keine leichte Anforderung, die aber durch
folgende Überlegungen und Maßnahmen erleichtert werden kann:
3.6 Der Ablauf am Beispiel von Scrum 157
• „Ich bin OK. Du bist OK.“ als Grundhaltung. Dieser Leitsatz aus der Transaktions-
analyse regt einen positiven Blick auf die Beteiligten an [17].
– Aktives Zuhören sorgt für ein besseres Verständnis der Beweggründe und
Motivationen der jeweiligen Partei.
Insgesamt gibt es fünf Formen der Konfliktlösung, die in Mischformen auftreten können
(Abb. 3.6):
Kooperation
Kooperation beinhaltet die 100 %ige Durchsetzung der Ziele beider Konfliktparteien.
Dies wird auch als Win-Win-Situation bezeichnet und ist die erstrebenswerteste Lösung
in einem Konflikt. Nicht immer lässt sie sich jedoch durchsetzen. Kooperation ist sinn-
voll, wenn
• eine integrierte Lösung notwendig ist, und beide Zielsetzungen so wichtig sind, dass
kein Kompromiss nötig ist und
• wenn sich nicht widersprechende Ziele vorliegen.
Kompromiss
Bei einem Kompromiss wird ein Teilerfolg für beide Parteien erzielt. Jede Partei wird ein
Stück von der 100 %igen Durchsetzung der eigenen Ziele zurücktreten müssen. Daher
wird diese Lösung auch als Lose-Lose-Situation bezeichnet. Kompromiss ist sinnvoll,
wenn
• die Zielsetzungen zwar wichtig sind, aber eine Verhärtung der Fronten vermieden
werden soll,
• eine Kooperation fehlschlägt und
• Teilzielerreichung bei komplexen Problemen wichtig ist.
Durchsetzung
Durchsetzung bedeutet die 100 %ige Durchsetzung der eigenen Ziele, ohne dass der
Konfliktpartner seine Ziele umsetzen kann. Durchsetzung ist unumgänglich, wenn
Vermeidung
Eine Vermeidung ist ein 100 %iger Verzicht beider Parteien auf ihre Ziele. Der Konflikt
wird damit nicht gelöst, was ein Problem darstellen kann. Ist eine Lösung dringend
erforderlich, kann der Konflikt zunächst vermieden werden, um nach einer Abkühlphase
darauf zurück zu kommen. Vermeidung ist erforderlich, wenn
• das Problem trivial ist und wichtigere Probleme gelöst werden müssen,
• keine Chance auf eine zufriedenstellende Lösung besteht, z. B. wenn man nicht genug
Macht hat, um sich durchsetzen zu können,
• die Wogen geglättet werden müssen, um auf einer anderen Ebene produktiv werden
zu können und
• ein Verlieren der Konfrontation mehr wiegt, als das Durchsetzen der eigenen Lösung.
Anpassung
Die Partei, die sich anpasst, ermöglicht der anderen Konfliktpartei eine 100 %ige Durch-
setzung, ohne eigene Ziele zu erreichen. Im Extremfall unterstützt sie die andere Partei.
Anpassung ist sinnvoll, wenn
• man feststellt, dass man falsch liegt oder nicht gewinnen kann,
• die Zielerreichung für die andere Partei wichtiger ist,
• Harmonie wichtiger ist, als die Zielerreichung,
• im Gegenzug ein anderes Ziel durchgesetzt werden kann und
• ein Verlieren der Konfrontation mehr wiegt, als das Durchsetzen der eigenen Lösung.
3.6 Der Ablauf am Beispiel von Scrum 159
Zu Beginn arbeiteten IBM und Microsoft zusammen. Die Zielsetzungen waren ähn-
lich und beide betrachteten sich als gute Ergänzung. IBM benötigte einen Entwickler
für das Betriebssystem MS-DOS, Bill Gates und Paul Allen, die Gründer von Micro-
soft hatten mit IBM einen potenten Käufer für die Software. Eine Kooperation war
also eine sehr gute Lösung.
Diese Kooperation bekam mit der weitergehenden Entwicklung von OS/2 Risse.
Beide Unternehmen versuchten, ihr präferiertes System gegenüber dem jeweils
anderen durchzusetzen. Lange Zeit versucht IBM mit forcierten Marketingstrategien
und anderen Kooperationspartnern, OS/2 gegenüber Windows durchzusetzen, was am
Ende nicht gelang. Stattdessen wurde wieder den Kunden einerseits Linux empfohlen,
andererseits wurden Kunden von IBM ebenfalls mit Windows-Rechnern versorgt, was
zuvor nicht vorgesehen war. In diesem Stadium sah IBM eine Anpassung an Micro-
soft als eine Strategie an, die dem eigenen Unternehmen Umsatz brachte, aber zum
größeren Teil Microsoft den Rücken stärkte (IBM und Microsoft: Die Chronologie
einer Trennung). ◄
An diesem Beispiel kann gut abgelesen werden, wie sich die Einschätzung der Konflikt-
lösungsstrategien ändern kann und dass auch eine Anpassungsstrategie für den vermeint-
lichen „Verlierer“ einen Gewinn bedeuten kann.
Gerade das Konfliktgeschehen innerhalb des Teams macht es notwendig, einen Scrum
Master zu haben oder zumindest eine andere externe Person.
Tablonautix
Ist der Sprint zu Ende, erhält man im Idealfall ein Ergebnis, das für den Kunden ein
nutzbares Produkt darstellt, das Inkrement. Oft wird man ein solches Ergebnis aber erst
nach einigen Sprints erreichen. Dieses Ergebnis der Arbeit an den Anforderungen aus
einem oder mehreren Sprint Backlogs nennt man Inkrement, ein Teilergebnis, das an den
Kunden ausgeliefert werden kann und für diesen damit sofort nutzbar ist. Getreu dem
160 3 Agiles Projektmanagement
Motto „Der Appetit kommt beim Essen“ stellt es eine Basis für weitere Änderungs-
wünsche dar und hilft dem gesamten Team dabei, die Anforderungen des Kunden besser
zu verstehen und weiter zu präzisieren.
Mit dem fertigen Inkrement beginnt die Prüfung, ob das Inkrement nützlich ist und
der eingeschlagene Weg richtig ist. Der maximal vier Stunden lange Sprint Review
konzentriert sich dazu nur auf das inhaltliche Ergebnis und die Arbeitsweise. Die
Leistung des Teams ist explizit nicht Gegenstand des Sprint Reviews, diese Themen
gehören in die Sprint Retrospektive (siehe Abschn. 3.6.8).
In vielen Fällen wird der Sprint Review nur mit dem Product Owner durchgeführt,
manchmal werden weitere Stakeholder dazu gebeten. Die angesprochenen Personen in
den User Stories geben Hinweise, welche Personen das sein könnten. Die gleichmäßige
Sprintdauer unterstützt bei der vorausschauenden Terminplanung. Günstig ist eine früh-
zeitige Festlegung auf den jeweils ersten Tag nach Sprintende mit der gleichen Uhrzeit
und im gleichen Raum, sodass alle Teilnehmer ihre Kalender passend für andere Termine
blockieren können.
Es empfiehlt sich, eine testbare Demo des entwickelten Inkrements bereitzu-
stellen, mit dem die Funktionalitäten unmittelbarer geprüft und getestet werden können
und nützlicheres Feedback gegeben werden kann. Theoretische Beschreibungen auf
Powerpoints wirken schnell einschläfernd, die Aufmerksamkeit ist nicht mehr voll-
kommen vorhanden und damit ist kein nützliches Feedback möglich. Um Feedback zu
bekommen, können schon vor der Demo die folgenden Fragen gestellt und im Nachgang
beantwortet werden:
Das Feedback ist nützlich, um sicherzustellen, dass das Ergebnis zu den Anforderungen
konform ist. Das Wertvollste stellen aber die Informationen zur Akzeptanz des Inkre-
ments dar. So kann ein Inkrement perfekt die Anforderungen erfüllen, ist aber vielleicht
nicht das, was sich der entsprechende Stakeholder vorgestellt hat. Die aufkommenden
Kritiken, Anregungen und Ideen werden für den Backlog gesammelt, priorisiert und
können so das Endprodukt noch weiter verbessern.
3.6 Der Ablauf am Beispiel von Scrum 161
Bevor es in das nächste Sprintplanungs-Meeting geht, schaut das Scrum Team zurück
und sucht nach wiederholbaren Erfolgen und Verbesserungsmöglichkeiten. In der
maximal 3stündigen Sprint Retrospektive wird der Arbeitsprozess des Teams durch-
leuchtet. Dies kann sich sowohl auf die Arbeitsweise und auf verwendete Werkzeuge
als auch auf die Verbesserungsmöglichkeiten der Beziehungen innerhalb des Teams
beziehen. Fragen, die den Prozess unterstützen können, sind:
• Worauf bin ich stolz, was hat bei mir gut geklappt?
• An welchen Stellen würde ich im nächsten Sprint anders arbeiten und wie?
• Was habe ich vorbildlich im Team wahrgenommen?
• Welche Verbesserungsvorschläge habe ich für mein Team?
Der Blick auf das Burndown Chart, das Taskboard und auf die Schätzungen kann weitere
wertvolle Erkenntnisse liefern.
In den Meetings ist der Scrum Master mit verschiedenen Herausforderungen
konfrontiert. Während der Forming-Phase des Teams (siehe Tab. 2.8) besteht die Heraus-
forderung darin, eine offene und konstruktive Atmosphäre zu schaffen, in der alle ohne
Scheu ihre Sicht auf den letzten Sprint darlegen können. Die erste Retrospektive ist ein
guter Zeitpunkt, um die Feedbackregeln in Erinnerung zu rufen, ggf. erneut bewusst zu
üben und genau auf die Einhaltung zu achten. Diese sind:
• wohlwollende Grundeinstellung: Der Gegenüber ist ein wertvoller Mensch und ich
möchte, dass er/sie noch besser wird.
• immer Positives zurückmelden: Ich benenne etwas, was ich am Gegenüber ehrlich
schätze.
• Ich-Botschaften: Ich spreche stets über meine Wahrnehmung, meine Gefühle, meine
Meinung und meine Veränderungswünsche.
162 3 Agiles Projektmanagement
• formulieren Sie das Bedürfnis, nicht den Mangel: Was hätte ich mir anders
gewünscht. Was würde eine Veränderung für mich bedeuten?
• keine Generalisierung: Ich sage niemals Worte wie „immer“, „dauernd“, „nie“, etc.
In der Performing-Phase (siehe Tab. 2.8) besteht ein starkes Interesse des Teams an
ununterbrochener Arbeit, die Sprint Retrospektiven werden dann eher als lästige Pflicht
als nützlich investierte Zeit gesehen. Um das Ausbreiten einer Verweigerungshaltung zu
verhindern, helfen anonyme Rückmeldungen auf die Fragen oder Kreativitätstechniken,
die den Teilnehmern eine anonymisierte Kritik erlauben. Es lohnt sich, die offenbar
gewordenen Lernfelder und Erfolge angemessen wertzuschätzen und ihre Bedeutung für
die Verbesserung der Zusammenarbeit zu betonen.
Am Ende der Retrospektive muss eine Planung stehen, wie die Erkenntnisse konkret
im nächsten Schritt genutzt werden können.
Kaarten Carrousel
Kaarten Carrousel ist Anbieter von Online-Plattformen für das Design von
individuellen Postkarten, Einladungen und anderen Werbematerialien. Das Unter-
nehmen entschied sich, Scrum für seine Marketingaktivitäten einzusetzen und machte
damit sehr gute Erfahrungen. Insbesondere die Retrospektiven zeigten schon nach
kurzer Zeit umfangreiche Erkenntnisse, welche Elemente von Scrum beibehalten,
geändert oder weggelassen werden sollten. Insgesamt war schon nach 5 Retro-
spektiven klar, dass das Arbeiten nach Scrum für alle Beteiligten ein großer Gewinn
waren, beispielsweise wurde die Produktivität des Teams mithilfe der regelmäßigen
Sprints verbessert und die Arbeitsmotivation stieg aufgrund der gemeinsamen,
visualisierten Ziele. Durch die Retrospektiven konnten andererseits Dinge aufgedeckt
werden, die nicht gut funktionierten. So wurde insbesondere für die Kommunikation
nach außen eine Übersetzung der Story Points in Stunden vorgenommen. Gleichzeitig
wuchs das geschätzte Intervall, wenn die Anzahl der Story Point größer wurde [19].
◄
Kontrollfragen
1. Nennen Sie die Statements des agilen Manifestes.
2. Mit welchen Mitteln wird die Änderungsfreude unterstützt?
3. Welche wesentliche Aufgabe hat ein Scrum Master?
4. Welche Lösungsstrategien gibt es bei Konflikten im Team?
5. Welches Ziel hat die Retrospektive
6. Was ist der Unterschied zwischen einem Product Backlog und einem Sprint Backlog?
7. Welche Grundidee steht hinter dem Planning Poker?
3.7 Agile Erfolgsgeschichten in den Unternehmen 163
Swisscom (Abb. 3.7).
Abb. 3.7 Swisscom
Springer (Abb. 3.8).
Abb. 3.8 Springer
Daimler AG (Abb. 3.9).
Abb. 3.9 Daimler AG
Swedbank (Abb. 3.10).
Abb. 3.10 Swedbank
164 3 Agiles Projektmanagement
Schaeffler (Abb. 3.11).
Abb. 3.11 Schaeffler
ING-DiBa AG (Abb. 3.12).
Abb. 3.12 ING-DiBa AG
DATEV eG (Abb. 3.13).
Abb. 3.13 DATEV eG
BMW (Abb. 3.14).
Abb. 3.14 BMW
Lufthansa (Abb. 3.15).
Abb. 3.15 Lufthansa Industry
Solutions GmbH & Co. KG
Literatur 165
Abb. 3.16 Nachbetrachtung
des gescheiterten Projektes
Robaso der Bundesanstalt für
Arbeit
Literatur
1. Bitkom. (2016). Agilität in Projekten: Veränderung des Projektcharakters und der Unternehmens-
kultur. https://www.bitkom.org/sites/default/files/file/import/AK-PM-Flyer-Agilitaet.pdf.
2. Bärtschi, C. N., Ebert, N., Kaeser, B. F., & Zenklusen, P. (2017). Business Analyse 2017.
Eine empirische Untersuchung im deutschsprachigen Raum und Fallbeispiele aus Unter-
nehmen. Arbeitsbericht des Instituts für Wirtschaftsinformatik. In V. S. Näpflin (Hrsg.), ZHAW
school of management and law. Winterthur. https://core.ac.uk/download/pdf/161264689.pdf.
Zugegriffen: 1. März 2020.
3. Düzardic, E. (2018). Bericht an den Haushaltsausschuss des Deutschen Bundestages. über die
Prüfung des Projekts „Rollenbasierte Oberflächen (ROBASO)“ und weiterer Projekte der
Bundesagentur für Arbeit. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web
&cd=5&cad=rja&uact=8&ved=2ahUKEwjAwqyunYjoAhVPLewKHVPVDuEQFjAEegQIA
RAB&url=https%3A%2F%2F1.800.gay%3A443%2Fhttps%2Fwww.bundesrechnungshof.de%2Fde%2Fveroeffentlichungen%2
Fprodukte%2Fberatungsberichte%2F2018%2F2018-bericht-projekt-rollenbasierte-oberflaechen-
robaso-und-weiterer-projekte-der-bundesagentur-fuer-arbeit&usg=AOvVaw2YlcrOG1o8STB0
0Sn-P7tP. Zugegriffen: 7. März 2020.
4. Bundesagentur für Arbeit: Geschäftsbericht 2018. Zugegriffen: 7. März 2020.
5. Manifest für Agile Softwareentwicklung. (2019). https://agilemanifesto.org/iso/de/manifesto.
html, zuletzt aktualisiert am 31.03.2019. Zugegriffen: 18. Aug. 2019.
6. Ebbinghaus, H. (1885). Uber das Gedachtnis: Untersuchungen zur experimentellien Psycho-
logie. Leipzig: Duncker & Humblot.
7. Johnson, J. (2018). CHAOS report decision latency theory. It is all about the interval. Boston:
The Standish Group international (CHAOS report series).
8. Pols, A. (2019). Scrum – König unter den agilen Methoden|Bitkom Research. https://www.
bitkom-research.de/de/pressemitteilung/scrum-koenig-unter-den-agilen-methoden, zuletzt
aktualisiert am 11.11.2019. Zugegriffen: 11. Nov. 2019.
9. Naujoks, P. The scrum guide. Zugegriffen: 18. Aug. 2019.
10. Ricker, S., & Pütz, H. (2017). „Change engine, while you are flying“: Kulturwandel in der
digitalen Transformation messen und gestalten. Zugegriffen: 1. März 2020.
11. Von der Happiness-Maschine zum führungslosen Chaos: So vergrault der Zappos-Chef seine
Mitarbeiter. (2015). https://t3n.de/news/zappos-management-holacracy-611218/, zuletzt
aktualisiert am 20.05.2015. Zugegriffen: 5. März 2020.
12. Lohmann, D. (2012). … und mittags geh ich heim. Verlag Karl Alber GmbH.
166 3 Agiles Projektmanagement
13. Wake, B. (2003). INVEST in good stories, and SMART tasks. https://xp123.com/articles/
invest-in-good-stories-and-smart-tasks/, zuletzt aktualisiert am 16.02.2011. Zugegriffen: 22.
Sept. 2019.
14. Lawrence, R. (2012). Story splitting flowchart DE. https://agileforall.com/wp-content/
uploads/2012/08/Story-Splitting-Flowchart-DE.pdf. Zugegriffen: 18. Okt. 2019.
15. Tietz, V., Kluge, J., Hahn, C., & Grams, B. (2015). Lernen aus Erfahrung – Vom agilen zum ver-
teilten Präsenzteam. In T. Köhler, N. Kahnwald, & E. Schoop (Hrsg.), Wissensgemeinschaften
2015. 18. GeNeMe-Workshop, TU Dresden, 25./26.06.2015: GeNeMe 2015, Gemeinschaften
in Neuen Medien (Bd. 18, S. 193–202). Dresden: Technische Universität Dresden. Medien-
zentrum; Saechsische Landesbibliothek- Staats- und Universitaetsbibliothek Dresden. https://
tud.qucosa.de/api/qucosa%3A28963/attachment/ATT-0/. Zugegriffen: 7. März 2020.
16. Obmann, C. (2018). Agilitäts-Labor. Wie große Unternehmen wendig wie ein Start-up
werden. Um mit dem Innovationstempo der Start-ups mithalten zu können, müssen Konzerne
flexibler werden. Bosch und Deutsche Bahn haben es ausprobiert. In Handelsblatt, 14.06.2018.
Zugegriffen: 7. März 2020.
17. Berne, E. (1980). Spiele der Erwachsenen: Psychologie d. menschl. Beziehungen (161–173.
Tsd) (rororo: Bd. 6735). Reinbek bei Hamburg: Rowohlt.
18. Hofmann, F. (2016). Ist das noch Scrum oder kann das weg? https://www.produktbezogen.de/
ist-das-noch-scrum-oder-kann-das-weg/. Zugegriffen: 8. März 2020.
19. Verwijs, C. (2016). Scrum for marketing teams: A case study – The liberators – Medium.
https://medium.com/the-liberators/scrum-for-marketing-teams-a-case-study-b650b31d9ab8.
Zugegriffen: 8. März 2020.
20. Dämon, K. (2019). Haufe-umantis: Wählen Sie sich Ihren Chef doch selbst. https://www.wiwo.
de/erfolg/management/haufe-umantis-waehlen-sie-sich-ihren-chef-doch-selbst/13310312.html,
zuletzt aktualisiert am 14.09.2019. Zugegriffen: 22. Sept. 2019.
21. IBM und Microsoft: Die Chronologie einer Trennung. https://www.computerwoche.de/a/ibm-
und-microsoft-die-chronologie-einer-trennung,1133813. Zugegriffen: 18. Okt. 2019.
22. Jene, N. (2013). Agilität als Erfolgsfaktor im Projekt-Controlling von Multichannel-Business
Projekten. Controlling, 25(6), 299–304. https://doi.org/10.15358/0935-0381_2013_6_299.
Fallbeispiele
4
Die nachfolgenden acht Fallbeispiele sollen Ihnen dazu dienen, die zuvor behandelten
Themenbereiche auf konkrete Fälle anzuwenden. Sie beruhen auf fiktiven Vorstellungen,
spiegeln aber die Entstehung von Projekten in der Unternehmenspraxis wider. Die Fall-
beispiele enthalten keine in allen Punkten vollständige Projektbeschreibung. Bitte lassen
Sie bei der Bearbeitung Ihrer Fantasie in sinnvollem Rahmen freien Lauf. Dies gilt ins-
besondere in Bezug auf die Planungsinhalte wie beispielsweise messbare Ziele, Teil-
projekte, Arbeitspakete etc. Nachfolgend präsentiert werden die Projekte von:
• der Schielmann AG
• dem Hammer Forum e. V.
• der Theodor Konrad AG
• der Eventis GmbH
• der Gaming GmbH
• Dorfsparkasse Sankt Augustin
• GroßKauf GmbH
• Rhein-Sieg-Air AG
Wir wünschen Ihnen bei der Bearbeitung der Fallbeispiele viel Erfolg und gutes
Gelingen!
© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer 167
Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021
T. Peters und N. Schelter, Kompakte Einführung in das Projektmanagement,
https://doi.org/10.1007/978-3-658-31194-0_4
168 4 Fallbeispiele
4.1 Schielmann AG
Das erste Ladengeschäft der Schielmann GmbH wurde im Jahr 1970 vom Augen-
optikermeister Karl-Theodor Schielmann in Bonn gegründet. Bereits drei Jahre später
expandierte Schielmann mit zwei weiteren Filialen in Köln, und Düsseldorf.
Der nationale Durchbruch gelang Schielmann 1985 mit der Entscheidung, eine erste
eigene Brillenkollektion zu fertigen und überregional zu vertreiben. Diese und folgende
Kollektionen erfüllen hohe Qualitätsansprüche und stehen für ein außerordentlich
positives Preis-/Leistungsverhältnis. Dadurch entwickelte sich die Schielmann GmbH
zügig zu einem der maßgeblichen deutschen Unternehmen in der Brillenherstellung.
1999 wurde das Unternehmen in eine AG umgewandelt im gleichen Zuge 25 % der
Anteile an die amerikanische BullsEye Group veräußert. Damit wurden beste Voraus-
setzungen dafür geschaffenen, die Produkte der Schielmann AG auch auf den inter-
nationalen Märkten zu vertreiben.
2006 entschloss sich Karl-Theodor Schielmann noch beratend im Vorstand der AG
tätig zu bleiben, den Sitz dem Vorsitzenden jedoch an seinen Sohn Nils Schielmann
abzugeben. Dieser treibt seitdem eine Modernisierung der Unternehmenskultur voran.
Noch heute gilt die Schielmann AG als einer der führenden Hersteller für Brillen-
fassungen, Sonnenbrillen, hochwertige Kontaktlinsen und Brillenzubehör. Derzeit ist die
AG in 9 europäischen Ländern aktiv, betreibt 893 Filialen und beschäftigt rund 5000 Mit-
arbeiter. Die Fertigung der Produkte erfolgt bis heute ausschließlich am Hauptsitz Bonn.
Der Verkauf der Waren erfolgt bis dato ausschließlich über die Filialen vor Ort.
Im Zuge der Modernisierungsabsichten von Nils Schielmann wurde der Leiter der
Marketing-Abteilung damit beauftragt, eine Online-Vertriebsstrategie zu entwickeln.
Durch einen repräsentativen Internetauftritt soll es den Kunden zukünftig möglich sein,
die Produkte auch online bestellen zu können. Der Vorstandsvorsitzende befürchtet,
dass es zu Kompetenzschwierigkeiten bei dem Aufbau der Homepage kommen könnte.
Auch die interne „Technik-Abteilung“, die u. a. auch für die Wartung der PCs zuständig
ist, verfügt nicht über das notwendige Knowhow, um eine Homepage vollständig zu
gestalten. Aus diesem Grund wurden drei Anbieter angefragt, die sich auf die Home-
pageerstellung spezialisiert haben und die Schielmann AG bei der Umsetzung des Vor-
habens unterstützen sollen.
• Die Cable GmbH – Der Marktführer verfügt bereits über jahrelanger Erfahrung bei
der Gestaltung von Webseiten. Allerdings ist Cable auch der teuerste Anbieter.
• Die WWWeasy OHG – Ein neuer Anbieter ohne Referenzen. Der Preis liegt in der
mittleren Kategorie.
• Die Mauszeiger GbR – Ein Discountanbieter, der von ehemaligen Studenten der
Hochschule Bonn-Rhein-Sieg gegründet wurde und das preisgünstige Gestalten
von Webseiten ermöglichen will. Das erste Projekt des jungen Unternehmens steht
allerdings noch aus.
4.2 Hammer Forum e. V. 169
Die Entscheidung über den Anbieter obliegt dem Projektteam. Sie ist in der
Dokumentation jedoch nachvollziehbar dem Vorstand darzulegen.
Im Rahmen des Projektes ist es Herrn Schielmann wichtig, dass der Nutzen aus dem
Projekt klar hervorgeht. Bezüglich der organisatorischen Einbindung des Projektteams
hat er keine Vorgaben gemacht.
Nils Schielmann bewilligt ein Budget in Höhe von 500.000 € und erwartet den
Abschluss des Projektes pünktlich zur Vorstandssitzung in elf Wochen.
Der Hammer Forum e. V. besteht aus Ärzten, Gasteltern, Pflegern, Krankenschwestern
und vielen anderen engagierten Menschen, die in erster Linie ehrenamtliche Hilfe für die
Kinder dieser Welt leisten.
Gegründet wurde das Hammer Forum e. V. 1991 während des Golfkrieges von Ärzten
und Bürgern der Stadt Hamm. Sie wollten der Not und dem Elend, das besonders die
Kinder hart getroffen hatte, nicht länger tatenlos zusehen. Heute engagieren sich in
Deutschland und im benachbarten Ausland über 400 Menschen für erkrankte und ver-
letzte Kinder in aller Welt.
Ziel des Hammer Forums e. V. ist die medizinische Versorgung von erkrankten und
verletzten Kindern aus und vor allem in Kriegs- und Krisengebieten. Hierbei wird die
Hilfe grundsätzlich unabhängig von Religion, Geschlecht oder Nationalität geleistet.
Langfristiges Ziel ist der Auf- und Ausbau von adäquaten Einrichtungen vor Ort,
um die Zahl jener Kinder, die in ihrer Heimat eine adäquate medizinische Behandlung
erhalten, zu vergrößern.
Mit den Projekten vor Ort soll auch „Hilfe zur Selbsthilfe“ geleistet werden. Dies
geschieht einerseits durch die Fortbildung von Ärzten und Pflegepersonal während der
Einsätze des Hammer Forums e. V., andererseits durch den Aufbau stationärer Ein-
richtungen wie z. B. Operationssälen, Kinderstationen oder Gesundheitszentren.
Die Auslandsprojekte des Hammer Forums e. V. sind so vielfältig wie die Länder,
in denen es tätig ist. Ziel der Projekte ist Aufbau einer geeigneten medizinischen Infra-
struktur für Kinder, die an die jeweiligen Verhältnisse vor Ort angepasst wird. Dies
beinhaltet z. B. den Aufbau von Gesundheitszentren oder Ambulanzen für Kinder.
Der fünfköpfige Vorstand von Hammer Forum e. V. hat beschlossen, in Kürze ein
neues Auslands-Hilfsprojekt durchzuführen, dass bereits in Kürze starten soll. Zur-
zeit führt das Kinderhilfswerk kein Auslandsprojekt durch. Gründe hierfür sind, dass
bis zum heutigen Zeitpunkt alle Auslands-Projekte erfolgreich abgeschlossen wurden
und zugleich nicht ausreichend Personalkapazität bei Hammer für ein weiteres parallel-
laufendes Projekt vorhanden war. Darüber hinaus gab es unter den Vorstandsmitgliedern
bisher keine Einigung auf eines der vielen vorgeschlagenen Projekte.
In den letzten acht Jahren haben Absolventen des Fachbereichs Wirtschaft der Hoch-
schule Bonn-Rhein-Sieg sehr verlässliche, gewissenhafte und engagierte Projekte
170 4 Fallbeispiele
geleitet. Der Vorstand hat daher entschieden, dass auch das anstehende Auslandsprojekt
von einem Studenten der Hochschule-Bonn-Rhein-Sieg geleitet werden soll. Dieser soll
selbst sein Projektteam aus dem Pool aller ehrenamtlichen Mitarbeiter des Vereins vor-
schlagen. Alle Mitarbeiter des Hammer Forum e. V. sollen das Projektteam bei ihrer
Arbeit unterstützen. Bezüglich der konkreten organisatorischen Einbindung des Projekt-
teams in den Verein wurden keine genauen Vorgaben gemacht. Im Rahmen des Projektes
ist es dem Vorstand wichtig, dass der Nutzen aus dem Projekt klar hervorgeht.
Das Projekt soll ausschließlich über Spendengelder finanziert werden und ist damit
auf 500.000 € begrenzt. Ziel des Auslandsprojektes ist es, in der kongolesischen Provinz
ein Gesundheitszentrum zu errichten.
Eine zentrale Aufgabe des Projektteams ist es eine geeignete Baufirma für das
Zentrum auszuwählen. Es sind bereits drei Anbieter in die engere Wahl gekommen. Dies
sind:
Die Entscheidung über den Anbieter obliegt dem Projektteam. Sie ist in der
Dokumentation jedoch nachvollziehbar dem Vorstand darzulegen.
Da bereits weitere Auslandsprojekte in Planung sind, hat der Vorstand entschlossen,
dass das anstehende Projekt bis zur Vereinsversammlung in elf Wochen abgeschlossen
sein soll.
Die Theodor Konrad AG wurde 1998 von dem Vater des jetzigen Vorstandsvorsitzenden
Herbert Konrad in Aachen gegründet. Sie zählt mittlerweile zu den führenden Unter-
nehmen in der Automobilbranche. Der Fahrzeughersteller hat einen hohen Marktanteil
bei den Premiumfahrzeugen sowie den Nutzfahrzeugen und vertreibt diese europaweit.
Neben der Fahrzeugherstellung wurden im Jahr 2000 die Geschäftsfelder um einen
konzerneigenen Finanzdienstleister erweitert, der kundenorientierte Finanzierungs-
lösungen für die Kunden der Theodor Konrad AG anbietet.
Die Fahrzeuge und Dienstleistungen werden sowohl an Großkunden als auch Privat-
kunden über insgesamt 192 Filialen vertrieben. Mit 53.000 Mitarbeitern an acht
Produktionsstandorten werden jährlich 800.000 Fahrzeuge hergestellt und diese durch
5400 Mitarbeitern in den Filialen vertrieben.
4.4 Eventis GmbH 171
Der Vorstand um Herbert Konrad hat in der letzten Vorstandssitzung vor einer Woche
entschieden, das Fahrzeugangebot auf die SUV-Branche auszuweiten und zukünftig auch
diese Art von Modellen zu produzieren und zu vertreiben. Im Zuge der Entwicklungen
in der Automobilbranche möchte der Vorstand mit den neuen Modellen gleichzeitig auch
in das Geschäftsfeld der Elektrofahrzeuge einsteigen und mit einem batteriebetriebenen
Modell die Serientauglichkeit testen.
Herbert Konrad hat die Vertriebsabteilung mit einem Projekt beauftragt, anlässlich der
Einführung des ersten seriengefertigten Elektrofahrzeuges im Konzern ein Großevent für
Investoren zu veranstalten. Die Veranstaltung soll so organisiert werden, dass möglichst
viele potenzielle Großkunden und Investoren an dem Event teilnehmen. Im Rahmen des
Projektes ist es dem Vorstand wichtig, dass der Nutzen aus dem Projekt klar hervorgeht.
Eine zentrale Entscheidung für den Erfolg der Veranstaltung wird die Wahl der
Location sein. Diese Entscheidung hat der Vorstand dem Projektteam überlassen, ver-
langt jedoch diese in der Projektdokumentation nachvollziehbar darzulegen. Es sind
bereits drei potenzielle Locations in die engere Wahl gekommen. Diese sind:
• Der Aachener Tivoli – repräsentiert die traditionelle Aachener Kultur und diente
bereits bei zahlreichen Veranstaltungen für ein gehobenes Ambiente. Entsprechend
fallen die Konditionen aus.
• Das Business Forum zu Aachen – bietet ein mittelklassisches Ambiente in einer
standardmäßigen Kulisse zu durchschnittlichen Konditionen.
• Die Mensa der Hochschule Aachen – der Discount-Anbieter für Großevents in
Aachen.
Bezüglich der organisatorischen Einbindung des Projektteams in den Konzern hat die
Geschäftsführung keine Vorgaben gemacht.
Theodor Konrad plant das Event auf der bevorstehenden Automobilmesse in
11 Wochen anzukündigen und erwartet entsprechend bis zu diesem Zeitpunkt den
Abschluss. Insgesamt hat der Vorstand für das Projekt ein Budget in Höhe von 500.000 €
bewilligt.
Die Eventis GmbH wurde 1997 von Norbert Schneider, einem Alumni der Hoch-
schule Bonn-Rhein-Sieg, gegründet und zählt mittlerweile mit 104 Mitarbeitern zu den
führenden Eventagenturen im Kreis Bonn-Rhein-Sieg. Neben der Organisation von
Großveranstaltungen betreut das Unternehmen auch die Umsetzung sowie die Nach-
kontrolle von Events im Kreis Bonn.
Aufgrund unterschiedlichster Kundenanforderungen bietet die Eventis GmbH eine
vielseitige Produktpalette an. Darunter zählen Betriebsfeiern, Geburtstage, Galas und
Bälle. Bei individuellen Kundenwünschen werden diese ebenfalls realisiert.
172 4 Fallbeispiele
• Das Luxury-Hotel – ein höchst repräsentatives Hotel direkt am Rhein gelegen. Es bot
bereits bei zahlreichen Veranstaltungen großer Wirtschaftsunternehmen aus dem Kreis
Bonn in gehobenes Ambiente. Entsprechend fallen die Konditionen aus.
• Der Business Treff zu Bonn – bietet ein mittelklassisches Ambiente in einer
standardmäßigen Kulisse zu durchschnittlichen Konditionen.
• Die Mensa der Hochschule Bonn-Rhein-Sieg – der Discount-Anbieter für Großevents
im Kreis Bonn.
Norbert Schneider plant die Einladungen zu dem Event in elf Wochen zu verschicken.
Da diese detaillierten Angaben zu der bevorstehenden Gala enthalten, wüscht Herr
Schneider den Abschluss des Projektes bis zu diesem Zeitpunkt. Insgesamt hat er ein
Budget in Höhe von 300.000 € bewilligt.
Die Gaming GmbH wurde im Jahr 1990 von den ehemaligen Berufsgamern Lukas
Miller und Patrick Holster in Gladbach gegründet und hat 2013 seinen Firmenhauptsitz
nach Köln in den neu erschlossenen Rheinauhafen verlegt.
Die GmbH vertreibt bundesweit in 256 Filialen verschiedenste Spiele für Video-
spielkonsolen. Die Filialen der Gaming GmbH sind sehr aufwendig gestaltet. Umfragen
der Vertrieb-Abteilung haben ergeben, dass die Kunden besonders auf Rabattaktionen
achten und rund 75 % der Kunden regelmäßig an den Bonusprogrammen der GmbH teil-
nehmen.
120 der Filialen sind nicht an den Hauptserver der Gaming GmbH in Köln
angeschlossen, da an diesen Standorten keine Datenleitungen vorhanden sind. Dadurch
ist es diesen Filialen nicht möglich, aktuelle interne Informationen aus dem Intranet zu
4.6 Dorfspaßkasse Sankt Augustin 173
erhalten. Folglich sind diese Filialen auch über besondere Preisaktionen oder über von
der Marketing-Abteilung entwickelte neue Bonusprogramme erst Tage später informiert,
wenn von der Vertrieb-Abteilung die neusten Meldungen ausgedruckt und per Post an
diese Filialen versendet sind. Die nicht an das Firmennetzwerk angeschlossenen Filialen
leiden daher permanent unter einem Informationsrückstand. Dies macht sich auch bei
den Umsätzen bemerkbar.
Die Geschäftsführung wurde vergangene Woche von einem Reporter des Spieglein
Magazins kontaktiert, dem im Rahmen von Recherchen für einen Zeitungsartikel zum
Teil stark abweichende Preise innerhalb der Filialen der Gaming GmbH aufgefallen
sind. Lukas Miller konnte sich mit dem Reporter darauf einigen, diesen Umstand in der
Reportage nicht zu erwähnen, sollte der Missstand bis zur Veröffentlichung des Artikels
in drei Monaten behoben sein.
Der Geschäftsführer Patrick Holster erteilt aus diesem Grund dem Leiter der IT-
Abteilung den Auftrag, innerhalb der kommenden elf Wochen ein einheitliches Firmen-
netzwerk aufzubauen, dass von den Filialen auch über ein mobiles Datennetzwerk
erreicht werden kann. Trotz dieser Vorgabe ist dem Vorstand wichtig, dass der Nutzen
aus dem Projekt klar hervorgeht.
Die IT-Abteilung ist darüber hinaus zur erfolgreichen Implementierung des neuen
Firmennetzwerkes damit beauftragt, einen Anbieter für die mobilen Datennetzwerke zu
finden. Es sind bereits drei Anbieter in die engere Wahl gekommen. Dies sind:
• Die MobileSpeed GmbH – Der Marktführer, der ein bekanntes gutes Produkt
anbietet, allerdings auch der teuerste Hersteller ist.
• Die ITSolutions OHG – Ein neuer Anbieter ohne Referenzen. Der Preis liegt in der
mittleren Kategorie.
• Die ITeasy GbR – Ein Discountanbieter, der von ehemaligen Studenten der Hoch-
schule Bonn-Rhein-Sieg gegründet wurde und ein gutes Standardprodukt bietet. Das
erste Projekt des jungen Unternehmens steht allerdings noch aus.
Die Entscheidung über den Anbieter obliegt dem Projektteam. Sie ist in der
Dokumentation jedoch nachvollziehbar dem Vorstand darzulegen.
Bezüglich der organisatorischen Einbindung des Projektteams hat die Geschäfts-
führung keine Vorgaben gemacht.
Patrick Holster bewilligt ein Budget in Höhe von 500.000 € und erwartet den
Abschluss des Projektes pünktlich zur Gesellschafterversammlung in elf Wochen.
Der Vorstand der Dorfspaßkasse Sankt Augustin möchte die Wettbewerbsfähigkeit seiner
kleinen Spaßkasse verbessern und eine etwaige Fusion mit der Großspaßkasse Köln
vermeiden. Mit dem bisherigen Geschäftskonzept ist die Dorfspaßkasse nicht mehr
174 4 Fallbeispiele
ettbewerbsfähig und müsste im Falle einer sich verschlechternden Finanzlage auf kurz
w
oder lang mit dem „Großkapital“ fusionieren.
Hauptproblem sieht der Vorstand u. a. im Internetauftritt. Zudem ist das Software-
system, mit dem gearbeitet wird, fast 30 Jahre alt und nicht miteinander integriert
(Insellösungen). Außerdem liegen eine schlechte individuelle Kundenbetreuung und
Kundenakquise vor.
Der Vorstand möchte dem Kunden über das Internet u. a. denselben Service wie eine
Direktbank anbieten können. Der Kunde soll über das Internet selbst Verträge sowie
persönliche Daten ändern können; Festgeldkonten, Versicherungen, Anlagekonten sowie
Sparkonten und Girokonten sollen abgeschlossen oder diese auch von dort aus gekündigt
werden können. Ferner sollen diese vom Kunden eingegebenen Daten dann gleich-
zeitig automatisch in die neuen Systeme übergehen können, sodass Doppelarbeiten,
Redundanzen und Inkonsistenzen in der Datenerfassung und -verwaltung vermieden
werden.
Zusätzlich sollen direkte Terminvereinbarungen über das Internet durchgeführt
werden können.
Die acht verschiedenen Softwaresysteme, die nicht miteinander integriert sind und zu
Doppelarbeiten, Datenredundanzen und Dateninkonsistenzen führen, sollen durch ein
einheitliches integriertes ERP-System abgelöst werden.
Ein CRM-System soll die individuelle Kundenansprache, -betreuung und -akquise
wesentlich verbessern. Es soll insbesondere im späteren mobilen Vertrieb eingesetzt
werden und auf wichtige Kundentermine in den Filialen vorbereiten. Auch gezielte
Marketing-Maßnahmen sollen dadurch besser ausgearbeitet werden können.
Ein Data Warehouse System sorgt zudem für eine schnelle und einfache Analyse
wichtiger Ist-Daten. Aufwendige Abfragen werden dadurch vermieden. Das Controlling
kann so schnell und bequem dem Vorstand über die aktuelle Lage informieren. Die
Planung und Organisation können dann die entsprechenden Maßnahmen planen, ein-
leiten und realisieren.
Der Vorstand hat ausgerechnet, dass eine Umsetzung seiner Pläne etwa 20 der
109 Mitarbeiter der Dorfspaßkasse freisetzen würde. Diese könnten dann im mobilen
Kundenvertrieb eingesetzt werden und einen höheren Kundenservice durch die kleine
Spaßdorfkasse garantieren.
Ohne solche Maßnahmen kann die Dorfspaßkasse Sankt Augustin jedoch maximal
noch zwei Jahre unabhängig bleiben bis eine Fusion aufgrund der dann schlechten
Finanzlage mit der Großspaßkasse Köln unabdingbar ist. Betriebsbedingte Kündigungen
und eine hohe Mitarbeitermobilität im ganzen Rheinland wären dann die Folge für die
Angestellten. Die Planung, Realisierung und Einführung dürfen also maximal ein Jahr
dauern. Danach müsste geschaut werden, ob die Maßnahmen die kleine Spaßkasse
wieder auf Kurs bringen würden.
Der Vorstand stellt sich für die Planung, Realisierung und Einführung einen Zeitraum
von insgesamt neun Monaten vor.
4.6 Dorfspaßkasse Sankt Augustin 175
Für die organisatorische Umsetzung der Pläne sollen drei Mitarbeiter, die mit den
einzelnen Prozessen der Spaßkasse vertraut sind, verantwortlich gemacht werden. Da
es an qualifiziertem IT-Personal in der Dorfspaßkasse fehlt, sollen zudem zwei externe
Wirtschaftsinformatiker für die reibungslose Umsetzung der Technik für die Dauer
des IT-Projektes eingestellt werden. Der Chef-Informatiker der Dorfspaßkasse soll die
technische Umsetzung leiten.
Da bereits die Einführung des Online-Bankings bei den Mitarbeitern auf wenig Ver-
ständnis getroffen ist, muss zudem für die Pläne in allen Filialen und bei allen Mit-
arbeitern geworben werden. Die Integration der Softwaresysteme soll im einzelnen
folgenden Nutzen bieten:
Der erweiterte Internetauftritt soll zudem der Dorfspaßkasse den Charme bzw. die Vor-
teile einer Direktbank geben, gleichzeitig jedoch durch den neuen mobilen Kundenver-
trieb die Betreuung verbessern und den Umsatz erhöhen.
Gleichzeitig sollen dadurch vor allem wieder junge Kunden herangezogen und der
Service für die ältere Generation erhöht werden.
Im neuen Internetauftritt sollen dem Kunden nicht nur viele Informationen über die
Produkte zur Verfügung gestellt werden, sondern ihm auch der Weg zur Filiale für an
sich unwesentliche Vorgänge erspart werden.
Da das Projekt drängt, möchte der Vorstand die neue Softwarelösung als Big Bang
durchführen. Diese Art der Einführung ist jedoch sehr risikoreich; evtl. wäre eine schritt-
weise prozessorientierte Einführung sinnvoller, die jedoch etwa drei bis vier Monate
länger dauern würde. Als mögliche Softwarealternativen stellen sich folgende Anbieter
vor:
• SAP – Banking: ERP, DW sowie CRM werden in einem Paket geliefert, von den
externen Beratern implementiert und auf Wunsch werden die Mitarbeiter der
Spaßkasse geschult. Allerdings bietet diese Standardsoftware viel zu viele Funktionen
176 4 Fallbeispiele
an, die die Dorfspaßkasse nicht braucht, ist zudem die mit weitem Abstand teuerste
Alternative.
• ERP Mega, CRM Toll und DW Data sind drei Spezialsoftwarehersteller, die die
einzelnen Softwaresysteme einzeln anbieten. Je nach Wunsch können diese mit ver-
schiedenen Funktionen ausgestaltet und letztlich miteinander integriert werden. Diese
Alternative ist ca. 30 % billiger. Der Nachteil ist jedoch, dass die vollendete Software-
lösung von drei verschiedenen Herstellern stammt. Etwaige Wartungsarbeiten können
dadurch erschwert werden. Die Installation erfolgt zwar durch deren Fachpersonal,
Schulungen werden jedoch nicht angeboten.
• Der Billiganbieter Software Super-Cheap bietet sehr wenige Funktionen an, ist jedoch
extrem günstig (noch mal um ca. 30 %) und auch eine komplette Softwarelösung nur
eines Herstellers. Allerdings kann kein Service erwartet werden. Die Implementierung
muss selbst durchgeführt werden. Fehlende Systemfunktionen müssen teuer hinzu-
gekauft werden (zusätzliche Softwarekomponenten sind doppelt so teuer wie bei SAP
Banking).
Nachdem die Entscheidung über die Standardsoftware erfolgt ist, muss das Customizing
durchgeführt werden. Dazu gehören:
Die drei für die Organisation zuständigen Mitarbeiter sind voll und ganz im operativen
Tagesgeschäft eingebunden. Sie müssen die langwierigen, z. T. widersprüchlichen Daten
in der alten Systemsoftware verwalten. Solange die neue Software nicht eingeführt ist,
sind diese Mitarbeiter nur die Hälfte ihrer Arbeitszeit verfügbar. Langjährige Mitarbeiter
(20 Mitarbeiter) können ggf. für das „Großprojekt“ zusätzlich rekrutiert werden, da sie
über die entsprechenden Kenntnisse im Bereich der Organisation verfügen.
Der leitende Informatiker der Dorfspaßkasse Sankt Augustin kann für die Dauer der
Systemeinführung für die Hälfte seiner wöchentlichen Arbeitszeit in das Projekt ein-
gebunden werden. Die für die Dauer zusätzlich eingestellten Fachinformatiker werden
voll verfügbar sein.
Nach einer Vielzahl von Beschwerden seitens der Mitarbeiter über die Handhabung
der Arbeitszeiterfassung, hat der Personalvorstand der GroßKauf GmbH & Co. KG
beschlossen, die Personaleinsatzverwaltung zu erneuern. Die GroßKauf GmbH & Co.
KG ist das führende Großhandelsunternehmen welches 1500 Filialen in Deutschland
betreibt. Die Produktpalette des Unternehmens umfasst Lebensmittel, Bio- Lebensmittel
4.7 GroßKauf GmbH 177
sowie Produkte des alltäglichen Gebrauchs. Außerdem ist die GroßKauf GmbH & Co.
KG an zwei kleineren Einzelhandelsketten mit jeweils 15 % beteiligt, welche national
und international tätig sind.
Die Hauptzentrale des Konzerns sitzt in Sankt Augustin. Die Geschichte des Unter-
nehmens begann im Jahre 1976 und wurde als Familienbetrieb der Cousins Manfred
Groß und Ulrich Kauf in Bonn-Beuel gegründet. Die Filialen des Konzerns werden von
34 Hauptzentrallagern beliefert, die die Regionalverwaltungen beinhalten. Im Durch-
schnitt ist eine Regionalverwaltung für ca. 44 Filialen verantwortlich. Die Filialen sind
bis auf die Personaleinsatzverwaltung bereits an ein einheitliches Warenwirtschafts-
system angeschlossen.
Bisher erfolgt die Personaleinsatzverwaltung durch die Filialleiter mittels handschrift-
licher Listen, wobei das Erstellen dieser Listen mit erheblichem Arbeitsaufwand ver-
bunden ist. Die Listen wurden zur Abrechnung an die zuständigen regionalen Zentralen
gefaxt und dort ins System übertragen. Bei der Übertragung schleichen sich laufend
Fehler ein, wobei eine Manipulation der Arbeitszeiten nicht ausgeschlossen werden
kann.
Es soll eine computergesteuerte konzernweite Personaleinsatzverwaltung eingeführt
werden. Die Software soll den Personalverantwortlichen ermöglichen, die Arbeits-
zeiten der Mitarbeiter am Computer zu planen, zu kontrollieren und anzupassen. Die
gespeicherten Daten werden automatisch an einen zentralen Server übermittelt. Die
Regionalverwaltungen können diese Daten zur direkten Kostensituationsübersicht nutzen
und eine konstante Situationsüberwachung (Kontrolle Arbeitsrechtlich, Personalkosten,
Personalzeiten, Urlaub, …) gewährleisten. Die Abrechnung der Arbeitszeiten soll in
Zukunft nicht mehr in den Regionalverwaltungen, sondern direkt in der Konzernzentrale
erfolgen. Die Filialleiter sollen die Arbeitspläne am Computer erstellen. Die Mitarbeiter
sollen sich in Zukunft mittels einer automatischen Arbeitszeiterfassung am System an-
und abmelden. Die minutengenaue Zeiterfassung ist dabei besonders wichtig. Bei einer
Kontrolle durch die Gewerkschaft wurde bemängelt, dass die Arbeitszeiten nur im
15-mintakt aufgeführt wurden. Die Arbeitszeiterfassung muss daher der strengen DIN-
Norm AZ4711 gerecht werden.
Das Projektmanagement hat vom Personalvorstand die Aufgabe bekommen eine
Personaleinsatzsoftware zu installieren. Die Systementscheidung liegt in der Hand der
Abteilung, diese muss aber dem Personalvorstand präsentiert werden. Das Projektteam
muss vor Beginn des Projektes zusammengesetzt werden. Da es um die konzernweite
Einführung einer neuen Software geht, spielt die IT-Abteilung eine sehr große Rolle. Die
IT-Abteilung ist derzeit mit 25 Mitarbeitern besetzt und pflegt eine intensive Zusammen-
arbeit mit der Hochschule Bonn-Rhein-Sieg. Die Abteilung wird daher dauerhaft von
zwei bis vier Studierenden unterstützt.
Zudem ist anzumerken, dass der IT-Bereich zwar fachlich über eine gewisse
Weisungsbefugnis verfügt, in wirtschaftlichen Fragen waren bisher jedoch die Regional-
verwaltungen für sich selbst verantwortlich.
178 4 Fallbeispiele
Zunächst ist ein Testlauf des Systems in einer Regionalverwaltung und den zugehörigen
Filialen geplant. Beim ersten Testlauf soll nur das Zusammenspiel zwischen der Regional-
verwaltung und den angeschlossenen Filialen getestet werden. Die Anforderungen an die
Testverwaltung sind von großer Bedeutung. Die Testergebnisse sind nur dann repräsentativ,
wenn die angeschlossenen Filialen mindestens 10–15 Mitarbeiter führen und den Firmen-
standards entsprechen. Im Zweiten soll die Konzernzentrale mit eingebunden werden. Zur
konzernweiten Einführung ist eine intensive Schulung aller Mitarbeiter notwendig. Die
Verantwortung dafür hat die GroßKauf GmbH & Co. KG zu tragen. Wobei in der gleichen
Schulung die neuen Firmengrundsätze übermittelt werden sollen.
Bevor der erste Testlauf beginnen kann, müssen die Kaufentscheidung und das
Customizing abgeschlossen sein. Folgende Unternehmen haben ein Angebot für dieses
System eingereicht:
• SAP – der Weltmarktführer, der ein bekanntes sehr gutes Produkt anbietet, allerdings
auch der teuerste Hersteller ist. SAP bietet das komplette Customizing und die
Implementierung als Komplettpaket zum Festpreis an. Die GroßKauf AG arbeitet
bereits mit dem Warenwirtschaftssystem von SAP.
• AROCLE – ein neuer Anbieter ohne Referenzen. AROCLE bietet das Customizing
an, die Implementierung erfolgt jedoch über einen unbekannten Subunternehmer.
Muss in das vorhandene Warenwirtschaftssystem integriert werden.
• ALDIIT – ein Unternehmen welches branchenspezifische IT-Lösungen anbietet und
bereits für die Konkurrenz ein ähnliches System entwickelt hat. Die Implementierung
muss selbstständig erfolgen und ein Customizing ist nicht möglich.
Der IT-Bereich der Konzernzentrale verfügt über 25 Mitarbeiter, von denen acht mit
IT-Administration beschäftigt sind. Die restlichen Mitarbeiter sind in momentane IT-
Projekte eingebunden, die bis Ende 2010 beendet sind. Das neue Projekt kann erst nach
Beendigung der bestehenden Projekte begonnen werden.
Parallel zur Softwareauswahl muss ein Anbieter gesucht werden, der die Geräte zur
automatischen Arbeitszeiterfassung liefert und installiert. Die Lieferung der Arbeitszeit-
erfassungsgeräte nimmt mindestens 6 Wochen in Anspruch. Die Geräte müssen bereits
beim ersten Testlauf voll zur Verfügung stehen und einsatzbereit sein. Mit der Lieferung
kann nur ein spezieller Logistikdienstleister beauftragt werden. Das Lieferrisiko über-
nimmt die GroßKauf GmbH & Co. KG.
4.8 Rhein-Sieg-Air AG
Der Vorstand der RSA AG hat beschlossen, die Kundenbindung entscheidend zu ver-
bessern. Der Konzern bietet Flüge in ganz Deutschland an. Da noch kein einheitliches
System zur Erfassung, Speicherung und Weiterverarbeitung von Kundendaten besteht,
bleiben die Kunden anonym. Dadurch ist eine kundenspezifische Ansprache nicht möglich.
4.8 Rhein-Sieg-Air AG 179
Der IT-Bereich hat vom Konzernchef den Auftrag erhalten, ein Customer-
Relationship-Management-System (CRM) zu implementieren. Es sollen möglichst viele
Informationen über die Kunden und deren Flugverhalten erfasst und ausgewertet werden.
Somit kann besser auf die individuellen Bedürfnisse der Kunden eingegangen werden.
Ihr IT-Bereich soll das Einführungsprojekt in Absprache mit dem Marketing ver-
antworten. Das CRM-System soll folgenden Nutzen stiften:
Des Weiteren ist anzumerken, dass der IT-Bereich zwar fachlich über eine gewisse
Weisungsbefugnis verfügt, die Akzeptanz für neue Systeme im Unternehmen jedoch
äußerst gering ist. Das bedeutet, dass Sie für Ihr Projekt entsprechende Werbung machen
müssen.
Von der sukzessiven Implementierung und dem Ausbau des CRM-Systems muss
zunächst die Auswahl erfolgen, welchen Anbieter man mit welcher Basissoftware
favorisiert. Es sind bereits drei Anbieter in die engere Wahl genommen. Dies sind:
• Macrohard – Der Marktführer, der ein bekanntes gutes Produkt anbietet, allerdings
auch der teuerste ist. Macrohard bietet auch das Customizing und die Einbindung an,
entweder als Komplettpaket oder als Unterstützung in Form von Beratung unserer
Experten im IT-Bereich.
• Mega Office – ein neuer Anbieter ohne Referenzen. Mega Office bietet die Anpassung
an, die Einbindung erfolgt allerdings durch einen Unterauftragsnehmer. Der Preis
liegt in der mittleren Kategorie.
• Aldito-System – ein Billiganbieter, der ein gutes Standardprodukt bietet. Die
Anpassung übernimmt Aldito System nicht.
Sie treffen in Ihrem Projekt die Vorentscheidung über den Anbieter und legen Ihre
Präferenz – gut begründet – dem Konzernvorstand zur Entscheidung vor.
Wenn die Entscheidung getroffen ist, beginnt die zweite Phase: das Customizing der
Software (Entwickeln der eigentlichen Lösung). Dazu gehören vor allem:
Ihr IT-Bereich verfügt über ca. 50 Mitarbeiter, von denen vier bereits in anderen Unter-
nehmen mit CRM-Systemen gearbeitet haben. Im Marketing-Bereich arbeiten hingegen
deutlich mehr Mitarbeiter, die jedoch nur wenig Erfahrung mit CRM-Systemen haben.
Momentan sind 20 Mitarbeiter in Ihrem Bereich in internen Projekten gebunden und
weitere 26 Mitarbeiter sind für das operative Geschäft zwingend erforderlich. Einige
Projekte laufen in diesem Monat aus, sodass sechs Mitarbeiter wieder zur Verfügung
stehen. Allerding ist anzumerken, dass – sofern Sie alle zehn Mitarbeiter aus dem IT-
Bereich für Ihr Projekt abstellen – Ihr Bereich in den nächsten zehn Monaten voll aus-
gelastet ist. Folglich bleibt keine Zeit mehr für Kleinaufträge bzw. Systembetreuung
übrig.
Es ist bisher des Öfteren vorgekommen, dass Ihre internen Projekte nicht zur
Zufriedenheit des Konzernvorstandes gelaufen sind. Ein Mitglied der Dezernentenrunde
ist Ihnen jedoch wohl gesonnen und hat gegen einige Widerstände doch erreicht, dass
dieser Auftrag nicht an einen externen Dienstleister vergeben wurde.
Das Projektteam trifft die Entscheidung über den Anbieter, entwirft eine Projekt-
planung und begründet diese in der Projektdokumentation.
Antworten auf die Kontrollfragen
5
5.1 Grundlagen
© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer 181
Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021
T. Peters und N. Schelter, Kompakte Einführung in das Projektmanagement,
https://doi.org/10.1007/978-3-658-31194-0_5
182 5 Antworten auf die Kontrollfragen
5.2.1 Projektstart
5.2.2 Projektorganisation
5.2.3 Projektplanung
3. Abweichungsanalyse durchführen
4. Optimierungen vornehmen
6. Welche Kostenarten fallen in Projekten an?
– Personalkosten
– Sachkosten,
– Materialkosten,
– Kapitalkosten
– kalkulatorische Kosten
7. Welche möglichen Risiken sind bei einer Risikoplanung zu berücksichtigen?
Mangelnde Sorgfalt, Missverständnisse, Unvermögen z. B. fehlendes Know-how,
Unsicherheit auf Grund von Informationsmangel, äußere Einflüsse oder Zufälle
können während einer Projektdurchführung auftreten. Diese Risiken sind jeweils zu
identifizieren und zu berücksichtigen.
5.2.5 Projektreporting
5.2.6 Projektabschluss
A äußerer, 100
Ablaufplanung, 76, 78 qualitativer, 36
Ablauf- und Terminplanung, 76 quantitativer, 36
Abschlussphase, 14 Einflussgröße
Abweichungsanalyse, 90, 113 organisatorisch-soziale, 34
Adjourning-Phase, 66 sachlich-inhaltliche, 34
Akzeptanzkriterien, 145 Ende-Anfang-Beziehung, 80
Allparteilichkeit, 156 Ende-Ende-Beziehung, 80
Anfang-Anfang-Beziehung, 80 Entscheidungsträger, 48
Anfang-Ende-Beziehung, 80 Entwicklungsteam, 148
Anordnungsbeziehung, 79 Eskalationsmanagement, 126
Arbeitspaket, 72
Aufgabenboard, 153
Auftraggeber, 57 F
Fertigstellungswertanalyse, 118
B
Backlog Item, 139 G
Bedarfsermittlung, 90 Gantt-Diagramm, 86
Bottom-Up-Verfahren, 73 Gegenstromverfahren, 73, 74
Burndown-Chart, 153 Gesamtbudget, geplantes, 119
Gesamtprojektrisiko, 104
D
Daily, 140, 152 I
Daily Scrum, 152 Initialisierungsphase, 11
Definitionsphase, 12, 67 Inkrement, 159
Detaillierung, 150 Interdisziplinarität, 2, 181
Dienende Führung, 149 INVEST, 151
E K
Earned Value Analyse, 118 Kanban-Board, 153
Einfluss Kapazität, 90
© Der/die Herausgeber bzw. der/die Autor(en), exklusiv lizenziert durch Springer 189
Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2021
T. Peters und N. Schelter, Kompakte Einführung in das Projektmanagement,
https://doi.org/10.1007/978-3-658-31194-0
190 Stichwortverzeichnis
T
Taskboard, 153 W
Teambesprechung, 111 Wert, geplanter, 119
Teamentwicklung, 65
Team
selbstorganisiertes, 148 Z
selbstverantwortliches, 141 Zielformulierung, 28
Termindruck, 2, 181 Zielkonflikt, 30
Timeboxing, 140 Zielsystem, 30
Top-Down-Verfahren, 73 Zufall, 100
Trendanalyse, 116
Tuckman Modell, 65