Was gilt als verfolgbares Risiko?

Was gilt bei der Erstellung eines Risikoanalysedokuments als angemessenes Risiko? Als Faustregel erwarten wir, dass 5 Risiken verfolgt werden. Ist es sinnvoll, Risiken einzubeziehen, wie z. B. dass das Gebäude abbrennt oder ein großer Sturm den Strom für 6 Wochen ausfällt ? Während die Wahrscheinlichkeit dieser Ereignisse gering ist, ist ihr Schweregrad extrem hoch, was sie wie Kandidaten für das Risikoprotokoll erscheinen lässt.

Wäre es nicht sinnvoller zu erwarten, dass der PM projektspezifische Risiken aufzeigt, im Gegensatz zu unternehmens- oder landesweiten Risiken? Hat jemand eine gute Faustregel, um zu entscheiden, was ein angemessenes Risiko ist, das aufgenommen und verfolgt werden sollte?

„Angemessenes Risiko“ klingt sehr nach „akzeptablem Risiko“ und nicht so, wie ich annehme, was Ihre beabsichtigte Bedeutung von „ein Risiko ist, das es wert ist, verfolgt zu werden“. Ich habe Ihre Frage leicht bearbeitet, um das klarer zu machen, wollte aber nicht zu weit von Ihrer ursprünglichen Absicht abweichen. Bitte bearbeiten Sie gegebenenfalls weiter, um die Unterscheidung vorzunehmen.
Danke, @CodeGnome - Ihre Bearbeitung macht die Frage klarer und wird geschätzt.

Antworten (3)

F: Was gilt als verfolgbares Risiko? A: Alles , was irgendjemand für ein Risiko für die Projektziele hält (normalerweise Zeit, Kosten, Umfang und Qualität)

Als Projektmanager bemühe ich mich sehr, jeden und jeden , der an dem Projekt interessiert ist, davon zu überzeugen, alle Risiken einzugehen, die sie für angebracht halten. Gleichzeitig fördere ich eine Kultur der Risikobereitschaft und insbesondere, dass niemand ein von irgendjemandem geäußertes Risiko beurteilen oder kleinreden sollte . Wenn jemand ein Problem vorhersehen kann, möchte ich davon wissen. Vielleicht untersuchen wir das Risiko, stellen fest, dass es nicht relevant ist, und schließen es ziemlich schnell... Oder vielleicht stellen wir fest, dass jemand gerade das schwerwiegendste Risiko für mein Projekt aufgedeckt hat - Beurteilen Sie niemals vorab!

Eine "Faustregel" darüber zu haben, wie viele Risiken gemanagt werden sollten, ist meiner Meinung nach sinnlos. Wenn es keine Risiken gibt, verschwenden Sie nur Zeit damit, einen PM dazu zu zwingen, Risiken zu konstruieren, nur um das Risikomanagement-Kästchen anzukreuzen, was wiederum aktives Risikomanagement für alle Beteiligten entwertet. Und das Festlegen einer fiktiven Grenze bedeutet, dass die Menschen aufhören, nach Risiken zu suchen, wenn sie „genug“ Risiken in den Büchern haben. Das Risikoprotokoll sollte alle Risiken enthalten, die jeder wahrnimmt, und wenn das Risikoprofil des Projekts so ist, dass es 20 offene Risiken gibt, dann sei es so. Gleichermaßen, wenn es nur ein offenes Risiko gegen ein Projekt gibt, aber Beweise für einen soliden Risikomanagementprozess, dann wieder, so sei es!

