"Projektmanagement"

"Projektmanagement" 

Reinhard Ludes, HS Magdeburg 

Stand 2007-01-24 

1

Voraussetzungen 

• Keine fachlichen (!) 

• Aber: Gute Laune ☺, zumindest Motivation! 

Lernziele der Vorlesung 

• Fundamente: Begriffe Projekte, Projektmanagement, 

Unternehmensorganisation, Einbindung PM in die Organisation 

• Grundlegende Techniken und Methoden des PMs 

Lernziele heute 

• Gegenseitiges Kennenlernen 

• Überblick über wichtige Begriffe und Ziele des 

Projektmanagements 

2

Wichtiger Hinweis 

Das zum Ende der Vorlesung herauskommende 

Manuskript ist zur Unterstützung gedacht (> kein 

direktes Mitschreiben “en gros” nötig). 

Es kann und soll das selbständige Erarbeiten der 

Inhalte der Vorlesung nicht ersetzen! 

3

Literaturhinweise 

In der angegebenen Reihenfolge; Signaturen der Hochschulbibliothek MD 

• Projektmanagement für Dummies; WL11510-537 

• Manfred Burkhard "Projektmanagement", Siemens; 1997; 

WL11510-054 

• WL11510-496 

• WL11510-691 

4

Noch eine Bitte 

☺ 

5

Gliederung / Inhalte 

• Definition, Ziele und Aufgaben des PM 

• Projektorganisation vs. Betriebsorganisation 

• Projektziele und Projektvision, Risikoanalyse 

• Meilensteinpläne, Projektstrukturplanung und Terminpläne, 

Phasenarbeitspläne 

• Projektüberwachung, Projektstatusberichte 

• Netzplantechnik 

• Aufwands-/Kostenschätzung 

• Alternative Projektstrategien/PM-Modelle 

• Systematischer Projektabschluss 

• Reserve, evtl. Investitionsbeurteilung oder PM-Fallstudie 

• Klausur 

6

Projektmanagement - Stichworte 

• “Sichtweise 1” = Betriebswirtschaftliche Sichtweise 

(„Soziotechnisches System“) 

• “Sichtweise 2” = Mathematische Sichtweise („Operation 

Research“) 

• Unternehmensorganisation 

• Projektmanagement im betrieblichen Umfeld 

• Projektorganisation 

• Produkt-/Projektstrukturplan und technische Planung 

• Risikomanagement 

• Terminplanung 

• Netzplantechnik 

• Einsatzmittelplanung 

• Kostenplanung 

7

Projekte – Anwendungsgebiete, Ziele, Inhalte 

• Forschungs-P. (-> “Erforschung der unsterblichen Seele des 

Maikäfers”) 

• Entwicklung-P. (-> Entwicklung eines neuartigen Getriebes) 

• Fertigungs-P. (-> Erstellung eines geeigneten 

Fertigungsprozesses für das Getriebe) 

• Management-P. (-> Implementierung einer neuen 

Führungsstruktur, “wie kriegen wir den alten Chef los”) 

• Investitions-P. (-> Erneuerung einer Fertigungsstrasse) 

• Consulting-P. (-> Erhöhung der Wirtschaftlichkeit des beratenen 

Unternehmens) 

• IT-P. (-> Einführung einer neuen Software, z.B. SAP) 

... 

8

Begriff, Merkmale von Projekten 

Was ist ein Projekt? – Anworten: 

Ein Projekt ist eine besondere, umfangreiche Aufgabe mit hohem 

Schwierigkeitsgrad und Risiko. 

Aufgaben,die außergewöhnliche Vorhaben sind, werden in der 

Regel als Projekte bezeichnet. 

Projekte sind zeitlich prinzipiell begrenzte Aufgaben von relativer 

Neuartigkeit, die ein auf die Steuerung von „normalen“ 

Daueraufgaben eingerichtetes Management vor besondere 

Probleme stellt. 

9

Definition „Projekt“ 

Nach DIN 69901 lautet die Definition: 

„Vorhaben, das im wesentlichen durch Einmaligkeit der 

Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.B.: 

◊ - Zielvorgabe 

◊ - zeitlich, finanzielle oder andere Begrenzungen 

◊ - Abgrenzungen gegenüber anderen Vorhaben 

◊ - projektspezifische Organisation.” 

Oder allgemein: 

Ein Projekt ist eine besondere, umfangreiche und zeitlich 

begrenzte Aufgabe von relativer Neuartigkeit mit hohem 

Schwierigkeitsgrad und Risiko, die in der Regel enge 

fachübergreifende Zusammenarbeit aller Beteiligten fordert. 

10

Begriff und Merkmale von Projekten 

Ein Projekt ist ein einmaliges, komplexes Vorhaben, durch das in 

begrenzter Zeit mit begrenzten Mitteln ein bestimmtes Ziel erreicht 

werden soll. 

Projektmerkmale stellen eine mögliche Abgrenzung des Projektes 

gegenüber anderen Aufgaben im Unternehmen dar. 

Für ein Projekt treffen folgende Merkmale zu: 

• Zu erreichendes, eigenständiges Ziel 

• Zeitliche, finanzielle und personelle Begrenzungen 

• Einmaligkeit, keine Routinetätigkeit 

• Komplexität, gekennzeichnet durch 

◊ Erforderliche Mindestgröße 

◊ Mehrere beteiligte Bereiche 

◊ Risiko eines Fehlschlags 

11

Was ist Projektmanagement? 

• Projektmanagement ist eine Führungskonzeption oder ein 

Führungsinstrument. 

• Direkte, fachübergreifende Koordination der Planungs-, 

Steuerungs- und Entscheidungsprozesse, bei fachübergreifenden 

Aufgabenstellungen 

• Systematische Anwendung erprobter Verfahren aus den 

Gebieten der Führungslehre, Organisationstechnik, 

Informationstechnik und der Entscheidungstheorie 

Quelle: G.C. Heuer, Projektmanagement 

12

Definition „Projektmanagement“ 

Nach DIN 69901 lautet die Definition: 

„ Gesamtheit von Führungsaufgaben, -organisation, -techniken und 

–mittel für die Abwicklung eines Projektes.“ 

Oder allgemein: 

Projektmanagement ist eine Führungskonzeption für direkte 

fachübergreifende Koordination von Planung, Entscheidung, 

Realisierung, Überwachung und Steuerung bei der Abwicklung 

interdisziplinärer Aufgabenstellungen. 

13

Historische Entwicklung 

14

Warum „Projektmanagement“? 

• Reduzierung von Risiken bei der Projektarbeit aufgrund von: 

◊ - Fehlbesetzungen - Konfliktsituationen 

◊ - Konkurrenzsituationen - mangelnden Informationsfluss 

◊ Kompetenzstreitigkeiten und Kompetenzüberschreitungen 

• Anwendung professioneller Projektarbeit 

• Praktizierung echter Teamarbeit 

• Förderung der persönlichen und fachlichen Qualifikation der 

Projektmitarbeiter 

• Steigerung der Kreativität und Innovationsfähigkeit 

15

Magisches Dreieck: Ziele des 

„Projektmanagement“ 

Projektmanagement ist eine umfassende Führungskonzeption, die 

dazu dient, komplexe Vorhaben zielorientiert und effizient 

abzuwickeln. 

16

Projektmanagement-Teilprozesse 

Stichwort „umfassende Führungskonzeption“ 

Nach Project Management Institute fünf Teilprozesse: 

• Projektstart: Projektziele spezifizieren, die Organisation auf das 

Projekt einstellen und zu dessen Unterstützung verpflichten. 

• Projektplanung: Ausarbeitung und regelmäßige Aktualisierung 

eines Plans mit dem die Projektziele realisiert werden sollen. 

• Projektsteuerung: Laufende Koordination, Kommunikation und 

Information, um Planung bzw. Projektziele zu erreichen. 

• Projektüberwachung: Verfolgen des Projektfortschritts und 

Erkennen erforderlicher Korrekturmaßnahmen. 

• Projektabschluss: Akzeptanz der Projektergebnisse 

herbeiführen und Auflösung der Projektorganisation. 

⇒ Kurz: Projekterfolg = Vorbereitung x Ausführung 

17

PM-Teilprozesse im Einzelnen 

Bild: FH Darmstadt 

18

Erfolgreiche Projekte benötigen drei 

Standbeine 


19

Naive Sicht von Projektmanagement 


20

Fehler und Verschwendung in Projekten ohne 

geregelte Vorgehensweise 

nach FH Darmstadt 

• zu realisierenden Funktionalität nimmt um 25 - 50 % zu/ab, 

häufig unbemerkt 

• Fehler werden erst spät im Projekt behoben, zu sehr hohen 

Kosten 

• Man ist immer auf der Suche nach dem „letzten Fehler“ 

• Bei Software-Projekten: Software wird während der Systemtests 

redesignt und neu geschrieben (-> geht bei Hardware nicht so 

einfach....) 

• Nachtarbeit während der Systemintegration 

• Entwickler verlieren Quellcode und finden ihn nicht wieder 

• Hektik beim Projekt-Endspurt: Tägliche Neuschätzung des 

Auslieferungstermins und laufende Neufestlegung der 

Fehlerabarbeitungsreihenfolge 

21

Realistische Sicht von Projektmanagement 

Bild: nach FH Darmstadt 

22

Gute Prozesse sind praktizierter gesunder 

Menschenverstand 


23

Projektorganisation - 

Unternehmensorganisation 

• Projekte finden innerhalb von Unternehmen statt. 

• Die Projektorgansation ist Teil der Unternehmensorganisation. 

Resultierende Fragen: 

• Wie ist ein Unternehmen organisiert? 

• Wie kann ein Projekt organisiert werden? 

• Wie ist die (ideale) Interaktion zwischen Unternehmes- und 

Projektorganisation? 

24

Unternehmen – Wo sind sie tätig? 

25

Unternehmen – Was produzieren sie? 

Warengruppen, ein Überblick 

26

Das Unternehmen & sein Umsystem 

27

Das Unternehmen & seine Prozessketten 

28

Organisatorische Gestaltungsarbeit 

29

Organisationsformen 

Funktionsorientierte Organisation 

30

Organisationsformen - Objektorientierte 

Organisation 

Quelle: Uni-BW München 

Objekt kann sein: Produkt, Kunde, Region, ... 

31


Divisionale Organisation (=Sparten-Orga) I 

32


Divisionale Organisation (=Sparten-Orga) II 

33


Divisionale Organisation III = Spartengestaltung 

34


Vor-/Nachteile divisionale Orga 

35

Stab-/Linienorganisation 

36


Einlinienorganisation - Struktur 

37


Einlinienorganisation – Merkmale 

38


Mehrlinienorganisation - Struktur 

39


Mehrlinienorganisation - Merkmale 

40


Matrixorganisation - Struktur 

41


Matrixorganisation - Merkmale 

42


Überblick Organisationsstrukturen 

43

Alternative Strategien der 

Organisationsstruktur 

Bild: TU Berlin 

44

Projektorganisation - Gedanklicher Leitfaden: 

Von der Unternehmensorganisation.... 

... über die Unternehmensaufbauorgatisation und – 

ablauforganisation ... 

... zur Projektorganisation 

45

Projektorganisation - Lernziele 

• Kennenlernen und Verständnis zu Projektmanagement- 

Grundformen 

• Merkmale, Kriterien und Ausprägung von PM-OSF 

• Verständnis Orga-Strukturplanung 

• Verständnis hinsichtlich unterschiedlicher Kompetenzen im 

Projekt 

• Verständnis der Weisungsbefugnis 

• Mögliche Verteilung der Zuständigkeiten im Projekt 

• Richtige Wahl der PM-OSF 

46

Linien- vs. Projektorganisation 

47

Organisationformen – Primär/Sekundär 

48

Reine Projektorganisation 

49

Einfluß-Projektorganisation (Stab-Linien-PO) 

