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

Diplomarbeit von Markus Böttger

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 is not completed on schedule, or the project functionality is incomplete’.

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.

Die Abbildung 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. Cunningham entwarf das erste Wiki bereits im Jahr 1994. Die folgende Grafik 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.

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.

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.

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.

Gang der Untersuchung:

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.

Inhaltsverzeichnis:

1.	Einleitung	1
1.1	Ziel	3
1.2	Aufbau	4
2.	Problemstellung	5
3.	Theoretische Grundlagen	7
3.1	Projektmanagement	7
3.1.1	Begriffsdefinitionen	7
3.1.2	Die Formen der Projektorganisation	8
3.1.3	Die Phasen eines Projekts	10
3.1.4	Aufgaben des Projektmanagements	11
3.1.5	Die Faktoren Zeit, Kosten und Qualität	12
3.1.6	Erfolgsfaktoren und Gründe für das Scheitern von Projekten	14
3.2	Software Engineering	15
3.2.1	Begriffsdefinition	16
3.2.2	Charakteristika von Software	17
3.2.3	Das Phasenmodell im Software Engineering	18
3.3	Wikis	20
3.3.1	Begriffsdefinition	20
3.3.2	Grundlagen	21
3.3.3	CSCW und das 3K-Modell	22
3.3.4	Anwendungsgebiete	24
4.	Methodik	25
4.1	Analysephase	25
4.2	Implementierungsphase	26
4.3	Testphase	27
5.	Ergebnisse	28
5.1	Anforderungen	28
5.1.1	Anforderungen aus der Literatur	28
5.1.2	Betriebliche Anforderungen	31
5.1.3	Priorisierung	31
5.1.4	Anforderungsspezifikation	34
5.2	Konzept	39
5.2.1	Erfolgsfaktoren	39
5.2.2	Wiki für das Wissensmanagement	40
5.2.3	Wiki für das Dokumentenmanagement	40
5.2.4	Wiki für das Projektmanagement	41
5.3	Auswahlprozess	42
5.3.1	Beschreibung der Alternativen	43
5.3.2	Nutzwertanalyse	44
5.4	Pilotversion	46
5.4.1	Implementierung	46
5.4.2	Test Cases	48
5.5	Szenario	51
5.5.1	Vorbereitungen	51
5.5.2	Durchführung	52
5.5.3	Auswertung	52
6.	Resumée	54
	Quellenverzeichnis	56
	Anhang	59

Textprobe:

Kapitel 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.

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.

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’.

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’.

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’.

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’.

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

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, ,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 Funktion. 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.