Project Management Book

...chapter 5 continued

4. Monitor

We've assessed the risks, reduced them where possible and told the sponsor how great the residual risk is, i.e. how big a risk he is running by deciding to do the project.

And the sponsor has said: "I hear what you say, I understand all those risks but succeed in spite of them." At this point don't go off in a huff, put in place things that will make sure the risks are managed down as you go through the project. Don't just log the risks and forget them.

Don't try and manage hundreds of minor risks. Focus on those most likely to cause significant problems. Assign each of these risks to someone in the team: it's their job to ensure the team does whatever is needed to reduce that risk as we go along. For example, if we will need a technical specialist in 3 months but they are hard to come by, one way of reducing the risk might be to ring the agency every fortnight to remind them of our requirement.

In weekly team meetings risk owners report briefly on the status of the risks they are looking after: what is being done, what needs to be done to keep the risk at bay. These actions could be pre-planned or involve the use of contingency time and money. In a smallish project the team members would report risk status direct to the project manager in the weekly meeting. In a larger project the reporting might be to the team leaders in their weekly team meeting and the team leaders report on the more significant risks to the project manager.

Perhaps in our example the team leader reports there are now plenty of those technical specialists available. Or he might report there is no prospect of finding someone in which case you might decide to trawl the world for that expertise and prepare to spend a slice of your contingency to pay for it.

Once a month the project manager tells the sponsor the status of key project risks. More on reporting in a later chapter.

In very large projects with many significant risks it may be appropriate to employ a risk manager who does nothing other than help the project manager manage the risks.

Of course, new risks can crawl out of the woodwork as the project progresses - if they are significant add them to the risk register.

5. Modify

Some organisations have a Project Support function (more later). At the end of each project stage they ask the project manager what problems they encountered that they hadn't foreseen. And when someone trips over a risk that isn't on the organisation's risk checklist what do project support do? Add it to the checklist so the checklists evolve to reflect risks actually being encountered. Checklists because there could be several: hardware projects have different risks to software projects, so there could be a risk checklist for each type of project the organisation undertakes.

And if project support are smart they'll also ask: how did you deal with the problems or, with hindsight, how would you deal with similar problems next time? Project support collect these successful ways of dealing with risks and produce something like the holiday risk checklist - what might go wrong and what might avoid or mitigate those risks. This means that new project managers don't all have to learn about risks the hard way.

Project Management Course

Monte Carlo

People have tried to devise elaborate mathematical risk assessment procedures. You answer a thousand questions, the tool whirs and clicks and comes out with a risk score - 63.724%. This can be very misleading: the scoring can obscure the fact that one risk actually makes the project a complete non-starter (and that specific risk may not even be considered in the tool). With checklists and tools there is a tendency just to consider the risks that happen to be listed. They also encourage averaging: you have a list of 20 risks, 6 high, 8 medium, 6 low - what's the overall risk? The temptation is to say medium. But again, one of those high risks could make the whole project too high risk to contemplate. Don't arrive at the overall risk by averaging. Projects are all different, no checklist will ever have on it all the risks your project faces. Risk assessment is a brain-in-gear activity, it is not about filling in a checklist and filing it away.

Some projects and manufacturing processes lend themselves to techniques such as EMV and Monte Carlo simulation. With EMV, the probability of a risk happening is multiplied by the cost if it does happen and the resulting amount of money (expected monetary value) put into the budget. So, 10% chance of a £1M problem biting, £100K goes into the budget. If you had ten such risks you'd have a £1M contingency pot. The chances are one risk will happen and nine won't and the £1M covers the one that happens.

Monte Carlo works like this: each task in the project is given a probability of happening anything between, say, 50% early and 200% late. A computer simulates the execution of the project many times, each time using statistical techniques for deciding how on time or otherwise each task will be. Sometimes the simulation will result in the project finishing early, sometimes on time, sometimes late. If, say, the most common outcome was the project finishing around 20% late that might be where you'd want to put your money. This is all fine in theory but it assumes you can give accurate values to all those probabilities. Keep it simple.

To summarise the risk management steps:

• Realise what risks you face, assess their probability and impact.
• Identify what could be done to remove or reduce risks and do it.
• Speak to the sponsor, don't keep risks secret.
• Keep risks under review, monitor and reduce them as you go along.
• Share your experience, update your company's risk checklists.

Or put another way: Measure, Minimise, Mention, Monitor and Modify.

Finally, managing risk is not the same as being risk averse. Jumping out of aeroplanes is a pretty high risk undertaking and you may decide it's wise to reduce the risk by wearing a parachute. Sometimes doing phenomenally high risk projects is the right thing to do. But if it is very high risk everyone knows that and exceptional action is taken to make the project succeed in spite of all the risks. For illustration, in a very high risk, business critical project you might ask for the mobile phone numbers of every member of the project steering committee - who may in fact be the Board of Director - and have an understanding that if anything arises day or night or weekend they can help with, you will call them and they will do whatever it takes. And would you, the project manager, let everyone know you had those mobile numbers? The unspoken promise is: get in my way and your Director will be having a quiet word with you...

The Appendix contains two examples of risk assessment checklists: one for very small projects with about a dozen items on it and one for larger projects which runs to several pages. Even the long checklist won't have anything like all the risks on it that any given project will face - risks will be very dependent upon the project's nature and the environment in which it is being done.

Privacy Policy and Cookies