"A little risk management save a lot of fan cleaning."
Here's a nice thought: you're going on holiday. But what might take the edge off your week of bliss?
And we could all list a dozen more risks whose consequences range from minor inconvenience to major disaster.
Let's look at the first risk on the list above and consider how we might address it:
Forget tickets, money or passport
The list of things to take should help avoid the problem of forgetting something. But if in spite of this you still forget your passport, you've got a big problem - they won't let you on the plane. It's not very likely you'll forget your passport but if you do the impact will be high.
If your passport is stolen while you're getting crisped on the beach, that photocopy in your suitcase should get you back into the country without too much hassle. You haven't avoided the risk of having your passport stolen but you have mitigated the consequences.
If your camera is stolen you can claim on the insurance. Your camera has gone along with all your pictures but at least you've managed to transfer the financial loss to someone else.
Let's consider another of the risks and how we might address it:
If one suitcase goes missing at least you've got half your stuff. If all your luggage goes astray would that have a high impact on your holiday? It depends. If it's a skiing holiday a bit of a disaster. If it's a naturist holiday not so much of a problem.
The plane crash risk is very unlikely to happen though rather high impact if it does. In practice you'd probably accept/ignore this risk.
We've seen how some risks can be avoided, some mitigated, some transferred to others and some accepted/ignored.
Suppose you run a company and it will go out of business if you do not comply with new legislation. That is rather obviously a risk to your business. So you establish a project to do whatever is needed to comply with the legislation. The resolution of the business risk becomes the benefit side of the project business case. The project may be simple and easy to complete in the required time: we have a low risk project solving a high business risk. But if by contrast the project is large, complicated and very hard to do in the time available we have a high risk project attempting to solve a high business risk and the Board may want to give the project a lot of assistance.
Equally, a minor business problem could be addressed by a project that is high risk. There is no significant business risk but the project manager has a high risk of failure. Business risk and project risk are different things.
And there is another category. Imagine your project develops a new IT system but your project actually finishes just before implementation. There is clearly a risk that the system might not work, but is that a project risk or not? You could argue that it isn't a project risk since it happens after the project has ended. However, your project makes a commitment - whether explicitly or implicitly - that the project's product will work when it goes live. The project manager would be wise to consider failure to meet this commitment as part of the project risk assessment.
In this chapter we are primarily considering project risk, that is things that might cause project failure:
Though "risks" can also go the other way: that techie you're going to hire may be twice as good as expected and the "risk" is that he does the work in half the planned time. Some say these "risks" (better called opportunities) should be assessed and monitored in much the same way as negative risks, to make it more likely they are exploited.
All of us have been on holiday many times so we all have in-built mental holiday risk checklists. But imagine you are asked to manage a project and you've never managed anything similar before. You'd have no idea what the pitfalls might be nor what to do about them. If you had a checklist, like the holiday risk checklist, that listed the things that had caused problems in previous similar projects, and what had been done to address those problems, that could be very valuable to you and help you deal with similar problems in your project.
Let us see how we might manage risks in projects. We will describe the process under these 5 headings:
You will notice that the initials form an easily remembered acronym: mmmmm.
If your project involves HR, Marketing, Finance and IT, only someone from those divisions can really tell you the risks their division poses to the project. Will they really be able to supply the promised resources? Will they really empower somebody to represent them and make decisions on their behalf? And only IT specialists can tell you how risky the proposed technology is.
Hold a half day risk identification meeting with representatives from all involved areas plus experts who you think will be able to help identify risks. Initially do not use a checklist. Ask everyone to articulate what they think could cause problems in the project - tell them beforehand you're going to do this so they give it some thought. List everything everyone mentions. Then - if your organisation has one - go though the risk checklist: that will probably highlight risks you hadn't thought of. Don't do it the other way round, don't go through the checklist first as that can limit people's thinking. (See the Appendices for an example of a risk assessment checklist.)
You now have a list of things that you think could cause problems for your project, i.e. risks. For each risk assess how likely is it to happen and how severe its impact would be. Avoid esoteric discussions on probability theory and percentages. Keep it simple. Beside each risk write High, Medium or Low under these two headings: probability and impact. For some risks you might decide you need an 'Unacceptably High' ranking.
Then re-order the list to show high probability high impact risks first - clearly these are the ones that represent the biggest threat to your success. Perhaps during the meeting you can devise ways of removing or reducing some of those risks. Where you can't, you might decide to assign risks to individuals to follow up.
Tools that employ risk weighting and calculate an overall risk score in an apparently scientific way may add value, but can obscure the fact that one single risk, which may not even be considered in the tool, can make the whole project a complete non-starter. Whatever techniques you use to assess, measure and understand the risks - brainstorming, checklists, tools - remember that the aim is simply to focus the attention of those involved in running the project on those things that are most likely to cause grief or even failure and ensure they do something about them. Complicated and mathematically elegant processes can cause one to lose sight of this. Similarly, don't clutter up the works with hundreds of things that are unlikely to happen and would have minor impact even if they did. List them (if you really must) but otherwise ignore them.
For very small projects risk assessment might involve getting the team together a week or so before you are due to make you commitments to focus their mind on risks. A half hour meeting in which you ask the team what they think are the risks and maybe to go through a simple checklist (see the Appendix) may be all that's needed. Though risk reduction may still be difficult.
For very large projects you may have much more formal processes, perhaps formal health and safety
risk assessments, and you may even employ consultants to assist if the company has no experience of projects
of that size and nature.
Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022
This book must not be copied either as is or in modified form to any website or other medium