Risk Identification and Analysis
· Defining Risk Management
· The Components of a Risk Statement
· The Risk Management Process
There are risks in every project, and the biggest mistake you can make is to ignore them and hope they’ll go away by themselves. In this chapter we’ll discuss proactive risk management, and find how using this process helps you deal with risks before they become actual problems.
Proactive risk management is a five-step plan, in which risks follow each phase of the project until they are eliminated, become of minor consequence, or become a problem that is dealt with accordingly.
Using this approach involves a number of forms, charts, and tables that make managing risks relatively easy. Within a short time, you’ll find that using this approach becomes second nature, and the possibility of loss is effectively kept at bay.
Risk is the possibility of suffering some sort of loss, and it is inherent to any project. The only way to avoid risk is to do nothing, and that means there is no chance of making any profit whatsoever from a project. Risks include anything from the project going over budget, to schedules not being met, to the project as a whole failing. There are all sorts of risks involved in any project, and that’s why risk management is so important.
As we’ll see later in this chapter, there are different ways of managing risks. In Microsoft’s definition though, risk management is a “discipline and environment of proactive decisions and actions to assess continuously what can go wrong, determine what risks are important to deal with, and implement strategies to deal with those risks”. In other words, it’s a way of dealing with problems before they happen. This involves implementing strategies that determine what risks are involved in a project, whether they’re important enough to be a priority, and continually assessing problems that arise during the course of a project.
If you have already dealt with forms of risk management on a project, you know it can seem like a boring, tedious task that’s bogged down in bureaucratic red-tape. This need not be the case. The Microsoft Solution Framework (MSF) addresses the problems of risk management by creating a dynamic discipline that involves all members of a project. Microsoft’s discipline of risk management is a five-step process, comprised of:
1. Risk identification
2. Risk analysis
3. Risk action planning
4. Risk tracking
5. Risk control
Rather than merely moving from one step to another in the process, risks are reassessed throughout the project. As new risks are identified, they are addressed with the five-step process. While we introduce these steps here, they are discussed in depth throughout the bulk of this chapter.
The issue of environment is crucial to good risk management. It is important that everyone involved in a project feels comfortable discussing potential problems with both superiors and subordinates. While people generally feel comfortable discussing risks with those who are below them in the chain of command, there is often a problem discussing potential problems with superiors. It can be a grueling experience telling your boss that a schedule can’t be met or that features may not be included in the current version. In environments that don’t promote good communication, this often results in risks becoming full-blown problems.
It is important to remember that identifying a risk and invoking a discussion about it, doesn't mean that you’re saying a problem exists. A risk is a potential problem, which doesn’t necessarily mean that it is inevitable and can’t be avoided or remedied. It is the possibility of a loss, not a certainty. By having an environment where everyone involved in a project feels comfortable discussing risk, strategies can be employed to deal with these potential problems.
The first, and most important thing, to remember about risk management is that risk is the possibility, and not the certainty, of loss. Though it’s common for project teams to consider risks to be something negative, taking risks is important to progress. For example, let’s look at something you can personally relate to right now, studying and taking the “Analyzing Requirements and Defining Solution Architectures” exam. You’ve probably identified certain risks in this: a schedule that needs to be met in taking the exam, possibly failing the exam the first time, and deciding whether to change jobs when you are certified. To deal with these risks, you’ve done some sort of risk management to lessen the odds of loss: you’ve adjusted your schedule to be prepared for the exam date, you’ve purchased this book and studied to avoid failing, and you've talked to management about a promotion. In taking these risks and managing them, you’ve pushed yourself forward and made progress toward becoming an MCSD. From this, you can see that just because a risk is identified in a project, it doesn’t mean you’re going to experience a loss.
The same goes for risk management in software development. Risk allows you to see where pitfalls may lie ahead, and manage them so they don’t become a major issue and result in loss. Once you can see where the possibility of loss exists, you can take action so that losses don’t occur, or deal with the problems once they’ve happened.
Good risk management requires having a project team assess risks throughout the course of a project. It is not uncommon for projects to make the mistake of identifying and assessing a risk at the beginning of a project, then failing to reassess the risk as the project progresses. For example, let’s say you are working on a project for the Nutbar Company. At the beginning of the project, it looked as if time factors dictated that certain features wouldn’t make it into the software you were creating. After some mitigation, you decide to subcontract some of the programming on this Nutbar project to a small software firm. End of risk, right? Not necessarily; if the subcontractor falls behind on coding and can’t make your deadline, it could mean these features still won’t be added. Without reassessing risks continuously, you run the risk that a potential problem will become a full-blown problem that results in loss.
The information gathered from the assessment of risks is used for making decisions on every phase of a project. Each team role (discussed in Chapter 2) must be aware of the risks involved in a project, and feel free to discuss those risks. If they aren’t involved or made aware of the decisions made by others when assessing risks, it can snowball into further problems. To use the previous example, let’s assume that the end result of the risk is that a feature isn’t included. Development needs to know this, so they don’t code the interface to access the feature. Testing needs to be aware of it, so they don’t waste time trying to access and test the feature. As the project progresses from a concept to an actual physical product, the information gathered from the assessment of risks will influence what is done, how it is done, and whether actions are driving further loss.
There are risks inherent in any project. There isn’t a project that’s ever been undertaken that didn’t involve some sort of risk. The major principle of risk management is dealing with the risk, and thereby lowering your odds that a loss will result. This means addressing the source of the risk, so that you don’t have to deal with the consequences.
For every project there are a number of sources of risk. The source of a risk is an object, person, or structure that provides the possibility of loss in a project. For every source of a risk, there is a related consequence that can result from ineffective risk management. It’s a simple matter of cause and effect. If you ignore the budget, you could wind up with cost overruns. If you ignore the schedule, it might slip. It is important to identify the sources of risk related to your particular project, so they can be properly addressed and you don’t have to deal with the consequences.
A risk source is made up of three components: risk factor category, focus area, and risk factor. The risk factor category breaks the project into small groups, each of which contain individual risk factors. There can be many risk factor categories in a project, including the following:
· mission and goals
· customer and end user
· organizational management
· operational environment
· development environment
· development process
· decision drivers
· project characteristics
· personnel
· technology
· schedule
· budget and cost
The focus area is an area of the project that is being focused on for risk management. It can include such areas as component-based development, custom software development, packaged software deployment, infrastructure deployment, enterprise architecture planning, and management of enterprise programs. The risk factor is the final component of a risk source that is used to identify the risk. As we’ll see, this can include such things as size of the project, availability of facilities, project fit, governmental regulations, and political influences.
Unfortunately, there is no simple list of risks and sources to memorize. While we discuss many of the common risks and risk sources in this chapter, it doesn’t necessarily mean that you’ll find them to be a possible threat to the success of a project. For example, when Microsoft introduced Windows 95, software development shifted to 32-bit programming for mainstream operating systems. While this technology shift was an issue for projects under development at the time (for Windows 3.1), the risk that this technology would change again wasn’t an issue in the initial projects that followed. Just as organizations and projects are different, risks and risk sources can thereby be different. What may be significant to one project may not necessarily be the case on other projects.
One of the most common risk sources involved in any project is scheduling. Time is a limited commodity, and only so much of it will be given to a project team to complete a product. As such, a schedule has an extensive list of risks associated with it, including the following:
· Schedules being overly optimistic Rather than including a bit of pessimism that some time might be lost, a best-case scenario is used. This often results in the project not being completed on time.
· Target dates are moved up When this happens, there is often a need for a tradeoff in other areas. Either the budget needs to be increased to pay for overtime and/or additional team members, or features need to be dropped. If there isn’t a tradeoff, then this becomes a significant risk.
· Delays in one area of the schedule have a cascading effect on other areas When tasks can’t be completed on time, it affects time allotted to other tasks.
·
The schedule is so intense
that the pressure of meeting it reduces productivity, and causes the schedule to
slip.
·
Tasks that are necessary to
the project’s success aren’t included in the schedule.
In any project you’re involved with, scheduling will have some risks associated with it. It is important to address these risks early in a project, as the project itself will follow this timeline. As the project progresses, the schedule should be reassessed. If it is found that it is unreliable, base any adjustments on how the project is going to date. The worst thing that can be done when an overly optimistic schedule is reassessed, is readjust it with great optimism. Remember to be realistic!
On the Job: Schedules can be a major problem in risk management. People naturally want to impress their boss, and often create schedules that are based on best-case scenarios. It is important to be a little pessimistic in schedules, or the first time a flu bug hits your team, the schedule will slip. In addition, it is important that all of the tasks that are necessary to the project’s success are included in the schedule. This may seem obvious, but after spending any length of time on a schedule, it’s easy to miss something. A good rule of thumb for making sure everything’s included is this: when you feel you’ve included everything in the schedule, don’t submit it! Set it aside for at least 24 hours; then review it. This allows you to view it fresh, and certain things you’ve omitted from the schedule will often jump out at you.
Just as there is only so much time to complete a project, there is only so much money that will be allotted to it. If you’ve ever bashed heads with an accounting department, you know this to be true. Budgets are another common source of risk, and also have a number of risks associated with them:
· The budget associated with the project has been cut As such, areas of the budget will need to be tightened, features may need to be dropped, and personnel may need to be dismissed. This can affect the morale of a team, and lower productivity.
· Costs associated with the project have changed since the original budget was drafted As such, more money is needed.
· The budget hasn’t taken into consideration certain items This can include the possibility for overtime, additional staff that is needed, and fees for contractors that have been hired.
These are but a few of the risks associated with the risk source of budget and cost. As with other risk sources, risks associated with budgets and costs should be reassessed throughout the life of a project. You need to be aware of how close you are keeping to the initial budget, and whether the budget meshes with reality. Since money is involved, depending on how much extra is needed, it is often the case that other areas of a project (such as features in the software) are traded off to keep within the original budget.
As we saw in Chapter 2, it is vital that everyone working on a project understands the mission and goals. The primary risk is that if project members don’t understand what they are working toward and hoping to achieve, the project is destined for failure. The process of a project should be based on easily identifiable milestones. For this reason, we cover milestones in great detail in the next chapter. A common risk of missions and goals is that they are written in difficult to understand words, or cryptic language. You must be clear and straight to the point as to what each team role is working toward, and keep them up-to-speed on changes in the project.
Project characteristics are often a source of risk. Again, cryptic language and unclear wording in describing the specifics of a project can lead to confusion. If developers don’t understand what features are being asked for, it can lead to immense problems. If an Exit function needs to be added under the File menu, say that! Don’t ask for a “text-based feature to terminate said application and remove binary data from memory.”
The most common risk for project characteristics is change. Customers or end users suddenly realize that certain features aren’t needed, or decide that certain characteristics must be added. External environments, such as government regulations or technical standards, can also require changes in the project’s characteristics. Laws, technical standards, and business rules can have the annoying habit of changing at the worst times in a project’s life. When they do, you will be forced to change certain characteristics to meet these changes.
Anyone who has dealt with people realizes there are lots of risks involved. It is amazing the number of times that personnel aren’t fully considered in risk management. Issues such as morale, relationships, and teamwork are often missed when identifying risks. These three areas relate to productivity. If personnel isn’t properly motivated, or if morale is low, their productivity decreases. The same occurs if there is a poor relationship between team members, and a lack of teamwork. If developers and management don’t get along, then the decision-making process slows down, and personnel will feel uncomfortable pointing out risks they’ve identified in a project. It is important to provide inspiring leadership, and deal with personnel issues immediately. Remember that without personnel, all areas of a project will stall and possibly fail.
On the Job: Aside from the military, which takes morale very seriously, organizations and management sometimes seem to go out of their way to lower morale. One of the best superiors I’ve had did take this seriously, and promoted teamwork. The organization’s upper management saw this, and chastised her for it. She was told “not to be friendly with them” and to basically earn respect and obedience through fear. This is something I’ve heard in several organizations. However, it is surprising the number of risks you can eliminate with personnel when they feel like a team, are motivated, have high morale, and look forward to doing their jobs each day.
In addition to more intrinsic risks involved with personnel, there are numerous other risks:
· Hiring When hiring personnel taking longer than originally expected, the project is at risk.
· Prerequisites This includes training, lack of critical skills, and the completion of projects to which members are currently working on.
· Work habits Personnel are working slower than expected, or doing things that are affecting the productivity of other team members.
· Availability Certain personnel are available only on a part-time basis, tied up with other projects, or contract, permanent, or part-time personnel leave the project before it’s completed.
When dealing with personnel, the risks involved are as numerous and different as people. Each project has its own risks involving personnel, and must be identified on a project-by- project basis.
Personnel risks must be evaluated continuously in a project. It is a bad idea to merely put together a team, and not assess the risks involved with personnel as the project progresses. It is possible for a team to initially work well together but fall apart over time. Some people don’t work well together, and sometimes problem members need to be removed from a project. These are risks in themselves, and should never be dismissed or underestimated in their impact.
Other people-orientated risk sources are customers and end users. Customers and end users aren’t necessarily the same. Customers pay for the product, while end users are the people who actually use a product. This in itself can make for interesting situations, since while the customer may approve a product, the end user may decide that it isn’t satisfactory. Besides customers and/or end users disapproving of a product, other risks related to these sources include the following:
· Customer and/or end user insists on new requirements for the product.
· Customer and/or end user is dissatisfied.
· Input from the end user isn’t acquired, so the product doesn’t meet expectations.
· Expectations for completion of the project is beyond what development can provide.
· Customer is slow in making decisions or reviewing documentation regarding the project.
· Customer provides inadequate input regarding requirements.
Dissatisfaction from a customer or end user brings up another risk related to these sources: loss of the company’s image. If your product doesn’t meet expectations, or the project is looked poorly upon by a customer or end user, you can be sure that word-of-mouth about your company will be poor. This results in people thinking twice before buying your products, or hiring your software development firm.
Once you’ve worked on a computer for any length of time, you realize that technology has a plethora of risks. Networks go down and system requirements must be met before updated development suites (such as Visual Basic 6.0 and Visual Studio 6.0) can be installed. There is a rule of thumb that computer hardware components need to be upgraded every two years to keep up with the latest software technology. It used to be three years and still is in a best-case scenario, but changing market costs and depreciation of computers and other equipment has changed this rule. Beyond this, you will also experience that the customer’s requirements for a project aren’t possible, because technology hasn’t improved enough to provide the features your customer wants. For example, web cams, which are used to transmit sound and images across the Internet, weren’t available until relatively recently, but for decades a number of customers have been requesting the ability to chat face-to-face on the network.
Over the last few years, the development environment has been recognized as a risk source. Ergonomics has become a major theme in computing, with the theory being that if the environment is comfortable and conducive to good work, then productivity will improve. They’re right! It is difficult to do good work if facilities are noisy, disruptive, uncomfortable and/or crowded. While these are rather basic examples of ergonomic issues, it does give you an idea of how such things can affect the project.
Other risks of the development environment include facilities not being ready when the project begins. Imagine showing up for work, only to find there are no desks, chairs, working phones, or computers. One experience I faced was where they’d forgotten to deliver copies of Visual Basic to the office so we could develop software. In addition to things like this, where you get paid for fun-filled days of playing Euchre, the development environment also holds the risks of development tools not working as expected, or being chosen because they are cheap rather than functional. If you’re ready to work with Microsoft Visual C++, and find you’ll be using an unknown compiler called the Dead C Scroll, productivity is bound to suffer.
If you don’t face problems with the development environment, you may find risks in the development process. If this is poorly managed, it can spawn numerous problems. If there is poor tracking of progress, you may not realize that a project is behind schedule until it’s too late. In addition, if there is a bureaucratic adherence to policies and standards, you may find there is unnecessary work and additional overhead on a project. On the other end of the scale, if there is too much of a casual approach to software policies and standards, it can result in quality problems, miscommunication, or inevitably having to redo the same work on a product. The key to resolving this is finding a happy medium, where rules are adhered to, but not to an unreasonable level of following policies and standards.
Organizational management and the operational environment of a company must also be taken into account for a project to succeed. It is important to remember that the Information Technology department, and the project teams within them, are part of a larger organization. As such, the pressures of the organization’s management and the company’s operational environment have a major impact on a project’s success. In fact, Microsoft states that many, if not most, projects fail because the pressures of the larger organization are ignored in risk management.
The company’s operational environment and organizational management are two risk sources that hold an incredible amount of risks, and are often out of your control. While you have some control over the project’s budget, (unless you’re the owner) you don’t have control over the entire company’s financial health. Budget cuts, layoffs, and other cutbacks can upset the ability of a team to complete a project on time. In addition, there may be exhaustive pressure put on a project team by upper management. For example, it may be standard practice to burden a project team with incredible amounts of paperwork. Though meant to improve the performance of a team and project, too much can have people spending more time doing the paperwork than doing the actual work! If upper management is slow in making decisions, then this will also affect the project. Unfortunately, there is little you can do with these risk sources. If you were working on a project for Microsoft and had a problem with organizational management, they wouldn’t let you fire Bill Gates. You can only add these risks into the project’s overall plans and try to work around them.
The final risk source we’ll discuss here is risk management. This seems like an oxymoron, but it’s not. When risk management isn’t taken seriously, or when the process of identifying and dealing with risks is skimmed over, you’re tempting fate. Major risks associated with a project can be missed, and additional time must be spent backtracking over risk issues. If the risks are completely missed, then some sort of loss is involved. Schedules slip and additional costs can cause projects to go over-budget due to the initial half-hearted effort. It is important that risk management is taken seriously on projects, or these are but a few of the risks you will encounter.
There are basically two approaches to risk management: proactive and reactive. Proactive risk management deals with risks before they become problems that result in loss. Reactive risk management deals with risks after they’ve occurred.
Proactive risk management requires implementing a plan to manage risks. The process used in this case must be measurable and repeatable. In other words, not only will you be able to document procedures and their results, but you will be able to use them in other projects. Earlier in this chapter, we mentioned how the MSF’s proactive risk management model is basically a five-step process. This process is not only measurable in its success, but repeatable in that it has worked for numerous companies. Throughout the remaining sections of this chapter, we will discuss each of these steps in detail.
One approach to proactive risk management is elimination of risk sources and factors. This is basically a two-part process:
1. Identify the factors that cause the risk.
2. Eliminate these factors, so the risk is no longer present.
As we saw in the previous section, this isn’t possible in a number of cases. For example, if you’re having a problem with upper levels of organizational management, chances are you can’t make personnel changes at that level. However, let’s say you identify contractors as a risk source and you’ve found a particular contractor to have slow performance, or not deliver what’s expected. Now that this has been identified, eliminate the risk source by not hiring that contractor. This could mean not hiring that particular problem contractor, or completely eliminating the risk source by developing the entire product internally.
Higher levels of risk management go beyond this, and actually involve a willingness to take risks. Since risk is only the possibility of loss, this doesn’t mean that a loss will definitely result. Risk is therefore viewed as possible opportunity, where risks are identified, evaluated, and used to the team’s advantage. With risk comes opportunity. The sources of risks are evaluated, and used as a means rather than an end. For example, if it is known that the development environment won’t be ready immediately, this gives developers the opportunity to work on other projects until it is ready. If it is known that a subcontractor is usually two days late with delivering the work they’ve been assigned, then you can give a false due date that’s four days before the actual time it’s expected. By evaluating risk sources and risks effectively, you can embrace risks and use them to your advantage.
Preventing risk is the transition between the reactive and proactive approaches to risk management. During the planning stages of a project, a project team will consider the various risks in a project, and take actions to keep them from occurring. However, doing so doesn’t really deal with the source of a risk, only the symptom of that particular cause. This is like handing a tissue to someone with a cold; you haven’t found a cure to the common cold, you’ve only dealt with the symptom.
You’ve probably heard your father or grandfather use the phrase “there’s no point closing the barn door after the horses have run away!” This essentially captures the spirit of reactive risk management. Reactive risk management reacts to the consequences of risk rather than addressing the issues before an actual problem occurs. This may involve fixing problems after they’ve occurred, assigning resources at the beginning of a project to deal with problems after they’ve happened, or addressing the risk issues only after they become problems. In any case, the key to reactive risk management is that the risk has become a distinctive problem that has already occurred in the project.
The potential for risks is far too often overlooked during the initial stages of a project. Often, only a cursory look is given to the issues that can drag a project from the lofty heights of the best-case scenario. Proper definition of project scope, adjustments for changing markets, and proper communication of required resources are paramount to reducing project risks.
One of the most common failures is accepting the inherent risk when the scope of a project is improperly defined. Clients, end users, and customers are often fickle in their expectations when a clearly defined project scope and analysis documentation are not produced. This failure opens the door to increased volatility in customer expectations, leading to greater risks taken with budgets, schedules, and customer satisfaction.
Failure to produce or communicate a proper list of project resource requirements, for example, can lead to some unexpected increases in risks. Beginning phase two of a proof-of-concept project, only to find that the client has migrated the entire development system to a virgin system without the necessary software can certainly lead to increased risks of missing schedules or reducing functionality.
When analyzing risk, Microsoft emphasizes assigning a decimal, from 0 to 1, as a measure of risk probability. This can be used when assessing quantitatively the impact of a risk. Also, the Delphi method should be a familiar process, both for allowing collaborative input of risk analysis from team members, and as a good source of exam questions.
— by Michael Lane Thomas, MCSE+I, MCSD, MCT, MCP+SB, MSS, A+
Earlier in this chapter, we saw that it is important for
team members to be aware of the risks involved in a project. Relaying this
information involves more than yelling across the office, “Hey Bob, the
schedule is wacky! I don’t think we’ll make it on time!” This is where
risk statements come into play. Risk
statements are used to communicate the risks involved in a project, so that
members can effectively manage them. This not only includes mentioning the
symptoms of a risk, but what the result of a risk could be.
In creating a risk statement, you are delving into the first two steps of the proactive risk management process: identification and analysis. It is through these two steps that risks are assessed. Risk identification results in a list of risks that have the potential to cause problems in a project. Risk analysis evaluates the impact of the identified risks and considers alternatives to factors causing the risk. In the following section, we will go through each of these steps in detail.
The first step in the risk management process, and the process of creating a risk statement, is identification. Before anything else can be done, a risk must be identified. It is from the identification of risks that the project team can see what threats, opportunities, and possibilities face them in a project. By using this information, they can deal with risks before they become problems that might jeopardize a project.
Risk identification involves project members and stakeholders following a series of steps, which result in the identification and ranking of risk factors. This involves the following:
· Using risk factor charts
· Using risk assessment tables
· Discussing the risks openly and freely
· Ranking risks by importance
Risk factor charts are used to organize and categorize risks, so it can be determined how critical certain risks are to a project. In using the risk factor chart, members and stakeholders discuss and rank risks in order of importance. When this is done, a risk statement is developed, and the risk is entered on a master list.
A risk factor chart is used to determine whether a risk should be considered high, medium, or low. Though called a chart, it is actually a table used to document risk factors in a project. Risk factors are grouped by risk factor category and focus area, with one or more characteristics that describe the risk level. Risk factor categories are the categories of risk sources, which we previously discussed in the section on risk sources. The category determines what is being addressed in the risk factor chart. In the example shown in Table 3-1, personnel is the risk category that is being addressed. The focus area narrows the view of this category, and focuses interest on a particular area of the category. This can include such things as enterprise architecture planning, software development, packaged software deployment, and component-based development. The risk factor characteristics are used within the risk factor chart to label the risk level as high, medium, or low.
Risk
Factor |
Low-Risk
Cue |
Medium-Risk
Cue |
High-Risk
Cue |
Hiring |
Taking longer than expected. |
Some unqualified people are being hired, and will require additional training. |
Personnel department’s union may strike, and no hiring will take place. |
Key Personnel |
Three are tied up with another project, and will join a week into the project. |
Two are available only part-time. |
Two will not be available until late in the project. |
Table 1: Personnel Risk Factor Chart
What might be crucial to one project, may be of minor importance to another. As such, when ranking risks, you need to view the risk in the context of the current project. Just because you found a risk factor to be high ranking in a previous project, doesn’t mean it rates as high on the current project.
Ranking the importance of a risk can be difficult. Project members and stakeholders come from different backgrounds and experience, so they will view the risks differently. In addition, their diversified roles on the project team will affect what they consider to be vital. For example, Development will consider coding issues more critical than testing issues. Because of this, you can’t always expect agreement on how a risk ranks in the overall project. When this happens, it should be put to a vote. Majority rules is the easiest way to decide where the risk resides on a ranking of risks. If the vote is tied, then the worst case should be used for assessment.
Once risks have been identified in a project, the second step of the proactive risk management process comes into play. This is analysis. Analysis takes the raw data you’ve acquired, and converts it into information used in decision making. Analysis determines which risks pose the greatest threats and opportunities to a project, and thereby which risks the project members should work on. It is pointless to work on risks that are unlikely to occur, or have little or no impact on a project.
When analyzing risks, two important factors quickly become apparent: risk probability and risk impact. Risk probability is the likelihood of events occurring, while risk impact is the amount of loss that could result. These factors are what you evaluate when analyzing risks.
Risk probability is usually indicated by a numerical value that expressed as a decimal number. Microsoft recommends using increments of 0.05, with a value between 0 and 1, as the standard way of expressing the probability of a risk. When calculating the probability of a risk in this manner, it must be more than 0 and less than 1. A risk probability of 0 means that there is no probability of loss, while a risk with a probability of 1 means that the risk has occurred.
While Microsoft recommends using decimal numbers, this may not be the only method you’ll encounter in the real world. For example, it isn’t uncommon to find the probability of risk indicated by a numerical value expressed as a percentage. The reason is because people will be able to recognize what this means without additional information. When calculating the probability of a risk, it must be more than 0% and less than 100%. A risk probability of 0% would mean that there is no possibility of loss, which means that the item shouldn’t even be analyzed. If the probability is 100%, then it means that the risk has already become a problem.
Exam Watch: Despite these other methods for showing risk probability, remember that these aren’t the recommended methods endorsed by Microsoft. For the exam, you should remember that the decimal increments are the preferred method.
Risk probability is often more subjective than scientific. It is difficult, if not downright impossible, to give an accurate percentage of risk probability. For example, can you accurately predict that there is a 25% chance that the design of a software product needs to be reworked? There are several ways to provide estimation, but in many cases (such as this) it comes down to good old-fashioned guesswork! As we’ll see, these “guestimates” are based on the experience of team members.
There are several methods that teams can use to estimate risk probability. One that is commonly used is having the person who is most familiar with the area of risk provide an estimate. Other members of the team then discuss this. Another common method is through group consensus, which is also called the Delphi method. Each member provides an estimate on their own, along with the logic and reasons behind the estimate. Once this estimate and justification have been submitted, the members receive the estimates, along with the ratings, and re-evaluate their own submissions. After re-evaluating their work, each member submits revised estimates, and then discusses these estimates until they come to a consensus.
While both of these methods are proven and commonly used, they rely on members to use personal experience to make educated guesses on what percentage of risk is involved.
A method of estimating probability that doesn’t require percentage estimates is adjective calibration. This uses a scale of verbs that describe the probability of a risk. For example, high probability, very likely, likely, unlikely, very unlikely, and improbable would describe the probability factor of a risk. On a sheet of paper, members would choose a word to describe the risk. Each of these words would have a percentage value, which the word is converted to. For example, likely might have a value of 50%. If most members said a risk was likely, then you would apply the value of 50% to this risk.
One of the funniest methods, which actually works, uses a betting scheme. This works as if you were betting money on particular risks; however, no money actually changes hands. To illustrate, let’s use this example: “If the development tools are ready and in place on time, you win $60. If not, I win $50!” These bets are adjusted until you feel comfortable on either side of the bet. You then take the lower amount and divide it by the total amount of cash that’s in the proverbial kitty. To use our development tools example, the lower amount is $50, while the total amount is $110 ($60 + $50). This means you would do the following to get the risk probability percentage:
$50 / ($60 + $50) = 45%
While this method seems strange at first, it does work and makes the process of estimating risk probabilities fun. People are naturally used to taking money seriously, and are used to dealing with cash in the real world. As such, it has a natural feel once it’s been used a few times.
Risk impact is the second factor involved in risk analysis. It measures the size of loss, or severity of adverse effects if a risk results in becoming an actual problem. It is measured in currency for risks with a financial impact, time increments (days and weeks) for risks with a time impact, or a subjective scale for other risks that don’t fall into such obvious areas. By using a scale of 1 to 5, you can show the seriousness of the impact. High values are used to indicate high losses; medium values show a moderate loss to portions of a project; and low values show that there is a minimum impact on the project.
Estimating the size of loss is considerably easier than estimating risk probability. It is a matter of taking the data available, and calculating the size of loss from the numbers. If you are expecting facilities to be ready September 1, and you know that phones, desks, and other necessities may not be setup until September 8, then the size of loss is one week (seven days). In cases where there are numerous components to an area, such as several programming tools being estimated for the risk impact of development tools, you simply look at the size of loss for each of the components, then add them together afterward. For example, let’s say you were looking at the size of loss from using the fictional Dead C Scroll compiler and Julie’s Wacky Tracker. You would first estimate the loss of each tool individually. There was a two-week training time for Dead C Scroll users and one week for Julie’s Wacky Tracker, and a day for each of three other tools. As such, you would add 2 weeks + 1 week + 3 days together, and find that the size of loss is three weeks and three days. By looking at the individual components of a focus area, you are able to see the overall size of loss when they are added together.
Risk exposure and risk impact are often used synonymously. This is because the size of loss is incorporated into the risk exposure. Risk exposure is used to balance the likelihood of an actual loss with the magnitude of the potential loss. In other words, it is the overall threat of a risk to a project.
The way to determine the risk exposure is by using the following formula:
Risk potential * size of loss = risk exposure
Risk exposure is equal to the size of loss multiplied by the risk potential estimate. To understand how this works, let’s go through this example step by step. If you estimated that there is a 50% chance that facilities wouldn’t be available on time, then your risk probability is 50%. If the amount of time it would take for the facilities to be ready is two weeks, then your size of loss is two weeks. By multiplying two weeks by 50%, you have a risk exposure of one week. Once you’ve gotten this estimate, you would incorporate an extra week into your schedule, so that the risk you’re exposed to won’t affect the overall schedule.
In finding the risk exposure of risks in a project, a risk assessment table is used. As shown in Table 3-2, a risk assessment table documents the probability of loss and the size of loss associated with the risk. These two fields are multiplied to find the risk exposure.
Risk |
Probability
of Loss |
Size
of Loss (Weeks) |
Risk
Exposure (Weeks) |
Facilities won’t be ready on time. |
25% |
4 |
1 |
Amount of paperwork is excessive, and may impact progress. |
50% |
1 |
0.43 |
Table 2:
Risk Assessment Table
Exam Watch: The tables, charts, and forms generated during the risk management process are important tools. You can expect questions dealing with them on the exam. It is important to remember the purpose of these tools, what steps of the process they’re associated with, and what items each contains.
Once these steps have been completed, you are ready to prepare the risk statement. The risk statement has a number of features in it, and includes information acquired in the identification and analysis stages. In creating the risk statement, there is a considerable amount of information that can be added to the form. However, the following must appear in the risk statement, or it will not be complete:
· Source of a risk
· Risk(s) associated with the source
· Expected result or consequence
You can see that a risk statement isn’t a long document. Remember that you are completing a form, not writing a novel, when generating a risk statement. First, you mention the condition that is causing the risk. This is followed by the risk that is faced and consequences the project may encounter. For example,
The job market is excellent for developers right now and the Company is
having difficulty hiring enough people. Consequently, we are short two people on
the project. Therefore, we don’t have the personnel needed to meet the October
deadline.
In addition to this basic information, there is additional information that is recommended on a risk statement, as shown in Table 3-3. When generating a risk statement form, it is advisable to go through this list, so you can be certain that you haven’t forgotten necessary information. For your convenience, the risks in Table 3-3 are listed in alphabetical order.
Risk
Statement Item |
Description |
Related Risks |
List of risk identifications that are related to this particular risk situation. Used for tracking risks that are interdependent. |
Risk Condition |
Description of the condition that might lead to a loss for the project. |
Description of the consequences or loss that will occur if the risk becomes an actual problem. |
|
Risk Context |
A brief paragraph that provides background information. Used to clarify a risk situation. |
This is the overall threat to a project. It is calculated by multiplying the size of loss by the probability of loss. |
|
Risk Identifier |
Used for reporting and tracking purposes, this identifies the risk statement. It can be a number, alphanumeric filing code, or a name. |
Represents the amount of loss that would occur if a risk became an actual problem. |
|
Risk Impact Classification |
Specifies where the risk is. For example, a risk could be legal, financial, strategic, or technical. |
Represents the likelihood that a loss will occur. |
|
Specifies the focus area, risk factor category, and risk factor. |
Table 3: A Risk Statement Form
Exam Watch: Review Table 3-3 before going into the exam. By and large, risk management is fairly straightforward compared to other models in the Microsoft Solution Framework. Where people often seem to have a problem is remembering the terms in risk management. Know what should go on a risk statement form, memorize what each term means, and you will be prepared for this part of the exam.
In stating a risk, you need to express it clearly and concisely. You don’t need to dazzle other members with your command of the English language and mastery of technical jargon. It should be stated so that everyone who reads or hears it will be able to understand what you’re saying. In addition, don’t ramble on about the consequences of a risk. You should be straight to the point. If people are baffled and bored by what you’re saying, it won’t be given the proper level of consideration.
Priorities are often set by the risk exposure figure on a risk assessment table. This figure represents the overall threat to a project, and balances the probability of loss with the impact (or size) of loss that could occur. By ranking the risks by this figure, you are then able to create a Top 10 Risk List.
A Top 10 Risk List helps you to pick your battles, and show which risks are the highest priority in a project. Remember that risk analysis determines the threat of each risk, so you can determine which risks require attention. If you don’t focus your efforts on a selection of risks, team members will spend more time performing risk management than they will performing their individual roles of development and testing. By using the risk exposure value, you can compare the different risks and find which pose the greatest threats and opportunities. The risks that rank as the highest ten are then placed on a separate list, which is identifies those risks that must be managed.
In ranking by risk exposure, it is important that all of the values representing risk impact are of the same units of measurement. This means that each of the size of loss values is, for example, either in weeks, dollars, or levels of impact. It is impossible to determine whether a week is of higher value than a dollar or the level of 3. As such, if you are using different units of measurement, you should convert them to levels of impact before attempting to prioritize them. By having a level of impact, such as a scale of 1 to 5, with 5 having the highest impact, you can then view the different risk exposures to determine which are top priority.
The Top 10 Risk List provides a way for team members and stakeholders to view the major risks that must be managed. It is used later to focus the team on developing a risk management strategy, which is implemented as part of the project. This document is included in the vision/scope document and the project plan, which are explained in Chapters 2 and 4 of this book
The steps of the risk management process we’ve covered so far—identification and analysis—lay the foundation for the remaining three steps. While the identification and analysis steps provide us with data, it is from this point on that data is transformed into information and then used to create an action plan to track and control the risks involved in a project.
In looking at this process, shown in Figure 3-1, it resembles a wheel moving over a road. This image does well in illustrating how the process as a whole works. The first steps of the process act as a foundation, or road, for the other steps. It is here that the risk statement is created, outlining the risks related to the project. The risks that are determined to pose the greatest threats are added to a Top 10 Risk List. Like a wheel going round-and-round, the risks are carried through the remaining steps, and dealt with until they are resolved or become actual problems.
Figure 1: The risk management process
We’ll briefly discuss each of the five steps. While we’ve already examined the first two steps, as part of the process that leads to the creation of risk statements and Top 10 Risk Lists, we will explore the remaining three steps in.
In the identification step, we identified a list of risks that have the potential to cause problems in a project. In the analysis step, the impact of the identified risks was evaluated, as were alternatives to what is causing the risk. The risk statement and Top 10 Risk List created from these first two steps are then carried through the remaining steps of the risk management process.
The third step of the risk management process is risk action planning. In this step, the data that’s been collected is transformed into meaningful information, which is used to generate strategies to deal with the risk.
The fourth step in this process is tracking. Just because strategies have been developed, doesn’t necessarily mean that they will work. As such, it is important that the status of risks is monitored, as are the actions taken to prevent loss.
The final step is control. This step requires the team to control risk action plans, correct the plan if necessary, and make improvements to the risk management process. It involves reacting to indications that a plan is failing, setting a backup plan into action, or determining that the team must go back to previous steps in the process and implement new strategies.
In using proactive risk management, you don’t go through the various steps and quit at step five. The process of proactive risk management requires risks to be assessed continuously, throughout the life of a project. These assessments are used for decision-making in every phase of a project. Risks are carried forward from one phase to the next, and dealt with until they are resolved or become actual problems. When they become a problem, they are then handled with reactive risk management.
The third step of the risk management process is risk action planning. This takes the information gathered in the previous steps, and transforms it into decisions and actions. Up until now, risks have been identified and analyzed to determine which ones will be dealt with, and the level of threat they present. It is here that risks actually begin to be dealt with, and a plan is created to deal with them. Risks are addressed individually, and actions are developed to deal with them. Once developed, the risk actions are prioritized so that the most vital ones are addressed first. Finally, they are integrated into a risk management plan.
By addressing four key areas, the team can decide how the risk will be dealt with. These four areas are the core of risk action planning:
1. Research
2. Acceptance
3. Management
4. Avoidance
Each of these areas represent a method that determines what action will be taken on a particular risk.
Research is performed when there isn’t enough information currently available. This route of action is taken when there is a need to further study a risk, acquire more information regarding its characteristics, or other areas are lacking in sufficient information. It is important to always consider whether additional analysis of a risk is required, so that the wrong action isn’t taken.
With research there may be times when its advisable to hire someone to investigate the risk, determine its seriousness, and suggest further courses of action. While this isn’t a regular occurrence in risk management, it does occasionally happen. Consultants are hired, or information dealing with the risk you’re concerned about is available for purchase. This should be considered when the risk is highly serious. For example, if you were creating software for air traffic control, and had concerns about design problems or risks that could threaten life or property, it would be wise to research critical risks thoroughly.
Acceptance is when you’re willing to live with what you’ve got. No further action is needed with a risk, and you are willing to accept the risk as it stands. This action should be taken only when you’re comfortable with accepting the consequences of a risk should they occur, or if the risk no longer poses a significant threat.
Avoidance is the final area of risk action planning. By avoiding the risk without changing the scope, you are able to side-step the problem without affecting the overall project. For example, if you are unfamiliar or uncomfortable dealing with certain features of a software product, you could contract out that area to another reputable firm. If you were having a problem with facilities not being ready, you could arrange for other facilities that will be ready for when the project starts. By avoiding the problem, you are removing risks that threaten the project, without changing the project itself.
Management refers to determining if the team can do anything to lessen the risk’s impact should it actually occur. There are three goals to risk management:
1. Reduce the probability that the risk will actually occur.
2. Reduce the extent or magnitude of loss that could result from the risk.
3. Change the consequences associated with the risk.
Achieving the goals of managing risks involves creating and implementing strategies and contingency plans to deal with the problem. This often involves using some creativity in finding solutions to individual risks.
In managing specific risks, there are a number of strategies available. While entire books have been written on managing and resolving the risks of software projects, a few common ones are reviewed here.
When luck, the budget, and upper management are with you, you can reduce risks be putting more resources into the project. If there is a risk that the schedule won’t be met, you can hire more people, and get more desks, chairs, and computers into the office space. Unfortunately, this may not be feasible in some projects if the budget is tight.
In cases where the risk is out of the team’s control or can’t be resolved, a workaround should be found to reduce risks. If the program has a bug that can’t be resolved by a certain date, let upper management and marketing know about it. If the schedule isn’t changed to allow the bug to be fixed, then information about the risk, its consequences, and a workaround can then be supplied to the customer and end user. This keeps everyone outside the project team from being surprised when the problem occurs. After release, a bug fix or patch for the problem can be released, and/or it can be resolved in the next version of the program.
Sometimes you can transfer the risk. In some cases, it is possible to move the risk from one area of a project to another, which thereby minimizes the risk. For example, if it is risky having a software feature in one part of the system, move it to another part that is better able to handle it. Moving the feature from the client executable to a separate component or the server part of the program can do this. If you are unfamiliar or uncomfortable with an activity in a project, you can transfer the risk by subcontracting part of the project to someone with more experience. For example, if there is a feature of a program that works with an Oracle database, and no one on your team knows anything about Oracle, this is a candidate for subcontracted work. While there are risks involved with contracting work out, the risks involved are less than those of allowing unqualified people to perform work they know little or nothing about.
When dealing with risks that are hardware-related, you may want to consider moving to different hardware. This strategy is often raised when dealing with system requirements, or graphic-intensive designs or images. For example, if your project requires that graphics or animations are created and added to the product, you may want to consider adding a few computers devoted to graphics production. The other time you’ll generally want to change hardware, is when software upgrades require it. This means upgrading or replacing the hardware to support updated software. For example, if you planned to program with Visual Basic 6.0, and most of the computers were 386s, you would need to upgrade or replace the hardware to Pentiums.
Because nothing is perfect, you can’t expect your plan of action to be foolproof either. As such, it is important to have a contingency plan to fall back on. This alternative strategy goes into action when all efforts to manage the risk and avoid a problem fail. As an example of a contingency plan, let’s say your team has office space reserved until January 2, when the project is complete. There is a risk that your team won’t be finished by this date, and able to vacate the facilities on that date. To deal with this risk, you plan to negotiate with the team who will take over the offices, so they won’t bump you out of there. As a contingency plan, you will arrange other office space to be used temporarily, until the project is complete. If all goes well, the contingency plan isn’t used, but it exists should the original action plan fail.
When creating a contingency plan, it is important to agree on what will trigger the second plan, and deem the first a failure. In the case of our previous example, you don’t want to wait until people get back to work the day after New Years! It would be better to discuss the situation before people go on vacation, and the second plan still has time to be implemented. If time isn’t an issue, then you would use values such as a dollar amount (for budget and cost risks) or a condition (such as strikes in a company you’re expecting deliveries from). Whatever you choose, it is important to decide on it at the time the contingency plan is incorporated into the project. If you wait until you’re suffering panic attacks, and the second plan should have already been activated, there was no point in even creating a contingency plan.
It is important to document all of this information so that you can refer to it throughout the project and use it in later steps in the risk management process. The following information that should appear on a risk action form:
· risk identifier
· risk statement
· risk management strategy
· risk management strategy metrics
· action items
· due dates
· personnel assignments
· risk contingency strategy
· risk contingency metrics and trigger values
A risk identifier is used for reporting and tracking purposes, and uniquely identifies the risk action form. It can be a number, alphanumeric filing code, or a name, but must be unique so that it can’t be confused with other forms. If you have developed an automated risk action form, such as a database program with Access or Visual Basic, the risk identifier could be nothing more than a record number.
The risk statement is part of the analysis step in the risk management process. However, it is important that a risk statement appear on or with the risk action form. The risk statement describes the condition that could result in loss, and explains the consequences of what might occur if the risk became an actual problem. A risk statement on the risk action form could reiterate this information, state the risk identifier of the risk statement form, or have a copy of the risk statement form attached. To keep team members and stakeholders from having to flip through too many pages though, it is often better to provide a paragraph or two on this information, and mention the risk identifier on the risk statement form. This provides a summary of what’s involved, while allowing members and stakeholders the opportunity to refer to the original risk statement form.
Since this form details with the strategy to be used in dealing with a particular risk, it would be remiss not to mention it! The risk management strategy provides a paragraph or more detailing the strategy to be used for managing the risk. This should also include any assumptions or observations that have been made about the strategy. The risk management strategy metrics provide the measurement to be used to ensure that the planned actions are working. To understand what metrics are, let’s look at your strategy of studying to become an MCSD. You are probably using metrics of your own to gauge how things are going, such as how well you’re doing on the questions at the end of each chapter. When dealing with risk management strategy metrics, you would use such things as a cutoff point for time or money spent dealing with a risk or a particular occurrence.
Action items detail the duties and actions to be performed in managing the risk. Basically, they outline what is to be done (as part of the strategy) to ensure the risk doesn’t result in loss. Along with these action items are due dates, which show when certain actions are to be completed. Personnel assignments also appear on the risk action form, to show whom is assigned to perform these action items. This allows team members to know, in writing, what their risk management duties are, when they are to be completed by, and who is responsible for doing what.
Finally, the risk contingency plan is included in the risk action form. This shows what the team strategy will be should the original plan fail. It consists of a paragraph or more describing what will be done if the risk contingency strategy trigger values are reached. These figures are also included on the form, and are used for determining when this fallback plan is put into action. Risk contingency strategy metrics also appear on the risk action form with these figures, to show whether the contingency plan is working. If it is not, the members will need to go back to the drawing board, and go through the previous steps to deal with the risk.
On the Job: While each project has its own risks, you can use risk action plans and other documents from previous projects. It is advisable to keep these forms after a project concludes, by storing them in a binder or database. When storing them, note whether certain plans were successful or failed, and (if possible) why. When you go into other projects, you can then refer to these plans and forms. By remembering that you experienced a similar risk, and referring to these documents, you can learn from failed plans and use successful ones in your current project!
Unfortunately, once an action plan has been implemented, you can’t just sit back and let it take care of the risk unattended. Once the plan has been put into action, it needs to be monitored and occasionally intervention is required. This is where the last two steps of proactive risk management come into play.
The fourth step in the risk management process is risk tracking. This takes place once an action plan has been put into play, and is where the team monitors the status of risks and the actions implemented to manage them. Risk tracking watches events unfolding as a result of the action plan, and monitors the risk metrics and triggers that determine whether the plan is successful or not.
Part of risk tracking involves updates and assessments of the Top 10 Risk List. This list provides a run-down of the most critical risks in a project, and ranks them from the highest possibility of loss (number 1 on the list) to the lowest (number 10). By reviewing this list on a weekly basis, you will be able to see if certain risks have gone down or up in rank. At the very least, this list should be evaluated monthly or when a milestone has been reached. An example of a Top 10 Risk List is shown in Table 3-4. While an initial Top 10 Risk List will simply have ten items ranked from highest to lowest, tracking uses the list to show an item’s previous ranking and its current ranking. This allows the team to see where risks are being dealt with successfully, and which risks are getting worse, and may need serious re-evaluation.
On the Job: One of the mistakes people make in risk management is monitoring the effects of risk action plans only after the project has been completed, and do little or no monitoring while the project is still running. This does allow you to see how a plan worked over the course of the entire project, but isn’t really risk management. It keeps you from actually seeing how a plan is working at the time, when you can do something to keep a risk from resulting in loss. This postmortem approach is useful when evaluating an action plan as a whole, but don’t do it instead of regular risk tracking.
Risk |
Progress |
This
Week |
Last
Week |
Weeks
on List |
Number
of Times in Top 10 |
Development tools late in delivery |
Two of three updated development tools have been delivered |
1 |
3 |
5 |
2 |
Redesign required |
Design is currently being redesigned; proceeding at good pace |
2 |
6 |
7 |
1 |
Table 4: Top 10 Risk List
The risks listed in the initial Top 10 Risk List may disappear completely from the listing. When an action plan works incredibly well, or the risk itself is eliminated, then other risks will be moved into the Top 10, as original ones are dropped from the list.
In creating a Top 10 Risk List, it is advisable to keep track of the number of times a risk has appeared in the Top 10. If its ranking has fluctuated repeatedly, and appeared in the listing numerous times, then it could be an indication that the action plan isn’t working as well as it could. In such a case, you should look at why the risk is doing this. If progress isn’t working as well as it should, or certain action items are bumping the risk up in the ranking, then personnel assignments or other areas of the action plan may need adjustment.
Another tool of risk tracking is risk status reports, which is used to identify four possible situations:
1. A risk is resolved, and the risk action plan is completed.
2. Risk actions are tracking the risk management plan.
3. Risk actions are not tracking the risk management plan.
4. Situation has changed.
When risk actions are tracking the risk management plan, it means that your risk action plan is following its proper course. If this is the situation, then you should let risk actions continue as planned, and leave well enough alone (unless something changes). If the risk actions aren’t tracking the risk management plan, then changes need to be made to the risk actions or risk action plan. This means you must determine where things have gone awry in your plan, and how things can be corrected. When the situation dealing with one or more risks has changed, it means that the risks may need reassessment, or the activity needs to be re-planned.
The final step of the proactive risk management process is risk control. This involves responding to triggers that indicate a plan is failing or has failed, making corrections in the initial risk action plan, and making improvements to the process of risk management. The work done in this step can include informing someone that they are not following a plan, or performing action items, or revamping existing actions or plans so they work properly.
It is important to remember that no matter how good your plans are, or how well things should work, success in risk management always falls on how well people perform in risk management. If your team is halfhearted or doesn’t care enough about performing their duties in managing risks, the risk action process will always fail. Some companies have actually found it beneficial to use a risk officer on projects. This is either a person in an existing team role (other than product manager, as it can be a conflict of duty) or a person hired in the job of finding and managing risks. This person points out the risks involved in a project, points out where things are going wrong and where the project may fail, and handles all the work of documentation. If problems with risk management traditionally pop up on projects in your organization, this may be an option to consider.
What is risk? |
Risk is the possibility of suffering some sort of loss, and is inherent to any project. |
I made a list of risk sources and risks during the last project I worked on. Can I just apply this list to the next project I’m working on? |
No. Risk sources and risks need to be identified and dealt with on an independent basis. What may be a major risk source or risk on one project may not be of great issue on other projects. It is better to use the existing list as a reference, to see if risks experienced in other projects are appearing here. This helps you remember certain risks, but should not be used as a listing of risks that is passed from one project to another. |
What is the difference between proactive risk management and reactive risk management? |
Proactive risk management addresses risks before they result in loss. Reactive risk management is used, or waits until, the risk becomes an actual problem. When this occurs, the consequences of the risk are dealt with. |
How do I find what the risk exposure will be for a particular risk? |
Multiply the risk impact (size of loss) by the risk potential (potential of loss). The answer will give you the risk exposure for that particular risk. |
Risk is the possibility of a loss. To increase your odds that risks don’t result in a loss of some sort, risk management is used. Risk management involves identifying, addressing, and possibly eliminating the sources of risk. It is an environment and discipline of proactive decisions and actions.
Risks are inherent to any project, and it is important to identify risk sources and their associated risks so they can be dealt with accordingly. There is no standard set of risk sources on a project, so what may be a major risk source on one project may not be an issue on other projects. As such, you need to identify and analyze the risk sources for each individual project.
Proactive risk management involves five steps that work together in dealing with risks before they result in loss. These steps consist of identification, analysis, risk action planning, tracking, and control. Together they deal with risks before they become an actual problem.
· Risk is the possibility of suffering some sort of loss, and it is inherent to any project.
· In Microsoft’s definition, risk management is a “discipline and environment of proactive decisions and actions to assess continuously what can go wrong, determine what risks are important to deal with, and implement strategies to deal with those risks.”
· A risk source is made up of three components: risk factor category, focus area, and risk factor.
· Proactive risk management deals with risks before they become problems that result in loss. Reactive risk management deals with risks after they’ve occurred.
· Risk statements are used to communicate the risks involved in a project, so that members can effectively manage them.
· Risk identification results in a list of risks that have the potential to cause problems in a project.
· Risk analysis evaluates the impact of the identified risks and considers alternatives to factors causing the risk.
· Risk probability is the likelihood of events occurring, while risk impact is the amount of loss that could result.
· There are three goals to risk management: reduce the probability that the risk will actually occur; reduce the extent or magnitude of loss that could result from the risk, and change the consequences associated with the risk.
· A risk identifier is used for reporting and tracking purposes, and uniquely identifies the risk action form.