Diplomarbeit

Diplomarbeit
Grundmodul einer modernen Projektmanagement

Plattform
Deborah Weber
Arth, Switzerland
Datum der vorliegenden Version:

21. August 2008
Abgabetermin:
4. September 2008
Dr. Andreas Huber, Prof. Dr. Helmut Schauer

Universtiät Zürich
Institut für Informatik
Diploma Thesis
Educational Engineering Group
Department of Informatics (IFI)
University of Zurich
Binzmühlestrasse 14, CH-8050 Zurich, Switzerland
URL: http://www.ifi.uzh.ch/ee/index.html
ii
Zusammenfassung
folgt
iii
Abstract
v
Inhaltsverzeichnis
1. Einleitung 1
1.1. Ausgangslage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. Zielgruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Grundlagen und Begriffe 3

2.1. Allgemeine Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Qualität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2. Kommunikationsräume und -techniken . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.3. CSCW und Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.4. ECM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.5. KMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. IT-Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Projektklassifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2.1. Klassifikation nach Wichtigkeit . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2.2. Klassifikation nach Zeitpunkt und Bedeutung . . . . . . . . . . . . . . . 11
2.2.2.3. Klassifikation nach Inhalt . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2.4. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Kontrolle eines Projekts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4. Steuerbarkeit eines Projekts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4.1. Das Teufelsquadrat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.4.2. Direkt wirksame Steuerung . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.4.3. Indirekt wirksame Steuerung . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.4.4. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.5. Erfolgsfaktoren eines Projekts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3. Methoden des Projektmanagements 17

3.1. Allgemeines Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1. Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.2. Rollen und Gremien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.3. Informationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.4. Dokumentationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.5. Sachmittelsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
vii
Inhaltsverzeichnis
3.2. Projektmanagement nach Jenny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1. Projektinstitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2. Projektabwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.2.1. Projektführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3. Projektmanagement-Systemelemente . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3.1. Projektportfoliomanagement . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.3.2. Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3.3. Qualitätsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3.4. Teammanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3.5. Konfigurationsmanagement . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Projektmanagement nach Specker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1. Projektmanagementfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2. Projektmanagementtätigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Agiles Projektmanagement: SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1. Projektmanagement in Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.2. SCRUM-Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.2.1. Product Owner - der Visionär . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.2.2. SCRUM Team - die Lieferanten . . . . . . . . . . . . . . . . . . . . . . 32
3.4.2.3. SCRUM Master - der Change Agent . . . . . . . . . . . . . . . . . . . . 32
3.4.2.4. Weitere Rollen im Scrum-Prozess . . . . . . . . . . . . . . . . . . . . . 33
3.4.3. Artefakte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.3.1. Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.3.2. Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.3.3. Burndown Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.3.4. Impediment List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.4. Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.4.1. Planungssitzung 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.4.2. Planungssitzung 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.4.3. Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.4.4. Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.4.5. Sprint Retrospektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5. MIO Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.1. Managementprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.2. Führungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6. Produktentwicklungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6.1. Wasserfallmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.2. Spiralmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6.3. Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6.4. Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.6.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7. Prozessintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7.1. Projektmanagement-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
viii
Inhaltsverzeichnis
3.7.2. Führungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.8. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4. Anforderung an eine moderne PM-Plattform 51

4.1. Randbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1. Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.2. Erweiterbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1.3. Vernetzt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1.4. Mehrsprachig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2. Kommunikation und Zusammenarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.1. E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.2. Kontaktmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.3. Bookmarks/Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.4. Forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.5. Instant Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.6. Nachrichtenboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.7. Umfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3. Informations- und Datenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.1. Dokumentemanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.2. Versionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.3. Strukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.4. Wissenserhaltung und Wissensfindung . . . . . . . . . . . . . . . . . . . . . . . 57
4.4. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.1. Termine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4.2. Management von Input und Output . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4.3. Ressourcenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.4. Aufgabenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.5. Änderungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4.6. Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5. Tool-Evaluation 61
5.1. Toolauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.1. PHProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.1.2. Open-Xchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.1.3. eGroupWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.1.4. Simple Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.1.5. IGSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.6. Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2. Kommunikation und Zusammenarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3. Informations- und Datenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5. File Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.5.1. Dropbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
ix
Inhaltsverzeichnis
5.5.2. Syncplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.5.3. Windows Live FolderShare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.6. Microsoft Produkte und Alternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.6.1. Kommunikation und Zusammenarbeit . . . . . . . . . . . . . . . . . . . . . . . . 75
5.6.1.1. Office Groove 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.6.1.2. Alternative zu Groove . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.6.2. Informations- und Datenmanagement . . . . . . . . . . . . . . . . . . . . . . . . 76
5.6.2.1. Microsoft Windows SharePoint Services (WSS) . . . . . . . . . . . . . . 76
5.6.2.2. Alternative zu Sharepoint . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.6.3. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.6.3.1. Microsoft Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.6.3.2. Open Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.7. Produktentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.7.1. Eclipse IDE mit PyDev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.7.2. WingIde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.7.3. Komodo Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6. Software Plattform 85
6.1. Programmiersprache Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.1. Vorteile von Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.2. Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.1.3. Konzept und Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.1.4. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2. Applikationsserver Zope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2.1. Konzept von Zope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2.2. Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2.2.1. ZMI - Zope Management Interface . . . . . . . . . . . . . . . . . . . . . 91
6.2.2.2. ZODB - Zope Object Database . . . . . . . . . . . . . . . . . . . . . . 91
6.2.2.3. Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2.3. Zope Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.2.4. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.3. CMS Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3.1. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3.2. Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3.2.1. Artikel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3.2.2. Ansichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.3.3. Arbeitsablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.3.4. Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.3.5. Benutzerberechtigungen und Funktionen . . . . . . . . . . . . . . . . . . . . . . 101
6.3.6. Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3.7. Plone Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7. Implementierung, Konfiguration 103

7.1. Erfüllung der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
x
Inhaltsverzeichnis
7.1.1. Kommunikation und Zusammenarbeit . . . . . . . . . . . . . . . . . . . . . . . . 103

7.1.2. Informations- und Datenmanagement . . . . . . . . . . . . . . . . . . . . . . . . 105
7.1.3. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
7.1.4. Änderungsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.2. Feldtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.2.1. Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.2.2. eXtreme Management 1.5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
7.3. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8. Ausewrtung / Ausblick 111
9. Schlussbemerkung 113
A. Literaturverzeichnis 115
B. Innovationsspiele 121
C. Planung mit Scrum 123

C.1. Sprint 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
C.2. Sprint 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
C.3. Sprint 03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
C.4. Agiles Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
D. Toolspezifikation 129
D.1. Toolauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
D.2. PHProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
D.3. Open-Xchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
D.4. eGroupWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
D.5. Simple Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
D.6. IGSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
D.7. Microsoft Groove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
D.8. Microsoft Windows SharePoint Services (WSS) . . . . . . . . . . . . . . . . . . . . . . 149
D.9. Microsoft Office Project 2007 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
D.10.PyDev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
D.11.Wing IDE 101 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
D.12.Komodo Edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
xi
Inhaltsverzeichnis
xii
1. Einleitung
1.1. Ausgangslage
Although the need is apparent, there appears to be precious little innovative ac-
tivity in the area of software management. Perhaps this is so because computer
scientists believe that management per se is not their business, and the mana-
gement 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 con-
ducted. In short, there are many challenges and opportunities for initiatives in
software 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 Projektmanagement
und entsprechende Unterstützung durch geeignete Tools.
Projektmanagement ändert sich in der heutigen Zeit aufgrund der erhöhten Anzahl von verteilten Pro-
jekten 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überwachung gelegt werden (Chen u. a., 2002).
Abbildung 1.1.: Erfolg von IT-Projekten (Standish Group, 2008)
1
1. Einleitung
1.2. Aufgabenstellung
Der Schwerpunkt mensch | informatik | organisation (MIO) am Institut für Informatik der Universität
Zürich beschäftigt sich mit der Führung und dem Management komplexer IT-Projekte. Zur Unterstützung
der entwickelten Methoden wurden eine eigene Lernumgebung und verschiedene 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 funktional perfor-
mant sein und die Prozessdifferenzierung des MIO-Ansatzes unterstützen. Durch ein einfaches Hand-
ling, Skalierbarkeit und Erweiterbarkeit soll die Plattform sich für das Management 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 zu-
kunftsträchtige und innovative Plattform mit einer starken Community im Hintergrund. 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 Zusam-
menarbeit nach der agilen Projektmanagementmethode „Scrum“ (Mengelt, 2008) sowie eines Autho-
ring 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 Projektleiter
genauso wie an Entwickler und Manager. Sie vertieft den Ansatz, dass für ein erfolgreiches Projekt-
management 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 Projektmanagementmethoden mit Fokus auf die ökonomi-
schen 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 Projek-
ten. Im Kapitel 3 folgt die Theorie des klassischen wie auch des agilen Projektmanagements. Ebenso
wird hier der MIO-Ansatz erläutert. Darauf folgt im Kapitel 4 die Anforderungsanalyse an eine moder-
ne Plattform, welche zugleich aktuell und innovativ sein soll. Als Erweiterung dazu werden im Kapitel
5 unterschiedliche Tools für die einzelnen Prozesse evaluiert und deren Eignung für eine moderne
Management-Plattform geprüft. Kapitel 6 bereitet den Leser mit technischem Hintergrund zum Appli-
kationsserver „Zope“, der Programmiersprache „Python“ und dem ECMS „Plone“ auf die Konfiguration
des Grundmoduls vor. Die genaue Parametrisierung und Konfiguration sowie Roadmap für weitere Re-
leases folgt in Kapitel 7. Kapitel 8 hinterfragt kritisch den Erfolg einer modernen Projektmanagement-
Plattform mit „Plone“.
2
2. Grundlagen und Begriffe
In diesem Kapitel werden die grundlegenden Begriffe und Eigenschaften von Projekten erläutert. Das
IT-Projektmanagement wird in der Literatur seit gut 50 Jahren erläutert. So gross die Anzahl von Litera-
tur 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 Projektmanagement 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 projektrelevanten 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 grundlegend für ein
erfolgreiches Projektmanagement sind. Um Kriterien für die Unterscheidung der Plattformen zu ver-
stehen, 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 informationstech-
nische Konzepte von CSCW/Groupware erläutert, deren Ideen und Grundkonzepte für eine moderne
Projektmanagement-Plattform adaptiert werden. Als Abschluss folgt die Definition 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 Unternehmen 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 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 unterschiedlichen Aspekten bezüglich Produkte, Prozesse und Potential (siehe
Abbildung 2.1, S. 4). 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, festgelegte und vorausgesetzte Erfordernisse zu erfüllen (ISO 8402).
2.1.2. Kommunikationsräume und -techniken
Die Theorie der Kommunikationsräume umfasst sechs Dimensionen:
3
Abbildung 2.1.: Aspekte der Qualität (Jankulik u. a., 2005)
personell: Anzahl der beteiligten Personen sowie deren Rollen, Interessen, Heterogenität und Ge-
schlecht
zeitlich: Dauer des Dialogs sowie Häufigkeit (einmalig, wiederkehrend)
räumlich: Grösse und Klima des Raumes sowie Ausstattung, Anordnung der Plätze und strategische
Platzierung der Leitung
kulturell: Werte und Regeln, Art (Dialog, Diskussion, Präsentation) sowie Sitten und Gebräuche (Pünkt-
lichkeit, 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).
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 Sy-
stemlösungen beschreibt (Borghoff u. Schlichter, 1998). Da kooperatives Arbeiten nicht nur die gemein-
schaftliche Erledigung von Sachaufgaben bedeutet, sondern auch Koordination und Kommunikation
(Interaktion) zwischen den beteiligten Aufgabeträgern einschliesst, verlangt es nach einer besonde-
ren 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 Nut-
zung durch mehrere Aufgabenträger. Groupware erlaubt, Informationen und sonstige Materialien auf
elektronischem Wege zwischen den Mitgliedern einer Gruppe koordiniert auszutauschen oder gemein-
same Materialien in gemeinsamen Speichern koordiniert zu bearbeiten (Schiestl, 1996).
In der Kooperation lassen sich drei sich gegenseitig ausschliessende Dimensionen unterscheiden, wo-
bei vorwiegend die dritte Dimension zur Klassifizierung von Groupware-Anwendungen verwendet wird
((Borghoff u. Schlichter, 1998), (Fischer, 2002)):
4
Abbildung 2.2.: Techniken der Kommunikation nach Kuhnt (2007)
Bilaterale vs. Multiple Kooperation: Anzahl der Beteiligten Kommunikationspartner
Konjunktive vs. Disjunktive Kooperation: Ausführung der Handlung durch einen (disjunktiv) oder
durch beide Beteiligten
Unmittelbare vs. Mittelbare Kooperation: Räumliche und zeitliche Trennung der Kooperationspart-
ner
2.1.4. ECM
Enterprise Content Management (ECM) is the term used to describe the techno-
logies, tools, and methods used to capture, manage, store, preserve, and deliver
„content“ or „information“ across an enterprise or organization. At the most ba-
sic level, ECM tools and strategies allow the management of an organization’s
unstructured information, wherever that information exists. Unstructured informa-
tion 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 einheitlich
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 Inhalt (Content) in strukturierter,
schwach strukturierter oder unstrukturierter Form vor. Der Grad der Struktur hängt hierbei mit der ver-
fügbaren Meta-Information und der Trennung von Layout und Inhalt zusammen. Diese Trennung ist
wichtig, weil Meta-Informationen für die elektronische Verwaltung und Kontrolle von Inhalten benötigt
werden.
5
Abbildung 2.3.: Die 5 Komponenten von ECM (Kampffmeyer, 2006)
5 Komponenten-Modell
Die wichtigsten ECM-Komponenten und -Technologien lassen sich gemäss Kampffmeyer (2006) (siehe
Abbildung 2.3, S. 6) in die fünf Hauptkategorien Erfassung, Verwaltung, Speicherung, Ausgabe und
Sicherung einordnen. Die bisherigen Anwendungsfelder
• 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 al-
ternativ einsetzen. Das von der AIIM im Jahre 2005 veröffentlichte „Enterprise Content Management
House“ (siehe Abbildung 2.4, S. 7) stellt die Komplexität und den Funktionsumfang von Enterprise Con-
tent Management dar. Informationen werden dabei als Ein- und Ausgang dargestellt, das Business
Process Management als verbindenden Aufzug zwischen den Stockwerken.
2.1.5. KMU
Als kleine und mittlere Unternehmen gelten Unternehmen mit bis zu 250 Mitarbeitenden, einem Um-
satz 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 Mitarbeitern) 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
6
Abbildung 2.4.: Enterprise Content Management House nach Kampffmeyer (2006)
Abbildung 2.5.: Marktwirtschaftliche Unternehmen und Beschäftigte nach Grössenklassen in der

Schweiz, 2005 (Bundesamt für Statistik, 2008)
7
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. 7). Ein
solches Unternehmen benötigt trotz dem geringen Formalisierungsgrad, einer schlanken Organisati-
onsstruktur und der zentralisierten Entscheidungsstelle für die Durchführung Ihrer Projekte ein profes-
sionelles Projektmanagement.
2.2. IT-Projektmanagement
Die Führung eines Projektes wird als Projektmanagement bezeichnet (Jenny, 2005). Dazu abzugren-
zen ist das Projektmanagement-System, welches gemäss DIN 69905 ein organisatorisch abgegrenztes
Ganzes ist, welches durch das Zusammenwirken seiner Elemente in der Lage ist, Projekte vorzube-
reiten und abzuwickeln. Die Elemente dieses Systems sind einzelne Disziplinen, die in einem Projekt
von den jeweiligen Rollen berücksichtigt und beherrscht werden müssen. Somit können in ein moder-
nes Projektmanagement auch die Prozesse der Führung und der Produktentwicklung mit einbezogen
werden.
Viele Begriffe aus dem Umfeld des Projektmanagements werden unterschiedlich definiert und verwen-
det. Dieses Kapitel soll dazu dienen, die in dieser Arbeit verwendeten Begriffe von einer allgemeingül-
tigen Definition abzugrenzen.
2.2.1. Projekt
Bei der Literatursuche nach der Erklärung des Begriffs „Projekt“ stellt man schnell fest, dass keine ein-
heitliche Definition möglich ist, sich die meisten Erklärungen in den wichtigsten Punkten 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ühauf u. a. (2001), Mangold (2002)). Ein Pro-
jekt 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 de-
finieren. Jenny (2005) definiert ein Projekt wie folgt:
Projekte sind in sich abgegrenzte, komplexe und/oder komplizierte Aufträge, de-

ren Erfüllung eine Organisation bedingt, die für die Umsetzung der Tätigkeiten
eine Projektmethode anwendet, mit der alle anfallenden Arbeiten geplant, ge-
steuert, durchgeführt und kontrolliert werden können.
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 entscheidend,
„dass bei einem solchen Vorhaben von Anfang an ein Ziel festgelegt und kommuniziert wird,
so dass alle Projekbestrebungen auf die Erreichung eines derzeit aktuellen Ziels ausgerichtet
werden können.“
begrenzt: Ein Projekt ist im Bezug auf Zeit, Kosten und Ressourcen begrenzt. Die Anforderungen
an ein Projekt legen die inhaltlichen Grenzen fest, welche nötig sind, um ein Endergebnis zu
definieren und zu erreichen.
8
individuell: Ein Projekt zeichnet sich durch seine Individualität aus. „Projekte sind nie Routinetätigkei-
ten. 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 not-
wendige Know-how und die Risiken, die das Projekt mit sich bringt.“ Wird das Projekt als ein
dynamisches System betrachtet, so steigen mit der Zunahme von Beteiligten und Dauer die Viel-
falt der sich wandelnden Elemente und ihre Wechselwirkungen (Kuhnt, 2007). Mit der Dauer
verändern sich die Beziehungen, und ein konstanter Wandel kann sich in fundamentale Verän-
derungen ausweiten.
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 be-
grenzter 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, specific objec-

tives 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 pro-
ject.“
Ein IT-Projekt ist im Allgemeinen ein Projekt mit einem verstärkten Bezug zur Informationstechnologie
und zur Entwicklung. Einfach gesagt ist ein IT-Projekt ein Projekt, welches als Lieferobjekt ein Stück
Software beinhaltet (Client/Server-, Webapplikation, . . . ).
Für diese Arbeit wird zusammengefasst die folgende Definition für ein Projekt verwendet:
Ein Projekt ist ein einmaliges Vorhaben mit einem klaren Start- und Enddatum,
einer eindeutigen Zielsetzung und begrenzten Ressourcen. Aufgrund seiner In-
dividualität ist für die erfolgreiche Abwicklung eine Organisation, Planung und
Kontrolle nötig.
2.2.2. Projektklassifizierung
Die Klassifizierung von Projekten beeinflusst die Wahl der Projektmanagement-Methode sowie die
Ressourcenplanung. Im Verlaufe der Zeit festigten sich die traditionellen Klassifizierungskriterien 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 unternehmensintern standardisiert und Projekte nach gleichen Kriterien
bewertet werden.
9
2.2.2.1. Klassifikation nach Wichtigkeit
Jenny (2005) stuft Projekte nach Wichtigkeit in vier Klassen (A − D) ein, wobei A die höchste Wichtig-
keit besitzt. Mögliche Einstufungskriterien sind Strategieeinfluss, Organisationsveränderung, Effizienz,
Komplexität, Kosten, Intensität der Projektabwicklung, Risiko oder Wirtschaftlichkeit, welche mit kon-
kreten Zahlenwerten oder durch eine verbale Gewichtung (hoch/mittel/tief) skaliert werden. Nebst der
Abbildung 2.6.: Projektklassifikation anhand eines Kiviat-Diagramms nach Jenny (2005)
Einstufung nach Wichtigkeit ist jedoch eine zusätzliche Einstufung nach Dringlichkeit notwendig. Die
Einstufung wird aufgrund der gleichen Kriterien für alle Projekte eines Unternehmens vorgenommen.
Dabei ist zu beachten, dass die Klassifikation 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 aufgrund anders gewichteter Kriterien als ein A- oder ein C-Projekt eingestuft werden.
Anhand eines Kiviat-Diagramms (siehe Abbildung 2.6, S. 10) kann die Projektklassifikation nach Krite-
rien visualisiert werden.
Auch Specker (2004) stuft Projekte in Kategorien anhand der Kriterien Umfang, organisatorische Kom-
plexität, Komplexität des Kundenproblems, Know-How und Technologiekomplexität ein. Dabei entste-
hen drei Kategorien A−C. Er weist darauf hin, dass auch in kleineren und weniger komplexen Projekten
alle Aspekte des Projektmanagements wahrzunehmen wären.
Im traditionellen Projektmanagement werden Projekte also hauptsächlich nach Dimensionen, fachli-

