Search This Blog

Showing posts with label Risk. Show all posts
Showing posts with label Risk. Show all posts

Monday, May 13, 2013

24 C The Risk Burn Down Chart


A spreadsheet similar to the risk register can be developed to manage risks and manage the budgets associated with risk management on large and long duration projects. It isn’t possible to avoid all arbitrariness in forecasting the risk management budget but it is possible to provide good management visibility into the process. One approach is as follows: (This description is a bit tedious so look ahead at figures 10 and 11. If the process is obvious to you from the figures skip the text. If not then just wade through the description. It may help to drawn out the spreadsheet as you read the description.)
•           Develop a spreadsheet with time, e.g. months, in the first column and the known risks in the first row of adjoining columns. The planned mitigation expense estimate as a function of time for each risk is added in the rows for each known risk. Summing the entries in each row across columns results in the estimated mitigation expense for all risk mitigation activities for that time period. As new risks are identified they are added in the first row of new columns and mitigation budgets are added in appropriate time rows in the new columns.
•           Develop a second spreadsheet with the following columns
o          Time line, e.g. month number from beginning of the project or actual dates
o          Planned Mitigation Expense per time period to be spent on risk mitigation for known risks, i.e. the cumulative value of the row for that time period from the first spreadsheet
o          Cumulative Planned Mitigation Expenses, i.e. the cumulative cost estimates for mitigation activities for the risks known at the time the plan is developed.
•           Recognize that as the project progresses new risks will appear as decisions are made and additional risk management budget is needed to mitigate these new risks. Therefore add the following columns to the spreadsheet.
o          Adjusted Cumulative Mitigation Budget; the planned expenses plus an adjustment, e.g. an arbitrary percentage, to mitigate unknown risks that will arise during the project.
o          Actual Mitigation Expenses for each time period.
o          Cumulative Actual Mitigation Expense
It may be helpful at this point to show a chart resulting from an example of the process described so far. Figure 10 is a chart for a large project in which the mitigation budget is nearly $40 million dollars. In this example the initially identified risks were planned to be mitigated with just over $30 million. The arbitrary adjustments for unknown risks increased the budget to nearly $40 million and the actual expenses at the end of a year were just below the adjusted budget. For situations where the budget for risk mitigation is released incrementally or for a large project that continues for several more years having data such as this chart provides the project managers sound arguments to defend their requests for risk mitigation budgets.

  Figure 10 An example of risk mitigation budget and expense resulting from the example approach.
The mitigation budget and expense are only half of the story. Risk is the rest of the story so now let’s return to the example approach:
•           At the beginning of a project sum up the expected values of all risks on the risk register. This cumulative risk value is the amount of over budget expense that is likely if initially known risks are not mitigated before they impact the project. Add a column to the second spreadsheet for this Cumulative Risk Value before Mitigation.
•           Add a risk value adjustment factor for each time period to cover unknown risks that will arise and add a new column to the second spreadsheet for the Adjusted Cumulative Risk Value before Mitigation. These “adjusted” values represent the best estimate of how both identified and new risks will be mitigated throughout the project
•           As the project continues, new risks are added and all risks are mitigated so that a Cumulative Risk Value after Mitigation can be added to the spreadsheet. Now there is sufficient data to construct a Risk Burn Down Chart which shows how the risk value is reduced over time by the risk mitigation work.
An example of a risk burn down chart is shown in figure 11. In this example the adjusted and actual cumulative risk values track each other reasonably well. If the manager of this project needed additional risk management funding in the middle of the project then showing this chart to the funding authority would provide excellent justification for the needed funds. If the planned and actual risk mitigation expenses also tracked each other well, as in the example shown in figure 10, then the funding authority should have good confidence in the management team.

 Figure 11 An example risk burn down chart for a large project with high initial risk.
