Assignment 3: Risk Workshop and Risk Register

HillsonDavidSim_2012_PARTITheProblem_PracticalProjectRiskM1.pdf

Home >Business & Finance homework help >Management homework help >Assignment 3: Risk Workshop and Risk Register

PART I

The Problem

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

Al l ri gh ts r es er ve d. M ay n ot b e re pr od uc ed i n an y fo rm w it ho ut p er mi ss io n fr om t he p ub li sh er , ex ce pt f ai r us es p er mi tt ed u nd er U .S . or a pp li ca bl e co py ri gh t la w.

EBSCO : eBook Collection (EBSCOhost) - printed on 9/25/2019 2:02 AM via STRAYER UNIVERSITY AN: 1672297 ; Hillson, David, Simon, Peter.; Practical Project Risk Management : The ATOM Methodology Account: strayer.main.ehost

CHAPTER 1

The Challenge of Managing Risk

ew would disagree that life is risky. Indeed, for many people it is precisely the element of risk that makes life interesting. However, unmanaged risk is dangerous because it can lead to unforeseen outcomes. This fact has led to the recognition that risk management is essential, whether in

business, projects, or everyday life. But somehow risks just keep happening. Risk management apparently does not work, at least not in the way it should. This book addresses this problem by providing a simple method for effective risk management. The target is management of risks on projects, although many of the techniques outlined here are equally applicable to managing other forms of risk, including business risk, strategic risk, and even personal risk.

The book is divided into three parts, starting with defining the problem in an effort to understand the underlying reasons for the apparent failure of project risk management to deliver the promised or expected benefits. The main body of the book describes a generic risk management process applicable to most projects, focusing on simple guidelines to make risk management work in practice. Finally, the book considers implementation issues, applying the risk management process to different types of projects, and addressing the steps necessary to use risk management effectively.

But before considering the details of the risk management process, there are some essential ideas that must be understood and clarified. For example, what exactly is meant by the word risk?

Risk—The Definition Debate

Some may be surprised that there is any question to be answered here. After all, the word can berisk found in any English dictionary, and surely everyone knows what it means. But in recent years risk practitioners and professionals have been engaged in an active and controversial debate about the precise scope of the word.

Everyone agrees that risk arises from uncertainty, and that risk is about the impact that uncertain events or circumstances could have on the achievement of goals. This agreement has led to definitions combining two elements of uncertainty and objectives, such as, “A risk is any uncertainty that, if it occurs, would have an effect on achievement of one or more objectives.” Traditionally risk has been perceived as bad; the emphasis has been on the potential effects of risk as harmful, adverse, negative, and unwelcome. In fact, the word has been considered synonymous with . But this is not therisk threat only perspective.

Obviously some uncertainties could be helpful if they occurred. These uncertainties have the same characteristics as threat risks (i.e., they arise from the effect of uncertainty on achievement of objectives), but the potential effects, if they were to occur, would be beneficial, positive, and welcome. When used in this way, becomes synonymous with .risk opportunity

Risk practitioners are divided into three camps around this debate, as illustrated by .Figure 1-1

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

Figure 1.1 Risk—The Definition Debate

One group insists that the traditional approach must be upheld, reserving the word for bad thingsrisk that might happen. This group recognizes that opportunities also exist, but sees them as separate from risks, to be treated differently using a distinct process (row a).

A second group believes that there are benefits from treating threats and opportunities together, broadening the definition of risk and the scope of the risk management process to handle both (row b).

A third group seems unconcerned about definitions, words, and jargon, preferring to focus on “doing the job.” This group emphasizes the need to deal with all types of uncertainty without worrying about which labels to use (row c).

While this debate remains unresolved, clear trends are emerging. The majority of official risk management standards and guidelines use a broadened definition of risk, including both upside opportunities and downside threats. Some leading procedural standards, such as A Guide to the Project

from the Project Management Institute, and theManagement Body of Knowledge (PMBOK Guide)®

Association for Project Management’s , alsoProject Risk Analysis and Management (PRAM) Guide reflect this wider definition in their risk management processes, with tools and techniques to identify, assess, and manage both opportunities and threats. Following this trend, increasing numbers of organizations are widening the scope of their risk management approach to address uncertainties with positive upside impacts as well as those with negative downside effects.

Given the increasing popularity of the wider application of risk management to both threats and opportunities, as well as the attraction of using a single process to deal with two related concerns, this book adopts the inclusive position. Using a common process to manage both threats and opportunities has many benefits, including:

• , with no need to develop, introduce, and maintain a separateMaximum efficiency opportunity management process

• (double “bangs per buck”) from using a single process to achieveCost-effectiveness proactive management of both threats and opportunities, resulting in avoidance or minimization of problems, exploitation and maximization of benefitsand

• , requiring only minor changes to current techniques for managingFamiliar techniques threats so organizations can deal with opportunitiesCo

py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

• , because the common process uses familiar processes, tools, andMinimal additional training techniques

• , so that opportunities that might have been missed canProactive opportunity management be addressed

• , by including potential upside impacts as well asMore realistic contingency management the downside, taking account of both “overs and unders”

• , by encouraging people to think creatively about ways to workIncreased team motivation better, simpler, faster, more effectively, etc.

• , because opportunities are identified and captured,Improved chances of project success producing benefits for the project that might otherwise have been overlooked.

Having discussed what a risk is (“any uncertainty that, if it occurs, would have a positive or negative effect on achievement of one or more objectives”), it is also important to clarify what risk is not. Effective risk management must focus on risks and not be distracted by other related issues. A number of other elements are often confused with risks but must be treated separately, such as:

• . This term can be used in several different ways. Sometimes it refers to matters ofIssues concern that are insufficiently defined or characterized to be treated as risks. In this case an issue is more vague than a risk, and may describe an area (such as requirement volatility, resource availability, or weather conditions) from which specific risks might arise. The term

is also used (particularly in the United Kingdom) as something that has occurred butissue cannot be addressed by the project manager without escalation. In this sense an issue may be the result of a risk that has happened, and is usually negative.

• . A problem is also a risk whose time has come. Unlike a risk that is a potentialProblems future event, there is no uncertainty about a problem—it exists now and must be addressed immediately. Problems can be distinguished from issues because issues require escalation, whereas problems can be addressed by the project manager within the project.

