1 Software Risk Management
In the middle of difficulty lies opportunity.
—Albert Einstein
The quest for an effective approach to managing software development is as sought after today as the Holy Grail was in medieval times. Just as the grail remained elusive to errant knights, the panacea for the software crisis has yet to be discovered by the software community. We continue to search for our grail in new and improved standards, languages, methods, and tools. In our failure to discover it, we blame people, process, technology, and management. Focus in any single area will not provide the synergy required to help the software community. Only a requisite set of properly coordinated disciplines can lead the crusade on software risk.
In this chapter, I define software risk and describe the need for software risk management. I describe a six-discipline model that integrates risk into the way we think. I discuss how we create opportunity by applying persistence to the possibilities.
This chapter answers the following questions:
What is software risk management?
Why is risk management necessary for software systems development?
How does risk fit into the big picture of managing product development?
1.1 Foundations
At the foundation of modern life in engineering, finance, insurance, medicine, and science is the mastery of risk. Peter Bernstein, a Wall Street economist, argues that the notion of bringing risk under control is one of the central ideas that distinguishes modern times from the more distant past [Bernstein96].
1.1.1 Risk
Risk as a science was born in the sixteenth-century Renaissance, a time of discovery. The word risk derives from the early Italian risicare, which means “to dare.” Games of chance led to the discovery of the theory of probability, the mathematical heart of risk. Today we define risk as the possibility of loss [American85]. We obtain an instance of a risk by specifying values for the risk attributes of probability (the possibility) and consequence (the loss). Probability is the likelihood that the consequence will occur. Consequence is the effect of an unsatisfactory outcome. I use the notation L2 to denote that we measure risk exposure by multiplying likelihood times loss.
Blaise Pascal and Daniel Bernoulli significantly contributed to defining risk. In 1654, the French mathematician Blaise Pascal solved a puzzle for gamblers. His solution of how to divide the stakes of an unfinished game of chance, called balla, led to the discovery of the theory of probability, which provides a method to calculate uncertainty. Pascal worked inductively to create Pascal’s Triangle for determining the probability of possible outcomes [David62]. This type of systematic method for measuring probability in terms of numbers is the cornerstone of modern insurance.
In 1738, in a paper titled “Exposition of a New Theory on the Measurement of Risk” [Bernoulli38], Swiss mathematician Daniel Bernoulli introduced the concept of utility, a measure of the consequences of an outcome in valuing risk. Bernoulli recognized that utility is dependent on the particular circumstances of the person valuing risk. He defined a procedure for introducing these subjective considerations into decisions that have uncertain outcomes. (A decision is the passing of judgment on an issue under consideration.) He suggested that our desire for wealth is inversely proportionate to the quantity of goods possessed. Bernoulli’s emphasis was on decision making based on a desire for wealth and opportunity rather than mathematical probability. Utility theory provides the basis for the law of supply and demand in economics.
1.1.2 Risk Management
Risk management can be traced to the eighteenth century era of Enlightenment, a time of searching for knowledge and exploring the unknown. Today we use risk management as a general procedure for resolving risks. Risk management is said to resolve a risk if, when it is applied to any instance, the possible consequences are all acceptable. Acceptable risk means that we can live with the worst-case outcome. There are two major activities in any risk management process. The first activity, risk assessment, defines the risk. Risk assessment is a discovery process of identifying sources of risk and evaluating their potential effects. The second activity, risk control, resolves the risk. Risk control is a process of developing risk resolution plans, monitoring risk status, implementing risk resolution plans, and correcting for deviations from the plan. You do not need to know what the risks are to begin risk management. It is normal to start the risk management process with fuzzy issues, concerns, doubts, and unknowns. The process of risk management transforms this uncertainty into acceptable risk.
Risk management transcends modern management theory, such as Total Quality Management (TQM) [Kolarik95] and Business Process Reengineering (BPR) [Champy95], because it is basic to decision making. Risk management is based on theories that provide different strategies for decision making under probabilistic conditions. All strategies attempt to improve the quality of decisions on the evaluation of two or more alternative courses of action [Clemen91].
Nine theories for decision making are fundamental to the practice of risk management.
Bayes theorem describes how to blend new information into old. In 1763, English minister Thomas Bayes’s Essay Towards Solving a Problem in the Doctrine of Chances was published [Bayes63]. Bayes addresses the dynamic nature of risk by providing a method to alter judgment as events unfold. Under conditions of uncertainty, there can be no static answer. The Bayesian system of inference is a learning process used in risk management to account for new information. It is fitting that Bayes himself is characterized in business statistics literature as “enigmatic” [Groebner93]. Risk management often begins with enigma: information that is mysterious, ambiguous, puzzling, paradoxical, and obscure.
Chaos theory tells us that chaos and uncertainty are market opportunities. We should take a competitive situation as given and learn to thrive on it. Winners of tomorrow will deal proactively with chaos. They will look at the chaos as the source of market advantage, not as a problem to get around [Peters87].
Creativity theory asserts that our brain processes information at a level that is not accessible to our conscious thought. Creativity theory attempts to understand the individual needs and motivations that are critical to creative solutions [Clemen91]. With creativity, we can generate opportunities by using knowledge and imagination to develop ideas that are either original (previously unknown) or novel (extensions of known). One theory divides creativity into four stages: preparation, incubation, illumination, and verification. Preparation and verification stages use convergent thinking: the ability of the left brain to deduce correct answers logically. Incubation and illumination stages, the heart of the creative process, use divergent thinking: the ability of the right brain to discover new answers through synthesis, imagery, and fantasy. It is in the incubation stage that ideas, associations, and relationships percolate beneath the creator’s conscious awareness. In fact, the right brain is most active when we are dreaming. Highly creative people are intensely observant, have a tolerance for ambiguity, and thrive on complexity and confusion [Fincher89].
Decision theory provides techniques to solve difficult problems—ones that are complex, have uncertain aspects, have multiple objectives, or encompass different perspectives. Decision theory uses probabilities to determine outcomes. Techniques to structure difficult problems include decision trees and computer simulation.
Game theory uses heuristics to determine which alternatives to explore in large search spaces. For example, artificial intelligence research uses the techniques of game theory. Much of what we call intelligence resides in the heuristics humans use to solve problems. The presence of an opponent in game playing adds an element of unpredictability to the game and the need to consider psychological as well as tactical factors in game strategy [Luger89]. Game theory presents life as a contest in which people seek to maximize rewards and minimize risks, while others do the same, often with conflicting objectives.
Portfolio theory is based on the assumption that diversification reduces risk. Putting all your eggs in one basket is an unacceptably risky strategy [Markowitz52]. Applying this theory to software development, this means not to rely heavily on one customer, vendor, method, tool, or person to fulfill project needs. Instead, build a balanced approach that stresses mastery of software project fundamentals.
Probability theory defines probability as a degree of certainty and uses a quantifiable probability to forecast an outcome. Through an estimation of probability before the fact, probability theory determines the probability of an outcome prior to the event’s occurrence. As an instrument for forecasting, probability theory depends on the quality of information that forms the basis of probability estimates.
Uncertainty theory uses probability to model unknown, uncertain, or subjective decision problems. Uncertainty results when there is a lack of adequate information to make a decision [Giarratano89]. The probability distribution of an uncertain event reflects the probability sets of all possible outcomes. Probability distributions are expressed as expected values, variance, and standard deviation.
Utility theory models people’s preference and attitude toward risk. Individuals have different tolerances for risk, which affects the way we make decisions. Utility theory selects the alternative that maximizes the expected-utility function. A utility function can reveal whether the decision maker is risk averse, risk seeking, or risk neutral.
We reason about the probability of risk using aspects of portfolio, probability, and uncertainty theories. Using aspects of chaos, creativity, game, and utility theories, we explore our desires regarding the consequence of risk. The combination of probability and consequence over time yields dynamic risk, which leads to the choices of risk management. We can better understand these choices through the use of Bayes theorem and the techniques of decision theory. These theories and their underlying principles form the basis of the risk management methods explored in this book.
1.1.3 Software Risk
Software risk is a measure of the likelihood and loss of an unsatisfactory outcome affecting the software project, process, or product.
1. Software project risk. This category defines operational, organizational, and contractual software development parameters. Project risk is primarily a management responsibility. Project risk includes resource constraints, external interfaces, supplier relationships, or contract restrictions. Other examples are unresponsive vendors and lack of organizational support. Perceived lack of control over project external dependencies makes project risk difficult to manage. Funding is the most significant project risk reported in risk assessments.
2. Software process risk. This category includes both management and technical work procedures. In management procedures, you may find process risk in activities such as planning, staffing, tracking, quality assurance, and configuration management. In technical procedures, you may find it in engineering activities such as requirements analysis, design, code, and test. Planning is the management process risk most often reported in risk assessments. The technical process risk most often reported is the development process.
3. Software product risk. This category contains intermediate and final work product characteristics. Product risk is primarily a technical responsibility. You may find product risk in the requirements stability, design performance, code complexity, and test specifications. Because software requirements are often perceived as flexible, product risk is difficult to manage. Requirements are the most significant product risks reported in risk assessments.
Figure 1.1 illustrates a useful hierarchy of responsibility for each type of software risk found on software projects. This top-level classification scheme for software risk explicitly shows the multiple inheritance of process risk from both management and technical processes.
Figure 1.1 Software risk classification. Risks may be classified into categories to better understand the nature of the risk. Management contains project and management process risks. Technical contains product and technical process risks. Project is a major risk category that includes customer relationships. Process includes tools to produce a product. Product includes intermediate work products. The top-level classification should be used as a minimum to classify a risk (e.g., Risk.Technical.Process). (This hierarchy is an abstraction of the Software Engineering Institute risk taxonomy [Carr93].)
Each software system is unique with its own particular set of risks. There are many software risks but fewer consequences that we care to avoid. Perhaps that is why we often discuss software risk in terms of the potential cost, schedule, and technical consequences. These three consequences are significant, because they could prevent a software project from meeting its cost, schedule, and technical goals. Goals are important because they define the success criteria for the project. To be successful, software projects must meet their technical requirements within cost and schedule constraints. Software risk is perilous because it can prevent software project success.
1.1.4 Software Risk Management
Software risk management is the practice of assessing and controlling risk that affects the software project, process, or product. You can discover software risks by working backward. First, define your goals and objectives. Then describe the risk in terms of uncertainty, loss, and time. The more clearly you define the goal and the associated risk, the more easily you can communicate these to other team members. Difficult choices often arise when collective team goals compete for the same scarce resources (most often time and money). Consideration of risk information helps teams sort out their priorities and provides the knowledge to make intelligent decisions.
The basic concepts of software risk management are these.
Goal. We manage risk in relation to a specific goal and can affect only the work that remains to achieve the goal. What is the risk in the plan? What is the risk in the remaining work? A clearly defined goal with measurable success criteria bounds acceptable risk.
Uncertainty. Uncertainty is that which we do not know. It is inherent in all of our assumptions and the future itself. There is always a degree of uncertainty in risk occurrence. We can be certain that the probability of risk occurrence is greater than zero and less than 100 percent. This means that we do not know whether the risk will (100 percent probability) or will not (probability of zero) occur. The likelihood that a loss will occur helps to determine the relative priority of the risk.
Loss. Unless there is a potential for loss, there is no risk. The loss can be either a bad outcome or a lost opportunity. An unsatisfactory outcome might be a product with an unacceptable latent defect rate, or failure to meet the desired delivery date. Opportunity is the chance of a good outcome; opportunity cost is the loss of a missed opportunity. Opportunity cost can be calculated in lost customer satisfaction (delivering a buggy product) and lost profits (failing to beat the competition to market).
Time. We need time to anticipate and prevent problems. Time is a great equalizer because every day we each have the same amount. Although a valuable resource, we cannot accumulate time. As time goes by, viable options tend to decrease. By managing risk, we reduce wasted time by using it to our advantage.
Choice. Unless there is a choice, there is no risk management. Sometimes we believe we cannot control risk, or do not feel empowered to select from the available options. Doing something or doing nothing should be a conscious choice. Understanding the goal, and the risk of not achieving the goal, helps us to make the right choice.
We can discover the risk of software risk management by first defining its goals.
Make intelligent decisions. We make intelligent decisions based on awareness, insight, and understanding of risk. Risk management provides a process to communicate risk information and provide visibility into software risks at all project levels.
Resolve risk. We develop and execute a risk action plan to resolve risk. The key to resolving risk is finding risk when there is time to take action and knowing when to accept a risk. It is possible that your risk resolution strategy is not to minimize risk but to maximize opportunity. Acceptable risk is defined by the decision maker.
Prevent problems. Resolution of software risk prevents problems and surprises. Risk management is a proactive strategy to reduce the problem of costly rework.
The risk of software risk management can be described by the uncertainty and loss that might occur if the goals of software risk management are not met. For example, the likelihood of making a bad decision without proper attention to the risk component of the decision is high. The loss caused by a bad decision would not be satisfactory when it could have been prevented. The risk of software risk management is that of making foolish decisions, accepting unsatisfactory outcomes, and paying for costly rework. If you can make a choice to prevent these risks from occurring, then you have time for risk management.
1.1.5 Need for Software Risk Management
Software practitioners have been challenged to make the transition from programmers who write projects in an ad hoc fashion to software engineers who develop high-quality software in a disciplined way. Software engineering is defined as the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines [Naur69]. Software engineering encompasses methods, tools, and procedures that enable managers to control the process and provide practitioners with a foundation for building high-quality software in a productive manner [Pressman92].
There are many reasons that risk management is currently in use on software projects. The ability to manage uncertainty on projects is a requirement designed to deal with scarce resources, advances in technology, and the increased demand for complex systems in a rapidly changing environment. Given the current business climate of shrinking profit margins, the global economy and its uncertain market conditions, and the competitive forces pressured by rapid technology advances, we can all use a coping mechanism. To respond to this need, risk management methods have been tailored for use by software managers and engineers.
Risk management techniques were introduced to the software community in the 1980s. The father of software risk management is Barry Boehm, whose contributions include the Spiral Model, a software life-cycle model that is iterative and risk driven [Boehm88]. The U.S. government has been a major player in defining software risk management to reduce the acquisition risk for software-intensive systems. The Department of Defense (DoD) has provided guidance and funding in this area to the following organizations.
Defense Systems Management College (DSMC). A memorandum from the deputy secretary of defense in 1981 required DoD action to improve the acquisition process. One initiative was to increase the visibility of technical risk in budgets of weapon systems acquisition projects and incorporate the use of budget funds for technological risk. In response, the DSMC wrote a handbook to familiarize project management personnel with the concepts and techniques of quantitative risk assessment to assist them in internal management decision making [DSMC83].
Air Force Systems Command (AFSC). Since 1983, the Software Development Integrity Program has used the Software Development Capability/Capacity Review question set to lower the risk of weapon systems acquisition by determining contractors’ software capability [Babel90]. The Air Force has several publications on risk, including the landmark AFSC/AFLC Pamphlet 800-45 on software risk abatement [AirForce88]. The Air Force has developed the Software Development Capability Evaluation (SDCE) model as a basis for the state of practice in software development [Frankford93]. The primary purpose of the SDCE is to reduce the acquisition risk for software-intensive systems.
Software Engineering Institute (SEI). In 1984, the DoD awarded the Carnegie Mellon University (CMU) a contract to establish the SEI. The SEI Risk Program was chartered in 1990 to develop risk methods and transfer the technology to industry. Two important contributions of the SEI Risk Program are the Risk Management Paradigm and the Taxonomy-Based Questionnaire. The Risk Management Paradigm [VanScoy92] is a model of how the different elements of a risk management process interact. Taxonomy-Based Risk Identification [Carr93] is a repeatable method for identifying risk in software projects using a software risk taxonomy and associated questionnaire.
Software Program Manager’s Network (SPMN). The SPMN was established in 1992 to help DoD software acquisition managers with the difficulties they face in managing complex systems. The SPMN mission is to focus the defense software acquisition community on employing high-leverage management practices that enable competitive software development. These proven practices were shared by successful organizations in the DoD’s Software Acquisition Best Practices Initiative. A best practice is a routine activity that enables excellent performance. The SPMN led this initiative to seek out the practices that improve software productivity and quality while reducing cost and risk. The Airlie Software Council, a group of industry software experts, was brought together to review and achieve consensus on the best practices. The council agreed that risk is inherent in all large software systems. They concluded that if you are told there is no risk, there probably is high risk because of risk that is overlooked until too late. After a rigorous collection and analysis process, SPMN reported formal risk management as the number one best practice [Hall95].
1.2 Risk in the Large
Any professional developing complex software in a team environment can appreciate the concept of programming in the large. If you have had the experience of personally writing a software program to satisfy an academic course requirement, then you understand the concept of programming in the small. Similarly, the distinction can be made between risk in the large and risk in the small.
Those who practice risk management agree that it must be performed regularly throughout the life cycle of a software system. Risks are dynamic, meaning that they change over time. As a project progresses, there is growth in staffing, an increased awareness of project issues, and a different life cycle focus that contribute to the need for routine risk management. Two perspectives hinder routine risk management.
1. Risk viewed as extra activity. Risk management is an extra activity layered on assigned work. The danger in perceiving risks as less important than assigned work is that we may not address risks when work priorities escalate.
2. Risk viewed as outside activity. Risk management is an outside activity that is not your responsibility. The pitfall in perceiving risk as someone else’s responsibility is that when that person is not around, risk management will cease.
When risk management is implemented as a mainstream function in the development process, the project is helped the most. Risk is neither more nor less important than work; it is, instead, a part of the effort remaining. There is not a “risk season” [VanScoy92] or a separate team to perform risk management. Risk management is not tied to a planning phase that is completed early in the project life cycle. For simplicity, most process descriptions show an isolated risk management process—what I call risk in a box. In fact, I use this depiction in discussing the risk management process in Part II. Although this is a convenient way to describe the process itself, it does not provide the understanding of risk in the larger context. My search to understand how risk fits into the big picture of managing product development led to my conclusion that existing management models lacked the ability to describe risk adequately.
1.2.1 The Six-Discipline Model
Two models of managing product development are based on the work of W. Edwards Deming, the father of statistical process control and the Japanese quality revolution. The first, continuous process improvement, is based on evolutionary key process areas of the SEI Capability Maturity ModelSM for Software (SW-CMMSM)1 [Paulk93]. The second, reengineering, is based on revolutionary innovation [Hammer93]. Both approaches have their roots in Deming’s quality work [Deming86]. The Plan-Do-Check-Act (PDCA) cycle popularized by Deming is a closed-loop approach for process optimization. The Deming cycle is an evolutionary model based on the scientific method [Basili95]. The systematic flow of Deming’s evolutionary model for product improvement based on process modification is unquestioned in contemporary quality literature.
1 Capability Maturity Model and CMM are service marks of Carnegie Mellon University.
Deming’s PDCA cycle defines four disciplines of human behavior. A discipline is a body of theory and technique that must be studied and put into practice to be mastered. It has a developmental path for acquiring certain skills or competencies. To practice a discipline is to be a lifelong learner. You spend your life mastering disciplines [Senge90]. The adaptation of Deming’s manufacturing process to software development is lacking a known discipline to develop vision that Deming described but did not diagram in the PDCA cycle. Developing vision is included in my model as the fifth discipline, Envision. In this section, I introduce a sixth discipline, Discover, which extends the Deming cycle by adding the ability to reveal risk and opportunity. These six disciplines are essential to managing development of software systems [Hall97], and together they form a new six-discipline model. The Six-Discipline (6-D) Model, presented in Figure 1.2, describes the relationship among the disciplines required to manage software systems development successfully. Deming’s PDCA disciplines are preserved within the 6-D Model as Plan-Work-Measure-Improve (PWMI). Three terms were updated to reflect the focus at successive SEI CMM levels, which correspond to each of Deming’s disciplines. For example, we do not check the software process, we measure it.
Envision. This discipline means transforming ideas into goals and objectives. Deming’s chain reaction begins with the creation and communication of organizational vision.2 First, management demonstrates its commitment to the vision statement. Then everybody in the organization learns the new philosophy. For a software project, a statement of need, such as “on-time delivery” or “flight safety,” can become the vision. Apple Computer developed the user-friendly Macintosh out of Steven Jobs’s vision of the computer as a household appliance. The vision of the U.S. Air Force that drove the development of the SEI CMM was to identify capable contractors. The power of the SEI CMM lies in its ability to create a vision of a mature process for the software industry. An organization at SEI CMM Level 1 must have management commitment to Envision process improvement.
2 Deming’s chain reaction was a revolutionary concept that showed how an improvement in quality causes productivity to improve. At that time, management believed that quality and productivity were traded off. Deming must have realized the fallacy of the logic in asking the customer, “Which would you prefer: quality or productivity?” His quality philosophy is described in fourteen points that drive the chain reaction.
Figure 1.2 Six-Discipline Model. (E) Envision. Develop a vision for a software product. (P) Plan. Plan the project by mapping resources to the goals established for the software. (W) Work. Produce the product based on the current plan. (M) Measure. Report the variance between expected and actual results to update the plan. (I) Improve. Analyze benchmarks and organization project measures to improve processes and metrics. (D) Discover. Assess the uncertainty of our work and external enigma for risk and opportunity, which we manage through changes to the plan and vision.
Plan. This discipline refers to mapping available resources to requirements, which are derived from project goals and objectives. Although management is responsible for high-level project planning, everyone plans with respect to accomplishing assigned work. We estimate the resources required to perform work based on historical performance data, sequence the planned work in a schedule, and develop standards and procedures such as the software development plan. SEI CMM Level 2 provides key process areas for the Plan discipline.
Work. This discipline refers to implementing the plan to produce the product (Deming’s “Do”). Work is any activity to produce the product, including intermediate and disposable work products (e.g., derived requirements, design documents, and test drivers). By-products of work are status and uncertainty, which develop as you make progress. Work includes identifying the unknowns in the intermediate work product (e.g., incomplete requirements) and uncertainty in the work environment (e.g., unfamiliar tools). If we cannot resolve the uncertainty, we must report it through communication channels designed to inform the appropriate people. Products remain in work until they satisfy the quality criteria. SEI CMM Level 3 provides key process areas for the Work discipline.
Measure. This discipline refers to comparing expected and actual results (Deming’s “Check”). We track our results over time and determine progress by comparing status (Where are we?) to the plan (Where should we be?). We analyze the variance and recommend corrective action. We report the variance between the estimates in the plan and the actual status to allow for mid-course corrections. We update the plan based on variance data from measurements of work status. SEI CMM Level 4 provides key process areas for the Measure discipline.
Improve. This discipline refers to learning from past experience (Deming’s “Act”). We analyze benchmarks and project measures for reporting and improving organizational processes and metrics. Internal measures and external benchmarks help us to know how to change our plan. We retain long-term organizational memory by maintaining process asset libraries, reuse repositories, and organizational metrics. We gather lessons learned to support continuous improvement. SEI CMM Level 5 provides key process areas for the Improve discipline.
Discover. The sixth discipline means becoming aware of the future. We seek to know by investigating what we do not know. We assess the uncertainty of our work for risk, which we manage through changes to the plan. We become cognizant of external enigma that puzzles us. We search for an explanation to ambiguous information by questioning and doubting what we think we know. We uncover opportunity by realizing the answer to the riddle. The significance of the sixth discipline is that it provides the input required to change the vision.
1.2.2 Future Awareness
Many computer companies suffer when senior management fails to read the future direction of the software industry. Even Microsoft chairman Bill Gates, a student of business history, reacted to the explosion of the World Wide Web. As Microsoft sales rocketed to $3.8 billion and staff soared from 5,600 to 14,400 in the early 1990s, chaos from cyberspace was around the corner [Rebello96]. Microsoft engineers worried about their own lack of responsiveness to the new age of Internet computing, yet management seemed asleep at the wheel. How did they manage to wake up in time to avert disaster? The breakthrough for Microsoft came at an executive retreat focused on the Internet as a critical issue. Later, Gates said, “I don’t know of any examples where a leader was totally energized and focused on the new opportunities where they totally missed it” [Gates95].
Future awareness is reasoning about possibilities. Possibilities have uncertain outcomes that may be good or bad. Opportunities are possibilities that have good outcomes; risks are possibilities that have bad outcomes. The sixth discipline, Discover, is the key to accessing future awareness because it resolves enigma that comes from the environment. In Microsoft’s case, past awareness would not have helped solve the 1990 Internet enigma. At that time, Microsoft owned the operating system for the world’s most popular computer, the PC, and its engineers were busy improving their operating system, which shipped as Windows95. No productivity measures or return-on-investment indicators could have told Microsoft management to change its plan. Only attention to the Discover discipline could help Microsoft leaders with the enigma that contradicted their belief that the Internet was free: there was no money to be made in cyberspace.3By struggling with these issues, Microsoft came to understand the opportunity and risk of the Internet, which radically changed their game plan and, most important, led them to a new vision.
3 Today we understand that the Internet is worth billions of dollars.
Whoever changes the rules wins the game. Question: What could take the place of the PC? Answer: The Internet. Because the owner of the preferred operating system of the Internet is TBD (to be determined), Microsoft and the rest of the software community can benefit from learning the disciplines for future awareness. The power of future awareness lies in its ability to provide opportunity for innovation. Innovation introduces something new, which changes the rules within the software community. Consider the changes associated with the invention of Web browsers on the Internet. Web browsers caused new rules for software development, distribution, technical support, marketing, and sales. When a new paradigm appears, everyone must go back to zero [Barker87]. After innovations occur, a new cycle of continuous improvement begins (e.g., better Web browsers). Future awareness and the risk of competition can be the stimulus that drives development of unprecedented software systems, which are radically innovative and fundamentally change the way we live. In this sense, the concept of risk can be revolutionary.
All six disciplines4 are requisite to managing and developing software systems successfully. As shown in Figure 1.3, the disciplines for future awareness are Plan, Work, Discover, and Envision. The disciplines for past awareness are Plan, Work, Measure, and Improve. Many software organizations support either continuous improvement (a model based on past awareness) or reengineering (a model based on future awareness). The fallacy in the logic of choosing between these two management models is that one without the other ultimately creates a dysfunctional organization. Only through the coexistence of past and future awareness can we optimize existing products and capitalize on new opportunities.
4 One acronym for the six disciplines is PM-WIDE, which reminds us to use them programwide.
Figure 1.3 Disciplines for awareness. Past awareness (PWMI) is achieved through planning, working, measuring, and improving. Future awareness (PWDE) is achieved through planning, working, discovering, and envisioning.
1.3 Risk in the Small
In this section, I discuss how individuals within the software community should think about risk. The six disciplines of the 6-D Model form four quadrants of awareness—known, past, unknown, and future—that together describe everything that we can consciously discern (see Figure 1.4).
Known. The Plan, Work, and Measure disciplines provide a short-term perspective of understanding where we are in relation to our plan. With these three disciplines, we can recognize discrepancies between the plan and our work.
Figure 1.4 Quadrants of awareness. The six disciplines form four quadrants of awareness: Known (PWM); Past (PMI); Unknown (PWD); and Future (PDE).
Past. The Plan, Measure, and Improve disciplines provide a long-term perspective of prior experience. With these three disciplines, we can use lessons learned on preceding projects to establish realistic expectations for our current project.
Unknown. The Plan, Work, and Discover disciplines provide a short-term perspective of those pieces of the plan or work that remain to be investigated. With these three disciplines, we can explore hidden requirements or new technology to reveal possible effects on our plans.
Future. The Plan, Discover, and Envision disciplines provide a long-term perspective of prospective circumstances. With these three disciplines, we can perceive an opportunity and capitalize on it.
1.3.1 Personal Awareness
Deming’s disciplines are found within the context of software development at the organization, project, and personal levels. Watts Humphrey states that “the Personal Software Process5 is a self-improvement process (Improve). We are each blessed with unique talents and opportunities. We need to decide what to do with them (Plan). Consistent high performance takes persistent effort (Work), an understanding of your own abilities (Measure), and a dedication to personal excellence (Envision)” [Humphrey95].
5 Personal Software Process and PSP are service marks of Carnegie Mellon University.
Figure 1.5 Quadrants of personal awareness. The six disciplines logically connect four quadrants of our brain. Logic and memory constitute the left brain, emotion and imagination the right brain.
The 6-D Model is also powerful at the personal level. In fact, a personal perspective of the 6-D Model is conceptually more powerful than a Turing machine.6Consider this: What could be more powerful than a computer? The mind of the computer’s creator. Further, the human brain is the most powerful parallel processor on earth. Called the ultimate enigma, the brain perplexes all who presume to take its measure [Fincher89].
6 In 1936, Alan Turing described a simple mathematical model of a computer. The Turing machine is equivalent in computing power to the digital computer as we know it today [Hopcroft79].
The 6-D Model is a requisite set of properly coordinated disciplines because it describes the four quadrants of the human brain: memory, logic, imagination, and emotion.7 (Figure 1.5 illustrates these four quadrants of personal awareness.) Past awareness requires logic and memory, which constitute the left brain. Future awareness requires emotion and imagination, which constitute the right brain. The quadrants of personal awareness are these.
7 Contributed by engineering manager Tom Gorsuch. As part of a leadership workshop, Tom used the Herrmann Brain Dominance Instrument to create a metaphorical model of his thinking cap. Ned Herrmann’s whole brain theory allocates the brain’s specialized modes into four physiological structures [Herrmann96].
Logic. Cerebral left performs the disciplines of Plan, Work, and Measure. Logic helps you understand technical work and precisely measure variance from the plan. Using logic, we can reason about what we know. Cerebral left is the portion of the brain that gathers facts, analyzes issues, and solves problems logically. Words that describe people who prefer to use their cerebral left brain include factual, logical, rational, theoretical, and mathematical.
Memory. Limbic left performs the disciplines of Plan, Measure, and Improve. Memory helps you develop detailed plans and procedures, organize and keep track of essential data, and maintain a standard of consistency. Using memory, we can learn from our experience. Limbic left is the portion of the brain that approaches problems practically and implements projects in a timely manner. Words that describe people who prefer to use their limbic left brain include ordered, detailed, sequential, controlled, and conservative.
Emotion. Cerebral right performs the disciplines of Plan, Work, and Discover. Emotion helps you challenge established policies, solve problems in intuitive ways, and recognize new possibilities. Using emotion, we can interpret our feelings about what we do not know. We can determine our fear of the unknown and develop valuable insight through these perceptions. Cerebral right is the portion of the brain that reads signs of coming change, tolerates ambiguity, helps you see the big picture, and integrates ideas. Words that describe people who prefer to use their cerebral right brain include musical, spiritual, talkative, emotional, and empathetic.
Imagination. Limbic right performs the disciplines of Plan, Discover, and Envision. Imagination helps you develop a vision based on your discovery. Using imagination, we can conceive new ways of living. Limbic right is the portion of the brain that anticipates how others will feel, considers values, and engenders enthusiasm. Words that describe people who prefer to use their limbic right brain include artistic, holistic, flexible, imaginative, and synthesizing.
1.3.2 Risk and Personal Progress
Risk is a consequence of the uncertainty in our work, not a reflection of our own ability. As shown in Figure 1.6, software risk exists in the uncertainty of what it will take to complete an assigned task. For any given task, risk is bounded by the progress made toward task completion and the actual task completion.
Figure 1.6 Risk and scheduled task completion. Risk exists in the unknowns of the work remaining to complete a task. Risk also exists in the work plan, because the plan approximates the time and effort required for task completion. This diagram shows how a task estimated to take three months to accomplish may actually take four months to complete without risk management.
Progress is the movement toward a goal. Risk, like status, is relative to a specific goal (in this example, the goal is task completion). Whereas status is a measure of progress toward a goal, risk is a measure of the probability and consequence of not achieving the goal (an unsatisfactory outcome). Risk is neither more nor less important than work, but rather is one of the obstacles remaining to achieve the goal. We make no progress without conquering risk. This means that if risk has not been resolved in previous work, the reported progress may be at risk. Although we may believe that our status is correct, risk exists whether or not we acknowledge it.
Our professional goals usually include meeting technical requirements and managing project constraints. As a practitioner, I was given three months to design software for a fingerprint-matching subsystem. My goal on the project was to architect this functionality according to the given schedule. My risk was anything that could prevent me from achieving my project goal. To achieve the project goal, I had to use an engineering process, a development system, and my knowledge. Whether your goal is making money from software or making fully functional software, risk is an important concept. Thus, risk management is essential to software managers and technical staff—teams and individuals—who inherit risk as an attribute of their assigned work. To be successful, we must manage software risks.
1.4 Consequences of Knowledge
From the study of risk in software development come awareness and improved understanding in how we think about risk. What are the consequences of this knowledge? What is the opportunity provided by this knowledge?
Knowledge of the 6-D Model and its implication for effective behavior requires an orientation of organizational priorities toward using the six disciplines and recognizing individual intelligence. These priorities are briefly described as follows.
Six disciplines. An orientation toward mastery of the six basic disciplines. These fundamentals support all project roles. Specialization requires that there is a manager who plans, an engineer who works, and a measurement analyst who measures. This specialization does not abdicate our responsibility for learning and using the six disciplines regardless of our assigned task. At the individual level, we use all six disciplines to function each day. We should evolve a basic capability in each discipline concurrently, rather than attempt to master the disciplines one at a time.8
8 This approach to education is similar to learning successive grade levels of English, math, and science in elementary school.
Individual intelligence. An orientation toward the use of individual preference in work assignments. Trying to fit “square” people into “round” jobs reduces the effectiveness of both the individual and the organization. Individual contribution is the key to high-performance teams and profitable organizations. Organizations must recognize the strengths of people who make a contribution by using their brains. People’s brain dominance (either left or right hemisphere) determines their preference, which ultimately determines their capability. From utility theory we know that preference also determines our tolerance for risk, which affects the way we make decisions under uncertainty. We must understand our own preference and that of our coworkers, because at work we rarely resolve risk in isolation.
Knowledge of the sixth discipline, Discover, requires an orientation of personal priorities toward utilizing a creative process and risk management. These priorities are briefly described as follows:
A creative process. An orientation toward repeatable creativity. The next “killer app” (that is, awesome software application program) will more likely be the result of creativity than a scientific experiment. People who prefer to use their right brain can use a creative process for repeatable results. People who prefer to use their left brain can use this process to expand their thinking and achieve results that are similar to their creative counterparts.
Risk management. An orientation toward awareness of the future and our ability to bring the desired future into reality. Time spent understanding the past has diminishing returns when rapid change renders the past obsolete. While software risk exists independent of our individual ability, how we manage that risk does reflect our level of intelligence. The remainder of this book is a practical guide to software risk management.
1.5 Consequences of Ignorance
There was a time when I did not consider risk management as a valuable practice. Unfortunately, I realized the value too late, having invested wealth from my software business poorly due to a lack of financial risk management. From my personal loss, I gained a passion to apply risk management to all areas of my life and to help others understand the consequences of life without risk management. But many people remain in the dark ages and are unaware of the knowledge of risk in software development. What are the consequences of this blissful ignorance? What is the opportunity that is lost by this lack of knowledge? By not doing risk management, you risk the following:
Lack of skills. You will miss the knowledge of risk management principles, methods, and tools to grapple with risk.
Lost opportunity. You miss an opportunity because you are unable to perceive it. Without knowing the risk, you cannot assess the opportunity.
Suffer from mistakes. You increase your chances of blundering into a bad situation because you do not control your risks. You become more afraid to take needed chances. Eventually you stop trying—the only sure way to fail.
Pain of regret. You make a conscious decision to remain in the dark ages. One day, the pain of regret will weigh more than the pain of learning and practicing risk management.
1.6 Summary
In this chapter, I used the simple notation L2 to denote that we measure risk exposure by multiplying likelihood times loss. I defined software risk management as a practice of assessing and controlling risk affecting the software project, process, or product. Since the advent of the risk-driven Spiral Model, risk management has been recognized as an important activity for software projects. Software risk management is necessary for managing and developing software systems.
Software risk is inherent in our work.
Software risk increases as system complexity increases.
Software risk prevents us from achieving our goals and objectives.
Risk fits into the big picture of managing product development as an input to the planning discipline. That is why risk is closely associated with the planning process. The discipline to transform uncertainty into risk is a discovery process, which is quite different from a planning process. I described the Six-Discipline (6-D) Model that enhances W. Edwards Deming’s evolutionary improvement model by addressing the revolutionary concept of risk. The six disciplines of the 6-D Model follow.
1. Envision the product.
2. Plan the work.
3. Work the plan.
4. Measure the work.
5. Improve the process.
6. Discover the possibilities.
I showed how to create opportunity by applying persistence to the possibilities. You may discover the possibilities by searching for them. Perhaps you will find the possibilities in the middle of your difficulty—your risks. You need only to manage them to create opportunity—your good outcomes.
1.7 Questions for Discussion
1. Do you think you should perform software risk management regularly throughout a project life cycle? Explain your answer.
2. What is a discipline? Describe the two disciplines of the 6-D Model that integrate risk into product development.
3. In what way is risk assessment a discovery process? List three items you might observe in a risk assessment at each phase of software development: requirements, design, code, and test. Give an example of a risk for each item you have observed.
4. Compare and contrast risk and risk management. Do you agree that software risk is independent of our individual ability? Discuss why you do or do not agree.
5. In your opinion, what is the power of the 6-D Model at the personal level? Describe your preference for using your left or right brain. Discuss the disciplines that are your strengths. Explain how an understanding of personal strengths can help a person find the right career path.
6. What is the relationship between risk and progress? Do you agree that you need to manage risk to make progress? Discuss why you do or do not agree.
7. Does the 6-D Model change how you think about risk? If so, what difference do you think that will make in the way you work?
8. Who should use risk management? How would software engineers benefit from applying risk management to their work?
9. Why should risk management be used? Identify the benefits of using risk management on software projects. Discuss the extent to which you need risk management in your current assignment.
10. What is the difference between risk and opportunity? Explain your answer.
1.8 References
[AirForce88] Air Force. Software Risk Abatement. AFSC/AFLC pamphlet 800-45. Wright-Patterson Air Force Base, OH: Air Force Systems Command, Air Force Logistics Command, 1988.
[American85] The American Heritage Dictionary. 2d college ed., Boston: Houghton Mifflin, 1985.
[Babel90] Babel P. Software Development Integrity Project. Video. Herndon, VA: Software Productivity Consortium, 1990.
[Barker87] Barker J. Discovering the Future: The Power of Vision. Video. Burnsville, MN: Chart House Int., 1987.
[Basili95] Basili V. “The Experience Factory and Its Relationship to Other Quality Approaches.” Advances in Computers, Vol. 41. Academic Press, 1995.
[Bayes63] Bayes T. “An Essay Towards Solving a Problem in the Doctrine of Chances.” Philosophical Transactions. Essay LII. 1763.
[Bernoulli38] Bernoulli D. “Specimen Theoriae Novae de Mensura Sortis (Exposition of a New Theory on the Measurement of Risk).” Translated from the Latin by Louise Sommer in Econometrica, 22:23–36, 1954.
[Bernstein96] Bernstein Peter L. Against the Gods: The Remarkable Story of Risk. New York: Wiley 1996.
[Boehm88] Boehm B. “A Spiral Model of Software Development and Enhancement.” IEEE Computer 21(5) (1988): 61–72, 1988.
[Carr93] Carr M, Konda S, Monarch I, Ulrich F, Walker C. Taxonomy Based Risk Identification. Technical report CMU/SEI-93-TR-6. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1993.
[Champy95] Champy J. Reengineering Management. New York: Harper-Collins, 1995.
[Clemen91] Clemen R. Making Hard Decisions: An Introduction to Decision Analysis. Belmont, CA: Wadsworth, 1991.
[David62] David. Games, Gods, and Gambling. New York: Hafner Publishing, 1962.
[Deming86] Deming W. Out of the Crisis. Cambridge, MA: MIT Center for Advanced Engineering Study, 1986.
[DSMC83] Defense Systems Management College. Risk Assessment Techniques. Fort Belvoir, VA, 1983.
[Fincher89] Fincher J. The Brain: Mystery of Matter and Mind. Washington, DC: U.S. News Books, 1989.
[Frankford93] Frankford R. (ed.). Software Development Capability Evaluation. AFMC pamphlet 800-61. Wright-Patterson Air Force Base, OH: Air Force Material Command, 1993.
[Gates95] Gates W. The Road Ahead. New York: Viking, 1995.
[Giarratano89] Giarratano J, Riley G. Expert Systems Principles and Programming. Boston: PWS-KENT Publishing, 1989.
[Groebner93] Groebner D, Shannon P. Business Statistics: A Decision-Making Approach. 4th ed. New York: Macmillan, 1993.
[Hall97] Hall E, Gorsuch T. “A Sixth Discipline for Future Awareness.” Proc. Seventh International Symposium of the International Council on Systems Engineering, Los Angeles, August 1997.
[Hall95] Hall E. “Formal Risk Management: #1 Software Acquisition Best Practice.” Proc. 4th SEI Conference on Software Risk, Monterey, CA, November 1995.
[Hammer93] Hammer M, Champy J. Reengineering the Corporation. New York: Harper-Collins, 1993.
[Herrmann96] Herrmann N. The Whole Brain Business Book. New York: McGraw-Hill, 1996.
[Hopcroft79] Hopcroft J. and Ullman J. Introduction to Automata Theory, Languages, and Computation. Reading, MA: Addison-Wesley, 1979.
[Humphrey95] Humphrey W. A Discipline for Software Engineering. Reading, MA: Addison-Wesley, 1995.
[Kolarik95] Kolarik W. Creating Quality: Concepts, Systems, Strategies, and Tools. New York: McGraw-Hill, 1995.
[Luger89] Luger G, Stubblefield W. Artificial Intelligence and the Design of Expert Systems. Redwood City, CA: Benjamin/Cummings Publishing, 1989.
[Markowitz52] Markowitz H. “Portfolio Selection.” Journal of Finance, Vol. VII, No. 1 (March), pp. 77–91, 1952.
[Naur69] Naur P, Randell B. Software Engineering: A Report on a Conference Sponsored by the NATO Science Committee. NATO, 1969.
[Paulk93] Paulk M, et al. Capability Maturity Model for Software. Version 1.1. Technical report CMU/SEI-93-TR-24. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1993.
[Peters87] Peters T. Thriving on Chaos. New York: HarperCollins, 1987.
[Pressman92] Pressman R. Software Engineering: A Practitioner’s Approach. New York: McGraw-Hill, 1992.
[Rebello96] Rebello K. “Inside Microsoft.” BusinessWeek, July 15, 1996.
[Senge90] Senge P. The Fifth Discipline: The Art & Practice of the Learning Organization. Garden City, NY: Doubleday, 1990.
[VanScoy92] VanScoy R. Software development risk: Problem or opportunity. Technical report CMU/SEI-92-TR-30. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1992.