Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Risk Management
How do you manage project and corporate risk registers?
Hi everyone
I'm establishing a PMO in an organisation with very low project management maturity. Corporate risk is managed by a different team and there is a current project to implement a basic business risk register based on our health and safety management system. I'm also scoping a PPM tool.
Corporate risks have a higher tolerance level than project risk so I'm unsure about having project risks in the corporate register. My preference is to have project risk in the PPM tool (and operational, strategic & significant programme/project risks). Current thought is to set up some kind of integration to push significant project risks to the corporate risk register.
I've encountered this problem in two organisations I've worked in so wonder whether its common place and how people are managing it.

Is anyone else finding challenges in how corporate and project risks are managed? Split responsibilities?
Do you have separate registers for project and corp risks?
How is this managed in IT / BI tools?

Many thanks
Sort By:
Chris -

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.

Kiron
...
1 reply by Chris Blythe
Dec 08, 2021 3:56 PM
Chris Blythe
...
Thanks Kiron - our views are aligned. Good for me to have some reassurance!!
Dec 08, 2021 3:49 PM
Replying to Kiron Bondale
...
Chris -

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.

Kiron
Thanks Kiron - our views are aligned. Good for me to have some reassurance!!
...
1 reply by Kiron Bondale
Dec 08, 2021 5:56 PM
Kiron Bondale
...
One of the real benefits we received from the cross-pollination meetings was that some new portfolio component risks were identified as a result which had been completely missed by the program/project teams. Given that portfolio components are part of a bigger organizational whole, the overall risk "stack" needs to be considered to increase effectiveness of the function.

Kiron
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.
Dec 08, 2021 3:56 PM
Replying to Chris Blythe
...
Thanks Kiron - our views are aligned. Good for me to have some reassurance!!
One of the real benefits we received from the cross-pollination meetings was that some new portfolio component risks were identified as a result which had been completely missed by the program/project teams. Given that portfolio components are part of a bigger organizational whole, the overall risk "stack" needs to be considered to increase effectiveness of the function.

Kiron
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.

Thomas
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

Content ID:
ADVERTISEMENTS

"If life was fair, Elvis would be alive and all the impersonators would be dead."

- Johnny Carson

ADVERTISEMENT

Sponsors