Adaptierung und Einführung eines Vorgehensmodells für IT-Projekte

Inhaltsverzeichnis

DARSTELLUNGSVERZEICHNIS

ABKÜRZUNGSVERZEICHNIS

MANAGEMENT SUMMARY

VORWORT

1 EINLEITUNG
1.1 MOTIVATION
1.2 ÜBERBLICK ÜBER DIE ARBEIT
1.3 ZIELBESCHREIBUNG

2 AUSGANGSSITUATION UND PROJEKTMOTIVATION
2.1 VORSTELLUNG DER FIRMA T.CON
2.2 HERAUSFORDERUNGEN / VISION

3 STATE OF THE ART: AUSWAHL EINES VORGEHENSMODELLS
3.1 DEFINITION VORGEHENSMODELL
3.2 ZIELE VON VORGEHENSMODELLEN
3.3 EXISTIERENDE VORGEHENSMODELLE
3.3.1 KLASSISCHE VORGEHENSMODELLE
3.3.2 PROZESSFRAMEWORKS
3.3.3 AGILE VORGEHENSMODELLE
3.4 STANDARD CONTRA INDIVIDUALISIERUNG

4 BEST OF BREED: DER WEG ZUM EIGENEN VORGEHENSMODELL
4.1 GRUNDLAGE: OPENUP
4.2 WEITERE EINFLUSSGRÖßEN
4.3 ZIELE VON TEAMUP
4.4 KONFIGURATION ODER ANPASSUNG: WARUM DAS RAD NEU ERFINDEN?
4.4.1 ABDECKUNGSGRAD
4.4.2 AUFWAND UND VARIANTEN DER ADAPTIERUNG
4.4.2.1 Ergänzen von OpenUP
4.4.2.2 Ergänzen und Ersetzen von Inhalten in OpenUP
4.4.2.3 Neugestalten von TeamUP in Anlehnung an OpenUP
4.4.2.4 Überblick über Varianten der Adaptierung
4.4.3 BEWERTUNG VON AUFWAND UND NUTZEN

5 TECHNIK: PFLEGE, VERÖFFENTLICHUNG UND NUTZUNG
5.1 HERAUSFORDERUNGEN
5.1.1 PFLEGE UND VERÖFFENTLICHUNG DER PROZESSBESCHREIBUNG
5.1.2 NUTZUNG DER PROZESSBESCHREIBUNG IM PROJEKTALLTAG
5.1.3 ÜBERBLICK
5.2 PFLEGE UND VERÖFFENTLICHUNG DER PROZESSDOKUMENTATION: EPC
5.2.1 GRUNDKONZEPTE
5.2.2 METHODENWISSEN
5.2.3 PROZESSWISSEN
5.2.4 VERBINDUNG VON METHODEN- UND PROZESSWISSEN IM EPC
5.2.5 ANWENDUNGSSZENARIEN
5.2.6 MODELLIERUNG VON TEAMUP
5.3 EINBINDUNG IN DEN PROJEKTALLTAG: PROJEKTPORTAL JIRA
5.3.1 ABBILDUNG DER ARTEFAKTE IN JIRA
5.3.2 VERKNÜPFUNG JIRA MIT TEAMUP

6 ORGANISATION: EINFÜHRUNGSPROZESS
6.1 HERAUSFORDERUNGEN
6.1.1 EINFÜHRUNGSPROZESS GESTALTEN
6.1.2 WEITERENTWICKLUNG INSTITUTIONALISIEREN
6.2 EINFÜHRUNGSPROZESS GESTALTEN
6.2.1 MODELLE FÜR DIE PROZESSEINFÜHRUNG
6.2.1.1 IDEAL-Modell
6.2.1.2 Implementierung des RUP
6.2.1.3 Einführung von Scrum
6.2.2 EINFÜHRUNGSPROJEKT FÜR TEAMUP
6.3 WEITERENTWICKLUNG INSTITUTIONALISIEREN
6.3.1 ORGANISATORISCHE INSTRUMENTE FÜR DEN WISSENSERHALT
6.3.1.1 Integration von Wissenszielen in die Projektphasen
6.3.1.2 Festlegung von Wissenszielen als Teil der Projektziele
6.3.2 VERANKERUNG IM PROZESSMODELL TEAMUP

7 MENSCH: CHANGE MANAGEMENT
7.1 HERAUSFORDERUNGEN
7.1.1 BEGLEITUNG DES EINFÜHRUNGSPROZESSES HIN ZUR INSTITUTIONALISIERUNG
7.1.2 MOTIVATION FÜR DAS TEILEN VON ERFAHRUNGEN
7.2 BEGLEITUNG DES EINFÜHRUNGSPROZESSES
7.2.1 DYNAMIK VON VERÄNDERUNGEN
7.2.1.1 Ebenen der Veränderung
7.2.1.2 Phasen der Veränderung
7.2.1.3 Unterschiedliche Veränderungsgeschwindigkeit
7.2.1.4 Anforderung an Management und Führung
7.2.2 CHANGE MANAGEMENT FÜR DIE EINFÜHRUNG VON TEAMUP
7.2.2.1 Vermittlung einer klaren Vision
7.2.2.2 Transparente und geplante Kommunikation
7.2.2.3 Beteiligung der Betroffenen
7.2.2.4 Qualifikation
7.2.2.5 Projektmanagement
7.3 MOTIVATION FÜR DAS TEILEN VON ERFAHRUNGEN
7.3.1 BEWEGGRÜNDE FÜR VERÄNDERUNGEN
7.3.2 MOTIVATION
7.3.2.1 Extrinsische Motivation
7.3.2.2 Intrinsische Motivation
7.3.3 SICHERUNG DER WEITERENTWICKLUNG VON TEAMUP

8 ERGEBNISSE UND PERSPEKTIVEN
8.1 MAßNAHMENÜBERSICHT
8.2 BEWERTUNG AKTUELLER STATUS
8.3 PERSPEKTIVEN

ANHANG A: ENTSTEHUNGSGESCHICHTE DER PROZESSMODELLE

LITERATURVERZEICHNIS

Darstellungsverzeichnis

Darst. 1-1: Gemeinsames Ziel von Vorgehensmodellen und Wissensmanagement

Darst. 1-2: Gestaltungsdimensionen

Darst. 1-3: Überblick über die Arbeit

Darst. 2-1: Herausforderungen im TOM-Modell

Darst. 3-1: Prozess- und Methodenwissen

Darst. 3-2: Elemente in Scrum

Darst. 4-1: Struktur OpenUP

Darst. 4-2: Aufbau einer Iteration in OpenUP

Darst. 4-3: Artefakte in OpenUP

Darst. 4-4: Einflussfaktoren für TeamUP

Darst. 4-5: Ziele von TeamUP

