January 16, 2012

Project Risk Analysis - M-10

Identify the project risks

A. Scope

Risk Management serves to identify risks of all types (technique and programmatic) to which the project is susceptible, to asses their potential impacts and to define and manage activities which can guarantee their acceptability.

Risk Management is initiated in phase A and is updated throughout the project's entire life cycle.

The Risk Management proceedings for the project are covered in the Risk Management Plan, written by the project department, based on the CNES Standards Reference (RNC) document "RNC-CNES-M-HB-80-501Plan type de maîtrise des risques projet". If need be, this Plan satisfies the Risk Management requirements made applicable by the project's Customer (using RNC standard "RNC-ECSS-M-ST-80 Risk Management").

B. Fundamentals

The Risk Management process comprises 5 stages, illustrated by the flow-chart below:



1. Risk identification

Risk identification is performed using analyses from all project players. When the project kicks off, it can be usefully conducted by consulting the lists of typical risks classified into activity domains (organisation, management, planning, costs, etc.) and by taking into account the output from the Preliminary Risk Analysis (refer to PA-4).

This identification is materialised by production and on updating the risk sheets that have been consolidated during the collective summary sessions chaired by the Project Manager. All the information thus collected for each risk is recorded in a project "Risk Sheet" (see MF-5). The set of Risk Sheets makes up the project's "Risk File".

2. Risk characterisation

Risk characterisation consists in assessing the Probability of occurrence for each risk and the Severity of its effects should it materialise.

The project team is responsible for defining objective Severity assessment criteria, in accordance with its risk policy.

The [Severity, Probability] pair allows the Criticality of the risk to be quantified, and the risks can then be organised into a hierarchy. Criticality is classified by allocating an acceptability status, e.g. "acceptable" or "unacceptable" for each pair of values [Probability, Severity].

Here is an example of Criticality classification (this characterisation depends on the risk policy adopted by the project team):

  • 3 levels are proposed for assessing the Probability of occurrence :
    • 1 = "Low". The risk should not materialise (this type of risk hardly ever materialises).
    • 2 = "Medium". The risk could materialise (this type of risk sometimes materialises every 1 to 10 projects).
    • 3 = "High". The risk is almost certain to materialise (this type of risk often materialises, once or twice per project).
  • 3 levels are also proposed for assessing the Severity:
    • 1 = "Negligible"
    • 2 = "Major"
    • 3 = "Critical"
  • Criticality is defined according to 2 classes: "Acceptable" and "Unacceptable"




3. Establishing an action plan for reducing risks

The action plan aims to bring the risk down to a Criticality level which is judged acceptable by the project team.

For every unacceptable risk, one or more actions must therefore be set up with a view to reducing its Probability of occurrence and/or Severity. Each action decided upon for the project takes the form of a "risk reduction action sheet" (refer to MF-6).

4. Monitoring risk changes

Risk monitoring frequency (during progress meetings, reviews, etc.) shall be defined as per the Risk Management policy adopted by the project team.

Monitoring changes to risks involves the following activities:

  • monitoring action plan progress,
  • regularly updating the Risk File, through dedicated meetings organised with the Project Manager,
  • issuing periodic summary reports,
  • presenting the status of risks, during key project reviews or meetings.


The closure of a risk and the acceptance of a residual unacceptable risk must be approved by the Project Manager.

5. Lessons learned

At the end of the project, summaries are drawn up in order to contribute to lessons learned on risks and to anticipate risks on new projects, as far in advance as possible. In particular, the lessons learned can also enrich the lists of typical risks.

C. Typical content for the Risk Management Plan

1. Scope

Following a brief recap of the project's characteristics and its Risk Management policy, this section presents the scope of the activities performed as part of Risk Management for the project.

2. Documentation

2.1 Applicable documents

These are all the documents which are applicable to the project's Risk Management activities.

2.2 Reference documents

These form the bibliography required for preparing the project's Risk Management activities.

2.3 Glossary

This defines the terminology and acronyms used in the document.

3. Definition of information

This section is used by the project team to precisely define the information used in the risk sheets and risk reduction action sheets (refer to MF-6).

This section also provides the documentation formats for summarising the risk file and associated actions.

4. Use of typical risks

This section mentions any typical risk lists to be used for the project in order to initialise its risk base.

5. Risk classification grid

This section presents the selected classification scales for establishing the hierarchy of risks:

  • Probability of occurrence (number of classes, characterisation of probabilities by class),
  • Severity of effects (number of classes, characterisation of effects by class),
  • Criticality by pair (Severity x Probability).


6. Organisation of activities

This section specifies:

  • the role and attributes of everyone involved (Project Manager, Risk Manager, designers, etc.),
  • the procedure for delivering the Customer of risks,
  • the updating frequency for Risk File summaries, the key points for which a summary is required.


If necessary, the project team states whether it intends to use a tool and provides a brief description of it.


RisksPoor knowledge of project risks
Analysis of Project Risk (ARP)



Activities / documentation

Published in: