Risikomanagement beim

Softwareprojektmanagement

Seminararbeit

Eingereicht bei: Univ.-Prof. Dr. Dr. habil. Horst Wildemann

Betreuer: Dipl. Ing. Franz Alt

von: Joachim Burkhardt

Studiengang MBA

2. Semester

Abgabetermin: 28. Juni 2004

- I -

Inhaltsverzeichnis

Inhaltsverzeichnis ................................................................................................... I

Abbildungsverzeichnis........................................................................................... II

Abkürzungsverzeichnis.......................................................................................... II

1 Einleitung ........................................................................................................1

2 Gründe für das Scheitern von Softwareprojekten ...........................................3

3 Risikomanagement bei der Softwareentwicklung...........................................7

3.1 Einführung ...............................................................................................7

3.2 Risikoidentifikation................................................................................10

3.3 Risikoanalyse .........................................................................................12

3.4 Risikoplanung ........................................................................................15

3.5 Risikoüberwachung................................................................................20

4 Spezielle Risiken beim Outsourcing von Softwareprojekten........................21

5 Zusammenfassung .........................................................................................24

Literaturverzeichnis ..............................................................................................III

- II -

Abbildungsverzeichnis

Abb. 1: Erfolgreiche und gescheiterte IT-Projekte.................................................4

Abb. 2: Projektrisikomanagement-Kreislauf. .........................................................8

Abb. 3: Das SEI Risikomanagement-Schema. .......................................................9

Abb. 4: Risikodokumentations-Formular .............................................................12

Abb. 5: Risikoportfolio .........................................................................................14

Abb. 6: Abhängigkeitsgraph von Risiken.............................................................15

Abb. 7: Risiko (R) nach Risikovermeidung (1), Risikoverminderung (2), … .....17

Abb. 8: Wirkungsmatrix zur Risikoplanung.........................................................19

Abkürzungsverzeichnis

ACM Association for Computing Machinery

AktG Aktiengesetz

IEEE Institute of Electrical and Electronics Engineers

KonTraG Gesetz zur Kontrolle und Transparenz im Unternehmensbereich

NIVADIS Niedersächsisches Vorgangsbearbeitungs-, Analyse-, Dokumentati-

ons- und Informationssystem

SEI Software Engineering Institute (at the Carnegie Mellon University)

USAF United States Air Force

- 1 -

1 Einleitung

In fast allen Bereichen der Wirtschaft spielt heute die Datenverarbeitung und

damit die Softwareentwicklung eine entscheidende Rolle. Nicht nur von Natur

aus sehr stark datenverarbeitungsgestützte Bereiche wie Banken und Versiche-

rungen, sonder auch klassische Industriebetriebe, sind heute auf die elektronische

Datenverarbeitung angewiesen. Softwarelösungen sind in viele Geschäftsprozes-

se sehr stark integriert, wie beispielsweise weltweit per Internet verfügbare Busi-

ness to Business Plattformen. Bei manchen Unternehmen hängt sogar das gesam-

te Vertriebsmodell von einer Online-Vertriebsplattform ab. Die eingesetzte Soft-

ware kann also maßgeblich zum Erfolg oder Misserfolg einer Unternehmung bei-

tragen und wird immer mehr zu einem entscheidenden Faktor. Trotz dieser ent-

scheidenden Stellung der Software, läuft die Softwareentwicklung heute oft noch

sehr unkontrolliert ab, wie verschiedene Studien über gescheiterte Softwarepro-

jekte zeigen.1 Prominente Beispiele für gescheiterte Softwareprojekte sind die

Finanzamt-Software „Fiskus“2 oder das Polizei-Computersystem NIVADIS.3

In dieser Arbeit soll zunächst aufgezeigt werden, welche Gründe für das Schei-

tern von Softwareprojekten verantwortlich sind und kurz etablierte Prozessmo-

delle zur Softwareentwicklung vorgestellt werden. Solche Prozessmodelle struk-

turieren den Entwicklungsprozess nach vorgegebenen Standards und ermögli-

chen die Installation von Risikomanagementsystemen zur proaktiven Behandlung

von Risiken. Ein proaktives Risikomanagementsystem reagiert nicht erst beim

Eintritt eines Risikos, sondern integriert den Umgang mit Risiken durch Vorbeu-

gende Maßnahmen, Notfallpläne und stetige Überwachung in den Entwicklungs-

prozess. Ein solchen Risikomanagementsystems kann aus den Bausteinen Risiko-

identifikation, Risikoanalyse, Risikoplanung und Risikoüberwachung bestehen,

welche in dieser Arbeit beschrieben werden.

1 Vgl. Gaulke (2001), S. 30f. 2 Vgl. Klesse (2004), [Stand 26.6.2004]. 3 Vlg. Mansmann (2004), [Stand 26.6.2004].

- 2 -

Um Kosten einzusparen, geht ein Trend bei der Softwareentwicklung heutzutage

zum Outsourcing von Entwicklungsprojekten. Besonders großes Einsparungspo-

tential verspricht man sich vom so genannten Offshore Outsourcing, d. h. der

Vergabe von Projekten an Outsourcing-Unternehmen in Länder mit sehr niedri-

gem Lohnniveau, die außerhalb des eigenen Kulturkreises liegen, wie Indien,

China oder Russland. Outsourcing und Offshore Outsourcing bergen zusätzliche

Risiken für ein Softwareprojekt, die in einem Risikomanagementsystem berück-

sichtigt werden müssen. Auf diese speziellen Risiken soll im letzten Abschnitt

der vorliegenden Arbeit eingegangen werden.

- 3 -

2 Gründe für das Scheitern von Softwareprojekten

Die Entwicklung von Software weist die typischen Eigenschaften eines Projektes

auf: große Bedeutung des Projektergebnisses, Einmaligkeit, zeitliche Befristung,

großer Umfang, Komplexität, Innovation, begrenzte Ressourcen (z. B. Budget

und Personal) und Risikobehaftung.4 Das Projektmanagement muss den Projekt-

ablauf so steuern, dass die vorgegebenen Ziele im Spannungsfeld von Ressour-

ceneinsatz, Zeit und Leistung bzw. Qualität erreicht werden. Im Unterschied zu

anderen Projekten ist das Ergebnis jedoch rein immateriell und erfordert große

kreative und schöpferische Leistungen. Der immaterielle Charakter von Software

erschwert hierbei eine genaue Überwachung des Projektfortschritts durch die

Projektleitung. Auch der Einsatz von sehr fortschrittlichen, oft unerprobten Tech-

nologien unterscheidet Softwareprojekte von anderen Projekten. Vor allem auf-

grund des kreativen Charakters der Softwareentwicklung, laufen Softwareprojek-

te oft ohne ausreichende Prozesskontrollen ab, obwohl der Umfang der Projekte

meist sehr erheblich ist. Indikatoren für unkontrolliert ablaufende Prozesse bei

der Softwareentwicklung sind:5