• . Many people confuse causes of risk with risks themselves. The cause, however,Causes describes existing conditions that might give rise to risks. For example, there is no uncertainty about the statement, “We have never done a project like this before,” so it cannot be a risk. But this statement could result in a number of risks that must be identified and managed.

• . Similar confusion exists about effects, which in fact only occur as the result of risksEffects that have happened. To say, “The project might be late,” does not describe a risk, but what would happen if one or more risks occurred. The effect might arise in the future (i.e., it is not a current problem), but its existence depends on whether the related risk occurs.

Using Risk Management on Projects

The widespread occurrence of risk in life, business, and projects has encouraged proactive attempts to manage risk and its effects. History as far back as Noah’s Ark, the pyramids of Egypt, and the Herodian Temple shows evidence of planning techniques that include contingency for unforeseen events. Modern concepts of probability arose in the 17th century from pioneering work by Pascal and his contemporaries, leading to an improved understanding of the nature of risk and a more structured approach to its management.

Without covering the historical application of risk management in detail here, clearly those responsible for major projects have always recognized the potentially disruptive influence of uncertainty, and they have sought to minimize its effect on achievement of project objectives. Recently, risk management has

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

become an accepted part of project management, included as one of the key knowledge areas in the various bodies of project management knowledge and as one of the expected competencies of project management practitioners.

Unfortunately, embedding risk management within project management leads some to consider it as “just another project management technique,” with the implication that its use is optional, and appropriate only for large, complex, or innovative projects. Others view risk management as the latest transient management fad. These attitudes often result in risk management being applied without full commitment or attention, and are at least partly responsible for the failure of risk management to deliver the promised benefits.

To be fully effective, risk management must be closely integrated into the overall project management process. It must not be seen as optional, or applied sporadically only on particular projects. Risk management must be if it is to assist organizations in achieving their objectives.built in, not bolted on

Built-in risk management has two key characteristics:

• First, project management decisions are made with an understanding of the risks involved. This understanding includes the full range of project management activities, such as scope definition, pricing/budgeting, value management, scheduling, resourcing, cost estimating, quality management, change control, and post-project review. These must take full account of the risks affecting the project, giving the project a risk-based plan with the best likelihood of being met.

• Secondly, the risk management process must be integrated with other project management processes. Not only must these processes use risk data, but there should also be a seamless interface across process boundaries. This has implications for the project toolset and infrastructure, as well as for project procedures.

Benefits of Effective Risk Management

Risk management implemented holistically, as a fully integral part of the project management process, should deliver benefits. Empirical research by Terry Cooke-Davies, gathering project performance data from benchmarking networks of major organizations across a variety of industries, shows that risk management is the single most influential factor in project success. Where risk management is well implemented, more projects meet their objectives (using a composite performance measure for schedule and cost, projects in organizations reporting “fully adequate” risk management completed on average at 95 percent of plan). Where risk management is poor, projects fail more often (projects where risk management was rated “not at all adequate” averaged 170 percent of plan). These conclusions are based on detailed examination of characteristics describing risk management approach and deployment. Figure

presents typical data (in this case for documenting organizational risk management responsibilities1-2 in the project).

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

Figure 1.2 Influence of Documenting Risk Responsibilities on Project Performance (from Cooke-Davies 2002)

Unfortunately, despite indications that risk management is very influential in project success, the same research found that risk management is the lowest scoring of all project management techniques in terms of effective deployment and use, suggesting that although many organizations recognize that risk management matters, they are not implementing it effectively. As a result, projects still fail, businesses still struggle, too many foreseeable downside threat-risks turn into real issues or problems, and too many achievable upside opportunity-risks are missed.

There is clearly nothing wrong with risk management in principle. The concepts are clear, the process is well defined, proven techniques exist, tools are widely available to support the process, and there are many training courses to develop risk management knowledge and skills. So where is the problem? If it is not in the theory of risk management, it must be in the practice. Despite the huge promise held out by risk management to increase the likelihood of project and business success by allowing uncertainty and its effects to be managed proactively, the reality is different.

The problem is not a lack of understanding the “why, what, who, or when” of risk management. Lack of effectiveness comes most often from not knowing “how to.” Project managers and their teams face a bewildering array of risk management standards, procedures, techniques, tools, books, training courses—all claiming to make risk management work—which raises the questions: How to do it? Which method to follow? Which techniques to use? Which supporting tools?

The main aim of this book is to offer clear guidance on “how to” do risk management in practice. The next chapter discusses common barriers to risk management effectiveness and introduces a number of Critical Success Factors to overcome these barriers. This leads into , which outlines ActiveChapter 3 Threat and Opportunity Management (ATOM)—a generic risk management methodology, applicable to any type of project of any size in any industry. Implementation of ATOM for the typical project is

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

described in , where each step in the risk process is presented with sufficient detail to makePart II implementation as easy as possible without oversimplifying. Techniques are explained step by step, with underlying theory where appropriate and relevant, and useful templates are contained in two appendices.

Of course not all projects are typical, so ATOM is scalable to fit both the simple and the more complex project. of this book explains how to tailor the generic risk process to both small and largePart III projects to ensure that the process meets the specific risk challenge, as well as discussing how ATOM for projects interfaces with the wider program context.

Undoubtedly risk management has much to offer to both businesses and projects. People following the approach in this book will discover how to capture those promises for themselves, their projects, and their business.

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

1. 2.

CHAPTER 2

Making It Work

isk management is too important to be left to chance. For risk management to work it must be applied consistently, and this is best achieved using a structured or formal approach that requires a number of components to be in place, including:

• A supportive organization

• Competent people

• Appropriate supporting infrastructure

• A simple to use, scalable, and documented process.

These factors, which are discussed later in this chapter, are often referred to as Critical Success Factors (CSFs), for two reasons:

Their absence leads to a failure of risk management to deliver the full benefit to the organization. Their presence increases the chances of risk management being effective and successful.

Putting Critical Success Factors in place may sound simple to achieve, but in practice making risk management work is a real challenge. This chapter explores some of the main reasons for this—not to be negative but to provide possible ways to counteract the most common reasons. Forewarned is forearmed.

