Author: Neville Turbit

Overview

We sometimes forget that project related activities are not as clear to business people as they are to us. In particular risk management can be seen as a low key part of the project by some business people. I remember trying to organise a risk workshop so that we could put together a risk management plan for a project. I was told by the Sponsor,

“Can’t you just put together a risk plan on your own?”

This article will give you some ammunition to address that situation if you are having trouble selling risk management to your colleagues.

Why Risk Management

The answer may seem to be “for the obvious reasons” but sometimes the obvious needs to be spelled out. Consider this. If something goes wrong, you need to do two things.

To explain further, if a customer refuses to pay, there is a process which might include letters of demand followed by court action. The path is one well travelled. With each new refusal, you can work through the process. Some letters of demand may result in payment. Some court action may result in payment. Some may result in bankruptcy. Some may fail completely.

The key thing is that you have a process to follow. You know what to do when something goes wrong. There is a path to travel.

When I was younger and more foolish (as opposed to older and equally foolish) I raced cars. On one occasion while driving an open wheeler, I had a suspension failure on a high speed corner. The car barrel rolled a number of times before crashing into a barrier. The car was destroyed and I suffered a few injuries – fortunately nothing permanent – but one injury was severe grazing on the back of my right hand. I had been wearing a glove but it was completely torn away.

At first I didn’t know how I had done it. I later then realised that while upside down, I had hit a kill switch I had installed on the dash to cut off all power. While my left hand was on the wheel during the 3 or 4 rolls, my right hand had cut off the power and was thrown up over my head. It hit the track during a roll.

This was risk mitigation in action. I knew in advance that the biggest danger in a crash was fire, and to lessen the probability I should cut electrical power. In this crisis, the awareness of the action I should take kicked in somewhere in my subconscious and I mitigated the risk.

It may be a radical example but it is applicable to any project. If we think out the risks in advance, and have a process in place, we will not waste time dithering about how we might solve the problem. We have a process. We just need to apply that process. Think issue management. What is your process for solving issues? Is there an escalation process if you cannot resolve it yourself?

Risk Mitigation

Risk mitigation is about what we can do to lessen either:

Going back to our previous example of customer payment, it is about monitoring customer credit. It is about talking with our sales people and people in the industry to try and predict any upcoming problems with clients. It is about credit limits and approval to exceed those limits.

In day to day business matters, risk management is embedded. It might not be called risk management or even seen as risk management, but it is there. This is particularly so where there are financial impacts – either direct or indirect. An indirect financial risk may be the damage that can be done to the business if a faulty product cannot be removed quickly from the market. Businesses have product withdrawal plans; they have business continuity plans to lessen the financial impact of a catastrophic event. They may or may not have evolved from a risk management workshop and if one were held today, usually other business risks would be identified.

Project Risk

Are projects risky? Of course they are. A project exists because it is not something the business does on a day to day basis. There might be similarities with previous projects, and there might be a methodology to follow. Each project will however have many aspects that are different to previous projects. There are many new risks in a project that need to be considered. Even if the risk is the same as another project – e.g. key resource leaves the company – the people who will be required to respond may well be different.

Addressing Risk.

There are four actions you can take when a risk is identified:

Avoid the Risk

In this case, you find a way to remove the risk completely. If the risk is that a new material you are about to use may not provide the solution, don’t use the material. If a supplier may not be able to supply, use a supplier you know can supply. You cannot always avoid the risk, but it is a valid response in some cases. If you are NASA, or Boeing avoiding risk is fairly important.

Transfer the Risk

Another action is to transfer the risk to someone else. If you are not sure you have the expertise to handle something internally, have it managed by a specialist company externally. Build penalty clauses into a contract to give the supplier incentive to meet your deadline or have to pay for the delay.

Mitigate the Risk

Take action to lessen the probability or impact of the risk. If a key resource leaving is a risk, have a backup person in place. Offer them an incentive to stay until the project is complete.

Accept the Risk

It is a valid action to say

“We know it is a risk, but we accept it and will do nothing about it”.

We do this all the time in projects where the risk is both low impact and low probability. We cannot address every risk or we will never start the project. We have to be pragmatic and draw the line below which, we accept risks. There is a risk the bus or train will not arrive on time to take us to work. We usually accept this risk.

Other white papers on our web site ( http://www.projectperfect.com.au/ ) cover how to prepare a risk plan.

Risk Examples

In explaining risk to business people, it is useful to use a few examples. Here are a couple of personal experiences.

The Pregnant Key Stakeholder

During a risk workshop we identified loss of key resources as a risk. The mitigation was that a number of key resources would have an understudy and were responsible for ensuring the understudy could step in if required. We didn’t know at the time but one key resource had just found out she was pregnant. Although it was two months later before she announced the fact, she was able to prepare her backup to take over in the later part of the project. She said later that it was a great relief to her to know that something that she was not able to share with us was being addressed through the process. From the company’s point of view, the changeover caused minimal impact on the project.

The Supplier Company Failure

In selecting a software provider we considered the risk that for whatever reason, negotiations fail at the last point in the selection process due to the unsuitability of the organisation selected. The mitigation was to carry out due diligence earlier in the selection process than we would normally do. The main contender had a great product however while there were still a number of contenders, we carried out due diligence. We found the prime candidate had major financial issues and would likely fail or be taken over.

We were able to move on to another supplier and avoid selecting a company that might not be around in the longer term. The company in question was later taken over by another organisation and their product range phased out over the following few years. Whilst the new company dressed it up as converting clients to their applications, it was in fact a new project which would have involved considerable expense.

Rapid Growth

A company in the building industry had a unique product. They were anticipating rapid growth and were smart enough to have us do a risk assessment. One risk was the availability of suitably skilled installers if they grew too quickly. The mitigation was to outsource the installation to a number of subcontractors rather than have installers in-house. The rationale was that ten subcontractors who spent 20% of their time on the company installations was more flexible than two people full time in-house. The training effort was much higher but you now had ten people who could do the installation rather then two.

The company did go through a rapid growth, and some of the subcontractors were full time doing installations. Unfortunately the rest of the market caught up, and the demand dived. The flexibility of subcontracting also helped here as they did not need to put off their own staff. They merely scaled back the work to the subcontractors.

Data Centre Equipment

The project was to replace some servers in a data centre which were about to reach the end of their maintenance contract. The risk was that the supplier could not deliver the required new servers on time. We decided to transfer the risk to the suppliers. The contract for supply included the new supplier picking up maintenance responsibility at the end of the existing maintenance contract if the new servers were not in place. Twelve months out from the implementation date, this was seen as an improbable risk by the supplier. Twelve months later it was not so improbable. In fact the implementation occurred five months late due to a fire in the supplier’s factory. They had to pick up five months of maintenance at no cost to the data centre company.

Conclusion

These are just a few of the reasons why a risk management plan is important. In your own environment you can probably come up with a number of

“If we had anticipated this we could have done something about it.” situations.

Risk management is about spending some time before you start a project to work out what might go wrong, and if you should/can do something about it. Not all risks are evident on day one so the exercise does need to be repeated. Don’t just tell the people you are doing a risk assessment. Make sure they understand why, and the value to them of the exercise.

Copyright Project Perfect