50

Matrix-PM 

51

Vergleich Projektorganisationsformen 

52

Kompetenzabgrenzung bei der Matrix-PO 

53

Weisungsbefugnisse 

54

AFT Atlas Fahrzeugtechnik GmbH – Die 

„Primärstruktur“ aus dem QM-Handbuch 

Datenverarbeitung 

(DV) 

Herr Böttner 

Mitarbeiter des 

Fachbereichs 

ECU 

Herr Steinbach 


Fachbereichs 

Rev. 2001-08-21 

Einkauf / Personal 

(EK) 

Herr Lindner 


Fachbereichs 

ECT 

Herr Dr. Ludes 


Fachbereichs 

Geschäftsleitung 

Herr Schilly 

Sekretariat 

Frau Steinbrecher 

Zentrale Entwicklung 

(ZEL) 

Herr Krohm 

Sekretariat 

Frau Akilli 

PtD 

Herr Howold 


Fachbereichs 

Werkstatt 

Herr Hidden 


Fachbereichs 

Qualitätsmanagement 

Qualitätsbeauftragter 

Herr Weisner 

Rechnungswesen 

(RW) 

Frau Zappe 


Fachbereichs 

ASC 

Herr Neubauer 


Fachbereichs 

Prüfstand 

Herr Magiera 

55 


Fachbereichs 

Herr Dr. Wodtke 

NVH 


Fachbereichs

PM-Teilprozess: Projektstart 


56

Programm für erfolgreiche Projektsitzungen 

57

Zwecke von Projekt-Sitzungen 

Quelle: FH Darmstadt (incl. Schritte) 

• Informationen an eine Personengruppe weitergeben 

• Informationen 

erbitten/abfragen 

• Offene 

Fragen beantworten 

• Ideenfindung/Brainstorming 

• Als 

Gruppe eine Entscheidung treffen 

• Das 

Team von einer Idee überzeugen 

• Teamgeist 

und Engagement fördern 

• Beispiele: 

◊ Projektstart, Kick-Off-Meeting 

◊ wöchentliche Statussitzungen 

◊ Team-Arbeitssitzungen 

◊ Komitee-/Arbeitskreissitzungen 

58

Schritt 1: Festlegung von Review-/Sitzungstyp 

sowie der Ziele 

• Um welche Art von Review-/Sitzung handelt es sich? 

◊ Kick-Off-Meeting, Statussitzung, Teamsitzung, 

Entwurfsinspektion, Code-Inspektion, Projekt-Review, etc. 

• Welches Ergebnis oder welche Entscheidung soll am Ende 

erreicht sein? 

• Review/Sitzung sollte zielorientiert, wertschöpfend und (vor 

allem) nicht konfliktauslösend sein! 

• Beispiele: 

◊ „Erzielen von Übereinstimmung zu den Schnittstellen- 

Anforderungen.” 

◊ „Überprüfung von Projektfortschritt und Risiken, um zu 

entscheiden, ob die Anforderungen reduziert werden 

müssen.“ 

59

Schritt 2: Eingangs- und Ausgangskriterien 

festlegen 

Eingangskriterien: 

• Welche Voraussetzungen müssen vor Review-/Sitzungsbeginn 

für einen erfolgreichen Verlauf erfüllt sein? - Leiten sich aus den 

Review-/Sitzungszielen ab. 

◊ Beispiel: Zu prüfende Arbeitsprodukte müssen fertig sein; 

Arbeitsdokumentation wurde von den Teilnehmern gelesen 

und auf darin enthaltene Fehler geprüft. 

Ausgangskriterien: 

• Was muss erreicht sein, damit Review oder Sitzung als 

ordnungsgemäß abgeschlossen betrachtet werden kann? 

◊ Beispiel: Identifikation und Protokollierung aller 

Ungereimtheiten in der Dokumentation gemäß Checkliste 

• Eingangs- und Ausgangskriterien müssen VOR Beginn von 

Review/Sitzung festgelegt sein! 

60

Schritt 3: Gut organisiert und vorbereitet 

• Auswahl der richtigen Teilnehmer 

• Auf gute Mischung achten. 

• Nur diejenigen einladen, die am Ergebnis interessiert sind. 

• Auf Kontinuität im Teilnehmerkreis achten 

• Funktionen zuweisen: Moderator, Autor, Gutachter, Zeitnehmer, 

Protokollführer 

• Tagesordnung festlegen (im voraus!!!) 

• Sich daran halten (!) 

• Verteilen der Tagesordnung rechzeitig vor der Sitzung 

• Gute Vorbereitung, -> darauf bestehen 

61

Schritt 4: Kick-Off für Reviews durchführen *) 

• Mit den Teilnehmern vorher Ziele des Meetings besprechen und 

überprüfen 

• Termin: mindestens 1 - 2 Wochen vor dem Review 

• Muss nicht unbedingt face-to-face im gleichen Raum sein, 

Video- oder Telefonkonferenz sind auch geeignet 

• Beispiel: Zielbesprechung vor einer formalen Inspektion 

*) Schritt 4 nur bei Reviews!! 

62

Schritt 5: Vorbesprechung mit dem 

Auftraggeber *) 

• Sich vorab mit dem Auftraggeber austauschen: Zweck und Ziele 

des Reviews, kontroverse Sichtweisen und bekannte Mängel 

• Zweck: mit den Teilnehmern von Auftraggeberseite vor dem 

Review einen grundsätzlichen Konsens über Ziele und 

Vorgehensweise des Reviews herzustellen 

• Besonders wichtig, wenn von Auftraggeberseite viele 

Teilnehmer aus unterschiedlichen Bereichen und Abteilungen 

kommen 

*) Schritt 5 bei Management Reviews mit Auftraggeber-Beteiligung 

63

Schritt 6: Für guten Start sorgen 

• Teilnehmer solle sich wohl fühlen: Garantieren Sie geeignete 

Einrichtungen (Platzangebot, Licht, Klimatisierung, ...) 

• Raum für Sitzungszweck vorbereiten, z. B. U-förmige oder 

ovale Platzanordnung 

• Essen, Getränke und Pausen organisieren 

• Teilnehmer aktiv begrüßen, gegenseitige Vorstellung 

• Zweck, Ziele, Agenda und Rollen der Teilnehmer 

zusammenfassen 

• Überprüfung, ob Eingangskriterien erfüllt sind 

64

Schritt 7: Spielregeln vereinbaren 

• Von jedem Teilnehmer Statements einholen; Reihum- 

Fragerunden einsetzen oder direkte Ansprache passiver 

Teilnehmer 

• Interesse zeigen für konstruktive Beiträge 

• Zu einer offenen Kommunikation ermutigen 

• Erfahrungen und Talente von jedem abfragen „Deswegen sind 

die Teilnehmer ja gekommen ….“ 

• Anzahl und Länge von Präsentationen begrenzen 

• Für das gesamte Meeting Zeitbegrenzungen vereinbaren 

• Zeitnehmer bestimmen 

• Arbeitsgruppengröße kontrollieren - Gruppen von mehr als 10 

Personen in Teilgruppen einteilen 

• Anschauungsmaterial und Prototypen einsetzen, um das 

Verständnis und die Kommunikation der Teilnehmer zu fördern 

• Regeln für Meinungsverschiedenheiten und Konflikte 

vereinbaren 

65

Schritt 7 / 2: Moderation ! 

66

Schritt 8: Protokoll führen und Action Items 

(„ToDos“) festhalten 

• Typische Protokollinhalte: Review-Name, Ziele und Datum, 

Teilnehmer, Ergebnisse und Entscheidungen, 

Erledigungsvermerke („Action Items“) 

• Bestimmen Sie Action Items für offene Punkte: 

Erledigungstermin, Priorität und verantwortliche Person 

festlegen 

• Action Items und Entscheidungen vor Review-/Sitzungsende 

noch einmal überprüfen 

• Action Items, die noch während der Sitzung geklärt werden 

können am Sitzungsende abhaken, um sich auf die detailliertere 

Analyse schwerwiegender Fragen konzentrieren zu können 

• Bestätigung einholen, dass die Ergebniskriterien erfüllt wurden 

• Protokoll innerhalb einer angemessenen Frist erstellen und 

verteilen; max. 2–3 Tage zur Gegenprüfung und 

Kommentierung zulassen 

67

Schritt 9: Feedback holen für künftige 

Verbesserungen 

Reviews und Sitzungen finden immer wieder statt! 

Alle Teilnehmer möchten, dass Reviews und 

Sitzungen produktiv sind! 

Beispiele für Feedback-Fragen: 

◊ War die Tagesordnung vorher verfügbar? 

◊ Wie können wir eine bessere Kommunikation fördern? 

◊ Haben wir die richtigen Teilnehmer? 

◊ Waren Räume und Einrichtung angemessen? 

◊ Wie können unsere Reviews und Sitzungen verbessert 

werden? 

68

Schritt 10: Verfolgen Sie die Action Items 

• Richten Sie ein System zur Nachverfolgung von Action Items ein 

• Typische Inhalte: 

◊ Action Item Nummer, Beschreibung, Priorität, 

Zuweisungsdatum, Verantwortliche Person(en), Status, 

Erledigungstermin/-datum 

• Verfolgen Sie als Metrik die Anzahl der offenen Action Items 

• Messgröße für den Zustand eines Projekts 

• Wenn notwendig, terminieren Sie eine Statussitzung zur 

Nachverfolgung der Action Items 

• Bereiten Sie das nächste Review/Sitzung vor 

69

Zusammenfassung: Die Schritte für 

erfolgreiche Reviews und Sitzungen 

1. Review-/Sitzungstyp und dessen Ziele festlegen 

2. Eingangs- und Ausgangskriterien vorher festlegen 

3. Gute Vorbereitung und Organisation 

4. Kick-Off für das Review durchführen * 

5. Vorbesprechung mit dem Auftraggeber vereinbaren* 

6. Für guten Start sorgen 

7. Spielregeln vereinbaren 

8. Protokoll führen Action Items („ToDos“) festlegen 

9. Feedback für künftige Verbesserungen einholen 

10. Action Items verfolgen 

70

PM-Teilprozess: Projektziele 


71

Projektziele und Risikoanalyse 

Inhalt, Kernfrage (-> naheliegend!): 

Wie legt man herausfordernde, anfordernde, zugleich 

aber auch realisierbare Ziele fest? 

Zuvor jedoch (-> „nicht so naheliegend“): 

Identifikation und Einbeziehung der 

Interessengruppen (Stakeholders) 

72

Bedeutung von Projektzielen 

Bedeutung einer frühzeitigen Zieldefinition 

Bei vielen Projekten sind die Ziele zu Beginn nur vage festgelegt 

und werden erst nach und nach präzisiert. 

Warum sollten Ziele in der Startphase präzisiert und genau 

definiert werden? 

• Damit der Projektleiter und das Projektteam einen gesicherten 

Aktionsrahmen besitzen. 

• Damit der Auftraggeber weiß, was er bekommen wird. 

• Um für die gesamte Projektplanung eine Basis zu legen. 

• Um unkontrollierte Zieländerungen zu vermeiden (wichtigste 

Ursache späterer Termin- und Kostenüberschreitungen). 

• Damit Mißverständnisse beim Projektabschluß vermieden 

werden (Fixierung des Projektendes). 

73

Zunehmend detailliertere Ziele im 

Projektverlauf 

74

Stakeholderanalyse - Zielfindung als 

Interessenausgleich 

Erste Feststellungen: 

• Es existieren unterschiedliche Interessentengruppen 

(„Stakeholder“) im Projekt 

• Es „droht“ die Bildung von Gewinner- und Verlierergruppen im 

Zielbildungsprozess 

• Abhilfe = „Theorie W“: Schaffung einer „Win-Win“-Situation 

75

Formale Struktur eines Projekts 

76

Informale Struktur: Stakeholder (1) 