Was also tun mit Risiken auf Unternehmensebene? Das ist meine eigene Philosophie:

  • Wenn ein identifizierbares Risiko besteht, ich aber nichts tun kann, um das Risiko für das Projekt zu mindern, dann protokolliere ich es und vergesse es. Wenn es buchstäblich nichts gibt, was Sie dagegen tun können, stellen Sie sicher, dass Sie Ihrem Projektausschuss mitteilen, dass es existiert, aber verschwenden Sie keine Zeit damit, etwas dagegen zu tun. Der Projektausschuss kann feststellen, dass etwas dagegen getan werden kann, und er wird es Ihnen bald mitteilen

  • Wenn es sich um ein echtes Risiko auf Unternehmensebene handelt, aber zu einer Risikoklasse gehört, die allen Projekten in allen Unternehmen gemeinsam ist (dh das Gebäude könnte abbrennen), dann verwenden Sie Ihr Urteilsvermögen. Jeder weiß, dass alle Gebäude abbrennen können, und jeder weiß, dass in diesem Fall alle Projekte auf Eis liegen. Das Unternehmen sollte diese Arten von Risiken mithilfe von Disaster Recovery auf Unternehmensebene mindern. Die erneute Angabe solcher Risiken in einem Projektrisikoprotokoll, insbesondere um es aufzufüllen, lässt den PM ein wenig dumm dastehen. ABER, wenn das Projekt geschäftskritisch ist und Sie feststellen, dass die Notfallwiederherstellung die Situation nicht bewältigen kann, besteht ein echtes Risiko, dass Sie benachrichtigt werden müssen. Wahrscheinlich wird niemand in der Lage sein, es zu mindern, wenn es sich um ein großes Risiko handelt, aber Sie müssen zeigen, dass Sie darüber nachgedacht haben und alle Mitglieder des Projektausschusses das Risiko verstehen.

  • Tragen Sie keine sensiblen Risiken in das offene Risikoprotokoll ein. Sie könnten das Gefühl haben, dass das Risiko besteht, dass eine Schlüsselperson kurz vor dem Ausscheiden steht, mit katastrophalen Folgen für Ihr Projekt. Sie müssen solche Dinge direkt und persönlich mit wichtigen Mitgliedern der Lenkungsgruppe ansprechen – niemand wird Ihnen dafür danken, dass Sie es zu einem offiziellen offenen Risiko im Protokoll gemacht haben (was etwas kontraintuitiv ist, aber dort, wo sich Politik mit Risikomanagement überschneidet).

  • Scheuen Sie sich nicht, Risiken zu schließen , wenn Sie festgestellt haben, dass die Auswirkung, Wahrscheinlichkeit oder Folgen nicht mehr relevant sind. Es hat keinen Wert , ein Risikoprotokoll voller Dinge zu führen, die untersucht und als derzeit nicht relevant befunden wurden. Schließen Sie sie. So kann sich das gesamte Team auf das Wesentliche konzentrieren . Sie können Risiken jederzeit wieder eröffnen oder erneut erhöhen. Beteiligen Sie sich aktiv an Ihrer Überprüfung und Verwaltung des aktuellen, sich ständig ändernden Risikoprofils eines Projekts. Zuzulassen, dass das Risikoprofil veraltet, ist wohl gefährlicher, als überhaupt kein Risikoprotokoll zu haben

Gut zu beachten: sensible Risiken im offenen Risikoprotokoll

Modellbasierte Risikobewertungen

Hat jemand eine gute Faustregel, um zu entscheiden, was ein angemessenes Risiko ist, das aufgenommen und verfolgt werden sollte?

Ihre Risiken werden von Ihrem Bedrohungsmodell bestimmt. Der Filter, den Sie verwenden, um bedeutsame Risiken zu identifizieren, sollte Teil Ihres Projektplans sein und wird oft in Ihre Projektannahmen eingebaut. Beispielsweise kann es sinnvoll sein anzunehmen, dass ein Softwareprojekt keinem großen Risiko durch spontane menschliche Verbrennung ausgesetzt ist, sodass Sie diese Art von Risiko wahrscheinlich aus Ihrem Bedrohungsmodell herauslassen würden. Andererseits können Personalfluktuation, Terminrisiken oder Fragen des geistigen Eigentums für ein solches Projekt relevant sein.

Stakeholder und die Geschäftsleitung tragen das Risiko