chen Inhalten, messbaren Grössen und Vorgehensphilosophie kategorisiert (Kessler u. Winkelhofer,
2004). Kessler selbst unterscheidet Projekt anhand folgender Kriterien:
• die Komplexität, Vielfalt und Dynamik des Umfeldes des Projektes

• projekttypische Merkmale, wie Innovationsgrad, Terminkritikalität und Komplexität der Projektzie-
le
• die Struktur des Projektes, die sich aus der Grösse ergibt und
• Grad der Auswirkung der Projektziele
10
2.2.2.2. Klassifikation nach Zeitpunkt und Bedeutung
Applegate (2005) unterscheidet Projekte nach Zeitpunkt und Bedeutung aus Unternehmenssicht (vgl.
auch Kuhnt (2007)).
Strategische Projekte sind kritisch für die Unternehmensstrategie und benötigen eine zentrale Pla-
nung. Die Erreichung der Ziele ist für das Unternehmen von hoher Bedeutung und bringt einen Mehr-
wert in der Zukunft.
High Potential Projekte können den Erfolg eines Unternehmens in der Zukunft möglicherweise ent-
scheidend 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 Unterstü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 Inhalt
Frühauf u. a. (2001) teilt Projekte grob in drei Gruppen anhand deren typischen Inhalts.
A: Auftragsprojekt: Es gibt einen traditionellen Auftragnehmer und einen Auftraggeber. Der Auftrag-
nehmer 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.
B: Interne Projekte: Unternehmensintern wird ein IT-Projekt für den Eigenbedarf entwickelt. Auftrag-
nehmer 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 Problem-
stellungen 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), Kessler u. Win-
kelhofer (2004), Frühauf u. a. (2001)). Dabei werden diese Merkmale je nach Bereich des Projektes und
Grösse und Art des Unternehmens unterschiedlich stark gewichtet sowie fortlaufend angepasst oder
neu definiert. Wichtige und für ein Unternehmen kritische Projekte benötigen einen höheren Admini-
strationsaufwand und bessere Kontrollen. Dem gegenüber werden bei internen oder unterstützenden
Projekten die Tätigkeiten des Projektleiters auf ein Minimum reduziert.
Die richtige Klassifikation ist wichtig, um die geeignete Projektmanagement-Methode zu wählen und
die Dokumentation und Planung in angemessenem Umfang zu erstellen (vgl. Tabelle 3.2). Im Bereich
11
von KMUs wird der Fokus auf die Überwachung von strategischen und kritisch-operativen Auftrags-
projekten aus allen Wichtigkeitsbereichen gesetzt. Für diese Arten von Projekten wird in Kapitel 4 ein
Anforderungskatalog erstellt.
2.2.3. Kontrolle eines Projekts
Das Risikomanagement steht in engem Zusammenhang mit dem Projektmanagement und dem Con-
trolling. Nach Gaulke (2004) steigt seine Bedeutung mit zunehmender Grösse und Komplexität von
Projekten und hängt auch mit der Automatisierung von Geschäftsprozessen und der Öffnung der Un-
ternehmenssysteme für Partner und Kunden ab. Unter zunehmendem Wettbewerbsdruck spielt die
Automatisierung und das damit verbundene Risiko durch unterlassene Kontrolle der Vorgänge eine
wichtige Rolle.
Das magische Dreieck

Unter dem magischen Dreieck versteht man das Management und die Kontrolle der ökonomischen
Prozessziele Leistung, Zeit und Kosten. Wird eine Komponente verändert, so müssen sich automa-
tisch 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äs-
sigung anderer wichtiger Faktoren wie Qualität, Erfolgsfaktoren, soziale Führung und Produktentwick-
lung. 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).
Traditionelles Projekt-Controlling überwacht hierbei nur die obigen drei Prozessziele. Dass dies in der
heutigen Zeit nicht mehr ausreicht, bräuchte nicht explizit erwähnt zu werden, da wichtige Bereiche wie
Zusammenarbeit, soziale Führung und die sozialen Erfolgsfaktoren (vgl. Kapitel 2.2.5) fehlen.
2.2.4. Steuerbarkeit eines Projekts
Die Projektsteuerung umfasst alle projektinternen Aktivitäten des Projektleiters,

die notwendig sind, um das geplante Projekt innerhalb der Planungswerte abzu-
wickeln und erfolgreich durchzuführen (Jenny, 2005).
Klar definierte Ansprechpartner in jeder Disziplin eines Projektes und ein grundlegendes Verständnis
der Vorgehensweisen wie auch die richtige Beurteilung und Einschätzung von Aufgaben sind Grund-
voraussetzung zur Steuerung eines Projekts (Stoyan, 2004). Nach Jenny (2005) ist für die Steuerung
eines Projektes nebst brauchbaren Planungsvorgaben auch ein geeignetes Messverfahren zur Pro-
jektkontrolle notwendig, um mögliche Abweichungen festzustellen. 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 er-
füllen:
• Klare Bestimmung des Projektumfangs

• Klare Projektabwicklungsziele
• Genau definierte Projekteinflussgrössen
12
• 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 Steue-
rungsmassnahmen meist mehr als eine der Projektgrössen Kosten, Leistung, Termin und Qualität be-
trifft. Das Teufelsquadrat (siehe Abbildung 2.7, S. 13) zeigt auf, wie sich Änderungen an einer Pro-
jektgrösse auf den ganzen Rahmen auswirken. Für eine Optimierung stehen dem Projektleiter im Vor-
aus 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 Planung und
der Gegenwart sowie auf die Differenzen, welche durch den Vergleich des geplanten und des erstellten
Lieferobjekts aufgedeckt wurden. Eine nicht abschliessende Liste von Projektführungstätigkeiten für die
direkt wirksame Steuerung gibt uns Jenny (2005):
Projektkoordination: Sind viele der Projektbeteiligten an mehreren unterschiedlichen Projekten be-

teiligt, so müssen Einzelaktivitäten auf die Projektziele ausgerichtet und aufeinander abgestimmt
sein.
Risikoverfolgung: In periodischen Intervallen sollen die Projektrisiken und die Erfolgsfaktoren über-
prüft und wenn nötig erweitert werden.
Steuerung von Aufwand und Zeit
Aufwand und Termineinhaltung werden durch Schätzung und Projektplan festgelegt. Die regelmässi-
ge 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 festgestellt und die erforderlichen Massnahmen eingeleitet werden. Weicht der Projektstand auf-
grund von Änderungen der Projektziele ab, so müssen Schätzung und Projektplan neu erstellt werden.
13
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 kontrolliert werden. Wer-
den 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 er-
forderlichen 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, inner-
halb eines Projekts alle Risiken zu vermeiden. Wichtig jedoch ist, diese frühzeitig zu identifizieren und
auf der Ebene der Entscheidungsträger zu lösen.
Steuerung von Abhängigkeiten
Aus Kundensicht können durch Abhängigkeiten von einem Dienstleister schnell hohe Kosten entste-
hen. Durch das Abliefern von Teilergebnissen, der Wahl einer verbreiteten Technologie und der Betei-
ligung und Einarbeitung kundenseitiger Mitarbeiter kann die Höhe der Wechselkosten und somit die
Abhängigkeit vom Dienstleister verringert werden. Auf Dienstleistersicht sind vorwiegend projektexter-
ne 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 Projektleiter die
Möglichkeit der indirekt wirksamen Steuerung zur Verfügung. Dazu gehören langfristige Motivations-
faktoren, Mitarbeiterbeurteilung und -förderung sowie der Einsatz des geeigneten Führungsstils und
-verhaltens. Als Projektführungstätigkeiten für die indirekt wirksame Steuerung gilt nach Jenny (2005)
das Projektmarketing. Es ist ein wichtiger Teil des Stakeholder-Managements und baut auf ähnlichen
Kriterien und Theorien wie das Produktmarketing auf. Durch Information können Widerstände gegen
das Projekt abgebaut und eine positive Haltung gegenüber dem Projekt geschaffen werden. Diese
gesteigerte Motivation unterstützt das Projekt in allen Phasen und hilft mit, den Projekterfolg zu garan-
tieren.
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 Projektführung. Die indirekt steuerbaren
14
Aspekte betreffen hierbei meist nicht nur eine Phase des Projekts, sondern ziehen sich über mehrere
Phasen und auch über mehrere Projekte hinweg.
2.2.5. Erfolgsfaktoren eines Projekts
Gemäss einer Untersuchung der Standish Group (siehe Abbildung 1.1, S. 1) konnten im Jahre 2004
nur knapp 30% der IT-Projekte erfolgreich abgeschlossen werden. 18% scheiterten 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.
Das Management von Informationen und Prozessen konzentriert sich auf die effektive und effiziente
Gestaltung der Erfolgsfaktoren. Zu den Erfolgsfaktoren des Projektmanagements zählen die Erreichung
der definierten Projektziele unter der Einhaltung der geplanten Ressourcen wie Zeit, Kosten und Ka-
pazitä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 Projekt-
abwicklungserfolg, welcher durch die Projektabwicklungsziele 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 eingeschä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 Erfolgsfaktoren be-
schränkt, werden in der systemischen Projektführung die sozialen Erfolgsfaktoren Macht, Zusammen-
arbeit, Wissen, Information und Identität betrachtet. Diese können als Leitfragen 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 Inter-
esse Ihrer Anspruchsgruppe?
• Wissen: Verfügt Ihre Anspruchsgruppe über genügend Wissen für die Unterstützung des Pro-
jekts? Wie fliesst das Wissen?
• 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 Informations-
austausch vor, so dass alle Beteiligten jederzeit die notwendigen Informationen 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 ver-
einbaren?
15
16
3. Methoden 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 unter-
scheiden. Zuerst werden die traditionellen Methoden von Jenny (2005) und Specker (2004) sowie de-
ren Abläufe und Artefakte erläutert. Diese beiden methodischen Ansätze für die Führung eines Projekts
unterscheiden sich in der Art der Prozessgestaltung, decken jedoch einen grossen Teil der wichtigen
Aspekte ab. Danach folgen die agile Methode „Scrum“ und der MIO-Ansatz. Der Abschnitt der Prozes-
sintegration soll aufzeigen, wie traditionelle und agile Methoden in den MIO-Ansatz integriert werden
können.
Das traditionelle Projektmanagement fokussiert auf den Reporting-Mechanismus. An moderne Projek-

te, welche sich oftmals durch ein hohes Mass an Komplexität und verteilte Teammitglieder auszeichnen,
stellen sich die Herausforderung der Zusammenarbeit, des Wissensmanagements und der genauen
Definition von Arbeitsprozessen. Traditionelles Projektmanagement erarbeitet oft passive Reportings
anstatt einer dynamischen Teamarbeits-Koordination. Projektmanagement an sich soll als nützliches
System für alle gelten, um sich selbst zu organisieren (Chen u. a., 2002).
3.1. Allgemeines Projektmanagement
Ein Projekt, welches innerhalb einer Organisation durchgeführt wird, hängt auch stark von der unter-
nehmensinternen Struktur, dem Aufbau der Hierarchie und der Verteilung der Kompetenzen ab. Um
deren Zusammenhang zu verstehen, werden zuerst die Arten der Projektorganisation und die Rollen
und Gremien erklärt. Obwohl ein Projekt nicht zwingend die Organisation eines Unternehmens abbilden
muss, finden sich in einer Projektorganisation oftmals die gleichen Strukturen wieder. Das Informations-
, Dokumentations- und Sachmittelsystem bilden grundlegende Begleitprozesse eines jeden Projekts.
3.1.1. Projektorganisation
Grundsätzlich sind die Organisationsformen Linien-, Stab-Linien- und Matrix-Organisation zu unter-

scheiden.
Bei einer Linien-Organisation werden die Mitglieder aus der Firmenhierarchie herausgenommen und zu
100% in einem einzelnen Projekt eingesetzt. Durch die hohe Effizienz und die einfache Entscheidungs-
findung 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, wel-
che oftmals einem anderen Projektleiter unterstellt sind, eingesetzt werden.
17
Im Gegensatz dazu bleiben die Projektmitglieder bei der Stab-Linien-Organisation direkt ihren Linien-
vorgesetzten unterstellt. Der Projektleiter übernimmt hier lediglich die Koordinationsaufgaben, die Ent-
scheidungsgewalt bleibt bei der Geschäftsleitung. Diese aufgabenorientierte Dezentralisierung erhöht
das Projektrisiko und Bedarf einer intensiveren Kontrolle.
Als Mischform der oben genannten Organisationen gilt die Matrix-Organisation. Während eines Pro-
jekts 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 Firmenhierarchie. Die Projektmitglieder arbeiten
fix zu einem bestimmten Prozentsatz für ein bestimmtes Projekt.
Tabelle 3.1 zeigt die drei Projektorganisationen im Vergleich.
Linien Stab-Linien Matrix

Weisungsbefugnis voll weisungngsbefugt nur Koordinationsauf- weisungsbefugt
Projektleiter gabe betreffend Projektauf-
gaben
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
Projekt gleichzeitig einem Projekt
Vorgesetzter der Mit- Projektleiter Linienvorgesetzter Projektleiter und Lini-
arbeiter envorgesetzter
Vorteile hohe Effizienz und hohe Einsatzflexibilität optimale Kapazitäts-
Flexibilität im Projekt der Mitarbeiter auslastung
Nachteile Aus- und Wiederein- Linienaufgaben haben Konfliktgefahr infolge
gliederung der Mitar- Vorrang vor Projekt- zweiter Vorgesetzter
beiter aus der Firmen- aufgaben
hierarchie
Tabelle 3.1.: Überblick Projektorganisation (eigene Darstellung)
3.1.2. Rollen und Gremien
Für Stellen in einer Projektorganisation werden die Aufgaben, Kompetenzen und Verantwortungen
(AKV) festgelegt, um das strukturierte Vorgehen zu unterstützen sowie die Koordination zu vereinfach
und den Entscheidungs- und Eskalationsweg zu regeln. Wie bei herkömmlichen Stellenbeschreibun-
gen sollten alle Aspekte von AKV pro Rolle aufeinander abgestimmt sein, damit alle Projektmitglieder
ihre Aufgaben im Grundsatz der Einheit und Kongruenz erfüllen können. Um zugeteilte Aufgaben ab-
zuschliessen, werden die entsprechenden Kompetenzen benötigt, und über diesen Bereich trägt das
Projektmitglied auch die Verantwortung.
Zum organisatorischen Projektumfeld gehören nebst den Projektmitgliedern in der Projektorganisation

alle Stakeholder, also die Projektträger und alle weiteren Betroffenen und Involvierten (Auftraggeber,
Kunden, Lieferanten). Oftmals besetzt ein und dieselbe Person in einem kleinerem Projekt mehr als
eine Projektrolle. Auch Aufbau und Grad der gesamten Projektorganisation ist in weniger komplexen
18
3.1. Allgemeines Projektmanagement
Projekten einfacher und wird immer der Projektklassifikation angepasst. Die Aufgaben des Projektlei-
ters lassen sich grob in die sechs Gebiete Planung (25%), Kontrolle (25%), Koordination (21%), Steue-
rung (14%), Administration (12%) und Diverses (3%) aufteilen. Dabei machen Planung und Kontrolle
in einem Projekt die Hälfte der Aufgaben aus. Die Zahlen dieser empirisch gestützten Untersuchung
zeigen die Wichtigkeit der zwei Bereiche Planung und Kontrolle in einem Projekt (Jenny, 2005).
3.1.3. Informationssystem
Das Projekt-Informationssystem besteht aus den Bereichen Projektsitzung, Dialog, Präsentation 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 Diskussionen. 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 Projekt-
sitzung fliesst die Information bei der Präsentation anfangs nur in eine Richtung. Erst nach der eigent-
lichen Präsentation kann, muss aber nicht, eine Diskussion folgen. Nach der Durchführung folgt die
Nachbearbeitungsphase, in welcher Bilanz über positive und negative Aspekte gezogen wird. Bei Pro-
jektberichten 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
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 hervorgehen. Zu
den Dokumenten der Projekt-Durchführung gehören nebst dem Business Case und dem Anforderungs-
katalog Schriftstücke aus der Konzeptions- und Realisierungsphase. Tabelle 3.2 zeigt im Überblick, wel-
che 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 Jenny (2005), S. 86ff verwiesen.
19
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)
3.1.5. Sachmittelsystem
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.
3.2. Projektmanagement nach Jenny
Abbildung 3.1.: Projektmanagement-System nach Jenny (2005)
20
Jenny betrachtet das Projektmanagement als ein System mit einer zentralen Projektabwicklung (Füh-
rung und Durchführung, (Jenny, 2005), S. 37) als Kernelement. Die weiteren Management-Funktionen
(Projektportfolio, Risiko, Qualität, Team, Konfiguration, Changemanagement), welche den Projekterfolg
massgeblich beeinflussen, wirken auf das gesamte Projektmanagement-System ein und laufen paral-
lel zur Projektabwicklung. Allem zugrunde liegt die Projektinstitution, auf welcher das gesamte Projekt
aufbaut (siehe Abbildung 3.1, S. 20).
3.2.1. Projektinstitution
Die Projektinstitution beinhaltet die organisatorischen Bereiche beim Aufbau des Projektmanagement-
systems. Es beinhaltet den Aufbau der Projektorganisation (vgl. Kapitel 3.1.1), die Verteilung von Auf-
gaben, Kompetenzen und Verantwortung (vgl. Kapitel 3.1.2) sowie die Festlegung des Informations-,
Dokumentations- und Sachmittelsystem (vgl. Kapitel 3.1.3, 3.1.4, 3.1.5). Diese fünf Bereiche bilden die
Projektbasis.
3.2.2. Projektabwicklung
Mit Projektabwicklung wird das prozessorientierte Projektvorhaben bezeichnet,

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), S. 35.
3.2.2.1. Projektführung
Zur Projektführung gehören die funktionelle und die personenbezogene Führung. In den Bereich der
funktionellen Führung gehören die Planung, Steuerung und Kontrolle. Für weitere Erläuterungen zur
personenbezogenen Führung sei auf Kapitel 3.2.3.4 verwiesen.
Projektplanung und Artefakte

Im Zuge der Projektplanung werden diverse Pläne erstellt.
Abwicklungszielplan: Abwicklungsziele existieren in zwei Stufen: Richtwerte und Meilensteine. Für

