Anforderungsanalyse, Konzeption und prototypische Implementierung eines Wikis für das Projektmanagement in einem mittelständischen Softwareunternehmen

Inhaltsverzeichnis

1. Einleitung
1.1 Ziel
1.2 Aufbau

2. Problemstellung

3. Theoretische Grundlagen
3.1 Projektmanagement
3.1.1 Begriffsdefinitionen
3.1.2 Die Formen der Projektorganisation
3.1.3 Die Phasen eines Projekts
3.1.4 Aufgaben des Projektmanagements
3.1.5 Die Faktoren Zeit, Kosten und Qualität
3.1.6 Erfolgsfaktoren und Gründe für das Scheitern von Projekten
3.2 Software Engineering
3.2.1 Begriffsdefinition
3.2.2 Charakteristika von Software
3.2.3 Das Phasenmodell im Software Engineering
3.3 Wikis
3.3.1 Begriffsdefinition
3.3.2 Grundlagen
3.3.3 CSCW und das 3K-Modell
3.3.4 Anwendungsgebiete

4. Methodik
4.1 Analysephase
4.2 Implementierungsphase
4.3 Testphase

5. Ergebnisse
5.1 Anforderungen
5.1.1 Anforderungen aus der Literatur
5.1.2 Betriebliche Anforderungen
5.1.3 Priorisierung
5.1.4 Anforderungsspezifikation
5.2 Konzept
5.2.1 Erfolgsfaktoren
5.2.2 Wiki für das Wissensmanagement
5.2.3 Wiki für das Dokumentenmanagement
5.2.4 Wiki für das Projektmanagement
5.3 Auswahlprozess
5.3.1 Beschreibung der Alternativen
5.3.2 Nutzwertanalyse
5.4 Pilotversion
5.4.1 Implementierung
5.4.2 Test Cases
5.5 Szenario
5.5.1 Vorbereitungen
5.5.2 Durchführung
5.5.3 Auswertung

6. Resumée

Quellenverzeichnis

Anhang A

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Magisches Dreieck

Abbildung 2: Suchvolumen Wiki - Blog

Abbildung 3: Gartner Hype Cycle for Emerging Technologies 2007

Abbildung 4: 3K-Modell nach Teufel et al

Abbildung 5: Deki Wiki Screenshot

Abbildung 6: Anforderungsspezifikation im Wiki

Abbildung 7: Gartner Hype Cycle 2005-2007 A

1. Einleitung

„According to a study performed by the Gartner Group, 80% of all IT projects are not successfully completed. Either the budget is overdrawn, the project in not completed on schedule, or the project functionality is incomplete.”^[1]

Dies ist der einleitende Satz auf der Internet-Projektseite meines Ausbildungsbetriebs, der AC-B GmbH. Die Angaben, wie viele IT-Projekte scheitern oder nicht planmäßig fertiggestellt werden, unterscheiden sich je nach vorhandener Quelle. Dies mag daran liegen, dass es je nach subjektiver Empfindung jedes Einzelnen unterschiedlich interpretiert werden kann, ab wann ein Projekt als gescheitert gilt. Eines ist jedoch aus zahlreichen Quellen deutlich erkennbar: IT-Projektmanagement ist schwierig – und die Zahl der gescheiterten Projekte hoch. Wie auch in dem einleitenden Zitat wird in diesem Zusammenhang oft das sogenannte „magische Dreieck“ herangezogen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Magisches Dreieck

Die Abbildung^[2] veranschaulicht die in einem Projekt stets konkurrierenden Faktoren Zeit, Kosten und Qualität, welche es gemäß den Anforderungen des Auftraggebers einzuhalten gilt. Diese Thematik wird im Verlauf der Arbeit noch ausführlicher betrachtet.

Es stellt sich also die berechtigte Frage, mit welchen Mitteln man das Projektmanagement unterstützen kann. Eine mögliche Technologie um dies zu realisieren könnten die Wikis sein, welche durch den Web 2.0 Boom große Aufmerksamkeit erlangt haben.

Der Erfinder des ersten Wikis, Ward Cunningham, weist schon in seinem Standardwerk The Wiki Way auf den potenziellen Nutzen von Wikis für das Projektmanagement hin.^[3] Cunningham entwarf das erste Wiki bereits im Jahr 1994. Die folgende Grafik^[4] lässt jedoch darauf schließen, dass das Thema „Wiki“ erst parallel zu anderen Web 2.0 Technologien für die breite Masse interessant wurde. Zu sehen ist das qualitative Suchvolumen nach den Begriffen „wiki“ und „blog“ bei der Suchmaschine Google.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Suchvolumen Wiki - Blog

