Which one “Qualitative” or “Quantitative”?

In the last MGT 598 class, we talked about project risk management.  The risk management process can be summarized in these four steps: Identification, Assessment, Response and Control.  These are typical processes and were widely discussed in many project management literatures.  Most literatures discussed how to identify and evaluate risks with quantitative approaches. One of them is from Guy Merritt and Preston Smith.

Merritt and Smith first introduced a tool called the “Standard Risk Model”.  This tool is used to evaluate project risks based on “facts” because they are easy to quantify:

Standard Model

The Standard Risk Model

Source: “Techniques for Managing Project Risks” by Guy M. Merritt and Preston G. Smith

With this model, we will have objective measures for the likelihood of risks (Pe) and impact of risks (Pi).  We will also get an estimate for total loss, Lt.   The four project risk management processes mentioned before will fit in different pieces of the model.  Putting these pieces together will give us a complete picture of how to manage project risks.  The author also illustrated how to apply this mathematical model by case studies.  This tool seems great because all four risk management steps were integrated in the model.

However, when we manage project risks, is it always true to use measurable facts only?  Do we need to consider non-measurable but material risks to the organization, for example, operational inefficiency, employee morale and loss of historical data, etc?

A year ago, our company implemented a project to migrate our ERP system from JDE to Oracle.  We planned the project for a while.  We tried our best to identify possible risks and evaluated financial impacts associated with all risks.  One of the risks we identified was loss of historical data.  Although we understand the importance of keeping track of historical records, we were not able to move all data to the new system due to time and budget constrain.   The risk mitigation plan was to allow two employees to have read-only accessibility to JDE.   This way we not only saved data migration costs but also license fees on the number of users.  In the meantime, we are able to keep track of old records.  While this seems a perfect plan, it has risks itself.

First, read-only function is not supported by JDE.  If for any reason, we have technical difficulty that we cannot access to the system, we will not be able to login and retrieve data.  Second, limited accessibility is like putting all eggs in one basket.  If an employee leaves the company without transferring knowledge to the successor, it will be difficult to retrieve historical data in the old system.  What happened to us was the second case.  The two employees with accessibility to JDE were no longer with the company.  We wanted to retrieve 2013 sales data but we were unable to do so because nobody knew how to do it.

I was not sure if we had thought about the risk of losing talents before.  This obviously has negative impact to the financial planning team.  We were not able to use historical data to perform financial analysis.  Although the impact is not easy to measure, I believe this kind of risks should be considered in project risk management.  How does your company identify risks?  Do you consider both measurable and non-measurable factors?

 

Article link:

“Techniques for Managing Project Risks” by Guy M. Merritt and Preston G. Smith

http://www.strategy2market.com/wp-content/uploads/2014/05/Techniques-for-Managing-Project-Risk.pdf

4 thoughts on “Which one “Qualitative” or “Quantitative”?

  1. Great post, Kit. This made me think about a recent ERP migration at my company. I’m not involved with identifying risks at my company and I did not help plan the migration. Although, I did deal with the aftermath. It was quite the project changing over to Oracle. Similarly, some data from the legacy system did not transfer. Frustrations built for weeks until the old system was brought back on-line. So, for the time being, we’re working off of two systems. From what I understand, this problem was also a case of “putting all the eggs in one basket”. You raise some good questions because I too am curious how much the non-measurables factored into the risk equation.

  2. I really enjoyed this post and the real life examples of managing risk. This truly illustrates the importance of having a comprehensive risk management plan that incorporates all types of risks that a project may have. Working for a construction company, many of our risks may tangible and relatively easy to measure. As we develop risk assessments for our projects we list out these items first. We then go deeper into the intangible risks such as customer management, alternate utilization of resources, etc. It may seem easy to get carried away and list too many items, but as you mentioned in your post, things do happen and it is best to have accounted for them. So I would recommend to spend more time on the front end listing out as many risks as possible, and creating detailed steps on how to control or account for these risks.

  3. Great post! Two years ago my organization attempted to switch to using a different database system for correctional management. I say attempted because we also; 1) kept the old system as a read-only function (although we have since gone to adding information to the old system as well, basically running concurrent systems) and 2) There are only three stqaff members who are versed on how to use the old system. One of them has been with the organization for 42 years. The other two are obviously disgruntled employees who are a broken light bulb from turning in their resignations. There has been zero risk aversion to only having three “short for the company” employees with the keys to the old kingdom. Yet we are still using the old system because we are afraid of the risks involved with the new database. The quantitative risks have overshadowed the obvious qualitative risks involved.

    Hopefully, in the future we will list ALL of the risks before engaging in a major change.

Leave a Reply

Your email address will not be published. Required fields are marked *