Risk Management in a challenging situation serves as a platform, or a tool, for reducing stress and loss, and communicating possible solutions. In reality, we often have to deal with challenging situations. I give you below, a realistic scenario.

  • You are newly assigned to troubleshoot a highly visible project that has a fast approaching regulatory deadline. Several project milestones were missed before you were invited to troubleshoot. Your whole team is also new, with no personal knowledge of the project. In addition, the project team members have to work on other projects; they are only ‘borrowed’ by your project for a brief period of time.
  • You immediately make a list of the project activities that must be completed before going live and you realize that with the given resources, the project cannot meet its deadline. The budget is already spent and the budget approval is so slow that even if you ask for additional resources, they cannot be approved before the deadline.
  • But, you also realize that there are activities your team can complete by the deadline date—the service development, testing of the service, passing the project reviews (e.g., architecture, security), and implementing the code into the production environment. However, there will not be enough time to implement service support (e.g., to train service desk, write and approve service level agreements).

 

In the scenario above, it is obvious that the original project risk of not meeting the regulatory deadline was not well managed. Missing the deadline became a certainty and the organization has to face the consequences (e.g., eroding reputation, financial loss, legal issues).

Could the organization have deployed the service without the service support? What are the risks of deploying a service without service support? Possible consequences (of deploying the service without the service support) are users’ confusion and dissatisfaction, perhaps some exposure to security and privacy risks, probably low performance. The inherent risk (i.e., risk that is not mitigated) is probably still High.

I think that everyone would agree that deploying an IT service and not supporting the service is poor Service Management practice. An IT service is not operationally ready if its service support is not in place. Nevertheless, in the above context, it is a viable alternative. It is worthy of consideration to determine whether some measures can decrease the risk to Medium, or even to Low. 

You can consider temporary measures, for example, a time-window after the service deployment, during which the development team provides service support. Furthermore, all users can be provided a contact (in the development team). Within the planned time-window, your project team will design and implement service support and hand it over to the service desk. These measures can significantly reduce the risk, so the residual risk, that is, the risk remaining after all risk mitigation measures are implemented, can probably be reduced to Medium.

In the above scenario, deploying without service support is a viable alternative for not meeting the regulatory deadline, and will have to be communicated to the team and senior management and assessed. Risk management gives you the tool to assess challenging situations and recommend alternatives. Without effective risk management it is much more difficult, time-consuming and stressful to determine and communicate alternative solutions. We will discuss more about how to communicate and facilitate decision making in such a situation in the next column.

To conclude, effective risk management increases organizational ability to adapt to internal and external changes. As more and more organizations are facing ever-increasing pace, Risk Management is becoming ever important to the point that it may become an enabler of organizational agility.

 

Your rating: None Average: 5 (7 votes)
Anonymous (14/09/2011)

I am not quite sure what your point is here. You haven't shown how using risk management helps in this situation, you have just identified that you could deploy the service without service support.

I agree completely that effective risk management would normally prevent these problems, but coming in at the last moment with a new team, no resources and no time, is not risk management it is, as you say at the start, "troubleshooting". You are unable to deliver on time, so you are doing damage limitation, which is a good idea.

You say in the ingress "Risk Management in a challenging situation serves as a platform, or a tool, for reducing stress and loss, and communicating possible solutions".

I would say risk management helps prevent challenging situations by reducing uncertainty, and giving a fact based analytical basis for decision making.

Rubina Polovina, PhD (21/09/2011)

Thank you very much for your comment.

I agree that one of the important benefits of effective risk management is the prevention of challenging situations. This topic itself deserves a separate column.

In my September column, I gave an example of another important benefit of effective risk management; that is making troubleshooting and managing through a challenging situation easier, swifter, less stressful and less costly. Troubleshooting is, by its nature, wrought by uncertainty; risk management is a tool to deal with that uncertainty. Off the top of my head, I cannot think of any example of successful troubleshooting in an IT project that did not include risk management.

Simply put; organizations that have effective risk management are better prepared to deal with challenging situations. No organization can ever avoid and prevent all challenging situations (e.g., recessions, natural disasters). Can they?

In my October column, I will discuss how troubleshooting communication is easier and swifter in organizations that have implemented effective risk management.

I hope you find my response to your comment helpful.

Joe Barry (not verified) (21/10/2011)

I agree completely that effective risk management would normally prevent these problems, but coming in at the last moment with a new team, no resources and no time, is not risk management it is, as you say at the start, "troubleshooting". You are unable to deliver on time, so you are doing damage limitation, which is a good idea.