0% found this document useful (0 votes)
264 views

Managing Risk in Projects

The document discusses why projects are inherently risky. It outlines three main reasons: common project characteristics like uniqueness and complexity introduce risks; projects are deliberately designed to achieve objectives and competitive advantages, requiring risk-taking; and external factors in the unpredictable environment expose projects to risks beyond their control.
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
264 views

Managing Risk in Projects

The document discusses why projects are inherently risky. It outlines three main reasons: common project characteristics like uniqueness and complexity introduce risks; projects are deliberately designed to achieve objectives and competitive advantages, requiring risk-taking; and external factors in the unpredictable environment expose projects to risks beyond their control.
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

Managing Risk in Projects

david hillson

cHapter 

risk and projects

WHATs WRoNg WITH PRojECTs?


We have seen in Chapter 1 that the world is uncertain, and that some of those uncertainties pose risks, depending on whether they matter in terms of affecting our ability to achieve our objectives. And it is this link with objectives that makes risk particularly relevant to projects, since projects are intimately associated with objectives. This chapter explores why projects are particularly risky, in order to set the context for risk management in projects and to help us to understand why managing risk effectively is essential if we really want our projects to succeed. Before we examine the reasons behind the close connection between risk and projects, we need to be clear what we mean by the term project. What are projects and why do we do them? Project management is served by a number of professional bodies, and not surprisingly, these have each developed their own definition of a project. Examples are given in Table 2.1. These and other definitions make it clear that projects exist for a very clear reason, or at least they should. A project is launched in order to implement an aspect of corporate strategy, to realise a business case, and to create a set of deliverables. Ultimately a project delivers benefits to the organisation and its stakeholders, but often these benefits do not arise immediately or directly as a result of completing the project itself. More often a project creates a capability which needs to be operated or used in order to generate the actual benefits. This is illustrated in Figure 2.1. It appears that there is reasonable consensus on what projects are and why we do them. Indeed mankind has been performing projects for many thousands of years, though not always labelling them as such. Construction of major enterprises in antiquity such as the Seven Wonders of the ancient world (the Great Pyramid of Giza, the Hanging Gardens of Babylon, the statue of Zeus at Olympia, the temple of artemis at Ephesus, the mausoleum of Maussollos at halicarnassus, the Colossus of Rhodes, the Lighthouse of Alexandria) were all projects.

1

Managing Risk in pRojects

Table 2.1

Definitions of project
GUIDE/STANDARD Body of knowledge DEFINITION OF PROJECT a unique transient endeavour undertaken to achieve a desired outcome. a temporary endeavour undertaken to create a unique product, service or result. a temporary organisation that is created for the purpose of delivering one or more business outputs according to a specified business case. a unique process, consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements, including constraints of time, cost and resources.

ORGANISATION association for project Management (apM) project Management institute (pMi)

a guide to the project Management Body of knowledge (pMBok guide) prince

Office of Government commerce (ocg)

british standards institution (bsi)

bs079-:000

PROGRAMME CORPORATE STRATEGY embody BUSINESS CASE launch

PROJECT

validate

BENEFITS

operate

CAPABILITY

create

DELIVERABLES

figure 2.1

Linking projects to strategy

execute

Risk and pRojects

1

With such a long history of executing projects, one would expect that we would be very successful at it by now. Unfortunately the data suggest otherwise. The best long-term data on project success come from the Standish Group, whose CHAOS Report continues to document a high number of projects which either fail completely or are challenged (meaning that they were delivered either late or over budget or with reduced scope). Figure 2.2 presents the standish Chaos data from its origin in 1994 to the most recently available in 2006, indicating that the situation has not improved dramatically over the years. So why do so many projects fail? It is not due to lack of project management theory, tools and techniques, or trained people. We have a good understanding of project concepts, project management processes are well developed, and the people working on projects are mostly professional, committed and capable. It seems that one of the major reasons for project failure is the occurrence of unforeseen events which disrupt the smooth running of the project and cause irrecoverable deviation from the plan. As former British Prime Minister Harold Macmillan explained when asked by a journalist what was most likely to throw a government off course, Events, dear boy, events. On any given project, some of these unforeseen events were probably unforeseeable. But others are likely to have been knowable, if only someone on the project team had looked in the right place or been aware of what lay ahead. These knowable uncertainties fall under the heading of risks, as future events that, if they occurred, would affect achievement of project objectives.

