Diplomarbeit

Diplomarbeit
Grundmodul einer Plattform für

modernes Projektmanagement
Deborah Weber
Obermühle 15
6340 Baar
Datum der vorliegenden Version:

3. August 2008
Abgabetermin:
4. September 2008
Universtiät Zürich
Institut für Informatik
Inhaltsverzeichnis
1. Einleitung 9
1.1. Ausgangslage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3. Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Zielgruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Grundlagen und Begriffe 13

2.1. Allgemeine Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1. Qualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.2. Kommunikationsräume und -techniken . . . . . . . . . . . . . . . . . . 14
2.1.3. CSCW und Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.4. ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.5. KMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2. IT-Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1. Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2. Projektklassifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2.1. Klassifikation nach Wichtigkeit . . . . . . . . . . . . . . . . . . 22
2.2.2.2. Klassifikation nach Zeitpunkt und Bedeutung . . . . . . . . . . 23
2.2.2.3. Klassifikation nach Projekttypen . . . . . . . . . . . . . . . . . 23
2.2.2.4. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.3. Risiken eines Projekts . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.4. Steuerbarkeit eines Projekts . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.4.1. Das Teufelsquadrat . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.4.2. Direkt wirksame Steuerung . . . . . . . . . . . . . . . . . . . 27
2.2.4.3. Indirekt wirksame Steuerung . . . . . . . . . . . . . . . . . . . 29
2.2.4.4. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.5. Erfolgsfaktoren eines Projekts . . . . . . . . . . . . . . . . . . . . . . . 29
3
Inhaltsverzeichnis
3. Theorie des Projektmanagements 33

3.1. Allgemeines Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.1. Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2. Rollen und Gremien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.3. Informationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.4. Dokumentationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1.5. Sachmittelsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2. Projektmanagement nach Jenny . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1. Projektinstitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2. Projektabwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2.1. Projektführung . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2.2. Projektplanung . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.2.3. Projektsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2.4. Projektkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2.2.5. Projektdurchführung . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.3. Projektmanagement-Systemelemente . . . . . . . . . . . . . . . . . . . 45
3.2.3.1. Projektportfoliomanagement . . . . . . . . . . . . . . . . . . . 45
3.2.3.2. Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2.3.3. Qualitätsmanagement . . . . . . . . . . . . . . . . . . . . . . 46
3.2.3.4. Teammanagement . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.3.5. Konfigurationsmanagement . . . . . . . . . . . . . . . . . . . 47
3.3. Projektmanagement nach Specker . . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.1. Projektmanagementfunktionen . . . . . . . . . . . . . . . . . . . . . . 49
3.3.2. Projektmanagementtätigkeit . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4. Agiles Projektmanagement: SCRUM . . . . . . . . . . . . . . . . . . . . . . . 55
3.4.1. Projektmanagement in Scrum . . . . . . . . . . . . . . . . . . . . . . . 56
3.4.2. SCRUM-Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4.2.1. Product Owner - der Visionär . . . . . . . . . . . . . . . . . . 58
3.4.2.2. SCRUM Team - die Lieferanten . . . . . . . . . . . . . . . . . 58
3.4.2.3. SCRUM Master - der Change Agent . . . . . . . . . . . . . . . 59
3.4.2.4. Weitere Rollen im Scrum-Prozess . . . . . . . . . . . . . . . . 59
3.4.3. Artefakte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.3.1. Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.3.2. Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4.3.3. Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4.3.4. Impediment List . . . . . . . . . . . . . . . . . . . . . . . . . 62
4
Inhaltsverzeichnis
3.4.4. Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.4.1. Planungssitzung 1 . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.4.2. Planungssitzung 2 . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.4.3. Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.4.4. Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.4.5. Sprint Retrospektive . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.5. MIO Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.5.1. Produktentwicklungsprozess . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5.1.1. Wasserfallmodell . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5.1.2. Spiralmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.1.3. Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.1.4. Extreme Programming . . . . . . . . . . . . . . . . . . . . . . 68
3.5.1.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.5.2. Managementprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.5.3. Führungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6. Prozessintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.6.1. Projektmanagement-Prozess . . . . . . . . . . . . . . . . . . . . . . . 73
3.6.2. Führungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.7. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4. Anforderung an eine moderne PM-Plattform 79

4.1. Randbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.1.1. Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.1.2. Erweiterbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.3. Vernetzt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.1.4. Mehrsprachig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.2. Kommunikation und Zusammenarbeit . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.1. E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.2. Kontaktmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.3. Bookmarks/Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.2.4. Forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.2.5. Mailinglisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2.6. Instant Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2.7. Nachrichtenboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.2.8. Umfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.3. Informations- und Datenmanagement . . . . . . . . . . . . . . . . . . . . . . . 86
5
Inhaltsverzeichnis
4.3.1. Dokumentemanagement . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.2. Versionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.3. Strukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.4. Wissenserhaltung und Wissensfindung . . . . . . . . . . . . . . . . . . 87
4.4. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.4.1. Termine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.4.2. Management von Input und Output . . . . . . . . . . . . . . . . . . . . 89
4.4.3. Ressourcenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4.4. Aufgabenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5. Tool-Evaluation 93
5.1. Toolauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.1.1. PHProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.1.2. Open Xchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.1.3. eGroupWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1.4. Simple Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1.5. IGSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1.6. Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.2. Kommunikation und Zusammenarbeit . . . . . . . . . . . . . . . . . . . . . . . 98
5.2.1. PHProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.2.2. Open Xchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.2.3. eGroupWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.5. IGSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.6. Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3. Informations- und Datenmanagement . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.1. PHProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.2. Open Xchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.3. eGroupWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.5. IGSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.6. Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.1. PHProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.2. Open Xchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.3. eGroupWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6
Inhaltsverzeichnis
5.4.5. IGSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.4.6. Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.5. Microsoft Produkte und Alternativen . . . . . . . . . . . . . . . . . . . . . . . . 100
5.5.1. Kommunikation und Zusammenarbeit . . . . . . . . . . . . . . . . . . . 100
5.5.1.1. Office Groove 2007 . . . . . . . . . . . . . . . . . . . . . . . 100
5.5.1.2. Alternativ zu Groove . . . . . . . . . . . . . . . . . . . . . . . 104
5.5.2. Informations- und Datenmanagement . . . . . . . . . . . . . . . . . . . 104
5.5.2.1. Microsoft Sharepoint . . . . . . . . . . . . . . . . . . . . . . . 104
5.5.2.2. Alternative zu SP . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5.3. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5.3.1. Microsoft Project . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5.3.2. Open Workbench . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.6. Produktentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.6.1. Eclipse IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.7. File Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.7.1. Dropbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.7.2. Syncplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.7.3. Windows Live FolderShare . . . . . . . . . . . . . . . . . . . . . . . . . 109
6. Software Plattform 113

6.1. Programmiersprache Python . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.1.1. Vorteile von Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6.1.2. Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.1.3. Konzept und Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.1.4. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.2. Applikationsserver Zope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.2.1. Konzept von Zope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.2.2. Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.2.2.1. ZMI - Zope Management Interface . . . . . . . . . . . . . . . . 120
6.2.2.2. ZODB - Zope Object Database . . . . . . . . . . . . . . . . . 120
6.2.2.3. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.2.3. Zope Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.2.4. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.3. CMS Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.3.1. Installation Basisversion . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.3.2. Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.3.2.1. Artikel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
7
Inhaltsverzeichnis
6.3.3. Arbeitsablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

6.3.4. Benutzerberechtigungen . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.3.5. Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
7. Implementierung, Konfiguration 129

7.1. Erfüllung der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.1.1. Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.1.2. Informations- und Datenmanagement . . . . . . . . . . . . . . . . . . . 131
7.1.3. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8. Ausewrtung / Ausblick 133
9. Schlussbemerkung 135
A. Literaturverzeichnis 137
B. Innovationsspiele 143
8
1. Einleitung
1.1. Ausgangslage
Although the need is apparent, there appears to be precious little in-

novative activity in the area of software management. Perhaps this is
so because computer scientists believe that management per se is not
their business, and the management professionals assume that its the
computer scientists’ responsibility. Be that as it may, there are many
software management problems yet to be solved as well as plenty of
room for improvement in the way that such business is conducted. In
short, there are many challenges and opportunities for initiatives in soft-
ware management. Cooper (1978)
Gemäss einer Studie der Standish Group (2008) scheitert heutzutage immer noch ein Grossteil
der IT-Projekte (vgl. Abbildung 1.1). Komplexe Projekte benötigen daher ein adäquates Pro-
jektmanagement und entsprechende Unterstützung durch geeignete Tools.
Projektmanagement ändert sich in der heutigen Zeit aufgrund der erhöhten Anzahl von verteil-
ten Projekten und neuen Projektmanagementmethoden. Um ein Projekt zum Erfolg zu führen,
muss aktuell und zukünftig mehr Fokus auf die Nachverfolgung von Projektarbeitsprozessen,
effizientes und effektives Teilen von Information und Wissen zwischen den Projektmitarbeitern
in alle Richtungen, ein proaktives Änderungsmanagement und eine geeignete Prozessüber-
wachung gelegt werden (Chen u. a., 2002).
1.2. Aufgabenstellung
Der Schwerpunkt mensch | informatik | organisation (MIO) am Institut für Informatik der Uni-
versität Zürich beschäftigt sich mit der Führung und dem Management komplexer IT-Projekte.
9
1. Einleitung
Abbildung 1.1.: Erfolg von IT-Projekten (Standish Group, 2008)
Zur Unterstützung der entwickelten Methoden wurden eine eigene Lernumgebung und ver-
schiedene Tools entwickelt.
Vor diesem Hintergrund soll eine neue webbasierte Plattform zur Unterstützung der Führung
und des Managements komplexer IT-Projekte realisiert werden. Die neue Plattform soll funk-
tional performant sein und die Prozessdifferenzierung des MIO-Ansatzes unterstützen. Durch
ein einfaches Handling, Skalierbarkeit und Erweiterbarkeit soll die Plattform sich für das Ma-
nagement von komplexen IT-Projekten eigenen.
1.3. Abgrenzung
Am 4. März wurde während einer Sitzung beschlossen, diese Plattform nicht mehr selbst zu
entwickeln, sondern das Open Source ECMS „Plone“ zu verwenden. Plone gilt zum aktuellen
Zeitpunkt als zukunftsträchtige und innovative Plattform mit einer starken Community im Hin-
tergrund. Seine Stärken sind das Dokumentemanagement und die Verwaltung von Prozessen.
Das Grundmodul dient als Basis für die Erweiterung um ein Modul für die Unterstützung der
10
1.4. Zielgruppe
Zusammenarbeit nach der agilen Projektmanagementmethode „Scrum“ (Mengelt, 2008) so-

wie eines Authoring Tools zur Unterstützung des kollaborativen Schreibens (Heuberger, 2008).
Das Scrum-Modul baut auf dem Grundmodul von „Plone“ auf, während das Authoring Tool auf
dem Grundmodul und dem Scrum-Modul aufbaut.
1.4. Zielgruppe
Diese Arbeit richtet sich an Personen aus den Bereichen Wirtschaft und Informatik, an Pro-
jektleiter genauso wie an Entwickler und Manager. Sie vertieft den Ansatz, dass für ein er-
folgreiches Projektmanagement im IT-Bereich das gemeinsame Verständnis aller Beteiligten
und ein verstärkter Fokus auf Führung, Entwicklungs- und Arbeitsprozess nötig sind. Für die
Entwicklung qualitativ hochwertiger, komplexer Software reichen die klassischen Projektma-
nagementmethoden mit Fokus auf die ökonomischen Prozessziele Inhalt, Kosten und Qualität
oftmals nicht mehr aus.
1.5. Aufbau der Arbeit

Die Arbeit beginnt in Kapitel 2 mit der Klärung grundlegender Begriffe und Eigenschaften von
Projekten. Im Kapitel 3 folgt die Theorie des klassischen wie auch des agilen Projektmana-
gements. Ebenso wird hier der MIO-Ansatz erläutert. Darauf folgt im Kapitel 4 die Anforde-
rungsanalyse an eine moderne Plattform, welche zugleich aktuell und innovativ sein soll. Als
Erweiterung dazu werden im Kapitel 5 unterschiedliche Tools für die einzelnen Prozesse eva-
luiert und deren Eignung für eine moderne Management-Plattform geprüft. Kapitel 6 bereitet
den Leser mit technischem Hintergrund zum Applikationsserver „Zope“, der Programmierspra-
che „Python“ und dem ECMS „Plone“ auf die Konfiguration des Grundmoduls vor. Die genaue
Parametrisierung und Konfiguration sowie Roadmap für weitere Releases folgt in Kapitel 7.
Kapitel 8 hinterfragt kritisch den Erfolg einer modernen Projektmanagement-Plattform mit „Plo-
ne“.
11
1. Einleitung
12
2. Grundlagen und Begriffe
In diesem Kapitel werden die grundlegenden Begriffe und Eigenschaften von Projekten erläu-
tert. Das IT-Projektmanagement wird in der Literatur seit gut 50 Jahren erläutert. So gross die
Anzahl von Literatur ist, so unterschiedlich sind die Definitionen und die Entwicklung, welche
die Managementmethoden in einem halben Jahrhundert durchgemacht haben.
Der Abschnitt 2.1 fokussiert auf allgemeine Begriffe, welche nicht direkt mit dem Projektma-
nagement in Beziehung stehen, jedoch für das Verständnis des Grundmoduls und dessen
Notwendigkeit und Aufbau wichtig sind. Darauf folgt im Abschnitt 2.2 die Klärung der projek-
trelevanten Begriffe. Ebenso werden Risiken und die Eigenschaften der Steuerbarkeit und der
Erfolgsfaktoren untersucht.
2.1. Allgemeine Begriffe

Das Projektmanagement hat Beziehungen zu vielen weiteren Gebieten, welche grundlegen
für ein erfolgreiches Projektmanagement sind. Um gut von weniger gut zu unterscheiden, geht
Kapitel 2.1.1 zuerst auf den Begriff der Qualität bei Produkten und Prozessen ein sowie eine
Vertiefung im Bereich der Kommunikation im Kapitel 2.1.2. Daraufhin werden die informati-
onstechnische Konzepte von CSCW/Groupware erläutert, deren Ideen und Grundkonzepte
für eine moderne Projektmanagement-Plattform adaptiert werden. Als Abschluss folgt die De-
finition der Zielgruppe für den Einsatz dieses Basismoduls.
2.1.1. Qualität
Nicht nur die Faktoren Inhalt, Kosten und Termine sind bei einem Projekt zu überwachen,
sondern auch die Qualität. Der Anspruch an die Qualität verändert sich in einem Unterneh-
men fortlaufend. Entscheidend ist ein gemeinsames Verständnis aller Mitarbeitenden über die
Bedeutung des Begriffs Qualität und darüber, wie diese Qualität erreicht werden kann. Nach
Kessler u. Winkelhofer (2004) stützt sich die Qualität in einem Projekt nicht auf die Anwendung
13
Abbildung 2.1.: Aspekte der Qualität (Jankulik u. a., 2005)
standardisierter Prozesse, sondern auf die drei Eckpfeiler der strukturierten Vorgehensweise,
dem Einsatz passender Hilfsmittel und Werkzeuge sowie der Ausbildung des Projektteams.
Jankulik u. a. (2005) geht einen Schritt weiter und betrachtet die Qualität aus den unterschied-
lichen Aspekten bezüglich Produkte, Prozesse und Potential (siehe Abbildung 2.1, S. 14). Die
Anforderung an die Qualität in einem Softwareprojekt nimmt stetig zu und zeichnet sich nicht
nur durch das Produkt aus, sondern durch die Gesamtheit aller Merkmale einer Einheit, fest-
gelegte und vorausgesetzte Erfordernisse zu erfüllen (ISO 8402).
2.1.2. Kommunikationsräume und -techniken
Die Theorie der Kommunikationsräume umfasst sechs Dimensionen:
personell: Anzahl der beteiligten Personen sowie deren Rollen, Interessen, Heterogenität
und Geschlecht
zeitlich: Dauer des Dialogs sowie Häufigkeit (einmalig, wiederkehrend)
räumlich: Grösse und Klima des Raumes sowie Ausstattung, Anordnung der Plätze und stra-
tegische Platzierung der Leitung
14
kulturell: Werte und Regeln, Art (Dialog, Diskussion, Präsentation) sowie Sitten und Gebräu-
che (Pünktlichkeit, Offenheit)
sprachlich: gemeinsame und funktionale Sprache
Organisation des Dialogs: Gesprächsart (Plenum, Teilgruppen), Art der Gesprächsführung

und der Visualisierung, Zeitplan und Unterlagen
Die angewendeten Techniken unterscheiden sich in jeder Phase der Projektführung (vgl. 3.5).
Abbildung 2.2.: Techniken der Kommunikation nach Kuhnt (2007)
2.1.3. CSCW und Groupware
CSCW (Computer Supported Collaborative Work) beschreibt das universelle Arbeitsgebiet

und die Forschungsfelder der computergestützten Gruppenarbeit, während Groupware die
entsprechenden Systemlösungen beschreibt (Borghoff u. Schlichter, 1998). Da kooperatives
Arbeiten nicht nur die gemeinschaftliche Erledigung von Sachaufgaben bedeutet, sondern
auch Koordination und Kommunikation (Interaktion) zwischen den beteiligten Aufgabeträgern
einschliesst, verlangt es nach einer besonderen Form von Computerunterstützung. Für diese
Art der Computerunterstützung hat sich der Ausdruck Groupware eingebürgert. Der Begriff
beinhaltet somit Hardware und Software für die gemeinsame Nutzung durch mehrere Auf-
gabenträger. Groupware erlaubt, Informationen und sonstige Materialien auf elektronischem
15
Wege zwischen den Mitgliedern einer Gruppe koordiniert auszutauschen oder gemeinsame
Materialien in gemeinsamen Speichern koordiniert zu bearbeiten (Schiestl, 1996).
In der Kooperation lassen sich drei sich gegenseitig ausschliessende Dimensionen unterschei-
den, wobei vorwiegend die dritte Dimension zur Klassifizierung von Groupware-Anwendungen
verwendet wird ((Borghoff u. Schlichter, 1998), (Fischer, 2002)):
Bilaterale vs. Multiple Kooperation: Anzahl der Beteiligten Kommunikationspartner
Konjunktive vs. Disjunktive Kooperation: Ausführung der Handlung durch einen (disjunk-
tiv) oder durch beide Beteiligten
Unmittelbare vs. Mittelbare Kooperation: Räumliche und zeitliche Trennung der Kooperati-
onspartner
2.1.4. ECM
Enterprise Content Management (ECM) is the term used to describe

the technologies, tools, and methods used to capture, manage, store,
preserve, and deliver „content“ or „information“ across an enterprise or
organisation. At the most basic level, ECM tools and strategies allow
the management of an organisation’s unstructured information, whe-
rever that information exists. Unstructured information means letters,
emails, reports etc as opposed to databases or accounting systems
which contain „structured“ information. (AIIM, 2008)
Ein ECM-System soll innerhalb eines Unternehmens die für Mitarbeiter relevanten Daten ein-
heitlich auf einer Plattform zur Verfügung stellen. Die technische Herausforderung liegt hierbei
bei der Menge von unterschiedlichen Quellen, in welchen die Informationen existieren (Archiv,
Datenbank, Internet, Mail, ERP-System, Papierdokumente) (Noack, 2007). Dabei liegt der In-
halt (Content) in strukturierter, schwach strukturierter oder unstrukturierter Form vor. Der Grad
der Struktur hängt hierbei mit der verfügbaren Meta-Information und der Trennung von Layout
und Inhalt zusammen. Diese Trennung ist wichtig, weil Meta-Informationen für die elektroni-
sche Verwaltung und Kontrolle von Inhalten benötigt werden.
5 Komponenten-Modell
Die wichtigsten ECM-Komponenten und -Technologien lassen sich gemäss Kampffmeyer (2006)
(siehe Abbildung 2.3, S. 17) in die fünf Hauptkategorien Erfassung, Verwaltung, Speicherung,
Ausgabe und Sicherung einordnen. Die bisherigen Anwendungsfelder
16
Abbildung 2.3.: Die 5 Komponenten von ECM (Kampffmeyer, 2006)
17
• DM Document Management (DMS, Dokumentenmanagement)
• Collaboration (die Zusammenarbeit unterstützende Software, Groupware)
• WCM Web Content Management (einschliesslich Portale)
• RM Records Management (Archiv- und Ablageverwaltungssysteme)
• Workflow / BPM Business Process Management (Vorgangsbearbeitung)
bilden die eigentlichen „Manage“-Komponenten, welche die ECM-Komponenten zusammen

oder alternativ einsetzen. Das von der AIIM im Jahre 2005 veröffentlichte „Enterprise Content
Management House“ (siehe Abbildung 2.4, S. 18) stellt die Komplexität und den Funktions-
umfang von Enterprise Content Management dar. Informationen werden dabei als Ein- und
Ausgang dargestellt, das Business Process Management als verbindenden Aufzug zwischen
den Stockwerken.
Abbildung 2.4.: Enterprise Content Management House nach Kampffmeyer (2006)
18
Abbildung 2.5.: Marktwirtschaftliche Unternehmen und Beschäftigte nach Grössenklassen,

2005 (Bundesamt für Statistik, 2008)
2.1.5. KMU
Als kleine und mittlere Unternehmen gelten Unternehmen mit bis zu 250 Mitarbeitenden, ei-
nem Umsatz von weniger als 40 Millionen Euro resp. einer Bilanzsumme von weniger als 27
Millionen Euro. Zudem befinden sich weniger als 25% des Kapitals bei einem Unternehmen,
welches diese Kriterien nicht erfüllen. Mikro- und Kleinunternehmen (mit bis 9 resp. 49 Mit-
arbeitern) sowie Mittelunternehmen zeichnen sich durch folgende qualitative Merkmale aus
(Bamberger, 2005):
• Autonomie der Unternehmung
• Fähigkeit zur Erbringung individualisierter, differenzierter Leistung
• geringer Formalisierungsgrad, vorherrschen von informellen Kommunikationskanälen
• vorherrschende Leitungsstruktur in Form eines auf den Unternehmer abgestimmten Ein-

Linien-Systems, seltener in Form des Stab-Linien-Systems
• Entscheidungszentralisation, die auch Routineentscheidungen umfasst
Rund 99.7% aller Unternehmen mit 67.5% aller Beschäftigten gehören in die Gruppe der KMU,
mehr als 87% der Unternehmen beschäftigen weniger als 10 Mitarbeitende (siehe Abbildung
2.5, S. 19). Ein solches Unternehmen benötigt trotz dem geringen Formalisierungsgrad, einer
schlanken Organisationsstruktur und der zentralisierten Entscheidungsstelle für die Durchfüh-
rung Ihrer Projekte ein professionelles Projektmanagement.
19
2.2. IT-Projektmanagement
Die Führung eines Projektes wird als Projektmanagement bezeichnet (Jenny, 2005). Dazu
abzugrenzen ist das Projektmanagement-System, welches gemäss DIN 69905 ein organisa-
torisch abgegrenztes Ganzes ist, welches durch das Zusammenwirken seiner Elemente in der
Lage ist, Projekte vorzubereiten und abzuwickeln. Die Elemente dieses Systems sind einzel-
ne Disziplinen, die in einem Projekt von den jeweiligen Rollen berücksichtigt und beherrscht
werden müssen. Somit können in ein modernes Projektmanagement auch die Prozesse der
Führung und der Produktentwicklung mit einbezogen werden.
Viele Begriffe aus dem Umfeld des Projektmanagements werden unterschiedlich definiert und
verwendet. Dieses Kapitel soll dazu dienen, die in dieser Arbeit verwendeten Begriffe von einer
allgemeingültigen Definition abzugrenzen.
2.2.1. Projekt
Bei der Literatursuche nach der Erklärung des Begriffs „Projekt“ stellt man schnell fest, dass
keine einheitliche Definition möglich ist, sich die meisten Erklärungen in den wichtigsten Punk-
ten jedoch decken. Ein Projekt gilt als einmaliges Vorhaben auf Zeit, welches durch einen
klaren Start- und Endzeitpunkt definiert ist (Jenny (2005), Thayer u. Yourdon (1997), Früh-
auf u. a. (2001), Mangold (2002)). Ein Projekt führt dabei einen bestehenden IST-Zustand in
einen gewünschten SOLL-Zustand über, wobei die Bedürfnisse des Auftraggebers und die
Möglichkeiten des Auftragnehmers den äusseren Rahmen definieren. Jenny (2005) definiert
ein Projekt wie folgt:
Projekte sind in sich abgegrenzte, komplexe und/oder komplizierte Auf-

träge, deren Erfüllung eine Organisation bedingt, die für die Umsetzung
der Tätigkeiten eine Projektmethode anwendet, mit der alle anfallenden
Arbeiten geplant, gesteuert, durchgeführt und kontrolliert werden kön-
nen.
Nach (Mangold, 2002) ist ein Projekt ein Vorhaben, welches folgende vier Kriterien erfüllt:
eindeutiges Ziel: Auch wenn sich Ziele während des Projektverlaufs verändern, ist entschei-
dend, „dass bei einem solchen Vorhaben von Anfang an ein Ziel festgelegt und kommu-
niziert wird, so dass alle Projekbestrebungen auf die Erreichung eines derzeit aktuellen
Ziels ausgerichtet werden können.“
20
begrenzt: Ein Projekt ist im Bezug auf Zeit, Kosten und Ressourcen begrenzt. Die Anforde-
rungen an ein Projekt legen die inhaltlichen Grenzen fest, welche nötig sind, um ein
Endergebnis zu definieren und zu erreichen.
individuell: Ein Projekt zeichnet sich durch seine Individualität aus. „Projekte sind nie Routi-
netätigkeiten. Etwas, was in gleicher Art und Weise schon einmal durchgeführt wurde,
ist kein Projekt mehr. Für solche Fälle lassen sich Ablaufmodelle entwickeln, die ohne
Projektmanagement-Methoden zum erwarteten Ziel führen.“
hohe Komplexität: „Die zu bewertenden Kriterien sind hauptsächlich der Gesamtaufwand,

das notwendige Know-how und die Risiken, die das Projekt mit sich bringt.“
Nach Frühauf u. a. (2001) ist ein Projekt
die Menge aller Tätigkeiten, Interaktionen und Resultate, die mit dem
Versuch zusammenhängen, ein bestimmtes Ziel mit begrenzten Mitteln
und innerhalb begrenzter Zeit zu erreichen.
Er lehnt sich dabei an die Definition von (Thayer u. Yourdon, 1997): a project is
A temporary activity that is characterized by having a start date, spe-

cific objectives and constraints, established responsibilities, a budget
and schedule, and a completion date. If the objective of the project is
to develop a software system, then it is sometimes called a software
development or software engineering project.
Ein IT-Projekt ist im Allgemeinen ein Projekt mit einem verstärkten Bezug zur Informations-
technologie und zur Entwicklung. Einfach gesagt ist ein IT-Projekt ein Projekt, welches als
Lieferobjekt ein Stück Software beinhaltet (Client/Server-, Webapplikation, . . . ).
2.2.2. Projektklassifizierung
Die Klassifizierung von Projekten beeinflusst die Wahl der Projektmanagement-Methode sowie
die Ressourcenplanung. Im Verlaufe der Zeit festigten sich die klassischen Klassifizierungs-
kriterien und wurden um neue erweitert. Wie bei der Wahl der Projektmanagementmethode
gibt es auch bei der Klassifizierung keine einheitliche Richtline. Je nach Projektdauer, nach
Erfahrung der Projektleiter und des Projektteams und den verfügbaren Ressourcen, werden
Projekte innerhalb einer Unternehmung unterschiedlich klassifiziert. Für eine klare Übersicht
und ein realistisches Projektportfoliomanagement sollte die Projektklassifizierung unterneh-
mensintern standardisiert und Projekte nach gleichen Kriterien bewertet werden.
21
2.2.2.1. Klassifikation nach Wichtigkeit
Jenny (2005) stuft Projekte nach Wichtigkeit in vier Klassen (A − D) ein, wobei A die höch-
ste Wichtigkeit besitzt. Mögliche Einstufungskriterien sind Strategieeinfluss, Organisationsver-
änderung, Effizienz, Komplexität, Kosten, Intensität der Projektabwicklung, Risiko oder Wirt-
schaftlichkeit, welche mit konkreten Zahlenwerten oder durch eine verbale Gewichtung (hoch-
/mittel/tief) skaliert werden. Nebst der Einstufung nach Wichtigkeit ist jedoch eine zusätzliche
Abbildung 2.6.: Projektklassifikation anhand eines Kiviat-Diagramms nach Jenny (2005)
Einstufung nach Dringlichkeit notwendig. Die Einstufung wird aufgrund der gleichen Kriterien
für alle Projekte eines Unternehmens vorgenommen. Dabei ist zu beachten, dass die Klassi-
fikation auch abhängig von der Grösse des Unternehmens ist. Ein Projekt, welches in einem
Unternehmen als ein B-Projekt klassifiziert wird, kann bei einer anderen Unternehmung auf-
grund anders gewichteter Kriterien als ein A- oder ein C-Projekt eingestuft werden. Anhand
eines Kiviat-Diagramms (siehe Abbildung 2.6, S. 22) kann die Projektklassifikation nach Krite-
rien visualisiert werden.
Auch Specker (2004) stuft Projekte in Kategorien anhand der Kriterien Umfang, organisatori-
sche Komplexität, Komplexität des Kundenproblems, Know-How und Technologiekomplexität
ein. Dabei entstehen drei Kategorien A−C. Er weist darauf hin, dass auch in kleineren und we-
niger komplexen Projekten alle Aspekte des Projektmanagements wahrzunehmen wären.
Im klassischen Projektmanagement werden Projekte also hauptsächlich nach Dimensionen,

fachlichen Inhalten, messbaren Grössen und Vorgehensphilosophie kategorisiert (Kessler u.
Winkelhofer, 2004). Kessler selbst unterscheidet Projekt anhand folgender Kriterien:
22
• die Komplexität, Vielfalt und Dynamik des Umfeldes des Projektes
• projekttypische Merkmale, wie Innovationsgrad, Terminkritikalität und Komplexität der

