Seminararbeit. Seminar aus Informationswirtschaft

Transkript

1 Seminararbeit Seminar aus Informationswirtschaft Abteilung für Informationswirtschaft Institut für Informationsverarbeitung und Informationswirtschaft Wirtschaftsuniversität Wien Augasse 2-6 A-1090 Wien, AUSTRIA Titel der Arbeit: Risikofaktoren und -management in Software-Projekten Name der LV: Seminar aus Informationswirtschaft, 0228 Seminarleiter: o. Univ. Prof. Dr. Wolfgang Janko, PD Dr. Stefan Koch Semester: Sommersemester 2008 Autor der Seminararbeit: Christoph Greilberger

2 Inhaltsverzeichnis I. Stichworte / Keywords... 3 II. Zusammenfassung / Abstract... 3 III. Kernpunkte des Managements Einleitung Grundlagen zum Thema Projektmanagement und IT Projektmanagement Projektmanagement Der Projektbegriff Was ist ein Projekt? Projektziele Das Magische Dreieck IT Projektmanagement Das IT-Projekt IT-Projektarten Das Teufelsquadrat Unterschiede zwischen IT-Projekten und herkömmlichen Projekten Das Risiko als Teil von Software Projekten Das Risikomanagement Abgrenzung des Begriffs Risikomanagement Die Notwendigkeit Abgrenzung des Risikobegriffs Was ist Risiko Risikoarten Klassische Projektrisiken nach Jenny Projektrisiko und Kontrollbereiche nach Gaulke Kernrisiken nach DeMarco Risikofaktoren Der Einfluss des Kundenverhaltens auf die Projektarbeit Der Einfluss der Aufwandsschätzung auf den Software- Projektfortschritt Lösungsansätze zum Risikomanagement Erfolgsfaktoren Einführung eines formalen standardisierten Prozesses Kontinuierliche Risikobetrachtung während des gesamten Projektes Seite 1

3 4.1.3 Risiken als positiven Prozess betrachten Risikobasierte Entscheidungsfindung Schlüsselpersonen, Prozesse, Geschäfts- und Technologiefelder einbinden Kontinuierliche Risikokommunikation Werkzeuge und Methoden zur Risikominimierung Risikomanagementplanung Risikoidentifikation Risikoanalyse und Bewertung Risikomaßnahmenplanung Risikosteuerung- und Überwachung Outsourcing Zusammenfassung IV. Literaturliste Abbildungs- und Tabellenverzeichnis Abbildung 1: Das Magische Dreieck, Quelle: Anlehnung an Lock... 8 Abbildung 2: Das Teufelsquadrat der IT Projekte, Quelle: 11 Tabelle 1: Risiko vs. Krise in Anlehnung an Saynisch (1994) Seite 2

4 I. Stichworte / Keywords Stichworte: Software Projekte Projektmanagement Risikomanagement Risikofaktoren Projektziele Outsourcing Risikomaßnahmenplanung Keywords: software projects project management risk management risk factors project goals outsourcing risk planning II. Zusammenfassung / Abstract Zusammenfassung Die folgende Arbeit behandelt das Thema Risikofaktoren und Risikomanagement in Software Projekten. Es werden zunächst grundlegende Begriffe des Projektmanagements und des IT Projektmanagements erfasst. In weiterer Folge wird konkret auf das Risiko als Teil von Software Projekten eingegangen. In diesem Zusammenhang wird in erster Linie versucht herauszufinden, welche Faktoren und Einflüsse vor allem für das Entstehen von Risiko in Software Projekten verantwortlich sind. Aufgrund der zugrunde liegenden Risikofaktoren- und Einflüsse soll im Anschluss versucht werden Lösungsansätze zu bieten, die darauf abzielen, das Risiko innerhalb von Projekten weitestgehend auszuschalten und wenn möglich zur Gänze zu eliminieren. Abstract The present paper focuses on the topic Riskfactors and Riskmanagement within Software Projects. At the beginnig fundamental and elementary terms according to the Projectmanagement in genereal and specific for the IT Projectmanagement are going to be covered. Moreover this paper is going to talk about the risk as an essential part of Software Projects. This includes to identify alle relevant factors and influences that are responsible for generating risk within Software Projects. After analysing these factors and influences the last part of this paper deals with methods of resolution. Which measures and actions can be taken to minimize or even eliminate the risk within Software Projects. Seite 3

