Angenommen, es besteht ein IT-Betriebsrisiko wie das Fehlen von Backups während der Bereitstellung einer Lösung, würde dies als Projektrisiko betrachtet, und wenn ja, wie würden Sie die Risiken klassifizieren?
Kann dies den erfolgreichen Abschluss Ihres Projekts beeinflussen? wenn ja, ist es ein Risiko. Ich bin mir nicht sicher, ob die Aufteilung der Risiken in „Betrieblich“ und „Projekt“ mir dabei hilft, das Projekt erfolgreich abzuschließen. Ein Risiko ist jede Unbekannte, die den Zeitplan, die Kosten, die Qualität oder den Umfang meines Projekts beeinflussen könnte. Das Fehlen von Backups ist per se kein Risiko. Das Fehlen von Backups bedeutet, dass:
Angesichts der Tatsache, dass es keine Backups gibt, WENN ein Ereignis eintritt, das meine Daten beeinträchtigt oder zerstört, DANN könnte ich eine vorhersehbare Menge an Zeit/Aufwand/Ressourcen verlieren, um den Ausfall zu beheben. In einigen Fällen könnte dies zum vollständigen Scheitern meines Projekts führen. Die Wahrscheinlichkeit eines Ausfalls lässt sich leicht quantifizieren, der Zeitaufwand für die Behebung ist relativ einfach vorherzusagen. Die Kosten für Backups sind vorhersehbar und relativ gering. Daher besteht mein Minderungsplan darin, Backups zu erzwingen.
Angesichts der Tatsache, dass meine IT-Mitarbeiter einfache Best Practices im Backup ignorieren, DANN ist meine Fähigkeit, die Kontrolle über mein Projekt auszuüben, erheblich eingeschränkt, WENN sie andere Best Practices ignorieren. Minderungspläne sollten eine Analyse beinhalten, warum das IT-Personal Backups ignoriert und welche anderen Verfahren fehlerhaft sind und welche Auswirkungen dies haben könnte. Dies ist ein Beispiel für ein Risiko, bei dem die Risikoanalyse das Risiko erheblich reduziert.
Ich war noch nie ein Fan davon, Risiken zu klassifizieren. Risikomanagement ist kein Ziel, es ist ein Werkzeug, um das Projekt erfolgreich abzuschließen. Entfernen Sie alles, was nicht zum Abschluss des Projekts beiträgt.
Meiner Meinung nach ist die Art und Weise, darüber nachzudenken, dass die Risiken im Risikoprotokoll des Projekts sich auf Risiken für die Ziele des Projekts beziehen. Mit anderen Worten, Dinge, die passieren könnten, die Sie daran hindern, das Projekt termin-, kosten- und qualitätsgerecht und insbesondere gemäß den Abnahmekriterien abzuliefern.
In Ihrem Fall (je nachdem, was Ihr Projekt eigentlich ist!) wären fehlende Betriebssicherheiten also kein Projektrisiko. Eigentlich ist „Mangel an Backups“ überhaupt kein Risiko, es ist eine Beschreibung einer Situation und sollte lauten „Wegen fehlender betrieblicher Backups besteht das Risiko, dass [einige Auswirkungen oder Folgen]“.
Abgesehen davon besteht ein Teil eines Softwarebereitstellungsprojekts normalerweise darin, den Post-Live-Support und die Betriebsübergabe sicherzustellen. Wenn das Fehlen von betrieblichen Backups diese Seite der Lieferung beeinträchtigen könnte, könnte dies ein Projektrisiko darstellen ...
Sowohl Marv als auch Mark haben großartige Antworten darauf, aber ich möchte etwas zur Klassifizierung von Risiken hinzufügen. Ich stimme Mark zu, dass Risikomanagement nicht das Ziel, sondern das Mittel zum Zweck ist, und dass es zwei wichtige Regeln sind, es einfach und geradlinig zu halten. Die Klassifizierung von Risiken und andere formellere Regeln zur Risikodokumentation helfen Ihrem aktuellen Projekt möglicherweise nicht, sind jedoch großartige Beiträge zu ZUKÜNFTIGEN Projekten und gewonnenen Erkenntnissen und werden vielleicht sogar selbst zu Projekten. Abhängig von der Größe und Komplexität Ihres aktuellen Projekts und der Pläne für zukünftige Projekte kann die Erstellung formalerer Risikomanagementrichtlinien, die mit Kosten verbunden sind, der Organisation auf lange Sicht gute Dienste leisten.
Ich würde dieses Risiko vielleicht als "operational", "process" oder "policy" klassifizieren.
Motiviert