There is a good number of techniques that can be used to identify risks.

Some are techniques focused looking at past (every Tender Manager should be able to create a list of issues he had experienced in past projects), other tools are focused on the present (spending a few hours reviewing your current assumptions should help you identify a good number of “what if the assumption is wrong” risks) and other help you to think forward (for instance, a good brainstorming session with stakeholders and experts from different departments).

The outcome of such techniques is a list of risk, usually very long and, above all, unstructured. A qualitative risk assessment can be done, attributing to each risk a “probability and impact score”. My impression is that such exercise is somehow arbitrary (although this is probably better than nothing). What is not provided by the qualitative risk assessment is some visibility on risk patterns, concentrations of risks and correlation between risk causes.

An interesting tool that can be used for such scope is the Risk Breakdown Structure (RBS). Inspired by its more famous counterpart, the Work Breakdown Structure (WBS), it is basically a hierarchical structure (a “taxonomy”) defining several categories and sub-categories for risks. For a wind farm, an example of RBS could for instance consider at the first level the project, the customer, the management (internal) risks and the environmental risk.

Here I’ve made a very rough, unfinished example of how a RBS for a wind farm could look like – as I think it is an interesting exercise I will try to expand it and complete it in the future:

Which are the benefits of such approach?

I believe that the most important one is the identification of high-risk areas: are the majority of your risks coming from the same area? This can help focus the efforts on the most critical aspects. "Majority of risks" should not be considered the absolute number of risks (you can have dozens of low severity risks in the same area). A better way to do it would be to assign a numerical value to each risk, the "Probability x Impact" score and sum the value of such risk scores in all the areas (level 1), subareas (level 2) or sub-subareas (level 3).

Once it has been properly developed the RBS itself can also be used as a checklist for risk identification in future tenders or projects (assuming that your organization is working at comparable projects, as it usually the case in wind farms).

Last but not least, the RBS can be used to compare the risk level and concentration of two or more different tenders or projects, possibly weighting the lowest level risks with their probability / impact score.

One of the key deliverables in project risk management is the risk register.

The idea is that after risk identification, qualitative and quantitative analysis, and planning of risk response the tender manger (or project manager) should end having a list with all the risk identified at that point in time.

I assume that the content and format of the list will vary depending on the type of project and organization. However I believe that it should include at least:

• Risk description
• Impact on objective
• Risk response strategy
• Risk owner

The Project Management Institute add to this list other concepts like category (the taxonomy of risks always looked somehow arbitrary to me), probability (even more difficult to define with accuracy in many situations) and cause.

If you are familiar with the topic you will remember that, if a risk materialize, it will be moved from the risk register to the issues (or problems) register.

And here the interesting parts – I have been reviewing some risk registers that I have done in the past noticing that the description of risk was mixing three different concepts – cause, risk and effect.

“Presence of strong Workers Unions in the area”, for instance, it is not a risk: it is a fact, a reality in several projects I have been involved.

The risk is to have many strikes in the construction site – the effect would be delays (impacting the “to be on time” objective) and payment of damages (impacting the “to be on budget” objective).

There is a proper way to fill the risk register: the use of risk metalanguage.

Risk should be expressed in sentences with this structure:

“Because of <cause>, <risk> might occur, which would lead to <effect>.”

This language construction help bringing clarity and logic to the risk register. The previous example would become for instance:

“Because of <the presence of strong Workers Unions in the area>, <many strikes> might occur, which would lead to <delays and payment of damages>.”

There are some interesting implications. For instance this structure should be used in different languages – I would be curious to see if it can be replicated easily in all of them.

Additionally, it force you to think at the logical correlation between the causes of risks.

For instance, you can think at different situations were the same risk can have 2 different, independent causes:

“Because of <cause #1 AND cause #2>, <risk> might occur, which would lead to <effect>.”

I understand that in this case it should be split in 2 different entries of the Risk Register.

However in some situations two or more different causes need to be there at the same time for the risk to materialize:

“Because of <cause #1 PLUS cause #2>, <risk> might occur, which would lead to <effect>.”

Obviously you can increase the complexity ad libitum, as the same risk can have more than one effect:

“Because of <cause>, <risk> might occur, which would lead to <effect #1 AND effect #2>.”

I guess that also in this case the good practice is to split the sentence in two different entries for the Risk Register.