5 III. Kernpunkte des Managements Dieser Teil der Arbeit beschreibt kurz und prägnant die wichtigsten Erkenntnisse und Ergebnisse das Themengebiet Risikofaktoren- und Management von Software Projekten betreffend. - Sowohl das Kundenverhalten als auch die Aufwandsschätzung im Zuge einer Projektabwicklung, können grundsätzlich mit signifikanten Auswirkungen auf die Projektarbeit- und Performance in Verbindung gebracht werden. - Risiko als Teil von IT Projekten sollte nicht isoliert betrachtet werden, sondern als integrativer Bestandteil angesehen werden, mit dessen Hilfe eine erfolgreiche Umsetzung möglich ist. - Aufgrund der Tatsache, dass es sich bei Software Projekten um immaterielle Güter handelt, kann das Risiko bei diesen Projekten niemals zur Gänze ausgeschlossen werden. - Im Unterschied zu herkömmlichen Projekten, findet der Entwicklungsprozess bei IT- Projekten in einem weitaus dynamischeren Umfeld statt (technologische und personelle Anforderungen) und stellt daher hohe Ansprüche an die Qualifikation und Leistungsfähigkeit der involvierten Personen. Seite 4

6 1 Einleitung Zu Beginn der Arbeit soll ein Überblick bzw. eine kurze Einführung zum Thema Projektmanagement im generellen und im speziellen zum IT Projektmanagement gegeben werden. Grundlegende Begriffe sollen erklärt, der Unterschied zwischen herkömmlichen Projekten und Software Projekten soll dargestellt und unterschiedliche Projektarten sollen identifiziert werden, um abschließend auch deren Ziele aufzeigen zu können. Der wesentliche Kern der Arbeit beschäftigt sich mit dem Risiko als elementarer Bestandteil von Software Projekten. Da der Erfolg von Software Projekten, verglichen mit herkömmlichen Projekten, von zusätzlichen Faktoren wie Analyse, Entwicklung, Wartung, Weiterentwicklung oder Einführung von mindestens einem Informations- oder Kommunikationssystem abhängt, ist das Risiko als viel größerer Bestandteil als bei herkömmlichen Projekten anzusehen. In einem ersten Schritt wird der Begriff des Risikomanagements genauer in Betracht genommen, um dessen Notwendigkeit und Wichtigkeit zu manifestieren. Da es in der Literatur eine Vielzahl von Definitionen für Risikoarten gibt, soll versucht werden die wichtigsten herauszufiltern, um diese einer genauen Betrachtung zu unterziehen. Es stellt sich natürlich auch die Frage, welche Faktoren in erster Linie dafür verantwortlich sind, eine Risikosituation in Softwareprojekten hervorzurufen. Hierbei soll versucht werden, sowohl auf den Einfluss des Kundenverhaltens auf das Projekt, als auch auf den Einfluss der Aufwandsschätzung auf die Projektarbeit, genauer einzugehen um zu zeigen in wie weit diese beiden Faktoren maßgeblichen Einfluss auf den Projektablauf haben. Der abschließende Teil der Arbeit beschäftigt sich mit konkreten Lösungsansätzen das Thema Risikomanagement bei Softwareprojekten betreffend. Es soll weiters erörtert werden, welche Erfolgsfaktoren es gibt, die maßgeblich dazu beitragen, das Risiko in Softwareprojekten einzudämmen bzw. zur Gänze auszuschließen. Gibt es einen konkreten Maßnahmen- und Managementplan, der dazu beitragen kann, das Risiko zu eliminieren? Gesprochen wird hierbei über Werkzeuge und Methoden wie Risikoidentifikation, Risikoanalyse- und bewertung, Risikomaßnahmenplan und Risikosteuerung. Abschließend soll noch gezeigt werden, inwieweit das Outsourcing von Risikomanagement dazu beitragen kann, Projekte einem sichereren und schnelleren Ablauf zu unterziehen. Seite 5

7 2 Grundlagen zum Thema Projektmanagement und IT Projektmanagement Folgendes Kapitel gibt einen Überblick über das Themengebiet Projektmanagement und IT Projektmanagement. Zunächst werden elementare Begriffe erklärt und abgegrenzt, wobei hier der Fokus auf dem Projektbegriff sowohl für das Projekt- als auch das IT Projektmanagement liegt. Eine Gegenüberstellung von herkömmlichen Projekten zu Software Projekten soll Aufschluss darüber bringen, worin die elementaren Unterschiede bestehen. 2.1 Projektmanagement Der Projektbegriff In der Literatur findet man eine Vielzahl von Definitionen für den Begriff Projekt. Ein Projekt ist ein Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z.b. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzungen gegenüber anderen Vorhaben oder einer projektspezifischen Organisation. (Gaulke 2004, S. 1) Da diese Definition für die Praxis allerdings zu lange und daher nicht merkfähig ist, wird grundsätzlich folgende Kurzdefinition für die Begriffsbestimmung eines Projektes empfohlen: Einmaliges Vorhaben einer Aufgabenausführung. (Steinbuch 2000, S. 24) Jenny (1997) definiert Projekte folgendermaßen: Projekte sind in sich geschlossene, komplexe Aufträge, deren Erfüllung eine Organisation bedingt, die für die Umsetzung der Tätigkeiten eine Methode anwendet, mit der alle anfallenden Arbeiten geplant, gesteuert, durchgeführt und kontrolliert werden können. (Jenny 1997, S. 520), Seite 6