Beachtlich ist, dass das vorerst geringe Interesse an Wikis die Nachfrage nach Blogs, welche zu stagnieren scheint, hier überschritten hat. Ein etwas widersprüchliches Bild liefert jedoch der Gartner Hype Cycle for Emerging Technologies aus dem Jahr 2007.^[5]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Gartner Hype Cycle for Emerging Technologies 2007

Hier befinden sich die Wikis im Trough of Disillusionment, dem „Tal der Ernüchterung“. Dies bedeutet, dass die Wikis, laut Gartner, an einem Punkt angekommen sind, an dem die überzogenen Erwartungen aus der vorherigen Phase, dem Peak of Inflated Expectations, nicht erfüllt wurden. Für die Zukunft bedeutet dies jedoch ebenso, dass die Analysten von Gartner den Wikis in den Folgephasen eine große Rolle im Bereich der IT zumessen. Die Entwicklung der Wikis im Gartner Hype Cycle von 2005 bis 2007 sowie eine Beschreibung der einzelnen Phasen kann dem Anhang entnommen werden.

Nachdem einleitend die allgemeine Signifikanz der Themen Wikis und Projektmanagement aufgezeigt wurde, folgt nun eine Darstellung der Ziele sowie des Aufbaus dieser Arbeit. Die theoretischen Grundlagen zu Wikis und Projektmanagement werden in Kapitel 3 behandelt. Da in dieser Arbeit schwerpunktmäßig auf das Projektmanagement im Bereich der IT eingegangen wird und das implementierte Wiki in einem Softwareunternehmen zum Einsatz kommt, werden die Grundlagen zum Thema Software Engineering hier ebenfalls erörtert.

1.1 Ziel

Im Rahmen dieser Arbeit soll erläutert werden, aus welchen Gründen Projekte, speziell IT-Projekte, scheitern und wie dies mit dem Einsatz von Wikis als Projektmanagement-Tool verhindert bzw. die Situation für das Projektmanagement verbessert werden kann. Hierzu werden vorerst die theoretischen Grundlagen über Wikis, Projektmanagement und Software Engineering dargestellt und diese Themen miteinander in Bezug gebracht.

Im späteren Verlauf der Arbeit wird dargelegt, welche Anforderungen ein Wiki erfüllen muss, um in einem mittelständischen Softwareunternehmen wie der AC-B GmbH als Projektmanagement-Tool nutzenbringend eingesetzt werden zu können. Als Praxisbeispiel dienen die Anforderungsanalyse, die Konzeption, der Auswahlprozess und die prototypische Implementierung eines Wikis bei der AC-B GmbH. Anhand eines konkreten Szenarios wird der potenzielle Nutzen des implementierten Wikis veranschaulicht.

Längerfristig gesehen könnte das implementierte Wiki das Wissens-, Dokumenten- sowie das Projektmanagement der AC-B GmbH unterstützen. Die Ergebnisse dieser Arbeit sollen hierbei auch auf andere Projekte und Unternehmen, beispielsweise auf einen Kunden der AC-B GmbH, übertragen werden können.

1.2 Aufbau

Der Aufbau der kompletten Diplomarbeit besteht aus einem theoretischen und einem praktischen Teil. Den praktischen Teil stellt das prototypisch implementierte Wiki dar. Die gewonnenen Erkenntnisse und die wissenschaftlichen Grundlagen aus der Literatur sind in diesem Manuskript beschrieben, welches den theoretischen Teil darstellt. Es folgt nun eine kurze Beschreibung der Inhalte der jeweiligen Kapitel dieser Arbeit.

Kapitel 1 gibt dem Leser eine Einführung in die Thematik, erörtert deren Relevanz und gibt einen allgemeinen Überblick über die Ziele und den Aufbau der Diplomarbeit.

Kapitel 2 beschreibt die konkrete Problemstellung sowie die spezifischen praktischen Gegebenheiten, unter welchen der Prototyp des Wikis implementiert wird. Als Beispiel wäre hier die geringe Mitarbeiteranzahl zu nennen, welche im Falle eines Wikis nicht unerhebliche Konsequenzen für die Vorgehensweise im Projekt hat.