Feststellungen: 

• Stakeholders sind Personen, die in irgendeiner Form am Projekt 

beteiligt sind bzw. Interesse am Ergebnis des Projektes haben. 

• Sie nicht unbedingt über die einzelnen Abläufe im Projekt 

informiert bzw. an diesen beteiligt. 

• Weil sie informiert sein sollten, sollten sie so früh wie möglich 

identifiziert, kontaktiert und einbezogen werden. 

• Ihre Beweggründe und Ziele müssen nicht übereinstimmen, 

sondern können im krassen Gegensatz zueinander stehen. 

77

Informale Struktur: Stakeholder (2) 

Beispiele für Stakeholder: 

◊ Mitglieder des Projektteams. 

◊ Kunden/Auftraggeber. 

◊ Gruppen außerhalb des Projektes. 

Typische Projekte, wo Konflikte vorprogrammiert 

sind: 

◊ Arbeitsplatz-Abbau-Projekte. 

◊ Projekte, wo der rangmäßige und/oder soziale Status 

geändert werden könnte. 

78

Interessentengruppen: „Stakeholder“ im 

Projekt 

79

Wichtigkeit der Einbeziehung von 

Stakeholders 

Quelle: “USA discovers key to successful projects”, Computer Weekly, 25 June 1998 

“Projects which have executive management support 

and user involvement - our two top criteria for IT 

project success - have a 50% greater chance of 

success” 

Karen Boucher, vice-president of Standish Group 

Standish have conducted annual surveys of IT project failures since 1994 

80

Maßnahme: „Networking“ 


81

Gewinner und Verlierer im 

Zielbildungsprozess 

• Die Festlegung von Projektzielen ist ein Verhandlungsprozeß 

zwischen den beteiligten Interessengruppen, bei dem es 

Gewinner und Verlierer geben kann (vgl. Beispiel unten). 

• Verlierer blockieren den Projektfortschritt. Daher gewinnt in 

Projekten mit Gewinnern und Verlierern am Ende niemand. 

• Konsequenz: So viele Beteiligte wie möglich zu Gewinnern 

machen („Win-Win“-Situation). 

82

„Theorie W“: Schaffung einer „Win-Win“- 

Situation 

• Alle vom Projekt betroffenen Gruppen vollständig identifizieren 

• Sich in die Lage dieser Gruppen versetzen; deren Interessen 

verstehen 

• Unrealistische Erwartungen abbauen: 

◊ Den Gruppen die Standpunkte der anderen Beteiligten 

verdeutlichen 

◊ Erwartungen mit Erfahrungen aus früheren Projekten 

vergleichen 

◊ Kosten und Zeitbedarf von Vorschlägen und Wünschen 

benennen 

◊ Projektablauf und notwendige Arbeitsschritte verdeutlichen 

◊ 

83

„Theorie W“: Schaffung einer „Win-Win“- 

Situation – Forts. 

◊ 

• Nach Alternativen zum gegenseitigen Nutzen suchen 

• Den Interessenten Einflußmöglichkeiten einräumen, z. B. 

◊ Benutzer verantwortlich für Review der Benutzerschnittstelle 

◊ Entwickler verantwortlich für Schätzung des Zeitaufwands 

◊ Systembetreuer verantwortlich für Quellcode-Review 

◊ Auftraggeber verantwortlich für Verfolgung des 

Projektfortschritts 

◊ Festlegung der Mitwirkungsarten durch z. B. 

Funktionendiagramm 

84

Stakeholderanalyse: Bewertung der 

Erwartungen der Interessentengruppen 


85

Projektziele festlegen 

Übersicht: 

• Arten von Zielen in Projekten 

• Inhalte von Projektauftrag/Projektvision, Lastenheft und 

Pflichtenheft 

• Vorgehensweise und Hilfsmittel zur Zieldefinition 

◊ Mind-Map 

◊ Zielhierarchie 

◊ Zielprioritätensetzung 

◊ Zielabgrenzung 

• Anforderungen an die Zieldefinition 

86

Arten von Zielen in Projekten 

Anm.: Jedes Ziel läßt sich innerhalb jeder der drei Attributgruppen eindeutig zuordnen, später zudem noch einer Zielklasse! 

• Ergebnisziele (Produkt- bzw. Systemziele): „Betriebssystem mit 

Funktionalität von Windows 98 in 4K-ROM“ …oder… 

• Vorgehensziele (Projektziele im engeren Sinne): 

„Markteinführung innerhalb von 12 Monaten, Kosten < 1Mio. 

DM“ 

• Qualitative Ziele: „Schnellere Arbeitsabläufe und Verbesserung 

des Service“ …oder… 

• Quantitative Ziele: „90 % der Reparaturen innerhalb eines 

Tages abgeschlossen“ 

• Mussziele: „Ladezeit des Programms auf Pentium 500 < 10 

Sekunden“ …oder 

• Soll-, Kann- und Wunschziele: „Ladezeit des Programms auf 

Pentium 500 < 3 Sekunden“ …oder… 

• „Nicht-Ziele“: Ausdrückliche Ausschlüsse 

87

Typische Inhalte von Projektauftrag / 

Projektvision (1) 

1. Geschäftlicher Hintergrund 

• Ausgangssituation, Markt-/Geschäftsmöglichkeiten 

• Finanzielle/Strategische Geschäftsziele 

• Kunden-/Marktanforderungen, Nutzen für die Kunden 

• Geschäftliche Risiken 

2. Produktvision 

• Kurze Produktbeschreibung („Vision Statement“, Kernziele in 2 

bis 5 Sätzen) 

• Auflistung der wichtigsten Produktmerkmale 

• Realisierung spezieller Sponsoren-/Stakeholder-Erwartungen 

88

Typische Inhalte von Projektauftrag / 

Projektvision (2) 

3. Projektumfang 

• Funktionsumfang, Qualitäts- und Leistungsmerkmale des ersten 

Release 

• Umfang und Zeitrahmen eventueller weiterer Releases 

• Projektabgrenzung: Nicht geplante Produktmerkmale (z. B. 

Kontextdiagramm) 

4. Randbedingungen 

• Hauptmerkmale der einzelnen Kundengruppen (Kundenprofile, 

Szenarien) 

• Projektprioritäten (Top-Prioritäten, Feste Größen, 

Dispositionsspielräume) 

5. Produkt-Erfolgsfaktoren 

89

Beispiel: Gliederung von Lastenheften für 

Softwareprojekte („Was?“) 

• Zielbestimmung: Durch den Einsatz der Software zu 

erreichende Ziele 

• Produkteinsatz: Anwendungsbereiche und Zielgruppen der 

Software 

• Produktfunktionen: Hauptfunktionen aus Auftraggebersicht 

• Produktdaten: Hauptdaten, die permanent gespeichert werden 

müssen 

• Produktleistungen: Anforderungen an Geschwindigkeit, 

Datenumfang, Genauigkeit 

• Qualitätsanforderungen: Wichtigste Qualitätsanforderungen, 

wie z. B. Zuverlässigkeit, Benutzbarkeit, 

Änderungsfreundlichkeit u. ä. 

• Ergänzungen (Ergänzungen oder spezielle Anforderungen) 

90

Beispiel: Gliederung von Pflichtenheften für 

Softwareprojekte („Wie?“) 

• Zielbestimmung: Muß-, Wunsch- und Abgrenzungskriterien 

• Produkteinsatz: Anwendungsbereiche, Zielgruppen und 

Betriebsbedingungen 

• Produktumgebung: Software, Hardware, Orgware, Produkt- 

Schnittstellen 

• Produktfunktionen: Realisierungsneutrale Beschreibung aller 

Produktfunktionen aus Benutzersicht; Wunschkriterien 

gekennzeichnet 

• Produktdaten: Aus Benutzersicht zu speichernde Daten 

• Produktleistungen: Anforderungen an Geschwindigkeit und 

Kapazitätsbedarf des Softwareprodukts 

• Benutzerschnittstelle: Bildschirmlayout, Drucklayout, 

Tastaturbelegung, Dialogstruktur 

• Qualitätszielbestimmung: Detaillierte Qualitätsmerkmale 

91

Beispiel: Gliederung von Pflichtenheften für 

Softwareprojekte („Wie?“) – Teil 2 

• Globale Testfälle: Funktionsübergreifende Testfälle für System- 

und Abnahmetests 

• Entwicklungsumgebung: Software, Hardware, Orgware, 

Entwicklungs-Schnittstellen 

• Versionsinformation: Version, Datum und Änderungsstand 

des Pflichtenhefts 

• Ergänzungen/Anhänge: Installationsbedingungen, Normen, 

Patente, Lizenzen, Glossar (Fachbegriffe) 

=> Das Pflichtenheft ersetzt in der Regel das 

Lastenheft 

92

Vorgehensweise zur Zieldefinition 

1. Bildung eines Zieldefinitionsteams: 

◊ Beteiligung wichtiger Interessengruppen 

2. Sammlung von möglichen Einzelzielen: 

◊ Prüffragen, Checklisten, Befragung, Brainstorming, Mind- 

Maps 

3. Gliederung der Ziele 

◊ Zielhierarchie, systematische Nummerierung 

4. Präzisierung der Einzelziele 

◊ Prioritätensetzung (Muss – Soll – Kann), Streichung weniger 

wichtiger Anforderungen, lösungsneutrale Formulierung 

5. Überprüfung der Zieldefinition 

◊ Erfüllung der Anforderungen an die Zieldefinition 

6. Verabschiedung der Zieldefinition 

◊ Review, Genehmigung, als „Baseline“ unter 

Änderungskontrolle stellen 

93

Anforderungen an Projektziele 

Abschluss-Check: 

Richtig formulierte Projektziele sollen 

◊ herausfordernd und motivierend, 

◊ erreichbar, 

◊ vollständig, 

◊ widerspruchsfrei, 

◊ überprüfbar, 

◊ lösungsneutral, 

◊ dokumentiert sowie 

◊ zwischen Auftraggeber und Projektleiter abgestimmt und von 

beiden akzeptiert sein. 

97

Stabile Anforderungen; Beispiel: SW-Projekte 

• Die Änderung von Anforderungen ist das größte Risiko bei 

Softwareprojekten 

• Umfassende, 100 % stabile Anforderungen sind normalerweise 

nicht möglich, aber …. 

• Die meisten Änderungsanträge entstehen aus Anforderungen, 

die zu Beginn unvollkommen definiert wurden, nicht aus 

„Marktveränderungen“ oder ähnlichen Gründen 

• Wirksame Stabilisierungsmethode bei Software z.B. „Clickbare 

Prototypen“ der Benutzeroberfläche 

98

Techniken zur Formulierung stabiler Anforderungen 

• Anforderungs-Workshop 

• Prototyp der Benutzeroberfläche 

• Befragung von Nutzern 

• Use Cases 

• Benutzerhandbücher als Spezifikation 

• Usability Studien (z. B. Videos) 

• Inkrementelle Implementierung 

• Anforderungs-Reviews 

• QFD-Methode 

99

Risikoanalyse/Risikomanagement 

100

Risikomanagement im Projekt 

Inhaltsübersicht - Unterpunkte: 

1. Begriffe: Risiko und Risikomanagement 

2. Schritte des Risikomanagements 

3. Wie finde ich Projektrisiken heraus? : Checkliste zur 

Identifikation von Personalrisiken; SEI‘s Taxonomy of Software 

Project Risks 

4. Risikoanalyse: Wahrscheinlichkeit und Risikofolgen: Risiko- 

Prioritätensetzung; Risiko-Portfolios und Risiko-Punktebewertung; 

Top-10-Risikoliste 

5. Risikomanagement Strategien und Risikoplanung 

6. Zusammenfassung: Ablauf des Risikomanagements 

101

Potentielle Probleme im Projektverlauf 

In Projekten können viele Probleme auftreten, z. B.: 