• Wiederauftauchen bereits korrigierter Fehler.

• Verlust von Source-Code.

• Fehlende Dokumentation von Programmveränderungen.

• Redundante Wartung und Entwicklung.

• Test und Integration von falschen (z. B. veralteten) Modulen.

Solche unkontrollierten Prozesse können letztendlich zum Scheitern von Soft-

wareprojekten oder zum Verfehlen von vorgegebenen Zielen führen. Von einem

gescheiterten Softwareprojekt spricht man, wenn das Projekt während der Ent-

wicklungszeit eingestellt wird oder die entwickelte Software nie eingesetzt wird.6

Von einem nur teilweise erfolgreichen Projekt ist die Rede, wenn eine Software

zwar fertig gestellt wurde und eingesetzt wird, jedoch die geplanten Ressourcen

4 Vgl. Gaulke (2002), S. 9f. 5 Vgl. Gaulke (2001), S. 40. 6 Vgl. The Standish Group International Inc. (2001), S 2.

- 4 -

überschritten, der Zeitplan nicht eingehalten oder weniger Funktionen implemen-

tiert wurden als geplant.

Die Unternehmensberatung The Standish Group untersucht seit 1994 in zweijäh-

rigem Rhythmus den Erfolg von IT-Projekten amerikanischer Unternehmen.7 Die

Daten aus Abb. 1 zeigen zwar, dass der Anteil an erfolgreichen Softwareprojek-

ten seit 1994 leicht gestiegen ist, jedoch immer noch weniger als ein drittel aller

Softwareprojekte als erfolgreich bezeichnet werden können. Der Anstieg der Er-

folgreichen Projekte ist deshalb auch mit Vorsicht zu genießen, da Projektmana-

ger aufgrund der schlechten Erfahrungen dazu neigen, die Projektkosten und -

zeiten zu überschätzen, um diese dann einhalten zu können.8

16%

27%

26%

28%

53%

33%

46%

49%

31%

40%

28%

23%

0% 20% 40% 60% 80% 100%

1994

1996

1998

2000

erfolgreich

eingeschränkter Erfolg

gescheitert

Abb. 1: Erfolgreiche und gescheiterte IT-Projekte, in Anlehnung an

The Standish Group International Inc., (2001), S 2.

Boehm hat eine Top Ten Liste der Risiken aufgestellt, die den Erfolg von Soft-

wareprojekten am meisten gefährden:9

1. Personalprobleme, z. B. mangelnde Qualifikation durch Neueinstellung,

Umschichtung oder mangelhafte Fortbildung

2. Unrealistische Pläne und Budgets, z. B. durch Unter-Preis-Angebote

wegen hohem Wettbewerbsdruck oder Nachverhandlungen

3. Entwickeln der falschen Funktionen und Eigenschaften, z. B. bei ei-

nem Online-Shop der mit unzureichender Kundenanalyse geplant wurde

7 Vgl. The Standish Group International Inc. (2001), S 1ff. 8 Vgl. ebenda, S 3. 9 Vgl. Boehm (1991), S. 32ff.

- 5 -

4. Entwickeln der falschen Benutzungsschnittstelle, z. B. komplizierte

Kommandozeile statt graphischer Oberfläche

5. „Goldverzierungen“, z. B. graphisch animierte Oberfläche

6. Ständiger Wechsel der Anforderungen, z. B. durch unzureichend ausge-

arbeitetes Pflichtenheft

7. Versagen externer Komponenten, z. B. Fehler des zugrunde liegenden

Betriebssystems

8. Versagen externer Aufträge, z. B. externer Lieferant für Datenbanklö-

sung geht in Konkurs

9. zu geringe Leistung pro Zeit, z. B. Überbelastung von Servern

10. Fehleinschätzung des Standes der Technik, z. B. Performance neu ent-

wickelter Datenbanktechnik wird überschätzt

Weitere Risiken, die den Projekterfolg gefährden können sind: Instabilität der

Entwicklungsplattform, Unzulänglichkeit der Infrastruktur, räumlich verteilte

Systementwicklung, unvertraute Entwicklungsmethodik, zu starre Regulatorien,

inadäquate bzw. unrealistische Teststrategie und Parallelarbeit der Entwickler.

Problematisch ist oft auch, dass Risiken und mögliche Unsicherheiten von den

Entwicklern zwar aufgedeckt werden, vom Management jedoch nur die positivs-

ten Schätzungen wahrgenommen werden und somit eine wirkungsvolle Bekämp-

fung verhindert wird.10

Zur Vermeidung unkontrolliert ablaufender Prozesse wurden zahlreiche Pro-

zessmodelle zur Softwareentwicklung entwickelt. Das erste solche Modell, das

auch den Einfluss von Risiken auf die Prozesse einbezieht, ist das Spiralmodell

von Boehm.11 Dieses Modell wird heute kaum in seiner ursprünglichen Form

angewandt, es existieren jedoch weit verbreitete Modelle wie das Wasserfallmo-

dell oder das in Deutschland oft angewandte V-Modell, die als erweiterte Imple-

mentierungen des Spiralmodells angesehen werden können.12 Die Anwendung

10 Vgl. Wiegers (1998), [Stand 26.6.2004]. 11 Vgl. Ould (1990), S. 32ff. 12 Vgl. Ould (1990), S. 38ff.

- 6 -

von etablierten Prozessmodellen als „best practice“ sichert strukturiert ablaufen-

de Prozesse.

Das Scheitern oder der nur teilweise Erfolg von Projekten können neben erhebli-

chen finanziellen Schäden auch weit reichende Imageschäden für die ausführen-

den Unternehmen haben. Ein Beispiel hierfür sind die am Mautsystem Toll Col-

lect beteiligten Firmen.

Um den Projekterfolg von Softwareprozessen zu sichern, ist deshalb in die durch

ein Softwareprozessmodell kontrollierten Prozesse ein Risikomanagementsystem

zu integrieren. Dies ermöglicht die frühzeitige Erkennung von Risiken und das

Ergreifung von entsprechenden Maßnahmen. Die Bausteine eines solchen Risi-

komanagementsystems sollen im folgenden Abschnitt dargestellt werden.

- 7 -

3 Risikomanagement bei der Softwareentwicklung

3.1 Einführung

Bei Finanzgeschäften spielen Risikomanagementsysteme schon seit langem eine

entscheidende Rolle. Die Methoden zur Risikobehandlung finden zunehmend

auch in allen anderen Unternehmensbereichen Einzug. Neben wirtschaftlichen

Gründen ist das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich

(KonTraG) hierfür verantwortlich. Das KonTraG schreibt vor, dass „der Vor-

stand […] geeignete Maßnahmen zu treffen [hat], insbesondere ein Überwa-

chungssystem einzurichten, damit den Fortbestand der Gesellschaft gefährdende

Entwicklungen früh erkannt werden“.13

Ein Risiko ist ein Problem, das Auftreten kann, und bei dessen Auftritt Kosten