Kapitel 3 erörtert die theoretischen Grundlagen, welche bei der Erstellung der Arbeit herangezogen wurden und zum Verständnis der Thematik notwendig sind. Behandelt werden die Themen Projektmanagement, Software Engineering und Wikis. Teilweise wird auch auf die spezifischen Gegebenheiten aus Kapitel 2 eingegangen.

Kapitel 4 legt die Vorgehensweise bei der Erstellung der Arbeit dar. Hierbei werden die Vorgänge in den einzelnen Projektphasen gesondert betrachtet. Auch hier werden Aspekte aus Kapitel 2 angesprochen, welche Einfluss auf die notwendige Vorgehensweise in den jeweiligen Projektphasen hatten.

Kapitel 5 stellt das eigentliche Ergebnis und somit den Hauptteil dieser Arbeit dar. Hier werden die gewonnenen Erkenntnisse dargelegt und die Ergebnisse aus den einzelnen Projektphasen vorgestellt. Hierzu zählen die Spezifikation der Anforderungen an das System, das Vorgehenskonzept, der Auswahlprozess sowie eine Beschreibung der implementierten Pilotversion und eines konkreten Szenarios.

Kapitel 6 bildet den Abschluss der Arbeit. Das Thema wird zusammengefasst und die Ergebnisse kritisch bewertet. Auch werden weitere Perspektiven aufgezeigt und die Übertragbarkeit der Ergebnisse auf andere Gegebenheiten bzw. Unternehmen dargelegt.

2. Problemstellung

Die AC-B GmbH, ein mittelständisches Softwareunternehmen mit zehn Mitarbeitern und zwei BA-Studenten, hat ihre Hauptgeschäftsfelder im Umfeld von Systemwartung und -Pflege sowie der Softwareentwicklung im Bereich der Luft- und Raumfahrt. Organisatorisch handelt es sich um eine reine Projektorganisation, womit dem Projektmanagement bei der AC-B GmbH eine besonders entscheidende Rolle zufällt.

Die Firmen- und Projektdokumentationen sind in Form von MS Office- und PDF-Dateien auf einem zentralen NAS File Server gespeichert. Dieser ist unterteilt in ein öffentlich zugängliches Laufwerk, auf dem alle Mitarbeiter an Dokumenten arbeiten können, sowie ein Laufwerk für das Konfigurationsmanagement, auf dem die aktuellsten Versionen von Dokumentationen etc. abgelegt sind und auf das nur die Geschäftsleitung und Netzwerkadministratoren Schreibzugriff haben.

Persönliches Wissen wird von jedem Mitarbeiter unterschiedlich verwaltet. Manche erstellen Textdateien mit Notizen zu Kunden und Projekten und legen diese in ihrem Nutzerverzeichnis aus dem Server oder lokal auf dem Arbeitsplatzrechner ab. Andere erstellen HTML-Dateien mit Notizen und Verweisen auf Quellen im Internet und dem File Server, wieder andere machen sich Notizen auf Papier und Post Its. Projektbezogenes Wissen wird, teilweise redundant, in entsprechenden Ordnern auf dem Server abgelegt. Zur Ordnerstruktur auf dem Server bestehen jedoch nur Richtlinien für die obersten Hierarchieebenen.

Diese Vorgehensweise im Umfeld von Dokumenten- und Wissensmanagement bringt folgende Probleme mit sich:

- Gleichzeitiges Arbeiten von mehreren Mitarbeitern an einem Dokument ist nicht möglich bzw. nur durch Bearbeitung von Kopien der Dokumente zu erreichen, was die Gefahr von Inkonsistenzen mit sich bringt.
- Daten werden teilweise redundant gehalten.
- Mitarbeiter haben keinen Zugriff auf für sie evtl. relevantes Wissen anderer Mitarbeiter, finden es nicht oder wissen nicht einmal, dass dieses Wissen existiert.
- Fehlende Richtlinien führen zu einer unübersichtlichen Ordnerstruktur, was zu Folge hat, dass:
- Mitarbeiter regelmäßig Zeit aufwenden müssen, um Dokumente zu suchen und
- Neue Ordner für bereits vorhandene Daten an anderer Stelle angelegt werden, da die vorhandenen Daten nicht gefunden werden oder deren Existenz nicht bekannt ist – was wiederum zu Redundanz führt.

Ein Wiki könnte dazu beitragen diese Probleme zu bewältigen und das Wissens- und Dokumentenmanagement effizienter zu gestalten. Da es sich bei der AC-B GmbH um eine reine Projektorganisation handelt, hätte dieser Umstand ebenso indirekte positive Auswirkungen auf das Projektmanagement. In einem weiteren Schritt könnte das Wiki auch aktiv als Tool für das Projektmanagement eingesetzt werden.