Darst. 4-6: Ergänzen von OpenUP

Darst. 4-7: Ergänzen und Ersetzen von OpenUP

Darst. 4-8: Neugestalten von TeamUP

Darst. 4-9: Überblick über Varianten der Adaptierung

Darst. 5-1: Herausforderungen Technik

Darst. 5-2: Methoden- und Prozesswissen im RUP

Darst. 5-3: Methoden- und Prozesswissen bei Fujitsu Macroscope

Darst. 5-4: Elemente des Methodenwissens

Darst. 5-5: Pflege Methodenwissen im EPC

Darst. 5-6: Veröffentlichte Dokumentation aus EPC

Darst. 5-7: Pflege Prozesswissen im EPC

Darst. 5-8: Verbindung von Methoden- und Prozesswissen im EPC

Darst. 5-9: Navigation in TeamUP

Darst. 5-10: Verbindung der Elemente durch EPC

Darst. 5-11: Möglichkeiten der Prozessanpassung in EPC

Darst. 5-12: Dokumentenplan TeamUP

Darst. 5-13: Verknüpfung Artefakte in JIRA

Darst. 5-14: Anwendungsfall in JIRA

Darst. 5-15: Erste Projektphase in TeamUP

Darst. 5-16: Aktivitäten in TeamUP

Darst. 5-17: Verbindung JIRA-TeamUP

Darst. 5-18: Überblick Verbindung JIRA-TeamUP

Darst. 6-1: IDEAL-Modell

Darst. 6-2: Phasen für Einführungsprozess des RUP

Darst. 6-3: Phasen und Aktivitäten für Einführungsprozess des RUP

Darst. 6-4: Überblick Einführungsprozess RUP

Darst. 6-5: Team-Organisation bei RUP-Einführung

Darst. 6-6: Demingkreis

Darst. 6-7: Projektphasen für Einführung TeamUP

Darst. 6-8: Projektplan Einführung TeamUP

Darst. 6-9: Prozessdominante Instrumente zur Sicherung des Erfahrungswissens

Darst. 6-10: Darstellungsdominante Instrumente zur Sicherung des Erfahrungswissens

Darst. 6-11: Feedback-Integration in TeamUP

Darst. 7-1: Gefahren für Veränderungsprozess

Darst. 7-2: Ebenen der Veränderung

Darst. 7-3: Phasen der Veränderung

Darst. 7-4: Vision aus TeamUP

Darst. 7-5: Kommunikationsmaßnahmen

Darst. 7-6: Formen der intinsischen Motivation

Darst. 7-7: Maßnahmen zur Sicherung der Weiterentwicklung von TeamUP

Darst. 8-1: Zusammenfassung von Herausforderungen und Maßnahmen

Darst. 8-2: Prozess des Wissensmanagements

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Management Summary

Deutsch

Diese Arbeit erörtert die Herausforderungen beim Erarbeiten, Veröffentlichen und Einführen eines neuen Vorgehensmodells für die Durchführung von IT-Projekten. Die Herausforderungen gliedern sich in drei Gestaltungsdimensionen: Technik, Organisation und Mensch. Dazu begleitet die vorliegende Arbeit die Einführung des neuen Vorgehensmodells „TeamUP“ bei der Firma T.CON.

Die erste Dimension „Technik“ beschreibt die notwendige Umgebung zur Erstellung, Veröffentlichung und Pflege der Prozessdokumentation. An dieser Stelle werden zwei technische Aspekte erläutert: Der Eclipse Process Composer ist ein Werkzeug, mit dem Prozess- und Methodenwissen in eine transparente Prozessdokumentation integriert werden können. Das zweite vorgestellte Werkzeuge JIRA begleitet bereits heute die Projektarbeit bei T.CON. In dieser Arbeit wird ein Lösungsansatz vorgestellt, der die Integration des Projektportals JIRA mit der Prozessdokumentation ermöglicht.

Die zweite Dimension „Organisation“ beschäftigt sich mit Instrumenten zur Gestaltung des organisatorischen Umfelds. Diese Arbeit stellt ein mögliches Szenario zur Durchführung des Einführungsprojektes vor. Darüber hinaus gibt sie einen Ausblick, wie die Erfahrungen aus zukünftigen Projekten in die Prozessbeschreibung aufgenommen werden können.

Die Menschen bilden die dritte Gestaltungsdimension. Diese Arbeit präsentiert die Dynamik und die Phasen des Veränderungsprozesses und zeigt Möglichkeiten auf, damit umzugehen. Sie geht auch darauf ein, wie die Motivation der Anwender zur weiteren Gestaltung der Prozessdokumentation aktiviert werden kann.

Der Hauptteil der Arbeit wird eingerahmt mit einem Überblick über existierende Vorgehensmodelle, einem Überblick über die Prozessanpassung bei T.CON und dem Zwischenstand der Ergebnisse nach Durchführung der ersten Projekte mit TeamUP. Nach der Durchführung der ersten Projekte mit dem neuen Vorgehensmodell lässt sich zum jetzigen Zeitpunkt bereits feststellen: Es ist sehr wichtig, alle drei Gestaltungsdimensionen während der Einführung zu berücksichtigen. Knackpunkte sind eine klare Vision, transparente Kommunikation und ein organisiertes Projektmanagement. Begleitet werden muss die Einführung durch passende Werkzeuge und die notwendigen organisatorischen Veränderungen. Ein etabliertes, anpassungsfähiges und lebendiges Vorgehensmodell kann aktives Wissensmanagement im Unternehmen unterstützen.

English

This paper discusses the challenges to design, publish and introduce a new process model for IT projects. The challenges are divided into three dimensions: technology, organization and people. Thereby this paper goes along with the introduction of the new process model “TeamUP” at T.CON.

The first dimension “technology” describes the environment needed to edit, publish and maintain the process documentation. At this point two technical aspects are covered: The Eclipse Process Composer gives the ability to integrate process and method content and generate transparent process documentation. The second tool JIRA already accompanies the project work at T.CON. This paper shows a solution, how to integrate the existing project portal JIRA with the published process documentation.

The second dimension “organization” deals with methods to form the organizational environment. This paper discusses a possible project environment to introduce the new process model TeamUP. Furthermore it shows a way to integrate the enhancements of the process model in upcoming projects.

“People” are the third dimension. This paper shows the dynamic and stages of the change process and presents methods to deal with them. It also gives an outlook how to motivate people to enhance the process in the future.

The main section is surrounded by an overview about existing process models, a short overview about the process adaption at T.CON and a preliminary result of the TeamUP rollout project. After collecting the experience from the first projects carried out with TeamUp, it can be seen already the following: It is important to cover all three dimensions during the process rollout. Key aspects are a clear vision, transparent communication and organized project management. This goes along with clear tool support and necessary organizational changes. An established, agile and living process model can foster an active knowledge management.