A research project by Risk Doctor & Partners in collaboration with KLCI investigated how organizations perceive the value of risk management. The survey addressed several different aspects, but two questions were particularly interesting. The first question asked, “How is riskimportant management to project success,” with possible answers including extremely important, very important, important, somewhat important, and not important. The second question asked, “How is riskeffective management on your projects,” with answers ranging from extremely effective to very effective, effective, somewhat effective, or ineffective.

With 561 responses, the raw data is interesting in itself, but the correlation between answers to these two questions is fascinating. Simplifying the answers to each question into two options (positive or negative) gives four possible combinations, presented below along with the percentage of respondents who fell into each category (see ):Figure 2-1

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

Figure 2.1 Importance and Effectiveness of Risk Management

Perhaps the combination “Not Important but Effective” is not really feasible because it would be unusual for risk management to be effective if the organization does not consider it to be important; indeed, less than 1 percent of people responding to the research questionnaire believed themselves to be in this situation. Indeed, if risk management is viewed as unimportant it might not be done at all. But the other three combinations represent different levels of risk management maturity, and organizations in each of these three groups might be expected to act in very different ways.

Organizations that consider risk management to be important and effective in delivering the promised benefits (combination 1) could become champions for risk management, demonstrating how it can work and persuading others to follow their lead. These risk-mature organizations might be prepared to supply case studies and descriptions of best practice, allowing others to learn from their good experience. Encouragingly, more than 40 percent of respondents in the research project reported being in this position. An organization that believes risk management is important but not effective in practice (combination 2), which is the position reported by about 42 percent of respondents (about the same as for combination 1), should consider launching an improvement initiative to benchmark and develop its risk management capability. Tackling the CSFs for effective risk management leads to enhanced capability and maturity, allowing the organization to reap the expected benefits.

Not surprisingly, risk management is ineffective in organizations that believe it is unimportant (combination 3), because it is not possible to manage risk effectively without some degree of commitment and buy-in. Only 17 percent of respondents admitted to this, perhaps recognizing that it is not a particularly good place to be. These risk-immature organizations should be persuaded and educated about the benefits of risk management to the business—a task best performed by convinced insiders who can show how to apply proactive management of risk to meet the organization’s specific challenges.

It is a good idea for every organization to review its position on risk management against the two dimensions of importance and effectiveness, and to take appropriate action to move up the scale of risk management maturity. Risk management offers genuine and significant benefits to organizations, their

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

projects, and their stakeholders, but these benefits will never be achieved without recognition of the of managing risk at all levels in the business, matched with operational inimportance effectiveness

executing risk management in practice.

Why Don’t We Do It?

Most people would agree that risk management should be useful. If this is true, why is it not more widely used? Some of the more frequently cited reasons or excuses are listed in andFigure 2-2 described in the following paragraphs.

The risk process takes time and money

Risk management is not a passive activity, and there is a cost associated with executing the upfront risk process—the cost of . Risk management requires involvement of the project sponsor,assessing risk project manager, members of the project team, and other stakeholders over and above what some would consider their normal level of commitment to the project. This causes a double problem: finding time for the risk process in an already overloaded working environment is difficult; and even when time is found, the risk process costs money, as effort is spent in risk workshops and review meetings.

Figure 2.2 Excuses and Solutions

Risk responses cost money

A central purpose of the risk process is to identify risks and determine appropriate responses, which inevitably results in the need to do new and unplanned things. This introduces a second type of cost to the risk process: the cost of . Risk responses are in reality new project activities that wereaddressing risk not originally considered necessary. Because risk responses were not included in the original project scope, they add to the resource requirement and budget. As a result, risk management adds to the project workload while at the same time increasing the required budget.Co

py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

Risk management doesn’t work for us

Although risk management is not difficult, many people have unfortunately experienced it being applied ineffectively, leading them to believe that risk management doesn’t work. This situation often arises when risk management is performed without proper commitment, perhaps by organizations merely complying with a regulatory, contractual, or procedural requirement.

Risk management is just scaremongering

Until recently, risk management was commonly concerned only with threats. As a result the risk process focused only on the bad things that might occur, examining every possible cause of failure, and listing every potential problem. This can demotivate and create a sense of doom for the project team, which believes that the project cannot succeed given the number of identified negative risks. This can also affect senior management, project sponsors, and customers, who might believe that the project team is merely scaremongering, raising potential problems that might never happen, possibly trying to engender sympathy, or maybe even paving the way for project failure.

Managing issues is more fun and rewarding

Some believe that dealing with issues, problems, or even crises is more interesting and rewarding. Individuals might gain considerable satisfaction from solving a problem, especially if it’s a big one, even if it could have been prevented by proactive risk management. In addition, many organizations reward those macho project managers who successfully resolve a major crisis and then deliver their project in line with its objectives. By contrast, the project manager who has avoided all problems by effectively applying risk management is often ignored, with the implication that “it must have been an easy project because nothing went wrong.”

It’s too late to carry out risk management

Some projects simply involve implementing predefined solutions in which all key objectives (time, cost, and quality) are pre-agreed and unchangeable. Where this is true, the project manager might see little point in taking time to identify risks that require additional work and more money to manage, when neither more resources nor more budget will be made available because the objectives are fixed and agreed upon in advance. The risk process might even reveal that achieving the agreed-upon project objectives is impossible—an “unacceptable” conclusion. Although many would say that part of the purpose of risk management is to expose unachievable objectives, in reality this could put the project manager in a difficult position and could result in statements like, “Don’t give me problems, just give me solutions,” or “Stop complaining, just do it.”

I’m too busy dealing with issues

When projects are badly planned in the first place, issues and problems will quickly arise that can dominate the project’s day-to-day management. In these situations, project managers easily become consumed with the “now” problems and find it difficult, if not impossible, to worry about potential future events, even though identifying and proactively managing them would clearly be beneficial to the project. Frequently the result is that risk management never even gets started.

It’s just common sense

Everyone looks both ways when they cross the road, don’t they? Nobody would ever consider climbing a mountain without ropes, would they? The majority of people should surely carry out risk managementCo

py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

