projektmanagement aufgabenstellung und übungsunterlagen

PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
PROJEKTMANAGEMENT
LV Nr. 706.023 (1 Ue)
Aufgabe 1
AUFGABENSTELLUNG
UND ÜBUNGSUNTERLAGEN
Von der Projektidee zum Projektvorschlag
und Risikomanagement
Autoren:
Evelyn Pilch
Andreas Ortner
Lehrveranstaltungsleiter:
Dipl.-Ing. Dr.techn. Christian Gütl
Seite 1 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
1. AUFGABENSTELLUNG
Im Rahmen der Übung werden lediglich Teilaspekte des Projektmanagementprozesses behandelt.
Ziel der ersten Aufgabe ist es, eine Projektidee zu konkretisieren und in einen Projektvorschlag
überzuführen sowie eine Risikoanalyse durchzuführen.
Den Ausgangspunkt der Übung bildet die Beschreibung eines fiktiven Unternehmens im
Softwarebereich. Neben der Aufbauorganisation werden die Strategien und Unternehmensziele,
die Unternehmensphilosophie sowie Leitbild und Unternehmenswerte dargestellt.
Im 1. Teil der Aufgabe soll eine Software-Projektidee gefunden, beschrieben und anschließend ein
Projektvorschlag ausgearbeitet werden. Hierbei soll es sich vorzugsweise um ein internes
Software-Projekt handeln, welches dem Unternehmen selbst zu gute kommt (z.B.
Informationssystem für eine bestimmte Abteilung).
Hinweis: Der eigenen Phantasie sind grundsätzlich keine Grenzen gesetzt und benötigte
Annahmen bezüglich des Unternehmens und der einzelnen Abteilungen sind erlaubt und
erwünscht.
Im 2. Teil der Aufgabe wird die Thematik des Risikomanagements behandelt, indem Risiken im
Zusammenhang mit dem geplanten Projekt erfasst und analysiert werden sollen. Hinweis: Die
Risiken sollen im Rahmen einer Brainstorming Session erfasst und beschrieben werden.
Die Ergebnisse der Aufgabe 1 (Deliverables) sind in die bereitgestellte Vorlage einzufügen, welche
jene Punkte beinhaltet, die ausgearbeitet werden müssen.
2. VON DER PROJEKTIDEE ZUM PROJEKTVORSCHLAG
Der Prozess zur Erstellung eines Projektvorschlages kann in zwei Phasen eingeteilt werden. Eine
klar formulierte Projektidee dient als Entscheidungsbasis, ob es für das Unternehmen interessant
ist, die Idee weiterzuverfolgen. Nach Durchsicht und Bewertung der Projektidee wird entschieden,
ob ein Projektvorschlag ausgearbeitet wird. Der Projektvorschlag stellt eine Verfeinerung der
Projektidee dar und dient als Entscheidungshilfe [Kapur 2005].
2.1.
Darstellung der Projektidee
Die Grundlage eines erfolgreichen Projektes bildet eine gut durchdachte und klare Beschreibung
der Projektidee. Als Anleitung und Hilfestellung sollten folgende Punkte beachtet werden:
-
Situationsanalyse
Zweck und Absicht des Projektes
Wer wird es verwenden?
Wo wird es verwendet werden?
Such-Schlüsselwörter
Ausrichtung auf die Unternehmensstrategien
Der Wert für das Unternehmen
Kritische Erfolgsfaktoren
Projekt Deadline
Projekt Einflüsse
Konsequenzen bei Ablehnung des Projektes
Sicherheitsanforderungen
Zeitliche Gelegenheit
Seite 2 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
2.2.1. Situationsanalyse
In diesem Punkt soll vor allem die derzeitige Situation beschrieben werden. Es wird dabei ein Blick
in die Vergangenheit geworfen und kurz betrachtet, wie es zur derzeitigen Situation gekommen ist.
Das aktuelle Problem (oder Bedürfnis) soll beispielsweise aufgrund folgender Fragen erläutert
werden:
-
Was ist fehlerhaft bzw. fehlt?
Warum muss dieser Fehler behoben werden?
Ein spezieller Lösungsvorschlag darf in diesem Punkt nicht gegeben werden. Ein bereits zu
diesem Zeitpunkt gegebener Lösungsvorschlag würde den Denkprozess zum Finden der besten
beziehungsweise optimalen Lösung nachhaltig hemmen.
2.2.2. Zweck und Absicht des Projektes
Die Absicht des Projektes soll überzeugend dargestellt werden. Eine gute Herangehensweise ist
hierbei die Darstellung der Situation nach erfolgreichem Abschluss des Projekts. Es soll aufgezeigt
werden, wie sich die Situation zukünftig verbessert und welche Vorteile beziehungsweise welchen
Nutzen das Projekt für das Unternehmen hat.
2.2.3. Wer wird es verwenden?
In diesem Punkt soll das Ausmaß des Einflusses des Projektes abgeschätzt werden. Es stellt sich
die Frage, ob nur einige wenige oder eine große Anzahl von Personen(-gruppen) beziehungsweise
Abteilungen vom beabsichtigten Projekt betroffen sind. Wenn ein Nutzen beispielsweise für das
gesamte Unternehmen absehbar ist, sollte diese Information besonders hervorgehoben werden.
2.2.4. Wo wird es verwendet werden?
Die räumliche Ausdehnung des Projektes spielt eine wesentliche Rolle und sollte kurz dargestellt
und erläutert werden. Ein Projekt kann hierbei einen lokalen, nationalen oder internationalen
Charakter haben.
2.2.5. Such-Schlüsselwörter
Ein wichtiger Aspekt ist die Überprüfung, ob bereits ähnliche, idente oder überlappende Projekte
beziehungsweise Projektideen existieren. Projekte und Projektideen sollten daher beispielsweise
im Rahmen einer „Ideen-Datenbank“ gespeichert und mit Such-Schlüsselwörtern („key search
words“) versehen werden. Aufgrund dieser Schlüsselwörter können Projekte leichter aufgefunden
werden. Such-Schlüsselwörter müssen während der Projektdurchführung fortlaufend aktuell
gehalten werden, um Änderungen (z.B. in der Funktionalität) widerspiegeln zu können.
2.2.6. Ausrichtung auf die Unternehmensstrategien
Bei jedem neuen Projekt soll berücksichtigt werden, welche Unternehmensstrategien damit
unterstützt und verfolgt werden:
-
Marktanteil vergrößern
Innerbetriebliche Leistungssteigerung
Kundenbindung erhöhen
Kundenservice verbessern
Seite 3 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
-
Produktivität erhöhen
Markenbewusstsein erhöhen
Gewinn/Profit erhöhen
Kosten reduzieren
u.a.
Der Geschäftsführung soll vor Augen geführt werden, welche Strategien mit der Projektidee
gekoppelt und verfolgt werden können. Projektideen, die sich mit Unternehmensstrategien und –
zielen vereinbaren lassen, werden als erfolgsversprechend angesehen und vorrangig in Erwägung
gezogen.
2.2.7. Der Wert für das Unternehmen
Ein wichtiger Aspekt bei jeder Projektidee ist die Überlegung, ob das Projekt für die Unternehmung
durchführenswert ist. Es stellt sich die Frage, welchen Nutzen beziehungsweise Wert das Projekt
für das Unternehmen hat:
-
zusätzliche Einnahmen
Konkurrenzvorteil
Kostenersparnis
Kapazitätserweiterung
Höherer Marktanteil
Personalabbau
u.a.
Der Nutzen beziehungsweise Wert für das Unternehmen muss messbar sein.
Beispiel:
Personalabbau Call-Center: 10 Personen,
jährliche Kostenersparnis: 200.000 Euro
Natürlich muss der vorgeschlagene Nutzen für das Unternehmen vollständig durchdacht werden.
Personalabbau kann beispielsweise verantwortlich für hohe Abfertigungszahlungen, sinkende
Mitarbeitermoral oder Rufschädigung sein.
Weiters können auch Konsequenzen dargelegt werden, wenn das Projekt nicht durchgeführt wird
(zB Strafen, verpasste Gelegenheiten).
2.2.8. Kritische Erfolgsfaktoren
Um den Erfolg eines vorgeschlagenen Projektes feststellen zu können, sollen messbare
Indikatoren definiert werden. Diese kritischen Erfolgsfaktoren können in zwei Kategorien eingeteilt
werden:
PRODUKT-BEZOGEN:
Funktionalität, Features, Qualität, Usability, Sicherheit, Zufriedenheit des Anwenders, Budget u.a.
PROZESS-BEZOGEN:
Kommunikation zwischen Entwickler und Anwender, Vorbereitung des Anwenders für die
Produkteinführung, Qualität bei der Projektdurchführung u.a.
Seite 4 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
Beispiele:
KRITISCHER ERFOLGSFAKTOR
MESSWERT
Systemverfügbarkeit (uptime)
Datengenauigkeit
Zuhilfenahme des technischen Supports
99%
98%
weniger als 3 Mal bei 100 Anwendungsfällen
2.2.9. Projekt Deadline
Viele Vorgesetzte beziehungsweise Auftraggeber diktieren eine Deadline, bevor ein Konzept für
die Durchführung und Problemlösung im Rahmen eines Projektes erstellt wurde.
Der Schwerpunkt wird oft auf die Fertigstellung des Projektes innerhalb eines bestimmten
Zeitraumes als auf die Qualität des Endproduktes gelegt.
Eine vom Auftraggeber vorgegebene Deadline soll auf jeden Fall hinterfragt werden:
-
Was sind die Gründe für diese Deadline (Willkür, Wettbewerbsdruck, finanzielle
Einschränkungen, Rechtliche Erfordernisse)?
Was ist die Tragweite bei Nichterreichung der Deadline?
Welche Kompromisse sind bei Nichterreichung der Deadline möglich?
Die gewünschte Deadline soll nach Möglichkeit dokumentiert und begründet sowie bei absehbarer
Nichterreichbarkeit mit dem Auftraggeber diskutiert werden. In jedem Fall ist es schwierig, in der
frühen Phase der Ideenfindung eine realistische Deadline zur Fertigstellung des Projektes
festzulegen.
2.2.10. Projekt Einflüsse
Alle Systeme, Projekte und Prozesse, die vom vorgeschlagenen Projekt beeinflusst werden,
sollten einheitlich erfasst werden.
Es soll untersucht werden, bis zu welchem Grad derzeitige Systeme, Produkte, Projekte und
Prozesse durch das neue Projekt eine Änderung erfahren.
Der Arbeitsaufwand, um ein neues Projekt in bestehende Produkte, Prozesse, Systeme und
Abläufe zu integrieren, darf nicht unterschätzt werden.
2.2.11. Konsequenzen bei Ablehnung des Projektes
In diesem Punkt wird der Einfluss auf das Unternehmen beschrieben, wenn eine vorgeschlagene
Projektidee verworfen wird.
Diese Überlegungen bilden die Grundlage, um eine neue Projektidee abzulehnen oder zu
rechtfertigen.
2.2.12. Sicherheitsanforderungen
Bestimmte Projekte unterliegen möglicherweise umfangreichen Sicherheitsanforderungen. Vor
allem in Entwicklungsbereichen, die nur für autorisierte Personengruppen bestimmt sind, müssen
Maßnahmen und Anforderungen bezüglich Sicherheit und Informationsverbreitung festgelegt und
beschrieben werden.
Seite 5 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
2.2.13. Zeitliche Gelegenheit
Bei einigen Projekten hängt der Erfolg vor allem von zeitlichen Gelegenheiten ab.
Solche Projekte müssen oft zu einem bestimmten Zeitpunkt fertig gestellt beziehungsweise
einsatzbereit sein, um erfolgreich zu sein.
Beispiele:
Ein Projekt zu einem neuen Anmeldesystem für
Semesterbeginn abgeschlossen und einsatzbereit sein.
Studenten
muss
vor
Ein neues Produkt eines Computerherstellers soll kurz vor einer großen Messe (zB
CeBIT) fertig gestellt werden.
Wird eine solche oft zeitlich sehr kurze Gelegenheit nicht genutzt, kann dies zu zahlreichen
negativen Konsequenzen für das Unternehmen führen. Aus diesem Grund sollen alle
Randbedingungen festgehalten werden, die einen Einfluss auf diese zeitliche Komponente
ausüben.
Eine klare Beschreibung der Projektidee bildet die Grundlage für eine genaue Definition der
Problemstellung oder Bedürfnisses des Projektes und der zu erwartenden Vorteile und Nutzen für
das Unternehmen.
Weiters erhält das gesamte Projektteam eine geeignete Darstellung der für das Projekt
erforderlichen Hintergrundinformationen. Es stellt sich die Frage, ob die Projektidee verworfen,
überarbeitet oder genehmigt werden soll.
2.2.
Der Projektvorschlag
Nach Durchsicht und positiver Bewertung der Projektidee wird ein Projektvorschlag entwickelt.
Folgende zusätzliche Informationen werden zur Erstellung eines Projektvorschlages benötigt:
-
Key stakeholders
Projekt Annahmen
Veränderungen in der Organisation
Finanzieller Rahmen
Projekt Eigentum
Überlappende und gleichartige Projekte
2.2.1. Key stakeholders
Alle an einem Projekt beteiligten und vom Projektergebnis beeinflussten Personen (stakeholders)
müssen identifiziert werden. Diese werden grundsätzlich in zwei Gruppen eingeteilt:
-
Policy-level stakeholders
Implementation-level stakeholders
POLICY-LEVEL STAKEHOLDERS:
Hierbei handelt es sich um jene internen und externen Personengruppen, die als
Entscheidungsträger auftreten beziehungsweise das Projekt beeinflussen können und weiters
Richtlinien für das Projekt festlegen.
Seite 6 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
IMPLEMENTATION-LEVEL STAKEHOLDERS:
Personengruppen, die vom Projektergebnis beeinflusst werden (z.B. durch Änderung der
bisherigen täglichen Arbeitsabläufe), werden als Implementation-level stakeholders bezeichnet.
Mögliche stakeholder können folgendermaßen identifiziert werden:
-
Beratung und Verkauf
Forschung und Entwicklung
Personal und Schulung
Rechnungswesen/Controlling
SW-Erstellung und Adaption
u.a.
Natürlich können Personen(-gruppen) einerseits einen messbaren Einfluss auf das Projekt
ausüben und andererseits nachhaltig vom Projektergebnis beeinflusst werden (z.B. Einführung
eines Informationssystems für Forschung und Entwicklung).
2.2.2. Projekt Annahmen
Projekte bauen auf Annahmen von Projektbeteiligten über das Eintreten von bestimmten
zukünftigen Ereignissen.
Beispiele:
Die Sicherheits-Gruppe wird das veränderte Passwort-Management System am 15.
Juni in Betrieb nehmen.
Drei neue Entwicklungscomputer werden am Monatsende zur Verfügung gestellt.
Zwei zusätzliche Programmierer werden dem Projekt ab 1. Juli zugewiesen.
Alle aufgelisteten und beschriebenen Annahmen müssen während der Projektdurchführung
fortlaufend überprüft und diskutiert werden. Durch Rücksprachen mit den beteiligten Personen(gruppen) muss analysiert werden, mit welcher Wahrscheinlichkeit die entsprechende Annahme
zum festgelegten Zeitpunkt eintreten wird.
2.2.3. Veränderungen in der Organisation
Der Projektvorschlag sollte eine Darstellung über die durch das Projektergebnis zu erwartenden
Veränderungen (politisch, kulturell, technisch) in den Bereichen der key stakeholders beinhalten.
2.2.4. Finanzieller Rahmen
Jedes Projekt unterliegt oftmals einer finanziellen Einschränkung seitens des Auftragsgebers.
Bereits in frühen Projektphasen ist es von Vorteil, wenn Informationen bezüglich des finanziellen
Rahmens angesprochen und diskutiert werden. Weiters soll festgelegt werden, welche Abteilung
des Unternehmens das Budget bereitstellt und welcher Entscheidungsträger das Budget
genehmigt.
2.2.5. Projekt Eigentum
Es stellt sich die Frage, welche Abteilung die Verantwortung über das Projektergebnis (Endprodukt,
Prozess) übernimmt beziehungsweise zum Eigentümer wird.
Seite 7 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
2.2.6. Überlappende und gleichartige Projekte
Die Dokumentation bezüglich Überlappung des geplanten Projektes mit anderen, bereits fertig
gestellten oder in Entwicklung befindlichen Projekten ist ein wichtiger Bestandteil des
Projektvorschlages. Eine gut gewartete Datenbank unterstützt hierbei die Informationsaufbereitung
hinsichtlich gleichartiger und überlappender Projekte beziehungsweise Projektideen.
2.3.
Zusammenfassung
Eine gut ausgearbeitete Beschreibung der Projektidee und ein umfassender Projektvorschlag
bilden die Grundlage für ein erfolgreiches Projekt. Schlecht durchdachte und unrentable
Projektideen werden herausgefiltert und erleichtern die Entscheidung für jene Projekte, die einen
hohen Nutzen für das Unternehmen versprechen.
3. RISIKOMANAGEMENT
3.1.
Risiko
Risiko ist ein Maß für die Wahrscheinlichkeit, das Projektziel nicht zu erreichen. Es muss die
Eintrittswahrscheinlichkeit eines negativen Ereignisses verbunden mit den Folgen und Schäden
berücksichtigt werden.
3.2.
Risikomanagement
Risikomanagement ist die Art mit Risiko umzugehen. Sie beinhaltet die Planung und Einschätzung
von Risiken (Identifikation und Analyse, z.B. wie sich Risiken auf den Zeitplan oder die Qualität der
entwickelten Software auswirken können), die Entwicklung von Strategien zum Umgang mit dem
Risiko, die Überwachung von Risiken und die Beurteilung dessen, wie sich die Risiken verändern
können.
Es ist ein Aspekt des Projektmanagements und sollte stets proaktiv (entwickle Notfallpläne schon
bevor etwas passiert) und nicht reaktiv (handle erst wenn schon ein Problem aufgetreten ist)
erfolgen. Dabei geht es darum, die Wahrscheinlichkeit des Eintritts eines Ereignisses zu
reduzieren oder dessen Auswirkungen so gering als möglich zu halten.
Risiken können das Projekt, die entwickelte Software und das Unternehmen selbst gefährden
[Sommerville 2001].
-
-
-
Projektrisiken: sind Risiken, die sich auf den Projektzeitplan oder die Ressourcen auswirken.
z.B. Personalveränderung - Personal verlässt das Projekt vor dessen Fertigstellung;
Managementveränderung - veränderte Vorgaben im Projekt aufgrund eines Wechsels im
Management, etc.
Produktrisiken: sind Risiken, die die Qualität oder die Leistung der entwickelten Software
beeinträchtigen.
z.B. Unzureichende Leistung - die Software erbringt nicht die im Pflichtenheft vereinbarten
Leistungen, etc.
Wirtschaftliche Risiken: sind Risiken, die sich auf das Unternehmen auswirken, welches das
Projekt entwickelt oder beschafft.
z.B. Produktkonkurrenz - Konkurrenz bringt ähnliche Software auf den Markt, bevor die
eigene Software fertig ist, etc.
Risiken können einen der drei Bereiche aber auch alle Bereiche überschneidend betreffen.
Seite 8 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
3.3.
Ablauf des Risikomanagements
Risikomanagement ist ein iterativer Prozess, der sich innerhalb des Projekts wiederholt (siehe
Abbildung 1: Ablauf des Risikomanagements). Sobald Pläne möglicher Risiken und deren
Vermeidung erstellt sind, muss man die Situation überwachen. Wenn mehr Informationen über die
Risiken verfügbar sind, müssen diese erneut analysiert und neue Prioritäten gesetzt werden.
Dabei muss man immer darauf achten, dass im selben Arbeitsschritt auch die Risikovermeidungund Notfallpläne modifiziert werden müssen.
Abbildung 1: Ablauf des Risikomanagements (entnommen aus [Sommerville 2001])
3.3.1. Risikoerkennung – Bestimmung möglicher Projekt-, Produkt- und wirtschaftlicher
Risiken
Die Risikoerkennung stellt den ersten Schritt des Risikomanagements dar und soll mögliche
Risiken des Projekts entdecken. In diesem Schritt sollen nur alle Ideen über Risiken gesammelt
werden. Dabei erfolgt jedoch noch keine Bewertung bzw. Prioritätenreihung der Risiken. Dieser
Schritt kann in der Praxis als Teamarbeit (z.B. Brainstorming) erfolgen oder auf den Erfahrungen
des Managers beruhen. Bei der Risikoerkennung muss man jedoch beachten, dass sich die
identifizierten Risiken im Projektlebenszyklus verändern können. Unklare Zielsetzungen und
Projektumfang können beispielsweise durch zunehmende Informationsgenerierung genau definiert
und abgegrenzt werden.
Mögliche Risikoarten können sein [Sommerville 2001]:
-
-
-
-
-
-
1
Technologische Risiken: Risiken, die sich aus den Hard- oder Softwaretechnologien
ergeben, die im entwickelten System Verwendung finden. Z.B. Die im System verwendete
Datenbank kann nicht so viele Transaktionen pro Sekunde durchführen wie erwartet.
Personenbezogene Risiken: Risiken, die mit den Personen im Entwicklungsteam
zusammenhängen. Z.B. Es ist unmöglich, genügend Personal mit den benötigten Fähigkeiten
zu finden.
Unternehmensbezogene Risiken: Risiken, die aus dem Unternehmensumfeld resultieren, in
dem die Software entwickelt wird. Z.B. Finanzielle Probleme des Unternehmens zwingen zu
Kürzungen des Projektbudgets.
Risiken durch Werkzeuge: Risiken, die sich aus den CASE-Werkzeugen1 und anderer bei
der Entwicklung des Systems verwendeter Unterstützungssoftware ergeben. Z.B. Der durch
CASE-Werkzeuge generierte Code ist ineffizient.
Anforderungsrisiken: Risiken, die auf Änderungen der Anforderungen des Kunden und auf
den Umgang mit den Anforderungsänderungen zurückzuführen sind. Z.B. Es werden
Änderungen der Anforderungen vorgeschlagen, die eine beträchtliche Nachbearbeitung des
Entwurfs nach sich ziehen.
Schätzrisiken: Risiken, die sich aus Schätzungen des Managements über die
Systemcharakteristik und die zur Herstellung des Systems benötigten Ressourcen ergeben.
Z.B. Die zur Entwicklung der Software benötigte Zeit wird unterschätzt.
CASE = Computer Aided Software Engineering
Unter CASE-Werkzeugen versteht man alle Programme, die zur Erstellung einer Software beitragen (z.B. Programme
zum Code schreiben (Programmierumgebung, Editor), zum Diagramme erstellen, zur Unterstützung bei der
Dokumentation etc.).
Seite 9 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
-
-
-
Qualitätsrisiken: Risiken, die aus mangelhaften Zwischenergebnissen resultieren, aus zu
wenig durchgeführten Tests und Kontrollen. Z.B. Durch zu wenige Zwischentests kommt es
zu Problemen beim Probebetrieb.
Terminrisiken: Risiken ergeben sich aus einer Terminverzögerung während des Projekts, die
eine
rechtzeitige
Übergabe
unmöglich
gemacht
hat.
Z.B.
Aufgrund
von
Programmierungsfehlern können die Termine nicht eingehalten werden.
Kostenrisiken: Risiken ergeben sich, wenn an verschieden Orten Entwicklungen
durchgeführt werden oder wenn der Kunde nicht zahlt. Z.B. Kunde ist in Konkurs gegangen
und kann daher die Software nicht mehr bezahlen.
3.3.2. Risikoanalyse – Beurteilung von Wahrscheinlichkeit und Konsequenzen dieser
Risiken
Bei der Risikoanalyse werden alle in der Risikoerkennung eruierten Risiken der Reihe nach
betrachtet und hinsichtlich ihrer Eintrittswahrscheinlichkeit (hoch, mittel, niedrig, dass dieses
Ereignis eintritt) und ihrer Konsequenzen (unbedeutend, tolerierbar, ernst, katastrophal wenn
dieses Ereignis eintreten sollte) beurteilt.
Eine solche Analyse ist in Tabelle 1 dargestellt.
RISIKO
WAHRSCHEINLICHKEIT AUSWIRKUNGEN
Es ist unmöglich, genügend Personal mit den
benötigten Fähigkeiten zu finden.
Finanzielle Probleme des Unternehmens zwingen
zu Kürzungen des Projektbudgets.
Kunde ist in Konkurs gegangen und kann daher
die Software nicht mehr bezahlen.
Die zur Entwicklung der Software benötigte Zeit
wird unterschätzt.
Die im System verwendete Datenbank kann nicht
so viele Transaktionen pro Sekunde durchführen
wie erwartet.
Aufgrund von Programmierungsfehlern können die
Termine nicht eingehalten werden.
Durch zu wenige Zwischentests kommt es zu
Problemen beim Probebetrieb.
Kunde
versteht
die
Auswirkungen
von
Anforderungen nicht
Der durch CASE-Werkzeuge generierte Code ist
ineffizient.
hoch
katastrophal
niedrig
katastrophal
niedrig
katastrophal
hoch
ernst
mittel
ernst
mittel
ernst
mittel
ernst
mittel
tolerierbar
mittel
unbedeutend
Tabelle 1: Risikoanalyse (entnommen aus [Sommerville 2001])
Aufgrund dieser Ergebnisse werden die Risiken nach ihren Auswirkungen von katastrophal bis
unbedeutend gereiht. Diese Reihung beruht zumeist auf den Erfahrungswerten des Projektleiters.
Dadurch ergibt sich die Prioritätenliste der erkannten Risiken.
Bsp. Risikoanalyse – mathematische Variante der Risikogewichtung:
Diese Gewichtungen der Risiken können natürlich nicht nur aufgrund der Erfahrungen des
Managers erfolgen, sondern auch mittels Skalen. Dabei setzen sich die Ergebnisse aus der
Wahrscheinlichkeit multipliziert mit der Auswirkung zusammen. Je höher diese Zahl ist, desto
höher ist die Wahrscheinlichkeit, dass das Risiko eintritt und negative Folgen mit sich bringt.
Seite 10 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
Skala Wahrscheinlichkeit
niedrig
mittel
hoch
1
2
3
Skala Auswirkung
unbedeutend tolerierbar ernst katastrophal
1
2
3
4
Wahrscheinlichkeit Auswirkung Ergebnis
hoch
hoch
mittel
hoch
katastrophal
ernst
katastrophal
tolerierbar
12
9
8
6
hohes
Risiko
mittel
mittel
niedrig
hoch
ernst
tolerierbar
katastrophal
unbedeutend
6
4
4
3
mittleres
Risiko
niedrig
mittel
niedrig
niedrig
ernst
unbedeutend
tolerierbar
unbedeutend
3
2
2
1
geringes
Risiko
3.3.3. Risikoplanung – Aufstellen von Plänen zur Behandlung des Risikos durch Umgehen
des Risikos oder durch das Minimieren seiner Auswirkungen
Die Risikoplanung zieht alle Hauptrisiken in Betracht und entwickelt Strategien zum Umgang mit
dem Risiko.
Bei der Risikoplanung kann man 3 Kategorien von Strategien unterscheiden [Sommerville 2001]:
- Vermeidungsstrategie: versuche die Wahrscheinlichkeit für das Auftreten des Risikos zu
verkleinern. Z.B. fehlerhafte Komponenten, bekannt gutes Framework auswählen.
- Minimierungsstrategie: Ziel dabei ist es, die Auswirkungen des Risikos zu reduzieren. Z.B.
Krankheit des Personals.
- Notfallpläne: Dabei versucht man sich auf den schlimmsten Fall einzustellen, damit man
richtig vorbereitet ist und sofort eine Strategie für den Fall des Eintritts zur Hand hat. Z.B.
Finanzielle Probleme des Unternehmens, Konkurs des Sublieferanten.
Beispiele für Risiken bzw. die Strategien für die Vermeidung dieser sind in Tabelle 2 dargestellt.
RISIKO
STRATEGIE
Finanzielle Probleme
des Unternehmens
Man bereitet eine Zusammenfassung an das höhere Management
vor, in der man aufzeigt, welchen wichtigen Beitrag das Projekt zum
Erreichen der Ziele des Unternehmens leistet.
Man soll das Team so reorganisieren, dass es mehr
Überschneidungen bei den Arbeiten gibt, damit die Mitarbeiter die
Aufgaben jedes anderen verstehen.
Man sollte mögliche fehlerhafte Komponenten durch neu erworbene
ersetzen.
Krankheit des
Personals
Fehlerhafte
Komponenten
Tabelle 2: Risiken und Strategien für die Vermeidung (entnommen aus [Sommerville 2001])
Seite 11 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
Beispiele für mögliche Anzeichen für ein Risiko sind in Tabelle 3 dargestellt.
ART DES RISIKO
MÖGLICHE ANZEICHEN FÜR EIN RISIKO
technologisches Risiko
Späte Anlieferung von Hardware oder Unterstützungssoftware,
Berichte über viele technische Probleme.
personenbezogenes
Schlechte Moral beim Personal, schlechtes Verhältnis zwischen
Risiko
den Teammitgliedern
unternehmensbezogenes Gerüche im Unternehmen, zu geringe Aktivität des höheren
Risiken
Managements
Tabelle 3: Anzeichen für ein Risiko (entnommen aus [Sommerville 2001])
3.3.4. Risikoüberwachung – Ständiges Überprüfen des Risikos und Überarbeiten der Pläne
zur Risikominimierung, sobald mehr Informationen über das Risiko verfügbar
werden.
Bei der Risikoüberwachung müssen alle erkannten Risiken regelmäßig überprüft und beurteilt
werden, ob sie sich in ihrer Wahrscheinlichkeit oder Auswirkung verändert haben. Dabei ist auch
darauf zu achten, dass man neu aufkommende Risiken erkennt und diese in die Risikoanalyse
aufnimmt.
3.4.
1.
2.
3.
4.
5.
6.
7.
Leitfaden zur Erstellung eines Risikomanagements
Brainstorming zum gewählten Projektthema. Welche Risiken können im Zusammenhang
mit diesem Projekt auftreten (Schriftliche Ausarbeitung des Brainstormings ist gemeinsam
mit der Risikomanagementvorlage abzugeben!).
Entscheidung, welche Risiken man beachtet und welche man ins Risikomanagement
einbezieht.
Grobkategorisierung der Risiken (Projekt-, Produkt-, wirtschaftliches Risiko).
Bewerten der Risiken nach ihrer Wahrscheinlichkeit und ihren Auswirkungen, wenn sie
auftreten.
In der Reihenfolge der Prioritäten (hoch bis niedrig) in die Risikomanagementvorlage
eintragen.
Eruieren möglicher Strategien, um die Risiken zu vermeiden.
Herausfinden möglicher Anzeichen, welche darauf hinweisen, dass das Risiko eintreten
könnte.
Seite 12 von 13
PROJEKTIDEE, PROJEKTVORSCHLAG UND RISIKOMANAGEMENT
4. LITERATURVERZEICHNIS
[Kapur 2005]
Kapur, Gopal K.: Projekt management for information, technology, business and certification. New
Jersey 2005. S. 89-107, S. 154-159.
[Kerzner 2003]
Kerzner, Harold: Projekt Management. Ein systemorientierter Ansatz zur Planung und Steuerung.
1. Auflage. Bonn, Landsberg 2003. S. 581-601.
[Sommerville 2001]
Sommerville, Ian: Software Engineering. 6th edition. München 2001. S. 95-103.
Seite 13 von 13