Projektziele
• die Struktur des Projektes, die sich aus der Grösse ergibt und
• Grad der Auswirkung der Projektziele
2.2.2.2. Klassifikation nach Zeitpunkt und Bedeutung
Applegate (2005) unterscheidet Projekte nach Zeitpunkt und Bedeutung aus Unternehmens-
sicht (vgl. auch Kuhnt (2007)).
Strategische Projekte sind kritisch für die Unternehmensstrategie und benötigen eine zentrale
Planung. Die Erreichung der Ziele ist für das Unternehmen von hoher Bedeutung und bringt
einen Mehrwert in der Zukunft.
High Potential Projekte können den Erfolg eines Unternehmens in der Zukunft möglicher-
weise entscheidend beeinflussen. Zum aktuellen Zeitpunkt zeichnen sie sich jedoch durch
ein hohes Risiko aus, da der Erfolg und somit ein erfolgreiches ROI nicht garantiert werden
kann.
Kritisch-operative Projekte sind zum Zeitpunkt der Durchführung von hoher Bedeutung und
verfolgen das Ziel einer quantifizierbaren Leistungsverbesserung. Sie gelten als besonders
kritisch, da der Erfolg des Unternehmens zurzeit davon abhängig ist.
Unterstützende Projekte sind weder kritisch noch risikobehaftet. Sie verfolgen das Ziel von
Kosten- und Aufwandsreduktion durch Optimierung, zum Beispiel durch elektronische Unter-
stützung. Sie sind für das Unternehmen weder zum aktuellen Zeitpunkt noch in der Zukunft
erfolgskritisch und meist ausserhalb der Kernkompetenzen angesiedelt.
2.2.2.3. Klassifikation nach Projekttypen
Frühauf u. a. (2001) teilt Projekte grob in drei Gruppen anhand des typischen Inhalts der Pro-
jekte.
A: Auftragsprojekt: Es gibt einen klassischen Auftragnehmer und einen Auftraggeber. Der

Auftragnehmer entwickelt hierbei ein Produkt für den Käufer. Verantwortung, Lieferung
und Zahlung sind in einem Vertrag klar geregelt. Konflikte werden notfalls vor Gericht
gelöst.
23
B: Interne Projekte: Unternehmensintern wird ein IT-Projekt für den Eigenbedarf entwickelt.
Auftragnehmer und -geber gehören hierbei dem gleichen Unternehmen an. Konflikte
werden über den gemeinsamen Vorgesetzten gelöst.
C: Entwicklungsprojekte: Der dritten Gruppe gehören eigens entwickelte Softwarepakete

an, welche erst nach der Fertigstellung auf den Markt gebracht werden. Diese lösen
meist gängige Problemstellungen und werden durch Marketing oder einen Produkt-
Manager während der Entwicklung begleitet und danach vertrieben. Konflikte werden
ebenfalls intern geregelt.
2.2.2.4. Fazit
Projekte können anhand unterschiedlicher Merkmale klassifiziert werden (Jenny (2005), Kes-
sler u. Winkelhofer (2004), Frühauf u. a. (2001)). Dabei werden diese Merkmale je nach Be-
reich des Projektes und Grösse und Art des Unternehmens unterschiedlich stark gewichtet
sowie fortlaufend angepasst oder neu definiert. In der Informatik, speziell in der Applikations-
und Softwareentwicklung und grundlegend für diese Arbeit, möchte ich Projekte nach folgen-
den Merkmalen charakterisieren:
Projektdauer: Die Projektdauer wiederspiegelt den Gesamtaufwand in einem Projekt und

steht im direkten Zusammenhang mit den benötigten personellen sowie räumlichen Res-
sourcen und den Kosten. Ebenso kann die Dauer auch einen Einfluss auf die Komplexi-
tät eines Projekts haben.
Stakeholder: Als Anspruchsgruppen (engl.: Stakeholder) gelten alle Beteiligte in einem Pro-
jekt, wobei einzelne Personen mit gleichen Anforderungen und Interessen zusammen-
gefasst werden. Ein Stakeholder muss nicht zwingend während der Entwicklung am
Projekt beteiligt sein. Miteinbezogen werden hier auch Gruppen, welche erst nach dem
Projektabchluss vom Resultat profitieren, so zum Beispiel die Endbenutzer bei einer
Online-Applikation.
Als vereinfachte Struktur übernehme ich für die Definition der Stakeholder nach Frühauf
u. a. (2001) die drei Gruppen Projekteigentümer, Projektleiter und Entwickler.
Benötigte Ressourcen: Nicht nur die personellen Ressourcen müssen in einem Projekt be-
trachtet werden, sondern auch räumliche und externe Ressourcen. Unter Ressourcen
sind z.B. Entwickler mit bestimmtem Know-How gemeint, aber auch externe Ressourcen
wie z.B. Juristen für rechtliche Abklärungen, hinzugekaufte Drittentwicklungen, externe
Manpower oder kundenseitige Mitarbeiter.
24
Dezentralisierungsgrad: Der Dezentralisierungsgrad hat einen direkten Einfluss auf die so-
ziale Führung in einem Projekt. Ein stark dezentralisiertes Projektteam benötigt mehr
Koordination, bessere Kontrollen und virtuelle Kommunikationskanäle. In der heutigen
Zeit werden durch die moderne Informations- und Kommunikationstechnik und die Anfor-
derung an spezifisches Know-How einzelner Projektmitglieder vermehrt verteilte, soge-
nannte virtuelle Projektteams gebildet, welche an unterschiedlichen Standorten arbeiten
(Chen u. a., 2002).
Produktvariante: Bei der Produktvariante unterscheiden wir die beiden grössten Gruppen
Neuentwicklung und Weiterentwicklung, welche jedoch grundsätzlich die gleichen Pro-
jektmanagementmethoden verwenden.
2.2.3. Risiken eines Projekts
Das Projektrisiko gilt gemäss DIN 62198 als die „Kombination aus Eintrittswahrscheinlichkeit
eines bestimmten Ereignisses und seinen Folgen für die Projektziele“. Die Risikofaktoren be-
treffen hierbei das Projekt selbst wie auch seine Umwelt. Gaulke (2004) nennt als Risikofak-
toren eines Projekts nebst externen Einflüssen wie Umwelt, Gesellschaft, Wirtschaft, Recht,
Zuverlässigkeit, Markt und Technik nur einen internen Aspekt: den Menschen.
Nach (Jenny, 2005) verkörpern „Projektrisiken [. . . ] den potenziellen Schaden (materiell/kör-

perlich), den Unternehmen oder Personen erleiden, wenn die Projektziele nicht erreicht wer-
den“. Die Problematik im Risikomanagement ist es, die Wesentlichen zu identifizieren und zu
verfolgen. Mangold (2002) listet häufige Risiken:
Konsens: Auftraggeber und Auftragnehmer arbeiten aneinander vorbei, da das Verständnis

des Ziels unterschiedlich ist. Bereits zu Beginn eines Projekts muss eine gemeinsame
Basis geschaffen werden.
Veränderungen: Anforderungen und Ziele ändern sich während eines Projektverlaufs. Die-
se Änderungen müssen nachverfolgt und richtig abgehandelt werden. Durch ein gutes
Change Management sowie klare Abläufe, offene Kommunikation und Transparenz kön-
nen Änderungen optimal umgesetzt und verfolgt werden.
Lieferung: Liefert der Auftraggeber seine vertraglich zugesicherten Leistungen nicht zur rich-
tigen Zeit, so können definierte Termine gefährdet werden. Ein genaues Festlegen des
Lieferumfangs und des Liefertermins erhöht die Transparenz.
25
Das magische Dreieck
Unter dem magischen Dreieck versteht man das Management der ökonomischen Prozessziele
Leistung, Zeit und Kosten. Wird eine Komponente verändert, so müssen sich automatisch
auch die beiden anderen Komponenten ändern, um das Dreieck im Gleichgewicht zu halten.
Das Problem beim magischen Dreieck ist die Fokussierung auf diese drei Prozessziele und die
Vernachlässigung anderer wichtiger Faktoren wie Qualität, Erfolgsfaktoren, soziale Führung
und Produktentwicklung. Die Theorie des magischen Dreiecks funktioniert nur in einem Projekt
mit einem reibungslosen Ablauf, und dies ist oftmals nur in kleinen und unkritischen Projekten
mit geringer Komplexität zu finden (vgl. auch Kapitel 2.2.4.1).
Klassisches Projekt-Controlling überwacht hierbei nur die obigen drei Prozessziele. Dass dies
heutzutage nicht mehr den Anforderungen genügt, muss hier nicht explizit erwähnt werden.
Notwendigkeit des Risikomanagements
siehe (Gaulke, 2004), Seite 11/12 –> folgt
2.2.4. Steuerbarkeit eines Projekts
Die Projektsteuerung umfasst alle projektinternen Aktivitäten des Pro-

jektleiters, die notwendig sind, um das geplante Projekt innerhalb der
Planungswerte abzuwickeln und erfolgreich durchzuführen (Jenny, 2005).
Klar definierte Ansprechpartner in jeder Disziplin eines Projektes und ein grundlegendes Ver-
ständnis der Vorgehensweisen wie auch die richtige Beurteilung und Einschätzung von Auf-
gaben sind Grundvoraussetzung zur Steuerung eines Projekts (Stoyan, 2004). Nach Jenny
(2005) ist für die Steuerung eines Projektes nebst brauchbaren Planungsvorgaben auch ein
geeignetes Messverfahren zur Projektkontrolle notwendig, um mögliche Abweichungen festzu-
stellen. Die so erkannten Abweichungen können mit entsprechenden Massnahmen korrigiert
werden.
2.2.4.1. Das Teufelsquadrat
Als Voraussetzung für eine erfolgreiche Steuerung sind gemäss Jenny (2005) folgende Punkte
zu erfüllen:
• Klare Bestimmung des Projektumfangs
• Klare Projektabwicklungsziele
26
• Genau definierte Projekteinflussgrössen
• Stetige Unterstützung des Projektleiters durch das Management
• Aufgabengerechte Qualifikation des Projektleiters und des Projektteams
• Zweckmässiger Einsatz der Sachmittel
• Genaue und umfassende Kontrolle
• Möglichst detaillierte Planung
Abbildung 2.7.: Teufelsquadrat nach (Daenzer, 2002) und (Jenny, 2005)
Einen grossen Einfluss auf die Effektivität der Steuerung hat die Erfahrung des Projektleiters,
da Steuerungsmassnahmen meist mehr als eine der Projektgrössen Kosten, Leistung, Termin
und Qualität betrifft. Das Teufelsquadrat (siehe Abbildung 2.7, S. 27) zeigt auf, wie sich Än-
derungen an einer Projektgrösse auf den ganzen Rahmen auswirken. Für eine Optimierung
stehen dem Projektleiter im Voraus konstruktive und im Nachhinein analytische Massnahmen
zur Verfügung. Diese können unter dem Aspekt der direkt oder indirekt wirksamen Steuerung
betrachtet werden.
2.2.4.2. Direkt wirksame Steuerung
Die direkt wirksame Steuerung wirkt sofort und kurzfristig auf Differenzen zwischen der Pla-
nung und der Gegenwart sowie auf die Differenzen, welche durch den Vergleich des geplanten
27
und des erstellten Lieferobjekts aufgedeckt wurden. Eine nicht abschliessende Liste von Pro-
jektführungstätigkeiten für die direkt wirksame Steuerung gibt uns Jenny (2005):
Projektkoordination: Sind viele der Projektbeteiligten an mehreren unterschiedlichen Pro-

jekten beteiligt, so müssen Einzelaktivitäten auf die Projektziele ausgerichtet und auf-
einander abgestimmt sein.
Risikoverfolgung: In periodischen Intervallen sollen die Projektrisiken und die Erfolgsfakto-

ren überprüft und wenn nötig erweitert werden.
Steuerung von Aufwand und Zeit
Aufwand und Termineinhaltung werden durch Schätzung und Projektplan festgelegt. Die re-
gelmässige Prüfung des Fortschritts wird durch den Fertigstellungsgrad aller Aufgabenpakete
errechnet. Durch die Berechnung der bisherigen Aufwände können durch einen SOLL-IST-
Vergleich Abweichungen vom Plan festgestelltund die erforderlichen Massnahmen eingeleitet
werden. Weicht der Projektstand aufgrund von Änderungen der Projektziele ab, so müssen
Schätzung und Projektplan neu erstellt werden. Um eine termingerechte Abgabe dennoch
zu gewährleisten, können weitere Ressourcen hinzugezogen oder der Umfang reduziert und
einzelne Lieferobjekte priorisiert werden.
Steuerung der Qualität
Ist durch die Projektziele definiert, welche Leistungen erbracht werden müssen, so muss die
Qualität der einzelnen Disziplinen, darunter Strategie, IT, Design und Inhalt, fortlaufend kon-
trolliert werden. Werden während des Projektes Abweichungen festgestellt, so muss in jeder
Disziplin so früh als möglich das Nötigste unternommen werden, um den Qualitätsansprüchen
aller Beteiligten gerecht zu werden. Hierzu erarbeiten die Qualitätsbeauftragten einer jeden
Disziplin in Abstimmung untereinander die erforderlichen Schritte, um einen Mindest-Standard
halten zu können.
Steuerung von Risiken
Risiken müssen vom Projektleiter erfragt und von den Projektmitgliedern mitgeteilt werden.
Auch die Auftraggeberseite soll frühzeitig über bestehende Risiken informiert werden. Es ist
nicht möglich, innerhalb eines Projekts alle Risiken zu vermeiden. Wichtig jedoch ist, diese
frühzeitig zu identifizieren und auf der Ebene der Entscheidungsträger zu lösen.
28
Steuerung von Abhängigkeiten
Aus Kundensicht können durch Abhängigkeiten von einem Dienstleister schnell hohe Kosten
entstehen. Durch das Abliefern von Teilergebnissen, der Wahl einer verbreiteten Technologie
und der Beteiligung und Einarbeitung kundenseitiger Mitarbeiter kann die Höhe der Wechsel-
kosten und somit die Abhängigkeit vom Dienstleister verringert werden. Auf Dienstleistersicht
sind vorwiegend projektexterne Abhängigkeiten zu minimieren. Die grösste Gefahr besteht
bei projektexternen Entscheidungen, Informationen und Dokumenten. Ein guter Ansatz ist der
Einbezug der externen Entscheidungsträger in das Projektteam, um Wartezeit und somit diese
Abhängigkeit zu verringern.
2.2.4.3. Indirekt wirksame Steuerung
Um das Leistungsverhalten des Projektteams längerfristig zu beeinflussen, steht dem Projekt-

leiter die Möglichkeit der indirekt wirksamen Steuerung zur Verfügung. Dazu gehören lang-
fristige Motivationsfaktoren, Mitarbeiterbeurteilung und -förderung sowie der Einsatz des ge-
eigneten Führungsstils und -verhaltens. Als Projektführungstätigkeiten für die indirekt wirk-
same Steuerung gilt nach Jenny (2005) das Projektmarketing. Es ist ein wichtiger Teil des
Stakeholder-Managements und baut auf ähnlichen Kriterien und Theorien wie das Produkt-
marketing auf. Durch Information können Widerstände gegen das Projekt abgebaut und eine
positive Haltung gegenüber dem Projekt geschaffen werden. Diese gesteigerte Motivation un-
terstützt das Projekt in allen Phasen und hilft mit, den Projekterfolg zu garantieren.
2.2.4.4. Fazit
Die Steuerbarkeit in einem Projekt hängt von der Umgebung und der betroffenen Grösse ab.
Während messbare Grössen wie Zeit und Qualität durch den Projektplan kontrolliert und direkt
korrigiert werden können, so können vorwiegend soziale Aspekte und Akzeptanz nur indirekt
über längere Zeit hinweg gesteuert werden und gehören in den Bereich der sozialen Projekt-
führung. Die indirekt steuerbaren Aspekte betreffen hierbei meist nicht nur eine Phase des
Projekts, sondern ziehen sich über mehrere Phasen und auch über mehrere Projekte hin-
weg.
2.2.5. Erfolgsfaktoren eines Projekts
Gemäss einer Untersuchung der Standish Group (siehe Abbildung 1.1, S. 10) konnten im
Jahre 2004 nur knapp 30% der IT-Projekte erfolgreich abgeschlossen werden. 18% scheiterten
29
komplett. Mehr als die Hälfte der Projekte konnten zwar abgeschlossen werden, musste aber
für einen erfolgreichen Abschluss an die äusseren Bedingungen angepasst werden.
Projektmanagement als Führung, Information und Prozess konzentriert sich auf die effekti-
ve und effiziente Gestaltung der Erfolgsfaktoren. Zu den Erfolgsfaktoren des Projektmanage-
ments zählen die Erreichung der definierten Projektziele unter der Einhaltung der geplanten
Ressourcen wie Zeit, Kosten und Kapazitäten. Sie stellen den Unternehmenserfolg sicher und
sind abhängig von den Erfolgsfaktoren für das Projektmanagement eines einzelnen Projekts
(Kessler u. Winkelhofer, 2004). Nebst dem Projektabwicklungserfolg, welcher durch die Pro-
jektabwicklungsziele definiert ist, kann auch der Systemerfolg anhand der Systemziele und
den Faktoren Akzeptanz und Wirtschaftlichkeit gemessen werden (Jenny, 2005). Wegmann u.
Winklbauer (2006) nennt als wichtige Erfolgsfaktoren:
• Business Impact: Wird ein Nutzen für das Unternehmen erzielt?
• Committed Stakeholders: Stehen die Stakeholder hinter dem Projekt?
• Realistic and manageable Scope: Ist der Arbeitsumfang des Projekts realistisch einge-
schätzt und machbar?
• Well-managed Work and Schedule: Gibt es eine hinreichend geplante Vorgehensweise

und einen realistischen Zeitplan?
• Mitigated Risks: Wurden die vorhandenen Risiken entschärft?
• High performance Team: Ist das Team leistungsfähig genug?
Soziale Erfolgsfaktoren
Während sich Wegmann u. Winklbauer (2006) auf messbare und kontrollierbare Erfolgsfak-
toren beschränkt, werden in der systemischen Projektführung die sozialen Erfolgsfaktoren
Macht, Zusammenarbeit, Wissen, Information und Identität betrachtet. Diese können als Leit-
fragen an die Stakeholder gestellt werden (Huber, 2007):
• Identität: Macht das Projekt für den Sponsor und Ihre Anspruchsgruppe zum jetzigen
Zeitpunkt Sinn?
• Macht: Liegt das vom Projekt zu entwickelnde Produkt im Interesse des Sponsors und
im Interesse Ihrer Anspruchsgruppe?
• Wissen: Verfügt Ihre Anspruchsgruppe über genügend Wissen für die Unterstützung des
Projekts? Wie fliesst das Wissen?
30
• Informationen: Verfügen Sie über die vorgesehene Informationen für das Projekt und
können Sie die erhaltenen Informationen aufnehmen und prozessieren? Wie gehen Sie
beim Informationsaustausch vor, so dass alle Beteiligten jederzeit die notwendigen In-
formationen abrufen können?
• Zusammenarbeit: Sind sie zu einer Zusammenarbeit mit dem Projekt bereit? Können
Sie die Teammitglieder genügend motivieren, Konflikte lösen und Interessengegensätze
miteinander vereinbaren?
31
32
3. Theorie des Projektmanagements
Dieses Kapitel widmet sich den Theorien des Projektmanagements. Die Literatur listet eine
Vielzahl unterschiedlicher Theorien, welche sich im Detailierungsgrad, dem Fokus und dem
Ablauf stark unterscheiden. Zuerst werden die klassischen Theorien von Jenny (2005) und
Specker (2004) sowie deren Abläufe und Artefakte erläutert. Diese beiden Theorien unter-
scheiden sich in der Art der Prozessgestaltung, decken jedoch einen grossen Teil der wichti-
gen Aspekte ab. Danach folgen die agile Methode „Scrum“ und der MIO-Ansatz. Der Abschnitt
der Prozessintegration soll aufzeigen, wie klassische und agile Methoden in den MIO-Ansatz
integriert werden können.
Das klassische Projektmanagement fokussiert auf den Reporting-Mechanismus. An moderne

Projekte, welche sich oftmals durch ein hohes Mass an Komplexität und verteilte Teammitglie-
der auszeichnen, stellen sich die Herausforderung der Zusammenarbeit, des Wissensmana-
gements und der genauen Definition von Arbeitsprozessen. Klassisches Projektmanagement
erarbeitet oft passive Reportings anstatt einer dynamischen Teamarbeits-Koordination. Pro-
jektmanagement an sich soll als nützliches System für alle gelten, um sich selbst zu organi-
sieren (Chen u. a., 2002).
3.1. Allgemeines Projektmanagement
Ein Projekt, welches innerhalb einer Organisation durchgeführt wird, hängt auch stark von der
unternehmensinternen Struktur, dem Aufbau der Hierarchie und der Verteilung der Kompeten-
zen ab. Um deren Zusammenhang zu verstehen, werden zuerst die Arten der Projektorgani-
sation und die Rollen und Gremien erklärt. Obwohl ein Projekt nicht zwingend die Organisa-
tion eines Unternehmen abbilden muss, finden sich in einer Projektorganisation oftmals die
gleichen Strukturen wieder. Das Informations-, Dokumentations- und Sachmittelsystem bilden
grundlegende Begleitprozesse eines jeden Projekts.
33
3.1.1. Projektorganisation
Unter Projektorganisation versteht man die Gesamtheit der Organisati-

onseinheiten und der aufbau- und ablauforganisatorische Regelungen
zur Abwicklung eines bestimmten Projeks [DIN 69901].
Grundsätzlich sind die Organisationsformen Linien-, Stab-Linien- und Matrix-Organisation zu

unterscheiden.
Bei einer Linien-Organisation werden die Mitglieder aus der Firmenhierarchie herausgenom-
men und zu 100% in einem einzelnen Projekt eingesetzt. Durch die hohe Effizienz und die ein-
fache Entscheidungsfindung aufgrund der gesamten fachlichen Kompetenz des Projektleiters
verkürzt sich die Projektdauer. Ist ein Projekt abgeschlossen, müssen die Projektmitglieder
jedoch wieder in neuen Projektteams, welche oftmals einem anderen Projektleiter unterstellt
sind, eingesetzt werden.
Im Gegensatz dazu bleiben die Projektmitglieder bei der Stab-Linien-Organisation direkt

ihren Linienvorgesetzten unterstellt. Der Projektleiter übernimmt hier lediglich die Koordinati-
onsaufgaben, die Entscheidungsgewalt bleibt bei der Geschäftsleitung. Diese aufgabenorien-
tierte Dezentralisierung erhöht das Projektrisiko und Bedarf einer intensiveren Kontrolle. Die
Projektmitglieder können sich weniger stark mit dem Projekt identifizieren und stellen die Pro-
jektaufgaben im Allgemeinen hinter ihre Linienaufgaben.
Als Mischform der oben genannten Organisationen gilt die Matrix-Organisation. Während
eines Projekts entsteht ein zeitlich befristetes Mehrliniensystem. Der Projektleiter hat hier
die projektbezogenen Kompetenzen gegenüber den Projektmitgliedern, der Linienvorgesetzte
kümmert sich weiterhin um das Anstellungsverhältnis und regelt die Integration in die Fir-
menhierarchie. Die Projektmitglieder arbeiten fix zu einem bestimmten Prozentsatz für ein
bestimmtes Projekt.
Tabelle 3.1 auf Seite 35 zeigt die drei Projektorganisationen im Vergleich.
3.1.2. Rollen und Gremien
Für Stellen in einer Projektorganisation werden die Aufgaben, Kompetenzen und Verantwor-
tungen (AKV) festgelegt, um das strukturierte Vorgehen zu unterstützen sowie die Koordinati-
on zu vereinfach und den Entscheidungs- und Eskalationsweg zu regeln. Wie bei herkömmli-
chen Stellenbeschreibungen sollten alle Aspekte von AKV pro Rolle aufeinander abgestimmt
34
3.1. Allgemeines Projektmanagement
Linien Stab-Linien Matrix

Weisungsbefugnis voll weisungngsbefugt nur Koordinationsauf- weisungsbefugt betref-
Projektleiter gabe fend Projektaufgaben
Verantwortlichkeit Projektleiter Geschäftsleitung Projektleiter
Komplexität hoch niedrig hoch und niedrig
Zeitdauer lang kurz kurz und lang
Einsatz Mitarbeiter Konzentration auf ein mehrere Projekte feste Beteiligung an ei-
Projekt gleichzeitig nem Projekt
Vorgesetzter der Projektleiter Linienvorgesetzter Projektleiter und Lini-
Mitarbeiter envorgesetzter
Vorteile hohe Effizienz und Fle- hohe Einsatzflexibilität optimale Kapazitäts-
xibilität im Projekt der Mitarbeiter auslastung
Nachteile Aus- und Wiederein- Linienaufgaben haben Konfliktgefahr infolge
gliederung der Projekt- Vorrang vor Projektauf- zweiter Vorgesetzter
mitarbeiter aus der Fir- gaben
menhierarchie
Tabelle 3.1.: Überblick Projektorganisation (eigene Darstellung)
sein, damit alle Projektmitglieder ihre Aufgaben im Grundsatz der Einheit und Kongruenz er-
füllen können. Um zugeteilte Aufgaben abzuschliessen, werden die entsprechenden Kompe-
tenzen benötigt, und über diesen Bereich trägt das Projektmitglied auch die Verantwortung.
Zum organisatorischen Projektumfeld gehören nebst den Projektmitgliedern in der Projekt-

organisation alle Stakeholder, also die Projektträger und alle weiteren Betroffenen und Invol-
vierten (Auftraggeber, Kunden, Lieferanten). Oftmals besetzt ein und dieselbe Person in einem
kleineren Projekt mehr als eine Projektrolle. Auch Aufbau und Grad der gesamten Projektorga-
nisation ist in weniger komplexen Projekten einfacher und wird immer der Projektklassifikation
angepasst. Die Aufgaben des Projektleiters lassen sich grob in die sechs Gebiete Planung
(25%), Kontrolle (25%), Koordination (21%), Steuerung (14%), Administration (12%) und Di-
verses (3%) aufteilen. Dabei machen Planung und Kontrolle in einem Projekt die Hälfte der
Aufgaben aus. Die Zahlen diese empirisch gestützten Untersuchung zeigen die Wichtigkeit
der zwei Bereiche Planung und Kontrolle in einem Projekt (Jenny, 2005).
3.1.3. Informationssystem
Unter Projekt-Informationssystem wird das richtige Verhältnis zwischen

vorhandenen, notwendigen und nachgefragten Informationen in einem
Projekt verstanden und deren Zusammenwirken bei der Erfassung, Be-
und Verarbeitung, Auswertung und Weiterleitung (Jenny, 2005).
35
Das Projekt-Informationssystem besteht aus den Bereichen Projektsitzung, Dialog, Präsenta-

tion und Projektberichtswesen.
Eine Projektsitzung wird einberufen, wenn Kommunikation benötigt wird und Informationen in
beide Richtungen fliessen sollen. Als Dialoge gelten unter anderem Telefonate und Diskussio-
nen. Sie sind eine wichtige jedoch zeitintensive Art von Informationsaustausch. Ein grosser Teil
der Dialoge wird als Koordinationstätigkeit verstanden. Dialoge finden meist informell statt. Im
Gegensatz zur Projektsitzung fliesst die Information bei der Präsentation anfangs nur in eine
Richtung. Erst nach der eigentlichen Präsentation kann, muss aber nicht, eine Diskussion fol-
gen. Nach der Durchführung folgt die Nachbearbeitungsphase, in welcher Bilanz über positive
und negative Aspekte gezogen wird. Bei Projektberichten werden Informationen als Rapporte
rein schriftlich festgehalten. Der wichtigste Bericht ist der Projektstatusbericht. Dieser dient als
Kontroll- und Steuerungsmassnahme während eines Projekts und wird periodisch verfasst.
Die Informationen für den Projektstatusbericht erhält der Projektleiter aus unterschiedlichen
Quellen und fasst daraus folgende Aspekte zusammen:
• Zeitpunkt der Fortschritts- und Aufwandsmeldung
• Vergleich von SOLL/IST-Zustand des Projektes
• Erzielte Erfolge
• Beurteilung der Wirksamkeit früher eingeleiteter Steuerungsmassnahmen
• Gründe der Abweichung und Massnahmen (Vorschläge/Anträge von Projektleiter)
• Aufwandgemässer Stand des Projektes (Restaufwand)
• Personalsituation und zukünftiger personeller Aufwand
• Hauptaktivitäten der nächsten Berichtsperiode
3.1.4. Dokumentationssystem
Als Projektdokumentation gilt die Zusammenstellung von ausgewähl-

ten, wesentlichen Daten über Konfiguration, Organisation, Mitteleinsatz,
Lösungswege, Ablauf und erreichte Ziele innerhalb eines Projektes [DIN
69901].
Dokumente sind ebenso Lieferobjekte in einem Projekt wie das eigentliche Produkt. Im Bereich
der Projekt-Führung entstehen Dokumente, welche aus der Tätigkeit der Projektführung her-
vorgehen. Zu den Dokumenten der Projekt-Durchführung gehören nebst dem Business Case
36
3.2. Projektmanagement nach Jenny
und dem Anforderungskatalog Schriftstücke aus der Konzeptions- und Realisierungsphase.

Tabelle 3.2, S. 37 zeigt im Überblick, welche Lieferobjekte bei welcher Projektklassifikation als
muss unbedingt erstellt werden müssen, welche Berichte auch in gekürzter Fassung genügen,
und welche unwichtig sind. Für eine detaillierte Erklärung der einzelnen Lieferobjekte sei auf
Lieferobjekt | Klassifikation A B C D
Projektantrag m m g u
Projektauftrag m m g g
Realisierungsantrag m m m g
Einführungsantrag m m m m
Projektabschlussbericht m m g g
Projektplan m m m g
Projektstatusbericht m m m g
Business Case m m g u
Anforderungskatalog m m m m
Konzept m m m g
Tabelle 3.2.: Lieferobjekte gemäss Projektklassifikation nach Jenny (2005)
Jenny (2005), S. 86ff verwiesen.
3.1.5. Sachmittelsystem
Projektinfrastruktur sind alle materiellen und immateriellen Einrichtun-

gen und Hilfsmittel, die zur Durchführung eines Projektes notwendig
sind [DIN 69905].
Das Projektteam sollte bereits zu Beginn des Projektes mit der benötigten Infrastruktur in den
vier Bereichen Arbeitsplatz, Büromaterial, Software und Hardware ausgestattet werden. In
einem IT-Projekt sind vor allem die Bereiche Hard- und Software zu beachten, damit Entwickler
die von ihnen erwartete Leistung auch erbringen können.
Jenny (2005) unterteilt den Ablauf eines Projekts in die zwei Bereich Führung und Durchfüh-
rung und fasst diese beiden Bereiche unter dem Begriff der Projektabwicklung zusammen.
Die weiteren Management-Funktionen (Projektportfolio, Risiko, Qualität, Team, Konfiguration,
37
Abbildung 3.1.: Projektmanagement-System nach Jenny (2005)
38
Changemanagement), welche den Projekterfolg massgeblich beeinflussen, wirken auf das ge-
samte Projektmanagement-System ein und laufen parallel zur Projektabwicklung. Allem zu-
grunde liegt die Projektinstitution, auf welcher das gesamte Projekt aufbaut (siehe Abbildung
3.1, S. 38).
3.2.1. Projektinstitution
Die Projektinstitution definiert das institutionelle Projektmanagement,

