Applied Software Risk Management

A Guide for Software Project Managers

C. Ravindranath Pandian

• Publisher: Auerbach Publications
• Year: 2006
• Print ISBN: 9780367453299
• eBook ISBN: 9781000611229
• Edition: 1
• Topic: Business
• Subtopic: Project Management
• Index: Business

Few software projects are completed on time, on budget, and to their original specifications. Focusing on what practitioners need to know about risk in the pursuit of delivering software projects, Applied Software Risk Management: A Guide for Software Project Managers covers key components of the risk management process and the software development

Chapter 1

Risk Culture

1.1 Risk Thinking

What makes us think of risks? Is it backward thinking or forward thinking? Will it allow us to grow and progress or slow us down? Such questions confront us when we think of risk management. In growth-oriented management cultures of the past, negative aspects were not mentioned. The drive was to reach out and move ahead. In those days, to reflect upon failure was a sign of weakness. The entrepreneur was a go-getter who crossed all barriers and achieved.

Thinking about failure came into management paradigms through different avenues. First, the market demanded fail-safe products. The product developer was forced to look at failure possibilities and come up with a robust design. He struggled to remove what we refer to today as “product risks.” The discipline of technology management accepted risk thinking rather elegantly. It made sense to product developers to design a product with minimum risks for the user. The success of risk management in product development also fuelled technological progress and expansion. To identify product risks, a fuller and more mature technical knowledge was required. It was not a smooth beginning. Although designers enjoyed the creative pleasures and excitement of design, they disliked risk analysis of their products. In due course, product risk analysis was accepted by the industry.

Second, for finance management, risk became an investment question. Credit risk was studied, defined, and measured religiously in finance institutions. Variation in ROI was a measure of risk, striking a sympathetic chord with the age-old concept that “variation is trouble.”

Third, risk considerations became an integral part of project management. Project managers (PMs) saw risk more clearly than anybody else. Projects were clearly risky. Building a dam in a jungle involved risks of all kinds. Constructing an underwater oil line also entailed huge risks. In such cases, a project was synonymous with risks. Managing a project implied living with risks around the clock.

All these influences have finally touched software project management. We all know that projects are associated with risks. Today, risk thinking is a part of software project life and is a basic step for project survival. Modernism in management manifests as “failure thinking,” or predating failure probabilities in endeavors, and a freedom to communicate potential failures to stakeholders, without fear of being misread. This new culture accommodates risk thinking.

1.2 What Is Risk?

The original meaning of risk is associated with gambling — to risk is to gamble. When we take risks, there is a chance of gaining and perhaps an equal chance of losing.

Uncertainty in business ventures has come to be known as risk. Every business venture is basically risky. In new business ventures and new product development, there are unknown factors and their impacts on the venture are equally unknown. The unknown factors could be favorable or unfavorable. There is a probability that one may either gain or lose. However, a loss may hurt the venture. Most business ventures like to assess the probability of loss and compare it with the probability of gain. The decision to go ahead depends on whether the odds are favorable or unfavorable. Risk is the probability of suffering loss. Using this approach, the business house will not pursue a venture that has a risk probability greater than 49 percent. The odds must be in favor of winning the gamble, even though the tilt is marginal.

Definition 1.1: Risk is the probability of suffering loss.

A refinement of this definition is to include goals, gains, or opportunities in the statement. Perhaps it is implied and obvious that risks are connected with gains. Nevertheless, if risks are divorced from the associated goals, then one sees just a set of problems. A risk list should not be reduced to a problem list. Risks have a much broader role to play.

Definition 1.2: Risk is the probability of suffering loss while pursuing goals.

Then there is the consideration of the magnitude of harm from the risk. What will its impact be? The consequence of the risk is evaluated. If the harm is tolerable but the gains are attractive, new decision rules emerge. One may even take a risk where the occurrence probability is greater than 50 percent. The threshold is not 49 percent. Risk is seen as a weighed parameter. The weight is based on the magnitude of loss due to risk, if the risk ever occurs. Risk is defined as the combination of probability of occurrence and the magnitude of loss it causes. This combination is also known as risk exposure.

Definition 1.3: Risk is the combination of probability and magnitude of loss.