Vorwort

Diese Arbeit entstand begleitend zur Einführung des neuen Vorgehensmodells bei der Firma T.CON im Rahmen meines berufsbegleitenden Master-Studiums. Die Ausarbeitung und Einführung des Vorgehensmodells TeamUP durfte ich als Projektleiter mitgestalten. Der Themenkomplex beschäftigt mich aber nicht erst seit diesem Projekt.

Bereits im Zuge meiner Bachelor-Arbeit habe ich die Frage diskutiert, wie die Anwendung von Vorgehensmodellen die Softwareentwicklung auch in kleinen Projekten unterstützt. Seitdem war ich auf der Suche nach Methoden, die auch in kleinen und mittleren Projekten sinnvoll angewendet werden können. Getrieben wurde diese Motivation durch meine beruflichen Aktivitäten und die Erfahrungen in zahlreichen Projekten im SAP-Umfeld.

Inspiriert wurde ich dabei immer wieder durch die Vorlesungsthemen in meinem Master-Studium. Besonders bedanken möchte ich mich bei Dr. Michael Müller, der durch seine Ausführungen zum TOM-Modell die Gliederung dieser Arbeit maßgeblich geprägt hat. Ebenso wurde die Arbeit durch die Ausführungen von Prof. Dr. Dr. Heribert Popp zum Thema Wissensmanagement beeinflusst.

Bedanken möchte ich mich auch bei Gerhard Schneider für die anregenden Diskussionen rund um das Thema Vorgehensmodelle. Ferner möchte ich mich bei Dr. Jürgen Schmied für die Anregungen aus dem Bereich Einführung von Prozessen bedanken. Dank gebührt auch den Korrekturlesern dieser Arbeit, die mir ihre Zeit geschenkt haben.

Besonders bedanken möchte ich mich bei meiner Frau Michaela, die mich während meines berufsbegleitenden Studiums immer unterstützt hat.

Plattling, 26. Juni 2010 Markus Kammermeier

1 Einleitung

1.1 Motivation

Die Vorteile beim Einsatz von Vorgehensmodellen bei der Projektdurchführung im Allgemeinen und bei der Entwicklung von Software im Speziellen sind seit Langem bekannt und heute nahezu unbestritten¹ :

- Sicherstellung einer hohen Qualität durch durchdachte Systementwicklung.
- Wiederholbarkeit von Ergebnissen durch Wiederverwendung von gewonnen Erfahrungen.
- Vorhersagbarkeit der Projektdauer durch strukturiertes Projektmanagement.
- Bessere Koordination des Projektteams durch Richtlinien für die Zusammenarbeit.

Auch in mittleren und kleinen Projekten werden heute existierende Vorgehensmodelle angewendet. Einer der Gründe hierfür ist häufig, dass Kunden die Anwendung von Standardmodellen einfordern. Standardmodelle wie das V-Modell XT oder der Rational Unified Prozess (RUP) unterstützen dabei die Anpassung des Vorgehensmodells auf das aktuelle Projekt.

Dennoch empfinden viele Projektbeteiligte, speziell bei der Erstellung von Software, diese Vorgaben als Einschränkung und Begrenzung ihrer Kreativität. In der Folge werden seit einigen Jahren für die Softwareentwicklung agile Modelle wie Scrum oder Extreme Programming (kurz XP) propagiert. Diese Modelle offerieren mehr Freiheiten, sind allgemeiner formuliert und sparen bei der Vorgabe von konkreten Handlungsanweisungen.

Ziel eines dokumentierten Vorgehensmodells ist es, die Prozessdokumentation und das methodische Wissen zusammenzuführen und für die Anwender strukturiert aufzubereiten. Die Prozessdokumentation klärt dabei die zeitliche Abfolge der Projektaktivitäten. Das methodische Wissen stellt das notwendige Know-how für die Durchführung der Projektaktivitäten zur Verfügung.

Strenge Vorgaben bei der Prozessstruktur und Ausführung der Aufgaben sind für die Durchführung von Standardprozessen sehr sinnvoll. Bei wissensintensiven Prozessen, wie der Durchführung einer Softwareentwicklung oder der Einführung eines neuen ERP-Systems, schränken strenge Vorgaben die Mitarbeiter zu sehr ein. In diesen Projekten ist nahezu jede Aufgabe eine wissensintensive Aktivität, deren Erfolg in hohem Maß vom Wissen des Akteurs abhängig ist.

In diesem Bereich muss das Ziel des Vorgehensmodells die Unterstützung der Projektbeteiligten bei der Durchführung ihrer Arbeit sein. Als Prozessdokumentation muss es Orientierung im Projektalltag bieten. Als Wissensbasis bietet es Zugriff auf Methodiken, Checklisten und Vorlagen zur Unterstützung der Projektbeteiligten.

Wissensintensive Projekte sind angewiesen auf das Wissen der Projektbeteiligten. Unternehmen, die diese Projekte gemeinsam mit ihren Kunden durchführen, sind angewiesen auf die Identifikation, Entwicklung, Verteilung und den Erhalt des Wissens im Unternehmen.

Ein Vorgehensmodell bietet somit aktives Wissensmanagement für Prozesse und Aufgaben (siehe Darst. 1-1). Aus diesem Grund muss ein Vorgehensmodell bei der Einführung, Anwendung und Weiterentwicklung gleichzeitig als Prozessdokumentation und Wissensmanagement-System verstanden werden.

Abbildung in dieser Leseprobe nicht enthalten

Darst. 1-1: Gemeinsames Ziel von Vorgehensmodellen und Wissensmanagement ²

1.2 Überblick über die Arbeit

Bei der Einführung und Weiterentwicklung eines Vorgehensmodells zur Unterstützung des aktiven Wissensmanagements müssen drei Gestaltungsdimensionen betrachtet werden: Technik, Organisation und Mensch (siehe Darst. 1-2).

Der Bereich Technik befasst sich mit der Bereitstellung und Pflege der unterstützenden IT-Systeme und der benötigten Infrastruktur. Die Organisation beschreibt die Organisation von Mitarbeitern und Prozessen im Unternehmen. Der Bereich Mensch setzt sich mit den Anforderungen an die Mitarbeiter und der Unterstützung bei Veränderungsprozessen auseinander.

Abbildung in dieser Leseprobe nicht enthalten

Darst. 1-2: Gestaltungsdimensionen ³

Diese Arbeit begleitet die Einführung eines Vorgehensmodells bei der Firma T.CON. Die Firma und das interne Projekt werden in Kapitel 2 vorgestellt. Der Autor dieser Arbeit ist gleichzeitig Projektleiter dieses Einführungsprojektes.

