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.