welches alle aufbauorganisatorischen Bereiche beinhaltet, die für ein
Projektmanagement-System notwendig sind (Jenny, 2005).
Im Zuge der Projektinstitution wird die Projektorganisation aufgebaut (vgl. Kapitel 3.1.1), Auf-
gaben, Kompetenzen und Verantwortung (vgl. Kapitel 3.1.2) sowie das Informations-, Dokumentations-
und Sachmittelsystem (vgl. Kapitel 3.1.3, 3.1.4, 3.1.5) festgelegt. Diese fünf Bereiche bilden
die Projektbasis.
3.2.2. Projektabwicklung
Mit Projektabwicklung wird das prozessorientierte Projektvorhaben be-

zeichnet, das in Projektdurchführung und Projektführung unterteilt ist.
Es bezieht sich auf den gesamten Aufgabenbereich vom Start bis zum
Abschluss eines Projektes. Jenny (2005)
Die Projektabwicklung umfasst die zwei Kernelemente der Führung und Durchführung eines
Projektes. Dabei arbeiten die zwei Bereiche parallel zueinander. Abbildung 3.2 zeigt das dy-
namische Zusammenspiel zwischen der Führung und Durchführung in einem Projekt.
3.2.2.1. Projektführung
Die Projektführung beinhaltet alle leitenden Führungsaufgaben, welche

von einem Projektleiter in einem Projekt wahrgenommen werden müs-
sen, um die Abwicklungsziele zu erreichen (Jenny, 2005).
Zur Projektführung gehören die funktionielle und die personenbezogene Führung. Für weitere
Erläuterungen zur personenbezogenen Führung sei auf Kapitel 3.2.3.4 verwiesen.
Projektstart
Die einzelnen Schritte in der Startphase eines Projekts laufen sequentiell ab. Die wichtigsten
Führungsaufgaben sind u.a. die Problemformulierung, Zielsetzung und Zuständigkeitsdefinie-
39
Abbildung 3.2.: Regelkreis der Projektabwicklung nach Jenny (2005)
rung. Nach der Genehmigung des Projektantrages durch den Projektportfolio-Controller oder
Abteilungsleiter werden bei der Initialisierung die wichtigsten Eckdaten des Projekts festge-
legt (Start-, Endzeit, Kosten, Qualität etc.) sowie Nutzen, Realisierbarkeit und Erfolgschancen
beurteilt. In dieser Phase entstehen der Business Case, der Anforderungskatalog, der Pro-
jektplan und ein umfassender Projektantrag, welche in das Dokumentationssystem abgelegt
werden. Für die Freigabe geht der Projektauftrag zur Prüfung an die oberen Instanz zurück,
und erst durch die Entscheidungen des Auftraggebers und des Projektleiters wird der Projekt-
antrag endgültig gutgeheissen oder abgelehnt.
3.2.2.2. Projektplanung
Projektplanung ist die geistige Vorwegnahme der zukünftigen mögli-

chen Realitäten (Jenny, 2005).
Im Zuge der Projektplanung werden diverse Pläne erstellt.
Abwicklungszielplan: Abwicklungsziele existieren in zwei Stufen: Richtwerte und Meilenstei-

ne. Für den Abwicklungszielplan werden die Meilensteine und seine Abwicklungsziele
(Leistung, Qualität, Zeit und Kosten) aufgelistet.
Projektstrutkurplan: Als Basis für die Ablauf-, Ressourcen- und Terminplanung gilt der Pro-
jektstrukturplan, der die Gesamtaufgabe in plan- und kontrollierbare Arbeitspakete glie-
dert. Alle Arbeitspakete zusammen stellen den gesamten Leistungsumfang des Projek-
tes dar. Die Aufteilung der Komponenten in einem Projektstruktruplan kann nach Arbeit-
spaketen (objektorientiert) oder nach Projektaufgaben (vorgehensorientiert) erfolgen.
40
Ablaufplan: Der Ablaufplan zeigt die sachlogische Reihenfolge der Arbeitspakete, ohne die
genauen Zeitpunkte anzugeben. Als Hilfestellung kann eine Arbeitspaket-Liste erstellt
werden, auf welcher Vorgangsdauer, direkte Vorläufer und Nachläufer aufgeführt sind.
Ein Ablaufplan kann beispielsweise als Plan-Net dargestellt werden.
Ressourcenplan: Verfügbare Personal- und Sachmittel werden ermittelt und den einzelnen
Arbeitspaketen zugeordnet. Diese Ressourcen werden im Ablaufplan angefügt und da-
nach in das Kapazitätsbelastungs-Diagramm übertragen, auf welchem die optimale Aus-
lastung ersichtlich ist.
Organisationsplan: Der Organisationsplan umfasst die Projektorganisation, die Rollen und

die Anwendung des Informations-, Dokumentations- und Sachmittelsystems und stellt
somit die Verbindung zur Projektinstitution her. Der Organisationsplan wird für das ge-
samte Projekt und danach phasenspezifisch erstellt.jj
Projektkostenplan: Der Projektkostenplan beinhaltet die Berechnung und Zuordnung der

voraussichtlichen Kosten für die einzelnen Arbeitspakete. Zu den Projektkosten werden
auch Anschaffungen für dieses eine Projekt gezählt, jedoch keine Betriebskosten. Aus
der Summe der Kosten für die Arbeitspakete werden die Gesamtkosten und somit das
Buget berechnet. Wie im Ablaufplan werden auch im Projektkostenplan keine Termine
festgehalten.
Terminplan: Im Terminplan werden die wichtigen Termine und die Meilensteine sowie Be-
ginn und Ende der Arbeitspakete festgehalten. Als Basis werden die vorgängig erstellen
Struktur-, Ablauf- und Ressourcenpläne herangezogen. Der Terminplan bildet den Ab-
schluss dieses Planungsprozesses. Änderungen an den Planwerten wirken sich somit
auf alle vier oben genannten Pläne aus.
Projektbudgetplan: Der Projektbudgetplan wird meist über den Zeitrahmen eines Jahres er-
stellt und zeigt das verfügbare Budget pro Monat in Abhängigkeit an Zeit-, Kosten- und
Arbeitspaket-Vorgaben an. Deckt sich das Projektbudget nicht mit den Vorgaben des
Auftraggebers, so können frühzeitig Abweichungen festgestellt werden und somit Anfor-
derungen reduziert oder Bugetänderungen beantragt werden.
Informationsplan: Als Basis für den Informationsplan werden das Projektinformationssystem

aus der Insitution und das Organigramm aus dem Organisationsplan verwendet und die
Informationsversorgung der Projektmitglieder geplant und koordiniert. Jede Information
muss hinsichtlich Empfänger, Zeitpunkt und Kommunikationskanal koordiniert werden.
Wichtig hierbei ist, dass Informationen frühzeitig an die richtigen Empfänger weitergelei-
tet werden.
41
3.2.2.3. Projektsteuerung
Die Projektsteuerung verbindet die Projektplanung mit der Projektdurchführung. Grundvor-

aussetzung für die Steuerung sind klar deifinierte Ziele und eine detaillierte Planung. Einen
genauen Überblick über die Steuerung gibt Kapitel 2.2.4 auf Seite 26.
3.2.2.4. Projektkontrolle
Durch die Kontrolle von Lieferobjekten durch eine höhere Instanz wird die Verantwortung
des Projektleiters weitergegeben. Durch eine regelmässige Prüfung und somit Abschluss be-
stimmter Lieferobjekte kann der Projektleiter sein Verantwortungsvolumen überwachen und
Arbeitspakete abschliessen. Eine regelmässige Kontrolle hilft ebenso, frühzeitig Fehler zu ent-
decken und diese möglichst kostengünstig zu beheben.
Die Projektkontrolle umfasst alle Aktivitäten und projektbezogenen Ab-

weichungen zwischen dem SOLL- und IST-Zustand aufzudecken, um
auf diese gezielt reagieren zu können.
Die Dimensionen der Projektkontrolle definieren, wie und von wem zu welchem Zeitpunkt ein
Lieferobjekt kontrolliert wird. Zur Planungskontrolle gehören hierbei die Kontrolle von Aufwand,
Kosten und Terminen. Im Bereich der Realisierung werden Fortschritt, Qualität, Dokumentati-
on und Inforamtion kontrolliert.
Aufwand und Kosten: Die Arbeitsrapporte der Projektmitglieder werden nicht nur auf Voll-
ständigkeit, sondern auch auf deren Inhalt kontrolliert. Eine Stundenerfassung auf die
einzelnen Arbeitspakete ist hierbei ideal und erleichtert den SOLL/IST-Vergleich von Ko-
sten und Aufwänden und somit den Budgetverbrauch.
Termine und Fortschritt: Schätzen die Projektmitglieder den Fertigstellungsgrad ihrer Lie-
ferobjekte, so kann daraus der Stand der einzelnen Arbeitspakete errechnet werden.
Verspätungen werden somit frühzeitig sichtbar, worauf der Projektleiter die entsprechen-
den Massnahmen einleiten kann. Kann der Fortschritt der einzelnen Arbeitspakete er-
rechnet werden, so gibt dies ebenfalls Rückschluss auf den Stand des gesamten Pro-
jekts.
Qualität: Bei der Qualitätskontrolle wird die Qualität der eingesetzten Kontrollmechanismen
beurteilt, welche als Grundlage für die Abnahme und Freigabe von Zwischenprodukten
dient.
42
Dokumentation: Die Prüfung der Dokumentation geschieht durch den Empfänger hinsicht-
lich Firmennormen, Versionierung und Inhalt. Eine regelmässige Kontrolle der Doku-
mentation ist wichtig, um deren Aktualität und Vollständigkeit zu garantieren.
Information: Der Informationsfluss sowie die Häufigkeit und der Inhalt von Berichten stehen
im Fokus der Informationskontrolle. Für ein erfolgreiches Projekt ist es wichtig, dass alle
Beteiligten zum richtigen Zeitpunkt über die richtigen Informationen verfügen.
Der Kontrollzeitpunkt bestimmt die Durchfühung und wird in einem Prüfplan festgelegt. Klare
Kontrollzeitpunkte sind Phasenenden und Meilensteine. Jedoch sollten die Abstände zwischen
zwei Kontrollen nicht grösser als drei Monate sein respektive das zu prüfende Volumen nicht
mehr als 300 Arbeitstage umfassen.
Projektabschluss
Ein Projekt wird nicht durch die Einführung, sondern durch den Projektabschlussbericht und
die Aufräumarbeiten beendet. Im Abschlussbericht werden die Abwicklungsziele Leistung,
Qualität, Zeit, Kosten) sowie Nichterfolge und die Gründe dafür festgehalten. Zu den Aufräum-
arbeiten gehören die Sicherung des während des Projekts angeeigneten Wissens sowie die
Auflösung des Projektteams. Die folgende Aufzähung listet die sechs Fragen, welche für einen
erfolgreichen Projektabschluss abgearbeitet und in den Abschlussbericht aufgenommen wer-
den (Jenny, 2005):
• Ist der Benutzer mit dem Produkt zufrieden?
• Stimmen gesetzte Ziele und realisierte Lösungen überein?
• Entsprechen die Ziele den tatsächlichen Benutzerbedürfnissen?
• Wurden die geplanten Termine eingehalten?
• Wurden die veranschlagten Kosten eingehalten?
• Wurde der angestrebte Nutzen erreicht?
3.2.2.5. Projektdurchführung
Die Projektdurchführung beinhaltet alle Projektaufgaben, die unmittel-

bar für eine effiziente Erstellung der Lieferobjekte respektive für die Er-
füllung der Systemziele vom Projetteam durchgeführt werden müssen
(Jenny, 2005).
43
Zur Durchführung gehören die sequenziell ablaufenden Phasen Impuls, Initialisierung, Kon-
zeption, Realisierung, Einführung und Nutzung.
Die ersten beiden Phasen, Impuls und Initialisierung, beziehen sich auf den Projektstart (siehe
Kapitel 3.2.2.1). Der Impuls gilt als Vorphase der Projektabwicklung und liegt den Grundstein
für ein neues Projekt. Hier werden Problemstellung, Bedarf und Idee in einem kurzen Bericht
sachlich dargelegt. Ebenso werden die benötigten Ressourcen für die Initialisierun geschätzt
und beantragt. Werden diese vom Linienvorgesetzten gutgeheissen, werden in der Initialisie-
rungsphase die Wirtschaftlichkeit, der konkrete Bedarf sowie die Systemziele des Vorhabens
geprüft.
In der Konzeptionsphase wird das Problem erfasst und eine detailliert beschriebene, realisier-
bare Lösung erstellt. Der Problemlösungsprozess teilt sich hierbei in sechs Phasen:
Zieldefinition: Wichtig ist die Messbarkeit der Ziele sowie dass diese lösungsneutral sind.
Ebenso müssen sie erreichbar und bewertbar sein. Zielkonflikte sind von vorn herein zu
bereinigen.
Erhebung und Analyse: In dieser Phase werden alle Daten für die Definition des IST- und
des SOLL-Zusandes gesammelt, nach Abhängigkeiten gruppiert und analysiert. Von der
Genauigkeit der Erhebung hängt die Qualität der zukünftigen Lösung ab.
Würdigung: Bei der Würdigung wird der IST-Zustand nach seinen Stärken, Schwächen, Chan-
cen und Gefahren (SWOT-Analyse) bewertet.
Lösungsentwürfe: Durch Erhebung und Analyse kennt man den IST-Zustand, durch die
SWOT-Analyse weiss man, welche Aspekte am IST-Zustand gut oder nicht so gut ist und
durch die Zieldefinition kennt den gewünschten SOLL-Zustand. Anhand dieser Grund-
lagen werden Lösungen und Alternativen gesammelt, welche danach konkretisiert und
analysiert werden. Je mehr Lösungsvorschläge vorhanden sind, desto grösser ist die
Wahrscheinlichkeit, die bestmögliche Lösung gefunden zu haben.
Bewertung und Entscheid: Die unterschiedlichen Lösungsansätze werden bewertet und dem
Auftraggeber vorgelegt, bei welchem auch die Entscheidugsgewalt liegt. Entscheiden
bedeutet hier, aus einer Vielzahl von Alternativen diejenige auszuwählen, mit der das
definierte Ziel unter Einhaltung der verfügbaren Ressourcen optimal erreicht werden
kann.
In der vierten Phase, der Realisierungsphase, werden die Lieferobjekte gemäss vorgängig
festgelegten Kriterien umgesetzt und mit Tests abgeschlossen. Anhand der Test- und Projekt-
statusberichte entscheidet der Auftraggeber, ob ein Produkt eingeführt wird.
44
Ist das Produkt abnahmebereit und sind somit alle Bedingungen seitens des Auftragnehmers
erfüllt, so wird das Produkt für die Einführung freigegeben. Je nach Produktart und Entschei-
dung des Auftraggebers, kann das Produkt auf einen bestimmten Stichtag, schrittweise und
somit Teilbereich für Teilbereicht oder parallel zum bisherigen Produkt eingeführt werden.
Die Nutzung gehört wie auch der Impuls nicht zum eigentlich Projekt, ist jedoch für den Pro-
duktlebenszyklus bedeutend. Für detailliertere Informationen sei auf Jenny (2005) verwie-
sen.
3.2.3. Projektmanagement-Systemelemente
3.2.3.1. Projektportfoliomanagement
Das Projektportfoliomanagement führt alle Projekte einer Führungsein-

heit. Dazu gehören alle Aufgaben, welche für das Priorisieren, das Ko-
ordinieren, das Kontrollieren und das Unterstützen der anstehenden
und laufenden Projekte und der notwendigen Ressourcen aus Projektportfolio-
Sich notwendig sind Jenny (2005).
Der Projektportfolio-Controller überwacht alle Projekte und stellt den Stand im Projektportfolio-
Controllingbericht (PPC) zusammen. Dabei werden die Projekte als grün, gelb (kritisch) oder
rot (gefährdet) deklariert. In der Besprechung des PPC mit den Projektleitern werden dann
die benötigten Massnahmen entschieden. Bei grossen Portfolios kann der Projektstatusbe-
richt elektronisch durch ein Projekt-Cockpit unterstützt werden, in welchem Risikoverfolgung,
Klassifizierung, Statusampeln, Meilensteintrend, Personalmittelplan und Finanzmittelplan auf-
geführt sind (vgl. Jenny (2005), S. 205). Je grösser das Unternehmen, je zahlreicher die Pro-
jekte und je länger die Projektdauer, desto wichtiger wird das Projektportfoliomanagement für
ein Unternehmen. Durch Priorisierungen können somit bei gefährdeten Projekten frühzeitig
Massnahmen ergriffen und so gesteuert werden.
3.2.3.2. Risikomanagement
Risikomanagement als Teil der Projektabwicklung ist das bewusste Ein-

beziehen und Bewältigen von möglichen, projektbezogenen Störfällen
in der Projektabwicklung auf der Grundlage der systematischen Erfas-
sung, Bewertung und Verfolgung von projektbezogenen Risiken Jenny
(2005).
45
Risikomanagement ist nicht alleine das Auflisten und Verfolgen von Risiken, sondern erweitert
sich auf die Analyse und die Überprüfung in jeder Projektphase. Dabei können Projektrisi-
ken in die drei Gruppen Umsetzungsrisiken (Einführung, Funktion, Materialzulieferer), Mana-
gementrisiken (Projektführung, Planung, Kommunikation, Koordination) und Soziale Risiken
(Motivation, Mitarbeiter, Politisch) unterteilt werden. Alle Risiken werden in einem Zyklus identi-
fiziert, analysiert, bewertet, gesteuert und überwacht. Dieser sogenannte Risikomanagement-
Prozess ist iterativ und wird während des gesamten Projekts wiederholt.
3.2.3.3. Qualitätsmanagement
Qualitätsmanagement in Projekten beinhaltet alle Tätigkeiten der Pro-

jektführung, welche die qualitätsbezogenen Projektziele und die Verant-
wortlichkeiten festlegen sowie diese mittels der Qualitätsplanung, der
Qualitätslenkung und der Qualitätsprüfung verwirklichen Jenny (2005).
Bei der Qualitätsplanung werden die Anforderungen an den Projektabwicklungsprozess de-

finiert. Dabei wird die Qualität in den definierten Bereichen gemessen und muss hierbei nicht
den höchst möglichen Qualitätsansprüchen genügen, sondern genau das geforderte Quali-
tätsmass erreichen. Qualitätskriterien sind Effizienz, Benutzbarkeit, Geschwindigkeit, Robust-
heit, Sicherheit, Funktionsabdeckung und Zuverlässigkeit. Diese Kriterien sind im Anforde-
rungskatalog, im Business Case oder im Projektauftrag definiert und werden im Prüfplan fest-
gehalten. Anhand des Prüfplans wissen alle Beteiligten, wann welcher Qualitätsaspekt wie
geprüft wird.
Mittels der Qualitätslenkung wird sichergestellt, dass die der Prüfplan eingehalten werden
kann und die Qualitätsanforderungen rechtzeitig erreicht werden. Sie besteht grösstenteils
aus konstruktiven Massnahmen (Methoden, Richtlinien, Checklisten, Standards), die dafür
sorgen, dass das Produkt zum richtigen Zeitpunkt bestimmte Eigenschaften aufweist. Dabei
kann zwischen technischen, organisatorischen und psychologischen Qualitätsmassnahmen
unterschieden werden.
Als dritter Bereich kommt die Qualitätsprüfung, welche zu dem im Prüfplan definierten Zeit-
punkt das Produkt nach klar definierten Kriterien prüft. Bei der Prüfung werden Abweichungen
vom Entwicklungsziel wie auch von Normen und Verfahren aufgezeigt. Eine weitere Möglich-
keit der Qualitätsprüfung ist die Mängel- und Fehleranalyse, welche auf einem Mängelkatalog
und einem Fehlerbericht basiert.
46
3.2.3.4. Teammanagement
Teammanagement in Projekten beinhaltet die sozialen Führungsaufga-

ben, welche von einem Projektleiter in einem Projekt wahrgenommen
werden müssen Jenny (2005).
Der Zyklus in einem Projekt beginnt bei der Teambildung während der Projektinstitution (vgl.
Kapitel 3.1.1 und 3.1.2), gefolgt von der Teamführung während des Projektes und der Team-
auflösung nach Beedigung des Auftrags.
Die Teambildung besteht aus den Prozessen Forming, Storming, Norming und Performing.
Während des „Formings“ werden Aufgaben und Kompetenzen der einzelnen Teammitglieder
definiert. Ebenso müssen sich die Mitglieder an Rahmenbedingungen halten, so dass sich die
teamspezifischen sozialen Normen bilden können. In der darauf folgendef „Storming“-Phase
beginnen die Team-Mitglieder, ein konkurrenzierendes Verhalten aufzuweisen, um sich im
Team zu etablieren. Die Aufgabe des Teamleiters besteht darin, die Konflikte, welche persön-
licher oder sachlicher Natur sein können, anhand des richtigen Führungsverhaltens zu lösen.
Während des „Normings“ schafft sich das Team durch Kommunikation und Konfliktlösung eine
gemeinsame Identität. Sind die Probleme gelöst und die sozialen Normen geschaffen, kann
das Team während des „Performings“ durch eine freundliche und zuvorkommende Stimmung
die Energie auf die anstehende Aufgabe ausrichten.
Die Teamführung ist Aufgabe des Teamleiters und lässt sich in die zwei unabhängigen Dimen-
sionen personenorientiert und aufgabenorientiert teilen. Im so entstehenden Verhaltensgitter
lassen sich fünf Führungsstile abbilden, wobei jede Achse mit einem Wert von 1 bis 9 versehen
ist und somit die fünf Führungsstile 1.1, 1.9, 9.1, 9.9 und 5.5 entstehen (für detailliertere Infor-
mationen siehe Jung (2006)). Meist ist der Führungsstil 5.5 und somit ein guter Kompromiss
zwischen Mitarbeiter- und Aufgabenorientierung anzustreben.
Ist das Projekt beendet, wird durch die Teamauflösung das Projektteam sukzessive abge-
baut, damit die Teammitglieder in neue Projekte wechseln können.
3.2.3.5. Konfigurationsmanagement
Unter Konfigurationsmanagement wird die Gesamtheit von Methoden,

Werkzeugen und Hilfsmitteln verstanden, welche die Entwicklung und
Pflege eines Produktes als eine Folge von kontrollierten Änderungen
und Ergänzungen an gesicherten Prozessergebnissen unterstützt (Jen-
ny, 2005).
47
Der wichtigste Bereich im Konfigurationsmanagement ist das Änderungsmanagement, mit

welchem Änderungen, Verbesserungen und Ergänzungen kontrolliert und rückverfolgt wer-
den. Hierbei werden Änderungsmeldungen bewertet und das Vorgehen festgelegt, denn durch
Änderungen entsteht meist Mehraufwand und zusätzliche Kosten. Eine ausführlich Dokumen-
tation wird hier benötigt, um die getätigten Änderungen nachzuweisen.
3.3. Projektmanagement nach Specker
Specker (2004) unterscheidet den Projekt- und den Projektmanagementprozess. Der Pro-
jektmanagementprozess, bestehend aus Projektplanung, Projektmanagementausführung und
Projektüberwachung (Controlling), übernimmt eine überlagerte Projektführungsfunktion, wäh-
rend dessen unter dem Projektprozess das geeignete Vorgehensmodell (Wasserfallmodell,
Spiralmodell, Prototyping, XP, vgl. 3.5.1) verstanden wird. Parellel zum Projektmanagement-
prozess listet Specker (2004) sieben Managementfunktionen, welche während allen Prozes-
sen in unterschiedlicher Ausprägung wahrgenommen werden müssen (siehe Abbildung 3.3,
S. 48).
Abbildung 3.3.: Projektmanagement-Prozesse mit Schwerpunkten nach Specker (2004)
48
Projektmanagementprozess
Projekte und Projektmanagement können als überlagertes System mit Teilbereichen aus dem
Systemumfeld und dem Projektumfeld aufgefasst werden. Dieses Projektsystem beinhaltet
Mitarbeiter, Aufgaben und Managementtools. Die Projektmanagementfunktionen begleiten al-
le Prozesse mit unterschiedlichen Schwerpunkten und sollten bei Projekten jeder Kategorie
verhältnismässig vertreten sein.
3.3.1. Projektmanagementfunktionen
Im Rahmen der Projektorganisation und des Teams sind zusätzlich generelle Führungsauf-
gaben wahrzunehmen (Führung, Motivation, Konfliktlösung). Viele Konflikte können bereits bei
der Intitialisierung des Projekts gesteuert werden.
Das Auftragsmanagement koordiniert die Übertragung und die Erledigung von Aufgaben so-
wie Verträge mit Kunden respektive Lieferanten und interne Projektvereinbarungen. Die inter-
nen Vereinbarungen beinhalten Verpflichtungen betreffend Umfang, Terminen und Ressour-
cen. Durch interne Contracts werden Mitarbeiter dazu gezwungen, ihre Arbeitskapazität mit
Fachvorgesetzten zu diskutieren und abzustimmen.
Im Kommunikationsmanagement werden Dokumente, Projektinformation und -marketing

geführt, um verbindlich gültige Dokumente abzulegen und alle Interessengruppen angemes-
sen zu informieren. Klare und regelmässige Information leistet einen grossen Beitrag zum
Projekterfolg.
Das Inhaltsmanagement beinhaltet Zielsetzungs-, Projektstruktur-, Änderungs- und Anforde-

rungsmanagement. Es stellt sicher, dass Zielsetzungen inhaltlich auch erreicht werden, defi-
niert im Strukturplan Teilprojekte und Arbeitspakete, stellt die Anforderungen und die Überprü-
fung des Funktionsumfangs sicher und verfolgt Änderungswünsche von Kunden und Lieferan-
ten.
Durch das Terminmanagement werden Termine, Meilensteine und Lieferdaten für Arbeitspa-
kete definiert. Es ist gleichzeitig stark mit dem Ressoucenmanagement und dem Inhaltsma-
nagement gekoppelt.
Das Ressourcenmanagement beinhaltet die Planung der Ressourcen für das Gesamtprojekt
wie auf für jedes einzelne Teilprojekt. In diesen Bereich fallen auch die Verwaltung der Kosten
und die Projektinfrastruktur.
Beim Risikomanagement werden projektspezifische Risiken erhoben. Der Risikokatalog listet

Eintretenswahrscheinlichkeit, Kostenfolge sowie Massnahmen und Zuständigkeiten.
49
Das Qualitätsmanagement unterteilt sich in Produkte- und Prozessqualität. Während die Pro-
duktequalität auf die Qualität des zu erstellenden Lieferobjekts fokussiert, werden bei der Pro-
zessqualität die Qualität der Projektabwichlung und des Projektmanagements überwacht.
Berichte werden während allen Prozessen im Projektmanagement erstellt und bilden die In-
formationsgrundlage für das gesamte Projekt.
3.3.2. Projektmanagementtätigkeit
Die foglenden Tabellen 3.3 bis 3.6 geben eine Ergebnisübersicht der Projektmanagementtä-
tigkeit während der vier Prozessphasen.
50
PM-Funktion Prozess: Projektplanung/-start

Projektorganisation Projektorganisation
Verantwortlichkeiten
Projektkontrollen
Zuständigkeismatrix
Auftragsmanagement Projektverträge
Interne Vereinbarungen
Aufgabenliste
Kommunikationsmanagement Dokumentations- & Dokumentenablageplan
Projektinformationsplan
Projektmarketingplan
Inhaltsmanagement Erfolgsfaktoren & Ziele
Projektstrukturplan
Ergebnisstrukturplan
Änderungsverfahren
Terminmanagement Vorgehensphasenplan
Termin- & Meilensteinplan
Projektablaufstrukturplan
Liefertermine (intern und extern)
Ressourcenmanagement Kostenplan
Zahlungsplan
Personal- & Sachmittelplan
Aktivitätenaufwandsplan
Projektinfrastrutkurplan
Risikomanagement Risikomanagementplan
Initialer Risikokatalog
Initiale Massnahmen
Qualitätsmanagement Qualitätssicherungsplan
QS-Modell
Prüfplan
Methoden & Standards
Berichte Projektplan (ink. Projektbeschreibung)
Projektübersicht
Tabelle 3.3.: Erbegnisübersicht Projektplanung nach Specker (2004)
51
PM-Funktion Prozess: Projektausführung

Projektorganisation Organisationsänderungen
Projektrollen zuweisen
Verantwortlichkeiten & Zuständigkeiten anpassen
Auftragsmanagement Arbeitsaufträge erteilen
Aufgabenliste führen
Verträge anpassen und laufende Überprüfung
Kommunikationsmanagement Dokumente verwalten
Informationen verteilen
Projektmarketingaktionen
Releases verwalten
Inhaltsmanagement Änderungen melden
Änderungsstatusliste führen
Fehler melden
Fehlerstatusliste führen
Terminmanagement Termine koordinieren
Meilensteine überwachen
Liefertermine überwachen
Terminplan nachführen
Ressourcenmanagement Personal führen
Aufwand überwachen
Zahlungen vornehmen
Kostenabrechnung
Risikomanagement Risikokatalog revidieren
Massnahmen umsetzen
Qualitätsmanagement Qualität sicherstellen
Prüfprozeduren definieren
Prüfspezifikationen ausführen
Berichte Aktueller Projektplan
Sitzungsprotokolle
Projektberichte/-reporting
Projektentscheide
Tabelle 3.4.: Erbegnisübersicht Projektausführung nach Specker (2004)
52
PM-Funktion Prozess: Projektcontrolling

Projektorganisation Status Projektorganisation:
Projektausschuss, Stellvertretung Projektleiter vor-
handen. . .
Auftragsmanagement Status etwaiger „Claims“
Status Vertragsänderungen
Grad der Umsetzung interner Vereinbarungen
Kommunikationsmanagement Status der Dokumentation, Vollzug der Kommunika-
tion
Status der Kommunikation von Projektzielen / -
visionen
Inhaltsmanagement Status Inhaltsfortschritt
Status von Änderungen
Terminmanagement Status Terminabweichung
Status der Meilensteine
Analyse Liefertermin
Ressourcenmanagement Status der Kostensituation (Stand IST-Kosten)
Risikomanagement Anzahl & Status der Risiken
Beurteilung der Massnahmen
Empfehlung der Massnahmen
Qualitätsmanagement Beurteilung Qualitätsstatus
Stand der Umsetzung von Qualitätsstandards in al-
len Projektfunktionsbereichen
Berichte Projektcontrollingbericht
Projektstatusbericht
Tabelle 3.5.: Erbegnisübersicht Projektcontrolling nach Specker (2004)
53
PM-Funktion Prozess: Phasen-, Projektende