den Abwicklungszielplan werden die Meilensteine und seine Abwicklungsziele (Leistung, Quali-
tät, Zeit und Kosten) aufgelistet.
Projektstrukturplan: Als Basis für die Ablauf-, Ressourcen- und Terminplanung gilt der Projektstruk-
turplan, der die Gesamtaufgabe in plan- und kontrollierbare Arbeitspakete gliedert. Alle Arbeit-
spakete zusammen stellen den gesamten Leistungsumfang des Projektes dar. Die Aufteilung
der Komponenten in einem Projektstrukturplan kann nach Arbeitspaketen (objektorientiert) oder
nach Projektaufgaben (vorgehensorientiert) erfolgen.
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 beispiels-
weise als Plan-Net dargestellt werden.
21
Ressourcenplan: Verfügbare Personal- und Sachmittel werden ermittelt und den einzelnen Arbeit-
spaketen zugeordnet. Diese Ressourcen werden im Ablaufplan angefügt und danach in das
Kapazitätsbelastungs-Diagramm übertragen, auf welchem die optimale Auslastung ersichtlich
ist.
Organisationsplan: Der Organisationsplan umfasst die Projektorganisation, die Rollen und die An-
wendung des Informations-, Dokumentations- und Sachmittelsystems und stellt somit die Verbin-
dung zur Projektinstitution her. Der Organisationsplan wird für das gesamte Projekt und danach
phasenspezifisch erstellt.
Projektkostenplan: Der Projektkostenplan beinhaltet die Berechnung und Zuordnung der voraussicht-
lichen 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 Budget berechnet. Wie im Ablaufplan
werden auch im Projektkostenplan keine Termine festgehalten.
Terminplan: Im Terminplan werden die wichtigen Termine und die Meilensteine sowie Beginn und En-
de der Arbeitspakete festgehalten. Als Basis werden die vorgängig erstellen Struktur-, Ablauf-
und Ressourcenpläne herangezogen. Der Terminplan bildet den Abschluss dieses Planungspro-
zesses. Ä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 erstellt 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 Anforderungen reduziert oder Budgetän-
derungen beantragt werden.
Informationsplan: Als Basis für den Informationsplan werden das Projektinformationssystem aus der
Institution und das Organigramm aus dem Organisationsplan verwendet und die Informationsver-
sorgung der Projektmitglieder geplant und koordiniert. Jede Information muss hinsichtlich Emp-
fänger, Zeitpunkt und Kommunikationskanal koordiniert werden. Wichtig hierbei ist, dass Infor-
mationen frühzeitig an die richtigen Empfänger weitergeleitet werden.
Projektsteuerung
Die Projektsteuerung verbindet die Projektplanung mit der Projektdurchführung. Grundvoraussetzung
für die Steuerung sind klar definierte Ziele und eine detaillierte Planung. Einen genauen Überblick über
die Steuerung gibt Kapitel 2.2.4.
Projektkontrolle
Durch die Kontrolle von Lieferobjekten durch eine höhere Instanz wird die Verantwortung des Projekt-
leiters weitergegeben. Durch eine regelmässige Prüfung und somit Abschluss bestimmter Lieferobjekte
kann der Projektleiter sein Verantwortungsvolumen überwachen und Arbeitspakete abschliessen. Eine
regelmässige Kontrolle hilft ebenso, frühzeitig Fehler zu entdecken und diese möglichst kostengünstig
zu beheben.
Die Dimensionen der Projektkontrolle definieren, wie und von wem zu welchem Zeitpunkt ein Liefer-
objekt kontrolliert wird. Zur Planungskontrolle gehören hierbei die Kontrolle von Aufwand, Kosten und
22
Terminen. Im Bereich der Realisierung werden Fortschritt, Qualität, Dokumentation und Information
kontrolliert.
Aufwand und Kosten: Eine Stundenerfassung auf die einzelnen Arbeitspakete ist ideal für die Kon-
trolle von Aufwand und Kosten und erleichtert den SOLL/IST-Vergleich und somit den Budgetver-
brauch.
Termine und Fortschritt: Schätzen die Projektmitglieder den Fertigstellungsgrad ihrer Lieferobjekte,
so kann daraus der Stand der einzelnen Arbeitspakete und des gesamten Projekts errechnet
werden.
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.
Dokumentation: Die Prüfung der Dokumentation geschieht durch den Empfänger hinsichtlich Firmen-
normen, Versionierung und Inhalt und garantiert Aktualität und Vollständigkeit.
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ührung und wird in einem Prüfplan festgelegt. Klare Kontroll-
zeitpunkte 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 Auf-
räumarbeiten beendet. Im Abschlussbericht werden die Abwicklungsziele Leistung, Qualität, Zeit, Ko-
sten) sowie Nichterfolge und die Gründe dafür festgehalten. Zu den Aufräumarbeiten gehören die Si-
cherung des während des Projekts angeeigneten Wissens sowie die Auflösung des Projektteams. Die
folgende Aufzählung listet die sechs Fragen, welche für einen erfolgreichen Projektabschluss abgear-
beitet und in den Abschlussbericht aufgenommen werden (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.3. Projektmanagement-Systemelemente
3.2.3.1. Projektportfoliomanagement
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
23
und dann die benötigten Massnahmen entschieden. Bei grossen Portfolios kann der Projektstatusbe-
richt elektronisch durch ein Projekt-Cockpit unterstützt werden, in welchem Risikoverfolgung, Klassifi-
zierung, Statusampeln, Meilensteintrend, Personalmittelplan und Finanzmittelplan aufgeführt sind (vgl.
Jenny (2005), S. 205).
Je zahlreicher die Projekte und je länger die Projektdauer, desto wichtiger wird das Projektportfolioma-
nagement für ein Unternehmen. Durch Priorisierungen können somit bei gefährdeten Projekten früh-
zeitig Massnahmen ergriffen werden.
3.2.3.2. Risikomanagement
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 Projektrisiken in die drei
Gruppen Umsetzungsrisiken (Einführung, Funktion, Materialzulieferer), Managementrisiken (Projekt-
führung, Planung, Kommunikation, Koordination) und Soziale Risiken (Motivation, Mitarbeiter, Politisch)
unterteilt werden. Alle Risiken werden in einem Zyklus identifiziert, 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
Bei der Qualitätsplanung werden die Anforderungen an den Projektabwicklungsprozess definiert. 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 Qualitätsmass erreichen. Qualitätskrite-
rien sind Effizienz, Benutzbarkeit, Geschwindigkeit, Robustheit, Sicherheit, Funktionsabdeckung und
Zuverlässigkeit. Diese Kriterien sind im Anforderungskatalog, im Business Case oder im Projektauf-
trag definiert und werden im Prüfplan festgehalten. 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, organisato-
rischen und psychologischen Qualitätsmassnahmen unterschieden werden.
Als dritter Bereich kommt die Qualitätsprüfung, welche zu dem im Prüfplan definierten Zeitpunkt das
Produkt nach klar definierten Kriterien prüft. Bei der Prüfung werden Abweichungen vom Entwicklungs-
ziel wie auch von Normen und Verfahren aufgezeigt. Eine weitere Möglichkeit der Qualitätsprüfung ist
die Mängel- und Fehleranalyse, welche auf einem Mängelkatalog und einem Fehlerbericht basiert.
3.2.3.4. Teammanagement
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 Teamauflösung nach
Beendigung 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. In der
24
3.3. Projektmanagement nach Specker
darauf folgenden „Storming“-Phase besteht die Aufgabe des Teamleiters darin, die Konflikte, welche
persönlicher 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 ge-
meinsame 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 Dimensionen
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 Informationen siehe Jung (2006)).
Meist ist der Führungsstil 5.5 anzustreben, welcher einen guten Kompromiss zwischen Mitarbeiter- und
Aufgabenorientierung bietet.
Ist das Projekt beendet, wird durch die Teamauflösung das Projektteam sukzessive abgebaut, damit
die Teammitglieder in neue Projekte wechseln können.
3.2.3.5. Konfigurationsmanagement
Der wichtigste Bereich im Konfigurationsmanagement ist das Änderungsmanagement, mit welchem

Änderungen, Verbesserungen und Ergänzungen kontrolliert und rückverfolgt werden. Hierbei werden
Änderungsmeldungen bewertet und das Vorgehen festgelegt, denn durch Änderungen entsteht meist
Mehraufwand und zusätzliche Kosten. Eine ausführliche Dokumentation wird hier benötigt, um die ge-
tätigten Änderungen nachzuweisen.
Specker (2004) unterscheidet den Projekt- und den Projektmanagementprozess. Der Projektmana-
gementprozess, bestehend aus Projektplanung, Projektmanagementausführung und Projektüberwa-
chung (Controlling), übernimmt eine überlagerte Projektführungsfunktion, während dessen unter dem
Projektprozess das geeignete Vorgehensmodell der Produktentwicklung (vgl. Kapitel 3.6) verstanden
wird. Parallel zum Projektmanagementprozess listet Specker (2004) sieben Managementfunktionen,
welche während allen Prozessen in unterschiedlicher Ausprägung wahrgenommen werden müssen
(siehe Abbildung 3.2, S. 26).
Projektmanagementprozess
Projekte und Projektmanagement können als überlagertes System mit Teilbereichen aus dem Sy-
stemumfeld und dem Projektumfeld aufgefasst werden. Dieses Projektsystem beinhaltet Mitarbeiter,
Aufgaben und Managementtools. Die Projektmanagementfunktionen begleiten alle Prozesse mit un-
terschiedlichen 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ührungsaufgaben wahr-
zunehmen (Führung, Motivation, Konfliktlösung). Viele Konflikte können bereits bei der Initialisierung
des Projekts gesteuert werden.
25
Abbildung 3.2.: Projektmanagementprozesse mit Schwerpunkten nach Specker (2004)
Das Auftragsmanagement koordiniert die Übertragung und die Erledigung von Aufgaben sowie Ver-
träge mit Kunden respektive Lieferanten und interne Projektvereinbarungen. Die internen Vereinbarun-
gen beinhalten Verpflichtungen betreffend Umfang, Terminen und Ressourcen. Durch interne Contracts
werden Mitarbeiter dazu bewegt, ihre Arbeitskapazität mit Fachvorgesetzten zu diskutieren und abzu-
stimmen.
Im Kommunikationsmanagement werden Dokumente, Projektinformation und -marketing geführt, um

verbindlich gültige Dokumente abzulegen und alle Interessengruppen angemessen zu informieren. Kla-
re und regelmässige Information leistet einen grossen Beitrag zum Projekterfolg.
Das Inhaltsmanagement beinhaltet Zielsetzungs-, Projektstruktur-, Änderungs- und Anforderungsma-

nagement. Es stellt sicher, dass Zielsetzungen inhaltlich auch erreicht werden, definiert im Strukturplan
Teilprojekte und Arbeitspakete, stellt die Anforderungen und die Überprüfung des Funktionsumfangs
sicher und verfolgt Änderungswünsche von Kunden und Lieferanten.
Durch das Terminmanagement werden Termine, Meilensteine und Lieferdaten für Arbeitspakete defi-
niert. Es ist gleichzeitig stark mit dem Ressourcenmanagement und dem Inhaltsmanagement gekop-
pelt.
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 Pro-
jektinfrastruktur.
Beim Risikomanagement werden projektspezifische Risiken erhoben. Der Risikokatalog listet Eintre-
tenswahrscheinlichkeit, Kostenfolge sowie Massnahmen und Zuständigkeiten.
26
Das Qualitätsmanagement unterteilt sich in Produkte- und Prozessqualität. Während die Produktqua-
lität auf die Qualität des zu erstellenden Lieferobjekts fokussiert, werden bei der Prozessqualität die
Qualität der Projektabwicklung und des Projektmanagements überwacht.
Berichte werden während allen Prozessen im Projektmanagement erstellt und bilden die Informations-
grundlage für das gesamte Projekt.
3.3.2. Projektmanagementtätigkeit
Die folgenden Tabellen 3.3 bis 3.6 geben eine Ergebnisübersicht der Projektmanagementtätigkeit wäh-
rend der vier Prozessphasen.
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.: Ergebnisübersicht Projektplanung nach Specker (2004)
27
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.: Ergebnisübersicht Projektausführung nach Specker (2004)
28
PM-Funktion Prozess: Projektcontrolling

Projektorganisation Status Projektorganisation:
Projektausschuss, Stellvertretung Projektleiter vorhan-
den. . .
Auftragsmanagement Status etwaiger „Claims“
Status Vertragsänderungen
Grad der Umsetzung interner Vereinbarungen
Kommunikationsmanagement Status der Dokumentation, Vollzug der Kommunikation
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 allen Pro-
jektfunktionsbereichen
Berichte Projektcontrollingbericht
Projektstatusbericht
Tabelle 3.5.: Ergebnisübersicht Projektcontrolling nach Specker (2004)
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.: Ergebnisübersicht Phasen-/Projektende nach Specker (2004)
29
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 gilt als agiles und modernes Projektmanagement und unterscheidet sich von den traditionel-
len Methoden vorwiegend durch die Verteilung der Zuständigkeiten, Kompetenzen und Verantwortung
sowie die Selbstorganisation und Autonomie 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 steu-
ern. Scrum ist eine Einstellung dazu, wie man mit Menschen und Mitarbeitern, Kunden und Managern
umgeht. Scrum ist eine innere Haltung, die sich durch Disziplin und Verantwortungsbewusstsein aus-
zeichnen (Gloger, 2008) und den Prinzipien des agilen Manifests folgt (siehe Anhang C.4).
Der Scrum-Prozess besteht aus sechs Rollen, sechs Meetings und neun Artefakten.
Abbildung 3.3.: Scrum-Prozess nach Gloger (2008)
3.4.1. Projektmanagement in Scrum
Scrum kennt die traditionelle Rolle des Projektleiters nicht, sondern teilt die Projektmanagementaufga-
ben auf die Scrum-Rollen auf (siehe Tabelle 3.7 auf Seite 31). Ein traditionell gemanagtes Projekt wird
langfristig auf der Ebene der Taktik gemanagt, ein agil gemanagtes Projekt auf der Ebene der Strate-
gie. Diese Grundunterscheidung führt dann zu vollkommen anderen Vorgehensweisen in der Planung
30
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-Management Produktleistungs- qualitätssichernde richtige Anwendung
merkmale Massnahmen des Prozesses
Lieferanten- mit Team mit Product Owner
Management
Personal-Management Produktivität und Bereitstellung der
kontinuerliche Pro- Mitarbeiter in Zu-
zessverbesserung sammenarbeit mit
dem Management
Tabelle 3.7.: Verteilung von Projektmanagementaufgaben in Scrum nach Pichler (2007)
eines Projektes - nämlich zu einer strategischen Planung und damit überhaupt erst zu einer Strategie
mit klaren Zielen (Gloger, 2008).
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 angesiedelt sind
(siehe Abbildung 3.4, S. 31). Für vertiefte Informationen wird auf Gloger (2008), Pichler (2007) und
Mengelt (2008) verwiesen.
Abbildung 3.4.: Organisation und Scrum nach Gloger (2008)
3.4.2.1. Product Owner - der Visionär
Die Rolle des Product Owners (PO) repräsentiert die Endkundenbedürfnisse, vereint Produkt- und Pro-
jektmanagementaufgaben in sich und ist zugleich fest in die Softwareentwicklung integriert. Der PO
erfasst Kundenbedürfnisse, beschreibt Anforderungen, managt und priorisiert das Product Backlog,
31
managt den Releaseplan und ist für den Erfolg des Projektes verantwortlich. 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 notwendigen 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 Verantwortung
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 (Pichler, 2007).
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 erle-
digt 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 vertre-
ten 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 entscheidet 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 Mitgliedern1 , wodurch ein Scrum Team optima-
lerweise fünf bis neun Mitglieder umfasst.
Vollzeitteammitglieder: Um Engpässe und höhere Prozesskosten zu vermeiden, sollten Mitarbeiter

nur einem Team angehören. Werden dennoch Teilzeitmitarbeiter eingesetzt, so sollten diese min-
destens an den Sprint-Planungssitzungen und -Reviews anwesend sein, damit der Informations-
fluss weiterhin gewährleistet ist.
3.4.2.3. SCRUM Master - der Change Agent
Der Scrum-Master ist Coach und Change Agent und vollständig im Team integriert. Durch seine Arbeit
fördert er neue Denk- und Verhaltensweisen und hilft, Scrum innerhalb des Unternehmens zu etablie-
ren. 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 erfolgreich zu sein und die eigene Rolle richtig ausführen zu
können, sollte der Scrum-Master über Kenntnisse in den Bereichen Moderation, Teambildungsprozess,
kollaborative Entscheidungsfindung und Konfliktmanagement verfügen (Pichler, 2007).
1
http://www.brandeins.de, Ausgabe 07/2007 „Der goldene Schnitt“
32
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 ausserhalb
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. Als zukünftiger
Anwender der „Usable Software“ wird er in die Produkt-Entwicklung vom Scrum-Team einbezogen: zu
Beginn gemeinsam mit dem Product Owner für die Definition der Anforderungen, später als Anwender
mit dem Team für die Nutzung der Anwendung.
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.
3.4.3. Artefakte
Artefakte sind in Scrum Dokumente und visuelle Hilfsmittel, welche die Methodik des Projektmanage-
ments unterstützen. Dieser Abschnitt gibt keine vollständige Auflistung aller Artefakte in Scrum. Für
zusätzliche 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 und in der entsprechenden Rei-
henfolge aufgeführt. Es enthält alle funktionalen und nicht funktionalen Merkmale sowie Anforderungen
an die Benutzerschnittstelle. Für jedes Scrum-Projekt gibt es ein Product Backlog. Aktivitäten fehlen
im Product Backlog, diese werden vom Team identifiziert und als Story im Sprint Backlog festgehalten.
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 Spezifika-
tion für ein Produkt einsetzen zu können. Es enthält keine programmierspezifischen 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 Merk-
male 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 traditionelles Change-Request Verfahren. Um Änderungen dennoch nachvollziehen
zu können, ist eine Versionierung des Product Backlogs sinnvoll. Change-Requests erscheinen
als neue Stories im Product Backlog.
kollaboratives Werk: Meist arbeitet der Product Owner bei der Erstellung des Product Backlogs mit
dem Team und weiteren externen Personen zusammen. Seine alleinige Aufgabe besteht darin,
33
die Backlog Items in eine Reihenfolge zu bringen, die aus Anwendersicht Sinn macht (Priorisie-
rung).
unterschiedlicher Detaillierungsgrad: Höher priorisierte Einträge werden detaillierter beschrieben

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 Merk-
mals. Die Schätzung wird vom Team vorgenommen.
Product Backlogs werden häufig in tabellarischer Form oder als Karteikarte pro Product Backlog Item
(Story Cards) festgehalten.
Story Cards sind optimal für Backlogs auf Teamebene und erfüllen die Forderungen der 3C2 :
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 Überlegun-
gen zur Umsetzung oder Abhängigkeiten auf der Karte notiert.
Conversation: Der Product Owner erklärt das Backlog Item dem Team. Wenn bereits Dokumente vor-
liegen, 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 Meeting 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 anzeigt, 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 Product Ow-
ner stellt hierbei eine Vorauswahl seiner Product Backlog Items vor, das Team identifiziert die Aufgaben
und wählt anhand der Story Points (Mass für den Aufwand eines Backlog Items) die zu realisierenden
Einträge innerhalb des nächsten Sprints („Selected Product Backlog“). In einer zweiten Planungssit-
zung 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
Burndown-Charts kann eine aktuelle Trendlinie aufgezeigt werden.
2
nach Gloger (2008) und www.xprogramming.com/xpmag/expCardConversationConfirmation.htm
34
3.4.3.4. Impediment List
Das Impediment Backlog besteht aus einer Liste aller Blockaden, die einem Team aus dem Weg ge-
rä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 Hindernisse 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 programmiertechnische Hindernisse bei der Retro-
spektive 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 lauffä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 umge-
setzten Backlog Items hat.
3.4.4.1. Planungssitzung 1
Im ersten Meeting des Sprints sind alle Beteiligten anwesend, auch Management und Anwender. 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 anstehenden
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 alle Projektbeteiligte teilneh-
men, 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:
- 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).
35
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 Funktionalitäten sofort
produktiv einzusetzen. Nicht getestete oder instabile Funktionalitäten werden 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 analysiert, welche
Arbeitsprozesse verbessert werden müssen, damit das Team effektiver arbeiten kann. Dazu gehören
auch zwischenmenschliche Unregelmässigkeiten und strukturelle Probleme. Die Resultate aus der Re-
trospektive werden im Impediment Backlog festgehalten und können 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 somit op-
timale Anpassungsfähigkeit an veränderte Umstände, mehr Kommunikation und mehr Mitverantwor-
tung, 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 aus-
lieferbares Produktinkrement geliefert, welches zu Beginn des Sprints im Sprint Backlog von Product
Owner und Team definiert wurde. Scrum wird oftmals im Zusammenhang mit agiler Softwareentwick-
lung eingesetzt, zum Beispiel mit Extreme Programming (vgl. 3.6.4), ist grundsätzlich jedoch nicht an
einen bestimmten Produktentwicklungsprozess gebunden. Ziele von „Scrum“ sind ein klarer Fokus auf
Nutzenpotenziale, schnelle Reaktion auf Veränderung, phasenorientierte Lieferung der Funktionalität
und ein iterativer Entwicklungsansatz (Schopp, 2008).
König (2008) führt aus, dass „Scrum“ alle drei Dimensionen von Erfolg (persönlich, technisch, unter-
nehmerisch) fördert: „Ohne persönlichen Erfolg ist man schwer motivierbar. Ohne technischen Erfolg
gleicht die Codebasis häufig einem Teller Spagetti und ohne unternehmerischen Erfolg wird sich das
Team vom Unternehmen abwenden und eine neue Herausforderung suchen.“
3.5. MIO Ansatz

Der Ansatz mensch - informatik - organisation fokussiert auf drei parallel laufende Prozesse, welche im
Verlaufe eines Projektes abgewickelt werden. Der erste Prozess, das traditionelle Projektmanagement,
managt die ökonomischen Prozessziele Leistung, Zeit und Kosten. Während die systemische Projekt-
führung die sozialen Erfolgsfaktoren fördert, unterstützt der Produktentwicklungsprozess die im Projekt-
auftrag 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 Projektabwicklungsmodell erlaubt es, unterschiedliche Erfolgsfakto-
ren zur überwachen. Eine 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
36
3.5. MIO Ansatz
Abbildung 3.5.: Drei parallele Prozesse nach Kuhnt (2007)
• Verfügbarkeit geeigneter Mitarbeiter in ausreichender Anzahl