Um dies zu erreichen muss ein Wiki ausgewählt werden, welches die allgemeinen Anforderungen an ein Wiki aus der Literatur sowie die betrieblichen Anforderungen der AC-B GmbH erfüllt. Die Anforderungen der Mitarbeiter an das System stellen hier einen sehr wichtigen Punkt dar, da ein Wiki von der Partizipation seiner Nutzer lebt. Die Spezifikation der Anforderungen ist eines der Ergebnisse dieser Arbeit.

Ferner muss sichergestellt werden, dass sich das zu implementierende Wiki ohne allzu großen Aufwand und ohne Gefahren für die IT-Sicherheit in die bestehende Infrastruktur der AC-B GmbH integrieren lässt. Hierbei müssen die technischen Richtlinien der AC-B GmbH berücksichtigt werden.

An dieser Stelle sei nochmals darauf hingewiesen, dass es sich um eine prototypische Implementierung handelt. Das Erstellen von Dokumentationen zum Projekt, die Erweiterung des Systems durch Plug-Ins sowie eine umfassende Gestaltung des Layouts sind somit nicht Bestandteil dieser Arbeit. Es soll lediglich aufgezeigt werden, welche Möglichkeiten das implementierte System bietet und welche Potenziale es für einen zukünftigen Einsatz bietet.

Man könnte davon ausgehen, dass sich die geringe Anzahl der Mitarbeiter negativ auf den Erfolg des Wikis auswirkt, da dieses so langsamer mit Inhalten gefüllt wird. Jedoch kann die niedrige Zahl an Nutzern den Vorteil mit sich bringen, dass deren Wünsche durch Meetings und persönliche Gespräche besser identifiziert und berücksichtigt werden können, was gute Voraussetzungen für die so wichtige Nutzerakzeptanz schafft.

3. Theoretische Grundlagen

Dieses Kapitel erläutert die theoretischen Grundlagen, welche zum Verständnis der Arbeit erforderlich sind. Behandelt werden die Themen Projektmanagement, speziell IT-Projektmanagement, Software Engineering und Wikis. Im Anschluss an dieses Kapitel folgt das Kapitel Methodik, welches die Vorgehensweise beim Erstellen dieser Arbeit beschreibt.

3.1 Projektmanagement

Im Folgenden werden die theoretischen Grundlagen zum Thema Projektmanagement erörtert. Es sei an dieser Stelle erwähnt, dass sich die Begriffe Projekt und Projektmanagement im Rahmen dieser Arbeit, neben allgemeinen Thesen, hauptsächlich auf das Gebiet des Software Engineering beziehen. Aufgrund der Komplexität und des hohen Umfangs des Themas wird nur ein allgemeiner Überblick über das Projektmanagement gegeben. Die für diese Arbeit weniger relevanten Aspekte werden ausgelassen.

3.1.1 Begriffsdefinitionen

Für den Projektbegriff sind in der Literatur zahlreiche Beispiele vorhanden, von denen nun einige angeführt werden. Die erste Definition richtet sich hierbei stark an Projekte im Bereich der Softwareentwicklung:

In einem Projekt „wird davon ausgegangen, dass es definierte Projektziele gibt, die Dauer des Projekts begrenzt ist und eine Neu- oder Weiterentwicklung eines Software-Systems durchgeführt werden soll.“^[6]

Eine allgemeinere Definition spezifiziert ein Projekt als „ein Vorhaben mit definiertem Beginn und Abschluss, das sich im Gegensatz zu den regelmäßig wiederkehrenden Arbeitsabläufen eines Unternehmens durch folgende Merkmale beschreiben lässt: Einmaliger und zeitlich begrenzter Lebenszyklus und relativ hohe technologische und/oder manageriale Komplexität und Neuartigkeit.“^[7]

Die DIN spricht von einem „Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B.:

- Zielvorgabe
- Zeitliche, finanzielle oder andere Begrenzungen
- Abgrenzung gegenüber anderen Vorhaben
- Projektspezifische Organisation“^[8]

Zu beachten ist, dass bereits hier die in der Einleitung erwähnten Faktoren des magischen Dreiecks, Zeit, Kosten und Qualität, teilweise herangezogen werden.

