Entwicklung einer Risikomanagementmethode für kleine und mittlere Softwareunternehmen

INHALTSVERZEICHNIS

1 Einleitung
1.1 Motivation und Problemstellung
1.1.1 Risikomanagement als Lösungsansatz
1.1.2 Risikomanagement in kleinen Softwareunternehmen
1.2 Persönliche Motivation
1.3 Ziele der Arbeit
1.4 Limitationen bestehender Methoden für den Einsatzzweck
1.5 Gliederung der Arbeit
1.6 Herangehensweise und Forschungsmethode
1.6.1 Überblick über die Vorgehensweise
1.6.2 Risikomanagement Methode auf Basis der Literatur entwickeln
1.6.3 Werkzeugprototyp entwickeln
1.6.4 Fallstudie durchführen

2 Risikomanagement Grundlagen und Konzepte
2.1 Risikomanagement
2.1.1 Einführung und wesentliche Begriffe
2.1.2 Risiken in der Softwareentwicklung
2.1.3 Risikomanagement Prozess im Überblick
2.1.4 Risikomanagement Aufgaben im Detail
2.2 Risikomanagement in ausgewählten Projektvorgehensmodellen
2.2.1 Risikomanagement im Spiralmodel
2.2.2 Risikomanagement in SCRUM
2.3 Risikomanagement im Kontext der Organisationsentwicklung
2.3.1 Risikomanagement und Organisationsentwicklung
2.3.2 Risikomanagement und Organisationales Lernen
2.3.3 Wissensmanagement und Risikomanagement

3 Risikomanagement Methode für KMU
3.1 Besondere Anforderungen für Risikomanagement in KMU
3.2 Überblick über die Risikomanagement Methode für KMU
3.3 Integration des Risikomanagements in ein Projekt
3.3.1 Risikomanagement in der Vorprojektphase
3.3.2 Risikomanagement in der Umsetzungsphase
3.3.3 Risikomanagement in der Nachprojektphase
3.4 Ablauf eines Risikoassessments
3.4.1 Zielsetzung und Teilnehmer
3.4.2 Risikoidentifikation und Risikobewertung
3.4.3 Maßnahmenplanung
3.4.4 Maßnahmencontrolling
3.5 Risikoprofile im Projektverlauf
3.5.1 P1: Grobes Risikoprofil nach Erstkontakt zu Projekt
3.5.2 P2: Feines Risikoprofil nach Anforderungsdefinition
3.5.3 P3: Detailliertes Risikoprofil bei Konzept- und Angebotserstellung
3.5.4 U: Vollständiges Risikoprofil für Risiko Monitoring
3.6 Abschluss des Projektes – Projektreview
3.6.1 Zielsetzungen des Projektreviews
3.6.2 Vorbereitung des Reviews
3.6.3 Ablauf des Review-Workshops
3.6.4 Dokumentation der Ergebnisse
3.7 Rollen im Risikomanagement
3.7.1 Risikomanager
3.7.2 Projektleiter
3.7.3 Vertriebsmitarbeiter
3.7.4 Projektteammitglied
3.8 Einführung des Risikomanagements
3.8.1 Überblick über die Vorgehensweise für die Einführung
3.8.2 Start der Einführung
3.8.3 Erstellung Einführungskonzept
3.8.4 Anpassung der Methode an das Unternehmen
3.8.5 Erstellung eines Werkzeugprototypen
3.8.6 Vorbereitung und Durchführung Pilotprojekte
3.8.7 Implementierung produktive Werkzeuge
3.8.8 Einsatzvorbereitung
3.8.9 Produktiveinsatz und Monitoring
3.9 Laufende Verbesserung des Risikomanagements
3.9.1 Zielsetzung für die laufende Verbesserung
3.9.2 Sammeln von Daten als Grundlage für Verbesserungen
3.9.3 Planung und Umsetzung von Verbesserungen
3.9.4 Kontrolle des Nutzens der Verbesserungen

4 Werkzeuge für das Risikomanagement
4.1 Überblick über den Risikomanagement Werkzeugkasten für KMU
4.2 Risikomanagement Process Guide
4.2.1 Überblick und Zielsetzungen für den Process Guide
4.2.2 Überblick über die Struktur
4.3 Risk Profiler
4.3.1 Zielsetzung und Überblick
4.3.2 Datenmodell
4.3.3 Funktionen im Detail
4.3.4 Im Prototyp nicht abgebildete Funktionen

5 Fallstudie zur Validierung von Methode und Werkzeug
5.1 Zielsetzung und Vorgehensweise für die Fallstudie
5.1.1 Zielsetzung und Forschungsfragen
5.1.2 Datensammlung
5.1.3 Datenanalyse
5.1.4 Vorgehensweise bei der Fallstudie
5.2 Auswahl und Beschreibung des Falles
5.2.1 Vorstellung cubido business solutions gmbh
5.2.2 Projekte in der cubido
5.2.3 Zielsetzung des Risikomanagements in der cubido
5.3 Beurteilung der Validität der gesammelten Daten
5.4 Durchführung der Fallstudie
5.4.1 Konzipierung des Einführungsprojektes
5.4.2 Anpassung der Risikomanagement Checklisten
5.4.3 Auswahl der Pilotprojekte
5.4.4 Validierung und Verbesserung von Checklisten und Prototyp in Pilotprojekten
5.5 Ergebnisse der Fallstudie
5.5.1 Quantitative Kostenanalyse
5.5.2 Quantitative Nutzenanalyse
5.5.3 Zusammenfassung der Ergebnisse der quantitativen Analyse
5.5.4 Qualitative Auswertung der Interviews

6 Schlussbemerkungen

7 Glossar

8 Literaturverzeichnis

9 Abbildungsverzeichnis

10 Tabellenverzeichnis

11 Anhang
11.1 Checklisten für die einzelnen Prozessschritte
11.1.1 P1: Grobes Risikoprofil nach Erstkontakt zu Projekt
11.1.2 P2: Feines Risikoprofil nach Anforderungsdefinition
11.1.3 P3: Detailliertes Risikoprofil bei Konzept- und Angebotserstellung
11.1.4 U: Vollständiges Risikoprofil für Risiko Monitoring
11.2 Anleitung für Durchführung eines Projektreviews
11.3 Konzeptdokument für Einführung Risikomanagement (Projektauftrag)
11.3.1 Vision
11.3.2 Nutzen durch das Risikomanagement
11.3.3 Führungsteam für die Einführung des Risikomanagements
11.3.4 Umsetzungsstrategie
11.3.5 Rollen und Aufgaben im Risikomanagement
11.3.6 Weitere wichtige Punkte
11.3.7 Mögliche Hindernisse im Einführungsprojekt und Maßnahmen dazu
11.3.8 Mögliche Nachteile durch Einsatz des Risikomanagements

Bedanken möchte ich mich bei meinen Kollegen in der cubido, die diese Arbeit möglich gemacht haben, allen voran Wolfgang Ennikl, David Mariacher und Christian Gschnell. Danken möchte ich auch meinem Nachbarn Bernhard für so manche spannende und interessante Diskussion zum Thema Risikomanagement. Und Danke sagen möchte ich vor allem meinem Betreuer Paul Grünbacher, der mich perfekt unterstützt und mit ans Übersinnliche grenzender Geschwindigkeit Schwächen in meiner Arbeit aufgedeckt und so wesentlich zu ihrem Gelingen beigetragen hat. Den größten Dank schulde ich aber meiner Frau Barbara, die mir in der langen Zeit des Lesens, Schreibens, Tüftelns und Prüfens stets den Rücken freigehalten hat.

KURZFASSUNG

Softwareentwicklungsprojekte bergen viele Risiken in sich. Gerade in kleinen und mittleren Unternehmen werden diese Risiken meist nicht strukturiert überwacht und behandelt, wodurch ein hoher Anteil der Projekte zumindest einen Teil seiner Ziele nicht erreicht.

Im Zuge dieser Diplomarbeit wird auf Basis wissenschaftlicher Literatur eine Risikomanagement Methode und Werkzeuge speziell für kleine und mittlere Softwareunternehmen entworfen. Kernaspekte der Methode sind zum einen die Integration in den gesamten Projektverlauf vom Beginn der ersten Vertriebsaktivitäten bis zum Abschluss des Projektes. Des Weiteren eine flexible Vorgehensweise, die verschiedene, in der Literatur vorhandene Methoden kombiniert und an die Bedürfnisse von KMU anpasst, sowie die kontinuierliche Verbesserung der Risikomanagement Prozesse und Werkzeuge. Die wesentlichen Schritte der in dieser Arbeit entwickelten Methode sind dabei die Erstellung von an die jeweilige Projektphase angepassten Risikoprofilen, welche mit steigendem Wissensstand immer vollständiger werden und ein Projektreview am Ende eines Projektes, in dem Lessons Learned für das gesamte Unternehmen erarbeitet werden.

