Managing Risk: Methods for Software Systems Development / Edition 1

Hardcover (Print)
Buy Used
Buy Used from BN.com
$42.51
(Save 39%)
Item is in good condition but packaging may have signs of shelf wear/aging or torn packaging.
Condition: Used – Good details
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 97%)
Other sellers (Hardcover)
  • All (23) from $1.99   
  • New (7) from $9.75   
  • Used (16) from $1.99   

Overview

"The increasing rate of technological change we are experiencing in our lifetime yields competitive advantage to organizations and individuals who are willing to embrace risk and the opportunities it presents. Those who choose to minimize or avoid risk, as opposed to managing it, set a course for obsolescence. Hall has captured the essence of risk management and given us a practical guide for the application of useful principles in software-intensive product development. This is must reading for public and private sector managers who want to succeed as we begin the next century."

- Daniel P. Czelusniak, Director, Acquisition Program Integration Office of the Under Secretary of Defense (Acquisition and Technology) The Pentagon

"Since it is more than just common sense, the newcomer to risk management needs an intelligent guide. It is in this role that Elaine Hall's book excels. This book provides a set of practical and well-delineated processes for implementation of the discipline."

- Tom DeMarco, from the Foreword

Risk is inherent in the development of any large software system. A common approach to risk in software development is to ignore it and hope that no serious problems occur. Leading software companies use quantitative risk management methods as a more useful approach to achieve success.

Written for busy professionals charged with delivering high-quality products on time and within budget, Managing Risk is a comprehensive guide that describes a success formula for managing software risk. The book is divided into five parts that describe a risk management road map designed to take you from crisis to control of your software project.

Highlights include:

  • Six disciplines for managing product development.
  • Steps to predictable risk-management process results.
  • How to establish the infrastructure for a risk-aware culture.
  • Methods for the implementation of a risk management plan.
  • Case studies of people in crisis and in control.
Read More Show Less

Editorial Reviews

Booknews
Describes a success formula for managing software risk, allowing companies to more easily deliver high-quality software on time and within budget. Details six disciplines for managing product development, outlines steps to predictable risk management process results, and shows how to establish the infrastructure for a risk- aware corporate culture. Presents methods for the implementation of a risk management plan, and provides five case studies. Includes a glossary and chapter discussion questions.

Annotation c. by Book News, Inc., Portland, Or.

Read More Show Less

Product Details

  • ISBN-13: 9780201255928
  • Publisher: Addison-Wesley
  • Publication date: 2/5/1998
  • Series: SEI Series in Software Engineering Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 374
  • Product dimensions: 6.62 (w) x 9.56 (h) x 1.00 (d)

Meet the Author

Elaine M. Hall is founder of Level 6 Software, a leading consulting group in discovery methods for software engineering. She conducts training seminars and supports the implementation of software risk management for both government and industry clients worldwide. Dr. Hall is chair of the risk management working group for the International Council on Systems Engineering. She has nearly 20 years of experience in software systems engineering and management.

Read More Show Less

Read an Excerpt

The growing pains of the software community continue with the increased demand for software systems. The fact that software, the code developed to execute in a computing system, is pervasive in todayIs society is both a problem and an opportunity for managers and engineers. Many software professionals see the problems, but only a few see the opportunities. Problems that cause projects to be late, over budget, or of poor quality are collectively known within the community as the software crisis. Application of traditional problem solving methods to solve the software crisis has been U for the most part U ineffective. The source of the software crisis is the project, process, and product risk that turns into problems because risk management is not done. Risk management differs from traditional problem solving, for the simple reason that a risk is not a problem. By analogy, risk management is to a risk what an algorithm is to a problem. Whereas problems may be solved by application of algorithms, a risk may be resolved by application of risk management.

Software-risk management is a practice to resolve risks that affect the software project, process, or product. The purpose of Managing Risk is to help people responsible for software systems to acquire the knowledge necessary to apply software-risk management. This book provides a handy reference to help busy professionals assess and control software risks.

This book will enable you to answer the following questions:

  • What does it take to manage software risk?
  • What is my current ability to manage software risk?
  • How can I increase my ability to manage software risk?
This book is a practical guide formanaging software risk that is easy to use. It describes an approach to manage risk based on proven practices. Whether your level of expertise in managing risk is novice, beginner, intermediate, advanced, or expert, the five stages of risk-management evolution ensure that you know where to start your journey.

