Manage risks

Having a detailed list of risks at the beginning of the project becomes a purely academic exercise if you do nothing to manage them. Ongoing risk management should be built into the project-management tasks you do on a regular basis, keeping you on top of anything that may upset the successful delivery of the project.

M I S S I O N C R I T I C A L ( P A R T 1 )

Dr Ady James, a project manager with 14 years experience in the management of space projects, led an international team of around 30 people to develop a highly technical extreme-ultraviolet imaging spectrometer. The instrument forms part of a Japanese spacecraft that has been designed to study the sun.

The project started in 1998 as a collaborative effort between the UK, the USA, Norway and Japan, with a budget of around £13 million. Managing the risks associated with such a large and critical piece of work was essential.

‘The main aspect of our risk-management system is that it is paper-based and under the control of the project manager,’ James explains. ‘It requires very little maintenance other than the vigilance of the project manager.’

Deceptively simple, the project team was constructed in such a way as to make risk management foolproof. James’ team, responsible for the spectro­

meter, tracked risks relating only to that. ‘The spacecraft-level team had their own risk assessment, and so we would be tracking the same risks. Similarly, the local teams had local management and would be tracking their risks.

My risk identification therefore passed some risks up and some down, and I received risks from both directions. This acts as a failsafe for spacecraft-level risks. If we didn’t identify it as a risk, then someone else might.’

Near the start of the project, the whole project team was asked to identify potential risks. These were then added to a draft risk-assessment document.

A small group of the project team with responsibility for the delivery of the technical elements of the project reviewed the document and categorized the risks. Risks were divided into two major sections to help with the classi­

fication:

• programmatic risks, associated with the build phase of the instrument up to launch;

• operational risks, associated with the operations phase of the mission, i.e. post-launch.

Then they were split further into another two sections:

Manage risks

• system-level risks, i.e. risks defined as having impact beyond the experi­

ment and that may affect the spacecraft or mission;

• subsystem-level risks, i.e. risks contained within the experiment and therefore likely to impact only performance.

‘This is where we split away from current thinking on risk management,’

James says. ‘Normally, one would look at probability of occurrence and the impact if the risk was realized. Generally, any impact on performance will be unacceptable to the end user, the scientist.’

There were performance tolerances for the spectrometer, and the role of the risk-management exercise was to resolve any risk that put the instrument outside of this tolerance. For that reason, the risk impact was documented but not scored – every impact was treated in the same way.

‘Another split from traditional thinking is that, rather than an individual, we name the local manager as the owner of the risk as someone who can locally delegate,’ James says. ‘It is up to the local project managers to report to me on risk and assign an owner internally if appropriate.’

The project team updated the risk register and reviewed the list of actions during their regular meetings, and at the end of significant phases the register was reviewed by a panel. Occasionally, new risks were added at this point, and the panel had to be satisfied that all risks were being managed adequately before allowing the team to move on to the next phase.

James had originally planned to update the register with new risks on a monthly basis, but in practice there were not that many to add. They tended to be minor performance concerns or to relate to unplanned work. ‘I found that the frequency of controlling all of the management tools was driven more by the needs of the project than by any active plan on my part,’ he says. ‘When things were going as well as expected, a dogmatic adherence to updating risk registers and the actions list and chasing the individuals for the sake of an update did not seem productive.’ James believes project managers can get a feel for this from management by ‘walking around’. ‘You get a feel for the team’s concerns and know when you may want to formalize some of the control functions,’ he explains. ‘As the team matures into the project – many of mine were already experienced – I found that they were all so aware of the needs of the project that management was always more of an oversight activity rather than a forced driving-type activity. I have the advantage that nearly all of the team members are suitably motivated by the very nature of the work, but I suspect that not many industries get that for free.’

The majority of the risks related to the fact that the project was using untested technology. ‘The number of risks in this type of project reaches a plateau very early on, and additions are rare,’ James says. ‘In our domain, we find that risk management rapidly integrates with the project scope, rather than being seen as a separate activity, so updating the risk register is not so essential. The level of risks at the subsystem level is also generally low as the result of a fairly conservative industry and an experienced development team.’

Project Management in the Real World

James kept the register tidy by closing down risks that had passed and not materialized, which were mainly those relating to late deliveries or test failures. ‘Despite the low number of issued updates to the document, it was read by me at least on about a monthly basis,’ he says. ‘I set up reminders on my calendar software to remind me to check and update the risks, as well as the budgets, schedules, actions and issues, on a monthly basis.’ James’