Im ersten Teil der Arbeit werden dazu die grundlegenden Problemstellungen und Lösungskonzepte auf Basis des aktuellen Stands der Wissenschaft dargestellt. Darauf aufbauend wird eine Methode für Risikomanagement in KMU Softwareunternehmen vorgestellt und es werden die dafür notwendigen Werkzeuge beschrieben. Die Methode und die Werkzeuge werden in einer Fallstudie validiert, welche im letzten Teil der Arbeit dokumentiert ist.

Abstract

Software development projects involve various risks. Especially in small and medium businesses these risks are not managed, which leads projects to failing or not reaching their targets.

In the course of this diploma thesis a risk management method and tools designed for SME software companies are developed. A basic aspect of the method is the tight integration throughout the project, starting with the first sales activities up to the end of the project. It combines different methods from literature to a flexible approach, which fits the special needs of SME. Continuous improvement of method and tools is a central part. The main steps of the method are the creation of several risk profiles, each of them adjusted to the particular phase in the project life cycle, and a project review at the end to derive lessons learned as source for future improvement.

The first part of this thesis contains the problem description and concepts for solving it based on the current state of science. In the main part the risk management method and tools are described. Finally, the last part of this thesis is the evaluation of method and tools in a case study.

1 Einleitung

1.1 Motivation und Problemstellung

Nach dem seit 1994 jährlich von der Standish Group durchgeführten „Chaos Report“ wurden 2009 32% aller Softwareprojekte abgebrochen und 44% lieferten eingeschränkte Funktionalität, überschritten das Budget oder wurden zu spät geliefert.^[1].

Die Ursachen für den hohen Anteil an nicht erfolgreich abgeschlossenen Projekten liegen zum einen an der Art des erstellten Produktes. Softwaresysteme sind immateriell und vielfach sehr komplex. Da die Softwareindustrie noch eine sehr junge Disziplin ist, sind deren Methoden und Werkzeuge nicht ausreichend ausgereift, um der Komplexität in der Softwareerstellung vollständig begegnen zu können. In der Softwareentwicklung gibt es zwar eine Vielzahl unterschiedlicher Entwicklungsparadigmen, Vorgehensmodelle und Prozesse, davon kann jedoch keines einen reproduzierbaren Erfolg garantieren [2]. Der Erfolg eines Projektes hängt nach wie vor stark von den individuellen Fähigkeiten der Entwickler ab. Von diesen wird neben einem hohen Maß an Kreativität und technischer Kompetenz eine rasche Auffassungsgabe für die in jedem Projekt neuen fachlichen Anforderungen des Auftraggebers und umfassende soziale Kompetenz im Umgang mit Kunden und Ansprechpartnern gefordert. Softwareentwickler sind daher „im allgemeinen sehr intelligente und komplexe Individuen“, was deren Führung oftmals schwierig macht^[2].

Viele der Ursachen, die schlussendlich zum Scheitern von Softwareprojekten führen, kündigen sich schon lange vor ihrem eigentlichen Auftreten an. Man spricht zu diesem Zeitpunkt von Risiken, dass Probleme auftreten und Schaden anrichten werden. Beispiele für solche Risiken sind Anforderungen, die zu spät genannt werden, Fehler in zugekauften Komponenten, die umschifft werden müssen, oder der Ausfall von Teammitgliedern.

Würden die wesentlichen Risiken bereits in frühen Stadien erkannt und rechtzeitig Maßnahmen ergriffen, könnte ein großer Teil der Projekte erfolgreicher angeschlossen werden. Die Praxis zeigt jedoch, dass sich Projektleiter und Entwickler kaum explizit mit Risiken und deren Management beschäftigen. Tun sie dies doch, werden die erkannten Gefahren vielfach nicht kommuniziert, aus Angst als Überbringer einer schlechten Botschaft selbst dafür verantwortlich gemacht zu werden. Werden Risiken dennoch angesprochen, so werden oftmals keine geeigneten Gegenmaßnahmen getroffen. Wird schließlich auch diese Hürde genommen und Maßnahmen geplant, so werden diese inkonsequent ausgeführt und überwacht. Insgesamt ist das strukturierte Management von Risiken in der Softwareentwicklung ein in der Praxis wenig verbreitetes und gelebtes Konzept^[3], was wesentlich zur hohen Quote an fehlgeschlagenen Projekten beiträgt.

1.1.1 Risikomanagement als Lösungsansatz

Werden Probleme frühzeitig erkannt und die richtigen Maßnahmen eingeleitet, so kann oftmals Schaden verhindert oder zumindest abgeschwächt werden. Genau dies ist die Kernaufgabe des Risikomanagements. Risiken sollen frühzeitig identifiziert und analysiert werden. Es sollen entsprechende Maßnahmen geplant und durchgeführt werden. Da Risiken jederzeit auftreten können, ist Risikomanagement ein kontinuierlicher Prozess, der während der gesamten Projektlaufzeit durchgeführt werden muss ^[4]. All dies ist seit langem bekannt, Risikomanagement ist daher in viele Vorgehensmodelle und Standards fix integriert (Spiralmodell von Boehm, SPICE, etc.), alleine es scheitert oft an der praktischen Umsetzung.

Ein weiterer wichtiger Aspekt zur Sicherung des Projekterfolges durch ein professionelles Projekt- und Risikomanagement ist das Lernen aus Fehlern und Erfolgen. Erfolgsrezepte und zu vermeidende Fehlerquellen werden von Projekt zu Projekt und von Mitarbeiter zu Mitarbeiter weitergegeben und laufend verbessert. Somit können Erfolge kontrolliert wiederholt werden und die Abhängigkeit von Einzelpersonen sinkt ^[5].

1.1.2 Risikomanagement in kleinen Softwareunternehmen

Der Großteil der Unternehmen in der Softwarebranche ist in den Bereich der „Kleinen und mittleren Unternehmen“ (KMU) einzuordnen, hat also unter 250 Mitarbeiter und einen Jahresumsatz von weniger als 50 Mio. EUR ^[6], ^[7].

KMU zeichnen sich durch Innovation, hohes technisches Know-How, Flexibilität, wenig Overhead für Management und Administration und kleine bis mittelgroße Projekte aus^[8]. Gerade in KMU sind die weiter oben angeführten Ursachen für gescheiterte Softwareprojekte besonders oft zu finden. Die Entwicklungsprozesse sind vielfach sehr unreif und unstrukturiert, der Erfolg hängt in hohem Maße von den beteiligten Personen ab.

Ein professionelles Risikomanagement wird in den meisten KMU nicht betrieben. Manche Projektleiter beschäftigen sich zwar mit möglichen Problemen, nur selten werden diese aber strukturiert identifiziert, analysiert und mit Maßnahmen versehen. Ein kontinuierliches Lernen von Projekt zu Projekt findet selten statt. Risikomanagement ist also, wie viele andere Bereiche im Projektmanagement, unstrukturiert und anlassgetrieben.

Für Risikomanagement in kleinen und mittleren Softwareunternehmen ist eine angepasste Methode mit entsprechenden Werkzeugen unerlässlich. Die Entwicklung einer solchen Risikomanagement Methode ist Inhalt dieser Diplomarbeit.

1.2 Persönliche Motivation

In dieser Arbeit werden besonders KMU betrachtet, die auftragsbasiert in Projekten Software für ihre Kunden entwickeln. Viele der durchgeführten Projekte bergen große Risiken in sich, da sie ohne vollständige Spezifikation starten und sehr individuell und innovativ sind. Diese Risiken trägt meist der Auftragnehmer.

Der Autor selbst ist seit über zehn Jahren in der Softwareentwicklung in KMU tätig. Zu Beginn arbeitete er als Programmierer, wurde jedoch rasch mit der Leitung von Projekten betraut. In dieser Funktion lernte er unterschiedlichste Vorgehensmodelle, Werkzeuge und Methoden im Projektmanagement kennen. Im Laufe der Zeit sammelte er viel Erfahrung, welche Risiken immer wieder auftreten und was alles schief gehen kann. In den letzten Jahren nutzte der Autor diese Erfahrung, um in den Unternehmen, in denen er tätig war, an der Verbesserung der Entwicklungsprozesse, deren Standardisierung und der Einführung neuer Methoden für die Projektleitung mitzuarbeiten. Daraus entstand die Idee für die Entwicklung einer eigenen Risikomanagement Methode für KMU.

1.3 Ziele der Arbeit

Im Zuge der Arbeit sollen folgende Ziele erreicht werden:

Entwickeln einer Risikomanagement Methode für den Einsatz in KMU Softwareunternehmen. Die Basis hierfür bilden Methoden aus der aktuellen wissenschaftlichen Forschung. Die Risikomanagement Methode soll leicht in das bestehende Projektmanagement integriert und mit wenig Aufwand von den Projektleitern eingesetzt werden können. Es sollen alle Prozessschritte in einem Softwareprojekt unterstützt werden, beginnend mit einfachen Risikoabschätzungen bei den ersten Vertriebsaktivitäten, über laufend durchgeführte Risikoanalysen während der Umsetzung, bis hin zu Reviews nach Abschluss des Projektes. Die gesamte Methode soll mit all ihren Prozessen, Artefakten und Rollen dokumentiert werden.

