In a large project the PM may choose to delegate risk management to a team member.
What information should be accessible to the Risk Manager? Should the RM have full access? Are there information that should be off limit? Saving Changes...
ISO 31000 family is a point of reference. IRM (Institute of Risk Management) documentation has helped a lot to me. About organizations, each one could have project risk management rules and plans defined so the first thing to do is searching for them.
Thanks for the clarification about ISO 31000 Sergio
Still intrigue about what information should not be available to Risk manager. If the role and responsibilities are to the project and the organization, what kind of risk one doesn't want to know about? Saving Changes...
I doesn't require to limit to the project risks but the project information. All project information might not be shared with a risk manager especially specific personal records, confidential information etc.
I can agree that some information about human ressource are confidential. But what else if any should or could be off limit? Saving Changes...
@ Vincent, If you are in construction domain, besides personal records of employees, there might be various types of confidential information before it becomes in public such as:
1. Contract negotiation with the client which might be affecting other projects or contractors, 2. Contract negotiation with the sellers / sub-contractors, or even with partners to share the opportunity, 3. Information, provided by the stakeholders, remains confidential due to information provider's request to do so, 4. Sensitive information for negative stakeholders, like detailed personal information, 5. Engagement or management strategies for extremely negative stakeholders including local residents and authorities, 6. Bidders' proposals and prices until the decision on qualified bidders is made before negotiation, 7. Others based on the performing organization's polices or on specific needs for confidentiality.
...
1 reply by Vincent Guerard
Dec 13, 2016 11:15 PM
Vincent Guerard
...
Hi Sungjoon,
Interesting Most of that I had access.
For the 6. bidders, you should make a risk assessment on the bidders! The company is financially solid to take on the basic risk that need to done often done by risk people.
I can agree that risk manager don't need some level of detail, but would know about the risk part.
Hello Vincent, I found this helpful. May not be complete answer to your question, but worth reading.
Twenty-One "Musts"
1. Risk management must be a priority for leadership and throughout the program's management levels. Maintain leadership priority and open communication. Teams will not identify risks if they do not perceive an open environment to share risk information (messenger not shot) or management priority on wanting to know risk information (requested at program reviews and meetings), or if they do not feel the information will be used to support management decisions (lip service, information not informative, team members will not waste their time if the information is not used).
2. Risk management must never be delegated to staff that lack authority.
3. A formal and repeatable risk management process must be present one that is balanced in complexity and data needs, such that meaningful and actionable insights are produced with minimum burden.
4. The management culture must encourage and reward identifying risk by staff at all levels of program contribution.
5. Program leadership must have the ability to regularly and quickly engage subject matter experts.
6. Risk management must be formally integrated into program management
7. Participants must be trained in the program's specific risk management practices and procedures.
8. A risk management plan must be written with its practices and procedures consistent with process training.
9. Risk management execution must be shared among all stakeholders.
10. Risks must be identified, assessed, and reviewed continuously not just prior to major reviews.
11. Risk considerations must be a central focus of program reviews.
12. Risk management working groups and review boards must be rescheduled when conflicts arise with other program needs.
13. Risk mitigation plans must be developed, success criteria defined, and their implementation monitored relative to achieving success criteria outcomes.
14. Risks must be assigned only to staff with authority to implement mitigation actions and obligate resources.
15. Risk management must never be outsourced.
16. Risks that extend beyond traditional impact dimensions of cost, schedule, and technical performance must be considered (e.g., programmatic, enterprise, cross-program/cross-portfolio, and social, political, economic impacts).
17. Technology maturity and its future readiness must be understood.
18. The adaptability of a program's technology to change in operational environments must be understood.
19. Risks must be written clearly using the Condition-If-Then protocol.
20. The nature and needs of the program must drive the design of the risk management process within which a risk management tool/database conforms.
21. Risk management tool/database must be maintained with current risk status information; preferably, employ a tool/database that rapidly produces "dashboard-like" status reports for management.
Markus KopkoAI Enabler for Project & Program Mgmt | Founder PMotion.ai / The PM
AI Coach| PMotion.aiHamburg, Hamburg, Germany
Dec 12, 2016 11:51 PM
Replying to Anupam
...
Hello Vincent, I found this helpful. May not be complete answer to your question, but worth reading.
Twenty-One "Musts"
1. Risk management must be a priority for leadership and throughout the program's management levels. Maintain leadership priority and open communication. Teams will not identify risks if they do not perceive an open environment to share risk information (messenger not shot) or management priority on wanting to know risk information (requested at program reviews and meetings), or if they do not feel the information will be used to support management decisions (lip service, information not informative, team members will not waste their time if the information is not used).
2. Risk management must never be delegated to staff that lack authority.
3. A formal and repeatable risk management process must be present one that is balanced in complexity and data needs, such that meaningful and actionable insights are produced with minimum burden.
4. The management culture must encourage and reward identifying risk by staff at all levels of program contribution.
5. Program leadership must have the ability to regularly and quickly engage subject matter experts.
6. Risk management must be formally integrated into program management
7. Participants must be trained in the program's specific risk management practices and procedures.
8. A risk management plan must be written with its practices and procedures consistent with process training.
9. Risk management execution must be shared among all stakeholders.
10. Risks must be identified, assessed, and reviewed continuously not just prior to major reviews.
11. Risk considerations must be a central focus of program reviews.
12. Risk management working groups and review boards must be rescheduled when conflicts arise with other program needs.
13. Risk mitigation plans must be developed, success criteria defined, and their implementation monitored relative to achieving success criteria outcomes.
14. Risks must be assigned only to staff with authority to implement mitigation actions and obligate resources.
15. Risk management must never be outsourced.
16. Risks that extend beyond traditional impact dimensions of cost, schedule, and technical performance must be considered (e.g., programmatic, enterprise, cross-program/cross-portfolio, and social, political, economic impacts).
17. Technology maturity and its future readiness must be understood.
18. The adaptability of a program's technology to change in operational environments must be understood.
19. Risks must be written clearly using the Condition-If-Then protocol.
20. The nature and needs of the program must drive the design of the risk management process within which a risk management tool/database conforms.
21. Risk management tool/database must be maintained with current risk status information; preferably, employ a tool/database that rapidly produces "dashboard-like" status reports for management.
@ Vincent, If you are in construction domain, besides personal records of employees, there might be various types of confidential information before it becomes in public such as:
1. Contract negotiation with the client which might be affecting other projects or contractors, 2. Contract negotiation with the sellers / sub-contractors, or even with partners to share the opportunity, 3. Information, provided by the stakeholders, remains confidential due to information provider's request to do so, 4. Sensitive information for negative stakeholders, like detailed personal information, 5. Engagement or management strategies for extremely negative stakeholders including local residents and authorities, 6. Bidders' proposals and prices until the decision on qualified bidders is made before negotiation, 7. Others based on the performing organization's polices or on specific needs for confidentiality.
Hi Sungjoon,
Interesting Most of that I had access.
For the 6. bidders, you should make a risk assessment on the bidders! The company is financially solid to take on the basic risk that need to done often done by risk people.
I can agree that risk manager don't need some level of detail, but would know about the risk part. Saving Changes...
Hello Vincent, I found this helpful. May not be complete answer to your question, but worth reading.
Twenty-One "Musts"
1. Risk management must be a priority for leadership and throughout the program's management levels. Maintain leadership priority and open communication. Teams will not identify risks if they do not perceive an open environment to share risk information (messenger not shot) or management priority on wanting to know risk information (requested at program reviews and meetings), or if they do not feel the information will be used to support management decisions (lip service, information not informative, team members will not waste their time if the information is not used).
2. Risk management must never be delegated to staff that lack authority.
3. A formal and repeatable risk management process must be present one that is balanced in complexity and data needs, such that meaningful and actionable insights are produced with minimum burden.
4. The management culture must encourage and reward identifying risk by staff at all levels of program contribution.
5. Program leadership must have the ability to regularly and quickly engage subject matter experts.
6. Risk management must be formally integrated into program management
7. Participants must be trained in the program's specific risk management practices and procedures.
8. A risk management plan must be written with its practices and procedures consistent with process training.
9. Risk management execution must be shared among all stakeholders.
10. Risks must be identified, assessed, and reviewed continuously not just prior to major reviews.
11. Risk considerations must be a central focus of program reviews.
12. Risk management working groups and review boards must be rescheduled when conflicts arise with other program needs.
13. Risk mitigation plans must be developed, success criteria defined, and their implementation monitored relative to achieving success criteria outcomes.
14. Risks must be assigned only to staff with authority to implement mitigation actions and obligate resources.
15. Risk management must never be outsourced.
16. Risks that extend beyond traditional impact dimensions of cost, schedule, and technical performance must be considered (e.g., programmatic, enterprise, cross-program/cross-portfolio, and social, political, economic impacts).
17. Technology maturity and its future readiness must be understood.
18. The adaptability of a program's technology to change in operational environments must be understood.
19. Risks must be written clearly using the Condition-If-Then protocol.
20. The nature and needs of the program must drive the design of the risk management process within which a risk management tool/database conforms.
21. Risk management tool/database must be maintained with current risk status information; preferably, employ a tool/database that rapidly produces "dashboard-like" status reports for management.