Currently, risk is defined and measured using Definition 1.3. Measurement of risk is often a subjective process. Both the probability and loss are measured using linguistic measures such as “high,” “medium,” and “low.” What matters is not just the risk, but its intensity, measured as risk exposure. Will the risk occur? What will the harm be? These are more significant questions than, “What is the risk?”

A clarification is due at this juncture. If loss occurs because of factors within our control, it is not considered as a risk. Factors beyond our control give rise to risk. This is the general perception that makes risk management simple. Internal factors are within our control. Hence, only external factors that contribute to loss, which are not under our direct control, qualify as risk factors. When this notion prevailed, people believed that they had not caused the risks.

Sometimes, processes are not in control and results are not predictable or what were intended. Such losses become risks. In this case, the origin is not the criterion — predictability and control are important factors. Hence, a complete risk definition would be:

Definition 1.4: Risk is the probability of suffering loss while pursuing goals due to factors that are unpredictable or beyond.

1.3 A Boundary Problem

What is risk? The answer to this question depends on who answers it and the boundaries the individual establishes around himself or herself. If the answer comes from someone who is responsible for all processes within the boundary, a clear answer can be expected. Risk is obvious when people own their processes. The owner is anxious about resources being well spent and not wasted, and that the results are acceptable. He wants to maximize the chance of success and looks for clues to act upon. In other words, the owner deliberately sees risks and responds to them. If he grows nonchalant and detached, he does not see many risks or does not feel like acting upon them. When nonowners see risks and communicate them to those who run the process, the result is conflict.

Risk arises from factors beyond our control. A designer may consider requirement analysis as a source of risk because it is external to him and he is not sure whether the analysis results will be communicated completely and correctly. This is a “dependency risk.” A boundary is drawn around the process, and risks that threaten the process from across the boundary are seen. Risk perception has a built-in boundary perception. Risk definition has meaning only with reference to this boundary.

Within the process owner’s boundary, a problem is not immediately seen as a risk, even if it happens to be vague and uncertain. The propensity is to assign the problem to process control and process management.

Across the boundary, the propensities change. A process owner has no influence beyond his boundary. Neighboring processes are alien and appear to be sources of risk. Problems tend to get labeled as risks.

When the boss of the SBU (strategic business unit) looks at the same risk from a larger perspective, the risk looks smaller and local. The risk appears to have occurred due to lack of cooperation between two process owners. He does not want to think of this local issue as a major risk, as things can improve through better management. If provoked, he may term this an internal risk that can be solved by taking internal measures. The SBU boss realizes that the better the management, the fewer the internal risks.

There are some sensitive internal conditions, such as when a PM chooses to run a project without adequate resources and authority. The processes have weaknesses that are well known to the stakeholders. Process weaknesses are potential breeding grounds for risks. But he may not have the resources, power, and influence to improve process capabilities. All he can do is mitigate the harmful effects, promote awareness of the risks, and prepare contingency plans. Risks have a different connotation in this case.

It is important to define internal risks, because they contribute to more than 65 percent of risks in a typical business environment.

Internal risks are solved by internal response plans. Most internal risks evoke short-term plans that operate within the life of the project. These are dependency risks that are solved by better coordination and risk communication. Some internal risks arise because of lack of ...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Table of Contents
• 1 Risk Culture
• 2 Risk Management Process
• 3 Risk Attributes
• 4 Risk Identification
• 5 Risk Analysis
• 6 Responding to Risk
• 7 Risk Tracking
• 8 Risk Models
• 9 Risk Intelligence
• 10 Feed Forward
• 11 Integrated Risk Management
• 12 Risk Management: Draft Procedures
• Appendix A: Caper Jones’s Risk
• Appendix B: Rex Black’s Quality Risk List
• Appendix C: SEI Risk Taxonomy
• Appendix D: Top N Software Risks
• Appendix E: PMI, Risk Management Process
• Appendix F: IRM, Risk Management Standard
• Appendix G: Continuous Risk Management (CRM) Paradigm
• Appendix H: Barry Boehm’s Risk Management Process
• Appendix I: Risk Management in CMMi
• Appendix J: Requirement Risk versus Measurable Quality Attributes
• Appendix K: Diary of a Risk Manager
• Risk Glossary
• References
• Index