Adobe® Digital Editions software.This eBook requires the free
Before downloading this DRM-encrypted PDF, be sure to:
"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."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.
- 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
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.
(Each chapter concludes with a Summary.)
I. RISK MANAGEMENT DISCOVERY.1. Software Risk Management.
Risk in the Large.
Risk in the Small.
Consequences of Knowledge.
Consequences of Ignorance.2. P2I2 Sucess Formula.
Major Factors in Risk Management Capability.
People: The Human Element.
Process: The Steps to Manage Risk.
Infrastructure: The Organizational Foundation.
Implementation: The Project Execution.3. Risk Management Roadmap.
The Road to Risk Management Capability.
Risk Management Roadmap Directions.
Journey from Problem to Opportunity.
Journey from Novice to Expert.
II. RISK MANAGEMENT PROCESS.4. Identify Risk.
Define Risk Identification Process.
Develop Risk Checklists.
Define Risk Assessment Method.
Develop Risk Management Form.
Establish Risk-Database Schema.5. Analyze Risk.
Define Risk Analysis Process.
Define Risk Analysis Techniques.
Define Risk Evaluation Criteria.
Establish Risk Prioritization Scheme.6. Plan Risk.
Define Risk Planning Process.
Define Risk Resolution Strategies.
Define Selection Criteria.
Develop Risk Action Plan Template.7. Track Risk.
Define Risk Tracking Process.
Define Risk Tracking Techniques.
Define Risk Tracking Measures.
Define Triggering Devices.8. Resolve Risk.
Define Risk Resolution Process.
Define Risk Resolution Techniques.
Define Risk Resolution Measures.
Develop Corrective Action Procedure.
III. RISK MANAGEMENT INFRASTRUCTURE.9. Develop Policy.
Survey Existing Practice.
Define Draft Policy.
Review Draft Policy.
Communicate Policy.10. Define Standard Process.
Establish Action Team.
Develop Draft Standard Process.
Review Draft Standard Process.
Document Standard Process.
Approve Standard Process.
Distribute Standard Process.11. Train Risk Technology.
Prepare for Training.
Develop Training Material.
Apply Training Metrics.
Obtain Training Feedback.12. Verify Compliance.
Review Risk Management Plan.
Audit Agents and Artifacts.
Generate Audit Report.
Track Action Items.13. Improve Practice.
Develop Appraisal Method.
Assess Risk Practices.
Develop Improvement Plan.
Implement Improvement Plan.
IV. RISK MANAGEMENT IMPLEMENTATION.14. Establish Initiative.
Review Risk Management Requirements.
Plan Risk Management Activities.
Budget Risk Management Activities.
Schedule Risk Management Activities.
Staff Risk Management Activities.
Coordinate Risk Management Training.15. Develop Plan.
Outline Risk Management Plan.
Define Risk Management Goals.
Define Risk Management Strategy.
Define Risk Management Process.
Define Risk Management Verification.
Define Risk Management Mechanisms.16. Tailor Standard Process.
Review Standard Process.
Examine Tailoring Options.
List Unique Project Factors.
Recommend Process Changes.
Document Standard Process Deviations.17. Assess Risk.
Conduct Risk Assessment.
Develop Candidate Risk List.
Define Risk Attributes.
Document Identified Risk.
Communicate Identified Risk.
Estimate and Evaluate Risk.
Prioritize Risk.18. Control Risk.
Develop Risk Resolution Alternatives.
Select Risk Resolution Strategy.
Develop Risk Action Plan.
Monitor Risk Status.
Execute Risk Action Plan.
Take Corrective Action as Required.
V. PEOPLE IN CRISIS AND CONTROL.19. Stage 1: Problem.
Problem Project Overview.
Process Improvement Initiative.
Process Assessment Results.
Initiative Hindsight.20. Stage 2: Mitigation.
Mitigation Project Overview.
Risk Assessment Preparation.
Risk Assessment Training.
Project Risk Assessment.
Project Risk Management.
Project Risk Retrospective.21. Stage 3: Prevention.
Prevention Project Overview.
Risk Assessment Results.
Risk Practice Survey.
Risk Practice Observations.Stage 4: Anticipation.
Anticipation Project Overview.
Proactive Risk Management.
Organization Measurement Practices.
Risk Management Committee.
Living Lifecycle Model.23. Stage 5: Opportunity.
Opportunity Project Overview.
Fixed Price Problems.
Routine Risk Management.
High Performance Engineering.
The Power Pyramid.Glossary.
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:
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?
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:
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:
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