Definition: Risikoidentifikation ist der Prozess der Bestimmung von Risiken, die das Programm, das Unternehmen oder die Investition möglicherweise daran hindern könnten, seine Ziele zu erreichen. Es beinhaltet die Dokumentation und Kommunikation des Anliegens.
Schlüsselwörter: Risiko, Risikoidentifikation, Risikomanagement
MITRE SE-Rollen & Erwartungen: Von MITRE-Systemingenieuren (SEs), die an Regierungsprogrammen arbeiten, wird erwartet, dass sie Risiken identifizieren, die sich auf das Projekt und das Programm auswirken könnten. Von ihnen wird erwartet, dass sie Risikoerklärungen verfassen und überprüfen, die klar und eindeutig sind und durch Beweise gestützt werden .
Hintergrund
Die Risikoidentifikation ist der entscheidende erste Schritt des in Abbildung 1 dargestellten Risikomanagementprozesses.
Das Ziel der Risikoidentifikation ist die frühzeitige und kontinuierliche Identifizierung von Ereignissen, die, wenn sie eintreten, negative Auswirkungen auf die Fähigkeit des Projekts haben, Leistungs- oder Fähigkeitsergebnisziele zu erreichen. Sie können aus dem Projekt oder aus externen Quellen stammen.
Es gibt verschiedene Arten von Risikobewertungen, einschließlich Programmrisikobewertungen, Risikobewertungen zur Unterstützung einer Investitionsentscheidung, Analyse von Alternativen und Bewertungen der Betriebs- oder Kostenunsicherheit. Die Risikoidentifikation muss der Art der Bewertung entsprechen, die zur Unterstützung einer risikoinformierten Entscheidungsfindung erforderlich ist. Bei einem Akquisitionsprogramm besteht der erste Schritt darin, die Programmziele zu identifizieren und so ein gemeinsames Verständnis darüber zu fördern, was für den Programmerfolg erforderlich ist. Dies gibt einen Kontext und begrenzt den Umfang, in dem Risiken identifiziert und bewertet werden.
Risiken identifizieren im Programm Systems Engineering
Es gibt mehrere Risikoquellen. Zur Risikoidentifikation sollte das Projektteam den Programmumfang, die Kostenschätzungen, den Zeitplan (einschließlich der Bewertung des kritischen Pfades), den technischen Reifegrad, die wichtigsten Leistungsparameter, die Leistungsherausforderungen, die Erwartungen der Stakeholder im Vergleich zum aktuellen Plan, externe und interne Abhängigkeiten, Implementierungsherausforderungen, Integration, Interoperabilität, Unterstützbarkeit, Schwachstellen in der Lieferkette, die Fähigkeit, Bedrohungen zu bewältigen, Kostenabweichungen, Erwartungen an Testereignisse, Sicherheit und mehr überprüfen. Darüber hinaus liefern historische Daten aus ähnlichen Projekten, Stakeholder-Interviews und Risikolisten wertvolle Einblicke in Bereiche, in denen Risiken berücksichtigt werden müssen.
Risikoidentifikation ist ein iterativer Prozess. Im weiteren Verlauf des Programms werden weitere Informationen über das Programm gewonnen (z. B. spezifisches Design), und die Risikoaussage wird angepasst, um das aktuelle Verständnis widerzuspiegeln. Neue Risiken werden im Laufe des Projektlebenszyklus identifiziert.
Best Practices und Lessons Learned
Operationelles Risiko. Verstehen Sie den Betriebscharakter der von Ihnen unterstützten Funktionen und das Risiko für die Endbenutzer, ihre Missionen und ihren Betrieb der Funktionen. Das Verständnis der betrieblichen Notwendigkeit / Mission (siehe das Thema Konzeptentwicklung des Systems Engineering Guide) wird Ihnen helfen, die Schwere der Risiken und die Auswirkungen, die sie auf die Endbenutzer haben könnten, zu erkennen. Dies ist ein kritischer Teil der Risikoanalyse – die Realisierung der realen Auswirkungen, die auftreten können, wenn ein Risiko während des betrieblichen Einsatzes entsteht. In der Regel sind operative Benutzer bereit, ein gewisses Risiko einzugehen, wenn sie ihre Mission erfüllen können (z. B. Mission Assurance), aber Sie müssen den Benutzern helfen, die von ihnen akzeptierten Risiken zu verstehen und die verfügbaren Optionen, Salden und Alternativen zu bewerten.
Technische Reife. Arbeiten Sie mit der Industrie und der Wissenschaft zusammen und nutzen Sie sie, um die für eine Anstrengung in Betracht gezogenen Technologien und den wahrscheinlichen Übergang der Technologie im Laufe der Zeit zu verstehen. Ein Ansatz besteht darin, mit Anbietern im Rahmen einer Geheimhaltungsvereinbarung zusammenzuarbeiten, um die Fähigkeiten zu verstehen und zu verstehen, wohin sie gehen, damit das Risiko bewertet werden kann.
Nichtentwicklungsgegenstände (NDI). NDI umfasst handelsübliche und regierungsübliche Artikel. Berücksichtigen Sie zum Risikomanagement die Rentabilität des NDI-Anbieters. Hat der Anbieter Marktanteile? Hat der Anbieter eine angemessene Langlebigkeit im Vergleich zu seinen Wettbewerbern? Wie geht der Anbieter mit Fähigkeitsproblemen um und veröffentlicht Korrekturen usw.? Was ist die Benutzerbasis für den jeweiligen NDI? Kann der Anbieter den NDI demonstrieren, vorzugsweise in einem ähnlichen Umfeld wie Ihr Kunde? Kann die Regierung die NDI verwenden, um einen Prototyp zu erstellen? All diese Faktoren werden dazu beitragen, das Risiko der Rentabilität des NDI und des Anbieters zu bewerten. Suchen Sie Antworten auf diese Fragen von anderen MITRE-Mitarbeitern, die in dem Gebiet gearbeitet oder den zu bewertenden NDI verwendet haben.
Akquisitionstreiber. Betonen Sie kritische Fähigkeitserweiterungen, insbesondere solche, die nur über begrenzte Alternativen verfügen. Bewerten und bestimmen Sie die Haupttreiber einer Akquisition und betonen Sie das damit verbundene Risiko bei der Formulierung von Empfehlungen zur Risikominderung. Wenn ein bestimmter Aspekt einer Fähigkeit für ihren Erfolg nicht entscheidend ist, sollte ihr Risiko bewertet werden, aber es muss nicht der Hauptfokus des Risikomanagements sein. Wenn beispielsweise ein Risiko für eine vorgeschlagene Benutzeroberfläche besteht, der Markt jedoch über zahlreiche Alternativen verfügt, ist der Erfolg des vorgeschlagenen Ansatzes für den Gesamterfolg der Fähigkeit wahrscheinlich weniger entscheidend. Andererseits ist ein Informationssicherheitsmerkmal wahrscheinlich kritisch. Wenn nur ein alternativer Ansatz den Bedarf befriedigt, sollte er betont werden. Bestimmen Sie die primären Erfolgstreiber, indem Sie Bedürfnisse und Designs bewerten und die vorhandenen Alternativen ermitteln. Ist eine einzigartige Lösung auf dem kritischen Weg zum Erfolg? Stellen Sie sicher, dass kritische Pfadanalysen den gesamten Systementwicklungszyklus und nicht nur die Entwicklung umfassen (dh die Systementwicklung an sich kann ein „Kinderspiel“ sein, aber der Einsatz in einer aktiven Betriebssituation kann ein großes Risiko darstellen).
Nutzen Sie Capability Evolution, um Risiken zu managen. Wenn bestimmte Anforderungen die Implementierung von Funktionen vorantreiben, die aufgrund der einzigartigen Entwicklung, der Leistungsanforderungen am Rand des Umschlags usw. ein hohes Risiko darstellen., die Anforderungen sollten mit den Benutzern für ihre Kritikalität besprochen werden. Es kann sein, dass die Notwendigkeit verschoben werden könnte, und die Entwicklungsgemeinschaft sollte beurteilen, wann sie in Zukunft befriedigt werden könnte. Helfen Sie Benutzern und Entwicklern abzuschätzen, wie viel Risiko (und Zeit- und Kostenauswirkungen) eine bestimmte Funktion im Vergleich zu den Anforderungen eingehen sollte, um weniger riskante Funktionen früher zu erhalten. Berücksichtigen Sie bei der Entwicklung Ihrer Empfehlungen die technische Machbarkeit und das Wissen über die damit verbundenen Implementierungserfolge und -misserfolge, um das Risiko einer Implementierung jetzt anstelle der Zukunft zu bewerten. Achten Sie beim Aufschieben von Fähigkeiten darauf, nicht in die Falle zu tappen, das endgültige Scheitern zu verschieben, indem Sie kurzfristige, einfache Erfolge für eine Zukunft mit mehreren Anforderungen mit hohem Risiko handeln, die für den Gesamterfolg von wesentlicher Bedeutung sein können.
Wichtige Leistungsparameter (KPPs). Arbeiten Sie eng mit den Benutzern zusammen, um KPPs einzurichten. Das Gesamtrisiko einer Programmabsage kann sich auf die Nichteinhaltung der KPPs konzentrieren. Arbeiten Sie mit den Benutzern zusammen, um sicherzustellen, dass die Parameter den Anforderungen der Mission entsprechen und technisch machbar sind. Die Parameter sollten nicht so nachsichtig sein, dass sie leicht erfüllt werden können, aber nicht die Missionsbedürfnisse erfüllen; Sie sollten auch nicht so streng sein, dass sie nicht ohne umfangreiche Anstrengungen oder technologische Fortschritte erreicht werden können beides kann ein Programm gefährden. Suchen Sie nach Ergebnissen vergangener Vorgänge, Experimente, Leistungsbewertungen und Industrieimplementierungen, um die Durchführbarkeit der Leistung zu ermitteln.
Externe und interne Abhängigkeiten. Eine Unternehmensperspektive kann Acquirern, Programmmanagern, Entwicklern, Integratoren und Benutzern helfen, das Risiko von Abhängigkeiten eines Entwicklungsaufwands zu schätzen. Mit dem Aufkommen serviceorientierter Ansätze wird ein Programm stärker von der Verfügbarkeit und dem Betrieb von Diensten abhängig, die von anderen bereitgestellt werden und die sie für die Entwicklungsbemühungen ihres Programms verwenden möchten. Arbeiten Sie mit den Entwicklern von Diensten zusammen, um sicherzustellen, dass qualitativ hochwertige Dienste erstellt werden, und es wurde über die Wartung und Weiterentwicklung dieser Dienste nachgedacht. Arbeiten Sie mit den Mitarbeitern des Entwicklungsprogramms zusammen, um die verfügbaren Dienste, ihre Qualität und das Risiko zu bewerten, das ein Programm bei der Nutzung und dem Verlassen auf den Dienst hat. Ebenso besteht ein Risiko im Zusammenhang mit der Erstellung des Dienstes und der Nichtbenutzung von Diensten eines anderen Unternehmens. Ermitteln Sie die Risiken und potenziellen Vorteile der Erstellung eines entwicklungsinternen Dienstes mit möglicherweise einem Übergang zum Unternehmensdienst zu einem späteren Zeitpunkt.
Integration und Interoperabilität (I&I). Ich&Ich werde fast immer ein Hauptrisikofaktor sein. Sie sind Formen von Abhängigkeiten, in denen der Wert der Integration oder Interoperabilität beurteilt wurde, um ihre inhärenten Risiken außer Kraft zu setzen. Techniken wie Enterprise Federation Architecting, Composable Capabilities on Demand und Design Patterns können der Regierung helfen, eine Route zur Navigation in I& I-Risiken zu planen und auszuführen. Im Abschnitt Enterprise Engineering des Systems Engineering Guide finden Sie Artikel zu Techniken zur Bewältigung von I&I-assoziierten Risiken.
Informationssicherheit. Informationssicherheit ist in fast jeder Entwicklung ein Risiko. Ein Teil davon ist auf die Einzigartigkeit der staatlichen Bedürfnisse und Anforderungen in diesem Bereich zurückzuführen. Ein Teil davon ist auf die inhärenten Schwierigkeiten bei der Bekämpfung von Cyberangriffen zurückzuführen. Die Schaffung von Verteidigungsfähigkeiten, um das Spektrum der Angriffe abzudecken, ist herausfordernd und riskant. Unterstützung der Regierung bei der Entwicklung von Resilienzansätzen (z. B. Notfallpläne, Backup / Recovery usw.). Die Ermöglichung des systemübergreifenden Informationsaustauschs in Koalitionsoperationen mit internationalen Partnern stellt technische Herausforderungen und politische Fragen dar, die sich in Entwicklungsrisiken niederschlagen. Die mit dem Supply Chain Management verbundenen Fragen der Informationssicherheit sind so breit und komplex, dass selbst die Aufrechterhaltung eines rudimentären Bewusstseins für die Bedrohungen eine enorme Herausforderung darstellt.
Schwierigkeitsgrad. Das Qualifikations- oder Erfahrungsniveau der Entwickler, Integratoren, Behörden und anderer Interessengruppen kann zu Risiken führen. Halten Sie Ausschau nach unzureichenden Fähigkeiten und erreichen Sie das gesamte Unternehmen, um Lücken zu schließen. Helfen Sie dabei, die Mitglieder des Regierungsteams zu schulen, und bringen Sie gleichzeitig unternehmerische Fähigkeiten und Erfahrungen ein.
Kostenrisiken. Programme erstellen in der Regel eine Kostenschätzung der Regierung, die das Risiko berücksichtigt. Während Sie die technischen und sonstigen Risiken des Programms entwickeln und verfeinern, sollten sich auch die damit verbundenen Kostenschätzungen weiterentwickeln. Die Kostenschätzung ist keine einmalige Aktivität.
Historische Informationen als Leitfaden zur Risikoidentifikation. Historische Informationen aus ähnlichen Regierungsprogrammen können wertvolle Einblicke in zukünftige Risiken geben. Informieren Sie sich über betriebliche Herausforderungen und Risiken in verschiedenen Betriebslektionen, einschließlich Aktionsberichten, Übungszusammenfassungen und Versuchsergebnissen. Kunden haben häufig Repositorys, auf die sie zugreifen können. Die Regierungschefs werden in der Regel ihre strategischen Bedürfnisse und Herausforderungen kommunizieren. Verstehen und berücksichtigen Sie diese in Ihrer Bewertung der wichtigsten Fähigkeiten, die Ihr Kunde benötigt, und als Grundlage für Risikobewertungen.
Historische Daten zur Risikobewertung sind häufig aus früheren Leistungsbewertungen und Erfahrungen von Akquisitionsprogrammen und Auftragnehmern verfügbar. In vielen Fällen unterstützen MITRE-Mitarbeiter die Regierung bei der Erstellung von Leistungsinformationen für eine bestimmte Akquisition. Der AF verfügt über einen Past Performance Evaluation Guide (PPEG), der die Art der zu erfassenden Informationen identifiziert, die für die zukünftige Auswahl von Regierungsquellen verwendet werden können . Dieser Informationsspeicher kann helfen, Hintergrundinformationen zu früheren Herausforderungen zu liefern und wo sie möglicherweise wieder auftreten sowohl für die jeweilige Art der Entwicklungstätigkeit als auch für die jeweiligen Auftragnehmer.
Es gibt zahlreiche technische Bewertungen für Herstellerprodukte, auf die zugegriffen werden kann, um das Risiko und die Lebensfähigkeit verschiedener Produkte zu bestimmen. Ein MITRE-Repository für Evaluierungen von Tools ist das Analysis Toolshed, das Anleitungen und Erfahrungen mit Analysetools enthält. Wenn Sie Ressourcen wie diese verwenden und andere suchen, die Produkte und Techniken in Prototypen und Experimenten ausprobiert haben, können Sie die Risiken für eine bestimmte Anstrengung besser einschätzen.
Wie man ein Risiko schreibt – eine Best Practice . Ein Best-Practice-Protokoll zum Schreiben einer Risikoerklärung ist das Condition-If-Then-Konstrukt. Dieses Protokoll gilt für Risikomanagementprozesse, die für nahezu jede Umgebung entwickelt wurden. Es ist eine Anerkennung, dass ein Risiko seiner Natur nach probabilistisch ist und, wenn es auftritt, unerwünschte Konsequenzen hat.
Was ist das Condition-If-Then Konstrukt? Der Zustand spiegelt das wider, was heute bekannt ist. Es ist die Ursache des identifizierten Risikoereignisses. Somit ist die Bedingung ein Ereignis, das aufgetreten ist, gegenwärtig auftritt oder mit Sicherheit auftreten wird. Risikoereignisse sind zukünftige Ereignisse, die aufgrund des vorliegenden Zustands auftreten können. Unten ist eine Illustration dieses Protokolls.
Das If ist das Risikoereignis, das mit der vorliegenden Bedingung verbunden ist. Es ist von entscheidender Bedeutung, die If und die Bedingung als Dual zu erkennen. Bei gemeinsamer Prüfung kann es Möglichkeiten geben, direkt einzugreifen oder die zugrunde liegende Ursache (Bedingung) des Risikoereignisses so zu beheben, dass die Folgen dieses Ereignisses, falls es auftritt, das Projekt nicht mehr bedrohen. Das If ist der probabilistische Teil der Risikoaussage.
Das Dann ist die Konsequenz oder der Satz von Konsequenzen, die sich auf das Engineering-Systemprojekt auswirken, wenn das Risikoereignis eintritt. Ein Beispiel für ein Condition-If-Then-Konstrukt ist in Abbildung 2 dargestellt.
Ermutigt Teams, Risiken zu identifizieren. Die Kultur in einigen Regierungsprojekten und -programmen schreckt von der Identifizierung von Risiken ab. Dies kann darauf zurückzuführen sein, dass die Risikomanagementaktivitäten zur Verfolgung, Überwachung und Minderung der Risiken als belastend und wenig hilfreich angesehen werden. In dieser Situation kann es nützlich sein, mit den Teams über die Vorteile der Identifizierung von Risiken und die Unfähigkeit zu sprechen, alles in Ihren Köpfen zu verwalten (z., Priorität festlegen, wer einbezogen werden muss, Minderungsmaßnahmen). Unterstützung der Regierungsteams bei der Durchführung eines Prozesses, der die Managementinvestitionen mit dem Wert der Projektergebnisse in Einklang bringt. Im Allgemeinen wird ein gutes Gleichgewicht erreicht, wenn der Projektumfang, der Zeitplan und die Kostenziele erreicht oder durch Aktionspläne erfolgreich gemildert werden und das Projektteam der Ansicht ist, dass Risikomanagementaktivitäten dem Projekt einen Mehrwert bieten. Teamübergreifende Repräsentation ist ein Muss; Risiken sollten nicht von einer Einzelperson oder ausschließlich vom Systems Engineering Team identifiziert werden (siehe oben Risikoquellen).
Berücksichtigen Sie organisatorische und Umweltfaktoren. Organisatorische, kulturelle, politische und andere Umweltfaktoren, wie z. B. die Unterstützung von Stakeholdern oder organisatorische Prioritäten, können für ein Projekt genauso viel oder mehr Risiken darstellen wie technische Faktoren allein. Diese Risiken sollten während der gesamten Projektlaufzeit identifiziert und aktiv gemindert werden. Minderungsaktivitäten können die Überwachung gesetzlicher Mandate oder Notfalländerungen umfassen, die sich auf das Programm oder die Projektmission auswirken könnten, organisatorische Änderungen, die sich auf die Benutzeranforderungen oder den Nutzen von Fähigkeiten auswirken könnten, oder Änderungen der politischen Unterstützung, die sich auf die Finanzierung auswirken könnten. Berücksichtigen Sie in jedem Fall das Risiko für das Programm und identifizieren Sie Handlungsoptionen für die Diskussion mit den Stakeholdern. Weitere Informationen finden Sie im Artikel Risikominderungsplanung, Implementierung und Fortschrittsüberwachung.
Stakeholder in die Risikoidentifikation einbeziehen. Projekte und Programme haben in der Regel mehrere Stakeholder, die verschiedene Dimensionen des Risikos für die Ergebnisse mit sich bringen. Dazu gehören Betreiber, die mit neuen Systemen überfordert sein könnten; Benutzer, die möglicherweise nicht ausreichend geschult sind oder Angst um ihre Arbeitsplätze haben; Vorgesetzte, die eine neue Fähigkeit möglicherweise nicht unterstützen, weil sie ihre Autorität zu verringern scheint; und politische Entscheidungsträger, die sich mit der Genehmigung und den Kosten durch die Gesetzgebung befassen. Darüber hinaus ist es wichtig, alle Beteiligten wie Zertifizierungs- und Akkreditierungsbehörden einzubeziehen, die, wenn sie versehentlich übersehen werden, später im Programm große Risiken darstellen können. Stakeholder können sich verschiedener Umweltfaktoren bewusst sein, z. B. ausstehender Gesetzgebung oder politischer Programmunterstützung, die Risiken für ein Projekt darstellen können, die der Regierung oder dem MITRE-Projektteam unbekannt sind. Beziehen Sie die Stakeholder in den Risikoidentifikationsprozess ein, um diese Risiken aufzudecken.
Schreiben Sie klare Risikoaussagen. Die Verwendung des Condition-If-Then-Formats hilft bei der Kommunikation und Bewertung einer Risikoaussage und der Entwicklung einer Minderungsstrategie. Die Hauptursache ist die zugrunde liegende Bedingung, die das Risiko eingeführt hat (z. B. könnte ein Entwurfsansatz die Ursache sein), die If spiegelt die Wahrscheinlichkeit wider (z. B. Wahrscheinlichkeitsbewertung, dass der If-Teil der Risikoaussage eintreten sollte), und die Then kommuniziert die Auswirkungen auf das Programm (z. B. erhöhte Ressourcen zur Unterstützung von Tests, zusätzlicher Zeitplan und Bedenken hinsichtlich der Einhaltung der Leistung). Die Minderungsstrategie ist fast immer besser, wenn sie auf einer klar formulierten Risikoaussage basiert.
Erwarten Sie Änderungen der Risikoaussage, wenn die Risikobewertungs- und Minderungsstrategie entwickelt wird. Es ist üblich, Risikoaussagen verfeinern zu lassen, sobald das Team die Auswirkungen bewertet. Bei der Bewertung und Dokumentation der potenziellen Risikoauswirkungen (Kosten, Zeitplan, Technik oder Zeitrahmen) können sich das Verständnis und die Darstellung des Risikos ändern. Bei der Bewertung der Risikoauswirkungen von Software-Terminplanungsfehlern kann die Risikoaussage beispielsweise dahingehend verfeinert werden, dass sie das Mindesthaltbarkeitsdatum und / oder eine weitere Klärung der Auswirkungen enthält (z. B. wenn die xyz-Software nicht bis März 2015 geliefert wird, bleibt nicht genügend Zeit, um den Schnittstellenaustausch vor dem eingeschränkten Benutzertest zu testen).
Nehmen Sie die Minderungserklärung nicht in die Risikoerklärung auf. Achten Sie darauf, nicht in die Falle zu tappen, dass die Minderungserklärung in die Risikoerklärung aufgenommen wird. Ein Risiko ist eine Unsicherheit mit potenziellen negativen Auswirkungen. Einige kommen schnell zu dem Schluss, dass das Risiko gemindert werden sollte, und anstatt das Risiko zu identifizieren, das gemindert werden sollte (mit identifizierten Minderungsoptionen), identifizieren sie das Risiko als suboptimalen Entwurfsansatz. Eine Risikoaussage könnte beispielsweise lauten: Wenn der Auftragnehmer XYZ nicht für den Test verwendet, schlägt der Test fehl. Die Sorge ist wirklich Test Suffizienz. Wenn der Auftragnehmer den Test nicht mit messbaren Ergebnissen zur Analyse durchführt, besteht das Programm möglicherweise keinen eingeschränkten Benutzertest. Die Verwendung von XYZ kann eine Minderungsoption sein, um das Testsuffizienzrisiko zu verringern.
Springen Sie nicht zu einer Minderungsstrategie, bevor Sie die Risikowahrscheinlichkeit und -auswirkungen bewertet haben. Ein Risiko kann bei weiterer Analyse verfeinert oder geändert werden, was sich auf die effizienteste / gewünschte Minderung auswirken kann. Ingenieure springen oft zur Lösung; Es ist am besten, mit dem nächsten Schritt fortzufahren, der im Artikel Risikofolgenabschätzung und Priorisierung beschrieben wird, um das Problem zuerst zu zerlegen und zu verstehen. Letztendlich wird dies zu einer Strategie führen, die eng mit dem Konzern abgestimmt ist.
Referenzen & Ressourcen
- Das MITRE Institute, 1. September 2007, MITRE Systems Engineering (SE) Kompetenzmodell, Version 1, S. 10, 40-41.
- Garvey, PR, 2008, Analytische Methoden für das Risikomanagement: Eine systemtechnische Perspektive, Chapman-Hall / CRC-Press, Taylor & Francis Group (UK), Boca Raton, London, New York, ISBN: 1584886374.U.S. Air Force, Januar 2008, Air Force Past Performance Evaluation Guide (PPEG), IG5315.305(ein).
- U.S. Air Force, Januar 2008, Air Force Past Performance Evaluation Guide (PPEG), IG5315.305(ein).
Zusätzliche Referenzen & Ressourcen
MITRE E520 Risikoanalyse und Management Checklisten des technischen Teams, Risikoprüfungen, Risikoanalyse- und Managementdokumente.
Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK-Leitfaden), Vierte Ausgabe, ANSI / PMI 99-001-2008, S. 273-312, Zugriff am 2. März 2010.
SEPO, „Standardprozess / Prozessschritte, Schritt 2: Risiken identifizieren & Gefahren“, MITRE SEPO Risk Management Toolkit, Zugriff am 5. Mai 2010.
