Please login or join to subscribe to this thread
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.
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).
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.
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.
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:
Conflict of interest
Governance and strategic direction
Human resources management
Organizational transformation and change management
Policy development and implementation
Privacy / Information stewardship
Program design and delivery
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