Because risk is defined as the possibility of loss, traditional works often portray risk with a negative connotation. This book is distinctive in that it has a broad and positive perspective on risk. Risk has long been associated with unmet reliability, safety, and security requirements. Although these requirements are important applications of risk concepts, they do not preclude managing risk to satisfy any other requirement U such as profitability, reusability, and quality. This book makes no assumptions about what your requirements are; it simply encourages you to take a broad view of managing risk to satisfy your requirements and achieve your goals. This book does not judge the consequence of a risk. Instead, risk is reframed in a positive manner; opportunity cost is viewed as a loss. A broad and positive perspective of risk challenges us to exceed expectations through possibility thinking: How can we manage risk to benefit from the enormous opportunity that exists today in the field of software?

Audience
This book is written for people who manage and develop software systems, including those who hold the responsibilities for oversight and improvement of a software project, product, or process. I assume that you are a busy professional, interested in maintaining a competitive advantage for yourself and your organization. Your job could be one of these:

  • Senior manager, responsible for management of an organization that has a core competency in software.
  • Engineering manager, responsible for functional management of technical individuals who develop or maintain software systems.
  • Project manager of software systems acquisition, development, or maintenance.
  • Software manager, responsible for directing software teams.
  • Systems engineer, responsible for meeting the technical requirements of software systems.
  • Software engineer, responsible for large-scale software development or maintenance.
  • Quality-assurance specialist, responsible for verification of process and product compliance using risk identification and problem prevention as a proactive strategy.
  • Measurement analyst, responsible for either short term or long term measurement of software projects.
  • Engineering process-group or process-action-team member, responsible for organizational technology transfer, process definition, and process improvement.
  • Change agent, working with software organizations as a corporate trainer.
  • Process consultant, performing risk assessment and risk management for clients within the government or commercial software sector.
  • College professor, teaching software-project management or risk management.
Book Overview
The book is divided into five parts that describe a risk-management roadmap designed to take you from crisis to control of your software project. The path to increasing your ability to manage risk is shown through progress in four synergistic dimensions of people, process, infrastructure, and implementation. These dimensions provide a separation of responsibility and focus that map to the specialization of the roles required on a software project. Parallel efforts in each dimension may speed the transition of risk management in your organization.

Each book part is introduced with a brief overview that summarizes the key topics covered in each Chapter, and why they are important. These five parts are:

  • Part I, Risk-Management Discovery, lays the foundation for understanding the role of risk management in software engineering. The relationship of six disciplines are described that illustrate where risk fits in to managing product development. Factors which contribute to the ability to manage software risks are described to show their relationship and relative importance. The Personal Risk-Management Matrix and the Risk-Management Roadmap are presented to provide understanding and motivation for improvement.
  • Part II, Risk-Management Process, elaborates the activities to perform risk management using a standard process-definition notation. Process steps, inputs, and outputs are fully defined. Methods and tools used by the process are shown by example. The process dimension describes the steps to predictable risk management results in terms of what and how. Engineering process-group or process-action-team members and process consultants can appreciate this reusable process component.
  • Part III, Risk-Management Infrastructure, provides the organizational foundation that supports the establishment of a risk-aware culture. Training metrics help you provide just-enough information just-in-time. Techniques for project oversight are included, as well as a method for establishing a baseline for quantitative process improvement. Without infrastructure, there is no strategic plan in place to institutionalize risk management. Senior managers, engineering managers, and change agents should benefit from these organizational building blocks.
  • Part IV, Risk-Management Implementation, instantiates the standard process within a software project. Risk management activities throughout the lifecycle are planned, budgeted, scheduled, and staffed. The implementation dimension describes who, where, when, and why. The details of the risk-management plan are presented, with tailoring suggestions for the standard process. Project managers, software managers, systems engineers, and software engineers behind schedule may tailor this plan to quickly claim progress.
  • Part V, People in Crisis and Control, describes different project teams whose practices formed the basis of the risk-management evolution stages. These case studies provide a wealth of experiences, ancedotes, and benchmark data from the 1990s. I had the opportunity to survey and study peopleIs perceptions of the performance and importance of their risk-management practices. Effective and ineffective practices were identified by project managers, engineering managers, configuration managers, quality assurance specialists, systems engineers, software engineers, test engineers, and the customer. These insights and lessons learned should be invaluable to people struggling to manage software-systems risk.