WHy ARE PRojECTs RIsky?


There seems little doubt that projects are risky, as anyone who has ever worked on one will know. In fact there are three distinct and separate reasons for this, which
60% 50% 40% 30% 20% 10% 0% 1994 1996 1998 2000 2002 2004 2006 Succeeded Failed Challenged

figure 2.2

standish CHAos data on project success 19942006

Source: Chaos database, www.standishgroup.com

1

Managing Risk in pRojects

we need to understand if we are to manage risk in projects successfully. These are discussed below under three headings: 1. Common characteristics; 2. Deliberate design; 3. External environment.

Common characteristics
All projects share a range of features which inevitably introduce uncertainty. Many of these characteristics are described in the definitions of project in Table 2.1. Factors found in all projects which make them inherently risky include: Uniqueness. Every project involves at least some elements that have not been done before, and naturally there is uncertainty associated with these elements. Complexity. Projects are complex in a variety of ways, and are more than a simple list of tasks to be performed. There are various kinds of complexity in projects, including technical, commercial, interfaces or relational, each of which brings risk into the project. Assumptions and constraints. Project scoping involves making a range of guesses about the future, which usually include both assumptions (things we think will or will not happen) and constraints (things we are told to do or not do). assumptions and constraints may turn out to be wrong, and it is also likely that some will remain hidden or undisclosed, so they are a source of uncertainty in most projects. People. All projects are performed by people, including project team members and management, clients and customers, suppliers and subcontractors. all of these individuals and groups are unpredictable to some extent, and introduce uncertainty into the projects on which they work. Stakeholders. These are a particular group of people who impose requirements, expectations and objectives on the project. Stakeholder requirements can be varying, overlapping and sometimes conflicting, leading to risks in project execution and acceptance. Change. Every project is a change agent, moving from the known present into an unknown future, with all the uncertainty associated with such movement.

These risky characteristics are built into the nature of all projects and cannot be removed without changing the project. For example, a project which was not unique, had no constraints, involved no people and did not introduce change would in fact not be a project at all. Trying to remove the risky elements from a project would turn it into something else, but it would not be a project.

Risk and pRojects

1

Deliberate design
The definitions of project in Table 2.1 emphasise that projects are conceived, launched and executed in order to achieve objectives which are (or should be) closely linked to corporate strategy. In the competitive business environment, organisations are seeking to get and stay ahead of the competition by making significant advances in the products and services which they offer, and by operating as efficiently and effectively as possible. Many businesses use projects as vehicles to deliver that competitive advantage. Clearly each organisation wishes to move ahead as quickly as possible, and that involves taking risk as the business exposes itself to a range of uncertainties that could affect whether or not it achieves its desired aim. This can be achieved in two ways: 1. One option might be to take small steps, making incremental changes to existing products and services, seeking continuous improvement and evolutionary change. While this strategy might appear to be less risky, it delivers smaller advantages at each increment, and relies on a constant supply of value-enhancing developments. 2. An alternative is to be revolutionary, looking for major innovations and paradigm-breaking change, trying to leapfrog the competition and get several steps ahead. This is a more risky strategy but the potential gains are larger and might be achieved more quickly. The two strategies reveal an important relationship between risk and reward: they are positively correlated. Higher-risk means potentially higher reward, though clearly there is also increased possibility of significant loss. By trying to make bigger changes more quickly, an organisation takes more risk in both dimensions, both positive and negative. This is illustrated graphically in Figure 2.3. For example, attempting to launch a new product in a new market could give first-mover advantage and be very profitable, or it could result in significant losses (shown as position A in Figure 2.3). If on the other hand the organisation plays safe and takes less risk, the potential gains are lower (position B). In project-based organisations, the role of projects is to deliver value-creating capabilities. As a result, projects are deliberately designed as risk-taking ventures. Their specific purpose is to produce maximum reward for the business while managing the associated risk. Since the existence of projects is so closely tied to reward, it is unsurprising that they are also intimately involved with risk. Organisations which understand this connection deliberately design their projects to take risk in order to deliver value. Indeed projects are undertaken in order to gain benefits while taking the associated risks in a controlled manner.