entstehen, einzelne Projektziele gefährdet werden oder sogar der gesamten Pro-

jekterfolg in Frage gestellt wird. Risiko berücksichtigt also vor allem zwei As-

pekte. Die Eintrittswahrscheinlichkeit eines Ereignisses und die (negative) Aus-

wirkung beim Eintritt des Ereignisses. Mann kann die Bedrohung durch ein Risi-

ko definieren als Produkt dieser beiden Faktoren:

Risikobedrohung = Eintrittswahrscheinlichkeit × Auswirkungen bei Eintritt.

Wichtig ist es, Risiken als potentiell auftretende Probleme von den aktuellen

Problemen eines Softwareprojekts zu unterscheiden, da beide Situationen unter-

schiedliche Handlungsweisen erfordern.14

Durch ein aktives Risikomanagement wird ein formelles, strukturiertes System

installiert, das es ermöglicht, die Risiken eines Projektes kontrollierbar zu ma-

chen. Ziel des Risikomanagements ist es dabei nicht, alle Risiken komplett aus-

zuschließen, sondern die Risiken berechenbar und überschaubar zu halten, denn

Risiken bedeuten auch immer Chancen für ein Unternehmen. Das Risikomana-

gementsystem soll sicherstellen, dass die Risiken, die ein Projekt am ernsthaftes- 13 § 91 Abs. 2 AktG. 14 Vgl. Wiegers (1998), [Stand 26.6.2004].

- 8 -

ten bedrohen, am stärksten überwacht und kontrolliert werden. Ein systemati-

sches Risikomanagement für alle Softwareprojekte eines Unternehmens verein-

facht durch eine einheitliche Dokumentation auch die Nutzung von Erfahrungen

aus vorangegangenen Projekten. So können Fehler, die in diesen Projekten be-

gangen wurden, vermieden werden und erfolgreiche Risikobehandlungsmaß-

nehmen erneut eingesetzt werden.

Für das Risikomanagement bei Softwareprojekten werden in der Literatur zahl-

reiche Vorgehensmodelle beschrieben. Die einzelnen Vorgehensschritte orientie-

ren sich zumeist an einer von Boehm eingeführte Einteilung.15 Boehm unterteilt

das Risikomanagement in Risikoeinschätzung und Risikokontrolle. Die Risiko-

einschätzung unterteilt sich weiter in Risikoidentifizierung, Risikoanalyse und

Risikopriorisierung. Die Risikokontrolle besteht aus Risikoplanung, Risikobe-

handlung und Risikoüberwachung.

Abb. 2: Projektrisikomanagement-Kreislauf, Gaulke, (2002), S.44.

Zur Implementierung von Risikomanagementsystemen in Softwareprojekten gibt

es zahlreiche aktuelle Modelle. Diese Modelle ordnen die Schritte nach Boehm

oder entsprechende Schritte meist in einem Managementkreislauf an, der wäh-

rend der gesamten Projektlaufzeit stetig durchlaufen wird. Dies ist nötig, da das

Risikomanagement keinen einmaligen Prozess zu Projektbeginn darstellt, son-

dern ständig auf sich verändernde und neu auftretende Risiken reagieren muss.

Abb. 2 zeigt beispielhaft einen solchen Managementkreislauf nach Gaulke,

15 Vgl. Boehm (1989), S. 2.

Projektrisiken erkennen

und beurteilen

Projektrisiken und

Maßnahmen überwachen

Projektkontrollen aufnehmen

und beurteilen

Verbleibende

Projektrisiken analysieren

Maßnahmen bewerten

und ergreifen

- 9 -

Abb. 3 zeigt den Kreislauf des SEI-Risikomanagement-Schemas.16 Ein weiteres

Risikomanagementmodell stellt die Riskit Methode der Universität von Mary-

land dar.17

Zentraler Punkt des SEI-Risikomanagement-Schemas ist die Kommunikation.

Nur wenn ein ausreichender und schneller Kommunikationsfluss zwischen allen

Projektbeteiligten besteht, kann das Risikomanagementsystem funktionieren, da

nur so alle Informationen über Risiken die Risikoverantwortlichen erreichen. Vor

allem für die in Abschnitt 3.5 beschriebene Risikoüberwachung ist die reibungs-

lose Kommunikation unerlässlich. Unterstützt werden kann die Kommunikation

durch ein standardisiertes, internes Berichtswesen.

Das Risikomanagement sollte von Personen koordiniert werden, die nicht direkt

am entsprechenden Projekt beteiligt sind. Dies ist nötig, da bei Personen, die am

Projekt beteiligt sind, stets die Gefahr der verzerrten Informationsweitergabe be-

steht. Vor allem negative Informationen werden nicht immer in vollem Umfang

weitergegeben.18

Abb. 3: Das SEI Risikomanagement-Schema, in Anlehnung an Carr et al, (1993), S. 4.

Auf die einzelnen weiteren Schritte eines Risikomanagementsystems soll nun im

Folgenden genauer eingegangen werden.

16 Vgl. Carr et al (1993), S. 4f. 17 Vgl. Kontio (1997), S. 1ff. 18 Vgl. Gaulke (2002), S. 47.

Kommunikation

Risikokontrolle

Risikoüberwachung

Risikoplanung

Risikoanalyse

Risikoidentifikation

- 10 -

3.2 Risikoidentifikation

Zunächst müssen die Risiken in einem Softwareprojekt identifiziert werden. Die

Risiken bei der Softwareprojektentwicklung lassen sich grob in zwei Klassen

einteilen: projektspezifische Risiken und allgemeine Risiken bei der Software-

entwicklung. Die projektspezifischen Risiken sind abhängig vom speziellen

Softwareprojekt und ergeben sich aus dessen spezifischen Eigenschaften. Sie

müssen von der Projektleitung durch Erfahrungsdatenbanken mit ähnlichen Pro-

jekten, Mitarbeiterworkshops wie Brainstorming oder genauer Analyse des Pro-

jektplanes entdeckt und festgelegt werden. Allgemeine Risiken bei der Software-

entwicklung sind Risiken, die bei jedem Softwareprojekt in unterschiedlich star-

ker Ausprägung auftreten können. Capers Jones hat ein Handbuch entwickelt,

das die 60 wichtigsten dieser Risiken auflistet und zu jedem Risiko detaillierte

Informationen und Checklisten liefert. Diese Informationen umfassen unter ande-

rem:19

1. Die Definition des Risikos

2. Die Ernsthaftigkeit

3. Die Eintrittshäufigkeit

4. Mögliche Bereiche des Auftritts

5. Anfälligkeit und Resistenz

6. Die Ursachen des Risikos

7. mit dem Risiko verbundene Probleme

8. Kosten bei Eintritt des Risikos

9. Vorbeugende Maßnahmen

10. Kontrollmaßnahmen

Jones gibt die Informationen zu jedem Risiko in Abhängigkeit der Art des Soft-