8 Das Project Management Institute of America definiert Projekt als a temporary endeaver undertaken to create a unique product or service (Peter Nausner 2006) Was ist ein Projekt? Ein Projekt setzt sich grundsätzlich aus mehreren Eigenschaften zusammen. Mit Hilfe folgender Merkmale ist es möglich zu prüfen, ob im Einzelfall die Bezeichnung Projekt gerechtfertigt ist oder nicht. Konkret liegt ein Projekt dann vor, wenn folgende, nachstehende Eigenschaften zutreffen: - Bedeutung: Ein Projekt muss für ein Unternehmen eine bestimmte Gewichtigkeit haben. Im Zusammenhang mit dem Projekt muss eine Korrelation zwischen dem Projektziel und dem Unternehmensziel bestehen. - Komplexität: Nur ein hoher Grad an Schwierigkeit deutet konkret auf ein Projekt hin. Bei einfachen Aufgaben sollte daher auf den Begriff Projekt verzichtet werden. - Umfang: Ein erheblicher Umfang deutet auf ein Projekt hin. Der Umfang wird am Arbeitsvolumen oder an der Projektdauer abgelesen. - Interdisziplinarität: Ein weiteres Merkmal von Projekten ist die Notwendigkeit verschiedene Fachgebiete zur Ausführung der Aufgabe einzusetzen. - Einmaligkeit: Eine Wiederholung im Zusammenhang mit der Projektabwicklung sollte nicht absehbar sein, demnach können Routineaufgaben nie Projekte sein. - Endlichkeit: Ein Projekt ist in zeitlicher Hinsicht immer begrenzt, d.h. es gibt einen Endtermin und somit ein exaktes Projektende. - Risiko: Die absolute Sicherheit für die Erreichung eines Projektes kann nicht gegeben sein. Nur wenn die Erfüllung eines Projektes mit Unsicherheiten verbunden ist, spricht man von einem Projekt. (Steinbuch 2000) Seite 7

9 2.1.3 Projektziele Das Magische Dreieck Projektziele lassen sich durch drei klassische Zieldimensionen: Zeit, Kosten und Qualität/Leistung darstellen. Diese drei Dimensionen werden häufig als Eckpunkte in dem so genannten Magischen Dreieck dargestellt: - Das Projektziel, das mit einer bestimmten Qualität oder Leistung erreicht werden soll - Der Zeitraum bzw. der Termin, bis zu dem das Projekt abgeschlossen werden muss - Die Kosten (d.h. Finanzmittel, Arbeitskraft und andere Ressourcen), die maximal dafür aufgebraucht werden dürfen Diese drei Inhalte werden an die Ecken eines gleichseitigen Dreiecks gesetzt. Es soll vermitteln, dass Zeit, Kosten und Qualität des Projektes nicht unabhängig voneinander variiert werden können, wobei die Kanten zwischen diesen Eckpunkten die gegenseitige Abhängigkeit verdeutlichen sollen. So kann beispielsweise eine höhere Qualität bzw. Mehrleistung einen höheren Mitarbeitereinsatz, einen höheren Zeitbedarf und somit höhere Kosten verursachen. Unternehmen können natürlich selbst entscheiden, ob sie versuchen die Kosten im Auge zu behalten, ihren Ruf verbessern oder schützen oder auf die Verbesserung der Qualität setzen. (Lock 1997) Leistung (Qualität, Umfang) Effektivität Rentabilität Zeit Produktivität Kosten Abbildung 1: Das Magische Dreieck, Quelle: Anlehnung an Lock Seite 8

