Pragmatic Risk Management

Risk is one of those things that we really don’t like but that we have no choice but to live with. In Joe Black’s words it is as certain as death and taxes. This level of certainty when you are at the program level should mean that teams are very good at dealing with it. However it is often not the case. Some teams take an extreme approach when managing risks. Either they do nothing to manage them, considering any issue as an unpredictable event, putting the endeavor and potentially the organization in an irremediable path for failure; or they attempt to develop true rocket science before they step up to manage them, causing an overhead which rests the speed and agility required for successful program outcomes. 

From my perspective, effective teams develop a pragmatic balance among those extremes. They keep in mind that the ultimate goal behind Risk Management is no other but to determine what may play against the project, so they can prevent it or at least decrease its impact; and at the same time determine what could play in its favor and try to make that happen.  A few principles can help the team to develop that pragmatic, balanced approach  for  dealing effectively with risks. 

Making it Visible – this is probably the most important principle that lies behind managing risk. It is all about visibility. It is all about making visible something that could go wrong. If it is not visible for the team, then no one will be able to do anything about it. 

Managing the Log – Team needs a single consolidated log of risks for the program or the project; it is the responsibility of the program/project manager to provide it, and to facilitate its management to the team members. The log should allow all team members to track the basics about a risk, as well as the response actions taken to solve it through time. A common practice is to develop a more holistic list called the D.A.I.R. log, which records not only risks but decisions, actions, and issues. Sometimes the differences among those are clear, sometimes they are blurry. What’s most important is to describe the situation in specific terms so the proper responses can be created and developed. If something is described too vaguely, you know something is coming, but you don´t really know what that is.  It can’t be resolved effectively. 

Community Input – several things can be considered risky for a project and they can come from virtually everywhere. This is why you do not want a risk log biased just by your single perspective or that of a sponsor. You want as many perspectives as possible, so you have the best line of sight possible around the endeavor. You will worry about prioritizing the risks later. Yes, this means you will have lots of risks in the log; there is no magic number, just keep in mind that more is better. To give you an idea about it, our current 2 year program for a Data Center Migration is arriving at 700 D.A.I.R Log items these days. This is an average of 29 items identified per month. 

First things first – the same level of attention can’t be devoted to every risk. It actually shouldn't. Risks with greatest chance of occurrence and with the worst impact should be thrown all the way up to the top. A simple way to do this is to have a scale (i.e. 1 to 10) for each variable (chance of occurrence and impact) and multiply both of them. Someone can probably say that there are more sophisticated approaches to risk rating. True, but most projects and industries won’t require a heavily statistical or elaborated approach, just a fair way to combine both variables to prioritize all risks.

Another useful tool is a flag to indicate if a risk must be reviewed at P.M.O. level or not. This allows Project Managers to record risks they can manage on their own, and also labeling for attention of the Program Management Office a few ones requiring attention from upper management. Periodic meetings will be hold by the Program Manager to review every item flagged for attention at that level. These flags can of course be changed as necessity arises or no longer exists. 

Keep walking – Risk Management is an ongoing effort through the entire life cycle of the Project. This is why periodic review meetings are a must. Risks need to be monitored. It is responsibility of every person opening a risk to keep it up to date, as circumstances change and responses are developed and executed. New risks should be logged as they appear; the ones solved or with no chance of occurrence anymore can be closed and kept for the records and lessons learned. 

Doing all this stuff sounds a bit annoying when you have a product, result, or service to deliver, but these tasks are one of the main reasons to have you as a Project Manager. If you fail to do so, you will pay a very high price. You may end up with nothing to deliver. And so the entire organization 

“Only what is monitored, can be prevented”                              

– Sergio Calvo.