on a day-to-day basis; it’s just common sense. If this is true, then we should expect that risk management will be applied intuitively to all projects, and that project managers will always do it without needing a formal or structured risk process.

We can’t prove that risk management works

Some risks that are identified never materialize, and as a result some people think that considering things that might not happen is just a waste of time. In addition, it is difficult to prove that risk management is working on a project because there is never an identical project that can be run without risk management as a control. And where the risk process only addresses threats, successful risk management means nothing happens! Since it is impossible to prove a negative, the absence of unusual problems cannot be firmly linked with the use of risk management—the project team might just have been lucky that no problems occurred.

Turning Negatives into Positives

Each of the excuses described above represents a potential barrier to implementing effective risk management. Where project stakeholders hold these views, it is important to address their concerns, correct their misperceptions, and allay their fears so that they can engage with the risk process and make it work. The following paragraphs outline possible approaches to deal with each point (summarized in

).Figure 2-2

The risk process takes time and money

Implementing risk management does take time and does cost money. However, when applied properly, risk management actually saves time, saves money, and produces outputs of the required quality. The argument is similar to that supporting the use of quality procedures in project management, where proactive attention to potential problems ensures the best possible results by reducing wasted effort and materials caused by rework or solving problems.

Risk responses cost money

The cost of implementing new activities in order to manage risks is a fundamental part of applying the risk process. Failing to respond to risks through planned response activities means that risks will go unmanaged, the risk exposure will not change, and the risk management process will not be effective. The cost of risk responses should be seen as an investment in the project’s success—“spending to save.” A similar argument exists for the cost of quality, where rework or fixing noncompliances is recognized as being more expensive than doing the job right the first time. Equally for risk management, addressing a threat proactively usually costs less than it does to resolve a problem when it happens. And addressing an opportunity is clearly more cost-effective than missing a potential benefit.

Risk management doesn’t work for us

Ineffective or badly applied risk management can cause more problems than it solves. Where this is the case, measures must be put in place to make the risk management process more effective, perhaps by training project team members or improving risk processes. Once these changes have been made, then the organization must ensure proper application of the changed ways of working. If the excuse that “risk management doesn’t work” is based on poor practice, the answer is to do it properly and it will work. Sometimes the belief that risk management is not applicable or helpful arises from a view that “our

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

projects are different,” a feeling that risk management might work for others but “it doesn’t work for us.” Here, a pilot project can be particularly useful in demonstrating the benefits of doing it properly on a real project.

Risk management is just scaremongering

Overemphasis on identifying every potential threat to the project can be overcome in two ways. The best solution is to ensure that the risk process also proactively identifies and addresses upside risks (opportunities) that counteract the threats. This also helps the project stakeholders realize that the project is not all “doom and gloom,” and that things might get better as well as worse. The second part of the answer is to ensure that identified threats really do matter. Often many so-called threats may have little or no impact on the project, or might not even be risks at all. And of course where threats are identified that really could affect the project adversely, effective responses must be developed to reduce the risk exposure. The answer to the charge that risk management is merely scaremongering is to ensure that the risk assessment is realistic and presents genuine threats and opportunities together with appropriate responses.

Managing issues is more fun and rewarding

It is undoubtedly stimulating to tackle problems and crises, and it is right for organizations to reward the staff who have the skills to rescue troubled projects. However, the reward scheme should not incentivize macho behavior at the expense of prudent risk management. Organizations should also find ways to reward project managers who successfully manage the risks on their project. This may be through the creation of key performance indicators (KPIs) that measure the effectiveness of the risk process, linked to a risk-based bonus. One KPI related to effective risk management might be the number of issues that arise during the project: the greater the number of issues, the less effectively the risk management process has been applied.

It’s too late to carry out risk management

The reality is it’s never too late, because failing to identify risks doesn’t make them go away; a risk identified is a risk that can be managed. Failing to identify and manage risks means that projects are taking risks blindfolded, leading to a higher number of problems and issues, and more missed opportunities. Even where project objectives are presented as “fixed,” this does not guarantee that they are achievable, and the aim of the risk process is to maximize the chances of achieving objectives.

I’m too busy dealing with issues

This excuse can become a self-fulfilling prophecy. If risk management never starts, then more issues will arise that require immediate attention, reinforcing the problem. This downward spiral must be nipped in the bud. Making risk management mandatory might solve the problem, though there is a danger that imposing a risk process will result in project teams only paying lip service to it. A better strategy is to make a convincing argument that risk management is actually good for the project, and that carrying it out will prevent further issues and make life easier.

It’s just common sense

The problem with common sense is that it’s not very common. Risk management cannot be left to intuition because the stakes are too high. Of course, some people are very good at managing risk intuitively, and these individuals might be able to trust their common sense instead of following a structured approach to risk management. However, most people require some assistance in taking theCo

py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

necessary steps to identify and manage risk effectively. For the majority, having a framework within which to conduct the risk process is both helpful and necessary. A structured approach to risk management helps everyone do what the best practitioners do intuitively.

We can’t prove that risk management works

This excuse might exist where the risk process is focused entirely on threats, since it is difficult to prove unambiguously that an absence of problems resulted from successful risk management. However, when the risk process also addresses upside risks (opportunities), a successful risk process results in measurable additional benefits, including saved time, reduced cost, and reduced rework. We recommend a broad approach to risk management covering both threats and opportunities; where this is implemented, evidence that risk management works can be gathered. It should also be recognized that risk management delivers a range of “soft” benefits in addition to those that are directly measurable, as reflected in , which presents “hard” and “soft” benefits of risk management as listed in the Figure 2-3

. Many of these benefits offer demonstrable proof of risk management’s value to anAPM PRAM Guide organization and its projects. Finally, evidence can be sought from either within the organization or other similar organizations by reviewing case studies of successful projects where the results are attributed to effective risk management.

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

Figure 2.3 Benefits of Risk Management

The Critical Success Factors for Risk Management

All of the common reasons/excuses for not applying risk management can be overcome by focusing on CSFs. It is possible to generate a long list of CSFs (for example, ); these have been groupedFigure 2-4 into four main categories for discussion in the following paragraphs.

Supportive organization

