Menu
Menu
A risk management implementation

A risk management implementation

Identify, manage and effectively communicate risks

As project managers, we have our hands full with the day-to-day management of our initiatives, and it is difficult enough to keep a lid on all the tactical actions that are taking place, let alone plan for the future. Nonetheless, we all know that planning is a key element to project success. Most successful project managers are effective because they simultaneously balance the immediate challenges and demands facing them with future needs, opportunities and risk-avoidance. In particular, they are able to do so because they identify and communicate these elements at the right levels throughout the organisation.

How do successful project managers remain successful in their day-to-day work while spending only the minimum amount of effort directed towards long-term ends?

The answer: A specific risk management strategy which can be simple to implement and can directly help to improve one’s ability to identify, manage and effectively communicate risks.

What is ‘risk’ and ‘risk management’?

According the PMBOK®, risk is an uncertain event that can be either positive or negative. Additionally, risk management is, “… the systematic process of identifying, analysing, and responding to project risk”. Risk management incorporates various processes. Models differ. For example: Risk planning, identification, qualitative analysis, quantitative analysis, response planning, and monitoring and controlling. While risks are ‘uncertain’ events that have not yet occurred, an issue is an event that has already transpired. A trigger is an indication that a risk is about to or has occurred, and is usually based on parameters that have been ‘set off’.

Before delving into the details of a risk management implementation, a few aspects of risk must be discussed. Firstly, by definition projects are the creation of a unique entity; therefore, a certain amount of risk will always be present. Secondly, one must acknowledge that risk is not bad. As discussed in a previous article called <i>Risk management and project management go hand in hand</i>, when managed effectively, risk control can yield positive outcomes for project managers and their project. While some consider risk to be intrinsically negative, risk outcomes can be positive. Such positive risks, or opportunities, as they are commonly referred to, are the events you seek to act upon to create a net positive impact on your project.

When the goal is the identification of project risks, it is helpful to categorise them; when does this risk arise and where is likely to have impact? For instance, is the project risk sourced within technical, quality, schedule, or resource aspects of the project? Balancing risk categories can help provide greater assurance that one is being effective when examining various areas of the project.

Risk management implementation: Risk register

The tool or risk register (in this case, a Microsoft Excel Spreadsheet) provides a mechanism for capturing project risks and issues, yet also covers all of the PMBOK® KPA processes, with the exception of risk planning. We suggest risk planning can be covered within one’s project management plan. The planning component within the risk management plan can be relatively short (summarised within a couple of paragraphs) by referencing the self-contained risk register, identifying the methods for updating the risk tool, and communicating the risks and issues from the risk tool.

As stated previously, we choose to manage some project risks via a spreadsheet template (see diagram).

As shown above, each of the processes is included within the spreadsheet (or risk register), with the exception of risk management planning. The idea is that each horizontal entry represents one risk or issue. If it is a risk, the format for capturing it is in a specific format: “IF BY THEN ”. Because risks are uncertain events, it is useful to state them in this format so that the point at which this risk may become an issue is clear. Note: Not all risks become issues; that is part of their inherent uncertainty.

As part of risk identification, we also capture the date on which the risk was identified and the category to which the risk belongs. Risk identification has been shown to be a significant part of risk management in that it makes one aware of potential events or issues that may impact the group.

Following this, we want to quantity and qualify the individual risk itself. Many organisations use a ‘risk matrix’ to control this (e.g. magnitude and likelihood). The mechanism employed here multiplies the probability of risk (value between 0.0 and 1.00) by the impact of the risk if it were to become an issue (values range 1 to 100). This produces a risk event number (REN), a way of ascribing a value (one to 100) to each risk. Depending upon your organisation’s preferences, you may consider color-coding the REN cell (clear, yellow, red) as a means of drawing attention to high-probability, high-impact risk.

Additionally, this mechanism enables users to collectively sort all of the risks, allowing them to recognise at any point how close any particular risk is to turning into an issue. It also allows users to sort and compare project risks.

Continuing left to right, the next field is labeled “Mitigation”. Within this field, we want to capture our risk mitigation plans. This requires that we look ahead, consider and plan as to what we will do to manage our risks and their potential progression to becoming issues. We find that having multiple plans in place helps to maintain a balance as to how we’ll manage our risks. To this end, we prefer to categorise the plans as either mitigate, monitor, encourage, or accept.

The last two fields include the risk owner (the person primarily responsible for the risk) and a running status of the risk. The latter should be updated each time the risk status is changed, so that one has a history log for all the risks.

Maintaining and reporting

Through the process of periodic evaluation and review of the risks (e.g., PM to review risk register with entire team on a monthly basis), and updating issues and risks individually when necessary, the risk register becomes a ‘living’ record. This includes the current potential for a risk becoming an issue (via REN), as well as its current owner and status.

Additionally, reporting top risks (via sorting of highest value REN) allows team members, customers, and senior staff/sponsors to quickly notice potential issues that could impact a project, as well as develop plans to deal with associated risks and issues (via the risk mitigation plan section).

Tools for decision-making are essential

While risk management is far more than maintaining a risk register, the tools for making decisions are essential. We hope that by using the tool discussed and its implementation it will prove to be useful for providing a framework in which project managers can successfully manage project risk.

Gareth Byatt, Gary Hamilton, and Jeff Hodgkinson are experienced PMO, program, and project managers who developed a mutual friendship by realising they shared a common passion to help others and share knowledge about PMO, portfolio, program and project management. In February 2010, they decided to collaborate on a three-year goal to write 50 PM subject articles for publication in any/all PM subject websites, newsletters and professional magazines/journals. They can be contacted at Contactus@pmoracles.com


Other articles by these authors:

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.

More about ExcelMicrosoft

Show Comments

Market Place

Computerworld
ARN
Techworld
CMO