Konzeptionierung und prototypische Erstellung von Werkzeugen für das Risikomanagement. Für alle Schritte im Risikomanagement Prozess sollen Werkzeuge konzipiert und in einer prototypischen Version zur Verfügung gestellt werden. Ein solcher Werkzeugkasten ermöglicht es den Projektleitern, Risikomanagement in ihren Projekten effektiv und mit wenig Aufwand durchzuführen. Des Weiteren bilden die mit den Werkzeugen gesammelten Daten die Basis für weiterführende Auswertungen und eine laufende Verbesserung des Risikomanagement Prozesses. Der prototypisch entwickelte Werkzeugkasten kann dann als Vorlage für die Entwicklung der unternehmensspezifischen produktiven Werkzeuge dienen.

Evaluierung der Methode und der Werkzeuge in einer Fallstudie in der Praxis. Erst im praktischen Einsatz zeigt sich, ob die entworfene Methode und die entwickelten Werkzeuge effektives und effizientes Risikomanagement ermöglichen. Es wird daher die Risikomanagement Methode gemeinsam mit den Werkzeugen in Pilotprojekten in einem KMU Softwareunternehmen eingesetzt.

1.4 Limitationen bestehender Methoden für den Einsatzzweck

Es gibt bereits viele Risikomanagement Methoden, so z.B. die „Taxonomy Based Risk Identification“ von Carr et al. vom Software Engineering Institute der Carnegie Mellon University ^[9] oder die „Software Risk Management: Principles and Practices“ von Barry Boehm^[10]. Bei der Literaturrecherche zeigte sich jedoch, dass die gebotenen Konzepte nicht ohne weiteres für KMU anwendbar sind. Die meisten Methoden erfordern hohen Aufwand und viele beteiligte Personen. Dies ist in kleinen Unternehmen aufgrund der relativ geringen Projekt- und Teamgrößen meist nicht möglich.

Des Weiteren berücksichtigen die bestehenden Methoden nicht, dass in der Praxis vielfach bereits vor der Umsetzung im Projektauftrag der Funktionsumfang und das dafür zur Verfügung stehende Budget fixiert sind. Zu diesem Zeitpunkt ist die Erstellung eines vollständigen Umsetzungskonzeptes aus Zeitgründen gar nicht möglich. Der Start von Risikomanagement mit Beginn der Planungs- und Designphase ist daher vielfach bereits zu spät.

Eine weitere Schwierigkeit in der Anwendung bestehender Methoden in KMU ist, dass aufgrund der sehr unterschiedlichen Projekte, Kunden und fachlichen sowie technischen Anforderungen eine einzige, allgemeingültige Methode kaum zu finden ist. Gefordert ist hier ein flexibler Methodenmix, der sich an unterschiedliche Projekte und deren Ablauf anpassen lässt.

Die hier entwickelte Risiko Management Methode setzt auf einer Reihe von bestehenden Methoden auf und kombiniert diese, unterscheidet sich aber in folgenden Punkten von den verfügbaren Risikomanagement Ansätzen:

Kleine Softwareunternehmen als Zielgruppe: Die bisher vorliegenden Methoden wurden für den Einsatz in großen Softwareunternehmen entwickelt. Sie können nicht direkt in KMU eingesetzt werden. Die hier vorgestellte Methode soll kleinen Softwareunternehmen bei der auftragsbasierten Erstellung von Software helfen, Probleme frühzeitig zu erkennen und Schaden abzuwenden.

Integration in die Vorprojektphase: Vielfach starten die Risikomanagement Methoden erst mit der Designphase oder gar mit Beginn der Umsetzung. Bei Softwareunternehmen, die auf Auftragsbasis Software entwickeln, werden die Weichen für den Projekterfolg jedoch bereits lange vor dem Umsetzungsstart gestellt. Aus diesem Grund ist die Integration des Risikomanagements in die Vorprojektphase und Angebotserstellung unabdingbar.

Schrittweise Verfeinerung der Risiko Checklisten: Wie die meisten verfügbaren Methoden setzt auch die hier vorgestellte Checklisten ein. Im Unterschied zu den bestehenden Konzepten wird aber nicht ein einziges Set an Fragen verwendet, sondern an die jeweilige Projektphase angepasste Checklisten. Bei den ersten Vertriebsterminen ist das Projekt noch sehr vage definiert, entsprechend sind auch die Risikochecklisten noch grob gehalten und sehr kurz. Je genauer im Vertriebsprozess und im Projektverlauf die Anforderungen und die Lösung bekannt sind, desto genauer und umfangreicher werden die Risikochecklisten.

1.5 Gliederung der Arbeit

Um die in Kapitel „1.3 Ziele der Arbeit“ gesetzte Ziele zu erreichen, gliedert sich diese Arbeit im Anschluss an das Einführungskapitel in fünf große Teile:

1. Risikomanagement Grundlagen und Konzepte: Beinhaltet die wesentlichen Grundlagen für Risikomanagement, Vorgehens- und Prozessmodelle und organisationales Lernen, auf denen die hier entwickelte Risikomanagement Methode aufbaut. Es fasst den aktuellen Stand der relevanten wissenschaftlichen Forschung auf diesen Gebieten zusammen.
2. Risikomanagement Methode für KMU: In diesem Abschnitt wird die entwickelte Methode beschrieben. Er beinhaltet den grundlegenden Risikomanagementprozess, die angewandten Methoden, die verwendeten Artefakte und den Entwurf eines Werkzeugsets.
3. Fallstudie zur Validierung der Risikomanagement Methode: Beinhaltet die Dokumentation der ersten Anwendung der Risikomanagement Methode in der Praxis. Es werden der Einführungsprozess, die angepassten Artefakte und Werkzeuge und die Erfahrungen aus dem ersten Praxiseinsatz beschrieben.
4. Schlussbemerkungen: Im letzten Bereich finden sich eine Zusammenfassung der Ergebnisse der Arbeit und ein Ausblick auf sich daraus ergebende Themen für weiterführende Forschung.

1.6 Herangehensweise und Forschungsmethode

1.6.1 Überblick über die Vorgehensweise

Erstes Ziel der Arbeit ist die Entwicklung einer Vorgehensweise für das Risikomanagement in KMU auf Basis des aktuellen Standes der wissenschaftlichen Forschung. Dafür sollen in weiterer Folge Werkzeuge entwickelt werden, die in der Praxis validiert, angepasst und verbessert werden. Es wurde dazu folgende Vorgehensweise gewählt (siehe Abbildung 1):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 - Überblick über den Forschungsprozess (Problem > Lösungsidee > Prototyp > Validierung)

Die Anwendung der Erkenntnisse in der Praxis ist nur mehr in Ansätzen Teil dieser Diplomarbeit. Zum Teil wird dies im Rahmen der Fallstudie vorbereitet und begonnen, die Diplomarbeit endet aber nach Abschluss der ersten Pilotprojekte und Validierung und Dokumentation der Ergebnisse. Die vollständige Einführung im Unternehmen ist somit ein weiterführender, über diese Arbeit hinausgehender Teil.

1.6.2 Risikomanagement Methode auf Basis der Literatur entwickeln

Für die Entwicklung der Risikomanagement Methode wurde, ausgehend von der Problemstellung, erst eine Literaturrecherche durchgeführt. Basierend auf deren Ergebnissen wurde dann die Methode konzipiert, siehe Abbildung 2:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 - Entwicklung der Risikomanagement Methode (Literaturrecherche > Methodenkonzept > Checklisten)

Bei der Literaturrecherche wurden als primäre Quelle Onlinekataloge für wissenschaftliche Literatur herangezogen^[11]. Hierbei wurden insbesondere die Kataloge „IEEE“ und „Springerlink“ zur Suche von Artikeln verwendet. Des Weiteren wurden Bücher und Lehrveranstaltungsunterlagen als Quellen eingesetzt.

Bei der Entwicklung der Risikomanagement Methode wurde ein Top-Down Ansatz verfolgt. Es wurden zuerst die groben Prozessschritte für das Risikomanagement definiert und modelliert. Für diese groben Schritte wurden Methoden aus der Literatur gesucht und wenn nötig adaptiert. Da der Großteil der verwendeten Methoden auf Checklisten basiert, wurde für die erste Definition der unterschiedlichen Listen ein Tabellenkalkulationsprogramm verwendet. Dies ermöglichte die schnelle und einfache Erstellung und Überarbeitung von Listen.

1.6.3 Werkzeugprototyp entwickeln

Nach der Konzipierung der Methode wurde im nächsten Schritt ein Werkzeugprototyp für den Einsatz in Pilotprojekten entwickelt. Die Zielsetzung für Entwicklung und Einsatz eines prototypischen Werkzeuges ist es, das Lösungskonzept schnell und einfach in der Praxis überprüfen und Feedback einfließen lassen zu können. Aus diesem Grund wurden für die Erstellung des Prototyps Werkzeuge ausgewählt, mit denen rasch neue Versionen erzeugt, eingesetzt und verändert werden können. In Abbildung 3 ist die Entwicklung der Werkzeuge für den Piloteinsatz dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 - Erstellung der prototypischen Werkzeuge (Spezifikation > Bau des Prototypen)