• Nutzung von Techniken und Instrumenten des Projektmanagements
• Unterstützung 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. Managementprozess
Der Inhalt des Projektmanagements besteht aus Abwicklung, Planung und Überwachung des Projekts,
wobei der Prozess des Projektmanagement eine übergelagerte Funktion der Projektführung übernimmt
(Kuhnt, 2007). Es begleitet das Projekt von Beginn bis Ende und ist unabhängig vom gewählten Vor-
gehensmodell. Der Projektauftrag, welcher vor dem eigentlich Start des Projekts statt findet, gehört
ebenfalls bereits zum Management-Prozess. Die funktionalen Managementprozesse dienen der Op-
timierung der Koordination der Aktivitäten der am Projekt beteiligten Akteure. Als Grundlage dienen
traditionelle Management-Methoden (vgl. 3.2, 3.3 und Tabellen 3.3, 3.4, 3.5), welche zwischen Initiali-
sierung und Abschluss die zyklischen Phasen Planung, Ausführung und Controlling beinhalten.
37
Unter Planung wird die vorausschauende Festlegung von Vorgaben zur Projektdurchführung verstan-
den. In dieser Phase wird die Grundlage für die effiziente Koordination der beteiligten Akteure geschaf-
fen. Zu den Planungsaufgaben gehören u.a. die Definition klarer Vorgaben zur effizienten Durchführung
des Projekts, die Festlegung der logischen und zeitlichen Organisation einzelner Aktivitäten, die Ermitt-
lung von Vorgaben für Projektzeitaufwand und Projektkosten, die Vorbereitung der Projektmanagementausführungs-
und Projektkontrollmassnahmen sowie die Bereitstellung von Informationen zur Abstimmung mit ande-
ren unternehmerischen Aktivitäten (Kuhnt, 2007).
Zum Ausführungsprozess gehören alle Aktivitäten des Projektleiters, um die ökonomischen Prozes-
sziele Zeit, Kosten, Qualität und Leistung zu erreichen (vgl. auch 2.2.4.1) und das Projekt erfolgreich
abzuschliessen.
Das Controlling soll Abweichungen zwischen IST- und SOLL Zustand überwachen (vgl. auch 3.2.2.1).
Dabei setzt ein zielorientiertes Kontrollvorgehen einen vordefinierten Kontrollprozess voraus, der be-
reits 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 Produktent-
wicklung.
3.5.2. Führungsprozess
Abbildung 3.6.: Lebensphasen eines Projektteams nach Brugger u. Soltermann (2004)
Der Führungsprozess besteht aus den Phasen Etablierung, Konstituierung, Durchführung und Ab-
schluss, 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 Perso-
nen 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ützlich 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 verschiedenen Perspektiven eruiert wurde,
erarbeitet die Projektleitung ihre Vorstellung über die Teamzusammensetzung, Rollen- und Aufgaben-
verteilung 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 gemeinsamer Rahmen geschaf-
fen. Dabei werden alle Stakeholder informiert und deren Interessen, Einstellungen und Probleme er-
fasst. Beim „Moving“ wird im gemeinsamen Gestaltungsprozess das Veränderungspotenzial erfasst und
38
3.6. Produktentwicklungsprozess
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 Teambildungsprozesses „Stor-
ming“, „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 Kommunikation der Teammitglieder geschaffen (vgl.
auch 2.1.2).
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 Kommunikations-
unterstützung. Soziale und kommunikative Kompetenzen haben in der Mitarbeiterführung eine hohen
Stellenwert und beeinflussen die sozialen Erfolgsfaktoren Wissen, Information und Zusammenarbeit.
Beim Abschluss werden Ergebnisse gefeiert und über die getane Arbeite reflektiert. Vor allem in agilen
Projektmanagementmethoden 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 ent-
standen, 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 definie-
ren. Oftmals arbeiten Teammitglieder am System weiter, obwohl das Projekt bereits als abgeschlossen
gilt.
Ein Vorgehensmodell gliedert den Prozess der Projektabwicklung in verschiedene, strukturierte Pha-
sen, denen wiederum entsprechende Methoden und Techniken der Organisation zugeordnet sind. Auf-
gabe eines Vorgehensmodells ist, die allgemein in einem Gestaltungsprozess auftretenden Aufgaben-
stellungen und Aktivitäten in ihrer logischen Ordnung darzustellen (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 ent-
wickelten Software und somit die Anzahl der involvierten Programmierer stetig zunahm, verschlechter-
te sich die Zuverlässigkeit der Software. Für ein erfolgreiches Projekt werden Kompetenzen in unter-
schiedlichen Bereichen benötigt. Vorwiegend die schnelle Änderung der Anforderung an geplante Soft-
ware setzt eine hohe Kompetenz im Veränderungsmanagement und im IT-Anwendungsfeld für den Pro-
jektleiter 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. Erstaunlicherwei-
se halten fast 90% 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.
39
Abbildung 3.7.: Wasserfallmodell nach Specker (2004)
3.6.1. Wasserfallmodell
In den 70er Jahren wurde das Vorgehen bei der Entwicklung eines Softwareproduktes vom altbekann-
ten Ingenieurwesen übernommen. Inhaltlich und zeitlich werden Phasen abgegrenzt, welche streng
sequentiell und vollständig umgesetzt werden. Diese wissenschaftliche Herstellung von Basisanwen-
dungen hat lange Entwicklungszeiten zur Folge, da alle Teilprozesse sequentiell durchlaufen werden
und erst ganz zum Schluss eine betriebsfähige Software entsteht, dafür mit vollem Funktionsumfang.
Ebenso gibt es nach der Spezifikation kein Veränderungsmanagement mehr. Das Projektmanagement
begleitet den Entwicklungsprozess parallel. Durch die langen Prozesse der Problemanalyse und Spezi-
fikation 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 Endanwen-
der entspricht. Diese und weitere Gründe verlangten schon bald ein Überdenken des Vorgehensmo-
dells.
3.6.2. Spiralmodell
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 Wasserfallmodell, 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
Zuordnung 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 Änderungen 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
40
Abbildung 3.8.: Spiralmodell nach Specker (2004)
jedoch die Gefahr, dass Probleme und Hindernisse in spätere Zyklen verschoben werden und durch
die fehlende Gesamtspezifikation das Ziel verfehlt wird.
3.6.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 traditionelle
Projektmanagement. Primäres Ziel ist die Bestimmung und Validierung von Anforderungen an ein An-
wendungssystem (Ferstl u. Sinz, 2006). Mithilfe der Spezifikation mittels Prototyping konnten kürzere
Entwicklungszyklen und versionenorientierte und evolutionäre Ansätze verfolgt werden. Die entstande-
nen 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 Soft-
wareentwicklung verankert, da eine optimale Anpassung an ein verändertes Umfeld möglich ist. Den-
noch erschwert Prototyping das Projektmanagement, da durch die schnelle Verfügbarkeit des Prototy-
pen und seine Änderungsfreundlichkeit 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 Erzeugung 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 Systemspezifikation wird in Zusammenarbeit mit
den Benutzern erarbeitet.
Experimentell: Weist die Realisierbarkeit eines Entwurfs vor dem Einstieg in die Implementierungs-
phase eines traditionellen Phasenmodells nach. Im Mittelpunkt steht nebst der softwaretechni-
41
schen Realisierung auch die Kommunikation mit den Anwendern (Biethahn u. a., 2004).
Evolutionär: Durch laufende Anpassung des Prototypen an geänderte Anforderungen in einem sich in
Entwicklung befindenden Systems stellt der evolutionäre Prototyp kein Wegwerfprodukt, 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.6.4. Extreme Programming
Extreme Programming (XP) ist ein agiler Softwareentwicklungsprozess für kleine Teams, welche sich
aus Kunden, Entwicklern und Management zusammensetzt. Der Prozess ermöglicht, langlebige Soft-
ware zu erstellen und während der Entwicklung auf vage und sich rasch ändernde 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 dem Kunden und Teammitgliedern
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), (West-
phal, 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 Funk-
tionalität.
Einfaches Design: Komplexe Strukturen auflösen, sobald diese entdeckt werden. Das System soll zu
jedem Zeitpunkt möglichst einfach strukturiert sein.
Refactoring: Das Design des Systems wird fortlaufend in kleinen, funktionserhaltenden Schritten ver-
bessert. Finden zwei Programmierer Codeteile, die schwer verständlich sind oder unnötig kompli-
ziert 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 bestehende 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ütlich 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 jede Mög-
lichkeit zur Codeverbesserung jederzeit wahrnehmen. Das ist kein Recht sondern 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 Ta-
ges in die Versionsverwaltung eingecheckt und ins bestehende System integriert. Die Unit Tests
müssen zur erfolgreichen Integration zu 100% laufen.
42
3.7. Prozessintegration
3.6.5. Fazit
Der Produktentwicklungsprozess besteht aus Vorgehensmodellen, welche sich den äusseren Einflüs-
sen, dem Projekt, der Organisation und den Veränderungen laufend anpassen und weiterentwickeln.
Wichtig bleibt, dass die Entwicklung vom passenden Projektmanagement unterstützt wird. Während das
Wasserfall- und Spiralmodell durch traditionelles Projektmanagement begleitet wird, empfehlen sich für
Prototyping und Extreme Programming agile Projektmanagement-Methoden.
Der MIO-Ansatz basiert auf der Prozessdifferenzierung und darauf, dass die Prozesse der sozialen Pro-
jektführung parallel und in gegenseitiger Wechselwirkung zum Management- und Produktentwicklungs-
prozess ablaufen. Für ein erfolgreiches Projekt sind somit alle Prozesse zu begleiten, zu überwachen
und zu unterstützen.
Während die Produktentwicklung abhängig ist von der Komplexität der zu erstellenden Software (vgl.
Kapitel 3.6), dem Wissen und Interesse der Projektmitglieder (Gloger, 2008) und dem Typ des Projekts
(vgl. Kapitel 2.2.2), laufen die soziale Projektführung und der Managementprozess ähnlich, jedoch in
unterschiedlich ausgeprägter Form ab (vgl. Tabelle 3.2 und Kapitel 3.2.3.4, 3.3). Die folgenden beiden
Abschnitte geben Aufschluss darüber, in welcher Form die traditionellen wie auch modernen und agilen
Managementmethoden auf die Prozesse der Führung und des Managements in Anlehnung an den
MIO-Ansatz abgebildet werden können.
43
3.7.1. Projektmanagement-Prozess
Während der Initialisierungsphase des Projektmanagements wird das Projekt oder die Projektphase
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 einem neuen Pha-
senbeginn, vor allem bei knappen Ressourcen, zu wenig oder gar nicht beachtet. Bei den traditionellen
Theorien zeichnet sich das Überspringen dieses Prozesses bei einer neuen Phase durch nicht aktuelle
Planwerte aus, welche möglicherweise ein Risiko aufzeigen könnten. Bei Scrum werden die Arbeiten
der Initialisierungsphase bei jeder Planung wiederholt.
Initialisierung Produkte Tätigkeit

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 Vision Stories sammeln
Product Backlog Items Product Backlog erstellen
Initiales Product Backlog
Tabelle 3.8.: Projektinitialisierung
44
Während der Planung werden Aufgaben betreffend Inhalte, Termine und Ressourcen logisch und zeit-
lich koordiniert und Aufwände geschätzt. Durch die Planung soll Transparenz in den Verlauf der Pro-
jektphase für alle gebracht werden.
Planung Produkte Tätigkeit

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

Jenny Testbericht direkte und indirekte Steuerung
Projektsteuerung Statusbericht
Specker Zielsetzungsplan Verwaltung von Kosten und Pro-
Inhalt Projektstrukturplan jektinfrastruktur
Termin Terminplan Änderungen und Prozessziele über-
Ressourcen Sitzungsprotokolle wachen
Auftrag Projektberichte
Scrum Impediment List Daily Scrum
Hindernisse beseitigen
Tabelle 3.10.: Projektausführung
45
Das Controlling begleitet das Projektmanagement kontinuierlich und wird mit verstärktem Fokus am En-
de jeder Phase durchgeführt. Es deckt Abweichungen zwischen 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 definitiv abzunehmen. Kontrolle umfasst nebst den
Lieferobjekten auch die Artefakte, zum Beispiel die Terminplanung, Aufwand- und Kostenschätzung.
Dafür stehen unterschiedliche Kontrollverfahren zur Verfügung, zum Beispiel Review, Audit oder Test
(vgl. auch Jenny (2005)). Der Abschluss findet wie die Initialisierung iterativ, nach jeder Phase sowie
Kontrolle Produkte Tätigkeit

Jenny Prüfplan Kontrolle von Aufwand, Kosten und
Projektkontrolle Arbeitsrapporte Terminen
testbare Arbeitspakete regelmässige Prüfung von Lieferob-
jekten und Dokumentation durch hö-
here Instanzen und Auftraggeber
Specker Risikokatalog Änderungen und Prozessziele über-
Risiko Risikomanagementplan wachen
Qualität Projektcontrollingbericht
Projektstatusbericht
Scrum Burndown Chart tägliches Update der Fortschritte
Tabelle 3.11.: Projektkontrolle
zum Projektende, statt.
Abschluss Produkte Tätigkeit

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
46
3.7.2. Führungsprozess
Der Führungsprozess beschäftigt sich mit der sozialen Führung der Projektmitglieder. In der Etablie-
rung werden wichtige Teamrollen festgelegt und Erwartungen abgeklärt. Während der Konstituierung
Etablierung Produkte Prozess

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

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

Ort & Zeit für Daily Scrum festlegen
Tabelle 3.14.: Projektkonstituierung
47
Während der eigentlichen Führung beobachtet der Projektleiter die Eigendynamik des Teams und rea-
giert bereits auf schwache Signale, um eine möglichst gute Atmosphäre und Arbeitsumgebung für alle
Beteiligten zu schaffen. Unter Führung fällt auch die Teamzusammensetzung, welche im schlimmsten
Fall geändert werden muss. Beim Abschluss werden Zwischenergebnisse gefeiert und Phasen ab-
Führung Produkte Prozess

Jenny - Kontrolle der Arbeitsrapporte auf In-
Teammanagement halt und Vollständigkeit
(Teamführung)
Specker Dokumentations- & Dokumentenab- Personal führen
Kommunikation lageplan regelmässige Projektinformation
Projektinformationsplan
Projektmarketingplan
Scrum Impediment List Hindernisse beseitigen
Tabelle 3.15.: Projektführung
geschlossen. Dies ist auch der Zeitpunkt, über das Getane zu reflektieren und Verbesserungen zu
besprechen.
Abschluss/Lernen Produkte Prozess

Jenny Leistungszeugnis für Projektmitar- Projektteam abbauen
Teammanagement beiter
(Teamauflösung)
Specker - Auflösung der Projektorganisation
Projektende Kommunikation der Projektzielerrei-
chung
Lehren für andere Projekte
Scrum - -
Tabelle 3.16.: Projektabschluss/Lernen
48
3.8. Fazit
3.8. Fazit
Projektmanagement ändert sich aufgrund der Globalisierung, des Fortschritts in der Informationstech-
nologie und der damit verbundenen Unterstützung verteilter Projektteams. Das traditionelle Projekt-
management fokussiert auf ein Projekt an einem Standort und beschäftigt sich hauptsächlich mit In-
und Output von Informationen und Dokumenten anstatt mit Prozessen. 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ändnisse zu
vermeiden und geben allen Projektmitgliedern einen umfassenden Überblick. Hilfswerkzeuge in
elektronischer Form unterstützen dabei die Kommunikation in alle Richtungen und die Speiche-
rung von Wissen.
• Sie managen nicht nur Input und Output, sondern auch Prozesse im Bereich der Führung 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 unvollständige Planung entste-
hen.
Die Integration dieser modernen Ansätze in eine Projektmanagement-Plattform hat zum Ziel, die Er-
folgsquote von IT-Projekten zu erhöhen und dabei Informationen und Wissen dauerhaft zu speichern
und abrufbar zu machen. Zudem sollen die Projektleiter durch automatisierte Prozesse entlastet und
die Fehlerquote bei der Verteilung von Information verringert werden. Planung, Berichte und Kontrolle
des traditionellen Projektmanagements sind weiterhin wichtige Faktoren für den Erfolg eines Projekts
und werden für diesen Zeitraum mittels Informations- und Datenmanagement zum richtigen Zeitpunkt
an die richtigen Stellen verteilt. Es genügt allein jedoch nicht aus, um den gestiegenen Anforderungen
an Kommunikation, Kollaboration und Informationsaustausch gerecht zu werden. Es ist wichtig, die In-
formationen wie auch den Prozess zu unterstützen, wobei der Prozess als dynamischer Teil gilt und
einen Bereich darstellt, in welchem die Forschung erst bei den Anfängen steht (Chen u. a., 2002). Die
Verknüpfung von traditionellen und modernen Methoden und Prozessen hat zum Ziel, das Projekt und
das Team als ein sich selbst organisierenden Systems zu betrachten und zu unterstützen. Dies stellt
auch neue Anforderungen an eine entsprechende Plattform.
49
50
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 Anforderun-
gen 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 Projektmitglieder beeinflusst.
Die spezifischen funktionalen Anforderungen an die Plattform lassen sich nach Spath u. a. (2007) in
drei Bereiche unterteilen:
- Kommunikation
- Projektmanagement (traditionell)
- Informations- und Datenmanagement
Für jeden Bereich wird eine empfohlene Mindestanforderung an die Plattform gestellt.
Nebst den funktionalen Anforderungen kommen Randbedingungen hinzu, welche eine Plattform erfül-
len muss, um richtig eingesetzt werden zu können. Diese können von Organisation zu Organisation
aufgrund der firmeninternen Richtlinien stark variieren. Zu Beginn dieses Kapitels werden mögliche
Randbedingungen für Klein- und Mittelunternehmen aufgelistet und begründet.
4.1. Randbedingungen
Klein- und Mittelunternehmen werden durch ihre Grösse, der Anzahl Mitarbeiter und des Jahresum-
satzes klassifiziert. Typische Projekte in einem KMU sind im mittleren Bereich der Wichtigkeit, B bis
C angesiedelt. Nur wenige Projekte mit hoher Komplexität (vgl. Kapitel 2.2.1) und hohem Risiko (vgl.
Kapitel 2.2.3) können von einem Kleinunternehmen gleichzeitig durchgeführt werden, um einem Klum-
penrisiko zu entgehen. Nach Applegate fallen sie in die Kategorie der strategischen, high potential oder
kritisch operativen Projekte. Unterstützende Projekte werden erst mit zunehmender Grösse eines Un-
ternehmens wichtig. Untersucht man die Projekttypen, so werden meist Auftragsprojekte 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 geregelt. Die häufig-
ste Lizenz ist die „GNU GPL“1 (GNU General Public Licence). Sie legt den kompletten Quellcode offen
1
http://www.gnu.org/copyleft/gpl.html
51
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 Distribution). 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 Up-
dates. Durch den offenen Quellcode erhält man zusätzlich auch das Know-How über die Entwick-
lung.
Anpassbarkeit: Anpassung an individuelle Bedürfnisse. Auch die Integration in bestehende Software

oder Designanpassungen sind möglich.
Offener Entwicklungskreis: Weiterentwicklung durch eine grosse Community. Somit erhält man Er-
weiterungen, welche eine Vielzahl von Anwendungsproblemen lösen. Im Gegensatz zu proprie-
tären Lösungen ist man nicht auf Weiterentwicklungen des Herstellers angewiesen.
Unabhängigkeit: Keine Verpflichtung gegenüber dem Hersteller. Es bestehen keine längeren Ver-
tragsbedingungen, welche möglicherweise den Umstieg auf eine andere Lösung behindern.
Dem gegenüber stehen natürlich auch einige Nachteile.

