The Essentials of Managing Risk for Projects and Programmes

John Bartlett

• Publisher: Routledge
• Year: 2017
• eBook ISBN: 9781351974738
• Topic: Business
• Subtopic: Business General
• Index: Business

The Essentials of Managing Risk for Projects and Programmes is an indispensable, practical guide to the steps that lead to success in managing risk.

Risk management is particularly important for projects and programmes, since they all carry varying degrees of risk. The combination of uniqueness, constraints, assumptions, stakeholder expectations, changing environment, and human behaviour all conspire to make projects and programmes risky ventures. Rather than presenting new theories or techniques or tools, John Bartlett offers down-to-earth guidelines and proven methods to respond to risk appropriately.

Pick up and use this concise, intensely practical guide to develop a shared understanding, shared language and shared purpose across project managers, programme managers, sponsors, risk managers, project and programme board members and associated stakeholders in all your projects and programmes.

1
Introduction

Thinking about risk

There is risk in everything we do. Crossing a busy road, bungee jumping, whitewater rafting, making an investment decision and building a house are actions and activities which all contain risk. A participant in any of these is likely to weigh up the risks before taking part.

The nature of the risk assessment, of course, will vary greatly and will depend on the activity and the value the participant places on it with respect to personal risk. For example, crossing a busy road might be perceived by a young, streetwise city dweller to be such a mundane action that it requires only a cursory, almost subconscious thought before embarking on it. To an elderly country dweller, however, the same action might merit considerably greater thought. Yet, whereas it is possible to make such generalised statements regarding these two stereotypes, it is by no means certain that they will apply in every occurrence. Extenuating circumstances could cause the elderly country dweller to make no assessment of risk before crossing the road and vice versa.

What is more certain, though, is that none of these stereotypes is likely to undertake a written risk assessment before carrying out the action. Undertaking a written assessment is more likely in activities such as making an investment decision or building a house, but again, it depends on how risk averse the participant is. Our perception is that few of our daily actions merit a formal risk management approach. We tend to balance monetary value against time and personal safety in arriving at the degree of risk we should take.

We are likely to identify with the newspaper headline “Elderly man injured crossing road” in terms of how the accident could have occurred, since we tend to take a view that elderly people are more vulnerable in this situation. The headline “City student injured crossing road” might cause us to search harder for causes, since we instinctively expect this situation to be a rarer event.

The moral here is that generalisation is fine as a starting point, though it rarely yields the best risk assessment. We need to apply greater depth to thinking about risk, but this does not mean it has to be a laboured activity.

Talking about risk to a colleague from the Far East recently, I was intrigued to discover that the Chinese word for “risk” is appropriately “wēi jī”, meaning “danger opportunity”.

The juxtaposition of both the positive and negative aspects of risk seemed to me to make perfect sense. However, many projects tend to focus only on the negative aspect, whereas the business case for bothering with risk at all must surely focus on the positive aspect. I am convinced that good risk management is the key to many of the ills about which contemporary projects complain: cost overruns, schedule conflicts, scope creep and resource shortages.

A question I like to ask project managers is “How often do you spend time on risk management in your projects?”. The answer is rarely “once a week”, never “daily”, sometimes “once a month” and often “once a quarter”. The answer varies, though, according to the type of project. For IT-related and general business projects, the above is usually the norm. For safety critical engineering projects, I would hope that the answer would be different and that more attention would be given to risk management. Even so, I often hear that risk management is deficient in many examples of safety critical projects.

It is possible, of course, to manage a project without any form of risk management, but this itself carries a degree of risk. There will always be situations that could have been handled more efficiently or cost effectively had risk management techniques been employed. Don’t forget the dual nature of risk where opportunity is just as appropriate as danger. Risk management is often a trade-off between that which is essential to be achieved and that which is not. In other words, how assured do you want to be of a project’s outcome?

My view is that a project manager should be thinking about risk on a daily basis – not necessarily formally, but at least informally. If weekly status reports are not showing differences in the risk register then insufficient attention is being given to risk management. The old saying amongst project managers “How do projects become late?” answered by “One day at a time” has a worrying ring of truth. It is often the incremental “creep” of projects in terms of scope, timescale and earned value that give credence to this saying. The only way we can tackle this problem is by practising risk management techniques, and on a daily basis. It does not mean that the project manager should be constructing risk analysis charts every day. It means that he or she should be applying thought in a risk-oriented way, and developing “risk-thinking teams” – but more of this later.

Some attempt to simplify what is, in fact, a complex subject, is sometimes made by prescribing templates. Indeed, I have often been asked for a “starter set of risks” for a particular type of project, as if all conform to a level of predictability. The very notion that risk management is an exact science and so is able to be prescribed by templates is a much-held fallacy.

The danger of prescription is that it can lead the project manager into a false sense of security – i.e., for very little effort the project manager can feel he or she has produced a viable risk plan. Risk management does require particular effort, however, and should not be dismissed as a trivial exercise. Prescription can also stifle creativity, preventing project managers from giving deep thought to the real risks in a project. Templates can only test generalised and historically identified risks. They cannot test the specific combinations of objectives and activities that will be unique to the project. Good risk management is not prescriptive, but it should, of course, be able to draw on previous experience. There will be plenty of projects where a checklist of previous experience is a particularly useful starting point.