wareprojekts an. Hierzu teilt Jones Softwareprojekte in sechs Kategorien ein:20

1. Management-Informationssysteme

19 Vgl. Jones (1994), S. 46ff. 20 Vgl. ebenda, S. 28.

- 11 -

2. Systemsoftware

3. kommerzielle Software

4. militärische Software

5. für dritte entwickelte Software

6. vom Enduser entwickelte Software

Kritikpunkte an dieser Einteilung sind das Fehlen von wissenschaftlicher Soft-

ware und die Vermischung von Anwendungsbereich der Software und Hersteller

der Software in den Kategorien.

Eine weitere mögliche Technik zur Identifikation von Risiken ist die Verwen-

dung von Expertenwissen und standardisierten Fragebögen. Der Taxonomy-

Based Risk Identification Questionnaire des SEI stellt einen solchen Frageboden

dar, der es ermöglicht einen Großteil möglicher Risiken zu entdecken.21 Die Fra-

gen eines solchen Fragebogens sollten nicht nur einmal zu Beginn des Projekts

beantwortet werden, sondern in regelmäßigen Abständen während der Projekt-

laufzeit wiederholt werden. So werden auch neu auftretende Risiken rechtzeitig

identifiziert.

Der Taxonomy-Based Risk Identification Questionnaire gliedert die Risiken der

Softwareentwicklung in drei Hauptkategorien: Produktentwicklung, Entwick-

lungsumgebung und Produktvorgaben. Diese Hauptkategorien werden weiter

unterteilt, um die verschiedenen Risikoaspekte genauer einzugrenzen. Eine Frage

des SEI Fragebogens zur Entwicklungsumgebung lautet beispielsweise: „Are

there enough workstations and processing capacity for all staff?“22

Die anschließende Dokumentation der identifizierten Risiken ist entscheidend, da

die Dokumentation zur späteren Risikoüberwachung benötigt wird. Es hat sich

außerdem gezeigt, dass das Management schriftlich niedergelegten Risiken eine

höhere Aufmerksamkeit schenkt. Eine Möglichkeit zur Dokumentation ist ein

standardisiertes Risikodokumentations-Formular. Ein standardisiertes Dokumen-

21Vgl. Carr et al (1993): S. B-1ff. 22Ebenda: S. B-12.

- 12 -

tationsformular hat zudem den Vorteil der schnellen und einfachen Verständlich-

keit für alle Projektbeteiligten. Abb. 4 zeigt wie ein Formular zur Dokumentation

eines Risikos aussehen kann. Es enthält auch Informationen zur Risikoanalyse

und Risikoplanung, auf die in den Abschnitten 3.3 und 3.4 genauer eingegangen

wird.

Risiko #: laufende Nummer Klassifikation: Risikokate-gorie z. B. nach SEI

Datum: letztes Update des Formulars

Beschreibung: Beschreibung des Risikos mit Bedingung und Konsequenz des Risikos

Wahrscheinlichkeit: Wahr-scheinlichkeit, mit der das Risiko auftritt

Auswirkung: Auswirkung bei Eintritt des Risikos

Risikobedrohung: Produkt aus Wahrscheinlichkeit und Aus-wirkung

Frühwarnsignal: Signal, das möglichst früh den möglichen Eintritt des Risikos anzeigt

Verminderungsmaßnahmen: Maßnahmen, die zur Risikominderung ergriffen werden

Startdatum: Start der Maß-nahmen

Enddatum: geplante Beendi-gung der Maßnahmen

Verantwortlicher: Verantwort-licher für die Maßnahmen

Aktueller Stand: Aktueller Stand der Maßnahmen

Notfallplan: Aktionen, die im Falle des Eintritts ausgeführt werden sollen

Auslöser für Notfallplan: Signal, das den Notfallplan Auslöst

Abb. 4: Risikodokumentations-Formular,

in Anlehnung an Wiegers, (1998), [Stand 26.6.2004].

3.3 Risikoanalyse

Nach der Risikoidentifikation erfolg die Analyse der zuvor identifizierten Risi-

ken. Die Analyse der Risiken ist notwendig, um festzulegen, mit welcher Priori-

tät die einzelnen Risiken behandelt werden müssen. Hierzu müssen die einzelnen

Risiken bewertet werden.

Die Bewertung erfolgt in zwei Schritten: Zunächst wird die Wahrscheinlichkeit

für den Eintritt eines Risikos geschätzt. Ideal wäre es, jedem Risiko eine Wahr-

scheinlichkeit zwischen 0 und 1 zuzuordnen. Aufgrund der Natur der Risiken ist

eine solche quantitative Analyse jedoch nicht für alle Risiken möglich. Das Risi-

ko wird dann qualitativ geschätzt und einer Klasse zugeordnet. Das USAF Hand-

buch zur Risikobekämpfung schlägt hierzu beispielsweise die Zuordnung jedes

Risikos zu einer der Klassen sehr gering, gering, mittel, hoch und sehr hoch

- 13 -

vor.23 Die Kategorisierung erfolgt meist intuitiv und erfordert deshalb möglichst

große Erfahrung in der Einschätzung von Risiken. Die Einteilung sollte durch

Erfahrungen aus vorangegangenen Projekten und Wissensdatenbanken unter-

stützt werden.

Nach der Festlegung der Wahrscheinlichkeit wird die Auswirkung bei Eintritt

eines Risikos auf das Softwareprojekt untersucht. Wünschenswert wäre wieder

die quantitative Bewertung der Auswirkung jeden Risikos, z. B. auf einer Skala

von 1 bis 10 oder durch die entstehenden Kosten beim Eintritt. Ist dies nicht

möglich, so muss die Bewertung wieder durch Klassenbildung erfolgen. Das

USAF Handbuch kategorisiert hierzu jedes Risiko als unbedeutend, gering, kri-

tisch oder katastrophal.24 Der Eintritt eines Risikos kann sich in verschiedener

Hinsicht auf das Projekt auswirken. Mann kann hier zwischen Auswirkungen auf

die Kosten, die Funktionalität oder den Zeitplan unterscheiden.

Zur Ermittlung der Risikobewertung stehen heute auch zahlreiche computerge-

stützte Simulationstools wie zum Beispiel Palisade @RISK oder Crystal Ball zur

Verfügung.

Sind die Wahrscheinlichkeit für den Eintritt und die Auswirkung bei Eintritt für

alle Risiken festgelegt, so kann für jedes Risiko eine Gesamtbeurteilung vorge-

nommen werden. Eine Möglichkeit zu Ermittlung dieser Gesamtbeurteilung ist

die Erstellung eines Risikoportfolios. Dies ist für qualitativ und quantitativ be-

wertete Risiken möglich. Jedes Risiko wird hierzu in eine Auswir-

kung/Wahrscheinlichkeits-Matrix eingetragen. In Abb. 5 ist ein solches Risiko-

portfolie dargestellt.

Werden Eintrittswahrscheinlichkeit und Auswirkung jeweils durch einheitliche