The charts resulting from the approach outlined above are useful for showing those responsible for funding projects the most likely project expense if risk mitigation is effectively conducted and the likely budget impacts if risks are not proactively mitigated. In the example shown the likely budget impact if risks are not mitigated is over $400 million. This budget impact is reduced to about $23 million by an expenditure of about $38 million for a total impact of about $63 million compared to over $400 million.
The percentage adjustments risks that will be identified during a project are necessarily arbitrary but can be adjusted during the project if the actual expected risk value line deviates substantially from the adjusted expected value line.
In summary, spending a small amount of money in proactively mitigating risks is far better than waiting until the undesirable event occurs and then having to spend a large amount of money fixing the consequences. Remember that risk management is proactive (problem prevention) and not reactive. Also risk management is NOT an action item list for current problems. Finally, risk management is an on-going activity. Do not prepare risk summary grids or risk registers and then put them in a file as though that completes the risk management process, a mistake inexperienced managers make too often.
Exercise
1. Spend some quiet time thinking about what the worst possible thing your competitors could do that would negatively impact your organization in the short and long terms. If you have already done this and have mitigation plans in place or on the shelf you are a mature risk manager. If not, you have some homework to do.
2. Handling anything your competitors do or responding to the loss of your most important customer are the easy ones. Now imagine that your organization is stable, progressing well on improving effectiveness, trust in management is growing, enthusiasm is growing and then your superiors tell you to lay off 10% of your people in order to increase enterprise profits for the year. You know this is going to demoralize the organization for some time and erode trust in the benefits of working to improve the organization. How do you respond to your people and to your superiors? There is no easy answer to this question but in today’s environment it is not an unlikely occurrence and you should be prepared for it.
2. Does your organization have a standard risk management process in place? If so then go on the next lecture. If not then think through a plan to put a standard process in place and train workers to use it. This can be a commercial process or a process you or your workers develop. You can implement it via formal training or on an incremental basis. The important thing is having a process and using it religiously.

If you find that the pace of blog posts isn’t compatible with the pace you  would like to maintain in studying this material you can buy the book “The Manager’s Guide for Effective Leadership” in hard copy or for Kindle at:
or hard copy or for nook at:
or hard copy or E-book at:


Tuesday, April 30, 2013

24 B The Risk Register


The risk register ranks risks by the dollar value of each risk according to the operational definition of risk given earlier. Constructing the risk register on a spreadsheet allows risks to be sorted by dollar value so that the highest risks are always on top of the list. The risk register also facilitates keeping all risks in the same data base even though management actions may be active on only the top five or ten at any time. When a high risk is mitigated the expected dollar value of the risk is reduced and it falls out of the top five or ten but is still on the list. This enables reviewing mitigated risks to ensure they remain mitigated or to readdress a risk at a later time when all the higher risks have been mitigated to even lower values. An example of a simple risk register constructed on a spread sheet is shown in figure 9.


Figure 9.  An example template of a risk register constructed in columns on a spread sheet.
The risk type and impact if risk occurs are usually described as “if”, “then” statements. This helps the management team remember specifically what each risk entails as they conduct reviews over the life of the activity. Expected values are expressed in dollars, which facilitates both ranking and decisions about how much resources should be assigned to mitigation activities. I am assuming of course that in managing activities in your organization it is the practice to hold some fraction of the budget in reserve to handle unforeseen events. It is this reserve budget that is assigned to risk mitigation activities. Risk mitigation actions should be budgeted and scheduled as part on on-going work. A failure many inexperienced managers make is handling risks outside of the mainline budget and schedule. This undisciplined approach often leads to risk management degenerating into an action item list and finally to a reactive approach to unexpected events rather that a proactive approach to reduce the risks systematically.
A more complete risk register template than the example shown in figure 9 might contain columns for the risk number, title, description (if), impact (then), types (three columns: cost, schedule, quality or technical), probability of occurrence, cost impact, schedule impact, mitigation plan and mitigation schedule. The form of the risk register template is not critical so the team managing the risks should construct a template that contains the information they feel they need to effectively manage risks.
The risk register, if properly maintained and managed, is a sufficient tool for risk management on small and short duration projects. Setting aside an arbitrary management reserve budget to manage risks is ok for small projects. Portions of the reserve are allocated to mitigation of risks and the budgets and expenses for risk mitigation can be folded into the overall cost management system. Large, long duration projects or high value projects warrant a more focused approach to budgeting for risk management.
If you find that the pace of blog posts isn’t compatible with the pace you  would like to maintain in studying this material you can buy the book “The Manager’s Guide for Effective Leadership” in hard copy or for Kindle at:
or hard copy or for nook at:
or hard copy or E-book at:


Thursday, April 25, 2013

24 A Introduction to Risk Management

The following three lectures define risk, outline a risk management process and provide examples of templates useful for risk management.
Risk is the consequence of things happening that negatively impact the performance of an organization’s planned activities. Risks arise from events that occur inside and outside an organization. The consequence of the event can impact the quality, cost or schedule of an activity, or some combination of these effects. There is risk in any activity but there are usually more risks associated with activities that are new to the organization. New activities include the introduction of new products or services or changes to the processes, people, materials or machines used to produce existing products or services. Risks to stable products and services arise from unplanned changes to the internal environment or changes in the external environment, such as the economy, costs of materials, labor market, customer preferences or actions by a competitor, a regulating body or a government agency. An effective manager faces up to risks and manages risks so that the negative impacts are minimized.
Definition of Risk
There is an operational definition of risk that aids in managing risk. This definition is:
Risk R is The Probability p of an Undesirable Event Occurring; Multiplied by The Consequence of the Event Occurrence measured in $, or R=p x $.
This definition allows risks to be quantified and ranked in relative importance so that the manager knows which risks to address first and to evaluate how much investment is reasonable to eliminate or reduce the consequence of the risk. The definition measures risk in dollars. Thus impacts to the quality of a product or service or to the schedule of delivering the product or service are converted to costs. Impacts to quality are converted to dollar costs via estimated warranty costs, cost of the anticipated loss of customers or loss of revenue due to anticipated levels of discounting prices. Schedule delays are converted to dollar costs by estimating the extra costs of labor during the delays and/or the loss of revenue due to lost sales caused by the schedule delays.
The key to good risk management is to address the highest risk first. There are three reasons to address the highest risk first. First is that mitigating a high risk can result in changes to plans, designs, approaches or other major elements in an activity. The earlier these changes are implemented the lower the cost of the overall activity because money and people resources are not wasted on work that has to be redone later. The second reason is that some activities may fail due to the impossibility of mitigating an inherent risk. The earlier this is determined the fewer resources are spent on the failed activity thus preserving resource for other activities. The third reason is that any activity is continually competing for resources with other activities. An activity that has mitigated its biggest risks has a better chance of competing for continued resource allocation than an activity that has gone on for some time and still has high risks.
Managing Risk
Managing risk is accomplished by taking actions before risks occur rather than reacting to occurrences of undesirable events. The steps in effective risk management are:
1.     Listing the most important requirements that the activity must meet to satisfy its customer(s). These are called Cardinal Requirements
2.     Identifying every risk to an activity that might occur that would have significant consequence to meeting each of the Cardinal Requirements
3.     Estimating the probability of occurrence of each risk and its consequences in terms of dollars
4.     Ranking the risks by the magnitude of the product of the probability and dollar consequence (i.e. by the definition of risk given above)
5.     Identifying proactive actions that can lower the probability of occurrence and/or the cost of occurrence of the top five or ten risks
6.     Selecting among the identified actions for those that are cost effective
7.     Assigning resources (funds and people) to the selected actions
8.     Managing the selected action until its associated risk is mitigated
9.     Identifying any new risks resulting from mitigation activities
10.  Replace mitigated risks with lower ranking or new risks as each is mitigated
11.  Conduct regular (weekly or biweekly) risk management reviews to:
·       Status risk mitigation actions
·       Brainstorm for new risks
·       Review that mitigated risks stay mitigated
In identifying risks it is important to involve as many people that are related to the activity as possible. This means people from senior management, your organization, other participating organizations and supporting organizations. Senior managers see risks that workers do not and workers see risks that managers don’t recognize. It is helpful to use a list of potential sources of risk in order to guide people’s thinking to be comprehensive. Your list might look like that shown in figure 7.


