Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Consulting, Risk Management
Project Risk Management: How to set the Risk Breakdown Structure?
Hi, I'm defining a Risk Breakdown Structure to be used for the International project in my Company. But, I have a question, due to the fact, my Company, operating in the railway and transportation sector, operate in different type of project (Design, Construction, Operation and maintenance - both passengers and goods etc.). The Risk Breakdown Structure should reflect these different typologies or it is better to generalize the RBS? Which is the best way to fix this problem? I hope I have been clear. Looking forward to read your precious answers
Sort By:
Dear Teresa
Interesting your question
Thanks for sharing

There are inherent risks to the activity that encompass the entire company and project risks

It depends on what level you are working on to define the Risk Breakdown Structure.
The key point is RBS must have a high level of abstraction. RBS is a template that you will instantiated for each project adding to it the risk you detect into the project itself. Because of that the rule of tumb the RBS has 7+-2 levels in deep. Is not by project, is by risk the whole company must face into each initiative because of that things like PESTLE analysis are the key tools to identify the risks.
...
1 reply by MD Sarfaraj Alam
Jan 15, 2020 8:44 AM
MD Sarfaraj Alam
...
I agree with this observation. PESTLE could be a great starting point. Especially for the fact that it is an international project. Sourcing of technical resource may not be as big a challenge as Political, or Legal aspect. Drilling down from PESTLE with close eye on country specific aspect should help.
A RBS should reflect the key sources of risk to your specific project, and as such should be tailored to your project.

Sergio is right, that organizations may have a RBS to be used for all projects, but a specific project may not use all categories in this and add other categories. When I worked at IBM, we had a big tool which hundreds of questions, but we could say not relevant to most. Automation resulted in a standardized overall risk score and suggestions for risk responses.

The organizational RBS should be updated with new categories as lessons learned identify underrepresented risk categories (e.g. GDPR risks).
...
1 reply by Luis Branco
Jan 15, 2020 6:40 AM
Luis Branco
...
Dear Thomas
Thank you for your opinion

For each project it is necessary to go through the identified risks for the sector and for the company.

It is important to determine whether or not these risks affect the specific project.
Jan 15, 2020 6:16 AM
Replying to Thomas Walenta
...
A RBS should reflect the key sources of risk to your specific project, and as such should be tailored to your project.

Sergio is right, that organizations may have a RBS to be used for all projects, but a specific project may not use all categories in this and add other categories. When I worked at IBM, we had a big tool which hundreds of questions, but we could say not relevant to most. Automation resulted in a standardized overall risk score and suggestions for risk responses.

The organizational RBS should be updated with new categories as lessons learned identify underrepresented risk categories (e.g. GDPR risks).
Dear Thomas
Thank you for your opinion

For each project it is necessary to go through the identified risks for the sector and for the company.

It is important to determine whether or not these risks affect the specific project.
Teresa,

Since an RBS can be multi-level like WBS like suggested by Sergio. Like many large corporations may have a WBS, many don't. If your organization doesn't have one Build the first one.
You may not have mentioned all your top-level, I would add Legal and Financial. Under Financial you need Exchange rates.
Suggestion from Thomas about lessons learned to update RBS is important.
I agree with Sergio.
Jan 15, 2020 5:47 AM
Replying to Sergio Luis Conte
...
The key point is RBS must have a high level of abstraction. RBS is a template that you will instantiated for each project adding to it the risk you detect into the project itself. Because of that the rule of tumb the RBS has 7+-2 levels in deep. Is not by project, is by risk the whole company must face into each initiative because of that things like PESTLE analysis are the key tools to identify the risks.
I agree with this observation. PESTLE could be a great starting point. Especially for the fact that it is an international project. Sourcing of technical resource may not be as big a challenge as Political, or Legal aspect. Drilling down from PESTLE with close eye on country specific aspect should help.
Our Treasury Board of Canada Secretariat has categorized risks into the following categories, which could be of assistance to to you in developing your own unique RBS, although many are unique to the government and not necessarily applicable to industry:

Business processes
Capital infrastructure
Communications
Conflict of interest
Financial management
Governance and strategic direction
Human resources management
Information management
Information technology
Knowledge management
Legal
Organizational transformation and change management
Policy development and implementation
Privacy / Information stewardship
Program design and delivery
Project management
Political
Reputational
Resource management
Stakeholders and partnerships
Values and ethics
There is no one optimal way, as what is optimal for some uses is not optimal for others. What works best for design is often different than for manufacturing, operations, or support. Risks may be related to individual components, functions which involve multiple components, requirements which may be broadly applicable, external environmental factors etc. There are one to one relationships, one to many, and many to many.

In order to figure out what is best for your own use, you need to carefully consider how it will be used and by whom, for example are they centrally managed, or will specific risks only be visible to certain departments? If it is narrowly focused on a specific project, you may be able to develop a point design solution with consultation from a few stakeholders, but if you need an enterprise standard solution which covers your entire product lifecycle, you may lay out several approaches, and determine which works best for the most stakeholders.
Just to add some additional comment, I worked for companies that sell RBSs for different industries considering architectures as you stated. Those companies sell WBSs, Schedules, etc. too. So, perhaps you can find examples or something like that to take as a basic template.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Teachers open the door, but you must enter by yourself."

- Chinese Proverb

ADVERTISEMENT

Sponsors