Kategorien
Risikomanagement – ein simpler Ansatz
Heute wollen wir uns mal um eine leider viel zu selten zugewendeten Disziplin kümmern: dem Risikomanagement. Ich muss davor noch mal kurz sagen, dass ich kein ausgebildeter Projektmanager oder ähnliches bin, alles was ich hier schreibe sollte aber trotzdem Sinn machen. Manchmal ist purer Menschenverstand ja schon ausreichend.
Nehmen wir folgende Situation: Wir sind kurz vor der Einführung eines neuen technischen Systems. Wir als Techniker lieben natürlich alles neue und gehen überaus euphorisch an die Sache ran. Stellen Konzepte auf und definieren Lösungen. Leider vergessen wir dabei sehr häufig, dass jedes Projekt auch mit Risiken einhergeht. Ach ja, der Risikofaktor ist übrigens als Wahrscheinlichkeit mal Kosten definiert, da kommen wir aber gleich noch zu.
Warum ist es so schwer die Risiken aufzustellen? Ich gehe mal von aus, dass es dort psychologische Gründe gibt. Jeder der Risiken aufzeigt ist ein Bremser und boykottiert das Projekt. Ok, ist jetzt vielleicht ein wenig übertrieben, aber so ähnlich könnten die Gedanken der anderen Teammitglieder aussehen. Meist ist das aber ein falsches Verständnis, dass dort zugrunde liegt. Wenn man mal ein Risiko korrekt aufzeichnet, wird einem klar, dass es viel mehr ist als reines „Motzen“.
Für einfaches Risikomanagement reicht es sich ein paar Gedanken über das Risiko zu machen und folgende Fragen zu beantworten:
- Wie teuer wird es, wenn das im Risiko beschriebene Problem eintritt (niedrig, hoch, mittel) ?
- Wie hoch ist die Chance, dass das Problem auftritt (niedrig, mittel, hoch) ?
- Wann wird das Problem voraussichtlich Auftreten (Projektphase)?
- Welche Maßnahmen kann ich ergreifen, damit das Problem erst gar nicht auftritt?
- Welche Maßnahmen muss ich ergreifen, wenn das Problem auftritt?
Hat man diese Fragen beantwortet, kann eigentlich nichts mehr schief gehen. Zumindest hat man die Verantwortung dafür abgegeben, denn die Risiken sind ja, sobald man sie schriftlich veröffentlicht hat, bekannt. Wir haben es also auch hier mit einer klassischen „Cover-Your-Ass„-Methode zutun.
Was können wir jetzt mit den Antworten auf die Fragen anfangen? Zum ersten können wir Zeitpläne erstellen, wann wir uns um was kümmern. Das bezieht sich auf mögliche Gegenmaßnahmen in Zusammenhang mit dem Eintrittsdatum. Des Weiteren können wir schon anfangen das Problem zu bekämpfen bevor es eintritt.
Was mir noch immer ganz wichtig ist, dass Risikomanagement teil des Prozesses wird. So ist es die Pflicht jedes Teammitglieds sich darum zu kümmern. Es sind nicht immer die gleichen die „Bremsen“ was gut für die Teamzusammengehörigkeit ist.
Was ich übrigens in der nächsten Zeit aufstellen will, ist ein leichtgewichtiger Projektfahrplan, der gut zur Webentwicklung passt. Vielleicht bekommen wir da ja was gutes zusammen hin, das einen sicher durch ein Projekt geleitet.
PS: Heute nachmittag gibt es noch einen Vortrag zum Thema Risikomanagement.
Nicht zu vernachlässigen ist auch das Thema Akzeptanz-Gefahr. Die Frage, die es zu stellen gilt ist: Wer muss die Entscheidungen letztlich umsetzen bzw. anwenden? Habe ich diese Leute – Entwickler aber auch und vor allem Anwender – mitgenommen und überzeugt? Auf der Ebene kann nämlich dann das best-geplanteste Projekt gegen den Baum gehen.
„Hat man diese Fragen beantwortet, kann eigentlich nichts mehr schief gehen. Zumindest hat man die Verantwortung dafür abgegeben, denn die Risiken sind ja, sobald man sie schriftlich veröffentlicht hat, bekannt.“
Na ganz so einfach ist es aber nicht 🙂
Man macht in der Regel vor der Risikoanalyse eine Stakeholderanalyse (das sind alle Einflussgrößen, die auf ein Projekt wirken können: Personen, Personenkreise, Umwelt, Politik, Lieferanten etc pp).
Aufgrund Grundlage dieser Analyse kann man Risiken identifizieren. Dabei natürlich technische Punkte (z.B. Serverausfall) und wirtschaftliche Dinge (Mitarbeiter sind krank / überlastet) nicht vergessen.
Man berechnet den Risikowert = Eintrittswahrscheinlichkeit * Schadenshöhe. Die Schadenshöhe sollen als möglichst realistischer €-Wert und nicht als niedrig/mittel/hoch angegeben werden, ebenso wie die Eintrittswahrscheinlichkeit in Prozent angegeben wird. Raus bekommt man dann einen €-Wert.
Beispiel: Die Festplate des Subversion Servers schmiert ab. Es ist kein Backup und kein RAID eingerichtet. Eintrittswahrscheinlichkeit 10%. Schadenshöhe: 20.000€. Risikowert = 2.000€.
Danach werden aus der Risikoanalyse Maßnahmen abgeleitet. Maßnahmen, die kostengünstiger sind, als deren Risikowert, werden durchgeführt.
Beispiel: Einrichtung einer Sicherung und eines RAID. Maßnahme kostet vielleicht 500€ (für den Kunden). 2.000€ – 500€ = 1500€. Diese Maßnahme sollte durchgeführt werden.
Und dann ist alles paletti 😉
Hi Nils,
Ein guter Artikel.
@Patrick: Danke für die sinnvollen Ergänzungen. Werde ich nachher mal direkt anwenden.
Mike
Hi Nils
Super Artikel!
Neben der Risikobewertung ist es auch sehr wichtig, wann die Risiken angegangen werden.
Grundsätzlich sollte gelten: Je grösser das Risiko und je wichtiger die Anforderung, desto früher sollte das Risiko abgeklärt/behoben werden. Häufig passiert genau das Gegenteil. Man fängt mit den einfachen Dingen an.
Nur zum empfehlen:
„Bärentango – Mit Risikomanagment Projekte zum Erfolg führen“
http://www.amazon.de/B%C3%A4rentango-Risikomanagement-Projekte-Erfolg-f%C3%BChren/dp/3446223339/ref=sr_1_7?ie=UTF8&qid=1301911895&sr=8-7
Habs gerade vor einem Monat gelesen und ist echt ein super Buch, dass das Thema einfach erklärt.
Die Rechnung des Risikowerts mittels Eintrittswahrscheinlichkeit in Prozent und Schadenshöhe in Euro ist zwar die Lehrbuchvariante aber meiner Meinung nach nicht immer das Mittel der Wahl da es einem eine trückerische Sicherheit gibt… nicht jedes Risiko lässt sich für den Eintrittsfall eindeutig beziffern. Genauso lässt sich die Eintrittswahrscheinlichkeit selten so genau (0-100) bestimmen. Man hat am Ende zwar eine Summe für Risikokapital da stehen aber inwiefern das aussagekräftig ist sei mal dahingestellt und wenn man dann darauf festgenagelt wird ist ja auch suboptimal.
Ich persönlich bevorzuge folgende schlankere Variante:
Eintrittswahrscheinlichkeit:
* A: Sehr unwahrscheinlich
* B: Kann durchaus passieren
* C: Tritt wahrscheinlich ein
Schaden:
* A: Kann im Projektrahmen (Zeit,Budget,Leistung,Qualität) behandelt werden
* B: Braucht Entscheidung des Lenkungsausschuss (Geschäftsführung, usw)
* C: Das Projekt kann so nicht weitergeführt werden
Dadurch sind die Prioritäten dann auch gut sichtbar… ein CC Risiko sollte man z.B. auf jeden Fall vermeiden, ein AA Risiko kann man dagegen schonmal eher unter den Tisch fallen lassen.
Grafisch kann man das dann schön in einer Matrix darstellen.
Hier noch der Link zu der versprochenen Präsentation: http://www.phphatesme.com/blog/projektwerk/it-risikomanagement/
„alles was ich hier schreibe sollte aber trotzdem Sinn machen“
Diese Aussage wäre Punkt 1 auf der Agenda meines Risikomanagements!
Guter Artikel! Allerdings finde ich gerade in den Folien den Risikobegriff doch etwas überstrapaziert. So kann dann nahezu jedes eintretende Ereignis im Projekt als Risiko gelten, etwa wird Mitarbeitermotivation aufgeführt. Okay – aber wo besteht dann der Unterschied zu klassischem Projektmanagement, das etwa diesen Faktor im Auge behalten muss? Hier sehe ich doch eine inhaltliche Unschärfe. Im schlechtesten Fall würde man Risikomanagement als Parallelstruktur bzw in Konkurrenz zu klassischem PM einführen. Oder stellt es einen alternative Weg zur Bearbeitung von Projekten dar und hilft diese effektiver durchzuführen?
@Shop Freelancer: Risikomanagement ist ein Bestandteil des Projektmanagements. Da es kein Projekt ohne Risiken gibt, ist das auch ganz logisch. Schon die Definition des Projekt-Begriffs macht das deutlich (einfach mal bei WikiPedia oder im PM-Handbuch deines Vertrauens nachschlagen).
Da stimme ich voll zu. Das Thema Risikomanagement hat in vielen Unternehmen noch lücken, besonders in der IT.
Doch das bessert sich immer mehr. Das Bewusstsein für IT-Gefahren in Unternehmen hat in den letzten Jahren stark zugenommen. In erster Linie liegt das daran, dass private und berufliche Elemente sich zunehmend vermischen – an vielen Stellen ist das gewollt, aber das schafft natürlich auch erhebliche Risiken. [Quelle: http://www.finance-magazin.de/risiko-it/risikomanagement/gutes-it-risikomanagement-ist-eine-herkulesaufgabe/ ]
Die Spitze des Unternehmens muss hier den Ton angeben. Risikomanagement muss in die Unternehmenskultur einfließen und von jedem Mitarbeiter gelebt werden.
Gruß,
W.