Figure 7 An example template for helping identify possible sources of risk to the customer’s cardinal requirements.
It also helps ensure completeness of understanding risks if each risk is classified as a technical, cost or schedule risk or a combination of these categories.
Risk Summary Grid and Risk Register
Two useful templates used in risk management are the risk summary grid and the risk register. The risk summary grid is a listing of the top ranked risks on a grid of probability vs. impact. The risk summary gird is excellent for showing all top risks on a single graphic and grouping the risks as low, medium or high. Typical grids are 3 x 3 or 5 x 5. An example 5 x 5 template is shown in figure 8.


Figure 8 An example of a 5 x 5 risk summary grid
The 5 x 5 risk summary grid enables risks to be classified as low, medium or high; typically color coded green, yellow and red respectively, and ranked in order of importance. Note that the definitions for low and medium are not standard. The definition used in figure 8 is conservative in limiting low risk to the six squares in the lower left of the grid. Others, e.g. the Risk Management Guide for DOD Acquisition (An excellent tutorial on risk management that is available as a free download at http://www.dau.mil/pubs/gdbks/risk_management.asp) define the entire first column plus six other lower left squares as low risk.
Relative importance is the product of probability and impact. Identified risks are assigned to a square according to the estimates of their probability of occurrence and impact to the overall activity. In figure 8 there is one medium risk, shown by the x in the square with a probability 0.3, impact 7 and therefore having a relative importance of 2.1. The numbers shown for impact are arbitrary and must be defined appropriate to the activity for which risk is being managed.
A typical approach is to construct a four column by six row table with Impact being the heading of the first column and the numbers 1,3,5,7,9 (or whatever five numbers or letters you choose) in each succeeding row of the first column. The remaining three columns are labeled Technical, Schedule and Cost. Each box in the rows under the Technical, Schedule and Cost headings is defined appropriately for the activity at risk. For example, costs could be defined as either percentage of budget or in actual monetary units. Similarly schedule can be defined as percent slip or actual time slip.
The process using a 3 x 3 risk summary grid typically assigns risks as 0.1, 0.3 or 0.9 and impacts as 1, 3 or 9. There are three squares for each of the low, medium and high risk classifications with relative importance values ranging from 0.1 to 8.1 according to the products of probability and impact. Specific processes or numerical values are not important. What is important is having a process that allows workers and managers to assess and rank risks and to communicate these risks to each other, and in some cases to customers. The simple risk summary grids are useful tools for accomplishing these objectives and are most useful in the early stages of the life cycle of an activity and for communicating an overall picture of risks. The risk summary grid can be used as a tool in risk management meetings but a better tool is the risk register discussed in the next lecture.

If you find that the pace of blog posts isn’t compatible with the pace you  would like to maintain in studying this material you can buy the book “The Manager’s Guide for Effective Leadership” in hard copy or for Kindle at:
or hard copy or for nook at:
or hard copy or E-book at:


Wednesday, August 3, 2011

Two More Risk Reduction Tools

10.3.2 Risk Register - The risk summary grid can be used as a tool in the development team’s risk management meetings but a better tool is the risk register. The risk register ranks risks by the expected dollar value of each risk according to the operational definition of risk given earlier. Constructing the risk register on a spreadsheet allows risks to be sorted by dollar value so that the highest risks are always on top of the list. The risk register also facilitates keeping all risks in the same data base even though management actions may be active on only the top five or ten at any time. When a high risk is mitigated the expected dollar value of the risk is reduced and it falls out of the top five or ten but is still on the list. This enables reviewing mitigated risks to ensure they remain mitigated or to readdress a risk at a later time when all the higher risks have been mitigated to even lower values. An example of a simple risk register with three risks constructed on a spread sheet is shown in Figure 10-8.
Figure 10-8 An example of a risk register constructed in columns on a spread sheet.
The risk type and impact if risk occurs are usually described as “if”, “then” statements as in Figure 10-8. This helps the management team remember specifically what each risk entails as they conduct reviews over the life of the activity. Expected values are expressed in dollars, which facilitates both ranking and decisions about how much resources should be assigned to mitigation activities. Assuming of course that in managing activities in the development organization it is the practice to hold some fraction of the budget in reserve to handle unforeseen events. Funds from this reserve budget are assigned to risk mitigation activities. Risk mitigation actions should be budgeted and scheduled as part on on-going work. A failure many inexperienced managers make is handling risks outside of the mainline budget and schedule. This undisciplined approach often leads to risk management degenerating into an action item list and finally to a reactive approach to unexpected events rather that a proactive approach to reduce the risks systematically.
A more complete risk register template than the example shown in Figure 10-8 might contain columns for the risk number, title, description (if), impact (then), types (three columns: cost, schedule, quality or technical), probability of occurrence, cost impact, schedule impact, mitigation plan and mitigation schedule. The form of the risk register template is not critical so the team managing the risks should construct a template that contains the information they feel they need to effectively manage risks.
The risk register, if properly maintained and managed, is a sufficient tool for risk management on small and short duration projects. Setting aside an arbitrary management reserve budget to manage risks is ok for small projects. Portions of the reserve are allocated to mitigation of risks and the budgets and expenses for risk mitigation can be folded into the overall cost management system. Large, long duration projects or high value projects warrant a more focused approach to budgeting for risk management. These management actions do not usually involve systems engineering but systems engineers should be aware of the methods used for management of risk reduction budgets.
In summary, spending a small amount of money in proactively mitigating risks is far better than waiting until the undesirable event occurs and then having to spend a large amount of money fixing the consequences. Remember that risk management is proactive (problem prevention) and not reactive. Also risk management is NOT an action item list for current problems. Finally, risk management is an on-going activity. Do not prepare risk summary grids or risk registers and then put them in a file as though that completes the risk management process, a mistake inexperienced managers make too often.
10.4 Design Iterations Reduce Risk
Design iterations are planned “build, test and learn” activities for high risk parts of the system; parts that are small enough to build, test and assess rapidly. Examples best illustrate the concept of using design iterations to reduce risk:
  • Engineering builds and tests two types of breadboard circuits to get data needed for a subsystem specification, trade studies and subsequent detailed design
  • Manufacturing pilots a new production process during architecture definition and uncovers yield problem early
  • Analysts simulate three candidate signal processing algorithms during concept development and recommend the best
  • Software implements and tests high risk parts of three alternative approaches for system control software during requirements analysis.
Design iteration is not a fire fighting technique; it is a methodical risk reduction methodology. Design iteration is not “build the entire system, test it and fix it if it doesn’t work” approach; in fact it is intended to avoid falling into such an unproductive approach. Note that “spiral development”, described earlier, is system level risk reduction methodology. Design iterations can be thought of as a methodology that supports implementing progressive freeze.
Recall the message in Figure 6-32 that the cost of making design changes is low in the early stages of a system development when there are many degrees of freedom and becomes higher as the development progresses and there are fewer and fewer degrees of freedom. Thus design iterations are cost effective for many high risk items in the early stages of a development. It’s ok to have many short cycle iterations in parallel in early phases and it’s ok to “throw away” some results as the team learns and lowers risk.

Tuesday, July 19, 2011

Introduction to Risk and Opportunity Management

Risk is always present; its presence is a fact of nature. Accepting that risk is always present is the first step toward managing risks to reduce the effects of risks. Managing risk is the responsibility of the development program leaders but the mechanics are often delegated to systems engineering. Even if systems engineers are not responsible for maintaining the processes and tools it is essential that they understand the importance of risk management and the methods used for effective risk management. Inattention to risk management is the second highest cause of projects not meeting expectations. Just like other systems engineering processes it takes experience and discipline to conduct effective risk management.
Development programs also have opportunities for improving cost, schedule or system performance. It is important to identify and manage opportunities as well as risks in order to have an effective program. This chapter defines risk, outlines a risk management process that can be used for risk and opportunity management and provides examples of templates and processes useful for risk and opportunity management.
10.1 Risk Definition
Risk is the consequence of things happening that negatively impact the performance of a system development project. Risks arise from events that occur inside and outside the development organization. The consequence of an event can impact the quality, cost or schedule of a system development project, or some combination of these effects. There is risk in any project but there are usually more risks associated with projects that are new to the development organization’s experience. Risks are always present in the development of new products or services or changes to the processes, people, materials or equipment used in the development of products or services. Risks to developing new products and services arise from unplanned changes to the internal environment or changes in the external environment, such as the economy, costs of materials, labor market, customer preferences or actions by a competitor, a regulating body or a government agency. An effective development team faces up to risks and manages risks so that the negative impacts are minimized.

There is an operational definition of risk that aids in managing risk. This definition is:
Risk R is The Probability p of an Undesirable Event Occurring; Multiplied by The Consequence of the Event Occurrence measured in arbitrary units C or dollars $; R=p x C or R=p x $.
This definition allows risks to be quantified and ranked in relative importance so that the development team knows which risks to address first, i.e. the risks with the highest values of R. If the event consequence is measured in dollars then it’s easier to evaluate how much budget is reasonable to assign to eliminate or reduce the consequence of the risk.
The second definition measures risk in units of dollars. Thus impacts to the quality of a product or service or to the schedule of delivering the product or service are converted to costs. Impacts to quality are converted to dollar costs via estimated warranty costs, cost of the anticipated loss of customers or loss of revenue due to anticipated levels of discounting prices. Schedule delays are converted to dollar costs by estimating the extra costs of labor during the delays and/or the loss of revenue due to lost sales caused by the schedule delays.
Opportunities can also be defined operationally by the product of the probability an opportunity for improvement can be realized and the consequence if the opportunity is realized, measured either in arbitrary units or dollars. In the rest of this chapter when risk is addressed the reader should remember that it can be viewed as “risk or opportunity”.
The key to good risk management is to address the highest risk first. There are three reasons to address the highest risk first. First is that mitigating a high risk can result in changes to plans, designs, approaches or other major elements in a project. The earlier these changes are implemented the lower the cost of the overall project because money and people resources are not wasted on work that has to be redone later. The second reason is that some projects may fail due to the impossibility of mitigating an inherent risk. The earlier this is determined the fewer resources are spent on the failed project thus preserving resource for other activities. The third reason is that any project is continually competing for resources with other activities. A project that has mitigated its biggest risks has a better chance of competing for continued resource allocation than activities that still have high risks.
10.2 Managing Risk

Managing risk means carrying out a systematic process for identifying, measuring and mitigating risks. Managing risk is accomplished by taking actions before risks occur rather than reacting to occurrences of undesirable events. The DoD SEF defines four parts to risk management and the NASA SE Handbook defines five top level parts and a seven block flow chart for risk management. It is helpful to decompose these into 11 steps. The 11 steps in effective risk management are:
1.      Listing the most important requirements that the project must meet to satisfy its customer(s). These are called Cardinal Requirements and are identified in requirements analysis or via Quality Function Deployment.
2.      Identifying every risk to a project that might occur that would have significant consequence to meeting each of the Cardinal Requirements
3.      Estimating the probability of occurrence of each risk and its consequences in terms of arbitrary units or dollars
4.      Ranking the risks by the magnitude of the product of the probability and consequence (i.e. by the definition of risk given above)
5.      Identifying proactive actions that can lower the probability of occurrence and/or the cost of occurrence of the top five or ten risks
6.      Selecting among the identified actions for those that are cost effective
7.      Assigning resources (funds and people) to the selected actions and integrating the mitigation plans into the project budget and schedule
8.      Managing the selected action until its associated risk is mitigated
9.      Identifying any new risks resulting from mitigation activities
10.  Replace mitigated risks with lower ranking or new risks as each is mitigated
11.  Conduct regular (weekly or biweekly) risk management reviews to:
·         Status risk mitigation actions
·         Brainstorm for new risks
·         Review that mitigated risks stay mitigated
In identifying risks it is important to involve as many people that are related to the activity as possible. This means people from senior management, the development organization, other participating organizations and supporting organizations. Senior managers see risks that engineers do not and engineers see risks that managers don’t recognize. It is helpful to use a list of potential sources of risk in order to guide people’s thinking to be comprehensive. A list might look like that shown in Figure 10-1.

Figure 10-1 An example template for helping identify possible sources of risk to the customer’s cardinal requirements.
It also helps ensure completeness of understanding risks if each risk is classified as a technical, cost or schedule risk or a combination of these categories.