How to Read This Book
The approach for reading this book depends on your job category, and your risk-management ability. Everyone should read Part I to provide the background for the rest of the book. Read Chapter 1 completely if you are a risk-management novice. Read Chapter 2 to learn the success formula for managing risk. Read Chapter 3 to understand the roadmap to increase your risk-management ability. Depending on your job category, Parts II-IV will apply. Read Part II if you are responsible for risk-management process definition or execution. Read Part III if you are responsible for establishing risk-management policy, conducting training, verifying compliance, or improving the process. Read Part IV if you are responsible for planning, tailoring, or performing risk management on a project. Everyone should read the case studies in Part V to benchmark their personal, project, and organization risk-management capability. As you read the case study that characterizes practices most similar to your own, you should be able to identify with the people and their behaviors. Note the similarities and the differences. More than likely, there will be differences due to individual risk preference, and your assessment of practices either above or below the level described in the case study. Read the following case study to help you determine the next steps in evolving your risk-management ability. You can use the questions at the end of each chapter to support retention and learning.

Acknowledgments
I would like to acknowledge the pioneers in the field of software-risk management for their foundational material. In order to add to the body of knowledge in this area, I stood on the shoulders of Dr. Barry Boehm, Dr. Robert Charette, and the Software Engineering Institute (SEI). Their ideas inspired me to develop risk-management methods for use by the software community.

Several managers were responsible for my process-improvement experience at Harris Corporation. Phil Henderson, as General Manager of the Information Systems Division (ISD), established the Software Process Team and funded the Software Engineering Process Group (SEPG) to improve the software engineering process. Hank Eyster, as division Director and Steering Committee representative on the Software Process Team, supported training and use of risk assessment and risk management on projects. Gary Natwick, who as SEPG Manager, recognized my enthusiasm for risk management and allowed me time to write articles and present papers. Those who worked with me on the Software-Risk Management Action Team were Clay Eberle, Jane Eden, Gary Natwick, Lon Hixson, Russ Hooper, and Steve Morris. Their cross-functional perspectives helped to evaluate and expand the current documented policy for risk management with a focus on practical-project implementation.

The benefits derived from the SEI efforts in technology transfer cannot be overstated. I was able to leverage their expertise to assist pursuits, proposals, and project teams in establishing effective risk management practices. Ken Dymond, Walt Lamia, and George Pandelios at the SEI Risk Program provided my early training in risk assessment. I am grateful for them, and others who contributed to the SEI Risk Program. Those with whom I worked to write a key process area for risk management were: Dr. Robert Charette, Dr. George Kambic, Roy Kimbrell, George Pandelios, and Charlie Weber. Those who made the SEI/Harris technical-collaboration agreement possible included Julia Allen and Clyde Chittister. For help in streamlining the risk-assessment process, I want to thank Carol Ulrich and Marvin Carr. Thanks to Mike Dedolph and Julie Walker for on-the-job training in Software Risk Evaluation, and Audrey Dorofee for training in the Risk Clinic.

My involvement in systems engineering process improvement through the International Council on Systems Engineering (INCOSE) has broadened my perspective in risk management. For those who discussed ideas with me including Dr. George Friedman, Dr. Jerry Lake, Jim Brill, and Dr. Larry Brekka, former Chairman of the INCOSE Risk-Management Working Group. Members who shared their experiences in risk management with me including Art Gemmer, John Hazelwood, Rudy Elam, and Bob Shishko. To members who contributed technical papers on risk practices to the national symposium, especially Dr. Dennis Beude for enlightening me on tools for risk analysis.

Many organizations contributed to the Department of DefenseIs Software Acquisition Best Practices Initiative. Those that shared risk practices included Aerospace Corporation, C&C Associates, Ceridian Corporation, Harris Corporation, Mitre Corporation, and Unisys. Norm Brown, initiative coordinator and Director of the Software Program Managers Network (SPMN), deserves the credit for condensing industrial strength software management strategies from the reported best practices. At the SPMN, I learned commercial best practices and the need for them to help meet defense needs at lower cost. The Airlie Software Council, especially opinion leader Tom DeMarco, deserves the credit for encouraging consensus that the number one best practice in software acquisition is formal risk management. I thank the attendees of my Software-Risk Management seminars at the Defense Systems Management College, and in London, Orlando, New Zealand, and Washington, D.C. for sharing their risks, questions, and improvement suggestions.