Maßzahlen quantifiziert, so lässt sich zu jedem Risiko die Risikobedrohung be-

rechnen und dem Risiko als Gesamtbewertung zuordnen. Die Risiken können

dann nach absteigender Risikobedrohung sortiert werden.

23 Vgl. Pinkerton (1995), [Stand 26.6.2004]. 24 Vgl. ebenda (1995), [Stand 26.6.2004].

- 14 -

Abb. 5: Risikoportfolio

Bei der Bewertung eines Risikos ist auch die Auswirkung auf andere Risiken zu

beachten. Risiken können meist nicht isoliert betrachtet werden, denn es bestehen

Beziehungen zwischen den Risiken. So kann der Eintritt eines Risikos beispiels-

weise Auswirkung auf die Eintrittswahrscheinlichkeit anderer Risiken haben.

Risiken, die große Auswirkung auf viele andere Risiken haben müssen mit er-

höhter Priorität betrachtet werden und es müssen verstärkt Ressourcen zu deren

Abschwächung bereitgestellt werden. Zur Darstellung der Abhängigkeiten zwi-

schen verschiedenen Risiken eignet sich ein Graph, wie er in Abb. 6 beispielhaft

dargestellt ist. Durch jeden Pfeil wird dargestellt, dass Risiken aus einem Bereich

Auswirkungen auf einen anderen Bereich haben. Im diesem Beispiel wird nicht

die Abhängigkeit aller Risiken zueinander dargestellt, da diese oft zu komplex

sind, sonder die Abhängigkeit der Risiken aus bestimmten Risikokategorien auf

Risiken aus anderen Risikokategorien. Man erkennt aus dem Diagramm, dass

Risiken, die die Finanzierung betreffen, direkt oder indirekt auf alle anderen Ri-

siken Auswirkungen haben und deshalb mit hoher Priorität behandelt werden

müssen. Durch unterschiedlich dicke Pfeile wäre zusätzlich eine Kennzeichnung

der stärke der Abhängigkeiten möglich. Keil und Wallace haben in einer Studie

mit über 500 Softwareprojekten die Abhängigkeit zwischen Risiken aus den Be-

reichen Kundeneinbindung, Projektanforderungen und -ziele und Projektausfüh-

rung gezeigt.25

25 Keil; Wallace (2004), S. 73.

Wahrscheinlichkeit mittel gering

katastrophal

Auswirkung

kritisch

gering

unerheblich

hoch

hoch

gering

Risiko

- 15 -

Abb. 6: Abhängigkeitsgraph von Risiken

3.4 Risikoplanung

Nach Identifikation und Analyse der Risiken wird die Risikoplanung vorgenom-

men, die festlegt, wie die identifizierten Risiken zu behandeln sind. Da bereits

vor Eintritt eines Risikos Maßnahmen zu dessen Behandlung ergriffen werden

spricht man von einem proaktiven Risikomanagement. Die Risikoplanung legt

zum einen fest, wie im Vorhinein mit einem identifizierten Risiko umzugehen ist,

d. h. welche Handlungsschritte einzuleiten sind, um das Risiko beispielsweise zu

mindern oder zu vermeiden. Zum andern wird für die Risiken ein Notfallplan

entwickelt, d. h. eine konkrete Vorgehensweise, die bei Eintritt oder zu erwarten-

dem Eintritt des Risikos anzuwenden ist. Hierzu wird eine Anzahl an Risiken mit

der höchsten Gesamtbewertung für die Risikoplanung ausgewählt. Die Anzahl

der ausgewählten Risiken richtet sich dabei nach der Gesamtanzahl an identifi-

zierten Risiken und der durch sie ausgehenden Bedrohung. Für Risiken mit ge-

ringer Gesamtbewertung ist es nicht sinnvoll Ressourcen in die Risikoplanung zu

investieren.

Mögliche Vorgehensweisen zur Behandlung eines Risikos sind Risikovermei-

dung, Risikoverminderung, Risikobegrenzung, Risikoverlagerung und Risikoak-

zeptanz.26 26 Vgl. Gaulke (2002), S. 159.

Finanzierung

Organisation

Methoden

und Tools

Ressourcenzuwei-

sung

Projektpla-

nung

Schulung Systemleistung

Schnittstellen

- 16 -

Risikovermeidung

Die Risikovermeidung hat eine vollkommene Beseitigung von Risiken zum

Ziel.27 Dies ist möglich, indem das gesamte geplante Projekt nicht durchgeführt

oder in wesentlichen Punkten eingeschränkt wird. Risiken können ebenfalls ver-

mieden werden, indem auf den Einsatz neuer Technologien und Methoden ver-

zichtet wird. Da Risiken jedoch immer auch Chancen bieten, gehen dem Unter-

nehmen diese Chancen mit der kompletten Risikovermeidung verloren. Es muss

daher sorgfältig abgewogen werden, welche Risiken vollkommen vermieden

werden, da durch die Vermeidung auch Geschäfts- und Projektziele gefährdet

werden können.

Risikoverminderung

Maßnahmen zur Risikoverminderung sollen die Eintrittswahrscheinlichkeit für

ein Risiko im Vorhinein vermindern. Die Maßnahmen lassen sich in die folgen-

den Kategorien einteilen:28

• Korrektur von Projektplanung- und zielen

• Erhöhung der Produktivität

• Veränderung und Erhöhung der Ressourcen

• Neugestaltung der Projektstruktur und des Entwicklungsprozesses

Risikobegrenzung

Die Maßnahmen zur Risikobegrenzung haben die Verringerung des potentiellen

Schadens bei Eintritt eines Risikos zum Ziel. Dies kann geschehen durch den

Aufbau von Redundanzen, z. B. durch die Bearbeitung der gleichen Aufgabe

durch ein zweites Team, oder durch die Bereithaltung von Handlungsalternativen

für den Fall des Risikoeintritts.29 Da die Maßnahmen zur Risikoverminderung

zumeist sehr teuer sind, werden sie vor allem für sehr kritische Risiken angewen-

det.

27 Vgl. Gaulke (2002), S. 161. 28 Vgl. ebenda, S. 162. 29 Vgl. ebenda, S. 164.

- 17 -

Risikoverlagerung

Durch die Risikoverlagerung wird das Risiko auf Dritte übertragen. Denkbar ist

hierbei die Übertragung an Versicherungen oder Vertragspartner.30 Die Übertra-

gung an Versicherungen geschieht meist für Risiken mit zwar sehr geringer Ein-

trittswahrscheinlichkeit aber überproportional hohem Schaden bei Eintritt. Das

Risiko wird bei Risikoverlagerung nicht beseitigt, sondern lediglich die finanziel-

len Auswirkungen abgeschwächt. Nicht abgeschwächt werden kann durch die

Risikoverlagerung ein möglicher Imageverlust, der durch das Scheitern eines

Projektes eintreten kann.

Risikoakzeptanz