• Nicht oder unpräzise spezifizierte Projektziele 

• Mangelhafte Einbeziehung von Auftraggebern und Anwendern 

• Unzureichende Qualifikation von Projektleiter und Mitarbeitern 

• Unzureichende Unterstützung durch das Management 

• Ungenaue Aufwandsschätzungen und unrealistische Zeitpläne 

• Laufende technische Änderungen 

• Budgetkürzungen während der Projektlaufzeit 

• Mangelnde Qualitätsfähigkeit der externen Zulieferer 

• Erarbeitung unverkäuflicher oder zu teurer Lösungen 

• … 

Ein guter Projektleiter hofft das Beste, aber bereitet 

sich auf das Schlechteste vor. 

102

Begriffe: Risiko und Risikomanagement 

• Risiko = Möglichkeit, daß eine Aktivität einen materiellen 

Verlust oder Schaden (z. B. Unfall, Terminverzug, 

Kostenüberschreitung, verärgerte Kunden) zur Folge hat. = 

Potentielles Problem 

• Problem = Risiko, das de facto eingetreten ist 

• Risiko-M.:= Erkennen, analysieren und beseitigen von 

Managementrisiken, bevor sie zu Problemen werden. 

Wer sich nicht um die Projektrisiken kümmert, um 

den kümmern sich die Risiken.“ 

103

Schritte des Risikomanagements 

104

Wie finde ich Projektrisiken heraus? 

Ziel: Alle denkbaren Gefahren für den Projekterfolg 

identifizieren durch: 

• Erfahrungen - Checklisten und Expertenbefragungen 

• Kreativität - Kreativitätstechniken, z.B. Brainstorming 

• Einsetzung eines Risikobeauftragten 

Sinnvolle Basis zur Risiko-Identifikation sind 

Lastenheft und Projektstrukturplan: 

• Alle Lastenheftanforderungen und/oder Arbeitspakete auf 

mögliche Risiken checken 

• Arbeitspakete mit großen Unsicherheiten bei Aufwand, Kosten 

und Zeitdauer durch Bereichsschätzungen identifizieren 

(„PERT“-Analyse ) 

105

Beispiel: Checkliste zur Identifikation von 

Personalrisiken 

Quelle: Schelle (1996, S. 63) nach FH Darmstadt 

• Gibt es kritische Aufgaben für die noch niemand vorgesehen 

ist? 

• Gibt es Zwänge bestimmte Mitarbeiter im Projekt einzusetzen? 

• Gibt es Zwänge, in frühen Projektphasen zu viele Mitarbeiter zu 

beschäftigen? 

• Passen die Mitglieder des Projektteams zusammen? 

• Haben die Mitglieder des Projektteams realistische Erwartungen 

über ihre Aufgaben im Projekt? 

• Sind die Mitglieder des Projektteams für die ihnen übertragenen 

Aufgaben geeignet? 

• Stehen die wichtigsten Mitglieder des Projektteams 

voraussichtlich für die gesamte Projektdauer zur Verfügung? 

• Sind die wichtigsten Mitglieder des Projektteams vollständig für 

das Projekt abgestellt? 

106

Beispiel: Taxonomie für Software-Projekte 

(nach Software Engineering Institute) 

107

Risiko: Eintrittwahrscheinlichkeit und 

mögliche Auswirkung („Schadenhöhe“) 

Risk Probability 

Risk probability is the likelihood that an event will actually occur. 

◊ Risk probability must be greater than zero, or the risk does 

not pose a threat to the project. 

◊ Likewise, the probability must be less than 100 percent or the 

risk is a certainty – in other words, it is a known problem. 

Risk Impact 

Risk impact measures the severity of adverse affects, or the 

magnitude of a loss, if the risk comes to pass. 

◊ Cost increase in euros/dollars 

◊ Schedule increase in days/weeks/months 

◊ Reduction in Functionality/Quality in Function Points 

Recommended: Combined scale from 0 to 5 points 

108

Risiko-Prioritätensetzung 

109

Beispiel eines Risko-Portfolios 

110

Beispiel: Risiko-Punktebewertungstabelle 

111

Beispiel: Top-10-Risikoliste („Hitparade“) 

112

Zusammenfassung: 

Ablauf des Risikomanagements (1) 

1. Risiko-Identifikation 

• Lasten-/Pflichtenheft, Projektstrukturplan, Checklisten 

• Einsetzung eines Risikobeauftragten 

2. Risiko-Analyse und Prioritätensetzung 

• Eintrittswahrscheinlichkeit, Termin-/Kostenauswirkungen 

• Risiko-Bewertungstabelle 

3. Risiko-Maßnahmenplanung 

• Top-10-Risiko-Liste, ggf. zusätzliches Risikoplanungsformular 

• Berücksichtigung von Maßnahmen und Reserven in 

Projektplanung 

113

Zusammenfassung: 

Ablauf des Risikomanagements (2) 

4. Risiko-Bekämpfung 

• Durchführung der festgelegten Maßnahmen 

5. Risiko-Überwachung 

• Regelmäßige Verfolgung/Aktualisierung Top-10-Risikoliste 

• Durchsprache auf Projektstatussitzungen 

• Action-Item-Liste zusätzlich erforderlicher Maßnahmen 

114

PM-Teilprozess: Projektplanung 

115

Projektstrukturplan - Begriffsbestimmung 

116

Projektstrukturpläne – Zweck 

Der Projektstrukturplan erfüllt verschiedene 

Funktionen: 

• Erhöhung der Projekttransparenz 

• Grundlage für die Verteilung von Aufgaben und 

Verantwortlichkeiten im Projekt 

• Ausgangsbasis für die Ablauf- und Terminplanung 

• Voraussetzung für Kostenplanung und Kostenkontrolle 

• Grundlage für Risikoanalysen 

• Mittel zur Strukturierung von Projektsteuerungssitzungen 

• Gliederungsschema für Projektberichte und deren Ablage 

117

Projektstrukturplan: Weitere Vorzüge 

Der Projektstrukturplan … 

• … hilft durch die Unterteilung in kleine, leicht überschaubare 

Aktivitäten, die Komplexität des Projekts zu reduzieren. 

• … kann durch die hierarchische Darstellung einfach auf 

Vollständigkeit überprüft werden - auch von projektfremden 

Fachleuten. 

• … ist einfach zu verstehen und eignet sich gut für 

Präsentationen. 

• … ist ein hervorragendes Kommunikationsmittel, mit dem jeder 

Beteiligte sofort seinen Beitrag zum Gesamtprojekt erkennt. 

• --- fördert den Teamentwicklungsprozess, da er im Rahmen 

eines neuen Projekts eines der ersten gemeinsam erarbeiteten 

Ergebnisse ist. 

118

Projektstrukturplan blättern 

Nach DIN 69901 ist der Projektstrukturplan lediglich die "Darstellung der Projektstruktur". Die DIN 69901 kennt dabei die Darstellung nach Aufbau, 

Ablauf, Grundbedingungen und sonstigen Gesichtspunkten. Sowohl Netzplan als auch Balkenplan zählen damit zu den Projektstrukturplänen. 

Die Praxis der Projektstrukturplanung präzisiert den PSP gemeinhin als "die vollständige hierarchische Anordnung aller Element eines Projektes". Als 

Darstellungsformen wird hierfür meist das Organigramm gewählt, alternativ die Listendarstellung mit Nummerierung und Einrückungen. Logisch dem 

Organigramm gleichwertig, aber mit anderer visueller Wirkung findet sich auch zunehmend die Mind Map als Format für den Projektstrukturplan. 

Unabhängig von seiner Darstellung hat der Projektstrukturplan folgende Aufgaben: 

Vorgabe einer Struktur für alle Projektmanagementaufgaben 

Vollständige Darstellung des Projektgegenstands 

Definition des Projektziels bzw. Überprüfung der Zieldefinition 

Bestimmung aller zum Projekt gehörenden Arbeitspakete (Kostenträger) 

Ordnen und Strukturieren der Arbeitspakete in einer geeigneten Systematik (Kostenträgerstruktur) 

Schaffung von Transparenz gegenüber allen Projektbeteiligten (Stakeholdern) 

Aufstellen der Gliederung für alle Projektdokumente (Pflichtenheft, Berichte usw.) 

Die Erstellung eines für alle verbindlichen Projektstrukturplans (Projektstrukturierung, Projektstrukturplanung, Projektgliederung) zu Anfang des 

Projekts dient somit der Effizienzsteigerung bei Planung, Durchführung und Abschluss des Projekts, da alle Elemente (Ressourcen, Vorgänge, Risiken, 

Berichte, Kosten, Ergebnisse usw.) in die gleiche Systematik eingeordnet werden. 

Zu diesem Zweck erhalten die Elemente des Projektstrukturplans eindeutige Bezeichner, den sogenannten Projektstrukturplan-Code (PSP-Code). 

Der PMBOK definiert die Work Breakdown Structure (WBS) sehr ähnlich dem Projektstrukturplan, legt jedoch größere Betonung auf die Strukturierung 

nach Arbeitsabläufen und Teilergebnissen. So ist nach PMBOK für jedes Arbeitspaket auch ein Lieferobjekt (Deliverable) zu definieren. 

Durch die zunehmende Verflechtung von Projektarbeit mit Linienarbeit und vor allem durch den Anspruch, Projektabläufe und betriebliche Abläufe eng 

zu koordinieren und aufeinander abzubilden, steigen auch die Anforderungen an den Projektstrukturplan. Mit den Möglichkeiten des rechnergestützten 

Projektmanagements und der ERP-Systeme werden künftig wohl mehrfache und miteinander verschränkte Projektstrukturpläne entstehen, die z.B. die 

Kostenträgerrechnung des Projekts (Arbeitspaketstruktur) auf die Kostenrechnung des Betriebs (Kostenstellen, Kostenarten) abbilden. 

Der Projektstrukturplan (bzw. die Projektstrukturpläne) muss im Projekthandbuch dokumentiert sein und ist in der Regel Teil der Gliederung des 

Projekthandbuchs. 

Abkürzung PSP 

Englischer Begriff Work Breakdown Structure 

Abbreviation WBS 

Norm DIN 69901, PMBOK, ICB, PMF 

119

Unterschiedliche Ebenen der Projektplanung 

und ihre Granularität 

120

Rollierende Gesamt- und Feinplanung bei 

größeren Projekten 

121

Typische Inhalte eines System- 

Entwicklungsplans/Projektgesamtplans (1) 

1. Einleitung 

◊ Überblick über die Inhalte des Phasenarbeitsplans 

2. Projektüberblick 

◊ Kurzer Überblick über Zweck und Ziele des Projekts 

3. Projektorganisation 

◊ Organisationsstruktur (Organigramm) des Projekts sowie 

Beschreibung der Rollen/Verantwortlichkeiten der 

Teammitglieder 

◊ 

◊ 

122

Typische Inhalte eines System- 

Entwicklungsplans/Projektgesamtplans (2) 

◊ 

4. Managementpläne 

◊ Projektphasen-/Meilensteinplan mit Terminen und Kosten 

◊ Zwischenprodukte (Artefakte) und vorgesehene 

Qualitätskontrollen 

◊ Personalplanung (Personalbedarf, Stellenbesetzung, 

Trainingsmaßnahmen) 

◊ Vorgesehener Projektcontrollingprozess und 

Projektabschluss 

5. Ggf. Anzuwendende Technische Standards, 

Methoden und Tools 

6. Ggf. Zusätzliche Pläne (z. B. Qualitätsplan, 

Zahlungsplan) 

123

Beispiel für einen Projektterminplan 

124

(Vorgriff:) Beispiel Projekt-Soll-Ist-Vergleich 

125

Typische Inhalte eines Phasen-Detailplans 

1. Einleitung 

◊ Überblick über die Inhalte des Phasenarbeitsplans 

2. Arbeitsplan 