Peter Gordon, my sponsoring editor, provided the opportunity to share my knowledge and experiences. Reviewers who contributed distinctly different perspectives are Tom Gorsuch, Dick Newman, Wade Shaw, and Hank Stuebing. Thanks to those at Addison-Wesley who made this book possible, and especially to Helen Goldstein, who made it a delight.

Elaine M. Hall
INDIALANTIC, FL.
Read More Show Less

Table of Contents

FOREWORD

PREFACE

PART I:: RISK MANAGEMENT DISCOVERY

1.: SOFTWARE RISK MANAGEMENT
1.1: Foundations
1.2: Risk in the Large
1.3: Risk in the Small
1.4: Consequences of Knowledge
1.5: Consequences of Ignorance
1.6: Summary

2.: P2I2 SUCCESS FORMULA
2.1: Major Factors in Risk Management Capability
2.2: People: The Human Element
2.3: Process: The Steps to Manage Risk
: 2.4: Infrastructure: The Organizational Foundation
2.5: Implementation: The Project Execution
2.6: Summary

3.: RISK MANAGEMENT ROADMAP
3.1: The Road to Risk Management Capability
3.2: Risk Management Roadmap Directions
3.3: Journey from Problem to Opportunity
3.4: Journey from Novice to Expert
3.5: Summary


PART II:: RISK MANAGEMENT PROCESS

4.: IDENTIFY RISK
4.1: Define Risk Identification Process
4.2: Develop Risk Checklists
4.3: Define Risk Assessment Method
4.4: Develop Risk Management Form
4.5: Establish Risk-Database Schema
4.6: Summary

5.: ANALYZE RISK
5.1: Define Risk Analysis Process
5.2: Define Risk Analysis Techniques
5.3: Define Risk Evaluation Criteria
5.4: Establish Risk Prioritization Scheme
5.5: Summary

6.: PLAN RISK
6.1: Define Risk Planning Process
6.2: Define Risk Resolution Strategies
6.3: Define Selection Criteria
6.4: Develop Risk Action Plan Template
6.5: Summary

7.: TRACK RISK
7.1: Define Risk Tracking Process
7.2: Define Risk Tracking Techniques
7.3: Define Risk Measures and Metrics
7.4: Define Triggering Devices
7.5: Summary

8.: RESOLVE RISK
8.1: Define Risk Resolution Process
8.2: Define Risk Resolution Techniques
8.3: Define Risk Management ROI
8.4: Develop Corrective Action Procedure
8.5: Summary

PART III:: RISK MANAGEMENT INFRASTRUCTURE

9.: DEVELOP POLICY
9.1: Obtain Commitment
9.2: Allocate Resources
9.3: Survey Existing Practice
9.4: Define Draft Policy
9.5: Review Draft Policy
9.6: Document Policy
9.7: Approve Policy
9.8: Communicate Policy
9.9: Summary

10.: DEFINE STANDARD PROCESS
10.1: Establish Action Team
10.2: Develop Draft Standard Process
10.3: Review Draft Standard Process
10.4: Document Standard Process
10.5: Approve Standard Process
10.6: Distribute Standard Process
10.7: Summary

11.: TRAIN RISK TECHNOLOGY
11.1: Prepare for Training
11.2: Develop Training Material
11.3: Apply Training Metrics
11.4: Deliver Training
11.5: Obtain Training Feedback
11.6: Summary

12.: VERIFY COMPLIANCE
12.1: Review Risk Management Plan
12.2: Audit Agents and Artifacts
12.3: Generate Audit Report
12.4: Track Action Items
12.5: Summary

13.: IMPROVE PRACTICE
13.1: Develop Appraisal Method
13.2: Assess Risk Practices
13.3: Develop Improvement Plan
13.4: Implement Improvement Plan
13.5: Summary


PART IV:: RISK MANAGEMENT IMPLEMENTATION

14.: ESTABLISH INITIATIVE
14.1: Review Risk Management Requirements
14.2: Plan Risk Management Activities
14.3: Budget Risk Management Activities
14.4: Schedule Risk Management Activities
14.5: Staff Risk Management Activities
14.6: Coordinate Risk Management Training
14.7: Summary