Das Werkzeug für das Risikomanagement geht über bloße Checklisten hinaus. Es werden u.a. Funktionen für die Erfassung von Maßnahmen, Mehrbenutzerfähigkeit und Datenanalyse gefordert, um nur einige zu nennen. All diese Funktionen können in Tabellenkalkulationsprogrammen nicht mehr abgebildet werden, müssen jedoch im Prototyp vorhanden sein. Es wurde daher nach der inhaltlichen Festlegung der Checklisten in einer Tabellenkalkulation ein Prototyp mit einer Datenbanksoftware erstellt. Dieser wurde dann in den Pilotprojekten eingesetzt und laufend verfeinert.

1.6.4 Fallstudie durchführen

Den letzten Schritt bildete der Einsatz der Methode und des Werkzeugprototypen in einer Fallstudie. Ziel war es hierbei, Methode und Werkzeuge zu validieren und mit den Erfahrungen aus der Praxis in mehreren Durchläufen zu verfeinern, bis ein Status erreicht war, der den Einsatz in allen Projekten des Unternehmens erlaubt. Die für die Fallstudie gewählte Vorgehensweise ist in Abbildung 4 dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 – Vorgehensweise für die Fallstudie (Auswahl Team und Pilotprojekt > Anpassung Checklisten > Einsatz im Pilotprojekt mit mehreren Feedbackzyklen)

Ganz wesentlich ist hierbei vor dem Einsatz die Anpassung der Checklisten an das Unternehmen. Dieser Schritt ist notwendig, da Projekte in jedem Softwareunternehmen anders aussehen und anders abgewickelt werden ^[12].

Nach der Anpassung wurde die Risikomanagement Methode in mehreren Pilotprojekten unter streng kontrollierten Bedingungen eingesetzt. Hierbei wurde nach jedem Prozessschritt ein Feedbackzyklus durchgeführt, bei dem die Checklisten und der Werkzeugprototyp überprüft und angepasst wurden.

Am Ende der Fallstudie standen eine validierte, in mehreren Projekten erfolgreich eingesetzte Methode und ein Werkzeugprototyp als Vorlage für die Entwicklung der produktiven Werkzeuge zur Verfügung.

Zusammenfassung: Im Einführungskapitel wurden nicht behandelte Risiken als eine der Ursachen von gescheiterten Softwareprojekten identifiziert und Risikomanagement als mögliche Lösung dafür vorgestellt. Es wurden die Ziele der Arbeit genannt, nämlich die Entwicklung und Validierung einer Risikomanagement Methode für KMU und die Herangehensweise zur Erreichung dieser Ziele umrissen. Im nächsten Kapitel wird nun der aktuelle Stand der wissenschaftlichen Forschung auf dem Gebiet des Risikomanagements in der Softwareentwicklung dargestellt.

2 Risikomanagement Grundlagen und Konzepte

2.1 Risikomanagement

2.1.1 Einführung und wesentliche Begriffe

Risikomanagement ist ein Management Prozess, welcher aus den Aufgaben Identifikation, Analyse, Planung, Kontrolle, Steuerung und Kommunikation von Risiken besteht [4].

Risiko ist dabei definiert als „die Wahrscheinlichkeit des Eintretens eines unerwünschten Ereignisses in einem bestimmten Zeitraum und der mit dem Ereignis verbundene Schaden, also Eintrittswahrscheinlichkeit mal Schadenshöhe des Ereignisses“ ^[13].

Risiko und Risikomanagement besitzen nach Schmidt 2009 drei Aspekte:

Auf die Zukunft gerichtete Betrachtung: Risikomanagement soll Informationen liefern, welche Gefahrensituationen in der Zukunft möglich und welche Entscheidungen und Handlungen daher in der Gegenwart notwendig sind.

Unsicherheit: Der Ausgang der Situation ist ungewiss, im Risikomanagement arbeitet man mit Wahrscheinlichkeiten, Erfahrungen und Schätzungen.

Möglichkeit eines Schadens: Das Hauptaugenmerk im Risikomanagement liegt auf Ereignissen, die Schaden hervorrufen können.

Unternehmerisches Handeln ohne das Eingehen von Risiken ist nicht möglich. „Das Eingehen von Risiken ermöglicht erst das Erreichen von Zielen, daher bedeutet ein Risiko immer auch eine Chance“ [14]. Carl Amery, deutscher Schriftsteller und Publizist, meinte „Risiko ist die Bugwelle des Erfolgs“.

Entsprechend ist das Ziel des Risikomanagements nicht die Vermeidung jeglichen Risikos, sondern „die Risikosituation so zu steuern, dass sie sich innerhalb eines definierten Bereiches bewegt“ [14]. Dieser Bereich wird „Risikokorridor“ genannt und wird bestimmt vom möglichen Gesamtschaden aller Risiken auf der einen und den Kosten für die Maßnahmen für Risikovermeidung und Minderung auf der anderen Seite. Es ist also zu entscheiden, ob ein möglicher Schaden die Kosten für die Vermeidung des Risikos rechtfertigt. Entsprechend dieser Abschätzung wird es immer Risiken geben, die nicht behandelt werden, da die Kosten für die Maßnahmen den möglichen Schaden übersteigen würden. Die Summe aller nicht behandelten Risiken nennt man „Restrisiko“^[14]

2.1.2 Risiken in der Softwareentwicklung

Es gibt viele Studien, die sich mit den am häufigsten auftretenden Risiken in der Softwareentwicklung beschäftigen. Die wohl bekannteste und am öftesten zitierte Risikoliste ist die Liste der „Top 10 Software Risk Items“ von Barry Boehm [10]:

Tabelle 1 - Top 10 Risiken nach Boehm [10]. (Übersetzung aus dem Englischen vom Autor)

Abbildung in dieser Leseprobe nicht enthalten

Aus der Liste von Boehm ist bereits ersichtlich, dass viele Risiken keine technischen Probleme beschreiben, sondern soziale und organisatorische.

Ein ähnliches Bild wie Boehm zeichnen Wallace, Keil & Rai 2004 in ihrem Modell der Risikodimensionen. Sie teilen dazu Risiken in drei große Subsysteme ein^[15]:

Risiken des sozialen Subsystems

Risiken des technischen Subsystems

Projektmanagement Risiken

Das soziale Subsystem betrachtet die Softwareerstellung als Prozess, der in einen sozialen Kontext eingebettet ist. Aus diesem Kontext ergeben sich Risiken wie Widerstand der Endanwender gegen das neue Softwaresystem, das Abziehen von Ressourcen durch das Management aus politischen Gründen oder zwischenmenschliche Konflikte im Team [15].

Das technische Subsystem betrachtet den Teil der Softwareentwicklung, der sich mit der Erstellung komplexer technischer Artefakte und Dokumente beschäftigt. Aus diesem Subsystem erwachsen Risiken wie hoher Aufwand durch nachträgliche Änderungen an den Anforderungen, Performanceprobleme zur Laufzeit und Ähnliches [15].

Projektmanagement Risiken sind sämtliche Risiken, die sich aus der Planung und Führung des Projektes ergeben. Dies können zum einen Zeitüberschreitungen durch falsche Aufwandsschätzungen und mangelndes Projektcontrolling sein, oder auch Themen wie fehlendes Know-How im Projektteam [15].

Die drei Subsysteme beeinflussen einander gegenseitig, innerhalb der drei Subsysteme definieren Wallace, Keil & Rai 2004 sechs Risikodimensionen (siehe Abbildung 5 und Tabelle 2 auf der nächsten Seite):

Abbildung 5 - Projektsubsysteme und Risikodimensionen nach Wallace, Keil & Rai [15]

Abbildung in dieser Leseprobe nicht enthalten

(Übersetzung aus dem Englischen vom Autor)

Tabelle 2 - Die sechs Risikodimensionen nach Wallace, Keil & Rai 2004

(Übersetzung aus dem Englischen vom Autor)

Eine weitere sehr umfassende Quelle zu Risiken in der Softwareentwicklung ist die Risikotaxonomie von Carr et al. vom Software Engineering Institute (SEI) der Carnegie Mellon University [9].

Die Risiken sind dabei in drei Klassen zusammengefasst, die aus mehreren Elementen bestehen, für die wiederum verschiedene Attribute definiert sind. Auf jeder dieser Ebenen gibt es Fragen, die als Impuls für das Auffinden von Risiken dienen sollen. In Abbildung 6 ist die Hierarchie aus Klassen, Elementen und Attributen dargestellt [9]:

Abbildung 6 - Dreistufige Risikoklassifizierung in Klassen, Elemente und Attribute nach Carr et al. 1993 (Übersetzung aus dem Englischen vom Autor)

Abbildung in dieser Leseprobe nicht enthalten

Basierend auf diesem Klassifizierungsschema wurde vom SEI ein Fragebogen entwickelt, der als Input für ein semistrukturiertes Brainstorming dient, in dem Risiken eines Projektes identifiziert werden sollen. Dieser Fragebogen wird gemeinsam mit anderen Methoden der Risikoidentifikation in Kapitel „2.1.4.1 Risikoidentifikation“ genauer beschrieben.