◊ Detaillierte Diagramme, die die Einzelaufgaben, deren 

Verantwortliche, Termine und Arbeitsaufwand zeigen 

3. Ressourcenbedarf 

◊ Ressourcenbedarf der Phase – Personal, Finanzmittel etc. 

4. Funktionsumfang 

◊ Liste der konkreten, detaillierten Funktionen, Merkmale, 

Szenarien etc., die in der Phase realisiert werden sollen 

5. Qualitätsmerkmale 

◊ Phasenziele hinsichtlich, Zuverlässigkeit, Leistungsfähigkeit, 

Benutzerfreundlichkeit, Design etc. 

126

Beispiel Phasenarbeits- und Terminplanung 

(mit Ressourchenzuordnungen / 

Verantwortlichkeiten) 

127

Projektstrategie - = Projektphasen und 

Meilensteine 

Inhaltsübersicht - Unterpunkte: 

1. Projektstrategie = Festlegung von Projektphasen und 

Hauptmeilensteinen 

2. Wozu dienen Meilensteine und wie werden sie definiert? 

3. Empfohlenes Planungsdokument: Meilensteinplan 

4. Beispiel für Phasen, Meilensteine und Meilenstein-Reviews 

in IT-Projekten 

128

Festlegung von Projektphasen und 

Hauptmeilensteinen 

• Projekte werden nur selten in einem Zug bearbeitet. Durch die 

Aufteilung in mehrere Phasen wird ein Projekt überschaubarer. 

• Am Ende einer Phase wollen Management und/oder Kunde 

die Ergebnisse sehen und über die nächste Phase entscheiden. 

• In der Regel geht dem eine sorgfältige Überprüfung (Review) 

der Phasenergebnisse voraus. Die Phasenergebnisse werden 

dann zur Grundlage („Baseline“) der Arbeiten in der 

Folgephase. 

• Das Ende (teilweise auch der Beginn) einer Phase sind damit 

Haupt-Meilensteine zur Kontrolle und Steuerung des 

Projektverlaufs. 

• Um ein unsystematisches „Gleich-drauf-los-Arbeiten“ zu 

vermeiden, sollten Details der Projektbearbeitung erst geplant 

129

werden, wenn Phasenfolge und Meilensteine (= 

Projektstrategie) festgelegt sind. 

• Für IT-Projekte existieren eine Reihe von 

„Vorgehensmodellen“, an denen die Projektstrategie 

ausgerichtet werden kann. 

130

Wozu Meilensteine? 

• Meilensteine sind Punkte, an denen eine Entscheidung über den 

weiteren Projektfortgang gefällt werden kann. 

• Meilensteine ermöglichen eine objektive Ermittlung und 

Darstellung des Projektstatus. 

• Ein Meilenstein ist immer ein Ereignis, von dem sich eindeutig 

feststellen lässt, ob es eingetreten ist oder nicht. 

• Bei ihrem Erreichen werden Reviews durchgeführt, in denen 

geprüft wird, ob die Ergebnisse ordnungsgemäß vorhanden 

sind. 

• Zusammengefasste Meilensteinpläne ermöglichen dem 

Management einen schnellen Überblick über die Eckpunkte der 

Projektplanung. 

• Meilensteine motivieren, immer wieder "Zwischenspurts" 

einzulegen und sich nicht nur am häufig weit entfernten 

Projektziel auszurichten. 

131

Was sind Meilensteine? 

Unter einem Meilenstein versteht man das Erreichen eines 

definierten Sachergebnisses oder den Eintritt einer definierten 

Arbeitsvoraussetzung. 

Meilensteine… 

◊ … repräsentieren einen wesentlichen Fortschritt im 

Projektverlauf. 

◊ … können sowohl Anfang oder Ende ganzer Projektphasen 

als auch wichtiger Arbeitsabschnitte innerhalb der Phasen 

betreffen. 

◊ … sind Ereignispunkte. Als solche wird ihnen im Projektplan 

kein Arbeitsaufwand und keine Bearbeitungsdauer 

zugewiesen. 

132

Wie werden Meilensteine definiert? 

Zur Definition eines Meilensteins gehören: 

◊ Meilensteinname 

◊ Ggf. Meilensteinverantwortlicher (falls nicht Projektleiter) 

◊ Meilensteintermin 

◊ Meilenstein-Ergebnisse (z.B. Dokumente, Prototypen, 

Entscheidungen) 

133

Planungsdokument: Meilensteinplan (Beispiel) 

134

Beispiel für Phasen, Meilensteine und 

Meilenstein-Reviews in IT-Projekten 

135

Methodik der Phasen-Detailplanung 

1. Grundsätze und Hilfsmittel zur Phasenstrukturierung 

◊ Mind Map zur groben Projektstrukturierung 

2. Top-Down-Ablauf der Projektstrukturplanung 

◊ Typische Einzelergebnisse in Systementwicklungsprojekten 

◊ Funktionendiagramme zur Arbeitsverteilung im Team 

◊ Arbeitspakete und Arbeitspaket-Beschreibungen 

◊ Aktivitätenplanung: Sechs Prozessschritte zum Ergebnis 

◊ PSP-Überprüfungsfragen und Vollständigkeits-Check 

136

Grundsätze bei der Phasenstrukturierung 

• cWichtigstes Ziel: Vollständigkeit aller Aktivitäten im PSP 

• Einzelne Ebenen immer nur nach einem Prinzip detaillieren, um 

deren Vollständigkeit leichter zu überblicken. 

• Alle Aktivitäten klar voneinander abgrenzen, um 

Überschneidungen zu vermeiden. 

• Risiken und Unklarheiten im PSP markieren und während des 

Projektverlaufs besonders darauf achten. 

• PSP soweit detaillieren, bis allen Aktivitäten jeweils genau ein 

Verantwortlicher zugeordnet werden kann. 

• Noch nicht die Reihenfolge der Aktivitäten darstellen. PSP dient 

ausschließlich der inhaltlichen Untergliederung. 

137

Hilfsmittel zur Phasenstrukturierung im PSP 

1. Schriftliche Unterlagen: 

• Lasten- bzw. Pflichtenheft 

• Standardstrukturpläne 

• Strukturpläne früherer Projekte 

• Standardvorgehensmodelle 

• Produktstruktur (Komponenten/ 

• Module des Systems) 

• Personal-/Organisationsplan 

2. Gruppenarbeitstechniken, 

insbesondere 

• Brainstorming / Brainwriting 

• Mind Mapping 

• Funktionendiagramm 

Der Projektstrukturplan wird vom Projektteam gemeinsam 

erarbeitet! 

138

Mind Map zur groben Projektstrukturierung 

• Technik zum Festhalten von Gedanken und Arbeitsnotizen jeder 

Art 

• Verbindet sprachliches und bildhaftes Denken; 

• regt zu Assoziationen an 

• Ausgangspunkt: Blattmittelpunkt 

• Baumförmige Ausbreitung 

• Schlüsselwörter statt ganzer Sätze 

• Großbuchstaben, andere Farben, 

• Symbole und kleine Illustrationen zur Hervorhebung von 

Besonderheiten 

139

Top-Down-Ablauf der Projektstrukturplanung 

– Sechs Arbeitsschritte (1) 

1. Strukturierungsvorbereitung 

◊ Sichtung vorhandener Projektunterlagen (insb. Vision, 

Lasten-/Pflichtenheft) 

◊ Standardmodelle (z. B. Wasserfall-, V-Modell) als 

Orientierungshilfe 

2. Entwurf eines Strukturplans 

◊ Festlegung der Projektphasen und Hauptmeilensteine 

◊ Liste der in jeder Phase zu erarbeitenden Einzelergebnisse 

(Produkte, Entwürfe, Dokumente, Objekte, Artefakte) 

◊ Liste der für jedes Einzelergebnis erforderliche Arbeitsschritte 

(Aktivitäten) 

◊ Zuordnung von Verantwortlichen zu 

Einzelergebnissen/Aktivitäten (Funktionendiagramm) 

140

Top-Down-Ablauf der Projektstrukturplanung 

– Sechs Arbeitsschritte (2) 

3. Überprüfung des Planentwurfes 

◊ Vollständigkeit, Spezifikationserfüllung, 

Überschneidungsfreiheit, Eindeutige 

◊ Verantwortlichkeit, Aufwands-/Kostenerfassung 

◊ 

4. Identifikations-Nummerierung (PSP-Nummer) 

5. Ggf. Erstellung von Arbeitspaket-Beschreibungen 

6. Verabschiedung der Strukturpläne und 

Änderungsdienst 

141

Beispiel für ein Funktionendiagramm 

142

Arbeitspakete - Definition 

Als Arbeitspakete (AP) bezeichnet man Teilaufgaben, die im 

Projektstrukturplan (!) nicht weiter untergliedert werden. 

Bei ihrer Beschreibung und bei der Ablaufplanung können 

Arbeitspakete aber durchaus noch weiter in „Arbeitsvorgänge“ 

untergliedert werden. 

143

Arbeitspakete – Regeln/Kriterien 

• Jedes Arbeitspaket ist eine klar abgegrenzte, geschlossene 

Arbeitseinheit. 

• Jedes Arbeitspaket weist ein genau spezifizierbares und 

überprüfbares Ergebnis auf und kann termin- und kostenmäßig 

überwacht werden. 

• Jedes Arbeitspaket kann genau einem Verantwortlichen 

zugeordnet werden. 

• Dieser sorgt für die Einhaltung der zugesagten Termine und 

Kosten und die Erbringung der vereinbarten Ergebnisse. 

• Extern vergebene Aufgaben als getrennte Arbeitspakete führen. 

• Jedes Arbeitspaket sollte eindeutig einer Projektphase 

zugeordnet werden. 

• Typische Größenordnung eine Arbeitspakets: 0,5 bis 2 

Personenmonate 

144

Arbeitspakete – Beschreibung (1) 

Die Bezeichnung des Arbeitspakets im Projektstrukturplan reicht 

für die Arbeitsverteilung an Teamexterne nicht aus. 

Hierzu müssen mindestens folgende Auftragsinformationen 

schriftlich festgehalten werden: 

• Kurzbezeichnung 

• AP-Nummer. 

• AP-Verantwortlicher 

• Ziel/Ergebnisse des Arbeitspakets 

• Voraussetzungen zur Bearbeitung / Erforderliche Zulieferungen 

145

Arbeitspakete – Beschreibung (2) 

Optional können hinzu kommen: 

• Aufgabenbeschreibung (Welche Arbeitsvorgänge sind 

durchzuführen?) 

• Anzuwendende Richtlinien und Dokumente 

• Unterschriftsfelder für Projektleiter, AP-Verantwortlichen und 

dessen Vorgesetzten 

• (Die Unterschrift betont den Vertragscharakter der AP- 

Beschreibung und ist insbesondere in der Matrix- 

Projektorganisation empfehlenswert) 

• AP-Beschreibungen werden von den für die Ausführung 

Verantwortlichen erstellt und mit dem Projektleiter abgestimmt. 

146

PSP-Überprüfungsfragen 

Können Sie für jedes PSP-Element 

• … die Erledigung objektiv und messbar feststellen? 

• … Aufwand, Kosten und Dauer schätzen? 

• … klare Verantwortlichkeiten zuweisen? 

Wenn nicht: 

• Entwickeln Sie die nächst tiefere PSP-Ebene 

• Beschreiben Sie das PSP-Element neu 

• Bei dazu fehlendem Wissen: Fremdvergabe überlegen 

147

Außerdem: Aufpassen! - keine Aktivitäten 

vergessen! 

Offensichtliche 

Aktivitäten: 

• Anforderungsanalyse 

• Grob-/Feinentwurf 

• Programmierung 

• Testdurchführung 

• Benutzerdokumentation 

• Erstellung eines 

Installationsprogramms 

• Erstellung von Programmen 

