Entwicklung eines Vorgehensmodells zur Einführung von kollaborativem Projektmanagement in KMUs

Aus Winfwiki

Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Düsseldorf
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie / Wissenschaftliches Arbeiten
Betreuer:	Prof._Dr._Uwe_Kern
Typ:	Fallstudienarbeit
Themengebiet:	Kollaboratives Projektmanagement
Autor(en):	Dennis Schneider, Stephan Hotzy, Daniel Wittrock, Florian Horst
Studienzeitmodell:	Tagesstudium
Semesterbezeichnung:
Studiensemester:	2
Bearbeitungsstatus:	begutachtet
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis 1 Inhaltverzeichnis 2 Abkürzungsverzeichnis 3 Abbildungsverzeichnis 4 Einführung 5 Grundlagen 5.1 Allgemeines 5.2 Definition 6 Grundsätzliche Vorgehensmodelle 6.1 Definition eines Vorgehensmodells 6.2 Allgemeine Vorgehensmodelle 6.2.1 Wasserfallmodell[8] 6.2.1.1 Definition 6.2.1.2 Eigenschaften 6.2.1.3 Vorteile 6.2.1.4 Nachteile 6.2.2 V-Modell 6.2.2.1 Defintion[9] 6.2.2.2 Eigenschaften[12] 6.2.2.3 Vorteile[13] 6.2.2.4 Nachteile[14] 6.2.3 Spiralmodell 6.2.3.1 Definition 6.2.3.2 Eigenschaften[18] 6.2.3.3 Vorteile[20] 6.2.3.4 Nachteile[21] 6.2.4 Rational Unified Process 6.2.4.1 Definition 6.2.4.2 Eigenschaften 6.2.4.3 Vorteile[31] 6.2.4.4 Nachteile[32] 6.2.5 Extreme Programming 6.2.5.1 Definition 6.2.5.2 Eigenschaften[35] 6.2.5.3 Vorteile[36] 6.2.5.4 Nachteile[37] 7 Entwicklung eines Vorgehensmodells 7.1 Elemente eines Vorgehensmodells 7.1.1 Organisation[38] 7.1.1.1 Einliniensystem 7.1.1.2 Mehrliniensystem 7.1.1.3 Stabstellensystem 7.1.1.4 Matrixorganisation 7.1.1.5 Netzplan 7.1.2 Technik (IT Infrastruktur) 7.1.2.1 Allgemein 7.1.2.2 EAI[40] 7.1.2.3 SOA 7.1.2.4 ERP II[47][48] 7.1.2.5 PDM[49][50] 7.1.3 Rechtliche Aspekte (Datensicherheit)[51][52] 7.1.3.1 Bundesdatenschutzgesetz[53] 7.1.3.2 Telekommunikationsgesetz[54] 7.1.3.3 Telemediengesetz[55] 7.1.3.4 Handelsgesetzbuch[56] 7.1.3.5 Bundesamt für Sicherheit in der Informationstechnik[57] 7.2 Vorgehensweise 7.2.1 Vor der Implementierung: Auswahl und Analyse der Tools 7.2.2 Implementierung 7.2.2.1 Wie erfolgt die Einführung? 7.2.2.1.1 Vor- und Nachteile von Taskforces 7.2.2.1.2 Schulung von Mitarbeitern 7.2.3 Controlling 7.2.3.1 Konfliktmanagement[63][64][65][66][67] 7.2.3.2 Evaluierung[69] 7.2.3.3 Qualitätsmanagement[70][71] 7.2.3.4 Qualitätsmanagementmethoden 7.2.3.4.1 Balanced Score Card[72] 7.2.3.4.2 Total Quality Management[73] 7.2.3.4.3 FMEA[74] 8 Fazit 9 Fußnoten 10 Literatur- und Quellenverzeichnis 10.1 Buchquellen 10.2 Internetquellen 10.2.1 Grundlagen Allgemein + Definition 10.2.2 Organisation 10.2.3 Technik (IT- Infrastruktur) 10.2.4 grundsätzliche Vorgehensmodelle 10.2.4.1 Wasserfallmodell 10.2.4.2 V-Modell 10.2.4.3 Spiralmodell 10.2.4.4 RUP 10.2.4.5 XP 10.2.5 Datensicherheit 10.2.5.1 Bundesdatenschutzgesetz 10.2.5.2 Telekommunikationsgesetz 10.2.5.3 Telemediengesetz 10.2.5.4 Handelsgesetzbuch 10.2.5.5 Bundesamt für Sicherheit in der Informationstechnik 10.2.6 Evaluierung 10.2.7 Konfliktmanagement 10.2.8 Qualitätsmanagement 10.2.9 Qualitätsmanagementmethoden 10.2.9.1 Balanced Score Card 10.2.9.2 TQM – Total Quality Management 10.2.9.3 FMEA

1 Inhaltverzeichnis

2 Abkürzungsverzeichnis

Abkürzung	Bedeutung
EAI	Enterprise Application Integration
ERP	Enterprise Ressource Planning
IT	Informationstechnik
KMU	Klein- und Mittelstandsunternehmen
PDM	Produktdatenmanagement
RUP	Rational Unified Process
SOA	Service Oriented Architecture
XP	Extreme Programming
BSI	Bundesamt für Sicherheit in der Informationstechnik
FMEA	Fehlermöglichkeits- und Einflussanalyse

3 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	Wasserfallmodell
2	V-Modell
3	Spiralmodell
4	RUP
5	Extreme Programming
6	Einlinienorganigramm
7	Mehrlinienorganigramm
8	Stabstellenorganigramm
9	Matrixorganigramm
10	Netzplan
11	Übersicht IT- Infrstruktur
12	Point-to-Point
13	Hub & Spoke
14	Bus / Pipeline / Publish & Subscribe
15	Verzahnung
16	Kreislauf Konfliktmanagement
17	Struktur
18	Funktionale Struktur
19	Produktlinienstruktur
20	Taskforce

4 Einführung

In Zeiten von verschiedenen sozialen Netzwerken und Foto- und Videoplattformen wird auch der Aspekt der Zusammenarbeit an einem Dokument und einer strukturierten Kommunikation in die Idee eines kollaborativen Projektmanagements transportiert und verwirklicht. Da diese Art von Vernetzung auch für kleinere und mittlere Unternehmen von entscheidender Wichtigkeit sein kann, müssen viele Faktoen dabei beachtet werden.

Die Einführung von einem kollaborativen Projektmanagement muss geplant, daraufhin strukturiert und organisiert durchgeführt werden. In dieser Fallstudie werden wir gängige Vorgehensmodelle, häufige Unternehmensstrukturen und ihre Vor-und Nachteile beschreiben, die Anforderung eines solchen Projektes an die Informationstechnik erläutern um daraus die Qualitätssicherung und ein ausführliches Fazit abzuleiten.

5 Grundlagen

5.1 Allgemeines

Projektarbeit gilt heute in den meisten Organisationen als Routinetätigkeit. Dabei nimmt der Anteil der unternehmensübergreifenden Projekte stets zu. Klärung und Steuerung der Projektziele bekommen deshalb eine hohe Bedeutung. Die Zielvereinbarung bzw. -steuerung gestaltet sich aber aufgrund unterschiedlicher Kulturen und Erwartungshaltungen bei unternehmensübergreifenden Projekten schwieriger. Um Prozesse und Zusammenarbeit zu verbessern, ist es wichtig, dass die Unternehmen nach Modellen vorgehen. Die Vorteile liegen in einer erhöhten Transparenz der Ziele, der verbesserten Zusammenarbeit und in der Vereinbarung verbindlicher Spielregeln. ^[1]

Kollaborative Projekte haben bestimmte Merkmale, wie Kooperation der betroffenen Unternehmen, Kommunikation und unternehmensübergreifende Koordination. Damit die Projekte gemeinsam durchgeführt werden können, bedarf es Flexibilität und gewisser Rahmenbedingungen, in denen Ziele, Prozesse und das Management festgelegt werden.

Ziel dieser Arbeit ist es, ein Modell zu entwickeln, an das sich kleine und mittelständische Unternehmen anlehnen können um kollaboratives Projektmanagement einzuführen.

5.2 Definition

Kollaboration (Collaboration):

Cassell's Dictionary, 1978: collaborate, v.i. mitwirken, mitarbeiten, zusammenarbeiten; (Pol.) mit dem Feind zusammenarbeiten. collaboration, s. die Mitwirkung, Mitarbeit, Zusammenarbeit; (Pol.) Kollaboration; in - with, gemeinsam mit. collaborator, s. der Mitarbeiter, Mitwirkende(r); (Pol.) Kollaborator, Kollaborateur.

Heute:

„Zusammenarbeit eines Unternehmens mit seinen Kunden und Lieferanten unter Einsatz von modernen Informationstechnologien zur Integration von unternehmensinternen und unternehmensübergreifenden Geschäftsprozessen.“^[2]

Möglichkeiten der Zusammenarbeit:^[3]

• Bereiche eines Unternehmens -> Intra-Company Collaboration
• Bereiche verschiedener Unternehmen -> Inter-Company Collaboration
• Zusammenarbeit entlang der Wertschöpfungskette
• Zusammenarbeit auf einer Stufe der Wertschöpfungskette
• National
• International

Projektmanagement:

„Projektmanagement wird als Managementaufgabe gegliedert in Projektdefinition, Projektdurchführung und Projektabschluss. Ziel ist, dass Projekte richtig geplant und gesteuert werden, dass die Risiken begrenzt, Chancen genutzt und Projektziele qualitativ, termingerecht und im Kostenrahmen erreicht werden.“^[4]

6 Grundsätzliche Vorgehensmodelle

6.1 Definition eines Vorgehensmodells

Folgende Punkte kennzeichnen ein Vorgehensmodell^[5]:

• Ein Vorgehensmodell definiert wie Projekte gleicher Art ablaufen.
• Ein Vorgehensmodell benennt die an einem Projekt beteiligten Personen und deren Aufgaben.
• Ein Vorgehensmodell stellt Methoden zur Verfügung, die bei der Bewältigung der gestellten Aufgaben benutzt werden.

Folgende Punkte werden durch die Auswahl eines Vorgehensmodells festgelegt^[6]:

• durchzuführende Aktivitäten
• Reihenfolge des Arbeitsablaufs (Entwicklungsstufen, Phasen)
• Definition der Teilprodukte / Ergebnisse (Inhalt, Layout)
• Fertigstellungskriterien (Zielvereinbarungen)
• Verantwortlichkeiten und Kompetenzen
• notwendige Mitarbeiterqualifikationen
• anzuwendende Standards, Richtlinien, Methoden und Werkzeuge

Eine Unterform der Vorgehensmodelle sind Phasenmodelle. Deren Besonderheit besteht darin, dass sie das Vorgehen während eines Projektes explizit in einzelne Phasen unterteilen.

Warum überhaupt Vorgehensmodelle im Projektmanagement einsetzen?^[7]

• Ziel ist die Kontrolle von Zeit, Budget und Qualität der Ergebnisse
• Planbarkeit von Softwareprojekten durch definierte, strukturierte und standardisierte Vorgehensweise
• Optimierung des Entwicklungsprozesses
• Verbesserung der Kommunikation innerhalb des Projekts und nach außen
• Automatisierungsmöglichkeiten durch Werkzeuge

6.2 Allgemeine Vorgehensmodelle

6.2.1 Wasserfallmodell^[8]

6.2.1.1 Definition