10 2.2 IT Projektmanagement Das IT-Projekt Unter einem IT-Projekt wird ein Vorhaben verstanden, dem die oben angeführten Merkmale für ein Projekt zugrunde liegen, bei welchem aber der Erfolg des Projektes zusätzlich von der Auswahl, Analyse, Entwicklung, Wartung, Weiterentwicklung oder Einführung mindestens eines Informations- oder Kommunikationssystems abhängt. Aufgrund dieser Tatsache werden die meisten Projekte heutzutage als IT-Projekte angesehen, da beispielsweise auch Projekte, welche dem Ziel der Umstrukturierung oder der Geschäftsprozessoptimierung dienen, ohne Änderungen oder Ergänzungen and den IT-Systemen kaum vorstellbar wären. Demnach ist das Spektrum an möglichen IT-Projekten weitläufig, da die betroffenen Informations- und Kommunikationssysteme ganz unterschiedlicher Art sein können. Daher unterscheiden sich z.b. Projekte mit kaufmännischen Anwendungen erheblich von Projekten mit technischen Anwendungen oder systemnahen Applikationen. (Gaulke 2004) Henrich (2002) versteht vereinfacht ausgedrückt unter Software Projekten, Projekte, in denen hauptsächlich Software entwickelt wird. Es ist allerdings zu beachten, dass es sich hierbei um unterschiedliche Arten von Projekten handelt. Als erste Projektart kann die Neuentwicklung eines Systems genannt werden. Diese zeichnet sich dadurch aus, dass zumindest ein Großteil der Software selbst entwickelt wird. Es handelt sich hierbei also um eine Weiterentwicklung einer bereits bestehenden Software. Ein solches System kann entweder in Form einer Individualentwicklung (für einen bestimmten Anwender) erstellt oder auch als Standardlösung (für einen breiteren Markt) umgesetzt werden. Hierbei können drei verschiedene Untergruppen differenziert werden: - Einzelentwicklung - Entwicklung für eine kleine Anwendergruppe - Entwicklung für einen anonymen Markt Bei der zweiten Projektart handelt es sich um eine Anpassung so genannter COTS-Software (COTS = commercial of the shelf), welche die Grundversion des Softwareanbieters darstellt. Beispiele für diese Software reichen von den bekannten Office Paketen bis hin zu ERP- Systemen (Enterprise Resource Planing) wie SAP R/3 oder BAAN IV. Bei diesen Projekten Seite 9

11 liegt der Fokus auf der Auswahl der richtigen COTS-Software. Anschließend sind etwaige Anpassungen an das jeweilige Unternehmen erforderlich. Diese können sich im Extremfall an eine Neuentwicklung anpassen, sodass Übergänge fließend sein können. (Henrich 2002) Wieczorrek (2005) beschreibt IT-Projekte folgendermaßen: IT-Projekte beschäftigen sich mit der Entwicklung von Informations- und Kommunikationssystemen. Sie sind temporäre Organisationsformen innerhalb des sozio-technischen Systems Unternehmung und haben i- dentische Eigenschaften wie herkömmliche Projekte. (Wieczorrek 2005, S. 9) IT-Projektarten Jeder einzelne Wirtschaftssektor beinhaltet sowohl in organisatorischer als auch in entwicklungstechnischer Hinsicht unterschiedliche Anforderungen an die Projektabwicklung. Zusammen mit der Charakteristik des zu lösenden Problems ergeben sich daher unterschiedliche Projektarten. Im EDV bzw. Informatik Bereich werden folgende Projektarten bestimmt: (Jenny 1997) - Entwicklungsprojekte: z.b. Strategie- oder Innovationsprojekte, Eigenentwicklungen - Ausbildungsprojekte - Organisationsprojekte: Evaluationsprojekte oder Ausführungsprojekte - Unterstützungsprojekte - EDV-Projekte - Wartungsprojekte - Versuchsprojekte: z.b. Prototypen für spätere komplexe Systeme Seite 10

12 2.2.3 Das Teufelsquadrat Als Erweiterung des Magischen Dreiecks betrachtet man das Teufelsquadrat von Sneed (1987). IT Projektziele lassen sich besonders gut durch dieses Modell veranschaulichen. Die Dimensionen werden als Eckpunkte dargestellt, wobei die Kanten zwischen diesen Eckpunkten die gegenseitige Abhängigkeit verdeutlichen sollen. Qualität Umfang Zeit Kosten Abbildung 2: Das Teufelsquadrat der IT Projekte, Quelle: Die vier angegebenen Ziele des Quadrates konkurrieren sozusagen um die verfügbare Produktivität, welche durch die Fläche des grau unterlegten äußeren Vierecks dargestellt wird. Die Gesamtproduktivität des Projektes ergibt sich aus der Produktivität der eingesetzten Faktoren. Aufgrund der Begrenzung der Ressourcen, ergibt sich automatisch auch eine Begrenzung der Produktivität, symbolisiert durch die Fläche des inneren Vierecks. Man kann das Viereck natürlich in die eine oder andere Richtung strecken, muss dann allerdings einen geringern Zielerfüllungsgrad auf der anderen Seite hinnehmen. Soll beispielsweise die Qualität eines zu entwickelnden Produktes erhöht werden und gleichzeitig die Entwicklungsdauer verkürzt werden, dann muss als Resultat der Produktionsumfang gesenkt werden. Gleichzeitig steigen die Entwicklungskosten. Seite 11

