Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Risk Management
Sensitive Risk Mananagement
avatar
Phan Hoang Minh Product Manager| Ponos Tech Thu Duc, SG, Vietnam
Is it advisable to have multiple versions of the risk management plan and response document due to the presence of sensitive information that isn’t suitable for sharing with the entire team? For example, risks related to certain members’ abilities and mindset not meeting project requirements, or situations where two members have personal conflicts?
Sort By:
avatar
Danny Seow
Community Champion
Tokyo, Japan
Personally, i think it’s advisable to have multiple versions of the risk management plan to protect sensitive information. For instance, risks related to individual performance or company top secret, should be documented separately in a confidential version for key stakeholders (e.g., HR, project sponsors) rather than shared with the entire team. This ensures that sensitive issues are addressed appropriately without impacting team morale or trust, while still maintaining an overall high-level plan for broader team awareness. Access control and document versioning can help manage these different versions securely.

Early in the project, we had this almost paranoid assessment to ringfence intellectual property beyond what the patent department protects - due to the potential loss of competitive advantage had the information been inadvertently leaked. Even for a miniscule probability of exposure but with a enormous business impact, we kept these documents classified in a "vault". We are talking about time-to-market for projects in the range of multi-billion dollar investments.



In your case, does it warrant the additional protection? If yes, any amount of work is just administrative necessity.

avatar
Dan Misra Executive Manager Data Projects| Westpac Group Cremorne, New South Wales, Australia
Personally, no I don't think this is advisable for 2 main reasons:
1. From a practical perspective, it would be complicated to manage dissemination and to control who sees which version, and it is possible that a team member would see a version not meant for them. It is better to write the risk management plan in a way that you would be comfortable with anyone in the team and outside the team reading it, subject to any NDA requirements. If there are potential sensitivities you could ask team members to review a draft to gauge reactions, and then make edits to take into account - and avoid - any unintended interpretations.
2. It goes against a principle of transparency, openness and trust in the team. If we don't know or trust our team members sufficiently to feel comfortable with them reading the risk management plan, such that we need to make a different sanitised version for different team members, then we need to self-examine to check our approach and our relationship with team members. I realise this is easier said than done though, especially as I am unaware of your particular circumstances or scenario.
avatar
Kiron Bondale
Community Champion
Retired | Mentor| Retired Welland, Ontario, Canada
Phan -

This is where content in the risk register (not the RMP as that usually does not contain individual, specific risks) and the stakeholder register might overlap. The latter is normally considered a "for your eyes only" type document whereas the former isn't. However, if there are specific risks which you'd only want a limited audience to have access to, then yes, you'd want to control access at the individual risk level. This is possible when using a PM information system which has item-level access control but not when using a document-based approach. In that case, multiple risk registers might be required and there is always the risk of data inconsistencies between different instances.

Kiron
avatar
Keith Novak Tukwila, Wa, USA
There are many types of information that may require restricted access whether by internal policy or law. It is often not discretionary and a cost of doing business. That can include things like financial data, trade secrets, info covered by export requirements, HR information, internal or external supplier data, etc. The type of security measures can vary from just document marking, to physical access controls such as mentioned by Jason.

When not using access controlled systems like Kiron describes, then a variety of process controls may be used. Not everyone needs access to the entire list so an Excel file may be limited using passwords, secure servers, etc., and filters applied for a variety of information classes. Individuals without full access may be sent extracts that pertain to their specific needs.

When discussing the risks in meetings, the first part of the meeting can be general access and at some point you may politely request that non-authorized persons leave the meeting for the limited access portion. In other cases attendance of the entire meeting may be restricted and held in secure locations, virtual attendance prohibited, no electronic devices allowed, etc.
avatar
Varun Jayaraman PMO Manager| Technology Services North Vancouver, British Columbia, Canada
I agree with Kiron that details about stakeholder engagement need to be in a stakeholder register, which is not shared widely. I would be against maintaining two separate risk logs, ensuring it's shared with the right audience at the right time is an unneeded risk that can potentially impact team morale, performance and ultimately project outcomes. Team member engagement is a PM responsibility more than other team roles. Notes about specific people should should be stored privately by the project manager and resolved as appropriate (coaching, mentoring, 1:1 sessions and/or escalations etc.)

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Humanity has advanced, when it has advanced, not because it has been sober, responsible and cautious, but because it has been playful, rebellious and immature."

- Tom Robbins

ADVERTISEMENT

Sponsors