Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Risk Register normally contains very sensitive information about potential problems. Some of them sound very scary like "we may loose our key sponsor" or "our CTO may eventually leave the company". These severe risks are very important for a project manager; he/she has to include them into the Risk Registry.
However, shall a PM make this document visible to other project participants, like programmers, sponsors, architects, shareholders?
Let's say that "we may lose our key sponsor" is an actual risk on your project. Would you want to discuss that risk with your team members and stakeholders? Would you want them to discuss as a group how to mitigate this risk? If so, then you should make your risk register available to those people.
I am all for openness and transparency when managing a project. When you start to have "secret risks", you then have an additional risk -- that someone will find out that you have secret risks.
Create different versions of the risk register that are specific to the group you are sharing it with. They should be sub-sets of the overall project risk register.
Just as you don't need to share the status of every sub-task with your project sponsor (the milestones will do) or share the designers tasks with the engineer (each has their own task list to worry about), it can be detrimental to share every risk with every stakeholder on the project.
Here is an article on customizing communications to the right context from ComputerWorld (I wrote it) and a blog post on this topic (the Twitter Rule of Project Management).
Consider this, there are risks that you may not even know about!
There could be a pressing legal issue that only senior managers know about that could affect your project. In that case, even you, the project manager, doesn't have this information in your Risk Register.
The answer in your situation is simple. You mentioned that your Risk Register contains very sensitive information about potential problems.
By definition of the problems being labeled as very sensitive information, you do not want to make that public.
The analogy I use in this scenario is in Government security. There are oftentimes may layers of security with varying degrees of personnel authorized at different levels. At the top secret levels, the most sensitive risks are known. At the bottom levels, only very granular risks are known.
If you are the maintainer of this document, then you need to work with your managers to identify the level of sensitivity of the risk, and determine what type of secret clearance project members and stakeholders will have.
The scenarios you mentioned must be evaluated by the project team with a mitigation plan and owner. If key personnel leave the project, what will the impact be? Who has the authority/responsibility of replacing the resource? If it is sensitive company information, then you must certainly use your professional judgment. Document the risk "loss of key personnel" instead of saying "the CTO is going to be fired next week."
Risks are of different levels. While I advocate 100% transparency in risks, this is not practical. Practically speaking, a subset of all risks may need to be shown only to a limited number of people.
For example, your company is undergoing a round of lay-offs. Morale is low, and people may quit. Do you really think it's smart to put "X person (or X position) may quit" into a public register? That could exacerbate the problem.
The easiest solution to this is to keep two risk registers: One contains those risks that may be damaging and should be kept to only the few people who need to see them (like senior management), and everything else should be public.
This also forces you to think twice if you add a risk to your confidential register; does it really need to go there? Most risks won't need to, but a few will.