zur Datenkonvertierung 

• Projektplanung 

148 

Weniger offensichtlich: 

• Gespräche mit Kunden und 

Anwendern 

• Demos/Vorführungen für Top- 

Management, Kunden, 

Anwender 

• Reviews von Plänen, 

Entwürfen etc. 

• Behebung von Problemen 

und Fehlern nach Tests und 

Reviews 

• Verwaltung der 

Programmversionen 

• Prüfung technischer

149 

Änderungen 

• Beantworten von Fragen der 

Qualitätssicherung 

• Training von Supportpersonal 

• Hilfeleistung für frühere 

Projekte 

• Mitwirkung in „Feuerwehr“- 

Teams 

• Weiterbildung der 

Teammitglieder

Stopp! - Bisher gelernt für die Planung 

• Risikoanalyse/Risikomanagement 

• Projektstrukturpläne, generelle Projektorganisation 

• Detaillierung der Planung: Unterteilung in Arbeitspakete („vom 

Programm zum AP“), Zuordnung von benötigten Ressourcen 

(„Mensch & Material“) 

• Rollierende Planung 

• Festlegung von Projektphasen: Abläufe, Abhängigkeiten, 

(kalendarische) Anordnung über der Zeit; Definition von 

Meilensteine 

• Methodik der Phasen-Detaillierung: Mind Map, Top-Down- 

Ablauf in sechs Schritten, Festlegung eindeutiger Arbeitspakete 

• Detaillierte Zeitplanung: (kalendarische) Planung der 

Projektlaufzeit, Berechnung früheste und späteste Zeitpunkte für 

einzelne Projektphasen und des gesamten Projekts, 

Identifikation kritischer Pfade 

150

Was fehlt jetzt noch für die Planung? 

Risiken identifiziert! 

Aufgaben identifiziert und detailliert! 

Aufgaben den Ressourcen zugeordnet! 

Zuordnung von Aufwand, Kosten, Zeit! 

Aufgaben in der Zeit angeordnet! 

Alles klar? – Fast! 

Zwei kritische Punkte sind nicht vertieft! 

Geschätzte Aufwände wirklich o.k.? 

Zeitlicher Ablauf wirklich o.k.? 

151

Projektmanagement – Der Aufwandsfaktor 

Aufwandsschätzungen 

. . . sind Grundlage jeder Planung. 

• Wie lange dauert das Projekt? 

• Ist das Projekt überhaupt realisierbar? 

• Ist es technisch, mit dem vorhandenen Personal, Gerät usw. 

machbar? 

• Was kostet die Durchführung? Lohnt es sich überhaupt? 

• -> Machbarkeitsstudie, Marktanalyse 

Bei positivem Ergebnis: Annahmen in 

Projektvereinbarung festhalten. 

152

Alle Aufwands-Einflussfaktoren sind 

gleichzeitig wichtige Projektziele 

153

Exemplarisch: Schätzgenauigkeit von SW- 

Projekten 

154

Projektschätzungen: Bottom-Up vs. Top-Down 

155

(Vorab-)Schätzungen im Projekt… 

… spielen zentrale Rolle 

.. liefern für Budget und Termine notwendige 

Angaben 

.. beantworten im wesentlichen die folgenden drei 

Fragen: 

1. Wie groß ist der Arbeitsaufwand in Personenmonaten? 

2. Wie viel Kalenderzeit wird dafür benötigt? 

3. Welches sind die totalen Kosten (z. B. in Euro)? 

Totale Kosten 

= Personalkosten 

+ Hard- u. Softwarekosten 

+ Reise- u. Schulungskosten 

156

Aufwandsschätzung - Übersicht 

1. Top-Down-Methoden zur Projektgesamtschätzung: 

◊ Analogiemethode 

◊ Prozentsatzmethode 

◊ (Parametrische Schätzgleichungen )* 

◊ (Funktionspunkte)* 

2. Bottom-Up-Methoden zur Phasen-Detailschätzung: 

◊ Expertenbefragungen 

◊ Aufwandsschätzklausur 

)* nicht Gegenstand hier 

157

Analogiemethode (1) 

Vergleich des zu schätzenden Projekts mit einem oder mehreren 

bereits abgeschlossenen, ähnlichen Projekten: 

• gleiches oder ähnliches Anwendungsgebiet bzw. 

Aufgabenstellung 

• gleiche oder ähnliche Produktgröße 

• gleiche oder ähnliche Randbedingungen (z. B. Projektteam) 

Unterschiede in Aufgabenstellung und Realisierungsbedingungen 

werden vom Schätzer aufgrund seiner Erfahrung intuitiv 

angepasst. 

158

Analogiemethode (2) 

Vorteile: 

• Schätzungen bereits in sehr frühen Projektstadien möglich 

• Aufwand aus tatsächlichen Projekt-Istwerten abgeleitet 

• Schätzungen sowohl auf Gesamtprojekt- als auch auf 

Subsystemebene 

Probleme: 

• Schwierige Beurteilung der Repräsentativität der 

Analogieprojekte 

• Hohe Subjektivität der vorgenommenen Zu- und Abschläge 

159

Analogiemethode – Beispiel 

Ausgangslage: Windows-95-Datenbank: 20 PM (Personenmonate) 

Jetzt: Portierung auf Linux 

• 50 % des Programmcodes wiederverwendbar 

• 50 % müssen grundlegend überarbeitet werden 

• 20 % neue Module (sehr komplexe Zusatzfunktionen) 

160

Analogiemethode – Beispiel 

Ausgangslage: Windows-95-Datenbank: 20 PM (Personenmonate) 

Jetzt: Portierung auf Linux 

• 50 % des Programmcodes wiederverwendbar 

• 50 % müssen grundlegend überarbeitet werden 

• 20 % neue Module (sehr komplexe Zusatzfunktionen) 

Schätzung des Aufwands: 

• 50 % leicht modifiziert: 1/4 von 10 PM = 2,5 PM 

• 50 % völlige Überarbeitung: 10 PM 

• 20 % zusätzliche Neuentwicklung hoher Komplexität: 

⇒ 4 PM * 1,5 (Komplexitätszuschlag) = 6 PM 

Ergebnis: Linux-Datenbank 18,5 PM 

161

Prozentsatzmethode 

• Aus früheren Projekten wird ermittelt, wie sich Aufwand und 

Dauer prozentual auf die einzelnen Projektphasen verteilen. 

• Bei Folgeprojekten: Primäre Top-Down-Schätzung der 

Phasenverteilung 

• Zwei weitere Varianten für sekundäre Bottom-Up-Schätzungen: 

◊ Man schließt eine/mehre Projektphasen vollständig ab und 

rechnet deren Ist-Aufwand prozentual als Soll für die 

restlichen Phasen hoch. Einsatz insbesondere zur Schätzung 

der Systemtest- und der Einführungsphase. 

◊ Man führt für eine Phase/Aktivität (z. B. Programmierung) 

eine detaillierte Mikroschätzung durch und schließt daraus 

auf das Gesamtprojekt. 

• Voraussetzung: Eindeutig definiertes, einheitliches 

Phasenmodell 

• Zu Projektbeginn nur für Gegen-Checks sinnvoll, da hohes 

Fehlerrisiko bei Hochrechnung aus niedrigen Anfangswerten 

162

Prozentsatzmethode – Erfahrungswerte I 

Verteilungen Zeit/Aufwand im RUP 

(FH Darmstadt) 

163

Prozentsatzmethode – Erfahrungswerte II 

(FH Würzburg) 

164

Bedeutung von Expertenaussagen 

• Die Schätzung durch den Entwickler ist und bleibt die 

ausschlaggebenden Aussage für jede Projektkalkulation 

• Analytische Methoden sollen die Abgabe von Schätzungen 

unterstützen, bedürfen aber fast immer der Ergänzung durch 

Expertenaussagen, insbesondere bei keinen reinen SW- 

Entwicklungen, z. B. 

◊ Aufwand für Schulung und Produkteinführung 

◊ Aufwand für Bereitstellung von Daten und Inhalten 

◊ Gemischte Hardware-Softwareprojekte 

◊ Vertriebs- und Projektierungsprojekte 

• Analytische Methoden sind stärker Top-Down-orientiert 

• Expertenschätzungen beziehen sich meist auf die vom Schätzer 

bearbeiteten Arbeitspakete, sind also eher Bottom-Up-orientiert 

165

Arten von Expertenschätzungen 

Einzelschätzung 

• Ein einziger Projektleiter, Gruppenleiter oder Entwickler legt 

allein die Schätzwerte für eine bestimmte Aktivität fest 

Mehrfachbefragung 

• Es werden mehrere Schätzer, möglichst aus unterschiedlichen 

organisatorischen Bereichen, befragt und ein Mittelwert gebildet 

Delphi-Schätztechnik 

• Formalisierte, schriftliche Befragung mehrerer Experten 

• Zwei oder mehr Befragungsrunden mit Sitzungen zur Diskussion 

der Zwischenergebnisse der vorausgegangenen Schätzrunde 

Schätzklausur 

• Übertragung des Delphi-Prinzips auf eine Gruppensitzung 

166

Aufwandsschätzklausur 

Teilnehmer: 

• Projektleiter, Moderator, Protokollführer 

• Mehrere Kostenschätzer (davon ca. 50 % Projektfremde) 

Unterlagen: 

• Projektzieldefinition, Lasten-/Pflichtenheft 

• Produkt-/Projektstrukturplan und Arbeitspaketbeschreibungen 

• Projektrandbedingungen (Arbeitsmittel, Mitarbeiterqualifikation 

etc.) 

167

Aufwandsschätzklausur- Ablauf 

1. Auswahl eines oder mehrerer Referenzkomplexe zur 

Detailschätzung 

2. Schätzer schreiben Schätzungen für erstes Arbeitspaket 

anonym auf Karten 

3. Durchsicht der Karten, Ausscheiden von Extremschätzungen, 

Ermittlung von Mittelwert oder Median 

4. Bei weit auseinanderliegenden Einzelschätzungen: 

⇒ Schätzer mit pos./neg. Extremwerten erläutern Gründe (Rede/Gegenrede) 

⇒ Ggf. weitere Detaillierung in kleinere Arbeitseinheiten und Neuschätzung 

5. Beurteilung des Unsicherheitsgrades der Schätzung durch das 

Team 

6. Schätzung des nächsten Arbeitspakets im Referenzkomplex 

(Schritt 2) usw. 

7. Analogieschluss vom Referenzkomplex auf das 

Projektkomplexe 

8. Sofortprotokoll (Standardformulare) am Sitzungsende 

168

Stichwort Delphi-Methode 

169

Fazit: Realistische Schätzung 

(Hoffentlich!!! … ☺) 

Nettoaufwand laut Aufwandsschätzung 250 AT 

Projektleitung (8 % - 15 %): 10 % 25 AT 

Sonstiger Grundaufwand für 40 Mitarbeiter 

• - Wochenplanung: 0,5 Std./Woche und MA 

• - Besprechungen: 3,0 Std./Woche und MA 

• - Aufwandserfassung: 0,5 Std./Woche und MA 

• - Gesamt: 4,0 Std./Woche und MA 20 AT 

Qualitätssicherung: 2 % 5 AT 

Schätzungenauigkeit (10 % - 15 %): 10 % 25 AT 

Risikozuschlag: 10 AT 

Gesamt: 335 AT 

170

Projektmanagement – Der Zeitfaktor 

Bedeutung 

How does a project get to be a year late? 

. . . One day at a time. 

171

Detailplanung in der Zeit 

Begriffe 

Ressource: Person, Gerät oder sonstige Einrichtung, die für die 

Durchführung einer Tätigkeit gebraucht wird. Verfügbarkeit 

bestimmt nötigen Zeitraum. 

Vorgang: in sich abgeschlossene Tätigkeit, die in einer 

angemessenen Zeitdauer mit definierten Ressourcen durchgeführt 

