Capturing Risks Accurately
Risks must be managed on a project, but in order to do anything to manage the risks they first must be captured accurately--everything else done about risks stems from how they are captured. And if they can be managed effectively, then the project will stay on track and on schedule. But if the risks are not managed well, then the project could easily be headed into a danger zone.
Identifying the risks is the job of everyone working on or connected to the project, but capturing them in order to manage them is the job of the project manager. The following steps will help give you a framework for capturing the risks.
What’s in a Name One of the first items to determine about a risk is the name that it will be known by. Depending upon how risks are managed in your project or organization, this name might be a very short field or it might be an unending amount of text to describe the risk.
In general, it is best to give the risk a short and easily identifiable name. Something along the lines of, “Resource limitations during coding” or perhaps “Requirements not well defined.” A name that is simple but still conveys the message of the risk will help everyone stay focused on what needs to be done in order to mitigate the risk (or exploit it if necessary). The name is often the first thing anyone sees on the risk; if it is confusing or incomprehensible, then they may just stop paying attention. The name is what will help you lead the discussion of the risk with the decision makers and stakeholders who need to understand the risk in order to support it as needed.
By Definition Once the name is decided upon, then the risk needs to be defined. This is the portion where you can write your book about what the risk is. The definition should include what will happen if the risk occurs or does not occur. The definition should include all of the research and thought that has gone into identifying and creating the risk. Because there may be a lot of information in the definition of the risk, it is very important to edit, revise and edit again so that the definition makes logical sense to anyone who reads it.
Sometimes new information is added to the risk, and that information should be carefully inserted into the definition of the risk instead of just an addition at the end. By incorporating the new information into the definition, you will be clarifying the risk. If someone has to read through all the information as it was added, it can be very confusing instead of edifying.
Worst Case Scenario The entire reason for managing risks is to ensure that if something needs to be mitigated, then it is. Unfortunately, this often means that you are giving people new tasks to help mitigate something when their task load is already full. In order to help the team understand why they need to work on mitigating a risk, they should be able to see the worst-case scenario related to the risk. This will help them understand what might happen if the risk is not mitigated. It may not do anything to lighten their load, but they will be able to see the importance of the tasks.
The worst case scenario may be a bit extreme at times, so the information about the risk should also include the most likely outcome both of what will happen if the risk is not mitigated and occurs--and also what will happen if the risk is mitigated successfully and the project benefits from the extra work being done in order to mitigate the risk.
Next Steps Once you have determined all of the above, then it is time to decide upon the next steps that need to be taken. It might be that you need to take the risk to a group of decision makers (i.e. the risk committee) and make recommendations, or you might be able to add tasks to the schedule to cover the risk and the potential outcomes. Some risks just need to be accepted and others can become their own small projects with resources, schedules and everything else. The steps you went through to identify the risk will help determine what the next steps are.