Die Kapitel 3 und 4 legen mit der Beschreibung von Vorgehensmodellen das theoretische Fundament für die Diskussion über den Einführungsprozess.

Der Hauptteil dieser Arbeit gliedert sich in die drei Aspekte Technik, Organisation und Mensch. Kapitel 5 widmet sich den technischen Aspekten bei der Einführung: Es beantwortet die Frage, mit welchen Werkzeugen die Dokumentation und die Arbeit mit dem Vorgehensmodell unterstützt werden können. Die organisatorischen Aspekte werden in Kapitel 6 erläutert: Wie können die Einführung und die Weiterentwicklung durch die Unternehmensorganisation unterstützt werden. Kapitel 7 untersucht basierend auf den Erkenntnissen des Change Management, wie Konflikte bei der Einführung vermieden werden können.

Den Abschluss der Arbeit bildet ein Abschnitt über die Ergebnisse des Einführungsprojektes und einen Ausblick auf das weitere Vorgehen bei der Firma T.CON.

Darst. 1-3 gibt einen Überblick über die Struktur der Arbeit.

Abbildung in dieser Leseprobe nicht enthalten

Darst. 1-3: Überblick über die Arbeit ⁴

1.3 Zielbeschreibung

Das Ziel des Projektes im Unternehmen T.CON ist die Einführung eines angepassten, firmeninternen Vorgehensmodells für die Durchführung von Projekten. Dieses Vorgehensmodell soll den Erhalt des Wissens über die Durchführung von Projekten unterstützen und gleichzeitig die Weiterentwicklung dieses Wissens fördern. Die Lösung hierfür ist ein gelebtes Vorgehensmodell als Teil eines gelebten Wissensmanagements.

Das Ziel dieser Arbeit ist die wissenschaftliche Betrachtung der Herausforderungen bei der Einführung, Etablierung und Weiterentwicklung eines Vorgehensmodells. Gegliedert in die drei Gestaltungsdimensionen Technik, Organisation und Mensch werden diese Herausforderungen beschrieben und Lösungsvorschläge erarbeitet .

2 Ausgangssituation und Projektmotivation

2.1 Vorstellung der Firma T.CON

Das Unternehmen T.CON ist ein mittelständisches SAP-Beratungsunternehmen mit Sitz im niederbayerischen Plattling. Das Unternehmen wurde 1999 gegründet und betreibt heute neben seinem Hauptsitz in Plattling eine Geschäftsstelle in Villingen-Schwenningen. Die Hauptkompetenzen der Firma T.CON ist die Beratung ihrer Kunden bei der Einführung und Erweiterung von SAP- Lösungen. Dazu gehört insbesondere die Anpassung der ERP-Standardfunktionen auf die speziellen Anforderungen der Kunden. Dies beinhaltet neben Konfiguration der Systemparameter auch die Entwicklung von Kundenprogrammen im SAP-Umfeld. Darüber hinaus bietet die Firma T.CON mit dem Manufacturing Execution System CAT eine vorkonfigurierte Lösung für den Betrieb von SAP- Systemen in der Papier- und Stahlindustrie.

Die Arbeit in diesem Umfeld ist stark projektgetrieben. Dies spiegelt sich auch in der Organisationsstruktur des Unternehmens wider: Jeder Mitarbeiter hat als disziplinarischen Ansprechpartner einen Linienleiter. Gleichzeitig arbeitet jeder Mitarbeiter in einem oder mehreren Projekten, in denen der fachliche Ansprechpartner der Projektleiter ist. In jedem Jahr werden auf diese Weise bis zu 20 verschiedene Projekte mit einem Aufwand von 30 bis 1500 Personentagen abgewickelt. Die Spannweite reicht von reinen Entwicklungsprojekten über reine Beratungsprojekte bis hin zu kompletten Systemeinführungen. Reine Entwicklungsprojekte dienen der Erstellung einer neuen Softwarekomponente. In reinen Beratungskomponenten wird der Kunde bei der Anpassung des SAP-Systems für seine Geschäftsprozesse durch die Anpassung des Customizings beraten. Bei Systemeinführungen werden beide Disziplinen in unterschiedlichen Ausprägungen angewendet.

2.2 Herausforderungen / Vision

In den ersten Jahren wurden ähnliche Projekte immer von einem ähnlichen Projektteam bearbeitet. Durch diese enge Zusammenarbeit haben sich im Kernteam erprobte und bewährte Vorgehensweisen etabliert. Dieser Erfahrungsschatz bildet die Grundlage für die gleichbleibende hohe Qualität und Zuverlässigkeit der Lösungen. Eine Formalisierung dieses Vorgehens war nicht nötig, da das Vorgehensmodell ständig im Team gelebt und weiterentwickelt wurde.

In den letzten Jahren sind die Anzahl der Mitarbeiter und die Anzahl der Kunden stetig gewachsen. Das Unternehmen hat darauf reagiert und die Organisation beständig skaliert. Beispielsweise wird seit 2009 der Austausch von Fachwissen durch die Etablierung von Communities of Practice⁵ gefördert. Das etablierte Projektvorgehen ist weiterhin im Kernteam bekannt. Durch die gestiegene Anzahl von parallelen Projekten wird die Weiterentwicklung dieses Erfahrungsschatzes in den Projekten und nach den Projekten zunehmend erschwert. Hinzu kommt, dass die Vorgehensweise für neue Mitarbeiter und neue Kunden durch die fehlende Formalisierung nicht transparent dargestellt werden kann.

Die Lösung ist die Dokumentation des vorhandenen Projekt-Know-hows in Form eines firmeneigenen Vorgehensmodells. Das dokumentierte Vorgehensmodell stellt Prozessleitfäden, Checklisten und Vorlagen für die Projektdurchführung bereit. Es sammelt auf diese Weise Good Practices aus abgeschlossenen Projekten und stellt sie transparent zur Verfügung. Damit wird eine gleichbleibend hohe Qualität für zukünftige Projekte sichergestellt. Gleichzeitig wird die Einarbeitung von neuen Mitarbeitern erleichtert und die Transparenz für neue Kunden schon zu Projektbeginn verbessert. Darüber hinaus ist die Existenz eines dokumentierten Vorgehensmodells ein Alleinstellungsmerkmal im Vergleich mit Mitbewerbern.

Ziel ist die Bereitstellung eines dokumentierten Vorgehensmodells, welches das gemeinsame Verständnis über das Vorgehen im Projekt fördert, ohne dabei den individuellen Charakter eines Projektes zu verleugnen. Das firmeninterne Vorgehensmodell TeamUP soll den Projektbeteiligten als Orientierung im Projekt dienen. Es beschreibt das Projektvorgehen und stellt als Wissensportal einen strukturierten Zugriff auf bewährte Vorgehensweisen, Checklisten und Vorlagen zur Verfügung. Damit können alle Projektbeteiligten – Entwickler, Berater, Projektleitung und der Kunde – davon profitieren.

