Project Risk Management: Identify and Prevent Risk Issues

Project Risk Management: Identify and Prevent Risk Issues
By Ramkumar

Prevention is better than cure. Yet we often find that our focus is mainly towards issue resolution but not in its prevention. What are Issues?

Do issues occur in a project because of ineffective risk management practices or in other words can issues be prevented or eliminated in a project by proactive risk management? I opine that however good risk management practices are in a project, issues are bound to occur. There will always be some risks that are hard to detect because of our lack of knowledge in that area and these risks manifest themselves during project execution as issues and influence the course of the project. We can prevent issues from recurrence by analyzing and identifying the appropriate risk category they belong to and recording the risk category in the organization’s Risk Breakdown Structure (RBS) repository.

Causes of Risk Issues

Figure 1: Main Causes of Risk Issues
Issues are caused due to various reasons as depicted in Figure 1 above:

  • Risks Accepted – Project teams accept certain risks with the belief that the impact will not be high. In some circumstances there may be no other option but to accept the risk.
  • Risk Seepage – Occurs because of sheer oversight. Risks are identified, analyzed but not monitored or tracked properly.
  • Ineffective Risk Mitigation Measures – Risks are monitored and tracked but the mitigation measures fail to dampen the impact.
  • Unidentified Risks – Risks that couldn’t be identified due to lack of knowledge. For example, assuming that the Project sponsoring organization and performing organization are working together for the first time, a common scenario could be:
    • The sponsoring organization usually takes a long time to provide inputs or signoffs which may result in a schedule slippage. The Performing organization project manager may not be aware of this risk.
    • Similarly, the performing organization is usually good in technology but doesn’t understand the business or domain and the sponsoring organization project manager may not be aware of this fact.

At every milestone in a project, the Project Manager should analyze which of the four categories mentioned yields the maximum number of issues and fine tune the appropriate risk management activity. Root cause analysis needs to be carried out for each issue and the source or reason which caused the issue should be classified appropriately. If the underlying data is simple, a basic histogram can help us identify the category which gives rise to the maximum number of issues. For example, from the sample histogram shown in Figure 2 below one can deduce that the Risk Identification needs to be strengthened.

Risk Issues by Causes

Figure 2: Risk Issues by Causes
A typical issue occurrence to resolution cycle adopted in most projects is as indicated in Figure 3 below but seldom is enough emphasis laid on Issue Prevention activities. Walking this extra mile to prevent issues will immensely benefit the project and organization (Issue prevention or reduction improves project profit margins).

Risk Issue Resolution Cycle

Figure 3: Risk Issue Resolution Cycle

Ramkumar is a certified PMP since Jan 2007. He works for i-flex solutions which is recently renamed to Oracle Financial Services Software Limited. Ramkumar manages medium to large projects in the BFSI space and enjoys thinking, mulling and exploring ideas at work. He can be reached at ramkumar.krishnamurthy@iflexsolutions.com or krkumar06@gmail.com. Note: The thoughts and opinions expressed in this article are his own and don’t reflect those of his Organization.

PMHut Team

PMHut Team

PMHut.com is a website dedicated to providing PM articles, detailed project management software reviews, and the latest news for the most popular web-based collaboration tools.

2 Responses

  1. Avatar Vinny says:

    Hi Ram,

    The drafted process looks great in proactively understanding the Risks which are gonna exist all through the Project Cycle. Keep it going…

    My thoughts around it, When we are talking about Risk Management, it would also help having an understanding on where to place the kind of risks which we are certain to face in a project cycle.,

    Eliminate – Should we completely avoid it?
    Reduction – Can we reduce the impact of risk?
    Transfer – Can it be transfered to someother party?
    Retention – Can it be accepted?

    This even implies even on my domain of RIM,where we go for a transition to Onsite, we would wanna understand what can be taken over from the client and can be done back from India.

    For example:

    I go for a UNIX transition, where in I am supposed to transition work from Onsite to Offshore. I would wanna understand few things like.,

    – Can all servers be supported back from here in India. If not can we eliminate the servers from the support, rather than carrying the Risk of affecting your own SLA.
    – If client insists on taking over the servers, will I able to reduce the impact by taking a waiver for those servers from the SLA.
    – If client insists on equal treatment of the servers, can I transfer those particular servers to a local vendor to support
    – If none of the above work, understanding the facts on the level of work/trend of incidents, we can decide on whether to retain or eliminate the servers.

    Cheers,
    V

  2. Avatar Srinidhi says:

    Hi Ram,

    Nice write-up!! As organizations increasingly look to IT vendors to manage project risks effectively, it is becoming very important for the vendor to thoroughly understand the risk management process that is applicable to the client’s business. Some of the very pertinent risks that I have come across in Software projects include:

    1. Unclear requirements till well into the development phase: It is a risk to the project if this is not accepted as a risk :). This is inevitable.
    2. Unclear SLA numbers: This mostly leads to ambiguity in large deals.
    3. Non-uniform understanding of project risks among project members also proves to be a risk.

    Some of the typical categories for risks include technical, Project Management, External and customer centric. Irrespective of risk management techniques ranging from Checklists to Checkpoints, risks are an integral part of any project and are here to stay. Just my two cents!!

    Regards,
    Srinidhi

Leave a Reply