15.: DEVELOP PLAN
15.1: Outline Risk Management Plan
15.2: Define Risk Management Goals
15.3: Define Risk Management Strategy
15.4: Define Risk Management Process
15.5: Define Risk Management Verification
15.6: Define Risk Management Mechanisms
15.7: Summary

16.: TAILOR STANDARD PROCESS
16.1: Review Standard Process
16.2: Examine Tailoring Options
16.3: List Unique Project Factors
16.4: Recommend Process Changes
16.5: Document Standard Process Deviations
16.6: Summary

17.: ASSESS RISK
17.1: Conduct Risk Assessment
17.2: Develop Candidate Risk List
17.3: Define Risk Attributes
17.4: Document Identified Risk
17.5: Communicate Identified Risk
17.6: Estimate and Evaluate Risk
17.7: Prioritize Risk
17.8: Summary

18.: CONTROL RISK
18.1: Develop Risk Resolution Alternatives
18.2: Select Risk Resolution Strategy
18.3: Develop Risk Action Plan
18.4: Monitor Risk Status
18.5: Execute Risk Action Plan
18.6: Take Corrective Action as Required
18.7: Summary

PART V:: PEOPLE IN CRISIS AND CONTROL

19.: STAGE 1: PROBLEM
19.1: Problem Project Overview
19.2: Process Improvement Initiative
19.3: Process Assessment
19.4: Process Assessment Results
19.5: Initiative Hindsight
19.6: Summary

20.: STAGE 2: MITIGATION
20.1: Mitigation Project Overview
20.2: Risk Assessment Preparation
20.3: Risk Assessment Training
20.4: Project Risk Assessment
20.5: Project Risk Management
20.6: Project Risk Retrospective
20.7: Summary

21.: STAGE 3: PREVENTION
21.1: Prevention Project Overview
21.2: Risk Assessment Results
21.3: Risk Manager
21.4: Risk Practice Survey
21.5: Risk Practice Observations
21.6: Summary

22.: STAGE 4: ANTICIPATION
22.1: Anticipation Project Overview
22.2: Proactive Risk Management
22.3: Organization Measurement Practices
22.4: Risk Management Committee
22.5: Living Lifecycle Model
22.6: Summary

23.: STAGE 5: OPPORTUNITY
23.1: Opportunity Project Overview
23.2: Fixed Price Problems
23.3: Routine Risk Management
23.4: High Performance Engineering
23.5: The Power Pyramid
23.6: Summary


EPILOGUE

GLOSSARY

INDEX

Read More Show Less

Preface

The growing pains of the software community continue with the increased demand for software systems. The fact that software, the code developed to execute in a computing system, is pervasive in today's society is both a problem and an opportunity for managers and engineers. Many software professionals see the problems, but only a few see the opportunities. Problems that cause projects to be late, over budget, or of poor quality are collectively known within the community as the software crisis. Application of traditional problem solving methods to solve the software crisis has been — for the most part — ineffective. The source of the software crisis is the project, process, and product risk that turns into problems because risk management is not done. Risk management differs from traditional problem solving, for the simple reason that a risk is not a problem. By analogy, risk management is to a risk what an algorithm is to a problem. Whereas problems may be solved by application of algorithms, a risk may be resolved by application of risk management. Software-risk management is a practice to resolve risks that affect the software project, process, or product. The purpose of Managing Risk is to help people responsible for software systems to acquire the knowledge necessary to apply software-risk management. This book provides a handy reference to help busy professionals assess and control software risks. This book will enable you to answer the following questions: What does it take to manage software risk? What is my current ability to manage software risk? How can I increase my ability to manage software risk? This book is a practical guide for managing software risk that is easy to use. It describes an approach to manage risk based on proven practices. Whether your level of expertise in managing risk is novice, beginner, intermediate, advanced, or expert, the five stages of risk-management evolution ensure that you know where to start your journey. Because risk is defined as the possibility of loss, traditional works often portray risk with a negative connotation. This book is distinctive in that it has a broad and positive perspective on risk. Risk has long been associated with unmet reliability, safety, and security requirements. Although these requirements are important applications of risk concepts, they do not preclude managing risk to satisfy any other requirement — such as profitability, reusability, and quality. This book makes no assumptions about what your requirements are; it simply encourages you to take a broad view of managing risk to satisfy your requirements and achieve your goals. This book does not judge the consequence of a risk. Instead, risk is reframed in a positive manner; opportunity cost is viewed as a loss. A broad and positive perspective of risk challenges us to exceed expectations through possibility thinking: How can we manage risk to benefit from the enormous opportunity that exists today in the field of software?