A supportive organization behaves in such a way that it is seen to be fully behind risk management and all it entails. The organization “walks the talk.” It ensures that there are clear objectives for risk management and that these objectives are bought into by all stakeholders, who also contribute inputs and commit to using the outputs of the process. The organization allows time in the schedule for risk management, and it ensures that risk management occurs as early as possible in the project life cycle. The organization also provides the necessary resources and funding to carry it out. Supportive organizations recognize that the extra work identified to manage risks is fundamental to ensuring project success and needs to be adequately resourced. These organizations also accept the need to change in response to risk, and, where appropriate, provide a suitable contractual framework to facilitate the process.

Figure 2-4 Critical success Factors for Effective Risk Management

In the same way that individuals have an attitude to risk that affects their participation in the risk process, organizations also have a “risk culture” that reflects their preferred approach to dealing with uncertainty. There is a range of organizational risk cultures, as illustrated in .Figure 2-5

Organizations with a negative attitude to risk might be labeled as “risk-averse”; those with no strong response could be called “risk-tolerant”; “risk-seeking” organizations have a positive attitude toward risk. A fourth type of organizational risk culture is “risk-neutral,” displaying a short-term risk aversion combined with a longer-term willingness to seek risk. These cultures have a significant influence on theCo

py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

risk management process. For example, extreme risk aversion can sometimes develop into hostility: “We don’t have risk in our projects; we’re professionals/engineers/scientists.…” Denial results in important risks being ignored, and decisions being made without cognizance of the associated risks. At the other end of the scale, the risk-seeking organization might adopt a “gung ho” attitude to risk, which will likely lead to disaster if the amount of risk exposure taken on exceeds the organization’s ability to manage it.

The preferred risk attitude for an organization is neither risk-averse nor risk-seeking; rather, it is “risk-mature.” This attitude produces a supportive culture in the organization, which recognizes and accepts that uncertainty is inevitable, and welcomes it as an opportunity to reap the rewards associated with effective risk management. These organizations set project budgets and schedules with the knowledge that uncertain events can influence project progress and outcomes, but also with a commitment to provide the necessary resources and support to manage these events proactively. Project managers and their teams are rewarded for managing risks appropriately, with the recognition that some unwelcome risks occur in even the best-managed project.

Figure 2-5 Range of organizational Risk Cultures (based on Hillson and Murray-Webster 2007)

Culture is the total of the shared beliefs, values, and knowledge of a group of people with a common purpose. Culture therefore has both an individual and a corporate component. For risk management to be effective, the culture must be supportive, meaning that individuals’ risk attitudes must be understood and managed, and the organization’s overall approach must value risk management and commit to making it work.

Competent people

For many people, risk management seems to be neither common sense nor intuitive. Project sponsors, project managers, team members, and stakeholders must be trained in applying the process, participating in it, or both. Training also needs to be at the right level and depth to suit the role involved. Effective training creates a shared understanding of the key concepts and principles of risk management. It enables the establishment of a common language and agreement on key risk management terms. Properly delivered training also helps to convince participants of the benefits of the process.

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

Training should not be viewed as a one-off event carried out when formal risk management is first introduced. It must be a continual process, bringing new members of the organization up to speed as soon as is practical. The end benefit of effective training is skilled and competent staff who contribute effectively to the risk process.

Attention should also be paid to ongoing competence development, with on-the-job training, job rotation, mentoring, and coaching, in addition to focused formal training courses. The aim is to develop practical skills as well as theoretical knowledge, encouraging effective behaviors and appropriate attitudes.

Appropriate methods, tools, and techniques

Different organizations may implement risk management in varying levels of detail, depending on the type of risk challenge they face. The decision about implementation level may also be driven by organizational risk appetite—the overall willingness or hunger to expose the organization to risk—and by the availability of funds, resources, and expertise to invest in risk management. The objective is for each organization to determine a level of risk management implementation that is appropriate and affordable. Having chosen this level, the organization then needs to provide the necessary infrastructure to support it.

Having selected the level of implementation, providing the required level of infrastructure to support the risk process is then possible. This might include choosing techniques, buying or developing software tools, allocating resources, providing training in both knowledge and skills, developing procedures that integrate with other business and project processes, producing templates for various elements of the risk process, and considering the need for support from external specialists. The required level for each of these factors will be different depending on the chosen implementation level.

Failure to provide an appropriate level of infrastructure can cripple risk management in an organization. Too little support makes efficient implementation of the risk process difficult, while too much infrastructure and process can be overly bureaucratic and fail to add value, in fact reducing the overall benefit. Getting the support infrastructure right is therefore a Critical Success Factor for effective risk management, because it enables the chosen level of risk process to deliver the expected benefits to the organization and its projects.

A simple, scalable process

Risk management is not “one size fits all.” While all projects are risky, and risk management is an essential feature of effective project management, there are different ways of putting risk management into practice. At the simplest level is an informal risk process in which all the phases are undertaken, but with a very light touch. In this informal setting, the risk process might be implemented as a set of simple questions. For example:

• What are we trying to achieve?

• What could hinder or help us?

• Which of these are most important?

• What shall we do about it?

If these questions are followed by action and repeated regularly, the full risk process will have been followed, though without use of formal tools and techniques.

At the other extreme is a fully detailed risk process that uses a range of tools and techniques to support the various phases. For example, using this in-depth approach, stakeholder workshops might be used forCo

py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

the definition phase, followed by multiple risk identification techniques involving a full range of project stakeholders. Risk assessment would be both qualitative (with a Risk Register and various structural analyses) and quantitative (using Monte Carlo simulation, decision trees, or other statistical methods). Detailed response planning at both strategic and tactical levels might include calculation of risk-effectiveness, as well as consideration of secondary risks arising from response implementation.

Both of these approaches represent extremes, and the typical organization will wish to implement a level of risk management somewhere in between these two. These approaches do, however, illustrate how it is possible to retain a common risk methodology while selecting very different levels of implementation. Each organization wanting to adopt risk management consistently must first decide what level of implementation is appropriate.

A simple to use, scalable, and documented process ensures that each project does not have to work out the best way to apply risk management in its situation. An efficient procedural framework that supports the process and outlines “what to do” ensures support from the organization and makes the most of the investment in training, tools, and techniques.

Conclusion