2.1.3 Risikomanagement Prozess im Überblick

Risikomanagement ist ein kontinuierlicher Prozess, in dem laufend Risiken identifiziert und analysiert, Maßnahmen geplant und ausgeführt, sowie Risiken überwacht und gesteuert werden müssen. In allen Schritten ist Kommunikation ein zentraler Bestandteil [4]. Der kontinuierliche Risikomanagement Kreislauf ist in Abbildung 7 (nächste Seite) dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 – Risikomanagement als kontinuierlicher Prozess aus Identifizieren > Analysieren > Planen > Überwachen > Steuern und Kommunizieren nach Higuera & Haimes 1996

(Übersetzung aus dem Englischen vom Autor)

Risikomanagement ist ein Prozess, der die gesamte Projektlaufzeit über auszuführen ist. Ständig können Risiken entstehen, bestehende Risiken sich in ihren Auswirkungen oder in ihrer Eintrittswahrscheinlichkeit ändern oder Risiken wegfallen.

Nyfiord & Kajko-Mattsson 2008 fügen den oben beschriebenen fünf Prozessschritten zwei weitere hinzu, nämlich „Risikoausscheidung“ und eine „Risiko Post-Mortem Analyse“. In der Risikoausscheidung werden Risiken explizit und kontrolliert als nicht mehr relevant aus der Betrachtung ausgeschieden. Im Risiko Post-Mortem werden Erkenntnisse und Lessons Learned aus dem bisherigen Risikomanagement erarbeitet und sofort in den Prozesszyklus integriert:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8 - Risikomanagementprozess nach Nyfjord & Kajko-Mattsson 2008 mit den zusätzlichen Schritten Risikoausscheidung und Risiko Post-Mortem Analyse

(Übersetzung aus dem Englischen vom Autor)

Im folgenden Abschnitt werden die Teilaufgaben des Risikomanagements beschrieben.

2.1.4 Risikomanagement Aufgaben im Detail

2.1.4.1 Risikoidentifikation

Carr et al. definiert die Risikoidentifikation folgendermaßen: „Bevor Risiken behandelt werden können, müssen sie identifiziert werden. Die Identifikation bringt Risiken an die Oberfläche, bevor sie zu Problemen werden und das Projekt negativ beeinflussen“ [9].

In diesem ersten Schritt im Risikomanagement werden Risiken auf strukturierte Art identifiziert und beschrieben. Es wird dabei davon ausgegangen, dass den einzelnen Projektteammitgliedern die meisten Risiken bekannt sind, oder zumindest erahnt, aber nicht explizit kommuniziert werden [9]. Die in der Literatur am häufigsten zu findenden Methoden zur Risikoidentifikation sind Checklisten, Fragebögen und Brainstorming.

In der Methode des Software Engineering Institutes der Carnegie Mellon University wird ein mehrstufiger Fragebogen mit knapp 200 Fragen als Hilfestellung für ein Brainstorming verwendet („SEI Risk-Taxonomy“). Es wird bei dieser Methode also nicht primär ein Fragebogen ausgefüllt, sondern die Fragen dienen als Denkanstoß, um Risiken zu finden. Der Fragebogen ist somit eher als Gedächtnisstütze zu verstehen, um keine wichtigen Bereiche zu übersehen. Das Ergebnis dieser Methode ist somit nicht eine ausgefüllt fixe Checkliste, sondern eine freie Liste mit den gefundenen Risiken [9]. Tabelle 3 (nächste Seite) zeigt einen kleinen Auszug aus dem SEI Fragebogen.

Tabelle 3 – Beispiele für Fragen aus der SEI Risikotaxonomie

Abbildung in dieser Leseprobe nicht enthalten

(Übersetzung aus dem Englischen vom Autor)

Einen anderen Ansatz auf Basis von Checklisten verfolgen Tiwana und Keil 2004 in ihrem „One-Minute Risk Assessment Tool“. Sie verwenden eine Checkliste mit den sechs wichtigsten Projektrisiken, für die jeweils durch einen numerischen Wert anzugeben ist, inwieweit dieses Risiko auf das Projekt zutrifft (siehe Tabelle 4 auf der nächsten Seite). Die Einzeleinschätzungen werden gewichtet und zu einer Gesamtrisikokennzahl summiert. Auf diese Weise kann sehr rasch eine grobe Risikoabschätzung eines Projektes vorgenommen werden. Die Checkliste dient in dieser Methode nicht als Basis für ein Brainstorming, in dem frei eine Liste von Risiken erstellt wird, sondern das Ergebnis ist direkt eine ausgefüllte Checkliste inklusive einer Risikokennzahl.

Tabelle 4 - Checkliste mit sechs Fragen zur schnellen Berechnung einer Gesamtrisikokennzahl für ein Projekt nach Tiwana und Keil 2004

Abbildung in dieser Leseprobe nicht enthalten

(Übersetzung aus dem Englischen vom Autor)

Die Beurteilung, ob ein Risiko für ein Projekt relevant ist, erfolgt auf Basis eines Vergleichs mit anderen, bereits geschätzten Projekten auf einer Skala von 1 („Gering“) bis 10 („Hoch“). Die Gesamtrisikokennzahl kann einen Wert zwischen 10 und 100 annehmen, je höher der Wert, desto geringer das Risiko:

Abbildung in dieser Leseprobe nicht enthalten

In dieser Methode werden Risiken nicht nur identifiziert, sondern auch gleich bewertet. Vielfach erfolgt dies aber auch erst im nächsten Schritt, der Risikoanalyse.

2.1.4.2 Risikoanalyse und Risikobewertung

„Ziel der Risikoanalyse ist eine qualitative Bewertung bzw. quantitative Messung der Risiken“ [16]. Bei der Bewertung des Gesamtrisikos für ein Projekt müssen die Wechselwirkungen zwischen den Risiken berücksichtigt werden. Verbreitete Methoden zur Risikoanalyse und Gesamtrisikoberechnung sind Barwertmethoden, Schätzmethoden und die Value-At-Risk Methode, „die aussagt, mit welcher Wahrscheinlichkeit eine bestimmte Verlustgrenze in einer festgelegten Periode nicht überschritten wird“^[16].

Die am weitesten verbreitete Möglichkeit das Risiko quantitativ zu bewerten, ist die einfache Risikoformel zur Berechnung des Risikowertes aus Eintrittswahrscheinlichkeit und Schadenshöhe [14]:

Abbildung in dieser Leseprobe nicht enthalten

Da die Eintrittswahrscheinlichkeit nicht direkt, z.B. über statistische Häufigkeitsanalysen bestimmt werden kann, wird die Eintrittswahrscheinlichkeit geschätzt. Die Einstufung erfolgt hierbei meist in Klassen:

Abbildung in dieser Leseprobe nicht enthalten

Die Einschätzung der Eintrittswahrscheinlichkeit ist immer subjektiv und von der Erfahrung und Intuition der beteiligten Personen abhängig [14].

Die Bestimmung der Schadenshöhe erfolgt in zwei Schritten. Zuerst wird ermittelt, welche Art von Schaden verursacht wird. Mögliche Schadensarten sind Personenschäden, Verstöße gehen Gesetze, Vorschriften etc., finanzielle Schäden, Imageschäden und Ähnliches. Im zweiten Schritt wird jedem möglichen Schaden ein monetärer Schadenswert zugeordnet, der dann zu einem Gesamtschaden für das Risiko summiert wird [14].

Sehr oft ist eine exakte monetäre Bewertung der einzelnen Schadensarten kaum möglich. Daher wird auch die Bestimmung der Schadenshöhe oft in Klassen durchgeführt [14].

Sind Eintrittswahrscheinlichkeit und Schadenshöhe bekannt, können Risikowerte berechnet und die Risiken in einer Risikomatrix bzw. einem Risikoportfolio dargestellt werden [16] (siehe Abbildung 9). Im Risikoportfolio kann zu jedem Risiko zusätzlich ein Zielbereich eingetragen werden, in den das Risiko durch geeignete Maßnahmen zu bringen ist. Es ist daher auch gut als Werkzeug für die Risikoplanung einsetzbar:

Abbildung 9 - Darstellung der Risiken in einem Risikoportfolio nach Junginger & Krcmar

Abbildung in dieser Leseprobe nicht enthalten

Durch die Darstellung in einer Risikomatrix kann die Risikolage eines Projektes sehr schnell erfasst werden.

Die quantitative Bewertung von Risiken mittels der einfachen, zweidimensionalen Risikoformel birgt jedoch einige Gefahren [14]:

Der Wert für die Eintrittswahrscheinlichkeit ist meist nicht statistisch abgesichert und kann somit leicht manipuliert werden.

Es wird eine Genauigkeit vorgetäuscht, die nicht vorhanden ist.

Aufgrund der einfachen Multiplikation ergeben viele kleine aber wahrscheinliche Schäden denselben Gesamtrisikowert für ein Projekt wie ein unwahrscheinliches Risiko mit sehr hohem Schaden.

