Risk management is often considered a project management function, but that is not necessarily so. For any sort of endeavor we will be well served if we have some consideration of risk and the management. For example, our previous blog posts discussed configuration management. We saw how a wayward configuration management (or lack of configuration management) system subjected the work to additional risk that needn’t have occurred. In our testing example, we consumed many more hours than required for the work. In our software developer example, we see to recover previously working source code took unplanned hours and frustration to resurrect.  We can see from that perspective that configuration management is a risk diminishing activity. Risk alleviating – as in reduces the risk.  Risk management consists of the actions listed below.

• Identify risks
• Assess the risks
• Develop plan for risk responses
• Monitor for symptoms
• Invoke risk responses

We identify risks that can occur based upon the scope of the work. For example, if we have no software, then we have no software risks.  From a project perspective, our work breakdown structure provides some clues to what can go astray. We should not short-change the experience of our team–we should learn from those previous events about how things went awry.

We have a number of ways to assess risk.  We really want to be able to predict the probability and severity of any risks we identify.  All risks are not created equal but deserve equal scrutiny.  What is deemed “too risky” is relative and depends in part on the level of risk aversion of the person or organization?  Quantifying the risks in some way allows us to prioritize those risks that are the most damaging or most probable. There are typically two techniques each with strengths and weaknesses.  We list these assessments below and will discuss further in the upcoming blogs.

• Qualititative Risk Assessment
• Quantitative Risk Assessment

After we have assessed and prioritized our risks, we will then generate ways of controlling (or eliminating) the impact of the risk.  For those risks we cannot eliminate, we will search for risk reduction actions. We will identify actions we can take to reduce the severity or the probability of the risk happening.  We will also identify the leading symptoms associated with the impending risk and assign people the responsibility for monitoring the risk symptoms. We say leading symptom because we want to address the risk before it becomes a certainty. In this way, we are able to deliver our defined risk reduction actions quickly upon realizing that the risk is imminent.  It is imperative once the risk responses are identified that we constantly monitor for signs of the risk so we can invoke our responses. The failure do this action is surely one failing point of many a project.