Das Projektmanagement umfasst hierbei „alle Aktivitäten, um zu gewährleisten, dass die Projektziele eingehalten werden können. Dies sind speziell Planungs-, Überwachungs- und Steuerungs-Methoden.“^[9]

Laut DIN wird unter Projektmanagement „die Gesamtheit von Führungsaufgaben, Führungsorganisation, Führungstechniken und -mitteln für die Projektabwicklung“^[10] verstanden. „Dabei ist der Begriff ‚Führung‘ als die Steuerung der verschiedenen Aktivitäten im Projekt im Hinblick auf die übergeordneten Projektziele zu verstehen.“^[11]

3.1.2 Die Formen der Projektorganisation

Die verwendeten Begrifflichkeiten und Zuordnungen zu verschiedenen Projektorganisationen unterscheiden sich in der Literatur je nach herangezogener Quelle geringfügig. Auf Basis diverser Quellen^[12],^[13],^[14] wird nun eine Zusammenfassung der gängigsten Definitionen und Begriffe für verschiedene Formen von Projektorganisationen erarbeitet.

Stabs-Projektorganisation

Die Stabs-Projektorganisation, oft auch als Einfluss-Projektorganisation bezeichnet, kennzeichnet sich dadurch, dass ein Mitarbeiter die Leitung eines Projekts parallel zu seinen gewöhnlichen Tätigkeiten wahrnimmt. Die organisatorische Form des Unternehmens wird hierbei lediglich um eine Stabsstelle ergänzt. Bei dieser Organisationsform hat der Projektleiter eine sehr geringe Weisungsbefugnis. Der Vorteil bei dieser Form der Projektorganisation liegt darin, dass durch die geringe organisatorische Umstrukturierung im Unternehmen wenig Aufwand entsteht. Die Stabs-Projektorganisation findet Anwendung bei Projekten mit geringer Komplexität und einer weniger großen Bedeutung für das Unternehmen.

Matrix-Projektorganisation

Bei der Matrix-Projektorganisation werden die Aufgaben für die Mitarbeiter zwischen Projekttätigkeiten und Tätigkeiten für die Primärorganisation verteilt. Gegebenenfalls kann ein Mitarbeiter auch in mehreren Projekten gleichzeitig eingesetzt werden. Der Projektleiter verfügt hier über eine wesentlich höhere Weisungsbefugnis als bei der Stabs-Projektorganisation. Dies führt dazu, dass die jeweiligen Mitarbeiter zwei Vorgesetzte haben. Hierbei unterliegt dem Projektleiter die fachliche- und dem Abteilungsleiter die Personalverantwortung. Dieser Umstand birgt ein gewisses Konfliktpotential und erfordert von den Vorgesetzten Kooperationsbereitschaft. Andererseits bietet die Matrix-Projektorganisation ein hohes Maß an Flexibilität beim Personal- und Ressourceneinsatz. Sie findet Anwendung bei mehreren parallel laufenden Projekten niedriger bis mittlerer Komplexität.

Reine Projektorganisation

Bei der reinen Projektorganisation sind die Mitarbeiter vollständig aus ihren Abteilungen herausgelöst und arbeiten nur noch an dem Projekt. Dies kann so weit gehen, dass ein Unternehmen zu weiten Teilen nur noch in Projekten organisiert ist. Der Projektleiter hat in diesem Fall die alleinige Weisungsbefugnis über die Mitarbeiter im Projekt. Führungskräfte außerhalb des Projekts haben hier allenfalls noch eine beratende Funk-tion. Im Gegensatz zur Stabsorganisation ist in diesem Fall der Aufwand der Umorganisation für das Unternehmen sehr hoch. Ebenso besteht die Gefahr, dass Routineprozesse im Unternehmen vernachlässigt werden und dass Mitarbeiter nach Abschluss des Projekts schwer in ihre einstigen Abteilungen zurückintegriert werden können. Andererseits ermöglicht diese Form der Projektorganisation eine schnelle Entscheidungsfindung im Projekt und erhöht die Mitarbeitermotivation, da diese sich besser mit dem Projekt identifizieren und allein darauf konzentrieren. Auch besteht hier, sowohl für den Auftraggeber als auch für die Mitarbeiter, nur eine Anlaufstelle (der Projektleiter), was die externe Kundenorientierung verbessert. Die reine Projektorganisation wird eingesetzt bei komplexen Großprojekten, ist aber auch bei einer geringen Zahl an Mitarbeitern denkbar.