Die Community, welche ein 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 Quellcode
offen und es bestehen somit offene Schnittstellen respektive diese können programmiert werden, den-
noch 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 Pro-
dukte bereitstellen.
Aufbauend auf der Technologie des Grundsytems sollen zudem bereits frei verfügbare Produkte 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.
2
http://www.opensource.org/licenses/bsd-license.php
52
4.2. Kommunikation und Zusammenarbeit
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 zuge-
griffen werden kann. Eine weitere Möglichkeit ist eine Synchronisations-Software, welche die Daten bei
einer bestehenden Internetverbindung abgleicht. Der Unterschied besteht darin, wo die Daten liegen
und wann darauf zugegriffen werden kann.
Auf Daten einer webbasierten Applikation kann nur bei bestehender Internetverbindung zugegriffen
werden. Die Daten werden innerhalb der Applikation, meist in einer Datenbank, gespeichert. Besteht
keine aktive Internetverbindung, so gibt es keine Möglichkeit, auf Informationen zuzugreifen. Einen
Schritt weiter gehen sogenannte verteilte Applikationen, welche eine „Working Copy“ der gesamten
Infrastruktur lokal speichern. Bei bestehender Internetverbindung 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 web-
basierte Version öfters an.
4.1.4. Mehrsprachig
Obwohl sich in der Informatik die Sprach Englisch durchgesetzt hat, soll die Plattform in Hinblick auf
die verteilte Benutzung eine optimale Unterstützung für Mehrsprachigkeit bereitstellen, 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 Auftragsmanagement.
Für eine gute Zusammenarbeit wird bereits in der Initialisierungs- und Etablierungsphase eine gemein-
same Sprache festgelegt. Werden wichtige Elemente auf einer Plattform übersetzt, so ist diese Grund-
lage nicht mehr gegeben. Diese sollen somit nur in einer Sprache zur Verfügung stehen. Als Beispiel
seien hier Begriffe aus der Produktentwicklung (Story, Task) und dem Projektmanagement (Artefakte)
genannt.
Bei der Kommunikation geht es zum einen um die Kommunikation zwischen den Teammitgliedern 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 Netzwerkkommuni-
kation 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 einem grossen Anteil auch die Art der Zusammenarbeit der beteiligten Pro-
jektmitglieder. Der Austausch von Informationen und Wissen und die Zusammenarbeit gilt als wichtiger
53
sozialer Erfolgsfaktor in einem Projekt und muss bei der Verwendung einer Projektmanagementplatt-
form in geeigneter Form unterstützt werden.
4.2.1. E-Mail
Für die E-Mail-Kommunikation werden meist Standalone-Applikationen wie Microsoft Office/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, sondern 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 versenden3
4.2.2. Kontaktmanagement
Alle Projektmitglieder erhalten über einen Benutzernamen und ein Passwort Zugang zur Plattform,
wodurch Zugriffsberechtigungen geregelt werden. Eine vollständige Liste aller Benutzer kann somit
auch als Kontaktverwaltung ausgelegt werden und als Grundlage für alle Kontaktinformationen dienen.
Des Weiteren sind in einem Projekt Personen beteiligt, welche keinen 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 Kontaktverwaltung 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 definieren. 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, Abgabetermine, Kalendereinträge, . . . ) anzeigen
zu lassen
3
Aufgrund der Redundanz ist es sinnvoller, Medien selbst nicht zu versenden, sondern nur darauf zu verlinken
54
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
• 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. Instant Messaging
Mit einer Messaging-Funktion können zwei oder mehr Nutzer in Echtzeit schriftlich miteinander kom-
munizieren. Das Chatten ist ein beliebtes und verbreitetes Kommunikationshilfsmittel und bietet oftmals
zur schriftlichen Kommunikation auch Sprach- und Videoübertragung und die Möglichkeit des Daten-
austauschs. Im Gegensatz zum Forum müssen die Benutzer beim Chatten gleichzeitig online sein.
• dass mehrere Benutzer gleichzeitig 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 infor-

miert wird, sobald es sich einloggt
• bestehende Chat-Clients (z.B. Skype) zu integrieren, resp. den Status eines anderen Mitglieds
zu sehen
4.2.6. Nachrichtenboard
Ein Nachrichtenboard auf einer Plattform entspricht einer Pinnwand oder einem Whiteboard, auf wel-
chem Nachrichten hinterlegt werden können, die für alle Mitglieder wichtig sind. Da es sich hierbei um
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
55
4.2.7. Umfragen
Umfragen dienen zur quantitativen Erhebung von Fragestellungen.
• Umfragen einem Projekt zuzuweisen

• die Anzeige einer Umfrage personen- oder gruppenspezifisch sowie zeitlich einzuschränken
• das Resultat graphisch darzustellen
4.3. Informations- und Datenmanagement
Ein wichtiger Faktor in einem Projekt ist die Information. Moderne Projektmanagement-Methoden set-
zen dabei auf absolute Transparenz. Es geht darum informiert zu sein, wo das Projekt steht, woran
die anderen Mitarbeiter zurzeit 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 Dokumentemanagement-

system 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 be-
reitgestellt, welche direkt im System abgelegt wird. Hierbei ist eine Versionierung zur Nachverfolgung
sehr nützlich.
4.3.1. Dokumentemanagement
Als Dokumentemanagement wird jegliches Handling von Artefakten verstanden. Sie ermöglichen nebst
dem Speichern und Bearbeiten von Dokumenten auch die Verwaltung von Zugriffsberechtigungen. 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ückgängig
gemacht werden. Eine Versionshistory sollte automatisch erstellt werden und die Möglichkeit bereitstel-
len, eine neuere Version zu kommentieren und somit die Änderungen nachvollziehbarer zu machen.
4.3.3. Strukturierung
Für die strukturierte Ablage von Dokumenten soll die Möglichkeit zur Erzeugung einer Ordnerstruktur
vorhanden sein. In einem weiteren Schritt ist es denkbar, die Ordnerstruktur anhand der Klassifizierung
eines Projektes automatisch zu erzeugen (vgl. Tabelle 3.2).
56
4.4. Projektmanagement
4.3.4. Wissenserhaltung und Wissensfindung
Wissen ist in der heutigen Informationstechnologie ein wichtiges Gut. Mit jedem Mitarbeiterwechsel,
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 an alle Mitarbeiter eines Unternehmens versen-
det wurden mit der Hoffnung, jemanden zu finden, 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 Kon-
taktmanagementsystem 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 Verlin-
kungen zu erstellen
• den Zugriff personen- oder gruppenbezogen zu beschränken
Im Bereich des Projektmanagements soll die Plattform das Management der ökonomischen Projekt-
ziele Leistung, Kosten und Termine sowie Inhalte, Ressourcen und Änderungen überwachen sowie die
Prozessabläufe begleiten. Dabei muss die Plattform flexibel genug sein, um nicht nur eine Manage-
menttheorie zu unterstützen, sondern traditionelle wie auch agile Methoden bereitstellen können. Das
System greift dabei auf die Funktionalitäten der Kommunikation und des Informations- und Datenma-
nagements 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 Workflows.
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 innerhalb eines Projektes. Die Änderungen rühren von inneren wie auch
äusseren Einflüssen her. Jeder Projektleiter, jedes Teammitglied und jeder Kunde hat andere Vorlieben
und für die Benutzung einer Projektmanagement-Plattform. Somit ist es grundlegend, dass die Plattform
an verschiedene Bedürfnisse angepasst werden kann, benutzerfreundlich ist und einen entscheidenden
Mehrwert liefern soll. Teammitgliedern, welche sich nicht an die vorgegebene Managementmethode
57
halten 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 Meetings
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 las-
sen
4.4.2. Management von Input und Output
Im Bereich des Projektmanagement lege ich den Fokus auf den Management- und den Entwicklungs-
prozess. Die elektronisch unterstützbaren Aspekte der Führung werden subsumiert, da in der Manage-
menttheorie und der Kommunikation bereits ein Grossteil der Führung festgelegt wird.
Betrachten wir die traditionellen 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 bestimmt 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 Un-
terstü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 Entschei-
dungshilfen sind folgende:
• Ist eine verbindliche Vorlage vorhanden (z.B. Excel- oder Word-Template), welche aufgrund fir-
meninterner 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 sol-
che 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 Verbreitung kann danach das
Projektmanagementsystem verwendet werden. Ebenfalls wird über die Rechteverwaltung der Zugriff
eingeschränkt. Die Pläne aus dem Qualitätsmanagement (Kapitel 3.2.3.3, 3.3.1) und dem Risikomana-
gement (Kapitel 3.2.3.2,3.3.1) gehören gemäss dem Fragekatalog ebenfalls ins Dokumentemanagement-
System.
Da agile Methoden ein höheres Mass an Zusammenarbeit der einzelnen Teammitglieder und verteil-
te 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
58
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 Kontaktmanagement
erstellt, um redundante Daten zu vermeiden. Durch die Zuweisung einzelner Personen zu bestimmten
Gruppen werden gleichzeitig auch die Berechtigungen für die Ressourcenverwaltung 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 Projektmee-
ting 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.
4.4.4. Aufgabenmanagement
Das Aufgabenmanagement ist von der gewählten Projektmanagementmethode abhängig. Bei traditio-
nellen Methoden werden Aufgaben vom Projektleiter an die Teammitglieder delegiert, bei agilen Metho-
den organisiert sich das Team selbst und entscheidet, wie viele Aufgaben es in einer bestimmten Zeit
erledigen kann.
Für traditionelle 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 zerlegt 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 vorgegebenen 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 eigenen Time Tracker-
Bereich zu erstellen, wo alle Stunden zusammengetragen werden.
59
4.4.5. Änderungsmanagement
Die Produktdefinition und Zielsetzung des Projekts verändert sich während der Entwicklung laufend.
Das Änderungsmanagement als Überbegriff ist im Bereich der Systemelemente und der Projektma-
nagementfunktionen angesiedelt und betrifft das Konfigurations- und Inhaltsmanagement (vgl. Kapitel
3.2.3.5 und 3.3.1). Agile Methoden wie Scrum integrieren das Änderungsmanagement im Hauptpro-
zess (vgl. Kapitel 3.4.3.1). Für das Management und die Nachverfolgung von Änderungen eignet sich
ein Tracking-System.
• Änderungen von Kunden und Teammitgliedern zu erfassen

• die Zuständigkeit an eine Person zu delegieren
• Änderungen zu strukturieren und nach Wichtigkeit zu klassifizieren
• die richtigen Personen über die Änderungsanträge automatisch zu informieren
4.4.6. Workflows
Das Projektmanagement entwickelte sich vom Chaos hin zur Produktorientierung und wird in moder-
nen Ansätzen durch die Prozesse erweitert (vgl. Kapitel 3). Die Prozesse im Zusammenhang mit dem
Projektmanagement spezialisieren sich auf die Informationsverteilung und -strukturierung. Um diese
abzubilden, werden während der Projektinstitution (vgl. Kapitel 3.2.1) im Bereich des Kommunikations-
managements (vgl. Kapitel 3.3.1) der Dokumentations- & Dokumentenablageplan und die Informations-
verteilung definiert. Für die Ausführung der automatischen Prozesse wird ein Regelsystem benötigt,
welches Inhalte überwacht und gewünschte Aktionen auslöst (vgl. Kapitel 6.3.4).
• Objekte zu überwachen
• mehrere Bedingungen kumulativ auf ein Objekt anzuwenden
• mehrere Aktionen kumulativ auszuführen
4.5. Fazit
Aufgrund der Einzigartigkeit von Projekten und firmeninternen Richtlinien, den Vorlieben und Gewohn-
heiten der Stakeholder und den Randbedingungen und der Klassifizierung jedes einzelnen Projekts
unterscheidet sich die Notwendigkeit und Ausprägung einzelner Funktionen von Projekt zu Projekt. An-
hand der grundlegenden Anforderungen aus diesem Kapitel soll es möglich sein, das Grundmodul an
unterschiedliche Projekttypen, Stakeholder und Abläufe flexibel anzupassen. Dabei bleibt die gesamte
Struktur skalierbar. Das Ziel einer guten Projektmanagement-Plattform liegt also nicht darin, die einzig
richtige Lösung abzubilden, sondern eine Vielzahl von Funktionen und dynamischen Prozessen be-
reitzustellen, 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.
60
5. Tool-Evaluation
Die Liste verfügbarer Managementplattformen auf dem Markt ist sehr lang. Viele dieser Plattformen fo-
kussieren auf das Dokumente- und Aufgabenmanagement und weisen zum aktuellen Zeitpunkt einen
erfolgsversprechenden Stand der Entwicklungen auf. Dieses Kapitel soll Aufschluss darüber bringen,
inwiefern sie die Prozessdifferenzierung unterstützen. Der Fokus der meisten Produkte auf den klassi-
schen Managementprozess schränkt die individuelle Anpassung und die Zusammenarbeit ein. Berei-
che wie Kommunikation, Abbildung von Arbeitsprozessen und die Integration der Produktentwicklung
stehen im Zentrum der Untersuchung.
In Anlehnung an Spath u. a. (2007) werden 17 Open Source-Kollaborationsplattformen auf ihre Eig-

nung in den Bereichen Kommunikation, Informations- und Datenmanagement und Projektmanagement
untersucht. Sechs davon werden detaillierter beschrieben. Darauf folgen die neusten Entwicklungen
aus dem Bereich des File Sharing. Aufgrund der hohen Verbreitung werden anschliessend Produkte
aus der Microsoft-Familie auf deren Eignung untersucht sowie Alternativen aufgelistet. Zum Abschluss
folgen Systeme für die Produktentwicklung.
5.1. Toolauswahl
Eine Kollaborationsplattform unterstützt die Organisation bei der Kommunikation, Koordination und Ko-
operation innerhalb eines Projektes. Tabelle D.1 listet die 17 untersuchten OpenSource-Kollaborationsplattformen
sowie die dafür benötigte IT-Infrastruktur und die Lizenz. Die meisten dieser Plattformen unterstützen
ebenfalls grundlegende Funktionen für das Projektmanagement.
Abbildung 5.1 stellt in einem Balkendiagramm alle 17 Tools der Studie mit den erhaltenen Punkten in
den Kategorien Kommunikation, Projektmanagement und Informations- und Dokumentemanagement
dar. In den folgenden drei Kapiteln 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 min-
destens 6 von 10 möglichen Punkten und weisen somit in allen Bereichen einen überdurchschnittlichen
Funktionsumfang auf. Obwohl „Plone“ im Bereich der Kommunikation und des Projektmanagements nur
je 4 Punkte erhält, ist es das einzige Produkt, welches im Informations- und Dokumentemanagement
die volle Punktzahl erhält.
5.1.1. PHProject
PHProject ist mit der maximalen Punktzahl in der Kommunikationsunterstützung und im Projektmana-
gement und 9 von 10 möglichen Punkten im Informations- und Datenmanagement das bestklassierte
61
5. Tool-Evaluation
Abbildung 5.1.: Eignung der Tools nach Spath u. a. (2007)
62
5.1. Toolauswahl
Abbildung 5.2.: Kiviatdiagramm der Top5 Tools und Plone nach Spath u. a. (2007)
Kollaborationssystem nach Spath u. a. (2007). Mit Apache als Webserver, mySql als Datenbank und
PHP als Skriptsprache ist es schnell installiert und lauffähig. PHProject ist ein weit verbreitetes und
ausgereiftes System, dessen Zukunft optimistisch eingeschätzt werden kann. Neue Releases warten
regelmässig mit umfangreichen Erweiterungen und funktionalen Verbesserungen auf. Die Nutzung ist
nicht immer intuitiv und benötigt Einarbeitungszeit, dafür stehen auf der Projektseite gute Dokumenta-
tionen in verschiedenen Sprachen bereit. PHProject ist ein modulares Werkzeug im Web für Gruppen
zur Koordination von Terminen, Informationen und Dokumenten, unter anderem mit Gruppenterminka-
lender, Projektmanagement, Zeiterfassung, Dokumentenverwaltung, Kontakt Manager, Mail client und
vielen weiteren Modulen. PHProject unterstützt viele Protokolle (ldap, soap, webdav u.a.) und ist in 38
Sprachen und für 9 Datenbanken verfügbar. Eine genaue Auflistung aller Funktionalitäten der Version
4.1 befindet sich im Anhang D.2.
Test: PHProject 5.2, mySql 5.0.51, PHP 5.2.5 (lokale XAMPP Installation)
Nach dem Einrichten einer leeren Datenbank und dem Entpacken der Installationsdatei von der Pro-
jektseite1 kann die Installationsroutine über die Datei setup.php aufgerufen werden. In der dialog-
geführten Installation können bereits einige Einstellungen gemacht werden, darunter Sprache und die
Aktivierung zusätzlicher Module. Nach der Installation können über die Administrationsoberfläche alle
Einstellungen sowie neue Benutzer und Projekte erfasst werden. Die Installation ist einfach und stellt
schnell eine betriebsfähige Plattform bereit. PHProject kann sowohl im Intranet wie auch im Internet
genutzt werden und unterstützt somit auch die Zusammenarbeit mit Kunden und Benutzern, welche
von ausserhalb des Firmennetzes zugreifen möchten.
1
http://www.phprojekt.com/index.php?name=Downloads&req=viewdownloaddetails&lid=4
63
5. Tool-Evaluation
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 fehlen die webbasierte Administration und
Programme sowie Schnittstellen von Drittanbietern. Ebenso sind einige Erweiterungen kostenpflichtig,
zum Beispiel die Integration von Microsoft Outlook über sogenannte Konnektoren. Durch die kommer-
zielle Version ist die Weiterentwicklung grösstenteils gesichert und über eine Roadmap einsehbar.
„Open-Xchange“ kann für Hosting Provider auch als Hosting Package gekauft werden. Dadurch können
dem Benutzer nebst dem herkömmlichen Webmail erweiterte Kollaborations-Funktionen bereit gestellt
werden. In der Schweiz verfügt „Hostpoint“ über ein „Open-Xchange“ System.
Test: „Open-Xchange Express Edition“ mit „VMWare“

Die freie Version „Open-Xchange Express Edition“ kann als Download2 bezogen werden. Das Package
mit einer Grösse von rund 600MB stellt das komplette System bereit, ein VMWare Image für einen
virtualisierten Server kann ebenfalls auf der gleichen Seite heruntergeladen werden. Zu Testzwecken
kann Open-Xchange Outlook OXtender (Integration von Microsoft Outlook) in den Sprachen Deutsch,
Englisch und Französisch als Trial-Version getestet werden. Die Installation des VMWare Images ist
schnell vollbracht. Das Einrichten der Benutzer und die Konfiguration sind intuitiv, und durch Freigabe
des Servers kann aus dem Intranet und dem Internet darauf zugegriffen werden. Mehr Details finden
sich auf der Projekthomepage3 und im Anhang D.3.
5.1.3. eGroupWare
„eGroupWare“ ist eine Groupwarelösung mit allen Funktionen einer Kollaborationsplattform. Für die Un-
terstützung des Projektmanagements steht ein Modul zur Verfügung, mit dem sich auch eine Wissens-
datenbank und Workflows erstellen lassen. Für grössere Projektportfolios ist das System gut skalierbar.
Hervorzuheben ist die detaillierte Dokumentation, welche die Einarbeitung erleichtert. Eine Stärke liegt
darin, dass Funktionalitäten wie Termine, Kontakte und Dokumente untereinander verlinkt werden kön-
nen.
Test: eGroupWare 1.4.004, mySql 5.0.51, PHP 5.2.5 (lokale XAMPP Installation)
Mit etwas Vorkenntnissen ist die Installation schnell durchgeführt und das System einsatzbereit. Der
Administrator verfügt über ein umfangreiches Einstellungs-Tool zur Einrichtung aller nötigen Funktiona-
litäten. Neue Benutzer und Projekte sind einfach zu erstellen und benötigen keine grosse Einarbeitungs-
zeit. Das Layout ist sehr benutzerfreundlich und modern aufgebaut. Über die horizontale Navigation ist
ein schneller Zugriff auf alle Module möglich, die Seitennavigation wird für jedes Modul neu aufge-
baut und stellt alle gewünschten Funktionalitäten bereit. Weitere Informationen können im Anhang D.4
nachgelesen werden.
5.1.4. Simple Groupware
Simple Groupware verfügt über einen beachtlichen Funktionsumfang im Bereich der Kommunikati-
on und Integration externer Anwendungen. Hinter der baumartigen Ordnerstruktur verbergen sich die
2
http://www.open-xchange.com/de/produkte/open-xchange-express-edition-de/download
3
http://www.open-xchange.com
64
5.1. Toolauswahl
Funktionalitäten der Plattform. Die Möglichkeiten im Bereich des Projektmanagements sind leider etwas
eingeschränkt. Ein detaillierter Funktionsbeschrieb befindet sich im Anhang D.5.
Test: Simple Groupware 0.414, mySql 5.0.51, PHP 5.2.5 (lokale XAMPP Installation)
Die Installation ist einfach und schnell. Danach kommt man direkt in die Administrationsoberfläche.
Die Navigation geschieht über eine Baumstruktur wie sie aus dem Windows Explorer bekannt ist. Die
Administration geschieht über eine Reiter-Leiste oberhalb des Inhaltes. Zu den einzelnen Einträgen,
egal ob Termin, Stundenzettel oder Kontakt, können zahlreiche Informationen hinterlegt werden. „Sim-
ple Groupware“ ist von allen untersuchten Tools dasjenige, welches am meisten Formulardaten für die
Speicherung von Informationen bereitstellt.
5.1.5. IGSuite
Die „Software Integrated Groupware Suite“, kurz „IGSuite“, stellt eine breite Palette von Funktionalitäten
bereit und fokussiert auf das Customer Relationship Management (CRM). Es richtet sich hauptsächlich
an Unternehmen mit Schwerpunkt auf Kommunikation, Ressourcen- und Arbeitsteilung und Dokumen-
temanagement. Die IGSuite schneidet in den untersuchten Bereichen überall mit 7 von 10 möglichen
Punkten ab und bietet somit einen ausgeglichenen Mix an Unterstützung und Funktionen. Zu bemän-
geln ist der fehlende deutschsprachige Support des italienischen Herstellers.
Test: IGSuite 3.2.4, Online Demo

Für die Tests wurde der Demo-Account der Projekthomepage4 verwendet. Leider stand kein deutsches
Sprachfile zur Verfügung. Die Bedienung ist intuitiv und das Layout modern. Man erhält Unterstützung
im Projektmanagement, jedoch fehlen die klassischen Projektmanagement-Tools. Auch die Benutzer-
verwaltung mit den Zugriffsrechten kann noch verbessert werden. Eine kurze Übersicht befindet sich
im Anhang D.6.
5.1.6. Plone
„Plone“ gilt als Content Management System mit intuitiver Bedienung und einem sehr ausgereiften Do-
kumentemanagementsystem. Als einziges Produkt erreicht es in diesem Bereich die volle Punktezahl.
Es lassen sich umfangreiche Arbeitsabläufe und -prozesse abbilden und unterstützten den Benutzer
auch bei unstrukturierten Aufgaben. Durch die starke Community steht für „Plone“ eine grosse Anzahl
von frei verfügbaren Erweiterungen zur Verfügung. Als klassisches CMS kann „Plone“ im Intranet wie
auch im Internet eingesetzt werden. Das ausgereifte Benutzerberechtigungssystem regelt alle Zugriffe
und kann auch auf Erweiterungen Dritter angewandt werden. Obwohl „Plone“ im Bereich der Kommuni-
kation und des Projektmanagements unterdurchschnittlich abschneidet, eignet sich das CMS durch die
Stärke im Dokumentemanagement und dem einfachen Abbilden von Arbeitsabläufen und -prozessen
für den Einsatz als Projektmanagement-Plattform.
Test: Das Testprojekt mit „Plone“ wird im Kapitel 7 detailliert beschreiben.
4
http://demo.igsuite.org
65
5. Tool-Evaluation
Virtuelle Projektteams, welche räumlich getrennt arbeiten, benötigen vermehrt Techniken zur Kommu-
nikationsunterstützung. Darunter fallen synchrone und asynchrone Kommunikationswege (Mail, Forum,
. . . ). Die genauen Anforderungen sind in Kapitel 4.2 definiert.
PHProject
E-Mails können über den Client verwaltet werden. Eine Integration der Daten aus Microsoft Outlook ist
ebenfalls möglich. Die asynchrone Kommunikation wird über Nachrichtenboards und ein Forum unter-
stützt, für direkten Nachrichtenaustausch steht ein Chat zur Verfügung. Für Umfragen steht zusätzlich
eine Polling-Funktion bereit. Über die Kontaktverwaltung lassen sich Kontakte in Gruppen zusammen-
fassen und in Terminen, Aufgaben und Projekten darauf verweisen.
Open Xchange
„Open-Xchange“ verfügt über ein funktional ausgereiftes Kontaktmanagement-Tool, mit welchem Da-
teien einem Kontakt zugewiesen und Termine, Aufgaben und Projekte direkt verknüpft werden können.
Der Zugang zu den Kontaktdetails wird über Berechtigungen geregelt. Die Integration von Microsoft
Outlook ist gewährleistet (kostenpflichtig) und bietet mit der Darstellung als Textnachricht eine hohe
Sicherheit. Eine zentrale Bookmarkverwaltung, Diskussionsforum und ein Nachrichtenboard sind eben-
falls vorhanden.
eGroupWare
„eGroupWare“ ermöglicht die Integration von externen Kontaktdaten, zum Beispiel aus Microsoft Out-
look. Ein E-Mail-Client steht ebenfalls zur Verfügung. Für die asynchrone Kommunikation verfügt das
System über ein Forum. Mailinglisten und Umfragen können eingerichtet werden, jedoch steht kein
Nachrichtenboard zur Verfügung. Eigene Bookmarks und eine Echtzeit-Kommunikation über Chat feh-
len.
Simple Groupware
Im Kontaktmanagement lassen sich viele Angaben sammeln und als Visitenkarten übersichtlich darstel-
len. Auch Hierarchie-Strukturen lassen sich abbilden. Für die Mail-Kommunikation stehen Verbindun-
gen von IMAP und POP3 zur Verfügung sowie Nachrichtenboards, Foren und Echtzeit-Chats. Book-
marks aus Firefox können ebenfalls integriert werden. Im Bereich der Kommunikation fehlen jedoch
Mailinglisten und Umfragen.
IGSuite
Für das Kontaktmanagement stehen umfassende CRM-Funktionalitäten bereit. Es können eine Viel-
zahl von Informationen und Aufträge bei einem Kontakt hinterlegt werden. Im Zusammenhang mit den
dem Kunden zugewiesenen offenen To-Dos ist eine umfassende Historie des Kontakts verfügbar. Für
den E-Mail-Verkehr steht ein Webmail-Client zur Verfügung, Echtzeit-Kommunikation wird über den in-
tegrierten Chat abgewickelt. Als einziges Tool hat die „IGSuite“ einen Fax-Client integriert, welcher die
66
Nachverfolgung der Faxkorrespondenz unterstützt. Forum, Mailinglisten, Umfragen-Tool und Nachrich-

tenboard fehlen.
Plone
Über die Benutzerverwaltung können Kontakte organisiert werden. Jeder Artikel in „Plone“ kann an
Mitglieder versendet werden, mit einer Erweiterung ist auch der Versand an ganze Gruppen möglich.
Foren und Mailinglisten werden ebenfalls durch Dritte angeboten. Integriert sind eine Chat-Funktion
sowie ein Nachrichtenboard und die Möglichkeit, Umfragen zu starten. Als CMS bietet „Plone“ ein
benutzerspezifisches Portal, auf welchem Bookmarks hinterlegt werden können.
Es gilt anzumerken, dass „Plone“ sich als CMS mit einer starken Community im Hintergrund auf die
Verwaltung von Inhalten spezialisiert. Dadurch ist die tiefe Bewertung von 4 Punkten mit Vorsicht zu
betrachten. Durch eine grosse Anzahl von frei verfügbaren Erweiterungen können die fehlenden Funk-
tionalitäten nachinstalliert werden. Eine weitere Eigenschaft eines populären Open Source CMS ist die
konstante Weiterentwicklung und die Möglichkeit, gewünschte Funktionalitäten für kommende Relea-
ses vorzuschlagen. Das modulare Wachstum erstreckt sich in viele Richtungen.
Fazit
„PHProject“ schneidet im Bereich der Kommunikationsunterstützung am besten ab, gefolgt von „Open
Xchange“ und „SimpleGroupware“. Sie bieten in diesem Bereich zusätzliche erweiterte Funktionen
für individuelle Anpassungen. „eGroupware“, „IGSuite“ und „Plone“ verfügen über Standardanforde-
rungen. Diese Produkte verfügen bereits in den Standardversionen über eine breite Unterstützung
im Bereich von asynchronen Kommunikationswegen. Sie integrieren E-Mail-Funktionen, Kontaktma-
nagement, Bookmarks und Foren. Im Bereich der synchronen Kommunikation können „PHProject“ und
„SimpleGroupware“ weitere Punkte holen.
In das Informations- und Datenmanagement gehören die Dokumenteablage und -strukturierung, Such-
funktionen, Auswertungs- und Darstellungsfunktionen. Die genauen Anforderungen sind in Kapitel 4.3
definiert.
PHProject
Dateien lassen sich in „PHProject“ zentral speichern und können zu Objekten der Projekthierarchie
zugewiesen werden. Für den Datenaustausch ist ein FTP-Client integriert. Der Zugriff auf das Dateisy-
stem wird durch die Benutzerberechtigung gesteuert.
Open-Xchange
„Open-Xchange“ verfügt über ein Dokumentemanagementsystem mit persönlichen und geteilten Ord-
nern, dem sogenannten „Infostore“. Die öffentlichen Ordner werden auf dem Server freigegeben und
sind für alle zugänglich. Dateien können aus E-Mails direkt mittels Drag-n-Drop in die Ordner abgelegt
werden. Ebenso steht eine Versionierung zur Verfügung. Ein Wiki ist nicht verfügbar.
67
5. Tool-Evaluation
eGroupWare
„eGrouWare“ speichert Dateien auf dem Webserver. Das Verzeichnis kann während der Installation an-
gegeben und jederzeit geändert werden. Die Dokumente werden in einer Ordner-Hierarchie strukturiert
und verfügen über Versionierung, Zugriffsberechtigung und Versandmöglichkeiten. Standardmässig ist
zudem ein Wiki und eine durchsuchbare Wissensdatenbank integriert.
Simple Groupware
Die Speicherung von unterschiedlichen Dateitypen ist möglich, bei vielen ist auch eine Vorschau verfüg-
bar. Die Dateien können farblich kategorisiert und durchsucht werden. Ebenso kann ihnen ein Status
zugewiesen werden. Ein Dokument wird allgemein als Element interpretiert und kann mehrere Versio-
nen beinhalten. Dazu wird die History jedes Elements festgehalten. Ein Wiki ist nicht vorhanden.
IGSuite
Das System verfügt über ein Wiki und eine Notizfunktion. Dokumente können strukturiert abgelegt und
verlinkt werden. Eine Versionierung ist jedoch nicht möglich. Eine Zugriffsbeschränkung auf Dateien im
IGFile-Service gibt es nicht. Auf fremde Dateien hat der Benutzer standardmässig Lese-, aber keine
Schreibrechte.
Plone
In „Plone“ entspricht eine Datei einem Artikel und unterscheidet sich von den Möglichkeiten her nicht
vom übrigen Inhalt. Dadurch sind Arbeitsabläufe und -prozesse auch auf Dateien anwendbar. Die Da-
teiablage wird über die Navigationsstruktur organisiert. Dabei können die Dateien auf dem Dateisystem
oder direkt in die Datenbank gespeichert werden. Der Zugriff wird durch das Benutzerberechtigungssy-
stem organisiert, wobei der Zugriff einzelnen Personen, Rollen oder Gruppen gewährt werden kann.
Fazit
„eGroupWare“ verfügt als einziges System über kein ausgereiftes Dokumentemanagementsystem mit
Zugriffsberechtigungen und erweiterten Suchfunktionalitäten, bietet dafür ein Wiki an. Alle Systeme
bieten erweiterte Funktionalitäten an und eignen sich für die strukturierte Ablage von Dokumenten.
Für die Untersuchung im Bereich des Projektmanagement zählen Funktionalitäten zur Planung und
Ausführung eines Projekts. Funktionen wie Kalender, Ressourcen- und Aufgabenverwaltung gelten als
minimaler Standard. Als erweiterte Funktionen gelten Hierarchien der Arbeitspakete (z.B. Taskverwal-
tung) und visuelle Darstellungen von Plänen. Die genauen Anforderungen sind in Kapitel 4.4 defi-
niert.
68
PHProject
„PHProject“ zeichnet sich durch eine sehr gut strukturierte und umfangreiche Funktionalität für die Ver-
waltung von Projekten aus. Projekte und Aufgaben können Personen oder Gruppen zugewiesen und
die Aufgabenpakete hierarchisch strukturiert werden. Für ein Projekt steht eine Vielzahl von Merkmalen
zur Verfügung. Zur Nachverfolgung des aktuellen Projektfortschritts stehen die Verwaltung von Meilen-
steinen und Gantt-Charts bereit. Für den Ablauf können Workflows definiert werden, welche die Ar-
beitsschritte der Benutzer begleitet. Der Kalender, welcher auch als Gruppenkalender benutzt werden
kann, prüft automatisch auf Terminkollisionen und unterbreitet Alternativvorschläge.
Open Xchange
„Open-Xchange“ verfügt über einen sehr ausgereiften Kalender und über eine Aufgabenverwaltung.
Weitere Funktionen sind in der frei verfügbaren Version nicht vorhanden. Die kommerzielle Version
verfügt über eine Projektmanagement-Funktionalität zur Überwachung des Projektstands, der Meilen-
steine und der Zuteilung von Aufgaben an Mitarbeiter.
eGroupWare
In „eGroupWare“ können Projekte angelegt und nachverfolgt werden. Gantt-Charts werden automa-
tisch aus der Projektdefinition erstellt. Über den Stundenzettel können Arbeitsstunden direkt auf das
Projekt gebucht werden. Über die gesamten Informationen steht ein CSV Export und eine übersichtli-
che Druckfunktion zur Verfügung. Für die Terminverwaltung stehen persönliche und Gruppenkalender
mit verschiedenen Darstellungsoptionen bereit. Weitere Mitglieder oder Gruppen können zu einem Ter-
min eingeladen und Dokumente angehängt werden. Auch wiederholte Termine sind möglich. Integriert
ist eine automatische Überprüfung auf Terminkollisionen.
Simple Groupware
Projekte können bei „Simple Groupware“ mit umfangreichen Informationen angelegt werden. Ebenso
stehen ein Kalender für die Verwaltung der Termine und ein Ressourcenplaner zur Verfügung. Eine
Aufgabenverwaltung ist nicht vorhanden, daher eignet sich die Plattform nicht für die Zuweisung von
Tasks, es können jedoch Stunden auf Projekte gebucht werden.
IGSuite
Die „IGSuite“ fokussiert auf Kundenmanagement und bietet dazu eine umfassende Ablagemöglichkeit
von Informationen und Dokumenten. Klassische Projektmanagement-Funktionen fehlen. So können
keine eigenen Projekte und projektspezifische Aufgaben erstellt werden. Dafür ist ein übersichtlicher
Kalender die Verwaltung von Ressourcen verfügbar.
Plone
Ein Termin ist in „Plone“ ein Artikel und verfügt somit über alle bekannten Funktionalitäten für Inhalte.
Weitere Mitglieder können jedoch nicht eingeladen werden. Der Hinweis auf einen Termin kann aber
an andere Benutzer oder Gruppen versendet werden. Zur Integration in eine lokale Agenda können
Termine als vcs-Datei geöffnet werden. Des Weiteren bietet „Plone“ selbst keine Unterstützung für
69
5. Tool-Evaluation
Projektmanagement, dafür steht aber eine kostenlose Erweiterung namens „eXtreme Management“
zur Verfügung, welches den Prozess eines XP-Projektes abbildet. Dadurch können Projekte definiert,
Tasks erstellt und an Projektmitglieder delegiert werden. Ebenso können Stunden erfasst und dadurch
der Projektfortschritt mitverfolgt werden.
Fazit
Im Bereich des Projektmanagements schneiden „PHProject“, „eGroupware“ und „Open Xchange“ (je-
doch nur in der kostenpflichtigen Version) mit erweiterten Anforderungen am besten ab. „IGSuite“, „Sim-
ple Groupware“ und „Plone“ verfügen über den minimalen Standard. Durch Produkte von Drittanbietern,
welche bei „Plone“ installiert werden können, bietet es die erweiterten Anforderungen an.
5.5. File Sharing
File Sharing-Tools unterstützen den Benutzer bei der Verteilung und Nutzung von gemeinsamen Da-
ten. 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.
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“ Ord- individuell individuell
ner
Einstellung Synchronisation Automatisch gan- File Browser Online oder lokal
zer Ordnerinhalt
Integration Kontextmenü nur innerhalb „My „Share“ und „Add“- -
Dropbox“-Menü Funktion
Versionierung x x -
Speziell History Verknüpfung von Integration in Mi-
GoogleDocs und crosoft Dienste
iPaper
Tabelle 5.1.: Vergleich von File Sharing Tools
Alle Tools laufen im Hintergrund und synchronisieren die verteilten Ordner bei bestehender Internetver-
bindung. 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.
70
5.5. File Sharing
5.5.1. Dropbox
Dropbox5 ist eine frei verfügbare Software im Private Beta-Stadium für die verteilte Nutzung von Da-
teien. Die Installationsdatei für Windows oder Mac ist ca. 7MB gross. Nach der Installation werden
alle Dateien im Ordner <EIGENE_DATEIEN>/My Dropbox synchronisiert. Ein bestehender Ord-
ner kann über das Webinterface mit weiteren Benutzern geteilt werden. Hierfür kann die Einladung an
eine beliebige Mail-Adresse versendet werden.
Abbildung 5.3.: Online Ordner History von Dropbox
Ein grosser Vorteil von Dropbox ist die History und Versionierung. Während lokal die aktuellsten Versio-
nen der Dateien gespeichert werden, können über das Webinterface auch ältere Dateiversionen her-
untergeladen werden. Dropbox fungiert hier als Online-Repository. Die Versionierungsfunktion 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.
Abbildung 5.4.: Online Versionierung von Dropbox
Im Internet Explorer wird der aktuelle Status der Dateien angezeigt, wobei zwei weisse Pfeile auf blau-
em Hintergrund bedeuten, dass der Ordner oder die Datei sich noch in der Synchronisation befindet.
5
www.getdropbox.com
71
5. Tool-Evaluation
Abbildung 5.5.: Lokale Ordner-Markierung von Dropbox
5.5.2. Syncplicity
Syncplicity6 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 Kontextmenü 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.6.: 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, Administrations-
aufgaben auszuführen.
Im Beta-Stadium sind der Datentransfer und der verfügbare Speicherplatz unbeschränkt. Danach wird
er auf 2GB und 2 Computer limitiert. Syncplicity stellt auch ein Modell für die kommerzielle Nutzung zur
6
www.syncplicity.com
72
5.5. File Sharing
Verfügung. Hierbei können für 99$ pro Jahr total 40GB Datenspeicher und unlimitierte Computer kon-
figuriert werden. Mit zusätzlichem Versand von Einladungen an Freunde können pro Annahme weitere
250MB freigeschaltet werden, dies bis zu 10GB zusätzlich.
Abbildung 5.7.: Ordner Kennzeichnung mit Syncplicity
Wie auch bei Dropbox werden die in der Synchronisation eingeschlossenen Ordner durch ein Sym-
bol markiert (siehe Abbildung 5.7). Die abgeglichen Dateien erhalten durch einen grünen Haken eine
entsprechende Kennzeichnung (siehe Abbildung 5.8). Die Kennzeichnung ist nur im Online-Modus ver-
fügbar.
Abbildung 5.8.: 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 Abbildung 5.9). Dem gegenüber
lässt das Benutzermanagement in der aktuellen Version noch zu wünschen übrig.
Abbildung 5.9.: Online Versionierung von Syncplicity
Als einziges untersuchtes Tool bietet Syncplicity eine Schnittstelle zu Produkten von Drittanbietern.
Darunter hervorzuheben sind GoogleDocs, Scribd, Zoho und picnik.
Über GoogleDocs können Dokumente aus dem Repository von GoogleDocs durch hinterlegen der
Anmeldedaten im Webinterface hinzugefügt werden. Die Dateien werden danach in das File Repository
73
5. Tool-Evaluation
von Syncplicity hinzugefügt und bei der Synchronisation lokal gespeichert. Eine gute Möglichkeit, alle
Dateien aus GoogleDocs auch im Offline-Modus verfügbar zu machen.
Für die Ansicht und Bearbeitung von Dateien stehen Scribd, Zoho und picnik zur Verfügung. Über
das Kontextmenü können alle synchronisierten Dateien online mit Scribd betrachtet werden. PDFs,
Word, Excel, PowerPoint, Bilder und Text-Dateien können in ein iPaper konvertiert und wie ein Buch
durchgeblättert werden. Für das Editieren von Dateien stehen Zoho für Dokumente und picnik für Bilder
zur Verfügung. Nach dem Bearbeiten werden die Dateien wieder zurück ins Repository von Syncplicity
gespeichert und bei der nächsten Synchronisation lokal heruntergeladen.
5.5.3. Windows Live FolderShare
FolderShare7 ist nicht nur eine Synchronisationssoftware, sondern vereinfacht den Zugriff auf verteilte
Daten und bietet zusätzlich Remote-Verbindungen. Benötigt man ein Dokument, welches auf einem
anderen Rechner liegt, so kann man mit FolderShare jederzeit darauf zugreifen. Somit kann man zum
Beispiel ein gespiegeltes Abbild wichtiger Dateien auf mehreren Computern erzeugen. Die Synchroni-
sierung erfolgt hierbei automatisch oder auf Anfrage, sobald die Datei benötigt wird.
Abbildung 5.10.: Online Ordner-Administration von FolderShare
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 Berechtigungen:
Leser können Dateien in der Bibliothek anzeigen, jedoch keine Dateien hinzufügen oder ändern.
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 ausserdem Bibliotheksberechti-
gungen ändern.
7
www.foldershare.com
74
5.6. Microsoft Produkte und Alternativen
FolderShare kann auch als Remoteverbindungs-Tool verwendet werden, um von jedem mit dem Inter-
net 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 Instal-
lation der Software (Grösse ca. 1MB) unter Windows oder Mac, können persönliche Bibliotheken 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 freigegebe-
nen Ordners lokal an einem beliebigen Ort hinzufügen. FolderShare steht in verschiedenen Sprachen
zur Verfügung, darunter auch als deutsche Version.
Microsoft ist als Hersteller von Software im Bereich von Office- und Server-Anwendungen im privaten
wie kommerziellen Bereich stark verbreitet. Sie stellen auch Produkte im Bereich der Zusammenarbeit
und des Projektmanagements zur Verfügung. Alle diese Produkte sind weder frei verfügbar noch legen
Sie den Quellcode offen. Zur Vervollständigung der Auflistung von verfügbaren Softwaretools werden
im Folgenden drei Produkte von Microsoft auf deren Eignung in den Bereichen Kommunikation/Zusam-
menarbeit, Informations-/Datenmanagement und Projektmanagement untersucht.
5.6.1. Kommunikation und Zusammenarbeit
„Groove“ ist ein neues Produkt in der Office-Reihe, welches in den Office-Produkten Ultimate 2007
und Enterprise 2007 enthalten ist. Es wird von Microsoft als Kollaborationssoftware angepriesen, damit
Teams dynamisch in kollaborativen Arbeitsbereichen zusammenarbeiten können, und dies von ver-
schiedenen Standorten aus.
5.6.1.1. Office Groove 2007
Die Groove-Technologie macht es möglich dass die einzelnen Client-Rechner untereinander kommuni-
zieren, und über eine sichere Internet-Verbindung Daten austauschen können8 . Nebst dem Stammbe-
reich können weitere Tools integriert 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. Es 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 unter-
stützt.
Fazit
Mit Office Groove versucht Microsoft, im Bereich der Kollaborationssoftware Fuss zu fassen, welches
jedoch noch in den Kinderschuhen steckt. Es sind gute Ansätze vorhanden, man setzt auf bewähr-
te Technologien und erlaubt es dem Benutzer, mittels des Formulareditors individuelle Erweiterungen
hinzuzufügen. Die einzelnen Komponenten von Groove sind jedoch noch nicht so ausgereift. Zum Bei-
spiel kann man keine ganzen Ordnerstrukturen importieren und diese einem Projekt anfügen. Ebenso
8
Office2007 Blog (2008)
75
5. Tool-Evaluation
werden nicht genügend Projektmanagementfunktionen abgedeckt. Was die Kommunikation betrifft, so