Projektorganisation Anpassung / Auflösung der Projektorganisation
Überführung in laufende Organisation
Auftragsmanagement Vertragsbeedigung
Inkraftsetzen laufende Verträge
Planung Nachbesserungen
Kommunikationsmanagement Dokumentenarchivierung
Kommunikation der Projektzielerreichung
Inhaltsmanagement Feststellen Zielerreichung
Analyse der Abweichungen
Terminmanagement Begründung von etwaigen Abweichungen
Ressourcenmanagement Abschlussrechnung
Begründung von Kostenüberschreitungen
Risikomanagement Beurteilung der Risiken für laufenden Betrieb
Massnahmen
Qualitätsmanagement Qualitätsschlussreview
Lehren für andere Projekte
Berichte Projektphasenbericht
Projektabschlussbericht
Tabelle 3.6.: Erbegnisübersicht Phasen-/Projektende nach Specker (2004)
54
3.4. Agiles Projektmanagement: SCRUM

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more. (Agiles Manifest, 2001)
Scrum unterscheidet sich von den klassischen Projektmanagement-Methoden vorwiegend

durch die Verteilung der Zuständigkeiten, Kompetenzen und Verantwortung sowie die Selbst-
organisation und Autonomität des Teams. Auch Specker (2004), S. 409 hält fest, dass keine
einzelne Person in der Lage ist, alle Aspekte eines Projekts alleine zu berücksichtigen und die
Gesamtzusammenhänge eines komplexen Unternehmens zu verstehen. Scrum ist im Grunde
keine Projektmanagement-Methode, sondern enthält Methoden und ein Prozessmodell, um
Projekte zu steuern. Scrum ist ein Einstellung dazu, wie man mit Menschen und Mitarbei-
tern, Kunden und Managern umgeht. Scrum ist eine innere Haltung, die sich durch Disziplin
und Verantwortungsbewusstsein auszeichnen (Gloger, 2008) und folgende Prinzipien befolgt
(Agiles Manifest, 2001):
• Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
• Welcome changing requirements, even late in development. Agile processes harness

change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a deve-
lopment team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
55
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
Der Scrum-Prozess besteht aus sechs Rollen, sechs Meetings und neun Artefakten.
Abbildung 3.4.: Scrum-Prozess nach Gloger (2008)
3.4.1. Projektmanagement in Scrum
Scrum kennt die klassische Rolle des Projektleiters nicht, sondern teilt die Projektmanagemen-
taufgaben auf die Scrum-Rollen auf (siehe Tabelle 3.7 auf Seite 57). Ein traditionell gemangtes
Projekt wird langfristig auf der Ebene der Taktik gemanagt, ein agil gemanagtes Projekt auf
der Ebene der Strategie. Diese Grundunterscheidung führt dann zu vollkommen anderen Vor-
gehensweisen in der Planung eines Projektes - nämlich zu einer strategischen Planung und
damit überhaupt erst zu einer Strategie mit klaren Zielen (Gloger, 2008).
56
Aufgabenbereich Product Owner Team Scrum Master

Scope-Management Produktversion Sprints
Zeit-Mangement Releaseplan Sprint Backlog
Kosten-Management alle Aufgaben
Risiko-Management bewertet gibt Input
Qualitäts- Produktleistungs- qualitätssichernde richtige Anwen-
Management merkmale Massnahmen dung des Prozes-
ses
Lieferanten- mit Team mit Product Owner
Management
Personal- Produktivität und Bereitstellung der
Management kontinuerliche Mitarbeiter in Zu-
Prozessverbesse- sammenarbeit mit
rung dem Management
Tabelle 3.7.: Verteilung von Projektmanagementaufgaben in Scrum nach Pichler (2007)
3.4.2. SCRUM-Rollen
Die Rollen in Scrum entsprechen den Verantwortlichkeiten und sind keine Positionen innerhalb
des Unternehmens. Scrum kennt sechs Rollen, von welchen drei innerhalb des Systems an-
gesiedelt sind (siehe Abbildung 3.5, S. 57). Für vertiefte Informationen wird auf Gloger (2008),
Pichler (2007) und Mengelt (2008) verwiesen.
Abbildung 3.5.: Organisation und Scrum nach Gloger (2008)
57
3.4.2.1. Product Owner - der Visionär
Die Rolle des Product Owners (PO) repräsentiert die Endkundenbedürfnisse, vereint Produkt-
und Projektmanagementaufgaben in sich und ist zugleich fest in die Softwareentwicklung in-
tegriert. Der PO erfasst Kundenbedürnisse, beschreibt Anforderungen, managt und priorisiert
das Product Backlog, managt den Releaseplan und ist für den Erfolg des Projektes verantwort-
lich. Er schlägt somit die Brücke zwischen dem Endkunden und der Softwareentwicklung.
3.4.2.2. SCRUM Team - die Lieferanten
Scrum-Teams bestehen aus Mitarbeitern, welche über das relevante Wissen und die notwenid-
gen Fähigkeiten verfügen und produktiv zusammenarbeiten können. Sie weisen nach Pichler
(2007) folgende Eigenschaften auf:
Bevollmächtigt: Die Aufgaben werden nicht vom Management zugeteilt, sondern die Verant-
wortung liegt allein beim Team. Die Bevollmächtigung vereint Ursache und Wirkung: Das
Team wählt die umzusetzenden Anforderungen zu Beginn jeden Sprints aus und steht
zugleich in der Pflicht, die Auswahl zuverlässig in ein Produktinkrement umzusetzen 1 .
Autonom: Das Team muss seine Ziele ohne wesentliche externe Abhängigkeiten erreichen
können. Dies betrifft Lieferanten wie auch Arbeiten, welche von Mitarbeitern ausserhalb
des Teams erledigt werden sollten und ist ein Indiz dafür, dass das Team zu wenig
interdisziplinär besetzt ist.
Interdisziplinär: Die Interdisziplinarität garantiert, dass alle zu besetzenden Rollen im Team

vertreten sind, die Mitglieder über ein gemeinsames Softwareentwicklungswissen verfü-
gen und somit verschiedene Aufgaben im Team wahrnehmen können.
Selbstorganisiert: Ein selbstorganisiertes Team benötigt keinen Teamleiter, sondern ent-

scheidet selbst, wer welche Aufgaben übernimmt, um ein Sprint-Ziel zu erreichen. Die
Grundlagen dazu bilden das Sprint Backlog, der Burndown-Bericht und die Daily Scrum
Besprechungen.
Klein: Die optimale Führungsspanne liegt bei sieben Mitgliedern2 , wodurch ein Scrum Team
optimalerweise fünf bis neun Mitglieder umfasst.
Vollzeitteammitglieder: Um Engpässe höhere Prozesskosten zu vermeiden, sollten Mitar-

beiter nur einem Team angehören. Werden dennoch Teilzeitmitarbeiter eingesetzt, so
1
Pichler (2007), S. 14
2
http://www.brandeins.de, Ausgabe 07/2007 „Der goldene Schnitt“
58
sollten diese mindestens an den Sprint-Planungssitzungen und -Reviews anwesend

sein.
3.4.2.3. SCRUM Master - der Change Agent
Der Scrum-Master ist Coach und Change Agent und vollständig im Team integriert. Durch sei-
ne Arbeit fördert er neue Denk- und Verhaltensweisen und hilft, Scrum innerhalb des Unter-
nehmens zu etablieren. Er berät den Product Owner bei Erstellung des Backlogs, schützt das
Team vor externen Einflüssen und stellt die direkte Zusammenarbeit zwischen Product Owner
und Team sicher. Zudem ist es Aufgabe des Scrum-Masters, Hindernisse im Projekt wie auch
in der Infrastruktur zu beseitigen. Er verfügt über Einfluss, aber über keine Autorität. Um er-
folgreich zu sein und die eigene Rolle richtig ausführen zu können, sollte der Scrum-Master
über Kenntnisse in den Bereichen Moderation, Teambildungsprozess, kollaborative Entschei-
dungsfindung und Konfliktmanagement verfügen (Pichler, 2007).
3.4.2.4. Weitere Rollen im Scrum-Prozess
Zusätzlich zu den drei Rollen innerhalb des Systems existieren drei weitere Rollen ausserhalb
der Systemgrenze.
Der Kunde - der Finanzierer
Der Kunde kauft das Produkt oder hat es in Auftrag gegeben und kann innerhalb wie auch aus-
serhalb des Unternehmens angesiedelt sein. Seine Informationen gelangen über den Product
Owner in das System.
Der Anwender - der Nutzer
Der User des Produktes ist eine wesentliche Informationsquelle für das Scrum-Team. Er ist
es, der später die „Usable Software“ benutzen wird. Daher wird der Anwender in die Produkt-
Entwicklung vom Scrum-Team einbezogen. Anfangs beim Sprint Planning, wo er gemeinsam
mit dem Product Owner die Anforderungen definiert. Später wird er als Anwender mit dem
Team daran arbeiten, die Anwendung nutzbar zu machen.
Der Manager - die Bereitsteller
Das Management stellt die Ressourcen und die Richtlinien innerhalb einer Organisation bereit.
Es schafft den Rahmen, in dem sich das Team, der Product Owner und der Scrum-Master
bewegen und löst oft die vom Scrum-Master identifizierten Probleme.
59
3.4.3. Artefakte
Artefakte sind in Scrum Dokumente und visuelle Hilfsmittel, welche die Methodik des Projekt-
managements unterstützen. Dieser Abschnitt gibt keine vollständige Auflistung aller Artefakte
in Scrum. Für weitere Informationen wird auf Pichler (2007), Gloger (2008) und Mengelt (2008)
verwiesen.
3.4.3.1. Product Backlog
Auf dem Product Backlog werden alle Product Backlog Items priorisiert aufgeführt. Es ent-
hält alle funktionalen und nicht funktionalen Merkmale sowie Anforderungen an die Benut-
zerschnittstelle. Für jedes Scrum-Projekt gibt es ein Product Backlog. Aktivitäten fehlen im
Product Backlog, diese werden vom Team identifiziert und als Task im Sprint Backlog fest-
gehalten. Gloger (2008) und Pichler (2007) nennen zudem folgende Eigenschaften für das
Product Backlog:
keine Spezifikation: Das Beschreibungslevel des Product Backlogs ist zu grob, um es als
Spezifikation für ein Produkt einsetzen zu können. Es enthält keine programmierspe-
zifischen Ausdrücke sondern ist in einer gut verständlichen Sprache für den Kunden
geschrieben.
nie vollständig: Das Product Backlog wächst und verändert sich ständig, wobei bestehende
Merkmale verändert oder gelöscht und neue hinzukommen. Da die einzelnen Backlog
Items erst bei der Übertragung ins Sprint Backlog detaillierter beschrieben und verfeinert
werden, gibt es in Scrum kein klassisches Change-Request Verfahren. Um Änderungen
dennoch nachvollziehen zu können, ist eine Versionierung des Product Backlogs sinn-
voll. Change-Requests erscheinen als neue Stories im Product Backlog.
kollaboratives Werk: Meist arbeitet der Product Owner bei der Erstellung des Product Back-
logs mit dem Team und weiteren externen Personen zusammen. Seine alleinige Aufgabe
besteht darin, die Backlog Items in eine Reihenfolge zu bringen, die aus Anwendersicht
Sinn macht (Priorisierung).
unterschiedlicher Detaillierungsgrad: Höher priorisierte Einträge werden detaillierter be-

schrieben als niederpriore. Dies ist die Aufgabe des Product Owner, der vor einer Sprint-
Planung diese Einträge verfeinert und während der Sitzung die endgültigen Einträge mit
dem Team definiert.
geschätzt: Jedes Product Backlog Item enthält eine grobe Schätzung über den Aufwand des
Merkmals. Die Schätzung wird vom Team vorgenommen.
60
Product Backlogs werden häufig in tabellarischer Form oder als Karteikarte pro Product Back-
log Item (Story Cards) festgehalten.
Story Cards sind optimal für Backlogs auf Teamebene und erfüllen die Forderungen der 3C3 :
Cards: User Stories (Backlog Items) werden auf Karteikarten geschrieben (Cards). Diese
Karte wird mit gerade soviel Text beschrieben, um jeden daran erinnern zu können,
was die Story bedeutet. Priorität und Schätzung werden auf die Karte geschrieben. Es
werden auch mögliche Überlegungen zur Umsetzung oder Abhängigkeiten auf der Karte
notiert.
Conversation: Der Product Owner erklärt das Backlog Item dem Team. Wenn bereits Doku-
mente vorliegen, werden diese besprochen. Das Backlog Item wird sicherlich erläutert,
wenn es geschätzt werden soll, es wird aber auch noch einmal im Sprint Planning Mee-
ting erläutert. Wenn nötig auch noch einmal im Anschluss während des Sprints.
Confirmation: Meist auf der Rückseite der Karte wird die Bestätigung geschrieben, die an-
zeigt, was erfüllt sein muss, damit die Story erfüllt ist. Diese Bestätigung wird in Form
von User Acceptance Tests geschrieben.
3.4.3.2. Sprint Backlog
Während der Sprint-Planungssitzung wird ein realistisches Sprint Backlog festgelegt. Der Pro-
duct Owner stellt hierbei eine Vorauswahl seiner Product Backlog Items vor, das Team iden-
tifiziert die Aufgaben und wählt anhand der Story Points (Mass für den Aufwand eines Back-
log Items) die zu realisierenden Einträge innerhalb des nächsten Sprints („Selected Product
Backlog“). In einer zweiten Planungssitzung des Teams werden die Backlog Items detailliert
besprochen, wodurch das Sprint Backlog entsteht. Dieses kann elektronisch oder in Form von
Karten an einer Stellwand organisiert werden. Das Sprint Backlog wird täglich überarbeitet und
aktualisiert. Es hilft bei der Orientierung, wer was gerade macht und was noch getan werden
muss, um den Sprint erfolgreich abzuschliessen.
3.4.3.3. Burndown Chart
Burndown-Charts dienen im Scrum dem Reporting und zeigen den aktuellen Fortschritt eines
Sprints an, indem die erledigten Arbeiten beim visualisierten Graph abgezogen werden. Der
ideale Burndown entspricht einer linearen Linie bis zum Enddatum des Sprints. Durch das
täglich aktualisieren des Brundown-Charts kann eine aktuelle Trendlinie aufgezeigt werden.
3
nach Gloger (2008) und www.xprogramming.com/xpmag/expCardConversationConfirmation.htm
61
3.4.3.4. Impediment List
Das Impediment Backlog besteht aus einer Liste aller Blockaden, die einem Team aus dem
Weg geräumt werden müssen, damit es produktiver werden kann (Gloger, 2008). Handelt es
sich hierbei um externe Einflüsse, so ist es Aufgabe des Scrum-Masters, sich um diese Hin-
dernisse zu kümmern und wenn möglich innerhalb von 24 Stunden aus dem Weg zu räumen.
Die Hindernisse werden täglich im Daily Scrum identifiziert und aufgelistet. Werden program-
miertechnische Hindernisse bei der Retrospektive festgestellt, so wird festgelegt, welche im
nächsten Sprint beseitigt werden sollen.
3.4.4. Sprint
Der Sprint ist in „Scrum“ ein Zyklus von zwei bis vier Wochen, innerhalb welchem ein lauf-
fähiges Stück Software oder eine neue Funktionalität erstellt wird. Er startet mit dem „Sprint
Planning Meeting“ und endet mit der „Retrospektive“. Die Aufgaben innerhalb eines Sprints
werden vom Product Owner in Zusammenarbeit mit dem Team festgelegt, wobei das Team
den endgültigen Entscheid über die umgesetzten Backlog Items hat.
3.4.4.1. Planungssitzung 1
Im ersten Meeting des Sprints sind alle Beteiligten anwesend, auch Management und Anwen-
der. Ziel ist es, die Anzahl der Backlog Items zu bestimmen in das „Selected Product Backlog“
zu übernehmen, welche innerhalb des Sprints vom Team umgesetzt werden können.
3.4.4.2. Planungssitzung 2
Das Team verfeinert während des zweiten Meetings die Backlog Items und definiert die anste-
henden Arbeiten (Architektur, Interfaces, Tests, UI Design, Tasks, usw.). Daraus resultiert das
Sprint Backlog.
3.4.4.3. Daily Scrum
Jeden Tag treffen sich die Teammitglieder zur gleichen Zeit am selben Ort 15 Minuten lang
zu einem vom Scrum-Master moderierten Meeting. An einem Daily Scrum können Projekt-
beteiligten teilnehmen, z.B. Stakeholders, Analysten, Product Owner oder ein Vertreter aus
dem Management - allderings bleibt nur den „committed“ Mitgliedern das Recht vorbehalten
zu sprechen. Das macht den Daily Scrum zu einer idealen Basis, um Informationen und Status
auszutauschen. In diesem Meeting besprechen die Teammitglieder folgende Punkte:
62
- Was habe ich seit dem letzten Daily Scrum erreicht?

- Was will ich bis zum nächsten Daily Scrum erreichen?
- Welche Impediments (Hindernisse) sind mir dabei im Weg?
Treten Hindernisse auf, so ist der Scrum-Master dafür verantwortlich, diese innerhalb von 24
Stunden aus dem Weg zu räumen. Kann er dies nicht selbst (z.B. technische Probleme), muss
er sicherstellen, dass er jemanden findet, der das Problem lösen kann - meist innerhalb des
Teams (König, 2008).
3.4.4.4. Sprint Review
Am Ende des Sprints präsentiert das Team die erarbeiteten Funktionalitäten. Das Team zeigt
dabei nur die Funktionalitäten, die in einem Zustand sind, die es erlauben würden, diese Funk-
tionalitäten sofort produktiv einzusetzen. Nicht getestete oder instabile Funktionalitäten wer-
den nicht gezeigt und gelten als nicht geliefert (Gloger, 2008).
3.4.4.5. Sprint Retrospektive
Die Sprint Retrospektive ermöglicht das systematische Lernen des Teams. Hier wird analy-
siert, welche Arbeitsprozesse verbessert werden müssen, damit das Team effektiver arbeiten
kann. Dazu gehören auch zwischenmenschliche Unregelmässigkeiten und strukturelle Proble-
me. Die Resultate aus der Retrospektive werden im Impediment Backlog festgehalten und kön-
nen so als Verbesserungsvorschläge im Sprint Planning eingebracht werden (Gloger, 2008).
3.4.5. Fazit
Scrum fokussiert auf die Selbstorganisation des Teams, schnelle Entwicklungszyklen und so-
mit optimale Anpassungsfähigkeit an veränderte Umstände, mehr Kommunikation und mehr
Mitverantwortung, um die Effizienz bei der Programmierung zu steigern. Es definiert klare
Rollen, Verantwortung und Kompetenzen und regelt die Zusammenarbeit aller Beteiligten.
Nach einem Sprint wird ein auslieferbares Produktinkrement geliefert, welches zu Beginn des
Sprints im Sprint Backlog von Product Owner und Team definiert wurde. Scrum wird oftmals
im Zusammenhang mit agiler Softwareentwicklung eingesetzt, zum Beispiel mit Extreme Pro-
gramming (vgl. 3.5.1.4), ist grundsätzlich jedoch nicht an einen bestimmten Produktentwick-
lungsprozess gebunden. Ziele von „Scrum“ sind ein klarer Fokus auf Nutzenpotenziale, schnel-
le Reaktion auf Veränderung, phasenorientierte Lieferung der Funktionalität und ein iterativer
Entwicklungsansatz (Schopp, 2008).
63
König (2008) führt aus, dass „Scrum“ alle drei Dimensionen von Erfolg (persönlich, technisch,
unternehmerisch) fördert: „Ohne persöhnlichen Erfolg ist man schwer motivierbar. Ohne tech-
nischen Erfolg gleicht die Codebasis häufig einem Teller Spagetti und ohne unternehmeri-
schen Erfolg wird sich das Team vom Unternehmen abwenden und eine neue Herausforde-
rung suchen.“
3.5. MIO Ansatz
Abbildung 3.6.: Drei parallele Prozesse nach Kuhnt (2007)
Der Ansatz Mensch - Informatik - Organistaion fokussiert auf drei parallel laufende Prozes-
se, welche im Verlaufe eines Projektes abgewickelt werden. Der erste Prozess, das klassi-
sche Projektmanagement, managt die ökonomischen Prozessziele Leistung, Zeit und Kosten.
Während die systemische Projektführung die sozialen Erfolgsfaktoren fördert, unterstützt der
Produktentwicklungsprozess die im Projektauftrag definierten Lieferobjekte. Die Schwierigkeit
liegt hierbei auf den unterschiedlichen Lebenszyklen wie auch auf unterschiedlichen Theorien
der drei Prozesse (Kuhnt, 2007). Die Vereinigung dieser drei Prozesse in einem ganzheitlichen
64
3.5. MIO Ansatz
Projektabwicklungsmodell erlaubt es, unterschiedliche Erfolgsfaktoren zur überwachen. Ei-

ne Umfrage der verbandsübergreifenden Fachgruppe IT-Projektmanagement (GI/GPM) ergab
u.a. folgende Gründe für das Gelingen von IT-Projekten (Feldmüller u. a., 2004) und (Kuhnt,
2007):
• Vorliegen von Geschäftsmodell und Zustimmung der Führungskräfte
• Verfügbarkeit geeigneter Mitarbeiter in ausreichender Anzahl
• Nutzung von Techniken und Instrumenten des Projektmanagements
• Unterstürzung des Projektmanagements durch effektives Controlling
• Aktives Management der Veränderungen von Projektzielen und -anforderungen
• Aktives Betreiben von Stakeholder Management
• Schulung von Projektleiter und -mitarbeiter
• Anerkennung der Projektleistung durch Bonus, Gehaltserhöhung oder Beförderung
Sieht man sich diese Gründe genauer an, so stellt man fest, dass einige der Punkte nicht
direkt mit dem Projekt zusammenhangen, sondern sich auf das Umfeld und die Organisation
ausserhalb des Projektsystems beziehen.
3.5.1. Produktentwicklungsprozess
Ein Vorgehensmodell gliedert den Prozess der Projektabwicklung in verschiedene, struktu-

rierte Phasen, denen wiederum entsprechende Methoden und Techniken der Organisation
zugeordnet sind. Aufgabe eines Vorgehensmodells ist, die allgemein in einem Gestaltungs-
prozess auftretenden Aufgabenstellungen und Aktivitäten in ihrer logischen Ordnung darzu-
stellen. (Kuhnt, 2007)
Die Vorgehensmodelle entwickelten sich in den letzten 40 Jahren der Softwareentwicklung

aufgrund veränderter Umstände. Während die Anforderung an die Programmsysteme und die
Grösse der entwickelten Software und somit die Anzahl der involvierten Programmierer stetig
zunahm, verschlechterte sich die Zuverlässigkeit der Software. Für ein erfolgreiches Projekt
werden Kompetenzen in unterschiedlichen Bereichen benötigt. Vorwiegend die schnelle Än-
derung der Anforderung an geplante Software setzt eine hohe Kompetenz im Veränderungs-
management und im IT-Anwendungsfeld für den Projektleiter voraus. Nach Feldmüller u. a.
(2004) geben fast 80% der Projektleiter an, dass IT-Kompetenz nebst Projektmanagement-
Kompetenzen für ein erfolgreiches Projekt unerlässlich ist. Erstaunlicherweise halten fast 90%
65
der Befragten Kompetenzen im Veränderungsmanagement für wichtig, 50% davon sogar für
besonders wichtig. Daher erstaunt es nicht, dass der Produktentwicklungsprozess und das
Veränderungsmanagement innerhalb eines Projektes stark miteinander verknüpft sind und
sich die Vorgehensmodelle laufend verändern.
3.5.1.1. Wasserfallmodell
Abbildung 3.7.: Wasserfallmodell nach Specker (2004)
In den 70er Jahren wurde das Vorgehen bei der Entwicklung eines Softwareproduktes vom
altbekannten Ingenieurwesen übernommen. Inhaltlich und zeitlich werden Phasen abgege-
grenzt, welche streng sequentiell und vollständig umgesetzt werden. Diese wissenschaftliche
Herstellung von Basisanwendungen hat lange Entwicklungszeiten zur Folge, da alle Teilpro-
zesse sequentiell durchlaufen werden und erst ganz zum Schluss eine betriebsfähige Software
ensteht, dafür mit vollem Funktionsumfang. Ebenso gibt es nach der Spezifikation kein Verän-
derungsmanagement mehr. Das Projektmanagement begleitet den Entwicklungsprozess par-
allel. Durch die langen Prozesse der Problemanalyse und Spezifikation sollen Fehler bereits
sehr früh erkannt werden, können jedoch in späteren Phasen nur schwer wieder behoben
werden. Da das Wasserfallmodell keine Lieferung von Teilobjekten vorsieht, kann erst bei der
Einführung festgestellt werden, ob die Software auch wirklich den Bedürfnissen der Endan-
wender entspricht. Diese und weitere Gründe verlangten schon bald ein Überdenken des Vor-
gehensmodells.
66
3.5. MIO Ansatz
3.5.1.2. Spiralmodell
Abbildung 3.8.: Spiralmodell nach Specker (2004)
Als Optimierung des Wasserfallmodells folgte in den 80er Jahren das Spiralmodell, welche
durch das zyklisch-iterative Verfahren bereits von Anfang an alle Stakeholder beteiligt und die
Zusammenarbeit zwischen Anwendung und Entwicklung fördert. Im Gegensatz zum Wasser-
fallmodell, wo pro Phase nur eine Tätigkeit ausgeübt wird, enthält eine Phase im Spiralmodell
alle Tätigkeiten. Somit unterscheiden sich die zwei Vorgehensmodelle nicht in der Art und
dem Inhalt der Tätigkeiten, sondern lediglich in der Zurodnung der Tätigkeiten zu den Phasen.
Zudem liefern die kürzeren Zykluszeiten beim Spiralmodell schnellere Ergebnisse, welche im
Anwendungsfeld erprobt werden können. Da kein Gesamtkonzept besteht, können Änderun-
ge während der Entwicklung eingebracht und umgesetzt werden. Scheitert ein Projekt, so ist
zumindest ein Teilnutzen verfügbar. Für das Management ergibt sich durch die Zyklen jedoch
die Gefahr, dass Probleme und Hindernisse in spätere Zyklen verschoben werden und durch
die fehlende Gesamtspezifikation das Ziel verfehlt wird.
3.5.1.3. Prototyping
In den 90er Jahren begann das Zeitalter der evolutionären Softwareentwicklung. Man ging vom
sozio-technischen Ansatz zum Design von Werkzeugen für die Praxis über und forcierte das
67
klassische Projektmanagement. Primäres Ziel ist die Bestimmung und Validierung von Anfor-
derungen an ein Anwendungssystem (Ferstl u. Sinz, 2006). Mithilfe der Spezifikation mittels
Prototyping konnten kürzere Entwicklungszyklen und versionen-orientierte und evolutionäre
Ansätze verfolgt werden. Die entstandenen Softwarepakete können bereits von Anwendern
getestet und Änderungen und Erweiterungen in folgenden Releases implementiert werden.
Der evolutionäre Ansatz hat sich bis heute stark in der Softwareentwicklung verankert, da eine
optimale Anpassung an ein verändertes Umfeld möglich ist. Dennoch erschwert Prototyping
das Projektmanagement, da durch die schnelle Verfügbarkeit des Prototypen und seine Ände-
rungsfreundlichkeit die Plan- und Steuerbarkeit des Projekts erheblich erschwert wird (Alpar
u. a., 2005).
Man unterscheidet drei Arten von Prototyping:
Explorativ: Klärt sukzessiv die fachlichen Anforderungen durch wiederholte, schnelle Erzeu-
gung und Verwerfung von Prototypen in einer Testumgebung, welche nicht identisch mit
der vorgesehenen Entwicklungsumgebung sein muss. Exploratives Prototyping kann in
der Anforderungsanalyse bei unklaren Bereichen eingesetzt werden. Die Systemspezi-
fikation wird in Zusammenarbeit mit den Benutzern erarbeitet.
Experimentell: Weist die Realisierbarkeit eines Entwurfs vor dem Einstieg in die Implemen-
tierungsphase eines traditionellen Phasenmodells nach. Im Mittelpunkt steht nebst der
softwaretechnischen Realisierung auch die Kommunikation mit den Anwendern (Biet-
hahn u. a., 2004).
Evolutionär: Durch laufende Anpassung des Prototypen an geänderte Anforderungen in ei-

nem sich in Entwicklung befindenen Systems stellt der evolutionäre Prototyp kein Weg-
werfprodukt, sondern den Kern eines neuen Systems dar. Dieses Verfahren ist auch
unter dem Namen „Versioning“ (Vetter, 1998) oder „Rapid Prototyping“ (Biethahn u. a.,
2004) bekannt .
3.5.1.4. Extreme Programming
Extreme Programming (XP) ist ein agiler Softwareentwicklungsprozess für kleine Teams, wel-
che sich aus Kunden, Entwicklern und Management zusammensetzt. Der Prozess ermöglicht,
langlebige Software zu erstellen und während der Entwicklung auf vage und sich rasch än-
dernde Anforderungen zu reagieren (Westphal, 2001).
XP basiert auf den vier Werten Kommunikation (in Form persönlicher Gespräche mit dem
Kunden und Pair-Programming zwischen Programmierern), Einfachheit (die Motivation, die
einfachste Lösung zu finden), Feedback (als qualitätssichernde Komponente durch ständiges
Testen) und Mut (einfache Lösungen zu präsentieren und wieder von neuem zu beginnen, mit
68
3.5. MIO Ansatz
dem Kunden und Teammitgliederung ehrlich zu kommunizieren und Feedback anzunehmen)

(Beck, 2005), (Sörensen, 2007). Zudem benötigt es für XP Respekt und Interesse gegenüber
den Teammitgliedern und dem Projekt selbst.
XP kennt mehrere Hauptverfahrensbereiche, darunter folgende sechs Verfahren (Beck, 2005),
(Westphal, 2001):
Kurze Releasezyklen: Die Entwicklung erfolgt in Perioden von ein bis drei Wochen. Am Ende
jeder Iteration steht ein funktionsfähiges, getestetes System mit neuer, für den Kunden
wertvoller Funktionalität.
Einfaches Design: Komplexe Strukturen auflösen, sobald diese entdeckt werden. Das Sy-
stem soll zu jedem Zeitpunkt möglichst einfach strukturiert sein.
Refactoring: Das Design des Systems wird fortlaufend in kleinen, funktionserhaltenden Schrit-
ten verbessert. Finden zwei Programmierer Codeteile, die schwer verständlich sind oder
unnötig kompliziert erscheinen, verbessern und vereinfachen sie den Code. Sie tun dies
in disziplinierter Weise und führen nach jedem Schritt die Unit Tests aus, um keine be-
stehende Funktion zu zerstören.
Pair-Programming: Die Programmierer arbeiten stets zu zweit am Code und diskutieren