Eine letzte Möglichkeit der Risikobehandlung stellt die Risikoakzeptanz dar.

Hierbei wird keine der zuvor genannten Maßnahmen angewandt, sonder ein Ri-

siko bewusst in Kauf genommen. Zur Abfederung solcher in Kauf genommener

Risiken können im Projektplan geeignete zeitliche und finanzielle Puffer vorge-

sehen werden.

Die Abb. 7 zeigt, wie sich die Position eines Risikos (R) in einem Risikoportfo-

lio nach Anwendung einer Maßnahme zur Risikovermeidung (1), zur Risikover-

minderung (2), zur Risikobegrenzung (3) oder zur Risikoverlagerung (4) verän-

dern kann.

Abb. 7: Risiko (R) nach Risikovermeidung (1), Risikoverminderung (2),

Risikobegrenzung (3) und Risikoverlagerung (4)

30 Vgl. Gaulke (2002), S. 165.

Wahrscheinlichkeit gering

katastrophal

Auswirkung

unerheblich

hoch

R

1

2

3

4

- 18 -

Nach der Erstellung der Risikoplanung muss diese sorgfältig dokumentiert wer-

den, um eine exakte Umsetzung und Überwachung der Planung zu ermöglichen.

Eine solche Dokumentation sollte für jedes Risiko folgende Punkte enthalten:31

• Warum ist das Risiko wichtig?

• Welche Informationen werden benötigt, um das Risiko zu beobachten?

• Wer ist für das Risikomanagement verantwortlich?

• Welche Ressourcen werden für das Risikomanagement benötigt?

• Einen detaillierten Maßnahmenplan, der die festgelegten Präventiv- und

Notfallmaßnahmen beschreibt. Auch Gründe für die Verlagerung oder

Akzeptanz müssen hier dokumentiert werden.

• Wann soll der Plan umgesetzt werden?

Eine solche Dokumentation kann wieder mittels des in Abb. 4 aus Abschnitt 3.2

vorgestellten Risikodokumentationsformulars sichergestellt werden.

Die einzelnen Maßnahmen zur Risikobehandlung verursachen Kosten. Es dürfen

nur solche Maßnahmen in die Risikoplanung aufgenommen werden, deren Kos-

ten ihren Nutzen nicht übersteigen. Ein Maß für den Nutzen einer Maßnahme ist

durch folgende Formel gegeben:32

Bedrohung vor Maßnahme - Bedrohung nach MaßnahmeNutzenKosten für Maßnahme

=

Die Risikobedrohung ist hierbei in Kosten zu bewerten. Der Nutzen einer Maß-

nahme ist umso größer, je größer der berechnete Wert ist. Eine Maßnahme sollte

nur ausgeführt werden, wenn der Wert größer als eins ist, da anderenfalls die

Kosten für die Maßnahme die Reduzierung der Bedrohung übersteigen.

Maßnahmen zur Risikobehandlung können Auswirkungen auf mehrere Risiken

haben. In solchen Fällen muss eine geeignete Auswahl der Maßnahmen getroffen

werden. Diese Auswahl kann durch eine Wirkungsmatrix unterstütz werden, wie

31 Vgl. Pinkerton (1995), [Stand 26.6.2004]. 32 Vgl. Gaulke (2002), S. 163.

- 19 -

sie Abb. 8 zeigt.33 Die Felder der Matrix geben an, wie gut die einzelnen Risiken

(R1-R6) durch die möglichen Maßnahmen (M1-M4) behandelt werden können.

Der Wert 0 gibt dabei an, dass eine Maßnahme keine Auswirkung auf ein Risiko

hat, der Wert 3 gibt eine maximale Verminderung des Risikos durch die Maß-

nahme an. Die Aktivsumme (AS) gibt an, wie groß der Gesamteffekt einer Maß-

nahme ist, die Passivsumme (PS) gibt an, wie stark ein Risiko durch die Maß-

nahmen abgemildert werden kann. Im Beispiel hat die Maßnahme M1 den größ-

ten Gesamteffekt, und die Risiken R3 und R4 können durch die betrachteten

Maßnahmen am meisten abgeschwächt werden.

Die Wahrscheinlichkeit, dass eine geplante Risikobehandlungsmaßnahme nicht

den gewünschten Effekt erzielt, wird als Sekundärrisiko bezeichnet. Die Wahr-

scheinlichkeit, dass ein Risiko trotz funktionierender Maßnahmen Eintritt wird

als Restrisiko bezeichnet.

Beispiele für Risikobehandlungsmaßnahmen sind die Einstellung von sehr guten

Bewerbern unabhängig vom aktuellen Personalbedarf und der Vertragsschluss

mit Zeitarbeitsfirmen für plötzlich auftretenden Personalbedarf. Aufgaben in

Teams können mit Überschneidungen ausgelegt werden, um den Ausfall von

Mitarbeitern zu kompensieren. Auch die betriebliche Gesundheitsvorsorge kann

als Risikovorbeugende Maßnahme angesehen werden. Um dem Risiko sich än-

dernder Anforderungen vorzubeugen, kann vor der eigentlichen Implementierung

z. B. zunächst ein Prototyp erzeugt werden.

R1 R2 R3 R4 R5 R6 AS

M1 2 1 0 3 0 0 6

M2 0 0 3 0 0 1 5

M3 0 0 1 1 1 0 4

M4 0 0 0 0 1 0 1

PS 2 1 4 4 2 1

Abb. 8: Wirkungsmatrix für zur Risikoplanung

33 Vgl. Gaulke (2003), S. 160f.

- 20 -

3.5 Risikoüberwachung

Das Risikomanagement findet nicht nur zu Beginn des Softwareprojektes statt,

sondern währen der gesamten Projektlaufzeit muss eine Überwachung der Risi-

ken und Maßnahmen zur Risikobehandlung stattfinden. Die Überwachung um-

fasst die Beobachtung und Verfolgung aller identifizierten Risiken, die Identifi-

kation neu auftretender Risiken und die Überwachung der ergriffenen Maßnah-

men, um ihre Wirksamkeit zu prüfen.34

Zur Überwachung der Risiken müssen Indikatoren und Maßzahlen festgelegt

werden, durch deren Beobachtung der aktuelle Status eines Risikos ermittelt

werden kann und welche eine möglichst frühe Erkennung von kritischen Situati-

onen ermöglicht. Somit wird dem Management ermöglicht, gegebenenfalls

rechtzeitig gegensteuern zu können. Neben dem aktuellen Status muss auch die

Bewertung der Risiken überwacht und ggf. aktualisiert werden. So kann die Ein-

trittswahrscheinlichkeit eines Risikos mit zunehmender Projektdauer zum Bei-

spiel fallen, die Auswirkungen beim Eintritt des Risikos jedoch stark ansteigen.

Zusätzlich zur Überwachung der identifizierten Risiken muss das Projekt auch

ständig auf neu auftretende Risiken untersucht werden. Diese können z. B. bei

