28 Annex A normative Risk management policy document - DRD...30 Annex B normative Risk management plan - DRD...33 Annex C normative Risk assessment report - DRD ...36 Annex D informat
Trang 2Foreword
This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards. Requirements in this Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.
This Standard has been prepared by the ECSS‐M‐ST‐80 Working Group, reviewed by the ECSS Executive Secretariat and approved by the ECSS Technical Authority.
Disclaimer
ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error‐free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out
of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.
Published by: ESA Requirements and Standards Division
ESTEC, P.O Box 299,
2200 AG Noordwijk The Netherlands
Copyright: 2008 © by the European Space Agency for the members of ECSS
Trang 3• Update of descriptive text in clause 4.4, 5.1, 5.2.1.2f, 5.2.1.2h, 5.2.2.1, 6.5c,
• In clause 7, former text contained in “AIM” converted into notes and former text from “EXPECTED OUTPUT” deleted or converted into requirements when normative.
Trang 4Table of contents
Change log 3
Introduction 6
1 Scope 7
2 Normative references 8
3 Terms, definitions and abbreviated terms 9
3.1 Terms from other standards 9
3.2 Terms specific to the present standard 9
3.3 Abbreviated terms 10
4 Principles of risk management 11
4.1 Risk management concept 11
4.2 Risk management process 11
4.3 Risk management implementation in a project 11
4.4 Risk management documentation 12
5 The risk management process 13
5.1 Overview of the risk management process 13
5.2 Risk management steps and tasks 15
5.2.1 Step 1: Define risk management implementation requirements 15
5.2.2 Step 2: Identify and assess the risks 18
5.2.3 Step 3: Decide and act 19
5.2.4 Step 4: Monitor, communicate, and accept risks 20
6 Risk management implementation 22
6.1 General considerations 22
6.2 Responsibilities 22
6.3 Project life cycle considerations 23
6.4 Risk visibility and decision making 23
6.5 Documentation of risk management 23
Trang 57 Risk management requirements 25
7.1 General 25
7.2 Risk management process requirements 25
7.3 Risk management implementation requirements 28
Annex A (normative) Risk management policy document - DRD 30
Annex B (normative) Risk management plan - DRD 33
Annex C (normative) Risk assessment report - DRD 36
Annex D (informative) Risk register example and ranked risk log example 38
Annex E (informative) Contribution of ECSS Standards to the risk management process 41
Bibliography 43
Figures Figure 5-1: The steps and cycles in the risk management process 14
Figure 5-2: The tasks associated with the steps of the risk management process within the risk management cycle 14
Figure 5-3: Example of a severity–of–consequence scoring scheme 15
Figure 5-4: Example of a likelihood scoring scheme 16
Figure 5-5: Example of risk index and magnitude scheme 17
Figure 5-6: Example of risk magnitude designations and proposed actions for individual risks 17
Figure 5-7: Example of a risk trend 21
Trang 6
Introduction
Risks are a threat to project success because they have negative effects on the project cost, schedule and technical performance, but appropriate practices of controlling risks can also present new opportunities with positive impact. The objective of project risk management is to identify, assess, reduce, accept, and control space project risks in a systematic, proactive, comprehensive and cost effective manner, taking into account the project’s technical and programmatic constraints. Risk is considered tradable against the conventional known project resources within the management, programmatic (e.g. cost, schedule) and technical (e.g. mass, power, dependability, safety) domains. The overall risk management in a project is an iterative process throughout the project life cycle, with iterations being determined by the project progress through the different project phases, and by changes to a given project baseline influencing project resources.
Risk management is implemented at each level of the customer‐supplier network.
Known project practices for dealing with project risks, such as system and engineering analyses, analyses of safety, critical items, dependability, critical path, and cost, are an integral part of project risk management. Ranking of risks according to their criticality for project success, allowing management attention
to be directed to the essential issues, is a major objective of risk management. The project actors agree on the extent of the risk management to be implemented in a given project depending on the project definition and characterization.
Trang 71 Scope
This Standard defines the principles and requirements for integrated risk management on a space project; it explains what is needed to implement a project–integrated risk management policy by any project actor, at any level (i.e. customer, first level supplier, or lower level suppliers).
This Standard contains a summary of the general risk management process, which is subdivided into four (4) basic steps and nine (9) tasks.
The risk management process requires information exchange among all project domains, and provides visibility over risks, with a ranking according to their criticality for the project; these risks are monitored and controlled according to the rules defined for the domains to which they belong.
The fields of application of this Standard are all the activities of all the space project phases. A definition of project phasing is given in ECSS‐M‐ST‐10.
This standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS‐S‐ST‐00.
Trang 8
2 Normative references
The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revisions of any of these publications
do not apply. However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references the latest edition of the publication referred to applies.
ECSS‐ST‐00‐01 ECSS system ‐ Glossary of terms
ECSS‐M‐ST‐10 Space project management – Project planning and
implementation
Trang 93 Terms, definitions and abbreviated terms
3.1 Terms from other standards
For the purpose of this Standard, the terms and definitions from ECSS‐ST‐00‐01 apply, in particular for the following terms:
risk residual risk risk management risk management policy
3.2 Terms specific to the present standard
Trang 103.2.5 (risk) management process
consists of all the project activities related to the identification, assessment, reduction, acceptance, and feedback of risks
NOTE Preventive measures aim at eliminating the cause
of a problem situation, and mitigation measures aim at preventing the propagation of the cause to the consequence or reducing the severity of the consequence or the likelihood of the occurrence.
IEC International Electrotechnical Commission
Trang 114 Principles of risk management
4.1 Risk management concept
Risk management is a systematic and iterative process for optimizing resources
in accordance with the project’s risk management policy. It is integrated through defined roles and responsibilities into the day–to–day activities in all project domains and at all project levels. Risk management assists managers and engineers by including risk aspects in management and engineering practices and judgements throughout the project life cycle, including the preparation of project requirements documents. It is performed in an integrated, holistic way, maximizing the overall benefits in areas such as:
• design, manufacturing, testing, operation, maintenance, and disposal, together with their interfaces;
• control over risk consequences;
• management, cost, and schedule.
4.2 Risk management process
The entire spectrum of risks is assessed. Trade‐offs are made among different, and often competing, goals. Undesired events are assessed for their severity and likelihood of occurrence. The assessments of the alternatives for mitigating the risks are iterated, and the resulting measurements of performance and risk trend are used to optimize the tradable resources.
Within the risk management process, available risk information is produced and structured, facilitating risk communication and management decision making. The results of risk assessment and reduction and the residual risks are communicated to the project team for information and follow‐up.
4.3 Risk management implementation in a project
Risk management requires corporate commitment in each actor’s organization and the establishment of clear lines of responsibility and accountability from the top corporate level downwards. Project management has the overall responsibility for the implementation of risk management, ensuring an integrated, coherent approach for all project domains.
Trang 12Independent validation of data ensures the objectiveness of risk assessment, performed as part of the risk management process.
Risk management is a continuous, iterative process. It constitutes an integral part of normal project activity and is embedded within the existing management processes. It utilizes the existing elements of the project management processes to the maximum possible extent.
4.4 Risk management documentation
The risk management process is documented to ensure that the risk management policies (see Annex A) are well established, understood, implemented and maintained, and that they are traceable to the origin and rationale of all risk–related decisions made during the life of the project.
The risk management documentation includes the risk management policy, which:
• defines the organizationʹs attitude towards risk management, together with the project specific categorization of risk management, and
• provides a high‐level outline for the implementation of the risk management process.
In addition to the risk management policy document, two key documents are established:
• risk management plan describing the implementation of the risk management process (see Annex B), and
• risk assessment report for communicating the identified and assessed risks as well as the subsequent follow‐up actions and their results (see Annex C).
Trang 135 The risk management process
5.1 Overview of the risk management process
The iterative four–step risk management process of a project is illustrated in Figure 5‐1. The tasks to be performed within each of these steps are shown in Figure 5‐2.
Step 1 comprises the establishment of the risk management policy (Task 1) and risk management plan (Task 2) in coordination with other project disciplines, such as system engineering, product assurance, production, and operations, to ensure coherent approach to risk management across the programme/project. The risk management process includes full coordination between the disciplines
These tasks (1 and 2) are performed at the beginning of a project. The implementation of the risk management process consists of a number of “risk management cycles” over the project duration comprising the Steps 2 to 4, subdivided into the seven Tasks 3 to 9.
The period designated in the illustration with “Risk management process” comprises all the project phases of the project concerned. The frequency and project events at which cycles are required in a project (only three are shown in Figure 5‐1 for illustration purposes) depend on the needs and complexity of the project, and need to be defined during Step 1. Unforeseen cycles are required when changes to, for example, the schedule, technologies, techniques, and performance of the project baseline occur.
Risks at any stage of the project are controlled as part of the project management activities.
Trang 14Decide and act
Step 2
Identify and assess the risks
Step 4
Monitor, communicate and accept risks
Step 1
Define risk management implementation requirements
Task 1: Define the risk management policy Task 2: Prepare the risk management plan
Task 3: Identify risk scenarios Task 4: Assess the risks
Task 6: Reduce the risks Task 7: Recommend acceptance
Task 8: Monitor and communicate the risks Task 9: Submit risks for acceptance. (Return
Trang 155.2 Risk management steps and tasks
5.2.1 Step 1: Define risk management
implementation requirements 5.2.1.1 Purpose
To initiate the risk management process by defining the project risk management policy and preparing the project risk management plan.
5.2.1.2 Task 1: Define the risk management policy
d Definition of scheme for ranking the risk goals according to the requirements of the project.
e Establishment of scoring schemes for the severity of consequences and likelihood of occurrence for the relevant tradable resources as shown in the examples given in Figure 5‐3 and Figure 5‐4.
NOTE In the examples, five categories are used for
illustration only; more or fewer categories or designations are also possible.
f Establishment of a risk index scheme to denote the magnitudes of the risks of the various risk scenarios as shown, for example in Figure 5‐5. NOTE 1 Establishment of scoring and risk index schemas is
performed with the full coordination between the different project disciplines to ensure complete and consistent interpretation.
NOTE 2 In the example, risk magnitude categorization
(“Red”, “Yellow”, “Green”) is used for illustration only. Different designations are also possible
Trang 16Score Likelihood Likelihood of occurrence
E Maximum Certain to occur, will occur one or more times per project
NOTE In the example, risk magnitude designation,
acceptability, and proposed actions are used for illustration only. Project‐specific policy definitions can be different.
h Definition of risk acceptance criteria for individual risks.
NOTE The acceptability of likelihood of occurrence and
severity of consequence are both programme dependent. For example, when a programme is advancing new research, technology development
or management, a high probability of a consequence that quickly increase the cost can be acceptable.
i Establishment of a method for the ranking and comparison of risks.
j Establishment of a method to measure the overall risk.
k Establishment of acceptance criteria for the overall risk.
l Definition of the strategy for monitoring the risks and the formats to be used for communicating risk data to the decision–makers and all relevant actors in the project hierarchy.
m Description of the review, decision, and implementation flow within the project concerning all risk management matters.
Trang 17
Likelihood Risk Index:
Combination of Severity and Likelihood
E Low Medium High Very High Very High
A Very Low Very Low Very Low Very Low Low
E4, E5, D5 Very High risk Unacceptable risk: implement new team process or change
baseline – seek project management attention at appropriate high management level as defined in the risk management plan.E3, D4, C5 High risk Unacceptable risk: see above.
E2, D3, C4, B5 Medium risk Unacceptable risk: aggressively manage, consider alternative
team process or baseline – seek attention at appropriate management level as defined in the risk management plan. E1, D1, D2, C2,
Trang 185.2.2 Step 2: Identify and assess the risks
5.2.2.1 Purpose
To identify each of the risk scenarios, to determine then, based on the outputs from Step 1, the magnitude of the individual risks and, finally, to rank them. Data from all project domains are used (managerial, programmatic, technical).
NOTE List of examples of possible risk items:
• Technical: Technology maturity; definition
status of requirements, internal/external interfaces, payloads, operations; availability of margins, support team, project team; etc.
• Cost: Overall project cost definition status; cost
margins; insurance costs; availability of funding, independent cost assessment, industrial offers; human resources aspects; etc.
• Schedule: Procurement planning; availability
of planning of phases and activities interfacing with third parties; etc.
• Others: Internal organisational aspects; public
image; political constraints; risk sharing between actors; etc.
5.2.2.2 Task 3: Identify risk scenarios
Trang 195.2.3 Step 3: Decide and act
5.2.3.1 Purpose
To analyse the acceptability of risks and risk reduction options according to the risk management policy, and to determine the appropriate risk reduction strategy.
5.2.3.2 Task 5: Decide if the risks may be accepted
5.2.3.4 Task 7: Recommend acceptance
The following activities are included in this task:
a Decision options for acceptance of risks.
b Approval of acceptable and resolved risks.
Trang 205.2.4 Step 4: Monitor, communicate, and accept
b Identification of changes to existing risks and initiation of new risk analysis needed in order to decrease uncertainties.
c Verification of the performance and effect of corresponding risk reduction.
d Illustration of the risk trend over the project evolution by identifying how the magnitudes of risk have changed over project time.
e An example of a risk trend for technical risks, which are main risk contributors at the first project milestone, is provided in Figure 5‐7. S1, S2 and S3 are three risk scenarios.
NOTE In the example, the evolution of S1 shows that, in
spite of risk reduction efforts, risk trend can worsen before improvement.
f Communication of the risks and the risk trend to the appropriate level of management.
g Implementation of an alert system for new risks.