Die Herausforderungen dabei sind:

- Die Bereitstellung einer interaktiven Prozessdokumentation.
- Die Integration der Prozessdokumentation in die tägliche Arbeit.
- Die Einführung eines unternehmensweiten, einheitlichen Vorgehens.
- Die ständige Weiterentwicklung dieser Wissensbasis.
- Die Begleitung des Einführungs- und Veränderungsprozesses.
- Das Aktivieren der Motivation für das Teilen von Erfahrungen.

Diese Herausforderungen eröffnen ein Spannungsdreieck aus den drei Bereichen Technik, Organisation und Menschen (siehe Darst. 2-1). Diese drei Gestaltungsdimensionen müssen bei der Einführung und Weiterentwicklung des Vorgehensmodells ausgefüllt werden.

Abbildung in dieser Leseprobe nicht enthalten

Darst. 2-1: Herausforderungen im TOM-Modell ⁶

In den folgenden Kapiteln wird für jeden Bereich auf Basis der Erkenntnisse aus den wissenschaftlichen Disziplinen Prozessdokumentation, Wissensmanagement und Change Management die Lösungsstrategie für die Firma T.CON erarbeitet.

3 State of the Art: Auswahl eines Vorgehensmodells

3.1 Definition Vorgehensmodell

In der Wirtschaftsinformatik werden Vorgehensmodelle häufig direkt im Kontext der Software- Entwicklung definiert:

„Ein Prozessmodell⁷ [...] beschreibt einen festgelegten organisatorischen Rahmen für die Software-Entwicklung. In ihm wird festgelegt, welche Aktivitäten in welcher Reihenfolge von welchen Personen erledigt werden und welche Ergebnisse [...] dabei entstehen und wie diese in der Qualitätssicherung überprüft werden.“⁸

Agile Vorgehensmodelle geben lediglich einen Rahmen für die Projektdurchführung vor, an dem sich das Projektteam orientieren kann; exemplarisch hierfür die Definition von Scrum:

„Scrum ist ein agiles Managementframework zur Entwicklung von Software, das aus wenigen klaren Regeln besteht.“⁹

Vorgehensmodelle werden jedoch nicht nur bei der Software-Entwicklung eingesetzt. Es existieren Modelle für die Einführung neuer Prozesse¹⁰, Veränderungsprojekte¹¹ oder die Produktentwicklung¹². Die folgende Definition fasst den Begriff daher allgemeiner:

„Ein Prozessmodell ist eine Beschreibung einer koordinierten Vorgehensweise bei der Abwicklung eines Vorhabens. Es definiert sowohl den Input, der zur Abwicklung der Aktivitäten notwendig ist, als auch den Output, der als Ergebnis der Aktivitäten produziert wird. Dabei wird eine feste Zuordnung von Workern¹³ vorgenommen, die die jeweilige Aktivität ausüben.“¹⁴

Ein Vorgehensmodell definiert somit, wer , wann , was, wie im Projekt erledigen soll und welches Ergebnis erwartet wird. Der Inhalt des Vorgehensmodells gliedert sich dabei in Prozess- und Methodenwissen (siehe Darst. 3-1). Das Prozesswissen beinhaltet die Information über den zeitlichen Arbeitsablauf und beteiligte Akteure (Wer? und Wann?)¹⁵. Die übrigen Elemente des Vorgehensmodells sind Teil des Methoden- bzw. Funktionswissens . Es besteht aus Erfahrungen (Best Practices), Arbeitsanweisungen, Vorlagen, Checklisten und Hilfsmitteln zur Bearbeitung von einzelnen Prozessschritten¹⁶.

Abbildung in dieser Leseprobe nicht enthalten

Darst. 3-1: Prozess- und Methodenwissen ¹⁷

Im Gegensatz zur Definition von Geschäftsprozessen, mit der standardisierte Prozesse dokumentiert werden, bieten Vorgehensmodelle eine Vorlage für die Durchführung von einmaligen Projekten (z.B. die Entwicklung einer neuen Software oder die Einführung eines ERP-Systems)¹⁸. Diese projekthaften Prozesse zeichnen sich u.a. durch folgende Merkmale aus¹⁹ :

- Hohe Komplexität
- Hohe Individualität
- Hohe Wertigkeit
- Hohe Wissensintensität
- Interdisziplinarität

Im Ergebnis bedeutet das, hohe Anforderungen an das Projektmanagement, Bedarf an hoch qualifiziertem Personal und den gezielten Einsatz von vorhandenem Unternehmenswissen.

Vorgehensmodelle bilden diese projekthaften Prozesse ab und Unterstützung das Projektteam bei der Durchführung. Durch das enthaltene Prozesswissen definieren sie einen Rahmen für die Gestaltung des Projektfahrplans. Gleichzeitig verknüpfen sie die Projektaktivitäten mit vorhandenem Methodenwissen.

Dies begründet die hohe inhaltliche Abhängigkeit bei der Gestaltung bzw. Anwendung von Vorgehensmodellen und den Herausforderungen des Wissensmanagements²⁰. Teilaktivitäten des Wissensmanagements sind die Identifikation, der Erwerb, die Entwicklung, die Verteilung, die Bewahrung und die Nutzung des Unternehmenswissens²¹. Ein Vorgehensmodell kann diese Ziele unterstützen:

- Durch die Weiterentwicklung eines Vorgehensmodells wird implizit vorhandenes Wissen identifiziert und sichtbar gemacht.
- Durch die Anwendung von vorhandenen Industriemodellen wird externes Wissen erworben.
- Durch die Bereitstellung des Vorgehensmodells wird Wissen im Unternehmen verteilt.
- Durch die explizite Erfassung wird Wissen im Unternehmen bewahrt.
- Durch die Anwendung des Vorgehensmodells in den Projekten wird Wissen genutzt.

Es liegt somit nahe, bei der Diskussion über den Einsatz von Vorgehensmodellen die Aspekte des Wissensmanagements ebenfalls zu betrachten. Insbesondere beim Ausrollen und der Weiterentwicklung stehen beide Disziplinen vor ähnlichen Herausforderungen.

In dieser Arbeit wird der Begriff Vorgehensmodell daher weiter gefasst: Das Vorgehensmodell bietet dem Projektteam Orientierung bei der Durchführung von wissensintensiven Projekten²². Es verknüpft hierfür Prozess- und Methodenwissen. Somit bietet das Vorgehensmodell einen zentralen Einstieg auf das Unternehmenswissen zur Unterstützung der Projekte. Durch die Weiterentwicklung der zugrunde liegenden Wissensbasis wird das Vorgehensmodell zum Werkzeug für ein aktives Wissensmanagement.