Als Wasserfallmodell wird in der Informationstechnologie ein lineares (nicht iteratives) Vorgehensmodell bezeichnet. Dieses Modell kommt zumeist in der Softwareentwicklung zur Anwendung, da eine Softwareentwicklung Schritt für Schritt vonstatten geht. Das Ergebnis der vorangegangenen Phase dient immer als bindende Vorgabe für die Ausführung der nächsten Phase.

Jede Phase im Wasserfallmodell besitzt vordefinierte Start- und Endpunkte sowie klare Zielvorgaben. Sogenannte Meilensteinsitzungen zum Ende einer jeweiligen Phase geben einen Rückblick auf das bereits Erreichte und dienen zur Nachbesprechung. Als die wichtigsten Dokumente gelten das Lasten- und das Pflichtenheft.

Heutzutage existieren mehrere Varianten vom traditionellen Wasserfallmodell. Nach wie vor gilt das Wasserfallmodell aber als das am weitesten verbreitete Modell.

Die Phasen des Wasserfallmodells im Überblick:

1. Anforderungsanalyse und -spezifikation (engl. Requirement analysis and specification)
2. Systemdesign und -spezifikation (engl. System design and specification)
3. Programmierung und Modultests (engl. Coding and module testing)
4. Integrations- und Systemtest (engl. Integration and system testing)
5. Auslieferung, Einsatz und Wartung (engl. Delivery, deployment and maintenance)

6.2.1.2 Eigenschaften

• Aktivitäten sind in der vorgegebenen Reihenfolge und in der vollen Breite vollständig durchzuführen.
• Am Ende jeder Aktivität steht ein fertiggestelltes Dokument, d.h. das Wasserfall-Modell ist ein „dokument-getriebenes“ Modell.
• Der Entwicklungsablauf ist sequenziell, d.h. jede Aktivität muss beendet sein, bevor die nächste anfängt.
• Es orientiert sich am sogenannten Top-Down-Verfahren.
• Es ist einfach, verständlich und benötigt nur wenig Managementaufwand.
• Eine Benutzerbeteiligung ist nur in der Anfangsphase vorgesehen, anschließend erfolgen der Entwurf und die Implementierung ohne Beteiligung des Benutzers bzw. Auftraggebers. Weitere Änderungen stellen danach Neuaufträge dar.

6.2.1.3 Vorteile

• klare Abgrenzung der Phasen
• einfache Möglichkeiten der Planung und Kontrolle
• bei stabilen Anforderungen und klarer Abschätzung von Kosten und Umfang sehr effektives Modell

6.2.1.4 Nachteile

• Abgrenzungsproblem
  • Die klare Abgrenzung von Phasen ist in der Realität nicht gegeben. Dies funktioniert nur in einer Modellumgebung. Tatsächlich findet ein Übergang zwischen den einzelnen Phasen fließend und kontinuierlich statt.
• Abfolgeproblem
  • In der Theorie laufen die Phasen nacheinander ab, in der Praxis ist aber oft ein Rückschritt notwendig, da in der vorangegangenen Phase Probleme aufgetreten sind, die vor Fortführung des Projektes erst noch behoben werden müssen.
• Das Modell ist nur auf einfache Projekte anwendbar
• Unflexibel gegenüber Änderungen und im Vorgehen (sequenzielle Abarbeitung der einzelnen Phasen)
• Fixierung der Anforderungen vor dem Projektstart kann im Projektprozess eventuell teure Änderungen mit sich bringen
• Fehler werden unter Umständen erst spät erkannt (da keine Prozessprüfung stattfindet) und müssen mit erhöhtem Aufwand entfernt werden

6.2.2 V-Modell

6.2.2.1 Defintion^[9]

Anfang der 90er Jahre erfolgte die Weiterentwicklung des Wasserfallmodells hin zum V-Modell. Ziel war es den Software-Lebenszyklus im Projektablauf mit zu berücksichtigen. Ebenfalls wird die Qualitätssicherung mit einbezogen.

Ablauf Software-Lebenszyklus:

1. Anforderungen
2. Analyse
3. Entwurf (Design)
4. Implementierung
5. Teststellung
6. Inbetriebnahme
7. Wartung

Die Idee des v-förmigen Vorgehens stammt aus dem Jahre 1979 und wurde von Barry Boehm entwickelt. 1986 entwickelt in Deutschland wurde das V-Modell für IT-Projekte der öffentlichen Hand vorgesehen, inzwischen findet es aber auch Anwendung in der Privatwirtschaft^[10].

Verifikation und Validation der Teilprodukte sind wesentlich Bestandteile des V-Modells^[11].

• Verifikation
  • Überprüfung der Übereinstimmung zwischen einem Software-Produkt und seiner Spezifikation - „Wird ein korrektes Produkt entwickelt?“
• Validation
  • Eignung bzw. der Wert eines Produktes bezogen auf seinen Einsatzzweck - „Wird das richtige Produkt entwickelt?“

6.2.2.2 Eigenschaften^[12]

• Durchführung von Projekten gemäß der Norm ISO 9001
• enthält Informationen über den Projektablauf
• Regelt welche Ausgangsprodukte von einer Aktivität erzeugt werden und welche nachfolgenden Aktivitäten dieses Produkt als Eingänge benötigt.
• Der inhaltliche Produktfluss ermöglicht die Ableitung einer zeitlichen Abfolge aller Aktivitäten.
  • Diese Eigenschaft dient als Schlüssel zur maschinellen Steuerung von IT-Projekten im Sinne eines Workflows
• nicht herstellerspezifisch (ausgewogene Sichtweise und keine firmenspezifische Vorgehensweise)
  • Eine jährlich tagende Änderungskonferenz mit Industrie- und Behördenvertretern kontrolliert die Einhaltung der Normen.
• Recht zur Anwendung durch die öffentliche Hand freigegeben (Public Domain).
• Einsatz ohne Lizenzgebühren

6.2.2.3 Vorteile^[13]

• gemeinsames Verständnis und eine Bezugsbasis für alle
• Reduzierung der Einarbeitungs- und Schulungszeiten (einmal gelerntes kann immer wieder eingesetzt werden)
• bessere Kalkulation von neuen Projekten(aufgrund von Erfahrungswerten)
• Projekte werden planbarer
• bessere Termintreue (Einhaltung von Terminen)
• Abhängigkeit von den Eigenheiten der Projektdurchführung einzelner Personen wird geringer
• Abhängigkeit von externen Firmen wird geringer
• klares Rollenkonzept
• verbesserte Produktqualität
• Wartungsaufwand verringert sich
• Überscheidungsfreiheit
• Angebote sind besser vergleichbar
• unmittelbar einsetzbar (ISO 9001-Zertifizierung)

6.2.2.4 Nachteile^[14]

• grundsätzliche Schwächen der strikten Phaseneinteilung bleiben erhalten
• zu starke Reglementierung und Papierflut
• großes Volumen verursacht bei Anwendung Mehraufwand

6.2.3 Spiralmodell

6.2.3.1 Definition

„Ziel ist es, durch eine mehrfache Wiederholung der gleichen Schrittfolgen ein immer weiter verfeinertes Produkt (Prototypen) zu entwickeln, anschließend zu überprüfen und in jedem weiteren Durchlauf zu verfeinern.“^[15]

Das sogenannte Spiralmodell oder "Boehm Spiral Model" geht auf zwei Publikationen von Barry Boehm zurück ^[16].

Das Spiralmodell beschreibt als eines der ersten Vorgehensmodelle den iterativ-inkrementellen Entwicklungsprozess von Software. Jeder Umlauf des Spiralmodells entspricht dem kompletten Durchlauf des Wasserfallmodells. Durch die mehrfachen Umläufe ist das Risiko der Zielverfehlung minimiert^[17].

6.2.3.2 Eigenschaften^[18]

Boehm teilt sein Spiralmodell in vier unterschiedliche Quadranten auf (Grafik anbei):

1. Zielbestimmung

• Voraussetzungen schaffen
• Beachtung und Berücksichtigung der Randbedingungen
• Analyse des bestehenden Systems
• Entwickung und Beschreibung von Lösungsansätzen

2. Risikoanalyse

• Bewertung der Lösungsalternativen
• Risikomanagement
• Ggf. Entwurf des ersten Prototyps

3. Entwicklung und Teststellung

• Requirements Engineering
• Beschreibung der Anforderungen
• Beschreibung der verwendeten Software-Architektur
• Detail-Entwurf
• Konstruktion
• Realisierung und Überprüfung der Spezifikation
• Qualitätssicherung

4. Planung der nächsten Zyklen (Überprüfung der Ergebnisse aus Schritt 1 bis 3)

Folgende Unterschiede bestehen im Vergleich zum Wasserfallmodell^[19]:

• Einbeziehung neuer Anforderungen nach jedem Spiraldurchlauf
• mehrfache Wiederholung des gesamten Prozesses
• neuer Prototyp dient nach jedem Durchlauf als Basis zur Risikominierung
• zeitaufwänderiges Management
• stärkeren Fokus auf den Risikofaktor

6.2.3.3 Vorteile^[20]

• Man bekommt permanentes Feedback – auf Moving Targets (dt.: bewegliche Ziele) kann reagiert werden
• Man kann pro Zyklus, wenn man möchte ein anderes Prozess- und Teammodell wählen
• Fehler werden relativ schnell erkannt
• Man hat bessere Eingriffsmöglichkeiten als beim Wasserfall-Modell

6.2.3.4 Nachteile^[21]

• Man braucht für das Spiralmodell ein besseres Management
• Für kleine Projekte viel Aufwand (lohnt sich erst bei größeren Projekten)

6.2.4 Rational Unified Process

6.2.4.1 Definition

RUP ist ein Software Engineering Prozess. Es dient dazu Probleme in der Softwareentwicklung anzugehen und zu lösen. RUP wurde durch die Firma IBM entwickelt und ist damit ein kommerzielles Produkt^[22].

„Der Rational Unified Process ist ein für die Nutzung der Modellierungssprache UML beschriebenes Vorgehensmodell / Phasenmodell für die Anwendungsentwicklung. Der Rational Unified Process (RUP-Modell) ist als Software Engineering Vorgehensmodell selbst in der UML beschriebenen. Das RUP-Modell ist als Sammlung von Best Practices im IBM Rational Method Composer umgesetzt.“^[23]

6.2.4.2 Eigenschaften

RUP zeichnet sich durch folgende Eigenschaften aus^[24]:

• die iterative Softwareentwicklung inklusive der Modellierung der Geschäftsprozesse steht im Vordergrund
• ein integriertes Anforderungsmanagement
• auf Komponenten basierte Architekturen
• visuelle Software-Modellierung
• verifizierbare Software-Qualität
• ein kontrolliertes Change-Management

RUP teilt das Projekt in vier Phasen^[25]:

1. Inception Phase (Projektsetup, Konzepterstellung)
2. Elaboration Phase (Ausarbeitung, Entwurf)
3. Construction Phase (Implementierung)
4. Transition Phase (Übertragung, Inbetriebnahme)

RUP definiert Workflows für insgesamt neun Aufgaben (Disciplines), welche sich in sechs Kernarbeitsschritte und drei unterstützende Arbeitsschritte aufteilen:

Kernarbeitsschritte^[26][27]

1. Geschäftsprozessmodellierung (engl: Business Modeling)
2. Anforderungsanalyse (engl: Requirements)
3. Analyse & Design (engl: Analysis & Design)
4. Implementierung (engl: Implementation)
5. Test (engl: Test)
6. Auslieferung (engl: Deployment)