1

Managing Risk in pRojects

extreme

REWARD

high moderate low zero

e as tc es b e as dc cte pe ex

wo

LOSS

low moderate high extreme zero low

rs

tc

as

A
moderate RISK high extreme

figure 2.3

Relationship between Risk and Reward/Loss (indicative)

External environment
Projects are not conducted in a vacuum, but exist in an environment external to the project itself which poses a range of challenges and constraints. This includes both the wider organisation beyond the project and the environment outside the organisation, and changes which are outside the projects control can occur in both of these. Environmental factors which introduce risk into projects include: market volatility; competitor actions; emergent requirements; client organisational changes; internal organisational changes; PESTLIED (political, economic, social, technological, legal, international, environmental, demographic) factors.

Each of these factors is subject to change at an increasing rate in the modern world. Projects essentially have a fixed scope which they are required to deliver within this ever-changing environment, which naturally poses risk to the project. It is not possible to isolate most projects from their environment, so this represents a common source of risk for projects.

Risk and pRojects

17

WHy MANAgE RIsk IN PRojECTs?


It is undoubtedly true that projects are risky as a result of their common characteristics, by deliberate design, and because of the external environment within which they are undertaken. It is impossible to imagine a project without risk. Of course some projects will be high-risk, while others have less risk, but all projects are by definition risky to some extent. The zero-risk project is an oxymoron and a logical impossibility it does not and cannot exist. But the link between risk and reward makes it clear that not only is a project without risk impossible, it is also undesirable. The important thing is not to keep risk out of projects, but to ensure that the inevitable risk associated with every project is at a level which is acceptable to the sponsoring organisation, and is effectively managed. indeed those involved with launching, sponsoring and managing projects in organisations should welcome risk in their projects, since it enables and supports change, innovation and creativity as long as it is taken sensibly, intelligently and appropriately, and as long as it is managed effectively. It is also important to remember that not all risk is bad, since the concept includes both threats and opportunities, as discussed in the previous chapter. Within the project context, this means that there are uncertainties that matter because if they occurred they would hinder achievement of project objectives (threats), but there are also uncertainties whose occurrence would help to achieve those objectives (opportunities). This of course is why risk management is such an important part of effective project management: since all projects are exposed to risk, successful projects are the ones where that risk is properly managed. In outlining the importance of managing risk in projects, we have used words such as sensible, intelligent, appropriate and effective to describe how risk management should be implemented. The next chapter describes a risk process that embodies those characteristics, but first there is one additional aspect of risk in projects that needs to be clarified.

RIsks oR RIsk?
When considering risk in projects, there are two levels of interest, typified by the scope of responsibility and authority of the project manager and the project sponsor. The project manager is accountable for delivery of the project objectives, and therefore needs to be aware of any risks that could affect that delivery, either positively or negatively. Their scope of interest is focused on specific sources of uncertainty within the project. These sources are likely to be

18

Managing Risk in pRojects

particular future events or sets of circumstances or conditions which are uncertain to a greater or lesser extent, and which would have some degree of impact on the project if they occurred. The project manager asks What are the risks in my project?, and the answer is usually recorded in a Risk Register or similar document. The project sponsor on the other hand is interested in risk at a different level. They are less interested in specific risks within the project, and more in the overall picture. Their question is How risky is my project?, and the answer does not usually come from a Risk Register. Instead of wanting to know about specific risks, the project sponsor is concerned about the overall risk of the project. This represents their exposure to the effects of uncertainty across the project as a whole.

These two different perspectives reveal an important dichotomy in the nature of risk in the context of projects. A project manager is interested in risks while their sponsor wants to know about risk. While the project manager looks at the risks in the project, the project sponsor looks at the risk of the project. This distinction is described in some of the more forward-thinking approaches to project risk management. Two examples are provided in Table 2.2, from risk management guidelines published by the Association for Project Management (APM) and the Project Management Institute (PMI) respectively. Table 2.2
GUIDE project risk analysis & Management (praM) guide (apM, 00)

Risks vs. Risk in project risk management guidelines