This chapter presented some of the common difficulties expressed by people who feel that risk management belongs in the “too difficult” category. It also offered counterarguments to each objection, suggesting that attention to CSFs can make the difference between wasting time on an ineffectual process and implementing risk management that works. If any of these supporting elements (see Figure

) are weak or missing, then the implementation of risk management becomes unstable and may even2-6 fall over.

Figure 2-6 Critical Success Factors to Support Effective Risk Management

Out of the four groups of CSFs discussed, the one that seems easiest to address is theC op yr ig ht @ 2 01 2. B er re tt -K oe hl er P ub li sh er s.

last—implementation of a simple, scalable process. This CSF allows project teams to apply risk management theory to their particular risk challenge. It also deals most directly with the main difficulty expressed by so many: “How exactly do we do risk management?” The rest of this book presents a detailed answer to this question, describing a simple scalable risk process that can be applied on any project in any industry. The next chapter introduces this process, known as Active Threat and Opportunity Management (ATOM), and of the book describes the ATOM process in detail.Part II

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

CHAPTER 3

Active Threat and Opportunity Management—The ATOM Risk Process

he benefits of formal risk management are undeniable and clear for all those who care to see. Even though this fact is recognized by many organizations, the reality is that risk management is rarely implemented effectively, often despite well-defined processes, the existence of proven tools and

techniques, and many training opportunities for those who need it. If this is the case, then where is the problem? It appears that ineffectiveness stems largely from project managers and their teams not knowing how to actually do risk management. Clear, practical “how to” guidance is obviously needed; this also meets one of the four Critical Success Factors (CSFs) for risk management outlined in the previous chapter: a simple to use, scalable, and documented process that removes many of the barriers to the use of risk management for projects and provides invaluable help to those who believe it to be important but are struggling to make it effective.

First we must determine what such a simple, scalable process should cover. A number of important steps must be included:

• If risk is defined as “any uncertainty that, if it occurs, would have a positive or negative effect on achievement of one or more objectives,” then clearly the first step in a risk management process is to ensure that the objectives at risk are well defined and understood. These objectives might have been clarified outside the risk process (for example, in a project charter, business case, or statement of work), but risk management cannot begin without them, so if there is no clear list of project objectives, the risk process must produce one.

• After defining objectives, determining the uncertainties that might affect them is possible. As discussed in , potentially harmful uncertainties (threats) must be identified, as mustChapter 1 those that might assist the project in achieving its objectives (opportunities).

• Of course, not all of the uncertainties identified in this way are equally important, so the risk process must include a step for filtering, sorting, and prioritizing risks to find the worst threats and the best opportunities. Examining groups of risks to determine whether there are any significant patterns or concentrations of risk is also useful. It might also be good to determine the overall effect of all identified risks on the final project outcome.

• Once risks have been identified and prioritized, the risk challenge faced by the project will be clear and the risk process can move from analysis to action. At this point attention turns to deciding how to respond appropriately to individual threats and opportunities, as well as considering how to tackle overall project risk. A range of options exists, from radical action such as canceling the project to doing nothing. Between these extremes lies a wide variety of action types: attempting to influence the risk, reducing threats, embracing opportunities, etc.

• The important step of planning responses is not enough to actually change risk exposure, of course; it must be followed by action, otherwise nothing changes. Planned responses must be implemented in order to change the risk exposure of the project, and the results of these responses must be monitored to ensure that they are having the desired effect.

• These steps in a risk process might be undertaken by just a few members of the project team, but the results are important for everyone, so it is essential to communicate what has been

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

1. 2. 3. 4. 5. 6. 7. 8.

decided. Key stakeholders should be kept informed of identified risks and their importance, as well as what responses have been implemented and the current risk exposure of the project.

• Clearly the risk challenge faced by every project is dynamic and changing. As a result, the risk process must continually revisit the assessment of risk to ensure that appropriate action is being taken throughout the project.

• A fully effective risk process does not end at this point, because the learning organization wants to take advantage of the experience of running this project to benefit future projects. The normal Post-Project Review step must, of course, include risk-related elements so that future threats are minimized and opportunities captured in the most efficient and effective manner.

Introducing ATOM

The logical story outlined above is not rocket science, but it does offer a simple, structured way to deal with the uncertainties that might affect achievement of project objectives. Any project risk management process should follow these eight steps:

Define objectives Identify relevant uncertainties Prioritize uncertainties for further attention Develop appropriate responses Report results to key stakeholders Implement agreed-upon actions Monitor changes to keep up-to-date Learn lessons for the future.

Active Threat and Opportunity Management (ATOM) is designed to meet the need for a simple scalable risk management process and to be applicable to all projects. It also embodies the steps described above in a generic risk management process that can be applied to all projects in any industry or business sector, whatever their size or complexity. ATOM brings together recognized best practices and tried-and-tested methods, tools, and techniques, combining them into an easy-to-use yet structured method for managing project risk.

The ATOM process is composed of the following eight steps:

Initiation Identification Assessment Response Planning Reporting Implementation Review Post-Project Review.

The Assessment step might also include quantitative risk analysis to determine the effect of risks on overall project outcome, though this is not always required (as discussed below). shows howFigure 3-1 these steps fit together into a cohesive process, which is described in detail for a typical project later in this chapter.

Of course, risk does not appear just at the beginning of a project and then go away, so a risk management process cannot be performed just once. The ATOM approach recognizes the undeniable need to carry out risk management throughout the project life cycle, from concept to completion, or

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

from the business justification to handover, as shown in .Figure 3-2

Figure 3-1 Steps in the ATOM Process

Figure 3-2 Steps Through the Project Life Cycle

Risk management is all too often seen as something done at the beginning of the project and then cast aside as other “proper project management processes” take over. This is clearly wrong. ATOM demands that, following an initial risk assessment, a series of reviews are undertaken through the life cycle of the project to keep the process alive. It is also important to recognize that part of any project’s value is the organizational learning it offers to the business, which is why ATOM places emphasis on lessons learned as an essential part of project management. The ATOM risk management process also includes aCo

py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

final step to capture risk-related lessons at the end of a project, concluding with a formal Post-Project Review.