3.2 Ziele von Vorgehensmodellen

Laut (Rupp 2007) ist das Ziel eines Vorgehensmodells die Qualität des entstehenden Systems durch eine gut durchdachte Systementwicklung sicherzustellen. Auch für (Essigkrug und Mey 2007) sind qualitative Ziele ein entscheidender Vorteil beim Einsatz von Vorgehensmodellen: Durch den Einsatz von Vorgehensmodellen können Erfahrungen wiederverwendet werden. Die Wiederholbarkeit von Ergebnissen und die Beständigkeit einer hohen Qualität werden damit gesteigert.

Darüber hinaus erhöht ein Vorgehensmodell die Transparenz für neue Mitarbeiter und den Auftraggeber²³ : Neue Mitarbeiter können auf Basis einer dokumentierten Vorgehensweise schneller eingearbeitet werden. In der Kommunikation mit dem Auftraggeber werden durch das Vorgehensmodell Prozesse wie z.B. die Änderung einer Anforderung klar geregelt. Diese Transparenz schafft für alle Projektbeteiligten mehr Sicherheit.

Schlussendlich werden Vorgehensmodelle heute zunehmend von Kunden gefordert: Bei den zivilen und militärischen Vorhaben des Bundes ist das V-Modell XT (mit wenigen Ausnahmen) verpflichtend²⁴. Auch in industriellen Ausschreibungen werden definierte Prozessabläufe gefordert²⁵.

Mit der Vorstellung agiler Vorgehensmodelle (siehe 3.3) rücken die Ziele bei der Verbesserung der Interaktion, Kommunikation und Kooperation zwischen Auftraggeber und Auftragnehmer stärker in den Vordergrund²⁶. Sie versuchen damit, gegen die Ängste von Projektmitarbeitern in wissensintensiven Projekten vor Einschränkung und Bevormundung durch das Vorgehensmodell entgegenzuwirken.

Beim Wissensmanagement geht es grundsätzlich um die systematische Erschließung und Nutzung des im Unternehmen vorhandenen Wissens. Die konkreten Ziele des Wissensmanagements werden aus den Unternehmenszielen abgeleitet. Der Einsatz eines Vorgehensmodells wird in den meisten Fällen die Erreichung der Wissensmanagement-Ziele unterstützen.

3.3 Existierende Vorgehensmodelle

Wie beschrieben werden Vorgehensmodelle für unterschiedliche Projektformen angeboten. Die Vorstellung und Klassifizierung existierender Vorgehensmodelle beschränkt sich auf Vorgehensmodelle in der Informatik. Sie unterstützen vornehmlich die Durchführung von Entwicklungsprojekten und Systemeinführungen.

Grundsätzlich lassen sich Vorgehensmodelle in drei Gruppen einteilen²⁷ :

- Klassische Vorgehensmodelle
- Prozessframeworks
- Agile Vorgehensmodelle

3.3.1 Klassische Vorgehensmodelle

In der Gruppe klassische Vorgehensmodelle werden hier alle Phasen-, Wasserfall- und Schleifenmodelle zusammengefasst. Sie haben ihren Ursprung im System Engineering. Das erste Phasenmodell wurde 1956 veröffentlicht²⁸. In den 1970er Jahren veröffentlichte Winston Royce erstmalig ein Wasserfall- oder Schleifenmodell²⁹. Heute werden dem Wasserfallmodell vielfach fehlende iterative und inkrementelle Verfahren als Nachteil ausgelegt. Tatsächlich beschrieb Winston Royce in seinem Entwurf ein evolutionäres Vorgehen. Erst durch die extreme Vereinfachung des Modells auf eine Iteration gingen diese Aspekte verloren³⁰. Das Spiralmodell von Barry Boehm brachte 1988 die iterative Entwicklung wieder ins Gespräch und legte damit den Grundstein für spätere Modelle³¹ (siehe 3.3.2). Anhang A bietet einen Überblick über die historische Entwicklung der Vorgehensmodelle.

Modelle dieser Gruppe gliedern das Projekt in Phasen, die sequenziell hintereinander ablaufen. Voraussetzung für den Übergang in die nächste Projektphase ist der Abschluss der aktuellen Phase. Rücksprünge sind nur an vorher definierten Stellen vorgesehen.

Die Vorgehensmodelle dieser Klasse gelten als zu träge und zu starr, um den heutigen Anforderungen an das Projektmanagement gerecht werden zu können. Dennoch werden heute noch viele Projekte auf Grundlage dieser Modelle abgewickelt. Die Phasen-Struktur der Modelle ist einfach und leicht nachvollziehbar. Diese künstliche Vereinfachung des Projektes entspricht jedoch nicht der Realität, sodass sich iterative und agile Vorgehensmodelle zunehmend durchsetzen.

Dennoch werden auch heute noch von führenden Software-Unternehmen wasserfallähnliche Modelle veröffentlicht³².

3.3.2 Prozessframeworks

Prozessframeworks definieren einen generischen Prozessrahmen. Bestandteil dieses Prozessrahmens sind Prozessvorlagen, Projektrollen, Artefakte und Hilfsmittel. Vor der Anwendung im konkreten Projekt muss dieser Rahmen an die Projektgröße, die Projektart und das Projektumfeld angepasst werden. Diesen Vorgang bezeichnet man als Tailoring, Konfiguration oder Process Engineering. Die angepasste Version wird anschließend veröffentlicht und bildet die Grundlage für die Projektarbeit.

Bekannte Vertreter dieser Gruppe sind das V-Modell XT (Nachfolger des V-Modell 97) und der Rational Unified Process (RUP).

Ohne eine projektspezifische Anpassung können diese Modelle aufgrund ihres Umfangs nicht verwendet werden³³. Somit müssen beim Projektstart der Aufwand und das Know-how für die Anpassung eingeplant werden.

3.3.3 Agile Vorgehensmodelle

Ende der 1990er-Jahre versuchten neue Ansätze wie z.B. Extreme Programming (kurz XP) die Entwicklung von Software dynamischer und erfolgreicher zu gestalten. Die Gruppe der agilen Vorgehensmodelle wird durch eine große Vielfalt an Methoden, das Auswählen der „passenden“ Methode, das fortlaufende Bewerten und gegebenenfalls Anpassung des Methodeneinsatzes bestimmt³⁴.

Begründet wird die Gruppe dieser Vorgehensmodelle durch das agile Manifest:

„Wir entdecken bessere Wege zur Entwicklung von Software, indem wir Software entwickeln und anderen bei der Entwicklung von Software helfen. Durch diese Tätigkeiten haben wir gelernt:

- Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
- Funktionierende Software ist wichtiger als umfangreiche Dokumentation
- Kooperation mit Projektbetroffenen ist wichtiger als Vertragsverhandlungen
- Reaktion auf Änderungen ist wichtiger als Festhalten an einem starren Plan

Natürlich sind auch die Dinge rechts wichtig, aber im Zweifelsfall schätzen wir die linken höher ein.“ ³⁵

Mit diesem Glaubensbekenntnis wollen die Verfasser den Problemen klassischer Vorgehensmodelle und Prozessframeworks begegnen. Sie sehen die Gefahr, sich zur sehr auf Prozesse und Werkzeuge, umfangreiche Dokumentation, Vertragsverhandlungen und Projektplanung zu konzentrieren. In ihren Augen sind die eigentlichen Faktoren für erfolgreiche IT-Projekte die Individualität und Kreativität der Beteiligten, funktionierende Software, die Kooperation mit dem Kunden und die Reaktion auf Änderungen.

Die agilen Vorgehensmodelle greifen dabei u.a. Ideen aus der leichtgewichtigen Produktentwicklung und Techniken zur Verbesserung des Arbeitsumfelds auf³⁶. Die beiden bekanntesten Vertreter sind Extreme Programming (XP) und Scrum.

Sowohl XP als auch Scrum definieren keinen vollständigen Entwicklungsprozess, sondern ein Rahmenwerk, in dem das Projekt ablaufen soll. Scrum definiert z.B. lediglich drei Projektrollen, drei Artefakte und drei Veranstaltungen (siehe Darst. 3-2). Die übrige Projektgestaltung wird bewusst an das Projektteam delegiert. Das Team ist in Scrum verantwortlich für die Erreichung der gesteckten Projektziele.

Abbildung in dieser Leseprobe nicht enthalten

Darst. 3-2: Elemente in Scrum ³⁷

Ziele der agilen Vorgehensmodelle sind die schnellere Auslieferung funktionierender Systeme, die sich besser an den Anforderungen der Anwender orientieren. Hierfür werden die Verantwortlichkeit der Projektmitglieder und das gemeinsame Verständnis aller Projektbeteiligten gefördert.

Die Konsequenzen sind hohe Anforderungen an die einzelnen Projektmitglieder und die notwendige Selbstorganisation innerhalb des Projektteams³⁸.

3.4 Standard contra Individualisierung

Neben der grundsätzlichen Entscheidung für ein geeignetes Vorgehensmodell steht die Frage, ob und wie weit das Modell an das Unternehmen bzw. das konkrete Projekt angepasst werden muss. Sowohl Prozessframeworks, als auch agile Vorgehensmodelle fordern diese Anpassung:

Bei Prozessframeworks ist die Anpassung des Modells Bestandteil des Modells selbst. Beim Tailoring bzw. der Prozesskonfiguration werden relevante Disziplinen, Rollen, Artefakte und Aktivitäten für das konkrete Projekt ausgewählt und als neue Prozesskonfiguration veröffentlicht. Für den schnellen Einstieg bieten sowohl das V-Modell XT als auch der RUP vordefinierte Prozesskonfigurationen für typische Projekte an. Diese Standardkonfigurationen können direkt angewendet werden, sodass der Aufwand für die Prozesskonfiguration entfällt. Darüber hinaus geben die Modelldokumentationen Hinweise darauf, welche Prozesselemente fallweise eingespart werden können und welche Konsequenzen dadurch zu erwarten sind. Nachteilig bei der Anwendung von Standardkonfigurationen ist, dass sie niemals genau auf das Projekt und das Team zutreffen werden. Daher sind Schwierigkeiten bei der Umsetzung und der Akzeptanz wahrscheinlich.

Agile Vorgehensmodelle definieren lediglich Techniken für die Projektarbeit und geben damit einen groben Prozessrahmen vor. Es ist in der Verantwortung des Projektteams diesen Prozessrahmen projektspezifisch mit Leben zu füllen. So macht Scrum z.B. keine Vorschläge, welche Werkzeuge die Projektarbeit unterstützen können und gibt keine Form für die Dokumentation vor.

In der Praxis ist es sinnvoll, sein Vorgehen an den beschriebenen Standardmodellen zu orientieren. Dafür sprechen insbesondere folgende Punkte:

- Standardmodelle basieren auf erprobten Praktiken, die sich vielfach in der Praxis bewährt haben (z.B. iteratives Vorgehen, Kommunikation im Team fördern, etc.). Ein Ziel ist es, diese bewährten „Best Practices“ in die eigenen Projekte einfließen zu lassen.
- In eigenen Erweiterungen können firmeninterne und branchenspezifische Hinweise auf vorhandene Werkzeuge und bewährte Techniken gegeben werden. Das erhöht den Wert der Dokumentation und fördert die Akzeptanz im Unternehmen.
- Durch eigene Ergänzungen wird der Mehrwert des Vorgehensmodells für eigene Projekte erhöht. Das vorhandene Wissen fließt in das Vorgehensmodell ein, erweitert es und dient somit zur Wissensbewahrung im Unternehmen.
- Durch die Anpassung kann die verwendete Sprache an die Bedürfnisse und die Kultur des Unternehmens angepasst werden. Dies betrifft zum einen eine eventuell notwendige Übersetzung, zum anderen eine Anpassung an firmeninterne Begrifflichkeiten. Auch diese Anpassung fördert die Akzeptanz und somit die Anwendung im Unternehmen.
- Das firmeneigene Prozessmodell kann passend gekürzt werden. Überflüssige Elemente werden entfernt und reduzieren damit den Umfang der Prozessdokumentation. Das erhöht die Übersicht und Transparenz im Unternehmen.

Teile dieser Anpassungen (z.B. das Streichen von Elementen) fallen noch in den Bereich der Prozesskonfiguration. Andere Teile (z.B. die Anpassung der Sprache oder die Erweiterung mit eigenen Inhalten) übersteigen die üblichen Anforderungen in dieser Disziplin und sind somit nicht im Modell selbst vorgesehen.

Die Anpassung des Modells ist somit bei der Einführung eines Vorgehensmodells ein wesentlicher Bestandteil. Es stellt sich jedoch die Frage, wie viel Aufwand für die Anpassung des Modells auf das Unternehmen betrieben werden muss:

- Ist die Prozesskonfiguration und anschließende Veröffentlichung der neuen Konfiguration ausreichend,
- soll ein vorhandenes Modell erweitert werden oder
- startet man mit dem eigenen Modell auf der „grünen Wiese“? Das nächste Kapitel wird diese Frage beantworten.

4 Best of Breed: Der Weg zum eigenen Vorgehensmodell