Unterstützende Arbeitsschritte^[28][29]

1. Konfigurations- und Änderungsmanagement (engl: Configuration & Change Management)
2. Projektmanagement (engl: Project Management)
3. Infrastruktur (engl: Environment)

Abgrenzung zwischen Wasserfall-Modell und RUP^[30]:

• Wasserfall-Modell basiert auf einzelne, abgegrenzte Phasen (unrealistisch)
• Dem Wasserfall-Modell liegt ein klares Ablaufschemata zugrunde (unrealistisch)

6.2.4.3 Vorteile^[31]

• Risikofaktoren können schnell erkannt werden.
  • Durch iteratives Vorgehen wird risikobasierte Vorgehensweise gut unterstützt. Dadurch, dass teilweise parallel vorgegangen wird, werden Fehler schnell erkannt und können ausgebessert werden.
• Aktualität
  • RUP wird ständig aktualisiert (kommerzielles Produkt)
  • Berücksichtigung der neusten Erkenntnisse
• Abstimmung der Komponenten zur Entwicklungszeit
  • Frühzeitige Abstimmung der Komponenten senkt das Risiko einer Fehlentwicklung und die Fehlerquote sinkt.
• Use Cases
  • Durch die Berücksichtigung von Use Cases können die Funktionen anwenderorientiert implementiert werden.
• UML als Basis
  • RUP basiert auf UML, damit ist sichergestellt, dass durch die weltweite Eindeutigkeit eine Kooperationsfähigkeit mit anderen Schnittstellen wie Unternehmen und Kunden gewährleistet ist.
• Support gewährleistet (durch IBM und andere User / Expertenforen)
• RUP basiert auf mehreren Vorgehensweisen
  • Die 6 "Best Practices" sind ein Destillat, aus den Erfahrungen vieler Projekte. Der RUP ist also in der Praxis verwurzelt.

6.2.4.4 Nachteile^[32]

• Phasenorientierung
  • Phasen- und Meilensteinkonzepte lassen sich für komponentenorientierte Softwareentwicklung nur schwer umsetzen.
• Keine integrierte Qualitätssicherung
• Iterationen
  • Sind nur in den einzelnen Phasen vorgesehen und somit nicht an die Bausteine gebunden. Es können nur Phasen oder ganze Zyklen wiederholt werden.
• Zentrierung der Architektur
  • Dabei aber wenig Rücksicht auf Baustein- und Ergebnisstruktur.
  • Einbezug der Systemstruktur und deren Bausteine fehlt.
• Komplexität
  • Das RUP-Modell ist sehr komplex und unterliegt noch einem kontinuierlichen Veränderungsprozess.

6.2.5 Extreme Programming

6.2.5.1 Definition

„Extreme Programming (XP) ist ein agiler Softwareentwicklungsprozess für kleine Teams. Der Prozess ermöglicht, langlebige Software zu erstellen und während der Entwicklung auf vage und sich rasch ändernde Anforderungen zu reagieren. XP-Projekte schaffen ab Tag eins Geschäftswert für den Kunden und lassen sich fortlaufend und außergewöhnlich stark durch den Kunden steuern.“^[33]

XP basiert auf folgenden Grundprinzipien^[34]:

• Kommunikation
• Einfachheit
• Feedback
• Mut
• Lernen
• Qualität
• Respekt

6.2.5.2 Eigenschaften^[35]

Schwerpunkte von XP sind:

• User Stories
  • Die Anforderungen an die zu erstellende Software werden nicht wie beim RUP in Use Cases, sondern in User Stories erfasst. User Stories beschreiben GUIs, Funktionalitäten und Testszenarien.
• On-site Customer
  • Ein Vertreter des Kunden ist während der gesamten Entwicklungszeit bei den Entwicklern anwesend.
• Pair Programming
  • An den Entwicklungsrechnern sitzen jeweils zwei Entwickler und entwickeln gemeinsam.
• Testing
  • Vor der Entwicklung eines Moduls werden automatisierbare Testfälle (Unit Tests) programmiert.
• Simple Design
  • Es werden keine unnötigen Features implementiert.
• Small Releases
  • Es werden häufige Iterationen durchgeführt mit lauffähigen Programmen als Ergebnis, welche der Kunde begutachtet.
• Refactoring
  • Der Sourcecode wird eher früh restrukturiert (falls erforderlich).
• Continuous Integration
  • Von verschiedenen Teammitgliedern produzierter Code wird sehr häufig zusammengeführt.
• Collective Ownership
  • Der entwickelte Sourcecode gehört dem gesamten Team, jeder ist für jeden Code verantwortlich. Die Teams rotieren zyklisch.
• Coding Standards
  • Es werden Konventionen zum Aufbau des Codes erstellt, um Lesbarkeit zu erleichtern.

6.2.5.3 Vorteile^[36]

• schnellere Software-Entwicklung
• Entwicklung von notwendigen Funktionen
  • Änderungen auch während des Projekts noch möglich
• einfache Software-Entwicklung (hohe Kommunikation mit dem Kunden)
• mehr Kommunikation im Projekt durch kürzere Iterationszyklen.
• Einfachheit in der Software-Entwicklung
  • mehr Verständnis durch den Kunden und dadurch bessere Einbindungsmöglichkeit des Kunden.
• erheblich geringere Kosten bei großen Software-Projekten
• höhere Qualität, Erweiterbarkeit und Nachhaltigkeit der Entwicklung

6.2.5.4 Nachteile^[37]

• Anwendung findet meist nicht in kleinen Firmen statt; lohnt sich erst in größerem Rahmen (Kosten-Nutzen-Rechnung)
• Projektverlauf vorher nicht festlegbar (dynamische Entwicklung)
• sehr hohe Anforderungen an die Qualität der Entwickler
• Kunden haben meist nicht ausreichend Zeit, um sich in das Projekt in der von XP geforderten Form einzubringen oder wollen das nicht.
• Programmierer werden schnell dazu verleitet Software sehr schnell fertigzustellen, ohne entsprechende Tests vor Implementierung.
• Kunden müssen Vertrauen in die Kompetenz und Kontinuität des technischen Partners haben.

7 Entwicklung eines Vorgehensmodells

7.1 Elemente eines Vorgehensmodells

7.1.1 Organisation^[38]

Die Einführung eines kollaborativen Projektmanagements orientiert sich an den Strukturen im Unternehmen und passt sich diesen an. Diese Strukturen sind aus zwei unterschiedlichen Perspektiven zu betrachten: Die Aufbauorganisation beschreibt die Kommunikationswege und Machverhältnisse im Unternehmen. Durch die dauerhafte Gültigkeit, ist dieser Ansatz ein statischer und wird in einem Organigramm dargestellt. Im Gegensatz dazu zeigt die Ablauforganisation die zeitliche Orientierung und das tatsächliche Zusammenwirken der Arbeitsprozesse. Dieser eher dynamische Aspekt wird häufig in einem Netzplan abgebildet. Es gibt verschiedene Möglichkeiten das Unternehmen in Aufbau und Ablauf zu organisieren: In der Aufbauorganisation gibt es das Einlinensystem, das Mehrliniensystem, das Stabstellensystem und die Matrix-Organisation.

7.1.1.1 Einliniensystem

Das Einliniensystem ist eine Top-Down-Struktur, bei der die Anweisungen und Ziele von der Geschäftsführung herunter bis zu den einzelnen Abteilungen gebrochen werden. Je mehr Ebenen zwischen der Führung und den Abteilungen abgebildet sind, desto schärfer ist die Hierarchie ausgerichtet und erfordert autoritäre Führungsmethoden. Die Abteilungen sind nach Verrichtungsart aufgeteilt, was bedeutet, dass jede Abteilung eine bestimmte Aufgabe im Unternehmen übernimmt. Als Beispiel für ein Einlinienorganigramm:

Bei dem Einliniensystem ergeben sich die folgenden Vorteile für das Unternehmen und die Mitarbeiter:

• Da die Leitung einheitlich ist, sind die Kommunikations- und Anordnungswege klar definiert
• Die Unternehmensstruktur ist klar und eindeutig erkennbar
• Mitarbeiter mit geringen Führungsqualitäten, können in untergebenen Stellen eingesetzt werden
• Erfolgreich bei aggressiven Makrtsituationen

Es ergeben sich dabei auch folgende Nachteile:

• Eine autoritäre Führung kann Mitarbeiter demotivieren
• Durch das zusammenlaufen der Informationskanäle kann die Führung überlastet werden
• Die Anforderung an die Führung ist sehr hoch. Bei schwachen Führungspersonen versagt das gesamte System
• Die Informationswege sind lang und dadurch bedarf es für Entscheidungen eine längere Zeit

7.1.1.2 Mehrliniensystem

Das Mehrliniensystem ist ebenfalls eine Top-Down-Struktur, bei der aber die Anweisung für die ausführenden Abteilungen nicht von einer vorgesetzten Stelle, sondern von mehreren kommt. Bei einem Unternehmen mit einer technischen und einer kaufmännischen Leitung ist das Mehrliniensystem empfehlenswert. Als Beispiel für ein Mehrlinienorganigramm: Aus dem Mehrliniensystem ergeben sich im Gegensatz zum vorherigen System folgende Vorteile:

• Der Aufbau des Unternehmens ist übersichtlich und einfach
• Die Anordnungswege sind kurz und das Unternehmen ist über die Vorgänge im Unternehmen informiert
• Für die Mitarbeiter entsteht ein unbürokratisches und schnelles System
• Durch die entstehende Demokratie, werden bestimmte Führungspersonen motiviert

Dabei entstehen auch folgende Nachteile:

• Sofern sich die Führungen nicht abstimmen, kommt es im gesamten Unternehmen zum Chaos
• Das Unternehmen ist alleine von den Leitungspersonen abhängig
• Es ist nicht geeignet, wenn die Marktposition durch Konkurrenz bedroht wird

7.1.1.3 Stabstellensystem

Das Stabstellensystem stellt für jede Instanz eine Stabstelle zur Verfügung, welche die Aufgabe hat, die Informationen zu sammeln und bereit zu stellen. Häufig gibt es nur Stabstellen in der Vorstandsebene um dieser den Aufwand für die Beschaffung und Ordnung von Informationen abzunehmen. Als Beispiel für ein Stabstellenorganigramm: Für das Stabliniensystem ergeben sich einige Vorteile:

• Durch das Einsetzen von Experten in den Stabstellen, die in Leistungsstellen versagt hätten werden die Informationen optimal genutzt
• Die eigentlichen Leitungsstellen werden entlasten und können sich besser auf die Entscheidungen konzentrieren
• Das eigentliche autoritäre Einliniensystem wird durch Stabstellen etwas aufgelockert

Die Nachteile des Stabliniensystem lauten wie folgt:

• Es besteht die Gefahr das nicht mehr zwischen dem Stab und der Führung unterschieden werden kann, wodurch ein Mehrliniensystem entsteht.
• Im Stab können die Informationen manipuliert werden wodurch die Experten indirekt das Unternehmen leiten können.
• Die Leitung missbraucht die Stabsstellen um mit den Mitarbeitern zu kommunizieren, wodurch die Entfernung wächst.

7.1.1.4 Matrixorganisation

Das Matrixsystem verfolgt einen anderen Ansatz und ist keine typische Top-Down Variante, da es für die ausführenden Abteilungen jeweils zwei zuständige Stellen gibt, die sich zum einen nach der Verrichtungsart und zum anderen nach den Produkten des Unternehmens zusammensetzten. Als Beispiel ein Matrixorganigramm:

Die Matrixorganisation bewährt sich in größeren Unternehmen durch die Vorteile:

• Eine zentrale Führung um ein Unternehmen mit vielen Produkten zu steuern
• Die Kreativität und Kenntnisse der Mitarbeiter werden besser genutzt

Dennoch ergeben sich folgende Nachteile:

• Durch eine uneinheitliche Leitung entstehen die Nachteile
• Es werden eine Menge von bürokratischen Vorgängen wie Besprechungen und Konferenzen eingesetzt, die viel Zeit in Anspruch nehmen
• Häufig entsteht dieses System bei schlecht geführten Einliniensystemen

7.1.1.5 Netzplan

Die Ablauforganisation beachtet vor allem die zeitlichen Komponenten bei den Arbeitsprozessen. Zur Planung dieser Abläufe dient ein Netzplan der folgendermaßen aufgebaut ist:

Es handelt sich um einen einzelnen Vorgang aus einem Netzplan. Die Felder des Vorgangs lassen sich wie folgt auflösen:

• FB = Frühester Beginn
• FE = Frühestes Ende
• Nr = Nummer des Vorgangs
• Bezeichnung = Name des Vorgangs
• D = Dauer des Vorgangs
• GP = Gesamtpuffer
• FP = Freier Puffer

Bei der Netzplantechnik wird, durch die logische Verkettung der verschiedenen Vorgänge ein Ablauf entstehen. Dabei wird die Dauer des Vorgans berücksichtigt und errechnet, wann der Nachfolgende Vorgang beginnen kann.

7.1.2 Technik (IT Infrastruktur)

7.1.2.1 Allgemein

Die IT ist als Unterstützung in Projekten nicht mehr wegzudenken, da Projekte immer komplexer und umfangreicher werden. Gerade wenn man das Merkmal räumliche Trennung betrachtet, ist das Zeitmanagement von großer Bedeutung, das nur mit Unterstützung moderner IT realisiert werden kann.

Das Hauptmerkmal ist aber ein anderes, denn in unternehmensübergreifenden Projekten kommen unterschiedliche IT- Architekturen zum Einsatz, die es heißt mit einander zu koppeln und zu integrieren. Da die Unternehmen aber immer wieder mit unterschiedlichen Partnern zusammenarbeiten, müssen diese Architekturen flexibel anpassbar sein um schnelle Zusammenarbeit zu ermöglichen.

Um Vorlaufzeiten und Anlaufkosten so vermeiden, bzw. so gering wie möglich zu halten, muss ein Unternehmen seine IT ad hoc an andere IT- Umgebungen anpassen können. So können die Projektteams innerhalb kürzester Zeit produktiv werden und die Vorteile der Zusammenarbeit werden nutzbar gemacht.

Damit es zu einer Implementierung der IT- Umgebung kommt und Daten bzw. Wissen unternehmensübergreifend verfügbar sind, bedarf es entsprechender IT- Systeme. Systeme, die in diesem Bereich zum Einsatz kommen sind Enterprise Application Integration (EAI) bzw. Service Oriented Architecture (SOA), Enterprise Ressource Planning II (ERPII) und Produktdaten- und Dokumentenmanagement Systeme (PDM).

Übersicht einer kollaborativen IT- Infrastruktur:

Da in kollaborativen Projekten unterschiedlichste Systeme zum Einsatz kommen und Zeitmanagement eine große Rolle spielt, ist neben der Verwendung von Kollaborationssoftware und angepasster IT- Architektur, die Standardisierung der verschiedenen verwendeten Dateienarten enorm wichtig.

Hier hat sich der ISO Standard 10303, STEP – Standard for the Exchange of Product Data, des Vereins ProSTEP iVip durchgesetzt. STEP ist ein internationaler Standard für den Datenaustausch zwischen den verschiedenen Anwendungssystemen. ProSTEP iVip stellt damit eine Methode für schnellen und sicheren Datenaustausch und gemeinsame Nutzung von Daten zwischen Partnern, die unterschiedliche Anwendungssysteme einsetzen, zur Verfügung. Deshalb ist STEP heute beim täglichen Umgang mit Produktdaten aus unterschiedlichen Unternehmen nicht mehr wegzudenken.^[39]

7.1.2.2 EAI^[40]

Mit Hilfe von EAI werden IT- Systeme unterschiedlicher IT- Infrastrukturen gekoppelt, dies ermöglicht hohe Flexibilität und leichte Erweiterbarkeit, außerdem lassen sich Prozesse und Abläufe einfach ändern.

Die Vorteile eines solchen Systems, auch Middleware, genannt liegen in den geringeren Kosten durch Automatismen und verkürzten Bearbeitungszeiten, sowie Datenkonsistenz durch redundant gespeicherte Daten. Außerdem vereinfacht EAI den Austausch einzelner Softwareprodukte, da die Kommunikation mit anderer Software über die zentrale EAI-Middleware verläuft und nur dort nur ein Adapter angepasst werden muss.

Das sich EAI flexibel in jede IT- Architektur einbinden lässt, erkennt man anhand der Einsatzmöglichkeit für folgende Integrationstopologien:

• Point-to-Point / Peer-to-Peer

• Hub and Spoke (Middleware)

• Bus / Pipeline / Publish & Subscribe

Eine EAI- Implementierung durchläuft 7 Phasen^[41]:

1. Geschäftsprozesse müssen dokumentiert werden
2. Anforderungsanalyse
3. Interaktionen
4. Detaillierung der Interaktionen
5. Schnittstellenspezifikation
6. Auswahl der EAI- Software
7. Architektur und Implementierung

7.1.2.3 SOA

„Eine Service-orientierte Architektur (SOA)ist ein Konzept, welche das Geschäft und die IT eines Unternehmens nach Diensten strukturiert, welche modular aufgebaut sind und flexibel zur Umsetzung von Geschäftsprozessen genutzt werden können.“^[42]

Das Hauptmerkmal einer SOA ist die Verzahnung von Geschäftsprozessen und IT, welche miteinander abgestimmt werden und enger zusammenarbeiten. Da die Marktanforderungen immer schneller wechseln und sich die Unternehmen entsprechend schnell darauf einstellen müssen, um ihre Wettbewerbsfähigkeit nicht einbüßen zu müssen, bedeutet dies, dass die IT- Architektur ebenso schnell angepasst werden muss. Insbesondere bei immer komplexer werdenden kollaborativen Projekten.^[43][44]

Die Verzahnung erfolgt nach dem Top-down Ansatz und fängt dementsprechend mit dem Geschäftsmodell an^[45].

Die SOA- Implementierung durchläuft 8 Phasen:

1. Geschäftsmodell definieren
2. Anforderungen an die Geschäftsprozesse, IT und Organisation ableiten
3. Geschäftsprozesse definieren
4. Business Services identifizieren
5. Bestehende Anwendungs- und IT-Landschaft analysieren
6. Verfügbare Services identifizieren
7. Angeforderte Service mit bestehenden Services abgleichen
8. Spezifizierung und Realisierung der Services planen

Vorteile bei der Einführung von SOA ergeben sich durch flexibel änderbare und transparentere Geschäftsprozesse, optimiertes Projektmanagement, Standardisierung und Qualitätsverbesserung.

Außerdem lassen sich mit Hilfe von SOA mittel- bis langfristige Kosteneinsparungen, auf Grund der schneller änderbaren Geschäftsprozesse, niedrigeren Projektkosten und reduzierten Wartungskosten, realisieren.^[46]

7.1.2.4 ERP II^[47][48]

Enterprise Ressource Planning II (ERPII) Systeme erweitern klassische ERP- Systeme um Funktionen zur Unterstützung unternehmensübergreifender Prozesse. Sie sollen die vorhandenen Ressourcen der zusammenarbeitenden Unternehmen effizient einsetzen und Prozesseoptimieren.

Diese Systeme gehören meist nicht mehr der unternehmenseigenen IT- Architektur an, sondern werden von Dienstleistern zur Verfügung gestellt. Der Zugriff auf Daten ist sowohl intern als auch extern möglich. Da flexible Systemstrukturen erforderlich sind, zeichnen sich ERP II Systeme durch ihre offene, Web- basierende Architektur und Plattformunabhängigkeit aus. Dadurch, dass diese Systeme von externen Dienstleistern zur Verfügung gestellt werden, werden die Kosten für Hardware und deren Instandhaltung bzw. Software und entsprechender Updates gespart.

ERP Systeme in Verbindung mit SOA / EAI- Architekturen bieten technische und betriebswirtschaftliche Integration und flexible Anpassung an wechselnde Prozess- und Informationsanforderungen.

7.1.2.5 PDM^[49][50]

Produktdaten- und Dokumentenmanagement-Systeme (PDM) stellen Produktdaten in Datenbanken zur Verfügung. Ihre Aufgabe liegt in der Speicherung, Verwaltung und Bereitstellung aller Produktdaten und Dokumente.

Gerade bei unternehmensübergreifenden Projekten ist die Synchronisation und gleichzeitige Verfügbarkeit von Informationen für zusammenarbeitende Unternehmen die Basis für erfolgreiche Projekte.

PDM- Lösungen ermöglichen eine Steigerung in der Qualität der Produktentwicklung, einheitliche Verwaltung kompletter Projektdokumentationen, einheitliche Bereitstellung von Produktdaten für alle Projektmitarbeiter und gemeinsame Verwaltung der projektbegleitenden Dokumente. Ziel ist ein durchgehender Informationsfluss und schneller Zugriff auf alle relevanten Projektdaten.

PDM Systeme nutzen moderne Datenbanken und beinhalten Schnittstellen zu ERP Systemen, somit ist eine einfache Integration in die IT- Architektur möglich.

7.1.3 Rechtliche Aspekte (Datensicherheit)^[51][52]

Generell gibt es für die IT bestimmte gesetzliche Richtlinien nach an denen sich u.a. die Prozesse und die Infrastruktur orientieren müssen. Da das kollaborative Projektmanagementsystem ein Teil der IT Systeme sein wird, sollten diese Richtlinien berücksichtigt werden. Ebenso ist der Inhalt, also die Projekte in diesem System zu schützen.

7.1.3.1 Bundesdatenschutzgesetz^[53]

Das Bundesdatenschutzgesetz hat, wie unter §1(Absatz1) beschrieben, folgende Aufgabe: „Zweck dieses Gesetzes ist es, den Einzelnen davor zu schützen, dass er durch den Umgang mit seinen personenbezogenen Daten in seinem Persönlichkeitsrecht beeinträchtigt wird.“ Für das kollaborative Projektmanagement hat das zur Folge, dass gewährleistet werden muss, dass es z.B. keine Auswertungen über das Arbeitsverhalten der Mitarbeitern an den Projekten gibt, wodurch ein Fehlverhalten aufgedeckt werden kann. Ein Beispiel währe eine Aufstellung über die Log-In-Zeiten des Mitarbeiters A in dem System, um herauszufinden, wie häufig er für das Projekt tätig ist. Ebenfalls dürfen nur befugte Zugang zu den personenbezogenen Daten haben.

7.1.3.2 Telekommunikationsgesetz^[54]

Das Telekommunikationsgesetz ist durch technologische Neuerungen, wie Voice-over-IP, ebenfalls auf die Netzwerkverbindungen der IT anzuwenden, wie bisher auf die separaten Telefonienetze. Besonders wichtig ist vorallem das Fernmeldegeheimnis, was im kollaborativen Projektmanagement von großer Bedeutung sein kann. Als Beispiel sind u.a. Projekte zu nennen, bei denen es sich um die Entwicklung neuer Produkte handelt.