Figure 3-2 shows how the ATOM risk process might be conducted through the various phases of the project life cycle. For a typical project, ATOM starts before the project is sanctioned or approved, by undertaking the Initiation step leading to a Risk Management Plan, followed by a First Risk Assessment to determine the risks associated with implementing the project. After the project sanction or approval, ATOM continues with a series of reviews throughout the project life cycle. The project life cycle is different for a contracting organization, which bids for work and only conducts the project if it wins it. For some contractors, ATOM starts when they win the work, which is when they undertake the Initiation and First Risk Assessment steps. For other contractors, ATOM starts during the bid process and is an integral part of putting the bid together. It is likely that a contractor that carries out Initiation and First Risk Assessment as part of the bid process will repeat the process if the bid is successful.

Project Sizing

No two projects are the same. Projects vary vastly in size and complexity. Some projects are started and finished in a few weeks, while others take a decade or more to complete. Some projects have budgets of a few thousand dollars (or even no budget at all), while others cost billions. Some projects are relatively routine, using tried and tested strategies, while others are totally innovative and groundbreaking.

In response to this wide variety of projects, ATOM offers a fully scalable risk management process that recognizes that simple or low-risk projects may need just a simple risk process, while complex or high-risk projects require more rigor and discipline. ATOM provides scalability in three ways: through the number and type of reviews required during the project life cycle, through the optional use of quantitative risk analysis techniques, and through the range of tools and techniques used during each of the ATOM steps.

• . Sometimes simply revisiting the risk process to determine changes to existing risksReviews and whether any new risks have arisen is sufficient. At other times a full repeat of the entire risk process might be appropriate. ATOM uses two types of reviews to meet these needs: a Major Review and a Minor Review. These can be used in various combinations depending on the size of the project.

• . ATOM suggests reserving use of quantitative analysis forQuantitative risk analysis projects that are large or high-risk, where the investment in such techniques can be justified.

• . Many techniques exist for the identification and assessment of risks.Tools and techniques An appropriate set of techniques should be selected to meet the risk challenge of a particular project.

Figure 3-3 presents the full scalable ATOM risk process, indicating where reviews and quantitative risk analysis (QRA) might occur. Broken lines in indicate the optional nature of QRA.Figure 3-3

With a scalable process, a method of deciding what level of process is appropriate for any particular project is clearly important. “Project size” is a multidimensional concept with many factors to be considered. It is also a continuous variable, rather than one with a small number of discrete values. However, it is useful to have a simple tool that uses various criteria to characterize a given project, perhaps dividing projects into three groups that we can call small, medium, or large. This tool has several uses, not just relating to risk management, because many project management processes can also be scalable depending on the size of the project.

One key question is how many criteria should be used in such a sizing tool. If too few criteria are used,Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

then it is difficult to distinguish between projects of different sizes. On the other hand, too many criteria can become overly complex and can lead to insufficient discrimination due to the averaging effect. Experience suggests that using 10 to 12 criteria is about right, giving a good compromise between detail and usability. Each organization should define those criteria that best describe the relative size and importance of a project within the business. One organization’s “small” will be another organization’s “large.”

Even where sizing criteria are well defined, an organization may wish to allow shortcuts to describe circumstances in which project size can be determined without use of the project sizing tool. For example, projects of very low value or very short duration might always be deemed small, while business-critical projects might always be large.

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

Figure 3-3 The Full ATOM Process

Figure 3-4 presents a sample project sizing tool to illustrate the approach that an organization might adopt in order to size a project. This example uses a Likert scale to translate qualitative descriptions ofCo

py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

the sizing criteria into quantitative values that can be combined into a sizing score. Thresholds are then set to define small, medium, and large. Any given project can then be scored against the criteria in order to determine its size.

The example in is specific to a particular business, but can be tailored by anotherFigure 3-4 organization to include those criteria that reflect the types of projects it undertakes, because the general principles should apply. Other criteria could include “relationship with other projects,” “exposure to the wider business,” or “political sensitivity.” Note that the numerical thresholds used in the example in

are scaled to work with ten criteria and must be adjusted if more or fewer criteria are used.Figure 3-4

Of course, there are exceptions to every rule, and it is important not to be process-driven when making important decisions on projects. There will always be projects that score as medium or small using a project sizing tool, but that are so strategically important or commercially sensitive that it would be foolhardy not to treat them as large. Such decisions to contradict the output of the project sizing tool should only be made by the project sponsor in consultation with the project manager.

Figure 3-4 Example Project Sizing Tool

Most project-based organizations have a portfolio of projects of various sizes, including small, medium, and large ones, all of which require active management of risk, though at different levels. A reducedCo

py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

level of risk management attention is appropriate for small projects because they matter less to the business and the potential for variation is usually small. By contrast, large projects require a higher level of risk management attention because any variation is likely to be significant.

The typical ATOM process is designed for medium-size projects, though it is scalable for small and large ones. Taking the basic ATOM process as shown in , the main differences for the threeFigure 3-3 project sizes are as follows:

• Small projects require a reduced ATOM risk management process that is integrated into the normal day-to-day management of the project without using dedicated risk meetings.

• Medium projects require the application of the standard ATOM risk process with risk-specific activities in addition to the normal project process. These are led by a risk champion who oversees the use of specific risk meetings, including workshops, interviews, and ongoing reviews.

• Large projects require an extended ATOM process, which includes quantitative risk analysis and a more rigorous review cycle in addition to the elements applied for medium projects.

It is important for the depth of the risk process to match the risk challenge of the project. For example, applying a reduced risk process to a medium or large project is likely to result in the failure to properly resource the process and ineffective management of risk.

The ATOM process for a medium-size project is described in detail in ( through )Part II Chapters 4 12 and is summarized below. Recommended variations in using ATOM for small and large projects are covered in and , respectively.Chapters 13 14

ATOM for the Typical Project

The ATOM process for a typical medium-size project requires a structured approach, as follows.

Like most other risk management processes, ATOM starts with an Initiation step. This step, described in , considers project stakeholders and their relationship to the project. A fundamental part of theChapter 4

Initiation step is confirmation of the project objectives to ensure that they are clearly understood and documented, and as a result the uncertainties that matter can be determined and subsequently prioritized. The size of the project, and therefore the degree to which ATOM should be applied, is also confirmed. Initiation culminates with the preparation of a Risk Management Plan.