geänderten Anforderungen oder geänderten Prozessabläufen eintreten.

Neben den identifizierten Risiken werden ebenfalls die Risikoplanung und die

Maßnahmen überwacht. Diese Überwachung gibt Auskunft über Effektivität und

Effizienz des Risikoplans und ermöglicht somit unter Umständen eine Anpas-

sung von Risikoplan und Maßnahmen.

Die Risikoüberwachung – vor allem gegen Ende des Projektes – kann zusätzlich

wertvolle Daten über die Entwicklung der Indikatoren und die Auswirkungen der

gewählten Maßnahmen liefern. Diese Informationen sollten in einer Datenbank

gesammelt werden, um als Datenbasis für zukünftige Projekte zu dienen. Zur

Risikoüberwachung zählt auch die regelmäßige Berichterstattung über die Risi-

ken an die Unternehmensleitung.

34 Charette (1989), S. 249f.

- 21 -

4 Spezielle Risiken beim Outsourcing von Softwareprojekten

Viele Unternehmen aus Industrieländern lagern ihre Softwareentwicklung heute

in Länder wie Indien, Russland oder China aus, da in diesen Ländern die Soft-

wareentwickler einen Bruchteil vergleichbarer Entwickler in Europa, Japan oder

den USA kosten. Wenn sich die Unternehmen, an die die Softwareentwicklungs-

aufträge übertragen werden auf einem andern Kontinent, oder in einem andern

Kulturkreis befinden, spricht man auch von Offshore Outsourcing. Outsourcing

und speziell Offshore Outsourcing birgt neben den „normalen“ Risiken bei der

Softwareentwicklung zahlreiche weitere Risiken, die in ein Risikomanagement-

system eingebunden werden müssen, um ein Entwicklungsprojekt erfolgreich

outsourcen zu können. Risiken ergeben sich zum Beispiel aus unterschiedlichen

kulturellen Hintergründen und Arbeitsauffassungen. Besonders problematisch

kann hierbei die unterschiedliche Art und Weise der Kommunikation in den ver-

schiedenen Ländern sein. Im Folgenden sollen mögliche Risiken, die beim Out-

sourcing von Softwareprojekten, speziell auch beim Offshore Outsourcing, auf-

treten können beschrieben werden.

Sprachbarriere und Kommunikation

Eine der wichtigsten Voraussetzungen zur erfolgreichen Durchführung von Off-

shore Outsourcing Projekten ist eine gut funktionierende und stetige Kommuni-

kation zwischen den Vertragspartnern. Nur so ist es für den Auftraggeber mög-

lich ein effektives Überwachungs- und Risikomanagement zu installieren. Prob-

leme bei der Kommunikation können vor allem durch unterschiedliche Sprachen

entstehen. Es sollte für international ausgerichtete Unternehmen heute eigentlich

kein Problem darstellen, diese Kommunikation auf Englisch abzuwickeln. Ist

Englisch jedoch für beide Vertragspartner eine Fremdsprache, so kann es trotz-

dem zu Kommunikationsschwierigkeiten kommen. Dies ist auch daran zu sehen,

dass englischsprachige Firmen aus den USA oder England vor allem nach Indien

outsourcen, da die meisten indischen Entwickler sehr gut Englisch sprechen. Ein

weiteres Hindernis für die Kommunikation kann die oft nicht unerhebliche Zeit-

verschiebung zwischen den Sitzen der Vertragspartner sein. Diese macht eine

Kommunikation per Telefon oft sehr schwierig.

- 22 -

Kulturelle Unterschiede

Zwischen den Kulturen der Länder der beiden Vertragspartner können beträchtli-

che Unterschiede bestehen. Dies kann sich beispielsweise in sehr unterschiedli-

chen Arbeitsauffassungen und der Auslegung von Vertragsinhalten auswirken.

Beispiele für mögliche Konfliktfelder sind hier Termintreue oder die Art und

Weise der Kommunikation. Um Risiken aufgrund kultureller Unterschiede zu

vermeiden, kann ein Outsourcing-Partner in einem Land gewählt werden, das

sich in der Kultur möglichst wenig unterscheidet. Norwegische Firmen wählen

aus diesem Grund vorwiegend russische Partner für Outsourcing-Projekte. Japa-

nische Unternehmen harmonieren aufgrund der räumlichen und kulturellen Nähe

am besten mit chinesischen Outsourcing-Unternehmen.

Lieferung der gewünschten Funktionalität

Beim Outsourcing müssen die Anforderungen an die Funktionalität im Vorhinein

sehr genau festgelegt werden, damit die gelieferte Software auch den gewünsch-

ten Anforderungen entspricht. Problematisch kann dies werden, wenn die Ent-

wicklung die Kenntnisse der eigenen Anwenderkultur erfordern. Zur Verminde-

rung des Risikos kann in solchen fällen die Prototypenentwicklung eingesetzt

werden um beispielsweise die Anwenderschnittstelle bereits in einem frühen Sta-

dium festzulegen. Auch die Auswahl der Projekte ist für die Ausprägung diese

Risikos entscheidend. So können Teile eines Operationssystems leichter „kultur-

neutral“ spezifiziert werden als endkundennahe Anwendersoftware.35

Schutz von geistigem Eigentum

Beim Outsourcing besteht die Gefahr, dass Mitarbeiter des Outsourcing-

Unternehmens das geistige Eigentum des Auftraggebers, z. B. durch den Verkauf

an einen Konkurrenten, verletzen.36 Zur Vermeidung solcher Risiken mit beson-

ders gravierenden Auswirkungen sind die Gesetzte zum Schutz von geistigem

Eigentum im Land des Vertragspartners zu prüfen. Der Vertragspartner sollte

möglichst auch Vermögen und ein rechtlich belangbares Tochterunternehmen im 35 Vgl. Krishna (2004), S. 64. 36 Vgl. Fitzgerald (2003), [Stand 26.6.2004].

- 23 -

Land des Auftraggebers besitzen. Wichtig ist auch eine eingehende Kontrolle der

Sicherheitsmaßnahmen des Vertragspartners.

Know-How Verluste

Bei der Vergabe von Entwicklungstätigkeiten besteht für das outsourcende Un-

ternehmen immer die Gefahr des Verlustes von Know-How. Vor der Vergabe

von Softwareentwicklungsprojekten an externe Anbieter ist deshalb zu prüfen, ob

mit dem Projekt Know-How abgegeben wird, das für die strategischen Ziele des

Unternehmens von Bedeutung ist.

Weitere Risiken können beim Outsourcing beispielsweise durch unterschiedliche

Prozesse und Technologien, zusätzliche Überwachungskosten, Kommunikati-

onskosten, Reisekosten, versteckte Servicekosten, mangelhaften Service oder

schlechte Termintreue entstehen.

Die Auswahl, welche (Teil-)Projekte an Outsourcing Partner vergeben werden

sollen und an welche Partner sie vergeben werden sollen kann durch verschiede-