während der Entwicklung intensiv über Entwurfsalternativen. Sie wechseln sich minüt-
lich an der Tastatur ab und rotieren stündlich ihre Programmierpartner. Das Ergebnis ist
eine höhere Codequalität, grössere Produktivität und bessere Wissensverbreitung.
Gemeinsame Verantwortlichkeit: Der gesamte Code gehört dem Team. Jedes Paar soll je-
de Möglichkeit zur Codeverbesserung jederzeit wahrnehmen. Das ist kein Recht son-
dern eine Pflicht.
Fortlaufende Integration: Das System wird mehrmals täglich durch einen automatisierten
Build-Prozess neu gebaut. Der entwickelte Code wird in kleinen Inkrementen und spä-
testens am Ende des Tages in die Versionsverwaltung eingecheckt und ins bestehende
System integriert. Die Unit Tests müssen zur erfolgreichen Integration zu 100% laufen.
3.5.1.5. Fazit
Der Produktentwicklungsprozess besteht aus Vorgehensmodellen, welche sich den äusse-

ren Einflüssen, dem Projekt, der Organisation und den Veränderungen laufend anpassen
und weiterentwickeln. Wichtig bleibt, dass die Entwicklung vom passenden Projektmagement
69
unterstützt wird. Während das Wasserfall- und Spiralmodell durch klassisches Projektma-
nagement begleitet wird, empfehlen sich für Prototyping und Extreme Programming agile
Projektmagement-Methoden.
3.5.2. Managementprozess
Der Inhalt des Projektmanagements besteht aus Abwicklung, Planung und Überwachung des
Projekts, wobei der Prozess des Projektmanagement eine übergelagerte Funktion der Pro-
jektführung übernimmt (Kuhnt, 2007). Es begleitet das Projekt von Beginn bis Ende und ist
unabhängig vom gewählten Vorgehensmodell. Der Projektauftrag, welcher vor dem eigentlich
Start des Projekts statt findet, gehört ebenfalls bereits zum Management-Prozess. Die funktio-
nalen Managementprozesse dienen der Optimierung der Koordination der Aktivitäten der am
Projekt beteiligten Akteure. Als Grundlage dienen klassische Management-Modelle (vgl 3.2,
3.3 und Tabellen 3.3, 3.4, 3.5), welche zwischen Initialisierung und Abschluss die zyklischen
Phasen Planung, Ausführung und Controlling beinhalten.
Unter Planung wird die vorausschauende Festlegung von Vorgaben zur Projektdurchführung
verstanden. In dieser Phase wird die Grundlage für die effiziente Koordination der beteiligten
Akteure geschaffen. Zu den Planungsaufgaben gehören u.a. die Definition klarer Vorgaben zur
effizienten Durchführung des Projekts, die Festlegung der logischen und zeitlichen Organisa-
tion einzelner Aktivitäten, die Ermittlung von Vorgaben für Projektzeitaufwand und Projektko-
sten, die Vorbereitung der Projektmanagementausführungs- und Projektkontrollmassnahmen
sowie die Bereitstellung von Informationen zur Abstimmung mit anderen unternehmerischen
Aktivitäten (Kuhnt, 2007).
Zum Ausführungsprozess gehören alle Aktivitäten des Projektleiters, um die ökonomischen