Diese Form der Projektorganisation kommt auch bei der AC-B GmbH zum Einsatz. Die Mitarbeiter verwenden einen Großteil der Arbeitszeit auf die jeweiligen Projekte und kümmern sich nur bei Bedarf um firmeninterne Tätigkeiten wie Netzwerkadministration, Vertrieb etc. Der eben angeführte Nachteil bei reinen Projektorganisationen, nämlich der Umstand, dass die Routinetätigkeiten im Unternehmen eventuell vernachlässigt werden, könnte den Grund für einige der in Kapitel 2 aufgeführten Probleme beim Wissens- und Dokumentenmanagement darstellen.

3.1.3 Die Phasen eines Projekts

Phasenmodelle für Projekte unterscheiden sich je nach Projektart, sind in ihren Grundzügen jedoch immer relativ ähnlich. Das gängige Phasenmodell in der Softwareentwicklung, welches für diese Arbeit relevant ist, wird im folgenden Abschnitt Software Engineering dargelegt. Zum Vergleich ein kurzes Beispiel eines Phasenmodells einer anderen Branche, in der die AC-B GmbH ebenfalls situiert ist, der Raumfahrt:

„ A: Konzeptphase mit den Schritten Formulierung der Projektzielsetzung, Durchführung von Systemanalysen, Konzeptauswahl und Projektformulierung, vorläufige Projektplanung.

B : Definitionsphase mit den Schritten Detaillierung der Projektplanung, Projekt- und Systemoptimierung sowie abschließende Projekt- und Systemplanung.

C: Entwurfs- und Entwicklungsphase mit den Schritten Spezifikation des Entwicklungsauftrags, detaillierter Entwurf und Testmodelle, System- und Teilsystementwicklung, Prototypenentwicklung und Test sowie Entwicklungsabschluss.

D: Fertigungs-, Betriebs- und Wartungsphase, Teilefertigung, Montage und Test sowie Inbetriebnahme.

E: Aussonderungsphase“^[15]

Generell lassen sich Projekte unterteilen in die Vorphase, Analysephase, Konzeptionsphase, Realisierungsphase, Testphase, Abnahmephase und Abschlussphase. Am Ende einer jeden Projektphase steht ein eindeutig definierter Meilenstein, an dem ein konkretes Ergebnis vorliegt, zum Beispiel ein erstelltes Pflichtenheft.^[16]

3.1.4 Aufgaben des Projektmanagements

Laut der bereits angeführten Definition beschäftigt sich das Projektmanagement mit Planungs-, Überwachungs- und Steuerungs-Methoden, um das Erreichen des Projektziels sicherzustellen. Konkret gehören hierzu unter anderem:

- Festlegung von Rahmenbedingungen für das Projekt wie beispielsweise die Wahl der Projektorganisation, Besprechungsplanung oder Aufstellen von Eskalationsstrategien.
- Erstellung einer Aufwandsschätzung, um zu erkennen, ob die Projektziele realisierbar sind.
- Planung des Projektverlaufs, um notwendige Aktivitäten wie Qualitätsmanagement, Konfigurationsmanagement etc. zu detaillieren und den Mitarbeitern zuzuordnen.
- Beauftragung der Mitarbeiter, um diese über die von ihnen erwarteten Arbeitsergebnisse zu informieren.
- Ermittlung der Projektsituation mit Hilfe von Besprechungen und Arbeitsberichten. Basierend auf den gewonnenen Erkenntnissen folgt die
- Bewertung der Projektsituation, um festzustellen, ob alle notwendigen Aktivitäten durchgeführt wurden und die Projektziele nach wie vor innerhalb der vorgegebenen Zeit und des vorgegebenen Budgets realisierbar sind (siehe magisches Dreieck). Falls dies nicht der Fall ist, folgt die
- Einleitung steuernder Maßnahmen.
- Durchführung des Projektabschlusses und Analyse des Projektverlaufs.^[17]

Eines scheint sich bereits jetzt abzuzeichnen: Im Projektmanagement spielen Kommunikation, Koordination und Kooperation eine große Rolle, sowie zwischen der Projektleitung und den Mitarbeitern, als auch unter den Mitarbeitern selbst. Diese drei Faktoren sind die Eckpfeiler des 3K-Modells von Teufel et al^[18], auf welches im Abschnitt 3.3 Wikis noch genauer eingegangen wird. Die genannten Umstände deuten darauf hin, dass Wikis im Projektmanagement nutzenbringend eingesetzt werden könnten. An dieser Stelle sei nochmals, wie schon in der Einleitung, auf Cunningham hingewiesen, der Wikis ebenfalls als potenzielle Tools für das Projektmanagement eingestuft hat.