7.1.3.3 Telemediengesetz^[55]

Geringere Anwendbarkeit auf das kollaborative Projektmanagement findet im Rahmen der IT, das Telemediengesetz, welches u.a. die Auskunftspflicht beinhaltet.

7.1.3.4 Handelsgesetzbuch^[56]

Im Handelsgesetzbuch wird die Speicherung von Handelsbüchern auf Datenträgern beschrieben und fordert dabei wie unter §249 Abs. 4 eine Sicherstellung der Verfügbarkeit aller relevanten Unterlagen. Darüber hinaus ist es notwendig, dass die Daten innerhalb der Aufbewahrungsfrist, zeitnah lesbar gemacht werden können.

7.1.3.5 Bundesamt für Sicherheit in der Informationstechnik^[57]

Bereits im Telekommunikationsgesetz, wurde die Notwendigkeit von IT-Sicherheit erwähnt. Ein Unternehmen kann großen Schaden rleiden, wenn die IT nicht ausreichend vor Angriffen von außen geschützt ist. Für diesen Zweck wurde im Jahr 1991 das Bundesamt für Sicherheit in der Informationstechnik gegründet. Im BSI Gesetz §3 heißt es zu den Aufgaben im Absatz 1: „Abwehr von Gefahren für die Sicherheit der Informationstechnik des Bundes“.

7.2 Vorgehensweise

7.2.1 Vor der Implementierung: Auswahl und Analyse der Tools

Welche Tools eDie Auswahl der Tools erfolgt nach dem Prinzip „angemessen“. Das bedeutet in erster Linie, dass Tools in die engere Auswahl kommen, die entweder schon lange existieren oder neu aber bereits vom Großteil der Unternehmen eingesetzt werden. Das Problem vieler Tools ist die Skalierbarkeit. Die Frage ist dabei, ab wann wird das Tool vollständig nutzbar sein oder decken sich die Kosten des Tools mit dessen Leistung? Aus dieser Fragestellung heraus werden 2 Tools analysiert. Diese sind

• Microsoft Share Point
• Google Wave

Beide werden seid längerem auf dem Markt Angeboten.

Microsoft Share Point Services ( MSSPS)^[58]

Dieses von Microsoft angebotene Tool ist bereits ab der Windows Server Version 2003 verfügbar. Die Aufgabe von MSSPS ist es, die Zusammenarbeit der Benutzer virtuell zu verknüpfen. Es liefert so die Funktionen zu einer Zusammenarbeit für Aufgabenlisten, Kalender, Dokumentenstämme und mehr.

Die Eigenschaften beschreiben sich wie folgt.

• Zentrale Datenablage: Informationen werden zentral und nach individuell vorgegebenen Strukturen in Listen abgelegt.
• Aktualität von Informationen: Änderungen erfolgen in der Regel in Echtzeit und stehen berechtigten Benutzern sofort zur Verfügung.
• Benachrichtigung: Benutzer können über Änderungen sofort, einmal täglich oder wöchentlich per E-Mail benachrichtigt werden.
• Suche: Es kann nach allen in SharePoint abgelegten Informationen gesucht werden.
• Integration: Listen sind in den korrespondierenden Microsoft Office-Anwendungen direkt verfügbar. Beispiel: alle Listen können in Excel und Access bearbeitet werden, Adresslisten sind als Kontaktlisten in Outlook verfügbar und Dokumentenbibliotheken (Dokumentenlisten) können als Ort zum Öffnen und Speichern von Dateien aus allen Microsoft Office-Anwendungen verwendet werden.
• Integration: Listen- und Dokumentenbibliotheken verfügen über Versionierung und Inhaltsfreigaben
• Workflow: Über das Produkt Microsoft SharePoint-Designer 2007 (frei verfügbar) können eigene Workflows erstellt werden

Merkmale

• Webbasierter Zugriff per Webbrowser insbesondere Internet Explorer. Weitere Browser wie Firefox ermöglichen einen Zugriff mit Einschränkungen.
• Strukturierung: Informationen können in Abhängigkeit zueinander hierarchisch gespeichert werden.
• Darstellung: Informationen können ganz oder auszugsweise nach vorgegebenen Kriterien (Filtern, Gruppierung) und bedarfsweise in gegenseitiger Abhängigkeit dargestellt werden.
• Freiheitsgrad: Benutzer können Listen erstellen, anpassen oder löschen. Benutzer können auch Administratoren sein und Berechtigungen einzeln und gruppenweise vergeben.
• Integration zu Microsoft Office: Windows SharePoint Services und Microsoft Office erweitern ihre Funktionen gegenseitig. Beispiele sind Teamkalender und Teamaufgabenlisten in Outlook oder Erweiterungen der Windows SharePoint Services durch Microsoft Frontpage. Die Integrationsmöglichkeiten in Office 2007 sind umfangreicher als in Office 2003.
• Integration zu weiteren Microsoft-Produkten: Exchange, BizTalk, SQL-Server und Project-Server.
• Integration allgemein: Es können weitere digitale Datenquellen angebunden werden.
• Erweiterbarkeit und Anpassbarkeit

Für diese Art der Zusammenarbeit wird allerdings auch ein intaktes Netzwerk vorausgesetzt. Sollte dies nicht der Fall sein, so ist die IT-Abteilung des Unternehmens zu kontaktieren.

Google Wave

Google Wave wurde, wie der Name schon erklärt, von der Firma Google entwickelt. Diese hat Mitte 2009 ein Tool bereitgestellt, das alle gängigen Kommunikationsformen (E-Mail, Blogs, kollaborative Editoren, Wikis etc.) miteinander verknüpft. Google selbst beschreibt es als „Personal Communication and Collaboration Tool“. Das spannende an Googles Plattform ist, das es einen anderen Weg einschlägt als andere Anbieter. Zum einen wird das gesamte Produkt als Open Source Version angeboten, wodurch einerseits auf Lizenzgebühren verzichtet wird, als auch den Entwicklern die Möglichkeit geboten wird, ihre eigenen Ideen in das Produkt zu implementieren. Zum anderen wird durch die Veröffentlichung von Google Wave ein neues, bis daher nicht benutztes, Protokoll zur Datenübertragung eingebunden.

Grundsätzliche Merkmale zu Google Wave.^[59]

Die Hauptfeatures von Google Wave:

• Echtzeit: Twitter oder Instant-Messenger sind schnell? Google Wave ist schneller: Live verfolgen, wie der oder die Gesprächspartner ihre Nachricht eingeben und Tippfehler verbessern.
• Drag & Drop: Einfach Bilder, Videos oder sonstige Dateien in die Wave hinein ziehen und sofort wird die Datei hochgeladen oder eingebunden, wenn die Datei von einer anderen Webseite heraus gezogen wird.
• Open Source: Google Wave wird komplett für Entwickler geöffnet. Dadurch können schneller Modifikationen und Erweiterungen von Wave-Nutzern erstellt werden, als es das Team von Google könnte.
• Offene Schnittstelle: Durch diese ist es möglich, Waves in die eigene Webseite, Blog oder Community einzubauen und darin in Echtzeit mit anderen Webseiten-Usern diskutieren.
• Playback: Bei einer so schnellen Kommunikation kann schnell einmal der Überblick verloren werden. Mit der Playback Funktion kann jede Änderung noch einmal einzeln angesehen werden.
• Applikationen: Google Wave lässt sich quasi beliebig erweitern. Über Gadgets und Robots können eigene Programme in Wave eingebracht werden. Hier wird uns in Zukunft einiges erwarten.

Die Entscheidung, welches Tool sich besser in das Unternehmen integrieren lässt, ist nicht zu treffen. Die Schwierigkeit ergibt sich eher aus der Fragestellung heraus, ob man bereit und offen für eine Veränderung in der Zusammenarbeit mit und unter den Mitarbeitern im Unternehmen ist.

Microsofts Share Point Services geht den formalen Pfad. Es bedient sich der Überlegenheit im Marktsegment und unterstreicht das durch die kommerzielle Vermarktung zum Preis von xx €, zum anderen jedoch sowohl Support anbietet als auch die Integrität der Daten gewährt.

Google Wave schlägt dem gegenüber einen neuen Weg ein und bietet eine Open Source Lösung. Dabei ist zu beachten, dass alle Daten über die Server von Google gehandelt werden. Dieser „kleine“ Grund genügt bereits, um das Tool grundsätzlich aus Datenschutzgründen nicht in den Firmenalltag zu integrieren. Das sollte auch Google bewusst sein. Möglicherweise besteht die Möglichkeit, den Dienst in das Unternehmen zu integrieren, autark von den Google Servern. Damit Google Wave von internen IT-Fachkräften erweitert und gewartet werden kann.

====Aufbruch der Unternehmensstruktur====^[60]

Die Unternehmensstruktur, die in den Unternehmen vorherrscht, unterliegt verschiedenen Faktoren. In der Abhängigkeit zum Alter und dem Wachstum, kann das schon folgende Formen der Unternehmensstruktur ergeben ^[61]

Hierbei wird sichtbar, welchen Zusammenhang die Komplexität und das Alter bzw. die Größe des Unternehmens spielt. Das Problem, das hierbei entstehen kann, ist die Formalisierung des Unternehmens. Das bedeutet je älter und beständiger ein Unternehmen ist, desto häufiger wird der Einwand „Das hatten wir schon“ „Das machen wir immer so“ hervor gebracht. In diesen Unternehmen ist eine Umsetzung von neuen Methoden sehr schwer.

Ist ein Unternehmen groß, sind die Strukturen wesentlich komplexer und es bedarf ein höherer Verwaltungsaufwand. Dies schlägt sich nicht nur in der Modernisierung nieder, sondern auch in der Einführung neuer Arbeitsweisen. Es kann dazu führen, dass Einscheidungsfindungen mehr Zeit in Anspruch nehmen.

Ein wichtiger, nicht zu unterschätzender Faktor bei dem Aufbruch der Unternehmensstruktur ist die Branche. Die Branche bestimmt zum Teil die Offenheit oder auch die Herangehensweise von Mitarbeitern, sich mit neuen Arbeitsmethoden oder Geräten auseinander zu setzen. Z. B. sind Technologieunternehmen im Gegensatz zu Bauunternehmen wesentlich aufgeschlossener, wenn es um die Einführung neuer Arbeitsmethoden bzw. Werkzeuge geht.

Die häufigsten Unternehmensstrukturen sind jedoch folgende:
Diese Form kommt meistens in Start-ups oder Klein(st)unternehmen zum Vorschein. Diesen Unternehmen fehlt es in der Regel an formeller Struktur. Das Unternehmen wird von den Gründern geführt, die auch kritische Entscheidungen direkt treffen. Diese Struktur zeichnet sich durch eine hohe Flexibilität und Dynamik aus.

• Funktionale Struktur

Hierbei ist das Unternehmen in verschiedenen Abteilungen gegliedert, wie z.b IT, Vertrieb, Marketing, Support

Die Unternehmensführung übernimmt die zentrale Entscheidungsfindung. Dabei kann es zu Problemen in der Koordination und Abstimmung der einzelnen Abteilungen kommen, da diese nicht eigenständig entscheiden können.

• Produktlinienstruktur

In dieser Struktur wird das Unternehmen nach Geschäftsbereichen unterteilt:

Die Vorteile sind hier, dass die Unternehmensleitung sich bei diesem Modell auf andere Aufgaben konzentrieren kann und sich jede Abteilung auf seine eigenes Kerngeschäft ausrichten kann.

Welche Struktur kann also am besten aufgebrochen werden?

Diese Frage kann nicht pauschal beantwortet werden, da die Unternehmensformen sehr verschieden sind. Grundsätzlich muss die Entscheidung zur Umstellung eines Unternehmens in der Unternehmensleitung beginnen. Es muss aufgezeigt werden, wie viel Möglichkeiten es zur kollaborativen Projektarbeit gibt. Dem Unternehmen muss klar gemacht werden, dass eine Umstellung unverzichtbar ist. Ein gutes Hilfsmittel sind externe Berater, die das Unternehmen bewerten und eventuelle Schwachstellen aufdecken können. Eine abschließende Umsetzungsentscheidung zum kollaborativen Projektmanagement sollte dann zunächst an die jeweiligen Leiter der Teams oder Abteilungen weitergegeben werden, damit Schulungen die Mitarbeiter auf die Umstellung und die damit verbundene neue Arbeitsweise vorbereiten können, um so eine schnelle Umsetzung und Akzeptanz zu schaffen und somit eine möglichst hohe Erfolgsquote gewährleisten zu können.

7.2.2 Implementierung

7.2.2.1 Wie erfolgt die Einführung?

Die Einführung des kollaborativen Projekmanagements wird zum Anlass genommen, zwei Methoden zu kombinieren. Kritisch gesehen sind beide Ansätze in der Vorgehensweise grundsätzlich verschieden. Das macht sie jedoch wiederum für das Projekt attraktiv. Zum einen wird die Implementierung des kollaborativen Projektmanagements über eine autark geführte Gruppe, der „Task Force“, durchgeführt. Diese beschäftigt sich ausschließlich mit der neuen Vorgehensweise. Zum anderen sieht die Schulung der Mitarbeiter vor, ihnen die Angst vor „dem Neuen“ zu nehmen, und so in das gewohnte Umfeld der Mitarbeiter zu integrieren und etablieren. Damit wird eine höhere Akzeptanz der Mitarbeiter für die Umsetzung hergestellt.

7.2.2.1.1 Vor- und Nachteile von Taskforces

Die Task Force oder auch „Reine Projektorganisation“, gehört zu den Formen der Projektorganisationen. Sie bietet sich vor allem an, wenn Projekte umfangreicher ausfallen und eine hohe strategische Bedeutung für das Unternehmen besitzen.
Für die Task Force werden aus einzelnen Unternehmensorganisationen Mitarbeiter ausgegliedert, und anschließend für die Dauer des Projektes einem Projektleiter unterstellt

Die Vorteile die aufgrund des Aufbaus entstehen, sind zum einen eine schnelle und saubere Abgliederung vom Rest des Unternehmens. Diese führt dazu, dass das Projekt zunächst separat durchgeführt werden kann, um so zu überprüfen, ob das kollaborative Projektmanagement für das Unternehmen eine wertvolle Bereicherung ist. Die Mitarbeiter der einzelnen Organe, die dem Projekt zugeordnet sind, bringen durch ihre Erfahrung und dem Wissen der Anforderung ihrer Abteilung ein heterogenes Wissensnetz.

Die Nachteile einer solchen Projektorganisation sind der entstehende administrative Aufwand sowie die damit verbunden Kosten, die dem Unternehmen entstehen. Ein Ressourcenengpass in den Human Ressources und die Wiedereingliederung der Mitarbeiter in Ihre vorherigen Abeilungen bilden einen weiteren Nachteil.

7.2.2.1.2 Schulung von Mitarbeitern

Die Schulung der Mitarbeiter ist das Wichtigste bei der Einführung neuer Arbeitselemente. Das kollaborative Projektmanagement stellt eine Herausforderung an Mitarbeiter und Vorgesetze. Zur Umsetzung des Ziels können mehrere Schulungsmethoden eingesetzt werden. Die Möglichkeit der internen oder externen Schulung bietet darüber hinaus folgende Merkmale.

• Firmenintern

Hierbei wird die Schulung der Mitarbeiter intern bearbeitet. Das Unternehmen stellt Ressourcen für die Schulung zur Verfügung. Diese Ressourcen können internes Fachpersonal, Räume, Arbeitszeit usw. sein. Das Fachpersonal unterweist die Mitarbeiter in die neue Arbeitsumgebung ein. Wichtig ist hierbei, dass alle Mitarbeiter auf den gleichen Kenntnisstand gebracht werden und Fragen direkt zu beantworten sind.

• Firmenextern

Das Unternehmen bezahlt ein externes Schulungsunternehmen, die Aufgabe der Mitarbeiterschulung zu übernehmen. Die Schulung findet in Geschäftsräumen der Schulungsfirma statt. Das zu schulende Unternehmen stellt als Ressource nur Geld, Zeit und Mitarbeiter zur Verfügung. Da die Schulungen meist am Wochenenden stattfinden, beeinträchtigen sie also nicht die tägliche Arbeit.

Folgende Methoden können zur Mitarbeiterschulung eingesetzt werden.^[62]

• Klassiche Methode – Übungen

Diese Übungen werden in der Regel schriftlich festgehalten, um so einen Überblick der Leistungen zu gewährleisten. Schriftliche Übungen dienen vor allem der Konzentration. Nach den schriftlichen Übungen, sollte das gelernte an praktischen Fallbeispielen geübt werden.

• E-Learning

Beim E-Learning werden die Mitarbeiter mit speziellen Computersimulationen trainiert. Das Ergebnis kann direkt analysiert werden, um die Mitarbeiter auf Schwachstellen hinzuweisen.

7.2.3 Controlling

7.2.3.1 Konfliktmanagement^{[63][64][65][66][67]}

Konfliktmanagement ist die „Feststellung, Steuerung und Regelung von Konflikten durch spezifische Handhabungsformen, etwa Verhandlung, Vermittlung, Schlichtung einschließlich Zwangsschlichtung.“^[68]

Von besonderer Bedeutung in kollaborativen Projekten ist das Konfliktmanagement. Durch die Zusammenarbeit mehrerer Unternehmen, die eventuell unterschiedliche Interessen haben oder international zusammenarbeiten und somit verschiedene Kulturen aufeinander treffen, kann es zu Konflikten innerhalb der Projektphase kommen. Konflikte kosten Zeit, die zu Lasten des Projektziels bzw. des Terminplans im Projekt geht, daher gehört zum Konfliktmanagement, dass Konfliktpotentiale reduziert werden, Konfliktsignale frühzeitig erkannt werden, Konflikte benannt werden und mit den Konfliktpartnern nach Lösungen gesucht wird.

Im Konfliktmanagement gibt es präventive (vorbeugende Maßnahemen) und kurative (Konfliktlösungen) Methoden zur Konfliktbewältigung. Ebenso wird zwischen latenten (versteckt) und manifesten (offen) Konflikten unterschieden. Diese Konflikte gilt es frühzeitig zu erkennen und anschließend zu analysieren. Während der Konfliktanalyse ist festzustellen wer am Konflikt beteiligt ist, um welchen Konflikt es sich handelt, was sind die wirklichen Interessen der beteiligten Personen und wie wichtig ist dieser Konflikt.

Um Konflikte lösen zu können kann auch die Kenntnis der Konfliktursache hilfreich sein. Wird die Ursache verstanden kann dies helfen einen tatsächlichen Schlussstrich zu ziehen. Entscheidend ist in jedem Fall die Steuerung des Konfliktes, denn sobald einer der Beteiligten dem Konflikt ausweicht, ist dieser nur aufgeschoben und nicht gelöst. Die Steuerung sollte nach Möglichkeit eine neutrale Person übernehmen. Um den Konflikt zu Lösen und eine Win- Win- Situation zu schaffen bedarf es einer Kommunikation und Offenheit für Kompromisse. Sollte sich kein Kompromiss finden lassen, muss der Konflikt durch einen Schlichter neutral bzw. durch die Projektverantwortlichen in Form von Hierarchie beendet werden.

In den zusammenarbeitenden Unternehmen sollte daher in den Projektteams entsprechend geschultes Personal vorhanden sein, die Konflikte frühzeitig erkennen, analysieren, steuern und lösen können.

Kreislauf des Konfliktmanagements:

7.2.3.2 Evaluierung^[69]

Nach der Einführung des kollaborativen Projektmanagementsystems im Unternehmen ist eine Evaluierung ein erforderlicher Vorgang. Dabei wird bei Abschluss der Einführung und Implementierung der Nutzen des Projektes beurteilt.

Laut "Praxishandbuch Projektmanagement" von Margit Gätjens-Reuter, sollte bei der Evaluierung eine Checkliste verwendet werden.Es wird ein Beispiel für eine solche Checkliste beschrieben: Checkliste Evaluierung

• Beschreiben Sie den Nutzen, der mit der Projekterreichung gewonnen werden soll
  • quantitativ(zum Beispiel Zeitgewinn oder Kostenreduzierung)
  • qualitativ(zum Beispiel Kundenzufriedenheit, Mitarbeitermotivation etc.)
• Entwickeln und definieren Sie Prüfkriterien, mit deren Hilfe Sie dass Ausmaß des erzielten Nutzens bewerten zu können
  • für den finanziellen Nutzen
  • für den immateriellen Nutzen
  • für den ideellen Nutzen
• Entwickeln und definieren Sie Kennzahlen, mit denen Sie den Grad des erzielten Nutzens messen können
  • für den finanziellen Nutzen
  • für den immateriellen Nutzen
  • für den ideellen Nutzen
• Bewerten Sie nun den durch das Projekt erzielten Nutzen, indem Sie
• die entsprechenden Kennzahlen ermitteln und mit den Soll-Werten vergleichen
• die ermittelten Kennzahlen mit denen anderer Projekte vergleichen(Benchmarking)

7.2.3.3 Qualitätsmanagement^[70][71]

Damit ein unternehmensübergreifendes Projekt erfolgreich ist wird entsprechendes Qualitätsmanagement benötigt. Hiermit sollen sich nur einzelne Produkte in ihrer Qualität verbessert werden sondern auch die Qualitätsziele, Qualitätsplanung, Qualitätslenkung und Qualitätssicherung der Unternehmen umgesetzt werden.

Die DIN EN ISO 9000 definiert Qualitätsmanagement als: "Aufeinander abgestimmte Tätigkeiten zum Leiten und Lenken einer Organisation bezüglich Qualität." Die Verwendung des Begriffs „Organisation“ macht deutlich, dass es sich dabei nicht nur um einzelne Produkte handelt, sondern eben um ganze Unternehmen, die Leistungen für entsprechende Kunden erbringen.

In der Norm DIN EN ISO 9000 werden 8 Grundsätze des Qualitätsmanagements aufgeführt:

1. Kundenorientierung
2. Führung
3. Einbeziehung der Personen
4. Prozessorientierter Ansatz
5. Systemorientierter Managementansatz
6. Ständige Verbesserung
7. Sachbezogener Ansatz zur Entscheidungsfindung
8. Lieferantenbeziehung zum gegenseitigen Nutzen

Der Erfolg der Unternehmen bzw. kollaborativer Projekte hängt von den Erwartungen und tatsächlich an den Kunden gelieferten Leistungen ab. Deshalb müssen die erbrachten Leistungen oder Produkte analysiert werden und anschließend Prozesse zur Erfüllung der Kundenanforderung definiert werden.

Die Einführung des Qualitätsmanagements verläuft im Wesentlichen in 4 Phasen:

1. Analyse der Organisationsstruktur und der Kundenanforderungen
2. Erarbeitung einer Zielsetzung für die Organisation,
3. Eingreifen in die beteiligten Prozesse
4. Evaluation der eingeführten Maßnahmen

Qualitätsmanagement ist ein kontinuierlicher Verbesserungsprozess, dessen Phasen im Laufe des Projektes immer wieder durchlaufen werden.

In unternehmensübergreifenden Projekten muss das Qualitätsmanagement der Unternehmen aufeinander abgestimmt sein. Neben den zusammenarbeitenden Unternehmen müssen auch entsprechende Lieferanten in das Qualitätsmanagement eingebunden werden. In den Projektteams müssen die Verantwortlichen die Qualitätsziele festlegen und für das notwendige Qualitätsbewusstsein sorgen.

7.2.3.4 Qualitätsmanagementmethoden

7.2.3.4.1 Balanced Score Card^[72]

Bei der Balanced Score Card werden individuelle Kennzahlen aus den Zielen des Unternehmens abgeleitet und bewertet. Für diese Methode nennen Norton und Kaplan 4 Grundperspektiven in denen die Kennzahlen ermittelt werden um so einen Soll-Ist Vergleich zu ermöglichen. Es handelt sich dabei um die Kategorien Finanzen, Kunden, Prozesse und Mitarbeiter. Das Unternehmen kann sich für diese Bereiche eigene, für sich selbst anwendbare Kennzahlen erarbeiten, oder aber auf die bereits existierenden Kennzahlen zurückgreifen. Dadurch würde sich einfach ein Benchmarking mit anderen Unternehmen erstellen lassen. Für das kollaborative Projektmanagement ist eine Qualitätssicherung und die Orientierung an den Unternehmenszielen notwendig, wobei die Bewertung dessen, anhand der Balanced Score Card schwer möglich ist.

7.2.3.4.2 Total Quality Management^[73]

Das Total Quality Management (TQM) beschreibt eine Methode, bei der alle Mitarbeiter des Unternehmens (total) bei der Qualitätssicherung der Prozesse (quality) mit einbezogen werden und installiert die Qualitätssicherung als Führungsaufgabe (management). Im Grunde bedeutet es, dass eine Instanz im Unternehmen eingeführt wird, welche die Prozesse und ihre Durchlaufzeiten im Hinblick auf die Qualität bewertet und gegebenenfalls verbessert. Für das kollaborative Projektmanagement, ist dies ein sinnvoller Ansatz um notwendige Änderungen am System durchführen zu können und einen reibungslosen Ablauf der Projekte zu gewährleisten.

7.2.3.4.3 FMEA^[74]

Die Methode der Fehlermöglichkeits- und Einflussanalyse ( FMEA engl. Failure Mode and Effect Analysis), beschreibt den Ansatz, bei der Einführung eines Prozesses mögliche Fehler zu erkennen und diese sofort zu beseitigen. Das hat zum Vorteil, dass einige Fehler im täglichen Einsatz nicht auftreten, schließt Fehler aber nicht komplett aus. Für das kollaborative Projektmanagement ist es nicht möglich, jeden Fehler bereits bei der Entwicklung auszuschließen.

8 Fazit

Kollaboratives Projektmanagement ist ein guter Projektmanagementansatz um vielfältige Problemstellungen in einem IT-Unternehmen (oder auch Unternehmen allgemein) anzugehen. Je nach Art des Problems ist im Vorfeld eine Entscheidung für ein Vorgehensmodell zu treffen, das im Projektverlauf auch beibehalten wird. Egal für welchen Ansatz man sich entscheidet, es wird immer nach folgenden sechs Grundprinzipien vorgegangen:

1. Anforderung
2. Entwurf
3. Implementierung
4. Teststellung
5. Inbetriebnahme
6. Wartung

Heutzutage existieren am Markt vielfältige Lösungen für alle möglichen Problemstellungen einer Unternehmung. Eine korrekt formulierte Anforderung (siehe Punkt 1) kann also schon entscheidend sein für Erfolg oder Misserfolg. Da sonst eventuell die falsche Software eingesetzt wird, was nur unter erheblichem Kostenaufwand (und damit verknüpfter Neuaufsetzung des betroffenen Projekts) verbunden ist.

Schon im ersten Entwurf sorgen Qualitätsmanagement und Qualitätssicherung für die richtige Richtung der Entwicklung, so dass man in der ersten Implementierungsphase nicht eine böse Überraschung erlebt.

Eine ausführliche Teststellung prüft das entwickelte Programm auf noch möglicherweise bestehende Fehler.

Nach Inbetriebnahme erfolgt ein kontinuierlicher Verbesserungsprozess (KVP) der bestehenden Software.

Für ein KMU können bei Einführung eines kollaborativem Projektmanagements anfangs viele Hürden zu überwinden sein (wie Sicherheitsstandards etc.), nach erfolgter Einführung erwachsen dadurch der Firma aber ganz neue Möglichkeiten an der eigenen IT und Infrastruktur zu arbeiten und zu verbessern.

9 Fußnoten

1. ↑ http://www.pmaktuell.org/uploads/PMAktuell-200802/PMAktuell-200802-031-Public.pdf
2. ↑ http://wirtschaftslexikon.gabler.de/Archiv/82856/collaboration-v4.html
3. ↑ http://www.c-lab.de/de/arbeitsgebiete/cooperation/collaboration/index.html
4. ↑ http://wirtschaftslexikon.gabler.de/Archiv/54978/projektmanagement-pm-v4.html
5. ↑ http://books.google.de/books?id=g-qvEnUc_78C&pg=PA3&lpg=PA3&dq=vorgehensmodell+definition&source=bl&ots=G_dmVBlLbs&sig=tZyHhm59PM9T16rfhV4HgzEpZD0&hl=de&ei=TCcBTOnULeSUOP2TyNYE&sa=X&oi=book_result&ct=result&resnum=8&ved=0CEsQ6AEwBw#v=onepage&q=vorgehensmodell%20definition&f=false
6. ↑ http://bis2.informatik.uni-leipzig.de/studium/vorlesungen/2005_ws/swt/2005w_swt_v_03.pdf
7. ↑ http://bis2.informatik.uni-leipzig.de/studium/vorlesungen/2005_ws/swt/2005w_swt_v_03.pdf
8. ↑ http://www.computerbase.de/lexikon/Wasserfallmodell
9. ↑ http://www.fh-wuerzburg.de/professoren/bwl/fiedler/vorlesungen/WI/Material_09/Uebung_Vorgehensmodelle/Vorgehensmodelle.pdf
10. ↑ http://www.computerbase.de/lexikon/V-Modell
11. ↑ http://bis2.informatik.uni-leipzig.de/studium/vorlesungen/2005_ws/swt/2005w_swt_v_03.pdf
12. ↑ http://www.swe.uni-linz.ac.at/teaching/lva/ws03-04/se_uebung/05_gruppen/g1_ploesch/VModell_03.pdf
13. ↑ http://www.swe.uni-linz.ac.at/teaching/lva/ws03-04/se_uebung/05_gruppen/g1_ploesch/VModell_03.pdf
14. ↑ http://www.swe.uni-linz.ac.at/teaching/lva/ws03-04/se_uebung/05_gruppen/g1_ploesch/VModell_03.pdf
15. ↑ http://www.fh-wuerzburg.de/professoren/bwl/fiedler/vorlesungen/WI/Material_09/Uebung_Vorgehensmodelle/Vorgehensmodelle.pdf
16. ↑ (Boehm, Barry: A Spiral Model of Software Development and Enhancement. ACM SIGSOFT Software Engineering Notes, August 1986; Boehm, Barry: A Spiral Model of Software Development and Enhancement. IEEE Computer, Vol.21, Ausg. 5, Mai 1988, pp 61-72.)
17. ↑ http://www.projektmagazin.de/glossar/gl-0824.html
18. ↑ http://www.fh-wuerzburg.de/professoren/bwl/fiedler/vorlesungen/WI/Material_09/Uebung_Vorgehensmodelle/Vorgehensmodelle.pdf
19. ↑ http://www.objectarchitects.de/tu2002/slides/vl02proz.pdf
20. ↑ http://www.objectarchitects.de/tu2002/slides/vl02proz.pdf
21. ↑ http://www.objectarchitects.de/tu2002/slides/vl02proz.pdf
22. ↑ http://www.computerbase.de/lexikon/Rational_Unified_Process
23. ↑ http://www.infforum.de/themen/anwendungsentwicklung/thema_SE_rup.htm
24. ↑ http://www.infforum.de/themen/anwendungsentwicklung/thema_SE_rup.htm
25. ↑ http://www.torsten-horn.de/techdocs/sw-dev-process.htm#RUP
26. ↑ http://www.torsten-horn.de/techdocs/sw-dev-process.htm#RUP
27. ↑ http://www.computerbase.de/lexikon/Rational_Unified_Process
28. ↑ http://www.torsten-horn.de/techdocs/sw-dev-process.htm#RUP
29. ↑ http://www.computerbase.de/lexikon/Rational_Unified_Process
30. ↑ http://www.fh-wuerzburg.de/professoren/bwl/fiedler/vorlesungen/WI/Material_09/Uebung_Vorgehensmodelle/Vorgehensmodelle.pdf
31. ↑ http://www.swe.uni-linz.ac.at/teaching/lva/ws03-04/se_uebung/05_gruppen/g1_ploesch/RUP_03.pdf
32. ↑ http://www.swe.uni-linz.ac.at/teaching/lva/ws03-04/se_uebung/05_gruppen/g1_ploesch/RUP_03.pdf
33. ↑ http://www.frankwestphal.de/ExtremeProgramming.html
34. ↑ http://www.frankwestphal.de/ExtremeProgramming.html
35. ↑ http://www.torsten-horn.de/techdocs/sw-dev-process.htm#XP
36. ↑ http://blog.seibert-media.net/2005/05/01/extreme-programming-vorgehensmodell-zur-software-entwicklung-bei-seibertmedia/
37. ↑ http://blog.seibert-media.net/2005/05/01/extreme-programming-vorgehensmodell-zur-software-entwicklung-bei-seibertmedia/
38. ↑ http://www.zingel.de/pdf/10orga.pdf
39. ↑ http://www.prostep.org/de/standards-amp-infos/was-ist-step.html
40. ↑ http://www.torsten-horn.de/techdocs/eai.htm
41. ↑ http://www.torsten-horn.de/techdocs/eai.htm
42. ↑ http://soa-know-how.de/index.php?id=45&tx_bccatsandauthors[catid]=11
43. ↑ http://soa-know-how.de/index.php?id=45&tx_bccatsandauthors[catid]=26
44. ↑ http://www.itwissen.info/definition/lexikon/service-oriented-architecture-SOA-SOA-Architektur.html
45. ↑ http://soa-know-how.de/index.php?id=45&tx_bccatsandauthors[catid]=26
46. ↑ http://www.torsten-horn.de/techdocs/soa.htm
47. ↑ http://www.itwissen.info/definition/lexikon/enterprise-resource-planning-ERP.html
48. ↑ http://www.ec-net.de/EC-Net/Redaktion/Pdf/Anwendungssoftware/Materialien/erp-oss-leitfaden,property=pdf,bereich=ec_net,sprache=de,rwb=true.pdf
49. ↑ http://www.aip-institut.de/download/pdm_systeme.pdf
50. ↑ http://www.virtualsolutions-gmbh.de/lexikon/pdm-system__9.htm
51. ↑ http://books.google.de/books?id=yhsPaeo6SToC&printsec=frontcover&dq=datensicherheit&hl=de&ei=mXgATJqwBZzC-Qb6p8SkCg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDQQ6AEwAA#v=onepage&q&f=false
52. ↑ http://books.google.de/books?id=7lRSiI9GiFUC&pg=PA24&dq=datenschutz+kollaboratives+projektmanagement&hl=de&ei=FnkATI2vDJLl-Qb3qcCkCg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDMQ6AEwAA#v=onepage&q&f=false
53. ↑ http://www.gesetze-im-internet.de/bdsg_1990/
54. ↑ http://www.gesetze-im-internet.de/tkg_2004/
55. ↑ http://www.gesetze-im-internet.de/tmg/
56. ↑ http://www.gesetze-im-internet.de/hgb/
57. ↑ https://www.bsi.bund.de/ContentBSI/dasBSI/Gesetz/gesetz.html
58. ↑ http://de.wikipedia.org/wiki/Microsoft_Windows_SharePoint_Services
59. ↑ http://www.waveinside.de/wave-inside-alles-uber-google-wave/
60. ↑ http://www.themanagement.de/ressources/Strukturen.htm
61. ↑ http://www.themanagement.de/ressources/Strukturen.htm
62. ↑ http://www.contentmanager.de/magazin/artikel_139_erfolgsfaktoren_e_learning.html
63. ↑ http://www.student-online.net/Publikationen/457/Projekt.doc
64. ↑ http://www.die-schule-des-lebens.de/downloads/konfliktmanagement.pdf
65. ↑ http://pjmb.wordpress.com/2009/02/04/projektmanagement-ist-konfliktmanagement/
66. ↑ http://www.pm-quadrat.com/pdf/PMAktuell_200704_GPM.pdf
67. ↑ http://www.mediation-svm.ch/images/ph_news/Collaborative%20Working%20&%20Editorial%20GR.pdf
68. ↑ http://wirtschaftslexikon.gabler.de/Archiv/85839/konfliktmanagement-v5.html
69. ↑ http://books.google.de/books?id=LfaEjOdMBmYC&pg=PA215&dq=evaluierung+projekte&hl=de&ei=qUkATOWWEcrI-QborfikCg&sa=X&oi=book_result&ct=result&resnum=2&ved=0CDMQ6AEwAQ#v=onepage&q=evaluierung%20projekte&f=false
70. ↑ http://www.qualitaetsmanagement-online.de/cn/J-96DC54D5266A35895AE96E5229C78D70.1/bGV2ZWw9dHBsLXFtLWdydW5kbGFnZW4*.html#02
71. ↑ http://www.pruckner.biz/qualitaetsmanagement_qualitaetskonzeption.html
72. ↑ http://books.google.de/books?id=xw9Z6HtHfZAC&pg=PA207&dq=qualit%C3%A4tssicherung+Balanced+Scorecard&hl=de&ei=_5ICTJ3QENSY_Qan-4XSCw&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDEQ6AEwADgK#v=onepage&q=qualit%C3%A4tssicherung%20Balanced%20Scorecard&f=false
73. ↑ http://books.google.de/books?id=Ow5E5HmzLpAC&pg=PA1&dq=total+quality+management&hl=de&ei=AZcCTIfjK4SC_Qb0iNjJBQ&sa=X&oi=book_result&ct=result&resnum=1&ved=0CC0Q6AEwAA#v=onepage&q&f=false
74. ↑ http://books.google.de/books?id=lAEosVeVXIwC&printsec=frontcover&dq=FMEA&cd=1#v=onepage&q&f=false