Prozessziele Zeit, Kosten, Qualität und Leistung zu erreichen (vgl. auch 2.2.4.1) und das Pro-
jekt erfoglreich abzuschliessen.
Das Controlling soll Abweichungen zwischen IST- und SOLL Zustand überwachen (vgl. auch
3.2.2.4. Dabei setzt ein zielorientiertes Kontrollvorgehen einen vordefinierten Kontrollprozess
voraus, der bereits in der Initialisierungsphase aufgesetzt wird. Der Kontrollbereich beschränkt
sich jedoch nicht nur auf das Projektmanagement, sondern auf alle drei Prozesse, also auch
auf Führung und Produktentwicklung.
70
3.5. MIO Ansatz
Abbildung 3.9.: Lebensphasen eines Projektteams nach Brugger u. Soltermann (2004)
3.5.3. Führungsprozess
Der Führungsprozess besteht aus den Phasen Etablierung, Konstituierung, Durchührung und
Abschluss, welches den zentralen Lebensphasen eines Projektteams entspricht. In der Praxis
werden der ersten und letzten Phase meist zuwenig Beachtung geschenkt. Während sich
Jenny (2005) mit der Projektführung unter dem Begriff des Teammanagements (vgl 3.2.3.4)
befasst, behandelt Specker (2004) die personelle Führung nur ansatzweise im Bereich der
Projektorganisation. Beide Theorien vernachlässigen jedoch die Projektetablierung, welche
passiert, bevor sich die vorgesehenen Personen das erste Mal treffen, sowie den Abschluss
resp. die Auflösung des Teams nach Beendigung des Projekts.
Die Etablierung klärt, inwieweit die Arbeitsform im Team für die Aufgabe nütztlich ist und
wie das Team zusammengesetzt werden soll (Brugger u. Soltermann, 2004). Nachdem die
Rahmenbedingungen und die Erwartungen an das Projekt mit allen Stakeholdern aus ver-
schiedenen Perspektiven eruiert wurde, erarbeitet die Projektleitung ihre Vorstellung über die
Teamzusammensetzung, Rollen- und Aufgabenverteilung und Hierarchie. Diese Phase wird
bei Jenny (2005) in der Phase der Teambildung („Forming“) umgesetzt.
Der MIO-Ansatz geht bei der Etablierung nach den drei Phasen „Unfreezing“, „Moving“ und
„Freezing“. Beim „Unfreezing“ werden für die potentiellen Anspruchsgruppen ein gemeinsa-
mer Rahmen geschaffen. Dabei werden alle Stakeholder informiert und deren Interessen,
Einstellungen und Probleme erfasst. Beim „Moving“ wird im gemeinsamen Gestaltungspro-
zess das Veränderungspotenzial erfasst und die gewünschten Änderungen im Projektauftrag
aufgenommen. Beim „Freezing“ wird der Projektauftrag fixiert. In die Phase der Etablierung
gehört auch die Klärung der sozialen Erfolgsfaktoren (vgl. 2.2.5).
Die Konstituierung entspricht im weiteren Sinne den drei Formen des Teambildungsprozes-
ses „Storming“, „Norming“ und „Performing“, wie sie auch in der Theorie von Jenny (2005)
beschrieben werden. Der ideale Rahmen für die Konstituierung schafft ein Kick-Off-Meeting
resp. -Workshop zu Beginn des Projekts, welches die Voraussetzung für eine synergetische
Zusammenarbeit schafft (Kuhnt, 2007). In dieser Phase wird auch der Grundstein für die Kom-
munikation der Teammitglieder geschaffen (vgl. auch 2.1.2).
71
Aus systemischer Sicht ist die Aufgabe der Führung die Vermittlung zwischen den Ansprü-
chen an das Projektteam von aussen und der Arbeit des Projektteams (Brugger u. Soltermann,
2004). Dazu gehören zum Führungsprozess auch die Beobachtung der Gruppendynamik und
die Kommunikationsunterstütztung. Soziale und kommunikative Kompetenzen haben in der
Mitarbeiterführung eine hohen Stellenwert und beeinflussen die sozialen Erfolgsfaktoren Wis-
sen, Information und Zusammenarbeit.
Beim Abschluss werden Ergebnisse gefeiert und über die getane Arbeite reflektiert. Vor allem
in agilen Projektmanagmentmethoden wie Scrum wird dieser Phase eine grosse Wichtigkeit
zugestanden (vgl. 3.4.4.4, 3.4.4.5). Der Fokus liegt auf den Fehlern, die während einer Phase
oder eines Projekts entstanden, und die Lehre daraus, um eine Verbesserung und Optimierung
bei den nächsten Phasen und Projekten zu erlangen. Die Auflösung in Informatik-Projekten
ist nicht immer einfach, muss man doch den Abschluss des Projekts bestimmen und somit
den Übergang von Entwicklung zu Wartung definieren. Oftmals arbeiten Teammitglieder am
System weiter, obwohl das Projekt bereits als abgeschlossen gilt.
3.6. Prozessintegration
Der MIO-Ansatz selbst beschreibt keine Methoden für das Projektmanagement und die Füh-
rung, sondern basiert auf der Prozessdifferenzierung und darauf, dass die drei Prozesse Pro-
jektmanagement, Führung und Produktentwicklung parallel und in gegenseitiger Wechselwir-
kung ablaufen. Für ein erfolgreiches Projekt sind somit alle Prozesse zu begleiten, zu überwa-
chen und zu unterstützen.
Während die Produktentwicklung abhängig ist von der Komplexität der zu erstellenden Softwa-
re, dem Wissen und Interesse der Projektmitglieder und dem Typ des Projekts, laufen Manage-
ment und Führung ähnlich und in unterschiedlich ausgeprägter Form ab. Die folgenden beiden
Abschnitte geben Aufschluss darüber, in welcher Form die klassischen wie auch modernen
und agilen Managementmethoden auf die Prozesse der Führung und des Manaagements in
Anlehnung an den MIO-Ansatz abgebildet werden können.
72
3.6.1. Projektmanagement-Prozess
Während der Initialisierungsphase des Projektmanagements wird das Projekt oder die Projekt-
phase aufgesetzt. Er wird zum Projektstart initial ausgeführt und vor jeder neuen Projektphase
wiederholt. Die Artefakte werden hierbei um die Erkenntnisse der letzten Phase erweitert und
in einer neuen Version freigegeben.
Die Initialisierungsphase wird oft meist nur zum Projektstart durchgeführt und bei einer neuen
Phasenbeginn, vor allem bei knappen Ressourcen, zu wenig oder gar nicht beachtet. Bei den
klassischen Theorien zeichnet sich das Überspringen dieses Prozesses bei einer neuen Pha-
se durch nicht aktuelle Planwerte aus, welche möglicherweise ein Risiko aufzeigen könnten.
Bei Scrum werden die Arbeiten der Inititalisierungsphase bei jeder Planung wiederholt.
Initialisierung Artefakte Management

Jenny Business Case wichtige Eckdaten festlegen
Projektstart Anforderungskatalog Nutzen, Realisierbarkeit und Er-
Impuls Projektplan folgschancen beurteilen
Initialisierung Projektantrag benötigte Ressourcen schätzen
Infrastruktur aufbauen
Specker Projektstrukturplan Änderungsverfahren festlegen
Inhalt Ergebnisstrukturplan wichtige Eckdaten festlegen
Termin Projektverträge Nutzen, Realisierbarkeit und Er-
Ressourcen Aufgabenliste folgschancen beurteilen
Auftrag
Scrum Stories sammeln Vision
Product Backlog erstellen Product Backlog Items
Initiales Product Backlog
Tabelle 3.8.: Projektinitialisierung
73
Während der Planung werden Aufgaben betreffend Inhalte, Termine und Ressourcen logisch
und zeitlich koordiniert und Aufwände geschätzt. Durch die Planung soll Transparenz in den
Verlauf der Projektphase für alle gebracht werden.
Planung Artefakte Management

Jenny Abwicklungszielplan Klare Zieldefinition
Planung Projektstrukturplan detailierte Planung erstellen
Konzeption Ablaufplan Zieldefinition, Analyse von IST-
Ressourcenplan (Sachmittel) und SOLL-Zustand
Organisationsplan Lösungsentwürfe erarbeiten
Projektkostenplan Entscheid des Auftraggebers ein-
Terminplan holen
Budgetplan
Informationsplan
Specker Zielsetzungsplan Definition von Terminen, Meilen-
Inhalt Kostenplan steinen und Lieferdaten für Ar-
Termin Zahlungslplan beitspakete
Ressourcen Aktivitätenaufwandsplan Kosten und Aufwand schätzen
Auftrag
Scrum Planungsmeetings Selected Product Backlog
Aufwände schätzen Sprint Backlog
Releaseplanung
Tabelle 3.9.: Projektplanung
Mit der Ausführung wird das eigentliche Durchführen des Projektmanagements bezeichnet
und bezieht sich in den klassischen Methoden auf die Arbeiten des Projektleiters, bei Scrum
beschreibt es die hauptsächlich die Aufgaben des Scrum Masters und des Teams.
Ausführung Artefakte Management

Jenny Testbericht direkte und indirekte Steuerung
Projektsteuerung Statusbericht
Specker Zielsetzungsplan Verwaltung von Kosten und Pro-
Inhalt Projektstrukturplan jektinfrastruktur
Termin Terminplan Änderungen und Prozessziele
Ressourcen Sitzungsprotokolle überwachen
Auftrag Projektberichte
Scrum Daily Scrum Impediment List
Hindernisse beseitigen
Tabelle 3.10.: Projektausführung
74
Das Controlling begleitet das Projektmanagement kontinuierlich und wird mit verstärkten Fo-
kus am Ende jeder Phase durchgeführt. Es deckt Abweichungen zwischem aktuellen IST-
und dem SOLL-Zustand auf. Bei der Kontrolle wirkt nicht nur das Projektteam mit, sondern
auch Management und Auftraggeber können integriert werden, um fertige Lieferobjekte defini-
tiv abzunehmen. Kontrolle umfasst nebst den Lieferobjekten auch die Artefakte, zum Beispiel
die Terminplanung, Aufwand- und Kostenschätzung. Dafür stehen unterschiedliche Kontroll-
verfahren zur Verfügung, zum Beispiel Review, Audit oder Test (vlg. auch Jenny (2005)). Der
Kontrolle Artefakte Management

Jenny Prüfplan Kontrolle von Aufwand, Kosten
Projektkontrolle Arbeitsrapporte und Terminen
testbare Arbeitspakete regelmässige Prüfung von Lie-
ferobjekten und Dokumentation
durch höhere Instanzen und Auf-
traggeber
Specker Risikokatalog Änderungen und Prozessziele
Risiko Risikomanagementplan überwachen
Qualität Projektcontrollingbericht
Projektstatusbericht
Scrum tägliches Update der Fortschritte Burndown Chart
Tabelle 3.11.: Projektkontrolle
Abschluss findet wie die Initialisierung iterativ, nach jeder Phase sowie zum Projektende, statt.
Abschluss Artefakte Management

Jenny Projektabschlussbericht Sicherung des Wissens
Projektabschluss Phasenschlussbericht Gründe für Erfolg oder Nichterfolg
ausarbeiten
Specker Projektabschlussbericht Dokumentenarchivierung
Projektende Phasenschlussbericht Feststellen Zielerreichung
Abweichungen analysieren
Qualitätsschlussreview
Scrum Retrospektive -
Sprint Review
Tabelle 3.12.: Projektabschluss
75
3.6.2. Führungsprozess
Der Führungsprozess beschäftigt sich mit der sozialen Führung der Projektmitglieder. In der
Etablierung werden wichtige Teamrollen festgelegt und Erwartungen abgeklärt. Während der
Etablierung Artefakte Prozess

Jenny Ressourcenplan (personell) benötigte Ressourcen schätzen
Projektstart Aufbau der Projektorganisation
und Infrastruktur
Aufgaben, Verantworung und
Kompetenzen zuweisen
Teamauswahl treffen
Specker - Motivation der Projektmitarbeiter
Projektorganisation
Scrum Teamauswahl treffen -
Scrum Master und Product Ow-
ner bestimmen
Tabelle 3.13.: Projektetablierung
Konstituierung treffen sich die Teammitglieder das erste Mal physisch zum ersten Kick-Off
Meeting und dem eigentlichen Arbeitsstart der involvierten Projektmitglieder. Während der
Konstituierung treten auch die ersten Probleme auf, welche beiseitigt werden müssen, um das
Team als eine Einheit formen zu können.
Konstituierung Artefakte Prozess

Jenny - Forming, Storming, Norming und
Teammanagement Performing
(Teambildung)
Specker - Konfliktlösung
Scrum Vereinbarungen festlegen -

Ort & Zeit für Daily Scrum festle-
gen
Tabelle 3.14.: Projektkonstituierung
76
Während der eigentlichen Führung beobachtet der Projektleiter die Eigendynamik des Teams
und reagiert bereits auf schwache Signale, um eine möglichst gute Atmosphäre und Arbeit-
sumgebung für alle Beteiligten zu schaffen. Unter Führung fällt auch die Teamzusammenset-
zung, welche im schlimmsten Fall geändert werden muss. Beim Abschluss werden Zwischen-
Führung Artefakte Prozess

Jenny - Kontrolle der Arbeitsrapporte auf
Teammanagement Inhalt und Vollständigkeit
(Teamführung)
Specker Dokumentations- & Dokumenten- Personal führen
Kommunikation ablageplan regelmässige Projektinformation
Projektinformationsplan
Projektmarketingplan
Scrum Hindernisse beseitigen Impediment List
Tabelle 3.15.: Projektfuehrung
ergebnisse gefeiert und Phasen abgeschlossen. Dies ist auch der Zeitpunkt, über das Getane
zu reflektieren und Verbesserungen zu besprechen.
Abschluss/Lernen Artefakte Prozess

Jenny Leistungszeugnis für Projektmit- Projektteam abbauen
Teammanagement arbeiter
(Teamauflösung)
Specker - Auflösung der Projektorganisati-
Projektende on
Kommunikation der Projektzieler-
reichung
Lehren für andere Projekte
Scrum - -
Tabelle 3.16.: Projektabschluss/Lernen
77
3.7. Fazit
Das klassische Projektmanagemt kämpft mit diversen Problemen, welche sich aus veränder-
ten Anforderungen an komplexe und verteilte Projekte ergeben. Zudem werden die Bereiche
der Führung, Kommunikation und Selbstorganisation zu wenig unterstützt. Moderne Methoden
setzen genau bei diesen Punkten an (Chen u. a., 2002):
• Sie unterstützen die effektive und effiziente Kommunikation. Sie helfen, Missverständ-
nisse zu vermeiden und geben allen Projektmitgliedern einen umfassenden Überblick.
Hilfswerkzeuge in elektronischer Form unterstützen dabei die Kommunikation in alle
Richtungen und die Speicherung von Wissen.
• Sie managen nicht nur Input und Output, sondern auch Prozesse im Bereich der Füh-
rung und der Produktentwicklung.
• Sie unterbinden ein reaktives Management und fokussieren auf eine ganzheitliche und
stetige Planung, auch in Stresssituationen. Sie reduzieren dadurch den Aufwand für die
Überarbeitung von Lieferobjekten und die Fehlerbehandlung, welche durch eine unvoll-
ständige Planung entstehen.
Die Integration dieser modernen Methoden in eine moderne Projektmanagement-Plattform hat

zum Ziel, die Erfolgsquote von IT-Projekten zu erhöhen und dabei Informationen und Wissen
dauerhaft zu speichern und abrufbar zu machen. Zudem sollen die Projektleiter durch automa-
tisierte Prozesse entlastet und die Fehlerquote bei der Verteilung von Information verringert
werden.
78
4. Anforderung an eine moderne
PM-Plattform
Obwohl es oftmals versucht wird, ist es nicht möglich, eine allgemeingültige Lösung für das
richtige Projektmanagement zu erstellen. So unterschiedlich Projekte sind, so variieren auch
die Anforderungen an jedes einzelne Projekt und die Methoden und Hilfsmittel, welche für die
Projektführung und -durchführung angewendet werden sollten. Zudem wird die Eigendynamik
eines Projektes stark von der Motivation, den Interessen und Vorkenntnissen der Projektmit-
glieder beeinflusst.
Das Ziel einer guten Projektmanagement-Plattform liegt also nicht darin, die einzig richtige
Lösung abzubilden, sondern eine Vielzahl von Funktionen und dynamische Prozesse bereit-
zustellen, um den meisten Anforderungen gerecht zu werden. Bei der Initialisierung und der
ersten Planung und Etablierung des Projektes können daraufhin die benötigten Werkzeuge
eingerichtet und verbreitet werden.
Die spezifischen funktionalen Anforderungen an die Plattform lassen sich in drei Bereiche
unterteilen:
- Kommunikation
- Projektmanagement (klassisch)
- Informations- und Datenmanagement
Für jeden Bereich wird eine empfohlene Mindestanforderung an die Plattform gestellt.
Nebst den funktionalen Anforderungen kommen Randbedingungen hinzu, welche eine Platt-
form erfüllen muss, um richtig eingesetzt werden zu können. Diese können von Organisation
zu Organisation aufgrund der firmeninternen Richtlinien stark variieren. Zu Beginn dieses Ka-
pitels werden mögliche Randbedingungen für Klein- und Mittelunternehmen aufgelistet und
begründet.
79
4. Anforderung an eine moderne PM-Plattform
4.1. Randbedingungen
Klein- und Mittelunternehmen werden durch ihre Grösse, der Anzahl Mitarbeiter und des Jah-
resumsatzes klassifiziert. Typische Projekte in einem KMU sind im mittleren Bereich der Wich-
tigkeit, B bis C angesiedelt. Nur wenige Projekte mit hoher Komplexität und hohem Risiko
können von einem Kleinunternehmen gleichzeitig durchgeführt werden, um einem Klumpen-
risiko zu entgehen. Nach Applegate fallen sie in die Kategorie der strategischen, high poten-
tial oder kritisch operativen Projekte. Unterstützende Projekte werden erst mit zunehmender
Grösse eines Unternehmens wichtig. Untersucht man die Projekttypen, so werden meist Auf-
tragsprojekte durchgeführt, in welchen im Auftrag eines externen Kunden ein Softwareprodukt
hergestellt wird.
In Anbetracht dieser Projekttypen und der Aufgabenstellung stellen sich an das Grundmodul
einer modernen Plattform die in diesem Abschnitt gelisteten Randbedingungen.
4.1.1. Open Source
Open Source bedeutet unter anderem, dass der Quellcode einer Software frei zur Verfügung
steht. Ebenso sind in einer Open Source-Lizenz auch die Vermarktung und Verbreitung gere-
gelt. Die häufigste Lizenz ist die „GNU GPL“1 (GNU General Public Licence). Sie legt den kom-
pletten Quellcode offen und verlangt, dass adaptierte Versionen wiederum unter dieser Lizenz
veröffentlicht werden müssen. Es gibt daher keine kommerzielle Verwertung dieser Software.
Die schwächste aller Open Source-Lizenzen ist die „BSD“2 -Lizenz (Berkeley Software Distri-
bution). Sie macht keinerlei Vorschriften darüber, wie modifizierte Software weiterverwendet
werden kann. Sie kann somit kommerziell vertrieben werden und schreibt keine Offenlegung
des modifizierten Quellcodes vor.
Die wichtigsten Vorteile für ein KMU sind folgende (Spath u. a., 2007):
Wirtschaftlichkeit: Keine Kosten bei der Beschaffung sowie keine Folgekosten, zum Beispiel
für Updates. Durch den offenen Quellcode erhält man zusätzlich auch das Know-How
über die Entwicklung.
Anpassbarkeit: Anpassung an individuelle Bedürfnisse. Auch die Integration in bestehende

Software oder Designanpassungen sind möglich.
1
http://www.gnu.org/copyleft/gpl.html
2
http://www.opensource.org/licenses/bsd-license.php
80
4.1. Randbedingungen
Offener Entwicklungskreis: Weiterentwicklung durch eine grosse Community. Somit erhält

man Erweiterungen, welche eine Vielzahl von Anwendungsproblemen lösen. Im Gegen-
satz zu proprietären Lösungen ist man nicht auf Weiterentwicklungen des Herstellers
angewiesen.
Unabhängigkeit: Keine Verpflichtung gegenüber dem Hersteller. Es bestehen keine länge-

ren Vertragsbedingungen, welche möglicherweise den Umstieg auf eine andere Lösung
behindern.
Dem Gegenüber stehen natürlich auch einige Nachteile.

Die Community, welche eine Open Source-Produkt entwickelt, gibt keine Garantie und keinen
Support für das Produkt. Handelt es sich jedoch um ein verbreitetes Produkt, so sind Lösungen
zu Problemen und Fehlern meist durch die Community oder andere Nutzer schnell behoben.
Ebenso findet man auf Foren im Internet breite Unterstützung. Die Weiterentwicklung bleibt
dennoch ungewiss.
Der Schulungsaufwand ist oftmals hoch, da nur wenig oder unvollständige Literatur von den
Core-Entwicklern zur Verfügung gestellt wird. Auch dieser Faktor ist heutzutage immer weniger
gravierend, da für beliebte Open Source-Produkte auch eine Vielzahl an Literatur, oft kostenlos
und meist von Anwendern selbst geschrieben, verfügbar ist.
4.1.2. Erweiterbar
Erweiterbarkeit ist keine logische Implikation eines Open Source-Produktes. Zwar ist der Quell-
code offen und es bestehen somit offene Schnittstellen respektive diese können programmiert
werden, dennoch ist die Erweiterbarkeit von der Architektur des Produktes abhängig. Optimal
ist einer modulartiger Aufbau der Basisversion. Das Kernsystem soll eine allgemeine Basis für
die darauf aufbauenden Produkte bereitstellen.
Aufbauend auf der Technologie des Grundystems sollen zudem bereits frei verfügbare Produk-
te auf dem Markt sein, die für ein Projektmanagementsystem verwendet werden können. Für
ein KMU ist es nicht sinnvoll, mit dem Einrichten eines solchen Systems eine ganze Abteilung
über Monate hinweg zu beschäftigen. Wird die Erweiterung und Anpassung zu arbeitsintensiv,
läuft man Gefahr, diese aufgrund fehlender Zeit und Ressourcen nicht durchführen zu können.
Die Verwendung eines Systems, welches sich nicht optimal in den Arbeitsprozess integrieren
lässt, bringt keine Vorteile und ist in einem Projekt nicht sinnvoll.
81
4.1.3. Vernetzt
Für eine flexible Zusammenarbeit, auch über Unternehmensgrenzen hinweg, eignet sich eine
vernetzte Software. Die einfachste Möglichkeit ist eine webbasierte Applikation, auf welche
von überall her zugegriffen werden kann. Eine weitere Möglichkeit ist eine Synchronisations-
Software, welche die Daten bei einer bestehenden Internetverbindung abgleicht. Der Unter-
schied besteht darin, wo die Daten liegen und wann darauf zugegriffen werden kann.
Auf Daten einer webbasierten Applikation kann nur bei bestehender Internetverbindung zuge-
griffen werden. Die Daten werden innerhalb der Applikation, meist in einer Datenbank, gespei-
chert. Besteht keine aktive Internetverbindung, so gibt es keine Möglichkeit, auf Informatio-
nen zuzugreifen. Einen Schritt weiter gehen sogenannte verteilte Applikationen, welche eine
„Working Copy“ der gesamten Infrastruktur lokal speichern. Bei bestehender Internetverbin-
dung werden die lokalen Daten mit einem Repository oder den Working Copies der übrigen
Benutzer abgeglichen und die lokalen Informationen aktualisiert. Dieses Vorgehen ist oft bei
der Produktentwicklung anzutreffen, um geschriebenen Code erst dann allen zur Verfügung zu
stellen, wenn dieser abnahmebereit ist. Für das Projektmanagement sind beide Infrastrukturen
geeignet, im Zusammenhang mit Open Source-Produkten trifft man die webbasierte Version
öfters an.
4.1.4. Mehrsprachig
Obwohl sich in der Informatik die Sprach Englisch durchgesetzt hat, soll die Plattform in Hin-
blick auf die verteilte Benutzung eine optimale Unterstützung für Mehrsprachigkeit bereitstel-
len, so dass jeder Benutzer die angezeigte Sprache selbst wählen kann. Vorwiegend in der
Zusammenarbeit mit externen Kunden (zum Beispiel Änderungsmanagement), soll dieser die
freie Wahl haben, gewisse Elemente der Seite in seiner eigenen Sprache zu bearbeiten.
Die Mehrsprachigkeit macht in einigen Bereichen keinen Sinn, zum Beispiel im Auftragsmana-
gement. Für eine gute Zusammenarbeit wird bereits in der Initialisierungs- und Etablierungs-
phase eine gemeinsame Sprache festgelegt. Werden wichtige Elemente auf einer Plattform
übersetzt, so ist diese Grundlage nicht mehr gegeben. Diese sollen somit nur in einer Spra-
che zur Verfügung stehen. Als Beispiel seien hier Begriffe aus der Produktentwicklung (Story,
Task) und dem Projektmanagement (Artefakte) genannt.
82
4.2. Kommunikation und Zusammenarbeit

Bei der Kommunikation gehts zum einen um die Kommunikation zwischen den Teammitglie-
dern sowie auch um die Kommunikation zwischen verschiedenen Stakeholdern. Dabei kann
eine Kommunikation einseitig (nur in eine Richtung) oder zweiseitig (in beide Richtungen)
sein oder als Netzwerkkommunikation alle Stakeholder beteiligen (Wegmann u. Winklbauer,
2006). Zudem läuft eine Kommunikation synchron (Chat) oder asynchron (E-Mail, Forum) ab.
Wir beschränken uns hier auf die nach dem Träger definierten mediale Kommunikation, also
diejenige, welche über kommunikationsorientierte Medien abgewickelt wird.
Kommunikation bestimmt zu einen grossen Anteil auch die Art der Zusammenarbeit der be-
teiligten Projektmitglieder. Der Austausch von Informationen und Wissen und die Zusammen-
arbeit gilt als wichtiger sozialer Erfolgsfaktor in einem Projekt und muss bei der Verwendung
einer Projektmanagementplattform in geeigneter Form unterstützt werden.
4.2.1. E-Mail
Für die E-Mail-Kommunikation werden meist Standalone-Applikationen wie Microsoft Offi-

ce/Exchange, IBM Lotus Notes oder der frei verfügbare Mozilla Thunderbird verwendet. Dies
bringt den Vorteil, dass E-Mails strukturiert in Ordnern abgelegt, durchsucht und archiviert
werden können. Auf einer Projektmanagement-Plattform steht jedoch nicht der Empfang, son-
dern der Versand von E-Mails im Vordergrund.
Anforderungen: es soll möglich sein
• eine E-Mail an eine beliebige Mail-Adresse zu versenden
• eine E-Mail an ein oder mehrere Mitglieder des Projektes oder Gruppen zu versenden
• der E-Mail Medien anzuhängen (Dokumente, Bilder) resp. den Link auf ein Medium ver-
senden3
4.2.2. Kontaktmanagement
Alle Projektmitglieder erhalten über einen Benutzernamen und ein Passwort Zugang zur Platt-
form, wodurch Zugriffsberechtigungen geregelt werden. Eine vollständige Liste aller Benutzer
kann somit auch als Kontaktverwaltung ausgelegt werden und als Grundlage für alle Kontakt-
informationen dienen. Des weiteren sind in einem Projekt Personen beteiligt, welche keinen
3
Aufgrund der Redundanz ist es sinnvoller, Medien selbst nicht zu versenden, sondern nur darauf zu verlinken
83
Zugriff auf die Plattform benötigen und daher nicht zwingend in über die Benutzerverwaltung
organisiert sein müssen. Für diese Fälle ist eine vom Grundsystem unabhängige Kontaktver-
altung sinnvoll
Anforderung: es soll möglich sein
• Kontaktinformationen zu jedem Benutzer zu hinterlegen: E-Mail, Telefon, Skype, . . .
• die Eingabefelder für Informationen beliebig zu erweitern
• den Zugriff auf die Kontaktinformationen zu beschränken
• nach Benutzern anhand von Stichwörtern zu suchen
• Kontakte zu strukturieren, um die Organisation abzubilden
• Kontakt ohne Benutzerberechtigungen abzulegen (evtl. in einem eigenen Kontext)
4.2.3. Bookmarks/Portal
Ein Portal bietet die Möglichkeit, eine individualisierte Einstiegsseite der Plattform zu defi-
nieren. Darauf können Bookmarks (Schnellzugriffe) abgelegt, Aufgaben angezeigt und News
publiziert werden.
• eine eigene Darstellung der Einstiegsseite zu definieren
• Links zu wichtigen Dateien, Ordnern oder Kontaktdaten zu hinterlegen
• eigene Inhalte in einem geschützten Ordner abzulegen
• dynamische Anzeigen von Events (Meetings, Abggabetermine, Kalendereinträge, . . . )

anzeigen zu lassen
4.2.4. Forum
Das Forum ist die beste Möglichkeit zur Unterstützung einer zeitversetzten Diskussion, an
welcher sich alle berechtigten Teammitglieder beteiligen können.
• neue Themenbereiche und Themen zu eröffnen
• den Zugriff personen- oder gruppenbezogen auf einzelne Bereiche zu beschränken
84
• eine automatische E-Mail-Benachrichtigung einzurichten und dadurch den Eigentümer

eines Themas bei Antworten automatisch zu benachrichtigen
• Moderatoren für einzelne Bereiche zu ernennen, welche Beiträge editieren und löschen
sowie Themen schliessen können
4.2.5. Mailinglisten
Mailinglisten fassen die E-Mail-Adressen mehrerer Personen zusammen und ermöglich so das
schnelle und einfache Versenden an mehrere Empfänger. Die Kennzeichnung einer Mailing-
liste wird durch eine Adresse im normalen E-Mail-Format repräsentiert. Bei der Antwort an
diese Adresse wird der Verlauf gespeichert und kann danach baumartig dargestellt werden.
Die Kommunikation läuft im Gegensatz zu einem Newsletter bei einer Mailingliste bidirektional
ab.
• eine Mailingliste einzurichten und somit verfügbar zu machen
• eine Mailingliste abzurufen und darzustellen
4.2.6. Instant Messaging
Mit einer Messaging-Funktion können zwei oder mehr Nutzer in Echtzeit schriftlich miteinan-
der kommunizieren. Das Chatten ist ein beliebtes und verbreitetes Kommunikationshilfsmittel
und bietet oftmals zur schriftlichen Kommunikation auch Sprach- und Videoübertragung und
die Möglichkeit des Datenaustauschs. Im Gegensatz zum Forum müssen die Benutzer beim
Chatten gleichzeitig online sein.
• dass mehrere Benutzer gleichzeit miteinander chatten können
• den Verlauf einer älteren Diskussion nachzuverfolgen (Archivierung)
• Chat-Nachrichten auch im Offline-Betrieb an ein Mitglied zu versenden, welches darüber

informiert wird, sobald es sich einloggt
• bestehende Chat-Clients (z.B. Skype) zu integrieren, resp. den Status eines anderen
Mitglieds zu sehen
85
4.2.7. Nachrichtenboard
Ein Nachrichtenboard auf einer Plattform entspricht einer Pinwand oder einem Whiteboard,
auf welchem Nachrichten hinterlegt werden können, die für alle Mitglieder wichtig sind. Da
es sich hierbei im eine einseitige Kommunikationsart handelt, entlastet das Nachrichtenboard
den meist eh bereits hohen Mailverkehr.
• dass alle Benutzer Nachrichten erfassen können
• Nachrichten einem bestimmten Projekt zuzuweisen oder als global gültig zu definieren
• das Anzeigeverhalten personen- oder gruppenspezifisch einzuschränken
4.2.8. Umfragen
Umfragen dienen zur quantitativen Erhebung von Fragestellungen.
• Umfragen einem Projekt zuzuweisen
• die Anzeige einer Umfrage personen- oder gruppenspezifisch sowie zeitlich einzuschrän-
ken
• das Resultat graphisch darzustellen
4.3. Informations- und Datenmanagement

Ein wichtiger Faktor in einem Projekt ist die Information. Moderne Projektmanagement-Methoden
setzen dabei auf absolute Transparenz. Es geht darum informiert zu sein, wo das Projekt steht,
woran die anderen Mitarbeiter zur Zeit arbeiten und wie das weitere Vorgehen in naher Zukunft
ist. Dabei ist Information stark mit Kommunikation und Wissen verknüpft.
Für eine Projektmanagement-Plattform ist es daher unerlässlich, ein gutes Dokukmentema-

nagementsystem bereitzustellen, welches nicht nur die strukturierte Ablage von Dokumenten,
sondern auch die Nachverfolgung und Archivierung unterstützt. Zudem wird eine Vielzahl von
Information als Inhalt bereitgestellt, welche direkt im System abgelegt wird. Hierbei ist eine
Versionierung zur Nachverfolgung sehr nützlich.
86
4.3.1. Dokumentemanagement
Als Dokumentemanagement wird jegliches Handling von Artefakten verstanden. Sie ermögli-
chen nebst dem Speichern und Bearbeiten von Dokumenten auch die Verwaltung von Zugriffs-
berechtigungen. Je nach Format können die Dokumente direkt auf der Plattform bearbeitet
werden, meist jedoch ist dafür ein externes Programm nötig.
• Dokumente beliebigen Formats zu speichern und zu veröffentlichen
• durch einen eindeutigen Link auf ein Dokument zuzugreifen
• mehrere Versionen eines Dokuments zu veröffentlichen
• Metadaten und Beschreibungen hinzuzufügen
• den Zugriff auf die Dokumente zu beschränken
4.3.2. Versionierung
Durch die Versionierung von Informationen können Änderungen nachverfolgt und wieder rück-
gängig gemacht werden. Eine Versionshistory sollte automatisch erstellt werden und die Mög-
lichkeit bereitstellen, eine neuere Version zu kommentieren und somit die Änderungen nach-
vollziehbarer zu machen.
4.3.3. Strukturierung
Für die strukurierte Ablage von Dokumenten soll die Möglichkeit zur Erzeugung einer Ordner-
struktur vorhanden sein. In einem weiteren Schritt ist es denkbar, die Ordnerstruktur anhand
der Klassifizierung eines Projektes automatisch zu erzeugen (vgl. Tabelle 3.2).
4.3.4. Wissenserhaltung und Wissensfindung
Wissen ist in der heutigen Informationstechnologie ein wichtiges Gut. Mit jedem Mitarbeiter-
wechsel, mit jedem Projektabschluss und an jeder System- und Phasengrenze geht Wissen
verloren, wenn es nicht in geeigneter Form festgehalten wird. Während die Sammlung des
Wissens bei jedem drohenden Verlust in Aktion treten soll, ist das Wiederauffinden der zweite
Faktor. Schon mehrmals habe ich es erlebt, dass Wissen mithilfe von Spam-ähnlichen Mails
87
an alle Mitarbeiter eines Unternehmens versendet wurden mit der Hoffnung, jemanden zu fin-
den, der vielleicht in einem bestimmten Gebiet bereits Erfahrungen sammeln konnte. Daraus
ergeben sich zwei Aspekte. Zum einen soll es möglich sein, mithilfe einer Wissensdatenbank
Informationen zu finden, zum anderen sollen auch Personen, welche über ein bestimmtes
Wissen verfügen, ausfindig gemacht werden können. Letzteres kann über ein Kontaktmana-
gementsystem erfolgen, in welchem Mitarbeiter ihr Erfahrungsgebiete eintragen können. Für
Informationen selbst eignet sich ein Wiki.
Als Wiki wird ein interaktives Nachschlagewerk bezeichnet, in welchem jedes Projektmitglied
neue Seiten erfassen und somit Informationen zur Verfügung stellen kann. Alle Seiten werden
als Hypertext-Dokumente abgelegt und untereinander verlinkt.
• Artikel zu erstellen, editieren, veröffentlichen, löschen
• Medien in die Artikel zu integrieren (Bilder, Videos, Dokumente beliebigen Formats) und
Verlinkungen zu erstellen
• den Zugriff personen- oder gruppenbezogen zu beschränken
4.4. Projektmanagement
Im Bereich des Projektmanagements soll die Plattform das Management der ökonomischen
Projektziele Leistung, Kosten und Termine sowie Inhalte, Ressoucen und Änderungen über-
wachen sowie die Prozessabläufe begleiten. Dabei muss die Plattform flexibel genug sein, um
nicht nur eine Managementtheorie zu unterstützen, sondern klassische wie auch agile Metho-
den bereitstellen können. Das System greift dabei auf die Funktionalitäten der Kommunikation
und des Informations- und Datenmanagements zu. Der grosse Vorteil eines Systems ist die
automatische Erkennung definierter kritischer Zusammenhänge und Abhängigkeiten.
Ein wichtiger Bereich im Projektmanagement sind die Prozessabläufe, die sogenannten Work-
flows. Sie unterstützen den Ablauf in einem Projekt und garantieren einen Mindeststandard,
der eingehalten werden muss. Zudem vereinfachen sie das Handling und erlauben es, in der
Projektleitung Zeit für die Erledigung wiederkehrender Aufgaben einzusparen.
Während die firmenspezifischen Regeln meist über längere Zeit gleich bleiben, verändern sich
die projektspezifischen Abläufe oftmals bereits innerhalb eines Projektes. Die Änderungen rüh-
ren von inneren wie auch äusseren Einflüssen her. Jeder Projektleiter, jedes Teammitglied und
88
jeder Kunde hat andere Vorlieben und für die Benutzung einer Projektmanagement-Plattform
mit vordefinierten Abläufen sensibilisiert werden. Ich selber habe bereits die Erfahrung ge-
macht, dass Kunden die Unterstützung einer Plattform nicht schätzen und lieber nur mit E-
Mails arbeiten möchten. Somit ist es grundlegend, dass die Plattform an verschiedene Bedürf-
nisse angepasst werden kann, benutzerfreundlich ist und einen entscheideneden Mehrwert
liefern soll. Teammitgliedern, welche sich nicht an die vorgegebene Managementmethode hal-
ten möchten, sind oftmals besser aus dem Team auszuschliessen, sofern keine Besserung in
Sicht ist (Beck, 2005).
4.4.1. Termine
Ein Kalender dient dazu, projektbezogene Termine festzuhalten und zu verbreiten. Nebst Mee-
tings können auch weitere Termine wie Releases und Meilensteintermine integriert werden.
• Termine personen- oder gruppenspezifisch einzuschränken
• Termine einem Projekt zuzuordnen
• automatische Reminder für einen Termin einzurichten
• Termine zu exportieren, um diese in einem persönlichen Kalender automatisch eintragen

zu lassen
4.4.2. Management von Input und Output
Im Bereich des Projektmanagement lege ich den Fokus auf den Management- und den Ent-
wicklungsprozess. Die elektronisch unterstützbaren Aspekte der Führung werden subsumiert,
da in der Managementtheorie und der Kommunikation bereits ein Grossteil der Führung fest-
gelegt wird.
Betrachten wir die klassischen Managementmethoden nach Jenny (vgl. 3.2) und Specker (vgl.
3.3), so fällt auf, dass diese Methoden durch eine Vielzahl von Meetings und Dokumenten be-
stimmt wird, welche in einer festgelegten Reihenfolge oder bei bestimmten Ereignissen erstellt
werden. Wo reine Informationsinhalte erstellt werden, z.B. Business Case, und Projektantrag,
ist eine elektronische Unterstützung nur für die Verteilung der Information sinnvoll, jedoch
nicht für deren Erstellung. Für jedes einzelne Dokument ist demnach zu entscheiden, ob es
als Content auf der Plattform oder mit einem externen Programm erstellt wird und danach im
Dokumentesystem abgelegt wird. Wichtige Entscheidungshilfen sind folgende:
89
• Ist eine verbindliche Vorlage vorhanden (z.B. Excel- oder Word-Template), welche auf-
grund firmeninterner Richtlinien verwendet werden sollte?
• Arbeitet hauptsächlich nur eine Person an einem Dokument?
• Soll ein Dokument auch im Offline-Betrieb vorhanden sein?
• Handelt es sich beim Inhalt des Dokuments hauptsächlich um statische Informationen

oder solche mit Vertragscharakter?
• ...
Je mehr dieser Fragen mit „Ja“ beantwortet werden, desto eher sollte ein Dokument mit einer
externen Applikation erstellt und im Dokumentesystem abgelegt werden. Für deren Verbrei-
tung kann danach das Projektmanagementsystem verwendet werden. Ebenfalls wird über die
Rechteverwaltung der Zugriff eingeschränkt.
Da agile Mehoden ein höheres Mass an Zusammenarbeit der einzelnen Teammitglieder und
verteilte Verantwortung vorschreiben, ist hier eine vollständige Integration einiger Bereiche in
das System sinnvoll und schafft einen echten Mehrwert für Kunden und Entwickler. Zudem wird
der Projektleiter entlastet, da viele administrative Aufgaben automatisiert ausgeführt werden.
Für eine genaue Analyse der Anforderung mit Scrum wird auf Mengelt (2008) verwiesen.
4.4.3. Ressourcenmanagement
Beim Ressourcenmanagement werden Personen, Sachmittel und Räume verwaltet.
Die Verwaltung von Personen wird optimalerweise im Zusammenhang mit dem Kontaktmana-
gement erstellt, um redundante Daten zu vermeiden. Durch die Zuweisung einzelner Personen
zu bestimmten Gruppen werden gleichzeitig auch die Berechtigungen für die Ressourcenver-
waltung festgelegt.
Die Verwaltung von Sachmittel und Räumen ist meist nicht nur auf ein Projekt beschränkt,
sondern betrifft alle Projekte und Arbeitsgebiete in einem Unternehmen. Hier kann ein Raum
für ein Projektmeeting genauso wie für eine Geschäftsleitungssitzung gebucht werden. Daher
ist es dem Unternehmen überlassen, diese Verwaltung in die Projektmanagement-Software
zu integrieren oder selbstständig zu führen.
90
4.4.4. Aufgabenmanagement
Das Aufgabenmanagement ist von der gewählten Projektmanagementmethode abhängig. Bei

klassischen Methoden werden Aufgaben vom Projektleiter an die Teammitglieder delegiert,
bei agilen Methoden organisiert sich das Team selbst und entscheidet, wie viele Aufgaben es
in einer bestimmten Zeit erledigen kann.
Für klassische wie auch agile Methoden ergibt sich eine eindeutige Struktur. Ein gesamtes
Projekt wird in Teilaufgaben unterteilt, welche wiederum mehrere Arbeitspakete enthalten. Ein
Arbeitspaket ist die kleinste Einheit und stellt eine Aufgabe dar, welche nicht mehr weiter zer-
legt werden kann. Es muss zudem zuverlässig schätzbar sein und in sich abgeschlossen.
• Aufgaben/Tasks strukturiert zu definieren
• Tasks zu Personen oder Gruppen zuzuordnen
• eigene Tasks auf einem Portal anzeigen zu lassen
• Stunden auf einen Task zu buchen
• Schätzung und Termine zu einem Task hinzuzufügen
• eine automatische Benachrichtigung zu erhalten, wenn ein Task nicht in der vorgegebe-
nen Zeit abgearbeitet wird
Die Möglichkeit, Stunden auf einen bestimmten Task zu buchen, macht ein eigenes Time
Tracker-System überflüssig. Es kann dennoch sinnvoll sein, der Übersicht halber einen eige-
nen Time Tracker-Bereich zu erstellen, wo alle Stunden zusammengetragen werden.
91
92
5. Tool-Evaluation
Die Liste verfügbarer Managementplattformen auf dem Markt ist sehr lang. Viele dieser Platt-
formen fokussieren auf die Dokumente- und Aufgabenmanagement und weisen zum aktuellen
Zeitpunkt einen erfolgsversprechenden Stand der Entwicklungen auf. Dieses Kapitel soll Auf-
schluss darüber bringen, inwiefern sie die Prozessdifferenzierung unterstützen. Der Fokus der
meisten Produkte auf den klassischen Managementprozess schränkt die individuelle Anpas-
sung und die Zusammenarbeit ein. Bereiche wie Kommunikation, Abbildung von Arbeitspro-
zessen und die Integration der Produktentwicklung stehen im Zentrum der Untersuchung.
In Anlehnung an Spath u. a. (2007) werden 17 Open Source-Plattformen auf ihre Eignung

in den Bereichen Kommunikation, Informations- und Datenmanagement und Projektmanage-
ment untersucht. Sechs davon werden detaillierter beschrieben. Aufgrund der hohen Verbrei-
tung werden anschliessend Produkte aus der Microsoft-Familie sowie spezialisierte Alterna-
tiven dazu auf deren Eignung untersucht. Darauf folgen Systeme für die Produktentwicklung.
Zum Abschluss werden neuste Entwicklungen aus dem Bereich des File Sharing untersucht.
5.1. Toolauswahl
Eine Kollaborationsplattform unterstützt die Organisation bei der Kommunikation, Koordination
und Kooperation innerhalb eines Projektes. Tabelle 5.1 listet die 17 untersuchten OpenSource-
Kollaborationsplattformen sowie die dafür benötigte IT-Infrastruktur und die Lizenz. Die mei-
sten dieser Plattformen unterstützen ebenfalls grundlegende Funktionen für das Projektmana-
gement.
93
5. Tool-Evaluation
Kompatible Webserver Daten- Skript- Lizenz

Betriebs- (empfoh- banken sprachen
systeme len)
Open Groupwa- Windows, Apache PostgreSQL, Objective- GNU
re Linux, FrontBase, C GPL,
Mac OSX, Open- LGPL
Solaris LDAP
Open-Xchange Windows SUSE PostgreSQL, Java, C GNU GPL
LINUX DBServer
Enterprise mit JDBC
Server
Simple Group- Windows, Apache MySQL, PHP, XML, GNU GPL
ware Linux, So- PostgreS- SQL,
laris, Mac QL, Oracle HTML,
OS, Novell CSS,
Netware sgsML
phpGroupWare Windows, Apache MySQL, PHP GNU GPL
Linux, Mac PostreSQL,
OSX Oracle,
Sybase,
MSQL,
MSSQL
PHProject Windows, Apache, MySQL, PHP GNU GPL
Linux, Mac IIS, Sam- PostreSQL,
OS, Solaris bar Oracle,
Informix
TUTOS Windows, Apache MySQL, PHP GNU GPL
Linux, PostgreS-
Solaris QL, Oracle,
Borland,
Interbase 5
eGroupWare Windows, Apache, MySQL, PHP GNU GPL
Linux, Mac IIS, Roxen Post-
OSX greSQL,
MaxDB,
MSSQL,
Oracle
NullLogic Windows, standalone MySQL, C GNU GPL
Groupware Linux Server PostgreS-
oder Apa- QL, ODBC
che, IIS,
u.v.a.
IGSuite Windows, k.A. MySQL, Perl GNU GPL
Linux PostgreS-
QL
94
5.1. Toolauswahl
Kompatible Webserver Daten- Skript- Lizenz

Betriebs- (empfoh- banken sprachen
systeme len)
more.groupware Windows, Apache MySQL, PHP GNU GPL
Linux, Mac PostgreS-
OSX QL
Silk Windows, k.A. MySQL Java GNU GPL
Linux
Plone Windows, Zope ZODB Python GNU GPL
Linux, Mac
OSX
netOffice k.A. JavaScript, MySQL PHP GNU GPL
PHP
dotProject Windows, Apache, IIS MySQL PHP GNU GPL
Linux
Web Collab Linux, Win- Apache MySQL, PHP GNU GPL
dows, Mac PostgreS-
OS QL
Scalix Linux Apache k.A. k.A. SPL
Tomcat
Kolab Linux Apache Open- C, Perl GNU GPL
LDAP
Tabelle 5.1.: Technische Daten zu den Plattformen nach Spath u. a. (2007)
Abbildung 5.1 stellt in einem Balkendiagramm alle 17 Tools der Studie mit den erhaltenen
Punkten in den Kategorien Kommunikation, Projektmanagement und Informations- und Doku-
mentemanagement dar. In den folgenden drei Kapitel werden die drei Kategorien für die Top5
Systeme und Plone genauer untersucht.
Das Kivit-Diagramm in Abbildung 5.2 stellt auf übersichtliche Weise die sechs untersuchten
Tools und ihre Dimensionen dar. Alle Tools aus den Top5 erlangen bei der Untersuchung in
allen Kategorien mindestens 6 von 10 möglichen Punkten und weisen somit in allen Bereichen
eine überdurchschnittlichen Funktionsumfang auf. Obwohl „Plone“ im Bereich der Kommunika-
tion und des Projektmanagements nur je 4 Punkte erhält, ist es das einzige Produkt, welches
im Informations- und Dokumentemanagenent die volle Punktzahl erhält.
95
5. Tool-Evaluation
Abbildung 5.1.: Eignung der Tools nach Spath u. a. (2007)
96
5.1. Toolauswahl
Abbildung 5.2.: Kiviatdiagramm der Top5 Tools und Plone nach Spath u. a. (2007)
5.1.1. PHProject
5.1.2. Open Xchange
Open Xchange gehört zu einer sehr verbreiteten Projektmanagementplattform und ist als freie
wie auch kommerzielle Version verfügbar. In der freien Version fehlt die webbasierte Admi-
nistration und Programme und Schnittstellen von Drittanbietern. Ebenso sind einige Erwei-
terungen kostenpflichtig, zum Beispiel die Integration von Microsoft Outlook über sogenannte
Konnektoren. Durch die kommerzielle Version ist die Weiterentwicklung grösstenteils gesichert
und über eine Roadmap einsehbar.
97
5. Tool-Evaluation
5.1.3. eGroupWare
5.1.4. Simple Groupware
5.1.5. IGSuite
5.1.6. Plone
5.2.1. PHProject
5.2.2. Open Xchange
Open Xchange verfügt über ein funktional ausgereiftes Kontaktmanagement-Tool, mit wel-
chem Dateien einem Kontakt zugewiesen und Termine, Aufgaben und Projekte direkt ver-
knüpft werden können. Der Zugang zu den Kontaktdetails wird über Berechtigungen geregelt.
Die Integration von Microsoft Outlook ist gewährleistet und bietet mit der Darstellung als Text-
nachricht eine hohe Sicherheit. Eine zentrale Bookmarkverwaltung, Diskussionsforum und ein
Nachrichtenboard sind ebenfalls vorhanden.
98
99
5. Tool-Evaluation
5.2.3. eGroupWare
5.2.5. IGSuite
5.2.6. Plone
5.3.1. PHProject
5.3.2. Open Xchange
5.3.3. eGroupWare
5.3.5. IGSuite
5.3.6. Plone
5.4.1. PHProject
5.4.2. Open Xchange
5.4.3. eGroupWare
5.4.5. IGSuite
5.4.6. Plone
5.5. Microsoft Produkte und Alternativen
5.5.1. Kommunikation und Zusammenarbeit

100
5.5.1.1. Office Groove 2007
Groove ist ein neues Produkt in der Office-Reihe, welches in den Office-Produkten Ultima-
te 2007 und Enterprise 2007 enthalten ist. Die Groove-Technologie macht es möglich dass
die einzelnen Client-Rechner untereinander kommunizieren, und über eine sichere Internet-
Verbindung Daten austauschen können1 . Nebst dem Stammbereich können weitere Tools in-
tegriert und auf das einzelne Projekt zugeschnitten werden. Groove steht auch als Server-
Version für den Einsatz innerhalb eines Unternehmens bereit und kann vollständig und mit
verhältnismässig wenig Aufwand in eine Microsoft-Server-Umgebung integriert werden und ist
für die Zusammenarbeit mit Microsoft SharePoint vorbereitet.
Groove deckt in der Office-Version standardmässig viele gängige Funktionalitäten ab. Weitere
können selbst mit dem Formulareditor hinzugefügt werden, welcher Javascript, VBScript und
Makros unterstützt.
Rollen
Der Projektleiter startet einen Arbeitsbereich und lädt hierzu weitere Teilnehmer ein. Diese
erhalten im Teambereich folgende Berechtigungen zugewiesen: weitere Teilnehmer ein- und
ausladen, Tools hinzufügen und löschen sowie ausstehende Einladungen abbrechen. Vorde-
finiert sind die drei Rollen Manager, Teilnehmer und Gast. In der Office-Version können keine
weiteren Abstufungen erstellt werden, jedoch können die Berechtigungen dieser drei Rollen
selbst gesetzt werden.
Dokumente
Abbildung 5.3.: Dateiverwaltung in Groove
Im Bereich Dateien werden Projektspezifische Dateien verwaltet. Das Hinzufügen von neuen
Datein geschieht über das Dateibrowsing und legt die Dateien im Workspace ab. Die Doku-
mente werden über die Groove-Oberfläche gestartet, nach dem Beenden automatisch wieder
im Workspace abgelegt und eingeckeckt, sobald eine Internetverbindung besteht. Die Verfüg-
barkeit aller Dateien ist somit auch im Offline-Betrieb gewährleistet. Die Struktur wird dabei
wie gewohnt über Ordner organisiert.
1
(Office2007 Blog, 2008)
101
5. Tool-Evaluation
Für die Verwaltung von Bildern steht eine eigene Oberfläche zur Verfügung, welche eine Vor-
schau sowie die Verlinkung von Bildern, zum Beispiel zur Integration in eine Besprechungs-
Einladung, ermöglicht. Für das schnelle Aufnehmen von Informationen steht eine Notiz- und
Skizzenfunktion zur Verfügung.
Über den Rollenmanager können die Berechtigungen zum Hinzufügen, Ändern und Löschen
von Dateien und Ordnern gesetzt werden. Ebenso besteht die Möglichkeit, diese Berechtigun-
gen nur für eigene erstellte Dateien zu gewähren.
Termine
Abbildung 5.4.: Kalender in Groove
Für die Terminverwaltung steht in Groove ein Gruppen-Kalender zur Verfügung. Gemeinsame
Termine können eingetragen werden und verteilen sich automatisch an alle weiteren Mitglie-
der. Wünscht man mehr Funktionalitäten, so steht ein Besprechungs-Tool zur Verfügung. Ein
Besprechungs-Eintrag kann hier an mehrere Mitglieder zugewiesen werden (und nur diese se-
hen den Eintrag dann auch), es können Anhänge mitgeben, Traktanden erfasst und Protokolle
abgelegt werden. Im Beschreibungstext können hier auch Links zu Bildern, Kalendereinträgen
und Dokumenten erstellt werden.
Kommunikation
Integriert ist das Versenden von Nachrichten an die Projektmitglieder sowie eine Chat-Funktion,
zu welcher alle aktiven Mitglieder Zugang haben. Der Chat verfügt nebst dem Textmodus auch
über einen Zeichnungsmodus.
Aufgaben
Micorosoft stellt online eine Reihe von vordefinierten Formularen bereit, welche in Groove
importiert werden können. Darunter ist auch ein Issue & Task Tracker verfügbar, mit welchem
102
Abbildung 5.5.: Issue & Task Tracker in Groove
offene Aufgaben und Tasks nachverfolgt werden können, welche über ein Start- und Enddatum
verfügen und einem Owner zugewiesen werden.
Kosten
Über den Time Tracker können die aufgewendeten Stunden und somit die Kosten überwacht
werden. Projekte können in Phasen zerlegt werden und einzelne Aktivitäten zur Bearbeitung
an andere Teammitglieder delegiert werden, welche danach ihre Arbeitszeiten auf diesen Ak-
tivitäten erfassen können.
Ressourcen
Microsoft stellt einen Asset Tracker zur Verfügung, mit welchem materielle Ressourcen ver-
waltet und auch verrechnet werden können.
Änderungen
Abbildung 5.6.: Proposal Tracker in Groove
Über den Proposal Tracker können Änderungen und Wünsche eingereicht werden, denen
danach Tasks und Personen zugewiesen werden können. Ebenfalls steht ein Problemver-
folgungsbereich standardmässig zur Verfügung, welcher individuell angepasst und erweitert
werden kann.
Berichte
Mit Project Status Reports kann der Projektstand überwacht werden. Die einzelnen Status Re-
ports können einer Kategorie zugewiesen und von den Projektmitgliedern kommentiert wer-
den.
103
5. Tool-Evaluation
Abbildung 5.7.: Project Status Report in Groove
Sicherheit
Alle Arbeitsbereiche werden in einer verschlüsselten Datei auf der Festplatte gespeichert, auf
die der Zugriff nur mit dem dazugehörigen Konto und über Groove möglich ist. Für die Syn-
chronisation werden die Dateien ebenfalls verschlüsselt.
5.5.1.2. Alternativ zu Groove
5.5.2. Informations- und Datenmanagement
5.5.2.1. Microsoft Sharepoint
5.5.2.2. Alternative zu SP
5.5.3. Projektmanagement
5.5.3.1. Microsoft Project
5.5.3.2. Open Workbench
Open Workbench2 ist eine OpenSource Projektplanungs- und Projektmanagement-Software

als Alternative zu Microsoft Project. Es unterstützt in der Projektplanung Gantt Diagramm,
Vorgangserstellung, Abhängigkeiten von Vorgängen, Ressoucenzuweisung, Kaldenderverwal-
tung für spezielle Ferien- und Abwesenheitszeiten und Grundlinienerstellung sowie in der Pro-
jektverfolgung Aufzeichnung erwarteter Vorgänge, Aufzeichnung aktueller Vorgangsdaten und
die Darstellung des aktuellen Projektstandes in Prozent.
2
www.openworkbench.org
104
5.6. Produktentwicklung
Abbildung 5.8.: Open Workbench Arbeitsbereich
5.6. Produktentwicklung
5.6.1. Eclipse IDE
5.7. File Sharing
File Sharing-Tools unterstützen den Benutzer bei der Verteilung und Nutzung von gemein-
samen Daten. Sie können zusätzlich zu einer Projektmanagement-Software und als Backup-
Funktion genutzt werden. Alle der drei vorgestellten Tools befinden sich noch im Beta-Stadium,
können jedoch bereits aktiv genutzt werden.
Alle Tools laufen im Hintergrund und synchronisieren die verteilten Ordner bei bestehender
Internetverbindung. Nebst dem lokalen Ordner befindet sich der komplette Inhalt auch auf
dem Repository. Eine kommerzielle Nutzung ist auch nach der Beta-Phase vorgesehen, es
bleibt abzuwarten, ob die Dienste dann weiterhin kostenlos zur Verfügung stehen.
105
5. Tool-Evaluation
Dropbox Syncplicity FolderShare

Lizenz Private Beta Freeware
Kapazität 2GB Beta: unlimitiert 2GB
Nachher: 2GB
Plattform Win/Mac Win/Mac
Abhängigkeit - .NET Framework -
3.0
Registrierung Private Beta Frei Windows LiveID
Speicherort lokal „My Dropbox“ individuell individuell
Ordner
Einstellung Synchronisation Automatisch gan- File Browser Online oder lokal
zer Ordnerinhalt
Integration Kontextmenü nur innerhalb „My „Share“ und -
Dropbox“-Menü „Add“-Funktion
Versionierung x x -
Speziell History Verknüpfung von Integration in Mi-
GoogleDocs und crosoft Dienste
iPaper
Tabelle 5.2.: Vergleich von File Sharing Tools
5.7.1. Dropbox
Dropbox3 ist eine frei verfügbare Software im Private Beta-Stadium für die verteilte Nutzung
von Dateien. Die Installationsdatei für Windows oder Mac ist ca. 7MB gross. Nach der Instal-
lation werden alle Dateien im Ordner <EIGENE_DATEIEN>/My Dropbox synchronisiert.
Ein bestehender Ordner kann über das Webinterface mit weiteren Benutzern geteilt werden.
Hierfür kann die Einladung an eine beliebige Mail-Adresse versendet werden.
Ein grosser Vorteil von Dropbox ist die History und Versionierung. Während lokal die aktuell-
sten Versionen der Dateien gespeichert werden, können über das Webinterface auch ältere
Dateiversionen heruntergeladen werden. Dropbox fungiert hier als Online-Repository. Die Ver-
sionierungsfunktion ist einer der Stärken von Dropbox und beschleunigt das Abgleichen der
Dateien, da nur die Dateiveränderung hochgeladen werden muss. Über die History können
die neusten Veränderungen schnell nachverfolgt werden.
Im Internet Explorer wird der aktuelle Status der Dateien angezeigt, wobei zwei weisse Pfeile
auf blauem Hintergrund bedeuten, dass der Ordner oder die Datei sich noch in der Synchro-
nisation befindet.
3
www.getdropbox.com
106
5.7. File Sharing
Abbildung 5.9.: Online Ordner History von Dropbox
Abbildung 5.10.: Online Versionierung von Dropbox
Abbildung 5.11.: Lokale Ordner-Markierung von Dropbox
107
5. Tool-Evaluation
5.7.2. Syncplicity
Syncplicity4 liegt aktuell im Beta-Stadium vor. Für die Installation der 2.2MB grossen Datei wird
das .NET Framework 3.0 benötigt. Lokale Ordner können bei Syncplicity über das Kontextme-
nü oder den integrierten File Browser registriert werden. Bei der Einladung weiterer Benutzer
können für die Ordner Lese- und/oder Schreibrechten gesetzt werden. Die lokale Installation
bietet einen eigenen File Browser für die Verwaltung aller freigegebenen Dateien.
Abbildung 5.12.: Online File Browser von Syncplicity
Obwohl die aktuelle Version bereits stabil läuft, sind viele der verfügbaren Funktionen noch
schwer zu gebrauchen. Beispielsweise kann der lokale File Browser nur genutzt werden, wenn
eine Verbindung zum Server besteht. Ohne verfügbare Internetverbindung ist es somit nicht
möglich, Administrationsaufgaben auszuführen.
Im Beta-Stadium ist der Datentransfer und der verfügbare Speicherplatz unbeschränkt. Da-
nach wird er auf 2GB und 2 Computer limitiert. Syncplicity stellt auch ein Modell für die kom-
merzielle Nutzung zur Verfügung. Hierbei können für 99$ pro Jahr total 40GB Datenspeicher
und unlimitierte Computer konfiguriert werden. Mit zusätzlichem Versand von Einladungen an
4
www.syncplicity.com
108
5.7. File Sharing
Freunde können pro Annahme weitere 250MB freigeschaltet werden, dies bis zu 10GB zu-
sätzlich.
Abbildung 5.13.: Ordner Kennzeichnung mit Syncplicity
Wie auch bei Dropbox werden die in der Synchronistaion eingeschlossenen Ordner durch ein
Symbol markiert (siehe Abbildung 5.13). Die abgeglichen Dateien erhalten durch einen grünen
Haken eine entsprechende Kennzeichnung (siehe Abbildung 5.14). Die Kennzeichnung ist nur
im Online-Modus verfügbar.
Abbildung 5.14.: Lokale Datei-Markierung von Syncplicity
Hervorzuheben ist die gute Navigation durch einen intuitiven Browser im Webinterface. Der
lokale und der Online File-Browser sind die Stärken von Syncplicity. Ebenso ist Online eine
Versionierung aller Dateien abzurufen, um Zugriff auf ältere Dateien zu erhalten (siehe Abbil-
dung 5.15). Dem gegenüber lässt das Benutzermanagement in der aktuellen Version noch zu
wünschen übrig.
Als einziges untersuchtes Tool bietet Syncplicity eine Schnittstelle zu Produkten von Drittan-
bietern. Darunter hervorzuheben sind GoogleDocs, Scribd, Zoho und picnik.
Über GoogleDocs können Dokumente aus dem Repository von GoogleDocs durch hinterle-
gen der Anmeldedaten im Webinterface hinzugefügt werden. Die Dateien werden danach in
das File Repository von Syncplicity hinzugefügt.
Für die Ansicht und Bearbeitung von Dateien stehen Scribd, Zoho und picnik zur Verfügung.
Über das Kontextmenü können alle synchronisierten Dateien betrachtet (Scribd) sowie Doku-
mente editiert (Zoho) und Bilder bearbeitet (picnik) werden. Danach werden die Dateien wieder
zurück ins Repository von Syncplicity gespeichert und bei der nächsten Synchronisation lokal
heruntergeladen.
109
5. Tool-Evaluation
Abbildung 5.15.: Online Versionierung von Syncplicity
5.7.3. Windows Live FolderShare
FolderShare5 ist nicht nur eine Synchronisationssoftware, sondern vereinfach den Zugriff auf
verteilte Daten und bietet zusätzlich Remote-Verbindungen. Benötigt man ein Dokument, wel-
ches auf einem anderen Rechner liegt, so kann man mit FolderShare jederzeit darauf zugrei-
fen. Somit kann man zum Beispiel ein gespiegeltes Abbild wichtiger Dateien auf mehreren
Computern erzeugen. Die Synchronisierung erfolgt hierbei automatisch oder auf Anfrage, so-
bald die Datei benötigt wird.
Abbildung 5.16.: Online Ordner-Administration von FolderShare

5
www.foldershare.com
110
5.7. File Sharing
Dateien werden online auf dem Server von FolderShare gespeichert. Kostenlos stehen 2GB
Datenplatz zur Verfügung. Hat man einen persönlichen Ordner eingerichtet, so kann man
diesen mit weiteren Benutzern teilen. Hierfür wird eine Einladung an die betreffende LiveID
versendet. FolderShare bietet sogar ein Benutzerberechtigungssystem mit folgenden Berech-
tigungen:
Leser können Dateien in der Bibliothek anzeigen, jedoch keine Dateien hinzufügen oder än-
dern.
Mitwirkende können Dateien anzeigen und hinzufügen, jedoch nicht ändern oder löschen.
Editoren können Dateien in dieser Bibliothek anzeigen, ändern, löschen und zu ihr hinzufü-
gen.
Verwalter haben die gleichen Möglichkeiten wie Editoren und können außerdem Bibliotheks-
berechtigungen ändern.
FolderShare kann auch als Remoteverbindungs-Tool verwendet werden, um von jedem mit
dem Internet verbundenen Computer auf alle eigenen Dateien zugreifen zu können.
Für die Benützung von Windows Live FolderShare wird eine Windows LiveID benötigt. Nach
der Installation der Software (Grösse ca. 1MB) unter Windows oder Mac, können persönliche
Bibiliotheken erstellt werden. Eine Bibliothek entspricht einem lokalen Ordnern sowie allen
darin enthaltenen Unterordner und Dateien. Werden weitere Benutzer dazu eingeladen, so
können diese den Inhalt des freigegebenen Ordners lokal an einem beliebige Ort hinzufügen.
FolderShare steht in verschiedenen Sprachen zur Verfügung, darunter auch als deutsche Ver-
sion.
111
5. Tool-Evaluation
112
6. Software Plattform
Zope, Plone, Phyton.
Warum Plone? Wie ist Plone aufgebaut? Was ist Zope, was ist Phyton? Was sind die Ei-
genheiten davon? Wie ist die Grundplattform/Core aufgebaut? Welche Funktionen sind in der
Grundinstallation enthalten? Welche Erweiterungen sind erhältlich? Welche davon kann ich
benutzen? Wie werde ich welche Erweiterung zur Abdeckung welcher Anforderung verwen-
den?
6.1. Programmiersprache Python
Python wurde 1990 von Guido van Rossum in

Amsterdam als Programmier-Lehrsprache entwickelt. Der Fokus lag hierbei auf einer leicht
zu erlernenden und übersichtlichen Sprache. Durch den grossen Funktionsumfang wurde Py-
thon bald in der Entwicklung von grösseren Systemen eingesetzt. Python vereinfacht es, gut
lesbaren und wiedervewendbaren Code zu schreiben. Sie wurde absichtlich zur Verbesserung
der Entwicklungsqualität in der Skript-Welt entworfen.
Python ist eine Very-High-Level Language (VHLL) und benutzt somit ein höheres Level an
Abstraktion als beispielsweise C++ (Martelli, 2006).
6.1.1. Vorteile von Python
Die wichtigsten Gründe für die Benutzung von Python sind Qualität, Produktivität, Portabilität
und Integration.(Lutz, 2006)
113
Software Qualität: Pythons klare Syntax und das kohärente Design bringt Programmierer
dazu, gut lesbaren Code zu schreiben, ein kritisches Feature für Softwarecode, welcher
zukünftig verändert und weiterentwickelt werden muss. Die Sprache wurde von Grund
auf designt und hat ein orthogonales und klares Design, um Code schnell zu verste-
hen und leicht vorauszusagen. Der Kern der Sprache wurde einfach gehalten und kann
durch modular aufgebaut Libraries erweitert werden. Die Einschränkung der möglichen
Beeinflussung im Code reduziert die Programmkomplexität wie auch das Fehlerpoten-
tial. Ebenso kann Python die modernen Methoden der Softwareentwicklung abbilden,
strukturierte, modulare wie auch objektorientierte Programmierung sind möglich.
Produktivität: Mit Python kann die Anzahl Codierzeilen in einem Programm deutlich verkürzt
werden, da der Interpreter sich um viele Details kümmert, welche in andere Sprachen
expliziet auscodiert werden müssen. Auch die Wiederverwendbarkeit von Codefragmen-
ten ist aufgrund der fehlenden Abhängigkeit des Codes von der Typdefinition des Objek-
tes gewährleistet, denn es kann einaml geschriebener Implementations-Code auf wei-
tere Typen angewendet werden, wenn diese daselbe Interface implementieren. Ein wei-
terer Grund für die Produktivität von Python ist die Einfachheit der Struktur des Codes.
Durch die minimierte Anzahl Codezeilen wird der Code übersichtlicher und somit leser-
licher für Programmierer, welche bestehenden Code überarbeiten und weiterentwickeln
müssen. Diese können sich schneller einarbeiten und werden somit auch schneller pro-
duktiv.
Portabilität: Programme, welche in Python geschrieben wurde, sind auf unterschiedlichen

Plattformen lauffähig. Somit kann ein Code, der auf einer Windows-Installation geschrie-
ben wurde, ohne Änderungen direkt auf einem Linux-Rechner, auf einem Macintosh
oder einem PDA in Betrieb genommen werden.
6.1.2. Grundlagen
Python ist eine imperative Programmiersprache, mit welcher objektorientiert wie auch funktio-
nal programmiert werden kann. Wie Java, wir der Programmiercode durch einen Compiler in
Byte-Code übersetzt, welcher danach im Python-Interpreter ausgeführt wird. Der entstandene
Byte-Code ist plattformunabhängig und unterstützt insbesondere die Betriebssysteme Win-
dows, Linux und Mac OS X. Im Lieferumfang von Python ist nebst dem Interpreter und dem
Compiler eine umfangreiche Standardbibliothek vorhanden, welche es dem Programmierer
erlaubt, schnell komplexe Aufgaben zu lösen.
114
Interner Ablauf
Python kann als interpretierte Programmiersprache in einer beliebigen Entwicklungsumge-

bung geschrieben werden und mit jedem Texteditor geöffnet werden. Die Endung einer Python-
Datei ist *.py. Der Compiler übersetzt danach die Programmdatei in Byte-Code, der entweder
im Arbeitsspeicher bleibt oder als ausführbarer Code mit der Endung *.pyc auf die Festplatte
geschrieben wird. Der übersetzte Byte-Code wird danach in einer virtual machine, dem so-
genannten Interpreter, ausgeführt. Abbildung 6.1 zeigt das Kompilieren und Ausführen einer
Programmdatei.
Abbildung 6.1.: Ablauf einer Programmdatei
Ausführung in der Kommandozeile
Python kann über die Kommandozeile im sogenannten interaktiven Modus ausgeführt werden.
Nach der Eingabeaufforderung »> des Interpreters kann beliebiger Code eingegeben werden.
Abbildung 6.2 zeigt die Kommandozeile unter Windows.
Abbildung 6.2.: Eingabeaufforderung in der Kommandozeile
6.1.3. Konzept und Syntax
Die gute Lesbarkeit von Python ist zu einem grossen Teil der strengen Syntax zu verdanken.
Eine Anweisung besteht im einfachsten Fall aus einer Zeile. Das Ende der Anweisung wird
mit einem Zeilenumbruch gekennzeichnet. Anweisungen, welche sich in einen Kopf und einen
115
Körper unterteilen lassen, werden durch Doppelpunkt am Ende des Anweisungskopfs und
Einrückung des Anweisungskörpers um 4 Leerzeichen festgelegt. Eine Kennzeichnung eines
Körpers durch geschweifte Klammer {...}, wie bei vielen Programmiersprachen üblich, existiert
in Python nicht.
# Anweisung
x = 10
if x < 20:
print “Hallo Welt”
Abbildung 6.3.: Anweisungen in Python
Fallunterscheidungen
Fallunterscheidungen sind Konstrukte, welche dazu dienen, einen Anweisungsblock unter be-
stimmten Bedingungen ausführen zu lassen. Ein Fallunterscheidungs-Block beginnt immer
mit dem Schlüsselwort if. Weitere Unterscheidungen können durch elif erzeugt werden. Eine
Default-Anweisung wird durch das Schlüsselwort else eingeleitet.
if x == 1:
print "x hat den Wert 1"
elif x == 2:
print "x hat den Wert 2"
else:
print "Fehler: Der Wert von x ist weder 1 noch 2"
Abbildung 6.4.: Fallunterscheidung in Python
Conditional Expression
Bedingte Ausdrücke sind Anweisungen in der Form A if Bedingung else B, wobei Bedingung
ein beliebiger logischer Ausdruck sein kann. Die Auswertungsreihenfolge unterscheidet sich
insofern vom herkömmlichen Ablauf, dass zuerst die Bedingung ausgewertet wird, danach die
Anweisung A für eine wahre Bedingung, und sonst die Anweisung B.
Abbildung 6.5.: Conditional Expression in Python
116
Schleifen
Schleifen ermöglichen es, einen bestimmten Codeblock mehrmals auszuführen. Dabei stehen
dem Programmierer die while- und die for -Schleife zur Verfügung.
Eine while-Schleife wird ausgeführt, sofern die Bedingung „true“ ist. Mittels „continue“ kann ein
Schleifendurchlauf vorzeitig beendet werden, durch „break“ wird die ganze Schleife verlassen.
Abbildung 6.6.: For-Schleife in Python
Die for -Schleife dient dazu, einen Codeblock eine genau definierte Anzahl Mal zu durchlau-
fen. Dabei durchläuft die for -Schleife ein beliebiges iterierbares Objekt, zum Beispiel eine Zei-
chenkette oder einen Zahlenbereich. Wir ein Zahlenbereich verwendet, so stehen zu dessen
Definition drei Varianten zur Verfügung:
range(stop) - range(start, stop) - range(start, stop, step)
Module
In Modul ist ein Code-Fragment, welches in einer eigenen Datei steht und von anderen, meh-
reren Dateien importiert und verwendet werden kann. Sie tragen ebenfalls die Endung *.py
und können somit als Modul oder als eigenständige Programme verwendet werden. In einem
Modul definierte Variabeln können durch den Befehl
from <Modulname> import <Variable>
importiert werden. Der Befehl
from <Modulname> import *
117
importiert alle Variabeln und Funktionen, welche nicht mit einem „_“ beginnen. Diese soge-
nannten Membervariabeln sind nur innerhalb des Moduls sichtbar und können nicht von aus-
sen aufgerufen werden. (Schwarzer, 2006)
Objektorientierte Programmierung
Eine Klasse in Python wird mit der Anweisung class erzeugt. Eine neue Instanz wird mit dem
Konstruktor __init__ erzeugt, welcher die neue Instanz mit Werten initialisieren kann. Auch
die Vererbung von einer oder mehreren Klassen ist in Python möglich. (Schwarzer, 2006)
6.1.4. Fazit
Die Einfachheit von Python, seine Flexibilität und Erweiterbarkeit lässt die Sprache für klei-
ne wie auch grosse und komplexe Projekte interessant werden. Grosse Firmen wie Google
oder die NASA schätzen die Vorteile von Python in ihren Projekten. Auch die Online Platt-
form YouTube wurde fast vollständig in Python programmiert. Die einfache Installation, die
Plattformunabhängigkeit, die grosse Standard Bibliothek sowie der offene Quellcode machen
Python zu einer mächtigen Sprache. Arbeiten mehrere Programmierer am selben Quellcode,
soll dieser leicht erlernbar, verständlich und überschaubar sein, so ist Python eine optimale
Wahl. Die Ausnahmebehandlung von Python erlaubt es, die Zeit für Fehlersuche wesentlich
zu verringern.
6.2. Applikationsserver Zope

Zope ist ein objektorientierter Open-Source-Applikationsserver für datenbankgestützte dyna-
mische Internetanwendungen wie z. B. Content- und Dokumenten-Management Systeme oder
ERP- und eCommerce-Plattformen (Zope Group, 2008). Es erlaubt und erleichtert Entwicklern
mit unterschiedlichen Levels und Fähigkeiten die Entwicklung von sogenannten Web Applika-
tionen. Web Applikationen sind Programme, welche über das Internet erreichbar sind und eine
oder mehrere der folgenden Bedingungen erfüllen:
• Speicherung der Daten in einer Datenbank (z.B. MySql)
• Entwicklung mit Hilfe eines Applikationsentwicklungstools (z.B. eclipse)
• Dauerhaft laufender Server-Prozess für Erreichung der Applikation
• Speicherung der Daten über Eingabescreens oder Formulare
118
6.2.1. Konzept von Zope
Zope erweitert als Web Applikationsserver, als ein Framework, um Web Applikationen zu ent-
werfen, die Standard-Fähigkeiten der Programmiersprache Python um Dienste wie Templa-
ting, Security Model, Datenpersistenz, Sessions und weitere nützliche Features. Die Vorteile
von Zope als Applikationsserver und Grundsteine für den Betrieb eines WCMS sind (Zope
Community, 2008):
Dynamischer Inhalt: Dynamische Inhaltsbereitstellung sowie Personalisierung, Datenban-

kintegration, Inhaltsindexierung und Suchfunktionalität
Content Management System: Erstellen und editieren von Inhalten auch für nichttechnische
Editoren dank entsprechender Tools
Zugangskontrolle und Sicherheit: Abgestufte Benutzerberechtigungen für unterschiedliche

Benutzer und Benutzergruppen
Aufruf von Objekten
Zope übernimmt von der Programmiersprache Python die Objektorientierung. Somit werden
Daten und Methoden in einem Objekt zusammengefasst. Die Klasse definiert das Verhalten
einen Objekts und dient als Konstruktor. Für Grundlagen zur Objektorientierung im Zusam-
menhang mit Zope sei auf (Zope Community, 2008) verwiesen.
Wie dies bereits von Webserver wie Apache oder Microsoft IIS bekannt ist, welche die URL auf
Verzeichnisse und Dateien abbilden, wird dies auch von Zope in ähnlicher Weise umgesetzt.
Die über den Webbrowser aufgerufene URL wird von Zope in seine Bestandteile in der Form
protocol://host:port/path?querystring
aufgeteilt. Zope lokalisiert das Objekt in der Objektdatenbank anhand des Pfades und führt
darauf die Parameter des Abfragestring aus. Ist die Ausführung erfolgreich, so wird das Resul-
tat an den Browser zurückgesendet. Meist sind dies Daten in HTML, Dateien oder Bilder.
Sicherheit
Zope wurde von Beginn an mit Fokus auf das Webentwicklungsmodell und die Sicherheits-
abstufung designt. Eine erfolgreiche Webseite benötigt eine flexible Rechteverwaltung, um
die Sicherheit der Applikation zu gewährleisten. Die Objekte in Zope stellen eine umfangrei-
chere Zugriffsbeschränkung als herkömmliche Dateisysteme bereit. Die Zugriffskontrolle wird
119
über das Objekt selbst geregelt und erlauben somit eine feine Abstufung der Zugriffe. Dieses
Grundkonzept, welches im Applikationsserver selbst implementiert ist, kann von jedem Objekt
innerhalb des Applikationsservers verwendet werden. Entwickler haben somit als Basis eine
ausgereifte Grundlage für ihr Berechtigungskonzept.
Akquisition
Die Akquisition ist eine Spezialform der Vererbung. Bei dem herkömmlichen Vererbungskon-
zept erbt eine Klasse die Eigenschaften der Vaterklasse. In Zope kann ein Objekt zusätzlich
von einem übergeordneten Objekt in der Objekthierarchie erben. Dieses Vererbungskonzept
ist einzigartig und wird hauptsächlich für die gemeinsame Nutzung von Informationen, zum
Beispiel einen gemeinsamen Header eines ganzen Ordners einer Webseite, verwendet. Sei-
ne Mächtigkeit zeichnet sich dadurch aus, dass Definitionen an einer einzigen zentralen Stelle
verwaltet und ohne explizite Einbindung verwendet werden können, und dies auf unterschied-
lichen Objekten. Die Akquisition kommt erst nach der Vererbung zum tragen.
Ein Beispiel:
Das Objekt Sub(SuperA, SuperB) erbt von der Klasse SuperA sowie der Klasse SuperB.
Zudem liegt es im Ordner SuperFolder. Wird in einer Instanz des Objektes Sub nun
die Methode instance.method() aufgerufen, so werden der Reihe nach SuperA >
SuperB > SuperFolder nach der aufgerufenen Methode durchsucht.
6.2.2. Grundlagen
6.2.2.1. ZMI - Zope Management Interface
Auf Zope-Objekte kann vollständig über den Brwoser zugegriffen werden. Somit kann die ge-
samte Entwicklung und Administration über den Browser abgehandelt werden.
6.2.2.2. ZODB - Zope Object Database
Objekte in Zope werden in einer performanten Objektdatenbank gespeichert. Jede Anfrage

über das Web wird als eigene Transaktion behandelt und ist vollkommen atomar. Entwickler
brauchen sich bei der Programmierung nicht auf die Atomarität ihrer Datenbankmanipulatio-
nen zu konzentrieren. Die Persistenz für die Objekte und Objekt-Instanzen wird kann von Zope
übernommen werden.
120
6.2.2.3. Architektur
Zope besteht als Web Applikationsserver aus unterschiedlichen Komponenten, welche die
Entwicklung von Webapplikationen unterstützen.
ZServer: Der integrierte ZServer empfängt Inhalte via FTP, WebDAV, XML-RPC und über den
Browser und stellt Inhalte dem Benutzer zur Verfügung.
Web Server: Für die Benutzung von Zope kann anstelle des eigenen Web Servers auch ein
alternatives Produkt wie Apache oder Microsoft IIS verwendet werden, sowie weitere
Web Server, welche das Common Gateway Interface (CGI) unterstützen.
Zope Core: Der Kern von Zope koordiniert die Zusammenarbeit der Datenbank, des Web
Servers und den Erweiterungen und stellt die Kernfunktionalitäten bereit.
Object Database: Die Zope Object Datenbank ZODB speichert die von Zope verwendeten
Objekte.
Relationale Datenbanken: Zope unterstützt die Verwendung von relationalen Datenbanken

wie Oracle, PostgreSQL, Sybase oder MySQL. Man ist somit nicht an die Verwendung
der ZODB gebunden, um die Objekte zu speichern.
File System: Dateien können in Zope entweder in der ZODB oder auf dem Dateisystem ab-
gelegt werden. Dies ermöglicht die Verknüpfung von lokalen Dateien und den Zugriff
darauf, ohne von Zope abhängig zu sein.
ZClasses: ZClasses sind zustätzliche Objekttypen, welche über das Zope Management In-
terface ZMI hinzugefügt wurden.
Products: Zustätzlich zu den ZClasses können externe Produkte auf dem Dateisystem des
Zope-Servers installiert werden und als Objekte in Zope eingebunden werden.
6.2.3. Zope Services
Einige Zope Objekte sind Service-Objekte, welche verschiedene Dienste bereit stellen. Eine
nicht abschliessende Liste (Zope Community, 2008):
Access Rule Services: Zugangsregeln ermöglichen es, beim öffnen eines bestimmten Ord-
ners eine Aktion auszulösen.
121
Temporary Storage Services: In Zope können Objekte temporär in entsprechenden Ord-

nern gespeichert werden. Diese Ordner unterscheiden sich von den „normalen“ Ord-
nern in dem Sinne, dass die Objekte bei einem Neustart des Zope-Servers gelöscht
werden und Änderungen nicht durch die Undo-Funktion rückgängig gemacht werden
können. Die temporären Objekte werden im RAM und nicht in der ZODB gespeichert.
Standardmässig ist im Root ein temporärer Ordner temp_folder enthalten. In tempo-
rären Ordnern werden hauptsächlich kleine Objekte mit vielen Zugriffen gespeichert, ein
Beispiel dafür sind Daten über Benutzersessions. Für grössere Objekte sind temporäre
Ordner weniger geeignet.
Caching Services: Im Cache werden Objekte nach dem ersten Rendering gespeichert und
so die Zeit für die Bereitstellung des Inhaltes bein nächsten Aufruf bedeutend verringert.
Vorwiegend für komplexere Abfragen mit komplizierten Abfragen, wie sie auf Internetsei-
te oftmals vorkommen, steigern Caching Dienste die Performance der Webseite.
Error Logging Services: Zope stellt einen Logging-Dienst für Fehlermeldungen bereit, der
bei der Fehlersuche und deren Behebung behilflich sein soll.
Searching und Indexing Services: ZCatalog ist die in Zope integrierte Suchmaschine, mit
deren Hilfe alle Zope-Objekte durchsucht werden können. Für eine detaillierte Beschrei-
bung zu den Such- und Indexierungsmöglichkeiten in Zope sei auf (Zope Community,
2008) verwiesen.
Session Services: Sitzungsdaten eines Benutzers werden in Plone registriert und erlauben
es den Entwicklern, diese Daten für ihre Webanwendung weiter zu verwenden.
6.2.4. Fazit
Zope stellt als Web Applikationsserver eine grosse Menge an Grundfunktionalitäten und Diensten
zur Verfügung, welche von Entwicklern für die Programmierung von Webseiten verwendet
werden kann. Da Zope von Grund auf mit Fokus auf Web Anwendungen entwickelt wurde,
unterstützt es die Bedürfnisse optimal und erleichtert das Fehlerhandling sowie verringert den
Programmieraufwand.
Zope ist Open-Source und kann individuell angepasst werden. Die mitgelieferten Komponen-
ten wie eigene Datenbank ZODB kann ebenso durch eine eigene Datenbank ersetzt werden
wie der in Zope integrierte Web Server, der durch Apache oder Microsoft IIS getauscht werden
kann.
122
6.3. CMS Plone
6.3. CMS Plone

Plone ist ein sogenanntes ECMS, geschrieben in Python und mit Zope als Applikationsser-
ver.
6.3.1. Installation Basisversion
Plone wird als Produkt oder als Gesamtpaket mit Zope und Python ausgeliefert. Die Installation
des Pakets ist denkbar einfach, man braucht lediglich den Installationsschritten zu folgen.
6.3.2. Grundlagen
Nach der Installation kann „Plone“ über den Webbrowser unter http://localhost auf-
gerufen werden. Sie wird mit den Standard-Layout geliefert und enthält initial bereits einige
erstellte Texte und Ordner.
6.3.2.1. Artikel
In „Plone“ gibt es verschiedene Artikeltypen, durch welchen der Verwendungszweck und die
Eigenschaften festgelegt werden. Initial werden folgende Artikeltypen mitgeliefert:
- Seiten
- Nachrichten und Termine
- Bilder und Dateien
- Links und Lesezeichen
- Ordner und Kollektionen
Alle Artikeltypen stellen mindestens die Reiter Anzeigen, Bearbeiten und Zugriff zur Verfü-
gung, sofern der Benutzer über genügend Berechtigungen verfügt („Ansehen“ resp. „Bearbei-
ten“). Anzeige und Bearbeiten sind für alle Artikeltypen gleich. Eine detaillierte Auflistung aller
verfügbaren Reiter und Einstellungen gibt Tabelle 6.1. Der Status
Anzeige
Die Anzeige stellt Artikel so dar, wie sie auch der Besucher der Webseite sieht und besteht
aus folgenden Elementen:
1. Titel
2. Verfasserzeile
3. Beschreibung
123
nen
n
iere
ktio
g
n
llun
olle
nen
orm
eite
gen
en
n
alte
terk
rste
riff
tus
sio
nsf
arb
teri
gel
zei
Zug
Sta
Ver
Inh
Tra
Re
Un
Da
Kri
An
Be
Ordner x x x x x x x
Kollektionen x x x x x x x x x
Seite x x x x x
Bild x x x x
Datei x x x
Nachricht x x x x x
Termin x x x x x
Tabelle 6.1.: Verfügbarkeit der Einstellungen in Plone
4. Artikelaktionen
5. Historie (nur für angemeldete Benutzer sichtbar)
6. Vor- und Zurückblättern (je nach Einstellungen des Ordners)
Die beiden Artikeltypen „Ordner“ und „Kollektion“ können als Container zur Strukturierung ver-
wendet werden. Anhand dieser Struktur wird auch die Navigation aufgebaut. Die „Kollektion“
ist hierbei ein interessantes und mächtiges Konstrukt, welches es erlaubt,
6.3.3. Arbeitsablauf
„Plone“ kennt unterschiedliche Arbeitsabläufe, welche einem Artikeltyp zugewiesen werden

können. Die Arbeitsabläufe bestimmten die verfügbaren Statuse und deren mögliche Über-
gange.
Kein Arbeitsablauf
Hat ein Artikeltyp den Status „kein Arbeitsablauf“, so wird die Sichtbarkeit des Artikels durch
den Ordner bestimmt, in welchem er sich befindet. Initial ist dies dem Typ „Bild“ und „Datei“
zugewiesen. Bei der Erstellung wird der Artikel nach dem Speichern gleich publiziert und kann
eingesehen werden, wenn man für den übergeordneten Ordnen die entsprechenden Berech-
tigungen hat.
Arbeitsablauf mit einem Zustand
Artikeltypen mit einem Zustand verfügen nach dem Speichern über den Status veröffentlicht.
Weitere Statusübergänge sind nicht möglich.
124
6.3. CMS Plone
Einfacher Publikationsarbeitsablauf
Dies ist der Standard-Ablauf. Nach dem Erstellen eines Artikels erhält dieser den Status „pri-
vat“. Danach kann er zur Veröffentlichung an die Redaktion eingereicht oder direkt für alle
Benutzer veröffentlicht werden.
Intranet Arbeitsablauf
Beim Intranet-Arbeitsablauf sind Inhalte nur sichtbar, wenn man angemeldet ist. Neu erstellte
Artikel erhalten den Status „Interner Entwurf“. Die grundlegenden Zustände sind: Interner Ent-
wurf, Zur Prüfung eingereicht, Intern veröffentlicht und Privat. Es gibt auch den Status „extern
veröffentlicht“, sodass Sie ausgewählte Inhalte Personen ausserhalb des Intranets zugänglich
machen können.
Zusätzlich gibt es einen Intranet Arbeitsablauf für Ordner, welcher nur über die Zustände „In-
terner Entwurf“ und „Privat“ verfügt.
Community Arbeitsablauf
Benutzer können Inhalte erzeugen, die sofort öffentlich zugänglich sind. Inhalte können ver-
öffentlicht werden, wenn Sie zur Redaktion eingereicht werden, was typischerweise gemacht
werden sollte, damit Termine und Nachrichten auf der Startseite erscheinen. Während der In-
halt der Redaktion zur Prüfung vorliegt, kann ihn jeder lesen. Sobald der Inhalt veröffentlicht
ist, kann er nur vom Administrator zurückgezogen werden.
6.3.4. Benutzerberechtigungen
Nicht angemeldete Besucher der Seite oder Benutzer ohne Berechtigungen sehen alle Inhal-
te der Seite, welche den Status „Veröffentlicht“ besitzen. Für die Zusammenarbeit mehrerer
Personen können Berechtigungen für jeden einzelnen Benutzer oder für ganze Gruppen ver-
geben werden. Diese Berechtigungen können dann auf alle Artikeltypen angewandt werden.
„Plone“ liefert standardmässig die in Tabelle 6.2 aufgelisteten Berechtigungs-Funktionen. Die-
se können auf einzelne Benutzer wie auch auf ganze Gruppen angewandt werden. Genügen
diese vordefinierten Abstufungen nicht aus, so können im ZMI weitere Funktionen definiert
werden. Das ZMI listet unter acl_users im Bereich Security alle Rollen und deren Be-
rechtigungen. Da das ZMI vollständig in Englisch aufgebaut ist, werden hier auch die engli-
schen Funktionen gelistet: Contributor (Hinzufügen), Editor (Bearbeiten), Member (Benutzer),
Reader (Ansehen), Reviewer (Veröffentlichen) und Manager (Verwalten). Eine weitere Rolle
125
n
che
n
n
üge
ntli
lten
eite
zer
en
öffe
seh
zuf
wa
arb
nut
Hin
Ver
Ver
Be
An
Be
Anzeige private Artikel x x x x
Anzeige eingereichter Artikel x x x x x
Veröffentlichen eingereichter Artikel x x x
Zurückweisen eingereichter Artikel x x x
Einreichen privater Artikel x x
Änderung der Darstellung x x x
Hinzufügen neuer Artikel x1 x
Tabelle 6.2.: Berechtigungen nach Benutzerstatus
ist der Besitzer (Owner). Als Besitzer eines Artikels hat man darüber mehr Rechte, man kann
ihn standardmässig bearbeiten und löschen.
6.3.5. Erweiterungen
Plone-Produkte sind Erweiterungen, welche die Basis-Funktionalität erweitern. Ein grosses

Repository von frei verfügbaren Produkten findet man auf der Seite der Zope-Community2 . Die
Produkte werden in gezippter Form zum Donwload zur Verfügung gestellt und sind entweder
als normale Pakete oder als sogenannte „Eggs“ verfügbar.
Plone-Produkte werden entpackt und der Ordner in den Produkte-Ordner <PLONE_HOME>/

Data/Products kopiert. Nach einem Neustart des Applikationsservers, können die Pro-
dukte in der Konfiguration unter „Zusatzprodukte“ installiert werden.
Die Installation von Produkte ist oftmals aufwendig, weil diverse Abhängigkeiten zwischen von
anderen Produkte bestehen, welche zusätzlich installiert werden müssen. Seit der Version 3
verfügt Plone über ein Skript mit dem Namen „easy_install“. Die „Eggs“ werden mit diesem
Skript installiert, welches im selben Schritt alle Abhängigkeiten prüft und diese bei Bedarf mit-
installiert. Zusätzlich können über das Installationsskript bereits diverse Einstellungen an der
Konfiguration vorgenommen werden. Das Skript befindet sich im Ordner <PLONE_HOME>/
Python/Scripts/. Möchte man „easy_install“ unter Windows über die Kommandozeile
aufrufen, muss der Ordner als Umgebungsvariable hinzugefügt werden.
2
http://www.plone.org
126
6.3. CMS Plone
Abbildung 6.7.: Zope Architektur (Zope Community, 2008)
Abbildung 6.8.: Root-Objekte in Zope
127
128
7. Implementierung, Konfiguration
Feldtest
Basiskonfiguration gemäss Konzept

Anbindung von Modulen sicherstellen
Richtige Koniguration für Modulerweiterungen (keine Programmierung von Schnittstellen!)
evt. Events und Reaktionen
7.1. Erfüllung der Anforderungen
7.1.1. Kommunikation
E-Mail
Plone bietet in der Core-Version die Möglichkeit, den Link zu einem Artikel zu versenden und
dabei Empfänger-, Absenderadresse und Kommentar hinzuzufügen. Mit der Erweiterung AR-
MailServices 0.6 können die gewünschten Funktionen bereitgestellt werden.
ARMailServices 0.6 wird als Produkt installiert und erweitert jeden Artikel um eine Aktion zum
erweiterten Versenden. Standardmässig können nur Benutzer mit Verwaltungsrechte Mails
versenden, diese Einstellung kann über das ZMI oder das Installationsfile angepasst werden.
Zusätzlich ist ein Portlet (Classic Portlet > „portlet_mailservices“) verfügbar. Nach Installation
können Mails an Benutzer und Gruppen versendet werden können. Wird ARMailServices über
die Aktion aufgerufen, so wird der Link zum akutellen Artikel gleich in den Body-Text des E-
Mails eingefügt. Somit können Hinweise auf neue Informationen schnell an eine ganze Gruppe
versendet werden.
129
Abbildung 7.1.: Benutzerauswahl von ARMailServices 0.6
Kontaktmanagement
Plone bietet nur eine sehr oberflächliches Kontaktmanagement durch die Erfassung der Be-
nutzer, welche eine E-Mail-Adresse erhalten und zu einer oder mehreren Gruppen zugewiesen
werden können. Der Benutzer und die Gruppe dient zur Zugriffsregelung, ist jedoch nicht als
Kontaktverwaltung vorgesehen.
Bookmarks/Portal
Als klassisches CMS liefert Plone eine Portalseite mit, welche nach dem Einloggen die be-
nutzerspezifischen Inhalte anzeigt. Nebst der Inhaltsseite in der Mitte, gibt es verschiedene
Portlet-Positionen, auf welchen dynamische Erweiterungen angezeigt werden können.
130
7.1. Erfüllung der Anforderungen
Forum
Mailinglisten
Instant Messaging
Nachrichtenboard
Umfragen
7.1.2. Informations- und Datenmanagement
Dokumentemanagement
Versionierung
Stukturierung
Wissenserhaltung und Wissensfindung
7.1.3. Projektmanagement
Extreme Programming
* Project Multiple projects can be added by employees. For each project contact information
of team members, iterations and stories can be added by both the customers and employees.
* Iteration The project will be planned with iterations. An iteration is a period of 2 to 4 weeks
in which a number of stories will be implemented. * Offer Contains the stories that a customer
wants in this Project. It is used as a way to bundle the wishes of the client and give a first
indication of the size of a project. * Story The customer can define new features by describing
these feature in a story. * Task The employees can estimate the story by defining tasks.
131
132
8. Ausewrtung / Ausblick
Ideen für die Weiterentwicklung. Möglichkeiten.
Das Tool wird getestet und ausgewertet. Die beteiligten Personen werden befragt. Hier wird
auch erläutert, welche Erweiterungen noch implementiert werden müssen, damit das Tool den
Anforderungen einer modernen PM Plattform entspricht (und auch wie das gemacht werden
muss).
133
8. Ausewrtung / Ausblick
134
9. Schlussbemerkung
...
135
9. Schlussbemerkung
136
A. Literaturverzeichnis
[Agiles Manifest 2001] AGILES M ANIFEST: Manifesto for Agile Software Development. 2001. –
http://agilemanifesto.org
[AIIM 2008] AIIM: What is ECM? 08.06.2008, 2008. –

http://www.aiim.org.uk/publications/roadmap/index.asp
[Alpar u. a. 2005] A LPAR, Paul ; G ROB, Heinz L. ; W EIMANN, Peter ; W INTER, Robert: An-
wendungsorientierte Wirtschaftsinformatik. Vieweg Friedr. + Sohn Ver, 2005. – ISBN 978–
3528356569
[Applegate 2005] A PPLEGATE: Corporate Information Strategy and Management. Boston,

2005
[Bamberger 2005] B AMBERGER, Ingolf: Strategische Unternehmensberatung. Gabler Verlag,

2005. – ISBN 978–3409430654
[Beck 2005] B ECK, Kent: Extreme Programming Explained: Embrace Change. Addison-
Wesley Longman, 2005. – ISBN 978–0201616415
[Biethahn u. a. 2004] B IETHAHN, Jörg ; M UCKSCH, Harry ; RUF, Walter: Ganzheitliches Infor-
mationsmangement - Band I: Grundlagen. Oldenbourg, 2004. – ISBN 978–3486200201
[Borghoff u. Schlichter 1998] B ORGHOFF, Uwe M. ; S CHLICHTER, Johann H.: Rechnergestütz-

te Gruppenarbeit: Eine Einführung in verteilte Anwendungen. Springer Verlag, 1998. – ISBN
978–3540628736
[Brugger u. Soltermann 2004] B RUGGER, Marcel ; S OLTERMANN, Caroline: Informationsma-

nagement bei technisch-organisatorischen Veränderungen. Vdf Hochschulverlag, 2004
[Bundesamt für Statistik 2008] B UNDESAMT FÜR S TATISTIK: Unternehmen Indikatoren. Stand
30.06.2007, 2008. – http://www.bfs.admin.ch
137
[Chen u. a. 2002] C HEN, Fang ; J AY F. N UNAMAKER , J R ; N ICHOLAS C. R OMANO, J R ; R OBERT

O. B RIGGS: A Collaborative Project Management Architecture. IEEE, 2002 (Proceedings of
the 36th Hawaii International Conference on System Sciences)
[Cooper 1978] C OOPER, John D.: Corporate Level Software Management.

http://ieeexplore.ieee.org : IEEE Journal, 1978 (IEEE TRANSACTIONS ON SOFTWARE
ENGINEERING 4)
[Daenzer 2002] DAENZER, W: Systems Engineering. Zürich : Verlag industrielle Organisation,