Audience
This book is written for people who manage and develop software systems, including those who hold the responsibilities for oversight and improvement of a software project, product, or process. I assume that you are a busy professional, interested in maintaining a competitive advantage for yourself and your organization. Your job could be one of these: Senior manager, responsible for management of an organization that has a core competency in software. Engineering manager, responsible for functional management of technical individuals who develop or maintain software systems. Project manager of software systems acquisition, development, or maintenance. Software manager, responsible for directing software teams. Systems engineer, responsible for meeting the technical requirements of software systems. Software engineer, responsible for large-scale software development or maintenance. Quality-assurance specialist, responsible for verification of process and product compliance using risk identification and problem prevention as a proactive strategy. Measurement analyst, responsible for either short term or long term measurement of software projects. Engineering process-group or process-action-team member, responsible for organizational technology transfer, process definition, and process improvement. Change agent, working with software organizations as a corporate trainer. Process consultant, performing risk assessment and risk management for clients within the government or commercial software sector. College professor, teaching software-project management or risk management.

Book Overview
The book is divided into five parts that describe a risk-management roadmap designed to take you from crisis to control of your software project. The path to increasing your ability to manage risk is shown through progress in four synergistic dimensions of people, process, infrastructure, and implementation. These dimensions provide a separation of responsibility and focus that map to the specialization of the roles required on a software project. Parallel efforts in each dimension may speed the transition of risk management in your organization. Each book part is introduced with a brief overview that summarizes the key topics covered in each Chapter, and why they are important. These five parts are: Part I, Risk-Management Discovery, lays the foundation for understanding the role of risk management in software engineering. The relationship of six disciplines are described that illustrate where risk fits in to managing product development. Factors which contribute to the ability to manage software risks are described to show their relationship and relative importance. The Personal Risk-Management Matrix and the Risk-Management Roadmap are presented to provide understanding and motivation for improvement. Part II, Risk-Management Process, elaborates the activities to perform risk management using a standard process-definition notation. Process steps, inputs, and outputs are fully defined. Methods and tools used by the process are shown by example. The process dimension describes the steps to predictable risk management results in terms of what and how. Engineering process-group or process-action-team members and process consultants can appreciate this reusable process component. Part III, Risk-Management Infrastructure, provides the organizational foundation that supports the establishment of a risk-aware culture. Training metrics help you provide just-enough information just-in-time. Techniques for project oversight are included, as well as a method for establishing a baseline for quantitative process improvement. Without infrastructure, there is no strategic plan in place to institutionalize risk management. Senior managers, engineering managers, and change agents should benefit from these organizational building blocks. Part IV, Risk-Management Implementation, instantiates the standard process within a software project. Risk management activities throughout the lifecycle are planned, budgeted, scheduled, and staffed. The implementation dimension describes who, where, when, and why. The details of the risk-management plan are presented, with tailoring suggestions for the standard process. Project managers, software managers, systems engineers, and software engineers behind schedule may tailor this plan to quickly claim progress. Part V, People in Crisis and Control, describes different project teams whose practices formed the basis of the risk-management evolution stages. These case studies provide a wealth of experiences, ancedotes, and benchmark data from the 1990s. I had the opportunity to survey and study people's perceptions of the performance and importance of their risk-management practices. Effective and ineffective practices were identified by project managers, engineering managers, configuration managers, quality assurance specialists, systems engineers, software engineers, test engineers, and the customer. These insights and lessons learned should be invaluable to people struggling to manage software-systems risk.

