Developing a Risk Table
6.4.1 Developing a Risk Table
A risk table provides a project manager with a simple technique for risk projection. 2
A sample risk table is illustrated in Figure 6.2.
Risks Category Probability Impact RMMM
2 Larger number of users than planned
Size estimate may be significantly low
PS
3 Less reuse than planned
PS
2 End-users resist system
PS
3 Delivery deadline will be tightened
BU
2 Funding will be lost
BU
1 Customer will change requirements
CU
2 Technology will not meet expectations
PS
1 Lack of training on tools
TE
3 Staff inexperienced
DE 80%
2 Staff turnover will be high
Impact values: 1—catastrophic 2—critical 3—marginal 4—negligible
F I G U R E 6.2 Sample risk table prior to sorting
2 The risk table should be implemented as a spreadsheet model. This enables easy manipulation and sorting of the entries.
Risk and Very high management concern
Impact
Disregard risk factor
High
Management
Very low
concern
Probability of occurrence
A project team begins by listing all risks (no matter how remote) in the first col- umn of the table. This can be accomplished with the help of the risk item check- Think hard about the
lists referenced in Section 6.3. Each risk is categorized in the second column (e.g., software you’re about
PS implies a project size risk, BU implies a business risk). The probability of occur- to build and ask
rence of each risk is entered in the next column of the table. The probability value yourself, “What can go
wrong?” Create your for each risk can be estimated by team members individually. Individual team mem- own list and ask other
bers are polled in round-robin fashion until their assessment of risk probability members of the
begins to converge. software team to do
Next, the impact of each risk is assessed. Each risk component is assessed using the same. the characterization presented in Figure 6.1, and an impact category is determined.
The categories for each of the four risk components—performance, support, cost, and schedule—are averaged 3 to determine an overall impact value. Once the first four columns of the risk table have been completed, the table is sorted by probability and by impact. High-probability, high-impact risks percolate to The risk table is sorted the top of the table, and low-probability risks drop to the bottom. This accomplishes by probability and
first-order risk prioritization. impact to rank risks.
The project manager studies the resultant sorted table and defines a cutoff line. The cutoff line (drawn horizontally at some point in the table) implies that only risks that lie above the line will be given further attention. Risks that fall below the line are re-evaluated to accomplish second-order prioritization. Referring to Figure 6.3, risk impact and probability have a distinct influence on management concern. A risk fac-
3 A weighted average can be used if one risk component has more significance for the project.
tor that has a high impact but a very low probability of occurrence should not absorb
a significant amount of management time. However, high-impact risks with moder- ate to high probability and low-impact risks with high probability should be carried forward into the risk analysis steps that follow.
All risks that lie above the cutoff line must be managed. The column labeled RMMM contains a pointer into a Risk Mitigation, Monitoring and Management Plan “Failure to prepare is
or alternatively, a collection of risk information sheets developed for all risks that preparing to fail.”
lie above the cutoff. The RMMM plan and risk information sheets are discussed in
Ben Franklin
Sections 6.5 and 6.6. Risk probability can be determined by making individual estimates and then devel- oping a single consensus value. Although that approach is workable, more sophisti- cated techniques for determining risk probability have been developed [AFC88]. Risk drivers can be assessed on a qualitative probability scale that has the following val- ues: impossible, improbable, probable, and frequent. Mathematical probability can then be associated with each qualitative value (e.g., a probability of 0.7 to 1.0 implies
a highly probable risk).
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more