Please login or join to subscribe to this thread
When I led the EPMO for a local government agency, we had the same issue with an established enterprise risk function and a relatively new portfolio/program/project risk one.
It does make sense to separate the risk data between the two, but it also makes sense to have integration between them and this was achieved by my sitting on the enterprise risk committee. My role was to bring to the table any key risks which the cross functional risk leaders needed to be aware of which might impact their operational areas and similarly for me to become aware of any many operational initiatives, events or risks which could end up impacting portfolio components.
We had a prose-like register for the enterprise risks (as it was shared with stakeholders inside and outside the organization) and a more traditional tabular risk register for our enterprise portfolio.
A simple way to do this would be to have a common repository yet have a flag for portfolio or business/corporate which would then enable reporting and linking of items in both.
Absolutely different registers or as Kiron noted, to have a way to differentiate the two for the appropriate audiences.
For one, While I do advocate transparency over secrecy, sometimes it is wise to be cautious about what you present to the executive level without someone there to explain it. At the working level, you can be a bit less formal about how you document some things, since there is more knowledge about the actual situation. I have had instances where a senior executive started asking questions about things they found in our risk tool on items that were a significant risk at the project level, but much lower at the program level. When the big boss calls for answers, all other work stops.
Secondly, some tools drive a lot of overhead so you need to decide what risks go into the tool. Some can require a lot of documentation such as the entire handling plan which is a duplicate to your working plan any time you add a new risk. That's fine at the exec level, but you don't want to double your work for every single risk at the working level.
Finally, some risks will haunt you for your entire career once you put them in the tool if you are not careful about how they are documented. Some risks will never go away, but will require regular status if they are in the tool. On one program where I worked, regulatory compliance was always an issue. Any minor product test failure could cause a delay to fix the problem before we were compliant, so the risk to the program was a revolving door of mostly minor risks and issues. If it is flagged at the wrong level, it gets discussed at every corporate level risk review, even though that risk is really business as usual. It can waste time, and draw the wrong kind of attention.
Project risks must be derived from corporate risks. Project risks must not be inside the corporate risks. We have a simple tool created with MS Power Apps to manage this.
Yes, Chris, different risk registers as there are different targets under risk and different risk appetites, tolerances and attitudes.
It also is different for portfolios and program levels.
The need is risk level integration, which means risk escalation but also overall risk levels considered from lower level areas.
Enterprise risk management ERM is well standardized and mandatory for public companies, many consultants and tools help with it. Also at PMI. Internal Audit - reporting the Board - will help with improving it, on a project level, independent QA - quality assurance - can help to identify risks and mitigate them. I introduced my first QA function as part of a PMO in 1997.
I see the Risk Register as a bottom up tool. Starts with the individual team members and feeds up to the corporate level. That doesn't mean that one has to have a formal Risk Register at the individual level but there should be an understanding as to what could go wrong with one's assignment and how that could impact the team, the project and the corporation.
Depending on the complexity of the project a formal Risk Register may not appear until the project level.
As to what feeds into the upper levels, that depends on the impact of the risk at that level. As an example: A corporate risk may be project failure - what is the probability, what is the impact, how do we mitigate. One of the mitigating measures may be to have a project Risk Register.
thanks everyone - its good to have back up from the team on this one!!
Please login or join to reply