Beruflich Dokumente
Kultur Dokumente
Diplomarbeit
Diplomarbeit
Deborah Weber
Obermühle 15
6340 Baar
Universtiät Zürich
Institut für Informatik
Inhaltsverzeichnis
1. Einleitung 9
1.1. Ausgangslage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3. Abgrenzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Zielgruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3
Inhaltsverzeichnis
4
Inhaltsverzeichnis
3.4.4. Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.4.1. Planungssitzung 1 . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.4.2. Planungssitzung 2 . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.4.3. Daily Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.4.4. Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.4.5. Sprint Retrospektive . . . . . . . . . . . . . . . . . . . . . . . 63
3.4.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.5. MIO Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.5.1. Produktentwicklungsprozess . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5.1.1. Wasserfallmodell . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5.1.2. Spiralmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.1.3. Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.1.4. Extreme Programming . . . . . . . . . . . . . . . . . . . . . . 68
3.5.1.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.5.2. Managementprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.5.3. Führungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6. Prozessintegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.6.1. Projektmanagement-Prozess . . . . . . . . . . . . . . . . . . . . . . . 73
3.6.2. Führungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.7. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5
Inhaltsverzeichnis
4.3.1. Dokumentemanagement . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.2. Versionierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.3. Strukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3.4. Wissenserhaltung und Wissensfindung . . . . . . . . . . . . . . . . . . 87
4.4. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.4.1. Termine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.4.2. Management von Input und Output . . . . . . . . . . . . . . . . . . . . 89
4.4.3. Ressourcenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4.4. Aufgabenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5. Tool-Evaluation 93
5.1. Toolauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.1.1. PHProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.1.2. Open Xchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.1.3. eGroupWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1.4. Simple Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1.5. IGSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1.6. Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.2. Kommunikation und Zusammenarbeit . . . . . . . . . . . . . . . . . . . . . . . 98
5.2.1. PHProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.2.2. Open Xchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.2.3. eGroupWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.4. Simple Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.5. IGSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.6. Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3. Informations- und Datenmanagement . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.1. PHProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.2. Open Xchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.3. eGroupWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.4. Simple Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.5. IGSuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.3.6. Plone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.1. PHProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.2. Open Xchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.3. eGroupWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.4. Simple Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6
Inhaltsverzeichnis
7
Inhaltsverzeichnis
9. Schlussbemerkung 135
A. Literaturverzeichnis 137
B. Innovationsspiele 143
8
1. Einleitung
1.1. Ausgangslage
Gemäss einer Studie der Standish Group (2008) scheitert heutzutage immer noch ein Grossteil
der IT-Projekte (vgl. Abbildung 1.1). Komplexe Projekte benötigen daher ein adäquates Pro-
jektmanagement und entsprechende Unterstützung durch geeignete Tools.
Projektmanagement ändert sich in der heutigen Zeit aufgrund der erhöhten Anzahl von verteil-
ten Projekten und neuen Projektmanagementmethoden. Um ein Projekt zum Erfolg zu führen,
muss aktuell und zukünftig mehr Fokus auf die Nachverfolgung von Projektarbeitsprozessen,
effizientes und effektives Teilen von Information und Wissen zwischen den Projektmitarbeitern
in alle Richtungen, ein proaktives Änderungsmanagement und eine geeignete Prozessüber-
wachung gelegt werden (Chen u. a., 2002).
1.2. Aufgabenstellung
Der Schwerpunkt mensch | informatik | organisation (MIO) am Institut für Informatik der Uni-
versität Zürich beschäftigt sich mit der Führung und dem Management komplexer IT-Projekte.
9
1. Einleitung
Zur Unterstützung der entwickelten Methoden wurden eine eigene Lernumgebung und ver-
schiedene Tools entwickelt.
Vor diesem Hintergrund soll eine neue webbasierte Plattform zur Unterstützung der Führung
und des Managements komplexer IT-Projekte realisiert werden. Die neue Plattform soll funk-
tional performant sein und die Prozessdifferenzierung des MIO-Ansatzes unterstützen. Durch
ein einfaches Handling, Skalierbarkeit und Erweiterbarkeit soll die Plattform sich für das Ma-
nagement von komplexen IT-Projekten eigenen.
1.3. Abgrenzung
Am 4. März wurde während einer Sitzung beschlossen, diese Plattform nicht mehr selbst zu
entwickeln, sondern das Open Source ECMS „Plone“ zu verwenden. Plone gilt zum aktuellen
Zeitpunkt als zukunftsträchtige und innovative Plattform mit einer starken Community im Hin-
tergrund. Seine Stärken sind das Dokumentemanagement und die Verwaltung von Prozessen.
Das Grundmodul dient als Basis für die Erweiterung um ein Modul für die Unterstützung der
10
1.4. Zielgruppe
1.4. Zielgruppe
Diese Arbeit richtet sich an Personen aus den Bereichen Wirtschaft und Informatik, an Pro-
jektleiter genauso wie an Entwickler und Manager. Sie vertieft den Ansatz, dass für ein er-
folgreiches Projektmanagement im IT-Bereich das gemeinsame Verständnis aller Beteiligten
und ein verstärkter Fokus auf Führung, Entwicklungs- und Arbeitsprozess nötig sind. Für die
Entwicklung qualitativ hochwertiger, komplexer Software reichen die klassischen Projektma-
nagementmethoden mit Fokus auf die ökonomischen Prozessziele Inhalt, Kosten und Qualität
oftmals nicht mehr aus.
11
1. Einleitung
12
2. Grundlagen und Begriffe
In diesem Kapitel werden die grundlegenden Begriffe und Eigenschaften von Projekten erläu-
tert. Das IT-Projektmanagement wird in der Literatur seit gut 50 Jahren erläutert. So gross die
Anzahl von Literatur ist, so unterschiedlich sind die Definitionen und die Entwicklung, welche
die Managementmethoden in einem halben Jahrhundert durchgemacht haben.
Der Abschnitt 2.1 fokussiert auf allgemeine Begriffe, welche nicht direkt mit dem Projektma-
nagement in Beziehung stehen, jedoch für das Verständnis des Grundmoduls und dessen
Notwendigkeit und Aufbau wichtig sind. Darauf folgt im Abschnitt 2.2 die Klärung der projek-
trelevanten Begriffe. Ebenso werden Risiken und die Eigenschaften der Steuerbarkeit und der
Erfolgsfaktoren untersucht.
2.1.1. Qualität
Nicht nur die Faktoren Inhalt, Kosten und Termine sind bei einem Projekt zu überwachen,
sondern auch die Qualität. Der Anspruch an die Qualität verändert sich in einem Unterneh-
men fortlaufend. Entscheidend ist ein gemeinsames Verständnis aller Mitarbeitenden über die
Bedeutung des Begriffs Qualität und darüber, wie diese Qualität erreicht werden kann. Nach
Kessler u. Winkelhofer (2004) stützt sich die Qualität in einem Projekt nicht auf die Anwendung
13
2. Grundlagen und Begriffe
standardisierter Prozesse, sondern auf die drei Eckpfeiler der strukturierten Vorgehensweise,
dem Einsatz passender Hilfsmittel und Werkzeuge sowie der Ausbildung des Projektteams.
Jankulik u. a. (2005) geht einen Schritt weiter und betrachtet die Qualität aus den unterschied-
lichen Aspekten bezüglich Produkte, Prozesse und Potential (siehe Abbildung 2.1, S. 14). Die
Anforderung an die Qualität in einem Softwareprojekt nimmt stetig zu und zeichnet sich nicht
nur durch das Produkt aus, sondern durch die Gesamtheit aller Merkmale einer Einheit, fest-
gelegte und vorausgesetzte Erfordernisse zu erfüllen (ISO 8402).
personell: Anzahl der beteiligten Personen sowie deren Rollen, Interessen, Heterogenität
und Geschlecht
räumlich: Grösse und Klima des Raumes sowie Ausstattung, Anordnung der Plätze und stra-
tegische Platzierung der Leitung
14
2.1. Allgemeine Begriffe
kulturell: Werte und Regeln, Art (Dialog, Diskussion, Präsentation) sowie Sitten und Gebräu-
che (Pünktlichkeit, Offenheit)
Die angewendeten Techniken unterscheiden sich in jeder Phase der Projektführung (vgl. 3.5).
15
2. Grundlagen und Begriffe
Wege zwischen den Mitgliedern einer Gruppe koordiniert auszutauschen oder gemeinsame
Materialien in gemeinsamen Speichern koordiniert zu bearbeiten (Schiestl, 1996).
In der Kooperation lassen sich drei sich gegenseitig ausschliessende Dimensionen unterschei-
den, wobei vorwiegend die dritte Dimension zur Klassifizierung von Groupware-Anwendungen
verwendet wird ((Borghoff u. Schlichter, 1998), (Fischer, 2002)):
Konjunktive vs. Disjunktive Kooperation: Ausführung der Handlung durch einen (disjunk-
tiv) oder durch beide Beteiligten
Unmittelbare vs. Mittelbare Kooperation: Räumliche und zeitliche Trennung der Kooperati-
onspartner
2.1.4. ECM
Ein ECM-System soll innerhalb eines Unternehmens die für Mitarbeiter relevanten Daten ein-
heitlich auf einer Plattform zur Verfügung stellen. Die technische Herausforderung liegt hierbei
bei der Menge von unterschiedlichen Quellen, in welchen die Informationen existieren (Archiv,
Datenbank, Internet, Mail, ERP-System, Papierdokumente) (Noack, 2007). Dabei liegt der In-
halt (Content) in strukturierter, schwach strukturierter oder unstrukturierter Form vor. Der Grad
der Struktur hängt hierbei mit der verfügbaren Meta-Information und der Trennung von Layout
und Inhalt zusammen. Diese Trennung ist wichtig, weil Meta-Informationen für die elektroni-
sche Verwaltung und Kontrolle von Inhalten benötigt werden.
5 Komponenten-Modell
Die wichtigsten ECM-Komponenten und -Technologien lassen sich gemäss Kampffmeyer (2006)
(siehe Abbildung 2.3, S. 17) in die fünf Hauptkategorien Erfassung, Verwaltung, Speicherung,
Ausgabe und Sicherung einordnen. Die bisherigen Anwendungsfelder
16
2.1. Allgemeine Begriffe
17
2. Grundlagen und Begriffe
18
2.1. Allgemeine Begriffe
2.1.5. KMU
Als kleine und mittlere Unternehmen gelten Unternehmen mit bis zu 250 Mitarbeitenden, ei-
nem Umsatz von weniger als 40 Millionen Euro resp. einer Bilanzsumme von weniger als 27
Millionen Euro. Zudem befinden sich weniger als 25% des Kapitals bei einem Unternehmen,
welches diese Kriterien nicht erfüllen. Mikro- und Kleinunternehmen (mit bis 9 resp. 49 Mit-
arbeitern) sowie Mittelunternehmen zeichnen sich durch folgende qualitative Merkmale aus
(Bamberger, 2005):
Rund 99.7% aller Unternehmen mit 67.5% aller Beschäftigten gehören in die Gruppe der KMU,
mehr als 87% der Unternehmen beschäftigen weniger als 10 Mitarbeitende (siehe Abbildung
2.5, S. 19). Ein solches Unternehmen benötigt trotz dem geringen Formalisierungsgrad, einer
schlanken Organisationsstruktur und der zentralisierten Entscheidungsstelle für die Durchfüh-
rung Ihrer Projekte ein professionelles Projektmanagement.
19
2. Grundlagen und Begriffe
2.2. IT-Projektmanagement
Die Führung eines Projektes wird als Projektmanagement bezeichnet (Jenny, 2005). Dazu
abzugrenzen ist das Projektmanagement-System, welches gemäss DIN 69905 ein organisa-
torisch abgegrenztes Ganzes ist, welches durch das Zusammenwirken seiner Elemente in der
Lage ist, Projekte vorzubereiten und abzuwickeln. Die Elemente dieses Systems sind einzel-
ne Disziplinen, die in einem Projekt von den jeweiligen Rollen berücksichtigt und beherrscht
werden müssen. Somit können in ein modernes Projektmanagement auch die Prozesse der
Führung und der Produktentwicklung mit einbezogen werden.
Viele Begriffe aus dem Umfeld des Projektmanagements werden unterschiedlich definiert und
verwendet. Dieses Kapitel soll dazu dienen, die in dieser Arbeit verwendeten Begriffe von einer
allgemeingültigen Definition abzugrenzen.
2.2.1. Projekt
Bei der Literatursuche nach der Erklärung des Begriffs „Projekt“ stellt man schnell fest, dass
keine einheitliche Definition möglich ist, sich die meisten Erklärungen in den wichtigsten Punk-
ten jedoch decken. Ein Projekt gilt als einmaliges Vorhaben auf Zeit, welches durch einen
klaren Start- und Endzeitpunkt definiert ist (Jenny (2005), Thayer u. Yourdon (1997), Früh-
auf u. a. (2001), Mangold (2002)). Ein Projekt führt dabei einen bestehenden IST-Zustand in
einen gewünschten SOLL-Zustand über, wobei die Bedürfnisse des Auftraggebers und die
Möglichkeiten des Auftragnehmers den äusseren Rahmen definieren. Jenny (2005) definiert
ein Projekt wie folgt:
Nach (Mangold, 2002) ist ein Projekt ein Vorhaben, welches folgende vier Kriterien erfüllt:
eindeutiges Ziel: Auch wenn sich Ziele während des Projektverlaufs verändern, ist entschei-
dend, „dass bei einem solchen Vorhaben von Anfang an ein Ziel festgelegt und kommu-
niziert wird, so dass alle Projekbestrebungen auf die Erreichung eines derzeit aktuellen
Ziels ausgerichtet werden können.“
20
2.2. IT-Projektmanagement
begrenzt: Ein Projekt ist im Bezug auf Zeit, Kosten und Ressourcen begrenzt. Die Anforde-
rungen an ein Projekt legen die inhaltlichen Grenzen fest, welche nötig sind, um ein
Endergebnis zu definieren und zu erreichen.
individuell: Ein Projekt zeichnet sich durch seine Individualität aus. „Projekte sind nie Routi-
netätigkeiten. Etwas, was in gleicher Art und Weise schon einmal durchgeführt wurde,
ist kein Projekt mehr. Für solche Fälle lassen sich Ablaufmodelle entwickeln, die ohne
Projektmanagement-Methoden zum erwarteten Ziel führen.“
die Menge aller Tätigkeiten, Interaktionen und Resultate, die mit dem
Versuch zusammenhängen, ein bestimmtes Ziel mit begrenzten Mitteln
und innerhalb begrenzter Zeit zu erreichen.
Er lehnt sich dabei an die Definition von (Thayer u. Yourdon, 1997): a project is
Ein IT-Projekt ist im Allgemeinen ein Projekt mit einem verstärkten Bezug zur Informations-
technologie und zur Entwicklung. Einfach gesagt ist ein IT-Projekt ein Projekt, welches als
Lieferobjekt ein Stück Software beinhaltet (Client/Server-, Webapplikation, . . . ).
2.2.2. Projektklassifizierung
Die Klassifizierung von Projekten beeinflusst die Wahl der Projektmanagement-Methode sowie
die Ressourcenplanung. Im Verlaufe der Zeit festigten sich die klassischen Klassifizierungs-
kriterien und wurden um neue erweitert. Wie bei der Wahl der Projektmanagementmethode
gibt es auch bei der Klassifizierung keine einheitliche Richtline. Je nach Projektdauer, nach
Erfahrung der Projektleiter und des Projektteams und den verfügbaren Ressourcen, werden
Projekte innerhalb einer Unternehmung unterschiedlich klassifiziert. Für eine klare Übersicht
und ein realistisches Projektportfoliomanagement sollte die Projektklassifizierung unterneh-
mensintern standardisiert und Projekte nach gleichen Kriterien bewertet werden.
21
2. Grundlagen und Begriffe
Jenny (2005) stuft Projekte nach Wichtigkeit in vier Klassen (A − D) ein, wobei A die höch-
ste Wichtigkeit besitzt. Mögliche Einstufungskriterien sind Strategieeinfluss, Organisationsver-
änderung, Effizienz, Komplexität, Kosten, Intensität der Projektabwicklung, Risiko oder Wirt-
schaftlichkeit, welche mit konkreten Zahlenwerten oder durch eine verbale Gewichtung (hoch-
/mittel/tief) skaliert werden. Nebst der Einstufung nach Wichtigkeit ist jedoch eine zusätzliche
Einstufung nach Dringlichkeit notwendig. Die Einstufung wird aufgrund der gleichen Kriterien
für alle Projekte eines Unternehmens vorgenommen. Dabei ist zu beachten, dass die Klassi-
fikation auch abhängig von der Grösse des Unternehmens ist. Ein Projekt, welches in einem
Unternehmen als ein B-Projekt klassifiziert wird, kann bei einer anderen Unternehmung auf-
grund anders gewichteter Kriterien als ein A- oder ein C-Projekt eingestuft werden. Anhand
eines Kiviat-Diagramms (siehe Abbildung 2.6, S. 22) kann die Projektklassifikation nach Krite-
rien visualisiert werden.
Auch Specker (2004) stuft Projekte in Kategorien anhand der Kriterien Umfang, organisatori-
sche Komplexität, Komplexität des Kundenproblems, Know-How und Technologiekomplexität
ein. Dabei entstehen drei Kategorien A−C. Er weist darauf hin, dass auch in kleineren und we-
niger komplexen Projekten alle Aspekte des Projektmanagements wahrzunehmen wären.
22
2.2. IT-Projektmanagement
• die Struktur des Projektes, die sich aus der Grösse ergibt und
Applegate (2005) unterscheidet Projekte nach Zeitpunkt und Bedeutung aus Unternehmens-
sicht (vgl. auch Kuhnt (2007)).
Strategische Projekte sind kritisch für die Unternehmensstrategie und benötigen eine zentrale
Planung. Die Erreichung der Ziele ist für das Unternehmen von hoher Bedeutung und bringt
einen Mehrwert in der Zukunft.
High Potential Projekte können den Erfolg eines Unternehmens in der Zukunft möglicher-
weise entscheidend beeinflussen. Zum aktuellen Zeitpunkt zeichnen sie sich jedoch durch
ein hohes Risiko aus, da der Erfolg und somit ein erfolgreiches ROI nicht garantiert werden
kann.
Kritisch-operative Projekte sind zum Zeitpunkt der Durchführung von hoher Bedeutung und
verfolgen das Ziel einer quantifizierbaren Leistungsverbesserung. Sie gelten als besonders
kritisch, da der Erfolg des Unternehmens zurzeit davon abhängig ist.
Unterstützende Projekte sind weder kritisch noch risikobehaftet. Sie verfolgen das Ziel von
Kosten- und Aufwandsreduktion durch Optimierung, zum Beispiel durch elektronische Unter-
stützung. Sie sind für das Unternehmen weder zum aktuellen Zeitpunkt noch in der Zukunft
erfolgskritisch und meist ausserhalb der Kernkompetenzen angesiedelt.
Frühauf u. a. (2001) teilt Projekte grob in drei Gruppen anhand des typischen Inhalts der Pro-
jekte.
23
2. Grundlagen und Begriffe
B: Interne Projekte: Unternehmensintern wird ein IT-Projekt für den Eigenbedarf entwickelt.
Auftragnehmer und -geber gehören hierbei dem gleichen Unternehmen an. Konflikte
werden über den gemeinsamen Vorgesetzten gelöst.
2.2.2.4. Fazit
Projekte können anhand unterschiedlicher Merkmale klassifiziert werden (Jenny (2005), Kes-
sler u. Winkelhofer (2004), Frühauf u. a. (2001)). Dabei werden diese Merkmale je nach Be-
reich des Projektes und Grösse und Art des Unternehmens unterschiedlich stark gewichtet
sowie fortlaufend angepasst oder neu definiert. In der Informatik, speziell in der Applikations-
und Softwareentwicklung und grundlegend für diese Arbeit, möchte ich Projekte nach folgen-
den Merkmalen charakterisieren:
Stakeholder: Als Anspruchsgruppen (engl.: Stakeholder) gelten alle Beteiligte in einem Pro-
jekt, wobei einzelne Personen mit gleichen Anforderungen und Interessen zusammen-
gefasst werden. Ein Stakeholder muss nicht zwingend während der Entwicklung am
Projekt beteiligt sein. Miteinbezogen werden hier auch Gruppen, welche erst nach dem
Projektabchluss vom Resultat profitieren, so zum Beispiel die Endbenutzer bei einer
Online-Applikation.
Als vereinfachte Struktur übernehme ich für die Definition der Stakeholder nach Frühauf
u. a. (2001) die drei Gruppen Projekteigentümer, Projektleiter und Entwickler.
Benötigte Ressourcen: Nicht nur die personellen Ressourcen müssen in einem Projekt be-
trachtet werden, sondern auch räumliche und externe Ressourcen. Unter Ressourcen
sind z.B. Entwickler mit bestimmtem Know-How gemeint, aber auch externe Ressourcen
wie z.B. Juristen für rechtliche Abklärungen, hinzugekaufte Drittentwicklungen, externe
Manpower oder kundenseitige Mitarbeiter.
24
2.2. IT-Projektmanagement
Dezentralisierungsgrad: Der Dezentralisierungsgrad hat einen direkten Einfluss auf die so-
ziale Führung in einem Projekt. Ein stark dezentralisiertes Projektteam benötigt mehr
Koordination, bessere Kontrollen und virtuelle Kommunikationskanäle. In der heutigen
Zeit werden durch die moderne Informations- und Kommunikationstechnik und die Anfor-
derung an spezifisches Know-How einzelner Projektmitglieder vermehrt verteilte, soge-
nannte virtuelle Projektteams gebildet, welche an unterschiedlichen Standorten arbeiten
(Chen u. a., 2002).
Produktvariante: Bei der Produktvariante unterscheiden wir die beiden grössten Gruppen
Neuentwicklung und Weiterentwicklung, welche jedoch grundsätzlich die gleichen Pro-
jektmanagementmethoden verwenden.
Das Projektrisiko gilt gemäss DIN 62198 als die „Kombination aus Eintrittswahrscheinlichkeit
eines bestimmten Ereignisses und seinen Folgen für die Projektziele“. Die Risikofaktoren be-
treffen hierbei das Projekt selbst wie auch seine Umwelt. Gaulke (2004) nennt als Risikofak-
toren eines Projekts nebst externen Einflüssen wie Umwelt, Gesellschaft, Wirtschaft, Recht,
Zuverlässigkeit, Markt und Technik nur einen internen Aspekt: den Menschen.
Veränderungen: Anforderungen und Ziele ändern sich während eines Projektverlaufs. Die-
se Änderungen müssen nachverfolgt und richtig abgehandelt werden. Durch ein gutes
Change Management sowie klare Abläufe, offene Kommunikation und Transparenz kön-
nen Änderungen optimal umgesetzt und verfolgt werden.
Lieferung: Liefert der Auftraggeber seine vertraglich zugesicherten Leistungen nicht zur rich-
tigen Zeit, so können definierte Termine gefährdet werden. Ein genaues Festlegen des
Lieferumfangs und des Liefertermins erhöht die Transparenz.
25
2. Grundlagen und Begriffe
Unter dem magischen Dreieck versteht man das Management der ökonomischen Prozessziele
Leistung, Zeit und Kosten. Wird eine Komponente verändert, so müssen sich automatisch
auch die beiden anderen Komponenten ändern, um das Dreieck im Gleichgewicht zu halten.
Das Problem beim magischen Dreieck ist die Fokussierung auf diese drei Prozessziele und die
Vernachlässigung anderer wichtiger Faktoren wie Qualität, Erfolgsfaktoren, soziale Führung
und Produktentwicklung. Die Theorie des magischen Dreiecks funktioniert nur in einem Projekt
mit einem reibungslosen Ablauf, und dies ist oftmals nur in kleinen und unkritischen Projekten
mit geringer Komplexität zu finden (vgl. auch Kapitel 2.2.4.1).
Klassisches Projekt-Controlling überwacht hierbei nur die obigen drei Prozessziele. Dass dies
heutzutage nicht mehr den Anforderungen genügt, muss hier nicht explizit erwähnt werden.
Klar definierte Ansprechpartner in jeder Disziplin eines Projektes und ein grundlegendes Ver-
ständnis der Vorgehensweisen wie auch die richtige Beurteilung und Einschätzung von Auf-
gaben sind Grundvoraussetzung zur Steuerung eines Projekts (Stoyan, 2004). Nach Jenny
(2005) ist für die Steuerung eines Projektes nebst brauchbaren Planungsvorgaben auch ein
geeignetes Messverfahren zur Projektkontrolle notwendig, um mögliche Abweichungen festzu-
stellen. Die so erkannten Abweichungen können mit entsprechenden Massnahmen korrigiert
werden.
Als Voraussetzung für eine erfolgreiche Steuerung sind gemäss Jenny (2005) folgende Punkte
zu erfüllen:
• Klare Projektabwicklungsziele
26
2.2. IT-Projektmanagement
Einen grossen Einfluss auf die Effektivität der Steuerung hat die Erfahrung des Projektleiters,
da Steuerungsmassnahmen meist mehr als eine der Projektgrössen Kosten, Leistung, Termin
und Qualität betrifft. Das Teufelsquadrat (siehe Abbildung 2.7, S. 27) zeigt auf, wie sich Än-
derungen an einer Projektgrösse auf den ganzen Rahmen auswirken. Für eine Optimierung
stehen dem Projektleiter im Voraus konstruktive und im Nachhinein analytische Massnahmen
zur Verfügung. Diese können unter dem Aspekt der direkt oder indirekt wirksamen Steuerung
betrachtet werden.
Die direkt wirksame Steuerung wirkt sofort und kurzfristig auf Differenzen zwischen der Pla-
nung und der Gegenwart sowie auf die Differenzen, welche durch den Vergleich des geplanten
27
2. Grundlagen und Begriffe
und des erstellten Lieferobjekts aufgedeckt wurden. Eine nicht abschliessende Liste von Pro-
jektführungstätigkeiten für die direkt wirksame Steuerung gibt uns Jenny (2005):
Aufwand und Termineinhaltung werden durch Schätzung und Projektplan festgelegt. Die re-
gelmässige Prüfung des Fortschritts wird durch den Fertigstellungsgrad aller Aufgabenpakete
errechnet. Durch die Berechnung der bisherigen Aufwände können durch einen SOLL-IST-
Vergleich Abweichungen vom Plan festgestelltund die erforderlichen Massnahmen eingeleitet
werden. Weicht der Projektstand aufgrund von Änderungen der Projektziele ab, so müssen
Schätzung und Projektplan neu erstellt werden. Um eine termingerechte Abgabe dennoch
zu gewährleisten, können weitere Ressourcen hinzugezogen oder der Umfang reduziert und
einzelne Lieferobjekte priorisiert werden.
Ist durch die Projektziele definiert, welche Leistungen erbracht werden müssen, so muss die
Qualität der einzelnen Disziplinen, darunter Strategie, IT, Design und Inhalt, fortlaufend kon-
trolliert werden. Werden während des Projektes Abweichungen festgestellt, so muss in jeder
Disziplin so früh als möglich das Nötigste unternommen werden, um den Qualitätsansprüchen
aller Beteiligten gerecht zu werden. Hierzu erarbeiten die Qualitätsbeauftragten einer jeden
Disziplin in Abstimmung untereinander die erforderlichen Schritte, um einen Mindest-Standard
halten zu können.
Risiken müssen vom Projektleiter erfragt und von den Projektmitgliedern mitgeteilt werden.
Auch die Auftraggeberseite soll frühzeitig über bestehende Risiken informiert werden. Es ist
nicht möglich, innerhalb eines Projekts alle Risiken zu vermeiden. Wichtig jedoch ist, diese
frühzeitig zu identifizieren und auf der Ebene der Entscheidungsträger zu lösen.
28
2.2. IT-Projektmanagement
Aus Kundensicht können durch Abhängigkeiten von einem Dienstleister schnell hohe Kosten
entstehen. Durch das Abliefern von Teilergebnissen, der Wahl einer verbreiteten Technologie
und der Beteiligung und Einarbeitung kundenseitiger Mitarbeiter kann die Höhe der Wechsel-
kosten und somit die Abhängigkeit vom Dienstleister verringert werden. Auf Dienstleistersicht
sind vorwiegend projektexterne Abhängigkeiten zu minimieren. Die grösste Gefahr besteht
bei projektexternen Entscheidungen, Informationen und Dokumenten. Ein guter Ansatz ist der
Einbezug der externen Entscheidungsträger in das Projektteam, um Wartezeit und somit diese
Abhängigkeit zu verringern.
2.2.4.4. Fazit
Die Steuerbarkeit in einem Projekt hängt von der Umgebung und der betroffenen Grösse ab.
Während messbare Grössen wie Zeit und Qualität durch den Projektplan kontrolliert und direkt
korrigiert werden können, so können vorwiegend soziale Aspekte und Akzeptanz nur indirekt
über längere Zeit hinweg gesteuert werden und gehören in den Bereich der sozialen Projekt-
führung. Die indirekt steuerbaren Aspekte betreffen hierbei meist nicht nur eine Phase des
Projekts, sondern ziehen sich über mehrere Phasen und auch über mehrere Projekte hin-
weg.
Gemäss einer Untersuchung der Standish Group (siehe Abbildung 1.1, S. 10) konnten im
Jahre 2004 nur knapp 30% der IT-Projekte erfolgreich abgeschlossen werden. 18% scheiterten
29
2. Grundlagen und Begriffe
komplett. Mehr als die Hälfte der Projekte konnten zwar abgeschlossen werden, musste aber
für einen erfolgreichen Abschluss an die äusseren Bedingungen angepasst werden.
Projektmanagement als Führung, Information und Prozess konzentriert sich auf die effekti-
ve und effiziente Gestaltung der Erfolgsfaktoren. Zu den Erfolgsfaktoren des Projektmanage-
ments zählen die Erreichung der definierten Projektziele unter der Einhaltung der geplanten
Ressourcen wie Zeit, Kosten und Kapazitäten. Sie stellen den Unternehmenserfolg sicher und
sind abhängig von den Erfolgsfaktoren für das Projektmanagement eines einzelnen Projekts
(Kessler u. Winkelhofer, 2004). Nebst dem Projektabwicklungserfolg, welcher durch die Pro-
jektabwicklungsziele definiert ist, kann auch der Systemerfolg anhand der Systemziele und
den Faktoren Akzeptanz und Wirtschaftlichkeit gemessen werden (Jenny, 2005). Wegmann u.
Winklbauer (2006) nennt als wichtige Erfolgsfaktoren:
• Realistic and manageable Scope: Ist der Arbeitsumfang des Projekts realistisch einge-
schätzt und machbar?
Soziale Erfolgsfaktoren
Während sich Wegmann u. Winklbauer (2006) auf messbare und kontrollierbare Erfolgsfak-
toren beschränkt, werden in der systemischen Projektführung die sozialen Erfolgsfaktoren
Macht, Zusammenarbeit, Wissen, Information und Identität betrachtet. Diese können als Leit-
fragen an die Stakeholder gestellt werden (Huber, 2007):
• Identität: Macht das Projekt für den Sponsor und Ihre Anspruchsgruppe zum jetzigen
Zeitpunkt Sinn?
• Macht: Liegt das vom Projekt zu entwickelnde Produkt im Interesse des Sponsors und
im Interesse Ihrer Anspruchsgruppe?
• Wissen: Verfügt Ihre Anspruchsgruppe über genügend Wissen für die Unterstützung des
Projekts? Wie fliesst das Wissen?
30
2.2. IT-Projektmanagement
• Informationen: Verfügen Sie über die vorgesehene Informationen für das Projekt und
können Sie die erhaltenen Informationen aufnehmen und prozessieren? Wie gehen Sie
beim Informationsaustausch vor, so dass alle Beteiligten jederzeit die notwendigen In-
formationen abrufen können?
• Zusammenarbeit: Sind sie zu einer Zusammenarbeit mit dem Projekt bereit? Können
Sie die Teammitglieder genügend motivieren, Konflikte lösen und Interessengegensätze
miteinander vereinbaren?
31
2. Grundlagen und Begriffe
32
3. Theorie des Projektmanagements
Dieses Kapitel widmet sich den Theorien des Projektmanagements. Die Literatur listet eine
Vielzahl unterschiedlicher Theorien, welche sich im Detailierungsgrad, dem Fokus und dem
Ablauf stark unterscheiden. Zuerst werden die klassischen Theorien von Jenny (2005) und
Specker (2004) sowie deren Abläufe und Artefakte erläutert. Diese beiden Theorien unter-
scheiden sich in der Art der Prozessgestaltung, decken jedoch einen grossen Teil der wichti-
gen Aspekte ab. Danach folgen die agile Methode „Scrum“ und der MIO-Ansatz. Der Abschnitt
der Prozessintegration soll aufzeigen, wie klassische und agile Methoden in den MIO-Ansatz
integriert werden können.
Ein Projekt, welches innerhalb einer Organisation durchgeführt wird, hängt auch stark von der
unternehmensinternen Struktur, dem Aufbau der Hierarchie und der Verteilung der Kompeten-
zen ab. Um deren Zusammenhang zu verstehen, werden zuerst die Arten der Projektorgani-
sation und die Rollen und Gremien erklärt. Obwohl ein Projekt nicht zwingend die Organisa-
tion eines Unternehmen abbilden muss, finden sich in einer Projektorganisation oftmals die
gleichen Strukturen wieder. Das Informations-, Dokumentations- und Sachmittelsystem bilden
grundlegende Begleitprozesse eines jeden Projekts.
33
3. Theorie des Projektmanagements
3.1.1. Projektorganisation
Bei einer Linien-Organisation werden die Mitglieder aus der Firmenhierarchie herausgenom-
men und zu 100% in einem einzelnen Projekt eingesetzt. Durch die hohe Effizienz und die ein-
fache Entscheidungsfindung aufgrund der gesamten fachlichen Kompetenz des Projektleiters
verkürzt sich die Projektdauer. Ist ein Projekt abgeschlossen, müssen die Projektmitglieder
jedoch wieder in neuen Projektteams, welche oftmals einem anderen Projektleiter unterstellt
sind, eingesetzt werden.
Als Mischform der oben genannten Organisationen gilt die Matrix-Organisation. Während
eines Projekts entsteht ein zeitlich befristetes Mehrliniensystem. Der Projektleiter hat hier
die projektbezogenen Kompetenzen gegenüber den Projektmitgliedern, der Linienvorgesetzte
kümmert sich weiterhin um das Anstellungsverhältnis und regelt die Integration in die Fir-
menhierarchie. Die Projektmitglieder arbeiten fix zu einem bestimmten Prozentsatz für ein
bestimmtes Projekt.
Für Stellen in einer Projektorganisation werden die Aufgaben, Kompetenzen und Verantwor-
tungen (AKV) festgelegt, um das strukturierte Vorgehen zu unterstützen sowie die Koordinati-
on zu vereinfach und den Entscheidungs- und Eskalationsweg zu regeln. Wie bei herkömmli-
chen Stellenbeschreibungen sollten alle Aspekte von AKV pro Rolle aufeinander abgestimmt
34
3.1. Allgemeines Projektmanagement
sein, damit alle Projektmitglieder ihre Aufgaben im Grundsatz der Einheit und Kongruenz er-
füllen können. Um zugeteilte Aufgaben abzuschliessen, werden die entsprechenden Kompe-
tenzen benötigt, und über diesen Bereich trägt das Projektmitglied auch die Verantwortung.
3.1.3. Informationssystem
35
3. Theorie des Projektmanagements
Eine Projektsitzung wird einberufen, wenn Kommunikation benötigt wird und Informationen in
beide Richtungen fliessen sollen. Als Dialoge gelten unter anderem Telefonate und Diskussio-
nen. Sie sind eine wichtige jedoch zeitintensive Art von Informationsaustausch. Ein grosser Teil
der Dialoge wird als Koordinationstätigkeit verstanden. Dialoge finden meist informell statt. Im
Gegensatz zur Projektsitzung fliesst die Information bei der Präsentation anfangs nur in eine
Richtung. Erst nach der eigentlichen Präsentation kann, muss aber nicht, eine Diskussion fol-
gen. Nach der Durchführung folgt die Nachbearbeitungsphase, in welcher Bilanz über positive
und negative Aspekte gezogen wird. Bei Projektberichten werden Informationen als Rapporte
rein schriftlich festgehalten. Der wichtigste Bericht ist der Projektstatusbericht. Dieser dient als
Kontroll- und Steuerungsmassnahme während eines Projekts und wird periodisch verfasst.
Die Informationen für den Projektstatusbericht erhält der Projektleiter aus unterschiedlichen
Quellen und fasst daraus folgende Aspekte zusammen:
• Erzielte Erfolge
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 her-
vorgehen. Zu den Dokumenten der Projekt-Durchführung gehören nebst dem Business Case
36
3.2. Projektmanagement nach Jenny
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
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.
Jenny (2005) unterteilt den Ablauf eines Projekts in die zwei Bereich Führung und Durchfüh-
rung und fasst diese beiden Bereiche unter dem Begriff der Projektabwicklung zusammen.
Die weiteren Management-Funktionen (Projektportfolio, Risiko, Qualität, Team, Konfiguration,
37
3. Theorie des Projektmanagements
38
3.2. Projektmanagement nach Jenny
Changemanagement), welche den Projekterfolg massgeblich beeinflussen, wirken auf das ge-
samte Projektmanagement-System ein und laufen parallel zur Projektabwicklung. Allem zu-
grunde liegt die Projektinstitution, auf welcher das gesamte Projekt aufbaut (siehe Abbildung
3.1, S. 38).
3.2.1. Projektinstitution
Im Zuge der Projektinstitution wird die Projektorganisation aufgebaut (vgl. Kapitel 3.1.1), Auf-
gaben, Kompetenzen und Verantwortung (vgl. Kapitel 3.1.2) sowie das Informations-, Dokumentations-
und Sachmittelsystem (vgl. Kapitel 3.1.3, 3.1.4, 3.1.5) festgelegt. Diese fünf Bereiche bilden
die Projektbasis.
3.2.2. Projektabwicklung
Die Projektabwicklung umfasst die zwei Kernelemente der Führung und Durchführung eines
Projektes. Dabei arbeiten die zwei Bereiche parallel zueinander. Abbildung 3.2 zeigt das dy-
namische Zusammenspiel zwischen der Führung und Durchführung in einem Projekt.
3.2.2.1. Projektführung
Zur Projektführung gehören die funktionielle und die personenbezogene Führung. Für weitere
Erläuterungen zur personenbezogenen Führung sei auf Kapitel 3.2.3.4 verwiesen.
Projektstart
Die einzelnen Schritte in der Startphase eines Projekts laufen sequentiell ab. Die wichtigsten
Führungsaufgaben sind u.a. die Problemformulierung, Zielsetzung und Zuständigkeitsdefinie-
39
3. Theorie des Projektmanagements
rung. Nach der Genehmigung des Projektantrages durch den Projektportfolio-Controller oder
Abteilungsleiter werden bei der Initialisierung die wichtigsten Eckdaten des Projekts festge-
legt (Start-, Endzeit, Kosten, Qualität etc.) sowie Nutzen, Realisierbarkeit und Erfolgschancen
beurteilt. In dieser Phase entstehen der Business Case, der Anforderungskatalog, der Pro-
jektplan und ein umfassender Projektantrag, welche in das Dokumentationssystem abgelegt
werden. Für die Freigabe geht der Projektauftrag zur Prüfung an die oberen Instanz zurück,
und erst durch die Entscheidungen des Auftraggebers und des Projektleiters wird der Projekt-
antrag endgültig gutgeheissen oder abgelehnt.
3.2.2.2. Projektplanung
Projektstrutkurplan: Als Basis für die Ablauf-, Ressourcen- und Terminplanung gilt der Pro-
jektstrukturplan, der die Gesamtaufgabe in plan- und kontrollierbare Arbeitspakete glie-
dert. Alle Arbeitspakete zusammen stellen den gesamten Leistungsumfang des Projek-
tes dar. Die Aufteilung der Komponenten in einem Projektstruktruplan kann nach Arbeit-
spaketen (objektorientiert) oder nach Projektaufgaben (vorgehensorientiert) erfolgen.
40
3.2. Projektmanagement nach Jenny
Ablaufplan: Der Ablaufplan zeigt die sachlogische Reihenfolge der Arbeitspakete, ohne die
genauen Zeitpunkte anzugeben. Als Hilfestellung kann eine Arbeitspaket-Liste erstellt
werden, auf welcher Vorgangsdauer, direkte Vorläufer und Nachläufer aufgeführt sind.
Ein Ablaufplan kann beispielsweise als Plan-Net dargestellt werden.
Ressourcenplan: Verfügbare Personal- und Sachmittel werden ermittelt und den einzelnen
Arbeitspaketen zugeordnet. Diese Ressourcen werden im Ablaufplan angefügt und da-
nach in das Kapazitätsbelastungs-Diagramm übertragen, auf welchem die optimale Aus-
lastung ersichtlich ist.
Terminplan: Im Terminplan werden die wichtigen Termine und die Meilensteine sowie Be-
ginn und Ende der Arbeitspakete festgehalten. Als Basis werden die vorgängig erstellen
Struktur-, Ablauf- und Ressourcenpläne herangezogen. Der Terminplan bildet den Ab-
schluss dieses Planungsprozesses. Änderungen an den Planwerten wirken sich somit
auf alle vier oben genannten Pläne aus.
Projektbudgetplan: Der Projektbudgetplan wird meist über den Zeitrahmen eines Jahres er-
stellt und zeigt das verfügbare Budget pro Monat in Abhängigkeit an Zeit-, Kosten- und
Arbeitspaket-Vorgaben an. Deckt sich das Projektbudget nicht mit den Vorgaben des
Auftraggebers, so können frühzeitig Abweichungen festgestellt werden und somit Anfor-
derungen reduziert oder Bugetänderungen beantragt werden.
41
3. Theorie des Projektmanagements
3.2.2.3. Projektsteuerung
3.2.2.4. Projektkontrolle
Durch die Kontrolle von Lieferobjekten durch eine höhere Instanz wird die Verantwortung
des Projektleiters weitergegeben. Durch eine regelmässige Prüfung und somit Abschluss be-
stimmter Lieferobjekte kann der Projektleiter sein Verantwortungsvolumen überwachen und
Arbeitspakete abschliessen. Eine regelmässige Kontrolle hilft ebenso, frühzeitig Fehler zu ent-
decken und diese möglichst kostengünstig zu beheben.
Die Dimensionen der Projektkontrolle definieren, wie und von wem zu welchem Zeitpunkt ein
Lieferobjekt kontrolliert wird. Zur Planungskontrolle gehören hierbei die Kontrolle von Aufwand,
Kosten und Terminen. Im Bereich der Realisierung werden Fortschritt, Qualität, Dokumentati-
on und Inforamtion kontrolliert.
Aufwand und Kosten: Die Arbeitsrapporte der Projektmitglieder werden nicht nur auf Voll-
ständigkeit, sondern auch auf deren Inhalt kontrolliert. Eine Stundenerfassung auf die
einzelnen Arbeitspakete ist hierbei ideal und erleichtert den SOLL/IST-Vergleich von Ko-
sten und Aufwänden und somit den Budgetverbrauch.
Termine und Fortschritt: Schätzen die Projektmitglieder den Fertigstellungsgrad ihrer Lie-
ferobjekte, so kann daraus der Stand der einzelnen Arbeitspakete errechnet werden.
Verspätungen werden somit frühzeitig sichtbar, worauf der Projektleiter die entsprechen-
den Massnahmen einleiten kann. Kann der Fortschritt der einzelnen Arbeitspakete er-
rechnet werden, so gibt dies ebenfalls Rückschluss auf den Stand des gesamten Pro-
jekts.
Qualität: Bei der Qualitätskontrolle wird die Qualität der eingesetzten Kontrollmechanismen
beurteilt, welche als Grundlage für die Abnahme und Freigabe von Zwischenprodukten
dient.
42
3.2. Projektmanagement nach Jenny
Dokumentation: Die Prüfung der Dokumentation geschieht durch den Empfänger hinsicht-
lich Firmennormen, Versionierung und Inhalt. Eine regelmässige Kontrolle der Doku-
mentation ist wichtig, um deren Aktualität und Vollständigkeit zu garantieren.
Information: Der Informationsfluss sowie die Häufigkeit und der Inhalt von Berichten stehen
im Fokus der Informationskontrolle. Für ein erfolgreiches Projekt ist es wichtig, dass alle
Beteiligten zum richtigen Zeitpunkt über die richtigen Informationen verfügen.
Der Kontrollzeitpunkt bestimmt die Durchfühung und wird in einem Prüfplan festgelegt. Klare
Kontrollzeitpunkte sind Phasenenden und Meilensteine. Jedoch sollten die Abstände zwischen
zwei Kontrollen nicht grösser als drei Monate sein respektive das zu prüfende Volumen nicht
mehr als 300 Arbeitstage umfassen.
Projektabschluss
Ein Projekt wird nicht durch die Einführung, sondern durch den Projektabschlussbericht und
die Aufräumarbeiten beendet. Im Abschlussbericht werden die Abwicklungsziele Leistung,
Qualität, Zeit, Kosten) sowie Nichterfolge und die Gründe dafür festgehalten. Zu den Aufräum-
arbeiten gehören die Sicherung des während des Projekts angeeigneten Wissens sowie die
Auflösung des Projektteams. Die folgende Aufzähung listet die sechs Fragen, welche für einen
erfolgreichen Projektabschluss abgearbeitet und in den Abschlussbericht aufgenommen wer-
den (Jenny, 2005):
3.2.2.5. Projektdurchführung
43
3. Theorie des Projektmanagements
Zur Durchführung gehören die sequenziell ablaufenden Phasen Impuls, Initialisierung, Kon-
zeption, Realisierung, Einführung und Nutzung.
Die ersten beiden Phasen, Impuls und Initialisierung, beziehen sich auf den Projektstart (siehe
Kapitel 3.2.2.1). Der Impuls gilt als Vorphase der Projektabwicklung und liegt den Grundstein
für ein neues Projekt. Hier werden Problemstellung, Bedarf und Idee in einem kurzen Bericht
sachlich dargelegt. Ebenso werden die benötigten Ressourcen für die Initialisierun geschätzt
und beantragt. Werden diese vom Linienvorgesetzten gutgeheissen, werden in der Initialisie-
rungsphase die Wirtschaftlichkeit, der konkrete Bedarf sowie die Systemziele des Vorhabens
geprüft.
In der Konzeptionsphase wird das Problem erfasst und eine detailliert beschriebene, realisier-
bare Lösung erstellt. Der Problemlösungsprozess teilt sich hierbei in sechs Phasen:
Zieldefinition: Wichtig ist die Messbarkeit der Ziele sowie dass diese lösungsneutral sind.
Ebenso müssen sie erreichbar und bewertbar sein. Zielkonflikte sind von vorn herein zu
bereinigen.
Erhebung und Analyse: In dieser Phase werden alle Daten für die Definition des IST- und
des SOLL-Zusandes gesammelt, nach Abhängigkeiten gruppiert und analysiert. Von der
Genauigkeit der Erhebung hängt die Qualität der zukünftigen Lösung ab.
Würdigung: Bei der Würdigung wird der IST-Zustand nach seinen Stärken, Schwächen, Chan-
cen und Gefahren (SWOT-Analyse) bewertet.
Lösungsentwürfe: Durch Erhebung und Analyse kennt man den IST-Zustand, durch die
SWOT-Analyse weiss man, welche Aspekte am IST-Zustand gut oder nicht so gut ist und
durch die Zieldefinition kennt den gewünschten SOLL-Zustand. Anhand dieser Grund-
lagen werden Lösungen und Alternativen gesammelt, welche danach konkretisiert und
analysiert werden. Je mehr Lösungsvorschläge vorhanden sind, desto grösser ist die
Wahrscheinlichkeit, die bestmögliche Lösung gefunden zu haben.
Bewertung und Entscheid: Die unterschiedlichen Lösungsansätze werden bewertet und dem
Auftraggeber vorgelegt, bei welchem auch die Entscheidugsgewalt liegt. Entscheiden
bedeutet hier, aus einer Vielzahl von Alternativen diejenige auszuwählen, mit der das
definierte Ziel unter Einhaltung der verfügbaren Ressourcen optimal erreicht werden
kann.
In der vierten Phase, der Realisierungsphase, werden die Lieferobjekte gemäss vorgängig
festgelegten Kriterien umgesetzt und mit Tests abgeschlossen. Anhand der Test- und Projekt-
statusberichte entscheidet der Auftraggeber, ob ein Produkt eingeführt wird.
44
3.2. Projektmanagement nach Jenny
Ist das Produkt abnahmebereit und sind somit alle Bedingungen seitens des Auftragnehmers
erfüllt, so wird das Produkt für die Einführung freigegeben. Je nach Produktart und Entschei-
dung des Auftraggebers, kann das Produkt auf einen bestimmten Stichtag, schrittweise und
somit Teilbereich für Teilbereicht oder parallel zum bisherigen Produkt eingeführt werden.
Die Nutzung gehört wie auch der Impuls nicht zum eigentlich Projekt, ist jedoch für den Pro-
duktlebenszyklus bedeutend. Für detailliertere Informationen sei auf Jenny (2005) verwie-
sen.
3.2.3. Projektmanagement-Systemelemente
3.2.3.1. Projektportfoliomanagement
Der Projektportfolio-Controller überwacht alle Projekte und stellt den Stand im Projektportfolio-
Controllingbericht (PPC) zusammen. Dabei werden die Projekte als grün, gelb (kritisch) oder
rot (gefährdet) deklariert. In der Besprechung des PPC mit den Projektleitern werden dann
die benötigten Massnahmen entschieden. Bei grossen Portfolios kann der Projektstatusbe-
richt elektronisch durch ein Projekt-Cockpit unterstützt werden, in welchem Risikoverfolgung,
Klassifizierung, Statusampeln, Meilensteintrend, Personalmittelplan und Finanzmittelplan auf-
geführt sind (vgl. Jenny (2005), S. 205). Je grösser das Unternehmen, je zahlreicher die Pro-
jekte und je länger die Projektdauer, desto wichtiger wird das Projektportfoliomanagement für
ein Unternehmen. Durch Priorisierungen können somit bei gefährdeten Projekten frühzeitig
Massnahmen ergriffen und so gesteuert werden.
3.2.3.2. Risikomanagement
45
3. Theorie des Projektmanagements
Risikomanagement ist nicht alleine das Auflisten und Verfolgen von Risiken, sondern erweitert
sich auf die Analyse und die Überprüfung in jeder Projektphase. Dabei können Projektrisi-
ken in die drei Gruppen Umsetzungsrisiken (Einführung, Funktion, Materialzulieferer), Mana-
gementrisiken (Projektführung, Planung, Kommunikation, Koordination) und Soziale Risiken
(Motivation, Mitarbeiter, Politisch) unterteilt werden. Alle Risiken werden in einem Zyklus identi-
fiziert, analysiert, bewertet, gesteuert und überwacht. Dieser sogenannte Risikomanagement-
Prozess ist iterativ und wird während des gesamten Projekts wiederholt.
3.2.3.3. Qualitätsmanagement
Mittels der Qualitätslenkung wird sichergestellt, dass die der Prüfplan eingehalten werden
kann und die Qualitätsanforderungen rechtzeitig erreicht werden. Sie besteht grösstenteils
aus konstruktiven Massnahmen (Methoden, Richtlinien, Checklisten, Standards), die dafür
sorgen, dass das Produkt zum richtigen Zeitpunkt bestimmte Eigenschaften aufweist. Dabei
kann zwischen technischen, organisatorischen und psychologischen Qualitätsmassnahmen
unterschieden werden.
Als dritter Bereich kommt die Qualitätsprüfung, welche zu dem im Prüfplan definierten Zeit-
punkt das Produkt nach klar definierten Kriterien prüft. Bei der Prüfung werden Abweichungen
vom Entwicklungsziel wie auch von Normen und Verfahren aufgezeigt. Eine weitere Möglich-
keit der Qualitätsprüfung ist die Mängel- und Fehleranalyse, welche auf einem Mängelkatalog
und einem Fehlerbericht basiert.
46
3.2. Projektmanagement nach Jenny
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 Team-
auflösung nach Beedigung des Auftrags.
Die Teambildung besteht aus den Prozessen Forming, Storming, Norming und Performing.
Während des „Formings“ werden Aufgaben und Kompetenzen der einzelnen Teammitglieder
definiert. Ebenso müssen sich die Mitglieder an Rahmenbedingungen halten, so dass sich die
teamspezifischen sozialen Normen bilden können. In der darauf folgendef „Storming“-Phase
beginnen die Team-Mitglieder, ein konkurrenzierendes Verhalten aufzuweisen, um sich im
Team zu etablieren. Die Aufgabe des Teamleiters besteht darin, die Konflikte, welche persön-
licher oder sachlicher Natur sein können, anhand des richtigen Führungsverhaltens zu lösen.
Während des „Normings“ schafft sich das Team durch Kommunikation und Konfliktlösung eine
gemeinsame Identität. Sind die Probleme gelöst und die sozialen Normen geschaffen, kann
das Team während des „Performings“ durch eine freundliche und zuvorkommende Stimmung
die Energie auf die anstehende Aufgabe ausrichten.
Die Teamführung ist Aufgabe des Teamleiters und lässt sich in die zwei unabhängigen Dimen-
sionen personenorientiert und aufgabenorientiert teilen. Im so entstehenden Verhaltensgitter
lassen sich fünf Führungsstile abbilden, wobei jede Achse mit einem Wert von 1 bis 9 versehen
ist und somit die fünf Führungsstile 1.1, 1.9, 9.1, 9.9 und 5.5 entstehen (für detailliertere Infor-
mationen siehe Jung (2006)). Meist ist der Führungsstil 5.5 und somit ein guter Kompromiss
zwischen Mitarbeiter- und Aufgabenorientierung anzustreben.
Ist das Projekt beendet, wird durch die Teamauflösung das Projektteam sukzessive abge-
baut, damit die Teammitglieder in neue Projekte wechseln können.
3.2.3.5. Konfigurationsmanagement
47
3. Theorie des Projektmanagements
Specker (2004) unterscheidet den Projekt- und den Projektmanagementprozess. Der Pro-
jektmanagementprozess, bestehend aus Projektplanung, Projektmanagementausführung und
Projektüberwachung (Controlling), übernimmt eine überlagerte Projektführungsfunktion, wäh-
rend dessen unter dem Projektprozess das geeignete Vorgehensmodell (Wasserfallmodell,
Spiralmodell, Prototyping, XP, vgl. 3.5.1) verstanden wird. Parellel zum Projektmanagement-
prozess listet Specker (2004) sieben Managementfunktionen, welche während allen Prozes-
sen in unterschiedlicher Ausprägung wahrgenommen werden müssen (siehe Abbildung 3.3,
S. 48).
48
3.3. Projektmanagement nach Specker
Projektmanagementprozess
Projekte und Projektmanagement können als überlagertes System mit Teilbereichen aus dem
Systemumfeld und dem Projektumfeld aufgefasst werden. Dieses Projektsystem beinhaltet
Mitarbeiter, Aufgaben und Managementtools. Die Projektmanagementfunktionen begleiten al-
le Prozesse mit unterschiedlichen Schwerpunkten und sollten bei Projekten jeder Kategorie
verhältnismässig vertreten sein.
3.3.1. Projektmanagementfunktionen
Im Rahmen der Projektorganisation und des Teams sind zusätzlich generelle Führungsauf-
gaben wahrzunehmen (Führung, Motivation, Konfliktlösung). Viele Konflikte können bereits bei
der Intitialisierung des Projekts gesteuert werden.
Das Auftragsmanagement koordiniert die Übertragung und die Erledigung von Aufgaben so-
wie Verträge mit Kunden respektive Lieferanten und interne Projektvereinbarungen. Die inter-
nen Vereinbarungen beinhalten Verpflichtungen betreffend Umfang, Terminen und Ressour-
cen. Durch interne Contracts werden Mitarbeiter dazu gezwungen, ihre Arbeitskapazität mit
Fachvorgesetzten zu diskutieren und abzustimmen.
Durch das Terminmanagement werden Termine, Meilensteine und Lieferdaten für Arbeitspa-
kete definiert. Es ist gleichzeitig stark mit dem Ressoucenmanagement und dem Inhaltsma-
nagement gekoppelt.
Das Ressourcenmanagement beinhaltet die Planung der Ressourcen für das Gesamtprojekt
wie auf für jedes einzelne Teilprojekt. In diesen Bereich fallen auch die Verwaltung der Kosten
und die Projektinfrastruktur.
49
3. Theorie des Projektmanagements
Das Qualitätsmanagement unterteilt sich in Produkte- und Prozessqualität. Während die Pro-
duktequalität auf die Qualität des zu erstellenden Lieferobjekts fokussiert, werden bei der Pro-
zessqualität die Qualität der Projektabwichlung und des Projektmanagements überwacht.
Berichte werden während allen Prozessen im Projektmanagement erstellt und bilden die In-
formationsgrundlage für das gesamte Projekt.
3.3.2. Projektmanagementtätigkeit
Die foglenden Tabellen 3.3 bis 3.6 geben eine Ergebnisübersicht der Projektmanagementtä-
tigkeit während der vier Prozessphasen.
50
3.3. Projektmanagement nach Specker
51
3. Theorie des Projektmanagements
52
3.3. Projektmanagement nach Specker
53
3. Theorie des Projektmanagements
54
3.4. Agiles Projektmanagement: SCRUM
• Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a deve-
lopment team is face-to-face conversation.
• Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
55
3. Theorie des Projektmanagements
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
Der Scrum-Prozess besteht aus sechs Rollen, sechs Meetings und neun Artefakten.
Scrum kennt die klassische Rolle des Projektleiters nicht, sondern teilt die Projektmanagemen-
taufgaben auf die Scrum-Rollen auf (siehe Tabelle 3.7 auf Seite 57). Ein traditionell gemangtes
Projekt wird langfristig auf der Ebene der Taktik gemanagt, ein agil gemanagtes Projekt auf
der Ebene der Strategie. Diese Grundunterscheidung führt dann zu vollkommen anderen Vor-
gehensweisen in der Planung eines Projektes - nämlich zu einer strategischen Planung und
damit überhaupt erst zu einer Strategie mit klaren Zielen (Gloger, 2008).
56
3.4. Agiles Projektmanagement: SCRUM
3.4.2. SCRUM-Rollen
Die Rollen in Scrum entsprechen den Verantwortlichkeiten und sind keine Positionen innerhalb
des Unternehmens. Scrum kennt sechs Rollen, von welchen drei innerhalb des Systems an-
gesiedelt sind (siehe Abbildung 3.5, S. 57). Für vertiefte Informationen wird auf Gloger (2008),
Pichler (2007) und Mengelt (2008) verwiesen.
57
3. Theorie des Projektmanagements
Die Rolle des Product Owners (PO) repräsentiert die Endkundenbedürfnisse, vereint Produkt-
und Projektmanagementaufgaben in sich und ist zugleich fest in die Softwareentwicklung in-
tegriert. Der PO erfasst Kundenbedürnisse, beschreibt Anforderungen, managt und priorisiert
das Product Backlog, managt den Releaseplan und ist für den Erfolg des Projektes verantwort-
lich. Er schlägt somit die Brücke zwischen dem Endkunden und der Softwareentwicklung.
Scrum-Teams bestehen aus Mitarbeitern, welche über das relevante Wissen und die notwenid-
gen Fähigkeiten verfügen und produktiv zusammenarbeiten können. Sie weisen nach Pichler
(2007) folgende Eigenschaften auf:
Bevollmächtigt: Die Aufgaben werden nicht vom Management zugeteilt, sondern die Verant-
wortung liegt allein beim Team. Die Bevollmächtigung vereint Ursache und Wirkung: Das
Team wählt die umzusetzenden Anforderungen zu Beginn jeden Sprints aus und steht
zugleich in der Pflicht, die Auswahl zuverlässig in ein Produktinkrement umzusetzen 1 .
Autonom: Das Team muss seine Ziele ohne wesentliche externe Abhängigkeiten erreichen
können. Dies betrifft Lieferanten wie auch Arbeiten, welche von Mitarbeitern ausserhalb
des Teams erledigt werden sollten und ist ein Indiz dafür, dass das Team zu wenig
interdisziplinär besetzt ist.
Klein: Die optimale Führungsspanne liegt bei sieben Mitgliedern2 , wodurch ein Scrum Team
optimalerweise fünf bis neun Mitglieder umfasst.
58
3.4. Agiles Projektmanagement: SCRUM
Der Scrum-Master ist Coach und Change Agent und vollständig im Team integriert. Durch sei-
ne Arbeit fördert er neue Denk- und Verhaltensweisen und hilft, Scrum innerhalb des Unter-
nehmens zu etablieren. Er berät den Product Owner bei Erstellung des Backlogs, schützt das
Team vor externen Einflüssen und stellt die direkte Zusammenarbeit zwischen Product Owner
und Team sicher. Zudem ist es Aufgabe des Scrum-Masters, Hindernisse im Projekt wie auch
in der Infrastruktur zu beseitigen. Er verfügt über Einfluss, aber über keine Autorität. Um er-
folgreich zu sein und die eigene Rolle richtig ausführen zu können, sollte der Scrum-Master
über Kenntnisse in den Bereichen Moderation, Teambildungsprozess, kollaborative Entschei-
dungsfindung und Konfliktmanagement verfügen (Pichler, 2007).
Zusätzlich zu den drei Rollen innerhalb des Systems existieren drei weitere Rollen ausserhalb
der Systemgrenze.
Der Kunde kauft das Produkt oder hat es in Auftrag gegeben und kann innerhalb wie auch aus-
serhalb des Unternehmens angesiedelt sein. Seine Informationen gelangen über den Product
Owner in das System.
Der User des Produktes ist eine wesentliche Informationsquelle für das Scrum-Team. Er ist
es, der später die „Usable Software“ benutzen wird. Daher wird der Anwender in die Produkt-
Entwicklung vom Scrum-Team einbezogen. Anfangs beim Sprint Planning, wo er gemeinsam
mit dem Product Owner die Anforderungen definiert. Später wird er als Anwender mit dem
Team daran arbeiten, die Anwendung nutzbar zu machen.
Das Management stellt die Ressourcen und die Richtlinien innerhalb einer Organisation bereit.
Es schafft den Rahmen, in dem sich das Team, der Product Owner und der Scrum-Master
bewegen und löst oft die vom Scrum-Master identifizierten Probleme.
59
3. Theorie des Projektmanagements
3.4.3. Artefakte
Artefakte sind in Scrum Dokumente und visuelle Hilfsmittel, welche die Methodik des Projekt-
managements unterstützen. Dieser Abschnitt gibt keine vollständige Auflistung aller Artefakte
in Scrum. Für weitere Informationen wird auf Pichler (2007), Gloger (2008) und Mengelt (2008)
verwiesen.
Auf dem Product Backlog werden alle Product Backlog Items priorisiert aufgeführt. Es ent-
hält alle funktionalen und nicht funktionalen Merkmale sowie Anforderungen an die Benut-
zerschnittstelle. Für jedes Scrum-Projekt gibt es ein Product Backlog. Aktivitäten fehlen im
Product Backlog, diese werden vom Team identifiziert und als Task im Sprint Backlog fest-
gehalten. Gloger (2008) und Pichler (2007) nennen zudem folgende Eigenschaften für das
Product Backlog:
keine Spezifikation: Das Beschreibungslevel des Product Backlogs ist zu grob, um es als
Spezifikation für ein Produkt einsetzen zu können. Es enthält keine programmierspe-
zifischen Ausdrücke sondern ist in einer gut verständlichen Sprache für den Kunden
geschrieben.
nie vollständig: Das Product Backlog wächst und verändert sich ständig, wobei bestehende
Merkmale verändert oder gelöscht und neue hinzukommen. Da die einzelnen Backlog
Items erst bei der Übertragung ins Sprint Backlog detaillierter beschrieben und verfeinert
werden, gibt es in Scrum kein klassisches Change-Request Verfahren. Um Änderungen
dennoch nachvollziehen zu können, ist eine Versionierung des Product Backlogs sinn-
voll. Change-Requests erscheinen als neue Stories im Product Backlog.
kollaboratives Werk: Meist arbeitet der Product Owner bei der Erstellung des Product Back-
logs mit dem Team und weiteren externen Personen zusammen. Seine alleinige Aufgabe
besteht darin, die Backlog Items in eine Reihenfolge zu bringen, die aus Anwendersicht
Sinn macht (Priorisierung).
geschätzt: Jedes Product Backlog Item enthält eine grobe Schätzung über den Aufwand des
Merkmals. Die Schätzung wird vom Team vorgenommen.
60
3.4. Agiles Projektmanagement: SCRUM
Product Backlogs werden häufig in tabellarischer Form oder als Karteikarte pro Product Back-
log Item (Story Cards) festgehalten.
Story Cards sind optimal für Backlogs auf Teamebene und erfüllen die Forderungen der 3C3 :
Cards: User Stories (Backlog Items) werden auf Karteikarten geschrieben (Cards). Diese
Karte wird mit gerade soviel Text beschrieben, um jeden daran erinnern zu können,
was die Story bedeutet. Priorität und Schätzung werden auf die Karte geschrieben. Es
werden auch mögliche Überlegungen zur Umsetzung oder Abhängigkeiten auf der Karte
notiert.
Conversation: Der Product Owner erklärt das Backlog Item dem Team. Wenn bereits Doku-
mente vorliegen, werden diese besprochen. Das Backlog Item wird sicherlich erläutert,
wenn es geschätzt werden soll, es wird aber auch noch einmal im Sprint Planning Mee-
ting erläutert. Wenn nötig auch noch einmal im Anschluss während des Sprints.
Confirmation: Meist auf der Rückseite der Karte wird die Bestätigung geschrieben, die an-
zeigt, was erfüllt sein muss, damit die Story erfüllt ist. Diese Bestätigung wird in Form
von User Acceptance Tests geschrieben.
Während der Sprint-Planungssitzung wird ein realistisches Sprint Backlog festgelegt. Der Pro-
duct Owner stellt hierbei eine Vorauswahl seiner Product Backlog Items vor, das Team iden-
tifiziert die Aufgaben und wählt anhand der Story Points (Mass für den Aufwand eines Back-
log Items) die zu realisierenden Einträge innerhalb des nächsten Sprints („Selected Product
Backlog“). In einer zweiten Planungssitzung des Teams werden die Backlog Items detailliert
besprochen, wodurch das Sprint Backlog entsteht. Dieses kann elektronisch oder in Form von
Karten an einer Stellwand organisiert werden. Das Sprint Backlog wird täglich überarbeitet und
aktualisiert. Es hilft bei der Orientierung, wer was gerade macht und was noch getan werden
muss, um den Sprint erfolgreich abzuschliessen.
Burndown-Charts dienen im Scrum dem Reporting und zeigen den aktuellen Fortschritt eines
Sprints an, indem die erledigten Arbeiten beim visualisierten Graph abgezogen werden. Der
ideale Burndown entspricht einer linearen Linie bis zum Enddatum des Sprints. Durch das
täglich aktualisieren des Brundown-Charts kann eine aktuelle Trendlinie aufgezeigt werden.
3
nach Gloger (2008) und www.xprogramming.com/xpmag/expCardConversationConfirmation.htm
61
3. Theorie des Projektmanagements
Das Impediment Backlog besteht aus einer Liste aller Blockaden, die einem Team aus dem
Weg geräumt werden müssen, damit es produktiver werden kann (Gloger, 2008). Handelt es
sich hierbei um externe Einflüsse, so ist es Aufgabe des Scrum-Masters, sich um diese Hin-
dernisse zu kümmern und wenn möglich innerhalb von 24 Stunden aus dem Weg zu räumen.
Die Hindernisse werden täglich im Daily Scrum identifiziert und aufgelistet. Werden program-
miertechnische Hindernisse bei der Retrospektive festgestellt, so wird festgelegt, welche im
nächsten Sprint beseitigt werden sollen.
3.4.4. Sprint
Der Sprint ist in „Scrum“ ein Zyklus von zwei bis vier Wochen, innerhalb welchem ein lauf-
fähiges Stück Software oder eine neue Funktionalität erstellt wird. Er startet mit dem „Sprint
Planning Meeting“ und endet mit der „Retrospektive“. Die Aufgaben innerhalb eines Sprints
werden vom Product Owner in Zusammenarbeit mit dem Team festgelegt, wobei das Team
den endgültigen Entscheid über die umgesetzten Backlog Items hat.
3.4.4.1. Planungssitzung 1
Im ersten Meeting des Sprints sind alle Beteiligten anwesend, auch Management und Anwen-
der. Ziel ist es, die Anzahl der Backlog Items zu bestimmen in das „Selected Product Backlog“
zu übernehmen, welche innerhalb des Sprints vom Team umgesetzt werden können.
3.4.4.2. Planungssitzung 2
Das Team verfeinert während des zweiten Meetings die Backlog Items und definiert die anste-
henden Arbeiten (Architektur, Interfaces, Tests, UI Design, Tasks, usw.). Daraus resultiert das
Sprint Backlog.
Jeden Tag treffen sich die Teammitglieder zur gleichen Zeit am selben Ort 15 Minuten lang
zu einem vom Scrum-Master moderierten Meeting. An einem Daily Scrum können Projekt-
beteiligten teilnehmen, z.B. Stakeholders, Analysten, Product Owner oder ein Vertreter aus
dem Management - allderings bleibt nur den „committed“ Mitgliedern das Recht vorbehalten
zu sprechen. Das macht den Daily Scrum zu einer idealen Basis, um Informationen und Status
auszutauschen. In diesem Meeting besprechen die Teammitglieder folgende Punkte:
62
3.4. Agiles Projektmanagement: SCRUM
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).
Am Ende des Sprints präsentiert das Team die erarbeiteten Funktionalitäten. Das Team zeigt
dabei nur die Funktionalitäten, die in einem Zustand sind, die es erlauben würden, diese Funk-
tionalitäten sofort produktiv einzusetzen. Nicht getestete oder instabile Funktionalitäten wer-
den nicht gezeigt und gelten als nicht geliefert (Gloger, 2008).
Die Sprint Retrospektive ermöglicht das systematische Lernen des Teams. Hier wird analy-
siert, welche Arbeitsprozesse verbessert werden müssen, damit das Team effektiver arbeiten
kann. Dazu gehören auch zwischenmenschliche Unregelmässigkeiten und strukturelle Proble-
me. Die Resultate aus der Retrospektive werden im Impediment Backlog festgehalten und kön-
nen so als Verbesserungsvorschläge im Sprint Planning eingebracht werden (Gloger, 2008).
3.4.5. Fazit
Scrum fokussiert auf die Selbstorganisation des Teams, schnelle Entwicklungszyklen und so-
mit optimale Anpassungsfähigkeit an veränderte Umstände, mehr Kommunikation und mehr
Mitverantwortung, um die Effizienz bei der Programmierung zu steigern. Es definiert klare
Rollen, Verantwortung und Kompetenzen und regelt die Zusammenarbeit aller Beteiligten.
Nach einem Sprint wird ein auslieferbares Produktinkrement geliefert, welches zu Beginn des
Sprints im Sprint Backlog von Product Owner und Team definiert wurde. Scrum wird oftmals
im Zusammenhang mit agiler Softwareentwicklung eingesetzt, zum Beispiel mit Extreme Pro-
gramming (vgl. 3.5.1.4), ist grundsätzlich jedoch nicht an einen bestimmten Produktentwick-
lungsprozess gebunden. Ziele von „Scrum“ sind ein klarer Fokus auf Nutzenpotenziale, schnel-
le Reaktion auf Veränderung, phasenorientierte Lieferung der Funktionalität und ein iterativer
Entwicklungsansatz (Schopp, 2008).
63
3. Theorie des Projektmanagements
König (2008) führt aus, dass „Scrum“ alle drei Dimensionen von Erfolg (persönlich, technisch,
unternehmerisch) fördert: „Ohne persöhnlichen Erfolg ist man schwer motivierbar. Ohne tech-
nischen Erfolg gleicht die Codebasis häufig einem Teller Spagetti und ohne unternehmeri-
schen Erfolg wird sich das Team vom Unternehmen abwenden und eine neue Herausforde-
rung suchen.“
Der Ansatz Mensch - Informatik - Organistaion fokussiert auf drei parallel laufende Prozes-
se, welche im Verlaufe eines Projektes abgewickelt werden. Der erste Prozess, das klassi-
sche Projektmanagement, managt die ökonomischen Prozessziele Leistung, Zeit und Kosten.
Während die systemische Projektführung die sozialen Erfolgsfaktoren fördert, unterstützt der
Produktentwicklungsprozess die im Projektauftrag definierten Lieferobjekte. Die Schwierigkeit
liegt hierbei auf den unterschiedlichen Lebenszyklen wie auch auf unterschiedlichen Theorien
der drei Prozesse (Kuhnt, 2007). Die Vereinigung dieser drei Prozesse in einem ganzheitlichen
64
3.5. MIO Ansatz
Sieht man sich diese Gründe genauer an, so stellt man fest, dass einige der Punkte nicht
direkt mit dem Projekt zusammenhangen, sondern sich auf das Umfeld und die Organisation
ausserhalb des Projektsystems beziehen.
3.5.1. Produktentwicklungsprozess
65
3. Theorie des Projektmanagements
der Befragten Kompetenzen im Veränderungsmanagement für wichtig, 50% davon sogar für
besonders wichtig. Daher erstaunt es nicht, dass der Produktentwicklungsprozess und das
Veränderungsmanagement innerhalb eines Projektes stark miteinander verknüpft sind und
sich die Vorgehensmodelle laufend verändern.
3.5.1.1. Wasserfallmodell
In den 70er Jahren wurde das Vorgehen bei der Entwicklung eines Softwareproduktes vom
altbekannten Ingenieurwesen übernommen. Inhaltlich und zeitlich werden Phasen abgege-
grenzt, welche streng sequentiell und vollständig umgesetzt werden. Diese wissenschaftliche
Herstellung von Basisanwendungen hat lange Entwicklungszeiten zur Folge, da alle Teilpro-
zesse sequentiell durchlaufen werden und erst ganz zum Schluss eine betriebsfähige Software
ensteht, dafür mit vollem Funktionsumfang. Ebenso gibt es nach der Spezifikation kein Verän-
derungsmanagement mehr. Das Projektmanagement begleitet den Entwicklungsprozess par-
allel. Durch die langen Prozesse der Problemanalyse und Spezifikation sollen Fehler bereits
sehr früh erkannt werden, können jedoch in späteren Phasen nur schwer wieder behoben
werden. Da das Wasserfallmodell keine Lieferung von Teilobjekten vorsieht, kann erst bei der
Einführung festgestellt werden, ob die Software auch wirklich den Bedürfnissen der Endan-
wender entspricht. Diese und weitere Gründe verlangten schon bald ein Überdenken des Vor-
gehensmodells.
66
3.5. MIO Ansatz
3.5.1.2. Spiralmodell
Als Optimierung des Wasserfallmodells folgte in den 80er Jahren das Spiralmodell, welche
durch das zyklisch-iterative Verfahren bereits von Anfang an alle Stakeholder beteiligt und die
Zusammenarbeit zwischen Anwendung und Entwicklung fördert. Im Gegensatz zum Wasser-
fallmodell, wo pro Phase nur eine Tätigkeit ausgeübt wird, enthält eine Phase im Spiralmodell
alle Tätigkeiten. Somit unterscheiden sich die zwei Vorgehensmodelle nicht in der Art und
dem Inhalt der Tätigkeiten, sondern lediglich in der Zurodnung der Tätigkeiten zu den Phasen.
Zudem liefern die kürzeren Zykluszeiten beim Spiralmodell schnellere Ergebnisse, welche im
Anwendungsfeld erprobt werden können. Da kein Gesamtkonzept besteht, können Änderun-
ge während der Entwicklung eingebracht und umgesetzt werden. Scheitert ein Projekt, so ist
zumindest ein Teilnutzen verfügbar. Für das Management ergibt sich durch die Zyklen jedoch
die Gefahr, dass Probleme und Hindernisse in spätere Zyklen verschoben werden und durch
die fehlende Gesamtspezifikation das Ziel verfehlt wird.
3.5.1.3. Prototyping
In den 90er Jahren begann das Zeitalter der evolutionären Softwareentwicklung. Man ging vom
sozio-technischen Ansatz zum Design von Werkzeugen für die Praxis über und forcierte das
67
3. Theorie des Projektmanagements
klassische Projektmanagement. Primäres Ziel ist die Bestimmung und Validierung von Anfor-
derungen an ein Anwendungssystem (Ferstl u. Sinz, 2006). Mithilfe der Spezifikation mittels
Prototyping konnten kürzere Entwicklungszyklen und versionen-orientierte und evolutionäre
Ansätze verfolgt werden. Die entstandenen Softwarepakete können bereits von Anwendern
getestet und Änderungen und Erweiterungen in folgenden Releases implementiert werden.
Der evolutionäre Ansatz hat sich bis heute stark in der Softwareentwicklung verankert, da eine
optimale Anpassung an ein verändertes Umfeld möglich ist. Dennoch erschwert Prototyping
das Projektmanagement, da durch die schnelle Verfügbarkeit des Prototypen und seine Ände-
rungsfreundlichkeit die Plan- und Steuerbarkeit des Projekts erheblich erschwert wird (Alpar
u. a., 2005).
Man unterscheidet drei Arten von Prototyping:
Explorativ: Klärt sukzessiv die fachlichen Anforderungen durch wiederholte, schnelle Erzeu-
gung und Verwerfung von Prototypen in einer Testumgebung, welche nicht identisch mit
der vorgesehenen Entwicklungsumgebung sein muss. Exploratives Prototyping kann in
der Anforderungsanalyse bei unklaren Bereichen eingesetzt werden. Die Systemspezi-
fikation wird in Zusammenarbeit mit den Benutzern erarbeitet.
Experimentell: Weist die Realisierbarkeit eines Entwurfs vor dem Einstieg in die Implemen-
tierungsphase eines traditionellen Phasenmodells nach. Im Mittelpunkt steht nebst der
softwaretechnischen Realisierung auch die Kommunikation mit den Anwendern (Biet-
hahn u. a., 2004).
Extreme Programming (XP) ist ein agiler Softwareentwicklungsprozess für kleine Teams, wel-
che sich aus Kunden, Entwicklern und Management zusammensetzt. Der Prozess ermöglicht,
langlebige Software zu erstellen und während der Entwicklung auf vage und sich rasch än-
dernde Anforderungen zu reagieren (Westphal, 2001).
XP basiert auf den vier Werten Kommunikation (in Form persönlicher Gespräche mit dem
Kunden und Pair-Programming zwischen Programmierern), Einfachheit (die Motivation, die
einfachste Lösung zu finden), Feedback (als qualitätssichernde Komponente durch ständiges
Testen) und Mut (einfache Lösungen zu präsentieren und wieder von neuem zu beginnen, mit
68
3.5. MIO Ansatz
Kurze Releasezyklen: Die Entwicklung erfolgt in Perioden von ein bis drei Wochen. Am Ende
jeder Iteration steht ein funktionsfähiges, getestetes System mit neuer, für den Kunden
wertvoller Funktionalität.
Einfaches Design: Komplexe Strukturen auflösen, sobald diese entdeckt werden. Das Sy-
stem soll zu jedem Zeitpunkt möglichst einfach strukturiert sein.
Refactoring: Das Design des Systems wird fortlaufend in kleinen, funktionserhaltenden Schrit-
ten verbessert. Finden zwei Programmierer Codeteile, die schwer verständlich sind oder
unnötig kompliziert erscheinen, verbessern und vereinfachen sie den Code. Sie tun dies
in disziplinierter Weise und führen nach jedem Schritt die Unit Tests aus, um keine be-
stehende Funktion zu zerstören.
Gemeinsame Verantwortlichkeit: Der gesamte Code gehört dem Team. Jedes Paar soll je-
de Möglichkeit zur Codeverbesserung jederzeit wahrnehmen. Das ist kein Recht son-
dern eine Pflicht.
Fortlaufende Integration: Das System wird mehrmals täglich durch einen automatisierten
Build-Prozess neu gebaut. Der entwickelte Code wird in kleinen Inkrementen und spä-
testens am Ende des Tages in die Versionsverwaltung eingecheckt und ins bestehende
System integriert. Die Unit Tests müssen zur erfolgreichen Integration zu 100% laufen.
3.5.1.5. Fazit
69
3. Theorie des Projektmanagements
unterstützt wird. Während das Wasserfall- und Spiralmodell durch klassisches Projektma-
nagement begleitet wird, empfehlen sich für Prototyping und Extreme Programming agile
Projektmagement-Methoden.
3.5.2. Managementprozess
Der Inhalt des Projektmanagements besteht aus Abwicklung, Planung und Überwachung des
Projekts, wobei der Prozess des Projektmanagement eine übergelagerte Funktion der Pro-
jektführung übernimmt (Kuhnt, 2007). Es begleitet das Projekt von Beginn bis Ende und ist
unabhängig vom gewählten Vorgehensmodell. Der Projektauftrag, welcher vor dem eigentlich
Start des Projekts statt findet, gehört ebenfalls bereits zum Management-Prozess. Die funktio-
nalen Managementprozesse dienen der Optimierung der Koordination der Aktivitäten der am
Projekt beteiligten Akteure. Als Grundlage dienen klassische Management-Modelle (vgl 3.2,
3.3 und Tabellen 3.3, 3.4, 3.5), welche zwischen Initialisierung und Abschluss die zyklischen
Phasen Planung, Ausführung und Controlling beinhalten.
Unter Planung wird die vorausschauende Festlegung von Vorgaben zur Projektdurchführung
verstanden. In dieser Phase wird die Grundlage für die effiziente Koordination der beteiligten
Akteure geschaffen. Zu den Planungsaufgaben gehören u.a. die Definition klarer Vorgaben zur
effizienten Durchführung des Projekts, die Festlegung der logischen und zeitlichen Organisa-
tion einzelner Aktivitäten, die Ermittlung von Vorgaben für Projektzeitaufwand und Projektko-
sten, die Vorbereitung der Projektmanagementausführungs- und Projektkontrollmassnahmen
sowie die Bereitstellung von Informationen zur Abstimmung mit anderen unternehmerischen
Aktivitäten (Kuhnt, 2007).
Das Controlling soll Abweichungen zwischen IST- und SOLL Zustand überwachen (vgl. auch
3.2.2.4. Dabei setzt ein zielorientiertes Kontrollvorgehen einen vordefinierten Kontrollprozess
voraus, der bereits in der Initialisierungsphase aufgesetzt wird. Der Kontrollbereich beschränkt
sich jedoch nicht nur auf das Projektmanagement, sondern auf alle drei Prozesse, also auch
auf Führung und Produktentwicklung.
70
3.5. MIO Ansatz
3.5.3. Führungsprozess
Der Führungsprozess besteht aus den Phasen Etablierung, Konstituierung, Durchührung und
Abschluss, welches den zentralen Lebensphasen eines Projektteams entspricht. In der Praxis
werden der ersten und letzten Phase meist zuwenig Beachtung geschenkt. Während sich
Jenny (2005) mit der Projektführung unter dem Begriff des Teammanagements (vgl 3.2.3.4)
befasst, behandelt Specker (2004) die personelle Führung nur ansatzweise im Bereich der
Projektorganisation. Beide Theorien vernachlässigen jedoch die Projektetablierung, welche
passiert, bevor sich die vorgesehenen Personen das erste Mal treffen, sowie den Abschluss
resp. die Auflösung des Teams nach Beendigung des Projekts.
Die Etablierung klärt, inwieweit die Arbeitsform im Team für die Aufgabe nütztlich ist und
wie das Team zusammengesetzt werden soll (Brugger u. Soltermann, 2004). Nachdem die
Rahmenbedingungen und die Erwartungen an das Projekt mit allen Stakeholdern aus ver-
schiedenen Perspektiven eruiert wurde, erarbeitet die Projektleitung ihre Vorstellung über die
Teamzusammensetzung, Rollen- und Aufgabenverteilung und Hierarchie. Diese Phase wird
bei Jenny (2005) in der Phase der Teambildung („Forming“) umgesetzt.
Der MIO-Ansatz geht bei der Etablierung nach den drei Phasen „Unfreezing“, „Moving“ und
„Freezing“. Beim „Unfreezing“ werden für die potentiellen Anspruchsgruppen ein gemeinsa-
mer Rahmen geschaffen. Dabei werden alle Stakeholder informiert und deren Interessen,
Einstellungen und Probleme erfasst. Beim „Moving“ wird im gemeinsamen Gestaltungspro-
zess das Veränderungspotenzial erfasst und die gewünschten Änderungen im Projektauftrag
aufgenommen. Beim „Freezing“ wird der Projektauftrag fixiert. In die Phase der Etablierung
gehört auch die Klärung der sozialen Erfolgsfaktoren (vgl. 2.2.5).
Die Konstituierung entspricht im weiteren Sinne den drei Formen des Teambildungsprozes-
ses „Storming“, „Norming“ und „Performing“, wie sie auch in der Theorie von Jenny (2005)
beschrieben werden. Der ideale Rahmen für die Konstituierung schafft ein Kick-Off-Meeting
resp. -Workshop zu Beginn des Projekts, welches die Voraussetzung für eine synergetische
Zusammenarbeit schafft (Kuhnt, 2007). In dieser Phase wird auch der Grundstein für die Kom-
munikation der Teammitglieder geschaffen (vgl. auch 2.1.2).
71
3. Theorie des Projektmanagements
Aus systemischer Sicht ist die Aufgabe der Führung die Vermittlung zwischen den Ansprü-
chen an das Projektteam von aussen und der Arbeit des Projektteams (Brugger u. Soltermann,
2004). Dazu gehören zum Führungsprozess auch die Beobachtung der Gruppendynamik und
die Kommunikationsunterstütztung. Soziale und kommunikative Kompetenzen haben in der
Mitarbeiterführung eine hohen Stellenwert und beeinflussen die sozialen Erfolgsfaktoren Wis-
sen, Information und Zusammenarbeit.
Beim Abschluss werden Ergebnisse gefeiert und über die getane Arbeite reflektiert. Vor allem
in agilen Projektmanagmentmethoden wie Scrum wird dieser Phase eine grosse Wichtigkeit
zugestanden (vgl. 3.4.4.4, 3.4.4.5). Der Fokus liegt auf den Fehlern, die während einer Phase
oder eines Projekts entstanden, und die Lehre daraus, um eine Verbesserung und Optimierung
bei den nächsten Phasen und Projekten zu erlangen. Die Auflösung in Informatik-Projekten
ist nicht immer einfach, muss man doch den Abschluss des Projekts bestimmen und somit
den Übergang von Entwicklung zu Wartung definieren. Oftmals arbeiten Teammitglieder am
System weiter, obwohl das Projekt bereits als abgeschlossen gilt.
3.6. Prozessintegration
Der MIO-Ansatz selbst beschreibt keine Methoden für das Projektmanagement und die Füh-
rung, sondern basiert auf der Prozessdifferenzierung und darauf, dass die drei Prozesse Pro-
jektmanagement, Führung und Produktentwicklung parallel und in gegenseitiger Wechselwir-
kung ablaufen. Für ein erfolgreiches Projekt sind somit alle Prozesse zu begleiten, zu überwa-
chen und zu unterstützen.
Während die Produktentwicklung abhängig ist von der Komplexität der zu erstellenden Softwa-
re, dem Wissen und Interesse der Projektmitglieder und dem Typ des Projekts, laufen Manage-
ment und Führung ähnlich und in unterschiedlich ausgeprägter Form ab. Die folgenden beiden
Abschnitte geben Aufschluss darüber, in welcher Form die klassischen wie auch modernen
und agilen Managementmethoden auf die Prozesse der Führung und des Manaagements in
Anlehnung an den MIO-Ansatz abgebildet werden können.
72
3.6. Prozessintegration
3.6.1. Projektmanagement-Prozess
Während der Initialisierungsphase des Projektmanagements wird das Projekt oder die Projekt-
phase aufgesetzt. Er wird zum Projektstart initial ausgeführt und vor jeder neuen Projektphase
wiederholt. Die Artefakte werden hierbei um die Erkenntnisse der letzten Phase erweitert und
in einer neuen Version freigegeben.
Die Initialisierungsphase wird oft meist nur zum Projektstart durchgeführt und bei einer neuen
Phasenbeginn, vor allem bei knappen Ressourcen, zu wenig oder gar nicht beachtet. Bei den
klassischen Theorien zeichnet sich das Überspringen dieses Prozesses bei einer neuen Pha-
se durch nicht aktuelle Planwerte aus, welche möglicherweise ein Risiko aufzeigen könnten.
Bei Scrum werden die Arbeiten der Inititalisierungsphase bei jeder Planung wiederholt.
73
3. Theorie des Projektmanagements
Während der Planung werden Aufgaben betreffend Inhalte, Termine und Ressourcen logisch
und zeitlich koordiniert und Aufwände geschätzt. Durch die Planung soll Transparenz in den
Verlauf der Projektphase für alle gebracht werden.
Mit der Ausführung wird das eigentliche Durchführen des Projektmanagements bezeichnet
und bezieht sich in den klassischen Methoden auf die Arbeiten des Projektleiters, bei Scrum
beschreibt es die hauptsächlich die Aufgaben des Scrum Masters und des Teams.
74
3.6. Prozessintegration
Das Controlling begleitet das Projektmanagement kontinuierlich und wird mit verstärkten Fo-
kus am Ende jeder Phase durchgeführt. Es deckt Abweichungen zwischem aktuellen IST-
und dem SOLL-Zustand auf. Bei der Kontrolle wirkt nicht nur das Projektteam mit, sondern
auch Management und Auftraggeber können integriert werden, um fertige Lieferobjekte defini-
tiv abzunehmen. Kontrolle umfasst nebst den Lieferobjekten auch die Artefakte, zum Beispiel
die Terminplanung, Aufwand- und Kostenschätzung. Dafür stehen unterschiedliche Kontroll-
verfahren zur Verfügung, zum Beispiel Review, Audit oder Test (vlg. auch Jenny (2005)). Der
Abschluss findet wie die Initialisierung iterativ, nach jeder Phase sowie zum Projektende, statt.
75
3. Theorie des Projektmanagements
3.6.2. Führungsprozess
Der Führungsprozess beschäftigt sich mit der sozialen Führung der Projektmitglieder. In der
Etablierung werden wichtige Teamrollen festgelegt und Erwartungen abgeklärt. Während der
Konstituierung treffen sich die Teammitglieder das erste Mal physisch zum ersten Kick-Off
Meeting und dem eigentlichen Arbeitsstart der involvierten Projektmitglieder. Während der
Konstituierung treten auch die ersten Probleme auf, welche beiseitigt werden müssen, um das
Team als eine Einheit formen zu können.
76
3.6. Prozessintegration
Während der eigentlichen Führung beobachtet der Projektleiter die Eigendynamik des Teams
und reagiert bereits auf schwache Signale, um eine möglichst gute Atmosphäre und Arbeit-
sumgebung für alle Beteiligten zu schaffen. Unter Führung fällt auch die Teamzusammenset-
zung, welche im schlimmsten Fall geändert werden muss. Beim Abschluss werden Zwischen-
ergebnisse gefeiert und Phasen abgeschlossen. Dies ist auch der Zeitpunkt, über das Getane
zu reflektieren und Verbesserungen zu besprechen.
77
3. Theorie des Projektmanagements
3.7. Fazit
Das klassische Projektmanagemt kämpft mit diversen Problemen, welche sich aus veränder-
ten Anforderungen an komplexe und verteilte Projekte ergeben. Zudem werden die Bereiche
der Führung, Kommunikation und Selbstorganisation zu wenig unterstützt. Moderne Methoden
setzen genau bei diesen Punkten an (Chen u. a., 2002):
• Sie unterstützen die effektive und effiziente Kommunikation. Sie helfen, Missverständ-
nisse zu vermeiden und geben allen Projektmitgliedern einen umfassenden Überblick.
Hilfswerkzeuge in elektronischer Form unterstützen dabei die Kommunikation in alle
Richtungen und die Speicherung von Wissen.
• Sie managen nicht nur Input und Output, sondern auch Prozesse im Bereich der Füh-
rung und der Produktentwicklung.
• Sie unterbinden ein reaktives Management und fokussieren auf eine ganzheitliche und
stetige Planung, auch in Stresssituationen. Sie reduzieren dadurch den Aufwand für die
Überarbeitung von Lieferobjekten und die Fehlerbehandlung, welche durch eine unvoll-
ständige Planung entstehen.
78
4. Anforderung an eine moderne
PM-Plattform
Obwohl es oftmals versucht wird, ist es nicht möglich, eine allgemeingültige Lösung für das
richtige Projektmanagement zu erstellen. So unterschiedlich Projekte sind, so variieren auch
die Anforderungen an jedes einzelne Projekt und die Methoden und Hilfsmittel, welche für die
Projektführung und -durchführung angewendet werden sollten. Zudem wird die Eigendynamik
eines Projektes stark von der Motivation, den Interessen und Vorkenntnissen der Projektmit-
glieder beeinflusst.
Das Ziel einer guten Projektmanagement-Plattform liegt also nicht darin, die einzig richtige
Lösung abzubilden, sondern eine Vielzahl von Funktionen und dynamische Prozesse bereit-
zustellen, um den meisten Anforderungen gerecht zu werden. Bei der Initialisierung und der
ersten Planung und Etablierung des Projektes können daraufhin die benötigten Werkzeuge
eingerichtet und verbreitet werden.
Die spezifischen funktionalen Anforderungen an die Plattform lassen sich in drei Bereiche
unterteilen:
- Kommunikation
- Projektmanagement (klassisch)
- Informations- und Datenmanagement
Für jeden Bereich wird eine empfohlene Mindestanforderung an die Plattform gestellt.
Nebst den funktionalen Anforderungen kommen Randbedingungen hinzu, welche eine Platt-
form erfüllen muss, um richtig eingesetzt werden zu können. Diese können von Organisation
zu Organisation aufgrund der firmeninternen Richtlinien stark variieren. Zu Beginn dieses Ka-
pitels werden mögliche Randbedingungen für Klein- und Mittelunternehmen aufgelistet und
begründet.
79
4. Anforderung an eine moderne PM-Plattform
4.1. Randbedingungen
Klein- und Mittelunternehmen werden durch ihre Grösse, der Anzahl Mitarbeiter und des Jah-
resumsatzes klassifiziert. Typische Projekte in einem KMU sind im mittleren Bereich der Wich-
tigkeit, B bis C angesiedelt. Nur wenige Projekte mit hoher Komplexität und hohem Risiko
können von einem Kleinunternehmen gleichzeitig durchgeführt werden, um einem Klumpen-
risiko zu entgehen. Nach Applegate fallen sie in die Kategorie der strategischen, high poten-
tial oder kritisch operativen Projekte. Unterstützende Projekte werden erst mit zunehmender
Grösse eines Unternehmens wichtig. Untersucht man die Projekttypen, so werden meist Auf-
tragsprojekte durchgeführt, in welchen im Auftrag eines externen Kunden ein Softwareprodukt
hergestellt wird.
In Anbetracht dieser Projekttypen und der Aufgabenstellung stellen sich an das Grundmodul
einer modernen Plattform die in diesem Abschnitt gelisteten Randbedingungen.
Open Source bedeutet unter anderem, dass der Quellcode einer Software frei zur Verfügung
steht. Ebenso sind in einer Open Source-Lizenz auch die Vermarktung und Verbreitung gere-
gelt. Die häufigste Lizenz ist die „GNU GPL“1 (GNU General Public Licence). Sie legt den kom-
pletten Quellcode offen und verlangt, dass adaptierte Versionen wiederum unter dieser Lizenz
veröffentlicht werden müssen. Es gibt daher keine kommerzielle Verwertung dieser Software.
Die schwächste aller Open Source-Lizenzen ist die „BSD“2 -Lizenz (Berkeley Software Distri-
bution). Sie macht keinerlei Vorschriften darüber, wie modifizierte Software weiterverwendet
werden kann. Sie kann somit kommerziell vertrieben werden und schreibt keine Offenlegung
des modifizierten Quellcodes vor.
Die wichtigsten Vorteile für ein KMU sind folgende (Spath u. a., 2007):
Wirtschaftlichkeit: Keine Kosten bei der Beschaffung sowie keine Folgekosten, zum Beispiel
für Updates. Durch den offenen Quellcode erhält man zusätzlich auch das Know-How
über die Entwicklung.
80
4.1. Randbedingungen
4.1.2. Erweiterbar
Erweiterbarkeit ist keine logische Implikation eines Open Source-Produktes. Zwar ist der Quell-
code offen und es bestehen somit offene Schnittstellen respektive diese können programmiert
werden, dennoch ist die Erweiterbarkeit von der Architektur des Produktes abhängig. Optimal
ist einer modulartiger Aufbau der Basisversion. Das Kernsystem soll eine allgemeine Basis für
die darauf aufbauenden Produkte bereitstellen.
Aufbauend auf der Technologie des Grundystems sollen zudem bereits frei verfügbare Produk-
te auf dem Markt sein, die für ein Projektmanagementsystem verwendet werden können. Für
ein KMU ist es nicht sinnvoll, mit dem Einrichten eines solchen Systems eine ganze Abteilung
über Monate hinweg zu beschäftigen. Wird die Erweiterung und Anpassung zu arbeitsintensiv,
läuft man Gefahr, diese aufgrund fehlender Zeit und Ressourcen nicht durchführen zu können.
Die Verwendung eines Systems, welches sich nicht optimal in den Arbeitsprozess integrieren
lässt, bringt keine Vorteile und ist in einem Projekt nicht sinnvoll.
81
4. Anforderung an eine moderne PM-Plattform
4.1.3. Vernetzt
Für eine flexible Zusammenarbeit, auch über Unternehmensgrenzen hinweg, eignet sich eine
vernetzte Software. Die einfachste Möglichkeit ist eine webbasierte Applikation, auf welche
von überall her zugegriffen werden kann. Eine weitere Möglichkeit ist eine Synchronisations-
Software, welche die Daten bei einer bestehenden Internetverbindung abgleicht. Der Unter-
schied besteht darin, wo die Daten liegen und wann darauf zugegriffen werden kann.
Auf Daten einer webbasierten Applikation kann nur bei bestehender Internetverbindung zuge-
griffen werden. Die Daten werden innerhalb der Applikation, meist in einer Datenbank, gespei-
chert. Besteht keine aktive Internetverbindung, so gibt es keine Möglichkeit, auf Informatio-
nen zuzugreifen. Einen Schritt weiter gehen sogenannte verteilte Applikationen, welche eine
„Working Copy“ der gesamten Infrastruktur lokal speichern. Bei bestehender Internetverbin-
dung werden die lokalen Daten mit einem Repository oder den Working Copies der übrigen
Benutzer abgeglichen und die lokalen Informationen aktualisiert. Dieses Vorgehen ist oft bei
der Produktentwicklung anzutreffen, um geschriebenen Code erst dann allen zur Verfügung zu
stellen, wenn dieser abnahmebereit ist. Für das Projektmanagement sind beide Infrastrukturen
geeignet, im Zusammenhang mit Open Source-Produkten trifft man die webbasierte Version
öfters an.
4.1.4. Mehrsprachig
Obwohl sich in der Informatik die Sprach Englisch durchgesetzt hat, soll die Plattform in Hin-
blick auf die verteilte Benutzung eine optimale Unterstützung für Mehrsprachigkeit bereitstel-
len, so dass jeder Benutzer die angezeigte Sprache selbst wählen kann. Vorwiegend in der
Zusammenarbeit mit externen Kunden (zum Beispiel Änderungsmanagement), soll dieser die
freie Wahl haben, gewisse Elemente der Seite in seiner eigenen Sprache zu bearbeiten.
Die Mehrsprachigkeit macht in einigen Bereichen keinen Sinn, zum Beispiel im Auftragsmana-
gement. Für eine gute Zusammenarbeit wird bereits in der Initialisierungs- und Etablierungs-
phase eine gemeinsame Sprache festgelegt. Werden wichtige Elemente auf einer Plattform
übersetzt, so ist diese Grundlage nicht mehr gegeben. Diese sollen somit nur in einer Spra-
che zur Verfügung stehen. Als Beispiel seien hier Begriffe aus der Produktentwicklung (Story,
Task) und dem Projektmanagement (Artefakte) genannt.
82
4.2. Kommunikation und Zusammenarbeit
Kommunikation bestimmt zu einen grossen Anteil auch die Art der Zusammenarbeit der be-
teiligten Projektmitglieder. Der Austausch von Informationen und Wissen und die Zusammen-
arbeit gilt als wichtiger sozialer Erfolgsfaktor in einem Projekt und muss bei der Verwendung
einer Projektmanagementplattform in geeigneter Form unterstützt werden.
4.2.1. E-Mail
• eine E-Mail an ein oder mehrere Mitglieder des Projektes oder Gruppen zu versenden
• der E-Mail Medien anzuhängen (Dokumente, Bilder) resp. den Link auf ein Medium ver-
senden3
4.2.2. Kontaktmanagement
Alle Projektmitglieder erhalten über einen Benutzernamen und ein Passwort Zugang zur Platt-
form, wodurch Zugriffsberechtigungen geregelt werden. Eine vollständige Liste aller Benutzer
kann somit auch als Kontaktverwaltung ausgelegt werden und als Grundlage für alle Kontakt-
informationen dienen. Des weiteren sind in einem Projekt Personen beteiligt, welche keinen
3
Aufgrund der Redundanz ist es sinnvoller, Medien selbst nicht zu versenden, sondern nur darauf zu verlinken
83
4. Anforderung an eine moderne PM-Plattform
Zugriff auf die Plattform benötigen und daher nicht zwingend in über die Benutzerverwaltung
organisiert sein müssen. Für diese Fälle ist eine vom Grundsystem unabhängige Kontaktver-
altung sinnvoll
4.2.3. Bookmarks/Portal
Ein Portal bietet die Möglichkeit, eine individualisierte Einstiegsseite der Plattform zu defi-
nieren. Darauf können Bookmarks (Schnellzugriffe) abgelegt, Aufgaben angezeigt und News
publiziert werden.
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.
84
4.2. Kommunikation und Zusammenarbeit
• Moderatoren für einzelne Bereiche zu ernennen, welche Beiträge editieren und löschen
sowie Themen schliessen können
4.2.5. Mailinglisten
Mailinglisten fassen die E-Mail-Adressen mehrerer Personen zusammen und ermöglich so das
schnelle und einfache Versenden an mehrere Empfänger. Die Kennzeichnung einer Mailing-
liste wird durch eine Adresse im normalen E-Mail-Format repräsentiert. Bei der Antwort an
diese Adresse wird der Verlauf gespeichert und kann danach baumartig dargestellt werden.
Die Kommunikation läuft im Gegensatz zu einem Newsletter bei einer Mailingliste bidirektional
ab.
Mit einer Messaging-Funktion können zwei oder mehr Nutzer in Echtzeit schriftlich miteinan-
der kommunizieren. Das Chatten ist ein beliebtes und verbreitetes Kommunikationshilfsmittel
und bietet oftmals zur schriftlichen Kommunikation auch Sprach- und Videoübertragung und
die Möglichkeit des Datenaustauschs. Im Gegensatz zum Forum müssen die Benutzer beim
Chatten gleichzeitig online sein.
• bestehende Chat-Clients (z.B. Skype) zu integrieren, resp. den Status eines anderen
Mitglieds zu sehen
85
4. Anforderung an eine moderne PM-Plattform
4.2.7. Nachrichtenboard
Ein Nachrichtenboard auf einer Plattform entspricht einer Pinwand oder einem Whiteboard,
auf welchem Nachrichten hinterlegt werden können, die für alle Mitglieder wichtig sind. Da
es sich hierbei im eine einseitige Kommunikationsart handelt, entlastet das Nachrichtenboard
den meist eh bereits hohen Mailverkehr.
• Nachrichten einem bestimmten Projekt zuzuweisen oder als global gültig zu definieren
4.2.8. Umfragen
• die Anzeige einer Umfrage personen- oder gruppenspezifisch sowie zeitlich einzuschrän-
ken
86
4.3. Informations- und Datenmanagement
4.3.1. Dokumentemanagement
Als Dokumentemanagement wird jegliches Handling von Artefakten verstanden. Sie ermögli-
chen nebst dem Speichern und Bearbeiten von Dokumenten auch die Verwaltung von Zugriffs-
berechtigungen. Je nach Format können die Dokumente direkt auf der Plattform bearbeitet
werden, meist jedoch ist dafür ein externes Programm nötig.
4.3.2. Versionierung
Durch die Versionierung von Informationen können Änderungen nachverfolgt und wieder rück-
gängig gemacht werden. Eine Versionshistory sollte automatisch erstellt werden und die Mög-
lichkeit bereitstellen, eine neuere Version zu kommentieren und somit die Änderungen nach-
vollziehbarer zu machen.
4.3.3. Strukturierung
Für die strukurierte Ablage von Dokumenten soll die Möglichkeit zur Erzeugung einer Ordner-
struktur vorhanden sein. In einem weiteren Schritt ist es denkbar, die Ordnerstruktur anhand
der Klassifizierung eines Projektes automatisch zu erzeugen (vgl. Tabelle 3.2).
Wissen ist in der heutigen Informationstechnologie ein wichtiges Gut. Mit jedem Mitarbeiter-
wechsel, mit jedem Projektabschluss und an jeder System- und Phasengrenze geht Wissen
verloren, wenn es nicht in geeigneter Form festgehalten wird. Während die Sammlung des
Wissens bei jedem drohenden Verlust in Aktion treten soll, ist das Wiederauffinden der zweite
Faktor. Schon mehrmals habe ich es erlebt, dass Wissen mithilfe von Spam-ähnlichen Mails
87
4. Anforderung an eine moderne PM-Plattform
an alle Mitarbeiter eines Unternehmens versendet wurden mit der Hoffnung, jemanden zu fin-
den, der vielleicht in einem bestimmten Gebiet bereits Erfahrungen sammeln konnte. Daraus
ergeben sich zwei Aspekte. Zum einen soll es möglich sein, mithilfe einer Wissensdatenbank
Informationen zu finden, zum anderen sollen auch Personen, welche über ein bestimmtes
Wissen verfügen, ausfindig gemacht werden können. Letzteres kann über ein Kontaktmana-
gementsystem erfolgen, in welchem Mitarbeiter ihr Erfahrungsgebiete eintragen können. Für
Informationen selbst eignet sich ein Wiki.
Als Wiki wird ein interaktives Nachschlagewerk bezeichnet, in welchem jedes Projektmitglied
neue Seiten erfassen und somit Informationen zur Verfügung stellen kann. Alle Seiten werden
als Hypertext-Dokumente abgelegt und untereinander verlinkt.
• Medien in die Artikel zu integrieren (Bilder, Videos, Dokumente beliebigen Formats) und
Verlinkungen zu erstellen
4.4. Projektmanagement
Im Bereich des Projektmanagements soll die Plattform das Management der ökonomischen
Projektziele Leistung, Kosten und Termine sowie Inhalte, Ressoucen und Änderungen über-
wachen sowie die Prozessabläufe begleiten. Dabei muss die Plattform flexibel genug sein, um
nicht nur eine Managementtheorie zu unterstützen, sondern klassische wie auch agile Metho-
den bereitstellen können. Das System greift dabei auf die Funktionalitäten der Kommunikation
und des Informations- und Datenmanagements zu. Der grosse Vorteil eines Systems ist die
automatische Erkennung definierter kritischer Zusammenhänge und Abhängigkeiten.
Ein wichtiger Bereich im Projektmanagement sind die Prozessabläufe, die sogenannten Work-
flows. Sie unterstützen den Ablauf in einem Projekt und garantieren einen Mindeststandard,
der eingehalten werden muss. Zudem vereinfachen sie das Handling und erlauben es, in der
Projektleitung Zeit für die Erledigung wiederkehrender Aufgaben einzusparen.
Während die firmenspezifischen Regeln meist über längere Zeit gleich bleiben, verändern sich
die projektspezifischen Abläufe oftmals bereits innerhalb eines Projektes. Die Änderungen rüh-
ren von inneren wie auch äusseren Einflüssen her. Jeder Projektleiter, jedes Teammitglied und
88
4.4. Projektmanagement
jeder Kunde hat andere Vorlieben und für die Benutzung einer Projektmanagement-Plattform
mit vordefinierten Abläufen sensibilisiert werden. Ich selber habe bereits die Erfahrung ge-
macht, dass Kunden die Unterstützung einer Plattform nicht schätzen und lieber nur mit E-
Mails arbeiten möchten. Somit ist es grundlegend, dass die Plattform an verschiedene Bedürf-
nisse angepasst werden kann, benutzerfreundlich ist und einen entscheideneden Mehrwert
liefern soll. Teammitgliedern, welche sich nicht an die vorgegebene Managementmethode hal-
ten möchten, sind oftmals besser aus dem Team auszuschliessen, sofern keine Besserung in
Sicht ist (Beck, 2005).
4.4.1. Termine
Ein Kalender dient dazu, projektbezogene Termine festzuhalten und zu verbreiten. Nebst Mee-
tings können auch weitere Termine wie Releases und Meilensteintermine integriert werden.
Im Bereich des Projektmanagement lege ich den Fokus auf den Management- und den Ent-
wicklungsprozess. Die elektronisch unterstützbaren Aspekte der Führung werden subsumiert,
da in der Managementtheorie und der Kommunikation bereits ein Grossteil der Führung fest-
gelegt wird.
Betrachten wir die klassischen Managementmethoden nach Jenny (vgl. 3.2) und Specker (vgl.
3.3), so fällt auf, dass diese Methoden durch eine Vielzahl von Meetings und Dokumenten be-
stimmt wird, welche in einer festgelegten Reihenfolge oder bei bestimmten Ereignissen erstellt
werden. Wo reine Informationsinhalte erstellt werden, z.B. Business Case, und Projektantrag,
ist eine elektronische Unterstützung nur für die Verteilung der Information sinnvoll, jedoch
nicht für deren Erstellung. Für jedes einzelne Dokument ist demnach zu entscheiden, ob es
als Content auf der Plattform oder mit einem externen Programm erstellt wird und danach im
Dokumentesystem abgelegt wird. Wichtige Entscheidungshilfen sind folgende:
89
4. Anforderung an eine moderne PM-Plattform
• Ist eine verbindliche Vorlage vorhanden (z.B. Excel- oder Word-Template), welche auf-
grund firmeninterner Richtlinien verwendet werden sollte?
• ...
Je mehr dieser Fragen mit „Ja“ beantwortet werden, desto eher sollte ein Dokument mit einer
externen Applikation erstellt und im Dokumentesystem abgelegt werden. Für deren Verbrei-
tung kann danach das Projektmanagementsystem verwendet werden. Ebenfalls wird über die
Rechteverwaltung der Zugriff eingeschränkt.
Da agile Mehoden ein höheres Mass an Zusammenarbeit der einzelnen Teammitglieder und
verteilte Verantwortung vorschreiben, ist hier eine vollständige Integration einiger Bereiche in
das System sinnvoll und schafft einen echten Mehrwert für Kunden und Entwickler. Zudem wird
der Projektleiter entlastet, da viele administrative Aufgaben automatisiert ausgeführt werden.
Für eine genaue Analyse der Anforderung mit Scrum wird auf Mengelt (2008) verwiesen.
4.4.3. Ressourcenmanagement
Die Verwaltung von Personen wird optimalerweise im Zusammenhang mit dem Kontaktmana-
gement erstellt, um redundante Daten zu vermeiden. Durch die Zuweisung einzelner Personen
zu bestimmten Gruppen werden gleichzeitig auch die Berechtigungen für die Ressourcenver-
waltung festgelegt.
Die Verwaltung von Sachmittel und Räumen ist meist nicht nur auf ein Projekt beschränkt,
sondern betrifft alle Projekte und Arbeitsgebiete in einem Unternehmen. Hier kann ein Raum
für ein Projektmeeting genauso wie für eine Geschäftsleitungssitzung gebucht werden. Daher
ist es dem Unternehmen überlassen, diese Verwaltung in die Projektmanagement-Software
zu integrieren oder selbstständig zu führen.
90
4.4. Projektmanagement
4.4.4. Aufgabenmanagement
Für klassische wie auch agile Methoden ergibt sich eine eindeutige Struktur. Ein gesamtes
Projekt wird in Teilaufgaben unterteilt, welche wiederum mehrere Arbeitspakete enthalten. Ein
Arbeitspaket ist die kleinste Einheit und stellt eine Aufgabe dar, welche nicht mehr weiter zer-
legt werden kann. Es muss zudem zuverlässig schätzbar sein und in sich abgeschlossen.
• eine automatische Benachrichtigung zu erhalten, wenn ein Task nicht in der vorgegebe-
nen Zeit abgearbeitet wird
Die Möglichkeit, Stunden auf einen bestimmten Task zu buchen, macht ein eigenes Time
Tracker-System überflüssig. Es kann dennoch sinnvoll sein, der Übersicht halber einen eige-
nen Time Tracker-Bereich zu erstellen, wo alle Stunden zusammengetragen werden.
91
4. Anforderung an eine moderne PM-Plattform
92
5. Tool-Evaluation
Die Liste verfügbarer Managementplattformen auf dem Markt ist sehr lang. Viele dieser Platt-
formen fokussieren auf die Dokumente- und Aufgabenmanagement und weisen zum aktuellen
Zeitpunkt einen erfolgsversprechenden Stand der Entwicklungen auf. Dieses Kapitel soll Auf-
schluss darüber bringen, inwiefern sie die Prozessdifferenzierung unterstützen. Der Fokus der
meisten Produkte auf den klassischen Managementprozess schränkt die individuelle Anpas-
sung und die Zusammenarbeit ein. Bereiche wie Kommunikation, Abbildung von Arbeitspro-
zessen und die Integration der Produktentwicklung stehen im Zentrum der Untersuchung.
5.1. Toolauswahl
Eine Kollaborationsplattform unterstützt die Organisation bei der Kommunikation, Koordination
und Kooperation innerhalb eines Projektes. Tabelle 5.1 listet die 17 untersuchten OpenSource-
Kollaborationsplattformen sowie die dafür benötigte IT-Infrastruktur und die Lizenz. Die mei-
sten dieser Plattformen unterstützen ebenfalls grundlegende Funktionen für das Projektmana-
gement.
93
5. Tool-Evaluation
94
5.1. Toolauswahl
Abbildung 5.1 stellt in einem Balkendiagramm alle 17 Tools der Studie mit den erhaltenen
Punkten in den Kategorien Kommunikation, Projektmanagement und Informations- und Doku-
mentemanagement dar. In den folgenden drei Kapitel werden die drei Kategorien für die Top5
Systeme und Plone genauer untersucht.
Das Kivit-Diagramm in Abbildung 5.2 stellt auf übersichtliche Weise die sechs untersuchten
Tools und ihre Dimensionen dar. Alle Tools aus den Top5 erlangen bei der Untersuchung in
allen Kategorien mindestens 6 von 10 möglichen Punkten und weisen somit in allen Bereichen
eine überdurchschnittlichen Funktionsumfang auf. Obwohl „Plone“ im Bereich der Kommunika-
tion und des Projektmanagements nur je 4 Punkte erhält, ist es das einzige Produkt, welches
im Informations- und Dokumentemanagenent die volle Punktzahl erhält.
95
5. Tool-Evaluation
96
5.1. Toolauswahl
Abbildung 5.2.: Kiviatdiagramm der Top5 Tools und Plone nach Spath u. a. (2007)
5.1.1. PHProject
Open Xchange gehört zu einer sehr verbreiteten Projektmanagementplattform und ist als freie
wie auch kommerzielle Version verfügbar. In der freien Version fehlt die webbasierte Admi-
nistration und Programme und Schnittstellen von Drittanbietern. Ebenso sind einige Erwei-
terungen kostenpflichtig, zum Beispiel die Integration von Microsoft Outlook über sogenannte
Konnektoren. Durch die kommerzielle Version ist die Weiterentwicklung grösstenteils gesichert
und über eine Roadmap einsehbar.
97
5. Tool-Evaluation
5.1.3. eGroupWare
5.1.5. IGSuite
5.1.6. Plone
5.2.1. PHProject
Open Xchange verfügt über ein funktional ausgereiftes Kontaktmanagement-Tool, mit wel-
chem Dateien einem Kontakt zugewiesen und Termine, Aufgaben und Projekte direkt ver-
knüpft werden können. Der Zugang zu den Kontaktdetails wird über Berechtigungen geregelt.
Die Integration von Microsoft Outlook ist gewährleistet und bietet mit der Darstellung als Text-
nachricht eine hohe Sicherheit. Eine zentrale Bookmarkverwaltung, Diskussionsforum und ein
Nachrichtenboard sind ebenfalls vorhanden.
98
5.2. Kommunikation und Zusammenarbeit
99
5. Tool-Evaluation
5.2.3. eGroupWare
5.2.5. IGSuite
5.2.6. Plone
5.3.1. PHProject
5.3.3. eGroupWare
5.3.5. IGSuite
5.3.6. Plone
5.4. Projektmanagement
5.4.1. PHProject
5.4.3. eGroupWare
5.4.5. IGSuite
5.4.6. Plone
Groove ist ein neues Produkt in der Office-Reihe, welches in den Office-Produkten Ultima-
te 2007 und Enterprise 2007 enthalten ist. Die Groove-Technologie macht es möglich dass
5.5. Microsoft Produkte und Alternativen
die einzelnen Client-Rechner untereinander kommunizieren, und über eine sichere Internet-
Verbindung Daten austauschen können1 . Nebst dem Stammbereich können weitere Tools in-
tegriert und auf das einzelne Projekt zugeschnitten werden. Groove steht auch als Server-
Version für den Einsatz innerhalb eines Unternehmens bereit und kann vollständig und mit
verhältnismässig wenig Aufwand in eine Microsoft-Server-Umgebung integriert werden und ist
für die Zusammenarbeit mit Microsoft SharePoint vorbereitet.
Groove deckt in der Office-Version standardmässig viele gängige Funktionalitäten ab. Weitere
können selbst mit dem Formulareditor hinzugefügt werden, welcher Javascript, VBScript und
Makros unterstützt.
Rollen
Der Projektleiter startet einen Arbeitsbereich und lädt hierzu weitere Teilnehmer ein. Diese
erhalten im Teambereich folgende Berechtigungen zugewiesen: weitere Teilnehmer ein- und
ausladen, Tools hinzufügen und löschen sowie ausstehende Einladungen abbrechen. Vorde-
finiert sind die drei Rollen Manager, Teilnehmer und Gast. In der Office-Version können keine
weiteren Abstufungen erstellt werden, jedoch können die Berechtigungen dieser drei Rollen
selbst gesetzt werden.
Dokumente
Im Bereich Dateien werden Projektspezifische Dateien verwaltet. Das Hinzufügen von neuen
Datein geschieht über das Dateibrowsing und legt die Dateien im Workspace ab. Die Doku-
mente werden über die Groove-Oberfläche gestartet, nach dem Beenden automatisch wieder
im Workspace abgelegt und eingeckeckt, sobald eine Internetverbindung besteht. Die Verfüg-
barkeit aller Dateien ist somit auch im Offline-Betrieb gewährleistet. Die Struktur wird dabei
wie gewohnt über Ordner organisiert.
1
(Office2007 Blog, 2008)
101
5. Tool-Evaluation
Für die Verwaltung von Bildern steht eine eigene Oberfläche zur Verfügung, welche eine Vor-
schau sowie die Verlinkung von Bildern, zum Beispiel zur Integration in eine Besprechungs-
Einladung, ermöglicht. Für das schnelle Aufnehmen von Informationen steht eine Notiz- und
Skizzenfunktion zur Verfügung.
Über den Rollenmanager können die Berechtigungen zum Hinzufügen, Ändern und Löschen
von Dateien und Ordnern gesetzt werden. Ebenso besteht die Möglichkeit, diese Berechtigun-
gen nur für eigene erstellte Dateien zu gewähren.
Termine
Für die Terminverwaltung steht in Groove ein Gruppen-Kalender zur Verfügung. Gemeinsame
Termine können eingetragen werden und verteilen sich automatisch an alle weiteren Mitglie-
der. Wünscht man mehr Funktionalitäten, so steht ein Besprechungs-Tool zur Verfügung. Ein
Besprechungs-Eintrag kann hier an mehrere Mitglieder zugewiesen werden (und nur diese se-
hen den Eintrag dann auch), es können Anhänge mitgeben, Traktanden erfasst und Protokolle
abgelegt werden. Im Beschreibungstext können hier auch Links zu Bildern, Kalendereinträgen
und Dokumenten erstellt werden.
Kommunikation
Integriert ist das Versenden von Nachrichten an die Projektmitglieder sowie eine Chat-Funktion,
zu welcher alle aktiven Mitglieder Zugang haben. Der Chat verfügt nebst dem Textmodus auch
über einen Zeichnungsmodus.
Aufgaben
Micorosoft stellt online eine Reihe von vordefinierten Formularen bereit, welche in Groove
importiert werden können. Darunter ist auch ein Issue & Task Tracker verfügbar, mit welchem
102
5.5. Microsoft Produkte und Alternativen
offene Aufgaben und Tasks nachverfolgt werden können, welche über ein Start- und Enddatum
verfügen und einem Owner zugewiesen werden.
Kosten
Über den Time Tracker können die aufgewendeten Stunden und somit die Kosten überwacht
werden. Projekte können in Phasen zerlegt werden und einzelne Aktivitäten zur Bearbeitung
an andere Teammitglieder delegiert werden, welche danach ihre Arbeitszeiten auf diesen Ak-
tivitäten erfassen können.
Ressourcen
Microsoft stellt einen Asset Tracker zur Verfügung, mit welchem materielle Ressourcen ver-
waltet und auch verrechnet werden können.
Änderungen
Über den Proposal Tracker können Änderungen und Wünsche eingereicht werden, denen
danach Tasks und Personen zugewiesen werden können. Ebenfalls steht ein Problemver-
folgungsbereich standardmässig zur Verfügung, welcher individuell angepasst und erweitert
werden kann.
Berichte
Mit Project Status Reports kann der Projektstand überwacht werden. Die einzelnen Status Re-
ports können einer Kategorie zugewiesen und von den Projektmitgliedern kommentiert wer-
den.
103
5. Tool-Evaluation
Sicherheit
Alle Arbeitsbereiche werden in einer verschlüsselten Datei auf der Festplatte gespeichert, auf
die der Zugriff nur mit dem dazugehörigen Konto und über Groove möglich ist. Für die Syn-
chronisation werden die Dateien ebenfalls verschlüsselt.
5.5.2.2. Alternative zu SP
5.5.3. Projektmanagement
2
www.openworkbench.org
104
5.6. Produktentwicklung
5.6. Produktentwicklung
File Sharing-Tools unterstützen den Benutzer bei der Verteilung und Nutzung von gemein-
samen Daten. Sie können zusätzlich zu einer Projektmanagement-Software und als Backup-
Funktion genutzt werden. Alle der drei vorgestellten Tools befinden sich noch im Beta-Stadium,
können jedoch bereits aktiv genutzt werden.
Alle Tools laufen im Hintergrund und synchronisieren die verteilten Ordner bei bestehender
Internetverbindung. Nebst dem lokalen Ordner befindet sich der komplette Inhalt auch auf
dem Repository. Eine kommerzielle Nutzung ist auch nach der Beta-Phase vorgesehen, es
bleibt abzuwarten, ob die Dienste dann weiterhin kostenlos zur Verfügung stehen.
105
5. Tool-Evaluation
5.7.1. Dropbox
Dropbox3 ist eine frei verfügbare Software im Private Beta-Stadium für die verteilte Nutzung
von Dateien. Die Installationsdatei für Windows oder Mac ist ca. 7MB gross. Nach der Instal-
lation werden alle Dateien im Ordner <EIGENE_DATEIEN>/My Dropbox synchronisiert.
Ein bestehender Ordner kann über das Webinterface mit weiteren Benutzern geteilt werden.
Hierfür kann die Einladung an eine beliebige Mail-Adresse versendet werden.
Ein grosser Vorteil von Dropbox ist die History und Versionierung. Während lokal die aktuell-
sten Versionen der Dateien gespeichert werden, können über das Webinterface auch ältere
Dateiversionen heruntergeladen werden. Dropbox fungiert hier als Online-Repository. Die Ver-
sionierungsfunktion ist einer der Stärken von Dropbox und beschleunigt das Abgleichen der
Dateien, da nur die Dateiveränderung hochgeladen werden muss. Über die History können
die neusten Veränderungen schnell nachverfolgt werden.
Im Internet Explorer wird der aktuelle Status der Dateien angezeigt, wobei zwei weisse Pfeile
auf blauem Hintergrund bedeuten, dass der Ordner oder die Datei sich noch in der Synchro-
nisation befindet.
3
www.getdropbox.com
106
5.7. File Sharing
107
5. Tool-Evaluation
5.7.2. Syncplicity
Syncplicity4 liegt aktuell im Beta-Stadium vor. Für die Installation der 2.2MB grossen Datei wird
das .NET Framework 3.0 benötigt. Lokale Ordner können bei Syncplicity über das Kontextme-
nü oder den integrierten File Browser registriert werden. Bei der Einladung weiterer Benutzer
können für die Ordner Lese- und/oder Schreibrechten gesetzt werden. Die lokale Installation
bietet einen eigenen File Browser für die Verwaltung aller freigegebenen Dateien.
Obwohl die aktuelle Version bereits stabil läuft, sind viele der verfügbaren Funktionen noch
schwer zu gebrauchen. Beispielsweise kann der lokale File Browser nur genutzt werden, wenn
eine Verbindung zum Server besteht. Ohne verfügbare Internetverbindung ist es somit nicht
möglich, Administrationsaufgaben auszuführen.
Im Beta-Stadium ist der Datentransfer und der verfügbare Speicherplatz unbeschränkt. Da-
nach wird er auf 2GB und 2 Computer limitiert. Syncplicity stellt auch ein Modell für die kom-
merzielle Nutzung zur Verfügung. Hierbei können für 99$ pro Jahr total 40GB Datenspeicher
und unlimitierte Computer konfiguriert werden. Mit zusätzlichem Versand von Einladungen an
4
www.syncplicity.com
108
5.7. File Sharing
Freunde können pro Annahme weitere 250MB freigeschaltet werden, dies bis zu 10GB zu-
sätzlich.
Wie auch bei Dropbox werden die in der Synchronistaion eingeschlossenen Ordner durch ein
Symbol markiert (siehe Abbildung 5.13). Die abgeglichen Dateien erhalten durch einen grünen
Haken eine entsprechende Kennzeichnung (siehe Abbildung 5.14). Die Kennzeichnung ist nur
im Online-Modus verfügbar.
Hervorzuheben ist die gute Navigation durch einen intuitiven Browser im Webinterface. Der
lokale und der Online File-Browser sind die Stärken von Syncplicity. Ebenso ist Online eine
Versionierung aller Dateien abzurufen, um Zugriff auf ältere Dateien zu erhalten (siehe Abbil-
dung 5.15). Dem gegenüber lässt das Benutzermanagement in der aktuellen Version noch zu
wünschen übrig.
Als einziges untersuchtes Tool bietet Syncplicity eine Schnittstelle zu Produkten von Drittan-
bietern. Darunter hervorzuheben sind GoogleDocs, Scribd, Zoho und picnik.
Über GoogleDocs können Dokumente aus dem Repository von GoogleDocs durch hinterle-
gen der Anmeldedaten im Webinterface hinzugefügt werden. Die Dateien werden danach in
das File Repository von Syncplicity hinzugefügt.
Für die Ansicht und Bearbeitung von Dateien stehen Scribd, Zoho und picnik zur Verfügung.
Über das Kontextmenü können alle synchronisierten Dateien betrachtet (Scribd) sowie Doku-
mente editiert (Zoho) und Bilder bearbeitet (picnik) werden. Danach werden die Dateien wieder
zurück ins Repository von Syncplicity gespeichert und bei der nächsten Synchronisation lokal
heruntergeladen.
109
5. Tool-Evaluation
FolderShare5 ist nicht nur eine Synchronisationssoftware, sondern vereinfach den Zugriff auf
verteilte Daten und bietet zusätzlich Remote-Verbindungen. Benötigt man ein Dokument, wel-
ches auf einem anderen Rechner liegt, so kann man mit FolderShare jederzeit darauf zugrei-
fen. Somit kann man zum Beispiel ein gespiegeltes Abbild wichtiger Dateien auf mehreren
Computern erzeugen. Die Synchronisierung erfolgt hierbei automatisch oder auf Anfrage, so-
bald die Datei benötigt wird.
110
5.7. File Sharing
Dateien werden online auf dem Server von FolderShare gespeichert. Kostenlos stehen 2GB
Datenplatz zur Verfügung. Hat man einen persönlichen Ordner eingerichtet, so kann man
diesen mit weiteren Benutzern teilen. Hierfür wird eine Einladung an die betreffende LiveID
versendet. FolderShare bietet sogar ein Benutzerberechtigungssystem mit folgenden Berech-
tigungen:
Leser können Dateien in der Bibliothek anzeigen, jedoch keine Dateien hinzufügen oder än-
dern.
Mitwirkende können Dateien anzeigen und hinzufügen, jedoch nicht ändern oder löschen.
Editoren können Dateien in dieser Bibliothek anzeigen, ändern, löschen und zu ihr hinzufü-
gen.
Verwalter haben die gleichen Möglichkeiten wie Editoren und können außerdem Bibliotheks-
berechtigungen ändern.
FolderShare kann auch als Remoteverbindungs-Tool verwendet werden, um von jedem mit
dem Internet verbundenen Computer auf alle eigenen Dateien zugreifen zu können.
Für die Benützung von Windows Live FolderShare wird eine Windows LiveID benötigt. Nach
der Installation der Software (Grösse ca. 1MB) unter Windows oder Mac, können persönliche
Bibiliotheken erstellt werden. Eine Bibliothek entspricht einem lokalen Ordnern sowie allen
darin enthaltenen Unterordner und Dateien. Werden weitere Benutzer dazu eingeladen, so
können diese den Inhalt des freigegebenen Ordners lokal an einem beliebige Ort hinzufügen.
FolderShare steht in verschiedenen Sprachen zur Verfügung, darunter auch als deutsche Ver-
sion.
111
5. Tool-Evaluation
112
6. Software Plattform
Warum Plone? Wie ist Plone aufgebaut? Was ist Zope, was ist Phyton? Was sind die Ei-
genheiten davon? Wie ist die Grundplattform/Core aufgebaut? Welche Funktionen sind in der
Grundinstallation enthalten? Welche Erweiterungen sind erhältlich? Welche davon kann ich
benutzen? Wie werde ich welche Erweiterung zur Abdeckung welcher Anforderung verwen-
den?
Die wichtigsten Gründe für die Benutzung von Python sind Qualität, Produktivität, Portabilität
und Integration.(Lutz, 2006)
113
6. Software Plattform
Software Qualität: Pythons klare Syntax und das kohärente Design bringt Programmierer
dazu, gut lesbaren Code zu schreiben, ein kritisches Feature für Softwarecode, welcher
zukünftig verändert und weiterentwickelt werden muss. Die Sprache wurde von Grund
auf designt und hat ein orthogonales und klares Design, um Code schnell zu verste-
hen und leicht vorauszusagen. Der Kern der Sprache wurde einfach gehalten und kann
durch modular aufgebaut Libraries erweitert werden. Die Einschränkung der möglichen
Beeinflussung im Code reduziert die Programmkomplexität wie auch das Fehlerpoten-
tial. Ebenso kann Python die modernen Methoden der Softwareentwicklung abbilden,
strukturierte, modulare wie auch objektorientierte Programmierung sind möglich.
Produktivität: Mit Python kann die Anzahl Codierzeilen in einem Programm deutlich verkürzt
werden, da der Interpreter sich um viele Details kümmert, welche in andere Sprachen
expliziet auscodiert werden müssen. Auch die Wiederverwendbarkeit von Codefragmen-
ten ist aufgrund der fehlenden Abhängigkeit des Codes von der Typdefinition des Objek-
tes gewährleistet, denn es kann einaml geschriebener Implementations-Code auf wei-
tere Typen angewendet werden, wenn diese daselbe Interface implementieren. Ein wei-
terer Grund für die Produktivität von Python ist die Einfachheit der Struktur des Codes.
Durch die minimierte Anzahl Codezeilen wird der Code übersichtlicher und somit leser-
licher für Programmierer, welche bestehenden Code überarbeiten und weiterentwickeln
müssen. Diese können sich schneller einarbeiten und werden somit auch schneller pro-
duktiv.
6.1.2. Grundlagen
Python ist eine imperative Programmiersprache, mit welcher objektorientiert wie auch funktio-
nal programmiert werden kann. Wie Java, wir der Programmiercode durch einen Compiler in
Byte-Code übersetzt, welcher danach im Python-Interpreter ausgeführt wird. Der entstandene
Byte-Code ist plattformunabhängig und unterstützt insbesondere die Betriebssysteme Win-
dows, Linux und Mac OS X. Im Lieferumfang von Python ist nebst dem Interpreter und dem
Compiler eine umfangreiche Standardbibliothek vorhanden, welche es dem Programmierer
erlaubt, schnell komplexe Aufgaben zu lösen.
114
6.1. Programmiersprache Python
Interner Ablauf
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.
Die gute Lesbarkeit von Python ist zu einem grossen Teil der strengen Syntax zu verdanken.
Eine Anweisung besteht im einfachsten Fall aus einer Zeile. Das Ende der Anweisung wird
mit einem Zeilenumbruch gekennzeichnet. Anweisungen, welche sich in einen Kopf und einen
115
6. Software Plattform
Körper unterteilen lassen, werden durch Doppelpunkt am Ende des Anweisungskopfs und
Einrückung des Anweisungskörpers um 4 Leerzeichen festgelegt. Eine Kennzeichnung eines
Körpers durch geschweifte Klammer {...}, wie bei vielen Programmiersprachen üblich, existiert
in Python nicht.
# Anweisung
x = 10
if x < 20:
print “Hallo Welt”
Fallunterscheidungen
Fallunterscheidungen sind Konstrukte, welche dazu dienen, einen Anweisungsblock unter be-
stimmten Bedingungen ausführen zu lassen. Ein Fallunterscheidungs-Block beginnt immer
mit dem Schlüsselwort if. Weitere Unterscheidungen können durch elif erzeugt werden. Eine
Default-Anweisung wird durch das Schlüsselwort else eingeleitet.
if x == 1:
print "x hat den Wert 1"
elif x == 2:
print "x hat den Wert 2"
else:
print "Fehler: Der Wert von x ist weder 1 noch 2"
Conditional Expression
Bedingte Ausdrücke sind Anweisungen in der Form A if Bedingung else B, wobei Bedingung
ein beliebiger logischer Ausdruck sein kann. Die Auswertungsreihenfolge unterscheidet sich
insofern vom herkömmlichen Ablauf, dass zuerst die Bedingung ausgewertet wird, danach die
Anweisung A für eine wahre Bedingung, und sonst die Anweisung B.
116
6.1. Programmiersprache 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
Schleifendurchlauf vorzeitig beendet werden, durch „break“ wird die ganze Schleife verlassen.
Die for -Schleife dient dazu, einen Codeblock eine genau definierte Anzahl Mal zu durchlau-
fen. Dabei durchläuft die for -Schleife ein beliebiges iterierbares Objekt, zum Beispiel eine Zei-
chenkette oder einen Zahlenbereich. Wir ein Zahlenbereich verwendet, so stehen zu dessen
Definition drei Varianten zur Verfügung:
Module
In Modul ist ein Code-Fragment, welches in einer eigenen Datei steht und von anderen, meh-
reren Dateien importiert und verwendet werden kann. Sie tragen ebenfalls die Endung *.py
und können somit als Modul oder als eigenständige Programme verwendet werden. In einem
Modul definierte Variabeln können durch den Befehl
117
6. Software Plattform
importiert alle Variabeln und Funktionen, welche nicht mit einem „_“ beginnen. Diese soge-
nannten Membervariabeln sind nur innerhalb des Moduls sichtbar und können nicht von aus-
sen aufgerufen werden. (Schwarzer, 2006)
Objektorientierte Programmierung
Eine Klasse in Python wird mit der Anweisung class erzeugt. Eine neue Instanz wird mit dem
Konstruktor __init__ erzeugt, welcher die neue Instanz mit Werten initialisieren kann. Auch
die Vererbung von einer oder mehreren Klassen ist in Python möglich. (Schwarzer, 2006)
6.1.4. Fazit
Die Einfachheit von Python, seine Flexibilität und Erweiterbarkeit lässt die Sprache für klei-
ne wie auch grosse und komplexe Projekte interessant werden. Grosse Firmen wie Google
oder die NASA schätzen die Vorteile von Python in ihren Projekten. Auch die Online Platt-
form YouTube wurde fast vollständig in Python programmiert. Die einfache Installation, die
Plattformunabhängigkeit, die grosse Standard Bibliothek sowie der offene Quellcode machen
Python zu einer mächtigen Sprache. Arbeiten mehrere Programmierer am selben Quellcode,
soll dieser leicht erlernbar, verständlich und überschaubar sein, so ist Python eine optimale
Wahl. Die Ausnahmebehandlung von Python erlaubt es, die Zeit für Fehlersuche wesentlich
zu verringern.
118
6.2. Applikationsserver Zope
Zope erweitert als Web Applikationsserver, als ein Framework, um Web Applikationen zu ent-
werfen, die Standard-Fähigkeiten der Programmiersprache Python um Dienste wie Templa-
ting, Security Model, Datenpersistenz, Sessions und weitere nützliche Features. Die Vorteile
von Zope als Applikationsserver und Grundsteine für den Betrieb eines WCMS sind (Zope
Community, 2008):
Content Management System: Erstellen und editieren von Inhalten auch für nichttechnische
Editoren dank entsprechender Tools
Zope übernimmt von der Programmiersprache Python die Objektorientierung. Somit werden
Daten und Methoden in einem Objekt zusammengefasst. Die Klasse definiert das Verhalten
einen Objekts und dient als Konstruktor. Für Grundlagen zur Objektorientierung im Zusam-
menhang mit Zope sei auf (Zope Community, 2008) verwiesen.
Wie dies bereits von Webserver wie Apache oder Microsoft IIS bekannt ist, welche die URL auf
Verzeichnisse und Dateien abbilden, wird dies auch von Zope in ähnlicher Weise umgesetzt.
Die über den Webbrowser aufgerufene URL wird von Zope in seine Bestandteile in der Form
protocol://host:port/path?querystring
aufgeteilt. Zope lokalisiert das Objekt in der Objektdatenbank anhand des Pfades und führt
darauf die Parameter des Abfragestring aus. Ist die Ausführung erfolgreich, so wird das Resul-
tat an den Browser zurückgesendet. Meist sind dies Daten in HTML, Dateien oder Bilder.
Sicherheit
Zope wurde von Beginn an mit Fokus auf das Webentwicklungsmodell und die Sicherheits-
abstufung designt. Eine erfolgreiche Webseite benötigt eine flexible Rechteverwaltung, um
die Sicherheit der Applikation zu gewährleisten. Die Objekte in Zope stellen eine umfangrei-
chere Zugriffsbeschränkung als herkömmliche Dateisysteme bereit. Die Zugriffskontrolle wird
119
6. Software Plattform
über das Objekt selbst geregelt und erlauben somit eine feine Abstufung der Zugriffe. Dieses
Grundkonzept, welches im Applikationsserver selbst implementiert ist, kann von jedem Objekt
innerhalb des Applikationsservers verwendet werden. Entwickler haben somit als Basis eine
ausgereifte Grundlage für ihr Berechtigungskonzept.
Akquisition
Die Akquisition ist eine Spezialform der Vererbung. Bei dem herkömmlichen Vererbungskon-
zept erbt eine Klasse die Eigenschaften der Vaterklasse. In Zope kann ein Objekt zusätzlich
von einem übergeordneten Objekt in der Objekthierarchie erben. Dieses Vererbungskonzept
ist einzigartig und wird hauptsächlich für die gemeinsame Nutzung von Informationen, zum
Beispiel einen gemeinsamen Header eines ganzen Ordners einer Webseite, verwendet. Sei-
ne Mächtigkeit zeichnet sich dadurch aus, dass Definitionen an einer einzigen zentralen Stelle
verwaltet und ohne explizite Einbindung verwendet werden können, und dies auf unterschied-
lichen Objekten. Die Akquisition kommt erst nach der Vererbung zum tragen.
Ein Beispiel:
Das Objekt Sub(SuperA, SuperB) erbt von der Klasse SuperA sowie der Klasse SuperB.
Zudem liegt es im Ordner SuperFolder. Wird in einer Instanz des Objektes Sub nun
die Methode instance.method() aufgerufen, so werden der Reihe nach SuperA >
SuperB > SuperFolder nach der aufgerufenen Methode durchsucht.
6.2.2. Grundlagen
Auf Zope-Objekte kann vollständig über den Brwoser zugegriffen werden. Somit kann die ge-
samte Entwicklung und Administration über den Browser abgehandelt werden.
120
6.2. Applikationsserver Zope
6.2.2.3. Architektur
Zope besteht als Web Applikationsserver aus unterschiedlichen Komponenten, welche die
Entwicklung von Webapplikationen unterstützen.
ZServer: Der integrierte ZServer empfängt Inhalte via FTP, WebDAV, XML-RPC und über den
Browser und stellt Inhalte dem Benutzer zur Verfügung.
Web Server: Für die Benutzung von Zope kann anstelle des eigenen Web Servers auch ein
alternatives Produkt wie Apache oder Microsoft IIS verwendet werden, sowie weitere
Web Server, welche das Common Gateway Interface (CGI) unterstützen.
Zope Core: Der Kern von Zope koordiniert die Zusammenarbeit der Datenbank, des Web
Servers und den Erweiterungen und stellt die Kernfunktionalitäten bereit.
Object Database: Die Zope Object Datenbank ZODB speichert die von Zope verwendeten
Objekte.
File System: Dateien können in Zope entweder in der ZODB oder auf dem Dateisystem ab-
gelegt werden. Dies ermöglicht die Verknüpfung von lokalen Dateien und den Zugriff
darauf, ohne von Zope abhängig zu sein.
ZClasses: ZClasses sind zustätzliche Objekttypen, welche über das Zope Management In-
terface ZMI hinzugefügt wurden.
Products: Zustätzlich zu den ZClasses können externe Produkte auf dem Dateisystem des
Zope-Servers installiert werden und als Objekte in Zope eingebunden werden.
Einige Zope Objekte sind Service-Objekte, welche verschiedene Dienste bereit stellen. Eine
nicht abschliessende Liste (Zope Community, 2008):
Access Rule Services: Zugangsregeln ermöglichen es, beim öffnen eines bestimmten Ord-
ners eine Aktion auszulösen.
121
6. Software Plattform
Caching Services: Im Cache werden Objekte nach dem ersten Rendering gespeichert und
so die Zeit für die Bereitstellung des Inhaltes bein nächsten Aufruf bedeutend verringert.
Vorwiegend für komplexere Abfragen mit komplizierten Abfragen, wie sie auf Internetsei-
te oftmals vorkommen, steigern Caching Dienste die Performance der Webseite.
Error Logging Services: Zope stellt einen Logging-Dienst für Fehlermeldungen bereit, der
bei der Fehlersuche und deren Behebung behilflich sein soll.
Searching und Indexing Services: ZCatalog ist die in Zope integrierte Suchmaschine, mit
deren Hilfe alle Zope-Objekte durchsucht werden können. Für eine detaillierte Beschrei-
bung zu den Such- und Indexierungsmöglichkeiten in Zope sei auf (Zope Community,
2008) verwiesen.
Session Services: Sitzungsdaten eines Benutzers werden in Plone registriert und erlauben
es den Entwicklern, diese Daten für ihre Webanwendung weiter zu verwenden.
6.2.4. Fazit
Zope stellt als Web Applikationsserver eine grosse Menge an Grundfunktionalitäten und Diensten
zur Verfügung, welche von Entwicklern für die Programmierung von Webseiten verwendet
werden kann. Da Zope von Grund auf mit Fokus auf Web Anwendungen entwickelt wurde,
unterstützt es die Bedürfnisse optimal und erleichtert das Fehlerhandling sowie verringert den
Programmieraufwand.
Zope ist Open-Source und kann individuell angepasst werden. Die mitgelieferten Komponen-
ten wie eigene Datenbank ZODB kann ebenso durch eine eigene Datenbank ersetzt werden
wie der in Zope integrierte Web Server, der durch Apache oder Microsoft IIS getauscht werden
kann.
122
6.3. CMS Plone
Plone wird als Produkt oder als Gesamtpaket mit Zope und Python ausgeliefert. Die Installation
des Pakets ist denkbar einfach, man braucht lediglich den Installationsschritten zu folgen.
6.3.2. Grundlagen
Nach der Installation kann „Plone“ über den Webbrowser unter http://localhost auf-
gerufen werden. Sie wird mit den Standard-Layout geliefert und enthält initial bereits einige
erstellte Texte und Ordner.
6.3.2.1. Artikel
In „Plone“ gibt es verschiedene Artikeltypen, durch welchen der Verwendungszweck und die
Eigenschaften festgelegt werden. Initial werden folgende Artikeltypen mitgeliefert:
- Seiten
- Nachrichten und Termine
- Bilder und Dateien
- Links und Lesezeichen
- Ordner und Kollektionen
Alle Artikeltypen stellen mindestens die Reiter Anzeigen, Bearbeiten und Zugriff zur Verfü-
gung, sofern der Benutzer über genügend Berechtigungen verfügt („Ansehen“ resp. „Bearbei-
ten“). Anzeige und Bearbeiten sind für alle Artikeltypen gleich. Eine detaillierte Auflistung aller
verfügbaren Reiter und Einstellungen gibt Tabelle 6.1. Der Status
Anzeige
Die Anzeige stellt Artikel so dar, wie sie auch der Besucher der Webseite sieht und besteht
aus folgenden Elementen:
1. Titel
2. Verfasserzeile
3. Beschreibung
123
nen
n
iere
ktio
g
n
llun
olle
nen
orm
eite
6. Software Plattform
gen
en
n
alte
terk
rste
riff
tus
sio
nsf
arb
teri
gel
zei
Zug
Sta
Ver
Inh
Tra
Re
Un
Da
Kri
An
Be
Ordner x x x x x x x
Kollektionen x x x x x x x x x
Seite x x x x x
Bild x x x x
Datei x x x
Nachricht x x x x x
Termin x x x x x
4. Artikelaktionen
5. Historie (nur für angemeldete Benutzer sichtbar)
6. Vor- und Zurückblättern (je nach Einstellungen des Ordners)
Die beiden Artikeltypen „Ordner“ und „Kollektion“ können als Container zur Strukturierung ver-
wendet werden. Anhand dieser Struktur wird auch die Navigation aufgebaut. Die „Kollektion“
ist hierbei ein interessantes und mächtiges Konstrukt, welches es erlaubt,
6.3.3. Arbeitsablauf
Kein Arbeitsablauf
Hat ein Artikeltyp den Status „kein Arbeitsablauf“, so wird die Sichtbarkeit des Artikels durch
den Ordner bestimmt, in welchem er sich befindet. Initial ist dies dem Typ „Bild“ und „Datei“
zugewiesen. Bei der Erstellung wird der Artikel nach dem Speichern gleich publiziert und kann
eingesehen werden, wenn man für den übergeordneten Ordnen die entsprechenden Berech-
tigungen hat.
Artikeltypen mit einem Zustand verfügen nach dem Speichern über den Status veröffentlicht.
Weitere Statusübergänge sind nicht möglich.
124
6.3. CMS Plone
Einfacher Publikationsarbeitsablauf
Dies ist der Standard-Ablauf. Nach dem Erstellen eines Artikels erhält dieser den Status „pri-
vat“. Danach kann er zur Veröffentlichung an die Redaktion eingereicht oder direkt für alle
Benutzer veröffentlicht werden.
Intranet Arbeitsablauf
Beim Intranet-Arbeitsablauf sind Inhalte nur sichtbar, wenn man angemeldet ist. Neu erstellte
Artikel erhalten den Status „Interner Entwurf“. Die grundlegenden Zustände sind: Interner Ent-
wurf, Zur Prüfung eingereicht, Intern veröffentlicht und Privat. Es gibt auch den Status „extern
veröffentlicht“, sodass Sie ausgewählte Inhalte Personen ausserhalb des Intranets zugänglich
machen können.
Zusätzlich gibt es einen Intranet Arbeitsablauf für Ordner, welcher nur über die Zustände „In-
terner Entwurf“ und „Privat“ verfügt.
Community Arbeitsablauf
Benutzer können Inhalte erzeugen, die sofort öffentlich zugänglich sind. Inhalte können ver-
öffentlicht werden, wenn Sie zur Redaktion eingereicht werden, was typischerweise gemacht
werden sollte, damit Termine und Nachrichten auf der Startseite erscheinen. Während der In-
halt der Redaktion zur Prüfung vorliegt, kann ihn jeder lesen. Sobald der Inhalt veröffentlicht
ist, kann er nur vom Administrator zurückgezogen werden.
6.3.4. Benutzerberechtigungen
Nicht angemeldete Besucher der Seite oder Benutzer ohne Berechtigungen sehen alle Inhal-
te der Seite, welche den Status „Veröffentlicht“ besitzen. Für die Zusammenarbeit mehrerer
Personen können Berechtigungen für jeden einzelnen Benutzer oder für ganze Gruppen ver-
geben werden. Diese Berechtigungen können dann auf alle Artikeltypen angewandt werden.
„Plone“ liefert standardmässig die in Tabelle 6.2 aufgelisteten Berechtigungs-Funktionen. Die-
se können auf einzelne Benutzer wie auch auf ganze Gruppen angewandt werden. Genügen
diese vordefinierten Abstufungen nicht aus, so können im ZMI weitere Funktionen definiert
werden. Das ZMI listet unter acl_users im Bereich Security alle Rollen und deren Be-
rechtigungen. Da das ZMI vollständig in Englisch aufgebaut ist, werden hier auch die engli-
schen Funktionen gelistet: Contributor (Hinzufügen), Editor (Bearbeiten), Member (Benutzer),
Reader (Ansehen), Reviewer (Veröffentlichen) und Manager (Verwalten). Eine weitere Rolle
125
n
che
n
n
üge
ntli
lten
eite
6. Software Plattform
zer
en
öffe
seh
zuf
wa
arb
nut
Hin
Ver
Ver
Be
An
Be
Anzeige private Artikel x x x x
Anzeige eingereichter Artikel x x x x x
Veröffentlichen eingereichter Artikel x x x
Zurückweisen eingereichter Artikel x x x
Einreichen privater Artikel x x
Änderung der Darstellung x x x
Hinzufügen neuer Artikel x1 x
ist der Besitzer (Owner). Als Besitzer eines Artikels hat man darüber mehr Rechte, man kann
ihn standardmässig bearbeiten und löschen.
6.3.5. Erweiterungen
Die Installation von Produkte ist oftmals aufwendig, weil diverse Abhängigkeiten zwischen von
anderen Produkte bestehen, welche zusätzlich installiert werden müssen. Seit der Version 3
verfügt Plone über ein Skript mit dem Namen „easy_install“. Die „Eggs“ werden mit diesem
Skript installiert, welches im selben Schritt alle Abhängigkeiten prüft und diese bei Bedarf mit-
installiert. Zusätzlich können über das Installationsskript bereits diverse Einstellungen an der
Konfiguration vorgenommen werden. Das Skript befindet sich im Ordner <PLONE_HOME>/
Python/Scripts/. Möchte man „easy_install“ unter Windows über die Kommandozeile
aufrufen, muss der Ordner als Umgebungsvariable hinzugefügt werden.
2
http://www.plone.org
126
6.3. CMS Plone
127
6. Software Plattform
128
7. Implementierung, Konfiguration
Feldtest
7.1.1. Kommunikation
Plone bietet in der Core-Version die Möglichkeit, den Link zu einem Artikel zu versenden und
dabei Empfänger-, Absenderadresse und Kommentar hinzuzufügen. Mit der Erweiterung AR-
MailServices 0.6 können die gewünschten Funktionen bereitgestellt werden.
ARMailServices 0.6 wird als Produkt installiert und erweitert jeden Artikel um eine Aktion zum
erweiterten Versenden. Standardmässig können nur Benutzer mit Verwaltungsrechte Mails
versenden, diese Einstellung kann über das ZMI oder das Installationsfile angepasst werden.
Zusätzlich ist ein Portlet (Classic Portlet > „portlet_mailservices“) verfügbar. Nach Installation
können Mails an Benutzer und Gruppen versendet werden können. Wird ARMailServices über
die Aktion aufgerufen, so wird der Link zum akutellen Artikel gleich in den Body-Text des E-
Mails eingefügt. Somit können Hinweise auf neue Informationen schnell an eine ganze Gruppe
versendet werden.
129
7. Implementierung, Konfiguration
Kontaktmanagement
Plone bietet nur eine sehr oberflächliches Kontaktmanagement durch die Erfassung der Be-
nutzer, welche eine E-Mail-Adresse erhalten und zu einer oder mehreren Gruppen zugewiesen
werden können. Der Benutzer und die Gruppe dient zur Zugriffsregelung, ist jedoch nicht als
Kontaktverwaltung vorgesehen.
Bookmarks/Portal
Als klassisches CMS liefert Plone eine Portalseite mit, welche nach dem Einloggen die be-
nutzerspezifischen Inhalte anzeigt. Nebst der Inhaltsseite in der Mitte, gibt es verschiedene
Portlet-Positionen, auf welchen dynamische Erweiterungen angezeigt werden können.
130
7.1. Erfüllung der Anforderungen
Forum
Mailinglisten
Instant Messaging
Nachrichtenboard
Umfragen
Dokumentemanagement
Versionierung
Stukturierung
7.1.3. Projektmanagement
Extreme Programming
* Project Multiple projects can be added by employees. For each project contact information
of team members, iterations and stories can be added by both the customers and employees.
* Iteration The project will be planned with iterations. An iteration is a period of 2 to 4 weeks
in which a number of stories will be implemented. * Offer Contains the stories that a customer
wants in this Project. It is used as a way to bundle the wishes of the client and give a first
indication of the size of a project. * Story The customer can define new features by describing
these feature in a story. * Task The employees can estimate the story by defining tasks.
131
7. Implementierung, Konfiguration
132
8. Ausewrtung / Ausblick
Das Tool wird getestet und ausgewertet. Die beteiligten Personen werden befragt. Hier wird
auch erläutert, welche Erweiterungen noch implementiert werden müssen, damit das Tool den
Anforderungen einer modernen PM Plattform entspricht (und auch wie das gemacht werden
muss).
133
8. Ausewrtung / Ausblick
134
9. Schlussbemerkung
...
135
9. Schlussbemerkung
136
A. Literaturverzeichnis
[Agiles Manifest 2001] AGILES M ANIFEST: Manifesto for Agile Software Development. 2001. –
http://agilemanifesto.org
[Alpar u. a. 2005] A LPAR, Paul ; G ROB, Heinz L. ; W EIMANN, Peter ; W INTER, Robert: An-
wendungsorientierte Wirtschaftsinformatik. Vieweg Friedr. + Sohn Ver, 2005. – ISBN 978–
3528356569
[Beck 2005] B ECK, Kent: Extreme Programming Explained: Embrace Change. Addison-
Wesley Longman, 2005. – ISBN 978–0201616415
[Biethahn u. a. 2004] B IETHAHN, Jörg ; M UCKSCH, Harry ; RUF, Walter: Ganzheitliches Infor-
mationsmangement - Band I: Grundlagen. Oldenbourg, 2004. – ISBN 978–3486200201
[Bundesamt für Statistik 2008] B UNDESAMT FÜR S TATISTIK: Unternehmen Indikatoren. Stand
30.06.2007, 2008. – http://www.bfs.admin.ch
137
A. Literaturverzeichnis
[Ferstl u. Sinz 2006] F ERSTL, Otto ; S INZ, Elmar: Grundlagen der Wirtschaftsinformatik. Ol-
denbourg, 2006. – ISBN 978–3486579420
[Gloger 2008] G LOGER, Boris: Scrum. Produkte zuverlässig und schnell entwickeln. Hanser
Fachbuch, 2008. – ISBN 978–3446414952
[Huber 2007] H UBER, Andreas: Führung und Management von IT-Projekten: Projektetablie-
rung, Schaffung eines Projektrahmens. Vorlesung vom 31.10.2007, 2007
138
A. Literaturverzeichnis
[Jenny 2005] J ENNY, Bruno: Projektmanagement - Das Wissen fur eine erfolgreiche Karriere.
vdf Hochschulverlag AG an der ETH Zürich / 2. Auflage, 2005. – ISBN 978–3–7281–3004–4
[König 2008] KÖNIG, Jean-Pierre: Warum machst DU Scrum? Online, 2008. – http://inside-
scrum.blogspot.com
[Kuhnt 2007] K UHNT, Beate: Führung und Management von IT-Projekten / Schwerpunkt
mensch informatik organisation, Institut für Informatik, Universität Zürich. 2007. – For-
schungsbericht
[Lutz 2006] L UTZ, Mark: Programming Python. O’Reilly, 2006. – ISBN 978–0596009250
[Martelli 2006] M ARTELLI, Alex: Python in a Nutshell - A Desktop Quick Reference. O’Reilly,
2006. – ISBN 978–0596100469
[Mengelt 2008] M ENGELT, Flurin: Zusammenarbeit nach Scrum, Universität Zürich, Diplomar-
beit, 2008. – http://www.ifi.uzh.ch/mio/schwerpunkt/services/forschung/projects/studenttasks/index.html
[Noack 2007] N OACK, Sascha: ECM - Enterprise Content Management. GRIN Verlag, 2007.
– ISBN 978–3638644631
[Office2007 Blog 2008] O FFICE 2007 B LOG: Projekte managen, mit MS Office Groove 2007.
online, 2008. – http://www.office2007-blog.de
[Schiestl 1996] S CHIESTL, Josef: Groupware-Software für die Teamarbeit der Zukunft. Tectum
Verlag, 1996. – ISBN 978–3896089250
139
A. Literaturverzeichnis
[Schopp 2008] S CHOPP, Bernd: Intranet Projekte mit SCRUM. Online, 2008. –
http://blog.namics.com
[Spath u. a. 2007] S PATH, Dieter ; S CHIMPF, Sven ; K UGLER, Andreas: Webbasierte Open
Source Kollaborationsplattformen / Frauenhofer Institut für Arbeitswirtschaft und Organisa-
tion. 2007. – Forschungsbericht
[Sörensen 2007] S ÖRENSEN, Sven: Extreme Programming und Software-Qualität. GRIN Ver-
lag, 2007. – ISBN 978–3638655279
[Stoyan 2004] S TOYAN, Robert: Management von Webprojekten. Heidelberg : Springer Verlag,
2004. – ISBN 3–540–00582–X
[Vetter 1998] V ETTER, Max: Objektmodellierung. Teubner Verlag, 1998. – ISBN 978–
3519121435
140
Abbildungsverzeichnis
141
Abbildungsverzeichnis
142
B. Innovationsspiele
Innovationsspiele werden dazu verwendet, auf spielerische Art und Weise Informationen zu
erarbeiten und die Bedürfnisse der Kunden besser zu verstehen. Diese Spiele können in Zu-
sammenarbeit mit den Teammitgliedern oder mit den Kunden erprobt werden. Sie werden
benutzt, um Produkt-Roadmaps zu erstellen, Verkauf und Marketing zu verbessern, Kunden-
beziehungen zu stärken, neue Geschäftsmöglichkeiten zu erforschen und um strategisch zu
planen (Hohmann, 2007).
Für die Erarbeitung der Anforderungen im Kapitel 4 wurden folgende Innovationsspiele ver-
wendet:
Buy a Feature: Ziel ist die Priorisierung der Features einer Software durch den Kunden.
Vorgehen: Eine Liste mit potentiellen Features wird erstellt und jedem Feature wird ein
Preis zugeordnet. Der Preis basiert zum Beispiel auf Entwicklungskosten oder auf Kun-
dennutzen. Die anwesenden Kunden können danach diese Features kaufen, haben aber
nur eine beschränkte Menge Geld zur Verfügung. Einige Features kosten jedoch mehr,
als ein einzelner Kunde zur Verfügung hat. Um dieses zu kaufen, müssen mehrere Kun-
den ihr verfügbares Geld zusammenlegen. Somit wird die Verhandlung innerhalb der
Kunden und die Kommunikation gefördert. Ideal ist eine Gruppe von ca. sieben Perso-
nen aus verschiedenen Aufgabenbereichen des Kunden.
Product Box: Ziel ist es, die wichtigsten Features eines Produkts zu erarbeiten.
Vorgehen: Alle Kunden erhalten eine leere Kartonbox und sollen sich vorstellen, sie
müssten diese Box, welche das System repräsentiert, nun verkaufen. Als Hilfe soll die
Box so verändert werden, dass der Kunde selbst sie kaufen würde. Danach muss er,
wie an einer Tradeshow oder auf dem öffentlichen Markt, seine eigene Box den übrigen
Anwesenden verkaufen. Der Projektleiter achtet hierbei auf die Fragestellungen, welcher
Kunde die Box kaufen würde, und warum.
Remember the Future: Ziel ist es, den Begriff des Erfolgs für den Kunden zu verstehen.
Jeder Kunde erhält ein paar Blätter Papier und soll sich vorstellen, er befinde sich in
143
B. Innovationsspiele
der Zukunft - ein paar Monate, ein paar Jahre, je nachdem was der Projektleiter her-
ausfinden möchte. Nun soll er so detailliert wie möglich aufschreiben, was das Produkt
dazu beigetragen hat, dass sich der Kunde gut fühlt (dieses Spiel kann mit diversen Ad-
jektiven gespielt werden, z.B. erfolgreich, glücklich, sicher, . . . ). Wichtig ist die Art der
Fragestellung: es ist ein grundlegeneder Unterschied ob man fragt „Was soll das System
tun?“ oder „Was hat das System getan?“.
20/20 Vision: Ziel ist es, die Features nach Wichtigkeit zu ordnen.
Vorgehen: Der Projektleiter notiert alle Features eines Produktes auf Karten, eine Karte
pro Feature. Er durchmischt den Stapel und hängt das erste Feature an eine Pinnwand.
Für das zweite Feature muss der Kunde entscheiden, ob dieses wichtiger oder weniger
wichtig als das erste Feature ist. Der Projektleiter hängt das Feature danach oberhalb
(wichtiger) oder unterhalb (weniger wichtig) der ersten Karte auf. Sind alle Karten durch-
gespielt, resultiert daraus eine Reihenfolge aller Features nach Wichtigkeit geordnet.
144