3.1.5 Die Faktoren Zeit, Kosten und Qualität

Nun soll anhand entsprechender Quellen^[19],^[20] auf die bereits des Öfteren erwähnten Aspekte Zeit, Kosten und Qualität, welche in jedem Projekt konkurrierende Faktoren darstellen, eingegangen werden.^[21] Das hierbei oftmals angeführte magische Dreieck wird übrigens auch hin und wieder als „Konfliktdreieck des Projektmanagements“ bezeichnet, was die Situation sehr treffend beschreibt. Dies soll anhand einer Veranschaulichung der Wechselwirkungen zwischen diesen Faktoren verdeutlicht werden.

Der Zeitfaktor

Projekte müssen in den meisten Fällen zu einem bestimmten Zeitpunkt fertiggestellt werden, beispielsweise, wenn ein Produkt auf einer Messe präsentiert werden soll oder der Auftraggeber dies in den Anforderungen festgelegt hat. Nachdem die Anforderungen an das Projekt klar definiert wurden, wird mit Hilfe einer Aufwandsschätzung und der allgemeinen Projektplanung das Terminziel definiert. Kontrolliert wird dies durch die bereits angesprochene Erfassung des Projektfortschritts und entsprechende Hochrechnungen.

Der Kostenfaktor

Die Kosten müssen in jedem Projekt stets in einem definierten Rahmen gehalten werden. Neben den Faktoren Zeit und Qualität ist gerade der Kostenfaktor einer der wesentlichen Aspekte, an welchen ein Projekt gemessen wird. Da ein Großteil der Projektkosten aus Personalkosten besteht, kann die Kostenschätzung durch die bereits für das Terminziel erstellte Aufwandsschätzung erfolgen. Ebenso sind jedoch auch alle weiteren für das Projekt anfallenden Kosten zu erfassen, welche sich aus der Projektplanung ergeben haben. Während der Überwachung des Projekts müssen Planabweichungen analysiert und die neue Kostensituation erneut hochgerechnet werden.

Der Qualitätsfaktor

Es sei vorerst darauf hingewiesen, dass der Begriff Qualität subjektiv ist und es demnach keine allumfassende Definition dieses Begriffs geben kann. In Anlehnung an die ISO-Richtlinien zum Qualitätsmanagement könnte man an dieser Stelle jedoch Qualität als Erfüllung von Anforderungen beschreiben.^[22] Im Rahmen der Anforderungsanalyse und im erstellten Pflichtenheft werden die Anforderungen an das System festgehalten, die es zu erfüllen gilt. Hierbei ist es sehr wichtig, die Anforderungen widerspruchsfrei, vollständig und überprüfbar zu dokumentieren. Die Erfüllung der Anforderungen ist durch regelmäßige Reviews und Tests zu gewährleisten.

Die Wechselwirkungen

Nun wird dargestellt, ich welcher Weise sich die eben angesprochenen Faktoren gegenseitig beeinflussen können.

Angenommen, ein Projekt muss früher als geplant fertiggestellt werden, beispielsweise wegen einer wichtigen Messe, so geht dies immer zu Lasten der Kosten oder der Qualität, da entweder mehr Personal eingesetzt werden muss, was ebenso den Koordinationsaufwand innerhalb des Projekts erhöht, oder nicht alle Anforderungen umgesetzt werden können. Ebenso denkbar wäre eine festgestellte Planabweichung während des Projekts, was die selben Folgen hätte.

Auch ist es denkbar, und in der Praxis auch oft vorzufinden, dass Anforderungen nicht genau definiert wurden und zu einem späteren Zeitpunkt im Projekt neue Funktionalitäten implementiert werden sollen oder vorhandene angepasst werden müssen. Um das Terminziel einhalten zu können, müssen in diesem Fall zusätzliche Ressourcen bereitgestellt werden, andernfalls verschiebt sich der Fertigstellungszeitpunkt nach hinten.

Ob ein Projekt überhaupt durchführbar ist, wird sehr stark durch das zur Verfügung stehende Budget entschieden. Würde im Falle eines Liquiditätsengpasses während des Projekts das Budget gekürzt, müssten entweder Mitarbeiter aus dem Projekt abgezogen werden, was wiederum das Terminziel gefährdet, oder es muss auf die Erfüllung bestimmter Anforderungen verzichtet werden, was wie schon beschrieben den Qualitätsfaktor negativ beeinflussen würde.