werden nur wenige Kanäle bereitgestellt. Kontaktmanagement, Forum, Mailinglisten und Umfragen feh-
len. Dafür deckt es auch einige Punkte aus dem Daten- und Projektmanagement ab.
5.6.1.2. Alternative zu Groove
Wenn man genau betrachtet, wofür Groove genutzt werden kann, so fallen die Bereiche Kommunika-
tion, Datenaustausch und Informationsspeicherung auf. Die im Kapitel 5.1 gelisteten Produkte, insbe-
sondere die genauer untersuchten „Open-Xchange“, „eGroupWare“, „Simple Groupware“ und „Plone“,
decken zu einem grossen Teil dieselben Funktionen ab. Sie verfügen in gleicher oder ähnlicher Form
über ein Benutzermanagement mit unterschiedlichen Rollen, eine Dokumenteverwaltung, Kommunika-
tion und ein Aufgaben-, Ressourcen- und Kostenmanagement. Dadurch, dass sie frei verfügbar und ihr
Quellcode offen ist, können sie zudem frei angepasst und erweitert werden.
5.6.2. Informations- und Datenmanagement
„Windows SharePoint Services“ stellt eine robuste, erweiterbare Plattform bereit, welche gleichzeitig
umfangreiche Funktionalitäten bietet, um Teams die Zusammenarbeit und Kommunikation zu erleich-
tern. Durch umfangreiche Listen werden Dokumente und Informationen geteilt.
5.6.2.1. Microsoft Windows SharePoint Services (WSS)
Obwohl „WSS“ mehr bietet als nur Datenmanagement, möchte ich hier nur auf diesen Aspekt eingehen
(siehe auch das offizielle Datenblatt von Microsoft im Anhang D.8). „WSS“ ist nicht zu verwechseln mit
MOSS („Microsoft Office SharePoint Server“).
„WSS“ bietet veränder- und anpassbare Listenansichten von Aufgaben, Dateien und weiteren Informa-
tionen. Es ist eine Webanwendung, welche asynchrone Kommunikation unterstützt.
„WSS“ bietet als grosses Plus eine vollständige Integration in die Microsoft-Anwendungen. Dokumente
können geöffnet und wieder abgelegt werden, Listen können in „Excel“ oder „Access“ bearbeitet werden
und Kontaktdaten sind in „Outlook“ verfügbar.
Für die Betreibung muss das Betriebssystem Windows Server 2003 mit ASP.NET und der Internet In-
formation Services (IIS) vorhanden sein. Als Datenbank wird die SQL Server Desktop Engine (MSDE
2000) verwendet. Mitgeliefert wird der WMSDE SQL Server, der jedoch keine Replikation und Voll-
textsuche unterstützt. Wie es sich für Microsoft gehört, wird als Browser nur der Internet Explorer un-
terstützt, weitere Browser wie Firefox, Safari und Opera stellen die Webanwendung ebenfalls korrekt
dar und verfügen seit „WSS“ Version 3 über Basisfunktionen. Wird für die Bearbeitung der Office-
Dokumente die aktuelle Office-Version 2007 verwendet, so bietet „WSS“ eine Vielzahl von Zusatzfunk-
tionen.
Fazit
Windows SharePoint Services ist eine flexible Technologie, mit der Organisationen und Geschäftsein-
heiten aller Grössen die Effizienz von Geschäftsprozessen und die Teamproduktivität steigern können.
76
Windows SharePoint Services ermöglicht den Zugriff auf wichtige Informationen, indem Tools für die
Zusammenarbeit über Organisations- und Ländergrenzen hinweg zur Verfügung gestellt werden9 .
Windows SharePoint Services basiert auf Microsoft Windows Server 2003 und bietet eine gemeinsame
Plattform zum Erstellen von webbasierten Geschäftsanwendungen, die einfach angepasst werden kön-
nen, um den sich ändernden und wachsenden Bedürfnissen von Unternehmen gerecht zu werden10 .
5.6.2.2. Alternative zu Sharepoint
Betrachtet man bei „Sharepoint“ den Bereich des Datenmanagements, so bietet sich für den Austausch
von Daten alternativ ein File Sharing-Tool aus Kapitel 5.5 an. Fasst man die zentralen Gedanken hinter
„WSS“ zusammen, so kommt man auf folgende Punkte:
• Zentrale Organisation der Dateien

• Speicherort der Dateien auf einem Server, dadurch Aktualisierung in Echtzeit
• Regelung der Zugriffe über Benutzerverwaltung
• Benachrichtigung über veränderte Daten per Mail an ausgewählte Benutzer
All diese Aspekte können mit einem geeigneten File Sharing-Tool ebenfalls berücksichtigt werden. Die
Synchronisation der Daten, die zentrale Verwaltung und das Zugriffsmanagement sind in den in Kapitel
5.5.1, 5.5.2 und 5.5.3 beschriebenen Tools ebenfalls vorhanden.
5.6.3. Projektmanagement
„Project“ von Microsoft ist das Standard-Tool für Projektleiter. Es besticht durch schnelle Bedienung
und umfangreiche Reportmöglichkeiten, um die Arbeit des Projektleiters zu automatisieren und somit
zu erleichtern.
5.6.3.1. Microsoft Project
„Project“ ist ein Projektmanagementtool, verfügbar in zwei Versionen. Die Standard-Version kann Stand-
Alone auf einem Client genutzt werden, die Professional-Version wird benötigt, um an eine Project-
Server-Umgebungen angebunden zu werden. Wir beschränken uns hier auf die Standard-Version ohne
Verbindungen zu einem Server.
„Project“ fokussiert auf das Management von Terminen und Ressourcen, die Projektüberwachung und
Berichterstattung. Die zu erledigenden Arbeiten werden als Vorgänge bezeichnet, wobei ein Vorgang
eine Arbeitseinheit oder eine Paket von Vorgängen darstellen kann. Ein Vorgang verfügt über mehrere
Eigenschaften, darunter Anfang- und Endtermin, Dauer, Priorität, Status in %, Vorgänger, Ressourcen,
Einschränkungen und frei definierbare Felder. Die erstellten Vorgänge können als Balkendiagramm
(siehe Abbildung 5.11) oder als Netzplandiagramm dargestellt werden. Im Gantt-Chart können die Be-
schriftungen gewählt und die Balken unterschiedlich eingefärbt werden, um Zugehörigkeiten darzustel-
len. Durch die Ressourcenzuweisung wird automatisch ein Ressourcen Einsatz-Bericht und eine Grafik
dazu erstellt. Mit den Informationen zu Vorgängen und Ressourcen können 24 vordefinierte Ansichten
erstellt werden. Zudem stehen 22 grafische Berichte bereit, welche die Informationen in „MS Visio“ oder
9
http://www.microsoft.com
10
http://www.microsoft.com
77
5. Tool-Evaluation
Abbildung 5.11.: Arbeitsbereich mit Vorgängen und Gantt-Diagramm in „MS Project 2007“
78
„MS Excel“ exportieren. Durch die Zuweisung von personellen Ressourcen zu Vorgängen können auch
die Kosten überwacht werden.
Fazit
Project“ ist ein umfangreiches Projektmanagement-Tool für die Verwaltung von Arbeitspaketen, Res-
sourcen, Terminen und Kosten. Durch die Integration in die Microsoft Office-Familie können umfang-
reiche Reports automatisch erstellt und weiterverarbeitet werden. Die Planung mit „Project“ eignet sich
für kleine wie auch für grosse und komplexe Projekte, da ein Projekt schnell eingerichtet und die An-
wendung gut skalierbar ist.
5.6.3.2. Open Workbench
Abbildung 5.12.: Ansicht der importierten XML-Datei aus „MS Project 2007“
Im Gegensatz zu „Groove“ und „Sharepoint“ deckt keine der bisher genannten frei verfügbaren Tools
den Bereich von „Microsoft Project“ ab. „Open Workbench“11 ist eine OpenSource Projektplanungs- und
Projektmanagement-Software als Alternative zu Microsoft „Project“. Es unterstützt in der Projektpla-
nung Gantt-Diagramme, Vorgangserstellung, Abhängigkeiten von Vorgängen, Ressourcenzuweisung,
Kalenderverwaltung für spezielle Ferien- und Abwesenheitszeiten und Grundlinienerstellung sowie in
der Projektverfolgung Aufzeichnung erwarteter Vorgänge, Aufzeichnung aktueller Vorgangsdaten und
die Darstellung des aktuellen Projektstands in Prozent.
Bereits der Arbeitsbereich hat eine grosse Ähnlichkeit mit dem Produkt von Microsoft. Werden „MS
Project“-Dateien im XML-Format gespeichert, so können diese mit „Open Workbench“ geöffnet wer-
11
www.openworkbench.org
79
5. Tool-Evaluation
den. Abbildung 5.12 zeigt die gleiche Datei wie in Abbildung 5.11 durch die Übertragung der XML-
Datei, welche über rund 6’500 Zeilen verfügt. Vorgänge, Ressourcen, Abhängigkeiten und Termine
werden übergeben. Der XML-Export ist jedoch nicht geeignet, um das Projekt mit beiden Systemen zu
betreiben, da dennoch Informationen verloren gehen.
Fazit
„Open Workbench“ ist eine starke Alternative in der Planung von Projekten und Ressourcen, verfügt je-
doch in der Berichterstattung nur über begrenzte Funktionalitäten. Wer an die umfangreichen Templates
und Berichte aus „Project“ gewöhnt ist, wird hier enttäuscht werden. „Open Workbench“ deckt in der
aktuellen Version 1.1.6 die meisten der benötigten Planungsvorgänge ab, hat aber keine Schnittstelle
zu externen Programmen.
5.7. Produktentwicklung
Für den Bereich der Produktentwicklung im engeren Sinne, also die Implementierung des Codes selbst,
können eine Reihe unterschiedlicher Tools benutzt werden. Diese stellen dem Entwickler eine Vielzahl
von Unterstützungsmöglichkeiten und Dienste bereit, um die verteilte Produktentwicklung zu beglei-
ten.
Das einfachste Tool ist ein Editor, welcher im Minimum über Codevervollständigung und Syntaxhervor-
hebung verfügt. Integriert sind auch die Standardfunktionen wie Suchen/Ersetzen und diverse Darstellungs-
und Formatierungsoptionen. Etwas umfangreichere Editoren verfügen zusätzlich über weitere Dienste
für die schnelle und fehlerfreie Codeentwicklung.
Dem gegenüber stehen Entwicklungstools, welche nebst dem Erstellen von Code auch die Steuerung
von Applikationsservern, Debugging und Compilieren sowie das Entwickeln im Team unterstützen. Für
diese sogenannten IDEs (Integrated Development Environments) stehen meist auch Module zur Erwei-
terung bereit.
Der folgenden Tabellen gehen auf die Anforderungen an eine IDE ein und stellen vier IDEs für Python in
den Bereichen Editing und Debugging gegenüber. Danach folgt die genauere Untersuchung drei dieser
IDEs.
5.7.1. Eclipse IDE mit PyDev
Abbildung 5.13.: Code-Vervollständigung in PyDev
80
Editing PyDev SPE Komodo Wing IDE

Syntax Fehler Ja Ja Ja Ja
Tastatur Makros Nein Nein Ja Ja
Tastenkürzel Ja Ja Ja Ja
Tab Hilfe Nein Ja Ja Ja
Automatisches Ja Ja Ja Ja
Einrücken
Code Vervollstän- Bescheiden Schlecht Gut Hervorragend
digung
Aufrufs-hinweise Ja Ja Ja Ja
Sprung zu Defini- Ja Ja Nein Ja
tion
Templates Ja Nein Ja Ja
Code Kontrolle Ja (Eclipse) Nein CVS, Perforce, CVS, Perforce,
SVN SVN
Tabelle 5.2.: Python IDE Übersicht Editing-Funktionen nach Ellis (2006)
Debugger PyDev SPE Komodo Wing IDE

Breakpoints Ja Ja (via winpdb) Ja Ja
Integrierte Kon- Ja Ja Ja Ja
sole
Debug externer Ja Ja Ja Ja
Programme
Tabelle 5.3.: Python IDE Übersicht Debugger-Funktionen nach Ellis (2006)
Diverses PyDev SPE Komodo Wing IDE

GUI Builder Nein Ja (via WxGlade) Ja Nein
Emulation Emacs Nein Emacs Emacs
Dokumentation Schwach Bescheiden Hervorragend Gut
Memory 150MB 10MB 50MB 50MB
Weiteres Code Analyse UML Diagramme Mehrsprachig Scriptable mit
Refactoring PyChecker Inte- RegEx Builder Python
gration
Tabelle 5.4.: Python IDE Übersicht Diverse Funktionen nach Ellis (2006)
81
5. Tool-Evaluation
PyDev ist ein Plugin für Eclipse für die Unterstützung von Python-Projekte. Das Plugin wird über „Help
> Software Updates > Find and Install“ mit der
Remote Site http://pydev.sourceforge.net/updates/
automatisch installiert. In den Einstellungen kann danach der Python Interpreter ausgewählt werden,
für die Programmierung steht auch eine eigene Python Perspektive zur Verfügung.
Abbildung 5.14.: Syntax-Hervorhebung und Navigator in PyDev
PyDev unterstützt den Entwickler und vereinfacht die Implementierung. Nebst Syntax-Highlighting und
Code-Vervollständigung werden fehlerhafte Codesegmente markiert sowie Warnung ausgegeben (zum
Beispiel nicht verwendete Importe und Variablen). Auch das Debugging hilft bei der Suche nach Feh-
lern. Zudem können alle Funktionen und Erweiterungen aus Eclipse genutzt werden. Für die Versions-
kontrolle seien hier „Subversion“ und „CVS“ genannt, welche gewohnt zur Verfügung stehen und auch
mit Python-Projekten einwandfrei funktionieren.
Fazit
Da „PyDev“ als Plugin in „Eclipse“ funktioniert, ist die Lernkurve für Entwickler, welche sich nicht mit
„Eclipse“ auskennen, hoch. Der Einsatz lohnt sich daher nur für komplexere Projekte oder für Entwick-
ler mit Erfahrung im Umgang mit „Eclipse“. In Anbetracht dessen, dass „Eclipse“ zu einem Standard-
werkzeug für Entwickler gehört und die Weiterentwicklung von „PyDev“ daher als sehr zukunftsträchtig
erachtet werden kann, ist dieses Tool bestimmt eine gute Wahl. „PyDev“ ist, im Gegensatz zu den fol-
genden IDEs, nicht in Python, sondern in Java geschrieben. Eine Übersicht über die Haupt-Features
von „PyDev“ gemäss der Projekthomepage befindet sich im Anhang D.10.
5.7.2. WingIde
Abbildung 5.15.: Code-Vervollständigung in Wing IDE
WingIde wird von der Firma Wingware12 entwickelt und kommerziell vertrieben. Die frei verfügbare
12
http://www.wingware.com
82
„WingIDE 101“ kommt ohne Lizenz aus und kann auf der Homepage des Herstellers als Installations-
paket bezogen werden. Eine detaillierte Beschreibung der Funktionen befindet sich im Anhang D.11.
Abbildung 5.16.: Syntax Hervorhebung und Tabs in Wing IDE
Der Editor verfügt über eine schnelle Code-Vervollständigung, aber leider über keine Metainformationen
(Klasse, Variable, Konstante, . . . ), wie man es sich aus „Eclipse“ gewohnt ist. Die Hervorhebung der
Syntax stellt den Code übersichtlich dar. Ganze Code-Fragmente lassen sich bei vielen Codezeilen ein-
und ausklappen. Eine nützliche Funktion sind die automatischen Tabs, welche während der Program-
mierung erstellt werden. Sie enthalten Klassen und Funktionen und ermöglichen einen raschen Zugriff
darauf. „Wing IDE“ unterstützt die verteilte Entwicklung mit CVS, Subversion und Perforce SCM.
Fazit
„Wing IDE“ ist ein mächtiges Entwicklungswerkzeug für Python-Programmierer mit Stärken in der Code-
Vervollständigung und dem Debugging. Für Neueinsteiger existiert gutes Informationsmaterial13 , damit
man sich schnell zurecht findet. Der grosse Nachteil ist die Lizenzierung, da einige interessante Featu-
res der kostenpflichtigen kommerziellen Version vorbehalten sind14 .
5.7.3. Komodo Edit
Abbildung 5.17.: Code-Vervollständigung in Komodo-Edit
„Komodo Edit“ bietet mehr als ein reiner Editor. Es ist intuitiv zu bedienen und besticht durch ein ange-
nehmes Look and Feel. Es verfügt über eine Code-Vervollständigung mit Metainformation und dezente
Code-Hervorhebung. Es unterstützt eine Vielzahl verschiedener Sprachen, darunter JavaScript, Perl,
PHP, Python, Ruby, Tcl, HTML und diverse XML-Formate.
Wie „Wing IDE“ unterstützt „Komodo Edit“ die verteilte Entwicklung mit CVS, Subversion und Perforce
SCM, jedoch nur in der kostenpflichtige Version.
13
http://wingware.com/pub/wingide-personal/2.1.4/doc
14
http://www.wingware.com/wingide/features
83
5. Tool-Evaluation
Abbildung 5.18.: Code-Hervorhebung in Komodo Edit
Fazit
„Komodo Edit“ ist ein einfach zu bedienendes Tool mit einer breiten Unterstützung von diversen Pro-
grammiersprachen. Es eignet sich optimal für kleine und mittlere Projekte, da schnell produktiv gear-
beitet werden kann.
84
6. Software Plattform
Um mit „Plone“ arbeiten zu können, braucht man nicht zwingend Kenntnisse über den Applikationsser-
ver oder die Programmiersprache. Für die Konfiguration stellt „Plone“ eine eigene Konfigurationsober-
fläche bereit, über welche jedoch nicht alle Anpassungen gemacht werden können. Hierfür verfügt der
Applikationsserver über das so genannte „Zope Management Interface“. Für eigenen Erweiterungen
wird die Programmiersprache „Python“ benötigt.
Das vorliegende Kapitel gibt eine kurze Einführung in „Python“ und „Zope“, und stellt zum Abschluss
das CMS „Plone“ vor.
6.1. Programmiersprache Python
Python wurde 1990 von Guido van Rossum in Amster-