LOWER LEVEL RISKS the term risk event describes an individual uncertainty which can be identified, assessed and managed through the project risk management process, and is defined as follows: a risk event is an uncertain event or set of circumstances that, should it occur, will have an effect on achievement of one of more project objectives. HIGHER LEVEL RISK the term project risk is used to describe the joint effect of risk events and other sources of uncertainty. at an overall project level, project risk must be the focus, not individual risk events, but it is important to understand how project risk is defined by its components, and to manage it at both levels. Project risk is defined as follows: project risk is the exposure of stakeholders to the consequences of variation in outcome.

Risk and pRojects

19

Table 2.2
GUIDE

Concluded
LOWER LEVEL RISKS Individual risks are the focus of day-to-day project risk management in order to enhance the prospects of a successful project outcome. it is important to examine individual risk events or conditions that might affect project objectives. individual risks refer to specific events or conditions that have the ability to affect project objectives positively or negatively. note that an individual risk may affect one or more project objectives, elements, or tasks. understanding individual risks can assist in determining how to apply effort and resources to enhance the chances of project success. HIGHER LEVEL RISK Overall project risk represents the effect of uncertainty on the project as a whole. overall project risk is more than the sum of individual risks on a project, since it applies to the whole project rather than individual elements or tasks. it represents the exposure of stakeholders to the implications of variations in project outcome. it is an important component of strategic decision-making, program and portfolio management, and project governance where investments are sanctioned or cancelled and priorities are set.

project risk Management practice standard (pMi, 009)

Given these two levels of interest, any approach to risk management in projects needs to be able to answer the questions of both project manager and project sponsor. An effective project risk management process should identify individual risk events within the project and enable them to be managed appropriately, and should also provide an indication of overall project risk exposure. This second aspect is less well developed in current thinking and practice, and is the subject of active development by leading practitioners and professional bodies.

WHy Is RIsk MANAgEMENT IMPoRTANT To PRojECTs?


This chapter has described why projects are risky: by nature, by design and by context. In a real sense, the whole discipline of project management can be seen as an attempt to bring structure and order to the various elements of uncertainty within a project. For example, the purpose of the Work Breakdown Structure (WBS) is to define the full scope of the project, to ensure that this is clearly stated and understood, and to form a basis for project control and monitoring. With a properly

0

Managing Risk in pRojects

RISK MANAGEMENT EFFECTIVENESS ineffective


ITIC OF AL SO FAI U L U RCE RE

effective
SU AL OR ITIC CT CR S FA ES CC

lower
figure 2.4

CR

higher

CHANCE OF PROJECT SUCCESS


Risk management as a Csf for project success defined WBS, there should be no uncertainty about project scope all project work is described in the WBS, and if it is not in the WBS it is not in the project. Similarly the Organisational Breakdown Structure (OBS) and Cost Breakdown Structure (CBS) seek to define the roles within the project and the structure of the project budget respectively, in order to reduce or remove possible ambiguity, confusion or misunderstanding. The project schedule describes the dependency relationships between project activities and their expected time-phasing, to reduce uncertainty about what happens when. While each of the project management disciplines can be seen as addressing some aspect of project uncertainty, it is risk management which has the most direct relevance here, since it specifically and intentionally focuses on those uncertainties that matter. The whole purpose of the risk process is to identify risks and enable them to be managed effectively. As a result, risk management is essential for project success. The outcome of managing risks properly on a project is to reduce the number of threats that materialise into problems, and to minimise the effect of those which do occur. it also results in more opportunities being captured proactively and turned into positive benefits for the project. Effective

Risk and pRojects

1

risk management minimises threats, maximises opportunities and optimises the achievement of project objectives. The converse is also true (as illustrated by the experience of many projects where risk management is less than fully effective). Failing to manage risks on projects will result in more problems, less benefits and a lower chance of project success. In this sense, risk management is a true CSF for projects: it is unlikely that projects will be successful without effective management of risk (it is a Critical Source of Failure), and where risk management is working properly projects have the best chance of succeeding (it is a Critical success Factor), as illustrated in Figure 2.4 opposite. Having explained why risk management matters to projects, the next question is how to do it, which is addressed in the next chapter.

You might also like