Category Archives: Project Management

Order out of chaos: Risk Breakdown Structure

Posted on by
Reply

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.

Risk metalanguage: how to make a proper Risk Register

Posted on by
Reply

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.

Risk & contingencies - a brief introduction

Posted on by
Reply

One of the hot topics frequently discussed in the creation of the budget for big projects is the appropriate contingency level and how to estimate it.

My colleague Giuseppe had found an interesting paper online that has been the starting point for this post.

So, what are contingencies?

Some far reaching definitions consider different typologies of contingencies:

  1. Money in the budget
  2. Float in the schedule
  3. Tolerance in the technical specifications
  4. Tolerance in the quality
  5. Tolerance in the scope of work

Possibly this is a very broad approach, so I will focus only on the first point.

Monetary contingencies are added to the estimate “to allow for items and events for which the state, occurrence or effect is uncertain” (the definition is proposed by the Association for the Advancement of Cost Engineering).

Several concepts are usually excluded from the contingency budget:

  • Major changes in scope
  • Extraordinary events (such as the one indicated in the Force Majeure clauses)
  • Currency exchange risk (this is usually hedged or it is included in a different section of the budget)

Basically in the definition of contingencies the focus is on the “negative risks” that can create a loss if they materialize (“positive risks” is a fancy way to call the opportunities).

Identified vs unidentified risks

A key distinction should be made between identified risks and unidentified risks.

Identified risks are “known unknowns” – that is, risks you are aware of (a classic example would be the geotechnical risk.

Unidentified risks are more similar to “unknown unknowns” - risks that come from situations that are so unexpected and difficult to foreseen even to subject matter experts that they would not be considered.

On top of this type of risk, there are also risk that emerge later in time – as a result of our actions and decisions or as a result of actions and decisions of external agents.

For this reason risk management processes include periodical risk reviews: you do your best to identify all risk at the beginning of the project but the situation can evolve in unexpected ways.

Identified risks can (and should) be managed: they should be included in a risk register, with a quantification, a predefined plan if the risk materialize, an owner, etc.

Strategies for identified risks

Additionally, several strategies are possible for identified risk: they can be

Avoided (if a subcontractor has a poor financial status it can be removed from the bidders list)

Transferred (if the failure of the main transformer can put at risk the viability of the investment, a business continuity insurance can be purchased)

Shared (if a project is very big, possibly a Joint Venture could be a good choice)

Mitigated (if a construction technology is very complex it could be a poor choice in an emerging country, where an easier solution could be a less risky choice)

Accepted (in this case, usually a monetary reserve is created for the accepted risks).

What about unidentified risks?

Unidentified (“unknown”) risks are conceptually different. Even if a great effort has been made to identify all possible risks the experience show that when the project is finally built several unforeseen events will happen, impacting the budget.

The quantification of the contingency for these unknown risk is a complex topic and a never ending source of discussions when budgeting a project.

I have found an interesting chapter on the subject on a book on Project Risk Management (by C. Chapman and S. Ward, ISBN 978-0470853559).

They consider that the residual uncertainty has three sources:

  • Explicit assumptions (known unknowns)
  • Implicit assumptions (unknown unknowns)
  • Bias (systematic estimation errors)

They suggest to use three different "scaling factors" to consider these sources of uncertainty, Fk, Fu and Fb, The product of the three factors is designated F3:

F3 = Fk x Fu x Fb

The authors suggest that even if estimating these factors is highly subjective not doing so lead to an even worst scenario, a "Conspiracy of Optimism".

The logic is that would be seriously irrational to believe that such factors do not apply to your project unless you have solid grounds to prove that.

Even if different stakeholders could have a different view on the value of these factors the debate itself inside the organization should prove to be beneficial: refusing to acknowledge and discuss the issue will not make it disappear.

I believe that the same logic should apply when a risk register is created.

The meaning of a qualitative analysis of a risk ("There is a high probability of a small impact on budget") should be made explicit.

Is an high probability 80% or 99%? How small is a small impact? And so on.

Wind farm project management: PRICE2 vs PMP

Posted on by
Reply

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

Posted on by
5

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

Posted on by
3

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.

Posted on by
1

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.