dam als Programmier-Lehrsprache entwickelt. Der Fokus lag hierbei auf einer leicht zu erlernenden
und übersichtlichen Sprache. Durch den grossen Funktionsumfang wurde Python bald in der Entwick-
lung 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 Inte-
gration.(Lutz, 2006)
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än-
dert und weiterentwickelt werden muss. Die Sprache wurde von Grund auf designt und hat ein
orthogonales und klares Design, um Code schnell zu verstehen 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 Programmkom-
plexität wie auch das Fehlerpotential. Ebenso kann Python die modernen Methoden der Softwa-
reentwicklung abbilden, strukturierte, modulare wie auch objektorientierte Programmierung sind
möglich.
85
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 ausco-
diert werden müssen. Auch die Wiederverwendbarkeit von Codefragmenten ist aufgrund der
fehlenden Abhängigkeit des Codes von der Typdefinition des Objektes gewährleistet, denn es
kann einaml geschriebener Implementations-Code auf weitere Typen angewendet werden, wenn
diese daselbe Interface implementieren. Ein weiterer 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 leserlicher für Programmierer, welche bestehenden Code überarbeiten
und weiterentwickeln müssen. Diese können sich schneller einarbeiten und werden somit auch
schneller produktiv.
Portabilität: Programme, welche in Python geschrieben wurde, sind auf unterschiedlichen Plattformen
lauffähig. Somit kann ein Code, der auf einer Windows-Installation geschrieben 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 funktional pro-
grammiert werden kann. Wie Java, wir der Programmiercode durch einen Compiler in Byte-Code über-
setzt, welcher danach im Python-Interpreter ausgeführt wird. Der entstandene Byte-Code ist plattfor-
munabhängig und unterstützt insbesondere die Betriebssysteme Windows, Linux und Mac OS X. Im
Lieferumfang von Python ist nebst dem Interpreter und dem Compiler eine umfangreiche Standardbi-
bliothek vorhanden, welche es dem Programmierer erlaubt, schnell komplexe Aufgaben zu lösen.
Interner Ablauf
Python kann als interpretierte Programmiersprache in einer beliebigen Entwicklungsumgebung ge-
schrieben 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 über-
setzte Byte-Code wird danach in einer virtual machine, dem sogenannten Interpreter, ausgeführt. Ab-
bildung 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.
86
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 Zei-
lenumbruch gekennzeichnet. Anweisungen, welche sich in einen Kopf und einen Körper unterteilen
lassen, werden durch Doppelpunkt am Ende des Anweisungskopfs und Einrückung des Anweisungs-
körpers um 4 Leerzeichen festgelegt. Eine Kennzeichnung eines Körpers durch geschweifte Klammer
{...}, wie bei vielen Programmiersprachen üblich, existiert in Python nicht.
Abbildung 6.3.: Anweisungen in Python
Fallunterscheidungen
Fallunterscheidungen sind Konstrukte, welche dazu dienen, einen Anweisungsblock unter bestimmten
Bedingungen ausführen zu lassen. Ein Fallunterscheidungs-Block beginnt immer mit dem Schlüssel-
wort if. Weitere Unterscheidungen können durch elif erzeugt werden. Eine Default-Anweisung wird
durch das Schlüsselwort else eingeleitet.
Abbildung 6.4.: Fallunterscheidung in Python
Conditional Expression
Bedingte Ausdrücke sind Anweisungen in der Form A if Bedingung else B, wobei Bedingung ein be-
liebiger 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.
87
Abbildung 6.5.: Conditional Expression in Python
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 Schlei-
fendurchlauf 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 durchlaufen. Dabei
durchläuft die for -Schleife ein beliebiges iterierbares Objekt, zum Beispiel eine Zeichenkette 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, mehreren
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 *
importiert alle Variabeln und Funktionen, welche nicht mit einem „_“ beginnen. Diese sogenannten
Membervariabeln sind nur innerhalb des Moduls sichtbar und können nicht von aussen aufgerufen
werden. (Schwarzer, 2006)
88
Objektorientierte Programmierung
Eine Klasse in Python wird mit der Anweisung class erzeugt. Eine neue Instanz wird mit dem Kon-
struktor __init__ erzeugt, welcher die neue Instanz mit Werten initialisieren kann. Auch die Verer-
bung 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 kleine 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 Plattform 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 Fehler-
suche wesentlich zu verringern.
89
6.2. Applikationsserver Zope
Zope ist ein objektorientierter Open-Source-Applikationsserver für datenbankgestützte dynamische In-

ternetanwendungen 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 Applikationen. Web Applikationen sind Pro-
gramme, 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
6.2.1. Konzept von Zope
Zope erweitert als Web Applikationsserver, als ein Framework, um Web Applikationen zu entwerfen,
die Standard-Fähigkeiten der Programmiersprache Python um Dienste wie Templating, 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, Datenbankintegrati-

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

zer 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 Zusammenhang mit Zope sei auf
(Zope Community, 2008) verwiesen.
Wie dies bereits von Webserver wie Apache oder Microsoft IIS bekannt ist, welche die URL auf Ver-
zeichnisse 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 Resultat 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 Sicherheitsabstufung
90
designt. Eine erfolgreiche Webseite benötigt eine flexible Rechteverwaltung, um die Sicherheit der Ap-
plikation zu gewährleisten. Die Objekte in Zope stellen eine umfangreichere Zugriffsbeschränkung als
herkömmliche Dateisysteme bereit. Die Zugriffskontrolle wird über das Objekt selbst geregelt und er-
lauben 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 Vererbungskonzept erbt
eine Klasse die Eigenschaften der Vaterklasse. In Zope kann ein Objekt zusätzlich von einem über-
geordneten Objekt in der Objekthierarchie erben. Dieses Vererbungskonzept ist einzigartig und wird
hauptsächlich für die gemeinsame Nutzung von Informationen, zum Beispiel einen gemeinsamen Hea-
der eines ganzen Ordners einer Webseite, verwendet. Seine Mächtigkeit zeichnet sich dadurch aus,
dass Definitionen an einer einzigen zentralen Stelle verwaltet und ohne explizite Einbindung verwen-
det werden können, und dies auf unterschiedlichen 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. Zu-
dem 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
Die grundlegende Architektur und der Aufbau von „Zope“ ist objektorientiert. Es bietet ein Managment
Interface und eine eigene Datenbank.
6.2.2.1. ZMI - Zope Management Interface
Auf Zope-Objekte kann vollständig über den Brwoser zugegriffen werden. Somit kann die gesamte
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 Datenbankmanipulationen zu konzentrieren. Die
Persistenz für die Objekte und Objekt-Instanzen wird kann von Zope übernommen werden.
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.
91
Abbildung 6.7.: Zope Architektur (Zope Community, 2008)
92
Abbildung 6.8.: Root-Objekte in Zope
Web Server: Für die Benutzung von Zope kann anstelle des eigenen Web Servers auch ein alternati-
ves 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 abgelegt
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 Interface 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 ab-
schliessende Liste (Zope Community, 2008):
Access Rule Services: Zugangsregeln ermöglichen es, beim öffnen eines bestimmten Ordners eine
Aktion auszulösen.
Temporary Storage Services: In Zope können Objekte temporär in entsprechenden Ordnern gespei-
chert werden. Diese Ordner unterscheiden sich von den „normalen“ Ordnern 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 temporären Ordnern werden hauptsächlich kleine Objekte mit vie-
len Zugriffen gespeichert, ein Beispiel dafür sind Daten über Benutzersessions. Für grössere
Objekte sind temporäre Ordner weniger geeignet.
93
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 Internetseite 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 Beschreibung 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 Komponenten 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.
94
6.3. CMS Plone
6.3. CMS Plone
Plone ist ein auf ZOPE basierendes Enterprise Content Management System, welches zum grössten
Teil in der Programmiersprache „Python“ geschrieben ist.
6.3.1. Installation
Für Windows und Mac stehen einfach Installationsprogramme zur Verfügung, für Linux werden RPM-
Pakete vertrieben, Debian installiert „Zope“ und „Plone“ über den apt-get-Befehl. Bei der Installation
werden bereits einige Erweiterungen sowie alle Sprachdateien mitinstalliert. Somit steht das System
von Anfang an in über 25 Sprachen bereit. Das Grundsystem wird mit zwei verschiedenen Templates
ausgeliefert, weitere Skins können nachinstalliert werden.
6.3.2. Grundlagen
Nach der Installation kann „Plone“ über den Webbrowser unter http://localhost aufgerufen wer-
den. 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 welche der Verwendungszweck und die Eigenschaf-
ten festgelegt werden. Initial werden folgende Artikeltypen mitgeliefert:
- Seiten
- Nachrichten und Termine
- Bilder und Dateien
- Links und Lesezeichen
- Ordner und Kollektionen
Der Status, in welchem sich der Artikel befinden kann, regelt die Sichtbarkeit und die Zugriffe der
Benutzer. Ebenso werden dadurch die Aktionen (kopieren, einfügen, löschen) eingeschränkt.
6.3.2.2. Ansichten
„Plone“ kennt für Artikel unterschiedliche Ansichten. Die häufigste davon ist die Anzeige, welche den
Artikel so darstellt, wie ihn auch Besucher der Webseite sehen. Für angemeldete Benutzer stehen je
nach Berechtigungsstufe weitere Ansichten zur Verfügung, welche unterschiedlichen Zwecken dienen.
Die Ansicht der Inhalte listet alle Artikel der Seite mit Titel, Grösse, dem letzten Änderungsdatum, dem
aktuellen Status und der Möglichkeit, die Reihenfolge via Drag and Drop zu verändern. Befindet man
sich in der Ansicht Bearbeiten, so können alle Inhalte des Artikels editiert werden. In dieser Ansicht
stehen zudem weitere so genannte Tabs zur Verfügung, in welchen Kategorien und Metadaten, Freiga-
bedatum, Urheber und Einstellungen wie Kommentare, Sichtbarkeit im Navigationsmenü und Seiten-
navigation zwischen einzelnen Artikeln innerhalb eines Ordners eingestellt werden können. Handelt es
sich um einen Ordner oder um einen Container, so steht auch die Ansicht Regeln zur Verfügung. Hier
können die in Kapitel 6.3.4 vorgestellten Workflows eingerichtet werden. Die letzte Anzeige trägt den
95
Namen Zugriff und regelt die Berechtigungen bezogen auf den aktuellen Artikel. Zusätzliche Berechti-
gungen können an einzelne Mitglieder oder an ganze Gruppen vergeben werden. Kollektionen verfügen
auch über eine Ansicht Kriterien, welche den Filtern für die Kollektion entsprechen. Seite, Nachricht und
Termin speichern alle Änderungen ab, welche danach über die Versionen abgerufen werden können.
Nicht jeder Artikeltyp verfügt über alle Anzeigemöglichkeiten. Alle Artikeltypen stellen mindestens die
Reiter Anzeigen, Bearbeiten und Zugriff zur Verfügung, sofern der Benutzer über genügend Berechti-
gungen verfügt („Lesen“ resp. „Bearbeiten“). Anzeige und Bearbeiten sind für alle Artikeltypen gleich.
Eine detaillierte Auflistung aller verfügbaren Reiter und Einstellungen gibt Tabelle 6.1.
nen
n
iere
ktio
g
n
llun
olle
nen
orm
eite
en
en
n
g
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ügbare Ansichten in „Plone“
Benutzer und Gruppen

„Plone“ stellt als Content-Management-System eine Benutzerverwaltung zur Verfügung, welche Mitglie-
der mit unterschiedlichen Rollen auszeichnet und sie in Gruppen gliedern kann. Je nach Rolle haben
Benutzer zusätzliche Rechte auf Artikel. So können Sie diese bearbeiten, veröffentliche, kopieren oder
löschen. Ebenso können Benutzer in ihrem eigenen Ordner Dateien ablegen und diese mit weiteren
Benutzern teilen.
Neue Benutzer können sich entweder selbst registrieren oder werden vom Administrator erfasst. Auto-
matisch wird ein persönlicher eine persönliche Seite und falls so eingestellt ein persönlicher Benutzer-
ordner erstellt. Die persönliche Seite kann selbst editiert werden, wodurch durch eigene gewünschte
Inhalte eine Art Portalseite erstellt werden kann. Im persönlichen Ordner kann der Benutzer beliebige
Artikel erstellen und pflegen und diese den Besuchern der Webseite anzeigen lassen.
Mehrere Benutzer können in einer Gruppe zusammengefasst werden. Für Gruppen kann ein Gruppen-
arbeitsplatz eingerichtet werden, in welchem alle Mitglieder der Gruppe Artikel anlegen und veröffentli-
chen können.
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 Übergänge.
96
6.3. CMS Plone
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 Berechtigungen hat. Es gibt somit keinen
eigenen Zustand für den Artikel und keine Übergänge.
Arbeitsablauf mit einem Zustand

Artikeltypen mit einem Zustand verfügen nur über den Status „veröffentlicht“. Statusübergänge sind
nicht möglich. Der Unterschied zum Typ „kein Arbeitsablauf“ besteht darin, dass die Berechtigungen
nicht vom Ordner vererbt werden, sondern für den Artikeltyp selbst bestimmt werden.
Einfacher Publikationsarbeitsablauf
Dies ist der Standard-Ablauf. Nach dem Erstellen eines Artikels erhält dieser den Status „privat“. Da-
nach kann er zur Veröffentlichung an die Redaktion eingereicht oder direkt für alle Benutzer veröffent-
licht werden. Er verfügt über drei Zustände und sieben Übergänge (siehe Abbildung 6.9).
Abbildung 6.9.: Einfacher Publikationsarbeitsablauf in Plone
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 Entwurf, 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. Es sind gesamt
fünf Zustände und 13 Übergänge möglich.
Auffallend am Intranet Arbeitsablauf ist die Sichtbarkeit. Fast alle angemeldeten Benutzer (ausser die
97
Rolle „Benutzer“, welcher keine privaten Artikel sehen kann) können die Artikel und Ordner betrach-
ten. Ebenso können Sie intern veröffentlichte und extern sichtbare Artikel zurückziehen. Der Intranet
Arbeitsablauf ist der komplizierteste mit den meisten Abstufungen.
Zusätzlich gibt es einen Intranet Arbeitsablauf für Ordner, welcher nur über die Zustände „Interner
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 Inhalt der Redaktion zur Prüfung
vorliegt, kann ihn jeder lesen. Sobald der Inhalt veröffentlicht ist, kann er nur vom Administrator und von
Benutzern mit Veröffentlichungsrechten zurückgezogen werden.
Total sind vier Zustände und zehn Übergänge verfügbar.
6.3.4. Workflows
In der Konfiguration von Plone können vier verschiedene Regeln für Ordner und Container definiert
werden (siehe Abbildung 6.12). Jede Regel verfügt über eine beliebige Anzahl Bedingungen und darauf
folgende Aktionen.
Werden die Regeln aktiviert, sind diese danach für die Ordner innerhalb der Daten- und Navigations-
struktur von „Plone“ verfügbar. Der Effekt wirkt sich dabei auf alle Artikel innerhalb eines Ordners aus.
Das Zuweisen geschieht über den Reiter „Regeln“ innerhalb eines Ordners. Dabei können Regeln an
Unterordner weiter vererbt werden. Die Bedingungen aus Abbildung 6.13 bezeichnen die Eigenschaf-
ten des Objektes innerhalb des Ordners oder Containers, welchem die Regel zugeordnet wurde. Sie
können kumulativ angewendet werden.
Zuletzt folgen die Aktionen, welche ausgeführt werden, sobald die Bedingungen für einen Artikel in-
nerhalb des Ordners zutreffen. „Plone“ kennt standardmässig die in Abbildung 6.14 beschriebenen
Aktionen mit den entspreche

Sprache

Diplomarbeit

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Diplomarbeit

Hochgeladen von

Copyright:

Verfügbare Formate

Diplomarbeit

Grundmodul einer modernen Projektmanagement

Datum der vorliegenden Version:

Dr. Andreas Huber, Prof. Dr. Helmut Schauer

2. Grundlagen und Begriffe 3

3. Methoden des Projektmanagements 17

3.2. Projektmanagement nach Jenny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4. Anforderung an eine moderne PM-Plattform 51

7. Implementierung, Konfiguration 103

7.1.1. Kommunikation und Zusammenarbeit . . . . . . . . . . . . . . . . . . . . . . . . 103

8. Ausewrtung / Ausblick 111

C. Planung mit Scrum 123

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

1.5. Aufbau der Arbeit

2.1. Allgemeine Begriffe

2.1.2. Kommunikationsräume und -techniken

Die Theorie der Kommunikationsräume umfasst sechs Dimensionen:

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

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

sprachlich: gemeinsame und funktionale Sprache

2.1.3. CSCW und Groupware

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

Bilaterale vs. Multiple Kooperation: Anzahl der Beteiligten Kommunikationspartner

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

• DM Document Management (DMS, Dokumentenmanagement)

• Autonomie der Unternehmung

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

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

Projekte sind in sich abgegrenzte, komplexe und/oder komplizierte Aufträge, de-

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

„a temporary activity that is characterized by having a start date, specific objec-

2.2.2.1. Klassifikation nach Wichtigkeit

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

Im traditionellen Projektmanagement werden Projekte also hauptsächlich nach Dimensionen, fachli-

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

2.2.2.2. Klassifikation nach Zeitpunkt und Bedeutung

2.2.2.3. Klassifikation nach Inhalt

2.2.3. Kontrolle eines Projekts

Das magische Dreieck

2.2.4. Steuerbarkeit eines Projekts

Die Projektsteuerung umfasst alle projektinternen Aktivitäten des Projektleiters,

2.2.4.1. Das Teufelsquadrat

• Klare Bestimmung des Projektumfangs

• Stetige Unterstützung des Projektleiters durch das Management

Abbildung 2.7.: Teufelsquadrat nach (Daenzer, 2002) und (Jenny, 2005)

2.2.4.2. Direkt wirksame Steuerung

Projektkoordination: Sind viele der Projektbeteiligten an mehreren unterschiedlichen Projekten be-

Steuerung von Aufwand und Zeit

Um eine termingerechte Abgabe dennoch zu gewährleisten, können weitere Ressourcen hinzugezogen

Steuerung der Qualität

Steuerung von Risiken

Steuerung von Abhängigkeiten

2.2.4.3. Indirekt wirksame Steuerung

2.2.5. Erfolgsfaktoren eines Projekts

• Business Impact: Wird ein Nutzen für das Unternehmen erzielt?

Das traditionelle Projektmanagement fokussiert auf den Reporting-Mechanismus. An moderne Projek-

3.1. Allgemeines Projektmanagement

Grundsätzlich sind die Organisationsformen Linien-, Stab-Linien- und Matrix-Organisation zu unter-

Tabelle 3.1 zeigt die drei Projektorganisationen im Vergleich.

Linien Stab-Linien Matrix

Tabelle 3.1.: Überblick Projektorganisation (eigene Darstellung)

3.1.2. Rollen und Gremien