advice to other project managers is to never plan to do these updates on a Friday. ‘Don’t plan to do them all on the same day either,’ he adds, ‘because it won’t happen. You never get a full free day when a project is in full flow.’

Risk management can be done in an incredibly formal way, with scheduled meetings where the team gets together to discuss the latest developments for each risk, or in a less structured way, with the project manager coordinating the management activity and getting updates on risks as part of the normal progress updates from the team. How you choose to record your risks is up to you; a starter-for-10 document template is included in the appendix.⁴⁰ The point of having done the identification exercise is to then put plans in place so the risks never happen.

Whatever your approach to the paperwork side of things, your approach at the business end of risk management is going to be the same: work out how to handle each risk, plan actions to meet that strategy and monitor progress against the actions. This is the actual activity relating to risk management as opposed to the documentation and thinking process that has to happen up front. The activity of risk management is the critical part, as studies have shown that having an up-to-date risk-management plan and a process for assigning ownership of risk statistically improves your chance of completing the project on time.⁴¹ The more risk management you do, the more chance you have of successful project delivery, however your project defines success.

It is hardly surprising that research shows that the riskier the project, the less successful the outcome; some projects, however much risk management you do and however many times you allocate actions or chase your team for updates, are just too risky to really deliver a top result.⁴²

The next step after risk identification is to work out what you are going to do to stop those risks from happening. This is called risk response. There are four general risk response strategies, as shown in Table 20.1.

Baccarini, Salm and Love have looked at the popularity of each of these different types of risk response in a study of Australian IT project managers.

Presented with a list of frequently occurring risks that were not specific to any particular project, such as lack of resources, incomplete requirements, unreasonable project schedules and so on, the project managers described the strategy they would apply to managing the risk. The results were incred­

ibly varied. The authors conclude that this ‘indicates that there is not one solution for managing any particular risk and the project manager must be aware of the possible need to implement two or more treatments for one risk.’⁴³

Manage risks activity that will result in the risk occurring

Act to reduce the impact of the risk should it occur or the likelihood of it occurring Get someone else to take on part or all of the risk

Understand and accept the consequences should the risk happen

Don’t hold the fete

Hire marquees for all the stands, so the fete can go ahead under cover if the weather is bad

Take out an insurance policy against the potential loss of income for the school if bad weather keeps people away

Accept that there is a chance of bad weather and do nothing

As their research shows, there is no textbook way to manage any given risk. What works for one project in one situation may not work for exactly the same risk in a different project and a different situation. You will need to use your judgement to decide what action plan will be the most effective for you. Baccarini, Salm and Love’s analysis does show that reduction is the most favoured risk response; transfer and acceptance are hardly used at all. This may be because in the majority of projects, it is difficult, if not impossible, to transfer the risk to a third-party contractor, an insurance company or even another department willing to take the chance. Acceptance is similarly not proposed frequently as a risk response, because it is suitable only for very small risks. It is rarely appropriate to do nothing.

Once you have decided on the right risk response given the situation, you can work out a risk-mitigation plan. This is a task-based approach with the aim of making sure that the risk does not materialize. Draw up a list of tasks and owners for each action to carry out your risk-mitigation plan.

H I N T

Your risk-management plans can become a formal part of the signoff process to move from one phase of the project to another. It’s not a good idea to talk to your sponsor about the project risks only when you move from one phase to another.

They will probably want greater visibility of the risks facing the project, so you should provide that information on a more regular basis. One way to do this is to include the top three risks of the moment in your regular reports to the project board, along with a brief statement of how you are managing them to mitigate against the potential impact they would have on the project.

Project Management in the Real World

A final thought on risk management: once you have successfully mitigated against a risk to the point where the risk will now not happen, it can be removed from the risk register. That does not mean deleting it from the document altogether. Each risk should have a status: open or closed. Move closed risks to an appendix or somewhere at the bottom of the document out of the way. Keep a record of what you did to manage the risks out of the project: this might be useful for your post-project review, for an audit or if a similar risk comes up later in the project.

This has been a brief introduction to risk management. Whole books have been written on the subject, so see the further reading for some ideas to follow this up.

G O L D E N R U L E S

Having a list of risks is not enough. Risks should be managed by defining the appropriate risk response, allocating an owner and carrying out activities to mitigate against the risk materi­

alizing.