Am Risikowert ist nicht ersichtlich, ob es sich um einen Best-Case, einen Worst-Case oder ein realistisches Szenario handelt.

Um diese Probleme mit der Risikoformel und dem damit berechnet Risikowert zu umgehen, gibt es einige Vorschläge aus der Literatur:

Einführen einer Gewichtung [14]:

Abbildung in dieser Leseprobe nicht enthalten

Berücksichtigung der Entdeckungswahrscheinlichkeit ^[17]:

Abbildung in dieser Leseprobe nicht enthalten

mit R(A) als Entdeckungswahrscheinlichkeit des Risikos

Zum Teil wird auch komplett auf eine Berechnung des Risikowertes verzichtet und jedem Risiko lediglich ein einziger Wert zugeordnet, der der subjektiv geschätzten Schwere des Risikos im Sinne einer Handlungsdringlichkeit entspricht ^[18].

2.1.4.3 Risikoplanung und Maßnahmenentwicklung

Sind alle Risiken bekannt und bewertet, ist der nächste Schritt die Risikoplanung. In der Risikoplanung wird eine Auswahl getroffen, welche Risiken behandelt werden müssen und welche Maßnahmen zu treffen sind [4].

Je nach Art und Schwere des Risikos, können folgende Arten von Maßnahmen getroffen werden [14]:

Maßnahmen zur Risikovermeidung: Das Produkt oder der Entwicklungsprozess wird so verändert, dass das Risiko nicht mehr existiert.

Maßnahmen zur Risikoeliminierung: Es werden einer oder mehrere Faktoren, die zum Eintreten des Risikos führen beseitigt.

Maßnahmen zur Risikoverminderung: Der Risikowert wird verringert, indem Maßnahmen getroffen werden, die die Eintrittswahrscheinlichkeit und/oder den entstehenden Schaden reduzieren.

Maßnahmen zur Risikoabwälzung: Das Risiko wird auf Dritte abgewälzt.

Die Entwicklung und Umsetzung von Maßnahmen kostet Geld und Zeit. Aus diesem Grund ist es notwendig, eine Priorisierung der Risiken vorzunehmen und sich auf die wichtigsten zu konzentrieren. Die Priorisierung kann nach verschiedenen Regeln vorgenommen werden:

1. Es werden nur die wichtigsten zehn Risiken basierend auf dem berechneten Risikowert behandelt [10].
2. Es werden, beginnend mit den wichtigsten, die Risiken soweit reduziert, bis das Gesamtrisiko des Projektes innerhalb des definierten Risikokorridors liegt [14].
3. Beginnend mit den am höchsten bewerteten Risiken werden Risiken solange reduziert, bis nur noch 20% des ursprünglichen Gesamtrisikowertes als Restrisiko übrigbleiben (80:20 Regel) [14].
4. Es werden alle Risiken behandelt, deren Risikowert über einem bestimmten Schwellenwert liegt.

Nachdem die Risiken priorisiert und die Maßnahmen geplant sind, kann berechnet werden, wie hoch das noch verbleibende Risiko ist. Dieses wird als „Restrisiko“ bezeichnet und muss von den Projektverantwortlichen übernommen werden [14].

2.1.4.4 Risikoüberwachung und -steuerung

Ist die Risikoplanung abgeschlossen, kann die Durchführung des Projektes und die Umsetzung der Maßnahmen begonnen werden. Dabei wird laufend eine Risikoüberwachung- und Steuerung vorgenommen.

Unter Risikoüberwachung versteht man die Verfolgung des Status der identifizierten Risiken und der Maßnahmenumsetzung. Zur Risikoüberwachung werden Metriken verwendet, die eine Beurteilung der Risiken und auch der Effektivität der Maßnahmen erlauben [4].

Als Risikometrik wird entweder der Risikowert, berechnet mit der Risikoformel oder einer ihrer Varianten empfohlen [14], bzw. die Erweiterung und Verdichtung der Werte zu einem Risikobaum, in dem die monetär bewerteten Risiken zu Szenarien gruppiert und weiter bis zum Gesamtprojektrisiko aggregiert werden [17].

Neben der Überwachung der Risiken selbst, können für jedes Risiko definierte Auslöser („Trigger“) überwacht werden. Diese zeigen frühzeitig an, dass ein Risiko schlagend werden wird [4].

Die Risikoüberwachung wird während des gesamten Projektes immer wieder durchgeführt. Nyfjord et al. schlagen vor, den Risikostatus zum einen in täglichen Statusmeetings, zum anderen bei Erreichen von bestimmten Meilensteinen („Checkpoints“) zu kontrollieren. Die Risikoüberwachung soll zumindest bei folgenden Meilensteinen durchgeführt werden:

1. Umfang einer Iteration ist festgelegt
2. Aufgabenplanung für eine Iteration ist abgeschlossen
3. Iteration ist fertig umgesetzt

Zwischen diesen Fixpunkten werden Risiken täglich von Entwicklern und Projektleitern überwacht [12].

Basierend auf dem in der Risikoüberwachung erhobenen Risikostatus werden in der Risikosteuerung Anpassungen an den Maßnahmen zur Risikominderung und -abwehr vorgenommen. Ziel der Risikosteuerung ist es, das Gesamtrisiko im definierten Risikokorridor zu halten und Abweichung vom Plan zu korrigieren. Risikoüberwachung und -steuerung gliedern sich dabei nahtlos ins normale Projektmanagement, speziell ins Projektcontrolling (Fortschrittskontrolle, Kostenkontrollen, etc.) ein [4]. Sehr wichtig sind hierbei Werkzeuge, wie z.B. Reporting Werkzeuge, die ein effektives und effizientes Monitoring ermöglichen.

2.1.4.5 Risiko Post-Mortem Analyse

Ist das Projekt abgeschlossen, erfolgt rückblickend eine Analyse, ob das Projekt und das Risikomanagement erfolgreich waren, um das neu gewonnene Wissen zu beurteilen und für die Zukunft nutzbar zu machen. In jedem Projekt werden technische Problemlösungen und Maßnahmen zur Risikominimierung entwickelt und alle möglichen Erfahrungen technischer und organisatorischer Natur gemacht. Ein Großteil dieses Wissens könnte in ähnlichen Projekten und von anderen Teams angewandt werden.

Diese Wiederverwertung von Wissen passiert aber oft nicht oder in sehr geringem Ausmaß. Die Hauptgründe dafür sind [5]:

1. Es ist keine Zeit für eine Analyse und Aufarbeitung der Erfahrung, sowie für die Wissensweitergabe vorhanden, das Projektteam eilt sofort ins nächste Projekt.
2. Es gibt keine definierten Prozesse und Methoden, wie Wissen zwischen Personen und Projektteams weitergegeben wird.
3. Die Träger des Wissens haben Angst vor der Weitergabe, da die eigene Position scheinbar geschwächt wird, wenn man einen Wissensvorsprung aufgibt.

Wird das in einem Projekt gesammelte Wissen strukturiert aufbereitet und weitergegeben, so kann das Unternehmen als Ganzes lernen und von Projekt zu Projekt besser werden. Passiert dies nicht, bleibt der Erfolg eines Projektes stark von den individuellen Erfahrungen der beteiligten Mitarbeiter abhängig und das Risiko ist hoch, dass dieselben Fehler immer wieder gemacht werden. Die Nicht-Weitergabe von Wissen an sich ist ein hohes Risiko für ein Unternehmen.

Eine Methode zur Aufbereitung und Weitergabe von Erfahrungen ist die Durchführung von Projektreviews (Projekt Retrospektive, Projekt Post-Mortem, Post-Mortem-Analyse). Desouza et al. definieren ein Projektreview als „eine Aktivität des gemeinsamen Lernens, die für ein Projekt entweder bei Erreichen eines bestimmten Meilensteines oder am Projektende durchgeführt werden kann. Die Hauptmotivation ist eine Reflexion, was geschehen ist, um zukünftiges Arbeiten zu verbessern und zwar sowohl für die am Projekt beteiligten Individuen, als auch für das Unternehmen als Ganzes.“^[19].

In Bezug auf Risikomanagement bedeutet dies, dass Erfahrungen weitergegeben werden, welche Risiken aufgetreten sind, welche Maßnahmen erfolgreich waren und was in Zukunft zur Verbesserung der Risikoabwendung getan werden kann.

Zum Ablauf eines Projektreviews gibt es in der Literatur sehr viele Vorschläge. Allen gemeinsam ist eine Strukturierung in drei Phasen ^[20], ^[21], ^[22]:

1. Vorbereitungsphase: Wichtige Daten zum Projekt werden gesammelt und ausgewertet. Dies sind Dokumente, die den Projektablauf beschreiben (Projektpläne, Protokolle, etc.), sowie Kennzahlen zum Projekterfolg (Plan / Ist Zahlen für Kosten, Zeit, Aufwand etc., Messgrößen für die Projektgröße wie z.B. Lines of Code etc.).
2. Durchführung: Ein Review-Workshop wird durchgeführt, in dem die Erfahrungen aus dem Projekt gesammelt und bearbeitet werden. Hierfür gibt es eine große Vielzahl an Vorschlägen für Dauer (wenige Stunden bis hin zu mehreren Tagen) und Ablauf (Brainstorming, Dokumentenreview, Methodenmix von Teambuilding bis Lessons-Learned-Analyse, etc.).
3. Aufbereitung und Publikation der Ergebnisse: Die Erfahrungen aus dem Projekt werden in strukturierten Reports, kurzen Geschichten, Fallstudien etc. beschrieben und allen Mitarbeitern zugänglich gemacht, indem sie z.B. als Newsletter verschickt oder im Intranet veröffentlicht werden.

Aufgrund der Vielzahl an in der Literatur vorhandenen Konzepten und Methoden für Projektreviews ist eine Anpassung an das konkrete Unternehmen und dessen Zielsetzungen besonders wichtig. Viele der Methoden sind in KMU nicht einsetzbar, ein mehrtägiger Workshop mit allen Projektbeteiligten z.B. steht in der Regel in keinem sinnvollen Verhältnis zur oft geringen Projektgröße und ist so nicht durchführbar.

2.2 Risikomanagement in ausgewählten Projektvorgehensmodellen

Im Folgenden wird beschrieben, wie Risikomanagement in bekannten und vielfach angewandten Prozessvorgehensmodellen integriert ist. Es wurden dazu das Spiralmodell von Boehm ^[23] und SCRUM ^[24] ausgewählt, da diese in KMU Softwareunternehmen häufig verwendet werden.

2.2.1 Risikomanagement im Spiralmodel

Das Spiralmodell von Boehm ist ein „risikogetriebener Prozessmodellgenerator“ [23]. Es beschreibt einen Rahmen für die Vorgehensweise in Softwareprojekten. Es teilt die Entwicklung in zyklische Iterationen auf, wobei in jeder Iteration der Fertigstellungsgrad steigt und das verbleibende Risiko sinkt. Am Ende jeder Iteration steht ein bestimmtes Produkt, die Entwicklung des Produktes erfolgt mit einer frei wählbaren Vorgehensmethode (z.B. Wasserfallmodell, SCRUM, etc.; siehe Abbildung 10). In jedem Projekt werden Anker-Meilensteine festgelegt. Zu diesen Meilensteinen entscheiden die Stakeholder, ob das Projekt weitergeführt wird und ob die gefundenen Lösungen tragbar und sinnvoll sind [23].

Abbildung 10 - Das Spiralmodel von Barry Boehm mit einer Risikoanalyse als Startpunkt jeder Iteration [23]. Grafik aus ^[25]

Abbildung in dieser Leseprobe nicht enthalten

Im Spiralmodell ist Risikomanagement fix am Beginn jeder Iteration vorgesehen. Boehm bezeichnet die „risikogetriebene Festlegung von Prozess und Produkt“ [23] als ein Kernelement des Modells. Durch eine solche risikogetriebene Vorgehensweise können „Entwicklungskosten gesenkt, schlechte Alternativen von vorneherein ausgeschieden und unnötiger Aufwand für Nacharbeiten vermieden werden“ [23]. Je nach Ergebnis der Risikoanalyse wird für die Iteration dann ein passendes Vorgehensmodell gewählt. Die Risikoanalyse hilft also zu entscheiden, was, wie und wie lange als nächstes getan wird [23].

In den Invarianten, d.h. den unabdingbaren Grundprinzipien des Spiralmodells sind ebenfalls Hinweise auf den Einsatz von Risikomanagement enthalten [23]:

1. Alle Kernartefakte werden gleichzeitig festgelegt (Pläne, Anforderungen, Betriebskonzept, Design, Code).
2. In jedem Zyklus werden Ziele, Einschränkungen, Alternativen und Risiken bestimmt, Reviews durchgeführt und die Zustimmung aller Stakeholder eingeholt.
3. Der Aufwand wird durch Risikoabschätzungen bestimmt.
4. Der Detailierungsgrad der in der Iteration entwickelten Lösung hängt von Risikoüberlegungen ab.
5. Es werden die Anker-Meilensteine: Life Cycle Objektives (LCO), Life Cycle Architecture (LCA) und Initial Operational Capability (IOC) verwendet.
6. Das Hauptaugenmerk liegt auf System- und Lebenszyklusaktivitäten und artefakten.

Die Invarianten (2), (3) und (4) drücken aus, wann und mit welchem Ziel Risikomanagement ins Spiralmodell integriert wird. Boehm gibt jedoch keine genauen Anweisungen, wie die Risikoanalyse durchgeführt werden soll. Die in dieser Diplomarbeit entwickelte Methode stellt eine Möglichkeit dar, die im Spiralmodell geforderte Risikoanalyse durchzuführen.

2.2.2 Risikomanagement in SCRUM

SCRUM ist eine Erweiterung der iterativen und inkrementellen Softwareentwicklungsmethode. Der Kerngedanke hinter SCRUM ist, dass viele Prozesse in der Softwareentwicklung nicht vollständig definiert und beherrschbar sind. Flexibilität in der Reaktion auf Änderungen an den Anforderungen und unvorhergesehene technische Entwicklungen ist daher der zentrale Erfolgsfaktor. Um dies zu berücksichtigen, wird ein Projekt in folgende Phasen eingeteilt (siehe Abbildung 11 auf der nächsten Seite) [24]:

Abbildung 11 - Übersicht über die Softwareentwicklung mit SCRUM [24]

Abbildung in dieser Leseprobe nicht enthalten

(Übersetzung aus dem Englischen vom Autor)

1. Planung und Architektur: In definierten Prozessen wird das Projekt initial geplant (Anforderungen, Zeitplan, Kosten, etc.) und eine Systemarchitektur erstellt.
2. Evolutionäre Umsetzung in Iterationen: Die eigentliche Umsetzung erfolgt in sehr kurzen Iterationen (Sprints). In jedem Sprint wird neu festgelegt, welche Funktionen umgesetzt werden. Dies können nun Funktionen aus der ursprünglichen Anforderungsliste (Product Backlog) sein, oder auch neue bzw. geänderte Anforderungen des Kunden. Die Funktionen werden dann in einem fixen Zeitrahmen umgesetzt. Am Ende eines Sprints ist eine neue Version des Produktes verfügbar und es wird ein Review des Produktes und des Sprints durchgeführt. Viele Prozesse innerhalb eines Sprints sind undefiniert und laufen ungesteuert ab.
3. Abschluss: Ist die Entwicklung abgeschlossen, erfolgen Abnahmetest, die produktive Installation, Dokumentation etc. Die Prozesse in dieser Phase sind wieder definiert und gesteuert.

Sowohl die im fertigen Produkt enthaltenen Funktionen, als auch Fertigstellungszeit und Kosten können sich im Laufe des Projektes ändern. In jedem Sprint werden die umzusetzenden Punkte neu verhandelt und festgelegt. So kann das Team sehr flexibel auf Änderungen und unerwartete Ereignisse reagieren, das Produkt entspricht am Ende mit sehr hoher Sicherheit den Erwartungen des Kunden [24].

Risikomanagement ist eine der zentralen Kontroll- und Steuerungsmechanismen in SCRUM. Es ist an folgenden Stellen ins Vorgehensmodell integriert [24]:

1. Während der Planungsphase am Beginn des Projektes: Basierend auf den Anforderungen und der Architektur werden Risiken identifiziert, analysiert und entsprechende Maßnahmen entwickelt. Die Länge der Sprints wird entsprechend dem Projektrisiko festgelegt. Je höher das Risiko, desto kürzer die Sprints.

2. Während jedes Sprints: Es werden laufend Reviews der Risiken und ggf. Anpassungen der Maßnahmen durchgeführt. Ein Vorschlag hierfür ist, dies direkt in die täglichen Teammeetings zu integrieren.

Somit fordert auch SCRUM ein aktives Identifizieren, Behandeln und Kontrollieren von Risiken und entsprechenden Maßnahmen.

2.3 Risikomanagement im Kontext der Organisationsentwicklung

In diesem Abschnitt wird Risikomanagement nicht im Kontext eines Projektes, sondern in seiner Einbettung und seinen Wechselwirkungen im Gesamtunternehmen betrachtet.

Unternehmen müssen sich weiterentwickeln, sonst werden sie vom Markt verdrängt. Dies gilt besonders für kleine Softwareunternehmen, für die es zum einen viel Konkurrenz durch andere KMU gibt, zum anderen die Gefahr droht, dass sie von großen Anbietern und deren Standardlösungen verdrängt werden. Überlebenswichtig ist es somit, dass sich das Unternehmen ständig verbessert, aus Fehlern der Vergangenheit lernt, sich noch besser an die individuellen Anforderungen seiner Kunden anpassen kann und Projekte effektiv, effizient und reproduzierbar erfolgreich abwickelt. Gerade in letztem Punkt steckt eine der größten Herausforderungen für KMU, nämlich die starke Personenabhängigkeit zu verringern und das in den Köpfen einzelner vorhandene Wissen für alle nutzbar zu machen.

2.3.1 Risikomanagement und Organisationsentwicklung