13 Das Teufelsquadrat ergibt sich somit aus den Software-Wirtschaftlichkeitsfaktoren: - Zeit: Ist der einfachste Faktor und lässt sich sehr leicht messen. Zeit ist weder beeinflussbar noch vermehrbar und stellt oft einen kritischen Faktor bei der Softwareentwicklung dar. Viele Software Projekte sind deshalb ein Wettrennen mit der Uhr. z.b. Y2K, Euro Einführung. - Kosten: Sind ein Maßstab für den Ressourcenverbrauch während der Abwicklung eines Projektes. Die Kosten der Ressourcen (Personal, Betriebskosten ) werden in der Regel von dem Anwender entweder direkt oder indirekt getragen. - Umfang: Ist die Menge der Software, die an den Anwender ausgeliefert wird. (=Summe aller Funktionen und Informationen). Um die Quantität zu messen werden häufig Function Points, Datenelemente oder Dokumente verwendet. (Lines Of Code, Decision Counts) - Qualtiät: Darunter versteht man die Güte der Software. Sie ist das Produkt aller einzelnen gewichteten Qualitätsmerkmale bezüglich Effizienz, Effektivität und Rentabilität der Software aus Sicht der Konsumenten (Zuverlässigkeit, Sicherheit, Benutzerfreundlichkeit, Effizienz) und des Produzenten (Wartungsfreundlichkeit, Übertragbarkeit und Erweiterbarkeit). Um Qualität messen zu können muss sie genau definiert und quantifiziert werden. Auch dann bleibt aber Qualität immer noch relativ zu den Projektzielen. ( 2.3 Unterschiede zwischen IT-Projekten und herkömmlichen Projekten Aufgrund von allgemeinen Betrachtungen können Unterschiede erstens daran erkannt werden, dass Software ein immaterielles Produkt ist, dessen Fertigungsgrad und Qualität nur relativ schwer visuell wahrgenommen werden kann. Andererseits handelt es sich bei IT-Projekten um einen Entwicklungsprozess, welcher in einem sehr dynamischen Umfeld, betreffend Technologie und personelle Anforderungen, stattfindet und daher hohe Ansprüche an die Qualifikation und Leistungsfähigkeit der involvierten Beteiligten stellt. Seite 12

14 Aufwands- und Kostenschätzung Die Aufwands- und Kostenschätzung gestaltet sich durchaus schwierig. Die Gründe hierfür sind vielfältig und reichen von der Unsicherheit, mit der ambitionierte Entwicklungsprojekte generell zu kämpfen haben über die relativ geringe Erfahrung mit Software Projekten bis hin zu den sich kontinuierlich verändernden technologischen Rahmenbedingungen. Abschätzung des Entwicklungsfortschritts Dieser ist sehr schwer abzuschätzen. Konkret soll das heißen, dass zu einem beliebigen Zeitpunkt innerhalb der Projektabwicklung nur sehr schwer bestimmt werden kann, wie weit die Entwicklung einer Software schon tatsächlich fortgeschritten ist. Es ist daher beispielsweise möglich, dass das Projekt eine sehr rasch aber mit mangelhafter Qualität erstellte Systemarchitektur aufweist, es jedoch zu einem späteren Zeitpunkt zu einem erheblichen Mehraufwand und Nachbesserungen kommen kann, welche zumindest auf den ersten Blick nicht erkennbar waren. Die Schwierigkeit der Projektbegleitenden Qualitätssicherung Es ist sehr schwierig eine Projektbegleitende Qualitätssicherung zu gewährleisten, wobei die Hauptursache darin liegt, dass es sich bei einer Software um ein immaterielles Gut handelt. Während bei herkömmlichen Projekten wie z.b. dem Bau eines Lagerhauses, Zwischenergebnisse materiell verfügbar sind und somit zahlreiche Fehlentwicklungen aufgrund von augenscheinlichen Tatsachen kaum zu übersehen sind, ist andererseits für Software Projekte eine fundierte Qualitätssicherung erforderlich. Ergebnisse und Zwischenergebnisse Ergebnisse und ganz im speziellen Zwischenergebnisse sind für IT-Laien oft sehr schwer nachzuvollziehen. Diese Tatsache führt in letzter Instanz sehr häufig zu Problemen zwischen dem Management des Unternehmens und den Anwendern des zu erstellenden Systems auf der einen Seite und dem Projektteam auf der anderen Seite. Aufgrund dieser Schwierigkeiten innerhalb der Kommunikation, welche aufgrund einer möglichst eindeutigen formalen Notation seitens des Projektteams entsteht und folglich für Außenstehende oft nur sehr schwer verständlich ist (es existiert sozusagen kein Überbegriff für die an einem Softwareprojekt beteiligten Personen), entsteht somit ein Misstrauen, welches ein gemeinsames Arbeiten, in erster Linie auch Verständnis für die gegenseitige Arbeitsleistung, erschwert. Seite 13

15 Unteilbarkeit der Arbeit die Softwareentwicklung betreffend Es kann vorkommen, dass bei unterschiedlichen Projekten ein Verzug in der Bearbeitung durch den Einsatz zusätzlichen Personals ausgeglichen werden muss. Bei Softwareprojekten ist dies allerdings nicht möglich. Die Gründe dafür liegen darin, dass der Einarbeitungsaufwand und die Einarbeitungszeit für die zusätzlichen Arbeitskräfte in das konkrete Projekt dermaßen hoch sind, sodass kurzfristig sogar eine weitere Projektverzögerung eintreten kann. Es besteht daher das Problem, dass bereits eingearbeitete Mitarbeiter einen Teil ihrer Arbeitszeit dafür opfern müssen, um die neuen Mitarbeiter einzuschulen und auszubilden. Vorteile sind daher generell nur mittel- oder langfristig zu erwarten. Änderung der Anforderungen Ein wesentlicher Unterschied von Software Projekten zu herkömmlichen Projekten besteht darin, dass sich das Anforderungsprofil während der Projektlaufzeit im Normalfall ändert. Die Ursachen dafür liegen zum einen in der rasanten technischen Entwicklung und zum anderen darin, dass sich durch eine kontinuierliche Beschäftigung mit dem Projekt sowohl beim Projektteam als auch bei den Anwendern ein ständiger Lernprozess abspielt, welcher schlussendlich zu fortlaufenden Anforderungsänderungen führt. Zusammenhang zwischen Anforderungen und Kosten oft schwer erkennbar Oft ist es für das Management sehr schwer abzuschätzen, welche Aufwände sich hinter Zwischenergebnissen einerseits und der Berücksichtigung neuer Anforderungen andererseits verstecken. Es kann daher vorkommen, dass für Änderungen, die dem Anwender als sehr schwerwiegend erscheinen, nur ein relativ geringer technischer Aufwand notwendig ist, während eine andere Anforderung, welche dem Anwender beispielsweise relativ einfach erscheint, jedoch einen relativ hohen technischen Aufwand mit sich bringt. Softwareprojekte: Hoher Grad an Abstraktion bei geringer Normierung Bei technischen Entwicklungsaufgaben, wie beispielsweise dem Maschinenbau, ist es möglich, auf eine Vielzahl von normierten Komponenten zurückzugreifen. Dies lässt sich auf den Softwarebereich jedoch nur Ansatzweise umlegen. Die Objektorientierung bietet hier zwar Lösungsansätze, notwendig sind allerdings definierte Komponenten mit einer einfachen Schnittstelle und präzise definiertem Verhalten. (Henrich 2002) Seite 14

16 3 Das Risiko als Teil von Software Projekten Das folgende Kapitel soll sich nun eingehend mit der Thematik des Risikos als wesentlicher Teil von Software Projekten beschäftigen. Wie in der Ausführung zu den Unterschieden zwischen Software Projekten und herkömmlichen Projekten schon zu erkennen war, gestaltet es sich aufgrund verschiedenster Charakteristika von Software Projekten schwierig, risikofrei zu arbeiten. Vor allem die Tatsache, dass es sich hierbei um ein immaterielles Gut handelt führt dazu, dass das Risiko niemals vollständig ausgeschlossen werden kann. Zu Beginn soll daher die Notwendigkeit eines Risikomanagements für Unternehmen dargestellt werden. Es erfolgt weiters eine Abgrenzung und Erklärung des Risikobegriffs und eine Analyse, der in der Literatur vorkommenden Formen von Risikoarten. Abschließend soll in diesem Kapitel auf Risikofaktoren, wie Kundenverhalten und Aufwandsschätzung eingegangen werden, um deren Auswirkungen auf die Projektarbeit zu zeigen. 3.1 Das Risikomanagement Wenn ein Projekt kein Risiko birgt, dann lassen Sie die Finger davon Tom DeMarco Projekte ohne echte Risiken werden als Loser angesehen, weil sie fast nie gewinnbringend sind und deshalb nicht schon vor Jahren realisiert wurden. Risiken und Gewinn gehen üblicherweise immer Hand in Hand. (DeMarco 2003) IT Risikomanagement in Projekten basiert auf der Teilung der Verantwortung in die Zielverantwortung der Projektleitung und der Ergebnisverantwortung durch die Unternehmensleitung. Um diesen Zielen gerecht zu werden, sollte versucht werden, Risiken, sollten diese nicht vermeidbar, ausschließbar, versicherbar oder auf Dritte abwälzbar sein, überschaubar und begrenzbar zu gestalten. Eine der wichtigsten Komponenten, die zur Erfüllung dieser Anforderungen geeignet ist, stellt die Risikoanalyse- und bewertung dar. Die Organisation des Risikomanagements umfasst einen weiteren wichtigen Faktor. Nur durch eine ständige, periodische Wiederholung der Risikoanalyse und der dafür erforderlichen Überarbeitung des Risikokataloges lassen sich Maßstäbe für die Bewertung schaffen, welche es erlauben, den Erfolg eingeleiteter Maßnahmen zur Risikominimierung zu beurteilen. (Franke 1990) Seite 15

17 3.1.1 Abgrenzung des Begriffs Risikomanagement Ganz allgemein werden unter Risikomanagement alle erforderlichen Aufgaben und Maßnahmen zur Risikobekämpfung verstanden. Aus der Sicht eines Unternehmens umfasst Risikomanagement alle systematischen Maßnahmen zur rechtzeitigen Erkennung, Bewertung und Bewältigung potentieller Risiken. Es soll dabei die Unternehmensführung unterstützen, elementare Risiken, welche geeignet sind den Unternehmenserfolg bzw. Bestand zu gefährden, rechtzeitig zu erkennen, um diese zu bewältigen. Dafür ist es notwendig, ungünstige Entwicklungen im Unternehmen frühzeitig aufzuzeigen, als auch neue bisher nicht definierte Risiken zu erkennen. Laut DIN wird der Begriff Risikomanagement sehr abstrakt definiert als systematische Anwendung von Managementgrundsätzen, Verfahren und Praktiken zwecks Ermittlung des Kontexts sowie Identifikation, Analyse, Bewertung, Steuerung/Bewätltigung, Überwachung und Kommunikation von Risiken. (Gaulke 2004, S. 6) Voraussetzung für ein Risikomanagementsystem ist, dass es ganzheitlich angelegt sein sollte und alle Unternehmensbereiche berücksichtigt. Die Notwendigkeit eines unternehmensweiten Risikomanagementsystems ergibt sich aufgrund der Tatsache, dass Einzelrisiken kumuliert werden und sich dadurch in Wechselwirkung mit anderen Risiken befinden können. Ein Risikomanagementsystem besteht aus den drei Grundelementen Frühwarnsystem, Überwachungssystem und Controlling. (Gaulke 2004) Zusammenfassend kann also festgehalten werden, dass es sich beim Risikomanagement um einen essentiellen Bestandteil der Unternehmenspolitik handelt, der immer proaktiv gestaltet ist. Dies bedeutet, dass sich das Risikomanagement mit Risiken beschäftigt, bevor sie entstehen. Vereinfacht ausgedrückt besteht Risikomanagement aus den folgenden Aktivitäten: - Identifizierung von Risiken - Analyse und Bewertung von Risiken einschließlich der Aufstellung eines Maßnahmenkataloges - Festlegung von Risikostrategien - Monitoring von Risiken Seite 16

18 3.1.2 Die Notwendigkeit Die Notwendigkeit eines unternehmensweiten Risikomanagements ergibt sich aufgrund der Tatsache, dass sich Einzelrisiken akkumulieren und sich in Wechselwirkung mit anderen Risiken befinden können. Bei IT Projekten ergibt sich der Bedarf für ein Risikomanagement aus gesetzlicher Sicht und aus dem Aspekt unterschiedlicher Standards und Leitfäden. Dabei wird deutlich, dass trotz fehlender gesetzlicher bzw. aufsichtlicher Konkretisierung Risikomanagement ein unerlässlicher Bestandteil eines jeden größeren IT Projektes sein sollte. Das Thema Risikomanagement bei IT Projekten hat für Unternehmen nicht nur aufgrund der strategischen Bedeutung der Informationstechnologie an Einfluss gewonnen, sondern auch weil IT Projekte immer anspruchsvoller und komplexer werden (Gaulke 2004). Die Gründe dafür sind: - Steigende Komplexität der Systeme und grenzüberschreitende Integration der IT- Strukturen durch Expansion und Globalisierung der Geschäftstätigkeit - Zunehmende Systemintegration und weitgehende Automatisierung von Geschäftsprozessen durch immer stärker wachsenden Wettbewerbsdruck - Steigende Abhängigkeit von der Verfügbarkeit und Sicherheit der Datenverarbeitung durch Öffnung der Unternehmenssysteme für Geschäftspartner und Kunden via Internet - Erhöhte Dynamik der Märkte durch neue Technologien, welche neuartige Geschäftsprozesse (z.b. reine Vertriebbanken) ermöglichen - Informationstechnologie als Enabler für eine bessere Positionierung des Unternehmens im Wettbewerb - Steigende Anforderungen des Gesetzgebers und der Aufsichtsbehörden (z.b. die Mindestanforderungen an das Betreiben von Handels- und Kreditgeschäften, Basel II) Zusätzlich entstehen bei IT Projekten im Vergleich zu anderen Projekten besonders inhärente Risiken. Diese ergeben sich aufgrund der oben schon genannten Tatsache, dass es ich bei IT Projekten um immaterielle Güter handelt und deren Wahrnehmung dadurch für die menschli- Seite 17

19 chen Sinne quasi unmöglich ist. Ein Risikomanagement für derartige Projekte ist daher unumgänglich Abgrenzung des Risikobegriffs Risiko vs. Krise Der Begriff Krise stammt aus dem Griechischen und bedeutet entscheidende Wendung. Im Chinesischen zum Beispiel besteht das Wort aus zwei Zeichen, welche Chance und Gefahr darstellen. Eine Krise markiert daher die Höhe einer sich zuspitzenden Entwicklung, die von Chancen und Gefahren begleitet ist (Saynisch 1994) Projektrisiken sind somit Prozesse, die - zeitlich begrenzt sind - nicht gewollt oder gewünscht wurden - und den Fortbestand des Unternehmens und des Projektes substantiell gefährden Folgende Tabelle soll die unterschiedlichen Merkmale von Risiko und Krise gegenüberstellen: Risiko Mögliche Zielabweichung in der Zukunft Statische Situation Verlangt nach Vorsorge Krise Zielabweichung ist Realität geworden Dynamische Situation Verlangt nach unmittelbarer Intervention Tabelle 1: Risiko vs. Krise in Anlehnung an Saynisch (1994) Risiko vs. Chance Laut Saynisch (1994) verhalten sich Chancen und Risiken komplementär zueinander. Chancen und Risiken sind immer als Einheit aller Möglichkeiten zu betrachten. In der Vergangenheit wurde der Risikobegriff recht einseitig bevorzugt, was eine negative Perspektive förderte. Diese hat als Meßlatte für den Erfolg keine Höherordnung, sondern dient nur der Beibehal- Seite 18

20 tung des vorhandenen Gleichgewichtszustandes. Die Möglichkeiten einer Innovation bzw. Diversifikation sind demnach dem Risikobegriff fremd, diese gehören zum Chancenprinzip. (Saynisch 1994) Operatives Risiko vs. Projektrisiko Projektrisiken unterscheiden sich von normalen operativen Risiken. Während operative Risken häufig wiederkehrend, am Geschäftsprozess orientiert und funktional sind, sind Projektrisiken meist einmalig und im Hinblick auf die Projektziele Ergebnisorientiert. (Gaulke 2004) Was ist Risiko In der Literatur findet sich eine Vielzahl von Definitionen, die sich mit dem Begriff Risiko beschäftigen. Interessant erscheint die Betrachtung, wo das Wort Risiko überhaupt herkommt. Risiko leitet sich vom italienischen Begriff risicare, sprich etwas wagen ab. Grundlegend ist dabei, dass der Ausgang ungewiss ist, man somit also nicht genau weiß, ob etwas passiert oder nicht und wenn, welche Auswirkungen dies haben kann. (Versteegen 2003) Im betrieblichen Bereich versteht man unter Risiko ganz allgemein die Gefahr, dass Ereignisse oder Handlungen ein Unternehmen daran hindern können, seine Ziele zu erreichen bzw. seine Strategien erfolgreich umzusetzen. Weiters versteht man darunter die Möglichkeit ungünstiger künftiger Entwicklungen oder die Gefahr, die den Prozess der Zielsetzung und Zielerreichung begleiten und ihn negativ beeinflussen können. Eine weitere Definition liefert Schnorrenberg (1997). Er beschreibt Risiko als ein Ergebnis, von dem nicht sicher bekannt ist, ob es eintreten und/oder in welcher genauen Höhe es einen Schaden verursachen wird. Ein Ereignis, dass mit Sicherheit eintreten wird, stellt demnach ein Problem und kein Risiko dar. (Schnorrenberg 1997, S. 4) Seite 19