Post navigation

As the first article in this series indicated, a top down approach as opposed to a bottom up approach will provide a solid basis for a success risk environment. This approach has 4 major steps:

Establish a solid risk management process from the project initiation

Discuss and reassess risk management often

Establish a collaborative environment

Ensure risks are documented as one of the five project constraints

It is now time to focus on the third step of this top-down approach: Establishing a Collaborative Environment. If your risk environment is established at the start of your project, the teams work collaboratively, processes are well communicated, resources are used wisely, the project team can address the risks that are truly affecting the deliverables and objectives.

A structured and collaborative risk environment from the start will encourage proactive communications. This environment should specifically aim to increase the success of the project team. Tools to improve the performance and effectiveness of our projects can include established reoccurring risk meetings, well established and communicated risk processes, consistent reporting and solid metrics showing risk status.

Risk communication lies at the center of any collaborative risk environment to ensure all stakeholders know how to identify a risk, update a risk, escalate a risk and identify a triggered risk. Without effective communications, no risk management approach can be viable.

In order to be analyzed and managed correctly, risks must be communicated to and between the projects within the portfolio. Communications must also provide information flow between the project and organization, to all stakeholders, and most especially to upper management.

Because communication needs to be pervasive, risk activities should be detailed in the Project’s Communications Plan. If the project is a large or complex, it is recommended that the Project Manager write a separate Risk Management Plan to detail the risk environment. The last article, “Discuss and Reassess Risk Management Often” discussed a detailed framework that should be in every risk program. In addition to the framework, how often the team should meet to discuss the risks, what reporting will be available to track the risks and what the roles and responsibilities are for each team member? These are all additional areas able to increase project success.

Risk Meetings: Risk discussion should be an agenda item in team meetings. The duration and how often should be determined by the complexity and size of the project, but risk discussions should be done at least once a week. Projects where the risk program is managed by the Project Manager and never discussed with the team will show signs of failure quickly as there will risks that are never identified. Projects that put the risk management on the shoulders of a risk analyst to manage will also show signs of failure as the management of each risk is not with the person that is most capable of mitigating that risk.

As a rule of thumb, here is a simple guide to follow when deciding how often risks should be addressed:

High Risks: At least weekly

Medium Risks: At least bi-weekly

Low Risks: At least Monthly

Issues: Daily*

*Triggers are critical to determine if a risk has changed from a future uncertain event to a certain real time event. Triggered risks should be responded to immediately. Contingency plans for your high risks should be reviewed to determine if they are still viable or if a new response plan should be effected.

Stakeholder Roles and Responsibilities: If stakeholders know their role and responsibility in the risk process, and manage risks they have responsibility for, the success rate for projects increase. Too many times, the risk process is done by one person in a vacuum void of key people that came provide valuable key information.

Key roles and their responsibilities within the risk framework:

Project Manager (PM): Overall responsible person for the project therefore has overight responsibility for each risk. The PM is responsible to ensure risks are discussed at project meetings, triggers are in place and risks are monitored. The PM should assign risk owners to each risk to further develop mitigation plans and identify triggers. The PM has the ultimate responsibility to approve new risks and close those eliminated.

Risk Owners (RO): Accountable for managing the analysis of assigned risks. ROs are accountable for the preliminary risk mitigation plan, or the preliminary issue response plan. They should ensure all risks and issues are added to the risk register and that it is maintained and updated. During team meetings, the RO should update the team on their assigned risks. The RO should be a Subject Matter Expert (SME) on their assigned risks.

Risk Action Owners (RAO): The RAO is the person the RO feels is the most qualified to implement the chosen strategy to mitigate the risk. For their assigned risks and issues, they should assist the RO in maintaining and upgrading these assignments.

Team Members: All team members have a responsibility to identify risk potentials and bring these risk potentials to the PM’s attention. All risk potentials should be considered.

Risk Source: The person who identified the risk

Clear, Communicated Processes: Processes for how to identify a risk, how to escalate a risk, how to identify triggered risks and assess a risk should all be clear and communicated to the entire team. When a team knows how or where to initiate a risk discussion this helps to mature the risk environment of the project.

Reporting and Metrics: The risk program is not static. Risks identified at the beginning of the project should not be the only risks in the risk register with no progress towards mitigation of these risks. Reporting should show ALL changes to the risk environment. Consistent reports will allow the project manager and the team to understand the risk environment and the critical changes needed. The trigger report will show risks that are liable to become issues thus allowing time to respond if needed.