CASoft Blog

In my experience, Risk Analysis is primarily about communication. If the communication going around the project is not open and efficient, no risk analysis approach will save it.
On the other hand, if there is good communication going, a simple risk analysis methodology will do wonders.

The objective of a risk analysis is to identify, quantify and as much as possible mitigate the effects of events that have the potential to prevent a project from reaching its objectives. A risk analysis is not about identifying dysfunctions or people to blame.

The goals of a risk analysis is to:

• give confidence to the Project Manager that all the contingencies have been considered
• help working teams to focus on the key issues
• mitigate the potiential impact of certain risks
• help to prepare for the unexpected
• improve the control over the development life-cycle and increase the capability to achieve the project objectives

A common method consists in brainstorming sessions, which allow to establish a list of risks. Each risk has an assignee, who will have the responsibility to help analysing the risk, usually the subject matter expert.
Let’s remind ourselves now one fundamental principle of risk analysis: “No idea is too stupide to be mentionned”. This is why small risks and very important risks will be listed side by side.
Then each risk is the object of a detailled analysis, which will allow to determine the value of a number of attributes. In particular, risks are classified by category.

The following categories may be considered for Software Development projects:

• Requirements
• Analysis and Design
• Coding
• Test
• Deployment
• Training and Documentation
• Maintenance and Support
• General

Each risk is also allocated a value for importance. The calculation of the importance is realised by using a Probability-Impact matrix. In the following example the matrix give more importance to the impact over the probability:

Still in the context of the calculation of the importance, it is recommended to undertake a ponderation of the severities in relation to cost, quality and planning, in order to take into account the imperatives of the project.

A risk analysis will allow to highlight a number of solutions susceptible to mitigate the risks. Solutions will translate into actions. Some of these actions will need to be undertaken rapidely, in order to prevent the apparition of risks. They are preventive actions. Some will rely on the risk being triggered. They are curative actions.
Each action is allocated a value for importance too, which is calculated with the importance of risks it is mitigating.

Risks may later be managed using Risk Management Plan type document, or project traking type document, such as Status Assessment.

The source of information should also be documented, as context for the risk analysis. For example, list the brainstorming sessions that have happened and the attendees.

When documenting the results of the risk analysis, it is recommended to provide first the catalog of risks as a summary, sorted by importance. Then describe the risks in details by category.
The following attributes are to be documented for each risk:

• Description – what it is about
• Indicator – how do we find out
• Impact (source part, impacted part, probability, impact severity on cost, quality and planning)
• Possible solutions – refering to actions

The risk repartition may be documented using charts as for example:

• Severity repartition for planning, quality and/or cost
• Risks repartition by category (risks number and % importance)
• Risks control repartition (risks per person, team, group and/or organisation)

Proposed actions are listed with a reference, a description, an undertaking mechanism and associated risks (which are mitigated by the action).

In conclusion, most of the proposed actions should be preventive and therefore undertaken as soon as possible, as a fundamental principle of risks analysis consists in anticipating problems. Indeed risk analysis is not supposed to provide solutions to existing problems, as it is considered to be late.
It is recommended to undertake a process analyse, as per the RUP methodology for example, in order to describe actions in details and to anchor them within a well known methodology.

Finally the risks analysis identifies New risks. The risks management consists in turning risks from New to Open when they are triggered, and turning them from Open to Closed when they have been treated.

Existing problems, at the time of the risks analysis, aren’t identified as risks, since no probability can associated, but they may be managed as open risks during risk management.