2002
[Feldmüller u. a. 2004] F ELDMÜLLER, Dorothee ; F RICK, Andreas ; S EIBERT, Siegfried: Was

müssen IT-Projektmanager wirklich können? In: projekt MANAGEMENT (2004)
[Ferstl u. Sinz 2006] F ERSTL, Otto ; S INZ, Elmar: Grundlagen der Wirtschaftsinformatik. Ol-
denbourg, 2006. – ISBN 978–3486579420
[Fischer 2002] F ISCHER, Joachim: Bausteine der Wirtschaftsinformatik. 3. Schmidt (Erich),

2002. – ISBN 978–3503066100
[Frühauf u. a. 2001] F RÜHAUF, Karol ; L UDEWIG, Jochen ; S ANDMAYR, Helmut: Software-

Projektmanagement und -Qualitätssicherung. 4. Auflage. Zürich : vdf Hochschulverlag,
2001. – ISBN 978–3728128225
[Gaulke 2004] G AULKE, Markus: Risikomanagement in IT-Projekten. Oldenburg Wissenschaft-

licher Verlage, 2004. – ISBN 3–4862–7599–2
[Gloger 2008] G LOGER, Boris: Scrum. Produkte zuverlässig und schnell entwickeln. Hanser
Fachbuch, 2008. – ISBN 978–3446414952
[Heuberger 2008] H EUBERGER, Daniel: Authoring Tools zur Unterstützung

des kollaborativen Schreibens, Universität Zürich, Diplomarbeit, 2008. –
http://www.ifi.uzh.ch/mio/schwerpunkt/services/forschung/projects/studenttasks/index.html
[Hohmann 2007] H OHMANN, Luke: Innovation Games - Creating breakthrough Products

through collaborative Play. Addison Wesley, 2007. – ISBN 978–0321437297
[Huber 2007] H UBER, Andreas: Führung und Management von IT-Projekten: Projektetablie-
rung, Schaffung eines Projektrahmens. Vorlesung vom 31.10.2007, 2007
[Jankulik u. a. 2005] J ANKULIK, Ernst ; K UHLANG, Peter ; P IFF, Roland: Projektmanagement

und Prozessmessung. Wiley-VCH, 2005. – ISBN 978–3895782510
138
[Jenny 2005] J ENNY, Bruno: Projektmanagement - Das Wissen fur eine erfolgreiche Karriere.
vdf Hochschulverlag AG an der ETH Zürich / 2. Auflage, 2005. – ISBN 978–3–7281–3004–4
[Jung 2006] J UNG, Hans: Personalwirtschaft. Oldenbourg, 2006. – ISBN 978–3486580488
[Kampffmeyer 2006] K AMPFFMEYER, Ulrich: ECM Enterprise Content Management. Project

Consult, 2006. – http://www.project-consult.net/Files/ECM_White%20Paper_kff_2006.pdf
[Kessler u. Winkelhofer 2004] K ESSLER, Heinrich ; W INKELHOFER, Georg A.: Projektmanage-

ment - Leitfaden zur Steuerung und Führung von Projekten. Springer-Verlag GmbH, 2004.
– ISBN 3–5402–0444–X
[König 2008] KÖNIG, Jean-Pierre: Warum machst DU Scrum? Online, 2008. – http://inside-
scrum.blogspot.com
[Kuhnt 2007] K UHNT, Beate: Führung und Management von IT-Projekten / Schwerpunkt
mensch informatik organisation, Institut für Informatik, Universität Zürich. 2007. – For-
schungsbericht
[Lutz 2006] L UTZ, Mark: Programming Python. O’Reilly, 2006. – ISBN 978–0596009250
[Mangold 2002] M ANGOLD, Pascal: IT Projektmanagement kompakt. Spektrum Akademischer

Verlag, 2002. – ISBN 3–8274–1338–9
[Martelli 2006] M ARTELLI, Alex: Python in a Nutshell - A Desktop Quick Reference. O’Reilly,
2006. – ISBN 978–0596100469
[Mengelt 2008] M ENGELT, Flurin: Zusammenarbeit nach Scrum, Universität Zürich, Diplomar-
beit, 2008. – http://www.ifi.uzh.ch/mio/schwerpunkt/services/forschung/projects/studenttasks/index.html
[Noack 2007] N OACK, Sascha: ECM - Enterprise Content Management. GRIN Verlag, 2007.
– ISBN 978–3638644631
[Office2007 Blog 2008] O FFICE 2007 B LOG: Projekte managen, mit MS Office Groove 2007.
online, 2008. – http://www.office2007-blog.de
[Pichler 2007] P ICHLER, Roman: Scrum - Agiles Projektmanagement erfolgreich einsetzen.

dpunkt Verlag, 2007. – ISBN 978–3898644785
[Schiestl 1996] S CHIESTL, Josef: Groupware-Software für die Teamarbeit der Zukunft. Tectum
Verlag, 1996. – ISBN 978–3896089250
139
[Schopp 2008] S CHOPP, Bernd: Intranet Projekte mit SCRUM. Online, 2008. –
http://blog.namics.com
[Schwarzer 2006] S CHWARZER, S.: http://www.sschwarzer.net/python/perlpy_vortrag.html.

17.05.2008, 2006
[Spath u. a. 2007] S PATH, Dieter ; S CHIMPF, Sven ; K UGLER, Andreas: Webbasierte Open
Source Kollaborationsplattformen / Frauenhofer Institut für Arbeitswirtschaft und Organisa-
tion. 2007. – Forschungsbericht
[Specker 2004] S PECKER, Adrian: Modellierung von Informationssystemen. Ein methodischer

Leitfaden zur Projektabwicklung. Vdf Hochschulverlag, 2004. – ISBN 978–3728129840
[Sörensen 2007] S ÖRENSEN, Sven: Extreme Programming und Software-Qualität. GRIN Ver-
lag, 2007. – ISBN 978–3638655279
[Standish Group 2008] S TANDISH G ROUP: Chaos Report. Online, 2008. –

http://www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf
[Stoyan 2004] S TOYAN, Robert: Management von Webprojekten. Heidelberg : Springer Verlag,
2004. – ISBN 3–540–00582–X
[Thayer u. Yourdon 1997] T HAYER, Richard H. ; YOURDON, Edward: Software Engineering

Project Management. 1. IEEE Computer Society Prress, 1997. – ISBN 0818680008
[Vetter 1998] V ETTER, Max: Objektmodellierung. Teubner Verlag, 1998. – ISBN 978–
3519121435
[Wegmann u. Winklbauer 2006] W EGMANN, Christoph ; W INKLBAUER, Holger: Projektmana-

gement für Unternehmensberatungen. Gabler Verlag, 2006. – ISBN 978–3834902955
[Westphal 2001] W ESTPHAL, Frank: Extreme Programming. online, 2001. –

http://www.frankwestphal.de/ExtremeProgramming.html
[Zope Community 2008] Z OPE C OMMUNITY: Zope Book. Online, 2008. –

http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition
[Zope Group 2008] Z OPE G ROUP: http://www.zope.de/ueber-zope. Online, 2008
140
Abbildungsverzeichnis
1.1. Erfolg von IT-Projekten (Standish Group, 2008) . . . . . . . . . . . . . . . . . . 10
2.1. Aspekte der Qualität (Jankulik u. a., 2005) . . . . . . . . . . . . . . . . . . . . 14

2.2. Techniken der Kommunikation nach Kuhnt (2007) . . . . . . . . . . . . . . . . 15
2.3. Die 5 Komponenten von ECM (Kampffmeyer, 2006) . . . . . . . . . . . . . . . 17
2.4. Enterprise Content Management House nach Kampffmeyer (2006) . . . . . . . 18
2.5. Marktwirtschaftliche Unternehmen und Beschäftigte nach Grössenklassen, 2005
(Bundesamt für Statistik, 2008) . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6. Projektklassifikation anhand eines Kiviat-Diagramms nach Jenny (2005) . . . . 22
2.7. Teufelsquadrat nach (Daenzer, 2002) und (Jenny, 2005) . . . . . . . . . . . . . 27
3.1. Projektmanagement-System nach Jenny (2005) . . . . . . . . . . . . . . . . . 38

3.2. Regelkreis der Projektabwicklung nach Jenny (2005) . . . . . . . . . . . . . . . 40
3.3. Projektmanagement-Prozesse mit Schwerpunkten nach Specker (2004) . . . . 48
3.4. Scrum-Prozess nach Gloger (2008) . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5. Organisation und Scrum nach Gloger (2008) . . . . . . . . . . . . . . . . . . . 57
3.6. Drei parallele Prozesse nach Kuhnt (2007) . . . . . . . . . . . . . . . . . . . . 64
3.7. Wasserfallmodell nach Specker (2004) . . . . . . . . . . . . . . . . . . . . . . 66
3.8. Spiralmodell nach Specker (2004) . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.9. Lebensphasen eines Projektteams nach Brugger u. Soltermann (2004) . . . . . 71
5.1. Eignung der Tools nach Spath u. a. (2007) . . . . . . . . . . . . . . . . . . . . 96

5.2. Kiviatdiagramm der Top5 Tools und Plone nach Spath u. a. (2007) . . . . . . . . 97
5.3. Dateiverwaltung in Groove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.4. Kalender in Groove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.5. Issue & Task Tracker in Groove . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.6. Proposal Tracker in Groove . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.7. Project Status Report in Groove . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.8. Open Workbench Arbeitsbereich . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.9. Online Ordner History von Dropbox . . . . . . . . . . . . . . . . . . . . . . . . 107
141
Abbildungsverzeichnis
5.10.Online Versionierung von Dropbox . . . . . . . . . . . . . . . . . . . . . . . . 107

5.11.Lokale Ordner-Markierung von Dropbox . . . . . . . . . . . . . . . . . . . . . 107
5.12.Online File Browser von Syncplicity . . . . . . . . . . . . . . . . . . . . . . . . 108
5.13.Ordner Kennzeichnung mit Syncplicity . . . . . . . . . . . . . . . . . . . . . . 109
5.14.Lokale Datei-Markierung von Syncplicity . . . . . . . . . . . . . . . . . . . . . 109
5.15.Online Versionierung von Syncplicity . . . . . . . . . . . . . . . . . . . . . . . 110
5.16.Online Ordner-Administration von FolderShare . . . . . . . . . . . . . . . . . . 110
6.1. Ablauf einer Programmdatei . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.2. Eingabeaufforderung in der Kommandozeile . . . . . . . . . . . . . . . . . . . 115
6.3. Anweisungen in Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.4. Fallunterscheidung in Python . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.5. Conditional Expression in Python . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.6. For-Schleife in Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6.7. Zope Architektur (Zope Community, 2008) . . . . . . . . . . . . . . . . . . . . 127
6.8. Root-Objekte in Zope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.1. Benutzerauswahl von ARMailServices 0.6 . . . . . . . . . . . . . . . . . . . . 130
142
B. Innovationsspiele
Innovationsspiele werden dazu verwendet, auf spielerische Art und Weise Informationen zu
erarbeiten und die Bedürfnisse der Kunden besser zu verstehen. Diese Spiele können in Zu-
sammenarbeit mit den Teammitgliedern oder mit den Kunden erprobt werden. Sie werden
benutzt, um Produkt-Roadmaps zu erstellen, Verkauf und Marketing zu verbessern, Kunden-
beziehungen zu stärken, neue Geschäftsmöglichkeiten zu erforschen und um strategisch zu
planen (Hohmann, 2007).
Für die Erarbeitung der Anforderungen im Kapitel 4 wurden folgende Innovationsspiele ver-
wendet:
Buy a Feature: Ziel ist die Priorisierung der Features einer Software durch den Kunden.
Vorgehen: Eine Liste mit potentiellen Features wird erstellt und jedem Feature wird ein
Preis zugeordnet. Der Preis basiert zum Beispiel auf Entwicklungskosten oder auf Kun-
dennutzen. Die anwesenden Kunden können danach diese Features kaufen, haben aber
nur eine beschränkte Menge Geld zur Verfügung. Einige Features kosten jedoch mehr,
als ein einzelner Kunde zur Verfügung hat. Um dieses zu kaufen, müssen mehrere Kun-
den ihr verfügbares Geld zusammenlegen. Somit wird die Verhandlung innerhalb der
Kunden und die Kommunikation gefördert. Ideal ist eine Gruppe von ca. sieben Perso-
nen aus verschiedenen Aufgabenbereichen des Kunden.
Product Box: Ziel ist es, die wichtigsten Features eines Produkts zu erarbeiten.
Vorgehen: Alle Kunden erhalten eine leere Kartonbox und sollen sich vorstellen, sie
müssten diese Box, welche das System repräsentiert, nun verkaufen. Als Hilfe soll die
Box so verändert werden, dass der Kunde selbst sie kaufen würde. Danach muss er,
wie an einer Tradeshow oder auf dem öffentlichen Markt, seine eigene Box den übrigen
Anwesenden verkaufen. Der Projektleiter achtet hierbei auf die Fragestellungen, welcher
Kunde die Box kaufen würde, und warum.
Remember the Future: Ziel ist es, den Begriff des Erfolgs für den Kunden zu verstehen.
Jeder Kunde erhält ein paar Blätter Papier und soll sich vorstellen, er befinde sich in
143
B. Innovationsspiele
der Zukunft - ein paar Monate, ein paar Jahre, je nachdem was der Projektleiter her-
ausfinden möchte. Nun soll er so detailliert wie möglich aufschreiben, was das Produkt
dazu beigetragen hat, dass sich der Kunde gut fühlt (dieses Spiel kann mit diversen Ad-
jektiven gespielt werden, z.B. erfolgreich, glücklich, sicher, . . . ). Wichtig ist die Art der
Fragestellung: es ist ein grundlegeneder Unterschied ob man fragt „Was soll das System
tun?“ oder „Was hat das System getan?“.
Spider Web: Ziel ist es, Beziehungen des Produktes zu verstehen.

Auf einer grossen leeren Fläche wird der Produktname in die Mitte geschrieben. Nun
sollen alle Kunden weitere Stichwörter hinzufügen, die in irgend einer Beziehung zum
Produkt stehen (Dienste, Firmen, Personen, physische Objekte, . . . ). Dabei sollen wich-
tige Verbindungen durch unterschiedlich starke Linien hervorgehoben werden oder ähn-
liche Verbindungen, z.B. gewinnbringende, durch einheitliche Farben markiert werden.
Alle Beziehungen werden danach in der Gruppe erläutert.
20/20 Vision: Ziel ist es, die Features nach Wichtigkeit zu ordnen.
Vorgehen: Der Projektleiter notiert alle Features eines Produktes auf Karten, eine Karte
pro Feature. Er durchmischt den Stapel und hängt das erste Feature an eine Pinnwand.
Für das zweite Feature muss der Kunde entscheiden, ob dieses wichtiger oder weniger
wichtig als das erste Feature ist. Der Projektleiter hängt das Feature danach oberhalb
(wichtiger) oder unterhalb (weniger wichtig) der ersten Karte auf. Sind alle Karten durch-
gespielt, resultiert daraus eine Reihenfolge aller Features nach Wichtigkeit geordnet.
144

Diplomarbeit

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Diplomarbeit

Cargado por

Copyright:

Formatos disponibles

Diplomarbeit

Grundmodul einer Plattform für

Datum der vorliegenden Version:

2. Grundlagen und Begriffe 13

3. Theorie des Projektmanagements 33

4. Anforderung an eine moderne PM-Plattform 79

5.4.5. IGSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6. Software Plattform 113

6.3.3. Arbeitsablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

7. Implementierung, Konfiguration 129

8. Ausewrtung / Ausblick 133

Although the need is apparent, there appears to be precious little in-

Abbildung 1.1.: Erfolg von IT-Projekten (Standish Group, 2008)

Zusammenarbeit nach der agilen Projektmanagementmethode „Scrum“ (Mengelt, 2008) so-

1.5. Aufbau der Arbeit

2.1. Allgemeine Begriffe

Abbildung 2.1.: Aspekte der Qualität (Jankulik u. a., 2005)

2.1.2. Kommunikationsräume und -techniken

Die Theorie der Kommunikationsräume umfasst sechs Dimensionen:

zeitlich: Dauer des Dialogs sowie Häufigkeit (einmalig, wiederkehrend)

sprachlich: gemeinsame und funktionale Sprache

Organisation des Dialogs: Gesprächsart (Plenum, Teilgruppen), Art der Gesprächsführung

Abbildung 2.2.: Techniken der Kommunikation nach Kuhnt (2007)

2.1.3. CSCW und Groupware

CSCW (Computer Supported Collaborative Work) beschreibt das universelle Arbeitsgebiet

Bilaterale vs. Multiple Kooperation: Anzahl der Beteiligten Kommunikationspartner

Enterprise Content Management (ECM) is the term used to describe

Abbildung 2.3.: Die 5 Komponenten von ECM (Kampffmeyer, 2006)

• DM Document Management (DMS, Dokumentenmanagement)

• Collaboration (die Zusammenarbeit unterstützende Software, Groupware)

• WCM Web Content Management (einschliesslich Portale)

• RM Records Management (Archiv- und Ablageverwaltungssysteme)

• Workflow / BPM Business Process Management (Vorgangsbearbeitung)

bilden die eigentlichen „Manage“-Komponenten, welche die ECM-Komponenten zusammen

Abbildung 2.4.: Enterprise Content Management House nach Kampffmeyer (2006)

Abbildung 2.5.: Marktwirtschaftliche Unternehmen und Beschäftigte nach Grössenklassen,

• Autonomie der Unternehmung

• Fähigkeit zur Erbringung individualisierter, differenzierter Leistung

• geringer Formalisierungsgrad, vorherrschen von informellen Kommunikationskanälen

• vorherrschende Leitungsstruktur in Form eines auf den Unternehmer abgestimmten Ein-

• Entscheidungszentralisation, die auch Routineentscheidungen umfasst

Projekte sind in sich abgegrenzte, komplexe und/oder komplizierte Auf-

hohe Komplexität: „Die zu bewertenden Kriterien sind hauptsächlich der Gesamtaufwand,

Nach Frühauf u. a. (2001) ist ein Projekt

A temporary activity that is characterized by having a start date, spe-

2.2.2.1. Klassifikation nach Wichtigkeit

Abbildung 2.6.: Projektklassifikation anhand eines Kiviat-Diagramms nach Jenny (2005)

Im klassischen Projektmanagement werden Projekte also hauptsächlich nach Dimensionen,

• die Komplexität, Vielfalt und Dynamik des Umfeldes des Projektes

• projekttypische Merkmale, wie Innovationsgrad, Terminkritikalität und Komplexität der

• Grad der Auswirkung der Projektziele

2.2.2.2. Klassifikation nach Zeitpunkt und Bedeutung

2.2.2.3. Klassifikation nach Projekttypen

A: Auftragsprojekt: Es gibt einen klassischen Auftragnehmer und einen Auftraggeber. Der

C: Entwicklungsprojekte: Der dritten Gruppe gehören eigens entwickelte Softwarepakete

Projektdauer: Die Projektdauer wiederspiegelt den Gesamtaufwand in einem Projekt und

2.2.3. Risiken eines Projekts

Nach (Jenny, 2005) verkörpern „Projektrisiken [. . . ] den potenziellen Schaden (materiell/kör-

Konsens: Auftraggeber und Auftragnehmer arbeiten aneinander vorbei, da das Verständnis

Das magische Dreieck

Notwendigkeit des Risikomanagements

siehe (Gaulke, 2004), Seite 11/12 –> folgt

2.2.4. Steuerbarkeit eines Projekts