The risk-issue-change pathway

I find project managers are almost universally good at knowing that when an issue has occurred something has to be done to resolve it. They may not know what has to be done, but they certainly know that a process needs to be invoked. The issue is recorded and reported at Progress Meetings, where it is then probably discussed. Such issues, or problems as some prefer to call them, will demand time and, therefore, cost expenditure in order to resolve them. If a project change has to be raised in order to resolve an issue then this could bring an even greater cost. Also, there are often further risks associated with making a change and resolving an issue. Figure 1.1 illustrates this.

Figure 1.1 The link between risks, issues, changes and the relative cost of dealing with each

When a project is completed, the project close-out meeting invariably debates the issues that occurred during the life of the project. How much more efficient it might have been if many of the issues could have been foreseen as risks, and tackled as such! The cost of impact could have been saved. The “firefighting” and running around trying to solve something urgently could have been avoided. There would have been no unplanned disruption to tasks, and the possibility of follow-on risks through resolving the issues could also have been avoided.

Surprisingly, though, few people make the connection between risks and issues. Today’s risks are tomorrow’s issues. Yet, if it is more efficient to deal with risks than issues, why do so few people think along these lines?

I believe it is partly a difficulty in differentiating between risks and issues (the next chapter explores this) and partly a lack of precision that causes people to ignore the risks. It is easy to identify an issue, because it is here and present. A risk may impact at any time in the future – who can be precise about that? It is a difficult business case to persuade management to release money and resources to tackle a risk on such an expectation.

Yet experience shows that those who are able to “bet the project” and spend money tackling risks benefit significantly.

Many projects set aside an amount for risk in the original project business case. This might be a standard percentage or, infrequently, a figure derived from calculating an initial risk exposure. I find it strange, though, that having set aside this amount, managers are often reluctant to spend it on identifying and tackling risks. It is as if the money set aside in the name of risk is really for resolving issues, i.e., when risks impact. This reverse logic is symptomatic of a focus on issues and a lack of risk-thinking, which many project teams display.

Risks, issues and changes are often termed project exceptions, in that they are exceptional events (or ought to be) during a project’s lifespan. As project exceptions they have one thing in common – actions. Each needs one or more actions to tackle it. It is useful to know this since, as actions occur elsewhere in the cycle of project control, it is possible to be consistent about their presentation. Thus, actions from a project progress meeting can be recorded in a similar way to actions from project exceptions. Ideally, actions should appear as tasks on the project plan, since the performance of actions requires time and effort, as does any other project activity. This provides a valuable management link between the plan and project exceptions. These latter should not be thought of as separate entities, though many tend to manage them as such. (More on managing actions may be found in Chapter 4, Responding to risk.)

Understanding the risk-issue-change pathway is vital for developing a risk-thinking attitude. Occasionally, though, this can be abused. It is easy to fill a risk register with risks and pay lip service to a process, so that when an impact occurs, a claim could be made that it was not the project manager’s fault because the risk was recorded and reported. A true risk-thinking attitude is about taking mental ownership of the risks and an active desire to ensure that they don’t impact as issues. This can be measured, of course, though I have yet to see a contract specify “no more than ten risks should impact as issues”! What is specified is the bottom line. Project managers are frequently measured against budget, time and quality, and good risk management has the ability to influence these outcomes significantly.

Figure 1.2 Typical risk management activities in relation to project phases

Risk management applicability

When and where to apply risk management is a question frequently asked. If you accept my view that it should be thought about at least daily, then the identification and assessment of risk is an ongoing activity right across a project or programme’s lifespan. There are, however, specific points in a lifespan where risk management is particularly relevant. Figure 1.2 shows some typical risk management activities across project phases.

Pre-contract stage

Risk management plays an essential role well before a project gets underway. At the bidding or tendering stage it is important to identify and assess risks before proceeding to contract. The allocation of funding and resources should always be based on a formal risk assessment. Companies tend to have different ways of doing this, depending on their business requirements. Some use software questionnaires that produce weighted assessments of risk according to how questions are answered. Others open formal risk registers at this stage, so that risks identified can be seamlessly transferred into project execution.

Less widespread is any formal calculation of risk reserves for contingencies. Many companies will decide on a percentage of the total project cost for risk, e.g., 5% or 10%. For very little effort, however, it is possible to calculate a proper risk exposure. The margin of error will be much less than any “finger in the air” guesswork and both the project team and the financiers will gain a degree of assurance through knowing that it is calculated from gathered data rather than guesswork. (Details of risk exposure calculation may be found in Chapter 6...

Table of contents

• Cover
• Title
• Copyright
• Contents
• List of Illustrations
• Foreword
• Preface to the Third Edition
• Acknowledgements
• About the author
• 1 Introduction
• 2 Identifying and expressing risk
• 3 Assessing risk
• 4 Responding to risk
• 5 Recording risk
• 6 Analysing and reporting risk
• 7 Administering risk
• 8 Managing risk
• 9 Conclusion
• Appendix A – Sample risk management procedure
• Appendix B – Sample risk register
• Bibliography
• Glossary
• Index