3.1.6 Erfolgsfaktoren und Gründe für das Scheitern von Projekten

Bereits im vorausgegangenen Abschnitt wird deutlich, dass das Erreichen aller Projektziele sehr schwer ist. In diesem Abschnitt sollen nun konkrete Gründe für das Scheitern von Projekten aufgezeigt werden, die in der Literatur zu finden sind. Ebenso werden anschließend die wichtigsten Faktoren für erfolgreich abgeschlossene Projekte genannt.

Hindel et al nennen unter Herannahme einer Studie aus den USA folgende Faktoren für den Misserfolg von Projekten:^[23]

- Unvollständige/ungenaue Anforderungen: 13,1%
- Mangelnde Einbeziehung der Beteiligten: 12,4%
- Ressourcenmangel: 10,6%
- Unrealistische Erwartungen: 9,9%
- Mangelnde Unterstützung vom Management: 9,3%
- Sich häufig ändernde Anforderungen: 8,7%
- Mangelhafte Planung: 8,1%
- Wird nicht mehr benötigt: 7,5%
- Mangelndes IT-Management: 6,2%
- Mangelndes Technologiewissen: 4,3%

Hindel et al weisen darauf hin, dass unter „Mangelnde Einbeziehung der Beteiligten“ insbesondere das Umfeld der Projektkommunikation verstanden werden kann und stellen mangelndes Anforderungsmanagement als den „ Misserfolgsfaktor schlechthin für Softwareprojekte “ dar.

Diese These wird bestätigt durch Hofmann und Lehner, welche ebenfalls die Relevanz der Kommunikation herausstellen:

„ Teams often struggle with fluctuating requirements, communication breakdowns, and difficulties in prioritizing requirements. RE goes through recurrent cycles of exploring the perceived problem, proposing improved specifications, and validating and verifying those specifications. It is a learning, communication, and negotiation process; to succeed, you must integrate your technical, cognitive, social, and organizational processes to suit your project’s particular needs and characteristics.”^[24]

Als Erfolgsfaktoren für Projekte führen Hindel et al folgendes an:^[25]

- Geeignete Unternehmensorganisation für die Projektabwicklung
- Hoher Stellenwert von Projektleitung im Unternehmen
- Definierte Entwicklungsprozesse, die auch angewendet werden
- Verfügbarkeit von Ressourcen
- Qualifikation der Mitarbeiter
- Funktionierendes Qualitätsmanagement
- Kommunikationsprobleme meistern
- Verteilte Entwicklung beherrschen

Die Kritikalität der Faktoren Kommunikation, Koordination, Kooperation wurde hier nochmals herausgestellt, was stark darauf hindeutet, dass Wikis im Projektmanagement nutzenbringend eingesetzt werden könnten. Diese Argumentation wird später im Abschnitt 3.3 Wikis fortgeführt und genauer erläutert.

[...]

^[1] http://www.ac-b.de

^[2] http://www.pmqs.de

^[3] Vgl. Leuf/Cunningham 2005, S. 35

^[4] http://www.google.com

^[5] http://www.gartner.com, Aus http://www.groupereflect.net/

^[6] Kitz 2004, S. 212

^[7] Madauss 2000, S. 538

^[8] DIN 1994

^[9] Kitz 2004, S. 212

^[10] DIN 1994

^[11] Hindel et al 2006, S. 8

^[12] Vgl. Schönert 2002, S. 37 ff

^[13] Vgl. Hindel et al 2006, S. 202 ff

^[14] Vgl. Schindler 2002, S. 64 f

^[15] Schönert 2002, S. 25

^[16] Vgl. Hindel et al 2006, S. 6

^[17] Vgl. Kitz 2004, S. 49 ff

^[18] Vgl. Teufel et al 1995

^[19] Vgl. Hindel et al 2006, S. 6 f

^[20] Vgl. Kitz 2004, S. 27 ff

^[21] Anm.: Die von Kitz vorgenommene Trennung zwischen Sach- und Qualitätsziel wird hier aufgehoben und beide Faktoren zusammen als Qualitätsfaktor erläutert.

^[22] Vgl. EN ISO 9000:2005

^[23] Hindel et al 2006, S. 4

^[24] Hofmann / Lehner 2001, S. 66

^[25] Hindel et al 2006, S. 7