Skip to main content

Currently Skimming:

4 Managing Risks
Pages 75-90

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 75...
... , and the coarser grain contributing to overarching program risk management, which is the focus of this chapter. To explain how human-system integration fits into program risk-management efforts, an example methodology is presented; however, it should be noted 
From page 76...
... In essence, CAIV entails establishing aggressive cost objectives, bound by maximum acceptable risk, so that if costs are too great and viable opportunities exist to reduce them, then the user and developer may compromise system performance requirements to meet cost objections. The important aspect to glean is that, as HSI risks are identified, their subsequent prioritization must be presented in a manner that shows a pragmatic and balanced understanding of the risk/opportunity's likelihood and consequence traded against acquisition and in-service cost impacts.
From page 77...
... If HSI specialists are not involved in the business offer process, their perspective and knowledge are not accounted for in formulating the program baselines, often making it necessary to use management reserve or negotiated requirements relief to resolve technical risks and issues that may have been otherwise accounted for during proposal activities. The second important program management practice is creating a program organization -- in particular, a product-based organization with clear team charters and integration teams at appropriate organizational levels.
From page 78...
... The risk identification component entails screening candidate risks to ensure validity, deletion of duplicates, clear statement of the risk, and creation of records used to summarize and track risks throughout the program life cycle. Due to the heterogeneity and nuances of program objectives, program life-cycle stages, and skill areas contributing to risk identification, detailed standard approaches are generally not promoted; however, some high-level steps are universal.
From page 79...
... Catalog specific candidate risks Define Risk Process Execution 3. Validate candidate risk list Mgmt Method Identify Risks Evaluate & Refine Develop & Communicate/ Analyze Execute Track Risks Risks Mitigation Evaluate Handling Options FIGURE 4-2 Steps in risk identification.
From page 80...
... In some instances, the interrelated nature of HSI risks may require that it is co-owned by more than the HSI team. Candidate risks are subsequently recorded in a risk-management database.
From page 81...
... Upon completing the candidate risk validation process, HSI risks are included in a program risk watch list that serves as the deliverable for risk identification activities. Risk Analysis Risk analysis determines the levels of likelihood, consequence, and overall risk for each candidate risk, then categorizes (technical, schedule, or cost)
From page 82...
... For candidate risks & executed risk mitigation plans, determine: Define Risk Process Execution Mgmt Method Likelihood & consequence ÿ Risk level ÿ Identify Risks 3. Assess impacts to program Evaluate & Refine 4.
From page 83...
... Individual risks frequently have common elements that make them interdependent despite their independent occurrence; this is especially true for HSI risks. As a result, the potential relations of individual risks to higher level program items may have a collective effect of increasing the risk level of that higher level program item -- hence the importance of collective risk analysis in which the first step in assessing program impacts is to determine the relationship of individual risks to higher level program items
From page 84...
... for individual risks and higher level program items, an identified program risk-critical path, and prioritized individual risks to steer subsequent risk-handling activities. Given the extent of influence that risk analysis has on resource allocation, it is important that HSI practitioners are actively involved in this component of risk management.
From page 85...
... The HSI practitioner is well suited to offer a range of risk-handling options given the flexibility in HSI techniques and bringing a mind set of the impact of those options on user and system performance when the system is operational. Process Management Define Risk Process Execution Mgmt Method Identify Risks Evaluate & Refine Develop & Communicate/ Analyze Execute Track Risks Risks Mitigation Evaluate Handling Options 1.
From page 86...
... Delaying the handling of an HSI risk is often the option chosen because decision makers do not fully appreciate the importance of managing HSI risks proactively and early in the program life cycle. This is particularly true in software development and hardware design, in which ergonomic (anthropometry and biomechanics)
From page 87...
... Risk assumption is another often-used approach for handling HSI risks, primarily because the decision makers do not fully grasp the implications, or the seriousness of the risk does not surface in demonstrable manner until the system is operational. Human-in-the-loop evaluations of system prototypes and system build releases within the spiral life cycle are the most effective means for demonstrating when an HSI risk should not be assumed, but these activities require competing for highly utilized program resources.
From page 88...
... Figure 4-5 is a representation of the risk mitigation activity. Process Management Define Risk Process Execution Mgmt Method Identify Risks Evaluate & Refine Develop & Communicate/ Analyze Execute Track Risks Risks Mitigation Evaluate Handling Options 1.
From page 89...
... Incorporate into Program Schedules Approved risk mitigation plans need to be a formal part of the program schedule and be reflected in the program's metrics to garner the requisite attention needed to accomplish planned mitigation tasks. Generally, "off the books" mitigation efforts suffer from lack of visibility, suboptimal coordination, and improper configuration management.
From page 90...
... As noted previously, any decisions to change the plan need to mandate proper coordination, approval, and incorporation into the program schedule. Successful completion of the risk mitigation step culminates in detailed mitigation plans documented in team and program schedules, fallback plans, approved resources to execute the risk mitigation plan, and completion of the risk mitigation strategy resulting in the expected reduced level of risk.


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.