Risk metalanguage: how to make a proper Risk Register

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.

Wind farm project management: PRICE2 vs PMP

In another post I have discussed my experience with the PMP certification and its (somehow weak) relationship with wind farm project management.

In a nutshell, several processes and concepts are not directly applicable given the peculiarity of our industry. Said that, I believe that the PMP has a value, because it explain in detail a lot of tools and ideas that are used daily – for instance dependency types in Gantt charts, how to handle risk management or the “stakeholder management” concept.

Some days ago I have made another PM certification, the British de facto standard PRINCE2. The main reason for that has been my curiosity to see another point of view on a very broad topic such as project management.

Both certifications are trying to live together and differentiate themselves:

  • PMP define itself as a “standard” and comes with a mountain of processes and techniques.
  • PRINCE2 define itself as a “methodology”, coming with models and templates but very few techniques.

My personal impression is that the role of the Project Manager in PRICE2 is less relevant compared to the PMP idea of the same role – basically he has some decision margins, but he’s somehow squeezed between the Project Board making the big decisions and the teams doing the actual job. As soon as one of the tolerance levels is exceeded, he need to escalate the problem to the Project Board (that in the wind industry, if it exist, is usually called “Steering Committee” or something similar).

This image is strikingly different from the one that my mentor Luis Miguel gave me when he told me that, in the infancy of the wind industry, the PM was basically “the God of construction site”. Possibly the image is a bit strong but it makes the concept crystal clear.

Said that I also had the feeling that PRINCE2 was much easier to follow in the definition of the workflow, with less processes (seven) clearly linked between them and few key concepts (“Themes” and “Principles”). Understanding the relationship between the 49 processes of PMP is not that easy: I had to print them in a huge A0 and spend a lot of time staring at it to make a sense of them.

An interesting argument that I want to mention against PRINCE2 is that it is “unfalsifiable”, in the scientific sense defined by Karl Popper. This basically means that PRINCE2 has to be tailored (that is, adapted) to the specific project to work properly. If something goes wrong, you cannot proof that the problem is PRINCE2 (because possibly the tailoring you have made was wrong).

In conclusion I would recommend both certification to people interested in knowing more about project management, even if some tools, techniques and processes are not used in wind farms construction.

PMP methodology & wind farm project management

This week I had the pleasure to pass the PMP (Project Management Professional) exam – one of the two leading certifications for project managers, the other being PRINCE2 from the UK. The exam itself is notoriously not trivial: long (200 questions in 4 hours) and based on a book very hard to read, the Project Management Body of Knowledge (“PMBoK”).

In general I would recommend it, as it provide a solid methodology together with a broad suit of concepts, tools and techniques. On top of that, a great number of terms are defined in detail and this alone is a great benefit as this facilitate the interaction with other professionals providing a common language.

Said that, and totally aware of the fact that this type of methodologies are conceived to be “not industry specific”, I believe that there are many relevant difference between the PMP concept and the way wind farm project management is today, at least seen through the eyes of Project Managers (PM) working for wind turbine manufacturers or Main Contractors.

To give some example, one of the first steps in the PMP standard is the creation of a business case for the project.  This is something that you will hardly see in wind farm construction – maybe the wind farm developer has a business case, but the company building the wind farm is selling a product (the wind turbine) and some services (BoP, installation, maintenance). No need for business justifications, this is the core business.

Additionally, in the PMP methodology the PM should start to define the scope, the deliverables, the cost baseline, etc. I believe that in general the wind industry the PM receive all this inputs from the Sales Manager and/or Tender Manager, and even if there are always open points and deliverables that need to be defined more in detail this is not the main focus of the PM.

I have also rarely seen in wind farm construction a change management system as developed as the one in the PMP standard. I do however recognize that it has a lot of sense, providing a uniformity and a logic in the way changes are analysed and approved or rejected.

Finally yet importantly, the current version of PMP (sixth edition) include a variety of Agile Development concepts. These are more relevant in software development and similar environments: onshore wind farm construction is a business where these evolutionary development and adaptive planning techniques do not usually find opportunities to be used.

Wind farm construction steps: generic timeline infographic

One of the pleasures of fatherhood is the fact that you have quite a lot of extra times during the night – if your kids do not sleep.

Yesterday night has been exceptionally short due to a son diving out of the bed and hitting his head and another who decided that at 6 AM the night was ended.

Therefore I’ve used this extra time to create a timeline with a very generic overview of a small wind farm construction steps.

They can (and do) vary a lot between a project and another. However it should give you a rough order of magnitude of the key steps and the time needed for each of them.

The editable PPT file is available on demand. It’s based on a free template made available by Hubspot (thank you guys!).

Enjoy!

Where do I go from here? Careers path in the renewable industry.

This post is about my personal experience with possible careers path in the onshore wind industry - what are the easy and the not so easy movements. I believe that the main concepts would be applicable to similar industries, such as Solar or Offshore.

It’s applicable to medium and big size companies organized in a classic way (Engineering design the product - in my case a wind turbine, Sales & Tender Management sell it, Project Management build it).

I focused on the departments that are near to my professional experience – therefore I’m not keeping into consideration Service and all auxiliary departments (e.g. HHRR).

The most “natural” career path is upward: you start for instance as a (Junior) Project Manager, you become a Project Manager, Senior Project manager, maybe a Project Director (if this position exist in your company) and finally you land in a Head of Project management position.

What makes fun (and broaden your view of the company) is to have also “lateral” movements.

I believe that some are easier than other. For instance I know many Project Managers that become Tender Manager and vice versa, or engineers becoming Tender Manager. Somehow more rare is to see a Sales Manager becoming a Project Manager, or a Tender Manager becoming a Sales Manager.

It’s not impossible, I know a bunch of cases. However, Sales guy are usually a different class.

For instance I’ve never met an Engineer with a Sales background: I’m not saying that it’s impossible, but for sure is a less frequent (and more complicate) career move.

I tried to summarize visually the idea in the picture.

I also beleive that  moving “lateral and up” would make the change even more complicate.

For instance it would be complicate for Tender Manager to become a Senior Project Manager (or Project Director), but it would be much more complicate for a Project Manager to step into a Senior Sales Manager (or Sales Director) position.