werden kann 

Phase: Zusammenfassung von Vorgängen, die einen definierten 

Arbeitsabschnitt darstellen 

Meilenstein: Termin, zu dem bestimmte Vorgänge abgeschlossen 

sein müssen 

Kritischer Pfad: Folge von Vorgängen in einem Projekt. 

Verzögerungen schlagen sich direkt auf die Gesamtprojektdauer 

durch. 

172

Planung (2) 

Ziel: Erstellung eines Projektplans 

1. Optimale Einteilung der Ressourcen an Geld, Personal, Zeit und 

Maschinen 

2. Rasche Reaktion auf Verzögerungen, Änderung der 

Arbeitsabläue etc. 

3. Antwort auf Fragen wie: 

◊ Wie lange dauert das Projekt? 

◊ Wann beginnt/endet eine Aktivität frühestens/spätestens? 

◊ Wie lange darf eine Aktivität länger dauern als geplant, ohne 

dass sich der Endtermin des Projekts ändert? 

◊ Wofür wird eine knappe Ressource wann eingesetzt? 

173

Running example 

Projekt “P” 

• Tabelle ist unübersichtlich. 

• Wie lange dauert “P” nun? 

• Wann beginnt „T7“? 

• Welche Vorgänge muss man versuchen zu beschleunigen? 

174

Vorgangsdiagramm 

...stellt Projekt als gerichteten Graphen dar (Knoten = Vorgang) 

Bilder: Uni Augsburg 

175

Meilensteine 

176

Vorgangsdiagramm 

• Mit Meilensteinen 

• Ergänzt um Start, Ende und Meilensteine 

• Knoten annotiert 

177

Netzplantechnik 

“Alle Verfahren zur Analyse, Beschreibung, Planung, Steuerung 

von Abläufen auf Grundlage der Graphentheorie, wobei Zeit, 

Kosten, Einsatzmittel und weitere Einflussgrößen berücksichtigt 

werden können. (DIN 69900)” 

Verwendete Methoden 

• PERT Program Evaluation and Review Technique 

• CPM Critical Path Method (Vorgangspfeilnetz): 

◊ Knoten entsprechen Ereignissen, Pfeile entsprechen 

Vorgängen 

• MPM Metra Potential Method (Vorgangsknotennetz): 

◊ Knoten entsprechen Vorgängen, Pfeile entsprechen 

Ereignissen 

178

Netzplantechnik - Critical Path Method (CPM) 

• CPM ist vorgangsorientiert 

• Entwickelt 1957-59 von den Firmen Du Pont und Ramington 

Rand 

• Jeder Vorgang durch ein Vor- und ein Nachereignis begrenzt 

• Hier: Darstellung als Graph 

• Knoten = Ereignisse 

• Kanten = Vorgänge 

179

CPM - Definitionen und Darstellung 

• i, j == Ereignisse 

• FZi, SZi == frühest-/spätestmöglicher Zeitpunkt des Ereignisses i 

• V == Vorgangsbezeichnung 

• DV == Dauer des Vorgangs V 

• Scheinvorgang Vorgang ohne Tätigkeit, mit Vorgangsdauer DV 

= 0. 

180

CPM – Semantik 

• Ein Vorgang kann erst beginnen, 

◊ wenn alle vorangehenden Vorgänge abgeschlossen sind 

◊ und damit das Vorereignis eingetreten ist. 

• Jeder Vorgang kann nur einmal ablaufen 

⇒ Keine Duplikate von Vorgängen 

⇒ Keine Schleifen im CPM-Netzplan 

• Jeder Vorgang hat ein eindeutiges Vor- und Nachereignis 

⇒ Keine Multikanten 

181

CPM - Konstruktionsregeln (1) 

• Keine Schleifen 

• Keine Multikanten: 

⇒ mit Scheinvorgängen (und neuen Ereignissen) auflösen 

182

CPM - Konstruktionsregeln (2) 

• Falls ein Vorgang beginnt, bevor der vorangehende beendet ist: 

⇒ Unterteile den vorangehenden Vorgang und definiere 

Zwischen-Ereignisse 

• Bei mehreren vorgehenden Ereignissen: 

⇒ mit Scheinvorgängen zusammenfassen 

• Falls es mehrere Anfangs-/Endereignisse gibt: 

⇒ Füge mit Hilfe von Scheinvorgängen eindeutige Ereignisse 

Projektstart/-ende hinzu 

• Innerhalb einer Folge von Vorgängen können beliebig viele 

Scheinvorgänge eingefügt werden. Sie dienen neben der 

logischen Verknüpfung auch der besseren Übersicht. 

183

CPM-Graph: 

Transformation aus Vorgangsdiagramm 

Vom Vorgangsdiagramm mit Meilensteinen zum 

CPM-Graphen 

• Ersetze gemäß folgendem Schema 

184

CPM-Graph: Optimierung der Transformation 

(1) 

Entferne überflüssige Hilfsknoten und 

Scheinvorgänge 

Mindestens ein Ereignis darf kein Meilenstein sein, damit keine 

Meilensteine o.ä. entfernt werden! 

185

CPM-Graph: Optimierung der Transformation 

(2) 

Fasse äquivalente Hilfsknoten zusammen 

• Voraussetzung: gleiche Scheinvorgänge als Eingangspfeile 

• Nachfolger egal! 

186

Beispiel: Projekt “P” als CPM-Netzplan 

• Umsetzen gemäß Schema, mit anschließender Optimierung, 

ergibt 

187

Netzpläne 

Berechnung der FZi (1) 

Gegeben: 

• Für jeden Vorgang seine Dauer DV, 

• Eine Menge F von Ereignissen mit vorgegebener FZ (z. B. kann 

FZi festgelegt sein, wenn ein Mitarbeiter nicht früher zur 

Verfügung steht.) 

• Start Element von F 

Für alle Ereignisse i, deren FZi zu berechnen ist, sei diese mit 

“minus unendlich” vorbelegt. 

Idee: Vorwärtsrechnung 

Solange Knoten aktualisiert worden sind: behandle im nächsten 

Schritt deren Nachfolger. 

188

Beispiel: Projekt „P“ 

Berechnung der FZi - Initialisierung 

Hier nur Startzeitpunkt = 0 zu setzen 

189

Beispiel: Projekt “P” 

Berechnung der FZi 

190


Berechnung der Szi - Initialisierung 

191


Berechnung der Szi 

192

CPM - Definitionen 

Für jeden Vorgang V mit Vorereignis i und Nachereignis j 

definieren wir den 

frühestmöglichen Anfangszeitpunkt FAV = FZi, 

spätestmöglichen Anfangszeitpunkt SAV = SZj_DV, 

frühestmöglichen Endzeitpunkt FEV = FZi+DV und 

spätestmöglichen Endzeitpunkt SEV = SZj. 

193

Zusammenfassung Planung / Terminpläne 

- Empfängerorientierte Verdichtung - 

Bild: FH Würzburg 

194

PM-Teilprozess: Projektcontrolling (= 

Steuerung & Überwachung) 


195

Projektcontrolling = … 

…Projektüberwachung …. 

• Leistungsfortschritt 

• Terminüberwachung (z.B. Balkendiagramm, Netzplan) 

• Kostenüberwachung 

• Kapazitätsüberwachung 

….plus Projektsteuerung! 

• Koordination der Projektarbeiten und Projektmitarbeiter 

• Förderung der Motivation und Kooperation der Beteiligten 

• Steuerung des Projektgeschehens, Einleiten von 

Gegenmaßnahmen, 

• Anstoß für Planrevisionen, Einleiten von Entscheidungen 

IST -> SOLL -> ABWEICHUNGEN -> ABWEICHUNGSANALYSE 

196

Abweichungsanalyse 

Ursachen: 

• Falsche, nicht mögliche Einschätzung von Schwierigkeiten und 

Umfeldbedingungen 

• Fehler in der Planung, Planungsausführung 

• Plötzlicher Eintritt unerwarteter Ereignisse 

197

Voraussetzungen für das Projektcontrolling 

• Projektplanung 

• Projektberichterstattung (=Reporting), z. B. computergestützt 

• Regelmässige Anpassung der Planung an den Fortschritt 

198

Planung und Überwachung 

Bild: TU München 

199

Projektcontrolling – Regelkreis 

Bild: Uni Würzburg 

200

Projektcontrolling – Aufgaben 


201

Projektcontrolling – Aufgaben und 

Organisation 


202

Projektcontrolling= 

Projektüberwachung und Projektsteuerung 

Ziel: Tatsächlichen Projektverlauf mit geplantem 

Projektverlauf in Übereinstimmung bringen 

◊ Punktgenaue Planeinhaltung möglich bei Abweichungen bis 

max. +/– 20 % um Idealwert („Self-fulfilling Prophecy“) 

◊ ca. 20 bis 30 % verschiebbare, persönliche Pufferzeiten 

◊ Nutzung des “Deadline”-Effektes (Wichtige Meilensteine, 

Reviews, Kunden-/Managementpräsentationen) 

◊ Aber auch lockerere bzw. sorgfältigere Arbeitsweise 

(Ausfüllen zu großzügig geplanter Termine und Budgets) 

Notwendigkeit: Frühwarnsystem mit dem 

Planabweichungen möglichst früh erkannt und 

Steuerungsmaßnahmen ausgelöst werden können 

203

Maßnahmen im Projektcontrolling 

(Uni Hamburg) 

204

Reaktionszeit bei Planabweichungen 

205

Transparenz des Projektfortschritts 

206

Empfohlene Überwachungszyklen 

(FH Darmstadt) 

207

Ablauf des Projektcontrollingprozesses 

1. Projektdatenerfassung 

◊ Erhebung, Überprüfung und Aufbereitung von Daten zur 

aktuellen Projektsituation 

2. Soll-Ist-Vergleich 

◊ Vergleich zwischen Plan und Ist und Feststellung von 

Abweichungen 

3.Abweichungsanalyse 

◊ Gründe für Soll-Ist-Abweichungen sowie Aufzeigen möglicher 

Korrekturmaßnahmen 

4.Steuerungsmaßnahmen 

◊ Entscheidung, Durchführung und Kontrolle von Maßnahmen 

zur Zielerreichung und Korrrektur von Abweichungen 

208

Projektüberwachung im magischen Dreieck 


209

Meilenstein-Kostendiagramm 

210

Abschnitt 2: Die Arbeitswertanalyse als methodisches 

Beispiel 

• Inhaltsübersicht - Unterpunkte: 

• 1. Kostenverfolgung: Die übliche Methode 

• 2. Der Arbeitswert-Ansatz 

• (Earned Value Analysis): Beispiel 

• 3. Arbeitswert: Abweichungsanalyse 1/2 

• 4. Schätzung der erwarteten Gesamtkosten 

• 5. Arbeitswertanalyse für das Gesamtprojekt = Summe der 

Einzel-Arbeitspakete 

211

Kostenverfolgung, die übliche Methode 

Arbeitspaket 2.1, Plandaten: 

Dauer 4 Wochen 

Aufwand/Kosten 160 Stunden/16.000 Eur. 

Nach drei Wochen Bearbeitungsdauer: 

• Bisherige Kontierung: 96 Arbeitsstunden / 9.600 Eur. 

• Erste Schlussfolgerung: Projekt liegt kostengünstig im Plan … 

212

Arbeitswert-Ansatz (Earned Value Analysis) 

Nochmals Arbeitspaket 2.1, Plandaten: 

Dauer 4 Wochen 

Aufwand/Kosten 160 Stunden/16.000 Eur. 

Nach drei Wochen Bearbeitungsdauer: 

Bisherige Kontierung: 96 Arbeitsstunden / 9.600 Eur. 

-> 50 % der Arbeiten sind fertiggestellt. 

Folgerungen: 

• 12 TEur Plankosten (BCWS Budgeted Costs for Work 

Scheduled) 