Risikomanagement ist nicht statisch, sondern muss sich, wie das Unternehmen selbst, ständig weiterentwickeln. Unternehmen als Organisationen bestehen aus Handlungen und entwickeln sich über Entscheidungen weiter. Diese wiederum sind in der Realität immer Entscheidungen unter Unsicherheit und somit mit Risiken verbunden. Ziel ist es meist, nicht optimale Lösungen zu generieren, sondern diejenige Lösung, die mit geringstem Aufwand die gesteckten Ziele erreicht. Um solche Lösungen entwerfen zu können, muss die Komplexität und die Unsicherheit der Entscheidungssituation reduziert werden. Dies wiederum erreichen Unternehmen, indem sie Routinen und Regeln entwickeln, die helfen neue Situationen zu bewältigen und die richtigen Entscheidungen zu treffen. In der Wissenschaft ist die Beschäftigung mit solchen Routinen und deren strukturierte Entwicklung, Einführung und laufende Umsetzung als Teilbereich der Betriebswirtschaftslehre im Zweig Organisationsentwicklung angesiedelt. Diese beschäftigt sich also mit Entwicklung, Aufbau und Veränderung von Organisationen und deren Routinen ^[26].

Die in dieser Diplomarbeit entwickelte Risikomanagement Methode ist selbst eine solche Routine, die dem Unternehmen hilft, die komplexen Risiken eines Softwareprojektes beherrschbar zu machen. Risikomanagement hat mit dem Bereich Organisationsentwicklung drei große Berührungspunkte:

1. Risikomanagement als Unternehmensroutine: Risikomanagement und seine Methoden sind selbst Routinen, die Unternehmen zur Verringerung der Komplexität und Unsicherheit einsetzen.
2. Risikomanagement als Quelle für die Weiterentwicklung des Unternehmens: Die Erkenntnisse aus den Risikoanalysen der Projekte sind Quelle und Auslöser für Veränderungen im Unternehmen.
3. Einführung von Risikomanagement als Veränderungsprojekt: Die Einführung und laufende Verbesserung der Risikomanagement Methoden stellt selbst ein Veränderungsprojekt dar. Gerade die Einführung bedarf einer guten Planung und Steuerung. Hier können Erkenntnisse aus Organisationsentwicklung und Change Management eingesetzt werden, um Risikomanagement erfolgreich im Unternehmen zu etablieren.

2.3.2 Risikomanagement und Organisationales Lernen

Im Risikomanagement wird ständig Wissen über Risiken und Maßnahmen verbessert, neu generiert und weitergegeben. Somit kommen auch für Risikomanagement viele Erkenntnisse aus dem Bereich des organisationalen Lernens zum Tragen. Die Lernprozesse im Unternehmen spielen sich auf verschiedenen Ebenen ab (siehe Abbildung 12) [27]:

Abbildung 12 – Organisationales Lernen als Überführung des Lernens des Individuums hin zur Gruppe und weiter zum Lernen der Organisation über die Anpassung von Regeln und Routinen [27].

Abbildung in dieser Leseprobe nicht enthalten

(Übersetzung aus dem Englischen vom Autor)

Die unterste Ebene ist dabei das individuelle Lernen der handelnden Personen, indem diese durch neue Entscheidungen und die intuitive Anwendung des vorhandenen Wissens neues Wissen aufbauen. Auf zweiter Ebene geschieht Lernen in der Gruppe, z.B. in einem Projektteam. Gemeinsam wird eine globale Sichtweise, eine kognitive Landkarte erstellt. Das individuell Gelernte wird dabei ständig interpretiert und in die bestehenden Modelle der Wirklichkeit eingebaut. Auf oberster Ebene steht das Lernen der Organisation insgesamt. Dies geschieht durch Institutionalisierung des neu erlernten Wissens, indem dieses als unternehmensweit gültige Regeln und Routinen etabliert wird. Diese Routinen werden dann in allen Projektteams von den einzelnen Teammitgliedern angewandt. Es entsteht ein Lernkreislauf [27].

Organisationales Lernen kann also als die Überführung der Erfahrungen von Einzelpersonen (individuelles Lernen) in das für alle anwendbare und gelebte Regelwerk der Organisation bezeichnet werden. Bei diesem Vorgang ist zu beachten, dass nicht automatisch jede Einzelerfahrung in eine unternehmensweite Regel überführt werden darf. Dies würde zu einer unkontrollierten Veränderung des Unternehmens führen und die Organisation handlungsunfähig machen. Zentraler Baustein eines strukturierten organisationalen Lernens ist somit eine Kontrolle und Auswahl, welches Wissen in den globalen Routinenschatz des Unternehmens übernommen wird ^[27].

Für das Risikomanagement ergeben sich im Kontext des organisationalen Lernens folgende Erkenntnisse und Herausforderungen:

[...]

---

[1] L. Eveleens und C. Verhoef, „The Rise and Fall of the Chaos Report Figures,“ IEEE, Amsterdam, 2010.

^[2] J. S. Reel, „Critical Success Factors In Software Projects,“ IEEE, 1999.

^[3] S. Islam und S. H. Houmb, „Integration Risk Management Activities into Requirements Engineering,“ IEEE, München, Norwegen, 2010.

^[4] R. Higuera und Y. Haimes, „Software Risk Management,“ Software Engineering Institute, Pittsburg, 1996

^[5] M. Schindler und M. Eppler, „Harvesting project knowledge a review of project learning methods and success factors,“ International Journal of Project Management 21, p. 219–228, 2003.

^[6] E. Kommission, Die neue KMU-Definition - Benutzerhandbuch und Mustererklärung, Brüssel, 2006.

^[7] A. Fuller, P. Croll und O. Garcia, „Why Software Engineering is Riskier than Ever,“ IEEE, Wollongong, 2001.

^[8] M. Sivashankar, A. Kalpana und A. Jeyakumar, „A Framework approach using CMMI for SPI to Indian SME's,“ IEEE, Salem, 2010

^[9] M. Carr, S. Konda, I. Monarch, C. Ulrich und C. Walker, „Taxonomy-Based Risk Identification,“ Software Engineering Institute, Pittsburgh, 1993

^[10] B. Boehm, „Software Risk Management: Principles and Practices,“ IEEE, 1991

^[11] „Digitale Bibliothek,“ 2011. [Online]. Available: http://www.jku.at/UB/content/e997/. [Zugriff am 2011].

^[12] J. Nyfjord und M. Kajko-Mattsson, „Outlining a Model Integrating Risk Management and Agile Software Development,“ IEEE, Stockholm, 2008

^[13] L. Heinrich und F. Roithmayr, Wirtschaftsinformatik-Lexikon, München, Wien: Oldenbourg Verlag, 1998

^[14] K. Schmidt, „IT-Risikomanagement,“ in Handbuch IT-Management, München, Carl Hanser Verlag, 2009, pp. 537-574.

^[15] L. Wallace, M. Keil und A. Rai, „How Software Project Risk Affects Project Performance: An Investigation of the Dimensions of Risk and an Exploratory Model,“ Decision Sciences Vol. 35 No. 2, 2004.

^[16] M. Junginger und H. Krcmar, „IT Risk Management – Fit für E-Business?,“ in Information Age Economy, Heidelberg, Physica-Verlag, 2001, pp. 295-408.

^[17] G. Roy, „A Risk Management Framework for Software Engineering Practice,“ IEEE, Perth, 2004

^[18] A. Tiwana und M. Keil, „The One-Minute Risk Assessment Tool,“ Communications of the ACM, Vol. 47, No. 11, pp. 73-77, 2004

^[19] K. C. Desouza, T. Dingsøyr und Y. Awazu, „Experiences with Conducting Project Postmortems: Reports vs. Stories and Practitioner Perspective,“ IEEE, Hawaii, 2005

^[20] A. Birk, T. Dingsøyr und T. Stålhane, „Postmortem: Never Leave A Project Without It,“ IEEE, Norwegen, 2002.

^[21] B. Collier, T. De Marco und P. Fearey, „A Defined Process For Project Postmortem Review,“ 1996.

^{[22] [22]} N. Kerth, Postmortem: Projekte erfolgreich auswerten, Bonn: mitp-Verlag, 2003.

^[23] B. Boehm, „Spiral Development: Experience, Principles, and Refinements,“ IEEE, Pittsburgh, 2000.

^[24] K. Schwaber, „SCRUM Development Process,“ Burlington, 1997.

^[25] Diverse, „Spiralmodell,“ http://de.wikipedia.org/wiki/Spiralmodell, 2008. [Online]. Available: http://de.wikipedia.org/wiki/Spiralmodell. [Zugriff am 27 07 2011].

^[26] W. H. Güttel, „Architekturen der Verhaltenssteuerung: Human Resource Management, Change Management and Leadership; Teil 3: Routinen und (Entscheidungs-)regeln als Bausteine der Organisation,“ Linz, 2011

^[27] W. H. Güttel, „Architekturen der Verhaltenssteuerung: Human Resource Management, Change Management and Leadership; Teil 10: Wissen und Lernen,“ Linz, 2011