Project Management Book

...chapter 5 continued

2. Minimise

We now have a list of things we think will threaten our project's success and we have ranked them with highest likelihood/impact first. It may only have taken half a day to do this - to realise what risks the project faces - but identifying what can be done about those risks, and doing it, could require some heavyweight, time consuming, toe-to-toe negotiation.

If the project scope is simply too large to fit into the desired timescale, some forthright discussions with the sponsor may be needed. If one of the major risks was, say, that HR may be unable to provide a person properly to define HR's requirements, a meeting with the HR manager may be appropriate. If a firm commitment is obtained for a knowledgeable HR person to be definitely available and empowered to represent HR you may conclude the risk has been removed. If you can only extract a half-hearted resource promise you may have succeeded in reducing the risk a bit but not in removing it. How big the remaining risk is depends, partly, on how important HR's requirements are in the grand scheme of things and to what extent you believe the promise. You have to make a judgement.

Some risks might be avoided altogether: you simply won't use that untried technology. For other risks, you will be able to reduce the likelihood of them occurring. If you thought a couple of people might leave the project at some point (which could cause real problems) what would you do?

For contractors you might offer to pay them a bonus if they stay until the end of the project. They might still leave half way through but it's less likely.

For regular staff you might line up two backfills who would come in and replace them. In the plan you'd then have two tasks (not yet assigned to anyone), let's say each one week long, labelled 'hand over to your replacement'. As soon as you know someone is going to leave that becomes the last task in their plan. And of course the first task for each of the backfills would be a one week 'be handed over to' task. You haven't altered the risk of people leaving but you have potentially reduced its impact. Now, if you get lucky during the project, guess what? Nobody leaves and you've got 4 weeks of effort in hand! If you get unlucky, guess what? More than two people leave. This illustrates two things quite nicely: for some risks you put specific tasks into the plan to help mitigate the risk (the handover tasks) and it also shows it is all ultimately down the your judgement. Your judgement was that two would leave so you planned on that basis. You win some you lose some but do that across all the risks and if you're lucky it will more or less balance out.

For some risks there may be no specific tasks that can be include in the plan, so we simply include contingency in the budget (i.e. money) and in the schedule (i.e. elapsed time). One risk that exists on every project is that tasks are overlooked and not included in the project plan. When, half way through, you discover work must be done that is not in the plan what do you do? Raid the contingency. And you will never foresee all of the risks: things that aren't foreseen are sometimes called unknown unknowns - include contingency for them.

How much contingency should the budget and timescale include? It depends. A small, simple, familiar project may only have 5% budget and time contingency. A huge, complex, leading edge project may have 30% contingency, which means you're saying this: "I've planned work tasks for everything I can see we will need to do, but this is such new territory I know we will end up doing a lot of other work as well - I just can't foresee specifically what those work tasks will be, so I've allowed time and money for them under the heading contingency." Thirty percent contingency will be hard to sell. Another reason PMs get well paid.

Replanning of various sorts is usually what risk reduction boils down to: extra people, moving the end date, building in third party reviews, building in contingency, etc. Estimating and planning contingency will be further explored in the next two chapters.

When are we doing this risk assessment? As part of the planning of each project stage. So, as we near the end of the project definition stage we will assess the project's risks. We may even do two risk assessments at that time: one in great detail for Stage 1 and another for any later project stages. Then, as we near the end of Stage 1 we will, as part of the planning of Stage 2, do a detailed risk assessment for Stage 2. Risk assessment is a key input to the go no go decision at the start of each project stage.

3. Mention

We have done what we can to deal with the risks: removed them, reduced their likelihood, included things in the plan to reduce their impact, put contingency in the plan, added extra people, adjusted budgets and dates... all to try and make it more likely we'll succeed. But we certainly haven't magiced all the risks away: risks remain.

Who owns the project risk, who ultimately is taking the risk? The project sponsor. But most sponsors, particularly of technical projects, have no idea what the risks are. The project manager has a duty to explain the risks to the sponsor before the sponsor gives the go-ahead.

But beware - there are good ways and bad ways of presenting risks to the sponsor. Do not go to the sponsor with a hundred PowerPoint slides listing several hundred risks most of which are minor. Instead try something like this: "Sponsor, we have been through the following process to assess the project's risks - workshops, checklists... Initially, sponsor these twelve things came out as very high risks. However, we have already taken these actions... and as a result eight of those twelve risks have been removed or significantly reduced." That is a very positive thing to say and builds real credibility for the next bit where you say: "But these four high risks remain." You must then explain the probability and impact of each. If you were the sponsor and the project manager said: "This risk is almost certain to happen and when it does your $5M project will be a total write off," would you give that project the go ahead? Probably not - unless the benefits are measured in billions and it's worth the gamble.

For example: "Sponsor, this risk remains: it is very probable that HR will not be able to supply resources to define their requirements. The impact will be that we will have to more or less guess what they want and in the worst case when we go live the system won't do what HR needs and will be unusable." Now, like any good project manager you're probably already thinking of ten ways that risk could be reduced! But assuming all those things have been tried and there really is no way HR can do it the sponsor may decide he will not start the project until HR can make the requisite resource available.

But if we said: "Sponsor, this risk will be very hard to contain and if it happens we could easily be a month late." The sponsor might say: "OK, try and bring it in on track, but I recognise the end date is a bit exposed."

You must mention the risks to the sponsor before he gives the go-ahead. Imagine you keep the risks secret and when the project is all going wrong you say: "well of course, sponsor, I knew all along it was high risk and bound to go wrong," you're going to get shot, and quite rightly so.

A face to face presentation of the risks should be mandatory for any significant project.

...next

Privacy Policy and Cookies