1. Trang chủ
  2. » Kinh Tế - Quản Lý

Space project management - Risk management pptx

43 577 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Risk Management
Tác giả ECSS Secretariat, ECSS Requirements & Standards Division
Trường học European Space Agency - ESA
Chuyên ngành Space Project Management
Thể loại Standard (Standard for space project management)
Năm xuất bản 2008
Thành phố Noordwijk
Định dạng
Số trang 43
Dung lượng 551,24 KB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

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 2

Foreword

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 4

Table 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 5

7 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 7

1   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 9

3 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 10

3.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 11

4 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 12

Independent  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 13

5 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 14

Decide 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 15

5.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 16

Score  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 18

5.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 19

5.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 20

5.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. 

Ngày đăng: 07/03/2014, 02:20

TỪ KHÓA LIÊN QUAN