• 9,6 TEur Istkosten (ACWP Actual Costs of Work Performed) 

9,6 TEur tatsächliche, bisher angefallene Kosten 

• 8 TEur Arbeitswert (Earned Value, Sollkosten), Wert der 

bisher geleisteten Arbeit; 

(BCWP Budgeted Costs of Work Performed) 

213

Arbeitswert: Abweichungsanalyse (1) 

Kostenabweichung 

• Wenn die Aufgabe gemessen an ihrem Arbeitsfortschritt bis jetzt 

8 TEur (ihr Arbeitswert) hätte kosten dürfen, tatsächlich aber 9,6 

TEur gekostet hat, dann liegen die Kosten 1,6 TEur über Soll. 

◊ Kostenabweichung = Istkosten – Arbeitswert 

Leistungsabweichung 

• Es war geplant, dass die Aufgabe zum heutigen Zeitpunkt einen 

Arbeitswert von 12 TEur haben sollte. Tatsächlich hat sie erst 

einen Wert von 8 TEur. Wir haben für 4 TEur weniger geleistet 

als geplant. 

◊ Leistungsabweichung = Arbeitswert – Plankosten 

214


Cash-Flow-Abweichung 

• Es war geplant, bis zum heutigen Zeitpunkt 12 TEur 

auszugeben. Tatsächlich wurden jedoch nur 9,6 TEur 

ausgegeben. Zur Finanzierung waren 2,4 TEur weniger Cash 

Flow bereitzustellen als geplant. 

◊ Cash-Flow-Abweichung = Istkosten – Plankosten 

= Kostenabweichung + Leistungsabweichung 

Terminabweichung 

• Der Arbeitswert liegt um 4 TEur, entsprechend 33 %, hinter 

seinem Planwert von 12 TEur zurück. Bei einer bisherigen 

Bearbeitungsdauer von 3 Wochen entspricht dies einem 

Terminverzug von einer Woche. 

◊ Terminabweichung = Bearbeitungsdauer * 

[ (Arbeitswert – Plankosten) / Plankosten ] 

215


Hochgerechnete Gesamtdauer 

• Wenn die bisherige Terminabweichung weiter anhält, verlängert 

sich die Gesamtdauer von den ursprünglich geplanten 4 

Wochen auf 6 Wochen. 

◊ Erwartete Gesamtdauer = Plangesamtdauer * (Plankosten 

/ Arbeitswert ) 

Hochgerechnete Gesamtkosten 

• Um einen einen Arbeitswert von 8 TEur zu erhalten, wurden 9,6 

TEur ausgegeben, d. h. die Kosten waren um 20 % höher. 

Wenn diese Steigerungsrate weiter anhält, erhöhen sich die 

Gesamtkosten von 16 auf 19,2 TEur. 

◊ Erwartete Gesamtkosten = Plangesamtkosten * (Istkosten 

/ Arbeitswert) 

216

Schätzung der erwarteten Gesamtkosten (1) 

Prozentuale Hochrechnung der Ist- 

Kostenabweichungen 

• Nur bei Arbeitspaketen „in Bearbeitung“ / „bearbeitet“: 

• Bei niedrigerer Arbeitsproduktivität als geplant (Normalfall) 

• Bei allgemeinen Lohn- und Materialkostensteigerungen 

◊ Erwartete Gesamtkosten = Plangesamtkosten * (Ist- 

Kosten / Arbeitswert) 

Konstanthalten der Kostenabweichung (ohne weitere 

Hochrechnung) 

• Bei einmaligen Sondereffekten 

◊ Erwartete Gesamtkosten = Plangesamtkosten + 

Kostenabweichung 

217

Schätzung der erwarteten Gesamtkosten (2) 

Detaillierte Restkostenschätzung („Cost-to- 

Complete“-Schätzung) 

• Neuschätzung aller Projektaktivitäten (einschl. der noch nicht 

begonnenen) 

• Nach Abschluss kompletter Projektphasen oder in Sonderfällen 

(z. B. Krise) 

◊ Erwartete Gesamtkosten = Ist-Kosten + Aktuell 

kalkulierte Restkosten 

218

Arbeitswertanalyse für das Gesamtprojeakt = 

Summe der Arbeitspakete 

S 

219

Ist-Datenerfassung mit Microsoft Project 

(Beispiel) 

220

Messgrößen zur Überwachung von SW- 

Projekten (NASA) 

221

Organisation der Ist-Datenerfassung (1) 

Wie kann man die Istsituation in einem Projekt 

erfassen? 

Schriftliche Abfragen per Formular, Mail oder Project- 

Website 

◊ Typische Instrumente: Stundenaufschreibungen, 

Rückmeldelisten für Arbeitspakettermine, 

Kostenerfassungsbelege 

◊ Vorteil: Gute Dokumentation und Nachvollziehbarkeit 

◊ Problem: Emotionale Ablehnung bei betroffenen Mitarbeitern 

Teamorientierte Datengewinnung 

◊ Datenerhebung in Projektbesprechungen und Reviews 

◊ Vorteil: Absicherung und Verteilung der Info gleichzeitig mit 

Erhebung 

◊ Problem: Hohe Sitzungsdisziplin erforderlich 

222

223

Organisation der Ist-Datenerfassung (2) 

Gespräche und Beobachtungen 

◊ Zur Erhebung „weicher“ Daten, z. B. Motivationen, 

Stimmungen etc. 

Projektreviews 

◊ Vollständige Erhebung der Projektsituation durch 

Fragebögen, Checklisten, Interviews und Inspektion der 

Projektergebnisse 

224

Erfassung des Arbeitswerts (1) 

Wie kann der Arbeitswert eines Arbeitspakets 

bestimmt werden? 

„Prozent-Fertig-Schätzung“: Einzelschätzung des prozentualen 

Fertigstellungsgrades durch die Arbeitspaketverantwortlichen 

„Zeit-Proportionalität (Time-to-Complete-Schätzung)“: 

Schätzung der Restbearbeitungsdauer durch die 

Arbeitspaketverantwortlichen 

50-50-Methode (Automatismus bei kleinen Arbeitspaketen): 

◊ Noch nicht begonnen: 0 % fertig 

◊ In Bearbeitung: 50 % fertig 

◊ Abgeschlossen und abgenommen: 100 % fertig 

225

Erfassung des Arbeitswerts (2) 

0-100-Methode (Für Minimeilensteine = Aufteilung 

Arbeitspakete in Miniaktivitäten von ca. 1 - 2 Arbeitstagen 

Aufwand): 

◊ Minimeilenstein noch nicht fertig: 0 % 

◊ Minimeilenstein abgeschlossen: 100 % 

Reifegradbeurteilung der Arbeitsobjekte (s.u.) 

Mengen-Proportionalität: Orientierung an einem 

messbaren/zählbaren Schlüssel, z. B. Lines of Code, Anzahl 

Medien, Anzahl Interviews etc. 

226

Reifegradbeurteilung: Sechs 

Entwicklungsschritte zum fertigen Ergebnis 

Prinzip: Jedes Arbeitspaket wird in eine 

standardisierte Folge von Mikroprozess-Schritten mit 

Durchschnittsprozentwerten zerlegt 

Vorteil: Gut für teamorientierte Erfassung in Statussitzungen 

geeignet 

227

Mengenproportionalität: Quellcode-Wachstum 

im Projektverlauf 

228

Mengenproportionalität: Anzahl 

Fehlermeldungen 

229

Psychologische Effekte der 

Projektüberwachung 

Problematische Projektdatenerfassung 

◊ Fast-schon-fertig-Syndrom („90%-Syndrom”) 

◊ Kostenverbuchung nach „Tragfähigkeitsprinzip” 

Bewusste / unbewusste Schönfärberei von 

Statusmeldungen 

◊ Die Messung eines Parameters und dessen Beachtung durch 

das Management beeinflusst dessen Nützlichkeit 

◊ Hauptaspekt: Angst vor negativer Einstufung 

230

„Schwache Signale“ zur Früherkennung von 

Abweichungen 

• Wiederholte Änderung von Projektzielen und Projektprioritäten 

• Arbeits- und Terminzusagen werden wiederholt nicht 

eingehalten 

• Doppelbelastung der Projektmitarbeiter durch zusätzliche 

Aufgaben 

• Häufige Personalwechsel im Projektteam 

• Nachlassendes Interesse des Managements und des 

Machtpromotors 

• Notwendige Entscheidungen werden nicht getroffen 

• Probleme werden vertagt oder vertuscht 

• Unzureichende Abstimmung von Arbeiten und Zunahme der 

• Missverständnisse zwischen den Projektbeteiligten 

• Zurückgehende Motivation und Loyalität der Mitarbeiter 

• Abkapselung und Detailperfektion 

231

Typische Inhalte eines Projektstatusberichtes 

232

Darstellung ins MS-Project: Gantt-Diagramm 

233

2. Beispiel für Soll-Ist-Vergleich (tabellarisch) 

234

Reifegrad, Meilenstein-Trenddiagramm 

235

Kosten-Trenddiagramm 

236

Darstellung und Bewertung mit 

Ampelsymbolik 

237

Verfolgung der Teammoral durch Befragung 

238

Dichtung und Wahrheit in Projekt- 

Statusberichten 

239

Ursachen Plan/Soll-Ist-Abweichungen 

240

Korrekturmaßnahmen bei Soll-Ist- 

Abweichungen 

241

Beispiel Statussitzung – Agenda Besprechung 

242

Verfolgung von Action Items!! 

243

Projektverfolgung: Management-Reviews 

244

Management-Reviews: Typische Fragen 

245

Management-Reviews: Wo/Wann im Projekt? 

246

Beispiel: Projektplanungs-Review 

247

Beispiel: Projektplanungs-Review 

248

Zusammenfassung 

Projektüberwachung/Steuerung 

249

Projektabschluß 


250

Projektabschluß: Inhalte 

Definiertes Ende => bewusste Gestaltung des Projektabschlusses 

• Ergebnisabnahme: intern (=Management) & beim Kunden; 

Schriftlichkeit!! 

• Ergebnisimplementierung 

• Übergabe der „Objekte“ (Hardware, Software, Produkt, Bericht) 

• Vollständige Dokumentationen; ggf. getrennt für internen Bedarf 

(für Pflege&Wartung und/oder Folgeprojekte) und extern für 

Kunde (Bedienungsanleitung)! 

• Kaufmännische Abrechnung des Projektes 

• Kaufmännische Beurteilung = Nachkalkulation 

• Abschließender Soll-Ist-Vergleich: Projektabschluß-Bericht 

• Sicherung der Erfahrungen; ggf. Weitergabe von Dokumentaion 

in firmeninterne „knowledge base“/Info-Management 

• Auflösung des Projektteams 

251

• Weitergabe der Mitarbeiter an (geeignete) Nachfolgeprojekte = 

Wieder-/Weiterverwendung von Erfahrung 

252

Projektabschluß - Probleme 

253

Anhang I: Besondere Aspekte 

Was der Kunde sich vorstellte! 

(Kundenwunsch?) 

Bilder: Allgemeingut “Asbach-Uralt-Klasse” (= “Goldkrone-Klasse” östlich von Helmstedt); 

Design nach Uni Paderborn 

254

Was im Vertrag (Pflichtenheft) stand! 

255

Was im Entwurfdokument stand (Design) 

256

Was der Programmierer draus gemacht hatte 

(Implementierung) 

257

... Und was der Kunde eigentlich gewollt hat 

(Kundenwunsch!) 

258

Anhang II: Alternatives Phasenmodell 

Phase 1: Begeisterung 

Phase 2: Verwirrung 

Phase 3: Ernüchterung 

Phase 4: Suche der Schuldigen 

Phase 5: Bestrafung der Unschuldigen 

Phase 6: Auszeichnung der Nichtbeteiligten 

259

"Projektmanagement"

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?