How to Read This Book
The approach for reading this book depends on your job category, and your risk-management ability. Everyone should read Part I to provide the background for the rest of the book. Read Chapter 1 completely if you are a risk-management novice. Read Chapter 2 to learn the success formula for managing risk. Read Chapter 3 to understand the roadmap to increase your risk-management ability. Depending on your job category, Parts IIDIV will apply. Read Part II if you are responsible for risk-management process definition or execution. Read Part III if you are responsible for establishing risk-management policy, conducting training, verifying compliance, or improving the process. Read Part IV if you are responsible for planning, tailoring, or performing risk management on a project. Everyone should read the case studies in Part V to benchmark their personal, project, and organization risk-management capability. As you read the case study that characterizes practices most similar to your own, you should be able to identify with the people and their behaviors. Note the similarities and the differences. More than likely, there will be differences due to individual risk preference, and your assessment of practices either above or below the level described in the case study. Read the following case study to help you determine the next steps in evolving your risk-management ability. You can use the questions at the end of each chapter to support retention and learning.

Acknowledgments
I would like to acknowledge the pioneers in the field of software-risk management for their foundational material. In order to add to the body of knowledge in this area, I stood on the shoulders of Dr. Barry Boehm, Dr. Robert Charette, and the Software Engineering Institute (SEI). Their ideas inspired me to develop risk-management methods for use by the software community. Several managers were responsible for my process-improvement experience at Harris Corporation. Phil Henderson, as General Manager of the Information Systems Division (ISD), established the Software Process Team and funded the Software Engineering Process Group (SEPG) to improve the software engineering process. Hank Eyster, as division Director and Steering Committee representative on the Software Process Team, supported training and use of risk assessment and risk management on projects. Gary Natwick, who as SEPG Manager, recognized my enthusiasm for risk management and allowed me time to write articles and present papers. Those who worked with me on the Software-Risk Management Action Team were Clay Eberle, Jane Eden, Gary Natwick, Lon Hixson, Russ Hooper, and Steve Morris. Their cross-functional perspectives helped to evaluate and expand the current documented policy for risk management with a focus on practical-project implementation. The benefits derived from the SEI efforts in technology transfer cannot be overstated. I was able to leverage their expertise to assist pursuits, proposals, and project teams in establishing effective risk management practices. Ken Dymond, Walt Lamia, and George Pandelios at the SEI Risk Program provided my early training in risk assessment. I am grateful for them, and others who contributed to the SEI Risk Program. Those with whom I worked to write a key process area for risk management were: Dr. Robert Charette, Dr. George Kambic, Roy Kimbrell, George Pandelios, and Charlie Weber. Those who made the SEI/Harris technical-collaboration agreement possible included Julia Allen and Clyde Chittister. For help in streamlining the risk-assessment process, I want to thank Carol Ulrich and Marvin Carr. Thanks to Mike Dedolph and Julie Walker for on-the-job training in Software Risk Evaluation, and Audrey Dorofee for training in the Risk Clinic. My involvement in systems engineering process improvement through the International Council on Systems Engineering (INCOSE) has broadened my perspective in risk management. For those who discussed ideas with me including Dr. George Friedman, Dr. Jerry Lake, Jim Brill, and Dr. Larry Brekka, former Chairman of the INCOSE Risk-Management Working Group. Members who shared their experiences in risk management with me including Art Gemmer, John Hazelwood, Rudy Elam, and Bob Shishko. To members who contributed technical papers on risk practices to the national symposium, especially Dr. Dennis Beude for enlightening me on tools for risk analysis. Many organizations contributed to the Department of Defense's Software Acquisition Best Practices Initiative. Those that shared risk practices included Aerospace Corporation, C&C Associates, Ceridian Corporation, Harris Corporation, Mitre Corporation, and Unisys. Norm Brown, initiative coordinator and Director of the Software Program Managers Network (SPMN), deserves the credit for condensing industrial strength software management strategies from the reported best practices. At the SPMN, I learned commercial best practices and the need for them to help meet defense needs at lower cost. The Airlie Software Council, especially opinion leader Tom DeMarco, deserves the credit for encouraging consensus that the number one best practice in software acquisition is formal risk management. I thank the attendees of my Software-Risk Management seminars at the Defense Systems Management College, and in London, Orlando, New Zealand, and Washington, D.C. for sharing their risks, questions, and improvement suggestions. Peter Gordon, my sponsoring editor, provided the opportunity to share my knowledge and experiences. Reviewers who contributed distinctly different perspectives are Tom Gorsuch, Dick Newman, Wade Shaw, and Hank Stuebing. Thanks to those at Addison-Wesley who made this book possible, and especially to Helen Goldstein, who made it a delight.

Elaine M. Hall
INDIALANTIC, FL.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)