ne Portfolios unterstütz werden. Mögliche Portfolios bestehen aus Entwicklungs-

zyklus, geographischer Lage des Vertragspartners und Geschäftsprozess, den das

Projekt betrifft, oder Risiko der Auslagerung und erwartete Einsparungen. Zur

quantitativen Bewertung von Outsourcing-Vorhaben kann die Risk-Return-

Rating Methode (R3) dienen.37

Eine Übersicht über mögliche Länder für die Vergabe von Outsourcing Projekten

hat Stephanie Overby zusammengestellt.38 Die Übersicht gibt zu jedem Land un-

ter anderem Informationen über die Entwicklerkosten, die vorhandene Infrastruk-

tur, das geopolitische Risiko sowie mögliche Vor- und Nachteile des Outsour-

cings in dieses Land an. Als Beispiel für ein erfolgreiches Risikomanagement

können verschiedene große IT-Outsourcing-Projekte der Firma British Petroleum

betrachtet werden, welche detailliert veröffentlicht und diskutiert wurden.39

37 Vgl. Kleinhammer et al (2003), [Stand 26.6.2004]. 38 Vgl. Overby (2002), [Stand 26.6.2004]. 39 Vgl. Benoit et al (2000), S. 4ff.

- 24 -

5 Zusammenfassung

Trotz ausgefeilter Prozessmodelle für die Softwareentwicklung werden ein Groß-

teil der Softwareprojekte in Unternehmen heute nicht erfolgreich abgeschlossen.

Softwareprojekte nahmen jedoch eine immer entscheidendere Position in den

Unternehmen ein. Diese beiden Entwicklungen erfordern zusätzliche Maßnah-

men, die den erfolgreichen Abschluss von Softwareprojekten unterstützen. Durch

die Implementierung eines proaktiven Risikomanagementsystems wird diese Un-

terstützung gegeben und zusätzlich die gesetzliche Forderung nach Überwachung

geschäftswichtiger Prozesse erfüllt.

Hierzu wurden in der vorliegenden Arbeit die Risiken der Softwareentwicklung

analysiert und die grundlegenden Bausteine eines Risikomanagementsystems für

die Softwareentwicklung vorgestellt: Die Risikoidentifikation, die Risikoanalyse,

die Risikoplanung und die Risikoüberwachung.

Viele Unternehmen lagern ihre Softwareentwicklung heute aus, um so Kosten

einzusparen. Hierdurch entstehen neue Risiken, die in einem Risikomanagement-

system beachtet werden müssen. Diese Risiken entstehen vor allem durch die oft

sehr große räumliche Entfernung und kulturelle Unterschiede zwischen Auftrag-

geber und Auftragnehmer.

- III -

Literaturverzeichnis

Benoit, Aubert A.; Patry Michel; Rivard Suzanne; Smith Heather (2000): IT

Outsourcing Risk Management at British Petroleum, CIRCANO Scientific Se-

ries, Montréal, 2000.

Boehm, Barry W. (1989): Tutorial: Software Risk Management, Washington D.

C. (IEEE Computer Society Press), 1989.

Boehm, Barry W. (1991): Software Risk Management: Principles of Software

Engineering, in IEEE Software, Vol. 8, 1991, No.1, S. 32-41.

Carr, Marvin J. u. A. (1993): Taxonomy-Based Risk Identification, Software

Engineering Institute at Carnegie Mellon University, Pittsburgh, 1993.

Charette, Robert N. (1989): Software Engineering Risk Analysis and Manage-

ment, NewYork u. a. (Multiscene Press), 1989.

Fitzgerald, Michael (2003): At Risk Offshore ,in: CIO Magazine, 2003, elektro-

nisch veröffentlicht:

URL.: http://www.cio.com/archive/111503/offshore.html [Stand 26.6.2004].

Gaulke, Markus (2001): Risikomanagement bei Softwareentwicklung und -

einführung, in: KES – Zeitschrift für Kommunikations- und EDV-Sicherheit,

2001, Nr. 4, S. 40-42.

Gaulke, Markus (2002): Risikomanagement in IT-Projekten, München u. a. (Ol-

denbourg), 2002.

Jones, Capers (1994): Assessment and Control of Software Risks, Englewood

Cliffs (Yourdon Press), 1994.

Keil, Mark; Wallace, Linda (2004): Software Project Risks and their Effect on

Outcomes, in: Communications of the ACM, Vol. 47, 2004, No. 4, S. 68–73.

- IV -

Kleinhammer, Rod; Nelsen Todd; Warner AJ (2003): Balancing the Risk,

elektronisch veröffentlicht:

URL.: http://www.darwinmag.com/read/060103/risk.html [Stand 26.6.2004].

Klesse, Anne (2004): Finanzamt: Fiskus frisst Millionen, manager-magazin.de,

elektronisch veröffentlicht: URL.:

http://www.e-lo-go.de/html/modules.php?name=News&file=print&sid=5373

[Stand 26.6.2004].

Kontio, Jyrki (1997): The Riskit Method for Software Risk Management, Ver-

sion 1.00, Computer Science Technical Reports, Institute for Advanced Com-

puter Studies and Department of Computer Science, University of Maryland,

1997.

Krishna, S.; Sahay, Sundeep; Walsham, Geoff (2004): Managing Cross-

Cultural Issues in Global Software Outsourcing, in: Communication of the

ACM, Vol. 47, 2004, No. 4, S. 62-66.

Mansmann, Urs (2004): Vorläufiger Stopp für Polizei-Computersystem NIVA-

DIS, heise online, elektronisch veröffentlicht:

URL.: http://www.heise.de/newsticker/meldung/43744 [Stand 26.6.2004].

Ould, Martyn A. (1990): Strategies for Software Engineering, Chichester (John

Wiley), 1990.

Overby Stephanie (2002): A Buyer’s Guide to Offshore Outsourcing, CIO Ma-

gazine, 2002, elektronisch veröffentlicht:

URL.: http://www.cio.com/offshoremap/, [Stand 26.6.2004].

Pinkerton, Andrew (1995): Software Risk Management, elektronisch veröffent-

licht: URL.: http://www.eas.asu.edu/~riskmgmt/intro.html [Stand 26.6.2004].

- V -

The Standish Group International Inc. (Hrsg.) (2001): Extreme Chaos, elekt-

ronisch veröffentlicht: URL.:

http://www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf

[Stand 27.6.2004].

Wiegers, Karl E. (1998): Know Your Enemy: Software Risk Management, in:

Software Development, Vol. 6, 1998, No. 10, elektronisch veröffentlicht:

URL.: http://www.processimpact.com/articles/risk_mgmt.html

[Stand 26.6.2004].

Ehrenwörtliche Erklärung

Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbständig

angefertigt habe; die aus fremden Quellen direkt oder indirekt übernommenen

Gedanken sind als solche kenntlich gemacht.

Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch

noch nicht veröffentlicht.

München, 28.6.2004