“What is quite unlooked for is more crushing in its effect, and unexpectedness adds to the weight of a disaster. The fact that it was unforeseen has never failed to intensify a person’s grief. This is a reason for ensuring that nothing ever takes us by surprise. We should project our thoughts ahead of us at every turn and have in mind every possible eventuality instead of only the usual course of events.”

Seneca, Letter from a Stoic

I have always thought it a shame that philosophy isn’t given the same priority in science and engineering programs as other subjects, calculus for example. When I was an undergraduate, the first class computer science majors were required to take was an introduction to philosophy in order to teach us logic and reason. We didn’t really study the stoics, but Seneca has captured well the purpose and process of risk management. It is all right there in that nice succinct paragraph, but this is a blog and I have to do more than plagiarize a paragraph from a first-century Roman philosopher. So, let’s look at how this applies to project management.

I would like to continue our discussion of the RAID log; focusing our attention on the “R”, the risk register. The risk register is an output of the Risk management process which is the process that forecasts and evaluates project risks. The purpose of risk management is to reduce the occurrence of events that will negatively impact the project as well as minimize the impact of those events that do occur. As Seneca tells us, an unanticipated issue is more crushing than one for which we have prepared. The unexpected nature of it, the inexplicability of its occurrence, the scramble of trying to find a solution only amplifies the impact it has on the project. In order to avoid this, project managers should look into the future to anticipate what issues may occur and plan for them in order to keep the project on track. This is risk management.

Some may argue that risk management is part of a waterfall approach; it is contrary to the principles of an agile methodology. After all, agile is about not having documentation. The team comes together every morning, sings kumbaya, and since we are all experienced professionals with cutting edge skills all possible problems magically disappear like donuts in the coffee room. As is evident from my snarky description, I disagree. I would argue that agile is NOT about a lack of documentation and, due to the dynamic nature of an agile approach, risk management is all the more important.

The following is a basic structure for a risk register;

1. Risk ID – Unique ID to identify the risk
2. Probability – The likelihood of this risk becoming an issue
   1. High (Weight = 3) – A greater than 70% probability of occurrence
   2. Medium (Weight = 2) – Between 30% and 70% probability of occurrence
   3. Low (Weight = 1) – Less than 30% probability of occurrence
3. Impact – Indicates the impact of the risk if it were to become an issue
   1. High (Weight = 3) – Has the potential of causing the project to fail
   2. Medium (Weight = 2) – Has the potential of significant negative impact, such as not being able to deliver a required functionality, or relatively on time
   3. Low (Weight = 1) – Has little impact, such as not being able to deliver optional functionality or slightly less than optimal performance
4. Priority – Probability Weight times Impact Weight
5. Track – The project track that will be affected; i.e. Installation, ETL, Report Design…
6. Planned Response – The response to the risk
   1. Avoid – Eliminate the threat by eliminating the cause
   2. Mitigate – Identify ways to reduce the impact of the risk
   3. Accept – Nothing will be done
   4. Transfer – Make another party responsible for the risk
7. Description – A detailed description of the risk
8. Opened By – Name of the team member that identified the risk
9. Data Opened
10. Owner – Name of team member responsible for managing the risk
11. Status – Current status of the risk; Open, Closed, Deferred.
12. Comments – Any additional comments

The key feature here is the priority, which is the probability multiplied by the impact. The risks with the greatest priorities receive the most attention. In this example, I used just three level for both the probability and impact. In the past, I have used more levels for each metric in order to be more precise in my forecasting. It depends on what works best for your project.

The risk register should be monitored on a regular basis with the team, monitoring status and adding new entries to the log. There are several methods you can use to compile possible project risks; brainstorming, the Delphi technique, and interviewing. As I have written in the past, risk identification provides team members an opportunity to voice their concerns about the project. Also, in the projects I have managed, RAID log reviews happen at least once a week. Therefore, I prefer the less obtrusive brainstorming method. The team can range from the entire project team for small projects to tech leads for larger projects. During the session participants evaluate previous entries into the risk register as well as adding any possible risks that may have come to light since the last review.

I cannot emphasize the importance of team collaboration on risk identification and mitigation. Slightly rewording Linus’s Law; Given enough eyeballs, all risks are shallow. By collaborating with the team, we are able to have a more exhaustive list of risks as well as better developed mitigation plans. More importantly, this continuous dialog develops the group’s problem-solving skills; skills that can be leveraged when an issue that has not been anticipated occurs.  Ultimately, this helps forge bonds among professions that enable them to work more effectively towards a common goal.