10 Literatur- und Quellenverzeichnis

10.1 Buchquellen

10.2 Internetquellen

10.2.1 Grundlagen Allgemein + Definition

• http://www.pmaktuell.org/uploads/PMAktuell-200802/PMAktuell-200802-031-Public.pdf
• http://wirtschaftslexikon.gabler.de/Archiv/82856/collaboration-v4.html
• http://www.c-lab.de/de/arbeitsgebiete/cooperation/collaboration/index.html
• http://wirtschaftslexikon.gabler.de/Archiv/54978/projektmanagement-pm-v4.html

10.2.2 Organisation

• http://www.zingel.de/pdf/10orga.pdf

10.2.3 Technik (IT- Infrastruktur)

• http://www.prostep.org/de/standards-amp-infos/was-ist-step.html
• http://www.torsten-horn.de/techdocs/eai.htm
• http://www.soa-know-how.de
• http://www.itwissen.info/definition/lexikon/service-oriented-architecture-SOA-SOA-Architektur.html
• http://www.torsten-horn.de/techdocs/soa.htm
• http://www.itwissen.info/definition/lexikon/enterprise-resource-planning-ERP.html
• http://www.ec-net.de/EC-Net/Redaktion/Pdf/Anwendungssoftware/Materialien/erp-oss-leitfaden,property=pdf,bereich=ec_net,sprache=de,rwb=true.pdf
• http://www.aip-institut.de/download/pdm_systeme.pdf
• http://www.virtualsolutions-gmbh.de/lexikon/pdm-system__9.htm

10.2.4 grundsätzliche Vorgehensmodelle

• http://books.google.de/books?id=g-qvEnUc_78C&pg=PA3&lpg=PA3&dq=vorgehensmodell+definition&source=bl&ots=G_dmVBlLbs&sig=tZyHhm59PM9T16rfhV4HgzEpZD0&hl=de&ei=TCcBTOnULeSUOP2TyNYE&sa=X&oi=book_result&ct=result&resnum=8&ved=0CEsQ6AEwBw#v=onepage&q=vorgehensmodell%20definition&f=false
• http://bis2.informatik.uni-leipzig.de/studium/vorlesungen/2005_ws/swt/2005w_swt_v_03.pdf
• http://www.to-go-pm.de/?q=aggregator/sources/1

10.2.4.1 Wasserfallmodell

• http://www.computerbase.de/lexikon/Wasserfallmodell
• http://cartoon.iguw.tuwien.ac.at:16080/fit/fit01/wasserfall/welcome.html

10.2.4.2 V-Modell

• http://www.fh-wuerzburg.de/professoren/bwl/fiedler/vorlesungen/WI/Material_09/Uebung_Vorgehensmodelle/Vorgehensmodelle.pdf
• http://www.computerbase.de/lexikon/V-Modell
• http://bis2.informatik.uni-leipzig.de/studium/vorlesungen/2005_ws/swt/2005w_swt_v_03.pdf
• http://www.swe.uni-linz.ac.at/teaching/lva/ws03-04/se_uebung/05_gruppen/g1_ploesch/VModell_03.pdf

10.2.4.3 Spiralmodell

• http://www.fh-wuerzburg.de/professoren/bwl/fiedler/vorlesungen/WI/Material_09/Uebung_Vorgehensmodelle/Vorgehensmodelle.pdf
• http://www.projektmagazin.de/glossar/gl-0824.html
• http://www.objectarchitects.de/tu2002/slides/vl02proz.pdf

10.2.4.4 RUP

• http://www.computerbase.de/lexikon/Rational_Unified_Process
• http://www.infforum.de/themen/anwendungsentwicklung/thema_SE_rup.htm
• http://www.torsten-horn.de/techdocs/sw-dev-process.htm#RUP
• http://www.fh-wuerzburg.de/professoren/bwl/fiedler/vorlesungen/WI/Material_09/Uebung_Vorgehensmodelle/Vorgehensmodelle.pdf
• http://www.swe.uni-linz.ac.at/teaching/lva/ws03-04/se_uebung/05_gruppen/g1_ploesch/RUP_03.pdf

10.2.4.5 XP

• http://www.frankwestphal.de/ExtremeProgramming.html
• http://www.torsten-horn.de/techdocs/sw-dev-process.htm#XP
• http://blog.seibert-media.net/2005/05/01/extreme-programming-vorgehensmodell-zur-software-entwicklung-bei-seibertmedia/

10.2.5 Datensicherheit

• http://books.google.de/books?id=yhsPaeo6SToC&printsec=frontcover&dq=datensicherheit&hl=de&ei=mXgATJqwBZzC-Qb6p8SkCg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDQQ6AEwAA#v=onepage&q&f=false
• http://books.google.de/books?id=7lRSiI9GiFUC&pg=PA24&dq=datenschutz+kollaboratives+projektmanagement&hl=de&ei=FnkATI2vDJLl-Qb3qcCkCg&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDMQ6AEwAA#v=onepage&q&f=false

10.2.5.1 Bundesdatenschutzgesetz

• http://www.gesetze-im-internet.de/bdsg_1990/

10.2.5.2 Telekommunikationsgesetz

• http://www.gesetze-im-internet.de/tkg_2004/

10.2.5.3 Telemediengesetz

• http://www.gesetze-im-internet.de/tmg/

10.2.5.4 Handelsgesetzbuch

• http://www.gesetze-im-internet.de/hgb/

10.2.5.5 Bundesamt für Sicherheit in der Informationstechnik

• https://www.bsi.bund.de/ContentBSI/dasBSI/Gesetz/gesetz.html

10.2.6 Evaluierung

• http://books.google.de/books?id=LfaEjOdMBmYC&pg=PA215&dq=evaluierung+projekte&hl=de&ei=qUkATOWWEcrI-QborfikCg&sa=X&oi=book_result&ct=result&resnum=2&ved=0CDMQ6AEwAQ#v=onepage&q=evaluierung%20projekte&f=false

10.2.7 Konfliktmanagement

• http://wirtschaftslexikon.gabler.de/Archiv/85839/konfliktmanagement-v5.html
• http://www.student-online.net/Publikationen/457/Projekt.doc
• http://www.die-schule-des-lebens.de/downloads/konfliktmanagement.pdf
• http://pjmb.wordpress.com/2009/02/04/projektmanagement-ist-konfliktmanagement/
• http://www.pm-quadrat.com/pdf/PMAktuell_200704_GPM.pdf
• http://www.mediation-svm.ch/images/ph_news/Collaborative%20Working%20&%20Editorial%20GR.pdf

10.2.8 Qualitätsmanagement

• http://www.qualitaetsmanagement-online.de/cn/J-96DC54D5266A35895AE96E5229C78D70.1/bGV2ZWw9dHBsLXFtLWdydW5kbGFnZW4*.html#02
• http://www.pruckner.biz/qualitaetsmanagement_qualitaetskonzeption.html

10.2.9 Qualitätsmanagementmethoden

10.2.9.1 Balanced Score Card

• http://books.google.de/books?id=xw9Z6HtHfZAC&pg=PA207&dq=qualit%C3%A4tssicherung+Balanced+Scorecard&hl=de&ei=_5ICTJ3QENSY_Qan-4XSCw&sa=X&oi=book_result&ct=result&resnum=1&ved=0CDEQ6AEwADgK#v=onepage&q=qualit%C3%A4tssicherung%20Balanced%20Scorecard&f=false

10.2.9.2 TQM – Total Quality Management

• http://books.google.de/books?id=Ow5E5HmzLpAC&pg=PA1&dq=total+quality+management&hl=de&ei=AZcCTIfjK4SC_Qb0iNjJBQ&sa=X&oi=book_result&ct=result&resnum=1&ved=0CC0Q6AEwAA#v=onepage&q&f=false

10.2.9.3 FMEA

• http://books.google.de/books?id=lAEosVeVXIwC&printsec=frontcover&dq=FMEA&cd=1#v=onepage&q&f=false