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 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 ineffective for the most part. 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 the application of algorithms, a risk may be resolved by application of risk management.

Software risk management is a practice designed to resolve risks that affect the software project, process, or product. The goal of Managing Risk is to help people responsible for software systems 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 help you answer the following questions:

1. What does it take to manage software risk?

2. What is my ability to manage software risk?

3. How can I increase my ability to manage software risk?

This book is a practical, easy-to-use guide for managing software risk that describes an approach based on proved 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 it with a negative connotation. This book however, 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, it reframes risk in a positive manner, and views opportunity cost as a loss. A broad and positive perspective of risk challenges us to exceed expectations through thinking about the possibilities. 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 staff 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 road map designed to take you from crisis to control of software projects. 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 begins with a brief overview that summarizes the key topics covered in each chapter and why they are important.

Part I, “Risk Management Discovery,” lays the foundation for understanding the role of risk management in software engineering. The chapters describe the relationship of six disciplines that illustrate where risk fits in to managing product development and the factors that contribute to the ability to manage software risks. The Risk Management Map, Personal Risk Management Matrix and the Ten-Point Game Plan 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,” sets out 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 life cycle 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, especially useful for project managers, software managers, systems engineers, and software engineers behind schedule.

Part V, “People in Crisis and Control,” describes actual 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 and identified effective and ineffective practices used by project managers, engineering managers, configuration managers, quality assurance specialists, systems engineers, software engineers, test engineers, and customers. 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, which provides the background for the rest of the book. If you are a risk management novice read Chapter 1 completely. Read Chapter 2 to learn the success formula for managing risk. Read Chapter 3 to understand the road map to increase your risk management ability. Depending on your job category, Parts II through IV will apply. Read Part II if you are responsible for risk management process definition or execution; Part III if you are responsible for establishing risk management policy, training, compliance, verification, or process improvement; and 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 organizational risk management capability.

These case studies are based on a range of software projects. Read them to determine whether your risk management process is above or below the levels described. Use them to define the steps needed to mature your risk management ability. Technical terms in boldface are explained in the Glossary. You might read a section out of order and find a term defined a few chapters back. The questions at the end of each chapter support retention and learning.

Acknowledgments

I acknowledge those software risk management pioneers who built a body of fundamental knowledge. Barry Boehm, Robert Charette, and the Software Engineering Institute (SEI) inspired me to develop this practical set of risk management methods applicable to the entire software community.

Several managers were responsible for my process improvement experience at Harris Corporation. Phil Henderson, as general manager of the Information Systems Division, established the Software Process Team and funded the Software Engineering Process Group (SEPG) to improve the software process. Hank Eyster, division director and steering committee representative on the Software Process Team, supported training and the use of project risk assessment and risk management. Gary Natwick, 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 this 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 to 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 Robert Charette, 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 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 on risk management. I thank those who discussed ideas with me, including George Friedman, Jerry Lake, Jim Brill, and Larry Brekka, former chair of the INCOSE Risk Management Working Group. Members who shared their experiences in risk management with me include Bob Shishko, Art Gemmer, John Hazelwood, and Rudy Elam. Thanks also to members who contributed technical papers on risk practices to the national symposium, especially 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 Barry Boehm, John D. Eikenberry, Tom Gorsuch, Susan Tinch Johnson, J. Richard Newman, Richard Rubinstein, Professor Wade H. Shaw, David Siefert, 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, Florida