Basis für das eigene Vorgehensmodell bei T.CON ist OpenUP/Basic³⁹. Es bietet einen Mittelweg zwischen Prozessframeworks und agilen Vorgehensmodellen⁴⁰. Die Wahl, OpenUP als Ausgangspunkt für die Entwicklung eines eigenen Modells zu verwenden, fiel bereits im Vorfeld durch einen Auswahlprozess. Hauptgrund für OpenUP ist, dass es dem vorhandenen Projektvorgehen sehr ähnlich ist. OpenUP ist eine frei verfügbare Version des Unified Prozess und greift Elemente verschiedener Modelle auf. Im Folgenden werden zunächst die Kernelemente des Modells dargestellt. Im Anschluss werden Gründe und Umfang der Anpassung diskutiert. Am Ende steht für T.CON das angepasste firmeneigene Vorgehensmodell TeamUP.

4.1 Grundlage: OpenUP

Dieser Abschnitt stützt sich weitgehend auf (Kroll 2007), (Kroll und MacIsaac 2006, S. 15ff) und (Eclipse Process Framework Project 2009).

OpenUP beschreibt ein vollständiges, minimales und anpassbares Vorgehensmodell für die Entwicklung von Software. OpenUP ist generisch, sodass es in vielen verschiedenen Szenarien angewendet werden kann. Gleichzeitig ist es so konkret, dass es Projektteams ohne vorherige Konfiguration verwenden können. OpenUP füllt die Lücke zwischen großen Prozessframeworks und agilen Modellen⁴¹. Hierfür übernimmt es die Struktur des RUP und greift viele Ideen von Scrum auf.

OpenUP gliedert die gesamte Projektlaufzeit in die aus dem Unified Process bekannten Phasen Inception, Elaboration, Construction und Transition. Jede dieser Phasen endet mit einem Meilenstein, der Auskunft über den aktuellen Projektfortschritt gibt (siehe Darst. 4-1).

Abbildung in dieser Leseprobe nicht enthalten

Darst. 4-1: Struktur OpenUP ⁴²

Am Ende der Inception-Phase haben sich die Projektbeteiligten auf eine gemeinsame Vision geeinigt. Mit dem Abschluss der Elaboration-Phase ist die grundsätzliche Architektur des Systems definiert. In der Construction-Phase findet der Hauptteil der Umsetzung statt. An ihrem Ende steht ein vollständiges Beta-Release, das alle wesentlichen Funktionen enthält. Den Abschluss bildet die endgültige Freigabe der Lösung für die Anwender.

Jede Phase wird weiter in Iterationen mit gleicher Länge geteilt. In jeder Iteration (und somit auch in jeder Phase) sind alle Disziplinen (Architektur, Implementierung, Projektmanagement, Anforderungsmanagement und Test) aktiv. Allerdings unterscheidet sich die Intensität, mit der eine Disziplin aktiv ist, in den verschiedenen Phasen. Darst. 4-2 zeigt den grundsätzlichen Aufbau jeder Iteration:

Abbildung in dieser Leseprobe nicht enthalten

Darst. 4-2: Aufbau einer Iteration in OpenUP ⁴³

Am Beginn jeder Iteration steht die gemeinsame Priorisierung der vorhandenen Anforderungen. Daraus werden Ziele und Aufgaben für die Iteration abgeleitet. Während der Iteration werden die einzelnen Arbeitsergebnisse von jedem Projektmitglied zeitnah in die Lösung eingebracht. Am Ende der Iteration steht eine gemeinsame Retroperspektive mit einer Bewertung der Iterationsergebnisse.

[...]

---

¹ Quelle: Essigkrug und Mey (2007)

² Quelle: eigene Darstellung

³ Quelle: eigene Darstellung

⁴ Quelle: eigene Darstellung

⁵ Community of Practice: Praxisbezogener Wissensaustausch von Gleichgesinnten; vgl. Belliger und Krieger (2007, S. 111ff)

⁶ Quelle: eigene Darstellung

⁷ Aus dem Englischen „Software Process Model“; entspricht dem deutschen Begriff Vorgehensmodell

⁸ Quelle: Balzert (2001, S. 54)

⁹ Quelle: Pichler (2009, S. 1)

¹⁰ vgl. Schmied et al. (2008, S. 31)

¹¹ vgl. Abecker et al. (2002, S. 53)

¹² vgl. Schäppi et al. (2005, S. 261)

¹³ Der Begriff Worker beschreibt eine Projektrolle

¹⁴ Quelle: Versteegen (2000, S. 23)

¹⁵ Quelle: Abecker et al. (2002, S. 18)

¹⁶ Quelle: Abecker et al. (2002, S. 27ff)

¹⁷ Quelle: eigene Darstellung

¹⁸ vgl. Stahlknecht und Hasenkamp (2005, S. 215)

¹⁹ Quelle: Abecker et al. (2002, S. 296–298)

²⁰ vgl. Schmied (2006)

²¹ Quelle: Probst et al. (1999, S. 58)

²² Im konkreten Fall sind das die Entwicklung von Software, die Begleitung von Beratungsprojekten und die Einführung von ERP-Systemen.

²³ Quelle: Versteegen (2000, S. 27)

²⁴ Quelle: Beauftrage der Bundesregierung für Informationstechnik (2010)

²⁵ Gefordert werden häufig definierte Prozess-Reifegrade. Ein Maß hierfür sind z.B. die Maturity Levels des CMMI-Modells; vgl. Chrissis et al. (2009)

²⁶ Quelle: Oestereich und Weiss (2007, S. 15–17)

²⁷ Quelle: Kammermeier (2010)

²⁸ Quelle: Bunse und von Knethen (2002)

²⁹ Quelle: Royce (1970)

³⁰ Quelle: Oestereich und Weiss (2007)

³¹ Quelle: Grechenig (2010, S. 376)

³² Beispiel für ein modernes Wasserfall-Modell ist die ASAP-Roadmap der SAP

³³ RUP definiert in einer Konfiguration für kleine Projekte fast 40 Artefakte und 26 Rollen

³⁴ Quelle: Rupp (2007)

³⁵ Engl. Originalquelle: Beck et al. (2001); Übersetzung aus Oestereich und Weiss (2007, S. 15)

³⁶ vgl. Takeuchi und Ikujiro (1986)

³⁷ Quelle: eigene Darstellung

³⁸ vgl. Kammermeier (2010)

³⁹ OpenUP/Basic ist die derzeit einzige veröffentlichte Prozessversion von OpenUP. In dieser Arbeit bezeichnet OpenUP daher immer diese Prozessversion.

⁴⁰ vgl. Kammermeier (2010)

⁴¹ vgl. Bjorn (2008)

⁴² Quelle: Eclipse Process Framework Project (2009)

⁴³ Quelle: Eclipse Process Framework Project (2009)