This is followed by three sequential steps that make up the First Risk Assessment, namely Identification, Assessment, and Response Planning. A formal two-day risk workshop is used to identify project risks (see ) as well as to assess their probability and impacts against predefined scales as set out inChapter 5 the Risk Management Plan (see ). The aim of the Identification step is to identify and properlyChapter 6 describe relevant uncertainties, including both positive opportunities and negative threats that could affect project objectives. Assessment provides the means to determine which uncertainties matter most to the project, by considering the probability of the risk occurring and its potential impact on the defined project objectives. During Identification and Assessment, all identified risks and their assessment data are recorded in a newly created project Risk Register. Following the risk workshop, Response Planning takes place via a series of interviews with identified risk owners, during which responses are identified with their associated actions (see ). The appropriateness of the response is paramount to thisChapter 7 step to ensure that responses are not only physically effective but also timely and cost-effective.

Once the First Risk Assessment step is complete, the next two steps in the ATOM process take place in parallel. A risk report documenting the results from the First Risk Assessment is prepared and disseminated to those who need to receive it; this Reporting step is described in . Reporting isChapter 8Co

py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

one of the ways in which the dynamic nature of risk is communicated, because reports highlight significant changes to project risk exposure.

At the same time as the Reporting step, the ongoing step of Implementation of responses via their associated actions also starts (see ). Implementation of responses continues throughout theChapter 9 project, only concluding when the project ends. Without effective implementation, the risk exposure of the project remains unchanged.

Fundamental to keeping the process alive throughout the project life cycle is the use of formal risk reviews. At predetermined points in the life cycle, as set out in the Risk Management Plan, a Major Review (see ) takes place that includes the same elements as the First Risk Assessment but onChapter 10 a reduced scale. All key stakeholders attend a risk workshop to review existing risks and identify and assess new risks, resulting in an update to the Risk Register. Risk responses and their associated actions are identified by interviewing risk owners as soon as possible after the risk workshop. Agreed-upon responses and actions are recorded in the Risk Register. New and revised actions are implemented through the ongoing Implementation step. A full report is produced at the end of the Major Review.

At regular points in the project, usually in line with the normal project reporting cycle, risk management is formally revisited as part of a Minor Review (see ). A Minor Review may take place asChapter 11 part of a normal project review or as a separate meeting. During a Minor Review all high-priority risks are reviewed, new risks are identified and assessed, and responses are planned; the Risk Register is then updated. As for the Major Review, new and revised actions are implemented through the ongoing Implementation step. A summary report is produced at the end of each Minor Review.

The ATOM process concludes either at the formal Post-Project Review meeting or at a separate meeting, during which a “risk lessons learned” report is produced and the final Risk Register agreed upon. describes this conclusion to the ATOM process.Chapter 12

The ATOM process for the typical medium-size project is purely qualitative, with no use of statistical processes to predict the overall effect of risk on project outcome. Quantitative risk analysis techniques are an important part of project risk management, but ATOM suggests that they should only be mandatory for large projects. This does not, however, mean that quantitative risk analysis cannot be used effectively on medium or even small projects, but this analysis should be at the discretion of the project manager and considered during the ATOM Initiation step. Quantitative risk analysis is valuable because it models the effect of identified risks on the project schedule and budget, calculating the range of possible completion dates (and interim milestones) and final project cost. It is also possible to predict ranges of outcomes for other project criteria, such as net present value (NPV) and internal rate of return (IRR). This information can be beneficial when determining the correct strategy for the project and for understanding the effects of managing individual risks. describes how to apply quantitativeChapter 15 risk analysis to projects.

Comparison to Existing Standards

There are a number of standards documents in the project risk management area offering different approaches to the subject, as well as more general risk standards that include projects in their scope. The most popular of these include:

• ISO 31000:2009— from the InternationalRisk Management—Principles and Guidelines Organization for Standardization (ISO)

• BS 31100:2011—Risk Management—Code of Practice and Guidance for the Implementation of BS ISO 31000 from the British Standards Institute

• from the UK Office for Government Commerce (OGC)Management of Risk (M_o_R)C op yr ig ht @ 2 01 2. B er re tt -K oe hl er P ub li sh er s.

• IRM/ALARM/AIRMIC Risk Management Standard

• from the Project Management Institute (PMIPractice Standard for Project Risk Management )®

• from the ProjectGuide to the Project Management Body of Knowledge (PMBOK Guide)®

Management Institute, particularly , “Project Risk Management”Chapter 11

• from the Association for ProjectProject Risk Analysis and Management (PRAM) Guide Management (APM)

• from the UK Institution of CivilRisk Analysis and Management for Projects (RAMP) Engineers, Faculty of Actuaries and Institute of Actuaries

• BS IEC 62198:2001—Project Risk Management—Application Guidelines

• BS 6079-3:2000—Project Management— : Guide to the Risk Management of BusinessPart 3 Related Project Risk

Although there are several different standards covering the topic, there is good agreement between their content, with the main differences being terminology used. Those familiar with these standards should have no problem in understanding or applying the ATOM process, since it is fully consistent with them all. The key differences between ATOM and the other standards are summarized in , whichFigure 3-5 compares their use of terminology, the different constituent stages of each process (mapped to ATOM steps labeled as A-H), and the unique aspects of each approach.

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

Figure 3-5 Comparison of Different Standards

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .

The fact that ATOM is consistent with the main project risk management standards raises the question of why it should be used instead of what already exists. The main difference is that ATOM is not a standard. Instead it is a practical method that describes how to do risk management for a real project, rather than a theoretical framework or set of principles. It is intended to make project risk management accessible to all and easy to use, with enough detail to support practical implementation on any project in any organization or industry type.

Conclusion

One of the main Critical Success Factors for effective risk management is a simple, scalable process. ATOM offers such a process, and following it allows any organization to identify and manage risks to its projects in a way that is appropriate and affordable. Using ATOM provides assurance that the main risks will be exposed, thereby minimizing threats, maximizing opportunities, and optimizing the chance of achieving project objectives.

Co py ri gh t @ 20 12 . Be rr et t- Ko eh le r Pu bl is he rs .