Das wirklich Wichtige ist, dass Ihr Risikoprotokoll ein Projektartefakt ist, das alle Risiken enthalten sollte, über die die Organisation nachgedacht hat und die sich als relevant erwiesen haben. Das Risikoprotokoll sollte auch eindeutig angeben, ob diese Risiken akzeptiert, übertragen oder kontrolliert werden.

Es wird nicht erwartet, dass Sie für alle Eventualitäten planen; Die Rolle eines Projektmanagers besteht darin, die vom Projekt identifizierten Risiken zu erfassen, zu dokumentieren und an seine Stakeholder zu kommunizieren. Danach liegt die Verantwortung bei ihnen .

Als PjM wurde von mir immer erwartet, dem Risikodokument alternative Lösungen und/oder Problemumgehungen hinzuzufügen . Nicht nur, um sie festzuhalten, zu dokumentieren und zu kommunizieren . Ist das nicht SOP?
@DannySchoemann Projektmanager haben oft Verantwortung ohne Befugnisse. Wer finanziert diese alternativen Lösungen? Wer hat die Workarounds genehmigt? Sie sind es wahrscheinlich nicht, warum also die Verantwortung dafür übernehmen, es sei denn, die Befugnis wurde Ihnen als Teil des Projektauftrags übertragen? Tappen Sie nicht in die politische Falle, die Verantwortung von jemand anderem „zu übernehmen“, insbesondere von denen, die eigentlich der Geschäftsleitung oder den Interessenvertretern zufallen. Das Empfehlen von Alternativen oder das Vorschlagen von Kontrollen ist in Ordnung, aber das Risiko und die Verantwortung gehören immer noch woanders hin.
@CodeGnome +1 für deinen Kommentar. sehr weise Worte. Wie immer.

Ich gehe davon aus, dass Sie mit "qualifizieren" in Ihrem Risikoprotokoll erfasst meinen. Obwohl es auf diese Weise verwendet wird, glaube ich nicht, dass das Protokoll jemals dazu gedacht war, das Universum der Risiken zu erfassen, die ein bestimmtes Projekt bedrohen. Ich denke, dass Sie sich auf fünf konzentrieren – obwohl ich keine Fünferregel haben würde – ist eine gute Möglichkeit, das Team auf das Wesentliche zu konzentrieren.

Die allgemeine Regel, die ich verwende, besteht darin, ein Risiko auf formelle Weise zu erfassen – Risikoprotokoll, dokumentierte Risikobewertungen, Minderungspläne usw. – für jene Bedrohungen, die 1) eine formelle Kommunikation/Eskalation an eine Interessengruppe erfordern; 2) formelle Genehmigungen für die Zuweisung von Ressourcen zur Minderung der Bedrohung(en) und/oder zur Bildung von Notfallreserven verlangen; 3) Die Bedrohung ist so groß, dass Sie den Fortschritt der Minderung überwachen müssen/möchten; oder 4) CYA, wenn Sie niemanden dazu bringen können, zuzuhören.

Organische Risiken, wie z. B. Wetter, würden eines dieser Kriterien typischerweise nicht erfüllen. Ich definiere organische Risiken als natürlich durch das Projekt oder durch die Natur erzeugt, jeder kennt sie von Natur aus, und Minderung ist oft ohnehin in die Projektpläne „eingebaut“. Ich habe jedoch von Zeit zu Zeit ein paar organische Risiken dokumentiert, weil etwas ziemlich Einzigartiges an der organischen Bedrohung ist. Zum Beispiel hatten wir bei einem Projekt über die Feiertage im Winter eine Menge Arbeit zu erledigen und die meisten Arbeiter reisten an. Es schien, dass alle optimistisch die Möglichkeit ignorierten, dass wetterbedingt keine Reisen möglich sind, und die Tatsache, dass die meisten Leute es mögen in den Ferien Urlaub nehmen. Da alle auf dem glücklichen Weg waren, eskalierte ich dieses Risiko, weil es mein Kriterium Nr. 4 erfüllte.

Ich mag deine 4 Kriterien.